Thinking in UML(第一章)

lemon2018發表於2020-01-05

UML(Unified Modeling Language)即統一建模語言。是一種建模用的語言。

    UML定義了一些建立模型所需要的、表達某種特地含義的基本元素,這些元素稱為元模型,相當於語言中的基本詞彙,例如用例、類等。另外,UML還定義了這些元模型互相之間關係的規則,以及如何用這些元素和規則繪製圖形以建立模型來對映現實世界;這些規則和圖形稱為表示法或檢視(View),相當於語言中的語法。學習UML無非是掌握基本詞彙的含義,在掌握語法,通過語法將詞彙結合起來形成一篇有意義的文章。

從現實世界到業務模型
從理論上說,建立模型是指通過對客觀事物建立一種抽象的方法,用來表徵事物並獲得對事物本身的理解,再把這種理解概念化,並將這些邏輯概念組織起來,形成對所觀察的物件的內部結構和工作原理的便於理解的表達。

建立模型的關鍵就是弄明白有什麼人,什麼人做什麼事,什麼事產生什麼物,中間有什麼規則,再把人事物之間的關係定義出來,一個模型也就基本成型了。

那麼UML是不是提供了這樣的元素來為現實世界建立模型呢?是的。

  1. UML採用稱之為參與者(actor)的元模型作為資訊來源的提供者,參與者代表了現實世界的“人”。
  2. UML採用稱之為用例(use case)的一種元模型來表示驅動者的業務目標,也就是參與者想要做什麼並且獲得什麼。這個業務目標就是現實世界種的事。而這件事是怎麼做的,依據什麼規則,則通過稱之為業務場景(business scenario)和用例場景(use case scenar)的UML檢視來描繪的,這些場景便是現實世界種的“規則”。最後,UML通過稱之為業務物件模型(business object model)的檢視來說明在達成業務目標的過程中涉及到的事物,用邏輯概念來表示它們,並定義了它們之間的關係。業務物件模型則代表了現實世界中的“物”。

人、事、物、規則就是這樣被模型化的。

從業務模型到概念模型

UML通過稱之為概念化的過程來建立適合計算機理解和實現的模型,這個模型稱為分析模型(Analysis Model)。分析模型介於原始需求和計算機實現之間,是一種過度模型。分析模型向上對映了原始需求,計算機的可執行程式碼可以通過分析模型追溯到原始需求;同時分析模型向下為計算機的實現規定了一種高層次的抽象,這種抽象是一種指導也是一種約束,計算機實現過程非常容易遵循這種指導和約束來完成可執行程式碼的設計工作。

事實上分析模型在整個分析設計過程中承擔了很大的職責,起到了非常重要的作用。繪製分析模型最主要的元模型有:

  • 邊界類(boundary)Thinking in UML(第一章)

。裡外的事物互動需要有一個邊界。比如參與者與系統的互動,系統與系統之間的互動,模組與模組之間的互動等。邊界決定了外面能對裡面做什麼“事”。

  • 實體類(entity)Thinking in UML(第一章)

。原始需求中領域模型中的業務實體對映了現實世界中參與者完成業務目標時所涉及的事物,UML採用實體類來重新表達業務實體。

  • 控制類(control)Thinking in UML(第一章)

。邊界和實體都是靜態的,本身並不會動作。UML採用控制類來表述原始需求中的動態資訊,及業務或用例場景中的步驟和活動。邊界類和邊界類之間、實體類和實體類之間不能夠直接相互訪問,它們需要通過控制類來代理訪問要求。這樣就把動作和物體分開了。

分析類將業務模型概念化,由於所有的操作都通過邊界類來進行,能做什麼不能做什麼由邊界決定,所以邊界類實際上代表了原始需求中的“事”,實體類代表了現實世界中的“物”,控制類是“規則”,再加上參與者轉化而來的系統“使用者”,這樣一來,人、事、物、規則都有了,就可以依據業務模型中已經描繪出來的用例場景來組合這些元素,讓給它們表達特定的業務含義。

從概念模型到設計模型

在大多數情況下,實現類可以簡單地從分析類對映出來。在設計模型中,概念模型中的邊界類可以被轉化為操作介面或系統介面;控制類可以被轉化為計算程式或控制程式,例如工作流、演算法體等;實體類可以轉化為資料庫表、XML文件或者其他帶有持久化特徵的類。

本作品採用《CC 協議》,轉載必須註明作者和本文連結

相關文章