利用周末的时间读了潘加宇的《软件方法（上）》，希望梳理清楚UML的知识脉络；
| 工作流 | 子流程 | 内容 | 备注 | ||||
| 建模和uml |
利润=需求-设计 |
||||||
| 愿景 |
缺乏清晰、共享的愿景往往是项目失败的主要原因。 愿景回答这样一个问题:在老大看来,引进这个系统的目的是什么? 寻找老大：
可度量的目标：
揣摩目标度量：老大心底里是有度量指标的,否则,系统摆在他面前的时候,他拿什么来判断系统好不好?不过, 要得到度量指标不容易。 涉众利益 :愿景是老大针对系统的目标,那其他人的目标难道不重要吗?其他人的目标也是要关注的,我们 把它叫做涉众利益。愿景实际上就是系统最重要涉众的利益。 |
||||||
| 业务建模（组织建模） |
业务建模——描述组织内部各系统(人肉系统、机械系统、电脑系统......)如何协作,使得组 织可以为其他组织提供有价值的服务。新系统只不过是组织为了对外提供更好的服务,对自己的内部 重新设计而购买的一个零件。组织引进一个软件系统,和招聘一名新员工没有本质区别。如果能学会 通过业务建模去推导新系统的需求,而不是拍脑袋得出需求,假的“需求变更”会大大减少 业务用例图：软件是组织的零件 【业务建模步骤 1-1】:选定要改进的组织 【业务建模步骤 1-2】:组织的业务用例图
业务序列图：描述业务流程的手段
业务序列图要点 ：
【业务建模步骤 1-3】:现状业务序列图
【业务建模步骤 1-4】:改进业务序列图
|
||||||
| 需求 |
需求——聚焦于待开发系统的边界,详细描述系统要卖得出去必须具有的表现——功能和性能。 这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众(Stakeholder)在意的、不能改变的契 约,哪些不是,严防“做”污染“卖”。需求工作流的结果——需求规约是“卖”和“做”的衔接点 需求-系统用例图： 系统执行者要点：在所研究系统外,与该系统发生功能性交互的其他系统。 系统用例要点 ：系统能够为执行者提供的、涉众可以接受的价值。 【需求步骤 2-1】识别系统执行者
【需求步骤 2-2】识别系统用例
需求-系统用例规约 【需求步骤 2-3】书写系统用例规约 需求-需求启发 |
||||||
| 分析 |
分析——提炼系统内需要封装的核心领域机制。可运行的系统需要封装各个领域的知识,其中 只有一个领域(核心域)的知识是系统能在市场上生存的理由。对核心域作研究,可以帮助我们获得 基于核心域的复用 |
||||||
| 设计 |
设计——将核心域知识和非核心域知识结合,最终实现系统。说“代码就是设计”指的是这里 说的“设计”。代码确实是设计,但代码不是分析,不是需求,不是业务建模。 |