用例建模在线视频

同学们 今天我们学习面向对象分析与设计这门课的第八部分

活动图

在学习活动图之前 我们先回顾下上节课学习的用例模型

用例模型描述了软件的需求

在用例模型中 对每个用例都有用例规约

在用例规约中最重要的是事件流

事件流描述了对一个用例 软件是如何一步步进行执行

也就是说描述了软件在用例中的控制流

如果一个用例的事件流很复杂

它有基本流有可选流 而且基本流与可选流又交互在一起

如果只是用文字描述可能很难理解

这种情况下我们就可以引入活动图

以图形的方式来描述软件用例的用例规约

下面我们介绍一下活动图 活动图主要有以下几个基本元素

第一个元素就是活动

如图所示的矩形 四个圆角边的矩形

它代表了一个基本活动

每个基本活动可能还有它所伴随的对应的动作

在活动图中每个箭头描述了一个活动的迁移

箭头是有方向的 它表示从前一个活动迁移到后续的活动

另外 在活动迁移过程中

我们用这种方括号表示

中间写入的内容我们称之为守护条件

守护条件表示只有在守护条件为真的情况下

这种活动迁移才是被允许的或者说是合法的

也就是说 当守护条件为真的时候

我们才可以从前一个活动迁移到后一个活动来

另外比较重要的元素是分支

所有的分支活动只能有一个进入

可以有两个或者多个离开

在每一个离开分支上都必须标注有守护条件

同时每一条离开路线分支必须是互斥的

换句话说 在不同分支上的守护条件

在任何情况下 有且只能有一个为真

另外我们在活动图中引入了并发条的概念

并发条分为两类 一类称之为分支（Fork）

它表示活动进入到这个并发条之后 会同时启动两个并发的线程

或者说有两个并发的线程活动 来执行活动

这两个并发的线程是完全独立的

从这条并发条开始 分支成两个并发线程之后

哪个并发线程先完成哪个后完成是不确定的

为了让两种并发线程同步起来

我们有了第二种并发条 将它称之为联合

如图所示 这两个并发线程必须在这个地方进行联合

也就是说它们两个必须在这个地方同步等待

任何一个活动到这个地方都必须等待另外一个线程也活动到这个地方以后

它们才会共同的向下去执行

所以我们把它称之为并发条的联合

在活动图中 每个活动图都要有一个开始符号

开始符号标记了整个活动的起始

整个活动触发之后都会从开始符号进行执行

当然我们知道这个开始符号是一个假的开始

所以这个开始符号会有一个箭头直接指向真正的第一个开始活动

在活动图中可能会有一个也可能会有多个结束符号

我们看这个结束符号有点像牛的眼睛

在活动图中也可以没有结束符号

如果没有结束符号 那么说明这个活动会永远循环的连续运行

或者说可以有一个或者多个结束符号

一个或者多个没有什么区别

只是为了整个活动图的整齐美观

我们才来决定画一个或者多个结束符号

我们把活动图做一个变形 我们称之为分区图

我们把活动分在不同的分区里面 也称之为泳道图

泳道图和普通活动图的区别在于

在每一个泳道的上方我们来标记

这个泳道中的所有的活动是由哪个角色来执行或者说负责完成的

如图所示 销售员需要做这些活动

填单的需要做另外一个活动

所以泳道图和普通的活动图相比 通过泳道

可以方便我们很快的了解每个活动的执行者是谁

或者说谁负责来执行这个活动

活动图我们就介绍到这里

下面我们介绍一个需求的概念叫术语表

我们的软件是面向某个行业领域来解决这些行业领域的问题

对于软件开发人员来说

他对于行业或领域的问题并不是非常清楚

这样我们在需求分析阶段我们需要建立整个软件的术语表

在术语表中我们定义整个软件中常用的重要的一些基本概念和名词

我们将这些概念或者名词定义出来 给出它的标准解释

这样在软件开发过程中 不光是需求工程师

包括后期的架构师 设计师 测试人员都可以通过查阅术语表

对这个行业或者领域中的概念 名词 有一个统一的准确的认识

术语表第一部分往往是对文档的概述介绍

最重要的是第二部分

对整个行业领域中的关键概念 名词或者术语的准确解释

在需求分析中 用例模型描述了整个系统的功能需求

除了功能需求以外 软件还有一些非功能性需求

我们将其描述在补充说明书或者说附加说明书里面

在附加说明书中 它的主要内容有这么几个

第一个是功能性 我们前面讲

每一个用例已经描述了系统的功能性需求

但是整个系统全局的

和多个用例相关的公共的一些功能

我们就将它定义在附加规格说明书中

第二个非功能性需求我们称之为易用性 Usability

易用性要来描述定义软件的操作使用 用户对软件的学习是如何要求的

或者说用户能够很方便的学习掌握软件的操作过程

第三个是可靠性

可靠性定义软件在指定的运行环境下

能够成功运行的概率 我们称之为可靠性

我们一般衡量软件可靠性的指标有

平均无故障运行时间和平均故障修复时间等

第四个我们称之为性能

性能描述了软件对用户的响应

当用户对软件发出请求之后

系统在多长时间能对用户给出响应结果

性能和负载是相关的

软件在不同的负载下其响应时间可能是不一样的

第五个称之为可支持性

软件系统在运行过程中

需要我们的开发人员对用户提供各种支撑服务

比如我们的用户在使用过程遇到问题中需要电话服务甚至现场服务

另外还包括我们给用户提供的培训服务等等

我们都把它称之为可支持性

最后一个是设计约束

在需求阶段我们主要描述系统的功能 非功能性的一些需求

设计是基于需求来做

用户可能会对软件设计从用户角度提出一些设计要求

我们称之为设计约束

例如说用户之前用的是C语言的系统

他的人员对于C语言比较熟悉

他可能就会要求整个项目采用C语言来开发

用户可能对于Windows系统比较熟悉

他可能就要求我们的系统基于Windows平台来开发

用户可能对oracle数据库比较熟悉

他可能就会指定我们的数据库系统采用oracle数据库 等等

我们把这些称之为设计约束

我们把这些所有的东西写一个文档中

这个文档就是我们所说的需求的附加规格说明书

所以需求的附加规格说明书也是我们软件需求的一个重要组成部分

同学们 我们今天的内容首先介绍了活动图

我们可以用活动图来描述复杂的事件流

以图形可视化的方式描述复杂事件流

当然 活动图不仅仅可以用来描述事件流

同样可以用来描述程序设计中的一些复杂算法

第二个我们介绍了术语表

术语表定义我们开发软件最重要最基本的一些概念

使得软件开发的参与者能够对这些领域的专业基本概念有一个统一清楚的认识

最后我们介绍了附加规格说明书

它定义了软件系统的一些公共功能

还有可用性 可靠性 性能等非功能性需求以及设计约束

术语表 附加规格说明书和我们之前介绍的用例图

三个合在一起就构成了我们面向对象分析与设计的整个软件需求分析成果

谢谢大家