摘要 　　 　　本文从初始需求开始构建聊天室模型，以及对个案进行研究。在不同的开发阶段，分别要用到UML类图、时序图和状态图。这样，难免需要确定一致性问题，现在已经提出了许多仿真和方法，用来确保模型各个方面的一致性。我们关注内部一致性，即给定模型内部制品之间的一致性问题。 　　 　　1 简介 　　 　　软件系统的开发过程通常会被划分成一些步骤，每个步骤会用到不同的UML图。由于建模系统变得越来越复杂，一致性问题就越发突出起来。而在其中，有两种类型或问题更为显著。第一，内部一致性问题，涉及给定模型内部制品之间的一致性。第二，系统之间一致性问题，涉及软件开发过程中不同演化模型之间的一致性。我们主要关注于内部一致性问题。 　　 　　不同的文献提出了不同的形式化方法，用来自动检查一致性，发现设计当中存在的问题。在下面几节里，我们分步研究了一个聊天室的开发过程。本文的灵感来源于Agder大学Geir Melby完成的一次项目报告（http://fag.grm.hia.no/ikt2340/year2002/）。这个模型提出了一些潜在的一致性问题。对于它们当中的部分内容，也给出了自动化的一致性检查方法。 　　 　　在这份案例研究中，我们从需求开始开发了一个聊天室模型。第二节给出了客户、管理器对象以及聊天室之间的通信协议，作为初始需求。第三节研究了一个可能的类的设计，它定义了符合协议的接口。第四节中给出的时序图进一步定义和描述了组件之间的通信，并保持与类设计之间的一致性。第五节使用状态图更进一步地确定应用程序的行为。这份规程可以在我们的SVM（状态图虚拟机）环境中实时地进行仿真或执行。在第六节中，讨论了协议规程与仿真迹的一致性。第七节进行总结。 　　 　　2 通信协议 　　 　　我们将要创建的聊天室程序是按照客户机/服务器范型来架构的。客户会随机连接聊天室。如果某个聊天室接收了客户，客户就会发送消息给这个聊天室。然后聊天室广播每条消息，除了发送者以外，每个与聊天室建立连接的客户都会收到一份拷贝。 　　 　　下面将要描述一个特定的简化了的用例： 　　 　　X　　　　　系统包括五个客户和两个聊天室。客户端最初没有连接。每隔一到三秒（非均匀分布），它们都会随机连接一个聊天室。被请求的聊天室同时收到请求（假定没有网络延时，并且通信可靠）。 　　 　　X　　　　　一个聊天室至多接收三个客户。当且仅当容量没有超标时聊天室才会接收连接。 　　 　　X　　　　 发出请求的客户会立刻收到接收或拒绝通知。 　　 　　X　　　　　在客户可以发送聊天信息之前必须被一个聊天室接收。 　　 　　X　　　　　连接建立之后，客户会每隔一到五秒（非均匀分布）给它所连接的聊天室发送随机消息。聊天室会立即接收消息，它将耗时一秒钟来处理接收到的消息，并把它广播给除发送者之外的所有连接客户。 　　 　　X　　　　　客户会同时收到广播。为了简化起见，我们不讨论没有连接的情况。 　　 　　3 类的设计 　　 　　根据上面的规定，显然我们需要两个类：Client和ChatRoom。在开发过程早期阶段，对于仿真来说无需用户干预，我们明确地按照随机过程对用户行为（连接请求和聊天信息）进行建模。以后，客户模型将会被与软件打交道的真实客户所代替。仿真开始时，会初始化五个Client实例和两个ChatRoom实例。 　　 　　我们还加入了一个singleton类：Manager。Manager以仲裁者的身份中继组件之间的所有通信。这种中央控制措施将会帮助截取系统传递的所有消息，使用它们就可以检查模型的正确性。 　　 　　图一描述了由这三个类组成的UML类图。 　　 　　X　　　　 ChatRoom提供两个方法处理到达的事件。request处理来到的请求，每个请求都有参数clientID和roomID。ChatRoom把接收或拒绝通知发回拥有全局ID标识clientID的发送者。它也使用参数roomID来决定请求是发给它自己还是发给另外一个聊天室了1。send方法接收由客户clientID发送的消息msg。这条msg将会在一秒钟之后被广播出去。 　　 　　X　　　　 Client的方法accept和reject处理到达的接收和拒绝通知。参数clientID用来确定目标客户。当一个Client接收到一个broadcast事件，它会检查自己是否在clients集合中。如果情况确实如此，消息msg就会在输出中被打印出来。 　　 　　X　　　　 Manager中继连接请求、接收和拒绝通知、来自客户的消息以及聊天室的广播。例如，如果它收到来自聊天室的广播，有三个参数会告诉它消息最初的发送者（客户），广播者（聊天室）以及消息字符串。然后它把消息发给所有连接在聊天室中的，除了最初发送者以外的客户。 　　 　　　 　　图一 类的设计 　　 　　尽管这种API定义不是形式化的，但接口背后的行为还是很容易理解的。但是，检查协议的一致性会有些困难，甚至是不可能的，原因如下： 　　 　　X　　　　 行为隐藏在接口背后，它只能在理解的基础上进行解释。 　　 　　X　　　　 协议是用自然语言表达的，程序不可能很容易地处理。 　　 　　X　　　　 对于一个定义完好的系统来说，会有许多接口设计。它们可能有相当大的不同。例如，本设计中用Manager类来拦截通信。另一项设计可能会使用RequestManager来拦截请求、接收和拒绝，用MessageManager来拦截消息和发送广播。更有另外一种设计可能根本就不会使用任何管理器。 　　 　　4 时序图 　　 　　本节讨论的时序图把设计带入比类图更低的抽象层次（更高层次的细节）。时序图必须清晰反映组件之间的交互。 　　 　　　 　　图二 请求模式的时序图 　　 　　　 　　图三 消息模式的时序图 　　 　　4.1 定时 　　 　　定时问题使得协议转化为时序图和之后转化为状态图的过程变得困难。在协议描述中，同一时刻会发生一个或多个动作，即使这些动作在某种原因下相关也是如此。例如，聊天室不应该在收到请求之前发送接收或拒绝消息。这样的话，输出迹中出现“在时刻1请求；在时刻1接收”就是正确的，如果出现“在时刻1接收；在时刻1请请求”，那就是不正确的。 　　 　　一种可能的解决方案是使用tuple(t, s)表示时间，t是以秒计数的浮点时间，s是整数序号。以这种方式，正确的输出可以写成“在时刻(1.0s, 0)请求；在时刻(1.0s, 1)接收”。序列“在时刻(1.0s, 0)接收；在时刻(1.0s, 1)请求”则是不正确的。 　　 　　4.2 请求和消息模式 　　 　　请求模式如图二所示。Client首先会调用Manager的方法mrequest。然后Manager通过调用ChatRoom的方法request中继这个调用。ChatRoom立刻响应，回调Manager的方法maccept或mreject。然后请求Client会接收到由Manager中继的响应。 　　 　　图三是消息模式，在系统中随机产生消息，进行传递。注意ChatRoom在收到一次请求后故意延时一秒钟。在这两个时序图中，没有其它延时存在。 　　 　　4.3 类图和协议之间的一致性问题 [1] [2] [3] [4] 下一页