用例间的关联(泛化-包含-扩展)

合集下载

用例图元素之间的关系

用例图元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。

包括：角色之间的关系、用例之间的关系、用例和角色之间的关系。

角色之间的关系由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

用例之间的关系：(1)包含关系:基本用例的行为包含了另一个用例的行为。

基本用例描述在多个用例中都有的公共行为。

包含关系本质上是比较特殊的依赖关系。

它比一般的依赖关系多了一些语义。

在包含关系中箭头的方向是从基本用例到包含用例。

简单的理解就是用例可以包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。

(2)泛化关系：代表一般于特殊的关系。

它的意思和面向对象程序设计中的继承的概念是类似的。

不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。

在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。

泛化（Generalization）在面向对象的技术中无处不在，下图给出了一个使用泛化的用例图：在用例图中，角色和用例都能够泛化。

角色的泛化/继承很容易理解，因为角色本来就是类（Class），它是一种版型（stereotype）为Actor的类，所以角色的继承直观而自然。

但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展（extended）和包含（include）两种泛化的特例。

扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。

包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。

(3)扩展关系：扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。

与包含关系一样，扩展关系也是依赖关系的版型。

用例之间的关系

3、4用例之间得关系1、泛化关系Ｇｅneralｉzａｔioｎ代表一般与特殊得关系。

（类似于继承）在用例泛化中，子用例表示父用例得特殊形式，子用例继承了父用例得行为与属性，也可以增加新得行为与属性或覆盖父用例中得行为。

例子：一个租赁或销售系统用例得部分内容，在此,父用例就是“预定",其两个子用例分别就是“网上预定”与“电话预定”,这两个用例都继承了父用例得行为,并可以添加自己得行为。

