系统分析师15：系统设计

1 内容概要

2 软件架构设计

2.1 架构设计

• 软件架构 = 软件体系结构
• 架构设计就是需求分配，即将满足需求的职责分配到组件上
  

2.2 架构风格

• 架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统
• 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
• 五大架构风格及其子风格
  

2.3 服务

• 服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持
• 服务的特点是：松散耦合、粗粒度、标准化接口
• 单个服务内部结构
  

2.3.1 SOA

• 典型的SOA结构
  

2.3.1.1 SOA实现技术——Web Service

Web Service 是实现 SOA 的关键技术之一，通过 UDDI、WSDL 和 SOAP 等技术，Web Service 能够实现服务的发布、描述和通信。Web Service 应用系统的六大层次从底层传输层到服务注册层，层层递进，确保了服务的可靠传输、通信、描述、实现、业务流程协调和服务注册与查找。

【SOA的关键技术】

1. UDDI (Universal Description, Discovery, and Integration)
   • 功能: 提供服务发布、查找和定位的方法。
   • 作用: 帮助服务提供者发布其服务，并允许服务请求者查找和定位所需的服务。

2. WSDL (Web Services Description Language)

• 功能: 对服务进行描述的语言。
• 作用: 定义服务的接口、操作、消息格式等，使服务请求者能够理解和使用服务。

3. SOAP (Simple Object Access Protocol)

• 功能: 服务请求者和服务提供者之间的消息传输规范。
• 作用: 定义消息的格式和传输协议，确保服务请求者和服务提供者之间的可靠通信。
  

【Web Service应用系统的六大层次】

1. 底层传输层

   • 功能: 负责数据的物理传输。
   • 协议: HTTP、HTTPS、SMTP等。
   • 作用: 确保数据在网络中的可靠传输。

2. 服务通信协议层

   • 功能: 定义服务请求者和服务提供者之间的通信协议。
   • 协议: SOAP、REST等。
   • 作用: 确保服务请求者和服务提供者之间的消息交换符合规范。

3. 服务描述层

   • 功能: 描述服务的接口和操作。
   • 语言: WSDL。
   • 作用: 提供服务的详细描述，使服务请求者能够理解和使用服务。

4. 服务层

   • 功能: 实现具体的服务功能。
   • 作用: 提供服务的具体实现，处理服务请求并返回结果。

5. 业务流程层

   • 功能: 定义和协调多个服务的执行顺序。
   • 语言: BPEL (Business Process Execution Language)。
   • 作用: 管理和协调多个服务的执行，实现复杂的业务流程。

6. 服务注册层

   • 功能: 提供服务的注册、查找和定位功能。
   • 协议: UDDI。
   • 作用: 帮助服务提供者发布其服务，并允许服务请求者查找和定位所需的服务。

2.3.1.2 SOA实现技术——ESB

• Enterprise Service Bus (ESB) 是一种用于集成和协调企业内部各种服务的技术架构。它充当服务之间的中介，提供消息路由、转换、协议适配、服务编排等功能，从而实现不同服务之间的无缝通信和协作。ESB 是实现面向服务架构 (SOA) 的关键组件之一，旨在提高系统的灵活性、可扩展性和可维护性。
  

【功能】

• 提供位置透明性的消息路由和寻址服务
• 提供服务注册和命名的管理功能
• 支持多种消息的传递泛型
• 支持多种可以广泛使用的传输协议
• 支持多种数据格式及其相互转换
• 提供日志和监控功能

2.3.2 微服务

• 微服务：顾名思义，就是很小的服务，所以它属于面向服务架构的一种

• 【特点(优点)】
  小服务【且专注于做一件事情】
  轻量级的通信机制
  松耦合
  独立测试
  独立部署【简单部署】
  独立运行【每个服务独立在其独立进程中】
  支持异构【如每个服务使用不同数据库】
  更好的可用性与弹性
  化整为零，易于小团队开发

• 【面临的挑战】
  分布式环境下的数据一致性【更复杂】
  测试的复杂性【服务间依赖测试】
  运维的复杂性

2.3.3 微服务和SOA的对比

2.3.3.1 微服务 (Microservices)

1. 能拆分的就拆分

   • 特点: 微服务架构鼓励将系统拆分成多个独立的小服务，每个服务专注于一个特定的业务功能。
   • 作用: 提高系统的灵活性和可扩展性。

2. 纵向业务划分

   • 特点: 微服务按照业务功能进行纵向划分，每个服务独立负责一个业务领域。
   • 作用: 简化服务的管理和维护。

3. 由单一组织负责

   • 特点: 每个微服务通常由一个独立的团队负责开发、部署和维护。
   • 作用: 提高团队的自主性和响应速度。

4. 细粒度

   • 特点: 微服务的粒度较细，通常只负责一个特定的业务功能。
   • 作用: 提高服务的专注度和效率。

5. 两句话可以解释明白

   • 特点: 微服务的业务逻辑通常比较简单，可以用几句话解释清楚。
   • 作用: 简化服务的理解和使用。

6. 独立的子公司

   • 特点: 微服务可以看作是独立的“子公司”，每个服务独立运行，互不干扰。
   • 作用: 提高系统的可靠性和容错性。

7. 组件小

   • 特点: 微服务的组件通常较小，专注于一个特定的业务功能。
   • 作用: 简化服务的开发和维护。

8. 业务逻辑存在于每一个服务中

   • 特点: 每个微服务包含自己的业务逻辑，独立完成特定的业务功能。
   • 作用: 提高服务的独立性和可重用性。

9. 使用轻量级的通信方式，如HTTP

   • 特点: 微服务通常使用轻量级的通信协议，如HTTP/REST。
   • 作用: 简化服务之间的通信和集成。

2.3.3.2 SOA (Service-Oriented Architecture)

1. 是整体的，服务能放一起的都放一起

   • 特点: SOA 倾向于将相关的服务组合在一起，形成一个整体的服务集合。
   • 作用: 提高服务的集成度和协同工作能力。

2. 是水平分多层

   • 特点: SOA 通常按照功能层次进行水平划分，如数据层、业务逻辑层、表示层等。
   • 作用: 提高系统的结构化和模块化。

3. 按层级划分不同部门的组织负责

   • 特点: SOA 的服务通常由不同部门的组织负责，每个部门负责一个特定的层次或功能。
   • 作用: 提高组织的协作和分工。

4. 粗粒度

   • 特点: SOA 的服务粒度通常较粗，涵盖多个业务功能。
   • 作用: 提高服务的覆盖范围和集成度。

5. 几百字只相当于SOA的目录

   • 特点: SOA 的业务逻辑通常比较复杂，需要较多的描述和解释。
   • 作用: 提高服务的全面性和复杂性。

6. 类似大公司里面划分了一些业务单元 (BU)

   • 特点: SOA 的服务可以看作是大公司中的业务单元，每个单元负责一个特定的业务领域。
   • 作用: 提高服务的组织性和管理性。

7. 存在较复杂的组件

   • 特点: SOA 的组件通常较复杂，涵盖多个业务功能。
   • 作用: 提高服务的集成度和复杂性。

8. 业务逻辑横跨多个业务领域

   • 特点: SOA 的业务逻辑通常横跨多个业务领域，涉及多个服务之间的协作。
   • 作用: 提高服务的全面性和复杂性。

9. 企业服务总线(ESB)充当了服务之间通信的角色

   • 特点: SOA 使用 ESB 作为服务之间的通信中介，提供消息路由、转换、协议适配等功能。
   • 作用: 提高服务的通信和集成能力。

2.3.3.3 小结

微服务和 SOA 都是面向服务的架构风格，但它们在服务粒度、组织方式、通信方式等方面存在显著差异。微服务强调细粒度的服务拆分和独立性，适合快速迭代和敏捷开发；而 SOA 强调服务的集成和协同工作，适合复杂的企业级应用。选择哪种架构风格取决于具体的业务需求和系统特点。

2.4 Model Driven Architecture(MDA)

2.4.1 概述

Model Driven Architecture (MDA) 是一种软件开发方法论，旨在通过使用模型来驱动软件的整个生命周期，包括分析、设计、构建、部署和维护。MDA 的核心思想是将系统的规约与平台的实现分离，从而提高软件的可移植性、互通性和可重用性。

2.4.2 关键概念

1. Model (模型)

   • 定义: 模型是对客观事物的抽象表示。
   • 作用: 模型用于描述系统的结构、行为和功能，是软件开发的基础。

2. Architecture (架构)

   • 定义: 架构是构成系统的部件、连接件及其约束规约。
   • 作用: 架构定义了系统的整体结构和组件之间的关系，是系统设计的核心。

