=====
原文(woodysteven于2001/03/16 16:25粘貼) 
嘿，你是錯的！ 
--------------------------------------------------------------------------------

我說UML是方法學，這句話的確不太準確（至少從字面上是這樣）。但這實在是因為我并不特別在乎UML的Meta-Model而已。對我而言，真正的UML是UML背后的東西 —— 三位大師在OO建模領域所做的思考和探索。學習UML，重要的是學習Unified Method，而不是UM-Language。 

我也知道思想需要借助形式來表達，但這種表達形式本身卻是值得探究的！在UML0.9以前，OMT和Booch的方法在表達形式上就存在很大的區別，它們之所以走到一起來，是因為在這些不同的表達形式背后存在共同的語義和互補的方法。Booch 就曾經改變了它的著名的類圖表示（從云圖到UML的矩形框），關于這個，我又想說：這有什么關系呢？ 

我最近在看一本Buhr書，他介紹了一種新的方法用來填補UML中需求分析和系統設計之間的鴻溝。為了表示他的方法，自然也推出了一套新的Notation和Meta-Model，不過并不規范和完善，也就是說他沒有精確地告訴你某個東西一定要放在什么地方。可是，這本書非常的好，連 Ivar Jacobson （Use Cases 創始人，Rational公司的首席科學家）也極力推薦。問題是，在這本書出來的時候并沒有任何Case工具支持它的Notation，我們就更不可能在這里討論它的關于“狀態變量應該放在那里的問題”。那么，是不是就是說，我們就不能在實踐中使用這種新的方法了呢？如果真是這樣，這個世界就永遠不會有雞和雞蛋了。 

Alistair Cockburn教它的學生使用Use Case，然后布置了一道作業。有一個十分好學的學生幾乎把他所知道的所有圖形元素都用上了，結果他交給Cockburn一張十分龐大的Use Case圖（包括用來描述Use Case的順序圖）。你想情況會怎樣呢？本來Use Case是用來清晰表達系統功能需求的，可是從那張復雜的圖來看，誰也無法知道這個系統準備做什么！ 

我想，你現在開始明白我想講什么了：形式固然重要，可是并沒有什么證據使我相信現有的圖形表達方式一定是最好的，或者說存在某種唯一正確的表達方式。我知道國外有很多建模方面的專家，他們甚至討厭Case工具，而寧愿使用字處理器。可是他們確實是在做OO建模，甚至也是在使用UML。 

你是不是偶爾也會覺得，打開一個Rose工程文件，從那堆各種各樣的圖示里邊，你其實很難對一個系統產生整體的把握？至于利用Rose來生成代碼，我真的沒有在這上面看到多大的希望。我很想知道這里有多少朋友，在整個工程周期中都一直在使用Rose的這一功能？如果有的話，你們的生活有沒有因此感到愜意？ 

國內的軟件人員有時侯是太遵循標準了，以致于沒了標準就不知道該怎么走。殊不知，制定標準的人已經在思考下一個標準了。我覺得，OO是一個特邊緣的領域，很多東西都沒有成型（不像經典物理，被老牛一個人玩完了），如果在這里都不能有所考、有所創新，咱們就真的完了。 

另外，我想告訴Jyemii：你關于狀態變量的回答其實是錯的。而《UML Programming Guide 設計核心技術》的相關內容并沒有錯。實際上你所說的并不是狀態變量，而是守衛條件（guard-condition）。條件與變量是兩碼事，條件是變量和臨界值構成的布爾表達式。舉個例子，客人訂票可能使某個航班的狀態從Open變為Close。在這里，訂票是觸發事件，相應的Action是“扣減座位”。如果座位沒有了，航班應該停止售票并且轉入Close狀態。為了跟蹤這一變化，航班類顯然需要維護一個“剩余座位數”變量，這個“剩余座位數”才是狀態變量，它用來刻畫航班的當前狀態。由于這個變量實際上是一個普通的類數據成員，如果要表達出來的話，當然應該畫在類框里面（根據UML關于類框的規范）。UML規格文檔(version 1.3)在說明狀態框的時候只規定了狀態名稱和Action List的畫法（分別畫在兩個子框里），并不等于我們就不能把類的其他屬性表達出來。正因為這個原因，《UML Programming Guide 設計核心技術》在有的地方把狀態框分成了三個子框，加入了狀態變量的表達，是一種更詳細的表示方式。至于守護條件，在這里顯然應該是“座位數 = 0”，它如果畫在觸發事件的旁邊（形式為：Trigger[guard-condiction]），表示“當且僅當事件發生且布爾表達式成立時，狀態轉移才發生”。另一種形式是：守衛條件可能直接觸發狀態轉移，此時，狀態轉移箭頭上只有[guard-condition]，而沒有觸發事件。 

