解上。Р8.1 业务架构РSAP是业界著名的ERP软件产品,它之所以能够做到通用,即使在不同行业间实施也只需很小的开发工作量,绝大部分需求都是通过配置来完成的。不是因为SAP采用了多么先进的技术架构,而是因为SAP把业务做到了极致,它已经砌好了那些可以搭建不同业务平台的各式各样的砖块。再复杂和迥异的需求,都可以用这些砖块搭建出来。这些砖块,就是业务架构。Р8.1 业务架构Р在项目开发过程中,当我们获得了一份需求时,如果不建立业务架构,那么这份需求对我们来说就是一盘沙子,每次我们都要从头把沙子做成砖块,一点点辛苦地开发程序。而建立业务架构的工作,就是要把沙子变成各式各样的砖块、部件,从部件做起而不是从沙子做起,像拼图一样,拼出我们的世界来。Р8.1 业务架构Р但这项工作是非常困难的,需要非常精深的行业知识。并且不是一朝一夕就可行的,必须通过几个甚至几十个项目的累积,才有可能总结出可用的拼图。在开发项目时,仅将业务架构作为项目中的一项工作,它可能不会对你当前的项目带来什么好处,但是随着每一个项目的积累,不断地修正和丰富业务架构,手中可用的砖块就会越来越多,越来越丰富。总有一天,你可以用拼图来完成项目中大部分的业务需求,也就是行业解决方案的形成。Р8.2 业务架构分析Р分析工作往往被模糊化,经常的情况是需求弄清楚以后直接进入设计阶段,例如详细的表结构、类方法、属性、页面原型等,然后就进入编码阶段了。那么分析与设计之间究竟存在什么样的差别呢??从工作任务上来说,分析做的是需求的计算机概念化;设计做的是计算机概念实例化。?从抽象层次上来说,分析高于实现语言、实现方式;而设计则基于特定的语言和实现方式。因此分析的抽象层次高于设计的抽象层次。?从角色上来说,分析由系统分析师承担的,而设计则由设计师来承担。?从产出物上来说,分析的典型成果是分析模型和组件模型,设计的成果是设计类、程序包等。
全文预览
