UML 精粹：标准对象建模语言
2023-12-04 13:43:22 1 举报AI智能生成
登录查看完整内容
UML 精粹：标准对象建模语言
作者其他创作
大纲/内容
20210803-UML 精粹：标准对象建模语言简明指南
系统行为
Wait（等待）
Lock（上锁）
Open（打开）
3个状态
子主题
图10.1 一个简单的状态机图
一个状态到另一个状态的转移
转换（transition）
控制器举例
状态机图
把事件、警戒条件和活动放在状态框里面
内部活动（internalactivity）
转回到同一状态的转换
自转换（self-transition）
entry activity
无论何时进入一个状态都要执行
入口活动
exit activity
无论何时离开一个状态都要执行
出口活动
内部活动不触发入口活动和出口活动
两个活动
一个文本域的typing（输入中）状态的内部事件展示
内部活动
activity state
持续进行的活动
do/
do-活动
do-activity
术语
活动状态
图10.3 带活动的状态
若干状态
子状态
共享行为
超状态
若干状态共享共同的转换和内部活动
图10.4 带有嵌套子状态的超状态
若干正在并发运行
正交状态图
被分解
状态
history pseudostate
没有历史时
第一次进入
应该进入哪个状态
所指向的状态
历史伪状态
图10.5 并发正交状态
并发状态
嵌套switch
state pattern
创建状态类层次来处理状态的行为
每个状态都有一个状态子类
针对每一个事件的方法
转发给状态类
控制器
一个抽象类
覆盖状态有转换的特定事件方法
具体状态
顶层
层次
图10.7 图10.1的状态模式实现
状态模式
state table
捕获状态图信息为数据
图10.1的状态表
修改
无须重新编译
运行时状态表
状态表
3种方式
实现状态图
跨越若干用例的对象的行为
擅长
涉及许多对象协作的行为
和其他技能结合很有用
单个用例中的若干对象的行为
交互图
展示若干对象和用例的通用活动序列
活动图
例如
不擅长
何时使用状态图
《UML用户指南》[Booch，UML user]
《UML参考手册》[Rumbaugh，UML Reference]
更多资料
描述过程逻辑、业务流程和工作流的技术
区别
支持并行行为
类似于流程图
initialnode
开始动作
初始节点
fork
一个进入流
若干离开的并发流
填写订单
发送发票
交付
接收付款
可以
也可以
序列不相关
分叉
join
所有进入流到达结合时
离开流才会执行
结合
decision
分支
单个进入流
若干带警戒的外向流
每个外向流有一个警戒条件
判断
多个输入流
单个输出流
由判断开始的条件行为结束
合并
图11.1 一个简单的活动图
该流程
任何人
选择做事情的次序
允许
动作可以分解为子活动
子活动
可以实现为子活动或者类的方法
动作
图11.2 一张次级的活动图
展示子活动
耙子符号
语法class-name：：method-name
被调用的行为不是单个方法调用
在动作符号里写一个代码片段
方法上的调用
靶子符
分解一个动作
展示谁做什么
哪一个动作由哪一个类或组织单元执行
把活动图划分为分区
分区
简单的一维分区
这种风格
泳道
针对每一个维度层级划分行或列
二维网格
图11.4 活动图上的分区
time signal
因为时间的流逝而发生
财务周期中的月末
实时控制器的每一微秒
可以指示
时间信号
signal
该活动从一个外部进程接收一个事件
监听信号的活动
信号
在航班离开前2个小时
即使我收拾得足够快
还是不能离开
开始打包
直到出租车到达
图11.5 活动图上的信号
接收信号
不得不发送一个消息
等待回复才能继续
将获胜
终止其他流
第一个到达终止状态
两个流在竞赛
图11.6 发送和接收信号
发送信号
等待一个外部事件
一个进入它们的流
展示
流触发了接受
才开始监听
接受
创建一个令牌
传给下一个动作
动作执行
传给下一个
一个令牌进入
每一个向外的流上产生一个令牌
分叉处
每一个向里的令牌到达，没有任何事情发生，
直到所有令牌出现在结合处
结合处
令牌
两个动作之间的连接
流和边
flow
一个简单的箭头
流
edge
边上放一个类框
沿着边传送对象
边
连线上有困难
不必画一条穿过整张图的线
进入流一个
离开流一个
两者标签相同
必须成对使用
破坏了控制流的可视化
尽可能避免使用连接器
连接器
图11.7 展示边的4种方式
pin
为动作
展示参数信息
向外动作的输出参数
匹配
另一个动作的输入参数
确保
针脚
transformation
转换
图11.8 流上的变换
针脚和变换
expansion region
标记活动图的一个区域
动作为一个集合中的
每个条目执行一次
在该区域里
扩展区域
输出集合的条目数和输入集合的条目数相同
过滤器的角色
条目变少
图11.9 扩展区域
只有单个需要多次调用的动作
图11.10 扩展区域中的单个动作的速记
flow final
一个特定流的结束
不终止整个活动
流结束
图11.11 活动中的流结束
所有输入流到达一个结合
执行通过它的向外流
当每个输入流上的令牌都到达时，
它释放出一个它的输出流上的令牌
正式的说法
默认的
一个附加到结合上的布尔表达式
结合规格
图11.12 结合规格
支持和鼓励并行行为
何时使用活动图
http://www.daimi.au.dk/PetriNets/
communication diagrams
交互图的一种
强调
交互的各种参与者之间
数据链接
每一个参与者画成生命线并按垂直方向展示消息序列
不像序列图
通过画链接来展示参与者如何连接
使用编号来展示消息序列
允许自由放置参与者
collaborationdiagrams
被称为协作图
UML 1.x中
通信图
展示关联实例的链接
只在交互上下文中出现
瞬时链接
一个局部变量
«local» 链接
图12.1 中央控制的通信图
也可以在消息上放置字母
代表不同的控制线程
除了编号
图12.2 嵌套小数编号的通信图
依赖于个人偏好
强调调用序列时
序列图
强调链接时
何时使用通信图
part
把一个复杂的对象分解为部件
部件
小球-球窝表示法
供给和需求接口
组合结构
图13.1 展示TV Viewer及其接口的两种方式
generator
发生器部件
control
控制部件
类如何在内部分解为两个部件
name：class的形式命名
不是实例规格
不是用带下画线表示
用粗体表示
图13.2 组件的内部视图（来自Jim Rumbaugh的例子）
图13.3 带多个端口的组件
编译时分组
包
展示运行时分组
包和组合结构的区别
何时使用组合结构
图14.1 组件的表示法
till（收银台）使用sales message（销售消息）接口，通过消息队列连接到Sales Server（销售服务器）组件。该消息队列既供应salesmessage接口来和收银台交流，还需要该接口和服务器交流。服务器分解成两个主要组件，transaction processor（事务处理器）组件实现sales message接口，accounting driver组件和accounting system交流。
图14.2 组件图例子
不是一种技术
顾客要如何与软件发生关系
关注
顾客要能够每次购买一小片软件，能够像升级音响一样升级软件
新的小片能无缝地和旧的小片一起工作
按照他们自己的进度升级
难以管理
太多组件
“DLL地狱”
小心过细粒度的组件
组件
组件图
展示它们通过接口的相互关系
把组件分解为更低级别的结构
何时使用组件图
participant-name/role-name：class-name
命名体系
拍卖中，可以有一个卖家（seller）、一些买家（buyer）、许多要拍卖（lot）的货物和一些出价（offer）
被一个虚线的椭圆包围
椭圆代表拍卖协作
首先
协作中的所谓的类不是类
而是应用协作时要实现的角色（role）
其次
不是十分常见的类图
图15.1 带角色类图的协作
图15.2 拍卖协作的序列图
从协作到那些类的链接表明类如何扮演协作定义的各种角色
图15.3 协作发生
协作
一种有竞争力的图形类型
图15.4 展示JUnit（junit.org）中模式使用的非标准方式
何时使用协作
嫁接
其中的活动替换为了小的序列图
被活动图表示法打碎
展示控制流
交互概述图
图16.1 交互概述图
取决于哪一种图能更好地为你的目的服务
何时使用交互概念图
另一种形式的交互图
时间约束
焦点
咖啡壶的泵和电炉
泵开始工作和电炉开始工作之间的间隔至少要10秒
当盛水容器变成空的时，泵关闭
电炉不能继续打开超过15分钟
规则
图17.1 展示状态为线的时间图
图17.2 展示状态为区域的时间图
时间约束的可选方式
场景
时间图
展示不同对象上的状态改变之间的时间约束
何时使用时间图
统一建模语言
一组图形表示法
共同
元模型
特别是
面向对象（OO）风格建造的软件系统
描述和设计软件系统
帮助
由对象管理组织（OMG）控制
各公司组成的联盟
建立支持互操作性的标准
成立的目的
CORBA（通用对象请求代理架构）标准
OMG
比较开放的标准
UML 是什么
帮助沟通想法
展示所要做事情的可选方案
目的
草稿
编写代码之前画
正向工程
从已有代码建造UML图
帮助理解代码
解释系统的某些部分如何工作
不用展示每一个类
只需展示那些令人感兴趣的、在深入到代码之前值得讨论的类
逆向工程
完整性
蓝图
编程语言
三种模式
可以做正向和逆向工程的工具
双程（round-trip）工具
使用源代码本身作为存储器
把图当做代码的图形视角
无转换（tripless）工具
工具
不完整
强调重要信息
探索性的
全面
把编程缩减成简单的机械活动
定义性的
蓝图和草稿区别
MDA
使用UML作为编程语言的标准方法
由OMG控制
MDA使用UML作为其基本建模语言
模型驱动架构
PIM
Platform Independent Model
平台无关模型
PSM
Platform SpecificModel
针对特定执行环境
系统模型
是UML，也可以不是
平台特定模型
从PIM到PSM再到最终代码的过程
完全自动化
工作划分为两个
类似于MDA
Executable UML
不使用完全的UML标准
可执行UML
如何把可执行UML模型转换到特定编程平台
架构型（archetype
状态图
三种行为建模方法
software perspective
软件视角
conceptual perspective
对所研究领域概念的描述
概念视角
模型驱动架构和可执行UML
使用 UML 的方式
Jim Rumbaugh离开GE加盟Grady Booch所在的Rational
“以微软的方式”达成标准化
催化剂事件
在OOPSLA'95大会上
Grady和Jim
统一方法文档版本0.8
首次引发
各种组织一起提交了方法标准的建议书
UML文档版本1.0
第一次被
UML
1.1版本
官方的OMG标准
1.2完全是走走过场
1.3更加重要
1.4围绕组件和扩展机制添加了许多详细的概念
1.5添加了动作语义
1997年1月
GradyBooch、
Ivar Jacobson
和Jim Rumbaugh
功劳
UML 诞生史
notation
在模型中看到的图形
建模语言的图形语法
表示法
meta-model
一张定义语言概念的图
类图
表示法和元模型
13种官方图形类型
类、特性和关系
组件的结构和链接
类的运行时分解
组合机构图
工件部署到节点
部署图
实例的配置例子
对象图
编译时层次结构
包图
结构图
顺序和并性行为
用户如何和系统交互
用例图
对象在生命期中如何被时间改变
对象之间的交互
强调顺序
强调链接
序列图和活动图的混合
交互概念图
强调时间
行为图
图
UML图
descriptive rules
人们在实践中如何使用该语言来理解它的规则
描述性的
prescriptive rules
官方说明
什么是合法
什么是不合法
这门语言所发表言论的含义是什么
官方控制
强制性的
UML的规则
什么是合法的UML
展示复杂逻辑条件
用活动图代替
决策表会更加精练和清晰
情况比较复杂
决策表
仅有 UML 是不够的
基本形式的类图和序列图
开始使用一些更高级的类图表示法
掌握了上面
何处开始 UML
简介
从一堆OO分析和设计方法
混合了图形建模语言和描述如何开发软件的过程
RUP
一个过程
可以使用UML的过程框架
Rational统一过程
开发过程
基于活动来分解项目
需求分析
设计
编码
测试
不得不做某些活动
瀑布风格
根据功能子集来分解项目
处理1/4的需求
分析、设计、代码和测试
对这1/4做完整的软件生命周期
拥有了一个做了1/4所需功能的系统
结束时
第一个迭代
6个月结束时
完成一半功能的系统
再做第二个迭代
把一年分解为3个月的迭代
每一个发布又分解到若干迭代（iteration）
多个发布（release）
一个项目
增量、
螺旋、
演进
和极可意（Jacuzzi）
许多名字
McConnell
stageddelivery
先以瀑布风格做完分析和高级别设计
然后把编码和测试划分到迭代中
阶段交付
时间盒（time boxing）
强迫每个迭代有固定长度的时间
常见技能
迭代风格
automated regression test
快速检测任何可能引进的缺陷
xUnit家族测试框架
http://junit.org
自动化回归测试
refactoring
有纪律地改变现有软件的技能
一系列小的
行为保留
对代码基变换
http://www.refactoring.com
重构
continuous integration
保持团队同步
避免痛苦的集成周期
完全自动化的构建过程
核心
持续集成
迭代和瀑布过程
预测性和自适应计划
敏捷过程
项目初始估计
决定是否投入足够的资金来做细化阶段
初始（inception）阶段
识别项目的首要用例
迭代建造软件
最后
细化（elaboration）阶段
继续建造
开发足够发布的功能
构造（construction）阶段
各种后期阶段的活动
部署到数据中心、用户培训等
移交（transition）阶段
遵循4个阶段
Rational 统一过程
建造的系统的种类
使用的技术
团队的规模和分布
风险的本质
失败的后果
团队的工作风格
组织的文化
因素
改编过程以适合你的特定环境
表达面向对象设计
过程的结果
例子设计
模式
Gang of Four
23种设计模式
POSA1
POSA2
Core J2EE Patterns
Pont
书籍
为什么这样做的原因
还包含
不只是模型
为项目剪裁过程
人们如何与系统交互
用例
概念视角画类图
组织的工作流
展示软件如何与人类活动交互
为用例展示其上下文
一个概念
一个有趣的生命周期
各种状态和改变状态的事件
从软件视角展示软件中的类
它们如何互联
常用场景的
从用例中挑选最重要和最有趣的场景
CRC卡
使用
弄清楚软件中发生了什么
展示软件的大规模组织
有复杂生命历史的类
展示软件的物理布局
归档已经做的事情
描绘系统的逻辑路线
帮助我理解系统的逻辑块
看到依赖并保持依赖受控
不展示每个类上的每个操作，只展示帮助我理解内容的重要特性
支持这张类图
展示系统中最重要的交互
一些交互图
一张类图
包内部
如果一个类有复杂的生命周期行为
文档
查看处理复杂的方法时多个对象如何协作
理解遗留代码
为过程裁剪UML
Highsmith
Cockburn，agile]
敏捷社区
http://xprogramming.com
http://www.extremeprogramming.org
Beck and Fowler
极限编程（XP）
描述系统中的对象类型
存在于它们之间的各种静态关系
性质
操作
应用于对象连接方式的约束
展示类的
一个通用术语
性质（property）
操作（operation）
类的
覆盖
特性（feature
类的名字（粗体）
类的性质
类的操作
分为三栏
方框是类
关联
和泛化
类之间的两种关系
订单处理的例子
类的结构特性
类中的字段
粗略看做
两种十分不同的表示法
attribute
类方框中的一行文本
类如何引用属性
对应于编程语言中的字段名
name
公开的（+）
私有的（-）
visibility
一种对象可以被放进属性的限制
编程语言中的字段类型
type
multiplicity
创建期间没有指定值时新创建对象的值
default value
属性附加的性质
客户不可以修改该性质
{readOnly}
{property-string}
小的东西使用属性
属性
同一性质的两种不同表示法
一根两个类之间的实线
从源类到目标类
方向
性质的名称及多重性放在关联的目标端
链接到性质所属类型的类
目标端
两种不同表示法
更重要的类，使用关联
和关联
多少对象可以填充该性质
（一张订单必须有且只有一名顾客。）
1
可能有一名销售代表，
也可能没有销售代表
一名企业顾客
0..1
不需要下订单
但顾客下的订单数量没有上限
零
或者更多张订单
一名顾客
＊
最常见的多重性
任何正整数
或零
一个下限
或*（无限）
一个上限
使用一个数
如果下限和上限是同一个数
canasta纸牌游戏有2..4个玩家
更常见的多重性
可选的
下限0
Optional
强制的
下限为1
可能更多
Mandatory
单值的
上限为1
Single-valued
多值的
上限大于1
通常是*
Multivalued
多重性的术语
多重性
Car类有性质owner：Person[0..1]
cars性质
性质类型的复数形式
Person类有性质cars：Car[＊]
一对性质
关系可以用一句话来表达
动词短语给关联加标签
双向关联
类知道如何执行的动作
一个字符串
操作的参数列表
direction name : type = default value
输入（in）
输出（out）
兼有（inout）
默认
direction
parameter-list
返回值的类型
如果有的话
return-type
应用到给定操作的性质的值
property-string
操作的完整UML语法
修改器（modifier）
也称为命令
改变系统状态
查询（query）
不改变系统状态
辨别操作
返回来自字段的值
获取方法（getting method）
把值放进一个字段
设置方法（setting method）
方法
知识完全在类的内部
修改器是不是设置方法
对象上可以调用的某些东西
例程体
一个超类型有3个子类型
每一个子类型都覆盖超类型的getPrice操作
一个操作和4个实现它的方法
多态情况
操作和方法的区别
做生意时的个人和企业顾客
差异
放进一个通用的Customer类（超类型）中
超类
Personal Customer（个人顾客）
Corporate Customer（企业顾客）
子类
相似
典型例子
substitutability
可替换性
重要原则
高效使用继承
泛化
图中的注释
可以单独存在
也可以通过虚线链接到所注释的元素
可以出现在任何类型的图中
注解符
注释符和注释
dependency
如果改变一个元素的定义会导致改变其他类，两个元素之间就存在
依赖
一个类发送消息给另一个类
一个类拥有另一个类作为其数据的一部分
一个类把另一个类当成操作的参数
各种原因
任何发送给该类的消息可能都不再有效
如果一个类改变其接口
表示类到领域类
依赖只有一个方向
每一种都有特定的语义和关键词
源调用目标元素的操作
call
原创建目标的实例
create
源从目标诞生
dervie
源是目标的实例
instantiate
目标允许源访问目标的私有特性
permit
原生目标所定义的规格或接口的实现
realize
源可能是射击类
目标对应分析类
精化指不同语义级别的关系
refine
源可以替代目标
substitute
用于跟踪类似需求到类
或一个模型中的变更如何链接到其他地方
trace
源的实现需要目标
use
许多种依赖
最小化依赖
避免环状依赖
通用规则
例如当一个对象被传递给另一个对象作为参数
阐述瞬时的关系
允许你使用任何东西来描述约束
放进花括号（{}）
唯一的规则
断言（assertion）
决不应该为假的布尔陈述
假的唯一原因是存在bug
应用于操作
post-condition
操作执行后世界看起来应该像什么样子
我们做什么而不说我们怎么做的一种有用的方式
将接口从实现分离
后置条件
pre-condition
期望在执行操作前世界是什么样子
显式指出调用者负责检查
前置条件
关于类的断言
对于类的所有实例来说，这个不变式“总是”为真
不变式
3种特定的断言
exception
异常
契约设计
约束规则
UML的骨架
不要尝试使用所有可用的表示法
尽量把软件排除在讨论范围之外
集中于关键区域
不要为每个东西都画模型
被过度使用提示
何时使用类图
描述对象组在某些行为中如何协作
捕获单个场景的行为
我们有一个订单，打算调用其上的一个命令来计算它的价钱。为此，需要查看订单上的所有订单行条目，决定它们的价钱，价钱基于订单行的产品的定价规则。针对所有订单行条目做这个计算后，订单需要计算出一个整体的折扣，折扣规则和顾客有关
垂直地沿着页面朝下运行
消息也沿着页面向下排序
订单实例发送getQuantity和getProduct消息给订单行
每一个参与者有一条生命线
在交互中参与者何时是活动的
可选
每条生命线都有一根激活条
来自一个不确定的源
没有发送它的参与者
称为寻获消息（found message）
participant
name：Class
语法
参与者
交互图（interaction diagram）
把消息箭头直接画进参与者方框
“new”来标记它
创建一个参与者
大的×表示
一个消息箭头指向×
一个参与者显式删除另一个
生命线末端的×
删除自身
参与者的删除
创建和删除参与者
标记一小块序列图的方法
每个框有一个操作符
每一个片断可以有一个警戒条件
交互框
loop操作符
循环条件放在警戒条件的位置
循环
alt操作符
条件放在每一个片断之上
条件逻辑
opt操作符
只有一个区域
只有警戒条件为真的片断会执行
多选的一个片断
只有条件为真会执行
alt
该片段旨在所有条件为真时执行
opt
并行
每个片断并行运行
par
片断可以执行多次
警戒条件表示循环的条件
loop
关键区域
片断一次只有一个线程执行
region
否定
片断展示无效的交互
neg
引用
引用到另一张图中定义的交互
画一个框盖住交互涉及的生命线，可以定义参数和返回值
ref
全出一个完整的序列图
sd
交互框常见操作符
一个添加到消息名称的*号
iterationmarker
迭代标记
guard
放在方括号中的条件表达式
消息只有在警戒条件为真时发送
警戒条件
UML1
循环、条件等
synchronous message
必须等待，直到消息完成，就像调用一个子程序
同步消息
asynchronous message
继续进行其他处理
不必等待响应
多线程应用
面向消息的中间件中看到异步调用
更好的响应性，减少瞬时的耦合，但更难以调试
异步消息
同步和异步调用
查看单个用例内若干对象的行为时
Class-Responsibility-Collaboration
何时使用序列图
基础
interface
一个类
只有公开的操作
没有方法体
带关键词«interface» 的类
UML接口
展示为双尖括号之间的文本
«I»
«interface»
{A}
{abstract}
关键词
profile
为了特定目的使用一组相关的构造型
例如业务建模
扩展UML的某个部分
扩展机制
作为注释字符串在自己的栏中展示
责任
应用于类而不是实例的操作或属性称为静态的（static）
静态特性在类图中带下画线
静态操作和属性
aggregation
是“……的一部分”的关系
汽车有引擎和轮子作为它的部件
聚合
composition
虽然一个类可以是许多其他类的组件
但任何实例都必须是唯一拥有者的组件
Point（点）的实例可以是Polygon（多边形）的一部分
或者可以是Circle（圆）的圆心
但不能二者皆是
如果你删除Polygon
应该自动地确保任何它所拥有的Point也被删除
聚合没有严格的含义
“无分享”
组合
聚合和组合
derived property
基于其他值计算出来
指明计算值和存储值之间的区别
派生性质
开始日期
结束日期
这段时期内的天数
开始日期和结束日期
存储值
日期长度
计算值
日期范围
比如
在名称上标记一个/
abstract class
不能被直接实例化的类
有一个或多个抽象操作
把名称变成斜体
abstract operation
没有实现
纯声明
抽象操作
抽象类
没有实现的类
所有特性都是抽象的
关键词«interface» 来标记
接口
类可以替换接口
类供给一个接口
provides an interface
供给
类需要一个接口的实例才能工作
类需要一个接口
requires an interface
需求
ArrayList本身是AbstractList类的子类
类跟接口之间有两种关系
完全表示法
简洁表示法
接口和抽象类
只能读取不能更新的
只读
{frozen}
性质在对象的生命期内不能改变
不可变的
可以标记个别性质为冻结
指明所有实例的所有性质都是冻结的
也可以把该关键词应用到一个类
冻结
只读和冻结
reference object
引用对象
value object
«value»
«struct»
值对象
data type
数据类型
引用对象和值对象
qualified association
数组
哈希
词典
UML里
在Order上每个Product有单个Order Line
表达Order（订单）和Order Line（订单行）类之间的关联的一种方式
在和一个Order的连接中，对于每一个Product（产品）实例，可能会有一个Order Line
限定符
限定关联
classification
对象和它的类型之间的关系
分类
generalization
传递性的
分类和泛化
single classification
对象属于单个类型
可能从超类型继承
单个分类
multipleclassification
对象可以由若干类型描述
这些类型未必通过继承连接
多重分类
一个类型可以有许多超类型
必须为每一个对象定义单个类型
多重继承
泛化箭头上加上泛化集名称的标签
鉴别器
UML 1
把每一个泛化关系放进一个泛化集
任何超类型的实例可以是泛化集中唯一一个子类型的实例
默认不相交
类型结合
泛化集
dynamic classification
允许对象在子类型化结构内改变类
动态分类
static classification
不允许
类型和状态被分离
静态分类
多重和动态分类
http://martinfowler.com/ap2/timeNarrative.html
association class
允许你给关联添加属性、操作和其他特性
一个人可以参加许多会议
记录人们开会的时候有多清醒
给关联添加属性attentiveness（专注程度）
如果
关联类
parameterized class
参数化类
template
模板
派生（derivation）
Set<Employee>
<parameter-name：：parameter-value>
形式
EmployeeSet会遵从Set接口
«bind» 关键词
绑定元素
模板（参数化）类
用于展示一个固定集合的值
除了它们的符号值没有其他任何性质
«enumeration»
枚举
active class
有实例
每个实例执行和控制它自己的控制线程
客户的线程
或主动对象的线程
执行
方法调用
主动类
命令处理器
从外部接受命令对象
在它自己的控制线程内执行命令
例子
任何类都有公开和私有的元素
被任何其他类使用
公开元素
只能被拥有它的类使用
私有元素
简单认识
每一种语言都有自己的规则
可见性
+（公开）
-（私有）
～（包）
＃（保护）
可见性标记
实线箭头
虚线箭头
不需要到类的关联来发送消息给类
非关联类
一个对象发送到另一个对象的消息
箭头上的标签
标记说明
依赖箭头
消息
进阶
object diagram
某时间点上的对象在系统中的快照
展示实例
不是类
实例图
被称为
对象的配置案例
一组类
对象之间的可能连接比较复杂时
元素是实例
名称带下画线
每个名称的形式都是“实例名 ∶ 类名”
6.2 展示Party实例的对象图
实例规格
不是真正的实例
元素
instance specification
部分定义的实例
可看做没有消息的通信图
展示连接在一起的对象
何时使用对象图
一种分组构造
允许选择UML里的任何构造
把它的元素组织在一起
成为更高级别的单元
组织类
最常见的用法
每一个类都是单个包的成员
包也可以是其他包的成员
顶层包分解为子包
子包又有它们自己的子包等
直到层级的底部只有类
一个具有层级的结构
一个包中可以包含子包和类
UML模型中
每个包代表一个命名空间（namespace）
每一个类在拥有它的包里必须有唯一的名称
编程术语
7.1 在图上展示包的方式
公有的
或私有的
包中的类
相似的原因改变
共同封闭原则
一起被复用
共同复用原则
两个原则
包之间的依赖
包分组
package diagram
包和包之间的依赖
控制系统的大规模结构
清晰的依赖流
好的包结构
所有依赖运行在单个方向上
这个经验法则的一个异常
领域和数据库包之间的隔离层
映射器模式[Fowler，P of EAA]
数据映射器
7.2 企业应用包图
环应该局限在一个范围内
不应该有跨层的环
作者认为
无环依赖原则[Martin]
有越多依赖进入一个包
该包的接口就需要越稳定
接口的任何改变都会波动到所有依赖于它的包
leasing data mapper（租赁数据映射器）包
assetdomain（资产领域）包需要更稳定的接口
稳定依赖原则[Martin]
如果一个asset domain包中的类改变了
可能要改变leasing domain（租赁领域）包内部的类
这个改变不一定波动到leasing presentation（租赁表现）包
依赖关系不是传递性的
«global»
包和依赖
图7.2
图7.3 把图7.2分离成两个部分
表现
领域
数据库
应用的分层结构
租赁
资产
主题区域结构
两种结构
包的分解
一个包定义了一个可以被许多其他包实现的接口
图7.4 被其他包实现的包
定义了一个接口
DatabaseGateway（数据库入口）
其他入口类提供实现
Database Gateway包所包含的接口和抽象类完全由其他包实现
实现包
大规模系统
系统主要元素之间的依赖关系
对应用依赖的控制
绘制包和依赖的图
代表编译时的分组机制
何时使用包图
[Martin]
RobertMartin
展示系统的物理布局
揭示哪个软件运行在哪个硬件上
通信路径连接的节点
能驻留一些软件的环境
计算机
更简单的、连接到一个系统的
硬件部件
硬件
设备（device）
软件
包含其他软件
操作系统
或容器进程
执行环境（executionenvironment）
两种形式
软件的物理显现
.exe文件，二进制、DLL和JAR文件，程序集或脚本
可执行的
数据文件
配置文件
HTML文档等
通常是文件
工件
包含工件（artifact）
节点（node）
添加一个文档图标
或者 «artifact» 关键词
用类方框
或者通过列出节点内的名称
例如厂商、操作系统、位置或任何其他你感兴趣的事情
用标记值标记节点或工件，来表示各种关于节点的有趣信息
表示方法
部署图说明
三个物理的Web服务器
number deployed
图8.1 部署图实例
什么地方部署了什么
复杂一点的部署
何时使用部署图
捕获系统功能需求的技能
描述系统用户和系统本身的典型交互
系统如何被使用的说明
通过描述场景
用例介绍
描述用户和系统之间交互的步骤序列
场景（scenario）
通过共同用户目标绑在一起的场景集合
用例（usecase）
用户扮演的跟系统相关的角色
执行用例
顾客
客服代表
销售经理
产品分析师
单个执行者可以执行许多用例
一个用例可能有若干执行者执行
多人可以扮演一个执行者
一个人也可以扮演执行者
系统为另一个计算机系统提供服务
其他系统就是执行者
执行者不一定是人
角色
合适的术语
执行者（actor）角色
图9.1 用例文本实例
挑选场景之一
主成功场景（main success scenario）
把主成功场景书写为编号的步骤序列
书写用例体
描述主成功场景上的变化。
书写其他场景作为扩展（extension）
继续扩展——直到用户达到目标
执行者和系统之间的交互元素
每个步骤
和主成功场景
不同交互
差异是什么
描述
命名了一个条件
提供短的条件描
条件被检测的步骤
描述在何处返回到主成功场景完成这些步骤
步骤
之后
用例中的扩展
用头脑风暴法产生
用例结构
变成另一个用例
第一个用例包含（includes）第二个用例
用例中复杂步骤
被包含用例
子用例
和子子用例
用例为
分解
不要使用功能分解方法
重复的步骤
系统允许
用例开始之前
确保为真的东西
前置条件（pre-condition
用例结束
确保的东西
系统
成功保证
成功场景
最小保证
任何场景
保证（guarantee）
规定
触发用例开始
事件
触发器（trigger）
共同信息
用例的内容
图9.2 用例图
用例集内容的图形目录
展示系统边界和外部世界的交互
哪个执行者执行哪个用例
哪个用例包含其他用例
执行者、用例和它们之间的关系
system use case
和软件的交互
系统用例
business use case
讨论业务如何响应顾客或事件
业务用例
[Cockburn，use cases]建议
sea-level
主执行者和系统之间独立的交互
对主执行者有价值的东西
海平面级别
fish level
被海平面级别用例包含的用例
鱼级别
kite-level
比海平面级别更高级别的用例
风筝级别
用例的级别结构
用例的级别
助描述需求
先开发用例
然后生成特性列表
整个用例
用例中的场景
用例中的步骤
或一些行为变体
特性可能是
为你的资产评估添加另一个折旧方法
用例和特性（或故事）
帮助理解系统功能需求的有价值的工具
粗略地描述每个用例
项目早期
详细的版本
开发该用例之前
用例表达系统的外部视图
不要期望用例和系统内部的类之间有任何关联
何时使用用例
Ivar Jacobson的[Jacobson，OOSE]
，[Cockburn，use cases]
http://usecases.org
http://foruse.com
职业：本科
0 条评论
回复 删除
下一页
