第13章 統一塑模語言

靜態模型分析與設計工具



1. 請詳述UML的演進過程。

【參考答案】：

圖一是統一塑模語言的演進過程，在1994年以前，一些研究物件導向方法之專家例如Booch, Rambaugh, Jacobson, Codd, Yourdon, Schlaer 及Mellor等人均有提出物件導向開發方法，各種方法皆有其特色且適用的對象與場合均不相同。1994年，Coleman提出所謂「融合理論」企圖統一個專家的物件導向方法論與視覺化塑模語言。同時，Booch與Rambaugh先後加入Rational 公司共同為統一塑模語言（Unified Modeling Language, UML）催生。1995年，Jacobson 加入Rational公司，開始制定UML版本。1996年，物件管理學會（Object Management Group, OMG）公開徵求物件導向視覺化塑模語言的建議書，1997年，OMG接受UML規格，於是UML正式成為一種產業界標準。


統一塑模語言(UML)是由三位軟體工程大師 Booch, Rumbaugh, Jacobson共同主導的一種描述物件模式的語言，UML是一種符合產業標準與開放性的視覺化語言，並且使用物件導向開發方論進行資訊系統的開發工作。至目前為止，UML是一種使用最為廣泛的物件導向塑模語言。2000年推出的UML 1.4版已經具有一部份語意表達能力，UML在物件行為方面的描述能力有了突破性進展。2004年，UML 2.0版正式推出，它是目前全世界公認的一種物件導向塑模語言的標準。





圖一：統一塑模語言的演進過程



2. 請詳述UML2.0的架構圖。

【參考答案】：

基本上，UML是一種泛用性的視覺化塑模語言，它涵蓋以下三大部分(圖二)

圖二：UML2.0的架構圖

（一） 建構區域UML的基本元素包括物體、關係與圖。

一般而言，物體有以下類型:（1）結構物體類別、介面、物件、使用案例、活動類別、元件與節點等，（2）元件物體UML模型之動態模式例如互動圖、活動圖與狀態圖，（3）行為物體同類物件的集合，（4）註解物體說明用途，與（5）部署物體實體物件。而關係是指兩個物件之間的關連，主要的關係有相依性、關連、聚合、合成、包含、一般化與具體化。

至於UML的圖形分為兩大類 (圖三)：（1）結構圖主要是描述物件本身結構與物件之間的關係，它是屬於一種靜態模型，主要是類別圖、物件圖、元件圖、部署圖、套件圖與合成結構圖，與（2）行為圖描述物件之間的互相影響之行為，它是屬於一種動態模型，主要是活動圖、循序圖、合作圖、時序圖、互動概觀圖、使用個案圖與狀態圖。



圖三：UML2.0的圖形類別



（二） 通用機制描述系統運作之規格包括一般領域(Common Division)、延伸機制(Extensibility Mechanism)、裝飾(Adornment)與規格(Specification)。

一般領域是指設計者思考實體世界的方式，主要有分類器與實例、介面與實作。所謂「分類器」（Classifier）是指:「一種描述物件之結構與行為特性的機制。」它包含類別、元件、介面、節點、訊號與使用者個案，其中 “類別” 是UML最重要的一種分類器，而實例（Instance）就是分類器的一個實體化類型。

所謂裝飾是指﹕「每一個模式元件再加上一些簡單圖案當作裝飾的作法。」利用裝飾可以充分的展現個層面的元件規格，例如圖四所示，類別視窗的屬性加上一些符號例如（+、#、-）等可以代表其可見性。

圖四：裝飾的一個實例

其次，延伸主要有三大類﹕（1）約束條件（Constraints）加入一些新的規則，延伸描述元件本身的語意的能力，（2）刻版（Stereotype）定義新的模型元件，與（3）標籤值（Tagged Value）增加一些自己定義的屬性或元件模型。所謂「刻板」（Stereotype）是指:「以UML模式元件為基礎，定義出一種新的模式元件之表示符號。」一般而言，刻板經常被應使用在UML的一些模式例如元件圖與部署圖等。至於規格是用來描述元件的規格，主要是用文字或圖表來敘述細部模式的內容。

（三） 架構UML的架構主要是結構、行為、互動關係與元件。

UML 2.0版主要是根據Kruchten提出的4+1 View的觀點來設計建構模式的工具（圖五）。茲將各種觀點的內容說明如下﹕





圖五：4+1 View(Kruchten, 1995)

資料來源﹕Kruchten, P., “Architectural Blueprints— The “4+1” View Model of Software Architecture,” IEEE Software, 12(6), 1995, pp. 42-50.

