協(xié)同軟件中的三個要素

申請免費試用、咨詢電話：400-8352-114

第一節(jié) 軟件工程三個要素的價值

　　 思考問題的方法可以是由點及面的，也可以是統(tǒng)攬全局的。換成業(yè)界最常用的詞匯，就是“自上而下”還是“自下而上”的區(qū)別。

　　 “牛屎圖”中描述的工具、方法與過程也被稱為軟件工程的三個要素。在本書中他們被分解開來思考，并不是要孤立這個三個層面——它們實際上是相互作用的。

　　 例如“過程”問題，就既有實施過程的工具，也有相關的過程方法理論。我雖然說方法是“基于一種數據結構的編程實踐的結果”，但這實在一種非常狹義的定義。這個定義在過程的開發(fā)環(huán)節(jié)上是有效的(或者說是對“開發(fā)方法”的定義)。然而“需求”、 “設計”、 “測試”等其他環(huán)節(jié)也有各自的方法論，即使站在具體環(huán)節(jié)之外，過程本身也有方法論的問題，這還不包括管理方法等在內。

　　 由于方法在過程環(huán)節(jié)及過程總體層面上具有貫通性，因此保證“方法(或其行為)”的實施的“工具”也會出現在過程的各個環(huán)節(jié)和層面上。這樣一來，我們得到的軟件工程模型將不是經典的、層狀的“牛屎圖”，而可能像太極圖一樣由陰陽交匯而生萬物。

　　 為了不使讀者認為我已經人了道家理論的歧途，這樣的一副圖還是交由你自己去畫吧。只不過你應該清楚，即使畫出了太極圖的軟件工程模型，你所視見到的仍舊是工程的細部環(huán)節(jié)。就如同以管窺豹一般，斑是斑，豹是豹。

　　 你能把每一個“管見”拼合起來，你得到的才能是“豹”，而不是“斑”。所以盡管本書割裂了軟件工程的各個要素，并從每個孤立的層面來審視。然而實質上，你應該回歸到電子商務軟件工程的本體上來思考問題，而不是僅關注于每一個局部的要素。

　　 工程的整體問題仍舊是“實現”。

第二節(jié) 其實RUP是一個雜物箱

　　 我或許總是在批評RUP，但是我不得不承認它是對前人在軟件過程思想方面的高度包容。

　　 請注意我用“包容”這個詞，而不是按照語言習慣那樣用“概括”。因為如果是“高度概括”，那你應該把目光投向瀑布模型，而RUP其實就像一個雜物箱一樣“包容”了全部的已知理論。

　　 你可以把RUP定制成其他任何模型所表述的過程形態(tài)——RUP本身的特質決定了這一點——因而它也如同一個雜物箱一樣放滿了各種稀奇古怪的東西。你可能從這個雜物箱里面拿出了一把剪刀，或一只蒼蠅拍，或者是一根釣桿……

　　 喂，等等。面對“軟件開發(fā)”這樣的一個需求，釣桿能有什么作用呢?在你扔掉它之前，請轉換一下你的思維：釣桿可能帶給你的團隊以精神上的激勵。如果你能意識到這一點，那么它將立即轉化為生產力：把釣桿掛在開發(fā)部的墻上。

　　 RUP能不能被用起來，將取決于你剛才那個挑挑撿撿的行為，以及現在你在拿到釣桿后的辨識能力與組織能力。

第三節(jié) UML與甲骨文之間的異同

　　 在你真的打算用甲骨文來寫項目文檔之前，請先明確UML與甲骨文之間的異同。

　　 在這本書里，他們都被作為溝通的工具。因此目標是溝通，而不是“選用工具”這件事本身。更進一步的推論是：即使你因為個人喜好而選擇了甲骨文，也不要試圖在結繩記事的原始人面前去用它。

　　 UML與甲骨文都是符號文字，都具有象形含義。然而這并不表明UML符號本身能表達多么豐富的含義。如果要像甲骨文一樣用幾代人、上千冊的論著去解釋它，那么UML圖的價值也就只剩下象征性的意義了。

　　 出于溝通的必要，這種語言的象征意義在一個圖中應當被表述得足夠準確和詳細，乃至針對于不同的閱讀者來說都能提供充足的信息。然而，一方面UML的規(guī)范中沒有提供一個標準來衡量“怎樣的UML圖是描述充分的”；另一方面，UML作為一個語言，也無法直接在某個環(huán)境或場景中被語法檢錯和調試。

　　 所以在工程中使用UML圖，應該有相應的文字來描述它。而且這種描述與圖之間的對應關系要持續(xù)地維護下去。如果這種關系松散了、斷裂了，那么下一個閱讀UML圖的人所面對的，將是無異于甲骨文出土時的困境。

　　 好在做UML圖的那個工程設計人員(在辭世之前)還有機會為這些古符號寫下規(guī)約。