UML判断题

三、判断题：（如果正确，选择”T”,否则选择“F”）

1.严格地说，CASE只是一种开发环境而不是一种开发方法。T 2.实体-联系图的数据实体对应于数据流图中的数据存储。T 3.用户必须在系统开发的各个阶段参与开发。T 4.系统功能常变，但对象相对稳定。T 5.系统维护的重点是对应用程序的维护。T 6.数据流程图不涉及技术细节，便于与用户交流。T 7.系统分析的主要目标是完成系统的可行性分析。F

8.用户界面设计过程中应先进行输入设计，后进行输出设计。F 9.E-R模型具有的三要素是实体、属性、主关键字。F

10.在数据库的规范化理论中，第二范式意味着关系中的所有非关键字都完全依赖于整个关键字。T

11.开发大型、复杂的信息系统，通常采用的开发方法是面向对象开发方法。F 12.结构化方法能对用户需求的变更作出快速响应。T 13.差的系统规划＋好的程序开发不失为一个好的信息系统。F 14.数据流图主要描述信息的计算机处理过程。T 15.CASE也被称为计算机辅助软件工程。T 16.绘制模块结构图属于系统分析阶段的工作。F 17.信息来源于数据，是经由处理系统加工过的数据。T 18.系统的基本组成部分包括输入、处理、存储。F 19.计算机处理信息的缺点体现在对应用的适应性。T 20.事务处理系统（TPS）是用来处理突发事件。F 21.在面向对象方法中，系统模型的基本单元是数据。F 22.系统分析员需要了解许多开发系统的工具和技术。T 23.在数据处理中，基本的、不可分割的逻辑单位是文件。F 24.系统分析的目标是提出建设系统的物理方案。F 25.系统的培训工作一般在系统投入运行之后进行。F 26.没有计算机参与就没有管理信息系统存在。T 27.信息系统开发工作的目的和出发点是满足设计要求。F 28.可以用学生姓名作为学生信息库表的关键字。F 29.代码设计是在系统分析阶段完成的。F 30.系统测试的目的是为了发现程序的错误。T 31.信息系统的开发是一个技术过程。F

32.开发人员对用户需求有了初步了解后就可以看手编程，这样可以提高效率。F 33.选择网络结构是在系统设计阶段完成的。T

34.最关心信息系统成本和效益的人员是信息系统的用户。F

35.信息系统建设工作的复杂性，主要是由于信息系统技术手段的复杂性造成的。F 36.管理信息系统开发的成功与否，取决于对编程语言和数据库系统的选择。F 37.好的系统设计应给程序员留有更多的开发余地。F 38.决策支持系统辅助各种决策人员从可选项中选出决策。T 39.业务过程的规范化是信息系统成功的重要前提。T

40.开发人员对用户需求有了初步了解后就可以着手编程，这样可提高效率。F 41.人和计算机在构成管理信息系统时缺一不可。T

42.假定全校的学生中没有重名者，就可以用学生姓名作为学生信息表的关键字。T 43.结构化系统分析是对系统自下而上的分析过程。F 44.高层管理层面对的是非结构化决策问题。T

45.在文件管理系统阶段，多个程序可以使用同一个数据文件。T 46.CASE是一种支持开发的专门工具。T

47.软件编写和调试是系统实施阶段需要完成的任务。T 48.管理信息系统(MIS)收集和记录影响组织的事务信息。F 49.系统设计是程序设计的先导和前提条件。T

50.系统实施计划工作在系统开发的系统设计阶段进行。T 51.部门实体与员工实体之间存在多对多的关系。T 52.系统维护是为了改正软件中遗留的错误。T

53.严格区分开发阶段，重视文档是结构化方法的主要特征。T 54.UML是一种可视化的建模语言。T

55.类是由内部状态和外部行为相似的对象构成的集合。T 56.从数据流程图到绘制信息系统流程图是一种单纯的符号改换。F 57.UML是面向对象分析与设计的一种方法。F

58.系统分析就是在系统开发可行的条件下，考虑如何选择机器设备及数据管理软件，从而得到一个用户满意的软件系统方案。F 59.CASE是一种独立的开发方法。F

60.数据流程图中既可表示信息流也可表示物流、资料流等内容，它是表达系统的有力工具。F

61.面谈是系统调查时收集信息的主要方法。T 62.系统测试的目的是充分证实系统的正确性。T

63.系统设计阶段包括设计数据库的结构、设计代码、设计源程序等大量工作。F 64.一个对象是把事物的属性和对属性数据的操作方法结合成的整体。T 65.行为图描述系统的动态模型和组成对象间的交互关系。T 66.状态图和活动图都属于行为图。T 67.系统维护工作的对象是源程序代码。F

68.数据库设计是从系统的观点出发建立一个数据模型。F 69.系统设计面临的是技术环境。T 70.开发信息系统并不仅仅是编写程序。T

71. 一个状态图最多只能有一个初态和一个终态。（ F ） 72. 协作图中的消息必须要标出消息顺序号。（ T ）

73. 两个参与者（actor）之间可以有包含（include）关系、扩展（extend）关系或泛化（generalization）关系，而包含关系和扩展关系是依赖（dependency）关系的版型。（ F ）

74. 参与者（actor）和用例（use case）之间的关系是关联（association）关系。（ T ） 75. 类A和类B之间的关系如图1所示，则称类B中的getName()方法是对类A中的getName()方法的重载（overload）。（ T ）

图1 getName（）方法之间的关系

图2 活动图

76. 如图2所示，活动Gesture和Stream audio可以并发进行。（ T ）

77. 一个软件系统，如果只有源代码，缺乏其它相应的辅助文档，如缺乏顺序图和类图，则可以利用Rose进行逆向工程得到顺序图和类图，但得到的顺序图和类图会比较简单。（ F ）

78. CMM描述了五个级别的软件过程成熟度，即初始级、可重复级、已定义、已管理级、优化级。（ ）

79. UML模型由用例视图、物理视图、组件视图、进度视图和配置视图组成。(F) 80. 在设计类图时，可以不对类图中的每个关联进行命名，但如果需要命名的话，最好用一个“动词”给关联命名。（ F ）

81. 一个状态图最多只能由一个初态和一个终态。（F） 82. 协作图中的消息必须要有消息顺序号。(T)

83. 一个软件系统，如果只有源代码，缺乏其他相应的辅助文档，如缺乏顺序图和类图，则可以利用Rose进行逆向工程得到顺序图和类图，但得到的顺序图和类图会比较简单。（F）

84. CMM描述了五个级别的软件过程成熟度，即初始级、可重复级、已定义、已管理级、优化级。（T）

85. UML由用例视图、物理视图、组件视图、进度视图和配置视图组成。（F） 86. 在设计类图时，可以不用对类图中的每个关联进行命名，但如果需要命名的话，最好用一个“动词”给关联命名。（T） 87.一个顺序图只能有一个初态和多个终态。（ F ）

88.活动图中生命线的长度表示对象的激活的时间段。（F ） 89.组件图只能对源代码文件之间的关系进行建模。（ F ） 90.活动图中泳道的作用是用来发现工作流的。（ F ） 91.用例图和用例的概念相同，没有区别。（ F ）

92.顺序图和协作图都是用来描述对象之间的交互的，并可以相互转化。（T ） 93.包中元素可见性的符号”#“，表示只能被该包中的其它元素使用。( F) 94.部署图由节点（Node）和节点间的关联关系（Association）组成。（ T ） 95.两个参与者之间可以有包含关系、扩展关系或泛化关系，而包含关系和扩展关系是依赖关系的版型。(F)

96.参与者位于所要建模的系统边界的外部。(T)

97.在顺序图中无法表示要重复发送的消息，但在协作图中可以表示要重复发送的消息。( F )

98. 协作图中的消息必须要有消息顺序号。(T) 99. 参与者和用例之间的关系是关联关系。(T )。

100. RUP软件开发生命周期中有4个核心工作流，即初始阶段、细化阶段、构

造阶段和移交阶段。 ( F)

101. 软件开发工作只到软件交付使用为止。( F )

102. 为了符合程序设计风格指导原则，应尽可能把程序编得短些。（ F ） 103. 系统结构图中反映的是程序中数据结构的情况。 （ F ） 104. 结构化分析是面向数据流进行需求分析的方法。( T )

105. 程序测试应对程序模块的所有独立的执行路径至少测试一次。（ F ） 106. GOTO语句非常灵活，程序员应该尽量使用。（ F ）

