UML建模原理试题集.docx
《UML建模原理试题集.docx》由会员分享，可在线阅读，更多相关《UML建模原理试题集.docx（23页珍藏版）》请在冰点文库上搜索。
UML建模原理试题集
第一章面向对象方法论
三.名词解释
1.对象：
有形的、可以感知的实体
2.面向过程方法论：
以数据为中心的，以自顶向下方法将复杂数据加工处理逐步分解为简单、独立模块的开发方法。
3.面向对象方法论：
以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统的方法
4.多态：
相同的行为表现出不同的实现过程。
5.封装：
每个对象都包括自己进行操作所要的所有信息，而不依赖于其他随想来完成自己的操作。
四.简答题
1.简述面向对象三大特性。
封装：
对象在其操作中隐藏属性及操作的细节，良好的封装可以降低耦合度。
继承：
描述对象之间存在内在的静态关系，并最终以层次结构描述了整个世界
多态：
相同的行为表现出不同的实现过程
2.简述对象具有哪些特性：
原子性、抽象性、独立性。
3.简述面向过程方法论的优缺点。
4.简述面向对象方法论与面向过程方法论的各自特点。
5.如果让你为一个公司开发一个管理系统，请简述面向对象方法论和面向过程方法论的调
研方法？
6.继承的特点是什么，继承有哪几种表现方式？
7.简述单继承和多继承的异同点。
8.什么是多态，多态有几种表现形式，面向对象语言通过什么方式实现多态？
9.简述OOA与OOD的异同
3.优点：
把现实世界描绘为数据在信息系统中的流动，在数据流动过程中数据发生转化。
通过自顶向下的程序设计将复杂的程序分解为程序模块的层次图。
概括为自顶向下、逐步求
精、模块化设计、结构化编码的基本特点。
缺点：
当构成一个系统的因素过多，把所有可能的因素都考虑到，所有因素可能的因果
关系都分析清楚，把这些过程模拟出来实在太困难了。
对于复杂度较低、构成系统的各个部
分之间有着密不可分的因果关系，面向过程方法论很管用。
对于复杂的系统，任何小的变动
，都可能会引起蝴蝶效应
4.面向过程方法论把现实世界描绘为数据在信息系统中的流动，在数据流动过程中数据发
生转化。
通过自顶向下的程序设计将复杂的程序分解为程序模块的层次图。
概括为自顶向下
、逐步求精、模块化设计、结构化编码的基本特点。
面向过程方法论特点：
（1）世界由紧密联系的数据和过程组成。
（2）分析设计就是过程分
析。
（3）数据与过程分离。
面向对象方法论将世界看成一个个相互独立的对象，相互之间并无因果关系，它们平时
没有任何联系。
只有在某个外部力量的驱动下，对象之间才会依据某种规律相互传递信息。
这些交互构成了世界的一个“过程”。
在没有外力的情况下，对象保持“静止”状态。
面向
对象方法论特点：
（1）把世界看作相互独立的小对象。
这些对象根据某种规则组织起来，完成
一个特定的功能。
（2）分析设计就是对象获取，过程由特定规则组织起来的一组对象表现出来
。
（3）数据与过程不分离.
5.面向过程：
先问清多少业务流程，画出业务流程图，找出业务流程中每一步骤的参与部
门或岗位，弄清楚参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给
下一个环节的。
面向对象：
先问清有多少部门，多少岗位，再找到每一个岗位的业务代表，
问他们类似的问题：
你平时做什么？
每件事是谁交办的？
做完了你需要通知或传达给谁？
做
这件事你需要填写些什么表格？
6.特点
--子类拥有父类非private的属性和功能；
--子类具有自己的属性和功能，即子类可以扩展父类没有的属性和功能；
--子类可以以自己的方式重写父类的功能。
表现方式
--实现继承：
使用基类的属性和方法而无需额外编码的能力；
--接口继承：
仅使用属性和方法的名称、但是子类必须提供实现的能力；
--可视继承：
子窗体（类）使用基窗体（类）的外观和实现代码的能力。
7.单继承
--目前的主流继承方式，比如java,C#；
--继承结构清晰，为树状结构；
--类可以继承一个父类，但可以继承多个接口
--从完全封装（对象必须是属性+行为）到半封装（承认了行为的独立性，契约式）
多继承
--最早出现，目前多数语言已不支持；
--由于继承多个父类，子类经常存在命名冲突
--二义性：
两个父类中有同名方法的时候，你不得不在子类的调用中指明此方法出自那
个父类
--多继承的滥用增加了系统复杂性，导致无法维护
8.多态：
相同的行为表现出不同的实现过程
多态的表现形式
--子类以父类的身份出现；
--子类在运行时以自己的方式实现；
--子类以父类的身份出现时，子类特有的属性和方法不可以使用。
实现方式：
覆盖
--子类重新定义父类的函数的做法
--子类可以选择使用override将父类的实现替换为自己的实现
重载
--指允许存在多个同名函数，而这些函数的参数表不同（或许参数个数不同，或许参数
类型不同，或许两者都不同）
9.OOA偏重于理解问题，描述软件要做什么，而OOD偏重于理解解决方案，描述软件要如何做
OOA只考虑理想的设计，不关心技术与实现底层的细节，而OOD需要得到更具体详细更接近于真?
实的代码的设计方案
在设计结果的描述上，OOA偏重于描述对象的行为，OOD偏重于描述对象的属性与方
OOA只关注功能性需求，OOD还需要关注非功能性需求
OOD是对OOA的细化OOD的结果直接用于编码，与OOA的输出一样，只是更加详细完善
三.名词解释
1.建模：
对客观事件建立一种抽象的方法用以表征事物并获得对事物本身的理解。
同时把这种理解概念化，用逻辑组织起来，以表达所观察的对象的的内部结构和工作原理。
2.UML：
以面向对象方法论为指导，将现实世界映射成软体世界的一种图形化描述语言
四.简答题
1.简述蓝图与草图的区别，并简单描述其适用的场景
2.说明UML适用的建模领域，以及作用和主要参与人员。
解答:
1.蓝图一般是指采用CASE工具绘制的、正式的、规范的UML模型
草图则通常是指手工绘制的、规范度较低的在纸张的UML模型大胆地绘制草图，尽可能基于草图进行讨论。
对于局部的、重要性不高的、共享范围较小的UML模型，直接将草图扫描到电脑存档即可；对于全局的、重要性高的、高度共享的，在草图的基础上用CASE工具绘制成为正式的蓝图，并将其纳入统一的模型管理中
2.•业务建模：
以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与
•需求模型：
以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和
资深开发人员参与
•设计模型：
高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发
人员从技术实现方面提供支持。
详细设计模型则以资深开发人员为主，架构师提供指导。
•实现模型：
以资深开发人员（设计人员）为主，架构师提供总体指导。
•数据库模型：
以数据库开发人员为主，架构师提供指导，资深开发人员（设计人员）
予以配合。
三.名词解释
1.用例：
描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员之间就系统的行为所达成的契约。
2.用例驱动：
以用例为抽象角度来观察现实世界，为产生的用例描述出可能的特定场景，并找到实现这些场景的事物、规则和行为。
3.参与者：
系统之外与系统交互的某人或物。
4.业务用例：
对用户的当前业务进行建模，以确定客户和合作伙伴当前是如何开展业务
四.简答题
1.简述参与者与角色、业务工人之间的区别。
2.简述用例之间包含关系与扩展关系的区别。
3.简述业务用例与系统用例区别。
4.简述用例驱动开发分为几个阶段，每个阶段的主要任务是什么。
解答:
1.角色代表了系统中的一类职责，是一个抽象的概念，从众多参与者的职责中抽象相同的
部分，将其命名而形成一个角色系统为参与者服务，业务工人负责完成参与者的业务目标，不需要为之建立业务模型，他们只是在主角的业务模型中出现，缺少了他们，业务模型是不完整的
2.扩展关系的明显特征是，子用例并不总是发生的，或者说子用例的发生是有条件的，只
有在特定条件下才能发生子用例。
如果去掉子用例，我们照样可以得到一个完整的结果包括关系的明显特征是子用例必然发生，没有子用例，基本用例是不完整的。
3.范围不同：
业务用例涉及的范围更大，可能有各种人、部门、各种系统，甚至包含手工操作、讨
论等。
系统用例只涉及我们自己系统与操作人员的交互，对应于业务用例中某些活动步骤，
不包含其他系统及手工操作
用途不同：
业务用例建模是为了明确业务组织是如何运作的。
系统用例是明确各种角色面对计算机系统时，双方各自要做的事和交互反馈，
执行者不同：
业务用例的执行者为外部客户或组织，各种领导或操作人员为内部业务工人
系统用例的执行者为操作人员所代表的岗位角色建模必要性不同
业务用例仅当业务活动复杂、涉及人员多、需要长期深入某个行业时才需要业务建模
系统用例的无论什么时候，都必须建模，以对计算机系统进行面向对象分析
4.从现实世界到业务模型，分析现实世界的用户的业务流程，通过用例的方式表达
从业务模型到系统分析模型（分析类），根据系统的用例，获取界面类，控制类，实体类
从系统分析模型到设计模型，根据界面类、控制类、实体类设计系统的具体类
三.名词解释
1.泛化2.抽象类3.接口污染4.关联关系5.限定关联6.依赖关系7.常量接口8.标识接口9.分析类10.边界类11.控制类12.实体类
解答:
1.也称之为继承，描述了超类与子类之间的关系
2.一种不能被直接实例化的类
3.为接口添加了不必要的职责，程序员被迫实现并维护不必要的方法。
4.是一种结构关系，它指明一个事物的对象与另一个事物的对象间的联系
5.带有限定符的关联
6.一个事物（独立事物）发生变化，会影响到另一个事物（依赖事物）的语义
7.表示静态数据的接口类
8.没有任何方法和属性的接口
9.将系统模型转换成概念模型，适合软件系统理解和实现的类
10.一种用于对系统外部环境与其内部运作之间的交互进行建模的类。
这种交互包括转换事
件，并记录系统表示方式（例如接口）中的变更。
11.控制类用于对一个或几个用例所特有的控制行为进行建模。
12.实体类是用于对必须存储的信息和相关行为建模的类
四.简答题
2.简述继承的优缺点
3.简述抽象类与接口的异同点
4.聚合和关联的区别
5.简述聚合与组合的区别
6.简述关联与依赖的共同点与异同点
7.简述开闭原则的原理、实现方法
8.简述依赖倒置原则的原理
9.简述分析类的作用
解答:
2.优点：
提高了代码复用性。
减少创建类的工作量，每个子类都拥有父类的方法和属性；
子类可以形似父类，但又异于父类。
提高代码的可扩展性。
缺点
降低代码的灵活性，增强了耦合性，设计中的不足很难修改
继承是侵入性的。
只要继承，就必须拥有父类的所有属性和方法。
当父类的常量、变量
和方法被修改时，必需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非
常糟糕的结果——大片的代码需要重构。
层次结构会泄露给客户代码，难以修改
3.抽象类和接口很相似，都定义了抽象操作而推迟了实现部分
代码层次
--接口不允许实现任何方法；接口的属性只能有静态属性常量；类可以继承多个接口；
--抽象类允许实现部分方法；抽象类的属性定义没有任何限制；类只能继承一个父类（抽
象类）
设计层次
--抽象类体现了一种继承关系，父类和派生类之间必须存在“isa”关系，即父类和派
生类在概念本质上应该是相同的。
--接口表现出，实现类实现了interface定义的契约而已，即实现了接口规定的功能，是
一种”likea”关系。
4.与关联关系一样，聚合关系也是通过属性变量来实现这样关系的。
关联关系和聚合关系来语法上是没办法区分的，从语义上才能更好的区分两者的区别。
关联关系所涉及的两个对象是处在同一个层次上的。
聚合关系涉及的两个对象处于不平
等的层次上，一个代表整体，一个代表部分。
5.聚合也称为“has-a”关系，组合也称为“contains-a”关系
聚合表示较弱的整体/部分关系，组合表示较强的整体/部分关系
聚合关系中，代表部分事物的对象可以属于多个聚合对象，具有共享性；而组合关系中
，代表部分事物的对象不可以属于多个聚合对象，不具有共享性
聚合关系中，代表整体事物的对象与代表部分事物的对象，有各自独立的生存期，而组
合关系中，有完全一致的生存期
6.泛化、关联和实现都可以算作是某种依赖关系，只不过它们有比较强的语义和重要的作
用，所以划分出来。
依赖是使用关系，类与类之间表现为临时性
依赖是单向的
代码表现为被依赖类在类中的一个方法中调用
关联是结构化关系，即拥有关系，类与类关系表现为长期性
关联可以是双向的
代码表现为被关联类是类中的一个属性
7.软件实体在扩展性方面应该是开放的，而在更改性方面应该是封闭的
实现开闭原则的关键是
（1）找所有的具体类必须提供的方法的特征作为系统设计的抽象层
（2）找到类中可能变化的部分，将变化的部分封装成对象
实现方法：
（1）面向接口编程
（2）封装变化
（3）组合代替继承
8.依赖关系应该是尽量依赖接口（或抽象类），而不是依赖于具体类
抽象不应该依赖于细节,细节应该依赖于抽象
要针对接口编程，不针对实现编程
9.分析模型是介于原始需求和实现之间的一种过渡模型
分析模型向上映射了原始需求，计算机的可执行代码可以通过分析模型追溯到原始需求;
分析模型向下为计算机实现规定了一种高层次的抽象，这种抽象是一种指导，也是一种
约束，计算机实现过程非常容易遵循这种指导和约束来完成可执行代码的设计工作。
第五章对象图
三.名词解释
1.对象2.匿名对象3.简述类和对象的异同。
4.简述对象图的作用，什么时候可以使用对象图？
解答:
1.代表一个单独的、可确认的物体、单元或实体，它可以是具体的也可以是抽象的，在问
题领域里有确切定义的角色。
2.对象图中对象名不存在的对象元素。
3.对象是一个存在于时间和空间中的具体实体，而类仅代表一个抽象，抽象出对象的“本
质”。
类是共享一个公用结构和一个公共行为对象集合
类是静态的，对象是动态的；类是一般化，对象是个性化；类是定义，对象是实例；类
是抽象、对象是具体
4.作用
对象图展现了多个对象的特征及对象之间的交互
对象图代表了系统某时刻的状态。
使用对象图时机
论证类模型的设计：
当设计了类模型时，举例说明多个对象在某个时刻的交互状态
分析和说明源代码：
由于类图只是展示了程序的静态类结构，因此通过类图看懂代码的
意图是很困难的，通过对象图来分析。
三.名词解释
1.包2.重用等价原则3.共同闭包原则4.共同重用原则5.非循环依赖原则
解答:
1.语义上相关的元素的组合
2.把类放入包中时，应考虑把包作为可重用的单元，有利于开发人员不断升级包，方便包
的各个版本的管理。
3.指把那些需要同时改变的类放在一个包中。
4.指不会一起使用的类不要放在一个包中。
5.指包之间的依赖关系不要形成循环
四.简答题
1.系统建模中为什么要引入包图？
2.简述包图的绘制原则。
3.简述什么是包的构造型，常见的包的构造型有哪些，分别的作用是什么。
4.包的重用等价原则、共同闭包原则、共同重用原则能不能同时满足？
如果不能应该如何灵活应用。
5.包与包之间存在几种关系，分别举例说明。
解答:
1.对基本构造块进行分类
在面向对象软件开发的视角中，类显然是构建整个系统的基本构造块。
但是对于庞大的
应用系统而言，其包含的类将是成百上千，再加上其间“阡陌交纵”的关联关系、多重性等
，必然是大大超出了人们可以处理的复杂度。
这也就是引入了“包”这种分组事物构造块。
高层次把握系统结构
包图是一种维护和描述系统总体结构的模型的重要建模工具，通过对包中各个包以及包
之间关系的描述，展现出系统的模块与模块之间的依赖关系。
2.重用等价原则
指把类放入包中时，应考虑把包作为可重用的单元，有利于开发人员不断升级包，方便
包的各个版本的管理。
共同闭包原则：
共同半包原则是指把那些需要同时改变的类放在一个包中。
共同重用原则：
共同重用原则是指不会一起使用的类不要放在一个包中。
非循环依赖原则：
非循环依赖原则是指包之间的依赖关系不要形成循环
3.用以表示包的语义的说明为包的构造型
常见的包的构造型有
《subsystem》表示汇在建模系统的独立部分
《framework》表示设计模式、，模型的体系结构
《stub》作为代理的包，它服务于某个其他包的公共内容
4.不能。
重用等价原则、共同闭包原则、共同重用原则，3个原则事实上不可能同时满足。
共同闭包原则希望包越大越好。
共同重用原则希望包越小越好。
一般情况下，开发早期，可以以共同闭包原则为主，当系统稳定后，可以对包做一些重
构，以重用等价原则和共同重用原则为主。
5.依赖关系：
一个包依赖于另一个包的代码
模型（Model）
模型用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。
“模型”不依赖“视图”和“控制器”，也就是说，模型不关心它会被如何显示或是如
何被操作。
但是模型中、数据的变化一般会通过一种刷新机制被公布。
为了实现这种机制，
那些用于监视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发
生的改变。
视图（View）
视图层能够实现数据有目的的显示（理论上，这不是必需的）。
在视图中一般没有程序
上的逻辑。
为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应
该事先在被它监视的数据那里注册。
控制层（Controller）
控制层起到不同层面间的组织作用，用于控制应用程序的流程。
它处理事件并作出响应
。
“事件”包括用户的行为和数据模型上的改变
2.该图存在非循环依赖原则
解决方法
3.根据《use》关系，可以发现Client包使用Server包，Server包使用System.Data.SqlCli
ent包，结合其元素，不难得知Client负责Order（订单）的输入，并通过Server来管理用户
的登录（LoggingService）和数据库存储（DataBase），而Server包还将通过.NET的SQLSer
ver访问工具包来实现与数据库的实际交互。
接着再看两个《import》，从包的命名和其所属的元素不难发现Rule负责处理一些规则
，并引用一个具体的窗体（Window），而Client包则通过引用Rule来实现整个窗体和表单的
显示、输入等。
并且还将暂存Order（订单）信息。
最后来看包的泛化关系，GUI有两个具体实现，一个是针对C/S的WindowsGUI，一个是实
现B/S的WebGUI。
第七章交互图
三.名词解释
1.交互
2.交互图
3.消息
解答:
1.在特定语境中，为了实现某一个目标，而在一组对象之间进行交换的一组消息所表示的
行为
2.描述对象之间的关系以及信息传递的图
3.用来描述对象之间所进行的通信的描述，该信息带有对将要发生的活动的期望。
四.简答题
1.简述时序图与通信图的区别。
2.简述UML2.0的四种交互图用途。
3.简述同步消息、异步消息之间的区别。
解答:
1.时序图是一种强调消息时间顺序的交互图，为读者提供了控制流随着时间推移的清晰的
可视化轨迹
通信图它强调的是参加交互的对象的组织，为读者提供了在协作对象结构组织的语境中
观察控制流的一个清晰的可视化轨迹
2.时序图：
时序图是一种强调消息时间顺序的交互图，为读者提供了控制流随着时间推移
的清晰的可视化轨迹
通信图：
强调的是参加交互的对象的组织，为读者提供了在协作对象结构组织的语境中
观察控制流的一个清晰的可视化轨迹
定时图：
采用了一种带数字刻度的时间轴来精确地描述消息的顺序
交互概述图：
是交互图和活动图的混合物
3.同步消息
发送者把消息发送后，等待直到接收者返回信息
异步消息
消息发送后，发送者继续操作，不等待
三.名词解释
1.泳道
解答:
1.把活动图中的活动划分为若干组，并将划分的组指定给对象，这些对象必须履行该组所
包括的活动，它能够明确地表示哪些活动是由哪些对象完成的。
四.简答题
1.简述活动图和交互图的差别
2.简述活动图与程序流程图的差别
3.简述分叉与分支的区别
解答:
1.交互图强调的是对象到对象的控制流，而活动图则强调的是从活动到活动的控制流
活动图是一种表述过程基理、业务过程以及工作流的技术。
它可以用来对业务过程、工
作流建模，也可以对用例实现甚至是程序实现来建模
2.传统的程序流程图描述的是处理的过程，主要控制结构有顺序、分支和循环，各个处理
之间有严格的顺序和时间关系
活动图描述的是对象（或模型元素）的活动的顺序关系所遵循的规则，它着重表现的是
系统的行为，而不是系统的处理过程，在活动图中也没有通常的循环控制结构。
活动图能够
表现并发情形
3.分叉表示的是并发活动的开始
分支表示的是条件，在不同的条件下执行不同的流程
三.名词解释
1.事件驱动
2.状态
3.状态机
4.事件
5.历史状态
解答:
1.根据当前事件,以及对以前事件的响应的结果决定对当前事件的响应的软件对象的动态行
为
2.指在对象的生命周期中的某个条件或者状况，在此期间对象将满足某些条件、执行某些
活动活活等待某些事件。
3.用于描述一个对象在其生存期间的动态行为，表现为对象响应事件所经历的状态序列以
及伴随的动作。
4.是对一个时间和空间上占有一定位置的有意义的事情的规格说明。
5.历史状态是一种伪状态。
可以存储腿出组合状态时所处的子状态，则返回组合状态时可
以直接回到相应的子状态。
四.简答题
1.状态图与交互图的区别
2.状态图与活动图的区别
3.什么是历史状态，为什么需要历史状态，举例说明。
4.状态转换分为几种类型，各代表什么含义。
解答:
1.交互图不显示对象所有可能的动态行为，只显示特定交互（一个具体用例）中对象的行为
。
状态图可以显示对象所有的动态行为
2.状态图只建模一个对象的行为，活动图可以建模多个对象的活动
活动图允许建模特定活动中的对象的某个状态
3.历史状态是一种伪状态。
可以存储腿出组合状态时所处的子状态，则返回组合状态时可
以直接回到相应的子状态。
用户有时需要保存一种历史操作的记录，当返回时并不从初始状态开始执行，而是从历
史中断处执行，这时就需要历史状态。
比如用户听评书，用户因为某事退出播放，而再次播
放评书时，用户的默认希望从历史中断处继续播放。
4.进入和退出转换：
当进入一个状态时，执行某个动作；
内部转换：
用来处理一些不离开该状态的事件
外部转换：
对外部事件做出响应，引起状态变化，并执行一系列运作
三.名词解释
1.构件
2.执行构件
3.实施构件
解答:
1.系统的一类模块，隐藏了细节，并且可以被其它实现了该功能的模块替换。
2.可以
升级会员 