软件工程里的UML序列图的概念和总结

俗话说，自己写的代码，6个月后也是别人的代码……复习！复习！复习！

　　软件工程的一般开发过程：愿景分析、业务建模，需求分析，健壮性设计，关键设计，最终设计，实现……

　　时序图也叫序列图（交互图），属于软件工程里的第二步——业务建模阶段里的图，业务建模要求我们把视角从系统转向组织，要站在客户的角度看问题，以达到清晰准确地“知彼”，术语就是从组织的角度来定位系统的价值，从而避免软件项目的失败，因为大量软件项目失败的原因都是一个——最终实现和用户需求不一致！故业务建模也叫组织建模，切记在业务建模和需求分析阶段，忘掉自己技术专家的身份！其实说那么多，就是一句话：业务建模就是把系统放在组织中来看。

　　•组织[Organisation] ——为了实现既定的目标，按一定规则和程序而设置的多层次岗位及其有相应人员隶属关系的权责角色结构。例如政府、企业等。
　　•业务[Business]——组织的本行业本职工作。例如医院的看病、急诊；银行的储蓄、贷款等。
　　•业务建模[ Business Modeling ]——是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系。包括对业务组织建模，对业务流程建模，改进业务流程等方面。

　　

　　业务建模的第一步就是找到组织，然后是明确组织的现状（必要的时候需要改进现状），明确现状一般需要如下两个图：业务用例图，业务序列图（或者活动图、或者文字）。从外部看，组织是价值的集合，用业务用例图来建模，业务用例图帮助我们从高层次了解组织的业务构成。从内部看，组织是系统的集合(人是一种智能系统)，用业务序列图来建模，业务序列图帮助我们从细节上了解组织的业务流程，每个业务用例都代表一条业务流程，一般用文字、活动图或者序列图来描述这个流程。

　　

　　采用序列图描述业务的优势：以面向对象的思想来看业务流程。而活动图往往表示的只有事件，序列图却可以表现责任和动作！

　　

　　业务序列图的组成：业务执行者、业务工人、业务实体，以及三者间的交互，以完成某个业务用例的实现流程。业务工人[Business worker]——位于业务组织内部，负责业务流程中某些工作的人员。比如银行柜员，诊所的医生。业务实体[Business Entity]——在业务用例的实现流程中，业务工人所使用的“系统”。例如银行的数钞机，学校的校园卡系统。业务实体可以和业务工人相互取代各自的职责。

　　采用序列图来描述业务现状的步骤：

　　1.识别业务对象：业务执行者、业务工人、业务实体；

　　2.确定业务对象间的职责、协作及交互顺序

　　3.绘制业务序列图。

　　其中绘制图的时候，生命线（Lifeline）是一条垂直的虚线，用来表示序列图中的对象在一段时间内的存在

　　

　　示例：比如为某家招聘公司进行业务建模——画出业务现状序列图，招聘的业务用例描述：招聘公司在XXX市人才交流中心前台，要求发布招聘信息，并向工作人员出示公司资质证明，工作人员核实资质的有效性，招聘公司将招聘简介给工作人员。工作人员在招聘记彔本上填写公司招聘职位，招聘条件，以及公司简介等信息，并要求招聘公司核实，招聘公司核实无误后，工作人员将招聘信息用彩纸张贴在招聘信息栏内，工作人员向招聘公司收取一定费用。（注意：在现实工作中，类似如上的信息都是分析师与组织的业务专家深入沟通后才能获得的）。本例的业务对象是，招聘公司（业务执行者），工作人员（业务工人），找到业务对象之后，开始确定各个对象之间的职责，交互……

　　

　　序列图中常用分支，有loop循环，alt条件分支，opt可选分支，画法如下：

　　业务序列图里的消息可分为过程消息、自调用消息、回送消息，还有分法是分异步消息和同步消息。回送消息（也就是返回）是用虚线的，其余都是实线。

　　

　　消息的名字代表责任和目的！！！具体格式就是，A—》B，A请求B做某事的过程，注意是B做事情，A只请求，如下对比；

　　　　       

　　

　　消息的方向代表了责任的委托！绝不是数据的流动！如下对比：

　　不对，右边是对的　　　　

　　序列图只需要画出领域内相关的系统

　　业务序列图的最小单位是人或者独立智能系统

　　可以把时间看作特殊的业务实体

　　

　　千万注意，业务建模阶段不能！也没有必要去考虑需要实现什么系统！

　　业务改进序列图；了解业务组织现状的目的——发现流程中的改进点：

　　•信息自动流转

　　•封装复杂业务逻辑

　　•职责转移

　　•访问和操作业务对象

　　•其他……

　　

　　改进点：信息自动流转，业务中涉及到信息的流动吗？

   　            　　　

　　改进点：封装复杂业务逻辑：包含的业务逻辑能封装到系统里吗？

　　改进点：职责转移：业务工人的职责可以转移吗？

　　　　　　　　　　

　　

　　改进点：访问和操作业务对象：涉及到什么业务对象？需要系统管理起来吗？

　　　　　　　　

　　示例：XXX市人才交流中心业务的改进思考
　　通过分析XXX市人才交流中心业务的业务现状序列图，结合老大的愿景，我们可以分析出如下可改进的思路：
•原先由前台职员提供的求职、招聘业务在流程上都非常固定，不存在太多技术含量，我们完全可以考虑通过建设一个招聘网站来解放前台职员的这部分工作；
•此外，前台职员无法实现7*24小时不间断的服务，这个问题也可以由招聘网站解决；
•招聘网站可以极大地缓解人才交流中心顼客排队等待发布求职戒者招聘信息的状况，可极大提高客户满意度。

　　

　　现在能看出业务建模用序列图的好处了吗？
　　•通过改进业务序列，可以提前模拟出新系统的出现，将对组织现行的业务流程造成哪些影响，可以提前评估新系统的可行性戒提前进行相应的准备工作，实现安全平稳的组织改进。
　　•不要小看这一点，在真实世界里，这一点很关键，很多优秀的系统就因为不能适应组织的业务流程而被遗弃（例如工作流软件在国内命运）。

　　如何获取业务建模信息
　　•选定组织：老大和他的愿景。
　　•组织业务现状：业务与家的介绍。
　　•组织业务改进：
　　•老大的痛处和愿景；
　　•业务与家的抱怨；
　　•需求分析师的经验和智慧；

　　业务建模结果复核目的
　　•一是完善业务建模成果，寻找是否有遗漏戒错误的地方进行修正，如果问题明显，就需要迭代回去继续做业务建模工作；
　　•二是关键干系人在信息和意见上达成一致，并共同签字确认，作为下一阶段启动的标志。

　　业务建模结果复核方法
　　•形式：面对面会。
　　•参会人：甲乙双方在业务建模阶段的主要参不者。
　　•被审材料：系统愿景、选定组织、业务用例、业务现状序列图、业务改进序列图；
　　•过程：需求分析师主持，介绍业务建模成果，所有参不者交流讨论，达成统一理解和确认。
　　•结论：所有参会者签字确认。（当然， 也有可能是未达成共识，需要返工。）
　　•注意：后续的工作基本不需要 “老大”的参加了。

　　如果下面问题已经很清楚了，就可以精简甚至不做业务建模而直接进入需求分析阶段。
　　•系统是改善什么业务组织（或人群）的价值？
　　•改善哪方面价值？目前这方面有什么不足？
　　•系统可以改进哪些不足？