最后，我想告訴Homesoft，只要理解了狀態變量和守衛條件的真正含義，即便不看UML的文檔，你也絕不會把他寫到紙的背面去。我想講的就是這個意思。 
====
回答非常出色！補充：UML是建模語言，因為沒有定義過程，因而不是方法學。 - <0b> zjunerd 2001/03/16 20:03 (31次點擊) 
===
回復: 可能問題太難了，你們都不會！ - <0b> homesoft 2001/03/11 21:34 (20次點擊) 
====
原文(Ms.OO于2001/03/11 22:17粘貼) 
是比較難呀老兄，我用Rose做了兩個項目了，還是回答不出你的問題 
--------------------------------------------------------------------------------

你那個界面的圖倒是可以探討一下，能不能傳一張真圖到圖片共享，文字看起來怪怪的。 
====
回復: 圖已經上傳了，分別叫 教學界面與教學頁面1、2 - <0b> homesoft 2001/03/14 21:00 (18次點擊) 
===
原文(woodysteven于2001/03/17 12:35粘貼) 
回復: 圖已經上傳了，分別叫 教學界面與教學頁面1、2 
--------------------------------------------------------------------------------

這里線索太深了，我另外開了一個線索用于專門回答這個問題。 
===
請問什么是狀態變量？ - <0b> lgjut 2001/03/12 09:34 (17次點擊) 
===
原文(dysang于2001/03/15 11:40粘貼) 
回復: 請問什么是狀態變量？ 
--------------------------------------------------------------------------------

狀態變量是否是指生存周期僅限于對象處于該狀態下的屬性變量？可以用來存放同特定狀態相關的數據？ 
====
原文(fact-finder于2001/03/16 19:52粘貼) 
回復: 請問什么是狀態變量？ 
--------------------------------------------------------------------------------

說具體點：設計范圍？實現語言？英文名字？在哪里出現？ 
=====
原文(ken_xu于2001/03/14 20:32粘貼) 
回復: 關于Rose及UML的10個問題，請高手賜教。 
--------------------------------------------------------------------------------

no.5 
在rose中用Package（stereotype is "layer"）表示三層結構中的層。你可以在Logical view中產生一個package(Design Model)，然后在Design Model中建立三個Package，分別表示Application, business services, database, any other. It depends your project. 

=====
原文(ken_xu于2001/03/14 20:38粘貼) 
回復: 關于Rose及UML的10個問題，請高手賜教。 
--------------------------------------------------------------------------------

no.2 
我不知你所說的類圖中的空矩形是何意。 
還有我也不知你上指的Document是何東東。 
類圖中只有Note,text box. 
Note通常用來注釋。Textbox通常用來加條件（For instance, [if a>2])。這只是我們使用當中的一個約定。我沒有看到瑞理有什么Convention. 
=====
原文(ken_xu于2001/03/14 20:44粘貼) 
回復: 關于Rose及UML的10個問題，請高手賜教。 
--------------------------------------------------------------------------------

no.9 
我也想選中所有的類，然后再操作。但是好象不可以。Rational軟件在操作方面有很多bug. 

no.10 
在rose2000e中子系統用包表示，使用subsystem stereotype. 
可能視覺上不怎么明顯，但確實是這樣的。 

no.6 
I think it don't run. 

=====
原文(homesoft于2001/03/14 21:22粘貼) 
回復: 整理一下答案 （還有1,3,4,7沒結果） 
--------------------------------------------------------------------------------

原文(homesoft于2001/03/14 21:14粘貼) 
回復: 狀態變量 
狀態變量 是 我在《UML Programming Guide 設計核心技術》看到的。page 81 

