UML软件方法大纲

利用周末的时间读了潘加宇的《软件方法（上）》，希望梳理清楚UML的知识脉络；

工作流

子流程

内容

备注

建模和uml

利润=需求-设计

愿景

缺乏清晰、共享的愿景往往是项目失败的主要原因。

愿景回答这样一个问题:在老大看来,引进这个系统的目的是什么?

寻找老大：

• 要点:老大是买方。典型错误:老大就是我们开发公司老总(或者研发总监、产品经理等)。
• 要点:系统改善哪个组织的流程?老大就是该组织的负责人。典型错误:老大是××局信息中心主任李××。
• 要点:系统好坏的度量指标藏在他的大脑里吗?典型错误:老大是某位大领导(可能是集团董事长,也可能是省长,甚至是总理)。

可度量的目标：

像愿景	不像愿景
减少采集数据所花费的时间 提高制作动画的速度 缩短订单的处理周期	建立一个 CRM 系统 提供在线订机票功能

揣摩目标度量：老大心底里是有度量指标的,否则,系统摆在他面前的时候,他拿什么来判断系统好不好?不过, 要得到度量指标不容易。

涉众利益 :愿景是老大针对系统的目标,那其他人的目标难道不重要吗?其他人的目标也是要关注的,我们 把它叫做涉众利益。愿景实际上就是系统最重要涉众的利益。

业务建模（组织建模）

业务建模——描述组织内部各系统(人肉系统、机械系统、电脑系统......)如何协作,使得组 织可以为其他组织提供有价值的服务。新系统只不过是组织为了对外提供更好的服务,对自己的内部 重新设计而购买的一个零件。组织引进一个软件系统,和招聘一名新员工没有本质区别。如果能学会 通过业务建模去推导新系统的需求,而不是拍脑袋得出需求,假的“需求变更”会大大减少

业务用例图：软件是组织的零件

【业务建模步骤 1-1】:选定要改进的组织

【业务建模步骤 1-2】:组织的业务用例图

• 业务执行者
• 业务工人和业务实体
• 识别业务执行者
• 业务用例

业务序列图：描述业务流程的手段

 

活动图	序列图
活动图只关注人 活动图表示动作 活动图更“灵活”	序列图把人当作系统 序列图强迫思考动作背后的目的 序列图更不“灵活”

业务序列图要点 ：

• 消息代表责任分配而不是数据流动
• 聚焦于系统之间的协作
• 只画核心域相关的系统
• 把时间看作特殊的业务实体

【业务建模步骤 1-3】:现状业务序列图

• 错误:把“现状”误解为“纯手工”
• 错误:把“现状”误解为“规范”
• 错误:以待开发系统为中心拼凑流程

【业务建模步骤 1-4】:改进业务序列图

• 改进一:物流变成信息流
• 改进二:改善信息流转
• 改进三:封装领域逻辑
• 阿布思考法：(1)假设有充足的资源去解决问题,得到一个完美的方案;(2)用手上现有的资源去山寨这个完美方案。

需求

需求——聚焦于待开发系统的边界,详细描述系统要卖得出去必须具有的表现——功能和性能。 这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众(Stakeholder)在意的、不能改变的契 约,哪些不是,严防“做”污染“卖”。需求工作流的结果——需求规约是“卖”和“做”的衔接点

需求-系统用例图：

系统执行者要点：在所研究系统外,与该系统发生功能性交互的其他系统。

系统用例要点 ：系统能够为执行者提供的、涉众可以接受的价值。

【需求步骤 2-1】识别系统执行者

• 不要把执行者和权限管理混淆

【需求步骤 2-2】识别系统用例

• 错误:玩弄“复用”
• 错误:玩弄“层次”
• 错误:玩弄“子系统”
• 错误:模糊的价值
• 提示:大用例无妨小用例
• 提示:用例的命名 （动宾结构）

需求-系统用例规约

【需求步骤 2-3】书写系统用例规约

需求-需求启发

分析

分析——提炼系统内需要封装的核心领域机制。可运行的系统需要封装各个领域的知识,其中 只有一个领域(核心域)的知识是系统能在市场上生存的理由。对核心域作研究,可以帮助我们获得 基于核心域的复用

设计

设计——将核心域知识和非核心域知识结合,最终实现系统。说“代码就是设计”指的是这里 说的“设计”。代码确实是设计,但代码不是分析,不是需求,不是业务建模。