107. 对于递归的问题应使用递归的过程，这样做可提高编程效率。( T ) 108. 工程的规模确定可行性研究需要时间的长短和费用的多少。（ T ） 109. 软件需求分析的任务应包括结构化程序分析。（ F ） 110. 操作手册的编写工作应该在软件测试阶段之前完成。（ T ） 111、泳道是一种分组机制，它描述了状态图中对象所执行的活动。（ F ）

177、UML

（Ｔ）

178、可行性研究分析包括经济可行性分析、技术可行性分析和开发可行性分析 （Ｆ）

179、UML的客户需求分析模型包括用例模型、类图、对象图和时序图组成。（Ｆ） 180、UML客户需求分析使用的CRC卡上责任栏的内容主要描述类的属性和操作（Ｔ）

181、UML客户需求分析产生的用例模型描述了系统的功能要求 （Ｔ） 182、在UML的需求分析建模中，用例模型不必与用户反复交流并加以确认。（Ｆ） 183、CRC卡中的描述由类名、类特征、类类型、责任和协作者共五部分组成 （Ｔ） 184、用例模型中的执行者可以是“人”执行者也可以是“外部”系统执行者 （Ｔ）

185、系统分析是在客户需求分析规格说明的基础之上对其进行的分析 （Ｔ） 186

某个行为的模型化工具 （Ｔ） 187

（Ｔ）

188、线程是内部的一个动作流，不能够与其他线程并发执行 （Ｆ） 189、状态图描述一个对象在不同事件的驱动下发生的状态迁移。（Ｔ）

190、活动图中动作状态之间的迁移不靠事件触发的（Ｆ）

191、活动图即可以描述对象的动态行为，还可以用来描述用例 （Ｔ） 192、活动图中活动状态的迁移是按

（Ｆ）

193、状态图和活动图描述系统中某个系统对象的一系列状态变化（Ｔ） 194、在UML

图由这些构件、接口以及构件之间的关系组成。（Ｔ）

195、UML可以描述硬件之间的互联关系，不能描述硬件单元上的软件系统的分布 （Ｆ）

196、系统体系结构建模可以分为软件系统体系结构建模和硬件系统体系结构建模 （Ｔ）

197、构件图主要用于建立系统的动态模型 （Ｆ）

198、结点之间、结点与构件之间的联系包括通信关联、依赖联系等。(T) 199、构件图中的构件没有实例,只要在配置图中才能标识构件的实例 (T) 200、状态的改变---迁移(T)

201. 分析侧重于问题域，设计侧重于解域T 202. 一般情况下，设计模型比分析模型复杂得多 T 203. 分析解决做什么的问题，设计则解决怎么做的问题 T

204. 分析模型主要侧重功能需求，而设计模型则要充分考虑各种非功能需求 T 205. 一般情况下，分析模型不考虑系统结构，而设计模型则对系统结构进行全面设计 F

206. 软件架构包含着一套关于软件系统组织的重要结论（decision） T 207. 软件架构决策是最基础的决策，它的改变会带来巨大的影响 T 208. 架构为设计提供了一个框架 T 209. 架构是静态的，而不是动态的 F

210. 存在两类边界类：用户界面类、系统和设备接口类 T

211. 每对主角/用例对应有一个边界类 T

212. 边界对象的生存周期不大于用例实例的生存期 F

213. 边界类关注职责，而不关注界面细节T

214. 分层时高层模块仅对当前层和紧邻着的下层建立依赖关系，同时尽量避免越层依赖 T

215. 分层时较高层关注用户需求，受需求影响；而较低层关注实施平台，受环境影响 T

216. 分层的目标是减低耦合度，并且减轻维护工作量，因此层数越多越好 F

217. 分层要最大化包内的耦合和内聚，而最小化包之间的耦合T

218. 设计模式描述了在特定环境中解决一般设计问题的通信构件频繁出现的结构 T

219. 设计模式是一种从面向对象的设计到特定实现语言的映射机制 F 220. 设计模式是中到小规模的模式，但通常独立于编程语言T 221. 以 UML 表现设计模式时，一个设计模式是一个参数化的协作T 222. 对于所有的设计类都需要进行状态建模 F 223. 状态建模描述了一个类的对象的发展历史 T 224. 对于复杂的类，应该利用多个状态图进行状态建模 F 225. 某一时刻，一个类的对象可以处于多个不同的状态F 226. 状态建模过程只会影响类的操作，而不会涉及类的属性F 227. 实现关系容易支持多态性，而泛化关系则很难支持多态性 F

