关于rose及uml的10个问题，请高手赐教。.txt

一些关于UML的经典讨论

关于Rose及UML的10个问题，请高手赐教。

http://www.shecn.com/best/g1/g120.htm

--------------------------------------------------------------------------------

关于Rose及UML的10个问题，请高手赐教。 

１、状态图中如何加入状态变量？ 
２、类图中常出现的不可见的空矩形是何意？是文字性信息(Text box)吗? Document、Note、Text box的作用由何具体细节的差别？ 
３、Report->Show participants in VC显示Vsecase相关的类和操作。如何事先建立好这种关联？ 
４、按照《Rose入门到精通》P231的方法设置关联类为何不起作用? 是Rose98与Rose2000用法上的具体差异吗？ 
５、如何在Rose中画三层结构？用泳道？ 
６、在Rose集成环境中可否从类直接看到源代码？例如点击类图上的类，Rose直接调用VC环境的相应类的代码？ 
７、我正在用Rose设计一个教学软件，以下那种模型更合理？注意：基本知识页面与知识问答页面不可能同时出现在教学界面中。 
| 
|---------| |--------| | |------------| |--------| 
|教学界面 | O—— |控制按钮| | |教学界面 |O----- |控制按钮| 
|---------| |--------| | |------------| |--------| 
O O | O 
/ \ | | 
/ \ | | 
/ \ | | 
|------------| |-------------| | |----------| 
|基本知识界面| |知识问答界面 | | |教学界面 | 
|------------| |-------------| | |----------| 
\ / | ^ ^ 
\ / | / \ 
\ / | / \ 
V V | / \ 
|-----------------| | |------------| |-------------| 
| 教学界面 | | |基本知识界面| |知识问答界面 | 
|-----------------| | |------------| |-------------| 


以上两种模型是否合理? 
（注意：上图用"O"表示聚合关系、用"V"、"^"表示继承关系。） 

８、我想引入一个以前逆向工程生成的一个mdl,但为何import……效果同open? 我以前好像成功使用过这个功能？ 
９、可否一下子将所有类都不显示其操作？即都改变option-->show……？ 
10、子系统的矩形柜在Rose如何表示，用包表示吗？设成subsystem也达不到这样的视觉效果。这样好像不太直观。 


Homesoft 道士无情 
2001.3.10 

====
回复: 没有人能帮我么？ - <0b> homesoft 2001/03/11 09:29 (24次点击) 
====
原文(john_zhu于2001/03/12 09:28粘贴) 
回复: 没有人能帮我么？ 
--------------------------------------------------------------------------------

你一下子问得太多了，谁有空回答你，建议你将10个问题拆为10个贴子。将问题作为标题。 
====
原文(john_zhu于2001/03/12 09:46粘贴) 
no.8 
--------------------------------------------------------------------------------

将以前逆向工程生成的一个mdl按照包导出为patel file，再导入 
====
回复: no.8 谢谢，我试过了，还是不成 :-< - <0b> homesoft 2001/03/14 20:12 (5次点击) 
===
原文(john_zhu于2001/03/12 09:37粘贴) 
回复: 没有人能帮我么？ 
--------------------------------------------------------------------------------

状态图中的变量只有在状态的Action内的设置send event 时可以加，在其他地方你为什么还需要，状态变量不明白你的意思，详述一下。 
===
原文(homesoft于2001/03/14 21:14粘贴) 
回复: 状态变量 
--------------------------------------------------------------------------------

我在《UML Programming Guide 设计核心技术》看到的。page 81 
======
原文(jyemii于2001/03/15 11:28粘贴) 
回复: 状态变量 
--------------------------------------------------------------------------------

状态图中状态转换(或依《UML Programming Guide 设计核心技术》所称的状态转移：Transition)卷标的语法包含三个部份，这三个部份在使用上是有选择性的，UML 的语法为： 

事件名称(Event) [成立条件(guard)] / 动作(action) 

