你可能感兴趣的试题

在uML语言中，图5-3中的a、b、c三种图形符号按照顺序分别表示（）。

对于如图5-1所示的UML类图，正确的描述是（）。

已知3个类A、B和C，其中类A由类B的一个实例和类C的一个或多个实例构成。能够正确表示类A、B和C之间关系的UML类图是（）。

如图5-9所示的UML类图描绘的是 (113) 设计模式。关于该设计模式的叙述中，错误的是 (114) 。

图5-6属于UML中的 (79) ，其中，AccountManagement需要 (80) 。

UML类图中类与类之间的关系有5种：依赖、关联、聚合、组合与继承。若类A需要使用标准数学函数类库中提供的功能，那么类A与标准类库提供的类之间存在 (101) 关系；若类A中包含了其他类的实例，且当类A的实例消失时，其包含的其他类的实例也消失，则类A和它所包含的类之间存在 (102) 关系；若类A的实例消失时，其他类的实例仍然存在并继续工作，那么类A和它所包含的类之间存在 (103) 关系。

在“模型一视图一控制器”(MVC)模式中， (32) 主要表现用户界面， (33) 用来描述核心业务逻辑。

如图5-9所示的UML类图描绘的是 (113) 设计模式。关于该设计模式的叙述中，错误的是 (114) 。

采用 (88) 设计模式可保证一个类仅有一个实例；采用 (89) 设计模式可将对象组合成树形结构以表示“部分-整体”的层次结构，使用户对单个对象和组合对象的使用具有一致性；采用 (90) 设计模式可动态地给一个对象添加一些额外的职责。

在如图5-3所示的用例图(Use-Case Diagram)中，X1、X2和X3表示 (44) (已知UC3是抽象用例，那么X1可通过 (45) 用例与系统进行交互。并且，用例 (46) 是UC4的可选部分，用例 (47) 是UC4的必需部分。

(65) 限制了创建类的实例数量，而 (66) 将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

在如图5-3所示的用例图(Use-Case Diagram)中，X1、X2和X3表示 (44) (已知UC3是抽象用例，那么X1可通过 (45) 用例与系统进行交互。并且，用例 (46) 是UC4的可选部分，用例 (47) 是UC4的必需部分。

图5-6属于UML中的 (79) ，其中，AccountManagement需要 (80) 。

(65) 限制了创建类的实例数量，而 (66) 将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

采用 (88) 设计模式可保证一个类仅有一个实例；采用 (89) 设计模式可将对象组合成树形结构以表示“部分-整体”的层次结构，使用户对单个对象和组合对象的使用具有一致性；采用 (90) 设计模式可动态地给一个对象添加一些额外的职责。

在“模型一视图一控制器”(MVC)模式中， (32) 主要表现用户界面， (33) 用来描述核心业务逻辑。

UML类图中类与类之间的关系有5种：依赖、关联、聚合、组合与继承。若类A需要使用标准数学函数类库中提供的功能，那么类A与标准类库提供的类之间存在 (101) 关系；若类A中包含了其他类的实例，且当类A的实例消失时，其包含的其他类的实例也消失，则类A和它所包含的类之间存在 (102) 关系；若类A的实例消失时，其他类的实例仍然存在并继续工作，那么类A和它所包含的类之间存在 (103) 关系。

在如图5-3所示的用例图(Use-Case Diagram)中，X1、X2和X3表示 (44) (已知UC3是抽象用例，那么X1可通过 (45) 用例与系统进行交互。并且，用例 (46) 是UC4的可选部分，用例 (47) 是UC4的必需部分。

采用 (88) 设计模式可保证一个类仅有一个实例；采用 (89) 设计模式可将对象组合成树形结构以表示“部分-整体”的层次结构，使用户对单个对象和组合对象的使用具有一致性；采用 (90) 设计模式可动态地给一个对象添加一些额外的职责。

UML类图中类与类之间的关系有5种：依赖、关联、聚合、组合与继承。若类A需要使用标准数学函数类库中提供的功能，那么类A与标准类库提供的类之间存在 (101) 关系；若类A中包含了其他类的实例，且当类A的实例消失时，其包含的其他类的实例也消失，则类A和它所包含的类之间存在 (102) 关系；若类A的实例消失时，其他类的实例仍然存在并继续工作，那么类A和它所包含的类之间存在 (103) 关系。

当采用标准UML构建系统类模型(Class Model)时，若类B除了具有类A的全部特性外，类B还可定义新的特性以及置换类A的部分特性，那么类B与类A具有 (39) 关系；若类A的对象维持类B对象的引用或指针，并可与类C的对象共享相同的类B的对象，那么类A与类B具有 (40) 关系。

软件需求分析中，性能需求指定系统必须满足 (13) 或 (14) 。

在如图5-3所示的用例图(Use-Case Diagram)中，X1、X2和X3表示 (44) (已知UC3是抽象用例，那么X1可通过 (45) 用例与系统进行交互。并且，用例 (46) 是UC4的可选部分，用例 (47) 是UC4的必需部分。

当采用标准UML构建系统类模型(Class Model)时，若类B除了具有类A的全部特性外，类B还可定义新的特性以及置换类A的部分特性，那么类B与类A具有 (39) 关系；若类A的对象维持类B对象的引用或指针，并可与类C的对象共享相同的类B的对象，那么类A与类B具有 (40) 关系。

软件需求分析中，性能需求指定系统必须满足 (13) 或 (14) 。

(53) 是指把数据以及操作数据的相关方法组合在同一个单元中，使我们可以把类作为软件中的基本复用单元，提高其内聚度，降低其耦合度。面向对象中的 (54) 机制是对现实世界中遗传现象的模拟，通过该机制，基类的属性和方法被遗传给派生类。

(59) 设计模式将抽象部分与它的实现部分相分离，使它们都可以独立地变化。图5-5所示为该设计模式的类图，其中， (60) 用于定义实现部分的接口。

(83) 是把对象的属性和服务结合成一个独立的系统单元，并尽可能隐藏对象的内部细节； (84) 是指子类可以自动拥有父类的全部属性和服务； (85) 是对象发出的服务请求，一般包含提供服务的对象标识、服务标识、输入信息和应答信息等。

已知某子系统为外界提供功能服务，但该子系统中存在很多粒度十分小的类，不便被外界系统直接使用，采用 (57) 设计模式可以定义一个高层接口，这个接口使得这一子系统更加容易使用；当不能采用生成子类的方法进行扩充时，可采用 (58) 设计模式动态地给一个对象添加一些额外的职责。

在UML的各种视图中， (67) 显示外部参与者观察到的系统功能； (68) 从系统的静态结构和动态行为角度显示系统内部如何实现系统的功能； (69) 显示的是源代码以及实际执行代码的组织结构。

已知3个类O、P和Q，类O中定义了一个私有方法F1、一个公有方法F2和一个受保护的方法F3；类P和类Q是类O的派生类，其继承方式如下所示。
class P：protected O；
class Q：public O…；
关于方法F1的描述中正确的是 (9) ；关于方法F2的描述中正确的是 (10) ；关于方法F3的描述中正确的是 (11) 。

面向对象分析与设计中的 (62) 是指一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的；而 (63) 是指子类应当可以替换父类并出现在父类能够出现的任何地方。

当不适合采用生成子类的方法对已有的类进行扩充时，可以采用 (76) 设计模式动态地给一个对象添加一些额外的职责；当应用程序由于使用大量的对象，造成很大的存储开销时，可以采用 (77) 设计模式运用共享技术来有效地支持大量细粒度的对象；当想使用一个已经存在的类，但其接口不符合需求时，可以采用 (78) 设计模式将该类的接口转换成我们希望的接口。

(59) 设计模式将抽象部分与它的实现部分相分离，使它们都可以独立地变化。图5-5所示为该设计模式的类图，其中， (60) 用于定义实现部分的接口。

如图5-8所示的UML类图表示的是 (99) 设计模式。以下关于该设计模式的叙述中，错误是 (100) 。

面向对象分析与设计中的 (62) 是指一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的；而 (63) 是指子类应当可以替换父类并出现在父类能够出现的任何地方。

已知某子系统为外界提供功能服务，但该子系统中存在很多粒度十分小的类，不便被外界系统直接使用，采用 (57) 设计模式可以定义一个高层接口，这个接口使得这一子系统更加容易使用；当不能采用生成子类的方法进行扩充时，可采用 (58) 设计模式动态地给一个对象添加一些额外的职责。

在UML的各种视图中， (67) 显示外部参与者观察到的系统功能； (68) 从系统的静态结构和动态行为角度显示系统内部如何实现系统的功能； (69) 显示的是源代码以及实际执行代码的组织结构。

(83) 是把对象的属性和服务结合成一个独立的系统单元，并尽可能隐藏对象的内部细节； (84) 是指子类可以自动拥有父类的全部属性和服务； (85) 是对象发出的服务请求，一般包含提供服务的对象标识、服务标识、输入信息和应答信息等。

已知3个类O、P和Q，类O中定义了一个私有方法F1、一个公有方法F2和一个受保护的方法F3；类P和类Q是类O的派生类，其继承方式如下所示。
class P：protected O；
class Q：public O…；
关于方法F1的描述中正确的是 (9) ；关于方法F2的描述中正确的是 (10) ；关于方法F3的描述中正确的是 (11) 。

(53) 是指把数据以及操作数据的相关方法组合在同一个单元中，使我们可以把类作为软件中的基本复用单元，提高其内聚度，降低其耦合度。面向对象中的 (54) 机制是对现实世界中遗传现象的模拟，通过该机制，基类的属性和方法被遗传给派生类。

如图5-8所示的UML类图表示的是 (99) 设计模式。以下关于该设计模式的叙述中，错误是 (100) 。

已知3个类O、P和Q，类O中定义了一个私有方法F1、一个公有方法F2和一个受保护的方法F3；类P和类Q是类O的派生类，其继承方式如下所示。
class P：protected O；
class Q：public O…；
关于方法F1的描述中正确的是 (9) ；关于方法F2的描述中正确的是 (10) ；关于方法F3的描述中正确的是 (11) 。

(83) 是把对象的属性和服务结合成一个独立的系统单元，并尽可能隐藏对象的内部细节； (84) 是指子类可以自动拥有父类的全部属性和服务； (85) 是对象发出的服务请求，一般包含提供服务的对象标识、服务标识、输入信息和应答信息等。

在UML的各种视图中， (67) 显示外部参与者观察到的系统功能； (68) 从系统的静态结构和动态行为角度显示系统内部如何实现系统的功能； (69) 显示的是源代码以及实际执行代码的组织结构。

当不适合采用生成子类的方法对已有的类进行扩充时，可以采用 (76) 设计模式动态地给一个对象添加一些额外的职责；当应用程序由于使用大量的对象，造成很大的存储开销时，可以采用 (77) 设计模式运用共享技术来有效地支持大量细粒度的对象；当想使用一个已经存在的类，但其接口不符合需求时，可以采用 (78) 设计模式将该类的接口转换成我们希望的接口。

当不适合采用生成子类的方法对已有的类进行扩充时，可以采用 (76) 设计模式动态地给一个对象添加一些额外的职责；当应用程序由于使用大量的对象，造成很大的存储开销时，可以采用 (77) 设计模式运用共享技术来有效地支持大量细粒度的对象；当想使用一个已经存在的类，但其接口不符合需求时，可以采用 (78) 设计模式将该类的接口转换成我们希望的接口。

设计模式 (117) 将抽象部分与其实现部分相分离，使它们都可以独立地变化。图5-10为该设计模式的类图，其中， (118) 用于定义实现部分的接口。

下面给出了4种设计模式的作用。
外观(Facade)：为子系统中的一组功能调用提供一个一致的接口，这个接口使得这个子系统更加容易使用；
装饰(Decorator)：当不能采用生成子类的方法进行扩充时，动态地给一个对象添加一些额外的功能；
单例(Singleton)：保证一个类仅有一个实例，并提供一个访问它的全局访问点；
模板方法(Template Method)：在方法中定义算法的框架，而将算法中的一些操作步骤延迟到子类中实现。请根据下面叙述的场景选用适当的设计模式。若某面向对象系统中的某些类有且只有一个实例，那么采用 (35) 设计模式能够有效达到该目的；该系统中的某子模块需要为其他模块提供访问不同数据库系统(Oracle、SQL Server、DB2 UDB等)的功能，这些数据库系统提供的访问接口有一定的差异，但访问过程都是相同的，例如，先连接数据库，再打开数据库，最后对数据进行查询， (36) 设计模式可抽象出相同的数据库访问过程；系统中的文本显示类(TextView)和图片显示类(PictureView)都继承了组件类(Component)，分别显示文本和图片内容，现需要构造带有滚动条，或者带有黑色边框，或者既有滚动条又有黑色边框的文本显示控件和图片显示控件，但希望最多只增加3个类， (37) 设计模式可以实现该目的。

(55) 以静态或动态的连接方式，为应用程序提供一组可使用的类。 (56) 除了提供可被应用程序调用的类以外，还基本实现了一个可执行的架构。

若类A仅在其方法Method1中定义并使用了类B的一个对象，类A其他部分的代码都不涉及类B，那么类A与类B的关系应为 (74) ；若类A的某个属性是类B的一个对象，并且类A对象消失时，类B对象也随之消失，则类A与类B的关系应为 (75) 。

设计模式 (117) 将抽象部分与其实现部分相分离，使它们都可以独立地变化。图5-10为该设计模式的类图，其中， (118) 用于定义实现部分的接口。

下面给出了4种设计模式的作用。
外观(Facade)：为子系统中的一组功能调用提供一个一致的接口，这个接口使得这个子系统更加容易使用；
装饰(Decorator)：当不能采用生成子类的方法进行扩充时，动态地给一个对象添加一些额外的功能；
单例(Singleton)：保证一个类仅有一个实例，并提供一个访问它的全局访问点；
模板方法(Template Method)：在方法中定义算法的框架，而将算法中的一些操作步骤延迟到子类中实现。请根据下面叙述的场景选用适当的设计模式。若某面向对象系统中的某些类有且只有一个实例，那么采用 (35) 设计模式能够有效达到该目的；该系统中的某子模块需要为其他模块提供访问不同数据库系统(Oracle、SQL Server、DB2 UDB等)的功能，这些数据库系统提供的访问接口有一定的差异，但访问过程都是相同的，例如，先连接数据库，再打开数据库，最后对数据进行查询， (36) 设计模式可抽象出相同的数据库访问过程；系统中的文本显示类(TextView)和图片显示类(PictureView)都继承了组件类(Component)，分别显示文本和图片内容，现需要构造带有滚动条，或者带有黑色边框，或者既有滚动条又有黑色边框的文本显示控件和图片显示控件，但希望最多只增加3个类， (37) 设计模式可以实现该目的。

关系代数最基本的操作是并、差、笛卡尔积和 (41) 。п_A(R)表示关系R的 (42) 。

UML中有多种类型的图，其中， (49) 对系统的使用方式进行分类， (50) 显示了类及其相互关系， (51) 显示了人或对象的活动，其方式类似于流程图，通信图显示了在某种情况下对象之间发送的消息， (52) 与通信图类似，但强调的是顺序而不是连接。

在面向对象分析与设计中， (71) 是应用领域中的核心类，一般用于保存系统中的信息，以及提供针对这些信息的相关处理行为； (72) 是系统内对象和系统外参与者的联系媒介； (73) 主要是协调上述两种类对象之间的交互。

不同的对象收到同一消息可以产生完全不同的结果，这一现象叫做 (94) 。绑定是把过程调用和响应调用所需要执行的代码加以结合的一个过程。在一般的程序设计语言中，绑定在编译时进行，叫做 (95) ；而 (96) 则在运行时进行，即一个给定的过程调用和执行代码的结合直到调用发生时才进行。

(110) 是一种很强的“拥有”关系，“部分”和“整体”的生命周期通常一样。整体对象完全支配其组成部分，包括它们的创建和销毁等； (111) 同样表示“拥有”关系，但有时候“部分”对象可以在不同的“整体”对象之间共享，并且“部分”对象的生命周期也可以与“整体”对象不同，甚至“部分”对象可以脱离“整体”对象而单独存在。上述两种关系都是 (112) 关系的特殊种类。

若类A仅在其方法Method1中定义并使用了类B的一个对象，类A其他部分的代码都不涉及类B，那么类A与类B的关系应为 (74) ；若类A的某个属性是类B的一个对象，并且类A对象消失时，类B对象也随之消失，则类A与类B的关系应为 (75) 。

(55) 以静态或动态的连接方式，为应用程序提供一组可使用的类。 (56) 除了提供可被应用程序调用的类以外，还基本实现了一个可执行的架构。

UML中有多种类型的图，其中， (49) 对系统的使用方式进行分类， (50) 显示了类及其相互关系， (51) 显示了人或对象的活动，其方式类似于流程图，通信图显示了在某种情况下对象之间发送的消息， (52) 与通信图类似，但强调的是顺序而不是连接。

关系代数最基本的操作是并、差、笛卡尔积和 (41) 。п_A(R)表示关系R的 (42) 。

在面向对象分析与设计中， (71) 是应用领域中的核心类，一般用于保存系统中的信息，以及提供针对这些信息的相关处理行为； (72) 是系统内对象和系统外参与者的联系媒介； (73) 主要是协调上述两种类对象之间的交互。

不同的对象收到同一消息可以产生完全不同的结果，这一现象叫做 (94) 。绑定是把过程调用和响应调用所需要执行的代码加以结合的一个过程。在一般的程序设计语言中，绑定在编译时进行，叫做 (95) ；而 (96) 则在运行时进行，即一个给定的过程调用和执行代码的结合直到调用发生时才进行。

下面给出了4种设计模式的作用。
外观(Facade)：为子系统中的一组功能调用提供一个一致的接口，这个接口使得这个子系统更加容易使用；
装饰(Decorator)：当不能采用生成子类的方法进行扩充时，动态地给一个对象添加一些额外的功能；
单例(Singleton)：保证一个类仅有一个实例，并提供一个访问它的全局访问点；
模板方法(Template Method)：在方法中定义算法的框架，而将算法中的一些操作步骤延迟到子类中实现。请根据下面叙述的场景选用适当的设计模式。若某面向对象系统中的某些类有且只有一个实例，那么采用 (35) 设计模式能够有效达到该目的；该系统中的某子模块需要为其他模块提供访问不同数据库系统(Oracle、SQL Server、DB2 UDB等)的功能，这些数据库系统提供的访问接口有一定的差异，但访问过程都是相同的，例如，先连接数据库，再打开数据库，最后对数据进行查询， (36) 设计模式可抽象出相同的数据库访问过程；系统中的文本显示类(TextView)和图片显示类(PictureView)都继承了组件类(Component)，分别显示文本和图片内容，现需要构造带有滚动条，或者带有黑色边框，或者既有滚动条又有黑色边框的文本显示控件和图片显示控件，但希望最多只增加3个类， (37) 设计模式可以实现该目的。

开-闭原则(0pen-Closed Principle，OCP)是面向对象的可复用设计的基石。开-闭原则是指一个软件实体应当对 (104) 开放，对 (105) 关闭；里氏代换原则(Liskov Substitution Principle，LSP)是指任何 (106) 可以出现的地方， (107) 一定可以出现。依赖倒转原则(Dependence Inversion Principle，DIP)就是要依赖于 (108) 而不依赖于 (109) ，或者说要针对接口编程，不要针对实现编程。

(110) 是一种很强的“拥有”关系，“部分”和“整体”的生命周期通常一样。整体对象完全支配其组成部分，包括它们的创建和销毁等； (111) 同样表示“拥有”关系，但有时候“部分”对象可以在不同的“整体”对象之间共享，并且“部分”对象的生命周期也可以与“整体”对象不同，甚至“部分”对象可以脱离“整体”对象而单独存在。上述两种关系都是 (112) 关系的特殊种类。

UML中有多种类型的图，其中， (49) 对系统的使用方式进行分类， (50) 显示了类及其相互关系， (51) 显示了人或对象的活动，其方式类似于流程图，通信图显示了在某种情况下对象之间发送的消息， (52) 与通信图类似，但强调的是顺序而不是连接。

在面向对象分析与设计中， (71) 是应用领域中的核心类，一般用于保存系统中的信息，以及提供针对这些信息的相关处理行为； (72) 是系统内对象和系统外参与者的联系媒介； (73) 主要是协调上述两种类对象之间的交互。

不同的对象收到同一消息可以产生完全不同的结果，这一现象叫做 (94) 。绑定是把过程调用和响应调用所需要执行的代码加以结合的一个过程。在一般的程序设计语言中，绑定在编译时进行，叫做 (95) ；而 (96) 则在运行时进行，即一个给定的过程调用和执行代码的结合直到调用发生时才进行。

(110) 是一种很强的“拥有”关系，“部分”和“整体”的生命周期通常一样。整体对象完全支配其组成部分，包括它们的创建和销毁等； (111) 同样表示“拥有”关系，但有时候“部分”对象可以在不同的“整体”对象之间共享，并且“部分”对象的生命周期也可以与“整体”对象不同，甚至“部分”对象可以脱离“整体”对象而单独存在。上述两种关系都是 (112) 关系的特殊种类。

UML中有多种类型的图，其中， (49) 对系统的使用方式进行分类， (50) 显示了类及其相互关系， (51) 显示了人或对象的活动，其方式类似于流程图，通信图显示了在某种情况下对象之间发送的消息， (52) 与通信图类似，但强调的是顺序而不是连接。

开-闭原则(0pen-Closed Principle，OCP)是面向对象的可复用设计的基石。开-闭原则是指一个软件实体应当对 (104) 开放，对 (105) 关闭；里氏代换原则(Liskov Substitution Principle，LSP)是指任何 (106) 可以出现的地方， (107) 一定可以出现。依赖倒转原则(Dependence Inversion Principle，DIP)就是要依赖于 (108) 而不依赖于 (109) ，或者说要针对接口编程，不要针对实现编程。

(6) 反映了类间的一种层次关系，而 (7) 反映了一种整体与部分的关系。

(6) 反映了类间的一种层次关系，而 (7) 反映了一种整体与部分的关系。

开-闭原则(0pen-Closed Principle，OCP)是面向对象的可复用设计的基石。开-闭原则是指一个软件实体应当对 (104) 开放，对 (105) 关闭；里氏代换原则(Liskov Substitution Principle，LSP)是指任何 (106) 可以出现的地方， (107) 一定可以出现。依赖倒转原则(Dependence Inversion Principle，DIP)就是要依赖于 (108) 而不依赖于 (109) ，或者说要针对接口编程，不要针对实现编程。

开-闭原则(0pen-Closed Principle，OCP)是面向对象的可复用设计的基石。开-闭原则是指一个软件实体应当对 (104) 开放，对 (105) 关闭；里氏代换原则(Liskov Substitution Principle，LSP)是指任何 (106) 可以出现的地方， (107) 一定可以出现。依赖倒转原则(Dependence Inversion Principle，DIP)就是要依赖于 (108) 而不依赖于 (109) ，或者说要针对接口编程，不要针对实现编程。

开-闭原则(0pen-Closed Principle，OCP)是面向对象的可复用设计的基石。开-闭原则是指一个软件实体应当对 (104) 开放，对 (105) 关闭；里氏代换原则(Liskov Substitution Principle，LSP)是指任何 (106) 可以出现的地方， (107) 一定可以出现。依赖倒转原则(Dependence Inversion Principle，DIP)就是要依赖于 (108) 而不依赖于 (109) ，或者说要针对接口编程，不要针对实现编程。

开-闭原则(0pen-Closed Principle，OCP)是面向对象的可复用设计的基石。开-闭原则是指一个软件实体应当对 (104) 开放，对 (105) 关闭；里氏代换原则(Liskov Substitution Principle，LSP)是指任何 (106) 可以出现的地方， (107) 一定可以出现。依赖倒转原则(Dependence Inversion Principle，DIP)就是要依赖于 (108) 而不依赖于 (109) ，或者说要针对接口编程，不要针对实现编程。