Transcript 需求分析

软件工程
Software Engineering
Fall, 2012
第四章 需求分析
(Requirements Elicitation)

面向对象需求分析
2
An overview of OOSE development
activities and their products
problem statement
Requirements
elicitation
nonfunctional
requirements
functional
model
usecase diagram
Analysis
class diagram
analysis
object model
System design
statechart diagram
dynamic
model
sequence diagram
3
面向对象软件工程(OOSE)开发的活动及
产物
问题陈述
需求获取
非功能需求
功能需求
用例图
需求分析
类图
分析对象模型
系统设计
状态图
动态模型
序列图
4
Requirements Specification vs
Analysis Model
Both focus on the requirements from the user’s
view of the system.
 The requirements specification uses natural
language (derived from the problem statement)
 The analysis model uses a formal or semiformal notation (we use UML)
5
需求分析面临的困难


需求分析是一个项目的开端，也是项目建设的基
石。在失败的项目中，80％是由于需求分析的不
明确而造成的。因此一个项目成功的关键因素之
一，就是对需求分析的把握程度。
由于软件项目的特殊性和行业覆盖的广阔性，以
及需求分析的高风险性，软件需求分析的重要性
是不言而喻的，同时需求分析又面临着很多困难。
6
需求分析失败案例

1999年NASA（ National Aeronautics and
Space Administration，美国国家航空航天局）
损失了一颗价值数亿美元的气象卫星，据调查
是因为列在度量表中的控制数据出了问题。不
巧的是这个缺陷在灾难发生几天之前才刚发现，
如果在需求分析阶段就被识别出来就可避免损
失了。
7
面向对象需求分析


分析建模的目的是对来自客户的需求形式化。
形式化可以导致新的洞察和发现需求错误。
避免需求错误或遗漏的第一道防线就是把所有
的需求细化，建立分析模型。
8
需求分析模型
分析模型由三个独立的模型构成：

由用例和场景表示的功能模型；
2.
用类和对象表示的分析对象模型；
3.
由状态图和顺序图表示的动态模型。
在需求获取阶段得到的用例模型就是功能模型。据此可
导出分析对象模型和动态模型。
需要注意，这些模型代表的是来自客户的概念，而非实
际软件类或实际构件。如数据库、子系统、会话管理器、
网络等，不应出现在分析模型中，因为这些概念仅与实
现相关。
分析中的类可以看作是高层抽象，在后续阶段将使用更
多的细节实现。
1.



9
用例图：视图
功能模型：模型
类图：视图
对象模型：模型
分析模型：模型
顺序图：视图
状态图：视图
动态模型：模型
活动图：视图
分析模型的构成
10
分析对象模型

对象模型是三个模型中最关键的一个模型，它
的作用是描述系统的静态结构，包括构成系统的
类和对象，它们的属性和操作，及它们之间的关
系。
11
分析对象模型

在分析对象模型中有实体对象、边界对象和控制对
象等三种类型。

实体对象表示系统将跟踪的持久信息；

边界对象表示参与者与系统之间的交互（接口）；

控制对象负责用例的实现 。
图示
Actor
Boundary
Control
Entity
参与者
边界对象
控制对象
实体对象
12
在RUP的分析中，三类对象分别用下图表示：
边界对象
控制对象
实体对象
13
(1) 实体对象(或实体类)




负责保存长效且持久的信息。
实体类大多数是直接从业务模型或 领域模型中相
应实体类得到的。
实体类一般表示为一种逻辑数据结构（通常映射
为数据表格或文件），有助于开发人员理解系统
所依赖的信息。
实体对象不一定都是被动的，有时可能具有与它
所表示的信息有关的复杂行为。实体对象能够将
变化与它们所表示的信息隔离开。
14
(2) 边界对象(或边界类)




