【软件系统架构设计】知识点汇总

明月出天山_

已于 2024-04-19 22:45:06 修改

阅读量2.7k

点赞数 20

分类专栏：软件架构设计软件工程文章标签：软件工程架构 uml

于 2024-04-17 00:10:57 首次发布

本文链接：https://blog.csdn.net/spicy_chicken123/article/details/135256501

版权

软件架构设计同时被 2 个专栏收录

4 篇文章

订阅专栏

软件工程

4 篇文章

订阅专栏

第一章系统分析与设计概述

信息系统概述

信息系统组成：
信息系统类型：
- 业务处理系统 TPS
- 管理信息系统 MIS
- 决策支持系统 DSS
- 专家系统 ES
- 办公自动化系统 OA
- 知识工作支持系统 KWS

信息系统软件

软件系统类型：应用软件、支撑软件（中间件）、系统软件
举例说明中间件软件的功能作用？

系统软件和用户应用软件之间连接的软件，搭建应用软件的环境，以便于软件各部件之间的沟通，如Tomcat

信息系统开发过程

信息系统生命周期：
各个阶段主要活动：
- 系统规划：明确问题，提出解决方案与建设计划，可行性分析，启动项目
- 系统需求分析：信息采集，定义需求，原型验证，划分优先级，需求规格说明
- 系统设计阶段：构件设计、系统架构设计、程序流程设计、数据库设计、用户界面与系统接口设计、网络环境设计、安全机制设计
- 系统构造阶段：系统集成、软件部署、程序编写、开发环境搭建、设备安装
- 系统测试阶段
- 系统运行和维护阶段
信息系统和软件系统的关系？信息系统生命周期和软件生命周期的关系？

信息系统范围更大，包含了软件系统；信息系统生命周期多了系统规划阶段

系统开发过程模型

瀑布开发过程模型：
- 严格开展，大量文档
- 组织简单，划分明确，大量文档工作，周期长，初期难以获得完整需求难以开展
- 适用需求明确规模小的项目
原型开发过程模型：
- 基于初始需求快速开发，下一版本迭代开发
- 速度快，反馈快，难以标记里程碑，管理复杂，稳定性有挑战
- 适用需求不明确，有大量人机交互的项目
螺旋式开发过程模型：
- 迭代式开发，兼顾原型和瀑布
- 引入风险分析，但是成本增加，项目管理更复杂
- 适用大型复杂的系统开发，特别强调风险分析
统一软件开发过程模型：
- 面向对象、用例驱动、以架构为中心
- 增量迭代开发，与UML配套
- 全面考虑，适用于大型复杂系统开发
敏捷软件开发模型：
- 轻量级开发，编程人员与业务专家紧密合作，注重人的作用，适应需求快速变更
- 注重系统快速开发，且适用于解决早期需求模糊或需求变更频繁的系统开发项目。
- 不适合大型系统开发
原型开发过程模型能解决瀑布开发过程模型的哪些问题？

用户参与度低、需求变更不明确、风险管理不足

系统开发方法与工具

系统开发方法：自行开发、委托开发、购买商品软件、联合开发
系统开发方法：结构化方法（面向过程）、面向对象开发方法、基于构件软件开发方法、面向服务的系统开发方法
系统开发工具：项目管理工具，版本控制管理工具，分析与设计工具，程序开发工具，系统测试工具，系统维护工具
系统开发环境是指在计算机硬件和系统软件平台上，进行信息系统开发及维护所使用的软件工具及集成环境。
系统运行环境是指信息系统运行所依赖的平台环境，包括操作系统软件、数据库软件、运行时软件等软件环境，以及服务器、网络设备、存储设备等硬件支持环境。

第二章面向对象建模语言

UML建模语言

用例图：包括系统用例图和业务用例图（业务用例图有斜线，区分系统用例图）
活动图
类图
顺序图、通信图：返回消息用虚线
- 边界类：圆圈左边一个横着的 T
- 控制类：圆圈加逆时针箭头
- 实体类：圆圈下面一条线
- 通信图：对象之间要有连接才能通信，连接用实线
状态机图
构件图
- 构件的画法：右上角有标识
- 接口和端口，接口之间的连接
- 依赖：半圆指向圆圈
- 代理连接：半圆伸出去实线
部署图
- 常见的构造型：<<subsystem>>、<<component>>
包图：包的画法：方框左上角加一个方框
对象图
构件图、包图和部署图一般是在系统分析与设计的哪个阶段使用？

系统设计
顺序图和通信图有什么联系与区别？

联系：都用于表示系统中对象之间的交互和消息传递。

区别：顺序图更关注对象之间消息的时序和顺序，用于展示交互的时间顺序和时序约束，通信图更关注对象之间的关系和交互。
类图与对象图有什么联系与区别？

类图可以看做是对象图的实例，用来表达各个对象在某一时刻的状态
类图在系统开发哪些阶段使用?

系统分析阶段和系统设计阶段

BPMN建模语言

模型元素

方块是活动（任务），圆圈是事件，菱形是网关

子流程有加号，代表复合活动
- 有黑点是终止事件，无黑点是无结束事件（流程结束，但不终止流程）
- 消息事件一个圈代表初次，两个圈代表后续
- 记忆：计时器事件、错误事件、升级事件
- 菱形里面没有东西是排他性网关，类似于流程图中的分支
- 有圆圈是包容性网关，都有可能
- 加号是并发执行网关，都要执行
- 有两个圆圈和一个五边形是基于事件的排他性网关
- 一个圆圈和一个五边形是开始一个流程的基于事件网关
- 一个圆圈一个十字是开始一个流程的基于事件并发网关
注意消息流要用虚线
业务模型通常有哪些模型图？它们作用是什么?
- 组织机构图：它描述了组织内部的结构，包括各个部门之间的关系和层级关系。它有助于理解组织内部的决策流程和责任分配。
- 业务流程图：它描述了组织内部的业务流程，包括各个步骤和环节。它有助于理解业务流程的运作方式，以及如何优化流程以提高效率。
- 业务协作过程图：它描述了组织内部各个部门之间如何协同工作以完成特定任务。它有助于理解组织内部的协作方式，以及如何改进协作以提高效率。
- 业务信息关系图：它描述了组织内部各个部门之间信息交换的方式和流程。它有助于理解信息交换的方式，以及如何优化信息交换以提高效率。

第三章系统规划

系统规划概述

为什么在信息系统建设前需要进行系统规划？

系统规划提供了机构信息化建设的基本纲领和总体指向。

系统规划是工程项目实施的前提与依据。

做好系统规划可避免盲目信息化建设给机构带来巨大的损失
系统规划主要解决什么问题？

根据组织机构使命及其战略目标，制定信息系统建设总体目标与愿景; 针对组织机构信息化需求，确定信息系统总体框架、技术路线与实施方案: 在充分考虑组织机构的技术、设备和人力资源等因素下，制定组织机构的信息系统实施建设项目计划，并分析评估信息系统建设方案可行性。

系统规划方法

业务系统规划法 BSP：
- 信息系统必须支持组织机构战略目标
- 系统规划应该表达出组织机构各个管理层次的信息化需求
- 信息系统应为各部门提供一致的数据信息
- 信息系统应适应机构管理体制的变化
- “自上而下”分析与“自下而上”设计相结合
业务流程重组法 BPR：
- 以客户服务为中心，优化业务流程。
- 跨部门业务流程重组优化。
- 以过程管理代替职能管理，取消不增值的管理环节。
- 取消不必要的信息处理环节，消除冗余信息集。
价值链分析法 VCA：
- 分析企业中的主要业务活动链
- 企业基本业务包括内部物流、产品生产、外部物流、产品销售、售后服务等环节。利用IT技术针对这些业务环节提供支持，促进它们对产品或服务产生更多价值。
战略目标集转移法 SST：
- 根据组织机构战略目标确定信息系统目标。
- 从组织机构战略集的支撑因素识别出相应信息系统战略约束。
- 根据信息系统目标和约束提出信息系统的建设战略。
关键成功因素法 KSF：
- 管理者可以根据机构目标确定关键成功因素，从中提取相应关键成功因素的关键绩效指标(Key Performance Indicator，KPI) 。
- 根据KPI指标评价管理工作成效，从而形成以调控行为成效为目标的反馈控制系统。
- 管理者就可以借助信息系统观测关键KPI指标而得知关键成功因素的状态，再通过关键成功因素状态调控来控制子目标的实现，进而促成机构目标的最终实现。
BPR方法适合于哪类组织机构的系统规划？

BPR方法适用于那些需要进行全面变革、彻底重构业务流程的组织机构。这种方法可以帮助组织重新设计和优化其业务流程，以实现更高效、更灵活和更有竞争力的运营模式

系统项目计划

项目工作分解 WBS：将项目工作按照交付成果方式，定义项目的详细任务过程。
任务活动排序：

画法：要有开始和结束，要有箭头
项目工期估算
- 三点估计法：项目经理或系统分析人员根据历史数据经验对某类任务活动的工期完成时间分别给出乐观时间（记为a）、悲观时间（记为b）和正常时间（记为m)。采用如下经验公式计算得到任务活动工期E。
  $E = (a + 4 m + b) /6$
- 德尔菲法：
项目成本估算与预算区别：
- 项目成本估算一般用于项目立项，先估算项目各任务成本，然后计算出项目总体费用。
- 项目预算则用于项目计划，它是将项目成本总经费在各活动任务上进行经费分配，以便后期作为项目成本控制管理的基准。
项目进度安排
- 项目任务网络中最长的一条路径称为关键路径，它决定了完成该项目的工期。关键路径上的每一项任务都是关键任务。这些任务的完成时间一旦有延迟，就会影响项目的完成时间。
- 甘特图方法
  - 前置任务：前置任务是指在一个任务前面必须完成另一个任务，即任务之间的先后顺序。在项目计划中，可以使用甘特图或网络图的方式来表示任务之间的前置关系。
  - 并行任务：有些任务可以同时进行，互不干扰，这时候可以将它们设置为并行任务。并行任务的好处是能够缩短项目的总时间，提高效率。
  - 里程碑任务：里程碑任务是项目中的重要节点，表示一个阶段的完成或者是整个项目的完成。里程碑任务可以作为项目管理的重要依据，帮助管理者及时发现和解决问题。
- PERT 图方法
甘特图与PERT图有何异同？

甘特图侧重展现流程，PERT图侧重展现依赖关系

