北京umlchina实训第二天笔记
一、 类
区别分析和设计：分析是提取核心域知识，设计是添加非核心域知识
类的定义：对象具有状态、行为和标识，而类是共享一个公用结构和公用行为的对象集合
类的提取：没有寻找类的简单算法，靠分析员的头脑跨越鸿沟
一般可以阅读用例文档，抽取对应于实体或事件的词汇，将词汇分类、抽取出合适的类和属性（业务知识+建模技术）
审查类的属性是否合适：
① 属性是否直接描述类的特征（什么的什么）
② 是否有复杂结构或1对多的属性
③ 属性是否对类的所有对象都有意义
类的关系：
(1)泛化：子类通过继承复用超类的特征（集合关系）
(2)关联：对象通过组装复用其他对象的特征（个体关系）
泛化：识别泛化可以采用自上而下或者自下而上，不同领域的类之间不应形成泛化关系
关联：①聚合和组合没有必要分开，识别聚合（组合）有利于在动态建模时帮助责任分配②连接
关联的注意点：关联的名字胜过多重性，类之间的关联可以有多种，关联类也要有业务意义（警惕数据库的关系表习惯），不是拥有“外键”，而是拥有“对象”
泛化与关联的选择：
•共享数据－－关联优先
•行为变异－－泛化优先
依赖：既不是泛化也不是关联的关系（尽量不要在类图上画依赖）
类关系总结：聚合/组合不是万金油，尽量用连接关系
二、 画序列图
画序列图之前已有的工作是用例文档和类图，然后通过序列图完成责任分配（此时的序列图与业务序列图不同之处是业务实体被类取代）
三种类：
(1)边界类：用例的每个执行者映射一个边界类 责任：输入、输出、过滤
(2)控制类（可选）：一个用例映射一个控制类 责任：控制事件流，负责为实体类分配责任
(3)实体类：一个用例有多个实体类参与，一个实体类可以参与多个用例 责任：业务行为的主要承载体
序列图和类图的映射：消息的传入：类对象所具有的操作－－责任
消息的传出：类对象完成操作所需合作－－协作
序列图的绘制要点：参考ppt
责任分配的总原则：低耦合（目的：复用），高内聚（明确责任）
耦合定义：描述设计的组成部分之间的相互依赖
内聚定义：描述模块内各元素的紧密结合程度
责任分配的交互原则：
(1)专家原则－－资源决定消息内容
(2)老板原则－－由老板发送消息给我
(3)可视(Demeter)原则－－只发消息给朋友
判断一个设计好不好不在于能不能实现，而是看这个模型有没有抓住领域的内涵
关系三种：泛化、关联、依赖，泛化和关联是静态关系，依赖是动态关系
依赖不需要在类图上表现，可以在序列图上表示
识别是聚合还是连接不会影响系统的结构，只会界定责任分配
刚开始可以统一化成连接，在动态建模的时候再确定
业务序列图研究的范围：组织内部的系统之间
分析序列图研究的范围：开发的系统的内部之间
序列图上的箭头并不代表数据流向，而是代表责任分配
UML包含着程序员从不曾考虑的做出来的东西的卖点问题
不同领域的复杂性要分开，不要过早的把复杂性带到序列图里
三、 画状态图
状态图是把对象从所有的序列图中单独拿出来考察
状态图的要点：状态是属性值的组合（不是单一属性值决定行为）