软件构造与与体系结构习题

第一章

1.下面关于类的描述正确的是？A

A、类是一组相似事物的统称。

B、一个事物可以称为一类。

C、两个完全相同的事物可以称为一类。

D、“奥巴马”和“特朗普”可以统称为“奥巴马”。

解析：

类（重点）
概念：⼀组相似事物的统称。 A对
概念分析
⼀组：多个事物⽽不是单个事物，单个事物不能成⼀类。⽐如：“⼈”可以是⼀类，“我”不是⼀类。B错
因为“我”是⼀个事物。
相似：⽐较像，但不完全相同。“奥巴⻢”和“特朗普”都是“美国总统”，都是“⼈”，他们有很多相似的
地⽅，但他们两个绝对不是完全相同。C错
统称：要能概括多个事物。“奥巴⻢”和“特朗普”可以统称为“⼈”、“男⼈”、“美国总统”，但不可以统
称为“奥巴⻢”。因为“奥巴⻢”是个个体，不能概括多个事物。D错

2.下面关于在面向对象设计时如何划分类的描述正确的是？ B

A、按照事物的相似点进行划分。

B、站在一个角度观察事物，有相似点儿就是一类。

C、面向对象程序语言Java中Object类就可以满足任何编程需求了，没有必要编写其他类。

D、汽车、自行车、火车可以划分为一类。

解析：类的划分

⽅法⼀：根据定义划分。只要有相似点的事物就是⼀类。

例⼦：“我”和“你”是⼀类，因为我们都是“⼈”。“你”和“猪”是⼀类，因为你们都是“动

物”。“你”和“树”是⼀类因为你们都是“⽣物”。

世界物质统⼀性的原理：三个基本观点，世界是统⼀的，世界统⼀于物质，世界的物质统⼀性

是⽆限多样的统⼀。由此可以得出万物归⼀的结论——世界存在⼀个⼤⼀统的类。在JAVA世

界中，Object就是⼀个⼤⼀统的类。

问题：我们能否只⽤⼀个类呢？如果只有⼀个类，显然是⽆法满⾜需求。C错

⽅法⼆：站在某⼀个⻆度观察事物，有相似点⼉就是⼀类。（对第⼀种⽅法的修订，建议）

例⼦：站在观察⼈的⻆度，我和你就是⼀类，猪就不属于这⼀类了。站在观察动物的⻆度，

我、你、猪都是⼀类，但是树不是。站在观察⽣物的⻆度，我、你、猪、树都是⼀类。

D看以什么角度划分，交通工具没问题，驱动方式就不对了。

3.在描述类时，下面那个选项不是描述类的维度？D

A、类的名称

B、类的属性

C、类的方法

D、类的设计原则

解析：类的描述（三个维度：名称、属性、⽅法）

4.选出下面描述不正确的选项？C

A、现实世界中东西都可以称之为现实对象。

B、现实类是对现实对象的归纳和总结。

C、软件类和现实类存在一一对应关系。

D、软件类是软件设计过程中归纳和总结出来的类。

解析：现实对象：现实世界中东⻄都可以称之为现实对象。A

现实类：是对现实对象的归纳和总结。B

软件对象：软件运⾏过程中存在的对象。

软件类：软件设计过程中归纳和总结出来的类。D

软件类与现实类并⾮⼀⼀对应。C

软件类并不⼀定现实存在。

5.下面关于面向对象特征描述不正确的是？ A

A、抽象

B、封装

C、继承

D、多态

解析：⾯向对象的三⼤特征：封装、继承、多态（难点）

6.下面属于项目技术流程的是？ABCD

A、需求模型

B、领域模型

C、设计模型

D、实现模型

解析：项⽬技术流程（重点）

服务的对象：软件开发⼈员。

技术流程：需求模型—>领域模型---->设计模型—>实现模型。注：解决了从⽂字到类的问题。

7.下面描述不正确的是？A

A、5W1H8C就是需要建立的需求模型

B、需求包括三个方面：功能、质量、约束

C、用例可以用于描述需求

D、系统顺序图可用于用例分支的可视化。

解析：需求挖掘——5W1H8C(重点) A

需求⽅⾯：功能： 5W+1H、**质量：**8C、**约束：**不包含在质量属性中的其他约束条件 B

UML中的⽤例图⽤于描述系统、⼦系统或者类相关的呈现给外部⽤户的⾏为。 C

⽤例图不是⽤例的可视化描述。

系统顺序图作⽤：⽤可视化的⽅式描述⽤例的某个分⽀ D

8.下面那个属于领域模型的建立步骤？ ABC

A、找名词

B、加属性

C、连关系

D、找动词

解析：建⽴领域模型的⽅法（重点）：找名词、加属性、连关系

9.下面哪些属于类模型建立过程中所做的事情？ABCD

A、领域类映射

B、精雕细琢应用设计原则和设计模式优化模型

C、照本宣科拆分辅助类

D、分配职责

解析：类模型（静态模型）：1.领域类映射；2.精雕细琢，应⽤设计原则和设计模式；3.照本宣科，拆分辅助类4.分配职责。

10.下面属于通常所说的六大设计原则的选项？ABC

A、单一职责原则

B、开闭原则

C、里氏替换原则

D、高内聚低耦合

解析：六⼤设计原则

Robert C.Martin SOLID原则，⼤作《敏捷软件开发：原则、模式与实践》

