UML
UML又称同一建模语言或标准建模语言，是一个支持模型化和软件系统开发的图形化语言，它的作用域不仅支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
建模的意义：
模型是对现实的简化，建模是为了更好地理解系统。
*模型帮助我们按照实际情况或需求对系统可视化；（掌握不了文字，画幅画代替）；
*模型允许我们详细说明系统的结构、行为；
*模型给出了一个构造系统的模板；
*模型对我们作出的决策进行文档化。（先有文档，在有代码）
UML的特点：
*统一的标准，已经被OMG接受为标准建模语言
*面向对象，支持面向对象开发
*可视化，表示能力强
*独立于开发过程，可以适用于不同软件过程
*概要明确，表示简洁，结构清晰，容易学习掌握
一、UML的结构
*基本构造块
*规则
*公共机制
1.基本构造块
*事物（元素）thing
模型中最具代表性成分的抽象
*关系 Relationship
事物之间的联系
*图 Diagram
相关事物的集合
一、用例图（use case diagram）
描述一组用例、参与者（一种特殊的类）及它们之间的关系。用例模型描述的是外部执行者所理解的系统功能，用于需求分析阶段。
1.用例之间的关系
（1）包含（include）（是一种依赖关系，加了版型<<include>>）
*两个以上用例有共同功能，可分解到单独用例，形成包含依赖；
*箭头方向由基本用例指向被包含用例；
*执行基本用例时，每次都必须调用被包含的用例（吃放前洗手）；
*被包含用例也可以单独执行；
（2）扩展（extend）（是一种依赖关系，加了版型<<extend>>）
*如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，则可以断定将这个用例分为一个主用例和一个或多个辅用例进行描述可能更加清晰。
2.构建用例模型需要经历三个阶段
*识别参与者
*合并需求获得用例
*细化用例描述
（1）识别参与者（actor）
*参与者是系统之外与系统进行交互的任何事物，参与者可以是使用系统的用户，可以是其他外部系统、外部设备等外部实体。
*在UML中采用小人符号来表示参与者。
*参与者有主要参与者和次要参与者，开发用例的重点是要找到主要参与者。
（2）合并需求获得用例
将参与者都找到之后，接下来就是仔细地检测参与者，为每一个参与者确定用例。
其中的依据主要来源于已经取得的特征表。首先，将特征分配给相应的参与者，然后进行合并操作，最后绘制成用例图。要注意区分业务用例和系统用例。
*业务用例：是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。业务用例着重于业务操作。
*系统用例：系统用例的设计范围就是这个计算机系统设计的范围。它是一个系统参与者，与计算机系统一起实现一个目标。系统用例着重于要设计的软件系统。
（3）细化用例描述
用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流，扩展事件流）、后置条件等，其他的还可以包括非功能需求、用例优先级等。
UML又称同一建模语言或标准建模语言，是一个支持模型化和软件系统开发的图形化语言，它的作用域不仅支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
建模的意义：
模型是对现实的简化，建模是为了更好地理解系统。
*模型帮助我们按照实际情况或需求对系统可视化；（掌握不了文字，画幅画代替）；
*模型允许我们详细说明系统的结构、行为；
*模型给出了一个构造系统的模板；
*模型对我们作出的决策进行文档化。（先有文档，在有代码）
UML的特点：
*统一的标准，已经被OMG接受为标准建模语言
*面向对象，支持面向对象开发
*可视化，表示能力强
*独立于开发过程，可以适用于不同软件过程
*概要明确，表示简洁，结构清晰，容易学习掌握
一、UML的结构
*基本构造块
*规则
*公共机制
1.基本构造块
*事物（元素）thing
模型中最具代表性成分的抽象
*关系 Relationship
事物之间的联系
*图 Diagram
相关事物的集合
一、用例图（use case diagram）
描述一组用例、参与者（一种特殊的类）及它们之间的关系。用例模型描述的是外部执行者所理解的系统功能，用于需求分析阶段。
1.用例之间的关系
（1）包含（include）（是一种依赖关系，加了版型<<include>>）
*两个以上用例有共同功能，可分解到单独用例，形成包含依赖；
*箭头方向由基本用例指向被包含用例；
*执行基本用例时，每次都必须调用被包含的用例（吃放前洗手）；
*被包含用例也可以单独执行；
（2）扩展（extend）（是一种依赖关系，加了版型<<extend>>）
*如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，则可以断定将这个用例分为一个主用例和一个或多个辅用例进行描述可能更加清晰。
2.构建用例模型需要经历三个阶段
*识别参与者
*合并需求获得用例
*细化用例描述
（1）识别参与者（actor）
*参与者是系统之外与系统进行交互的任何事物，参与者可以是使用系统的用户，可以是其他外部系统、外部设备等外部实体。
*在UML中采用小人符号来表示参与者。
*参与者有主要参与者和次要参与者，开发用例的重点是要找到主要参与者。
（2）合并需求获得用例
将参与者都找到之后，接下来就是仔细地检测参与者，为每一个参与者确定用例。
其中的依据主要来源于已经取得的特征表。首先，将特征分配给相应的参与者，然后进行合并操作，最后绘制成用例图。要注意区分业务用例和系统用例。
*业务用例：是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。业务用例着重于业务操作。
*系统用例：系统用例的设计范围就是这个计算机系统设计的范围。它是一个系统参与者，与计算机系统一起实现一个目标。系统用例着重于要设计的软件系统。
（3）细化用例描述
用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流，扩展事件流）、后置条件等，其他的还可以包括非功能需求、用例优先级等。