古巴ERP库存模块的软件架构

摘要

在这项工作中，展示了针对古巴ERP的库存模块的面向服务的体系结构的提案，从而使它成为：可移植，安全，可伸缩且可与其他系统集成，同时又可扩展到其他系统。 ERP模块。

面向erp服务的架构

为了实现提出的定义和描述软件体系结构的目标，根据该主题的最负盛名的作者以及开发库存管理系统和系统的经验，对构成该体系结构的元素和当前趋势进行了研究。仓库（SIGIA）。

对体系结构进行定义和描述的成功与否，将主要取决于其开发过程中做出的体系结构决策，所决定的最适当技术以及允许对系统本身进行有利开发的设计方面，并在其中加以考虑。组件之间的关系和配置，并允许组织正在开发的系统的结构，从而使整个工作团队对正在开发的内容有清晰的了解。

关键词

软件体系结构，样式，模式，组件，框架，面向服务的体系结构（SOA），Web服务，集成，企业资源计划（ERP），XML，SOAP，UDDI，WSDL。

介绍

随着苏维埃社会主义共和国联盟社会主义的消失和美国在1990年代对古巴的封锁加剧，古巴经济陷入瘫痪。因此，该国需要重新设计经济政策的过程。从那时起，开始实施逐步的经济措施方案，目的是以尽可能最低的社会成本克服国家局势。

由于该国面临的经济困难，古巴国家开始对经济的各个战略领域进行投资，并开始分配大量资源以提高社会的计算机化水平，这是最好的例子可靠且最新的是创建计算机科学大学，以生产高质量的软件并将其插入世界市场。作为该策略的结果，已经获得了更高效，更高质量的业务系统，可以满足当前的技术需求。

从业务改进开始，公司致力于提高生产或提供服务的效率。因此，使用允许业务流程自动化并因此使其效率更高的计算机系统。使之成为可能的系统之一就是企业资源计划（ERP），它是一种信息管理系统，可在单个应用程序中集成和自动化公司的所有业务流程，从而可以理解：生产，销售，购买，物流，会计，项目管理，库存，仓库控制，订单，工资单，人力资源等。

ERP为业务用户提供支持，有效的决策信息管理，快速的响应时间以及运营总成本的降低。（Martínez等，2001）。

库存资源是公司资源计划中最重要的过程之一，因此它构成了ERP系统开发的坚实基础。

在当今的经济中，库存管理已成为业务管理问题的顶峰，因为它是生产力的重要组成部分。如果库存过高，成本可能会导致公司出现财务流动性问题。另一方面，如果维持不足的库存水平，则可能无法令人满意地为客户提供服务，这将导致利润减少和市场损失（Sanchez，2006年）。因此可以看出，保持健康的库存将确保任何公司和行业在仓库中移动产品时都具有更高的可靠性。

在古巴，有库存管理系统，其中包括：顾名思义，文化和自然遗产清单系统（SIP）的创建是出于遗产的目的，例如：对该系统的注册，控制和保存。为了记录和处理从森林清单中获得的数据，执行森林清单处理计算机系统（INVENFOR 1.0），以便以有助于更多森林管理规划的方式估算林分的数据参数高效。系统的其他示例包括：GET（旅游电子集团）公司的DRIM，FONDUS，SI和IHMM 2000，后者旨在用于酒店设施。

它们都有一个共同点，那就是大多数系统专用于某些公司的运营，因此它们并不灵活，而是设计封闭，难以标准化库存管理流程和流程。与其他系统集成，需要解决的基本要素。

因此，有必要开发一种新的库存管理系统，以满足公司和国家的当前需求，并配备最新技术，以使其更加灵活，现代化，友好，可靠和安全，并且能够与其他系统集成。正是由于这一点，它可以根据客户的特殊需求进行配置，并且符合财政和价格部制定的新规定。简而言之，它满足了旧系统已不再提供的所有新要求。

为了令人满意地开发任何软件系统并同时保证一定的质量和低成本，有必要使用开发方法来指导该过程。开发过程中的一个重要元素是高级设计的概念，它可以组织和理解正在开发的系统的结构，并使整个团队对正在开发的东西有清晰的认识。

事实是，在软件开发过程中出现了限制和阻碍过程本身的情况。其中您可以看到：稀缺的重用，软件元素的选择不当，体系结构样式，体系结构模式，通信协议，设计元素的组成，设计元素的功能分配，工具，框架，同步问题以及数据访问，程序员只要符合他们希望程序执行的操作，就可以以任何方式编写代码，从而影响可扩展性，性能和成本。解决所有这些问题的方法是正确定义和描述软件体系结构。

软件体系结构是由于需要使系统更具模块化，允许组件的重用而产生的，因此其实施可大大降低成本。由于组件的结构，它们的通信方式以及它们之间存在的关系被明确地建立，因此还允许在系统的各个元素之间保持较低的耦合，但是具有非常高的内聚性。

以上所有导致了以下问题的定义：

如何在库存管理系统的开发过程中做出高层设计决策，以使其可扩展，安全，可移植并与其他业务管理系统集成？

研究集中在研究对象：库存管理系统的开发过程。为此，提出了以下总体目标：提出一种面向服务的软件体系结构，该体系结构可使库存管理系统具有可伸缩性，安全性，可移植性并与其他业务管理系统集成。

定义为行动领域：库存管理系统的软件体系结构。

为了完成拟议的目标，使用以下任务进行了研究：

• 对软件体系结构的最新状态进行研究，以了解不同的体系结构方法，其发展方式，主要趋势和定义，以及在业务系统开发中蓬勃发展的最重要的体系结构样式。要使用的建筑风格，使用它们的合理性以及它们的应用，要使用的框架和开发工具的定义，体系结构的定义和描述，通过专业标准进行验证。

使用以下方法执行任务：

理论方法

• 历史-逻辑：确定建筑模型和方法开发的当前趋势。分析性-综合性：从处理的信息中得出结论，并指定提议的体系结构模型的特征。系统方法：定义系统的元素及其关系。

经验方法

• 测量：用于评估案例研究中关键情况下的响应时间。

可能的结果

关于库存管理系统的面向服务的软件体系结构的提案，该体系结构使其具有可伸缩性，安全性，可移植性以及与其他业务管理系统的集成性。

本工作分为三章

第一章：理论基础

在这一章中，本研究的理论基础是基于对软件体系结构的最新状态以及不同的体系结构方法，主要趋势和定义的研究而进行的。对正在兴起的最重要的建筑风格进行了研究，揭示了它们的优缺点。简而言之，所有这些方面都将能够为支撑研究的理论框架建模。

第2集：

