軟件測試開發技術UML環境表示法職責和程序語言職責

軟件測試開發技術UML環境表示法職責和程序語言職責  UML模型

關鍵字：UML 程序語言 · 表示法職責


表示法并不是給模型增加含義，而是幫助用戶理解模型的含義。表示法沒有語義，但它經常為用戶加入一些內在涵義，如在一張圖中基于相近意義的兩個概念的密切聯系。
　　 UML文檔[UML-98]和本書定義了一套規范的UML 表示法，可以稱作模型的格式出版。這和許多程序設計語言類似，把期刊文章中的程序印刷成有吸引力的格式，包括仔細的規劃、用黑體保留字表示的，且每個過程用不同的圖形來說明。而實際的編譯者不得不接受較為凌亂的輸入。我們期望編輯工具能把表示法擴展成屏幕格式，包括諸如使用不同的字體和顏色加亮條目，簡單地刪除和過濾不需要使用的條目的能力，放大圖像以展示圖中的嵌套元素的能力，通過超文本熱鏈轉入其他模型和視圖的能力，以及動畫功能。試圖將所有這些可能的項目都標準化是不可能的，也是愚蠢的，因為沒有這個必要，而且這樣還會限制有益的創新。這種表示法的擴展能力是工具制造者的工作。在交互式工具中，產生二義性的危險不大，因為用戶總能找到一個明確的解釋。這也許比堅持一種粗看上去沒有任何二義性的表示法更有用。這個觀點是說：當需要時，一個工具必須能生成規范化的表示法，特別是在印刷格式中，但在使用交互式工具中也應該采用合理的擴展。
　　 我們仍期望工具能讓用戶有限制但又有效地擴展表示法。我們已經規定構型型可以有自己的圖標。對其他的表示法的擴展也是允許的，但用戶要謹慎使用這些擴展機制。
注意，表示法不僅僅是圖片，它還包括基于文本格式的信息和元素中間不可見的超鏈接。


· 程序語言職責

UML 必須在沒有與不同的實現語言明確地合并時與它們共同使用。我們認為 UML應該允許任何程序設計語言（至少是多數）的使用，包括規格說明和目標代碼生成。問題是每種程序設計語言都存在許多我們不想吸收到UML中的語義，因為它們作為程序設計語言來說很好控制，而在執行語義中有相當大的變化。例如，并發的語義在不同的語言中存在不同的處理方法（如果能夠處理這些語義）。
　　 UML中沒有詳細地描述簡單數據類型，這么做是經過深思熟慮的，因為我們不想把我們偏愛的一種程序設計語言的語義合并到其他所有語言中。對于多數的建模目的，這不是一個問題。應使用適合于你的目標語言的語義模型。這是語義變更點的一個例子。
　　 詳盡的語言實現特性的表示使得在不把實現特性的語義內置到UML的情況下，帶來了捕獲其信息的問題。我們的方法是通過構造型和標記值捕獲超越了UML內置能力的語言特性，這些可以由工具或代碼生成器分配給語言給性和代碼生成選項。一般的編輯器不需要理解它們。事實上，用戶可以用一個不支持目標語言的工具創建一個模型，然后把最終模型轉換到適用于最終處理的工具。當然，如果工具不能理解構造型和標記值，那么它不能對它們進行一致性檢查。但這并不比用文本編輯器和編譯器差。如果必要，可以創建一個工具來使用UML語言的一組特定的擴展。
　　 在可預知的未來，代碼生成和逆向轉換不僅需要UML模型，還需要設計者的輸入信息。代碼生成器需要的指導和提示可以由標記值和構造型提供。例如，建模者可以指定哪種包容器類用于實現一個關聯。當然，這種工具中的代碼生成設置方法也許是矛盾的，但目前沒有一種標準化的實際設置方法。目前不同的工具均使用對自己有競爭優勢的代碼生成器，但最終將會出現缺省設置并發展為成熟的標準。

原文轉自：http://www.anti-gravitydesign.com