Java建模: UML工作簿,第 3部份[Java编程]

需求汇集是任何成功的软件开辟周期中不可贫乏的一步.固然有众多的需求汇集办法,但是最普通的办法是用例建模.在 先前的两个专栏中,我们已经完成了一部份将序列图同用例建模关联起来的工作.这次我将更多地评论办法之后的理论,并且也增添一些您的建模词汇.

这次谈论中,我更关心的是阐明用户接口、系统接口和用例描写之间的关系.因为所成立的大大都系统将被计划成人机交互式的,所以将用例描写计划成以用户接口开始运行是很诱人的.但是在用例中包含用户接口逻辑普通被认为是不好的情势.这种说法的一个简单注释是,用户接口供应一个系统透视图的系统概貌.用例老是以参与者（或用户）透视图被描写.

为了真正理解为什么我们在用例描写中不包含 UI 逻辑,我想无论若何我们不得不采取亲身实践的办法.我们将利用我的 第一个专栏中的贷款申请的示例,并且您将看到用例是若何随着尺寸的增大而变得复杂的.分外地,我们要注意在用例建模中透视图的角色.随着我们的深化,您将看到透视图是怎样被用来为您工作的,大概,假如被不精确地利用,它是若何阻碍您工作的.

什么是用例模子?

一个用例模子由一张图表和一组阐明该用例的描写构成.一个用例是在一个系统中的一组大概的交互,它的参与者朝着同一个被定义的目标举行.这些描写描写了系统中该用例的功效性;这张图表供应了这些描写的可视化路标.UML 规定了成立用例图表的尺度,但并非为了编写用例描写的.后果产生了很多编写用例描写的办法,这些办法有时是彼此竞争的.

最风行的编写用例描写的办法表现着 Ivar Jacobson （用例建模的创造者）的思惟.Jacobson 的办法触及一系列进入和退出的原则,辨别被称作 前置条件和 后置条件,和一个称为 事件流的核心原则.这个事件流描写了一系列参与者（用户或外部系统）和被拟定的系统之间的交互.这个事件流代表一个经过系统的通向成功输出的单一途径.这是用例描写的核心部份,但不是全部.

事件流的交替和例外

除描写中央事件流之外,用例描写必须阐明那些发生在普通事件流之外的交互.比方录像带租用用例的主要事件流（在简单情形下）可以以下表示:

录像带租赁店伴计扫描顾客的会员卡.

系统获得会员名和他目前的租赁情况.一个“答应租赁”状况表示这个顾客可以租用录像带.

录像带租赁店伴计扫描每盘被租借的录像带.

系统通过扫描每盘录像带,将可出租的录像带加入到用户可见的列表中,并显示当前的可出租的录像带列表.

录像带租赁店伴计输入应收取的钱的数目（假如是现金）大概扫描信誉卡.

系统标志这盘录像带为已在某段时间被出租并且打印这笔交易的收条.

但是假如顾客在上次租借中欠了过期费怎么办?在她能再次租借她所选的录像带之前,她需付清所欠的过期费.过期费的交互表现为一个 交替流或 例外流.事件流的交替和例外是很正常的.在某些情形下,他们可以被改正以重新开始正常的事件流,在其他情形下,他们则达不到目标.在我们的示例中,假如顾客付了过期费和这次的租金,那她就到达了持续租借录像带的目的了.

用例建模中的事件处理

伴随着它的交替和例外,事件流是由一系列的事件处理构成.事件处理是由参与者发动,并且当系统等候来自参与者的触发信号时完成的交互（注意完成事件处理的参与者不一定就是发动该事件处理的参与者）.事件处理答应我们把用例分割成更小的元素,并在每个决意点上将逻辑分组.决意点是在描写中参与者必须作出决意大概供应额外信息的那个点.

全部的事件处理是由一个参与者和一个系统交互构成.您将极少需求筹划一个没有启动的系统,即便这个启动仅仅以时间为底子.当成立用例模子的时刻,您必须确保每个启动被某种范例的系统呼应拜候到.这个调用和呼应关于用例来说是完好的.

　　以上是“Java建模: UML工作簿,第 3部份[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：