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


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


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.13 Exercícios Aula 7 – Activity Diagrams .............................................................. 134

5.14 Gabarito Aula 7 – Activity Diagrams ................................................................ 142

Versão 3.2


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


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


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


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.

http://www.omg.org/

Versão 3.0


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


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;

http://www.omg.org/uml-certification/

Versão 3.0


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


28

3.2.4 Features Diagram

3.2.4.1 Feature

A feature declares a behavioral or structural characteristic of instances of classifiers.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


65

Abstraction Permission <<permit>>

Versão 3.0


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


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


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


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


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


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».


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


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


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


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


75

4.2.3 Class Diagrams (BasicActivities)

Figure 66 – Node

Figure 67 - Control nodes

Versão 3.0


76

Figure 68 - Control nodes (IntermediateActivities)

Figure 69 - Flows

Versão 3.0


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


78

Figure 71 - Activity notation

Versão 3.0


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


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


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


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


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


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


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


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


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


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


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


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


90

Table 6 - Graphic nodes included in activity diagrams

Versão 3.0


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


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


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


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


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


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


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


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


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


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


101

Figure 100 - Elements Iteraction Diagram

Versão 3.0


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


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


104

An actor is represented by ―stick man‖ icon with the name of the actor in the vicinity (usually

above or below) the icon.


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


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


106

Figure 104 - Example of use cases owned by various packages


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


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


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


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


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


110

The graphic nodes that can be included in structural diagrams are shown in

Table 11.


Versão 3.0


111


Versão 3.0


112

Figure 108- Use Case diagram with a rectangle representing the boundary of the subject.

Versão 3.0


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


114

Versão 3.0


115

Versão 3.0


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


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


118

Versão 3.0


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


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


121


1. C,E

2. C

3. A,C

4. D

5. C

6. D

7. A,B,C

Versão 3.0


122


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


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


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


125


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


126


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


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


128


1. B,C

2. B

3. C,D

4. C

5. E

6. A

7. B,D

Versão 3.0


129


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


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


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


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


133


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


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


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


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


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


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


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


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


141

C. state transitions

D. object flows

E. dependencies

F. control flows

Versão 3.0


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


160

F. Use Case A generalizes Use Case B.


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


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


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


163

Documents

Apostila UML 2.0 Versao 3.2