（1） 邏輯觀點

邏輯觀點是從設計的觀點進行描述，它是一種靜態模型（Static Model），針對類別、物件與介面的結構關係進行邏輯描述，據此來定義一個系統功能的細部設計的內容。同時，針對系統的運作過程，內部結構如何透過物件的互動與操作來達到預期的系統功能。因此，有人稱之為系統內部設計觀點（Design View）或架構模型觀點（Architectural Model View），主要是提供設計者描述系統功能的用途，UML是提供類別圖或物件圖作為邏輯塑模的工具。

（2） 流程觀點

流程觀點是從支援外部實體流程的操作觀點來進行描述，它是一種動態模型（Dynamic Model），來定義資訊系統操作流程中一系列之執行程序、組合的活動、狀態與控制程序等。因此，有人稱之為行為模型觀點（Behavioral Model View），UML是提供活動圖、狀態圖、循序圖、合作圖、時序圖與互動概觀圖作為流程塑模的工具。

（3） 發展觀點

發展觀點是從系統發展的觀點，將邏輯模型觀點與流程模型觀點所產生的類別、屬性與方法等，如何整合的作法進行細節的描述。有人將稱之為實作觀點或元件觀點，透過不同方式組裝成一些實際可操作的獨立元件與檔案，利用彼此間的互動關係來說明系統內部的模組或元件的結構以及彼此間的相依關係，例如實體元件的架構與元件之間的依存關係。在實施過程中，必須描述系統如何切割成軟體元件再進行實作的工作，UML是提供元件圖、套件圖與合作結構圖作為發展塑模的工具。

（4） 實體觀點

實體觀點是從系統運作的觀點，描述資訊系統的硬體之基礎架構。同時，顯示一些硬體設備、連接的方式、軟體程式的配置、訊息傳遞、系統安裝細節以及元件的實體部署狀況等。因此，實體觀點主要是提供系統設計人員有關於實體環境的細部設計的內容，做為資訊系統實作的依據。因此，有人稱之為佈署觀點（Deployment View），UML是提供部署圖作為實體塑模的工具。

（5） 情境觀點

情境是從使用者的觀點，描述資訊系統的功能性需求，因此，有關真實世界所面臨的問題、解決方案或領域的知識均是此部分含蓋的範圍。藉由描述系統的操作行為或事件的情境的描述，充分表達資訊系統的功能，針對行為者與系統之間互動的情形或是系統內部操作的作法進行詳細的描述，但是並不描述軟體的結構或行為的細節。情境觀點主要目的是提供系統設計人員進行架構設計或是驗證是否滿足使用者需求的工具，它是物件導向設計的重心，可以作為參與系統開發人員之間溝通的ㄧ個橋樑。因此，UML塑模作業是以 “情境” 為中心整合其他觀點所建構的物件模式，其重要性不言而喻，UML主要是提供使用個案圖與活動圖作為情境觀點塑模之工具。

綜合以上所述，Kruchten（1995）提出4+1 View軟體架構，它是以使用個案為軸心來整合各種觀點建構的模型，並針對不同系統開發人員角色的工作需求提供一些設計的具體指導原則與做法。



3. UML2.0的結構圖包含些圖形?

【參考答案】：

至於UML2.0的結構圖主要是描述物件本身結構與物件之間的關係，它是屬於一種靜態模型，主要是類別圖、物件圖、元件圖、部署圖、套件圖與合成結構圖，與（2）行為圖描述物件之間的互相影響之行為，它是屬於一種動態模型，主要是活動圖、循序圖、合作圖、時序圖、互動概觀圖、使用個案圖與狀態圖。



4. UML2.0的行為圖包含些圖形?

【參考答案】：

至於UML2.0的行為圖描述物件之間的互相影響之行為，它是屬於一種動態模型，主要是活動圖、循序圖、合作圖、時序圖、互動概觀圖、使用個案圖與狀態圖。





5. 請說明Kruchten （1995）的4+1 View的軟體架構圖的概念。

【參考答案】：

UML 2.0版主要是根據Kruchten提出的4+1 View的觀點來設計建構模式的工具（圖六）。茲將各種觀點的內容說明如下﹕





圖六：4+1 View(Kruchten, 1995)

資料來源﹕Kruchten, P., “Architectural Blueprints— The “4+1” View Model of Software Architecture,” IEEE Software, 12(6), 1995, pp. 42-50.

（1） 邏輯觀點

