UML软件方法大纲

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

工作流	子流程	内容	备注
建模和uml		利润=需求-设计
愿景		缺乏清晰、共享的愿景往往是项目失败的主要原因。 愿景回答这样一个问题:在老大看来,引进这个系统的目的是什么? 寻找老大： 要点:老大是买方。典型错误:老大就是我们开发公司老总(或者研发总监、产品经理等)。 要点:系统改善哪个组织的流程?老大就是该组织的负责人。典型错误:老大是××局信息中心主任李××。 要点:系统好坏的度量指标藏在他的大脑里吗?典型错误:老大是某位大领导(可能是集团董事长,也可能是省长,甚至是总理)。 可度量的目标： 像愿景 不像愿景 减少采集数据所花费的时间 提高制作动画的速度 缩短订单的处理周期 建立一个 CRM 系统 提供在线订机票功能 揣摩目标度量：老大心底里是有度量指标的,否则,系统摆在他面前的时候,他拿什么来判断系统好不好?不过, 要得到度量指标不容易。 涉众利益 :愿景是老大针对系统的目标,那其他人的目标难道不重要吗?其他人的目标也是要关注的,我们 把它叫做涉众利益。愿景实际上就是系统最重要涉众的利益。
业务建模（组织建模）		业务建模——描述组织内部各系统(人肉系统、机械系统、电脑系统......)如何协作,使得组 织可以为其他组织提供有价值的服务。新系统只不过是组织为了对外提供更好的服务,对自己的内部 重新设计而购买的一个零件。组织引进一个软件系统,和招聘一名新员工没有本质区别。如果能学会 通过业务建模去推导新系统的需求,而不是拍脑袋得出需求,假的“需求变更”会大大减少 业务用例图：软件是组织的零件 【业务建模步骤 1-1】:选定要改进的组织 【业务建模步骤 1-2】:组织的业务用例图 业务执行者 业务工人和业务实体 识别业务执行者 业务用例 业务序列图：描述业务流程的手段   活动图 序列图 活动图只关注人 活动图表示动作 活动图更“灵活” 序列图把人当作系统 序列图强迫思考动作背后的目的 序列图更不“灵活” 业务序列图要点 ： 消息代表责任分配而不是数据流动 聚焦于系统之间的协作 只画核心域相关的系统 把时间看作特殊的业务实体 【业务建模步骤 1-3】:现状业务序列图 错误:把“现状”误解为“纯手工” 错误:把“现状”误解为“规范” 错误:以待开发系统为中心拼凑流程 【业务建模步骤 1-4】:改进业务序列图 改进一:物流变成信息流 改进二:改善信息流转 改进三:封装领域逻辑 阿布思考法：(1)假设有充足的资源去解决问题,得到一个完美的方案;(2)用手上现有的资源去山寨这个完美方案。
需求		需求——聚焦于待开发系统的边界,详细描述系统要卖得出去必须具有的表现——功能和性能。 这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众(Stakeholder)在意的、不能改变的契 约,哪些不是,严防“做”污染“卖”。需求工作流的结果——需求规约是“卖”和“做”的衔接点 需求-系统用例图： 系统执行者要点：在所研究系统外,与该系统发生功能性交互的其他系统。 系统用例要点 ：系统能够为执行者提供的、涉众可以接受的价值。 【需求步骤 2-1】识别系统执行者 不要把执行者和权限管理混淆 【需求步骤 2-2】识别系统用例 错误:玩弄“复用” 错误:玩弄“层次” 错误:玩弄“子系统” 错误:模糊的价值 提示:大用例无妨小用例 提示:用例的命名 （动宾结构） 需求-系统用例规约 【需求步骤 2-3】书写系统用例规约 需求-需求启发
分析		分析——提炼系统内需要封装的核心领域机制。可运行的系统需要封装各个领域的知识,其中 只有一个领域(核心域)的知识是系统能在市场上生存的理由。对核心域作研究,可以帮助我们获得 基于核心域的复用
设计		设计——将核心域知识和非核心域知识结合,最终实现系统。说“代码就是设计”指的是这里 说的“设计”。代码确实是设计,但代码不是分析,不是需求,不是业务建模。