在这一章中，提出了解决该研究的理论设计中所提出的问题的建议，该建议由信息科学大学提出的用于生产项目的建筑工件说明文件给出。

第3章：

本章指定了将支持上一章中针对库存管理系统的架构建议的工具。另外，从质量的角度对提出的解决方案进行了分析。

第一章：理论基础

介绍

在本章中，将进行研究的理论基础，对软件体系结构的艺术以及不同的体系结构方法，主要趋势和定义进行研究。对业务和管理系统开发中兴旺的最重要的体系结构样式进行研究，揭示了它们的优缺点，以便为开发库存管理系统选择合适的体系结构。分析了软件体系结构，体系结构建模语言，面向服务的体系结构样式（当前面临的挑战）以及软件体系结构的质量的不同抽象层次。

最新的软件架构

软件体系结构是仅持续几年的年轻实践。它起源于60年代，但直到90年代，Dewayne Perry和Alexander Wolf才以今天所知的方式揭露它。

同样，Bass对其定义如下：“计算机或程序系统的软件体系结构是系统结构的结构，包括软件的组件，这些外部可见组件的属性以及关系。其中。” （Pressman，2002）。

另一方面，许多架构师在国际上最认可的定义是行业征税的，属于IEEE 1471，因此引用如下：“软件架构是系统的基本组织，该系统体现在其组件，它们之间的关系以及与软件之间的关系。环境和指导其设计和发展的原则» （雷诺索，2006年）。

尽管存在许多软件体系结构定义，但绝大多数人都认为这是指系统的广泛结构（高级抽象），该结构由组件和它们之间的关系组成。对于什么软件体系结构定义为计算机系统软件元素的结构和组织，这些元素将如何以及在什么条件和配置下进行通信。

可以得出结论，软件体系结构是：与任何开发方法无关的学科，代表了高水平的系统抽象，并且对非功能性需求做出了响应，因为这些要求可以通过对应用程序进行建模和设计来满足。以同样的方式可以得出结论，软件体系结构不是：软件设计是一种成熟的法规，在学术界和工业界都以相同的方式对待。

1.2.1.2。样式

通常，当人们以一种或另一种方式谈论架构时，他指的是与具体相关的东西：分类。事实是，这不仅是一个分类问题，而且每种架构形式都有着很大的关系，并且与工具，概念，经验和问题相关联。

这些分类已通过多种方式调用，例如：建筑类，建筑类型，重复原型，种类，拓扑范式，通用框架以及其他几十种。十多年来，这些建筑资格被称为：样式或建筑模式。样式仅在具有高度抽象性的描述性理论体系中体现。模式无处不在。 （Reynoso等人，2004年）

Dewayne Perry和Alexander Wolf在1992年10月提出了第一个明确的风格定义。他们将建筑风格的推理作为该学科的基本方面之一。 “风格是一种描述性概念，它定义了一种表达形式或建筑组织形式。样式集列出了软件结构的可能基本形式，而复杂形式则通过基本样式的组合来表达”（Perry等，1992）。

根据Pressman（Pressman，2002年），一种样式描述了一种系统类别，其中包含执行系统所需功能的一组组件，使组件之间能够进行通信，协调和协作的一组连接器，它们定义了如何集成组件以形成系统，以及有助于设计人员理解系统所有部分的语义模型。建筑风格也是一种建筑模式。

样式结合了组件，连接器，配置和约束。样式的描述可以用自然语言或图表来表述，但是最好用建筑描述语言（ADL）或形式规范语言（LFE）进行描述。

可以得出以下结论：

• 一种样式考虑了AS的四个“ C”（元素，连接器，配置和约束），用于合成解决方案结构，这些结构随后将通过设计进行完善，很少有抽象样式封装了各种各样的具体的配置他们定义了应用程序的可能模式，避免了体系结构错误。它们允许在不同的非功能需求集之前评估具有已知优点和缺点的替代体系结构。

1.2.1.3。模式

框架概念用于软件系统开发的许多领域。您可以找到用于开发Web应用程序，桌面应用程序，医疗应用程序，游戏开发以及人们可以想到的任何领域的框架。

通常，术语框架是指由可定制和可互换的组件组成的软件结构，用于开发应用程序。换句话说，可以将框架视为不完整且可配置的通用应用程序，可以将最后一部分添加到该通用应用程序中以开发特定的应用程序。

因此，总而言之，框架是应用程序的框架，程序员必须根据框架的特定需求对其进行修改以开发应用程序。

1.2.2。 发展趋势

尽管今天没有任何东西可以明确地认可软件架构学派的存在，也没有可以分析每种结构的特殊性的参考书目，但目前可以大致区分出六种潮流。属于这些潮流之一并不代表确定性，因为一些软件体系结构从业人员在不同的时间执行在不同框架中进行的不同工作，或者因为他们只是改变了观念。

提议的软件架构学院的部门如下：

1. 建筑是工程和面向对象设计的阶段。显然是格雷迪·布赫（Grady Booch）的；对他来说，软件体系结构是“系统的逻辑和物理结构，由在开发过程中应用的所有战略和战术决策构成”。其他定义表明，从这个角度来看，软件体系结构涉及有关组织，结构元素的选择，行为，组成和体系结构样式的决策，这些决策可以通过Kruchten 4 +1模型的五个经典视图来描述。 （Reynoso，2006年）基于样式，ADL和视图的静态模型的结构体系结构。这种趋势的代表都是学者，主要来自卡耐基大学，这也是该学院主导软件体系结构的愿景，尽管它是最重要的努力，旨在将软件体系结构识别为学科，其类别和工具在工业实践中仍然知之甚少。在机芯内部，您可以看到不同的部分。在门洛帕克（Menlo Park）SRI的马克·莫里科尼（Mark Moriconi）小组代表了一种非正式的“盒式”变体，而形式主义则更为正式。原则上，在形式化方面可以识别三种模式；非正式的使用口头描述或箱形图，中级字符使用ADL和最苛刻的使用正式规范语言（例如CHAM和Z）的语言。在当前，架构设计不仅是最高的抽象级别，而且不必与明确配置应用程序；很少会找到对编程语言或代码段的引用，并且通常没有人谈论类或对象。尽管有些参与者将数据模型排除在软件体系结构的关注范围之外（Shaw，Garlan等），但其他参与者则坚持认为它的相关性（Medvidovic，Taylor）。 （雷诺索，2006年）很少会找到对编程语言或代码段的引用，并且通常没有人谈论类或对象。尽管有些参与者将数据模型排除在软件体系结构的关注范围之外（Shaw，Garlan等），但其他参与者则坚持认为它的相关性（Medvidovic，Taylor）。 （雷诺索，2006年）很少会找到对编程语言或代码段的引用，并且通常没有人谈论类或对象。尽管有些参与者将数据模型排除在软件体系结构的关注范围之外（Shaw，Garlan等），但其他参与者则坚持认为它的相关性（Medvidovic，Taylor）。 （雷诺索，2006年）激进的建筑结构主义。这与以前的趋势（主要是欧洲趋势）背道而驰，后者与UML世界之间的对抗态度更为激烈。在这一运动中，至少有两种趋势，一种趋势完全排除了面向对象建模与软件体系结构的相关性，另一种趋势则是试图定义新的元模型和UML的原型来纠正这种情况。 （Reynoso，2006年）基于模式的体系结构。在承认从面向对象设计中产生的模型的重要性时，它在建模中与UML的联系并不紧密，而与方法论中的CMM的联系并不紧密。该变体可以识别为参考的图案文本是Buschmann等人的POSA系列，其次是四阶乐队。设计包括识别和阐明现有的模式，这些模式的定义与建筑风格类似。 （Reynoso，2006年）流程体系结构。自21世纪初以来，以SEI为中心，第一代卡耐基梅隆大学的一些建筑师和第二代的许多新名字的参与者：里克·卡兹曼，伦·巴斯，保罗·克莱门茨等。它尝试建立特定于软件体系结构的生命周期模型和需求启发技术，集思广益，设计，分析，替代选择，验证，比较，质量估计和经济合理性。 （Reynoso，2006）基于场景的架构。这是最新的流。这是一个以荷兰为中心的主要欧洲运动。它可以恢复软件体系结构与系统的需求和功能之间的联系，而在经典结构体系结构中偶尔会变得模糊。在此流中，UML用例图通常用作非正式或偶然的工具，因为用例是可能的场景之一。用例不是面向对象的。除了ATAM，CBAM，QASAR和其他SEI方法的编码器外，与此模式相关的作者还包括埃因霍温技术大学，布里耶大学，格罗宁根大学和飞利浦研究中心的荷兰建筑师。（雷诺索，2006年）

1.2.3。 软件架构与设计之间的区别

软件体系结构的学术界与使设计与体系结构混乱相去甚远，尽管有些从业人员在谈到该主题时却将这两个领域之间的关系弄得模棱两可。

在某种程度上，架构和设计可以达到相同的目的。但是，软件体系结构侧重于系统结构和组件的互连，从而使其与传统软件设计（如面向对象的设计）区分开来，而传统的软件设计则将更多的精力放在对低层抽象进行建模上。 ，例如算法和数据类型。随着高级体系结构的完善，其连接器可能会失去突出性，并散布在较低级别的体系结构元素上，从而导致将体系结构转换为设计。 （Reynoso等，2004）。

软件构架是软件设计中的一门相对较新的学科，实际上涵盖了设计方法学和分析方法学。当代的软件架构师兼具系统分析师，系统设计师和软件工程师的职责。但是体系结构不仅仅是功能的重新定位。体系结构的概念试图将分析和设计活动纳入一个更广泛，更一致的设计框架中。但是，架构比一方面的分析和设计的总和更加集成。方法和模型的集成是将AS与分析和设计技术的简单并置区别开来的地方。 （Albin，2003）。

架构涉及更高层次的抽象；处理组件而不是程序；这些组件之间而不是接口之间的交互作用；施加在组件和交互上的限制，而不是算法，过程和类型的限制。至于组成，建筑的是粗粒度的，设计的是程序上的精细结构。体系结构中组件之间的交互作用与高级协议（从非技术意义上来说）有关，而设计中的组件则涉及过程类型的交互作用（消息，例行调用）（Perry，1997）。

因此可以得出结论，软件体系结构不是软件设计，因为它发生在项目开发的较早阶段，具有较高的抽象水平，涉及组件，连接器，配置，限制，从而使设计更加详细下层，更精细的架构元素，例如：过程，算法和数据类型。

软件体系结构的抽象级别

1.3.1。 建筑风格

1.3.1.1。风格分类

有多少种样式？

在Mary Shaw和David Garlan（Garlan等，1994）进行的研究中，他们提出了以下分类法，其中以前称为“架构”的东西与“设计模型”混合在一起：

1. 管道过滤器数据抽象和面向对象的组织隐式，基于事件的调用分层系统存储库面向表的解释器分布式过程。分布式过程的一种特殊形式是，例如，客户端-服务器体系结构，主程序/子例程组织，特定领域的软件体系结构，状态转换系统，控制过程系统，异构样式。

在Bass，Clements和Kazman撰写的基本软件实践中（Bass等，1998），提供了五组样式类的系统化信息：

• 数据流（数据移动，无需接收者控制“上游”内容）
  • 顺序批处理数据流网络管道过滤器
  调用和返回（计算为主的样式，通常具有单个控制线程）
  • 主程序/子例程抽象数据类型对象基于呼叫的客户端-服务器分层系统
  独立组件（由独立进程之间的通信模式主导，几乎总是并发的）
  • 面向事件的系统通信流程
  以数据为中心（由复杂的中央存储控制，由独立的计算操作）
  • 储存库黑板
  虚拟机（通过将指令转换为其他指令来表征）
  • 口译员

与样式不同，样式很少，并且分为样式类，在调查过程中假定了最新，最简洁的分类（Reynoso，2005年）：

• 数据流样式
  • 管道和过滤器
  以数据为中心的样式
  • Slate或存储库体系结构
  通话和退货方式
  • 模型-视图-控制器（MVC）分层体系结构面向对象的体系结构基于组件的体系结构
  移动代码样式
  • 虚拟机架构
  异构样式
  • 过程控制系统基于属性的体系结构
  点对点样式
  • 基于事件的架构面向服务的架构（SOA）基于资源的架构

1.3.1.2。最受欢迎的款式

在1960年代和1970年代，根据要提供的功能服务来构建应用程序是很自然的。实际上，诸如分析和结构化设计之类的方法是从分层的功能分解开始的，然后将其分解为应用程序中的过程。随着应用程序复杂性的提高以及对它们的发展的需求，这种方法还不够。在80年代和90年代，面向对象的软件开发变得很流行，除其他目标外，其目的是允许构建更可维护的应用程序。 （Casallas等，2005）

今天，对象似乎还不够，不是因为它们不再是好东西，而是因为问题已经改变。这些变化是技术进步和客户期望提高的结果。例如，非功能性功能变得越来越关键，应用程序集成问题已成为当务之急。必须具有灵活的架构，并尽可能独立于所使用的工具。在（附件1）中，显示了多年来系统的体系结构如何演变。

• 面向对象架构

可以通过几种方式来了解这种类型的架构，包括：基于对象的架构，数据抽象和面向对象的组织。

