企业体系结构开发样本

1、企业体系结构开发团队解决复杂问题需要规划。对于企业软件系统来说，有些最重要的 规划是高技术的（比如规划系统体系结构）。规划产生制品（artifact）,可是规划（作为一种活动）要比作为典型制品 的项目管理计划更为重要。从这一点看，我们认为文档驱动的方法并不值得推荐 因为它强调纸制品的优先权 而任何软件开发项目的真正产品是”软件”！我们 在更大的环境中用多种层次的形式和技术细节来考虑规划。例如构建是规划， 需求分析、设计建模、生产计划等也同样是。形式化的层次应该与文档的更长 期用途联系在一起。在以体系结构为中心的开发中，规划是重视实用性的（参见图3.2）。项目计划和设计模型被丢掉，因为它们只具有

2、短期的精确性。一个计划 或设计书一旦过时，那它在实际上就已毫无用处。比如说，源代码的改变可能迅 速导致设计模型被抛弃。图3.2由于没有规划，则许多个别的成功对于整个项目的成功而言，显然是不够的另外，软件方法和标准应该看做是指南，而不是命令。应该鼓励项目 小组自己思考，并经过对过程进行调整来满足项目的要求。实用性是软件建模的一个基本原则：对于需求、体系结构和设计而言 都是这样。每个模型都有一个目的和多个关注点，并抑制那些不重要的细节。模 型中重要的决策应该基于项目假设和优先级。决定什么是重要的，是有能力的架 构师所应该具备的一项重要决策技能。以体系结构为中心的过程图3.3展示了覆盖整个系统生命周

3、期的以体结构为中心的开发的十个 步骤。重要的目标在于：促进在步骤7中并行迭代开发（即编码和测试）的 生产率。我们在这里强调步骤7中所进行的活动，是因为在这些步骤中包含了我 们认为在当前企业开发中存在的关键的问题，即体系结构规划活动。我们需要强调：这个过程本质上就是迭代和递增的，可能需要修改以 前的步骤的制品（结果）。然而，因为它们之间互相依赖，预开发步骤确实有一 个瀑布式的进程。整个的过程是质量驱动的，最终的目标是提供一个稳定可靠的 体系结构描述和一个能适应变化的运行软件代码库，以满足最终用户的需求。步骤1:系统构想讨论建模的时候，我们曾提到关键词有目的、焦点、假设和优先级， 它们都是系统级的

4、”构想描述（Vision Statement） ”的基本元素。如果它们在 系统开发过程中改变 那么项目就有抛弃自身模型的危险。因此 以体系结构为 中心的开发的第一步就是建立一个构想描述。一旦开始：步骤7）,就假定构想 描述不会改变。所有的改变必须在关键的项目计划中有所反映一特别是在系统 体系结构（步骤3）中。实际上构想描述是一个系统开发人员与系统用户之间共同的协议它必须简 短而切中要点 根据系统不同而不同一般不到十页文本。资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。岌料#虫怵赃时.构挞+鹿样档哦始构剧念律机潺Wft但务政Cr露.想我合小：愚石为环概眠威跪精眼系衅堵换显书I押M

5、嚏耿夏芫伴呵机痛密隔擀机祁北务H上坡 fHEC景程陌配责顿找个配述雌mu踱务旧过以蝮职篦系费轧戎择帝理嘛扩志拒将植高统叫姒番矗睡析悼弟恭构成就 J祥爵哒杓的壁收用用划期m强阵掐站鸣为中也的jik谊群构想描述建立了从需求分析开始的所有接下来的项目活动的语境（上下 文）。步骤2:需求分析需求应该定义系统的外部行为和外观，而不用设计系统的内部结构。 外部行为包括了用来保证外部行为能够完成而所需的内部行为（比如持续性或 计算）。外观包括用户界面的布局和导航。一个有效地捕捉行为需求的方法是经过用例（use case）。一个用例 包含一个顶层的图和扩展的文字描述。用例符号简单得令人难以置信，但它却具 有不

6、可估量的价值：它促进了抽象。用例符号在已创造的表述复杂概念的记法中, 是最有效的。因此，它非常适合于用来保证在表述顶层需求概念时的简单性和清 晰度。图中的每个圆（称做一个单独的用例）都有一个相关需求的扩展文字 描述。这种方法采用了包含一系列活动的长列表形式，用特定领域的平铺直叙的 文字来描述。定义用例应该和领域专家一起进行。如果没有领域专家的长期参与， 这种活动只能是一种常见的反模式，称为”伪分析”，这是需要避免的。用例为定义体系结构提供了一个系统的领域模型。用例也发挥着顺流 (downstream)的角色。在开发的步骤7中，用例被特定系统的场景图表所扩展, 最后这些场景会在软件测试中详尽的予

7、以阐述。用户界面的外观、功能和导航同用例紧密相联。一个有效定义屏幕的 方法叫做低保真度原型(low-fidelity prototyping)。在这种方法中，屏幕是 用纸和笔先画出来的。同样，最终用户领域专家也始终参与到屏幕定义的过程中 去。有了用例和定义的用户界面，我们已经建立了体系结构规划的环境。 在产生文档之外(包括纸、笔的草图)，体系结构小组获得在最终用户领域中 对所需的系统功能的更深刻的理解。需求分析的最终产品是一个项目词汇表，它应在体系结构规划(步骤 3)中被扩展。步骤3:体系结构规划体系结构沟通了需求和软件之间巨大的语义上的鸿沟。因为需求语言 是平铺直叙的，从本质上说，需求是模糊

8、的、直观的和不正式的一一这是右脑 所要考虑的问题。而软件则具有相反的性质：软件的源代码是一种正规的符号; 软件被机器无二义性地翻译，它的含义在逻辑上也是不直观的（即，很难解码） 这是左脑所要考虑的问题。体系结构的第一个任务就是定义这两个极端之间的映射。体系结构用 一种更为正规的方式来捕捉直觉的决定（这对程序员来说是很有用的），它在 硬连线（hardwire）形成编码（这样当前和将来的需求能够满足）之前定义了 内部的系统结构。体系结构作为一项计划，它用允许系统构建和适应变化的方法 来管理系统的复杂性。体系结构还有另一个显著的任务：定义软件项目的组织 （参见步骤6）。在当前的许多软件项目、过程和方

9、法中，体系结构规划是容易被忽略 的重要步骤。造成这个鸿沟的原因之一是长期以来关于什么是体系结构的讨论。 幸运的是，这个问题已被软件体系结构专家用开放分布式处理的正式ISO标准 予以了明确的回答。开放分布式处理（ODP）是一种考虑复杂系统的强有力的方法，它使 作出决定变得更加容易（更为聪明地工作，而非更加费劲）。它从5个标准的视 点组织了系统的体系结构，描述了同一系统的重要方面。这些视点包括企业、逻 辑信息、计算接口、分布式工程和技术选择（参见图3.4） o对于每个视点，确认体系结构需求的一致性是非常重要的。如果一致 性没有客观的定义，那么体系结构是没有意义的，因为它对实现没有明确的影 响。开放分布式处理促进了这个过程，因为它内嵌了一个普遍的一致性方法。简 单的一致性清单包含识别体系结构中一致点所需的全部内容。在下面的几个小节中，我们将总结各个视点。采用开放分布式处理， 一个典型的体系结构规范是简洁的，包含大约100页，因系统不同而有所不同。每个视点包含520页。一般希望每个开发者一页一页地详细阅读这个文档，并 了解它的内容。我们建议把内容做成向导（视图），并经过一个几天的初始会议 （见步骤7）同开发者进行细节上的交流。图3.4 ODP视点业务企业体系结构业务企业体系结构（企业视点）用高层企业对象来定义业务目的和系 统策略。这些业务对象模型标识出系统的关键性约束