1、系统分析师-面向对象方法学(三)及答案解析(总分：37.00，做题时间：90 分钟)一、B单项选择题/B(总题数：11，分数：37.00)UML 提供了 5 种对系统动态方面建模的图，其中U U 4 /U /U对系统行为组织和建模；U U 5 /U /U对系统功能建模，它强调对象之间的控制流；U U 6 /U /U之间是同构的。（分数：3.00）(1). A.用例图 B.顺序图 C.协作图 D.状态图（分数：1.00）A.B.C.D.(2). A.用例图 B.活动图 C.状态图 D.顺序图（分数：1.00）A.B.C.D.(3). A.状态图和活动图 B.用例图和活动图 C.顺序图和协作图 D
2、.活动图和协作图（分数：1.00）A.B.C.D.图 7-3 中左边的 UML 类图描绘的是设计模式中的U U 7 /U /U模式。右边的 UML 类图描述了该模式的一种应用，其中与左图中的“Creator”对应的类是U U 8 /U /U。（分数：2.00）(1). A.Command B.Factory Method C.Composite D.Class Adapter（分数：1.00）A.B.C.D.(2). A.Bank B.Account C.Checking D.Savings（分数：1.00）A.B.C.D.UML 采用 4+1 视图来描述软件和软件开发过程，其中U U 9 /
3、U /U描绘了所设计的并发与同步结构；U U 10 /U /U表示软件到硬件的映射及分布结构；UML 中的类图可以用来表示 4+1 视图中的U U 11 /U /U。（分数：3.00）(1). A.逻辑视图(Logical View) B.实现视图(Implementation View) C.进程视图(Process View) D.部署视图(Deployment View)（分数：1.00）A.B.C.D.(2). A.逻辑视图 B.实现视图 C.进程视图 D.部署视图（分数：1.00）A.B.C.D.(3). A.逻辑视图 B.实现视图 C.进程视图 D.部署视图（分数：1.00）A.B
4、.C.D.图 7-4 中左边的 UML 类图描绘的是设计模式中的U U 12 /U /U模式。右边的 UML 类图描述了该模式的一种应用，其中与左图中的“Abstraction”对应的类是U U 13 /U /U。（分数：2.00）(1). A.Command B.Bridge C.Composite D.Proxy（分数：1.00）A.B.C.D.(2). A.DataAccess B.DataAccessImpl C.CustomerDM D.AccountDM（分数：1.00）A.B.C.D.面向对象系统由对象及其相互间的通信构成。一般来说，面向对象软件的测试可以分为 4 个层次进行。其
5、中，U U 14 /U /U测试，测试类中定义的每个方法，基本上相当于传统软件测试中的U U 15 /U /U；U U 16 /U /U测试，测试一组协同工作的类之问的相互作用。（分数：7.00）(1). A.类层 B.模板层 C.系统层 D.算法层（分数：1.00）A.B.C.D.(2). A.单元测试 B.系统测试 C.确认测试 D.集成测试（分数：1.00）A.B.C.D.(3). A.类层 B.模板层 C.系统层 D.算法层（分数：1.00）A.B.C.D.(4).设计模式(Design pattern)是一套被反复使用、多数人知晓、经过分类编目的、代码设计经验的总结。下面关于设计模式
6、所倡导的基本原则的描述，错误的是U U /U /U。 A.模块应对扩展开放，而对修改关闭 B.优先使用继承，而不是组合 C.要针对接口编程，而不是针对实现编程 D.抽象不应该依赖于细节，细节应当依赖于抽象（分数：1.00）A.B.C.D.(5).在企业应用系统开发中，方法调用(Method Invocation)和消息(Messaging)机制是两种常用的数据处理与交换方式。下面关于这两种机制的描述，不正确的是U U /U /U。 A.方法调用一般具有同步特性，而消息机制具有异步的特点 B.从可靠性方面考虑，消息机制比方法调用更有优势 C.从效率方面考虑，一般情况下消息机制比方法调用更有优势
7、D.消息调用机制可以支持多个数据的发送者和接收者，更加灵活（分数：1.00）A.B.C.D.(6).Java EE 是 Java 领域内企业级应用开发的框架与标准。下面关于采用 Java EE 架构的描述，不正确的是U U /U /U。 A.Java EE 定义了分布式环境中多层应用系统的架构，是多种 Java 技术的混合体 B.具有典型的三层结构：表现层、业务逻辑层和基础设施层 C.不同的应用系统对底层支持系统的要求可能不同，因此每次开发时应该针对不同的应用需求对底层系统进行二次开发，提供支持接口 D.要严格区分业务逻辑层和表现层，尤其应该注意不要在表现层中混杂业务代码（分数：1.00）A.
8、B.C.D.(7).希赛图书订单处理系统中，“创建新订单”和“更新订单”两个用例都需要检查客户的账号是否正确，为此定义一个通用的用例“核查客户账户”。用例“创建新订单”和“更新订单”与用例“核查客户账户”之间是U U /U /U。 A.包含关系 B.聚合关系 C.泛化关系 D.关联关系（分数：1.00）A.B.C.D.UML 的事物是对模型中最具有代表性的成分的抽象，U U 21 /U /U是模型的静态部分，描述概念或物理元素；U U 22 /U /U用来描述、说明和标注模型的任何元素。（分数：2.00）(1). A.结构事物 B.分组事物 C.行为事物 D.注释事物（分数：1.00）A.B.
9、C.D.(2). A.分组事物 B.注释事物 C.结构事物 D.行为事物（分数：1.00）A.B.C.D.UML 用关系把事物结合在一起，U U 23 /U /U描述一个事物发生变化会影响另一个事物的语义；U U 24 /U /U描述特殊元素的对象可替换一般元素的对象。（分数：3.00）(1). A.聚合关系 B.关联关系 C.包含关系 D.依赖关系（分数：1.00）A.B.C.D.(2). A.实现关系 B.聚合关系 C.泛化关系 D.关联关系（分数：1.00）A.B.C.D.(3).希赛公司欲开发一个在线交易系统。为了能够精确表达用户与系统的复杂交互过程，应该采用 UML 的U U /U
10、/U进行交互过程建模。 A.类图 B.顺序图 C.部署图 D.对象图（分数：1.00）A.B.C.D.在某银行业务的用例模型中，“取款”用例需要等到“存款”用例执行之后才能执行，两个用例之间的关系属于U U 26 /U /U；“取款”和“存款”两个用例中都需要执行查询余额的功能，将查询余额提取成独立的用例，那么“取款”和“存款”用例与“查询余额”用例之间的关系属于U U 27 /U /U。（分数：8.00）(1). A.关联关系 B.扩展关系 C.使用关系 D.依赖关系（分数：1.00）A.B.C.D.(2). A.扩展关系 B.使用关系 C.依赖关系 D.继承关系（分数：1.00）A.B.C
11、.D.(3).雇员类含有计算报酬的行为，利用面向对象的U U /U /U，可以使得其派生类专职雇员类和兼职雇员类计算报酬的行为有相同的名称，但有不同的计算方法。 A.多态性 B.继承性 C.封装性 D.复用性（分数：1.00）A.B.C.D.(4).面向对象分析的一项重要任务是发现潜在对象并进行筛选，错误的做法是删除U U /U /U。 A.系统范围之外的名词 B.表示事件的名词 C.不具有独特行为的名词 D.一个对象的同义词（分数：1.00）A.B.C.D.(5).面向对象分析的任务不包含U U /U /U。 A.建模系统功能 B.发现并确定业务对象 C.建模各对象的状态 D.组织对象并确定
12、对象间的关系（分数：1.00）A.B.C.D.(6).关于用例和类，错误的说法是U U /U /U。 A.两者都属于模型图的构成元素 B.存在抽象用例和抽象类 C.类图描述系统的部分静态视图，用例图描述系统与用户之间的交互视图 D.两者都可以用来描述系统的内部结构（分数：1.00）A.B.C.D.(7).U U /U /U适用于描述复杂算法的执行流程。 A活动图 B状态图 C类图D用例图（分数：1.00）A.B.C.D.(8).在面向对象方法中，信息流是通过向参与者或内部对象发送消息形成的。U U /U /U用于描述进出系统的信息流。 A.协作图 B.顺序图 C.数据流图 D.流程图（分数：1
13、.00）A.B.C.D.面向对象设计是模型驱动和用例驱动的，整个设计过程将U U 34 /U/U作为输入，并生成U U 35 /U /U作为输出。（分数：3.00）(1). A.逻辑数据流图 B.设计文档和用户说明 C.需求类图 D.需求模型（分数：1.00）A.B.C.D.(2). A.物理数据流图 B.设计文档和用户说明 C.设计类图和系统顺序图 D.设计模型（分数：1.00）A.B.C.D.(3).以下关于面向对象设计的叙述中，错误的是U U /U /U。 A.类的属性用于封装数据，类的方法用于封装行为 B.面向对象设计的基本思想包括抽象、封装和可扩展性 C.对象继承和多态可用来实现可扩
14、展性 D.对象持久化是指将数据库中的数据加载到内存中供应用程序访问（分数：1.00）A.B.C.D.采用面向对象技术设计银行信息系统，“账户类”应设计为U U 37 /U /U，“账户管理员类”应设计为U U 38 /U /U。（分数：2.00）(1). A.控制类 B.边界类 C.接口类 D.实体类（分数：1.00）A.B.C.D.(2). A.控制类 B.边界类 C.接口类 D.实体类（分数：1.00）A.B.C.D.遵守面向对象设计原则可以有效地提高系统的复用性和可维护性。应用U U 39 /U /U原则可扩展已有的系统，并为之提供新的行为；U U 40 /U /U原则建议在面向对象程序
15、设计中，应尽量针对接口编程，而不是针对实现编程。（分数：2.00）(1). A.开闭 B.里氏替换 C.依赖倒置 D.接口隔离（分数：1.00）A.B.C.D.(2). A.里氏替换 B.依赖倒置 C.接口隔离 D.最小知识（分数：1.00）A.B.C.D.系统分析师-面向对象方法学(三)答案解析(总分：37.00，做题时间：90 分钟)一、B单项选择题/B(总题数：11，分数：37.00)UML 提供了 5 种对系统动态方面建模的图，其中U U 4 /U /U对系统行为组织和建模；U U 5 /U /U对系统功能建模，它强调对象之间的控制流；U U 6 /U /U之间是同构的。（分数：3.0
16、0）(1). A.用例图 B.顺序图 C.协作图 D.状态图（分数：1.00）A. B.C.D.解析：(2). A.用例图 B.活动图 C.状态图 D.顺序图（分数：1.00）A.B. C.D.解析：(3). A.状态图和活动图 B.用例图和活动图 C.顺序图和协作图 D.活动图和协作图（分数：1.00）A.B.C. D.解析：解析 UML 提供了 5 种对系统动态方面建模的图。其中： 用例图描述了一组用例和参与者及它们之间的关系，对于系统行为的组织和建模特别重要。 交互图是顺序图和协作图的统称。顺序图强调消息的时间次序；协作图强调收发消息的对象的结构组织。这种是同构的，这意味着可以把一种图转
17、换为另一种图而没有信息损失。 状态图显示了一个由状态、转换、事件和活动组成的状态机，它强调一个对象按事件次序发生的行为。 活动图显示了系统中从活动到活动的流，它强调对象之间的控制流，对系统的功能建模是非常重要的。图 7-3 中左边的 UML 类图描绘的是设计模式中的U U 7 /U /U模式。右边的 UML 类图描述了该模式的一种应用，其中与左图中的“Creator”对应的类是U U 8 /U /U。（分数：2.00）(1). A.Command B.Factory Method C.Composite D.Class Adapter（分数：1.00）A.B. C.D.解析：(2). A.Ba
18、nk B.Account C.Checking D.Savings（分数：1.00）A. B.C.D.解析：解析 Command 模式将一个请求封装为一个对象，从而将不同的请求对象化并进行排队或登记，以支持撤销操作。 Factory Method 模式定义一个创建对象的接口，但由子类决定需要实例化哪一个类。 Composite 模式将对象组成树结构来表示局部和整体的层次关系。客户可以统一处理单个对象和对象组合。Class Adapter 模式将一个类的接口转换成用户希望得到的另一种接口。它使原本不相容的接口得以协同工作。UML 采用 4+1 视图来描述软件和软件开发过程，其中U U 9 /U
19、/U描绘了所设计的并发与同步结构；U U 10 /U /U表示软件到硬件的映射及分布结构；UML 中的类图可以用来表示 4+1 视图中的U U 11 /U /U。（分数：3.00）(1). A.逻辑视图(Logical View) B.实现视图(Implementation View) C.进程视图(Process View) D.部署视图(Deployment View)（分数：1.00）A.B.C. D.解析：(2). A.逻辑视图 B.实现视图 C.进程视图 D.部署视图（分数：1.00）A.B.C.D. 解析：(3). A.逻辑视图 B.实现视图 C.进程视图 D.部署视图（分数：1.
20、00）A. B.C.D.解析：解析 UML 采用 4+1 视图来描述软件和软件开发过程： 逻辑视图：以问题域的语汇组成的类和对象集合。 进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描绘了所设计的并发与同步结构。 实现视图：对组成基于系统的物理代码的文件和组件进行建模。 部署视图：把构件部署到一组物理的、可计算的节点上，表示软件到硬件的映射及分布结构。 用例视图：最基本的需求分析模型。图 7-4 中左边的 UML 类图描绘的是设计模式中的U U 12 /U /U模式。右边的 UML 类图描述了该模式的一种应用，其中与左图中的“Abstraction”对应的类是U U
21、13 /U /U。（分数：2.00）(1). A.Command B.Bridge C.Composite D.Proxy（分数：1.00）A.B. C.D.解析：(2). A.DataAccess B.DataAccessImpl C.CustomerDM D.AccountDM（分数：1.00）A. B.C.D.解析：解析 Command 模式将一个请求封装为一个对象，从而将不同的请求对象化并进行排队或登记，以支持撤销操作。Bridge 模式将类的抽象概念和它的实现分离开来，使它们可以相互独立地变化。Composite 模式将对象组成树结构来表示局部和整体的层次关系，客户可以统一处理单个对
22、象和对象组合。Proxy 模式给另一个对象提供一个代理或定位符号，以控制对它的访问。因此，UML 类图描绘的是 Bridge模式。 将右图和左图进行对比不难得出，与左图中的“Abstraction”对应的类是 DataAccess。面向对象系统由对象及其相互间的通信构成。一般来说，面向对象软件的测试可以分为 4 个层次进行。其中，U U 14 /U /U测试，测试类中定义的每个方法，基本上相当于传统软件测试中的U U 15 /U /U；U U 16 /U /U测试，测试一组协同工作的类之问的相互作用。（分数：7.00）(1). A.类层 B.模板层 C.系统层 D.算法层（分数：1.00）A.
23、B.C.D. 解析：(2). A.单元测试 B.系统测试 C.确认测试 D.集成测试（分数：1.00）A. B.C.D.解析：(3). A.类层 B.模板层 C.系统层 D.算法层（分数：1.00）A.B. C.D.解析：解析 模板是面向对象语言所提供的一种特殊机制，通过模板可以定义一种特殊的类(称为模板类)。在这些类的定义中可以包含待定的类型参数，在声明类的实例时，系统会自动根据传递的类型生成用户想要生成的类实例。 面向对象的测试可以分成的 4 个层次如下： 测试与对象关联的单个操作(方法)，即算法层。由于是测试单个方法，所以相当于传统软件测试中的单元测试。 测试单个对象类，即类层。 测试对
24、象集群(测试一组协同工作的类之间的相互作用)，即模板层。 测试整个面向对象系统，即系统层。(4).设计模式(Design pattern)是一套被反复使用、多数人知晓、经过分类编目的、代码设计经验的总结。下面关于设计模式所倡导的基本原则的描述，错误的是U U /U /U。 A.模块应对扩展开放，而对修改关闭 B.优先使用继承，而不是组合 C.要针对接口编程，而不是针对实现编程 D.抽象不应该依赖于细节，细节应当依赖于抽象（分数：1.00）A.B. C.D.解析：解析 本题所考查的是面向对象设计的一些基本原则，这些原则如下： 开闭原则：一个软件实体应当对扩展开放，对修改关闭。在设计一个模块时，应
25、当使这个模块可以在不被修改的情况下被扩展。关键在于抽象，抽象层要预见所有可能的扩展，因此抽象层在任何扩展情况下都不会改变，即对修改关闭。同时，由于从抽象层导出一个或多个新类，可以有不同的实现，改变系统的行为，此即对扩展开发。简而言之，抽象层对修改关闭，通过扩展实现改变系统行为。 里氏代换原则：任何基类可以出现的地方，子类一定可以出现。 依赖原则：要依赖于抽象，而不是具体实现。也可以这样说，要针对接口编程，不要针对实现编程。 接口分离原则：应当为客户端提供尽量小的单独的接口，而不是提供大的接口。 组合复用原则：要尽量使用组合而不是继承关系达到复用目的。 迪米特法则：又叫最少知识法则，就是说一个对
26、象应当对其他对象有尽可能少的了解。 有关这些原则的详细介绍，请学习指定教材系统分析师教程(张友生，清华大学出版社)第 13.4.3 节。(5).在企业应用系统开发中，方法调用(Method Invocation)和消息(Messaging)机制是两种常用的数据处理与交换方式。下面关于这两种机制的描述，不正确的是U U /U /U。 A.方法调用一般具有同步特性，而消息机制具有异步的特点 B.从可靠性方面考虑，消息机制比方法调用更有优势 C.从效率方面考虑，一般情况下消息机制比方法调用更有优势 D.消息调用机制可以支持多个数据的发送者和接收者，更加灵活（分数：1.00）A.B.C. D.解析：解
27、析 方法调用是指当某个事件发生时，调用某个对象的方法来处理事件。消息机制是指当某个事件发生时，把相关的消息发送给某些对象(一个或多个)，相关对象捕获消息后，进行相应的处理。 从以上定义可以看出，方法调用一般具有同步特性，而消息机制具有异步的特点。在消息调用机制中，消息是通过消息总线进行发送的，可以支持多个数据的发送者和接收者，更加灵活。 从效率方面考虑，由于方法调用指定调用某个对象的方法同步进行，所以效率要高一些。而消息机制由于采用异步方法，数据不一定得到很快处理，具体要根据接收消息的对象的处理情况，所以一般情况下效率会低一些。但是，从可靠性方面考虑，由于消息机制是通过系统总线来完成，且可能有
28、多个接收者，所以比方法调用更有优势。(6).Java EE 是 Java 领域内企业级应用开发的框架与标准。下面关于采用 Java EE 架构的描述，不正确的是U U /U /U。 A.Java EE 定义了分布式环境中多层应用系统的架构，是多种 Java 技术的混合体 B.具有典型的三层结构：表现层、业务逻辑层和基础设施层 C.不同的应用系统对底层支持系统的要求可能不同，因此每次开发时应该针对不同的应用需求对底层系统进行二次开发，提供支持接口 D.要严格区分业务逻辑层和表现层，尤其应该注意不要在表现层中混杂业务代码（分数：1.00）A.B.C. D.解析：解析 Java EE 以前称为 J2
29、EE，可以帮助开发和部署可移植、健壮、可伸缩且安全的服务器端Java 应用程序。Java EE 是在 Java SE 的基础上构建的，它提供 Web 服务、组件模型、管理和通信 API，可以用来实现企业级的面向服务体系结构(SOA)和 Web 2.0 应用程序。Java EE 定义了分布式环境中多层应用系统的架构，是多种 Java 技术的混合体，具有典型的三层结构：表现层、业务逻辑层和基础设施层。在实际应用中，基础设施层应该要保持稳定，要严格区分业务逻辑层和表现层，尤其应该注意不要在表现层中混杂业务代码。(7).希赛图书订单处理系统中，“创建新订单”和“更新订单”两个用例都需要检查客户的账号是
30、否正确，为此定义一个通用的用例“核查客户账户”。用例“创建新订单”和“更新订单”与用例“核查客户账户”之间是U U /U /U。 A.包含关系 B.聚合关系 C.泛化关系 D.关联关系（分数：1.00）A. B.C.D.解析：解析 用例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。它确定了一个和系统参与者进行交互并可由系统执行的动作序列。用例模型描述的是外部执行者(actor)所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。 两个用例之间的关系可以概括为两种情况。一种是用于重用的包含关系，用 i
31、nclude 表示(在 UML 1.x 版本中用 use 表示)；另一种是用于分离出不同行为的扩展，用 extend 表示(在 UML 1.x 版本中用 extends 表示)。 (1)包含关系。当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个构件来实现某一个用例的部分功能很重要时，我们应该使用包含关系来表示它们。 (2)扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，则将这个用例分为一个主用例和一个或多个辅用例描述可能更加清晰。 另外，用例之间还存在一种泛化关系。用例可以被特别列举为一个或多个子用例，这被称为用例泛化。当父用例能够被
32、使用时，任何子用例也可以被使用。例如，我们购买飞机票，既可以是电话订票，也可以是网上订票，则订票用例就是电话订票和网上订票的抽象。UML 的事物是对模型中最具有代表性的成分的抽象，U U 21 /U /U是模型的静态部分，描述概念或物理元素；U U 22 /U /U用来描述、说明和标注模型的任何元素。（分数：2.00）(1). A.结构事物 B.分组事物 C.行为事物 D.注释事物（分数：1.00）A. B.C.D.解析：(2). A.分组事物 B.注释事物 C.结构事物 D.行为事物（分数：1.00）A.B. C.D.解析：解析 UML 有三种基本的构造块，分别是事物(元素)、关系和图。事物
33、是 UML 中重要的组成部分。关系把事物紧密联系在一起。图是很多有相互相关的事物的组。 UML 中的事物也称为建模元素，包括结构事物、动作事物、分组事物和注释事物。这些事物是 UML 模型中最基本的面向对象的构造块。 (1)结构事物。结构事物在模型中属于最静态的部分，代表概念上的或物理上的元素。总共有七种结构事物： 首先是类，类是描述具有相同属性、方法、关系和语义的对象的集合。一个类实现一个或多个接口。 第二种是接口，接口是指类或组件提供特定服务的一组操作的集合。因此，一个接口描述了类或组件的对外的可见的动作。一个接口可以实现类或组件的全部动作，也可以只实现一部分。 第三种是协作，协作定义了交
34、互的操作，使一些角色和其他元素一起工作，提供一些合作的动作，这些动作比元素的总和要大。因此，协作具有结构化、动作化、维的特性。一个给定的类可能是几个协作的组成部分。这些协作代表构成系统的模式的实现。 第四种是用例，用例描述一系列的动作，这些动作是系统对一个特定角色执行，产生值得注意的结果的值。在模型中用例通常用来组织动作事物。用例是通过协作来实现的。 第五种是活动类，活动类是这样一种类，它的对象有一个或多个进程或线程。活动类和类很相像，只是它的对象代表的元素的行为和其他的元素是同时存在的。 第六种是构件，构件是物理上或可替换的系统部分，它实现了一个接口集合。在一个系统中，可能会遇到不同种类的构
35、件，例如 DCOM 或 EJB。 第七种是节点，节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个组件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。 (2)动作事物：动作事物是 UML 模型中的动态部分。它们是模型的动词，代表时间和空间上的动作。总共有两种主要的动作事物。 第一种是交互(内部活动)，交互是一组对象在特定上下文中，为达到特定的目的而进行的一系列消息交换而组成的动作。交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序(消息产生的动作)、连接(对象之间的连接)。 第二种是状态机，状态机由一系列对象的状态组成。 内部
36、活动和状态机是 UML 模型中最基本的两个动态事物元素，它们通常和其他的结构元素、主要的类、对象连接在一起。 (3)分组事物。分组事物是 UML 模型中组织的部分，可以把它们看成是个盒子，模型可以在其中被分解。总共只有一种分组事物，称为包。包是一种将有组织的元素分组的机制。结构事物、动作事物甚至其他的分组事物都有可能放在一个包中。与组件(存在于运行时)不同的是包纯粹是一种概念上的东西，只存在于开发阶段。 (4)注释事物。注释事物是 UML 模型的解释部分。UML 用关系把事物结合在一起，U U 23 /U /U描述一个事物发生变化会影响另一个事物的语义；U U 24 /U /U描述特殊元素的对
37、象可替换一般元素的对象。（分数：3.00）(1). A.聚合关系 B.关联关系 C.包含关系 D.依赖关系（分数：1.00）A.B.C.D. 解析：(2). A.实现关系 B.聚合关系 C.泛化关系 D.关联关系（分数：1.00）A.B.C. D.解析：解析 用 UML 建立业务模型时，可以把业务人员看做是系统中的角色或者类。在建立抽象模型时，很少有类会单独存在，大多数都将会以某种方式彼此通信，因此还需要描述这些类之间的关系。关系是事物间的连接，在 UML 中，有几个很重要的关系。 (1)依赖关系。有两个元素 A、B，如果元素 A 的变化会引起元素 B 的变化，则称元素 B 依赖于元素 A。在
38、类中，依赖关系有多种表现形式，例如，一个类向另一个类发消息；一个类是另一个类的成员；一个类是另一个类的某个操作参数等。 (2)泛化关系。描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类中继承的，而父类则是子类的泛化。在 UML 中，对泛化关系有 3 个要求。 子类应与父类完全一致，父类所具有的关联、属性和操作，子类都应具有。 子类中除了与父类一致的信息外，还包括额外的信息。 可以使用父类实例的地方，也可以使用子类实例。 (3)关联关系。关联表示两个类的实例之间存在的某种语义上的联系。例如，一个老师为某所学校工作，一所学校
39、有多间教室。我们就认为老师和学校、学校和教室之间存在着关联关系。关联关系为类之间的通信提供了一种方式，它是所有关系中最通用、语义最弱的。关联关系通常可以再细分成以下两种： 聚集关系。聚集关系(聚合关系)是关联关系的特例，表示一种整体和部分的关系， 其中整体和部分的生命周期不相同。例如，电话机和话筒的关系，计算机和显示器的关系等都是聚集关系的例子。 组合关系。组合关系也是表示一种整体和部分的关系，其中整体和部分的生命周期相同。例如，公司与部门之间的关系就是组合关系的例子。 (4)实现关系。类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。在 UML 中，活动图用来表示系统中各种活动的
40、次序，它的应用非常广泛，既可用来描述用例的工作流程，也可用来描述类中某个方法的操作行为。活动图是由状态图变化而来的，它们各自用于不同的目的。活动图依据对象状态的变化来捕获动作(将要执行的工作或活动)与动作的结果。活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。(3).希赛公司欲开发一个在线交易系统。为了能够精确表达用户与系统的复杂交互过程，应该采用 UML 的U U /U /U进行交互过程建模。 A.类图 B.顺序图 C.部署图 D.对象图（分数：1.00）A.B. C.D.解析：解析 显然，为了能够精确表达用户与系统的复杂交互过程，应该使用交互图。在 U
41、ML 中，交互图包括顺序图、通信图、定时图和交互概览图。顺序图强调消息的时间次序，通信图强调消息流经的数据结构，定时图强调消息跨越不同对象或角色的实际时间，交互概览图是顺序图和活动图的混合体。在某银行业务的用例模型中，“取款”用例需要等到“存款”用例执行之后才能执行，两个用例之间的关系属于U U 26 /U /U；“取款”和“存款”两个用例中都需要执行查询余额的功能，将查询余额提取成独立的用例，那么“取款”和“存款”用例与“查询余额”用例之间的关系属于U U 27 /U /U。（分数：8.00）(1). A.关联关系 B.扩展关系 C.使用关系 D.依赖关系（分数：1.00）A.B.C.D.
42、解析：(2). A.扩展关系 B.使用关系 C.依赖关系 D.继承关系（分数：1.00）A.B. C.D.解析：解析 用例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。它确定了一个和系统参与者进行交互并可由系统执行的动作序列。用例模型描述的是外部执行者(actor)所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。 两个用例之间的关系可以概括为两种情况。一种是用于重用的包含关系，用 include 表示(在 UML 1.x 版本中用 use 表示)；另一种是用于分离出不同行为的扩展，用 exten
43、d 表示(在 UML 1x 版本中用 extends 表示)。 (1)包含关系。当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个构件来实现某一个用例的部分功能很重要时，我们应该使用包含关系来表示它们。 (2)扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，则将这个用例分为一个主用例和一个或多个辅用例描述可能更加清晰。 另外，用例之间还存在一种泛化关系。用例可以被特别列举为一个或多个子用例，这被称为用例泛化。当父用例能够被使用时，任何子用例也可以被使用。例如，我们购买飞机票，既可以是电话订票，也可以是网上订票，则订票用例就是电话订票和网
44、上订票的抽象。 用 UML 建立业务模型时，可以把业务人员看做是系统中的角色或者类。在建立抽象模型时，很少有类会单独存在，大多数都将会以某种方式彼此通信，因此还需要描述这些类之间的关系。关系是事物间的连接，在 UML 中，有几个很重要的关系。 (1)依赖关系。有两个元素 A、B，如果元素 A 的变化会引起元素 B 的变化，则称元素 B 依赖于元素 A。在类中，依赖关系有多种表现形式，例如，一个类向另一个类发消息；一个类是另一个类的成员；一个类是另一个类的某个操作参数等。 (2)泛化关系。描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类中继承的，而父类则是子类的泛化。在 UML 中，对泛化关系有3 个要求。 子类应与父类完全一致，父类所具有的关联、属性和操作，子类都应具有。 子类中除了与父类一致的信息外，还包括额外的信息。 可以使用父类实例的地方，也可以使用子类实例。 (3)关联关系。关联表示两个类的实例之间存在的某种语义上的联系。例如，一个老师为某所学校工作，一所学校有多间教室。我们就认为老师和学校、学校和教室之间存在着关联关系。关联关系为类之间的通信提供了一种方式，它是所有关系中最通用、语义最弱的。关联关系通常可以再细分成以下两种： 聚集关系。聚集关系(聚合关系)是关联关系的特例，表
