What is the notation for an Exception Handler in UML activity diagrams? Is it just the lightning bolt? Or more than that?
According to the specification v2.5.1 page 404:
An ExceptionHandler is shown by drawing a “lightning bolt” symbol from the boundary of the protectedNode to a small square on the boundary of the ExceptionHandler.
To me, this sounds like a recursive explanation.
According to the abstract syntax (page 403), exception handlers are part of their protected node and are associated to the handlerBody (ExecutableNode), the exceptionInput (ObjectNode), and to exceptionTypes (Classifier).
My understanding is, that the exception handler is just the lighning bolt. The handlerBody, its objectNode, and the protectedNode are separate entities using their own notation.
Is someone able to clarify this?
The wording in the specs is sometimes confusing. The lightning is an InterruptFlow and the handler is an ExecutableNode. There are quite some examples in the specs (pp. 403 of UML 2.5)
You need four things to show exception handling in an AD:
Some Action (I left out control flows from/to other actions)
An InterruptibleActivityRegion (the dashed boundary)
An ExceptionHandler with a ObjectNode to accept an exception
And the InterruptFlow (shown by the bolt)
You can only have the bolt go out of the interruptible region. And like usual object flows you can attach guards to that bolt.
In order to show details of the exception handling you can place call behavior inside the handler.
To specify exception types you can do it as shown in the specs on p. 403 of UML 2.5:
You are right the Abstract Syntax seems more clear than the description for me.
Exception Handler might be see like an edge.
It is owned by its source, aka the protectedNode for the Exception Handler, and referring its target, aka the exceptionInput (owned by the handlerBody) in the Exception Handler case.
Of course in most of the case the protectedNode and handlerBody are two differents Executable Node with their own notation (Structured Activity, Action ,etc. ).
Last point is the exceptionType Classifier which is a reference to any Classifier on your model.
Hoping it clarifies things.
EBR
You are right - ExceptionHandler is a lightning bolt.
According to the Abstract Syntax diagram below, ExceptionHandler is an Element that represents a relationship between four other instances: ExecutableNode (protectedNode), ExecutableNode (handlerBody), ObjectNode (exceptionInput) and Classifier (exceptionType)
So the documentation is mostly precise (with my minor modification - I replaced the second ExceptionHandler with handlerBody):
The notation for ExceptionHandlers is illustrated in Figure 15.62. An ExceptionHandler is shown by drawing a “lightning bolt” symbol from the boundary of the protectedNode to a small square on the boundary of the handlerBody. The name of the exceptionType is placed next to the lightning bolt. The small square is the exceptionInput node.
Related
What is a UML fragment is using in a case representing a check operation that either stops the further execution on a failed check or lets it go, kind of a programming statement if role != 'admin': break:?
I found the assert fragment seems to fit the case.
The idea on a diagram:
Is the fragment used properly to represent that operation change_sensetive_settings() is executing only if a user has admin role?
I'm not a big fan of assert, which seems to be meant for visual procedureal programming rather than clean design of valid behavior. There is not much information on assert fragment in the standard:
The interactionOperator assert designates that the CombinedFragment represents an assertion. The sequences of the operand of the assertion are the only valid continuations. All other continuations result in an invalid trace.
But the way assert is used here, seems confusing in this regard: you just show a constraint { user.role == 'admin } on the server lifeline, whereas the continuation will result in a message being initiated on the client side.
To disambiguate this diagram, I'd recommend to enclose in the assert fragment the sequence made of the register_user() message, followed by the return message and your constraint. This would clearly relate the outcome regarding the user role constraint to the registration.
But this only tells a part of the story. Because, what does it mean in pratice that "All other continuations result in an invalid trace" ? Assert, just tells an assumption. Is there anything ahead of this interaction that makes this assumption realistic? If not what should happen if the user has insufficient authorisations?
For all these reasons, I'd rather recommend to use here and alt to show the normal flow, but also suggest that if the user does not have the right authorisation, something should happen (and on which side: client or server).
No, I think assert is not used correctly. Here is why:
The specification defines:
The interactionOperator assert designates that the CombinedFragment
represents an assertion. The sequences of the operand of the assertion
are the only valid continuations. All other continuations result in an
invalid trace.
That means, the state invariant {user.role='admin'} is the only valid continuation after the reply to the register_user() message. This would rule out other outcomes. I don't think, this is what you had in mind.
So, simply remove the assert fragment. Since the sequence diagram only shows one possible scenario, it doesn't mean, that other scenarios are not valid. You could have another sequence diagram, where the state invariant is {user.role='student'}.
If you want to show more scenarios in one diagram, you could use an alt fragment. However, as others have pointed out, the purpose of the sequence diagram is not visual programming. Therefore, striving for a complete description of all possible scenarios is not appropriate.
minor mistakes
There are some minor mistakes in the diagram. Most of them have been pointed out by others, but to make this a complete answer:
The first message could be a found message. Then the circle would be filled and the name of the message would be on the arrow. It could also come from a gate. This would be shown by originating the arrow from the frame. I would recommend the latter.
The state invariant should probably move down below the reception of change_sensitive_settings because the user could still try to change them. Only the server can decide to reject this request. Or it must move to the client lifeline, if you want to specify that the client only sends the message, if s/he is an admin.
The arrow at the end of the diagram should be dashed, since it is the reply to the synchronuous message it begins with. And again, it should end in a black circle denoting a lost message or, better, at the frame of the diagram.
Given a class inheritance hierarchy:
which says:
class S inherits A1 and A2
class A1 and A2 inherits B1
class A2 inherits B2
class B2 inherits C1
and for class A1, B1, B2, C1, they have classifierBehavior attribute setted, while
the class S has no classiferBehavior.
Now the question is, when I run simulation for class S, then what behavior should be executed?
In Cameo Systems Modeler, the simulation engine will execute classifier behavior of A1, B1, and B2.
Is this the correct way and can be derived from UML spec?
The UML specification doesn't tell us how to deal with multiple inherited classifierBehaviors. However, the fUML specification says:
fUML 1.5 (page 151): [5] startBehavior [...] create a classifier behavior invocation for each of the types of the object of this object activation which has a classifier behavior [...].
So, I think the Cameo simulation engine works as specified, since the supertypes are in the list of types an object has. And, it really makes sense. If something is of two types, it should exhibit the behavior of both types. For example an inverter-charger will react to the events an inverter and a charger reacts to.
One thing I didn't find in the specification is, that when a Class has a classifierBehavior, the inherited behaviors should be replaced by it. I think it makes sense, because otherwise the inherited behaviors could never be changed. The simulation engine does exactly this.
Now, it is possible, that you want to select one of the inherited behaviors instead of defining a new one or executing them concurrently. This could be done by defining an empty Behavior with a generalization to the inherited classifierBehavior and assign this as classifierBehavior. This doesn't work in the simulation engine though. fUML excludes redefinition of ActivityNodes, so this could be an explanation why Activity generalization doesn't work. However, the "Precise Semantics of State Machines" specification allows redefinition of states.
So the only way I found was to create a new classifierBehavior and call one of the inherited behaviors.
The situation for resolving the method of an operation is different. For example it could have an output. Here only the modeler can decide, which output shall be returned. This is done by defining a new version of the operation that redefines both old versions and select the behavior from the desired ancestor as method of the new operation. I think this is fairly straight forward and no reason for rejecting multiple inheritance.
I skimmed the UML 2.5 specs and found this paragraph on p. 288:
If the Class of the receiving object owns a method for the Operation identified in the CallEvent, then that method is the result of the resolution. Otherwise, the superclass of the Class of the receiving object is examined for a method for the Operation, and so on up the generalization hierarchy until a method is found or the root of the hierarchy is reached. If a Class has multiple superclasses, then all of them are examined for a method. If no method is found, or a method is found in more than one ancestor Class along different paths, then the model is ill-formed for this resolution process and it results in no method.
So there you are. It's not valid to have multiple behaviors defined. Other than that you can/must override the behavior with something new.
Suppose I have some Class (specialization of BehavioredClassifier) with three operations A(), B() and C() and the operation C just calls operation A and then B. UML's CallOperation action (see 16.3.3.1 Call Actions) requires target object which in this case will be a context object in UML parlance as described in section 13.2.3.4 Behaviored Classifiers of UML Specification:
a Behavior that is the ownedBehavior of a BehavioredClassifier has that BehavioredClassifier as its context... If a Behavior has a context , then an execution of the Behavior always has an associated context object that is an instance of the context BehavioredClassifier (as long as that BehavioredClassifier is instantiable)
UML Activity diagram will look rather ugly due to Read self activity (see 16.4.3.4 Read Self Actions in UML Specification):
I have a feeling that I read somewhere that Read self can be omitted under some circumstances and target may be assumed to be context object in that case.
Is there such clause in UML documentation?
I couldn't find such clause in UML Specification, but found the solution, described below.
First so called ActionInputPin is to be used for target. According to paragraph 16.2.3.3 Pins:
An ActionInputPin provides values by executing another Action. When an Action is enabled by other means, the
fromActions on any ActionInputPins owned by the Action are also enabled. The fromActions must execute before the Action owning the ActionInputPins, and the outputs of the fromActions are placed in the corresponding ActionInputPins. The process recurs on any ActionInputPins of the fromActions. In the case that ActionInputPins are used for all inputs, this forms a tree structure that is an Action model of nested expressions, bottoming out at Actions that have no inputs (such as ReadVariableActions or ReadSelfActions)
Then Annex B: UML Diagram Interchange of UML Specification that
... enables interchange of the purely graphical aspects of UML models that modelers have control over, such as the position of shapes on a diagram and line routing points (UML DI). This information must be interchanged between tools to reproduce UML diagrams reliably.
states in paragraph B.4.3 Activity Diagram Labels that
ActionInputPins with fromActions that are ReadSelfObjectActions may be shown in a shorthand notation that shows only the ActionInputPin and nearby the string “self” interchanged as a UMLLabel with the ReadSelfObjectAction as modelElement.
The above clause is illustrated in table Table B.1 UML Shapes as follows:
Thus the model in question is transformed into the neat version shown below:
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
I'm taking a Data Analysis course, we're covering UML class diagrams. I keep getting confused by the terminology of methods (operations) and constructors. What is the difference between a method and a constructor? Any explanation would be greatly appreciated, the light bulb for this just hasn't lit yet and hope some outside perspectives will help. Thank you in advance!
Some of the confusion has historical reasons where terms were defined only partially (or not at all). The current UML spec 2.5 defines on p. 114
9.6.3.1 Operations
An Operation is a BehaviorialFeature of an Interface, DataType, or Class. An Operation may be directly invoked on instances of its featuringClassifiers. The Operation specifies the name, type, Parameters, and Constraints for such invocations.
Sounds a bit like blurb, but basically this is what a programmer would call a function.
Method in contrast (which formerly has been used alternatively to Operation) is defined on p. 13
For example, an operation owned by a class may have a related method that defines its detailed behavior.
So the method is the "how to" of an operation and can be described by various means like e.g. a StateMachine and more.
Finally a Constructor is a certain operation which by is executed during initialization of an object. On p. 15:
Therefore, when modeling the detailed behavior of the instantiation of a classifier, it is a modeler responsibility to ensure that the modeled behavior carries out the proper initialization of any attributes with default values once the object is created. (This is often done by encapsulating the instantiation behavior for a class in a constructor operation – see sub clause 11.4 – in which case the initialization of the attributes becomes an implicit postcondition for the constructor.)