統一建模語言UML釋義之（三）

2019-11-17 04:41:16

字體：大中小

來源：轉載

供稿：網友

　　從設計程序之初我就沒有打算把建模讓給別人去做，我這并不是自私，引用兩句名言來說明我的觀點：一拿破侖：“不想當將軍的士兵不是好士兵”；二張五常先生的《經濟解釋》“要現實公司利益的最大化，必然使得能讓公司最大化的人來當排頭”。

　　我雖然沒有從出生以來就開始注重建模，但也開始學習搭積木了，大家和我一樣期待著成為軟件模型的設計者，但是要怎么樣做，又從那開始做呢？

　　在給UML欄目寫東西的時候，我一直從事軟件開發，是中國傳統方式的操作—作坊式的，公司三五十來個人，連個軟件小組都稱不上。我雖然不是軟件開發組的組長，但我是唯一的一個把文檔整理好給別人的人。我告訴同事我的三個優點：我很會和客戶打交道；我很會寫一份詳盡的文檔；我很會整理，使得一件復雜的東西簡單化。

　　一．開始構想我們的軟件

　　除了無用的哲學理論之外，我還不知道哪一件東西可以憑空產生。我們開發的軟件是供別人使用，學過經濟學人都知道經濟開始的三個要素：為誰生產？生產什么？如何生產？

　　我們可以圍繞這三個因素來開始談論軟件建模：

　　a：為誰生產

　　在軟件的領域內我簡單把該項過程考察為：軟件的需求分析（在最近幾期的《程序員》雜志上有高展先生的具體論述）。站在客戶的角度（客戶正是我們為之生產的對象），有兩個方面的需求：一是該軟件產品符合操作規范；二是該軟件產品操作簡單方便、界面友好。許多人都知道軟件開發過程中的許多問題，都是由于收集、編寫、協商、修改該軟件產品的代碼、文檔（有的人把代碼也列入文檔）時由于失誤、馬虎、未確定或不明確等因素造成的。我在軟件工程上找到“客戶”兩個字的解釋：是指直接或間接從產品中獲得利益的個人或組織，包括提出要求、支付款項、具體說明或使用軟件產品的項目風險承擔者或是獲得產品所產生的結果的人。

　　其實，客戶的如此兩個字并不能說明我們為誰生產的生產對象，作為軟件的開發者已經很了解各個軟件開發的差異性，假如說客戶是機器（當然機器也是人操作的嗎？），我們為之開發驅動程序、操作系統等；假如是商業使用我們為之做CRM、ERP等商務軟件或與其相關的財務軟件。如此說明就象我們是在建造商務樓還是在造民房。

　　當然為誰生產的本質并不重要，因為它們在實現起來是一樣的。

　　b：生產什么

　　沒有不罵我是白癡的，講了半天的軟件了，還在問這是生產什么？

　　如此說法是正確的，但仔細一想就知道這個問題的答案還很難回答，雖然這是微軟風格但也必須把它說明。

　　在為誰生產的問題中已經有些說明了，生產什么，當然是用戶說了算，我們生產什么，我告訴你：“我們生產用戶所需要的”。但用戶到底是需要什么？在軟件的需求中我們賦予用戶一些權利：可以要求軟件使用客戶語言規范；要求軟件跟蹤客戶的系統業務目標；要求軟件對產生結果或數據進行具體的說明；要求軟件符合質量要求。

　　根據軟件的種類我們來列舉一大堆的例子分析說明我們軟件開發者生產的是什么：操作系統啦、驅動程序啦或者媒體播放軟件啦．．．．．．

　　其實不然，我生產的是根據用戶提出的軟件設計的模板來進行軟件生產。

　　c：如何生產

　　先談談分析和設計的區別：“分析是一門科學，設計是一門藝術”，說話者的意思是在所有的“正確”分析模型中只存在一個最“正確”分析模型可以完全滿足解決某個具體問題的需要；當然軟件的建模也同樣是合乎其理的。需求分析需要一絲不茍、精確的完成,而軟件設計的時候反而可以發揮創造力和想象力，不然世界沒有進步了。

　　在實際的操作過程中，軟件的設計者（我還不能包括在內）經常碰到一個問題就是：對軟件的理解在開發的過程中才愈來愈深，在設計的初期軟件的設計者并沒有對軟件如此理解，如此便造成一種假象：好象是需求經常改動。其實不是，客戶對待軟件的需求并沒有變，但由于交流或其他方式的接觸，使得軟件設計者對軟件的理解加深了，我們改變了對需求的理解而不是需求變。

　　根據軟件的需求，我們如此而知到軟件開發的目的。

　　有了目標我們必須找一條路走過去，而這條路就是如何生產了。

　　首先，軟件的設計不可避免的需要寫文檔，按照軟件設計規范，軟件文檔有十三種，每一種對應于軟件開發的一個時期（具體的內容以后再談）。

　　其次，根據軟件的文檔開始編寫代碼，該代碼就是軟件的源代碼，源代碼的開發在目前的國內軟件開發上還是占據主要的份額（其實這個問題在我身上基本上消失了）。

　　再，軟件測試，具統計很少有人愿意干此類的活，雖然每個人都知道該項很重要，在前面的釋義(二)我已經講了心態的問題了。

　　最后，把開發好的軟件放在有電源的設備，并為之添加硬件和軟件的環境支持，使其運行。在運行的過程中進行軟件維護。

　　二．做些預備工作

　　別把建模當回事（當然說這個話是有目的），建模就是讓別人知道如何操作自己而來實現別人對你的要求。模也就是一個Document（使用MFC的兄弟應該對此有很深的體會），但如何把Document敘述的詳盡，完整和條理，為此我們（當然不包括我了）利用UML定義了一套標準來規范文檔的寫作。

