軟體全程建模2

   

2 分析模型

分析是一個十分關鍵的過程，它是把需求轉化為代碼實現的中間階段。軟體分析是將自然語言表達的軟體需求進一步進行解析的過程。軟體設計就是從分析到軟體實現的過程。

2.1 架構設計

1.      分層架構

架構設計決定了各子系統如何組織以及如何協調工作。架構設計的好壞影響到軟體的好壞，系統越大越是這樣。在分解複雜的軟體系統時，經常使用的一種架構技術就是分層。分層架構中最困難的問題就是決定建立哪些層以及每層的職責。分層結構的好處主要有：不需要去瞭解層的實現細節；可以使用另一種技術來改變基礎的層，而不會影響上層的應用；可以減少不同層之間的依賴；容易制定出層標準；底下的層可以用來建立頂上層的多項服務；分層有利於標準化工作的執行。分層只是將系統各種邏輯進行更有效組織。分層架構的缺陷也不容忽視，層次不能封裝所有東西，有時候會帶來級聯修改；過多的層間資料傳遞會影響效能。

2. 兩層結構與三層結構

在分層結構中比較常用的有兩層結構和以三層結構為代表的多層結構。基於二層架構的應用通常稱為Client/Server應用。很多情況下伺服器提供的服務僅僅是資料庫服務。在這種模式中用戶端負責訪問資料，完成商務邏輯處理、接收使用者的輸入及將結果向使用者展示。二層體繫結構的主要不利之處是其商務邏輯沒有從表示邏輯中分離開來，程式員很難在二層結構的應用中清楚地將商務邏輯從表示邏輯中分割出來，這樣就很難維護、改進，可擴充性差，也很難重用。

三層體繫結構以傳統客戶服務器模式為基礎，將客戶程式和資料庫伺服器的功能進一步分解，客戶程式僅根據需要提出資料請求，資料庫伺服器也僅負責與資料存放區、完整性控制等有關的任務，而資料加工、處理等商務邏輯，交於另一個獨立的部分來完成，這樣不僅減輕了伺服器的負擔，也使前台客戶程式更加獨立，僅注重於與操作人員的互動和資料的單一處理，形成了展示層、業務層、以及資料層三層結構，其中業務層也稱為中介層，執行中介層任務的電腦稱為應用程式伺服器。

與傳統的兩層結構相比，三層最大的特徵是將業務層獨立了出來，從而提高了業務層的可複用性。在兩層結構中，使用者介面和業務處理流程放在一起，因此無法直接複用業務處理的相關功能，也無法將業務處理功能進行靈活的部署。在三層結構中，展示層只處理使用者介面相關的功能，主要處理使用者和軟體的互動，展示層主要有Windows圖形介面和基於Web的介面，主要職責就是為使用者提供資訊，以及把使用者的指令傳送給業務層。業務層複雜處理商務程序，是三層結構中最重要的一層，可以對業務層進行靈活的部署，開發時也便於業務處理的開發和使用者介面的開發同時進行。針對於資訊系，資料層的最大的邏輯就是儲存持久資料。

三層結構的優點如下：減少客戶機的維護量，因為前景程式比較簡單；把企業邏輯封裝在通用的中介軟體應用伺服器中，不同的客戶都可以共用同一個中介層，而不必每個客戶都單獨實現企業規則，避免了重複開發和維護的麻煩。由於客戶程式相當瘦，無論是開發還是發布，都變得簡單了。便於升級，當中介軟體升級的時候，客戶程式可能不需要變化；實現了分布式資料處理，把一個應用程式分布在幾台機器上運行，可以提高應用程式的效能，也可以把敏感部分封裝在中介軟體，為不同的使用者佈建不同的存取權限，增強了安全性。

3. 本軟體架構設計

在上述的二層結構和三層結構中，三層結構具有明顯的優勢，能很好的實現業務與介面的分離，在一定程度上實現了重用和松耦合。本軟體的結構在三層架構的基礎上繼續改進，2所示。展示層採用Windows介面，主要是結合使用者的使用習慣及本項目開發人員的技能綜合考慮。資料庫採用微軟的SQL Server2000及MSDE，對於使用者網路環境受限，本軟體只能單機安裝的情況採用MSDE資料庫，其他情況採用SQL Server2000。 在基於資料庫系統的三層結構中，商務邏輯層不僅負責商務邏輯，而且直接存取資料庫，提供對業務資料的儲存、更新、刪除和查詢操作。系統架構起到容器的作用向商務邏輯層提供服務，它還能夠被很好的重用，將一些基礎的公用的功能放在系統架構層，這樣就沒有必要每個項目都從頭做起，可以重用以前的成果提高效率。目前該系統架構提供的服務主要有串連池、緩衝、日誌、安全性、異常、訪問配置資訊等。

 

圖2 系統架構

2.2 擷取分析類

類圖的擷取是一個不斷細化的過程，一般我們先從分析類開始。分析類是概念層面上的類，是進行類設計的基礎，擷取分析類是系統分析中一項很重要的工作。擷取分析類的是一個需要大量技巧的工作，我們主要根據用例描述來確定分析類。表2中列出的問題可以協助我們識別用例中的類。

表 2 識別用例中類的問題

用例描述中出現了那些實體？

用例的完成需要哪些實體合作？

用例執行過程中會產生並儲存哪些資訊？

用例要求與之關聯的每個角色的輸入是什嗎？

用例反饋與之關聯的每個角色的輸出是什嗎？

用例需要操作哪些硬裝置？

比如在“選擇建設項目”用例描述中對基本流的描述如下：“系統提供已有建設項目供使用者選擇。使用者從系統提供的項目列表中選中某個建設項目。系統對當前選中的建設項目進行標識，進入主介面” 。通過對用例描述的分析可以確定出分析類“建設項目”。通過類似的方式對每個用例描述進行分析，可以獲得系統的分析類。3所示，就是我們對用例進行分析後獲得的系統的分析類。

圖3 分析類

2.3 用例實現

獲得分析類以後，我們就可以藉助分析類通過互動模型對用例如何?進行描述。用例實現是一個由需求轉移到分析、設計的過程。用例描述了使用者的功能性需求，用例實現藉助分析類以及他們之間的互動來描述用例被如何?。可以看出使用UML從需求到分析、設計的過渡是很平滑的。在描述用例實現時我們可以使用活動圖表、順序圖、共同作業圖表等方式。活動圖表和共同作業圖表可以互換，一般我們僅選擇其中的一種就可以了。由於篇幅的限制項目繼續以用例“選擇建設項目”為例說明。

圖4 “選擇建設項目”的活動圖表

 

為了使這個用例能夠更加清晰，使用了圖4所示的“選擇建設項目”的活動圖表對該用例加以描述。進入該用例後，系統提供所有建設項目及建立建設項目功能。此時使用者可以瀏覽已經列出的建設項目進行選擇，或者使用查詢功能進行查詢，或者建立一個並不存在的建設項目，這些操作對應了基本流和可選流。由於使用者處理的建設項目不多，所以將所有的建設項目都列出來。通過這樣的活動圖表我們對用例“選擇建設項目”將有一個更清晰的認識。

下面的對用例實現的描述主要採用了順序圖來描述，當然也可以同時使用共同作業圖表進行描述。順序圖和共同作業圖表都屬於互動圖，都是用於描述系統中對象之間的動態關係。兩者可以相互轉換，但是兩者強調的重點不同，順序圖強調的是訊息的時間順序，而共同作業圖表強調的是參與互動的對象的組織。如果我們使用建模工具，建立了順序圖之後，工具可以幫我們自動產生共同作業圖表。

用例描述中描述的基本流、可選流可以通過順序圖來進行更加詳細的描述。對於用例“選擇建設項目”使用一個活動圖表和三個順序圖來實現它的動態模型。“選擇建設項目”的用例描述中有一個基本流，兩個可選流。我們將選用3個順序圖分別描述這三個情境。

圖5 “選擇建設項目”基本流的順序圖

 

