Question

我经常参与建模协议的任务，通常涉及3个主要方面：

逻辑:(如果（cond）行动1;否则行动2）
模块或设备：模块1将此消息发送到模块2，或客户端请求服务器。
数据结构：客户端将此数据（param1，param2 ..）发送到服务器。

我不确定如何以一种可以理解的关系来表示UML中的这3个元素。

我的主要问题是＆＃34;如何在UML中表示这三个元素，以一种使他们的关系直观的方式？＆＃34;

使用哪种主图类型？活动？
如何表示模块/设备？泳道？
如何表示消息和消息结构？对象+类图？
还有其他建议吗？

实施例

为了使问题更准确，遵循它是一个简单的协议：

 This is a protocol of synchronization between an user interface and a
 server with the program logic.

 =Start-up process=

 The user set the communication to synchronous (the
 user interface have to pull for changes every few seconds, only
 possible for low usage and simple programs) or asynchronous (the server
 send changes directly to the user interface)

 The user also set a general purpose URL (G), that point to the server.

 Async
     If the communication is async, the UI request to the server for 2 URL:
     * R : reception socket, to get informed about changes and update the UI
     * S : sending socket, to request for get/set/change/create data in 
           the server. 

     The UI open the R socket with the server.

 =Live process= 

 Sync: 
     If the communication is sync, the client ask to G any get/set/change/
     create operation.

 Async: 
     If the communication is async, the client request through S an operation. 
     The request contain:
     * the R ip+port
     * The UI element identifier to be updated (only for get operations)
     * Data requiere for the operation: the request and requiered data.

     The server save for every request following data:
     * The user that make the request (for example the R IP+port)
     * Unique reference to the UI element that will contain the data
     * Unique references to the data to be returned to the client (for example
       database.table.rowId.column) The user+ UI element is unique, so a new
       data reference will override the old data reference. That is a way from
       the server to save what each client is showing.

     After any change is made on a data, the new value is sent to every user
     that are showing this value through R.

 =Shutdown process=
 When the client close R, the server may drop/free every saved references 
 for this user.

 -

以下是我尝试使用活动图对其进行建模：

enter image description here

Answer 1

简短快速回答

在英国。一切都被认为是一个类的实例（A.K.A。＆＃34; Object＆＃34;）。

[1]使用什么主图类型？活动吗

用例图类图活动图（其他取决于）

[2]如何表示模块/设备？泳道吗

结构：类图逻辑：活动图+ Swimlanes

[3]如何表示消息和消息结构？对象+类图？

好。这在UML中应用得不是很好。

我已经解决了这个问题。

如您所述，消息也可以表示为对象，其中参数是属性。

发送单个消息可以表示为一个类，通过参数来响应或执行。

[4]还有其他建议吗？

阅读答案的其余部分。

长期无聊的答案

U.M.L。以面向对象的范式为中心。因此，像通信这样的场景可能看起来有点不合适，但是，仍然可以用UML来描述。

除了少数例外，使用事件/消息/信号通常与许多O.O.P无关。编程语言。

与许多程序一样，您可以从用例图表开始，表示与系统交互的 Actor 。

然后，您可能希望使用类图来描述系统的类/对象。

您的＆＃34;设备＆＃34;也可以被描述为类。

有一个User设备：

The user

可以将其建模为类的实例：

......................
..+----------------+..
..|     Client     |..
..+----------------+..
......................

然后：

The user set the communication to synchronous

User类有一个属性，（＆＃34; CommunicationMode＆＃34;）可以是：＆＃34; undefined＆＃34;，＆＃34; synchronous＆＃34;或＆＃34 ;异步＆＃34 ;. ＆＃34;未定义＆＃34;表示设备已关闭。

.........................
..+-------------------+..
..|      <<enum>>     |..
..| CommunicationMode |..
..+-------------------+..
..|[+] Undefined      |..
..|[+] Synchronus     |..
..|[+] Asynchronus    |..
..+-------------------+..
.........................

..................................
..+----------------------------+..
..|          <<class>>         |..
..|           Client           |..
..+----------------------------+..
..|[+] CommunicationMode: Mode |..
..+----------------------------+..
..................................

程序的逻辑可以用几种类型的图来描述，例如活动图，状态图，序列图。

状态图和序列图是活动图的特殊情况。所以，如果你不熟悉它们，你可能会坚持活动图（s）。

[正在建设中]

Answer 2

我的第一个想法是一个活动图，看起来你的人很好地对你描述的行为进行建模。我有一些可能会带来改进的观察结果：

我不确定我会在服务器活动中使用起点，因为服务器没有任何活动不是由用户首先发起的。
我看到单个活动路径的多个端点。应该有决策逻辑来决定应用哪个端点。例如，＆＃34;简单请求到G＆＃34;和＆＃34;简单服务器操作＆＃34;表示同一活动序列的两个冲突端点。
这些多个端点意味着您可以在不经过关机过程的情况下退出系统，这似乎不太可能。

我还会给你一些你可能会觉得有帮助的概括。

UML图分为两类：行为和结构。行为图包括用例，活动，序列和状态图等。结构图包括类，对象，组件和部署图。

正如umlcat所提到的，活动和状态图非常相似。差异实际上是一个焦点问题。活动图关注行为，状态图关注行为的影响 - 不同活动如何导致状态变化。

现在，序列和活动图之间的主要区别（除了它们看起来不同）是范围。活动图可以很好地对并行行为和复杂决策树进行建模，而序列图可以很好地对特定相关活动序列的行为进行详细建模（它们不能很好地建模并行行为和复杂决策树）。例如，您可以通过活动图（＆＃34;路径＆＃34;从UI起点到您的某个端点之间的一条线）对每条路径进行建模，作为单独的序列图，详细介绍每个活动节点至于它实际上做了什么。

如果您希望确切地说明如何实现活动图描述的行为，那么是时候使用类图了。

用例图不如活动图详细。您的用例图可能有三个用例：初始设置，操作和关闭，以及两个actor，用户和服务器。它可能还会生成URL作为初始设置的扩展，也可能使用两个服务器活动扩展操作。这将提供您在活动图中描述的行为的高级概述。如果这对于向您的员工解释问题域很有用，那么请务必先创建一个。

UML：如何建模涉及逻辑+数据结构+模块的协议

实施例

2 个答案: