下面是这个用况的概念。
所谓用况就是参与者,在识别完参与者之后呢,
每个参与者可能与系统进行交互,交互它一个参与者
不一定是只有一项功能,也因此一个参与者可以对应很多的用况。
而用况呢就是指的参与者在使用系统一项功能时 与系统进行这个交互的过程。
体现这个 参与者和系统之间的一种对话,在对话过程中的一些
交互的一个描述,整个描述一个过程, 这个是 use case 的定义。
因此 use case 实际上呢 按照 Ivar Jacobson
的话说呢,实际上就是 相当一种对话,是用户和系统之间的一种对话。
它是为了完成一项功能时所使用的一种 交互过程。
但是它不是完整的功能,因为 很多功能呢实际上是在系统内部,它只是在这个
系统边界上用户和系统之间的一种对话,这是 用况。
用况这个,为什么要使用用况呢?这个
可以说呢,尽管我们现在是在需求分析阶段,描述的这个 用况图,但实际上这个用况图我们后面
实际上在需求分析、 系统分析、 系统设计,甚至是这个 实现、
测试,这每个阶段都会要 反复的要使用。
就是要使得我们,保障我们未来开发的系统在每个阶段 都要符合用户的需求,或者说便于与用户呢
发生这个一定的沟通,使得我们最后开发出来的这个 系统呢,符合用户的需求。
所以用况呢,实际上 是贯穿于我们整个这个软件生命周期的始终的。
在描述清楚用况之后呢,实际上就是对这个用户的需求也规范
规范化的一个描述,使得用户非常支离破碎的,不正规的,很难理解的
一些需求呢,被整理成一些非常清晰,非常明确,非常这个
容易理解的这么一些规范,使用用况一个方面的 原因。
另外呢就是,用况图本身也是一种,作为模型也是一种
软件开发中不同的人员的一种 有效交流的一种手段。
它呢实际上是 包括这个业务专家、 最终用户和开发者之间
为了这个清晰,或者说我们这个需求描述清楚,所以要 这个交流的一种手段。
而借助于这种这个需求,本身 use case 呢 是最简单的一种模型。
所以不仅是一种技术人员、 开发人员能够容易掌握,
最终用户,甚至是非软件领域的一些技术 这个一些领域专家也是经过
很短暂的一个学习也是很容易掌握的,非常符合人的自然的一种思维方式。
它是一种黑盒的一种方式,所以呢 便于软件开发中所有的这些相关的
利益相关的一些人员进行这个有效的交流。
大家这个如果是不借助于这种模型手段,比如说你这 用这个自然语言来描述很可能会造成一些
通信交流上的一些误差,对软件开发造成一些不利的影响。
另外呢,就对开发这个本身来说, 就是到了这个软件领域,全部都是由一些
具备软件开发知识的一些开发人员,他们也是
作为一种理解,本身要理解这个需求,系统需求是什么样的,也是一种非常好的一种
这个模型,也是一种工具。
使得开发人员呢本身在开发 过程中需要相互协作,然后这个为开发人员提供一种
认识和理解系统的一些方法。
因为 一个开发人员可能在真正开发的时候涉及到一个类,然后 不同的开发人员之间为了深入
理解这个内核之间的接口以及他们 从全局的方面把握我们这个开发的
这个业务流程,所以呢有必要要用这个用况图来进行描述。
最后呢就是 这个本身这个用况贯彻于整个开发
阶段,我们尽管在需求分析、 描述,但是我们后面在系统分析,
在系统设计、 系统测试、 实现等等,都会
仍然会使用,这个我们通过上周那个 例子也能看的出来。
再就是我们说一下用况的这个中文译法,为什么 课本上我们这个使用用况这个词,但是大部分书籍上都是
用这个用例,就是因为,实际上按照这个 Ivar Jacobson 中的 use case
,我们前面有提到 这个参与者本身是一种角色,是一个
用户的一个集合,那么这个 use case 本身呢,它也
不是我们这个,因为英语这个 case 实际上是两个意思,一个方面呢是
这个案例,另一方面是一种情景,或者说是情况的意思。
但是呢,我们这个之前,在 use case
产生之前有这个测试用例,那个是一种 真正的这种测试的一些实例。
所以我们受它那个影响,所以我们在翻译 use case
的时候往往把它翻译成用例,这是 很多书上都是这么翻译过来的,但实际上呢
我们通过这个定义发现,它这个 use case 和参与者之间是一种
全部都是一些这个集合,这个 use case
也是描述的具有相同行为特征的一些 场景的集合。
所以呢,如果说是 翻译成用例,显然就不合适了。
所以应该说 比较准确的翻译方法应该是使用的一个情况,表示的是
一些相似,一些这个行为集合,所以呢这里用 用况来进行翻译。
相似讨论大家可以详见 我们这个课本,教材上有详细的讨论。
另外呢这个,它既然是一些交互的集合,因此也不可避免的
有这个用况的实例,就是这个具体的一个 场景。
这里边 UML 中也是做了一下区分。
下面呢是这个用况和参与者之间的关系,
用况和参与者之间呢只有一种关系,那就是关联关系。
它表示呢,这个哪一个参与者
与这个当前的这个用况发生一个通信,就是它
这个在使用这个系统的这一过程中,实际上是哪一个参与者与系统发生了一个
交互,这个描述这么一种语义。
因此呢,这个关联呢 是吧,就是按照
UML 对关联的这个定义,实际上关联呢 是没有方向的,就是说这个
尽管关联有箭头,但是那个不表示关联的方向,有些书上当然用的是不对的,就是说 经常在这个参与者和
use case 之间 这关联上画上箭头,实际上呢表示是
参与者向系统提出来的 主动发出的请求呢,还是系统向参与者发出的请求?这显然
是这个不符合 UML 中规范的定义,
是一种自己想当然的一种 表示。
所以我们这个实际上在真正这个符合 UML 规范的这个
图上呢,实际上这个参与者和用况之间这根线,这个关联关系是没有任何箭头的。
它实际上是表示这个不管是参与者主动发起,还是系统主动发起 这些都是可以的。
这个我们注意不要用这个箭头。
当然这个 关联关系当然是会有箭头的,但它不是表示
这个谁是主动,谁是被动,而是表示一种导航性,这个 一般情况下在 use case 中是不用的。
只是在这个类图中 类和类之间,表示类和类之间的这种关联关系的时候才用。
下面我们看第一个例子, 我们这个讲,其实讲完这个
use case 是非常简单的一种图,实际上就是 最基本的
use case 就是三个建模元素,一个就是那个
由小人儿组成的,小人儿所表示这个参与者,另外是一个椭圆表示的 use case,
还有就是一根直线,联系他们参与者和 use case 之间的关联关系。
所以有了这三个元素其实我们就可以建立 use case。
use case 图真正建立的难度并不是在于这个 use case 的这个
模型的复杂性,这个模型非常简单,最基本的就三种建模元素。
当然最重要的是在,你如何根据现实世界中的一个问题,然后你呢能够 这个比较规范的画出这个
usecase 图来,那么首先呢我们这里边要涉及到很多的一些
参与者的一些取舍,以及这个参与者和 它相应的一些
usecase 的关联关系,下面我们看一个简单的一个例子 这个例子就是这个叫语音邮件系统,在这个系统中呢
其实我们平时打电话也经常会遇到过这种情况,就是对方的那种这个电话机呀
除了电话机之外,它又接上一种这个语音邮件系统,它接在电话里 对方电话机上,如果你打电话的时候,如果对方有人接,然后它就
自动接了,但是如果你响了三声之后没人接,这时候呢这个语音邮件的这个
系统,当然它是一个嵌入式的或者说一个软硬件结合的一个系统,它就不让你接了
它会按照固定的程序,这个向你发出一些问候信息,然后呢请求你这个
录音,并且在最后说这个 很有礼貌的说这个结束这次通话,等等这些功能
所以针对这个问题呢,针对这个场景,假使说 现在我们要开发这个语音邮件系统,那么我们构造一个
小的一个 usecase 我们看一下。
并且呢这个当对方 这个电话的这个主人这个回来之后呢,它还可以
检索到当前的,在他离开的这段时间内,有哪些人来这个打过电话,并且呢这个
收听一下他们的留言,这是另外一个事 所以整个这就是一个系统的功能,我们如何用这个
usecase 来描述清楚这个系统功能? 所以这个我们可以看到,当前的这个在
画这个 usecase 的时候呢,要有三个步骤,第一个就是划分系统边界
我们一开始讲到的,第二个就是识别参与者,第三个呢就是 识别 usecase。
划分系统边界实际上是跟识别参与者是
基本上是一起做的,完成的,因为我们这个划分系统边界实际上是不涉及到系统内部
有哪些对象,所以我们当我们识别出来与系统发生交互的 参与者之后,这个系统边界呢应该说就已经划分清楚了
而当前可以候选的这个参与者呢,我们可以大概的列举一下。
比如说这个用户 这个用户呢指的是这个语音邮件
系统这个主人,这个他呢是语音邮件系统的这个用户 另外呢就是这个接入电话,因为这个本身这个系统呢
还将与这个本地的这个电话有一个 这个连接关系,有个通信关系。
再就是远程电话 是吧,就是这个打进来的那个电话机,作为一个设备也与整个系统发生了一个交互
另外呢就是呼叫者,还有呢就是这里没有显示出来 的,就比如说这个中间,在当前语音系统
和电话之间并不是直接连接的,而是借助于交换机 程控交换机来进行联系,并且程控交换机还不只是一台,它可能有很多台
不断的一种级联,或者说是一种连接调用引用关系。
所以这 时候我们就要分析了,因为这里边涉及到比较复杂的 usecase 的识别和 筛选的一个工作。
首先呢这个用户呢这个肯定是,它作为人 是吧,他作为人的一个参与者,他直接会与系统发生一个交互,就是因为他
在这个回来之后,是吧,它可以 查询这个当前的系统,有哪些人给打,所以这个
人,作为人,他是作为这个参与者来说,他是 一个应该说是一个比较容易识别的一个
参与者,我们这个大部分同学都应该没有问题识别出这个问题来 再就是接入电话,它是不是一个参与者?
就是说这个接入电话指的是通过一根电话线 然后与我们当前的这个语音邮件系统发生关联的这么一个
本地的这个电话,它是不是一个参与者呢?这是一个设备 设备是一个很不容易把握的情况,很多同学就可能拿不准这个问题,因为为什么呢?
因为我们不知道到底这个语音邮件系统和这个很多 同学可能对这个技术不太熟悉,不知道它们是否真正 发生一个交互。
实际上呢,在这个对方打来电话之后,实际上呢 这个语音邮件系统就与这个当前的本地电话发生了一个交互
因为它要始终是监听这个电话是否摘机,摘机实际上呢
意味着这个电话线,这个电压的幅度发生了一个变化,这样的话呢实际上呢它
它们之间是存在一种直接的一种这个交互,并且这种交互呢
并没有一些其他的软件把它们隔离起来,形成一个透明的机制,没有这种情况。
所以呢 它应该是,我们在开发这个语音邮件系统的时候 应该直接编写程序处理这方面的
这个它与电话之间的这种通信,所以呢这个接入电话应该也是一个 参与者。
再就是远程电话是不是一个参与者?这个又涉及到更复杂一个问题,就是远程电话本身呢
这个不是直接的一个,它中间,它们中间呢 会有一个程控交换机,那么我们为什么不把程控交换机作为参与者而作为
将远程交换远程电话作为一个参与者,并且远程电话之外呢
还有一个呼叫者,人的一个参与者 这时候如何决策这个问题?那还是按照
刚才那种分析情况,首先程控交换机已经是 不是,已经被划到我们边界之外,因此呢
这个我们不必要关心程控交换机到底是内部怎么运作的
程控交换机就相当于一种这个中转,一种中枢,实际它将信号呢这个进行了中转,这些
这些所有的这些它的如何调度啊、 进行路由啊,这些管理的时候,实际上呢
跟我们当前开发这个语音系统是没有任何关系的,它对于语音邮件系统实际上是透明的
我们说来了个电话,那意味着对语音邮件系统呢实际上 就是一次这个它的这个电话线上的一些信号的一个波动
因此呢,语音邮件,这个程控交换机在当前这个案例中,由于不是我们开发的,所以呢可以
这个对我们这个开发语音邮件系统来说是透明的
既然它透明的,它就是我们就可以直接跨过它,直接看到了这个电话
这个远程这个电话,为什么这个这时候还要进行一个取舍,就是说 这个电话和这个电话的呼叫者之间到底使用谁呢?那就是说
因为我们当前的这个语音邮件系统呢需要直接与这个电话进行什么呢?
进行一个直接的通信,因为我们在开发的时候直接要处理这个 比较底层的这个电话的这个
at 指令,或者说是它的一个摘 机挂机呀这些信号、
这些波动,甚至呢可能我们要检测它的电压,因此呢 这个是我们直接与它进行交流的。
因此这个电话这个设备 它是在语音邮件系统和这个呼叫者之间,它不可能 是透明的。
它我们既然看,它不是透明的,那么 它就作为参与者,那么它不是透明的,我们,它就隔离了这个
呼叫者,因此呼叫者我们是看不到的,我们只能看到的是 远程电话。
因此呢呼叫者 这个参与者实际上呢是被删除了
因此呢我们通过这么一个分析之后,我们最终确定下来的 这个参与者,我们从五个参与者中选出了三个真正的参与者 就是用户、
接入电话和远程电话这三个参与者 这是识别完参与者了,识别完参与者之后呢,就是
接下来呢我们要进行这个识别用况,识别 usecase 识别
usecase 的时候呢实际上呢我们就根据当前
系统的功能,或者说系统的需求呢 是吧接入电话来,这个将一些
这个整个功能给它分成若干个比较独立的一些 功能点,这就是 usecase。
并且呢将每一个这个 usecase 与我们,它实际的
与它这个发生交互的,发生功能这个 系统边界上的这种交互序列的这个参与者发生建立 一种关联关系。
因此呢,这个接入电话 实际上呢与这个系统发生了一种这个 这种交互就是在检测摘机上。
就是当电话响起 我这个语音邮件系统马上进入了一种工作状态,然后它首先呢要检测
当前的近端这个电话是否已经摘机,因此在这个方面 它可能要进行一次与系统发生一种交互
而这个远程电话呢,它这个主要是在
这个发生这个在呼叫系统的时候,这时候呢 这个,它会与我们的语音邮件系统发生一种交互,另外在
接听来电的时候,实际上这个也会发生 这个一些交互。
另外呢对于这个人 的这个用户来说呢,无非就是检索信息、
保存信息和删除信息 因此在这个时候呢,我们就画出了 use
case 图 这个 use case 图画出来之后还没有完全完毕,因为我们要真正
最有用的信息,use case 图中往往不是 use case 图本身,而是
use case 的详细描述 所以我们要详细地描述每一次交互,每一个
use case 交互的时候,这个参与者和系统之间的交互的这个过程,交互的序列到底是什么样的
这个序列实际上我们可以,当然这不是一种正规的画法 不是 uml
正规的画法,实际上它可以这个 独立于,完全独立于
use case 图,我们这为了大家理解,我们画 在了它的 use case 图这个
参与者之后,其实这不是非常那个 好的一种方式,我们这是为了让大家理解
所以在呼叫系统的时候,整个工作流呢,它实际上是这样的
就是在远程电话,拨打一个号码,这个号码实际上已经安装了语音邮件系统
然后他拨打这个号码之后通过交换机,然后呢就
把这个信号转接到当前这个电话上,转接到电话之后呢,这时候这个
远程电话和我们这个语音邮件系统就发生了一次 交互,这个交互包括
远程电话拨打信号,拨打电话,然后这个当前的系统呢
检测到这个呼叫信号之后呢,然后马上
它实际上是与这个近端的这个电话同时 检测到这个呼叫信号,但是呢
所不同的是,电话一旦检测到这个信号之后马上振铃,它呢
实际上是通过内部的逻辑,先看一下是不是这个电话机有人被
这个是不是有人摘机,因此它 这个在呼叫系统的时候,当前的这个
语音邮件系统就开始工作,与系统发生了一个交互,只不过这个交互很短暂 然后做的这个过程也非常简单,就是检测摘机
接到信号之后马上进入检测摘机,检测摘机实际上就是
这个接入电话和我们当前系统之间的一个
互动,它实际上就是不断地监测 这个振铃信号,然后呢
这个如果说是,并且计数,如果说是三次之内有人接听,表示当前家里有人
就没有什么工作,直接就忽略掉本次行为就完了 但如果连振了三次铃,没有人接听,那就表示
有必要进行,这个语音邮件系统开始工作,要进行这个
转接,转接这个来电 下面呢就是这个接听来电,接听来电这时候系统呢,要像
首先要摘机,首先就是说接听,然后呢这个 这就说意味着这个线路已经保持
接通,只不过这是由机器帮它接的,因此它
显示欢迎语音量,这个并且让对方留言,留言完之后就
提示说这个一些"再见"等等这些话,这样的话就 是这个接听来电的
use case ,所以说这些 use case 实际上是这个 用户以外一圈都是有声音的
不是我们正常意识的这种人机的这种图形界面来表示的
所以这是一个 大概的一个过程,这个过程实际上是
如果我们这个平时对这个 电话方面理解不是特别多的话呢,这个还是 有一定的难度的。
之后呢,这个用户回来之后,检测信息,保留信息,这些
实际上就没有太多的一些,非常简单,这个就是涉及到一个一般的一种查询
删除这个工作,这个没有什么太多的一些问题