是参与者与系统交互的接口，这些对象位于系统
与外部世界的边界上，代表如界面窗口、通信接
口、打印机接口、传感器等的抽象，用于阐明和
收集系统的边界需求，
这样，可把用户界面或通信接口的变化隔离在一
个或多个边界类中。
在分析问题域时，边界类仍保持较高的概念层次，
说明通过交互所实现的目标就可以了。
在设计活动中（如用户界面设计）才根据参与者
操作需求，添加具体的边界对象。
15
(3) 控制对象(或控制类)


控制用例的流程，表示协调、顺序、事务处理以
及对其他对象的控制（如分派任务给其他对象）。
主要用来体现应用程序的执行逻辑，可以使得变
化不影响用户界面和数据库中的表。
16
UML提供的衍型机制
• 可用UML提供的衍型机制，区分不同类型对象。



衍型，UML建模术语。
衍型是对UML的词汇扩展，允许创建与已有的构
造块相似但针对特定问题的新种类的构造块。
在图形上，把衍型表示为双尖括号（即：<<和>>）
括起来的名字，放在其他元素名之上。作为一种
选择，可以用一种与衍型相联系的新图标表示被
衍型化的元素。
17
实例：
具有两个按钮的手表的分析类
<<entity>>
Year
<<entity>>
Month
<<control>>
ChangeDateControl
<<boundary>>
ButtonBoundary
<<boundary>>
LCDDisplayBoundary
<<entity>>
Day

使用实体对象、控制对象和边界对象和等
概念对系统建模时，常常需要提供一些简
单的启发式规则来指导开发人员使用这些
概念，可以使用相应的类来跟踪。
18
实例：
具有两个按钮的手表的分析类

实体对象：Year、Month、Day
控制对象：ChangeDateControl

边界对象： ButtonBoundary、 LCDDisplayBoundary

19
动态模型

动态模型由多个状态图组成。

对于每一个具有重要动态行为的类都有一个状态
图，从而表明所有系统活动的模式。

各个状态图并发地执行，并可以独立地改变状态。

各种类的状态图可以通过共享事件组合到一个动
态模型中。
20
面向对象需求分析 - 步骤
1.
2.
3.
4.
标识类：通过查看相关资料并与用户广泛地接触，自己对
问题域有一个大致的了解。在这个基础上，将问题域中与
系统和问题有关的对象提取出来。
标识类的关联：将第一步中抽象出来的对象(类)的之间的
关系考虑清楚；如整体与部分、从属关系等；
标识类的属性和操作：为“类”提取与系统问题域有关的属
性、服务等；
由于要完成一项任务，肯定是有不同的对象互相协作完成
的。同时一个对象的属性、服务也是在与相关对象的协作
中体现出来的。将问题域中所有任务的对象的协作关系搞
清楚，是面向对象需求分析的关键一环。即将问题域中的
“剧情”搞清楚，是需求分析的主要工作之一。
21
面向对象需求分析
•
以上四步并不是单独的而是互有联系，可以同时进行的。
通过，对以上4步工作的反复执行我们就可以建立一个
基于对象的问题域的模型。
•
在该模型的基础上，可以比较容易地产生一个符合用户
需求的软件需求规格说明书成为后续工作的基础。
22
分析建模活动的实际步骤：
1) 标识实体对象
2) 标识边界对象
3)
4)
5)
6)
7)
8)
9)
标识控制对象
使用顺序图将用例映射为对象
使用CRC卡片对对象之间的交互建模
标识关系（结构）
标识属性
对每一对象的与状态有关的行为建模
分析模型评审
23
1) 标识实体对象
 自然语言分析法：利用Abbott启发式准则，将语言成分
映射为模型成分。
 自然语言分析法主要关注用户术语。但存在以下缺陷：
识别质量高度依赖人们的书写风格；
可能会出现许多无关词汇，或同义词。
语言成分
模型成分
示例
专有名词
实例
普通名词
类
Doing动词
操作
创建、提交、选择
Being动词
继承
是…的一种，是…中的一个
Having动词
聚合
有…，由…组成，包括…
情态动词
约束
必须是
形容词
属性
事件描述
人员乙
现场工作人员
24
标识实体对象
 检查每一个用例，标识所有候选对象
