UML建模实例
3. 用例建模的优势
• 完全站在用户的角度描述系统 – – – – • 将被定义的系统看成黑匣子，不考虑内部实现问题． 定义了系统具有的参与者，他们都将与系统有交互． 描述了参与者的所有行为 用例图可展示被定义系统的整体情况
将需求与设计做了比较彻底的分离 – 用例模型主要用于表述系统的功能性需求（系统的设 计主要由对象模型来表述） – 每一个用例描述的是一个完整的系统服务，容易被用 户理解，有利于设计者与用户间的沟通．
•避免二义性语义
好的需求定义应该是无二义性的，即不同的人对于同一需求的理解 应该是一致的。
如何确定用例间的关系
包含：提取公共交互，提高复用 泛化：同一业务目的的不同实现技术
扩展：“冻结”基用例以保持稳定
包含(inclusion) ：是指基础用例会用到的包含用例，具体地
讲，就是将包含用例的事件流插入到基础用例的事件流中。 包含用例是可重用的用例──是多个用例的公共用例。
第四章
实例学习
----一个餐馆系统的业务建模
南开大学软件学院
1
本章目标
使用面向对象分析方法和UML完成一个业务建模 典型实例：餐馆系统
南开大学软件学院
2
一、餐馆系统管理
• 当前系统使用手工方式完成用餐预定，预约单 格式：
当前主要完成的功能包括
• 预约信息记录在一张纸片上 – 联系人的姓名和电话号码 – 就餐人数: ‘餐桌占用’ • ‘未预约就餐’ 也需要记录 – 只记录就餐人数 • 可以预定指定的餐桌 • 可取消预约信息 – 在预约单上划掉已有的预约记录
3、调整与检查用例模型
在用例模型中除了参与者和用例之间的关系外，还要描 述参与者与参与者之间的泛化(generalization)、用例和用例 之间的包含(include)、扩展(extend)和泛化(generalization)关 系。 通过调整把一些公共的信息抽取出来重用，使得用例模 型更易于维护。但要注意模型调整通常都是在建模后期完 成，为的是避免不必要的复杂化．
泛化(generalization)：描述同一业务目标的不同实现。当 多个用例共同拥有一种类似的结构和行为的时候，可以将它 们的共性抽象成为父用例，其他的用例作为泛化关系中的子 用例。
扩展(extend)： 将扩展用例的事件流在一定的条件下按照相应的 扩展点插入到基础用例中。
基础用例不必知道扩 展用例的任何细节， 它仅为其提供扩展点 扩展用例的行为是否 被执行要取决于主事 件流中的判定点。
用户界面原型
• 写用例时, 需要给出一个用户界面的粗略构思， 这对今后的设计是有用的。
界面可只包含要显示的内容和方式，其他暂不考虑。
四、用例模型的调整与优化
找出共享功能
• 不同的用例可能有交融的部分 • E.g. “记录到达”: – 领班输入当前日期 – 系统显示当天预约 – 领班确认一个预约已到达 – 系统记录这些并更新显示 • 前两步与‘记录预约’是共享的（尽管属于不同的 参与者）
用IT替代原系统：定义第一次迭代
• 第一次迭代应能实现一个最简可用的系统 • 基本功能: – 记录预约 – 更新预约单的信息 • 系统应能够替代手工制单操作
二、用例建模
创建用例模型的基本步骤： 1．定义系统 2．确定参与者 3．确定用例 4．描述用例 5．定义用例间的关系 6．确认模型
完成最初的用例图
七、用例建模中包含技术
1.确定参与者(Actor) • 参与者是指与系统交互的人或其它系统 • 参与者代表一种角色，而不是具体的某个人 可通过回答下列问题确定执行者： 谁使用系统的主要功能？ 谁需要系统对他们日常工作的支持？ 谁需要维护、管理和维持系统的日常运行 ？ 系统需要控制哪些硬件设备？ 系统需要与哪些其它系统交互？ 哪些人/系统对系统产生的结果感兴趣？
这里有一个新 的参与者是”员 工“，他是已有 参与者通过泛 化产生的。
用例扩展
用例扩展是表示用例间所具有的依赖关系。如‘ 记录未预约’ 顾客的基本事件流程为： 1. 领班执行”显示预约“用例 2. 领班输入时间、用餐人数和分配的餐桌 3. 系统记录并显示新预约 • 该用例与”记录到达”用例有太多重叠，能否用包 含依赖性来描述呢？ •
领域词汇表
建立领域词汇表可以对今后的描述进行规范。 • 预约单(Booking): 针对一个餐桌的就餐预约 • 就餐人数(Covers): 对于就餐预约中的人数说明 • 顾客（Customer): 提出预约就餐的人 • 预约（Reservation）: 预约的一次就餐 • 未预约（Walk-in）: 没有提前预约的一次就餐 • 位子（Places):一个餐桌能够就坐的数量
对模型检查的重点
•功能需求的完备性
检查是否还有系统功能没有被记录在现有的用例模型中，抽象一些 新的用例或是归纳到原有用例中
•模型是否易于理解
考察模型是否易于被不同的涉众所理解 ，可能需要修改用例的粒度、 个数以及模型元素之间的关系复杂程度 等内容
•是否存在不一致性
要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在 模型内部产生不一致性。
作业2
对一个简化了的银行储蓄账户管理系统进行业务建模。该系 统可完成在银行的柜台上对客户办理活期储蓄业务。系统 的需求陈述如下： 一个客户可以在多个银行中开设账户，一个客户也可在 同一银行中开设多个不同的账户。 客户可以通过银行职员进行开户、存款、取款、转账、 注销账户等活动。其中转账指客户将自己的某个账户上 的钱款转入同一银行的不同账户（称为银行内转账）或 转入不同银行的账户（称为银行间转账）。 系统管理员负责系统的账户管理及业务报表的生成。 完成：确定参与者，确定用例，画出用例模型图，给出开户和 取款事件的基本流程描述。
标识包含依赖关系
• UML可表现出两个用例之间具有’依赖‘的这种包 含关系， 这时需要用规定的’依赖‘符号来标识
:
表示：”记录预约 “用例中包含着” 显示预约“用例。 或称”记录预约“ 用例与”显示预约 “用例有包含依赖 关系。
参与者泛化
结合前面的用例图，可以将包含“显示预约”用例的用例 图替换：
2.确定用例
针对每个参与者从以下问题入手： 参与者为什么要使用该系统或需要系统提供哪些功能？ 参与者是否会在系统中创建、修改、删除、访问、存储 数据？若是的话，参与者又是如何来完成这些操作的？ 参与者是否会将外部的பைடு நூலகம்些事件通知给该系统？ 系统是否会将内部的某些事件通知该参与者？
会出现的情况 对同一个项目，不同的开发者选取的用例数 可能不同。 例如一个10人年规模的项目，有人选取了20 个用例，有人选用了100个用例。 似乎20个太少，而100个太多，因此需要在 项目建模中找到一个最好或较好的用例模型。
扩展用例举例：
用例与扩展用例的区别 ①相对于基础用例，扩展用例是可选的，而包含 用例则不是。 ②如果缺少扩展用例，基础用例还是完整的，而 缺少包含用例，则基础用例就不完整了。 ③扩展用例的执行需要满足某种条件，而包含用 例不需要。 ④扩展用例的执行会改变基础用例的行为，而包 含用例不会。
八、领域建模
描述用例---“记录预约”可选事件流程
• 在“记录预约”时若没有餐桌，可选流程: 1 接待员输入预约日期 2 系统显示该日的预约 3 没有可用餐桌: 用例终止
描述用例---“记录预约”可选事件流程
在“记录预约”时餐桌过小，例外流程 1. 接待员输入要求预约的日期； 2. 系统显示该日的预约； 3. 接待员输入输入预约人详细信息； 4. 发现用餐人数多于餐桌可容纳数，系统发出警 告并询问是否继续预约； 5. 回答“no”预约终止 6. 回答“yes”预约将被记录，并附警告标志
• 领域建模是对业务领域描述，并用模型方式展 示，重要的是用该领域的术语进行描述。 • 它是一个真实世界的模型 – 类似于实体关系模型（协助设计者理解） • 该模型记录像是一个类图 • 便于‘Seamless development’ – 对于分析和设计使用同一种注释 – 设计可以是从初始的领域模型中演化而来
综合用例模型
将以上各模型综合起来，完成整体用例图：
六、关于用例模型的价值
１．从使用层面看
任何参与系统功能活动的人都需要用例模型： 客户：因用例模型指明了系统的功能，描述了系统将如 何使用。客户积极参与用例建模十分重要。 开发者：用例模型可帮助他们理解系统要做什么，同时 为以后的其它模型建模、结构设计、实现等提供依据。 集成测试和系统测试人员：根据用例来测试系统，以验 证系统是否完成了用例指定的功能。
２．从实质层面看
用例模型描述的是参与者(Actor)所理解的系统功能。 描述了待开发系统的功能需求。 用例模型由用例图组成，用例图展示了执行者、 用例以及它们之间的关系。 用例通常用正文和活动图描述。 一个用例模型可由若干幅用例图组成。一幅用例 图包含的模型元素有系统、执行者、用例，以及 表示它们间的不同关系，如关联、扩展、包含、 泛化等。
经分析后用扩展依赖比较合适
•因为并不是每次执行’记录到达‘要执行的内容，但 在某种情况下‘记录到达’ 用例可以被’记录未预约‘用 例扩。因此有：
注意：包含依赖和扩 展依赖关系可以通过 用例描述加以区别！
五、完用例模型
完成其他两个用例模型
“取消预约”用例基本事件流程： 1. 接待员选择要求取消的预约 2. 接待员取消该预约 3. 系统询问接待员是否确认取消 4. 回答“是”，记录取消并显示。 “调换餐桌”用例基本事件流程： 1. 领班选择需调换餐桌预约 2. 领班改变该预约餐桌分配 3. 系统记录改变并更新显示
• 找出用例，找出参与者并描述他们都做什么， 画出初始用例图：
用例包括： •记录预约 •取消预约 参与者包括： •前台接待员 •领班 •记录到达 •调换餐桌
三、描述用例 “记录预约”基本事件流程
• 对于 “记录预约”正常情况完成: 1 接待员输入要预约的日期 2 系统显示该日的预约 3 接待员输入具体细项 4 系统记录并显示新的预约
UML系统需求分析建模实例(包括业务建模)
系统用例几乎总是以黑盒形式编 写的。它们描述了软件系统之外 的参与者如何与将被设计的系统 进行交互。系统用例详细阐明了 系统需求。系统用例模型的目的 是从涉众的角度说明需求，而不 是设计如何满足需求。
业务用例图中，可以让业务参与者【业 在系统用例图中，让参与者与用 务执行者】和业务角色【业务工人】与 例进行交互。 业务用例进行交互。
做专业的企业，做专业的事情，让自 己专业 起来。2 020年1 2月上 午12时3 5分20. 12.200: 35Dece mber 2, 2020
时间是人类发展的空间。2020年12月2 日星期 三12时 35分4 秒00:35: 042 December 2020
科学，你是国力的灵魂；同时又是社 会发展 的标志 。上午1 2时35 分4秒上 午12时 35分00 :35:042 0.12.2
原始需求愿景
1. 为员工提供账务的自动化办理，提高办 事效率，方便员工。
2. 方便财务部门管理好账务信息。
涉众分析
涉众
解释
期望
员工
公司的正式录用雇员 通过网上办理账务业务申 请，计算机控制流程
部门经理 部门负责人，负责审 方便审核操作，通过计算 核员工提交的申请 机代替原来的手工审核方 式。
公司主任 公司负责人，负责 2 方便审核操作，通过计算
次审核员工提交的申 机代替原来的手工审核方
请
式，界面友好易用。
财务主任 公司财务部门负责人，通过计算机转账的方式替 负责发放报账款项 代原来的人为付款方式。
业务用例获取（1）
定义：
" 业务用例从一个外部的，增加值的角度来描 述一个业务过程。为了给这个业务的涉众创造 价值，业务用例是超越组织边界的业务过程， 很可能包括合作伙伴和供应商。“
UML实例UML案例(完整建模)(汽车租赁系统)
theWorkRecord : WorkRecord
系统的状态图
系统的活动图
customer request Employee check the request no new request store the request have new request handle new request
Manager Interface
Skill Worker
系统功能需求
① ② ③ ④ 满足上述需求的系统主要包括以下模块： 基本数据维护模块 基本业务模块 数据库管理模块 信息查询模块
基本数据维护模块
① ② ③ ④ 基本数据维护模块包括的主要功能模块： 添加车辆信息 修改车辆信息 添加员工信息 修改员工数据
基本业务模块
① ② ③ ④ 基本业务模块包含的功能： 用户填写预定申请 工作人员处理预定请求 技术人员填写服务记录 工作人员处理还车
建立UML模型框架
选择J2EE模式
系统的用例图
① ② 创建用例图之前首先需要确定参与者。 系统中的参与者主要有两类： 客户 公司职员
系统的用例图
1. 客户参与的用例图 2. 公司职员参与的用例图
客户参与的用例图
公司职员参与的用例图
系统的时序图
1. 2. 3. 4. 管理人员开展工作的时序图 客户预订车辆的时序图 客户取车的时序图 客户还车的时序图
数据库模块
① ② ③ ④ 数据库模块的功能： 客户信息管理 车辆信息管理 租赁信息管理 职员信息管理
信息查询模块
① ② ③ ④
信息查询模块是查询数据库中的相关信息， 包括： 查询客户信息 查询职员信息 查询车辆信息 查询客户记录
UML系统需求分析建模实例包括业务建模
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
uml建模案例
uml建模案例UML（Unified Modeling Language）是一种软件工程的建模语言，用于描述、分析和设计软件系统。
它提供了一套图形化的表示法，用于可视化和概括软件系统的各个方面，包括结构、行为和交互等。
以下是一个简单的 UML 建模案例，以一个图书馆管理系统为例：首先，我们需要定义系统的主要角色。
在这个案例中，主要角色有图书馆管理员、读者和图书。
接下来，我们可以开始构建类图，用于描述系统中的类及其之间的关系。
我们可以创建以下类：1. 图书类（Book）：包含图书的相关信息，如书名、作者、出版社等。
2. 读者类（Reader）：包含读者的相关信息，如姓名、年龄、地址等。
3. 图书馆管理员类（Librarian）：包含管理员的相关信息，如姓名、工号等。
该类可以包含一些操作，例如借书、还书等。
4. 图书管理系统类（LibraryManagementSystem）：负责管理图书、读者和管理员。
该类可以包含一些操作，如添加图书、删除图书、注册读者、借书、还书等。
接下来，我们可以定义类之间的关系。
在这个案例中，可以定义如下关系：1. 图书与读者之间的关系：读者可以借阅图书，每位读者可以借阅多本图书，而每本图书只能被一个读者借阅。
2. 图书与图书馆管理员之间的关系：管理员可以管理图书，例如添加图书、删除图书等操作。
3. 读者与图书馆管理员之间的关系：管理员可以注册读者，读者可以向管理员借书、还书。
最后，我们可以根据需求进一步细化类的行为和交互。
例如，根据借书和还书的需求，可以设计用例图，描述用户与系统之间的交互流程。
在用例图中，我们可以定义以下用例：1. 注册读者：读者通过系统界面提供个人信息进行注册。
2. 添加图书：管理员通过系统界面提供图书信息进行添加。
3. 借书：读者通过系统界面搜索图书并进行借书操作。
4. 还书：读者通过系统界面搜索已借阅的图书并进行还书操作。
以上仅为一个简单的UML 建模案例，实际情况可能更为复杂，涉及更多的类和关系。
uml建模实例100例
uml建模实例100例UML（统一建模语言）是一种用于软件开发的标准建模语言，它可以帮助开发人员更好地理解、设计和实现软件系统。
下面是100个UML建模实例。
1. 用例图：描述系统功能和外部用户的行为。
2. 活动图：描述系统中的过程和活动，通常用来描述系统的业务流程。
3. 类图：描述系统中的类、属性和方法、关系等。
4. 对象图：描述系统中的对象及其关系。
5. 状态图：描述系统中的对象或类的状态和状态转换。
6. 序列图：描述系统中的对象或类之间的交互过程。
7. 协作图：描述系统中的对象或类之间的协作过程。
8. 构件图：描述系统的组成部分和它们之间的关系。
9. 部署图：描述系统的物理部署结构和组件之间的关系。
10. 通信图：描述系统中的对象之间的消息传递。
11. 包图：描述系统中的包和它们之间的关系。
12. 组合结构图：描述系统中的组成部分和它们之间的组合关系。
13. 时序图：描述系统中的对象或类之间的时间关系。
14. 交互概述图：描述系统中的对象或类之间的协作过程。
15. 系统顺序图：描述系统中的对象或类之间的时间关系。
16. 概念图：描述系统中的概念和它们之间的关系。
17. 数据流图：描述系统中的数据流和处理过程。
18. 流程图：描述系统中的过程和流程。
19. 参与者图：描述系统中的参与者和它们之间的关系。
20. 视图图：描述系统中的视图和它们之间的关系。
21. 规则图：描述系统中的规则和它们之间的关系。
22. 用例图扩展点：描述用例图中的扩展点和它们之间的关系。
23. 活动图扩展点：描述活动图中的扩展点和它们之间的关系。
24. 类图扩展点：描述类图中的扩展点和它们之间的关系。
25. 对象图扩展点：描述对象图中的扩展点和它们之间的关系。
26. 状态图扩展点：描述状态图中的扩展点和它们之间的关系。
27. 序列图扩展点：描述序列图中的扩展点和它们之间的关系。
28. 协作图扩展点：描述协作图中的扩展点和它们之间的关系。
UML建模实例分析PPT课件
UML建模 实例分析
-
1
电梯控制监视系统
背景
18层楼，2部电梯 （m层楼，n部电梯）
需求
控制：电梯上下运行载客至指定楼层 监视：当前电梯位置及状态
-
2
主要需求描述
初始所有电梯停在1楼，处于等待服务 状态
乘客通过按动每层楼的按钮呼叫电梯 当电梯到达所请求的楼层的时候，它
将打开门5秒钟，然后关上门 乘客通过按动电梯内控制面板上的按
-
14
课内实验
要求： 学习体系结构设计思路 掌握UML模型图画法（用例图、类图、
活动图、状态图、协作图、序列图） 提交设计说明文档
-
15
钮来与电梯系统进行交互
-
3
主要需求描述
如果乘客在电梯内按了去第X层的按钮， 电梯将移向第X层
如果没有新的呼叫，电梯将停在最后 到达的楼层
其他更多需求描述
中途呼叫请求的处理 多部电梯响应的协调 服务效率与能耗的平衡
-
4
建模总流程
需求分析 关键问题识别 体系结构设计 初始模型设计 主体模型设计 模型评估与改进 模型细化与完善
-
8
初始模型设计
目的：以粗颗粒度、粗线条方式来对 系统进行初步设计
途径：没有固定的套路，根据所设计 的系统特点，可以有不同的构思方法
一般情况下，可以从用例图、类图、 活动图开始着手
-
9
用例图 类图 活动图 状态图 协作图 序列图
主体模型设计
-
10
模型评估与改进
模型是否正确 模型是否一致 模型是否便于维护 模型是否能进一步改进
-
5
需求分析 明确系统边界
哪些该做，哪些不该做
UML业务建模实例分析四例
UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。
我们在日常生活中也经常和ATM打交道。
本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
图5.1 自动取款机（ATM）系统用例图银行储户在ATM机上完成取款、存款及其他业务。
图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。
帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。
六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。
getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。
getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。
getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
UML建模案例——我的一位朋友结婚了
UML建模案例——我的一位朋友结婚了案例：我的一位朋友结婚了1、引入案例这是人们日常生活中一件很普通的事情，但这只是事情的结果，这其中隐藏着很多活动和过程。
这就需要经过有效地分析和设计过程来描述，可以从不同的角度进行探讨。
A. 这里面有什么东西?要分析问题，首先就是要找到问题中所包含的事物。
在本案例中，可能存在月老、小伙、姑娘、恋人、玫瑰花等各种人、物或者事件。
B. 每个东西看上去是什么样的?找到这些事物后，下一步就要分析每个事物的特征，以认识和理解事物本质。
在本案例中，每个事物可能的特征有：月老一一看上去有些年纪了、挺热心；小伙一一看上去很强壮、很诚实；姑娘——看上去很漂亮，还很温柔；恋人一一看上去很黏糊，最终结婚了；玫瑰花——火红火红的，难怪姑娘动情了。
C. 每个东西能做什么?认识了这些事物后，下面就要分析这些事物的能力，以完成特定的事情。
在本案例中，每个事物的能力有：月老一一牵线搭桥，介绍两人认识；小伙一一追求献花，表达爱意；姑娘一一仰慕倾情，以身相许；恋人一一拍拖，结婚；玫瑰花一一令姑娘心动，传情示爱。
D. 这些东西都呆在什么地方?分析完这些事物本身的特征和能力之后，下面就要安排这些事物出场，为此首先需要定义每个事物所处的位置。
在本案例中，比如：月老可能在婚介所或交友网站；小伙可能在软件园工作；姑娘可能在医院工作；恋人可能出现在电影院；玫瑰花可以在花店，也可以在小伙或姑娘手中。
E. 这些东西之间有什么关系?安排好所有事物后，为了能够有效地完成事情，还需要分析它们彼此之间的关系，以便彼此合作。
在本案例中，可能的关系如表1-1所示。
F. 这些东西是怎么完成整个事情的?最后就是我们的重头戏，要利用前面的那些事物以及事物之间的关系，完成整件事情。
完成这个案例的过程如下所示:（1）月老牵线搭桥，介绍小伙和姑娘认识。
（2）姑娘和小伙一见钟情，成为一对恋人。
（3）一对恋人开始拍拖。
（4）小伙用献花表达对姑娘的爱意。
uml建模实例
问题分析-2
C. 每个东东能做点什么用？
月老：牵线搭桥，介绍认识 小伙：追求献花，表达爱意 姑娘：仰慕倾情，以身相许 恋人：拍拖，…，结婚 玫瑰花：令姑娘头晕，传情示爱
问题分析-3
D. 这些东东都呆在什么地方？
月老：婚介所，交友网站 小伙：软件园，住唐家 姑娘：人民医院，住新香洲 恋人：情侣路，电影院， … 玫瑰花：花店里，小伙手中，姑娘手中
递交 喜悦 说" 嫁给我吧! "
惊喜
晕倒பைடு நூலகம்
同意
理清头绪的协作图
5. 通知见面 1. 邀请见面 : 月老 2. 同意见面 6. 通知见面 4. 同意见面 3. 邀请见面 7. 约会 : 小伙 8. 见面 : 姑娘
定点观察的状态图
首次见面( 一见钟情 ) 初恋 首次亲吻( 倾情 ) 热恋
和好( 愉快 ) 不愉快( 伤感 ) 和好( 愉快 ) 不愉快( 伤感 ) 苦恋 首次??( 甜...
月老牵线搭桥，介绍小伙和姑娘认识 姑娘和小伙一见钟情，成为一对恋人 一对恋人开始拍拖 小伙追求献花，表达对姑娘的爱意 姑娘收到999火红玫瑰，激动得头晕目眩 小伙真心求婚，姑娘以身相许 一对恋人终于走入婚姻殿堂
—上升到面向对象— 用面向对象观点观看事物
用对象观点认识事物
A.这里面有什么东东？ 类与对象 B.每个东东看上去是什么样的？ 类的属性 C.每个东东能做点什么用？ 类的方法 D.这些东东都呆在什么地方？ 类的行为、状态、部署 E.这些东东之间有什么关系？ 类间的关联 F.这些东东是怎么成事的？ 类间的交互
B C F
UML建模参考样例1
目录1．系统软件重构分析 (2)2．系统模块时序图 (2)2．1 managestatute模块 (2)2．1．1 managestatuteSD.createstatute (2)2．1．2 managestatuteSD.modifystatute (3)2．1．3 managestatuteSD.querystatute (4)2．2 manageinspectionplan模块 (5)2．2．1 manageinspection.creat (6)2．2．2 manageinspection.modify (6)2．2．3 manageinspection.query (7)2．3 managecheckrecord模块 (8)2．3．1 managecheckrecord (9)3．系统模块活动图 (10)3．1 managestatute模块 (10)3．2 manageinspectionplan模块 (11)3．3 managecheckrecord模块 (11)4. 系统模块状态图 (12)4.1 enterprisecheckedstatechart(GMP) (12)4.2 statutestatechart (13)5. 整体系统部署图 (14)5.1 deployment diagram (14)6．系统软件重构建模总结 (20)1．系统软件重构分析本系统用于药店、药品检查评定工程,采用的C/S即客户端/服务器端的架构方式，系统软件后台数据管理易学好用，可维护性强，对系统性能要求较低。
本系统有三类用户，即管理员、检查员和统计员。
系统要实现用户管理模块、系统管理模块、检查准备模块、检查执行模块和检查统计模块等功能。
管理员通过对用户信息进行增、删、查、改操作进行用户信息管理。
对受检单位进行设置，对法规、法规条例和监管单位等信息进行增加、删除、修改等操作。
浏览GMP认证检查评定标准和GSP认证检查评定标准,按照这些标准对受检单位进行检查.安排检查任务、修订之前已保存的检查任务，选取检查任务和复检任务进行执行。