Java 建模：子整體軟件開發

2019-11-18 14:18:22

字體：大中小

來源：轉載

供稿：網友

Granville Miller 暫時放棄需求收集主題，著手討論另一個引人入勝的主題：子整體軟件編程。讓我們找找這個方法如何補充和擴展靈活開發運動原則，以及它在主流開發界中的出現如何可能改變軟件開發者的教育和軟件開發實踐。請在討論論壇與作者和其他讀者分享您關于本文的想法。
在我早期專欄的結論中（請參閱參考資料），我曾許諾此專欄將會專門討論靈活開發過程中需求收集的各種方法。然而，當我開始著手那個專欄時，我意識到可能值得從靈活軟件開發這個較大的討論開始。但當我開始著手那個主題時，我發現自己渴望去討論子整體軟件開發這個相關主題。

這并不希奇，因為我相信子整體軟件開發是靈活軟件開發的下一步。我對此十分雀躍，我選擇改變我的路線，并且引入我非常獨特的子整體軟件開發宣言。我們將在下一次返回需求收集這個主題。

靈活軟件開發
靈活軟件開發運動對軟件工程的理論和實踐造成了巨大的沖擊。它的擁護者成功的挑戰和駁斥了實踐證實的優秀的系統開發準則，并用自己的來代替它們。運動的基礎在于四個核心價值，在靈活軟件開發宣言中第一次對它們進行了概述（請參閱參考資料）：

個人和交互優于過程和工具
有用的軟件優于綜合的文檔
客戶合作優于合同協商
對更改作出反應優于遵循計劃
實際上，這些價值標志著對那些受傳統軟件開發方法支持東西的背離。最高目的在于創建一個更有益于成功的軟件開發環境。的確，靈活運動在軟件開發的歷史上留下了自己的印記。然而，雖然靈活運動具有革命性，但它究竟只是更復雜更有益的開發實踐的第一步。子整體軟件開發才是下一步。

過程是第一位嗎？
在工業革命時期，Frederick Winslow Taylor 先生對人的工作方式進行了研究。他進行了時間和動作的研究，目的在于優化身體技能的使用，有效的創造產品。Taylor 的出名在于他對效率原則的執著。他聞名的引述概括了他對工業時代工人的心情：“過去，人是第一要素，而將來，系統很可能會成為第一要素?！?br />
效率的追隨和系統第一或者說過程第一原則是現在我們稱為質量治理的兩個基本組成部分。質量治理就是研究和實現那些正確的實現就會提高質量的活動。要害詞是正確的實現。這些詞組成了質量治理的安全港灣式表述。可以肯定的說假如您的業務、制造或工程實踐不能提高質量，您就沒有正確的實現它們。

雖然我不相信軟件開發中存在質量治理危機，但我的確看到了失敗正在我們的行業中產生。這些失敗往往是過程和技術造成的，理由在于過程沒有被正確實現或技術不成熟。不過我覺得把失敗歸咎于過程和技術經常是一種逃避。尤其當您考慮 Alistair Cockburn 的斷言 ? 在成功的軟件開發中過程和技術是第二位要素（請參閱參考資料）的時候。

人是任何軟件開發項目的第一位要素。任何好的第一線治理員知道他或她的小組成員是項目首要和最有用的資產。一個永遠不會被取代的軟件開發準則是優秀的人編制優秀的軟件。不過，假如這樣的話，開發項目失敗時，我們該歸咎于人嗎？答案是否定的！

子整體（holon）
我相信，尋找能反映優秀的軟件開發技巧的行為的最佳地方是不太可能的。只有戰場。對于導致單個士兵取得巨大成功最有用的兩個準則是練習和主動性。最棒的軍隊答應單個士兵在戰斗期間對于如何達到他們的目標作出決定。許多戰斗勝利是通過許多士兵作為個體思考和行動、同時又作為團隊一起戰斗而取得。

一個維持自身獨立性、同時又作為整體的部分發揮作用的實體稱為子整體（holon）。這個術語是 Arthur Koestler 通過把詞整體（holos 或者說“the whole”）和部分（on 或者說“the part”）相結合而發明。子整體曾用于描述社會、細胞和組織的行為，還有最近的制造行為。我相信子整體的（holonic）行為是軟件開發者實際的并且很可能是理想的工作方式。

事實是，在開發軟件時，我們繼續遵循了 Frederick Winslow Taylor 的思想。時間和動作的研究提出了學術上軟件工程周期的令人驚異的規律。然而，軟件開發，就像信息時代許多其它要素一樣，已經和時間和動作無關了。與之相關的是創造、革新和人。

對于軟件開發，我們繼續了工業時代誕生的思想 ? 死守著基于制造業的裝配線生產的思路和環境。在這個環境中，個人是成不了氣候的。他沒有授權制造變革，也因此在要求變革的生命周期（軟件開發周期）失敗時，不該歸咎于他?；蛟S，是時候停止把過程和技術作為第一位要素了，讓真正的第一位要素 ? 人 ? 作為中心。

子整體軟件開發
軟件工程是一種手藝。它需要運用聰明。它的準則很復雜且需要知識。最好的準則仍處于開發狀態。因為軟件工程領域如此廣博，沒有哪個人可以完全“把握”它。還因為這一領域在不斷發展，知識的保持需要不斷努力和學習。

假如您是個優秀的開發者、建模者或治理員，您該知道我的意思。您曾面對多種技巧，然后例行公事的選出一種用于工作的最好的技巧。您在危機中調整并設法找出一種解決方案。您使子整體具體化。您需要一個在任何給定時刻指定您接著該做什么的軟件開發過程嗎？根本不需要。

真正的子整體軟件開發組織承認不同的人有不同的思維方式。有些人的思維方式是抽象的、其他人是具體的；有些人是戰略上的計劃者，其他人則以行動為取向。子整體組織使用的技術使人們在選擇完最佳工作方法的同時共同工作。這些組織答應人們用他們發現的最佳方法工作。簡言之，子整體軟件開發要求不斷的學習和個體適應。它鼓勵差異。

培訓模型
我作出這些警告的斷言 ? 我們的培訓沒有像它應該的那樣成熟。與之相比，士兵的練習可以回溯到幾千年前（最保守估計）。它已經發展成熟了許多個世紀。新的技術改變了我們作戰的一些方法。但戰爭的很多基本模式沒有因技術的改變而改變，士兵的練習也是如此。在我們接納技術上的改變時，還要適應這些永恒的教訓。

有效戰斗練習的一半是提供士兵一個可供選擇的戰爭戰術庫。另一半涉及到教它們隨著練習創造出自己的戰術。同樣，我要鄭重公布軟件開發者有效教育的一半在于知識和技能的獲得。另一半在于學習對變化進行處理、在不斷變化的領域中快速前進。簡言之，去革新。

沒有安全網的軟件開發
許多軟件開發過程幾乎不提供安全網。有些人提議重復過程自身，就似乎不斷重復查看同一個狀態圖最終就會得到更多信息一樣。重復我們的助診文件可以改善它們，但只有引入反饋方法后才生效。當有必要知道我們在何處有可能誤入歧途時，簡單的重復是不夠的。

補充活動
一種可以結合進來以糾正預期錯誤的活動正成為一種成長趨勢。這種活動稱為補充。例如，我們用域分析權衡用例建模以確保隨后的對象模型不起作用。這些補充性的活動可以讓我們不犯常見錯誤。

沒有了補充活動，第二位要素如過程和技術成為我們唯一的安全網；假如我們陷入困境，我們可以歸咎于它們。因為大多數軟件開發過程最多只有兩維，或許這種歸咎是它們應得的。的確，除了給我們控制的感覺，過程再無其它用途，它是一張虛假的安全網。

過程？什么過程？
這是不是意味著您可以拋掉軟件開發過程并真的在沒有安全網的支持下開發呢？除非您有預備接受項目失敗的責任。

在另一方面，假如您沒有在適應，您就不會嘗試做事情的新方法。假如您不嘗試新的東西，您就不會學習、發展并成為最優秀的。這是個不斷探索的過程，我們中沒有哪一個人有可能在任何時候馬上完成。

即使您選擇了已建立過程的安全網，您也不一定在完全的遵循它。除非小組的每個人的想法相同才不會這樣。假如您的確找到了小組中每個人都覺得最佳并適用于您所從事的所有項目的終極過程，請發送給我。然而，我并不期待收到許多滿足上述條件的過程，因為 Jacobson 定律表明這種過程不存在。我相信即使在高度團結的小組中，也沒有哪個過程會適合每個人的思考方式。我們之間存在著太多的差異。

結論
子整體軟件開發是靈活運動的邏輯擴展。它需要高度理解用于編制軟件的技術，還需要開發者對交付使用系統負責。子整體軟件開發小組把過程用作指南，而不是支柱。該小組并不墨守成規，或者說當常識起支配作用時忽略過程。

本文不是一篇定義，而是宣言。其中提出了一種較好的交付使用軟件系統方法的見解，此方法利用許多靈活過程中定義的活動。同樣，我考慮了軟件開發的最佳準則和作為開發期間糾正錯誤方法的緊迫的補充活動。

我們將在下一專欄繼續討論這個主題，其中我們會返回已許諾的關于用例、功能和用戶情景的討論。我將向您展示如何讓這些元素成為您子整體軟件開發工具箱的一部分，并且還將描述這些元素如何支持一種前載的、平衡的或后載的編制軟件方法。請別離開。

參考資料

請參與有關本文的討論論壇。

有關前載與后載軟件開發過程對比的討論，請參閱 Granville Miller 的文章 “Sizing Up Today′s Lightweight Software PRocesses”（IT Professional，2001 年）。

在 Agile Alliance 主頁您會找到“靈活軟件開發宣言”（Manifesto for Agile Software Development）。

Alistair Cockburn 的主頁反映了他對于靈活軟件開發的個人討論（還有他將于 2001 年后期由 Addison-Wesley 出版社出版的書的預先介紹）。

另一個靈活過程，極端編程（Extreme Programming）得到了重大關注。Role Model Software 的開發者 Roy Miller 和 Chris Collins 在他們的文章 XP 精粹（developerWorks，2001 年 3 月）中提出了綜合的 XP 概述。

有關 holinic 的一些準則的概述，請參閱研究論文“子整體制造系統（Holonic Manufacturing Systems）”（由康涅狄格大學電子和系統工程系的 Peter B. Luh 和 Ling GouDepartment 撰寫）。

智能制造系統（Intelligent Manufacturing Systems）已成功的在整個制造行業推廣了子整體的思想。

Intelligent Systems Group 是卡爾加里大學機械和制造工程系和計算機科學系的合作小組。這個小組的研究目標是為了開發合作代理或者說子整體的體系結構、工具及演示系統。

IBM 的以用戶為中心的設計主頁提出在大規模軟件開發環境中如何規劃和發展最佳準則的有意思的初步熟悉。

IBM 和其他行業領先者創建了 XMI，一種新的、結合 xml 和 UML 優點的開放行業標準。

請閱讀 java 建模專欄所有部分。

可以在 developerWorks Java 技術專區找到更多 Java 參考資料。

關于作者
Granville 對于面向對象社區已經有十幾年的經驗了。他是高級用例建模系列的合著者，并在全世界范圍的各種面向對象技術會議中介紹過教程。他的面向對象開發的實踐方法來自于他在多家公司供職的經驗，其中包括從處于創業階段的公司到相當成熟的軟件業巨人在內的各種公司。他目前正在教授有關靈活過程、方法和 Java 技術的研習班、教程和課程，同時還在輔導和幫助實現一些有作為的項目。請通過 rmiller@togethersoft.com 與 Granville 聯系。

上一篇：Java 和 XML 為何將成功

下一篇：Java 繁體中文處理完全攻略（二）