统一建模语言(Unified Modeling Language,UML)

DBAS建模

UML的定义由语义和表示法两部分组成。语义用自然语言描述，而表示法定义了UML的可视化标准表示符号，这决定了UML是一种可视化的建模语言。具体来说，UML的语义是定义在一个4层（或4个抽象级）建模概念框架中的，这四层分别是：
（1）元元模型层：组成了UML的最基本的元素"事物"，它是UML体系中最高的抽象层级。
（2）元模型层：组成了UML的基本元素，这一层中的每个概念都是元元模型中"事物"概念的实例。
（3）模型层：组成了UML的模型，这一层中的每个概念都是元模型层中概念的一个实例。
（4）用户模型层：这层中的所有元素都是UML模型的实例。
UML中包括以下五种视图：结构视图、实现视图、行为视图、环境视图和用例视图。

统一建模语言，UML的词汇表分为三种构造块：事物、关系、图

UML中的事物

UML中有4种事物：结构事物、行为事物、分组事物和注释事物。
结构事物(Structural Thing)：类(Class)、接口(Interface)、协作(Collaboration)、用例(Use Case)、主动类(Active Class)、构(组)件(Component)、制品(Artifact)、节点(Node)。

行为事物(Behavior Thing)：交互(Interaction)、状态机(State Machine)和活动(Activity)。

