如何选择合适的软件体系结构

㈠ 如何选择合适的软件体系结构设计方法

（1）软件体系结构的多视图建模
通过逻辑视图，开发视图、进程视图、物理视图、进程来描述的软件体系结构。
（2）基于评估与转换的软件体系结构设计
通过迭代的开发方式，直至满足客户的需求。
（3）模式驱动的软件体系结构设计
通过总结、记录、复用来实现的体系结构设计
（4）领域特定的软件体系结构设计
借鉴领域中已经成熟的软件体系结构来实现解决方案在某个领域内的复用。
（5）软件产品线方法
软件复用发展的一个更高阶段，它并不仅仅局限于以前人们在软件复用中考虑的对函
数、模块、类、体系结构甚至子系统的复用。
（6）其于目标推理的软件体系结构设计方法
功能需求和非功能需求皆被表达为要达到的目标。
（7）其于属性的软件体系结构设计方法
基于目标图推理的体系结构设计方法、基于属性的体系结构设计方法。
开发心得：
在这些具有系统化过程的软件开发方法中，体系结构设计师一个不可避免
的过程，它们也都有自己的一些设计方式。但这并不排斥前面讲到的软件体系结构设计
方法，反之，如果能把这些体系结构设计方法与开发方法学结合起来，将能起到更好的
效果。

㈡ 求一篇关于 软件体系结构分析 的论文

软件体系结构论文：一种面向方面软件体系结构模型
摘 要: 为了分离软件系统中的核心关注点和横切关注点，通过引入面向方面软件开发的思想设计了一种面向方面软件体系结构模型，并详细分析了该模型的三个基本构成单元，即构件、连接件和方面构件。最后通过一个网上支付实例验证了该模型具有一定的理论意义和实用价值。
关键词: 面向方面软件体系结构;横切关注点;构件;连接件;方面构件
20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构和算法的选择上，然而随着软件系统规模越来越大，对总体的系统结构设计和规格说明变得异常重要。随着软件危机程度的加剧，软件体系结构(software architecture)这一概念应运而生。软件体系结构着眼于软件系统的全局组织形式，在较高层次上把握系统各部分之间的内在联系，将软件开发的焦点从成百上千的代码上转移到粒度较大的体系结构元素及其交互的设计上。与传统软件技术相比，软件体系结构理论的提出不仅有利于解决软件系统日益增加的规模和复杂度的问题，有利于构件的重用，也有利于软件生产率的提高。面向方面软件开发(AOSD)认为系统是由核心关注点(corn concern)和横切关注点(cross-cutting concern)有机地交织在一起而形成的。核心关注点是软件要实现的主要功能和目标，横切关注点是那些与核心关注点之间有横切作用的关注点，如系统日志、事务处理和权限验证等。AOSD通过分离系统的横切关注点和核心关注点，使得系统的设计和维护变得容易很多。
Extremara大学的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面向方面软件体系结构模型
由于传统软件体系结构模型包含构件、连接件和约束，而面向方面软件体系结构是在传统软件体系结构的基础之上扩展了方面构件，所以面向方面软件体系模型结构包含构件、连接件、方面构件和约束。其中约束描述了面向方面体系结构配置和拓扑的要求，确定了体系结构的构件、连接件和方面构件之间的连接关系，而构件、连接件、方面构件是它的三个基本的构成单元。以下对这三个构成单元的模型进行详细的设计。
2.1构件模型
构件模型由以下几个要素构成(图1):
(a)端口。
构件的服务请求和服务提供功能是通过端口来实现的。端口是构件与外部环境进行交互的惟一通道。一般的构件模型通常采用两种端口，即双向端口和单向端口。在使用双向端口的构件模型中，服务请求和服务提供功能可以在同一个端口中实现。本文中的构件模型使用单向端口，此种端口分为请求端口和服务端口两种类型。
(a)服务端口。构件通过服务端口向其他构件提供服务。构件通过服务端口向其他构件的请求消息进行应答，返回响应消息。每个服务端口对应一个接口。
(b)请求端口。构件通过请求端口向其他构件请求服务。构件为了实现自己的业务功能，需要通过请求端口向其他构件发送请求消息。每个服务端口也对应一个接口。
(b)接口。
它定义了一个到多个业务功能。这些业务功能由服务端口进行提供，并由请求端口进行使用。一个接口限定了一个特定端口可以进行的交互功能，接口是构件间交互的契约。通常的接口类型有:Java Interface、WSDL 1．1 portTypes和WSDL 2．0 Interfaces等，也可以自定义接口类型。
(c)属性。
与类或对象相似，构件也具有属性，属性可以在构件使用前进行配置，它能够反映构件在交互过程中状态的变化。
2.2连接件模型
连接件是用来建立构件间交互以及支配这些交互规则的体系结构构造模块。连接件为构件间信息交互提供传输和路由服务。在最简单的情况下，构件之间可以直接完成交互，这时体系结构中的连接件就退化为直接连接。在更为复杂的情况下，构件间交互的处理和维持都需要连接件来实现。对于构件而言，连接件是构件的粘合剂，是构件交互的实现，也可以看做是一种特殊的构件［8］。与构件相似，连接件也具有端口。连接件的端口可分为两种类型，即源端口(source port)和目标端口(target port)。源端口用于接收构件请求端口中的消息，目标端口用于向构件服务端口中输入消息。连接件通常需要使用一种合适的绑定(binding)机制，构件的请求端口使用这种绑定机制来描述服务请求的方法，构件的服务端口也使用这种机制来描述构件进行请求的方式。常用的绑定机制有:WebService Binding和JMS Binding等，也可以自定义绑定机制。与构件一样，连接件也具有属性，来表示构件间交互的状态变化，如图2所示。

2.3复合构件模型
构件可分为两种，即原子构件和复合构件。前者是不可再分的构件。后者是可再分构件，它封装了若干个子构件。子构件间通过连接件相互连接，且子构件的端口也可以暴露成为复合构件的端口，子构件也可能是复合构件。如图3所示:复合构件A包含两个子构件B和D，子构件B和D通过连接件C进行相连，构件B的服务端口E暴露成为复合构件A的服务端口F，其请求端口G暴露成为A的请求端口H。
2.4方面构件模型
方面构件是面向方面软件体系结构的一个核心的构成单元，它封装了横切关注点，这是与传统软件体系结构最大的不同之处。图4给出了方面构件模型，与普通构件一样，方面构件也有服务端口和请求端口以及属性，但是它还有普通构件所没有的方面端口。当一个构件具有一个方面端口时，即可认为此构件就是方面构件。一个方面端口中包含若干个方面，这与一般面向方面编程(AOP)技术中方面概念有所不同。面向方面编程具有以下四个基本概念:方面(aspect)、连接点(joinpoint)、通知(advice)和切点(pointcut)。连接点是应用程序执行过程一个定义明确的位置，如方法调用是一种典型的连接点。切点是一系列连接点的集合，是方面的作用点。通知表述了在切点所选定的连接点处要执行的动作，常见通知类型有before、around和after等，分表代表在连接点之前、连接点附近和连接点之后执行相应的通知代码。方面是用来描述和实现横切关注点的基本单位，由切点和通知构成。方面端口中的方面横切关注的是构件，这与一般AOP(如AspectJ)横切关注的对象(object)不同，由于构件能够表达对象所不能表达的请求服务的能力［9］，这使得方面端口中方面所采用的连接点模型和切点语言具有很大的不同。

2.4.1连接点模型
该连接点模型包含两种不同类型的连接点，即构件服务端口中的服务提供操作和请求端口的服务请求操作。由于构件的内部结构通常被视为黑盒，因此连接点模型应该仅考虑构件的外部可见元素，如构件请求端口和服务端口中的服务操作。如果连接点模型包含构件的属性，那么它将会破坏构件的分装性。
2.4.2切点语言
用来选用连接点的切点语言基于切点表达式，表1给出了切点的五个组成部分，即component、jp_type、port、interface和service，然后分别对其进行了说明。其中，jp_type代表选用的连接点类型，可以是请求端口中的服务、服务端口中的服务或所有端口中的服务，详细如表1。表2给出了切点语言的一些例子，其中正则表达式基于java．util．regexp包。

2.5面向方面软件体系结构模型
面向方面软件体系结构由构件、连接件、方面构件组成，详细请参见图6。

3基于面向方面软件体系结构模型的网上支付实例
近年来，网上购物发展迅速，网上支付是消费者主要的支付手段之一，图7给出了基于面向方面软件体系结构的网上支付模型，它由四个原子构件，即一个复合构件、两个方面构件和三个连接件组成。其中WebClientComponent代表客户端构件，它可以向网上银行构件WebBankComponent请求AccountService()服务，该服务有三个参数，即username、password、cost，分别对应于用户的网上银行账户名、密码及购买商品的消费金额。
〈component name="WebClientComponent"〉〈required．port name="WebClientRequest"〉
〈java．interface interface="AccountServiceInterface"〉〈service name="AccountService()"〉
〈param name="username"type="string"/〉
〈param name="password"type="string"/〉
〈param name="cost"type="float"/〉
〈/service〉〈/java．interface〉
〈/required．port〉
〈/component〉
连接件AccountServiceConnector用于连接客户端构件和网上银行构件，它采用WebServiceBinding绑定机制。
〈connector name="AccountServiceConnector"binding="WebServi-ceBinding"/〉
〈source name="S"/〉〈target name="T"〉
〈/connector〉
〈connect．source from="WebClientComponent．WebClientRequest"to="S"/〉
〈connect．target from="T"to="WebBankComponent．Bank-Re-sponse"/〉
网上银行构件是一个复合构件，由账户服务构件Account-ServiceComponent、账户数据库连接件AccountDBConnector和账户数据库构件AccountDBComponent组装而成。其中该复合构件的服务端口也使用接口AccountServiceInterface，这是为了兼容客户端构件请求端口使用的接口。
身份验证构件AuthenticationComponent用于验证用户的身份信息，它通过UserInfoConnector连接件访问用户信息数据库构件UserInfoDBComponent。
pointcut="WebBankComponent;BankResponse;AccountServiceInterface;AccountService()"
是该方面构件的方面端口中使用切点的表达式。
为了保证数据库构件UserInfoDBComponent和AccountDB-Component的安全性，方面构件SecurityComponent使用方面端口Security监视这两个构件的服务端口，使得在这两个构件服务调用之前增加日志和事务功能，而日志和事务功能在系统中通常表现为横切关注点，面向方面软件体系结构能够对它进行很好的封装，便于设计和维护。
〈aspect．component name="SecurityComponent"〉〈aspect．port name="Security"〉〈aspect〉〈pointcut="UserInfoDBComponent;UserInfoResponse;*;*|Ac-countDBComponent;AccountDBResponse;*;*"/〉〈advice．role="before"action="Log()"/〉〈advice．role="before"action="Transaction()"/〉〈/aspect〉〈/aspect．port〉〈required．port name="UserInfoRequest"/〉〈/aspect．component〉
4结束语
本文给出了一种面向方面软件体系结构模型，详细设计了它的三个基本构成单元模型，即构件、连接件和方面构件;最后通过一个网上支付实例验证了该模型有效性和实用性，为面向方面软件体系结构的实际应用奠定了一定的基础。笔者将继续完善该模型的相关理论，研究面向方面软件体系结构的工程化应用方法。
参考文献:
［1］FABRESSE L，DONY C，HUCHARD M．Foundations of a simpleand unified component-oriented language［J］．Journal of ComputerLanguages，Systems＆Structures，2008，34(2-3):130-149．
［2］LIEBERHERR K，LORENZ D，MEZINI M．Programming with as-pectual components，T R NU-CSS-99-01［R］．［S．l．］:NoutheastamUniversity，1999．
［3］PAWLAK R，SERNTURIER L，DUCHIEN L D，et al．JAC:an as-pect-based distributed dynamic framework［J］．Software Practiceand Experiences，2004，34(12):1119-1148．
［4］李千目．软件体系结构设计［M］．北京:清华大学出版社，2008．
［5］马亮，孙春艳．软件构件概念的变迁［J］．计算机科学，2002，29(4):28-30．
［6］SZYPERSKI C，GRUNTZ D，MURER S．Component software:be-yond object-oriented programming［M］．2nd ed．［S．l．］:Addison-Wesley，2002．
［7］LAU K K，WANG Z．Software component models［J］．IEEE TransSoft Eng，2007，33(10):709-724．
［8］SHAW M．Procere calls are the assembly language of software in-terconnection:connectors deserve first-class status［C］//Proc of InICSE Workshop on Studies of Software Design．1993:17-32．
［9］NAVASA A，PREZ M A，MURILLO J M，et al．Aspect orientedsoftware architecture:a structural perspective［C］//Proc of Workshopon Early Aspects．2002．

㈢ 软件体系结构的评估方法有哪些

评估方法
成功的体系结构遵循各种指导原则和最佳实践。SEI 在这方面做了广泛的研究，并最终创建了几种用于改进和评估体系结构的方法。四种代表性的方法如下：
质量属性专题研讨会 (QAW)
体系结构权衡分析方法 (ATAM)
软件体系结构分析方法 (SAAM)
积极的中间设计审核 (ARID)
QAW 在定义体系结构之前执行，ARID 在设计工作过程中执行，而 ATAM 和 SAAM 则在已经完成体系结构之后执行。这些方法的引出部分的执行由一个协调人员引导。

㈣ 体系结构与开发平台选择

原型系统架构分硬件架构、软件架构和部署方式3个方面。硬件部分描述了系统在部署的时候会涉及的服务器角色、不同角色之间的关联关系和网络连接方式；软件架构描述了系统各软件组件之间的层次关系；部署方式说明系统在不同用户环境下的配置形式。

5.2.5.1 硬件体系结构

按照原型系统的功能要求，根据数据处理流程，从多种数据源输入开始，到数据存储和处理，再到面向最终用户的不同形式展现，分来源/控制、存储/处理，以及运算/发布3个层次来设计系统硬件体系结构。硬件体系结构的设计需要根据系统对多数据源、多种数据处理方式、多种展现方式和多用户等功能要求，将不同的功能模块独立部署于不同的硬件平台，以满足系统的多种功能要求，支持负载均衡控制，提高系统的可扩展性（左美云等，2006）。系统的硬件体系结构见图5.24。

图5.24 系统硬件体系结构

（1）第一层次：来源/控制

系统的数据来源有Internet自动抓取、人工输入、模型运算输入等。数据下载服务器（Data Download Server）负责从Internet自动抓取数据，其中抓取的数据类型包括不同网站来源的石油价格数据以及影响石油价格的事件等；模型运算服务器（Model Server）负责模型的运算执行，并生成模型运算的结果数据。数据下载和模型运算的数据将存储到中心数据库服务器（Center Database Server）中，由中心数据库来完成数据归一、合并、错误数据检测等任务。

（2）第二层次：存储/处理

第二层次包含的中心数据库是整个系统的核心。通过设置中心数据服务器，完成存储在中心数据库中的数据增加、修正、计算、展现等任务。中心数据库除了由第一层次的数据下载服务器和模型运算服务器获取数据之外，还需要提供数据的人工输入，并为模型运算服务器提供中间数据接口任务。

除此之外，考虑到数据量规模，中心数据库服务器可以兼备数据仓库服务器（Data Warehouse Server）的角色。中心数据库服务器对数据仓库数据的生成、转换进行控制，提供具有星型架构的多维数据源。

（3）第三层次：发布/展现

第三层次负责完成对中心数据库中的数据进行提取，按照不同的应用进行展现。第三层次包括GIS展现服务器（GIS Server）、数据发布服务器（Data Deployment Server）等，这些服务器由独立的W eb服务器（Web Server）向网络用户提供单一的用户访问接口。GIS展现服务器负责对系统的GIS展现部分提供支持，包括国家风险、运输风险等。数据发布服务器则包含了所有二次开发的系统数据处理内容，包括各个风险模块中的指标体系定义和评价、基本数据的维护和展现等。此外，第三层次还提供对系统中心数据库的多维数据的展现功能，提供数据的切片、旋转、上钻、下卷等多维操作，并可以对结果数据进行导出。

GIS展现服务器从中心数据库服务器处获得的数据包括展现对象的基本信息、风险值等；数据发布服务器从中心数据库服务器处获得的数据包括石油价格、汇率、影响油价的事件等，另外数据发布服务器还从数据仓库服务器（中心数据库服务器）读取多维数据源。

5.2.5.2 软件体系结构

在软件体系结构设计方面，通过对系统关于国家风险、运输风险、市场风险、需求风险和供应风险的功能需求进行分析，抽象出共性的功能，依照三层设计的原则进行系统软件体系结构的设计，如图5.25所示，包括数据层、中间层和用户层。

图5.25 系统软件体系结构

在系统的软件体系结构中，系统运行管理模块具有贯穿全局的作用，负责对系统各个层次功能的运行参数进行配置，控制系统的权限等（左美云等，2006）。此外，系统的主体可以划分为数据层、中间层和用户层3个相互作用的软件层次结构。

（1）数据层

系统的数据层以中心数据库为核心。图5.26展示了处于数据层中的中心数据库里面的相关数据信息类别。可见，中心数据库是整个系统的基础，提供了所有数据的存储空间。在中心数据库层和程序代码之间设置了数据访问中间层，用来抽象程序对数据库的访问，提供统一的数据访问接口，提高程序代码对数据库平台的独立性。

图5.26 中心数据库内容

（2）中间层

系统的中间层包括数据抓起模块、图库管理模块、指标管理模块、模型运算模块和基础信息维护模块。

数据抓取模块负责对Internet数据进行抓取和更新。数据抓取模块自动连接不同的数据源网站，将网站上的数据经过下载、转换和过滤等处理，更新到中心数据库中，其中还要求留有处理各个阶段的详细日志。在数据抓取到本地的中心数据库之后，多个数据源的数据需要合并到一起，向数据使用者提供单一的数据出口。

图库管理模块为系统中国家、港口等模块中涉及的图片进行集中管理，完成图片的更新控制等。

指标管理模块将多个功能中所包含的指标归类形成一个共享模块。指标管理模块主要包括评价对象定义、评价指标维护、评价方法审核、评价值录入、评价指标存储、评价指标体系展现等功能。指标管理模块按照树形方式提供评价指标的定义功能，并可以提供按照时间版本进行管理的历史评价指标，同时为展现模块提供指标的查询和显示接口。

模型运算模块主要处理系统要求的数据计算模型，模型数据来源和数据输出需要经过数据访问中间层连接到中心数据库。在这个过程中，模型运算模块调用数据处理模块获得数据输入，并将模型运算结果依据模型本身的要求输入到中心数据库中。如油价预测模型以及石油市场风险预测模型就是模型运算模块中非常重要的组成部分。油价预测模型读取数据抓取模块获得的原始油价数据，在客户端进行计算预测，并显示预测结果；石油市场风险预测模型读取进行结构转换后的中间油价数据，接受用户输入的参数，计算并输出结果和报告。模型运算模块需要定义统一的模型结构，为多单位联合开发提供一致的接口，便于集成。

基础信息维护模块主要负责完成系统内实体对象相关属性信息的修改维护功能，主要包括国家、港口和航线等对象。

（3）用户层

用户层负责用户和系统接口的交互，包括GIS、价格数据、数据仓库、指标等多种展现形式完成交互。GIS展现和指标展现是最终用户界面的主要显示内容，主要功能包括多个风险的GIS展现、风险对象详细信息的查询显示和风险评价指标的显示等以及模型运输结果的展示等；价格展现模块则主要提供石油价格数据和影响油价事件的查询显示和导出；数据仓库展现模块从数据仓库读入数据，按照用户的要求进行国际石油价格的多维展现，包括价格按照市场、油品、价格类型和时间等多个维度的分析。

5.2.5.3 系统部署方式

在海外油气资源利用的风险管理系统中，系统的用户分为普通用户和管理员用户，这些用户的分布位置分散，特别是最终用户，包括了不同单位、不同地理位置，以及不同的访问终端等。为了最大程度地提高系统的灵活性和兼容性，在部署上主要采取了B/S（浏览器/服务器）的结构形式，以降低系统对客户端的要求，提高系统的可维护性。考虑到部分功能模块的特殊需求，采用了C/S（客户机/服务器）结构，这些主要是数据抓取和部分需要独立运行的模型程序。

5.2.5.4 开发平台选择

开发平台采取具有较高开发效率的.net平台为主体。Microsoft.net是一种全新的运算平台，其核心内容之一就是要搭建第三代互联网平台，以最大限度保护用户的现有投资和适应未来发展的需要。Microsoft为促进.net应用程序的开发而推出的Visual Studio.net集成开发环境中包含了许多强大的工具，并且支持多种编程语言，如 C＃,Visual Basic.net,ASP.net等，这些编程语言可以实现代码级的无缝链接。

整个开发平台的选型如下：

1）服务器操作系统：Microsoft Windows Server 2003;

2）数据库管理系统：Microsoft SQL Server 2008;

3）内容管理系统：Microsoft Sharepoint Service 3.0,Microsoft Office Sharepoint Design 2007;

4）工作站操作系统：IE/FireFox/Opera等主流浏览器，Windows/Linux平台；

5）应用系统开发环境：Microsoft Visual Studio 2008;

6）应用系统开发语言：C＃,ASP.NET,VB.net，框架为.net Framework 2.0;

7）GIS开发软件：MapInfo MapXtreme 2008;

8）数据仓库软件：QlikTech QlikView 9.0。

㈤ 什么是软件架构

当你去了解一个东东的时候，第一步要做的，就应该去知道这个东东的定义，对于软件架构也是如此，经过网上查询和书籍的帮助，我大概理清了一个轮廓。
软件行业是一个热衷于制造‘名词’的行业，如果退回15年，估计没几个人知道‘软件架构’是什么，在上个世纪80年代，随着软件开发的规模不断扩大，软件开发成为一个行业，初期，随之而来的是越来越多的软件项目的失败，造成项目失败的原因很多，但主要集中在开发过程，所以软件工程应运而生，CMMI等流程标准也是一茬接着一茬的冒个不停。
在软件工程初具规模的时候，软件开发还是以数据结构+算法的形式存在，进入20世纪最后10年，随着面向对象技术、设计模式等在开发过程中的成功应用，软件架构也走进了大家的视野。
软件架构在定义上分为‘组成派’和‘决策派’两大阵营，分别描述如下：
’组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互
。它有两个非常明显的特点：
关注架构实践的客体——软件，以软件本身作为描述对象。
分析了软件的组成，说明软件不是一个‘原子’意义上的整体，而是有不同的部分经过特定的接口进行连接组成的一个整体，这对软件开发来说很重要。
‘决策派’认为
软件架构包含了一系列的决策
，主要包括：
软件系统的组织
选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为
用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合
软件架构并不仅仅关注软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。
‘决策派’有以下两个显着的特点：
关注软件架构中的实体——人，以人的决策为描述对象。
归纳了软件架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能性需求的决策。
按照‘组成派’的观点，软件架构关注的是软件整体的分割和交互，之所以分割，是因为不同的部分在逻辑或物理上相对独立，通过‘分而治之’的原则进行分割可以更好的理解整个系统，把握用户的需求，但是虽然整个软件可以分割成多个模块或子系统，但是模块和子系统之间的通信和交互也是很重要的，我想按照这种观点，架构师的主要任务是将软件分割成不同的模块，并定义模块之间的接口。
按照‘决策派’的观点，软件是一个在很多限制下产生的产品，这些限制包括用户和技术两方面，用户方面包括功能需求、性能需求、硬件需求等，技术方面包括技术选择、可扩展性、可重用性、可维护性等。我想按照这中观点，架构师的主要任务就是作出上述个各种限制作出选择或决策。《软件架构设计》 温昱

㈥ 因特网应用软件架构主要有哪两种组织架构模型

网络体系结构是固定的。
指通信系统的整体设计，它为网络硬件、软件、协议、存取控制和拓扑提供标准。
它广泛采用的是国际标准化组织，并为应用程序提供了特定的服务集合，分层思想比如应用层，传输层等。应用程序体系结构由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。在选择应用程序体系结构时，有两种主流体系结构，serverclient结构或p2p体系结构。

㈦ 流程管理软件的流程管理软件系统的体系结构

以Internet为代表的信息技术的快速发展和应用改变着企业的商业环境，使商业运行节奏越来越快，企业的价值链更加紧密和多样性.企业的布局和资源的配里不以地域、国家和行业为主要考f，而是根据企业价值链，通过优化资源配里、降低企业的组织成本和交易成本，提升企业的市场竞争力，进而使企业的价值最大化。这种以价值链为核心的企业变革主要表现为企业的重组(包括组织结构、业务流程和业务操作方式的重组)，CSCIndex顾问公司抽查621家北美和欧洲最具实力的企业调查结果表明，在497家北美公司中有69%、在124家欧洲企业中有75纬都推行一项或多项不同的企业重组工程;其中业务流程重组最为突出，因为企业流程的重组可获得的“戏剧性”成就— 将生产周期缩短70%，成本降低40肠，顾客满意度、产品质I$和总收入均提高40%。比如，柯达公司对新产品开发实施业务流程重组，把35毫米焦距一次性照相机从产品概念到产品生产所需要的开发时间一下子缩减了50%.从原来的38周降低到19周。
企业的重组工程的趋势是朝电子商务的运营模式转变，这种变化深刻影响着企业的组织结构和企业内部的作业流程。因此，必须解决企业应用中的“信息孤岛”现象，把针对相对具体和复杂业务的各项独立系统集成起来是企业信息系统支律企业重组工程面临的问题.在构造一个信息系统时每一个项目干系人(Stakeholder)都要考虑如何提高系统柔性，以支持企业重组和业务流程再造?如何集成异构系统，对原有系统资源的利用和保护?
在实际开发中。许多系统需要返工往往并不是因为系统功能没有完成，而是因为质量性能得不到满足，而这些质量属性又总是交织在一起的，在系统设计时没有方法使其中的一性能最大而不牺牲其他质性能，这就要求在着手设计系统时首先要考虑好如何满足系统的业务性能(如投放市场时间、成本、系统的生命周期和目标市场等)和质量性能，如何满足质蚤性能的动态属性(运行时可以测量的属性，如安全性、可用性、功能性和使用性等)和静态(运行时不能测量的属性，如可修改性、移植性、重用性、集成性和可测试性等)属性，并根据需求在这些性能之间权衡，这种权衡可通过分析系统软件体系结构来实现一个系统的软件体系结构是系统分析时优先考虑的诸多因素中最早着手的物件(Artifact)，它反映了系统应该包涵的全部属性，是对系统需要实现的诸多属性的平衡，比如系统运行效率与安全性、维护性与可靠性、目前开发成本与今后扩展成本之间的平衡，系统对这些质量属性的实现就是通过系统的结构平衡实现的，并且可能是设计者一开始不能用文字表述的。
流程管理的挑战
业务主管希望企业的流程能够与不断变化的业务环境保持同步，而IT主管希望对不断变化的业务需求迅速做出响应，以较低的成本进行改变
经营管理者希望对企业流程的执行进行通盘的监控和绩效分析，更好的协调业务，做出更迅速、有效的决策
业务系统越来越多也越来越复杂，完成一笔业务需要人工访问多个系统 企业应用系统中软件成分越来越复杂，系统规模不断扩大，使得软件体系结构越来越庞杂，系统的质量和性能己经不再仅仅取决于实现算法和数据结构，软件系统体系结构在一定程度上决定系统的优劣。软件体系结构提供了一种使软件开发活动可被管理、形式化、可组织的一种工具，通过它可以把软件开发过程中的一些物件转化成新的软件体系结构下的物件，例如，我们可以通过软件体系结构把软件的需求规格说明转化成系统设计、把设计转化成实现。
软件体系结构是指计算机软件(程序)系统的一个或多个系统结构，它们由组成系统的构件、构件的外在表现属性和构件之间的关系构成软件系统的体系结构有好坏之分，一个好的体系结构能够使软件系统满足特性要求、性能要求和生命周期的需求，而不好的体系结构则不能。因此，在系统开发工作启动时我们要通过实验、验证等评估方法，选择一个最好的体系结构来构造系统。
软件体系结构很多，文中将软件体系结构分为五类:以数据为中心的体系结构、数据流体系结构、虚拟机体系结构、调用和返回体系结构和独立构件体系结构，每一类体系结构都为我们提供了一种分析系统需求的基点和设计系统的方法，并且都是行之有效的、实用的.但都是立足于技术角度，从产品域分析体系结构所定义的构件，构件间相互作用的信息和构件的外在表现属性即该构件被其他构件操作时它所能提供的服务、性能统计、错误处理、共享数据的应用等等。系统的质t属性孺求源于系统的业务需求，如果我们从业务域出发考虑系统的体系结构，通过抽象企业应用需求中的业务建模，用业务功能构件实现业务处理中的具体工作来描述业务逻辑在软件体系结构中的静态属性，用参与者匹配和过程定义来建立业务流程、业务活动和组织机构间的关系，并用工作流虚拟机作为支撑，解释运行反映业务流程的过程模型实例，实现软件体系结构中的动态属性。通过对业务逻辑和系统实现的分离，系统软件体系结构中的静态属性和动态属性的逻辑，用业务逻辑的表现实体来描述企业应用系统的体系结构，企业应用中的业务逻辑描述实体可分为:业务流程、业务活动和参与者。通过对它们之间的信息文换机制独立封装，可降低业务逻辑、业务数据和业务操作实体三者间的藕合，实现在业务域中的业务流程的柔性管理(即业务过程管理)和不同业务活动的应用功能在业务流程的集成。
业务流程指在企业或机构中，能够实现业务目标和策略的相互连接的过程和活动集。业务流程可以用工作流来描述，将其表示成为能够完全或部分由计算机自动执行的业务过程，在此过程中，文档、信息或任务按照预定的规则传递，企业人员、已有软件互相之间协调工作，以实现企业业务的整体目标，通过流程建模定义业务处理过程中涉及到的各种数据，包括开始和中止条件、各个工作环节及相互之间的控制流和数据流关系等。
业务活动是业务流程最小工作单元，表示了业务的具体功能，对应工作流中一个逻辑步骤或环节的工作任务，一般分为手工操作和自动处理两类。通过对业务活动建模，可以分离活动的内容和活动的控制关系，这样活动的内容可以是一个用户界面，也可以是一个构件(如COST构件，编译后的执行程序，或一个子业务流程)。当业务内容改变时，只豁替换具体的功能构件，无需改变业务流程的过程定义;业务流程变化时只需改变活动的控制关系，而业务内容及其相关的数据库则不需改变。
组织机构 是对参与者的建模机制，它有三种荃本元素:组织单位、角色和参与者，这些荃本元素供过程建模使用，并通过建模机制保证已定义的过程中使用的角色和组织机构中定义元素的一致性。对组织建模带来两个好处:①分离业务的过程定义和业务的实际执行参与者，提供了过程模型和企业人员组织模型之间的相对独立性;②提供了一种平衡工作t的手段。当有多个执行者满足参与者孺要时，可在不改动流程定义的前提下，通过角色匹配在这些参与者之间平衡工作，提高工作效率，降低流程一次执行的周转时间。 SynchroFLOW就是采用面向业务域的系统体系结构的业务过程管理与集成系统，通过对业务流程建模、对组织机构分离，最大限度地满足系统的各项质量属性。
1 工作流虚拟机
工作流虚拟机是解释执行业务流程的工作流管理系统，是工作流过程实例创建、执行和监督管理的一个运行环境.它对外提供过程、活动、工作流的查询、控制、管理功能、日志管理功能、系统管理功能.对内它提供工作流解释执行的语义和语法规则，在SynchroFLOW 中提供基于信牌驱动模型的工作流语义和语法规则，它是遵循WfMC标准基于Petri一网理论提出的一种工作流模型，通过划分同步区与异步区，以及在同步区使用真假信牌规则。在异步区使用真信牌规则，具有丰富的语义和直观的描述能力，能够描述各种业务流程的控制逻辑。
2 业务流程建模
业务过程建模就是按照信牌驱动模型制定工作流解释执行语义和语法规则对业务流程的严格描述。只要完整地定义了业务流程的过程和一些相关的描述信息，工作流虚拟机按照这种流程定义自动或半自动地执行，而无需用户再另外开发软件。
SynchroFLOW的业务过程建模分为过程建模定义、过程建模管理和过程定义结果的标准格式等，过程建模完成业务流程的棋型定义，包括流程信息和相关数据;过程建模管理负责过程定义的管理职能，包括过程定义结果保存、获取和过程定义数据库的管理等。过程定义结果的格式将遵循XMLWPDL过程定义交换标准。
3 业务活动建模
一个工作流模型可以包含若干个过程;一个过程可以包含若干个基本元素;它们可分为两类:活动元素和转移元素.活动分为开始活动、手工活动、自动活动、内里活动、子活动、路由活动、活动组、意外活动和结束活动等九种特殊情况。业务活动建模，一方面把活动的内容(具体功能)设计成为一个个构件(如COST构件，编译后的执行程序，或一个子业务流程或一个用户界面)，由它们完成人机交互、数据处理和与数据库的连接等功能，并把它们按一定的方式存储起来，供业务过程定义时调用.另一方面，根据活动的类型和控制流信息，在业务过程定义时，定义参与者匹配方式，以便在活动执行时确定活动的执行者。
4 组织结构建模
业务流程定义中除了定义一系列活动以及活动之间的关系外，还要考虑手工执行的活动由谁来做和如何决定谁来做。在工作流系统中，一个活动的参与者(执行者)可能有三种情况:人员、单位和角色.这三种信息存放在一个企业的组织模型数据库中，供过程定义使用。
人员:指明某一活动的具体执行者，由该人员交互式地完成该活动的任务。
单位:一个活动的执行者并不指定给一个人，而是一个组织单位，它表明该单位中的任何一个人员都有能力和贵任执行该活动，当系统执行时再根据当时的情况动态地选择该单位中的一个合适的人员完成该活动。
角色:是对不同人员在业务流程中所承担责任的一种划分，不同的贵任可由不同的角色完成。
参与者就是活动的执行者，描述了一个活动可以由谁来执行，它是一个人、组织单位和角色的集合运算表达式，参与者是与过程相关的，而人、组织单位和角色是独立于过程定义的。参与者与活动之间的关系是执行与被执行的关系，参与者与人、组织单位和角色之间是扮演与被扮演的关系.只有满足参与者表达式的人、组织单位和角色才有权执行活动(只要在流程实例执行前，将参与者分配给某个活动就行了，即参与者匹配或参与者转换)。因此，参与者和执行者之间存在着多对多的关系，一个参与者可由一个或几个执行者来扮演，而一个执行者可以扮演多个参与者，这种多对多的关系给参与者匹配的实现带来一定的难度。但同时带来了灵活、简便、易于控制的好处。
利用SynchroFLOW实现业务流程管理
由于SynchroFLOW过程建模采用标准的XML-WPDL形式的过程定义，作为过程建模与工作流虚拟机之间交换过程定义的方式，从而使表现企业业务流程的过程定义程序与工作流虚拟机之间建立起了一种松散的韧合关系.当企业业务流程重组时，业务流程变化，只需要改变业务过程定义，用新的过程定义文件替换旧的即可，系统的功能构件、参与者以及数据库属性都不用修改。
在采用SynchroFLOW开发企业应用时，业务流程、活动或参与者发生变化时，可以利用SynchroFLOW提供的工具对系统的局部快速修改而不影响系统的体系结构整体，保证了系统质量属性.同时由于工作流虚拟机和反映业务流程的过程定义文件分离，还可以动态修改业务流程，即对流程定义模型的实例进行修改，当一个实例化的流程在运行过程中需要修改时，由工作流虚拟机挂起濡要修改的流程实例，利用SynchroFLOW提供的工具对流程、活动或参与者进行快速修改，并得到新的业务流程模型文件，交由工作流虚拟机实例化，恢复被挂起的业务流，由于其实例己被更新，它将按新的业务流程运行。
利用SynchroFLOW实现企业应用集成
SynchroFLOW降低业务逻辑、业务数据和业务操作实体三者间的藕合，在企业应用异构环境中可以实现功能构件级和流程级不同层次的集成。软件开发商开发的EJB、应用程序、FORM和与过程定义有关的附件通过系统管理进行注册和注销;用FORM开发工具开发的FORM通过应用程序管理提供的API进行注册;EJB通过EJB部署工具部署到EJB服务器上;EJB、应用程序、FORM和附件的索引信息保存到应用程序数据库中。利用SynchroFLOW的FORM开发工具开发的FORM或用第三方开发工具(如FrontPage)开发的FORM以及以JSP,HTML, EJB封装的组件，通过注册，成为一个业务活动功能构件。
在企业应用中有很多应用程序是二次开发商和用户自己开发的，有的是第三方开发的COST组件，这些应用程序是工作流虚拟机所不认识的.SynchroFLOW通过应用程序的注册和注销机制实现对它们的集成。应用程序的集成有两种方式，一种是将做好的应用程序作为活动一个功能构件，将应用程序索引信息登记在应用程序管理中，供过程定义时集成到活动中，当业务流程运行时它随活动一块执行;另一种是调用应用程序，由相应的API进行处理客户端注册应用程序的请求，还有响应调用应用程序的请求。

㈧ 几种常见的软件体系结构及特点分析

20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构和算法的选择上，然而随着软件系统规模越来越大，对总体的系统结构设计和规格说明变得异常重要。随着软件危机程度的加剧，软件体系结构(software architecture)这一概念应运而生。软件体系结构着眼于软件系统的全局组织形式，在较高层次上把握系统各部分之间的内在联系，将软件开发的焦点从成百上千的代码上转移到粒度较大的体系结构元素及其交互的设计上。与传统软件技术相比，软件体系结构理论的提出不仅有利于解决软件系统日益增加的规模和复杂度的问题，有利于构件的重用，也有利于软件生产率的提高。面向方面软件开发(AOSD)认为系统是由核心关注点(corn concern)和横切关注点(cross-cutting concern)有机地交织在一起而形成的。核心关注点是软件要实现的主要功能和目标，横切关注点是那些与核心关注点之间有横切作用的关注点，如系统日志、事务处理和权限验证等。AOSD通过分离系统的横切关注点和核心关注点，使得系统的设计和维护变得容易很多。
Extremara大学的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面向方面软件体系结构模型
由于传统软件体系结构模型包含构件、连接件和约束，而面向方面软件体系结构是在传统软件体系结构的基础之上扩展了方面构件，所以面向方面软件体系模型结构包含构件、连接件、方面构件和约束。其中约束描述了面向方面体系结构配置和拓扑的要求，确定了体系结构的构件、连接件和方面构件之间的连接关系，而构件、连接件、方面构件是它的三个基本的构成单元。以下对这三个构成单元的模型进行详细的设计。

㈨ 软件体系结构的研究范畴有哪些请举例加以说明！

软件体系结构的形式化方法研究
软件体系结构研究如果仅仅停留在非形式化的框图阶段，已经难以适应进一步发展的需要。为支持基于体系结构的开发，需要有形式化建模符号、体系结构说明的分析与开发工具。从软件体系结构研究的现状来看，在这一领域近来已经有不少进展，其中比较有代表性的是美国卡耐基梅隆大学（Carnegie Mellon University）的Robert J．A11en于l997年提出的Wright系统。Wright是-种结构描述语言，该语言基于一种形式化的、抽象的系统模型，为描述和分析软件体系结构和结构化方法提供了一种实用的工具。Wright主要侧重于描述系统的软件构件和连接的结构、配置和方法。它使用显式的、独立的连接模型来作为交互的方式，这使得该系统可以用逻辑谓词符号系统，而不依赖特定的系统实例来描述系统的抽象行为。该系统还可以通过一组静态检查来判断系统结构规格说明的一致性和完整性。从这些特性的分析来说，Wright系统的确适用于对大型系统的描述和分析。
软件体系结构的建模研究
研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。根据建模的侧重点的不同，可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。在这5个模型中，最常用的是结构模型和动态模型。
（1）结构模型
这是一个最直观、最普遍的建模方法。这种方法以体系结构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是体系结构描述语言。
管道/过滤器风格的体系结构
（2）框架模型
框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
（3）动态模型
动态模型是对结构或框架模型的补充，研究系统的"大颗粒"的行为性质。例如，描述系统的重新配置或演化。动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。这类系统常是激励型的。
（4）过程模型
过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。
（5）功能模型
该模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。它可以看作是一种特殊的框架模型。
这5种模型各有所长，也许将5种模型有机地统一在一起，形成一个完整的模型来刻画软件体系结构更合适。例如，Kruchten在1995年提出了一个"4+1"的视角模型。"4+1"模型从5个不同的视角包括逻辑视角、过程视角、物理视角、开发视角和场景视角来描述软件体系结构。每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件体系结构的全部内容。"4+1"模型如图1所示。
图1 "4+1"模型
发展基于体系结构的软件开发模型
软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架，给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为三种类型:
（1）以软件需求完全确定为前提的瀑布模型。
（2）在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型,如螺旋模型等。
（3）以形式化开发方法为基础的变换模型。
所有开发方法都是要解决需求与实现之间的差距。但是，这三种类型的软件开发模型都存在这样或那样的缺陷，不能很好地支持基于软件体系结构的开发过程。因此，研究人员在发展基于体系结构的软件开发模型方面做了一定的工作。例如，为了形象地表示体系结构的生命周期，北京邮电大学的周莹新博士建立了一个软件体系结构的生命周期模型，该模型如图2所示。
数据抽象和面向对象风格的体系结构
图2 软件体系结构的生命周期模型
软件产品线体系结构的研究
软件体系结构的开发是大型软件系统开发的关键环节。体系结构在软件生产线的开发中具有至关重要的作用，在这种开发生产中，基于同一个软件体系结构，可以创建具有不同功能的多个系统。在软件产品族之间共享体系结构和一组可重用的构件，可以增加软件工程和降低开发和维护成本。
一个产品线代表着一组具有公共的系统需求集的软件系统，它们都是根据基本的用户需求对标准的产品线构架进行定制，将可重用构件与系统独有的部分集成而得到的。采用软件生产线式模式进行软件生产，将产生巨型编程企业。但目前生产的软件产品族大部分是处于同一领域的。

㈩ 软件体系结构的体系风格

对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可以共享同一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构。例如，如果某人把系统描述为客户/服务器模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。
下面是Garlan和Shaw对通用体系结构风格的分类：
（1）数据流风格：批处理序列；管道/过滤器
（2）调用/返回风格：主程序/子程序；面向对象风格；层次结构
（3）独立构件风格：进程通讯；事件系统
（4）虚拟机风格：解释器；基于规则的系统
（5）仓库风格：数据库系统；超文本系统；黑板系统
限于篇幅，在本文中，我们将只介绍几种主要的和经典的体系结构风格和它们的优缺点。有关新出现的软件体系结构风格，将在后续文章中进行介绍。 C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：
（1）系统中的构件和连接件都有一个顶部和一个底部；
（2）构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；（3）一个连接件可以和任意数目的其它构件和连接件连接；
（4）当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
图3是C2风格的示意图。图中构件与连接件之间的连接体现了C2风格中构建系统的规则。
图3 C2风格的体系结构
C2风格是最常用的一种软件体系结构风格。从C2风格的组织规则和结构图中，我们可以得出，C2风格具有以下特点：
（1）系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起；
（2）所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的；
（3）构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。 在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。此风格特别重要的过滤器必须是独立的实体，它不能与其它的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。
图4是管道/过滤器风格的示意图。一个典型的管道/过滤器体系结构的例子是以Unix shell编写的程序。Unix既提供一种符号，以连接各组成部分(Unix的进程)，又提供某种进程运行时机制以实现管道。另一个着名的例子是传统的编译器。传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段（包括词法分析、语法分析、语义分析和代码生成）的输出是另一个阶段的输入。
图4 管道/过滤器风格的体系结构
管道/过滤器风格的软件体系结构具有许多很好的特点：
（1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；
（2）允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；
（3）支持软件重用。重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；
（4）系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；
（5）允许对一些如吞吐量、死锁等属性的分析；
（6）支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。
但是，这样的系统也存在着若干不利因素。
（1）通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
（2）不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重。
（3）因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。 抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。
图5是数据抽象和面向对象风格的示意图。图5 数据抽象和面向对象风格的体系结构
面向对象的系统有许多的优点，并早已为人所知：
（1）因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象。
（2）设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
但是，面向对象的系统也存在着某些问题：
（1）为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。
（2）必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。 基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。
从体系结构上说，这种风格的构件是一些模块，这些模块既可以是一些过程，又可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。
基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。
支持基于事件的隐式调用的应用系统很多。例如，在编程环境中用于集成各种工具，在数据库管理系统中确保数据的一致性约束，在用户界面系统中管理数据，以及在编辑器中支持语法检查。例如在某系统中，编辑器和变量监视器可以登记相应Debugger的断点事件。当Debugger在断点处停下时，它声明该事件，由系统自动调用处理程序，如编辑程序可以卷屏到断点，变量监视器刷新变量数值。而Debugger本身只声明事件，并不关心哪些过程会启动，也不关心这些过程做什么处理。
隐式调用系统的主要优点有：
（1）为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
（2）为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。
隐式调用系统的主要缺点有：
（1）构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被 调用的顺序。
（2）数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。
（3）既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。 层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。
这种风格支持基于可增加抽象层的设计。这样，允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。
图6是层次系统风格的示意图。层次系统最广泛的应用是分层通信协议。在这一应用领域中，每一层提供一个抽象的功能，作为上层通信的基础。较低的层次定义低层的交互，最低层通常只定义硬件物理连接。
图6 层次系统风格的体系结构
层次系统有许多可取的属性：
（1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；
（2）支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；
（3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。
但是，层次系统也有其不足之处：
（1）并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；
（2）很难找到一个合适的、正确的层次抽象方法。 在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化。
控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择，则仓库是一传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。
图7是黑板系统的组成。黑板系统的传统应用是信号处理领域，如语音和模式识别。另一应用是松耦合代理数据共享存取。
图7 黑板系统的组成
我们从图4中可以看出，黑板系统主要由三部分组成：
（1）知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。
（2）黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
（3）控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。