![]() ![]() 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.įlat contain an attributes "floor" that says at which floor the flat is. 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. ![]() ![]() 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'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. 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. 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. 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.Ī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. 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.UML 2 Component Diagrams: An Agile IntroductionĬomponent-based development (CBD) and object-oriented development go hand-in-hand, and it is generally UML 2 component diagrams as an architecture-levelĪrtifact, either to model the business software architecture, the technical software architecture, or more often Recognized that object technology is the preferred foundation from which to build components. Physical architecture issues, in particular hardware issues, are Than not both of these architectural aspects. In fact I'll often iterate back and forth between these diagrams.Ĭomponent diagrams are particularly useful with larger teams. YourĬycle 0 should focus on identifying the initial architectural landscape for your system. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |