前幾期的主要內容包括:
一、標準建模語言UML概述
二、標準建模語言UML的靜態建模機制
三、標準建模語言UML的動態建模機制
四、標準建模語言UML支持環境
五、標準建模語言UML的應用實例
1. UML建模過程高層視圖
2. UML實際建模過程
(1) 需求
(2) 分析

(接上期)
(3) 設計
設計階段的任務是通過綜合考慮所有的技術限制,以擴展和細化分析階段的模型。設計的目的是指明一種易轉化成代碼的工作方案,是對分析工作的細化,即進一步細化分析階段所提取的類(包括其操作和屬性),并且增加新類以處理諸如數據庫、用戶接口、通信、設備等技術領域的問題。
設計階段可以分為兩個部分:結構設計是高層設計,其任務是定義包(子系統),包括包間的依賴性和主要通信機制。我們希望得到盡可能簡單和清晰的結構,各部分之間的依賴盡可能的少,并盡可能的減少雙向的依賴關系。
第二部分是詳細設計,細化包的內容,使編程人員得到所有類的一個足夠清晰的描述。同時使用UML中的動態模型,描述特定情況下這些類的實例之間的行為。
· 結構設計
一個設計良好的系統結構是系統可擴充和可變更的基礎。包實際上是一些類的集合。類圖中包括有助于用戶從技術邏輯中分離出應用邏輯(領域類),從而減少它們之間的依賴性。這就是軟件結構設計強調的模塊間的高聚合、低偶合的原則。在商業MIS中,存在以下包(或子系統):
用戶接口包:用戶接口類允許用戶訪問系統數據和加入新數據。在商業對象中,用戶接口包跟商業對象包合作,調用商業對象的操作,實施數據的檢索和插入。
商業對象包:包括來自分析階段的特定領域類。在設計階段,詳細設計這些類,以完整定義他們的操作,支持對數據庫的存取。所以,所有商業對象類必須繼承數據庫包中的類。
數據庫包:為商業對象包中的類提供服務,便于永久存儲。
實用包:包含系統其他包要使用的服務。它們之間的內在關系如圖1所示。

c/SoftMethod/UML/uml7-1.jpg" width=315>

· 詳細設計
詳細設計的目的是通過創建新的類圖、狀態圖和動態圖,描述新的技術類,并擴展和細化分析階段"素描"的商業對象類。這些圖在分析階段也曾用過,不過在詳細設計階段,它們是從技術層次上對系統進行更詳盡的描述。如分析階段的用例描述用來驗證它們是否在設計階段都得到處理,而順序圖用來展示系統中每個用例在技術上如何實現,等等。
數據庫包:MIS的實現必須有永久存儲對象即數據庫的支持,因此系統中必須增加數據庫層,提供這種服務。目前,市面上有許多商用數據庫,有的是真正的面向對象數據庫如工程數據庫,有的是傳統的關系數據庫。由于我們只討論設計方法,不涉及具體的環境,因此,可以抽象一個永久存儲類來實現對數據庫的通用操作,如存儲、更新、刪除、查詢等。永久類類似于MFC中的基類。
商業對象包:設計階段的商業對象包即是分析階段的領域類,需要從實現角度對這些類進行細化,包括如何實現他們之間的關聯和行為。所有這些對象類必須從數據庫包的永久類中繼承而來。分析階段描述的類的操作,在設計模型中可能被分解成幾個操作或者改變名稱。因為分析是構造每個類的框架,而設計是對系統的詳細說明,因此設計模型中所有類的操作必須定義符號和返回值。圖2是經過細化后的商業類圖(局部)

原文轉自：http://www.anti-gravitydesign.com