现在的位置: 首页 > 综合 > 正文

软件架构:提升抽象层次(译)

2012年08月21日 ⁄ 综合 ⁄ 共 2183字 ⁄ 字号 评论关闭

软件架构:提升抽象层次(译)

 

Peter Eeles的文章,文中一些定义以下面的为准。

 

架构,是系统的基本组织,涵盖组件,组件与组件的关系,组件与环境关系,以及一些指导设计和演变的原则。[IEEE 1471]

 

       与此相关的一些术语:

       系统,是具有一个或一组功能的组件集合。该术语的概念涵盖了个人应用程序,传统意义上的系统,子系统,综合系统,产品线,产品系列,整个企业,以及其他利益集合体。系统为任务而生。[IEEE 1471]

 

       环境(或上下文),决定了开发、操作、政治、以及其他方面的设置和条件。[IEEE 1471]

 

       使命是对系统的使用和操作,系统是用来,为一个或多个参与者,实现一些目标的集合。[IEEE 1471]

 

     参与者是个人,团队,或者组织(或者它所属于的阶级),他们或是利益相关者,或感兴趣者。

 

     组件是一个实现了功能的系统之模块化的局部,且具有可替换性。组件基于规定和要求的接口,来定义行为。因此,在提供服务的时候,组件的一致性是由规定和要求的接口定义的(既包括静态语义,也包括动态语义)。

 

此外,架构是重大决定的集合,这些决定事关一个软件系统的组织,架构元素的选择,组成系统的各部分的接口,还有这些元素间协作的指定行为,如何把这些元素逐步组装成子系统,指导这种组织的架构风格包括这些元素及其接口、协作和构成。

程序或者计算系统的软件架构就是它的结构,包括软件元素,这些元素的外部可见属性,以及它们之间的关系

架构是系统的组织结构和相关行为。一个架构可以被递归地拆解成:靠接口交互的小块,小块之间的关系,以及组装约束。小块之间交互的接口包括类,组件和子系统。[UML 1.5]

 

一个或一组系统的软件架构,包括所有关于软件结构和不同结构间的交互,的重要设计决策。设计决策支持一套理想的质量,以支持系统能够成功。设计决策还为系统的部署、支持和维护提供一套概念基础。[McGovern]

本文提供了关于软件架构的下列观察。我已把它们分为三组:

1.   软件系统的结构特征

- 架构定义了结构或结构特征

- 架构定义了行为或结构元素间的交互

- 架构关注于重要的元素或所有重要行为相关的主要结构元素

2.   利益相关者(包括开发团队)的影响

- 架构平衡利益相关者的需要

- 架构最终解决利益相关者的功能或非功能的需求

- 架构包含了基于逻辑依据的决策

- 环境影响着架构,例如架构的上下文

- 架构影响团队结构

- 架构可能遵照架构风格

- 架构具有特定的范围

3.   关注点分离

- 架构定义相关元素的连贯组合,处理一组给定的关注点

 

在所有定义里面,共同的主题当然是“关注点分离”。划分关注点,从关注点的这些特定的范式中进行抽象,提供一个使用方式。

 

       论文“软件架构介绍”跟踪了软件架构观点的演进,从早期的计算到现在复杂的软件系统。在抽象层次以及如何谈论抽象层次上都有了提高。从早期的打孔卡的计算系统到编程语言,执行类似于循环、条件表达式、过程调用的通用模式出现,并由汇编语言转换为高级编程语言。焦点转移到了数据和关于不同类型数据不同结构化的概念上。抽象数据类型出现。不管是数据的单独处理,还是真的像数学函数所描述的那样计算,从早期的机器语言到高级编程语言到编程模式,尽管我们对软件的理解已经在演进,如何看待计算仍然有不同的观点。

 

       最终我们需要一种架构风格,按照这种风格我们可以在结构组织模式方面,定义一系列软件系统。这样的架构风格将能够决定被使用的组件、连接件、以及一系列连接约束的词汇。我们已经有软件架构的第一个概念了。

 

       Booch在他的个人网站Handbook of Software Architecture上一再提到,“软件开发,从根本上,一直是,现在是,并且将来仍然是很困难的。为此,软件工程的整个历史就是提升抽象层次的历史(因为我们人类在处理复杂事物时抽象是一种主要的方式),并且我们看到这也反映在我们的编程语言、平台、过程、工具,以及模式的成熟上面。事实上,每个结构良好的软件密集型系统里,从形成特定编程语言的使用风格到定义了社会中的对象、组件以及其他部分之间的协作的机制,到处都充满了模式。在抽象的最高层次,每个系统都有一个架构,包括关键的抽象和机制,它们定义了从各个利益相关者的角度所看到的不同的关注点的结构和行为。在任何情况下-从语言风格到机制再到架构-这些模式要么是有意要么是偶然的,但是只要他们是可见的,这些模式反映了每个系统的风格和内在的美。

 

       至于软件架构的重要性被总结成三点,它们在“软件架构实战”中有提到,前两个是:

  1. 作为利益相关者之间的通信手段,架构包括一组通用的系统抽象,系统的利益相关者们可以用来相互理解,协商,达成共识和沟通。
  2. 能够影响软件实现的早期设计决策,可以采用之前对架构风格方面的了解来指导。

 

第三点是说一个软件架构包括一个系统的可转移的抽象,它可以被用作相同结构的其他系统,但是我相信我们已经在架构中看到了抽象的作用。创建架构是因为需要,而不是重要,事实上正是架构关注的是结构元素的抽象,根本上这也是我们创建架构的原因。

 

       对我而言,十字架就是抽象层次的概念是怎样的,面向语言编程,面向特征编程和软件架构是联系在一起的,以致于想出面向语言(/面向特征)的软件架构。

抱歉!评论已关闭.