uml培训笔记(完善中)

提升销售
到底要解决什么样的业务问题? --业务建模
为了解决业务问题, 所开发的系统要提供什么功能和性能 -- 需求

降低成本
为了提供功能, 系统内部要有什么样的核心机制? --分析
为了满足性能, 系统的核心机制如何用选定的技术实现? -- 设计

UML的结构:
简化
结构:用例图+类图
行为:序列图

用例文档示例:

用例编号: UC1
用例名称: 提交故障
执行者:
客户(主)
前置条件
系统已经记录故障信息
涉众利益(必须从涉众中来)
客户(1)--担心不能及时解决, 得到跟踪. 希望方便
销售代表(2)--担心恶意的提交故障, 希望客户能清楚..
基本路径:
1.客户选择故障类别
2.系统显示该类别说明
3.客户提交故障的描述文字
4.系统验证输入的内容符合要求
5.系统保存故障信息
6.系统提示故障已保存, 以及要处理销售代表信息扩展
扩展
4a. 不符合要求:
4a1.系统提示输入内容存在的问题
5a.保存失败
5a1.系统提示故障保存失败, 联系Xxx
字段列表
故障类别+故障描述+客户身份+提交时间
业务规则
... ...



关于愿景

老大对要开发系统的目标, 期望
必须来自老大, 必须能度量, 能度量需要有度量的指标, 而作某件事则不能作为愿景
愿景举例:在尽可能短的时间内计算出佣金, 同时要尽可能的准确, 每一步的操作事后可以追究.
远景不是功能, 是实现功能之后带来的效果
愿景实现的目标:没有实现的产品老大需要付出的代价
对现实的不满, 需要改善, 但是改善需要限定一个范围
程序员要从老大的角度来看整个项目
对于产品来说, 老大就是客户群的代表

关于涉众
谁关心这个系统, 会涉及到他的什么利益?
对于同一件事情, 不同的人看的视角可能各不相同, 而不同的视角则是基于不同的利益
探索系统的需求, 就是探索不同的涉众之间的利益的最佳平衡点
涉众的位置不同, 利益会有所不同, 开发人员要从最前排的涉众(老大)的利益为出发点, 否则会影响需求
必须明确, 涉众的利益是不会轻易改变的, 稳定的

业务建模
通过业务建模找出工作量
要把系统放在业务组织中来看
将放在人脑中的需求放到电脑中去

业务建模要实现的内容包括:
1)系统改善什么组织的价值,
2)改善那方面的价值,
3)目前这方面有什么不足,
4)我的系统可以改善那些不足
如果大脑中清楚以上四点, 则不需要建模

找到要建模的组织, 也就是系统所涉及到的人和物的集合

业务执行者
actor:从业务组织外面找出和业务组织交互的人和组织
业务执行者要和业务工人区分, 业务工人存在业务组织内部, 业务工人可以被其他的业务实体替换的, 业务实体可以是系统, 设备等, 因此要实现的业务也可以看成系统中的一个业务实体
开发系统就是为业务组织开发一个业务实体来替代或者业务实体或者业务工人的工作
业务用例代表业务的本质, 是业务的价值所在, 不会随着时间而改变, 代表了业务对外提供的价值
业务建模是对业务组织来说的, 不是对业务系统来说的, 系统只是业务用例的一个零件而已

简单的业务用例可以直接找出
复杂的业务用例是一些隐含的, 需要不断的挖掘出来
用例是一种可以买的服务
业务用例代表了一个业务组织的本质
业务零件都是可以替换的, 只是容易不容易而已

一个组织会有多个用例, 但是我们建模只针对改善的那个用例

时序图
时序图是责任流不是数据流, 职责从一个业务实体或者业务工人转移到另一个

画时序图就是为了改善它
第一个改进点:让信息自动流转, 让人肉处理改进成机器自动处理, 尽量减少人肉的处理, 也就说用系统处理来替换人肉处理
第二个改进点:封装复杂业务逻辑, 将位于人肉大脑中的逻辑抽取出来, 放到设计的系统中去
第三..把基本的数据管理起来

进一步改进的思考, 思考的大前提是愿景, 与愿景背离的都应该舍弃:
实物流改成信息流了吗?
相关的业务流都封装到系统中了吗?
涉及到的业务对象, 系统都管理起来了么?

改进点:先考虑改进点, 在考虑那些是符合愿景的

业务序列图中的消息线, 表示是箭头方能提供的职责或者服务, 并不是职责方发起的请求

如果涉及到数据的回流(返回), 而返回不是请求方职责, 不能用实线表示, 必须要用虚线表示, 实现表示的箭头是指向自己

时序图的箭头线, 起始方表示请求的发起方, 箭头方表示请求(职责)的提供方, 箭头线的文字, 是提供方提供的职责内容

业务序列图涉及到的业务工人或者业务实体, 必须是人肉, 或者系统, 而不是系统中的某个东西, 比如业务实体只能是db系统, 而不是db中的某个具体表

如果是对已有系统的改进, 职责流则需要画详细一些, 如果画不下, 可以另外新建一个扩展的时序图

有时候时间也是一个业务实体, 比如到了某个时间点, 执行某个动作


执行者
理解功能需求和需求约束
有时候涉众比执行者更重要
越是与电脑打交道的, 可能越不重要
执行者可以是任何事物

找出系统的执行者:
谁使用系统的主要功能
谁改变系统的数据
谁从系统中获取数据
谁需要系统的支持完成工作任务
谁负责管理, 维护系统的正常运行
系统需要哪些硬件设备
系统需要哪些外部系统交互
谁对系统产生的结果感兴趣
有没有自动发生的事件

系统用例
系统用例就是价值, 比如医院对病人的承诺, 病人对医院的期望
只有对执行者有价值的对象才能作为用例
用例包括两点:有价值, 系统能实现的
用例采用动宾结构, 谨慎使用弱动词和弱名词, 比如进行, 使用, 复制
用例没有粒度的限制
数据库的crud不是用例, 但是可以直接将crud概括为xxx管理的用例, 要尽可能的隐藏实现细节
防止系统活动步骤和执行者操作当用例
用例都是服务, 能买的东西
从涉众的角度看到的东西才能成为用例, 是可以买卖的, 人家愿意花钱的东西
一个用例包含很多的操作, 所以不能将操作当成用例

应该将需求和设计割裂, 不一定是一对一的关系, 需求是不可复用的, 设计则可以, 这样才可以赚钱

通过愿景来删除无用的用例, 与愿景目标不符合的都要干掉, 没有实现的远景目标要加上
审查用来按照重要性排序:最能实现愿景的用例先开发

用例文档
前置条件:是一种承诺, 一种契约, 要能检查, 不能影响,涉众的利益, 是起点
后置条件:是终点
例如, 取钱, 前置是口袋没钱, 后置是口袋多了500快
下面的用例文档从上到下, 精度从低到高, 稳定性从高到低
用例(取款)
路径(正常取款)
步骤(系统验证取款金额合法)
补充约束(取款金额必须为100的倍数)

编写用例文档的总原则:如果涉众不能理解就不是需求, 如果去掉是否有涉众的利益受到伤害

前置条件
形式:系统在用例开始前能检测, 比如登录密码多少位, 取款金额不能大于余额不是前置条件, 因为在开始前没法检测
内容:不满足会伤害到涉众利益

后置条件:
用例成功结束之后, 系统应具备的状态, 也就是应该是一种结果状态. 比如提示操作成功, 打印取款凭证, 后置条件应该是系统"已"记录鉴定结果, 而不是系统系统记录鉴定结果

涉众利益
用例必须平衡涉众之间的利益
比如取款, 用户的利益是方便, 银行的利益是安全, 低成本, 因此需要在二者之间做出平衡
只有人才是涉众
只是某个用例的涉众
如果涉众坐不到前排, 必然会受欺负
如何找涉众
1.醉酒法
当事人(希望什么, 担心什么)
上游(希望什么, 担心...)
下游(结果的影响者)
涉众是系统背后的"人"而不是系统本身(人指业务人员也可以业务实体)
时刻将涉众利益放在心上
照顾到戏院的前几排就可以了, 越靠后越不重要

通过业务建模就可以确定用例所关联的涉众
用例图中的执行者和辅助执行者
序列图中的业务工人和业务实体

基本路径步骤
观众坐好了, 演出开始了
取款机例子:正常取款的过程就是基本路径
路径四部曲:发起动作, 系统验证, 系统做出改变, 系统做出回应
要遵守四部曲, 不要涉及到过多的细节, 否则就是多余的废话
发起动作的一定是执行者, 如果第一步的主语是系统的话, 则路径为错
涉众能理解的才能作为路径步骤(要说"可观测"人话, 不要说鸟语(技术用语))
写的时候采用主动语句,禁用被动语句, 主语只能是执行者和系统
不要涉及界面细节
界面不是需求
所有在基本步骤中提到界面元素都是错的
界面是开发人员强加到涉众身上的
稳定程度:用例>路径>步骤>约束
只写自己能承诺做到的事情
"如果"这样的字眼只能出现在分支扩展, 而不能出现在基本路径步骤
有时候还可能涉及到步骤的循环
基本路径步骤只涉及到系统和执行者, 出现与其他东东(辅助执行者, 与系统无关的执行者)相关的步骤有可能是错误的(避免的办法是系统请求xx做某事)


扩展
写一些意外(如果这样, 那么怎么处理)
如果某个步骤有意外, 那么怎么处理(2a, 2a1, 2a2...)
如果不知道是哪个步骤, 用*表示
扩展必须是系统能感知的和要处理的
扩展点一般出现在执行者的选择, 系统验证, 步骤失败等
扩展只是一种交互行为的变化, 不是可选项的罗列

补充约束
多的话另外成文档, 少的话写到用例文档里面
字段列表
不能当成数据模型
不等于数据字典
用于与涉众达成共识
达成共识的东西不用写到文档中(比如邮编是6位数字构成的, 如果涉众是外星人, 邮编是21位的就要就分别说清楚)
字段列表不等同于业务模型, 可能只是业务模型的一部分, 也不等同于数据字典, 因为业务模型和数据字典是业务细节, 在此阶段不能涉及过多的细节
业务规则:
自然语言表达, 记住要涉众能看懂就可以了
不能把算法当成规则(当涉众发生逆转(能看懂算法)的时候, 才是对的)
业务规则可以包括:一种事实(xxx是xxx), 一种推理结论(如果xxx, 那么xxx), 一种约束(xxx不能超过xxx)
表述方式可以文字, 决策表,

非功能需求
可用性:
可用性必须可度量, "系统易于使用"是屁话, 不能涉及到系统的实现细节, 最明显的就是界面细节
有这个功能, 但是用户可能不用
要写可以验证的标准
需求工程师不能做界面的, 不能搞界面原型

可靠性:
安全, 稳定, 完整

性能:
速度, 容量, 能力, 要可度量
写的最多的, 几乎每个用例都会有的

可支持性:
涉众需要的是系统的能力, 至于怎么做不关心

要杜绝在需求文档中混入设计, 删掉设计->提炼出真正的需求
功能需求是软件要求的

设计约束
必须来自涉众
现实的条件限制的
比如公司中买了oracle, 开发人员只会java等
凡是涉及到界面的都不是设计约束, 除非是涉众明确指出的要求
小心设计约束当成需求, 有时候所谓的设计约束可能是用户的一种需求, 要善于将这种约束转换成一种需求

再看一遍
时刻想到涉众利益, 是否照顾到涉众利益, 是否偏离涉众利益
从需求到利益, 从利益到需求

