物件導向式資料庫分析與設計

Object DB Analysis and Design

指導教授：陳彥良　博士

內容整理：89443007　沈清正

87423032　劉慧敏

89423042　江吉雄

緒論-------------------------------------------------------------------------------------------3

Part I UML------------------------------------------------------------------------------4

第1章前言------------------------------------------------------------------------------4

第2章視覺化塑模---------------------------------------------------------------------5

第3章UML簡介-----------------------------------------------------------------------6

第4章UML內容-----------------------------------------------------------------------9

4.1 使用案例(use case)----------------------------------------------------------------------9

4.2 類別圖(class diagram)------------------------------------------------------------------10

4.3 互動圖(interaction diagrams)----------------------------------------------------------13

4.4 狀態圖(statechart diagram)------------------------------------------------------------15

4.5 活動圖(activity diagram)---------------------------------------------------------------18

4.6 實體圖(implementation diagrams)----------------------------------------------------22

第5章UML與專案開發程序--------------------------------------------------------24

第6章UML總結-----------------------------------------------------------------------26

Part II　OODB 模式分析與設計----------------------------------------------------27

第7章物件導向資料庫模式系統分析----------------------------------------------27

7.1 問題陳述(problem statement)--------------------------------------------------27

7.2 列出暫時性的類別(Listing tentative Classes)-------------------------------28

7.3 去除假性的類別(Eliminating Spurious classes)-----------------------------29

7.4 列出暫時性的關聯(Listing Tentative Associations)------------------------30

7.5 去除假性的關聯(Eliminating Spurious Associations)----------------------31

7.6 精製關聯(refining associations)------------------------------------------------32

7.7 列出暫時性的物件與連結屬性(Listing Tentative Attributes of Objects

and links)--------------------------------------------------------------------------33

7.8 去除假性的屬性(Eliminating Spurious Attributes)----------------------34

7.9 利用一般化指明類別的相似與相異(Using Generalization to Note

Similarities and Differences)------------------------------------------------35

7.10 測試存取路徑(Testing Access Paths)------------------------------------37

7.11 反覆的琢磨類別(Iterating and Refining the model)-------------------38

7.12 搬動抽象的層次(Shifting the Level of Abstraction)-------------------38

7.13 第一次的修訂：增加Transaction的見解(First Revision: Introduce

the Notion of a Transaction )------------------------------------------------38

7.14 組成物件模式-------------------------------------------------------------------39

第8章物件導向資料庫模式系統設計---------------------------------------------41

8.1 考慮時間的資料(Dealing with Temporal Data)--------------------------41

8.2 考慮資料的第二面向(Dealing with SecondaryAspects of Data)---41

參考資料--------------------------------------------------------------------------------------43

緒論

