软件体系结构第5章

合集下载

软件工程导论 第五章总体设计

软件工程导论  第五章总体设计
低 数据 耦合
控制 耦合
耦合性
特征耦 合 公共 耦合 内容 耦合

28
注意!!
在软件设计中应该追求尽可能松散耦合的系统。
否则影响系统的可理解性、可测性、可靠性和可
维护性。
29
耦合程度强弱的区分

无耦合:如果两个模块中的每一个都能独立 地工作而不需要另一个模块的存在,那么它 们彼此完全独立,模块间无任何连接。
在可行性研究阶段,软件作为系统的一个完整 部件; 在需求分析期间,软件解法是使用在问题环境 内熟悉的方式描述的; 当由总体设计向详细设计过渡时,抽象的程度 也就随之减少; 最后,当源程序写出来以后,也就达到了抽象 的最低层。 20
5.2.3 逐步求精
定义:为了能集中精力解决主要问题而尽量推迟 对问题细节的考虑。 人类的认知过程遵守Miller法则:一个人在任何时 候都只能把注意力集中在(7±2)个知识块上。
6
3. 推荐最佳方案 • 综合分析对比各种合理方案的利弊,推荐 一个最佳的方案,并且为推荐的方案制定 详细的实现计划。 • 在使用部门的负责人也接受了分析员所推 荐的方案之后,将进入总体设计过程的下 一个重要阶段——结构设计。
7
4.功能分解 • 为确定软件结构,首先需要从实现角度把 复杂的功能进一步分解。结合算法描述仔 细分析数据流图中的每个处理,如果一个 处理的功能过分复杂,必须把它的功能适 当地分解成一系列比较简单的功能。
12
5.2 设计原理

5.2.1 模块化
模块化:把程序划分成独立命名且可独立访问的模块,每个 模块完成一个子功能,这些模块集成起来构成一个整体,可 以完成指定的功能以满足用户的需求。 模块是由边界元素限定的相邻程序元素的序列,而且有一个 总体标识符代表它。模块是构成程序的基本构件。 过程、函数、子程序和宏等,都可作为模块。 面向对象方法学中的对象是模块,对象内的方法(或称为服 务)也是模块。

软件工程导论 第5章 总体设计

软件工程导论 第5章 总体设计

第五章总体设计经过需求分析阶段的工作,系统必须“做什么”已经清楚了,现在是决定“怎样做”的时候了。

总体设计的基本目的就是回答“概括地说,系统应该如何实现?”这个问题,因此,总体设计又称为概要设计或初步设计。

通过这个阶段的工作将划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等等,但是每个物理元隶仍然处于黑盒子级,这些黑盒子里的具体内容将在以后仔细设计。

总体设计阶段的另一项重要任务是设计软件的结构,也就是要确定系统中每个程序是由哪些模块组成的,以及这些模块相互间的关系。

总体设计过程首先寻找实现目标系统的各种不同的方案,需求分析阶段得到的数据流图是设想各种可能方案的基础。

然后分析员从这些供选择的方案中选取若干个合理的方案,为每个合理的方案都准备一份系统流程图,列出组成系统的所有物理元素,进行成本/效益分析,并且制定实现这个方案的进度计划。

分析员应该综合分析比较这些合理的方案,从中选出一个最佳方案向用户和使用部门负责人推荐。

如果用户和使用部门的负责人接受了推荐的方案,分析员应该进一步为这个最佳方案设计软件结构,通常,设计出初步的软件结构后还要多方改进,从而得到更合理的结构,进行必要的数据库设汁,确定测试要求并且制定测试计划。

从上面的叙述中不难看出,在详细设计之前先进行总体设计的必要性:可以站在全局高度上,花较少成本,从较抽象的层次上分析对比多种可能的系统实现方案和软件结构,从中选出最佳方案和最合理的软件结构,从而用较低成本开发出较高质量的软件系统。

5.1 设计过程总体设计过程通常由两个主要阶段组成:系统设计阶段,确定系统的具体实现方案;结构没计阶段,确定软件结构。

典型的总体设计过程包括下述9个步骤:1.设想代选择的方案如何实现要求的系统呢,在总体设计阶段分析员应该考虑各种可能的实现方案,并且力求从中选出最佳方案。

在总体设计阶段开始时只有系统的逻辑模型,分析员有充分的自由分析比较不同的物理实现方案,一旦选出了最佳的方案,将能大大提高系统的性能/价格比。

2011年软考系统架构设计师知识要点第五章

2011年软考系统架构设计师知识要点第五章

5.1.1 软件架构设计与生命周期1、需求分析阶段需求和 SA设计面临的是不同的对象:一个是问题空间;另一个是解空间。

保持二者的可跟踪性和转换。

2、设计阶段1.传统的设计概念只包括构件,随着研究的深入,构件间的互联机制逐渐独立出来,成为与构件同等级别的实体,称为连接子。

2.体系结构描述语言(Architecture Description Language ADL)对连接子的重视成为区分 ADL和其他建模语言的重要特征之一。

3.不同的视角得到多个视图,组织起来以描述整体的SA模型;不同侧面的视图反映所关注的系统的特定方面,体现了关注点分离的思想。

3、实现阶段团队的结构应该和体系结构模型有一定的对应关系,提高软件开发效率和质量。

分析和记录不同版本构件和连接子之间的演化。

填补高层 SA模型和底层实现之间的鸿沟,典型的方法如下:1.引入实现阶段的概念。

2.SA模型逐步精化。

3.封装底层称为较大粒度构件。

4、构件组装阶段可复用构件组装可以在较高层次上实现系统,研究内容包括:1.如何互联。

2.如何检测并消除体系结构失配问题。

中间件跨平台交互。

产品化的中间件更好地保证最终系统的质量,中间件导向的体系结构风格。

失配是指复用过程中,待复用构件对最终系统的体系结构和环境的架设(Assumption)与实际状况下不同而导致的冲突。

5、部署阶段软件构件的互联性、硬件的拓扑结构、硬件资源占用。

6、后开发阶段实现中的软件往往具有动态性,一类是软件内部执行所导致的体系结构改变,另一类变化是软件系统外部的请求对软件进行的重配置。

升级或进行其他修改时不能停机。

SA重建是指从已实现的系统中获取体系结构的过程。

5.2 基于架构的软件开发方法5.2.1 体系结构的设计方法概述基于体系结构的软件设计(Architecture-Based Software Design ABSD)方法。

体系结构驱动,指构成体系结构的商业、质量、功能需求的组合驱动。

软件体系结构课件第5章统一建模语言

软件体系结构课件第5章统一建模语言

2:GetPrefSet()
10:PrefSet(date_mg)
1:GetPrefSet()
:MeetingInitiator
第5章 统一建模语言 直接使用UML建模 – 会议安排系统的类图
Person
StronglyConflicts With
Conflicts With
Important Attendee
0..* 0..*
0..* Profers
Attendee
1..* 1..* 0..* 0..*
11 1 1
1
Meeting Initiator
Find.exe
Query .dll
部署图 定义系 统中软 硬件的 物理体
系结构
第5章 统一建模语言 部署图
客户端:个人PC QueryClient.exe
服务器
《TCP/IP》 查询
QueryServer.exe 部署图
定义系
统中软
Find.exe
硬件的
物理体
Query.dll系结构
第5章 统一建模语言
第5章 统一建模语言
直接使用UML建模 – UML中的通用表示
➢ 字符串:表示有关模型的信息; ➢ 名字:表示模型元素; ➢ 标号:不同于编程语言中的标号,是用于表示或说明图形符号的字
符串; ➢ 特殊字符串:表示某一模型元素的特性; ➢ 类型表达式:声明属性、变量及参数,含义同编程语言中的类型表
0
10
20
30s 时间刻度
第5章 统一建模语言 状态图
提交订单 已审核 印前处理
客户付钱
已付款
已处理
进行冲印
冲印中 冲印完成
描述满足 用例要求 所要进行 的活动以 及活动间 的完约成束关 系,有利 于识别并 行活动

软件体系结构5 第5章 软件质量属性

软件体系结构5 第5章 软件质量属性

外部质量
易用性
易用性是指用户使用软件的容易程度。 现代人的生活节奏快,做什么事都想图个方便。所以把易用性作为 重要的质量属性对待无可非议。导致软件易用性差的根本原因 : 理工科大学教育存在缺陷:没有开设人机工程学、美学、心理学这 些必修课,大部分开发人员不知道如何设计易用的软件产品。开发 人员犯了“错位”的毛病:他以为只要自己用起来方便,用户也就 会满意。软件的易用性要让用户来评价。当用户真的感到软件很好 用时,一股温暖的感觉油然而生,于是就用“界面友好”、“方便 易用”等词来评价软件产品。
外部质量
兼容性
兼容性是指不同产品(或者新老产品)相互交换信息的能力。例如 两个字处理软件的文件格式兼容,那么它们都可以操作对方的文件, 这种能力对用户很有好处。兼容性又称为互操作性。 兼容性的商业规则:弱者设法与强者兼容,否则无容身之地;强者 应当避免被兼容,否则市场将被瓜分。金山软件公司的WPS与微 软的Word之争。WPS一定要与Word兼容,否则活不下去。但是 Word绝对不会与WPS兼容,除非WPS又在中国占有绝对优势。 中国联通和中国移动的手机互联互通问题。(互联网的价值与用户 数量的平方成正比)
质量目标与商业目标
质量定义
古时候人们ห้องสมุดไป่ตู้为长得结实、饭量大就是健康,这显然是不科 学的。现代人总是通过考察多方面的生理因素来判断是否健 康,如测量身高、体重、心跳、血压、血液、体温等。如果 上述因素都合格,那么表明这人是健康的。如果某个因素不 合格,则表明此人在某个方面不健康,医生会对症下药。 软件质量是许多质量属性的综合体现,各种质量属性反映了 软件质量的方方面面。人们通过改善软件的各种质量属性, 从而提高软件的整体质量。
响应度量(Response Measure):以某种方式对其进行度量,对 需求进行测试。

软件工程 第5章--RUP统一开发过程

软件工程 第5章--RUP统一开发过程
10
(3) 制品(Artifact)
制品是过程生产、修改或使用的一种信息。制 品可分为输入制品和输出制品。
在面向对象设计中,制品被当作活动的参数。 制品有多种可能的形式,如:
模型 : 如用例模型或设计模型; 模型元素 : 如类、用例或子系统; 文档 : 如一个业务用例或体系结构文档; 源代码; 可执行文件。
13
a) 核心工作流
在 RUP 中共有 9 个核心过程工作流。它们将 所有工作人员和活动进行逻辑分组。
核心过程工作流分为 6 个核心工程工作流和 3 个核心支持工作流。
核心工程工作流有:业务建模工作流、需求 工作流、分析和设计工作流、实现工作流、 测试工作流、实施工作流。
核心支持工作流有:项目管理工作流、配置 和变更管理工作流、环境工作流。
11
Iteration Plan Storyboard
Use Case Model Project Measurements User-Interface Prototype
Developer Test
Iteration Assessment
Business Goal Test Environment Configuration
场景的系统大致轮廓; 估计整个项目需要的成本和时间; 评估风险,即分析不确定性的原因;
31
制品
a) 构想文档:有关项目核心需求、关键特 性和主要限制的构想。
b) 用例模型调查:包括所有在此阶段可确 定的用例和参与者。
c) 初期的项目术语。 d) 初始的业务用例:包括业务环境、是否
成功的评价标准、经济预测。 e) 早期的风险评估。 f) 项目计划:表明阶段和迭代。
内部发布 小里程碑
第1个外部发布 (如Beta版本)

软件工程 第5章--UML

软件工程 第5章--UML
10
UML的定义
UML定义有两个主要组成部分:语义和表示法。 语义用自然语言描述,表示法定义了UML的可 视化标准表示符号,这决定了UML是一种可视 化的建模语言。 在语义上,模型是元模型的实例。UML定义给 出了语法结构的精确定义。 使用UML时,要从不同的角度观察系统,为此 定义了概念“视图(View)‖。视图是对系统的模 型在某方面的投影,注重于系统的某个方面。
独立于过程
系统建模语言,独立于开发过程。
9

容易掌握使用 概念明确,建模表示法简洁明了,图形结 构清晰,容易掌握使用。 着重学习三个方面的主要内容: (1) UML的基本模型元素 (2) 组织模型元素的规则 (3) UML语言的公共机制 与程序设计语言的关系 用Java,C++ 等编程语言可实现一个系统。 一些CASE工具可以根据 UML所建立的系 统模型来产生Java、C++ 等代码框架。
31
UML事物 — 注释事物
11) Note(注释)
依附于一个元素或一组元素之上,对其进
行约束或解释的简单符号。没有语义影响。
See policy8-5-96.doc for details about these algorithms.
CashAccount presentValue()
32
15
UML定义 9 种图,表达UML中的 5 种视图,各 视图在静态和动态方面表示系统模型。
结构 视图 静态 方面
动态 方面
行为 视图 同左
实现 视图 构件图
环境 视图 部署图
同左
用例 视图 用例图
同左
类图 对象图
顺序图 同左 顺序图 合作图 (注重 合作图 状态图 进程、 状态图 活动图 线程) 活动图

软件体系结构-完整PPT课件张友生.doc

软件体系结构-完整PPT课件张友生.doc

软件体系结构课程性质:必修学时/学分:40/2.5关于教材◇出版社:清华大学出版社◇作者:张友生课程内容◇软件体系结构概论◇软件体系结构建模◇软件体系结构风格◇软件体系结构描述◇动态软件体系结构◇Web服务体系结构◇基于体系结构的软件开发◇软件体系结构的分析与测试◇软件体系结构评估◇软件产品线体系结构◇软件危机的表现◎软件成本日益增长◎开发进度难以控制◎软件质量差◎软件维护困难第1章软件体系结构概论1.1 从软件危机谈起◇软件危机的表现◎软件成本日益增长20世纪50年代,软件成本在整个计算机系统成本中所占的比例为10%-20%。

到20世纪60年代中期,软件成本在计算机系统中所占的比例已经增长到50%左右。

而且,该数字还在不断地递增,下面是一组来自美国空军计算机系统的数据:1955年,软件费用约占总费用的18%,1970年达到60%,1975年达到72%,1980年达到80%,1985年达到85%左右。

第1章软件体系结构概论1.1 从软件危机谈起◇软件危机的表现◎开发进度难以控制由于软件是逻辑、智力产品,软件的开发需建立庞大的逻辑体系,这是与其他产品的生产不一样的。

在软件开发过程中,用户需求变化等各种意想不到的情况层出不穷,令软件开发过程很难保证按预定的计划实现,给项目计划和论证工作带来了很大的困难。

盲目增加软件开发人员并不能成比例地提高软件开发能力。

相反,随着人员数量的增加,人员的组织、协调、通信、培训和管理等方面的问题将更为严重。

第1章软件体系结构概论1.1 从软件危机谈起◇软件危机的表现◎软件质量差软件项目即使能按预定日期完成,结果却不尽人意。

1965年至1970年,美国范登堡基地发射火箭多次失败,绝大部分故障是由应用程序错误造成的。

在“软件作坊”里,由于缺乏工程化思想的指导,程序员几乎总是习惯性地以自己的想法去代替用户对软件的需求,软件设计带有随意性,很多功能只是程序员的“一厢情愿”而已,这是造成软件不能令人满意的重要因素。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

5.2.7
解释器风格
5.2.8
C2风格
5.3 案例研究
5.3.1
案例1:上下文关键字
5.3.2
案例2:仪器软件
5.3.3
平台层PaaS和应用程序层SaaS
2
5.4 客户/服务器风格
5.5 三层C/S结构风格
5.5.1
三层C/S结构的优点
5.5.2
实例:某石油管理局劳动管理信息系统
5.6
24
低效。
黑板系统在拒绝错误假设中要承受多余的计 算开销。
但是,如果没有确定的算法存在,那么与根 本不存在的系统相比,低效总比没有强。
开发成本高。
绝大多数黑板系统要花几年时间来进化。 我们把这归因于病态结构问题。
25
5.2.6 模型-视图-控制器(MVC)风格
1. MVC模式
MVC由Trygve Reenskaug提出,首先被应用在 SmallTalk-80环境中,是许多交互和界面系统的构成基 础。MVC结构是为那些需要为同样的数据提供多个视图 的应用程序而设计的,它很好地实现了数据层与表示层的 分离。作为一种开发模型,MVC通常用于分布式应用系 统的设计和分析中,以及用于确定系统各部分间的组织关 系。对于界面设计可变性的需求,MVC(Model– View–Controller)把交互系统的组成分解成模型、视图、 控制器三种部件。
连接件可以用层次间的交互协议来定义。每个独立层 都要防止较高层直接访问较低层。
每一层次是由不同的部件构成的实体集合。层内的部 件可以交互。
相邻层的部件可直接从上向下调用,还可以设计 统一的层调用接口对层进行保护。
17
客户
使用
层N

层 N-1
层1

图5-5 分层模型
清华大学出版社
18
5.2.5 仓库风格和黑板风格
(5)支持并发执行。基于管道-过滤器模式 的系统存在很多并行的过滤器,这样的系统在实 际运行时,可以将存在并发可能的多个过滤器看 作多个并发的任务并行执行,从而大大提高了系 统的整体效率,加快了处理速度。当然,在调度 并行任务的时候,必须有相应的并行算法作基础, 否则,可能导致系统功能的混乱。
11
种处理。这时,仓库是一个黑板体系结构。即黑
板体系结构是仓库体系结构的特殊化。
19
(1)适应的设计问题 (2)解决方案
20
“黑板”模式类似于这样一个情形,即让专家们坐
在真实黑板前并一起工作来解决一个问题。每个专家独
立评估解法的当前状态,并可在任何时间到黑板上添加、
更改或删除信息。人们往往要决定接下来谁去访问黑板。
清华大学出版社
5
5.2 软件体系结构基本风格解析
5.2.1 滤器
管道-过
适用于对有序数据进行一系列已经定义的相互计算的 应用程序。管道过滤器模式下,每个功能模块都有一组 输入和输出。功能模块从输入集合读入数据流,并在输 出集合产生输出数据流,即功能模块对输入数据流进行 增量计算得到输出数据流。管道过滤器模式下,功能模 块称作过滤器(filter);功能模块间的连接可以看作输 入、输出数据流之间的通路,所以称作管道(pipe)。
在黑板模式中,如果可用的组件超过一个,仲裁者
(moderator)组件决定程序执行的顺序。
KS2
KS1
中央数据单元
KS3
(黑板/仓库)
KSn
KS4
图5-6 黑清板华大风学出格版的社 体系结构
21
从图5-6中不难看出,一个标准的黑板型 仓库模式系统通常包括3个组成部分:
(1)知识源: (2)中央数据单元: (3)控制单元:
◆ 支持容错性和健壮性。
在黑板体系结构中,所有的结果都只是假设。 只有那些被数据和其他假设强烈支持的才能生存。这
提供了对噪声数据和不确定结论的容忍。 23
黑板风格的体系结构的缺点有:
不同的知识源代理对于共享数据结构要达
成一致,而且,这也造成对黑板数据结构的修
改较为困难。
需要一定的同步锁机制保证数据结构的完
14
隐式调用系统的主要优点有以下两点:
为软件重用提供了强大的支持。当需要将 一个构件加入现存系统时,只需将它注册 到系统的事件中。
为改进系统带来了方便。当用一个构件代 替另一个构件时,不会影响到其他构件的 接口。
15
隐式调用系统的主要缺点有以下几方面:
● 构件放弃了对系统计算的控制。一个构件
22
黑板风格的体系结构的优点有:
◆ 便于多客户共享大量数据,它们不用关心数 据是何时出现的、谁提供的、怎样提供的。
◆ 既便于添加新的作为知识源代理的应用程序, 也便于扩展共享的黑板数据结构。
◆ 可重用的知识源。
知识源是某类任务的独立专家。 黑板体系结构有助于使它们可重用。重用的先决条件
是知识源和所基于的黑板系统理解相同的协议和数据, 或者在这方面相当接近而不排斥协议或数据的自适应 程序。
清华大学出版社
31
存储器
输入
被解释的程序 的当前状态
正在被解释 的程序
用于计算的 状态机
输出
执行引擎
选择的指令 选择的数据
执行引擎的 当前状态
图5-9 解释器风格的体系结构
32
解释器风格的优点如下:
有助于应用程序的可移植性与程序设 计语言的跨平台能力;可以对未实现的硬 件进行仿真。
清华大学出版社
6
数据 处理器
处理器 处理器
处理器 处理器
图5-1 管道–过滤器风格的体系结构
清华大学出版社
7
采用管道-过滤器模式建立的系统主要 有以下几个优点:
(1)由于每个构件的行为不受其他构件的影响, 因此,整个系统的行为比较易于理解。
设计者可以将系统抽象成一个“黑匣子”,其输入是 系统中第一个过滤器的输入管道,输出是系统中最后 一个过滤器的输出管道,而其内部各功能模块的具体 实现对用户完全透明。
触发一个事件时.不能确定其他构件是否会响应 它。而且即使它知道事件注册了哪些构件的过程, 它也不能保证这些过程被调用的顺序。
● 数据交换的问题。有时数据可被一个事件
传递,但在另一些情况下,基于事件的系统必须 依靠一个共享的仓库进行交互。在这些情况下, 全局性能和资源管理便成了问题。
● 既然过程的语义必须依赖于被触发事件
8
(3)具有较强的可维护性与可扩展性。 可维护性体现在系统过滤器部件的更新或 升级。
由于技术改进等原因,过滤器A的实现发生了 改变,采用新技术开发的过滤器D具有和A完 全相同的输入、输出管道接口,这时可以直接 将A替换为D,而无须对系统中的其他过滤器 或管道进行任何修改。
9
C
A
B
图5-2 管道-过滤器支持功能模块复用
的上下文约束,关于正确性的推理就存在问题。
16
5.2.4 分层系统风格
一个分层风格的系统按照层次结构组织,每一层 向它的上层提供服务,同时又是它的下层客户; 在某些系统中,除了邻接的层,一个内部层次对 于其他外部层次是隐藏的,对体系结构的约束包 括把系统内的交互限制在邻接层次之间。交互只 在相邻的层间发生;同时,这些交互按照一定协 议进行。
(2)支持功能模块的复用。任意两个过滤器只 要在相互的输入、输出管道格式上达成一致,就 可以连接在一起。
过滤器A和过滤器B只要对管道C中传输的数据格式达 成一致就可以实现互连,其中过滤器A并不关心过滤器 B如何处理管道C的内容,而过滤器B也不知道管道C的 内容究竟是如何产生的,即在管道过滤器模式中,过 滤器之间仅需很少的信息交换就可以完成互连。
清华大学出版社
13
5.2.3 基于事件的隐式调用风格
基于事件的隐式调用风格的思想是构 件不直接调用一个过程,而是触发或广播 一个或多个事件。系统中的其他构件中的 过程在一个或多个事件中注册,当一个事 件被触发,系统自动调用在这个事件中注 册的所有过程,这样,一个事件的触发就 导致了另一模块中的过程的调用。
清华大学出版社
26
2. MVC中的模型、视图和控制类
MVC中的模型、视图和控制类如图5-7所示。
(1)模型类
(2)视图类
(3)控制类
27
模型类
数据结构关系 变化-传播注册关系
内部数据和逻辑计算 向视图和控制器通知数据变化
视图类
显示形式 显示模式控制
从模型获得数据视图 更新操作
(a)
(b)
控制类
整性和一致性,增大了系统复杂度。
测试困难。由于黑板系统的计算没有依据
一个确定的算法,所以其结果常常不可再现。
此外,错误假设也是求解过程的一部分。
不能保证有好的求解方案。
一个黑板系统往往只能正确解决所给任务的某一百 分比。
难以建立一个好的控制策略。
控制策略不能以一种直接方式设计,而需要一种试 验的方法。
状态
事件控制 控制视图更新
(c)
28
3. MVC的实现 实现基于MVC的应用需要完成以下工作,如图5-8所
示:
分析应用问题,对系统进行分离
设计和实现每个视图
设计和实现每个控制器
使用和安装、卸载控制器 图5-8 MVC的实现
29
(1)分析应用问题,对系统进行分离 (2)设计和实现每个视图 (3)设计和实现每个控制器 (4)使用可安装和卸载的控制器
C
A
B
X
图5-3
管道-过滤器的可扩展性
清华大学出版社
10
(4)支持特殊的分析:如吞吐量计算和死 锁检测等。利用管道-过滤器模式图,可以很容 易地得到系统的资源使用与请求状态图,然后, 根据操作系统原理等相关理论中的死锁检测方法 就可以分析出系统目前所处的状态,是否存在死 锁可能及如何消除死锁等问题。
相关文档
最新文档