Linguagem Unificada

Conteudista: Prof. Me. Artur Marques

Revisão Textual: Esp. Jéssica Dante

Objetivo da Unidade:

Fundamentar e modelar sistemas mediante UML.

ʪ Material Teórico

ʪ Material Complementar

ʪ Referências
1 /3

ʪ Material Teórico

Linguagem Unificada de Modelagem (UML)

UML – Unified Modeling Language ou Linguagem de Modelagem Unificada é uma forma de
unificar diagramaticamente os dados referentes a modelagem e requisitos necessários para um
projeto de software para que qualquer profissional da área de análise possa entender de qualquer
lugar do mundo.

É baseada em representações diagramáticas de componentes de software. Ela foi criada como

resultado do caos que girava em torno do desenvolvimento e documentação de software. A partir
disso, surgiu a necessidade de uma forma mais unificada de representar visualmente esses
sistemas e, como resultado, em meados da década de 90 do século XX, a UML foi desenvolvida
por três engenheiros de software que trabalhavam na Rational Software, empresa que mais
adiante foi adquirida pela IBM. Mais tarde, foi adotada como padrão no final da década de 90 e
permaneceu como padrão desde então, recebendo apenas algumas atualizações.

Existem vários tipos de diagramas UML e cada um deles atende a um propósito diferente,
independentemente de estar sendo projetado antes ou depois da implementação.

As duas categorias mais amplas que abrangem todos os outros tipos são os diagramas
Comportamentais e Estruturais.

Diagramas comportamentais: descrevem os elementos de um

sistema que são dependentes do tempo e que transmitem os
conceitos dinâmicos do sistema e como eles se relacionam
entre si. Os elementos nesses diagramas se assemelham aos
verbos no infinitivo em uma linguagem natural e as relações
que os conectam normalmente transmitem a passagem do
tempo.

Diagrama de atividades;

Diagrama de casos de uso;

Diagrama de visão geral da interação;

Diagrama de temporização;

Diagrama de máquina de estado;

Diagrama de comunicação;

Diagrama de sequência.

Diagramas estruturais: descrevem os elementos de um sistema

que são independentes do tempo e que transmitem os conceitos
de um sistema e como eles se relacionam entre si. Os elementos
nesses diagramas se assemelham aos substantivos em uma
linguagem natural, e os relacionamentos que os conectam são
relacionamentos estruturais ou semânticos.

Diagrama de classe;

Diagrama de objeto;

Diagrama de componentes;

Diagrama de estrutura composta;

Diagrama de implantação;

Diagrama de pacote;

Diagrama de perfil.
Existem três grandes benefícios da UML:

Comunicação aprimorada: permite que os desenvolvedores se comuniquem sobre

um tópico que inclui o sistema e seus requisitos. Dessa forma, pode ajudar os
profissionais a se comunicarem com colegas de trabalho e entre várias equipes;

Modelo claro: o modelo UML usa uma representação do assunto e uma combinação
de um conjunto de ideias para auxiliar a comunicação visual;

Padronização: reúne tecnologia e sistemas de informação e aplica técnicas

específicas para desenvolver sistemas padronizados e bem-sucedidos.

Os diagramas são feitos de elementos, ou seja, utilizam conceitos orientados a objetos. Aqui
estão algumas notações de elementos comuns que você pode usar na modelagem UML e que
deve se apropriar dos seus conceitos:

Objetos: representam uma entidade do mundo real e são a base da UML. Eles ajudam
desenvolvedores e engenheiros a quebrar sistemas grandes e construí-los em
seções;

Classe: define a estrutura e a função de um objeto. Você provavelmente agruparia

objetos que têm a mesma estrutura e função em uma classe;

Abstração: visualiza o comportamento do objeto e sua dependência de outro

elemento do diagrama;

Herança: categoriza classes de objetos ou forma novas classes a partir de outras já

existentes;

Encapsulamento: é um processo técnico que une os dados para protegê-los

daqueles sem permissão que podem ter a capacidade de interferir em um processo
de outra forma;
 Polimorfismo: é um processo em que entidades ou funções podem operar da
mesma forma, mas passam por um processo de implementação diferente um do
outro e em momentos diferentes durante o desenvolvimento.

Vamos definir rapidamente esses diagramas da UML e depois focaremos nos que utilizamos
rotineiramente em engenharia de software tradicional e ágil.

Diagramas estruturais:

Diagramas de classe: são o princípio fundamental de qualquer sistema de software

orientado a objetos e descrevem classes e conjuntos de relacionamentos entre
classes. As classes dentro de um sistema ou operação descrevem sua estrutura, o
que ajuda os engenheiros e desenvolvedores de software a identificar o
relacionamento entre cada objeto;

Diagramas de componentes: indicam a estrutura organizacional dos elementos

físicos em um sistema de software. Eles ajudam engenheiros e desenvolvedores a
entender se os sistemas precisam de melhorias adicionais ou se sua estrutura
original funciona com eficiência;

Diagramas de estrutura composta: mostram a estrutura interna de uma classe e

como ela se comunica com outras partes do sistema;

Diagramas de implantação: mostram quais componentes de hardware estão

disponíveis e quais tipos de componentes de software podem executá-los com
eficiência. Eles são benéficos quando o software é distribuído ou usado em várias
máquinas com diversas configurações;

Diagramas de objetos: mostram o relacionamento entre as funções de um sistema,

juntamente com suas características;

Diagramas de pacote: são os vários níveis que podem contribuir para a arquitetura
de um sistema, e os diagramas de pacote ajudam os engenheiros e desenvolvedores
a organizar seus diagramas UML em grupos que os tornam mais fáceis de entender;
 Diagramas de perfil: fornecem um mecanismo de extensão
genérico para construir modelos em domínios específicos. Eles
são baseados em valores adicionais de Estereótipos e Marcados
que são aplicados a Elementos, Atributos, Métodos, Links,
Terminais de Link e muito mais.

Diagramas comportamentais:

Diagramas de caso de uso: mostra as partes do sistema ou a funcionalidade de um

sistema e como elas se relacionam entre si. Ele fornece aos desenvolvedores uma
compreensão clara de como as coisas funcionam, ou seja, os atores e suas
interações, sem a necessidade de analisar os detalhes da implementação;

Diagramas de atividades: descrevem o fluxo de controle em um sistema e podem

ser úteis como referência a seguir ao executar um diagrama de caso de uso. Os
diagramas de atividades também podem descrever as causas de um evento
específico;

Diagramas de sequência: mostram como os objetos se comunicam

sequencialmente. É comumente usado por desenvolvedores de software para
documentar e entender os requisitos necessários para estabelecer novos sistemas
ou obter mais conhecimento sobre os sistemas existentes;

Diagramas de comunicação: mostram a troca sequencial de mensagens entre

objetos. Esses diagramas são semelhantes aos diagramas de sequência, mas os
diagramas de comunicação oferecem mais flexibilidade;

Diagramas de visão geral da interação: usam diferentes tipos de programas de

interação para mostrar a sequência de ações. Esses diagramas ajudam os
desenvolvedores a transformar interações complexas em eventos simples;

Diagramas de máquina de estado: descrevem como os objetos se comportam de

maneiras diferentes a partir de uma situação atual conhecida;
 Diagramas de tempo: são um tipo de diagrama de sequência usado para mostrar o
comportamento dos objetos ao longo do tempo. Os desenvolvedores os usam para
ilustrar as restrições de duração e o tempo para controlar as mudanças no
comportamento dos objetos.

Artefatos UML Comuns Usados em Projeto de Software

Diagramas de Classe
Vamos recordar rapidamente o que é uma classe. Trata-se de um objeto, portanto poderá ser
qualquer pessoa, local, coisa, conceito, evento, tela ou relatório aplicável ao seu sistema. Os
objetos “possuem” coisas (atributos) e fazem “coisas” (métodos).

Uma classe é uma representação ou, se preferir, uma coleção de objetos ou, ainda, é
simplesmente um modelo a partir do qual os objetos são criados e colecionados. Abstraímos os
atributos essenciais para que nosso modelo funcione, afinal não pretendemos imitar o mundo
real em toda a sua riqueza de detalhes, para nossos sistemas de informação, apenas alguns
serão o suficiente.