本文架構分成兩大部份，Part I 一開始先介紹目前物件導向系統分析設計的標準UML，由傳統系統分析設計的缺點與視覺化塑模觀點切入，逐一介紹UML源起、各種圖形技術等。從Rational網站(http://www.rational.com/uml/ )取得的文件中，UML的定義分成三份文件，即UML Semantics、UML Notation Guide和UML Extensions。其中UML Semantics介紹母模型(meta-model)以規範UML圖形的語意、限制等。UML Notation Guide則介紹圖形技術內容表示法和使用範例。UML Extensions則包含使用者可依需求自定專屬的表示法和專業術語。本部份內容以“UML Distilled Second Edition”一書的內容為主，簡介UML中基本圖形技術內容範例與使用時機。

Part II則以“Object-Orinted Modeling and Design for Database Applications”一書內容為主，利用書中所舉投資組合管理為例，配合Part I所介紹之UML類別圖，以資料模式觀點介紹物件導向資料庫模式系統分析與設計。由問題陳述開始，將系統分析的過程分成14個步驟，並針對與資料模式相關的部分進行討論，忽略與操作模式相關的部分。設計的過程則延續分析的部份，考慮時間性資料和資料的第二面向，將分析架構做適當的調整，以配合資料庫實作需要。

Part I UML

第1章前言

近一兩年，在Inprise, Oracle, Javasoft, IBM, Microsoft,OMG,…等組織大力推廣軟體元件技術和架構下，「未來的軟體系統將是由一個一個軟體元件所組成的」的軟體發展技術趨勢，已普遍被大家所接受。很多企業也開始使用軟體元件來發展系統，不管是使用或自行開發的GUI元件和企業元件來兜成應用系統，均可視為以軟體元件為基礎的軟體發展方式。

基本上，實作標準化元件(如：DCOM, Corba, Javabean)並不難，幾乎所有的發展工具，如：Inprise , Microsoft, 或Sybase 等，均提供元件製作精靈的功能，透過這些精靈，我們很容易製作出標準化元件。其實元件化軟體發展方式更重要也是最困難的工作就在於，如何從企業需求中導出系統是由那些元件所組成的，如何設計出每個元件的介面(interface)和元件間是如何相互運作的。面對IT技術快速的演進，不管是Internet/Intranet, 元件化, 或3-tier 架構應用系統，都將使系統複雜度和開發風險大幅提高。

早期的系統分析、系統設計是以「程序」為主，作為整個系統分析與設計的主體。物件導向程式語言興起後，系統分析師們使用新的程式套用在舊的分析方法，發現到有許多困難，於是出現了物件導向系統分析（OOA）與物件導向系統設計（OOD）。未來的軟體開發方式，無論是元件化、Internet/Intranet、或是N-Tier 系統開發，將是以物件導向視覺化塑模(Visual Modeling)為主導的開發方式。

第2章視覺化塑模

視覺化塑模對於軟體發展者而言，也許會感到陌生或覺得又是一個新的名詞或新的發展工作模式。其實，在其他工程領域上，此工作模式已被運用的相當普遍而且非常成功，甚至一定要如此做，才有辦法把事情做好。當一個建設公司要蓋一棟大樓，它一定是先做好大樓的規劃，規劃要蓋幾層樓、每一層樓的外觀、樓梯電梯要位在哪裡，門窗陽台要如何設計、客廳房間長寬要多少、管線要如何配置、…等等，畫好大樓的藍圖和製作出大樓的模型，然後工人才根據此藍圖開始蓋大樓，絕不可能沒有藍圖就開始蓋，不然真無法想像蓋出來的大樓會變成什麼樣子。製造飛機、汽車、電腦、…等等的過程也是一樣，一定是做好各項規劃設計工作，畫好工作藍圖，才開始進行製造，過程中再搭配製造出一些雛形來加以驗證，以確保事情的成功。視覺化塑模正是這樣的工作模式。

為什麼這類的事情需要透過視覺化塑模才有辦法把事情做好呢？因為這類的事情都具有高複雜性、高風險性、和需要高度團隊合作的特性，以致於你需要做好規劃設計的工作，將高複雜的問題逐步加以簡單化，將高風險的問題逐步解決以降低風險，透過藍圖來加強各團隊成員的溝通，如此一來整件事情的發展一切就在你的掌握中，複雜度和風險性就可以有效的被控制，並可促進團隊的合作，提高整體的生產力。甚至簡單到裁縫衣服這類的事情，裁縫師都有必要先繪製好衣服的藍圖，才有辦法做好一件衣服。

因此，未來軟體開發方式更應該採用視覺化塑模技術，就跟蓋房子一樣，你需要好好地規劃和設計你的系統藍圖，然後按圖施工，以降低系統開發之風險和有效管理系統複雜度，並確保系統的品質、可維護和擴充性、更可節省開發的時間和成本。並且，在可預見的未來，支援視覺化塑模的工具將成為軟體發展的必備工具之一。

第3章UML簡介

視覺化塑模乃是一種系統規劃、分析、設計，將系統視覺化，繪製系統藍圖的發展方式。並且，必須定義一套支援到系統發展各個階段的標準化符號，無論從需求收集、架構設計、元件設計、甚至到系統軟硬體上線佈建，均可透過這套標準化符號繪製系統藍圖。

1980年代，物件走出實驗室踏入真實世界。1980年代後期到1990年代早期出現了一波物件導向分析設計方法論的熱潮，UML延續了這股熱潮，整合了物件技術大師Grady Booch、IvarJacobson、和Jim Rumbaugh等許多人的方法論，並由Rational公司向OMG (Object Management Group)提出標準化的提案。經過各種不同提案的角力與結合，OMG終於在1997年11月宣佈UML 1.1版為第一代官方標準，目前OMG的第二代官方標準為UML 1.3版。UML的全名為統一塑模語言(Unified Modeling Language)，顧名思義，其主要用意就是要將系統視覺化和文件規格所用的符號加以統一。

UML支援到軟體開發的各個階段，無論從需求收集、分析、架構設計、以及元件設計，均可使用UML的符號來表達。UML是一種模型語言(modeling language)，用來詳細描述、顯現、建構和記錄整個系統的發展內容。

UML定義了一組表示法(notation)和一個母模型(meta-model)。表示法是我們在模型中看到的圖形部份，它也是模型語言的語法。例如，為類別圖(class diagram)的表示法，我們定義了類別(class)、關聯(association)和多重性(multiplicity)等項目和概念來說明它的表示法。大家也許會問：類別、關聯和多重性的精確定義是什麼？我們可以從一般的使用情況得到非正式的定義，不過，大多數人還是希望知道一個嚴謹的定義。

　　正式的方法論大多定義了嚴謹的規格和設計語言。在某些技術中，規格和設計語言用一些數學的表示法（例如predicate calculus），這樣的定義很嚴謹而不會有模擬兩可的情形發生。但是這樣的定義是否符合系統需求？設計須關注於開發時所遭遇的重要議題上，正式的方法論常讓人不自覺的陷入細節的泥沼中，而且有時很難瞭解或實行它。大部份的物件方法論都不太嚴謹，它們的表示法看起來直覺好用，雖然沒有正式的定義，只要大家瞭解這些表示法的意義就行。然而，研究物件方法論的人還是希望能改善不夠嚴謹的問題，最重要的是不能破壞好用的特性，於是其中一個解決方法便是定義出母模型和用圖（通常是類別圖）來定義表示法，如下圖所示之部份UML母模型，裡面說明關聯和一般化(generalization)關係。

部份UML母模型

母模型幫助我們定義出什麼是好的模型，即語法正確的模型。大部份的使用者並不須深入瞭解母模型，光是使用UML表示法就能帶來很大的好處，所以我們在這裡不打算介紹母模型，只介紹UML的表示法。UML的表示法主要內容包含以下圖形技術：

• 使用案例(use case)

• 類別圖(class diagram)

• 互動圖(interaction diagrams) ：

  • 順序圖(sequence diagram)

  • 合作圖(collaboration diagram)

• 狀態圖(statechart diagram)

• 活動圖(activity diagram)

• 實體圖(implementation diagrams)：

  • 元件圖(component diagram)

  • 配置圖(deployment diagram)

其中互動圖分成順序圖和合作圖，實體圖則提供元件圖和配置圖兩種表示圖形。

第4章UML內容

4.1 使用案例(use case)

使用案例主要用來收集使用者需求。使用案例由一組情節(scenarios)組成，每個情節描述使用者與系統間一連串互動的步驟。例如顧客在網路商店購買商品的情節：顧客先瀏覽型錄，再把想要的東西放進購物籃中，當他付錢時，輸入送貨和信用卡資料，然後確認這筆交易，接著系統會檢查其信用卡資料並確認這筆銷售，最後發出電子郵件。使用案例通常包含一個普遍且正常可行的情節，和其他多個可行或不可行的替代方案。在訪談使用者的過程中，根據使用者描述之承辦業務和流程，轉換成可能的使用案例，並決定啟動這些使用案例的參與者(actors)，加上之前所界定的系統範圍，很容易就可分析出使用案例圖。

以圖1為例，說明如下：

參與者：包括交易經理、交易員、銷售員和會計系統，即圖中人形部份。表示使用者在使用系統時所扮演的一個角色。一個使用者可能扮演許多角色（例如交易經理同時也是資深的交易員），多個使用者可能扮演同樣角色（例如組織內部有許多銷售員）。參與者有可能是人類，也可能是其他外部系統。

使用案例：包括設定交易量限制、更新會計資料、分析風險等，即圖中橢圓形部份。使用案例與參與者間的連線代表參與者與使用案例間的關係。一個使用者可執行多個使用案例，一個使用案例也可由多個使用者執行。使用案例間也可能相關，例如：圖中<<包含>>代表「分析風險」和「交易價格」兩使用案例參考「評估交易價值」使用案例。

使用時機：使用案例被使用在收集使用者需求時。在訪談使用者的過程中，使用者很容易地描述出其承辦的業務流程，這些都將是可能的使用案例，也可一併決定出啟動這些使用案例的行為者，再加上之前所界定的系統界線，就很容易分析出使用案例圖了。在進行使用案例分析時，除了繪製使用案例圖外，針對每一個代表企業流程的使用案例，需進一步與使用者互動，以便更進一步詳細描述流程的情節(scenario)，即系統與行為者互動的過程。

圖1：使用案例圖

4.2 類別圖(class diagram)

類別圖是物件導向方法論的核心部份，主要表達出系統靜態結構，包括物件的各種型態和物件之間各種靜態關係。根據Steve Cook和John Daniel(1994)年的想法，可以從三個觀點來畫類別圖或模型，說明如下：

分析階段畫概念觀點模型。此時類別圖表現的是領域裡的概念，即描述真實狀況的觀點（例如一張訂單只能屬於一個人，不能有兩人擁有同一份訂單）。一個概念觀點模型應該儘量跟實作它的軟體無關（例如與程式語言無關）。設計階段畫規格觀點模型。此時類別圖注重的是系統介面(interfaces)。

正式的UML並沒有說明這些觀點，但是它提供stereotypes可以將類別(class)加上<<type>>標記表示此類別屬於概念觀點或規格觀點，而以<<implementation class>>標記表示此類別屬於實作觀點。

由於類別圖所包含的東西很多，因此只以圖2訂單作業為例，介紹其基本概念：

圖2：類別圖

1. 關聯(associations)：代表類別實例(instances)間的關係（例如顧客下很多訂單，一個訂單屬於一個顧客）。

2. 角色名稱(role name)：每個關聯會有兩個端點，端點以標籤命名為角色名稱，若端點沒用標籤命名，則直接以類別名稱命名（例如Order Line和Order的關聯在Order Line端的角色名稱為line items，而Order端的角色名稱則自動命名為order）。

3. 多重性(multiplicity)：代表在某關聯中會有多少個物件參與此關聯（例如「*」代表多個、「1」代表1個、「0..1」代表0到1個，即下限和上限）。

4. 屬性(attributes)：代表該類別的特性（例如顧客有姓名）。UML的正式表示法為：可見性(visibility) 名稱：型態(types) ＝ 預設值，其中可見性可以是「+」public、「#」protected和「-」private。

5. 操作(operations)：指一些程序，而類別知道該如何完成這些程序工作。UML的正式表示法為：可見性 名稱　（參數序列）： ＝ 傳回型態表示式｛屬性字串｝（例如+balanceOn (date: Date) : Money），其中參數序列包含一串用逗號隔開的參數，其表示法為：方向 名稱型態 ＝ 預設值，方向用來表示參數是輸入(in, 預設值)、輸出(out)和輸入輸出(inout)；傳回型態表示式是用逗號隔開的傳回型態，允許同時傳回數個型態；屬性字串則用來表示操作的性質（例如用{query}代表該操作只從類別中取值，不會去改變系統狀態）。

6. 一般化(generalization)：顧客分成個人顧客和公司顧客是一般化的典型例子。其中顧客類別為超型態(supertypes)，個人顧客和公司顧客則為子型態(subtypes)。子型態會繼承超型態的關聯、屬性和操作等。

7. 限制(constrains)：類別圖中的東西都是一種限制（例如一個訂單只會跟一個顧客有關）。UML允許用任何東西來描述限制，只要放進{}中即可。此外UML也提供正式的物件限制語言(object constraint language, 簡稱OCL)。

使用時機：在分析完一個或多個順序圖後，你可以整理出從各個情節中找出了哪些物件，進一步去發掘物件彼此間是否存在有共通性（如：相同的屬性和方法），然後定義出用來產生這些物件的類別，並根據順序圖的訊息資訊，定義出類別之間的關聯，最後繪製出類別圖。在設計階段，若是因為設計的考量有增加新的類別時，則需再檢討新類別是否會對原先的類別圖產生影響，檢討後的類別圖就成為因設計考量而調整的結果，而無需修改分析階段的類別圖。有關類別圖其它細節請參考本文Part II-第7章-7.14 組成物件模式。

4.3 互動圖(interaction diagrams)

互動圖是用來描述一群物件在一個使用案例中的行為，包括物件和物件之間的訊息(message)傳遞。互動圖利於顯示出物件間的合作情形、行為的先後順序，卻不適合用來精確定義物件的行為。互動圖分成兩種，即順序圖與合作圖，分別說明如下：

4.3.1 順序圖(sequence diagram)

以（圖3-1）為例，說明如下：

1. 物件以一個方形顯示在垂直虛線上方，這條垂直虛線稱為物件生命線(lifeline)，生命線表示物件在互動時的生命週期。

2. 訊息(message)：以兩條物件生命線間的箭頭表示，其顯示順序由上而下。每個訊息至少會標示訊息名稱，也可以加上一些參數或控制資訊。訊息也可以將訊息送給物件本身，叫作自身呼叫(self-call)。

3. 啟動(activation)：以長條形表示，顯示物件被啟動的期間，也可以省略不畫。

4. 控制資訊：分成條件(condition)和重複標記(iteration marker)兩種。條件訊息只有條件成立時才被送出。重複標記則當訊息重複送給好幾個物件，可以用*[for all order lines]的格式來表示。

5. 返回(return)：代表訊息的回覆，以虛線箭頭表示。

6. 產生(creation)：即產生一個新物件。

7. 刪除(delete)：以一個大X表示，代表物件的刪除。物件可能自行刪除，也可能因為其他訊息才被刪除。

此外，順序圖也提供並行程序(concurrent processes)與非同步訊息(asynchronous message)的處理。

使用時機：在紀錄完企業流程的情節後，根據這些情節加以分析，找出完成此情節的物件和彼此間傳遞的訊息，再加上時間軸，繪製成順序圖。在設計階段，若是因為設計的考量有增加新的類別時，則需再檢討新類別的物件是否會對原先的順序圖產生影響，檢討後的順序圖就成為因設計考量而調整的結果，而無需修改分析階段的順序圖。

圖3-1：順序圖

4.3.2 合作圖(collaboration diagram)

以（圖3-2）為例，說明如下：

1. 物件與訊息顯示方式與順序圖一樣。訊息以編號決定其先後順序，UML的訊息編號是採用小數點編號方式，這種方式可以清楚顯示出一個操作(operation)裡面的其他操作。

2. 物件命名方式以“物件名稱：物件類別名稱”的型式顯示，其中「物件名稱」可以省略，但是冒號不可省略。

圖3-2：合作圖

4.4 狀態圖(statechart diagram)

狀態圖主要用來描述某個物件之所有可能狀態，和物件如何隨不同事件(events)而改變其狀態，對於描述某物件在不同使用案例中的行為很有幫助。以（圖4-1）描述訂單處理作業中的訂單的狀態為例，說明如下：

1. 起始點(start point)：圖中黑色圓點，表示有一個初始的轉換(/get first item)連接到Checking(檢查中)狀態。

2. 狀態(state)：例如Checking(檢查中)、Waiting(等待中)和Delivered(已遞送)等，以圓角矩形表示。

3. 活動(activity)：以“do / 活動”的型式表示。例如Checking(檢查中)狀態下半部之「do/check item」，即進入此狀態後所需執行的工作。活動執行的時間較長而且可被一些事件中斷。

4. 轉換(transition)：語法包含三部份（可選擇性的使用），即“Event[成立條件(guard)] / 動作(action)”。在「/get first item」中，只有動作部份，執行完動作後，就會進入Checking(檢查中)狀態，此狀態內有一個活動：check item(檢查單項)。動作執行的時間較短而且不能被中斷。

圖4-1：沒有使用超狀態的狀態圖

5. 狀態：對一個狀態來說，只有一個成立條件(guard)為真的轉換能離開此狀態，因此我們要讓一個事件的各個成立條件是互斥的。例如Checking(檢查中)狀態有四個會離開的轉換，這四種情況為：

1. 假如我們還沒檢查過所有項目，就取得下一個項目(/get next item)，然後回到Checking(檢查中)狀態檢查它。

2. 假如我們已經檢查過所有項目且它們都有庫存，就轉換到Dispatching(發送中)狀態。

3. 假如我們已經檢查過所有項目，而有些項目沒有庫存，就轉換到Waiting(等待中)狀態。

4. 取消訂單事件發生，不必檢查成立條件，直接轉換到Cancelled(已取消)狀態。

6. 超狀態(superstate)：如果我們希望在訂單遞送前取消它，如果以（圖4-1）的畫法，必需從Checking(檢查中)、Waiting(等待中)和Dispatching(發送中)狀態各畫一條離開的轉換至Cancelled(已取消)狀態。如果我們改以（圖4-2）的畫法，在Checking(檢查中)、Waiting(等待中)和Dispatching(發送中)狀態外先產生一超狀態Active(處理中)，然後畫單獨一條離開的轉換至Cancelled(已取消)狀態即可，超狀態內的每個子狀態都會繼承超狀態的轉換，這樣就可以清楚的表示取消訂單的處理。

圖4-2：使用超狀態的狀態圖

訂單狀態除了上述情形外，還包括一些付款授權的狀態，將這些狀態結合起來可以畫成如（圖4-3）之並行狀態圖(concurrent state diagram)。圖中表示訂單處理作業除了檢查訂單項目、存貨外，還同時進行檢查付款的活動。一開始取得顧客付款同意後，便進入授權中狀態，假如付款的結果為OK，那麼訂單會在已授權狀態等待，直到已遞送狀態發生。並行狀態圖對處理同一物件之並行行為很有幫助（這在接下來要介紹的活動圖中會表示得更清楚，狀態圖較強調非同步狀態的處理），但是同一物件不該有太多的並行行為，如果某物件有數個複雜的並行狀態圖，代表這個物件該被拆開成數個物件。

使用時機：若系統內的物件有狀態轉換(state transition)的情形，那發展者就需要透過狀態圖的繪製，協助發展者分析物件內部的動態行為，即狀態轉換的過程。狀態圖適合描述跨數個使用案例之物件內之行為轉換過程。但並不是系統內的每個類別都需要繪製此圖，可依據那些內部有強烈狀態轉換的物件加以繪製即可，以節省你寶貴的時間。一般而言，UI和流程控制的物件均屬此類之物件。在設計階段時，若分析出的狀態圖內的狀態很多，狀態變遷很複雜的話，可套用狀態的設計樣板(state design pattern)，以增加設計的彈性。通常狀態圖的分析將視需要而定，所有系統內的物件均找不到狀態變遷的情形，則不必強求。

圖4-3：並行狀態圖（部份細節）

4.5 活動圖(activity diagram)

活動圖描述活動的發生順序，同時也支援條件式(conditional)與平行(parallel)的行為。適合建立工作流程模型，處理多執行緒(multithread)程式，也適合於當分析一個使用案例時，只想瞭解什麼動作需要發生、行為間的關係，不管物件為何的時候。

活動圖是狀態圖的一個變種。基本上活動圖大部份的專有名詞都跟狀態圖一樣。在這裡只介紹不同的部份，如（圖5-1）訂單處理流程所示：

1. 分支(branches)：條件式(conditional)行為用分支和合併表示，代表有一個進入的轉換(incoming transition)和數個有成立條件(guard)的離開轉換(outgoing transition)。成立條件間是互斥的，只有一個離開轉換會成立。

2. 合併(merges)：會有數個輸入轉換(input transition)和一個輸出轉換(output transition)。合併用以表示以分支為開端的條件式行為的結束。

3. 分叉(fork)：平行(parallel)行為用分叉和會合表示，有一個進入轉換和數個離開轉換。當離開轉換引發後，所有離開轉換會平行發生。因此在（圖5-1）中，收到一張訂單後，會同時準備訂單上的貨品跟送出發票的行為。即有些活動會同時發生，與順序無關。

4. 會合(join)：所有進入轉換的狀態必須先完成它們的活動，離開轉換才會發生。即當有平行行為發生時，需要確保它們同步(synchronize)。例如（圖5-1）在結束訂單活動前使用會合即是上述觀念的表達。

圖5-1：活動圖

5. 活動的分解：一個活動可以被分解成幾個子活動(subactivities)，或是說幾個相關的子活動可以合成一個活動，就如同狀態圖中的超狀態。如（圖5-2）表示，遞送活動可分成隔夜送達或一般送達兩個子活動。

圖5-2：活動的分解

6. 水道(swimlanes)：活動圖可以表達幾個不同的物件類別（例如負責此活動的部門）所形成的活動順序。如（圖5-3）表示，以直線垂直分開的區域代表不同的物件類別（例如Fulfillment、Customer Service、Finance）所負責的活動。

圖5-2：水道(swimlanes)

4.6 實體圖(implementation diagrams)

UML提供兩種實體圖：配置圖(Deployment Diagram)與元件圖(Component Diagram)。實體圖顯示軟體實作的部份，包含原始碼架構(source code structure)與執行實作架構(run-timeimplementationstructure)。前者為元件圖，後者則為配置圖所要表達的意念。說明如下：

4.6.1 元件圖(component diagram)

當一步一步做完分析之後，接下來除了加入設計機制的考量和定義類別內屬性和方法的參數及還回值的型態外，你需要決定系統將被切割成那幾個軟體元件以及軟體元件之間的關係，然後繪製元件圖。

元件圖顯示軟體元件間的相依性(software components)，元件部份包括原始碼元件(source codecomponents)、二元碼元件(binary code components)，和可執行元件(executable components)。元件各自有存活時期，例如編譯時期(compile time)、連結時期(link time)、執行時期(run time)等，有些元件甚至跨越不同時期。原始碼元件圖表達檔案間編譯關係﹔二元碼元件圖呈現出類別在Run-Time Library 中的配置關係﹔可執行元件圖包含各元件的介面（Interface，如Course、User、BillingSystem的長條形符號）和彼此呼叫(Calling Dependency，如Register.exe利用虛線箭頭指向Course)的相依關係。

4.6.2 配置圖(deployment diagram)

面對越來越複雜的網路系統，你可能有多個Server(Database server/Transaction server/Web server)和多個Client，而且系統元件可能分佈在不同的server上執行，在同一個Server上，不同的程序同時執行不同的元件。因此，你需要透過配置圖好好規劃系統在實際環境執行時，各運作單元(如Registration, Database node)的分佈安排、彼此間關係的定義、以及在各運作單元上所執行的軟體程序(Software Process)的安排，如下圖所示：

系統複雜到有多個Server和多個Client，系統元件可能分佈在不同的server上執行。而且在同一個Server上，不同的軟體程序同時執行不同的元件。未來系統真的上線時，就可按圖施工了。

第5章UML與專案開發程序

本章簡介UML圖形技術在物件導向開發專案過程中被使用的方式。我們使用Rational統一程序(Rational Unified Process)為專案開發程序，由物件導向巨擘技術大師Grady Booch、IvarJacobson、和Jim Rumbaugh所建立，其架構圖如下所示：

Rational統一程序

1. 初始階段：建立專案的企業原理和專案範圍，此階段需得到專案贊助者的承諾才能做進一步的開發。

2. 詳述階段：詳細收集使用者需求階段，需要評估各種風險（包含需求、技術、技能和政治等風險）。專案開發人員可以用使用案例來找出所有可能的使用者需求，並當作與使用者溝通的基礎。接下來專案開發人員可以類別圖和活動圖來建立領域模型。領域模型用來描述系統中的基本物件模型，例如描述企業的財務部門是如何運作。類別圖用以勾勒出企業專家對企業活動的概念，以及如何將這些概念串在一起。活動圖則用來描述工作流程，它最主要的貢獻在於找出企業中平行的活動，減少企業流程中不必要的部份。在處理技術風險時，最重要的就是以想要的技術建立系統原型(prototype)，瞭解系統元件是很重要的事，例如類別圖和互動圖通常用來表達各元件之間是如何溝通，配置圖則可以提供系統各部份如何被分散配置的概觀。

3. 建構階段：此時開始進行專案的實作。專案開發人員先將之前的使用案例加以分類（有高優先權和高開發風險的使用案例要排在前面處理），分階段完成這些使用案例功能面，包括分析、設計、寫程式、單元測試、整合測試和撰寫技術文件等工作。進行設計時，專案開發人員需要研究這些概念性類別圖中的類別是如何合作達成使用案例所需的功能。CRC卡片（Class-Responsibility-Collaboration Card，幫助定義類別本身與類別之間關聯的方法）和互動圖在探索這些互動時很有用。如果類別的行為有複雜的生命週期(lifecycle)時則可以使用狀態圖來表示。

4. 轉換階段：開發程序的最後階段，使系統達到最佳化(optimization)的狀態。減少系統的清晰度和延伸性以增進系統效能，一個系統必須快速執行以滿足使用者需求，此時不要為了增加功能而去更改系統，只要修正系統錯誤即可。

第6章UML總結

因此，從需求收集、物件導向分析／設計、架構設計（N-Tier, Internet/Intranet, 元件化架構）、甚至到系統上線的配置圖，UML均定義了標準符號給發展者於系統視覺化、溝通和產生各式文件時使用。但UML並不定義軟體發展程序，就好想蓋房子的藍圖採用同樣的一組符號，但蓋法可能各家不一樣。因此，不管你採用的是哪一套發展程序，均可採用UML當作其塑模符號，只是發展的步驟不一樣而已。但UML各圖之間是有相關性的，如：使用案例會導出一至多個順序圖、順序圖的物件會導出類別圖的類別、順序圖的訊息會導出類別圖的方法、元件圖的元件包含類別圖的類別…等等，而且這些推導過程是循環漸增式的(Iterative and Incremental)，彼此間環環相扣，相互確認，一直到整個模型同時穩定為止。

Part II　OODB 模式分析與設計

第7章物件導向資料庫模式系統分析

在分析的過程中，將針對與資料模式相關的部分進行討論，並不討論與操作模式相關的部分，因為操作模式與實作較為相關。

分析的程序包含下列步驟：

1. 問題陳述。

2. 列出暫時性的類別。

3. 去除假性的類別。

4. 列出暫時性的關聯。

5. 去除假性的關聯。

6. 精製關聯。

7. 列出暫時性的屬性。

8. 去除假性的屬性。

9. 利用一般化指明類別的相似與相異。

10. 測試存取路徑。

11. 反覆的琢磨類別。

12. 搬動抽象的層次。

13. 修訂。

14. 組成物件模式。

而每一步驟各包含數項要點，而系統則依要點進行分析。接下來我們以一個為管理投資組合所發展軟體過程作為說明，說明其過程步驟：

7.1問題陳述(problem statement)

問題陳述用以描述系統需求，界定系統範圍。下表是投資組合管理(portfolios manager)問題陳述的內容。

7.2列出暫時性的類別(Listing tentative Classes)

將可能性的類別以下列原則一一找出。

• 名詞與名詞片語(Nouns and noun phrases)

下列文章中黑體字為本原則所找出的項目

• 被動式語態(Passive voice)- software developer

• 隱含的類別(Implicit classes)- financialinstitution (holder)，person(owner)

• 類別的種類(Kinds of classes)- 自然實體(physical entities)(cash, precious metals)，概念實體(conceptual entities)(financial instrument, portfolio)

• 再用(Reuse)- 盡可能再利用先前已定義的類別實體

• 定名(Naming)- 謹慎的選擇類別名稱

• 行蹤不明的類別(Missing classes)- 行蹤不明的類別會造成存取路徑的缺口、行蹤不明的目標與操作的爭議。

7.3去除假性的類別(Eliminating Spurious　

classes)

• 多餘的類別(Redundant classes)-將性質相同的類別歸類成為一類，或性質內容值正負相反的類別歸類成為一類：

InvestmentPortfolio, Mixture, PortfolioPortfolio

Security, AssetAsset

Purchase, SaleCurrencyConversion

Asset, LiabilityAsset

Bond, Loan Bond

• 不恰當的與含糊的類別(irrelevant or vague classes)- 去除不恰當的與含糊的類別：software, capabilities, issuance, kinds

• 屬性(attributes)- 去除應是歸類為屬性的項目：dates, price, value, fee

• 操作(operations)- 去除運算產生的資料：ROI

• 角色(roles)- 角色只會出現在某一特定的情況下並無法代表全部的類別，所以要去除：

AccountholderFinancialInstitution

AccountownerPerson

• 導出類別(derived classes) - 推延導出類別到設計階段再產生

• 實作訊息(implementation information)- 避免與建構結構有關的如linked lists, tree等：去除Hierarchy

• 推延到設計階段- 有些項目在設計階段才會出現：stocksplit

經過本階段的處理後現在剩下的類別為：Financial Institution, Person, Asset, Bond, Stock, Stock Option, Mutual Fund, Precious Metal, Collectible, Cash, Insurance, Real Estate, Financial Instrument, Portfolio, Purchase, Sale, Dividend, and Interest Payment等。

7.4列出暫時性的關聯(Listing Tentative

Associations)

我們以下列的的指導方針列出暫時性的關聯：

• 動詞與介係詞片語(Verbs and prepositional phrases:)

其原則為名詞動詞名詞或是名詞介係詞名詞(noun verb noun or noun preposition noun)會具有關聯，下列文章中黑體字為本原則所找出的可能具有關聯的項目項目

而有些名詞動詞名詞如：a financial instrument is an asset, liability不是關聯而是一般化的指標。

• 相依(Dependencies)- 當兩個或兩個以的類別有相依的關係，就可能有關聯如：purchase and sale of financial instruments

• 隱含的關聯(Implicit Associations)- 有些關聯是隱含的如：a financial institution holds portfolios and persons own portfolios.

• 一般的常識(General knowledge)- 如：a bond has interest payments, a stock has dividends, and a stock option has an underlying stock

• 關聯的種類(Kinds of Associations)- 關聯的種類有許多，包括實際位置(physical location ) (next to, contained in), 直接作用(drives), 交流(talks to), 所有權(has, part of), 或者是滿足某種條件(works for, married to, manages) 如：portfolios contain financial instruments.

• 避免指標(avoid pointers)-這是在設計階段所要考慮的一種方法

以下是可進一步考量的關聯

7.5去除假性的關聯(Eliminating Spurious

Associations)

有些關聯實際上不應存在分析階段上，說明如下：

• 被去除類別間的關聯(Associations between eliminated classes)- 如果有一類別被捨去，這實作相關的關聯也應捨去如：

software for managing investment portfolios, hierarchy of portfolios, value of assets, and currency conversions with possible fees

• 不相關與實作性的關聯(Irrelevant or implementation associations)- 與外界領域關聯或是實作才會產生的關聯也應捨去如：hierarchy of portfolios

• 活動(Actions)- 關聯是說明結構的屬性而不是在說明事件

• 三元關聯(Ternary associations)- 在一般的情況下三元或多元關聯可轉換成二元關聯或是用限定資格的方式表達關聯如：phrase mixture of assets and liabilities as mixture of assets

• 導出關聯(derived associations ) – 不要管導出關聯

最後在分析步驟中剩下的關聯如下表:

7.6精製關聯(refining associations)

對關聯而言這時還是需要加以精製，下列的規定對關聯語義加以規範：

• 過早的實做(Premature implementation)- 要注意要表現邏輯的意圖，而非實作導向，過早的實做使得在了解全局前就做了明細的決定。

• 誤稱的關聯(Misnamed associations). 精心地選擇名字。決定名稱對於理解非常重要, 應該非常小心選擇他們，當不會混淆時可以省略名稱，如有笨拙的名稱則必須重新修訂名稱如：portfolio of assets as portfolio contains assets

• 角色名稱(roles names)- 角色名稱用以表示問題中出現角色的特性，或是用以表示兩個類別間不同的關聯，特別是對反身關聯(reflexive associations)特別重要

• 資格(Qualifiers)- 盡可能使用資格的特性用以表現特定的緊密的從屬關係，但在分析時尚不需要表現他

• 多重性(Multiplicity)- 多重性用以表現兩個類別參予的程度由0..1,1,*,m..n所組合表現

• 關聯類別(Association classes)- 用以完整的表現兩個類別的關聯，這類類別用以說明較複雜關聯特性，如有多個屬性與操作甚至可與其他類別進行關聯

• 遺失的關聯(Missing association)- 應該有但是需求定義上沒有表現關聯，特別是在建構功能模式時

• 聚合(aggregation)- 一類別擁有其他類別的特性關聯如：portfolios contain financial instruments

• 合成(composition)- 一類別由其他類別組成的特性關聯，與上述差異為合成是非選擇性所有的成員必須同時存在或不存在，聚合則是選擇性的出現

下圖是最初提出的投資組合管理的類別圖

7.7列出暫時性的物件與連結屬性(Listing

Tentative Attributes of Objects and links)

注意在需求中的名詞如the population of the city or the password of the user，或者是存在許多特定可列舉數(enumerations)red, green, blue，下列文章中黑體字為本原則所找出的可能具有的屬性片語：

• 遺失的屬性(Missing attributes)- 不像類別，與關聯一樣, 屬性不可能在問題聲明中提示清楚，必須利用對應用程式的了解的知識和熟練的經驗以找到他們。幸虧，屬性很少影響一個問題的基本架構，如投資管理有preferred stock 與common stock這樣我們就可以加入一個isprefrred的屬性給stock。

• 有限的發覺屬性(Limit discovery of attributes)- 不要過度發覺屬性，只要考慮直接與應用有關的屬性。

• 避開指標(avoid pointers)- 屬性不應該涉及物件，在物件之間描述應使用關聯。

7.8去除假性的屬性(Eliminating Spurious

Attributes)

利用下列的準則去除不需要與不正確的屬性。

• 物件(Objects)-如果與實體不相依而獨立存在且具有重要，而非僅僅是它的值，這是一個物件。詳細調查這些類別和試驗性的屬性以確信你沒有錯貼任何屬性或者是類別。

• 資格(Qualifiers)-.如果一個屬性的值取決於特定環境條件，, 考慮作為資格者重申屬性。如姓名作為qualifiers較成為物件屬性更好，在我們的問題而言還沒有運用qualifiers。

• 定義者(Identifiers)- 定義者在物件導向模式是隱性屬性不需顯現。

• 連結屬性(Link attributes)- 在關聯發生才成立的屬性如：Asset與Portfolio間的quantity。

• 澄清明細(fine detail)- 省略對應用不重要的次要屬性。

• 導出屬性(Derived attribute)- 省略導出屬性

• 不相干的屬性(Discordant attributes) .好像是完全不同的一個屬性並且對所有其他屬性的不相關，可能應該分解兩個截然不同類別，一個類別)應該是簡單和一致的。如果你們遇到許多不一致屬性，你們的分析很可能是瑕疵的，用自然界相關事情的描述主要的方法，笨拙結合應該很少出現。

• 布林屬性(Boolean attributes)- 可以將布林二值屬性更改為列舉多值屬性如：isPreferred StockType(common , preferred , closed-end ,與others)

下圖說明投資組合管理具有屬性的類別圖

7.9利用一般化指明類別的相似與相異(Using

Generalization to Note Similarities and

Differences)

接下來是用由上而下或由下而上的方式，以繼承架構的方式組織類別。

• 由上而下一般化(Top-down generalization)- 將已存在的類別特殊化為子類別。

在我們應用的例子中，將Bond, Stock, StockOption, MutualFund, PreciousMetal, Collectible. Cash, Insurance, and RealEstate視為Asset的子類別

is-a是明顯的一般化如a financial instrument is an asset, liability, or portfolio. ，financial instrument明顯是asset, liability, or portfolio一般化類別

• 由下而上一般化(Bottom-up generalization)- 找出類別相同的屬性、關聯或操作，建立一抽象的類別以分享共同的資訊。

在我們應用的例子中，投資組合的收益分為兩類一是股息(dividends)、一是利息(interest)，根據這項差異我們對類別進行調整如下：

分裂：MutualFund. BondFund and StockFund.

利息一般化：Bond and BondFund  BondAsset

股息一般化：Stock and StockFund  StockAsset

同時各種金融產品各具有部分的相同與相異點，是否要分裂或是要一般化端看使用者與環境的需求。

