企业体系结构开发.doc

企业体系结构开发???? ?? 团队解决复杂问题需要规划。对于企业软件系统来说，有些最重要的规划是高技术的（比如规划系统体系结构）。 规划产生制品（artifact），但是规划（作为一种活动）要比作为典型制品的项目管理计划更为重要。从这一点看，我们认为文档驱动的方法并不值得推荐，因为它强调纸制品的优先权，而任何软件开发项目的真正产品是“软件”！我们在更大的环境中用多种层次的形式和技术细节来考虑规划。例如，构建是规划，需求分析、设计建模、生产计划等也同样是。形式化的层次应该与文档的更长期用途联系在一起。 ?? 在以体系结构为中心的开发中，规划是重视实用性的（参见图3.2）。项目计划和设计模型被丢掉，因为它们只具有短期的精确性。一个计划或设计书一旦过时，那它在实际上就已毫无用处。比如说，源代码的改变可能迅速导致设计模型被抛弃。 图3.2 由于没有规划，则许多个别的成功对于整个项目的 成功而言，显然是不够的 ?? 另外，软件方法和标准应该看做是指南，而不是命令。应该鼓励项目小组自己思考，并通过对过程进行调整来满足项目的要求。 ?? 实用性是软件建模的一个基本原则：对于需求、体系结构和设计而言都是这样。每个模型都有一个目的和多个关注点，并抑制那些不重要的细节。模型中重要的决策应该基于项目假设和优先级。决定什么是重要的，是有能力的架构师所应该具备的一项重要决策技能。 以体系结构为中心的过程 3.3展示了覆盖整个系统生命周期的以体结构为中心的开发的十个步骤。 ?? 重要的目标在于：促进在步骤7中并行迭代开发（即编码和测试）的生产率。我们在这里强调步骤7中所进行的活动，是因为在这些步骤中包含了我们认为在当前企业开发中存在的关键的问题，即体系结构规划活动。 ?? 我们需要强调：这个过程本质上就是迭代和递增的，可能需要修改以前的步骤的制品（结果）。然而，因为它们之间互相依赖，预开发步骤确实有一个瀑布式的进程。整个的过程是质量驱动的，最终的目标是提供一个稳定可靠的体系结构描述和一个能适应变化的运行软件代码库，以满足最终用户的需求。 步骤1：系统构想 Vision Statement）”的基本元素。如果它们在系统开发过程中改变，那么项目就有抛弃自身模型的危险。因此，以体系结构为中心的开发的第一步就是建立一个构想描述。一旦开始（步骤7），就假定构想描述不会改变。所有的改变必须在关键的项目计划中有所反映—— 特别是在系统体系结构（步骤3）中。 实际上，构想描述是一个系统开发人员与系统用户之间共同的协议，它必须简短而切中要点，根据系统不同而不同，通常不到十页文本。  构想描述建立了从需求分析开始的所有接下来的项目活动的语境（上下文）。 ???? 步骤2：需求分析 ?? 一个有效地捕捉行为需求的方法是通过用例（use case）。一个用例包含一个顶层的图和扩展的文字描述。用例符号简单得令人难以置信，但它却具有不可估量的价值：它促进了抽象。用例符号在已发明的表述复杂概念的记法中，是最有效的。因此，它非常适合于用来保证在表述顶层需求概念时的简单性和清晰度。 ?? 图中的每个圆（称做一个单独的用例）都有一个相关需求的扩展文字描述。这种方法采用了包含一系列活动的长列表形式，用特定领域的平铺直叙的文字来描述。定义用例应该和领域专家一起进行。如果没有领域专家的长期参与，这种活动只能是一种常见的反模式，称为“伪分析”，这是需要避免的。 ?? 用例为定义体系结构提供了一个系统的领域模型。用例也发挥着顺流（downstream）的角色。在开发的步骤7中，用例被特定系统的场景图表所扩展，最后这些场景会在软件测试中详尽的予以阐述。 ?? 用户界面的外观、功能和导航同用例紧密相联。一个有效定义屏幕的方法叫做低保真度原型（low-fidelity prototyping）。在这种方法中，屏幕是用纸和笔先画出来的。同样，最终用户领域专家也始终参与到屏幕定义的过程中去。 ?? 有了用例和定义的用户界面，我们已经建立了体系结构规划的环境。在产生文档之外（包括纸、笔的草图），体系结构小组获得在最终用户领域中对所需的系统功能的更深刻的理解。 ?? 需求分析的最终产品是一个项目词汇表，它应在体系结构规划（步骤3）中被扩展。 步骤3：体系结构规划 ?? 体系结构的第一个任务就是定义这两个极端之间的映射。体系结构用一种更为正规的方式来捕捉直觉的决定（这对程序员来说是很有用的），它在硬连线（hardwire）形成编码（这样当前和将来的需求可以满足）之前定义了内部的系统结构。体系结构作为一项计划，它用允许系统构建和适应变化的方法来管理系统的复杂性。体系结构还有另一个显著的任务：定义软件项目的组织（参见步骤6）。 ?? 在当前的许多软件项目、过程和方法中，体系结构规划是容易被忽略的重要步骤。造