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的关键技术】
- UDDI (Universal Description, Discovery, and Integration)
- 功能: 提供服务发布、查找和定位的方法。
- 作用: 帮助服务提供者发布其服务，并允许服务请求者查找和定位所需的服务。
2. WSDL (Web Services Description Language)
- 功能: 对服务进行描述的语言。
- 作用: 定义服务的接口、操作、消息格式等，使服务请求者能够理解和使用服务。
3. SOAP (Simple Object Access Protocol)
- 功能: 服务请求者和服务提供者之间的消息传输规范。
- 作用: 定义消息的格式和传输协议，确保服务请求者和服务提供者之间的可靠通信。
【Web Service应用系统的六大层次】
-
底层传输层
- 功能: 负责数据的物理传输。
- 协议: HTTP、HTTPS、SMTP等。
- 作用: 确保数据在网络中的可靠传输。
-
服务通信协议层
- 功能: 定义服务请求者和服务提供者之间的通信协议。
- 协议: SOAP、REST等。
- 作用: 确保服务请求者和服务提供者之间的消息交换符合规范。
-
服务描述层
- 功能: 描述服务的接口和操作。
- 语言: WSDL。
- 作用: 提供服务的详细描述，使服务请求者能够理解和使用服务。
-
服务层
- 功能: 实现具体的服务功能。
- 作用: 提供服务的具体实现，处理服务请求并返回结果。
-
业务流程层
- 功能: 定义和协调多个服务的执行顺序。
- 语言: BPEL (Business Process Execution Language)。
- 作用: 管理和协调多个服务的执行，实现复杂的业务流程。
-
服务注册层
- 功能: 提供服务的注册、查找和定位功能。
- 协议: 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)
-
能拆分的就拆分
- 特点: 微服务架构鼓励将系统拆分成多个独立的小服务，每个服务专注于一个特定的业务功能。
- 作用: 提高系统的灵活性和可扩展性。
-
纵向业务划分
- 特点: 微服务按照业务功能进行纵向划分，每个服务独立负责一个业务领域。
- 作用: 简化服务的管理和维护。
-
由单一组织负责
- 特点: 每个微服务通常由一个独立的团队负责开发、部署和维护。
- 作用: 提高团队的自主性和响应速度。
-
细粒度
- 特点: 微服务的粒度较细，通常只负责一个特定的业务功能。
- 作用: 提高服务的专注度和效率。
-
两句话可以解释明白
- 特点: 微服务的业务逻辑通常比较简单，可以用几句话解释清楚。
- 作用: 简化服务的理解和使用。
-
独立的子公司
- 特点: 微服务可以看作是独立的“子公司”，每个服务独立运行，互不干扰。
- 作用: 提高系统的可靠性和容错性。
-
组件小
- 特点: 微服务的组件通常较小，专注于一个特定的业务功能。
- 作用: 简化服务的开发和维护。
-
业务逻辑存在于每一个服务中
- 特点: 每个微服务包含自己的业务逻辑，独立完成特定的业务功能。
- 作用: 提高服务的独立性和可重用性。
-
使用轻量级的通信方式，如HTTP
- 特点: 微服务通常使用轻量级的通信协议，如HTTP/REST。
- 作用: 简化服务之间的通信和集成。
2.3.3.2 SOA (Service-Oriented Architecture)
-
是整体的，服务能放一起的都放一起
- 特点: SOA 倾向于将相关的服务组合在一起，形成一个整体的服务集合。
- 作用: 提高服务的集成度和协同工作能力。
-
是水平分多层
- 特点: SOA 通常按照功能层次进行水平划分，如数据层、业务逻辑层、表示层等。
- 作用: 提高系统的结构化和模块化。
-
按层级划分不同部门的组织负责
- 特点: SOA 的服务通常由不同部门的组织负责，每个部门负责一个特定的层次或功能。
- 作用: 提高组织的协作和分工。
-
粗粒度
- 特点: SOA 的服务粒度通常较粗，涵盖多个业务功能。
- 作用: 提高服务的覆盖范围和集成度。
-
几百字只相当于SOA的目录
- 特点: SOA 的业务逻辑通常比较复杂，需要较多的描述和解释。
- 作用: 提高服务的全面性和复杂性。
-
类似大公司里面划分了一些业务单元 (BU)
- 特点: SOA 的服务可以看作是大公司中的业务单元，每个单元负责一个特定的业务领域。
- 作用: 提高服务的组织性和管理性。
-
存在较复杂的组件
- 特点: SOA 的组件通常较复杂，涵盖多个业务功能。
- 作用: 提高服务的集成度和复杂性。
-
业务逻辑横跨多个业务领域
- 特点: SOA 的业务逻辑通常横跨多个业务领域，涉及多个服务之间的协作。
- 作用: 提高服务的全面性和复杂性。
-
企业服务总线(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 关键概念
-
Model (模型)
- 定义: 模型是对客观事物的抽象表示。
- 作用: 模型用于描述系统的结构、行为和功能，是软件开发的基础。
-
Architecture (架构)
- 定义: 架构是构成系统的部件、连接件及其约束规约。
- 作用: 架构定义了系统的整体结构和组件之间的关系，是系统设计的核心。
-
Model-Driven (模型驱动)
- 定义: 使用模型完成软件的分析、设计、构建、部署、维护等各开发活动。
- 作用: 通过模型驱动开发，提高软件开发的效率和质量。
-
MDA的起源
- 思想: 分离系统规约和平台实现的思想。
- 作用: 通过分离系统规约和平台实现，提高软件的可移植性和可重用性。
2.4.3 MDA的主要目标
-
Portability (可移植性)
- 定义: 软件能够在不同的平台上运行，而不需要进行大量的修改。
- 作用: 提高软件的可移植性，降低平台迁移的成本。
-
Interoperability (互通性)
- 定义: 软件能够与其他系统或组件进行无缝的通信和协作。
- 作用: 提高软件的互通性，促进系统集成和互操作。
-
Reusability (可重用性)
- 定义: 软件组件能够在不同的系统或项目中重复使用。
- 作用: 提高软件的可重用性，降低开发成本和时间。
2.4.3 MDA的3种核心模型
-
平台独立模型 (PIM)
- 定义: 具有高抽象层次、独立于任何实现技术的模型。
- 作用: PIM 描述系统的核心功能和结构，不依赖于具体的实现技术。
-
平台相关模型 (PSM)
- 定义: 为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。
- 作用: PIM 会被变换成一个或多个 PSM，每个 PSM 针对特定的实现技术进行优化。
-
代码 (Code)
- 定义: 用源代码对系统的描述（规约）。
- 作用: 每个 PSM 都将被变换成代码，最终生成可执行的软件系统。
2.4.4 MDA的开发流程
-
创建平台独立模型 (PIM)
- 步骤: 分析系统的功能和结构，创建高层次的抽象模型。
- 作用: 描述系统的核心功能和结构，不依赖于具体的实现技术。
-
转换为平台相关模型 (PSM)
- 步骤: 将 PIM 转换为针对特定实现技术的 PSM。
- 作用: 优化模型以适应特定的实现技术，提高系统的性能和效率。
-
生成代码
- 步骤: 将 PSM 转换为源代码。
- 作用: 生成可执行的软件系统，实现系统的功能和结构。
2.4.5 小结
MDA 是一种通过模型驱动软件开发的方法论，旨在提高软件的可移植性、互通性和可重用性。通过分离系统规约和平台实现，MDA 使用平台独立模型 (PIM)、平台相关模型 (PSM) 和代码生成，实现从高层次抽象到具体实现的转换。MDA 的核心目标是提高软件开发的效率和质量，降低开发成本和时间。
2.5 软件设计
- 软件设计包括体系结构设计、接口设计、数据设计和过程设计
- 结构设计：定义软件系统各主要部件之间的关系
- 数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性
- 接口设计（人机界面设计)：软件内部，软件和操作系统间以及软件和人之间如何通信
- 过程设计：系统结构部件转换成软件的过程描述
例1
软件设计包括了四个既独立又相互联系的活动：高质量的（）将改善程序结构和模块划分，降低过程复杂性；(）的主要目标是开发一个模块化的程序结构，并表示出模块间的控制关系；(）描述了软件与用户之间的交互关系。
A:程序设计
B:数据设计
C:算法设计
D:过程设计
A:软件结构设计
B:数据结构设计
C:数据流设计
D:分布式设计
A:数据架构设计
B:模块化设计
C:性能设计
D:人机界面设计
解析
- 高质量的（B:数据设计）将改善程序结构和模块划分，降低过程复杂性
- 数据设计: 数据设计关注的是如何组织和表示数据，包括数据结构、数据库设计等。高质量的数据设计能够改善程序的结构和模块划分，降低过程复杂性，提高代码的可读性和可维护性。
- （A:软件结构设计）的主要目标是开发一个模块化的程序结构，并表示出模块间的控制关系
- 软件结构设计: 软件结构设计关注的是如何将系统划分为模块，并定义模块之间的控制关系。其主要目标是开发一个模块化的程序结构，确保模块之间的低耦合和高内聚，提高系统的可维护性和可扩展性。
- （D:人机界面设计）描述了软件与用户之间的交互关系
- 人机界面设计: 人机界面设计关注的是如何设计用户与软件之间的交互界面，包括用户界面、交互流程、用户体验等。其主要目标是提供一个直观、易用、高效的交互界面，确保用户能够方便地使用软件。
答案：B 、A、D。
2.6 架构评估方法
2.6.1 概述
架构评估是确保系统设计满足需求和质量属性的关键步骤。常用的评估方法包括基于调查问卷（检查表）的方式、基于度量的方式、基于场景的方式。
- 基于调查问卷（检查表)的方式
- 基于度量的方式
- 基于场景的方式
2.6.1.1 基于调查问卷（检查表）的方式
概述: 基于调查问卷的方式通过向相关人员（如架构师、开发人员、测试人员等）发放问卷，收集他们对架构设计的意见和建议。
步骤:
- 设计问卷：根据评估目标设计一系列问题，涵盖架构的各个方面。
- 发放问卷：将问卷发放给相关人员，收集他们的反馈。
- 分析结果：汇总和分析问卷结果，识别架构设计中的问题和改进点。
优点:
- 简单易行，成本较低。
- 能够收集广泛的意见和建议。
缺点:
- 主观性强，依赖于问卷设计和参与者的经验。
- 难以量化评估结果。
2.6.1.2 基于度量的方式
概述: 基于度量的方式通过收集和分析架构设计的量化指标，评估架构的质量和性能。
步骤:
- 定义度量指标：根据评估目标定义一系列量化指标，如模块化程度、耦合度、内聚度等。
- 收集数据：通过工具或手动方式收集架构设计的相关数据。
- 分析数据：使用统计方法分析数据，评估架构的质量和性能。
优点:
- 客观性强，能够量化评估结果。
- 能够识别架构设计中的具体问题。
缺点:
- 需要定义和收集大量的度量指标，工作量较大。
- 度量指标的选择和定义可能存在主观性。
2.6.1.3 基于场景的方式
概述: 基于场景的方式通过描述系统在特定情况下的行为和响应，评估架构的适应性和可靠性。
场景: 场景是从风险承担者的角度与系统交互的简短描述，通常包括刺激、环境和响应三个方面。
步骤:
- 定义场景：根据评估目标定义一系列场景，描述系统在特定情况下的行为和响应。
- 分析场景：分析每个场景中的刺激、环境和响应，评估架构的适应性和可靠性。
- 改进架构：根据场景分析结果，改进架构设计，提高系统的适应性和可靠性。
优点:
- 能够模拟真实情况，评估架构的实际表现。
- 能够识别架构设计中的潜在问题。
缺点:
- 场景的定义和分析可能存在主观性。
- 需要定义和分析大量的场景，工作量较大。
2.6.2 场景的三个方面
-
刺激 (Stimulus)
- 定义: 场景中解释或描述项目干系人怎样引发与系统的交互部分。
- 作用: 描述系统在特定情况下的触发条件和交互方式。
-
环境 (Environment)
- 定义: 描述刺激发生时的情况。
- 作用: 描述系统在特定情况下的运行环境和条件。
-
响应 (Response)
- 定义: 系统是如何通过架构对刺激作出反应的。
- 作用: 描述系统在特定情况下的行为和响应，评估架构的适应性和可靠性。
2.6.4 SAAM (Software Architecture Analysis Method)
2.6.4.1 概述
SAAM 最初用于分析架构的可修改性，后来扩展到其他质量属性。
2.6.4.2 过程
-
形成场景
- 步骤: 根据评估目标定义一系列场景，描述系统在特定情况下的行为和响应。
- 作用: 为后续评估提供基础。
-
描述架构
- 步骤: 详细描述系统的架构设计，包括模块、组件、连接件等。
- 作用: 为场景分析提供架构基础。
-
对场景分类和确定优先级
- 步骤: 根据重要性和影响程度对场景进行分类和优先级排序。
- 作用: 确保重点场景得到优先评估。
-
对场景进行单个评估
- 步骤: 逐一评估每个场景，分析架构在特定情况下的表现。
- 作用: 识别架构设计中的具体问题。
-
评估场景的相互作用
- 步骤: 分析不同场景之间的相互作用，评估架构的整体表现。
- 作用: 确保架构能够应对复杂情况。
-
形成总体评价
- 步骤: 汇总所有评估结果，形成对架构设计的总体评价。
- 作用: 提供改进架构设计的建议。
2.6.5 ATAM (Architecture Tradeoff Analysis Method)
2.6.5.1 概述
ATAM 在 SAAM 的基础上发展起来，旨在揭示架构满足特定质量目标的情况，使架构设计师更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。主要针对性能、可用性、安全性和可修改性。
2.6.5.2 过程
-
描述和介绍阶段
- 步骤:
- 描述 ATAM 方法：介绍 ATAM 的评估过程和目标。
- 描述业务动机：解释系统的业务目标和动机。
- 描述架构：详细描述系统的架构设计。
- 作用: 为后续评估提供背景和基础。
- 步骤:
-
调查和分析阶段
- 步骤:
- 确定架构方法：识别和描述架构设计中使用的方法和策略。
- 生成质量属性效用树：创建一个树状结构，表示不同质量属性的重要性和优先级。
- 分析架构方法：评估架构方法对质量属性的影响。
- 作用: 深入分析架构设计，识别质量属性的权衡和冲突。
- 步骤:
-
测试场景
- 步骤:
- 讨论场景和对场景分级：讨论和分类场景，确定其优先级。
- 分析架构方法：评估架构方法在特定场景下的表现。
- 作用: 通过场景测试，评估架构的实际表现。
- 步骤:
-
报告阶段
- 步骤: 描述评估结果，包括架构的优点和缺点，以及改进建议。
- 作用: 提供改进架构设计的具体建议。
例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（统一建模语言）中，用例之间的关系主要有以下几种：
- Include（包含关系）：表示一个用例（UC2）包含了另一个用例（UC1）。UC1是UC2的一部分，UC2的执行必然会触发UC1的执行。
- Extend（扩展关系）：表示一个用例（UC1）扩展了另一个用例（UC2）。UC1可以在UC2的某个特定点插入执行，但UC2的执行并不一定会触发UC1的执行。
- Generalize（泛化关系）：表示一个用例（UC1）是另一个用例（UC2）的泛化，即UC1是UC2的更一般化的版本。UC2是UC1的特化版本。
- Call（调用关系）：在UML中，用例之间并没有明确的“call”关系。调用关系通常用于描述活动图中的活动之间的调用。
根据题目描述，“用例UC1可以出现在用例UC2出现的任何位置”，这意味着UC1是UC2的一部分，UC2的执行必然会触发UC1的执行。这种关系符合Include（包含关系）的定义。
因此，UC1和UC2之间的关系是Include（包含关系）答案：A。
6.3 设计模式
- 架构模式：软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策
- 设计模式：主要关注软件系统的设计，与具体的实现语言无关
- 惯用法：是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用-计数就是C++语言中的一种惯用法
7 附录：思维导图
