Unidade 3 - Design Ágil Clique para obter mais opções

Prévia do material em texto

Desenvolvimento Ágil 
Responsável pelo Conteúdo:
Prof. Me. Artur Marques
Revisão Textual:
Prof. Esp. Mateus Gonçalves
Design Ágil
Design Ágil
 
 
• Aplicação UML para criação dos artefatos de desenvolvimento e aclaramento de requisitos 
para construção do software.
OBJETIVO DE APRENDIZADO 
• Conceitos de Qualidade e Riscos em Projetos Ágeis; 
• Artefatos Ágeis Baseados em UML: Diagramas de Classe;
• Casos de Uso Geral;
• Caso de Uso Descritivo;
• Diagrama de Sequência.
UNIDADE Design Ágil
Conceitos de Qualidade e 
Riscos em Projetos Ágeis 
O risco é um evento de incerteza nos projetos. Projetos ágeis envolvem menos 
riscos de qualidade do que os projetos tradicionais, se todas as melhores práticas de 
engenharia pregadas na programação extrema forem usadas. Dados os ciclos de 
tempo mais curtos, algumas técnicas que melhoram a qualidade do produto podem 
ser utilizadas. Alguns lugares que encontramos riscos de qualidade são:
Planejamento de liberação
O dono do produto, que conhece a funcionalidade do sistema de ponta a ponta, 
explica o alto nível de risco que prevê, e a equipe o avalia.
Lembrando que existem três níveis de planejamento ágil, que são: planejamento 
de liberação, de iteração e diário. 
O planejamento de liberação geralmente é realizado durante a Sprint Zero, onde 
não há incremento de produto entregue. Portanto, é uma maneira de prever o fu-
turo, definindo qual é o objetivo do release, quais recursos precisam ser entregues 
durante o lançamento, definindo o backlog do release, dividindo recursos e épicos 
em histórias de usuários, escrevendo critérios de aceitação para todas as histórias e 
estimando as histórias de usuários. Se você está pensando que eles podem mudar 
como tudo num projeto ágil, acertou; com base em novas histórias adicionadas ou 
excluídas. No início do planejamento da liberação, o dono do produto define a meta 
e o prazo da liberação.
Um ponto importantíssimo aqui são os testadores que deverão realizar várias atividades:
• Escrever histórias de usuário;
• Escrever os critérios de aceite;
• Esclarecer histórias com informação faltando ou não adequada ao entendimento;
• Descrever testes de alto nível;
• Descrever os riscos;
• Planejar como vão ocorrer os testes;
• Por fim, determinar qual a granularidade do teste, ou seja, até qual profundi-
dade iremos.
A conclusão aqui é que o planejamento da liberação não é um documento enges-
sado; pode sofrer alterações à medida que os fatores externos e internos são altera-
dos e que as execuções da iteração ocorrem. 
Diagrama de um Planejamento de Release (Liberação): https://bit.ly/2T7S3e3
8
9
Aqui cabe um exemplo:
Digamos que o Product Owner estabeleça, a partir de questões de negócios, a necessidade 
de uma entrega a ser realizada daqui a dois meses.
Digamos também que o tamanho do Sprint utilizado pelo Time de Desenvolvimento seja 
de duas semanas.
Assim, podemos calcular quantos Sprints serão executados até a data dessa Release:
n. Sprints = (Tempo Total / Tam. do Sprint) = (8 semanas / 2 semanas) = 4 Sprints
Sabemos, portanto, que quatro Sprints serão executados até a data dessa Release. Também 
podemos estimar quantos pontos o Time de Desenvolvimento entregará nessa Release:
n. pontos = (Velocidade x n. Sprints) = (30 pontos/Sprint x 4 Sprints) = 120 pontos
Para determinar o escopo provável da Release, parte-se do topo do Product Backlog e se 
desce, somando-se as estimativas de cada item dadas pelo Time de Desenvolvimento até 
se chegar em algo próximo (um pouco mais ou um pouco menos) que esses 120 pontos.
É importante, no entanto, entender que essa extrapolação traz uma previsão de baixa 
precisão, e assim gera um planejamento que deve ser revisto Sprint a Sprint.
Em outro caso, digamos que, ao invés de fornecer uma data, o Product Owner deseja saber 
em quanto tempo uma determinada necessidade de negócios poderá ser atendida.
Essa necessidade de negócios é a própria Meta da Release.
Estimativas: Primeiramente, o Product Owner deve garantir que o Product Backlog esteja 
ordenado e como os itens adequados para atender a essa necessidade.
O Product Owner partirá então do topo do Product Backlog e descerá, somando as estima-
tivas de cada item dadas pelo Time de Desenvolvimento, até considerar que já percorreu 
os itens necessários para atender a essa necessidade de negócios.
Assim, digamos que a soma dessas estimativas seja 184 pontos.
Se o Time de Desenvolvimento produz, em média, 30 pontos por Sprint (Velocidade), po-
deremos então estimar em quantos Sprints ele será capaz de queimar esses pontos:
n. Sprints = (n. pontos / Velocidade) = (184 pontos / 30 pontos/Sprint) = 
aprox. 6 Sprints
Podemos prever, portanto, que o Time de Desenvolvimento será capaz de queimar 
esses pontos em seis Sprints (parte inteira), ou seja, daqui a três meses.
É sempre importante lembrar que essa estimativa é de baixa precisão e deve ser 
revista em cada Sprint (DUARTE, 2015, p. 6 ).
Planejamento de iteração 
Toda a equipe passa por todas as histórias de usuários e descobre o risco de qua-
lidade associado a elas.
Aqui lembramos que o time SCRUM puxa as histórias para o backlog do sprint 
backlog do produto e as agrupa em tarefas independentes de menos de 8 horas 
cada. O mais interessante é que você precisa entender que muitas coisas em projetos 
ágeis acontecem sob demanda, como por exemplo, nós realizamos a avaliação de 
risco das histórias de usuários e decidimos/criamos um plano simples sobre como 
lidar com eles à medida que o sprint avança.
9
UNIDADE Design Ágil
Como fazemos isso? Simples, fazemos perguntas ao proprietário do produto 
sobre esclarecimentos que podem levá-lo a entender as histórias de maneira mais 
realista e nos passar. Ai a medida do desempenho de seu time de desenvolvimento 
será o número de histórias que puxamos, claro, isso vai depender da capacidade e 
da velocidade da equipe.
Sim, os testadores também são envolvidos nessa fase da mesma forma que no 
planejamento da liberação.
Sprint Planning
Início do
ciclo da
Sprint
Determina
• Objetivo
• Escopo
De�ne o
Sprint
Backlog
Figura 1 – Diagrama do Planejamento da aIteração (Sprint)
Fonte: Adaptado de DUARTE, 2018
Quando nos referimos a qualidade e risco ágil, o teste baseado em risco é a ideia 
de que podemos organizar nossos esforços de teste de forma a reduzir o nível residual 
de risco do produto quando o sistema é implantado. Ele começa no início do projeto, 
identificando riscos para a qualidade do sistema e usando esse conhecimento de 
risco para orientar o planejamento, especificação, preparação e execução do teste. 
Isso envolve tanto a mitigação do risco com o teste para reduzir a probabilidade de 
defeitos, principalmente os de alto impacto, quanto o teste de contingência, que 
serve para identificar soluções alternativas para tornar os defeitos que passam pelo 
time de desenvolvimento menos dolorosos.
O risco em projetos ágeis diminui à medida que o projeto avança. Por fim, é 
importante retratarmos as diferenças entre os riscos ágeis e os riscos tradicionais 
conforme tabela abaixo.
Tabela 1 – Risco tradicional versus risco ágil
Gerenciamento de riscos 
com abordagens tradicionais
Dinâmica de risco 
com abordagens ágeis
Muitos projetos falham ou são desafiadores.
O risco de falha catastrófica que leva em conta gastar 
grandes quantias de dinheiro sem nada para mostrar. 
Quase sempre é eliminado.
Quanto maior, mais longo e mais complexo o projeto, mais 
arriscado. O risco é mais alto no final de um projeto.
O valor do produto é obtido imediatamente, em vez de 
investir em um projeto por meses ou até anos, com a 
crescente chance de falha.
A realização de todos os testes no final de um projeto 
significa que encontrar problemas sérios pode colocar 
todo o projeto em risco.
O teste ocorre enquanto você desenvolve. Se uma aborda-
gem técnica, um requisito ou mesmo um produto inteiro 
não for viável, a equipe de desenvolvimento descobrirá 
isso rápido e você terá mais tempopara corrigir o rumo. Se 
a correção não for possível, as partes interessadas gastam 
menos dinheiro em um projeto com menos falhas.
10
11
Gerenciamento de riscos 
com abordagens tradicionais
Dinâmica de risco 
com abordagens ágeis
Os projetos são incapazes de acomodar novos requisitos no 
meio do projeto, sem aumento de tempo e custo, porque 
existem custos irrecuperáveis mesmo nos requisitos de 
menor prioridade.
As alterações em benefício do produto são bem-
-vindas. Projetos ágeis acomodam novos requisitos 
de alta prioridade sem aumentar o tempo ou o custo, 
removendo um requisito de baixa prioridade de tempo 
e custo iguais.
Projetos tradicionais exigem estimativas de tempo e 
custo no início do projeto, quando as equipes sabem 
menos sobre o projeto. As estimativas geralmente são 
imprecisas, criando uma lacuna entre os cronogramas e 
orçamentos previstos e reais do projeto.
O tempo e o custo do projeto são estimados usando o de-
sempenho real ou a velocidade da equipe SCRUM. Você 
refina as estimativas ao longo do projeto, porque quanto 
mais você trabalha em um projeto, mais aprende sobre o 
projeto, os requisitos e a equipe de SCRUM.
Quando as partes interessadas não têm um objetivo 
unificado, podem acabar confundindo a equipe do pro-
jeto com informações conflitantes sobre o que o produto 
deve alcançar.
Um único proprietário do produto é responsável por criar 
uma visão para o produto e representa as partes interessa-
das para a equipe do projeto.
As partes interessadas que não respondem ou estão 
ausentes podem causar atrasos no projeto e resultar em 
produtos que não atingem as metas certas.
O proprietário do produto é responsável por fornecer 
informações sobre o produto imediatamente. Além 
disso, o SCRUM MASTER ajuda a remover impedimen-
tos diariamente.
Fonte: Adaptado de LAYTON, 2020, p. 2
Artefatos Ágeis Baseados em UML: 
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 re-
lató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. Senã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 rela-
cionados a outros objetos. Por exemplo, professores instruem os alunos. As associa-
ções é uma linha que possui duplo sentido que são representados pela multiplicidade.
11
UNIDADE Design Ágil
nome
multiplicidade sentido de leitura
Pessoa Empresatrabalha para1..* *
empregado empregador
papéis
Tipo: associação
Figura 2 – Componentes de associação entre dois objetos (classes)
As multiplicidades podem ocorrer da seguinte maneira:
Tabela 2 – Indicadores de Mutiplicidade
Indicador Significado
0..1 Zero ou um
1 1 Apenas um
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.
subclasse
superclasse
“é um”
“é um tipo de”
Veículo
Terrestre Aéreo
Figura 3 – Superclasse e Subclasse
À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:
12
13
Revistas
Edicoes
+ codigo : int
+ titulo : string
+ tipo : string
+ edicao : Edicoes
+ SetEdicao(numEdicao : int, dataEdicao : date, numArtigos : int) : void
+ GetEdicao() : void
+ SetEdicao(numEdicao : int, dataEdicao : date, numArtigos : int) : void
+ GetEdicao() : void
+ numEdicao : int
+ dataEdicao : date
+ numArtigos : int
Figura 4 – Associação do tipo composiçã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 exem-
plo mais tradicional para isso é:
todo parte
agregação
Pedido
1 1..* Item
Figura 5 – Relacionamento de Agregação
Um exemplo completo:
Figura 6 –Diagrama de Classe de uma Escola
Fonte: cnx.org
13
UNIDADE Design Ágil
• Classe Aluno: o que inclui basicamente essa classe são os atributos nome, sexo, 
matrícula, dataNascimento. Todos esses atributos serão exclusivos, ou serão, 
serão todos de 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. 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;
• Professor da classe: basicamente é composto pelos atributos nome, sexo e 
registro. Os métodos dessa classe são: consultarTurma, lancarNota e realizar-
Frequencia. Todos os atributos da classe podem ser privados e precisos dos seus 
métodos Getter e Setter;
• Classe Turma: composto pelos atributos código, codigoAluno, codigoProfessor. 
Os métodos dessa classe são listarTurma, listarAlunos. Os atributos dessa classe 
são exclusivos;
• Classe Curso: é composto pelos atributos código e nome apenas e os métodos 
consultarCurso e incluirCurso. Os atributos são privados;
• Classe Disciplina: é composto pelos códigos e nome, e pelos métodos de con-
sultaDisciplina e inclusãoDisciplina;
• Classe DetalheTurma: é uma classe que auxilia no relacionamento da classe 
turma junto como classes Aluno e Professor. Essa classe é composta pelos atri-
butos 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 codificadosCurso e 
codigoTurma. Os atributos dessa classe são privados;
• DetalheDisciplina: é uma classe que auxilia no relacionamento da classe Disci-
plina junta a classe Curso. É composto pelos atributos Código e Disciplina. Seus 
atributos são privados (SANTOS, 2010, 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 requisitose seus atores.
14
15
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 pro-
cessos de negócios.
Cliente
Obter extrato
Realizar saque
Realizar
transferência
Fornecer
identi�cação
<<include>>
<<include>>
<<include>>
Figura 7 – Relacionamento <include>
• 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.
Escritor
<<extend>>
<<extend>>
Substituir texto
Corrigir ortogra�a
Editar documento
Figura 8 – Relacionamento <extend>
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;
15
UNIDADE Design Ágil
 » 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.
Visitante
Registrar-se
<<include>>
<<include>>
<<extend>>
Modi�car horário Adicionar pizzas
Modi�car quantidades
Ver cardápios
Efetuar login
Escolher horário
Criar pizza personalizada
Alterar ingredientes
Selecionar pizza do cardápio
Modi�car ingredientes
Cliente
Figura 9 – Diagrama simples de uma pizzaria. Subsistema 1
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 anterior-
mente (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, 2020, p. 2).
Atendente
Cadastrar pedido
Cadastrar cliente
Completar fornada
Dar baixa em pedidoDeterminar carga
Ver pedidos
Ver ingredientes necessários
Pizzaiolo
Cozinheiro
Figura 10 – Diagrama simples de uma pizzaria. Subsistema 2
16
17
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 de-
terminar 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, 2020, 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 deve ser 
escrita de forma a abranger todas as sequências de eventos, todos os cenários rela-
cionados 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:
17
UNIDADE Design Ágil
Quadro 1 – 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 inica-se quando o cliente deseja sanar sua dúvidas em relação aos serviços e produtos fornecidos
Atores Usuario, 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. Usúario abre a aba de chatbot:
1.1 Chatbot pede ao usuário que digite seu nome;
1.2 Usuário digita o nome;
1.3 Chatbot informa ao assuntos aos quais ele tem respostas;
1.4 Usuário digita suas dúvidas;
1.5 Chatbot imprime as respostas;
1.6 Usuário finaliza atendimento e avalia o chatbot.
Fluxo alternativo 1. Chatbot não resolve as perguntas;1.1 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 se-
quê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 li-
nhas 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.
• 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 fragmentode 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;
18
19
• 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 des-
truiçã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 mo-
mentos 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 frag-
mento 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, 2007, p. 3).
Figura 11 – Exemplo de Principais elementos do diagrama de sequência UML
Fonte: uml.diagrams.org
: AtorLeitor
dadosLeitor
veri�carLeitorCadastro( )
: Leitor
Curso Normal
Cursos Alternativos
1. O leitor fornece seus dados;
2. O sistema veri�ca se este leitor não
 está cadastrado;
