Correct aproach to model network interaction in Enterprise Architect

user_2690527 0
Viewed 42

I have a class Actor whose instances send/receive network messages. (E.g. each instance of that class is part of a different process running on a different physical machine.) The network messages are serialized instances of classes MessageA and MessageB whose attributes are sent over the wire. An incoming message is handled by a callback method method of my Actor class. An ougoing message is triggered by calling a method of my Actor class. Hence, I started to model this situation in a class diagram like this:

Class Diagram

  • The network messages are "signals" in EA term, i.e. classes with a special prototype (for succinctness the attributes are left out)
  • My Actor-class is an usual class in EA with four corresponding methods

Now, I want to model a typical interaction and started to draw the following sequence diagram:

Sequence Diagram

The messages are no methods invocations, but are asynchronous and have kind "signal" which allows me to assign them the correct message type.

However, I wonder how I model

  1. the fact that a message with payload MessageA is handled by onMessageAReceived

  2. that method sendMessageA emits a message with payload MessageA

    (Note: In terms of my implementation it is correct, that sendMessageA returns void, because sending a network message is asynchronous, offloaded to the underlying OS and the method returns to its callee after having send the message.)

in the sequence diagram.

Maybe, my whole approach is completely wrong and I am trying to model something which cannot be modeled like that. In that case some pointers to the correct approach are highly welcome.

enterprise-architect sequence-diagram
1 Answers

Of course there's more than one way to model this (and it does not depend on the tool EA). So, you should ask which audience you are talking to, repsectively which their domain is basically.

Technical

A SD is well suited to show a physical transport. In that case you concentrate on the way how messages are sent. In this case you will have the physical operations shown as messages. E.g. using sockets, it would be some (a-)synchronous send(message) which assures that the content message is transported from A to B. This could be at any level of technical implementation from rough to single CRCs being sent (or how the operation is internally built to ensure packages are not lost).

Logical

In order to show a more logical aspect it's a good idea to have components (being deployed on multiple hardware) having ports (realizing some interface) along which you have an information flow (which is a connector you will find in EA) that can transport something (that is your message classes).

Overview

You might want to describe both aspects in your model. But likely you will have the focus on the one or other part depending on your overall domain.

There is no single way to model something. Models are always abstraction which is why we create models. They shall show reality, but more light weight.

user_33796530
Related