软件系统总体架构图-系统架构设计师 er图

软件、架构、设计

3.2信息系统设计

3.2.1方案设计

系统方案设计包括各部分的总体设计和详细设计(物理设计)。

(1)系统总体设计：包括系统总体架构设计、软件系统总体架构设计、数据存储总体设计、计算机及网络系统方案设计等。

(2)详细的系统设计：包括代码设计、数据库设计、人机界面设计、加工工艺设计等。

第二版P134@3.2.1

问题概率：

180313、190113

点击以下链接：领取6G软测试准备套件

软考培训_软考认证_软考时间-51CTO学校

包括软考、16本电子官方教材、36本教程教材、27套官方真实冲刺卷、21套必修知识点

3.2.2系统架构

系统架构将整个系统分解成更小的子系统和组件，从而形成不同的逻辑层或服务。之后进一步确定各层的界面和层间关系。对于整个系统的分解，既要纵向分解，也要把同一个逻辑层分块横向分解。系统可以参照“架构模式”进行分解。

通过对系统的一系列分解，最终形成系统的整体框架。系统选择主要取决于系统

架构。

第二版P134@3.2.2

出题概率：★

180113

3.3软件工程

3.3.2软件设计、测试与维护

（2）软件测试

测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。软件测试是针对一个程序的行为，在有限测试用例集合上，动态验证是否达到预 期的行为。

测试不再只是一种仅在编码阶段完成后才开始的活动。现在的软件测试被认为是一种应该包括在整个开发和维护过程中的活动，它本身是实际产品构造的一个重要部分。

软件测试伴随开发和维护过程，通常可以在概念上划分为单元测试、集成测试和系 统测试三个阶段。

第二版P135@3.3.2

出题概率：★

140310

（3）软件维护

将软件维护定义为需要提供软件支持的全部活动。这些活动包括在 交付前完成的活动，以及交付后完成的活动。交付前要完成的活动包括交付后的运行计 划和维护计划等。交付后的活动包括软件修改、培训、帮助资料等。

软件维护有如下类型：

①更正性维护：

更正交付后发现的错误；

②适应性维护：

使软件产品能够在变化后或变化中的环境中继续使用；

③完善性维护：

改进交 付后产品的性能和可维护性；

④预防性维护：

在软件产品中的潜在错误成为实际错 误前，检测并更正它们。

第二版P136@3.3.2

出题概率：★★★★

150315、160111、170316、190112

3.3.3软件质量保证及质量评价

软件质量指的是软件特性的总和，是软件满足用户需求的能力，即遵从用户需求，达到用户满意。软件质量包括“内部质量”“外部质量”和“使用质量”三部分。软件需求定义了软件质量特性，及确认这些特性的方法和原则。

软件质量管理过程由许多活动组成，一些活动可以直接发现缺陷软件系统总体架构图，另一些活动则检查活动的价值。其中包括质量保证过程、验证过程、确认过程、评审过程、审计过程等。

（1）软件质量保证：通过制订计划、实施和完成等活动保证项目生命周期中的软件产品和过程符合其规定的要求。

（2）验证与确认：确定某一活动的产品是否符合活动的需求，最终的软件产品是否达到其意图并满足用户需求。

验证过程试图确保活动的输出产品已经被正确构造，即活动的输出产品满足活动的规范说明；确认过程则试图确保构造了正确的产品，即产品满足其特定的目的。

（3）评审与审计：包括管理评审、技术评审、检查、走查、审计等。管理评审的目的是监控进展，决定计划和进度的状态，或评价用于达到目标所用管理方法的有效性。技术评审的目的是评价软件产品，以确定其对使用意图的适合性。

软件审计的目的是提供软件产品和过程对于可应用的规则、标准、指南、计划和流程的遵从性的独立评价。审计是正式组织的活动，识别违例情况，并要生成审计报告，采取更正性行动。

第二版P136@3.3.3

出题概率：★★

180114、190311

3.3.6软件开发工具

软件开发工具是用于辅助软件生命周期过程的基于计算机的工具。通常使用这些工具来支持特定的软件工程方法，减少手工方式管理的负担。工具的种类包括支持单个任务的工具及涵盖整个生命周期的工具。

第二版P137@3.3.6

出题概率：★

190114

3.4面向对象系统分析与设计

3.4.1面向对象的基本概念

1. 对象：

由数据及操作所构成的封装体，是系统中用来描述客观事物的一个模块，是构成系统的基本单位。用计算机语言来描述，对象是由一组属性和对这组属性进 行的操作构成的。

对象包含三个基本要素，分别是对象标识、对象状态和对象行为。例如，对于姓名 (标识）为Joe的教师而言，其包含性别、年龄、职位等个人状态信息，同时还具有授课 等行为特征》Joe就是封装后的一个典型对象。

2. 类：

现实世界中实体的形式化描述，类将该实体的属性（数据）和操作（函数) 封装在一起。

类和对象的关系：对象是类的实例

3. 抽象：

通过特定的实例抽取共同特征以后形成概念的 过程。抽象是一种单一化的描述，强调给出与应用相关的特性，抛弃不相关的特性。对象是现实世界中某个实体的抽象，类是一组对象的抽象。

4. 封装：

将相关的概念组成一个单元模块，并通过一个 名称来引用它。面向对象封装是将数据和基于数据的操作封装成一个整体对象，对数据 的访问或修改只能通过对象对外提供的接口进行。

5．继承

表示类之间的层次关系（父类与子类），这种关系使得某类对象可以继承另外一类对象的特征，继承又可分为单继承和多继承。

(6)多态：

使得在多个类中可以定义同一个操作或属性名，并在每个类中可以有不 同的实现。多态使得某个属性或操作在不同的时期可以表示不同类的对象特性。

(7)接口：

描述对操作规范的说明，其只说明操作应该做什么，并没有定义操作如 何做。可以将接口理解成为类的一个特例，它规定了实现此接口的类的操作方法，把真正的实现细节交由实现该接口的类去完成。

(8) 消息。

体现对象间的交互，通过它向目标对象发送操作请求。

(9) 组件：

表示软件系统可替换的、物理的组成部分，封装了模块功能的实现。组 件应当是内聚的，并具有相对稳定的公开接口。

(10) 复用：

指将己有的软件及其有效成分用于构造新的软件或系统。组件技术是 软件复用实现的关键。

(11) 模式：

描述了一个不断重复发生的问题，以及该问题的解决方案。其包括特定 环境、问题和解决方案三个组成部分。应用设计模式可以更加简单和方便地去复用成功 的软件设计和架构，从而帮助设计者更快更好地完成系统设计。

第二版P138@3.4.1

出题概率：★★★★★

160315、170116、170315、180115、180315、190115、190312

3.5软件架构

3.5.2软件架构模式

常见的典型架构模式如下。

1．管道/过滤器模式

此模式中，每个组件（过滤器）都有一组输入/输出，组件 读取输入的数据流，经过内部处理后，产生输出的数据流，该过程主要完成输入流的变 换及增量计算。其典型应用包括批处理系统。

管道/过滤器模式体现了各功能模块高内聚、低耦合的“黑盒”特性，支持软件功能 模块的重用，便于系统维护；同时，每个过滤器自己完成数据解析和合成工作（如加密 和解密），易导致系统性能下降，并增加了过滤器具体实现的复杂性。如图3-4所示。

2．面向对象模式

模式：在面向对象的基础上，将模块数据的表示方法及其相应操作封 装在更高抽象层次的数据类型或对象中。其典型应用是基于组件的软件开发(Component-Based Development，CBD)。

3．事件驱动模式

其基本原理是组件并不直接调用操作，而是触发一个或多个事件。系统中的其他组件可以注册相关的事件，触发一个事件时，系统会自动调用注册了 该事件的组件，即触发事件会导致另一组件中操作的调用。其典型应用包括各种图形界面应用。

4．分层模式

采用层次化的组织方式，每一层都为上一层提供服务，并使用下一 层提供的功能。该模式允许将一个复杂问题逐步分层实现。其中的每一层最多只影响相 邻两层，只要给相邻层提供相同的接口，就允许每层用不同的方法实现，可以充分支持 软件复用。其典型应用是分层通信协议，如ISO/OSI的七层网络模型。此模式也是通用 应用架构的基础模式

5．客户机／服务器模式（Client/Server, C/S):

基于资源不对等，为实现共享而提出 的模式。C/S模式将应用一分为二，服务器（后台）负责数据操作和事务处理，客户（前 台）完成与用户的交互任务。

第二版P142@3.5.2

出题概率：★★★★

140312、160316、180116、190313

3.5.4软件中间件

“中间件的分类及特点”

中间件（Middleware)是位于硬件、操作系统等平台和应用之间的通用服务。借由 中间件，解决了分布系统的异构问题。

中间件服务具有标准的程序接口和协议。不同的应用、硬件及操作系统平台，可以提供符合接口和协议规范的多种实现，其主要目的是实现应用与平台的 无关性。借助中间件，屏蔽操作系统和网络协议的差异，为应用程序提供多种通讯机制, 满足不同领域的应用需要。

中间件包括的范围十分广泛，针对不同的应用需求有各种不同的中间件产品。从不 同角度对中间件的分类也会有所不同。通常将中间件分为数据库访问中间件、远程过程 调用中间件、面向消息中间件、事务中间件、分布式对象中间件等。

（1）数据库访问中间件：

通过一个抽象层访问数据库，从而允许使用相同或相似的代码访问不同的数据库资源。典型技术如 Windows平台的 ODBC和 Java平台的 JDBC等。

（2）远程过程调用中间件（Remote Procedure Call，RPC）：

是一种分布式应用程序的处理方法。一个应用程序可以使用 RPC来“远程”执行一个位于不同地址空间内的过程，从效果上看和执行本地调用相同。

一个 RPC应用分为服务器和客户两个部分。服务器提供一个或多个远程操作过程；客户向服务器发出远程调用。服务器和客户可以位于同一台计算机，也可以位于不同的计算机，甚至可以运行在不同的操作系统之上。客户和服务器之间的网络通讯和数据转换通过代理程序（Stub与 Skeleton）完成，从而屏蔽了不同的操作系统和网络协议。

（3）面向消息中间件（ Message-Oriented Middleware，MOM）：

利用高效可靠的消息传递机制进行平台无关的数据传递，并可基于数据通信进行分布系统的集成。通过提供消息传递和消息队列模型，可在分布环境下扩展进程间的通信，并支持多种通讯协议、语言、应用程序、硬件和软件平台。典型产品如 IBM的 MQSeries。

（4）分布式对象中间件：

是建立对象之间客户 /服务器关系的中间件，结合了对象技术与分布式计算技术。该技术提供了一个通信框架，可以在异构分布计算环境中透明地传递对象请求。典型产品如 OMG的 CORBA、Java的 RMI/EJB、Microsoft的 DCOM等。

（5）事务中间件：

也称事务处理监控器（ Transaction Processing Monitor，TPM），提供支持大规模事务处理的可靠运行环境。TPM位于客户和服务器之间，完成事务管理与协调、负载平衡、失效恢复等任务，以提高系统的整体性能。典型产品如 IBM/BEA的 Tuxedo。结合对象技术的对象事务监控器（ Object Transaction Monitor，OTM）如支持 EJB的 JavaEE应用服务器等。

第二版P143@3.5.4

出题概率：★★★★

180316、190116、190315

以下为第一版内容，仅供参考

软件需求的3 个层次

业务需求（ Business requirement ） 表示组织或客户高层次的目标。

用户需求（ user requirement ） 描述的是用户的目标，或用户要求系统必须能完成的任务。

功能需求（ functional requirement ） 规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（ behavioral requirement ）

出题概率：★

160115

结构化分析方法

结构化分析方法(Structured Method)是强调开发方法的结构合理性以及所开发软件的结构合理性的软件开发方法。结构是指系统内各个组成要素之间的相互联系、相互作用的框架。

结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表以及判定树等。

出题概率：★

160114

结构化分析基本思想

结构化分析方法的基本思想是自顶向下逐层分解。分解和抽象是人们控制问题复杂性的两种基本手段。

出题概率：★

160127

结构化分析的常用工具

1、数据流图（DFD-Data Flow Diagram）

数据流图是描述数据处理过程的工具，是需求理解的逻辑模型的图形表示，它直接支持系统的功能建模。

2、数据字典（DD-Data Dictionary）

数据字典是结构化分析方法的核心。数据字典是对所有与系统相关的数据元素的一个有组织的列表，以及精确严格的定义，使用户和系统分析员对输入、输出、存储和中间结果有共同的理解。

数据字典的作用是对数据流图（DFD）中出现的被命名的图形元素的确切解释，通常数据词典包含的信息有：名称、别名、何处使用/如何使用、内容描述、补充信息等。

3、判定树

使用判定树进行描述时，应先从问题定义的文字描述中分清哪些是判定条件，哪些是判定结论，根据描述材料中的连接词找出判定条件之间的从属关系、并列关系、选择关系，根据它们构造判定树。

4、判定表

判定表和判定树似是而非，当数据流图中的加工要依赖于多个逻辑条件的取值，即完成该加工的一组动作是由于某一组条件取值的组合而引发的，使用判定表描述比较适宜。

判定由四部分组成：（1）基本条件；（2）条件项；（3）基本动作；（4）动作项

出题概率：★

170114

软件需求分析与定义

软件需求是一个为解决特定问题而必须由被开发或被修改的软件展示的特性。这个问题可能是使用软件的某人的任务中的一个自动化部分，或是支持委托开发软件的组织的业务流程，或修正当前软件的缺点，或是控制一个设备等。用户、业务流程和设备的功能通常很复杂，因此软件系统总体架构图，特定软件的需求在外延上通常是来自一个组织不同层次的不同人员的需求和来自软件将要在其中运行的环境的需求的复杂组合。

所有软件需求的一个基本特性就是可验证性。验证某些软件需求可能很困难或者成本很高。软件需求和软件质保人员都必须保证，在现有的资源约束下，需求可以被验证。

除了其表达的行为特性外，需求还有其他特性，如优先级，以便在资源有限时进行权衡。通常，要唯一地标识软件需求，才能在整个软件生命周期中，进行软件配置控制和管理。

需求分析涉及分析需求的过程，其目的如下。

(1)检测和解决需求之间的冲突。

(2)发现软件的边界，以及软件与其环境如何交互。

(3)详细描述系统需求，以导出软件需求。

描述需求时必须仔细，应该精确到能确认需求，验证需求的实现，估算需求的成本。

P101@3.3.1

出题概率：★★

140113、150314