UML面向對象分析、建模與設計


一圖勝千言。

作為人類最古老的交流方式。

  • UML對於開發者來講,個人開發者也好,最重要的是讓你的系統是思考過的。
  • UML對於公司中的來講, 也是,讓系統的結構上有一個更直觀的記錄。而且交流起來確實比代碼方便。因為代碼以里有各種喜好,而UML沒有。只是簡單的關系

面向對象方法的概念

  1. 對象

    • 世界上萬事萬物都可以看作一個對象,這些是現實中的實體也被稱作客觀對象

    • 客觀對象可以抽象其某些屬性和方法來研究在某個問題或場景中的性質,這被稱為問題對象

    • 抽象出來的問題對象通過封裝等過程稱為計算機中的一個包含有數據和操作的集合體,這被稱為計算機對象

    • 三者之間的關系:

      客觀對象(抽象) -> 問題對象(封裝) < - > 計算機對象(模擬)。

    • 一個對象應該是具有狀態、行為和標識符的實體,並且對象之間往往可以通過通信互相交互。

    • 對象有以下4個特性:

      • 自治性

      • 封閉性

      • 通信性

      • 被動性

    • 類是擁有共同的結構、行為和語義的一組對象的抽象。類可以作為對象的一種描述機制,用來刻畫一組對象的公共屬性與公共行為,也可以用來作為程序的一個單位,用來形成程序中更大的模塊。

    • 類可以從以下4個角度來理解:

      • 類是面向對象程序中的構造單位。一個面向對象程序就是一組相關的類。

      • 類是面向對象程序設計語言的基本成分。在面向對象編程語言中,類內的成分是無法單獨構成程序的,程序應該至少包含一個完整的類。

      • 類是抽象數據類型的具體表現。類可以表示一種數據類型的抽象並給出了具體的數據結構表示與操作的實現方法。

      • 類刻畫了一組相似對象的共同特征。在面向對象程序的運行時,對象是根據類的定義而創建的,同類的對象具有相同的屬性與操作。對象又被稱為累的實例。

  2. 抽象

    • 抽象就是揭示一個事物區別於其他事物的本質特征,去除從某一個角落看起來不重要的細節行為。
    • 抽象具有動態與靜態的屬性。例如:文件的文件名屬於靜態,大小與內容為動態,常被抽象為對象的操作。
  3. 封裝

    • 封裝即對其客戶隱藏對象的屬性和實現細節,僅對外公開接口,並控制在程序中屬性的讀和修改的訪問級別。
    • 封裝強調兩個概念,即獨立和封閉。
      • 獨立是指對象是一個不可分割的整體,它集成了事物全部的屬性和操作,並且他的存在不依賴於外部事物。
      • 封閉是指與外部的事物通信時,對象要盡量的隱藏其內部的實現細節,它的內部信息對外界來說是隱蔽的,外界不能直接訪問對象的內部信息,而只能通過有限的接口與對象發生聯系。
    • 類是數據封裝的工具,而對象是封裝的實現。類的成員又分為共有成員、私有成員和保護成員,他們分別有不同的訪問控制機制。封裝是軟件模塊化思想的重要體現
  4. 泛化

    • 泛化是類元的一般描述和具體描述之間的關系,具體描述建立在一般描述的基礎之上,並對其進行了擴展。具體描述完全擁有一般描述的特性、成員和關系,並且包含補充的信息。
    • 實現泛化關系的機制為繼承(inheritance)。一個子類(subclass)繼承一個或多個父類(superclass),從而實現了不同的抽象層次,實現兩者之間的泛化關系。通過這種關系,子類可以共享其父類的結構和行為,從而容易復用已經存在的數據和代碼,並實現多態處理。
  5. 多態

    • 多態是在同一接口下表現多種行為的能力,是面向對象技術的根本特征。

面向對象方法的優點

在實際開發過程中,需求通常不穩定,在使用時,數據和功能最容易發生改變,而對象一般則是相對穩定的。