1. 用例中的连续名词（如借阅事件）；
2. 系统需要跟踪的现实世界中的实体（如借阅记
录、馆藏图书信息）；
3. 系统需要跟踪的现实世界中的活动（如紧急情
况操作预案）；
4. 数据源或数据潭（如借阅者、管理员）。
25
2) 标识边界对象
 在用例图中，每一个参与者至少要与一
个边界对象交互。边界对象收集来自参
与者的信息，将它们转换为可用于实体
对象和控制对象的表示形式。
 边界对象对用户界面进行粗略的建模，
不涉及如菜单项、滚动条等可视方面的
细节。
26
标识边界对象

1.
2.
3.
标识边界对象的启发式准则如下：
标识用户所需初始用例的用户界面控制;
标识用户需要键入系统的数据表格;
标识通知和系统用于响应用户的消息;
4. 当用例中有多个参与者时，根据构想的用户界面来标识
参与者的行为;
5. 不要使用边界对象对接口的可视方面建模，应使用用户
原型对可视用户界面建模;
6. 使用用户的术语来描述接口，不要使用来自设计和实现
的术语。
27
3)
标识控制对象
 控制对象负责协调实体对象和边界对象。
 控制对象在现实世界中没有具体的对应物，它通常
从边界对象处收集信息，并把这些信息分配给实体
对象。
28
图书管理系统中的实体对象
①
②
③
④
⑤
Borrower：借阅者。他们可以借阅、返还、预约和取消预
约。因为名字可能重复，可用借阅证号码识别。
Title：馆藏图书。它表明某一种书，通过馆藏号码识别。
Book：流通图书。它表明某一种书的具体复本，通过馆藏
号码识别。
Loan：借阅记录。同一个人关于不同图书的借阅记录是不
同的。
Reservation：预约记录。
29
图书管理系统中的边界对象
①
②
③
④
mainWindow：主窗口。有借书、还书、预约、取消预约、
添加书种、修改书种、删除书种、添加借阅者、修改借阅
者、删除借阅者、添加图书复本、删除图书复本等操作。
BorrowerDialog：借阅者对话框。有添加借阅者、修改借
阅者、删除借阅者等操作。
FindBwrDialog：弹出对话框。有根据借阅者ID号码查找
借阅者的操作。
TitleDialog：馆藏图书对话框。有添加书种、修改书种、
删除书种等操作。
30
⑤
⑥
⑦
⑧
⑨
⑩
FindTDialog：弹出对话框。根据图书的馆藏号查找馆藏
图书。
BorrowDialog：借书对话框。根据馆藏图书的馆藏号和借
阅者信息，执行借阅动作，创建和保存借阅记录。
ReturnDialog：还书对话框．根据流通图书的馆藏号和复
本号，执行还书动作，删除借阅记录。
ReserveDialog：预约对话框。根据馆藏图书的馆藏号和借
阅者信息，执行预约、取消预约动作。
MessageWindow：显示提示信息窗口。
LoginDialog：输入用户名和密码的窗口。
31
4) 使用顺序图将用例映射为对象
 顺序图将用例与对象联系起来，直观地描述了
用例（场景）行为在其参与对象之间是如何实
施的。
 顺序图对用例中各参与对象之间的交互序列进
行建模。每一个消息从一个对象（或参与者）
发送给另一个对象（或参与者）。消息的接受
就触发了一个操作。
 通过顺序图，将责任以操作集合的形式分配给
每一个对象。如果一个对象参与到多个用例，
则其操作应为这些用例共享。
32
 画顺序图的启发式准则如下：