2、包含关系Inｃluｄe一个用例（基用例,基本用例）可以包含其她用例(包含用例）具有得行为，并把它所包含得用例行为作为自身用例得一部分，这被称为包含关系.在UML中，包含关系表示为虚线箭头加版型《inｃludｅ》，箭头从基本用例指向包含用例。

例子：一个租赁或销售系统中，“填写电子表格”得功能在“网上预定”得过程中使用，不管如何处理“网上预定”用例，总就是要运行“填写电子表格”用例,因此具有包含关系.3、扩展关系Extenｄ一个用例也可以定义为基本用例得增量扩展,这称作扩展关系,即扩展关系就是把新得行为插入到已有得用例中得方法。

在ＵML中,包含关系表示为虚线箭头加版型《eｘtｅnｄ》,箭头从扩展用例指向基本用例。

基本用例提供了一组扩展点，在这些新得扩展点中可以添加新得行为,而扩展用例提供了一组插入片段，这些片段能够被插入到基本用例得扩展点上.扩展关系可以有控制条件,当用例实例执行到达一个扩展点时，控制条件决定就是否执行扩展。

一般情况下,基本用例得执行不会涉及到扩展用例，只有满足用例得控制条件时,扩展用例才被执行，因此扩展关系处理事件流得异常或者可选事件。

同一个基本用例得几个扩展可以在一起使用。

基本用例不知道扩展得任何细节、没有扩展用例，基本用例就是完整得。

例子：一个汽车租赁系统用例图得部分内容。

在此，基本用例就是“还车"，扩展用例就是“交纳罚金”。

如果一切顺利汽车可以被归还,那么执行“还车"用例即可。

软件建模(卫红春)课后习题答案--归类版(全网最全)

一、简答题1. 简述模型的作用。

答：现实系统的复杂性和内隐性，使得人们难于直接认识和把握，为了使得人们能够直观和明了地认识和把握现实系统，就需要借助于模型。

2. 软件模型有什么特征？答：建模对象特殊，复杂性，多样性3. 软件建模技术有哪些因素？答：软件建模方法，软件建模过程，软件建模语言，软件建模工具4. 软件模型包括哪些方面的内容？答：从模型所反映的侧面看：功能模型，非功能模型，数据模型，对象模型，过程模型，状态模型，交互模型，架构模型，界面模型等；从软件开发工作看：业务模型，需求模型，分析模型，设计模型，测试模型等。

5. 软件建模工具应该具有哪些基本功能？答：软件模型的生成和编辑，软件模型的质量保障，软件模型管理等1. 简述UML的发展过程。

答：Rational公司在众多软件开发方法的基础上于1996年提出了UML0.9版本，1997年把UML1.0版本提交给OMG，1997年被OMG正式批准成为标准，1998年UML1.2 版，1999年UML1.3版，2001年1.4版本，2003年1.5版本，2005年2.0版本，2009年2.2版本，2010年2.3版本，现在已经上升为2.4版本。

2. 作为一种统一建模语言，UML由哪些部分构成？答：模型元素，图，语义规则，公共机制。

3. 元模型理论是UML的基础，元模型分为哪四个层次？答：元元模型，元模型，模型，对象。

4. 聚集关系与组合关系有什么区别？答：聚集松散，组合紧密；一个部分事物对象可以属于多个聚集对象,但一个部分事物对象仅能属于一个组合对象；聚集的对象生命周期可以不同,但组合对象则是同存同亡。

5. 用例和协作有什么区别？答：协作是对用例的实现。

6. 模型元素的可见性含义是什么？答：模型元素可被其他模型元素访问的程度，共分为公用，受限，私有，包四种。

7．UML的构造型有什么作用？答：给UML定义的模型元素赋予新的含义，定义新的模型符号，改换模型元素的表示形式。

用例的三种关系

用例的三种关系用例是软件开发中的重要组成部分，用于描述系统与用户之间的交互。

在用例分析的过程中，我们需要了解用例之间的关系，以便更好地理解系统功能和需求。

用例的关系可以分为三种：包含关系、扩展关系和泛化关系。

1. 包含关系（Include Relationship）包含关系表示一个用例可以包含另一个用例，被包含的用例是基础功能，被包含的用例所描述的场景是包含关系中包含用例的一部分。

包含关系可以用来提高用例的复用性和可维护性。

在用例图中，包含关系用带箭头的虚线表示。

举个例子，假设我们正在开发一个电子商务网站，其中一个用例是“用户下订单”，而另一个用例是“用户选择支付方式”。

用户下订单的过程中必须选择支付方式，所以“用户选择支付方式”这个用例可以被包含在“用户下订单”用例中。

通过包含关系，我们可以将这两个用例的共同部分提取出来形成一个独立的用例。

2. 扩展关系（Extend Relationship）扩展关系表示一个用例可以在特定条件下扩展另一个用例。

扩展关系描述了一个用例可以根据某种条件执行额外的步骤或者部分功能。

扩展关系可以用于处理非必要的但可能发生的情况。

在用例图中，扩展关系用带箭头的虚线表示。

举个例子，继续以电子商务网站为例，假设我们有一个基本的用例是“用户下订单”，而另一个用例是“用户使用优惠码”。

当用户选择使用优惠码的时候，我们可以通过扩展关系将“用户使用优惠码”这个用例扩展到“用户下订单”用例中。

这样，在完成基本的下订单操作后，系统将会检查是否有优惠码，并执行相应的优惠操作。

3. 泛化关系（Generalization Relationship）泛化关系表示一个用例可以作为另一个用例的一般形式。

泛化关系在用例间建立一种继承关系，用于描述用例之间的通用和特殊关系。

在用例图中，泛化关系用带箭头的实线表示。

举个例子，假设我们正在开发一个电子商务网站，其中有多种不同的用户角色，如客户、管理员和供应商。

用例间的关联(泛化-包含-扩展)

（1）B通常是A和C 中共同操作部分抽象出的部分（2）B是A的子过程为了避免太复杂单独抽象出来的部分
➢A extend B 表示B是A在系统某些情况下（特定条件）触发产生的，B不是A中必须存在的部分，B可以单独存在 ➢B是对A在一些基本功能上具体的扩展（在A的扩展点处）
9
用例间的关系
➢Include 包含关系通常发生在多个用例中，有可以提取出来的公共部分（就象提取公因式一样） ➢例如 UseCaseA 中包括了 a 和 b 两个流程，而 UseCaseC 中包含了 c 和 b 两个流程。为了提高复用性，可以把 b 提取出来，形成另一个用例 UseCaseB，此时，UseCaseA include UseCaseB，UseCaseC 也 include UseCaseB。 ➢当有 include 关系时，被 include 的用例通常会被两个以上的其他用例 include（否则就不需要提取出来了）
10
用例间的关系
➢Extend 关系：假设 UseCaseA 的功能描述为“发送一条通知”，可是，发送通知的方式可能有许多种（例如通过邮件发送、通过短信发送等）。在需求分析阶段，可能无法明确到底有多少种方式，在用例分析阶段，UseCaseA 需要留出扩展接口，然后把已知的发送方式作为扩展用例给出，例如 UseCaseB 是“通过短信发送”，而 UseCaseC 是“通过邮件发送”，此时，UseCaseB 和 UseCaseC extend 了 UseCaseA，表现为两根虚线，箭头指向 UseCaseA
11
用例间的关系
12
用例间的关系
错！
13
用例间的关系
➢销户：因为销户必需先进行账户结算，所以这里用include ➢停机提醒：有两个可选项，短信提醒和邮件提醒，所以用extend

用例之间的关系

例子
一个汽车租赁系统用例图的部分内容。在此，基本
用例是“还车”，扩展用例是“交纳罚金”。如果一切顺利汽车可以被归还，那么执行“还车”用例即可。但是如果超过了还车的时间或汽车受损，按照规定客户要交纳一定的罚金，这时就不能执行提供的常规动作。若研讨修改用例“还车”，势必会增加系统的复杂性，因此可以在用例“还车”中增加扩展点，即特定条件为超时或损坏，如果满足条件，将执行扩展用例“交纳罚金”，这样显然可以使系统更容易被理解。
用例之间的关系
在画用例图的时候，理清用例之间的关系是重点。用例的关系有泛化(generalization)、扩展 (extend)和包含(include)。其中include和 extend最易混淆。使用关系uses(UML1.2以后已经不再使用此关系）下面我们结合实例彻底理清三者的关系。
基本概念
包含(include)
include为包含关系，当两个或多个用例中共用一组
相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以 include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注 <<include>>)，箭头从基用例指向子用例。
泛化关系是一种继承关系，子用例将继承基
用例的所有行为，关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例。
在用例泛化中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。

uml题库

C. 用例
D. 实体
8. UML 中关联的多重度是指
(B)
A. 一个类有多个方法被另一个类调用
B. 一个类的实类能够与另一个类的多个实类相关联
C. 一个类的某个方法被另一个类调用的次数
D. 两个类所具有的相同的方法和属性
9.关于协作图的描述，下列哪个不正确（B）
A.协作图作为一种交互图，强调的是参加交互的对象的组织；
B.活动图用于对业务过程中顺序和并发的工作流程进行建模。
C.活动图中的基本要素包括状态、转移、分支、分叉和汇合、泳道、对象流。
D.活动图是 UML 中用于对系统的静态方面建模的五种图中的一种
14. 下面哪个 UML 视图是描述一个对象的生命周期的（ B ）
A. 类图
B. 状态图
C. 协作图
D. 顺序
A．信号
B．调用事件
C．源事件
D．时间事件
42.在 UML 中，（A ）把活动图中的活动划分为若干组，并将划分的组指定给对象，这些对象必须履行该组所包括的活动，它能够
明确地表示哪些活动是由哪些对象完成的。
A．泳道
B．同步条
C．活动
D．组合活动
43.下面（D ）属于 UML 中的动态视图。
A．类图
B．用例图
22.通常对象有很多属性，但对于外部对象来说某些属性应该不能被直接访问，下面哪个不是 UML 中的类成员访问限定性（C）
A.公有的（public）
B.受保护的（protected）
C.友员（friendly）
D.私有的（private）
23.下列描述中，哪个不是建模的基本原则（D）
A.要仔细的选择模型
B.每一种模型可以在不同的精度级别上表示所要开发的系统

用例间的三种关系

⽤例间的三种关系⽤例间的三种关系：（1）扩展(extends)：⽤例B extends ⽤例A，表⽰⽤例B是⽤例A在某种特定情况下可能会出现的扩展⽤例。

例如：⽼王进城办事，2⼩时就可以回去，在这2⼩时内内急时就会去上厕所。

上厕所⽤例是进城⽤例的扩展，因为不上厕所⽼王进城办事也可完成。

（2）包含(includes)：⽤例A includes ⽤例B，表⽰没有了⽤例B，⽤例A本⾝也就不完整了。

例如：还是⽼王进城，他从海南来北京办事，3天才能回去，那么这种情况下进城⽤例与上厕所⽤例的关系就应该是包含关系了。

（3）泛化：泛化关系指的是同⼀业务⽬的的不同技术实现。

例如：⽼王进城，他可以坐飞机，可以坐⽕车，还可以⾛路，那么进城⽤例就泛化为坐飞机、坐⽕车和⾛路三个⽤例了，它们之间存在层级关系。

总的来看，扩展可以“冻结”基本⽤例以保持稳定（因为扩展⽤例通常是不确定的）；包含可以提供公共交互，提⾼“复⽤”；泛化是同⼀业务⽬的的不同技术实现。

⽤例之间除了上述三种关系不再有其他关系，⽤例之间不能通讯。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝下⾯是另外⼀种解释，⽤例⼦来描述。

⽤例描述的是系统外部可见的⾏为，是系统为某⼀个或⼏个参与者提供的⼀段完整的服务。

从原则上来讲，⽤例之间都是并列的，它们之间并不存在着包含从属关系。

但是从保证⽤例模型的可维护性和⼀致性⾓度来看，我们可以在⽤例之间抽象出包含(include)、扩展(extend)和泛化 (generalization)这⼏种关系。

这⼏种关系都是从现有的⽤例中抽取出公共的那部分信息，然后通后过不同的⽅法来重⽤这部公共信息，以减少模型维护的⼯作量。

4.2.1 包含(include)包含关系是通过在关联关系上应⽤<<include>>构造型来表⽰的，如下图所⽰。

它所表⽰的语义是指基础⽤例(Base)会⽤到被包含⽤例(Inclusion)，具体地讲，就是将被包含⽤例的事件流插⼊到基础⽤例的事件流中。

UML软件建模教程课后习题和答案

UML 软件建模教程课后习题习题1一、简答题1、简述模型的作用。

答:现实系统的复杂性与内隐性,使得人们难于直接认识与把握,为了使得人们能够直观与明了地认识与把握现实系统,就需要借助于模型。

2、软件模型有什么特征？答:建模对象特殊,复杂性,多样性3、软件建模技术有哪些因素？答:软件建模方法,软件建模过程,软件建模语言,软件建模工具4、软件模型包括哪些方面的内容？答:从模型所反映的侧面瞧:功能模型,非功能模型,数据模型,对象模型,过程模型,状态模型,交互模型,架构模型,界面模型等;从软件开发工作瞧:业务模型,需求模型,分析模型,设计模型,测试模型等。

5、软件建模工具应该具有哪些基本功能？答:软件模型的生成与编辑,软件模型的质量保障,软件模型管理等二、填空题1、模型就是对现实的（抽象）与模拟,就是对现实系统（本质）特征的一种抽象、简化与直观的描述2、模型具有（反映性）、直观性、（简化性）与抽象性等特征。

3、从抽象程度,可以把模型分为（概念模型）、逻辑模型与（物理模型）三种类型。

4、较之于其她模型,软件模型具有（建模对象特殊）、复杂性与（多样性）等特征。

5、软件模型就是软件开发人员交流的（媒介）,就是软件升级与维护的（依据）。

6、软件建模技术的要素包括软件建模方法、（软件建模过程）、软件建模语言与（软件建模工具）。

7、从开发阶段瞧,软件建模有业务模型、（需求模型）、分析模型、（设计模型）与测试模型。

8、软件语言有软件需求定义语言、（软件设计语言）、软件建模语言、（软件结构描述语言）、软件程序设计语言等。

9、根据软件建模工具的独立性,把软件建模工具分为（独立软件）建模工具与（插件式软件）建模工具。

10、OMG 在（ 1997 ）年把UML 作为软件建模的标准,UML2 、0 版本就是（ 2005 ）年颁布的。

三、选择题1、对软件模型而言,下面说法错误的就是（ D ）。

A、就是人员交流的媒介B、就是软件的中间形态C、就是软件升级与维护的依据D、就是软件的标准文档2、下面说法错误的就是( B )。

UML建模——用例图（UseCaseDiagram）

UML建模——⽤例图（UseCaseDiagram）⽤例图主要⽤来描述⾓⾊以及⾓⾊与⽤例之间的连接关系。

说明的是谁要使⽤系统，以及他们使⽤该系统可以做些什么。

⼀个⽤例图包含了多个模型元素，如系统、参与者和⽤例，并且显⽰这些元素之间的各种关系，如泛化、关联和依赖。

它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。

【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。

⼀、⽤例图所包含的的元素1. 参与者(Actor)——与应⽤程序或系统进⾏交互的⽤户、组织或外部系统。

⽤⼀个⼩⼈表⽰。

2. ⽤例(Use Case)——⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。

⽤椭圆表⽰。

3. ⼦系统(Subsystem)——⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。

⼆、⽤例图所包含的的关系⽤例图中涉及的关系有：关联、泛化、包含、扩展。

如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。

【箭头指向】：⽆箭头，将参与者与⽤例相连接，指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。

⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。

⽗⽤例通常是抽象的。

在实际应⽤中很少使⽤泛化关系，⼦⽤例中的特殊⾏为都可以作为⽗⽤例中的备选流存在。

【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。

包含关系对典型的应⽤就是复⽤，也就是定义中说的情景。

但是有时当某⽤例的事件流过于复杂时，为了简化⽤例的描述，我们也可以把某⼀段事件流抽象成为⼀个被包含的⽤例；相反，⽤例划分太细时，也可以抽象出⼀个基⽤例，来包含这些细颗粒的⽤例。

这种情况类似于在过程设计语⾔中，将程序的某⼀段算法封装成⼀个⼦过程，然后再从主程序中调⽤这⼀⼦过程。

UML软件建模教程课后习题及答案

UML软件建模教程课后习题习题 1一、简答题1. 简述模型的作用。

答：现实系统的复杂性和内隐性，使得人们难于直接认识和把握，为了使得人们能够直观和明了地认识和把握现实系统，就需要借助于模型。

5. 软件建模工具应该具有哪些基本功能？答：软件模型的生成和编辑，软件模型的质量保障，软件模型管理等二、填空题1、模型是对现实的（抽象）和模拟，是对现实系统（本质）特征的一种抽象、简化和直观的描述。

2、模型具有（反映性）、直观性、（简化性）和抽象性等特征。

3、从抽象程度，可以把模型分为（概念模型）、逻辑模型和（物理模型）三种类型。

4、较之于其他模型，软件模型具有（建模对象特殊）、复杂性和（多样性）等特征。

5、软件模型是软件开发人员交流的（媒介），是软件升级和维护的（依据）。

6、软件建模技术的要素包括软件建模方法、（软件建模过程）、软件建模语言和（软件建模工具）。

7、从开发阶段看，软件建模有业务模型、（需求模型）、分析模型、（设计模型）和测试模型。

8、软件语言有软件需求定义语言、（软件设计语言）、软件建模语言、（软件结构描述语言）、软件程序设计语言等。

9、根据软件建模工具的独立性，把软件建模工具分为（独立软件）建模工具和（插件式软件）建模工具。

10、OMG在（ 1997 ）年把UML作为软件建模的标准，UML2.0版本是（ 2005 ）年颁布的。

三、选择题1、对软件模型而言，下面说法错误的是（ D ）。

A.是人员交流的媒介B.是软件的中间形态C.是软件升级和维护的依据D.是软件的标准文档2、下面说法错误的是（ B ）。

初学UML——用例图

初学UML——⽤例图开始学习UML建模语⾔，从⽤例图⼊⼿。

建模⼯具选择visio ⽤例图描述的是参与者所理解的系统功能，主要元素是⽤例和参与者，是帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。

这时处于项⽬初始，分析⽤户需求的阶段，不⽤管怎么实现具体的功能，只要能向客户形象化的表述项⽬的功能就⾏。

⽤例图有四个部分：⽤例（Use Case), 参与者（Actor),系统边界，关系。

