Visual Studio 2010 塑模化應用程式設計(二)[UML簡介]

UML是Unified Modeling Language統一塑模語言,它是用來描述物件導向的分析與設計(OOA&D)的一種方法,而使用OOA & OOD並不表示就一定是使用UML,OO的的設計觀念早在1960年代就出現了,當時是由Ole Jone Dahl所設計的Simula67語言引進這樣的思維的,類別的概念也是在Simula67帶進來的。後期1970~1980年代的為較有名的SmallTalk

 

UML是Unified Modeling Language統一塑模語言,它是用來描述物件導向的分析與設計(OOA&D)的一種方法,而使用OOA & OOD並不表示就一定是使用UML,OO的的設計觀念早在1960年代就出現了,當時是由Ole Jone Dahl所設計的Simula67語言引進這樣的思維的,類別的概念也是在Simula67帶進來的。後期1970~1980年代的為較有名的SmallTalk,且SmallTalk的建立者Alan Kay幾乎以Simula67為基礎的概念發展了SmallTalk,在SmallTalk中已經有物件、繼承、子類別等概念了。

到了1990年代才出現一些較著名的物件導向分析法,其中有Grady Booch的Booch方法,Ivar Jacobson的物件導向軟體工程(Object Oriented Software Engineering) OOSE、還有James Rumbaugh的物件塑模技巧(Object ModelingTechnique) OMT。

在1994年James Rumbaugh加入了Grady Booch的Rational公司,並在1995年10月發表了UM (Unified Method),後來Ivar Jacobson也加入Rational公司並在1996年6月三個人共同發表了UML 0.9版,並正式改名稱為UML (統一塑模語言)。後來到了1997年的1月,在Rational公司的許多人一起努力之下才定義出一個完整的、功能較為強大、適合一般情況使用的UML 1.0版。並給務建管理組織 OMG (Object Management Group)審查,當中也發現一些問題並經過了近9個月的審查與改進,同年又再以UML 1.1版通過OMG的審查,成為物件塑模的標準,並且正式運用在軟體開發之上。

也因此要追朔UML發展的歷史可以追朔到這三位UML大師,Grady Booch、Ivar JacobsonJames Rumbaugh,他們也是UML軟體及描述標準的開發之父,

後來在2001年則推出了最新的UML統一模型語言1.4版,於2004年推出了2.0版。詳細的UML發展史可參考底下簡圖:

 

image

圖片取自http://w3.cyu.edu.tw/kwsheng

從圖片中可以知道UML出現在市場上可追朔到1995年。OMG組織正式採用的日期為1997年,而筆者真的開始接觸UML的時候已經是2001年的1.4版,不過當時許多的UML Case Tool還是只支援到1.3 版。

UML各版本之間的差異:

UML1.3與UML1.2版的差異主要是改善Use Case Diagram與Activity Diagramu一些表示法,如在Use Case中UML 1.2之前Actor 與 Use Case 的關係只有一種 Communicates (溝通/聯繫)關係,而在 UML 1.3 版為了與其他 UML 圖型有較為一致性的關係表示法,因此改為 Association(結合關係)。而且在Actor 之間也僅有一種關係,也就是所謂的 Generalization(一般化關係),這也就是物件導向裡所謂的繼承的關係。然後在 Use Case(活動)之間在 UML 1.1 版時,也只有兩種關係,分別是 uses(使用關係)及 extends(延伸關係),到了 UML 1.3 版,則拆解成三種關係,分別為 include(包含關係),extend(延伸關係)以及 generalization(一般化關係)。後來UML 從 1.4 版到 1.5 版主要的改變是在 UML 中新加入動作語意 action semantic),它是讓 UML 具有一些『程式語言能力』的一個必要的一個步驟,也就是所謂的MDA (Model Driven Architecture)模型驅動開發架構。這讓大家不用等到完整的 UML 2.0 版出現就可以先將 UML當成程式語言來使用。

在後來的UML 2.0其實在底層的塑模有很多的改變與擴充,比如說如狀態機擴充(state machine extension)、互動圖中的閘道(gateway)概念、與類別圖中的強力型態(power type)等等… 太細節的部分就不再深入了,一般來說最最主要的就是新增了一些圖形,如套件圖(package diagram),互動概圖(interaction overview diagram)、時序圖(timing diagram)與合成結構圖(composite structure diagram)等,且在UML 2.0終將原先的合作圖(collaboration diagram)改名成通訊圖(communication diagram)。

目前UML最新版本為2.2版,在2.2版中共有14種圖形:

  1. 使用案例圖 (Use Case Diagram)
  2. 類別圖 (Class Diagram)
  3. 物件圖 (Object Diagram)
  4. 循序圖 (Sequence Diagram)
  5. 溝通圖 (Communication Diagram)
  6. 狀態圖 (State Diagrma)
  7. 活動圖 (Activity Diagram)
  8. 元件圖 (Component Diagram)
  9. 部署圖 (Deployment Diagram)
  10. 套件圖 (Package Diagram)
  11. 時序圖 (Timing Diagram)
  12. 互動概觀圖 (Interaction Overview Diagram)
  13. 複合結構圖 (Composite Structure Diagram)
  14. 輪廓圖 (Profile Diagram)

 

各圖形的用途及簡要說明如下:

使用案例圖 (Use Case Diagram):

Use Case 是Jacobson於1994年發明了使用案例圖的方法。使用者案例是使用者觀點來看模形化的軟體設計,是由使用者觀點描述系統的行為者與系統間之互動行為與關係。從內部觀點來看,使用個案可描述系統做什麼 (What)。從外部觀點來看,可描述行為者與系統怎麼互動 (How) 。使用者案例可以幫助辨別系統服務。使用者案例可以被進一步被解構成小的使用者案例。