1. 顺序图第一栏对应激活该用例的参与者;
2. 顺序图第二栏是边界对象;
3. 顺序图第三栏是管理用例中其他参与对象的控
制对象;
4. 通过边界对象来初始化用例，并创建控制对象;
5. 通过控制对象可创建其他边界对象;
6. 实体对象允许边界对象和控制对象访问;
7. 实体对象不能访问边界对象和控制对象;
33
借书用例的顺序图
:Librarian :mainWindow :BorrowDialog
1:borrow()
2:createDialog()
3:borrow()
:Title
:Book
:Borrower
:Loan
4:findTitle(string)
5:getTitle()
6:getAvaliableBook()
7:findBorrower(string)
8:newLoan(OID, OID, Date)
9:store()
10:getBorrower(OID)
11:update()
12:addLoan(OID)
13:getObject(OID)
14:setLoan(OID)
15:update()
34
还书用例的顺序图
:Librarian :mainWindow :ReturnDialog
1:return()
2:createDialog()
3:return()
:Borrower
:Book
:Loan
4:findBook(Integer)
5:getObject(OID)
6:getLoan()
7:getBorrower()
8:setLoan(null)
9:update()
10:delLoan(OID)
11:update()
12:delete()
35
5) 使用CRC卡片对对象之间的交互建
模
 CRC是类、职责和协作的缩写。
 CRC (Class, Responsibility, Collaboration)
 Class：类，类名在CRC卡的顶端；
 Responsibility：职责，该类需要履行的职责在CRC卡的左
栏；
 Collaboration：协助，该类为了完成其职责，所需要协作
的其它类CRC卡的右栏。
 每一个类可用一张CRC卡片表示。
36
类名 读卡机
职责
显示欢迎词
接收磁卡
让密码验证器检验
启动菜单选择器
退出磁卡
协作
密码验证器
菜单选择器
类名 菜单选择器
协作
职责 显示菜单
存款管理器
等待客户选择 取款管理器
调用相应的
存款/取款管理器
类名 密码验证器
协作
职责 从账户中取出密码
账户
如无此账户返回假值
提示客户输入密码
读入密码
比较核实, 返回结果
类名 账户
职责 检查账户有效性
返回密码
检查取款/存款信息
类名 取款管理器
协作
职责 询问取款额
账户
要求验证账户 出银机
启动出银机发款
37
5) 使用CRC卡片对对象之间的交互建
模
 建立CRC卡片有以下几个步骤：
① 识别类和职责： 首先识别类或对象，然后从客户需求说
明中寻找有关行为的描述，以发现职责。
② 将职责分配到类 ：记录在相应的卡片上。
③ 找寻协作者：依次检查每一类承担的责任，看是否需要其
他类的帮助，找寻与每个类协作的伙伴，并记录在相应卡
片上。
④ 细化：模拟在执行每个基本功能时系统内部出现的场景，
以此推动细化工作的进行。
38
5) 使用CRC卡片对对象之间的交互建
模
 在模拟一个场景的过程中，每当一个类开始“执
行”时，它的CRC卡片就被拿出来讨论，当“控
制”传送到另一个类时，注意力就从前一张卡片
转移到另一张上去了。不同的场景，包括例外和
出错状况，都应逐一加以模拟。
 在这个过程中可以验证已有的定义，不断发现新
的类、职责以及伙伴。
 在模拟不同的场景中会发现某些职责需要重新加
以分配。这些都导致进一步的开发工作。
39
6)
标识关联
 使用类图，能够表示对象之间的关系。
 关联表示了两个或多个类之间的关系。
 关联
 聚集：组成聚集和共享聚集
 泛化和继承
40
类的关联
雇员
Person
0..1
Employment
0..*
0..*
居民
Company
雇主
0..*
Residence
Site
1..*
1..1
Country
41
聚集


支持复用。如“发动机类”可以是一个可复用构
件，用于其他系统定义中。
能表示动态变化的对象特征。不需要经常变化的
属性与操作放在整体类，需要动态变化的特征放
在部分类。
42
组成聚集
滑翔机
1
fuselage
机身
1
tail
1
机尾
1
leftWing rightWing
机翼
43
继承：客户、团体客户、个人客户、雇员
*
订单
DateReceived
isPrepaid
number:String
prce:Money
Dispatch()
close()
1
Name
address
CreditRating():String
项 *
订单项
Quantity:Integer *
price:Money
isSatisfied:Boolean
客户
1
团体客户
个人客户
ContactName
creditRating
creditLimit
CreditCard#
Remind()
billforMonth(Intrger)
1
{creditRating()
=“poor”}
*
产品
销售代表 0..1
雇员
44
 标识关联的启发式准则如下：