项目可行性分析

包括：技术可行性分析，进度可行性分析，经济可行性分析，社会可行性分析等

第四章系统需求分析

需求采集

研究现有文档和系统：组织机构图，系统规划文档，工作规范文档，业务单据，报表，问题描述文档，领域专业知识，现有相关软件系统
与客户及相关人员进行面谈
问卷调查法：适合目标清晰、业务简单的项目
观察法
头脑风暴法
原型法：
- 进化式原型：逐渐演化，要求稳定性、可拓展性
- 抛弃式原型：达到目的后抛弃，代价少，适合解决需求不确定性，减少风险，可以帮助用户和开发者激发需求
- 开发过程：
快速应用开发 RAD：融合进化型原型法和头脑风暴法
快速应用开发与原型法在需求获取中有何异同？

相同点：都可以用于项目初期需求不明确的时候使用。

不同点：快速应用开发是头脑风暴法与进化式原型开发的结合。而原型法有进化式和抛弃式两种。
下列哪些系统适合抛弃式原型开发实现？哪些系统适合进化式原型开发实现？
- 全自动洗衣机控制系统
- 网上学习系统
- 人力资源管理系统
抛弃式，进化式，进化式

可视化需求建模

业务流程建模：
- 普通流程建模：包含私有业务流程（单泳池）和公开业务流程（多泳池）
- 合作流程建模：通常包含两个或更多泳池
- 编排流程建模：无泳池
业务用例建模：UML业务用例图
系统用例图：UML用例图，用例规约：写名称、简介、参与者、前置条件、基本流程、备选流程、后置条件
活动图建模
分析类图建模：
- 从问题领域抽取类：用例驱动、名词短语方法抽取类、公共类模式方法、CRC方法
- 定义类名及其属性
- 建模类之间的关系：关联、依赖、泛化、聚合、组合等
业务建模与系统需求建模是什么关系？

业务建模是系统需求建模的基础，两者相互关联
针对用例图中的各功能用例，如何进一步描述内部的处理要求？

用例规约表、活动图
用例图、活动图和分析类图分别描述系统需求的什么内容？

用例图：系统的功能需求

活动图：系统的业务流程流程

分析类图：系统的结构，系统中类之间的关系

需求文档化

功能性需求
非功能性需求：性能需求、可靠性需求等
- 性能需求：响应时间、吞吐量、并发用户数、资源利用率等
接口需求：
- 用户接口（命令行还是图形用户界面）
- 软件接口：调用API服务接口
- 硬件接口：设备驱动、接插件标准
- 通信接口：局域网通信协议、蓝牙4.0协议、WiFi协议等

需求管理

需求管理内容：当需求数目比较少时，采用需求依赖矩阵是一种发现需求矛盾或需求重叠的有效技术方法。
需求变更管理
需求风险分析与优先级
需求变更对于项目有哪种风险？

项目工作量增加，项目延期，项目成本增加，降低项目质量
如何对需求变更过程控制进行有效管理？

采用需求变更管理工具
银行ATM机系统有哪些功能需求？哪些非功能需求？

功能需求：登录、存款、取款、查询余额、转账、打印凭条

非功能需求：性能需求、可靠性、易用性、安全性、可维护性等

第五章系统架构设计

系统设计概述

系统设计过程：
系统设计基本方法：
- 抽象化：抽象过程是指从特殊对象到一般对象建立反映事物本质要素的过程。上层概念是对下层概念的抽象。通过抽象可实现系统全局建模描述。抽象使得设计者能在宏观层面描述过程和数据，不需被低层细节所困扰。
- 逐步求精：逐步求精是将把问题的求解过程分解成若干步骤或阶段进行，每步处理都比前步处理更加精化，更接近问题的解法。
- 模块化
- 信息隐藏
- 模块独立
系统设计方法分类：
抽象设计与逐步求精是什么关系?

抽象设计使得设计者能在宏观层面描述过程和数据而忽略低层的细节，逐步求精有助于设计者在微观层面设计低层技术细节。
在面向对象开发中，系统设计模型与系统分析模型如何联系?

分析与设计是无缝迭代过程，系统设计模型是在系统分析模型的基础上，对新建系统进行设计与具化的建模过程

系统架构基础

系统架构类型：
系统总体架构是从全局层面给出系统各种组成要素之间结构关系。它通常包括基础设施、运行平台、应用软件、业务部门、信息数据以及用户等。
- 要有系统管理，各种应用的平台，对应的各种管理
- 网站CMS管理：统计查询、站点导航、交互设计、缓存优化等
- 最下面是系统接口和底层服务
系统拓扑结构是指从系统基础设施平台层面描述节点与节点之间的通信连接关系。节点是指系统中处理逻辑相对独立的物理实体，如PC计算机、服务器、外围设备等。
- 服务器一般有web服务器，数据库服务器，应用服务器，DNS服务器
- 还可以有缓存服务器，系统备份服务器等
系统拓扑结构设计是从系统基础设施平台层面给出系统节点在网络环境中的结构关系，包括节点分布、节点类型、节点运行环境以及节点之间的通信联系。

基本类型：总线型、树型、星型、网状型、混合型
系统数据架构是指从数据管理视角所描述的系统架构，它通常用来反映各类数据咨源的组织与存储。系统数据架构不仅需要反映机构的数据结点分布关系。还需要考虑数据资源的存储结构与存储方式，如文件存储、数据库存储或数据仓库存储
- 系统数据分层架构设计：在大数据应用系统中，按照数据不同处理要求，可以将它们组织到不同层次的数据管理系统进行计算与分析处理。
  
  数据源+数据集成+文件存储+数据存储+编程模型+数据分析
- 系统数据治理架构设计：在信息系统中，一般是按照业务管理的数据治理需求，将数据资源部署到不同业务部门系统服务器进行数据访问与权限管理。系统数据治理架构与组织机构的数据管理职能有直接关系。
- 系统数据存储架构设计：在信息系统中，一些数据资源需要采用文件系统存储，另外一些数据资源需要采用数据库系统存储，还有一些数据资源则需要数据仓库系统进行数据存储。每类存储系统在设计上需要满足应用需求，如支持高可用、高性能的存取访问。
系统应用架构是指从应用功能视角所描述的系统架构。系统应用架构关注立用功能划分、应用功能配置、服务访问、服务管理等要素。
- 企业级应用架构：在企业信息化全局层面，系统应用架构起到了统一规划、承上启下的作用，向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。一般在系统规划阶段设计。
- 系统应用架构：在开发单个信息系统时，设计系统的应用功能结构，并考虑系统各个层次的功能结构组成，如前端展示层、业务处理逻辑层、数据访问层的功能模块结构。一般在系统开发阶段设计。
- 系统管理包括：权限管理、日志管理、备份管理、数据管理等
- 应用支持平台可以有云计算平台、大数据引擎、消息队列、搜索引擎、动态加载等
软件体系架构（简称软件架构）是一种从软件视角所描述的系统架构，它对软件系统的结构、行为进行高层抽象，一般通过构件、连接件、配置、端口、角色等图符元素进行描述。
- 从上到下：展示层、业务层、数据层（数据处理层、数据存储层）、运行环境
如何理解系统架构？系统架构对信息系统有何影响？
系统架构是指软件系统的组织结构，它确定了系统中的各个元素之间的关系和组织结构。

系统架构对信息系统的影响主要体现在以下几个方面：
- 确定系统的组成和结构：系统架构明确了系统的各个组成部分以及它们之间的关系，以及系统的整体结构。
- 指导系统设计：系统架构是系统设计的基础，它为系统的开发、维护和扩展提供了指导和框架。
- 确定系统功能：系统架构明确了系统的功能和职责，以及各个组成部分的功能和职责。
- 影响系统性能：系统架构对系统的性能有很大的影响，不同的架构可能会导致不同的性能表现。
- 约束系统开发：系统架构对系统的开发有一定的约束，它规定了系统的开发方式、开发工具和技术选择等方面的要求。
为什么系统架构需要从多个视角进行描述？
1. 不同的视角可以反映系统的不同方面，有助于全面理解系统。
2. 从多个视角进行描述可以提高系统的可读性和可维护性，有助于团队成员之间的沟通和协作。
3. 从多个视角进行描述可以帮助团队更好地理解系统的质量属性，如性能、可靠性、安全性等，从而更好地满足业务需求
哪种系统拓扑架构适合电子商务平台系统？

混合型
针对具有高可用性的信息系统，采用什么数据架构更合适？

数据治理架构
软件架构与系统架构有何不同?

软件架构是关注软件系统内部组件的结构和行为，定义了系统的整体框架和组件之间的协作方式。

系统架构则更广义，包括软件、硬件和网络等多个组成部分的设计和组织，考虑整个计算机系统的结构和互动关系。软件架构是系统架构的一部分

软件架构风格

软件架构风格是指针对不同系统共性问题提供一般性可重用的软件架构解决方案，它反映了领域中众多系统所共有的软件结构及其模式。

分层体系架构：采用层次化方式组织功能构件，每一层都是为上一层提供服务，并使用下一层提供的功能服务。
- 优点：设计简化，系统结构清晰；支持拓展设计；只要提供接口就可以功能复用
- 缺点：层次划分没有统一的方法，层次过多系统性能降低，层内部耦合拓展困难
数据共享体系架构：一种以数据存储服务器为中心，为客户软件提供数据共享、数据交换访问的软件架构风格。在数据共享体系架构中，各个客户软件相互独立，它们通过共享数据存储实现数据交换。一个客户软件对共享数据进行了修改，其他客户软件可以获得数据变更信息。
- 优点：体系架构简单开发容易；有效实现大量数据共享；客户软件独立执行
- 缺点：共享数据结构发生变化，客户软件都要跟着变；共享数据性能压力大；一旦故障整个系统无法运行；分布式困难
事件驱动体系架构：基于事件与消息机制实现软件构件之间进行通信的软件架构。构件（子系统)之间并不直接交互，而是通过触发一个或多个事件，隐式调用另一构件执行。系统各构件需要在消息处理器中注册相关事件，一旦事件触发，将隐含调用注册构件进行处理，并将处理结果返回事件发布构件。
- 优点：可拓展性好，便于维护，耦合性低
- 缺点：削弱了构件对系统的控制能力，不能高效解决数据交换问题
客户机/服务器体系架构（C/S架构和B/S架构）：一种典型的分布系统体系架构，其软件分为客户端构件和服务端构件，客户端构件通常在客户机上运行，服务端构件在服务器上运行。
- C/S架构优点:
  - 可实现分布式计算处理，有利于系统负载分担。
  - 交互性强、具有安全的存取模式、响应速度快、利于处理大量数据。
- C/S架构缺点:
  - 缺少通用性，系统维护、升级需要重新安装部署，增加了维护和管理的难度。
  - 只限于小型的局域网应用。
- B/S架构优点:
  - 分布性强——服务器可以在任何地点运行。
  - 访问方便——只要有网络、浏览器，就可以对系统应用进行访问。
  - 系统处理负载能力强——可以将负载分布在Web服务器、应用服务器、数据库服务器处理。此外，通过负载均衡、集群技术可以支持更大负载处理。
  - 系统运维方便——只需要在服务器进行功能修改与发布，即可实现所有用户访问的同步更新。
  - 用户共享性强——可以支持不同地点用户共享访问系统。
- B/S架构缺点:
  - 个性化处理、人机交互性能不如C/S架构软件。
  - 在系统安全性设计需要考虑更多内容。
微核体系架构：又称为“插件架构”，系统基本核心功能在软件内核中实现，其功能较少，系统大部分功能和业务逻辑都通过插件实现。
- 优点：良好的拓展性，插件之间是隔离的，可定制性高，可以渐进式开发
- 缺点：伸缩性差不易分布式，开发难度高
微服务架构：面向服务架构( service-oriented architecture，SOA）的轻量级实现版本。
- 优点：拓展性好，容易部署，容易开发，易于测试
- 缺点：服务可能会拆分得很细。这导致系统依赖大量的微服务，变得凌乱和笨重，性能不佳；分布式处理使得微服务较难实现原子性操作，交易回滚会比较困难。

软件架构模式

软件架构模式就是针对特定需求问题及其环境，所给出通用的软件架构设计解决方案。软件架构模式相对软件架构风格，所涉及范围要窄些，解决更具体问题。
代理者模式
- 在代理者模式的软件架构中，需要使用代理者扮演客户端和服务端的中介角色。
- 代理者使得客户端不再需要知道某个服务在哪里，就可以获得这个服务，从而使得客户端可以方便地定位服务。
集中式控制模式
- 在集中式控制模式的软件架构中，中央控制构件按照特定对象状态机逻辑对系统全局行为进行控制操作。
- 中央控制构件接收输入构件或用户界面构件的输入操作。
- 中央控制构件根据输入事件引发的系统状态变迁，对相关部件实施操作控制，从而实现系统功能控制。
分布式控制模式
- 在分布式控制模式的软件架构中，系统控制分布在多个控制构件之中，不存在总控全局的单一构件。
- 每个控制构件按照特定对象状态机逻辑对系统特定部分的行为进行控制操作。
- 多个控制构件通过消息通信协作完成整个系统的控制处理。
多层控制模式
- 在多层控制模式的软件架构中，系统控制分布在多个控制构件之中，此外，通过协调者构件控制所有控制构件实现整个系统的控制。
- 协调者构件提供全局控制，而每个控制构件按照特定对象状态机逻辑对系统特定部分的行为进行控制操作。
- 协调者控件发布命令到各个控制构件执行控制操作，同时协调者控件也从控制构件接收状态消息。
抽象分层模式
- 在抽象分层模式的软件架构中，复杂的软件构件关系被抽象到不同的功能层次。
- 每个层次构件只能访问它的相邻下层服务同时也只对相邻的上层提供服务。
- 相邻上下层次构件之间通过请求调用访问、返回响应消息方式进行交互实现系统功能处理。
多客户/单服务模式
- 在多客户/单服务模式的软件架构中，软件构件被部署到多个客户端结点和一个服务端结点。
- 各客户端结点的软件构件通过网络连接访问服务端结点上运行的服务。
- 在本模式下，多个客户端构件可并发向一个服务端构件提出服务请求，服务端构件一次将处理结果返回给请求的客户端构件。
多客户/多服务模式
- 在多客户/多服务模式的软件架构中，软件构件被部署到多个客户端结点和多个服务端结点上运行。
- 客户端构件通过网络连接访问多个服务器结点上运行的服务。
- 在本模式下，多个客户端构件可并发向多个服务端构件提出服务请求，服务端构件各自将处理结果返回给请求的客户端构件。
多层客户/服务模式
- 在多层客户/服务模式的软件架构中，除了基本的客户端层次和服务端层次外，还有一个同时扮演客户端角色和服务端角色的中间层。
- 中间层对于它的服务层而言是一个客户端，但对其他客户端而言又是一个服务端。
- 客户端、中间层、服务端的结点通过网络进行通信，支持多个客户端构件向服务端构件提出服务请求，服务端构件将处理结果返回给请求的客户端构件。
软件架构通信模式关注构件之间通信的方式。典型的软件架构通信模式如下:
- 调用/返回模式
- 异步消息通信模式、同步消息通信模式
- 服务注册、转发、发现模式
- 广播/组播模式
软件架构事务模式关注构件之间的事务处理，以确保业务数据完整性。典型的软件架构事务模式如下:
- 两阶段提交协议模式
- 复合事务模式
- 长事务模式
软件架构模式与软件架构风格有何区别?

软件架构模式强调解决某种特定场景、特定问题的架构模式，而软件架构风格强调解决某一类型问题的架构表现方式，是概念层面上的、抽象的。
代理者模式如何解决客户端透明访问服务的问题?

代理者扮演客户端和服务端的中介角色，使客户端不再需要知道某个服务在哪里就可以获得这个服务，从而实现客户端透明访问服务
集中式控制模式与分布式控制模式各有哪些优缺点?

集中式控制模式：简单好管理，一致性高，成本低，但是有单点故障风险，可拓展性差。

分布式控制模式：容错性强，可拓展性好，但是复杂，成本高，一致性不好保障。
哪种通信模式的软件架构适合高并发访问系统?

异步消息通信模式、服务注册、转发、发现通信模式

软件架构UML建模设计

UML设计类图：在面向对象系统设计中，采用UML设计类图模型将软件系统的类程序组成静态结构可视化呈现出来。
UML包图：针对各个子系统，分别给出它们的类图设计，但在高层设计中采用UML包图对系统的软件静态结构进行抽象设计。
通信图/顺序图：在UML软件建模设计中，可以采用交互图（通信图或顺序图）描述软件对象之间的协作通信，从而反映对象之间通过动态消息交互行为实现系统功能。
软件架构的物理结构模型：软件架构的物理结构模型用于反映软件系统架构的实现方案。在面向对象系统设计中，软件架构采用UML构件图和UML部署图表示系统物理结构实现方案。

第六章上软件建模详细设计

软件建模详细设计原则

开闭原则：软件实体（类、构件等）应该对功能扩展具有开放性，对代码修改具有封闭性。当应用需求改变时，在不修改软件实体源代码的前提下，就可以扩展模块的功能，使其满足新的需求。
里氏替换原则：子类可以扩展基类的功能，但不能改变基类原有的功能。子类在继承基类时，除了添加新的方法且完成新增功能外，不要重写基类的方法代码。子类必须遵守基类与外部类之间的隐含约定。
依赖倒置原则：基于抽象类编程，不依赖具体类编程。面向接口编程，不要面向实现编程。
接口分离原则：一个构件对外应提供不同服务的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的构件去调用，避免客户端依赖不必要的接口方法。提供者构件应该为每个不同访问构件类型提供一个特定的接口。
单一职责原则：一个类应该有且仅有一个功能职责，否则该类应该被拆分。单一职责原则的核心就是控制类的粒度大小，将对象解耦，提高其内聚性。
最少知识原则：迪米特法则的定义是:只与你的朋友交谈，不跟“陌生人”说话。在程序设计中，如果两个软件实体没有直接关系，那么就个直接调用，可以通过第三方转发该调用。
高内聚原则
松耦合原则
可重用原则

UML软件静态结构视图建模

类的聚合关系细分：
- 专属聚合：依赖性、传递性、非对称性、固定性
- 从属聚合：依赖性、传递性、非对称性
- 拥有聚合：传递性、非对称性
- 成员聚合：四个性质都不存在，仅仅是将一组对象组合在一起
实现继承：
- 拓展继承：子类组合来自超类的特征，并增加新的特征
- 限制继承：子类组合来自超类的特征，并重载部分继承来的特征
- 方便继承：某些类之间具有一定相似的实现，但它们之间不存在泛化关系，即没有概念上的分类关系。方便继承是指将它们中一个类作为其它类的超类。
高级类图建模：
- 可见性：
  - + public公共可见性:该元素对任何类都可见
  - - private私有可见性:该元素只对本类可见;
  - # protected保护可见性:该元素对本类及子类可见;
  - ~ package包可见性:该元素对同一包中的元素可见。
- 导出信息
- 限定关联
- 关联类与具体化类
接口与抽象类：
- 接口用于定义一个类或者构件的功能操作函数集。
- 如果接口使用构造型标签表示，实现关系线是一条末端带有空心三角的虚线，箭头指向接口，虚线上可以加上构造型关键字《implement》。
- 抽象类指不具有实例的类，它通常作为父类，不创建实例对象。抽象类的子类可以实例化。
- 抽象类一般至少有一个抽象操作。
- 抽象类的作用是为其子类描述它们的公共属性和行为。
- UML采用斜体表示抽象类的名称，也可以可使用{abstract}约束来表示。
类内聚与耦合：
- 类耦合的种类：
  - X包含Y，或者X有一个属性指向Y的一个实例
  - X有一个方法引用了Y的一个实例，如:X使用一个Y类型的局部变量;或者返回Y类型的对象
  - X调用Y的服务
  - X是Y的直接或间接子类
  - X类具有一个输入参数为Y类实例的对象
  - Y类是一个接口，而X类实现了该接口
- 类之间6种关系的耦合强度依次增强：依赖<关联<聚合<组合<继承<实现
为什么在软件功能模块中的类之间必然存在耦合?

因为存在实现、继承等关系，对象之间必然合作，类耦合也必然存在
在软件模块详细设计中，什么情况下使用抽象类?什么情况下使用接口?

使用抽象类是为了代码的复用，而使用接口的动机是为了实现多态性。

抽象类适合用来定义某个领域的固有属性，也就是本质，接口适合用来定义某个领域的扩展功能。当几个类需要协作完成特定功能，却又互相没有联系，实现一个相同的规范时使用接口

UML软件动态交互视图建模

顺序图
通信图
类操作：在UML中，类操作的表示语法为:
[可见性] 操作名称 [（参数表）] [:返回类型] [{属性字符串}]
顺序图高级交互技术
- 创建与销毁临时对象
- 片段：opt(if-then), alt(if-then-else), loop, para
- 交互引用：已处理逻辑

UML软件状态机视图建模

UML软件的实现视图建模

构件图：构件图是用来表示系统中构件与构件之间、构件与接口之间关系的图。构件图可以从多种层次粒度描述系统实现架构，如系统分解哪几个子系统，子系统包括哪些构件，构件由哪些类封装组成。
- 构件和构件之间的依赖关系
- 构件与接口之间的关系：
  - 构件与构件之间通过定义良好的接口进行协作。
  - 构件图中，构件之间的关系表现为依赖关系或实现关系。
  - 实现关系：指一个构件实现了一个接口，使用实线连接到小圆上。该接口被称为供给接口。
  - 依赖关系：指一个构件使用了一个接口，使用实线连接到半圆上。该接口被称为请求接口。
- 端口是指构件一个对外交互点。端口显示为一个小正方形，放置在构件方框的边界上。
- 端口连接：
  - 在UML软件架构建模设计中，主要使用如下连接器将构件的端口进行连接。
  - 装配连接器：用于连接构件之间的端口
  - 委托连接器：用于连接构件供给端口与内部供给端口或内部请求端口与构件请求端口
部署图：对系统的物理实现情况进行建模
- 节点：节点是指人工制品和构件在系统中部署的硬件设备及其运行环境。节点之间通过通信线路将连接起来实现信息传输。
- 构件需要在节点中进行部署
包图：包图用于对模型自身组织进行建模，它是由一系列模型元素（类、用例等)构成的包所组成的模型，描述包与包之间的关系。
- 包与包之间可以存在依赖关系。两个包之间存在着依赖关系通常是指这两个包所包含的模型元素之间存在着一个或多个依赖关系。
- 包的依赖关系使用一根虚线箭线表示，箭头指向被依赖的包。依赖关系可以标上标签，在《》中包含依赖关系的类型。

第六章下设计模式

设计模式类型：

创造模式：与对象创建有关，提供一种创建对象而隐藏创建逻辑，给出灵活创建对象的解决方案，典型模式有5种。
结构模式：处理类或对象的组合，给出利用继承、接口组合对象以获得新功能的解决方案，典型模式有7种。
行为模式：用于描述对象之间协作完成特定功能及其职责分配，给出对象之间通信的解决方案，典型模式有11种。

单例模式

单例模式是一种创建型设计模式，它确保一个类只有一个实例，并提供了一个全局访问点来访问该实例。

饿汉式单例类：在单例类被加载时候，就实例化一个对象交给自己的引用。

public class Singleton {  
    private static Singleton instance = new Singleton();  
    private Singleton (){}  
    public static Singleton getInstance() {  
    return instance;  
    }  
}

懒汉式单例类：在访问实例对象时才实例化对象。

public class Singleton {  
    private static Singleton instance;  
    private Singleton (){}  
    public static synchronized Singleton getInstance() {  
        if (instance == null) {  
            instance = new Singleton();  
        }  
        return instance;  
    }  
}

适配器模式

适配器模式（Adapter Pattern）是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。

这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。

桥接模式

桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。

责任链模式

责任链模式（Chain of Responsibility Pattern）为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。

中介者模式

中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。

第七章用户界面设计

用户界面设计概述

用户界面设计内容：
- 界面结构设计：对用户界面系统的组成结构与控制关系进行设计。通过设计的界面结构图可以将系统所有的屏幕界面、表格和报表等组成元素联系起来，展示出系统的界面组织结构。
- 界面交互设计：对用户实现功能操作的交互过程进行设计。信息系统功能服务通常需要用户通过操作来完成。用户在功能操作中需要与系统界面进行交互才能实现功能处理。因此，在设计用户界面时，需要针对每个功能的执行，给出交互逻辑设计。
- 界面导航设计：在用户界面导航设计中，需要采用导航机制来帮助用户定位，告诉用户“从哪里来”、“现在在哪里”、“可以去哪”。
- 界面视觉设计：在用户界面中通过使用恰当的视觉要素 (如色彩、文字、图片、空间) 满足用户功能需求和心理需求
- 界面布局设计：对界面内各元素的位置安排与分布来呈现内容。界面布局的目标是提高用户兴趣、方便用户操作。用户界面中布局方式直接影响着使用者视觉和操作两方面的用户体验。
用户界面设计流程：
在用户界面设计中，如何满足易用性特性?

简洁清晰，符合用户习惯，操作简单，有明确的提示和反馈，优化布局和排版，保持一致性
在用户界面设计中，如何满足用户个性化特性?

提供个性化选项，自适应设计
系统界面结构与系统功能结构有何联系?

系统界面结构是系统功能结构的外在表现。系统功能结构决定了系统界面结构
如何进行用户界面的交互设计?

了解用户需求，明确设计目标，根据用户反馈不断迭代优化
举例说明Web系统有哪些页面导航逻辑?

顶部导航栏、底部导航、侧边栏导航、水平栏目导航、垂直栏目导航、混合栏目导航、页面内容导航

Web系统GUI设计

总体页面结构设计：线性结构、分层结构、网络结构

分层结构：Web系统的页面结构除了在垂直方向上支持控制流程外，还可以在水平方向实现控制流程

网络结构：页面之间除了上下左右有关联外，还有跨层连接
页面布局设计
- 一栏式页面布局：
- 两栏式页面布局：
- 三栏式页面布局
页面导航设计：
- 水平栏目导航：在页面头部区域版块中，采用水平栏目导航主菜单，实现功能页面一级导航。在一级菜单下，还可以扩展二级菜单。
- 垂直栏目导航：在页面的左侧区域垂直给出主菜单栏目，它们实现功能页面一级导航，也可扩展二级导航。
- 混合栏目导航：混合栏目导航同时在页面的顶部区域和左侧区域给出栏目导航菜单
- 页面内容导航方式：面包屑导航、超链导航、Tab标签导航等
导航机制是指Web系统提供的页面导航元素及使能方式。

典型的页面导航元素有NavMenu导航菜单、Breadcrumb (面包屑) 导航链接、Tab导航标签、超文本导航链接、导航面板等。

导航使能方式通常为用户在导航元素上触发的事件，如鼠标点击或快捷按键操作。当事件出现后，根据导航元素关联的链接进行页面跳转。
导航语义是指用户完成系统一个功能操作的页面导航流程。
页面输入设计：文本输入框、复选框、单选按钮、列表框、文件域、按钮等控件
页面输出设计：在任何信息系统中，结果数据输出都是信息系统应提供的基本功能。无论是在屏幕显示、报告打印、音视频呈现，还是数据文件输出，它们均可为用户提供结果数据输出服务。
Web系统界面导航与桌面软件界面导航有哪些不同?

导航方式：Web 系统通常使用菜单栏、侧边栏或标签页等方式实现导航，用户通过点击链接或选项来切换页面或执行操作。而桌面软件界面通常使用菜单栏、工具栏、工作区等方式进行导航和操作，用户通过鼠标点击、拖拽或快捷键等方式来进行交互。

可见性：在 Web 系统中，导航通常以固定的位置显示在页面上，用户可以随时看到并进行操作。而在桌面软件界面中，导航可能会隐藏在菜单栏或工具栏中，需要用户主动点击或悬停才能展开或显示出来。

层级结构：Web 系统页面导航通常具有更明显的层级结构，通过菜单或侧边栏的嵌套关系来表示不同功能或页面之间的层级关系。而桌面软件界面导航在布局上可能更加自由，功能模块和工具可以根据需要自由排列和组织。

响应性和适应性：由于 Web 系统需要适应不同屏幕尺寸和设备类型，导航通常需要具备响应式设计，可以在不同设备上提供一致的用户体验。而桌面软件界面通常只需要适应不同分辨率的显示器，并且可以更充分地利用屏幕空间。
如何对表单输入数据进行校验?

编写脚本检验输入数据的完整性、格式、数字、一致性

移动APP软件GUI设计

总体界面结构：在移动 App 软件 GUI开发中，首先需要设计系统总体界面结构，将 App 各个界面按照一定结构（如思维导图）组织起来，让用户了解 App 功能界面结构。
界面布局设计：移动 App 界面布局设计是指在 App 界面中对内容文字、表格、图形、图像、视频等元素进行版面排布设计。它需要对界面主题内容、界面信息展示形式、用户行为心理、用户功能操作灵便性等方面进行整体考虑。
界面导航设计：界面导航是移动 App 用户界面中不可缺少的组成部分，它们引导用户抵达目标界面。移动 App 用户界面导航主要有标签导航、宫格导航、列表导航、抽屉式导航、轮播导航等多种形式。
- 底部标签导航：位于界面底部，采用文字加图标的方式展现
- 顶部+底部双标签导航：腾讯新闻，下面是新闻、视频、关注、我的；上面是要闻、国际、娱乐、体育、军事等（细化新闻）
- 舵式标签导航：舵式标签导航可以看为底部标签式导航的一种变体。它在后者的基础上，强调了一个高频核心功能，并且放在中间。
- 宫格导航
- 列表导航：通常用于二级界面，不会默认展示任何实质内容。这种导航结构清晰，易于理解，能够帮助用户快速定位相应界面。
- 抽屉式导航：QQ点击头像会出现一个抽屉式导航：直播、会员、QQ钱包、相册、收藏、文件等
- 轮播导航：使用者可以向左或者向右滑动进行快速切换界面，比较适合界面层级较低的交互，几乎不需要进一步的交互。
移动App用户界面设计与Web系统用户界面设计有哪些不同?

移动app基于移动终端设备，需要面对不同于电脑端的操作系统，使用场景和触屏等硬件，同时其界面交互也应当考虑利用移动设备集成的各种传感器。
移动App总体界面结构如何组织?

使用方框和连接，构建导图，由总到分地组织页面结构
轮播导航适合哪些应用场景?

电商网站、新闻网站、企业网站
微信App采用了哪些导航方式?

底部标签导航：微信、通讯录、发现、我

列表导航：朋友圈、视频号、直播、扫一扫、摇一摇等

宫格导航：服务里面有金融理财、生活服务、交通服务等