2011年软考系统架构设计师学习笔记第十四章(完)

 基于ODP的架构师实践

　　14.1 基于ODP的架构开发过程

　　系统架构反映了功能在系统系统构件中的分布、基础设施相关技术、架构设计模式等，它包含了架构的原则和方法、构件关系与约束，并能支持迭加或增量开发。

　　以软件架构为中心的开发过程是以质量和风险驱动的，最终提供一个稳定、低风险的系统架构，并满足客户的需求(包含潜在需求)。

　　开放分布进程的参考模型(RM-ODP)是一个ISO标准，定义了分布系统的重要性质：

　　开放性、整体性、灵活性、可塑性、联合性、可操作管理性、优质服务、安全性、透明性。

　　RM-ODP定义的 5个观点：

　　1、企业视点：商业需求和策略、系统的范围和目的。可能会影响系统中的与企业相关的信息，如组织结构等。

　　2、信息视点。

　　3、计算视点。

　　4、工程视点。

　　5、技术视点。

　　每一个观点有具体的建模目标和系统相关者。

　　分层子系统视图提供了一个所有子系统高度抽象的视图。

　　14.2 系统构想

　　14.2.1 系统构想的定义

　　系统构想是开发人员与用户之间共同的协议。

　　按照该协议，开发人员需要在特定的时间内完成系统用户的需求，系统构想必须简短而切中要点。

　　高度概括了业务架构的核心内容。

 

14.2.2 架构师的作用

　　系统构想有助于各方明了系统的目标和范围。

　　确保系统开发的计划、设计等阶段能依次有序地展开。

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

　　1、有利于使系统架构师本身对系统的看法更加全面、准确。

　　2、统一系统开发人员对系统的看法。

　　3、正确确定需求的优先次序。

　　4、最大程度上提高客户对设计等过程的参与程度，更好地与客户沟通。

　　14.2.3 系统构想面临的挑战

　　架构师对其控制能力之外的因素通常无能为力，可以通过有效地评估，以及高级经理和架构师之间保持紧密的联系克服这些困难。

　　还必须面对以下几种情况：

　　1、很多架构师把架构看成是他们独自的创造，只要他们认为合适的就进行修改。

　　2、有些人不是拥有产品线构想的高级经理，却总是由这些人决定雇佣谁来做架构师。

　　14.3 需求分析

　　14.3.1 架构师的工作

　　需求一般定义系统的外部行为和外观以及用户信息，而不用设计系统的内部结构。

　　对需求分析通常考察以下6个方面的内容：

　　1、系统范围对象关系图。

　　2、用户接口原型，用户操作的一个雏形。

　　3、需求的适用性，该用什么技术解决，性能怎么样，是否与其他需求相重合或矛盾，需求分析应注意需求本身的实用或适用，而不必考虑其实现。

　　4、确定需求的优先级。

　　5、为需求建立功能结构模型，组件图，实体数据对象图。

　　6、使用质量功能分配(Quality Function Deploymen，QFD)发现隐藏质量需求，建立相关质量场景，先期预测需求风险。

　　有效地捕捉行为需求的方法是分析用例(Use Case)

　　用例包含图和文字描述，符号 简单、抽象，保证表述需求时简单性和清晰度。

14.3.2 需求分析的任务

　　1、需求分析的目的

　　完整、准确地描述用户对系统的需求，跟踪用户需求的变化，准确地反映到系统架构和设计中，设计和用户的需求保持一致。

　　具有决策性、方向性、策略性的作用。

　　2、需求分析的特点

　　追求系统需求的完整性、一致性、验证性。

　　保持和用户要求同步，

　　保持需求分析各侧面之间的一致，

　　保持需求和系统设计间的同步。

　　14.3.3 需求文档与架构

　　每个用例都有一个相关需求的文字描述，定义用例应该和领域专家一起进行，如果没有领域专家的长期参与，只能是一种“伪分析”。

　　用例为定义架构提供了一个系统的领域行为模型。

　　界面的外观、功能、导航同用例紧密相连，有效定义屏幕的方法叫低保真度原型(Low-fidelity Prototyping)，领域专家也始终参与到屏幕定义中去。

　　需求分析的项目词汇表，也将在架构规划中被扩展。

　　14.4 系统架构设计

　　系统架构沟通了需求和软件之间巨大的语义上的鸿沟。

　　系统架构的第一个任务就是定义这两个极端之间的映射。

　　开放分布式处理(Open Distributed Processing，ODP)包括企业、逻辑信息、计算接口、分布式工程、技术选择。

　　对每个观点，确认架构需求的一致性是非常重要的。

　　14.4.1 企业业务架构

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

　　包含如下内容：

　　1、企业的业务和战略目标，近期、中期、长远 目标。

　　2、企业的组织结构。

　　3、业务的分类。

　　4、各类业务之间的关系。

　　5、组织机构与业务的关系。

　　6、企业与外部机构的关系。

　　这些业务对象模型标识出系统的关键性约束，包括系统目标和重要的系统策略。

　　策略包含如下三类明确的表达方式：

　　责任：业务对象必须做什么。

　　许可：业务对象可以做什么。

　　禁止：业务对象不可以做什么。

　　对业务问题进行分析时，要考虑企业业务的发展，如新的服务或产品推出、考虑组织机构的改变等。

　　所有这些可能的变化(易变场景)都应该提现在企业业务架构中。

　　通过对企业业务架构的定义，很清楚地知道由于企业业务特点、业务的流程特点、企业的组织机构等原因对IT系统所带来的自然分块和各个分块之间的边界关系。

　　企业业务架构的维护是一个长期而反复的工作。

　　测试结果报告系统(Test Results Reporting System，TRRS)。

　　对象约束语言(Object Constraint Language，OCL)来定义企业活动者的这些策略(如 许可、禁止、义务等)。

14.4.2 逻辑信息架构

　　逻辑信息架构(信息视点)标识出系统必须知道什么。

　　强调定义系统状态的属性。

　　开放分布式处理是一种面向对象的方法，模型包含了关键信息的处理，如传统的对象概念。

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

　　架构师应该把他们的建模集中于有高风险、高复杂性、模糊性的关键方面。

　　14.4.3 计算接口架构

　　计算接口对系统架构非常有帮助，但是它常常被架构师所忽略。

　　消除多个开发者和小组的主要设计争端，这些接口的架构控制对于一个支持变化和控制复杂性的稳定的系统结构来说，是非常重要的。

　　接口定义语言(IDL)，完全独立于编程语言和操作系统。

　　14.4.4 分布式工程架构

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

　　ODP的一个最大好处是关注点分离。

　　14.4.5 技术选择架构

　　大多数架构是独立的。

　　基于对候选者的初始选择，根据产品价格、培训要求、维护风险之类的项目因素而反复进行。

　　14.5 实现模型

　　最终用户和架构师应在一起审查并贯穿于用例，始终来证实需求的有效。

　　对产品设计的可行性做出准确地评估、论证。

　　14.6 架构原型

　　架构原型是很好的需求验证工具，作为改进设计的手段，确保与工程约束相一致。

　　下面是一些架构师可以在架构原型中寻求解答的具体问题：

　　1、主要组件是否得到了良好的定义?是否恰当?

　　2、主要组件间的协作是否得到了良好的定义?

　　3、耦合是否得意最小化?

　　4、我们能否确定重用的潜在来源?

　　5、接口定义和各项约束是否可以接受?

　　6、每个模块是否能访问到其所需要的数据?

　　经过2次或3次迭代之后，架构变得稳定。主要的抽象对象都已找到，子系统和过程都已经完成，所有的接口都已明确定义。

　　利用架构原型，几个好处：

　　1、落实之前，让团队成员能自由发表他们自己的看法。

　　2、统一团队之间的思想看法，提高系统开发的成功率。

　　3、对系统内部的结构分析与设计也有帮助。

14.7 项目规划

　　项目规划是通过批准的正式文档，以它为基准跟踪和控制项目，行动方案和资源分配，引导项目实施。

　　主要作用是将指定规划的假设和决定批准的范围、成本、进度 的基线等用正式的文档记录保存。

　　估算是项目规划的核心。

　　随着项目的进展，估算会不断校正并逐渐地接近实际。

