软件架构的过程.docVIP

软件架构的过程 本文来自于 Rational Edge：软件架构被公认为软件开发领域的一门新兴学科。作为软件架构系列文章的第三篇，本文描述的是在软件工程的生命周期里软件架构师正在进行的各类活动。 在这个系列里，我的 第一篇文章描述的是什么是软件架构， 第二篇文章 讲述软件架构师这个角色的特征。第三部分是建立在以前讨论的基础之上，而且所考虑的主题或者特征都是在软件架构过程这个框架下。 软件架构活动：定义及范围 根据IEEE标准，软件架构活动代表了 这样一系列活动：定义、记录、维持、改进一个软件构架并确保其正确执行。 1 软件架构的范围相当宽泛。图1展示的模型详细地说明了软件架构过程的各个方面。这个模型来自IEEE标准1471，架构师所关注的软件架构各个方面都可以此模型作为参考。 图1：软件架构相关术语的模型 图1中阴影框里的元素直接来自于IEEE标准1471，它们之间的相互关系阐明的是一个系统及其构架的诸多特征： 一个系统有一个构架。 一个系统完成一项任务。 一个系统存于一个环境中，并受这个环境的影响。 一个系统有一个或多个涉众。 一个构架对应一条构架描述。 一条构架描述识别一个或多个涉众。 一条构架描述识别一条或多条关联。 一条构架描述提供理由。 一个涉众有一条或多条关联，一条关联对一个或多个涉众都很重要。 图1中另外那些不是来自IEEE标准1471的元素和相互关系，显示在非阴影框中，可描述如下： 一个团队组负责一个开发项目。 一个开发项目遵循一个开发流程。 一个开发项目交付给一个系统。 开发流程包括软件架构。 项目组里包含一个架构师。 架构师负责软件架构。 架构师是涉众中的一种。 架构最终得出一个软件构架。 架构师创造出软件构架。 软件架构是一门科学 虽然软件构架是一门新生事物，但它已被公认为一门学科。而随之而来的是将重点放在使软件架构过程日趋成熟的技术、方法和资源上。推进这一趋势的方法之一就是利用现有的知识体系。概括地说，就是架构师们在开发一个新的构架时寻求已经通过检验的解决方案，而不是重蹈覆辙，将以往的软件构架、构架设计模型以及其他一些可再度使用的元素中可以借鉴的经验汇集成册。 尽管如此，软件架构过程要想在任何地方都和土木工程的架构过程一样成熟，仍有一段路要走。这种成熟可以体现在很多层面上，包括标准的运用，对最佳实行方案、技术以及方法的理解上。因此，基于这一点，一个架构师的经验对于一个项目的成功有很大的影响。 软件架构是一门艺术 尽管软件架构被认为是一门科学，但有些时候具备一定的创造力是十分必要的，在处理一些从未见过的奇特的系统时这一点就尤为重要。在这种情况下，可能没有成形的经验可以借鉴。就如同一个画家在面对一张空白的画板时需要灵感一样，架构师们有时会视他们的工作为一门艺术而不是一门科学。当然在很大程度上，软件架构的艺术层面是很小的。即使是面对一个极为新奇的系统，通常的做法也是借鉴别处的解决办法，处理之后使其适应用这个系统。 随着软件架构过程日渐成为主流，它极有可能不再被认为是只有“被挑出的极少数人”可以理解的一系列神秘的实践行为，而是一系列被广泛接受的、建立在科学基础之上的、定义明确并通过检验的实践行为。 软件架构跨越很多学科 在软件开发过程中架构师需要涉及许多学科。架构师涉及最多的学科是软件设计，尽管如此，架构师也很关注其他的一些学科。例如，在需求分析里，架构师要确保对于利害关系的需求条件尤为了解，同时也懂得区分这些需求的优先次序。架构师参与实现工作，他们详细地说明用来组织源代码以及可执行的工作产品的实现结构。架构师们还参与测试工作，确保架构结构具有可测性并能通过测试。架构师负责开发环境中的一些特定元素，特别是建立一些特定的指针。架构师们还帮助制定配置管理策略，因为配置管理结构（用来支持版本管理的）经常影响已经定义好的软件架构。架构师与项目管理人紧密合作，正如这个文章系列中的第二部分所提到的，架构师已经成为项目计划中的一员。 当谈及软件架构的范围时，我需要提到架构和设计的关系。尽管架构师尤为重视设计学，但并非所有的设计都可以认为是软件架构。因为一个架构只是关注那些十分重要的元素，而并不是所有的设计元素都对架构有重要意义。例如，用户界面屏幕的详细设计通常认为对架构没有任何意义，最好是留给用户界面设计者来完成。这种思路同样应用于其他的系统元素，例如那些支持业务逻辑或数据逻辑的元素。架构师只在必要时加以限制，而许多设计方面的决策都是留给设计者们来完成的。 架构是时刻进行的行为 经验表明，软件架构并不是在项目初期一蹴而就的事情，而是贯穿整个项目的始终。在整个项目里，通过交付给可执行软件的一系列迭代递增的程序，软件架构也日趋成熟。在每一次交付过程中，软件构架都会变得更加稳定完善。这就很