1. 检查指示状态的动词或动词短语；
2. 准确地命名关联和角色；
3. 尽量使用常用的修饰词标识出名字空间和关键属
性；
4. 消除可导出其他关联的关联；
5. 在关联集合稳定之前不必关心重复性；
6. 过多的关联使得一个模型不可读；
45
“主题”的概念
 主题是把一组具有较强联系的类组织在一起而得
到的类的集合。
 一个主题内部的对象类应具有某种意义上的内在
联系
 描述系统中相对独立的组成部分（如一个子系统）
 描述系统中某一方面的事物（如人员、设备）
 解决系统中某一方面的问题（如输入输出）
 主题的划分有一定的灵活性和随意性
46
标识关联的操作步骤：
a)
b)
c)
d)
基于“主题”建立系统的包图
建立边界类的类图
建立实体类的类图
建立边界类与实体类之间关系的类图

实例：图书馆图书借阅管理系统
47
a) 基于“主题”建立系统的包图
 建立包图是为了降低复杂性，目的是控制可见度
及指引读者的思路。
 对于面向对象分析模型，主题表示此模型的整体
框架。可以是一个层次结构。
 通过对主题的识别，可以让人们能够比较清晰地
了解大而复杂的模型。
GUI
Library
DataBase
48
b) 建立边界类的类图
 标明类之间的关系，包括关联、泛化等。
messageWindow
loginDialog
returnDialog
borrowerDialog
reserveDialog
mainWindow
borrowDialog
findBwrDialog
findTDialog
TitleDialog
49
c)
建立实体类的类图
 这些类与数据库相关，为了操作方便，以它们
为子类，建立一个持久类(Persistent)作为它们
的父类，共享与数据库相关的操作。
Book
1
*
1
0..*
Persistent
(from DataBase)
0..1
Loan
0..*
1
Title
0..*
Reservation
0..*
Borrower
1
50
d) 建立边界类与实体类之间关系的类图
1
Book
(from Library)
*
1
Title
(from Library)
0..1
BorrowDialog
(from GUI)
Reservation
(from Library)
Loan
(from Library)
0..*
1
Borrower
(from Library)
ReturnDialog
(from GUI)
51
1
Book
(from Library)
0..1
Loan
(from Library)
0..*
*
findTDialog
(from GUI)
1
Borrower
(from Library)
TitleDialog
(from GUI)
1
1
Title
0..*
(from Library)
0..*
0..
Reservation
(from Library)
*
52
7) 标识属性

对象所保存的信息称为它的属性。类的属性所描述的是
状态信息，每个实例的属性值表达了该实例的状态值。
 标识属性的启发性准则如下：
1. 每个对象至少需包含一个属性；
2. 属性取值必需适合对象类的所有实例；
3. 出现在泛化关系中的对象所继承的属性必须与泛化关
系一致；
4. 系统的所有存储数据必须定义为属性；
5. 对象的导出属性应当略去。例如：“年龄”是由属性
“出生年月”导出，它不能作为基本属性存在。
53
8) 对每一对象的与状态有关的行为
建模
对象收到消息后所能执行的操作称为它可
提供的服务。
对每个类的增加、修改、删除、选择等服
务有时是隐含的，在图中不标出，但实现
类和对象时有定义。
其它服务则必须显式地在图中画出。
54
显式标识类的其它服务
① 首先标识在每个类中封装的服务;
② 再比较服务与类的属性，验证其一致性。所标识的类属性，
它必然关联到某个服务，否则该属性就形同虚设，永远不可
能被访问;
③ 画出对象之间的消息通信路径，协调系统的行为。
 自底向上方法：找出每一对象在其生存周期中的所有状态。
每一状态的改变都关联到对象之间消息的传递。从对象着
手，逐渐向上分析。
 自顶向下方法：一个对象必须识别系统中发生或出现的事
