使用UML进行项目开发

使用UML进行项目开发

一、概述

本文主要论述的内容是如何使用UML来指导（辅助）项目设计。在此篇文章中，假设读者对UML已经有了概念上的认识，对UML中出现的名词都能很好的理解。

UML的目标是以面向对象图的方式来描述任何类型的系统，可以对任何具有静态结构和动态行为的系统进行建模。

在一个完整的软件项目开发流程中，我们一般将之分为四个阶段：

l        一是分析阶段，主要关心问题域中的主要概念（如抽象、类和对象等）和机制。

l        二是设计阶段，主要考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通讯和并行性等问题的类）。

l        三是构造（实现）阶段，这是一个相对独立的阶段，其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。

l        四是测试和维护阶段，在这个阶段最重要的验收测试中，将由用户进行,以验证系统测试的结果是否满足在分析阶段确定的需求。

而本文也将就UML如何在这四个阶段中应用提出建议。

二、应用

2.1、分析阶段

在使用UML的分析阶段中，主要任务是绘制用例图（Use Case Diagram），因为：一、它描述了待开发系统的功能需求；二、它将系统看成一个黑箱，从使用者（最终客户）的角度来理解系统功能；三、是系统开发者和用户交流的工具，也是以后驱动整个项目过程（Use Case Driven）的基准。

用例图描述了整个系统需要的实现的功能，而并不关心系统的具体实现，这样就避免了系统设计人员过早的陷入技术实现细节的泥潭，有利于快速建立正确而简单的系统模型；同时，用例图造就了一条技术人员和非技术人员的交流途径，这样，最大程度的避免了需求分析阶段的失误（错误），降低了整个项目的风险。

在用例图得出的同时，也需要产生相应的用例文档。用例可以分为业务级、系统级、功能级等不同的级别，而用例文档关心的是系统级的用例。在一份好的用例文档里，不仅要描述用例中涉及到的参与者、步骤、结果等以后的系统设计必须的信息，而且要避免过早考虑用例的具体的实现。也就是说，要使建模过程   和特定的编程语言、实现细节完全分开。

 

 

 

 

 

在进行系统用例分析的过程中，需要注意的是用例的粒度（大小）问题。开发设计人员一个常犯的毛病就是系统用例粒度过小，使之成为系统的功能分解，这样的话，在用例描述中，就会脱离业务用语，导致出现技术语言的描述。粒度过小的表现通常是：

l        把系统活动当成系统用例

l        把交互步骤当成系统用例

实际我们可以从上面的描述看出，判断是否粒度过小的一个方法就是判断用例描述中是否出现了技术语言，如果有的话，那就极有可能是犯了用例粒度过小的错误。

在使用UML进行系统分析的过程中，我们一般采取的是以下的步骤（括号中该步骤的目的）：

1、识别系统边界和Actor（识别Actor的一个作用之一就是确定系统边界）

2、识别用例（从最终客户的角度的出发，捕获功能需求）

3、书写用户文档（明确用例，以便在设计阶段识别类和类的属性）

4、识别用例间的关系（以便在设计阶段识别类之间的交互关系）

在分析阶段中，如何识别用例以及如何识别用例间的关系是很复杂、很有技巧性的一件事，需要一定的系统设计的知识和经验才能做好。具体的识别过程请参考文末的参考文献1、2。

分析阶段UML的相关输出产品是系统用例图和系统用例文档。

2.2、设计阶段

在设计阶段中，主要任务是绘制类图（Class Diagram）和序列图（Sequence Diagram），这阶段的工作主要依赖于分析阶段的输出产品，也就是用例图和用例文档。

我们发现，在分析阶段产生的用例文档出现了很多的名词，经过进一步的分析，我们发现可以从用例文档中出现的这些名词里总结出类和类的属性来。以前面提出的用例文档为例，我们发现，“航班”可以做为一个类，而航班号、起始地、目的地、日期等可以做为“航班”的属性而存在。当然，并不是所有的名词都可以总结为类或类的属性的。通过这样持续不断的分析和鉴别，我们就建立了一张类图。但是，在现在的这张类图里，我们仅有的是类名和类属性，一个最重要的：类的方法并没有出现在这种类图里面。

接下来的一步我们要做的就是分析用例文档中出现的动词。在语法中，动词描述了各名词之间的关系；同样，在用例文档里的动词描述了我们总结出来的类之间的（协作）关系。绘制序列图的功用之一就是把这些关系给描述出来。同样以前面的用例文档为例，我们可以得到下面的一个序列图：

 

 

 

我们发现，“查询指定航班号的航班”可以被定义为“航班管理系统”类的这样一个方法：

 

 

 

类似的，通过类之间的其他协作关系和消息传递，我们就能很容易的得出类应该拥有的其他公有（public）方法。这样，很快的，在序列图绘制出来的同时，我们也完成了对类图的补充。

