组合关系显然已经将类的关系清晰化了，因此无须对 其进行导航性描述。根据对需求的理解，book与 borrowrecord之间，应该是一个双向链接。因为，当浏 览书籍列表时，会希望看到某本书是否被借出；当有 人归还时，希望能从借阅记录中关联到book。

(3)确定约束 根据用户需要，我们有两个地方可以用约束来体现： 一是book对象创建之后就不能被删除，只能做修改， 因此在book类边上加上了一条用自由文本写的约束。 二是一本书要么属于计算机类，要门属于非计算机 类。因此要加一个“{xor}”约束。 (4)确定关联的限定符 由于这个系统是“个人图书管理系统”，因此特定 的一本书只有一本，所以只能被借一次，因此对于 一本书而言，只有一个Recordid与其对应，因此将添 加一个Recordid限定符。把限定符加入图3-25中，再 把类的职责(属性和方法)加入到类图后，得到的类图， 如图3-26所示。
5.业务员随后给他们准备好会议用纸（send follow-up letter）。
6.如果会议产生了一个问题陈述（statement of problem），咨询 顾问就根据问题陈述建立编写一个提案（Create proposal）并把 该提案发给客户（Send proposal to client）。
医院病房监护系统类图，在类图中标明类之间的关系：
值班护士
1 1
医生
1
病人
*
病历
1
1
监视
报警
*
病情报告
*
病历库
1 1
*
1
1
病症监视
1 1
1
*
1
报警信号
1
1
中央监护系统
1 1
1
*
病人病症信号
标准病症信号
*
1
标准病症信号库
首页 上页 下页 末页 退出
案例：一个咨询公司和该咨询公司会见一个客户时的业务过程：

因为是个人藏书，因此每本书都是唯一的，没有副本， 要么被借出，要么未被借出，因此对于每一本书籍来 说，要么只有一条借阅记录，要么没有借阅记录。 所有的书籍组成书籍列表，借阅记录刘表是由所有的 借阅记录组成。 通过上面的分析，可以得到信息补充的类图，即可得 到如图3-25所示的类模型。


图3-26 加入多重性的类图


3. 给类添加职责
当找到了反应问题域本质的主要类，并清理他们之 间的关系之后，就可以为这些类添加相应的职责。 类的职责包括以下两个内容：类所维护的信息(成员 变量)和类提供的行为(成员方法)。
在本阶段将主要的成员变量和成员方法标识出来， 以便更好的理解问题域。


书籍类：从需求描述中，可找到书名、类别、作者、 出版社；同时从统计的需要中，可得知“定价”也 是一个关键的成员变量。
Prepared a conference room Meet with the client send follow-up letter
[statement of problem] [no statement of problem]
Prepared a laptop
Create proposal Send proposal to client
2014-7-10
10
角色描述
通过分析可以初步识别出系统的用例为：中央监护，病症 监护，提供标准病症信号，病历管理，病情报告管理。顶层用 例图为：
中央监护
《使用》 病症监护 病人
值班护士
病情报 告管理 《使用》 病历管理 医生 《使用》
提供标准 病症信号
标准病症 信号库
2014-7-10
11
系统类图
Create proposal Send proposal to client
Sales Person Call client and setup appointment
Consultant
Corporate Technician
[appointment onsite] [appointment offsite ]
6.1.3
一个无人职守电梯升降的状态图
标识用例间的关系


下面以一个“棋牌馆管理系统”的局部用例模型为例，说 明用例之间的三种关系：包含关系、扩展关系、泛化关系 该系统的主要功能是：以Internet的形式向客户提供座位预 订服务，如果暂时无法获取座位信息时，允许客户进入 “等候队列“，当有人退订之后将及时通知客户。另外， 该系统还将为总台服务员提供座位安排以及结帐的功能， 要求能够支持现金和银行卡两种结帐方式。 在图中可以看到4种元素：参与者、用例、一个方框和一 些表示关系的连接线。前面已经介绍了参与者和用例的表 示法，不难知道该图中有客户、总台服务员和银联POS系 统3个参与者，还包括预订座位、安排座位、办理结帐等8 个用例。
1.公司业务员打电话给客户，确立一个约定（Call client and setup appointment）。
2.如果约定地点是在公司之内（appointment onsite），那么公司 中的技术人员就要为会面准备一间会议室（Prepared a conference room）。 3.如果约定地点是在公司之外（appointment offsite ），那么咨 询顾问就要用膝上电脑准备一份陈述报告（Prepared a laptop）。 4.咨询顾问和业务员与客户在约定的时间和地点见面（Meet with the client）。
2014-7-10
9
2、识实现有关的主要问题是什么？ （2）系统需要哪些输入/输出？这些输入/输出从何而来？到 哪里去？ （3）执行者需要系统提供哪些功能？ （4）执行者是否需要对系统中的信息进行读、创建、修改、 删除或存储？
通过分析可以初步识别出系统的用例为：中央监护，病症 监护，提供标准病症信号，病历管理，病情报告管理。顶层用 例图为：