即是事件名称、事件成立的条件及条件成立后的执行动作。例如：Checking [Item is equal to EOF] / Dispatching (批注：确认物品[所有的物品都已经完成确认]/发送物品)，以系统规格的观点而言，只要表达条件的叙述即可。 

但若以程序设计的观点来看，条件包含所要确认的变量名称及变量值，而他会在此状态中的不同阶段进行变化，例如以上述的例子来看，我们可以使用程序伪码表示： 
do while not item.eof() 
begin 
Checking; 
MoveNextRecord; 
end; 
Dispatching; 
而 item.eof() 所传回的布尔值代表物品是否确认完成，若未完成则进行确认并取得下一个物品，由于 item.eof() 其代表状态的变量值，因此《UML Programming Guide 设计核心技术》这本书的作者称这种用来判断事件是否成立的变量为「状态变量」。 

=====
原文(homesoft于2001/03/15 11:35粘贴) 
回复: 如何体现状态变量 
--------------------------------------------------------------------------------

谢谢,你回答得太好了,可是这些我知道. 
我问的是如何在 rose中表现条件变量? 

===
原文(jyemii于2001/03/15 14:31粘贴) 
回复: 如何体现状态变量 
--------------------------------------------------------------------------------

这个问题并不难，很多文件上面都有说明，你可以参考 OMG 协会所发布 UML 1.3 版的规范书，或是 UML 参考手册，这些资料你可以很容易从「文件分享」中找到，另外你也可以从 Rose 的辅助文件中去发掘，只要从 Rational Rose 选单中选择「Help/Search for help on…」，并于对话窗口出现后，在文字方块中输入 Statechart Diagram(Overview) 或Statechart Diagram Example，尤其是后者，可以让你从图例中一眼就看出条件变量的表示法。你可以了解到，绝非《UML Programming Guide 设计核心技术》这本书作者的表示方式。差异在： 

《UML Programming Guide 设计核心技术》这本书将状态变量放置于状态的图标内（即方圆形的图标内，可参考该书的参考图 5-4 和 5-5），而 UML 规范正确的表示法中，状态图标内仅规划成两层(若有动作时)，上层为状态名称，下成则为状态一系列的活动(action)。至于条件变量应该放在转换的图标(连接线含箭头，箭头表示状态转换的方向)成为事件的部份，这就如前面一帖我所说的形式表示，条件放置于中括号内( [ … ])。 

　　以 Rose 来实作相当简单，当你从起始状态(Start state)或其它状态(State)图标里，拉出一条转换线(State transition)，开启这条转换线的规格窗口，并切换到细节(Detail)页次，你会看到有一个”Guard Condition”的项目，你只要在其相对的文字方块中输入条件，例如 StockQty > 0 即可。 

======
原文(homesoft于2001/03/15 20:34粘贴) 
回复: I 服了 U 
--------------------------------------------------------------------------------

大哥，I 服了 U，你是我老大，你博学，还如此不吝啬（你的时间） 
=====
原文(woodysteven于2001/03/15 21:59粘贴) 
回复: I 服了 U 
--------------------------------------------------------------------------------

他的确很熟悉规范，不过你也不必盲目崇拜。陷进UML/Rose的Notation中去不一定是一件好事。UML是方法学，Rose是工具。把眼睛盯在一堆图表上面，那是本末倒置。只要便于理解，状态变量爱放哪儿就放哪儿，真的有什么关系吗？ 
=======
原文(jyemii于2001/03/16 11:40粘贴) 
回复: I 服了 U 
--------------------------------------------------------------------------------

Woodsteven 前面几句讲得不错，不需过于「盲目崇拜」，且过度或过严谨的看待 UML 确实也没有必要。但对于其后半段的话：「UML是方法学，Rose是工具。把眼睛盯在一堆图表上面，那是本末倒置。只要便于理解，状态变量爱放哪儿就放哪儿，真的有什么关系吗？」，我却不敢茍同，而且对woodsteven 于 UML 的一知半解，又将错误的观念指导他人，也深感忧心。 

UML(Unified Modeling Language) 是什么？从他的英文全名就可以看得很清楚了，它是一种模型语言，而不是方法学。UML 里面的各种 Notations(表示法或图标)，是为了让各种不同学派的系统分析及设计的方法论，有一种共通的模型语言(一般都是以图标来表示)，让软件开发的各阶段各观点中，有一种统一的方式来表达系统的观点。既然它是一种语言，就具有语言的各种特色，我们当然无须学会全部的语法，才有办法同别人沟通，也无须完全遵循过于严谨的文法，才认为有能力让别人理解你说什么。但若语法过于贫乏，或乱无章法，我想要让别人从中了解你所要表达的事物或观念，就已经很困难，更何况要他人理解。学习语言是用来与人沟通，重点是「沟通」而非「语言」，所以我赞同 woodsteven 说「把眼睛盯在一堆图表上面，那是本末倒置。」，但我想应该稍微改一下这句话为「把重心放在一堆图表上面，那是本末倒置。」，因为耳朶不听人语，眼睛不看图表，我怎知其所表达。 

另外，究竟需要以多严谨的态度去正视模型语言？这可要看目的而定。若只要使用这些图形达成沟通的目的，只要让对方能够理解，那么就有很大的裕度及空间，我相信不需要一板一眼，语言是应该可以被适当的调整以协助我去与人沟通，而非是毫无转圜或在原地兜圈子。但通常使用 UML，我不会这样做，因为改变语言有时会造成误解或沟通上的困难，不遵循正式的表示法(Notations)，有些开发人员可能无法完全了解你要表达的是什么。 

除上述的情况外，若今天你是用一种 CASE 工具如 Rational Rose，其目的是要让它能够自动产生程序代码，这个时候你就必须遵循此 CASE 工具对模型语言的诠释，才能得到你所期望的结果。这两种情况，绝非一句「只要便于理解，状态变量爱放哪儿就放哪儿，真的有什么关系吗？」，我现在慎重的跟你说，真的就是有关系。 

=====
原文(jyemii于2001/03/17 12:03粘贴) 
并无所谓的对错，而是立论基础不同 
--------------------------------------------------------------------------------

费曼在美国一场演讲中说到： 
　　　作为一个知道「无知哲学」的伟大价值， 
　　　更知道这套哲学可以带来巨大进步的科学家， 
　　　我觉得我肩负着一种责任。 
　　　这些进步乃是思想进步的果实。 
　　　我觉得我有责任大声急呼，宣扬这种自由， 
　　　教导大家不要害怕疑惑，而是要欢迎它。 
　　　如果你知道你很不确定， 
　　　你就有改进现状的机会。 
　　　我要替未来的世代争取这自由。 

Woodysteven 君，我发现你很喜欢谈理论，但实务的经验却显然不足，抱歉，我这样的评论并无恶意，但只是就事论事，这样的讨论很不错，基本上论坛就该如此。而让我有这样的感觉并非毫无原因。我在信息界打混很多年，从程序员、系统分析师、项目经理乃至目前兼任多家公司的顾问，我与你所说的那三位大师其中两位，在几场研讨会上也有所接触，也谈了些东西，既然你说你重视「三位大师在OO建模领域所做的思考和探索」，那么我倒是很好奇，你了解多少？而你对 UML 发展的过程其精神又了解多少？如果你深知于己场 OOPSA 会议中所提出的论点，你上述有几段话就被推翻了，你会发现你所重视的东西，可能并非那么重要，而忽略掉的，反而却是最重要的。 

另外再谈论到另一个吊诡，「方法论与方法的表示法实际上是密不可分的」，因为方法表示法就代表方法论的体现，就很多方面，模型语言是方法论最重要的部分，这么说好象推翻之前所谓「模型语言」非方法论的说法，实则模型语言却也真实的未说明透过怎样的程序去呈现，但是，它却用的确隐含着程序的体现。 

我与伙伴们实作大小项目，与客户或程序员沟通，最常使用的就是模型语言及文件说明，从需求分析、风险评估、初部规划乃至细部规划等等，反而重视的是这些模型语言反映出的理念是否符合需求，文件说明是否齐备，而软件开发程序反而如生活作息或呼吸般自然。这也是为何OMG 协会提出要统一软件开发程序，招各方法论学派封杀后，于 OOPSA’94 会议经几位提出将方法论及方法表示法分离，并且由 Grady Booch 及 James Rumbaugh 宣告，朝统一方法表示法为努力方向时，会有反 Booch 团体联盟成立。以及 OOPSA’95 Ivar Jacobson 的加入、’96年 UML 0.9 的出现，同样为方法论大师级的 James J. Odell 看大势已去，决然放弃自己的标准，而宣告加入 OMG 联合主席并推动统一模型语言的制定，他的决定在于统一模型语言的标准，并不能由 Rational 一手主导。这里面尚有许多小插曲，包含 ’98年 Rational 较 OMG 协会提前公开 UML 1.1的规格，因为在 OMG 尚未公开其官方版本时，三人的著书( UML 使用手册、参考手册及统一软件开发程序)就公开发时，无意造成 OMG 协会的压力，促使接受 UML 1.1 为官方的标准。这件事情虽招致批评，但毕竟是「雷声大，雨势小」，无损其大师的地位，我曾为此问过 Booch，其微笑的回答道，他们无法等到 OMG 制定官方的标准后才发布 RUP。他们也了解方法表示法与方法论实际上是密不可分，一体两面。 

另外，我并没有说必须全部学会整套语言语法，才能与人沟通，实际上表达一个系统，重点在于清楚且易于明了，不竟然整个 UML 全部的图形都要使用，UML 中的重点图形是类别图，状态图仅用来显示类别或系统的状态改变，若可以很简单用批注或文字描述者，我通常不会使用它，除非系统复杂到某种程度，必须以图形来加以辅助说明，其它的图形也是如此。所以，Alistair Cockburn 教导学生的方法是正确的，图形是用来清晰表达系统功能需求的，过多或不足都是错误，那位学生犯的毛病就是「画蛇添足」。 

除此，我也没有说过不能够在实践中使用新的方法了，我说语言本来就是用来沟通用的，若真有必要，我会稍微改变一下语言，因为我相信语言应该能够适当的调整以协助沟通，这种适当的调整就是新表示法的体现。只不过后面我又说，这在大部分的情况下是不需要的，因为大部分的情况，正式的表示法就能符合需求。而且新的方法，除非我能够说明得相当清楚，否则会招致误解。我想你需要回过头去看我立论的重点才是。我相信未来有 UML 2.0 版（事实已在制作讨论中），UML 也会不断的有新创意，但为了与大部分人沟通，我会尽量以他们了解的标准来实作而已。 

对于状态变量的部分，我并没有错，这是由于立论的基准不同，状态图里表现的精神是对象、类别或系统内部状态的表现，状态变量是以程序实作的观点去看，实际上其值存放在对象、类别或系统的属性，对象有能力保有自己本身的状态原本就是对象导向立论的观点之一，表现于程序上面，就是类别属性（可能为 Public、Protected 或 private）。但要在状态图中将它表现出来，实际上并不必要，例如计数器加一，只要使用动作并加以说明就可以了，若真的有需要，唯一的原因是它具有控制事件的能力，并且影响事件触发的条件，但这只要在条件式中表示就可以了。你可以于《UML Programming Guide 设计核心技术》作者的图例 5.8 及说明看到这一切，我想你会有此一说，乃在于你对 UML 的标准不重视的缘故，若以你的方式，当然有此一说。 

希望我们能藉由这个论坛交换心得，因为我真的觉得你很优秀，但仍需琢磨。