内容


用 Rational Software Architect 建立面向服务的体系结构(Service-Oriented Architecture)的模型,第 4 部分

用例模型

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 用 Rational Software Architect 建立面向服务的体系结构(Service-Oriented Architecture)的模型,第 4 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:用 Rational Software Architect 建立面向服务的体系结构(Service-Oriented Architecture)的模型,第 4 部分

敬请期待该系列的后续内容。

在您开始之前

了解从本文中可以学到什么,以及如何最大限度的取得收获。

关于本系列教程

本系列教程为您详细介绍了如何使用 IBM® Rational® Software Architect 对面向服务的体系架构进行建模(SOA)进行建模。尽管本系列教程主要是针对软件设计师及其执行的活动,但是它同样有助于软件开发过程中的其他角色,包括那些向软件体系架构提供输入的人员,比如业务分析师,和那些将软件体系架构用作输入以执行他们自己的活动的人员,比如软件设计者和开发者(体系架构认识、设计和执行)。本系列教程同样涵盖了许多核心的 SOA 概念,这些概念对许多读者来说都非常有用。

您将了解到如何做以下3件事情:

  • 体系架构:描述 SOA 是由什么组成的,以及它适用于整个软件开发过程的哪些地方。
  • 服务:为一个使用 SOA 的解决方案设计服务体系架构。
  • 模型:示范 Rational Software Architect 是如何支持模型驱动的开发(MDD)方法的,该方法用于面向服务的体系架构的规范。

在描述了软件体系架构和定义了服务在其中的位置之后,本系列教程随后介绍了 Rational Software Architect 及其与 SOA 和与体系架构相关的特性。

本系列教程通过一个贯穿始终的假想的在线 DVD 租用的案例研究,达到以下三个主要目的:

  • 描述将产品用作服务体系架构活动的输入,包括组建业务模型、业务过程模型、系统用例模型、和设计模型的外部系统部分。
  • 逐步描述服务模型如何展示 Rational Software Architect 中定义的体系架构,包括服务用户、服务规范、服务划分、原子和合成的服务提供者、服务、服务协作、服务交互、和服务信道。
  • 解释服务模型是如何被应用到软件开发过程的后续阶段中的,比如设计和执行阶段。

关于本文

在第 1 部分中,我们引入了录像租用的案例研究,这个例子将贯穿本系列教程的始终。我们将服务体系架构放置在 Rational 统一过程的框架中,并且引入 IBM SOA Solution Stack 作为参考资料。我们注意到不同的工作产品作为服务体系架构的输入,然后使用案例研究来为其中的两个提供例子:业务体系架构模型(在第一部分中以组件业务模型的形式进行描述)和业务过程模型。

在第 2 部分中,我们详细介绍了什么是域模型,以及它如何在 Rational Software Architect 中被表现出来。您开始获得使用工具的第一手经验,并且创建本系列教程中所使用的域模型。

在第 3 部分中,我们解释了如何对面向服务的体系架构的上下文环境中的外部系统进行建模。我们讨论了自底向上的分析以及对接口和组件的建模。

在本部分中,我们将介绍用例模型的相关内容。首先,我们从输入的角度配置和描述用例模型,以及它在您的 SOA 建模过程中的作用。然后,我们描述如何在 Rational Software Architect 中创建模型,以及如何使用不同的用例模型元素对其进行详述。

目标

在完成本教程的学习之后,您将能够:

  • 描述一个用例模型的价值。
  • 生产出一个详细说明参与者、用例和用例流程的用例模型。

必备条件

为了能够从本教程中取得最大的收获,我们建议您(但并非必须)对如下内容有所了解:

  • 面向服务的体系架构(SOA);
  • IBM Rational Software Architect;
  • 统一建模语言(UML);
  • IBM Rational Unified Process® (RUP®)。

重要提示:
我们强烈建议您在阅读本部分之前,阅读本系列教程的前 3 部分。(请点击左上角的“本系列的更多教程”链接。)

系统要求

Rational Software Architect Version 7 (Fix Pack 005 或更新的版本)。

创建用例模型

这是我们在正式进入服务模型之前所回顾的最后一个模型:用例模型。在后面的服务模型中的服务协作和交互建模时,它将作为一个重要的输入。

介绍用例模型

