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

我通常从事协议建模的工作，这通常涉及3个主要方面：

逻辑：如果条件动作1；其他行动2 模块或设备：模块1将此消息发送到模块2，或客户端请求服务器。 数据结构：客户端发送此数据param1，param2。。到服务器。 我不知道如何在UML中以一种关系可以理解的方式表示这3个元素

我的主要问题是如何在UML中表示这三个元素，使它们的关系更直观

要使用的主要图表类型是什么？活动 如何表示模块/设备？泳道？ 如何表示消息和消息结构？对象+类图？ 还有其他建议吗？ 实例 为了使问题更准确，以下是一个简单的协议：

 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.

 -

下面是我尝试用活动图对其建模的过程：

简短快速的回答

在U.M.L.中，每件事物都被认为是一个A.k.A类对象的实例。

[1] 要使用的主要图表类型是什么？活动

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

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

结构：类图 逻辑：活动图+泳道

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

好。这在UML中没有很好的应用

我一直在做这件事

正如您所提到的，消息也可以表示为对象， 其中参数是属性

单个消息的发送可以表示为一个方法，由一个类用参数响应或执行

[4] 还有其他建议吗

读剩下的答案

冗长乏味的扩展答案

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

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

对于许多程序，您可以从用例图开始， 指示与系统交互的参与者

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

您的设备也可以描述为类

有一个用户设备：

可以建模为类实例的：

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

然后：

用户类有一个属性CommunicationMode，可以是：未定义、同步或异步。未定义表示设备已关闭

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

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

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

状态图和序列图是活动图的特例。因此，如果你对它们不是很精通，你可以坚持使用活动图

[施工中]

简短快速回答

在U.M.L.中，每件事物都被认为是一个A.k.A类对象的实例。

[1] 要使用的主要图表类型是什么？活动

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

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

结构：类图 逻辑：活动图+泳道

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

好。这在UML中没有很好的应用

我一直在做这件事

正如您所提到的，消息也可以表示为对象， 其中参数是属性

单个消息的发送可以表示为一个方法，由一个类用参数响应或执行

[4] 还有其他建议吗

读剩下的答案

冗长乏味的扩展答案

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

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

对于许多程序，您可以从用例图开始， 指示与系统交互的参与者

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

您的设备也可以描述为类

有一个用户设备：

可以建模为类实例的：

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

然后：

用户类有一个属性CommunicationMode，可以是：未定义、同步或异步。未定义表示设备已关闭

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

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

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

状态图和序列图是活动图的特例。因此，如果你对它们不是很精通，你可以坚持使用活动图

---

[正在建设中]

我的第一个想法是活动图 m、 看起来你的模型很好地模拟了你描述的行为。我有几个观察结果可能会激发改进：

我不确定我是否会在服务器活动上使用起始点，因为服务器没有任何不是由用户首先发起的活动。 我看到单个活动路径有多个端点。应该有决策逻辑来决定应用哪个端点。例如，通过G的简单请求和简单服务器操作表示相同活动序列的两个冲突端点。 这些多个端点意味着您可以退出您的系统而不必经历关闭过程，这似乎不太可能。 我还会给你一些你可能会觉得有用的概括

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

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

现在，序列图和活动图的主要区别除了它们看起来不同之外，还在于范围。活动图能够很好地建模并行行为和复杂决策树，而序列图能够很好地建模相关活动的特定序列的行为。它们不能很好地建模并行行为和复杂决策树。例如，您可以通过活动图对每个路径进行建模—路径是从UI起点到其中一个端点的一条线，作为一个单独的序列图，深入了解每个活动节点的实际功能

如果您希望准确地模拟出如何实现活动图所描述的行为，那么是时候使用类图了

---

用例图不如活动图详细。您的用例图可能有三个用例：初始设置、操作和关闭，以及两个参与者，用户和服务器。它可能还将生成URL作为初始设置的扩展，还可能使用两个服务器活动扩展操作。这将提供您在活动图中描述的行为的高级概述。如果这有助于向您的员工解释问题领域，请尽一切努力创建一个问题领域。

