《软件工程》PPT第11章 体系结构设计
合集下载
《软件工程》PPT课件
第四课时
第一章第四课时
喷泉模型 软件工程的任务与研究范围 软件开发的原则与开发方法
返回
喷泉模型
瀑布模型要求在软件开发的初期就完全确定软件的需求,这在很多 情况下往往是做不到的.螺旋模型试图克服瀑布模型的这一不足.SM 把软件开发过程安排为逐步细化的螺旋周期序列,每经历一个周期, 系统就细化和完善一些.SM每—螺旋周期由六个步骤组成： <1> 确定任务目标： 根据初始需求分析项目计划,确定任务目标、可选 方案和限制.<2>选择对象：对各种软硬件设备、开发方法、技术、 开发工具、人员、开发管理等对象进行选择：并决定软件是进行研 制、购买还是利用现有的.<3>分析约束条件：软件开发的时间、经 费等限制条件.<4>风险分析：评估目标、对象、约束条件三者之间 的联系,列出可能出．现的问题及问题的严重程度等,把最重要的问 题作为尚未解决的关键问题的风险.<5>制定消除风险的方法：应有 详尽的说明和周密的计划,并估计可能产生的后果.依此来开发软件, 为制订下一周期的计划打下基础.<6>制定下一周期的工作计划：在 第一个螺旋周期,确定目标、选择对象、分析约束,通过风险分析制 订消除风险的方法,初步开发原型1,制定系统生存周期计划.
软件工程的任务与研究范围
•软件产品的特点 •软件工程的研究内容与方法 •软件工具与软件支撑环境 •软件管理
软件开发的原则与方法
•软件开发的原则 • 自顶向下与模块结构 •软件开发的方法 •1.非自动形式的系统开发方法 •〔1〕系统流程图〔2〕结构分析法〔3〕结构化设计法 •〔4〕数据结构法〔5〕层次输入——处理——输出方法<HIPO法> • 2.半自动形式的系统开发方法 •〔1〕软件需求工程法〔2〕问题说明语言与分析法 • 3. 自动形式的系统开发方法 〔HOS方法〕：由计算机自动确定规 范、自动分析、自动编程、自动执行与模拟,以规范语言AXES、资 源分配工具RTA为工具.能自动进行分析、设计,工作量少、设计规范, 也能自动进行修改和维护.该方法适用于系统分析和设计.
第一章第四课时
喷泉模型 软件工程的任务与研究范围 软件开发的原则与开发方法
返回
喷泉模型
瀑布模型要求在软件开发的初期就完全确定软件的需求,这在很多 情况下往往是做不到的.螺旋模型试图克服瀑布模型的这一不足.SM 把软件开发过程安排为逐步细化的螺旋周期序列,每经历一个周期, 系统就细化和完善一些.SM每—螺旋周期由六个步骤组成： <1> 确定任务目标： 根据初始需求分析项目计划,确定任务目标、可选 方案和限制.<2>选择对象：对各种软硬件设备、开发方法、技术、 开发工具、人员、开发管理等对象进行选择：并决定软件是进行研 制、购买还是利用现有的.<3>分析约束条件：软件开发的时间、经 费等限制条件.<4>风险分析：评估目标、对象、约束条件三者之间 的联系,列出可能出．现的问题及问题的严重程度等,把最重要的问 题作为尚未解决的关键问题的风险.<5>制定消除风险的方法：应有 详尽的说明和周密的计划,并估计可能产生的后果.依此来开发软件, 为制订下一周期的计划打下基础.<6>制定下一周期的工作计划：在 第一个螺旋周期,确定目标、选择对象、分析约束,通过风险分析制 订消除风险的方法,初步开发原型1,制定系统生存周期计划.
软件工程的任务与研究范围
•软件产品的特点 •软件工程的研究内容与方法 •软件工具与软件支撑环境 •软件管理
软件开发的原则与方法
•软件开发的原则 • 自顶向下与模块结构 •软件开发的方法 •1.非自动形式的系统开发方法 •〔1〕系统流程图〔2〕结构分析法〔3〕结构化设计法 •〔4〕数据结构法〔5〕层次输入——处理——输出方法<HIPO法> • 2.半自动形式的系统开发方法 •〔1〕软件需求工程法〔2〕问题说明语言与分析法 • 3. 自动形式的系统开发方法 〔HOS方法〕：由计算机自动确定规 范、自动分析、自动编程、自动执行与模拟,以规范语言AXES、资 源分配工具RTA为工具.能自动进行分析、设计,工作量少、设计规范, 也能自动进行修改和维护.该方法适用于系统分析和设计.
软件工程结构化软件设计PPT
软件工程结构化软件设计PPT 在当今数字化的时代，软件已经成为了驱动社会发展和创新的重要力量。
而软件工程中的结构化软件设计则是确保软件质量、可维护性和可扩展性的关键环节。
本 PPT 将深入探讨软件工程结构化软件设计的相关概念、原则、方法和技术。
一、结构化软件设计的概念结构化软件设计是一种基于模块化、自顶向下、逐步细化的设计方法。
它将软件系统分解为多个相互独立、功能明确的模块，通过清晰的接口进行通信和协作。
这种设计方法有助于提高软件的可读性、可理解性和可维护性，降低开发成本和风险。
二、结构化软件设计的原则1、模块化原则将软件系统划分为若干个模块，每个模块具有独立的功能和明确的接口。
模块之间的耦合度要低，内聚度要高，以提高模块的独立性和可复用性。
2、自顶向下原则从软件系统的顶层开始，逐步向下分解和细化，直到最底层的模块。
这种方法有助于把握软件系统的整体结构和功能，避免出现混乱和遗漏。
3、信息隐藏原则模块内部的实现细节对其他模块隐藏，只通过公开的接口进行交互。
这样可以减少模块之间的相互影响，提高软件的稳定性和可修改性。
4、高内聚低耦合原则模块内部的元素之间具有紧密的联系，形成一个高度内聚的整体；模块之间的联系要尽量松散，降低耦合度。
这样可以使软件系统更容易理解和维护。
三、结构化软件设计的方法1、数据流图（DFD）用于描述软件系统中数据的流动和处理过程。
通过绘制 DFD，可以清晰地了解系统的功能需求和数据流程，为后续的设计提供依据。
2、结构图展示软件系统的模块结构和模块之间的层次关系。
结构图可以帮助开发人员直观地了解系统的整体架构，便于进行模块的划分和设计。
3、程序流程图用于描述程序的控制流程和逻辑结构。
通过绘制程序流程图，可以清晰地了解程序的执行过程，便于进行代码的编写和调试。
四、结构化软件设计的技术1、模块划分技术根据功能需求和设计原则，将软件系统划分为合理的模块。
在划分模块时，要考虑模块的大小、功能的独立性和复用性等因素。
软件工程中的结构化设计PPT课件
10
3. 逐步求精
• 细化
• 为了集中精力解决主要问题而尽量推迟对问题细节的考 虑。
• 软件工程过程的每一步都是对软件解法的抽象层次的一 次精化。
• 求精是帮助设计者在设计过程中提示出低层细节。
.
11
4. 信息隐藏（Information Hiding）
• 又称数据封装（Data Encapculation）
.
37
功能内聚
• 功能内聚：
– 一个模块内的所有成分的处理动作全部为完成某个 功能，且只执行一个功能，缺一不可，称为功能内 聚。
– 如：计算实发工资，打印发票等 – 是最高程度的内聚。 – 有利于实现软件的重用，从而提高软件开发的效率。
.
38
耦合、内聚与模块独立性关系
• 内聚和耦合密切相关，同其它模块强耦合的模 块意味着弱内聚，强内聚模块意味着与其它模 块间松散耦合。
软件工程基本定理
软
总成本
件
最小成本区
接口成本
开
M
发
工
作
量 模块成本
.
8
模块数
有关模块化
• 模块化考虑因素：
– 模块数目 – 怎样定义一个给定大小的模块
• 评价模块系统设计方法的标准：
– 可分解性、可组装性、可理解性、连续性、保护性
• 模块化的优点：
– 易阅读和理解，可靠性，可修改性
.
9
2. 抽象（Abstraction）
• 标记耦合（又称特征耦合）：
– 指两个模块之间传递的是数据结构（如记录、数组 等）。其实传递的是这个数据结构的地址。
– 两个模块必须清楚这些数据结构，并按要求对其进 行操作，这样就降低了可理解性。
《软件工程》教学课件 第11章 软件项目管理
式为组织型、半独立型或嵌入型。
下 表 是 根 据 63 个 项 目 的 数 据 统 计 结 果 ， 按 照 基 本 的 COCOMO模型估算的工作量和进度。
总体类型 组织型
半独立型 嵌入型
工作量 MM=10.4（KLOG）1.05 MM=3.0（KLOG）1.12 MM=3.6（KLOG）1.20
进度 TDEV=10.5（MM）0.38 TDEV=10.5（MM）0.35 TDEV=10.5（MM）0.32
i1
其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数
将估算的源代码行数，乘以根据经验推算的每行源代 码所需成本，即为该软件的成本。
IBM 估算模型
1977年由Waiston 和 Felix 总结了IBM联合系统 分部（FSD）负责的６０个项目的数据，利用最小二 乘法拟合，得到如下估算公式：
PERT（Program evaluation & review technique)计 划评审技术或CPM（Critical path method）关键路径法， 都是采用网络图来描述项目的进度安排。如图描述了开发 模块A、B、C的任务网络图。各边上所标注的数字为该任 务所持续的时间，数字结点为任务的起点和终点。
70
任务
月份 １ 2 3 4 5 6 7 8 9 10 11 12
60
需求分析 ▲ ▲ ▲
50
总体设计
▲ ▲▲
40
详细设计
▲▲
30
编码 软件测试
▲ ▲▲
20
10
▲▲▲
0 一月
二月
三月
四月
五月
六月
进度表
2.甘特图（Gantt Chart）
下 表 是 根 据 63 个 项 目 的 数 据 统 计 结 果 ， 按 照 基 本 的 COCOMO模型估算的工作量和进度。
总体类型 组织型
半独立型 嵌入型
工作量 MM=10.4（KLOG）1.05 MM=3.0（KLOG）1.12 MM=3.6（KLOG）1.20
进度 TDEV=10.5（MM）0.38 TDEV=10.5（MM）0.35 TDEV=10.5（MM）0.32
i1
其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数
将估算的源代码行数，乘以根据经验推算的每行源代 码所需成本，即为该软件的成本。
IBM 估算模型
1977年由Waiston 和 Felix 总结了IBM联合系统 分部（FSD）负责的６０个项目的数据，利用最小二 乘法拟合，得到如下估算公式：
PERT（Program evaluation & review technique)计 划评审技术或CPM（Critical path method）关键路径法， 都是采用网络图来描述项目的进度安排。如图描述了开发 模块A、B、C的任务网络图。各边上所标注的数字为该任 务所持续的时间，数字结点为任务的起点和终点。
70
任务
月份 １ 2 3 4 5 6 7 8 9 10 11 12
60
需求分析 ▲ ▲ ▲
50
总体设计
▲ ▲▲
40
详细设计
▲▲
30
编码 软件测试
▲ ▲▲
20
10
▲▲▲
0 一月
二月
三月
四月
五月
六月
进度表
2.甘特图（Gantt Chart）
软件工程导论第11章
22
【还可以把适配接口再进一步细分为转换接口和扩充接口。转换接口， 是为了克服与表示方法、数据结构或硬件特点相关的操作给重用带来 的困难而设计的，这类接口是每个类构件在重用时都必须重新定义的 服务的集合。当使用C++语言编程时，应该在根类(或适当的基类)中， 把属于转换接口的服务定义为纯虚函数。如果某个服务有多种可能的 实现算法，则应该把它当作扩充接口。扩充接口与转换接口不同，并 不需要强迫用户在派生类中重新定义它们，相反，如果在派生类中没 有给出扩充接口的新算法，则将继承父类中的算法。当用C++语言实现 时，在基类中把这类服务定义为普通的虚函数。】
4. 弱耦合 耦合：指一个软件结构内不同模块之间互连的紧 密程度。 在面向对象方法中，对象是最基本的模块，因此， 耦合主要指不同对象之间相互关联的紧密程度。 弱耦合是优秀设计的一个重要标准。
5
对象之间的耦合分为两大类： (1) 交互耦合： 对象之间的耦合通过消息连接来实现。 使交互耦合尽可能松散，应遵守下述准则： 尽量降低消息连接的复杂程度。 应该尽量减少消息中包含的参数个数，降低参数的复 杂程度。 减少对象发送(或接收)的消息数。 (2) 继承耦合 与交互耦合相反，应该提高继承耦合程度。 通过继承关系结合起来的基类和派生类，构成系统中 粒度更大的模块。设计时应该使特殊类尽量多继承并 使用其一般化类的属性和服务，从而更紧密地耦合到 其一般化类。
13
2. 软件成分的重用级别 (1) 代码重用 源代码剪贴：最原始的重用形式。 复制或修改原有代码时可能出错，存在严重的配臵 管理问题，人们几乎无法跟踪原始代码块多次修改 重用的过程。 源代码包含：许多程序设计语言都提供包含库中 源代码的机制。配臵管理问题有所缓解，修改了库 中源代码之后，所有包含它的程序自然都必须重新 编译。 继承：利用继承机制重用类库中的类时，无须修 改已有的代码，就可以扩充或具体化在库中找出的 类，基本上不存在配臵管理问题。
【还可以把适配接口再进一步细分为转换接口和扩充接口。转换接口， 是为了克服与表示方法、数据结构或硬件特点相关的操作给重用带来 的困难而设计的，这类接口是每个类构件在重用时都必须重新定义的 服务的集合。当使用C++语言编程时，应该在根类(或适当的基类)中， 把属于转换接口的服务定义为纯虚函数。如果某个服务有多种可能的 实现算法，则应该把它当作扩充接口。扩充接口与转换接口不同，并 不需要强迫用户在派生类中重新定义它们，相反，如果在派生类中没 有给出扩充接口的新算法，则将继承父类中的算法。当用C++语言实现 时，在基类中把这类服务定义为普通的虚函数。】
4. 弱耦合 耦合：指一个软件结构内不同模块之间互连的紧 密程度。 在面向对象方法中，对象是最基本的模块，因此， 耦合主要指不同对象之间相互关联的紧密程度。 弱耦合是优秀设计的一个重要标准。
5
对象之间的耦合分为两大类： (1) 交互耦合： 对象之间的耦合通过消息连接来实现。 使交互耦合尽可能松散，应遵守下述准则： 尽量降低消息连接的复杂程度。 应该尽量减少消息中包含的参数个数，降低参数的复 杂程度。 减少对象发送(或接收)的消息数。 (2) 继承耦合 与交互耦合相反，应该提高继承耦合程度。 通过继承关系结合起来的基类和派生类，构成系统中 粒度更大的模块。设计时应该使特殊类尽量多继承并 使用其一般化类的属性和服务，从而更紧密地耦合到 其一般化类。
13
2. 软件成分的重用级别 (1) 代码重用 源代码剪贴：最原始的重用形式。 复制或修改原有代码时可能出错，存在严重的配臵 管理问题，人们几乎无法跟踪原始代码块多次修改 重用的过程。 源代码包含：许多程序设计语言都提供包含库中 源代码的机制。配臵管理问题有所缓解，修改了库 中源代码之后，所有包含它的程序自然都必须重新 编译。 继承：利用继承机制重用类库中的类时，无须修 改已有的代码，就可以扩充或具体化在库中找出的 类，基本上不存在配臵管理问题。
软件工程结构化软件设计(共98张PPT)
➢ 传出模块 ：从上级模块获得数据，进行某些处理，再将 其传送给下属模块。
➢ 变换模块 ：即加工模块。它从上级模块取得数据，进 行处理，转换成其它形式，再传送回上级模块。
➢ 协调模块 ：对所有下属模块进行协调和管理的模块。
第五页，共98页。
7.1.1 系统结构图中的模块
在系统结构图中不能再分解的底层模块为原 子模块。
模块 软件包应满足设计约束和可移植性
第二十六页，共98页。
7.5.1 模块功能的完善化
一个完整的功能模块，不仅应能完成指定的 功能，而且还应当能够告诉使用者完成任务 的状态，以及不能完成的原因。
➢ 规定的功能部分。 ➢ 出错处理部分。当模块不能完成规定的功能时
，必须返回出错信息和标志，向它的调用者报 告出现这种例外情况的原因。 ➢ 给调用者返回一个该模块执行是否正确结束的 “标志”。
第十页，共98页。
7.2 变换映射
变换映射是一组设计步骤，将具有变换流特征的数据流图 映射为一个预定义的程序结构模版。
运用变换映射方法建立初始的系统结构图，然后进行多 次改进，得到系统的最终结构图。
➢ （1）复审并评估分析模型； ➢ （2）复审并重画数据流图； ➢ （3）确定数据流图中的变换和事务特征； ➢ （4）区分输入流、输出流和中心变换部分，即标明数据
在具体的应用中一般以变换型为主，事务型 为辅的方式进行软件结构设计。
第二十三页，共98页。
7.4 变换-事务混合型的系统结构图
第二十四页，共98页。
课堂作业
在医院就诊系统中，挂号子系统的数据流图 如下图所示：
挂号请求
科室信息
查询科室 排队信息
科室排队 信息
确 科定 室挂 医号 生挂医号生的信科息室确费定用挂号
➢ 变换模块 ：即加工模块。它从上级模块取得数据，进 行处理，转换成其它形式，再传送回上级模块。
➢ 协调模块 ：对所有下属模块进行协调和管理的模块。
第五页，共98页。
7.1.1 系统结构图中的模块
在系统结构图中不能再分解的底层模块为原 子模块。
模块 软件包应满足设计约束和可移植性
第二十六页，共98页。
7.5.1 模块功能的完善化
一个完整的功能模块，不仅应能完成指定的 功能，而且还应当能够告诉使用者完成任务 的状态，以及不能完成的原因。
➢ 规定的功能部分。 ➢ 出错处理部分。当模块不能完成规定的功能时
，必须返回出错信息和标志，向它的调用者报 告出现这种例外情况的原因。 ➢ 给调用者返回一个该模块执行是否正确结束的 “标志”。
第十页，共98页。
7.2 变换映射
变换映射是一组设计步骤，将具有变换流特征的数据流图 映射为一个预定义的程序结构模版。
运用变换映射方法建立初始的系统结构图，然后进行多 次改进，得到系统的最终结构图。
➢ （1）复审并评估分析模型； ➢ （2）复审并重画数据流图； ➢ （3）确定数据流图中的变换和事务特征； ➢ （4）区分输入流、输出流和中心变换部分，即标明数据
在具体的应用中一般以变换型为主，事务型 为辅的方式进行软件结构设计。
第二十三页，共98页。
7.4 变换-事务混合型的系统结构图
第二十四页，共98页。
课堂作业
在医院就诊系统中，挂号子系统的数据流图 如下图所示：
挂号请求
科室信息
查询科室 排队信息
科室排队 信息
确 科定 室挂 医号 生挂医号生的信科息室确费定用挂号
软件工程ppt课件完整版
缺陷跟踪
使用缺陷管理工具对缺陷进行 跟踪，确保每个缺陷都得到处 理。
缺陷修复
开发人员对缺陷进行分析并修 复，然后提交给测试人员进行 验证。
回归测试
对修复后的缺陷进行回归测试 ，确保修复没有引入新的缺陷
。
质量评估与改进
质量评估
定期对软件产品的质量进行评估，包括功能 、性能、安全等方面。
过程改进
对软件开发过程进行持续改进，提高开发效 率和软件质量。
，提高代码的可读性和可维护性。
模块化开发
02
采用模块化开发方式，将系统划分为不同的模块进行开发，提
高开发效率和质量。
错误处理
03
对可能出现的错误进行充分的考虑和处理，包括异常捕获、日
志记录和错误提示等，确保系统的稳定性和可靠性。
05 测试与质量保证
测试类型及方法
功能测试对软件产品的各项功 进行验证，确保符 合需求和设计。
同时引入了风险管理机制。
螺旋模型的主要阶段包括：制 定计划、风险分析、工程实施
和客户评估。
螺旋模型的优点在于其强调风 险分析和迭代开发，能够及时 发现并解决问题，降低项目风 险。
螺旋模型的缺点在于其需要较 高的项目管理能力和技术水平 ，且可能因为过度关注风险而 忽略其他重要因素。
敏捷开发模型
敏捷开发的主要实践包括：短周期迭代开发、 持续集成、持续交付和自动化测试等。
水平。
04
迭代增量模型的优点在于其能够逐步增加系统功能和 性能，降低项目风险，同时也能够及时发现并解决问 题。
03 需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领域 专家等进行沟通，明确需求背景
和范围。
使用缺陷管理工具对缺陷进行 跟踪，确保每个缺陷都得到处 理。
缺陷修复
开发人员对缺陷进行分析并修 复，然后提交给测试人员进行 验证。
回归测试
对修复后的缺陷进行回归测试 ，确保修复没有引入新的缺陷
。
质量评估与改进
质量评估
定期对软件产品的质量进行评估，包括功能 、性能、安全等方面。
过程改进
对软件开发过程进行持续改进，提高开发效 率和软件质量。
，提高代码的可读性和可维护性。
模块化开发
02
采用模块化开发方式，将系统划分为不同的模块进行开发，提
高开发效率和质量。
错误处理
03
对可能出现的错误进行充分的考虑和处理，包括异常捕获、日
志记录和错误提示等，确保系统的稳定性和可靠性。
05 测试与质量保证
测试类型及方法
功能测试对软件产品的各项功 进行验证，确保符 合需求和设计。
同时引入了风险管理机制。
螺旋模型的主要阶段包括：制 定计划、风险分析、工程实施
和客户评估。
螺旋模型的优点在于其强调风 险分析和迭代开发，能够及时 发现并解决问题，降低项目风 险。
螺旋模型的缺点在于其需要较 高的项目管理能力和技术水平 ，且可能因为过度关注风险而 忽略其他重要因素。
敏捷开发模型
敏捷开发的主要实践包括：短周期迭代开发、 持续集成、持续交付和自动化测试等。
水平。
04
迭代增量模型的优点在于其能够逐步增加系统功能和 性能，降低项目风险，同时也能够及时发现并解决问 题。
03 需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领域 专家等进行沟通，明确需求背景
和范围。
软件工程导论(第11章)
3. 信息隐蔽
在面向对象方法中，信息隐蔽通过对象的封
装性实现：类结构分离了类的接口与类的实
现，从而支持了信息隐蔽。
4. 弱耦合
弱的耦合可以提高软件模块的独立性，避免 某一部分模块发生变化对其它模块有较大的影 响。
一般来说，对象间的耦合有两大类：
A．交互耦合：对象间的耦合通过信息连接来
实现。应使交互耦合尽量松散。
2. 一般—特殊结构的深度应适当
中等规模的系统中，类等级层次数应保持 为7±2。不是必要情况，不应该随意创建派生类；
3. 设计简单的类：设计小而简单的类，便于
开发和管理；
1）避免包含过多的属性； 2）有明确的定义； 3）尽量简化对象之间的合作关系； 4）不要提供太多服务。
4. 使用简单的协议：设计简单的类接口，发送 的消息中参数要少。 5. 使用简单的服务：编写实现每一个服务时， 避免复杂的语句和结构； 6. 把设计变动减至最小。
2.
两个方向的关联都用属性实现，这种方法能 实现快速访问。
3.
用独立的关联对象实现双向关联。关联对象 不属于相互关联的任何一个类，它是独立的 关联类的实例 。
40
41
4、关联对象的实现
关联对象的实现方法取决于关联的阶数：
一对一关联：
• 关联对象可以与参与关联的任一个对象合并。
一对多关联：
• 关联对象可以与“多”端对象合并。
11.9 设计类中的服务 11.9.1 确定类中应有的服务 11.9.2 设计实现服务的方法
1. 设计实现服务的算法
1）算法复杂度；
2）容易理解、容易实现；
3）容易修改；
2. 选择数据结构 3. 定义内部类和内部操作
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 2
总体设计
功能设计
总体功能结构 子系统及组件物理部署 系统层次结构 公共组件 全局数据结构 子系统（组件） 子系统（组件）内全局 数据结构 通信接口组件 外部接口数据 总体测试数据 总体数据库结构 数据库公共管理组件 公共数据库表结构 系统主界面 用户功能子系统切换界 面 统一登录界面 权限划分与管理 数据安全管理设计 系统性能设计 总体设计说明书 数据模型文件
缺点
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 25
客户机/服务器模型
分布式系统模型（Distributed system model） 显示数据和操作是如何通过一系列组件而进行 分布的。客户机/服务器体系结构的模型是一 个分布式系统模型。 这个模型的主要组成部分是： 一组给其他子系统提供特定服务（如打印服务， 数据管理服务等）的单机服务器； 一组向服务器请求服务的客户机； 一个连接客户机和服务器的网络。
Slide 10
清晰的软件体系结构的三个好处
信息持有者之间的沟通
• 体系结构可以作为不同的项目相关人员之间讨论 的焦点。 系统分析对体系结构的设计决策，对系统能否满 足非功能需求具有很大的影响。 体系结构能在相似需求的系统之间互用，以支持 大规模的软件复用。
系统分析
•
大规模复用
•
陈江平
Software Engineering, 8th edition. Chapter 11
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 18
体系结构的复用
同一个应用领域内的系统通常具有相似的体系 结构，这种体系结构能反映基本的领域概念， 比如信息管理系统的体系结构。 应用产品线（ Application product lines ）是 围绕一个核心体系结构建立的一些应用，核心 体系结构会有一些变量可以调整来满足专门用 户的需求。 一般应用体系结构，应用产品线将分别在13 章和18章进行讨论。
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 20
体系结构模型
体系结构设计的产品是一个体系结构设计文档。 静态结构模型（ Static structural model ）显示一个 系统的子系统或组件。 动态过程模型（Dynamic process model） 显示系统 在运行时的过程组成。 接口模型（Interface model） 定义每个子系统从它们 的公共接口能得到的服务。 关系模型（Relationships model）如数据流模型，显 示子系统间的关系。 分布模型（Distribution model）显示子系统在多台计 算机上是如何分布的。
缺点
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 28
客户机/服务器两层架构 客户机 服务器两层架构
对一个拥有12~100个用户，两层架构模型是一个 个用户， 对一个拥有 个用户 很好的解决方案。 很好的解决方案。该模型极少需要在人工的介入下 运作，且常被用作不是太复杂、 运作，且常被用作不是太复杂、时间性不强的信息 处理系统。 处理系统。 该模型有3个组件： 该模型有 个组件： 个组件 (1) 用户系统界面（比如会话、文本输入、对话框 用户系统界面（比如会话、文本输入、 和显示管理）； 和显示管理）； (2) 程序管理（比如程序开发和程序资源服务）； 程序管理（比如程序开发和程序资源服务）； (3) 数据库管理（比如数据和文件服务 数据库管理（
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 4
内容
体系结构设计决策 系统组成 模块化分解模型 控制类型 参考体系结构
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 5
软件体系结构
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 26
电影和图片库系统的体系结构
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 27
客户机/服务器模型的特点
优点
• • • • • • 数据的分布式最直接的; 可以更有效地使用网络系统，从而降低了对硬件的要求； 很容易就添加一台新的服务器或更新现有的服务器。 没有共享数据模型，子系统以不同的方式组织它们的数据。 数据交换效率就可能很低； 每个服务器上出现冗余数据管理； 没有中央寄存器的名字和服务，这可能很难找出哪个服务 器和哪些服务可用 。
Software Engineering, 8th edition. Chapter 11
目标
介绍软件体系结构的概念和设计，以及软件体 系结构设计的重要性； 在体系结构设计阶段对系统体系结构必须做出 的决策； 介绍三种互补的软件体系结构类型，涵盖系统 组成、模块分解和控制 讨论如何用参考体系结构来沟通体系结构概念 和评估系统体系结构
初始设计过程的任务是要识别出组成大型系统 的多个子系统，并建立起子系统控制与通信的 框架，这个过程叫做体系结构设计 （ architectural design）。 体系结构设计输出的一个描述就是软件体系结 构（ software architecture）。
陈江平
Software Engineering, 8th edition. Chapter 11
信息安全性 安全性
• • •
可用性 可维护性
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 12
体系结构之间的冲突
使用大力度的组件虽然改进了系统的性能，但 却降低了系统的可维护性； 引入冗余性数据虽然提高了系统的可用性，但 却使系统的信息安全性变得更困难； 定位与安全相关的操作意味着增加了子系统之 间的通信，但这样也降低了系统的性能。
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 14
打包机器人控制系统的方块图
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 15
箱式图和线路图
方块图非常抽象 ，因为它没有给出系统组件 之间的本质关系，也没有显示出子系统的全部 特性； 不过，这种模型在与系统项目相关人员沟通中 和在项目规划中是很有效的。
Slide 6
体系结构设计
体系结构设计是设计过程的初始阶段； 表现为设计和需求工程过程之间的桥梁； 通常是与一些系统描述活动同时进行的； 它包括识别出系统的主要组件以及它们之间的 通信。
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 7
陈江平
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 16
体系结构设计决策
体系结构设计是一个充满创意性的过程，所以 过程中的活动差别非常的大，这很大程度上所 要开发的系统的类型。 然而，所有的设计过程都有一些共同的决策阶 段。因而，我们可以从决策角度来看待体系结 构设计。
Software Engineering, 8th edition. Chapter 11
Slide 8
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 9
陈江平
Software Engineering, 8th edition. Chapter 11
数据结构设计
子系统公用数据结构 模块内公用数据结构 子系统测试数据
数据库设计 界面设计
子系统通用数据库表 子系统专用数据库表 功能子系统界面
安全设计 设计完成的交 付产物
陈江平
子系统权限
功能模块单元权限 子系统（模块） 子系统（模块）详细 设计说明书 数据模型文件
Slide 3
子系统（组件） 子系统（组件）设计说明 书 数据模型文件
陈江平
Software Engineering, 8th edition. Chapter 11
Slide 17
体系结构设计决策
是否存在一个一般性的应用体系结构可以拿来当做模 板？ 系统将如何分配到多个处理器上？ 有哪个或哪几个体系结构类型时候本系统？ 有哪些基本方法可以用来构成该系统? 如何将系统中的结构单元分解为模板? 应该使用什么样的策略来控制系统中单元的操作? 如何评估体系结构设计? 如何记录系统体系结构?
子系统（组件） 子系统（组件）
子系统功能结构 子系统模块物理部署 子系统模块层次结构 公共组件功能结构
模块（单元） 模块（单元）设计
模块功能流程， 模块功能流程，主要包 括业务逻辑。 括业务逻辑。 模块内局部数据结构 包括协议包结构等） （包括协议包结构等） 。 模块测试数据 模块专用数据库表 用户功能模块单元界面
Slide 11
软件体系结构的属性
性能
• • • 定位关键性操作，最大限度内减少子系统之间的通信； 使用较大粒度的组件。 采用分层结构，把重要资源放在内层，并在每层中采用更加严 格的信息安全性验证。 把与安全相关的操作集中在一个或少数几个子系统中。 包括冗余性组件和容错型体系结构设计。 使用小粒度，可更换的组件。