　　项目管理者通过计划与规划的差异，不断优化和更新计划策略，使项目按规划的要求得以实现，计划的变更是可管理和可受控的。

　　规划包括：

　　1、项目的目的、范围、目标、对象。

　　2、软件生存周期 的选择。

　　3、精选的规程、方法、标准。

　　4、待开发的软件工作产品。

　　5、规模估计、软件项目的工作量和成本估计。

　　6、关键计算机资源的估计;项目的里程碑。

　　7、风险的识别和评估。

　　8、工程实施和支持工具计划。

　　软件项目计划的目标有：软件估计被文档化，活动和约定形成文档，受影响的组和个人认同与软件项目规划的约定。

　　14.8 并行开发

　　14.8.1 软件并行开发的内容及意义

　　提高软件生产率，改善软件质量，有效地组织可以重复的资源。

　　并行开发研究的内容主要如下：

　　1、软件过程及其模型。

　　2、并行分成划分。

　　3、并行控制。

　　4、支持环境。

　　5、交互机制与集成技术。

　　14.8.2 并行开发的过程

　　把软件系统的开发过程划分为若干个可以并行的成分，这个成分称之为子开发过程。

　　子开发过程 = 开发小组 + 软件对象 + 对软件对象的开发活动。

　　并行开发活动，称为并行开发系统，实体是个开发小组，实体属性是被开发的软件对象，行为是开发软件对象的活动。

　　行为模块的划分是并行开发中的核心问题，模块独立性是衡量软件设计质量的关键。

　　系统划分方法：

　　1、基于 Petri网系统模型的动态划分方法。

　　2、基于脚本的系统划分方法。

　　软件过程并行控制是一个非常重要的问题。

　　就是要用正确的方式调度并行操作，避免造成不一致性，使一个操作的执行不受其他系统的干扰。

　　保证一致性、相容性、正确性、可靠性，手段有 加锁、时间戳、管程、Petri 网、PV 操作等。

　　继承和测试被分为两个阶段，如果不考虑硬件或软件的集成，两个阶段并没有明显的界限，所以，软件集成的主要问题是集成测试技术。

14.9 系统转换

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

　　14.9.1 系统转换的准备

　　转换前，必须认真做好准备。

　　还需测试试运行这项工作。

　　注意如下两个问题：

　　1、系统试运行工作的代表性。

　　2、系统试运行中错误的修正。

　　14.9.2 系统转换的方式

　　直接转换、平行转换、分段转换、分批转换。

　　14.9.3 系统转换的注意事项

　　1、大量的基础数据，录入工作量很大，应及早准备，尽快完成。

　　2、应提前做好人员的培训工作。

　　3、出现一些局部性的问题，应有足够的准备，并做好记录。如果出现致命问题，要重新设计。

　　14.10 操作与维护

　　14.10.1 操作与维护的内容

　　数据管理与维护。

　　设备管理与维护。

　　软件的管理与维护工作。

　　14.10.2 系统维护与架构

　　系统架构的好坏，可维护性是一个重要方面，维护人员应参与架构的审评。

　　可维护性可以定性地定义为：维护人员 理解、改正、改动、改进的难易程度。

　　可维护性有如下几个评价指标：

　　可理解性。

　　可测试性。

　　可修改性。

　　系统维护工作可以分为以下4种类型：

　　更正性维护。

　　适应性维护。

　　完善性维护。

　　预防性维护。

　　维护人员必须先理解要维护的系统，然后建立一个维护方案。

　　由于某处修改很可能会影响其他模块程序，所以考虑的重要问题是修改的影响范围和波及面的大小。

　　必须强调的是，维护是对整个系统而言的，必须同时修改涉及的所有文档。

14.11 系统移植

　　14.11.1 系统移植的方式

　　不修改已有的软件。

　　修改软件。

　　重新编软件。

　　14.11.2 系统移植的工作阶段划分

　　计划阶段。

　　准备阶段，准备转换所需的材料。

　　转换阶段。

　　测试阶段。

　　验证阶段。

　　使系统移植工作标准化，工具实现自动化。

　　14.11.3 系统移植工具

　　系列化、标准化、文档化，使任何人都能以相同的顺序开展工作，提高效率。

 

------------------<<完>>--------------------