UML使用——活動圖、類圖

這次是活動圖,也是網上寫的不錯的,特地摘錄在這裏。

UML 活動圖

內容路線

image

•活動圖概述

活動圖概述

•活動圖和交互圖是UML中對系統動態方面建模的兩種主要形式

•交互圖強調的是對象到對象的控制流,而活動圖則強調的是從活動到活動的控制流

•活動圖是一種表述過程基理、業務過程以及工作流的技術。它可以用來對業務過程、工作流建模,也可以對用例實現甚至是程序實現來建模

•UML 2.0而言,去除了“活動圖是狀態圖的一種特例”這一規定

 

 

 

•如何閱讀活動圖

閱讀簡單活動圖

image

活動圖的主要元素

•初始節點和活動終點:用一個實心圓表示初始節點,用一個圓圈內加一個實心圓來表示活動終點

•活動節點:是活動圖中最主要的元素之一,它用來表示一個活動

image

 

•轉換:當一個活動結束時,控制流就會馬上傳遞給下一個活動節點,在活動圖中稱之爲“轉換”,用一條帶箭頭的直線來表示

活動圖的主要元素

•分支與監護條件:分支是用菱形表示的,它有一個進入轉換(箭頭從外指向分支符號),一個或多個離開轉換(箭頭從分支符號指向外)。而每個離開轉換上都會有一個監護條件,用來表示滿足什麼條件的時候執行該轉換。

image

•分岔與匯合:

image

修改後的簡單活動圖

image

帶泳道的活動圖

image

帶對象流的活動圖

image

複雜活動圖

•輔助活動圖:

image

•匯合描述:當匯合的所有入流均到點匯合點時,就將執行匯合點指向的活動節點。但是有些時候,你希望對其做一些約束,這時就可以藉助匯合描述來完成。匯合描述實際上是一個約束,其格式就是“{約束條件}”。

•發送信號與接收信號:

image 

image

 

 

 

•如何繪製活動圖

繪製活動圖

•“活動圖” 比較直觀易懂;與傳統的流程圖十分的相近,只要能夠讀懂活動圖,就不難畫出活動圖

•繪製時首先決定是否採用泳道:主要根據活動圖中是否要體現出活動的不同實施者

•然後儘量使用分支、分岔和匯合等基本的建模元素來描述活動控制流程

•如果需要,加入對象流以及對象的狀態變化,利用一些高級的建模元素(如輔助活動圖、匯合描述、發送信號與接收信號、引腳、擴展區)來表示更多的信息

•活動圖的建模關鍵是表示出控制流,其它的建模元素都是圍繞這一宗旨所進行的補充

工作流程,控制流程,業務流程中使用。

•活動圖應用說明

活動圖應用說明

•對工作流建模:用於業務建模的時候,每一條泳道表示一個職責單位,該圖能夠有效地體現出所有職責單位之間的工作職責業務範圍及之間的交互關係、信息流程

建模時應遵循以下策略:

•爲工作流建立一個焦點,除非你所涉及的系統很小,否則不可能在一張圖中顯示出系統中所有的控制流

•選擇對全部工作流中的一部分有高層職責的業務對象,併爲每個重要的業務對象創建一條泳道

•識別工作流初始節點的前置條件和活動終點的後置條件,這可有效地實現對工作流的邊界進行建模。

•從該工作流的初始節點開始,說明隨時間發生的動作和活動,並在活動圖中把它們表示成活動節點

•將複雜的活動或多次出現的活動集合歸到一個活動節點,並通過輔助活動圖或子活動圖來表示它們

•找出連接這些活動節點的轉換首先從工作流的順序開始然後考慮分支接着再考慮分岔和匯合

•如果工作流中涉及重要的對象,則也可以將它們加入到活動圖中

•若工作流中有多次啓用的,則可採用展開區表示

對操作建模:每一個對象佔據一個泳道,而活動則是該對象的成員方法

•建模時應遵循以下策略: 
-- 收集操作所涉及的抽象概念,包括操作的參數、返回類型、所屬類的屬性以及某些鄰近的類 
-- 識別該操作的初始節點的前置條件和活動終點的後置條件。也要識別在操作執行過程中必須保持的信息 
-- 從該操作的初始節點開始,說明隨着時間發生的活動,並在活動圖中將它們表示爲活動節點 
-- 如果需要,使用分支來說明條件語句及循環語句 
-- 僅當這個操作屬於一個主動類時,纔在必要時用分岔和匯合來說明並行的控制流程

•本章小結

•首先介紹了“活動圖”的歷史變遷;逐一介紹簡單活動圖、帶泳道的活動圖、帶對象流的活動圖的閱讀方法

•講解了活動節點、初始節點和活動終點、轉換、 分支與監護條件、分岔與匯合等基本建模元素;逐步引出了泳道、對象流等控制流邏輯

•介紹了輔助活動圖、匯合描述、發送信號與接收信號、引腳和擴展區的概念

•最後,概括地說明了活動圖的繪製要點,並結合對工作流建模和對操作建模之間的異同


1、什麼是類圖

  類圖(Class diagram)主要用於描述系統的結構化設計。類圖也是最常用的UML圖,用類圖可以顯示出類、接口以及它們之間的靜態結構和關係。

2、類圖的元素

  在類圖中一共包含了以下幾種模型元素,分別是:類(Class)、接口(Interface)、依賴(Dependency)關係、泛化(Generalization)關係、關聯(Association)關係、聚合關係(Aggregation)、組合關係(Composition)和實現(Realization)關係。

2.1 類(Class)

  在面向對象(OO) 編程中,類是對現實世界中一組具有相同特徵的物體的抽象。

2.2 接口(Interface)

  接口是一種特殊的類,具有類的結構但不可被實例化,只可以被實現(繼承)。在UML中,接口使用一個帶有名稱的小圓圈來進行表示。

2.3 依賴(Dependency)關係

  依賴關係是指兩個或多個類之間的依存關係,如植物類依賴於土壤類。 依賴關係還可以再細分爲5種類型,分別是綁定(Binding)依賴、實現(Realization)依賴、使用(Usage)依賴、抽象(Abstraction)依賴和授權(Permission)依賴。

  依賴關係用虛線箭頭來表示,箭頭指向爲依賴的方向。

2.4 泛化(Generalization)關係

  簡單的講就是類之間的繼承關係。在UML中,泛化關係用空心三角形+實線來表示,箭頭指向爲父類。

2.5 聚合(Association)關係

  聚合關係是類之間的一種較弱的耦合關係,如一個字符串數組和一個字符串就是一種聚合關係。在UML中類圖中,聚合關係用空心的菱形+實線箭頭來表示,箭頭指向爲被聚合的類。

  

2.6 組合(Aggregation)關係

  組合關係是類之間一種整體與部分之間的關係,如一隻青蛙有四條腿,青蛙類與青蛙腿類之間的關係就是組合關係。在UML類圖中,組合關係用實心的菱形+實線箭頭來表示,箭頭指向爲被組合的類。

2.7 關聯(Composition)關係

  關聯關係是類之間一種相互影響的關係,影響的方向就是關聯的方向。在UML類圖中,組合關係用實線箭頭來表示。

2.8 實現(Realization)關係

  一般來講實現關係是針對類與接口之間的關係而言的。在UML類圖中,實現關係用空心三角形+虛線來表示。


3、簡單的類圖示例

 




在UML 2.0的13種圖形中,類圖是使用頻率最高的UML圖之一。Martin Fowler在其著作《UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition》(《UML精粹:標準對象建模語言簡明指南(第3版)》)中有這麼一段:“If someone were to come up to you in a dark alley and say, 'Psst, wanna see a UML diagram?' that diagram would probably be a class diagram. The majority of UML diagrams I see are class diagrams.”(“如果有人在黑暗的小巷中向你走來並對你說:‘嘿,想不想看一張UML圖?’那麼這張圖很有可能就是一張類圖,我所見過的大部分的UML圖都是類圖”),由此可見類圖的重要性。

類圖用於描述系統中所包含的類以及它們之間的相互關係,幫助人們簡化對系統的理解,它是系統分析和設計階段的重要產物,也是系統編碼和測試的重要模型依據。

1. 類

類(Class)封裝了數據和行爲,是面向對象的重要組成部分,它是具有相同屬性、操作、關係的對象集合的總稱。在系統中,每個類都具有一定的職責,職責指的是類要完成什麼樣的功能,要承擔什麼樣的義務。一個類可以有多種職責,設計得好的類一般只有一種職責。在定義類的時候,將類的職責分解成爲類的屬性和操作(即方法)。類的屬性即類的數據職責,類的操作即類的行爲職責。設計類是面向對象設計中最重要的組成部分,也是最複雜和最耗時的部分。

在軟件系統運行時,類將被實例化成對象(Object),對象對應於某個具體的事物,是類的實例(Instance)。

類圖(Class Diagram)使用出現在系統中的不同類來描述系統的靜態結構,它用來描述不同的類以及它們之間的關係。

在系統分析與設計階段,類通常可以分爲三種,分別是實體類(Entity Class)、控制類(Control Class)和邊界類(Boundary Class),下面對這三種類加以簡要說明:

(1) 實體類:實體類對應系統需求中的每個實體,它們通常需要保存在永久存儲體中,一般使用數據庫表或文件來記錄,實體類既包括存儲和傳遞數據的類,還包括操作數據的類。實體類來源於需求說明中的名詞,如學生、商品等。

(2) 控制類:控制類用於體現應用程序的執行邏輯,提供相應的業務操作,將控制類抽象出來可以降低界面和數據庫之間的耦合度。控制類一般是由動賓結構的短語(動詞+名詞)轉化來的名詞,如增加商品對應有一個商品增加類,註冊對應有一個用戶註冊類等

(3) 邊界類:邊界類用於對外部用戶與系統之間的交互對象進行抽象,主要包括界面類,如對話框、窗口、菜單等。

在面向對象分析和設計的初級階段,通常首先識別出實體類,繪製初始類圖,此時的類圖也可稱爲領域模型,包括實體類及其它們之間的相互關係。

2. 類的UML圖示

在UML中,類使用包含類名、屬性和操作且帶有分隔線的長方形來表示,如定義一個Employee類,它包含屬性name、age和email,以及操作modifyInfo(),在UML類圖中該類如圖1所示:

圖1 類的UML圖示

圖1對應的Java代碼片段如下:

public class Employee {
	private String name;
	private int age;
	private String email;
	
	public void modifyInfo() {
		......
	}
}

在UML類圖中,類一般由三部分組成:

(1) 第一部分是類名:每個類都必須有一個名字,類名是一個字符串。

(2) 第二部分是類的屬性(Attributes):屬性是指類的性質,即類的成員變量。一個類可以有任意多個屬性,也可以沒有屬性

UML規定屬性的表示方式爲:

可見性 名稱:類型 [ = 缺省值 ]

其中:

  • “可見性”表示該屬性對於類外的元素而言是否可見,包括公有(public)、私有(private)和受保護(protected)三種,在類圖中分別用符號+、-和#表示。
  • “名稱”表示屬性名,用一個字符串表示。
  • “類型”表示屬性的數據類型,可以是基本數據類型,也可以是用戶自定義類型。
  • “缺省值”是一個可選項,即屬性的初始值。

(3) 第三部分是類的操作(Operations):操作是類的任意一個實例對象都可以使用的行爲,是類的成員方法。

UML規定操作的表示方式爲:

可見性 名稱(參數列表) [ : 返回類型]

其中:

  • “可見性”的定義與屬性的可見性定義相同。
  • “名稱”即方法名,用一個字符串表示。
  • “參數列表”表示方法的參數,其語法與屬性的定義相似,參數個數是任意的,多個參數之間用逗號“,”隔開。
  • “返回類型”是一個可選項,表示方法的返回值類型,依賴於具體的編程語言,可以是基本數據類型,也可以是用戶自定義類型,還可以是空類型(void),如果是構造方法,則無返回類型。

在類圖2中,操作method1的可見性爲public(+),帶入了一個Object類型的參數par,返回值爲空(void);操作method2的可見性爲protected(#),無參數,返回值爲String類型;操作method3的可見性爲private(-),包含兩個參數,其中一個參數爲int類型,另一個爲int[]類型,返回值爲int類型。

圖2 類圖操作說明示意圖

由於在Java語言中允許出現內部類,因此可能會出現包含四個部分的類圖,如圖3所示:

圖3 包含內部類的類圖

類與類之間的關係(1)

在軟件系統中,類並不是孤立存在的,類與類之間存在各種關係,對於不同類型的關係,UML提供了不同的表示方式。

1. 關聯關係

關聯(Association)關係是類與類之間最常用的一種關係,它是一種結構化關係,用於表示一類對象與另一類對象之間有聯繫,如汽車和輪胎、師傅和徒弟、班級和學生等等。在UML類圖中,用實線連接有關聯關係的對象所對應的類,在使用Java、C#和C++等編程語言實現關聯關係時,通常將一個類的對象作爲另一個類的成員變量。在使用類圖表示關聯關係時可以在關聯線上標註角色名,一般使用一個表示兩者之間關係的動詞或者名詞表示角色名(有時該名詞爲實例對象名),關係的兩端代表兩種不同的角色,因此在一個關聯關係中可以包含兩個角色名,角色名不是必須的,可以根據需要增加,其目的是使類之間的關係更加明確。

如在一個登錄界面類LoginForm中包含一個JButton類型的註冊按鈕loginButton,它們之間可以表示爲關聯關係,代碼實現時可以在LoginForm中定義一個名爲loginButton的屬性對象,其類型爲JButton。如圖1所示:

圖1 關聯關係實例

圖1對應的Java代碼片段如下:

public class LoginForm {
private JButton loginButton; //定義爲成員變量
……
}

public class JButton {
    ……
}

在UML中,關聯關係通常又包含如下幾種形式:

(1) 雙向關聯

默認情況下,關聯是雙向的。例如:顧客(Customer)購買商品(Product)並擁有商品,反之,賣出的商品總有某個顧客與之相關聯。因此,Customer類和Product類之間具有雙向關聯關係,如圖2所示:

圖2 雙向關聯實例

圖2對應的Java代碼片段如下:

public class Customer {
private Product[] products;
……
}

public class Product {
private Customer customer;
……
}

(2) 單向關聯

類的關聯關係也可以是單向的,單向關聯用帶箭頭的實線表示。例如:顧客(Customer)擁有地址(Address),則Customer類與Address類具有單向關聯關係,如圖3所示:

圖3 單向關聯實例

圖3對應的Java代碼片段如下:

public class Customer {
private Address address;
……
}

public class Address {
……
}

(3) 自關聯

在系統中可能會存在一些類的屬性對象類型爲該類本身,這種特殊的關聯關係稱爲自關聯。例如:一個節點類(Node)的成員又是節點Node類型的對象,如圖4所示:

圖4 自關聯實例

圖4對應的Java代碼片段如下:

public class Node {
private Node subNode;
……
}

(4) 多重性關聯

多重性關聯關係又稱爲重數性(Multiplicity)關聯關係,表示兩個關聯對象在數量上的對應關係。在UML中,對象之間的多重性可以直接在關聯直線上用一個數字或一個數字範圍表示。

對象之間可以存在多種多重性關聯關係,常見的多重性表示方式如表1所示:

表1 多重性表示方式列表

表示方式
多重性說明
1..1
表示另一個類的一個對象只與該類的一個對象有關係
0..*
表示另一個類的一個對象與該類的零個或多個對象有關係
1..*
表示另一個類的一個對象與該類的一個或多個對象有關係
0..1
表示另一個類的一個對象沒有或只與該類的一個對象有關係
m..n
表示另一個類的一個對象與該類最少m,最多n個對象有關係 (m≤n)

例如:一個界面(Form)可以擁有零個或多個按鈕(Button),但是一個按鈕只能屬於一個界面,因此,一個Form類的對象可以與零個或多個Button類的對象相關聯,但一個Button類的對象只能與一個Form類的對象關聯,如圖5所示:

圖5 多重性關聯實例

圖5對應的Java代碼片段如下:

public class Form {
private Button[] buttons; //定義一個集合對象
……
}

public class Button {
……
}

(5) 聚合關係

聚合(Aggregation)關係表示整體與部分的關係。在聚合關係中,成員對象是整體對象的一部分,但是成員對象可以脫離整體對象獨立存在。在UML中,聚合關係用帶空心菱形的直線表示。例如:汽車發動機(Engine)是汽車(Car)的組成部分,但是汽車發動機可以獨立存在,因此,汽車和發動機是聚合關係,如圖6所示:

圖6 聚合關係實例

在代碼實現聚合關係時,成員對象通常作爲構造方法、Setter方法或業務方法的參數注入到整體對象中,圖6對應的Java代碼片段如下:

public class Car {
	private Engine engine;

    //構造注入
	public Car(Engine engine) {
		this.engine = engine;
	}
    
    //設值注入
public void setEngine(Engine engine) {
    this.engine = engine;
}
……
}

public class Engine {
	……
} 

(6) 組合關係

組合(Composition)關係也表示類之間整體和部分的關係,但是在組合關係中整體對象可以控制成員對象的生命週期,一旦整體對象不存在,成員對象也將不存在,成員對象與整體對象之間具有同生共死的關係。在UML中,組合關係用帶實心菱形的直線表示。例如:人的頭(Head)與嘴巴(Mouth),嘴巴是頭的組成部分之一,而且如果頭沒了,嘴巴也就沒了,因此頭和嘴巴是組合關係,如圖7所示:

圖7 組合關係實例

在代碼實現組合關係時,通常在整體類的構造方法中直接實例化成員類,圖7對應的Java代碼片段如下:

public class Head {
	private Mouth mouth;

	public Head() {
		mouth = new Mouth(); //實例化成員類
	}
……
}

public class Mouth {
	……
} 

類與類之間的關係(2)

2. 依賴關係

依賴(Dependency)關係是一種使用關係,特定事物的改變有可能會影響到使用該事物的其他事物,在需要表示一個事物使用另一個事物時使用依賴關係。大多數情況下,依賴關係體現在某個類的方法使用另一個類的對象作爲參數。在UML中,依賴關係用帶箭頭的虛線表示,由依賴的一方指向被依賴的一方。例如:駕駛員開車,在Driver類的drive()方法中將Car類型的對象car作爲一個參數傳遞,以便在drive()方法中能夠調用car的move()方法,且駕駛員的drive()方法依賴車的move()方法,因此類Driver依賴類Car,如圖1所示:

圖1 依賴關係實例

在系統實施階段,依賴關係通常通過三種方式來實現,第一種也是最常用的一種方式是如圖1所示的將一個類的對象作爲另一個類中方法的參數,第二種方式是在一個類的方法中將另一個類的對象作爲其局部變量,第三種方式是在一個類的方法中調用另一個類的靜態方法。圖1對應的Java代碼片段如下:

public class Driver {
	public void drive(Car car) {
		car.move();
	}
    ……
}

public class Car {
	public void move() {
		......
	}
    ……
}  

3. 泛化關係

泛化(Generalization)關係也就是繼承關係,用於描述父類與子類之間的關係,父類又稱作基類或超類,子類又稱作派生類。在UML中,泛化關係用帶空心三角形的直線來表示。在代碼實現時,我們使用面向對象的繼承機制來實現泛化關係,如在Java語言中使用extends關鍵字、在C++/C#中使用冒號“:”來實現。例如:Student類和Teacher類都是Person類的子類,Student類和Teacher類繼承了Person類的屬性和方法,Person類的屬性包含姓名(name)和年齡(age),每一個Student和Teacher也都具有這兩個屬性,另外Student類增加了屬性學號(studentNo),Teacher類增加了屬性教師編號(teacherNo),Person類的方法包括行走move()和說話say(),Student類和Teacher類繼承了這兩個方法,而且Student類還新增方法study(),Teacher類還新增方法teach()。如圖2所示:

圖2 泛化關係實例

圖2對應的Java代碼片段如下:

//父類
public class Person {
protected String name;
protected int age;

public void move() {
        ……
}

    public void say() {
    ……
    }
}

//子類
public class Student extends Person {
private String studentNo;

public void study() {
    ……
    }
}

//子類
public class Teacher extends Person {
private String teacherNo;

public void teach() {
    ……
    }
}

4. 接口與實現關係

在很多面嚮對象語言中都引入了接口的概念,如Java、C#等,在接口中,通常沒有屬性,而且所有的操作都是抽象的,只有操作的聲明,沒有操作的實現。UML中用與類的表示法類似的方式表示接口,如圖3所示:

圖3 接口的UML圖示

接口之間也可以有與類之間關係類似的繼承關係和依賴關係,但是接口和類之間還存在一種實現(Realization)關係,在這種關係中,類實現了接口,類中的操作實現了接口中所聲明的操作。在UML中,類與接口之間的實現關係用帶空心三角形的虛線來表示。例如:定義了一個交通工具接口Vehicle,包含一個抽象操作move(),在類Ship和類Car中都實現了該move()操作,不過具體的實現細節將會不一樣,如圖4所示:

圖4 實現關係實例

實現關係在編程實現時,不同的面嚮對象語言也提供了不同的語法,如在Java語言中使用implements關鍵字,而在C++/C#中使用冒號“:”來實現。圖4對應的Java代碼片段如下:

public interface Vehicle {
public void move();
}

public class Ship implements Vehicle {
public void move() {
    ……
    }
}

public class Car implements Vehicle {
public void move() {
    ……
    }
}

實例分析1——登錄模塊

某基於C/S的即時聊天系統登錄模塊功能描述如下:

用戶通過登錄界面(LoginForm)輸入賬號和密碼,系統將輸入的賬號和密碼與存儲在數據庫(User)表中的用戶信息進行比較,驗證用戶輸入是否正確,如果輸入正確則進入主界面(MainForm),否則提示“輸入錯誤”。

根據以上描述繪製初始類圖。

參考解決方案:

參考類圖如下:

考慮到系統擴展性,在本實例中引入了抽象數據訪問接口IUserDAO,再將具體數據訪問對象注入到業務邏輯對象中,可通過配置文件(如XML文件)等方式來實現,將具體的數據訪問類類名存儲在配置文件中,如果需要更換新的具體數據訪問對象,只需修改配置文件即可,原有程序代碼無須做任何修改。

類說明:

類 名
說 明
LoginForm 登錄窗口,省略界面組件和按鈕事件處理方法(邊界類)
LoginBO 登錄業務邏輯類,封裝實現登錄功能的業務邏輯(控制類)
IUserDAO 抽象數據訪問類接口,聲明對User表的數據操作方法,省略除查詢外的其他方法(實體類)
UserDAO 具體數據訪問類,實現對User表的數據操作方法,省略除查詢外的其他方法(實體類)
MainForm 主窗口(邊界類)

方法說明:

方法名
說 明
LoginForm類的LoginForm()方法 LoginForm構造函數,初始化實例成員
LoginForm類的validate()方法 界面類的驗證方法,通過調用業務邏輯類LoginBO的validate()方法實現對用戶輸入信息的驗證
LoginBO類的validate()方法 業務邏輯類的驗證方法,通過調用數據訪問類的findUserByAccAndPwd()方法驗證用戶輸入信息的合法性
LoginBO類的setIUserDAO()方法 Setter方法,在業務邏輯對象中注入數據訪問對象(注意:此處針對抽象數據訪問類編程
IUserDAO接口的findUserByAccAndPwd()方法 業務方法聲明,通過用戶賬號和密碼在數據庫中查詢用戶信息,判斷該用戶身份的合法性
UserDAO類的findUserByAccAndPwd()方法 業務方法實現,實現在IUserDAO接口中聲明的數據訪問方法

實例分析2——註冊模塊

某基於Java語言的C/S軟件需要提供註冊功能,該功能簡要描述如下:

用戶通過註冊界面(RegisterForm)輸入個人信息,用戶點擊“註冊”按鈕後將輸入的信息通過一個封裝用戶輸入數據的對象(UserDTO)傳遞給操作數據庫的數據訪問類,爲了提高系統的擴展性,針對不同的數據庫可能需要提供不同的數據訪問類,因此提供了數據訪問類接口,如IUserDAO,每一個具體數據訪問類都是某一個數據訪問類接口的實現類,如OracleUserDAO就是一個專門用於訪問Oracle數據庫的數據訪問類。

根據以上描述繪製類圖。爲了簡化類圖,個人信息僅包括賬號(userAccount)和密碼(userPassword),且界面類無需涉及界面細節元素。

參考解決方案:

在以上功能說明中,可以分析出該系統包括三個類和一個接口,這三個類分別是註冊界面類RegisterForm、用戶數據傳輸類UserDTO、Oracle用戶數據訪問類OracleUserDAO,接口是抽象用戶數據訪問接口IUserDAO。它們之間的關係如下:

(1) 在RegisterForm中需要使用UserDTO類傳輸數據且需要使用數據訪問類來操作數據庫,因此RegisterForm與UserDTO和IUserDAO之間存在關聯關係,在RegisterForm中可以直接實例化UserDTO,因此它們之間可以使用組合關聯。

(2) 由於數據庫類型需要靈活更換,因此在RegisterForm中不能直接實例化IUserDAO的子類,可以針對接口IUserDAO編程,再通過注入的方式傳入一個IUserDAO接口的子類對象(在本書後續章節中將學習如何具體實現),因此RegisterForm和IUserDAO之間具有聚合關聯關係。

(3) OracleUserDAO是實現了IUserDAO接口的子類,因此它們之間具有類與接口的實現關係。

(4) 在聲明IUserDAO接口的增加用戶信息方法addUser()時,需要將在界面類中實例化的UserDTO對象作爲參數傳遞進來,然後取出封裝在UserDTO對象中的數據插入數據庫,因此addUser()方法的函數原型可以定義爲:public boolean addUser(UserDTO user),在IUserDAO的方法addUser()中將UserDTO類型的對象作爲參數,故IUserDAO與UserDTO存在依賴關係。

通過以上分析,該實例參考類圖如圖1所示:

圖1 註冊功能參考類圖

注意:在繪製類圖或其他UML圖形時,可以通過註釋(Comment)來對圖中的符號或元素進行一些附加說明,如果需要詳細說明類圖中的某一方法的功能或者實現過程,可以使用如圖2所示表示方式:

圖2 類圖註釋實例

實例分析3——售票機控制程序

某運輸公司決定爲新的售票機開發車票銷售的控制軟件。圖I給出了售票機的面板示意圖以及相關的控制部件。

圖I 售票機面板示意圖

售票機相關部件的作用如下所述:

(1) 目的地鍵盤用來輸入行程目的地的代碼(例如,200表示總站)。

(2) 乘客可以通過車票鍵盤選擇車票種類(單程票、多次往返票和座席種類)。

(3) 繼續/取消鍵盤上的取消按鈕用於取消購票過程,繼續按鈕允許乘客連續購買多張票。

(4) 顯示屏顯示所有的系統輸出和用戶提示信息。

(5) 插卡口接受MCard(現金卡),硬幣口和紙幣槽接受現金。

(6) 打印機用於輸出車票。

(7) 所有部件均可實現自檢並恢復到初始狀態。

現採用面向對象方法開發該系統,使用UML進行建模,繪製該系統的初始類圖。

參考解決方案:

參考類圖如下:

類說明:

類 名
說 明
Component 抽象部件類,所有部件類的父類
Keyboard 抽象鍵盤類
ActionKeyboard 繼續/取消鍵盤類
TicketKindKeyboard 車票種類鍵盤類
DestinationKeyboard 目的地鍵盤類
Screen 顯示屏類
CardDriver 卡驅動器類
CashSlot 現金(硬幣/紙幣)槽類
Printer 打印機類
TicketSoldSystem 售票系統類

方法說明:

方法名
說 明
Component 的init()方法 初始化部件
Component 的doSeltTest()方法 自檢
Keyboard的getSelectedKey()方法 獲取按鍵值
ActionKeyboard的getAction()方法 繼續/取消鍵盤事件處理
TicketKindKeyboard的getTicketKind()方法 車票種類鍵盤事件處理
DestinationKeyboard的getDestinationCode()方法 目的地鍵盤事件處理
Screen的showText()方法 顯示信息
CardDriver的getCredit()方法 獲取金額
CardDriver的debitFare()方法 更新卡餘額
CardDriver的ejectMCard()方法 退卡
CashSlot的getCredit()方法 獲取金額
Printer的printTicket()方法 打印車票
Printer的ejectTicket()方法 出票
TicketSoldSystem的verifyCredit()方法 驗證金額
TicketSoldSystem的calculateFare()方法 計算費用

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章