類別圖 (Class Diagram):

用以表示系統存在之物件型態 (或稱類別) 及各物件型態間之靜態的資料結構或邏輯的關係,通常也表達類別之屬性操作(Operation或稱Method)與類別間連結之限制/連結關係(Association),要包括多重性(如:一對多、多對一、多對多..等關係)。

物件圖 (Object Diagram):

通常用以描述系統於某一時點之靜態資料結構,該圖由一群相關物件及其連結所組成。

循序圖 (Sequence Diagram):

這個圖形相信大家都不陌生,常使用到的一種圖形,描述系統個物件/類別運作時物件間的互動行為,著重以時間之先後順序為主軸,表達物件間的訊息傳遞與處理程序。

溝通圖 (Communication Diagram):

此為UML 1.x 版之合作圖 (Collaboration Diagram),在UML 2.0版的時候改名為溝通圖。它主要描述系統運作時物件間的互動行為,但比較著重表達相關物件間之連結結構的關係,並可以同時展現物件間之訊息傳遞活動。

狀態圖 (State Diagrma):

用以表達物件在生命週期中的狀態變化。

活動圖 (Activity Diagram):

通常用來(加強/表達)使用案例中不足以表達的部分,如:一系列事件的流程,包含工作流程和所需之作業活動,或執行某一作業之行為中之活動、轉換與條件等。一個活動可表示一個工作流程的步驟或一個運算執行的動作。

元件圖 (Component Diagram):

通常就是描述系統之實體模組,是系統中可被替換的部分,如.NET平台可能就是Assembly、DLL等之間的關係。

部署圖 (Deployment Diagram):

用於說明系統在實際應用時各軟硬體 ,如:處理器、處理元件,元件之配置與關聯,或甚至是硬體或網路基礎建設之拓撲等。

套件圖 (Package Diagram):

通常用以表達系統中Package與其他群組元素的組成方式,或描述Package與Package之間的相依性。

時序圖 (Timing Diagram):

所謂的時序圖著重物件間訊息傳遞的時間關係,並顯示詳細的時間資訊,常用於即時 (Real-time) 或嵌入式系統的塑模上。時序圖藉由狀態與時間軸、時間尺規等符號來表達物件在不同時間點上的狀態改變。

互動概觀圖 (Interaction Overview Diagram):

而所謂的UML互動概觀圖其實是結合活動圖與互動圖來表達整體的控制流程,以活動圖為主幹,說明主要活動與控制流程 (Control Flow),而細部活動則以互動圖 (包含循序圖、時序圖、溝通圖等) 來表示。

複合結構圖 (Composite Structure Diagram):

用以表達某類別或元件於執行時期可能會產生之實例 (Instance) 與連結 (Link),描述各物件如何於類別中協同合作,或各物件如何達成目標。可用於表達類別之內部結構 、使用類別之方式和物件間之合作關係三種情形。

輪廓圖 (Profile Diagram) :

又有人稱作剖面圖,它能針對現存所謂的[基礎模型或稱超模型] (Meta-model) 中之基礎類別或稱超類別 (Meta-class) 來進行擴充,使其適用於不同用途,如此便可隨不同平台 (如JAVA、.NET等) 或領域 ,如:即時系統塑模或企業流程領域 (Business Process) 塑模來調整UML之超模型。

且Grady Booch於1999年時對UML在設計各種不同的圖形時提出五種不同的面向,因為一般而言在實際設計系統的塑模時因為觀點的不同,因此會有不同的面向,共有哪五個面向呢?使用一個經典的圖表示:

image

個觀點說明如下:

使用個案觀點 (Use Case View)

由描述系統行為的使用個案組成,此系統行為以使用者、分析師、測試者的觀點描述系統做什麼及操作情境,不涉及系統的軟硬體架構。


設計觀點 (Design View)

所謂的設計觀點是描述系統之類別、介面、彼此合作的情形及之間的互動方式。此觀點主要支援系統之功能面需求,意即著重表達系統應提供予使用者之服務。


流程觀點 (Process View)

此觀點較著重表達系統內部的處理程序或執行緒,比如說明系統績效 (Performance)、產出 (Throughput) 的部分與可擴充性 (Scalability) 。


實施觀點 (Implementation View)

因為通常系統在實際進行開發時可能會套用某些設計樣式,或是使用某些元件,這個面向主要在於表達系統的結構配置管理,描述系統主要由哪些元件與檔案組成的 (如實際的DLL檔案、在.NET 可能稱作Assembly),元件與檔案如何以不同方式組合可實際執行之系統。


部署觀點 (Deployment View)

此觀點在於當系統實際運作時各子系統或元件配置的一個狀況,同一個系統有可能在同機器也可能跨機器間佈署,這時也可能牽涉到硬體部分,它表達系統執行時,硬體拓撲上或說各節點 (Nodes) 上的配置,並描述系統分析與設計的產出,及說明系統如何實作。


 

簽名:

學習是一趟奇妙的旅程

這當中,有辛苦、有心酸、也有成果。有時也會有瓶頸。要能夠繼續勇往直前就必須保有一顆最熱誠的心。

軟體開發之路(FB 社團)https://www.facebook.com/groups/361804473860062/

Gelis 程式設計訓練營(粉絲團)https://www.facebook.com/gelis.dev.learning/


 

如果文章對您有用,幫我點一下讚,或是點一下『我要推薦,這會讓我更有動力的為各位讀者撰寫下一篇文章。

非常謝謝各位的支持與愛護,小弟在此位各位說聲謝謝!!! ^_^