软件工程-第7章 系统架构设计.pptx

软件工程-第7章 系统架构设计.pptx

《软件工程-第7章 系统架构设计.pptx》由会员分享，可在线阅读，更多相关《软件工程-第7章 系统架构设计.pptx（115页珍藏版）》请在冰豆网上搜索。

*,第*页,第7章系统架构设计,对于软件系统来说，描述系统架构一般涉及到两个方面的内容：

业务架构和软件架构。

这两方面内容分别针对于人们对业务领域的理解和对系统领域的理解。

这两者是需要和谐统一的，前者从业务需求的角度出发，理清物理结构图和逻辑结构图，划分出每个子模块。

确定为什么要这么划分，各个子模块之间如何交互，每个子模块具有哪些接口；后者从解决技术上讨论，着重讨论采用什么样的技术，如何分层，采用哪些好的技术特性，采用这些技术特性会为我们的工作带来哪些好处，为什么要这么做等。

*,第7章系统架构设计,7.1活动图7.2状态图7.3业务架构7.4业务架构分析7.5软件架构7.6软件架构设计7.7组件图7.8部署图第*页,*,第*页,7.1活动图,1.问题引入活动图是一种对动态行为建模的交互图。

它常用来对业务流程建模，但您也可以使用它对对象在交互期间执行的操作（类的操作）建模。

在RationalRose中如何建立活动图？

*,第*页,7.1活动图,2.解答问题,以客户服务人员处理来电咨询为例建立活动图，其结果如图7-1所示。

7.1活动图,图7-1客户服务人员处理来电咨询活动图,7.1活动图,3.分析问题图7-1中，当“客户来电”事件发生后，进入“来电咨询”活动，如果受理，则查询客户信息，否则，活动结束；当查询客户信息时，如查询到该客户，则判断咨询类型，否则新增一个客户的信息；咨询类型有三种：

咨询、投诉、报障，如果是咨询，判断是否是能解答的问题，如果能，则直接处理，否则，由维护人员跟进；如果是投诉，转入投诉处理；如果是报障，则转入故障处理。

咨询处理结束后，填写咨询处理结果，整个活动流程自动结束。

7.1活动图,一个基本活动图通常具有以下元素：

开始点：

用填充的圆圈表示。

在同一个包的同层次活动图中，只允许存在一个开始点。

结束点：

活动图可以有一个或多个结束点，用牛眼符号表示。

活动：

表示工作流程中的任务或步骤。

用环绕着活动文本的圆头矩形表示。

如图7-1中的“来电咨询”、“查询客户信息”等。

7.1活动图,活动转换：

用来显示活动状态的先后顺序。

这种类型的转换通常称为完成转换，它不需要显式的触发器事件，是直接通过任务完成来触发。

活动之间的转换用带箭头的连接线表示。

从一个活动转换到另一个活动，如：

当有“来电咨询”后，如果“受理”了，下一步要做的就是“查询客户信息”，因此，就从“来电咨询”活动转换到了“查询客户信息”活动。

整个活动流程按箭头的流向进行。

7.1活动图,活动图可以说明在转换发生之前必须为“真”的警戒条件，用方括号括起来的内容，如图7-1中的“受理”、“不受理”等是转换发生前的警戒条件。

在RationalRose的活动图中，双击转换线，打开【StateTransitionSpecification】对话框，在【Detail】页的【GuardCondition】栏中输入警戒条件，如“受理”。

如图7-2所示。

7.1活动图,图7-2警戒条件,7.1活动图,决策：

用判断菱形表示。

为其定义一组警戒条件。

警戒条件控制当某个任务完成时转换到一组备选转移中的哪一个转移。

通常用在两个或两个以上分支的情况。

如图7-1中，当有来电咨询，需要查询有没有要咨询的客户时，有两个分支：

有客户和没有客户，其处理步骤不同，因此需要两个可选流程。

我们也可以使用决策图标来显示这些流程在何处再次合并。

比如，在图7-1中，当“咨询”、“报障”、“投诉”处理结束后，将这三个分支流程合并起来。

7.1活动图,同步条：

用来处理并行子流程。

并行活动按什么顺序发生并不重要，它们可以同时发生，或者可以交迭发生。

同步条还用于将同步发生的活动集合起来，这就意味着向外的转换仅在所有向内的转换发生之后才发生。

如图7-3所示的粗水平线即为同步条，图中“准备货物”和“开发票”两个活动的先后顺序无明确规定，既可以同时发生，也可以交迭发生。

同步条有两种：

一种是在上面已经提到的水平同步条，另一种则是垂直同步条。

一般地，如果分叉的多个活动横向排列时，使用水平同步条；当多个活动竖向排列时，则使用垂直同步条。

7.1活动图,图7-3带同步条的活动图,7.1活动图,4.问题扩展：

泳道从上面的基本活动图中，我们发现活动图有一个主要缺点：

它没有显示出由谁或者什么负责来执行某项活动。

当用活动图对业务过程建模时，它没有显示哪个部门或人负责哪些活动。

当用活动图对对象交互建模时，它没有显示出由哪个对象对哪些活动负责。

如何解决这个问题呢？

解答：

为了给活动图中的活动指明责任者，必须在活动图中放置泳道。

泳道是将图划分为职责域的垂直线。

7.1活动图,在图7-4中，我们看到客户服务人员处理来电咨询活动图被泳道分成了两个职责域，每个域有一个标题，说明在这个域中负责执行活动的对象。

例如，Customer（客户）对象负责“来电咨询”活动，而CustomerService（客户服务人员）则负责“查询客户信息”、“新增客户信息”等活动。

使用泳道可以把整个活动图组织成职责域，增强了活动图的可理解性。

7.1活动图,图7-4使用泳道的客户服务人员处理来电咨询活动图,7.1活动图推荐：

在建立活动图时，最好先给出泳道，然后把活动添加到相应的泳道上。

这是因为如果在创建活动图的最后阶段才使用泳道，会使整个活动图的整理过程变得很困难，相当于重新创建一次活动图，效率极其低下。

活动图的优缺点,

（1）活动图的优点活动图与顺序图和协作图相比，主要有两个优点：

可以对平行行为建模。

活动图因为有显示平行活动的能力，所以很适合为多线程应用和并发应用建模。

可以显示多个用例如何相互关联。

这样，可以使用活动图获得一个系统中构件是如何交互的。

另外，活动图还可以用来优化业务流程。

在业务建模的早期，发现业务流程不合理，及时纠正，以优化业务流程。

活动图的优缺点,

（2）活动图的缺点活动图的主要缺点就是，只有使用泳道，才能清楚地显示出该由哪个对象对哪个活动负责。

但在复杂的活动图上，涉及的泳道很多，使整个活动流程变得很不清晰，影响了人们对活动图的理解。

*,第*页,7.2状态图,1.问题引入状态图描述了一个对象基于事件反应的动态行为，显示了该对象所处的可能状态以及状态之间的转换，并给出了状态变化的起点和终点。

状态图与活动图很相似。

两种图的不同之处主要表现在：

状态图以状态为中心，而活动图则以活动为中心。

状态图通常用来对一个对象生命周期的离散的状态建模，而活动图更适合于对一个流程中的一系列活动建模。

状态图通常用于显示具有复杂行为和经历许多状态之间转换的类。

不必为系统中每个类都建立状态图。

只有当行为的改变和状态有关时才创建状态图。

如何在StarUML中建立状态图？

*,第*页,7.2状态图,2.解答问题以客户服务系统中的“派工单”为例，创建状态图。

“派工单”状态图如图7-5所示。

7.2状态图,图7-5“派工单”状态图,*,第*页,7.2状态图,3.分析问题在图7-5中，“派工单”有五个状态：

新派工单、未分配、已分配未完成、已分配已完成、删除派工单。

当某一事件发生或某个条件满足时，就在这五个状态之间进行转换。

图中还包含了一个开始状态和一个结束状态。

对象的状态图具有以下元素：

*,第*页,7.2状态图,开始状态：

由一个实心圆圈表示。

每个类必须有一个开始状态，并且只能有一个开始状态。

终止状态：

由一个牛眼符号表示。

终止状态是可选的，对象可以有多个终止状态。

状态：

由环绕着状态文本的圆角矩形表示。

一个状态表示一个对象在其生命周期中满足某个条件或等待某个事件发生的一个条件或情形。

每个状态代表了它的行为轨迹。

状态转换：

由带箭头的直线表示。

