服装连锁管理软件体系结构基础

软件体系结构是在识别可重用部件和连接器的基础上，研究软件结构的表达和分析的理论和技术。在过去十多年间，系统软件体系结构受到了广泛的关注，目前已经成为系统软件工程研究的一个重要分支和热点。本章主要介绍几种常见的服装连锁管理软件体系结构风格。

软件体系结构基础
软件体系结构的定义
虽然软件体系结构在软件工程中已经有很深的根基，但是由于有关研究和使用刚刚兴起，因而人们对它的理解还没有达成共识。许多研究人员基于自己的经验从不同角度、不同侧面对体系结构进行了刻画。下面列出一些重要文献中关于软件体系结构的定义。
DewaynePerry和AlexanderWolf于1992年正式提出软件体系结构的概念：软件体系结构是具有一定形式的结构化元素。结构化元素包括：进程元素、数据元素和连接元素三类。

MaryShaw和DavidGarlan于1993年提出：软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计，研究整体结构设计和描述方法。在这里，设计和说明总体系统结构作为一个新问题被正式提了出来Bass等人于1994年在关于软件品质属性研究中提出：软件结构设计至少包括应用领域的功能分割，系统结构，结构的领域功能分配这三个方面。Hayes—Roth指出：软件体系结构是由功能构件组成的抽象系统的说明，它是按照功能构件的行为、界面和构件之间的相互作用进行描述的。

DewaynePerry和DavidGalan于1995年在IEEE软件工程学报上将其定义为：软件体系结构是一个程序／系统各部件的结构、它们之间的相互关系、进行设计的原则和随时间演进的指导方针。

南加州大学软件工程中心的BarryBoehm指出：一个软件体系结构包括：①一个软件和系统部件、它们之间的相互关系及约束的集合；②一个系统需求说明的集合；③一个基本原理用以说明某一部件、互连和约束能够满足系统的需求。
1997年，Bass、Clements和Kazman在《使用软件体系结构》一书中将其定义为：一个程序或计算机系统的软件体系结构包括一个或一组软件部件、软件部件的外部可见特性及其相互关系。

下面对服装连锁管理软件体系结构定义进行简单的总结分析：软件体系结构定义了软件部件(Component)，包括部件间交互的定义，特别强凋省略和部件相互关系无关的内容信息(ContentInformation)；软件体系结构并不说明什么是部件、什么是部件的相互关系；每一个软件系统都有自身的体系结构，即由软件部件及其相互关系组成；软件体系结构中每一部件的行为是体系结构的一部分，反映部件间如何进行交互；软件体系结构的基本元素是部件，部件的描述信息包括：计算功能——一部件所实现的整体功能，额外功能特性——描述部件的执行效率、处理能力、环境假设和整体特性，结构特性——描述部件如何与其他部件集成在一起，以构成系统信息；家族特性一描述了相同或相关部件之间的关系。 总之，软件体系结构的研究正在发展，软件体系结构的定义也必然随之完善。

研究软件体系结构的目的
下面从三个方面说明为什么要研究软件体系结构。
(1)体系结构是风险承担者进行交流的手段。
软件体系结构代表了系统的公共的高层次的抽象。这样，系统的大部分有关人员(即使不是全部)就能把它作为建立一个互相理解的基础，形成统一认识，互相交流。体系结构提供了一种共同语言来表达各种关注和协商，进而对大型复杂系统能进行理智的管理。这对项目最终的质量和使用有极大的影响。
(2)体系结构是早期设计决策的体现，早期的决策比较难处理、比较难以改变、影响范围也比较大。
软件体系结构明确了对系统实现的约束条件；软件体系结构决定了开发和维护组织的组织结构；软件体系结构制约着系统的质量属性；通过研究软件体系结构可能预测软件的质量；软件体系结构使推理和控制更改更简单；软件体系结构有助于循序渐进的原型设计；软件体系结构可以作为培训的基础。基于以上因素，可以看出体系结构作为早期设计决策的体现的重要性。
(3)软件体系结构是可传递和可重用的模型。
软件体系结构级的重用意味着体系结构的决策能在具有相似需求的多个系统中发生影响。通过体系结构的抽象可以使设计者能够对一些经过实践证明是非常有效的体系结构部件进行复用，从而提高设计的效率和可靠性。软件体系结构有利于形成完整的软件生产线，并共享公共的软件体系结构。可以引进大量的外部开发的部件来构造系统，只要这些部件是与确定的体系结构相容的。体系结构可以使部件的功能与其互连机制分离，从而可以分散注意焦点，有利于处理问题。体系结构有利于面向模式、面向部件的开发。

