软件体系结构-第3章(设计方法)
软件体系结构设计技术手册
软件体系结构设计技术手册软件体系结构是指软件系统中最高层的抽象表达，包含了系统的组织结构、关键机制、成员职责等信息。
软件体系结构设计技术手册是开发工程师在进行软件开发过程中进行软件设计时使用的重要文献，有助于提高软件系统的可靠性和可维护性。
本文将阐述软件体系结构设计的基本概念、设计流程、常用的设计方法、以及如何进行软件体系结构的评估和演化。
一、软件体系结构设计的基本概念软件体系结构是针对软件系统而言的，包含了软件系统的机制、组件、交互，以及这些机制和组件所涉及到的关键约束。
软件体系结构的设计是软件开发过程中的一个极其重要的步骤，是确定软件的可靠性、可维护性、易扩展性以及性能的关键所在。
软件体系结构的设计需要满足一定的准则：指导问题分解，提供系统架构的概念完整性，体现系统最重要的特性。
软件体系结构的设计需要考虑以下几个方面：1.软件系统的功能需求和非功能需求；2.软件系统的使用场景；3.使用的开发工具和开发语言；4.软件系统的架构样式。
二、软件体系结构设计的流程在软件体系结构设计过程中，需要考虑多个因素，主要分为五个阶段：需求分析、体系结构设计、详细设计、编码和测试。
1.需求分析：该阶段是整个软件开发的第一个阶段，其中对软件系统的需求进行分析，以确定软件体系结构所需要的功能需求和非功能需求。
2.体系结构设计：体系结构设计阶段是在完成需求分析阶段后进行软件设计的第二个主要步骤。
在这个阶段，开发人员必须考虑应用程序的整体结构，设计并定义整个应用程序的组织结构以及各组表示的职责。
3.详细设计：此阶段的目的是详细描述整个软件系统的功能以及每个过程所需要的细节。
在这个阶段，工程师需要细化构件的职责、定义接口以及定义各种数值元件（例如变量、常量、函数和参数）。
4.编码：在这个阶段，开发人员使用选定的开发工具和编程语言将详细设计的规范转换为源代码。
5.测试：在这个阶段，测试人员使用一系列测试用例来测试应用程序以及体系结构的正确性和完整性。
软件体系结构课件3 软件体系结构层面的设计策略
分 析
阶
段
需求导出
需求描述
需求检查
不合格
生成功能规范 评审功能规范
体
设计体系结构风格
系
设
计
阶
设计构件
设计连接器
段
生成体系结构规范
不合格
评审体系结构规范
系
选择设计平台
统 设
计
阶
子系统设计
段
内部构件设计
接口设计
数据结构设计
算法设计
不合格
生成设计规范 评估设计规范
增量规划
使用设计空间对设计过程进行拆分
1
• 很多体系结构风格的数据流和控制流都是同构的，包括顺序 批处理风格，数据流网络和C/S风格架构，但是也有一些体系 结构风格是不同构的，例如黑板模型。
PSAS方法主流程
1.为系统需要提供的服务进行进行用例分析。需要提供的服务在架构功能说明书 中被指定。 2.对于每一个在用例中的服务，从构架库中选择最合适的构件，并且构件基础构 件列表。 3.如果基本构件列表中的每一个构件，通过4.5.2中的方法判别系统整体的构件 类型，如果所有的构件不是同一种类型，我们把最多的类型作为系统整体构件类 型。 4.如果基本构件列表中的每一个构件，通过4.5.2中的方法判别系统整体的连接 器属性类型，如果所有的连接器不是同一种类型，我们把最多的类型作为系统整 体连接器类型。 5.使用4.5.2中的方法绘制控制列表，判别系统的控制类型，包括拓扑结构和同 步方式 6.使用4.5.2中的方法绘制数据列表，判别系统的数据类型，包括数据拓扑和连 续性类型。 7.确定是或否同构 8.查找表4-1来判断最合适的软件体系结构风格。如果找不到最合适的，可以选 择有相对较多的共性的风格。
软件体系结构与设计模式笔记
第1章软件体系结构概述✓SEI软件体系结构讨论群定义如下：一个程序/系统构件的结构，它们之间的相互关系，以及在设计和交付的整个过程中的原则和指导方针。
✓Mary Shaw和David Garlan认为软件体系结构包括构成系统的设计元素的描述，设计元素的交互，设计元素组合的模式，以及在这些模式中的约束。
✓软件体系结构包括构件(Component)、连接件(Connector)和约束(Constrain)或配置(Configuration)三大要素。
✓国内普遍接受的定义：软件体系结构包括构件、连接件和约束，它是可预制和可重构的软件框架结构。
✓构件是可预制和可重用的软件部件，是组成体系结构的基本计算单元或数据存储单元✓连接件也是可预制和可重用的软件部件，是构件之间的连接单元✓构件和连接件之间的关系用约束来描述✓软件体系结构= 构件+ 连接件+ 约束软件体系结构的优势容易理解、重用、控制成本、可分析性第2章软件体系结构风格♦软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
♦体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。
词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
♦体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
♦数据流风格: 批处理序列; 管道/过滤器。
♦调用/返回风格：主程序/子程序；面向对象风格；层次结构。
♦独立构件风格：进程通讯；事件系统。
♦虚拟机风格：解释器；基于规则的系统。
♦仓库风格：数据库系统；超文本系统；黑板系统。
♦过程控制环路♦C/S风格体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。
♦B/S风格浏览器/Web服务器/数据库服务器。
优点：C/S体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。
将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。
软件体系结构设计方法ppt课件
模式驱动的体系结构设计方法从模式导出体系结构 抽象。软件设计模式的目的在于编制一套可重用的 基本原则，用于开发高质量的应用系统。体系结构 模式类似于设计模式，但它关心更粗粒度的系统结 构及其交互。
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）的方法
*
者）与系统的其它的 管理员
构件是如何联系的。管
管理端子系统 *
理端的主用例图如右图：
软件体系结构
1.2软件体系结构研究的内容和范畴
• 体系结构风格、设计模式和应用框架的概念是从不同的目的和出发点讨论
软件体系结构，它们之间的概念经常互相借鉴和引用。
1.3体系结构设计原则
• 抽象
• 分而治之
• 封装和信息隐藏
• 模块化
• 高内聚和低耦合
• 关注点分离
• 策略和实现的分离
• 接口和实现的分离
1.3体系结构设计原则
Filter将文件分离为音频流和视频流，AVI解码Filter对视频流进行解码并送往Video表现Filter，
由后者将各帧在显示器上显示，默认的DirectSound设备用DirectSound将音频流输
出。。
1.1what is SA ？
• 其次，体系结构的描述的作用好像一个框架，系
统属性在这个框架下进行扩充，并且，它在考察
设计出合适的体系结构。经验不丰富的设计师往往把注意力集中在“功能性
需求”而疏忽了“非功能性需求”，殊不知后者恰恰是最能体现设计水平的
地方。
高水平的设计师高就高在“设计出恰好满足客户需求的软件，并且使开
发方和客户方获取最大的利益，而不是不惜代价设计出最先进的软件。（以
设计住宅为例）…
对于软件系统而言，能够满足需求的设计方案可能有很多种，究竟该选
能力，新的、更大的、更复杂的问题又摆在人们的面前。
1.1what is SA ？
• 这种全局结构的设计和规划问题包括 全局组织
结构；全局控制结构；通信和同步以及数据存取
协议；规定设计元素的功能；设计元素的组合；
物理分布；规模和性能；演化的维度；设计方案
的选择等。
• 1随着软件系统的规模和复杂性不断增加，系统
软件工程中的软件体系结构与设计模式
软件工程中的软件体系结构与设计模式软件工程是一门涉及软件开发、维护、测试和管理的学科。
在软件工程的实践中，软件体系结构和设计模式是两个重要的概念。
本文将探讨软件体系结构与设计模式在软件工程中的应用和重要性。
一、软件体系结构软件体系结构是指软件系统的整体结构和组成部分之间的关系。
它描述了软件系统的组织方式、模块划分和模块之间的通信方式。
软件体系结构的设计对于软件系统的可维护性、可扩展性和可重用性具有重要影响。
在软件体系结构的设计中，常用的模式包括层次结构、客户端-服务器模式和发布-订阅模式等。
层次结构将软件系统划分为多个层次，每个层次都有特定的功能。
客户端-服务器模式将软件系统划分为客户端和服务器两个部分，客户端发送请求，服务器处理请求并返回结果。
发布-订阅模式中，发布者发布消息，订阅者接收消息。
软件体系结构的设计需要考虑多个因素，如系统的可靠性、性能、安全性和可维护性等。
一个好的软件体系结构应该能够满足系统的需求，并且易于理解和维护。
二、设计模式设计模式是在软件设计中常见问题的解决方案。
它们是经过验证的、可重用的设计思想，可以提高软件的可维护性和可扩展性。
设计模式可以分为三类：创建型模式、结构型模式和行为型模式。
创建型模式用于对象的创建，包括工厂模式、单例模式和原型模式等。
结构型模式用于对象之间的组合，包括适配器模式、装饰器模式和代理模式等。
行为型模式用于对象之间的通信，包括观察者模式、策略模式和命令模式等。
设计模式的应用可以提高软件系统的灵活性和可维护性。
通过使用设计模式，开发人员可以将系统的不同部分解耦，使其更易于修改和扩展。
此外，设计模式还可以提高代码的可读性，减少重复代码的编写。
三、软件体系结构与设计模式的关系软件体系结构和设计模式是紧密相关的概念。
软件体系结构提供了软件系统的整体框架，而设计模式提供了解决具体问题的方法。
在软件体系结构的设计中，设计模式可以用于解决不同层次和模块之间的通信问题。
软件体系结构—设计模式3.1—简单工厂模式
要提出BadShapeException 异常。
（2）请给出上一题的源代码。 （3）请简单举例说明描图员系统怎样使用。
消费角色无需知道它得到的是哪一个产品；换言之，产品消费角色无需修改 就可以接纳新的产品。
对于工厂角色来说，增加新的产品是一个痛苦的过程。工厂角色必须知道每
一种产品，如何创建它们，以及何时向客户端提供它们。换言之，接纳新的 产品意味着修改这个工厂角色的源代码。
综合本节的讨论，简单工厂角色只在有限的程度上支持“开–闭”原则。
3、多个工厂方法 每个工厂类可以有多于一个的工厂方法，分别负责创建不同的产品对象。 4、抽象产品角色的省略 如果系统仅有一个具体产品角色的话，那么就可以省略掉抽象产品角色。省 略掉抽象产品类后的简略类图如下图所示。
仍然以前面给出的示意性系统为例，这时候系统的类图就变成如下所示。
下面是工厂类的源代码。显然，这个类提供一个工厂方法，返还一个具体产 品类的实例。
简单工厂模式所创建的对象往往属于一个产品等级结构，这个等级结构可以
是MVC模式中的视图（View）；而工厂角色本身可以是控制器
（Controller）。一个MVC 模式可以有一个控制器和多个视图，如下图所示。
换言之，控制器端可以创建合适的视图端，就如同工厂角色创建合适的对象
角色一样；而模型端则可以充当这个创建过程的客户端。 如果系统需要有多个控制器参与这个过程的话，简单工厂模式就不适用了，
简单的情况下，可以简化为一个标识接口。所谓标识接口，就是没有声明任 何方法的空接口。
具体产品类的示意性源代码如下。
2.3简单工厂模式的实现
1、多层次的产品结构 在真实的系统中，产品可以形成复杂的等级结构，比如下图所示的树状结构 上就有多个抽象产品类和具体产品类。
软件设计与体系结构 第三章 软件设计基础
• 制约因素
资源：时间，人力，财力、开发工具 技术：方法、技术、平台
• 最终目标：满足需求的解决方案
明确：设计模型易于理解 可行：在可用的技术平台和软件项目的可用资源条件下，须用预定的开 发语言可构造技术可以完整地实现设计模型 高质量：设计模型给出需求的实现方案，非功能需求的约束，设计模型 优化
抽象与求精
软件设计过程
过程/算法设计
对模块内部的工作和执行过程进行描述，给出有关处理的 精确说明 事件的顺序、确切的决策位置、循环操作，数据的组成 使用UML活动图进行描述 数据模型设计： 数据结构设计、数据库设计、数据文件设计的总称 数据结构描述各数据分量之间的逻辑关系。
持久数据操作：包括写入、查询、更新和删除四类基本 操作及及由它们复合而成的业务数据操作 数据库设计：确定设计模型中需要持久保存的数据条目 数据：数据元素的格式、结构、访存、表示等机制进行良 好的建模和优化，是提高软件设计质量和系统性能的基础， 对软件系统的应用具有重要意义
部数据或 不通过正 常入口而 转入C的内 部。
内聚与耦合
例2：部分代 码重叠（常出 现在汇编程序 中）
A B
例3：一个模 块有多个入 口（功能）
A: ……………… ……………… entry 1: ……………… ……………… entry 2: ……………… ………………
The least desirable
B A M C
M的控制域为 {M，A，B，C}
作用域：M中的一个判定所影响的模块。
例如：
A: ………… if …… then goto B1 ………… ………… B: ………… ………… B1: ………… ………… A: ………… if …… then goto M1 ………… ………… M: ………… ………… M1: goto C1 ………… …………
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
各阶段设计的任务
实现阶段 在测试环境中创建和部署试验性和/或原型部署 设计和运行功能性测试来衡量与系统要求的符合 度 设计和运行负载测试来衡量峰值负载下的性能 创建生产部署，可能需要分阶段部署到生产中
架构设计-架构源自需求
为什么要从需求开始？
IT界的技术层出不穷，面对着如此之多的技术、平台、 框架、函数库，我们如何选择一组适合软件的技术？
架构设计阶段划分
架构设计前准备阶段（预备架构阶段）
概念架构设计阶段 精华架构设计阶段
预备架构阶段
最大误区：架构师是技术人员不必懂需求
实践要点：摒弃“需求列表”方式，建立二
维需求观。 思维工具：需求矩阵
概念架构
最大误区：概念架构=理想设计
实践要点：重大需求塑造概念架构 思维工具：鲁棒图、目标-场景-决策等
架构设计-分层模式（续）
在企业应用中，有两个非常重要的概念：业务逻
辑和持久性 企业应用是围绕着业务逻辑进行开展的 ，从业 务逻辑的底层实现来看，业务逻辑其实是对业务 实体进行组织的过程 企业应用中大部分的数据都是需要可持久化的。 因此，基础组织支持持久性就显得非常的重要
架构设计-分层模式（续）
软件体系结构
第三章 软件体系设计方法
本章要点
架构设计概述 架构设计过程 总体架构规划
架构设计分层模式
分层模式使用原则
案例
体系结构设计的目标
重用：为了避免重复劳动，为了降低成本，希望
能够重用之前的代码、之前的设计。 透明：有些时候，为了提高效率，把实现的细节 隐藏起来，仅把客户需求的接口呈现给客户。 扩展：对扩展的渴求源于需求的易变。 简明：一个复杂的架构不论是测试还是维护都是 困难的。 高效：不论是什么系统，都希望架构是高效的 安全：是架构的一个很重要的方面。
各阶段设计的任务
逻辑设计阶段 始于逻辑设计阶段。此阶段的任务是设计一个逻 辑体系结构，它应该体现能够满足技术要求阶段 所确定的使用用例和场景。
部署设计阶段 任务是创建一个反映部署方案与物理环境的映射 关系的部署体系结构。物理环境是指部署的网络 框架结构，它包括计算节点、每个节点的硬件要 求、防火墙以及网络上的其他设备。
每一个客户的软件都有自身的特点，如何才能够设计
出符合客户利益的架构？ 软件中往往都充斥着众多的问题，在一开始就把所有 的问题都想清楚往往很难做到，但是如果不解决问题， 风险又居高不下
架构设计-架构源自需求（举例）
例1：城市中自来水管的架设是一项非常的复杂的 工程。为了需要满足每家每户的需要，自来水管 组成了一个庞大的网络。在这样一个复杂的网络 中，如何完成铺设的任务呢。一般的做法是，先 找出问题的根源，也就是水的源头。从水源铺设 一条管道通至城市，然后根据城市的区域划分， 设计出主管道，剩下的就是使用的问题了，每家 每户的管道最终都是连到主管道上的。因此，虽 然自来水网络庞大复杂。但是真正的主管道的非 常简单的。
必做功能 识别方法：在用户愿景文档中的主要特征 高风险功能 独特功能
举例：确定关键质量与关键功能
确定关键质量
确定关键质量与关键功能（续）
确定必做功能
Amazon的特点在于它的专业、便捷、实惠，
最终体现这些特点的功能就是必做功能：
评价功能----专业
多角度关联信息----专业
为软件全局设置的架构愿景可以以原则、或是模
式名的方式体现，并用自然语言或伪代码描述。 需要强调的是总体架构规划的制定是根据不同的 应用环境而变化的
总体架构规划的层次-软件全局（续）
举例：在JAVA环境中
客户端采用前端浏览器界面。
业务逻辑采用servlet，配合JSP编写。 浏览器到服务器的数据采用集中处理，具体的方法是
架构设计-架构源自需求（续）
需求的划分
非功能需求：定义了一些性能、效率上的一些约束、 规则，决定技术架构。
功能需求：定义了软件能够做些什么？决定业务架构。
变化案例：变化案例是对未来可能发生的变化的一个 估计，决定架构的范围。
架构设计-架构源自需求（举例）
举例：我们打算开发一个字处理软件，功能需求 可以简单概括为格式化用户输入的文字，非功能 需求可能是格式化大小为1000K的一段文字的处 理速度不能低于10S，变化案例可能是推出多种 语言版本。那么我们在设计业务架构的时候，我 们会集中于如何表示文字、图象、媒体等要素， 我们该需要有另外的技术架构来处理速度问题， 比如缓冲技术，对于变化案例，我们也要考虑相 应的架构，比如把字体独立于程序包的设计。
总体架构的形成过程-使用架构模式
初步设计
初步设计的目标是发现职责，为高层切分奠
定基础 初步设计不是必须的，但当待设计系统对架 构师而言并无太多直接经验时，则强烈建议 进行初步设计 基于关键功能，借助鲁棒图进行初步设计
功能影响架构的基本原理：职责协作链
初步设计方法-鲁棒图分析
基于关键功能，进行初步设计
总体架构规划的层次-代码级的规划
严格的说这一层次的规划已经不是真正的愿景，
而是具体设计了 这一个层次的规划一般可以使用类图、接口来表 示。但在类图中，不需要标记出具体的属性、操 作，只需要规定出类的职责以及类之间的相互关 系就可以了 比较重要的工作在于问题如何分解和如何归并 分解主要是从两个维度来考虑
需要注意的问题
初步设计的目标是发现职责，初步设计无需
展开架构设计细节
高层分割的实践法则
切系统为系统
切系统为子系统
架构设计-分层模式
分而治之的思想是计算机领域非常重要的思想
分层的优势 ： 上层的逻辑不需要了解所有的底层逻辑，它只需要了 解和它邻接的那一层的细节 不同层间的耦合度明显降低。通过严格的区分层次， 大大降低了层间的耦合度。 某一层次的下级层可以有不同的实现 同一个层次可以支持不同的上级层
软件需求各组成部分之间的关系
需求层次划分
业务级需求：包含客户要达到的业务目标、
预期投资、工期要求，以及要符合哪些标准、 对哪些遗留系统进行整合等约束条件 用户级需求：用户使用系统来辅助完成哪些 工作？对质量有何要求？用户群及所处的使 用环境方面有何特殊要求？ 开发级需求：开发人员需要实现什么？开发 期间、维护期间有何质量考虑？开发团队的 哪些情况反过来影响架构？
问题大小维
时间长短维
总体架构的形成过程
总体架构规划的形成的源头是需求，需要特别指
出的是，这里的需求主要是那些针对系统基本面 的需求。 总体架构规划的主要目的就是为了能够在开发团 队中传播设计思路，因此，总体架构规划包括基 本的设计思路和基本的设计原则 总体架构规划可能会有多种的视角
不同需求影响架构的原理不同
需求种类
功能需求：体现各级直接目标要求
质量属性：运行期质量 + 开发期质量 约束需求：业务环境质量 + 使用环境因素 +
构建环境因素 + 技术环境因素
需求结构化的原因
通过需求层次-需求方面矩阵，高屋建瓴地把
握复杂系统的需求大局：
将复杂的需求集合梳理得井井有条，可以全面理
理解需求
建立需求大局观 确定架构设计方向
在预备架构总体工作内容
在架构设计之初，就全盘考虑架构设计要重
点支持的关键质量目标 在第一时间就判断这些“关键质量”之间有 没有冲突关系，并制定权衡取舍策略
预备架构阶段指导原则
需求结构化
分析约束影响 确定关键质量
确定关键功能
每个子设计团队可以从别人那里吸取设计经验
总体架构规划的层次-子模块级、或是子 问题级（续）
子模块（子问题）间的耦合问题 ： 各个子模块间的耦合程度相对较小 子问题间的耦合程度就比较大 具体的做法： 为子模块（子问题）制定出合同接口（Contact Interface） 系统中的一些全局性的子问题最好是提到全局愿景中 考虑
分析约束影响（推导法则）
分析约束影响（续）
分析约束影响（续）
分析约束影响（查漏法则）
确定关键质量的原则
分类合适 + 必要扩充
考虑多方涉众 检查性思维
识别矛盾 + 划定优先级
严格程度符合领域与规模特点
质量属性关系矩阵
确定关键功能的规则
核心功能 识别方法：业务层的接口要反映这些功能
解需求的各个层次、各个方面 为分析不同需求之间联系，做出权衡折衷的依据 识别遗漏需求、发现延伸需求奠定基础
举例：大型B2C网站
象Amazon这样大型的B2C网站，架构的起步
阶段应如何规划呢？ 方法
需求结构化
分析约束影响 确定关键质量 确定关键功能
先梳理业务需求
再梳理重点用户需求
最快的全库搜索----便捷 频率极高的新货上架----便捷 灵活的打折设置----实惠
概念架构阶段
概念架构设计的步骤 初步设计，基于关键功能，借助鲁棒图进行发现 职责为目的的初步设计 高层分割：对系统进行高层切分 考虑非功能需求
总体架构规划
总体架构应该能够提供软件全局视图，包括所有
在业务逻辑和前端浏览器之间采用Front Control模 式，接受前端浏览器传送过来的数据，并指派给相应 的业务逻辑处理。 数据的合法性检验分为两个部分：
和业务逻辑无关的基本合法性验证在前端使用Java Script 处理。 和业务逻辑相关的合法性验证在业务逻辑层处理，可以使 用一个集中的servlet专门处理错误情况。
细化架构
最大误区：架构=模块+接口
实践要点：贴近实践的五视图法 思维工具：包图、包-接口图、灰盒包图、序
列图、目标-场景-决策表等