面向对象技术试题Word格式.docx
- 文档编号:20365954
- 上传时间:2023-01-22
- 格式:DOCX
- 页数:19
- 大小:608.51KB
面向对象技术试题Word格式.docx
《面向对象技术试题Word格式.docx》由会员分享,可在线阅读,更多相关《面向对象技术试题Word格式.docx(19页珍藏版)》请在冰豆网上搜索。
getNoQuarterState()或newNoQuarterState()
(4)tissueMachine->
(5)tissueMachine->
getSoldOutState()或newSoldOutState()
空
(1):
根据题意,本题使用的是状态模式,判断纸巾售卖机的状态,根据不同的状态执行不同的动作。
State定义了纸巾售卖机所对应的一些状态,如售出纸巾、纸巾售完等。
类SoldOutState、NoQuarterState、HasQuarterState、SoldState均由类State派生而来。
空
(2):
voidinsertQuarter()定义了一个"
投币"
的方法,即在"
没有投币"
状态1F,用户投币的方法。
tissureMachine->
setState是改变纸巾售卖机的状态,此时,用户已投入2元钱,故将此时的状态改为"
有2元钱"
的状态,纸巾售卖机调用"
状态的方法即可。
空(3):
voidejectQuarter()定义了一个"
退币"
状态下,用户按下退币按钮,纸巾售卖机将此时的状态改为"
状态,故直接调用getNoQuarterState()即可。
空(4):
根据纸巾售卖机状态图可知,当售出纸巾并且纸巾数量仍大于0时,将返回"
状态。
同空(3)的分析,此处应调用getNoQuarterState0。
空(5):
根据纸巾售卖机状态图可知,当售出纸巾并且纸巾数量等于0时,将返回"
纸巾售完"
此处用了if…else…判断语句,当纸巾数量仍大于0时,返回"
状态,否则,纸巾数量一定等于0。
空(5)处是else下的一条语句,故此处是判断count为0时纸巾售卖机的状态,显然应调用getSoldOutState()。
3阅读下列说明和Java代码,将应填入(n)处的字句写在答题纸的对应栏内。
某饭店在不同的时段提供多种不同的餐饮,其菜单的结构图如图10.43所示
。
现在采用组合(Composition)模式来构造该饭店的菜单,使得饭店可以方便地在其中添加新的餐饮形式,得到如图10.44所示的类图。
其中MenuComponent为抽象类,定义了添加(add)新菜单和打印饭店所有菜单信息(print)的方法接口。
类Menu表示饭店提供的每种餐饮形式的菜单,如煎饼屋菜单、咖啡屋菜单等。
每种菜单中都可以添加子菜单,例如图10.43中的甜点菜单。
类Menultem表示菜单中的菜式。
Java代码如下:
(1)abstractclass或publicabstractclass
(2)publicabstractvoidadd(MenuComponentmenuComponent)或abstractvoidadd(MenuComponentmenuComponent)或protectedabstractvoidadd(MenuComponentmenuComponent)
(3)add(menuComponent)
(4)menuComponent.print()
(5)allMenus.print()
组合模式将对象组合成树形结构以表示"
整体一部分"
的层次结构,其中的组合对象使得用户可以组合基元对象以及其他的组合对象,从而形成任意复杂的结构。
组合模式使得用户对单个对象和组合对象的使用具有一致性。
组合模式的结构如图10.46所示。
图中各部分说明如下。
类Component为组合中的对象声明接口,在适当的情况下,实现所有类共有接口的默认行为,声明一个接口用于访问和管理Component的子部件。
类Leaf在组合中表示叶节点对象,叶节点没有子节点,并在组合中定义图元对象的行为。
类Composite定义有子部件的那些部件的行为,存储子部件,并在Component接口中实现与子部件有关的操作。
类Client通过Component接口操纵组合部件的对象。
下列情况可以使用组合模式。
表示对象的整体一部分层次结构。
希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象。
本试题将组合模式应用到饭店菜单的构造中。
图10.44中的类MenuComponent对应图10.46中的Component,Menultem对应Leaf,Menu对应Composite。
在实现时,通常都会把Component定义为抽象类。
在Java中,用abstract关键字限定的类即为抽象类,所以空
(1)处应填入abstractclass。
根据注释,空
(2)处应该定义功能为"
添加新菜单"
的成员函数。
在子类Menultem和Menu中都可以看到add成员函数,说明子类中重置了父类中的成员函数。
所以空
(2)处应填入publicabstractvoidadd(MenuComponentmenuComponent)。
由图10.44可以看出,Menu中包含了MenuComponent的对象集合。
程序中用Java中的list来实现这个聚合关系,这样就可以利用list中提供的各种方法了。
list中用于添加元素的方法是add,所以空(3)处应填入add(menuComponent)。
空(4)处出现在方法print中,其功能是打印出所有菜单的信息。
这里使用了list中的迭代器类iterator遍历每个子菜单,并调用子菜单中定义的print方法打印该子菜单的信息。
空(4)处应填入menuComponent.print()。
为了能够在mam中打印出所有的菜单信息,必须使用表示菜单结构中最顶层菜单的对象来调用print,因此空(5)处应填入allMenus.print()。
4阅读下列说明和C++代码,将应填入(n)处的字句写在答题纸的对应栏内。
某饭店在不同的时段提供多种不同的餐饮,其菜单的结构图如图10.41所示。
现在采用组合(Composition)模式来构造该饭店的菜单,使得饭店可以方便地在其中添加新的餐饮形式,得到如图10.42所示的类图。
每种菜单中都可以添加子菜单,例如图10.41中的甜点菜单。
c++代码如下:
(1)virtualvoidadd(MenuComponent*menuComponent)=0
(2)MenuComponent*
(3)menuComponents->
push_back(menuComponent)
(4)(*iter)
(5)allMenus
MenuComponent是虚基类,其中要定义添加新菜单纯虚函数,函数体在其派生类Menultem和Menu中实现。
空
(1)处应填入virtualvoidadd(MenuComponent*menuComponent)=0。
在类Menu中定义了列表menuComponents,用于保存添加的新菜单,由std:
:
list<
MenuComponent*>
iteratoriter可知列表的类型为MenuComponent*,故空
(2)处应填入MenuComponent*。
添加菜单时,可以从menuComponents列表的前面添加,也可以从menuComponents列表的后面添加,但通过菜单的输出函数可知,菜单是从列表的后面添加的,因此空(3)处应填入menuComponents->
push_back(menuComponent)。
iter是迭代器,用于遍历菜单列表menuComponents,空(4)处应填入(*iter)。
在主函数,打印饭店所有菜单信息的函数调用为allMenus->
print()。
5阅读下列说明和图,回答问题1至问题3,将解答填入答题纸的对应栏内。
一个简单的图形编辑器提供给用户的基本操作包括:
创建图形、创建元素、选择元素以及删除图形。
图形编辑器的组成及其基本功能描述如下。
(1)图形由文本元素和图元元素构成,图元元素包括线条、矩形和椭圆。
(2)图形显示在工作空间中,一次只能显示一张图形(即当前图形,current)。
(3)编辑器提供了两种操作图形的工具:
选择工具和创建工具。
对图形进行操作时,一次只能使用一种工具(即当前活动工具,active)。
①创建工具用于创建文本元素和图形元素。
②对于显示在工作空间中的图形,使用选择工具能够选定其中所包含的元素,可以选择一个元素,也可以同时选择多个元素。
被选择的元素成为当前选中元素(selected)。
③每种元素都具有相应的控制点。
拖曳选定元素的控制点,可以移动元素或者调整元素的大小。
现采用面向对象方法开发该图形编辑器,使用UML进行建模。
构建出的用例图和类图分别如图10.39和图10.40所示。
问题1:
根据说明中的描述,给出图10.39中U1和U2所对应的用例,以及
(1)和
(2)处所对应的关系。
问题2:
根据说明中的描述,给出图10.40中缺少的C1~C8所对应的类名以及(3)~(6)处所对应的多重度。
问题3:
图10.40中的类图设计采用了桥接(Bridge)设计模式,请说明该模式的内涵。
问题1:
U1:
移动元素U2:
调整元素的大小注:
U1和U2的答案可以互换
(1)<
>
(2)<
问题2:
C1:
创建工具C2:
选择工具C3:
线条C4:
矩形C5:
椭圆C6:
线条C7:
矩形C8:
椭圆注:
C3~C5的答案可以互换;
C6~C8的答案可以互换(3)0..1(4)1(5)1(6)1..*或*
问题3:
桥接模式将抽象部分和它的实现部分分离,使它们都可以独立地变化,对一个抽象的实现部分的修改应该对使用它的程序不产生影响。
由"
被选择的元素成为当前选中元素"
、"
每种元素都具有相应的控制点。
拖曳选定元素的控制点,可以移动元素或者调整元素的大小"
可知,U1和U2分别为"
移动元素"
和"
调整元素的大小"
用例U1和U2是对"
选择元素"
用例的功能扩展,因此空
(1)处和空
(2)处都应填入"
<
"
图形中包括文本元素和图元元素,图元元素又包括线条、矩形和椭圆。
所以C6~C8依次为线条、矩形、椭圆,三者顺序可以颠倒。
工具有两种:
创建工具用于创建文本元素和图形元素;
使用选择工具能够选定其中所包含的元素。
类图中C2和元素类关联,且通过C2可以调整元素的大小,因此C2为选择工具,则C1为创建工具。
C3~C5依次为线条、矩形、椭圆,顺序可以颠倒。
多重度有以下几种。
0..1:
表示0或1个实例。
n..m:
表示表示有n~m个实例。
0..*或者*:
表示没有实例个数的限制(包括没有实例)。
1:
表示只有一个实例。
1..*:
表示最少一个实例。
编辑器提供了两种操作图形的工具,但一次只能使用一种工具,当然也可以不选用工具,因此(3)处为0..1,(4)处为1。
图形由文本元素和图元元素构成,图形中至少要包含一种元素,因此(5)处为1,(6)处为1..*。
桥接模式用于将抽象部分与实现部分分离,使它们都可以独立地变化。
该模式使用"
对象间的组合关系"
解耦了抽象和实现之间固有的绑定关系,使得抽象和实现可以沿着各自的维度来变化。
6阅读下列说明和Java代码,将应填入(n)处的字句写在答题纸的对应栏内。
纸巾售卖机的状态如图10.37所示
采用状态(State)模式来实现该纸巾售卖机,得到如图10.38所示的类图。
其中类State为抽象类,定义了投币、退币、出纸巾等方法接口。
类SoldState、SoldOutState、NoQuarterState和HasQuarterState分别对应图10.37中纸巾售卖机的4种状态:
(2)tissueMachinE.getHasQuarterState()或newHasQuarterState()或tissueMachinE.HasQuarterState()
(3)tissueMachinE.getNoQuarterState()或newNoQuarterState()或tissueMachinE.NoQuarterState()
(4)tissueMachinE.getNoQuarterState()或newNoQuarterState()或tissueMachinE.NoQuarterState()
(5)tissueMachinE.getSoldOutState()或newSoldOutState()或tissueMachinE.SoldOutState()
publicvoidinsertQuarter()定义了一个"
状态下,用户投币的方法。
tissureMachine.setState是改变纸巾售卖机的状态,此时,用户已投入2元钱,故将此时的状态改为"
publicvoidejectQuarter()定义了一个"
状态,故直接调用NoQuarterState()即可。
同空(3)的分析,此处应调用NoQuarterState()。
空(5)处是else下的一条语句,故此处是判断count为0时纸巾售卖机的状态,显然应调用SoldOutState()。
7阅读下列说明和图,回答问题1至问题3,将解答填入答题纸的对应栏内。
Pay&
Drive系统(开多少付多少)能够根据驾驶里程自动计算应付的费用。
系统中存储了特定区域道路交通网的信息。
道路交通网由若干个路段(RoadSegment)构成,每个路段由两个地理位置坐标点(Node)标定,其里程数(Distance)是已知的。
在某些地理坐标点上安装了访问控制(AccessControl)设备,可以自动扫描行驶卡(Card)。
行程(Trajectory)由一组连续的路段构成。
行程的起点(Entry)和终点(Exit)都装有访问控制设备。
系统提供了3种行驶卡。
常规卡(RegularCard)有效期(ValidPeriod)为一年,可以在整个道路交通网内使用。
季卡(SeasonCard)有效期为三个月,可以在整个道路交通网内使用。
单次卡(MinitripCard)在指定的行程内使用,且只能使用一次。
其中,季卡和单次卡都是预付卡(PrepaidCard),需要客户(Customer)预存一定的费用。
系统的主要功能有:
客户注册、申请行驶卡、使用行驶卡行驶等。
使用常规卡行驶,在进入行程起点时,系统记录行程起点、进入时间(DateofEntry)等信息。
在到达行程终点时,系统根据行驶的里程数和所持卡的里程单价(UnitPrice)计算应付费用,并打印费用单(Invoice)。
季卡的使用流程与常规卡类似,但是不需要打印费用单,系统自动从卡中扣除应付费用。
单次卡的使用流程与季卡类似,但还需要在行程的起点和终点上检查行驶路线是否符合该卡所规定的行驶路线。
现采用面向对象方法开发该系统,使用UML进行建模。
构建出的用例图和类图分别如图10.33和图10.34所示。
根据说明中的描述,给出图10.33中的U1和U2所对应的用例,以及
(1)处所对应的关系。
根据说明中的描述,给出图10.34中缺少的C1~C6所对应的类名以及
(2)、(3)处所对应的多重度(类名使用说明中给出的英文词汇)。
根据说明中的描述,给出RoadSegment、Trajectory和Card所对应的类的关键属性(属性名使用说明中给出的英文词汇)。
使用常规卡行驶U2:
使用单次卡行驶
(1)<
RoadSegmentC2:
TrajectoryC3:
CardC4:
RegularCardC5:
PrepaidCardC6:
MinitripCard
(2)1(3)1..3
RoadSegment的属性:
DistanceTrajectory的属性:
Entry、Exit、DateOfEntryCard的属性:
UnitPrice、ValidPeriod
UML用例图中有包含(include)、扩展(extend)和泛化(generalization)_种关系。
包含关系:
使用包含(Inclusion)用例来封装一组跨越多个用例的相似动作(行为片断),以便多个基(Base)用例复用。
基用例可以依赖包含用例执行的结果,但是双方都不能访问对方的属性。
扩展关系:
将基用例中一段相对独立并且可选的动作,用扩展(Extension)用例加以封装,再让它从基用例中声明的扩展点(ExtensionPoint)上进行扩展,从而使基用例行为更简练和目标更集中。
扩展用例为基用例添加新的行为。
扩展用例可以访问基用例的属性,因此它能根据基用例中扩展点的当前状态来判断自己是否执行,但是扩展用例对基用例不可见。
对于一个扩展用例,可以在基用例上有几个扩展点。
泛化关系:
子用例和父用例相似,但表现出更特别的行为;
子用例将继承父用例的所有结构、行为和关系。
子用例可以使用父用例的一段行为,也可以重载它。
父用例通常是抽象的。
在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。
本题中,系统提供了3种行驶卡:
常规卡、季卡和单次卡。
其中,季卡和单次卡都是预付卡。
季卡的使用流程与常规卡类似,但是不需要打印费用单,系统自动从卡中扣除应付费用,即"
使用季卡行驶"
是"
使用常规卡行驶"
的子用例,因此U1为"
单次卡的使用流程与季卡类似,但还需要在行程的起点和终点上检查行驶路线是否符合该卡所规定的行驶路线,即"
使用单次卡行驶"
扩展了原来的用例"
,因此U2为"
,空
(1)处应填"
每个路段由两个地理位置坐标点(Node)标定,行程(Trajectory)由一组连续的路段构成,则C1为RoadSegment,C2为Trajectory。
行程的计算要通过读取卡来获得,卡分为常规卡和预付费卡,预付费卡又分为季卡和单次卡,所以C3~C6依次为Card、RegularCard、PrepaidCard和MinitripCard。
关联的多重度是指一个类的实例能与另一个类的多少个实例相关联。
一个客户可以有不同类型的卡,而每一张卡只能属于一个用户,也就是说一个Customer类实例可以与Card类的3个实例相关联,而一个Card类实例只能和一个Customer类实例相关联。
里程数是每个路段(RoadSegment)的关键属性;
行程有起点(Entry)和终点(Exit),在进入行程起点时,系统还要记录进入时间,那么行程(Trajectory)的关键属性有Entry、Exit、DateOfEntry;
卡有3种类型,不同的卡有不同的有效期(ValidPeriod)和里程单价(UnitPrice),所以Card的关键属性有UnitPrice、ValidPeriod。
8、业务用例和参与者一起描述
(1),而业务对象模型描述
(2)。
空白
(2)处应选择()
A.业务结构
B.结构元素如何完成业务用例
C.业务结构以及元素如何完成业务用例
D.组织支持的业务过程
C
业务用例模型描述一个业务的流程以及它们与外部各方(如客户和合作伙伴)之间的交互。
业务用例模型描述的是业务范围,与系统用例模型讲述的系统范围是不同的。
业务对象模型是描述业务用例实现的对象模型。
业务对象模型是一种根据职责、可交付工件和协作行为来说明业务流程的方法。
没有业务对象模型意味着存在一定风险,因为开发人员只是肤浅地注意业务的进行方式,他们将做自己所熟悉的工作,即在缺乏业务流程观念的前提下设计和创建软件,其结果可能是构建出来的系统无法满足业务需要。
9、业务用例和参与者一起描述
(1),而业务对象模型描述
(2)。
A.工作过程中的静态元素
B.工作过程中的动态元素
C.工作过程中的逻辑视图
没有业务对象模型意味着存在一定风险,因为开发人员只是肤浅地注意业务的进行方式,他们将做自己所熟悉的工作,即在缺乏业务流程观念的前提下设计和创建软件,其结果可能是构建出来的系统无法满足业务需要
10、
(1)设计模式允许一个对象在其状态改变时,通知依赖它的所有对象。
该设计模式的类图如图所示,其中,
(2)在
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 面向 对象 技术 试题
![提示](https://static.bdocx.com/images/bang_tan.gif)