把参与者放到用例图中，并说明与用例之间的关联 为何用例图可对系统需求建模？
需求是一个系统所需的特征、性质或行为。
一个设计良好的系统应能可预料地、可靠地完成所有需求。 大多数需求可用用例图表示
? 识别参与者来建立系统的语境
? 考虑每个参与者需求系统提供的行为。 ? 把重要的行为命名为用例 ? 分解公共行为，异常行为
? 对用例、参与者以及关联关系建模 ? 增加注解以说明非功能性需求。
用例图如何支持正向工程和逆向工程？ 用例图不能直接进行正向或逆向工程。 正向工程Forward Engineering 用例图作为设计和测试的指南。 良好的用例可说明前置条件和后置条件，可定义测试的初态和成功的标准。 逆向工程Reverse Engineering 只能手工进行。
3 基本结构建模：类和类图
3.1 类
如何对类命名？
命名(name) 简单名，路径：包名::子包::类名 语义：被建模系统的词汇表中提取出来的名词或名词短语。 语法：字符、数字及其它符号构成的字符串，首字符大写。 属性是什么？如何确定类的属性？
属性(attribute)：对类中每个对象所包含的某一种数据或状态的抽象。 一个对象在特定时刻在每个属性上都有确定值。 语义：表示类的特征的名词或名词短语。 语法：可仅表示属性名，也可详细描述：类型、缺省值等。 属性名[：类型[ = 缺省值]] 首字符小写，而后面其它词的首字符大写。 操作是什么？如何确定类的操作？
操作(operation)：该类所有对象所能做的事情的抽象。
调用操作可改变对象的数据或状态，或可访问对象内部的数据或状态。
语义：表示类的特征的动词或动词短语。 语法：操作名，首字符小写，而后面其它词的首字符大写 visibility name ( parameter-list ) : return-type-expression { property-string }
每个操作在类中唯一基调(signature)。每个参量的格式： kind name : type-expression = default-value
构造型<
类的职责是什么？如何表示？
职责(responsibility) 一个类的一项约定(contract)或一项义务(obligation)。
从更高抽象角度看，属性和操作是完成职责的特征。每个类至少有一项职责。 细化模型时类的各项职责要转化为完成职责的属性和操作。
相关技术：CRC(Class-Responsibilities-Collaborators)卡片和基于用例的分析 语法：注释，自由文本(短语、单句、短文)，类底部框中，注解方式。
接口是什么？如何表示？
接口interface，一组操作的一个命名的集合，表示某些元素的行为特征。 接口描述行为规范，但不描述行为如何实现。由一组类提供接口的实现。 类可实现接口，即根据操作的基调，提供具体的实现方法method。
语法：圆圈；方框(可描述各操作的基调signature)。 如何对类进行建模？
如何组织属性和操作？
可省略；可用构造型(stereotype)分组。
如何对系统的词汇建模？
? 识别描述问题和解决方案的事物，用CRC或用例来发掘。
? 识别每个抽象的职责集合，确切定义每个类，且使职责在类之间均衡。 ? 确定为实现每个类的职责所需的属性和操作。
如何对系统中的职责分布建模？ 均衡的职责分布，每个类应做好一件事。
? 识别为完成某些行为而紧密协同工作的一组类。 ? 对每个类识别其职责。
? 整体上审查各类职责，职责过多应分解，过少则应合并，重新分配职责。 ? 从类之间协作的角度，重新分配各自职责。
如何对非软件事物进行建模？ 并非所有抽象都对应软件的实现。扮演特定角色的人和硬件也能抽象为类。
? 广泛抽象，描述其职责和特征。
? 可使用构造型(stereotype)来使其详细描述和可视化。 ? 对包含软件的硬件，可建模为节点(node)。
如何对初等/简单类型进行建模？ 编程语言中的简单类型，如char, int, float, String，以及自定义枚举类型等
? 可用构造型来描述。
? 可用约束来描述值的范围（值域）
提示
对最终用户或软件实现者，每个类都应该映射到某个真实的或概念上的抽象。 如何建立一个结构良好的类？
? 对来自问题域和方案域的词汇所表示的事物进行明确抽象。 ? 嵌入一个较小的、但明确定义的职责集合，并能很好实现。 ? 把抽象的规格说明和具体的实现过程明确分开。 ? 简单、易理解、可适应性、可扩展性。
3.2 关系
类之间主要有哪些关系？ 依赖、泛化和关联。
依赖是什么？如何对依赖关系建模？
依赖(dependence) 区分独立元素(被依赖元素)和依赖元素。 语法：虚线箭头从依赖元素到独立元素。可命名。 语义：通常指行为上的依赖，确定独立元素的某个操作的基调，use关系。 泛化是什么？如何对泛化关系建模？
泛化(generalization) 区分较一般的元素(超类)和较特殊的元素(子类)。 语法：实线空心箭头从子类到超类，不命名 语义：子类is-a-kind-of超类。
子类对象可替代超类对象；
子类继承超类特征且可增加新特征；
子类操作的基调与超类相同时，子类可改写(override)超类的实现。 根类/基类----叶子类 单继承---多继承
关联是什么？如何对关联建模？
关联(association) 对象间结构关系，导航方向。 二元Binary关联、n元(n-ary)关联 语法：实线连接加说明 命名：名称及方向，区分多个关联的性质(关联的角色)。 角色role：关联中的一方对于另一方的职责的识别和命名 多重性multiplicity：对象之间定量的结构关系。 聚集aggregation：表示部分和整体关系。Has-A 空心菱形 共享聚集和复合聚集
复合composite：实心菱形
注意：依赖和关联是自反的，而泛化则反自反。
如何对关系进行建模？
如何对简单依赖进行建模？ 类A中的某操作的基调包含另一个类B作为参量类型。 如何对继承建模？
1. 在一组类中两个和两个以上类的共同职责、属性和操作 2. 抽象为一个更一般的类，或建立新类 3. 确定泛化关系
注意：区别抽象类(斜体表示)和具体类。 什么是抽象类？什么是具体类？ 不能直接实例化的类为抽象类；可直接实例化的类是具体类。 一个抽象类往往是若干具体类的抽象，以管理这些具体类的共同特征。 如何对结构关系建模？ 注意：依赖和泛化都是单方向的，而关联大多是多方向的。
? 数据驱动：若一对类之间有导航，则建立关联。 ? 行为驱动：若需与其它类交互，不作为操作参量且在交互前存在，则建立关联。 ? 说明关联的名字、多重性和角色。
? 若关联的一端有明显的整体结构或组织，而另一端是部分，则聚合。
提示：
? ? ? ? ? ?
仅当被建模关系不是结构关系时，才考虑依赖关系。 仅当is-a-kind-of，才使用泛化关系。
避免可能的多继承，一般可用聚合代替多继承。 避免泛化的循环。
保持泛化关系的平衡。深度和宽度。 描述对象间的结构关系应以关联为主。
3.3 公共机制
公共扩展机制General Extension Mechanism是什么? 注解、构造型、标记值、约束。 注解是什么？如何表示？
注解note: 包含文字信息的一种图形符号。
一种修饰，以说明更多语义(约束、注释、方法体、标记值等)。
除note外还有其它修饰。如描述类的职责所用的附加栏。表示方法。
构造型stereotype是什么？
从效果看，一个构造型是在建模时引入的元模型元素的一种新类。 表示一个已有元模型元素的一个子类，与其具有相同形式(属性和关系)，但有不同用意。 可附加约束或标记值tagged value。 UML的一种内置的扩展机制。 表示方法：<
语义：可看作为元数据，做用于类本身，而不是类的每个实例。 详述与代码生成或配置管理相关的特性。如编程语言、作者、版本、日期等。 语法：{标记tag=值value；……} 约束constraint是什么？ 某种语义条件或限制。
语法：{文本 / OCL, Object Constraint Language}
如何使用公共机制进行建模？ 如何对注释建模？
? 建立注释，连接到元素。
? 使用工具时，可能选择隐藏注释
? 长文本或更复杂的内容，可连接到外部文档。 ? 模型演化，注释也变化
如何对新构造单元建模？ 先确认基本UML元素和已提供标准构造型能否表达一种新事物。 选择一个基本UML事物，与你的事物特征最相近，命名建立一个构造型。 构造型可能具有一定的泛化层次。 对构造型定义标记值和约束，以规范其特征和语义。 定义一个新图标，以清晰形象地表示。 如何对新特征建模？ 构造单位的基本特征若不能表达，需要用标记值扩展基本构造单位的特征。
先确认基本UML构造单位和标准标记值是否要求。 对基本UML构造单位或构造型增加新特征。 为一种元素定义的标记值，将扩展到它的子孙。 如何对新语义建模？ 先确认基本UML语义无法表达或需修改UML规则，且标准约束也无法表达。 以约束形式把新的语义写成文本，用依赖把约束连接到相应元素上。 更精确更形式化的描述，用OCL。 提示 注解 仅用注解表示UML不能表达的情形，如需求、观察资料、评论和解释。 把注解作为一种电子粘贴便笺，以便跟踪工作进展 扩展 项目中构造型、标记值和约束的标准化，应避免过多过滥的扩展。 为构造型、标记值选择简短有意义的名称。
3.4 类图
类图是什么？
表示一组类、接口、协作、依赖、泛化和关联关系，注解和约束。 类图中可有包或子系统，用于将模型元素进行分组。 类图中可表示实例。 用法：
? 对系统的词汇建模
? 对简单协作建模。类不是单独存在，要与其它类协作以完成更强功能。 ? 对数据库模式建模
如何对简单协作建模？
每个类图应注重表达一种协作关系
? 识别被建模的机制。一种机制描述了部分系统的功能和行为，需要群体内交互。 ? 对每种机制，识别参与协作的类、接口及其它协作，识别其间关系。 ? 用剧情scenario排演这些协作，以发现遗漏和错误。
? 建立元素间关系，聚集起来，职责平衡，逐渐转换为具体属性和操作。 如何对数据库模式建模？
永久对象，关系数据库/混合式数据库，类图是ER图超集。
行为：可实现为存储过程或触发器 ? 识别永久对象
? 建立类图，标注为{persistent}，UML标准标记值 ? 展开结构细节，属性，关联和多重性，限制泛化 ? 简化设计，建立中间抽象逻辑。
? 展开行为细节，维护内部数据存储完整性，业务规则更上一层。 ? 可使用工具，转为物理设计。
正向工程和逆向工程
模型与软件之间相匹配，且保持同步的代价应最小，甚至取消。 UML->OOPL(Java/C++/ObjectPascal/Smalltalk…) 正向工程Forward Engineering 模型到代码的过程，UML到编程语言的过程。信息损失，如协作、交互