圖5所示的順序圖，是“選擇建設項目”用例的基本流中對象之間的互動序列。在此順序圖中的對象有質監機構的工作人員、選擇建設項目表單的一個執行個體、TProject類的一個對象。使用者啟用選擇建設項目表單的一個執行個體。該表單建立TProject類的一個對象。接著表單調用對象方法，獲得的所有建設項目，並且調用自身的方法將這些建設項目進行載入，供質監機構的工作人員選擇。使用者選擇了一個建設項目，表單調用對象的方法將使用者選擇的建設項目標識為當前的建設項目，以後所有的操作將在這個建設項目上進行。

圖6　“選擇建設項目”可選流1的順序圖

 

圖6所示的順序圖是選擇建設項目用例的“可選流1”中對象之間的互動序列。也就是使用者不使用系統列出的建設項目，而是查詢建設項目從中選擇。在此順序圖中的對象有某個質監機構的工作人員、選擇建設項目表單的一個執行個體、TProject類的一個對象。某個質監機構的工作人員啟用選擇建設項目表單的一個執行個體。該表單建立TProject類的一個對象。接著表單調用對象方法，獲得的所有建設項目，並且調用自身的方法將這些建設項目進行載入，供質監機構的工作人員選擇。某個質監機構的工作人員將查詢資訊提供給表單進行查詢，表單調用對象的查詢方法獲得建設項目。表單調用自身的載入方法，將查詢得到的建設項目載入到表單上，供質監機構的工作人員選擇。質監機構的工作人員選擇某個建設項目之後，表單調用對象的方法將使用者選擇的建設項目標識為當前的建設項目，以後所有的操作將在這個建設項目上進行。

 

圖7　“選擇建設項目”可選流2的順序圖

圖7所示的順序圖是“選擇建設項目”用例的可選流2中對象之間的互動序列。也就是不選擇建設項目而建立一個建設項目。在此順序圖中的對象有某個質監機構的工作人員、選擇建設項目表單的一個執行個體、TProject類的一個對象。某個質監機構的工作人員啟用選擇建設項目表單的一個執行個體。該表單建立TProject類的一個對象。接著表單對象的方法，獲得所有的建設項目，並且調用自身的方法將這些建設項目進行載入，供質監機構的工作人員選擇。某個質監機構的工作人員不進行選擇，建立建設項目，表單調用對象的建立建設項目的功能。該功能在建立建設項目用例中描述。

2.4 整理分析類

整理分析類主要是依據用例實現部分的一系列的互動圖。我們已經獲得了分析類，在用例實現中我們在互動圖中使用了這些類。但是這些類還沒有屬性、職責。我們需要對他們進行整理，完成分析類的屬性、職責以及類之間的關係，並在類圖中將他們展示出來。

職責是分析類響應訊息並完成特定功能的能力，包括對外提供服務和維護自身的資訊。由於訊息和職責存在著對應關係，根據訊息就可以確定職責。在互動模型中對象之間的互動通過訊息進行。將互動圖中將和該類有關的訊息進行整理確定類的職責。

類之間並不是孤立的，利用類之間的關係就可以找到另一個類。利用共同作業圖表中對象之間的串連就是分析類之間的關聯方式之一。分析類之間完整的關聯關係要根據所有事件序列中對象間的串連加以歸納。

屬性是分析類的基本內容。屬性的基本來源是用例的事件流描述。如果對分析類及方法的描述比較明確，屬性就比較容易擷取。要分析屬性也要結合分析類的方法，因為職責會使用屬性去完成功能。

在整理分析類的過程中一定要注意分析類不僅僅參與了一個用例，它可能參與了很多的用例，因此在分析屬性、職責及類之間關聯的時候要考慮每個用例的情況，進行歸納總結。通過整理分析類繪製的類圖僅僅是分析階段的類圖還需要在後續階段繼續完善和細化。

圖8 分析類Project

圖8就是整理出的一個分析類Project類的樣本，當然這個類不僅僅是從選擇建設項目這個用例擷取的資訊，它是綜合了所有相關的用例分析的結果。

未完待續......