• 調整關聯的佈置(Adjust placement of associations)

當你討論到繼承時，因為類別的特性有所調整，所以你也要調整關聯的佈置，如asset.有值可以直接買賣，portfolio 卻不是asset，因此portfolio中的Financiallnstrument 不可以直接買賣，所以purchase 與sale 不可以與Financiallnstrument有直接關聯但可以與Asset關聯，而我們將聚合Asset與portfolio的聚合移轉為Financiallnstrument與portfolio的聚合，而Financiallnstrument是Asset與次要portfolio的一般化。

• 多重繼承(Multiple inheritance)- 可以用若干繼承來增進分享, 但是, 並非必要, 因為它會增加概念性的複雜性。多重繼承使用在設計期間更適當。

下圖顯示增加了繼承後的投資組合管理類別圖

7.10測試存取路徑(Testing Access Paths)

在物件模式你是無法徹底證實途徑是否正確，如在OMT直到功能模型才可達成。在物件模式中期望得到一個唯一的值時我們用qualifiers 限定其存取路徑，如用accountNumber 用到Portfolio 與Financiallnstitution 之間的關聯上，而bondasset與interestpayment間關聯與stockasset與dividend間關聯用date作qualifiers用以限定存取對象。

7.11反覆的琢磨類別(Iterating and Refining the

model)

