6.5.3 系统分析
系统分析并不是确定如何解决问题的过程, 而是在寻找系统究竟处理什么的过程。在这一环节中, 需要把那些复杂的需求分解为若干对象及其关系, 并在此基础上提出系统的解决方案。
系统分析分为两部分: 静态分析和动态分析。静态分析部分主要使用分析类图来描述系统要处理的对象和这些对象之间的相互关系, 而动态分析部分主要使用交互图来证明静态分析部分的可行性。
1.静态分析——分析类图
静态分析的主要任务是建立反映对象静态结构的分析类图, 即确定分析类、分析类的属性及分析类的关系。
(1) 确定分析类
对象是面向对象方法中最基本的概念, 是数据和操作的封装体。系统功能是通过对象之间相互通信、不断变化来实现的。因此, 为了更清晰地了解系统的运行过程, 有必要建立对象的分析类图, 从而可以很容易地观察到某一时刻活动的对象以及它们之间的关系。
分析类是从现实世界业务映射出来的, 是对问题域的抽象。因此, 分析模型中所有的分析类都应该只描述对象的高层次的属性和操作。
在分析阶段, 对于分析类来说不会在软件中实现它, 通常只用自然语言去描述其属性和操作。分析类是为定义设计类做准备, 一个分析类可以创建一个或多个设计类。
静态分析的第一步是确定那些备选的、执行用例行为的分析类。这些分析类的实例可以满足用例的所有需求。第3章中已经介绍了3种不同的分析类: 实体类、控制类和边界类。在确定分析类时, 可以使用3种不同的模式来识别和提取这些类。
(2) 分析类的属性
在识别出分析类后, 下一步是识别出类的属性, 继续细化和补充分析模型。
在找到实体类后, 就要研究类的属性。类包括信息和行为, 这些信息就称为属性。可以查阅需求描述和用例描述来获得属性, 事件流中的名词有一些是属性。在标记属性时,要将其赋予适当的类, 属性是与类相关的信息。
标识对象/类属性的规则如下。
①常识性: 按一般常识, 该对象应具有的属性。
②专业性: 在当前问题论域中, 该对象应具有的属性。
③功能性: 根据系统功能的要求, 该对象应具有的属性。
④管理性: 建立该对象是为了保存和管理哪些属性。
⑤操作性: 为了实现对象的操作功能, 需要增设哪些属性。
⑥标志性: 是否需要增设属性来区别对象的不同状态。
⑦外联性: 用什么属性来表示对象的整体—部分联系和实例链接。
(3) 分析类的关系
第3章已经介绍了类之间的关系有关联关系、聚合关系、组合关系、泛化关系、依赖关系。
描述类之间关系的手段是绘制类图。分析阶段绘制的类图称为分析类图, 逻辑上每个用例对应一张完整的分析类图。分析类图可分为两种: 简略的分析类图和详细的分析类图。
简略的分析类图没有描述每个类的属性和操作, 而是突出类之间的关系。某银行系统简略的分析类图如图6-22所示。
图6-22 某银行系统简略的分析类图
详细的分析类图用标准方式描述了类, 在描述类之间的关系的同时, 还展示了每个类的属性和操作。
在用例驱动的开发过程中, 通过分析各个用例及参与者得到类图。在这个过程中需要根据面向对象的原则设计类和关系, 根据用例的细节设计类的属性和操作。
某演出售票系统用例图如图6-23所示。参与者有信息亭(Kjosk), 信用卡服务商(Credit Card Service), 监督员(Supervisor)、接待员(Clerk); 其系统用例图包括4个用例: 买个人票(Buy Tickets), 买套票(Buy Subscription), 信用卡付款(Make Charges),调查销售(Survey Sales)。
图6-23 某演出售票系统用例图
该演出集票系统详细的分析类图如图6-24所示, 只考虑买个人票(Buy Tickets), 买套票(Buy Subscription), 信用卡付款(Make Charges) 3个用例。
图6-24 某演出售票系统详细的分析类图
2.动态分析交互图
静态分析完成后, 下一步的重要工作是检查系统用例的实现问题。用例可以转变为对象之间的协作, 可以跟踪对象之间的消息传递, 从而模拟并检验用例的实现。
顺序图和协作图是专门为用例的实现而设计的, 它们可以记录对象之间传递的消息。同时, 顺序图和协作图都可以记录相同的信息, 但相较而言协作图更适合于用例的实现,因为协作图更多关注的是对象及其链接, 而不是传递消息的顺序, 而且协作图比较容易生成。
(1) 顺序图
绘制顺序图主要从以下5个方面入手。
①识别参与交互的对象。
②确定系统对象的交互过程。
③为每个对象设置生命线, 即确定哪些对象存在于整个交互过程中, 哪些对象在交互过程中被创建和撤销。
④从引发交互过程的初始消息开始, 在生命线之间自顶向下依次画出随后的个别消息。
⑤如果需要表示消息的嵌套或表示时间, 则采用控制焦点; 如果需要说明时间约束,则在消息旁加上说明。
图6-25所示是某售票系统的顺序图, 对象包括信息亭(Kjosk), 售票中心(Box Office), 信用卡服务(Credit Card Service), 顾客在信息亭与售票中心通话触发了这个用例的执行。顺序图中付款具体为: 信息亭发Request(count,performance)消息给售票中心, 表示调用售票中心类的Request(count,performance)操作来查询演出的信息。售票中心发Show Available(seat-list)消息给信息亭, 表示调用信息亭类中的Show Available(seat-list)操作, 给出可用的座位表。信息亭与售票中心还需要一些插卡(Insert Card)、弹卡(Eject Card) 的消息传递。
图6-25 某售票系统的顺序图
(2) 协作图
协作图和顺序图比较类似, 但它不考虑消息的通信时间, 而更关心对象之间的交互(或协作)。因此, 协作图主要是用于描述系统的行为是如何由系统的对象协作完成的。
协作图侧重描述对象、对象间的链接以及链接对象之间如何发送消息。它只对相互之间具有交互作用的对象和对象间的关联建模, 而忽略其他对象和关联。
绘制协作图主要从以下8个方面入手。
①识别参与交互过程的对象。
②确定对象之间的交互过程。
③如果需要, 则为每个对象设置初始特性。
④确定对象之间的链, 以及沿着链的消息。
⑤从引发交互过程的初始消息开始, 将随后的每个消息附到相应的链上。
⑥根据需要表示消息的嵌套。
⑦根据需要说明消息的时间约束。
⑧根据需要为每个消息附上前置条件和后置条件。
售票系统的协作图可自行绘制。
(3) 活动图
UML 提供了一种能够描述用例逻辑流程的工具, 称为活动图, 其可用于对系统的活动过程进行建模。活动图非常类似于业务流程图, 它也是用图形的方式来描述业务的过程、用例的工作步骤、流程的图形。但它也有不同于业务流程图的地方, 即支持对于并行活动的描述。
活动图用来描述一个操作执行过程中所完成的一系列动作, 包括操作的活动、判定点和分支等部分。在UML 动态建模过程中, 活动图能够被附加到任何建模元素上, 以描述其动作行为, 这些元素包括用例、类、接口、组件、节点、合作、操作和方法。
绘制活动图主要从以下5个方面入手。
①识别要对其工作流进行描述的类。
②确定各类的动态行为。
③确定动作流。
④对动作流建模。
⑤对建模结果进行精化和细化。
图6-26所示的活动图描述了某售票系统处理订票订单的用例执行过程。
①执行Set Up Order (建立订单)。
②根据Order 的类型执行不同的分支。Single Order: 执行Assign Seats (分配座位)、Charge Credit Card (信用卡结算); Subscription: 同时执行Assigns Seats、Debit Account(借记账号结算) 或Award Bonus (优惠); Single Order 与Subscription 两步可同时进行。
③最后Mail Packet (邮包)。
图6-27为一个按活动职责(带泳道) 组织的处理订单用例的活动图(模型中的活动按职责组织)。活动被按职责分配到用垂直实线分开的不同区域(泳道): Customer (顾客), Sales (销售), Stockroom (仓库)。
图6-26 某售票系统活动图
①顾客要求服务, Sales 负责接收订单, 并提交到Stockroom。
②Stockroom 处理订单, 与此同时, Customer 付款, 并由Sales 处Deliver Order 至Customer。
图6-27 某售票系统带泳道的活动图