模板
教程
环境
性能
功能
管理
用于软件服务的 UML 2.0 Profile
用于软件服务的 UML 2.0 Profile 概述
在IBM Rational Sofware Architect 上实现 profile 的目的是为描述服务提供一个共同语言，该 profile 包括了在开发生命周期内的很多活动并且为不同的涉众提供了视图。例如，该 profile 提供为架构师指定服务的能力――在生命周期的早期――使用逻辑划分来描述整个企业范围的服务组合。这个视图再由设计师来细化，设计师开发服务规约说明――结构上的和行为上的――这个服务规约说明担当服务的客户和实现者之间契约的作用。消息视图为设计师对于公共的服务数据定义提供重用信息模型的能力。
概念模型
下面的图一显示了在建模服务时重要的概念。正如你可以看到的，概念的数目相对较小，而且对于任何从事面向服务的解决方案的人应当相当地熟悉。该图表示的UML 2.0 profile 已经在IBM Rational Sofware Architect 上实现了，被成功的应用于客户复杂场景的建模以及用于帮助人们训练在开发面向服务的解决方案过程中关心的问题。然而，尽管这个profile是该模型的一个实现，在这个profile中注意很多概念不是明显的原型。例如，操作（operation ）或者协议（protocol）就是没有原型，就像UML 2.0中已经有一些概念一样，该 profile 可以进行没有歧义的或者进一步约束的重用。
图一. 对服务建模
被识别的 UML 2.0 子集
表一列出了UML 2.0元模型中在UML profile中用作原型元类的元素。
表一. UML 2.0元模型中的元素
| UML 2.0元类 | 原型 |
| 类 | 消息，服务划分，服务提供者 |
| 分类器 | 服务消费者 |
| 协作 | 服务协作 |
| 连接器 | 服务信道 |
| 接口 | 服务规约说明 |
| 端口 | 服务，服务网关 |
| 属性 | 消息附件 |
profile本身
图二（可以点击）是一个UML 2.0 profile 图。它表明了profile 的实际细节，使用扩展标记（实心的箭头）显示了每一个原型以及它的元类。你可以在该模型中，看到一些约束。尤其是那些在profile元素之间的相互约束。
图二. 一个 UML 2.0 profile图
接下来的部分概述了UML 2.0 profile 现在定义的元素。每个部分略述了一个单个的原型，它的细节详细说明了它的元类、属性以及在使用该profile时应该应用的任何约束。
原型消息
继承自
类（Class）
语义
一个消息代表在 Web 服务描述语言（WSDL）规范中定义的一个概念；即，它是实际数据对服务和消费者有意义一个容器。消息不能有操作，但是它可能有属性和与其他类的关联（很可能是某个领域模型）。一个消息原型具有一个属性来表示它的假定的编码格式（例如SOAP-literal, SOAP-rpc, ASN.1等等）。
属性
表二列出了一个消息原型的属性。
表二. 一个消息原型的属性
| 种类 | 名称 | 类型 | 描述 |
| 属性 | 编码 | 字符串 | 代表了用于产生消息模式的平台编码机制。例如SOAP-literal, SOAP-rpc, ASN.1等等 |
符号
约束
- 不应有任何自己的操作
- 不应有任何自己的行为
原型消息附件
继承自
属性（Property）
语义
这个原型用于表示消息的某些组件是一个该消息的附件（相对于消息的直接部分本身）。总体而言，你不太可能在高级的设计活动中经常使用这个原型，但是对于许多过程，区分附件数据和内嵌的消息数据还是很重要的。例如，一个目录服务可能返回概括的细节作为一个结构化的消息的一部分，但是返回图像作为该消息的附件。这也允许你表示这个图片的编码是二进制的（与主要消息的文本编码方式相对）。
属性
表三列出了消息附件原型的属性
表三. 消息附件原型的属性
| 种类 | 名称 | 类型 | 描述 |
| 属性 | 编码 | 字符串 | 代表了用于产生消息模式的平台编码机制。例如SOAP-RPC, Doc-Literal, ASN.11等等。 |
符号
约束
- 只能用于属于原型为<<Message>>的类的属性。
原型服务
继承自
端口（Port）
语义
该服务模型的元素提供服务交互作用（在Web服务技术中）的一个终点，然而这些交互作用的定义是服务规约说明原型的一部分。在你的模型中，服务不仅识别提供的接口，而且识别需要的接口（例如回调接口）。一个服务拥有附加的属性表示需要使用的绑定，例如SOAP-HTTP, SOAP-JMS等等。
属性
无
符号
约束
- 应该只在原型为<<Service Provider>>的类中使用
- 应该被作为原型为<<Service Specification>>的接口
原型服务信道
继承自
连接器（Connector）
语义
一个信道表示两个服务之间的通讯路径。注意交互作用可能出现在一个信道，但是信道并不表示任何特殊的交互作用。在Web服务世界里，每个服务表示与之相联系的绑定（这样一个客户可以访问它）。在建模一个profile的时候，你要么在服务之间的通信，要么在服务与客户之间的通信来表示绑定。以这样的方式，在理解绑定需求的时候你可以很灵活。
属性
表四列出了一个服务信道原型的属性。
表四。一个服务信道原型的属性
| 种类 | 名称 | 类型 | 描述 |
| 属性 | 绑定 | 字符串 | 表示了用于在 Web 服务描述语言（WSDL）规范中产生服务绑定的平台绑定机制。例如 SOAP-RPC, SOAP-Doc, HTTP-Get等等。 |
符号
约束
- 连接器的至少一端应当连接到原型为<<Service >>的端口
- 连接器的至多一端能够连接到原型为<<Service Gateway>>的端口，一个原型为<<Service Provider>>的类或者<<Service Consumer>>的分类器
原型服务协作
继承自
协作（Collaboration）
语义
服务协作是一种指定一个服务的实现作为一个其他服务的协作的方式。从Web服务的角度来看，这对应于在指定服务实现过程中使用BPEL4WS（Web服务的业务过程执行语言）。所以，这意味着你使用一种服务协作作为服务的行为――如果有意要产生一种类似BPEL的语言――它可能由其他的实现相关的特殊的约束。
属性
无
符号
约束
- 协作参与者应当只应该是原型为<<Service Provider >>的类
原型服务消费者
继承自
分类器（Classifier）
语义
任何分类器（类，组件等等）可能充当服务的消费者，也包括其他的服务。当这个原型是明确的最优的时，它可能帮你识别模型的元素――这不是服务本身－－作为服务的客户。另一方面，它可能仅仅是更高层次的，而你并不需要使用它。
属性
无
符号
约束
无
原型服务网关
继承自
端口（Port）
语义
原型服务网关看起来像一个服务，但是它却只是对划分可用的，而对服务提供者是不可用的。一个网关充当一个代理服务，你可以使用它来协调协议或者表示一个划分上的可以利用的接口。例如，你可能表示――尽管许多服务实在一个划分内实施的――只有某些服务对于划分之外的使用是可用的，因此网关来提供这些服务。这不允许不暴露于网关的从通信到服务的其他服务或者划分。
属性
无
符号
约束
- 应当只用于原型为<<Service Partition>>的类
- 应该被作为原型为<<Service Specification>>的接口
原型服务划分
继承自
类（Class）
语义
一个划分代表系统的某个逻辑或者物理的边界。建模划分是可选的但是有用的。例如，你可以使用划分来表示传统的n层应用中的网络，业务以及数据层。你也可以使用划分来表示更多的物理边界（例如我的主要数据中心、第二站点、客户站点、合作伙伴等等），在这些情况下，划分的跨越可能具有特别的约束，安全方面、允许的协议、带宽等等。
一个划分可能只具有表示嵌套部分的属性，成为服务或者其他的划分。注意这是一个约束――没有其他的元素现在划分内可以被表示。
一个划分的符号也比较严格。如果一个划分表示它和其他所有划分的全部通信必须直接通过指定的网关，那么它被称为是一个严格的划分。
属性
无
符号
约束
- 不应当有任何自己的属性
- 不应当有任何自己的操作
- 不应当有任何自己的行为
- 任何自己的部分应当是原型为<<Service Provider>>的一个类
原型服务提供者
继承自
类（Class）
语义
服务提供者是一个提供一个或者多个服务的软件元素。在建模的术语里，你可能最经常期望见到的一个UML组件。然而，这样的一个约束似乎是武断的，所以为了更大的灵活性，元类被指明作为一个类。一个服务提供者拥有一个属性能够捕捉他的位置信息，尽管它的意思是随具体的实现而定的。该类充当服务提供者可能不直接暴露任何属性和操作：只有公开的端口可能被提供（原型为Service），而且这些事被写入服务规约说明书中的。
位置属性――在实施的时候――或者平台特定的――在生产服务的端点名称时是有效的。例如（有了WSDL），位置可能是http://svc.myco.com/ ， 服务可能被称为CustInfo，在这种情况下服务的端点名字可以生成如下：http://svc.myco.com/CustInfo。
属性
表五列出了服务提供者原型的属性
表五。服务提供者原型的属性
| 种类 | 名称 | 类型 | 描述 |
| 属性 | 允许的绑定 | 字符串 | 表示了允许的平台绑定机制，一个信道可能使用在连接服务中；例子可能是SOAP-RPC, SOAP-Doc, HTTP-Get等等. |
| 属性 | 位置 | 字符串 | 提供者的位置，它可以被生成器用作创端点点的名字。 |
符号
约束
- 不应当有任何自己的属性
- 不应当有任何自己的操作
- 应当有任何自己的行为
- 任何自己的部分应当是原型为 <<Service>>的一个类
原型服务规约说明
继承自
接口（Interface）
语义
对接口的使用表示服务提供的一个操作集合。注意一个服务可能实现多个接口。习惯上，可以将一个协议状态机或者UML2.0 协作附加到这样的规约说明上来表示服务规约说明上的操作调用的顺序。有了这样一个行为的规约说明，任何实现服务相对于不仅是静态的而且是动态的结构和行为的规约说明，都可以是有效的。注意服务的规约说明只能提供公开的操作，而且每个操作应当只能消耗至多一条消息、产生至多一条消息。
属性
表六列出了服务规约说明原型的属性
表六。服务规约说明原型的属性
| 种类 | 名称 | 类型 | 描述 |
| 属性 | 公开的 | 布尔型 | 这个属性表示了服务是否被认为发布到一个服务的存储库中；这和UML中提供的共有/私有的属性是一个不同的概念。 |
符号
约束
- 不应当有任何自己的属性
- 所有的操作都应当被标记为公有的
- 只能被用作原型为 <<Service>> 或者 <<Service Gateway>>端口的类型
