软考系统架构设计师 - 第 14 章 基于ODP的架构师实践

已阅第14小时和教程。涉及单选题。

本章在RM-ODP（参考模型-开发分布式进程）多视点架构模型上，探讨应用于分布式信息系统的软件架构方法，对软件生命手气其它阶段的影响，特别是架构师在开发过程中的任务与作用。

14.1 基于ODP的架构开发过程

开放分布进程的参考模型（RM-ODP）是一个ISO标准，它为分布式计算进程提供了一个框架。其定义了5个视点（企业视点、信息视点、计算视点、工程视点、技术视点）和整个系统及架构开发的10个过程，如下图所示：

不同视图解决不同方面的内容，这是应对复杂问题的基本研究方法（分治）。

14.2 系统构想

1. 定义

系统构想是指系统开发人员与用户之间的共同协议。按照该协议，系统开发人员需要在特定的时间内完成用户的需求。

构想描述了从需求分析开始的所有项目活动的语境，它高度概括了企业业务架构的核心内容。

2. 架构师的作用

系统构想阶段，架构师合理的介入，有以下好处：

• 有利于使架构师本身对系统的看法更加全面、准确
• 有利于统一开发人员对系统的看法
• 有利于正确确定需求的优先次序
• 可以在最大程度上提高客户对设计等过程的参与程度，更好地与客户沟通

14.3 需求分析

1. 架构师的工作

架构师对需求分析通常考察6个方面的内容：

• 需求的适用性
• 确定需求的优先级
• 为需求建立功能结构模型
• 使用质量功能分配（Quality Function Deployment，QFD）
• 用户接口原型
• 系统范围对象关系图

架构师的一个有效的捕捉行为需求的方法是分析用例。

2. 需求分析的任务

目的：完整、准确地描述用户对系统的需求，跟踪用户需求的变化。

特点：追求系统需求的完整、一致性和验证性

• 完整性：准确、全面地描述用户对系统架构的需求
• 一致性：通过分析用例，提出用户需求矛盾的地方，规范用户需求
• 验证性：是需求一致性的表现形式。包含几个含义：保持和用户要求的同步；保持需求分析各侧面之间的一致；保持需求和系统设计间的同步

14.4 系统架构设计

1. ODP视点

开发分布式处理（Open Distributed Processing，ODP）从5个标准的视点组织分析了系统的架构，描述了同一系统的重要方面。

2. 企业业务架构（企业视点）

企业业务架构从IT的角度，对企业的业务结构、企业结构与业务的关系、企业内部的关系以及企业与外部起购的关系进行整理定义。

企业业务架构包含的内容：

• 企业的业务和战略目标
• 企业的组织机构
• 业务的分类
• 各类业务之间的关系
• 组织机构与业务的关系
• 企业与外部机构的关系

3. 逻辑信息架构（信息视点）

逻辑信息架构表示出系统必须知道什么。这种架构通过一个对象模型来表达，强调定义系统状态的属性。

软件架构对象并不是编程的对象，它表示对系统的约束和依赖。这些约束能够消除在把需求翻译成软件过程中的许多猜测性工作。

4. 计算接口架构

它定义了顶层的应用程序接口，这些是完全工程化的子系统边界的接口。

ODP架构的一个ISO标准采用的是CORBA接口定义语言（IDL）。IDL是一种基本记法，它完全独立于编程语言和操作系统。IDL可以被编译器自动翻译成Java、C++、C#等大多数流行的编程语言。

5. 分布式工程架构

分布式工程架构定义了底层结构的需求，而独立于所选择的技术。其很好的解决了一些最复杂的系统策略，其中包括物理位置、系统规模可变性和通信服务质量。

在进行分布式工程架构建模时，必须考虑系统的各个方面，如对象复制、多线程和系统拓扑等。

6. 技术选择架构（技术视点）

技术选择架构确定了实际的技术选择，所有其它视点都独立于这些决定。

架构师选择的原因是非常重要的，因为这些观点可以作为以后架构约束的理由。

14.5 实现模型

最终用户和架构师应在一起审核并贯穿于用例（业务场景、质量场景、易变场景）始终来证实需求的有效。

通过模型，管理层能够看到可视化的进展。

多数系统可以采用快速原型技术生成模型。

14.6 架构原则

在完成上述任务之后，从构建的草图进而发展成产品原型。架构原型是很好的需求验证工具，它能够帮助利益相关人检测系统契合用户操作的程度。可以使用各种各样的方法（比如故事板）构建架构原型，而非编码一种。

架构框架是对系统架构的一种可运行验证工具，通过对系统的API定义的编译以及编写小程序来模拟运行的系统。架构框架用于正式计算和工程体系架构，包括穿越分布式边界的控制和定时。

为了构建实际的系统，初始的架构原型需要进行演化，一般会进过2到3次迭代后，架构变得稳定。主要的抽象对象已经被找到；子系统和过程都已经完成；所有的接口都已经明确定义。

