uml 图学习记录

UML类图与类的关系详解

2011-04-21 来源：网络

在画类图的时候，理清类和类之间的关系是重点。类的关系有泛化(Generalization)、实现（Realization）、依赖(Dependency)和关联(Association)。其中关联又分为通常关联关系和聚合关系(Aggregation)，合成关系(Composition)。下面咱们结合实例理解这些关系。 基本概念 类图（Class Diagram）: 类图是面向对象系统建模中最经常使用和最重要的图，是定义其它图的基础。类图主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。 类图的3个基本组件：类名、属性、方法。  泛化(generalization)：表示is-a的关系，是对象之间耦合度最大的一种关系，子类继承父类的全部细节。直接使用语言中的继承表达。在类图中使用带三角箭头的实线表示，箭头从子类指向父类。 实现（Realization）:在类图中就是接口和实现的关系。这个没什么好讲的。在类图中使用带三角箭头的虚线表示，箭头从实现类指向接口。 依赖(Dependency)：对象之间最弱的一种关联方式，是临时性的关联。代码中通常指由局部变量、函数参数、返回值创建的对于其余对象的调用关系。一个类调用被依赖类中的某些方法而得以完成这个类的一些职责。在类图使用带箭头的虚线表示，箭头从使用类指向被依赖的类。 关联(Association) : 对象之间一种引用关系，好比客户类与订单类之间的关系。这种关系一般使用类的属性表达。关联又分为通常关联、聚合关联与组合关联。后两种在后面分析。在类图使用带箭头的实线表示，箭头从使用类指向被关联的类。能够是单向和双向。 聚合(Aggregation) : 表示has-a的关系，是一种不稳定的包含关系。较强于通常关联,有总体与局部的关系,而且没有了总体,局部也可单独存在。如公司和员工的关系，公司包含员工，但若是公司倒闭，员工依然能够换公司。在类图使用空心的菱形表示，菱形从局部指向总体。 组合(Composition) : 表示contains-a的关系，是一种强烈的包含关系。组合类负责被组合类的生命周期。是一种更强的聚合关系。部分不能脱离总体存在。如公司和部门的关系，没有了公司，部门也不能存在了；调查问卷中问题和选项的关系；订单和订单选项的关系。在类图使用实心的菱形表示，菱形从局部指向总体。 多重性(Multiplicity) : 一般在关联、聚合、组合中使用。就是表明有多少个关联对象存在。使用数字..星号（数字）表示。以下图，一个割接通知能够关联0个到N个故障单。 聚合和组合的区别 这两个比较难理解，重点说一下。聚合和组合的区别在于：聚合关系是“has-a”关系，组合关系是“contains-a”关系；聚合关系表示总体与部分的关系比较弱，而组合比较强；聚合关系中表明部分事物的对象与表明聚合事物的对象的生存期无关，一旦删除了聚合对象不必定就删除了表明部分事物的对象。组合中一旦删除了组合对象，同时也就删除了表明部分事物的对象。 实例分析 联通客户响应OSS。系统有故障单、业务开通、资源核查、割接、业务重保、网络品质性能等功能模块。如今咱们抽出部分需求作为例子讲解。 你们能够参照着类图，好好理解。 1． 通知分为通常通知、割接通知、重保通知。这个是继承关系。 2． NoticeService和实现类NoticeServiceImpl是实现关系。 3． NoticeServiceImpl经过save方法的参数引用Notice,是依赖关系。同时调用了BaseDao完成功能，也是依赖关系。 4． 割接通知和故障单之间经过中间类(通知电路)关联，是通常关联。 5． 重保通知和预案库间是聚合关系。由于预案库能够事先录入，和重保通知没有必然联系，能够独立存在。在系统中是手工从列表中选择。删除重保通知，不影响预案。 6． 割接通知和需求单之间是聚合关系。同理，需求单能够独立于割接通知存在。也就是说删除割接通知，不影响需求单。 7． 通知和回复是组合关系。由于回复不能独立于通知存在。也就是说删除通知，该条通知对应的回复也要级联删除。 通过以上的分析，相信你们对类的关系已经有比较好的理解了。你们有什么其它想法或好的看法，欢迎拍砖。 PS：仍是那句话：以上类图用Enterprise Architect 7.5所画，在此推荐一下EA,很是不错。能够替代Visio和Rose了。Visio功能不够强大，Rose过重。惟有EA比较合适。

 

 

参考二：

深刻浅出UML类图

做者：刘伟 ，发布于：2012-11-23，来源：CSDN

在UML 2.0的13种图形中，类图是使用频率最高的UML图之一。Martin Fowler在其著做《UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition》（《UML精粹：标准对象建模语言简明指南（第3版）》）中有这么一段：“If someone were to come up to you in a dark alley and say, 'Psst, wanna see a UML diagram?' that diagram would probably be a class diagram. The majority of UML diagrams I see are class diagrams.”（“若是有人在黑暗的小巷中向你走来并对你说：‘嘿，想不想看一张UML图？’那么这张图颇有可能就是一张类图，我所见过的大部分的UML图都是类图”），因而可知类图的重要性。 类图用于描述系统中所包含的类以及它们之间的相互关系，帮助人们简化对系统的理解，它是系统分析和设计阶段的重要产物，也是系统编码和测试的重要模型依据。 1. 类 类(Class)封装了数据和行为，是面向对象的重要组成部分，它是具备相同属性、操做、关系的对象集合的总称。在系统中，每一个类都具备必定的职责，职责指的是类要完成什么样的功能，要承担什么样的义务。一个类能够有多种职责，设计得好的类通常只有一种职责。在定义类的时候，将类的职责分解成为类的属性和操做（即方法）。类的属性即类的数据职责，类的操做即类的行为职责。设计类是面向对象设计中最重要的组成部分，也是最复杂和最耗时的部分。 在软件系统运行时，类将被实例化成对象(Object)，对象对应于某个具体的事物，是类的实例(Instance)。 类图(Class Diagram)使用出如今系统中的不一样类来描述系统的静态结构，它用来描述不一样的类以及它们之间的关系。 在系统分析与设计阶段，类一般能够分为三种，分别是实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class)，下面对这三种类加以简要说明： (1) 实体类：实体类对应系统需求中的每一个实体，它们一般须要保存在永久存储体中，通常使用数据库表或文件来记录，实体类既包括存储和传递数据的类，还包括操做数据的类。实体类来源于需求说明中的名词，如学生、商品等。 (2) 控制类：控制类用于体现应用程序的执行逻辑，提供相应的业务操做，将控制类抽象出来能够下降界面和数据库之间的耦合度。控制类通常是由动宾结构的短语（动词+名词）转化来的名词，如增长商品对应有一个商品增长类，注册对应有一个用户注册类等 (3) 边界类：边界类用于对外部用户与系统之间的交互对象进行抽象，主要包括界面类，如对话框、窗口、菜单等。 在面向对象分析和设计的初级阶段，一般首先识别出实体类，绘制初始类图，此时的类图也可称为领域模型，包括实体类及其它们之间的相互关系。 2. 类的UML图示 在UML中，类使用包含类名、属性和操做且带有分隔线的长方形来表示，如定义一个Employee类，它包含属性name、age和email，以及操做modifyInfo()，在UML类图中该类如图1所示： 图1 类的UML图示 图1对应的Java代码片断以下： public class Employee { private String name; private int age; private String email; public void modifyInfo() { ...... } } 在UML类图中，类通常由三部分组成： (1) 第一部分是类名：每一个类都必须有一个名字，类名是一个字符串。 (2) 第二部分是类的属性(Attributes)：属性是指类的性质，即类的成员变量。一个类能够有任意多个属性，也能够没有属性 UML规定属性的表示方式为： 可见性 名称:类型 [ = 缺省值 ] 其中： “可见性”表示该属性对于类外的元素而言是否可见，包括公有(public)、私有(private)和受保护(protected)三种，在类图中分别用符号+、-和#表示。 “名称”表示属性名，用一个字符串表示。 “类型”表示属性的数据类型，能够是基本数据类型，也能够是用户自定义类型。 “缺省值”是一个可选项，即属性的初始值。 (3) 第三部分是类的操做(Operations)：操做是类的任意一个实例对象均可以使用的行为，是类的成员方法。 UML规定操做的表示方式为： 可见性 名称(参数列表) [ : 返回类型] 其中： “可见性”的定义与属性的可见性定义相同。 “名称”即方法名，用一个字符串表示。 “参数列表”表示方法的参数，其语法与属性的定义类似，参数个数是任意的，多个参数之间用逗号“，”隔开。 “返回类型”是一个可选项，表示方法的返回值类型，依赖于具体的编程语言，能够是基本数据类型，也能够是用户自定义类型，还能够是空类型(void)，若是是构造方法，则无返回类型。 在类图2中，操做method1的可见性为public(+)，带入了一个Object类型的参数par，返回值为空(void)；操做method2的可见性为protected(#)，无参数，返回值为String类型；操做method3的可见性为private(-)，包含两个参数，其中一个参数为int类型，另外一个为int[]类型，返回值为int类型。 图2 类图操做说明示意图 因为在Java语言中容许出现内部类，所以可能会出现包含四个部分的类图，如图3所示： 图3 包含内部类的类图 类与类之间的关系（1） 在软件系统中，类并非孤立存在的，类与类之间存在各类关系，对于不一样类型的关系，UML提供了不一样的表示方式。 1. 关联关系 关联(Association)关系是类与类之间最经常使用的一种关系，它是一种结构化关系，用于表示一类对象与另外一类对象之间有联系，如汽车和轮胎、师傅和徒弟、班级和学生等等。在UML类图中，用实线链接有关联关系的对象所对应的类，在使用Java、C#和C++等编程语言实现关联关系时，一般将一个类的对象做为另外一个类的成员变量。在使用类图表示关联关系时能够在关联线上标注角色名，通常使用一个表示二者之间关系的动词或者名词表示角色名（有时该名词为实例对象名），关系的两端表明两种不一样的角色，所以在一个关联关系中能够包含两个角色名，角色名不是必须的，能够根据须要增长，其目的是使类之间的关系更加明确。 如在一个登陆界面类LoginForm中包含一个JButton类型的注册按钮loginButton，它们之间能够表示为关联关系，代码实现时能够在LoginForm中定义一个名为loginButton的属性对象，其类型为JButton。如图1所示： 图1 关联关系实例 图1对应的Java代码片断以下： public class LoginForm { private JButton loginButton; //定义为成员变量 …… } public class JButton { …… } 在UML中，关联关系一般又包含以下几种形式： (1) 双向关联 默认状况下，关联是双向的。例如：顾客(Customer)购买商品(Product)并拥有商品，反之，卖出的商品总有某个顾客与之相关联。所以，Customer类和Product类之间具备双向关联关系，如图2所示： 图2 双向关联实例 图2对应的Java代码片断以下： public class Customer { private Product[] products; …… } public class Product { private Customer customer; …… } (2) 单向关联 类的关联关系也能够是单向的，单向关联用带箭头的实线表示。例如：顾客(Customer)拥有地址(Address)，则Customer类与Address类具备单向关联关系，如图3所示： 图3 单向关联实例 图3对应的Java代码片断以下： public class Customer { private Address address; …… } public class Address { …… } (3) 自关联 在系统中可能会存在一些类的属性对象类型为该类自己，这种特殊的关联关系称为自关联。例如：一个节点类(Node)的成员又是节点Node类型的对象，如图4所示： 图4 自关联实例 图4对应的Java代码片断以下： public class Node { private Node subNode; …… } (4) 多重性关联 多重性关联关系又称为重数性(Multiplicity)关联关系，表示两个关联对象在数量上的对应关系。在UML中，对象之间的多重性能够直接在关联直线上用一个数字或一个数字范围表示。 对象之间能够存在多种多重性关联关系，常见的多重性表示方式如表1所示： 表1 多重性表示方式列表 表示方式 多重性说明 1..1 表示另外一个类的一个对象只与该类的一个对象有关系 0..* 表示另外一个类的一个对象与该类的零个或多个对象有关系 1..* 表示另外一个类的一个对象与该类的一个或多个对象有关系 0..1 表示另外一个类的一个对象没有或只与该类的一个对象有关系 m..n 表示另外一个类的一个对象与该类最少m，最多n个对象有关系 (m≤n) 例如：一个界面(Form)能够拥有零个或多个按钮(Button)，可是一个按钮只能属于一个界面，所以，一个Form类的对象能够与零个或多个Button类的对象相关联，但一个Button类的对象只能与一个Form类的对象关联，如图5所示： 图5 多重性关联实例 图5对应的Java代码片断以下： public class Form { private Button[] buttons; //定义一个集合对象 …… } public class Button { …… } (5) 聚合关系 聚合(Aggregation)关系表示总体与部分的关系。在聚合关系中，成员对象是总体对象的一部分，可是成员对象能够脱离总体对象独立存在。在UML中，聚合关系用带空心菱形的直线表示。例如：汽车发动机(Engine)是汽车(Car)的组成部分，可是汽车发动机能够独立存在，所以，汽车和发动机是聚合关系，如图6所示： 图6 聚合关系实例 在代码实现聚合关系时，成员对象一般做为构造方法、Setter方法或业务方法的参数注入到总体对象中，图6对应的Java代码片断以下： public class Car { private Engine engine; //构造注入 public Car(Engine engine) { this.engine = engine; } //设值注入 public void setEngine(Engine engine) { this.engine = engine; } …… } public class Engine { …… } (6) 组合关系 组合(Composition)关系也表示类之间总体和部分的关系，可是在组合关系中总体对象能够控制成员对象的生命周期，一旦总体对象不存在，成员对象也将不存在，成员对象与总体对象之间具备同生共死的关系。在UML中，组合关系用带实心菱形的直线表示。例如：人的头(Head)与嘴巴(Mouth)，嘴巴是头的组成部分之一，并且若是头没了，嘴巴也就没了，所以头和嘴巴是组合关系，如图7所示： 图7 组合关系实例 在代码实现组合关系时，一般在总体类的构造方法中直接实例化成员类，图7对应的Java代码片断以下： public class Head { private Mouth mouth; public Head() { mouth = new Mouth(); //实例化成员类 } …… } public class Mouth { …… } 类与类之间的关系（2） 2. 依赖关系 依赖(Dependency)关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其余事物，在须要表示一个事物使用另外一个事物时使用依赖关系。大多数状况下，依赖关系体如今某个类的方法使用另外一个类的对象做为参数。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。例如：驾驶员开车，在Driver类的drive()方法中将Car类型的对象car做为一个参数传递，以便在drive()方法中可以调用car的move()方法，且驾驶员的drive()方法依赖车的move()方法，所以类Driver依赖类Car，如图1所示： 图1 依赖关系实例 在系统实施阶段，依赖关系一般经过三种方式来实现，第一种也是最经常使用的一种方式是如图1所示的将一个类的对象做为另外一个类中方法的参数，第二种方式是在一个类的方法中将另外一个类的对象做为其局部变量，第三种方式是在一个类的方法中调用另外一个类的静态方法。图1对应的Java代码片断以下： public class Driver { public void drive(Car car) { car.move(); } …… } public class Car { public void move() { ...... } …… } 3. 泛化关系 泛化(Generalization)关系也就是继承关系，用于描述父类与子类之间的关系，父类又称做基类或超类，子类又称做派生类。在UML中，泛化关系用带空心三角形的直线来表示。在代码实现时，咱们使用面向对象的继承机制来实现泛化关系，如在Java语言中使用extends关键字、在C++/C#中使用冒号“：”来实现。例如：Student类和Teacher类都是Person类的子类，Student类和Teacher类继承了Person类的属性和方法，Person类的属性包含姓名(name)和年龄(age)，每个Student和Teacher也都具备这两个属性，另外Student类增长了属性学号(studentNo)，Teacher类增长了属性教师编号(teacherNo)，Person类的方法包括行走move()和说话say()，Student类和Teacher类继承了这两个方法，并且Student类还新增方法study()，Teacher类还新增方法teach()。如图2所示： 图2 泛化关系实例 图2对应的Java代码片断以下： //父类 public class Person { protected String name; protected int age; public void move() { …… } public void say() { …… } } //子类 public class Student extends Person { private String studentNo; public void study() { …… } } //子类 public class Teacher extends Person { private String teacherNo; public void teach() { …… } } 4. 接口与实现关系 在不少面向对象语言中都引入了接口的概念，如Java、C#等，在接口中，一般没有属性，并且全部的操做都是抽象的，只有操做的声明，没有操做的实现。UML中用与类的表示法相似的方式表示接口，如图3所示： 图3 接口的UML图示 接口之间也能够有与类之间关系相似的继承关系和依赖关系，可是接口和类之间还存在一种实现(Realization)关系，在这种关系中，类实现了接口，类中的操做实现了接口中所声明的操做。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。例如：定义了一个交通工具接口Vehicle，包含一个抽象操做move()，在类Ship和类Car中都实现了该move()操做，不过具体的实现细节将会不同，如图4所示： 图4 实现关系实例 实现关系在编程实现时，不一样的面向对象语言也提供了不一样的语法，如在Java语言中使用implements关键字，而在C++/C#中使用冒号“：”来实现。图4对应的Java代码片断以下： public interface Vehicle { public void move(); } public class Ship implements Vehicle { public void move() { …… } } public class Car implements Vehicle { public void move() { …… } } 实例分析1——登陆模块 某基于C/S的即时聊天系统登陆模块功能描述以下： 用户经过登陆界面(LoginForm)输入帐号和密码，系统将输入的帐号和密码与存储在数据库(User)表中的用户信息进行比较，验证用户输入是否正确，若是输入正确则进入主界面(MainForm)，不然提示“输入错误”。 根据以上描述绘制初始类图。 参考解决方案： 参考类图以下： 考虑到系统扩展性，在本实例中引入了抽象数据访问接口IUserDAO，再将具体数据访问对象注入到业务逻辑对象中，可经过配置文件（如XML文件）等方式来实现，将具体的数据访问类类名存储在配置文件中，若是须要更换新的具体数据访问对象，只需修改配置文件便可，原有程序代码无须作任何修改。 类说明： 类 名 说 明 LoginForm 登陆窗口，省略界面组件和按钮事件处理方法（边界类） LoginBO 登陆业务逻辑类，封装实现登陆功能的业务逻辑（控制类） IUserDAO 抽象数据访问类接口，声明对User表的数据操做方法，省略除查询外的其余方法（实体类） UserDAO 具体数据访问类，实现对User表的数据操做方法，省略除查询外的其余方法（实体类） MainForm 主窗口（边界类） 方法说明： 方法名 说 明 LoginForm类的LoginForm()方法 LoginForm构造函数，初始化实例成员 LoginForm类的validate()方法 界面类的验证方法，经过调用业务逻辑类LoginBO的validate()方法实现对用户输入信息的验证 LoginBO类的validate()方法 业务逻辑类的验证方法，经过调用数据访问类的findUserByAccAndPwd()方法验证用户输入信息的合法性 LoginBO类的setIUserDAO()方法 Setter方法，在业务逻辑对象中注入数据访问对象（注意：此处针对抽象数据访问类编程 IUserDAO接口的findUserByAccAndPwd()方法 业务方法声明，经过用户帐号和密码在数据库中查询用户信息，判断该用户身份的合法性 UserDAO类的findUserByAccAndPwd()方法 业务方法实现，实如今IUserDAO接口中声明的数据访问方法 实例分析2——注册模块 某基于Java语言的C/S软件须要提供注册功能，该功能简要描述以下： 用户经过注册界面(RegisterForm)输入我的信息，用户点击“注册”按钮后将输入的信息经过一个封装用户输入数据的对象(UserDTO)传递给操做数据库的数据访问类，为了提升系统的扩展性，针对不一样的数据库可能须要提供不一样的数据访问类，所以提供了数据访问类接口，如IUserDAO，每个具体数据访问类都是某一个数据访问类接口的实现类，如OracleUserDAO就是一个专门用于访问Oracle数据库的数据访问类。 根据以上描述绘制类图。为了简化类图，我的信息仅包括帐号(userAccount)和密码(userPassword)，且界面类无需涉及界面细节元素。 参考解决方案： 在以上功能说明中，能够分析出该系统包括三个类和一个接口，这三个类分别是注册界面类RegisterForm、用户数据传输类UserDTO、Oracle用户数据访问类OracleUserDAO，接口是抽象用户数据访问接口IUserDAO。它们之间的关系以下： (1) 在RegisterForm中须要使用UserDTO类传输数据且须要使用数据访问类来操做数据库，所以RegisterForm与UserDTO和IUserDAO之间存在关联关系，在RegisterForm中能够直接实例化UserDTO，所以它们之间可使用组合关联。 (2) 因为数据库类型须要灵活更换，所以在RegisterForm中不能直接实例化IUserDAO的子类，能够针对接口IUserDAO编程，再经过注入的方式传入一个IUserDAO接口的子类对象（在本书后续章节中将学习如何具体实现），所以RegisterForm和IUserDAO之间具备聚合关联关系。 (3) OracleUserDAO是实现了IUserDAO接口的子类，所以它们之间具备类与接口的实现关系。 (4) 在声明IUserDAO接口的增长用户信息方法addUser()时，须要将在界面类中实例化的UserDTO对象做为参数传递进来，而后取出封装在UserDTO对象中的数据插入数据库，所以addUser()方法的函数原型能够定义为：public boolean addUser(UserDTO user)，在IUserDAO的方法addUser()中将UserDTO类型的对象做为参数，故IUserDAO与UserDTO存在依赖关系。 经过以上分析，该实例参考类图如图1所示： 图1 注册功能参考类图 注意：在绘制类图或其余UML图形时，能够经过注释(Comment)来对图中的符号或元素进行一些附加说明，若是须要详细说明类图中的某一方法的功能或者实现过程，可使用如图2所示表示方式： 图2 类图注释实例 实例分析3——售票机控制程序 某运输公司决定为新的售票机开发车票销售的控制软件。图I给出了售票机的面板示意图以及相关的控制部件。 图I 售票机面板示意图 售票机相关部件的做用以下所述： (1) 目的地键盘用来输入行程目的地的代码（例如，200表示总站）。 (2) 乘客能够经过车票键盘选择车票种类（单程票、屡次往返票和座席种类）。 (3) 继续/取消键盘上的取消按钮用于取消购票过程，继续按钮容许乘客连续购买多张票。 (4) 显示屏显示全部的系统输出和用户提示信息。 (5) 插卡口接受MCard（现金卡），硬币口和纸币槽接受现金。 (6) 打印机用于输出车票。 (7) 全部部件都可实现自检并恢复到初始状态。 现采用面向对象方法开发该系统，使用UML进行建模，绘制该系统的初始类图。 参考解决方案： 参考类图以下： 类说明： 类 名 说 明 Component 抽象部件类，全部部件类的父类 Keyboard 抽象键盘类 ActionKeyboard 继续/取消键盘类 TicketKindKeyboard 车票种类键盘类 DestinationKeyboard 目的地键盘类 Screen 显示屏类 CardDriver 卡驱动器类 CashSlot 现金（硬币/纸币）槽类 Printer 打印机类 TicketSoldSystem 售票系统类 方法说明： 方法名 说 明 Component 的init()方法 初始化部件 Component 的doSeltTest()方法 自检 Keyboard的getSelectedKey()方法 获取按键值 ActionKeyboard的getAction()方法 继续/取消键盘事件处理 TicketKindKeyboard的getTicketKind()方法 车票种类键盘事件处理 DestinationKeyboard的getDestinationCode()方法 目的地键盘事件处理 Screen的showText()方法 显示信息 CardDriver的getCredit()方法 获取金额 CardDriver的debitFare()方法 更新卡余额 CardDriver的ejectMCard()方法 退卡 CashSlot的getCredit()方法 获取金额 Printer的printTicket()方法 打印车票 Printer的ejectTicket()方法 出票 TicketSoldSystem的verifyCredit()方法 验证金额 TicketSoldSystem的calculateFare()方法 计算费用

 

 