一个状态转换表示一个对象在源状态将执行某些特定的动作，并当某个特定的事件发生或某些条件满足时，进入目标状态。

状态转换是两个状态之间的关系。

*,第*页,7.2状态图,状态转换是互斥的。

因为对象不能同时转换到多种状态，所以，在状态图中每次只能有一个向外的转换发生。

状态转换的语法格式：

事件（参数列表）警戒条件/动作目标.发送事件（参数）,*,第*页,7.2状态图,图7-5中，“待分配”、“已分配”、“完成”等是状态转换所发生的事件（Event），“客户已确认”则是从状态“已分配未完成”转换到状态“已分配已完成”的警戒条件（GuardCondition），而“客户签字”则是转换的动作（Action）。

每个转换仅允许有一个事件，每个事件只能有一个动作。

7.2状态图,4.问题扩展：

子状态简单状态是指不含子结构的状态。

如图7-5中所有的状态都不含有子结构，因此这些状态都是简单状态。

含有子状态（内嵌状态）的状态被称为组合状态。

在状态图中一个状态可以内嵌任意层的子状态。

子状态通过显示仅在特定环境（封闭状态）内可能存在的某些状态，用以简化复杂的状态图。

7.2状态图子状态是一种包含在超状态中的状态。

图7-6中显示了三个子状态：

未分配、已分配未完成和已分配已完成，它们都内嵌在“处理派工单”超状态中。

在嵌套状态中还可以包含一个开始状态和至少一个终止状态。

7.2状态图,图7-6含有子状态的组合状态图,7.2状态图从整体上看，组合状态图减少了转换数，组织结构更有逻辑性，并且对象生命周期也更容易观察，因此，组合状态图减少了图形的复杂性，更适合用于对更大、更复杂的问题建模。

*,第*页,7.3业务架构,1.问题引入系统架构一般涉及到两个方面的内容，其一是业务架构，其二是软件架构。

人们常常会听到软件架构这个词，对软件架构的概念也有一些了解，但是，也许还有人对业务架构这个词比较陌生，那么，究竟什么是业务架构呢？

*,第*页,7.3业务架构,2.解答问题业务架构描述了业务领域主要的业务模块及其组织结构。

业务架构在先启阶段建立，在精化阶段得以改进。

业务架构的目的是为业务领域建立一个维护和扩展的结构，描述业务的构成。

业务架构对我们理解客户业务，尤其是对软件开发行业确定解决方案起着非常重要的作用。

*,第*页,7.3业务架构,3.分析问题软件开发一直在追求构件化，就像建房子一样来构建系统，用一块一块砌成不同形状的砖头来搭建自己想要的房子。

在很多人看来，构件化开发是技术问题。

即随着技术的发展，各种先进的架构和技术框架能够越来越多地解决复杂的现实问题，总有一天，我们能够利用一个极其灵活和强大的技术架构，将现实中的业务像搭房子一样构建出整个系统。

但是，技术架构仅仅提供了您搭建房子的手段和方法，从可行性上给予您支持，您是否想过您砌成大大小小不同形状的砖头是什么呢？

它们从何而来呢？

7.3业务架构可见，喜欢和迷信技术的我们又忘了一个基本原则：

技术服务于业务。

尽管我们知道怎么样搭建房子，而手中却没有可用的砖头，怎么能建好房子呢？

正所谓巧妇难为无米之炊啊。

软件、技术通通是服务于业务的，技术只是保证做好系统的手段，一个好的软件其根本还在于业务的理解上。

7.3业务架构,SAP是业界著名的ERP软件产品，它之所以能够做到通用，即使在不同行业间实施也只需很小的开发工作量，绝大部分需求都是通过配置来完成的。

不是因为SAP采用了多么先进的技术架构，而是因为SAP把业务做到了极致，它已经砌好了那些可以搭建不同业务平台的各式各样的砖块。

再复杂和迥异的需求，都可以用这些砖块搭建出来。

这些砖块，就是业务架构。

7.3业务架构在项目开发过程中，当我们获得了一份需求时，如果不建立业务架构，那么这份需求对我们来说就是一盘沙子，每次我们都要从头把沙子做成砖块，一点点辛苦地开发程序。

而建立业务架构的工作，就是要把沙子变成各式各样的砖块、部件，从部件做起而不是从沙子做起，像拼图一样，拼出我们的世界来。

7.3业务架构,但这项工作是非常困难的，需要非常精深的行业知识。

并且不是一朝一夕就可行的，必须通过几个甚至几十个项目的累积，才有可能总结出可用的拼图。

在开发项目时，仅将业务架构作为项目中的一项工作，它可能不会对你当前的项目带来什么好处，但是随着每一个项目的积累，不断地修正和丰富业务架构，手中可用的砖块就会越来越多，越来越丰富。

总有一天，你可以用拼图来完成项目中大部分的业务需求，也就是行业解决方案的形成。

7.4业务架构分析,分析工作往往被模糊化，经常的情况是需求弄清楚以后直接进入设计阶段，例如详细的表结构、类方法、属性、页面原型等，然后就进入编码阶段了。

那么分析与设计之间究竟存在什么样的差别呢？

从工作任务上来说，分析做的是需求的计算机概念化；设计做的是计算机概念实例化。

从抽象层次上来说，分析高于实现语言、实现方式；而设计则基于特定的语言和实现方式。

因此分析的抽象层次高于设计的抽象层次。

从角色上来说，分析由系统分析师承担的，而设计则由设计师来承担。

从产出物上来说，分析的典型成果是分析模型和组件模型，设计的成果是设计类、程序包等。

7.4业务架构分析系统分析是在不考虑具体实现语言和实现方式的情况下，将需求在软件架构和框架下进行的计算机模拟。

系统分析的目的是确定系统应当做成什么样的设想，而系统设计的目的是将这些设想转化为可实施的步骤。

如果类比于房屋装修，分析相当于绘制设计图，而设计则相当于绘制施工图。

分析决定哪个地方用哪个物品来装饰，设计决定如何装饰，用什么工具来装饰。

7.4业务架构分析事实上，经过分析之后，已经决定了系统要做成什么样子，已经完成了从需求到系统的转换过程。

至于接下来是用JAVA还是C#，是用J2EE还是.NET，是用两层结构还是用三层结构，是用工厂模式还是用适配器模式就已经不是问题的重点了。

不论采取什么样的实现方式，得到的结果无非是程序运行效率的高低、扩展性、可维护性的差别，无论如何都不会影响系统实现需求这一最基本的要求。

7.4业务架构分析,7.4.1客户服务系统业务架构分析7.4.2客户服务系统子模块划分,*,第*页,7.4.1客户服务系统业务架构分析,1.问题引入上面我们已经了解了分析与设计的区别，接下来将讨论客户服务系统的业务架构分析与实现。

*,第*页,7.4.1客户服务系统业务架构分析,2.解答问题客户服务系统的业务架构如图7-7所示。

7.4.1客户服务系统业务架构分析,图7-7客户服务系统业务架构,*,第*页,7.4.1客户服务系统业务架构分析,3.分析问题对客户服务系统业务架构的分析立足于对需求足够理解的基础之上，我们知道软件开发中最重要的就是抽象，也就是采用OO（面向对象）的思想，这个思想应贯穿于软件开发过程的始终。

需求作为分析过程的输入，需求分析后，产生用例模型和领域模型。

用例模型和领域模型是业务架构的基础。

如果只有用例模型和领域模型而没有业务架构，我们将“只见树木不见森林”。

因为不论是用例模型还是领域模型，它们都只是业务领域的一部分。

如果说用例模型代表了一个软件项目对需求的定义和理解，那么架构就代表了一个软件项目对系统的定义和理解。

架构将系统规划为一些独立的逻辑组件，各负其责，这些组件通过标准的通信接口传递信息。

一个架构就是一个系统的骨架。

7.4.1客户服务系统业务架构分析,通过整理客户服务系统的需求，我们摘录出系统的核心业务如下：

（1）公司客户通过电话完成对软件产品或项目提出使用中的BUG或疑难问题以及投诉建议等内容。

（2）客户服务人员代理公司客户将咨询内容录入到客户服务系统中，以供备案查询。

（3）部门领导负责处理相关客户的投诉建议及故障申报，并视具体情况安排维护人员上门维护及安排客户服务人员进行回访。

（4）维护人员通过查询任务安排，接受相关派工任务，并填写维护报告。

（5）客户服务人员通过查询任务安排，接受相关回访任务，并填写相关回访报告。