反覆的討論各種限制如qualifiers的使用與應用樣式格式到你的系統中使系統減少不確定與不一致的部分，使應用系統更正確與有效。

7.12搬動抽象的層次(Shifting the Level of

Abstraction)

採取文字問題聲明的方式，把問題描述中的名詞和動詞看作類別與關聯的直接類似物。雖然它是開始分析的一個好方法，但是總是有些不滿足。這時你可能要搬動抽象的層次，在這種場合中可能運用到metamodels, generic classes, and reification用以搬動抽象的層次，BOM的應用是一個相當好的說明。

7.13 第一次的修訂：增加Transaction的見解

(First Revision: Introduce the Notion of a

Transaction )

用一新的物件Transaction更抽象化取代purchase 與sale，因為purchase 與sale只在交易方向與數量的不同，其他所具有的屬性卻是非常接近，同時利用物件導向的多型的觀念與兩個關聯，取代原本只有asset 在portfolio 內的變化，變成asset 在portfolio 內與portfolio 與portfolio間的變化，使架構更接近實務。並加入一個具體化的導出關聯(/Asset Portfolio)，說明asset 是portfolio具體化的關係。

下圖顯示類別修訂增加Transaction後的投資組合管理類別圖

第二次的修訂：分析存在的構型與精練Transaction (Second Iteration: Analyze Existing Forms and Refine Transaction)

進一步的分析物件模式我們發現還有錯誤，因為有些bond是單獨還本金的而且分為許多期，相同在更深入討論財務說明與實際情形還有許多要修正的地方，這裡我們在修改bondasset與stockasset的date qualifier 以transaction 與asset 間的assetReferenced 關聯取代之，並將transaction擴充為處理配股配息還本買賣的處理類別，並強化了所有的角色名稱，最後建立下列的最終的物件模型。

7.14組成物件模式

下圖顯示組成物件模式後的完成版投資組合管理類別圖

第8章物件導向資料庫模式系統設計

在此將也只討論與資料模式相關的部分，並不討論與操作模式或資料儲存相關架構選擇的問題。

設計的過程是延續分析的架構，將其架構做適當的調整，以配合以後的資料庫實作需要，相關的部分包含下列數個步驟：1. 考慮時間性資料，2. 考慮資料的第二面向，而每一步驟各包含數項討論的空間，將在以下分別說明。

8.1考慮時間的資料(Dealing with Temporal Data)

在字面上是與時間的資料交往，也就是要考慮與時間發生與順序有關的資訊，在分析階段我們可能將其視為導出屬性並不去深入討論，在設計我們就必須加以考慮，在OODB可能可以用版本(Versions)的方法加以解決，在其他型態如RDB則否，因為是模式分析，所以我們採取應用層面較廣的記錄屬性內容發生的時間的方法。