分组事物(Grouping Thing）。分组事物是 UML 模型的组织部分，是一些由模型分解成的 “盒子”。在所有的分组事物中，最主要的分组事物是包（Package）。 包是把元素组织成组的机制，这种机制具有多种用途。结构事物、行为事物甚至其他分组事物都可以放进包内。包与构件（仅在运行时存在）不同，它纯粹是概念上的（即它仅在开发时存在）。

注释事物(Annotational Thing）。注释事物是 UML 模型的解释部分。 这些注释事物用来描述说明和标注模型的任何元素。 注解（Note）是一种主要的注释事物。 注解是一个依附于一个元素或者一组元素之上，对它进行约束或解释的简单符号。

UML中的关系

参考文章：UML的9种图例解析
UML 中有 4 种关系：依赖、关联、泛化和实现。

依赖 （Dependecy）

依赖是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在图形上，把一个依赖画成一条可能有方向的虚线。
在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。

关联 (Association)

关联是一种结构关系，它描述了 一组链，链是对象之间的连接。

• 聚集(Aggregation)是一种特殊类型的关联，它描述了整体和部分间的结构关系。
  【箭头指向】带空心菱形的实线，空心菱形指向整体。
• 组合(Composition)是关联关系的一种，是比聚合关系还要强的关系。
  【箭头指向】带实心菱形的实线，实心菱形指向整体。
  在关联上可以标注重复度(Multiplicity)和角色(Role)

双向关联

默认情况下，关联是双向的。

单向关联

类的关联关系也可以是单向的，单向关联用带箭头的实线表示。

自关联

在系统中可能会存在一些类的属性对象类型为该类本身，这种特殊的关联关系称为自关联。

重数性关联

重数性关联关系又称为多重性关联关系(Multiplicity)，表示一个类的对象与另一个类的对象连接的个数。在UML中多重性关系可以直接在关联直线上增加一个数字表示与之对应的另一个类的对象的个数。

泛化 （Generalization）

泛化是一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。用这种方法，子元素共享了父元素的结构和行为。在图形上把一个泛化关系画成一条带有空心箭头的实线，它指向父元素。
泛化关系(Generalization)也就是继承关系，也称为“is-a-kind-of“关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。
泛化关系(Generalization)：A是B和C的父类，B，C具有公共类(父类)A，说明A是B，C的一般化(概括，也称泛化)

实现 （Realization）

实现是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。在两种情况下会使用实现关系：一种是在接口和实现它们的类或构件之间 ，另一种是在用例和实现它们的协作之间。在图形上，把一个实现关系画成一条带有空心箭头的虚线。

这4种关系是 UML 模型中可以包含的基本关系事物。它们也有变体。例如，依赖的变体有精化、跟踪、包含和延伸。

UML 中的图

参考文章：一文掌握14种UML图
图(Diagram)是一组元素的图形表示，大多数情况下把图画成顶点（代表事物）和弧（代表关系）的连通图。为了对系统进行可视化，可以从不同的角度画图，这样图是对系统的投影。

UML 2.0 提供了 13 种图，分别是类图、对象图、用例图、序列图、通信图、状态图、活动图、构件图、部署图、组合结构图、包图、交互概览图和计时图。序列图、通信图、交互概览图和计时图均被称为交互图。

DBAS业务流程与需求表达

活动图(Activity Diagram）

是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程。活动图专注于系统的动态视图。 它对于系统的功能建模特别重要，并强调对象间的控制流程。活动图可用于对工作流建模、操作建模。

图中简单描述了，从开始到登录到查看订单列表，或者登录失败直接结束。

活动图主要用于描述系统、用例和程序模块中逻辑流程的先后执行次序、并行次序。
起始点：指一连串活动的开始点。在一张活动图中，必须有且只能有一个起始点，用●表示。
结束点：指一连串活动的终结点。在一张活动图中，可以有多个结束点，用◉表示。

用例图(Use Case Diagram）

展现了一组用例、参与者(Actor)以及它们之间的关系，描述了谁将使用系统以及用户期望以什么方式与系统交互。用例图中包含用例、参与者及用例之间的扩展关系(<<extend>>)和包含关系(<<include>>)，参与者和用例之间的关联关系，用例与用例以及参与者与参与者之间的泛化关系。用例图给出系统的静态用例视图，可用于对系统的语境建模；对系统的需求建模。

包含关系使用符号<<include>>，想要查看订单列表，前提是需要先登录。
扩展关系使用符号<<extend>>，基于查看订单列表的功能，可以增加一个导出查询结果的功能

用例模型由系统、角色和用例3部分组成。
系统是在边界线以内的区域（即用例的活动区域）抽象地表示能够实现的所有基本功能。
角色是与系统进行交互的外部实体，可以是系统用户也可以说是其他系统或者硬件设备。
一个角色可以执行多个用例，反过来，一个用例也可被多个角色使用。
在UML中，用例用椭圆形表示，用例位于系统边界的内部。
用例之间也存在关系，包括扩展、使用、组合3种。
用例用于描述从系统用户的角度来观察，系统应具有哪些功能，帮助分析人员理解系统的行为。

DBAS系统内部结构的表达

类图(Class Diagram）

展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，包含主动类的类图给出了系统的静态进程视图。类图中通常包含类、接口、协作、以及依赖、泛化和关联关系，也可以包含注解和约束。类图通常用于对系统的词汇建模；对简单的协作建模；对逻辑数据库模式建模。

类图是展现一组类、接口和协作以及它们之间的关系的一种静态视图。
类与类之间通常有关联、通用化（继承）、依赖和精化四种关系。
聚集可进一步划分为共享聚集和组成。共享聚集表示为空心菱形，组成为实心菱形。

顺序图/序列图(Sequence Diagram）

是场景(Scenari)的图形化表示，描述了在一个用例或操作的执行过程中以时间顺序组织的对象之间的交互活动。图中对象发送和接收的消息沿垂直方向按时间顺序从上到下放置。序列图中有对象生命线和控制焦点。

loop是循环，alt是选择

顺序图是用来描述对象自身及对象间信息传递顺序的视图。

1. 顺序图有两个坐标轴：纵向表示时间的持续时间，横向表示对象，每一个对象用矩形框表示，纵向的虚线表示对象在序列中的执行情况，称为对象的“生命线”。
2. 对象间的通信用对象生命线之间的水平消息线表示，箭头说明消息的类型，如同步、异步或简单。
3. 顺序图中的消息可以附加条件，这时规定只有条件为真时才可以发送和接收消息。用条件来描述分支时，如果各分支的条件之间不互相排斥，则消息可能会并行发出。
4. 在顺序图中可以描述对象如何创建和销毁的，创建和销毁对象的消息一般是同步的。
5. 顺序图也可以表示递归过程，当一个操作调用它本身时，消息总是同步的。

通信图(Communication Diagram）

强调收发消息的对象之间的结构组织。通信图有路径和顺序号。序列图和通信图都是交互图(Interaction Diagram）。交互图展现了一种交互，它由一组对象和它们之间的关系组成，包括它们之间可能发送的消息。交互图关注系统的动态视图。序列图和通信图是同构的，它们之间可以相互转换。

方框和小人表示生命线，不同生命线之间可以传递消息，消息前面的数字可以表达序列顺序

通信图是交互图的一种，也被称为协作图。
顺序图和通信图都描述交互，但是顺序图强调的是时间，而通信图强调的是空间。
通信图显示了在交互过程中各个对象之间的组织交互关系以及对象彼此之间的链接。

DBAS系统微观设计的表达

对象图(Object Diagram）

展现了一组对象以及它们之间的关系，描述了在类图中所建立的事物实例的静态快照。对象图一般包括对象和链。与类图相同，对象图给出系统的静态设计视图或静态进程视图，但它们是从真实的或原型案例的角度建立的。

bat这个公司有一个研发部，一个销售部，两个部门只有一个人iisheng

UML中的对象图被用来描述特定时间点上所有对象在系统中的结构，也可以把对象图当成系统在某一时间点的快照，即对象图根据类图所诞生的实例。
对象图可以被用来解释类图以及验证所设计的类图是否符合实际的状况，也可以帮助程序设计人员理解类图的复杂结构。

状态图(State Diagram）

展现了一个状态机，它由状态、转换、事件和活动组成，用于建模时间如何改变对象的状态以及引起对象从一个状态向另一个状态转换的事件。状态图关注系统的动态视图，它对于接口、类和协作的行为建模尤为重要，强调对象行为的事件顺序。

图中简单描述了，从开始到登录到查看订单列表，或者登录失败直接结束。

状态图主要用来描述一个实体在发生一些事件时的状态变化情况，用于展示该实体处于不同状态时对不同事件做出响应后的状态变化情况。
在状态图中，只能有一个起始状态，这一点与活动图中起始点是相同的，起始状态的图示是一个是实心的圆形。结束状态代表整个状态机到此活动结束，可以有多个结束状态。

时间图/定时图(Timing Diagram）

是另一种交互图，关注一个对象或一组对象在改变状态时的时间约束条件，描述对象状态随着时间改变的情况，很像示波器，适合分析周期和非周期性任务。当为设备设计嵌入式软件时，定时图特别有用。

图中展示了老年痴呆病人随着时间的变化病情的变化。

一般情况下，一张时间图通常会对应至少一张状态图，通常可以把时间图作为状态图的辅助说明工具。

DBAS系统宏观设计的表达

包图(Package)

用于把模型本身组织成层次结构的通用机制，描述类或其他 UML 构件如何组织成包，以及这些包之间的依赖关系。包可以拥有其他元素，可以是类、接口、构件、结点、协作、用例和图，甚至是嵌套的其他包。拥有是一种组成关系。

<<Use>>关系表示使用依赖，Web Shopping依赖Payment
<<Merge>>关系表示合并，Web Shopping合并了Shopping Cart就拥有了Shopping Cart的功能
<<Access>>关系表示私有引入，比如代码中的指定包名类名
<<Import>>关系表示公共引入，比如Java中的import之后，就可以直接使用import包中的类了

包图是表示包及包之间的关系的类图。

交互概览图(Interaction Overview Diagram）

组合了序列图和活动图的特征，显示了每个用例的活动中对象如何交互。它使用活动图的表示法，描述业务过程中的控制流概览，软件过程中的详细逻辑概览，以及将多个图进行连接，抽象掉了消息和生命线。

sd的框代表具体的交互流程，ref框代表使用交互

组合结构图(Composite Structure Diagram）

用于描述一个分类器（类、组件或用例）的内部结构，分类器与系统中其他组成部分之间的交互端口，展示一组相互协作的实例如何完成特定的任务，描述设计、架构模式或策略。

Car是由车轴连接着的两个前面轮子、两个后面轮子，和引擎组合的。

组件图(Component Diagram）

展现了一组构件之间的组织和依赖。组件图专注于系统的静态实现视图。它与类图相关，通常把构件映射为一个或多个类、接口或协作。

订单系统组件依赖于客户资源库和库存系统组件。中间的虚线箭头表示依赖关系。另外两个符号，表示组件连接器，一个提供接口，一个需要接口。

部署图(Deployment Diagram）

展现了运行时处理结点以及其中构件（制品） 的配置。部署图给出了体系结构的静态实施视图。它与构件图相关，通常一个结点句含一个或多个构件。部署图是 UML 图中唯一用来对面向对象系统的物理方面建模的一种图。

图中简单的表示，不同机器上面部署的不同软件。

总结

1. 用例可以简单理解为功能，那么序列图、活动图和用例图都描述了用例，只有通信图不用于描述用例。
2. UML状态图包含初始状态(实心圆)和结束状态(同心圆)，用于描述对象的状态转换。
3. 静态建模：类图、对象图、用例图
   动态建模：序列图(顺序图，时序图)、通信图(协作图)、状态图、活动图
   物理建模：构件图(组件图)、部署图
   交互图：序列图(顺序图，时序图)、通信图(协作图)

DBAS系统实现与部署的表达

U M L 13 种图分类 { 结构图，主要用于对系统静态结构建模 { 类图 对象图 复合结构图 包图 组件图 部署图 行为图，主要用于对系统的动态行为建模 { 用例图 交互图 ( 顺序图、通信图 / 协作图、交互概述图、时间图 ) 状态图 活动图 UML 13种图分类\begin{cases} 结构图，主要用于对系统静态结构建模 \begin{cases} 类图\\ 对象图\\ 复合结构图\\ 包图\\ 组件图\\ 部署图\\ \end{cases}\\ 行为图，主要用于对系统的动态行为建模 \begin{cases} 用例图\\ 交互图(顺序图、通信图/协作图、交互概述图、时间图)\\ 状态图\\ 活动图\\ \end{cases}\\ \end{cases}UML13种图分类⎩⎨⎧​结构图，主要用于对系统静态结构建模⎩⎨⎧​类图对象图复合结构图包图组件图部署图​行为图，主要用于对系统的动态行为建模⎩⎨⎧​用例图交互图(顺序图、通信图/协作图、交互概述图、时间图)状态图活动图​​
结构图是指以模块的调用关系为线索，用自上而下的连线表示调用关系并注明参数传递的方向和内容，从宏观上反映模块层次结构的图形。其中结构图包括包图、复合结构图、类图、组件图、对象图和部署图。

设计模式

按照设计模式的目的划分 { 创建型设计模式 { F a c t o r y M e t h o d （工厂方法）：定义一个用于创建对象的接口，让子类决定实例化哪一个类。 A b s t r a c t F a c t o r y （抽象工厂）：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。 B u i l d e r （生成器）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 P r o t o t y p e （原型）：用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。 S i n g l e t o n （单例）：模式保证一个类仅有一个实例，并提供一个访问它的全局访问点。 结构型设计模式 { A d a p t e r （适配器） C o m p o s i t e （组合） P r o x y （代理） F l y w e i g h t （享元） F a c a d e （外观） B r i d g e （桥接）：将对象的抽象和其实现分离，从而可以独立地改变它们 D e c o r a t o r （装饰） 行为型设计模式 { T e m p l a t e M e t h o d （模板方法） C h a i n o f R e s p o n s i b i l i t y （责任链）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求。直到有一个对象处理为止。 O b s e r v e r （观察者） S t r a t e g y （策略）：定义一系列算法，把他们封装起来，并且使它们可以相互替换。 C o m m a n d （命令） M e m e n t o （备忘录） S t a t e （状态） V i s i t o r （访问者） I t e r a t o r （迭代器）：提供一种方法顺序访问一个聚合对象中的各个元素，且不需要暴露该对象的内部表示。 按照设计模式的目的划分\begin{cases} 创建型设计模式 \begin{cases} Factory Method（工厂方法） ：定义一个用于创建对象的接口，让子类决定实例化哪一个类。\\ Abstract Factory（抽象工厂）：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。\\ Builder（生成器）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。\\ Prototype（原型）：用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。 \\ Singleton（单例）：模式保证一个类仅有一个实例，并提供一个访问它的全局访问点。 \end{cases}\\ 结构型设计模式 \begin{cases} Adapter（适配器）\\ Composite（组合）\\ Proxy（代理）\\ Flyweight（享元）\\ Facade（外观）\\ Bridge（桥接）：将对象的抽象和其实现分离，从而可以独立地改变它们\\ Decorator（装饰） \end{cases}\\ 行为型设计模式 \begin{cases} Template Method（模板方法）\\ Chain of Responsibility（责任链）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求。直到有一个对象处理为止。\\ Observer（观察者）\\ Strategy（策略）：定义一系列算法，把他们封装起来，并且使它们可以相互替换。\\ Command（命令）\\ Memento（备忘录）\\ State（状态）\\ Visitor（访问者）\\ Iterator（迭代器）：提供一种方法顺序访问一个聚合对象中的各个元素，且不需要暴露该对象的内部表示。 \end{cases}\\ \end{cases}按照设计模式的目的划分⎩⎨⎧​创建型设计模式⎩⎨⎧​FactoryMethod（工厂方法）：定义一个用于创建对象的接口，让子类决定实例化哪一个类。AbstractFactory（抽象工厂）：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。Builder（生成器）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。Prototype（原型）：用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。Singleton（单例）：模式保证一个类仅有一个实例，并提供一个访问它的全局访问点。​结构型设计模式⎩⎨⎧​Adapter（适配器）Composite（组合）Proxy（代理）Flyweight（享元）Facade（外观）Bridge（桥接）：将对象的抽象和其实现分离，从而可以独立地改变它们Decorator（装饰）​行为型设计模式⎩⎨⎧​TemplateMethod（模板方法）ChainofResponsibility（责任链）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求。直到有一个对象处理为止。Observer（观察者）Strategy（策略）：定义一系列算法，把他们封装起来，并且使它们可以相互替换。Command（命令）Memento（备忘录）State（状态）Visitor（访问者）Iterator（迭代器）：提供一种方法顺序访问一个聚合对象中的各个元素，且不需要暴露该对象的内部表示。​​

在UML用例图中，参与者表示硬件或其他系统可以扮演的角色。
UML中关联是一个结构关系，描述了一组链。两个类之间可以有多个由不同角色标识的关联。
在UML中有4种事物：结构事物、行为事物、分组事物和注释事物。其中，结构事物表示UML模型中的名词，它们通常是模型的静态部分，描述概念或物理元素。
UML中行为事物是模型中的动态部分，采用动词描述跨越时间和空间的行为。状态机属于行为事物，它描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。