在某银行业务的用例模型中,“取款”用例需要等到“存款”用例执行之后才能执行,两个用例之间的关系属于 (26) ;“取款”和“存款”两个用例中都需要执行查询余额的功能,将查询余额提取成独立的用例,那么“取款”和“存款”用例与“查询余额”用例之间的关系属于 (27) 。
A.扩展关系
B.使用关系
C.依赖关系
D.继承关系
参考答案:B
解析:
[分析]: 用例是在系统中执行的一系列动作,这些动作将生成特定参与者可见的价值结果。它确定了一个和系统参与者进行交互并可由系统执行的动作序列。用例模型描述的是外部执行者(actor)所理解的系统功能。用例模型用于需求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。
两个用例之间的关系可以概括为两种情况。一种是用于重用的包含关系,用include表示(在UML 1.x版本中用use表示);另一种是用于分离出不同行为的扩展,用extend表示(在UML 1x版本中用extends表示)。
(1)包含关系。当可以从两个或两个以上的原始用例中提取公共行为,或者发现能够使用一个构件来实现某一个用例的部分功能很重要时,我们应该使用包含关系来表示它们。
(2)扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景,即根据情况可能发生多种事情,则将这个用例分为一个主用例和一个或多个辅用例描述可能更加清晰。
另外,用例之间还存在一种泛化关系。用例可以被特别列举为一个或多个子用例,这被称为用例泛化。当父用例能够被使用时,任何子用例也可以被使用。例如,我们购买飞机票,既可以是电话订票,也可以是网上订票,则订票用例就是电话订票和网上订票的抽象。
用UML建立业务模型时,可以把业务人员看做是系统中的角色或者类。在建立抽象模型时,很少有类会单独存在,大多数都将会以某种方式彼此通信,因此还需要描述这些类之间的关系。关系是事物间的连接,在UML中,有几个很重要的关系。
(1)依赖关系。有两个元素A、B,如果元素A的变化会引起元素B的变化,则称元素B依赖于元素A。在类中,依赖关系有多种表现形式,例如,一个类向另一个类发消息;一个类是另一个类的成员;一个类是另一个类的某个操作参数等。
(2)泛化关系。描述了一般事物与该事物中的特殊种类之间的关系,也就是父类与子类之间的关系。继承关系是泛化关系的反关系,也就是说子类是从父类中继承的,而父类则是子类的泛化。在UML中,对泛化关系有3个要求。
·子类应与父类完全一致,父类所具有的关联、属性和操作,子类都应具有。
·子类中除了与父类一致的信息外,还包括额外的信息。
·可以使用父类实例的地方,也可以使用子类实例。
(3)关联关系。关联表示两个类的实例之间存在的某种语义上的联系。例如,一个老师为某所学校工作,一所学校有多间教室。我们就认为老师和学校、学校和教室之间存在着关联关系。关联关系为类之间的通信提供了一种方式,它是所有关系中最通用、语义最弱的。关联关系通常可以再细分成以下两种:
·聚集关系。聚集关系(聚合关系)是关联关系的特例,表示一种整体和部分的关系,
其中整体和部分的生命周期不相同。例如,电话机和话筒的关系,计算机和显示器的关系等都是聚集关系的例子。
·组合关系。组合关系也是表示一种整体和部分的关系,其中整体和部分的生命周期相同。例如,公司与部门之间的关系就是组合关系的例子。
(4)实现关系。类之间的语义关系,其中的一个类指定了由另一个类保证执行的契约。在UML中,活动图用来表示系统中各种活动的次序,它的应用非常广泛,既可用来描述用例的工作流程,也可用来描述类中某个方法的操作行为。活动图是由状态图变化而来的,它们各自用于不同的目的。活动图依据对象状态的变化来捕获动作(将要执行的工作或活动)与动作的结果。活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。