方法逻辑 序列图在记录方法逻辑方面非常优秀。实际上，只要给出了 Java 方法，某些 CASE 工具会自动生成一个序列图。序列图可用于设计未来方法或记录现有方法的流程。

关于示例应用程序

我们将在示例贷款处理应用程序的帮助下学习序列图。因为本专栏的重点在于建模，而不是方法，我们要直接讨论建立图，所以我们不会注重于应用程序的细节。我们为贷款处理应用程序绘制的基本功能如下：

用例：提交贷款请求

申请人通过因特网完成并向银行提交贷款申请。

系统确认贷款申请的信息，检查它是否正确以及信息是否尽可能完整。

系统向外部商业资信咨询机构转发贷款请求，以获取该申请人的信用报告。

系统根据所返回的信用报告计算申请人的信用积分。

入门

创建序列图的第一步是确定该图是否表示与外部或内部实体的交互。如果正在建立用例方案的模型，那么序列图通常表示与外部实体的交互。如果正在建立框架中协议的模型，那么此图也许表示内部或外部交互。子系统图、类图和个别方法逻辑图通常只表示内部实体。无论是哪种情况，将要建模的交互类型决定了序列图中的第一个（最左边的）元素。

与外部实体的交互表示参与者是交互的一部分。内部交互可能由参与者启动（如果子系统用例是交互的基础），但它更可能是由叫作 Sender 的普通类启动的。如果参与者启动了交互，那么参与者将归入启动程序类别，这是四种常见参与者角色之一。

我们将关注为贷款处理应用程序（以上概述的 提交贷款请求用例）的方案建立图。请注意当申请人完成在线贷款申请并在因特网上提交它时序列图的变化。在这个方案中，申请人在系统外部，因此用参与者来表示他。我们首先将参与者 Applicant 添加到序列图，如图 1 所示。

图 1. 添加申请人

Java建模: UML工作簿，第1部分――序列图简介(3)

添加参与者

一旦交互的启动程序就位，下一步就是添加它在方案的过程中将与之交互的对象。这些对象的名称应该反映出类或实例的行为。（类或实例的选择给出了与序列图截然不同的含义，但我将把这两者之间差异保留到下次讨论。）

对于示例方案，我们将添加两个类： LoanApplication 和 LoanRequest 。当申请贷款时，需要提交贷款申请。它包含了关于申请人和期望贷款金额的信息。贷款请求是银行向商业资信咨询机构发送的关于接受贷款申请的表单。它包含了来自贷款申请的一些信息，以及获取关于申请人的信用历史记录信息的请求。图 2 中显示了将这两个类添加到序列图中。

图 2. 添加两个交互类

连接各点 -- 虚线

对于大多数软件开发人员来说，序列图是直观的。它们将对象和参与者（横轴）映射到时间（纵轴）。消息连接了对象，当消息发生时，它们沿着纵轴从一个对象移动到另一个对象。这些消息被连接到从对象或参与者底部的中间延伸出的竖直虚线。这条线被称作 生命线。

在横轴上，我们用被称作 调用箭头或 消息箭头的箭头来表示消息。消息箭头从发送方（尾）指向接收方（头）。这些箭头用于捕捉系统的动态行为。调用通常始于左边，向右边移动。即，交互中的初始箭头通常来自左边。当创建类的新实例时，我们绘制的箭头都指向类自身，而不是生命线。我们方案中的第一步是创建新的贷款申请，因此我们在 Applicant 和 LoanApplication 之间画出箭头。由于用 Java 创建新实例涉及到调用构造器，因此我们将这个箭头标上构造器名称，可能的话，还要标上变量。

我们仍处于软件开发生命周期中的分析阶段，因此我们要仅可能多地包含分析信息。我们的一个商务分析员提到我们把创建新贷款申请的操作称作“完成贷款申请”。如果我们要在构造过程中使这个序列图保

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!