`
阅读更多

软件架构活动:定义及范围

根据IEEE标准,软件架构活动代表了

这样一系列活动:定义、记录、维持、改进一个软件构架并确保其正确执行。 1

软件架构的范围相当宽泛。图1展示的模型详细地说明了软件架构过程的各个方面。这个模型来自IEEE标准1471,架构师所关注的软件架构各个方面都可以此模型作为参考。

Figure 1: A metamodel of architecting related terms

图1:软件架构相关术语的模型

图1中阴影框里的元素直接来自于IEEE标准1471,它们之间的相互关系阐明的是一个系统及其构架的诸多特征:

  • 一个系统有一个构架。
  • 一个系统完成一项任务。
  • 一个系统存于一个环境中,并受这个环境的影响。
  • 一个系统有一个或多个涉众。
  • 一个构架对应一条构架描述。
  • 一条构架描述识别一个或多个涉众。
  • 一条构架描述识别一条或多条关联。
  • 一条构架描述提供理由。
  • 一个涉众有一条或多条关联,一条关联对一个或多个涉众都很重要。

图1中另外那些不是来自IEEE标准1471的元素和相互关系,显示在非阴影框中,可描述如下:

  • 一个团队组负责一个开发项目。
  • 一个开发项目遵循一个开发流程。
  • 一个开发项目交付给一个系统。
  • 开发流程包括软件架构。
  • 项目组里包含一个架构师。
  • 架构师负责软件架构。
  • 架构师是涉众中的一种。
  • 架构最终得出一个软件构架。
  • 架构师创造出软件构架。

软件架构是一门科学

虽然软件构架是一门新生事物,但它已被公认为一门学科。而随之而来的是将重点放在使软件架构过程日趋成熟的技术、方法和资源上。推进这一趋势的方法之一就是利用现有的知识体系。概括地说,就是架构师们在开发一个新的构架时寻求已经通过检验的解决方案,而不是重蹈覆辙,将以往的软件构架、构架设计模型以及其他一些可再度使用的元素中可以借鉴的经验汇集成册。

尽管如此,软件架构过程要想在任何地方都和土木工程的架构过程一样成熟,仍有一段路要走。这种成熟可以体现在很多层面上,包括标准的运用,对最佳实行方案、技术以及方法的理解上。因此,基于这一点,一个架构师的经验对于一个项目的成功有很大的影响。

软件架构是一门艺术

尽管软件架构被认为是一门科学,但有些时候具备一定的创造力是十分必要的,在处理一些从未见过的奇特的系统时这一点就尤为重要。在这种情况下,可能没有成形的经验可以借鉴。就如同一个画家在面对一张空白的画板时需要灵感一样,架构师们有时会视他们的工作为一门艺术而不是一门科学。当然在很大程度上,软件架构的艺术层面是很小的。即使是面对一个极为新奇的系统,通常的做法也是借鉴别处的解决办法,处理之后使其适应用这个系统。

随着软件架构过程日渐成为主流,它极有可能不再被认为是只有“被挑出的极少数人”可以理解的一系列神秘的实践行为,而是一系列被广泛接受的、建立在科学基础之上的、定义明确并通过检验的实践行为。

软件架构跨越很多学科

在软件开发过程中架构师需要涉及许多学科。架构师涉及最多的学科是软件设计,尽管如此,架构师也很关注其他的一些学科。例如,在需求分析里,架构师要确保对于利害关系的需求条件尤为了解,同时也懂得区分这些需求的优先次序。架构师参与实现工作,他们详细地说明用来组织源代码以及可执行的工作产品的实现结构。架构师们还参与测试工作,确保架构结构具有可测性并能通过测试。架构师负责开发环境中的一些特定元素,特别是建立一些特定的指针。架构师们还帮助制定配置管理策略,因为配置管理结构(用来支持版本管理的)经常影响已经定义好的软件架构。架构师与项目管理人紧密合作,正如这个文章系列中的第二部分所提到的,架构师已经成为项目计划中的一员。

当谈及软件架构的范围时,我需要提到架构和设计的关系。尽管架构师尤为重视设计学,但并非所有的设计都可以认为是软件架构。因为一个架构只是关注那些十分重要的元素,而并不是所有的设计元素都对架构有重要意义。例如,用户界面屏幕的详细设计通常认为对架构没有任何意义,最好是留给用户界面设计者来完成。这种思路同样应用于其他的系统元素,例如那些支持业务逻辑或数据逻辑的元素。架构师只在必要时加以限制,而许多设计方面的决策都是留给设计者们来完成的。

架构是时刻进行的行为

经验表明,软件架构并不是在项目初期一蹴而就的事情,而是贯穿整个项目的始终。在整个项目里,通过交付给可执行软件的一系列迭代递增的程序,软件架构也日趋成熟。在每一次交付过程中,软件构架都会变得更加稳定完善。这就很好地解释了什么是架构师贯穿项目始终的重点。

成功的软件架构行为是以结果为导向的。因此,架构师的重点会因预期结果随时间变化而变化。这一点如图2所示,图2由Bran Selic绘制。 2

图2:随时间变化的工程重点

图2:随时间变化的工程重点

图2表明,在工程早期,架构师着眼于发现,重点是理解系统所涉及的范围并识别其主要特征及所有相关的风险——所有的要素对软件构架都有显著的影响。然后重点转向创造,主要是开发一个可以为整个实现过程提供牢固基础的稳定的构架。最终,重点放在了实现上面,这个时候大部分的发现和创造开始起作用。

应该注意到,发现、创造和实现并不是严格按顺序来的。例如,随着架构模型的建立,在项目早期会有一些实现过程。而随着过程的深入理解和实现架构中某些元素的不同策略的提出,在项目后期将会有一些发现。

请记住,直到系统交付架构过程才被完成,因此,架构师必须一直关注软件构架直至项目结束。一旦一个项目的软件构架稳定下来,人们总是希望架构师离开这个项目,将这一珍贵的资源用于其他的项目。然而,直到项目后期仍有一些架构方面的决策需要制定。实际上,还有介于两者之间的情况,一旦影响软件架构的重大决策制定出来,架构师就成为项目组中的一名兼职人员。不管怎样,架构师不应该完全脱离这个项目。当然还有一种更加灵活的情况,那就是由一个团队来履行架构师这个角色,这个团队里的一些成员可能去参予其他的项目,而另外一些则留下来继续确保这个系统架构的完整性。

软件架构受涉众所驱动

正如在早期的章节里所描述的,一个构架满足许多涉众的需求。因此架构的过程必须适应所有这些涉众,以确保他们的关系——特别是那些极有可能对软件构架产生影响的——能够被了解,被阐明,能够得到协调及有效的处理,也有必要将相关的涉众融入到对这些关系处理的每一次复审之中。

在架构过程中不应低估适应所有涉众所付出的努力。涉众影响着架构过程的许多方面,包括集中需求条件的方式,构架的文档记录样式以及构架的评估方法。

软件架构经常需要做出折衷

假定给出影响软件构架的诸多因素,很显然软件架构过程需要做出折衷。通常情况是在需求中做出权衡,同时也要考虑涉众来帮助做出正确的折衷。一个折衷的例子就是性能价格比:添加更多的问题处理能力会增加性能,但是要以成本为代价。这可能代表一个需求的冲突,假设架构师已经努力地找到所有可解决方案,这就是一个要由有需求冲突的涉众来解决的问题。

另一种折衷体现在解决方案上:例如,用一种技术代替另一种技术,或是用第三方的部分代替另一方,或者甚至用一组模式来取代另外的一组。作出折衷无法避免,也不应避免。构架师的一项工作就是考虑可选择的方案并在它们之间作出折衷。

软件架构受益于过去的经验

架构师们很少“白手起家”。正如前面提到的,他们积极地寻找已经汇集成册的经验,包括架构模式、设计模式以及已经成形的部分等等。换句话说,架构师努力获取那些可再度利用的资源。只有那些最无知的架构师才放弃考虑过去的经验。

当问题重复发生时,可重复使用的资源就是解决方案;可重复使用的资源就是一种在重复使用时已经在脑海中得到提炼的资源。 3

一个软件构架中的元素可以在当前系统的前后关系里再度使用,与此同时,一个架构师可能也已经将其构架或者其中的一些元素作为可再度使用的资源,用于当前系统之外。

软件架构既是自上而下也是自下而上的

许多软件构架是按照自上而下方式来设计的:1)在定义构架之前掌握涉众需求并加以研究;2)设计架构元素;3)实现这些元素。尽管如此,一个软件构架很少完全按照这个自上而下的方式进行架构,普遍情况是采取相反的方式,从已经创造出来的实现软件中汲取教训,比如说概念论证。在某种程度上,软件构架按照自下而上的方式是由于指定的设计或实现方案的约束,在这种情况下这些元素是给定的,软件构架必须适应它们。例如,约束可能是设计将在现在系统上使用关系数据库或者接口。

成功的架构师们承认,架构的方法是必要的,并且他们的软件架构是按照自上而下和自下而上两种方式创建的。这可以被认为是“中间的”架构解决方法。

评论

相关推荐

    软件架构过程,描述的是在软件工程的生命周期里软件架构师正在进行的各类活动

    软件架构过程是软件开发中的核心环节,它定义了软件系统的基本构造、组织和交互方式,对整个项目的成功至关重要。在软件工程的生命周期中,软件架构师的角色尤为关键,他们不仅负责设计系统的整体框架,还参与规划、...

    计算机软件水平考试:软件架构的过程.pdf

    1. **定义**:这是软件架构过程的起点,架构师需要理解项目的目标、需求和约束,然后设计出能够满足这些需求的结构和组件。这包括确定系统的高层次结构、模块划分以及它们之间的交互关系。 2. **记录**:架构师需将...

    软件架构---构建可持续软件架构的模式语言

    3. **最佳实践**:本文列举了一系列作者认为在构建实际软件架构过程中不可或缺的最佳实践,可以被视为一套“架构过程”。 #### 构建可持续软件架构的关键要素 - **模式语言的应用**:通过模式语言来描述和规范软件...

    架构实战——软件架构设计的过程

    ### 架构实战——软件架构设计的过程 在现代软件开发中,软件架构设计扮演着至关重要的角色。良好的架构设计能够确保软件系统的可扩展性、可维护性和性能等关键特性。《架构实战——软件架构设计的过程》一书深入...

    企业级应用软件架构开发过程与实践

    在企业级应用软件架构开发过程中,我们关注的不仅仅是技术实现,更重要的是如何设计出能够满足大规模、高并发、可扩展性、稳定性和安全性的系统。本篇内容将围绕这一主题,依据提供的章节名称,深入探讨企业级应用...

    软件架构设计

    决策派则更注重软件架构过程中的一系列决策,这些决策通常由项目的负责人或架构师做出,决定了系统的整体方向和技术选型等关键问题。 **例子:** 考虑一个项目管理系统,其中一个具体的需求是允许用户以甘特图的...

    架构实战—软件架构设计的过程.rar

    "架构实战—软件架构设计的过程"是一个深入探讨这一主题的资源,非常适合那些对软件架构感兴趣或者希望提升自己架构能力的人。 首先,软件架构设计是系统开发的蓝图,它为项目的整体结构和组织提供指导。这个过程...

    架构实战 : 软件架构设计的过程

    本书从基本原理入手,介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源,从第6章开始,通过介绍一个具体的案例来阐述如 何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”...

    架构实战(软件架构设计的过程).rar

    《架构实战:软件架构设计的过程》是一本深入探讨软件架构设计的专业书籍,旨在提供实际操作中的指导和经验分享。在软件开发中,架构设计是至关重要的一步,它决定了系统的整体结构、组件之间的关系以及系统如何应对...

    软件架构设计过程实例

    本案例以"大学信息系统"为背景,通过一个详细的软件架构设计过程实例来阐述这一关键环节。以下将详细介绍该过程中的核心知识点。 首先,软件架构设计始于需求分析。在大学信息系统这个例子中,可能的需求包括学生...

    软件架构师教程,系统架构师讲义

    软件架构是软件开发过程中的关键环节,它定义了系统的整体结构和组织方式,包括主要组件、组件之间的关系以及交互方式。本教程首先会介绍软件架构的基本概念,如模块化、分层架构、微服务架构等,让读者理解架构设计...

    软件架构实践 第2版

    《软件架构实践 第2版》是一本深入探讨软件架构设计与实践的重要著作。软件架构是构建大型、复杂软件系统的基础,它定义了系统的组件、组件之间的关系以及指导系统开发和演进的原则。这本书的第二版提供了最新的理论...

    软件架构--软件架构讲义

    软件架构是软件开发过程中的核心组成部分,它定义了软件系统的高级结构、主要组件以及它们之间的关系,为系统设计提供了一个蓝图。本讲义将深入探讨软件架构的基本概念、重要性以及如何进行有效的架构设计。 首先,...

    软件架构实践(第三版)林巴斯

    ### 软件架构实践(第三版)林巴斯——关键知识点解析 #### 一、概述 《软件架构实践(第三版)》由林巴斯编著,是一部深入探讨软件架构设计与实现的专业书籍。本书旨在帮助读者理解软件架构的核心概念、方法论...

    软件架构和架构师

    - **职责**: 软件架构师在整个软件开发过程中扮演着关键角色,他们的职责包括但不限于: - 确定软件架构的整体框架。 - 定义软件组件及其交互机制。 - 确保软件架构符合业务需求和技术目标。 - 指导开发团队遵循...

    软件架构师-架构资料.zip

    《软件架构师:构建高效系统的关键》 在信息化社会中,软件架构师的角色日益凸显,他们不仅是技术专家,更是项目中的灵魂人物。软件架构师负责设计和规划软件系统的整体结构,确保系统的可扩展性、可维护性和性能。...

Global site tag (gtag.js) - Google Analytics