为用例逻辑建模

下载本文示例代码
本文转自IBM developerWorks中国网站　　这篇对“统一建模语言 (UML)”序列图标记的简介改编自 The Object Primer 2nd Edition 的第 6 章。 　　序列图用于为使用方案的逻辑建模。使用方案恰如其名称所揭示的那样 -- 描述使用系统的潜在方法。使用方案的逻辑可以是用例的一部分，可能是备选过程。它也可以是整个用例过程，例如由基本行动过程描述的逻辑，或者部分基本行动过程再加上一个或多个替代方案描述的逻辑。使用方案的逻辑也可以是几个用例中包含的逻辑。例如，一个学生在大学入学后，立即参加了三个研习班。序列图以可视方式为系统中逻辑的流程建模，能够让您记载和验证逻辑，这通常用于分析和设计目的。　　图 1 是“参加研习班”用例的基本行动过程的模型。您可能想要现在打开该图，并在阅读本文时参考它。　　分类器　　横贯该图顶部的那些框表示的是分类器或它们的实例 -- 通常是用例、对象、类或参与者（往往用长方形表示，但它们也可以是符号）。　　因为既可以向对象发送消息，又可以向类发送消息（对象通过调用操作来响应消息，而类则通过调用静态操作来响应消息），所以有必要将它们都包括在序列图中。另外，因为参与者在使用方案中发起操作并占据主动地位，因此也要将他们包括在序列图中。对象的标签具有标准 UML 格式 "name: ClassName"，其中的 "name" 是可选的。（在图中没有给出名称的对象称为匿名对象。）类标签的格式为 "ClassName"，而参与者名的格式为 "Actor Name" -- 这些也都是 UML 标准。例如在图 1 中，"Student"（“学生”）参与者的名称为 "A Student"，它的标签为原型 <>。表示 "UI32 Seminar Selection Screen"（“UI32 研习班选择屏幕”）的主要 UI 元素的实例是名称为 ":SeminarSelector"、原型为 <> 的匿名对象。因为向 "Student" 类发送静态消息 "isEligible(name, studentNumber)"，所以在图中标名了该类（名称为 "Student" 的框）。我们稍后再详细说明。在图中，因为 "Student" 的实例在几个地方都用作消息中的参数，所以为它提供了名称 "theStudent"。与之相反，"StudentsFees" 类的实例不需要在图中的其它任何地方引用，因此可以是匿名的。　　生命线　　从各个框垂下来的虚线称为对象生命线，表示在对方案建模期间对象的生命跨度。生命线上的细长框是方法调用框，表明正在由目标对象／类执行处理，以完成消息。方法调用框底部的 X 是一种 UML 约定，表明对象已从内存中除去，这通常是接收到原型为 <> 的消息的结果。　　 　　为消息建模　　消息以带有标签的箭头表示。当消息的源和目标为对象或类时，标签是响应消息时所调用方法的签名。不过，如果源或目标中有一方是人类参与者，那么消息就用描述正在交流的信息的简要文本作为标签。例如，":EnrollInSeminar" 对象向 "Seminar" 的实例发送消息 "isEligibleToEnroll(theStudent)"。请注意我是如何同时包含方法名和参数名的（如果有参数名，则传递给它）。　　图 1 还表明 "Student" 参与者通过标签为 "name"（“姓名”）和 "student number"（“学号”）的消息向 ":SecurityLogon" 对象提供信息。（这些实际上并不是消息；它们实际上是用户交互。）返回值可以使用带有表明是返回值标签的虚线箭头表示。例如，标出了从 "Student" 类返回的，作为调用消息结果的返回值 "theStudent"，而没有标出向 "seminar" 发送消息 "isEligibleToEnroll(theStudent)" 的结果的返回值。我的风格是，当返回内容很明显时不标出返回值，这样就不会把序列图搞乱。（您可以发现，序列图可以很快变得相当复杂。）　　消息实现用例步骤的逻辑，图的左侧概括了这些步骤。请注意，由于步骤的描述往往太过冗长，以至于无法恰当地放在一张图上，因此并没有对用例步骤使用确切的措辞。关键是，步骤号要与用例中的步骤号对应起来，使图的读者能够清楚地了解步骤的大体思想。　　下面列出的是图 1 所显示的 UML 序列图“参加研习班”用例的基本行动过程。　　“参加研习班”用例 名称：参加研习班 标识：UC 17 描述：允许有资格的学生参加研习班。 前提：是在校注册学生。 结果：在学生有资格且有空位的条件下，允许该生参加他想参加的课程。 扩展：N/A 包含：N/A 继承自：N/A　　基本行动过程： 学生想参加研习班。 学生通过“UI23 安全登录屏幕”将他的姓名和学号输入系统。 系统根据“BR129 确定参加资格”商业规则来验证该学生是否有资格参加学校里的研习班。 系统显示可供选择的研习班列表“UI32 研习班选择屏幕”。 学生指定他想参加的研习班。 系统根据“BR130 确定学生参加研习班的资格”商业规则来验证该学生是否有资格参加研习班。 系统根据“BR143 验证学生研习班课程表”商业规则来验证研习班是否适合该学生的现有课程表。 系统根据课程目录中公布的费用、适用的学生费用和适用的税款来计算研习班的费用。应用“BR 180 计算学生费用”和“BR45 计算研习班税款”商业规则。 系统通过“UI33 显示研习班费用屏幕”显示费用。 系统询问该学生是否仍然想参加研习班。 学生表明他想参加研习班。 系统招收该生参加研习班。 系统通过“UI88 研习班注册摘要屏幕”通知该学生注册成功。 系统根据商业规则“BR100 为学生开具研习班帐单”给该学生开出参加研习班费用的帐单。 系统询问该生是否想打印注册报告书。 学生表明他想打印报告书。 系统打印注册报告书 -“UI89 注册摘要报告书”。 当学生拿到打印的报告书后，用例结束。 　　备选过程 A：学生没有资格参加研习班 系统确定学生没有资格参加研习班。 系统通知该生，他没有资格参加研习班。 用例结束。 　　备选过程 B：学生不具备前提条件 系统确定学生没有资格参加他所挑选的研习班。 系统通知该生，他不具备前提条件。 系统通知该生他所需的前提条件。 用例返回至基本行动过程的第 4 步继续。 　　备选过程 C：学生决定不参加现有的研习班 学生在查看了研习班的列表之后，发现没有他想要参加的研习班。 用例结束。 本文转自IBM developerWorks中国网站　　这篇对“统一建模语言 (UML)”序列图标记的简介改编自 The Object Primer 2nd Edition 的第 6 章。 　　序列图用于为使用方案的逻辑建模。使用方案恰如其名称所揭示的那样 -- 描述使用系统的潜在方法。使用方案的逻辑可以是用例的一部分，可能是备选过程。它也可以是整个用例过程，例如由基本行动过程描述的逻辑，或者部分基本行动过程再加上一个或多个替代方案描述的逻辑。使用方案的逻辑也可以是几个用例中包含的逻辑。例如，一个学生在大学入学后，立即参加了三个研习班。序列图以可视方式为系统中逻辑的流程建模，能够让您记载和验证逻辑，这通常用于分析和设计目的。　　图 1 是“参加研习班”用例的基本行动过程的模型。您可能想要现在打开该图，并在阅读本文时参考它。　　分类器　　横贯该图顶部的那些框表示的是分类器或它们的实例 -- 通常是用例、对象、类或参与者（往往用长方形表示，但它们也可以是符号）。　　因为既可以向对象发送消息，又可以向类发送消息（对象通过调用操作来响应消息，而类则通过调用静态操作来响应消息），所以有必要将它们都包括在序列图中。另外，因为参与者在使用方案中发起操作并占据主动地位，因此也要将他们包括在序列图中。对象的标签具有标准 UML 格式 "name: ClassName"，其中的 "name" 是可选的。（在图中没有给出名称的对象称为匿名对象。）类标签的格式为 "ClassName"，而参与者名的格式为 "Actor Name" -- 这些也都是 UML 标准。例如在图 1 中，"Student"（“学生”）参与者的名称为 "A Student"，它的标签为原型 <>。表示 "UI32 Seminar Selection Screen"（“UI32 研习班选择屏幕”）的主要 UI 元素的实例是名称为 ":SeminarSelector"、原型为 <> 的匿名对象。因为向 "Student" 类发送静态消息 "isEligible(name, studentNumber)"，所以在图中标名了该类（名称为 "Student" 的框）。我们稍后再详细说明。在图中，因为 "Student" 的实例在几个地方都用作消息中的参数，所以为它提供了名称 "theStudent"。与之相反，"StudentsFees" 类的实例不需要在图中的其它任何地方引用，因此可以是匿名的。　　生命线　　从各个框垂下来的虚线称为对象生命线，表示在对方案建模期间对象的生命跨度。生命线上的细长框是方法调用框，表明正在由目标对象／类执行处理，以完成消息。方法调用框底部的 X 是一种 UML 约定，表明对象已从内存中除去，这通常是接收到原型为 <> 的消息的结果。　　 　　为消息建模　　消息以带有标签的箭头表示。当消息的源和目标为对象或类时，标签是响应消息时所调用方法的签名。不过，如果源或目标中有一方是人类参与者，那么消息就用描述正在交流的信息的简要文本作为标签。例如，":EnrollInSeminar" 对象向 "Seminar" 的实例发送消息 "isEligibleToEnroll(theStudent)"。请注意我是如何同时包含方法名和参数名的（如果有参数名，则传递给它）。　　图 1 还表明 "Student" 参与者通过标签为 "name"（“姓名”）和 "student number"（“学号”）的消息向 ":SecurityLogon" 对象提供信息。（这些实际上并不是消息；它们实际上是用户交互。）返回值可以使用带有表明是返回值标签的虚线箭头表示。例如，标出了从 "Student" 类返回的，作为调用消息结果的返回值 "theStudent"，而没有标出向 "seminar" 发送消息 "isEligibleToEnroll(theStudent)" 的结果的返回值。我的风格是，当返回内容很明显时不标出返回值，这样就不会把序列图搞乱。（您可以发现，序列图可以很快变得相当复杂。）　　消息实现用例步骤的逻辑，图的左侧概括了这些步骤。请注意，由于步骤的描述往往太过冗长，以至于无法恰当地放在一张图上，因此并没有对用例步骤使用确切的措辞。关键是，步骤号要与用例中的步骤号对应起来，使图的读者能够清楚地了解步骤的大体思想。　　下面列出的是图 1 所显示的 UML 序列图“参加研习班”用例的基本行动过程。　　“参加研习班”用例 名称：参加研习班 标识：UC 17 描述：允许有资格的学生参加研习班。 前提：是在校注册学生。 结果：在学生有资格且有空位的条件下，允许该生参加他想参加的课程。 扩展：N/A 包含：N/A 继承自：N/A　　基本行动过程： 学生想参加研习班。 学生通过“UI23 安全登录屏幕”将他的姓名和学号输入系统。 系统根据“BR129 确定参加资格”商业规则来验证该学生是否有资格参加学校里的研习班。 系统显示可供选择的研习班列表“UI32 研习班选择屏幕”。 学生指定他想参加的研习班。 系统根据“BR130 确定学生参加研习班的资格”商业规则来验证该学生是否有资格参加研习班。 系统根据“BR143 验证学生研习班课程表”商业规则来验证研习班是否适合该学生的现有课程表。 系统根据课程目录中公布的费用、适用的学生费用和适用的税款来计算研习班的费用。应用“BR 180 计算学生费用”和“BR45 计算研习班税款”商业规则。 系统通过“UI33 显示研习班费用屏幕”显示费用。 系统询问该学生是否仍然想参加研习班。 学生表明他想参加研习班。 系统招收该生参加研习班。 系统通过“UI88 研习班注册摘要屏幕”通知该学生注册成功。 系统根据商业规则“BR100 为学生开具研习班帐单”给该学生开出参加研习班费用的帐单。 系统询问该生是否想打印注册报告书。 学生表明他想打印报告书。 系统打印注册报告书 -“UI89 注册摘要报告书”。 当学生拿到打印的报告书后，用例结束。 　　备选过程 A：学生没有资格参加研习班 系统确定学生没有资格参加研习班。 系统通知该生，他没有资格参加研习班。 用例结束。 　　备选过程 B：学生不具备前提条件 系统确定学生没有资格参加他所挑选的研习班。 系统通知该生，他不具备前提条件。 系统通知该生他所需的前提条件。 用例返回至基本行动过程的第 4 步继续。 　　备选过程 C：学生决定不参加现有的研习班 学生在查看了研习班的列表之后，发现没有他想要参加的研习班。 用例结束。 下载本文示例代码


为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模为用例逻辑建模