第四章關系建模關聯泛化依賴關系建模方法設計原則關系概述關系：描述元素之間的關系；而關系本身也是元素。主要有三種關系：關聯association泛化generalization依賴dependence關聯概述關聯表示類間靜態的結構關系。關聯是一種關系，同時也是一種類元。關聯的一個實例被稱為一個鏈(link)，一個鏈是一個元組(tuple)。一個元組有兩個以上的值，每個端(end)對應一個值，每個值都是關聯端類型的一個實例。元組的多個端的組合是不重復的。關聯確定了類型的實例之間的語義關系。一個關聯至少有兩個端，每個端連接到一個類型。一個關聯的多個端可連接到同一個類型上。在一個端上，如果一個實例存在的話，要求被關聯的另一端的零個或多個實例也必須存在。關聯是一種非定向的關系，盡管關聯可說明導向性。鏈與關聯關聯關系二元binary關聯、n元(n-ary)關聯語法：實線連接加說明命名：名稱及方向，區分多個關聯的性質(關聯的角色)。角色role：關聯中的一方對于另一方的職責的識別和命名多重性multiplicity：對象之間定量的結構關系。關聯的多重性傳統的多重性有3種形式：“1對1”、“1對多”、“多對多”。其中，“多對多”包含了“1對多”作為其特殊情形，而“1對多”包含了“1對1”作為特例。關聯端的多重性可缺省，缺省情況下為“*”，即0個到多個，而且是不重復的。用術語可表示為一個Set集合。如何確定一個關聯的多重性？對于二元關聯<A,B>來說，先確定一端類元A的任意一個實例，然后斷定所關聯的另一端B可能有多少實例，表示為B端的多重性。盡可能確切描述，避免“多”的情形。多重性聚集（1）關聯種類有3種：非聚集：無菱形共享聚集：空心菱形，各部分對象的生命期獨立于整體復合聚集：實心菱形，各部分對象的生命期受限于整體聚集aggregation：一種特殊的關聯，表示部分和整體關系，即has-a或has-many關系復合composite：整體對象負責其各部分對象的生存和存儲區分兩種聚集形式聚集（2）復合composite：一種“強”聚集aggregation形式，區分復合對象和部分對象；一個部分對象在特定時刻只能被包含在一個復合對象中；且該復合對象“獨占”各部分。當整體對象撤銷時，其各部分對象也撤銷。有三種不同方式來表示復合關系。關聯與性質關聯導向性從一端能方便到達另一端可導向不可導向非確定自關聯關聯類（1）一個關聯類(AssociationClass)是表示關聯的一個類，它不僅連接一組類元，而且可定義關聯自身的一組性質和操作。表示一個關聯類：將該類與關聯用虛線連接，而且使類名與關聯的名字相同。關聯類（2）把一個“多對多”關聯類轉換為一個普通類。兩者語義大致相同，但并不完全相同。關聯類的本質仍是二元組，有這樣一個限制作用，同一個人加入同一個團體只能有1次，所以加入時間只能有1個值。而后者則沒有這樣的限制，同一個人可多次加入同一個團體，這導致可能有多個不同的加入時間。限定關聯一個限定符包含了一個或多個屬性，限定符的一個實例包含每個屬性的一個值，稱為限定符實例。給定一個對象(如一個Consortium對象)和一個限定符實例(一個SeqNo)，在關聯的另一端的對象數量就受到限制(如Person)，其多重性通常為“0..1”。多元關聯3元關聯和一個關聯類三元關聯的一個實例是一個三元組。多重性如何確定？限定兩方都唯一時，檢查第三方關聯端的修飾符{subsets<性質名>}說明該端是指定性質的一個子集。{redefines<端名>}說明該端是指定端的重定義/<端名>說明該端是一個派生的關聯端，往往與{union}相關。{union}說明該端是其多個子集合構成的一個派生并集。{ordered}該端的多個元素是一個有序集合。{bag}該端表示一個集聚，其中同一個元素可出現多次。{sequence}或{seq}該端表示一個序列，即一個有序的bag。缺省情況下一個關聯端的集聚類型是一個集合{set}。泛化概述較一般的元素(超類)和較特殊的元素(子類)之間的關系。語法：實線空心箭頭從子類到超類語義：子類is-a-kind-of超類。子類對象可替代超類對象；子類繼承超類特征且可增加新特征；子類操作的基調與超類相同時，子類可改寫(override)超類的實現。根類/基類----葉子類單繼承---多繼承泛化的反義詞是特化specialization泛化的表示特征的繼承與擴展泛化的用途概念表述：要表述一個概念，往往要用“是一種什么”來說明。

特征重用：子類的對象繼承其超類的性質和操作，但子類并不重復描述這些特征。子類中僅描述擴展的新特征，而超類中的特征能被其所有子類共享和重用。

抽象設計：基于泛化關系的多態性是抽象設計的基礎。抽象設計與具體設計對立，在高層的抽象的級別上建立行為特征和行為規范，為低層的具體的設計提供一個統一的框架。主要是兩方面的多態性：引用類型的多態性和操作調用的多態性。關系環在兩個類之間是否可同時存在泛化和關聯兩種關系？關系環的例子泛化集一個泛化集包含一組泛化關系，針對同一個一般性類元，提供了一種分類方式，得到了一組子類型劃分泛化集的屬性一個泛化集有兩個重要屬性：isDisjoint和isCoveringoverlapping&disjoint：相交&不相交，缺省相交plete&complete；不完全&完全，缺省不完全泛化集的例子單繼承和多繼承如果一個子類只有一個直接的超類，這就是一個單繼承。反之，如果一個子類具有多個直接的超類，就是一個多繼承，也稱為多重繼承。C++語言允許類之間有多重繼承，即一個子類可有多個直接的超類。Java語言不允許類的多重繼承，但支持接口的多重繼承。UML支持類的多重繼承。如何將多繼承轉變為單繼承？依賴概述兩個命名元素之間的一種定向關系；一個是依賴元素作為client，另一個是獨立元素作為supplier；依賴元素取決于獨立元素的規范或實現；若獨立元素改變，則依賴元素也需隨之改變使用一種常見的依賴關系，表示client元素為其完整的實現或操作而需要supplier元素提供部分實現或操作。最常見的形式是類A的某個操作的形參類型是類B，那么A依賴B。使用關系通常采用構造型?use?來表示使用的標準構造型?call?表示一個操作調用另一個操作。在表示時，這種關系往往擴大到包含操作的類：一個“源”操作調用一個“目標”操作，表示為一個“源”類中的一個操作調用了“目標”類中的某個操作。?create?說明client類元創建supplier類元的實例。?instantiate?說明在client中的某個操作創建supplier類元的實例。?responsibility?說明一個元素對其他元素提供某種約定或義務。?send?表示一個源操作發送一個信號，源是一個操作，目標是一個信號。實現概述一種特殊的抽象關系，supplier端是一組建模元素作為規范，而client端表示規范的一種實現。實現主要用于對逐步細化、優化、轉換、模板、模型合成、框架復合等進行建模。注意，實現的含義并沒有嚴格定義，而只是隱含著某建模語境更細化或更詳細的描述。如何表示實現關系？一般不用構造型，而采用虛線和三角箭頭，從實現元素指向被實現的規范元素。類型類和實現類UML模型中，被實現的規范不一定都是接口，一個類也可描述規范。?type?類被稱為“類型類”，指定某一領域的一組對象，也包括作用于這些對象上的一組操作，也可定義屬性和關聯，但未定義這些對象的物理實現。?implementationClass?類被稱為“實現類”，以某種編程語言實現，如C++、Java。對于一個類元(一般是類型類)，如果一個實現類提供了該類元定義的所有操作，而且具有類元操作所規范的相同行為，該類就實現了這個類元。一個實現類可實現多個不同的類型。類型類與實現類對依賴的討論假設類A是類B的泛化，兩者之間是否可能還有依賴關系？假設類A與類B之間存在關聯關系，兩者之間是否可能還有依賴關系？關系建模方法確定泛化關系最重要，因為它是建立概念的基礎。區分泛化和特化的不同目的。泛化的目的是提取抽象，自下而上建立一般性的概念；特化的目的是具體化，自上而下建立特殊性的概念。對泛化建模在一組類中，分析兩個和兩個以上的類的共同職責、性質和操作；抽象為一個更一般的類，并確定泛化關系；確定一般類的性質和操作。對于特化關系，一般按照以下步驟進行分析和建模：在已有的一組類中尋找最具體的一個類作為其一般類；建立該類的一個子類；確定子類特有的性質和操作；確定需要重定義的性質和操作。對關聯建模數據驅動：如果兩個類的對象之間有導航，則建立關聯。行為驅動：如果一個類需要與其它類交互，而且這種關系在交互之前就存在，則建立關聯。說明關聯的名字、關聯端的角色名字、以及多重性。若關聯的一端有明顯的整體結構，而另一端是其組成部分，則建立聚集關系。進一步確定關聯端的導向性、關聯類、限定符，以及其他修飾符。對依賴建模類A中的某操作有一個形參類型為類B，那么A依賴B。注意：依賴和泛化都是有方向的，而關聯不同。關系建模提示僅當被建模的關系不是關聯或泛化關系時，才考慮依賴關系。僅當表示“is-a-kind-of”或者“isa”關系時，才使用泛化關系。如果兩個類之間已存在泛化或關聯關系，隱含著存在依賴關系，而且不需要表示。避免可能的多重繼承，一般可用聚集來替代避免泛化的循環。因為泛化關系是有向無環圖。描述對象間的結構關系應以關聯為主。不良設計的7種現象僵硬：很難加入新功能，新加入的模塊會波及其他，而且范圍越來越大，最后不得不放棄。脆弱：與僵硬共存，修改某個地方卻導致不相關的其他地方發生故障，而且難以預料。低復用：發現某個模塊希望能被復用，進一步卻發現要依賴一大堆沒用的或不明確的東西，以至于很難把可復用部分隔離開來，最后還得放棄復用。高粘度：對設計的更改違背了原始設計的意圖和框架，僅考慮眼前利益，只做權宜之計，缺乏長遠打算，最終導致設計方案難以經受長久考驗而失敗。無端復雜性：即過度設計。設計人員試圖預測將來可能的變化，從而設計了過多的當前無用的元素，這些偶然性的元素卻導致不必要的復雜性，使軟件難以維護。無端復制：團隊中多人出于自己的目的復制了相同的代碼，而后各自修改一部分，使大量代碼重復但略有差別，當在一個地方發現bug而其它地方也存在相同bug時，卻難以集中修復。晦澀：即難以理解，不能明確表達其意圖。開始的設計往往清晰易懂，但隨著工程進行，不斷添加新功能，越來越難以理解，使軟件難以維護。面向對象設計的5個原則SOLIDSRP：TheSingleResponsibilityPrinciple，單一職責原則。一個類應僅有一個改變的理由。OCP：TheOpen/ClosedPrinciple，開閉原則。不應修改已有的類，而應擴展一個類。LSP：TheLiskovSubstitutionPrinciple，里氏替換原則。子類對象能隨時隨地替換其超類。ISP:TheInterfaceSegregationPrinciple，接口分離原則。一個客戶程序只需關注自己所需要的接口。DIP:TheDependencyInversionPrinciple，依賴倒置原則。依賴抽象而不依賴細節。單一職責原則SRP“一個設計元素只做一件事”。當你要改變一個類時，只能有一個理由開/閉原則OCP“模塊應對擴展開放，對更改關閉”“對擴展開放”。這意味著模塊的行為可擴展。當需求改變時，我們可對模塊進行擴展，使其具有滿足那些改變的新行為，使軟件具有適應性和靈活性。“對更改關閉”。對模塊行為進行擴展時，不應改動已有模塊，使軟件具有一定的穩定性和延續性。總之，當我們需要擴展新功能時，應編寫新的代碼，而不應更改已有的代碼。開/閉原則OCP（2）對于OCP原則，抽象是關鍵。對可變性進行封裝的原則(PrincipleofEncapsulationofVariation，簡稱EVP)。其核心思想是“找到系統中的可變因素，將其封裝起來”。EVP有兩個要點：一種可變性不應散落在代碼的很多角落，而應封裝到一個對象中。一種可變性與另一種可變性不能混雜在一起。里氏替換原則LSPLSP專門針對泛化關系設計的合理性。“派生類通過其基類的接口必須可用，而用戶無需知其差別”。子類型的對象必須能隨時隨地替換其基類型接口分離原則ISP為客戶程序提供盡可能“小”的單獨的接口。依賴倒置原則DIP細節應依賴抽象，而抽象不應依賴細節小結（1）關系建模是結構建模中的難點和重點。UML模型中的基本關系包括關聯、泛化和依賴。一個關聯是一組鏈(link)的抽象，每一個鏈都是一個二元組或多元組，其中每一個值都是特定類型的一個實例。關聯的命名表示了作為類元的抽象，關聯端的名字表示了關聯中各端所扮演的不同角色。關聯的多重性表示了對關聯端的定量約束。聚集是表示整體和部分概念