http://www.cnblogs.com/hack/archive/2010/08/25/1808561.html
第十四章 基于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 系统移植工具
系列化、标准化、文档化，使任何人都能以相同的顺序开展工作，提高效率。