本節書摘來自異步社群《軟體工程（第4版?修訂版）》一書中的第2章2.4節實際的過程模組化，作者【美】shari lawrence pfleeger , 【加】joanne m.atlee，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
2.4 實際的過程模組化
軟體工程（第4版•修訂版）
很長時間以來，過程模組化一直是軟體工程研究的焦點。但是，它的實用性如何呢？一些研究人員稱，正确地使用過程模組化，為了解過程和揭示過程中的不一緻性帶來了諸多益處。例如，barghouti、rosenblum、belanger和alliegro進行了兩個案例研究，以确定在大型組織中使用過程模型的可行性、效用和限制（barghouti, rosenblum, belanger and alliegro 1995）。在這一節，我們将讨論他們所做的工作以及他們的研究結果。
2.4.1 marvei的案例研究
在這兩個案例研究中，研究人員都使用msl（即marvel規格說明語言）來定義過程，然後，為其生成一個marvel過程制訂環境（kaiser, feiler and popovich 1988；barghouti and kaiser 1991）。msl使用3種主要的結構（類、規則和工具信封（tool envelope））來産生一個3部分的過程描述。
(1) 基于規則的過程行為規格說明。
(2) 模型的資訊過程的面向對象定義。
(3) 用作執行該過程的外部軟體工具和marvel之間的接口的一組信封。
第一個案例研究的是美國電話電報公司的呼叫處理網絡。該網絡處理電話呼叫，還包含一個單獨的信令網，它負責為這些呼叫安排路由并平衡網絡負載。marvel用于描述信令故障解析過程，該過程負責檢測、維修以及解決信令網絡的問題。工作中心1監控該網絡、檢測故障并把故障送出給其他兩個工作中心中的一個進行處理；工作中心2處理需要詳細分析的軟體故障或人為故障；工作中心3處理硬體故障。圖2-15描述了這個過程。雙虛線表示哪一個活動使用了工具或資料庫，工具或資料庫用橢圓表示，矩形框表示任務或活動，菱形框表示判定，箭頭指明控制流。該圖給出的是概要，并沒有提供足夠的細節以表示基本的過程要素。
因而，用msl對每一個實體和工作中心模組化。圖2-16解釋了模組化是如何進行的。圖的上半部分定義了一個憑單類，這裡憑單（ticket）表示當一個失效出現時就記下的一個故障單（fault ticket）（或問題報告）。正像我們将在有關測試的章節中看到的那樣，故障單用于跟蹤一個問題（從問題的出現到它的解決）。整個網絡表示為22個這樣的msl類，一個過程的建立或需要的所有資訊都包含在其中。
接着，該模型強調了信令故障解析過程的行為方面的資訊。圖2-16的下半部分是一個msl規則，它大緻對應于圖2-15中标有“診斷”的方框。因而，msl描述了診斷未決問題的規則，它由每一個打開的憑單激發。當過程模型完成時，需要21個msl規則來描述這個系統。
第二個案例是研究美國電話電報公司的5ess交換機軟體的部分維護過程。與第一個案例研究不同（第一個案例研究的目标是過程改進），第二個案例研究的目的隻是用msl擷取過程步驟和互動進而把它們文檔化。該模型包含有25個類和26個規則。
對每一個模型，用msl過程描述生成“過程制訂環境”，它産生一個含有資訊模型類執行個體的資料庫。接着，研究人員模拟若幹場景以驗證模型是否像期望的那樣執行。在模拟的過程中，他們收集計時和資源使用情況的資料，為分析合适的過程執行提供基礎。通過改變這些規則并重複執行一個場景，對計時進行比較和對照，進而不用在資源方面進行大的投資就得到顯著的過程改進。
模組化和模拟執行對早期識别問題和解決問題是非常有用的。例如，軟體維護過程定義揭示了現有過程文檔中的3種類型的問題：缺少任務輸入和輸出、含義模糊的輸入輸出标準以及低效率的過程定義。信令故障模型的模拟揭示了各工作中心單獨描述造成的低效率。
barghouti和他的同僚指出，把過程模組化問題劃分成模組化資訊和模組化行為是非常重要的。通過将這兩方面分離開，産生的模型清晰且簡潔。他們還指出，計算機密集的活動比人員密集的活動更容易模組化，curtis和他的同僚也指出了這一經驗。
2.4.2 過程模組化工具和技術應該具有的特性
有很多過程模組化的工具和技術，而且研究人員不斷地努力，以确定在給定情況下哪些工具和技術是最合适的。但是，有一些特性對任何一種技術都是有益的。curtis、kellner和over辨別了以下5類良好的特性（curtis, kellner and over 1992）。
(1) 促進人們的了解和交流。該技術應該使用一種大多數客戶和開發人員能了解的方式來表示過程，鼓勵關于過程的交流并對其形式和改進達成一緻。該技術應該包含足夠的資訊，以便能夠實際執行該過程，并且模型或工具應當成為教育訓練的基礎。
(2) 支援過程改進。該技術應當辨別開發或維護過程的基本構件。它應當允許在後面的項目中複用過程或子過程，并能比較不同的可選方案，而且在過程實際投入使用之前估算變化造成的影響。同樣，該技術應該有助于為過程選擇工具和技術，有助于有組織的學習，支援持續的過程演化。
(3) 支援過程管理。該技術應該允許過程是針對特定項目的。這樣，開發人員和客戶應該能夠推測軟體建立或演化的屬性。該技術還應該支援計劃和預測、監控和管理過程以及測量關鍵的過程特性。
(4) 在執行過程時提供自動化的指導。該技術應該定義所有的或部分的軟體開發環境，提供指導和建議，并保留可複用的過程表示供以後使用。
(5) 支援自動化的過程執行。該技術應該讓全部的或部分過程自動化，支援協同工作，擷取相關的測度資料，以及強制規則以保證過程的完整性。
當為開發項目選擇過程模組化技術時，這些特性可以作為有用的指導。如果你的組織機構試圖将其過程标準化，那麼第4個特性特别重要。工具能夠提示開發人員下一步做什麼，并且提供入口和檢查點，以確定在下一步之前，制品滿足了某些标準。例如，工具可以檢查一組代碼構件，評估它的規模和結構。如果規模或結構超出了預先定義的限制，那麼，可以在測試開始之前通知開發人員，而某些構件可能被重新檢查，也可能要重新設計。
本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。