UML概念模型


UML概念模型主要包括基本構造塊、運用於構造塊的通用機制和用於組織UML視圖的架構

構造塊

構造塊是UML的基本建模元素,是UML中用於表達的語言元素,是來自現實世界中概念的抽象描述方法。包括事物、關系和圖。事物是對模型中關鍵元素的抽象體現;關系是事物和事物之間的聯系方式;圖是相關事物及其關系的聚合表現。

事物

事物包含構建事物,行為事物,分組事物,注釋事物

  1. 構建事物:UML模型的靜態部分,描述概念或者物理元素;包含以下

    • 類class:具有相同屬性、相同操作、相同關系、相同語義的一組對象描述
    • 接口interface:描述元素的外部可見行為,即服務集合的定義說明
    • 協作collaboration:多個元素共同工作、相互配合達到某個目的的交互動作
    • 用例use case:一組動作序列的集合,動作序列特定的參與者觸發或執行,結果可以反饋給參與者或者作為參數
    • 組件component:系統中封裝好的模塊化部件(類似java中jar包),僅將外部接口暴露出來,內部實現隱藏
    • 節點node:運行時存在的物理元素
  2. 行為事物:UML模型圖的動態部分,描述靜態元素之間產生的空間和時間的行為動作,類似於句子中的動詞

    • 交互:實現某功能的一組構建事物(元素)之間消息的集合,涉及消息,動作序列,連接
    • 狀態機:描述事物或交互在生命周期內相應事件所經歷的狀態序列
    • 活動:描述一個操作執行時的過程信息
  3. 分組事物: UML模型圖的組織部分,描述事物的組織結構包:把元素組織成組的機制

  4. 注釋事物: UML模型的解釋部分,用來對模型中的元素進行說明,解釋

關系

關系是事物之間具體化的語義連接,在UML中有四種基本關系

  1. 關聯 association
    • 描述不同類元的實例之間的連接。一種對象和另一種對象存在聯系,即“從一個對象可以訪問到另一個對象”,例如:人和身份證
  2. 依賴dependency
    • 描述一對模型元素之間的內在聯系(語義關系[1])。一個元素的某些特性隨着另一個獨立的元素的特性變化而改變,例如:人和自行車
  3. 泛化generalization
    • 類似於面向對象方法中的繼承關系,即一個具體類對另一個具體類的繼承,例如:寶馬類泛化了小汽車類
  4. 實現realization
    • 一種類與接口的關系,表示類是接口所有特征和行為的實現

根據UML圖的基本功能和作用,包含以下

結構圖:捕獲事物與事物的之間的靜態關系,用來描述系統的靜態結構模型

行為圖:捕獲事物交互過程如何產生系統行為,用來描述系統的動態行為模型

UML2規范包含了:類圖、對象圖、組合結構圖、組件圖、部署圖、包圖、外廓圖、用例圖、活動圖、狀態機圖、順序圖、通信圖、時序圖、交互概覽圖(后期筆記會進行整理)

UML通用機制

通用機制描述了面向對象建模目的4種策略,並在UML不同的語境下被反復使用,使得UML更簡單並易於使用

  1. 規格說明specifications

    • 構造塊的語法和語義的描述
  2. 修飾adornments

    • 對規格說明的文字或圖形的表示
  3. 通用划分common divisions

    • 類型-實例:通用描述與某個特定的元素的對應,例如:類和對象
    • 接口-實現:接口和實現它的類或組件、用例與實現它的協作、操作與實現它的方法等
  4. UML擴展機制extensibility mechanisms

    • 本身的描述能力可能不夠,需要擴充某些細節上描述。在不改變整體語言風格的基礎上定義一些通用性的擴展

    • 構造型

      構造型擴展了UML的詞匯,可以用來創造新的構造塊,這個新構造塊是從現有的構造塊派生的,但是針對特定的問題。 在圖形上,把構造型表示成用雙尖括號(<<>>)括起來的名字,放在其他元素名之上。

    • 標記值

      標記值擴展了構造型的特性,可以用來創建構造型規約的新信息。 衍型與標記值

      如上圖所示,authored是基於類擴展而來的構造型,用來表述事件隊列;針對authored構造型有一個注釋,注釋中的version和author並不是UML的基本概念,而是新擴展的標記值,用來說明構造型的特殊信息。

    • 約束

      約束是對UML規則的擴展,或者是對已有規則的修改,使用{}中的文本串表示。

“4+1”架構

采用用例驅動,在軟件生命周期的各個階段對軟件進行建模,從不同視角對系統進行解讀,從而形成統一軟件過程架構描述

  • 組成:邏輯視圖(類圖)、開發視圖(組件圖)、進程視圖(順序圖、協作圖、狀態機圖)、物理進程(部署圖)和場景視圖(用例圖)

  • 邏輯視圖:用於描述系統的功能需求,即系統給用戶提供哪些服務;以及描述系統軟件功能拆解后的組件關系、組件約束和邊界,反映系統整體組成與系統如何構建的過程。在UML中由類圖來表示

  • 開發視圖:開發視圖關注軟件開發環境下實際模塊的組織,反映系統開發實施過程。

    一個設計良好的開發視圖,應該能夠滿足以下要求:

    通過邏輯架構元素,能夠找到它所有代碼和所有的二進制交付件 每一個代碼源文件,都能夠找到它所屬的邏輯架構元素 每一個二進制交付件,都能夠找到它集成了哪些邏輯架構元素

  • 進程視圖:用於描述系統軟件組件之間的通信時序,數據的輸入輸出。在UML中通常由時序圖和流程圖表示

  • 物理視圖:開發出的軟件系統,最終是要運行在物理或軟件環境上。物理環境可能是服務器、PC機、移動終端等物理設備;軟件環境可以是虛擬機、容器、進程或線程。部署視圖就是對這個部署信息進行描述。在UML中通常由部署圖表示

  • 場景視圖:場景視圖,即4+1中的1,4+1中的4個視圖都是圍繞着場景視圖為核心的。它用於描述系統的參與者與功能用例間的關系,反映系統的最終需求和交互設計

  • 軟件架構設計流程:場景視圖(架構師與客戶)=〉邏輯視圖(架構師與開發人員)=〉進程視圖、開發視圖、物理視圖(開發小組)


  1. 語義關系,指語言單位之間在意義上的關系,主要表現為縱的方向上的聚合關系和橫的方向上的組合關系,以及邏輯關系。語義的聚合關系指根據語言單位之間在意義上的對比而確立的可替代的垂直關系,包括同義關系、反義關系、類義關系、異義關系等;語義的組合關系指語言單位在語言體系中和語流中相互搭配構成的關系,包括施受關系、領屬關系、限定關系、並列關系、支配關系、判斷關系、說明補充關系等;語義的聚合關系和組合關系都是建立在邏輯關系的基礎上的。語義的邏輯關系還有預設關系、蘊涵關系等。 ↩︎


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM