在使用 Rational Unified Process (RUP)——被认为是支持迭代软件开发的分析与设计的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要价值。然而，RUP 以 OOAD 的原则为基础，因而使其不容易与 SOA 设计保持一致。从 RUP 的角度来看，系统的体系结构是其通过已定义接口交互的主要组件的体系结构。此外，这些组件还由逐渐减小到类级粒度的更小组件组成。相反，在 SOA 中，系统的体系结构通常包括满足普通业务服务需要的无状态、全封装且自描述的服务组成，它更接近于映射到 BPM，如图 5 所示。
图 5. SOAD 服务定义层次
这些服务可能包括许多协作或编排服务。这并没有排除 RUP 采用的 OO 观点，而是在其上实现了另一个抽象层。这个超层的作用是封装作为正式的跨层接口结构中的 RUP 构件（软件服务）设计的组件。
SOAD 原理
在这一部分中，我们将更详细地描述 SOAD 的需求，并且开始确定它的主题和原理。目的是将关于这个主题的讨论引到进一步的设计工作。进一步的工作无疑需要形式化 SOAD 方法。
SOAD 必须提供什么？
已经为 SOAD 确定了下列需求：
正如任何其他的项目和方法一样，必须正式（至少半正式）地定义流程和表示法。通过选择和组合 OOAD、BPM 和 EA 原理，就可以在需要时确定额外的原理。
必须有结构化的方法来概念化服务：
OOAD 为我们提供了应用程序层上的类和对象，而 BPM 具有事件驱动的流程模型。SOAD 需要将它们结合在一起。
方法不再是面向用况的，而是由业务事件和流程驱动的。用况建模是在更低的层次上作为第二步进行的。
方法包括语法、语义和策略。这就需要特别的组合、语义代理和运行时发现。
SOAD 必须提供定义良好的品质因素和最佳实践（例如回答粒度问题）。必须回答 BPEL 提出的角色问题。例如，谁为哪部分工作负责：是开发人员、架构师，还是分析人员？
SOAD 活动还必须回答这样的问题：什么不是好的服务？例如：不可重用的任何东西都不可能成为好的一流 SOA 成员（即服务）。另一个例子就是带有挑战性的非功能要求的嵌入式实时系统，它们不能承受任何 XML 处理开销。
SOAD 必须易于进行端到端建模，并且有全面的工具支持。假如 SOA 给业务带来了灵活性和敏捷性，就应该对从企业到体系结构和应用程序设计领域产生的支持方法有相同的期望。
品质因素
一些通用原则或品质因素已经确定，并且可以作为 SOAD 中的设计基准：
构思良好的服务给业务带来了灵活性和敏捷性；它们通过松散耦合、封装和信息隐藏使重构更加容易。
设计良好的服务是有意义的，并且不只适用于企业应用程序；服务之间的依赖性减到最少，并且是显式声明的。
服务抽象是内聚、完整和一致的；例如，在设计服务和它们的操作签名时应该考虑创建（Create）、读取（Read）、更新（Update）、删除（Delete）和搜索（Search）(CRUDS) 隐喻。
常常声明的假定是，服务是无状态的（例如非对话式的）；为了要求服务在特定的问题域和上下文中是无状态的，将削弱这种声明。
领域专家无需深奥的专业知识就可以理解服务命名。
在 SOA 中，所有的服务都遵循相同的设计体系（通过模式和模板连接的）和交互模式；底层体系结构形式可以容易地标识（例如在体系结构复审期间）。
服务和服务使用者的开发除了领域知识之外只需要基本的编程语言技能；中间件专业知识只有少数的专业人员才需要，在理想的情况下，这种知识是为工具和运行时厂商所用，而不是为制作像 SOA 这样的企业应用程序的公司所用。
服务标识和定义
自顶向下的业务级建模技术（如 CBM）可以为 SOA 建模活动提供起点。但是正如我们在前面提到的，SOA 实现很少是在全新的项目中开始的；创建 SOA 解决方案几乎总需要涉及集成现有的遗留系统，方法是将它们分解成服务、操作、业务流程和业务规则
文章来源于领测软件测试网 https://www.ltesting.net/
