6.3.2基于UML的需求分析

在初步的业务需求描述已经形成的前提下，基于UML的需求分析过程（见图6-18） 大致可分为以下步骤。

利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象，形成用例；确定执行者与用例、用例与用例图之间的关系， 生成用例图。

图6-18需求分析过程

利用包图及类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描 述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取"关键概 念"'形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的 关系，生成类图。

上述两个步骤并没有时序关系，它们可以并行展开。

1.生成用例

从外部用户的视角看，一个用例是执行者（actor）与目标软件系统之间的一次典型 的交互作用。从软件系统内部的视角出发，一个用例代表系统执行的一系列动作，动作 执行的结果能够被外部的执行者所察觉。执行者是指外部用户或外部实体在系统中扮演 的角色。如果多个用户在使用目标软件系统时扮演同一角色，这些用户将由单一执行者 表示。反之，如果一个用户扮演多种角色，则需要用多个执行者来表示同一用户。

对用例的完整描述包括用例名称、参与执行者、前置条件、一个主事件流、零到多 个辅事件流和后置条件。主事件流表示正常情况下执行者与系统之间的信息交互及动作 序列，辅事件流则表示特殊情况或异常情况下的信息交互及动作序列。显式地分隔主、 辅事件流是为了使分析人员首先聚焦于正常的业务处理流程，同时也便于用例的读者理 解业务需求。

用例主要来源于分析人员对场景的分类和抽象，即将相似的场景进行归并，使一个 用例可以通过实例化和参数调节而涵盖多个场景。

例如，在"家庭保安系统"中，执行者有"用户"、"传感器"、"替报器"、"报瞥电话"和"显示器",用例有"系统配置"、"命令响应"和"传感器监测".下面以"传感 器监测"为例说明用例的一般描述格式。

用例名称：传感器监测。

参与执行者：各类传感器、替报器、报警电话和显示器。

前置条件：系统巳开机。

主事件流：

①传感器向目标软件系统上报其监测数据，系统判别监测数据是否正常。

②如果不正常，系统启动瞥报器，拨报替电话号码。

③报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的 性质》

④系统在控制面板的显示器上显示报瞥时间及当前状态（报替）。

辅事件流：

①如果报警电话无人接听，则按照重拨延迟反复拨号，直至电话接通，再转入主事 件流的步骤③。

②如果重拨次数达到系统预设的最大次数，电话仍无人接听，则跳过主事件流的步 骤③，转入步骤④。

后置条件：如果己发现异常的监测数据，系统处于"报瞥"状态；否则，系统处于 正常的"监测"状态。

2.用活动图表示用例

针对前面所述的"传感器监测"用例，其活动图表示如图6-19所示。

3.生成用例图

执行者与用例之间的关系有两种：触发执行与信息交换。执行者与用例之间可能 兼具这两种关系，例如，在"家庭保安系统"中，执行者"用户"在触发用例"命令响 应"的同时，还要向用例传送命令信息。

在UML用例图中，从执行者指向用例的边表示触发执行和/或信息交换，从用例指向执行者的边则表示用例将其生成的信息传递给执行者。例如图6-19中的"传感器监 测"用例仅包含正常的处理流程，而"报警电话未接通"用例除正常流程外还增加了 "重 复拨号"以及"重拨次数达到最大次数仍无人接听"这两种异常处理动作。 

顶层架构的主要目的是为后续的分析和设计活动建立一种结构和分划，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。 顶层架构是分析和设计的阶段成果的承载体。随着开发过程的推进，框架中的内容不断 丰富、翔实，最终演进为完整的面向对象软件结构。

图6-19 活动图

1）UML包图

包是UML对类进行分组的一种机制。可以从某种视角将具有比较密切的关联的一 些类划分为一个包，分属于不同包的两个类之间的关联则比较松散。由此可见，对于大 型软件系统而言，包的划分是实现"分而治之"的重要技术手段。

包之间存在两种依赖关系：依赖和构成。如果对类A的修改将导致类B的改变，则 称B依赖于A.如果两个包中存在具有依赖关系的两个类，则认为这两个类分属的包之 间存在依赖关系。

2）顶层架构设计

软件系统顶层架构的基本方法是，结合实际需求，从既往的架构设计经验模式中选

取适当者，再进行微调或局部改造。目前有如下几种主要的架构模式：

流程处理模式。流程处理系统以算法和数据结构为中心，其系统功能由一系列 的处理步骤构成，相邻的处理步骤之间以数据流通管道相互连接。

客户/服务器模式。客户端负责用户输入和处理结果的呈现，服务器端则负责后 台的业务逻辑处理。

模型--视图--控制器（Model、View、Controller, MVC）模式。该模式将整 个软件系统划分为模型、视图和控制器三个部分。模型负责维护并保存具有持久 性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知视图；视 图负责呈现模型中包含的业务数据，响应模型变化通知，更新呈现形式，并向控 制器传递用户的界面动作；控制器负责将用户的界面动作映射为模型中的业务处 理功能并实际调用之，然后根据模型返回的业务处理结果选择新的视图。MVC 模式特别适合于分布式应用软件，尤其是Web应用系统。

分层模式。分层模式将整个软件系统分为若干层次，最顶层直接面向用户提供软 件系统的操作界面，其余各层为紧邻其上的层次提供服务。分层模式可以有效地 降低软件系统的耦合度，因此其应用十分普遍。

事实上，大型软件的顶层架构往往需要复合使用多种架构样式。例如，整个目标软 件系统采用分层结构I在系统的不同层次内再分别使用适宜的其他种类的架构模式。

在确立顶层架构的过程中需综合考虑以下因素：

架构中包的数量。原则上，如果母个包中包含的软件元素（例如类）的数量过多， 应考虑将其进一步细分；如果过少，则说明架构过早地陷入了细节，架构划分返 工的可能性致大，同时也不合理地限制了后续分析和设计活动的自由空间。

架构中包之间的耦合度。包之间的依赖关系和连接关系应尽量简单、稀疏。

软件系统的稳定性。要尽量抽取不稳定的软件元素之中相对稳定的部分，将不稳引起的软件元素分类聚集于少数几个包中，以提高软件系统的可维护性。

软件系统的必然性。可以将可选功能和必须实现的功能分置于架构中不同的包或子包之中。

作为软件系统运行环境的物理网络拓扑。根据软件元素在分布环境中的部署情 况。区分顶层架构中的包，可以使包之间的消息传递与物理节点之间的通信相吻 合，使后续的分析和设计活动受益于顶层架构中明确定义的通信关系。

软件元素的安全、保密级别。根据安全访问的权限划分顶层架构中的包或者子包。

开发团队的技术专长。根据开发人员在问题领域和软件技术领域不同的专长划分 顶层架构中的包，使每个包都能分配给最适合的开发人员进行后续的分析、设计、 编码和测试等，从而有利于并行开发。

5.建立概念模型

例如，"家庭保安系统"的领域概念模型如图6-20所示。

图6-20 "家庭保安系统"的领域概念模型