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
...
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 have a question about my UML diagram. I have made a system consisting of a "User" parent class and the two child classes inherit from the "User". Now my question is how to show the multiplicity notation between them, just like the multiplicity notation is shown between "Booking" and "client", where more clients can only have one booking each and the notation would be many to one.
The question is:
The user in our system can only be a practitioner or a client, not both at the same time -->, therefore, the notation would be 1 to 1
There are more users and the different users could be either a practitioner or a client --> therefore the notation would be 1..n to 1..n
What is the right way to write it? Is it wrong to write multiplicity notation when a class inherits? Please help I have spend like 2 hours on figuring it out.
You don't. There are no multiplicities on a Generalization in UML.
The fact that your User is either a Cient or Practitioner can be expressed by setting your User abstract. The notation for abstract classes is to set the name in italic. This way you cannot instantiate User instance directly, but you have to use one of the concrete subclasses.
The second phrase doesn't really constrain anything, so you don't have to mention it at all.
Remark: the guillemets « and » are reserved in UML to denote stereotypes and keywords. As it is right now your User class is really an unnamed class with stereotype «User»
hi every body i'm trying to understand UML but there are some questions about it
In UML what is the significance of tagging a class with the stereotype <<abstract>>?
and how to express this constraint as an invariant,
A stereotype "abstract" does not exist - an abstract class should be depicted using italic font. Abstract means that a class cannot be instantiated. It needs a subclass to do so. So as a pseudo-code constraint this would mean
for all instances i of MyAbstractClass holds: i.actualClass != MyAbstractClass
or in ocl for MyAbstractClass holds
self.allInstances()->forAll(i: MyAbstractClass | i.classifier <> self)
As the word 'abstract' was not displayed in your first question version, I expanded on stereotypes in general:
First of all: When learning UML, stereotypes should not be the first things you look into. They are rather complex.
Stereotypes or keywords (both denoted with <<MyStereotype>>) do not have a general meaning. It is defined by the specific stereotype. Commonly you cannot express a stereotype as an invariant instead.
But some other aspects of UML can be shown the same way: A class from the UML Metalevel is marked with <<metaclass>> even though it does not have a stereotype or even is of different actual type. The Stereotypes themselves are shown with a <<stereotype>> marker (even if they are instances of a special class).
An example for a custom stereotype could be "Service". You could mark classes with it which represent a Service. There could be a constraint which tells you that a "Service" must implement a special Interface. In this case you could express this constraint as a (boring) invariant. But probably it is even just a marker. In the latter case you can use a keyword as replacement.
I realize this thread is a couple of years old, but I came to it when it was referenced by someone else, as supporting the assertion that the «abstract» stereotype isn't supported by the UML spec. That assertion isn't quite accurate, and I'd like to explain why. I'll start by clarifying what abstract classes are.
Abstract classes are definitions of classes that don't include complete implementation. Therefore, abstract classes can't be directly instantiated; they have to be specialized (inherited). Abstract classes are notated by italicizing the class name and the methods that are abstract, and additionally by optionally adding an {abstract} property to the class name and/or to the operations (methods, we usually say, but methods are actually the "method" by which the operation is implemented) that are abstract.
Interfaces are actually a specific type of abstract class: a class with zero implementation. Their notation is different from other types of abstract classes (don't italicize, use the «interface» keyword, and notate all the specialization arrows with dotted lines). So, as Christian says here, there is standard notation for abstract classes--at least, there is in class diagrams.
Now, while it is true, as Christian also says, that the «abstract» stereotype doesn't exist, it is also true that you can create it if you want to, and that doing so is supported by the UML spec. It's unlikely that you'll have a reason to (at least in class diagrams), but you still can.
A stereotype is an "extensibility mechanism" for UML (there are three: stereotypes, tagged values, and constraints). It allows you to more specifically define some sort of element. Stereotypes are applied to classes (metaclasses actually, metaclasses are classes whose instances are also classes). A number of stereotypes are pre-defined "Standard Stereotypes" (in UML 1.4 they were called "Standard Elements"). Examples of these are «metaclass» (again, a class whose instances are also classes) and «file» (a physical file in the context of the system developed).
Stereotypes are a type of keyword. The spec (Superstructure 2.0, Annex B, p. 663) has this to say about keywords:
UML keywords are reserved words that are an integral part of the UML
notation and normally appear as text annotations attached to a UML
graphic element or as part of a text line in a UML diagram. These
words...cannot be used to name user-defined model elements where such naming would result in ambiguous interpretation of
the model. For example, the keyword “trace” is a system-defined
stereotype of Abstraction (see Annex C, “Standard Stereotypes”) and,
therefore, cannot be used to define any user-defined stereotype.
In UML, keywords are used for four different purposes:
To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form...
To distinguish a particular kind of relationship between UML concepts (meta-association) from other relationships sharing the same general graphical form...
To specify the value of some modifier attached to a UML concept (meta-attribute value)...
To indicate a Standard Stereotype (see Annex C, “Standard Stereotypes”)...
Keywords are always enclosed in guillemets («keyword»), which serve as visual cues to more readily distinguish when a keyword is being used...In addition to identifying keywords, guillemets are also used to distinguish the usage of stereotypes defined in user profiles. This means that:
Not all words appearing between guillemets are necessarily keywords (i.e., reserved words), and
words appearing in guillemets do not necessarily represent stereotypes.
In other words, you can create any stereotype that you want, so long as it isn't a keyword. Since "abstract" is not a keyword, it follows that you can create an «abstract» stereotype.
In order to do so, however, you would have to go to some trouble, more trouble in UML 2.0 and above than in UML 1.4. UML 1.4 simply stated that a stereotype was an extension mechanism for the UML spec. One could simply define the stereotype, apply it to whichever part of the UML metamodel one wanted, and document the change. UML 2.0 wanted to formalize the relationship of a stereotype to a UML metaclass (any item on a UML diagram is a metaclass, and part of the UML metamodel). So, they came up with Profiles. This sample diagram shows how profiles work:
Now, that black arrow may look a bit strange, since you don't see it in any context but this one. UML 2.0 introduced the concept of an Extension, which it defines as "used to indicate that the properties of a metaclass are extended through a stereotype." This black arrow indicates an extension.
I'll quote Tom Pender (The UML Bible, Wiley Publishing, 2004) for an explanation of this diagram, since he does a better job than the spec (and I certainly can't improve on it):
It shows that a Component is extended by a Bean stereotype, which is required. The Bean stereotype is an abstract type, with two subtypes - Entity and Session. Each instance of Component, therefore, must be extended by an instance of either the Entity stereotype or the Session stereotype. Remember that a stereotype is a kind of class that can have properties - in this case, a Session stereotype has an attribute named state. This corresponds to a tagged definition whose value specifies the state of the Session. The tagged value is an enumeration, StateKind, which has either a stateless or stateful value.
The Component has a constraint on it, displayed in the note attached to the Component symbol, which states that a Component cannot be generalized or
specialized.
The diagram also shows that an Interface metaclass is extended by the Remote and Home stereotypes. The EJB package has a constraint, displayed in the note that sits in the package, that states a Bean must realize exactly one Home interface.
So, you can indeed use an «abstract» stereotype if you have reason to go to the trouble of creating it. The main reason that anyone might want to is to represent an abstract class in some place other than a class diagram.
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: