umlsysml

Activity Diagram: Reusing Activity/Action With different inherited type of object flow as output

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:

Solution

  • 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.