邏輯觀點是從設計的觀點進行描述，它是一種靜態模型（Static Model），針對類別、物件與介面的結構關係進行邏輯描述，據此來定義一個系統功能的細部設計的內容。同時，針對系統的運作過程，內部結構如何透過物件的互動與操作來達到預期的系統功能。因此，有人稱之為系統內部設計觀點（Design View）或架構模型觀點（Architectural Model View），主要是提供設計者描述系統功能的用途，UML是提供類別圖或物件圖作為邏輯塑模的工具。

（2） 流程觀點

流程觀點是從支援外部實體流程的操作觀點來進行描述，它是一種動態模型（Dynamic Model），來定義資訊系統操作流程中一系列之執行程序、組合的活動、狀態與控制程序等。因此，有人稱之為行為模型觀點（Behavioral Model View），UML是提供活動圖、狀態圖、循序圖、合作圖、時序圖與互動概觀圖作為流程塑模的工具。

（3） 發展觀點

發展觀點是從系統發展的觀點，將邏輯模型觀點與流程模型觀點所產生的類別、屬性與方法等，如何整合的作法進行細節的描述。有人將稱之為實作觀點或元件觀點，透過不同方式組裝成一些實際可操作的獨立元件與檔案，利用彼此間的互動關係來說明系統內部的模組或元件的結構以及彼此間的相依關係，例如實體元件的架構與元件之間的依存關係。在實施過程中，必須描述系統如何切割成軟體元件再進行實作的工作，UML是提供元件圖、套件圖與合作結構圖作為發展塑模的工具。

（4） 實體觀點

實體觀點是從系統運作的觀點，描述資訊系統的硬體之基礎架構。同時，顯示一些硬體設備、連接的方式、軟體程式的配置、訊息傳遞、系統安裝細節以及元件的實體部署狀況等。因此，實體觀點主要是提供系統設計人員有關於實體環境的細部設計的內容，做為資訊系統實作的依據。因此，有人稱之為佈署觀點（Deployment View），UML是提供部署圖作為實體塑模的工具。

（5） 情境觀點

情境是從使用者的觀點，描述資訊系統的功能性需求，因此，有關真實世界所面臨的問題、解決方案或領域的知識均是此部分含蓋的範圍。藉由描述系統的操作行為或事件的情境的描述，充分表達資訊系統的功能，針對行為者與系統之間互動的情形或是系統內部操作的作法進行詳細的描述，但是並不描述軟體的結構或行為的細節。情境觀點主要目的是提供系統設計人員進行架構設計或是驗證是否滿足使用者需求的工具，它是物件導向設計的重心，可以作為參與系統開發人員之間溝通的ㄧ個橋樑。因此，UML塑模作業是以 “情境” 為中心整合其他觀點所建構的物件模式，其重要性不言而喻，UML主要是提供使用個案圖與活動圖作為情境觀點塑模之工具。

綜合以上所述，Kruchten（1995）提出4+1 View軟體架構，它是以使用個案為軸心來整合各種觀點建構的模型，並針對不同系統開發人員角色的工作需求提供一些設計的具體指導原則與做法。



6. 請說明UML圖形與設計觀點的對應關係。

【參考答案】：

表一是統一塑模圖形與設計觀點的對應表。

表一：統一塑模圖形與設計觀點的對應表

設計觀點

統一塑模圖形 邏輯 情境 流程 發展 實體

使用個案圖 

活動圖  

類別圖 

物件圖 

循序圖 

合作圖 

狀態圖 

時序圖 

互動概觀圖 

套件圖 

合成結構圖 

元件圖 

部署圖 



7. 請說明UML的圖形如何應在系統分析與設計階段的過程。

【參考答案】：

一般而言，UML實施步驟如下：進行需求塑模強韌分析物件結構塑模物件互動行為分析塑模使用者面塑模系統與元件塑模，如圖七所示。茲將上述活動之工作項目敘述如下﹕

(一) 需求塑模的活動主要的活動是蒐集系統需求，需求是一個資訊系統發展的核心，亦是任何系統開發的工作重點，需求主要是分為功能需求（Functional Requirements）與非功能需求（None-functional Requirements），通是常利用訪談、問卷調查的程序或是蒐集與資訊系統相關的資料例如制度、資料表格或相關文件、UML主要是應用使用案例圖與活動圖進行需求塑模的活動。

(二) 強韌分析的活動主要的活動是確認需求分析的結果是否滿足使用者的需求，UML主要是應用強韌圖進行強韌分析塑模的活動。

(三) 結構塑模的活動主要的活動是進行結構塑模的作業，UML主要是應用類別圖與物件圖進行塑模的活動。

