几种常见的软件体系结构及特点分析
20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构和算法的选择上，然而随着软件系统规模越来越大，对总体的系统结构设计和规格说明变得异常重要。随着软件危机程度的加剧，软件体系结构(software architecture)这一概念应运而生。软件体系结构着眼于软件系统的全局组织形式，在较高层次上把握系统各部分之间的内在联系，将软件开发的焦点从成百上千的代码上转移到粒度较大的体系结构元素及其交互的设计上。与传统软件技术相比，软件体系结构理论的提出不仅有利于解决软件系统日益增加的规模和复杂度的问题，有利于构件的重用，也有利于软件生产率的提高。面向方面软件开发(AOSD)认为系统是由核心关注点(corn concern)和横切关注点(cross-cutting concern)有机地交织在一起而形成的。核心关注点是软件要实现的主要功能和目标，横切关注点是那些与核心关注点之间有横切作用的关注点，如系统日志、事务处理和权限验证等。AOSD通过分离系统的横切关注点和核心关注点，使得系统的设计和维护变得容易很多。
Extremadura大学的Navasa等人［1］在2002年提出了将面向方面软件开发技术引入到软件体系结构的设计中，称之为面向方面软件体系结构(aspect oriented software architecture，AO-SA)，这样能够结合两者的优点，但是并没有给出构建面向方面软件体系结构的详细方法。
尽管目前对于面向方面软件体系结构这个概念尚未形成统一的认识，但是一般认为面向方面软件体系结构在传统软件体系结构基础上增加了方面构件(aspect component)这一新的构成单元，通过方面构件来封装系统的横切关注点。目前国内外对于面向方面软件体系模型的研究还相对较少，对它的构成单元模型的研究更少，通常只关注方面构件这一构成单元。方面构件最早是由Lieberherr等人［2］提出的，它是在自适应可插拔构件(adaptive plug and play component，APPC)基础之上通过引入面向方面编程(AOP)思想扩展一个可更改的接口而形成的，但它关于请求接口和服务接口的定义很模糊，未能给出一个清晰的方面构件模型。Pawlak等人［3］提出了一个面向方面的框架，该框架主要包含了一个方面构件模型———Java方面构件(Java aspect component，JAC)，但该方面构件模型仅包含了切点(pointcut)，并把AOP中装备(advice)集成到了切点的表达式中，它主要从实现的角度进行了阐述，并没有给出详细的方面构件模型。本文没有只关注面向方面软件体系结构中方面构件这一构成单元模型，还详细分析了它的另外两个构成单元，即构件和连接件，因为面向方面软件体系结构各部分之间是相互关联的。
1面向方面软件体系结构相关概念
面向方面软件体系结构涉及诸多概念，以下将分别介绍。软件体系结构在软件工程领域有着广泛的影响，但当前仍未形成一个统一的、标准的定义。目前国内外普遍认可的看法是软件体系结构包含构件、连接件和约束［4］。其中约束描述了体系结构配置和拓扑的要求，确定了体系结构的构件与连接件的连接关系。这样就可以把软件体系结构写成
软件体系结构(software architecture)=构件(components)+
连接件(connectors)+约束(constraints)
构件是软件体系结构的基本元素之一。一般认为，构件是指具有一定功能、可明确辨识的软件单位，并且具备语义完整、语法正确、有可重用价值的特点，然而目前对于构件的具体结构及构成并没有一个统一的标准［5］，而且一些主要的构件技术也没有使用相同的构件类型。另外，当前被广泛接受的构件定义并不包含具体的软件构件模型(software component model)。例如，Szyperski等人［6］给出了软件构件一个很有名的定义:软件构件是一个仅带特定契约接口和显式语境依赖的结构单位，它可以独立部署，易于第三方整合。但是关于软件构件模型有一个被普遍接受的观点是:软件构件是一个具有服务提供和服务请求功能的软件单元［7］。
连接件是软件体系结构另一个基本的构成元素，是用来建立构件间交互以及支配这些交互规则的构造模块。连接件最先是由Shaw［8］提出来的，她建议把连接件作为软件体系结构中第一类实体，用来表示普通构件之间的交互关系。目前对于连接件尚未形成统一的认识，尽管在软件体系结构中强调了连接件存在的必要性，但是关于连接件模型的研究还很少，连接件的实际应用还不成熟。
面向方面软件体系结构在传统软件体系结构的基础上增加了方面构件单元。通常认为，方面构件是封装了系统横切关注点的一类特殊的构件。目前关于方面构件模型的研究还处于起步阶段。
2面向方面软件体系结构模型
由于传统软件体系结构模型包含构件、连接件和约束，而面向方面软件体系结构是在传统软件体系结构的基础之上扩展了方面构件，所以面向方面软件体系模型结构包含构件、连接件、方面构件和约束。其中约束描述了面向方面体系结构配置和拓扑的要求，确定了体系结构的构件、连接件和方面构件之间的连接关系，而构件、连接件、方面构件是它的三个基本的构成单元。以下对这三个构成单元的模型进行详细的设计。
软件的实用性要从哪些方面来进行分析？
如何进行软件需求分析
需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求。
关键的问题是一定要编写需求文档。我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起。系统的分析人员说："我们想与你谈谈你的需求。"客户的第一反应便是："我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统"。而实际上，需求并未编写成文档，因此新的分析人员不得不从头做起。所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人。
需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明"。有些需求分析专家拓展了这个概念："从系统外部能发现系统所具有的满足于用户的特点、功能及属性等"。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性：
需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。
从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的"需求"术语存在，真正的"需求"实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。
任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述。