用例之间的关系
扩展
用来分离扩展路径
包含
公共的部分
某些步骤在多个用例作用反复出现, 将其抽取出来独立成价值, 注意用例=价值, 而不是用例=步骤
泛化
同一业务目的的不同实现, 比如识别用户, 可以通过输入口令验证识别, 也可以通过扫描虹膜识别, 子用例将集成父用例的一切(关系, 前置条件, 后置条件, 路径, 步骤)

用例之间只有三种关系, 其他的都是错误, 比如用例和用例之间的通讯

需求启发
需求不能采蘑菇, 需求必须采用侦探的眼光去发现

因为涉众可能会说(定义),但是不会做, 所以需要你去启发他(比如足球教练不一定会踢球)
涉众没有资格也没有责任决定需求
涉众说什么都是对的, 但是要发现后面的利益(银行门口放箩筐)
采用不同的视图去启发需求(针对不同的涉众)

类图
需求=外观, 类图=内部机理
分解需求
人脑只能把握7件事
人脑的问题产生了分解
采用人脑更能理解的方式进行分解

连接
两个类平等协作关系

从用例文档抽取类

领域建模现实世界中的人和事物之间的关系

从基本路径到业务规则提炼出类
类的属性出现在字段列表中
对象是一个有生命的东西, 不要带信息, 表之类的字段

类的属性审查
类的属性:什么的什么
类的属性是否对所有对象都有意义(比如, 人的男性器官和女性器官), 是否每个人都有男性器官和女性器官呢?

领域中的关系决定了类的关系
集合关系=>泛化关系
个体关系=>观念关系

陌生领域中很难发现关系

泛化识别(从上到下, 从下到上)
有共同的行为才做泛化
不同领域不能形成泛化
通过lsp来识别泛化
泛化用来形成框架, 用的少
关联用来形成个体, 用的多

聚合vs组合
聚合是一种松散的关系(老大和小弟之间的关系, 公司和雇员)
组合是一种紧密的包含关系(比如订单和订单向)
这两种关系的区别不是很重要

学会说不知道, 因为上下文信息太少了

每个人都有具体的,合适的答案

区分的意义
简化责任的分配 -> 以此为出发点来做区分

类之间可能有多种关联
类可以自反关联(比如员工类中的下属和上司之间的关系)

聚合组合意味着传递性(比如计算订单和订单向之间的关系)

关联只是将属性分离出去

关系是静态的, 动态的关系不能表示对象之间的关系

用例和类只升级到系统的边界
哪个类做哪个呢, 类之间的交互通过序列图表现出来
边界类与执行者交互, 能搞定的就搞定, 不能搞定的交给系统内部去搞定
一个执行者映射一个边界类, 多个执行者多个边界类
业务序列图最小单位是一个实体, 一个系统
活动序列图是对一个系统的分解

有几个箭头, 表示有几个操作, 自己指向自己表示私有操作
箭头表示责任分配, 而不是数据流动, 虚线表示数据返回

责任分配原则
总原则:地耦合, 高内聚
专家原则:把资源分给专家, 根据资源来, 只有一个最合适的, 自己能搞定, 不能搞定能分解, 都不能搞定, 我能委托出去(单一职责原则)
一个类只有一个变化的原因
有丰富领域知识才能做到精准的分解, 喊口号最简单, 怎么做才是最难的
老板原则:出现关联关系的时候
可视原则:不和陌生人说话
将消息的传递放在相互关联的类之间
oo之间的消息传递是命令式的, 而不是询问式的(告诉他去做, 而不是问能不能做)

重构也是将责任进行调整

状态图用来判断责任分配是否合理
一种独特的视角
状态不是类, 是一个属性值的组合
状态反应行为的变化, 属性值的变化
这种变化是通过外部来观察的

类图是方法 映射为序列图的消息, 映射为状态的行为事件

分析  理清关系
设计 根据平台实现关系