(四) 物件互動行為塑模的活動主要的活動是進行物件互動行為塑模的作業，UML主要是應用循序圖、合作圖、時序圖、互動概觀圖、活動圖與狀態圖進行塑模的活動。

(五) 使用者介面塑模的活動主要的活動是進行使用者介面塑模的工作，UML主要是應用介面架構、循序圖與狀態圖進行塑模的活動。

(六) 系統與元件塑模的活動主要的活動是進行子系統與元件的塑模，UML主要是應用部署圖、元件圖、合成結構圖與套件圖進行塑模的活動。

基本上，物件導向開發方法是採用漸進式與反覆式的作法進行資訊系統開發工作。因此，實施物件導向開發方法進行塑模時，必須不斷進行修正的工作，如此一來，使作業的彈性更具彈性而且建立之物件模式的品質更好。





圖七：UML圖形在系統分析與設計階段之應用



8. 何謂「靜態模型」? UML2.0包含哪些圖形工具?

【參考答案】：

所謂「靜態模型」是指：「物件的結構包括屬性與操作的描述，將一個資訊系統視為由ㄧ群套件、元件、類別、物件與介面所組合而成的實體，針對物件的結構提供一些規範性的語法，詳細描述其內容與條件。」靜態模型的工作重點為物件結構的設計，靜態模型可做為建立資料庫檔案的依據。

UML 2.0定義一系列的靜態模型分析工具，主要是提供的塑模工具包括類別圖(Class Diagram)、物件圖(Object Diagram)、元件圖(Component Diagram)、合成結構圖(Composite Structure Diagram)、套件圖(Package Diagram)與部署圖(Deployment Diagram)等分析工具，表二是靜態模型分析工具的彙整表，而表三是以架構觀點彙整統一塑模語言的靜態塑模工具，邏輯觀點包括類別圖與物件圖，發展觀點包括合成結構圖、元件圖與套件圖，實體觀點包括部署圖。以下擬各節針對UML 2.0靜態模型分析工具作詳細的介紹。

表二：UML 2.0 靜態模型分析工具的彙整表

工具型態 說明

類別圖

(Class Diagram) 主要是針對類別結構與操作進行描述，包括類別的屬性、操作、訊息以傳遞及類別之間的關係等。

物件圖

(Object Diagram) 主要是針對物件的結構及物件之操作進行描述，包括物件的屬性、方法、訊息以及物件之間的關係等。

元件圖

(Component Diagram) 主要是針對元件的結構及元件之操作進行描述。

合成結構圖

(Composite Structure Diagram) 它是UML 2.0 新增加的一個概念，主要是針對類別的內部結構，並對於協同合作的過程涉及的元件之間的合作關係進行描述。

套件圖

(Package Diagram) 主要是針對一些常用的類別、物件或套件等利用包裹套件的方式，將相關的類別與元件予以聚集成一個套件。

部署圖

(Deployment Diagram) 主要是針對實體的配置進行描述，說明實體世界的節點配置與連接方式。



表三：統一塑模語言的靜態塑模工具彙總表架構觀點

架構觀點 UML圖形 主要的元件

邏輯觀點 類別圖

類別、屬性、關聯、相依、一般化、介面、實現化

物件圖 物件、屬性、關聯、相依、一般化

發展觀點 合成結構圖 連結器、介面、組件、埠、供給/需求介面、合作、合作使用、角色

元件圖 元件、分類器、次系統、相依、關聯、實現化、埠、組件

套件圖 載入、模式、套件

實體觀點 部署圖 工作產出物、相依、關聯、節點



9. 請問UML2.0靜態模型的建立步驟爲何?

【參考答案】：

至於靜態模型的建立步驟如下：（1）制定目標，（2）需求分析，（3）初步靜態模型的製作架構圖，（4）細部靜態模型的製作屬性、操作與訊息傳遞，（5）檢討與修正，與（6）完成靜態模型的製作。



10. 何謂「類別圖」? 請舉一個實例來加以說明。

【參考答案】：

「類別圖」（Class Diagram）主要是用來描述類別的結構以及類別之間的關係。類別圖主要是應用在物件結構的塑模作業，描述有關於資訊系統之物件類型（Type）、類型間與子類型之間的靜態關係。類別圖的主要資料來源是使用案例圖、合作圖與循序圖之互動圖，由於物件導向分析與設計是採取反覆式與漸進式的做法。因此，若能夠以上述兩種資料交替進行塑模的工作，可以使物件結構塑模的作業進行更為順利。圖八是類別圖之一個實例。























圖八：類別圖的一個實例。



