UML: how to model a protocol that involve Logic+Data structures+Modules

Question

I usually get into the task of modeling a protocol, which usually involve 3 main aspects:

Logic: (if (cond) action 1; else action 2)
Modules or devices: Module 1 send this message to Module 2, or client request the server.
Data structures: The client send this data (param1, param2..) to the server.

I am not sure how to represent theses 3 element in UML in a way that the relationship is understandable.

My main question is "How to represent these 3 elements in UML, in a way that make their relationship intuitive?"

What main diagram type to use? activity?
How to represent modules/devices? Swimlanes?
How to represent messages and messages structures? Object + class diagram?
Any other suggestion?

Example

To make the question more accurate, following it is a simple protocol:

 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.

 -

Following it is my attempt to model it with an activity diagram:

enter image description here

BobRodes · Accepted Answer

My first thought was an activity diagram, and it looks like yours does a good job of modeling the behavior you describe. I have a couple of observations that may inspire improvements:

I'm not sure I would use the start points on the server activities, given that the servers don't have any activity that isn't first initiated by the user.
I see multiple endpoints for single activity paths. There should be decision logic to decide which endpoint applies. For example, "Simple Request through G" and "Simple Server Operation" represent two conflicting endpoints for the same sequence of activities.
Those multiple endpoints imply that you can exit your system without going through your shutdown process, which seems unlikely.

I'll also give you a couple of generalizations that you might find helpful.

UML diagrams divide into two categories: behavioral and structural. Behavioral diagrams include Use Case, Activity, Sequence and State Diagrams, among others. Structural diagrams include Class, Object, Component and Deployment diagrams.

Activity and State diagrams, as umlcat mentions, are quite similar. The difference is really a matter of focus. Activity diagrams focus on behaviors, and State diagrams focus on the effects of the behaviors--how different activities cause changes in state.

Now, the main difference between Sequence and Activity diagrams (besides that they look different) is scope. Activity diagrams do a good job of modeling parallel behaviors and complex decision trees, whereas Sequence diagrams do a good job of modeling the behavior of a specific sequence of related activities in detail (they do not do a good job of modeling parallel behaviors and complex decision trees). For example, you might model each path through your activity diagram (a "path" being a line from your UI starting point to one of your endpoints) as a separate sequence diagram, going into deeper detail with each activity node as to what it actually does.

If you wish to model out exactly how you are going to implement the behavior that your activity diagram describes, then it is time to use a Class diagram.

Use case diagrams are less detailed than activity diagrams. Your use case diagram would probably have three use cases: initial setup, operations, and shutdown, and two actors, user and server. It would probably also have Generate URLs as an extension of initial setup, and maybe also extend operations with the two server activities. This would provide a high-level overview of the behavior you describe in your activity diagram. If this is useful in explaining the problem domain to your people, by all means go ahead and create one.

UML: how to model a protocol that involve Logic+Data structures+Modules

Example

Answers (2)

Related Questions