軟體工程 -物件導向程式設計與UML系統分析實作

Presentation on theme: "軟體工程 -物件導向程式設計與UML系統分析實作"— Presentation transcript:

1 軟體工程 -物件導向程式設計與UML系統分析實作

2 OutLine 軟體開發、塑模與溝通 UML概述 UML事物、關係與圖形 UML軟體開發方式 UML圖形繪製 結論

3 軟體開發、塑模與溝通 在軟體發展的過程中，因為參與開發過程的的成員眾多，所以，有效的溝通非常重要。 舉例來說：
客戶與承包商需要反覆溝通，以取得用戶需求 廠商與廠商之間需要有效溝通，以達成相互合作 而開發團隊內部更必須確保溝通，以保證發展方向正確等等 因此軟體開發能夠順利進行，有效且良好的溝通，是不可或缺的要素。

4 軟體開發、塑模與溝通 但軟體發展與其他的文明建設不同，軟體開發通常不像建築物，具有明確的外觀形貌，也沒有所謂建築藍圖或建築模型以供參考。
在大部分狀況下，軟體發展的基本參考，通常只是用戶需求裡的條列式文句。而相同的文句，每個開發人員可能會做出不同的解釋，更因沒有實體或模型可供參考的狀況下，開發軟體很容易造成『瞎子摸象』的後果，不但需要花更多的時間進行溝通，同時也無法保證軟體產出的品質。

5 軟體開發、塑模與溝通 因此，依循其他傳統的文明建設發展軌跡，諸如建築藍圖或結構模型等成功經驗，軟體工程也朝向此一『建立可討論的模型』目標前進。 有可見的藍圖，總比以文字表示的條文容易理解。更進一步，如果有可見的模型，不僅對整體架構有更明確的概念，同時也可確保開發團隊中的每個成員，都有相同且明確的目標，因此可以事半功倍，避免無謂虛耗的困擾。 因此，在軟體工程中，塑模的重要性不言可喻。

6 塑模的原則 建立模型的方式與種類，會因為問題分析方式與解決方案的不同而有所影響。 每一模型均可以透過不同的精細度表示 模型應與實際面銜接
一套完整的系統不應由單一模型描述、應由數個單一且獨立的較小模型來分析描述

7 塑模的方式 在軟體工程領域中，最常見的有兩種塑模方式，分別是： 透過演算法塑模 物件導向塑模

8 透過演算法塑模 傳統的軟體開發的觀點，是使用演算法的方式來作分析。在這種方式裡，軟體是由一連串的程序或函式所構建起來的。在這種開發模式下，設計師只需專注在不斷的將大函式切成小函式。 這樣的設計方式行之有年，但很容易造成系統改變彈性很差，尤其是碰上需求變更或是系統成長時，以演算法塑造的模型，就變的難以維護與修改，同時也難以維護。

9 物件導向塑模 近年的軟體開發方式，主要以物件導向觀念進行開發
在此一開發觀念下，軟體由物件或類別構成，而物件便是一項事物，是由問題或解決方案所萃取出來的詞彙。 類別則是對共通的某種物件所做的歸類。而每一個物件都有獨一無二的識別ID、狀態、資料與行為。

10 物件導向塑模 Cont. 而以物件導向概念開發軟體的最大優勢，在於人類本來就是活在物件的世界中
我們身旁周遭無一不是物件。即使如最平凡的桌椅刀叉，也具有物件的特質。以物件的觀點來切割軟體，對人類而言是如同直覺一般，再自然不過的事情。

11 物件導向塑模 Cont. 以經驗法則來看，物件導向軟體開發方式已經是軟體開發的主流，原因在於這樣的開發方式證明了可以適應各式各樣的問題領域、大小不同的各式專案。 越來越多的程式語言、作業系統、開發工具都強調物件導向的特色。試著以人類一般看事物的方式來開發軟體，就是物件導向開發方式所要達到的目標。

12 UML Introduction UML（Unified Modeling Language） 是一套專門用於塑模的標準語言