12. 以實作觀點而言，類別主要有哪些類型?

【參考答案】：

另一方面，從實作的觀點而言，類別有以下三種類型:

(1) 實體類別（Entity Class）指企業的實體資料，例如客戶資料、產品資料、採購資料等皆屬實體類別。大部分的實體類別是一種永續類別，即資料被儲存在資料庫中，實體類別的表示符號是一個圓圈下面有一條直線。

(2) 邊界類別（Boundary Class）指表單、報表與硬體介面或是與其他系統溝通介面之資料，也就是行為者與系統的介面，邊界類別又被稱為「介面類別」（Interface Class），大部分的邊界類別是一種暫存類別，其屬性包括欄位、超連結、方塊、按鈕等，邊界類別的表示符號是一個圓圈左邊加上一條垂直線。

(3) 控制類別（Entity Class）負責執行、控制動作、傳送資料、協調與其他類別之物件的工作者。主要工作是指派工作給其他類別之物件或是處理一些異常狀況的作業，例如執行發生錯誤時，系統應如何處理異常作業的一項作業程序。控制類別大部分是屬於一種暫存類別。因此，使用個案的事件處理或控制均交由控制類別來負責。控制類別的表示符號是一個圓圈邊界上加一個叉狀箭頭。



13. 請問製作一個類別圖的實施步驟爲何?

【參考答案】：

茲將製作類別圖的實施步驟敘述如下﹕

 步驟一﹕確認類別以及類別之屬性或操作

類別的主要資料來源包括需求分析文件、企業的詞彙表、使用案例、企業表單、報表、資訊系統或企業模型等。至於類別主要判斷的基準是根據領域知識、設計者的經驗、專家知識、現場實地觀察與使用者訪談的結果，最常見的ㄧ些案例是物體、物件的規格、抽象化概念、事件、交易活動或資料表等。以行銷資訊系統為例，客戶、產品、訂購、送貨與客戶抱怨等是屬於類別的類型。一般而言，類別或類別的屬性是以使用者個案規格的內容為主，其作業準則如下﹕

（1） 類別主要是來自於使用個案規格內容中描述中的重要名詞或代名詞。

（2） 類別是一些主要的物件與獨立實體，本身擁有某些重要的屬性與操作，經常出現在使用個案規格的描述中，主要是作為儲存資料之用途。

（3） 屬性是屬於描述類別的一種資料，在使用個案之規格敘述，採取「主詞+動詞+受詞」的描述方式，其中主詞或受詞這一部份可能是類別或屬性的名稱。

（4） 邊界或介面類別的屬性大部分是來自於活動圖的註記。

（5） 判斷是否為一個屬性的條件列舉如下﹕單一概念、某一個時間只有一個值、非衍生的屬性、擁有單元特性而非複合屬性。

（6） 操作是一種描述類別的行為，在使用個案之規格敘述，若採取「主詞+動詞+受詞」的描述方式，其中動詞的部份有可能是一個操作。

如果系統分析師已經順利完成循序圖時，根據循序圖的內容做為設計類別的參考依據。茲將另外一種建立類別圖的方法敘述如下:

（1）循序圖中的實體物件、邊界物件與控制物件直接對應至類別圖的實體物件、邊界物件與控制物件。

（2）循序圖中物件的訊息傳遞對應（Mapping）至類別圖的操作。

一般而言，類別圖的操作只是描述系統的行為，並不會進行程式邏輯細節的描述，因為物件導向設計方法是採取漸進式與反覆式的做法，經常要進行修正的動作，並不適合在此一階段進行細部的描述。其次，領域分析（Domain Analysis）是製作類別圖的一個重要的過程，進行領域分析的主要方式是透過使用者與系統領域的一些專家的訪談。一般而言，建構一個資訊系統的領域模式（Domain Model）必須描述類別、關係、資料字典與術語對照表。茲將進行領域分析的步驟敘述如下﹕（1）採用自然語言或文字分析進行問題的敘述，（2）確認類別並且建立相關的資料字典，（3）確認類別之間的關係，（4）定義類別的屬性與關係，（5）建立類別的繼承關係，（6）以 “資料查詢” 的事例來驗證類別的正確性，與（7）修正類別圖。此外，初步類別產生以後，必須針對下列項目進行診斷與調整工作﹕（1）類別名稱是否反應出使用的目的，（2）精確的描述抽象化的概念，（3）清晰的定義每一個類別的責任，（4）是否擁有高內聚力，（5）是否擁有低耦合力，與（6）避免過度的繼承關係，若是無法滿足上述要求，必須進行改善的工作。