软件方法

使用业务序列图原因：
  一、活动图只关注人，序列图把人当作系统。活动图描述流程时，往往会忽略了非人工系统的责任。
  二、活动图表示动作，序列图强迫思考动作背后的目的。序列图不但表达非人工系统的责任，也揭示出某个岗位对外暴露的责任，序列图可以在业务建模和系统建模的过程中始终贯彻“对象协作以完成用例“的思想。
  三、活动图更“灵活”，序列图更不“灵活”。“很容易画”的活动图容易掩盖开发人员对业务流程认识不足或者业务流程本身存在缺陷的事实。序列图强迫开发人员通过alt、loop等结构化控制片段描述业务流程的方式去思考，通过故事来思考待开发系统的位置。
    
  业务序列图要点：
  一、消息代表责任分配而不是数据流动。在序列图中，焦点是对象之间的责任和写作，数据流是作为消息的输入输出参数存在的。建模人员不但要看到数据的流动，还要找出背后的责任。消息代表对他人提供的服务，如果没有指定目的可以用“处理...”来命名，消息名称中不需要带“请求”二字，箭头已表明请求的意义。
  二、聚焦于系统之间的协作。业务建模研究的焦点是组织，所以业务序列图上对象的最小单位是人肉或非人肉系统。建模的基本原则是抽象级别的一致，勿需细化到每一步操作。
  三、只画核心域相关的系统。一个智能系统要不要成为序列图上出现的业务实体，要根据“它是否核心域内的系统”来判断。
  四、把时间看作特殊的业务实体。这样便可以映射到系统用例的时间执行者。注意，时间是外系统，世上只有一个时间系统，定时器是其他系统用来和时间大交道的边界类，定时器会有无数个。
    
  a.绘制现状业务序列图：现状好比拿着摄像机去拍摄，会拍到什么？把拍到的场景如实绘制成业务序列图。根据不同的业务用例，会有多个业务序列图。
  应避免的错误：
  一、把“现状”误解为“纯手工”。业务流程中有人工系统也有非人工的系统，新系统的需求需要通过研究业务现状，再结合愿景推导得出。
  二、以待开发系统为中心拼凑流程。业务建模时，摄像机应该一路跟随着实现业务用例的流程去拍摄，如实反映拍摄的故事，各个系统知识流程中的一个零件。业务建模就是要从业务流程中待到代开发系统的位置，证明该系统对实现业务用例是有帮助的。
    
  b.绘制业务交互概述图：将各个业务用例的序列图串联起来。
   c.改进业务序列图：挑选一个最值得改进的业务序列，阐明原因，然后空降一个系统，画出改进后的序列图，从而得到第一批用例。注意UML建模不是为了“先建模后需求在分析”的顺序而使用，而是迅速定位最值得改进点，得到最有价值的用例，先开发。这才是敏捷。
  改进途径：
  一、物流变信息流。为降低流转成本，尽可能把物流变成信息流，在需要物的时候才将信息变成物。
  二、改善信息流程。可以依靠引入一个新的系统来达到在多个信息系统之间实现信息传递和协调。
  三、封装领域逻辑。通过将人脑中的领域逻辑提炼封装到信息系统中，使人脑得到解放。在绘制业务流程时，非常重要的改进点是：一定要注意画出人脑中的思考逻辑，避免白开水一样的业务流程。前两条改进，系统内部封装逻辑不复杂，效率高，而做到第三条，就可以靠软件的功能就能卖钱。
  四、阿布思考法。
  改进思路是：1.假设有足够的资源去解决问题，得到一个完美的方案；2.用手上现有的资源去山寨这个完美方案。例如：中国组织最得力的会议是靠人脑组织的全国人民代表大会，做会议软件的话可以山寨一二。
  “创新的需求是从观察和思考的汗水中来，不是把拍脑袋闭门造车的所谓‘头脑风暴‘当作调研”。

2-系统建模：与业务建模不同的是研究对象，业务建模的对研究对象是组织，而系统建模的研究对象是系统。
  1.画出系统用例图：有了业务建模的铺垫，系统用例实际上以呼之欲出。
  1). 系统用例图：
  a. 确定系统执行者：系统执行者的定义是在所研究系统外，与该系统发生功能性交互的其他系统。有了前面的业务建模，就不需要头脑风暴了，直接从业务序列图映射即可得到系统执行者。