UML研发--- Use case, Activity, Class Diagram 的协同使用

大家都使用UML来指导项目的研发，项目一开始都信心十足地画UML图，但是当项目进行一定时间后，随着各种各样的UML图越来越多的时候，随之而来的维护问题越来越严重，特别是现代的项目采用Agile, XP等开发模式，需求的迭代在逐步推进，这种模式下项目文档的维护也显得越来越不堪重负，最后导致代码，文档之间不匹配越来越多，也使得UML文档渐渐地丧失了其开发的指导性地位，大家都知道UML的九种基本图形：用例图、类图、对象图、状态图、时序图、协作图、活动图、组件图、配置图，可是实际应用起来的时候为何经常出现UML文档与代码不匹配呢？

根据我个人的经验，出现UML文档与代码不匹配而且导致其难以维护的原因主要有2个：

• 技术管理原因

• UML的不合理使用

管理者过于片面的认为代码是首要任务，疏忽对文档的管理，另外对UML文档的要求定位不太合理再加上参与人员的不合理使用，最后导致了UML大量应用，由于进度以及成本的原因不得不忽略对UML文档的维护，造成上述的种种问题。

本文重点谈谈定位不太合理这个问题，大家都知道UML的9种图形以及应用场合，理论上大家都可以说得头头是道，可是到实际中应用的时候往往是度把握得很不合适，哪怕一个很简单的逻辑都是时序图、状态图等等一起上，表面上看起来是很“正规化”地建模了，可是到后面由于“量大”、“工期紧”、“代码优先”等众多的因素导致了不尽合理的、无法维护的UML文档的大量出现，错误的、过量的文档比没有文档更加可怕，在这里我觉得如何正确合理地使用UML建模工具是非常重要的，我认为有如何不过度地使用UML文档至关重要，正如本文标题提到的，Use case, Activity, Class Diagram 的协同使用是主要的，另外需要把握重要的地方，项目组理解有问题、出偏差的地方等需要使用UML图来予以阐述，其他的地方应该避免

使用UML图，特别反对的是过度使用Sequence, Collaboration, State Diagram,个人认为应该使用Use case简要地描述客户需求的全貌，适当

配合文字，表格较为简洁地反应客户的需求，然后使用带有Swim Lane的Activity Diagram描述系统的活动，实现Use case逐步向可运行的计算机

系统的设计迭代，在泳道的基础之上逐步产生Class Diagram, 设计系统的各组件以及组件协作的接口，并且逐步细化方法，在类图以及活动图的

交互演绎下逐步完善系统的设计定义，最后演绎出完整的类图，包图，即可进入到设计编码阶段，在交互演绎阶段需要特别注意的是UML图形的层次

对应以及组成、关联关系，确保设计的完整性。

有关设计的具体例子在以后的文章中再独立讨论。