SRP（Single Responsibility Principle）：单⼀职责原则 A

OCP（Open/Close Principle）：开闭原则 B

LSP（Liskov Substitution Principle）：⾥⽒替换原则 C

ISP（Interface Segregation Principle）：接⼝隔离原则⼝。

DIP（Dependency Inversion Principle）：依赖反转原则

迪米特法则(Law of Demeter )又叫做最少知识原则，也就是说，一个对象应当对其他对象尽可能少的了解。不和陌生人说话。英文简写为: LoD。

迪米特法则的目的在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。

11.在类模型设计时必须遵守设计原则 错误

解析：Arthur J.Riel《OOD启思录》:你不必严格遵守这些原则，违背它们也不会被处以宗教刑

罚。但你应当把这些原则看作警铃，若违背了其中的⼀条，那么警铃就会响起。

12.设计模式用于指导类的行为设计？正确

13.设计原则用于指导类的定义设计？ 正确

解析：设计原则⽤于指导”类的定义“设计，设计模式⽤于指导”类的⾏为“设计。

14.在设计类的动态模型时必须绘制状态图、活动图、序列图、协作图等。 错误

解析：常⻅的动态模型

状态模型（状态图）：描述对象⽣命周期的状态变化。通过状态图，可以了解到对象有哪些状态、

状态之间如何转换、转换的触发条件。

活动模型（活动图）：描述⼯作流程或计算流程，其关注点是在完成某项⼯作的过程中，系统中的

哪些对象承担了什么样的任务，做了什么处理，以及这些对象之间的先后交互关系。

序列模型（序列图）：描述对象按照时间顺序组织的消息交互过程，其关键特征是强调按照“时间顺

序”来组织对象的交互，所以序列图有时⼜称为“时序图”或“顺序图”。

协作模型（协作图）：描述按照对象之间的关联来组织的消息交互过程，其关键特征是强调按照“对

象关系”来组织对象的交互。

从效率和效果两⽅⾯考虑，不需要⾯⾯俱到，只需要针对⼀些关键的、核⼼的、复杂的业务或者功

能进⾏动态模型设计即可。

动态模型有很多种，每种有不同的适⽤场景，意味着不需要每个业务或功能每种模型都要设计，那

种模型能够将处理过程描述清楚即可

15.模块就是一个方法 错误

解析：模块：在⾯向对象领域中，模块可⼤可⼩，⼤到⼀个⼦系统，⼩到⼀个⽅法。

16.内聚概念中的结合指的是模块内部的元素忠于模块职责的程度 正确

解析：内聚概念：指⼀个模块内部元素彼此结合的紧密程度。

结合=凝聚⼒：在⾯向对象设计中应将“结合”理解为“凝聚⼒”，即模块的元素忠于模块职责的程度。

17.偶然内聚的实践原则是必须放到一个模块。 错误

18.逻辑内聚的实践原则是根据需求看是否要放到一个模块 正确

19.时间内聚的具体实践原则是一般放到同一个模块 正确

20.过程内聚的实践原则是应该尽可能的放到一起 正确

21.信息内聚的实践原则是应该放到一个模块 正确

22.功能内聚的实践原则是必须放到一起 正确

解析：

偶然内聚是指模块内的元素很任性地组合到⼀起，除了“恰好放在⼀个模块内”之外，没有任何关

系。

具体实践：根据需求看是否要放到⼀个模块逻辑内聚

逻辑内聚是指⼀个模块内的元素仅仅因为“逻辑相似”⽽被放到了⼀起——即使这⼏个元素本质上完

全不同。

具体实践：根据需求看是否要放到⼀个模块

时间内聚是指⼀个模块内的多个元素除了要在程序执⾏到同⼀个时间点时做处理之外、没有其它关

系。

具体实践：⼀般放到同⼀个模块。

过程内聚是指⼀个模块内的多个元素之间必须遵循⼀定的执⾏顺序才能完成⼀个完整功能。

具体实践：过程内聚是⼀种⽐较强的内聚，存在过程内聚的⼏个元素应该尽可能地放在⼀个模块内。

信息内聚：模块内部元素之所以被划分在同⼀模块中，是因为这些元素都操作相同的数据。

具体实践：应该放到⼀个模块。

顺序内聚：模块内的多个元素之间存在“⼀个元素的输出是下⼀个元素的输⼊”这种“流⽔线”的关系。

具体实践：必须放到⼀起

功能内聚：模块内所有元素共同完成⼀个功能、缺⼀不可

具体实践：必须放到⼀起，且与模块功能⽆关的元素都应该另谋⾼就

23.内聚由弱到强的顺序是：偶然内聚–>逻辑内聚–> 时间内聚–>过程内聚–>信息内聚–>顺序内聚–>功能内聚 正确

解析：内聚的强弱程度：由低到⾼

偶然内聚–>逻辑内聚–> 时间内聚–>过程内聚–>信息内聚–>顺序内聚–>功能内聚

24.常见的耦合类型包括？ABCDEFGH

A、无耦合

B、消息耦合

C、数据耦合

D、数据结构耦合

E、控制耦合

F、外部耦合

G、全局耦合

H、内容耦合

25.无耦合的实践原则是查看是否有重复代码 正确

26.消息耦合的实践原则是必须修改 错误

27.数据耦合的实践原则是不用修改，做好数据校验 正确

28.数据结构耦合的实践原则是能改则改 正确

29.控制耦合的实践原则是尽量修改，不能修改则做好数据校验 正确

30.外部耦合的实践原则是内部隔离接口代码，并对输入做严格校验 正确

31.全局耦合的实践原则是尽量减少这种耦合 正确

32.内容耦合的实践原则是必须改进 正确

33.高内聚低耦合不仅是做好设计的途径、也是评价设计好坏的标准 正确

解析：耦合分类

**⽆耦合：**模块间没有任何关系或交互。

⽆耦合降低了重⽤其它模块的能⼒。

具体实践：查看是否有重复代码

消息耦合：耦合关系表现在消息传递上。

具体实践：不⽤修改

数据耦合：模块间通过参数传递基本数据。

具体实践：不⽤修改，做好数据校验

数据结构耦合：两个模块通过传递数据结构的⽅式传递数据。

具体实践：能改则改，不能改要注意⼏点：1.参数是否可能被修改 2. 做好数据校验 3. 内存开销、泄露

控制耦合：当⼀个模块可以通过某种⽅式来控制另⼀个模块的⾏为时，称为控制耦合。最常⻅的是通过传递控

具体实践：尽量修改，不能修改则做好数据校验

外部耦合：当两个模块依赖相同的外部数据格式、通信协议、设备接⼝时，称为外部耦合。模块间没有直接的交互，⽽是通过某种约定俗成的“协议”、“格式”、“接⼝”等完成分⼯合作。

具体实践：内部隔离接⼝代码，并对输⼊做严格校验

全局耦合：当两个模块共享相同的全局数据时，称为全局耦合。

具体实践：尽量减少

内容耦合：当⼀个模块依赖另⼀个模块的内部内容时称为内容耦合。很差的⼀种耦合，破坏了模块的封装性。

具体实践：必须改进

34.单一职责原则中的职责不是一件事，而是多件事，但都和职责紧密相关 正确

35.单一职责原则只适合基础类，不适合基于基础类构建的聚合类 正确

36.单一职责原则用于指导高内聚的类设计 正确

解析：SRP原则，Single Responsibility Principle，单⼀职责原则：职责不是⼀件事，⽽是多件事，但都和职责紧密相关。

适⽤范围：SRP只适合基础类，不适合基于基础类构建的聚合类。

⽤于指导⾼内聚的类设计

37.下面关于OCP原则描述正确的是？ ABCD

A、对提供者扩展开放，对使用者修改封闭

B、提供者/使用者：A类调用了B类的方法，那么A就是使用者，B就是提供者

C、新功能不是全新的功能，而是原有功能的替代实现

D、接口不变可以用OCP，接口改变则不能用OCP

解析：OCP原则，Open-Closed Principle，开闭原则

概念理解：对提供者扩展开放，对使⽤者修改封闭 A

提供者/使⽤者：A类调⽤了B类的⽅法，那么A就是使⽤者，B就是提供者。 B

通俗地讲，就是提供者扩展了新的功能，使⽤者不需要修改代码。

注意：新功能不是全新的功能，⽽是原有功能的替代实现。这也是“extension”所隐含的意思。

适⽤范围 C

接⼝不变：接⼝包括函数名、函数参数、函数返回值，可以应⽤OCP

接⼝改变：已有函数修改名称、参数、返回值，或者增加了新的函数，OCP不再适⽤。 D

38.OCP可以用于指导高可扩展类的设计 正确

OCP虽然针对类的设计⽽提出的原则，但其思想可以应⽤到系统和系统、⼦系统和⼦系统、模块和

模块之间。不同的地⽅都应⽤同⼀个原则：接⼝交互。例：类之间通过接⼝交互；模块或⼦系统之

间通过规定好的协议交互，不管是私有的还是公开的例如HTTP、SOAP等

应⽤场景：总的指导思想，在⾯向对象设计中，如果能够符合LSP/ISP/DIP原则，⼀般情况下就能够符合OCP

原则。

⽤于指导⾼可扩展类的设计

OCP可⽤于指导系统架构设计。

39.下面关于里氏替换原则的描述正确的是？ ABCD

A、子类必须实现或继承父类所有的公有方法，否则调用者调用了一个父类中有，而子类中没有的方法，运行时就会出错

B、类每个方法的输入参数必须和父类一样，否则调用父类的代码不能调用子类

C、子类每个方法的输出（返回值、修改全局变量、插入数据库、发送网络数据库）必须不比父类少，否则基于父类的输出做的处理就没法完成

D、指导类继承的设计

解析：LSP原则，Liskov Substitution Principle，⾥⽒替换原则

概念理解：Liskov⼥性计算机科学家，2008年图灵奖获得者，1987年提出的LSP原则。

Liskov的解释：⼦类的对象提供了⽗类的所有⾏为，且加上了⼦类额外的⼀些东⻄（⽅法或属性）

程序基于⽗类实现时，如果将⼦类替换⽗类⽽程序不需要修改，则符合LSP原则

Robert. C. Martin的解释：使⽤指向⽗类的指针或引⽤时，必须能够在不知道⼦类类型的情况下使⽤⼦类的对象。（1996年的解释）⼦类必须能替换成它们的⽗类。（2002年的解释）

具体实践：⼦类必须实现或继承⽗类所有的公有⽅法，否则调⽤者调⽤了⼀个⽗类中有，⽽⼦类中没有的⽅

法，运⾏时就会出错。 A

⼦类每个⽅法的输⼊参数必须和⽗类⼀样，否则调⽤⽗类的代码不能调⽤⼦类 B

⼦类每个⽅法的输出（返回值、修改全局变量、插⼊数据库、发送⽹络数据库）必须不⽐⽗类少，

否则基于⽗类的输出做的处理就没法完成。 C

应⽤场景:指导类继承的设计。 D

40.下面关于ISP原则描述正确的是？ ABCD

A、不应该强行要求客户端依赖于它们不用的接口

B、类之间的依赖应该建立在最小的接口上面

C、ISP原则承认对象需要非内聚接口，然而ISP原则建议客户端不需要知道整个类，只需要知道具有内聚接口的抽象父类即可

D、ISP原则是接口隔离原则

41.ISP原则用于指导接口设计 正确

解析：ISP原则，Interface Segregation Principle，接⼝隔离原则 D

概念理解 :1996年Martin提出，在《敏捷软件开发：原则、模式与实践》详细解释了ISP原则。

原始定义：ISP原则承认对象需要⾮内聚接⼝，然⽽ISP原则建议客户端不需要知道整个类，只需要知道具有内聚接⼝的抽象⽗类即可。也就是说，某些类不满⾜SRP原则，但使⽤这些类的客户端应该根据⽗类来使⽤它们，⽽不是直接使⽤它们。注：客户端===使⽤者 C

具体实践：其⼀，不应该强⾏要求客户端依赖于它们不⽤的接⼝； A

其⼆，类之间的依赖应该建⽴在最⼩的接⼝上⾯。简单点说，客户端需要什么功能，就提供什么接⼝，对于客户端不需要的接⼝不应该强⾏要求其依赖 B

应⽤场景：指导接⼝设计。本质上和SRP的思想⼀致。SRP⽤于指导类的设计，ISP⽤于指导接⼝的设计。

42.下面关于DIP原则描述正确的是 ABCD

A、高层模块不应该直接依赖底层模块，两者都应该依赖抽象层

B、抽象不能依赖细节，细节必须依赖抽象

C、指导类的抽象

D、DIP原则是依赖反转原则

解析：DIP原则，Dependency Inversion Principle，依赖反转原则 D

概念理解：1996年Martin提出，在《敏捷软件开发：原则、模式与实践》详细解释了DIP原则。

⼤师的解释：⾼层模块不应该直接依赖底层模块，两者都应该依赖抽象层。抽象不能依赖细节，细节必须依赖抽象 A

进⼀步的解释：模块的解释：⼴义的概念：站在系统层的⻆度，模块可以是⼦系统。站在⼦系统的⻆度，模块可以指模块站在模块的⻆度，模块可以指类

依赖的解释：⾼层模块不应该直接依赖底层模块，两者都应该依赖抽象层。⾼层模块“依赖”低层模块：⾼层模块需要调⽤低层模块的⽅法。⾼层模块“依赖”抽象层：指⾼层模块基于抽象层编程。低层模块“依赖”抽象层：低层模块继承或实现抽象层

解释：抽象不能依赖细节，细节必须依赖抽象。抽象不能依赖细节：与⾼层模块“依赖”抽象层相同。细节“依赖”抽象：与“低层模块“依赖”抽象层”相同 B

应⽤场景：指导类的抽象。当设计类之间的依赖关系时，可以使⽤DIP原则来判断这种依赖是否符合DIP原则。 C

DIP原则和LSP(⾥⽒替换)原则相辅相成，DIP原则⽤于指导抽象出接⼝或抽象类，⽽LSP(⾥⽒替换)

原则⽤于指导从接⼝或抽象类派⽣出新的⼦类。

43.过度设计原则是指远超需求的设计。 正确

解析：NOP，No Overdesign Priciple，不要过度设计原则

概念理解:不要过度设计。过度设计是指远超需求之外的设计。⽐如：设计时把5年之后可能的业务变化进⾏

了设计。

第二章

1.下列关于设计模式，说法正确的是 ABC

A、设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

B、模式描述了⼀个在我们周围不断重复发⽣的问题，以及该问题的解决⽅案的核⼼。

C、模式就是重复发⽣的问题的解决⽅案。

D、设计模式主要⽤于指导“类的定义”的设计，设计原则主要⽤于指导“类的⾏为”的设计。

解析：概念：借用了Christopher Alexander的定义：“模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。” B
模式就是重复发生的问题的解决方案。 C

设计原则主要用于指导“类的定义”的设计。设计模式主要用于指导“类的行为”的设计。D

软件设计模式Q(Design pattern),又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。A

2.模式由哪些基本要素构成？ABCD

A、模式名称：一个助记名，它用一两个词来描述模式的问题、解决方案和效果。

B、问题：描述了应该在何时使用模式。解释设计问题和问题存在的前因后果，它可能描述了特定的设计问题，也可能描述了导致设计方案不灵活的类或对象结构。

C、解决方案：描述设计的组成成分，它们之间的相互关系及各自的职责和协作方式。 解决方案一般并不描述特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。

D、效果：描述了模式应用的效果及使用模式应权衡的问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响。

解析：模式的构成
名称：标识模式，表达模式的问题、解决方案、效果等信息。
问题：模式的应用场景
解决方案：解决问题的抽象分析和解决方法，而不是具体问题的设计或实现。
效果：好的效果、坏的效果

3.模式的类别 ABC

A、创建型模式

B、结构型模式

C、⾏为型模式

D、状态式模式

解析：模式的类别（23个模式）
1.创建型模式
解决对象的创建问题。
5个：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式
2.结构型模式
解决类、对象的组合问题。

7个：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式

3.行为型模式

解决类、对象的协作问题。

11个：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式

4.设计模式的指导思想 ABC

A、找到变化，封装变化

B、基于接⼝编程，⽽不是基于实现编程

C、优先使⽤对象组合⽽不是继承

D、不拘泥于设计模式

解析：设计模式的指导思想
找到变化，封装变化（一个中心） A
基于接口编程，而不是基于实现编程（两个基本点） B
优先使用对象组合而不是继承（两个基本点） C

5.下面关于“设计模式之道”说法正确的是？ ABD

A、找到变化，封装变化。

B、对变化的概念进⾏封装。

C、模式是万能的。

D、凡是能封装变化的办法都可以⽤。

解析：《设计模式精解》（Design Pattern Explained）：找到变化，封装变化 A

模式不是瑞⼠军⼑，不是万能的。C

设计模式之道——对变化的概念进⾏封装。（出⾃：设计模式之道就隐藏在《设计模式》书中——2.6.2封装实现依赖关系中的最后⼀段。很简单，⼤道⾄简。 B

凡是能封装变化的办法都可以⽤。⽐如：使⽤配置⽂件封装变化。D

6.请解释下列类图有哪些要素？属于那种设计模式？

我的答案

Abstraction抽象类，RefinedAbstraction精细化的抽象，Implementor实现类接口（桥），ConcretelmplementorA，ConcretelmplementorB具体实现类，属于桥接模式

解析：桥接模式
·定义：将抽象部分和实现部分分离，使它们可以独立地改变，是一种对象结构型模式。
模式角色：
Abstraction(抽象类）
·RefinedAbstraction(精细化的抽象）
·Implementor(实现类接口）————桥
·Concretelmplementor(具体实现类）

https://www.cnblogs.com/MoisAbby/p/8616422.html
https://www.cnblogs.com/zytrue/p/8484806.html

7.第六题中出现的设计模式

意图：

主要解决：

何时使用：

如何解决：

我的答案

1、将抽象部分与其实现部分分离，使它们都可以独立的变化

2、在有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。

3、实现系统可能有多个角度分类，每一种角度都可能变化。

4、把这种多角度分类分离出来，让它们独立变化，减少它们之间耦合。

8.在WINDOWS操作系统中，"主题"一词特指WINDOWS的视觉外观。电脑主题可以包含风格、桌面壁纸、屏保、鼠标指针、系统声音事件、图标等，除了风格是必须的之外，其他部分都是可选的，风格可以定义的内容是大家在Windows里所能看到的一切。例如窗口的外观、字体、颜色 按钮的外观等等。 一个电脑主题里风格就决定了大家所看到的Windows的样子。

根据上述描述，现需要“灵活创建主题”的需求。请选择设计模式？并绘制出设计模式类图。

解析：Prototype模式

业务描述：“主题”是⼀个在⼿机和电脑上常⻅的概念，以⼿机为例，主题通常包含如下配项：待机图⽚或者动画；屏幕保护图⽚或动画；来电铃声；短信铃声。不同的主题包含不同⻛格的配置项组合，我们可以根据⾃⼰的喜好选择不同的主题；如果觉得某个主题默认的内容不好，我们也可以定制具体的内容。例如：可以修改来电铃声为⾃⼰喜欢的歌曲，也可以修改待机图⽚为⼥友的美图等。

假设条件：主题对象、配置项对象的创建都⼗分复杂。⽽主题、配置项的变化要求频繁的创建对象。

发现变化

不变：对⼀个特定系统⽽⾔，主题的配置项种类不会变化

变化1: 配置项的组合要变，即主题的种类要变化。例如：有的⼈喜欢经典的主题，有的⼈喜欢⽐较时尚的主题，还有的⼈喜欢运动相关的主题。

变化2: 对同⼀配置项来说配置项的内容要变，⽐如铃声，你可能喜欢《我的歌声⾥》，他可能喜欢《⽉亮之上》。因此，对于某⼀主题应该能够修改其配置项。

总结：主题属于个性化需求，主题种类会有很多，⽽且主题是由配置项组合⽽成，主题的创建

⽐较复杂。问题的核⼼——灵活创建主题

对象创建的复杂：参数多、构造困难、创建过程耗时

Prototye：⽤原型实例指定创建对象的种类，并且通过拷⻉这些原型创建新的对象。原型是物体⼤略的构造，基于原型能够简单的创建出新的物体。

创建型模式

Prototype(接⼝）：原型⽗类，声明clone接⼝。

ConcretePrototype1（实现类）:具体变化的原型，实现clone接⼝。

Client（使⽤者，聚合Prototype）：调⽤原型的clone接⼝得到新的对象。

public class WallPaper{

 public WallPaper clone();

}

public class ScreenSaver{

 public ScreenSaver clone() ;

}

public class ClassicWallPaper extends WallPaper{

 public WallPaper clone() {

 //省略墙纸对象的复制代码

 return null;

 }

}

public class FashionWallPaper extends WallPaper{

 public WallPaper clone() {

 //省略墙纸对象的复制代码

 return null;

 }

}

public class ClassicScreenSaver extends ScreenSaver {

 public ScreenSaver clone() {

 //省略屏保对象的复制代码

 return null;

 }

}

public class FashionSaver extends ScreenSaver {

 public ScreenSaver clone() {

 //省略屏保对象的复制代码

 return null;

 }

}

//主题原型类public class PrototypeTheme {

 

 public PrototypeTheme clone(){

 //省略主题对象的复制代码

 return null;

 }

 

}

//经典主题类

public class ClassicTheme extends PrototyeTheme{

 private WallPaper wallPaper;

 private ScreenSaver screenSaver;

 public ClassicTheme()

 {

 this.wallPaper = new ClassicPaper();

 this.screenSaver = new ClassicScreenSaver();

 }

 

 public WallPaper getWallPaper() {

 return wallPaper.clone();

 

 }

 public void setWallPaper(WallPaper wallPaper) {

 this.wallPaper = wallPaper;

 }

 public ScreenSaver getScreenSaver() {

 return screenSaver.clone();

 }

 public void setScreenSaver(ScreenSaver screenSaver) {

 this.screenSaver = screenSaver;

 }

 

 

 public PrototypeTheme clone(){

 //省略主题对象的复制代码

 return null;

 }

 

}

public class Test {

 public static void main(String[]args) {

 //⽆参构造⽅法，简化主题对象的创建⽅法

 PrototypeTheme classicTheme = new ClassicTheme();

 useTheme(classicTheme); 

 //克隆主题，并修改

 PrototypeTheme myTheme = classicTheme.clone();

 WallPaper myPaper = myTheme.getWallPaper(); //得到了⼀个克隆的墙纸对象

 //省略墙纸的修改的代码

 myTheme.setWallPaper(myPaper);

 

 }

 public static void useTheme(PrototypeTheme theme) {

 

 }

}

设计分析

配置项类会越来越多，但是这些类的增⻓速度远⼩于主题类增加的速度。因为主题类是主题项的组合增⻓。（没有彻底解决类增⻓的问题）。能够预置各种现成的主题。通过修改主题类配置项能够灵活的增加主题。配置项的变化不需要添加新的主题类。

第三章

1.关于架构的概念，下列说法不正确的是 D

A、是计算机硬件或者软件系统的结构和组织。

B、架构是系统的顶层结构。

C、“顶层”意味着“架构”的粒度到当前系统的子系统或者子模块。

D、子系统没有架构。

解析：概念：计算机硬件或者软件系统的结构和组织。A

换句话说，架构是系统的结构和组织。
架构与结构的关系：架构就是结构，但指的是系统级的结构，也就是说，架构是系统的顶层结构。B

“顶层"意味着"架构"的粒度到当前系统的子系统或者子模块。C
系统与子系统的关系：“系统”和“子系统”是一个相对概念，“子系统”也是“系统”，也有自己的架构。D
软件架构直观映像：金字塔。塔的最底层就是软件的详细结构。

2.下列关于业务架构说法错误的是：A

A、业务架构是文字描述，需要考虑业务的各个细节。

B、业务架构包含功能需求和质量需求。

C、业务架构除了关注业务本身的流程外，也需要包含业务的约束和限制。

D、业务架构只需要描述业务的整体结构即可，不需要考虑业务的细节。

解析：业务架构和需求模型⼀样，其实也是⽂字描述，但⽐需求模型更抽象，也不需要关注各种异常或者替代分⽀处理流程，只需要描述业务的整体结构即可。A D

业务约束和限制：功能需求是架构的基本要求，满⾜业务约束和限制需求才是合格架构。因此，业务架构除了关注业务本身的流程外，也需要包含业务的约束和限制 C

业务需求（功能需求+质量需求）B

3.Java的JVM架构主要包含哪几类子系统：ABC

A、类加载子系统

B、运行时数据区

C、执行引擎

D、垃圾收集器

解析：JVM架构–>三个⼦系统–>类加载器⼦系统、运⾏时数据区、执⾏引擎

4.JVM架构中类加载子系统经历哪几个阶段 ABCD

A、从 Class 文件加载到内存，对数据进行校验；

B、转换解析和初始化；

C、形成可以被虚拟机直接使用的 Java 类型；

D、将高级语言翻译为机器语言。

解析：JVM 的类加载分为 5 个阶段：加载、验证、准备、解析、初始化。

5.JVM中执行引擎包含：ABC

A、解释器 ：运行字节码文件

B、编译器：把字节码文件(.class文件)编译成根据当前操作系统能够执行的文件，他决定跨平台

C、垃圾回收器：会把内存中产生的垃圾数据进行回收清理，进行释放内存，

D、JIN：java本地接口

解析：执行引擎–>解释器、编译器、垃圾回收器、JIN、本地⽅法库

执行引擎属于 JVM 的下层，里面包括解释器、及时编译器、垃圾回收器——知乎

6.架构设计的任务是： ABD

A、把系统拆分为不同子系统或不同模块。

B、有机的组织好这些子系统或模块。

C、通过封装“类”来降低复杂度。

D、架构 = 子系统（模块）+ 交互。

解析：架构设计的任务

1.把系统拆分为不同⼦系统或不同模块。A

2.有机的组织好这些⼦系统或模块。B

3.架构 = ⼦系统（模块）+ 交互 D

7.下列说法正确的是：ACD

A、面向对象架构设计通过封装“模块”来降低复杂度。

B、面向对象架构设计通过“类”来完成分工合作。

C、面向对象思想既可以指导程序设计，也可以指导架构设计。

D、面向对象架构设计通过“模块交互”来完成分工合作。

解析：⾯向对象程序设计通过封装“类”来降低复杂度，⾯向对象架构设计通过封装“模块”来降低复杂度。A

⾯向对象程序设计通过“类”交互来完成分⼯合作，⾯向对象架构设计通过“模块交互”来完成分⼯合

作。BD

⾯向对象思想既可以指导程序设计，也可以指导架构设计。C

8.面向对象架构设计的总体流程有： BCE

A、用例模型

B、业务架构

C、领域架构

D、领域模型

E、软件架构

F、软件模型

解析：⾯向对象架构设计的总体流程–>业务架构–>领域架构–>软件架构

9.业务架构包含哪两种场景： BC

A、创新设计的业务系统

B、全新的业务系统

C、已有架构的优化

D、颠覆已有架构

解析：业务架构设计–>全新的业务系统、已有架构的优化

10.软件架构设计流程可以分为以下几步：ABCD

A、照猫画虎：将领域架构中的各部分的名称后增加“子系统”，形成初始的软件架构。

B、按图索骥：“图”是质量需求，“骥”是架构模式，逐一对照质量需求，设计满足要求的软件架构。

C、深思熟虑：“深思”全面评估各个备选方案的优劣点。“熟虑”挑选最优的方案。

D、精益求精：逐步迭代，进一步优化。

解析：软件架构设计流程–>第⼀步：照猫画⻁：将领域架构中的各部分的名称后增加“⼦系统”，形成初始的软件架构。第⼆步：按图索骥。概述：按领域架构映射的初始软件架构，业务功能需求⼀般情况下已经满⾜，但质量需求可能还⽆法满⾜，因此这⼀步就是要设计能够满⾜业务质量需求的软件架构。“图”是质量需求，“骥”是架构模式。第三步：深思熟虑。概述：“深思”全⾯评估各个备选⽅案的优劣点。“熟虑”挑选最优的⽅案

11.架构师要考虑的因素 ABCD

A、成本、可靠性

B、质量、投入、进度、

C、性能、可扩展性

D、团队技能水平

解析：架构师要考虑的因素

技术因素：成本、可靠性、性能、可扩展性等。

管理因素：质量、投⼊、进度、团队技能⽔平等。

12.如果单台机器自身性能瓶颈，如何解决问题，满足性能需求？ BD

A、扩展系统。

B、拆分子系统。

C、拆地点：将机器放在不同的地点。

D、增加物理机器的数量

解析：⼀台机器处理太慢，拆。需要集群，性能达到瓶颈，系统也比较复杂了，不适合扩展系统。

13.“拆”的常见手段有哪些？（ ）ABC

A、 拆硬件

B、拆地点

C、拆功能

D、拆系统

解析：“拆”的常⻅⼿段：拆硬件、拆地点、拆功能

14.“拆地点”可分为哪些种方式？（ ）ABC

A、同城多机房

B、跨城多机房

C、跨国多机房

D、跨区多机房

解析：拆分的模式：同城多机房、跨城多机房、跨国多机房

15.“拆”的原则有哪些？（ ）ABCD

A、 要拆“应该拆”的

B、不要到处“拆”

C、不可强“拆”

D、要技术性地“拆”

解析：拆的原则

要拆“应该拆”的，不要到处“拆”。（没有问题的不要拆）

不可强“拆”，要技术性地“拆”。（拆后影响要⼩）

16.拆功能的优点（ ）ABC

A、系统变得简单

B、改动影响小，方便各系统独立扩展

C、通过接口来控制变更，降低风险

D、接口增加，交互变得复杂

解析：拆功能的优点：

系统变得简单。每个系统负责的功能少了，⾃然就变得简单了。A

改动影响⼩，⽅便各系统独⽴扩展。通过拆分，单个功能的改动和影响被限制在有限的范围内。例如，同样是修改“登录”功能，在原来⼤⼀统的系统内，可能会影响“注册”、“任务”、“签到”等功能。拆分后，最多影响“注册”，其他功能不受影响。B

通过接⼝来控制变更，降低⻛险。拆分后的⼦系统间通过接⼝进⾏交互，⼤⼤地降低了⻛险。C

拆功能的缺点：

接⼝增加，交互变得复杂

17.“合”的常见手段有哪些？（ ）ABCD

A、 客户端合

B、网络合

C、中间件合

D、子系统合

解析：“合”的常⻅⼿段：客户端合、⽹络合、中间件合、⼦系统合

18.三横包括哪些方面？（ ）ABC

A、 确定系统目标

B、研究高层需求

C、建立用例模型

D、确定非功能需求

解析：三横（存在先后次序）

确定⽬标：输出业务⽬标 A

研究⾼层需求：确定范围、特性、上下⽂图 B

建⽴⽤例模型：⽤例模型 C

19.下列叙述中，正确的是（ ） ABC

A、功能是发现职责的依据

B、质量是完善架构设计的动力

C、约束直接制约设计决策

D、质量单独影响架构

解析：功能是发现职责的依据 A

质量是完善架构设计的动力 B

质量和功能共同影响架构，抛开任何⼀⽅开展设计都是不合适的 D

约束直接制约设计决策 C

20.需求分为哪几类？（ ）ABC

A、 功能需求

B、质量属性

C、约束需求

D、直接需求

解析：需求⽅⾯：功能、质量、约束

21.领域模型对整个软件开发活动的作用（ ）ABD

A、为需求规格提供了领域知识和领域词汇

B、为软件界面设计提供了参考

C、在分层架构中领域模型是数据层的核心

D、是数据架构的重要参考

解析：领域模型⼦软件开发中的作⽤（强化领域模型的重要性即可）

为需求规格提供了领域知识和领域词汇 A

为软件界⾯设计提供了参考，⼀⽅⾯领域信息是软件展现的重要内容，另⼀⽅⾯领域模型为界⾯信息布局提供了参考。影响软件的可扩展性，因为领域模型决定了软件可能的范围 B

在分层架构中领域模型是业务层的核⼼ C

是数据架构的重要参考 D

22.物理架构从哪些方面设计优化来“降低开销”和“避免争用”（ ） ABCD

A、 降低物理节点内的计算开销

B、降低物理节点间的通信开销

C、避免物理节点内的CPU、内存、硬盘等资源争用

D、避免物理节点间的网络带宽资源争用

解析：物理架构设计从思维层⾯要降低开销避免争⽤

降低物理节点内的计算开销 A

降低物理节点间的通信开销 B

避免物理节点内的cpu、内存、硬盘等资源争⽤ C

避免物理节点间的⽹络带宽资源争⽤ D

23.架构设计的终极方法是“合”，而终极难点是“拆”。（ ） 错误

24.拆硬件有两种常见的架构模式：主备模式和负载均衡模式。（ ） 正确

解析：有两种常⻅的架构模式：主备模式和负载均衡模式。

25.架构设计有两个重要原则：客户需求原则和超前原则。（ ） 错误

解析：设计原则

客户需求原则。“如何满⾜客户需求”。

适当超前原则。

超前要适当。唯⼀不变就是变化。预测的太⻓，预测正确的概率就会急剧下降。

⾸先满⾜客户需求，然后适当超越客户需求。

如何把握“适当”需要架构师具备⾏业经验。有的⾏业变化快，有的⾏业变化慢。

26.用例技术本身不是面向对象的，而设计应该是面向对象的，这是两种不同的思维方式。（ ）正确

解析：⽤例不是⾯向对象或⾯向过程，⽽设计应该是⾯向过程或⾯向对象

27.概念架构是界定系统的高层组件以及它们之间的关系，但不涉及接口细节。（ ） 正确

解析：概念架构的定义：是界定系统的⾼层组件以及它们之间的关系，但不涉及接⼝细节

28.概念架构是细化架构，强调战术，追求完整。（ ） 错误

解析：概念架构不是细化架构，强调战略不是战术，强调重点不追求完整。

29.场景包含：影响来源、如何影响、受影响对象和所处环境4个要素。（ ） 错误

解析：场景思维5要素

影响来源。来⾃系统外部或系统内部的触发因素。

如何影响。影响来源施加了什么影响。

受影响对象。默认的受影响对象为“⽬标系统”

问题或价值。受影响对象因此⽽出现什么问题，或需要体现什么价值

所处环境。所处环境或上下⽂怎样。

30.物理架构关注职责划分和接口定义。不同粒度的职责需要被关注，它们可能是逻辑层、功能子系统、模块、关键类等。（ ） 错误

解析：逻辑架构实践。关注点：关注职责划分和接⼝定义。不同粒度的职责需要被关注，它们可能是逻辑层、功能⼦系统、模块、关键类等。

物理架构实践。关注点：关注“⽬标程序及其依赖的运⾏库和系统软件”最终如何安装、烧写或部署到物理机器，以及如何部署机器和⽹络来配合软件系统的可靠性、可伸缩性等要求。

31.类加载过程的整个生命周期包括七个阶段，依次是

加载，验证，准备，解析，初始化，使用，卸载

32.完成下面软件设计过程图

1、需求分析
2、领域建模
3、确定关键需求
4、概念架构设计
5、细化架构设计
6、架构验证

解析：

33.领域架构的提炼方法

提取业务模块、确定业务模块之间的关系

解析：领域架构设计–>提炼⽅法–>提取业务模块、确定业务模块之间的关系

34.完成下面概念架构的设计过程图

1、关键功能
2、关键质量
3、运用鲁棒图
4、运用目标-场景-决策表
5、概念架构

解析：

35.假设在一个未知的星球上，有电视、电话，但没有电脑，现在我们要在这个星球上创建一个电视购物商城，名叫“京西商城”，京西商城业务如下：

1.京西商城在电视上投放商品广告。

2.客户通过看电视，获取商品信息。

3.客户打电话给京西商城的客服下订单。

4.京西商城的客服收到订单后，客服打电话给仓库管理员下出货单。

5.仓库管理员生成出货单，安排物流人员送货。

6.客户收到货后，支付款项给物流人员。

7.物流人员收到款项后，将出货单盒款项交给结算中心结算。

8.结算中心确认发货单和款项无误后，记录订单，订单完成。

性能需求：1.性能：10万个订单/秒；2.可靠性：99.999%，全年中断服务时间为5分钟。

请根据上述内容，设计该系统的系统架构图。