uml精粹――3.類圖(必需)

3.類圖class diagram（必須）
  1個類圖描寫了系統中對象的類型及他們間存在的各種靜態關系static relationship。類圖也展現了1個類的屬性和操作properties and operations和對象相互連接的限制。uml使用屬于feature特性來表示1個類的屬性和操作。
  類圖中的盒子box表示類，它分成3部份：類名（粗體），屬性attribute，操作operation。


【屬性property】
  property屬性代表1個類的結構形態，但它以兩種不同的標記出現：屬性attribute和聯系association
【屬性attribute】
  屬性標記用類盒里的1個行文字描寫1個屬性。1個屬性的完全格式是：
visibility name: type multiplicity = default {property-string}
  例子：
- name: String [1] = "Untitled" {readOnly}
  只有name是必須的。
?visibility 指明屬性是public(+) or private(-)
?name 類如何稱呼refer to該屬性
?type 數據類型
?default value 若1個新創建的對象沒有指定該屬性時，使用這個值
?{property-string} 允許你指定這個attribute的附加的property，比如readOnly表示客戶不能修改這個屬性。如果不指定這個，表示屬性可以修改。
【聯系association】
  attributes:
Order
+ dateRecv: Date [0..1]
+ isPrepaid: Boolean [1]
+ lineItems: OrderLine [*] {ordered}


  associations:
Date <- Order -> Boolean
-> OrderLine
  1個聯系association是兩個類之間的1條實線，從源類source class指向目標類target class。屬性的名字和multiplicity在聯系的目標終端。聯系的目標終端是屬性的類型type。特殊的，聯系可以在線的兩端顯示多重性multiplicity。
  1般，小東西的時候我使用屬性attribute，比如1般的值類型。而更重要的類則用聯系。


【甚么時候用類圖】
  建議：
?開始的時候用簡單的：類，聯系，屬性，1般化generalization，限制constraint
?不要為所有東西畫模型圖，集中注意到重要的方面。


【多重性multiplicity】
  表示這個屬性會被多少對象充滿，最普遍的是：
?1
?0..1
?* zero or more
  更1般的，1般定義1個下限和上限，比如2..4。下限是0和正數，上限是正數或*（無窮）。
  多重性的屬于：
?Optional: 下限0
?Mandatory： 下限1 或更多
?Single-valued: 上限1
?Multivalued： 超過1的上限：常常是*
  如果我有1個多值的屬性，我喜歡用復數命名。
  如果順序成心義，需要在聯系的末端添加{ordered}，如果允許相同，添加{nonunique}，如果想顯式的顯示默許值，可用{unordered}和{unique}。


【雙向的聯系bidirectional association】
Person <-> Car
  Car類有1個屬性onwer: Person[1]，Person類有1個屬性cars: Car[*]。


【操作operation】
  表示1個類要履行的動作actions that a class knows to carry out。1般你不能顯示那些簡單操作屬性的操作，由于他們常常被推斷。
  操作的完全語法是：
visibility name (parameter-list) : return-type {property-string}
?visibility public+ private-
?name
?paramet-list 操作的參數列表
?return-type 返回值的類型（如果有的話）
?property-string
  參數的格式是：
direction name: type = default value
  direction表示參數是輸入in，輸出out或輸入輸出inout，默許是in。
  例子：
+ balanceOn (date: Date) : Money
  我常常覺得辨別改變和不改變系統狀態的操作很有用。uml定義query為從1個類得到1個值但不改變系統狀態的操作，就是沒有副作用。你可以標記這類操作為{query}。我把改變狀態的操作命名為modifiers，也叫命令commands。
  嚴格講，query和modifiers的區分是是不是改變可視察狀態observable state。可視察狀態是可以從外部感知到的狀態。比如1個更新緩存的操作會改變內部狀態，但不會影響從外部視察他。
  我覺得高亮query很有用，由于你可以改變query的履行順序而不改變系統的行動。
  get和set方法應當算類的內部方法。
  operation是指1個對象上的進程說明，而method是1個進程的身體。當你有多態的時候這兩個不同。比如1個父類有3個子類，都重寫了父類的getPrice操作，則有1個operation和4個method。


【1般化generalization】  
  使用繼承的1個重要的準則是可替換性。比如我有1個Customer，則我可隨便用Customer的任何子類。1個類是子類型subtype，如果他是父類的替換品，不論是否用了繼承。subClassing子類是普通繼承的同義詞。
【筆記和注釋】
  可獨立出現。


【依賴dependency】
  兩個元素間出現依賴，如果1個元素（供應者supplier）的定義的改變 會引發另外1個元素（客戶）的改變。
  類間的依賴多種：1個類發送消息給另外一個；1個類作為另外一個類的數據；1個類作為另外一個的某個操作的參數。
  如果依賴超越控制，1個系統的每一個改變都會有很大影響致使更多的改變。這樣就很難做改變。
  uml允許你描寫所有元素種類間的依賴。當你想顯示1個元素改變以后可能怎樣改變其他元素時可用依賴。
  例子（當Employee改變的時候，Window可能需要改變）：
Benefits Window - - > Employee - - > Employee Data Gateway
      - - > Benefits Data Gateway
  我發現嚴格的分展開示presentation和業務邏輯domain logic，讓展現依賴業務而不反過來 這樣很有價值。
  另外就是Window沒有直接依賴Data Gateway，若這些類改變了，Employee可能會改變。但如果改變只影響Employee的實現implementation，而不是接口interface，則改變停在那里。
  基本的依賴是不可傳遞的transitive。某些類型的依賴，比如替換substitute是可傳遞的。但大多數例子中，在有向和無向依賴間有1個重要的區分。
  1個子類依賴父類，但不反過來。
  可選的依賴關鍵字：
call src calls an operation in the targ
create src creates instances of the targ
derive src is derived from the targ
instantiate src is an instance of the targ
permit targ allows the src to access the targ's private features
realize src is an implementation of a specification or interface defined by the targ
refine refinement indicates a relationship between different semantic levels
比如src多是1個設計類，而targ是相應的分析類analysis class
substitute src is substitutable for the targ
trace used to track such things as requirements to classes or how changes in one model
link to changes elsewhere
use src requires the targ for its implementation


【限制規則constraint rule】
  uml允許用任何東西來描寫限制，唯1的規則是你要把他放到{}里。例子：
{disallow incest: husband and wife must not be siblings}