在Rose中分析用例实现时按MVC模式分析出了实体类，控制类,边界类 如何从分析模型过渡到类模型？ 比如分析出了 Entity ,Control 等，如何过渡到Class? 不知道说明白没有，望指教！
看来tobato对用例模型和分析模型都已经掌握的差不多了. 下面的文字摘抄于RUP的概念:设计模型,有什么不明白的,请提问. 一个分析类可以成为设计模型中的单个类。 一个分析类可以成为设计模型中某个类的一部分。 一个分析类可以成为设计模型中的一个聚合关系类。（这意味着不能在分析模型中直接建立此聚合关系类各部分的模型。） 一个分析类可以成为设计模型中从同一个类继承而来的一组类。 一个分析类可以成为设计模型中一组功能相关的类。 一个分析类可以成为设计模型中的一个包（这意味着它可以成为一个构件。） 一个分析类可以成为设计模型中的一项关系。 分析类之间的一项关系可以成为设计模型中的一个类。 分析类主要处理功能性需求以及来自“问题”领域的模型对象；而设计类则处理非功能性需求以及来自“解决方案”领域的模型对象。 分析类可用来代表“我们希望系统支持的对象”，而不用决定用硬件支持分析类的多少部分，用软件支持分析类的多少部分。因此，某个分析类的一部分可以通过硬件来实现，根本不用在设计模型中建模。 以上方法也可能会以任何组合的形式存在。
我倾向于这样做： 1.确定系统职责，即系统要做什么，例如系统要通过UI与用户交互，系统要完成用户发起的业务事件的响应，系统要将需要持久的数据进行持久。这些职责一般设计为Java中的接口。 2.确定系统如何做，由哪些类来实现这些接口。一个类可以实现多个接口，就像现实生活中一个人扮演多个角色一样。一个类既实现UI的职责，也实现业务职责，同时也实现持久，这也没什么问题，如果您的程序特别小的话。如果一个小公司，财务兼出纳兼接待员。而对一个大系统来说，UI可能就是由一组复杂的类来实现。 从需求到最后可运行的二进制码，是一个概念逐层转译的过程。需求中的描述主要是用客户的概念和词汇。据此我们可以建立CIM（Computation Independent Model），即计算机发明之前做生意的模式。然后结合计算机的特点，设计出PIM（Platform Independent Model），这种模型对使用.net还是使用java来说，都是一样的。再接下来是PSM（Platform Specific Model），结合了比如说J2EE以及Struts框架这样的具体平台。最后是编码，再由编译器产生二进制码。 我们的任务就是做好这些转换工作。每一次转换没有固定的方法，如果有固定的方法，大家就会让计算机去做，那就不需要人做了。例如从高级语言到机器指令的过程。
想必tobato对UML及RUP已经有一些了解了，那么我想你就不能回避用例，因为用例在RUP（或者其他的过程模型）中是极为重要的（回想一下4+1视图），建模过程中的每一步都离不了用例的，从分析模型到CLASS当然也不例外，从用例中提取类，从顺序图或状态图中提取操作，就是类图的生成过程。你根据MVC模式分出的三大类其实是从逻辑角度分出来的，我个人认为那是在考虑分层设计时比较有用的概念。（个人观点，有待讨论） 如果还是觉得不很清楚，推荐一本书给你看看，Parl R.Reed,JR.的《使用Visual Basic和UML开发应用程序》，他还写了一本用JAVA和UML的，不过建议先不要管他用的语言先，注意理解他的思路，相信对你会很有启发，而且如果你有时间，最好多看几遍，绝对开卷有益
现在大家讨论得最多的就是用例，怎么样来写好用例，用例的作用..用例..用例..讨论来讨论去还是用例，用例确实是当前Rup4＋1视图中的核心，写好用例很重要！但是最终用户需要的是可以运行的系统。如何从用例过渡到分析，由分析过渡到设计，再到迭代开发的计划...还有很多东西可以拿出来讨论的 Rup是一个软件开发的参照过程，希望有人能够讨论一些更深入的分析与设计的话题。 有没有办法可以拿出一个虚拟的项目来从需求做到可以运行的程序的？
好好分析了一下那个课程注册的例子，终于看明白了： 我的问题是将Rose中的版型的作用搞错了，如果在Rose中设置了版型，那么默认显示就是版型的形状，可以设置不显示版型就成为了Class了。 在课程注册的例子中，分析模型中的大部分边界类，实体类，控制类在设计模型中都保留了下来，而在分析模型中没有架构模型，在设计模型中才有了架构模型，设计层次等东西。 能谈谈你们成功的面向对象软件工程实施的经验吗？如果一两句话说不明白，总结一下也行！:)
1.系统特性列表; 2.系统界面原型设计; 3.系统类图. 我的经验就是如此,认真扎实做好这三件事,大部分的项目在技术上就不会翻船.
系统特性列表RequestPro 中提到了这个东西，一般来说可以从特性演化到功能，功能可以Trace到特性。但是在实践中我感觉很难分出特性与实际的功能，究竟如何认识特性与功能？如何区分特性与功能呢？
特性是对系统功能的概括性描述，主要从客户的角度出发。 功能（或用例）是对系统功能的精确的，形式化的描述，主要从设计者的角度出发。 一般一个特性都能对应多个功能（用例）。 不过我个人不支持这种繁琐的描述方式，一般来说描述到特性就可以了。形式化的用例描述过于精细，开发过程中往往会反复改变（由于客户的原因或软件设计自身的原因），维护这些改变一般是一件非常困难的事。
臭帖评价：