《UML系统分析与设计》复习纲要
第1章 面向对象技术概述
复习题
1-1. 领域模型又称为（ ）
A. 用例模型 B. 概念模型 C. 分析模型 D. 设计模型
1-2. ( )是面向对象方法中用来描述“对客户隐藏对象的属性和实现细节”的概念。
A. 封装 B. 继承 C. 多态 D. 抽象
1-3. 使得在多个类中能够定义同一个操作或属性名，并在每一个类中有不同的实现的一种方法是( )。
A. 继承 B. 多态 C. 约束 D. 接口
1-4. ( )是指同一操作作用于不同的对象可以有不同的解释，产生不同的执行结果。
A. 继承 B. 多态 C. 封装 D. 泛化
1-5. 已知f1和f2是同一个类的两个成员函数，但f1不能调用f2，说明( )。
A. f1和f2都是静态成员函数 B. f1是静态成员函数，f2不是静态成员函数
C. f1不是静态成员函数，f2是静态成员函数 D. f1和f2都不是静态成员函数
1-6 判断( ) ：面向对象方法中对象是从客观世界中抽象出来的一个集合体。
1-7. 判断( ) ：类是面向对象程序中的构造单位，也是面向对象程序语言的基本成分。
第2章 统一建模语言UML概述
复习题
2-1. UML的全称是 ( )
A. Unify Modeling Language B. Unified Modeling Language
C. Unified Modem Language D. Unified Making Language
2-2. 在UML中表示一般事物与特殊事物之间的关系是( )。
A. 关联关系 B. 泛化关系 C. 依赖关系 D．实现关系
2-3. 我们可以使用UML中的( )来描述图书馆与书的关系。
A. 关联关系 B. 泛化关系 C. 依赖关系 D．实现关系
2-4. UML使用( )来描述接口和实现接口的类之问的父系。
A. 关联关系 B. 泛化关系 C. 依赖关系 D．实现关系
2-5. 下列选项中不属于UML的扩展机制的是( )。
A. 约束 B. 构造型 C. 注解 D. 标记值
2-6. UML的软件以( )为中心，以系统体系结构为主线，采用循环、迭代、渐增的方式进行开发。
A. 用例 B．对象 C．类 D.程序
2-7．UML的( )模型图由类图、对象图、包图、组件图和部署图组成。
A．用例 B. 静态 C．动态 D.系统
2-8 . UML的( )模型图由活动图、顺序图、状态图和协作图组成。
A. 用例 B. 静态 C．动态 D．系统
2-9．UML的最终产物就是最后提交的可执行的软件系统和( )。
A. 用户手册 B. 类图 C. 动态图 D.相应的软件文档资料
2-10. 在UML的需求分析建模中，( )模型图必须与用户反复交流并加以确认。
A．配置 B．用例 C. 包 D. 动态
2-11. 判断( ) ：构造块就是UML中的事物。
2-12. 判断( ) ：UML中的行为事物通常用来描述模型的动态部分。
2-13. 判断( ) ：所有的UML图都不依赖于元素符号的大小和位置。
2-14. 判断( ) ：UML的用户可以随意对UML进行任意形式的扩展。
2-15. 判断( ) ：UML中的约束使用大括号中的文本来表示。
第3章 用例图
要求掌握内容
1. 参与者(Actor)：
是指系统以外的--需要使用系统或与系统交互的东西--包括人-设备-外部系统等。
参与者这个概念更确切的术语应该是角色(role)--参与者是他们相对系统而言(与系统交互时)所扮演的角色(而非特定的人或事物--实际上是版型化的类)。
版型：既构造型(Stereotype) – 必须从UML中已有的基本构造块上派生 - 解决特定问题(在已有的元素上增加新的语义但没有增加新的语法) - 这就是UML的扩展机制 P38。
例如：参与者是类的构造型 -- 接口是类的构造型 -- 子系统是包的构造型
2. 参与者之间的关系：
泛化(generalization)关系：一般事物(称为超类或父类)和该事物的较为特殊的种类之间的(分类)关系-子类继承(共享)父类的特性(特别是属性和操作)-也可以用自己特性 P36。
3. 参与者和用例之间的关联关系：
关联(association)关系：是一种结构关系--说明一个事物的实例与另一个事物的实例间的(通信)联系(P36) -- 参与者和用例之间的关联关系-表明了哪个参与者与用例通信。
4. 用例的概念：
(1)用例由一组用例实例(场景)组成-在商场购物“付款”的用例中-一个是使用现会成功付款的场景-一个是由于银行卡付款被拒绝造成的付款失败场景。
(2)用例从使用系统的角度描述系统--即站在系统外部察看系统功能-而不考虑系统内部对该功能的具体实现。
(3)用例的执行结果对参与者来说是有意义的--登录系统是一个有效的用例--但输入密码却不是--因为登录系统对参与者有价值--这样他可以获得身份认证和授权。
(4)用例是对系统行为的动态描述-属于动态建模部分--不存在没有参与者的用例用例不是全部的系统需求--只是功能性的需求。
5. 用例之间的关系：
(1)泛化关系：泛化(Generalization)代表一般与特殊的关系，与继承关系类似。在泛化关系中，子用例继承了父用例的行为和含义，也可以增加新的行为和含义，或覆盖父用例中的行为和含义。当发现系统中有两个或多个用例在行为、结构和目的方面存在共性时，就可以使用泛化关系。这时，可以用一个新的(通常也是抽象的)用例(父用例)来描述这些共有部分。
(2)包含关系：一个用例(基本用例)的行为包含(Include)了另一个用例(包含用例) 的行为。包含关系是依赖关系的版型--也就是说包含关系是比较特殊的依赖关系--它们比一般的依赖关系多了一些语义。当发现系统中有两个或多个用例有某些相同的动作--就可以这些相同的动作提取出来--单独构成一个用例(包含用例)--基本用例仅仅依赖包含用例执行的结果--而不依赖包含用例执行的内部结构。
(3)扩展关系：一个用例(基本用例)的行为包含了另一个用例(扩展用例)的行为。扩展(Extend)关系也是依赖关系的版型。相对于包含关系，扩展用例(Extension Use Case)有更多的规则限制，即基本用例必须申明若干“扩展点” (Extension Point)，而扩展用例只能在这些扩展点上增加新的行为和含义。
在基本用例的每一次执行时，包含用例都一定会执行，而扩展用例只是偶尔被执行。
6. 用例描述：
没有描述的用例就像一本书的目录--人们只知道该该目录标题--但并不知道该目录的具体内容是什么；系统所要执行的一系列动作序列(事件流)是用例描述(Use Case Specification)主要内容。
复习题：
3-1. 下面不是用例之间主要关系的是( )。
A. 扩展 B. 包含 C. 依赖 D. 泛化
3-2. 某ATM自动取款机系统中--"查询余额"和"取现"两个用例都需要检查用户的验证码是否正确--为此定义一个通用的用例叫"核查验证码" --那么用例"查询余额"和"取现"与用例"核查验证码"之间是( )。
A. 包含关系 B. 扩展关系 C. 泛化关系 D. 关联关系
3-3. 下列对系统边界的描述中不正确的是( )。
A. 系统边界是指系统与系统之间的界限
B. 用例图中的系统边界用来表示正在建模系统的边界
C. 边界内表示系统的组成部分--边界外表示系统外部
D. 可以使用Rose绘制用例图中的系统边界
3-4. 在进行网上商店的用例绘制时，( )是不适合的用例。
A. 打开页面 B.购买商品 C. 管理订单 D. 搜索商品
3-5. 判断( )：用例图中的参与者可能对应于现实世界中的人，也可能是其他与系统有交互的事物。
3-6. 判断( )：在用例图中，用例必须有相应的参与者来发起或执行。
3-7. 判断( )：在绘制用例图时，其中用例的粒度越细越好。
3-8. 判断( )：用例的包含关系与扩展关系在表示法上相似，都是将虚线箭头从基用例指向包含用例（扩展用例）。
3-9. 判断( )：用例描述中的前置条件与后置条件分别指的是用例执行前和执行后系统与参与者所处的状态。
第4章 类图与对象图
要求掌握内容
1. 类的属性
[可见性] 属性名 [:类型] ['['多重性 [次序] ']'] [=初始值] [{ 特性}]
可见性：Java也叫访问控制 属性名：personNumber
类型：基本数据类型或用户自定义类型(类)
多重性：如1..*表示该属性值有一个或多个，还可以是有序的(用ordered指明)
约束特性：changeable(可变的)； addOnly(只可加)； Frozen(冻结的)；
作用域：具有类作用域的属性 -- Java的静态变量或类变量
具有对象作用域的属性 -- 非静态变量或实例变量
2. 类的操作
[可见性] 操作名 [(参数列表)] [:返回类型] [{ 约束特性}]
操作名：setValue 约束特性：文字串(说明操作的一些有关信息)
操作接口：操作名、参数列表和返回类型组成操作接口
操作的实现：操作的具体实现叫方法
类的职责：属性和操作(形式化描述) -- 职责(非形式化描述)
3. 类之间的关系
(1)关联关系：关联(Association)关系是类与类之间最常用的一种关系 -- 是一种结构化关系 -- 用于表示一类对象与另一类对象之间有联系 -- 如汽车和轮胎、班级和学生等等用Java等实现关联关系时通常将一个类的对象作为另一个类的成员变量
●双向关联; ●单向关联; ●自关联; ●多重性关联; ●聚合关系; ●组合关系
(2)依赖关系：依赖(Dependency)关系是一种使用关系--大多数情况下--依赖关系体现在某个类的方法使用另一个类的对象作为参数 -- 驾驶员开车--在Driver类的drive( )方法中将Car类型的对象car作为一个参数传递 -- 以便在drive( )方法中能够调用car的move( )方法--且驾驶员的drive( )方法依赖车的move( )方法--因此类Driver依赖类Car
(3)泛化关系：泛化(Generalization)关系也就是继承关系 -- 用于描述父类与子类之间的关系--父类又称作基类或超类--子类又称作派生类
4. 类版型
实体类：保存需要放进持久存储体(数据库-文件等)的信息--通常实体类在数据库中有 相应的表(实体的属性对应表的字段) -- 但不一定一一对应
边界类：位于系统与外界的交界处-它是系统内的对象和系统外的参与者的联系媒介 窗体-对话框-报表-表示通讯协议-直接与外部设备(如打印机和扫描仪)交互 的类-直接与外部系统交互的类等都是边界类的例子
控制类：协调边界类和实体类之间的交互--如果用例逻辑比较简单可以不用控制类而 直接利用边界类来操作实体类实现业务逻辑
引入边界类-控制类-实体类的概念-有助于分析人员和设计人员确定系统中的类；一般按下面的BEC模式进行分析和设计。
BEC模式：将对象分为三类--边界对象-控制对象-实体对象
●参与者只能与边界对象互动 ●每个用例可以对应生成一个控制类
●实体对象一般不能发送消息给边界对象和控制对象(返回消息除外)
5. 类图
类及其关系--构成类图--描述的是类和类之间的静态关系；在软件开发的不同阶段使用的类图具有不同的抽象层次。
领域模型--从面向对象的视角看待现实世界--主要工作是找出相关类--然后明确它们的关系--必要时加入一些多重性描述和业务规则--不涉及具体语言
分析模型--从领域模型将得到实体类--对软件系统进行分析--可以得到边界类；描述的是软件的接口--不是软件的实现--最利于开发者使用和交流的类图
设计模型--加入了抽象类--接口等设计元素--加入了设计模式等--描述了类的实现细节-可以直接映射到可执行代码--因此--涉及具体语言和设计模式等
6. 对象图
表示一组对象及它们之间的联系--是系统的详细状态在某一时刻的快照；常用于表示复杂的类图的一个实例；
对象是类的实例--对象之间的链是类之间的关联的实例--因此--对象图实质上是具有关联关系的类图的实例。
复习题
4-1. 下面那个类图的表示是错误的（ ）
4-2. 在类图中,“ #”表示的可见性是( )
A. public B. protected C. private D. package
4-3. 在UML中, 多重性用来描述类属性或类之间关联关系的一种约束。下面哪种表示方法不是其中之一( )
A. 0..1 B. 0..* C. 1..* D. *..*
4-4. 类和对象都有属性，它们的差别是：类描述了属性的类型，而对象的属性必须有( )。
A. 正负号 B. 动作 C. 具体值 D. 私有成员
4-5. 汽车(Car)由轮子、发动机、油箱、座椅、方向盘等组成。那么Car类和其他类(Wheel、
Engin、Tank、Chair、SteeringWheel)之间的关系是( )。
A. 关联关系 B. 泛化关系 C．实现关系 D．依赖关系
4-6. 在下列选项中不属于分析类的是( )。
A. 实体类 B. 主类 C. 边界类 D. 控制类
4-7. 判断( )：类图主要通过系统中的类及类之问的关系来描述系统的动态结构。
4-8. 判断( )：任何一个类都必须具有一定数量的属性与操作。
4-9. 判断( )：接口与抽象类的概念是完全相同的。
4-10. 判断( )：假设班级类(Class)与学生类(Student)之问建立了关联关系，并且约定一个班级至少拥有一个学生，每个学生只能属于一个班级，则关联关系的班级类一端的多重性应设为1..*。
4-11. ( )主要职责是存储和管理系统内部的信息，它也可以有行为，甚至很复杂的行为。
A. 边界类 B. 控制类 C．抽象类 D．实体类
4-12. 对于场景：一个公司(Company)负责多个项目，每个项目(Project)由至少有一个以上员工(Employee)的团队(Team)来开发。下面UML概念图中，( )最适合描述这一场景。
4-13. 根据下面的陈述画出类图。
1)学生包括本科生-研究生两种；2)研究生的一部分利用课余时间担任助教；3)教师包括助教-讲师和教授三种； 4)一名助教可以为一位讲师或一位教授助课，一位讲师只能有一名助教 一位教授可以有5名助教。
4-14. 将以下类图用Java语言实现。
4-15. 根据以下Java代码画出类图。
第5章 顺序图与协作图
要求掌握内容
1．几个重要的概念
2．顺序图(sequence diagram)和协作图(collaboration diagram)
3．主要消息
调用消息(procedure call)：简单地说，表示调用某个对象的一个操作(通常格式为对象.成员方法)。可以是对象之间的调用，也可以是对象本身的调用(自身调用)。调用是同步机制，也就是说对象A调用对象B时，A发送完消息后会等待B执行完所调用的方法之后再继续执行。
异步消息(asynchronous)：表示发送者通过消息把信号传递给接收者，然后继续自己的活动，不等待接收者返回消息或控制。
返回消息(return)：被调用对象向调用者返回一个值(有值必须明确表示否则可不画)
复习题
5-1. UML顺序图将交互关系表现成一张二维图，其中纵向是( )，横向是( ) 。
A. 时间,对象 B.交互,消息 C.时间,消息 D.交互,泛化
5-2. UML顺序图的一个对象被命名为“:B”，该对象名的含义是( )。
A. 一个属于类B的对象B B.一个属于类B的匿名对象
C.一个所属类不明的对象B D. 非法对象名
5-3. 顺序图和协作图建立了UML面向对象开发过程的对象动态( )模型。
A. 交互 B. 状态 C. 体系结构 D. 软件复用
5-4. 协作图用来连接对象与对象的元素是( )。
A. 关联关系 B. 链 C. 生命线 D. 消息
5-5. 在开始编写代码时，交互图可以用来提供的信息是( )。
A. 消息发送的顺序 B. 在什么条件下消息将被发送
C. 一个对象下不同状态之间的转移 D. 类之间的关联的多重性信息
5-6. 判断( )：顺序图从时间顺序上显示了交互过程中信息的交换。
5-7. 判断( )：顺序图中的对象可以在交互开始时已经存在，也可以在交互过程中才被创建。
5-8. 判断( )：在顺序图中，对象的生命线一定会贯穿整个交互过程。
5-9. 判断( )：激活表示在这一时间段内对象正在完成某项任务。
5-10. 判断( )：在顺序图中，如果一个对象在接收到消息时还没有被激活，那么这条消息将会激活这个对象。
5-11. 判断( )：顺序图虽然能表示消息发送的事件顺序，却无法量化地表示出消息发送的具体时间。
5-12. 判断( )：协作图的主要组成元素包括对象、链、生命线和消息。
5-13. 判断( )：协作图中应该表示出交互发生的时刻系统中存在的所有对象。
5-14. 判断( )：与关联关系相似，UML也允许对象自身与自身之问建立一条链。
5-15. 判断( )：就语义和语法而言，协作图中的消息与顺序图中的消息完全相同。
5-16. 下图中( )分别表示一条同步消息和一条异步消息。
A. 1和2 B. 3和5 C. 5和6 D. 6和7
5-17. 根据下面描述画出顺序图：Student(李明)首先通过WebInterface(登录页面)进行登录--WebInterface需要通过DataManager(数据管理)获得用户Student(李明)的验证信息--成功验证以后-- Student(李明)通过WebInterface(登录页而)向DataManager(数据管理)获取自己的信息进行显示。
5-18. 订票管理系统的类图和顺序图下图。根据类图，分析顺序图中缺少的类名是什么？
6章 状态图与活动图
要求掌握内容
1. 几个重要的概念
2．状态图(statechart diagram)：UML2.0后称为状态机图；核心元素：状态和转移
3．状态：状态是指-在对象生命周期中的-某个状况(手机)或条件(贷记卡)
4．转移
5. 包含复杂转移(转换)的状态图
6. 包含组合状态(复合状态)的状态图
7. 活动图
8. 泳道
9. 对象流
复习题
6-1. 状态图描述一个对象在不同的( )驱动下发生的状态转移。
A. 事件 B.对象 C.执行者 D.数据
6-2. 假设一个转换被表示为“A[B]/C”，其表达的语义是( )。
A. 触发事件为B，监护条件(警戒条件)为A，效果列表(动作)为C
B. 触发事件为A，监护条件(警戒条件)为B，效果列表(动作)为C
C. 触发事件为C，监护条件(警戒条件)为A，效果列表(动作)为B
D. 触发事件为A，监护条件(警戒条件)为C，效果列表(动作)为B
6-3. 需要依赖某个表达式的布尔条件才能发生的事件被称为( )。
A. 信号事件 B. 调用事件 C. 改变事件 D. 时间事件
6-4. 反应型对象建模一般使用( )。
A. 状态图 B. 顺序图 C. 活动图 D. 类图
6-5. 组合状态(复合状态)的多个子状态之间是互斥的，不能同时存在，那么这种状态称之为( )复合状态。
A. 顺序 B.并发 C.历史 D.同步
6-6. 假设某个状态的内部的一行内容为“eventA/defer”，其表达的语义是( )。
A. 触发器 B. 内部转移 C. 内部执行活动 D.可延迟事件
6-7. 将一个活动图中的活动状态进行分组，每一组表示一个特定的类、人或部门，他们负责完成组内的活动。这种技术是( )
A. 泳道 B. 分叉汇合 C. 分支 D. 转移
6-8. 在活动图中用于将判断节点产生的多个控制流合并并导出为一个控制流的元素是( )。
A. 分叉节点 B.结合节点 C. 判断节点 D.合并节点
6-9. 为了描述和理解系统中的控制机制(不是顺序执行的控制逻辑)，如为了描述一个设备控制器在不同情况(状态)下所要完成的动作，下面几个图中哪个图是最有用的?( )。
A. 交互图 B. 活动图 C. 状态图 D. 类图
6-10. 如果要对一个企业中的工作流程建模，那么下面4个图中哪个图是最有用 的?( )。
A. 状态图 B. 顺序图 C. 活动图 D. 类图
6-11. 判断( )：在状态图中，转移就是对象在两种状态之间的时空下发生的有意义的事情。
6-12. 判断( )：一个状态图中只能有一个初态。
6-13. 判断( )：内部转移就是某个状态转换到自身的过程。
6-14. 判断( )：可延迟事件表示这一事件如果无法立即执行，则会被延迟执行。
6-15. 判断( )：如果一个非内部的转移没有触发器，则该转移会在其内部活动执行完毕后触发。
6-16. 判断( )：当顺序复合状态被激活时，同一时间只有一个子状态会被激活。
6-17. 判断( )：活动本身是一个原子操作，是不可被中断的。
6-18. 判断( )：活动图中必须有且只能有一个开始标记。
6-19. 判断( )：活动图的控制流与状态图中的转换是语义完全相同的元素。
6-20. 判断( )：泳道按活动发生的时间将活动图划分为几部分。
6-21. 根据C程序绘制fib函数的活动图。
6-22. 当线程准备运行时-进入就绪状态-如果获得cpu时间片-转入运行状态-运行正常结束-进入结束状态-如果在运行过程中-cpu时间片用完后还没有完成任务-进入就绪状态-等待再次得到cpu时间片-如果线程在运行过程中-不满足所需资源-就进入阻塞状态-处于阻塞状态的线程得到相关资源后-进入就绪状态-依次循环。请画出线程对象的状态机图。
第7章 组件图与部署图
要求掌握内容
1. 组件
逻辑设计角度--系统由类及其关系组成；物理实现角度--哪些类需要放在一个组件中；组件对应-组成软件系统的源码文件-目标文件-可执行文件-数据库文件-HTML文件等。
2. 组件图 component diagram
3. 组件的接口
4. 部署图deployment diagram
复习题
7-1. 在组件图中，将系统中可重用的模块封装成可替换的物理单元是( )。
A. 类 B.子系统 C.包 D.组件
7-2. 在下面的UML关系中，最可能出现在组件图中的是( )。
A. 依赖关系 B. 泛化关系 C. 关联关系 D.包含关系
7-3. 某系统部署时需要一台LED显示屏，其在部署图中应该被建模为( )类型
的结点。
A. 设备 B.处理器 C.两者皆可 D.都不适用
7-4. 部署图实质是( )。
A. 部署软件组件 B.部署软件程序 C.部署软件模型 D.部署软件制品
7-5. 判断( )：组件是一个封装完好的物理实现单元，与外部完全分离。
7-6. 判断( )：组件比类的抽象层次要高，类应该从属于某个组件。
7-7. 判断( )：组件是系统工作产品的一部分，因此exe文件是一个组件，而程序的源文件不是。
7-8. 判断( )：部署图中结点之间的关联关系，可以对其应用构造型来表示不同类型的通信路径或通信的实现方式。
7-9. 判断( )：如果所开发的软件只运行在一台机器上且所有与机器交互的设备都已经由操作系连接，这类软件就不必设计部署图。
第8章 包 图
要求掌握内容
UML中的包：对模型元素进行组织管理(UML中的包有意表现为一个文件夹的样式-就是表示模型元素按文件夹管理的形式进行管理)。
包名：AWT 元素：类-接口… 可见性：+ # -
包名的层次性：包可以有子包
如果在“数据操作”这个包中有元素Student类
那么Student类的完整名称就是：
数据访问层::数据操作::Student
类似于Java的表示：数据访问层.数据操作. Student
因为包中包含了模型元素(例如最重要的模型元素是类)--而模型元素之间存在着关系--因此--折射出包之间也存在相同的关系包之间的关系主要有--依赖关系--泛化关系(很少用到)。
在考虑如何对类进行分组并放入不同的包时--主要是根据类之间的依赖关系和泛化关系进行分组--同时考虑重用等价原则(考虑把包作为可重用的单元)--共同闭包原则(需要同时改变的类放在一个包中--体现了体现高内聚低耦合)--共同重用原则(不会一起使用的类不放在同一包中)--非循环依赖原则(包之间的依赖关系不要形成循环--这样每个包都无法独立)。
其实这些原则比较高大上，很难同时满足。比较实际的分包原则是：元素不能“狡兔三窟”；相同包内不能重名；包内元素紧密联系(高内聚) ；包和包尽可能独立(低耦合)。实际上主要基于顺序图和协作图来分包。
复习题
8-1. 什么是模型的组织结构？其作用是什么？
8-2. 在UML的建模机制中，模型的组织一般通过( )来实现。
A. 用例 B. 数据库 C. 包 D. 注释
8-3. 下列选项中，不能直接放在包中的元素是( )。
A. 类 B. 操作 C. 包 D. 对象图
8-4. 在下列选项中，包元素之间可能形成的关系是( )。
A. 关联关系 B. 依籁关系 C. 实观关系 D. 扩展关系
8-5. 假设有两个包A与B，其中B包依赖于A包，且两者之间不构成任何嵌套关系。此外，A包中含有3个类元素：①ClassA，可见性修饰为public；②ClassB，可见性修饰为protected； ③ClassC，可见性修饰为private。那么在B包中可见的元素有( )。
A. ① B. ①② C. ①②③ D. ②
8-6. 判断
(1) 包的路径名使用前缀来表示出上层包的名称。 ( )
(2) UML中的所有模型元素都可以被直接包含在包中。 ( )
(3) UML中的每个元素只能被包含在一个包中。 ( )
第10章 软件设计模式及应用
要求掌握内容
1. 设计模式概述
设计模式(pattern)是从许多优秀的软件系统中总结出的成功的可复用的设计方案--每一个设计模式描述一个在我们周围不断重复发生的问题以及该问题的解决方案的核心--这样你就能一次一次地使用该方案而不必做重复劳动.
2. 设计模式遵循的原则
开-闭原则(Open-Closed Principle,OCP)--对扩展开放-而对修改关闭
里氏替换原则(Liskov Substitution Principle,LSP)：如何正确地进行继承的设计
依赖倒转原则(DIP)：针对接口编程-不要针对实现编程 -- 核心是解耦
接口隔离原则(Interface Segregation Principle,ISP)：减少接口“污染”和“臃肿”
组合/聚合复用原则(Composite/Aggregate Reuse Principle,CARP)：尽量使用组合/ 聚合--尽量不要使用继承
迪米特法则(Law of Demeter,LoD)：一个对象应该对其他对象有尽可能少的了解
单一职责原则(Simple Responsibility Principle,SRP)：一要避免相同的职责分散 到不同的类中 -- 二要避免一个类承担太多的职责
这些原则 -- 是指导性的 -- 而不是法律规定；这些原则 -- 很多在概念上有交叉 -- 很多设计模式也一样；甚至你很难判断一段代码属于哪一种设计模式(可能有多种模式的影子)；目的只有两个：一是功能要实现，二是维护和扩展，做好了就是成功的。
3. 简单工厂模式Simple Factory
简单工厂模式是类的创建模式；由一个工厂类根据传入的参数决定创建出哪一种产品类的实例；该模式比较简单-核心是工厂类-这个类含有必要的判断逻辑-可以决定在什么时候创建哪一个产品类的实例--增加新的产品时必然要修改工厂类-只有一个具体工厂--一旦它本身不能正常工作了-整个程序都会受到影响。
4. 工厂方法模式Factory Method
允许多个具体工厂类从抽象工厂类继承而来--多个简单工厂模式的集合；简单工厂模式是由工厂方法模式退化而来。
5. 适配器模式Adapter
将一个类的接口转换成客户希望的另外一个类的接口--也叫包装器(Wrapper)；使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
6. 策略模式Strategy
针对一组算法，将每一个算法封装到具有共同接口的独立类中，从而可以使得它们可以相互替换。这种封装算法就成为一个策略。
7. 状态模式State
允许一个对象在其内部状态变化时改变它的行为。
策略模式与状态模式极其相似，但是二者有其内在的差别，策略模式将具体策略类暴露出去，调用者需要具体明白每个策略的不同之处以便正确使用。而状态模式状态的改变是由其内部条件来改变的，与外界无关，二者在思想上有本质区别。
复习题
10-1. 以下关于设计模式的描述中，不正确的是( )。
A．使用设计模式的主要目的是复用成功的设计和体系结构
B．设计模式具有适应需求变化的优点 C．设计模式可以改善代码的平台可移植性
D．设计模式可以减少方案出错的可能性
10-2 下面有关面向对象方面的描述，不正确的是( )。
A. 面向对象要求针对接口编程，而不是针对实现编程 B. 接口和实现不可分割
C. 设计职责单一的类 D. 尽量使用已有的类库
10-3. ( )使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
A. Adapter(适配器) B. Factory Method(工厂方法)
C. Abstract Factory(抽象工厂) D. Strategy (策略模式)
10-4. ( )定义一系列算法，把它们一个个封装起来，并且使它们可相互替换。
A. Adapter(适配器) B. Factory Method(工厂方法)
C. Abstract Factory(抽象工厂) D. Strategy (策略模式)
10-5. 适配器设计模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。下图为该设计模式的类图，其中，( )实现了目标接口并包含被适配者的引用。
A. Client B. Target C. Adapter D. Adaptee
10-6. 策略设计模式定义一系列算法，把它们一个个封装起来，并且使它们可相互替换。下图为该设计模式的类图，其中，( )定义若干个算法标识，即定义了若干个抽象方法。
A. Context B. Strategy C. ConcreteStrategyA D. ConcreteStrategyB
附参考答案：
第1章 面向对象技术概述
1-1. B 1-2. A 1-3. A 1-4. B 1-6. √ 1-7. √
1-5. B (提示：虽然fl和f2都是同一个类的成员函数，但fl不能调用f2，如果都是普通成员函数，那么肯定是可以调用；如果它们都是静态成员函数，也可以调用；如果fl是静态成员函数，而f2不是的话，那么这种情况下，fl不能调用f2；如果fl不是静态成员函数，而f2是的话，那么这种情况下，fl也能调用f2。)
第2章 统一建模语言UML概述
2-1. B 2-2. B 2-3. A 2-4. D 2-5. C 2-6. A 2-7. B 2-8. C 2-9. D 2-10. B
2-11. × 2-12. √ 2-13. × 2-14. × 2-15. √
第3章 用例图
3-1. C 3-2. A 3-3. D 3-4. A 3-5. √ 3-6. √ 3-7. × 3-8. × 3-9. √
第4章 类图与对象图
4-1. D 4-2. B 4-3. D 4-4.C 4-5.A 4-6.B 4-7. × 4-8. × 4-9. × 4-10. ×
4-11. D (提示：边界类描述的是系统外部环境和系统内部运作之问的交互，它工作在参与者和系统之间；实体类的主要职责是存储和管理系统内部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关，实体类独立于系统外部环境( Actor)；控制类描述的是特定用例的控制行为，与特定的用例实现密切相关，可以说它就是在执行用例实现，控制类可以有效地降低边界类和实体类之间的耦合，使系统对于外部环境的变化具有良好的适应性。)
4-12. B (提示：在UML中，关联的多重度足指一个类的实例能够与另一个类的多少个实例相关联。它又称为重复度。本题中不难看出有4个类，而且由描述“一个公司负责多个项目”可知，公司和项目两个类之问的关联是一种一对多的关联，即项目端是多端，这样就可以排除答案C；另外公司和项目之问并不是一种继承的关系，这样就可以排除答案D。而在A和B选项间，它们的区别就在于A的关联牵涉了3个类，但其实这种表达方式是不存在的，而B选项中很好地表明了题目的意思，即一个项目由一个团队来开发，而团队中的成员个数至少是一个，或者是多个。)
第5章 顺序图与协作图
5-1.A 5-2. B 5-3. A 5-4. B 5-5. AB 5-6. √ 5-7. √ 5-8. × (提示：交互过程中某个对象可以销毁) 5-9. √ 5-10. √ 5-11. √(提示：可以用UML2.x新增的时间图描述) 5-12. × 5-13. ×(提示：不参与交互的对象不用画出来) 5-14. √ 5-15. √
5-16. D (提示：如果一个对象发送了一个同步消息，那么它要等待对方对消息的应答，收到应答后才能继续自己的操作。发送异步消息的对象不需要等待对方对消息的应答便可以继续自己的操作。1,2,5,6表示的是同步消息，而3,4表示的是返回消息，7表示的是异步消息。)
第6章 状态图与活动图
6-1. A 6-2. B 6-3. C 6-4.A 6-5. A 6-6. D 6-7. A 6-8. D 6-9. C 6-10. C
6-11. √ 6-12. √ 6-13. × 6-14. √ 6-15. √ 6-16. √ 6-17. × (提示：动作状态是原子的，活动状态是非原子的) 6-18. √ (提示：结束标记可以有多个)
6-19. × (提示：活动图的控制流是自动地顺序执行，状态图中的转换是事件驱动的)
6-20. × (提示：泳道按活动的责任者将活动图划分为几部分)
6-21.
6.22
第7章 组件图与部署图
7-1. D 7-2. A 7-3. A 7-4. D 7-5. × (提示：与外部完全分离是不对的) 7-6. √
7-7. × 7-8. √ 7-9. √
第8章 包 图
8-1. 在开发软件系统的过程中，尤其是对于规模较大的系统而言，如何将系统中众多模型元素组织起来，即如何将一个大系统有效地分解成若干个小的模块并准确描述各个模块之问的关系是一个必须要解决的重要问题。对此，UML使用包元素来实现模型的组织，使用包图来表示出包之间的相互关系。通过这种方式构造的系统就能够从模块的层次上来把握系统的静态结构。包是UML中的万能容器，优秀的设计者用它建立伟大的软件架构，而平庸的设计者把它变成垃圾桶。
8-2. C 8-3. B 提示：低层次的元素不直接体现在包中，而是体现在所属的模型元素中
8-4. B 8-5. A 8-6. (1)√ (2) × (3) √
第10章 软件设计模式及应用
10-1. C 10-2. B (提示：“针对接口编程，而不足针对实现编程”是面向对象设计的7大原则之一，遵循此原则有以下几个方面的好处。(1)使用者不必知道其使用对象的具体所属类； (2)使用者无须知道特定类，只需知道它们所期望的接口；( 3)一个对象可以很容易地被（实现了相同接口的）另一个对象所替换；(4)对象间的连接不必硬绑定到一个具体类的对象上，因此增加了灵活性。另外，在这种方式下，接口与实现是可以分割的，这样利于变化，也符合面向对象的根本意图（便于需求的改变）。设计职责单一的类也是7大设计原则中的一个，因为如果一个类有一个以上的职责，这些职责就耦合在了一起，这会导致脆弱的设计。比如，当一个职责发生变化时，就可能会影响其他的职责。另外，多个职责耦合在一起，也会影响程序的复用性。)
10-3. A 10-4. D 10-5. C 10-6. B
查看24道真题和解析