在系统架构开发过程中，利用架构原型，至少有如下好处：

• 在架构落实前，组员自由讨论，提出建议，对架构原型进行完善修正
• 统一组员思想看法、提高系统开发成功率
• 对系统内部结构分析与设计有帮助

14.7 项目规划

项目规划是一份已经通过批准的正式文档，它根据项目的目标，对项目实施进行的各项活动作出规定，以它为基准跟进和控制项目，确定未来的行动方案和资源分配，引导项目的实施。其主要作用是将制定规划的假设和决定以及批准的范围、成本、进度的基线等用正式的文档记录保存。

项目规划是基于当前已有的信息，包括过去的经验，当前的目标、范围、组织结构、资源等，工作活动、里程碑、质量目标和风险管理等，其中估算是项目规划的核心。

项目规划包含的内容：

• 项目的目的、范围、目标和对象
• 软件生命周期的选择
• 精选的供开发和维护软件用的规程、方法和标准
• 待开发的软件工作产品
• 软件工作产品的规模估计、软件项目的工作量和成本估计
• 关键计算机资源的估计；项目的里程碑
• 风险识别和评估
• 工程设施和支持工具计划

14.8 并行开发

1. 意义

提高软件生产率和改善软件质量。

2. 主要研究内容

• 软件过程及模型
• 并行成分划分（核心问题）
• 并行控制
• 支持环境
• 交互机制与集成技术

3. 什么是开发子过程？

把软件系统的开发过程划分为若干个可以并行的部分，这个部分称之为子开发过程。子开发过程 = 开发小组 + 软件对象 + 对软件对象的开发活动。

4. 并行开发系统及其生命周期

把整个并行开发活动看作是一个并行系统，称为并行开发系统。子开发过程是对并行开发系统的一种动态描述，此系统中的实体是开发小组，实体属性是被开发的软件对象，行为是开发软件对象的活动。每个子开发过程完成一个子系统或一个模块的开发任务，当各个子开发过程都完成后，进行系统集成和测试，最终完成整个系统的开发。

5. 并行模块划分

并行模块的划分是并行开发中的核心问题，模块独立性是衡量软件设计质量的关键。有两种划分方法：基于Petri网系统模型的动态划分方法、基于脚本的系统划分方法。

6. 并行控制

并行控制是要用正确的方式调度并行操作，避免造成不一致性，使一个操作的执行不受其它操作的干扰。为保证开发出的系统内部各成分间的一致性、相容性，保证系统的正确性和可靠性，就要进行并行控制。常用的并行控制手段有加锁、时间戳、管程、Petri网和PV操作等。

14.9 系统转换

1. 定义

系统转换是指运用某种方式由新的系统代替旧的系统的过程，也就是系统设备、系统数据和人员等方面的转换。

2. 准备工作

系统转换的准备工作：系统设备、数据、人员、有关文件（比如操作手册）的准备、系统试运行。

3. 转换方式

系统转换方式：

• 直接转换：新的装好，老的直接停掉
• 平行转换：新旧共同运行一段时间，待新系统稳定后，停用旧系统
• 分段转换：一次只用新系统中的部分功能替换旧系统的相应部分，逐步完成新系统替换旧系统
• 分批转换：先在小范围内试点，然后再全部推广到所有

4. 注意事项

• 提前准备新系统需要的基础数据（整理、录入数据工作量大）
• 注意人员的转换，做好人员的培训工作
• 为系统运行时出现问题做好准备，保存记录

14.10 操作与维护

软件交付后，进入正常的运行操作与维护时期。

1. 系统操作与维护的内容

• 数据管理与维护：数据收集、数据整理、数据录入、数据分发、数据库管理
• 机器设备的管理与维护：硬件维护、机器日常行政管理、系统操作记录、用户服务等
• 系统软件的管理与维护
• 应用软件的管理与维护
• 代码维护

2. 系统的可维护性（是判定系统架构好坏的一个重要方面）

定义为：维护人员理解、改正、改动和改进这个软件的难易程度，提高可维护性是开发管理系统所有步骤的关键目的。

系统可维护性的评价指标：可理解性、可测试性、可修改性。

系统维护的分类：

• 更正性维护：bug
• 适应性维护：环境变化
• 完善性维护：新需求
• 预防性维护

系统维护的步骤：

14.11 系统移植

1. 系统移植方法

• 不修改已有软件，可以使用的方法有高位互换、仿真功能和虚拟机功能
• 修改软件，把已有软件资源（程序、数据、计算机应用方法及各种说明书）转换为与新机器具有匹配性的软件
• 重编软件，从有逻辑设计开始，从程序设计开始和从编程开始三种开发方式

2. 移植工作的阶段划分

• 计划阶段：调查整理、探讨如何转换、决定移植方法、确定移植工作体制及移植日程
• 准备阶段：准备转换所需资料
• 转换阶段
• 测试阶段：核实程序能否在新系统中准确地工作
• 验证阶段