UML风格---236条实作准则(三）

三、UML类图准则
56、确定领域类模型的职责。
57、仅在设计模型上注明可见性(visibility)。
58、用特性字符串(property string)注明依赖于语言的可见性。
59、仅当类型(type)是真正的需求时，才在分析模型中注明类型。
60、属性名和类型应该一致。
61、在分析图中对关联类建模。
62、不要对有关联类的关联命名。
63、关联类的虚线居中。
64、类名采用通用的术语。
65、推荐类名采用完整的单数名词。
66、用强动词(strong verb)为操作命名。
67、用基于领域的名词为属性命名。
68、不要对脚手架代码建模。
69、不要对关键字建模。
70、永远不要显示只有两面三刀个隔间的类。
71、标记不常见的类隔间。
72、在不完全的列表末尾包含一个省略号(...)。
73、静态操作/属性要在实例操作/属性之前列出。
74、以可见性降低的顺序列出操作/属性。
75、对于参数、如果是对象，则只列出他们的类型。
76、追求一致的操作和属性特征标记。
77、避免使用已被语言的命名规范所隐含的版型。
78、在操作的特性字符串中指明异常。
79、在接口定义中反映实现语言的约束。
80、根据语言命名规范来命名接口。
81、优先考虑用“棒棒糖”符号来表示接口的实现。
82、分开定义接口和类。
83、不要在类中建模接口的操作和属性。
84、按水平方向建模关系。
85、只有当两个建模元素之是有关系时，才对它们之间的协作建模。
86、当关系是暂时的，把关系建模为依赖。
87、如果多个关系是相似的，且是一个共同的类，则布局成树的形式。
88、始终指明多重性。
89、避免“*”这个多重性。
90、用属性类型代替关系线。
91、不要对隐含的关系建模。
92、不要对每个依赖关系都建模。
93、把名字放在关联的中间。
94、用主动语态写出简洁的关联名。
95、指明方向性以便澄清关联名。
96、以一致的方向命名单向关联。
97、按从左到右的方向命名关联名。
98、当两个类之间存在多个关联时，应指明角色名。
99、在递归关联上指明角色名。
100、只有当关联的两面三刀人方向都有协作出现时，才可以使关联是双向的。
101、只有当某些事物改变时才重画继承的关联。
102、质疑涉及最小值和最大值的多重性。
103、对继承应用语句规则(sentence rule).
104、将子类放在超类的下方。
105、小心基于数据的继承。
106、子类应该继承超类推所有内容。
107、对聚集应用语句规则(sentence rule)。
108、同时关注整体和部分。
109、把整体放在部分的左边。
110、把组合应用于物理实体的聚集。
111、当部分和整体共享持久性生命周期时，应使用组合。
112、不用担心菱形。