云服务建模方法及工具

现在我们正在设计云服务。在软件工程领域，我们称之为步骤建模。在这一步骤中，我们对企业的业务进行了分析，最后对企业的服务目录进行了整理和设计。这可以帮助我们更好地理解其业务流程，同时也方便了与用户的沟通。建模时，列出当前的业务模型和未来的业务模式。这有助于我们理解业务的哪些方面需要修改。用户和缔约方审查现有的模型，并提出可以反映在未来业务模型中的评论。

（一）服务定义层次结构

在面向服务的体系结构中，映射到业务功能或企业服务的服务是在分析业务流程的过程中定义的。服务可以是细粒度的，也可以是粗粒度的，这取决于业务流程。每个服务都有一个定义良好的接口，通过它可以发现、发布和调用服务。企业可以选择向业务合作伙伴或内部发布其服务。服务也可以由其他服务组成。

SOA是一种与业务流程集成的服务分层体系结构。组件实现服务，并负责提供其功能和维护其服务质量。通过将这些公开的服务组合到应用程序中，可以支持业务流程。使用ESB支持这些服务、组件和流程的路由、中介和转换。

总之，在设计云服务时，有两个主要问题。

流程：通常是对一个或多个服务的调用，以完成业务流程。

服务：可重用的功能块。在服务中，封装了一个单独的函数。服务具有一个清晰的接口，可以由另一个服务或客户端应用程序调用。

（二）统一建模语言（UML）

我们可以使用办公软件（如Microsoft Office）来描述云服务，还可以使用一些建模工具，如Web Sphere Business Modeler、Rational Software Architect等。建模工具提供了比办公软件更多的功能。

服务有不同的用途和用途，软件服务可以不同于业务服务。此外，有时还需要将较小的服务组合成更大的服务。一些工具，如BPEL建模模型，可以用于组合服务。这是办公软件很难处理的事情。此外，服务具有语法、语义和质量特征（例如响应时间）。因此，建模工具可以提供更多的帮助。

统一建模语言是一种流行的建模语言。上述所有建模工具都使用UML。UML由以下三个部分组成。

1.元素

元素是系统中结构或行为特征的抽象。UML定义了四种类型的元素。

·结构元素：描述系统的静态部分。例如：类、接口等。

·行为元素：描述系统的动态部分。新闻等。

·组织元素：用于将多个元素组合成有意义的集合。例如：袋子。

·注释元素：用于注释模型。例如：约束等。

2.关系

关系用于记录元素之间的语义关系。它涉及以下几种。

·依赖关系：对一个元素的更改会影响另一个元素。

·关联：元素实例与另一个元素实例相关联。例如，客户可能在云平台上有多个账户（具有不同的权限）。然后，客户端类可能包含对账户类的引用。在Java中，客户机类包含一个实例变量来引用Account对象。

·继承：一个元素是另一个元素的特定对象。在Java中，扩展关键字用于描述这种关系。

·实现关系：一个元素实现另一个元素的定义。在Java中，这是接口和类，实现用于描述关系。

3.图解

可视化系统的一部分（如上述关系、结构元素、行为元素等）。该图可分为以下几种。(www.xing528.com)

·静态图：描述系统的静态部分。例如：类图。

·动态图：描述系统的动态部分。记录应用程序如何响应外部请求、对象之间的协作以及对象内部状态的更改。例如：时序图。

·功能图：描述系统的功能需求。例如：用例图。

·序列图：描述应用程序的动态结构。它显示了正在运行的应用程序中不同对象之间的交互。对象按某种顺序交换消息，这是应用程序的一个重要部分。在Java应用程序中，消息交换主要通过方法调用完成。在需求分析阶段，可以使用序列图来描述用例。在设计阶段，时序图描述了设计类之间的交互。

在序列图中，生命线由一个盒子和一个向下的虚线组成。框表示一个交互对象，向下虚线表示整个交互过程。一条消息描述了两个生命线之间的交互。消息是从源生命线到目标生命线的箭头，在箭头上方的操作名称指示调用操作，例如在目标生命线上调用方法。操作名称前面有一个序列号，该序列号描述了调用的顺序。实线和箭头描述同步调用，虚线和真箭头描述返回消息。一个称为活动杆的直立矩形框架表示执行的操作。

值得注意的是，建模工具也有一些缺点。例如，它基于面向对象的设计，不容易与SOA设计保持一致。在面向对象的设计中，对象是类粒度。这种粒度级别往往太小。此外，行业中有许多用于需求采纳和分析的工具，如RationalRequisitePro。通过这个工具，需求分析人员可以管理需求，编写用例，等等。

（三）建模步骤

将业务分解成服务不仅仅是一个抽象的过程，它还具有实际意义。

1.识别服务

身份服务（服务标识）相当于传统的需求分析阶段。自上而下的业务建模技术可以为建模活动提供一个起点。我们自上而下地将企业业务分解为功能领域和子系统。然后将功能区域进一步分解为流程、子流程和业务流程用例（业务用户用例）。一般来说，业务处理示例将成为未来的服务。功能区域划分为未来IT子系统的设计设置了服务边界。业务流程的建模过程是将流程分解为多个子流程和操作。例如，订单处理过程分为检查库存和发货。

在构建基于SOA的模型时，必须注意在原有体系结构中对模型进行详细的分析和整理。我们知道面向服务的体系结构是当前和未来应用系统开发的重点，面向服务的体系结构由可互操作和位置透明的组件组成。基于SOA的企业系统架构通常是在现有体系结构的基础上开发的，我们不需要完全重新开发所有子系统；SOA可以通过利用当前系统上的现有资源（开发人员、软件语言、硬件平台、数据库和应用程序）来实现。

SOA是一种适应性和灵活性的体系结构。基于SOA的系统架构可以降低企业系统开发的成本和风险。因此，当我们对一个非常复杂的企业系统进行建模时，首先要考虑的是如何重用现有的投资，而不是替代旧的系统。更换整个系统的成本很高。对于现有的系统，我们通过自下而上的方法将它们分解成服务。我们可以分析现有的系统，看看哪些功能已经存在，可以转换为服务。对于现有功能，我们有以下选项。

将现有功能直接打包到服务中，有两种方法：一是现有职能的实现方式是支持转换为标准服务的服务；二是现有功能不能直接转换为服务。对于后者，可以使用转换器，如消息队列等。

在开发新服务时暂时保留现有功能。完成后，新服务将替换旧功能。

开发一个新服务来调用现有功能。

在标识服务阶段，可以使用许多工具这样做。比如使用SOMA、业务转型分析。此外，在此阶段，我们需要定义业务词汇表集（业务术语表），以提供统一的术语。

2.编制服务规范

编写服务规范是一个传统的设计阶段。在服务规范方面，我们需要做以下工作。

·确定公开了哪些服务。

·确定服务之间的依赖关系。有两种类型的依赖：函数依赖。例如，下订单服务依赖于库存检查服务、运输服务等。另一个关系是处理的顺序依赖关系。例如，必须在传送服务之前调用库存检查服务。

·确定服务、输入消息和输出消息的功能。

3.服务的执行情况

在开发服务之前，这个步骤首先选择服务的接口、开发工具和运行时平台。服务可以通过已经在使用的软件或新开发的软件来完成。在云平台上，我们通常使用Web服务进行集成。除了业务功能之外，还需要考虑服务的安全性、管理和监视。