服装销售管理软件体系结构

设计篇
DDIO教学大纲指出“设计过程就是学生通过一个产品、过程或系统的设计而进行学习的一系列活动。这一过程要求通过设计来创造一个能进行具体测试的条件。在这种条件下，学生可以检验所设计的产品、过程或系统是否符合实际需要，明确可能改进的方向”。本篇在构思阶段成果的基础上，将关注点放在“如何实现”上。因此这一阶段的核心问题从对问题空间的建模转移到解空间的建模。该过程不仅要说明为实现构思阶段所产生的需求模型必须引入哪些计算模块以及模块之间的关系，还必须从提高软件设计质量和效率方面考虑如何改进软件结构。

服装销售管理软件体系结构
体系结构一词来源于建筑行业，当谈论某些建筑物的体系结构时，首先考察的是建筑物整体的外观形状及其结构特点。实际上，体系结构涵盖的内容远远多于建筑物的外观形状和结构特点，它是使各种建筑构件集成为一个有机整体的方式，即将砖石、管道、电气线路和门窗等结合在一起创建外部门面和内部居住环境的方式，也是与其所处的环境相协调的方式。
通常将软件系统比作一座建筑。从整体上讲，软件系统也有基础、主体和装饰，即建立在操作系统之上的基础设施软件，实现业务逻辑的应用程序，以及方便用户使用的图形用户界面。由于软件系统可以被认为是由许多相互作用的模块按照一定的规律组织起来的具有整体属性的智力产品，因此，软件系统也具有体系结构。随着服装销售管理软件规模、复杂程度以及应用环境的不断演变，对软件系统体系结构选择、设计和规格说明往往比对算法和数据结构的选择重要得多。本章将围绕软件体系结构相关的概念、方法和原理展开讨论。

1．1概述
软件体系结构定义了软件的布局和总体计算单元的构成，以及这些计算单元之间的相互关系。计算单元有时也称之为构件或部件(Component)。典型的构件包含了服务器程序、客户端程序、程序包、过程、子程序、数据库等一切组成软件的单元。构件间关系除了包括过程调用、共享变量访问、消息传递等常规形式外，同时还包含了十分复杂的语义和协议，如客户／服务器的访问协议、数据库的访问协议、网络的传输协议和异步事件的映射等。
体系结构除了描述系统的构成和结构关系外，还可以描述系统需求和构成之间的对应关系，这为系统的设计提供了分析和评价的依据。同时，人们还关心系统的非功能性需求方面的内容，如容量、数据吞吐量、一致性、兼容性、安全性和可靠性等，这些概念也可以使用体系结构进行表达。
一般地说，体系结构清楚地刻画了构成计算机系统的计算单元以及它们之间的作用关系和语义。在理想的情况下，体系结构描述的各个构件及其关系都是被独立定义的，因此可以在不同的场合中得到重用。体系结构将为它们建立结构和功能规范，经过进一步完善，可以将它们组成更大、更复杂的构件或可运行的软件系统。由于系统每一层次和每一部分的组成结构是明确、规范的，因此为整个系统的功能和非功能特性的分析提供全体系的和具体的根据。
总体看来，软件体系结构是由结构和功能各异、相互作用的构件集合，按照一定关系构成的。它包含了软件系统基础构成单元、相互的连接关系、合成方法以及对合成约束的描述。

1．2软件体系结构的类别及重要性
依据层次和细节程度的不同，服装销售管理软件体系结构大致可以分为概要型、需求型和设计型。概要型是对软件系统宏观结构的描述，反映系统最上层的构件和连接关系。需求型是对概略体系结构的深入表述，以刻画用户功能和非功能性需求为目的，通常需要对概略层的构件和连接进行深层的描述。设计型体系结构是从设计角度对需求结构的再次细致地描述。在此类型的体系结构中，需要从不同的视角，采用各种表达图示和说明，设计系统各个层面的构件和连接结构。该层次的体系结构将直接服务于系统的实现和性能分析。
软件体系结构的重要性在于它决定了一个系统的主体结构、宏观特性和具有的基本功能以及特性。正如大型建筑物设计成功的关键在于主体结构，复杂软件设计的成功在于软件系统在宏观层次上结构设计的正确性和合理性。因此，软件体系结构是整个软件设计成功的基础和关键之所在，其作用可以延伸到软件设计开发的各个阶段。
(1)在项目规划阶段,概略的体系结构是进行项目可行性分析、工程复杂性分析、工程进展、投资规模分析和风险预测等活动的重要依据。
(2)在需求分析阶段，通过对概要体系结构进行更加深入和细致分析从而建立更深入的体系结构描述及需求体系结构。该体系结构是开发商和客户之间进行需求交互的基础，也是交互所产生的结果。通过它可以准确地表达用户的需求，以及设计对应需求的解决方法，并考察最终系统的各项性能。
(3)在设计阶段，需要从实现的角度，从多个维度对软件系统结构再次进行深入的分解和描述，并产生设计型软件体系结构。该体系结构能够反映用户需求与实现之间的映射关系。
(4)在实施阶段，可以根据体系结构的层次和构件粒度的大小建立项目开发人员的组织、分工和进度表，协调开发人员关系。
(5)在项目评估阶段，体系结构是性能测试和评价的依据。
(6)在项目维护阶段，对软件任何扩展和修改都需要在体系结构的指导下进行。以维持整个设计的合理性和正确性，并为维护升级的正确性和开销分析提供依据。

1．3软件体系结构的构成
构件和连接件被公认为软件体系结构的两大基石。构件是软件系统的组成单元，是软件功能设计和实现的负责构件间连接的载体，在系统架构中起结构块的作用。连接件是构件和构件之间连接的成分。为了建立部件之间的连接关系，还需要得到连接协议的支持。连接件是专门承担连接作用的特殊部件。

1．3．1构件
从设计的角度来看，构件可以看作模块、类、对象或者一个相关功能的计算实体的集合。根据在系统中的作用，构件可以如下分类：负责系统运行管理的控制构件、负责构件间协作关系的协调构件、负责构件间连接和转换的连接构件、为其他构件提供特定服务的服务提供构件、负责安全检查和信息转接传递的信息控制构件、完成对象生产和撤销的构造构件等。
在分析系统的整体结构和特性时，构件是作为封装的实体，将其内在结构隐藏起来。一个构件至少有一个接口，每一个接口代表着对外联系的一种角色，这是构件与外界发生关联的唯一途径。
实现构件的最简单形式的是具有属性和服务的对象，通过对对象按照不同的组织原则可以形成更大规模的构件，从而形成行为更复杂、结构更多样化的构件。例如，用于界面设计的可视化构件、实现特殊输入的输入构件、实现多媒体处理的OLE对象、实现分布式计算的DCOM／CORBA构件等都是系统的组成部分，都可以通过对对象的集成实现。
所以，构件的基本实现形式就是对象。在不同的设计环境中，服务于不同的目的和运行环境，又可以表现为控件、组件、库、表、实体、包、设计模式、框架等。
(1)根据构成的概念层次不同，构件分为：基础构件、中层构件、高层构件。
(2)根据构件的应用可以分为：通用构件和专用构件。
(3)根据构件的功能可分为：数据服务构件、功能服务构件、逻辑／处理构件、界面构件、控制构件、连接构件、体系结构构件等。
(4)根据构件运行的特性，可分为调度和非调度构件、中断和非中断构件、多客户服务构件等。
构件的特性包括以下几个方面：接口特性、运行特性、远程服务特性、关联特性、动态特性。
(1)构件的接口特性。包括其设计的完备性、最小化、正交性，方便性、效率。
完备性：从构件使用的角度出发，完备性可以定义为使用者可以用它来完成构件应该能够完成的一切工作。希望可以使用构件提供的接口和操作界面，通过简单的组合，完成用户需要和构件应该能完成的工作。
最小化：构件的接口或界面中任一操作，都不能由其他操作组合而实现。具有最小特征的构件具有最小的界面，最容易设计实现，也最容易分析使用和维护。使用最小化的操作可以组合生产复杂的操作。
正交性：设法使两个不同的操作交叉重复部分达到最小。这样，操作的特性就更容易理解和实现。
方便性：该要求是与其他要求相抵触的。该要求提出，构件的设计应该提供用户欢迎的操作，而不去管这个操作可能破坏最小化和正交性要求。多接口的设计就往往是从方便性考虑的。
效率：接口操作的执行效率。对效率的要求也可能导致增加某些操作，而破坏了操作界面的最小化和正交性。
(2)构件的运行特性。在实时、并行、多任务／多用户访问的情况下，该特性十分重要，因为它关系到系统的整体功能实现和运行效果。该特性可以从构件的中断处理、并行调度、多用户服务三个方面加以说明。
对于实时系统，要求构件能够根据定时或偶然事件的触发，完成特定的处理，包括数据的采集、分配、传输、计算等。在实时性要求不高的场合，操作系统的消息机制可以达到满意的效果。但当实时响应速度提高时，必须通过系统中断服务的设置才能达到要求。
经常要求构件具有被并行调度的能力，即要求多个功能构件能同时运行。为此，构件的设计必须考虑进程的产生、撤销、通信和调度管理。
在要求诸如数据服务、操作服务、分布式计算的系统中，由于服务请求的分布和多源性，要求这些构件具有同时处理多用户服务请求的能力。为了实现多用户服务，要求构件具有事件触发和多线程运行的能力。这样，每个线程负责响应一个请求，还需要为触发事件建立监听和响应线程，实现多任务的并发处理。
(3)服务构件的远程服务特性。该特性包含了数据和功能服务。在分布式计算环境当中，大多数的数据和功能服务都通过网络进行连接。无论获取或者提供服务都需要进行远程访问，故该特性在网络环境中是必须的。
(4)构件的关联特性。这是构件与相关联构件所建立的联系和联系的方式。一般情况下，构件都需要在完成自身计算的同时，向其他构件请求信息或服务，或为其他构件提供服务。为此，构件需要掌握与之发生关联的构件的地址，或设法获取这些地址的信息，并保存和维护它们。如果要求构件能够动态地处理这些联系，则构件的设计和实现就复杂化了。
(5)构件的动态特性。该特性包含两类动态特性：构件运行调度的动态性和构件的生存周期管理的动态性。运行调度涉及运行环境资源的分配和多任务的并行执行，还包括运行的效率，这在运行特性中应经处理了。生存周期管理指构件运行实例的产生和撤销，也包括由构件负责的其他类型构件的产生和撤销，以及它们的运行。简单地处理各类构件的产生和撤销并不复杂，复杂的是正确地维持各构件之间的依赖关系，并有效地利用系统资源。

1．3．2连接件
连接是构件与构件之间建立和维持行为关联和信息传递的路径。实现连接需要有两方面的支持：一是连接的已发生和维持的机制，二是连接能够正确、无二义、无冲突地得到保证。前者是连接实现的物质基础，后者是连接正确有效进行的信息交换规则，称为连接的协议。 因此，连接的本质是连接的两个方面：实现机制和信息交换协议，简称机制和协议。从连接的目的来看，连接可以分为操作／过程调用、控制／事件／消息发送、数据传输三大类。
除了连接的物理实现的难易程度外，影响连接实现复杂性另外一个因素是无连接的返回信息和返回时间。表现在连接的实现机制上，可将其分为同步和异步两大类。
从连接的双方看，如果～个连接的请求在得到响应并完成处理之前，请求方一直在等待，直到收到被请求方的处理结果后才退出连接状态，这样的连接就是同步的。如果请求者不需要立即等待处理的结果，就可以采取异步连接方式。这使得请求者在发送请求后，可以自由地处理其他事务。但在需要得到处理结果的情况下，这使得对返回结果的处理变得复杂化。因为同一个请求者可能发送多个请求，必须建立一种对应机制，使请求和对请求的处理结果严格遵循一对一的关系。
协议是连接的规约，是实现有意义连接的保证。如同软件的结构层次一样，协议通常也是按照层次构成的。例如，网络的7层协议结构。物理层是在硬件的机制上建立的最底层的连接规约，逻辑层是在物理层规约上建立的信息编码和连接控制规约，应用层是在逻辑层规约上建立的应用问题表达和操作的规约。
连接的特性反映了其对连接关系的处理性质，体现了对连接器设计的宏观性能要求。它包括连接关系、角色和方向、交互方式、可扩展性、互操作性、动态连接性、请求响应时间、请求的处理策略、连接代价、连接处理能力和概念等级。
(1)连接的关系分为1：1、1：n、n：1、m：11．，分别指1对1、1对多、多对1、多对多的连接关系。
(2)连接的角色和方向。连接的角色是对连接的双方所处地位的不同的表达。在调用过程中，角色有调用方和被调用方。在客户端朋醍务器连接中，角色有客户方和服务器方。在中断连接中，角色有中断源和中断响应等。角色和地位的不同在连接的实施中表现为所进行的操作不同、期望所获得的信息不同。例如，在电子邮件的发送过程中，发送方首先需要查询接收服务器的存在和运行正常，只有在得到被查询方的正确的响应后，才启动发送程序，也只有等待接收方确认完成接收后才确认发送成功。连接的方向是指任何一端口是否可进行双向或仅可单向请求传递。
(3)连接的交互方式。连接的交互方式是指请求信息传递的方式，包括信号式和语言式。对于信号式，请求和响应之间按约定的信号实施处理。对于语言式，则需要建立较复杂的语言的解释、翻译和转换机制，以完成信息的处理。
(4)可扩展性。可扩展性指操作接口、功能和连接关系的动态可扩展性。所谓“动态”是相对于设计实现时的“静态”而言的。连接关系的扩展允许动态地改变被关联的构件集合和关联性质。
(5)连接的互操作性。连接的互操作性指连接的构件双方通过连接器所建立的关系．直接或间接操作对方信息的能力。
(6)连接的动态连接性。连接的动态连接性，指接口所提供的操作允许根据请求者或接收者或传送数据对象的不同，实施动态地确定处理方法的性能。也就是连接行为的动态约束特性。
(7)连接请求响应特性。连接请求响应特性，包括响应的顺序性、同时性、并发性。简单情况下，请求是根据发生的顺序逐一地被处理的。在并发环境下，连接器无法知道请求发生的时间，请求的到来可能是近乎同时的，而对每个请求的处理所需时间和资源上又会有很大差别。为此，在不破坏处理逻辑的前提下，需要对多个请求具有并行处理的能力。在某些情况下，具体的处理次序是希望可以选择的。
(8)连接请求的处理策略。连接请求的处理策略，指对请求处理的条件转移，包括对请求的传递、扩展和撤销。传递是当被连接器关联的某个构件无能力完成处理时把请求传递给其他构件。扩展是根据请求的特性将其分解成多个新的请求并发送给其他构件处理。撤销是根据请求的特性有条件地抑制相应处理。例如，设计模式(DesignPattern)中的责任链，可视界面对象对消息的处理等，都存在对请求或事件的传递、扩展和撤销处理。
(9)连接的代价，处理速度或能力。连接的代价，如同一切软件系统一样，需要考察其对资源和时间消耗情况，以反映处理计算的复杂性。包括建立连接的代价、处理请求的代价。连接处理速度或能力，是反映连接代价的另一方面，以处理请求的单位时间个数或处理信息的单位时间数量来衡量。
(10)连接器的概念等级或层次。连接器的概念等级或层次是根据建立连接所处理问题的概念层次确定的。

1．4软件体系结构的描述语言
研究软件体系结构的另外一个重要问题是如何描述软件体系结构，目前已有很多表现形式和方法，如图表法、模块连接语言、构件描述法和体系结构描述语言(ArchitectureDescriptionLanguage，ADL)等。其中体系结构描述语言吸收了传统程序设计中语义严格、精确的特点，并针对软件体系结构的整体性和抽象性，定义了适合于软件体系结构表达与描述的有关抽象元素．从而能精确、无歧义地描述软件体系结构，更好地支持对软件体系结构求精、验证、演化和分析。
为了精确描述软件体系结构，体系结构描述语言首先应有一个形式化理论基础，如Petri网、状态图、Z、CSP等。有了形式化理论基础，才能对所描述的系统进行分析和验证。
体系结构描述语言还应具有严谨的语法和语义。描述能力应足够强，能描述的基本构件如构件、连接件及有关配置规范。同时，为了更好地应用，体系结构描述语言应有相应的支持工具。支持工具的能力直接反映了该体系结构描述语言的可使用程度和范围。
描述软件体系结构的一个很重要的目的是为了便于软件开发者的理解和交流，因此，体系结构描述语言描述应简单易懂，最好有图表辅助理解。对于同一个体系结构，不同的软件开发者需要从不同的抽象层次上理解，这就要求体系结构描述语言能描述不同抽象程度的软件体系结构。
分析作为软件体系结构求精、验证的基础，是一般体系结构描述语言不可缺少的一种功能。分析有静态分析和动态分析，如Wright基于CSP能对单个组件或连接件进行静态死锁分析。
Rapide基于偏序事件集合可进行动态分析。