图3-27 加入限定符和约束的类图
【举例】
IC卡电话包括3 个基本状态：“使用状态”、“未使用状 态”和“维修状态”。其中“使用状态”状态是一个复合 状态。 IC电话的连接过程： 当拿起电话打IC电话的时候，首先要插入IC卡，进行 IC卡的有效验证，验证通过才可以拨打电话，此时从最初 的“IC卡验证”状态转到“拨号”状态。如果电话接通， 则转到“连接”状态；在连接状态，如果对方也拿起听筒， 则转入“通话”状态，通话完毕转入“挂断”状态；如果 对方无人接听。则转入“挂断”状态。如果拨号时出现异 常情况，则挂断电话；如果挂断后重新拨号，电话又处于 “拨号”状态。如果此时取出IC卡，则IC电话转入“未使 用”状态。 “未使用状态”包含5个子状态，因为IC电话不能同时 处于两个不同的子状态中，所以这些子状态是顺序子状态。
Call client and setup appointment
[appointment onsite]
Prepared a conference room
Prepared a laptop
Meet with the client send follow-up letter
[no statement of problem] [statement of problem]


书籍列表类：书籍列表就是全部的藏书列表，其主 要的成员方法是新增、修改、查询（按关键字查 询）、统计（按特定时限统计册数与金额）。 借阅记录类：借阅人（朋友）、借阅时间。 借阅记录列表类：主要职责就是添加记录（借出）、 删除记录（归还）以及打印借阅记录 通过上面的分析，我们对这些概念类有了更深入的 了解，可以重新修改类，将这些信息加入原先的模 型中。同时，把关联的属性加入类模型后，得到如 图3-27所示的类图。 职责（属性，方法）的添加是一个循序渐进的过程， 在类分析，类设计时都是逐步对类模型进行完善的。
2014-7-10
2
2014-7-10
3
2014-7-10
4
案例
现有一医院病房监护系统，病症监视器安置在每个病 房，将病人的病症信号实时传送到中央监视系统进行分析 处理。在中心值班室里，值班护士使用中央监视系统对病 员的情况进行监控，根据医生的要求随时打印病人的病情 报告，定期更新病历，当病症出现异常时，系统会立即自 动报警, 并实时打印病人的病情报告，立及更新病历。 要求根据现场情景，对医院病房监护系统进行需求分 析， 建立系统的Use case model。
2014-7-10
8
角色描述
通过回答这六个问题以后，再进一步分析可以识别出本系统的四个 角色：值班护士，医生，病人，标准病症信号库。 角色描述模板
角色：病 人 角色职责： 提供病症信号 角色职责识别： 负责生成、实时提供 各种病症信号。 角色：医 生 角色职责： 对病人负责，负责 处理病情的变化 角色职责识别： (1)需要系统支持以完 成其日常工作 (2)对系统运行结果感 兴趣 角色：值班护士 角色职责： 负责监视病人的病 情变化 角色职责识别： (1)使用系统主要功能 (2)对系统运行结果感 兴趣 角色:标准病症信号库 角色职责： 负责向系统提供病症 信号的正常值 角色职责识别： (1)负责保持系统 正常运行 (2)与系统交互
2014-7-10
需求分析
首页
上页
下页
末页
退出 7
需求分析
三、用UML的静态建模机制定义并描述系统的静态结构 （一）建立系统的用例图 1、通过以下六个问题识别角色 (1)谁使用系统的主要功能？ (2)谁需要系统的支持以完成日常工作任务？
(3)谁负责维护，管理并保持系统正常运行？
(4)系统需要应付（或处理）哪些硬设备？ (5)系统需要和哪些外部系统交互？ (6)谁（或什么）对系统运行产生的结果（值）感兴趣？