最近一个项目中，开始全部使用UML做设计，在项目过程中，体会到关于UML的一些经验。我以前也间断地学过一些UML方向的知识，但从头到尾用到项目中，这是第一次，因此把其中一些收获列出来，不对的地方请指教。
一． 需求阶段
1． 需求阶段使用use-case图描述需求
顶层use-case：粗粒度地描述系统，给出系统的概况
细分use-case：将顶层use-case细化
Use_case图的方法是：从参与者开始寻找用例，用use-case diagram来表示参与者与用例之间的关系。
Use-case描述的方法是：就是use-case规约，用详尽的文字来描述用例的执行流程(包括主业务流程及所有分支流程及异常流程)。
Active diagram:可选，类似业务流程图，业务比较复杂时，用流程图来描述业务。
注：use-case图和use-case描述，是整个系统设计的主要产品，今后的分析和设计，都将围绕这两个产品进行。以前看过的好多资料，都没有讲到这一点，use-case的作用非常大，将贯穿分析到设计到编码的全过程。
二．分析阶段
分析阶段的主要工作，是围绕use-case图，及use-case规约，从中寻找参与系统的各种对象。
1． 用sequence diagram来描述use-case的执行过程(包括主流程及备选流程)：
方法：a.从参与者开始，寻找参与系统流程的对象
b.依照参与者à边界类à控制类à生命周期类à实体对象 的次序，区分各对象的职责，将参与系统的各种对象，依次添加到sequence中。
c.从后向前验证序列，检查每个对象是否拥有它提供服务所必需的信息。如果没有，需要重新考虑对象的职责划分，确保每个对象有相应的方法或通过调用能够找到必需的信息。
注：分析阶段，不应涉及到具体技术。关注的重点还是系统做什么，而不是怎么做。
思考：1.现有项目，往往技术是已经确定的，这种情况下，分析应该关注什么内容？
2． 生命周期类，是开发中工作量较大的部分，也有很多可选的frmework来支持，常用的有自己实现DAO、hibernate等技术路线。
3． 分析阶段，已经确定了系统中的package。有一点要注意，package一定要根据业务来进行划分，而不是在系统建立时，就根据客户的意见来强行划分包。根据包之间最小依赖关系，来划分包，并注意一定要避免包之间的相互依赖。
三．从技术的角度考虑系统技术方法及软件构架
主要工作是为边界类、实体类、控制类选择候选技术。但往往项目已经是确定了技术路线的，比如我们公司项目已经规定使用J2EE技术。但即便如此，也有很多地方需要考虑。比如是使用JMS通信，还是自己实现Observer。是使用EJB，还是不使用。个人认为，使用EJB一定要慎重。
这部分工作需要系统设计经验比较丰富的人来做，因为技术路线一时选错，对系统后期带来的不良影响是十分大的。
根据可扩展性、可维护性、可靠性、可伸缩性的综合考虑，来确定系统的构架。
四．设计阶段
设计阶段，同样围绕use-case图及use-case描述来进行，和分析阶段的不同，是加入了选定的具体技术，同时使用面向对象的理论及设计模式等，对系统进行设计。
使用UML的建模工具，在设计阶段产生的产品，主要有两大作用：一是便于交流，也便于修改。二是便于进度安排和工作分配。
五．实现阶段
实现阶段是针对设计阶段的产品，编码来进行系统的实现。
注：主要内容都来自<<Enterprise Java with UML中文版>>及RUP文档。