件，产生发送给其他对象的消息，由那些对象作出响应。
所以对象应具有能够接收、处理、产生每个消息的服务。
它是从系统行为着手，然后逐渐分析到对象。
④ 使用顺序图或协作图，标识和描述对象之间的相互通信，并
进行运行走查。
55
9) 分析模型评审

1.
2.
3.
4.
从以下四个方面评审分析模型：
模型正确性
模型完备性
模型一致性
模型可实现性
56
 有关模型正确性的问题：




对实体对象的分类，用户是否能够理解?
抽象类是否对应到用户层的定义?
是否所有的描述均符合用户的定义?
是否所有的实体对象和边界对象都使用了有实际含义的
名词短语进行了命名?
 是否所有的用例和控制对象都使用了有意义的动词短语
进行了命名?
 是否所有的错误用例都已经描述和处理?
57
有关模型完备性的问题：
 每一个对象是否有用例用到它？创建、修改或
删除该对象的用例是哪些？
 每一个属性的类型是什么？它应进行修饰吗？
 每一个关联何时被用到？其重复性的选择原则
是什么？该关联使用那一种连接？
 每一个控制对象是否具有必要的关联，以连接
到用例中相关的其他对象？
58
有关模型一致性的问题：
 是否有多个类或多个用例同名？
 名字相近的实体（如类、对象、属性）能够相
互区别吗？
 在同一泛化层次是否存在相似属性和关联的对
象？
59
有关模型可实现性的问题：
 在该系统中性能需求和可靠性需求是否满足？
 在选定硬件上运行原型是否可以确定需求？
