uml精粹——3.类图(必需)

3.类图class diagram（必需）
  一个类图描述了系统中对象的类型及他们间存在的各种静态关系static relationship。类图也展示了一个类的属性和操作properties and operations以及对象相互连接的限制。uml使用属于feature特性来表示一个类的属性和操作。
  类图中的盒子box表示类，它分成3部分：类名（粗体），属性attribute，操作operation。


【属性property】
  property属性代表一个类的结构形态，但它以两种不同的标记出现：属性attribute和联系association
【属性attribute】
  属性标记用类盒里的一个行文字描述一个属性。一个属性的完整格式是：
visibility name: type multiplicity = default {property-string}
  例子：
- name: String [1] = "Untitled" {readOnly}
  只有name是必须的。
·visibility 指明属性是public(+) or private(-)
·name 类如何称呼refer to该属性
·type 数据类型
·default value 若一个新创建的对象没有指定该属性时，使用这个值
·{property-string} 允许你指定这个attribute的附加的property，比如readOnly表示客户不能修改这个属性。如果不指定这个，表示属性可以修改。
【联系association】
  attributes:
Order
+ dateRecv: Date [0..1]
+ isPrepaid: Boolean [1]
+ lineItems: OrderLine [*] {ordered}


  associations:
Date <- Order -> Boolean
-> OrderLine
  一个联系association是两个类之间的一条实线，从源类source class指向目标类target class。属性的名字和multiplicity在联系的目标终端。联系的目标终端是属性的类型type。特殊的，联系可以在线的两端显示多重性multiplicity。
  一般，小东西的时候我使用属性attribute，比如一般的值类型。而更重要的类则用联系。


【什么时候用类图】
  建议：
·开始的时候用简单的：类，联系，属性，一般化generalization，限制constraint
·不要为所有东西画模型图，集中注意到重要的方面。


【多重性multiplicity】
  表示这个属性会被多少对象充满，最普遍的是：
·1
·0..1
·* zero or more
  更一般的，一般定义一个下限和上限，比如2..4。下限是0和正数，上限是正数或*（无限）。
  多重性的属于：
·Optional: 下限0
·Mandatory： 下限1 或更多
·Single-valued: 上限1
·Multivalued： 超过1的上限：经常是*
  如果我有一个多值的属性，我喜欢用复数命名。
  如果顺序有意义，需要在联系的末端添加{ordered}，如果允许相同，添加{nonunique}，如果想显式的显示默认值，可用{unordered}和{unique}。


【双向的联系bidirectional association】
Person <-> Car
  Car类有一个属性onwer: Person[1]，Person类有一个属性cars: Car[*]。


【操作operation】
  表示一个类要执行的动作actions that a class knows to carry out。一般你不能显示那些简单操作属性的操作，因为他们经常被推断。
  操作的完整语法是：
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为从一个类得到一个值但不改变系统状态的操作，就是没有副作用。你可以标记这种操作为{query}。我把改变状态的操作命名为modifiers，也叫命令commands。
  严格讲，query和modifiers的区别是是否改变可观察状态observable state。可观察状态是可以从外部感知到的状态。比如一个更新缓存的操作会改变内部状态，但不会影响从外部观察他。
  我觉得高亮query很有用，因为你可以改变query的执行顺序而不改变系统的行为。
  get和set方法应该算类的内部方法。
  operation是指一个对象上的过程说明，而method是一个过程的身体。当你有多态的时候这两个不同。比如一个父类有3个子类，都重写了父类的getPrice操作，则有一个operation和4个method。


【一般化generalization】  
  使用继承的一个重要的准则是可替代性。比如我有一个Customer，则我可随意用Customer的任何子类。一个类是子类型subtype，如果他是父类的替代品，不管是否用了继承。subClassing子类是普通继承的同义词。
【笔记和注释】
  可独立出现。


【依赖dependency】
  两个元素间出现依赖，如果一个元素（供应者supplier）的定义的改变 会引起另外一个元素（客户）的改变。
  类间的依赖多种：一个类发送消息给另一个；一个类作为另一个类的数据；一个类作为另一个的某个操作的参数。
  如果依赖超出控制，一个系统的每个改变都会有很大影响导致更多的改变。这样就很难做改变。
  uml允许你描述所有元素种类间的依赖。当你想显示一个元素改变之后可能怎样改变其他元素时可用依赖。
  例子（当Employee改变的时候，Window可能需要改变）：
Benefits Window - - > Employee - - > Employee Data Gateway
      - - > Benefits Data Gateway
  我发现严格的分开展示presentation和业务逻辑domain logic，让展示依赖业务而不反过来 这样很有价值。
  另外就是Window没有直接依赖Data Gateway，若这些类改变了，Employee可能会改变。但若改变只影响Employee的实现implementation，而不是接口interface，则改变停在那里。
  基本的依赖是不可传递的transitive。某些类型的依赖，比如替代substitute是可传递的。但大多数例子中，在有向和无向依赖间有一个重要的区别。
  一个子类依赖父类，但不反过来。
  可选的依赖关键字：
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可能是一个设计类，而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允许用任何东西来描述限制，唯一的规则是你要把他放到{}里。例子：
{disallow incest: husband and wife must not be siblings}