下面我们再看一下这个用况和用况之间的第三种关系,就是说我们其实刚才也提到了,就是
泛化关系,泛化关系实际上也是表示一种这个变化和一种扩展。
它这个在表示变化和扩展的时候,与扩展关系和包含关系不同的就是说它可以
覆盖或者重写这个父用况的某些行为, 这一点是包含关系和扩展关系所不同的,
从这一点上来说呢可以改写 这个父用况和基用况的某些行为,好,这是
这个这个它的一个特点,而这些包含关系扩展关系只能是
在父用况基础上,在哪个具体的位置给它插入新的,但是对于人家
以前有的那些场景,它一点都不能做出那些修改, 因此呢在某些情况下,
还需要使用泛化关系来表示,这种这种情况, 泛化关系呢,实际上这个表示法也就是很简单了,
用空心,这种箭头来表示,其中这个箭头指向的是父类以后的基类,然后这个尾巴上
那个跟着的是个扩展,但是扩展类和实际上跟这个包含这个
它的这个父类实际上都是非常完整的, 这个交互序列,这一点跟那个其他的那个包含关系和扩展关系都是不同的,
就是一个子类,子用况它实际上是一个非常完整的
一个序列,它应该把这个父类的所有的场景,所有的交互序列都给它 重新抄一遍,或者有些地方给它重新你就给重写或者说覆盖,
然后或者有些地方给它加入新的,但是它得完全重写,这是它的一个,在这个如何写
我们下面举一个,引用这个如何写这个有效用例这本书上的一个例子就是说
当我们这个参与者有泛化关系,用况 之间也有泛化关系,但是有些情况下呢,它会出现
这个参与者和用况之间,这个泛化关系同时存在时候这时 要特别小心,你像我如果我们描述一个销售人员终止
一般的交易,但是不能终止大交易,而这个高级销售人员或销售主管他可以终止
大交易也可以终止一般的交易,这种非常简单的场景的时候 如果我们用这种图,那实际上猛一看好像是对的是吧,
普通的销售人员和高级销售人员之间是一种这个泛化关系, 这是他们之间是一种这个子类和父类关系,
大类和小类的关系,然后终止交易和这个终止大交易呢,又是一种什么呢?
刚才我们讲到的use case之间的一种这个泛化关系。
它这个终止交易所包含的流程, 和终止大交易,实际上终止大交易是对终止交易
的一些这个交互序列的一个扩展,或者说是一些改写, 它们是非常非常符合这个扩展关系的表示方式,
但是呢,这两个分开看 是没有什么问题的,但是如果把它们合起来看,这时候就出现问题了,为什么呢,
就是因为我们普通销售人员可以终止交易,
但是呢,由于这个终止大交易和这个终止交易之间是一种这个 use
case之间是一种什么呢,泛化关系,所以呢 既然我普通的销售人员能够终止一个大类的一个
交易那么他也可以终止他作为他大类一个子集的一个, 一个一个一个交易,所以这时候呢,就会造成普通销售人员
会终止大的交易,这时候呢是 这个不行的,所以为了便于
对这种情况呢,我们一定要注意,对于这个泛化关系和这个 这个参与者泛化和用况泛化之间的这种复用的时候呢,
我们要改写成右面这种图,这种图的时候,实际上就非常清楚了,因为这个普通销售人员
这个把这个交易啊,给它拆分成大交易和小交易, 它们都是属于这个一般,都是从这个基本交易
这个继承过来的,这样的环呢就非常清晰,也是非常这个
这个便于这个不会产生这个 错误。
好,下面我们谈一下这个用况的分类,因为用况我们可以看到呢
它有可以从三个维度进行分类, 第一维度就是说高层用况和低层用况,所谓高层用况呢
就是我们所画的那个use case图,它是非常高层,它就一个小的拓延就表示一个
交互活动,那低层是什么呢,低层就是这个刚才我们说到的用况的详细描述,
这个参与者干什么,系统干什么,然后反过来这个参与者再干什么,系统再干什么,整个这个-
交互的一个 业务的一些详细的一个描述,这个呢是
这个称之为低层用况,这是一个维度,另外从本质用况和具体用况而言。
就说我们这个用况,是不是涉及到一些实现或是软件的解决方案,
还是只是一个独立于这个当前的这个软件或
实现的这么一种这个解决方案, 如果说独立于软件的这个解决方案,它只是描述一个问题域或者说一种
这个业务逻辑的话,那我们称之为本质用况, 如果是依赖于设计,那就是依赖一个具体的一个
一种平台一种架构,甚至是一种编程语言的时候,这时候呢,是称之为
这个具体的用况,而本质用况一般出现在
需求分析,系统分析的这个阶段,而具体用况呢一般是出现在系统设计,
另外呢就是我们也刚才我们也提到了就是这个主要用况和次要用况,特别是在
扩展关系的时候,是吧,我们这个主要用况是捕捉到的是这个系统主要的业务功能,
而次要用况是捕捉了到一些不常见的或例外的一些情况, 这个也可以从这个维度来进行划分,并且它们三者是正交的,
我既可以是高层的也可以是本质的,也可以是主要的, 既可以是高层的也可以是具体的也可以是次要的,它们三者是一种正交
的关系,因此呢,我们在一开始进行需求分析的时候,一般来说是先做高层的 用况,先做本质的,这个高层的,
这个用况,然后呢再把它这个做这个低层的本质的,
这个用况,然后在做的时候,过程中呢,先做主要的然后再做次要的,到设计阶段我们再做- 具体的,
往往是这个在不同阶段有不同这个维度的这个需求, 下面是这个用况和场景的一个
问题,就是说我们如何识别 这个用况,那么识别用况的时候呢,实际上呢
还是从这个用况的实例及场景中概括出来, 这个因为场景呢是往往
涉及到一次真正的使用这个系统的一个实例, 而我们的用况实际上是对一些相似的一些实例一个概括,
所以往往在对于初学者,或者说是对于我们接触到一个非常 不太熟悉的业务领域的一个情况,
情况下,我们一定要不要急于先写use case 先写用况,而先写这个用况的实例场景,
然后把多个场景给它们这个提升、 提炼、 抽象
总结成这个use case,这就是一个 一个这个方法,方法的一个,这个如何构建用况的一个方法的一个问题,
因此呢,我们在比如说这个在做ATM交易的时候呢,
这是我们这个参考这个如何写有效用例这本书上的一个例子,
就是我们在做这个ATM机交易的时候,我们这个
先找一些这个成功的一些场景,然后比如说这个查询成功,某一个人,某一天
张三去这个什么,人行,不是人行,这个建行 这个ATM机上进行一次查询,有一次呢这个什么
李四又去这个农行ATM机取款,是这样, 然后呢,这些,把这些大量的这些场景
给它们概括出来,就提出共性之后,就提升成我们用况, 另外呢还有一些情况下呢,它是处理失败的一些场景,
同时呢也要把这些处理失败的场景给它融合到我们这个 这个用况的描述,这时的用况呢
可以非常朴实的适合各种人员在各种ATM
机上,在遇到各种问题的时候呢,它都是适合的,这时候呢就已经我们
从场景的描述上,提升到,提升成为这个用况的描述,
所以,具体来谈呢,捕捉用况的策略,这个就是说呢,我们
在最普遍的情况下,当然如果你对这个业务非常熟悉呢,不一定非得用这种方式,
就是你这个初学者遇到了非常这个不太容易,不太熟悉的业务领域时候,
往往你不要直接写用况,而是从这个场景开始, 写一些简单的场景,然后呢,写完
几个之后,写完几个场景之后,你就会
这个有一些共性一些认识,然后把它们抽象成为这个更加
这个,可以这个,描述规约不同场景的这么一些 use case
然后通过不断地增加新的场景,可以这个使得我们这个 use case 可以适用越来越多的一些 情况。
所以,这个写 use case 这个工作呢,应该是一个增量型的
不断螺旋地盘旋上升的一个阶段,一个过程。
所以呢我们在 不管是大的阶段,还是在我们每一个阶段,这个不断地完善当前的现有用况模型的时候,都-
是实用的 但是具体到一个更大规模上来说呢,我们应该是先开发主要的高层的,然后呢再开发主要的
这个本质的,然后呢再开发次要的本质的,最后是 开发次要的具体的用况。
这个用况的这个模板呢 就是我们这个提到,就是用况详细描述呢
它可以遵循一个,非常标准化的一个模板。
在这个模板中呢 主要的一个内容就是要把这个,所有的参与者与系统发生的这个交互场景 一步一步地写清楚。
这个,这里呢我们给出一个模板的一个例子 这是一个用户登录的一个例子。
当然在此之前呢 这个父用况、 子用况、
前置条件,这些呢,有些实际上是 冗余了,跟图中的信息冗余了,但是呢,你这个为了
便于这个在,图形,在表格上来这个 完整地描述这一方面也可以写。
但最重要的这个 是要描述这个用况的这个详细的这个 描述。
这个描述呢,包括参与者和系统
当然这里边呢,有几个参与者,涉及到当前的 use case 那就要写几个参与者。
一般情况下是一个这个参与者
那这个当前这个用户登录,我们可以看一下,这个最关键
这个用况描述,表示这个用户首先请求登录,系统呢显示登录界面,然后呢用户输入 自己的这个
ID 和密码,然后系统呢进行这个验证
验证成功的话,进入登录后界面,错误的话给出提示信息 就这么简单地就可以把这个
你来我往的,把这个用户和参与者之间的这种交互活动非常清晰地描述出来
这个,这是这个,给出的一个详细描述用况的一个表格,一个模板
好,下面我们看,第三个例子,就是网上职位发布系统。
这个就是相当于一些 这个网络职位招聘。
但是网络招聘呢,它分为 两种发布,一种是一般的发布,就是
把这个,通过一个页面,然后把发布职位的公司啊
把招聘什么职位,有什么要求,人数等等这一些信息
通过一个网页,然后呢提交上去,然后呢发布的时候 也是按固定格式发布。
当然还有一种叫特效职位发布,就是说这个公司啊
往往喜欢在发布职位的时候呢,加上一些图片的说明,或者说是一些
自己定制的一些网页,或者说是这个图片,页面的风格
也不与这个以前的一样,表现自己的一些比较特殊的一些需求。
这时候呢 我们要描述这个情况的时候就必须借助于我们刚才讲到的这个泛化关系
发布职位和发布特效职位是个泛化关系,为什么必须用泛化关系呢
就是因为,这时候呢是对这个,发布职位的一个扩充,并且这个
扩充的过程中很可能会改写发布职位,在这个用况的这个详细的描述
所以,除此之外呢,在这个发布职位完之后呢 都会用到这个提交,检查权限预览,这些
小的一些不完整的这个交互序列,但是这些序列呢
实际上指的是,为什么要用包含关系,就是因为它们是无条件地调用,它们是可复用的
它们任何发布,任何场景,发布职位的任何场景下都会调用这些情况,没有条件,所以呢是一-
种包含关系 然后在描述这个详细描述的时候呢,要
重点要描述清楚,这个参与者和这个系统之间的交互过程
这是发布一般职位的一个交互过程。
这个发布特效职位,实际上呢 这个我们可以看出它在原有的基础上呢
又增加了上传定制图片和网页这个功能 其他的基本上没动,如果其他的进行改写,也是可以支持的
这个用况的这个详细描述,就是说我们实际上可以通过三种方式,一种是文本的方式
一种是结构化文本的方式,一种是交互图的方式 在当前这个需求分析阶段呢,我们主要是用文本和结构化文本的方式
对于这个到系统分析的时候,我们画完类图之后,我们可以用交互图的方式来描述这个 use case。
一般呢,非常简单的一个场景的话我们可以基本上用这个,我们刚才提到的 本文的方式来进行描述。
当然如果我们涉及到一个非常复杂的流程,这个流程是
一个很多循环,条件判断,这些情况下,我们往往呢要用结构化文本
也就是说我们往往加上一些关键词,表示循环啊
表示条件判断,等等一些关键词,这样使得我们描述这个 交互序列的时候非常清晰。
这是,一个例子。
但是呢,就是说 我们在描述用况的时候呢,需要注意问题,几个问题,就是说
很多情况下我们描述用况的时候往往,因为用况是这个系统和这个参与者进行的交互
所以呢,有些情况下呢,特别初学者,在描述这个 use case
的时候呢 往往不写系统干什么,主要是描述用户干什么,这是 不对的,或者出现这种问题往往属于这个
可能是一些这个用户在描述用况的时候往往会出现这个问题 因为他最关心的是,他要干什么干什么,他不关心系统干什么
另外,另一个极端呢就是没有,只有系统 没有参与者干什么,这个也就是说这种错误的这个使用者往往是这个
一些这个开发人员,他关心系统干什么不关心用户干什么
所以参与者必须是二者都要描述清楚 要描述二者之间的这种交互序列。
这是,当然这样一说的话大家可能就 很容易避免。
但是还有一种情况可能是大家不容易,容易这个不太
注意的就是说,太多的用户界面细节,在我们在需求 阶段描述时,比较忌讳。
就是我们在需求 阶段描述这个用况,不要涉及太多的用户界面细节
我们在描述这个职位发布的时候,不要把每一个按钮啊,每一个
这个,这个发布的每一个数据啊,都给它写清楚
因为在需求描述的时候我们这些东西还不太清楚 这个东西最后非常清晰,有待于在系统分析之后,才能够真正形成
所以我们在需求分析阶段描述的时候呢,不要涉及到太多的这个用户界面细节
还有一种情况呢就是,它不涉及到这个用户界面,就是它在描述的时候,不涉及到这个
真正这个,这个用户界面长的什么样,但是也是 过低的目标级别,就是它涉及到一些,尽管它没有说出来
这个有哪些按钮啊,有哪些什么菜单啊,有哪些这个 edit 啊这些
用户界面细节,但是它描述这个 职位发布的时候,把职位的一些属性描述太清楚了
实际上这也是,不合理,因为我们在需求分析中还没有 办法做到这一步。
真正做到这一步基本上应该是在 后续阶段,在系统分析完成之后才能够完成的一个阶段