软件体系结构的研究角度
1．软件角度
服装连锁管理软件体系结构从不同角度分析软件的体系结构，描述一个软件系统的整体结构，能全面、清晰地反映软件系统的全貌，也能满足不同参与者的需求。
如图8．1所示是目前常用的“4+1”角度模式：
逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。开发视图也称模块视图，主要侧重于软件模块的组织和管理。进程视图侧重于系统的运行特性，主要关注一些非功能性的需求，它强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。物理视图主要考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等，解决系统拓扑结构、系统安装、通信等问题。场景可以看做是那些重要系统活动的抽象，它使4个视图有机联系起来，从某种意义上说，场景是最重要的需求抽象。在开发体系结构时，它可以帮助设计者找到体系结构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。

2．软件风格角度
软件体系结构描述了对软件设计成分如何进行整理和安排，并且对这些整理和安排加以限制，从而形成一种设计软件的特定模式。每一种软件体系结构风格均有自己的组织原则和基本成分，它们决定了风格的形成。
有原则地使用结构风格有比较多的益处，例如，促进了对体系结构设计的复用；带来显著的代码复用；体系结构风格不变部分可以共享同一段实现代码；只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构；对标准风格的使用也支持了互操作性；CORBA与基于事件机制的集成；结构风格通常允许进行特殊的和风格有关的分析，这与连接件的特性有关；通常有可能对特定的风格提供可视化手段。
软件体系结构风格有4种基本的要素：①提供一个词汇表，定义与设计元素有关的部件、连接件类型等；②定义一套配置规则或系统的拓扑限制，明确设计元素的合法组成方式；③定义一套语义解释原则，使得设计元素的组成可以适当地约束于配置规则之中，并具有清晰的含义；④定义可以对基于这种风格建立的系统进行的分析，例如，Client／Server结构风格的实时处理过程的可调度性。

软件体系结构的研究热点
近年来，人们逐渐认识到软件体系结构在软件开发中的重要地位，好的服装连锁管理软件体系结构是决定一个软件系统成功的因素，因此将热点集中到软件体系结构的研究上。目前，已经有一些公用的体系结构规范，如管道／过滤器层次系统、Client／Server结构等，但只是用特定的方式来理解并用于特定的系统。软件系统设计者没有从系统体系结构中寻找共性来对特定领域形成通用的体系结构范型，没有对体系结构模型进行选择的原则，甚至没能将他们的设计技巧规范地表达出来，因此无法传授给他人。
目前，人们在软件体系结构领域主要致力于模块接口语言、特定领域的体系结构、软件重用、软件模式的规范化、软件体系结构描述语言、软件体系结构设计的形式化基础和设计环境的研究。主要的研究方向如下：
(1)提供软件体系结构描述语言：使开发者能够描述他们设计的体系结构，以便与人交流。
(2)对软件体系结构的专门知识的整理：对软件工程师在软件开发中得来的各种体系结构方面的原则、模式进行整理和分类。
(3)提供特定领域的体系结构框架：使得开发者能够很容易地将此体系结构框架实例化为该领域内新的软件系统。
(4)提供软件体系结构设计技术的形式化基础：希望对系统的非功能性需求(性能、可维护性等)给出形式化特征，使得据此设计的软件体系结构可以更好地被理解和实现。
(5)研究体系结构的分析技术：预见软件质量，比较不同的体系结构性。
(6)体系结构设计规则与开发方法的研究：将体系结构设计活动推，“到更广的软件开发进程中去。
(7)体系结构设计工具和环境：用软件工具描述和分析软件体系结构。

基本的软件体系结构风格
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
本节主要讨论以下内容：管道和过滤器(PipesandFilters)；数据抽象和面向对象组织(DataAbstractionand00一organization)；基于事件的隐式调用(Event—based，ImplicitInvocation)；分层系统(LayeredSystems)；仓库系统(Repositories)。

管道和过滤器
在管道／过滤器风格的软件体系结构风格中，每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。如图8．2所示是管道／过滤器风格的示意图。
过滤器的作用是对输入数据进行局部变换，并采用渐进式计算方法，在未处理完所有输入数据以前，就可以产生部分计算结果，并将其送到输出端VI。管道的作用是作为各过滤器之间的连接器将一个过滤器的输出传到下一个过滤器的输入端。
管道和过滤器风格的优点如下：
(1)系统的整体行为可以理解为各独立过滤器行为的简单合成。
(2)系统维护容易：过滤器可以容易地替换和增加。
(3)允许进行如吞吐量和死锁等性能分析。
(4)很自然地支持并发执行。
但是，这样的系统也存在一些缺点：
(1)过滤器容易被看成是一个提供完整的将输入数据转换成输出数据的模块。实际上，过滤器是以渐进式处理数据的。
(2)维护两个分离但相关的数据流时，很难设计这样的系统。
(3)由于管道遵循最一般的数据传输标准，所以，过滤器必须承担数据语法分析和编码的额外工作，增加了复杂性，降低了性能。

数据抽象和面向对象组织
抽象数据类概念对软件系统的重要作用。目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上，据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称做管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。如图8．3所示是数据抽象和面向对象风格的体系结构。
面向对象的系统有许多优点，并早已为人所知：
(1)因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他对象。
(2)设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
但是面向对象也存在某些缺点：
(1)为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。
(2)必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，c也使用了对象B，那么，c对B的使用所造成的对A的影响可能是料想不到的。

基于事件的隐式调用
基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发时，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。
这种风格的构件是一些模块，这些模块既可以是一些过程，也可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。
这种风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响，这样就不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。
基于事件的隐式调用的主要优点有：
(1)为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
(2)为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其他构件的接口。
基于事件的隐式调用的主要缺点如下：
(I)构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序。
(2)数据交换的问题。有时数据可被一个事件传递，但在另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。
(3)既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理则存在问题。

分层系统
层次系统组织成一个层次结构，每一层为上层服务，并作为下层用户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。在这样的系统中构件在一些层实现了虚拟机(在另一些层次系统中层是部分不透明的)。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。
这种风格支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。
如图8．4所示是分层系统的示意图。
分层系统有许多优点：
(1)支持基于抽象程度递增的系统设计。
(2)支持功能扩展、增强。因为功能的改变最多影响相邻的层次。
(3)支持复用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。
但是，分层系统也有一些缺点：
(1)并不是每个系统都可以很容易地划分为分层的模式，有时即使存在逻辑层次结构，但出于对系统性能的考虑，往往会将低层和高层的功能耦合起来。
(2)很难找到一个合适的、正确的层次抽象方法。

仓库管理软件
在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化。
控制原则的选取产生两个主要的子类：一方面，若输人流中某类时间触发进程执行的选择，则仓库是一个传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一个黑板系统。
如图8．5所示是黑板系统的组成。
从图中可以看出，黑板系统主要由三部分组成：知识源、黑板数据结构和控制。
还有体系类型的软件体系结构，如用户／服务器模型，这里不做详细介绍。
总之，一个体系结构风格定义了有相同组织结构模式的一系列系统，并定义了组件和连接器类型的列表以及一套组件连接的约束。许多体系结构模型还有一个或多个语义模型来指定如何由各部分的属性决定系统的整体属性。

基于软件体系结构的开发模式
模式是指从某个具体的形式中得到的一种抽象，在特殊的非任意性的环境中，该形式不断地重复出现。
一个软件体系结构的模式描述了一个出现在特定设计语境中的特殊的再现设计问题，并为它的解决方案提供了一个经过充分验证的通用图示。解决方案图示通过描述其组成构件及其责任和相互关系以及它们的协作方式来具体指定。

良好的体系结构可以为软件开发和维护带来好处：识别相似系统的通用结构模式，有助于理解系统高层之间的联系，使得新系统可以作为以前系统的变种来构造；合适的体系结构是系统成功的关键，而不合适的体系结构可能带来灾难性的后果；对软件体系结构的理解，可以帮助开发人员在不同的设计方案中做出理性的选择；体系结构对于分析和描述复杂系统的高层属性通常是十分必要的；各种体系结构风格的提炼、描述和普遍采用，便于软件开发人员在系统设计中互相交流；在服装连锁管理软件开发文档中清晰地记录系统体系结构，不仅可以显著地节省软件理解的工作量，而且便于在软件维护的全过程中保持系统的总体结构和特性不变。

传统的软件开发过程可以划分从概念直到实现的若干个阶段，包括问题定义、需求分析、软件设计、软件实现及软件测试等。如果采用传统的软件开发模式，软件系统结构的建立应位于需求分析之后、概要设计之前。传统的软件开发模式存在开发效率不高，不能很好地支持软件重用等缺点。

基于软件体系结构的开发模式把整个服装连锁管理软件过程划分为系统结构需求、设计、文档化、复审、实现、演化6个子过程。

软件体系结构应用实例
管理信息系统(简称为MIS系统)是目前最常见的应用系统形式之一，然而即使是一些资深的MIS系统开发者，对其体系结构均没有进行系统的分析与总结，使得很多MIS系统在可用性、稳定性和可扩展性等方面存在不足。有数据表明，在全球范围内，有50％的“MIS系统”是完全失败的，这与没有采用合适的体系结构是有一定关系的。在本实例中，根据MIS处理对象的不同，对MIS系统进行分类，并通过实例对其中最常见的一种体系结构进行简单分析。

MIS系统的处理对象主要是数据、信息与知识。首先对这三个概念进行简单的定义：
数据：数据是对处理对象进行简单加工所形成的记录。以银行系统为例，某个用户在营业网点存入一笔钱，则会在银行的数据中心至少形成两条数据记录：(1)在其账户的余额上增加存人的金额；(2)增加一条流水记录，包括账户、户名、营业网点、操作员、存入时间、存入金额等信息。这些可以称之为数据。

信息：信息是对数据进行过滤，分析与综合后所形成的内容。例如某银行的营业网点在每天的营业结束后需要统计一下本日存款笔数、取款笔数、存款金额、取款金款、营业网点余额等。上述在数据的基础上进行汇总及简单抽取所形成的内容，可以称之为信息。
知识：知识是在信息的基础上按照多维度统计与综合分析所形成的具体决策性和指导性的概要结论。例如，在学校附近的银行营业网点经过统计和分析近几年的银行业务发现，每年9月初现金取款业务非常频繁，而且取款额度也比较大，经过分析发现这是因为每年9月初新生开学所造成的。所以每到9月初，银行可以多准备一点现金储备，并多开相应的业务窗口来应对突然增长的用户人群。这就是在知识的指导下银行营业网点对业务的调整。

到目前为止，仍然有开发者没能准确区分以数据处理为中心的系统和以信息处理为中心的系统之间的区别，都是按照管理系统的架构来进行设计。事实上，以数据处理为中心的系统应以事务系统架构为宜，而以信息处理为中心的系统则适宜于采用传统的IPO(输入、处理与输出)架构。

本章小结
本章首先从一些重要文献中关于软件体系结构的定义出发分析总结了软件体系结构的定义。然后重点说明了几种基本的软件体系结构风格，包括管道和过滤器、数据抽象和面向对象组织、基于事件的隐式调用、分层系统、仓库系统。接着简单介绍了软件体系结构的开发模式。

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