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

2020年2月24日星期一第1页第8章系统架构设计对于软件系统来说，描述系统架构一般涉及到两个方面的内容：业务架构和软件架构。这两方面内容分别针对于人们对业务领域的理解和对系统领域的理解。这两者是需要和谐统一的，前者从业务需求的角度出发，理清物理结构图和逻辑结构图，划分出每个子模块。确定为什么要这么划分，各个子模块之间如何交互，每个子模块具有哪些接口；后者从解决技术上讨论，着重讨论采用什么样的技术，如何分层，采用哪些好的技术特性，采用这些技术特性会为我们的工作带来哪些好处，为什么要这么做等。2020年2月24日星期一第2页第8章系统架构设计8.1业务架构8.2业务架构分析8.3软件架构8.4软件架构设计8.5软件架构与框架8.6软件架构的“4＋1”视图模型8.7组件图8.8部署图2020年2月24日星期一第3页8.1业务架构1.问题引入系统架构一般涉及到两个方面的内容，其一是业务架构，其二是软件架构。人们常常会听到软件架构这个词，对软件架构的概念也有一些了解，但是，也许还有人对业务架构这个词比较陌生，那么，究竟什么是业务架构呢？2020年2月24日星期一第4页8.1业务架构2.解答问题业务架构描述了业务领域主要的业务模块及其组织结构。业务架构在先启阶段建立，在精化阶段得以改进（关于先启阶段、精化阶段等内容请读者参见第3章的RUP统一过程的相关内容）。业务架构的目的是为业务领域建立一个维护和扩展的结构，描述业务的构成。业务架构对我们理解客户业务，尤其是对软件开发行业确定解决方案起着非常重要的作用。2020年2月24日星期一第5页8.1业务架构3.分析问题软件开发一直在追求构件化，就像建房子一样来构建系统，用一块一块砌成不同形状的砖头来搭建自己想要的房子。在很多人看来，构件化开发是技术问题。即随着技术的发展，各种先进的架构和技术框架能够越来越多地解决复杂的现实问题，总有一天，我们能够利用一个极其灵活和强大的技术架构，将现实中的业务像搭房子一样构建出整个系统。但是，技术架构仅仅提供了您搭建房子的手段和方法，从可行性上给予您支持，您是否想过您砌成大大小小不同形状的砖头是什么呢？它们从何而来呢？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客户服务系统子模块划分2020年2月24日星期一第14页8.2.1客户服务系统业务架构分析1.问题引入上面我们已经了解了分析与设计的区别，接下来将讨论客户服务系统的业务架构分析与实现。2020年2月24日星期一第15页8.2.1客户服务系统业务架构分析2.解答问题客户服务系统的业务架构如图8-1所示。8.2.1客户服务系统业务架构分析电话咨询客户客服人员维护人员部门领导管理员投诉处理维护处理回访处理信息查询系统管理图8-1客户服务系统业务架构2020年2月24日星期一第17页8.2.1客户服务系统业务架构分析3.分析问题对客户服务系统业务架构的分析立足于对需求足够理解的基础之上，我们知道软件开发中最重要的就是抽象，也就是采用OO（面向对象）的思想，这个思想应贯穿于软件开发过程的始终。需求作为分析过程的输入，需求分析后，产生用例模型和领域模型。用例模型和领域模型是业务架构的基础。如果只有用例模型和领域模型而没有业务架构，我们将“只见树木不见森林”。因为不论是用例模型还是领域模型，它们都只是业务领域的一部分。如果说用例模型代表了一个软件项目对需求的定义和理解，那么架构就代表了一个软件项目对系统的定义和理解。架构将系统规划为一些独立的逻辑组件，各负其责，这些组件通过标准的通信接口传递信息。一个架构就是一个系统的骨架。8.2.1客户服务系统业务架构分析通过整理客户服务系统的需求，我们摘录出系统的核心业务如下：(1)公司客户通过电话完成对软件产品或项目提出使用中的BUG或疑难问题以及投诉建议等内容。(2)客户服务人员代理公司客户将咨询内容录入到客户服务系统中，以供备案查询。(3)部门领导负责处理相关客户的投诉建议及故障申报，并视具体情况安排维护人员上门维护及安排客户服务人员进行回访。(4)维护人员通过查询任务安排，接受相关派工任务，并填写维护报告。(5)客户服务人员通过查询任务安排，接受相关回访任务，并填写相关回访报告。(6)系统管理员对系统基础资料进行维护管理。(7)部门领导可以查询客户服务人员及维护人员的工作完成情况。由此分析出客户服务系统的核心业务架构，用业务活动图表示如图8-2所示。8.2.1客户服务系统业务架构分析图8-2客户服务核心业务活动图8.2.1客户服务系统业务架构分析业务架构与核心模型的关系可用图8-3来表示。用例模型、领域模型所描述的业务过程，通过抽象可得到业务架构。反过来，业务架构对用例模型和领域模型则有着重要的指导作用。尤其在业务架构改进的时候，某些用例可能需要重组，领域模型也可能重构。8.2.1客户服务系统业务架构分析图8-3业务架构与核心模型的关系8.2.1客户服务系统业务架构分析从图8-3可以看出，实际上建立业务架构的活动是一个反复迭代的过程，且非常类似于面向过程的结构化设计，不同的是，在结构化设计方法中，得到的结果是子系统、模块；而在面向对象的设计方法中，得到的结果则是业务组件。2020年2月24日星期一第23页8.2.2客户服务系统子模块划分1.问题引入了解客户服务系统的业务架构图之后，接下来我们应该做的就是对客户服务系统划分模块。2020年2月24日星期一第24页8.2.2客户服务系统子模块划分2.解答问题客户服务系统的子模块如图8-4所示。8.2.2客户服务系统子模块划分客服系统mainsystem系统管理模块subsystem客服业务处理模块subsystem信息查询统计模块subsystem图8-4客户服务系统子模块8.2.2客户服务系统子模块划分进一步划分模块，系统管理模块、客户服务业务处理模块、信息查询统计模块分别划分为如图8-5、图8-6、图8-7所示的子模块。8.2.2客户服务系统子模块划分系统管理模块subsystem客户资料管理subsystem系统用户管理subsystem产品及项目管理subsystem经验库管理subsystem系统维护管理subsystem图8-5系统管理模块8.2.2客户服务系统子模块划分客服业务处理模块subsystem客户咨询管理subsystem咨询投诉报障派工管理subsystem维护安排回访安排图8-6客户服务业务处理模块8.2.2客户服务系统子模块划分信息查询统计模块subsystem基础资料查询统计客户咨询查询统计派工单完成情况查询统计报表查询图8-7信息查询统计模块2020年2月24日星期一第30页8.2.2客户服务系统子模块划分3.分析问题(1)客户服务系统子模块在得到业务架构的基础上，我们对客户服务系统的业务进行细分为以下三个子模块：①系统管理模块。包括客户基础资料录入修改，客户服务系统用户信息的添加、删除和修改，软件产品的基础资料维护，已上线项目的基础资料维护，FAQ经验库的数据维护以及客户服务系统本身的维护管理等。②客户服务业务处理模块。包括客户咨询服务处理、故障申报处理、投诉处理，部门领导派工处理，客户服务人员回访处理，维护人员上门处理等。③信息查询统计模块。包括基础资料查询统计，客户咨询的查询与统计，派工单完成情况，回访报告，维护报告查询统计以及相关报表的查询等。2020年2月24日星期一第31页8.2.2客户服务系统子模块划分(2)各子模块的功能①系统管理模块客户资料管理客户资料是客户服务系统的根源，只有健全的客户资料体系才能够保证客户服务有序地开展。主要包括录入客户资料、修改客户资料、删除客户资料和查询客户资料等功能。系统用户管理包括本系统的所有使用者的信息资料管理及查询。产品管理包括公司所有发布的软件产品信息的管理及查询。项目管理包括公司所承担的各种软件研发项目信息的管理及查询。经验库管理包括经验信息的管理及查询。8.2.2客户服务系统子模块划分②客户服务业务处理模块。客户咨询管理包括客户咨询信息的管理及查询。客户咨询服务活动如图8-8所示。图8-8客户咨询服务活动图8.2.2客户服务系统子模块划分派工管理当有客户投诉及报障时，部门领导会立即对投诉及报障的客户作出快速反应，及时安排派工任务。对投诉的客户安排客户服务人员及时回访处理；对报障的客户安排维护人员进行上门维护处理。派工活动图如图8-9所示。图8-9部门领导派工活动图8.2.2客户服务系统子模块划分③信息查询统计模块包括查询统计基础资料、客户咨询信息、派工单完成情况等信息，并可打印报表。2020年2月24日星期一第37页8.3软件架构1.问题引入经