1. 參与者(Actor)
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2. 用例(Use Case)
用例就是外部可见的系统功能，对系统提供的服务进行描写叙述。用椭圆表示。
3. 子系统(Subsystem)
用来展示系统的一部分功能，这部分功能联系紧密。
4. 关系
用例图中涉及的关系有：关联、泛化、包括、扩展。
例如以下表所看到的：
a. 关联(Association)
表示參与者与用例之间的通信，不论什么一方都可发送或接受消息。
【箭头指向】：指向消息接收方
b. 泛化(Inheritance)
就是通常理解的继承关系。子用例和父用例相似。但表现出更特别的行为；子用例将继承父用例的全部结构、行为和关系。
子用例能够使用父用例的一段行为，也能够重载它。
父用例一般是抽象的。
【箭头指向】：指向父用例
c. 包括(Include)
包括关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】：指向分解出来的功能用例
d. 扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
【箭头指向】：指向基础用例
e. 依赖(Dependency)（不考）
以上4种关系。是UML定义的标准关系。
但VS2010的用例模型图中。加入了依赖关系。用带箭头的虚线表示，表示源用例依赖于目标用例。
【箭头指向】：指向被依赖项
一个用例图演示样例：
1、活动状态图（Activity）
活动状态用于表达状态机中的非原子的执行。其特点例如以下：
(1)、活动状态能够分解成其它子活动或者动作状态。
(2)、活动状态的内部活动能够用还有一个活动图来表示。
(3)、和动作状态不同，活动状态能够有入口动作和出口动作。也能够有内部转移。
(4)、动作状态是活动状态的一个特例，假设某个活动状态仅仅包含一个动作，那么它就是一个动作状态。
UML中活动状态和动作状态的图标同样。可是活动状态能够在图标中给出入口动作和出口动作等信息。
2、动作状态（Actions）
动作状态是指原子的，不可中断的动作，并在此动作完毕后通过完毕转换转向还有一个状态。动作状态有例如以下特点：
(1)、动作状态是原子的，它是构造活动图的最小单位。
(2)、动作状态是不可中断的。
(3)、动作状态是瞬时的行为。
(4)、动作状态能够有入转换。入转换既能够是动作流。也能够是对象流。动作状态至少有一条出转换，这条转换以内部的完毕为起点，与外部事件无关。
(5)、动作状态与状态图中的状态不同，它不能有入口动作和出口动作，更不能有内部转移。
(6)、在一张活动图中。动作状态同意多处出现。
UML中的动作状态图用平滑的圆角矩形表示。例如以下：
3、动作状态约束（Action Constraints）
动作状态约束：用来约束动作状态。例如以下图展示了动作状态的前置条件和后置条件
4、动作流（Control Flow）
动作之间的转换称之为动作流，活动图的转换用带箭头的直线表示，箭头的方向指向转入的方向。
開始节点：表示成实心黑色圆点
6、终止节点（Final Node）
分为活动终止节点（activity final nodes）和流程终止节点（flow final nodes）。
活动终止节点表示整个活动的结束
而流程终止节点表示是子流程的结束。
7、对象（Objects）
8、数据存储对象（DataStore）
使用keyword«datastore»
9、对象流（Object Flows）
对象流是动作状态或者活动状态与对象之间的依赖关系，表示动作使用对象或动作对对象的影响。
用活动图描写叙述某个对象时，能够把涉及到的对象放置在活动图中并用一个依赖将其连接到进行创建、改动和撤销的动作状态或者活动状态上。对象的这样的用法就构成了对象流。
对象流中的对象有下面特点：
(1)、一个对象能够由多个动作操作。
(2)、一个动作输出的对象能够作为还有一个动作输入的对象。
(3)、在活动图中，同一个对象能够多次出现，它的每一次出现表面该对象正处于对象生存期的不同一时候间点。
对象流用带有箭头的虚线表示。假设箭头是从动作状态出发指向对象，则表示动作对对象施加了一定的影响。施加的影响包含创建、改动和撤销等。
假设箭头从对象指向动作状态，则表示该动作使用对象流所指向的对象。
状态图中的对象用矩形表示，矩形内是该对象的名称，名称下的方括号表明对象此时的状态。
10、分支与合并（Decision and Merge Nodes）
分支与合并用菱形表示
11、分叉与汇合（Fork and Join Nodes）
分为水平风向和垂直方向。
对象在执行时可能会存在两个或多个并发执行的控制流。为了对并发的控制流建模，UML中引入了分叉与汇合的概念。分叉用于将动作流分为两个或多个并发执行的分支。而汇合则用于同步这些并发分支。以达到共同完毕一项事务的目的。
当受保护的活动发生异常时。触发异常处理节点。
13、活动中断区域（Interruptible Activity Region）
活动中断区域环绕一些可被中断的动作状态图。比方下图，正常情况下【Process Order】顺序流转到【Close Order】。订单处理流程完成。但在【Process Order】过称中，会发送【Cancel Order】请求，这时会流转到【Cancel Order】，从而订单处理流程结束
14、泳道（Partition）
泳道将活动图中的活动划分为若干组。并把每一组指定给负责这组活动的业务组织。即对象。在活动图中，泳道区分了负责活动的对象，它明白地表示了哪些活动是由哪些对象进行的。
在包括泳道的活动图中，每一个活动仅仅能明白地属于一个泳道。
泳道是用垂直实线绘出。垂直线分隔的区域就是泳道。在泳道的上方能够给出泳道的名字或对象的名字，该对象负责泳道内的所有活动。
泳道没有顺序，不同泳道中的活动既能够顺序进行也能够并发进行，动作流和对象流同意穿越分隔线。
二、活动图案例分析
1、 泳道分为：会员泳道和系统泳道。
会员选择商品并增加购物车，系统完毕订单生成及其支付完毕。
2、 開始节点：会员加入商品到购物车。点击【订单确认】。開始交于系统处理订单流程3、 结束节点：商品发送完成和付款成功，订单处理流程结束
4、 活动状态：产生订单、Check Credit Cart核对信用卡、Check Stock 核对库存量、Deliver Goods 发送商品、Process Credit Cart付款
5、 分叉与汇合：【产生订单】份叉为检查库存量和会员支付金额是否足够，假设不足。取消订单。如过库存量和支付金额足够，发送商品和付款。最后汇合为订单完毕。
状态图
一、状态图简单介绍（Brief introduction）
状态图（Statechart Diagram）主要用于描写叙述一个对象在其生存期间的动态行为，表现为一个对象所经历的状态序列，引起状态转移的事件（Event），以及因状态转移而伴随的动作（Action）。一般能够用状态机对一个对象的生命周期建模，状态图用于显示状态机（State Machine Diagram）。重点在与描写叙述状态图的控制流。
例如以下图样例，状态机描写叙述了门对象的生存期间的状态序列，引起转移的事件，以及因状态转移而伴随的动作（Action）.
状态有Opened、Closed、Locked。
事件有 Open、Close、Lock和Unlock。
注意：
1、 并非全部的事件都会引起状态的转移。比方当门是处于【Opened】状态，不能进行【Lock】事件。
2、 转移（Transition）有警备条件（guard condition），比方仅仅有doorWay->isEmpty 条件满足时。才会响应事件。
二、状态图元素（State Diagram Elements）
1、状态（States）
指在对象的生命周期中的某个条件或者状况。在此期间对象将满足某些条件、运行某些活动活活等待某些事件。
全部对象都有状态，状态是对象运行了一系列活动的结果，当某个事件发生后，对象的状态将发生变化。
状态用圆角矩形表示
初态和终态（Initial and Final States）
初态用实心圆点表示，终态用圆形内嵌圆点表示。
2、转移（Transitions）
转移（Transitions）是两个状态之间的一种关系，表示对象将在源状态（Source State）中运行一定的动作，并在某个特定事件发生并且某个特定的警界条件满足时进入目标状态（Target State）
事件标记（Trigger）：是转移的诱因，能够是一个信号。事件、条件变化（a change in some condition）和时间表达式。
警界条件（Guard Condition）：当警界条件满足时，事件才会引发转移（Transition）。
结果（Effect）：对象状态转移后的结果。
3、动作（State Actions）
动作（Actions）是一个可运行的原子操作,也就是说动作是不可中断的，其运行时间是可忽略不计的。
在上例中，对象状态转移后的结果显示在转移线上。假设目标状态有很多转移，并且每一个转移有同样的结果。这时把转移后的结果（Effect）展示在目标状态中（Target State）更好一些。能够定义进入动作（Entry Action ）和退出动作（Exit Action），例如以下图
4、自身转移（Self-Transitions）
状态能够有返回自身状态的转移，称之为自身转移（Self-Transitions）
5、组合状态（Compound States）
嵌套在另外一个状态中的状态称之为子状态（sub-state）,一个含有子状态的状态被称作组合状态（Compound States）. 例如以下图，【Check PIN】是组合状态，【Enter PIN】是子状态。
也可用下面方式进行描写叙述
如上图，状态机【Check PIN】的细节被切割到另外一个图中了。
6、进入节点（Entry Point）
例如以下图所看到的，因为一些原因并不会运行初始化（initialization），而是直接通过一个节点进入状态【Ready】，则此节点称之为进入节点（Entry Point）
7、退出节点（Exit Point）
8、历史状态（History States）
历史状态是一个伪状态（Pseudostate）,其目的是记住从组合状态中退出时所处的子状态，当再次进入组合状态，可直接进入这个子状态，而不是再次从组合状态的初态開始。
在上图的状态图中。正常的状态顺序是:【Washing】- >【Rinsing】->【Spinning】。
假设是从状态【Rinsing】突然停电（Power Cut）退出，,洗衣机停止工作进入状态【Power Off】，当电力恢复时直接进入状态【Running】。
9、并发区域（Concurrent Regions）
状态图能够分为区域，而区域又包含退出或者当前运行的子状态。
说明组合状态在某一时刻能够同一时候达到多个子状态。例如以下图刹车系统，同一时候进入前刹车【Applying Front Brakes】状态和后刹车【Applying Rear Brakes】状态。
三、状态图案例分析（State Diagram Example Analysis）
依照blink518的建议（“出货中”是属于条件分支应该使用Decision），改成例如以下图也是非常好的做法：
订单成立状态主要有：
订单成立
订单取消（Guard:会员订单-缴款期限已过期）
备货中（Guard:已付款、订单成立、库存量足够）
出货中（Effect:扣除商品可接单量及移除购物车中的购买资料）
出货确认（Guard:实际配达日及发票代码、号码均不为空值）
出货完成（Guard:实际配达日不为空）
出货失败
订单成立（Guard:出货完成，已付款、鉴赏期结束日期 小于等于 [系统日期]）
状态图和活动图的差别
状态图是描写叙述某一对象的状态转化的。它主要表现的是该对象的状态。从状态图中能够看出，该对象在接受了外界的某种刺激之后，会做出什么样的反应。
描写叙述的是一个对象的事情。能够说是对类图的一种补充。帮助开发人员完好某一类。
活动图是描写叙述系统在运行某一用例时的详细步骤的。它主要表现的是系统的动作。
从活动图中能够看出，系统是怎样一步一步的完毕用例规约的。主要用于业务建模阶段。活动图描写叙述的是整个系统的事情。能够说活动图是对用例图的一种细化，帮助开发人员理解业务领域。
比方说：
学校用的学生选课系统。
在系统中。学生是一个对象（UML中的对象，不是编程语言中的对象），那么学生“未登录”“已登录”“未完毕选课”“已完毕选课”“已选XX课”“未选XX课”等都是学生的状态。描写叙述这些状态之间是怎样转化的。就要用状态图。
而学生选课的这个动作涉及到：学生、课程、教师、学生课表等多个对象。同一时候这个动作也是学生选课系统的一个用例，所以要描写叙述它就要用到活动图。
顺序图（时序图）
一、时序图简单介绍（Brief introduction）
二、时序图元素（Sequence Diagram Elements）
角色（Actor）
对象（Object）
生命线（Lifeline）
控制焦点（Focus of Control）
消息（Message）
自关联消息（Self-Message）
Combined Fragments
三、时序图实例分析（Sequece Diagram Example Analysis）
时序图场景
时序图实例
时序图实例分析
四、总结（Summary）
一、时序图简单介绍（Brief introduction）
时序图（Sequence Diagram）是显示对象之间交互的图。这些对象是按时间顺序排列的。顺序图中显示的是參与交互的对象及其对象之间消息交互的顺序。
时序图中包含的建模元素主要有：对象（Actor）、生命线（Lifeline）、控制焦点（Focus of control）、消息（Message）等等。
二、时序图元素（Sequence Diagram Elements）
角色（Actor）
系统角色，能够是人、及其甚至其它的系统或者子系统。
对象（Object）
对象包含三种命名方式：
第一种方式包含对象名和类名；
第二中方式仅仅显示类名不显示对象名，即表示他是一个匿名对象。
第三种方式仅仅显示对象名不显示类明。
生命线（Lifeline）
生命线在顺序图中表示为从对象图标向下延伸的一条虚线。表示对象存在的时间，例如以下图
控制焦点（Focus of Control）
控制焦点是顺序图中表示时间段的符号，在这个时间段内对象将运行对应的操作。用小矩形表示，例如以下图。
消息（Message）
消息一般分为同步消息（Synchronous Message），异步消息（Asynchronous Message）和返回消息（Return Message）.例如以下图所看到的：
同步消息=调用消息（Synchronous Message）
消息的发送者把控制传递给消息的接收者。然后停止活动，等待消息的接收者放弃或者返回控制。用来表示同步的意义。
异步消息（Asynchronous Message）
消息发送者通过消息把信号传递给消息的接收者，然后继续自己的活动。不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。
返回消息（Return Message）
返回消息表示从过程调用返回
自关联消息（Self-Message）
表示方法的自身调用以及一个对象内的一个方法调用另外一个方法。
Combined Fragments
➢ Alternative fragment（denoted “alt”） 与 if…then…else相应
➢ Option fragment (denoted “opt”) 与 Switch相应
➢ Parallel fragment (denoted “par”) 表示同一时候发生
➢ Loop fragment(denoted “loop”) 与 for 或者 Foreach相应
三、时序图实例分析（Sequece Diagram Example Analysis）
时序图场景
完毕课程创建功能，主要流程有：
1、请求加入课程页面，填写课程表单。点击【create】button
2、加入课程信息到数据库
3、向课程对象追加主题信息
4、为课程指派教师
5、完毕课程创建功能
时序图实例
时序图实例分析
1、序号1.0-1.3 完毕页面的初始化
2、序号1.4-1.5 课程管理员填充课程表单
3、序号1.6-1.7 课程管理员点击【Create】button，并响应点击事件
4、序号1.8 Service层创建课程
5、序号1.9-1.10 加入课程到数据库。并返回课程编号CourseId
6、序号1.11-1.12 加入课程主题到数据库，并返回主题编号topicId
7、序号1.13 给课程指派教师
8、序号1.14 向界面抛创建课程成功与否的消息
在UML的建模机制中。模型的组织是通过包来实现的。
包把建立的各种模型组织起来，形成各种功能或用途的模块，并能够控制包中元素的可见性以及描写叙述包之间的依赖关系。通过这样的方式，系统模型的实现者可在高层把握系统的结构。
包图是一种维护和描写叙述系统整体结构的模型的重要建模工具。通过对包中各个包以及包之间关系的描写叙述，展现出系统的模块与模块之间的依赖关系。
包图由两个矩形表示（单选项卡），包图名称写在大矩形中间。除包名外，还有元素，元素可见性，包构造型及包间的关系组成。
在包下能够创建各种模型元素：类。接口。构件。节点。用例，图以及其他包。
包图的作用
包图能够描写叙述需求。设计的高阶概况；包图通过合理规划自身功能反应系统的高层架构，在逻辑上将系统进行模块化分解。包图终于是组织源代码的方式。
例：
构件图提供系统物理视图。在一个很高的层次上显示系统中的构件与构件之间的依赖关系。
将系统中可重用的模块封装为具有可替代性的物理单元，就是构件。
它是一个系统或子系统中的封装单元。提供一个或多个接口，是系统高层的可重用部件。构件作为系统中的一个物理实现单元。包含：软件代码（源代码，二进制代码，可运行文件，脚本，命令行等），带有身份标识而且有物理实体的文件（文档，数据库）。
标准构件用左边有两个小矩形的大矩形表示。构件名在大矩形内部。
构件有不同的类型。
构件图是用来表示系统中构件与构件之间，类或接口与构件之间的关系图。当中。构建图之间的关系表现为依赖关系，定义的类或接口与类之间的关系表现为依赖关系或实现关系。
例：（astah中的构件图与rational rose2003中的不同）
部署图描写叙述了一个系统执行时的硬件节点。在这些节点上执行的软件构件将在何处物理执行以及它们将怎样彼此通信的静态视图。
部署图包含两种基本模型元素：节点和节点间的连接。
每一个模型中，仅包含一个部署图。节点包含两种类型：处理器和设备。
处理器指本身具有计算能力且能运行各各软件的节点，如server。处理器具有处理能力，所以在描写叙述处理器方面应当包括了处理器的调度和进程。调度指在处理器处理其进程中为实现一定的目的而对共同使用的资源进行时间分配。调度方式包括：抢占。无优先级。循环，算法控制，手动运行。进程表示一个单独的控制纯种，是系统中一个重量级的并发和运行单元。
设备指本身不具备处理能力的节点，如打印机。
连接用来表示两个节点之间的硬件连接。
节点之间的连接能够通过光缆直接进行。或通过卫星等方式非直接连接。通常连接都是双向的。
连接用实线表示。实线上可加连接名和构造型。
系统开发者和部署人员能够利用部署图去了解系统的物理执行情况。假设，开发的软件系统仅仅需在一台计算机上执行，且使用的标准设备，则不须要为它画出系统部署图。
部署图仅仅须要给那些复杂的物理执行情况进行建模。
部署图显示了系统的硬件，安装在硬件上的软件，用于连接硬件的各种协议和中间件等。
部署模型的目的：
描写叙述一个详细应用的主要部署结构。通过对各种硬件。在硬件中的软件以及各种连接协议的显示，能够非常好的描写叙述系统是怎样部署的；平衡系统执行时的计算资源分布。能够通过连接描写叙述组织的硬件网络结构或者是嵌入式系统等具有多种硬件和软件相关的系统执行模型。
例：（astah中部署图）
类图
一、简单介绍
二、类的构成
三、类之间的关系（Relationship）
1、单向关联
2、双向关联
3、自身关联
4、多维关联(N-ary Association)
5、泛化(Generalization)
6、依赖(Dependency)
7、聚合(Aggregation)
8、组合（Composite）
四、总结
一、简单介绍
类是对象的集合，展示了对象的结构以及与系统的交互行为。类主要有属性（Attribute）和方法（Method）构成,属性代表对象的状态，假设属性被保存到数据库。此称之为“持久化”；方法代表对象的操作行为，类具有继承关系。能够继承于父类，也能够与其它的Class进行交互。
类图展示了系统的逻辑结构，类和接口的关系。
二、类的构成
类主要有属性和方法构成。比方商品属性有：名称、价格、高度、宽度等。商品的方法有：计算税率，获得商品的评价等等。例如以下图
三、类之间的关系（Relationship）
关联(Association)
两个相对独立的对象，当一个对象的实例与另外一个对象的特定实例存在固定关系时。这两个对象之间就存在关联关系。
1、单向关联
A1->A2: 表示A1认识A2，A1知道A2的存在。A1能够调用A2中的方法和属性
场景：订单和商品。订单中包含商品。可是商品并不了解订单的存在。
类与类之间的单向关联图:
C#代码:
Public class Order
{
Public List<Product> order;
Public void AddOrder(Product product )
{
order.Add(product);
}
}
Public Class Product
{
}
代码表现为：Order(A1)中有Product(A2)的变量或者引用
2、双向关联
B1-B2: 表示B1认识B2。B1知道B2的存在。B1能够调用B2中的方法和属性；相同B2也知道B1的存在，B2也能够调用B1的方法和属性。
场景：订单和客户。订单属于客户。客户拥有一些特定的订单
类与类之间的双向关联图
C#代码
Public class User
{
Public List<Order> GetOrder()
{
} return new List<Order>();
}
Public Class Order
{
Public User GetUserByOrderID(string OrderId )
{
Return new User();
}
}
3、自身关联
同一个类对象之间的关联
类与类之间自身关联图
4、多维关联(N-ary Association)
多个对象之间存在关联
场景：公司雇用员工，同一时候公司须要支付工资给员工
类与类之间的多维关联图：
5、泛化(Generalization)
类与类的继承关系，类与接口的实现关系。
场景：父与子、动物与人、植物与树、系统使用者与B2C会员和B2E会员的关系
类与类之间的泛化图：
系统的使用者包含：B2C会员、B2B会员和B2E会员。
接口的实现，动物都有吃的行为，而人是动物的一个详细实例,实现详细Eat的动作
6、依赖(Dependency)
类A要完毕某个功能必须引用类B，则A与B存在依赖关系。依赖关系是弱的关联关系。C#不建议双相依赖。也就是相互引用
场景：本来人与电脑没有关系的。但因为偶然的机会，人须要用电脑敲代码，这时候人就依赖于电脑。
类与类的依赖关系图
在程序中一般为 using 引用。
7、聚合(Aggregation)
当对象A被增加到对象B中。成为对象B的组成部分时。对象B和对象A之间为聚合关系。聚合是关联关系的一种，是较强的关联关系，强调的是总体与部分之间的关系。
场景：商品和他的规格、样式就是聚合关系。
类与类的聚合关系图
8、组合（Composite）
对象A包括对象B。对象B离开对象A没有实际意义。是一种更强的关联关系。人包括手。手离开人的躯体就失去了它应有的作用。
场景： Window窗口由滑动条slider、头部Header 和工作区Panel组合而成。
类与类的组合关系图
领域模型
用包（Package）组织领域模型
有时候。一个领域模型会变得很大。这时我们能够把依照相关的概念将其划分成不同的包。
包的划分
我们能够将例如以下一些元素组合成一个单独的包：
• 在概念或用途上，它们属于同一个主题范围；
• 它们在同一个类层次结构上；
• 參与了同一个用例；
• 之间有很强烈的关联关系。
比如，我们将领域划分为Core/Misc, Payments, Products, Sales和Authorization Transation五个包，每一个包中的类图又例如以下所看到的。