《软件架构设计教程》PPT课件

实例—考试系统的设计决策(1)
v生成试卷存在的问题：当超过50生成试卷遇到性能瓶颈：等待时间长，甚至产生的试卷不完整。v原因：生成试卷是对母卷进行随机的大题 交换、小题交换、备选答案交换等一系列 复杂运算实现，运行时间长，并发操作不 能太多。v解决方案：将试卷生成功能独立，提前一 个时间量先生成考试试卷，考生登录后直
实例—考试系统的设计决策(1)
v可用性考虑：考生年龄差异大、工作岗位 特殊、有的考生计算机应用水平很低，可 能无法输汉字。v方案： ①考生登录只输数字型考号，登录 后显示考生信息进行核实； ②客观题机考， 主观题可机考，也可笔试(通过投影仪显 示主观题)
实例—考试系统的设计决策(1)
v系统性能不影响考试进度和考生情绪。v前面1、2条的方案属于软件架构的内容， 因为它是考试系统设计必须遵循的原则。v性能问题难以估计，将逐步解决。
常见的分层架构设计
常见的5层逻辑架构
一、界面层v界面层通过指的是用户层或表现层。v为什么把界面层和界面控制层分开来介绍 (一般把界面层和界面控制层综合在一起， 统称为“显示层”)
常见的分层架构设计
二、界面控制层v该层包含以下功能：决定用户应该看到 什么，对路径进行导航，以及解释用户 的输入。v在Windows窗体的应用程序中，这些逻 辑指窗体后台的代码； Web窗体的应用 程序中，这些逻辑不仅仅指窗体后台的 代码，也包含服务器端控件的代码。
正确理解设计的含义
v业务需求是系统架构的决定性因素v软件设计和开发在架构确定之后开始进 行v开发是在设计的基础上进行的设计
正确理解设计的含义
架构
业务需求
开发
正确理解设计的含义
正确理解设计的含义
v表示层(User Interface layer-UI)v业务逻辑层(Business Logic Layer-BLL)v数据访问层(Data Access Layer-DAL)

1
SaaS架构设计
（2） 方案二：共享数据库，隔离数据架构
这是第二种方案，即多个或所有租户共享Database，但一个Tenant一个 Schema。 优点： 为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离 ； 每个数据库可以支持更多的租户数量。 缺点：如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租 户的数据； 如果需要跨租户统计数据，存在一定困难。
1
SaaS架构设计
（3） 方案三：共享数据库，共享数据架构
这是第三种方案，即租户共享同一个Database、同一个Schema，但在表中 通过TenantID区分租户的数据。这是共享程度最高、隔离级别最低的模式。 优点： 三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的 租户数量最多。 缺点：隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量 ； 数据备份和恢复最困难，需要逐表逐条备份和还原。 如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离 级别换取降低成本，这种方案最适合。
1）用户一般只关心应用软件，因为它直接为用户提供支持 ； 2）在网络环境中，中间件通常在服务器端发挥作用。
1
中间件技术
中间件在具体系统中的作用：银行系统的例子
1
中间件技术
中间件主要是用来 支持网络环境中软件实体之间的有效交互
“软件实体”是具有不同特征的软件模块 它们通常是具有不同粒度的软件构造模块 “有效”是指所支持的实体之间的交互 必须具有可靠、安全、快速等特点
1
SaaS架构的设计
这种方式解决了这样一个问题，那就是随着SaaS 服务供应商业务的发展和客 户的增多，只能通过提供更多的服务器资源来运行更多应用实例，现在SaaS 服务供应商可以用同样数量的服务器资源为更多的客户服务，从而比起前两 级成熟度模型的系统，更有效的利用了硬件资源，降低了运营成本。

用户
交互 界面
业务 应用
外部 框架
服务
领域 核心
资源 代理
外部 数据
核心层反映出「领域模型」
核心层的接口基本就是对此领域模型进行操作
为何要建立领域模型？ 1. 帮助接口设计 2. 帮助数据存储设计，梳理出更具有弹性的存储方式
精选课件
24
用户
交互 界面
业务 应用
外部 框架
服务
领域 核心
资源 代理
外部 数据
赖任何非公共系统。公共系统接口简单不易改变。公共系统没有独立成为一家公司运
作的可能。各个后台系统独立成为公司运营时，公共系统可以送给他们。
业务系统不允许在没有代理隔离的情况下调用其他系统，是因为其他系统以后都可能
会独立运作。
精选课件
21
七层架构详解
精选课件
22
用户
交互 界面
业务 应用
外部 框架
服务
前后端维度（X1..X7）：界面（红）、应
Y
用（橙）、框架（黄）、服务（绿）、
核心（蓝）、代理（靛）、数据（紫）
X
T
业务维度（Y1..Yn）：每个业务系统
Z
系统维度（Z1..Zn）：软件、容器、运行 时、操作系统、虚拟机、到硬件。跟行 业无关
时间维度（T1..Tn）：初始架构到成熟架
构
精选课件
15
X 座标
通讯协议与格式 负载均衡模块
分布式锁 搜索模块
数据库
精选课件
数据访问模块 Session模块 分布式文件
缓存模块
19
前 端
用户
优
化
界面
应
应用
用

架构设计实践
1
最佳实践原则
掌握软件架构设计的最佳实践原则。
2
常见的设计模式
了解常用的设计模式并应用于实际项目中。
3
性能优化和可扩展性
学习如何优化性能和提高系统的可扩展性。
架构演进和迁移
介绍架构演进和迁移的重要性，以及如何规划和执行架构演进计划。
案例分析和实例展示
通过实际案例分析，展示不同应用场景下的架构设计方案。
分布式架构解决大规模应用的性Fra bibliotek和可扩展性问题。
多层架构
分离关注点，提高代码复用性和可维护性。
微服务架构
提供可独立部署和扩展的小型服务。
容器化架构
什么是容器化？
介绍容器化的定义和优势。
Docker容器
学习如何使用Docker容器化应用 程序。
Kubernetes
了解如何使用Kubernetes管理容 器。
《高级软件架构设计》 PPT课件
本课程将带你深入了解高级软件架构设计的重要性和实践原则，同时介绍常 见的软件架构模式，以及如何优化性能和实现可扩展性。
课程介绍
了解课程目标和内容，掌握学习路径。
软件架构概述
介绍软件架构的定义、作用和基本概念。
常见的软件架构模式
单层架构
简单而直接，适用于小规模应用。

2.1.3 模式驱动的方法
模式驱动的体系结构设计方法从模式导出体系结构 抽象。软件设计模式的目的在于编制一套可重用的 基本原则，用于开发高质量的应用系统。体系结构 模式类似于设计模式，但它关心更粗粒度的系统结 构及其交互。
15
客户 需求规格说明书
通用知识 2：实现
体系结构模式 描述 意图
上下文
问题
解决方案
体系结构描述Biblioteka 4：组合3：应用 体系结构模式
图4 模式驱动的体系结构设计的概念模型
16
3. 系统的管理端业务处理模块
3.1 总的网络拓补结构
系统管理员
数据库 和
Web程序 都在这上
导师
导师
导师
17
3. 系统的管理端业务处理模块
在该系统中采用面向对
象分析作为主要的系统
建模方法，用不同的设
计角度描述角色（管理
有所不同。
3
客户
领域知识
捕捉需求 需求规格 说明书
提取解决方 案的结构
领域知识 工作
解决方案抽象
体系结构 规格说明
领域知识
体系结构
图1 体系结构设计方法的元模型 4
2.软件体系结构设计方法的分析
为了获取对体系结构设计的抽象，人们已经提出 了许多方法。
2.1 体系结构设计方法的分类
（1）工件驱动（Artifact-Driven）的方法 （2）用例驱动（Use-Case-Driven）的方法 （3）模式驱动（Pattern-Driven）的方法 （4）领域驱动（Domain-Driven）的方法
*
者）与系统的其它的 管理员
构件是如何联系的。管
管理端子系统 *
理端的主用例图如右图：

·装配的构件。装配的构件在安装前已经装配在操作系统、 数据库管理系统或信息系统不同层次上，使用胶水代码就可 以进行连接使用。目前一些软件商提供的大多数软件产品都 属于这一类。
·可修改的构件。可修改的构件可以进行版本替换。如果 对原构件修改错误、增加新功能，可以利用重新“包装”或 写接口来实现构件的替换。这种构件在应用系统开发中使用 的比较多。
13
第1章 软件重用与构件技术
图1-1 重用驱动的软件开发过程
14
第1章 软件重用与构件技术
应用者重用关心利用可重用构件来建立新系统，它包括 以下几个步骤：
(1) 寻找候选的可重用的构件，由它们来产生软件生命周 期每一阶段的交付。
(2) 对候选构件进行评价，选择那些适合于在本系统内重 用的构件。
10
第1章 软件重用与构件技术
1.1.3 重用驱动的软件过程 1．软件重用失败的原因 尽管软件产业从本质上是支持重用的，但到目前为止，
很少有成功实施重用的公司。主要原因有以下几点： (1) 缺乏对为什么要实施重用的了解。 (2) 认为重用没有创造性。 (3) 管理者没有对重用承担长期的责任和提供相应的支持。 (4) 没有支持重用的方法学。
(4) 根据构件重用时的形态，分为动态构件和静态构件。 动态构件是运行时可动态嵌入、链接的构件，如对象链接和 嵌入、动态链接库等；静态构件如源代码构件、系统分析构 件、设计构件和文档构件等。
23
第1章 软件重用与构件技术
(5) 根据构件的外部形态，将构成一个系统的构件分为以 下5类：
·独立而成熟的构件。独立而成熟的构件得到了实际运行 环境的多次检验，该类构件隐藏了所有接口，用户只需用规 定好的命令使用即可，例如数据库管理系统和操作系统等。

C(P1)> C(P2) 即问题P1的复杂度比P2高，则显然有：
E(P1)> E(P2) 即解决问题P1比P2所需的工作量大。
精选课件
9
第4章 软件结构设计 在人们解决问题的过程中，发现存在有另一个有趣的规律：
C(P1+P2)> C(P1)+C(P2) 即解决由多个问题复合而成的大问题的复杂度大于单独解决各 个问题的复杂度之和。也就是说，对于一个复杂问题，将其分 解成多个小问题分别解决比较容易。由此我们可以推出：
E(P1+P2)> E(P1)+E(P2) 即将复杂问题分解成若干个小问题，各个击破，所需要的工作 量小于直接解决复杂问题所需的工作量。
精选课件
10
第4章 软件结构设计
根据上面的推理，我们可以得到这样一个结论，模块化可 以降低解决问题的复杂度，从而降低软件开发的工作量。虽然 增加程序中的模块数可以降低开发每个模块的工作量，但同时 却增加了设计模块接口的工作量。通过图4.1所示的模块数与软 件开发成本的关系图中可以看出，当划分的模块数处于最小成 本区时，开发软件的总成本最低。
耦合是影响软件复杂度的一个重要因素，设计过程中应力 求降低程序的耦合性。在以上所介绍的耦合中，数据耦合的程 度最低，其次是公共耦合，再其次是控制耦合，程度最高的是 内容耦合。
精选课件
18
第4章 软件结构设计
2) 内聚性
内聚性是对一个模块内部各个组成元素之间相互结合的紧密 程度的度量指标。模块中组成元素结合的越紧密，模块的内聚性 就越高，模块的独立性也就越高。模块的内聚性和耦合性是两个 相互对立且又密切相关的概念。事实上，它们是同一事物的两个 方面，模块的高内聚性往往就意味着模块间的低耦合性。因为程 序中的各个部分必定是有联系的，若将其中密切相关的部分放在 同一个模块中，模块间的联系就会降低；反之，若将密切相关的 部分分散放在不同的模块之中，模块间的联系必然会加强。在进 行模块化设计时，耦合性和内聚性都是必须考虑的重要指标。但 在软件设计时应将更多的注意力集中在提高模块的内聚性上。模 块的内聚性主要可划分为如下几种不同的类型。

➢ 传出模块 ：从上级模块获得数据，进行某些处理，再将 其传送给下属模块。
➢ 变换模块 ：即加工模块。它从上级模块取得数据，进 行处理，转换成其它形式，再传送回上级模块。
➢ 协调模块 ：对所有下属模块进行协调和管理的模块。
第五页，共98页。
7.1.1 系统结构图中的模块
在系统结构图中不能再分解的底层模块为原 子模块。
模块 软件包应满足设计约束和可移植性
第二十六页，共98页。
7.5.1 模块功能的完善化
一个完整的功能模块，不仅应能完成指定的 功能，而且还应当能够告诉使用者完成任务 的状态，以及不能完成的原因。
➢ 规定的功能部分。 ➢ 出错处理部分。当模块不能完成规定的功能时
，必须返回出错信息和标志，向它的调用者报 告出现这种例外情况的原因。 ➢ 给调用者返回一个该模块执行是否正确结束的 “标志”。
第十页，共98页。
7.2 变换映射
变换映射是一组设计步骤，将具有变换流特征的数据流图 映射为一个预定义的程序结构模版。
运用变换映射方法建立初始的系统结构图，然后进行多 次改进，得到系统的最终结构图。
➢ （1）复审并评估分析模型； ➢ （2）复审并重画数据流图； ➢ （3）确定数据流图中的变换和事务特征； ➢ （4）区分输入流、输出流和中心变换部分，即标明数据
在具体的应用中一般以变换型为主，事务型 为辅的方式进行软件结构设计。
第二十三页，共98页。
7.4 变换-事务混合型的系统结构图
第二十四页，共98页。
课堂作业
在医院就诊系统中，挂号子系统的数据流图 如下图所示：
挂号请求
科室信息
查询科室 排队信息
科室排队 信息
确 科定 室挂 医号 生挂医号生的信科息室确费定用挂号

例：
可靠性和容错需求如何影响设计？ 采购子构建的许可费用如何影响收益率？ 可适应性和可配置性需求如何影响设计？ 商标名称的选择如何影响架构？
.
5
架构分析
识别和分析对架构有影响的非功能性需求。虽然与功 能性需求也有关系（特别是可变性方面），但是应该 对非功能性需求给予非常彻底的关注。通常，这些都 被称为架构因素（或者称为架构驱动者）
P24 图2-9
.
16
框架和架构的关系
P25 图2-10
.
17
理解架构
真实的软件其实是“由组件递归组合而成”的：
组件的粒度可以很小，也可以很大；任何粒度的组件都 可以组合成粒度更大的整体。即所谓的粒度多样性问题
组件粒度的界定，必须在具体的实践上下文中才有意义 ；你的大粒度组件，对我而言可能是原子组件。即所谓 的粒度相对性问题
第十讲 软件架构设计
.
1
目标
管窥架构设计现状 架构设计方法 如何确定架构驱动因素 非功能需求设计方法论
.
2
通用过程太笼统
.
3
架构分析
架构分析可以被视为需求分析的规格化，其关注强烈 影响”架构“的需求。例如，为系统识别高度安全方 面的需求。
架构分析的本质是要识别影响架构的因素，理解这些 因素的可变性和优先级，并且解决这些问题
P32 图2-17
.
22
架构设计的5视图法
好的方法如路标，对实践者有启发和指引作用。
软件架构师的工作：
要满足性能、持续可用性等方面的需求，架构师必须深入研究软件 系统运行期间的情况、制定相应的设计决策，这些需求被称为软件 的“运行期质量属性”；
而要满足可扩展性、可重用性等方面的需求，则要求架构师深入研 究软件系统开发期间的情况，制定相应的设计决策，这些需求被称 为软件的“开发期质量属性”；

重构的实施
4
来进行重构。
重构应该是一个渐进的过程，通过逐步 修改系统的部分来达到整体的改进。
软件体系结构的例子和项目实践
实例一：在线商店系统
以在线商店系统为例，介绍如何 设计和实现具有扩展性和可维护 性的软件体系结构。
实例二：社交媒体平台
以社交媒体平台为例，讨论如何 应用不同的架构模式来满足用户 的需求。
项目实践：设计和实现一 个软件系统
通过一个具体的项目实践，展示 如何在整个软件开发生命周期中 应用软件体系结构的原理和方法。
结语
1 总结和反思
回顾我们在这份PPT课件中所讨论的内容，并总结其中的关键要点。
2 展望未来的发展趋势
预测软件体系结构领域的发展趋势，并对未来的研究方向提出建议。
3 鼓励学习和实践软件体系结构的重要性
通过评估和分析软件体系结构，我们可以发 现潜在的问题并做出相应的改进。
软件体系结构的演化和重构
1
演化的原因
技术的进步、需求的变化和系统的缺陷
重构的目的和方法
2
可能会导致软件体系结构的演化。
重构旨在改善系统的设计和结构，以提
高可维护性和可扩展性。Βιβλιοθήκη 3重构的技术和策略
通过使用设计模式、分解复杂的模块和
简化系统之间的依赖关系等技术和策略
客户端-服务 器架构
客户端发送请求，服 务器提供响应。这种 架构常用于网络应用 程序和分布式系统。
浏览器-服务 器架构
浏览器充当客户端， 通过HTTP协议与服务 器进行通信。这种架 构常用于Web应用程 序。
面向服务的架 构
系统通过服务进行通 信，每个服务提供特 定的功能。这种架构 可以促进系统的松耦 合和可扩展性。

8
由于架构是关于软件系统组织的配置定义 因此
它定义了： 组成系统的结构（结构元素/组件） 结构或组件间特定的构成和协作关系 系统的集成方法和约束
所以，软件架构不但决定了系统的物理构成 也支配了开发的组织行为
需求分配、范围和任务定义、进度计划、测 试方案、集成方法、配置项与基线管理……
这是现代软件工程更关注的地方。
• 因为
– 软件构架比需求更进一步要面对或满足系统 非功能性的内容，如：容量、数据吞吐量、 一致性、兼容性、安全性、可靠性
最新版整理ppt
12
1.2.3 软件架构的表示方法
最简单的架构视图：物理视图
（计算机系统构架）
最新版整理ppt
13
传感器监控的功能视图
规范显示 信息
产生显示 信息
产生报警信 号
16
MVC构架的并发视图
最新版整理ppt
17
一个由Struts实现的MVC构架
最新版整理ppt
18
最新版整理ppt
9
1.2.2 软件架构的作用
最新版整理ppt
10
1.2.2 软件架构的作用
（1）软件架构定义了软件计算的组件、局部 和总体的构成关系、以及这些组件之间的相 互作用
• 计算组件：
– 客户、服务器、数据库、中间件、程序包、过程、子程 序、进程等——切碎、再切碎（粒度）
• 相互作用关系：
软件架构包含了 系统的基础构成单元（组件） 它们之间的作用关系（连接/连接件） 在构成系统时，它们的集成方法以及 对集成约束的描述。
最新版整理ppt
7
什么是软件架构？
架构={ 组件、连接件、约束 }
组 件：一组程序代码、进程、接口 连接件：调用、管道、消息 约 束：组件之间的连接关系

• 组成派 – 软件系统的架构将系统描述为计算组件及组件之间的交互（The architecture of a software system defines the system in terms of computational components and interactions among those components） – Mary Shaw《软件体系结构：一门初露端倪学科的展望》 决策派 – 软件架构包含了关于一下问题的重要决策
SOA的特性
• • • • • • • • • SOA 有以下特性： ������ 服务具有明确的接口（合约）与策略。 ������ 服务通常代表业务功能或者领域。 ������ 服务拥有模块化的设计。 ������ 服务被松散的耦合在一起。 ������ 服务是可以被发现的。 ������ 服务的位置对客户是透明的。 ������ 服务是独立于传输层的。 ������ 服务是独立于平台的。
面向服务设计模式(SOAD)
service-oriented Architecture
• ������ SOA（service-oriented Architecture，也叫面向服务的体系 结构或面向服务架构）是指为了解决在Internet环境下业务集成的需 要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架 构。 • ������ SOA是一个组件模型，它将应用程序的不同功能单元（称为服 务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用 中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系 统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统 一和通用的方式进行交互。
• SOA 可以通过很多方式来实现，但最常用的SOA 是用Web Service 来实现，这主要应为WebService 的独立于平台的特性和其它特性更 符合SOA 的规则。