3. O sistema adiciona novo leitor;
4. O sistema emite a msg1 ‘leitor
 cadastrado’.
Caso 1: o leitor já está cadastrado.
2. O sistema veri�ca se este leitor
 está cadastrado;
3. O sistema emite a msg1 ‘leitor já 
 está cadastrado’;
4. Finalizar caso de uso.
msg1 ‘Leitor já está cadastrado’
‘cadastrado’
Figura 12 – Exemplo de diagrama de sequência a partir de um caso de uso descritivo
19
UNIDADE Design Ágil
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Aula modelagem diagrama de classes
https://youtu.be/Q6D5ogS0iTE
Curso de UML – Diagrama de Casos de Uso – Exemplo Básico
https://youtu.be/tezLX9quOVc
Analise de sistema – Descricao do caso de uso criar orçamento
https://youtu.be/P9dSXw006Z0
 Leitura
Using Scrum Together with UML Models: A Collaborative University-Industry R&D Software Project
SANTOS, N; FERNANDES, J; CARVALHO, M; SILVA, P; FERNANDES, F; 
REBELO, M; BARBOSA, D; MAIA, P; COUTO, M e MACHADO, R. Using 
Scrum Together with UML Models: A Collaborative University-Industry R&D 
Software Project. 2016.
https://bit.ly/3jaSleP
20
21
Referências
DUARTE, J. Scrum Release do Produto: Planejando a cadência das entregas do 
produto. 2015. Disponível em: <https://www.gp4us.com.br/scrum-release-do-pro-
duto/>. Acesso em: 10/02/2020 .
SANTOS, J. C. F. dos. Criando Diagramas UML com o StarUML. 2010. Dispo-
nivel em: <https://cnx.org/contents/sKehW_Tl@1/Criando-Diagramas-UML-com-o-
-StarUML>. Acesso em: 10/05/2020.
21