向架构师进军--->架构方法基本原理

通过上一节的介绍，相信你对架构设计已经有了初步的了解。这一节我们主要讲解架构的方法与基本原理，尽管这很俗，但是我们还不得不对它做一下大致的介绍，以免我们在进行架构设计时走入误区。

我们知道一个软件开发项目是由不同角色的人为完成不同的任务而产生的工作产品。我们要开发软件，制定架构就需要研究角色、任务和工作产品，接下来我们详述这三个部分。

角色

角色定义了软件开发组织内作为团队一起工作的一组人或单个人的职责。角色不是单个人，单个人可能扮演多个角色，多个人可能会扮演同一个角色。下面我们介绍一下不同角色的架构师的定义及其职责：

首席架构师全面负责定义系统架构的主要技术决策。这个角色也负责为这些决策提供理论基础；平衡各种利益相关者的关注点；管理技术风险和问题；还确保决策被有效地沟通、验证和执行。

应用架构师关注那些使业务流程自动化和满足业务需要的元素。这个角色主要关注业务需要的功能，但是他也关心应用相关的元素如何满足系统的非功能性需求（质量和约束）。

基础设施架构师关注那些不依赖业务功能的系统元素，如持久机制、硬件和中间件。这样的元素支持应用相关元素的执行。这个角色关注那些对系统质量有明显影响的元素，因此，他也会处理一些延伸的非功能性需求。

数据架构师关注系统的数据元素，尤其是那些用适当的机制（如数据库、文件系统、内容管理系统或其他存储机制）保持持久的数据。这个角色定义适当的与数据相关的属性，比如结构、来源、位置、完整性、可用性、性能和使用年限。

任务

任务是在项目的上下文中提供有意义结果的一个工作单元。它有明确的目的，通常涉及创建或更新工作产品。所有的任务都由适当的角色执行。

任务可能会被重复执行很多次，尤其是当采用迭代开发方式时。下图列出了不同角色的架构师的相关任务。







工作产品

工作产品是在流程执行过程中生成和使用的一些信息或物理实体。工作产品包括模型、计划、代码、可执行代码、文档、数据库等。虽然可能有多个角色协作来生成一个工作产品，但是它是单个角色的职责。

SPEM（软件系统流程工程元模型规范）定义了三种类型的工作产品：工件、可交付物及成果。工件是一个实在的工作产品，如文档、模型源代码、可执行物或项目计划。可交付物是切实的打包交付的工作产品。成果表示一个结果或任务执行结果的状态。下图是不同角色架构师的一些文档产品。






我们知道软件行业中使用的各种方法间的差异主要与遵循的流程有关，而不在于角色、工作产品和任务，所以我们现在讨论一下当前使用最多的三种流程类型：瀑布、迭代和敏捷。

瀑布模型在早期软件开发模型的典范，但是在开发绿色领域项目（架构师从头开始）或那些被大范围修改的项目上，瀑布模型就因项目进度不能精确地度量，直到项目的后期才能获得用户的反馈等原因而被逐渐放弃。在此，不再对瀑布模型做过多的介绍，仅以下面一幅图说明瀑布模型的开发过程。



迭代是一个项目的短的周期划分。迭代时一个明确的、固定时间的活动序列，它们会产生一个可执行产品的版本。OpenUP定义了软件开发的四个阶段：起始、细化、构造和移交，在每个阶段都会进行N次迭代最终形成产品。

迭代开发与瀑布开发流程相比，迭代开发是以结果驱动的，而不是以工作产品驱动，这有助于对项目进度进行更精确的测量。迭代的方式通过系统增量版本的执行尽早获得用户反馈，而这些反馈促进实际需求的收敛。

敏捷开发是近年来最受欢迎的开发方式，代表性的方法有极限编程、Scrum、精益和特征驱动开发。虽然每个特定的敏捷方法以及所倡导的方法存在一些差异，但是它们都基于相同的基础准则--敏捷宣言：

注重个人及其交互，胜于过程与工具。

注重可用的软件，胜于详尽的文档。

注重客户协作，胜于契约谈判。

注重响应变化，胜于恪守计划。

敏捷流程不倡导预先设计，架构直接来自于代码。然而，“注重可用的软件，胜于详尽的文档”这个原则并不意味着没有文档，这仅仅意味着只有满足当前迭代目标的文档。

本篇我们介绍了软件架构的一些方法和基本原理，同时也用生动的图形说明了不同角色的工程师的职责和工作产品。通过这些介绍，我们接下来就可以详细介绍项目生命周期中使用的方法，以及如何去设计架构。欢迎您保持关注。。。