1）参与者（Actor) 参与者是与系统交互的⼈或物。

⾸先当然包括我们的开发系统⽤户，除此之外，与我们开发的系统有关联的其他系统也算是参与者。

在UML图中我们⽤⼀个⼩⼈表⽰。

2）⽤例（Use Case) ⽤例是参与者可以感受到的系统服务或功能单元。

我理解的就是⽤户可以使⽤我们开发的项⽬去做的任何事情任何⽤例都不能在缺少参与者的情况下独⽴存在，同样，任何参与者也必须要有与之关联的⽤例。

在UML图中我们⽤椭圆表⽰：3）系统边界指系统与系统之间的界限。

把系统边界以外的同系统相关联的其他部分称为系统环境。

在UML图中我们⽤⼀个矩形表⽰。

4）关系⽤例图中的关系有4种：关联，泛化，包含和扩展。

关联：表⽰参与者和⽤例之间的交互。

为通信途径，任何⼀⽅都可发送或可接收消息。

箭头指向：指向消息接收⽅。

在UML中⽤直线表⽰包含：包含关系⽤来把⼀个较复杂的⽤例所表⽰的功能分解成较⼩的步骤。

包含⽤例是必须的，如果缺少包含⽤例，基⽤例就是不完整的。

包含关系最典型的应⽤就是复⽤。

这种情况类似与在过程设计语⾔中，将程序的某⼀段算法封装成⼀个⼦过程，然后在从主程序中调⽤这⼀⼦过程（这么说好像懂了点）在UML中，包含关系⽤带箭头的虚线段加《include》表⽰，箭头指向被包含的⽤例。

在VISIO中没有找到include包含关系，解决办法：1）选择菜单栏中的'UML'-》单击’构造型‘-》新建-》构造型那⾥输⼊include-》基类那⾥选择归纳，点击确定2）将UML⽤例下的“扩展”拖到绘图页上-》双击或右键属性-》构造下拉列表中选择include-》确定扩展：扩展关系是指⽤例功能的延伸。

Uml复习题

出题审阅批准一、选择题1、以下( D )不能当做模型：A、地球仪B、交通地图C、电路设计图D、灭火器2、以下( C )不属于UML基本构造块。

A、事物B、图C、规则D、关系3、在进行( A )相关领域的应用开发时，不推荐使用UML建模。

A、数值计算B、工业系统C 、信息系统D、软件系统4、以下关于软件的说法，错误的是( A )A、软件就是程序。

B、与硬件不同，软件不存在磨损和老化问题。

C、大多数软件是根据客户需求定做的，而不是利用现成的部件组装成所需要的软件。

D、软件是复杂的。

5、以下( D )不属于软件的生存期。

A、计划B、需求分析C、软件设计D、升级6、关于下图，说法错误的是( D )A、Reader是类名B、borrowBook是类的方法C、name是类的属性D、name是公有的7、以下图中，表示“包”这种事物的是( D )A、B、C、D、8、( A )图可以用来对需求建模。

A、用例图B、类图C、部署图D、组件图9、以下说法错误的是( A )A、用例既可以描述系统做什么，也可以描述系统是如何被实现的。

B、应该从参与者如何使用系统的角度出发定义用例，而不是从系统自身的角度。

C、基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。

D、备选流负责描述用例执行过程中异常的或偶尔发生的一些情况。

10、下面哪个不是UML中的静态视图( A )A、状态图B、用例图C、对象图D、类图11、下面哪个选项中有不是活动图中的基本元素( D )A、状态、分支B、状态、汇合C、泳道、转移D、信号、转移12、以下图中，表示“依赖”这种关系的是( A )A、B、C、D、13、事件表示对一个在时间和空间上占据一定位置的有意义的事情的规格说明，下面哪个不是事件的类型( D)A、信号B、调用事件C、变化事件D、源事件14、以下是图书管理系统中的相关类，属于实体类的是( A )A、书类B、借书操作界面类C、书籍管理类D、读者管理类15、通常对象有很多属性，但对于外部对象来说某些属性应该不能被直接访问，下面哪个不是UML中的类成员访问限定符( C )A、公有的（public）B、受保护的（protected）C、友员的（friendly）D、私有的（private）16、节点是存在于运行时并代表一项计算资源的物理元素，没有计算能力的节点称为（D）A、处理器B、规范C、接口D、设备17、在UML中，类之间的关系有一种为关联关系，其中多重性用来描述类之间的对应关系，下面哪个不是其中之一( D )A、0…、1B、0…、*C、1…、*D、*…、*18、顺序图是强调消息随时间顺序变化的交互图，下面哪个不是用来描述顺序图的组成部分( C )A、类角色B、生命线C、转换D、消息19、关于协作图的描述，下列哪个不正确( D )A、协作图作为一种交互图，强调的是参加交互的对象的组织。

用例图——包含（include）扩展（extend）和泛化（generalization）

⽤例图——包含（include）扩展（extend）和泛化（generalization）1、包含(include)包含关系：使⽤包含（Inclusion）⽤例来封装⼀组跨越多个⽤例的相似动作（⾏为⽚断），以便多个基（Base）⽤例复⽤。

基⽤例可以依赖包含⽤例执⾏的结果，但是双⽅都不能访问对⽅的属性。

也就是说，基⽤例的事件流具有它下属的所有的包含⽤例的事件流2、扩展(extend)扩展关系：将基⽤例中⼀段相对独⽴并且可选的动作，⽤扩展（Extension）⽤例加以封装，再让它从基⽤例中声明的扩展点（Extension Point）上进⾏扩展，从⽽使基⽤例⾏为更简练和⽬标更集中。

扩展⽤例为基⽤例添加新的可选⾏为。

扩展⽤例可以访问基⽤例的属性，因此它能根据基⽤例中扩展点的当前状态来判断是否执⾏⾃⼰。

但是扩展⽤例对基⽤例不可见。

也就是说，下属的扩展⽤例对应的事件流是基⽤例对应的事件流执⾏完毕后，可选的事件流，重点是可选。

3、泛化(generalization)泛化关系：⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。

⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。

4、扩展（extend）和泛化（generalization）的区别表⾯上看起来，好像两者没有什么分别，但是实际上他们之间的区别是⾮常的⼤的。

泛化：⼦⽤例⼀定和基⽤例是具有同⼀种操作的，或者说，⼦⽤例、⼦⽤例之间、基⽤例⼀定是同⼀种事件流扩展：下属扩展⽤例和基⽤例并不⼀定是同⼀类事件流，⽽且下属⽤例是基⽤例事件流执⾏完毕之后的⼀种选择有的时候，包含（include）和其他的两种关系也会有⼀定的重合，在实际操作中，应该⾃⼰判断⼀下，这种关系，更倾向于哪⼀种，从⽽做出适当的选择，毕竟我们使⽤⽤例图的⽬的是，更加清楚的表述系统的需求，⽽不是使系统的分析更加的复杂5、下⾯附上⼏张图，帮助理解⼀下6、下⾯，我们从整体上看⼀下，⽤例图都包含哪些内容7、下⾯我们来说⼀说⽤例规约和活动图，这⾥有⼀个问题：像上图中的每⼀个⽤例圆圈就是⼀个具体的动作，怎么还会有规约和活动图呢？实际上，真正合理的⽤例图中的每个⽤例都是⼀个能够代表⼀个完整动作的事件流，⽐如：订票可以作为⼀个⽤例，⽽订票这个⽤例是由⼀些列的有序事件组合完成的—>填写省份证号码—>跳转到⽀付界⾯—>确认订票信息—>确定⽀付—>订票成功。

02 UML用例图基础知识

表示符号
表示参与者与用例之间的通信，任何一方都可发送或接收消息。
uc 继承关系，子用例将继承基用例的所有行为、关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。
泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例。 uc Use Case Model
参与者总是处在正在建模的系统的外部，不是系统
的组成部分，是与系统、子系统或类发生交互的外部用户、进程或其他系统。
参与者有3大类，即系统用户、与本系统交互的其他系统和一些可以运行的进程。
名称
说明
人
即用户，是最常用的参与者。例如，汽车租赁公司的汽车租赁者，即客
户。
其他的系统
在当前的项目范围外，建立与其他系统的接口。该类位于程序边界之外
注：任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的
用例。
2）用例图形表示
在UML中，用例使用一个椭圆来表示，用例的名称写在椭圆里，如下图所示：
3）用例命名
用例是从用户的角度来描绘系统的功能，是根据所执行的实例来命名的，通常情况下，用例名是一个短语，例如浏览帐户、登陆系统等。命名的基本原则有以下几种：
一、什么是用例图（Use Case Diagram）二、用例图的组成三、用例建模技术
用例图也称为用户模型图，是由软件需求分析到最终实现的第1步，它是从用户的角度来描述系统功能，描述人们希望如何使用一个系统。用例图显示谁将是相关的用户、用户希望系统提供什么服务，以及用户需要为系统提供的服务。
线上标注<u<c Usee CaxsetMoedenl d>>)，箭头从子用例指向基用
例。

UML用例图的用例拓展与关联分析

UML用例图的用例拓展与关联分析UML（Unified Modeling Language）是一种用于软件系统的建模语言，用例图是UML中的一种图示工具，用于描述系统的功能需求和用户与系统之间的交互。

在用例图中，用例是对系统功能的描述，用例之间的关系则表示了不同用例之间的交互和依赖关系。

本文将探讨UML用例图中用例的拓展与关联分析。

一、用例拓展用例拓展是指在某个用例执行过程中，根据特定的条件和需求，对该用例进行扩展或修改。

用例拓展可以通过扩展关系（extend）来表示，该关系表示一个用例的行为可以被另一个用例的行为所扩展。

扩展关系可以帮助我们更好地理解系统的功能需求，并且可以在系统设计过程中提供更多的灵活性。

举个例子，假设我们正在设计一个在线购物系统的用例图。

其中一个基本用例是“下订单”，但是在某些情况下，用户可能需要修改订单中的商品数量或者删除某个商品。

这时，我们可以通过用例拓展的方式来描述这些特定的需求。

我们可以创建一个名为“修改订单”的拓展用例，它扩展了“下订单”用例，并且在用户需要修改订单时触发。

二、用例关联分析用例关联分析是指在用例图中，通过关联关系（association）来描述不同用例之间的关联和依赖关系。

关联关系表示了用例之间的相互关系，可以帮助我们更好地理解系统中不同用例之间的交互和依赖。

举个例子，假设我们正在设计一个社交媒体应用的用例图。

其中一个基本用例是“发布动态”，而另一个基本用例是“评论动态”。

这两个用例之间存在着关联关系，因为用户在发布动态后，其他用户可以对该动态进行评论。

我们可以在用例图中使用关联关系来表示这种关联和依赖关系。

除了关联关系，还有其他类型的用例关系可以用于描述不同用例之间的关系，如包含关系（include）和泛化关系（generalization）。

这些关系可以帮助我们更好地组织和理解系统的功能需求，同时也可以在系统设计中提供更多的灵活性和可扩展性。

综上所述，UML用例图的用例拓展与关联分析是系统设计过程中重要的一环。

用例直接的关系

用例直接的关系用例和直接的关系是指用例之间的依赖关系，包括扩展、包含、泛化、泛化和关联等。

在软件开发过程中，用例是描述系统功能和行为的重要手段。

下面将以几个典型的用例为例，详细介绍它们之间的关系。

1. 用户登录用例与用户注册用例的关系用户登录和用户注册是系统中常见的两个功能。

用户需要先注册账号才能登录系统。

因此，用户登录用例和用户注册用例之间存在依赖关系。

用户登录用例扩展了用户注册用例，即在用户注册成功后，才能进行登录操作。

用户注册用例包含了用户填写注册信息、验证信息、创建账号等步骤。

用户登录用例则包含了用户输入账号密码、验证账号密码等步骤。

两个用例之间的关系是一种扩展关系。

2. 商品搜索用例与购买商品用例的关系在电商系统中，用户可以通过搜索功能查找商品，并进行购买。

商品搜索用例与购买商品用例之间存在依赖关系。

购买商品用例是用户在搜索到商品后，进行购买操作的过程。

购买商品用例包含了用户选择商品、填写购买信息、确认订单等步骤。

商品搜索用例则包含了用户输入关键字、搜索商品等步骤。

两个用例之间的关系是一种包含关系。

3. 支付订单用例与查看订单用例的关系在购买商品后，用户需要支付订单，并可以查看订单的详细信息。

支付订单用例与查看订单用例之间存在关联关系。

支付订单用例是用户在确认订单后，进行支付操作的过程。

支付订单用例包含了用户选择支付方式、填写支付信息、确认支付等步骤。

查看订单用例则是用户在支付完成后，查看订单详细信息的过程。

查看订单用例包含了用户选择订单、查看订单信息等步骤。

两个用例之间的关系是一种关联关系。

4. 管理员登录用例与管理用户用例的关系在后台管理系统中，管理员需要先登录系统，才能进行用户管理操作。

管理员登录用例与管理用户用例之间存在依赖关系。

管理员登录用例扩展了管理用户用例，即在管理员登录成功后，才能进行用户管理操作。

管理员登录用例包含了管理员输入账号密码、验证账号密码等步骤。

管理用户用例则包含了管理员查看用户列表、编辑用户信息等步骤。

UML用例建模解析（二）---------用例执行者之间关系

UML⽤例建模解析（⼆）---------⽤例执⾏者之间关系(1) 关联关系关联关系是指执⾏者与⽤例之间的关系，⼜称为通信关系，如果某个执⾏者可以对某个⽤例进⾏操作，它们之间就具有关联关系，如下图所⽰，“经理”有⼀个功能为“查看库存报表”，因此可以在执⾏者“经理”和⽤例“查看库存报表”之间建⽴⼀个关联关系，关联关系⽤实线表⽰。

(2) 泛化关系执⾏者之间的关系只有⼀种，即泛化关系，⽤⼀个带有空⼼三⾓形的实线表⽰，如下图所⽰，在该图中，仓库管理员、系统管理员、经理都是员⼯的⼀种，因此员⼯拥有的功能这三者都拥有，如登录、修改个⼈信息等，为了减少⽤例的个数并且使系统更加符合⾯向对象设计规范，可以对执⾏者进⾏泛化，将各类执⾏者都具有相同的功能移⾄⽗执⾏者，⽽将每类执⾏者特有的功能保留在⼦执⾏者中。

常见的⽤例之间的关系有两种，分别是包含关系和扩展关系，下⾯介绍这两种关系的含义以及在⽤例图中如何表⽰。

(3) 包含关系如果多个⽤例都具有⼀部分相同的⾏为，可以将这部分相同的⾏为作为⼀个单独的⽤例抽取出来，与原来的⽤例形成⼀个包含关系。

如仓库管理员在进⾏⼊库、出库等操作之前需要先登录，登录是⼊库、出库流程的基本组成部分，因此⽤例“⼊库”和“出库”包含⽤例“登录”。

为了更加清晰地描述多个⽤例的相同⾏为，在⽤例图中提供了⽤例与⽤例之间的包含关系。

在UML中，包含关系⽤依赖线（虚线）加⼀个<<include>>表⽰，由原始⽤例指向包含⽤例，如下图所⽰：(4) 扩展关系扩展关系⼜称为延伸关系，如果⼀个⽤例在执⾏时可能会使⽤到另⼀个⽤例，或者使⽤⼀个新的⽤例对原有⽤例的⾏为进⾏扩展时可以使⽤扩展关系，如仓库管理员在⼊库时发现某种商品在系统中暂不存在，则可以增加新的商品信息；如果⼊库商品均已存在，则⽆需增加商品信息，此时⽤例“增加商品信息”可以作为⽤例“⼊库”的扩展⽤例。

在需要扩展的⽤例（原始⽤例）中需指定⼀个扩展点（即需扩展的位置），在下⼀节编写⽤例⽂档中将学习如何设置扩展点。