探討軟件工程概念模型

2019-11-17 04:40:26

字體：大中小

來源：轉載

供稿：網友

　　“今天，我比以往更加確信，概念的完整性是產品質量的核心?！@個原理決不僅限于軟件系統，它適合于所有的復雜事物?！?——Brooks《人月神話》

　　“模型可以澄清相互間的關系，識別出要害元素，有意識地減少可能引起的混淆?！?BR>

　　　 ——Forsberg,K.《可視化項目治理》

　　軟件工程內容廣泛，新技術新熱點層出不窮。如何快速把握軟件工程新技術，以及如何對眾多軟件工程技術綜合運用，以取得最佳的實踐效果，已經成為很現實的問題。本文認為，通盤把握軟件工程概念模型，將對解決上述問題大有裨益。

　　一、什么是軟件工程概念模型

　　模型就是抽象，就是有意識地忽略事物的某些特征。抽象帶來的好處是能夠反映模型中元素之間的關系，清楚把握大局。

　　概念模型是模型的一種，簡單說就是抽象程度極高的一種模型。

　　軟件工程概念模型是對軟件工程領域進行抽象描述的模型，它能夠使我們對軟件工程有一個完整把握。

　　二、一個精簡的軟件工程概念模型

　　《軟件工程——技術、方法與環境》一書中，有一個極為精簡的軟件工程概念模型：探討軟件工程概念模型

　　該模型可以用一句話概括：軟件工程是（目標，方法，活動）三元組。它體現了目標-方法-活動的3維正交關系：

　　· 任何目標，都要依照特定方法，由特定活動實現；

　　· 任何方法，都是指導特定活動，來完成某種目標；
　　· 任何活動，都由特定方法指導，來完成某種目標。

　　三、一個細化的軟件工程概念模型

　　下圖是筆者理解的軟件工程概念模型（采用UML類圖的語法）：

探討軟件工程概念模型

　　1、模型概述

　　圖中，“理論與經驗”和“工具”可以認為是2個比較獨立的概念，其他概念可以被分為4組——“方法論”、“過程”、“目標”、“項目”，分別標以不同顏色。這4組主要概念構成了軟件工程概念模型的骨架，可以描述為：為達到一定的“目標”，我們建立起相應的“項目”，在某種“方法論”的指導下，按照一定的“過程”，生產出相應的軟件“產品”。

　　從這個模型的骨架中，我們能清楚看到上面精簡模型的影子——（目標，方法，活動）三元組。但顯著區別是，更加強調“活動”的組織和控制方式——“過程”。這是軟件實踐發展的必然結果，因為，隨著軟件產品的復雜程度不斷提高，勢必要更加強調“過程”。Roger S. PRessman在其經典著作《軟件工程：實踐者的研究方法》里就指出：大約每隔5至10年，軟件界就會重定義“問題”，將其焦點從“產品”轉移到“過程”。

　　2、方法論

　　“方法論”是在一定“原則與策略”指導下的一套相關的“方法與技術”，而“方法論”可以分為“開發方法論”和“過程方法論”2種。相應的，“原則與策略”可以是開發策略，例如聞名的“功能分解”策略；也可以是過程策略，例如迭代模型等“過程模型”，就是過程策略。

　　應當說，“過程方法論”是隨著軟件實踐的深入，在“開發方法論”產生之后才產生的概念。Roger S. Pressman在其經典著作《軟件工程：實踐者的研究方法》里就指出：大約每隔5至10年，軟件界就會重定義“問題”，將其焦點從產品轉移到過程。在本文后面的章節，筆者將用“過程方法論”的概念解釋“Agile到底是過程還是方法論”的迷惑。

　　另外，值得一提的是，在實際當中，存在“方法”其實是指“方法論”的現象，在此說明一下。一方面，“方法論”是為完成特定目的一套“方法”，“方法論”和“方法”是一對多的關系；另一方面，實際中人們常將“方法論”簡稱為“方法”，所以也可以認為“方法”是個遞歸的概念，它可以是“原子方法”，也可以是“方法論”。至此，當你同時面對“Agile方法”和“Agile方法論”這2種說法時，就不必迷惑了。

探討軟件工程概念模型

　　3、過程

　　“過程模型”是對具體“過程”的抽象，它僅規定了后者的框架，例如瀑布模型規定了“過程”是線性框架；“過程模型”的例子還有螺旋模型、噴泉模型、迭代模型等。一個具體“過程”包括“開發子過程”和“治理子過程”2個子過程，它們分別由一組相關的“開發活動”和“治理活動”組成?！伴_發活動”開發出或再加工“開發工件”，“治理活動”使用“治理工件”，對“開發活動”和“開發工件”進行治理。
“過程開發與改進”是一個非凡的“治理子過程”?！斑^程開發與改進”與其它一般的“治理子過程”相比，后者是為軟件產品的開發服務的，而前者是以開發和改進軟件過程本身為目的。軟件工程大師Osterweil在其論文《Software Processes are Software Too》中高屋建瓴地指出：軟件過程也是軟件。軟件有一個開發的過程，軟件過程也有一個開發的過程；軟件開發產出軟件產品，軟件過程開發產出過程產品。

　　RUP是聞名的軟件過程產品。CMM是聞名的軟件過程改進框架，它本身不是特定軟件過程的定義，它只是建議如何一步一個臺階地改進軟件過程。在本文后面的章節，筆者將從“過程開發與改進”的角度，談談RUP的定制和CMM的定位問題。

　　4、目標

　　任何實踐都是有“目標”的，軟件實踐也不例外；比如“開發Bug跟蹤系統”就是一個“目標”的例子。“目標”的完成，依靠于一系列“任務”的完成；比如上述“目標”可以分解為“分析”、“設計”、“編碼”、“實現”等“任務”。

　　“任務”通常在“方法論”的指導下完成；比如“分析”任務，可以選用“OOA方法論”，也可以選用“結構化分析”方法論。每個“任務”還可以進一步分解成多個“子任務”；比如“分析”可以分解為“需求采集”、“需求分析”、“建立分析模型”等“子任務”。
　
　　“子任務”通常使用相關“方法與技術”來實現；比如“建立分析模型”子任務，可以選用“UML建模技術”，也可以選用“結構化建模技術”。

　　5、項目

　　“項目”是“目標”、“過程”和“方法論”3者的關聯類；這意味著任何一個“項目”，都采用一定的“過程”，在某種“方法論”的指導下，完成某種“目標”?！绊椖俊钡摹澳繕恕苯洺＞褪恰败浖a品”本身，但也可以不產出任何“軟件產品”。“項目”是為完成特定“目標”所做出的臨時性努力，可以是建造一棟大樓，一座工廠，也可以是解決某個研究課題，不一而足。

　　“產品”就是一組“開發工件”的集合，就象經典的“軟件”的定義中說的，“軟件是程序、文檔和相關數據的統稱”。“治理工件”是伴隨“項目”的進行產生的，但它并不是要交付給最終用戶的。

　　6、其他

　　現在回過頭來看“理論與經驗”和“工具”這2個概念?！袄碚摗笔歉叨认到y化的知識，“經驗”是尚未進行系統化抽象的知識?！袄碚撆c經驗”是“方法論”的依據，正是在“理論與經驗”的指導下，人們總結出方法論的“原則與策略”，又在后者的指導下，人們將眾多“方法與技術”組織成一套完整的“方法論”?！肮ぞ摺庇脕碇С帧胺椒ㄅc技術”的，好的“工具”可以提高人們的工作效率，減小出錯幾率。

　　其實圖中還包含了其它一些信息。比如，“方法”和“工具”是多對多關系：一種“方法”可以采用多種“工具”（比如畫Use Case圖可以采用Visio、Rose等多種工具），一種“工具”也可支持多種“方法”（比如Visio可以畫流程圖、UML圖等多種圖）。

　　又比如，“方法”和“過程”是多對多關系：一種“方法”可以被多種“過程”采用（比如CRC卡方法可以被RUP、XP等多種過程采用），一種“過程”也可采用多種“方法”（比如RUP可以采用OO建模、結構化建模等多種方法）。

　　篇幅所限，恕不一一列舉。

　　四、軟件工程概念模型的具體應用

　　下面再舉幾個具體的例子，以說明軟件工程概念模型在快速學習、正確理解和深入把握軟件工程技術方面的作用。

　　1、搞清楚Agile是過程還是方法論

　　當前，“Agile過程”和“Agile方法論”的說法都很流行，令初學者相當迷惑。下面根據軟件工程概念模型的知識，來弄清這個問題。

　　好的開始是成功的一半，我要做的第一步就是先推翻“Agile是過程還是方法論”這個問法，改問“Agile是過程、開發方法論還是過程方法論”。

　　第二步，分析《Agile Software Development》一書中給出的Agile模型：

　　通過對模型的分析，可以看出它是對過程建模：

　　·假如去掉人和團隊的因素，上面的模型最主要的要素就是過程（Process）、活動（Activities）、產品（ProdUCts）和技術（Techniques）了，這顯然是個過程的模型。

　　· 上面的模型中有相當多的和人相關的要素，包括角色（Roles）、技能（Skills）、個性（Personality）、團隊（Teams），對人的因素的極其重視，正是Agile過程的顯著特點。

　　· Agile過程是面向人的（people-oriented）過程，實施Agile過程的一個要害之處是讓人“接受”一個過程而非“強加”一個過程。

探討軟件工程概念模型

　　我預備提前下結論了——談過程哪能不談它背后的方法論呢——Agile是有它自己的過程方法論的過程。

　　2、為CMM定位

　　CMM是一個大家關注已久的話題，CMM標準的提法頗為流行，下面筆者換個角度，根據軟件工程概念模型的探討，將CMM定位為“過程開發與改進的需求和測試方案”。

　　CMM是軟件過程開發的需求：

　　· 要害實踐描述了應當“做什么”，而不是強制規定“如何做”；要害實踐的描述就是過程開發的需求項。

　　· 要害實踐被分組，成為一些要害過程域。相當于需求項的分組，便于治理。

　　· 要害過程域的實施都是為了達到一定的目的，從需求的層次角度（請參考Wiegers著陸麗娜譯《軟件需求》一書），可將“目的”理解為“業務需求”，將要害過程域理解為“用戶需求”，前者由后者來實現。

　　· CMM通過定義的這些要害實踐和要害過程域，覆蓋了我們要開發的軟件過程的主要目的（比如需求治理、產品工程）。

　　CMM是軟件過程開發的測試方案：

　　· 從原理上，需求就是測試依據。軟件工程中的一條基本原理就是：依據需求進行測試。

　　· 從實施上，我們通常依據需求來編寫測試用例，然后執行這些測試用例。

　　· Brain Marick更是表述了他的具有革命性的觀點：“我并不想寫出一套用于捕捉用戶愿望的需求，取而代之的是，我要寫出一套測試，一旦這些測試能夠通過，產品就能使她滿足?！北M顯大師風范。

　　· CMM提供的大量提問單，和測試用例的概念對應得很完美，我們通過這些提問單就可以輕松測試出每一個要害實踐進行得怎么樣，進一步測試出每個要害過程域完成得如何，該組織的軟件過程的能力成熟度有多高。

　　3、理解RUP定制

　　RUP是聞名的軟件過程產品，包含了相當優秀的思想，比如：

　　· 為了使風險最小化，RUP引入階段概念和迭代開發模型，以便給開發者足夠多的機會，在付出太多代價之前放棄或調整開發。

　　· 為了使并行最大化，RUP引入工作流的概念，工作流是相關活動的集合，不僅工作流之間也是并行，工作流內部的活動也是可以并行的。

　　然而，根據具體的實踐情況不同，使用RUP前應當對其進行適當定制。

　　“RUP定制”屬于“過程開發與改進”中的“過程開發”，而且嚴格來講，是“過程開發的再工程”。再工程（reengineering）是對現有軟件系統或軟件過程的重新開發過程，包括逆向工程、新需求的考慮和正向工程三個步驟。

　　值得一提的是，“RUP定制”既可以是“RUP剪裁”，也可以是“RUP擴充”。RUP剪裁大家討論的比較多了，有愛好的讀者可以閱讀本文參考文獻中所列的《RUP的剪裁原理和剪裁過程》一文。

　　聞名的RUP擴充的例子有：

　　· Ronin International公司將RUP擴充成為EUP。

　　· 再比如愛立信在RUP的基礎上進行擴充，開發出ERUP作為公司范圍內的框架結構。

　　五、軟件工程概念模型的啟示

　　1、軟件工程，一門實踐的科學

　　通過對軟件工程概念模型的研究，強烈地感覺到，軟件工程是一門實踐的科學——它的出發點和最終目的是指導實踐。基于此，我們至少應當注重2點：

　　· 從時間上，實踐是發展的，基于實踐的軟件工程學科也必然是發展的，比如近幾年，軟件工程領域的發展就相當大。我們必須意識到這一點，不斷學習新知識，才能適應軟件實踐的需要。Roger S. Pressman說：“軟件工程將發生變化——對此我們可以肯定。”

　　· 從內容上，軟件實踐的差異是巨大的，我們不能生搬硬套。正如Alistair Cockburn所說：“不同的項目需要不同的方法”。

　　2、軟件過程，合適的才是最好的

　　據我所知，好的軟件過程在不少人的腦子里，是一個“越……越……”的答案。比如，文檔越多越好，分工越細越好，控制粒度越小越好，等等。還有，人們認為好的軟件過程是可以照搬使用的，我聽到過類似“我在某某大公司都是……”的抱怨。

　　其實通過軟件工程概念模型的探討，我們可以看到，軟件過程是整個模型很多節點中的一個而已，這意味著軟件過程和很多因素有著影響、被影響的關系：

　　· 軟件類型、軟件規模、軟件重要程度、開發人員素質、治理和支持人員素質、合作單位素質等，都是影響軟件過程制定的因素。

　　· 而且，且不可單純認為軟件過程僅僅涉及到開發人員，用戶、合同確定者、投標者、項目治理者等，都可以成為軟件過程的“涉眾”；也就是說，他們都可能是待開發的軟件過程的用戶，應當收集他們對軟件過程的要求。

　　3、對個人的啟示

　　分析了軟件工程概念模型，可以看出，從某種角度，可以認為軟件產品是多種技術協作的結果。技術的協作最終表現為個人的協作，軟件工程概念模型對個人有何啟示呢？

　　· 明了自己知道的和不知道的，尊重他人，是一個團隊的必要基礎。

　　· 注重團隊成員間技術的互補性和全面性。

　　4、呼喚高層次人才

　　看著模型，想著近年來國際上軟件工程的巨大發展，深感國內在軟件工程領域的落后，“透過變化看趨勢、透過技術抓原理、把握軟件工程發展脈搏”的高層次人才太少。

　　我輩尚需努力。

上一篇：養成“好”的編程習慣

下一篇：WinCE嵌入式開發程序入門