（6）系统管理员对系统基础资料进行维护管理。

（7）部门领导可以查询客户服务人员及维护人员的工作完成情况。

由此分析出客户服务系统的核心业务架构，用业务活动图表示如图7-8所示。

7.4.1客户服务系统业务架构分析,图7-8客户服务核心业务活动图,7.4.1客户服务系统业务架构分析,业务架构与核心模型的关系可用图7-9来表示。

用例模型、领域模型所描述的业务过程，通过抽象可得到业务架构。

反过来，业务架构对用例模型和领域模型则有着重要的指导作用。

尤其在业务架构改进的时候，某些用例可能需要重组，领域模型也可能重构。

7.4.1客户服务系统业务架构分析,图7-9业务架构与核心模型的关系,7.4.1客户服务系统业务架构分析,从图7-9可以看出，实际上建立业务架构的活动是一个反复迭代的过程，且非常类似于面向过程的结构化设计，不同的是，在结构化设计方法中，得到的结果是子系统、模块；而在面向对象的设计方法中，得到的结果则是业务组件。

*,第*页,7.4.2客户服务系统子模块划分,1.问题引入了解客户服务系统的业务架构图之后，接下来我们应该做的就是对客户服务系统划分模块。

*,第*页,7.4.2客户服务系统子模块划分,2.解答问题客户服务系统的子模块如图7-10所示。

7.4.2客户服务系统子模块划分,图7-10客户服务系统子模块,7.4.2客户服务系统子模块划分,进一步划分模块，系统管理模块、客户服务业务处理模块、信息查询统计模块分别划分为如图7-11、图7-12、图7-13所示的子模块。

7.4.2客户服务系统子模块划分,图7-11系统管理模块,7.4.2客户服务系统子模块划分,图7-12客户服务业务处理模块,7.4.2客户服务系统子模块划分,图7-13信息查询统计模块,*,第*页,7.4.2客户服务系统子模块划分,3.分析问题

（1）客户服务系统子模块在得到业务架构的基础上，我们对客户服务系统的业务进行细分为以下三个子模块：

系统管理模块。

包括客户基础资料录入修改，客户服务系统用户信息的添加、删除和修改，软件产品的基础资料维护，已上线项目的基础资料维护，FAQ经验库的数据维护以及客户服务系统本身的维护管理等。

客户服务业务处理模块。

包括客户咨询服务处理、故障申报处理、投诉处理，部门领导派工处理，客户服务人员回访处理，维护人员上门处理等。

信息查询统计模块。

包括基础资料查询统计，客户咨询的查询与统计，派工单完成情况，回访报告，维护报告查询统计以及相关报表的查询等。

*,第*页,7.4.2客户服务系统子模块划分,

（2）各子模块的功能系统管理模块客户资料管理客户资料是客户服务系统的根源，只有健全的客户资料体系才能够保证客户服务有序地开展。

主要包括录入客户资料、修改客户资料、删除客户资料和查询客户资料等功能。

系统用户管理包括本系统的所有使用者的信息资料管理及查询。

产品管理包括公司所有发布的软件产品信息的管理及查询。

项目管理包括公司所承担的各种软件研发项目信息的管理及查询。

经验库管理包括经验信息的管理及查询。

7.4.2客户服务系统子模块划分,客户服务业务处理模块。

客户咨询管理包括客户咨询信息的管理及查询。

客户咨询服务活动如图7-14所示。

图7-14客户咨询服务活动图,7.4.2客户服务系统子模块划分,派工管理当有客户投诉及报障时，部门领导会立即对投诉及报障的客户作出快速反应，及时安排派工任务。

对投诉的客户安排客户服务人员及时回访处理；对报障的客户安排维护人员进行上门维护处理。

派工活动图如图7-15所示。

图7-15部门领导派工活动图,7.4.2客户服务系统子模块划分,信息查询统计模块包括查询统计基础资料、客户咨询信息、派工单完成情况等信息，并可打印报表。

*,第*页,7.5软件架构,1.问题引入经过业务架构的分析与建模，我们得到了许多业务构件，要将这些业务构件搭建起来需要了解软件架构的知识。

那么什么是软件架构呢？

*,第*页,7.5软件架构,2.解答问题软件架构是一种思想，一个系统蓝图，是对软件结构组成的规划和职责设定。

