2

I have a question regarding modeling on an Activity Diagram that has been bothering me for some time and I was not able to find any answers / Convention anywhere.

Here is an example to better understand my question:

Let say that I have two class named "flat" and "house". both are a generalization of the class "housing". housing contain an attribute "residents" for the person living in it. flat contain an attributes "floor" that says at which floor the flat is.

Here is the class diagram: class diagram of what is explained above

In an activity diagram, I want to represent the action of giving persons a housing. this action can take either house or flat as input (so the use of "housing" type for the input pin is correct I think) as well as an undefined number of people. I want this action to give an updated house or flat as output (not an updated housing as this would mean that information specific to the house or flat would be lost. I don't really know if I must create two actions (one for house and another for flats) or if there is a way to reuse the action for both class and have a correct output out of it.

Here is the activity Diagram: Activity diagram of what is explained above

My question is: how to represent in an activity diagram, an action that is the same for different type of Object flows as input, and that give the updated Object flow as output (that may be therefore of different type)?

nb:

  • all type of object flow are class and inherit from a same other class.
  • I'm representing this in modelio but first had this issue in Cameo.
  • I'm Trying to fit as best as I can within the rules of UML Language.
Jason Aller
  • 3,541
  • 28
  • 38
  • 38
Mygntay
  • 45
  • 5

2 Answers2

3

Cameo is right in rejecting this model. Give Flat Floor expects a Flat and will not work with a House, but Assign Resident to Housing could return a House. I know, in your context it can only return a Flat, but how should the tool know that?

The correct way to capture this fact would be to add a postcondition to Activity Assign Resident to Housing that states that the type of the input and output pin will be the same.

However, it would be really hard to define a complete set of compatibilty rules that takes into account all the global and local pre- and postconditions and the tools would also be hard pressed to validate a model according to these rules. Therefore the UML specification choose the easy road and simply doesn't allow to connect the pins.

The solution is to use the transformation property of the ObjectFlow. Just assign an OpaqueBehavior that casts the Type House to the Type Flat. Cameo will then accept the model. It is the modelers responsibility to ensure, that this cast will always work, since no exception handling can be defined here. Maybe this should be documented with a local postcondition.

In your specific example there is an even easier solution: simply fork the ObjectFlow of Type Flat and omit the OutputPin of Assign Resident to Housing.

As a side note: Due to a bug in Cameo, you can change the type of the OutputPin to a more specific Type than that of the ActivityParameter. This is correct for InputPins, but should be the opposite for OutputPins. You could use this to let the Parameter be of type House, but the OutputPin-Type would be Flat.

Axel Scheithauer
  • 2,758
  • 5
  • 13
2

The two flows (top object and lower control) in the blue frame could stay as they are. Give flat floor would commence only when it receives a Flat object and the control token is sent. In order to make the right action sort of optional I would just use the object flow, thus only triggering when a Flat object is passed. That would just be enough and no additional control flow is needed.

To make things clear I would also add a guarded flow from the Assign action to an exit reading [ house was assigned ] or the like.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • thanks for your answer! Cameo still think that this kind of use of type for object flow (descending the generalization link (from housing to flat)) is incorect (it's rasing an error) but then this error is more tool-related right ? – Mygntay Jun 09 '21 at 21:13
  • This is not a generalization but an object flow. I don't know Cameo (only by name). An object flow has nothing to do with generalization. But I suspect this a tooling issue. – qwerty_so Jun 10 '21 at 06:44
  • The semantics of an object flow with incompatible types is not that the token only traverses, when the actual type happens to be consistent. The UML says the target type must be a supertype. Therefore, the model is inconsistent and has no meaning. – Axel Scheithauer Aug 09 '21 at 19:10
  • `[house was assigned]` will never be true, since the Activity always receives a Flat. – Axel Scheithauer Aug 09 '21 at 19:11
  • @AxelScheithauer Too late for me now, but you seem to have spotted something in that tiny writing my aged eyes did not recognize :-) – qwerty_so Aug 09 '21 at 22:22
  • @AxelScheithauer I guess you are correct with your answer (as said, I don't know Cameo) and I never stumbled across such a validation issue. And honestly I have seen few real world models that went this far into details with activities. – qwerty_so Aug 10 '21 at 06:55