【软件设计与体系结构】用例图、类图、时序图

引入：

         

 

（将【泛化】的实线改为虚线则表示【实现】）

（一条实线加一个菱形表示【聚合】） 

1、用例图

1.用例图 组成

1.1 图形符号

1.2 用例名称

 1.3 参与者

        参与者所代表的角色有：人、硬件设备，或甚至 是另一个系统。

        例如：如果你在银行工作，你可能是一个贷款员， 如果你在该银行有存款，那么你同时也扮演一名顾 客的角色。所以，一个参与者的一个实例代表以一 种特定的方式与系统进行单独的交互。

        注意：尽管在模型中使用参与者，但参与者实际上 并不是系统的一部分。

        可以定义参与者的一般种类（比如Customer） 并通过泛化关系将其特殊化（比如Commercial Customer）。

       

1.4 事件流

        可以通过足够清晰的、外部人员容易理解的文字 描述一个或一些事件流来说明一个用例的行为，也即 通过事件流来详述用例 

        事件流中应该包含用例何时开始、何时结束，用例何时和参与者交互，什么对象被交换，以及该行为的基本流（主事件流）和可选择流（异常事件流）。

        例：在ATM系统中，可以采用下面的主事件流和异常 事件流来描述用例Validate User的行为：

2. 用例之间的关系

        用例之间存在泛化关系、包含关系和延伸关系，我们可以利用这些关系来组织用例。

2.1 用例之间的泛化关系

        用例之间的泛化关系就像类之间的泛化关系，子（特殊）用例继承父（一般）用例的行为和含义；子用例还可以增加或覆盖父用例的行为；子用例可以出现在父用例出现的任何位置。

        例：ATM系统中的Validate User用例，根据校验设备 的不同可以特例化为以下二个特殊用例：Check Password用例和Retinal Scan用例。

2.2 用例之间的包含关系

        用例之间的包含关系表示基础用例在它内部说明的某个位置上显式地合并了另一个用例的行为。

        被包含的用例从不孤立（独立）存在，仅作为某些包含它的更大的基础用例的一部分出现。可以想象为，它向基础用例提供行为。

        可以将包含关系表示成一个构造型的include依赖关系（基础用例依赖于被包含的用例）

2.3  用例之间的延伸关系

        用例之间的延伸关系表示基础用例在由延伸用例间接地说明的一个位置上隐式地合并了另一个用例的 行 为 。

        基础用例可以单独存在，但在一定条件下，它的行为可以被另一个用例的行为延伸。该基础用例只是在一个被称为它的延伸点的确定位置上被延伸。该延伸点由延伸用例间接说明。

        可以将延伸关系理解为延伸用例把行为放入基础用例中。可以将延伸关系表示成一个构造型为extend的依赖关系。

3.识别用例

3.1 识别方法

3.1.1 通过捕获功能性需求来发现用例

        也即通过考察用户如何使用现有系统（可能是一个人工系统）完成他们的工作来发现用例

        每个能对用户增值的系统使用方式就是一个候选用例。对这些候选用例进行详细说明，改变、划分为更小的用 况或相反地结合成更加完整的用例。 当以客户、用户和开发人员都能理解的方式正确地捕获 了全部的功能性需求，用例模型便基本完成了。

3.1.2 从非功能性需求中发现用例的附加成分

        用例除了描述功能需求之外，还可以说明某些非功能性需求，例如对某个用例特定的性能、可用性、准确度和安全性等的需求。这些都有必要作为用例的附加成分，附加到相应的用例中。

        例如：对于“取款”这一用例而言，应该附加下面的性能要求：银行储户从指定取款数量到得到相应的货币的响应时间在所有用例实例的95%中应该小于30秒。

3.2.实用的识别用例的方法和步骤

        比较实用的识别方法有以下两种：基于参与者的方法、基于事件的方法

3.2.1 基于参与者的方法

        a. 识别出与系统或组织有关的参与者。

        b. 对每个参与者，识别出他们发起或参加的执行过 程（业务过程），这些执行过程就是候选用例。

        例：找出销售点终端系统的可能的参与者及他们发起 或参加的活动。

        

3.2.2  基于事件的方法

a. 识别出系统必须响应的外部事件。 b. 把事件与参与者及用例联系起来。

4.用例模型

        系统的所有参与者和用例以及用例之间的关系（依赖、延伸、泛化等）构成用例模型。

        参与者“银行储户” 使用ATM从帐户中 取款，或存款到帐户中，或在不同的帐户之间转帐。上述行为可以由三个用例与“银行储户” 这个参与者之间的交互来表示。

        用例模型是所有可能使用系统（用例）的方式的完整的规格说明，它可以用作与客户签定合同的一部分。用例模型用来与用户和客户在“系统应该做什么”方面达成共识。也即用例模型表示功能性需求。

5、用例图

6.识别参与者

        通过以下几组事物来识别系统周围的参与者：

例题：

        学生注册的主要业务包括：报到与注册、缓缴费、缓注册的申请与审批 、报到、注册情况的查询与统计。

（1）注册业务需求概述（续）

         报到与注册：学生利用校园卡刷卡报到，注册代理通过“一卡通刷卡报到接口”获取报到信息、通过“财务缴费接口”获取学生缴费信息、通过共享数据库获取学生的学籍信息、处分信息，实施自动注册，当“已按时报到”、“已按要求缴费或已获准缓交学费”，“上一学年未受开除学籍处分或退学处理”等三个条件同时满足，则予以注册，否则暂不予以注册。

        缓缴费、缓注册的申请与审批： 学生可以在网上申请缓交学费，此申请必须经过所在院（系）审核及财务处审批。因特殊情况无法及时到校的学生可以在网上申请缓注册，此申请必须经过所在院（系）审核及教务处审批。

        报到、注册情况的查询与统计：教务处、财务处、学生处及有关校领导可以及时了解全校学生的报到、注册情况，并获得所需的各种统计数据（报到率、注册率、缴费率、欠费情况、申请缓缴费情况等）。 各院（系）可以及时了解本院（系）学生的报到、注册情况，并获得所需的各种统计数据（报到率、注册率、缴费率、欠费情况、申请缓缴费情况等）。

（2）注册系统功能概述

        由上述业务需求可以提炼出该系统的主要功能如下： 报到、自动注册、缓缴费申请与审批（工作流）、缓注册申请与审批（工作流）、报到情况查询与统计、注册情况查询与统计、系统维护。

 2.类图

        其基本元素包括：组成应用系统的基本单元——各个对象类； 对象类之间的关系——关联、依赖、泛化。

2.1 类图图标

2.2 命名规范

        属性名是描述属性所在类的一些特性的名词或名词 短语，因此，通常要将属性名中除第一个词之外的每 一个词的第一个字母大写。例如：name（单个名词），loadBearing（名词短语）

        操作名是描述它所在类的一些特性的动词或动词短语，因此，通常要将操作名中除第一个词之外的每一 个词的第一个字母大写。例如：move（单个动词）、isEmpty（动词短语）

        某些情况下属性和操作可以省略，此时类的符号就 仅是一个只标记类名的矩形。

例：识别一个零售系统所包含的事物并用类抽象之 （对词汇建模）。

2.3 识别类

        从问题陈述中找出与问题域有关的事物（主要是 结构事物），形成候选类组，然后去除其中一些虚假 的类，形成确定类组，这一过程称为识别类。

        1）识别对象类的方法

        常用的方法有现实分析法（基于用例的分析技术） 和语法分析法。

        基本思想：确定问题陈述所涉及的哪些活动（业 务过程）是与需求密切相关的，分析这些活动涉及到 哪些具体的事物、概念、过程，遵循哪些规则等，它 们都可能是系统内部的对象类。

        客观事物的分类。通常可以分为以下五大类：

        识别过程中重点关注的事物：

        a.问题域中任何需要以某种方式存储、转换、分 析或处理的信息，这些信息可能就是类的候选者。这 里，信息可以是在系统中总是必须被记录的那些概念， 或者是系统在特定时刻发生的事件或事务。

        b.问题域所涉及的外部系统。当我们建模时，外部 系统可以看作是我们的系统包含的或者应该与之打交 道的类。

2）语法分析法

         基本思想：在问题陈述中，对象类（结构事物）通常 对应于名词或名词词组（或短语），因此从问题陈述 中（或术语表中）找出（摘取）所有的名词或名词词 组，就得到大多数的“候选类” ，运用排除法（参照 排除规则），可以排除虚假的类，就获得确定的类组

2.4排除虚假类

        问题陈述中的冗余实体、与问题无关的部分，对 于实体属性的描述等等，都属于虚假类，应以予排除

        判断虚假类的准则:

        （1）冗余类：如果多个类表示同一信息，保留最能 描述这种信息的类。例如，候选类组中的客户类和用户类是重复描述， 因此去掉用户类，保留客户类。

        (2）无关类：是指与问题没什么关系的候选类。

        （3）模糊类：是指其边界可能存在非法定义或范围过 宽的类。 例如，ATM网络中费用的分担与问题无关，应当 排除。 例如，候选类组中的系统、安全装置、银行网络、 保存记录装置等类都属于模糊类（范围过宽），应当 排除。

        （4）属性：某些名词可能是对特定实体的属性的描述， 不应该视为对象类。 例如，候选类组中的帐目数据、收据、现金、业 务数据等类都属于某些类的属性，应该排除。

        （5）操作：问题陈述中有时可能使用一些兼有名词和 动词二种词性的词，这样的词通常作为动词，因此就应 该是类的操作而不是类。 例如，打电话时的“拨号” ，明显是一个操作而 不是一个类。

        （6）角色：问题陈述中涉及关联描述时会强调角色的 作用，因为角色是名词，因此有可能会被识别成类。 例如，对于“雇主管理雇员”这样的陈述，雇主和 雇员都是角色而不是类。

2.5类之间的关系

       2.5.1 依赖（dependency）关系

        依赖（dependency）关系是两个事物间的语义关系 （使用关系），其中一个事物（规格说明）发生变化 会影响另一事物，反之未必。 例如：Event和Window之间的关系：Window使 用Event，因此二者之间存在依赖关系：

        依赖的图形符号是一条有向的虚线，指向被依赖的 事物（类）。

        当要指明一个事物使用另一个事物时，就使用依赖。依赖可以带有名称，但很少使用这种修饰，一般情况下，用构造型来区别依赖的不同含义。 例如：用例之间的包含关系是一种依赖关系， 可以用构造型<>标记之。

例题：

例1：选课系统中课程调度和课程之间存在依赖关系， 因为课程调度的添加课程操作add(c:Course)和删除课 程操作remove（c:Course）均以course的对象作为参 数。

2.5.2 泛化

        泛化（generalization）关系是一种“特殊/一般” 关系，也即特殊事物和一般事物之间的关系，也称 为“is-a-kind-of ”关系（一个事物是一个更一般的 事物的“一个种类”）。 泛化意味着特殊类继承了一般类的性质，同时还 可以定义一般类所没有的性质，因此可以被用在一般 类对象可能出现的任何地方，也即特殊类可以替代一 般类。

        泛化的图形符号是一条带有空心大箭头的有向实现， 由特殊类指向一般类。

        

        当要表示事物之间的“一般/特殊”关系时，就使用 泛化。  使用泛化关系，蕴涵着指明了事物之间的继承关系， 因此可以利用泛化关系为继承建模，继承通常发生在 类和类的接口之间。  一般/特殊的层次大于等于2，也即存在多于两层的继 承。但在继承格中不允许出现循环，即一个给定的类 不能是它自己的父类。泛化可以带有名称，但很少使用这种修饰，除非模 型中有许多泛化而且要引用它们时，才使用名称 

例题：

        例2 在一个外汇兑换系统中存在有“出纳抽屉” 、 “支行储备金”和“总行储备金”三个类，我们抽取 这三个类中有关库存资金的一些共同的性质（共同的 行为特征和结构特征），就得到更一般的概念（事 物）—“库存” ，它和上述三种资金之间存在“泛化” 关系：

2.5.3 关联

        关联是类之间的一种结构关系，它描述一组链， 也即指明一个类的对象与另一个（或一些）类的对 象间的联系的形式（链属性）

        例1：公司类和员工类之间存在这样一种关联，即“员工 为公司工作”——“Work for”；

        

例2：银行类和帐户类之间存在着“持有”关联，每 个银行持有很多帐户。

         应用于关联的规则与修饰： 名称 角色 多重性 聚合

        关联的名称用来描述该关系的性质。 名称的方向，为了消除名称含义的歧义，可以提供 一个引读名称方向符（►）。 注意：一般情况下，关联的名称并不是必须的，只 有在下述几种情况下才需要名称： （1）关联加上角色修饰时，角色之间呈现什么关系； （2）当一个模型有很多关联，且需要对这些关联 进行查阅或区别时； （3）一个类上出现多个关联时。

例题：

例3：帐户和顾客是外币兑换系统的两个类，它们之 间存在着“持有”的一对多关联，一个顾客可以持有 令到多个帐户、一个帐户只对应一个顾客，试给出对 应的多重性表达式：

2.5.4.聚合

        聚合用来表示事物之间的“整体/部分”关系， “整 体”事物是一个较大的事物，它是由多个“部分”事 物（较小的事物）组成的。 “整体”事物可以抽象为 组合类， “部分”事物可以抽象成组元类。

        例4: 微型计算机是由监视器、主机、鼠标、键盘等设 备组成的，主机是由CPU、内存等设备组成的，试给 出其多级聚合结构：

例5: 公司是由一些部门组成的，因此公司是组合，而 部门是组元。

        聚合修饰符：一个菱形框。

        聚合是一种特殊的关联，一般的关联关系表示了具 有同等地位的多个类之间的结构关系，该关系是动态 建立的，而聚合描述了“has a”关系，意即整体对象 拥有部分对象，该关系是构造组合事物时静态建立的， 因此聚合是一种静态关联。

2.6 关联类

2.7 类图举例：

3、交互图

        UML用以下二种方式来 描述和解释控制流：

                 方式一，关注消息是如 何按照时间顺序调度—— 用顺序图表示。

                方式二，关注交互中对 象间的结构关系，并考虑 消息是如何在此结构的语 境中被传递的——用协作 图表示。

        交互 是指在语境中由实现某一目标的一组对象之间 进行交换的一组消息所构成的行为。 请注意两个关键短语：一组对象、一组消息。 对象是活动的主体（即行为的作用者），而消息则是 传送与活动有关的信息的主要手段。

        对象和角色 ：参与交互的对象既可以是具体的事物，又可以是 原型化的事物。 作为具体事物，一个对象是确定的，例如p作为 person的一个实例，它代表一个特定的人。 作为原型化的事物，则是一种“泛指” ，例如p 代表person的任何一个实例。

        在一个协作中，对象是指扮演特殊角色的原型化 事物，而不是一个特定的事物。交互图上的对象就是 这样一种对象。

3.1图标

3.2 相关概念 

3.2.1 链

 

3.2.2 消息  

        消息是对象发出的服务请求，也即，是对传送信 息的对象之间所进行的通讯的详述，该信息带有对将 要发生的活动的期望。 

         消息的图形表示法：消息被表示成一条有方向的直 线，通常还包含相应的操作名：

3.2.3 调用

        调用某个对象的一个操作，对象也可以给自己发 送消息，这将导致操作的局部引用，也即对象调用自 己的操作。 

        返回（Return）：返回一个值给调用者。

        发送（Send）：向对象发送一个信号。

        创建（Create）：创建一个对象。

         撤消（Destroy）：撤消一个对象，对象也可以撤消自己

        多数情况下，参与交互的对象将在整个交互过程 中存在，但也存在对象在交互过程中被创建和被撤消 （销毁）的情况。  如果一个对象在交互中创建，则该对象的生命线就 从接收到一个标有构造型《create》的创建消息之时 开始。  如果一个对象是在交互中销毁的，则该对象的生命 线就从接收到一个标有构造型《destroy》的销毁消 息之时终止。对象的销毁标志是在其生命线的终端部 标上一个“X” 。

        对象和消息是构成交互的主要元素，UML提供两 种图，即顺序图和协作图来可视化地表示这两者。  顺序图：强调消息的时间顺序。  协作图：强调发送和接收消息的对象的结构组织。 顺序图和协作图都属于交互图，它们在很大程度 上是同构的，也即这两种图可以相互转换而不会丢失 任何信息。但两者至少在视觉上存在差异，顺序图允 许对一个对象的生命线建模，而协作图允许对链建模

例题：

        下面给出对一个发行和订阅机制的控制流建模的 两种表示法——顺序图和协作图。 该机制包含3个对象，p、s1、s2：p是Stock Quote Publisher类的实例。 s1、s2是StockQuoteSubscriber类的实例

3.3 步骤

        1. 设置交互的语境

        语境可以是整个系统、一个协作、一个类也可能 是一个操作

        2. 通过识别各个对象在语境中扮演的角色来设置交互 的场所。 主要是设置这些对象的初始特性，包括属性值、 状态和角色。

        3. 如果想构造协作图，则需识别连接对象的链以及发 生在这个交互中的通信的相关路径。

        4.按照时间顺序，描述由对象发给对象的消息。 必要时，可以通过区分消息的不同类型来传递该 交互的必要细节，主要包括参数和返回值。

        5. 为了传递交互的必要细节，还可以用每个对象在每 个时刻的状态和角色来修饰该对象。

3.4 例图

        

         顺序图由：对象、对象生命线、激活期和消息等图形 元素构成。

        对象：一般只给出名称，对象图标一般位于顺序图 的顶部，布局以能够使图形尽量简洁为主。

        对象生命线：表示对象存在的时间，在顺序图中， 生命线表示为：从对象图标向下延伸的一条虚线。生 命线从对象创建开始到对象销毁时终止。

         激活期：又称为控制焦点，表示对象执 行一个动作的时间段。在顺序图中，激活 期由位于生命线上的一个窄矩形框表示。

3.5 例题

        例：对“买饮料用例”的控制流建模：一个理想的买饮料 场景（有饮料并且投入的钱数正确），有四个对象角色： 顾客：买饮料； 前端：饮料售货机与顾客之间的接口； 钱币记录仪：负责收集顾客投入的钱币； 分配器：负责取饮料递给前端。

        四个对象类角色之间的交互序列： （1）某顾客向机器前端投币口投入正确的钱币； （2）顾客选择有存货的饮料品种； （3）钱币被传送到记录仪； （4）记录仪控制分配器将一罐饮料投递到销售机的前端。 试给出该交互的顺序图。