228. 泛化关系是类与类之间的关系，而实现关系则是设计元素与接口之间的关系 T

229. 泛化关系被用于重用实施，而实现关系只能重用行为的规约 T

230. 泛化关系中父类可以提供缺省实现，而实现关系中接口不提供任何实现T

231．一个用例实现时设计模型中一个特殊用例的表达式 T 232.一个用例实现可以使用一个类图来表示 T

233.用例实现提供了从分析和设计到需求的可追踪性 T 234.用例实现与其关联的用例之间存在实现关系 F

235．设计模式描述了在特定环境中解决一般设计问题的通信构件频繁出现结构 T

236．设计模型是一种从面向对象的设计到特定实现语言的映射机制T 237．设计模型是中到大规模的模式，但是通常独立于编程语言 F 238．以 UML 表现设计模式时，一个设计模式是一个参数化的协作 T 239. 每个对象都是某个类的实例T 240.．每个类某一时刻必定存在对象实体 F 241．类是静态的描述 T 242．对象是动态的实例 T

243．对于多重性=0． ．１的情况，没有进一步的”设计”需求T

244．对于多重性=0． ．１的情况，可直接使用一个简单值或指针进行实施 T 245．对于多重性>1 的情况，也可以直接使用一个指针进行实施，也可进行”进一步”设计 F

246．对于多重性>1 的情况，可以增加一个容器类T 247．对于所有的设计类都需要进行状态建模 F 248．状态建模描述了一个类的对象的发展历史 T

249．对于复杂的类，应该利用多个状态图进行状态建模 F 250．某一时刻，一个类的对象可以处于多个不同的状态 F 251．状态建模过程只会影响类的操作，而不会设计类的属性F 252．关联类是一个设计类 T 253．关联类被附加在一个关联上T

254．关联类将一个多对多的关系转化为两个多对多的关系 F 255．对象间的每个连接对应着一个关联类的事例 T

256．关系数据库集中在数据库上，而面向对象系统则集中在行为上 T 257．关系数据库直接对外暴露数据，而面向对象系统则封装数据T 258．面向对象系统比关系数据库更先进，更高效 F

259．面向对象系统适合处理复杂行为，而关系数据库则适合于数据库报表系统T

260 ．实现关系容易支持多态性，而泛化关系则很难支持多态性F

261．泛化关系是类与类之间的关系，而实现关系则是设计元素与接口之间的关系T

262．泛化关系被用于重用实施，而实现关系只能重用行为的规约T

263．泛化关系中父类可以提供缺省实现，而实现关系中接口不提供任何实现 T 264．分析机制是构架机制的一种 T 265．分析机制与具体的实施环境相关F

266．分析机制通常源于架构或分析模型式的实例化 T 267．不同的分析机制一般具有不同的特征T

268．关于用例设计和用例分析的区别和联系，生成工件都是用例实现，但精确程序不同 T

269．关于用例设计和用例分析的区别和联系，都是说明对象之间的交互，组采用的 UML 模型不同 F

270．关于用例设计和用例分析的区别和联系，分析的基础要素是分析类，而设计则是设计元素 T

271．关于用例设计和用例分析的区别和联系，都包括静态视图和动态视图T 272．关于软件模块分层和分区的注意事项，分层时高层模块仅对当前层和紧邻着的下层建立依赖关系，同时尽量避免越层依赖 T

273．关于软件模块分层和分区的注意事项，分层时较高层关注用户需求，受需求影响;而较低层关注实施平台，受环境影响 T

274．关于软件模块分层和分区的注意事项，分层的目标是减低耦合度，而且减轻维护工作量，因为层数越多越好 F

275．关于软件模块分层和分区的注意事项，分区要最大化包内的耦合和内聚，而最小化包之间的耦合T

276．软件架构包含着一套关于软件系统组织的重要结论(decision) T 277．软件架构决策时最基础的决策，它的改变会带来巨大的影响 T 278．架构为设计提供了一个框架 T 279．架构师静态的，而不是动态的 F

280．关于状态图中，有且只有一个初始值状态 T

281．关于状态图中，至少有一个也可以有多个最终状态 F 282．关于状态图中，状态内可以执行不同的动作(Action)T 283．关于状态图中，事件可以引发状态的迁移 T

本文来源：https://www.bwwdw.com/article/u7q3.html