系统架构=业务架构+软件架构.pptVIP

8.1 业务架构 可见，喜欢和迷信技术的我们又忘了一个基本原则：技术服务于业务。尽管我们知道怎么样搭建房子，而手中却没有可用的砖头，怎么能建好房子呢？正所谓巧妇难为无米之炊啊。软件、技术通通是服务于业务的，技术只是保证做好系统的手段，一个好的软件其根本还在于业务的理解上。 8.1 业务架构 SAP是业界著名的ERP软件产品，它之所以能够做到通用，即使在不同行业间实施也只需很小的开发工作量，绝大部分需求都是通过配置来完成的。不是因为SAP采用了多么先进的技术架构，而是因为SAP把业务做到了极致，它已经砌好了那些可以搭建不同业务平台的各式各样的砖块。再复杂和迥异的需求，都可以用这些砖块搭建出来。这些砖块，就是业务架构。 8.1 业务架构 在项目开发过程中，当我们获得了一份需求时，如果不建立业务架构，那么这份需求对我们来说就是一盘沙子，每次我们都要从头把沙子做成砖块，一点点辛苦地开发程序。而建立业务架构的工作，就是要把沙子变成各式各样的砖块、部件，从部件做起而不是从沙子做起，像拼图一样，拼出我们的世界来。 8.1 业务架构 但这项工作是非常困难的，需要非常精深的行业知识。并且不是一朝一夕就可行的，必须通过几个甚至几十个项目的累积，才有可能总结出可用的拼图。在开发项目时，仅将业务架构作为项目中的一项工作，它可能不会对你当前的项目带来什么好处，但是随着每一个项目的积累，不断地修正和丰富业务架构，手中可用的砖块就会越来越多，越来越丰富。总有一天，你可以用拼图来完成项目中大部分的业务需求，也就是行业解决方案的形成。 8.2 业务架构分析 分析工作往往被模糊化，经常的情况是需求弄清楚以后直接进入设计阶段，例如详细的表结构、类方法、属性、页面原型等，然后就进入编码阶段了。那么分析与设计之间究竟存在什么样的差别呢？ 从工作任务上来说，分析做的是需求的计算机概念化；设计做的是计算机概念实例化。 从抽象层次上来说，分析高于实现语言、实现方式；而设计则基于特定的语言和实现方式。因此分析的抽象层次高于设计的抽象层次。 从角色上来说，分析由系统分析师承担的，而设计则由设计师来承担。 从产出物上来说，分析的典型成果是分析模型和组件模型，设计的成果是设计类、程序包等。 8.2 业务架构分析 系统分析是在不考虑具体实现语言和实现方式的情况下，将需求在软件架构和框架下进行的计算机模拟。系统分析的目的是确定系统应当做成什么样的设想，而系统设计的目的是将这些设想转化为可实施的步骤。如果类比于房屋装修，分析相当于绘制设计图，而设计则相当于绘制施工图。分析决定哪个地方用哪个物品来装饰，设计决定如何装饰，用什么工具来装饰。 8.2 业务架构分析 事实上，经过分析之后，已经决定了系统要做成什么样子，已经完成了从需求到系统的转换过程。至于接下来是用JAVA还是C#，是用J2EE还是.NET，是用两层结构还是用三层结构，是用工厂模式还是用适配器模式就已经不是问题的重点了。不论采取什么样的实现方式，得到的结果无非是程序运行效率的高低、扩展性、可维护性的差别，无论如何都不会影响系统实现需求这一最基本的要求。 8.2 业务架构分析 8.2.1 客户服务系统业务架构分析 8.2.2 客户服务系统子模块划分 8.2.1 客户服务系统业务架构分析 8.2.1 客户服务系统业务架构分析 通过整理客户服务系统的需求，我们摘录出系统的核心业务如下： (1) 公司客户通过电话完成对软件产品或项目提出使用中的BUG或疑难问题以及投诉建议等内容。 (2) 客户服务人员代理公司客户将咨询内容录入到客户服务系统中，以供备案查询。 (3) 部门领导负责处理相关客户的投诉建议及故障申报，并视具体情况安排维护人员上门维护及安排客户服务人员进行回访。 (4) 维护人员通过查询任务安排，接受相关派工任务，并填写维护报告。 (5) 客户服务人员通过查询任务安排，接受相关回访任务，并填写相关回访报告。 (6) 系统管理员对系统基础资料进行维护管理。 (7) 部门领导可以查询客户服务人员及维护人员的工作完成情况。 由此分析出客户服务系统的核心业务架构，用业务活动图表示如图8-2所示。 8.2.1 客户服务系统业务架构分析 8.2.1 客户服务系统业务架构分析 业务架构与核心模型的关系可用图8-3来表示。用例模型、领域模型所描述的业务过程，通过抽象可得到业务架构。反过来，业务架构对用例模型和领域模型则有着重要的指导作用。尤其在业务架构改进的时候，某些用例可能需要重组，领域模型也可能重构。 8.2.1 客户服务系统业务架构分析 8.2.1 客户服务系统业务架构分析 从图8-3可以看出，实际上建立业务架构的活动是一个反复迭代的过程，且非常类似于面向过程的结构化设计，不同的是，在结构化设计方法中，得到的结果是子