这种样式的组成部分是对象，或者是抽象数据类型的实例。在大卫·加兰（David Garlan）和玛丽·肖（Mary Shaw）的经典表征中，对象代表了一类被称为管理器的组件，因为它们负责维护自己表示的完整性。这方面的重要特征是无法从其他对象访问对象的内部表示。（Garlan等，1994）

根据Billy Reinoso（Reynoso等人，2004年）的说法，如果要总结面向对象体系结构的特征，可以这样说：

• 样式的组成部分基于OO原则：封装，继承和多态。它们还是建模，设计和实现的单元，对象及其交互是设计应用程序的体系结构和结构时要关注的中心，而接口与实现是分开的。通常，对象的分布是透明的，并且在技术水平上，对象是本地的还是远程的都无关紧要。分布式系统面向对象的最佳示例是通用对象请求代理体系结构（CORBA），其中使用接口描述语言（IDL）定义了接口；对象请求代理中介了分布式环境中客户端对象和服务器对象之间的交互。是否可以通过多个类实现接口是可以承认的。样式有很多变体。例如，某些系统允许对象成为并发任务；其他允许对象具有多个接口。

优点：

• 您可以在不影响对象客户端的情况下修改对象的实现对象是开发环境中的可重用实体

缺点：

• 为了通过过程调用与另一个对象进行交互，必须知道其身份。对于大型系统来说非常好。分层架构

Garlan和Shaw将分层样式定义为一种分层组织，以便每一层都向直接上一层提供服务，并利用直接下一层提供的好处（Reynoso等，2004）。（见附件2）

在分层样式中，连接器由确定交互形式的协议定义。拓扑样式约束可以包括或多或少的严格限制，它要求每一层只能与相邻层一起操作，并且一层的元素只能与其他元素一起理解；如果这种需求得到放松，则样式应该不再是纯粹的，并且会失去其启发式功能（MSDN，2004）；自然地，更换层而不影响其余部分的可能性也自然地丧失了，从而降低了组件的灵活性并使其维护复杂化。

有时有人争辩说，过度跨越许多层次会导致最终的性能下降。但是，更多次要精确地牺牲分层体系结构的纯度来改善它：例如将业务规则放置在数据库的存储过程中，或者将查询指令表达在用户界面层中。

优点

• 模块化（在某种程度上）支持基于不断提高的抽象水平的设计，这反过来又允许实现者将复杂的问题划分为一系列递增的步骤，提供广泛的重用性，轻松地支持系统演进；更改仅影响相邻层，可以在尊重与相邻层的接口的同时更改实现。

缺点

• 很难先就所需的分层进行推理，层之间的通信的格式，协议和传输通常是特定且专有的，并非所有系统都可以分层。基于组件的架构

当前，在软件开发中，非常需要利用现有软件的部件或模块的重用，其可用于生成应用程序或整个应用程序的新扩展。在谈论工程流程中的重用时，“组件”的概念非常隐含，因为可以用来构建应用程序的软件有效部分被称为“软件组件”。

该术语（软件组件）有几种定义：

• 根据Krutchen的说法，组件是系统的重要组成部分，几乎是独立且可替换的，可以在定义良好的体系结构内实现功能。组件符合一组接口并提供它们的物理实现。 （Brown等，1998）。卡内基梅隆大学软件工程学院（SEI）制定了一个定义，目的是为了统一关于软件组件应该是什么的不同观点：“组件是一种实现。功能不透明，受第三方组成并符合组件模型的约束（Bachmann等，2000）。根据Szyperski的说法，软件组件是具有合同规定的接口且仅具有显式上下文相关性的组成单元。一个软件组件可以独立部署，并由第三方来组成。 （Szyperski，2002）。

可以看出，大多数定义都围绕组件的本质而定，组件是软件工件的实现，该软件工件执行由服务发布的一个或多个功能，被视为一组接口，并提供对组件的物理实现。他们。

特点：

组件的最重要特征之一是它们是可重用的。为此，组件必须至少满足以下特征集：

• 可识别的：组件必须具有清晰一致的标识，以便于对其进行分类和在组件存储库中进行搜索。仅可通过其接口访问：该组件必须仅向公众公开表征其（接口）的操作集并隐藏其实现细节。此功能允许将一个组件替换为另一个实现相同接口的组件。服务是不变的：组件通过其接口提供的操作不得改变。这些服务的实现可以修改，但它们不应影响接口。已记录：组件必须具有足够的文档，以方便其在组件库中进行搜索，评估，适应新环境，与其他组件集成以及访问支持信息。

相对于面向对象的样式，组件样式的主要评估突出了其相对于对象模型的更大的通用性，但是其适应性也较低（Reynoso等，2004）。

优点：

• 软件重用。这会导致更高级别的软件重用。简化测试。它允许在测试整套组装好的组件之前通过测试每个组件来运行测试。简化系统维护。当组件之间的耦合较弱时，开发人员可以根据需要自由更新和/或添加组件，而不会影响系统的其他部分。更高的质量。由于可以由专家或组织来构建然后不断改进的组件，因此基于组件的应用程序的质量将随着时间的推移而提高。

缺点：

• 如果不存在这些组件，则必须开发它们并浪费大量时间，并且如果这些组件中出现新版本，这些组件可能会发生冲突，则可能必须重新实现这些组件。掌握在系统开发人员手中。面向服务的体系结构（SOA）

面向服务的体系结构（SOA）由松散耦合且高度可互操作的应用程序服务组成。为了彼此通信，这些服务基于独立于平台和编程语言（例如WSDL：Web服务描述语言）的正式定义。接口定义封装了实现的特殊性，使其独立于制造商，编程语言或开发技术（例如Java或.NET）。

通过这种体系结构，开发的软件组件具有很高的可重用性，因为该接口是根据标准定义的；因此，Java应用程序可以使用CSharp开发的服务。

SOA的最突出特征之一是它基于合同，提供商在合同中建立通信规则，运输规则以及将由双方交换的道路和出口数据。要查看更多SOA特性，请参阅（附件3）。

什么是SOA？

• SOA是一个概念性体系结构，将业务功能组织为可互操作的服务，允许重用服务以满足业务需求； SOA基于标准；制造商独立性； SOA是企业级IT战略。

SOA是一种体系结构样式，其中要构建的系统的业务流程以封装这些流程并可以通过定义明确的接口调用的独立的高凝聚力和低耦合服务的形式公开。

什么不是SOA

因此，SOA不是：

• 项目开发方法，业务架构方法。

SOA作为一种建筑风格

• 组件：ServiceConnectors：以前，RPC-现在，消息传递配置：分布式限制（约束）：低耦合，编程模型独立性，平台独立性，根据行业协议的传输和协议

