關于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 的標準不重視的緣故，若以你的方式，當然有此一說。 

希望我們能藉由這個論壇交換心得，因為我真的覺得你很優秀，但仍需琢磨。