和识别用例时一样，在识别类、类的属性和类之间的关系时，有很多的注意事项、技巧和讲究，同样的，也需要一定的理论功底和设计经验才能很好的完成这项工作。有关具体的如何识别类、类属性和类之间的关系的内容请参考文末的参考文献1、2。

在设计阶段， UML的相关输出产品为类图和序列图。

2.3、构造（实现）阶段

事实上，在设计阶段结束后，一般情况下，我们就不会再去更新UML里的文档和图了。所以从这个阶段开始，我们所需要了解是如何利用已形成UML文档和图去做好我们的工作。

构造阶段是一个相对独立的过程，在此阶段中，编码人员的任务是把需求、设计阶段形成的类、类属性和类之间的关系转换成为代码。在前面阶段所完成类图中，类的方法都是公有（对外）方法，也就是接口或API，我们为了完成这些API所需完成的功能还得自己添加一定的私有方法和属性。至于如何由类图转换成程序代码不属于本文讨论的内容，请各位自行查阅相关资料。

在一个比较完备的系统中，开发人员不仅仅需要完成代码，还需要完成由代码（类）到数据库的映射，这时，就还需完成数据库的建模和数据库、商务逻辑的中间层——数据库访问层编码和设计。关于数据库建模请查阅参考文献1或其他数据库相关书籍，本文不再赘述。

2.4、测试阶段

在进行测试时，UML模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测试、系统测试和验收测试。不同的测试小组使用不同的UML图作为测试依据，测试阶段和UML文档的相关关系请见下表：

测试阶段	UML相关文档
单元测试	类图和类规格说明
集成测试	部件图和协作图、序列图
系统测试	用例图
验收测试	用例图（实际中，这个阶段由用户进行， 一般情况下是不会使用到开发方的开发文档的）

说明：除非很庞大的项目，否则在一般的UML建模过程中是不会使用到部件图（Statechart Diagram）的，所以本文没有提及部件图的绘制和使用；而协作图（Collaboration Diagram）和序列图实际上是同构的，在UML中起到互补的作用。至于为什么仅提到了以上几种UML元素，这正如《UML用户指南》中提到的：“利用UML的20%就可以为80%的问题建模”，UML过于庞大，如何使用也是见仁见智，但我坚信一点：我们要做的仅仅是我们所需要的。

总结

通过本文以上的分析和讲解，相信各位对在具体项目中如何使用UML已经有了一个初步的印象，我们也发现，在一个完整的项目过程中，UML文档的生成主要是在分析、设计阶段（其实，建模工具、方法也只需在分析、设计起作用就够了）。在前面的文章里，UML文档的生成是和项目过程结合在一起讲的，现在我们把UML单列出来，看看UML文档的生成情况。

1、生成用例图、用例文档；

l        根据用户需求生成用例图、用例文档。这是一个与用户交互的阶段，以后的工作正确与否，与此阶段中是否与用户有了足够的联系有非常大的的关系。这阶段主要产生系统级别用例的用例图和用例文档，为以后的设计工作做好准备。

2、生成类图；

l        根据用例图和用例文档生成类图。此阶段完成的类图中，仅有类之间的关系、类名和类属性

3、生成序列图。

l        根据前两个阶段产生的文档，生成序列图，同时根据序列图中出现的类之间的关系、消息传递等信息继续完善前一阶段未完全完成的类图；同时继续丰富功能级和子用例级的用例图和用例文档

相信大家已经看出，虽说上面将具体过程分为了三个阶段，但实际上三个阶段间并没有清晰的界线。三个阶段互有交叉，逐步完善。而最终的目的，是形成一张完整的类图，为以后的实现阶段做好充分、充足的准备。

后记

撰写本文时，笔者并没有实际使用UML进行项目开发的经验，所以本文仅为笔者看书学习的一个学习总结。文中所介绍的开发流程是笔者对比了几种不同的流程后认为比较好的一种，因为这种流程思路简洁、清晰，所有UML文档的建立都是逐次而进，在从一个阶段进入到下一阶段时，下一阶段的所有必须信息都已具备，且无模糊不清之信息；而且，在下一阶段工作进行的同时，又为前面已完成阶段的工作提供了更多的、清晰的信息，为已完成阶段的工作起了一个继续完善、日臻完美的作用。

笔者认为，把自己学习的内容用笔写下来，是一种好的学习方法。因为这样就会迫使自己去把以前学习中模糊不清的概念一一理清，同时起到了复习巩固的目的。当然啦，这样的文章中肯定有错漏或错误之处，谈到这点，就得请各位读者不吝赐教，共同探讨了！^_^

敬请来信：kinyondgenius@msn.com，热情期盼你的信息。

参考文献

1、UML培训文档，UMLChina，2002

2、《UML和模式应用——面向对象分析与设计导论》，Craig Larman，2002