用例图向类图的转化的讨论

[cnepine]

一直以来都被这个问题给困扰。

也看过一些书，比如说

1. 把角色转化成类，用例转化为类等；
2. 通过用例的实现，即通过活动图来转化用例；
3. 还有一些别的，如寻求动，名词的方法等等。

可是我一直都对这些方法的实用性不能确定，针对新的系统开发，我仍然是非常的无助。

聪明的你，一起参与这个讨论吧。

[MadGodRokie]

我认为，首先你把注意力放在用例图就是一个错误。用例图所表达的内容是很少的。
应该把目光放在用例的文本描述。从用例的文本描述中获得角色、对象、数据和方法。这样才能得出合理的类。

[yang20052008]

根据用例做出顺序图，再根据顺序图做出类图

[angelflyingever]

我觉得不需要完全照搬
只要你把系统的结构和流程分析透了
画图就简单了！

[happyjun2000]

一个类似的问题
http://community.csdn.net/Expert/topic/4055/4055796.xml?temp=.5552179

虽然说个人有不同的喜好采用不同的方法，但是还是要一问:>

[Fanxr]

其实不需要搞得那么多,按自己的理解就好了.

把角色变成类,实际上就是一个角色(类)有多个属性而已,有点像数据表的一条记录.不知道这样是否好理解一些.

[rottenapple]

Use case 和use case图是不一样的
个人感觉一个好的use case文档甚至可以直接来做设计
当然，我说的在系统新增功能的基础上。
类图应该从use case中得到。

[putmybeautyonfire]

恩,一般我做的时候就是把use case document写完整,然后找出相关的对象,抽象成类.其实说白了,类对应的就是数据库里的表.有多少个类就因该有多少个表.至于怎么个优化数据库里的表,那又是另一件事了.

[happyjun2000]

1. 把角色转化成类，用例转化为类等；
2. 通过用例的实现，即通过活动图来转化用例；
3. 还有一些别的，如寻求动，名词的方法等等。

觉得都可以，你可以通过这几种方法来互补，看不是遗漏。

2. 通过用例的实现，即通过活动图来转化用例；
应该理解为通过分析探索用例的实现，可以使用活动图，也可以使用时序图，意在分析用例场景，寻找对象。
但是真正完整的用例实现，应该是在设计模型中进行描述的，因为那个时候的对象一般都是设计确定的，那样才能真正的描绘系统的对象交互，甚至可以作为以后的测试用例来使用。

[RobNoIdea]

用例描述的是角色的需求
角色是外部的

这两者如何直接转化为类？

类，准确说是对象是从用例中整理出来的，然后根据这些参与的对象制作类。