13 UML Introduction UML可以用來對各式各樣的系統塑模，從大型的B2B企業系統或分散式網路運算系統、甚至小至嵌入式系統，都可以用UML來塑模。 而在UML裡，每一項符號都有其清楚的定義，因此，所有開發人員可以透過相同的符號認知，透過UML來正確解讀的模型，由此達到塑模所要的效果。

14 UML Introduction 要瞭解UML，就必須瞭解UML的三個基本構成部分
將這些要素組合在一起的『法則 』 與UML的『一般機制』 在瞭解這些機制後，便能得心應手的使用UML進行塑模的工作。

15 UML的組成要素 UML的組成要素有以下三種
事物（Things） 關係（Relationships） 圖形（Diagrams） 事物（Things）是實體抽象化的最終結果，是模型中的基本成員，關係（Relationships）是將事物連結在一起的方式，圖形（Diagrams）則是事物集合的分類。

16 UML的事物 在UML裡的事物有以下幾種： 結構事物（Structural Things） 行為事物（Behavioral Things）
分組事物（Grouping Things） 附註事物（Annotational Things）

17 基本結構事物 絕大多數模型中的靜態部分，用以呈現概念或實體的表現元素，是一般軟體塑模中，最常見的元素，共有以下七種： 類別（Class）
介面（Interface） 合作（Collaboration） 使用案例（User Case） 主動類別（Active Classes） 元件（Components） 節點（Nodes）

18 類別(Class) 類別（Class）是物件導向架構中，最基礎的事物。類別是一組共享某些相同屬性（Attributes）、操作（Operations）、關係（Relationships）和語意（Semantics）的物件描述。一個類別可以實作出一個或多個介面。在圖形上通常以長方形表示之，在長方形裡，需包含該類別的名稱、屬性、操作等。

19 介面(Interface) 介面（Interface）是操作的集合，這些操作可以用來定義出某一類別或元件的服務，透過介面可以描述出元件外界可視的行為，介面通常必須依附在實現（Realizes）這一個介面的類別或元件上。在表示上，介面可以以一個圓圈表示，或以與類別相連的方塊表示。

20 合作（Collaboration） 合作（Collaboration）用來定義互動關係，也就是用來定義角色（Roles）與其他共同運作的元素，相互之間的合作行為。元件間的合作行為的複雜度與可能性，應該遠大於原先元件的行為總和。合作可以有不同的結構、行為、及維度。一個物件也可以參與多個不同的合作。以圖形表示，可以表現成一個虛線橢圓，並在橢圓內標註合作的名稱。

21 使用案例（User Case） 使用案例（User Case）是系統對某一位動作者（Actor）所做的一連串動作之描述，這些動作可以產生某些可觀察到的結果。透過使用案例，可以建構出模型中的行為事物，使用案例是由合作來實現的。以圖形表示，可以表現成一個實線橢圓，並在橢圓內標註使用案例的名稱。

22 主動類別（Active Classes） 主動類別（Active Classes）屬於類別的一種，但此類物件均具有一個到多個屬於自己的行程或執行緒，因此可以啟動某些控制活動。主動類別與其他類別的不同之處，在於主動類別裡的物件所代表的元素行為可以透過同步的方式，與其他元素溝通。以圖形表示，與類別相同，可以表現成一個實線長方形，但外框通常以粗線表示，以方便識別。

23 元件（Components） 元件（Components）是模型內的實體，代表一組介面的實現，而在實際的系統中，可以看到大量的實體元件，例如COM+或是 Java Beans等元件。同時，元件也可以是開發過程的產出，例如：程式碼檔案，就是元件的一種。元件基本上表示各種邏輯元素，如類別、介面或合作的實體（Phisical Packaging）。以圖形表示，可以表現成一個實線長方形外接兩個標籤，長方形內標註元件的名稱。

24 節點（Nodes） 節點（Nodes）是存在於執行時期的實體元素，通常表示運算資源，例如記憶體或是CPU等等實體資源，通常，元件會存在在節點之中。以圖形表示，節點通常表示為一個立方體，並在立方體內標註節點名稱。

25 行為事物 行為事物指的是UML模型中的動態部分，代表語句裡的『動詞』，表示模型裡隨著時空不斷變化的部分，行為事物主要有兩種：
互動（Interaction） 狀態機（State Machine）

