参加UMLCHINA（潘加宇）培训笔记

2005年3月18日，参加UMLCHINA培训，收获颇多，主讲者潘加宇老师显然在这方面有着丰富的经验，讲课的方式也很好，值得学习，讲课的内容如下：

开场讲了软件开发的本质，其实就是“现实世界－》找到问题－》解决问题”这样的步骤，找到问题包括（业务建模、愿景[目标]、需求），解决问题包括（分析核心机制、设计架构）

接着开始讲述每个过程：

◆ 业务建模

在这个阶段是完全基于业务的，这个时候不一定要开发软件，可能通过业务分析后，流程重组就可以达到目的，需要找出静态的业务对象模型

1》  先确定研究对象，先确定一个，此时不知道研究对象是大还是小，只有通过实践后才能知道

2》  确定业务的执行者

3》  识别业务用例

4》  详细描述业务用例（可选：文字或者活动图，一般建议：系统用例采用文字进行描述，业务用例采用活动图进行描述，还有，可以采用顺序图，顺序图能更好的表达一个对象的所有职责，涌到能清晰的表示责任在哪方）

注意：不要把表和实体混淆，实体是现实中的确存在的客观事务，而表是数据库中存储数据的容器，我们也可能把实体存储在表中

成果：此阶段完成后，需要有一份基于业务的用例图（或者文档），用活动图表示每个用例的流程

◆ 系统建模

基于业务建模已经完成，现在已经确定需要开发系统来管理业务，首先确定：

1》              目标：为什么要开发这个系统？这个过程需要问清楚用户关心的问题，开发这个系统后能解决什么样的问题，可以用各项指标来衡量

用例图是组织和分析业务的一种手段

确定系统用例后，要开始写用例文档（用来探索需求、组织需求）

系统用例文档的结构（以体检项目的“预约用例”为例）：

1、  前置条件：完成这个用例的前提条件，例如接待员已经登录，且已授权

2、  后置条件：如何确认这个用例已成功完成，系统已保存数据

3、  涉众利益：什么是涉众利益？涉众利益就是每个角色最关注的问题，通常用醉酒法进行获取，现在假设操作本系统的操作员喝醉了酒，各个角色现在最担心的问题是什么？？

体检联系人：担心录错了，体检人不能体检

接待员：担心输入不够方便，安全性不高，容易导致输入错误

下游工作人员：担心数据错误，使体检不能继续进行

4、  基本路径：凸现用例的核心价值，就是用户最希望看到的路径

5、  扩展路径：特殊路径，异常情况

书写系统用例文档的核心问题是保证涉众利益，通常涉众利益是有冲突的，如何平衡这些涉众利益体现了一个用例的核心价值。

千万不要以为此文档写完了就OK了，还有反复斟酌，反复考虑考虑涉众利益，并对基本路径和扩展路径进行调整和修改

成果：系统用例文档已完成

 

◆ 分析、设计

主要是设计系统的内部结构

分解：为什么要分解？

识别类及其属性：

可以先将实体类列举出来？

如何列举实体类呢？可以根据系统用例文档，找出其中的名词，动词，名词可能是一个类，也可能是类中的一个属性，动词可能是类中的一个方法

       成果：类图/用例图/系统用例文档均已完成！

       那下一步应该做些什么呢？

       下一步就要画序列图了，序列图是描述职责分配的过程，按BCE模式进行：

              界面类：界面类根本就不用找，必须有一个界面，找出界面完成的职责就行了

              实体类：根据类图找出实体类

              控制类：本身不做任何事情，可以考虑不要

成果：序列图已完成！（只是描述性的文档）

 

◆ 物理设计

基于前面序列图，类图均已完成，此时可以确定数据库的表结构和详细的序列图了，此时的序列图要求方法名和参数都已经确定

成果：表结构、类的方法、属性及其调用关系