　　為此，理解你要實現的東西是一件建模初期的事，在理解的基礎上我們并不能忽略現實的簡單性，所以，好的軟件設計人員把大多數時間花費在建立系統模型上，偶然寫一些源代碼，但那只不過是為了驗證設計過程中所碰到的問題。這將使他們的設計方案更加可行。我在工程的實踐中，碰到了一系列問題，但問題反映出來，其原因有如下幾個大問題：

　　1．設計者就是設計者

　　設計者如此費力地把模型搭建起來，然后再費力向各個程序員具體地說明該軟件開發的具體步驟，若程序員的水平太差，再給他們寫些原代碼示例，如此以來，還不如自己寫算了，設計者就是設計者，并不需要實際深入地參與軟件原代碼開發，但應參與其他文檔地編制。習慣了好象我們成了幼兒園的老師。

　　2. 教育你的程序員

　　你花了很大力氣建立一個很成熟的系統模型，而你的聽眾卻不能理解它們，甚至更糟－連為什么要先建立模型都不知道。那么你的工作是毫無意義的。

　　教給你開發人員基本的建模知識；否則，他們會只看看你畫的漂亮圖表，然后繼續編寫不規范的程序。其實該問題是如此地實際，但也正是該問題困擾著我目前的開發狀況，例如：我用Playcase的開發工具做了一套流程，使得程序編寫起來模塊化，第一沒有人看懂如此設計文檔，我開始講述如此建模知識；第二有些開發人員學習過其他的建模語言，對此開發工具指手劃腳，其實工具并不重要，重要的是用它來實現東西。

　　另外，你還需要告訴你的用戶一些需求建模的基礎知識。給他們解釋你的用例(uses case)和用戶界面模型，以使他們能夠明白你要表達地東西。當每個人都能使用一個通用的設計語言的時候，你的團隊才能實現真正的合作。

　　3. 在現有任務中應用多個模型

　　當你收集需求的時候，考慮使用用例模型，用戶界面模型和領域級的類模型。

　　當你設計軟件的時候，應該考慮制作類模型，順序圖、狀態圖、協作圖和最終的軟件實際物理模型。

　　程序設計人員應該慢慢意識到，僅僅使用一個模型而實現的軟件要么不能夠很好地滿足用戶的需求，要么很難擴展。

　　4. 證實你的設計在實踐中可行

　　在設計的時候應當先建立一個技術原型，或者稱為“端到端”原型。以證實你的設計是能夠工作的。軟件的設計最忌諱的就是使用不成熟的技術來開發軟件產品，我的朋友和談天的時候說：“我用最成熟技術開發最實用的軟件”,“首先客戶需要的是一個成熟的軟件，穩定、可靠，假如采用最新的技術，由于沒有經過時間的檢測，不能保證其運行的穩定性”。

　　你應該在開發工作的早期做這些事情，因為，假如軟件的設計方案是不可行的，在編碼實現階段無論采取什么措施都于事無補。技術原型將證實你的設計的可行性，從而，你的設計將更輕易獲得支持。

　　5. 治理接口和使用接口組件

　　你應該在開發階段的早期就定義軟件模塊之間的接口。我是電子商務軟件的，對于COM/DCOM組件的使用需要深入地研究下去，這個研究的目的就是使得軟件模塊的接口方便、簡易、易于治理。

　　接口或接口型組件將有助于開發人員全面理解軟件的設計結構并取得一致意見，讓各模塊開發小組相對獨立的工一旦模塊的接口確定之后，模塊怎樣實現就不是很重要了。從根本上說，假如你不能夠定義你的模塊“從外部看上去會是什么樣子”，你肯定也不清楚模塊內要實現什么。我想再說一次愛因斯坦的話：“外部的證實，內部的完備”。

　　6. 軟件的移植性和封裝

　　移植是軟件開發中一項具體而又實際的工作，不要相信某些軟件工具的廣告宣傳（當然廣告的宣傳是帶有軟件的商業性質）。

　　即使僅僅對軟件進行常規升級，也要把這看得和向另一個操作系統或數據庫移植一樣重要。記得從16 位Windows 移植到32 位windows 的“樂趣”嗎（微軟公司又開始掙我們的錢了）？當你使用了某個操作系統的特性，如它的進程間通信(ipC)策略，或用某數據庫專有語言寫了存儲過程(DCOM/Istorage或其他策略)。你的軟件和那個特定的產品結合度就已經很高了。

　　好的軟件設計者把那些特有的實現細節打包隱藏起來—我比較隨便把這種東西叫封裝（也可能我是C++等OO技術的愛好者），所以，當那些特性該變的時候，你的僅僅需要更新那個包就可以了。

　　7. 降低軟件模塊間的耦合度

　　高耦合度的系統是很難維護的。一處的修改引起另一處甚至更多處的變動，其實這種變動在數據庫領域內更讓你有很深的體會，尤其是現在人們常用的關系數據庫，修改起來很象株連九族一樣。

　　你可以通過以下方法降低程序的耦合度：隱藏實現細節，強制構件接口定義，不使用公用數據結構，不讓應用程序直接操作數據庫。

　　耦合度低的軟件可以很輕易被重用、維護和擴充(那什么軟件耦合度低—采用中間件，這么這些都是我喜歡的)。

　　8.最后的絕招

　　詢問.學習.整理。

　　這個沒有人教的，全是我悟出來的。但這是軟件設計人員的過程：1、詢問客戶建立需求文檔；2、學習研究需求文檔，測試設計的可行性；3、整理文檔，編寫設計文檔。進入討論組討論。

上一篇：用Avalon建立未來的Windows用戶界面

下一篇：VS.NET2005 Beta2初體驗