根据各体系结构描述语言的研究范围，可将它们归为如下三类：
(1)研究软件体系结构配置结构的描述语言。这一类体系结构描述语言主要针对体系结构的静态和动态配置，对体系结构配置的演化所具有的性质进行研究，如Darwin和CHAM。Darwin采用兀演算对系统行为进行建模，利用其强类型系统进行静态检查。CHAM通过对各单元的描述和引入的转换规则来描述和分析体系结构的动态行为。
(2)研究软件体系结构实例的描述语言。这一类体系结构描述语言是针对特定系统的，回答“系统的体系结构是什么”。Rapide是这类语言的一个例子，它是一种基于事件的、并发的面向对象的语言，专门为系统体系结构建立快速原型而设计，由5个子语言组成，通过这些子语言的结合使用，使得系统在确定实现策略之前能在体系结构的层次上进行分析和设计。
(3)研究软件体系结构风格的描述语言。这一类体系结构描述语言描述系统使用了哪类体系结构风格及该体系结构风格的含义。由于体系结构风格的重要性，这一类描述语言研究的比较多，典型的有Wright等。另外，根据与实现细节的关系，又可分为实现无关语言(impiementa—tionindependentlanguages)和实现相关语言(implementationconstraininglanguages)。前者如Wright、Rapide，后者如Unicon和MetaH等。
当前，已经开发和使用的常见体系结构描述语言有Wright、Unicon、C2、Aesop、Rapide、Dar—win、SADL等。由于这些语言大多是有关的设计研究者，在某种特殊应用的研究开发中而设计和发展出来的结果，因此，它们有各自不同的侧重点和特色。如Aesop支持软件体系结构风格的应用；Adage支持对电子导航系统体系结构框架的描述，MetaH为实时电子控制软件的设计者提供明确的指导；Unicon支持异构构件和连接，并针对体系结构有一高层编译器；Rapide是专门为系统体系结构建立快速原型设计的，是一种基于事件的、并发的、面向对象的语言，允许模拟软件体系结构设计，并提供工具分析模拟结果；Wright支持定义和分析构件间的相互作用，其最重要的是连接件；SADL提供了关于体系结构加细的形式化基础。如此众多的体系结构描述语言及它们的支持工具，其描述方法和形式各不相同，强调了软件体系结构的不同侧面，对软件体系结构研究起到了重要作用，但也有负面的影响。
(1)每一种体系结构描述语言都以独立的形式存在，描述语法不同且互不兼容，使得设计人员很难选择。
(2)大部分体系结构描述语言是领域相关的。不利于对不同领域的体系结构进行分析。
(3)一些体系结构描述语言在某些方面大同小异，有很多冗余的部分。

1．5体系结构模式和风格
1．5．1模式
软件设计模式是从软件设计过程中总结出来的，是针对特定问题的解决方案。好的模式能针对特定问题，采用成熟和成功的方法进行问题求解，该方法比重新设计要好得多。体系结构模式的经典定义是：每个模式都描述了一个在环境中不断出现的问题及该问题解决方案的核心。
在软件系统中，可以将模式划分为以下3类：
(1)体系结构模式(ArchitecturalPattern)。体系结构模式表达了软件系统的基本结构组织形式或者结构方案，包含了一组预定义的子系统，规定了这些子系统的责任，同时还提供了用于组织和管理这些子系统的规则和向导。典型的体系结构模式有国际化标准组织于1978年提出的计算机网络结构模型一一开放式系统互连参考模型，即OSI参考模型。
(2)设计模式(DesignPattern)。设计模式为软件系统的子系统、构件或者构件之间的关系提供一个精练之后的解决方案，描述了在特定环境下,用于解决通用软件设计问题的构件以及这些构件相互通信时的各种结构。有代表性的设计模式包含了抽象工厂模式、适配器模式等。
(3)惯用法(Idiom)。惯用法是与编程语言相关的低级模式，描述如何实现构件的某些功能，或者利用编程语言的特性来实现构件内部要素之间的通信功能。

1．5．2风格
风格是带有一种倾向性的模式。同一个问题可以有不同的解决问题的方案或模式，但根据经验。通常会强烈倾向于采用特定的模式，这就是风格。
建筑师通常使用体系结构风格作为描述手段，将一种风格的建筑与其他风格的建筑区分开
来。当使用某种体系结构风格来描述建筑时，熟悉这种风格的人就能够对建筑的整体结构有所了解。
为计算机系统建造的软件也展示了众多体系结构风格中的一种。每种风格描述一种系统范畴。该范畴包括：
(1)构件(比如数据库、计算模块)完成系统需要的某种功能。
(2)连接，它们能使构件间实现通信、合作和协调。
(3)约束，定义构件如何集成为一个系统。
(4)语义模型，它能使设计者通过分析系统构成成分的性质来理解系统的整体性质。
体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
对体系结构风格的研究和实践为大粒度的软件复用提供了可能。体系结构的不变部分使不同的系统可以共享相同的实现代码。只要系统是使用常用的、规范的方法来组织，就可以使用其他设计者很容易地理解的体系结构。例如，如果某人将系统描述为客户机／服务器风格，则不必给出设计细节，立刻就会明白系统是如何组织和工作的。
典型的体系结构风格有数据流风格、调用～返回风格和仓库风格等。

1．5．3抽象工厂模式
1．目的
抽象工厂(AbstractFactory)模式提供一个接口用以创建一个相联系或相依赖的对象族，而无须指定它们的具体实现类。
2．结构
例如，每一个中国企业几乎都需要一个工资计算系统，该系统的计算模式均可以表示成为：
员工工资一(基本工资+奖金一个人所得税)。中国企业奖金和个人所得税的计算规则是：
奖金=基本工资×lo％，个人所得税一(基本工资+奖金)×40％。
根据上面的分析，企业工资计算系统体系结构如图6一l所示。
针对美国市场，美国企业的工资计算同样是：员工的工资一基本工资+奖金一个人所得税。但是他们的奖金和个人所得税的计算规则不同于中国企业。美国企业奖金和个人所得税的计算规则是：奖金一基本工资×15％，个人所得税一(基本工资×5％+奖金×25％)。根据前面为中国企业建模经验，可以得到美国企业员工工资计算系统的体系结构如图6—2所示。
假如要将两个系统进行整合，同时为了在不修改客户端计算工资代码的前提下，同时保留所有业务规则模型，即保留中国和美国企业工资运算规则，可以采用抽象工厂模式，具体实现如图6-3所示。
3．参与者职责
(1)抽象工厂类(如图6—3中的个人所得税、奖金)：声明创建抽象产品对象的操作接口。
(2)具体工厂类(如图6—3中的中国个人所得税、美国个人所得税、中国奖金、美国奖金)：实现抽象工厂类定义的接口，负责执行具体的业务逻辑。
(3)客户：仅使用由抽象工厂类声明的接口。
4．协作
在执行时，抽象工厂类将产品交给具体工厂类创建。具体工厂类的实例只有一个，专门针对某种特定的实现标准，建立可用的产品对象。如果想要建立其他标准的产品对象，客户程序就得改用另一种具体工厂类。

