UML::UML核心元素

我对UML的理解：软件工程的东西。（有点模糊，不是很懂。）

 

建模：个人理解——对现实的一种抽象，对现实的简化，模型比现实更好理解。即是抽象。

 

UML核心元素：

版型(stereotype)：版型也称类型、构造型，它是对一个UML元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。版型只是UML对的一种扩展手段，本身并不涉及太多的思想和方法，而是在建模的不同阶段，为了区分视图之间的而不同观点，会采用不同的图示来表示。（不懂，能用C++中的typename理解吗?）

 

参与者（actor）：在建模过程中处于核心地位，官方文档的定义：actor是在系统之外与系统交互的某人或事物。业务主角(business actor)是参与者的一个版型。参与者可以有多个。（参与者主角？业务工人配角？）

 

用例（Use Case）：建模中最最重要的一个元素，除了用例之外，其他所有元素都是“封装”的，“独立”的那些元素在没有“外力”的情况下，“老死不相往来”，用例就是施加这一“外力”的元素。所谓用例，就是一件事情，要完成这件事情，需要一系列活动。（体现系统参与者的愿望。）

 

边界：略。

 

业务实体：业务实体是类（class）的一种版型。官方文档的定义：业务实体代表业务角色执行业务用例时所处理或使用的“事物”。例如，饭店中的业务实体有菜单和饮料。（具体的事物。）

 

 

    包：包是一种容器，如同文件夹一样，将某些信息分类，形成逻辑单元。可以自定义需要的版型，从特定角度分类元素，包是UML中随意性最大的，好包将帮助你更好地组织元素。（元素如其名）

 

    分析类:分析类代表系统中主要的“职责簇”，意味着分析类是从功能性需求向计算机实现转化过程的“第一个关口”，分析类可以产生系统的设计类和子系统，意味着计算机实现时可以通过某种途径“产生”出来的，而不是拍脑袋出来的，分为边界类，控制类，实体类。

    ——边界类：用于对系统外部环境与其内部运作之间的交互进行建模的类。现实世界中，边界类实例可以是：窗口、通信协议、打印机接口、传感器、终端。计算机世界里，边界类可以使一个消息中间件，一个驱动程序，一组对象接口甚至任意一个类。参与者与用例之间应当建立边界类。用例与用例之间如何有交互，应当建立边界类。

    ——控制类：也就是说，控制类来源于对用例场景中动词的分析和定义。UML定义中，控制类主要起协调对象的作用，如从边界类通过控制类访问实体类，或者实体类通过控制类访问另一个实体类。

    ——实体类：实体类用于对必须存储的信息和相关行为建模的类出于系统结构优化需要，一些业务实体可以在后续的过程中被分拆、合并。

 

设计类：设计类是系统实施中一个或者多个对象的抽象，设计类已经直接映射到实现代码，设计类依赖于实现语言设计类来源于前期的系统分析，类不是凭空想出来的，可以一一映射到前期系统分析的成果物上。（class）

 

关系:在UML中，关系是重要的语义。(用各箭头表示)

 

组件:组件是系统实际存在的可更换部分，它实现特定的功能，符合一套接口标准并实现一组接口。组件代表系统中的一部分物理实施，包括软件代码（源代码、二进制代码或可执行代码）或其等价物（如脚本或命令文件）。

 

节点：略。