This is correct for InputPins, but should be the opposite for OutputPins. 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.Īs 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. Maybe this should be documented with a local postcondition. It is the modelers responsibility to ensure, that this cast will always work, since no exception handling can be defined here. Just assign an OpaqueBehavior that casts the Type House to the Type Flat. The solution is to use the transformation property of the ObjectFlow. Therefore the UML specification choose the easy road and simply doesn't allow to connect the pins. 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.
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. I know, in your context it can only return a Flat, but how should the tool know that? Give Flat Floor expects a Flat and will not work with a House, but Assign Resident to Housing could return a House. I'm Trying to fit as best as I can within the rules of UML Language.Ĭameo is right in rejecting this model.I'm representing this in modelio but first had this issue in Cameo.all type of object flow are class and inherit from a same other class.
#Modelio sysml ports how to#
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)? 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. 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.
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. In an activity diagram, I want to represent the action of giving persons a housing. Housing contain an attribute "residents" for the person living in it.įlat contain an attributes "floor" that says at which floor the flat is. both are a generalization of the class "housing".
Let say that I have two class named "flat" and "house". Here is an example to better understand my question: SysML 1.2 defines flow ports as a stereotype “FlowPort” that extends UML ports and adds an attribute “direction” of enumeration type “FlowDirection”.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. Analyzing the XMI file with SDMetrics 2.3 and the new project files for SysML, I noticed that SDMetrics did not import the flow ports – block metrics “AtomicFlowPorts” and “NonAtomicFlowports” were both zero. I then exported the model to XMI, using the export options “OMG UML 2.3” and “with Modelio annotations”. Both are freely available from I created a small SysML model in Modelio, with a SysML block and some flow ports on it. In this post we’ll look at a case study how to adapt SDMetrics’ XMI import to the idiosyncrasies of a modeling tool.įor this case study, I used the open source UML tool Modelio 2.1.0, with the SysML Architect module 2.1.4. I may have mentioned it before on this blog, but UML model interchange via XMI is difficult in practice.
0 kommentar(er)
