aula03

Prévia do material em texto

3ºAula
Diagramas UML – parte 1
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
Olá, pessoal,
Como estão indo seus estudos? Esperamos que você tenha 
gostado das duas primeiras aulas. Nas duas próximas aulas, vamos 
apresentar a você a Unified Modeling Language, a popular UML, 
que consiste em apresentar padrões de diagramas para Análise 
Orientada a Objetos. Nosso estudo de UML se dividirá em duas 
aulas. Na primeira aula, você vai aprender a história da UML e os 
diagramas mais usados desse padrão.
Se você tiver qualquer dúvida, entre em contato via quadro 
de avisos, certo? A sua participação é muito importante para nós.
Bons estudos!
161
18Met. para de Desenvolvimento de Software
Seções de estudo
1 - Introdução à Unified Modeling 
Language – UML
1 – Introdução à Unified Modeling Language – UML
2 – Diagrama de Classes
3 – Diagrama de Casos de Uso
4 – Diagrama de Atividades
A Unified Modeling Language (ou em Português: Linguagem 
de Modelagem Unificada), é uma sintaxe geral para criar 
um modelo lógico de um sistema. Para os autores, Booch, 
Rumbaugh e Jacobson, a UML é uma linguagem destinada a 
visualizar, especificar, construir e documentar os artefatos de 
um sistema complexo de software.
A UML foi criada por James Rumbaugh, Grady Booch e 
Ivar Jacobson, durante o tempo em que trabalhavam na Rational 
Corporation, a criadora da Rational Unified Process – RUP. A UML 
teve como base a fusão das metodologias que os próprios 
autores haviam criado anteriormente: Método de Booch, a 
Engenharia de Software Orientada a Objetos (OOSE, criado 
por Jacobson), e a Técnica de Modelagem de Objetos (OMT, 
de Rumbaugh). Isso é comentado pelos próprios autores em 
seu livro “UML: Guia do Usuário” (2012):
Como principais autores dos métodos Booch, 
OOSE e OMT, nos sentimos motivados a 
por três motivos. Primeiro, nossos métodos 
já estavam evoluindo um em direção ao 
outro de maneira independente. Fazia sentido 
continuar essa evolução em conjunto e não 
separadamente, eliminando a possibilidade 
de diferenças casuais e desnecessárias que 
apenas confundiriam os usuários. Segundo, 
estabilidade ao mercado orientado a objetos, 
permitindo que os projetos tivessem como 
base uma linguagem madura de modelagem 
e que os produtores de ferramentas 
fornecessem recursos mais úteis. Terceiro, 
esperávamos que nossa colaboração 
proporcionasse aprimoramentos para os três 
métodos anteriores, auxiliando-nos a captar 
as lições aprendidas e a lidar com problemas 
que nenhum de nossos métodos conseguira 
manipular de maneira adequada até então. 
A primeira versão da UML foi a 0.8, criada em outubro 
de 1995. Daí em diante, a linguagem passou a receber 
contribuições de diversos especialistas e pesquisadores. Em 
1997, a Object Management Group – entidade que reúne empresas, 
agências do governo, usuários e instituições de ensino para 
definir padrões de tecnologia – acatou a UML como padrão, 
e passou a fazer o trabalho de revisão e manutenção da UML. 
Em 2005, foi lançada a UML 2.0.
Segundo Lee e Tepfenhart, a UML tem como objetivos:
A UML é uma linguagem composta de itens, 
relacionamentos entre esses itens e diagramas que 
abrigam esses itens e seus respectivos relacionamentos. 
Nas duas próximas aulas, vamos abordar esses diagramas e os 
itens que podem conter nesses diagramas, como determina a 
especificação UML.
Mas, antes aprendermos esses diagramas, vamos saber 
do estudo de caso da Locadora LocaPlus, que vai servir de 
contexto para todos os diagramas que apresentaremos aqui nas 
duas próximas aulas.
Você foi contratado pela locadora de veículos LocaPlus para construir 
um sistema que gerenciasse as locações da empresa. Assim, você fez 
a etapa de elicitação de requisitos, e extraiu os seguintes requisitos 
RG, seu nome, seu endereço, seu CPF e seu número de dependentes;
o nome, a marca, o modelo, o valor do seguro, o valor da locação e a 
sua cor. Sendo que o valor da locação do carro pode ser atualizado a 
qualquer momento.
pode ainda ser admitido ou demitido, para isso são registradas suas 
datas de admissão - contratação - e demissão.
de veículos. No momento da locação, a locadora registra o número do 
cliente e a placa do carro, além de atribuir a data da locação para o dia 
atual. No ato da devolução, o funcionário registra a data de devolução e 
a quilometragem percorrida, para que seja informada o preço a pagar 
pela locação.
o funcionário na condição de supervisor é o único que tem a permissão 
de registrar e demitir funcionários - além de pode fazer o que um 
funcionário comum pode fazer.
demissão;
cor.
162
19
O primeiro diagrama que veremos é o Diagrama de 
Classes, que trataremos a seguir:
2 - Diagrama de Classes
De longe, o Diagrama de Classes é um dos mais utilizados 
da UML. Ele define as classes que estarão no sistema, 
além da estrutura dos dados (atributos) e serviços 
(métodos) de cada classe, e dos seus relacionamentos 
entre essas classes que estão nesse sistema. É uma 
evolução do diagrama de Entidade-Relacionamento, que você 
viu na primeira aula.
Um diagrama de classes contém os seguintes elementos:
2.1 - Classes
Como você viu, uma classe é um conjunto de objetos 
que possuem características semelhantes. A UML define a 
representação de uma classe como um retângulo dividido 
em três partes, como é apresentado na figura abaixo:
No primeiro retângulo, temos o nome da classe. Esse 
nome deve ser iniciado com letra maiúscula, escrito no singular, 
negrito e centralizado. Adicionalmente, podemos colocar a 
versão da classe (ex. {versão 1.0}), o autor dessa classe (ex. 
{autor = Fulano de Tal}), e estereótipos, que explicaremos a 
seguir:
Na UML, 
. É aplicado a 
diversos itens, como veremos nas próximas aulas. É precedido por dois 
Além disso, podemos definir através do nome da classe 
se uma classe é abstrata ou não. Uma classe é denominada 
abstrata se ela não pode ser instanciada, ou seja, não se pode 
criar objetos a partir dessa classe. Para definirmos que uma 
classe é abstrata, devemos indicar colocando o nome da classe 
em itálico.
No segundo retângulo, colocamos os atributos da 
classe, que são indicados em formato de uma lista, onde cada 
linha é um atributo. Cada linha respeita a seguinte sintaxe:
<visibilidade> <nome do atributo>:<tipo> 
[<multiplicidade>]:<valor padrão>
No início de cada linha, é indicada a visibilidade desse 
atributo, como indicado nesta tabela:
e métodos. 
. é um dos conceitos que 
sustentam a característica do encapsulamento, muito importante na 
Orientação a Objetos.
acessado por qualquer classe;
ou seja, só pode ser acessível ou dentro da classe ou por classes que 
descendem dessa classe, ou seja, aqueles que herdam essa classe;
só pode ser acessado exclusivamente pela própria classe;
é do tipo pacote, marcando esse elemento como acessível por 
qualquer outra classe que esteja dentro do mesmo pacote em que 
essa classe está inserida. Nem todas as linguagens orientadas a objeto 
implementam isso.
Não existe na UML valor padrão para a visibilidade. Assim, não declarar 
a visibilidade não indicará absolutamente nada. Mas vale lembrar que 
existem várias linguagens de programação orientadas a objeto que 
exigem explicitamente que a visibilidade do elemento seja declarada.
Após a identificação da visibilidade, devemos colocar o 
nome do atributo - separado por um espaço. Esse nome deve 
iniciar-se com uma letra minúscula. Recomenda-se que em 
casos de nomes compostos, seja seguido o padrão camelCase, 
que consiste em colocar a primeira letra de cada nova palavra 
como letra maiúscula. Por exemplo: nomeDoDependente.
Ao lado do nome, colocamos um sinal de dois-pontos (:) 
e o tipo que será esse atributo. A UML define quatro tipos de 
dados primitivos, que são:
Boolean
String
Integer
UnlimitedNatural - representa números naturais.
Mesmo que a UML defina tipos padrões, nada impede 
que o programador use os tipos que estejam disponíveis na 
linguagem de programação escolhida para implementaro 
programa ou no sistema gerenciador de banco de dados 
que foi escolhido para armazenar os dados. Opcionalmente, 
podemos definir, entre colchetes, a multiplicidade do atributo, 
que determina o número mínimo e o número máximo de 
valores que um atributo pode conter. Ele segue a notação: 
[<Número mínimo>..<Número Máximo>]. Vejamos alguns 
exemplos:
máximo um valor. Esse é o valor que é deduzido se não for 
valor e no máximo vários valores.
163
20Met. para de Desenvolvimento de Software
Também de forma opcional, podemos definir um valor 
padrão para esse atributo. Vejamos alguns exemplos de 
atributos:
protegido de nome emailCliente, do tipo String, que para cada 
objeto, pode ter no mínimo nenhum valor associado a esse 
nome saldo, do tipo Float, cujo valor padrão é zero.
Nota: Wilson Moraes Góes (2014) afirma que não é 
necessário colocar chaves ou identificadores para diferenciar 
um objeto a outro. No modelo de classes, isso é implícito, pois 
as chaves são criadas em função das limitações dos programas 
existentes.
Por fim, no último retângulo, colocamos uma lista 
de métodos que estarão na classe. Essa lista é composta 
por linhas, onde em cada linha, definimos a sua visibilidade 
(da mesma forma que nos atributos) e o nome do método, 
seguido por um abre e fecha parênteses - “()”. Podemos ainda 
detalhar os parâmetros desse método, dentro dos parênteses, 
e o tipo do retorno do método. Porém, isso não é obrigatório, 
pois pode alongar demasiadamente o diagrama, devido à 
quantidade de parâmetros a serem colocados.
A figura que mostraremos a seguir é um exemplo de 
classe, segundo a notação UML.
2.2 - Associação entre as classes
Indica que os objetos das classes envolvidas se 
relacionam. Podem envolver objetos de classes diferentes ou 
da mesma classe - nesse caso, se chama associação reflexiva. 
É representada por meio de uma linha reta ligando as classes 
envolvidas no relacionamento.
Além dessa linha reta, informações adicionais a essa 
relação podem ser incluídas, como:
Nome (opcional)
Indica alguma informação em relação a essa associação. 
Normalmente é um verbo que expressa à ação entre os dois 
objetos. Junto a esse nome, é colocada uma seta que indica 
a direção em que esse nome deve ser lido. No diagrama 
que mostraremos a seguir, temos uma relação entre as 
classes Paciente e Remédio. Sabemos que um paciente toma 
medicamentos para tratar ou prevenir diversas doenças. 
Assim, podemos dizer que um paciente toma um ou vários 
remédios. Podemos representar isso na UML, através desse 
diagrama:
Navegabilidade (opcional)
Indica como será o sentido de acesso aos dados entre os 
participantes da relação. Assim, podemos definir se uma classe 
pode acessar a outra classe ou não. É indicada por meio de setas 
e xis na linha que liga as classes, mas isso não é obrigatório. 
Para sabermos como representar isso, vejamos esses diagramas 
abaixo:
Através dos diagramas representados acima, podemos 
deduzir que:
nenhum outro indicador. Isso afirma que a navegabilidade não 
está especificada.
extremidade do sentido entre K3 para K4. Isso significa que 
os objetos de K3 podem ter referências de K4. No sentido 
inverso, a navegabilidade não está especificada.
da reta entre K5 para K6. Isso significa que os objetos de K5 
podem acessar objetos de K6. Mas a diferença fica pelo fato 
que há um X no final do sentido de K6 a K5, indicando que 
os objetos de K6 não podem conter referências a K5, isso se 
chama navegabilidade excluída.
da associação, isso significa que a navegabilidade é bidirecional, 
onde uma classe pode ter referências a outra classe e vice-versa.
Multiplicidade
Indica quantos objetos podem estar envolvidos nesse 
relacionamento. É representada por dois números, separados 
por dois sinais de ponto final entre eles. O primeiro número 
indica o número de objetos mínimo que podem estar 
envolvidos nessa relação e o segundo número indica o número 
máximo de objetos que podem estar envolvidos nessa classe. 
Esses dois números ficam nas extremidades da reta.
Para ler uma multiplicidade, devemos começar da classe a 
ter a quantidade de objetos que pode e, depois, ler o número 
164
21
que está na extremidade oposta dessa classe. Assim, para este 
diagrama:
Podemos ler que um objeto da classe X pode ter no 
mínimo A objetos da classe Y e no máximo B objetos da classe 
Y. E um objeto da classe Y pode ter no mínimo N objetos da 
classe X e no máximo M objetos da classe X.
Normalmente, uma multiplicidade que pode ser entendida 
como cardinalidade pode ser expressa de cinco formas:
relacionar com no mínimo zero e no máximo um objeto da 
relacionar com no mínimo e no máximo um objeto. Esse é o 
valor que é deduzido se não for informada a multiplicidade do 
relacionar com um objeto da outra classe e pode se relacionar 
com muitos objetos.
Além disso, uma associação pode ter uma classe 
atrelada a essa relação, chamada de classe associativa. É 
comum em relações a multiplicidade muitos para muitos, que 
normalmente possui atributos que sejam inerentes à relação, 
não pertencendo a nenhuma das classes participantes. Essa 
classe pode se relacionar com qualquer outra classe do sistema, 
independentemente se participa ou não da relação. 
Para ilustrarmos, observe o diagrama da figura 6. Ele mostra 
uma relação entre um Artigo e seu Revisor. Duas informações, 
que são a data da revisão e a sua descrição, são inerentes ao 
ato da revisão, não sendo de nenhum dos participantes da 
relação. Assim, criamos uma nova classe, chamada de Revisão, 
e incluímos essas informações.
Além da associação comum, uma associação pode receber 
outros nomes, dependendo dos papéis das classes nesta relação. 
Veremos, a seguir, essas situações.
pode ter sobre a outra, ela pode ter outros dois nomes diferentes que 
 Indica um relacionamento todo-parte entre as classes 
participantes da relação, porém, as classes podem viver de forma 
independente. Por exemplo, um time pode conter vários jogadores, 
um jogador pode estar em um time.
 Indica uma relação mais forte que a agregação. Ela 
indica uma relação todo-parte entre os participantes, porém, um 
objeto-parte não faz sentido se o objeto-todo não existir. Por exemplo, 
uma revista é composta por artigos, mas um artigo tem como sua 
única razão de existir, compor a revista.
Na UML, essas duas situações são representadas com um diamante 
o todo. Na agregação, o diamante não é preenchido. Já, na composição, 
o diamante é preenchido.
relação envolvendo duas classes, A e B, precisamos fazer as seguintes 
1. Se um objeto da classe A for excluído, terei que excluir o objeto da 
Se a resposta for Sim, use a composição. Se Não vá à pergunta 2.
Se a resposta for Sim, utilize uma associação comum. Caso contrário, 
use um relacionamento de agregação, sendo que a classe A fará o 
papel do todo e a classe B fará o papel da parte.
Agora veremos mais um integrante do diagrama de 
classes, o relacionamento de Herança.
2.3
Como você viu na aula 2, a Herança é um conceito 
onde uma classe filha herda todas as características da classe 
pai, além de ter as suas próprias características. Na UML a 
relação de herança - chamada também de generalização/
especialização, é representada com uma linha reta, partindo 
da classe específica até a classe base (a classe pai). No lado 
da classe pai terá uma seta fechada e sem preenchimento. 
Na figura abaixo, as classes Gato, Cachorro e Rato herdam 
características da classe Animal.
165
22Met. para de Desenvolvimento de Software
Você também viu na segunda aula sobre o conceito de 
polimorfismo, que consiste em duas ou mais classes derivadas 
de uma mesma classe pai chamar métodos de mesmos nomes 
e parâmetros, mas com comportamentos distintos. Para isso, 
você pode colocar o mesmo nome do método nas classes 
derivadas.
2.4 - Exemplo de Diagrama de 
Classes
Nesta seção, mostraremos o diagrama de classes para o 
estudo de caso da locadora de veículos. Ele está reproduzido 
na figura abaixo.
Nesse diagrama,percebemos que:
características comuns entre Funcionário e Cliente. As 
classes Funcionário e Cliente possuem as características que 
são exclusivas dessas classes, como as datas de admissão e 
demissão de um Funcionário, o número da CNH e o número 
e serviços que foram identificados na etapa de análise. Além 
disso, percebeu-se a necessidade de colocar um atributo que 
e Carro, onde um cliente pode locar de nenhum a muitos 
colocados como parte de uma classe associativa chamada de 
e seleção das classes do sistema, colocamos os métodos 
manter() e selecionar() em todas as classes.
Chegamos ao fim da seção que explica o Diagrama de 
Classes. A seguir, você estudará o Diagrama de Casos de Uso.
3 - Diagrama de Casos de Uso
O Diagrama de Casos de Uso é uma forma de representar 
o sistema de informação na visão do usuário, representando 
os módulos que compõem o sistema, o usuário e seus papéis 
nesse sistema. É uma forma de mostrar os requisitos que 
deverão conter no sistema. 
Desenvolvido por Ivar Jacobson na década de 1970, 
demonstra de forma visual o que o sistema fará, e quem o 
fará, sem se preocupar com os detalhes de implementação. 
É uma forma importante e consolidada para documentar os 
requisitos funcionais do sistema.
Um diagrama de casos de uso normalmente contém 
Atores, Casos de Uso, Iterações e Relacionamentos. Veremos 
sobre eles a seguir.
3.1 - Caso de Uso
Reproduz um componente do sistema (serviços, 
tarefas ou funções) que pode ser manipulado por um ou 
mais atores. É representado por uma elipse, contendo no seu 
interior uma descrição do que é feito, normalmente composto 
por verbos no infinitivo - por exemplo: Calcular Média do 
Aluno, Gerar Pedido de Exame, Emitir Nota Fiscal etc.
No diagrama, um Caso de Uso apenas é apresentado pelo 
seu nome. Mas, pode-se colocar uma especificação funcional 
desse caso de uso. Ele representa de forma escrita o que 
será feito nesse caso de uso, descrevendo as etapas que serão 
executadas. A UML não define um padrão para fazer essa 
especificação. 
3.2 - Ator
Representa alguém externo ao sistema que interage ou 
utiliza os casos de uso. Pode ser uma pessoa, outro sistema 
de informação, uma empresa etc. Na UML, um ator é 
representado por um boneco-palito (stick man), junto com o 
nome que identifica esse ator. Góes (2014) recomenda que o 
nome do ator deve representar o papel que o ator desempenha 
no sistema - por exemplo: Professor, Gerente, Funcionário etc., 
evitando usar nome de pessoas reais como nome de ator, para 
evitar que a saída de pessoas inicialmente envolvidas com o 
sistema não deixe a documentação desatualizada rapidamente.
166
23
Um ator não precisa ser obrigatoriamente representado 
por um boneco-palito, ele pode ser exibido por um retângulo 
identificado com o seu nome e o estereótipo <<Actor>> ou 
por outros ícones como, por exemplo, de um microcomputador.
3.3 - Iterações ou Associações
Uma iteração indica que um ator utiliza um determinado 
caso de uso. Para representar uma iteração, ligamos uma linha 
reta entre o ator e o respectivo caso de uso.
Opcionalmente, podemos colocar multiplicidades para 
indicar quantas vezes um ator pode executar esse caso de 
uso e quantos atores podem executar um caso de uso. Essa 
multiplicidade é exatamente igual ao que você viu na seção 2.2 
desta aula. No exemplo abaixo, um ator só pode executar o 
caso de uso “Submeter Trabalho Científico” apenas uma vez, 
enquanto que esse caso de uso pode ser executado por diversos 
atores diferentes.
3.4 - Relacionamentos
Essa é a parte mais interessante de um Diagrama de Casos 
de Uso, podendo demonstrar relações, inclusão, exclusão e 
herança. Vejamos sobre eles a seguir:
de uso A e B. Se A tiver uma relação de inclusão com B, significa 
que toda vez que o caso de uso A for executado, o caso de uso 
B também será executado. É representado por uma flecha com 
uma reta tracejada, partindo do caso de uso que chamará o caso 
de uso a ser incluído (o caso de uso A) até o caso de uso a ser 
incluído (o caso de uso B). Essa reta deverá ter o estereótipo 
<<include>>.
inclusão, porém, o caso de uso a ser usado nem sempre será 
executado, dependendo das condições impostas pelo caso 
de uso. Assim, se um caso de uso A tiver uma relação de 
extensão com o caso de uso B, o caso de uso B nem sempre 
será executado se A for executado. É representado por meio 
de uma seta tracejada, partindo do caso de uso a ser usado 
até o caso de uso que usará ele (ou seja, no sentido contrário 
à inclusão), junto com o estereótipo <<extends>>. Pode 
ser acompanhado por uma linha tracejada com uma nota 
explicativa sobre qual seria essa condição.
herança indica uma passagem de características de um item 
mais geral, para um ou mais itens filhos. Nesse diagrama, ele 
pode ocorrer entre atores (um ator pode herdar os casos de 
uso que o ator geral interage) e casos de uso de um sistema. 
É representado da mesma forma que uma herança de classes, 
por meio de uma linha reta ligando o item base ao item a ser 
herdado, com um triângulo apontando para o item base.
2.5 - Exemplo de Diagrama de Caso 
de Uso
Vamos mostrar agora o Diagrama de Caso de Uso Geral 
para o sistema da Locadora. Neste diagrama procuramos 
agrupar as operações comuns de dados (que são criar, editar, 
ler e apagar) de uma classe como um caso de uso único, que é 
nomeado de cadastro. Um caso de uso geral pode abrigar um 
conjunto de casos de uso específicos.
No nosso exemplo, o analista descobriu cinco casos de 
uso usando este critério de agrupamento: Cadastro de Veículo, 
Cadastro de Locação, Cadastro de Cliente, Encerrar Locação 
e Cadastro de Funcionários. Todos os casos de uso podem 
ser executados por um usuário comum, exceto o cadastro 
de funcionários, onde já declaramos como uma atribuição 
exclusiva dos funcionários com o status de supervisor. 
Como um funcionário supervisor tem acesso a todos 
os cadastros que um funcionário comum tem, foi acertado 
o uso da herança, onde o funcionário supervisor herda todos 
os casos de uso que um funcionário comum pode acessar. O 
diagrama final você observa na figura abaixo:
167
24Met. para de Desenvolvimento de Software
Para finalizar a aula, vamos apresentar o Diagrama de 
Atividades.
4 - Diagrama de Atividades
É um diagrama que consiste em representar os aspectos 
dinâmicos do sistema. Pode ser usado para documentar de 
uma pequena parte de um código até um sistema inteiro, 
como também para documentar as atividades de um caso 
de uso. Góes (2014) afirma que o Diagrama de Atividades 
pode ser entendido como uma evolução do Fluxograma, e 
que a grande diferença entre os dois é que o Diagrama de 
Atividades pode documentar fluxos de controle concorrentes, 
o que não é possível em um Fluxograma comum.
Podemos encontrar os seguintes elementos em um 
Diagrama de Atividades:
: Indica o início de um fluxo quando uma 
sequência de ações tem início. É representado por um círculo 
totalmente preenchido, podendo ter mais de um nó inicial por 
diagrama.
: Indica o ponto de saída de um 
processamento ou processo. É representado por um círculo 
preenchido dentro de um círculo vazado, podendo ter mais de 
um ponto final por diagrama.
: É a unidade elementar que existe nesse tipo de 
diagrama. Ela indica a transformação dos dados por meio de 
um processamento ou mostra algum passo ou alguma rotina 
sendo executados em um processo. Podem ser coisas feitas 
pelo usuário ou pelo sistema. Ele é indicado por meio de um 
retângulo com bordas arredondadas, contendo o nome da 
ação, que normalmente é um verbo no infinitivo.
: Sua serventia é indicar uma 
conexão entre as ações, mostrando qual a ordem de execução 
entre elas, ou seja, indica qual será a próxima ação a ser 
executada após a conclusão da ação anterior. É indicada por 
meio de uma seta que começa da ação anterior, apontando 
para a próxima ação.
: Indica que há uma escolha de fluxo 
a ser feita por meio de uma decisão. É representada por meio 
de um losango vazado, podendoter vários fluxos partindo 
dele. Em cada fluxo é indicada qual a condição que deve ser 
satisfeita para seguir esse fluxo.
: 
Os dois nós são usados para simbolizar paralelismo. O nó 
de bifurcação abre uma série de fluxos de controle que são 
executados paralelamente. Já o nó de união indica a união de 
fluxos de controle paralelos, finalizando o paralelismo. Ambos 
os nós são indicados por uma barra.
: Indica uma união de vários fluxos de controle, 
com uma só saída do fluxo de controle. É representada por 
meio de um losango recebendo os fluxos a serem unidos e 
servindo de ponto de partida do fluxo seguinte.
: Dividem o fluxo de processo entre os atores 
que interagem com as ações do diagrama, podendo estar na 
horizontal ou na vertical.
Para ilustrar o Diagrama de Atividades, vamos mostrar 
um diagrama que fizemos para representar um cadastro de 
uma locação. Nesse ato, estão dois atores: o funcionário que 
realiza o cadastro e o sistema que processa as informações 
dadas. Por isso as atividades foram divididas em duas raias, 
cada uma representando um ator. Veja abaixo o diagrama:
Observe que as tarefas de validação são realizadas em 
paralelo, com o uso das barras de sincronização. Perceba que 
após a validação, há uma condição de guarda que determina se 
uma locação deve ser registrada ou se o sistema deve pedir os 
dados novamente.
Com isso, finalizamos a primeira parte da aula de UML. 
Na próxima aula, veremos mais diagramas importantes da 
UML.
Retomando a aula
Parece que estamos indo bem. Então, para encerrar 
1 – Introdução à Unified Modeling Language – UML
A Unified Modeling Language (ou em Português: 
Linguagem de Modelagem Unificada), é uma sintaxe geral 
168
25
para criar um modelo lógico de um sistema. É uma linguagem 
que serve para documentar, especificar, construir e visualizar 
artefatos de um software. Ela possui um conjunto de diagramas 
compostos por itens e relacionamentos.
2 – Diagrama de Classes
O Diagrama de Classes define as classes que estarão no 
sistema, além da estrutura dos dados (atributos) e serviços 
(métodos) de cada classe, e dos seus relacionamentos entre 
essas classes que estão nesse sistema. É considerado uma 
evolução do diagrama de Entidade-Relacionamento e contém 
basicamente representações de Classes, Associações e Herança.
3 – Diagrama de Casos de Uso
O Diagrama de Casos de Uso é uma forma de reproduzir 
o sistema de informação na visão do usuário, representando os 
módulos que compõem o sistema, o usuário e seus papéis nesse 
sistema. É uma forma de mostrar os requisitos que deverão 
conter no sistema. Ele contém representações de atores e casos 
de uso, sendo que os atores interagem com os casos de uso.
4 - Diagrama de Atividades
É um diagrama que consiste em representar os aspectos 
dinâmicos do sistema. Pode ser usado para documentar uma 
pequena parte de um código até um sistema inteiro, como 
também para documentar as atividades de um caso de uso. Ele 
contém uma série de atividades que devem ser executadas em 
um caso de uso.
PRESSMAN, Roger. Engenharia de Software. São Paulo-
SP: Makron Books, 2006.
SOMMERVILLE, I. Engenharia de Software. 8ª Edição. 
Addison Wesley, 2007.
James. UML – guia do usuário. Rio de Janeiro: Elsevier, 2012.
UML e 
C++-Guia prático de desenvolvimento orientado a objeto. São Paulo: 
Makron, 2002.
ENGHOLM JR, Hélio. Engenharia de Software na prática. 
São Paulo: Novatec Editora, 2010.
GÓES, Wilson Moraes. Aprenda UML por meio de estudos 
de caso. São Paulo: Novatec Editora, 2014.
BALZERT, Heide. UML 2: compacto. Rio de Janeiro: 
Elsevier, 2007.
LIMA, Adilson da Silva. UML 2.5 : do requisito à 
BEZERRA, Eduardo. Princípios de análise e projeto de 
sistemas com UML. 2. ed. Rio de Janeiro: Campus, 2007.
Vale a pena
Vale a pena ler
Vale a pena acessar
OMG. About. [S.l.:] OMG, [s.d.] Disponível em 
<http://www.omg.org/about/index.htm>. Acesso em 30 
set. 2017.
OMG. Unified Modeling Language™ (UML®). [S.l.:] 
OMG, [s.d.]. Disponível em: <http://www.omg.org/spec/
UML/>. Acesso em 02 out. 2017.
Minhas anotações
169