As classes formam os principais blocos de construção de um aplicativo orientado a objetos.

Então vejamos, embora muitos alunos possam frequentar uma escola, você modelaria apenas
uma turma, chamada alunos, que representaria toda a coleção de estudantes, por exemplo.

As classes geralmente são modeladas como retângulos com três seções: a seção superior para o
nome da classe, a seção intermediária para os atributos da classe e a seção inferior para os
métodos da classe.

Os objetos que estão contidos nas classes são frequentemente associados ou relacionados a
outros objetos. Por exemplo, professores instruem os alunos. A associação é uma linha que
possui duplo sentido e que é representada pela multiplicidade.
 Figura 1 – Componentes de associação entre dois objetos
(classes)

#ParaTodosVerem: Modelo padrão explicando classes. Imagem em preto e

branco colocando duas classes em retângulos, uma à esquerda chamada de
pessoa e outra à direita chamada de empresa. A relação entre pessoa com relação
a empresa é que precisamos de uma ou mais pessoas para compor uma
empresa, essas pessoas trabalham para essa empresa, a relação é empregado
para empregador, a associação é nesse caso, pessoas se associam a empresas.
Fim da descrição.

As multiplicidades podem ocorrer da seguinte maneira:

Tabela 1 – Indicadores de Multiplicidade

Indicador Significado

0..1 Zero ou um

11 Apenas um
 Indicador Significado

0 .. * Zero ou mais

1 .. * Um ou mais

n Somente n (onde n > 1)

0..n Zero a n (onde n > 1)

1..n Um para n (onde n > 1)

Geralmente existem semelhanças entre diferentes classes. Muitas vezes, duas ou mais classes
compartilham os mesmos atributos e/ou os mesmos métodos. Isso é uma herança!

Modelos de herança “é um” e “é como” relacionamentos, permitindo reutilizar dados e códigos

existentes facilmente. Por exemplo, quando o objeto A herda do objeto B, dizemos que A é a
subclasse de B e B é a superclasse de A.

Figura 2 – Superclasse e Subclasse

#ParaTodosVerem: Exemplo de classe e subclasses padrão. Duas imagens em

preto e branco, a imagem da esquerda representa no topo da imagem uma
superclasse e logo abaixo ligadas por linhas duas subclasses que partem da
 superclasse. Na imagem da direita, por outro lado, temos um exemplo prático
colocando veículo como superclasse e duas subclasses logo abaixo uma
chamada terrestre e outra aéreo. Fazendo a alusão que veículos terrestres, como
caminhões e carros, assim como veículos aéreos, como aviões de carga e de
passageiros são todos veículos apenas variando seu tipo. Fim da descrição.

Às vezes, um objeto é composto de outros objetos. Por exemplo, um avião é composto de

fuselagem, asas, motores, trem de pouso e assim por diante. Ou seja, os objetos “parte” só
podem pertencer a um único objeto “todo” e têm o seu tempo de vida coincidente com o dele. Se
o “todo” morre, todas as suas “partes” também morrem. A forma de representarmos isso em
um exemplo seria:

Figura 3 – Associação do tipo composição

 #ParaTodosVerem: Exemplo de classe e subclasse. Duas figuras, a de cima
chamada Revistas e a de baixo chamada Edições. Demonstra-se com isso o
princípio da composição em classes. Revistas são compostas de edições, ou seja,
edição de abril, edição de maio, edição de junho etc. representam a mesma
revista, porém com conteúdo dos meses aos quais suas edições representam.
Fim da descrição.

Temos a relação de agregação entre objetos e aqui se trata de algo do tipo (todo-parte), ou seja,
um objeto “parte” pode fazer parte de vários objetos “todo”. O exemplo mais tradicional para
isso é:

Figura 4 – Relacionamento de Agregação

#ParaTodosVerem: Exemplo de classe e subclasse. Duas figuras em preto e