就分析所討論投資組合管理的架構中有幾項與時間有關的資料條列如下，

• The time when a transaction occurs

• The time when the user records a transaction

• The time of valuation of an asset

• The time a portfolio value is computed

• The time interval (starting time and ending time) for computing ROI

在分析過程中我們提出了前面兩項，後三項在模式中將利用時間作qualifiers 加以處理，其圖示說明將與下一步驟合併提出。

8.2考慮資料的第二面向(Dealing with Secondary

Aspects of Data)

資料的第二面向的意義是相同的資料內容用不同的衡量單位顯現其表現值，其中包含類別與屬性值，在類別可用的方法有1.使用多重繼承，2.複製類別，3增加屬性，在屬性值可用的方法有1.建立常規，2. 增加屬性，3.擴充領域定義，其各有適用的範圍。

在投資組合管理的架構中只有屬性值的問題，我們採用增加屬性的方法，處理錢(money)的問題，因為錢有各種幣值單位如美元、馬克、日圓、新台幣等，在有需要處理的類別與Cash類別建立一關聯，而在其間加入currency 的角色處理錢的測量單位問題，就可以應用到整個模式中。

下圖顯示在設計階段加入1.考慮時間的資料與2.考慮資料的第二面向後的校訂版投資組合管理類別圖

參考資料

1.http://www.rational.com/uml/  UML網路資源中心

2.”UML DISTILLED SECOND EDITION”中譯本

　“UML精華第二版標準物件模型語言概述”, Martin Fowler, Kendall Scott著,

　趙光正,薛琇文譯; 碁峰資訊有限公司

3.http://www.sos747.com/ASP/Feature/sosf-2.htm UML-視化塑模標準語言

4.“Object-Orinted Modeling and Design for Database Applications”, Michael Blaha,

William Premerlani; Prentice Hall

5.附件：OOAD_ERDiagram_TO_ClassDiagram.pdf