一个软件里有处理数据存储的、处理业务逻辑的、处理页面交互的、处理安全的等许多可逻辑划分出来的部分。

传统的软件并不区分这些，将它们全部混合在一段程序里。

软件架构的意义就是要将这些可逻辑划分的部分独立出来，用约定的接口和协议将它们有机地结合在一起，形成职责清晰、结构明朗的软件结构。

*,第*页,7.5软件架构,3.分析问题一个典型的软件架构包括两个视角：

广度视角和深度视角。

这两个视角构成对软件架构的“立体”描述。

广度视角即是我们常说的软件层次结构，它关注软件的分层，规定每一层的职责以及层与层之间的通讯标准。

一般使用包元素来描述。

图7-16展示了一个典型的多层架构的层次模型。

7.5软件架构,图7-16软件层次的广度视角架构图,7.5软件架构,另一方面，软件架构还需要描述深度视角。

所谓深度视角，是指广度视角中每一层的详细说明，它关注每一层以及每个部分的具体实现架构。

例如可以针对业务实体层进行架构描述，图7-17展示了业务实体层的深度视角视图。

7.5软件架构,图7-17软件层次深度视角架构图,7.5软件架构广度视角和深度视角将软件架构立体化了。

层次构成了广度视角维度，而每一个层次的包、类的结构构成了深度视角维度。

*,第*页,7.6软件架构设计,1.问题引入软件架构设计就是要将我们在业务架构中设计出来的业务构件有机地结合在一起协调工作。

那么客户服务系统的软件架构是怎样的呢？

*,第*页,7.6软件架构设计,2.解答问题客户服务系统软件架构层次图如图7-18所示。

每个层次（web层、business层、dao层和jpa层）分别对应一个同名的包，包之间的关系与层之间的关系一致，每个包内类与类之间的依赖关系分别如图7-19、图7-20、图7-21、图7-22所示。

*,第*页,图7-18客户服务系统软件架构层次图,图7-19web包中类结构图,图7-20business包中类结构图,图7-21dao包中类结构图,图7-22jpa包中类结构图,*,第*页,7.6软件架构设计,3.分析问题根据需求，客户服务系统要求是B/S架构的，即浏览器/服务器架构。

该架构有许多优点：

客户端无需安装任何软件，只要有浏览器就可以使用系统，方便客户服务人员、部门领导和维护人员能即时处理客户问题。

当业务架构确定后，至于是选用.NET来实现还是选用JavaEE来实现并不重要，主要依据开发团队的技术素质而定，以期达到最小项目风险和减少开发成本的目的。

本节选用JavaEE来描述客户服务系统的软件架构分层模型，采用了客户端Ajax技术，结合当前使用最成熟的Hibernate框架技术，如图7-23所示。

7.6软件架构设计,图7-23轻量级的Ajax+Hibernate框架图,7.6软件架构设计,客户服务系统分为四个层次，其中表示层采用jQuery、ExtJS，使用客户端Ajax技术，封装Json格式数据，编写简单的业务流程控制层类和Dao封装客户服务业务逻辑处理，DB控制层采用Hibernate框架。

Ajax,Ajax是一种实现RIA的方案。

Ajax是“AsynchronousJavascriptandXML”的简称，即异步的Javascript和XML，是一种在无需重新加载整个网页的情况下，能够更新部分页面的技术。

传统的网页（不使用Ajax），如果需要更新内容，必需重载整个页面，而Ajax通过在后台与服务器进行少量的数据交换，就可以使网页实现异步更新。

传统的Web应用模型和Ajax模型分别如图7-24和7-25所示。

Ajax,图7-24传统web应用模型,图7-25Ajax模型,Hibernate,Hibernate是一个免费的开源Java包，它使得与关系数据库打交道变得十分轻松，它是一个面向Java环境的对象/关系数据库映射工具。

对JDBC进行轻量级的封装，将Java对象与对象关系映射至关系型数据库中的数据表与数据表之间的关系。

对象/关系数据库映射（object/relationalmappin，ORM）这个术语表示一种技术，用来把对象模型表示的对象映射到基于SQL的关系模型数据结构中去。

Hibernate不仅管理Java类到数据库表的映射（包括Java数据类型到SQL数据类型的映射），还提供事务处理、数据查询和获取数据的方法，可以大幅度减少开发时