文章目录
interaction diagram
文中提到了两种交互图sequence diagram和communication diagram,前者相对于后者更好(Craig Larman也承认这一点),后者的优势就是在墙上画图的时候可以充分利用整个墙面.
顺序图
常见图框操作符
- alt
选择性的片段,用于表示保护信息所表达的互斥条件逻辑- loop
用于表示保护信息为真的循环片段.也可以写*loop(n)*以指明循环的次数- opt
当保护信息为真时执行的可选片段- par
并行执行的片段- region
只能执行一个线程的片段
ref
用于交互图引用
metaclass
对于静态方法/类方法的调用需要加上<<metaclass>>
多态
在这里图表表达细节和多态屏蔽细节出现了矛盾,结果就是要画多份图,如下所示
active object
就是不需要从系统外部触发,能够自己触发的对象,一般运行在另一个线程.通过生命线框图加双竖线表示
通信图
并不是每个交互图都要由系统操作消息开始,可以由设计者希望表示其交互的任何消息开始
消息
对象间的每个消息都可以使用消息表达式和指明消息方向的小箭头来表示…可以增加顺序编号以表示当前控制线程中消息的次序
实例的创建
任何消息都可以用来创建实例,但是在UML中约定使用名为create的消息来实现这一目的(有人用new)
编号
不为第一个消息编号
使用核发编号的方案来表示后续消息的顺序和嵌套,其中嵌套消息要使用附加数字.通过在外部消息编号后附加引入消息编号来表示嵌套
注意上面英文标出的执行顺序
互斥&循环
静态方法 & 多态 & 同步异步
这些和顺序图类似
活动图
- action
他完成某些事物.在其完成时存在一个自动转换 - partition
表示参与过程的不同参与者 - fork
一个输入转换,以及多个输出的并行转化或对象流 - join
多个输入转换或对象流,一个输出变换.其输出直到所有输入都到达时才发生 - object node
由动作产生或使用的对象 - rake
当某个活动需要在另外一个活动图中展开时 - decision
条件分支 - merge
与decision相对应合并 - 时间信号
- 接收一个信号
DFD
活动图准则
活动图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值.对于简单的业务过程,用例文本就够用了
在进行业务建模过程中,可以利用rake符号和子活动图
与像一条相关的是,尽量保持同一张图中所有动作节点的抽象水平一致
state machine diagram
- event
一件值得注意的事情的发生 - state
对象在事件发生之间某时刻所处的情形 - transition
两个状态之间的关系.
准则
一般来讲,业务信息系统通常还有少数几个复杂的状态依赖类,对此,状态机建模通常用处不大
与此相反,在过程控制,设备控制,协议处理和通信等领域通常有许多的状态依赖对象
对状态依赖对象建模
- 对复杂的反应式对象建模
- 软件控制的物理设备
电话,汽车,微波炉:他们对于事件有复杂,丰富的相应,相应行为依赖当前状态 - 事务处理以及相关的业务对象
某个业务对象如何响应事件 - 角色转换器
某个人从平民转换为退伍军人
- 软件控制的物理设备
- 协议和合法序列
- 通信协议
- UI页面
- 用你系统操作
转换动作与监护
转换可以有一个条件监护逻辑测试,只有测试通过时,装换才发生
嵌套状态
部署图
node
部署图中最基本的元素是节点有两类节点
- 设备节点
具有处理和存储能力,可执行软件的物理计算资源- 执行环境节点
在外部节点中运行的软件计算资源,其自身可以容纳和执行其他可执行软件元素
- OS
- VM
- DB
- 工作流引擎
注意上面的VM是指jvm这样的vm
communication path
节点之间一般链接表示一种通信路径,上面可以标记协议
artifact
instance
部署图中通常现实的一组实例的示例…通常在UML中,具体实例的名字带有下划线,如果没有下划线则代表类,而不是实例
component
当某人使用UML构件图时,则其建模和设计意图是为了强调
- 接口是重要的
- 它是自包容和可替换的模块