Apostila UML 2.0 Versao 3.2
-
Upload
francisco-oliveira -
Category
Documents
-
view
1.228 -
download
2
Transcript of Apostila UML 2.0 Versao 3.2
Versão 3.2
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255
Lucélia Viera Mota
version 3.0
Study Guide OCUP FUNDAMENTAL Certification Guide UML 2.0
Esse documento foi criado a partir do UML 2 Certification Guide: Fundamental & Intermediate Exams by Tim Weilkiens and Bernd Oestereich, e não tem o objetivo de substituí-lo em parte ou em sua totalidade, sendo portanto, apenas um guia de referência rápida.
Versão 3.2
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255
Lucélia Viera Mota
Sumário
1 Introduction ............................................................................................ 5
1.1 O que é UML? .................................................................................................. 5
1.2 The three Amigos ............................................................................................. 5
1.3 The History of UML ........................................................................................... 6
1.4 UML subspecifications ....................................................................................... 7
1.5 The metamodel of UML 2.0 ................................................................................ 7
1.6 The Object Management Group .......................................................................... 8
1.7 The UML Certification Program ........................................................................... 8 1.7.1 The Exams Level ....................................................................................... 9 1.7.2 Examination Procedure ............................................................................... 9 1.7.3 Roteiro para a prova OCUP Fundamental .................................................... 10
2 Miscellaneous basic notions ................................................................... 12
2.1 Tópicos do Exame .......................................................................................... 12
2.2 Basic UML modeling ........................................................................................ 12 2.2.1 Diagrams ............................................................................................... 12 2.2.2 Standard Stereotypes (Basic) .................................................................... 15 2.2.3 Glossary ................................................................................................. 17
2.3 DataTypes ..................................................................................................... 18 2.3.1 PrimitiveDataTypes .................................................................................. 19 2.3.2 EnumerationTypes ................................................................................... 20
3 Class Diagrams (Basic) .......................................................................... 21
3.1 Classes Overview ........................................................................................... 21
3.2 Kernel Package .............................................................................................. 21 3.2.1 Root Diagram .......................................................................................... 21 3.2.2 Namespaces Diagram .............................................................................. 24 3.2.3 Classifiers Diagram .................................................................................. 25 3.2.4 Features Diagram .................................................................................... 28 3.2.5 Expressions Diagram ............................................................................... 29 3.2.6 Constraints Diagram ................................................................................ 30 3.2.7 Class Diagram ......................................................................................... 31 3.2.8 Operations Diagram ................................................................................. 40 3.2.9 Multiplicities Diagram ............................................................................... 42 3.2.10 Instances Diagram................................................................................... 45 3.2.11 Package Diagram .................................................................................... 48
3.3 Dependency Package ...................................................................................... 54 3.3.1 Dependency ............................................................................................ 54 3.3.2 Abstraction ............................................................................................. 56 3.3.3 Usage .................................................................................................... 57 3.3.4 Permission .............................................................................................. 58 3.3.5 Realization .............................................................................................. 59 3.3.6 Substitution ............................................................................................ 60
3.4 Interface Package .......................................................................................... 61 3.4.1 InterfaceRealization ................................................................................. 63
Versão 3.2
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255
Lucélia Viera Mota
3.5 Diagrams ...................................................................................................... 64
4 Behavior Diagrams (Basic) .................................................................... 66
4.1 Common Behaviors ........................................................................................ 66 4.1.1 Overview ................................................................................................ 66 4.1.2 Class Descriptions ................................................................................... 68
4.2 Activities Diagram .......................................................................................... 74 4.2.1 Overview ................................................................................................ 74 4.2.2 Abstract Syntax ....................................................................................... 74 4.2.3 Class Diagrams (BasicActivities) ................................................................ 75 4.2.4 Activity .................................................................................................. 77 4.2.5 ActivityNode ........................................................................................... 79 4.2.6 ActivityEdge ............................................................................................ 87 4.2.7 Diagrams ............................................................................................... 89
4.3 Interactions Diagrams .................................................................................... 91 4.3.1 Overview ................................................................................................ 91 4.3.2 Abstract syntax ....................................................................................... 91 4.3.3 Interaction.............................................................................................. 92 4.3.4 InteractionOccurrence .............................................................................. 93 4.3.5 EventOccurrence ..................................................................................... 94 4.3.6 ExecutionOccurrence ............................................................................... 94 4.3.7 Gate ...................................................................................................... 95 4.3.8 GeneralOrdering ...................................................................................... 95 4.3.9 Lifeline ................................................................................................... 96 4.3.10 Message ................................................................................................. 97 4.3.11 Stop ...................................................................................................... 98 4.3.12 Diagrams ............................................................................................... 99
4.4 Use Cases .................................................................................................... 102 4.4.1 Overview ............................................................................................... 102 4.4.2 Abstract syntax ...................................................................................... 102 4.4.3 Actor (from UseCases) ............................................................................ 103 4.4.4 UseCase ................................................................................................ 104 4.4.5 Extend .................................................................................................. 107 4.4.6 ExtensionPoint ....................................................................................... 108 4.4.7 Include.................................................................................................. 108 4.4.8 Diagrams .............................................................................................. 109
5.1 SIMULADOS ................................................................................................. 116
5.2 Exercícios Aula 2 – Class Diagrams .................................................................. 116
5.3 Gabarito Aula 2 – Class Diagrams ................................................................... 119
5.4 Exercícios Aula 3 - Class Diagrams .................................................................. 120
5.5 Gabarito Aula 3 – Class Diagrams ................................................................... 121
5.6 Exercícios Aula 4 – Class Diagrams .................................................................. 122
5.7 Gabarito Aula 4 – Class Diagrams ................................................................... 125
5.9 Exercícios Aula 5 – Class Diagrams .................................................................. 126
5.10 Gabarito Aula 5 – Class Diagrams ................................................................... 128
5.11 Exercícios Aula 6 – Class Diagrams .................................................................. 129
5.12 Gabarito Aula 6 – Class Diagrams ................................................................... 133
5.13 Exercícios Aula 7 – Activity Diagrams .............................................................. 134
5.14 Gabarito Aula 7 – Activity Diagrams ................................................................ 142
Versão 3.2
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255
Lucélia Viera Mota
5.15 Exercícios Aula 8 - Sequence Diagrams ............................................................ 143
5.16 Gabarito Aula 8 - Sequence Diagrams .............................................................. 153
5.17 Exercícios Aula 9 – Use Case Diagrams ............................................................ 154
5.18 Gabarito Aula 9 – Use Case Diagrams .............................................................. 162
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
5
1 Introduction
1.1 O que é UML?
A Unified Modeling Language (UML) é uma linguagem e uma notação de sistema usada para
especificar, construir, visualizar e documentar modelos de sistemas de software.
A UML é apenas uma linguagem e, portanto, é somente uma parte de um método para
desenvolvimento de software.
A UML é considerada uma linguagem por que fornece um vocabulário e as regras para a
combinação desse vocabulário, com finalidade de comunicar algo. Uma linguagem de
modelagem, pois usa o vocabulário e as regras para realizar representação conceitual e física de
um sistema. Uma linguagem de modelagem unificada por padronizar a elaboração dessa
representação.
A UML é independente do processo, apesar se ser perfeitamente utilizada em processos
orientados a caso de usos, centrado na arquitetura, iterativo e incremental.
Também não pode ser considerada uma metodologia por indicar apenas como criar e ler os
modelos, mas não indica quais devem ser criados, quando criá-los nem por quem devem ser
criados.
Dizemos que é uma linguagem para visualizar, pois modelos explícitos facilitam a
comunicação. A UML é mais que um mero conjunto de símbolos gráficos. Por trás de cada
símbolo empregado na notação da UML existe uma semântica bem definida. Dessa forma,
qualquer pessoa ou ferramenta que usar a UML será capaz de interpretá-la sem ambigüidades.
É uma linguagem para especificação, pois permite construir modelos precisos, sem
ambigüidades e completos.
É uma linguagem visual de programação que permite construir, ou seja, através dos modelos
é possível gerar códigos para linguagem ou vice-versa.
É uma linguagem para documentação, pois auxilia os processos de desenvolvimento de
software a produzir artefatos além do próprio código executável.
1.2 The three Amigos
By the beginning, a large number of books on object-oriented (OO) software modeling had
been published, and a large number of graphical notations had been introduced.
The decisive progress came about in 1995 when Grady Booch and Jim Rumbaugh
announced the combining of their concepts into a Unified Method.
Soon the Unified Method became the Unified Modeling Language, a term that clearly
indicates a language that comprises semantics and a uniform notation rather than a
methodology.
Booch and Rumbaugh were soon joined by Ivar Jacobson, and the three have henceforth
been called the ―Three Amigos‖ in 1996.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
6
Their books were very popular an enjoyed a large market share, by the time the UML was
born.
1.3 The History of UML
In 1997, UML 1.1 was submitted to the OMG. Since then, the UML has been further
developed by the OMG.
Later, the ISO (International Organization for Standardization) also accepted UML as a
standard.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
7
1.4 UML subspecifications
UML v. 2.0 has been formally divided into the following subspecifications:
Infrastructure: Core of the architecture, profiles and stereotypes.
Superstructure: Static and dynamic model elements.
Object Constraint Language (OCL): A formal language used to describe expressions on
UML models.
Diagrama Interchange: the UML interchange format for diagrams.
1.5 The metamodel of UML 2.0
The UML 2.0 language is largely defined in a so-called metamodel. The reason for the prefix
meta is that the language resides one abstraction level above the model that a UML user models.
Now, the metamodel might seem confusing and illogical at first because the metamodel is a UML
class model that describes UML.
In other words: UML is defined in UML.
You can find each word of UML as a class in the metamodel.
You can see three elements (Class, property, operation) – and that a class can have an
arbitrary number of properties (attributes) and an arbitrary number of operations.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
8
Note that not all model elements of UML are contained in the UML metamodel; in fact, only a
minimum subset (of the class modeling) is required. In turn, this set is described in its own
model, the meta-metamodel.
This means tha we have a metamodel and a meta-metamodel – The Metamodel. Of course,
we also have the models of UML users – your models – which include yet another model, the
model of objects based on your model. You can easily imagine the metamodel of UML is very
large. For structuring purposes, it is therefore divided into many packages.
Each of these packages comes up in this course over and over again because all of them
represent the granularity of the exam topics
The UML certification exam is a pure language test, which means that knowledge of the
metamodel of UML is tested. In addition to elements such as Class, which UML users are familiar
with, the metamodel also includes many abstract concepts (Abstract Class) that are not used on
the user´s modeling level. The abstract concept are also an integral part of the UML certification.
Don´t worry, Abstract Class are normally simple.
1.6 The Object Management Group
The Object Management Group (OMG) is an international organization of which all important
IT companies are members.
OMG‘s members companies cooperate in maintaining and implementing the UML standard.
The group‘s members include large international corporations such as IBM, Hewlett-Packard,
Sun Microsystems, Telelogic, Boeing, Adobe, etc.
O endereço eletrônico do site é : http://www.omg.org
1.7 The UML Certification Program
In 2004, OMG introduced qualification standards for individuals in the form or three-level
certification program based on UML 2.0 called OMG Certified UML Professional (OCUP)
certification program. This certification program ensures that UML users, trainers, consultants, tool developers, and
other interested parties can acquire a uniform UML understanding and a minimum qualification.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
9
1.7.1 The Exams Level
There are three OCUP Exams:
FUNDAMENTAL: Qualified to be a member of a UML Development Team.
INTERMEDIATE: Qualified to be a senior member of a UML Development Team.
ADVANCED: Qualified to manage a UML Development Team.
Nível Fundamental
Examines fundamental UML knowledge, including basic notions on class diagrams,
activity diagrams, interaction diagrams and use case diagrams as well as standard
stereotypes and primitive types.
This is for regular UML users.
Nível Intermediário
The second level emphasizes a deeper knowledge of activity diagrams and
interaction diagrams. More over, it adds composition structure diagrams, basic
notions on component and deployment diagrams, state diagrams, the action
model, and the profile extension mechanism.
This is for extensive UML users.
Nível Avançado
The third and highest level of test deals with advanced knowledge of class
diagrams, such as association classes and metatypes, composition structure
diagrams, component diagrams, activity diagrams, action modeling, deployment
diagrams, and protocol automatons. In addition, this level covers the topics: OCL,
UML 2.0 Architecture, information flow modeling, models, and templates.
This is for advanced UML users, e.g., designers, architects, UML tool developers.
1.7.2 Examination Procedure
Multiple-choice test
Pearson Vue testing center to register
Content of test
Each test is unique;
The test language is English.
Test result
In the end of the test with the successful or not;
Percent Resume of the coverage map.
Each certification level builds on the preceding one.
The certification question asked in the tests are based on the adopted UML Version
2.0 as well as a successor, UML 2.1.
The three certification exams are structured and organized in the same way, but
the topics are different, and the questions increase in difficulty from one level to
the next.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
10
1.7.3 Roteiro para a prova OCUP Fundamental
Antes de começar a estudar é importante entender como funciona a prova. Ela não é muito
diferente de outras certificações podendo ser marcada pelos centros PearsonVue e custando U$
210,00. É composta de 82 questões e pode ser feita em até 90min sendo a nota mínima para
aprovação de 57%, ou seja, erre no máximo 46 questões para ser aprovado.
Outro ponto importante sobre a prova é entender o foco da mesma. Como pode ser visto no
site oficial da Certificação o foco é distribuído conforme abaixo:
Class Diagrams (Basic) ....................30%
Activity diagrams (Basic) .................20%
Interaction Diagrams (Basic) ............20%
Use Case Diagrams (Basic) ...............20%
Miscellaneous basic notions ..............10%
Total 100%
Passo 01: O caminho das pedras:
Somente ter bons conhecimentos da UML não é suficiente para passar, é necessário
entender como os elementos da UML estão estruturados e como são cobrados no teste.
A leitura da especificação oficial da UML é obrigatória.
O Livro UML 2 Certification Guide: Fundamental & Intermediate Exams by Tim Weilkiens
and Bernd Oestereich foi o primeiro a ser lançado sobre UML Certication. Recomendo
fortemente a leitura, pois nele fica claro o foco da prova bem como o direcionamento
necessário para a aprovação na certificação. A cada capítulo os autores apresentam o
conteúdo da UML atrelado a um simulado para ajudar a fixar o assunto.
Depois de finalizada a leitura do livro explore o site da OMG. Alguns conteúdos sugeridos
são realmente fundamentais e de leitura obrigatória.
Passo 02: Não entre na sala de exames sem ter “decorado”:
A organização da parte estrutural;
Os elementos do capítulo Activity Diagrams;
Os relacionamentos disponíveis no Caso de Uso;
Os elementos do Interactions Diagrams;
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
11
Passo 03: Os simulados:
Infelizmente, como a certificação OCUP 100 é recente você não encontrará muitos
simulados facilmente;
No final deste material eu colhi e coloquei para vocês os simulados que consegui, é
necessário que TODOS sejam feitos e refeitos até que a semântica de cada questão
esteja gravada na sua mente.
Passo 04: O grande dia:
Não agende a prova para dias no meio da semana, pode ocorrer situações que exijam de
você mais dedicação e isso provocará uma certa insegurança sobre se conseguirá o
sucesso na prova.
Evite agendar em datas que antecem os feriados pois algumas escola trabalham em
regime especial e pode ocorrer de não ter a pessoa certa para te auxiliar na realização da
prova.
Escolha uma escola em que o ambiente seja agradável e tranqüilo, e que as atendentes
sejam tranquilas para não deixar você mais ansioso do que está.
Se você fez tudo como sugerido somando uma grande vontade de não perder U$ 210,00
você terá grandes chances de atingir os 57% da prova e se tornar um OCUP
FUNDAMENTAL.
Boa Sorte!!
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
12
2 Miscellaneous basic notions
Esta seção descreve os tópicos gerais que são exigidos de forma superficial na certificação de
nível fundamental da UML.
2.1 Tópicos do Exame
Miscellaneous basic notions:
Confirm knowledge of the basic UML modeling concepts
Diagrams
Stereotypes
Glossary
Recognize and understand UML primitive types
Confirm the basic knowledge of common behavior concepts (este conceito será tratado na seção
Behavior)
Este tópico representa 10% do teste.
2.2 Basic UML modeling
2.2.1 Diagrams
A UML model consists of elements such as packages, classes, and associations. The
corresponding UML diagrams are graphical representations of parts of the UML model. UML
diagrams contain graphical elements (nodes connected by paths) that represent elements in the
UML model. As an example, two associated classes defined in a package will, in a diagram for the
package, be represented by two class symbols and an association path connecting these two
class symbols. Each diagram has a contents area. As an option, it may have a frame and a
heading as shown in Figure Figure 1 - Contents area.
Figure 1 - Contents area
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
13
The frame is a rectangle. The frame is primarily used in cases where the diagrammed element
has graphical border elements, like ports for classes and components (in connection with
composite structures), and entry/exit points on statemachines. In cases where not needed, the
frame may be omitted and implied by the border of the diagram area provided by a tool. In case
the frame is omitted, the heading is also omitted. The diagram contents area contains the
graphical symbols; the primary graphical symbols define the type of the diagram (e.g., a class
diagram is a diagram where the primary symbols in the contents area are class symbols).
The heading is a string contained in a name tag (rectangle with cutoff corner) in the upper
leftmost corner of the rectangle, with the following syntax:
[<kind>]<name>[<parameters>]
As an example, Figure Figure 2 is a class diagram of a package P: classes C1 and C2 are defined
in the namespace of the package P.
Figure 2 - Class diagram of package P
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
14
UML diagrams may have the following kinds of frame names as part of the heading:
activity
class
component
deployment
interaction
package
state machine
use case
In addition to the long form names for diagram heading types, the following abbreviated forms
can also be used:
act (for activity frames)
cmp (for component frames)
dep (for deployment frames)
sd (for interaction frames)
pkg (for package frames)
stm (for state machine frames)
uc (for use case frames)
As is shown in Figure 3, there are two major kinds of diagram types: structure diagrams and
behavior diagrams.
Figure 3 - The taxonomy of structure and behavior diagrams
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
15
Structure diagrams show the static structure of the objects in a system. That is, they depict
those elements in a specification that are irrespective of time. The elements in a structure
diagram represent the meaningful concepts of an application, and may include abstract, real-
world and implementation concepts. For example, a structure diagram for an airline reservation
system might include classifiers that represent seat assignment algorithms, tickets, and a credit
authorization service. Structure diagrams do not show the details of dynamic behavior, which are
illustrated by behavioral diagrams. However, they may show relationships to the behaviors of the
classifiers exhibited in the structure diagrams.
Behavior diagrams show the dynamic behavior of the objects in a system, including their
methods, collaborations, activities and state histories. The dynamic behavior of a system can be
described as a series of changes to the system over time. Behavior diagrams can be further
classified into several other kinds.
Please note that this taxonomy provides a logical organization for the various major kinds of
diagrams. However, it does not preclude the mixing different kinds of diagram types, as one
might do when one combines structural and behavioral elements (e.g., showing a state machine
nested inside an internal structure).
Consequently, the boundaries between the various kinds of diagram types are not strictly
enforced. The constructs contained in each of the thirteen UML diagrams is described in the
Superstructure chapters as indicated below.
Activity Diagram - ―Activities‖
Class Diagram - ―Classes‖
Communication Diagram - ―Interactions‖
Component Diagram - ―Components‖
Composite Structure Diagram - ―Composite Structures‖
Deployment diagram - ―Deployments‖
Interaction Overview Diagram - ―Interactions‖
Object Diagram - ―Classes‖
Package Diagram - ―Classes‖
State Machine Diagram - ―State Machines‖
Sequence Diagram - ―Interactions‖
Timing Diagram - ―Interactions‖
Use Case Diagram - ―Use Cases‖
2.2.2 Standard Stereotypes (Basic)
This appendix describes the predefined standard stereotypes for UML. The standard stereotypes
are specified in three separate system-defined profiles.
Mas somente o Basic é cobrado na prova de nível fundamental.
Um estereótipo é um mecanismo de extensibilidade da UML que representa uma subclasse de um
elemento já existente com o mesmo formato, porém com objetivos diferentes e bem definidos.
Geralmente, quando é necessário distinguir o uso específico de um elemento, utiliza-se
estereótipos.
O estereótipo possui a mesma representação gráfica do elemento, sendo colocado seu nome
entre aspas francesas («») acima ou em frente do nome do elemento que está sendo descrito
pelo estereótipo.
The stereotypes belonging to the profile are described using a compact tabular form rather than
graphically. The first column gives the name of the stereotype label corresponding to the
stereotype. The actual name of the stereotype is the same as the stereotype label except that the
first letter of each is capitalized. The second column identifies the language unit of the
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
16
stereotype. The third column identifies the metaclass to which the stereotype applies and the last
column provides a description of the meaning of the stereotype.
Name Subpackage Applies to Description
«create» Dependencies Usage A usage dependency denoting that the
client classifier creates instances of the
supplier classifier.
«create»
Kernel BehavioralFeature
Specifies that the designated feature
creates an instance of
the classifier to which the feature is
attached. May be promoted to the
Classifier containing the feature.
«derive»
Dependencies Abstraction Specifies a derivation relationship
among model elements that are
usually, but not necessarily, of the
same type. A derived dependency
specifies that the client may be
computed from the supplier. The
mapping specifies the computation.
The client may be implemented for
design reasons, such as efficiency,
even though it is logically redundant.
«implement»
Components Component A component definition that is not
intended to have a specification itself.
Rather, it is an implementation for a
separate «specification» to which it has
a Dependency.
«implementation Class»
Classes Class Implementation Class:is a class that
may have attributes, associations, and
operations, and methods. Defines the
physical implementation of objects of a
class. For example, if you were to
implemented as an employee table, the
workproduct class might be
implemented as an artifact table, and
the UnitOfWork class might be
implemented as work order table.
Used during the later part of design
and during implementation activities
within a development process to
identify how objects are implemented
for a system. You can think about
implementation class as physical
―code‖ classes because, they are
physical implementations of classes.
The implementation of a class in some
programming language (e.g., C++,
Smalltalk, Java) in which an instance
may not have more than one class.
This is in contrast to
Class, for which an instance may have
multiple classes at one time and may
gain or lose classes over time, and an
object (a child of instance) may
dynamically have multiple classes.
An Implementation class is said to
realize a Classifier if it provides all of
the operations defined for the Classifier
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
17
with the same behavior as specified for
the Classifier's operations.
An Implementation Class may realize
a number of different Types. Note that
the physical attributes and
associations of the Implementation
class do not have to be the same as
those of any Classifier it realizes and
that the Implementation Class may
provide methods for its operations in
terms of its physical attributes and
associations.
«metaclass» Kernel Class A class whose instances are also
classes.
«type» Kernel Class Type: A type is a class that may have
attributes, associations, and
operations, but does not have any
methods. A type defines a role an
object may play relative to other
objects. For example, a worker object
may play the role of project manager,
resource manager, human resource, or
system administrator.
Types are commonly used during
analysis activities within a development
process to identify the kinds of objects
a system may require. You ca think of
types as conceptual classes, because
they are ideas for possible class. Also,
because types do not have methods
and represent roles only, they do not
have instances.
Types may be used with link ends. One
or more type names may be placed a
role name to indicate the roles a class
or object plays in the relationship.
Table 1 - Basic Standard Sterotypes
2.2.3 Glossary
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
18
There are no formal definitions in this specification that are taken from other documents.
Versão que pode ser baixada glossary_1.6 no site da OMG.
2.3 DataTypes
O tópico ―Miscellaneous basic notions‖ cobra apenas os data types primitivos predefinidos na
UML. Os conceitos gerais e as variações sobre o conjunto data types, estão descritos na seção
3.2.9.2 que pertence ao tópico ―class diagrams‖. As variações dos datatypes foram adicionadas
neste tópico por manterem um vínculo semântico.
A data type is a type whose values have no identity (i.e., they are pure values). Data types
include primitive built-in types (such as integer and string) as well as enumeration types.
Description
DataType defines a kind of classifier in which operations are all pure functions (i.e., they can
return data values but they cannot change data values, because they have no identity). For
example, an ―add‖ operation on a number with another number as an argument yields a third
number as a result; the target and argument are unchanged. Semantics
It´s instances are data values (e.g. Simple, primitive, enumeration etc...). An instance of a
datatype has no identity.
Notation
A data type is denotated using the rectangle symbol with keyword «dataType» or, when it is
referenced by e.g. an attribute, denoted by a string containing the name of the data type.
Examples
Figure 4 - Notation of data type: to the left is an icon denoting a data type and to the right is a reference to a data type which is used in an attribute.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
19
2.3.1 PrimitiveDataTypes
A Primitive defines a predefined DataType, without any relevant UML substructure (i.e., it has
no UML parts – Are not decomposable). A primitive datatype may have a logical algebra of
operations and constraints defined outside of UML.
These include primitive types such as Integer, Boolean, UnlimitedNatural, and String.
Figure 5 - The contents of the PrimitiveTypes package
Integer
An instance of Integer is an element in the (infinite) set of integers (…-2, -1, 0, 1, 2…). It is used
for integer attributes and integer expressions in the metamodel.
Boolean
Boolean is an instance of PrimitiveType. In the metamodel, Boolean defines an enumeration that
denotes a logical condition. Its enumeration literals are:
• true The Boolean condition is satisfied.
• false The Boolean condition is not satisfied.
String
An instance of String defines a piece of text. The semantics of the string itself depends on its
purpose, it can be a comment, computational language expression, OCL expression, etc. It is
used for String attributes and String expressions in the metamodel.
UnlimetedNatural
An instance of UnlimitedNatural is an element in the (infinite) set of naturals (0, 1, 2…). The
value of infinity is shown using an asterisk (‗*‘).
Semantics
The run-time instances of a primitive type are data values. The values are in many-to-one
correspondence to mathematical elements defined outside of UML (for example, the various
integers). Instances of primitive types do not have identity. If two instances have the same
representation, then they are indistinguishable.
Notation
A primitive type has the keyword «primitive» above or before the name of the primitive type.
Figure 6 - Example of primitive
Integer
<<primitive>>
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
20
2.3.2 EnumerationTypes
A enumeração é um recurso muito usado nas linguagens de programação e também usada como
um tipo de dado nos diagramas de classes, podendo ser modelada separadamente como uma
classe estereotipada como <<enumeration>>. O domínio correspondente a um conjunto de
literais fica listado no compartimento do meio.
An enumeration is a data type whose values are enumerated in the model as enumeration
literals.
An enumeration literal is a user-defined data value for an enumeration.
Description
Enumeration is a kind of data type, whose instances may be any of a number of user-defined
enumeration literals. It is possible to extend the set of applicable enumeration literals in other
packages or profiles.
Semantics
The run-time instances of an Enumeration are data values. Each such value corresponds to
exactly one EnumerationLiteral.
Whose values are possible listed in the botton compartment.
Notation
An enumeration may be shown using the classifier notation (a rectangle) with the keyword
«enumeration». The name of the enumeration is placed in the upper compartment.
A compartment listing the attributes for the enumeration is placed below the name compartment.
A compartment listing the operations for the enumeration is placed below the attribute
compartment. A list of enumeration literals may be placed, one to a line, in the bottom
compartment.
The attributes and operations compartments may be suppressed, and typically are suppressed if
they would be empty.
An EnumerationLiteral is typically shown as a name, one to a line, in the compartment of the
enumeration notation.
Examples
Figure 7 - Example of an enumeration
Imaginemos uma classe Pedido que contenha um atributo statusPedido o qual é definido da
seguinte forma: statusPedido = SituacaoPedido, poderia ser representado usando o domínio de
literais criado.
Pedido.statusPedito = pendente
Visibility Kind
Private
Public
Package
<<Enumeration>>
Address
Mr.
Mrs.
<<Enumeration>>
class Enumeration
«enumeration»
SituacaoPedido
«enum»
processandoPagamento
separandoMercadorias
empacotando
cancelado
pendente
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
21
3 Class Diagrams (Basic)
3.1 Classes Overview
The Classes package contains subpackages that deal with the basic modeling concepts of UML,
and in particular classes and their relationships.
Package Structure
The Figure 8 describes the dependencies (i.e., package merges) between the subpackages of the
package Classes.
Figure 8 - The subpackages of the Classes package and their dependencies
3.2 Kernel Package
3.2.1 Root Diagram
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
22
Figure 9 - The Root Diagram of the Kernel Package
3.2.1.1 Relationship
Relationship is an abstract concept that specifies some kind of relationship between elements.
Relationship is used to interconnect elements in another words is an element that specifies a
connection between elements. A relationship references one or more related elements.
3.2.1.2 Directed Relationship
A directed relationship represents a relationship between a collection of source model elements
and a collection of target model elements. Description
A directed relationship references one or more source elements and one or more target elements.
Notation
There is no general notation for a DirectedRelationship. The specific subclasses of
DirectedRelationship will define their own notation. In most cases the notation is a variation on a
line drawn from the source(s) to the target(s).
3.2.1.3 Comment
Comments and notes are terms often used synonymously.
A comment is a textual annotation that can be attached to a set of elements.
A comment can be annotated to any UML model element. (e.g. class, operation, comment,
association)
Figure 10 – The Comment Diagram of the Kernel package
Semantics
A Comment adds no semantics to the annotated elements, but may represent information useful
to the reader of the model.
Notation
A Comment is shown as a rectangle with the upper right corner bent (this is also known as a
―note symbol‖). The rectangle contains the body of the Comment.
A separate dashed line shows the connection to each annotated element.
Presentation Options
The dashed line connecting the note to the annotated element(s) may be suppressed if it is clear
from the context, or not important in this diagram.
Example:
Figure 11 - Comment notation
3.2.1.4 Element
An element is a constituent of a model. As such, it has the capability of owning other elements. Description
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
23
Element is an abstract metaclass with no superclass.
It is used as the common superclass for all metaclasses in the infrastructure library.
Semantics
Subclasses of Element provide semantics appropriate to the concept they represent.
Notation
There is no general notation for an Element. The specific subclasses of Element define their own
notation.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
24
3.2.2 Namespaces Diagram
3.2.2.1 NamedElement
A named element is an element in a model that may have a name.
The named element has a name and a visibility (public, private, protected or package)
The default rule is that two elements are distinguishable if they have unrelated types, or related
types but different names. This rule may be overridden for particular cases, such as operations
which are distinguished by their signature.
Description
The name is used for identification of the named element within the namespace in which it is
defined.
A named element also has a qualified name that allows it to be unambiguously identified within a
hierarchy of nested namespaces.
3.2.2.2 Namespace
A namespace is an element in a model that contains a set of named elements that can be
identified by name.
Named elements may appear within a namespace according to rules that specify how one named
element is distinguishable from another. Description
A namespace has the ability to import either individial members or all members of a package,
thereby making it possible to refer to those named elements without qualification in the
importing namespace. In the case of conflicts, it is necessary to use qualified names or aliases to
disambiguate the referenced elements.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
25
3.2.3 Classifiers Diagram
Figure 12 - The Classifiers diagram of the Kernel package
3.2.3.1 Classifier
A classifier is a classification of instances — it describes a set of instances that have features in
common.
A classifier is a classification of instances according to their features. Description
A classifier is a namespace whose members can include features.
A classifier is a type and can own generalizations, thereby making it possible to define
generalization relationships to other classifiers. In another word, Classifier can be part of a
generalization hierarchy.
A classifier is a redefinable element, meaning that it is possible to redefine nested classifiers.
Semantic
A classifier is a namespace whose members can include features.
Concrete classifier in the UML metamodel include, for example, class, component and use case.
Notation
The default notation for a classifier is a solid-outline rectangle containing the classifier‘s name,
and optionally with compartments separated by horizontal lines containing features or other
members of the classifier. The specific type of classifier can be shown in above the name.
Some specializations of Classifier have their own distinct notations.
The name of an abstract Classifier is shown in italics and an abstract Classifier can be shown
using the keyword {abstract} after or below the name of the Classifier.
Figure 13 - Abstract Classifier
Style Guidelines
GeomFigure
{abstract}
RetangleCircle
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
26
Attribute names typically begin with a lowercase letter. Multiword names are often formed by
concatenating the words and using lowercase for all letter except for upcasing the first letter of
each word but the first. Examples
Figure 14 - Examples compartments of attributes
3.2.3.2 Generalization
A generalization relates a specific classifier to a more general classifier, and is owned by the
specific classifier.
It is a special classifier derived by Directed Relationship.
Semantics
Each Generalization is a binary relationship that relates a specific Classifier to a more general
Classifier (i.e., a subclass).
Generalization applies to all classifiers and some other modeling elements.
Notation
A Generalization is shown as a line with an hollow triangle as an arrowhead between the symbols
representing the involved classifiers.
The arrowhead points to the symbol representing the general classifier.
The summarized arrows represent a generalization set, which is among the exam topics for
advanced certification.
This notation is referred to as the ―separate target style‖.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
27
Figure 15 - Multiple subtype partitions (GeneralizationSets) example
3.2.3.3 RedefinableElement
A redefinable element is an element that, when defined in the context of a classifier, can be
redefined more specifically or differently in the context of another classifier that specializes
(directly or indirectly) the context classifier.
A redefining element must be consistent with the element it redefines, but it can add specific
constraints or other details that are particular to instances of the specializing redefinition context
that do not contradict invariant constraints in the general context. Semantics
Subclassifiers inherit all features of their superclassifiers, and they can enhance them by adding
features or can overwriting them.
In UML, overwriting (redefining) feature is controlled by the metamodel class
RedefinableElement.
Notation
{redefines <property>}, property String.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
28
3.2.4 Features Diagram
3.2.4.1 Feature
A feature declares a behavioral or structural characteristic of instances of classifiers.
Presentation Options
Only the names of static features are underlined.
3.2.4.2 BehavioralFeature
A behavioral feature is a feature of a classifier that specifies an aspect of the behavior of its
instances.
3.2.4.3 StructuralFeature
A structural feature is a typed feature of a classifier that specify the structure of instances of the
classifier.
3.2.4.4 Parameter
A parameter is a specification of an argument used to pass information into or out of an
invocation of a behavioral feature.
A parameter has a type, a multiplicity and a direction.
Semantics
A parameter specifies how arguments are passed into or out of an invocation of a behavioral
feature like an operation.
Style Guidelines
A parameter name typically starts with a lowercase letter.
Notation
The syntax of a parameter looks like this:
[direction] name:type [multiplicity] [=default] [{property string}]
The property string for a parameter can be one of the values known for properties, such as
{ordered} and {nonunique}.
3.2.4.5 ParameterDirectionKind
Parameter direction kind is an enumeration type that defines literals used to specify direction of
parameters.
Description
The direction of a parameter is specified by use of the keywords in, out, inout, or return,
depending on what you want to do with the data. The Default value in is assumed if no direction
is stated.
Semantic
ParameterDirectionKind is an enumeration of the following literal values:
• in Indicates that parameter values are passed into the behavioral element by the caller.
• inout Indicates that parameter values are passed into a behavioral element by the caller and
then
back out to the caller from the behavioral element.
• out Indicates that parameter values are passed from a behavioral element out to the caller.
• return Indicates that parameter values are passed as return values from a behavioral element
back
to the caller.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
29
3.2.5 Expressions Diagram
3.2.5.1 Expression
An expression is a structured tree of symbols that denotes a (possibly empty) set of values when
evaluated in a context.
Semantics
An expression in UML 2.0 is a symbol or symbols signifying a set of value
Notation
By default an expression with no operands is notated simply by its symbol, with no quotes. An
expression with operands is notated by its symbol, followed by round parentheses containing its
operands in order. In particular contexts special notations may be permitted, including infix
operators. Examples
xor
else
plus(x,1)
x+1
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
30
3.2.6 Constraints Diagram
Figure 16 - The Constraints diagram of the Kernel package
3.2.6.1 Constraint
A constraint is a condition or restriction expressed in natural language text or in a machine
readable language for the purpose of declaring some of the semantics of an element.
Description
Constraint is a condition (a Boolean expression) that restricts the extension of the associated
element beyond what is imposed by the other language constructs applied to that element.
Constraint contains an optional name, although they are commonly unnamed.
Semantics
Constraints are often expressed as a text string in some language. If a formal language such as
OCL is used, then tools may be able to verify some aspects of the constraints.
Constraint is a condition (a Boolean expression) that restricts the semantics of an element, and it
must always be true. Notation
A Constraint is shown as a text string in braces ({}) according to the following BNF:
constraint ::= ‗{‗ [ <name> ‗:‘ ] <boolean expression>‘ }‘ Examples
Figure 17 - Constraint attached to an attribute
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
31
3.2.7 Class Diagram
Figure 18 - The Classes diagram of the Kernel package
3.2.7.1 Class
A class describes a set of objects that share the same specifications of features, constraints, and
semantics. Description
Class is a kind of classifier whose features are attributes and operations.
Notation
A class is shown using the classifier symbol. As class is the most widely used classifier, the
keyword ―class‖ need not be shown in guillemets above the name. A classifier symbol without a
metaclass shown in guillemets indicates a class. Presentation Options
A class is often shown with three compartments. The middle compartment holds a list of
attributes while the bottom compartment holds a list of operations.
Attributes or operations may be presented grouped by visibility. A visibility keyword or symbol
can then be given once for multiple features with the same visibility.
Additional compartments may be supplied to show other details, such as constraints, or to divide
features. Style Guidelines
• Center class name in boldface.
• Capitalize the first letter of class names (if the character set supports uppercase).
• Left justify attributes and operations in plain face.
• Begin attribute and operation names with a lowercase letter.
• Put the class name in italics if the class is abstract.
• Show full attributes and operations when needed and suppress them in other contexts or when
merely referring to a class.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
32
Examples
Figure 19 - Class notation: details suppressed, analysis-level details, implementation-level details
Figure 20 - Class notation: attributes and operations grouped according to visibility
3.2.7.2 Association
Figure 21 - Association diagram
An association describes a set of tuples whose values refers to typed instances.
An instance of an association is called a link.
An association specifies a links between instances of associated types.
When a property is owned by an association it represents a non-navigable end of the association.
In this case the property does not appear in the namespace of any of the associated classifiers.
When a property at an end of an association is owned by one of the associated classifiers it
represents a navigable end of the association. In this case the property is also an attribute of the
associated classifier. Only binary associations may have navigable ends. Generalizations
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
33
• ―Classifier (from Kernel, Dependencies, PowerTypes)‖
• ―Relationship (from Kernel)‖
Semantics
An association declares that there can be links between instances of the associated types.
When one or more ends of the association have isUnique=false, it is possible to have several
links associating the same set of instances.
When one or more ends of the association are ordered, links carry ordering information in
addition to their end values.
An end property of an association that is owned by an end class or that is a navigable owned end
of the association indicates that the association is navigable from the opposite ends, otherwise
the association is not navigable from the opposite ends.
Examples
A unary association indicate that an employee can be or not a manager of another employee.
Figure 22 - Unary association
Figure 23 shows a binary association from Player to Year named PlayedInYear.
PlayedInYear is an association name.
The solid triangle indicates the order of reading: Player PlayedInYear Year. The reading direction
refers only to the name and no at all to the navigability of association.
The figure further shows a ternary (N-ary) association between Team, Year, and Player with ends
named team, season, and goalie respectively.
Figure 23 - Binary and ternary associations
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
34
The following adornments are shown on the four association ends in Figure 23.
Figure 24 - Association ends with various adornments
• Names a, b, and d on three of the ends.
• Multiplicities 0..1 on a, * on b, 1 on the unnamed end, and 0..1 on d.
• Specification of ordering on b.
• Subsetting on d. For an instance of class C, the collection d is a subset of the collection b.
Figure 25 shows the notation for a derived union. The attribute A::b is derived by being the strict
union of all of the attributes that subset it. In this case there is just one of these, A1::b1. So for
an instance of the class A1, b1 is a subset of b, and b is derived from b1.
Figure 25 - Derived supersets (union)
The following examples show notation for navigable ends.
Figure 26 - Examples of navigable ends
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
35
In Figure 26:
• The top pair AB shows a binary association with two navigable ends.
• The second pair CD shows a binary association with two non-navigable ends.
• The third pair EF shows a binary association with unspecified navigability.
• The fourth pair GH shows a binary association with one end navigable and the other non-
navigable.
• The fifth pair IJ shows a binary association with one end navigable and the other having
unspecified navigability.
An aggregation is an association expanded by the semantically noncommittal comment that the
participating classes have o equal-ranking relationship; instead, the represent a whole-parts
hierarchy.
Only binary associations can be aggregations.
Composite aggregation is a strong form of aggregation that requires a part instance be included
in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted
with it.
A composition is a strict form of aggregation, where the existence for its parts depends on the
whole.
Figure 27 shows the black diamond notation for composite aggregation.
Figure 27 - Composite aggregation is depicted as a black diamond
Changes from UML 1.x
AssociationEnd was a metaclass in prior UML, now demoted to a member of Association. The
metaatribute targetScope which characterized AssociationEnd in prior UML is no longer
supported. Fundamental changes in the abstract syntax make it impossible to continue
targetScope or replace it by a new metaattribute, or even a standard tag, there being no
appropriate model element to tag. In UML 2, the type of the property determines the nature of
the values represented by the members of an Association.
3.2.7.3 AggregationKind
AggregationKind is an enumeration type that specifies the literals for defining the kind of
aggregation of a property.
Figure 28 – AggregationKind
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
36
• none Indicates that the property has no aggregation.
• shared Indicates that the property has a shared aggregation. (Refers to aggregation)
• composite Indicates that the property is aggregated compositely, i.e., the composite object has
responsibility for the existence and storage of the composed objects (parts).
3.2.7.4 Property
A property is a structural feature, is an attribute that belongs to a class or association.
Figure 29 - Property diagram
Description
When a property is owned by a class it represents an attribute. In this case it relates an instance
of the class to a value or set of values of the type of the attribute.
When a property is owned by an association it represents a non-navigable end of the association.
In this case the type of the property is the type of the end of the association.
It represent by an individual value in each object. The attribute has no identity outside the
object.
An attribute is a role that a property can take on type, visibility, an initial value or property
string.
Property is indirectly a subclass of Constructs::TypedElement.
Semantics
When a property is owned by a class or data type via ownedAttribute, then it represents an
attribute of the class or data type.
The UML metamodel does not have a metaclass for attributes. An attribute is a role that a
property can take on.
When owned by an association via ownedEnd, it represents a non-navigable end of the
association. In either case, when instantiated a property represents a value or collection of values
associated with an instance of one (or in the case of a ternary or higher-order association, more
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
37
than one) type. This set of classifiers is called the context for the property; in the case of an
attribute the context is the owning classifier, and in the case of an association end the context is
the set of types at the other end or ends of the association.
The value or collection of values instantiated for a property in an instance of its context conforms
to the property‘s type.
Property inherits from MultiplicityElement and thus allows multiplicity bounds to be specified.
These bounds constrain the size of the collection. Typically and by default the maximum bound is
1.
Property also inherits the isUnique and isOrdered meta-attributes. When isUnique is true (the
default) the collection of values may not contain duplicates. When isOrdered is true (false being
the default) the collection of values is ordered. In combination these two allow the type of a
property to represent a collection in the following way:
Table 2 - Collection types for properties
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
38
If there is a default specified for a property, this default is evaluated when an instance of the
property is created in the absence of a specific setting for the property or a constraint in the
model that requires the property to have a specific value. The evaluated default then becomes
the initial value (or values) of the property.
If a property is derived, then its value or values can be computed from other information. Actions
involving a derived property behave the same as for a nonderived property. Derived properties
are often specified to be read-only (i.e. clients cannot directly change values). But where a
derived property is changeable, an implementation is expected to appropriately change the
source information of the derivation. The derivation for a derived property may be specified by a
constraint.
The name and visibility of a property are not required to match those of any property it
redefines.
A derived property can redefine one which is not derived. An implementation must ensure that
the constraints implied by the derivation are maintained if the property is updated.
If a property has a specified default, and the property redefines another property with a specified
default, then the redefining property‘s default is used in place of the more general default from
the redefined property.
If a navigable property (attribute) is marked as readOnly then it cannot be updated, once it has
been assigned an initial value.
A property may be marked as the subset of another, as long as every element in the context of
subsetting property conforms to the corresponding element in the context of the subsetted
property. In this case, the collection associated with an instance of the subsetting property must
be included in (or the same as) the collection associated with the corresponding instance of the
subsetted property.
A property may be marked as being a derived union. This means that the collection of values
denoted by the property in some context is derived by being the strict union of all of the values
denoted, in the same context, by properties defined to subset it.
If the property has a multiplicity upper bound of 1, then this means that the values of all the
subsets must be null or the same.
A property may be owned by and in the namespace of a datatype.
Notattion
Each attribute is described at least by its name. In addition, you can define a type, a visibility, an
initial value, and so on. The full syntax is a follows:
[visibility][/]name[:type][multiplicity][=initial value][{property string}] Example
Name: String =‘unknown‘
Radius : integer = 25{readonly}
- versionNo: Integer
dynamArray[*]{ordered}
/age: Integer =21 {unique} Visibility <visibility> is the visibility of the property. <visibility> ::= ‘+’ | ‘-‘ | ‘#’ | ‘~’
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
39
Derived
‗/‘ signifies that the property is derived.
Name
<name> is the name of the property.
Type
<type> is the name of the Classifier that is the type of the property. Mutiplicity
Square brackets [1..*]. <multiplicity> is the multiplicity of the property. If this term is omitted, it implies a multiplicity of 1 (exactly one).
Default
<default> is an expression that evaluates to the default value or values of the property.
specifies the initial value of the attribute
Property string
<property string > indicates a modifier that applies to the property.
{readonly} If true, the attribute may only be read, and not written. The default value is false.
{Union} The property is a union of subsets.
{subsets <property>} The property is a subset of <property>
{sequence} An ordered list (identical elements are permitted)
{composite} The property is an existence-dependent part. and others.
{redefines <property>} The property is a new defition
{ordered} An ordered list (array, identical elements are permitted)
{Unique} A set may not contain a several identical elements
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
40
3.2.8 Operations Diagram
Figure 30 - The Operations diagram of the Kernel package.
3.2.8.1 Operation
Description
An operation is a behavioral feature of a classifier that specifies the name, type, parameters, and
constraints for invoking an associated behavior.
Parameter is an argument that is passed by a behavioral feature or return by this behavioral
feature.
Semantics
An operation is invoked on an instance of the classifier for which the operation is a feature.
The pre-conditions for an operation define conditions that must be true when the operation is
invoked (before invoke). These preconditions may be assumed by an implementation of this
operation.
The post-conditions for an operation define conditions that will be true when the invocation of the
operation is completes successfully, assuming the preconditions were satisfied (after invoke).
These postconditions must be satisfied by any implementation of the operation.
If an exception occurs during the execution, the pós-condition must not be true.
The body-conditions for an operation define conditions that will be true when an operation is
running (during the execution).
Notation
The syntax operations is described somewhat imprecisely in the UML specification. In fact, the
syntax given in the specification appears not to be totally correct, and the examples used in the
specification are different from those in the notation. Based on the current state of discussion,
the notation should look like this:
[visibility] name (parameter list) [:type] [{property string}]
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
41
where parameter list is a list of parameters, separated by commas.
Type of operation: It is the type of the return parameter, provided there is exactly one return
parameter. In this case, the parameter type can be written behind the parameter list to specify
the type of operation. Style Guidelines
An operation name typically begins with a lowercase letter.
Examples
getdisplay (return x : int, return y : int)
-hide (byFactor: Real) : GeomFigure
+createWindow (location: Coordinates, container: Container [0..1]): Window
+toString (): String
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
42
3.2.9 Multiplicities Diagram
Figure 31- The Multiplicities diagram of the Kernel package.
3.2.9.1 MultiplicityElement
A multiplicity is a definition of an inclusive interval of non-negative integers beginning with a
lower bound and ending with a (possibly infinite) upper bound. A multiplicity element embeds
this information to specify the allowable cardinalities for an instantiation of this element.
A multiplicity is an interval of positive integers to specifies allowable cardinalities.
Description
A MultiplicityElement also includes specifications of whether the values in an instantiation of this
element must be unique or ordered.
Cardinality
A cardinality is a concrete number of elements in a set.
Figure 32 - Cardinality representation
Designator:
• isOrdered: Boolean For a multivalued multiplicity, this attribute specifies whether the values in
an instantiation of this element are sequentially ordered. Default is false.
• isUnique : Boolean For a multivalued multiplicity, this attributes specifies whether the values in
an instantiation of this element are unique (distinct). Default is true. Semantics
r2:Bookings
Cardinality = 3
r2:Bookings:Kunde
r2:Bookings
Object model
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
43
A multiplicity defines a set of integers, single number or a value range, that define valid
cardinalities.
If a MultiplicityElement specifies a multivalued multiplicity, then an instantiation of this element
has a set of values. The multiplicity is a constraint on the number of values that may validly
occur in that set.
If the MultiplicityElement is specified as ordered (i.e. isOrdered is true), then the set of values in
an instantiation of this element is ordered. This ordering implies that there is a mapping from
positive integers to the elements of the set of values. If a MultiplicityElement is not multivalued,
then the value for isOrdered has no semantic effect
If the MultiplicityElement is specified as unordered (i.e. isOrdered is false), then no assumptions
can be made about the order of the values in an instantiation of this element.
If the MultiplicityElement is specified as unique (i.e. isUnique is true), then the set of values in an
instantiation of this element must be unique. If a MultiplicityElement is not multivalued, then the
value for isUnique has no semantic effect.
The lower and upper bounds for the multiplicity of a MultiplicityElement may be specified by value
specifications, such as (side-effect free, constant) expressions. Notation
The specific notation for a MultiplicityElement is defined by the concrete subclasses.
In general, the notation will include a multiplicity specification is shown as a text string
containing the bounds of the interval, and a notation for showing the optional ordering and
uniqueness specifications. Valid expressions
The notation for multiplicity is either a single number or a value range. A value rang is written by
stating the minimum and maximum values, separated by two dots or you can use the character *
to specify an arbitrary number of elements. This symbols is probably familiar with symbol for
infinite used for the primitive data type UnlimitedNatural.
0..1
1
*
1..*
3+5..7+1
Examples
Figure 33 - Multiplicity within a textual specification
Figure 34 - Multiplicity as an adornment to a symbol
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
44
3.2.9.2 Type
A type constrains the values represented by a typed element.
Semantics
A type represents a set of values. A typed element that has this type is constrained to represent
values within this set.
3.2.9.3 TypeElement
A typed element has a type. Description
A typed element is an element that has a type that serves as a constraint on the range of values
the element can represent. Typed element is an abstract metaclass.
Notation
Values represented by the element are constrained to be instances of the type. A typed element
with no associated type may represent values of any type.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
45
3.2.10 Instances Diagram
The Instances diagram of the Kernel package is shown in Figure 35.
Figure 35 - The Instances diagram of the Kernel package.
3.2.10.1 InstanceSpecification
An instance specification is a model element that represents a concrete instance in a modeled
system.
The terms instance and object are used synonymously.
Semantics
Any classifier, including class, association, and data type can be a classifier of an instance
specification.
A InstanceSpecification represents an entity at a point in time.
A InstanceSpecification has a set of slots that contain the value of the structural features.
Description
An instance specification specifies existence of an entity in a modeled system and completely or
partially describes the entity. The description may include:
• Classification of the entity by one or more classifiers of which the entity is an instance. If the
only classifier specified is abstract, then the instance specification only partially describes the
entity.
• The kind of instance, based on its classifier or classifiers — for example, an instance
specification whose classifier is a class describes an object of that class, while an instance
specification whose classifier is an association describes a link of that association.
• Specification of values of structural features of the entity. Not all structural features of all
classifiers of the instance specification need be represented by slots, in which case the instance
specification is a partial description.
• Specification of how to compute, derive or construct the instance (optional).
Note – When used to provide an illustration or example of an entity in a modeled system, an
InstanceSpecification class does not depict a precise run-time structure. Instead, it describes
information about such structures. No conclusions can be drawn about the implementation detail
of run-time structure. When used to specify the existence of an entity in a modeled system, an
instance specification represents part of that system. Instance specifications can be modeled
incompletely — required structural features can be omitted, and classifiers of an instance specification can be abstract, even though an actual entity would have a concrete classification. Notation
An instance specification is depicted using the same notation as its classifier, but in place of the
classifier name appears an underlined concatenation of the instance name (if any), a colon (‗:‘)
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
46
and the classifier name or names. If there are multiple classifiers, the names are all shown
separated by commas. Classifier names can be omitted from a diagram.
Figure 36 - Specification of an instance of String
An instance specification whose classifier is an association represents a link and is shown using
the same notation as for an association, but the solid path or paths connect instance
specifications rather than classifiers. It is not necessary to show an underlined name where it is
clear from its connection to instance specifications that it represents a link and not an
association.
End names can adorn the ends.
Navigation arrows can be shown, but if shown, they must agree with the navigation of the
association ends.
Example
The instance diagram below contains a link of an association having end names father e son.
Figure 37 - Instance specifications representing two objects connected by a link
3.2.10.2 ValueSpecification
A value specification indicates one or several values in a model.
Semantics
Value specification is a simple mathematical expressions, such as 4 + 2, and expressions with
values from the object model, Integer: MAX_INT – 1.
Notation
If an instance specification has a value specification as its specification, the value specification is
shown either after an equal sign (―=‖) following the name, or without an equal sign below the
name. If the instance specification is shown using an enclosing shape (such as a rectangle) that
contains the name, the value specification is shown within the enclosing shape.
Figure 38 - Value Specification
op1: LiteralInteger
value = 1:Expression
symbol = "+"
Operand
op2: LiteralInteger
value = 1
Operand
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
47
3.2.10.3 Slot
A slot specifies that an entity modeled by an instance specification has a value or values for a
specific structural feature.
A slot is an attribute value of an object.
A slot represents values for a structure element of an instance specification, such as an attribute
value of an object. Description
A slot is owned by an instance specification. It specifies the value or values for its defining
feature, which must be a structural feature of a classifier of the instance specification owning the
slot.
Notation
Slots are shown using similar notation to that of the corresponding structural features. Where a
feature would be shown textually in a compartment, a slot for that feature can be shown
textually as a feature name followed by an equal sign (‗=‘) and a value specification. Other
properties of the feature, such as its type, can optionally be shown.
Figure 39 - Slots with values
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
48
3.2.11 Package Diagram
3.2.11.1 Package
A package is used to group elements, and provides a namespace for the grouped elements.
Description
Only packageable elements can be owned members of a package
By virtue of being a namespace, a package can import either individual members of other
packages, or all the members of other packages.
In addition a package can be merged with other packages.
Semantics
A package is a namespace and is also an packageable element that can be contained in other
packages.
A package owns its owned members, with the implication that if a package is removed from a
model, so are the elements owned by the package.
The public contents of a package is always accessible outside the package through the use of
qualified names.
Notation
A package is shown as a large rectangle with a small rectangle (a ―tab‖) attached to the left side
of the top of the large rectangle. The members of the package may be shown within the large
rectangle. Members may also be shown by branching lines to member elements, drawn outside
the package. A plus sign (+) within a circle is drawn at the end attached to the namespace
(package).
• If the members of the package are not shown within the large rectangle, then the name of the
package should be placed within the large rectangle.
• If the members of the package are shown within the large rectangle, then the name of the
package should be placed within the tab.
The visibility of a package element may be indicated by preceding the name of the element by a
visibility symbol (‗+‘ for public and ‗-‘ for private). Package elements with defined visibility may
not have protected or package visibility.
Examples
There are three representations of the same package Types in Figure 40.
The one on the left just shows the package without revealing any of its members.
The middle one shows some of the members within the borders of the package, and the one to
the right shows some of the members using the alternative membership notation.
Figure 40 - Examples of a package with members
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
49
3.2.11.2 VisibilityKind
VisibilityKind is an enumeration type that defines literals to determine the visibility of elements in
a model. Description
VisibilityKind is an enumeration of the following literal values:
• public
• private
• protected
• package Semantics
VisibilityKind is intended for use in the specification of visibility in conjunction with, for example,
the Imports, Generalizations and Packages packages.
• A public element is visible to all elements that can access the contents of the namespace that
owns it.
• A private element is only visible inside the namespace that owns it.
• A protected element is visible to elements that have a generalization relationship to the
namespace that owns it.
• A package element is owned by a namespace that is not a package, and is visible to elements
that are in the same package as its owning namespace. Only named elements that are not owned
by packages can be marked as having package visibility. Any element marked as having package
element is visible to all elements within the nearest enclosing package (given that other owning
elements have proper visibility). Outside the nearest enclosing package, an element marked as
having package visibility is not visible.
In circumstances where a named element ends up with multiple visibilities, for example by being
imported multiple times, public visibility overrides private visibility, i.e., if an element is imported
twice into the same namespace, once using a public import and once using a private import, it
will be public.
3.2.11.3 PackageableElement
A packageable element indicates a named element that may be owned directly by a package. Semantics
A package element is a named element that belongs to a package.
Examples
Operation not belongs to a package.
Class belongs to a package.
3.2.11.4 PackageImport
A package import is a relationship that allows the use of unqualified names to refer to package
members from other namespaces.
Description
A package import is defined as a directed relationship that identifies a package whose members
are to be imported by a namespace.
PackageImport not permit alias name.
Semantics
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
50
A package import is a relationship between an importing namespace and a package, indicating
that the importing namespace adds the names of the members of the package to its own
namespace. Conceptually, a package import is equivalent to having an element import to each
individual member of the imported namespace, unless there is already a separately-defined
element import.
Notation
A package import is shown using a dashed arrow with an open arrowhead from the importing
namespace to the imported package. A keyword is shown near the dashed arrow to identify
which kind of package import that is intended. The predefined keywords are «import» for a public
package import , and «access» for a private package import.
Presentation options
As an alternative to the dashed arrow, it is possible to show an element import by having a text
that uniquely identi-fies the imported element within curly brackets either below or after the
name of the namespace. The textual syntax is then:
‗{import ‘ <qualified-name> ‗}‘ | ‗{access ‘ <qualified-name> ‗}‘
<<access>>
- Is not transitive in another words observing example below: The elements of Auxiliary cannot
be referenced in Webshop.
- Attributes public and private
- Alias name for element import.
<<import>>
- Is transitive in another words observing example below: The elements of WebShop can access
public elements in Type.
- Only attributes public
- Alias name for element import.
Examples
In Figure 41, a number of package imports are shown. The elements in Types are imported to
ShoppingCart, and then further imported WebShop. However, the elements of Auxiliary are only
accessed from ShoppingCart, and cannot be referenced using unqualified names from WebShop.
Figure 41- Examples of public and private package imports
3.2.11.5 ElementImport
An element import identifies an element in another package, and allows the element to be
referenced using its name without a qualifier.
Description
An element import is defined as a directed relationship between an importing namespace and a
packageable element that resides in another namespace. The name of the packageable element
or its alias is to be added to the namespace of the importing namespace (alias name is optional).
It is also possible to control whether the imported element can be further imported.
Semantics
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
51
An element import is used to selectively import individual elements without relying on a package
import.
An imported element can be further imported by other namespaces using either element or
member imports.
The visibility of the ElementImport may be either the same or more restricted than that of the
imported element.
Notation
An element import is shown using a dashed arrow with an open arrowhead from the importing
namespace to the imported element. The keyword «import» is shown near the dashed arrow if
the visibility is public, otherwise the key-word «access» is shown.
If an element import has an alias, this is used in lieu of the name of the imported element. The
aliased name may be shown after or below the keyword «import». Presentation options
If the imported element is a package, the keyword may optionally be preceded by element, i.e.,
«element import».
As an alternative to the dashed arrow, it is possible to show an element import by having a text
that uniquely identifies the imported element within curly brackets either below or after the name
of the namespace.
The textual syntax is then:
{element import <qualifiedName>} or {element access <qualifiedName>}
Optionally, the aliased name may be show as well:
{element import <qualifiedName> as <alias>} or {element access <qualifiedName> as <alias>} Examples
The element import that is shown in Figure 42 allows elements in the package Program to refer
to the type Time in Types without qualification. However, they still need to refer explicitly to
Types::Integer, since this element is not imported.
Figure 42 - Example of element import
In Figure 43, the element import is combined with aliasing, meaning that the type Types::Real
will be referred to as Double in the package Shapes.
Figure 43 - Example of element import with aliasing
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
52
3.2.11.6 Package Merge
A package merge defines how the contents of one package are extended by the contents of
another package. Semantics
A classifier from the target (merged) package is transformed into a classifier with the same name
in the source (merging) package, unless the source package already contains a classifier of the
same kind with the same name.
In the former case, the new classifier gets a generalization to the classifier from the target
package.
In the latter case, the already existing classifier gets a generalization to the classifier from the
target package.
In either case, every feature of the general classifier is redefined in the specific classifier in such
a way that all types refer to the transformed classifiers.
In addition, the classifier in the source package gets generalizations to each transformed
superclassifier of the classifier from the target package.
This is because the superclassifiers may have merged in additional properties in the source
package that need to be propagated properly to the classifier.
Classifiers of the same kind with the same name from multiple target packages are transformed
into a single classifier in the source package, with generalizations to each target classifier.
Nested classifiers are recursively transformed the same way. If features from multiple classifiers
are somehow conflicting, the same rules that apply for multiple inheritance are used to resolve
conflicts.
Notation
A PackageMerge is shown using a dashed line with a stick arrowhead pointing from the merging
package (the source) to the merged package (the target). In addition, the keyword «merge» is
shown near the dashed line.
Figure 44 - Notation for package merge
Examples
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
53
In Figure 45, packages P and Q are being merged by package R, while package S merges only
package Q.
Figure 45 - Simple example of package merges
The transformed packages R and S are shown in Figure 46. While not shown, the package
merges have been transformed into package imports.
Figure 46 - Simple example of transformed packages
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
54
3.3 Dependency Package
3.3.1 Dependency
A dependency is a relationship that signifies that a single or a set of model elements requires
other model elements for their specification or implementation.
This means that the complete semantics of the depending elements is either semantically or
structurally dependent on the definition of the supplier element(s). Semantics
A dependency signifies a supplier/client relationship between model elements where the
modification of the supplier may impact the client model elements.
A dependency implies the semantics of the client is not complete without the supplier.
The presence of dependency relationships in a model does not have any runtime semantics
implications, it is all given in terms of the model-elements that participate in the relationship, not
in terms of their instances. Notation
A dependency is shown as a dashed arrow between two model elements.
The model element at the tail of the arrow (the client) depends on the model element at the
arrowhead (the supplier), but a supplier element is unaffected by a change in the client element.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
55
The arrow may be labeled with an optional stereotype and an optional name.
It is possible to have a set of elements for the client or supplier. In this case, one or more arrows
with their tails on the clients are connected the tails of one or more arrows with their heads on
the suppliers.
A small dot can be placed on the junction if desired. A note on the dependency should be
attached at the junction point.
Figure 47 - Notation for a dependency between two elements
Examples
In the example below, the Car class has a dependency on the Vehicle Type class. In this case,
the dependency is an instantiate dependency, where the Car class is an instance of the Vehicle
Type class.
Figure 48 - An example of a instantiate dependency
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
56
3.3.2 Abstraction
An abstraction is a relationship that relates two elements or sets of elements that represent the
same concept at different levels of abstraction or from different viewpoints.
In the metamodel, an Abstraction is a Dependency in which there is a mapping between the
supplier and the client.
Semantics
Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and
it may be unidirectional or bidirectional.
Abstraction has predefined stereotypes (such as «derive», «refine», and «trace») which are
defined in the Standard Profiles chapter.
If an Abstraction element has more than one client element, the supplier element maps into the
set of client elements as a group.
For example, an analysis-level class might be split into several design-level classes. The situation
is similar if there is more than one supplier element. Notation
An abstraction relationship is shown as a dependency with an «abstraction» keyword attached to
it or the specific predefined stereotype name. Examples
In the example below, the Employee class identified in analysis (i.e., the «type») maps to the
same concept in the design model called Employee Record.
Figure 49 - An example of a refine abstraction
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
57
3.3.3 Usage
A usage is a relationship in which one element requires another element (or set of elements) for
its full implementation or operation. In the metamodel, a Usage is a Dependency in which the
client requires the presence of the supplier.
Semantics
The usage dependency does not specify how the client uses the supplier other than the fact that
the supplier is used by of the definition or implementation of the client.
The usage dependency mean in a relationship between one element and another requires
another element for its full implementation or operation. Notation
A usage dependency is shown as a dependency with a «use» keyword attached to it. Examples
In the example below, a Order class requires the Line Item class for its full implementation.
Figure 50 - An example of a use dependency
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
58
3.3.4 Permission
Permission signifies granting of access rights from the supplier model element to a client model
element. Or to put it another way, it signifies that the client requires access to some or all of the
constituent elements of the supplier. The supplier element gives the client permission to access
some or all of its constituents elements. Notation
A permission dependency is shown as a dependency with a «permit» keyword attached to it. Examples
In the example below, the Employee class grants access rights to Executive objects.
This means that executive objects may access the private properties of salary and
homePhoneNumber, but employee can access only public properties of Executive.
Figure 51 - An example of a permit dependency
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
59
3.3.5 Realization
Realization is a specialized abstraction relationship between two sets of model elements, where
the supplier represents the specification and the client represents the implementation. One
specifies the source (the supplier); the other implements the targer (the client). Realization can
be used to model stepwise refinement, optimizations, transformations, templates, model
synthesis, framework composition, etc.
Semantics
A Realization signifies that the client set of elements are an implementation of the supplier set,
which serves as the specification. The meaning of ‗implementation‘ is not strictly defined, but
rather implies a more refined or elaborate form in respect to a certain modeling context. It is
possible to specify a mapping between the specification and implementation elements, although
it is not necessarily computable. Notation
A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that
corresponds to the realized element.
Figure 52 illustrates an example in which the Business class is realized by a combination of
Owner and Employee classes.
Figure 53 - An example of a realization dependency
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
60
3.3.6 Substitution
A substitution is a relationship between two classifiers signifies that the substitutingClassifier
complies with the contract specified by the contract classifier. This implies that instances of the
substitutingClassifier are runtime substitutable where instances of the contract classifier are
expected. Semantics
The substitution relationship denotes runtime substitutability which is not based on specialization.
Substitution, unlike specialization, does not imply inheritance of structure, but only compliance of
publicly available contracts. Notation
A Substitution dependency is shown as a dependency with the keyword «substitute» attached to
it. Examples
In the example below, a generic Window class is substituted in a particular environment by the
Resizable Window class.
Figure 54 - An example of a substitute dependency
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
61
3.4 Interface Package
An interface is a kind of classifier that represents a declaration of a set of coherent public
features and obligations. In a sense, an interface specifies a kind of contract which must be
fulfilled by any instance of a classifier that realizes the interface.
An interface is a classifier that represents the declaration of a set of coherent public features and
Obligations.
Since interfaces are declarations, they are not directly instantiable. Instead, an interface
specification is realized by an instance of a classifier, such as a class, which means that it
presents a public facade that conforms to the interface specification. Note that a given classifier
may realize more than one interface and that an interface may be realized by a number of
different classifiers.
Figure 55 - The contents of Interfaces package
Notation
As a classifier, an interface may be shown using a rectangle symbol with the keyword «interface»
preceding the name.
The realization dependency from a classifier to an interface is shown by representing the
interface by a circle or ball, labelled with the name of the interface, attached by a solid line to the
classifier that implements this interface (see Figure 56).
Figure 56 - Isensor is the provided interface of ProximitySensor
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
62
The usage dependency from a classifer to an interface is shown by representing the interface by
a half-circle or socket, labeled with the name of the interface, attached by a solid line to the
classifier that require this interface (see Figure 57).
Figure 57 - Isensor is the required interface of TheftAlarm
Where two classifiers provide and require the same interface, respectively, these two notations
may be combined as shown in Figure 58. The ball-and-socket notation hints at that the interface
in question serves to mediate interactions between the two classifiers.
Figure 58 - Isensor is the required interface of TheftAlarm as well as the provided
Alternatively, in cases where interfaces are represented using the rectangle notation, interface
realization and usage dependencies are denoted with appropriate dependency arrows (see Figure
55). The classifier at the tail of the arrow implements the interface at the head of the arrow or
uses that interface, respectively.
Figure 59 - Alternative notation
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
63
3.4.1 InterfaceRealization
An InterfaceRealization is a specialized Realization relationship between a Classifier and an
Interface.
This relationship signifies that the realizing classifier conforms to the contract specified by the
Interface.
A classifier implementing (realize) an interface conforms to its contract.
Semantics
A classifier that implements an interface specifies instances that are conforming to the interface
and to any of its ancestors. A classifier may implement a number of interfaces.
The set of interfaces implemented by the classifier are its provided interfaces and signify the set
of services the classifier offers to its clients. A classifier implementing an interface supports the
set of features owned by the interface.
In addition to supporting the features, a classifier must comply with the constraints owned by the
interface.
An implementation relationship between a classifier and an interface implies that the classifier
supports the set of features owned by the interface, and any of its parent interfaces.
For behavioral features, the implementing classifier will have an operations or reception for every
operation or reception, respectively, owned by the interface. For properties, the implementing
classifier will provide functionality that maintains the state represented by the property.
Figure 60 - An example of InterfaceRealization
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
64
3.5 Diagrams
Structure diagram
This section outlines the graphic elements that may be shown in structure diagrams, and
provides cross references where detailed information about the semantics and concrete notation
for each element can be found. It also furnishes examples that illustrate how the graphic
elements can be assembled into diagrams.
The graphic nodes that can be included in structure diagrams are shown in Table 3.
Table 3 - Graphic nodes included in structure diagrams
TYPE NOTATION Obs.
Class
Interface
InstanceSpecification
Package
The graphic paths that can be included in structure diagrams are shown Table 4.
Table 4 - Graphic nodes included in structure diagrams
TYPE NOTATION Obs.
Association (Directed relationship)
Aggregation
Composition
Dependency
Generalization
Realization <<realize>>
Package Merge <<merge>>
PackageImport (private)
<<uses>>
PackageImport (public)
<<impot>>
<<access>>
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
65
Abstraction Permission <<permit>>
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
66
4 Behavior Diagrams (Basic)
This part specifies the dynamic, behavioral constructs (e.g., activities, interactions, state
machines) used in various behavioral diagrams, such as activity diagrams, sequence diagrams,
and state machine diagrams.. The UML packages that support behavioral modeling, along with
the structure packages they depend upon (CompositeStructures and Classes) are shown in Figure
61.
Figure 61 - Dependencies of the Activity packages
The function and contents of these packages are described in following chapters, which are
organized by major subject areas.
4.1 Common Behaviors
4.1.1 Overview
The Common Behaviors packages specify the core concepts required for dynamic elements and
provides the infrastructure to support more detailed definitions of behavior
The figure below shows a domain model explaining the relationship between occurrences of
behaviors. As shown in the domain model of Figure 62, the execution of a behavior may be
caused by a call behavior event (representing the direct invocation of a behavior through an
action) or a trigger event (representing an indirect invocation of a behavior, such as through an
operation call).
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
67
Figure 62 - Common Behaviors Domain Model
There are two kinds of behaviors, emergent behavior and executing behavior.
An executing behavior is performed by an object (its host) and is the description of the behavior
of this object.
An executing behavior is directly caused by the invocation of a behavioral feature of that object
or by its creation.
Emergent behavior results from the interaction of one or more participant objects. If the
participating objects are parts of a larger composite object, an emerging behavior can be seen as
indirectly describing the behavior of the container object also. Nevertheless, an emergent
behavior can result from the executing behaviors of the participant objects.
BasicBehaviors
The BasicBehaviors subpackage of the Common Behavior package introduces the framework that
will be used to specify behaviors. The concrete subtypes of Behavior will provide different
mechanisms to specify behaviors. A variety of specification mechanisms are supported by the
UML, such as automata (―StateMachine (from BehaviorStateMachines)‖ on page 564), Petri-net
like graphs (―Activity (from BasicActivities, CompleteActivities, FundamentalActivities,
StructuredActivities)‖ on page 315), informal descriptions (―UseCase (from UseCases)‖ on page
596), or partially-ordered sequences of event occurrences (―Interaction (from BasicInteraction,
Fragments)‖ on page 483).
Profiles may introduce additional styles of behavioral specification. The styles of behavioral
specification differ in their expressive power and domain of applicability. Further, they may
specify behaviors either explicitly, by describing the observable event occurrences resulting from
the execution of the behavior, or implicitly, by describing a machine that would induce these
events.
The relationship between a specified behavior and its hosting or participating instances is
independent of the specification mechanism chosen and described in the common behavior
package. The choice of specification mechanism is one of convenience and purpose; typically, the
same kind of behavior could be described by any of the different mechanisms. Note that not all
behaviors can be described by each of the different specification mechanisms, as these do not all
have the same expressive power. However, for many behaviors, the choice of specification
mechanism is one of convenience.
As shown in the domain model of Figure below, the execution of a behavior may be caused by a
call behavior occurrence (representing the direct invocation of a behavior through an action) or a
trigger occurrence (representing an indirect invocation of a behavior, such as through an
operation call). A start occurrence marks the beginning of a behavior execution, while its
completion is accompanied by a termination occurrence.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
68
Figure 63 - Invocation Domain Model
4.1.2 Class Descriptions
4.1.2.1 Behavior
Behavior is a specification of how its context classifier changes state over time. This specification
may be either a definition of possible behavior execution or emergent behavior, or a selective
illustration of an interesting subset of possible executions. The latter form is typically used for
capturing examples, such as a trace of a particular execution.
A classifier behavior is always a definition of behavior and not an illustration. It describes the
sequence of state changes an instance of a classifier may undergo in the course of its lifetime. Its
precise semantics depends on the kind of classifier. For example, the classifier behavior of a
collaboration represents emergent behavior of all the parts, whereas the classifier behavior of a
class is just the behavior of instances of the class separated from the behaviors of any of its
parts.
When a behavior is associated as the method of a behavioral feature, it defines the
implementation of that feature; i.e., the computation that generates the effects of the behavioral
feature.
As a classifier, a behavior can be specialized. Instantiating a behavior is referred to as
―invocating‖ the behavior, an instantiated behavior is also called a behavior ―execution.‖ A
behavior may be invoked directly or its invocation may be the result of invoking the behavioral
feature that specifies this behavior. A behavior can also be instantiated as an object in virtue of it
being a class.
The specification of a behavior can take a number of forms, as described in the subclasses of
Behavior. Behavior is an abstract metaclass factoring out the commonalities of these different
specification mechanisms.
When a behavior is invoked, its execution receives a set of input values that are used to affect
the course of execution and as a result of its execution it produces a set of output values which
are returned, as specified by its parameters. The observable effects of a behavior execution may
include changes of values of various objects involved in the execution, the creation and
destruction of objects, generation of communications between objects, as well as an explicit set
of output values. Constraints
[1] The parameters of the behavior must match the parameters of the implemented behavioral
feature.
[2] The implemented behavioral feature must be a feature (possibly inherited) of the context
classifier of the behavior.
[3] If the implemented behavioral feature has been redefined in the ancestors of the owner of the
behavior, then the behavior must realize the latest redefining behavioral feature.
[4] There may be at most one behavior for a given pairing of classifier (as owner of the behavior)
and behavioral feature (as specification of the behavior).
Semantics
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
69
The detailed semantics of behavior is determined by its subtypes. The features of the context
classifier and elements that are visible to the context classifier are also visible to the behavior,
provided that is allowed by the visibility rules.
When a behavior is invoked, its attributes and parameters (if any) are created and appropriately
initialized. Upon invocation, the arguments of the original invocation action are made available to
the new behavior execution corresponding to its formal parameters, if any.
When a behavior completes its execution, a value or set of values is returned corresponding to
each return result parameter, if any. If such a parameter has a default value associated and the
behavior does not explicitly generate a value for this parameter, the default value describes the
value that will be returned corresponding to this parameter. If the invocation was synchronous,
any return values from the behavior execution are returned to the original caller, which is
unblocked and allowed to continue execution
The behavior executes within its context object, independently of and concurrently with any
existing behavior executions. The object which is the context of the behavior manages the input
pool holding the events to which a behavior may respond (see BehavioredClassifier).
As an object may have a number of behaviors associated, all these behaviors may access the
same input pool. The object ensures that each event on the input pool is consumed by only one
behavior.
When a behavior is instantiated as an object, it is its own context.
4.1.2.2 BehavioredClassifier
Description
A classifier can have behavior specifications defined in its namespace. One of these may specify
the behavior of the classifier itself.
Constraints
No additional constraints. Semantics
The behavior specifications owned by a classifier are defined in the context of the classifier.
Consequently, the behavior specifications may reference features of the classifier. Any invoked
behavior may, in turn, invoke other behaviors visible to its context classifier. When an instance of
a behaviored classifier is created, its classifier behavior is invoked. When an event occurrence is
recognized by an object that is an instance of a behaviored classifier, it may have an immediate
effect or the occurrence may be saved for later triggered effect.
An immediate effect is manifested by the invocation of a behavior as determined by the event
(the type of the occurrence). A triggered effect is manifested by the storage of the occurrence in
the input event pool of the object and the later consumption of the occurrence by the execution
of an ongoing behavior that reaches a point in its execution at which a trigger matches the event
(type) of the occurrence in the pool. At this point, a behavior may be invoked as determined by
the event.
When an executing behavior owned by an object comes to a point where it needs a trigger to
continue its execution, the input pool is examined for an event that satisfies the outstanding
trigger or triggers. If an event satisfies one of the triggers, the event is removed from the input
pool and the behavior continues its execution, as specified. Any data associated with the event
are made available to the triggered behavior.
It is a semantic variation whether one or more behaviors are triggered when an event satisfies
multiple outstanding triggers. If an event in the pool satisfies no triggers at a wait point, it is a
semantic variation point what to do with it. The ordering of the events in the input pool is a
semantic variation.
4.1.2.3 BehavioralFeature (from BasicBehaviors, Communications)
Generalizations
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
70
BehavioralFeature (from Kernel)‖
Description
A behavioral feature is implemented (realized) by a behavior. A behavioral feature specifies that
a classifier will respond to a designated request by invoking its implementing method.UML
Superstructure Specification, v2.2 433
Attributes
Package BasicBehaviors
• isAbstract: Boolean
If true, then the behavioral feature does not have an implementation, and one must be supplied
by a more specific element. If false, the behavioral feature must have an implementation in the
classifier or one must be inherited from a more general element. Default value is false.
Package Communications
• concurrency: CallConcurrencyKind
Specifies the semantics of concurrent calls to the same passive instance (i.e., an instance
originating from a class with isActive being false). Active instances control access to their own
behavioral features. Default value is sequential.
Associations
Package BasicBehaviors
• method: Behavior [0..*]
A behavioral description that implements the behavioral feature. There may be at most one
behavior for a particular pairing of a classifier (as owner of the behavior) and a behavioral feature
(as specification of the behavior).
Package Communications
• raisedException: Classifier [0..*]
The signals that the behavioral feature raises as exceptions. (Subsets
BehavioralFeature::raisedException)
Constraints
No additional constraints
Semantics
The invocation of a method is caused by receiving a request invoking the behavioral feature
specifying that behavior. The details of invoking the behavioral feature are defined by the
subclasses of BehavioralFeature.
Semantic Variation Points
How the parameters of behavioral features or a behavior match the parameters of a behavioral
feature is a semantic variation point. Different languages and methods rely on exact match (i.e.,
the type of the parameters must be the same), co-variant match (the type of a parameter of the
behavior may be a subtype of the type of the parameter of the behavioral feature), contra-
variant match (the type of a parameter of the behavior may be a supertype of the type of the
parameter of the behavioral feature), or a combination thereof.
Changes from previous UML
The metaattributes isLeaf and isRoot have been replaced by properties inherited from
RedefinableElement.
4.1.2.4 Event (from Communications)
Generalizations
―PackageableElement (from Kernel)‖ Description
An event is the specification of some occurrence that may potentially trigger effects by an object. Attributes
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
71
No additional attributes Associations
None. Constraints
None.
Semantics
An event is the specification of some occurrence that may potentially trigger effects by an object.
This is an abstract metaclass. Notation
None. Presentation options
None.
4.1.2.5 Signal (from Communications)
A signal is a specification of send request instances communicated between objects. The
receiving object handles the received request instances as specified by its receptions. The data
carried by a send request (which was passed to it by the send invocation occurrence that caused
that request) are represented as attributes of the signal. A signal is defined independently of the
classifiers handling the signal occurrence.
Attributes
No additional attributes
Associations
• ownedAttribute: Property [0..*]
The attributes owned by the signal. (Subsets Classifier::attribute, Namespace::ownedMember).
This association end is ordered.
Constraints
No additional constraints
Semantics
A signal triggers a reaction in the receiver in an asynchronous way and without a reply. The
sender of a signal will not block waiting for a reply but continue execution immediately. By
declaring a reception associated to a given signal, a classifier specifies that its instances will be
able to receive that signal, or a subtype thereof, and will respond to it with the designated
behavior.
Notation
A signal is depicted by a classifier symbol with the keyword «signal».
Changes from previous UML
None
4.1.2.6 SignalEvent (from Communications)
A signal event represents the receipt of an asynchronous signal instance. A signal event may, for
example, cause a state machine to trigger a transition. Description
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
72
A signal event represents the receipt of an asynchronous signal. A signal event may cause a
response, such as a state machine transition as specified in the classifier behavior of the classifier
that specified the receiver object, if the signal referenced by the send request is mentioned in a
reception owned or inherited by the classifier that specified the receiver object. UML
Superstructure Specification, v2.2 451 Attributes
• signal: Signal [1] The specific signal that is associated with this event. Associations
No additional associations Constraints
No additional constraints Semantics
A signal event occurs when a signal message, originally caused by a send action executed by
some object, is received by another (possibly the same) object. A signal event may result in the
execution of the behavior that implements the reception matching the received signal. A signal
event makes available any argument values carried by the received send request to all behaviors
caused by this event (such as transition actions or entry actions). Semantic Variation Points
The means by which requests are transported to their target depend on the type of requesting
action, the target, the properties of the communication medium, and numerous other factors. In
some cases, this is instantaneous and completely reliable while in others it may involve
transmission delays of variable duration, loss of requests, reordering, or duplication. Notation
Signal events are denoted by a list of names of the triggering signals, followed by an assignment
specification:
<signal-event> ::= <name> [‗(‗ [<assignment-specification>] ‗)‘] <assignment-specification>
::= <attr-name> [‗,‘<attr-name>]* where:
• <attr-name> is an implicit assignment of the corresponding attributes of the signal to an
attribute (with this name) of the context object owning the triggered behavior.
• <assignment-specification> is optional and may be omitted even if the signal has attributes. Changes from previous UML
This metaclass replaces SignalEvent.
4.1.2.7 Class (from Communications)
A class may be designated as active (i.e., each of its instances having its own thread of control)
or passive (i.e., each of its instances executing within the context of some other object). A class
may also specify which signals the instances of this class handle. Attributes
isActive: Boolean Determines whether an object specified by this class is active or not.
If true, then the owning class is referred to as an active class.
If false, then such a class is referred to as a passive class.
Default value is false. Associations
ownedReception: Reception [0..*] Receptions that objects of this class are willing to accept.
(Subsets Namespace::ownedMember and Classifier::feature) Constraints
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
73
[1] A passive class cannot have receptions.
(not self.isActive) implies self.ownedReception->isEmpty() Semantics
An active object is an object that, as a direct consequence of its creation, commences to execute
its classifier behavior, and does not cease until either the complete behavior is executed or the
object is terminated by some external object. (This is sometimes referred to as ―the object
having its own thread of control.‖) The points at which an active object responds to
communications from other objects is determined solely by the behavior of the active object and
not by the invoking object. If the classifier behavior of an active object completes, the object is
terminated. Notation
See presentation options below. Presentation options
A class with the property isActive = true can be shown by a class box with an additional vertical
bar on either side, as depicted in Figure below.
Figure 64 - Duration (from SimpleTime)
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
74
4.2 Activities Diagram
4.2.1 Overview
Activity modeling emphasizes the sequence and conditions for coordinating lower-level behaviors,
rather than which classifiers own those behaviors.
These are commonly called control flow and object flow models. The actions coordinated by
activity models can be initiated because other actions finish executing, because objects and data
become available, or because events occur external to the flow.
BasicActivities
The basic level supports modeling of traditional sequential flow charts. It includes control
sequencing, but explicit forks and joins of control are not supported at this level. Decisions and
merges are supported at this level and need not be well structured.
4.2.2 Abstract Syntax
Figure 65 shows the dependencies of the activity packages.
Figure 65 - Dependencies of the Activity packages
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
75
4.2.3 Class Diagrams (BasicActivities)
Figure 66 – Node
Figure 67 - Control nodes
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
76
Figure 68 - Control nodes (IntermediateActivities)
Figure 69 - Flows
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
77
Figure 70 - Actions
4.2.4 Activity
Description
An activity specifies the coordination of executions of subordinate behaviors, using a control and
data flow model.
Activities may describe procedural computation. In this context, they are the methods
corresponding to operations on classes.
Activities may be applied to organizational modeling for business process engineering and
workflow. In this context, events often originate from inside the system, such as the finishing of
a task, but also from outside the system, such as a customer call. Activities can also be used for
information system modeling to specify system level processes.
Activities may contain actions of various kinds:
• occurrences of primitive functions, such as arithmetic functions.
• invocations of behavior, such as activities.
• communication actions, such as sending of signals.
• manipulations of objects, such as reading or writing attributes or associations.
Semantics
The semantics of activities is based on token flow. By flow, we mean that the execution of one
node affects and is affected by the execution of other nodes, and such dependencies are
represented by edges in the activity diagram. A token contains an object, datum, or locus of
control, and is present in the activity diagram at a particular node.
Each token is distinct from any other, even if it contains the same value as another. A node may
begin execution when specified conditions on its input tokens are satisfied; the conditions depend
on the kind of node. When a node begins execution, tokens are accepted from some or all of its
input edges and a token is placed on the node. When a node completes execution, a token is
removed from the node and tokens are offered to some or all of its output edges.
Notation
The notation for an activity is a combination of the notations of the nodes and edges it contains,
plus a border and name displayed in the upper left corner. Activity parameter nodes are
displayed on the border. Actions and flows that are contained in the activity are also depicted.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
78
Figure 71 - Activity notation
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
79
4.2.5 ActivityNode
An activity node is an abstract class for points in the flow of an activity connected by edges. Description
An activity node is an abstract class for the steps of an activity. It covers invocation nodes,
control nodes, and object nodes.
Notation
The notations for activity nodes are illustrated below. There are a three kinds of nodes: action
node, object node, and control node. See these classes for more information.
Figure 72 - Activity node notation
Examples
This figure illustrates the following kinds of activity node: action nodes (e.g., Receive Order, Fill
Order), object nodes (Invoice), and control nodes (the initial node before Receive Order, the
decision node after Receive Order, and the fork node and Join node around Ship Order, merge
node before Close Order, and activity final after Close Order).
Figure 73 - Activity node example (where the arrowed lines are only the non-activity node symbols)
4.2.5.1 Executable Node
An executable node is an abstract class for activity nodes that may be executed. It is used as an
attachment point for exception handlers.
4.2.5.1.1 Action
An action is an executable activity node that is the fundamental unit of executable functionality in
an activity, as opposed to control and data flow among actions.
Actions are contained in activities, which provide their context. Activities provide control and data
sequencing constraints among actions as well as nested structuring mechanisms for control and
scope.
An action execution corresponds to the execution of a particular action within an activity.
Notation
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
80
Use of action and activity notation is optional. A textual notation may be used instead.
Actions are notated as round-cornered rectangles. The name of the action or other description of
it may appear in the symbol.
Figure 74 - Action
4.2.5.2 ControlNode
A control node is an abstract activity node that coordinates flows in an activity. Description
A control node is an activity node used to coordinate the flows between other nodes. It covers
initial node, final node and its children, fork node, join node, decision node, and merge node.
Notation
The notations for control nodes are illustrated below: decision node, initial node, activity final,
and flow final.
(IntermediateActivities) Fork node and join node are the same symbol, they have different
semantics and are distinguished notationally by the way edges are used with them. For more
information, see ForkNode and JoinNode below.
Figure 75 - Control node notations
Examples
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
81
The figure below contains examples of various kinds of control nodes. An initial node is depicted
in the upper left as triggering the Receive Order action. A decision node after Received Order
illustrates branching based on order rejected or order accepted conditions. Fill Order is followed
by a fork node which passes control both to Send Invoice and Ship Order.
The join node indicates that control will be passed to the merge when both Ship Order and Accept
Payment are completed. Since a merge will just pass the token along, Close Order activity will be
invoked. (Control is also passed to Close Order whenever an order is rejected.) When Close Order
is completed, control passes to an activity final.
Figure 76 - Control node examples (with accompanying actions and control flows)
4.2.5.2.1 InitialNode
An initial node is a control node at which flow starts when the activity is invoked. Description
An activity may have more than one initial node.
Constraints
[1] An initial node has no incoming edges.
Notation
Initial nodes are notated as a solid circle, as indicated in the figure below.
Figure 77 - Initial node notation
4.2.5.2.2 DecisionNode
A decision node is a control node that chooses between outgoing flows. Description
A decision node has one incoming edge and multiple outgoing activity edges.
Constraints
[1] A decision node has one incoming edge.
[2] A decision input behavior has one input parameter and one output parameter.
Semantics
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
82
Each token arriving at a decision node can traverse only one outgoing edge. Tokens are not
duplicated. Each token offered by the incoming edge is offered to the outgoing edges.
Most commonly, guards of the outgoing edges are evaluated to determine which edge should be
traversed. The order in which guards are evaluated is not defined, because edges in general are
not required to determine which tokens they accept in any particular order.
The modeler should arrange that each token only be chosen to traverse one outgoing edge,
otherwise there will be race conditions among the outgoing edges. For decision points, a
predefined guard ―else‖ may be defined for at most one outgoing edge. This guard succeeds for a
token only if the token is not acepted by all the other edges outgoing from the decision point.
Notice that the semantics only requires that the token traverse one edge, rather than be offered
to only one edge. Multiple edges may be offered the token, but if only one of them has a target
that accepts the token, then that edge is traversed. If multiple edges accept the token and have
approval from their targets for traversal at the same time, then the semantics is not defined.
Notation
The notation for a decision node is a diamond-shaped symbol, as illustrated on the left side of the
figure below. Decision input behavior is specified by the keyword «decisionInput» placed in a
note symbol, and attached to the appropriate decision node symbol as illustrated in the figure
below.
A decision node must have a single activity edge entering it, and one or more edges leaving it.
The functionality of decision node and merge node can be combined by using the same node
symbol, as illustrated at the right side of the figure below.
This case maps to a model containing a merge node with all the incoming edges shown in the
diagram and one outgoing edge to a decision node that has all the outgoing edges shown in the
diagram. It assumes the UML 2.0 Diagram Interchange RFP supports the interchange of diagram
elements and their mapping to model elements.
Figure 78 - Decision node notation
Examples
The figure below contains a decision node that follows the Received Order behavior. The
branching is based on whether order was rejected or accepted. An order accepted condition
results in passing control to Fill Order and rejected orders to Close Order.
Figure 79 - Decision node example
The example in the figure below illustrates an order process example. Here, an order item is
pulled from stock and prepared for delivery. Since the item has been remove from inventory, the
reorder level should also be checked; and if the actual level falls below a prespecified reorder
point, more of the same type of item should be reordered.
4.2.5.2.3 MergeNode
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
83
A merge node is a control node that brings together multiple alternate flows. It is not used to
synchronize concurrent flows but to accept one among several alternate flows. Description
A merge node has multiple incoming edges and a single outgoing edge.
Constraints
[1] A merge node has one outgoing edge. Semantics
All tokens offered on incoming edges are offered to the outgoing edge. There is no
synchronization of flows or joining of tokens. Notation
The notation for a merge node is a diamond-shaped symbol, as illustrated on the left side of the
figure below. In usage, however, the merge node must have two or more edges entering it and a
single activity edge leaving it. The functionality of merge node and decision node can be
combined by using the same node symbol, as illustrated at the right side of the figure below.
This case maps to a model containing a merge node with all the incoming edges shown the
diagram and one outgoing edge to a decision node that has all the outgoing edges shown in the
diagram.
It assumes the UML 2.0 Diagram Interchange RFP supports the interchange of diagram elements
and their mapping to model elements.
Figure 80 - Merge node notation
Examples
In the example below, either one or both of the behaviors, Buy Item or Make Item could have
been invoked. As each completes, control is passed to Ship Item. That is, if only one of Buy Item
or Make Item complete, then Ship Item is invoked only once; if both complete, Ship Item is
invoked twice.
Figure 81 - Merge node example
4.2.5.2.4 FinalNode
A final node is an abstract control node at which a flow in an activity stops. Description
See descriptions at children of final node.
Constraints
[1] A final node has no outgoing edges.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
84
Notation
The notations for final node are illustrated below. There are a two kinds of final node: activity
final and
(IntermediateActivities) flow final. For more detail on each of these specializations, see
ActivityFinal and FlowFinal.
Figure 82 - Final node notation
4.2.5.2.5 ActivityFinalNode
An activity final node is a final node that stops all flows in an activity. Description
An activity may have more than one activity final node. The first one reached stops all flows in
the activity.
Notation
Activity final nodes are notated as a solid circle with a hollow circle, as indicated in the figure
below. It can be thought of as a goal notated as ―bull‘s eye,‖ or target.
Figure 83 - Activity final notation
Examples
The first example below depicts that when the Close Order behavior is completed, all tokens in
the activity are terminated.
This is indicated by passing control to an activity final node.
Figure 84 - Activity final example
4.2.5.2.6 FlowFinalNode
A flow final node is a final node that terminates a flow. Description
A flow final destroys all tokens that arrive at it. It has no effect on other flows in the activity.
Semantics
Flow final destroys tokens flowing into it.
Notation
The notation for flow final is illustrated below.
Figure 85 - Flow final notation
Examples
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
85
In the example below, it is assumed that many components can be built and installed. Here, the
Build Component behavior occurs iteratively for each component. When the last component is
built, the end of the building iteration is indicated with a flow final. However, even though all
component building has come to an end, other behaviors are still executing (such as Install
Component).
Figure 86 - Flow final example without merge edge
Rationale
Flow final nodes are introduced to model termination or merging of a flow in an activity. Changes from previous UML
Flow final is new in UML 2.0.
4.2.5.3 ObjectNode
An object node is an abstract activity node that is part of defining object flow in an activity. Description
An object node is an activity node that indicates an instance of a particular classifier, possibly in a
particular state, may be available at a particular point in the activity.
Constraints (BasicActivities)
[1] All edges coming into or going out of object nodes must be object flow edges.
Notation
Object nodes are notated as rectangles. A name labeling the node is placed inside the symbol,
where the name indicates the type of the object node. Object nodes whose instances are sets of
the ―name‖ type are labeled as such. Object nodes with a signal as type are shown with the
symbol on the right.
Figure 87 - Object node notations
4.2.5.3.1 ActivityParameterNode
An activity parameter node is an object node for inputs and outputs to activities. Description
Activity parameters are object nodes at the beginning and end of flows, to accept inputs to an
activity and provide outputs from it.
Notation
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
86
Also see notation at Activity.
Figure 88 - Activity notation
4.2.5.3.2 Parameter (as specialized)
Parameter is specialized when used with complete activities. Description
Parameters are extended in complete activities to add support for streaming, exceptions, and
parameter sets.
Constraints
[1] A parameter cannot be a stream and exception at the same time.
[2] An input parameter cannot be an exception.
[3] Reentrant behaviors cannot have stream parameters. Notation
See notation at Pin and ActivityParameterNode.
4.2.5.3.3 Pin
A pin is an object node for inputs and outputs to actions. Description
Pins are connected as inputs and outputs to actions. They provide values to actions and accept
result values from them.
Constraints
[1] If the action is an invocation action, the number and types of pins must be the same as the
number of parameters and
types of the invoked behavior or behavioral feature. Pins are matched to parameters by order.
Semantics
A pin represents an input to an action or an output from an action. The definition on an action
assumes that pins are ordered (although names are usually sufficient in the notation to
disambiguate pins, so the ordering is rarely shown in the notation).
Notation
Pin rectangles may be notated as small rectangles that are attached to action rectangles. See
figure below and examples. Thename of the pin can be displayed near the pin. The name is not
restricted, but it is often just shows the type of object or data that flows through the pin.
Rationale
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
87
Pins are introduced to model inputs and outputs of actions.
4.2.5.3.4 InputPin
An input pin is a pin that holds input values to be consumed by an action. They are object nodes
and receive values from other actions through object edges. See Pin, Action, and ObjectNode for
more details.
Constraints
[1] Input pins have incoming edges only.
Notation
When edges are not present to distinguish input, an optional arrow may be placed inside the pin
rectangle, as
shown below.
Input pins have the arrow pointing toward the action.
4.2.5.3.5 OutputPin
An output pin is a pin that holds output values produced by an action. Output pins are object
nodes and deliver values to other actions through object edges. See Pin, Action, and ObjectNode
for more details.
Constraints
[1] Output pins have outgoing edges only.
Notation
When edges are not present to distinguish output pins, an optional arrow may be placed inside
the pin rectangle, as shown below.
Output pins have the arrow pointing away from the action.
4.2.6 ActivityEdge
An activity edge is an abstract class for directed connections between two activity nodes. It
covers control and
data flow edges.
Semantics
Activity edges are directed connections, that is, they have a source and a target, along which
tokens may flow.
4.2.6.1 ControlFlow
A control flow is an edge starts an activity node after the previous one is finished.
See semantics inherited from ActivityEdge. A control flow is an activity edge that only passes
control tokens. Tokens offered by the source node are all offered to the target node.
Notation
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
88
A control flow is notated by an arrowed line connecting two actions.
Figure 89 - Control Flow without actions
Figure 90 - Control Flow linking two actions
Examples
The figure below depicts an example of the Fill Order action passing control to the Ship Order
action. The activity edge between the two is a control flow which indicates that when Fill Order is
completed, Ship Order is invoked.
Figure 91 - Control flow example
Changes from previous UML
Explicitly modeled control flows are new to activity modeling in UML 2.0. They replace the use of
(state) Transition in UML 1.5 activity modeling. They replace control flows in UML 1.5 action
model.
4.2.6.2 ObjectFlow
An object flow is an activity edge that can have objects or data passing along it. Description
An object flow models the flow of values to or from object nodes. Notation
An object flow is notated by an arrowed line.
Figure 92 - Object flow without activity nodes
Figure 93 - Two object flow edges linking object nodes and actions
Figure 94 - two object node pins An object flow edge linking
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
89
4.2.7 Diagrams
The following sections describe the graphic nodes and paths that may be shown in activity
diagrams.
Graphic Nodes
The graphic nodes that can be included in structural diagrams are shown in Table 5.
Table 5- Graphic nodes included in activity diagrams
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
90
Table 6 - Graphic nodes included in activity diagrams
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
91
4.3 Interactions Diagrams
4.3.1 Overview
The Interaction package describes the concepts needed to express Interactions.Depending on
their purpose, an interaction can be displayed in several different types of diagrams: Sequence
Diagrams, Interaction Overview Diagrams and Communication Diagrams. Optional diagram types
such as Timing Diagrams and Interaction Tables come in addition.
Each type of diagram provides slightly different capabilities that makes it more appropriate for
certain situations.
Interactions are a common mechanism for describing systems that can be understood and
produced, at varying levels of detail, by both professionals of computer systems design, as well
as potential end users and stakeholders of (future) systems.
4.3.2 Abstract syntax
Figure 326 - Interaction. (from BasicInteractions)
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
92
Figure 327 - Lifeline (from BasicInteractions)
4.3.3 Interaction
An interaction is a unit of behavior that focuses on the observable exchange of information
between ConnectableElements.
Semantics
Interactions are units of behavior of an enclosing Classifier. Interactions focus on the passing of
information with Messages between the ConnectableElements of the Classifier.
A trace is a sequence of Eventoccurrences. Notation
The notation for an Interaction in a Sequence Diagram is a solid-outline rectangle. The keyword
sd followed by the Interaction name and parameters is in a pentagon in the upper left corner of
the rectangle. The notation within this rectangular frame comes in several forms: Sequence
Diagrams, Communication Diagrams, Interaction Overview Diagrams and Timing Diagrams.
Examples
Figure 95 - An example of an Interaction in the form of a Sequence Diagram
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
93
The example in Figure 95 shows three messages communicated between two (anonymous)
lifelines of types User and ACSystem. The message CardOut overtakes the message OK in the
way that the receiving event occurrences are in the opposite order of the sending
eventoccurrences. Such communication may occur when the messages are asynchronous.
Finally a fourth message is sent from the ACSystem to the environment through a gate with
implicit name out_Unlock.
The local attriburte PIN of UserAccepted is declared near the diagram top. It could have been
declared in a Note
somewhere else in the diagram.
4.3.4 InteractionOccurrence
An InteractionOccurrence refers to an Interaction. The InteractionOccurrence is a shorthand for
copying the contents of the referred Interaction where the InteractionOccurrence is. Semantics
The semantics of the InteractionOccurrence is the set of traces of the semantics of the referred
Interaction where the gates have been resolved as well as all generic parts having been bound
such as the arguments substituting the parameters. Notation
The InteractionOccurrence is shown as a CombinedFragment symbol where the operator is called
ref. The complete syntax of the name (situated in the InteractionOccurrence area) is:
name ::=[ attribute-name = ][collaborationoccurrence.] interactionname[‗(‗arguments‘)‘] [:
return-value]
argument ::= in-argument [ out out-argument]
The attribute-name refers to an attribute of one of the lifelines in the Interaction.
The collaborationoccurence is an identification of a collaboration occurrence that binds lifelines of
a collaboration.
The interaction name is in that case within that collaboration.
The arguments are most often arguments of IN-parameters. If there are OUT- or INOUT-
parameters and the output value is to be described, this can be done following an out keyword.
If the InteractionOccurrence returns a value, this may be described following a colon at the end
of the clause. Examples
Figure 96 - InteractionOccurrence
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
94
In Figure 96 we show an InteractionOccurrence referring the Interaction EstablishAccess with
(input) argument ―Illegal PIN‖. Within the optional CombinedFragment there is another
InteractionOccurrence without arguments referring OpenDoor.
4.3.5 EventOccurrence
EventOccurrences represents moments in time to which Actions are associated. An
EventOccurrence is the basic semantic unit of Interactions. The sequences of Eventoccurrences
are the meanings of Interactions. Messages are sent through either asynchronous signal sending
or operation calls. Likewise they are recieved by Receptions or actions of consumption.
EventOccurrence is a specialization of InteractionFragment and of MessageEnd.
EventOccurrences are ordered along a Lifeline.
The namespace of an EventOccurrence is the Interaction in which it is contained.
Semantics
The semantics of an EventOccurrence is just the trace of that single EventOccurrence.
The understanding and deeper meaning of the Eventoccurrence is dependent upon the associated
Message and the information that it conveys. Notation
Eventoccurrences are merely syntactic points at the ends of Messages or at the beginning/end of
an ExecutionOccurrence. Examples
Figure 97 – EventOccurrence
4.3.6 ExecutionOccurrence
An ExecutionOccurrence is an instantiation of a unit of behavior within the Lifeline.
Since the ExecutionOccurrence will have some duration, it is represented by two
Eventoccurrences, the start EventOccurrence and the finish EventOccurrence.
An ExecutionOccurrence is an InteractionFragment. Constraints
[1] The startEvent and the finishEvent must be on the same Lifeline
start.lifeline = finish.lifeline
Semantics
The trace semantics of Interactions merely see an ExecutionOccurrence as the trace <start,
finish>. There may be Eventoccurrences between these.
Typically the start Eventoccurrence and the finish Eventoccurrence will refer to Eventoccurrences
such as a receive Eventoccurrence (of a Message) and the send Eventoccurrence (of a return
Message).
Notation
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
95
ExecutionOccurences are represented as thin rectangles (grey or white) on the lifeline (see
―Lifeline (from
BasicInteractions, Fragments)‖).
We may also represent an ExecutionOccurrence as Actions are represented in Activity diagrams.
ExecutionOccurrences that refer to atomic actions such as reading attributes of a Signal
(conveyed by the Message), the Action symbol may be associated with the reception
EventOccurrence with a line in order to emphasize that the whole Action is associated with only
one EventOccurrence (and start and finish associations refer the very same EventOccurrence)
4.3.7 Gate
A Gate is a connection point for relating a Message outside an InteractionFragment with a
Message inside the
InteractionFragment.
Gate is a specialization of MessageEnd.
Gates are connected through Messages. A Gate is actually a representative of an
EventOccurrence that is not in the same scope as the Gate.
Gates play different roles: we have formal gates on Interactions, actual gates on
InteractionOccurrences, expression gates on CombinedFragments.
Constraints
[1] The message leading to/from an actualGate of an InteractionOccurrence must correspond to
the message leading from/to the formalGate with the same name of the Interaction referenced
by the InteractionOccurrence.
[2] The message leading to/from an (expression) Gate within a CombinedFragment must
correspond to the message leading from/to the CombinedFragment on its outside. Semantics
The gates are named either explicitly or implicitly. Gates may be identified either by name (if
specified), or by a
constructed identifier formed by concatenating the direction of the message and the message
name (e.g. out_CardOut).
The gates and the messages between gates have one purpose, namely to establish the concrete
sender and receiver for every message.
Notation
Gates are just points on the frame, the ends of the messages. They may have an explicit name.
See Figure Figure 97.
The same gate may appear several times in the same or different diagrams.
4.3.8 GeneralOrdering
A GeneralOrdering represents a binary relation between two Eventoccurrences, to describe that
one Eventoccurrence must occur before the other in a valid trace. This mechanism provides the
ability to define partial orders of EventOccurrences that may otherwise not have a specified
order.
A GeneralOrdering is a specialization of NamedElement.
A GeneralOrdering may appear anywhere in an Interaction, but only between Eventoccurrences.
Semantics
A GeneralOrdering is introduced to restrict the set of possible sequences. A partial order of
Eventoccurrences is defined by a set of GeneralOrdering.
Notation
A GeneralOrdering is shown by a dotted line connected the two Eventoccurrences. The direction
of the relation from the before to the after is given by an arrowhead placed somewhere in the
middle of the dotted line (i.e. not at the endpoint).
Example
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
96
A GeneralOrdering bellow means that sending p may occur before sending q.
Figure 98 - Example General Ordering
4.3.9 Lifeline
A lifeline represents an individual participant in the Interaction. While Parts and
StructuralFeatures may have multiplicity greater than 1, Lifelines represent only one interacting
entity.
Lifeline is a specialization of NamedElement.
If the referenced ConnectableElement is multivalued (i.e. has a multiplicity > 1), then the Lifeline
may have an
expression (the ‗selector‘) that specifies which particular part is represented by this Lifeline. If
the selector is omitted this means that an arbitrary representative of the multivalued
ConnectableElement is chosen.
Semantics
The order of Eventoccurrences along a Lifeline is significant denoting the order in which these
Eventoccurrence will occur. The absolute distances between the Eventoccurrences on the Lifeline
are, however, irrelevant for the semantics.
The semantics of the Lifeline (within an Interaction) is the semantics of the Interaction selecting
only Eventoccurrences of this Lifeline. Notation
A Lifeline is shown using a symbol that consists of a rectangle forming its ―head‖ followed by a
vertical line (which may be dashed) that represents the lifetime of the participant. Information
identifying the lifeline is displayed inside the rectangle in the following format:
lifelineident ::= [connectable_element_name [‗[‗ selector ‗]‘]] [: class_name] [decomposition] |
self
selector ::= expression
decomposition ::= ref interactionident
class_name is the type referenced by the represented ConnectableElement.
Even though the syntax in principle allows it, a lifelineident cannot be empty.
The Lifeline head has a shape which is based on the classifier for the part that this lifeline
represents. Often the head is a white rectangle containing the name.
If the name is the keyword self, then the lifeline represents the object of the classifier that
encloses the Interaction that owns the Lifeline. Ports of the encloser may be shown separately
even when self is included.
To depict method activations we apply a thin grey or white rectangle that covers the Lifeline line.
Examples
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
97
See Figure 95 where the Lifelines are pointed to.
4.3.10 Message
A Message defines a particular communication between Lifelines of an Interaction.
A Message is a NmedElement that defines one specific kind of communication in an Interaction.
A communication can be e.g. raising a signal, invoking an Operation, creating or destroying an
Instance. The Message specifies not only the kind of communication given by the dispatching
ExecutionOccurrence, but also the sender and the receiver.
A Message associates normally two EventOccurrences - one sending EventOccurrence and one
receiving
EventOccurrence.
Semantics
The semantics of a complete Message is simply the trace <sendEvent, receiveEvent>.
A lost message is a message where the sending event occurrence is known, but there is no
receiving event occurrence.
We interpret this to be because the message never reached its destination. The semantics is
simply the trace <sendEvent>.
A found message is a message where the receiving event occurrence is known, but there is no
(known) sending event occurrence. We interpret this to be because the origin of the message is
outside the scope of the description. This may for example be noise or other activity that we do
not want to describe in detail. The semantics is simply the trace <receiveEvent>.
When a Message represents a Signal, the arguments of the Message are the arguments of the
SendAction on the sending Lifeline and on the receiving Lifeline the arguments are available in
the SignalEvent.
Notation
A message is shown as a line from the sender message end to the receiver message end. The
form of the line or arrowhead reflect properties of the message:
Asynchronous Messages have an open arrow head.
Synchronous Messages typically represent method calls and are shown with a filled arrow head.
The reply message from a method has a dashed line.
Object creation Message has a dashed line with an open arrow.
Lost Messages are described as a small black circle at the arrow end of the Message.
Found Messages are described as a small black circle at the starting end of the Message.
On Communication Diagrams, the Messages are decorated by a small arrow along the connector
close to the Message name and sequence number in the direction of the Message.
Syntax for the Message name is the following:
messageident ::= [attribute =] signal-or-operation-name [ ( arguments) ][: return-value] | ‗*‘
arguments ::= argument [ , arguments]
argument ::= [parameter-name=]argument-value | attribute= out-parameter-name [:argument-
value]| -
Messageident equalling ‗*‘ is a shorthand for more complex alternative CombinedInteraction to
represent a message of any type. This is to match asterisk triggers in State Machines.
Return-value and attribute assignment are used only for reply messages. Attribute assignment is
a shorthand for including the Action that assigns the return-value to that attribute. This holds
both for the possible return value of the message (the return value of the associated operation),
and the out values of (in)out parameters.
When the argument list contains only argument-values, all the parameters must be matched
either by a value or by a dash (-). If parameter-names are used to identify the argument-value,
then arguments may freely be omitted. Omitted parameters get an unknown argument-value.
Examples
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
98
In Figure 95 we see only asynchronous Messages. Such Messages may overtake each other.
In Erro! Fonte de referência não encontrada. we see how Messages are denoted in
ommunication Diagrams.
Examples of syntax:
mymessage(14, - , 3.14, ―hello‖) // second argument is undefined
v=mymsg(16, variab):96 // this is a reply message carrying the return value 96 assigning it to v
mymsg(myint=16) // the input parameter ‗myint‘ is given the argument value 16
See Figure 333 for a number of different applications of the textual syntax of message
identification.
4.3.11 Stop
A Stop is an EventOccurrence that defines the termination of the instance specified by the Lifeline
on which the Stop occurs. Constraints
[1] No other EventOccurrences may appear below a Stop on a given Lifeline in an
InteractionOperand. Semantics
It is assumed that a Stop implies that the instance described by this Lifeline will terminate.
The trace representing its semantics only contains a ―stop‖ EventOccurrence. Notation
The Stop is depicted by a cross in the form of an X at the bottom of a Lifeline.
Figure 99 - Stop symbol
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
99
4.3.12 Diagrams
Sequence Diagrams
The most common kind of Interaction Diagram is the Sequence Diagram, which focuses on the
Message interchange between a number of Lifelines.
A sequence diagram describes an Interaction by focusing on the sequence of Messages that are
exchanged, along with their corresponding EventOccurrences on the Lifelines. The Interactions
that are described by Sequence Diagrams are described in this chapter.
The graphic nodes that can be included in structural diagrams are shown in Table 7.
Table 7 - Graphic nodes included in sequence diagrams
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
100
The graphic paths between the graphic nodes are given in Table 8.
Table 8 - Graphic paths included in sequence diagrams
Table 9 - Graphic paths included in sequence diagrams
Table 10 - Graphic nodes and paths included in sequence diagrams
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
101
Figure 100 - Elements Iteraction Diagram
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
102
4.4 Use Cases
4.4.1 Overview
Use cases are a means for specifying required usages of a system. Typically, they are used to
capture the requirements of a system, that is, what a system is supposed to do. The key
concepts associated with use cases are actors, use cases, and the subject. The subject is the
system under consideration to which the use cases apply.
The users and any other systems that may interact with the subject are represented as actors.
Actors always model entities that are outside the system.
The required behavior of the subject is specified by one or more use cases, which are defined
according to the needs of actors.
Strictly speaking, the term ―use case‖ refers to a use case type. An instance of a use case refers
to an occurrence of the emergent behavior that conforms to the corresponding use case type.
Such instances are often described by interaction specifications.
Use cases, actors, and systems are described using use case diagrams.
4.4.2 Abstract syntax
Figure 101 - Dependencies of the UseCases package
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
103
Figure 102 - The concepts used for modeling use cases
4.4.3 Actor (from UseCases)
An actor specifies a role played by a user or any other system that interacts with the subject.
(The term ―role‖ is used informally here and does not necessarily imply the technical definition of
that term found elsewhere in this specification.) Description
An Actor models a type of role played by an entity that interacts with the subject (e.g., by
exchanging signals and data), but which is external to the subject (i.e., in the sense that an
instance of an actor is not a part of the instance of its corresponding subject).
Actors may represent roles played by human users, external hardware, or other subjects. Note
that an actor does not necessarily represent a specific physical entity but merely a particular
facet (i.e., ―role‖) of some entity that is relevant to the specification of its associated use cases.
Thus, a single physical instance may play the role of several different actors and, conversely, a
given actor may be played by multiple different instances.
Since an actor is external to the subject, it is typically defined in the some classifier or package
that incorporates the subject classifier.
Constraints
[1] An actor can only have associations to use cases, subsystems, components and classes, and
these associations must be binary.
[2] An actor must have a name.
name->notEmpty()
Semantics
Actors model entities external to the subject. Each actor represents a coherent set of roles that
users of the subject can play when interacting with it. When an external entity interacts with the
subject, it plays the role of a specific actor. Notation
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
104
An actor is represented by ―stick man‖ icon with the name of the actor in the vicinity (usually
above or below) the icon.
Presentation Options
An actor may also be shown as a class rectangle with the keyword «actor», with the usual
notation for all compartments.
Other icons that convey the kind of actor may also be used to denote an actor, such as using a
separate icon for nonhuman actors.
Style Guidelines
Actor names should follow the capitalization and punctuation guidelines used for classes in the
model. The names of abstract actors should be shown in italics.
4.4.4 UseCase
A use case is the specification of a set of actions performed by a system, which yields an
observable result that is, typically, of value for one or more actors or other stakeholders of the
system.
Description
A UseCase is a kind of behaviored classifier that represents a declaration of an offered behavior.
Each use case specifies some behavior, possibly including variants, that the subject can perform
in collaboration with one or more actors.
Use cases can be used both for specification of the (external) requirements on a subject and for
the specification of the functionality offered by a subject. Notation
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
105
A use case is shown as an ellipse, either containing the name of the use case or with the name of
the use case placed below the ellipse. An optional stereotype keyword may be placed above the
name and a list of properties included below the name.
If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the
system boundary rectangle. Note that this does not necessarily mean that the subject classifier
owns the contained use cases, but merely that the use case applies to that classifier.
For example, the use cases shown in Figure 103 apply to the ―ATMsystem‖ classifier but are
owned by various packages as shown in Figure 104.
Figure 103 - Example of the use cases and actors for an ATM system
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
106
Figure 104 - Example of use cases owned by various packages
Presentation Options
A use case can also be shown using the standard rectangle notation for classifiers with an ellipse
icon in the upper-righthand corner of the rectangle with optional separate list compartments for
its features. This rendering is more suitable when there are a large number of extension points.
Figure 105 - Example of the classifier based notation for a use case
Presentation Options
A use case can also be shown using the standard rectangle notation for classifiers with an ellipse
icon in the upper-righthand corner of the rectangle with optional separate list compartments for
its features. This rendering is more suitable when there are a large number of extension points.
Rationale
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
107
The purpose of use cases is to identify the required functionality of a system.
4.4.5 Extend
A relationship from an extending use case to an extended use case that specifies how and when
the behavior defined in the extending use case can be inserted into the behavior defined in the
extended use case. Description
This relationship specifies that the behavior of a use case may be extended by the behavior of
another (usually
supplementary) use case.
Constraints
[1] The extension points referenced by the extend relationship must belong to the use case that
is being extended. extensionLocation->forAll (xp | extendedCase.extensionPoint->include(xp))
Semantics
If the condition of the extension is true at the time the first extension point is reached during the
execution of the extended use case, then all of the appropriate behavior fragments of the
extending use case will also be executed. If the condition is false, the extension does not occur.
The individual fragments are executed as the corresponding extension points of the extending
use case are reached. Once a given fragment is completed, execution continues with the behavior
of the extended use case following the extension point. Note that even though there are multiple
use cases involved, there is just a single behavior execution.
Notation
An extend relationship between use cases is shown by a dashed arrow with an open arrowhead
from the use case providing the extension to the base use case. The arrow is labeled with the
keyword «extend». The condition of the relationship as well as the references to the extension
points are optionally shown in a Note attached to the corresponding extend relationship.(See
Figure 106)
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
108
Examples
Figure 106 - Example of an extend relationship between use cases
In the use case diagram above, the use case ―Perform ATM Transaction‖ has an extension point
―Selection‖. This use case is extended via that extension point by the use case ―On-Line Help‖
whenever execution of the ―Perform ATM Transaction‖ use case occurrence is at the location
referenced by the ―Selection‖ extension point and the customer selects the HELP key. Note that
the ―Perform ATM Transaction‖ use case is defined independently of the ―On-Line Help‖ use case. Rationale
This relationship is intended to be used when there is some additional behavior that should be
added, possibly conditionally, to the behavior defined in another use case (which is meaningful
independently of the extending use case).
4.4.6 ExtensionPoint
An extension point identifies a point in the behavior of a use case where that behavior can be
extended by the behavior of some other (extending) use case, as specified by an extend
relationship. Description
An ExtensionPoint is a feature of a use case that identifies a point where the behavior of a use
case can be augmented with elements of another (extending) use case.
Constraints
[1] An ExtensionPoint must have a name.
self.name->notEmpty ()
Semantics
An extension point is a reference to a location within a use case at which parts of the behavior of
other use cases may be inserted. Each extension point has a unique name within a use case. Semantic Variation Points
The specific manner in which the location of an extension point is defined is left as a semantic
variation point. Notation
Extension points are indicated by a text string within in the Use Case oval symbol or use case
rectangle according to the syntax below:
<extension point> ::= <name> [: <explanation>]
4.4.7 Include
An include relationship defines that a use case contains the behavior defined in another use case. Description
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
109
Include is a directed relationship between two use cases, implying that the behavior of the
included use case is inserted into the behavior of the including use case. The including use case
may only depend on the result (value) of the included use case. This value is obtained as a result
of the execution of the included use case.
Note that the included use case is not optional, and is always required for the including use case
to execute correctly.
Semantics
An include relationship between two use cases means that the behavior defined in the including
use case is included in the behavior of the base use case. The include relationship is intended to
be used when there are common parts of the behavior of two or more use cases.
This common part is then extracted to a separate use case, to be included by all the base use
cases having this part in common. Since the primary use of the include relationship is for reuse of
common parts, what is left in a base use case is usually not complete in itself but dependent on
the included parts to be meaningful. This is reflected in the direction of the relationship,
indicating that the base use case depends on the addition but not vice versa.
Execution of the included use case is analogous to a subroutine call. All of the behavior of the
included use case are executed at a single location in the included use case before execution of
the including use case is resumed. Notation
An include relationship between use cases is shown by a dashed arrow with an open arrowhead
from the base use case to
the included use case. The arrow is labeled with the keyword «include». (See Figure 403.)
Examples
A use case ―Withdraw‖ includes an independently defined use case ―Card Identification‖.
Figure 107 - Example of the Include relationship
Rationale
The Include relationship allows hierarchical composition of use cases as well as reuse of use
cases.
4.4.8 Diagrams
Description
Use Case Diagrams are a specialization of Class Diagrams such that the classifiers shown are
restricted to being either Actors or Use Cases. Graphic Nodes
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
110
The graphic nodes that can be included in structural diagrams are shown in
Table 11.
Table 11 - Graphic nodes included in sequence diagrams
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
111
Table 12 - Graphic nodes included in sequence diagrams
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
112
Figure 108- Use Case diagram with a rectangle representing the boundary of the subject.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
113
The use case diagram in Figure 108 shows a set of use cases used by four actors of a physical
system that is the subject of those use cases. The subject can be optionally represented by a
rectangle as shown in this example.
Figure 109 illustrates a package that owns a set of use cases (NB: a use case may be owned
either by a package or by a Classifier (typically the classifier specifying the subject)).
Figure 109 - Use cases owned by a package
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
114
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
115
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
116
5.1 SIMULADOS
5.2 Exercícios Aula 2 – Class Diagrams
1. Which kind of behavior diagram is NOT a UML 2.0 diagram?
A. communication diagram
B. activity diagram
C. dataflow diagram
D. interaction diagram
E. sequence diagram
2. What do the initials UML stand for?
A. Unified Methodology Language
B. Unified Modeling Language
C. UML Modeling Language
D. Unified Method Language
E. Universal Modeling Language
3. What kind of structure diagram is NOT a UML 2.0 diagram?
A. component diagram
B. composite structure diagram
C. package diagram
D. entity diagram
E. class diagram
4. What does OMG stand for?
A. Object Modeling Group
B. Object Modeling Gang
C. Object Management Group
D. Other Modeling Group
E. Object Management Gang
5. What is the difference between the <<implementationClass>> and <<type>> stereotypes?
A. <<implementationClass>>and <<type>> only differ by programming language.
B. <<implementationClass>> and <<type>> are synonymous.
C. <<implementationClass>>contains objects and <<type>> contains values.
D. <<implementationClass>> define physical implementation and <<type>> does not.
6. Which kinds of diagram can be used to define an interaction in UML 2.0? (Choose three)
A. class diagram
B. sequence diagram
C. communication diagram
D. state machine diagram
E. composite structure diagram
F. interaction overview diagram
7. What is true of primitive types in UML 2.0? (Choose two)
A. specify all the necessary metaclasses
B. specify only those metaclasses needed for a particular model
C. are decomposable
D. are not decomposable
E. specify predefined data types without any relevant structure
8. What does it mean when a classifier rectangle is labeled as an <<enumeration>>?
A. The list of all public and private features is provided.
B. The classifier is a data type whose values are possibly listed in the bottom compartment.
C. The classifier is an iterator for traversing a collection.
D. The list of all public and private structural features is suppressed.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
117
9. What is true about a data type? (Choose two)
A. Its instances are mutable objects.
B. It can be diagrammed as a rectangle with the keyword dataType
C. Its instances are data values.
D. It is a classifier that must not be abstract.
E. It is the only kind of type that can be returned by an operation.
F. Its instances are identified by GUIDs.
10. What are metaclasses?
A. classes that have no supertypes
B. classes that are instances of classes
C. classes whose instances are objects
D. classes that are abstract
E. classes whose instances are classes
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
118
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
119
5.3 Gabarito Aula 2 – Class Diagrams
1. C
2. B
3. D
4. C
5. D
6. B,C,F
7. D,E
8. B
9. B,C
10. E
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
120
5.4 Exercícios Aula 3 - Class Diagrams
1. What is true about constraints in UML 2.0? (Choose two)
A. can be applied to themselves
B. cannot be named
C. must be true to be satisfied
D. can result in any number of possibilities
E. can be named
2. Constraints are shown using what symbols?
A. ( )
B. " "
C. { }
D. ?"
E. [ ]
3. What is true about a comment in UML 2.0? (Choose two)
A. is shown as a note symbol
B. connections are always shown with a dashed line
C. can be attached to more than one element
D. contains only machine-readable symbols
E. must be attached to at most one element
4. What is a relationship in UML 2.0?
A. an element that has no derived union
B. the state of being related
C. an element that must have two owned elements
D. an element that specifies a connection between elements
E. an element that has no derived composition
5. What is an element in UML 2.0?
A. instance of a class
B. abstract metaclass with only one superclass
C. constituent of a model
D. member of a set
E. substance not separable by ordinary chemical means
6. What is an expression in UML 2.0?
A. language-specific string used to describe the meaning of a diagram
B. graphical addition to a diagramming element
C. language-specific text string used to describe the contents of a diagram
D. symbol or symbols signifying a set of value
E. comment placed on a diagram
7. What is true of a classifier? (Choose three)
A. describes a set of instances that have features in common
B. can be part of a generalization hierarchy
C. namespace whose members can include features
D. cannot be part a generalization hierarchy
E. namespace whose members cannot include features
F. describes a set of instances that have no features in common
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
121
5.5 Gabarito Aula 3 – Class Diagrams
1. C,E
2. C
3. A,C
4. D
5. C
6. D
7. A,B,C
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
122
5.6 Exercícios Aula 4 – Class Diagrams
1. What does an association specify?
A. links between associated types
B. relationship among models
C. tuples that are not links
D. links between instances of untyped classes
E. links between instances of associated types
2. What does the diamond symbolize in the diagram?
A. three-way message sent to three classes
B. ternary association between instances of Team, Player, and Year
C. binary association between instances of Team, Player, and Year
D. decision point between three classes
E. aggregation of team and goalie objects for a particular season
3. What is the meaning of the line between Person and Order?
A. unary association linking instances of Person and Order
B. binary association linking instances of Person and Order
C. communication involving customer and order messages
D. communication involving Person and Order messages
E. ternary association linking instances of Person and Order
4. A property is a feature that can be represented in what ways? (Choose two)
A. as an association
B. as an attribute in a class
C. as an association end
D. as an indication of whether the feature is public or private
E. as an operation in a class
5. In the exhibit, what is the meaning of size in these two diagrams?
A. There is one size property diagrammed both as an attribute and as an association end.
B. There are two size properties that have no name conflict as long as each size is private.
C. The size attribute in the class indicates that it will be stored within the class and the end name
does not.
D. The size end name on the association indicates data storage and the attribute does not.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
123
E. Only one or the other should be used, not both, in order to avoid a name conflict.
6. What is true of the black diamond on the diagram? (Choose two)
A. A Line Item may only be included in more than one Order at a time.
B. If an Order is deleted, its Line Item instances are normally deleted.
C. A Line Item may only be included in one Order at a time.
D. A Line Item cannot be removed from its Order.
E. If an Order is deleted, its Line Item instances normally still remain.
7. What is indicated by the open diamond on the diagram? (Choose two)
A. A Boat includes an Engine as an aggregate part.
B. An Engine cannot be removed from its Boat.
C. While in a Boat, an Engine is not prevented from being part of something else at the same
time.
D. If a Boat is deleted, its Engine instances are normally deleted.
E. An Engine may be a composite part of more than one Boat at a time.
8. What is the meaning of the subsets constraint in the diagram?
A. The collection of b is a subset of the collection of d for each A.
B. D contains a subset of instances of C.
C. The collection of d is a subset of the collection of b for each C.
D. D is a subclass of B.
E. The collection of c is a subset of the collection of b for each D.
9. What does multiplicity in UML 2.0 signify?
A. interval of integers
B. range of allowable cardinalities
C. upper bound for the number of allowable instances
D. sequence and uniqueness of association
E. ability to multiply two or more numbers
10. Which multiplicity expressions are valid? (Choose three)
A. 1
B. -3..3
C. 0,,*
D. 1..0
E. 1..5
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
124
F. 3+5..7+1
11. What does an {ordered} designator do for a multiplicity?
A. specifies an inclusive interval of non-negative integers
B. specifies that values are sequentially ordered
C. indicates the correct sequence of messages in a sequence diagram
D. indicates that the upper bound must be greater than the lower bound for the multiplicity
12. In the exhibit, what is the meaning of the {unique} designator?
A. instances of Account are unique
B. each customer's account is not an account of another customer
C. each of the customer's accounts are distinct
D. only one account is associated with a customer
E. multiplicity cannot be multivalued
13. What is true of an operation's pos-conditions? (Choose two)
A. defines what conditions must be true while the operation is executing
B. may not be true if an exception is raised
C. defines what conditions must be true when the operation completes
D. must be true even if an exception is raised
E. defines what conditions must be true when the operation begins
14. What is true of an operation's body-conditions?
A. defines what conditions must be true while the operation is executing
B. may not be true if an exception is raised
C. defines what conditions must be true when the operation completes
D. must be true even if an exception is raised
E. defines what conditions must be true when the operation begins
15. What is true about every named element that is a member of a namespace?
A. It can be distinguished from other members in the namespace.
B. It is identified by its name within the namespace.
C. It is owned by the namespace.
D. It has one unique name within the namespace.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
125
5.7 Gabarito Aula 4 – Class Diagrams
1. E
2. B
3. B
4. B,C
5. A
6. B,C
7. A,C
8. C
9. B
10. A,E,F
11. B
12. C
13. B,C
14. A
15. A
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
126
5.9 Exercícios Aula 5 – Class Diagrams
1. What can be a classifier of an instance specification?
A. only a class
B. only a class that is not abstract
C. any classifier except for an association, unless it is an association class
D. any classifier except for an association
E. any classifier, including class, association, and data type
2. The instance diagram in the exhibit contains father and son without underlines. What is the
meaning of this?
A. An association having end names father and son.
B. A link of an association having end names father and son.
C. The diagram is a mixture of class and instance diagrams.
D. The names are incorrectly specified, because underlined names are required.
E. The Don class is a superclass of the Josh class.
3. What are some of the important semantics of packages? (Choose three)
A.The public contents of a package are accessible outside the package.
B. If a package is removed from a model, the owned contents are removed.
C. If a package is removed from a model, the owned contents are reassigned.
D. An element may be owned by at most one package.
E. The public contents of a package are not accessible outside the package.
F. A class may be owned by multiple packages.
4. What are the primary purposes of packages in UML 2.0? (Choose two)
A. to group modeling elements
B. to group classes
C. to provide a namespace
D. to avoid the constraints of a namespace
E. to group features for a class
5. What is true of the import example in the exhibit?
A. Auxiliary and Types are imported into ShoppingCart, but neither can be further imported into
WebShop.
B. Webshop is imported into ShoppingCart and then further imported into Auxiliary and Types.
C. Public members of Types and Auxiliary are imported into ShoppingCart and then further
imported into WebShop.
D. Public members of WebShop are imported into ShoppingCart and then further imported into
Auxiliary or Types.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
127
E. Public members of Types and Auxiliary are imported into ShoppingCart and those from Types
are further imported into WebShop.
6. What is the meaning of the import example in the exhibit?
A. Types package is imported by the Program package.
B. Program package is imported to the Time datatype.
C. Time and Integer datatypes are imported by the Program package.
D. Time datatype is imported by the Program package.
E. Program package is imported by the Types package.
7. What is the result of the merge transformations for R in the exhibit?
A. A
B. B
C. C
D. D
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
128
5.10 Gabarito Aula 5 – Class Diagrams
1. B,C
2. B
3. C,D
4. C
5. E
6. A
7. B,D
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
129
5.11 Exercícios Aula 6 – Class Diagrams
1. What statements are true about implementation relationships? (Choose two)
A. An interface may implement multiple classifiers.
B. The set of interfaces implemented by a classifier are its provided interfaces.
C. A classifier implementing an interface conforms to its contract.
D. The set of interfaces implemented by a classifier are its required interfaces.
E. A classifier may only implement one interface.
2. What statements are true about interfaces? (Choose two)
A. A classifier may realize only one interface, but an interface may be realized by multiple
classifiers.
B. A classifier may realize more than one interface, but an interface may be realized by only one
classifier.
C. Interfaces are not directly instantiable.
D. A classifier may realize more than one interface, and an interface may be realized by different
classifiers.
E. Interfaces are directly instantiable.
3. What is the notation for a required interface?
A. A
B. B
C. C
D. D
4. What is an interface?
A. a classifier that represents the implementation of a set of coherent public features and
obligations
B. a relationship that represents the declaration of a set of coherent public features and
obligations
C. a relationship that represents the implementation of a set of coherent public features and
obligations
D. a classifier that serves as a level of indirection between two other classifiers
E. a classifier that represents the declaration of a set of coherent public features and Obligations
5. What is the notation for a provided interface?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
130
A. A
B. B
C. C
D. D
6. What statements are true of the <<permit>> dependency in the exhibit? (Choose two)
A. X can access only the quux property of W.
B. X can access the baz and quux properties of W.
C. W can access the foo and bar properties of X.
D. W can access only the bar property of X.
E. X can access only the baz property of W.
F. W can access only the foo property of X.
7. What is the meaning of a <<realize>> dependency between two model elements?
A. a specialized abstraction relationship between two model elements, where the supplier
represents the specification and the client represents the implementation
B. a generalized abstraction relationship between two model elements, where the client
represents the specification and the supplier represents the implementation
C. a generalized usage relationship between two model elements, where the supplier represents
the using element and the client represents the element being used
D. a specialized permission relationship between two model elements, where the supplier
represents the element accessing and the client represents the element being accessed
E. a specialized usage relationship between two model elements, where the supplier represents
the using element and the client represents the element being used
8. What does the arrow end of a dependency relationship indicate?
A. element initiates communication
B. whole in a whole-part relationship
C. supplier element is unaffected by a change in the client element
D. more general classifier
E. client element is affected by a change in the supplier element
9. What statements are true about the <<substitute>> dependency? (Choose two)
A. implies neither inheritance of structure nor compliance to publicly available contracts
B. implies inheritance of structure and compliance to publicly available contracts
C. denotes runtime substitutability requiring specialization
D. denotes runtime substitutability not requiring specialization
E. does not imply inheritance of structure, but implies compliance to publicly available contracts
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
131
10. What do abstraction dependencies represent? (Choose two)
A. different levels of abstraction or different viewpoints
B. same level of abstract or different viewpoints
C. different concepts
D. same concept
E. same level of abstraction or the same viewpoint
11. What are true statements about dependencies? (Choose two)
A. Dependency relationships do not have runtime semantics implications.
B. Dependency relationships are intransitive.
C. A dependency implies the semantics of the client(s) are complete without the supplier(s).
D. A dependency implies the semantics of the client(s) are incomplete without the supplier(s).
E. Dependency relationships have runtime semantics implications.
12. In the exhibit, what are all of the classes required by A?
A. B, C, D, E, G
B. B, C, D
C. B
D. B, D
E. B, C, D, E, F, G
F. B, C
13. What does a <<use>> dependency mean in a relationship between one element and
another?
A. requires another element for its full implementation or operation
B. specifies how it uses another element
C. specifies how it realizes another element
D. specifies how one element implements another element
14. What is true about a <<permit>> dependency?
A. signifies granting of access rights from the client model element to the supplier model element
B. defines communication between two model elements
C. requires another element for its full implementation or operation
D. specifies how one element implements another element
E. signifies granting of access rights from the supplier model element to the client model element
15. Refer to the exhibit. Given that class A realizes interfaces X and Y, and that class B realizes
interface Y (Z) and uses interface Z (X), what operations must class A support?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
132
A. intersection of the operations in interfaces X and Y
B. union of the operations in interfaces X and Y
C. intersection of the operations in interfaces X, Y, and Z
D. union of the operations in interfaces X, Y, and Z
E. not required to support any operations specified by the interfaces shown
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
133
5.12 Gabarito Aula 6 – Class Diagrams
8. A
9. C
10. D,E
11. A,D
12. A,D
13. A
14. A
15. E
16. E
17. A,B,D
18. A,C
19. E
20. D
21. C
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
134
5.13 Exercícios Aula 7 – Activity Diagrams
CommonBehavior
1. What statement most accurately characterizes the purpose of the Common Behavior
package?
A. It defines the behaviors that are the same in all UML systems.
B. It defines different kinds of behavior types and event types.
C. It defines the core concepts that describe the dynamic semantics of UML.
D. It explains how objects communicate with each other.
2. Which statement is true of signals? (Choose two)
A. are handled in a manner determined by the sender
B. are handled in a manner determined by the stimulus
C. are handled in a manner determined by the receiver
D. are synchronous stimuli
E. are asynchronous stimuli
3. Which describes active classes?
A. classes whose instances may signal other objects
B. classes whose instances are actively executing one or more operations
C. classes that have state machines
D. classes whose instances have their own thread of control
E. classes whose instances are able to execute one or more operations
4. In UML, what is the behavior of an object caused by?
A. an operation
B. an event
C. a trigger
D. an event type
E. a call
5. What does the method associated with a behavioral feature specify?
A. the process by which the design of the behavioral feature is produced
B. the procedure that realizes the behavioral feature
C. an illustration of an execution of the behavioral feature
D. the realization of a behavioral feature
6. What are the components of diagram frames? (Choose three)
A. heading
B. content area
C. author designation
D. round-cornered frame
E. square-cornered frame
F. date
General Activity
7. Which elements in an activity diagram can be redefined by which other elements?
(Choose two)
A. nodes by nodes
B. edges by nodes
C. nodes by edges
D. edges by edges
E. states by states
F. transitions by transitions
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
135
8. What does an activity contain? (Choose two)
A. messages
B. classes
C. edges
D. lifelines
E. nodes
F. states
9. If a well-defined activity has a parameter node with an incoming arrow and also contains a
final node, which of these will always have values when the activity finishes?
A. parameter node
B. final node
C. exactly one
D. one or both
E. both
10. An activity is what kind of element?
A. state machine
B. behavior
C. collaboration
D. method
E. action
ActivityNodeExecutableNode
11. What does the symbol in the exhibit represent inside UML 2.0 activity diagrams?
A. behavior
B. state
C. action
D. activity
E. object node
12. How many of the three outgoing arrows from a round-cornered, solid-line rectangle (as
depicted in the exhibit) will provide values at one time when the round-cornered rectangle
finishes?
A. one
B. three
C. none
D. two
ActivityNode ParameterSet
13. What does the symbol in the exhibit represent in UML 2.0 activity diagrams?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
136
A. control node
B. behavior
C. state
D. object node
E. activity
F. action
ActivityNode ObjectNode Parameter
14. How many arrows can go out of an input parameter node?
A. any number
B. one
C. two
D. none
15. What does a rectangle on the border of an activity diagram (as depicted in the exhibit)
represent in UML 2.0 activity diagrams?
A. port
B. parameter node
C. pin
D. entry state
E. place
ActivityNode ObjectNode Pin
16. What does the symbol in the exhibit represent inside UML 2.0 activity diagrams?
A. parameter node
B. port
C. pin
D. entry state
E. place
17. What are two kinds of pins in activity diagrams?
A. entry and exit
B. input and output
C. in and out
D. read and update
18. How many of the arrows in the exhibit must provide values before the round-cornered
rectangle can start?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
137
A. one
B. two
C. three
D. none
19. How many of the arrows in the exhibit will be given values when the round-cornered
rectangle finishes executing?
A. one
B. three
C. none
D. two
20. If the rectangle in the exhibit has one value, how many of the arrows will be given the value?
A. three
B. none
C. two
D. one
ActivityEdge
21. What do arrows in activity diagrams represent? (Choose two)
A. message passing
B. unidirectional associations
C. state transitions
D. object flows
E. dependencies
F. control flows
22. What do arrowed lines connecting to and from a rectangle (as depicted in the exhibit)
represent in UML 2.0 activity diagrams?
A. control flows
B. state transitions
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
138
C. object flows
D. dependencies
E. message passing
F. unidirectional associations
23. An arrowed line connecting small rectangles attached to round-cornered, solid-line rectangles
is depicted in the exhibit. What does the arrowed line represent in UML 2.0 activity
diagrams?
A. dependency
B. object flow
C. message passing
D. control flow
E. unidirectional association
F. state transition
ActivityNode
24. What do shapes in activity diagrams with no labels inside represent?
A. control nodes
B. activities
C. states
D. actions
E. behaviors
F. object nodes
ActivityNode ControlNode
25. How many diamond shapes can appear in a well-defined activity diagram?
A. any number
B. an even number
C. exactly two
D. an odd number
26. What does a solid circle (as depicted in the exhibit) represent in UML 2.0 activity diagrams?
A. joins
B. decisions
C. forks
D. activity final nodes
E. initial nodes
F. merges
G. flow final nodes
27. How many of the three arrows outgoing from the solid circle (as depicted in the exhibit) will
be given values during the execution of a well-defined activity diagram?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
139
A. one
B. three
C. two
D. none
28. What does a circle with a solid circle inside (as depicted in the exhibit) represent in UML 2.0
activity diagrams?
A. forks
B. initial nodes
C. merges
D. flow final nodes
E. decisions
F. joins
G. activity final nodes
29. A circle with a solid circle inside and three incoming arrows is depicted in the exhibit. How
many of the arrows must provide values for the circle to have an effect?
A. none
B. one
C. two
D. three
30. What does a diamond shape (as depicted in the exhibit) represent in UML 2.0 activity
diagrams? (Choose two)
A. joins
B. activity final nodes
C. decisions
D. forks
E. merges
F. flow final nodes
G. initial nodes
31. How many of the three arrows outgoing from the diamond shape (as depicted in the exhibit)
will be given values at one time in a well-defined activity diagram?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
140
A. none
B. three
C. one
D. two
32. How many of the three incoming arrows to the diamond shape (as depicted in the exhibit)
must provide values for the diamond to have an effect?
A. one
B. two
C. three
D. none
33. What receives output values of a behavior on a decision node?
A. guards
B. input pins
C. actions
D. input parameter nodes
E. entry states
34. What provides input values to a behavior on a decision node?
A. actions
B. output parameter nodes
C. output pins
D. exit states
E. object flows
35. Which will cause an activity to finish executing? (Choose two)
A. Output parameter nodes all have values.
B. All guards fail.
C. No tokens (values) are in the activity.
D. Activity final is reached.
E. No actions are executing.
36. What punctuation denotes the criteria for values flowing along arrows outgoing from a
decision node?
A. note symbol
B. braces: { }
C. brackets: [ ]
D. parentheses: ( )
37. What do arrows in activity diagrams represent? (Choose two)
A. message passing
B. unidirectional associations
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
141
C. state transitions
D. object flows
E. dependencies
F. control flows
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
142
5.14 Gabarito Aula 7 – Activity Diagrams
1. C
2. C,E
3. D
4. B
5. D
6. A,B,E
7. A,D
8. C,E
9. A
10. B
11. C
12. B
13. D
14. A
15. B
16. C
17. B
18. C
19. B
20. D
21. D,F
22. C
23. B
24. A
25. A
26. E
27. A
28. G
29. B
30. C,E
31. C
32. A
33. A
34. E
35. C,D
36. C
37. D,F
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
143
5.15 Exercícios Aula 8 - Sequence Diagrams
1. What constraint applies to a stop in a UML interaction diagram?
A. No other event occurrences may appear below a stop on a given lifeline in a simple interaction.
B. If there is a stop on one lifeline, there should be stops on all other lifelines within an
interaction.
C. Only one stop may occur in one interaction.
D. If one lifeline has a stop in one interaction, it should have stops in every interaction that it
appears.
2. Which element in the exhibit denote a lifeline?
A. b:C2
B. C1
C. q
D. p
E. M
3. What is a selector of a lifeline?
A. a specific lifeline that selects a resource from a resource pool
B. a scheduler that chooses the next lifeline on which to run
C. an expression selecting one out of a set; a general indexing mechanism
D. a construct to select one lifeline out of all the lifelines in the diagram
4. What about event order is true for simple interactions? (Choose two)
A. Events are ordered from top to bottom of a lifeline in a simple sequence diagram.
B. Events are ordered from top to bottom in a sequence diagram.
C. The start event of an execution occurrence will coincide in time with the event representing
the call of that operation.
D. The send event of a complete message comes before the receive event of the same message.
E. When messages represent operation calls, their sending and receiving events coincide in time.
5. There is an element identified as r in the exhibit. What does this element describe in a UML
2.0 interaction diagram?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
144
A. found message, found by b
B. lost message originating from b
C. timing signal from b
D. synchronous message to the environment of R
E. asynchronous message to the environment of R
6. In the exhibit, where is the execution occurrence in the sequence diagram named R?
A. message with identifier v (dashed line)
B. lifeline a
C. at the arrowhead of the dashed message on lifeline a
D. lifeline b in thin vertical rectangle
E. message denoted by r
F. lifeline b
7. In the exhibit, what is a lifeline?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
145
A. A
B. B
C. C
D. D
8. In the exhibit, what is an interaction?
A. A
B. B
C. C
D. D
9. In a UML 2.0 interaction diagram, what can be accomplished with a general ordering?
A. order any two events within one interaction
B. order the events within a lifeline more flexibly than merely downwards
C. order message arguments differently from the order of the corresponding parameters
D. order interactions in hierarchies of inheritance
10. What is true about lifelines?
A. has traces of events following the sequence of messages
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
146
B. in a sequence diagram, are horizontal or with a slight downward slope
C. represent a sequence of operation calls
D. represent an individual participant in the interaction
11. In the exhibit, there is one element with the identifier b. What is true about this element?
A. b is a class.
B. b is of the type C2.
C. b is contained in class C2.
D. b must be a property of a composite structure.
E. b is defined local to M.
12. A found message in a UML interaction diagram is a message with what characteristic?
A. the sending event is not present
B. chosen by the modeler to consider in this diagram
C. has no corresponding execution occurrence
D. the receiving event is not present
13. Which element in the diagram is the correct label for a lifeline?
A. C2
B. p
C. b
D. M
E. a:C1
14. What is a trace?
A. arrowed line representation
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
147
B. message line
C. set of message lines
D. sequence of event occurrences
15. What is the purpose of general ordering in a UML 2.0 interaction diagram?
A. principle of how to order the lifelines within a sequence diagram
B. mechanism to provide partial ordering of event occurrences
C. construct showing the order of messages in a communication diagram
D. construct to define the generalization relationship between different interactions
16. Which keyword denotes a lifeline that represents the object owning the lifeline?
A. object
B. own
C. ncloser?
D. this
E. self
17. In a sequence diagram, what does a stop symbol express?
A. The behavior of a lifeline halts within this diagram.
B. The object represented by a lifeline terminates.
C. A message is stopped short of its reception.
D. The interaction is no longer valid.
18. Let us denote sending of p as !p and receiving p as ?p. Which trace defines the interaction N2
in the exhibit?
A. <!p, !r, ?r, !q, ?q, ?p>
B. <!p, ?p, !r, ?r, !q, ?q>
C. <?r, !p, !r, ?q, !q, ?p>
D. <!r, ?r, !q, !p, ?p, ?q>
E. <!p, !r, !q, ?r, ?q, ?p>
19. Let us denote sending of p as !p and receiving p as ?p. In the exhibit, what is correct about
event occurrences of the interaction Q?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
148
A. !r will precede !q
B. ?q may precede ?r
C. ?p will precede !r
D. !p will precede !q
20. What ordering statement is correct about event occurrences of the interaction Q2 in the
exhibit? Denote sending of p as !p and receiving p as ?p.
A. ?r will precede ?p
B. !p will precede !q
C. ?q may precede !r
D. ?p will precede !r
21. Let us denote sending of p as !p and receiving p as ?p. Which trace defines the interaction N
in the exhibit?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
149
A. <!q, !p, ?p, ?q>
B. <!p, ?p, !q, ?q>
C. <!p, !q, ?q, ?p>
D. <!p, ?q, !q, ?p>
22. Let us denote sending of p as !p and receiving p as ?p. Which traces define the interaction M
in the exhibit? (Choose two)
A. <?p, !p, ?q, !q>
B. <!p, !q, ?p, ?q>
C. <!q, !p, ?p, ?q>
D. <!p, ?q, !q, ?p>
E. <!p, ?p, !q, ?q>
23. Let us denote sending of p as !p and receiving p as ?p. Which traces define the interaction M2
in the exhibit? (Choose three)
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
150
A. <!p, ?p, !q, ?q>
B. <!p, ?q, !q, ?p>
C. <!q, !p, ?p, ?q>
D. <!q, !p, ?q, ?p>
E. <?p, !p, ?q, !q>
F. <!p, !q, ?p, ?q>
24. What is true of an interaction?
A. An interaction always contains states and transitions.
B. An interaction can be used as types for ports.
C. An interaction is defined by a use case.
D. The semantics of an interaction are defined by event traces.
25. Which arrowhead shows that the message represents an operation call, rather than a signal,
in UML 2.0?
A. A
B. B
C. C
D. D
26. What is true concerning the UML model depicted in the exhibit?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
151
A. The communication diagram on the left forms the base for the sequence diagram on the right.
B. M is not a behavior of C since p and q are not defined within C.
C. If M is a behavior in C, then a in C is the property represented by lifeline a in M.
D. a and b are lifelines within C, as well as being the same entities as those referenced in M.
27. What does the execution occurrence in the exhibit convey?
A. the return of the reply from having performed the operation v
B. the execution of the behavior associated with the operation v on b
C. that the operation v is called
D. the sending of r
Answer: B
28. Which arrowhead shows that a message represents an asynchronous signal?
A. A
B. B
C. C
D. D
Answer: B
29. When a message corresponds to an operation call, what is true about the arguments in UML
2.0?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
152
A. All the parameters of the operation must be matched by message arguments.
B. A message argument should be of exactly the same type as the parameters of the
corresponding operation.
C. Message arguments must always be constants or attributes of the sender.
D. The message arguments must the same type as the parameters of the corresponding
operation or a subset of the parameters of the corresponding operation.
Answer: D
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
153
5.16 Gabarito Aula 8 - Sequence Diagrams
1. A
2. A
3. C
4. A,D
5. E
6. D
7. B
8. A
9. A
10. D
11. B
12. A
13. E
14. D
15. B
16. E
17. B
18. A
19. D
20. B
21. C
22. B,E
23. A,C,F
24. D
25. A
26. C
27. B
28. B
29. D
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
154
5.17 Exercícios Aula 9 – Use Case Diagrams
1. What is specified by a use case?
A. possible path based on a value
B. required usage of the system
C. business justification for system development
D. set of user interface screens
2. What can be captured by use cases? (Choose two)
A. data and control flow of the system
B. user-interface specification of the system
C. behaviors offered by the system
D. requirements of the system
E. changes in state over time of the system
3. What notation may be added to the line connecting a use case with an actor to indicate that
the actor can participate in several instances of the use case at the same time?
A. near the use case oval*
B. near the actor <<many>>
C. near the actor {many}
D. near the use case oval{*}
E. near the actor 0..*
4. What shapes are NOT likely to be found on a typical use case diagram? (Choose two)
A. rounded-cornered rectangles
B. square-cornered rectangles
C. ovals
D. straight lines
E. stick figures
F. diamonds
5. What would NOT make a good subject for use cases? (Choose two)
A. actor
B. component
C. class
D. subsystem
E. system
F. model
6. What shapes normally represent a use case? (Choose three)
A. A
B. B
C. C
D. D
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
155
E. E
F. F
7. In the exhibit, which relationship may have extension points attached to it?
A. between Use Case B and Actor Y
B. between Use Case E and Actor Z
C. between Use Case A and Use Case D
D. between Use Case C and Use Case A
E. between Use Case A and Actor X
8. In the exhibit, which relationship may have a condition attached to it?
A. between Actor X and Use Case B
B. between Use Case A and Use Case B
C. between Use Case A and Use Case D
D. between Use Case A and Use Case C
E. between Use Case D and Use Case E
9. In the exhibit, which use case does NOT need to be available to meet the goals of an
actor using Use Case D?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
156
A. Use Case B
B. Use Case E
C. Use Case D
D. Use Case A
E. Use Case C
10. In the exhibit, when Actor X initiates Use Case A, how many other actors must be involved?
A. 3
B. 1
C. 2
D. 0
11. In the exhibit, which actors are involved in Use Case E?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
157
A. Actor X and Actor Z
B. Actor Y and Actor Z
C. Actor Z
D. Actor X, Actor Y, and Actor Z
12. In the exhibit, when Actor X initiates Use Case A, how many other actors can be involved?
A. 3
B. 0
C. 2
D. 1
13. In the exhibit, if there are no other use case diagrams for this system, which use cases may
be abstract?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
158
A. Use Case A
B. Use Case B
C. Use Case D
D. Use Case C
E. Use Case E
14. In the exhibit, which use cases must be available to meet the goals of Actor X when it
initiates Use Case A? (Choose 2)
A. Use Case B
B. Use Case C
C. Use Case E
D. Use Case D
E. Use Case A
15. In the exhibit, which use case needs to have at least one extension point defined?
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
159
A. Use Case D
B. Use Case A
C. Use Case C
D. Use Case B
E. Use Case E
16. In the exhibit, which best describes the relationship between the two use cases: Use Case A
and Use Case B?
A. Use Case A extends Use Case B.
B. Use Case B extends Use Case A.
C. Use Case A includes Use Case B.
D. Use Case B generalizes Use Case A.
E. Use Case A generalizes Use Case B.
F. Use Case B includes Use Case A.
17. In the exhibit, which best describes the relationship between the two use cases: Use Case A
and Use Case B?
A. Use Case B extends Use Case A.
B. Use Case B generalizes Use Case A.
C. Use Case A extends Use Case B.
D. Use Case B includes Use Case A.
E. Use Case A includes Use Case B.
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
160
F. Use Case A generalizes Use Case B.
18. In the exhibit, which best describes the relationship between the two use cases: Use Case A
and Use Case B?
A. Use Case A includes Use Case B.
B. Use Case A extends Use Case B.
C. Use Case B generalizes Use Case A.
D. Use Case A generalizes Use Case B.
E. Use Case B extends Use Case A.
F. Use Case B includes Use Case A.
19. What are the possible relationships among use cases in UML 2.0? (Choose two)
A. <<extends>>
B. <<extend>>
C. <<includes>>
D. <<generalizes>>
E. <<include>>
F. <<uses>>
20. In the exhibit, to which may it be attached?
A. the actor who initiated an extension use case
B. the association from an extension use case to its target
C. the association from an extension use case to its included use cases
D. the use case that has extension points
E. the subject that owns the extension
21. Zev works as the librarian at the local library. He can also borrow books as an ordinary
library patron. How many actors are needed when modeling people like Zev in a use case
diagram?
A. 2 unconnected actors
B. 2 actors connected by a generalization
C. 1 actor
D. 1 actor and 1 external system
22. When a customer uses a service to order books, the service contacts a commercial credit
card validation service, an address verification service, and an internal client database.
Assuming the Order Books process is modeled as one use case at the system level, which actors
would there be?
A. Customer, Client Database
B. Customer, Credit Card Validation Service, Address Verification Service, Client
Database
C. Customer, Credit Card Validation Service
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
161
D. Customer
E. Customer, Credit Card Validation Service, Address Verification Service
23. Ten employees in a department can submit an expense form to have their expenses repaid.
The manager is required to approve the expense forms. How many actors have we
described?
A. 2 actors
B. 10 actors
C. 0 actors
D. 12 actors
E. 1 actor
F. 11 actors
24. What term describes a customer ordering books via the web?
A. external system
B. subject
C. client
D. user-case
E. user
F. actor
25. What is a good candidate for modeling a customer-initiated use case at an automated teller
machine (ATM)?
A. enter PIN
B. select account
C. cash management
D. withdraw cash
26. The name of a state is one possible way of defining which feature?
A. exception logic
B. extension point
C. encapsulated areas of change
D. include condition
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
162
5.18 Gabarito Aula 9 – Use Case Diagrams
1. B
2. C,D
3. A
4. A,F
5. A,F
6. A,D,E
7. D
8. D
9. E
10. B
11. A
12. C
13. A
14. A,E
15. B
16. E
17. A
18. A
19. B,E
20. B
21. A
22. E
23. A
24. F
25. D
26. B
Versão 3.0
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 Lucélia Viera Mota
163