浅谈软件体系结构思想及其应用(原创)

浅谈软件体系结构思想及其应用

摘要

 

近年来,软件体系结构逐渐成为软件工程领域的研究热点以及大型软件系统开发中的重要技术之一,基于软件体系结构的软件开发模型较传统的软件开发模型有着显著的优势。本文在归纳了软件体系结构定义,发展背景,存在价值及其描述方法和基本构成模型的基础之后,阐述了软件体系结构的软件设计方法,解释并分析开发过程中用到的设计模式,建模方法,软件体系结构风格,以及软件工程领域的模块化思想等知识和技术,并在此基础上给出了基于软件体系结构的软件开发模型。

关键词:软件体系结构，传统软件开发，软件工程，体系结构风格，设计模式

 

 

Abstract

   Recently, Software architecture has become a more and more widely applied technique in huge software development, it has also grown into a hot point of software engineering, the software development based on software architecture has conspicuous advantage compared with the traditional software development model. After generalizing the definition, the developing background, the description and the significance of software architecture, this passage concentrates on the design method of software architecture, it will also explain and analyze the design pattern, modeling method , software architecture style as well as decomposition thinking applied in the developing process, and ultimately manifest the software development process based on software architecture.

Keywords: software architecture, traditional software development, software engineering, software architecture style, design pattern

前言

    伴随着软件工程领域的发展,软件体系结构的发展也由无体系结构阶段逐步跨越到以描述系统的高级抽象结构为中心的高级阶段,在此期间确立了一系列软件体系结构描述方法,体系结构风格以及基于软件体系结构的软件开发方法,这些技术被广泛地应用在软件生命周期中,方便了员工和客户交流,明确了员工间的分工,提高了软件的质量属性,增强了软件的复用性和可扩展性,软件体系结构理论也将伴随着软件工程的发展而不断进行自我完善。

1 软件体系结构综述

软件体系结构是根植于软件工程发展起来的一门新兴学科,目前已经成为软件工程研究和实践的主要领域。下面分别从其定义,存在价值，发展史，描述方法,核心模型角度来阐述软件体系结构。

1.1  软件体系结构的定义

软件体系结构至今还没有被大家所公认的定义，专家们从不同角度对其进行刻画,在总结并理解专家们观点的基础上,根据笔者的理解归纳为下:在软件产品线的开发中,由于需求的复杂性和可变性,需要在一个较高的层次上考虑系统的各部分构件,构件之间的交互以及形成的拓扑结构,这些构件及其交互所形成的功能模块需要满足一定的约束,遵循一定的设计规则,并能够在一定环境下重构和扩展。且能够反映出系统开发中有重要影响的决策以便设计人员,开发人员,客户,用户的交流,使开发的系统据此能够完成系统既定的功能和非功能性需求。

1.2  软件体系结构的存在价值

软件体系结构的产生有着多重价值。首先,体系结构式软件开发过程中不同角色的交流手段,体系结构代表了系统的公共的高层次抽象,一方面这种抽象易于让客户和用户理解,这样可以更准确地表达出对系统的可用性和可靠性及进度需求。另一方管理者可以更清晰地把握项目进度,开发者之间的交互遵循统一的规范。其次,体系结构明确了对系统的约束条件，决定了开发和维护组织的组织机构，好的体系结构将系统模块化,并使得每个模块实现了不同的功能,模块间的耦合度降到最低,这样管理者对系统的把握更加清晰,同时方便了开发者之间的任务分配。再次,软件体系结构体现并制约着系统的质量属性,在大型软件系统中,质量属性更多由软件的功能划分来实现。最后,软件体系结构为后面的开发提供了可重用的模型,软件体系结构的重用与代码重用相比能更大地降低软件的复杂度,好的体系结构经过稍稍抽象就可以应用到其他系统中去。

1.3  软件体系结构的发展史

随着软件系统的应用领域与规模不断扩大,软件体系结构也由最初模糊的概念发展到日趋成熟的技术。纵观软件体系结构技术的发展过程,一共经历了四个阶段。(1)无体系结构阶段,此阶段主要运用汇编语言。(2)萌芽阶段:此阶段出现了以控制流图和数据流图表述软件结构特征的程序设计主题。(3)初期阶段:出现了各种表达结构模型的方式uml为一典型代表示(4)高级阶段:以描述系统的高级抽象结构为中心,不关系具体的建模细节,以Kruchten提出的”4+1”模型为标志。

1.4  软件体系结构的描述方法

在软件体系结构的描述方面,Kruchten提出的”4+1”视图模型为当今体系结构描述的经典构造。即逻辑视图,开发视图,进程视图,物理视图和场景,”4+1”模型法，和基于场景迭代的方法作为基于过程驱动的体系结构的两种方法通用性很强，下面一一解释。

(1) 逻辑视图:主要支持系统的功能需求,在面向对象技术中逻辑视图通过抽象,封装和继承来表示，用类图来描述。

 

                          

 

 

 

 

 

 

 

 

 

 

图1.1 类图示例

 

(2) 开发视图:侧重于软件模块的组织管理。应该按照高内聚低耦合的原则保证开发的容易醒，软件的重用性和通用性。通常使用层次风格,层次越低通用性越强,这样可以方便扩展。

    

User’s Interface

Find a Room

2.0

Delete a Room

3.0

Enter a New Room

1.0

Establish a House

5.0

……

By Type of Floor

2.3

By Square Footage

2.2

By Room ID

2.1

……

Add a Room

5.1

Find a Room

5.2

Delete a Room

5.3

View House

5.5

……

By Room ID

5.2.1

……

                              图1.2 层次图示例

 

(3) 进程视图:关注一些非功能性的需求,强调系统的并发性,分布性,系统集成和容错能力。可以由顺序图,协作图和状态图来表示。

    

                            图1.3 状态图

    (4) 物理视图:考虑如何把软件映射到硬件上, 解决系统的拓扑结构,安装等问题。通常由配置图来表现。

 

图1.4 配置图    

(5) 场景:可以看做重要系统活动的抽象,帮助设计者找到构件之间的相互关系,通过场景可以将四种视图有机结合起来,细致描述需求和体系结构之间的关系,场景是用来测试软件体系结构可行性的重要技术。

1.5 软件体系结构的核心模型

软件体系结构的核心模型由五种元素组成:构件,连接件,配置,端口和角色下面一一给予解释:

(1) 构件:通常把可重用的软件元素(程序代码,测试用例,设计文档,设计过程,需求分析文档等)成为软构件。较面向对象相比,构件是对一组类的组合进行封装,抽象层次更高。构件为用户提供了多个接口,整个构件隐藏了具体的实现。构件针对领域开发,所谓领域是指具有相似或相近软件需求的应用系统所覆盖的功能区域。构件的组装方式分为基于功能的组装,基于数据的组装,和面向对象的组装。其中基于功能的组装技术采用功能分解的方式将系统分解为高内聚低耦合的一些模块。基于数据的组装技术采用面向数据的设计方法，如jackson开发方法,将数据结构层次化，按照从低到高的顺序组装模块。面向对象的组装技术采用继承的机制,扩展原构件功能。

(2) 端口:构件的接口由端口组成,提供了对程序的访问点。

(3) 用来连接不同构件实现不同功能。

(4) 配置表示构件与连接件的拓扑结构和约束

2 面向体系结构的设计方法

由于软件需求的获取要经历一个时间过程,软件必须支持广义的软件需求，但即便如此在作出最基本的设计决定时就要进行初步的体系结构设计，因此设计师需要一个更加科学的设计方法,未处理非确定软件需求提供策略。由此引入了基于体系结构的软件设计方法。基于体系结构的软件设计方法由体系结构驱动,在需求抽取和分析还没有完成的情况下开始,但在开始前仍需要获取一定的信息,这些信息如下

(1) 抽象功能需求:在某种抽象级别上获取的功能需求,以及对需求相关的粗略变化的描述。

(2) 用例:采用需求分析过程中的用例图来表示,是用户与系统之间交互的具体表述。

(3) 抽象的质量和商业需求:用户的功能和非功能需求,质量场景就是质量需求的具化,可以对质量场景进行分组

(4) 体系结构选项:针对不同质量和商业需求的可能的体系结构选项。

(5)约束:可以由商业目标或者遗留系统导出,即对体系结构提出的要求

2.1 设计模式与软件体系结构

   设计模式是一些设计面向对象的软件开发经验总结,利用设计模式可以方便地重用成功的设计和结构。模式针对特定问题提出,对体系结构的开发有着重要的意义。在这里我们拿mvc模式来说,以往的开发往往在视图中注入业务逻辑和数据库访问代码,导致视图变更的成本很大,mvc将数据库访问业务过程划分为视图,模型,控制层,这样业务逻辑交给了控制层来处理,模型层直接与数据库打交道, 控制层为视图层提供了通用接口,在这种情况下视图就可以更改而无需引起业务和数据访问层代码的变动,大大减轻了程序开发的负担,提高了代码的复用性。

   在大型软件开发项目中，单个模式不能完成一个完整的体系结构构造,我们需要引入不同的设计模式,将它们组织成模式系统,将设计模式充分应用到体系结构的整体和局部模块上去,提高程序的可重用性和扩展性,降低程序的开发成本。

2.2 面向体系结构设计的相关术语。

   在阐释体系结构的设计方法之前本文先对设计方法中涉及的相关术语予以介绍。

(1) 设计元素:泛指软件系统,概念子系统或者概念系统,通俗的讲,设计元素即系统分解的各个功能模块,其中每个设计元素都有一个概念接口,用来指示输入信息和输出信息。

(2) 视角和视图:与Kruchten提出的概念类似,详请参照上文。

(3) 用例和质量场景:用例即各个角色与系统交互时的行为,质量场景是定义的用来捕获质量需求的场景。

2.3 面向体系结构软件设计方法的具体步骤

   软件体系结构设计方法的具体步骤经历了分解系统为子系统,对各个设计元素进行功能分解,选择体系结构风格,为风格分配功能,细化模板,功能校验,创建并发视图,创建配置视图，验证质量成精和验证约束阶段。

2.3.1 分解整个系统为各个概念子系统  

系统基于高内聚低耦合的原则进行分解,分解的每一个设计元素都有一组需求,一组适合于自身的模板和一组约束。可以分别从深度和广度进行分解,所谓深度即按照层层依赖的顺序首先找出系统依赖的一个子系统,然后找子系统依赖的一个子系统…,整个过程递归进行,直至覆盖了所有的需求。所谓广度即先将一个系统分解为所需的所有子系统,在按照分解的顺序依次分解子系统。

2.3.2 设计元素的功能分解

对设计元素进行功能分解，将各个设计元素分解为子模块,组织成层次结构图,层次图的模型已在上面给出。在这里主要介绍分解的原则,即高内聚低耦合的原则,这个原则用来保持模块独立性。按照内聚程度从弱到强划分为巧合内聚,逻辑内聚,时间内聚,过程内聚,通信内聚,信息内聚,功能内聚。按照耦合程度从弱到强划分为非直接，数据耦合,标记耦合,控制耦合,外部耦合,公共耦合,内容耦合。下面对这些概念给予说明。

功能内聚:一个模块中的各个部分都是完成某一具体功能必不可少的组成部分。

信息内聚:这种模块完成多个功能,各个功能都在同一数据结构上操作

通信内聚:一个模块内各功能部分都是用了相同的输入数据,或产生了相同的输出数据称为通信内聚模块。

过程内聚:流程图中的某一部分划出来单独成为一个模块,此模块为过程内聚

时间内聚:模块内各个功能与时间相关。

逻辑内聚:由传入参数决定模块内的功能调用。

巧合内聚:模块没有联系或者联系很松散。

非直接耦合:两个模块没有直接关系,它们之间的联系完全通过主模块控制和调用来实现

数据耦合:模块间通过简单数据参数进行交互。

标记耦合:一组模块通过参数表传递记录信息,记录信息非简单变量。

控制耦合:一个模块通过传送控制信息控制选择另一模块的功能。

外部耦合:一组模块都访问同一个全局简单变量

公共耦合:一组模块都访问同一全局数据结构。

内容耦合:一模块直接访问另一模块内部数据或进入另一模块内部。

一个好的设计结构应该保持模块的扇出不能过多,扇入尽可能的多(这样的模块复用性高),低层次模块尽可能避免调用同级或者高层次的模块。

2.3.3 选择体系结构风格

为设计元素选择体系结构风格,不同设计元素间的风格可以使异构的。选择和细化体系结构风格的结果是一组体系结构构件类型。下面介绍几个实用的体系结构风格。

(1)   管道和过滤器风格:在这种风格中,每个构件都有一组输入和输出,整个模型像是一串构件相连,前一构件的输出是后一构件的输入。这种风格易于扩充(可以根据构件的接口加入删除一个或多个构件)，隐蔽性好，却不适合处理交互的应用。

(2)   数据对象和抽象组织风格:数据的表示和方法封装在抽象数据类型或对象中。构件作为对象具有面向对象风格封装性，多态性，继承性的优点,对象与对象之间通过调用函数进行交互。

(3)   基于事件的隐式调用:在基于事件的隐式调用中,每个构件注册其对应的事件,外部对象通过触发事件调用注册该事件的一系列构件的功能。触发者并不知道哪些构件会被这些事件影响，同时当一个构件需要加入现存系统中时只需在事件中进行注册,对软件重用提供了巨大支持。

(4)   分层系统:分层系统中,系统被组织成层次结构,下层模块为上层提供服务,每个层只对相邻的两个层有影响,由于层次风格结构清晰,各个层次间耦合度小,层次风格支持系统的增量开发。

(5)   仓库系统和知识库:此系统有两种不同的构件,中央数据结构和独立构件,独立构件共享中央数据结构。如果构件功能调用通过外部事件触发,此仓库为一数据库。若中央数据结构触发进程执行的选择,仓库为一黑板系统。

(6)   C2风格:在C2风格中,构件通过连接件绑定在一起,构件间的通信以连接件为中介进行,构件之间的依赖性较小。

(7)   客户/服务器风格:在此风格中,服务器负责数据管理,客户机完成用户的交互任务,对于胖客户端的C/S风格,客户端包含了业务处理和显示功能,服务器管理数据的访问。而在瘦客户端的C/S风格中,客户端只需要实现视图层的功能,剩下的功能交给服务器实现。C/S风格将不同的功能委托给不同的终端，使得客户机不必包含数据库管理系统的编码,而服务器服务器只需管理数据,降低了开发费用。

(8)   三层C/S结构风格：二层C/S结构存在着很多不足，首先其结构是单一服务器且以局域网为中心,其次在胖客户类型中,客户机的负荷过重,而且由于业务层的验证机制处在客户机上,对安全性形成了极大的威胁。同理,瘦客户C/S模型的服务器也有着同样的问题。基于此产生了三层C/S结构风格,在三层C/S体系结构中增加了一个应用服务器,负责业务层的功能。由于三层是分别放置在不同的硬件系统中,灵活性比较高,能够适应客户机数目的增加和处理负荷的变动。

(9)   浏览器/服务器风格:浏览器/服务器风格主要利用www浏览器技术,用户在使用系统时只需要一个浏览器就可以实现相应的功能,使得客户端的负担大大减轻。但是B/S风格缺乏对动态页面的支持能力,响应速度远低于c/s体系结构。

(10) 公共对象请求代理体系结构(corba):corba作为一种中间件在分布式系统中扮演着重要的作用,采用不同的语言编写的终端程序可以相互通信。Corba采用接口定义语言(IDL)定义接口,配合内部的接口映射机制,可以将IDL翻译成为java,c++,c所支持的接口语言。Corba主要内容包括接口定义语言,接口池(存储了接口的信息方便动态调用)，动态调用接口,对象适配器(向分布式系统中的服务端程序隐藏了CORBA的具体实现)。

(11) 正交软件体系结构:正交体系结构由线索和层组成,将系统分解为多个子系统,成为线索,在这里层代表了不同的功能模块,如三层体系架构中的用户接口层,业务层,数据访问层。由于正交体系结构将整个系统细化为线索和层,提高了模块独立性,方便了系统的修改和扩展,同时也明确了开发小组的分工。

2.3.4 为风格分配功能

   将前面功能分解所得到的各个功能分配给选择体系结构风格时产生的构件,标识每个构件的借口。

2.3.5 细化模板

   将模板细化为各个功能块,将功能加到模板中去,判断产生的功能是否覆模板内容。

2.3.6 功能校验

   通过用例验证设计元素的功能是否满足需求,和扩展的需求。

2.3.7 创建并发视图

   并发视图用来表示构件间的交互,设计元素间的交互,以及之间的并行性。

2.3.8 创建配置视图

配置视图用来为系统分配资源,配置单元是能够分配给处理器的最小设计元素,若涉及元素的粒度大于配置单元,则需要对其进行分解,从而将处理机充分利用。

2.3.9 验证质量场景

采用质量场景验证所创建的子设计元素是否满足用户的需求。

2.3.10 验证约束

验证系统约束有没有相互矛盾的地方,并将这些问题记入文档。

 

3 面向体系结构的设计和演化过程

传统的软件开发过程包括需求分析,概要设计,详细设计,软件测试等过程，软件体系结构的设计位于需求分析之后,软件设计之前,体系结构的设计过程是设计者从宏观结构上对整个系统进行分析,选择构件,选择构件之间的交互,最后形成一个满足用户需求的系统框架的过程。基于体系结构的软件开发过程可以分为独立的两个阶段,实验原型阶段和演化开发阶段。实验原型阶段用户采用构件原型的方法获得对系统支持的问题域的理解,并与实际的最终用户一起讨论和评审。演化开发阶段将重点放在最重产品的开发上,在原型的基础上完成系统的设计。下面详细论述这两个阶段所做的工作

3.1 实验原型阶段

    在此阶段,开发人员被分为两个组,一组创建图形用户界面,另一组创建一个问题域，问题域模型可由一个统一建模语言类图表示。第一个周期结束时产生图形用户界面的初始设计和问题域模型。第二个周期设计和建立一个正交软件体系结构。下面对第二个周期的各个阶段分别论述

(1)   标识构件:

生成类图,可以采用Rational Rose 2000建模。对类进行分组,即通过类之间的不同关系将类分组,这些关系有泛化关系(继承与被继承),聚合关系(诸如教室由黑板,讲台,课桌等聚合而成),组合关系(诸如汽车的颜色是红色,颜色属性与汽车就是组合关系)。将类打包成构件,把第二步得到的类簇打包成构件，这些构件可以组合成更大的构件。

(2)   提出软件体系结构模型:即选择合适的软件体系结构风格。

(3)   把已标识的构建映射到软件体系结构中。

(4)   分析构件间的相互作用:这个过程可以利用UML的顺序图来完成。

(5)   产生软件体系结构:有了构件和其间的相互关系,软件体系结构自然而然的产生。

(6)   软件体系结构正交化:按照模块独立性的原则将软件体系结构进行正交化。

3.2 演化开发阶段

一旦正交体系结构得以确立,就可以开始正式的构件开发工作,由于正交体系结构的各个线索相互独立,可以把开发人员分成若干个小组进行开发。具体过程如下:

(1)   需求变动归类:将用户的需求变化归类,并将这些需求与已有的构件和线索对应。

(2)   制定体系结构的演化计划:制定好周密的体系结构演化计划作为后续开发的指南。

(3)   修改,增加或删除构件:开发人员根据第一步的需求变动归类对构件的修改,增加或删除操作进行归类。

(4)   更新构件之间的相互作用:更新构件之间的控制流

(5)   产生演化后的体系结构:对原体系结构进行的修改必须集成到原体系结构中

(6)   迭代:把3-5步迭代一次或者多次

(7)   进行技术评审

(8)   对所做的标记进行处理:重新开始一次演化过程,对构建按照标记要求进行修改,删除,更换。

结论

   本文在较大范围内介绍了软件体系结构的概念,阐述了基于软件体系结构的设计方法及其过程。但由于缺少实际的应用实践,此文章尚停留在理论阶段,还需要在实践中逐步完善。

参考文献:

[1] Bijay K. Jayaswal, Peter C. Patton.  Software Development Methodology Today. 美国: Prentice Hall. 2006.8

[2] N Medvidovic. A classification and comparison framework for software architecture description languages. Feb 1996

[3]  多切蒂.  面向对象分析与设计.  北京:清华大学出版社. 2006年4月 参考所述的开发过程

[4] 软件体系结构教程，李代平等．北京：清华大学出版社，2008

[5] 软件体系结构（第二版），张友生等．北京：清华大学出版社，2006.11

[6] 基于模板的软件体系结构描述技术, 高晖等 北京航空航天大学 2008

[7] 基于体系结构、面向构件的软件开发方法,梅宏等,北京大学, 2003.1

[8] 软件体系结构理论与实践，冯冲 江贺 冯静芳，北京：人民邮电出版社，2004.1

[9] 软件体系结构教程，李代平等．北京：清华大学出版社，2008

[10] 软件体系结构的艺术，阿尔宾．机械工业出版社，2004.1