1
第 8章 面向对象分析
领域分析
使用实例的需求获取
用类进行建模
对象 -行为模型
RUP分析活动
OO分析小结
2
8.1 领域分析
1、领域分析的概念面向对象的系统分析可以发生在许多不同的抽象层次。
在业务或企业级层次，可定义模拟整个业务的类、对象、
关系和行为。在业务域层次，可定义描述某特殊的业务域的工作的对象模型和行为模型；在应用层次，建模着重于特定的用户需求。
Firesmith对软件领域分析的定义是：领域分析
(Domain Analysis)指特定应用领域中公共需求的标识、分析和规约，即发现或创建那些可广泛应用的类，其 目的 使它们 在应用域中多个项目间能被复用 。领域分析的角色是设计和建造可复用构件（类似于制造环境中工具制造者的角色），它们被很多相似但不一定是相同的应用开发的人所使用。
3
Lethbridge的定义是：领域分析是软件工程师 了解背景信息的过程 。为了理解问题并在需求分析和软件工程过程的其他阶段作出合理的决策，软件工程师必须了解使用该类软件的一般性商业和技术领域中足够的信息。
2、领域分析过程的活动
（ 1） 定义将被调查的领域分离感兴趣的业务域、系统类型或产品范畴，抽取 OO和非 OO的“项”。 OO项包括：现存 OO应用的类的规约、设计和代码，支持类（如 GUI类或数据库访问类），和领域相关的构件库以及测试案例。非
OO项包括：政策、规程、计划、标准，非 OO应用文档和构件。
4
（ 2）对从领域中抽取出来的项进行分类并建立分类层次。
（ 3）收集领域中应用的代表性样本。
（ 4）分析样本中的每个应用
标识候选的每个可复用对象。
指明对象被标识为可复用的理由。
定义对象的适应性。
估算在领域中复用这些对象的应用的百分率。
使用配置管理技术控制这些对象。
（ 5）为对象开发分析模型。
5
3、领域分析的价值领域分析除了为软件复用奠定基础外，还为较低抽象层次的一般的面向对象分析带来如下好处：
快速开发。有助于集中精力关注最重要的问题，更有效地与相关人员进行交流，可以更快的确定需求。
优化系统。了解领域的细节有助于保证所采纳的解决方案更有效地解决用户的问题。会少犯错误，知道应该遵循那些规程和标准。领域分析给出一个应用领域的总体视图，会引导出更好的抽象从而改进设计。
有了领域知识，就可以洞察新兴趋势及进一步开发的机会，有助于创建适应性更强的系统。
了解通用性和特殊性，有助于创建出具有更好的可重用性和更宽的销售市场的软件。
6
专家提出，没有坚实的领域分析，任何重大的软件项目都不应该进行。对应用领域的深入理解能极大的提高成功的几率。许多非常成功的软件产品的开发人员以前都在业务领域工作过－段时间，对实际需要有着深切的感受。
一旦对领域有了真正的理解，就可进行某一个项目（或产品）的需求分析，包括定义待解决的问题以及开发什么软件来解决它。然而，领域分析永远也不应该结束：开发人员有责任在开发过程中不断增进他们的理解，后续版本的系统扩充通常需要对子领域进行进一步的领域分析。
7
8.2 使用实例的需求获取面向对象的分析过程并不从考虑对象开始，而是从对系统将被使用的方式的理解开始。如果系统是人机交互的，
则考虑被人使用的方式；如果系统是涉及过程控制的，则考虑被机器使用的方式；如果系统是协调和控制应用的，
则考虑被其他系统使用的方式。一旦使用的场景 (scenario)
被定义，软件的建模活动就开始了。
1,use-case（用例或使用实例）
在 OOA中，用例是分析模型的第一个元素的基础，
以终端用户的观点对系统建模。
用例在需求获取时创建，应达到下列 目标,
通过定义由终端用户和开发人员共同认可的使用场景，定义系统的功能和运行需求。
场景是用例的一个实例，表达用例的一个特定发生，
在特定的时间，使用特定的数据进行操作 。
8
提供清楚的、无二义性的终端用户和系统如何相互交互的描述。
提供确认测试的基础。
用例的描述以及用例图构成了参与者与系统交互的用例模型
（ 1）用例的描述建议：其中只有名称和步骤是必须的。
名称 (name)
参与者 (actor)
目标 (goal),参与者要完成的任务。
前置条件 (precondition),列出参与者启动用例前所有必需为真的条件。
相关用例 (related use cases),列出可能是此用例的扩展、包含的用例。
9
步骤 (step),用两列的格式描述用例的每一步（见例）。
后置条件 (postcondition),用例完成后系统所处的状态。
例 1：描述应用程序中打开文件的用例用例,打开文件步骤,
参与者动作 系统响应
① 选择“打开?” 命令 ② 显示“打开文件”对话框
③ 指定文件名
④ 确认选择 ⑤ 关闭对话框
10
例 2、图书管理系统借书 用例用例,为借阅者借出一本书参与者,借书员目标,帮助借阅者借阅书籍并确保输出正确的借出记录前置条件,借阅者必须有一张有效的借书卡并且没有欠费；
该书藉必须具有有效的条形码并且不是来自于参考文献区。
步骤,
参与者动作 系统响应
① 扫描书籍和借书卡 ② 显示允许借阅的信息
③ 在书籍上标记到期日期
④ 确认借出开始 ⑤ 显示借出已被记录的确认的信息后置条件,系统有一个该书藉被借出以及到期时间的记录
11
例 3、某商店 POS系统 用例描述实例用例,购买商品参与者：顾客（发起者）、收款员类型,主要的描述,顾客带着所要购买商品到付款处，收款员记录商品信息并收款。
用例,启动 /关闭系统参与者：管理员类型,主要的描述,管理员接通一台 POS机电源，检查时间、日期正确性，检查完成后，系统处于就绪 状态，以备收款员使用。
12
（ 2）用例图用来显示一系列用例和参与者之间的关系，有助于开发人员表达系统功能的不同的抽象层次的描述。
交互房主传感器配置监测
SafeHome高层用例图
13
启动 /关闭系统房主输入密码询问区域状态
SafeHome交互用例图询问传感器状态按紧急按钮验证密码询问传感器
,include》
,include》
,include》
(参考教材 1 P415)
14
用例分析是理解和组织系统应完成任务的直观方法。它还可以用来 驱动开发过程 。特别是，用例：
可以帮助定义系统的范围，即必须做什么和不必做什么。
可用来计划开发过程。确定的用例数量决定了项目的大小，开发进度可用完成的用例数量来测量。
用来开发和确认需求。
构成测试用例定义的基础。
可用来构造用户手册。
但是用例也不是万能的！注意：（ Lethbridge的观点）
① 用例必须经确认。用例集应是完全的、表达是一致的和明确的。
② 用例分析不一定覆盖到功能需求的所有方面。如，不被参与者触发的活动不会出现在用例中。
③ 当软件需求来自用例时，软件往往只是简单的反映开发软件前用户的工作方式，可能没有考虑到创新的解决方案。
15
2、获取需求的主要活动
（ 1）确定参与者和用例与用户一起确定与系统有交互活动的所有角色，并为每个角色设计用例。确定用例的准则：
每个用例都应该为其角色提供有价值的服务 —— 避免确定的用例太小；确保每个用例都向主要角色提供有价值的服务 —— 避免用例太大。
（ 2）定义用例的优先级
（ 3）描述每个用例用例描述可有不同的抽象层次与描述模板。概要描述主要强调每个用例的主要功能。详细描述包括每个用例的事件流（如何开始，与角色如何交互，如何终止）、
每个用例中所涉及到的对象（编入术语表）、执行一个用例所要求的非功能性需求等。
16
（ 4）建立用例图用例图用来显示一系列用例和参与者之间的关系。
它有助于表达系统功能的高层表述。
用例有特化、扩展和包含关系。特化的使用同类图。一个特化用例代表了几个相似用例，一个或多个特化提供了这些相似用例的细节。
使用包含关系减少用例之间的冗余。即 确定用例中可以被共享的功能。检查每个用例抽取出公共部分创建单独用例。
使用扩展关系区分事件的例外和事件的共有流程，
即确定补充功能或可选功能。如果发现一个用例比较复杂，既包含了一般处理又包含了特殊处理，将特殊处理的部分抽取出来，创建单独的用例。
17
打开文件用户通过键入文件名打开文件通过浏览打开文件试图打开不存在的文件 浏览文件
,extend》,include》
用例的特化、扩展和包含
18
（ 5）建立用户界面原型在面向对象的软件开发中，用例模型和用户界面设计息息相关。用例模型创建后，就可确定参与者如何驱动用例，以及用例以什么形式向参与者提供信息。因此可开始用户界面原型化的迭代过程，和构造系统的其他部分并行进行。
19
8.3 用类进行建模面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。在需求获取阶段已经建立了用例模型等阶段产品，但都是为了容易沟通信息，以用户语言描述的，存在着模糊、冗余、二义性、不一致性等问题。
系统分析阶段要进一步分析、完善前一阶段获取的需求，细化用例模型中的用例、确定系统中的对象、对象的静态和动态特征、对象间的关系及对象的行为约束，
建立满足用户需求的、精确的、稳定的、易于维护的、
便于后续设计的分析模型。
20
用例图：视图 功能模型：模型分析模型：模型类图：视图 对象模型：模型顺序图：视图状态图：视图活动图：视图动态模型：模型分析模型的构成
21
几条通用的分析原则：
（ 1）组装与分解相结合的原则基本对象可组装成复杂对象，对复杂对象进行分解从而完成系统模型的细化。
（ 2）抽象化与具体化相结合的原则数据抽象将数据及作用在其上的操作抽象成对象。
过程抽象为对象的相互作用提供了依据。
抽象强调对象的本质和内在属性，忽视与问题无关的属性。而具体化指在细化过程中，描述对象的某些特性，
加强系统模型的稳定性。
抽象化与具体化相结合可以使具体对象直接从抽象对象的定义中获得已有特性，而不必重复定义它们。
22
（ 3）封装原则将对象的各种独立的外部特性与内部实现细节分开。
对象接口定义要尽可能的与其内部工作状态相分离。封装有助于减少由于需求的改变而对整个系统所造成的影响。
（ 4）相关性原则在分析中要考虑对象间的各种关联，包括静态结构的关联、动态特征的关联。这些关联是对象协作的基础。
（ 5）行为约束的原则通过语义特征来刻画。表示了对象合法存在、对象合法操作应满足的条件，有助于深刻理解对象和系统。
23
一旦建立了系统的用例模型，则可以开始标识候选类，并指明它们的责任和协作。 Wirfs-Brock等人提出了一 种 类 -责任 -协作者 (Class-responsibility-
collaborator,CRC)开发类图的卡片技术。该技术使用实际的或虚拟的索引卡片（参考教材 P417)，为定义类提供较多的信息。其中 责任 是与该类相关的 属性和操作,协作者是为一个类提供要完成的责任所需要的信息的那些类。通常，协作意味着对信息的请求或者对某种操作的请求。
在确定属性和操作时，可把它们列在卡片上。由于卡片的空间有限，使得每一个类都不能太复杂。如果不能在一张卡片上列出所有的职责，该类应分成两个相关的类。可在白板上自由移动卡片以组成类图，在卡片之间画线表示关联与泛化。低科技的卡片技术可能比操作软件用户界面要快，对开发人员通过会议讨论确定方案很有效。
24
1、标识类及对象无论是面向对象分析还是面向对象设计与实现，建立类图都是核心技术。类图是定义其他图的基础，在该基础上用交互图、状态图等进一步描述系统其他方面的特性。
如何识别对象？对象以一系列不同形式展示自身：
外部实体、事物、发生的事件、角色、组织单位、位置或结构。一种最简单的方法是从系统处理说明中找出名词。例如，在 SafeHome的需求陈述中，找出相关的名词是：用户、传感器,控制面板、系统 (安全系统 )、
传感器编号,传感器类型、密码,电话号码,传感器事件,警报器 等。
这些候选的对象是否都可作为在系统中承担责任的有用对象？要根据一定原则筛选。见下表：
25
几条筛选特征,例,SafeHome中潜在的对象及筛选理由
(1)保留的信息 潜在对象 选取理由 筛选理由
(2)需要的服务 用户 角色或外部实体 不符合 1/2
(3)多个属性 传感器 外部实体 符合 1-6
(4)公共属性 控制面板 外部实体 符合 1-6
(5)公共操作 系统 (安全系统 ) 事物或聚集对象 符合 1-6
(6)基本的需求 传感器编号 事物或概念实体 不符合 3
传感器类型 事物或概念实体 不符合 3
密码 事物或概念实体 不符合 3
电话号码 事物或概念实体 不符合 3
传感器事件 事件 符合 1-6
警报器 外部实体 符合 1-6
几乎满足所有特征的对象才会被考虑为分析模型中的合法对象,
26
在 RUP中，将对象分为三种类型：
(1) 边界对象 (或边界类 )
是参与者与系统交互的接口，这些对象位于系统与外部世界的边界上，代表如界面窗口、通信接口、打印机接口、传感器等的抽象，用于阐明和收集系统的边界需求，
这样，可把用户界面或通信接口的变化隔离在一个或多个边界类中。在分析问题域时，边界类仍保持较高的概念层次，说明通过交互所实现的目标就可以了。在设计活动中
（如用户界面设计）才根据参与者操作需求，添加具体的边界对象。
(2) 控制对象 (或控制类 )
控制用例的流程，表示协调、顺序、事务处理以及对其他对象的控制（如分派任务给其他对象）。主要用来体现应用程序的执行逻辑，可以使得变化不影响用户界面和数据库中的表。
27
(3) 实体对象 (或实体类 )
负责保存长效且持久的信息。实体类大多数是直接从业务模型或 领域模型中相应实体类得到的。实体类一般表示为一种逻辑数据结构（通常映射为数据表格或文件），有助于开发人员理解系统所依赖的信息。
实体对象不一定都是被动的，有时可能具有与它所表示的信息有关的复杂行为。实体对象能够将变化与它们所表示的信息隔离开。
在 RUP的分析中，三类对象分别用下图表示：
边界对象 控制对象 实体对象
28
2、定义属性类的属性与操作和该类在系统中承担的责任有关。属性表示了类的特性，即类必须保持的以完成软件目标的信息。属性的取值决定了对象可能的状态。
传感器有类型、编号、位置、颜色、重量、工作状态
（关闭、待机、监控）、采样频率、报警阈值等特性，哪些与系统责任有关呢？
定义属性的一些经验：
一般常识；
分析问题域，检查与对象相联系的形容词或名词短语；
责任；
保存管理信息；
有些属性在对象模型稳定之前可暂不考虑。
29
3、定义操作操作反映对象的行为并以某种方式修改对象的属性。
对象行为可理解为对象应展现的外部服务的总和。对象的行为分为三类：
对象生命周期中的创建、维护、删除行为。
计算行为
监控行为通过这些行为体现对象的责任。对象以两种方式完成它们的责任：
使用它自己的操作去操作自己的属性，
对象和其他对象协作。
因此对象的操作可以有以下 几种类型,
① 实现功能的操作：可追溯到用户需求。
30
② 管理对象创建和删除的操作。在分析阶段，这些操作可暂缓定义。
③ 访问属性的操作。一个类的属性通常是私有的或受保护的，只有通过该类提供的操作来访问。
④ 辅助一个类完成其任务的操作，即协作操作。
如何定义操作呢？
分析问题域：有哪些行为，找有关动词。
如“传感器被赋予一个编号和类型”。
系统的责任：找与责任有关的对象，这些对象为承担责任应提供哪些服务。
分析类的状态转换，引起类状态转换的动作。
追踪一个用例的执行路线，如顺序图，通过对象间通信发现操作。
因此类的有些操作是在对象 -行为模型建立后才补充进来。
下图是传感器类的较为详细的定义及它的 STD：
31
传感器类类型；
编号；
位置；
工作状态；
采样频率；
警报阈值；
初始化；
关闭；
监视；
待机；
显示；
振铃；
拨号；
关闭状态待机状态监视状态初始化命令关闭命令监视命令待机命令关闭命令超越阈值 /激活显示、振铃、拨号传感器类的 STD
…
…
32
4、定义结构与层次类图中的类并非孤立存在，类之间有很多关系。应该关注类模型的结构以及类和子类出现时产生的类层次。
寻找关系的具体方法如下：
检查交互图，如果一个类向另一个类有请求，则它们之间通常有关联关系。
检查类的聚合关系。
检查类的泛化关系，寻找相似对象的不同点，抽取不同的部分定义为特殊类（自顶向下），或将共性的部分提升为基类（自底向上）。
检查其他类，发现不同类中的共同点，将共同的部分定义一个新类。其他类和新类之间的关系也是泛化关系。
但关系太多的类往往对其他类有更多的要求，较难复用且维护的工作量也很大，一旦其他类发生变化，则对该类产生影响。
33
（ 1）关联关系是类之间的连接关系，可以是双向的也可以是单向的。
两个关联之间可以相互发送消息。
订单类的属性放入客户类中，可以找到客户的订单；
而客户类的属性放入订单类中，可以找到订单的客户。
在一对多或多对多的关联中，从重数为 1的对象中找到它所对应的类的对象通常是比较困难的。解决的办法是在关联中加入限定，它可以唯一地识别重数为“多”
端的对象，以便快速定位到要查找的对象。
订单 客户* 属于 1拥有订单 订单号 客户属于
34
system sensor
alarm sensor event
1 检测 *
1
0..*
识别1
*
激活
SafeHome中几个对象类的关联
（参考教材 1P423)
35
（ 2）聚合关系表示类之间整体与部分的关系。 标识类的聚合的优越性：
清晰的表达语义并用重数约束之间的关系。
简化对象的定义。
支持复用。如“发动机类”可以是一个可复用构件，用于其他系统定义中。
飞机内嵌发动机和导航仪的属性内嵌发动机和导航仪的操作
…
…
飞机发动机 导航仪
36
身份人员会计师身份经理身份稳定部分 可变部分在强聚合关系中，部分依赖于整体，如果整体不存在了，部分会随之消失。实现时一同删除。聚合关系使得类具有了层次结构。
能表示动态变化的对象特征。不需要经常变化的属性与操作放在整体类，需要动态变化的特征放在部分类。
37
（ 3）泛化关系是一般与特殊关系。将具有共同特性的元素抽象成一般类，通过增加其内涵生成特殊类。
通常，符合下属条件之一类的泛化才有存在的价值：
便于实现软件重用。
一般类有两个或两个以上的特殊类。（消除冗余）
需要用它们创建对象实例。
但要避免过渡泛化，否则会增加系统的复杂性。
泛化关系使得类具有了层次结构。下图是 SafeHome
的部分类图。
38
system
control
panel
sensor alarm
entry
sensor
smoke
sensor
motion
sensor
SafeHome的部分类图
39
（ 4）包复杂系统的分析模型可能有数十个结构、上百个类，
难以理解与实现。当所有类的某个子集相互协作以完成一组内聚的责任（功能）时，划分为子系统（ UML称为包）。
包确定了整个系统抽象粒度更大的结构。包图可产生于类图之后（将类图组合成包），或将用例的功能分派给包，再细化包以产生类图。
如参考教材 1P421中将“控制面板类”的整个聚合结构划分成“控制面板包”。下图是某一教学管理系统的包图及包图的细化：
40
MFC类 用户接口出错处理 教学管理 数据库教学管理系统的包图
41
,subsystem》
课程注册子系统系统与子系统包图
,subsystem》
成绩管理子系统
,system》
教学管理系统
42
选课管理成绩管理 人事信息教学管理课程 学生登记课程登记开设课程选课统计学生成绩登记成绩统计学生教师身份验证
43
8.4 对象 -行为模型用例中的每个用例都是通过若干对象相互合作实现的。对象 -行为模型指明一个系统对外部事件的激励所作出的响应。为创建该模型，应该完成以下工作：
评估所有 use-case以完全理解系统中的交互顺序。
标识驱动交互序列的事件并理解这些事件如何和特定的对象相关联。
为每个 use-case创建交互图。
为具有主要动态特征的类建立状态转换图。
为描述对象的工作流同时便于识别并发活动建立相应的活动图。
评价对象 -行为模型以验证精确性和一致性。
44
1、通过 use-case识别事件，为对象的交互行为建模事件是某个时刻发生的事，包括所有来自或发往用户的信息、外部设备的信号、输入、策略、中断、转换和动作。当系统与参与者（人、设备或外部系统 )交换信息时则一个事件发生。为了方便分析对象对外部事件的响应，有必要建立交互图（协作图、顺序图），用于显示一个用例实现中涉及到的对象和这些对象间的消息传递情况。
（ 1）顺序图下面通过 SafeHome的用例说明，识别出事件，找出与该事件相关的对象，并将用例的责任分派给它们，通过它们的交互，体现了系统完成一个用例的整体行为。
45
检查 SafeHome的 use-case，带下划线的部分指明了事件。
（参考教材 1P424)
① 房主观察控制面板 以确定是否系统以准备好接收输入。
如果 系统未准备好,房主必须物理地关闭门 /窗户，以便 使
,准备好,指示灯亮 。
② 房主使用键盘输入 4位密码,系统 将密码与存储在配置库中的有效密码比较,如果密码不正确，控制面板 鸣叫一次并复位 等待再次输入。如果密码正确，控制面板等待进一步的动作。
③ 房主 选择键入,stay”（仅激活外部的传感器） 或
,away”（激活所有的传感器）以启动系统。
④ 当处于激活状态时,房主可观察到一个红色指示灯 。
46
一旦所有事件被标识，将它门分配给所涉及的对象。
对象可以生成事件（如房主生成密码输入事件）或识别发生在其他地方的事件（如控制面板识别密码比较事件的二进制结果）。
下图是 SafeHome的部分顺序图：
房主 控制面板 系统输入密码 密码比较密码正确 /不正确
[不正确 ]启动蜂鸣器蜂鸣器声响等待下一个动作
47
房主 控制面板 系统选择 stay/away 激活传感器传感器被激活请求指示灯亮红灯亮等待下一个动作
Rumbaugh等人在 OMT方法中提出，建立反映系统交互行为的动态模型时，需描述正常交互的脚本和例外的脚本。脚本也称为场景，是用例的一个实例。通过脚本中的步骤确定事件，比较方便的建立顺序图、协作图等视图。
48
如 ATM系统示意图：
分行计算机分理处计算机分理处计算机帐户帐户
ATM
ATM
自动出纳机与用户交互的正常脚本：
（ 1） ATM请求用户插入卡：用户插入现金卡。
（ 2） ATM接受卡片并读出它的卡号。
（ 3） ATM要求密码：用户输入密码 401230。
（ 4） ATM请求分行确认卡号和密码：由分理处检验并通知 ATM。
（ 5） ATM要求用户选择事务类型：用户选择取款。
49
（ 6） ATM要求输入现金数量：用户输入 $200。
（ 7） ATM请求分行处理事务，分行把请求传给分理处，
确认事务成功。
（ 8） ATM分发现金并要求用户取现金：用户取现金。
（ 9） ATM提示用户是否要继续：用户键入不继续。
（ 10） ATM打印收据，退出卡，并提示用户取走它们：
用户取走收据和卡。
（ 11） ATM请求用户插入卡。（回到初始状态）
还可列出用户与自动取款机交互的例外的脚本。
通过脚本，比较容易确定用例（如取款用例）中的事件（交互信息）、以及事件的发送者和接收者（完成该用例所涉及到的对象）。
50
（ 2）协作图用于快速浏览对象间的相互合作。强调对象间的通信，
不像顺序图那样强调传递消息间的时序性，它用数字顺序标号表示消息的顺序。
（ 3）活动图用来描述对象或构件执行的工作流。突出的优点：用来表示并发活动及活动的执行者。
在分析阶段，活动图用来描述满足用例要求所要进行的活动及之间的约束关系。（有些专家认为用活动图建立用户业务模型比对象模型更易理解）。
在设计阶段，活动图可以反映对象内部的工作流程，
可由状态图演化过去，是状态图的一个实例。
51
2、为单个对象类的重要行为建模
Pressman提出，在 OO系统的语境内，必须考虑两种不同的状态特征,
（ 1）当系统完成其功能时每个对象的状态；
（ 2）当系统完成其功能时从外界观察到的系统状态，
即系统的整体行为。
类的状态图反映了该类中每个对象内部的工作，在它的生命周期内遇到某个事件或动作使它从一种状态转换到另一种状态。通过状态图关注对象类应负有的责任，
防止遗漏一些功能，帮助标识对象类的操作，因此需要对有重要行为的对象类建立状态图。
状态图还能为对象设计中建立每个操作体的内部逻辑提供帮助。
52
例如,SafeHome系统中的传感器类是比较重要的类，观察它的状态特征 (详见 3.4例 2）对了解整个系统的动态行为很有帮助。
ATM系统中，自动取款机的行为特征比较重要。
下图是自动取款机类在正常取款行为下的状态转换图。
53
开始
do:请求插入卡检查
do:要求密码核对
do:确认帐户选择
do:要求类型输数据
do:要求数量事务
do:处理事务发现金
do:分发现金继续否
do:询问继续否结束
do:打印收据退卡
do:请求取卡插入卡 输入密码密码错帐户正确输入类型输入数量事务成功取现金继续终止打印指令发出取走卡
ATM类的部分 STD
54
范例：移动电话系统功能：
用手机做移动通讯下载铃声下载图片管理电话簿。
55
Talk to Others
Download Picture
Manage Phonebook
Download RingsMobile user Mobile Network
56
定义移动电话系统的对象（简化）
手机包括的对象：
手机屏幕手机按钮手机（屏幕、按钮以外的部件）
其它对象：
基站
MButton
MDisplqy
MmobileStation
MmobileHandset
移动电话系统的类图
57
移动电话系统对象间的通信
:MButton,MDisplqy
:MMobileStation
:MMobileHandset
Mobile user
1:pushDigButton()
3:pushSendButton() 2:displayButtonNumber()
4:connectStation()
6:connectSuccess ()5:createConnection()
移动电话系统的协作图
7:displayConnectSuccess()
58
移动电话系统的顺序图
:MButton,MDisplqy
Mobile user
pushSendButton()
displayButtonNumber()
displayConnectSuccess() connectSuccess ()
createConnection()
pushDigButton()
connectStation()
:MMobileStation,MMobileHandset
59
MButton
MDisplqy
MmobileStation
MmobileHandset
pushDigButton()
pushSendButton()
pushDisconnectButton()
createConnection()
cancelConnection ()
responseError()
displayError()
displayButtonNumber()
displayConnectSuccess()
displayIncomingCall()
connectStation()
disconnectStation()
connectSuccess ()
Disconnectsuccess()
移动电话系统的类图之二 （接口）
60
8.5 RUP的分析活动在统一过程中，用工作流来描述过程。工作人员执行工作流中的一组活动而产生相应的工作产品。
有 7种过程工作流，它们是业务建模、需求、分析、设计、实现、测试和实施。其中需求、分析、设计、实现和测试是核心工作流。
需求工作流：列举出候选需求，捕获功能性需求，
捕获非功能性需求。
分析工作流：构架分析，分析用例，分析类，分析包。
设计工作流：构架设计，设计一个用例，设计一个类，
设计一个子系统。
实现工作流：构架实现，系统集成，实现一个子系统，
实现一个类，执行单元测试。
测试工作流：制定测试计划，设计测试，实现测试，
执行集成测试，执行系统测试，评估测试。
实施工作流：可交付系统的配置。
61
分析工作流的任务是通过精化和组织需求捕获阶段所描述的需求来对其进行分析，工作结果是分析模型。下表列出了用例模型和分析模型的简单比较：
用例模型 分析模型使用用户的语言进行描述； 使用开发人员的语言进行描述；
系统的外部视图； 系统的内部试图；
通过用例来构造，提供外部 通过类、包来构造，提供内部视图视图的结构； 的结构 ；
主要用于用户和开发人员签 主要为开发人员使用，以理解如何署合同时明确系统应该做什么； 设计和实现系统；
需求中可能存在冗余和不一致； 不应该存在冗余和不一致等问题；
捕获系统的功能； 概述如何实现系统的功能；
定义在分析阶段中进一步进行 定义用例实现，每个实现代表对分析的用例 ； 用例模型中一个用例的分析；
62
1、分析活动
（ 1）构架分析确定系统的总体框架结构。
① 以业务模型和用例模型为基础，确定分析包。
一个大的系统包含有许多功能，通过分析业务模型、
用例模型，将系统功能组织成大小适中的包。划分包的原则是将与一个业务过程相关的所有用例及其有扩展关系、包含关系的用例都放在一个包中。
好处：
便于实现和管理；
将变化局限在一个包内，减少由于需求变化对整个系统结构的影响。
划分了分析包后，检查每个包是否有公共特性,提取出组成公共的分析包，便于其他包使用。要定义分析包之间的依赖关系。
63
检查每个分析包，如果包中含有一些可共享的、较低层的、可选择的功能，将它们组织成独立的服务包，便于为不同的系统复用与选择。
② 重要的实体类对理解系统结构很有帮助，对它们进行概要说明，包括属性、操作及与其他实体类的关联。
③ 定义系统级的公共特殊需求：系统的可靠性、安全性、
可用性、可维护性、容错、分布等非功能性需求。
（ 2）确定用例实现在需求获取阶段是从系统外部来看系统的功能。 功能放在用例中描述,功能实现的过程 用活动图描述，用例中各个对象之间、与外部参与者之间发生的 交互关系 用协作图、顺序图来反映,一个对象 跨越多个用例的 完整的行为描述用状态图来反映。但仅有这些还不能满足系统设计与实现的需要，因此，要细化每个用例。具体步骤如下：
64
① 分析用例模型的每个用例，确定用例实现的分析类和事件流。 分析类代表了类的抽象。 将参与用例实现的分析类收集到类图中。分析模型中使用了分析类的 3种构造型（边界类、控制类、实体类）。确定分析类注意以下几点：
为以人充当的角色建立一个主要边界类（通常实现为一个主窗口）。
为每个外部系统充当的角色定义一个主要边界类，
使其代表通信接口。
确定一个控制类负责处理用例实现的控制和协调关系。有时，一些控制信息是由参与者在与系统交互时处理的，这种情况下可将控制封装在边界对象中。
仔细研究用例说明和已有的业务模型确定实体类。
考虑每个用例实现所涉及到的信息，将它们分配到
3类对象中。
65
② 描述每个对象之间的交互。
③ 描述每个用例实现的特殊需求。
用例实现是对用例内部比较细节的描述，是分析类之间相互协作的构造。可通过用例实现回溯到用例模型，保持需求获取和分析之间的无缝连接。
（ 3）分析每个类的职责、属性和关联
确定分析类的职责通过研究一个分析类在每个用例实现中充当的角色，
将其在各个用例实现中的职责组合在一起，构成分析类的职责。
确定分析类的属性注意几点：与人交互的边界类的属性通常是参与者录入的信息项。与外部系统交互的边界类的属性表现为通信接口。实体类的属性往往作为重要信息被录入系统。
66
从几个分析类中抽取出公共的或可共享的特性，组成新的类。
确定分析类的关联。类之间的关系尽可能简单。
定义分析类的特殊需求。参照用例实现的特殊需求，
避免重复定义。
（ 4）检查分析模型用例实现、分析类和分析包构成了不同层次的分析模型，隋着分析的用例越来越多，分析模型会逐步完善起来。要检查分析模型中各种成分的准确性、一致性、
完整性。在分析阶段的后期要检查分析包之间的关系，
尽量独立且内聚性高，每个包实现一个完整的业务逻辑。
67
2、实例 － ATM系统的用例模型和分析模型在 ATM系统中，储户是参与者，取款、存款和转帐是 3个用例。 ATM的用例模型如图所示。
取款存款转帐储户
68
根据用例建立分析模型：
现在只考虑“取款”用例。完成取款用例动作序列的简化路径是：储户表明自己的身份；储户选择从哪个帐户取款；确定取款金额；系统从帐户扣除取款金额；
发给储户相应金额的现金。
通过分析取款用例实现时的角色，确定所需的分析类包括,分发 边界类 （指分发金额）,出纳接口 边界类、
取款 控制类,帐户 实体类 。边界类负责与用户进行交互并且处理交互的信息；控制类负责取款的事务处理；
实体类负责保存和管理帐户信息。
“取款”用例的分析模型如下图所示。在图中还表示了分析模型的“取款”用例实现跟踪依赖于用例模型的“取款”用例。
69
取款存款转帐储户取款参与者
,跟踪,
用例模型 分析模型分发 出纳接口 取款 帐户下图中，描述了“取款”用例如何通过一个带有,跟踪,（构造型元素）依赖关系的协作来实现，在这个用例实现中有 4个类参与并充当角色。图中虚线椭圆表示用例实现或协作。
70
下图显示了每个用例如何实现为分析类的结构。在图中选用不同的底纹来表示一个类参与哪个用例实现并在其中充当什么角色。如，有 4个类参与了“取款”用例的实现。“出纳接口”类和“帐户”类参与并在全部 3个用例实现中充当角色。
取款转帐存款储户分发 取款出纳接口 转帐 帐户货币接收器 存入储户用例模型 分析模型（类图）
71
每个 用例实现 都包含一个充当不同角色的分析类的集合。在分析中，可使用协作图来建立分析类的对象间的交互模型。下图是根据取款用例动作序列的简化路径绘制的协作图，它描述了取款的用例实现是如何通过一组分析对象来执行。
：出纳接口
：分发
：取款,帐户
：储户
1：表明身份 2：请求取款
3：确认并取款
4：授权分发5：分发货币分析模型（协作图）
72
3,Robustness分析 技术
Ivar Jacobson曾提出了 一种健壮性分析（俗称鲁棒分析）技术。在 OO实践中，当完成用例建模后，往往开始创建协作图或顺序图（ RUP中考虑的 用例实现 ），搞清实现一个用例需要哪些对象参与，进而根据职责设计类图。
鲁棒分析是在用例模型的基础上所做的进一步分析，帮助对用例模型的正确性、完善性进行检查，并从中发现一些新的对象及类，以及相关的责任，从而对分析模型的完善提供了支持。
鲁棒分析制定的相关规则：
（ 1）参与者只能通过边界对象与系统交互。
（ 2）边界对象只能与控制对象或参与者交互。
（ 3）实体对象只能与控制对象交互。
（ 4）控制对象可以与边界对象、控制对象、实体对象交互，但不能与参与者交互。
73
鲁棒分析过程：
（ 1）分析用例描述中的事件流 寻找边界对象 。一般以参与者为线索，在什么地方发请求，以什么方式发情求,… 。 细节部分可在用户界面设计中考虑。
（ 2） 找出相关的实体对象 。实体对象一般对应于问题域中的概念类。
（ 3）分析用例描述，针对事件、责任、主要的业务逻辑 设置控制对象 。
绘制鲁棒分析图最好的工具是纸和笔或白版，会给分析者提供大量的自由空间。在分析过程与分析结果相比之下，前者更为重要。
74
8.6 OO分析小结根据以上介绍的分析方法及过程，可总结出分析活动的典型序列（如下图）。用户、开发人员参与
“定义”用例中，开发一个最初的用例模型。他们确定许多概念，并构建参与对象的术语表。开发人员将这些对象分类为实体、边界和控制对象。这些活动迭代进行直到系统大部分功能被标识为带有名字和简短描述的用例为止。
开发人员通过构建交互图来标识遗漏的对象。定义感兴趣的其他行为、定义属性、定义关系、定义职责构成了分析模型的细化。
在固定模型过程中，开发人员通过引入限定词、
泛化关系、以及减少冗余来使模型稳定。检查模型过程以使模型正确、完整、一致以及现实。
75
定义用例定义参与对象定义边界对象定义实体对象 定义控制对象定义交互定义属性定义重要行为 定义关系固定模型评审模型定义操作分析活动图
76
习题
1、什么是领域分析？为什么要进行领域分析？领域分析过程中有哪些活动？
2、使用实例的需求获取与传统的需求获取有何区别？
3、使用实例的需求获取的主要活动有哪些？用例模型是用例图？
4、你认为建立用例模型后，建立交互图和建立类图，哪一个先考虑比较好？为什么？
5,RUP的分析和一般方法的 OO分析有什么主要区别？
6、针对一个具体应用问题，会使用 UML建立用例模型、
类图、交互图、状态图、活动图。掌握分析过程。
第 8章 面向对象分析
领域分析
使用实例的需求获取
用类进行建模
对象 -行为模型
RUP分析活动
OO分析小结
2
8.1 领域分析
1、领域分析的概念面向对象的系统分析可以发生在许多不同的抽象层次。
在业务或企业级层次，可定义模拟整个业务的类、对象、
关系和行为。在业务域层次，可定义描述某特殊的业务域的工作的对象模型和行为模型；在应用层次，建模着重于特定的用户需求。
Firesmith对软件领域分析的定义是：领域分析
(Domain Analysis)指特定应用领域中公共需求的标识、分析和规约，即发现或创建那些可广泛应用的类，其 目的 使它们 在应用域中多个项目间能被复用 。领域分析的角色是设计和建造可复用构件（类似于制造环境中工具制造者的角色），它们被很多相似但不一定是相同的应用开发的人所使用。
3
Lethbridge的定义是：领域分析是软件工程师 了解背景信息的过程 。为了理解问题并在需求分析和软件工程过程的其他阶段作出合理的决策，软件工程师必须了解使用该类软件的一般性商业和技术领域中足够的信息。
2、领域分析过程的活动
（ 1） 定义将被调查的领域分离感兴趣的业务域、系统类型或产品范畴，抽取 OO和非 OO的“项”。 OO项包括：现存 OO应用的类的规约、设计和代码，支持类（如 GUI类或数据库访问类），和领域相关的构件库以及测试案例。非
OO项包括：政策、规程、计划、标准，非 OO应用文档和构件。
4
（ 2）对从领域中抽取出来的项进行分类并建立分类层次。
（ 3）收集领域中应用的代表性样本。
（ 4）分析样本中的每个应用
标识候选的每个可复用对象。
指明对象被标识为可复用的理由。
定义对象的适应性。
估算在领域中复用这些对象的应用的百分率。
使用配置管理技术控制这些对象。
（ 5）为对象开发分析模型。
5
3、领域分析的价值领域分析除了为软件复用奠定基础外，还为较低抽象层次的一般的面向对象分析带来如下好处：
快速开发。有助于集中精力关注最重要的问题，更有效地与相关人员进行交流，可以更快的确定需求。
优化系统。了解领域的细节有助于保证所采纳的解决方案更有效地解决用户的问题。会少犯错误，知道应该遵循那些规程和标准。领域分析给出一个应用领域的总体视图，会引导出更好的抽象从而改进设计。
有了领域知识，就可以洞察新兴趋势及进一步开发的机会，有助于创建适应性更强的系统。
了解通用性和特殊性，有助于创建出具有更好的可重用性和更宽的销售市场的软件。
6
专家提出，没有坚实的领域分析，任何重大的软件项目都不应该进行。对应用领域的深入理解能极大的提高成功的几率。许多非常成功的软件产品的开发人员以前都在业务领域工作过－段时间，对实际需要有着深切的感受。
一旦对领域有了真正的理解，就可进行某一个项目（或产品）的需求分析，包括定义待解决的问题以及开发什么软件来解决它。然而，领域分析永远也不应该结束：开发人员有责任在开发过程中不断增进他们的理解，后续版本的系统扩充通常需要对子领域进行进一步的领域分析。
7
8.2 使用实例的需求获取面向对象的分析过程并不从考虑对象开始，而是从对系统将被使用的方式的理解开始。如果系统是人机交互的，
则考虑被人使用的方式；如果系统是涉及过程控制的，则考虑被机器使用的方式；如果系统是协调和控制应用的，
则考虑被其他系统使用的方式。一旦使用的场景 (scenario)
被定义，软件的建模活动就开始了。
1,use-case（用例或使用实例）
在 OOA中，用例是分析模型的第一个元素的基础，
以终端用户的观点对系统建模。
用例在需求获取时创建，应达到下列 目标,
通过定义由终端用户和开发人员共同认可的使用场景，定义系统的功能和运行需求。
场景是用例的一个实例，表达用例的一个特定发生，
在特定的时间，使用特定的数据进行操作 。
8
提供清楚的、无二义性的终端用户和系统如何相互交互的描述。
提供确认测试的基础。
用例的描述以及用例图构成了参与者与系统交互的用例模型
（ 1）用例的描述建议：其中只有名称和步骤是必须的。
名称 (name)
参与者 (actor)
目标 (goal),参与者要完成的任务。
前置条件 (precondition),列出参与者启动用例前所有必需为真的条件。
相关用例 (related use cases),列出可能是此用例的扩展、包含的用例。
9
步骤 (step),用两列的格式描述用例的每一步（见例）。
后置条件 (postcondition),用例完成后系统所处的状态。
例 1：描述应用程序中打开文件的用例用例,打开文件步骤,
参与者动作 系统响应
① 选择“打开?” 命令 ② 显示“打开文件”对话框
③ 指定文件名
④ 确认选择 ⑤ 关闭对话框
10
例 2、图书管理系统借书 用例用例,为借阅者借出一本书参与者,借书员目标,帮助借阅者借阅书籍并确保输出正确的借出记录前置条件,借阅者必须有一张有效的借书卡并且没有欠费；
该书藉必须具有有效的条形码并且不是来自于参考文献区。
步骤,
参与者动作 系统响应
① 扫描书籍和借书卡 ② 显示允许借阅的信息
③ 在书籍上标记到期日期
④ 确认借出开始 ⑤ 显示借出已被记录的确认的信息后置条件,系统有一个该书藉被借出以及到期时间的记录
11
例 3、某商店 POS系统 用例描述实例用例,购买商品参与者：顾客（发起者）、收款员类型,主要的描述,顾客带着所要购买商品到付款处，收款员记录商品信息并收款。
用例,启动 /关闭系统参与者：管理员类型,主要的描述,管理员接通一台 POS机电源，检查时间、日期正确性，检查完成后，系统处于就绪 状态，以备收款员使用。
12
（ 2）用例图用来显示一系列用例和参与者之间的关系，有助于开发人员表达系统功能的不同的抽象层次的描述。
交互房主传感器配置监测
SafeHome高层用例图
13
启动 /关闭系统房主输入密码询问区域状态
SafeHome交互用例图询问传感器状态按紧急按钮验证密码询问传感器
,include》
,include》
,include》
(参考教材 1 P415)
14
用例分析是理解和组织系统应完成任务的直观方法。它还可以用来 驱动开发过程 。特别是，用例：
可以帮助定义系统的范围，即必须做什么和不必做什么。
可用来计划开发过程。确定的用例数量决定了项目的大小，开发进度可用完成的用例数量来测量。
用来开发和确认需求。
构成测试用例定义的基础。
可用来构造用户手册。
但是用例也不是万能的！注意：（ Lethbridge的观点）
① 用例必须经确认。用例集应是完全的、表达是一致的和明确的。
② 用例分析不一定覆盖到功能需求的所有方面。如，不被参与者触发的活动不会出现在用例中。
③ 当软件需求来自用例时，软件往往只是简单的反映开发软件前用户的工作方式，可能没有考虑到创新的解决方案。
15
2、获取需求的主要活动
（ 1）确定参与者和用例与用户一起确定与系统有交互活动的所有角色，并为每个角色设计用例。确定用例的准则：
每个用例都应该为其角色提供有价值的服务 —— 避免确定的用例太小；确保每个用例都向主要角色提供有价值的服务 —— 避免用例太大。
（ 2）定义用例的优先级
（ 3）描述每个用例用例描述可有不同的抽象层次与描述模板。概要描述主要强调每个用例的主要功能。详细描述包括每个用例的事件流（如何开始，与角色如何交互，如何终止）、
每个用例中所涉及到的对象（编入术语表）、执行一个用例所要求的非功能性需求等。
16
（ 4）建立用例图用例图用来显示一系列用例和参与者之间的关系。
它有助于表达系统功能的高层表述。
用例有特化、扩展和包含关系。特化的使用同类图。一个特化用例代表了几个相似用例，一个或多个特化提供了这些相似用例的细节。
使用包含关系减少用例之间的冗余。即 确定用例中可以被共享的功能。检查每个用例抽取出公共部分创建单独用例。
使用扩展关系区分事件的例外和事件的共有流程，
即确定补充功能或可选功能。如果发现一个用例比较复杂，既包含了一般处理又包含了特殊处理，将特殊处理的部分抽取出来，创建单独的用例。
17
打开文件用户通过键入文件名打开文件通过浏览打开文件试图打开不存在的文件 浏览文件
,extend》,include》
用例的特化、扩展和包含
18
（ 5）建立用户界面原型在面向对象的软件开发中，用例模型和用户界面设计息息相关。用例模型创建后，就可确定参与者如何驱动用例，以及用例以什么形式向参与者提供信息。因此可开始用户界面原型化的迭代过程，和构造系统的其他部分并行进行。
19
8.3 用类进行建模面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。在需求获取阶段已经建立了用例模型等阶段产品，但都是为了容易沟通信息，以用户语言描述的，存在着模糊、冗余、二义性、不一致性等问题。
系统分析阶段要进一步分析、完善前一阶段获取的需求，细化用例模型中的用例、确定系统中的对象、对象的静态和动态特征、对象间的关系及对象的行为约束，
建立满足用户需求的、精确的、稳定的、易于维护的、
便于后续设计的分析模型。
20
用例图：视图 功能模型：模型分析模型：模型类图：视图 对象模型：模型顺序图：视图状态图：视图活动图：视图动态模型：模型分析模型的构成
21
几条通用的分析原则：
（ 1）组装与分解相结合的原则基本对象可组装成复杂对象，对复杂对象进行分解从而完成系统模型的细化。
（ 2）抽象化与具体化相结合的原则数据抽象将数据及作用在其上的操作抽象成对象。
过程抽象为对象的相互作用提供了依据。
抽象强调对象的本质和内在属性，忽视与问题无关的属性。而具体化指在细化过程中，描述对象的某些特性，
加强系统模型的稳定性。
抽象化与具体化相结合可以使具体对象直接从抽象对象的定义中获得已有特性，而不必重复定义它们。
22
（ 3）封装原则将对象的各种独立的外部特性与内部实现细节分开。
对象接口定义要尽可能的与其内部工作状态相分离。封装有助于减少由于需求的改变而对整个系统所造成的影响。
（ 4）相关性原则在分析中要考虑对象间的各种关联，包括静态结构的关联、动态特征的关联。这些关联是对象协作的基础。
（ 5）行为约束的原则通过语义特征来刻画。表示了对象合法存在、对象合法操作应满足的条件，有助于深刻理解对象和系统。
23
一旦建立了系统的用例模型，则可以开始标识候选类，并指明它们的责任和协作。 Wirfs-Brock等人提出了一 种 类 -责任 -协作者 (Class-responsibility-
collaborator,CRC)开发类图的卡片技术。该技术使用实际的或虚拟的索引卡片（参考教材 P417)，为定义类提供较多的信息。其中 责任 是与该类相关的 属性和操作,协作者是为一个类提供要完成的责任所需要的信息的那些类。通常，协作意味着对信息的请求或者对某种操作的请求。
在确定属性和操作时，可把它们列在卡片上。由于卡片的空间有限，使得每一个类都不能太复杂。如果不能在一张卡片上列出所有的职责，该类应分成两个相关的类。可在白板上自由移动卡片以组成类图，在卡片之间画线表示关联与泛化。低科技的卡片技术可能比操作软件用户界面要快，对开发人员通过会议讨论确定方案很有效。
24
1、标识类及对象无论是面向对象分析还是面向对象设计与实现，建立类图都是核心技术。类图是定义其他图的基础，在该基础上用交互图、状态图等进一步描述系统其他方面的特性。
如何识别对象？对象以一系列不同形式展示自身：
外部实体、事物、发生的事件、角色、组织单位、位置或结构。一种最简单的方法是从系统处理说明中找出名词。例如，在 SafeHome的需求陈述中，找出相关的名词是：用户、传感器,控制面板、系统 (安全系统 )、
传感器编号,传感器类型、密码,电话号码,传感器事件,警报器 等。
这些候选的对象是否都可作为在系统中承担责任的有用对象？要根据一定原则筛选。见下表：
25
几条筛选特征,例,SafeHome中潜在的对象及筛选理由
(1)保留的信息 潜在对象 选取理由 筛选理由
(2)需要的服务 用户 角色或外部实体 不符合 1/2
(3)多个属性 传感器 外部实体 符合 1-6
(4)公共属性 控制面板 外部实体 符合 1-6
(5)公共操作 系统 (安全系统 ) 事物或聚集对象 符合 1-6
(6)基本的需求 传感器编号 事物或概念实体 不符合 3
传感器类型 事物或概念实体 不符合 3
密码 事物或概念实体 不符合 3
电话号码 事物或概念实体 不符合 3
传感器事件 事件 符合 1-6
警报器 外部实体 符合 1-6
几乎满足所有特征的对象才会被考虑为分析模型中的合法对象,
26
在 RUP中，将对象分为三种类型：
(1) 边界对象 (或边界类 )
是参与者与系统交互的接口，这些对象位于系统与外部世界的边界上，代表如界面窗口、通信接口、打印机接口、传感器等的抽象，用于阐明和收集系统的边界需求，
这样，可把用户界面或通信接口的变化隔离在一个或多个边界类中。在分析问题域时，边界类仍保持较高的概念层次，说明通过交互所实现的目标就可以了。在设计活动中
（如用户界面设计）才根据参与者操作需求，添加具体的边界对象。
(2) 控制对象 (或控制类 )
控制用例的流程，表示协调、顺序、事务处理以及对其他对象的控制（如分派任务给其他对象）。主要用来体现应用程序的执行逻辑，可以使得变化不影响用户界面和数据库中的表。
27
(3) 实体对象 (或实体类 )
负责保存长效且持久的信息。实体类大多数是直接从业务模型或 领域模型中相应实体类得到的。实体类一般表示为一种逻辑数据结构（通常映射为数据表格或文件），有助于开发人员理解系统所依赖的信息。
实体对象不一定都是被动的，有时可能具有与它所表示的信息有关的复杂行为。实体对象能够将变化与它们所表示的信息隔离开。
在 RUP的分析中，三类对象分别用下图表示：
边界对象 控制对象 实体对象
28
2、定义属性类的属性与操作和该类在系统中承担的责任有关。属性表示了类的特性，即类必须保持的以完成软件目标的信息。属性的取值决定了对象可能的状态。
传感器有类型、编号、位置、颜色、重量、工作状态
（关闭、待机、监控）、采样频率、报警阈值等特性，哪些与系统责任有关呢？
定义属性的一些经验：
一般常识；
分析问题域，检查与对象相联系的形容词或名词短语；
责任；
保存管理信息；
有些属性在对象模型稳定之前可暂不考虑。
29
3、定义操作操作反映对象的行为并以某种方式修改对象的属性。
对象行为可理解为对象应展现的外部服务的总和。对象的行为分为三类：
对象生命周期中的创建、维护、删除行为。
计算行为
监控行为通过这些行为体现对象的责任。对象以两种方式完成它们的责任：
使用它自己的操作去操作自己的属性，
对象和其他对象协作。
因此对象的操作可以有以下 几种类型,
① 实现功能的操作：可追溯到用户需求。
30
② 管理对象创建和删除的操作。在分析阶段，这些操作可暂缓定义。
③ 访问属性的操作。一个类的属性通常是私有的或受保护的，只有通过该类提供的操作来访问。
④ 辅助一个类完成其任务的操作，即协作操作。
如何定义操作呢？
分析问题域：有哪些行为，找有关动词。
如“传感器被赋予一个编号和类型”。
系统的责任：找与责任有关的对象，这些对象为承担责任应提供哪些服务。
分析类的状态转换，引起类状态转换的动作。
追踪一个用例的执行路线，如顺序图，通过对象间通信发现操作。
因此类的有些操作是在对象 -行为模型建立后才补充进来。
下图是传感器类的较为详细的定义及它的 STD：
31
传感器类类型；
编号；
位置；
工作状态；
采样频率；
警报阈值；
初始化；
关闭；
监视；
待机；
显示；
振铃；
拨号；
关闭状态待机状态监视状态初始化命令关闭命令监视命令待机命令关闭命令超越阈值 /激活显示、振铃、拨号传感器类的 STD
…
…
32
4、定义结构与层次类图中的类并非孤立存在，类之间有很多关系。应该关注类模型的结构以及类和子类出现时产生的类层次。
寻找关系的具体方法如下：
检查交互图，如果一个类向另一个类有请求，则它们之间通常有关联关系。
检查类的聚合关系。
检查类的泛化关系，寻找相似对象的不同点，抽取不同的部分定义为特殊类（自顶向下），或将共性的部分提升为基类（自底向上）。
检查其他类，发现不同类中的共同点，将共同的部分定义一个新类。其他类和新类之间的关系也是泛化关系。
但关系太多的类往往对其他类有更多的要求，较难复用且维护的工作量也很大，一旦其他类发生变化，则对该类产生影响。
33
（ 1）关联关系是类之间的连接关系，可以是双向的也可以是单向的。
两个关联之间可以相互发送消息。
订单类的属性放入客户类中，可以找到客户的订单；
而客户类的属性放入订单类中，可以找到订单的客户。
在一对多或多对多的关联中，从重数为 1的对象中找到它所对应的类的对象通常是比较困难的。解决的办法是在关联中加入限定，它可以唯一地识别重数为“多”
端的对象，以便快速定位到要查找的对象。
订单 客户* 属于 1拥有订单 订单号 客户属于
34
system sensor
alarm sensor event
1 检测 *
1
0..*
识别1
*
激活
SafeHome中几个对象类的关联
（参考教材 1P423)
35
（ 2）聚合关系表示类之间整体与部分的关系。 标识类的聚合的优越性：
清晰的表达语义并用重数约束之间的关系。
简化对象的定义。
支持复用。如“发动机类”可以是一个可复用构件，用于其他系统定义中。
飞机内嵌发动机和导航仪的属性内嵌发动机和导航仪的操作
…
…
飞机发动机 导航仪
36
身份人员会计师身份经理身份稳定部分 可变部分在强聚合关系中，部分依赖于整体，如果整体不存在了，部分会随之消失。实现时一同删除。聚合关系使得类具有了层次结构。
能表示动态变化的对象特征。不需要经常变化的属性与操作放在整体类，需要动态变化的特征放在部分类。
37
（ 3）泛化关系是一般与特殊关系。将具有共同特性的元素抽象成一般类，通过增加其内涵生成特殊类。
通常，符合下属条件之一类的泛化才有存在的价值：
便于实现软件重用。
一般类有两个或两个以上的特殊类。（消除冗余）
需要用它们创建对象实例。
但要避免过渡泛化，否则会增加系统的复杂性。
泛化关系使得类具有了层次结构。下图是 SafeHome
的部分类图。
38
system
control
panel
sensor alarm
entry
sensor
smoke
sensor
motion
sensor
SafeHome的部分类图
39
（ 4）包复杂系统的分析模型可能有数十个结构、上百个类，
难以理解与实现。当所有类的某个子集相互协作以完成一组内聚的责任（功能）时，划分为子系统（ UML称为包）。
包确定了整个系统抽象粒度更大的结构。包图可产生于类图之后（将类图组合成包），或将用例的功能分派给包，再细化包以产生类图。
如参考教材 1P421中将“控制面板类”的整个聚合结构划分成“控制面板包”。下图是某一教学管理系统的包图及包图的细化：
40
MFC类 用户接口出错处理 教学管理 数据库教学管理系统的包图
41
,subsystem》
课程注册子系统系统与子系统包图
,subsystem》
成绩管理子系统
,system》
教学管理系统
42
选课管理成绩管理 人事信息教学管理课程 学生登记课程登记开设课程选课统计学生成绩登记成绩统计学生教师身份验证
43
8.4 对象 -行为模型用例中的每个用例都是通过若干对象相互合作实现的。对象 -行为模型指明一个系统对外部事件的激励所作出的响应。为创建该模型，应该完成以下工作：
评估所有 use-case以完全理解系统中的交互顺序。
标识驱动交互序列的事件并理解这些事件如何和特定的对象相关联。
为每个 use-case创建交互图。
为具有主要动态特征的类建立状态转换图。
为描述对象的工作流同时便于识别并发活动建立相应的活动图。
评价对象 -行为模型以验证精确性和一致性。
44
1、通过 use-case识别事件，为对象的交互行为建模事件是某个时刻发生的事，包括所有来自或发往用户的信息、外部设备的信号、输入、策略、中断、转换和动作。当系统与参与者（人、设备或外部系统 )交换信息时则一个事件发生。为了方便分析对象对外部事件的响应，有必要建立交互图（协作图、顺序图），用于显示一个用例实现中涉及到的对象和这些对象间的消息传递情况。
（ 1）顺序图下面通过 SafeHome的用例说明，识别出事件，找出与该事件相关的对象，并将用例的责任分派给它们，通过它们的交互，体现了系统完成一个用例的整体行为。
45
检查 SafeHome的 use-case，带下划线的部分指明了事件。
（参考教材 1P424)
① 房主观察控制面板 以确定是否系统以准备好接收输入。
如果 系统未准备好,房主必须物理地关闭门 /窗户，以便 使
,准备好,指示灯亮 。
② 房主使用键盘输入 4位密码,系统 将密码与存储在配置库中的有效密码比较,如果密码不正确，控制面板 鸣叫一次并复位 等待再次输入。如果密码正确，控制面板等待进一步的动作。
③ 房主 选择键入,stay”（仅激活外部的传感器） 或
,away”（激活所有的传感器）以启动系统。
④ 当处于激活状态时,房主可观察到一个红色指示灯 。
46
一旦所有事件被标识，将它门分配给所涉及的对象。
对象可以生成事件（如房主生成密码输入事件）或识别发生在其他地方的事件（如控制面板识别密码比较事件的二进制结果）。
下图是 SafeHome的部分顺序图：
房主 控制面板 系统输入密码 密码比较密码正确 /不正确
[不正确 ]启动蜂鸣器蜂鸣器声响等待下一个动作
47
房主 控制面板 系统选择 stay/away 激活传感器传感器被激活请求指示灯亮红灯亮等待下一个动作
Rumbaugh等人在 OMT方法中提出，建立反映系统交互行为的动态模型时，需描述正常交互的脚本和例外的脚本。脚本也称为场景，是用例的一个实例。通过脚本中的步骤确定事件，比较方便的建立顺序图、协作图等视图。
48
如 ATM系统示意图：
分行计算机分理处计算机分理处计算机帐户帐户
ATM
ATM
自动出纳机与用户交互的正常脚本：
（ 1） ATM请求用户插入卡：用户插入现金卡。
（ 2） ATM接受卡片并读出它的卡号。
（ 3） ATM要求密码：用户输入密码 401230。
（ 4） ATM请求分行确认卡号和密码：由分理处检验并通知 ATM。
（ 5） ATM要求用户选择事务类型：用户选择取款。
49
（ 6） ATM要求输入现金数量：用户输入 $200。
（ 7） ATM请求分行处理事务，分行把请求传给分理处，
确认事务成功。
（ 8） ATM分发现金并要求用户取现金：用户取现金。
（ 9） ATM提示用户是否要继续：用户键入不继续。
（ 10） ATM打印收据，退出卡，并提示用户取走它们：
用户取走收据和卡。
（ 11） ATM请求用户插入卡。（回到初始状态）
还可列出用户与自动取款机交互的例外的脚本。
通过脚本，比较容易确定用例（如取款用例）中的事件（交互信息）、以及事件的发送者和接收者（完成该用例所涉及到的对象）。
50
（ 2）协作图用于快速浏览对象间的相互合作。强调对象间的通信，
不像顺序图那样强调传递消息间的时序性，它用数字顺序标号表示消息的顺序。
（ 3）活动图用来描述对象或构件执行的工作流。突出的优点：用来表示并发活动及活动的执行者。
在分析阶段，活动图用来描述满足用例要求所要进行的活动及之间的约束关系。（有些专家认为用活动图建立用户业务模型比对象模型更易理解）。
在设计阶段，活动图可以反映对象内部的工作流程，
可由状态图演化过去，是状态图的一个实例。
51
2、为单个对象类的重要行为建模
Pressman提出，在 OO系统的语境内，必须考虑两种不同的状态特征,
（ 1）当系统完成其功能时每个对象的状态；
（ 2）当系统完成其功能时从外界观察到的系统状态，
即系统的整体行为。
类的状态图反映了该类中每个对象内部的工作，在它的生命周期内遇到某个事件或动作使它从一种状态转换到另一种状态。通过状态图关注对象类应负有的责任，
防止遗漏一些功能，帮助标识对象类的操作，因此需要对有重要行为的对象类建立状态图。
状态图还能为对象设计中建立每个操作体的内部逻辑提供帮助。
52
例如,SafeHome系统中的传感器类是比较重要的类，观察它的状态特征 (详见 3.4例 2）对了解整个系统的动态行为很有帮助。
ATM系统中，自动取款机的行为特征比较重要。
下图是自动取款机类在正常取款行为下的状态转换图。
53
开始
do:请求插入卡检查
do:要求密码核对
do:确认帐户选择
do:要求类型输数据
do:要求数量事务
do:处理事务发现金
do:分发现金继续否
do:询问继续否结束
do:打印收据退卡
do:请求取卡插入卡 输入密码密码错帐户正确输入类型输入数量事务成功取现金继续终止打印指令发出取走卡
ATM类的部分 STD
54
范例：移动电话系统功能：
用手机做移动通讯下载铃声下载图片管理电话簿。
55
Talk to Others
Download Picture
Manage Phonebook
Download RingsMobile user Mobile Network
56
定义移动电话系统的对象（简化）
手机包括的对象：
手机屏幕手机按钮手机（屏幕、按钮以外的部件）
其它对象：
基站
MButton
MDisplqy
MmobileStation
MmobileHandset
移动电话系统的类图
57
移动电话系统对象间的通信
:MButton,MDisplqy
:MMobileStation
:MMobileHandset
Mobile user
1:pushDigButton()
3:pushSendButton() 2:displayButtonNumber()
4:connectStation()
6:connectSuccess ()5:createConnection()
移动电话系统的协作图
7:displayConnectSuccess()
58
移动电话系统的顺序图
:MButton,MDisplqy
Mobile user
pushSendButton()
displayButtonNumber()
displayConnectSuccess() connectSuccess ()
createConnection()
pushDigButton()
connectStation()
:MMobileStation,MMobileHandset
59
MButton
MDisplqy
MmobileStation
MmobileHandset
pushDigButton()
pushSendButton()
pushDisconnectButton()
createConnection()
cancelConnection ()
responseError()
displayError()
displayButtonNumber()
displayConnectSuccess()
displayIncomingCall()
connectStation()
disconnectStation()
connectSuccess ()
Disconnectsuccess()
移动电话系统的类图之二 （接口）
60
8.5 RUP的分析活动在统一过程中，用工作流来描述过程。工作人员执行工作流中的一组活动而产生相应的工作产品。
有 7种过程工作流，它们是业务建模、需求、分析、设计、实现、测试和实施。其中需求、分析、设计、实现和测试是核心工作流。
需求工作流：列举出候选需求，捕获功能性需求，
捕获非功能性需求。
分析工作流：构架分析，分析用例，分析类，分析包。
设计工作流：构架设计，设计一个用例，设计一个类，
设计一个子系统。
实现工作流：构架实现，系统集成，实现一个子系统，
实现一个类，执行单元测试。
测试工作流：制定测试计划，设计测试，实现测试，
执行集成测试，执行系统测试，评估测试。
实施工作流：可交付系统的配置。
61
分析工作流的任务是通过精化和组织需求捕获阶段所描述的需求来对其进行分析，工作结果是分析模型。下表列出了用例模型和分析模型的简单比较：
用例模型 分析模型使用用户的语言进行描述； 使用开发人员的语言进行描述；
系统的外部视图； 系统的内部试图；
通过用例来构造，提供外部 通过类、包来构造，提供内部视图视图的结构； 的结构 ；
主要用于用户和开发人员签 主要为开发人员使用，以理解如何署合同时明确系统应该做什么； 设计和实现系统；
需求中可能存在冗余和不一致； 不应该存在冗余和不一致等问题；
捕获系统的功能； 概述如何实现系统的功能；
定义在分析阶段中进一步进行 定义用例实现，每个实现代表对分析的用例 ； 用例模型中一个用例的分析；
62
1、分析活动
（ 1）构架分析确定系统的总体框架结构。
① 以业务模型和用例模型为基础，确定分析包。
一个大的系统包含有许多功能，通过分析业务模型、
用例模型，将系统功能组织成大小适中的包。划分包的原则是将与一个业务过程相关的所有用例及其有扩展关系、包含关系的用例都放在一个包中。
好处：
便于实现和管理；
将变化局限在一个包内，减少由于需求变化对整个系统结构的影响。
划分了分析包后，检查每个包是否有公共特性,提取出组成公共的分析包，便于其他包使用。要定义分析包之间的依赖关系。
63
检查每个分析包，如果包中含有一些可共享的、较低层的、可选择的功能，将它们组织成独立的服务包，便于为不同的系统复用与选择。
② 重要的实体类对理解系统结构很有帮助，对它们进行概要说明，包括属性、操作及与其他实体类的关联。
③ 定义系统级的公共特殊需求：系统的可靠性、安全性、
可用性、可维护性、容错、分布等非功能性需求。
（ 2）确定用例实现在需求获取阶段是从系统外部来看系统的功能。 功能放在用例中描述,功能实现的过程 用活动图描述，用例中各个对象之间、与外部参与者之间发生的 交互关系 用协作图、顺序图来反映,一个对象 跨越多个用例的 完整的行为描述用状态图来反映。但仅有这些还不能满足系统设计与实现的需要，因此，要细化每个用例。具体步骤如下：
64
① 分析用例模型的每个用例，确定用例实现的分析类和事件流。 分析类代表了类的抽象。 将参与用例实现的分析类收集到类图中。分析模型中使用了分析类的 3种构造型（边界类、控制类、实体类）。确定分析类注意以下几点：
为以人充当的角色建立一个主要边界类（通常实现为一个主窗口）。
为每个外部系统充当的角色定义一个主要边界类，
使其代表通信接口。
确定一个控制类负责处理用例实现的控制和协调关系。有时，一些控制信息是由参与者在与系统交互时处理的，这种情况下可将控制封装在边界对象中。
仔细研究用例说明和已有的业务模型确定实体类。
考虑每个用例实现所涉及到的信息，将它们分配到
3类对象中。
65
② 描述每个对象之间的交互。
③ 描述每个用例实现的特殊需求。
用例实现是对用例内部比较细节的描述，是分析类之间相互协作的构造。可通过用例实现回溯到用例模型，保持需求获取和分析之间的无缝连接。
（ 3）分析每个类的职责、属性和关联
确定分析类的职责通过研究一个分析类在每个用例实现中充当的角色，
将其在各个用例实现中的职责组合在一起，构成分析类的职责。
确定分析类的属性注意几点：与人交互的边界类的属性通常是参与者录入的信息项。与外部系统交互的边界类的属性表现为通信接口。实体类的属性往往作为重要信息被录入系统。
66
从几个分析类中抽取出公共的或可共享的特性，组成新的类。
确定分析类的关联。类之间的关系尽可能简单。
定义分析类的特殊需求。参照用例实现的特殊需求，
避免重复定义。
（ 4）检查分析模型用例实现、分析类和分析包构成了不同层次的分析模型，隋着分析的用例越来越多，分析模型会逐步完善起来。要检查分析模型中各种成分的准确性、一致性、
完整性。在分析阶段的后期要检查分析包之间的关系，
尽量独立且内聚性高，每个包实现一个完整的业务逻辑。
67
2、实例 － ATM系统的用例模型和分析模型在 ATM系统中，储户是参与者，取款、存款和转帐是 3个用例。 ATM的用例模型如图所示。
取款存款转帐储户
68
根据用例建立分析模型：
现在只考虑“取款”用例。完成取款用例动作序列的简化路径是：储户表明自己的身份；储户选择从哪个帐户取款；确定取款金额；系统从帐户扣除取款金额；
发给储户相应金额的现金。
通过分析取款用例实现时的角色，确定所需的分析类包括,分发 边界类 （指分发金额）,出纳接口 边界类、
取款 控制类,帐户 实体类 。边界类负责与用户进行交互并且处理交互的信息；控制类负责取款的事务处理；
实体类负责保存和管理帐户信息。
“取款”用例的分析模型如下图所示。在图中还表示了分析模型的“取款”用例实现跟踪依赖于用例模型的“取款”用例。
69
取款存款转帐储户取款参与者
,跟踪,
用例模型 分析模型分发 出纳接口 取款 帐户下图中，描述了“取款”用例如何通过一个带有,跟踪,（构造型元素）依赖关系的协作来实现，在这个用例实现中有 4个类参与并充当角色。图中虚线椭圆表示用例实现或协作。
70
下图显示了每个用例如何实现为分析类的结构。在图中选用不同的底纹来表示一个类参与哪个用例实现并在其中充当什么角色。如，有 4个类参与了“取款”用例的实现。“出纳接口”类和“帐户”类参与并在全部 3个用例实现中充当角色。
取款转帐存款储户分发 取款出纳接口 转帐 帐户货币接收器 存入储户用例模型 分析模型（类图）
71
每个 用例实现 都包含一个充当不同角色的分析类的集合。在分析中，可使用协作图来建立分析类的对象间的交互模型。下图是根据取款用例动作序列的简化路径绘制的协作图，它描述了取款的用例实现是如何通过一组分析对象来执行。
：出纳接口
：分发
：取款,帐户
：储户
1：表明身份 2：请求取款
3：确认并取款
4：授权分发5：分发货币分析模型（协作图）
72
3,Robustness分析 技术
Ivar Jacobson曾提出了 一种健壮性分析（俗称鲁棒分析）技术。在 OO实践中，当完成用例建模后，往往开始创建协作图或顺序图（ RUP中考虑的 用例实现 ），搞清实现一个用例需要哪些对象参与，进而根据职责设计类图。
鲁棒分析是在用例模型的基础上所做的进一步分析，帮助对用例模型的正确性、完善性进行检查，并从中发现一些新的对象及类，以及相关的责任，从而对分析模型的完善提供了支持。
鲁棒分析制定的相关规则：
（ 1）参与者只能通过边界对象与系统交互。
（ 2）边界对象只能与控制对象或参与者交互。
（ 3）实体对象只能与控制对象交互。
（ 4）控制对象可以与边界对象、控制对象、实体对象交互，但不能与参与者交互。
73
鲁棒分析过程：
（ 1）分析用例描述中的事件流 寻找边界对象 。一般以参与者为线索，在什么地方发请求，以什么方式发情求,… 。 细节部分可在用户界面设计中考虑。
（ 2） 找出相关的实体对象 。实体对象一般对应于问题域中的概念类。
（ 3）分析用例描述，针对事件、责任、主要的业务逻辑 设置控制对象 。
绘制鲁棒分析图最好的工具是纸和笔或白版，会给分析者提供大量的自由空间。在分析过程与分析结果相比之下，前者更为重要。
74
8.6 OO分析小结根据以上介绍的分析方法及过程，可总结出分析活动的典型序列（如下图）。用户、开发人员参与
“定义”用例中，开发一个最初的用例模型。他们确定许多概念，并构建参与对象的术语表。开发人员将这些对象分类为实体、边界和控制对象。这些活动迭代进行直到系统大部分功能被标识为带有名字和简短描述的用例为止。
开发人员通过构建交互图来标识遗漏的对象。定义感兴趣的其他行为、定义属性、定义关系、定义职责构成了分析模型的细化。
在固定模型过程中，开发人员通过引入限定词、
泛化关系、以及减少冗余来使模型稳定。检查模型过程以使模型正确、完整、一致以及现实。
75
定义用例定义参与对象定义边界对象定义实体对象 定义控制对象定义交互定义属性定义重要行为 定义关系固定模型评审模型定义操作分析活动图
76
习题
1、什么是领域分析？为什么要进行领域分析？领域分析过程中有哪些活动？
2、使用实例的需求获取与传统的需求获取有何区别？
3、使用实例的需求获取的主要活动有哪些？用例模型是用例图？
4、你认为建立用例模型后，建立交互图和建立类图，哪一个先考虑比较好？为什么？
5,RUP的分析和一般方法的 OO分析有什么主要区别？
6、针对一个具体应用问题，会使用 UML建立用例模型、
类图、交互图、状态图、活动图。掌握分析过程。