诸如 IBM® Component Business Model™、业务处理过程模型和域模型这样的模型,都是业务级上的模型。然而,系统用例模型(通常简称为用例模型)则是 IT 级上的模型。尽管业务仍然是我们考虑的中心,但是我们的建模内容并不局限在业务上面。特别指出的是,我们将视野扩展到 IT 方面的内容(进一步明确为软件系统)。

用例模型是我们最抽象的 IT 级模型。它从需求的角度看待解决方案,所以我们可能会问:这个解决方案需要支持的下一个行为是什么?通过将需求表现为一组外部活动者和系统之间的交互作用,它被用来详细说明解决方案的黑盒行为。业务处理过程模型提供一组连续的点对点步骤,其中可能包括同一个系统的交互作用、关注这些交互作用的用例模型、以及一个系统需求角度的基于交互作用的视角。

用例模型主要定义了两样东西:

  • 同系统进行交互作用的外部参与者。
  • 一组进行交互作用的用例。

进一步地,每一个用例规范都将包括有关触发业务事件、事前条件和事后条件的信息。最重要的是,由用例所表现的行为的细节描述,将被包含在事件的一个基本流程和一组可选的流程之中。

当您希望创建一个系统范围的结构化视图的时候,用例建模十分有用。每一个用例形成了一包需求规范,并且将在随后的项目工作流程中被进一步使用(例如,设计和执行)。因此,向模型中添加一个用例,就等于添加了设计和执行工作。

当一个应用程序主要由一个用户接口(UI,屏幕)驱动的时候,分析参与者-系统之间的交互作用会起到很大的帮助作用。举例来说,在我们这个 DVD2U 的案例研究中,我们将建立一个“通报归还”的用例,DVD2U 的成员使用一个网络接口来通报 DVD2U 他们已经通过邮件将自己所租用的 DVD 发还出去了。“通报归还”用例的细节(由用户所提供的信息)随后将被用于设计“通报归还”的网页。

然而,用例模型并不仅仅是覆盖基于用户接口的交互作用。在同外部系统进行交互的情况下,参与者将成为一个系统参与者,而不仅仅是一个“人”参与者,被用来详细说明需求级上行为的其他基本构造与基于用户接口的交互作用中的相同。

对于这两种不同类型的交互作用来说,您可能拥有一组不同的额外规范工作产品,它们满足特定类型的交互作用。举例来说,“人”的参与者驱动用例总是受益于额外的简单屏幕、导航流程规范、和字段规范。同样地,您可能通过一个到第三部分中所描述的外部系统规范的映射,补充“系统”的参与者驱动用例(请参见屏幕左上角的“本系列的更多文章”链接)。

用例建模的输入

用例建模是需求原则的一个组成部分,它充分利用了前面的项目活动所生产出来的工作产品。一般地说,我们将其划分为自顶向下的输入和自底向上的输入:

  • 到目前为止,本系列教程中所接触到的自顶向下的工作产品的例子包括组件业务模型(请参见第一部分)、业务处理过程模型(第 1 部分)和域模型(第 2 部分)。
  • 我们已经看到了一个单一的自底向上的工作产品:外部系统模型(请参见第 3 部分)。

在本系列教程的范围之外,还有一个自顶向下的工作产品流,它对于用例识别也是非常有用的。这个流包括业务需要、系统特性、辅助规范等。这些工作产品,同前面所提到的那些内容一样,都被总结在下面所示的图1之中。

图 1. 用例模型的输入。
用例模型的输入
用例模型的输入

以下是对这些输入类别的简短描述:

  • 业务处理过程模型。它被用来识别那些应当使用用例而被描述的业务任务(那些涉及到参与者系统的交互作用)。
  • 组件业务模型。业务功能区域被定义在组件业务模型之中,并且可以被用来形成系统用例包的边界,也就是那些拥有每一个系统用例的系统的边界。
  • 域模型。当命名和描述用例时,我们使用定义在域模型中的业务方面的词汇。
  • 特性。如果一组特性被用作一种研究系统需求的轻量机制的话,那么我们可以使用它来识别各个用例。每一个特性都应当跟踪至少一个用例或者至少一个辅助规范。
  • 外部系统模型。在这个模型中被定义的外部系统将成为用例模型中的系统参与者。

用例模型在 SOA 建模活动期间是如何被使用的

正如前面所提到的那样,用例模型对于查看一个项目的范围来说,是一个十分有用的结构。您可以将它们用作信息需求包,并且围绕它们安排屏幕设计,这是因为它们提供了一个和人机界面相关联的交互作用。

同样地,当 SOA 作为体系架构的风格时,用例提供了关于交互作用的需求包,这些交互作用随后会被服务所实现。我们对用例模型中的每一个用例应用一项技术,我们详细说明了服务模型中的一个服务协作。然后,对于用例下面的每一个流程,我们详细说明了服务协作下面的一个服务交互作用(一个 UML 交互作用)。这样,我们使用用例模型的内容对服务模型中的动态规范进行打包。

在 Rational Software Architect 中创建 UML 用例模型

提示:
这一小节的起点就是本系列教程的第 3 部分中所得到的 SOA 教程项目。

  1. 下载文件 DVD_Rental-Part3-ProjectInterchange.zip (请参见 下载 小节),然后按照以下步骤将该项目导入到您的工作区中。

注释:
如果您仍然保存着第三部分所得到的工作区,请您直接跳到步骤8。

  1. 启动 Rational Software Architect。使用默认的工作区,或者创建一个新的工作区。
  2. 关闭欢迎屏幕。
  3. 选择 File > Import
  4. 在导入向导中,在 Select an import source filter 标签后面的文本框中输入项目,然后选择 Project Interchange 并且点击 Next,如图2中所示。
图 2. 导入 Project Interchange。
导入 Project Interchange
导入 Project Interchange
  1. 点击 Browse,并且定位到您保存 DVD_Rental-Part3-ProjectInterchange.zip 文件的位置。
  2. 选择 SOA Tutorial,并且点击 Finish,如图3中所示。
图 3. 导入 SOA 教程项目。
导入 SOA 教程项目
导入 SOA 教程项目
  1. 选择 Window > Open Perspective > Modeling 切换到 Modeling 视图(如果您尚未在这个视图之中的话)。

如果您展开 SOA 教程项目的话,您应当会在您的 Project Explorer 视图中看到如图4中所示的内容。

图 4. 原始的 Project Explorer 视图。
原始的 Project Explorer 视图
  1. 选择 SOA Tutorial 项目,右键单击,并且选择 New > UML Model
  2. 在 New UML Model 向导中,点击 Next 使用标准的模板。
  3. 在下一个屏幕中,将用例模型指定为文件名。另外,请确保 Create a default diagram in the model 被选中,然后选择 Use Case Diagram 作为默认的图表类型。
  4. 点击 Finish

注释:
在本文中,用例模型十分简单,我们不需要使用提供的用例模型模板。我们只需要使用空白模型模板即可。

您的 SOA Tutorial 项目看上去应当如图5中所示的那样。

图 5. 原始的用例模型。
原始的用例模型

详细说明用例模型的各个元素

现在,我们详细说明用例模型的各个元素:参与者、用例列表、用例分类、用例流程。

参与者

在业务处理过程模型中,我们识别了一个名为 Member (DVD2U 成员)的角色,以及另一个被称作 Receiving Clerk (在 DVD2U 商店中工作的人)的角色。另外,在设计模型(外部系统部分)中,我们识别了一个用于 Customer Relationship Management 的现已存在的系统。在这个用例模型中有所有的参与者候选人,所以您将创建用例参与者来表现它们在这些用例中将要扮演的角色(一个用例参与者定义了一个同系统进行交互作用时所能够扮演的角色)。

  1. Main 图表中,选择调色板中的 Actor,并且点击图表中的某个位置。这样做将创建一个新的参与者。我们将其取名为 Member
  2. 对于 Receiving Clerk 和 Customer Relationship Management 重复前面的步骤。

现在,您的图表看上去应当如图6中所示的那样。

图 6. 用例参与者。
用例参与者
用例参与者

您知道 Member 和 Receiving Clerk 都是人的参与者;而 Customer Relationship Management 是一个系统。现在,您将使用关键字来区分人和系统的参与者。

  1. 选择 Member 参与者,并且在 Properties 视图中点击 Stereotypes 标签。
  2. Keywords 文本框中键入 human,如图7中所示。
图 7. 关键字:人。
关键字:人
  1. 对于其他两个参与者重复前面的两个步骤(指定 system 作为 Customer Relationship Management 参与者的关键字)。

现在,在 Project Explorer 下面的用例模型看起来应当如图8中所示的那样。

图 8. 用例模型的参与者。
用例模型的参与者

识别用例

在业务处理过程模型中,我们识别了一个名为通报归还的业务任务,它由 Member (成员)执行,并且被分类为 Human-System (人的系统)交互作用,如图9中所示。接下来,您将为它创建一个用例。

作为一个一般的规则,考虑一个原子系统事务水平的系统用例的范围最为参与者的经历。这就是说,下面两个系统任务(得到成员的身份和发送下一个录像带)并不是成为新的用例,而是作为同一个系统用例范围的组成部分。

图 9. 归还录像带业务处理过程模型(2-1)。
归还录像带业务处理过程模型(2-1)
归还录像带业务处理过程模型(2-1)

同样地,我们识别了另外一个名为 Record (记录)收据的业务任务,它由 Receiving Clerk (接收店员)执行,并且被分类为 Human-System (人的系统)交互作用,如图10中所示。您也将为它创建一个用例。根据上面所提到的一般性规则,向库存中添加副本也被考虑作为同一个用例的组成部分。

图 10. 归还录像带业务处理过程(2-2)。
归还录像带业务处理过程(2-2)
归还录像带业务处理过程(2-2)

请注意,业务分析可以很好的完成业务处理过程中业务任务的分类工作(橙色表示“人”、灰色表示“系统”、蓝色表示“人-系统”)。正如您所看到的,我们从用例中所识别的这两个业务任务被标记为蓝色,这意味着它们是人-系统的,因此是用例的完美候选人。然而,有些任务仅仅是基于系统的,它们或者拥有一个系统参与者,或者以时间作为参与者。同样地,有些任务仅仅是基于人的,它们同系统用例没有任何关系,这是因为它们是完全手动的(尽管它们可能生产出被下游“人”或者“系统”任务所使用的产品)。

对于本文来说,您不需要了解用例 UML 图表上的连接器的细节(多样性和角色)。现在,更改您的 Preferences,从而使得 Rational Software Architect 在默认情况下并不显示这些内容:

  1. 选择 Window > Preferences。
  2. 在 Preferences 的 Filter 文本框中,键入 connector。
  3. 点击 Modeling > Diagrams > Appearance,并且选择 Connectors,如图11中所示。
  4. 去掉 Show multiplicityShow roles 前面的复选框,如图11中所示,然后点击 ApplyOK
图 11. 连接器的参数选择。
连接器的参数选择
连接器的参数选择
  1. Main 图表中,选择调色板中的 Use Case,并且点击用例图表的一个空白区域。这样做将创建一个新的用例。我们将其命名为“通报归还”。
  2. 对于 Record Receipt 用例,重复上述步骤。
  3. 成员是通报归还的一个角色。将鼠标移至 Member 上面。当外发连接器出现时(如图12中所示),点击并且将其拖动到 Notify of Return 上面。
图 12. 一个角色的外发连接器。
一个角色的外发连接器
一个角色的外发连接器
  1. 重复上述步骤,将 Customer Relationship Management (客户关系管理)连接到 Notify of Return (通报归还),并且将 Receiving Clerk (接收店员)连接到 Record Receipt (记录收据)。

现在,您的图表看上去应当如图13中所示的样子。

图 13. 用例和参与者。
用例和参与者
用例和参与者

组织用例

通过一个较大型的用例模型(例如那些包含12个用例的用例模型),我们可以很好地练习如何对用例进行分类。有许多不同的分类方法可供您采用。其中一种是根据它们所属的业务功能区域进行分类。本例中所采用的就是这种方法,尽管它只包含两个用例。在这个案例中,业务功能区域就是组件业务模型的业务组件,如图14中所示。

图 14. 用于 DVD2U 的组件业务模型对应关系。
用于 DVD2U 的组件业务模型对应关系
用于 DVD2U 的组件业务模型对应关系

在这个 DVD2U 案例研究中,有两个适当的业务组件:在线租用(用于通报归还及其参与者)和跟踪(用于记录收据及其参与者)。现在,您将相应地对这两类用例进行划分。

  1. 从 Project Explorer 中选择 Use Case Model,右键单击,并且选择 Add UML > Package。将该包命名为 Online Rentals (在线租用)。
  2. 从 Project Explorer 中将 Notify of ReturnCustomer Relationship ManagementMember 元素拖动到 Online Rentals 包的上面。
  3. 打开在“在线租用”包下被自动创建的图表,并且将这三个模型元素拖动到它的上面。将这个图表重新命名为 Online Rentals Use Cases (在线租用用例)。
  4. 重复上述三个步骤,将 Record ReceiptReceiving Clerk 移动到一个 Tracking 包中。使用 Tracking Use Cases (跟踪用例)作为图表的名称。
  5. 保存您的模型(CTRL + S)。