原文(ken_xu于2001/03/14 20:32粘貼) 
no.2 
我不知你所說的類圖中的空矩形是何意。 
還有我也不知你上指的Document是何東東。 
類圖中只有Note,text box. 
Note通常用來注釋。Textbox通常用來加條件（For instance, [if a>2])。這只是我們使用當中的一個約定。我沒有看到瑞理有什么Convention. 

原文(ken_xu于2001/03/14 20:32粘貼) 
no.5 
在rose中用Package（stereotype is "layer"）表示三層結構中的層。你可以在Logical view中產生一個package(Design Model)，然后在Design Model中建立三個Package，分別表示Application, business services, database, any other. It depends your project. 

原文(ken_xu于2001/03/14 20:32粘貼) 
no.6 
I think it don't run. 

原文(john_zhu于2001/03/12 09:46粘貼) 
no.8 
將以前逆向工程生成的一個mdl按照包導出為patel file，再導入 

原文(ken_xu于2001/03/14 20:32粘貼) 
no.9 
我也想選中所有的類，然后再操作。但是好象不可以。Rational軟件在操作方面有很多bug. 

原文(ken_xu于2001/03/14 20:32粘貼) 
no.10 
在rose2000e中子系統用包表示，使用subsystem stereotype. 
可能視覺上不怎么明顯，但確實是這樣的。 

====
原文(tacone于2001/03/17 15:01粘貼) 
回復: 關于Rose及UML的10個問題，請高手賜教之NO.7 
--------------------------------------------------------------------------------

回復NO.7 

等了好幾天,未見有人應答此問,故冒昧發言： 
答案很簡單,兩者相權,當毫不猶豫選圖2(閱者可參見"圖片共享"的原圖)。 
教學界面與教學頁面圖1(下簡稱圖1)同教學界面與教學頁面圖2(下簡稱圖2)雖頗相似,但境界截然不同,因為圖2使用“教學頁面”到“教學界面”的聚合,系統更具可塑性、可擴展性,抽象度更高。試想一下,如果頁面太多，可能從“教學頁面”派生“目錄頁面”，用于導航，另外可能還要從“基本知識教學頁面”、知識問答教學頁面”派生其他子類，這時候用圖1則修改量大，并涉及到“教學界面”的修改，而用圖1則只需做派生子類，系統邏輯保持完好。 
基于以上理由，該模型作為原型還可以，要轉化為系統還有如下幾方面值得商榷： 
1)界面控制不一定只有按鈕一種，為保持擴展性，故應為“控制按鈕”引入一超類“控制組件”，改成“控制組件”到“教學界面”的聚合。 
2)增加“控制組件”到“教學頁面”的聚合，使頁面更具表現力。 
3)口口口口口口口口(此處省略若干字) 
4)口口口口口口口口(此處省略若干字) 
(由于不了解需求和系統規模,第3第4點不敢妄提,會增加復雜度,有興趣另帖探討). 


附:圖1與圖2差別是OOP建模與OOSE建模的差別,OOSE建模會更多地考慮REUSE、系統可塑性、系統表現力、用戶需求及其變動，這也是中國PROGRAM強SOFTWARE弱的原因。 
另：為何不直接采用BROWSER/WEBPAGE的方式開發，那樣建模會大大不同。請回答。 

===
原文(woodysteven于2001/03/18 00:39粘貼) 
回復: 關于Rose及UML的10個問題，請高手賜教之NO.7 
--------------------------------------------------------------------------------

我們的觀點基本一致。 

另外我覺得Homesoft的模型里面并沒有限制不可以用Web方式實現呀？ 
====
原文(tacone于2001/03/19 02:26粘貼) 
回復: 關于Rose及UML的10個問題，請高手賜教之NO.7 
--------------------------------------------------------------------------------

主要是對“教學界面”類有看法，如果它對應瀏覽器，則“控制按鈕”類就顯得沒必要,在某CLIENT上瀏覽器的實例要有限制，否則會破壞約束。 
====
原文(liaofan于2001/03/18 17:57粘貼) 
回復: 關于association class 
--------------------------------------------------------------------------------

只需要點擊association class再連接關聯和相應類就可以設置association class了