1,265
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
songdan2002 2004-03-06
- 打赏
- 举报
你看Rational Unified Process这个软件吧,如果你安装了他的话,
这是一个功能强大的在线文档,包括了9大流程,和上千篇文档,他会告诉你步骤的.
soniczhouyu 2004-03-06
- 打赏
- 举报
确实是号帖，是我不再迷惑了
heroinwind 2004-02-13
- 打赏
- 举报
确实是好帖，对UML有了更深层的了解。
yunhi 2003-12-20
- 打赏
- 举报
好贴!
Panr 2003-12-14
- 打赏
- 举报
在谈论中能提出不同的视角引导讨论的主题，对技术人员没有多大意义的
无须辩解：作为一个专业人士，只有能用合理的代价达到要求才算合格，只有把世界冠军拿回来才叫做杰出
马俊仁也是一个有争议的人物，就连他引以为骄傲的爱徒也反唇相讥
我相信每个专业有自己的甘苦，只要“马家军取得的金牌是真实存在的”，我就认为马俊仁是一个杰出的专业人士，他做得很好，值得我去敬佩！
-----
至于是那些因素直接影响成本和竞争力，应该是没什么定论的吧，嘻嘻～
无须辩解：作为一个专业人士，只有能用合理的代价达到要求才算合格，只有把世界冠军拿回来才叫做杰出
马俊仁也是一个有争议的人物，就连他引以为骄傲的爱徒也反唇相讥
我相信每个专业有自己的甘苦，只要“马家军取得的金牌是真实存在的”，我就认为马俊仁是一个杰出的专业人士，他做得很好，值得我去敬佩！
-----
至于是那些因素直接影响成本和竞争力，应该是没什么定论的吧，嘻嘻～
wjdzs 2003-12-13
- 打赏
- 举报
学习:)
ozzzzzz 2003-12-11
- 打赏
- 举报
其实我看大家都忽视了设计模型和分析模型的区别。用例并不是分析模型，它只是形成分析模型的素材。而对于用例的分析我们可以产生一个分析模型，但是很少有把这个分析模型直觉去作设计模型而实现完成程序的。这是一种对于幼稚的做法。首先我们应该明白，用例得到的分析模型，只是表达了系统中的概念，而不能表达系统中的性能和系统的外观。同时分析模型往往对于系统的结构设计来说又往往过于简单或者过于复杂，复用和调试等等都不能在这个模型中被考虑完成。这就是为什么会有那么多人去学习设计模式，而不是去研究分析模式。
所以谁也不要幻想直接把分析类图画好就直觉按照其去编码。
所以谁也不要幻想直接把分析类图画好就直觉按照其去编码。
jeffyan77 2003-12-11
- 打赏
- 举报
ozzzzzz(希望敏捷) :有的时候就得像你这样讲才管用。
keen_9 2003-12-10
- 打赏
- 举报
Activity图我认为就是流程图，但rose里面的工具不是很好画，一般我习惯crack一个visio来画 ， ^_^～～～～
michaelli 2003-12-10
- 打赏
- 举报
对每个用例进行顺序图设计
然后提取类图，小工程这些完成后就可以编码实现了
然后提取类图，小工程这些完成后就可以编码实现了
Panr 2003-12-09
- 打赏
- 举报
界面磋商
个人的经验来说是界面磋商，就是确定‘软件的功能界面’，如果是操作性软件那么我们要约定操作界面，如果是平台性软件软件那么我们约定的是程序接口
如果是产品肯定是这样的。如果是项目的话界面交流的阶段短一点，很快就会转去考虑如何实现这些功能
个人的经验来说是界面磋商，就是确定‘软件的功能界面’，如果是操作性软件那么我们要约定操作界面，如果是平台性软件软件那么我们约定的是程序接口
如果是产品肯定是这样的。如果是项目的话界面交流的阶段短一点，很快就会转去考虑如何实现这些功能
lymkelly 2003-12-09
- 打赏
- 举报
学习:)
huarick 2003-12-09
- 打赏
- 举报
www.modeldriven.net.cn/bbs
在这里找找或者有答案
在这里找找或者有答案
iamwls 2003-12-09
- 打赏
- 举报
jeffyan77 出书就支持
谁让你写的<java与模式>如此清晰明白
现在你成天RUP，我都快晕死拉
赶快出书，要不扁你,哈哈
revoke 2003-12-09
- 打赏
- 举报
我想首先得有个阶段问题,若在初始始阶段,用例写完了(8%)左右吧,一般并不做设计类的分析的.在精化阶段,对于某一次迭代,可以根据用例描述及领域知识绘制概念类,然后绘制顺序图,接着是设计类,再运用各类原则,模式来细化设计类.<<Apply uml and pattern>>第二版有详细说明
BinaryTreeEx 2003-11-25
- 打赏
- 举报
用例完成后，就问问自己我真的完成了么？一直到你找到证据为止。到那个时候你也知道下一步该做什么了。
SyDes21 2003-11-25
- 打赏
- 举报
用例完成后,要先描述每个用例的流程,用UML就是用Sequence表达出来；接下来就是类的构造了。
libi 2003-11-25
- 打赏
- 举报
"介绍RUP和UML理论的书很多，但是以真实项目开发的事例进行讲解的书还真不多。如果我写一本《RUP一例》，将大多数流行办法结合一个真实项目讲解一下，不知道有没有人看。呵呵"
好啊，支持！！！！！！！！！！
好啊，支持！！！！！！！！！！
jeffyan77 2003-11-24
- 打赏
- 举报
从Use Case Model到Design Model是一个gap，如同ozzzzzz(希望敏捷) 所说的，有很多办法连接这两个模型。我记得在另一个帖子里面讲过了，方法基本上就是一下这些：
（1）Noun Exercise（名词法）把Use Case Model的文档拿来，列出所有的名词。这些名词就是以后的类或者类的属性。然后筛选这些名词，找到类和属性。
这是一种比较老的办法，在UML和RUP出现之前就有。直是那个时候并没有用例驱动，文档直接就是功能文档，现在换成了Use Case 文档，因此有时不太好用。
（2）CRC Exercise（CRC卡法）国内的不少书籍好像讲过，我就不讲了。
这种办法也比较老了，但是因为比较直观，适合于教学，所以仍有很多人沿用。同样，过去文档直接就是功能文档，现在换成了Use Case 文档，因此有时不太好用。
（3）RUP的Use Case Realization这是RUP过程理论的强项，只有RUP理论能够如此完美地将Use Case Model与Design Model无缝连接起来，与GUI Prototype和Database Design model与Use Case Model, Design Model连接起来。
（3.1）
一般而言可以先给出Activity 图Swimlane法，划出Activity图，作为Use case的实现。然后划分泳道，将泳道辨认为对象，过渡到Sequence图，然后辨认出类，给出类图。
在辨认类的时候，可以区分Entity class, border class, control class，这个时候可以与另外两个模型结合：
Database Design Model
GUI Prototype Model
注意这个时候，所谓的类并不是最后的Java类，而是比较粗放的business class。要经过几次循环才能得到最终的Design Model。
值得指出的是，有一些朋友不知道Activity图的重要性，直接从Use Case图给出Sequence图，这就是有缺陷的，恐怕是读书的时候没有读全面。在简单的项目中这也许可以，对于项目设计高手可能不是问题，但是中间毕竟缺少了一个环节。
所谓Activity图，其实就是事件流，在UML出现之前我们都是用flowcharts，而flowcharts和Activity图相差不多。你也不一定要用图表示事件流，用文字也可以。只是既然我们使用RUP，那么就用UML表示。
（3.2）也有人结合老的办法，使用名词法和CRC卡法，进行Use Case 实现。严格地讲，这不是RUP。但因为老的方法深入人心，所以也很普及。
在混合使用老的办法的时候，又有一个在什么时候混合的问题，不同人有不同做法，造成相当程度的混乱。譬如有人把名次法引入到从Use Case图到Sequence图中间，有人把CRC引入到它们中间，引发很多争议。
初学者极易在这个地方搞混掉。我建议初学的朋友不妨坚持使用最正规的RUP，不要混合使用老办法。反正中国的IT过程研究历史较短，并没有美国的包袱，为什么要使用老的办法？
介绍RUP和UML理论的书很多，但是以真实项目开发的事例进行讲解的书还真不多。如果我写一本《RUP一例》，将大多数流行办法结合一个真实项目讲解一下，不知道有没有人看。呵呵
（1）Noun Exercise（名词法）把Use Case Model的文档拿来，列出所有的名词。这些名词就是以后的类或者类的属性。然后筛选这些名词，找到类和属性。
这是一种比较老的办法，在UML和RUP出现之前就有。直是那个时候并没有用例驱动，文档直接就是功能文档，现在换成了Use Case 文档，因此有时不太好用。
（2）CRC Exercise（CRC卡法）国内的不少书籍好像讲过，我就不讲了。
这种办法也比较老了，但是因为比较直观，适合于教学，所以仍有很多人沿用。同样，过去文档直接就是功能文档，现在换成了Use Case 文档，因此有时不太好用。
（3）RUP的Use Case Realization这是RUP过程理论的强项，只有RUP理论能够如此完美地将Use Case Model与Design Model无缝连接起来，与GUI Prototype和Database Design model与Use Case Model, Design Model连接起来。
（3.1）
一般而言可以先给出Activity 图Swimlane法，划出Activity图，作为Use case的实现。然后划分泳道，将泳道辨认为对象，过渡到Sequence图，然后辨认出类，给出类图。
在辨认类的时候，可以区分Entity class, border class, control class，这个时候可以与另外两个模型结合：
Database Design Model
GUI Prototype Model
注意这个时候，所谓的类并不是最后的Java类，而是比较粗放的business class。要经过几次循环才能得到最终的Design Model。
值得指出的是，有一些朋友不知道Activity图的重要性，直接从Use Case图给出Sequence图，这就是有缺陷的，恐怕是读书的时候没有读全面。在简单的项目中这也许可以，对于项目设计高手可能不是问题，但是中间毕竟缺少了一个环节。
所谓Activity图，其实就是事件流，在UML出现之前我们都是用flowcharts，而flowcharts和Activity图相差不多。你也不一定要用图表示事件流，用文字也可以。只是既然我们使用RUP，那么就用UML表示。
（3.2）也有人结合老的办法，使用名词法和CRC卡法，进行Use Case 实现。严格地讲，这不是RUP。但因为老的方法深入人心，所以也很普及。
在混合使用老的办法的时候，又有一个在什么时候混合的问题，不同人有不同做法，造成相当程度的混乱。譬如有人把名次法引入到从Use Case图到Sequence图中间，有人把CRC引入到它们中间，引发很多争议。
初学者极易在这个地方搞混掉。我建议初学的朋友不妨坚持使用最正规的RUP，不要混合使用老办法。反正中国的IT过程研究历史较短，并没有美国的包袱，为什么要使用老的办法？
介绍RUP和UML理论的书很多，但是以真实项目开发的事例进行讲解的书还真不多。如果我写一本《RUP一例》，将大多数流行办法结合一个真实项目讲解一下，不知道有没有人看。呵呵
fhquutuu 2003-11-24
- 打赏
- 举报
学习
加载更多回复（9）
