2

There is a class diagram that contains one class and this class has three operations (Oper1, Oper2, and Oper3) and three attributes (Attr1, Attr2, Atrr3). Now suppose:

1- Oper1 uses Attr1 and Attr2 to read from and write to them, 2- Oper2 uses Attr3 to read from and write to it, 3- Oper3 uses Attr1, Attr2, and Attr3 to read from and write to them.

Now how can I show this dependency/usage of attributes in class's operations in UML diagram? Is it necessary to show this kind of relation in UML?

Anmk
  • 193
  • 1
  • 9
  • The question I have is: why would you need to do that? – qwerty_so Oct 23 '21 at 20:56
  • @qwerty_so Because traceability is so important for me. Suppose that we have a software requirement (Req1) that is satisfied by Attr1, Attr1 is used in Oper1, and Oper1 is an operation of class1. Now, because of changing Req1, I need to know which class, operation and attribute are affected with this change. I am using EA that in traceability window I can trace the changes, so I need a diagram. – Anmk Oct 25 '21 at 06:48
  • I think that in this case your question is a duplicate of https://stackoverflow.com/questions/69594867/how-to-show-the-relationship-of-a-requirement-with-the-method-of-satifying-class – qwerty_so Oct 25 '21 at 08:30
  • @qwerty_so These questions are close to each other but talking about different concept. The link talks about traceability of requirements and this question talks about the relationship of attribute/operation of a class. Of course by having a relationship between attribute/operation, we can answer the question mentioned in the link too. – Anmk Oct 25 '21 at 12:45

2 Answers2

1

This kind of relationships are not documented in an UML class diagram. The class diagram defines the properties and the operations, but not how they relate in a particular implementation.

May be today oper1 uses Attr1 and Attr2; but maybe tomorrow it will also use other properties. You may however document this in a comment note, or --perhaps better-- in UML pre-condition and post-condition constraints.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Suppose that a requirement is changed by system team, in this case if you have this relationship, you will find changes of your software easily. – Anmk Oct 25 '21 at 12:47
  • @Anmk Class diagrams nevertheless don't support it. Are you looking for something like a [dependency graph](https://en.wikipedia.org/wiki/Dependency_graph) ? Nodes would be properties and operations, and arrows would represent ins and outs; But it's not UML. You could misuse activity diagrams, with actions to represent the operations, object flows to represent ins and outs, and use [central buffers](https://www.uml-diagrams.org/activity-diagrams-objects.html#central-buffer) to emulate the properties. But it's far-fetched and not fully in line with activity diagram semantics. – Christophe Oct 25 '21 at 17:29
  • I knew that class diagrams don't support it. I am trying to use activity diagram in such a way that I can model these type of relationship(s). I'm curious to know the others' idea. – Anmk Oct 27 '21 at 05:27
  • Why would class diagrams not support it? Dependencies are allowed anywhere. – Axel Scheithauer Oct 27 '21 at 16:34
  • What condition would the pre-condition specify? I don't see how this could be used for documenting a dependency. – Axel Scheithauer Oct 27 '21 at 16:38
  • @AxelScheithauer 7.8.4.1 "A Dependency is a Relationship that signifies that a single model Element or a set of model Elements requires other model Elements for their specification or implementation". Is it really the purpose to define behavioral dependencies in structural diagrams? – Christophe Oct 27 '21 at 17:54
  • @Christophe, Well, a dependency is a dependency. So, if it is between an operation and an attribute, why not show it in a structural diagram? Both elements are visible there. Of course, there could be a behavioral diagram, telling us exactly how this dependency is coming about. But in most cases, we don't want to model a method-behavior for every single operation. – Axel Scheithauer Oct 29 '21 at 07:19
1

If you want to just model the dependency, you certainly can do it. Either in a class diagram: class with dependencies between operations

Or in a matrix

dependencies shown in a matrix

Or simply in the model:

enter image description here

You could also define an activity as a method for each operation, which accesses the attributes with ReadStructuralFeatureActions and WriteStructuralFeatureActions. However, this would only add meaningful information, if you really want to completely specify the operations with this. Is this effort warranted?

Axel Scheithauer
  • 2,758
  • 5
  • 13
  • Interesting. I understood the dependencies to be structural. But maybe I am too narrow-minded here. Maybe my eyes are too old, but I wonder if it'll be as readable and enlightening as OP expects looking at the difficulties I have to follow the dashed lines with only 3 attributes and 3 operations, what do you think? Moreover, you'd need to add some stereotypes for expressing the reads and writes that the OP is expecting to document as well. – Christophe Oct 27 '21 at 18:07
  • The matrix (is it UML?) is a nice representation of a dependency graph if there are not too many elements. But the dependency graph would be be directed. Can your tool generate the matrix taking into account different stereotypes as well? – Christophe Oct 27 '21 at 18:09
  • 1
    @Christophe, I agree, the class diagram hurts the eyes. However, as the OP states, traceability is the purpose. So, nobody needs to look at the diagram. The dependencies will get evaluated with a model query, for example to find out whether a change affects a certain operation. – Axel Scheithauer Oct 28 '21 at 17:39
  • 1
    @Christophe, The matrix is not defined by UML, but neither is the model browser, that most, if not all, tools support. Why should a tool be limited in the ways to show the content of the model. The tool used here allows to show (and edit) any kind of relationship in a matrix. So different stereotypes for `«read»` and `«write»` would be possible. – Axel Scheithauer Oct 28 '21 at 17:40