branco, a de cima chamada Revistas e a de baixo chamada Edições. Demonstra-
se com isso o princípio da composição em classes. Revistas são compostas de
edições, ou seja, edição de abril, edição de maio, edição de junho etc.
representam a mesma revista, porém com conteúdo dos meses aos quais suas
edições representam. Fim da descrição.

Um exemplo completo:
 Figura 5 – Diagrama de Classe de uma Escola

#ParaTodosVerem: Exemplo de um diagrama de classes. Imagem contendo

classes representadas por retângulos brancos, contornados em azul. São oito
classes representando um diagrama de classes completo da modelagem de uma
escola. As entidades apresentadas nesse diagrama estão conectadas por linhas e
são: Aluno, turma, professor, disciplina, curso, detalhe de turma, detalhe de
disciplina e detalhe de curso. Fim da descrição.

Vejamos a partir do diagrama de classe de uma escola representado pela Figura 5.

“Classe Aluno: o que inclui basicamente essa classe são os atributos nome, sexo,

matricula, dataNascimento. Todos esses atributos serão exclusivos, e terão acesso

exclusivo à classe, assim como para acessar os fóruns da classe serão necessários
para a construção dos métodos Getter e Setter (um método getter retorna seu valor,
enquanto um método setter o define ou atualiza).

Não é necessário visualizar esses métodos no diagrama, apenas os métodos

relevantes são considerados.

Os métodos dessa classe são: registradorAluno, ocultarAluno, excluirAluno e

alterarMatricula.

Classe Professor: basicamente é composto pelos atributos nome, sexo e registro.

Os métodos dessa classe são: consultarTurma, lancarNota e realizarFrequencia.
Todos os atributos da classe podem ser privados e precisos dos seus métodos
Getter e Setter.

Classe Turma: composto pelos atributos codigo, codigoAluno, codigoProfessor. Os

métodos dessa classe são listarTurma, listarAlunos. Os atributos dessa classe são
exclusivos.

Classe Curso: é composto pelos atributos codigo e nome apenas e os métodos

consultarCurso e incluirCurso. Os atributos são privados

Classe Disciplina: é composto pelos atributos codigos e nome e pelos métodos de

consultarDisciplina e incluirDisciplina.

Classe DetalheTurma: é uma classe que auxilia no relacionamento da classe Turma

junto com as classes Aluno e Professor. Essa classe é composta pelos atributos
codigoAluno, codigoProfessor e codigoTurma. Todos os atributos dessa classe são
particulares.

Classe DetalheCurso: é uma classe que auxilia no relacionamento da classe Curso

junto à classe Turma. É composto pelos caracteres codigoCurso e codigoTurma. Os
atributos dessa classe são privados.
DetalheDisciplina: é uma classe que auxilia no relacionamento da classe Disciplina
junto à classe Curso. É composto pelos atributos codigoCurso e codigoDisciplina.
Seus atributos são privados.”

- SANTOS, 2013, p. 11

Casos de Uso Geral

Os diagramas de casos de uso são usados para reunir os requisitos de um sistema, incluindo
influências internas e externas. Esses requisitos são principalmente requisitos de design.
Portanto, quando um sistema é analisado para reunir suas funcionalidades, os casos de uso são
preparados e os atores são identificados. Tudo isso usando uma linguagem visual para que o
usuário ou cliente possa entender o comportamento dos atores no sistema.

Os objetivos dos diagramas de casos de uso podem ser os seguintes:

Reunir os requisitos de um sistema;

Obter uma visão externa de um sistema;

Identificar fatores externos e internos que influenciam o sistema;

Mostrar a interação entre os requisitos e seus atores.

Os casos de uso nada mais são que as funcionalidades do sistema escritas de maneira
organizada, e os atores (pessoas, aplicativos internos ou aplicativos externos) podem ser
definidos como algo que interage com o sistema.

Um caso de uso é representado como um elipsoide e eles podem se relacionar com os atores ou
uns com os outros através de linhas, includes e extends que são alguns dos itens que os
compõem.
Um relacionamento entre dois casos de uso é basicamente uma dependência entre eles.

Include: quando um caso de uso é descrito como usando a funcionalidade de outro

