2-UML基础知识扫盲-学习笔记(20200512)

（一）用例图

（1）要用好UML，要多多培养：（1）书面表达能力；（2）归纳总结能力；（3）“面向对象”的思维能力和抽象能力；

（2）下面通过这个表格来总结一下我在需求分析工作中应用各种UML图的情况：

（3）用例图：用例图源于Jacobson的OOSE方法，用例图是需求分析的产物，描述了系统的参与者与系统进行交互的功能，是参与者所能观察和使用到的系统功能的模型图。它的主要目的就是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的“角色”关系以及系统各个功能之间的关系。它通过用例（Use Case）来捕获系统的需求，再结合参与者（Actor）进行系统功能需求的分析和设计。

用例图表达的是什么角色通过软件系统能做什么事情，我们可以使用用例图系统地表达软件系统的绝大部分需求。

（4）用例图有四部分组成：用例（Use Case）、参与者（Actor）、系统边界、关联

参与者：在一个系统开发前，我们必定首先要确定系统的用户，系统的用户就是系统的参与者。除此以外，我们还会想打，我们开发的系统与其他的系统有什么关联？因此，系统的参与者可分为两类，一类是人，包括系统的使用者、维护者等，另外一类是其他系统。

用例：用例（Use Case）是参与者（Actor）可以感受到的系统服务或功能单元。任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例，所以识别用例的最好方法就是

从分析系统参与者开始，在这个过程中往往会发现新的参与者。用例是有粒度的，用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。

系统边界：所谓系统边界是指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称之为系统环境。

关联：为了减少模型维护的工作量、保证用例模型的可维护性和一致性，可以在用例之间抽象出包含（Include）、扩展（Extend）和泛化（Generalization）这几种关系；

包含关系是指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。

包含指的是一个用例（基用例）可以包含其他用例（包含用例）具有的行为，其中包含用例中定义的行为将被插入基用例定义的行为中。

包含的两个基本约束：

1）基用例可以看到包含用例，并需要依赖于包含用例的执行结果，但是它对包含用例的内部结构没有了解；

2）基用例一定会要求包含用例执行。

包含表示为一个虚线箭头附加上《include》的构造型，箭头从基用例指向包含用例。

扩展关系是指在一定条件下，把新的行为加入到已有的用例中，获得的新用例称为扩展用例（Extension），原有的用例称为基础用例（Base）。

扩展指的是一个用例（扩展用例）对另一个用例（基用例）行为的增强。扩展使用一个附加了《enxtend》构造型的虚线箭头表示，箭头指向基用例。注意：扩展与包含的箭头方向是相反的，这表明扩展取决于扩展用例而非基用例，扩展用例决定扩展的执行时机，基用例对此一无所知。

扩展用例的使用包括四个部分：

基用例：需要被扩展的用例，“注册”用例。

扩展用例：提供所添加的行为序列的用例，如图5-10中的“检查实名信息”用例。

扩展关系：使用虚线箭头表示，箭头指向基用例。

扩展点：基用例中的一个或多个位置，表示在该位置会根据某条件来决定是否要中断基用例的执行从而执行扩展用例中的片段。

包含、扩展的区别：根本区别，包含是无条件执行，扩展是有条件执行。图的起点不同，终点也不同。

泛化关系是指一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。

（二）类图

1、什么是类图

类图(Class diagram)主要用于描述系统的结构化设计。类图也是最常用的UML图，用类图可以显示出类、接口以及它们之间的静态结构和关系。

2、类图的元素

在类图中一共包含了以下几种模型元素，分别是：类（Class）、接口（Interface）、依赖（Dependency）关系、泛化（Generalization）关系、关联（Association）关系、聚合关系（Aggregation）、组合关系（Composition）和实现（Realization）关系。

2.1 类（Class)

在面向对象（OO) 编程中，类是对现实世界中一组具有相同特征的物体的抽象。产生于分析阶段，由系统分析师绘制，主要作用是描述业务实体的静态结构，包括业务实体、各个业务实体所具有的业务属性及业务操作、业务实体之间具有的关系。

2.2 接口（Interface）

接口是一种特殊的类，具有类的结构但不可被实例化，只可以被实现（继承）。在UML中，接口使用一个带有名称的小圆圈来进行表示。

2.3 依赖（Dependency）关系

依赖关系是指两个或多个类之间的依存关系，如植物类依赖于土壤类。依赖关系还可以再细分为5种类型，分别是绑定（Binding）依赖、实现（Realization）依赖、使用（Usage）依赖、抽象（Abstraction）依赖和授权（Permission）依赖。依赖关系用虚线箭头来表示，箭头指向为依赖的方向。

2.4 泛化（Generalization）关系

简单的讲就是类之间的继承关系。在UML中，泛化关系用空心三角形+实线来表示，箭头指向为父类。

2.5 聚合（Association）关系

聚合关系是类之间的一种较弱的耦合关系，如一个字符串数组和一个字符串就是一种聚合关系。在UML中类图中，聚合关系用空心的菱形+实线箭头来表示，箭头指向为被聚合的类。

2.6 组合（Aggregation）关系

组合关系是类之间一种整体与部分之间的关系，如一只青蛙有四条腿，青蛙类与青蛙腿类之间的关系就是组合关系。在UML类图中，组合关系用实心的菱形+实线箭头来表示，箭头指向为被组合的类。

2.7 关联（Composition）关系

关联关系是类之间一种相互影响的关系，影响的方向就是关联的方向。在UML类图中，组合关系用实线箭头来表示。

2.8 实现（Realization）关系

一般来讲实现关系是针对类与接口之间的关系而言的。在UML类图中，实现关系用空心三角形+虚线来表示。

3、简单的类图示例

用例描述与文档

用例描述概述：一个完整的用例模型应该不仅仅包括用例图部分，还要有完整的用例描述部分。一般的用例描述主要包括以下几部分内容：

（1）用例名称：描述用例的意图或实现的目标，一般为动词或动宾短语。

（2）用例编号：用例的唯一标识符，在其他位置可以使用该标识符来引用用例。

（3）参与者：描述用例的参与者，包括主要参与者和其他参与者。

（4）用例描述：对用例的一段简单的概括描述。

（5）触发器：触发用例执行的一个事件。

（6）前置条件：用例执行前系统状态的约束条件。

（7）基本事件流（典型过程）：用例的常规活动序列，包括参与者发起的动作与系统执行的响应活动。

（8）扩展事件流（替代过程）：记录如果典型过程出现异常或变化时的用例行为，即典型过程以外的其他活动步骤。

（9）结论：描述用例何时结束。

（10）后置条件：用例执行后系统状态的约束条件。

（11）补充约束：用例实现时需要考虑的业务规则、实现约束等信息。

前置条件与后置条件

前置条件指的是用例执行前系统和参与者应处于的状态。前置条件是用例的入口限制，它便于我们在进行系统分析及设计的时候注意到，在何时何地才可以合法地触发这个事件。

后置条件是用例执行完毕后系统处于的状态。后置条件是对用例执行完毕后系统状况的总结，用来确保用户理解用例执行完毕后的结果，并非其他用例的触发器。

前置条件与后置条件分别是用例在开始和结束时的必要条件。

事件流

事件流是对用例在使用场景下的交互动作的抽象，应该包括用例何时以及怎样开始和结束，用例何时与参与者交互，该行为的基本流和可选择的流。

基本事件流：描述的是用例中最核心的事件流，是用例大部分时间所进行的场景。

扩展事件流：描述的是用例处理过程中的一些分支或异常情况。

补充约束

补充约束用来描述用例在系统功能之外的内容，例如非功能需求、业务规则等等。

数据需求：与该用例相关的一些数据项的说明。

业务规则：与业务相关的逻辑和操作规则。

非功能性需求：例如性能、支持的并发量等。

设计约束：是从多个角度对用例或系统的约定。

用例图使用要点

1.构建结构良好的用例。用例图中应该只包含对系统而言必不可少的用例与相关的参与者。

2.用例的名称不应该简化到使读者误解其主要语义的程度。

3.摆放元素时应尽量减少连接线的交叉，以提供更好的可视化效果。

4.组织元素时应使在语义上接近的用例和参与者在图的位置上也同样接近，便于读者

5.理解用例图。

5.可以使用注解或给元素添加颜色等方式突出图中相对重要的内容。

6.用例图中不应该有太多的关系种类。

用例图建模技术

对系统的语境建模

识别系统边界。

识别参与者。

如果需要，将具有相同特征的参与者使用泛化关系加以组织。

如果需要，对某些参与者应用一个构造型以便加深理解。

将参与者应用到用例图中，并描述参与者与用例间的通信路径。

对系统的需求建模

识别参与者。

对于某个参与者，考虑其期望系统提供的行为或与系统的交互。

将行为提炼成用例。

完善其他用例。分解用例中的公共行为与扩展行为，放入新的用例中以供其他用例使用。

创建用例图。

如果需要，在用例图中添加一些注解或约束来陈述系统的非功能需求。

案例（1）学生选课系统

某学校的网上选课系统主要包括如下功能：

管理员通过系统管理界面进入，建立本学期要开的各种课程，将课程信息保存在数据库中并可以对课程进行改动和删除。

学生通过客户机浏览器根据学号和密码进入选课界面，在这里学生可以进行三种操作：查询已选课程，选课以及付费。

同样，通过业务层。这些操作结果存入数据库中。

步骤：1。确定系统边界。2.确定参与者（名词）。3.确定用例（动宾结构）。4.确定关系（联系）

参与者：学生、教务人员、数据库

用例：选课、查询、支付课时费用、登陆、修改课程、添加课程、删除课程

关系：关联关系、泛化关系