UML在项目实施中的使用心得(详细设计阶段)_uml学习心得

3.详细设计阶段

在业务需求分析阶段使用Use Case图、Sequence图(有时候也使用Activity图的泳道图）描述清楚业务范围及业务流程，在概要设计阶段使用deployment图、component图、Sequence图、StateMachine图、Activity图描述清楚技术架构、部署方式、内外接口、主要流程后。在国内的项目中，很可能不需要详细设计，强大的中国程序猿已经可以直接开始开发了。中国的程序猿个个都有极强的创造精神，而且有相当一部分不大喜欢别人把详细设计做的太细，以便发挥下自己的创造力（初级设计能力）。我有朋友做日本公司的外包，详细设计不但详细到类级别，甚至每个方法都还有伪代码，这种感觉确实是太不能发挥自己的主观能动性了。不过仁者见仁，智者见智，因为一个初级的程序猿如果先是看别人的设计，然后再开始自己的设计，也许学习曲线就不会那么陡峭，日子也会过的舒服一点儿也未可知。

3.1Class图

类是面向对象最核心的要素（没有之一），因此详细设计阶段的第一要素是类。

类怎么设计类呢？按照UML的标准，要抽出来需求描述中的”名词“考虑是否要做一个对象，动作考虑是对象间的关系，我认为这句话以及相应的例子只是为了描述对象是什么，对象之间的关系是什么， 但是实际上是无法这样使用的：

1.一个需求文档可能动辄几百页，这么分析下去要死人的；

2.需求文档可能也不见得写的那么规范；

3.根据系统架构、需求，设计者心中已经有了合适的设计模式，而为了适应一个设计模式要建立的类，也不是通过需求文档逐句的挖掘能挖掘出来的。

所以说到底，如果说写需求文档的人可以不需要太懂技术，主要精力用于和客户讨论，进而把控需求的范围(SoW,Scope of Work)、梳理清楚相关的业务流程的话，那么写概要设计文档的就要有总体的架构能力，而写详细设计的人就得是超人，是一个从底层开发人员上去的，对设计模式、算法都精通的人，才能写出优秀的详细设计文档。有时候也很感慨，其实写需求文档的人（这个角色一般叫做BA，Business Analyst），写概要设计的人（这个一般叫架构师，Solution Architect,System Architect，System Analyst...)可能当年就没有搞明白设计模式、算法等计算机技术领域（这里的算法也指技术、工程域的算法，不包括计算科学家们搞的算法）相对”难“的东西，数年后最后摇身一变，工资比做详细设计、优秀的编码人员的工资还高出一大截，最后逼得有那么一批人心不甘情不愿的也走上了架构师、需求分析师的道路，做着其实不大喜欢做的活（这两个职位与人打交道要远多于程序猿与详细设计人员了）。Engineer的本意是说这是一门艺术，所以编程本身也是一门艺术，希望未来能看到越来越多的牛X的程序猿，拿的跟架构师、系统分析师不相上下的工资，做一个快乐的Engineer吧。

类图概要：

类图中的事物包括：类、接口、抽象类、模板类

类的关系包括：关联关系（又可分为聚合关系、组合关系）、泛化关系、实现关系、依赖关系。

关联关系的映射

下面是个形而上的例子，根据use case直接能生成类图，在实际系统中太难了：

3.2 Object图

可以使用对象图来描述某种状态下，系统中活跃的对象及其关系：

3.3 Package图(包图）

3.4 Sequence图

  Sequence图的描述见"UML在项目实施中的使用心得(需求分析阶段)"，与需求分析阶段和概要设计阶段不同的是，此时的sequence图可以与代码对应起来：

信息亭发Request (count, performance)消息给售票中心，表示调用售票中心类的Request (count, performance)操作，来查询演出的信息。

售票中心发Show Available(seat-list)消息给信息亭，表示调用信息亭类中的Show Available(seat-list)操作，给出可用的座位表。

3.5 Communication 图(通信图，协作图）

协作图的描述见"UML在项目实施中的使用心得(概要设计阶段)"，与概要设计阶段不同的是，此时的协作图是可以与代码级的类对象对应起来。

3.6 Activity图(活动图)

描述见"UML在项目实施中的使用心得(概要设计阶段)"，与概要设计阶段不同的是，此时的活动图是可以与代码级的类对应起来。

3.7 State Machine图(状态机图，状态图)

描述见"UML在项目实施中的使用心得(概要设计阶段)"，与概要设计阶段不同的是，此时的状态图是可以与代码级的类以及类中的成员变量、成员函数对应起来。