Can I hide a inused signature when I show the model(when I execute the line "pred show{}
run show for 8")?
For inused signature, I mean the signature which are not connected by no arrow.
For example:
abstract sig TypeMessage{}
one sig RichiestaLogin, RichiestaRegistrazione, RichiestaShell
Not going into the details of my code, there are instances in which I use a message type and other instances in which their use, so that some istances remain unconnected.
I would not show those instances are not connected in my diagram of the model.
If you don't want them in your model, constrain your model (or probably better the 'show' predicate) to exclude models which have unconnected atoms (where 'connected' means whatever you want it to mean).
If you really want to allow them in the model instances, but exclude them just from the display, you can define a subset of TypeMessage which contains just those TypeMessage atoms which are not connected. Then customize your display theme to suppress display of members of that set.
If the only problem is that you find the unconnected atoms distracting, I'd try to learn not to be distracted by them.
Related
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:
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:
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.
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.
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.
I have three classes one is called
WorkCoordinator and it calls different service classes depending on an event passed to it, so if the event is trackIssue there is a TrackService class that handles some operations specifically for tracking and there is also a Track object. So you could have the following
WorkCoordinator -- (track issue) --> TrackService (has a list of Track objects)
How would you correctly represent these three in a UML diagram ? where everything starts with the workcoordinator which uses a TrackService and TrackService may have a function like add(Track track), where you would pass it a Track object to add to an array list within it say:
private ArrayList<Track> tracks;
and as add gets called, then a track is added to tracks.
Appreciate any insights, I was thinking something like this but may be totally wrong.
I have three classes one is called
Contrarily to an operation a class cannot be called, but it can be used.
WorkCoordinator -- (track issue) --> TrackService
when the event string is trackIssue the class WorkCoordinator uses the class TrackingService, but how ? Because in your diagram the class TrackingService only has the operation add that means that operation is called, even I have some doubt about that, more the fact we don't know from where the instance of Track given in argument comes from. If an other operation is called add it in the diagram.
About your diagram :
the role of the line between WorkCoordinator and TrackingService is unknown as it is, and then invalid. Because of the attribute trackingService probably you wanted to also show it as a relation, in that case the relation must completed.
TrackingService has two lists of Track, one though the attribute trackItems and an other one through the relation tracks. This is probably not what you wanted, and trackItems must be renamed tracks or the reverse.
to show the same thing through an attribute and a relation is legal in UML, but quite heavy because the reader must check they are the same thing, I encourage you to use only one of them, and to favor the relation when both classes are drawn.
your aggregation says TrackingService is composed of Track, are you sure this is the case and an aggregation must be used ?
How would you correctly represent these three in a UML diagram ?
The class diagram does not indicate at all that when the processed event is trackIssue the operation add (or an other) is applied on trackingService (with the right argument). Of course you can add a note to say that, but that note is a free text and only human can understand it.
To show that in a diagram you can use a sequence diagram or an activity diagram, depending on what you want to show.
The sequence diagram showing what happens during the execution of process can be (supposing a new instance of Track is created to be given in argument to add) :
event is supposed to be the argument of process, to name the instance of TrackingService I used trackingService being the name of the attribute, and item represents the created instance of Track to use it in the message add.
All of that seems vague, but this is normal because an interaction is not a behavior, and a sequence diagram focuses on message interchange between lifelines.
If you want to fully model the behavior of the operation process without ambiguity you can use an activity, and the diagram can be :
Additional remarks :
An event is generally much more than a name like trackIssue, so the parameter of process is not a string or that string is a complex form.
Track has getter/setter for the id but not for the name, seems strange. Are you sure the id is not only set (with name) when an instance is created ?
I am trying to create UML diagram. For example I have a class A with method a() and class B that extends A and overrides method a(). Is there any standard to indicate overridden methods in UML?
No, there is no specific indicator for operations that override operations on a parent class.
If the signature matches it overrides the operation on the parent.
The norms says on p. 101:
Inherited members may also be shown in a lighter color to help distinguish them from non-inherited members. A conforming implementation does not need to provide this option.
Sadly, my tool (EA) does not support that.
The simplest method is to duplicate only the operation signatures of those operations you are going to override. That will make it clear that you are overidding something.
By just looking to Class2 there is no way to tell that b is actually an override. However, if someone wants to deal with Class2 he must know that it's a subclass - and thus will know that b is an override.
Note: The UML 2.5 specs are ambigous about the caret use. While (on p. 100) they say
Members that are inherited by a Classifier may be shown on a diagram of that Classifier by prepending a caret ’^’ symbol ...
the syntax below explictely mentions only properties and connectors and this passage
Analogous notations may be used for all NamedElements that are inheritedMembers of a Classifier to indicate that they are inherited.
As indicated in that answer https://stackoverflow.com/a/28932482/2458991 there is a specific indicator to indicate a member (for instance an operation) is inherited, but that indicator is not mandatory, the norm says :
Members that are inherited by a Classifier may be shown on a diagram of that Classifier by prepending a caret ’^’ symbol to the textual representation that would be shown if the member were not inherited.
So, having :
B does not override oper
But having :
we cannot know except if we are sure the ^ is always used in the model as in previous diagram
[edit]
Notice the norm use two times the words member (and not properties) in that sentence, and Class inherits (indirectly) Classifier, so that applies for operations.
As noticed in an other answer the norm says also :
Inherited members may also be shown in a lighter color to help distinguish them from non-inherited **members*.
so again two times members rather than properties, and the fact they use also clearly reference the fact there is an other way which is the ^. So two consistent sentences indicating ^ applies to operations
[warning]
I used BoUML to make the diagrams and in the first you can see "^oper()" but I 'cheated' to do that naming the corresponding operation "^oper", there is no option to show a ^ in a diagram to indicate an operation or other member is inherited
A few days ago a friend pointed out to me that I had a wrong idea of composition in UML. She was completely right, so I decided to find out what more I could have been wrong about. Right now, there is one more thing that I have doubts about: I have a circular dependency in my codebase that I would like to present in UML form. But how.
In my case the following is true:
Both A and B have a list of C
C has a reference to both A and B to get information from.
C cannot exist if either A or B stops to exist
Both A and B remain to exist after C is deleted from A and/or B
To model this, I've come up with the following UML (I've ommited multiplicities for now, to not crowd the diagram.)
My question is, is this the right way to model such relations?
Problems
Some facts to keep in mind:
Default multiplicity makes your model invalid. A class may only be composed in one other class. When you don't specify multiplicity, you get [1..1]. That default is sad, but true.
The UML spec doesn't define what open-diamond aggregation means.
Your model has many duplicate properties. There is no need for any of the properties in the attribute compartments, as there are already unnamed properties at the ends of every association.
Corrections
Here is a reworking of your model to make it more correct:
Notice the following:
The exclusive-or constraint between the associations means only one of them can exist at a time.
Unfortunately, the multiplicities allow an instance of C to exist without being composed by A or B. (See the reworked model below.)
The property names at the ends of all associations explicitly name what were unnamed in your model. (I also attempted to indicate purpose in the property names.)
The navigability arrows prevent multiple unwanted properties without resorting to duplicative attributes.
Suggested Design
If I correctly understand what your model means, here is how I would probably reverse the implementation into design:
Notice the following:
Class D is abstract (the class name is in italics), meaning it can have no direct instances.
The generalization set says:
An instance cannot be multiply classified by A and B. (I.e., A and B are {disjoint}.)
An instance of D must be an instance of one of the subclasses. (I.e., A and B are {complete}, which is known as a covering axiom.)
The subclasses inherit the ownedC property from class D.
The composing class can now have a multiplicity of [1..1], which no longer allows an instance of C to exist without being composed by an A or a B.
Leave away the open diamonds and make them normal associations. These are no shared aggregations but simple associations. The composite aggregations are ok.
In general there is not much added value in showing aggregations at all. The semantic added value is very low. In the past this was a good hint to help the garbage collection dealing with unneeded objects. But nowadays almost all target languages have built-in efficient garbage collectors. Only in cases where you want an explicit deletion of the aggregated objects you should use the composite aggregation.
I have one object, call it type A which has four data members of another object type, call it B. How do I show this in a UML class diagram so that its clear there are four B objects type in every A object?
Is the only solution to put "4" next to the arrow head pointing to class B?
It depends on what you want to achive, in sense of how you need to distinguish between those objects in context of their association/link, that is - what kind of role they play:
if there are all equal, no special differences in their role in context of A, them a multiplicity 4..4 will do the job, naming the association end properly (for example my_Bs)
If these object play different role in connection with A, then you can use separate associations with lower multiplicities each one, 2, 3 or even 4 pieces (for example, if B is a Wheel and A is Car, then you can put 2 associations with multiplicities 2..2 each, and call then "front" and "rear", or even 4 associations "front_left", "front_right"...)
Here is how the both cases look like. On the second one I showd different possible options (with max. 5 elements of B), just to give you an idea.
It's probably clear by now, but the fundamental concept here is the role of the association end.
Aleks answer is the best. However you can also represent the multiplicity in one box like this :
You cal also use composite structure diagram. See example below:
From my point of view, myBs defined as an attribute of type B on class A has a different meaning of myBs defined as a association's role between A and B (which is also different as defining it as a composition/aggregation).
If it is an attribute, then it's not a role. In that case, there is only a simple dependency relation between A and B, which must appear in the diagram.
I think that problem comes from unconsciously think from a "Relationnal Data (BMS)" and/or a "Object Oriented Programming" point of view, but UML is not intended for that.
:)