UML判断题.docx

三、判断题：（如果正确，选择”T”,否则选择“F”） 1.严格地说，CASE只是一种开发环境而不是一种开发方法。T2.实体-联系图的数据实体对应于数据流图中的数据存储。T3.用户必须在系统开发的各个阶段参与开发。T4.系统功能常变，但对象相对稳定。T5.系统维护的重点是对应用程序的维护。T6.数据流程图不涉及技术细节，便于与用户交流。T7.系统分析的主要目标是完成系统的可行性分析。F8.用户界面设计过程中应先进行输入设计，后进行输出设计。F9.E-R模型具有的三要素是实体、属性、主关键字。F10.在数据库的规范化理论中，第二范式意味着关系中的所有非关键字都完全依赖于整个关键字。T11.开发大型、复杂的信息系统，通常采用的开发方法是面向对象开发方法。F12.结构化方法能对用户需求的变更作出快速响应。T13.差的系统规划好的程序开发不失为一个好的信息系统。F14.数据流图主要描述信息的计算机处理过程。T15.CASE也被称为计算机辅助软件工程。T16.绘制模块结构图属于系统分析阶段的工作。F17.信息来源于数据，是经由处理系统加工过的数据。T18.系统的基本组成部分包括输入、处理、存储。F19.计算机处理信息的缺点体现在对应用的适应性。T20.事务处理系统（TPS）是用来处理突发事件。F21.在面向对象方法中，系统模型的基本单元是数据。F22.系统分析员需要了解许多开发系统的工具和技术。T23.在数据处理中，基本的、不可分割的逻辑单位是文件。F24.系统分析的目标是提出建设系统的物理方案。F25.系统的培训工作一般在系统投入运行之后进行。F26.没有计算机参与就没有管理信息系统存在。T27.信息系统开发工作的目的和出发点是满足设计要求。F28.可以用学生姓名作为学生信息库表的关键字。F29.代码设计是在系统分析阶段完成的。F30.系统测试的目的是为了发现程序的错误。T31.信息系统的开发是一个技术过程。F32.开发人员对用户需求有了初步了解后就可以看手编程，这样可以提高效率。F33.选择网络结构是在系统设计阶段完成的。T34.最关心信息系统成本和效益的人员是信息系统的用户。F35.信息系统建设工作的复杂性，主要是由于信息系统技术手段的复杂性造成的。F36.管理信息系统开发的成功与否，取决于对编程语言和数据库系统的选择。F37.好的系统设计应给程序员留有更多的开发余地。F38.决策支持系统辅助各种决策人员从可选项中选出决策。T39.业务过程的规范化是信息系统成功的重要前提。T40.开发人员对用户需求有了初步了解后就可以着手编程，这样可提高效率。F41.人和计算机在构成管理信息系统时缺一不可。T42.假定全校的学生中没有重名者，就可以用学生姓名作为学生信息表的关键字。T43.结构化系统分析是对系统自下而上的分析过程。F44.高层管理层面对的是非结构化决策问题。T45.在文件管理系统阶段，多个程序可以使用同一个数据文件。T46.CASE是一种支持开发的专门工具。T47.软件编写和调试是系统实施阶段需要完成的任务。T48.管理信息系统(MIS)收集和记录影响组织的事务信息。F49.系统设计是程序设计的先导和前提条件。T50.系统实施计划工作在系统开发的系统设计阶段进行。T51.部门实体与员工实体之间存在多对多的关系。T52.系统维护是为了改正软件中遗留的错误。T53.严格区分开发阶段，重视文档是结构化方法的主要特征。T54.UML是一种可视化的建模语言。T55.类是由内部状态和外部行为相似的对象构成的集合。T56.从数据流程图到绘制信息系统流程图是一种单纯的符号改换。F57.UML是面向对象分析与设计的一种方法。F58.系统分析就是在系统开发可行的条件下，考虑如何选择机器设备及数据管理软件，从而得到一个用户满意的软件系统方案。F59.CASE是一种独立的开发方法。F60.数据流程图中既可表示信息流也可表示物流、资料流等内容，它是表达系统的有力工具。F61.面谈是系统调查时收集信息的主要方法。T62.系统测试的目的是充分证实系统的正确性。T63.系统设计阶段包括设计数据库的结构、设计代码、设计源程序等大量工作。F64.一个对象是把事物的属性和对属性数据的操作方法结合成的整体。T65.行为图描述系统的动态模型和组成对象间的交互关系。T66.状态图和活动图都属于行为图。T67.系统维护工作的对象是源程序代码。F68.数据库设计是从系统的观点出发建立一个数据模型。F69.系统设计面临的是技术环境。T70.开发信息系统并不仅仅是编写程序。T71. 一个状态图最多只能有一个初态和一个终态。（ 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 ） 112、活动图显示动作及其结果，着重描述操作实现中所完成的工作以及用例或类中的活动。（F） 113、用例模型的基本组成部件是用例、角色和用例之间的联系。（T ）114、UML是一种建模语言，而不是建模方法。（ T）115、用面向对象方法开发的软件系统，可维护性好。（ T ） 116、UML是一种直观化、明确化、构建和文档化软件系统的通用可视化建模语言。（T） 117、模型是对现实的简化，建模是为了更好地理解所开发的系统。（T）118、多态性防止了程序相互依赖而带来的变动影响。（F） 119、面向对象的继承性是子类自动共享父类数据结构和方法的机制。（T ）120、描述类中某个对象的行为，反映了状态与事件关系的是对象图。（ F ）121用例图中包含关系是指一个用例继承了另一个用例 ( F )122顺序图中每个对象向下方向伸展的虚线是对象的生命线 ( T )123协作图是对象图的扩展 ( F )124只有状态图采用泳道 ( F )125部署图一般把节点分成处理器和外部软件 ( F )126协作图和顺序图是等价的 ( T )127一台计算机有很多零部件，例如：键盘，鼠标，主板，显示器等等，我们可以用一个聚集图来描述，也就是说计算机是一个聚集体 ( T )128对象之间协作可以通过相互发送消息来实现，也就是消息可以是双向的 (F)129GRAPPLE把开发过程分为3个段，每个段之中又由许多动作组成 (T)130状态图中3个常用的动作是入口动作、出口动作和do动作,也就是对象处于这个状态时应该做什么。 ( F)131收集用例的方法可以采用交谈 (T)132在找出了类的继承关系后，通常可以用调用来表示最上层的基类( F)133顺序图所表达的是基于时间顺序的动态交互 (T)134用例是从用户的观点对系统行为的一个描述 (T)135UML无法体现历史状态 (F)136状态图中状态一般分成顺序子状态和随机子状态(F)137状态图是以实心圆点开头，以公牛眼结束的 (T)138状态图可以描述对象状态的变化过程 (T)139注解是UML中的解释元素 (F)140包是UML中唯一分组元素 (T)141用例包括了包含用例和随机用例 (F)142在画类图时，属性或操作如果是public的，可以用“+”表示，protected用“#”表示，private用“-”表示 (T)143棒糖图实际上就是接口图 (F)144组成是强类型的聚集 (T)145.通讯图作为一种交互图，强调的是参加交互的对象的组织 （F ）146.通讯图是顺序图的一种特例（ T ）147.通信图中有消息流的顺序号（T ）148.状态机图通过建立类对象的生命周期模型来描述对象随时间变化的动态行为。（ F）149.状态机图适用于描述状态和动作的顺序，不仅可以展现一个对象拥有的状态，还可以说明时间如何随时间的推移来影响这些状态。（ F ）150.状态机图的主要目的是描述对象创建和撤销的过程中资源的不同状态，有利于开发人员提高开发效率。（ F ）151.状态机图描述了一个实体基于时间反应的动态行为，显示了该实体如何根据当前所处状态对不同的事件做出反应。（ F ）152、顺序图由对象、生命线、控制焦点、和实体组成。（ F ）153、UML建模语言是由视图、图、模型元素和通用机制构成的层次关系来描述的。（ F ）154、UML是一种建模语言，是一种标准的表示，是一种方法。（ F ）155、泳道是分组机制，它描述了状态机图中对象所执行的活动。（ T ）156、同步消息和异步消息的主要区别是：同步消息的发生对象在消息发生以后，不必等待消息处理，可立即继续执行，而异步消息的发送对象则必须等待接收对象完成消息的处理后，才能继续执行。（ F ）157、类图中的角色是用于描述该类在关联中所扮演的角色和职责的。（ T ）158、类图用来表示系统中类和类与类之间的关系，它是对系统动态结构的描述。（ F）159、用例模型的基本组成部件是用例、角色和 用例之间的关系。（ F）160、用例之间有扩展、使用、组合等几种关系。（ F ）161、顺序图描述对象之间的交互关系，重点描述对象之间消息传递的时间顺序。（ T ）162、活动图显示动作及结果。着重描述操作实现中所完成的工作以及用例实例或类中的活动。（ T ）163、系统建模的三要素是：方法、模型和过程 （ F ）164、软件危机产生的原因主要有两个，一是与软件本身的特点相关，二是软件开发和维护的方法不正确。（ T） 165、软件开发过程模型有瀑布模型、渐增模型、演化模型、螺旋模型、智能模型 （ T）166、UML的特点：唯一性、连续性、维护性、复用性和逐步完善 （T）167、面向对象的三大重要特征:封装性、继承性和抽象 （F） 168、软件开发方法从结构化开发方法、模块化开发方法到面向对象开发方法是一个渐进的演变过程 ( F )169、软件生命周期描述了一个软件从定义、开发、使用、维护到服用的全过程 (T)170、面向对象系统的开发过程以体系结构为中心,以用例为驱动,是一顺序的过程（ F）171、 封装是把对象的属性和操作结合在一起，组成一个独立的对象（ T）172、 封装是一种信息隐蔽技术，目的是使对象的生产者和使用者分离，使对象的定义和实现分开。 （T）173、 面向对象方法中的多态机制使子类可以自动地拥有复制父类全部属性和操作 （ F ）174、 使得在多个类中能够定义同一个操作或属性名，并在每一个类中有不同的实现的一种方法是继承性 （ ）175、UML的五种视图用例视图、逻辑视图、构件视图、进程视图和配置视图 （）176、UML的静态建模机制包括类图、对象图、包图、构件图、配置图 （）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. 分析侧重于问题域，设计侧重于解域T202. 一般情况下，设计模型比分析模型复杂得多 T203. 分析解决做什么的问题，设计则解决怎么做的问题 T204. 分析模型主要侧重功能需求，而设计模型则要充分考虑各种非功能需求 T205. 一般情况下，分析模型不考虑系统结构，而设计模型则对系统结构进行全面设计 F206. 软件架构包含着一套关于软件系统组织的重要结论（decision） T207. 软件架构决策是最基础的决策，它的改变会带来巨大的影响 T208. 架构为设计提供了一个框架 T209. 架构是静态的，而不是动态的 F210. 存在两类边界类：用户界面类、系统和设备接口类 T211. 每对主角/用例对应有一个边界类 T212. 边界对象的生存周期不大于用例实例的生存期 F213. 边界类关注职责，而不关注界面细节T214. 分层时高层模块仅对当前层和紧邻着的下层建立依赖关系，同时尽量避免越层依赖 T215. 分层时较高层关注用户需求，受需求影响；而较低层关注实施平台，受环境影响 T216. 分层的目标是减低耦合度，并且减轻维护工作量，因此层数越多越好 F217. 分层要最大化包内的耦合和内聚，而最小化包之间的耦合T218. 设计模式描述了在特定环境中解决一般设计问题的通信构件频繁出现的结构 T219. 设计模式是一种从面向对象的设计到特定实现语言的映射机制 F220. 设计模式是中到小规模的模式，但通常独立于编程语言T221. 以 UML 表现设计模式时，一个设计模式是一个参数化的协作T222. 对于所有的设计类都需要进行状态建模 F223. 状态建模描述了一个类的对象的发展历史 T224. 对于复杂的类，应该利用多个状态图进行状态建模 F225. 某一时刻，一个类的对象可以处于多个不同的状态F226. 状态建模过程只会影响类的操作，而不会涉及类的属性F227. 实现关系容易支持多态性，而泛化关系则很难支持多态性 F228. 泛化关系是类与类之间的关系，而实现关系则是设计元素与接口之间的关系 T229. 泛化关系被用于重用实施，而实现关系只能重用行为的规约 T230. 泛化关系中父类可以提供缺省实现，而实现关系中接口不提供任何实现T231 一个用例实现时设计模型中一个特殊用例的表达式 T232.一个用例实现可以使用一个类图来表示 T233.用例实现提供了从分析和设计到需求的可追踪性 T234.用例实现与其关联的用例之间存在实现关系 F235设计模式描述了在特定环境中解决一般设计问题的通信构件频繁出现结构 T236设计模型是一种从面向对象的设计到特定实现语言的映射机制T237设计模型是中到大规模的模式，但是通常独立于编程语言 F238以 UML 表现设计模式时，一个设计模式是一个参数化的协作 T239. 每个对象都是某个类的实例T 240.每个类某一时刻必定存在对象实体 F241类是静态的描述 T242对象是动态的实例 T 243对于多重性=0 的情况，没有进一步的”设计”需求T244对于多重性=0 的情况，可直接使用一个简单值或指针进行实施 T245对于多重性1 的情况，也可以直接使用一个指针进行实施，也可进行”进一步”设计 F246对于多重性1 的情况，可以增加一个容器类T247对于所有的设计类都需要进行状态建模 F 248状态建模描述了一个类的对象的发展历史 T249对于复杂的类，应该利用多个状态图进行状态建模 F250某一时刻，一个类的对象可以处于多个不同的状态 F251状态建模过程只会影响类的操作，而不会设计类的属性F252关联类是一个设计类 T253关联类被附加在一个关联上T254关联类将一个多对多的关系转化为两个多对多的关系 F255对象间的每个连接对应着一