26 互動（Interaction） 互動（Interaction），互動是由一組物件之間互相交換的訊息所組成，這些訊息裡，包含了要達成某種目的所應該有的資訊本文（Context），因此，互動必定與其他的元素有關。 互動可能包含有訊息、動作序列（Action Sequences）和連線（Links）。以圖形表示的話，訊息會以具有方向箭頭的直線表示之，並在直線上標註互動名稱。

27 狀態機(State Machine) 在UML中，單一類的行為或類別合作的行為，都可以用狀態機來定義，狀態機裡包含了很多其他元素，例如狀態（State）、轉換（Transitions）、事件（Events）以及活動（Activities），以圖形表示，則表示為一個圓角長方形，內部註明該狀態的名稱

28 分組事物：類別庫 分組事物可以用來切割模型，使其更為清楚，目前UML裡僅有一種分組事物，就是類別庫（Packages），類別庫是一種一般用途的分組機制，可以將元素分門別類，與元件（只存在於執行時期）不同，類別庫僅僅是一種概念，亦即類別庫僅存在於開發時期，提供開發者分類之用，以圖形表示，類別庫可表示成一個附有標籤的資料夾，並附記上類別庫的名稱。

29 附註事物：註解（Note） 附註事物是UML中用來作解釋、標註的部分，在UML中目前只有一種附註事物，即註解（Note），註解是一種簡單的符號，可以附加到某一個元素或元素的集合上，作為限制或說明之用，以圖形表示，則表示為折角的長方形，內附記說明文字。

30 UML中的關係 在UML中，有四種關係： 相依關係（Dependency） 結合關係（Association）
一般化關係（Generationalization） 實現化關係（Realization）

31 相依關係（Dependency） 相依關係（Dependency）表示兩個相連的事物有相關，當其中一個事物變更時，會影響到另外一個事物，以圖形表示，則以虛線表示。這一條虛線可以有方向性，也可以有標籤。

32 結合關係（Association） 結合關係（Association）是一種特殊的關係，代表某一個整體及其某一部份的結構關係，以圖形表示的話，可以表現成一條實線，這一條實線可以有方向性，也可以有標籤。

33 一般化關係（Generationalization）
一般化關係表示物件與物件的特殊/一般化關係，特殊化元素（子元素）可以被一般化元素（父元素）所取代，在這種關係中，子元素可以共用父元素的行為。以圖形表示的話，一般化關係是一條具有空心箭頭的實線，由子元素指向父元素。

34 實現化關係（Realization） 實現化關係是指限定元（Classifiers）之間的關係，其中一個限定元根據此一關係，訂定出契約（Contract），另一個限定元必須保證能達到此一契約，此即實現化關係。

35 UML的圖形 在塑模的過程中，我們會以不同的角度來看待系統，並以視覺化的方式繪圖表現，因此，圖形便是系統的投射（Projection）。在大多數的系統裡圖形以簡化的觀點表現出系統的構成元素，因此同一元素可能出現在數個不同的圖形中。理論上，圖形可以出現任意組合的事物與關係，在UML中，共包括以下九種圖形： 類別圖（Class Diagram） 物件圖（Object Diagram） 使用案例圖（Use case Diagram） 順序圖（Sequence Diagram） 合作圖（Collaboration Diagram） 狀態圖（Statechart Diagram） 活動圖（Activity Diagram） 元件圖（Component Diagram） 部署圖（Deployment Diagram）

36 使用案例圖（Use case Diagram）
在運用Use Case Diagram時的重要課題，是要認清使用者目標（use goal）與系統互動（system interaction）兩者之間的差異。圖形內中主要描述行為者（Actor）與使用個案（Use Case）的關係。 Use Case 是使用者與電腦系統兩者之間的一個典型互動情形。 Use Case 是用以捕捉使用者看得見的一些功能。Use Case 可大可小。 Use Case 達成使用者一個獨立的目標。

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

38 使用案例圖 Example Request Course Roster Professor Student
Maintain Schedule Billing System Maintain Curriculum Registrar

