I have a case that the application will destroy an object when condition is met. If the object is not destroyed, it will be used in later part in the sequence. I was wondering how to model that in sequence diagram.
Here is a simple demo, is that a valid sequence diagram?
You can not legally model it this way in UML
17.12.6 DestructionOccurrenceSpecification
...
17.12.6.4 Constraints
no_occurrence_specifications_below
No other OccurrenceSpecifications on a given Lifeline in an InteractionOperand may appear below a DestructionOccurrenceSpecification.
Which basically means that you can have the destruction occur only once. However, you can model the above like this:
Related
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:
UML Specification 2.5.1, section, 17.12.11.5 provides information about contstraints of the Interaction Classifier. The constraint not_contained is explained as the following:
An Interaction instance must not be contained within another Interaction instance.
inv: enclosingInteraction->isEmpty()
Now, when I look at Figure 17.1 which shows the abstract syntax of interactions, I see that the Interaction classifier is a generalization of Fragment classifier. Therefore, an Interaction is a Fragment, but not vice versa.
Additionally, Interaction classifier has the "fragment" association, the "enclosingInteraction" classifier is an association of the Fragment classifier. Then, how can we define the above constraint as a constraint of the Interaction classifier? Interaction classifier should have no attribute "enclosingInteraction".
Is my interpretation of the abstract syntax wrong? In my understanding, above OCL definition would only be applicable to the Fragment classifier, not the Interaction Classifier.
inv: enclosingInteraction->isEmpty()
Referring to the abstract syntax that means when an InteractionFragment is an Interaction then enclosingInteraction is empty (its size is 0).
Without that constraint an Interaction can have an enclosing Interaction and then the following can be false :
An Interaction instance must not be contained within another Interaction instance.
The goal of the relation is to allow an Interaction to know its InteractionFragment, and an InteractionFragment to know its containing Interaction, and thanks to the bidirectional association it is not possible to have :
having no sense but allowed in case of :
A way to not have the necessary constraint is to introduce an additional class :
but this is not the choice made in UML meta model
In fact in all the other cases of specialization of InteractionFragment the enclosingInteraction is not empty (its size is 1) because all of them cannot exist out of an Interaction :
OccurrenceSpecification : from § 17.12.23.5 of formal/2017-12-05
covered : Lifeline [1..1]{redefines InteractionFragment::covered} (opposite A_covered_events::events) References the Lifeline on which the OccurrenceSpecification appears.
StateInvariant : from 17.12.25.4 of formal/2017-12-05
covered : Lifeline [1..1]{redefines InteractionFragment::covered} (opposite
A_covered_stateInvariant::stateInvariant)
References the Lifeline on which the StateInvariant appears.
ExecutionSpecification : from 17.12.8.1 of formal/2017-12-05
An ExecutionSpecification is a specification of the execution of a unit of Behavior or Action within the Lifeline
Interaction classifier should have no attribute "enclosingInteraction"
Note enclosingInteraction is defined on InteractionFragment, Interaction inherits it.
tl;dr
Avoid loops in your behavior description.
Long version
Interaction
An Interaction is a unit of Behavior that focuses on the observable exchange of information between connectable elements.
So that describes a certain piece of your code. An Interaction itself is an InteractionFragment
InteractionFragment is an abstract notion of the most general interaction unit. An InteractionFragment is a piece of an Interaction. Each InteractionFragment is conceptually like an Interaction by itself.
This in turn (being abstract) is concretized by OccurrenceSpecification
An OccurrenceSpecification is the basic semantic unit of Interactions. The sequences of occurrences specified by them are the meanings of Interactions.
ExecutionSpecification (also being abstract)
An ExecutionSpecification is a specification of the execution of a unit of Behavior or Action within the Lifeline. The duration of an ExecutionSpecification is represented by two OccurrenceSpecifications, the start OccurrenceSpecification and the finish OccurrenceSpecification.
or StateInvariant
A StateInvariant is a runtime constraint on the participants of the Interaction. It may be used to specify a variety of different kinds of Constraints, such as values of Attributes or Variables, internal or external States, and so on. A StateInvariant is an InteractionFragment and it is placed on a Lifeline.
Each of them describe behavior from a different aspect.
An Interaction has a +enclodingIteractioninherited from the InteractionFragment which references any Interaction instance.
Now the constraint just says that once you have such an instance it may occur only once and not in some recursive description. So you can split behavior in any tiny pieces but you must not repeat one of them.
Quotations taken from the descriptions in the meta model of UML 2.5.
i've this method findNegozio(insertID) used to find the element with insertID in a Collection.
So, findNegozio(insertID) is an operation that is often referred to in my sequence diagrams so I thought I would illustrate it as a sequence diagram.
The idea is to represent an iteration on a collection and take only the element that matches with the entered ID.
Could this be a good way to represent my idea?
is it useful to represent a frequent step of some sequence diagrams?
EDIT: Maybe with only one step is better OPT instead of ALT.
First three remarks :
For me your code is invalid because a return is missing after the loop => I suppose a variable result is added and initialized to null, set to the found item if exist, and finally used for a final return.
Are you sure findNegocio is not static ?
Why findNegocio is defined on Negocio and not on GestoreNegocio ?
A sequence diagram shows an interaction (partially or not) and focuses on message interchange between lifelines.
From the definition of your operation it is needed to decide whose messages are enough interesting to be shown in your sequence diagram. I don't think the details concerning the list and iterator have to be shown, they are very classical, the goal is not to explain how to work with Java builtin classes.
To break the loop you have the fragment break, so your sequence diagram can be (I added a caller because my tool does not manage lost/found messages) :
But perhaps the main information shown is the use of GestoreNegocio and the loop by itself is not really interesting ?
I have a use case diagram, which has three Actors: User, Librarian and Staff.
The Staff and Librarian actors are specializations of the User actor, and in the Use Case diagram they each have some extended use cases associated only to them.
In the sequence diagram, how do I show that the Librarian actor is a specialization of the User actor?
Can the specialized actors (Librarian and Staff) have their own timelines in the Sequence diagram?
Do I have to show a timeline for the generalized actor, even if it has no extra uses cases or actions over its specializations?
Is it OK to re-arrange the Timelines of a sequence diagram once it has been extracted out into its own diagram, using an Interaction Use box in the main sequence diagram?
In the sequence diagram, how do I show that the Librarian actor is a specialization of the User actor?
There's no way (as far as I know). You can show this relationship in UML Use Case Diagram and even better in UML Class Diagram
Can the specialized actors (Librarian and Staff) have their own timelines in the Sequence diagram?
Yes, assuming they both play a role and interact in the scenario which the Sequence Diagram captures
Do I have to show a timeline for the generalized actor, even if it has no extra uses cases or actions over its specializations?
No, you don't have to show formally correct but otherwise useless artifacts in your diagrams, unless a followup code generation (or MDA) tool forces you to do so
Is it OK to re-arrange the Timelines of a sequence diagram once it has been extracted out into its own diagram, using an Interaction Use box in the main sequence diagram?
I'm not sure, but probably yes, if you keep binding of inputs and outputs and information identifying the lifeline clear and valid. Some articles where the correct answer might be hidden:
Source: uml-diagrams.org: UML Sequence Diagrams → Interaction Use
...One constraint imposed by UML specification that is sometimes difficult to follow is that the interaction use must cover all involved lifelines represented on the enclosing interaction. This means that all those lifelines should be somehow located near each other. If we have another interaction use on the same diagram it could be very tricky to rearrange all involved lifelines as required by UML
Source: www.omg.org/spec/UML/2.5/Beta2
17.7 Interaction Uses → Semantics → Part Decompositions
Decomposition of a lifeline within one Interaction by an Interaction (owned by the type of the Lifeline’s associated ConnectableElement), is interpreted exactly as an InteractionUse. The messages that go into (or go out from) the decomposed lifeline are interpreted as actual gates that are matched by corresponding formal gates on the decomposition.
As the decomposed Lifeline is interpreted as an InteractionUse, the semantics of a PartDecomposition is the semantics of the Interaction referenced by the decomposition where the gates and parameters have been matched...
17.7 Interaction Uses → Notation → PartDecomposition
PartDecomposition is designated by a referencing clause in the head of the Lifeline as can be seen in the notation sub clause 17.3.4 (Lifeline) (see also Figure 17.21).
If the part decomposition is denoted inline under the decomposed lifeline and the decomposition clause is “strict,” this indicates that the constructs on all sub lifelines within the inline decomposition are ordered in strict sequence (see 17.6.4 (Strict interactionOperator)...
Figure 17.21 PartDecomposition - the decomposed part
...
how can i use a variable in sequence diagram.. while sequence diagram show object calling in timelines...
You can use formal/actual parameters on the messages, and action-boxes on a particular lifeline, filled with your own specification language, e.g. Java-style assignments. The example below is for Message Sequence Charts, but works roughly the same for UML sequence diagrams, I just couldn't find a screenshot in a hurry: