Java建模: UML工作簿, 第2部份――序列图中的条件逻辑[Java编程]

我在介绍性专栏中曾经注释过,序列图用于描写系统随时间而产生的内部行为.因为系统行为是对象彼此之间发送消息的后果,因此序列图绘制了那些消息在对象之间移动时的线路.归根结底,序列图就是交互图.在前一部份中,固然我们描写了无数交互,但只成立了一个相当简单的图.这次,我们将做进一步的研究,看看 UML 指定的序列图的两种形状.这两种形状是 通例和 实例.让我们从每种形状的精确利用开始.

序列图的两种范例

序列图用于描写对象之间两种差别范例的交互.一种交互范例是 必须 (must) 交互,此中对象 A 必须向对象 B 发送特定消息.另一种交互范例是 大概 (may) 交互,此中对象 A 大概（但不一定）向对象 B 发送特定消息.这两种形状的序列图描写了这两种差别范例的交互.通例形状描写的是 必须交互,而实例形状则描写了 大概交互.

通例形状的序列图描写初始刺激因素所产生的类交互.通例形状则记叙了初始刺激因素可以产生的一切交互.成功和失利条件与循环、条件和分支一样,都是这种图的构成部份.

通例序列图在水平轴方向上的每个框中只包含一个类名,如图 1 所示.它的含义是,交互背后的对象是匿名的,该类的任何对象都可以参与到交互中.因此,必须为全部途径明确建模.在通例序列图中,对象 A 必须向对象 B 发送模子中的一条消息.

图 1. 通例序列图

序列图的第二种形状是实例形状.实例序列图描写了两个实例之间大概发生的单一消息交换.这样的图将在水平轴方向的框中包含一个变量名及其类范例,如图 2 所示.这种形状不包含通例形状中常见的循环、条件和分支.在系统中实际的掌握流程中,在交互历程中所举行的某些断言大概为假.假如发现断言为假,实例序列图中的全部消息都为空,这种情形将不呈现.实例序列图描写了大概发生也大概不发生的单一情形.

图 2. 实例序列图

实例序列图最合适于在软件开辟生命周期的解析阶段对个体筹划建模.通例序列图可认为包含多个筹划的整个用例建模.别的一些范例的活动 -- 比方为子系统或框架与其各个部份之间利用的协议建模 -- 可以利用任何一种形状,这取决于组件在软件开辟生命周期中所处的位置.与实例形状相比,通例形状更接近于在终究产品中呈现的实际代码.

我们在前一专栏中利用的是通例形状,并将在此持续研究这种形状.这一次,我们将根究条件逻辑在通例序列图中所扮演的角色,通过它来让您理解有关 UML 表示的更多知识.

　　以上是“Java建模: UML工作簿, 第2部份――序列图中的条件逻辑[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：