復用性也是面向對象方法帶來的優勢之一。面向對象方法通過封裝、繼承、聚合等手段,在不同層次上提供各種代碼復用,以此提高軟件的開發效率。

除此之外,面向對象方法還有改善軟件結構、增強擴展性、支持迭代式開發等優勢。

統一建模語言UML

統一建模語言UML是一種通用的可視化建模語言,可以用來描述、可視化、構造和文檔化軟件密集型系統的各種工作。

記錄了與被構建系統的有關的決策和理解,可用於對系統的理解、設計、瀏覽、配置、維護以及控制系統的信息。

UML的應用范圍

UML以面向對象的方式來描述系統。最廣泛的應用是對軟件系統進行建模,但它同樣適用於許多非軟件系統領域的系統。從理論上說,任何具有靜態結構和動態行為的系統都可以使用UML進行建模。當UML應用於大多數軟件系統的開發過程時,它從需求分析階段到系統完成后的測試階段都能起到重要作用。

在測試階段,可以用UML圖作為測試依據:用類圖指導單元測試,用組件圖和協作圖指導集成測試,用用例圖指導系統測試等。

初識UML

想要理解和使用UML,需要掌握UML的概念模型。UML的概念模型主要包括基本構造快、運用於構造快的通用機制和用於組織UML試圖的架構。

UML構造快

構造塊(building block)指的是UML的基本建模元素,是UML中用於表達的語言元素,是來自現實世界中的概念的抽象描述方法。

構造塊包括事物(thing)、關系(relationship)和圖(diagram)三個方面的內容。

  • 事物是對模型中關鍵元素的抽象體現;
  • 關系是事物和事物間聯系的方式;
  • 圖是相關的事物及其關系的聚合表現。

事物

在UML中,事物是構成模型圖的主要構造塊,它們代表了一些面向對象的基本概念,事物被分為以下四種類型。

  1. 結構事物

    結構事物(structural thing)通常作為UML模型的靜態部分,用於描述概念元素或物理元素。結構事物總稱為類元(classifier)。常見的結構事物有類、接口、用例、協作、組件、節點等。

    • 類(class)是對具有相同屬性、相同操作、相同關系和相同語義的一組對象的描述。在UML圖中使用矩形表示類,核心內容包括類名、屬性、方法(操作)。
    • 接口(interface)是一組操作的集合,這些操作包括類或組件的動作,描述了元素的外部可見行為。接口僅僅定義操作的數量和特征,但不提供具體的實現方法。接口可以被類繼承,繼承了某接口的類必須提供該接口所有操作的實現。接口一般不需要屬性。在UML中接口的聲明也使用矩形描述,在接口名上方使用構造型< >與類做區分。[見書 p17]
    • 協作(collaboration)定義了一個交互,它是在為實現某個目標而共同工作、相互配合的多個元素之間的交互動作。協作具有結構、行為和緯度,一個類或對象可以參與多個協作。在UML圖中把協作畫成虛線橢圓,僅包含名稱。這種表示法允許從外部把一個協作視為一個整體,但我們通常不使用這種表示方式,而是對協作內部更感興趣。因此,我們往往會放大一個協作,將其內部細節引導到一些圖中——特別是類圖(用來表示協作的結構部分)和交互圖(用來表示協作的行為部分)。
    • 用例(use case)描述了一組動作序列,這些動作序列將作為服務由特定的參與者觸發或執行,在過程中產生有價值、可觀察的結果,結果可反饋給參與者或作為其他用例的參數。在UML圖中用例表示為實現橢圓,僅包含名稱。
    • 組件(component)是系統中封裝好的模塊化部件,僅將外部接口暴露出來,內部實現被隱藏。組件可以由部件和部件之間的連接表示,其中部件也可以包含更小的組件。接口相同的部件可以互相替換。在UML圖中將組件表示稱矩形框,左邊框上附着兩個小矩形,框內些組件名。
    • 節點(node)是在軟件部署時需要的物理元素,其本質為一種計算機資源。一組組件可以存在於一個節點內,也可以從一個節點遷移到另一個節點。在UML圖中節點用一個立方體表示,僅包含名稱。
  2. 行為事物

    行為事物(behavioral thing)也稱為動作事物,是UML模型的動態部分,用於描述UML模型中的動態元素,主要為靜態元素之間產生的時間和空間上的行為動作,類似於句子中動詞的作用。

    • 交互(interaction)描述一種行為,它產生於協作完成一個任務的多個元素之間。交互包含消息、狀態和連接。在UML圖中消息表示為實箭頭,源自消息發出者,指向接收者,箭頭上方寫操作名。
    • 狀態機(state machine)定義了對象或行為在生命周期內的狀態轉移規則。狀態機中包含狀態、轉移、條件(事件)以及活動。UML圖中的狀態機表示為圓角矩形,包含狀態名。
    • 活動(activity)描述了一個操作執行時的過程信息。一個活動包含在操作執行過程中每一個步驟(動作)之間的先后序列關系。UML圖中的活動也表示為圓角矩形,它和狀態機圖例的區分依靠語義。
  3. 分組事物

    分組事物(grouping thing)又稱組織事物,是UML模型的組織部分,是用來組織系統設計的事物。主要的分組事物是包,另外,其他基於包的擴展事物(例如子系統、層等)也可作為分組事物。

  4. 注釋事物

    注釋事物(annotation thing)又稱輔助事物,是UML模型的解釋部分。這些注釋事物用來描述、說明和標注模型的任何元素,簡言之就是對UML中元素的注釋。最主要的注釋事物就是注解(note),是依附於一個元素或一組元素之上對其進行約束或解釋的簡單符號,內容為對元素的進一步解釋文本。這些解釋文本在UML圖中可以附加到任何模型的任意位置上,用虛線連接到被解釋的元素,當不需要顯示注解時可以隱藏,也可以以鏈接形式放到外部文本中(如果注釋很長)。幾乎所有的UML圖形元素都可以用注解來說明。

關系

關系是模型元素之間具體化的語義連接,負責聯系UML的各類事物,構造出結構良好的UML模型。

在UML中有四種主要的關系:

  • 關聯(association):描述不同類元的實例之間的連接。它是一種結構化的關系,指一種對象和另一種對象之間存在聯系,即“從一個對象可以訪問另一個對象”。更詳細地,我們說兩個對象之間互相可以訪問,那么這是一個雙向聯系,否則稱為單項聯系。關聯中還有一種特殊的情況,稱作聚合關系,聚合表示兩個類元的實例具有整體和部分的關系,表示整體的模型元素可能是多個表示部分的模型元素的聚合。
  • 依賴(dependency):描述一對模型元素之間的內在聯系(語義關系),若一個元素的某些特性隨某一個獨立元素的特性的改變而改變,則這個不是獨立的,它依賴於上文所給的那個獨立元素。
  • 泛化(generalization):類似於面向對象方法中的繼承關系,是特殊到一般的一種歸納和分類關系。泛化可以添加約束條件,說明該泛化關系的使用方法或擴充方法,稱為受限泛化。
  • 實現(realization):描述規格說明和其實現的元素之間的連接的一種關系。其中規定說明定義了行為的說明,真正的實現由后一個模型元素來完成。實現關系一般用於兩種情況下:接口和實現接口的類和組件之間與用例和實現它們的協作之間。

這四種關系是UML模型中包含的最基本的關系,它們可以擴展和變形。

圖是一組模型元素的圖形表示,是模型的展示效果。多數的UML圖是由通過路徑連接的圖形構成的。信息主要通過拓撲結構表示,而不依賴於符號的大小或者位置(有一些例外,如順序圖)。

根據UML圖的基本功能和作用,可以將其划分為兩大類:結構圖(structure diagrams)和行為圖(behaviour diagrams)。
結構圖捕獲事物與事物之間的靜態關系,用來描述系統的靜態結構模型;
行為圖則捕獲事物的交互過程如何產生系統的行為,用來描述系統的動態行為模型。

UML2

規范中包含14種圖:類圖、對象圖、組合結構圖、組件圖、部署圖、包圖、外廓圖、用例圖、活動圖、狀態機圖、順序圖、通信圖、時序圖、交互概念圖。

uml2img

UML通用機制

UML提供了四種通用機制,它們被一直地應用到模型中,描述了達到面向對象建模目的的4種策略,並在UML的不同語境下被反復運用,是的UML更簡單並易於使用。
這四種機制分別是:規格說明(specifications)、修飾(adornments)、通用划分(common divisions)和擴展機制(extensibility mechanisms)。

規格說明

UML不僅僅是一個圖形化的語言,恰恰相反,在每個圖形符號后面都有一段描述用來說明構建模塊的語法和語義。

UML的規格說明用來對系統的細節進行描述,在增加模型的規格說明時可以確定系統的更多性質,細化對系統的描述。通過規格說明,我們可以利用UML構建出一個可增量的模型,即首先分析確定UML圖形,然后不斷對該元素添加規格說明來完善其語義。

修飾

UML中大多數的元素都有一個唯一的和直接的圖形符號,用來給元素的最重要的方面提供一個可視的表達方式。
修飾是對規格說明的文字的或圖形的表示。
在UML中的每個元素符號都以一個基本的符號開始,在其上添加一些具有獨特性的修飾。

通用划分

在面向對象系統建模中,通常有幾種划分方法,其中最常見的兩種划分是類型-實例與接口-實例。

UML擴展機制

構造型(stereotype)

標記值(tagged value)

約束(constraint)

用例圖

用例圖(use case diagram)是表示一個系統中用例與參與者關系之間的圖。它描述了系統中相關的用戶和系統對不同用戶提供的功能和服務。
用例圖是UML中對系統的動態方面建模的五種圖之一(其他四種是活動圖、狀態機圖、順序圖和通信圖),是對系統、子系統和類的行為進行建模的核心。

用例圖的組成元素

  • 參與者

    凡有用例,必存在參與者。一個不能被任何用戶感知到的“功能”和“事物”,在系統中存在的意義又是什么呢? 太精辟了!

    什么是參與者?

    參與者(actor,也被譯為執行者),是與系統主體交互的外部實體的類元,描述了一個或一組與系統產生交互的外部用戶或外部事物。參與者以某種方式參與系統中一個或一組用例的執行。

    參與者位於系統邊界之外,而不是系統的一部分。也就是說,參與者是從現實世界中與系統有交互的事物中抽象出來的,而並非系統中的一個類。

    在UML中,參與者有兩種表示法。一般情況下,習慣用圖表表示法來代表人,用類符號表示法來表示事物。此外參與者可以分欄來表示它的屬性和接收到的事件。

    如何確定參與者?

    確定參與者是構建用例圖的第一步。一般可以從以下幾個角度來考慮:

    • 為系統提供輸入的人或事物。
    • 接收系統輸出的人或事物。
    • 需要接入的第三方系統或設備。
    • 時間是否會觸發某些事件。
    • 負責支持或維護系統中信息的人。

    除了從以上角度考慮參與者,還可以參考參與者的分類來進行確定。系統中的參與者一般可以分為四類。

    • 主要業務參與者(primary business actor):主要從用例的執行中獲得好處的關聯人員。主要業務參與者可能會發起一個業務事件。
    • 主要系統參與者(primary system actor):直接同系統交互以發起或觸發業務或系統事件的關聯人員。主要系統參與者可能會與主要業務參與者進行交互,以便使用系統。
    • 外部服務參與者(external server actor):響應來自用例的請求的關聯人員。
    • 外部接收參與者(external receiver actor):從用例中接收某些價值或輸出的非主要的關聯人員。
  • 用例

    在UML建模中,用例無疑是最重要的元素之一。
    用例圖是UML中最重要的元素之一,准確的用例定義是在軟件開發過程中不可或缺的要素。

    什么是用例?

    用例(use case,又被譯作用況)是類元(一般是系統、子系統或類)提供的一個內聚的功能單元,表明系統與一個或多個參與者之間信息交換的順序,也表明了系統執行的動作。一個用例就是系統的一個目標,描述為實現此目標的活動和系統交互的一個序列。用例的目標是要定義系統或子系統的一個行為,但不揭示系統的內部結構。

    用例是一種理解和記錄系統需求的出色的技術,用例所描述的場景實際上包含了系統的一個或多個需求,因此用例與用例圖被廣泛用於系統的需求建模階段,並在系統的整個生命周期中被不斷細化。

    在UML中,用例用一個包含名稱的橢圓形來表示,其中用例的名稱可以顯示在橢圓內部或橢圓下方。

    用例與參與者?

    參與者與用例是用例圖中最重要的兩個元素,二者也存在着密不可分的關系。用例是參與者與系統主體的不同交互作用的量化,是參與者請求或觸發的一系列行為。一個用例可以隸屬一個或多個參與者,一個參與者也可以參與一個或多個用例。沒有參與任何用例的參與者是無意義的。

    用例與參與者之間存在關聯關系,即參與者實例通過與用例實例傳遞消息實例(信號與調用)來與系統進行通信。

ER圖

ER圖的核心要素:

實體,屬性,關系;

圖例:

ea圖示

功能結構圖

一般情況下產品或系統的總功能可分解為若干分功能,各分功能又可進一步分解為若干二級分功能,如此繼續,直至各分功能被分解為功能單元為止。這種由分功能或功能單元按照其邏輯關系連成的結構稱為功能結構。分功能或功能單元的相互關系可以用圖來描述,表達分功能或功能單元相互關系或從屬關系的圖稱為功能結構圖。

定義

功能結構圖就是按照功能的從屬關系畫成的圖表,圖中的每一個框都稱為一個功能模塊。功能模塊可以根據具體情況分的大一點或小一點,分解得最小功能模塊可以是一個程序中的每個處理過程,而較大的功能模塊則可能是完成某一個任務的一組程序。

系統流程圖

系統流程圖是概括的描繪系統物理模型的傳統工具。它的基本思想是用圖形符號以黑盒子形式描繪系統里面的每個具體部件(程序、文件、數據庫、表格、人工過程等),表達數據在系統各個部件之間流動的情況。

說明

系統流程圖表達的是系統各部件的流動情況,而不是表示對信息進行加工處理的控制過程。

系統流程圖的作用表現在以下幾個方面:

  1. 制作系統流程圖的過程是系統分析員全面了解系統業務處理概況的過程,它是系統分析員做進一步分析的依據。
  2. 系統流程圖是系統分析員、管理員、業務操作員相互交流的工具。
  3. 系統分析員可直接在系統流程圖上畫出可以有計算機處理的部分。
  4. 可利用系統流程圖來分析業務流程的合理性。

圖例

tuli

tushi1

組織結構圖

  1. 可以顯示其職能的划分.
  2. 可以知道其權責是否適當.
  3. 可以看出該人員的工作負荷是否過重.
  4. 可以看出是否有無關人員承擔幾種較松散,無關系的工作.
  5. 可以看出是否有讓有才干的人沒有發揮出來的情形.
  6. 可以看出有沒有讓不勝任此項工作的人擔任的重要職位.
  7. 可以看出晉升的渠道是否暢通.
  8. 可以顯示出下次升級時誰是最合適的人選.

順序圖

是描述動態交互過程圖,以時間為順序,強調時間。

  1. 包圖 -> 組織結構圖
  2. 用例模型 -> 崗位職責圖

靜態用類圖

動態用順序圖(描述了一堆對象)

  1. 百度文庫
  2. bsdn博客
  3. 中國知網


免責聲明!

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



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