第13節 - UML(Unified Modeling Language): Class Diagram
這一節我會介紹統一建模語言(UML-Unified Modeling Language),而我會詳細介紹UML內的其中一種圖示-類別圖(Class Diagram)。
UML是一種用於描述軟體結構的語言,用於說明、可視化、構建和編寫一個軟體系統。簡單來說就是用圖表形式去設計你的程式或系統。
UML中一共定義了14種圖示(diagram),UML的不同版本可能會有不同數目的圖示。
這14種圖示可分為兩類:
1. 結構性圖形(Structure diagram)
2. 行為式圖形(Behavior diagram)
UML的定義(Definition)
- The Unified Modeling Language (UML) is a general-purpose modeling language in the field of software engineering, which is designed to provide a standard way to visualize the design of a system.
- UML是一種用於描述軟體結構的語言。
- 統一建模語言(UML-Unified Modeling Language)是非專利的第三代建模和規約語言。UML是一種開放的方法,用於說明、可視化、構建和編寫一個正在開發的、面向對象的、軟體密集系統的製品的開放方法。UML展現了一系列最佳工程實踐,這些最佳實踐在對大規模,複雜系統進行建模方面,特別是在軟體架構層次已經被驗證有效。
為甚麼要學UML和Class Diagram?
首先,在我們開發或設計一隻遊戲時,我們可用Class Diagram把不同程式部分串聯起來,對設計遊戲的初期有很多好處。
注意,UML內有14種圖示,我只會用到其中的一種-類別圖(Class Diagram)。
以下就是用Class Diagram來設計LibGDX遊戲的開埸晝面(Splash Screen),我會在第17節 - LibGDX: Splash Screen詳細介紹編寫Splash Screen的程式。
Class Diagram的種類
Class Diagram可分為六類:
1. 關聯-Association
2. 聚合-Aggregation
3. 組成-Composition
4. 依賴-Dependency
5. 概括-Generalization
6. 實現-Realization
Class Diagram的關聯多重性(Multiplicity)
關聯多重性(Multiplicity)是用來定義類別物件的數量,每個類別都必須指定多重性值,例如Class A會有多少個物件與Class B類別物件關連在一起,可以是一對多,或是多對多。
例子1
- Class A和Class B的關係是Association (單向,Uni-directional),Multiplicity是1...1,則是Class B會有一個物件與Class A的一個物件關連在一起。
One object A is associated with one object B.
例子2
- Class A和Class B的關係是Association (雙向,Bi-directional),Multiplicity是1...1,則是Class B會有一個物件與Class A的一個物件關連在一起,還有Class A會有一個物件與Class B的一個物件關連在一起。
One object A is associated with one object B and one object B is associated with one object A.
注意,Association (雙向,Bi-directional)也可用沒有箭頭的直線代表,如下圖:
例子3
- Class A和Class B的關係是Association (單向,Uni-directional),Multiplicity是1...*,則是Class B會有多個物件與Class A的一個物件關連在一起。
One object A is associated with more than one object B.
Association
以上介紹過,Association分為兩類:Uni-directional(單向)或Bi-direcitonal(雙向),而Bi-direcitonal可用雙箭頭或沒有箭頭的直線代表,如下圖:
Association有一個"has a"的關係,Class A物件"has a"Class B的物件。
要注意的是雖然Class A用到Class B的物件,但Class A沒有擁有Class B的物件,則Association是沒有擁有者(Owner)的。
例子1
在Class A的方法(method)內傳入Class B物件b的reference。
Class A的方法(method)只傳入Class B物件b的reference,Class A沒有擁有Class B的物件b。
例子2
在Class A的建構子(Constructor)內傳入Class B物件b的reference。
Class A的建構子(Constructor)只傳入Class B物件b的reference,然後Class A建立自己一個物件的reference,Class A沒有擁有Class B的物件b。
例子3
與例子2相似,在Class A的Setter() method內入傳入Class B物件b的reference,而Class A內須要設定一個Class B物件b的reference。
Class A的Setter() method只傳入Class B物件b的reference,然後Class A建立自己一個物件的reference,Class A沒有擁有Class B的物件b。
Aggregation
Aggregation也是Association的一種,也是Association的一種特別類型。
所以通常Aggregation也可以簡化用Association代替(Redundancy Relationship),如下圖:
Aggregation和Association一樣,也有一個"has a"的關係,不同的是Class A和Class B物件有一個Part-Whole的關係,而且關聯多重性(Multiplicity)會大過1。
注意,與Composition不同,一個Part可以供給不同的Whole。如果Whole刪除,Part仍然可以存在。
例子 - Part-Whole的關係
以下程式Class B有多個物件 b1 (e.g. Array Type)傳入一個Class A內
以下是一個Part-Whole的關係,Car是Whole,Wheel和Engine是Part,Engine除了供給Car1外,也供給Car2,如果Car1刪除,Wheel和Engine仍然存在,繼續供給Car2。
關聯多重性(Multiplicity)是大過1。
另外,Engine除了供給Car1也供給Car2,所以Aggregation也叫做Shared Association。
Composition
Composition也是Association的一種,也是Aggregation(Stong Type)的一種特別類型。
Composition有一個"owns"的關係,和Aggregation一樣,也有一個Part-Whole的關係,但與Aggregation不同,一個Part只可以供給一個Whole。如果Whole刪除,Part就不能存在。
例子 - Part-Whole的關係
以下程式Class A是Whole,Class B是Part,要做到Class A擁有Class B物件和共生死,只要在Class A內用"new"產生一個Class B物件就可以,如下圖:
以下是一個Part-Whole關係,Person是Whole,Leg和Hand是Part,如果Person刪除,Leg和Hand就不能存在。
另外,Leg和hand只可以供給一個Person,所以Composition也叫做Not-shared Association。
Dependency
Dependency通常會用Class B物件的reference傳入Class A的方法(method)內,再在Class A內用Class B的方法(method)。
所以Dependency的意思是如果Class B程式有任何更改,Class A程式也要更改,如下圖:
Generalization
Generalization就十分簡單,Class A繼承(extends) Class B,如下圖:
Realization
Realization也很簡單,Class A實現(implements) interface B,如下圖:
Association, Aggregation和Compostion的關係
1-Aggregation也是Association的一種,Aggregation是Association的一種特別類型。
2-Aggregation也叫做Shared Association。
3-Composition也是Association的一種,也是Aggregation的一種特別類型。
4-Composition也叫做Not-shared Association。
所以Association, Aggregation和Compostion有以下的關係:
簡化類別圖
大家可以在以上看到,Association, Aggregation, Composition和Dependency的關係很相似,因為其關係沒有一個很明確的定意,不同人的解釋有所不同,所以如果我們只想用Class Diagram去設計一個LibGDX遊戲,我們可以簡化類別圖,只用Association, Generalization和Realization。
Class Diagram - LibGDX遊戲的Splash Screen
以下就是用Class Diagram來設計LibGDX遊戲的開埸晝面(Splash Screen)。
- Game是abstract Class,ApplicationListener是interface,所以它們的關係是Realization。
- MyDemo13是Class,Game是abstract Class,所以它們的關係是Generalization。
- MyDemo13是Class,SplashScreen是Class(傳入MyDemo13內用),所以它們的關係是Association。
- SplashScreen是Class,MenuScreen是Class(傳入SplashScreen內用),所以它們的關係是Association。
- SplashScreen和MenuScreen是Class,Screen是interface,所以它們的關係是Realization。
注意,我會在第17節 - LibGDX: Splash Screen詳細介紹編寫Splash Screen的程式。