39 順序圖（Sequence Diagram）
在UML裡面，Scenario指的是一個use case中的某一個單一實行路徑，也就是在一個use case中某幾個特殊狀況，結合在一起的情形。而用來描述Scenario的工具即是Sequence Diagram。 在 Sequence Diagram中，物件是用一個方格表示，而在他的下方會有一條垂直的虛線，這條虛線就是物件的生命線（Life line）。他代表者一個物件在互動過程中的生命。 每一個訊息（message）是用連接著兩個物件生命線間的一個帶箭頭的直線來表示。這些訊息在圖中的上下順序，就是他們之間發生的順序。

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

41 順序圖 Example : Student registration form registration manager math 101
section 1 1: fill in info 2: submit 3: add course(joe, math 01) 4: are you open? 5: are you open? 6: add (joe) 7: add (joe)

42 合作圖（Collaboration Diagram）
在Collaboration Diagram中，一個物件是用一個小圖像來表示。就跟Sequence Diagram一樣，帶箭頭的線，是用來表示一個use case的訊息，但是在這裡，訊息的順序是用它的號碼來表示。 在Collaboration Diagram中，還可以表現出物件間的連結關係、包裹中所包含的物件，還有其它的資訊，但是，比較不易看出他們之間的順序關係。

43 合作圖Example course form : 1: set course info CourseForm 2: process
: Registrar course form : CourseForm theManager : CurriculumManager aCourse : Course 1: set course info 2: process 3: add course 4: new course

44 類別圖（Class Diagram） Class diagram 是用來描述系統中物件的類型，以及類型間的各種靜態關係。
靜態的關係主要包含兩大類： 結合關係（association） 子類型關係（subtype） Class diagram 技術已經成為物件導向方法最中心的部分。Class diagram 還會把類別的屬性（attribute）、操作方法（operation）、以及物件間相連接所應遵守的限制都顯示出來。

45 類別圖（Class Diagram） 而何時要使用 Class diagram呢？
在分析階段，畫概念層次的模型時。 在製作軟體時，把注意力集中在規格層次的模型。 要顯示特殊的實作技術時，才去畫實作層次的模型。 其使用時機在於在分析完一個或多個次序圖後，你可以整理出從各個情節中找出了哪些物件，進一步去發掘物件彼此間是否存在有共通性（如：相同的屬性和方法），然後定義出用來產生這些物件的類別，並根據次序圖的訊息資訊，定義出類別之間的關係，最後繪製出類別圖。

46 類別圖Example ScheduleAlgorithm RegistrationForm RegistrationManager
addStudent(Course, StudentInfo) Course name numberCredits open() addStudent(StudentInfo) Student name major Professor name tenureStatus CourseOffering location open() addStudent(StudentInfo)

47 狀態圖（Statechart Diagram）
對於系統行為的描述，State diagram可以把一個物件可以進入的所有可能狀態（state），以及這個物件在面對外部事件時所進行的狀態變化情形全都表現出來。 在大部分的OO技術中，一個 State diagram是用以表示一個物件生命期內的所有行為模式。 而其使用時機在於：若系統內的物件有狀態變遷(state transition)的情形，發展者就需要透過狀態圖的繪製，協助發展者分析物件內部的動態行為，即狀態轉換的過程。

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

49 狀態圖Example ScheduleAlgorithm RegistrationForm RegistrationManager
Course Student CourseOffering Professor addStudent(Course, StudentInfo) name numberCredits open() addStudent(StudentInfo) major location tenureStatus ScheduleAlgorithm

50 部署圖（Deployment Diagram）
系統發展過程最後要交付給使用者的是一個系統，Deployment Diagram可以把這個系統理的軟、硬體元件的實際關係表示出來。在Deployment Diagram上的node 代表著一種計算單元，在大部分的情形下，它是一個硬體。這個硬體可以是一個感應器或簡單的儀器，也可以是一部大型的電腦主機。 其使用時機在於：如果系統複雜到有多個Server和多個Client，系統元件可能分佈在不同的server上執行。而且在同一個Server上，不同的軟體程序同時執行不同的元件。未來系統真的上線時，就可按圖施工了。

51 部署圖 Example Registration Database Main Building Library Dorm

