CODEWITHSUNDEEP
umlclass-diagram
mon
mon

Reputation: 22244

Is there a way to specify an action in a class diagram that happens at runtime

Question

If there is a way to capture actions or behaviors in a class diagram, if possible, e.g. creates the links at runtime for associations, or updating objects states.

Background

In my understanding, Class Diagram is to capture static relationships, such as class X has-a class-Y as a member, or has a reference to class Z. Hence, I suppose capturing runtime actions or behaviors are not meant to be in a Class Diagram, but I wonder if there could be a way to inject the knowledge of what is happening at runtime among the objects of the classes.

For instance, in the diagram where I am trying to capture AWS ECS ER.

Please suggest a UML way by which I can capture "publish port" or "update TargetGroup" in the class diagram, if any.

enter image description here

Others

Please correct if any mistakes or incorrect usage of notations in the diagram. It would be highly apprciated.

Upvotes: 0

Views: 868

Answers (2)

Gerd Wagner
Gerd Wagner

Reputation: 5673

UML is quite bad at integrating class modeling with behavior (i.e. event/action) modeling.

However, it is natural to model the actions of active objects (of type A) in the form of operations in the corresponding class A.

You could then express their effects (e.g., changing the value of a property of an object, or creating a new link)

  1. with the help of OCL post-conditions, or
  2. in a related activity diagram where activity/action rectangles correspond to operations in the class diagram.

When using an activity diagram, you could use partitions (or 'swim lanes') for representing your active objects.

Upvotes: 1

qwerty_so
qwerty_so

Reputation: 36305

Two answers (about the behavior):

  • Yes, you can do than.

  • No, you must not do that.

So what? Class diagrams are meant to show the static relations between classes. The reason for associations between classes exists only for a design reason. The architect has the feeling that due to a described (use case) behavior it should be that way. When that is settled (though not in concrete) you model the various behavior (either with activity or sequence diagrams) which illustrate certain collaborations realizing use cases. In the cause of this design step it can be necessary to adapt the static relations. And that might again affect the shown behavior. Or even can have the conclusion that the use case activities need to be adapted (and even the requirement can be proven to be not implementable the one or other way because...).

Rather than mangling the associations you could make activity diagrams with call behaviors or show messages within sequence diagrams created for collaborations.

A better way would be to put the relevant part of teh static class design additionaly on a SD or AD. As per UML spec you can (and should) mix all UML elements on all diagrams (if it helps communicating the design reasons).

For the ports: you will show them in component diagrams. A port is an element for a component and shows interfaces. These are usually delegated to classes inside the component realizing or requiring the interfaces. You will show ports as small squares on the border. I haven't seen them listed in the operations compartment (that's likely not correct). If at all textual you would need a separate compartment marked as "list of ports" or the like. Just putting them in one row with attributes isn't right.

Upvotes: 1

Related Questions