1．5．4适配器模式
1．目的
适配器(Adapter)模式可将一个类的接口转换为客户期望的另一种接口，使得原本因接口不匹配而无法合作的类可以一起工作。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。在遗留代码复用、类库迁移等方面适配器模式非常有用。
2．结构
适配器模式有类适配器模式和对象适配器模式。适配器可以通过多继承方式实现不同接口之间的相容和转换，如图6—4所示。而一个对象适配器则依赖对象组合的技术实现接口的相容和转换，如图6—5所示。从图中可以看出，Adaptee类具有SpecificRequest()方法，但由于接口不匹配的问题，导致了Client类无法直接访问Adaptee类。为使客户端能够使用Adaptee类，需要提供一个中间环节，即Adapter类，将Adaptee的SpecificRequest服务与Target类的Request服务衔接起来，利用继承方式实现适配器模式。
3．参与者职责
Target：定义Client类使用的与特定领域相关的接口。

1．5．5数据流风格
当输入数据经过一系列的计算和操作构件的变换形成输出数据时，可以应用这种体系结构。传统的管道／过滤器、批处理序列都属于数据流风格。管道和过滤器结构如图6-6所示，拥有一组被称为过滤器(Filter)的构件，这些构件通过管道(Pipe)连接。管道将数据从一个构件传送到下一个构件。每个过滤器独立于其上游和下游的构件而工作。过滤器的设计要针对某种形式的数据输入，并且产生某种特定形式的数据输出。然而，过滤器没有必要了解与之相邻的过滤器的工作。
如果数据流退化成为单线程的变换，则称为批处理序列(BatchSequential)，这种结构接收一批数据，然后应用一系列连续的构件(过滤器)变换它。
管道／过滤器风格具有以下优点：
(1)使得软件构件具有良好的隐蔽性和高内聚、低耦合的特点。
(2)允许设计者将整个系统的输入／输出行为看成是多个过滤器行为的简单合成。
(3)支持软件复用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来。
(4)系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中；旧的可以被改进的过滤器替换掉。
(5)允许对一些属性如吞吐量、死锁等进行分析。
(6)支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行。
其主要缺点如下：
(1)通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
(2)因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

1．5．6调用一返回风格
该体系结构风格便于设计出易于修改和扩展的程序结构。在此类体系结构中，存在3种子风格。
1．主程序／子程序体系结构
这种传统的程序结构将功能分解为一个控制层次，其中“主”程序调用一组程序构件，这些程序构件又去调用别的程序构件。该系统结构如图6—7所示。这种结构总体上为树状结构，可以在底层存在公共模块。
当主程序／子程序体系结构的构件分布在网络上的多个计算机上时．称主程序对子程序的调用为远程过程调用。这种系统的目标是要通过将运算分布到多台计算机上来充分利用多台处理器，最终达到提高系统性能的目的。
主程序／子程序体系结构的优点是：
(1)可以使用自顶向下、逐步求精的方法得到体系结构图，典型的拓扑结构为树状结构。
(2)采用程序设计语言支持的单线程控制。
其主要缺点是：
(1)子程序的正确性难于判断。需要运用层次推理来判断子程序的正确性，因为子程序的正确性取决于它调用的子程序的正确性。
(2)子系统的结构不清晰。通常可以将多个子程序合成为模块。
2．面向对象风格
系统的构件封装了数据和必须应用到该数据上的服务，构件间通过消息传递进行通信与合作。与主程序／子程序的体系结构相比，面向对象风格中的对象交互会更加复杂一些。面向对象风格与网络应用的需求在分布性、自治性、协作性、演化性等方面具有内在的一致性。
面向对象风格具有以下优点：
(1)因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示而不影响其他的对象。
(2)设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
其缺点如下：
(1)为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。
(2)必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。
参见的具有面向对象风格的软件体系结构有两类：对象管理体系结构oMA和公共对象请求代理体系结构CORBA。OMA是0MG(0bjectManagementGroup)在1990年提出来的，它定义了分布式软件系统参考模型。OMA包括对象模型和参考模型两部分。OMA对象模型定义了如何描述异质环境中的分布式对象。OMA参考模型描述了对象之间的交互。CORBA是0MG所提出的一个标准，它以对象管理体系结构为基础实现了基于Internet环境的分布式对象协同工作环境。
3．层次结构
软件系统被组织成一个层次结构，下层为上层提供服务，并作为再下一层的客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。从外层到内层．每层的操作逐渐接近机器的指令集。在最外层，构件完成界面层的操作；在最内层，构件完成与操作系统的连接；中间层提供各种实用程序和应用软件功能。这种风格支持基于抽象程度递增的设计。允许将复杂问题分解成一系列增量步骤实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口。允许每层用不同的方法实现，同样为软件复用提供了强大的支持。
层次结构具有以下优点：
(1)支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解。
(2)支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的内外层。
(3)支持复用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，从而允许各种不同的实现方法。
层次结构的缺点如下：
(1)并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师也不得不把一些低级或高级的功能综合起来。
(2)很难找到一个合适的、正确的层次抽象方法。

1．5．7仓库风格
数据库系统、超文本系统和黑板系统都属于仓库风格。在这种风格中，数据仓库(如文件或数据库)位于这种体系结构的中心，其他构件会经常访问数据仓库，并对仓库中的数据进行增加、修改或删除操作。典型的仓库风格的体系结构如图6—8所示。
其中客户端软件访问数据仓库。在某些情况下仓库是被动的，也就是说，客户软件独立于数据的任何变化或其他客户软件的动作而对数据进行访问。这种方式相当于传统型数据库系统。该方式的一个变种是将中心存储库变换成“黑板”。黑板构件负责协调信息在客户问的传递，当用户对感兴趣的数据发生变化时，它将通知客户软件。
黑板系统的传统应用是信号处理领域，如语音和模式识别。另一应用是松耦合代理数据共享存取。如图6-9所示，黑板系统由知识源、黑板数据结构和控制3部分组成。
图6-8仓库风格圈6-9黑板系统
(1)知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进通信，它们之间的交互只通过黑板来完成。
(2)黑板数据结构。黑板数据是按照与应用程序相关的层次组织的数据。知识源通过不断地改变黑板数据来解决问题。
(3)控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。
黑板系统具有以下优点：
(1)对可更改性和可维护性的支持。由于控制算法和中心存储严格分离，所以黑板系统支持可更改性和可维护性。
(2)可复用的知识源。知识源是某类任务的独立专家。黑板体系结构有助于使它们之间的复用。复用的先决条件是知识源具有相同的协议和数据或者在这方面相当接近而不排斥协议或数据具有自适应程序。
(3)支持容错性和健壮性。在黑板体系结构中，所有的结果都只是假设，只有那些被数据和其他假设强烈支持的才能生存，从而提供了对噪声数据和不确定结论的容忍。
黑板系统具有以下不足：
(1)测试困难。由于黑板系统的计算没有依据确定的算法，所以其结果常常不可再现。此外，错误假设也是求解过程的组成部分。
(2)不能保证有好的求解方案。黑板系统往往只能正确解决所给任务的某一百分比。
(3)难以建立好的控制策略。控制策略不能以一种直接方式设计，而需要一种实验的方法。
(4)低效。黑板系统在拒绝错误假设中要承受多余的计算开销。
(5)缺少对并行机制的支持。黑板体系结构不可避免地采用了并行机制的控制策略。对黑板上中心数据的并发访问也必须是同步的。

1．6体系结构设计原理
软件体系结构是建立在几条基本原理之上的。这些基本原理包括：抽象、封装、数据隐藏、模块化、注意点分离、耦合和内聚、接口与实现的分离、引用的单一性、分而治之、层次化。
1．抽象
抽象是人们用来处理复杂问题的基本原理之一。抽象有几种形式：数据抽象、对象抽象、实体抽象、行为抽象、过程抽象、虚拟机抽象等。数据、实体的抽象活动要求软件操作的对象和参数是针对逻辑结构，而非存储结构的。行为、过程的抽象活动要求操作的指派是基于标识而非地址，由此产生了操作的接口和动态约束描述。在处理系统的复杂性方面，抽象起到了重要的作用。例如减少构件耦合、接口与现实的分离都得益于抽象的运用。
2．封装
封装是将构成抽象的属性和服务结合在一起，并区分不同抽象的方法。封装为不同抽象之间提供了明确的界限。封装有利于非功能特性实现，例如可重用性。可通过对象、模块设计和访问接口设计分别实现封装。
3．信息隐藏
信息隐藏是软件工程的最基本也是最重要的原则之一。信息隐藏对用户隐藏了功能的实现细节，更好地处理系统的复杂性和减少各构件之间的耦合度。为了更好地应用，用户不需要知道的细节都应该由构件隐藏起来。封装原理经常被用来作为实现信息隐藏的方法。信息隐藏也可以通过接口与实现分离的原理来实现。然而，构件应该隐藏什么取决于具体的应用。在一个应用中不需要知道的方面或许在另一个应用就需要看到。
4．模块化
模块化主要关心如何将系统划分为子系统或者构件，其主要任务就是决定怎样将构成应用的逻辑结构物理地分割成代码实体。模块化的主要做法是在一个系统内引入良好定义的分界，依此来处理系统的复杂性。模块的作用是作为一个应用的功能和责任的物理容器。由此带来了复杂系统资源管理、维护和应用的逻辑和条理性，增加了应用设计的灵活性。另外它对于系统的运行设计和管理调度也提供了方便，例如，对于动态链接库的选择应用、程序运行体的覆盖和交换都是有益的。
5．注意点分离
不同和无关联的责任应该在软件系统中分离开来，让他们出现在不同的构件中。相互协作完成一个特定任务的构件应该和其他任务中执行计算的构件分离开来。如果～个构件在不同的环境下扮演不同的角色，在构件中这些角色应该独立且相互分离。例如在多层次体系结构的组件设计中，在多种应用场景中担任不同角色的同一个组件，需要和可以使用不同的接口定义。这样，对于某一个角色开放的只是与角色相关的信息和服务，避免了过多暴露所造成对应用设计的负担和混乱，又保证了组件运行的可靠和安全。
6．耦舍和内聚
耦合和内聚最初是作为结构化设计方法的部分原理而提出。耦合强调模块之间的特征，而内聚强调模块内部的特征。耦合是用来衡量一个模块同另一个模块的联系的紧密程度。紧密的耦合会使系统变得复杂，因为如果一个模块和另一个模块有非常密切的联系，该模块就会变得非常难以理解、调试和维护。通过弱耦合构件的设计可以降低系统的复杂性。内聚度是用来衡量一个模块内部功能和元素之间联系性的程度。在体系结构设计中倡导模块内部的高内聚度。内聚有几种形式，最期望得到的是功能内聚，它说明一个模块或是构件内的所有元素都协同来提供具有良好边界的行为。最差的形式是偶然内聚，这种形式将毫无联系的抽象放置到同一个模块之中。其他形式的内聚还有：逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚和不规则内聚。
7．接口和实现的分离
任何一个构件应该包含两个部分，接口和实现。接口部分定义了构件能够提供的功能，并规范了功能的使用方法，接口对构件的客户是可访问的。输出接口的类型是由函数原型构成的。
实现部分包括了实现构件所提供功能的实现代码。实现部分对客户来说是不可用的。
该原理的主要目的是防止构件的客户接触到实现的细节，而只为客户提供构件的接口规范和使用方法。另外，该原理还允许独立于其他构件的应用实现一个构件的功能。就像封装一样，接口和实现的分离也是一种用来获得信息隐藏的技术。该原理强调一个客户只应该知道他需要知道的东西。
接口和实现的分离也支持可变性。如果构件的接口和实现分离，那么它就更容易在系统中进行改变。这种分离避免了客户直接受到构件变化的影响。该原理使构件行为和表示的改变而变容易，尤其是那些不影响接口的改变，例如对运行性能的提高。
8．分而治之
这条原理是众所周知的，在软件体系结构中该原理得到大量应用。例如，自上而下设计，将一个任务或构件分成可以独立设计的更小的部分。
9．层次化
处理复杂问题有两种方法：分而治之的横向分割和分层次处理的纵向分割。后者是一种把问题分解成建立在基础概念和思想上多层次的、从底向上逐步抽象的分析和表达的结构。
层次化在软件构造中是一个基本思想。类和对象是层次化的，操作系统构造、编译器构造、应用系统构造，无一不是层次化的。同样，软件体系结构也是层次化的。

1．7分布式软件体系结构
在集中式计算技术时代广泛使用的是大型机／终端的计算模型。这种计算模型是通过一台物理上与大型机相连接的非智能终端来实现大型机上的应用程序。在多用户环境中，大型机应用程序既负责与用户的交互，又负责对数据的管理。随着用户的增加，对大型机能力的要求不断提高。
20世纪80年代以后，集中式结构逐渐被以个人计算机为主的微机网络所取代。个人计算机和工作站的采用，改变了大型机／终端计算模型占据主导地位的状况，从而导致了分布式计算模型的产生和发展。
分布式体系结构主要具有以下优点。
(1)资源共享。分布式系统允许硬件、软件等资源共享使用。
(2)经济性。将个人计算机与工作站连接起来的计算机网络，其性能价格比要高于大型机。
(3)性能与可扩展性。根据Sun公司的理念一一网络即计算机，分布式应用程序能够利用网络上可获得的资源。通过使用联合起来的多个网络节点的计算能力，可以获得性能方面的极大提升。另外，至少在理论上，多处理器和网络是易于扩展的。
(4)固有分布性。有些应用程序是固有分布式的，如遵循客户机／服务器模型的数据库应用程序。
(5)健壮性。在大多数情况下，网络上的一台机器或多处理器系统中的一个CPU的崩溃不会影响到系统的其余部分。中心节点(文件服务器)是明显的例外，但可以采用备份系统来保护。
1．7．1多处理器体系结构
分布式系统的一个最简单的模型是多处理器系统。系统由许多进程组成，这些进程町以在不同的处理器上并行运行，可以极大地提高系统的性能。由于大型实时系统对响应时间要求较高，这种模型在大型实时系统中比较常见。大型实时系统需要实时采集信息，并利用采集到的信息进行决策，然后发送信号给执行机构。虽然，信息采集、决策制定和执行控制这些进程可以在同一台处理器上统一调度执行，但使用多处理器能够提高系统性能。

1．7．2客户机／服务器体系结构
客户机／／R务器(Client／Server，C／S)体系结构是基于资源不对等，且为实现共享而提出来的分布式体系结构，是20世纪90年代成熟起来的技术，C／S体系结构定义了工作站如何与服务器相连，以及将数据和应用分布到多个处理机上。
C／S体系结构有3个主要组成部分。
(1)服务器：负责给其他子系统提供服务。例如，数据库服务器提供数据存储和管理服务，文件服务器提供文件管理服务，打印服务器提供打印服务等。
(2)客户机：向服务器请求服务。客户机通常都是独立的子系统，在某段时问内，可能有多个客户机程序在并发运行。
(3)网络：连接客户机和服务器。虽然客户机程序和服务器程序可以在一台机器上运行，但在实际应用中，通常将它们放在不同的机器上运行。
在C／S体系结构中，客户机可以通过远程调用来获取服务器提供的服务，因此客户机必须知道可用的服务器名称及它们所提供的服务，而服务器不需要知道客户机的身份，也不需要知道有多少台服务器在运行。
C／S系统的设计应该考虑应用系统的逻辑结构。在逻辑上，通常将应用系统划分为三层。即数据管理层、应用逻辑层和表示层。数据管理层关注数据存储及管理操作，通常选择成熟的关系数据库管理系统来承担这项任务。应用逻辑层关注与业务相关的处理逻辑。表示层关注用户界面及与用户的交互。
传统的C／S体系结构为二层的C／S体系结构。在这种体系结构中，一个应用系统被划分为客户机和服务器两部分。典型的二层C／S体系结构如图6—10所示。二层C／S体系结构可以有两种形态。
(1)瘦客户机模型。在瘦客户机模型中，数据管理部分和应用逻辑都在服务器上执行，客户机只负责表示部分。瘦客户机模型的主要缺点是它将繁重的处理负荷都放在了服务器和网络上，服务器负责所有的计算，将增加客户机和服务器之间的网络流量。目前个人计算机所具有的处理能力在瘦客户机模型中根本用不上，因此造成了极大的浪费。
(2)胖客户机模型。在这种模型中，服务器只负责对数据的管理。客户机实现应用逻辑和与系统用户的交互。
胖客户机模型能够利用客户机的处理能力，比瘦客户机模型在分布处理上更有效。但另一方面，随着企业规模的日益扩大，软件的复杂程度不断提高，胖客户机模型逐渐暴露出以下缺点：图6-11三层c／s体系结构
(1)开发成本较高。C／S体系结构对客户端软硬件配置要求较高，尤其是服装销售管理软件的不断升级，对硬件要求不断提高，增加了整个系统的成本，且客户端变得越来越臃肿。
(2)用户界面风格不一，使用繁杂，不利于推广使用。
(3)软件移植困难。采用不同工具或平台开发的软件，一般互不兼容，很难移植到其他平台上运行。
(4)软件维护和升级困难。由于应用程序安装在客户端，如果软件需要维护，则每台客户机上的软件都需要更新或升级。
二层C／S体系结构的根本问题是必须将三个逻辑层——数据管理层、应用逻辑层和表示层映射到两个系统上。如果选择瘦客户机模型，则可能有伸缩性和性能的问题。如果选择胖客户机模型，则可能有系统管理上的问题。为了避免这些问题，三层C／S体系结构应运而生，其结构如图6—11所示。与二层C／S体系结构相比，三层C／S体系结构中增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。三层C／S体系结构将整个系统分成表示层、应用逻辑层和数据层3个部分。
(1)表示层：表示层是应用程序的用户界面部分，担负着用户与应用程序之间的对话功能。
它用于检查用户从键盘等输入的数据，显示应用程序输出的数据，一般采用图形用户界面(GraphicUserInterface，GUI)。
(2)应用逻辑层：应用逻辑层为应用的主体部分，包含具体的业务处理逻辑。通常包含有确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。
(3)数据层：数据层主要包括数据的存储及对数据的存取操作，一般选择关系型数据库管理系统。
三层c／s结构具有以下优点：
(1)允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性。
(2)允许更灵活、有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三个层次。并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
(3)应用的各层可以并行开发，可以选择各自最适合的开发语言。
(4)利用应用逻辑层有效地隔离开表示层与数据层，未授权的用户难以绕过应用逻辑层而利用数据库工具或用黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础。
需要注意的是，三层c／s结构各层问的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。此外，设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层c／s结构的关键问题。
浏览器／月艮务器(Browser／Server，B／S)风格就是上述三层应用结构的一种实现方式，其具体结构为浏览器／Web服务器或浏览器／数据库服务器。
B／S体系结构主要是利用不断成熟的WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。从某种程度上来说，B／S结构是一种全新的软件体系结构。
B／S体系结构具有以下优点：
(1)基于BtS体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块。真正达到了“零客户端”的功能，很容易在运行时自动升级。
(2)B／S体系结构还提供了异种机、异种网、异种应用服务的联机、联网和统一服务的最现实的开放性基础。
与C／S体系结构相比，B／S体系结构也有许多不足之处：
(1)B／S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
(2)B／S体系结构的系统扩展能力差，安全性难以控制。
(3)采用B／S体系结构的应用系统，在数据查询等响应速度上，要远远低于C／S体系结构。
(4)B／S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理应用。

1．7．3分布式对象体系结构
在客户机／服务器模型中，客户机和服务器的地位是不同的。客户机必须要知道服务器的存在及其所提供的服务，而服务器则不需要知道客户机的存在。在设计这种体系结构时，设计者必须决定服务在哪里提供，而且还得规划系统的伸缩性。当有较多的客户机增加到系统中时，就需要考虑如何将服务器上的负载分布开来。
分布式系统设计的更通用方法是去掉客户机与服务器之间的差别，用分布式对象体系结构来设计系统。
分布式对象的实质是在分布式异构环境下建立应用系统框架和对象构件。它将应用服务分割成具有完整逻辑含义的独立的子模块或构件，各个子模块可放在同一台服务器或分布在多台服务器上运行。模块之间需要进行通信时，传统的方式往往通过一种集中管理式的固定的服务接口进行能力有限的远程过程调用。这种方式不仅开销大，也难于开发，要进行成功的软件系统集成也存在很多障碍。更好的方式是模块之间通过中间件的相互通信，就如硬件总线允许不同的卡插于其上以支持硬件设备之间的通信一样，通常将这个中间件称为软件总线或对象请求代理，它的作用是在对象之间提供一个无缝接口。
分布式对象技术的应用目的是为了降低主服务器的负荷、共享网络资源、平衡网络中计算机事务资源的分配，提高计算机系统协同处理的能力．从而使应用的实现更为灵活。分布式对象技术的基础是构件。在分布计算的环境下构件可以是一个简单的对象，但大多数情况下是一组相关的对象组合体，提供一定的服务。分布式环境下，构件是一些灵活的软件模块，它们可以位置透明、语言独立和平台独立地互相发送消息，实现请求服务。构件之间并不存在客户机与服务器的界限，接受服务者扮演客户机的角色，提供服务者就是服务器。
当前主流的分布式对象技术规范有OMG的CoRBA、Microsoft的．NET和Sun公司的J2EE技术。它们都支持服务端构件的开发，都有其各自的特点。
(1)CORBA：主要目标是提供一种机制，使对象可以透明地发出请求和获得应答，从而建立起异质的分布式应用环境。它是开放的、独立于应用提供商的设计规范，支持网络环境下的应用程序，适用于各种体系结构和平台，可方便客户通过网络访问、执行各种对象。
(2)．NET：．NET几乎继承了对象组件模型(ComponentObjectModel，COM)和分布式组件对象模型(DistributedComponentObjectModel，DCOM)的全部功能。它不仅包括了COM的组件技术，更注重于分布式网络应用程序的设计与实现。．NET技术紧密地同操作系统相结合，通过系统服务为应用程序提供全面的支持。
(3)J2EE：J2EE则利用Java平台简化企业级解决方案的规划和开发，是管理相关复杂问题的体系结构。它集成了COBRA技术，具有方便存取数据库的功能，对EJB、JavaServletsAPI、JSP及XML提供全面支持。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com