60
面向对象的需求分析(实例)
1）分析使用场景，画 Use
Case
2）标识对象类
3）画Class对象类图
4）组织类结构（继承、聚合关系）
确定系统结构
系统结构：
体现在实体之间的关系上
5）定义主题（子系统）
6）画Sequence顺序图（轨迹图）
7）画State Transition状态图
8）画Collaboration协作图
确定系统行为
系统行为：
体现在作用于实体属性的操作上
62
面向对象的需求分析(实例)
1) 分析使用场景 (Use Case)
从参与者入手，提供参与者与系统交互功能的形式描述。以
SafeHome的软件为例，分析系统的三个参与者：
房主、传感器、监控响应子系统（控制警告和拨打电话）
SafeHome软件使得房主能够在安装时配置安全系统、监控所有和安全系统连接
的传感器以及通过包含在SafeHome控制面板中的键盘和功能与房主交互。
在安装过程中，SafeHome控制面板被用于编程和配置系统，每个传感器被赋予
一个编号和类型，主人密码被编程以启动和关闭系统，而且当传感器事件发生时，
输入电话号码自动拨号，
当传感器事件被识别时，软件激活附属于系统上可发声的警报，在一定的时间
延时后，软件拨打监控系统服务的电话号码并提供位置信息，报告被监测到的事
件性质，电话号码将每隔20秒重拨一次，直至电话接通。
所有和SafeHome的交互，由用户交互子系统管理，该子系统读入通过键盘和功
能键提供的输入，在LCD显示屏上显示提示消息和系统状态。键盘交互采用下面的
形式:
63
面向对象的需求分析(实例)
Use-case模型，从高层逐步精化
高层描述：
精化描述：
输入
passwor
d
交互
房主
正确的
passwor
d
询问区
域状态
设置
房主
询问传感
器状态
询问
传感器
处理惊
慌
激活/失
活系统
64
面向对象的需求分析(实例)
2）标识类和对象
文法分析来标识对象的方法：
•从问题陈述中分离出所有的名词或名词短语，作为候选的对象类
•区分相同意思的的名词
选择对象的方法：
•外部实体：表示制造或消费系统的信息(如：系统、设备、人员)
•事物：表示信息的一部分（如：报告、显示、信号）
•发生的事或事件：在系统运行语境中被表示(如：性质改变、动作完成)
•角色：由系统交互的实体扮演（如：工程师、售货员、管理者）
•组织：与应用相关（如：分支机构、小组、部门）
•位置：建立系统整体功能的语境中被表示（如：制造厂、码头、学校）
•结构：被表示为抽象的对象类或相关类(如：计算机、交通工具、地图)
65
面向对象的需求分析(实例)
名词作为候选对象类
SafeHome软件使得房主能够在安装时配置安全系统、监控所有和
安全系统连接的传感器以及通过包含在SafeHome控制面板中的键盘和
功能与房主交互。
在安装过程中，SafeHome控制面板被用于编程和配置系统，每个
传感器被赋予一个编号和类型，主人密码被编程以启动和关闭系统，
而且当传感器事件发生时，输入电话号码自动拨号，
当传感器事件被识别时，软件激活附属于系统上可发声的警报，
在一定的时间延时后，软件拨打监控服务的电话号码并提供位置信息，
报告被监测到的事件性质，电话号码将每隔20秒重拨一次，直至电话
接通。
所有和SafeHome的交互，由用户交互子系统管理，该子系统读入
通过键盘和功能建提供的输入，在LCD显示屏上显示提示消息和系统状
态。
66
面向对象的需求分析(实例)
排列名词并分类对象
候选对象
房主
传感器
控制面板
安装过程
系统
编号类型
主人密码
电话号码
传感器事件
发声的警报
监控服务
一般分类
角色或外部实体
外部实体
外部实体
发生的事
事物
（明显属于传感器的属性）
事物
事物
发生的事
外部实体
组织
67
面向对象的需求分析(实例)
筛选候选的对象类
筛选的原则：
1.是系统有用的信息
2.是某个对象的必要的操作
3.有较多的属性
4.是问题中很多对象公共的属性
5.是问题中很多对象公共的操作
6.是外部实体
候选对象
筛选的原因
结果
房主
传感器
控制面板
安装过程
系统
编号类型
主人密码
电话号码
传感器事件
发声的警报
监控服务
不符合1、2
全部符合
全部符合
×
√
√
×
√
×
×
×
√
√
×
全部符合
不符合3
不符合3
不符合3
全部符合
除1外，全部符合
不符合1、2
68
面向对象的需求分析(实例)
3）画Class对象类图
系统
1：1
1：1
控制面板
包含→
1：1
选中→
1：1
传感器
1：m
1：1
产生↓
0：k
发生警报
认可↓
0：n
传感器事件
69
面向对象的需求分析(实例)
4）组织类结构（继承、聚合关系）
控制面板
传感器
进入传感器
烟雾传感器
运动传感器
一般/特殊关系
一般/特殊：表示类之间的继承关系
键盘区
屏幕
闪光的灯
聚合关系
聚合：表示对象实体间的组成关系
70
面向对象的需求分析(实例)
控制面板
注意：
只限聚合关系
5）定义主题（子系统）
控制键盘
子系统包
键盘区
屏幕
闪光的灯
包对外提供一组特
定的请求服务，
并可以进行包的引
用。
键区
功能区
LCD显示
图符
信息
71
面向对象的需求分析(实例)
6）画Sequence顺序图
房主
控制面板
系统
系统准备
登录passsword
启动鸣响
鸣响声音
激活/失活准备
选择驻留/离开
激活/失活传感器
传感器激活/失活
红灯停止请求
下一动作准备
红灯停止
72
面向对象的需求分析(实例)
7）画Collaboration协作图
选择驻留/离开
登录passsword
系统准备
控制面板
房主
下一动作准备
激活/失活准备
鸣响声音
传感器激活/失活
红灯停止
启动鸣响
激活/失活传感器
红灯停止请求
系统
73
面向对象的需求分析(实例)
8）画State Transition状态图
主动对象----具有动态性质的属性值
被动对象----表示静态性质的属性值
状态转换图：仅对每个对象主动状态转换的描述
控制面板类状态图
控制面板
比较password = 不正确
控制面板
静止状态
password 进入
控制面板
比较password = 不正确
重新进入状态
划分状态
控制面板
比较password = 正确
激活成功
选择状态
74