参考三：

在UML的

类图中，常见的有如下几种关系: 泛化（Generalization）,  实现（Realization）, 关联（Association), 聚合（Aggregation）, 组合(Composition), 依赖(Dependency)

 

1.       泛化（Generalization）

【泛化关系】：是一种继承关系, 表示通常与特殊的关系, 它指定了子类如何特化父类的全部特征和行为. 例如：老虎是动物的一种, 即有老虎的特性也有动物的共性.

【箭头指向】：带三角箭头的实线，箭头指向父类

 

 

2. 实现（Realization）

【实现关系】：是一种类与接口的关系, 表示类是接口全部特征和行为的实现.

【箭头指向】：带三角箭头的虚线，箭头指向接口

 

3. 关联（Association)

【关联关系】：是一种拥有的关系, 它使一个类知道另外一个类的属性和方法；如：老师与学生，丈夫与妻子

关联能够是双向的，也能够是单向的。双向的关联能够有两个箭头或者没有箭头，单向的关联有一个箭头。

【代码体现】：成员变量

【箭头及指向】：带普通箭头（或实心三角形箭头）的实心线，指向被拥有者

 

上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。

 

上图为自身关联：

 

4. 聚合（Aggregation）

【聚合关系】：是总体与部分的关系, 且部分能够离开总体而单独存在. 如车和轮胎是总体和部分的关系, 轮胎离开车仍然能够存在.

聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上没法区分，必须考察具体的逻辑关系。

【代码体现】：成员变量

【箭头及指向】：带空心菱形的实心线，菱形指向总体

 

 

5. 组合(Composition)

【组合关系】：是总体与部分的关系, 但部分不能离开总体而单独存在. 如公司和部门是总体和部分的关系, 没有公司就不存在部门.

       组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中表明总体的对象负责表明部分的对象的生命周期

【代码体现】：成员变量

【箭头及指向】：带实心菱形的实线，菱形指向总体

 

 

6. 依赖(Dependency)

【依赖关系】：是一种使用的关系,  即一个类的实现须要另外一个类的协助, 因此要尽可能不使用双向的互相依赖.

【代码表现】：局部变量、方法的参数或者对静态方法的调用

【箭头及指向】：带箭头的虚线，指向被使用者

 

 

 

各类关系的强弱顺序：

泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

下面这张UML图，比较形象地展现了各类类图关系：

 

 

====================================================

序列图主要用于展现对象之间交互的顺序。

序列图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴表明了在协做中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。

消息用从一个对象的生命线到另外一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

 

序列图中涉及的元素：

1.   生命线：

生命线名称可带下划线。当使用下划线时，意味着序列图中的生命线表明一个类的特定实体。

 

 

2.       同步消息

发送人在它继续以前，将等待同步消息响应

 

3.       异步消息

在发送方继续以前，无需等待响应的消息

 

4.       注释

 

5.       约束

约束的符号很简单；格式是: [Boolean Test]

 

6.       组合片断

组合片断 用来解决交互执行的条件及方式。 它容许在序列图中直接表示逻辑组件，用于经过指定条件或子进程的应用区域，为任何生命线的任何部分定义特殊条件和子进程。

经常使用的组合片断有：

a.       抉择（Alt）

抉择用来指明在两个或更多的消息序列之间的互斥的选择，至关于经典的if..else..。

抉择在任何场合下只发生一个序列。 能够在每一个片断中设置一个临界来指示该片断能够运行的条件。 else 的临界指示其余任何临界都不为 True 时应运行的片断。 若是全部临界都为 False 而且没有 else，则不执行任何片断。

 

 

b.       选项（Opt）

包含一个可能发生或不发生的序列

c.       循环（Loop）

片断重复必定次数。 能够在临界中指示片断重复的条件。

 

d.       并行（Par）

 

下表列出了经常使用的组合片断：

片断类型	名称	说明
Opt	选项	包含一个可能发生或可能不发生的序列。 能够在临界中指定序列发生的条件。
Alt	抉择	包含一个片断列表，这些片断包含备选消息序列。 在任何场合下只发生一个序列。 能够在每一个片断中设置一个临界来指示该片断能够运行的条件。 else 的临界指示其余任何临界都不为 True 时应运行的片断。 若是全部临界都为 False 而且没有 else，则不执行任何片断。
Loop	循环	片断重复必定次数。 能够在临界中指示片断重复的条件。 Loop 组合片断具备“Min”和“Max”属性，它们指示片断能够重复的最小和最大次数。 默认值是无限制。
Break	中断	若是执行此片断，则放弃序列的其他部分。 可使用临界来指示发生中断的条件。
Par	并行	并行处理。 片断中的事件能够交错。
Critical	关键	用在 Par 或 Seq 片断中。 指示此片断中的消息不得与其余消息交错。
Seq	弱顺序	有两个或更多操做数片断。 涉及同一辈子命线的消息必须以片断的顺序发生。 若是消息涉及的生命线不一样，来自不一样片断的消息可能会并行交错。
Strict	强顺序	有两个或更多操做数片断。 这些片断必须按给定顺序发生。

 

有关如何解释序列的片断

默认状况下，序列图代表可能发生的一系列消息。 在运行的系统中，可能会出现您未选择显示在关系图上的其余消息。

如下片断类型可用于更改此释义：

片断类型	名称	说明
Consider	考虑	指定此片断描述的消息列表。 其余消息可发生在运行的系统中，但对此描述来讲意义不大。 在“Messages”属性中键入该列表。
Ignore	忽略	此片断未描述的消息列表。 这些消息可发生在运行的系统中，但对此描述来讲意义不大。 在“Messages”属性中键入该列表。
Assert	断言	操做数片断指定惟一有效的序列。 一般用在 Consider 或 Ignore 片断中。
Neg	否认	此片断中显示的序列不得发生。 一般用在 Consider 或 Ignore 片断中。

 

====================================================

用例图主要用来描述 用户、需求、系统功能单元 之间的关系。它展现了一个外部用户可以观察到的系统功能模型图。

【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。

 

用例图所包含的元素以下：

1.       参与者(Actor)

表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。

 

2.       用例(Use Case)

 用例就是外部可见的系统功能，对系统提供的服务进行描述。 用椭圆表示

3.       子系统(Subsystem)

用来展现系统的一部分功能，这部分功能联系紧密。

 

4.       关系

用例图中涉及的关系有：关联、泛化、包含、扩展；

以下表所示：

关系类型	说明	表示符号
关联	参与者与用例间的关系
泛化	参与者之间或用例之间的关系
包含	用例之间的关系
扩展	用例之间的关系

a.       关联(Association)

表示参与者与用例之间的通讯，任何一方均可发送或接受消息。

【箭头指向】：指向消息接收方

 

 

b.      泛化(Inheritance)

就是一般理解的继承关系，子用例和父用例类似，但表现出更特别的行为；子用例将继承父用例的全部结构、行为和关系。子用例可使用父用例的一段行为，也能够重载它。父用例一般是抽象的。

【箭头指向】：指向父用例

c.       包含(Include)

包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤；

【箭头指向】：指向分解出来的功能用例

 

d.      扩展(Extend)

    扩展关系是指 用例功能的延伸，至关于为基础用例提供一个附加功能。

   【箭头指向】：指向基础用例

 

 

e.       依赖(Dependency)

以上4中关系，是UML定义的标准关系。 但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示

表示源用例依赖于目标用例；

【箭头指向】：指向被依赖项

 

5.       项目(Artifact)

用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人可以通看懂它。不少时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员可以在用例图中连接一个普通文档。

用依赖关系把某个用例依赖到项目上

 

而后把项目-》属性 的Hyperlink 设置到你的文档上

这样当你在用例图上 双击项目时，就会打开相关联的文档。

 

6.       注释(Comment)

 

 

包含(include)、扩展(extend)、泛化(Inheritance) 的区别：

条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；

直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。

对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。

对Inheritance而言，子用例包含基础用例的全部内容及其和其余用例或参与者之间的关系；

 

一个用例图示例：

 

 

牢骚：

感受用例图还不成熟，并不能很好地表达系统的需求， 没有UML背景的用户几乎不知道画的些什么。

其次，包含关系、扩展关系 的箭头符号居然是一样的箭头，仅靠上方写个文字来加以区别，翻译成其余语言的话，几乎就不知道表明什么意思。  扩展关系的箭头朝向也很难理解，为什么要指向基用例，而不指向扩展用例

VS2010添加的“项目”元素，是个很好的创新，可以在用例图中关联word,excel这些文档。但为何不把这些功能直接集成到用例里面，双击用例就弹出一份文档岂不更容易理解，非要多此一举地加一个元件，仅仅为了提供个连接功能。

 

 

用例描述表：

鉴于用列图并不能清楚地表达功能需求，开发中你们一般用描述表来补充某些不易表达的用例，下图的表给你们提供一个参考：