优点

• 改善决策。
  • 统一全景。质量更高的更多信息。
  提高员工生产力。
  • 最佳访问系统。不受ICT限制
  加强与客户和供应商的关系。
  • 对客户的响应速度更快。
  更高效，更灵活的应用程序；更安全，更易管理的应用程序。

缺点

• 由于网络通信，消息大小等原因，通话时间不可忽略。这必然意味着要使用可靠的消息传递服务的响应直接受到外部问题的影响，例如网络问题，配置问题等等，它必须处理不可靠的通信，不可预测的消息，重试，消息不按顺序等等。

1.3.2。 建筑图案

有一个广泛使用的分类，分为两个最广泛的体系结构模式系统，它们是相同的：面向模式的软件架构（POSA）（Buschmann等，1996）和企业应用程序体系结构（PEAA）。 （Fowler等，2002）。

POSA类别

在POSA体系结构模式参考书中，模式划分如下：

• 从泥浆到结构：这些模式有助于避免大量的组件或对象。特别是，它们支持将系统任务分解为协作的子任务。分布式系统交互式系统自适应系统

在（附件4）中，列出了列出类别中的POSA模式的分布，然后在（附件5）中，显示了其中一些模式的简要说明。

PEAA类别

在PEAA中（Fowler等，2002），他们描述了许多面向业务应用程序架构的模式。

在PEAA中，定义了以下类别的模式：

• 分层：将系统划分为多个层的模式。域逻辑的组织：组织域对象的方式。映射到关系数据库：与域逻辑和数据存储库之间的通信有关。包括对象模型和关系数据库之间的映射。Web演示：Web演示是近年来业务应用程序必须克服的挑战之一。 Web瘦客户端具有许多优点，其中一项主要优点是易于分发（不必在客户端计算机上安装软件）。此类别包括用于管理Web演示的一系列模式。 （Welicki，2007年）并发：并发管理。当今基于Web的应用程序具有很高的并发管理需求。会话状态：Web服务器上的会话管理模式。分发策略：根据客户的经验知识，在多个位置分发对象。

在（附录6）中，显示了PEAA中定义的模式在上面暴露的类别中的分布。

“建筑模式”和“建筑风格”这两个术语经常被混淆，许多该学科的学生似乎对此尚不清楚。为了在建筑风格和建筑模式之间进行清晰的比较，（附件7）提出了这些概念的一些差异，这些差异是建立在该方法的基础上的（Buschmann等，1996）。

1.3.3。 抽象级别之间的关系

在（附件8）中，显示了建筑风格，建筑模式和设计模式的概念之间的抽象关系。

样式和模式可以帮助架构师定义软件系统的组成和行为，并且它们的适当组合可以满足质量要求，从而使软件系统可以持续构建。

但是，软件系统的组织必须对参与系统开发的所有人员可用，因为它在软件系统之间建立了通信机制。这是通过以不同的方式表示体系结构来实现的，从而获得对体系结构的描述，以便所有相关人员都可以理解和分析体系结构，从而获得质量体系。这些描述可以通过架构视图，UML等符号和架构描述语言来建立（Bengtsson，1999）。

通过不同抽象级别的体系结构视图突出了涉及开发人员的各种问题。因此，分析架构的这些观点以及它们如何帮助所有参与开发过程的人员推理系统的质量属性是很有趣的。

1.3.4。 构架

在1.2.1.4节中，给出了关于什么是框架的简短定义，因此本节将尝试解决更多有关框架的问题。

框架追求的主要目标是：加快开发过程，重用现有代码并促进良好的开发实践，例如使用模式。

框架用户的工作，一方面必须选择，实例化，扩展和重用其提供的组件，另一方面，通过开发必须与框架耦合的特定组件来完善框架的体系结构，从而实现根据框架施加的结构性限制开发不同的应用程序。

使用框架有什么好处？

通过使用标准衍生而来的；其中：

• 程序员不需要考虑应用程序的全局结构，但是框架提供了必须“填充”的框架。这使协作更加容易。任何不得不与另一个程序员的源代码或什至与他自己的源代码作斗争的人都将知道理解和修改它是多么困难；因此，定义和标准化的任何内容都可以节省协作开发的时间和工作，更容易找到适合特定框架的工具（实用程序，库）以促进开发。

尽管使用框架是开发软件系统的一种好习惯，但这并不意味着必须使用（无论是否已知）或类似的东西。这将取决于项目的规模以及开发团队和架构师的经验。

根据安全编程的原则之一，为什么不使用已经定义的框架，并利用其他开发人员的工作优势；换句话说，为什么要重新发明轮子呢？如果您有经过测试，可以运行且正在运行的产品，则无需执行相同的操作，这不是很有用，只会带来诸如浪费时间的复杂性。

确实，使用框架意味着一定的初始成本（学习曲线），但是从长远来看，这在软件项目的开发过程中是可以得到补偿的。

SOA：当前的挑战

面向服务的体系结构是一种软件体系结构概念，它将服务的使用定义为应用程序开发的基本结构。它是一种应用程序体系结构，其中功能定义为独立的服务，具有可访问的，定义明确的接口，可以按给定的顺序调用这些接口以形成业务流程。

SOA已成为应对用更少的资源做更多事情的挑战的最佳方法。它有望使重用和集成变得更加容易，从而有助于减少开发时间并提高组织敏捷性。毫不奇怪，80％的IT组织正在使用带有基础Web服务的SOA来部署应用程序。SOA提供了更大的灵活性来应对业务环境和技术基础架构的变化”（Reynoso，2005年）。

全球信息技术（IT）行业研究和分析的领先提供商Gartner在2003年指出：“到2008年，SOA将成为软件工程的主流实践，从而结束单片架构40年的主导地位。 （概率0.7）”（Natis，2003年）。

1.4.1。 使用SOA的理由

公司采用SOA方法的原因有很多，更具体地说，是基于Web服务的SOA方法：

• 重用：更改SOA的基本因素是业务服务的重用。公司内部以及与业务伙伴之间的业务功能可以作为Web服务公开，并可以重复使用以满足新的业务需求。互操作性：松散耦合的体系结构的目标是使客户和服务进行通信，而无论它们驻留在哪个平台上。具有Web服务的通信协议独立于平台，编码语言和操作系统，从而促进了与业务伙伴的通信。可扩展性：由于SOA服务是松散耦合的，因此使用这些服务的应用程序可以轻松扩展。这是因为客户端应用程序与其使用的服务之间几乎没有依赖性。灵活性：这是另一个功能，可提供服务之间的弱耦合。只要保持接口不变，对它们之一的实现的任何更改都不会影响其余部分。成本效率：SOA体系结构基于公开要重用的现有服务。通过使用Web服务公开这些服务，几乎所有组织都可以重复使用现有的Web基础结构，从而极大地限制了成本。

1.4.2。 SOA元素

此体系结构提供了一种构建分布式系统的方法，该系统为应用程序提供功能，作为最终用途应用程序或其他服务的服务。

附件9显示了在面向服务的体系结构中可以观察到的元素。在其中，可以区分两个领域，一个领域涵盖体系结构的功能方面，另一个领域涵盖服务质量的方面。下面简要介绍了这些元素（Endrei等，2004）：

• 特征
  • 传输：是一种机制，用于将服务需求从服务使用者传递到服务提供者，并将响应从提供者传递到使用者。服务通信协议：这是一种约定的机制，服务提供商和服务使用者可以通过该机制来传达正在请求的内容和正在回答的内容。服务描述：这是一个约定的架构，用于描述服务是什么，应如何调用它以及成功调用该服务需要哪些数据。服务：描述当前可以使用的服务。业务流程：是按特定顺序使用一组特定规则调用的服务的集合，以满足业务需求。服务注册中心：是服务描述和数据的存储库，服务提供者可以使用它们来发布他们的服务，以及服务使用者可以发现或找到可用服务。
  服务质量
  • 政策：服务提供者向消费者提供服务的一组条件或规则。安全性：这是一组规则，可用于识别，授权和控制对服务使用者的访问。事务：是可以应用于一组服务以提供一致结果的属性集。管理：是一组属性，可用于管理提供或使用的服务。

SOA协作遵循发布，发现和调用范式，在此范式中，服务使用者通过查询服务注册表以找到符合特定条件的服务来动态定位服务。如果该服务存在，则注册表为消费者提供合同界面和提供者服务的地址。（Endrei等，2004）

附件10展示了协作的面向服务架构中的实体（角色，操作和工件）。

（附件10）中图表所示的每个实体都可以充当消费者，供应商和/或注册机构的角色：

• 甲服务消费者是一个需要服务的应用程序，软件模块，或其他服务，并且执行该服务根据一个接口协议。甲服务提供商是接受并执行查询的网络可寻址实体。消费者，并在服务注册表中发布其服务及其接口协定，以便服务消费者可以发现和访问服务。服务注册表负责使服务的发现成为可能，其中包含服务库并允许感兴趣的用户查看服务提供商的界面。

操作是：

• 发布。为了访问服务，必须发布其描述，以便消费者可以发现并调用它。发现。服务使用者通过咨询服务注册表来找到符合特定条件的服务。绑定并召唤。一旦获得了消费者对服务的描述，消费者就会根据服务描述中的信息来调用它。

最后，面向服务的体系结构中的工件是（Alvez等，2006）：

• 服务。可以通过发布的界面使用并且可以由服务使用者调用的服务。服务说明。服务描述指定服务使用者如何与服务提供者交互，并指定服务的查询和响应格式。该描述还可以指定一组前提条件，后置条件和/或服务质量。

综上所述，可以得出结论，这种类型的体系结构的基本元素是服务，但仅使用该设备无法设计SOA。要形成SOA，基本上需要将操作，服务，消息和业务流程结合在一起。

1.4.2.1。服务种类

• 核心服务：它们可以集中于数据或逻辑，并封装诸如复杂的计算，数据访问和复杂的业务规则之类的功能。中介服务：适配器服务，外墙等 它们通常是无状态服务。流程服务：封装流程逻辑的业务服务。它们倾向于保留状态，并且可以驻留在BPM工具中。公共服务：第三方（组织外部）可以访问的服务。

一个业务服务是可重用的软件组件，具有全功能的意义，它是由（见附件11）：

• 合同：目的，功能，使用形式和服务限制的规范。接口：向用户公开服务的机制。实现：必须包含逻辑或数据访问。

1.4.3。 网络服务

与面向对象的体系结构相反，面向服务的体系结构由高度可互操作且松散耦合的应用程序服务组成。这些服务可以看作是分布式组件的复杂性的演变，而它们之间却有所不同（Alvez等，2006）：

• 与客户端应用程序相比，与组件的耦合要少得多；与组件相比，粒度要小；它们不必作为端到端应用程序的一部分进行设计和实现；它们是独立控制和管理的；通过开放协议公开其功能。和平台无关。即使冒着性能和资源消耗的风险，它们在网络上的位置也是透明的，从而确保了可伸缩性和容错能力。

通常，服务包括业务逻辑和数据管理，这与解决它们所针对的问题有关。服务作为独立的应用程序工作，具有自己的业务规则，数据，管理和操作过程，可伸缩性，安全性，容错能力，异常处理和配置策略。它使用基于消息的界面公开其所有功能，因此与服务的通信是通过消息而不是方法调用完成的。这些消息必须包含或引用所有必须理解的信息。

Web服务与应用程序进行通信，无论信息的创建方式，运行的操作系统或平台以及用于访问它们的设备，都可以共享信息。通信的特征是交换XML消息并独立于通信协议。为了实现这种独立性，由于创建了SOAP传输协议（简单对象访问协议：简单对象访问协议），因此针对每种协议将XML消息适当包装。（Alvez等，2006）

以XML表示的Web服务描述语言（WSDL）描述了如何访问该服务，其具有的功能，所需的参数以及每个参数返回的内容。

涉及的另一个基本技术是通用描述，发现和集成（UDDI：通用描述，发现和集成）。UDDI是Web服务的目录，您可以在其中发布提供的服务，提供服务类型的特征以及执行搜索。

总而言之，SOAP为服务之间的基本互操作性定义了XML协议，WSDL引入了描述服务的通用语言，UDDI提供了以编程方式发布和发现服务所需的基础结构。这些规范一起使应用程序可以按照与基础平台无关的松耦合模型进行交互。

1.4.3.1。相关技术

WSDL

Web服务描述语言由Microsoft，IBM和Ariba于2000年9月诞生，构成了Web联盟（W3C）的服务描述标准，W3C是指导Web开发的组织。（Endrei等，2004）

本质上，WSDL是服务提供商与客户端之间的合同，服务提供商据此指出（Alvez等，2006）：

• 可以调用哪些功能这些功能使用什么类型的数据将使用什么传输协议来发送和接收消息（通常但不仅限于SOAP消息）如何访问服务。本质上，使用什么URL来使用服务。

肥皂

这是用于在分布式和分散式环境中交换结构化信息的简单协议。它定义了不同进程中的两个对象如何通过XML数据交换进行通信。它使用XML通过提供可以通过各种基础协议交换的消息格式来定义可扩展的消息传递框架。该框架被设计为独立于任何编程模型或任何实现的任何特定语义（W3C，2007）。

SOAP使用XML的事实具有其优点，例如易于人们理解，但同时它也具有缺点，因为消息较长。

UDDI

它是Web服务技术所涉及的一组标准的核心要素。它是中介，通过它可以与服务提供商了解潜在的客户。它定义了一种在SOA上下文中发布和发现服务的标准方法（Alvez等，2006）。

UDDI规范与WSDL规范几乎同时诞生于同一家公司。当前版本是3.0，该规范可追溯到2003年8月，由结构化信息标准促进组织（OASIS）管理。这些规范的实现称为“ UDDI注册”，它通过SOAP提供了一组注册和咨询Web服务。

UDDI记录的功能目的是表示有关Web服务的数据和元数据。UDDI注册中心既可以在公共网络上使用，也可以在组织的内部基础结构中使用，它提供了一种基于标准的机制来对Web服务进行分类，分类和管理，以便其他应用程序可以发现和使用它们。

UDDI中的数据结构

UDDI记录中存储的信息是一组所谓的“ UDDI数据结构”。这些规范中定义的XML结构是客户端将与UDDI注册中心交换的结构。这些结构的每个实例都使用称为通用唯一标识符（UUID）的标识符进行唯一标识（OASIS，2004年）。

主要的高层结构如下（Alvez等，2006）：

• BusinessEntity。它包含公司的基本信息：联系人，根据某些定义的分类法对公司的分类以及公司活动的自然语言描述。PublisherAssertion。公司可以声明与其他公司的关系，例如作为合作伙伴或客户。这些关系中的每一个都被建模为PublisherAssertion。BusinessService。此元素显示公司提供的服务。这些服务可能是也可能不是Web服务。一个BusinessEntity由一个或多个businessService元素组成，一个businessService元素可以由多个BusinessService元素使用。绑定模板。该元素包含对技术描述的引用（例如，指向技术手册的URL）和Web服务的访问URL。每个BusinessService元素可以具有一个或多个BindingTemplate元素。TModel。此元素描述您如何与Web服务及其行为进行交互。其数据中包括WSDL文档所在的URL。可以包含服务的类别也可能会出现在此处（它们可能与BusinessEntity中可能出现的类别有所不同）。

1.4.4。 服务组成

在一个软件系统要完成一个业务流程而必须与其他系统进行交互而不管它们的物理分布和异构性的情况下，面向服务的体系结构将非常有用。

从面向服务的体系结构，更确切地说，从Web服务的使用，出现了一个称为服务组合的新概念。这种组合不仅可以对业务流程进行建模，而且还可以通过数据和应用程序的集成最大程度地发挥SOA的潜力。

服务的组成涉及寻找一种机制，以允许其中两个或多个相互协作以解决超出其个人能力范围的需求。必须满足的一些基本要求是（Alvez等，2006）：

• 与服务的异步交互：为了使创建长时间运行的流程成为可能。服务之间的同步交互：这引入了并行处理，从而大大提高了效率。异常处理：如果多个服务中的至少一个组件发生故障，则该进程可能无法运行。必须考虑错误的发生，并且必须提供处理错误的机制。事务完整性：长时间运行的过程可能最终会失败，在这种情况下，可能需要撤消已经采取的部分操作。

通常用于指代服务之间的协作的两个术语是编排和编排。两者都与构成直接相关，但是专注于服务之间交互的互补方面。

编排

当流程由单个实体完全控制时，可以将其视为服务编排。此过程完全定义了与组件服务的交互以及正确进行这些交互所需的逻辑。可以将这种类型的过程理解为私有的和可执行的，因为只有正在编排流程的实体才知道控制流程以及遵循正在编排的流程的信息。以这种方式，创建了一个使用不同服务的过程，处理了在它们之间流动的信息，例如将某些服务的输出数据转换为另一服务的输入数据。在这里，每个参与实体都实施和控制自己的流程（Cubillos等，2004）。

编舞

当流程定义了任何类型的组件应用程序之间的协作时，便是服务的编排，而与定义它们的语言或平台无关。编舞过程不受单个参与者的控制。与编排不同，编排可以看作是公共的，不可执行的过程。公开的，因为它定义了所有参与实体都必须知道的公共行为，而不是可执行的，因为它被更多地看作是规定规则的业务协议，以便这些实体可以彼此交互（Cubillos等，2004）。 。

1.4.5。 SOA和Web服务

SOA经常被误解，并与Web服务相混淆。 SOA是一种系统设计方法，它指导如何集成技术资源以及公开哪些服务。反过来，Web服务是一种使用特定标准和语言协议来执行SOA解决方案的实现方法。

面向服务的体系结构是一种设计和构建松耦合软件解决方案的方法，该解决方案将其业务功能公开为可通过编程访问的软件服务，以供其他应用程序通过发布接口使用。Web服务表示面向服务的体系结构的实现，但并非所有SOA应用程序都可以视为Web服务，例如表示状态转移（REST）的情况。

尽管如此，Web服务仍是当前的技术，并且显然是将要保留的技术。实际上，WSDL仍在继续发展，与描述语言无关的与Web服务有关的所有技术仍在以非常快的方式进行发展。

另一方面，面向服务的体系结构是一个比Web服务更广泛的概念，尽管这些是当前的实现。

如果（Reynoso，2005），Web服务就是SOA：

• 这些接口基于Web协议（HTTP，SMTP，FTP）。消息基于XML。

1.4.6。 SOA成熟度模型

什么是成熟度模型？

• 它允许测量有关SOA使用的业务体系结构的当前状态，并允许建立演进路径。

为什么要建立成熟度模型？

• 支持包括良好实践在内的分层学习，形成沟通和扩展功能的基础，帮助构建行程，形成创建增量SOA采用的基础

本节中提出的成熟度​​模型包括五个级别：启动程序服务，体系结构服务，业务服务，协作，业务指标和业务优化。这些级别将允许扩展SOA的利润，因为在这种类型的体系结构中，SOA的利润从少到多（请参见附件12）。该成熟度模型由Progress Software Corporation提出，Progress Software Corporation是一家致力于提供包括SOA和集成基础结构在内的业务应用程序平台的著名软件公司。它在软件市场上拥有公认的产品：SONIC ESB等。

ADL和UML

ADL

架构描述语言（ADL：Architecture Description Language）使您可以在对构成架构的应用程序进行编程之前对其进行建模，分析其适当性，确定其关键点并最终模拟其行为。它们在软件体系结构的学术界得到了很好的认可，但是它们似乎并没有在工业实践中得到相同的认可，因为它们没有在其软件项目中使用。

这些提供了用于指定体系结构抽象和机制的结构，以将系统分解为组件和连接器，指定这些元素如何组合以形成配置并定义体系结构或样式系列。（Reynoso等人，2004年）

ADL的特征在于它们提供给用户的抽象，并且这些语言提供的大多数视图主要包含体系结构信息，而该语言提供的分析则基于体系结构级别的信息。

ADL提出的一些优点是：

• 可以描述行为及其相关元素，例如事件产生的类型或事件的响应类型，包括高级描述或文档，可以轻松输入和维护有关系统的信息。可以根据需要对它们进行优化，以进行不同类型的分析。

尽管有上述所有规定，但可以说ADL很方便，但尚未证明是必需的，特别是由于UML的永久性（现在为2.0版）（Reynoso等，2004）。

统一语言

统一建模语言（UML）专门用于构建，指定，可视化和记录在面向对象软件系统软件开发过程中出现的元素。它由各种图形元素组成，这些图形元素组合在一起形成图表，并且由于它是一种语言，因此具有组合这些元素的规则。它提供了对类，关系，交互行为，包装等的支持。这些元素可以用该语言提供的各种图表来表示，这些图表是：类，对象，用例，序列，协作，状态，活动，组件和开发。

尽管根本没有资格成为ADL，但事实证明，它本身并不能用作ADL，而可以用作模拟其他ADL的元语言，尤其是C2和Wright（Reynoso等，2004）。

在UML中，它们标识：

• 元素（构成基本构建基块的抽象）关系（链接元素）图（一组元素的图形表示）

UML为描述硬件中的软件组件的投影提供了一种表示法，它与用于描述软件体系结构的Kruchten 4 +1模型的物理视图相对应（Kruchten，1999）。

在UML中，支持与软件体系结构相关的某些概念，例如组件，软件包，库和协作，因此可以说，可以使用UML对体系结构的基本元素进行很好的建模。但是对于架构的总体表示，将需要其他工具和语言，因为总体表示不仅是其组件之间存在的通信，还必须记录并证明为实现良好的架构设计所做的一切。

软件架构质量

要构建的软件系统的软件体系结构，成为确保其具有高质量水平的重要因素。具有良好的软件体系结构至关重要，因为这是所有软件系统的核心，并决定与系统相关的质量级别。

从以上内容可以推断出，评估体系结构的目的是要知道体系结构是否可以满足要求，质量属性和限制，以确保要构建的系统满足利益相关者的需求以及达到何种程度。除了分析和识别其结构和属性中的潜在风险外，这可能会影响最终的软件系统。

应当指出，非功能性需求也称为质量属性。质量属性是影响项目的质量特征。“特征”一词是指非功能性方面，而“元素是指组件”（Gómez，2007）。

评估技术

有一组评估技术，可以分为定性和定量技术（Brey等，2005）（见附件13）：

• 质疑或定性技巧。他们使用定性问题来询问建筑
  • 打开。早期特定于应用程序域特定于系统。先进的架构。
  测量技术。他建议对建筑进行定量测量。
  • 使用架构指标，例如耦合，模块凝聚力，继承深度，可修改性，模拟，原型和实验

通常，在架构构建过程中使用定性评估技术，而在架构已经实施时使用定量评估技术（Gómez，2007）。

可以评估什么素质的体系结构？

从广义上讲，Bass在两个类别中建立了质量属性的分类（Camacho等，2004）：

• 通过执行可观察：由系统在运行时的行为确定的那些属性。（附件14）中提供了其中一些属性的描述。通过执行不可观察：在系统开发期间建立的那些属性。（附件15）中介绍了其中一些属性。

评估体系结构会产生什么结果？

评估完成后，必须准备报告。必须将其作为初步文件提供，以便参与评估的人员对其进行更正。报告的内容回答了两种类型的问题（Gómez，2007年）：

• 是否为系统设计了最合适的体系结构？哪种提议的体系结构最适合要构建的系统？

除了回答这些问题之外，该报告还指出：

• 满足质量属性的程度要评估的体系结构所需的质量属性的优先列表风险而非风险

如今，有几种评估软件体系结构的方法可以验证是否符合某些质量属性，有些方法比其他质量属性更为具体，例如：体系结构折衷分析方法（ATAM），博世（Bosch） （2000），主动设计审查（ADR），中间设计的主动审查（ARID），Losavio（2003）。

还有其他评估特定质量属性的体系结构评估方法，例如：体系结构级别可修改性分析（ALMA），软件体系结构性能评估（PASA），基于场景的体系结构级别可用性分析（SALUTA）和可生存网络分析（SNA） 。

不管评估方法有多具体，大多数都具有共同点：场景技术被用作一种验证架构在多大程度上响应系统所需质量属性的方式。

一种评估方法并不比另一种评估方法好，而是在一定条件下评估给定的质量属性。因此得出的结论是，取决于条件和要评估的内容，这将是所使用的评估方法（不必只是一种）。

软件体系结构和质量属性之间的关系

在任何软件系统的开发过程中，都会做出架构设计决策，以实现某些特定的质量属性。为此，架构师必须经常质疑此决定对其他质量属性的影响。

纳入软件体系结构的每个决策都可能影响质量属性（Bass等，2000）。因此可以说，做出这样的决定通常会产生以下后果：

• 提出论据以解释决策如何实现建议的质量属性，以及有关决策对其他质量属性的影响的问题。

质量属性和软件体系结构之间存在的关系有几个好处（Camacho等，2004）：

• 一旦架构师了解架构组件对架构的一个或多个属性的影响，架构师便可以重用现有的分析并明确地确定协议，而不是即时地制定协议，从而极大地增强了架构分析和设计的流程。质量，则可以在必要时将一组组件替换为另一组组件，一旦对架构和质量属性之间的关系进行了编码，就可以构建一个测试协议来启用第三方认证。

部分结论

根据本章提出的目标，可以得出以下结论：

在本章中，整个学科的主要方面都已暴露出来，例如：主要定义的概念，当前趋势，业务应用程序世界中最新和最流行的样式，并揭示了它们的特性，优点和缺点。分析了诸如以下概念的架构模式和架构抽象级别：架构风格和框架。还讨论了诸如软件体系结构中的质量之类的主题，这些主题定义了主要的质量属性和方法，这些属性和方法用于验证体系结构在多大程度上符合已建立的质量参数。以同样的方式，面向服务的体系结构被分析为当前最大的指数，可以将其应用到解决方案提案中，因为面对当今公司不断变化的业务变化以及易于集成的情况，它将为系统提供更大的灵活性。提供了这种类型的架构。

业务伙伴：公司或公司的共同所有者的个人或公司，换句话说，是公司或公司一部分的合伙人。

下载原始文件