caso de uso em um diagrama, esse relacionamento “entre os casos de uso” é
nomeado como um include. Literalmente falando, um caso de uso inclui a
funcionalidade descrita em outro caso de uso como parte de seu fluxo de processos
de negócios.

Figura 6 – Relacionamento <include>

#ParaTodosVerem: Representação de um relacionamento de include. Imagem

em preto e branco contendo em seu lado esquerdo um ator chamado cliente. De
sua frente emanam três linhas que se ligam a três elipses chamadas na seguinte
ordem: obter extrato, realizar saque e realizar transferência. De cada elipse
dessa sai uma seta em linhas pontilhadas com o termo include, terminando
todas em uma elipse final mais a direita nomeada de fornecer identificação. Ou
seja, o cliente para poder obter extrato, fazer um saque ou realizar uma
transferência precisa obrigatoriamente se identificar, caso contrário isso não
ocorrerá. Fim da descrição.

Extend: em um relacionamento extend entre dois casos de uso, o caso de uso filho é
adicionado à funcionalidade e às características existentes do caso de uso pai. Um
relacionamento extend é representado com uma seta direcionada com um eixo
 pontilhado, semelhante ao relacionamento de inclusão. A ponta da seta se direciona
para o caso de uso pai e o caso de uso filho é conectado na base.

Figura 7 – Relacionamento <extend>

#ParaTodosVerem: Exemplo padrão de extend. Figura em preto e branco

contendo um ator definido como Escritor ligado a uma elipse chamada Editar
Documento. Dessa elipse chegam duas setas pontilhadas que partem de duas
elipses a saber: substituir texto e a outra, corrigir ortografia. Ou seja, quando
edito um texto nem sempre eu substituo o texto e nem sempre eu preciso
corrigir a ortografia. Fim da descrição.

Vejamos um exemplo prático:

Atores:

Visitante: qualquer pessoa que acessar o site da pizzaria e não possuir cadastro;

Cliente: visitante cadastrado e identificado por login;

Atendente: funcionário responsável por receber pedidos;

Pizzaiolo: funcionário responsável por preparar e assar as pizzas;

Cozinheiro: funcionário responsável por preparar os ingredientes das pizzas.

 Figura 8 – Diagrama simples de uma pizzaria. Subsistema 1

#ParaTodosVerem: Exemplo de diagrama de caso de uso completo para uma

pizzaria. Imagem composta das principais elipses contendo os casos de uso
gerais para uma pizzaria. As elipses estão em bege e circundam dois atores
principais a saber: um visitante e o outro, um cliente. O cliente pode fazer tudo o
que o visitante faz, porém poderá além disso: modificar ingredientes, modificar
horário, adicionar pizzas e modificar quantidades. Enquanto o visitante,
enquanto não se identificar, não poderá fazer isso. Fim da Transcrição.

“Os casos de uso foram divididos em 2 subsistemas: pedidos e produção.

O subsistema de pedidos mostra os atores visitante (cliente não identificado) e

cliente (já identificado). A relação de herança mostra que um cliente já identificado
pode realizar todas as operações que um visitante está habilitado a fazer. Algumas
funcionalidades, porém, estão disponíveis apenas aos clientes identificados. Um
visitante pode passar por todo o processo de criação de um pedido: (1) ver o
cardápio; (2) selecionar pizza do cardápio (com opção de alterar alguns
ingredientes) ou criar uma pizza personalizada; e (3) escolher o horário de entrega
da pizza (próxima fornada disponível ou agendada para um horário futuro). Ao
escolher o horário, será necessário identificar-se para concluir o pedido (seja por
um novo registro ou por login).

Um cliente cadastrado pode ainda modificar um pedido que tenha feito

anteriormente (desde que não esteja muito em cima da hora de entrega do
mesmo). De um pedido pode-se modificar ingredientes das pizzas, horário de
entrega, quantidades das pizzas e ainda adicionar novas pizzas.”

- SOUZA, 2022, p. 2

Figura 9 – Diagrama simples de uma pizzaria. Subsistema

2

#ParaTodosVerem: Exemplo de diagrama de caso de uso para três atores

específicos. Descreve os casos de uso gerais pertencentes ao ator atendente:
 cadastrar o pedido, cadastrar o cliente, completar a fornada, dar baixa no pedido
e determinar a carga. Outro ator nomeado como pizzaiolo tem como
responsabilidade, ver o pedido e por fim, um último ator, o cozinheiro, tem a
finalidade de ver os ingredientes necessários. Fim da descrição.

“O subsistema de produção mostra os atores que são funcionários da pizzaria: o

atendente, o pizzaiolo e o cozinheiro. O atendente é o que mais se relaciona com o

sistema. Ele pode cadastrar pedidos e clientes (no caso de clientes que fazem seus
pedidos in-loco ou por telefone), pode completar uma fornada que esteja com
espaço sobrando (com pizzas de última hora ou para serem vendidas a fatia) e dar
baixa em pedidos que forem sendo entregues. O atendente é responsável, ainda,
por determinar a carga de trabalho dependendo do número de funcionários
presentes no momento, o que determina os tamanhos das fornadas. O pizzaiolo e o
cozinheiro apenas acompanham pelos monitores suas próximas tarefas: o
pizzaiolo verifica os pedidos da próxima fornada para preparar as pizzas e o
cozinheiro obtém do sistema informação de quais ingredientes foram usados nos
últimos pedidos e podem estar precisando ser recarregados.”

- SOUZA, 2022, p. 3

Caso de Uso Descritivo

O caso de uso descritivo é um documento narrativo que descreve, em termos gerais, a
funcionalidade necessária do caso de uso. Ou seja, fornece uma descrição geral do que
geralmente acontece, o curso normal dos eventos, adicionando uma breve descrição de
quaisquer variações menores. A descrição é genérica e deve ser escrita de forma a abranger
todas as sequências de eventos, todos os cenários relacionados ao caso de uso.
A descrição está escrita em termos do que o sistema deve fazer, não como deve fazê-lo. O que
acontece nos bastidores em termos de codificação, estruturas de armazenamento de dados e
outros detalhes de implementação não é relevante em uma descrição de caso de uso, apenas o
que o usuário vê acontecendo. Portanto, descreve o sistema como o usuário o vê e não tem como
objetivo formar a base de uma especificação de programa ou fornecer informações sobre os
processos internos do sistema.

Quando suficientemente detalhada, deve conter:

O que acontece para iniciar o caso de uso;

Quais atores estão envolvidos;

Quais dados devem ser inseridos;

A saída do caso de uso;

Quais dados armazenados são necessários para o caso de uso;

O que acontece para sinalizar a conclusão do caso de uso.

Vamos ver um exemplo de como devemos proceder:

Tabela 2 – Exemplo de Caso de Uso Expandido

Caso de uso:
Suporte ao cliente

Referências:
RF 0038, RF 0039
Descrição geral:
O caso de uso inicia-se quando o cliente deseja sanar
suas dúvidas em relação aos serviços e produtos
fornecidos.

Atores:
Usuário, Chatbot.

Pré-condições:
Usuário dentro do site, na página de suporte/aba de
chatbot aberta.

Garantia de sucesso (Pós-condições):

Atendimento com status concluído.

Requisitos especiais:
RFN 0019

Fluxo básico:

1. Usuário abre a aba do chatbot:

a. Chatbot pede ao usuário que digite seu nome;

b. Usuário digita o nome;

c. Chatbot informa os assuntos aos quais ele tem

respostas;

d. Usuário digita suas dúvidas;

 e. Chatbot imprime as respostas;

f. Usuário finaliza atendimento e avalia o chatbot.

Fluxo alternativo:

1. Chatbot não resolve as perguntas;

a. Chatbot imprime e-mail para contato com

suporte humano.

Diagrama de Sequência
O diagrama de sequência é o tipo mais comum de diagrama de interação, que se concentra no
intercâmbio de mensagens entre várias linhas de vida. O diagrama de sequência descreve uma
interação, concentrando-se na sequência de mensagens que são trocadas, juntamente com
suas especificações de ocorrência correspondentes nas linhas da vida. Os seguintes nós e
arestas são tipicamente desenhados em um diagrama de sequência UML: linha de vida,
especificação de execução, mensagem, fragmento combinado, uso de interação, estado
invariável, continuação, ocorrência de destruição.
 Figura 10 – Exemplo de principais elementos do diagrama
de sequência UML

#ParaTodosVerem: Padrão de diagrama de sequência. Imagem circunscrita a

um quadrado contendo os elementos que constituem um diagrama de sequência
típico com suas descrições em vermelho para cada elemento. Fim de descrição.

“Linha de vida: elemento nomeado que representa um participante individual na

interação. Enquanto partes e características estruturais podem ter multiplicidade

maior que 1, as linhas de vida representam apenas uma entidade que interage.

Portal: um portal é um ponto de conexão e final de mensagem para relacionar uma

mensagem fora de um fragmento de interação com uma mensagem dentro do
fragmento de interação. O objetivo dos portais e mensagens entre portões é
especificar o remetente e o destinatário concretos de cada mensagem.

Especificação de ocorrência: descrição do evento é um fragmento de interação que

representa um momento no tempo (evento) no início ou no final de uma
mensagem ou no início ou no final de uma execução.

Ocorrência de destruição: é uma ocorrência de mensagem que representa a

destruição da instância descrita pela linha de vida. Isso pode resultar na destruição
subsequente de outros objetos que esse objeto possui por composição. Nenhuma
outra ocorrência pode aparecer abaixo do evento de destruição em uma
determinada linha de vida.

Especificação de ocorrência de execução: é uma ocorrência que representa

momentos no tempo em que as ações ou comportamentos iniciam ou terminam. A
ocorrência de execução faz referência exatamente a uma especificação de execução
que descreve a execução iniciada ou finalizada nessa ocorrência de execução.

Especificação de execução: informalmente chamada de ativação, é um fragmento

de interação que representa um período na vida do participante em que pode ser:
executar uma unidade de comportamento ou ação dentro da linha da vida; enviar
um sinal para outro participante e; aguardar uma mensagem de resposta de outro
participante.”

- UML-DIAGRAMS, c2009-2022, p. 1
Figura 11 – Exemplo de diagrama de sequência a partir de
um caso de uso descritivo

#ParaTodosVerem: Descrição de um caso de um diagrama de sequência simples

baseado em um ator cujo papel é: leitor. Imagem em preto e branco com itens de
destaque em quadrados e setas que servem para dar ênfases nas ações
realizadas tanto no caso de uso normal quanto no caso de uso alternativo. Em
linhas gerais pode ser assim resumido: leitor fornece dados, sistema verifica se
leitor existe, se não existir o sistema cadastra, se existir o sistema avisa que já
está cadastrado e finaliza o caso de uso. Fim da descrição.
2/3

ʪ Material Complementar

Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Vídeos

Aula Modelagem Diagrama de Classes

AULA MODELAGEM DIAGRAMA DE CLASSES

Diagrama de Casos de Uso – Exemplo Básico

Curso de UML - Diagrama de Casos de Uso - Exemplo Básico

Análise de Sistema – Descrição do Caso de Uso Criar

Orçamento

Video 11 - Analise de sistema - Descricao do caso de uso criar orç…

 Leitura

Using Scrum Together with UML Models: A Collaborative

University-Industry R&D Software Project

Clique no botão para conferir o conteúdo.

ACESSE
3/3

ʪ Referências

SANTOS, J. C. F. dos. Criando Diagramas UML com o StarUML. Openstax CNX, 28/09/2013.
Disponivel em: <https://cnx.org/contents/sKehW_Tl@1/Criando-Diagramas-UML-com-o-
StarUML>. Acesso em: 09/08/2022.

SOUZA, V. E. S. Exercício pizzaria: análise de casos de uso. Docplayer, c2022. Disponível em:
<https://docplayer.com.br/5643242-Exercicio-pizzaria-analise-de-casos-de-uso.html>.
Acesso em: 09/08/2022.

UML-DIAGRAMS. UML Sequence Diagrams. c2009-2022. Disponível em: <https://www.uml-

diagrams.org/sequence-diagrams.html>. Acesso em: 09/08/2022.