我的第一个想法是一个活动图，看起来您的活动图很好地模拟了您描述的行为。我有几个观察结果可能会激发改进：

我不确定我是否会在服务器活动上使用起始点，因为服务器没有任何不是由用户首先发起的活动。 我看到单个活动路径有多个端点。应该有决策逻辑来决定应用哪个端点。例如，通过G的简单请求和简单服务器操作表示相同活动序列的两个冲突端点。 这些多个端点意味着您可以退出您的系统而不必经历关闭过程，这似乎不太可能。 我还会给你一些你可能会觉得有用的概括

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

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

现在，序列图和活动图的主要区别除了它们看起来不同之外，还在于范围。活动图能够很好地建模并行行为和复杂决策树，而序列图能够很好地建模相关活动的特定序列的行为。它们不能很好地建模并行行为和复杂决策树。例如，您可以通过活动图对每个路径进行建模—路径是从UI起点到其中一个端点的一条线，作为一个单独的序列图，深入了解每个活动节点的实际功能

如果您希望准确地模拟出如何实现活动图所描述的行为，那么是时候使用类图了

用例图不如活动图详细。您的用例图可能有三个用例：初始设置、操作和关闭，以及两个参与者，用户和se

---

---

服务器。它可能还将生成URL作为初始设置的扩展，还可能使用两个服务器活动扩展操作。这将提供您在活动图中描述的行为的高级概述。如果这有助于向您的员工解释问题域，请务必创建一个问题域。

模块或设备也可以表示为对象。我同意消息/事件作为类的一部分的想法，在UMLIn中不是很有表现力。这个例子中，客户端是一个设备，服务器是另一个设备，所有这些逻辑都应该是它们的一部分。如果我将它们表示为对象，如何做到这一点？您可以从这里获得示例图。我将其放在注释中，因为链接将来可能会不可用：URL是什么意思？在这种情况下，协议用于与服务器通信的web用户界面。URL是服务器的URL，例如：www.example.com/myapp.phpModule或设备也可以表示为对象。我同意消息/事件作为类的一部分的想法，在UMLIn中不是很有表现力。这个例子中，客户端是一个设备，服务器是另一个设备，所有这些逻辑都应该是它们的一部分。如果我将它们表示为对象，如何做到这一点？您可以从这里获得示例图。我将其放在注释中，因为链接将来可能会不可用：URL是什么意思？在这种情况下，协议用于与服务器通信的web用户界面。URL是服务器的URL，例如：www.example.com/myapp.phpThank感谢您的详细解释：-类图是一个很好的补充，我还应该为每种消息类型制作它们。你还没有提到我的活动图，我应该知道你批准了吗？此外，您还向我推荐了用例图，但它在这种情况下很有用？对于行为方面，请不要错过几乎一体化的@Adrian Maire，您的活动图是一个良好的开端，但是，您可能需要为端口S、G添加额外的泳道，其他人，即使他们是客户的一部分。@Adrian Maire用例在这种情况下并不相关，但有助于将所有内容放在一个更一般的概念中，将细节留给其他图表。通常，一个用例可能会被分成几个较小的用例。感谢您的详细解释：-类图是一个很好的补充，我也应该为每种消息类型制作它们。你还没有提到我的活动图，我应该知道你批准了吗？此外，您还向我推荐了用例图，但它在这种情况下很有用？对于行为方面，请不要错过几乎一体化的@Adrian Maire，您的活动图是一个良好的开端，但是，您可能需要为端口S、G添加额外的泳道，其他人，即使他们是客户的一部分。@Adrian Maire用例在这种情况下并不相关，但有助于将所有内容放在一个更一般的概念中，将细节留给其他图表。通常，一个用例可以被分成几个较小的用例