3. Model-Driven (模型驱动)

   • 定义: 使用模型完成软件的分析、设计、构建、部署、维护等各开发活动。
   • 作用: 通过模型驱动开发，提高软件开发的效率和质量。

4. MDA的起源

   • 思想: 分离系统规约和平台实现的思想。
   • 作用: 通过分离系统规约和平台实现，提高软件的可移植性和可重用性。

2.4.3 MDA的主要目标

1. Portability (可移植性)

   • 定义: 软件能够在不同的平台上运行，而不需要进行大量的修改。
   • 作用: 提高软件的可移植性，降低平台迁移的成本。

2. Interoperability (互通性)

   • 定义: 软件能够与其他系统或组件进行无缝的通信和协作。
   • 作用: 提高软件的互通性，促进系统集成和互操作。

3. Reusability (可重用性)

   • 定义: 软件组件能够在不同的系统或项目中重复使用。
   • 作用: 提高软件的可重用性，降低开发成本和时间。

2.4.3 MDA的3种核心模型

1. 平台独立模型 (PIM)

   • 定义: 具有高抽象层次、独立于任何实现技术的模型。
   • 作用: PIM 描述系统的核心功能和结构，不依赖于具体的实现技术。

2. 平台相关模型 (PSM)

   • 定义: 为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。
   • 作用: PIM 会被变换成一个或多个 PSM，每个 PSM 针对特定的实现技术进行优化。

3. 代码 (Code)

   • 定义: 用源代码对系统的描述（规约）。
   • 作用: 每个 PSM 都将被变换成代码，最终生成可执行的软件系统。

2.4.4 MDA的开发流程

1. 创建平台独立模型 (PIM)

   • 步骤: 分析系统的功能和结构，创建高层次的抽象模型。
   • 作用: 描述系统的核心功能和结构，不依赖于具体的实现技术。

2. 转换为平台相关模型 (PSM)

   • 步骤: 将 PIM 转换为针对特定实现技术的 PSM。
   • 作用: 优化模型以适应特定的实现技术，提高系统的性能和效率。

3. 生成代码

   • 步骤: 将 PSM 转换为源代码。
   • 作用: 生成可执行的软件系统，实现系统的功能和结构。

2.4.5 小结

MDA 是一种通过模型驱动软件开发的方法论，旨在提高软件的可移植性、互通性和可重用性。通过分离系统规约和平台实现，MDA 使用平台独立模型 (PIM)、平台相关模型 (PSM) 和代码生成，实现从高层次抽象到具体实现的转换。MDA 的核心目标是提高软件开发的效率和质量，降低开发成本和时间。

2.5 软件设计

• 软件设计包括体系结构设计、接口设计、数据设计和过程设计
  • 结构设计：定义软件系统各主要部件之间的关系
  • 数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性
  • 接口设计（人机界面设计)：软件内部，软件和操作系统间以及软件和人之间如何通信
  • 过程设计：系统结构部件转换成软件的过程描述

例1
软件设计包括了四个既独立又相互联系的活动：高质量的（）将改善程序结构和模块划分，降低过程复杂性；(）的主要目标是开发一个模块化的程序结构，并表示出模块间的控制关系；(）描述了软件与用户之间的交互关系。
A:程序设计
B:数据设计
C:算法设计
D:过程设计

A:软件结构设计
B:数据结构设计
C:数据流设计
D:分布式设计

A:数据架构设计
B:模块化设计
C:性能设计
D:人机界面设计

解析

1. 高质量的（B:数据设计）将改善程序结构和模块划分，降低过程复杂性

• 数据设计: 数据设计关注的是如何组织和表示数据，包括数据结构、数据库设计等。高质量的数据设计能够改善程序的结构和模块划分，降低过程复杂性，提高代码的可读性和可维护性。

2. （A:软件结构设计）的主要目标是开发一个模块化的程序结构，并表示出模块间的控制关系

• 软件结构设计: 软件结构设计关注的是如何将系统划分为模块，并定义模块之间的控制关系。其主要目标是开发一个模块化的程序结构，确保模块之间的低耦合和高内聚，提高系统的可维护性和可扩展性。

3. （D:人机界面设计）描述了软件与用户之间的交互关系

• 人机界面设计: 人机界面设计关注的是如何设计用户与软件之间的交互界面，包括用户界面、交互流程、用户体验等。其主要目标是提供一个直观、易用、高效的交互界面，确保用户能够方便地使用软件。

答案：B 、A、D。

2.6 架构评估方法

2.6.1 概述

架构评估是确保系统设计满足需求和质量属性的关键步骤。常用的评估方法包括基于调查问卷（检查表）的方式、基于度量的方式、基于场景的方式。

• 基于调查问卷（检查表)的方式
• 基于度量的方式
• 基于场景的方式
  

2.6.1.1 基于调查问卷（检查表）的方式

概述: 基于调查问卷的方式通过向相关人员（如架构师、开发人员、测试人员等）发放问卷，收集他们对架构设计的意见和建议。

步骤:

• 设计问卷：根据评估目标设计一系列问题，涵盖架构的各个方面。
• 发放问卷：将问卷发放给相关人员，收集他们的反馈。
• 分析结果：汇总和分析问卷结果，识别架构设计中的问题和改进点。

优点:

• 简单易行，成本较低。
• 能够收集广泛的意见和建议。

缺点:

• 主观性强，依赖于问卷设计和参与者的经验。
• 难以量化评估结果。

2.6.1.2 基于度量的方式

概述: 基于度量的方式通过收集和分析架构设计的量化指标，评估架构的质量和性能。

步骤:

• 定义度量指标：根据评估目标定义一系列量化指标，如模块化程度、耦合度、内聚度等。
• 收集数据：通过工具或手动方式收集架构设计的相关数据。
• 分析数据：使用统计方法分析数据，评估架构的质量和性能。

优点:

• 客观性强，能够量化评估结果。
• 能够识别架构设计中的具体问题。

缺点:

• 需要定义和收集大量的度量指标，工作量较大。
• 度量指标的选择和定义可能存在主观性。

2.6.1.3 基于场景的方式

概述: 基于场景的方式通过描述系统在特定情况下的行为和响应，评估架构的适应性和可靠性。

场景: 场景是从风险承担者的角度与系统交互的简短描述，通常包括刺激、环境和响应三个方面。

步骤:

• 定义场景：根据评估目标定义一系列场景，描述系统在特定情况下的行为和响应。
• 分析场景：分析每个场景中的刺激、环境和响应，评估架构的适应性和可靠性。
• 改进架构：根据场景分析结果，改进架构设计，提高系统的适应性和可靠性。

优点:

• 能够模拟真实情况，评估架构的实际表现。
• 能够识别架构设计中的潜在问题。

缺点:

• 场景的定义和分析可能存在主观性。
• 需要定义和分析大量的场景，工作量较大。

2.6.2 场景的三个方面

1. 刺激 (Stimulus)

   • 定义: 场景中解释或描述项目干系人怎样引发与系统的交互部分。
   • 作用: 描述系统在特定情况下的触发条件和交互方式。

2. 环境 (Environment)

   • 定义: 描述刺激发生时的情况。
   • 作用: 描述系统在特定情况下的运行环境和条件。

3. 响应 (Response)

   • 定义: 系统是如何通过架构对刺激作出反应的。
   • 作用: 描述系统在特定情况下的行为和响应，评估架构的适应性和可靠性。
     

2.6.4 SAAM (Software Architecture Analysis Method)

2.6.4.1 概述

SAAM 最初用于分析架构的可修改性，后来扩展到其他质量属性。

2.6.4.2 过程

1. 形成场景

   • 步骤: 根据评估目标定义一系列场景，描述系统在特定情况下的行为和响应。
   • 作用: 为后续评估提供基础。

2. 描述架构

   • 步骤: 详细描述系统的架构设计，包括模块、组件、连接件等。
   • 作用: 为场景分析提供架构基础。

3. 对场景分类和确定优先级

   • 步骤: 根据重要性和影响程度对场景进行分类和优先级排序。
   • 作用: 确保重点场景得到优先评估。

4. 对场景进行单个评估

   • 步骤: 逐一评估每个场景，分析架构在特定情况下的表现。
   • 作用: 识别架构设计中的具体问题。

5. 评估场景的相互作用

   • 步骤: 分析不同场景之间的相互作用，评估架构的整体表现。
   • 作用: 确保架构能够应对复杂情况。

6. 形成总体评价

   • 步骤: 汇总所有评估结果，形成对架构设计的总体评价。
   • 作用: 提供改进架构设计的建议。

2.6.5 ATAM (Architecture Tradeoff Analysis Method)

2.6.5.1 概述

ATAM 在 SAAM 的基础上发展起来，旨在揭示架构满足特定质量目标的情况，使架构设计师更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。主要针对性能、可用性、安全性和可修改性。

2.6.5.2 过程

1. 描述和介绍阶段

   • 步骤:
     1. 描述 ATAM 方法：介绍 ATAM 的评估过程和目标。
     2. 描述业务动机：解释系统的业务目标和动机。
     3. 描述架构：详细描述系统的架构设计。
   • 作用: 为后续评估提供背景和基础。

2. 调查和分析阶段

   • 步骤:
     1. 确定架构方法：识别和描述架构设计中使用的方法和策略。
     2. 生成质量属性效用树：创建一个树状结构，表示不同质量属性的重要性和优先级。
     3. 分析架构方法：评估架构方法对质量属性的影响。
   • 作用: 深入分析架构设计，识别质量属性的权衡和冲突。

3. 测试场景

   • 步骤:
     1. 讨论场景和对场景分级：讨论和分类场景，确定其优先级。
     2. 分析架构方法：评估架构方法在特定场景下的表现。
   • 作用: 通过场景测试，评估架构的实际表现。

4. 报告阶段

   • 步骤: 描述评估结果，包括架构的优点和缺点，以及改进建议。
   • 作用: 提供改进架构设计的具体建议。

例2
软件架构评估是软件设计阶段最重要的活动之一，目前存在多种软件架构评估方式，其中，其中架构权衡分析法(Architecture Trade off Analysis Method,ATAM)属于基于( )的方式,在该方法的架构评估中，()是解释或描述项目干系人怎样引发与系统的交互部分。

A:场景
B:度量
C:仿真
D:调查问卷

A:环境
B:刺激
C:响应
D:制品

解析

• ATAM 是一种基于场景的架构评估方法，旨在揭示架构满足特定质量目标的情况，使架构设计师更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标
• 场景的三个方面
  • 刺激 (Stimulus)：场景中解释或描述项目干系人怎样引发与系统的交互部分；
  • 环境 (Environment)：描述刺激发生时的情况
  • 响应 (Response)：系统是如何通过架构对刺激作出反应的

答案：A、B。

3 人机界面设计

• 黄金三法则
  
  例3
  下列关于用户界面设计的叙述中，错误的是（ ) 。
  A：界面交互模型应经常进行修改
  B：界面的视觉布局应该尽量与真实世界保持一致
  C：所有可视信息的组织需要按照统一的设计标准
  D：确保用户界面操作和使用的一致性

解析

• 在用户界面设计中，界面交互模型不应经常进行修改，因为频繁修改会增加用户的学习成本，降低用户体验。
• 相反，界面的视觉布局应尽量与真实世界保持一致，所有可视信息的组织需要按照统一的设计标准，确保用户界面操作和使用的一致性。这些原则有助于提高用户界面的易用性和用户体验

答案：A。

4 工作流设计

工作流管理系统(WorkFlow Management System,WFMS)

• 基本功能
  • 对工作流进行建模。即定义工作流
  • 工作流执行。执行实际的工作流
  • 业务过程的管理和分析。监控和管理执行中的业务(工作流)，进度完成情况和数据所处状态、工作分配与均衡情况等

工作流参考模型(Workflow Reference Model，WRM)

• 工作流执行服务：【核心模块】，功能包括【创建和管理流程定义】，创建、管理和执行流程实例
• 工作流引擎：是为流程实例【提供运行环境】，并解释执行流程实例的软件模块
• 流程定义工具：是【管理流程定义的工具】，它可以通过图形方式把复杂的流程定义显示出来并加以操作，流程定义工具与工作流执行服务交互，一般该模块为设计人员提供图形化的用户界面
• 客户端应用：是通过请求的方式与工作流执行服务交互的应用
• 调用应用：是【被工作流执行服务调用的应用】，调用应用与工作流执行服务交互
• 管理监控工具：主要指组织机构和参与者等数据的维护管理和流程执行情况的监控，管理监控工具与工作流执行服务交互

例4
工作流参考模型(Workflow Reference Model, WRM）包含6个基本模块，分别是( )、工作流引擎、流程定义工具、()、调用应用和管理监控工具。

A:工作流执行服务
B:流程服务引擎
C:服务标准引擎
D:流程设计工具

A:客户端应用
B:服务端应用
C:部署端应用
D:网络端应用

解析
工作流参考模型(Workflow Reference Model, WRM）包含6个基本模块，分别是工作流执行服务、工作流引擎、流程定义工具、客户端应用、调用应用和管理监控工具。
答案：A、A。

5 结构化设计

• 概要设计【外部设计】∶功能需求分配给软件模块，确定每个模块的功能和调用关系，形成模块结构图

• 详细设计【内部设计】∶为每个具体任务选择适当的技术手段和处理方法

• 结构化设计原则

  • 模块独立性原则(高内聚、低耦合)
  • 保持模块的大小适中
  • 扇入/扇出系数合理（多扇入，少扇出)
    • 扇入：有几个模块调用它，扇入就为几
    • 扇出：当前模块，需要几个其他模块配合工作
    • 扇出越高，复杂度越高，耦合增加
  • 深度和宽度均不宜过高

• 内聚类型

  • 功能内聚：完成一个单一功能，各个部分协同工作，缺一不可
  • 顺序内聚：处理元素相关，而且必须顺序执行
  • 通信内聚：所有处理元素集中在一个数据结构的区域上
  • 过程内聚：处理元素相关，而且必须按特定的次序执行
  • 瞬时内聚（时间内聚)：所包含的任务必须在同一时间间隔内执行
  • 逻辑内聚：完成逻辑上相关的一组任务
  • 偶然内聚(巧合内聚)：完成一组没有关系或松散关系的任务
    - 自下向上：低内聚 =》高内聚

• 耦合类型

  • 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的
  • 数据耦合：一组模块借助参数表传递简单数据
  • 标记耦合：一组模块通过参数表传递记录信息（数据结构）
  • 控制耦合：模块之间传递的信息中包含用于控制模块内部逻辑的信息
  • 外部耦合：一组模块都访问同一全局简单变量，而且不是通过参数表传递该全局变量的信息
  • 公共耦合：多个模块都访问同一个公共数据环境
  • 内部耦合：一个模块直接访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的内部，两个模块有部分程序代码重叠；一个模块有多个入口
  • 自上向下：高耦合 =》低耦合

• 模块的四个要素

  • 输入和输出：模块的输入来源和输出去向都是同一个调用者，即一个模块从调用者那儿取得输入，进行加工后再把输出返回调用者
  • 处理功能：指模块把输入转换成输出所做的工作
  • 内部数据：指仅供该模块本身引用的数据
  • 程序代码：指用来实现模块功能的程序

例5
以下关于软件系统模块结构设计的叙述中，正确的是（) 。
A:当模块扇出过大时，应把下级模块进一步分解为若干个子模块
B:当模块扇出过小时，应适当增加中间的控制模块
C:模块的扇入大，表示模块的复杂度较高
D:模块的扇入大，表示模块的复用程度高

解析：

• 扇出是指一个模块直接调用的下级模块的数目。如果一个模块的扇出过大，那么这个模块可能承担了过多的职责，这会导致模块的复杂度增加，维护困难。当模块扇出过大时，应把该模块进一步分解为若干个子模块，以降低模块的复杂度；A错误。
• 扇入是指一个模块被其他模块调用的次数。如果一个模块的扇入过大，那么这个模块可能被多个模块依赖，这会增加模块的复用程度。模块的扇入大，表示模块的复用程度高；D正确。
• 模块的扇入大并不表示模块的复杂度高，而是表示模块的复用程度高；C错误。
• 模块的扇出过小并不一定需要增加中间的控制模块，这取决于具体的系统设计和需求。B错误。

答案：D。

例6
内聚表示模块内部各部件之间的联系程度，（）是系统内聚度从高到低的排序。
A:通信内聚、瞬时内聚、过程内聚、逻辑内聚
B:功能内聚、瞬时内聚、顺序内聚、逻辑内聚
C:功能内聚、顺序内聚、瞬时内聚、逻辑内聚
D:功能内聚、瞬时内聚、过程内聚、逻辑内聚

解析
系统内聚度从高到低的排序：功能内聚、顺序内聚、通信内聚、过程内聚、顺势内聚、逻辑内聚、偶然内聚。
答案：C。

6 面向对象设计

6.1 基本过程

面向对象设计（Object-Oriented Design, OOD）是软件开发过程中的一个关键阶段，它紧随面向对象分析（Object-Oriented Analysis, OOA）之后，旨在将分析模型转化为具体的设计模型，以便于后续的编码实现。以下是面向对象设计的基本过程：

6.1.1 分析模型

在面向对象设计之前，首先需要进行面向对象分析，以理解系统的需求和功能。

• 用例模型：用例模型描述了系统的功能需求，通过用例图展示系统与外部参与者之间的交互。
• 分析模型（领域模型）：领域模型是对系统中关键概念和它们之间关系的抽象表示，通常以类图的形式展示。

6.1.2 设计师

设计师的任务是将分析模型转化为设计模型，确保系统的设计能够满足需求并支持后续的实现。

• 设计用例实现方案：针对每个用例，设计师需要设计具体的实现方案，包括对象之间的交互和协作。
• 设计技术支撑实施：设计师需要考虑技术选型和架构设计，确保设计方案能够有效地实施。
• 设计用户界面：用户界面设计是面向对象设计的一部分，确保用户能够方便地与系统交互。
• 细化设计模型：在设计过程中，需要不断细化设计模型，确保每个类和对象的职责明确，关系清晰。

6.1.3 设计模型

设计模型是面向对象设计的最终产出，它包含了系统的详细设计信息，为编码实现提供指导。

• 架构图（用包图表示）：架构图展示了系统的整体结构，通常使用包图来表示各个模块和它们之间的关系。
• 用例实现图（用交互图表示）：用例实现图展示了用例的具体实现过程，通常使用交互图（如顺序图、协作图）来表示对象之间的交互。
• 类图（完整、精确）：类图是面向对象设计的核心，它展示了系统的类、属性和方法，以及类之间的关系。
• 其他（状态图、活动图等）：根据需要，还可以使用状态图、活动图等来补充设计模型，以更全面地描述系统的动态行为。

6.2 设计原则

• 单一职责原则：设计目的单一的类
• 开放-封闭原则：对扩展开放，对修改封闭
• 李氏(Liskov)替换原则：子类可以替换父类
• 依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程
• 接口隔离原则：使用多个专门的接口比使用单一的总接口要好
• 组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
• 迪米特(Demeter)原则（最少知识原则)：一个对象应当对其他对象有尽可能少的了解

例7
某网站系统在用户登录时使用数字校验码。为了增强安全性，现在要求在登录校验码中增加字母或图片。如果直接修改原有的生成登录校验码的程序代码，则违反了面向对象设计原则中的（）。
A:开闭原则
B:里氏替换原则
C:最少知识原则
D:组合复用原则

解析

• 开闭原则：对扩展开发，对修改关闭；
• 里氏替换原则（Liskov Substitution Principle, LSP）是指子类应该能够替换其基类并且不会影响程序的正确性；
• 最少知识原则（Least Knowledge Principle, LKP），也称为迪米特法则（Law of Demeter），是指一个对象应该对其他对象有尽可能少的了解；
• 组合复用原则（Composition Over Inheritance Principle）是指优先使用对象组合而不是类继承来实现代码复用。

答案：A。

例8
采用UML分析用户需求时，用例UC1可以出现在用例UC2出现的任何位置，那么UC1和UC2之间的关系是（ )。
A: include
B: extend
c: generalize
D: call

解析
在UML（统一建模语言）中，用例之间的关系主要有以下几种：

1. Include（包含关系）：表示一个用例（UC2）包含了另一个用例（UC1）。UC1是UC2的一部分，UC2的执行必然会触发UC1的执行。
2. Extend（扩展关系）：表示一个用例（UC1）扩展了另一个用例（UC2）。UC1可以在UC2的某个特定点插入执行，但UC2的执行并不一定会触发UC1的执行。
3. Generalize（泛化关系）：表示一个用例（UC1）是另一个用例（UC2）的泛化，即UC1是UC2的更一般化的版本。UC2是UC1的特化版本。
4. Call（调用关系）：在UML中，用例之间并没有明确的“call”关系。调用关系通常用于描述活动图中的活动之间的调用。
   根据题目描述，“用例UC1可以出现在用例UC2出现的任何位置”，这意味着UC1是UC2的一部分，UC2的执行必然会触发UC1的执行。这种关系符合Include（包含关系）的定义。
   因此，UC1和UC2之间的关系是Include（包含关系）

答案：A。

6.3 设计模式

• 架构模式：软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策
• 设计模式：主要关注软件系统的设计，与具体的实现语言无关
• 惯用法：是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用-计数就是C++语言中的一种惯用法

7 附录：思维导图