52 UML圖形小結 透過各式UML圖形的解說，我們可以瞭解到，對於軟體工程所需要的每個面向：從需求收集、物件導向分析／設計、架構設計（N-Tier, Internet/Intranet, 元件化架構）、甚至到系統上線的佈建圖，UML均定義了標準符號給發展者於系統視覺化、溝通和產生各式文件時使用。 但UML並不定義軟體發展程序，就好想蓋房子的藍圖採用同樣的一組符號，但蓋法可能各家不一樣。因此，不管你採用的是哪一套發展程序，均可採用UML當作其塑模符號，只是發展的步驟不一樣而已。

53 UML圖形小結 但UML各圖之間是有相關性的，如：使用案例會導出一至多個次序圖、次序圖的物件會導出類別圖的類別、次序圖的訊息會導出類別圖的方法、元件圖的元件包含類別圖的類別、…等等，而且這些推導過程是循環漸增式的(Iterative and Incremental)，彼此間環環相扣，相互確認，一直到整個模型同步穩定為止。

54 UML系統開發 UML進行系統的開發，通常分為以下幾個階段： System Analysis
OOA（Object-Oriented Analysis） OOD（Object-oriented Design） Implementation Integration and testing

55 系統發展模式 Inception Elaboration Construction Transition Iteration 1
Iteration Planning Rqmts Capture Analysis & Design Implementation Test Prepare Release “Mini-Waterfall”Process

56 系統開發程序(全圖)

57 系統開發程序(SA,OOA)

58 系統開發程序(OOD,Imp,Integ)

59 UML圖形繪製

60 UML案例圖繪製 Example 以訂房子系統的基本要求為例，以Poseidon繪製使用案例圖：
顧客可親自到飯店櫃臺或以電話方式辦理(預)訂房或者取消訂房 顧客到飯店櫃臺辦理住房手續(check-in)或退房手續(check-out)

61 繪製案例圖 Step by Step 建立一新 Use Case Diagram

62 繪製案例圖 Step by Step 建立一新Actor

63 繪製案例圖 Step by Step 依照需求，從Actor建立有向性關聯（Directed Association），Poseidon會自動在關聯的另一端建立Use Case，首先，我們先建立一個訂房的Use Case

64 繪製案例圖 Step by Step 建立關聯

65 繪製案例圖 Step by Step 依此類推，建立四個Use Case，分別為訂房、取消訂房、Check-in、Check-out。

66 結論 UML的出現，改變了舊有的軟體工程開發方式，這個問題，因為UML就是一個以圖形化的方式結合物件的觀念來分析系統。
在過去很多公司在開發MIS系統時，都是將系統分割成很制式化的幾個功能，如：新增、刪除、修改、查詢、 列印報表、…等，把系統切割成幾個子系統，整理出功能架構圖，然後訪談使用者取得欄位資料、查詢方式、和報表顯示欄位和資料排序方式，接著使用者畫面畫一畫，資料庫表格設計一下，頂多畫幾張 data flow diagram和E-R diagram，從經驗中可以得知，這並不是一個好的開發方式。尤其在面對新一代比過去更複雜的系統需求時，更顯無法因應。

67 結論 Cont. 如何回歸到處理複雜問題的正確的工作方法上，才是解決目前所面臨問題的上策。此正確的工作方法正是視覺化塑模和元件技術。透過視覺化塑模和元件技術，系統間的相關性可加以有效地控制，並且經過規劃、分析、和設計所繪製的系統藍圖，更有助於後續擴充及維護的工作。

68 結論 Cont. 因此，利用UML進行軟體塑模，使系統視覺化的好處在於：
有效縮短發展人員和使用者之間的距離，改善使用者需求收集和確認的工作。 讓使用者和發展者之間有一共通的語言。在分析階段，往上可與使用者做最好的溝通，往下直接給發展者繼續開發，各發展階段間無須任何的轉換，避免因層層轉換所帶來的錯誤和開發成本的提高。 做好分析設計工作，自動地產生系統藍圖和相關文件，大幅改善日後系統維護工作和降低維護成本。 可一步步推導出系統應該切割成那些元件以及元件間是如何互動的，作為元件發展的基礎。 因為UML能達到這些目標，並符合未來物件化軟體的開發標準，因此，UML將是未來系統分析、設計方面，不可阻擋的趨勢與潮流。