北京umlchina实训第二天笔记

一、       类

区别分析和设计：分析是提取核心域知识，设计是添加非核心域知识

类的定义：对象具有状态、行为和标识，而类是共享一个公用结构和公用行为的对象集合

类的提取：没有寻找类的简单算法，靠分析员的头脑跨越鸿沟

一般可以阅读用例文档，抽取对应于实体或事件的词汇，将词汇分类、抽取出合适的类和属性（业务知识+建模技术）

审查类的属性是否合适：

①     属性是否直接描述类的特征（什么的什么）

②     是否有复杂结构或1对多的属性

③     属性是否对类的所有对象都有意义

类的关系：

(1)泛化：子类通过继承复用超类的特征（集合关系）

(2)关联：对象通过组装复用其他对象的特征（个体关系）

泛化：识别泛化可以采用自上而下或者自下而上，不同领域的类之间不应形成泛化关系

关联：①聚合和组合没有必要分开，识别聚合（组合）有利于在动态建模时帮助责任分配②连接

关联的注意点：关联的名字胜过多重性，类之间的关联可以有多种，关联类也要有业务意义（警惕数据库的关系表习惯），不是拥有“外键”，而是拥有“对象”

泛化与关联的选择：

•共享数据－－关联优先

•行为变异－－泛化优先

依赖：既不是泛化也不是关联的关系（尽量不要在类图上画依赖）

类关系总结：聚合/组合不是万金油，尽量用连接关系

二、       画序列图

画序列图之前已有的工作是用例文档和类图，然后通过序列图完成责任分配（此时的序列图与业务序列图不同之处是业务实体被类取代）

三种类：

       (1)边界类：用例的每个执行者映射一个边界类  责任：输入、输出、过滤

       (2)控制类（可选）：一个用例映射一个控制类   责任：控制事件流，负责为实体类分配责任

       (3)实体类：一个用例有多个实体类参与，一个实体类可以参与多个用例  责任：业务行为的主要承载体

序列图和类图的映射：消息的传入：类对象所具有的操作－－责任

                    消息的传出：类对象完成操作所需合作－－协作

序列图的绘制要点：参考ppt

责任分配的总原则：低耦合（目的：复用），高内聚（明确责任）

 耦合定义：描述设计的组成部分之间的相互依赖

 内聚定义：描述模块内各元素的紧密结合程度

责任分配的交互原则：

(1)专家原则－－资源决定消息内容

(2)老板原则－－由老板发送消息给我

(3)可视(Demeter)原则－－只发消息给朋友

判断一个设计好不好不在于能不能实现，而是看这个模型有没有抓住领域的内涵

关系三种：泛化、关联、依赖，泛化和关联是静态关系，依赖是动态关系

依赖不需要在类图上表现，可以在序列图上表示

识别是聚合还是连接不会影响系统的结构，只会界定责任分配

刚开始可以统一化成连接，在动态建模的时候再确定

业务序列图研究的范围：组织内部的系统之间

分析序列图研究的范围：开发的系统的内部之间

序列图上的箭头并不代表数据流向，而是代表责任分配

UML包含着程序员从不曾考虑的做出来的东西的卖点问题

不同领域的复杂性要分开，不要过早的把复杂性带到序列图里

三、       画状态图

状态图是把对象从所有的序列图中单独拿出来考察

状态图的要点：状态是属性值的组合（不是单一属性值决定行为）