现在,在 Project Explorer 下面的用例模型看起来应当如图15中所示的那样。

图 15. Project Explorer 下面的用例模型。
Project Explorer 下面的用例模型
Project Explorer 下面的用例模型

注释:
在一个典型的用例建模活动中,架构师将验证这些用例,消除任何在体系架构方面没有意义的东西,并且确保它们被适当分解。在这个简单的 DVD2U 例子之中,我们保持两个用例,并且确保我们的设计处理它们所描述的需求。

用例流程

识别用例的集合进而描述项目的范围,通常是通过使用一个用例模型来完成的,但是这仅仅是全部用例规范中的一小部分。大量的努力被放在处理每一个用例规范上面。精确的需求正是在此处被详细说明的。这是由一个系统分析师所进行的需求分析工作。正如前面所描述的那样,各种其他的工作产品将被用作有用的输入。

对于每一个用例来说,下列信息被捕获到:

  • 概述:用一两句话对用例目标进行一个高层次的描述。
  • 业务事件:是什么触发了这个用例。
  • 事前条件:用例发生所必须具备的条件。
  • 事后条件:运行用例后所改变的结果。

本例中,用例“通报归还”看起来也许是这样的:

概述:这个用例描述了一个 DVD2U 成员如何使用 DVD2U 用户界面来通知 DVD2U 他们已经通过邮件归还了自己所租用的 DVD。

业务事件:成员希望通知 DVD2U 他们已经归还了一个或者多个 DVD。

事前条件:成员已经登录该系统,并且已经看到他们的 Member Rentals (租用情况)。

事后条件:对于每一个归还的录像带主题,其状态被更改为 RETURNED (已归还)。

注释:
这一类型的信息(以及描述流程的文本文件)往往是在生产力软件文档中(例如 Microsoft® Word®)被捕获的。举例来说,您可以使用一个模板,其中每一个部分对应于一个用例,图表中保存指定的信息。

在本文中,您将在 UML 用例的文档文本框中捕获到这一信息:

  1. 从 Project Explorer 中选择 Notify of Return 用例。
  2. 从 Properties 视图中选择 Documentation 标签,并且复制粘贴列表1中所示的信息。
列表 1. “通报归还”的用例文档。
Overview:
This use case describes how a DVD2U member can use the 
DvD2U user-interface to notify DVD2U that they have returned DVD(s) by mail.

Business Event:
Member wants to notify DVD2U of the return of one or more DVD(s).

Preconditions:
* Member is logged on to the system
* Member has viewed their member rentals

Post-conditions:
For each video title returned, its status is changed to RETURNED.

一个用例的大量规范都被包含在用例流程之中。一个用例流程通过一系列参与者-系统的交互作用和系统行为,描述了如何达到用例的结果(例如,成员已经注意到返回的信息)。对于每一个用例来说,您都需要至少一个基本的流程(发生在通常情况下面的“晴天”或者“愉快的小路”),并且一个或者多个可选的流程(发生在假定情况下面的“雨天”或者“不愉快的小路”)。

在 DVD2U 中,返回信息通告使得有价值的成员能够在上一个主题被接收之前发送他们的下一个主题。这样做能够激励成员们通告 DVD2U 他们已经归还了录像带。此外,这样做也使得 DVD2U 能够更好的管理 DVD 库存,并且及时知晓 DVD 丢失的情况。对于“通报归还”来说,我们有一个基本的流程和一个可选的流程提供给有价值的成员:

列表 2. “通报归还”的基本流程。
1. Member indicates which member rentals they have returned.

Steps 2-5 repeat for each member rental indicated: 

2. System updates return notification timestamp for the member rental.
3. System retrieves the video copy status for the member rental.
4. System updates the video copy status to be ON_THE_WAY_BACK.
5. System retrieves the video list title for the member rental.
6. System updates the video list title status to be RETURNED.
7. System retrieves the member for the member rental 
    and checks the member's membership standing.

请注意:流程的描述是如何充分利用包含在域模型中的业务信息规范来描述域元素的状态变化的。

列表 3. “通报归还”的选择性流程。
7a. Member has valued membership standing:
7a.1 System retrieves the member's video list.
7a.2 System sets member's video list's isNextVideoRequired to TRUE.
7a.3 System informs Member that the next video will be on the way.
  1. 将流程信息添加到“通报归还”的 Documentation 文本框之中。

现在,“通报归还”的文档应当如列表4中所示的那样。

列表 4. 修订过的“通报归还”的文档。
Overview:
This use case describes how a DVD2U member can use the 
DvD2U user-interface to notify DVD2U that they have returned DVD(s) by mail.

Business Event:
Member wants to notify DVD2U of the return of one or more DVD(s).

Preconditions:
* Member is logged on to the system.
* Member has viewed their member rentals.

Post-conditions:
For each video title returned, its status is changed to RETURNED.

Basic flow:
1. Member indicates which member rentals they have returned

Steps 2-5 repeat for each member rental indicated: 
2. System updates return notification timestamp for the member rental.
3. System retrieves the video copy status for the member rental.
4. System updates the video copy status to be ON_THE_WAY_BACK.
5. System retrieves the video list title for the member rental
6. System updates the video list title status to be RETURNED.
7. System retrieves the member for the member rental 
    and checks the member's membership. standing

Alternative flows:
7a. Member has valued membership standing:
7a.1 System retrieves the member's video list.
7a.2 System sets member's video list's isNextVideoRequired to TRUE.
7a.3 System informs Member that the next video will be on the way.

关于工具的提示

下面的各个小节为观察用例建模是如何使用不同工具的提供了一些有用的方法。

创建图表来表现流程

在 Rational Software Architect 中,您可以使用 UML Activities 来详细说明一个用例的流程,步骤如下:

  1. 从 Project Explorer 中选择一个用例,右键单击,然后选择 Add UML > Activity
  2. 然后,在 Activity 图表的内部,使用划分(参与者)、参与者和流程来详细说明发生了什么。
  3. 在每一个流程上面重复这一操作。

在本教程中我们并没有这样做,这是因为我们希望保持用例模型的简单性,并且只向您展示一个流程的书写描述。这种方法的缺点之一就是流程只表现纯文本内容,并不能作为模型驱动开发方法(确认、自动控制)的一部分。举例来说,您如何能够自动说出每一个用例是否至少具有一个与其相关联的基本流程呢?对于这一规范技术的详细介绍,超出了本文的范围。尽管我们建议您考虑使用 Activities 来对用例流程进行建模,但是我们承认这项技术并不完全适用于每个人。

使用 RequisitePro

IBM® Rational® RequisitePro® 是一款被用来管理所有需求(包括用例)的产品。我们说过,用例信息可以在 Word 文档中被捕捉到。在这种情况下,您可以使用 RequisitePro 和 Word 集成工具将用例信息导入到 RequisitePro 数据库之中。然后,使用 Rational Software Architect 和 RequisitePro 综合特性,您可以追踪 UML 用例模型元素到 Requisite Pro 项目元素。我们并没有在此处展示这一过程,这是由于它们已经在其他的 developerWorks 文章中被详细介绍过了。

确保可追溯性

在上一段话中,我们谈论了从 Rational Software Architect UML 模型到 RequisitePro 需求项目的可追溯性。另一条可追溯性的线索是从 Rational Software Architect UML 模型到 IBM® WebSphere® Business Modeler Business Process 模型。我们从 Business Process 模型的任务中识别各个用例,并且可以在我们的模型之间包括这一踪迹。我们并没有在此处展示这一过程,这是由于在第 2 部分中我们已经讨论了 Rational Software Architect 和 WebSphere Business Modeler 的集成。

下一步是什么?

本教程解释了如何使用用例模型来从用例的角度描述项目的范围,这正是需求规则的核心之处。我们讨论了这一活动在一个 SOA 项目中的重要性,然后在 Rational Software Architect 中概述了一个用例模型的创作物。然后,我们对这个模型的不同元素(参与者、用例)进行建模,并且详细设计每一个用例规范。在本系列的下一部分中,我们将介绍面向服务的体系架构的核心模型:服务模型


下载资源


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=312408
ArticleTitle=用 Rational Software Architect 建立面向服务的体系结构(Service-Oriented Architecture)的模型,第 4 部分: 用例模型
publish-date=06052008