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吧。

类图概要：

类图以反映类的结构(属性、操作)以及类之间的关系为主要目的，描述了软件系统的结构，是一种静态建模方法

类图中的“类”与面向对象语言中的“类”的概念是对应的，是对现实世界中的事物的抽象

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

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

关联关系的映射