軟件項目實訓及課程設計指導——系統概要設計中的程序類結構和類之間關系的設計示例 1、如何合理地進行軟件系統中的各個程序類的設計

　　靜可描形、動可描行，動和靜是辯證關系中的兩個方面。在UML技術規範中與靜态建模有關的各個視圖可以描述軟件應用系統的靜态組織和體系結構，而與動态建模有關的各個視圖則可描述出軟件系統中的各個對象的行為和動作。構成面向對象模型的基本元素主要為：類和對象、類和類之間的關系等。

　　（1）合理地遵守面向對象程序類設計的五大原則

　　因為軟件應用系統中的程序類設計直接對應于軟件應用系統的功能實現設計，它的最終設計的質量将直接影響着軟件應用系統的總體和整體的質量，所以這個設計階段的工作是十分重要的。這就給軟件應用系統的設計人員提出了一些挑戰：

　　首先，程序類是如何确定的？

　　其次，如何合理地規劃程序類？

　　最後，如何正确地建立程序類之間的關系？

　　因此，要求軟件應用系統的設計人員要遵守一些軟件應用系統程序類設計方面的基本原則、并合理地應用各種設計模式，從而可以提高軟件應用系統的總體設計的質量。

　　（2）合理地應用面向對象設計中的通用職責分配軟件模式

　　軟件應用系統的設計人員要應用面向對象設計中的通用職責分配軟件模式（GRASP，General Responsibility Assignment Software Patterns）進行程序類的職責設計。因為GRASP設計模式能夠為軟件應用系統的設計人員提供如下方面的指導：

　　1）如何把現實世界的業務數據抽象成對應的對象；

　　2）如何決定一個軟件應用系統中應該有多少程序對象（類）；

　　3）每個程序對象（類）都包括什麼方面的職責。

　　而對于上面的這些設計問題，GRASP設計模式都為軟件應用系統的設計人員給出了最基本的指導思想和設計原則，并幫助軟件應用系統的設計人員理解基本的面向對象的對象設計技術。

　　2、軟件應用系統在設計和開發時必須擁抱變化和适應變化

　　（1）軟件應用系統的用戶需求在客觀上是不斷地變化的

　　在軟件應用系統的組件模塊的設計階段最關鍵的問題是，用戶的需求是變化的，軟件應用系統的設計如何擁抱變化和适應變化？

　　（2）軟件應用系統的需求分析并不能解決一切問題

　　從事軟件應用系統設計工作的讀者可能經常聽到人們在抱怨，一個軟件應用系統項目已經通過了交付測試，但軟件系統投入運營以後用戶又提出了新的系統需求，這時就會面臨這樣一個問題，修改一段代碼就會需要幾百個相關的程序代碼跟着改變，因此軟件應用系統的升級就變成幾乎不可能的事情。于是，軟件應用系統的開發者抱怨說，用戶為什麼當初不提出這些新的需求呢？而用戶則抱怨說，随着企業經營的業務需求的不斷變化，原有的軟件應用系統将會逐漸不能滿足企業經營的需要，而當初企業人員也是無法預料到的，當然也就無法在軟件應用系統開發初期提出這些需求。

　　最後的結果，恐怕隻能是一個，那就是這個軟件應用系統将被棄之不用。其實，這個問題不在軟件應用系統的使用方——用戶，而是開發者在軟件應用系統的設計、開發實現等方面存在一定的欠缺。

　　（3）比較困惑的事情

　　1）如果軟件應用系統的設計和開發人員試圖去發現用戶的需求将會怎樣或者如何地變化，那麼軟件應用系統的設計人員的工作将永遠停留在軟件應用系統的分析階段——不斷地在獲得需求。

　　2）如果軟件應用系統的設計和開發人員所開發出的軟件應用系統能夠面向未來的未知需求，那軟件應用系統的設計人員的工作将永遠處在軟件應用系統的設計階段——不斷地完善系統設計以匹配變化的系統需求。

　　但軟件應用系統的開發時間和預算是不允許開發方的相關人員面向未來設計軟件應用系統，因為過分的系統分析和過分的系統設計，事實上都被稱之為分析癱瘓。

　　3、軟件應用系統在設計和開發時如何擁抱變化和适應變化

　　（1）軟件應用系統的設計和開發人員應該遵守的幾個原則

　　1）針對類接口編程而不是針對類實現編程。

　　2）優先使用對象組合關系，而不是類的繼承關系。

　　3）考慮軟件應用系統的設計有哪些是可變的，并考慮如果發生變化時，不會引起對軟件應用系統的大幅度的修改或者重新的系統設計。

　　（2）封裝變化的概念是模塊設計的主題

　　為了解決這些問題，在軟件應用系統的模塊設計和對應的程序類設計、開發實現中需要充分地應用GoF的23種代碼設計模式，而在GoF的23種代碼設計模式中，把這些相關的設計模式分為結構型、創建型和行為型三大類型。而通過通用職責分配軟件模式GRASP，軟件應用系統的設計和開發人員又能夠準确地進行各個程序類的各自的職責分配。

　　4、面向對象設計中所涉及的UML類與對象圖的主要作用

　　（1）UML技術規範中的UML類與對象圖能夠體現和表現出軟件應用系統的靜态結構

　　UML類與對象圖是面向對象分析和設計方法的核心内容之一，它們能表達面向對象模型的主要概念和各個組件類之間的關系，也是軟件應用系統開發的基礎；它們主要用以表達面向對象設計中的對象模型的靜态結構——因為它們不僅能夠定義軟件應用系統中的功能類的内部結構（類的屬性和類的操作），也可以表示類之間的關系（關聯、依賴、聚合等）。

　　（2）對象模型是對真實世界中的問題的抽象

　　由于以面向對象方法建造出的對象模型是基于真實世界的基本概念和業務流程的，并且與真實世界中的問題非常接近。從而使得該對象模型易于交流、易于驗證和易于維護。

　　5、熟悉軟件應用系統中的程序類與類之間的各種關系形式

　　（1）結構性關系

　　主要反映出軟件應用系統的靜态結構方面的關系——如程序類之間的聚合（表示事物的部分與整體關系的較弱情況）、組合（表示事物的部分與整體關系的較強情況）、泛化（體現類之間的繼承關系）等形式的關系。

　　在下圖所示的代表通用的計算機概念的抽象類Computer與其他類之間關系的UML類中，可以了解到Computer類與CPU和HDDisk（代表計算機硬盤）等類是組合包含關系（緊密構成關系），而Computer類與Print類是聚合包含關系（松散構成關系），代表微型計算機概念的類PCComputer是Computer的子類，因此兩者之間存在泛化關系，Computer類和該計算機的擁有者ComputUser類之間存在一對一的關聯。

　　（2）行為性關系

　　主要反映出應用系統的動态行為方面的關系——如類之間可以通過消息或者通過系統預定義、用戶自定義的語義關系，主要的關系形式為依賴（類之間的使用/調用關系）和關聯（關聯是一種結構化的關系，指一個類和另一個類有關系）。

　　通常情況下，依賴關系體現在目标類的對象出現在局部變量或者方法的參數中以及靜态方法的調用。依賴與關聯關系是不同的，首先依賴關系總是單向的，其次依賴關系一般都體現有使用或者調用形式的關系。

　　在上圖所示的Computer計算機類與其他類之間關系的UML類圖中，Computer抽象類中的calculateData()功能方法帶有一個Data類型的參數（代表計算機所要處理的各種數據），該calculateData()功能方法的執行依賴于所提供的參數Data對象。因此，Computer抽象類和Data類之間存在依賴關系。如下示圖為某個軟件應用項目中的相關程序類之間關系的局部截圖：

　　6、合理地分配軟件應用系統中程序類的職責

　　（1）什麼是程序類的職責

　　程序類所擔任的任務和所要完成的功能稱為該程序類的職責。但問題是，軟件應用系統的設計人員如何正确地分配程序類的職責？

　　（2）遵守單一職責的原則進行程序類的職責分配設計

　　在程序類的職責設計和分配時，軟件應用系統的設計人員應該要遵守面向對象程序類設計中所倡導的單一職責原則，這樣将有利于該程序類的重用。當軟件應用系統中的各個程序類在設計時如果不滿足這一原則，設計人員就需要對軟件應用系統中的有關功能類進行設計重構以拆分這個功能類為多個不同的程序功能類——這可以通過使用提取接口和提取方法等形式的重構方法加以實現。如下示圖為某個軟件應用系統中利用數據訪問服務組件隔離系統的業務處理層和數據持久層之間直接耦合關系的類圖局部截圖，此時的數據訪問服務組件為門面組件，該門面組件遵守面向對象設計中的單一職責設計原則進行程序類的職責分配設計。

　　7、畫出軟件應用系統中的各個程序類所構成的類圖

　　構成面向對象模型的基本元素是類和對象、類和類之間的關系等。因此UML中的類圖與對象圖是面向對象分析和設計工作的核心内容之一，因為它們能表達面向對象模型的主要概念和各個組件類之間的關系，也是軟件系統開發的基礎；而且它們主要用來表達對象模型的靜态結構。如下示圖為體現工廠設計模式中各個程序類之間關系的類圖局部截圖，應用産品接口定義各個産品的共性方法，并根據不同的應用需要實現該産品接口從而産生出滿足不同應用需要的産品類。

　　另外，在面向對象的設計方法中，設計階段的一個十分重要的工作是進行類設計。下圖所示為體現銀行賬戶信息管理系統項目中的粗粒度的概要設計中的業務邏輯處理層中的各個類之間關系的類圖——概要設計中的類圖一般隻體現類之間的關系，而不需要反映出類的内部結構和組成——對于各個類中的成員屬性和成員方法的設計，一般可以通過在詳細設計階段進一步細化設計結果而獲得。

　　,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!