UML讲义--3业务建模(业务分析模型)(精选)
2012-2013 第二学期 11本 UML 第十二章 业务建模
第十二章 业务建模
1
一．业务建模概述
1．业务建模的目的: 软件系统的需求的充分性和必要性的要求。
▲ 通过业务建模可捕获较准确的用户需求，为后续的
软件分析和设计提供依据。因为系统开发人员往往不精
于业务，为使开发出的软件满足需求，必须准确掌握业 务过程。
▲
业务建模的另一个目的是分析和改善机构的业务过
三. UML业务建模扩展（续）
因此，用UML进行业务建模，就要UML进行扩展。要通过在UML 核心建模元素上定义版型来满足业务建模的需要。 比如 Eriksson-Penker 扩展方法中，用Activityd 的 《process》版型表示业务过程，用版型《resource》表示资源 等。 而在Rose 中对业务建模的扩展和 Eriksson-Penker 扩展方 法有所不同，Rose 中定义了业务参与者、业务工人、业务实体、 业务用例、机构单元等图符。
系统更好地支持机构中的业务。在对软件系统建模时， 业务模型可起到以下作用：
1. 帮助确定更适合机构中业务的软件系统。
2. 帮助确定功能需求。（例如建立Use Case）
3. 帮助确定非功能需求。（安全性、速度、可用性） 4. 作为分析设计软件系统的基础。（归纳类） 5. 帮助识别业务构件。（封装构件）
3．业务结构视图（Business Structure View）
可用UML的类图和对象图表示 4．业务行为视图（Business Behavior View） 可用UML的状态图、交互图和活动图表示。 核心视图是业务过程视图。（参照P128图12.19）
五. 从业务模型到软件模型
在创建软件模型之前，先定义业务模型，可以使软件
业务建模
活动图解说
起点 活动 迁移 条件
终点
活动图
——起点终点
活动的一种特殊形式，各自只有一个 起点 终点 ：画在左上角，只有离开的迁移 ：画在右下角，只有进入的迁移
对每一项活动，都存在从起点出发，经过它到终点的 路径。
活动图
——判定
和流程图里的有区别（空的，判定内容在前面活动中或者由泳道 直接选择） 第一个判断不用加判定 谨慎使用（误把活动当判定）
活动图
——并行（分叉与合并）
有分必有合 有分必有进 有合必有出 并行！＝同时
活动图
——对象流
特地指出对某些业务实体的操作，类似数据流图
活动图
——分层（1）
活动图
——分层（2）
Rose
PD
活动图
——分层（3）
出入平衡 顶层有起点终点，下层可以没有 展开和隐藏
责任分配原则
原则1. 专家（ Expert ）原则 原则2. 老板（Boss）原则 原则3：可视（Visibility）原则
责任分配原则（1）
——专家（ Expert ）原则
把责任分配给专家
资源决定责任－－各尽其才，各施其能
UMLChina训练
业务建模
Think
开发流程--
平 自外而内，逐步求精
台
业务建模
业务执行者 业务用例
业务工人
业务建模只是辅助环节 不是所有的项目都需要 也不一定和软件开发相关
业务实体
系统执行者
系统用例
对于软件开发的作用：描述现实，帮助发现软件需求
业务用例模型
——工具指南
UML建模讲义
Analysis vs. Design
• Analysis
– Focus on understanding the problem – Idealized design – Behavior – System Structure – Functional requirements – A small model
Ï ©µ ¶ ¥
¹ Ô± ÜÀí
½ ¨ ÐÅÓü Í Á¢ ¼
Sequence Diagram
A diagram that shows object interactions arranged in time sequence. In particular, it shows the objects participating in the interaction and the sequence of messages exchanged. Unlike a collaboration diagram, a sequence diagram includes time sequences but does not include object relationships. A sequence diagram can exist in a generic form (describes all possible scenarios) and in an instance form (describes one actual scenario). Sequence diagrams and collaboration diagrams express similar information, but show it in different ways.
<<subsystem>> Subsystem Name Interface
UML系统需求分析建模实例包括业务建模
UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。
该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。
二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。
- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。
- 管理员：拥有所有功能权限。
2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。
（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。
- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。
- 管理员登陆：管理员可以使用管理员账号登陆系统。
- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。
- 薪资管理：人事部门可以查看和修改员工薪资信息。
- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。
4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。
（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。
（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。
对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。
对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。
对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。
对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。
对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。
2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。
UML概述ppt课件精选全文
注释体 用于对UML实体进行文字描述
注释连接
注释连接将注释体与要描述的实体相连。说 明该注释体是对该实体所进行2-
协作图（通讯图）
协作图表示一组对象间关系以及交互活动
协作图可以认为是对象图的扩展，它增加了一些符号用于表 示对象间的交互。协作图和顺序图具有同构性。
指向源同步 消息
表示对象间从目的对象向源对象发送同步消息
指向目的的 同步消息
表示对象间从源对象向目的对象发送同步消息
注释体
注释连接
-35-
示例：协作图
-36-
活动图
活动图：通过动作来组织，主要用于描述某一方法、机制或 用例的内部行为
主要使用场合：业务建模、用例分析
-37-
活动图元语-1
活动 组合活动
1997.1公布 UML 1.0 合作伙伴
业
公
意见
众 1996.6和1996.10 UML 0.9&0.91
化
反
馈 OOPSLA95 Unified Method 0.8
标
准
Booch93 OMT-2
化
Booch91 OOSE
OMT-1 其他方法 统
一
UML基本图
静态模型 (系类统图结 构) class diagrams
转移
用于说明两个对象间存在某种关系，如满足某 个条件并当某一事件发生时，对象将从一个状 态变迁到另一个状态并同时执行一些活动
注释体
注释连接
示例：状态图
顺序图
顺序图：主要用于显示对象间的交互活动，但没有明确的交 互环境和对象状态
主要使用场合：系统分析（用例分析）、设计
【原创】UML学习1：业务过程建模（BusinessProcess）
【原创】UML学习1：业务过程建模（BusinessProcess）
多年来，公司⼀直守着那个破rose，UML2.0出来很久了，都没有认真学习下。
现在终于给⾃⼰加加油，学习下。
从⽤例图直接就到类图等，中间跨度太⼤，复杂点的东西不容易分析清楚。
个⼈⼀直对只⽤⽤例图来表现需求有意见，太简单，遗漏了太多东西。
⽤例图和需求⽂档对照看⼜很是⿇烦，毕竟⼀个屏幕看两个东西切换⾮常烦⼈。
UML有多种类型的图来表现业务的流程和过程的，⽐如活动图等。
但我喜欢在⼀张图上把不同维度的流程关键点都标注出来。
所以今天先学习下业务流程图的UML画法。
⼯具选择 Enterprise Architect。
业务流程模型通常定义了以下内容：
◇说明过程的⽬标或原因
◇具体的输⼊
◇具体的输出
◇资源消耗情况
◇活动在某些顺序执⾏和事件驱动的过程
业务流程：⼀个指定序列的⼯作活动，跨越了时间和地点，有开始和结束，明确的投⼊和产出。
图标如下
图中“⽤户”驱动的为“查询”事件，事件有⾃⼰独有的图标是个不错想法。
“⽬标”这个版型做为业务流程模型的基本内容，也给理解上带来了很⼤⽅便。
这个图上还有些领域建模的影⼦，⽐如购物项和购物车。
正是我喜欢的风格。
可能有⼈不喜欢我的这些想法。
但UML只是⼀个描述语⾔，能对⾃⼰有所帮助就可以了。
语⾔只是表达思想的⼯具，思想可不要被约束住了哦，呵呵。
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建模语言 ppt课件
2021/3/26
20 UML建模语言 ppt课件
手机类图案例分析2
请用UML类图描述如下关系： • 每个品牌的手机开关机的功能相同 • 每个品牌备wifi功能,但是普通手
机不具备此功能、而有些手机具有蓝牙的功能 • 所有手机都可以打电话,发短信
2021/3/26
21 UML建模语言 ppt课件
时序图（Sequence Diagram）
• 时序图（Sequence Diagram）是强调消息时间 顺序的交互图。时序图描述类系统中类和类之间 的交互，它将这些交互建模成消息交换。时序图 是一个模型，用于描述对象组如何随着时间在某 些行为方面进行协作。
目
1. UML介绍
录
2. 用例图
3. 类图
4. 顺序图
5. 状态图
UML介绍
• 什么是软件危机 • 什么是软件工程 • UML概念、发展、意义
2021/3/26
2 UML建模语言 ppt课件
UML用例图
• 用例图概述 • 用例图包含的2元素4关系 • 用例图实例：京东商城用例图
2021/3/26
}
2021/3/26
14 UML建模语言 ppt课件
类图—泛化关系(generalization）
• 泛化关系实际上就是继承关系，他是依赖关系的 特例
public abstract class DaoSupport{ public void save(Object entity){ } public void delete(Object id){ }
单向一对 一关系
Person 1
-card IDCard 1
双向一对 一关系
Person -person 1