ANALISE DE SISTEMA

Prévia do material em texto

A
N
Á
LISE D
E SISTEM
A
S
JAIME WOJCIECHOWSKI
Código Logístico
59856
Fundação Biblioteca Nacional
ISBN 978-65-582-1013-9
9 7 8 6 5 5 8 2 1 0 1 3 9
Análise de Sistemas 
Jaime Wojciechowski
IESDE BRASIL
2021
© 2021 – IESDE BRASIL S/A. 
É proibida a reprodução, mesmo parcial, por qualquer processo, sem autorização por escrito do autor e 
do detentor dos direitos autorais.
Projeto de capa: IESDE BRASIL S/A. Imagem da capa: Krasnopolski/Linas Sinkunas/Shutterstock
Todos os direitos reservados.
IESDE BRASIL S/A. 
Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200 
Batel – Curitiba – PR 
0800 708 88 88 – www.iesde.com.br
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
W828a
Wojciechowski, Jaime
Análise de sistemas / Jaime Wojciechowski. - 1. ed. - Curitiba [PR] : 
IESDE, 2021.
138 p. : il.
Inclui bibliografia
ISBN 978-65-5821-013-9
1. Análise de sistemas. 2. Métodos orientados a objetos (Computação). 
3. UML (Computação). I. Título.
21-69939 CDD: 005.117
CDU: 004.415.2
Jaime Wojciechowski Doutor em Informática Aplicada em Engenharia Florestal 
pela Universidade Federal do Paraná (UFPR). Mestre 
em Informática Aplicada em Inteligência Artificial pela 
Pontifícia Universidade Católica do Paraná (PUCPR). 
Graduado em Matemática (bacharelado e licenciatura) 
pela mesma instituição. Atua, desde 1994, como 
docente no ensino superior e ingressou na UFPR no 
ano de 2006, onde é professor titular das disciplinas 
de Análise e Projetos de Sistemas no curso superior de 
Tecnologia em Análise e Desenvolvimento de Sistemas; 
Modelagem Ágil de Software no curso de Especialização 
em Desenvolvimento Ágil de Software; Aprendizado 
de Máquina e Laboratório de Inteligência Artificial 
no curso de Especialização em Inteligência Artificial 
Aplicada; Sistemas Computacionais Aplicados no curso 
de Especialização em Manejo Florestal; e é vice-diretor 
do Setor de Educação Profissional e Tecnológica. Foi 
analista de sistemas em ambiente de desenvolvimento 
de grande porte (mainframe). Trabalhou na área de 
desenvolvimento e treinamento para a formação de 
novos programadores no Banco do Estado do Paraná 
(Banestado), no Itaú, no Santander Banespa e no HSBC 
Bank Brasil.
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
SUMÁRIO
1 Introdução à análise de sistemas e Levantamento de Requisitos 9
1.1 Introdução à análise de sistemas 9
1.2 Levantamento de Requisitos 17
1.3 Análise Orientada a Objetos (UML) 29
1.4 Métodos Ágeis aplicados ao desenvolvimento de sistemas 34
2 Casos de Uso e Histórias de Usuário 41
2.1 Diagrama de Caso de Uso 41
2.2 Níveis do Diagrama de Caso de Uso 48
2.3 Prototipação de telas 53
2.4 Histórias de Usuário 56
3 Objetos e classes 67
3.1 Objetos e classes 67
3.2 Relacionamentos entre as classes 73
3.3 Diagrama de Classes 80
3.4 Diagrama de objetos 87
4 Diagrama de Sequência 91
4.1 Elementos do Diagrama de Sequência 91
4.2 Práticas do Diagrama de Sequência 100
4.3 Operadores do Diagrama de Sequência 112
5 Diagramas suplementares da UML 118
5.1 Diagrama de Transição de Estados 118
5.2 Diagrama de Atividades 125
5.3 Diagrama de Pacotes 130
 Gabarito 135
APRESENTAÇÃOVídeo
O desenvolvimento de software é uma das tarefas mais fascinantes e 
necessárias atualmente. Em todas as áreas do conhecimento, do trabalho 
e da produção, os softwares são imprescindíveis. Usamos algum tipo de 
software na maioria das nossas atividades diárias, no uso do celular, nos 
carros, nos estudos, no trabalho e no lazer, dentre muitas outras tarefas do 
dia a dia. É impossível gerenciar uma empresa sem o uso de softwares, e o 
funcionamento de quase todos os aspectos da vida diária é administrado 
por eles.
Esta obra busca não só apresentar as teorias de análise que fundamentam 
a construção de softwares e os procedimentos adotados nas empresas 
que os produzem, mas também mostrar as ferramentas que podem ser 
aplicadas para informatizar um determinado processo de negócio. Portanto, 
o livro tem um cunho essencialmente prático, em que você terá contato com 
o embasamento do conceito e, em seguida, será levado a realizar práticas 
com estudos de caso reais a fim de aplicar efetivamente a técnica, tal qual se 
aplicam nas empresas de desenvolvimento de software.
Serão abordados os primeiros aspectos da modelagem, desde o 
Levantamento dos Requisitos, passando pelo embasamento de Métodos 
Ágeis e partindo para a explicação detalhada dos principais diagramas da 
Análise Orientada a Objetos (UML).
Ao final do estudo, você contará com diversas ferramentas práticas de 
modelagem de sistemas e terá condições de, com base em um determinado 
problema, fazer toda a atividade de modelagem usando os diagramas da UML.
Bons estudos!
Introdução à análise de sistemas e Levantamento de Requisitos 9
1
Introdução à análise de sistemas 
e Levantamento de Requisitos
As atividades de análise de sistemas são de extrema importância no 
processo de desenvolvimento de um software. Muitas vezes as empresas 
negligenciam essas atividades por diversos motivos. É consenso que exis-
te uma grande expectativa (e pressão) por parte dos clientes em receber 
o produto final que solicitaram, ou seja, um software pronto, contemplan-
do todas as suas solicitações e, não raro, resolvendo todos os problemas 
de negócio.
Diferentemente de muitos produtos que exigem um processo com-
pleto e muito bem formalizado para se chegar ao produto final, um 
software, muitas vezes por uma visão equivocada da equipe de desen-
volvimento, aceita que algumas etapas do processo de desenvolvimento 
sejam suprimidas, e mesmo assim se chega a um software “funcionando”. 
A palavra foi colocada entre aspas para indicar que é muito questionável 
entregar um software, mesmo que “funcionando”, se etapas do processo 
forem suprimidas.
Neste capítulo serão apresentadas as bases das teorias de análise, seu 
histórico e a motivação para que as teorias evoluam. Também veremos 
o ciclo de desenvolvimento de um sistema, a visão das fases em que são 
aplicadas essas teorias e qual sua importância no processo como um 
todo. Finalmente teremos o primeiro contato com o que se chama de 
Métodos Ágeis, conjunto de práticas que vem revolucionando a indústria 
de desenvolvimento de software.
1.1 Introdução à análise de sistemas
Vídeo As atividades de análise fazem parte do ciclo de desenvolvimento de um sis-
tema e têm um papel de extrema importância na qualidade do produto final. Os 
prejuízos causados pela entrega de um software cujas etapas não foram seguidas 
da maneira correta são praticamente intangíveis. É muito difícil medir os efeitos 
negativos da falta de planejamento e de tarefas realizadas sem os devidos proce-
dimentos formais.
Como medir as perdas do negócio de uma empresa com um software que fre-
quentemente apresenta erros e muitas vezes apresenta resultados que não são 
10 Análise de Sistemas
aqueles esperados? Como medir as perdas de um software de difícil manutenção, 
seja para conserto de erros ou simplesmente para acomodar novas funcionalida-
des? O que é mais barato para uma empresa: a correção de um erro em uma hora 
ou em três dias? A demora na correção de um erro pode ocorrer devido à estrutura 
do software ter sido mal construída, aos programas terem sido codificados sem 
um padrão, sem uma estruturação dos módulos, sem planejamento nem análise, 
sem uma modelagem dos processos, ou seja, o que se diz na prática: “saíram pro-
gramando direto”.
Esse é um grande erro que as empresas cometem. Um software mal construído 
será carregado por anos (e talvez décadas), sempre comtrabalho visualmente usando o quadro (conhecido como Kanban).
A equipe de desenvol-
vimento do Spotify é 
totalmente voltada aos 
Métodos Ágeis. Nela são 
aplicados praticamente to-
dos os valores e princípios 
do Manifesto Ágil. O vídeo 
Spotify Engineering Culture - 
Partes 1 e 2, produzido por 
eles, mostra a dinâmica da 
equipe de desenvolvimen-
to, bem como suas carac-
terísticas. A forma como 
trabalham é impressionan-
te, vale a pena conferir.
Disponível em: https://www.youtube.
com/watch?v=NoGhC1LaaAE. Acesso 
em: 17 mar. 2021.
Vídeo
Introdução à análise de sistemas e Levantamento de Requisitos 39
 • Ter equipes enxutas com até dez pessoas.
 • Nada de títulos de função: estudos demonstram que quando não são criados 
títulos para as pessoas que possam limitar o entendimento de seu papel den-
tro de uma equipe, elas trabalham melhor.
 • Priorização: quando várias coisas são prioridade, nada é uma prioridade. En-
tão, para que algo realmente seja feito, a metodologia Scrum propõe que as 
atividades devem ser priorizadas.
Essa foi uma breve introdução sobre o Scrum. Existem outros conceitos, papéis 
e práticas envolvidos que não serão trabalhados aqui.
CONSIDERAÇÕES FINAIS
Este capítulo trouxe um panorama geral das teorias de análise, como ocorreu 
sua evolução e por quais motivos. Com o objetivo de situar o leitor em qual ciclo as 
atividades se encaixam, mostrou como é o ciclo completo de desenvolvimento de 
um sistema.
Fizemos um detalhamento da primeira atividade da fase de Iniciação, cujo produto 
final, a Lista de Requisitos, será a base para a construção de todos os artefatos da UML.
Trouxemos, ainda, os aspectos gerais sobre a Análise Orientada a Objetos, os Mé-
todos Ágeis e o framework Scrum, que são os padrões da área de desenvolvimento de 
software na atualidade.
ATIVIDADES
1. A Análise Estruturada foi um avanço no processo de modelagem de um sistema, 
com a introdução de diagramas como Fluxograma, DFD e Modelo de Dados. Esses 
diagramas ajudavam o analista no entendimento e mapeamento da solução dos 
problemas de negócio. Porém, essa estrutura não evitava completamente os 
problemas nos softwares produzidos. Explique o principal problema dessa teoria 
no funcionamento dos softwares.
2. Explique qual é o propósito dos Diagramas de Caso de Uso, de Classes e de 
Sequência da UML.
3. Quais foram as motivações para que os Métodos Ágeis se tornassem padrão da 
indústria de desenvolvimento de software?
REFERÊNCIAS
BECK, K. et al. Manifesto for Agile Software development. 2001. Disponível em: http://www.agilemanifesto.
org/. Acesso em: 17 mar. 2021.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 12. ed. Rio de Janeiro: Elsevier, 2012.
COHN, M. Desenvolvimento de Software com Scrum. Porto Alegre: Bookman, 2011.
DE PAULA, G. B. Tudo sobre Metodologia Scrum: o que é e como essa ferramenta pode te ajudar a poupar 
tempo e gerir melhor seus projetos. Treasy, 14 fev. 2016. Disponível em: https://www.treasy.com.br/blog/
scrum/. Acesso em: 17 mar. 2021.
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2018.
KRUCHTEN, P. Introdução ao RUP - Rational Unified Process. Rio de Janeiro: Ciência Moderna, 2003.
LAUDON, K. C.; LAUDON, J. P. Gerenciamento de sistemas de informação. 3. ed. Rio de Janeiro: LTC, 2005.
MELO, A. C. Desenvolvendo aplicações com UML 2.2. Rio de Janeiro: Brasport, 2011.
40 Análise de Sistemas
PRESSMAN, R. S., MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: 
Bookman, 2016.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de software. Porto Alegre: 
Bookman, 2014.
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. São Paulo: Campus, 1994.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
STAIR, R. M.; REYNOLDS G. W. Princípios de Sistemas de Informações: uma abordagem gerencial. São Paulo: 
LTC, 2015.
SUTHERLAND, J. SCRUM: a arte de fazer o dobro do trabalho na metade do tempo. Rio de Janeiro: Sextante, 
2019.
VALENTE, M. T. Engenharia de software moderna. Princípios e práticas para desenvolvimento de software 
com produtividade. Leanpub, 2020. [e-book]
VAZQUEZ, C. E. Engenharia de Requisitos: software orientado ao negócio. São Paulo: Brasport, 2016.
YOURDON, E.; CONSTANTINE, L. L. Projeto estruturado de sistemas. São Paulo: Campus, 1992.
Casos de Uso e Histórias de Usuário 41
2
Casos de Uso e Histórias 
de Usuário
A fase de Elaboração, no ciclo de desenvolvimento de um sistema, 
corresponde ao momento de aplicação das teorias de análise de siste-
mas para que o ciclo seja modelado na forma de artefatos (documentos 
e diagramas) que demonstrem qual será a solução informatizada para o 
problema do cliente. Esses artefatos também irão delinear a arquitetura 
do software e como ele deve ser programado na fase de Construção.
Para a confecção desses artefatos, o analista de sistemas responsável 
por essa fase irá se basear em todas as informações coletadas na fase de 
Iniciação, por meio das atividades de Levantamento dos Requisitos.
Vimos que, na fase de Iniciação, o produto final foi uma Lista de 
Requisitos com especificações e regras de negócio. Neste capítulo, 
iremos construir os primeiros artefatos previstos na UML, o Diagrama 
de Caso de Uso, as Prototipações das telas (esboços) e a escrita das 
Histórias de Usuário.
Tais artefatos têm como objetivo dar uma visão funcional do sistema, 
detalhar seus processos e mostrar como será a solução informatizada em 
termos da organização dos seus Requisitos.
2.1 Diagrama de Caso de Uso
Vídeo O Diagrama de Caso de Uso tem como objetivo apresentar uma visão geral das 
funcionalidades do sistema, demostrando as entidades externas que terão acesso 
ao sistema e com quais funcionalidades cada entidade irá interagir (GUEDES, 2018; 
MELO, 2011).
Segundo Booch, Rumbaugh e Jacobson (2012, p. 263), “os diagramas de caso de 
uso são importantes para visualizar, especificar e documentar o comportamento 
de um sistema”.
Sua principal característica é a simplicidade em demonstrar graficamente tais 
funcionalidades, o que permite que seja compartilhado com o cliente para que se 
tenha uma visão do escopo do sistema e permita uma discussão em termos dos 
Requisitos que foram solicitados.
42 Análise de Sistemas
Por isso, esse diagrama pode e deve ser apresentado em reuniões com os clien-
tes, pois permite que sejam identificadas possíveis falhas na elaboração da Lista de 
Requisitos, percebidos Requisitos que não tenham sido identificados e, também, 
para deixar claro aquilo que o sistema não irá abordar (GUEDES, 2018).
2.1.1 Conceitos
Um Diagrama de Caso de Uso é composto de três elementos básicos: ator, caso 
de uso e relacionamento.
2.1.1.1 Ator
Os atores representam entidades externas ao sistema e que interagem com ele 
(DEBONI, 2003). Os atores fornecem e/ou recebem informações do sistema. Eles 
irão interagir com o sistema para satisfazer suas necessidades. Existem três tipos 
de atores:
São os atores mais fáceis de serem identificados. São as pessoas que irão 
manipular as telas, receber relatórios e fazer consultas aos dados.
Pessoas 
Em uma organização (empresa, indústria, loja, escritório, clube, dentre 
outros), um determinado órgão pode ser considerado um ator quando todas 
as pessoas desse órgão interagirem com o sistema. Por exemplo, em uma 
clínica médica, a Secretária, que atende aos pacientes que chegam para rea-
lizar consultas, exames e procedimentos, poderia ser considerada um ator 
perante o sistema de controle de consultas médicas da clínica. Note que, 
nesse exemplo, o paciente, os médicos e outros funcionários da clínica tam-
bém serão atores desse sistema.
Órgãos de uma organização 
Esse é o ator mais difícil de ser identificado. Quando construímos um 
software, é comum que ele tenha ligação com softwares externos, perten-
centes ou não à mesma organização. No exemplo anterior, digamos que 
existam dois sistemas na clínica médica, umsistema de consultas e um de 
exames. Se, no momento da consulta, o médico necessita saber os dados 
dos exames do paciente, o sistema de consulta iria acessar o sistema de 
exames para buscar essa informação, com isso o sistema de exames faz 
o papel de ator perante o sistema de consultas. No mesmo exemplo, se 
o sistema de consultas precisa de uma autorização do plano de saúde, o 
Plano de saúde também faz o papel de ator perante o sistema de consultas.
Outros sistemas informatizados
Casos de Uso e Histórias de Usuário 43
A Figura 1 ilustra os tipos de atores e suas interações com o sistema. Sob o pon-
to de vista do sistema de consultas, os bonecos representam seus atores.
Figura 1
Tipos de atores
Fonte: Elaborada pelo autor.
Órgão da organização
Pessoa
Paciente
Médico
Secretária
Sistema de 
exames
Plano de 
saúde
Sistema de 
consultas
Outros sistemas 
informatizados
2.1.1.2 Caso de uso
Um caso de uso representa um determinado Requisito, é uma funcionalidade 
completa conforme percebida pelo ator. Ele fornece um resultado observável ao 
ator e contribui para que o ator atinja seu objetivo.
Os casos de uso derivam da Lista de Requisitos. Normalmente um Requisito se 
transforma em um caso de uso, mas pode ocorrer de um Requisito se transformar 
em vários casos de uso, se isso for mais apropriado para uma melhor estruturação 
da solução.
A Figura 2 mostra um conjunto de Requisitos de um sistema para controle de 
uma biblioteca e como esses Requisitos poderiam ser organizados em casos de 
uso. A sigla UC antes do nome do caso de uso é uma abreviatura para use case (caso 
de uso em inglês).
Figura 2
Requisitos x casos de uso
Fonte: Elaborada pelo autor.
R1 - Emprestar Livro
UC2 - Emprestar Livro
UC1 - Pesquisar Livro
R2 - Devolver Livro
R3 - Cadastrar Usuário
UC4 - Imprimir Recibo
UC3 - Devolver Livro
UC6 - Manter Usuário
UC5 - Pesquisar Usuário
44 Análise de Sistemas
Nessa figura, digamos que o Requisito R1 - Emprestar livro seja implementado 
usando duas telas. Na primeira, o usuário faria uma pesquisa do livro que deseja 
emprestar; após a escolha do livro nessa tela, o sistema poderia apresentar uma 
segunda tela para que o empréstimo fosse efetivado.
Esse é um exemplo de como um Requisito pode se transformar em mais de um 
caso de uso. Uma dica é que cada caso de uso se transforme em uma tela, pois 
isso faz com que a sua implementação seja mais simples. Isso não é uma norma, 
pois podem existir exceções, em que um caso de uso pode ser implementado com 
várias telas ou o inverso, uma tela ser especificada em vários casos de uso.
Finalmente, por padrão e pelo caso de uso se tratar de uma função (ou ação), o 
nome do caso de uso sempre deve começar com um verbo no infinitivo seguido de 
um substantivo, por exemplo, “cadastrar cliente”.
2.1.1.3 Relacionamento
Os relacionamentos têm por objetivo fazer as ligações entre os atores e casos 
de uso. Com isso, é possível saber com quais casos de uso um determinado ator vai 
se relacionar e estruturar os atores conforme seus tipos a fim de detalhar melhor 
suas responsabilidades. Também é possível estruturar os casos de uso separando 
suas responsabilidades e encontrando a melhor solução.
Existem cinco tipos de relacionamentos que podem ser utilizados em um Dia-
grama de Caso de Uso.
11 Ligação
As ligações são feitas entre atores e casos de uso para indicar exatamente com 
quais casos de uso cada ator irá interagir.
A ligação só indica que o ator irá passar ou receber informações do caso de uso 
e que terá acesso a ele.
A ligação é representada por uma linha simples, sem setas e nem legendas. Na 
Figura 3, temos um exemplo do ator Secretária ligado ao caso de uso Marcar con-
sulta indicando que esse ator tem acesso a essa funcionalidade do sistema.
Figura 3
Exemplo de ligação entre ator e caso de uso
Fonte: Elaborada pelo autor.
Secretária
Marcar 
consulta
22 Herança de atores
O conceito de herança é uma das bases da Análise Orientada a Objetos. Ele é 
aplicado não só para atores, mas para casos de uso e, principalmente, para as clas-
ses (que serão abordadas em outro momento).
Você é considerado um ator perante 
o sistema do WhatsApp, mais espe-
cificamente no caso de uso Enviar 
mensagem. Também no Facebook 
somos atores no caso de uso Fazer 
postagem.
Curiosidade
Casos de Uso e Histórias de Usuário 45
Segundo Rumbaugh et al. (1994), a herança (de ator) é um relacionamento entre 
um ator e uma ou mais versões refinadas dele. Assim, ela é identificada quando 
existem “tipos” desse ator. Um ator com características mais gerais tem seus tipos 
mais específicos.
Como exemplo, imagine que na clínica existem os médicos (que são atores do 
sistema de consultas). Sabemos que existem diversas especialidades de médicos, 
ou seja, vários tipos. Assim, caso seja necessária a representação desses tipos, po-
deríamos usar o conceito de herança nesse ator.
A herança é representada por uma linha com uma seta vazada saindo dos ato-
res mais específicos e apontando para o ator mais geral. A Figura 4 mostra o exem-
plo de um médico e dois tipos.

Figura 4
Exemplo de herança de atores
Fonte: Elaborada pelo autor.
Médico
Médico ortopedista Médico dermatologista

Nesse exemplo, tanto ortopedista como dermatologista são tipos 
de médicos. Então, no topo foi colocado o ator mais geral, o Médico, e 
abaixo os dois tipos. As setas estão saindo dos tipos mais específicos e 
apontam para o mais geral (médico).
Vamos supor que exista um caso de uso Registrar doenças de 
pele. Ora, podemos perceber que esse caso de uso é específico para 
doenças relacionadas à pele de uma pessoa, então ele só deve ser 
manipulado pelo médico especialista em pele, ou seja, um derma-
tologista. Se, no Diagrama de Caso de Uso, tivermos somente o ator 
Médico e fizermos a ligação desse caso de uso a esse ator, o diagra-
ma estaria representando que qualquer médico pode acessar o caso 
de uso Registrar doenças de pele. Isso iria ferir uma regra de negó-
cio, pois não teria sentido um médico de outra especialidade aces-
sar esse caso de uso. Assim, para resolver essa inconsistência, seria 
necessário usar o relacionamento de herança, fazendo com que o 
Médico dermatologista fique ligado ao seu caso de uso específico. A 
Figura 5 ilustra essa situação.
Fonte: Elaborada pelo autor.
Figura 5
Exemplo de ligação de caso de uso com um ator 
específico
Médico
Médico 
ortopedista
Médico 
dermatologista
Registrar 
doenças de 
pele

46 Análise de Sistemas
33 Herança de casos de uso
Assim como temos herança de atores, podemos ter herança de casos de uso 
seguindo o mesmo conceito. Um caso de uso mais geral pode ter diversos tipos 
mais específicos.
Como exemplo, imagine o procedimento de saque de di-
nheiro em uma instituição bancária. Se tivermos o caso de 
uso Sacar dinheiro e considerarmos que em um banco esse 
saque pode ser realizado de duas formas, o saque no caixa 
eletrônico e o saque no caixa da agência, temos então dois 
tipos de saque. Nesse caso, podemos relacionar esses casos 
de uso por meio de herança. A Figura 6 mostra o exemplo de 
um saque e seus dois tipos.
Nesse exemplo, podemos perceber que o caso de uso Sa-
car dinheiro é o mais geral e nele estão as informações de 
um saque independentemente de onde é realizado.
44 Include (ou uso)
O relacionamento de Include (ou uso) é exclusivo para ser utilizado entre casos 
de uso.
Quando queremos separar uma parte dos procedimentos de um caso de uso 
criando um novo caso de uso com essa parte, esses dois casos de uso devem ficar 
ligados por meio de um Include.
Esse relacionamento funciona como a chamada de uma função (nas linguagens de 
programação) em que o caso de uso chama esse novo caso de uso, que realiza seus 
procedimentos e retorna ao principal para que ele continue seus procedimentos.
O Include é indicado quando essa parte pode ser usada por outros casos de uso, 
se necessário.
O símbolo de Include no Diagrama de Caso de Uso é uma seta pontilhada apon-tada para o caso de uso chamado e com a legenda > na linha, conforme 
mostra a Figura 7.
Como exemplo, imagine novamente o procedimento de saque de dinheiro em 
uma instituição bancária. Em todo saque, é necessário 
validar a senha do cliente. Porém, esse procedimento 
(de validação de senha) é feito em outros casos de uso, 
por exemplo, Emitir extrato. Então, para que não seja ne-
cessário repetir a validação da senha em todos esses ca-
sos de uso, fazemos um novo caso de uso Validar senha, 
e todos aqueles que necessitarem dessa validação serão 
ligados a ele por meio desse relacionamento. A Figura 7 
mostra esse exemplo.
Figura 6
Exemplo de herança de casos de uso
Fonte: Elaborada pelo autor.
Sacar dinheiro
Sacar no caixa 
da agência
Sacar no caixa 
eletrônico
Fonte: Elaborada pelo autor.
Figura 7
Exemplo da utilização do Include
Sacar dinheiro
Emitir extrato
Validar senha
>
>
Casos de Uso e Histórias de Usuário 47
A Figura 8 ilustra a situação em que o caso de uso “pagar parcela do emprés-
timo” separou os procedimentos de calcular parcela em um novo caso de uso so-
mente para estruturar melhor as duas funções.
Fonte: Elaborada pelo autor.
Figura 8
Exemplo de Include
Pagar parcela do 
empréstimo
Calcular parcela>
Os casos de uso chamados pelo Include não se enquadram na dica de que um 
caso de uso deve corresponder a uma tela, ou seja, o caso de uso chamado pelo 
Include pode ou não corresponder a uma tela.
55 Extend (ou extensão)
O relacionamento de Extend (ou extensão) também é exclusivo para ser usado 
entre casos de uso.
Seu funcionamento é muito parecido com o Include, ou seja, existe a chamada 
de um caso de uso por outro para que se realize um determinado procedimento e 
retorne ao caso de uso original.
Porém, no caso de um Extend, essa chamada ocorre segundo uma deter-
minada condição, ou seja, não existe a obrigatoriedade de que o caso de uso 
chamador execute os procedimentos do caso de uso chamado, e essa chamada 
vai acontecer se uma determinada condição for verdadeira ou se, no caso de 
uma tela, uma determinada ação for realizada para que o segundo caso de uso 
seja chamado.
O símbolo de Extend no Diagrama de Caso de Uso é uma seta pontilhada apon-
tada para o caso de uso chamador (é o contrário do relacionamento de Include) e 
com a legenda > na linha, conforme mostra a Figura 9.
Como exemplo, imagine uma concessionária de automóveis e o caso de uso 
Vender automóvel. Suponha que o gerente impôs uma regra de negócio dizendo 
que os automóveis com valor abaixo de R$ 50.000,00 podem ser vendidos sem ne-
nhuma verificação das informações do cliente. Porém, caso o valor do automóvel 
seja maior que R$ 50.000,00, o sistema deve consultar o crédito do cliente para 
verificar se ele tem alguma inadimplência ou se o seu nome se encontra com algum 
impedimento em instituições financeiras.
A Figura 9 mostra esse exemplo.
Fonte: Elaborada pelo autor.
Figura 9
Exemplo da utilização do Extend
Vender automóvel
Consultar 
crédito do 
cliente
>
48 Análise de Sistemas
Nesse exemplo, o caso de uso Consultar crédito do cliente pode ou não ser 
chamado e isso vai depender de a condição “valor do automóvel maior que 
R$ 50.000,00” ser ou não verdadeira. Quando isso ocorre, temos uma situação do 
uso do Extend.
Outro exemplo: imagine uma tela com alguns botões que levam a outras telas. 
No acesso à primeira tela (primeiro caso de uso), o usuário pode ou não clicar nos 
botões que levam às outras telas (outros casos de uso relacionados com Extend). 
Ou seja, o caso de uso da tela principal pode ou não chamar os casos de uso das 
demais telas, o que caracteriza esse relacionamento.
Os relacionamentos no Diagrama de Caso de Uso podem ser utilizados para me-
lhor estruturar a solução e demonstrar graficamente como será o encadeamento 
das telas, bem como a interação entre os casos de uso. Eles fornecem informações 
importantes sobre o encadeamento das telas do sistema.
2.2 Níveis do Diagrama de Caso de Uso
Vídeo Os Métodos Ágeis nos mostram a necessidade de se construir os artefatos da 
análise (diagramas ou documentos) na medida em que tenham utilidade no pro-
cesso de desenvolvimento. Então, dependendo dessa utilidade, o Diagrama de 
Caso de Uso pode ser construído em dois níveis: o nível 1, mais geral, e o nível 2, 
mais detalhado.
2.2.1 Nível 1 do Diagrama de Caso de Uso
Nesse nível, não devemos utilizar os relacionamentos de herança de atores ou 
casos de uso, Include e Extend. A ideia desse nível é que se tenha uma visão mais 
geral, sem muito detalhamento. Nele, os casos de uso não necessitam correspon-
der a uma tela (conforme a dica dada na seção anterior).
A Figura 10 ilustra um Diagrama de Caso de Uso de nível 1. Note que existe so-
mente o ator, o caso de uso e uma ligação entre eles.
Figura 10
Exemplo de diagrama de nível 1
Fonte: Elaborada pelo autor.
Cliente
Comprar 
passagem
aérea
Cadastrar voo
Empresa aérea
2.2.2 Nível 2 do Diagrama de Caso de Uso
O objetivo desse nível é fazer um detalhamento dos casos de uso, em que cada 
um irá corresponder a uma tela física. Para isso, pode-se utilizar todos os cinco 
tipos de relacionamentos do diagrama.
A Figura 11 ilustra um Diagrama de Caso de Uso de nível 2. É um detalhamento 
do diagrama da Figura 10. Podemos supor que o caso de uso Comprar passagem 
aérea foi dividido em três novos casos de uso (três telas físicas): Pesquisar voo, 
Casos de Uso e Histórias de Usuário 49
Selecionar voo e Emitir passagem aérea. Também o caso de uso Cadastrar voo foi 
dividido em Pesquisar voo e Manter voo.
Figura 11
Exemplo de diagrama de nível 2
Fonte: Elaborada pelo autor.
Cliente
Pesquisar voo
Manter voo
Selecionar voo
Emitir 
passagem 
aérea
Empresa aérea >
>
>
Os relacionamentos utilizados devem refletir a navegação entre as telas. Por 
exemplo, entre os casos de uso Pesquisar voo e Manter voo foi utilizado o relacio-
namento de Extend por ser opcional essa navegação entre as duas telas, ou seja, se 
a empresa aérea acessar o caso de uso Pesquisar voo, ela pode ou não escolher o 
acesso para a tela Manter voo (condição do Extend). Se o cliente acessar esse caso 
de uso, a condição é de que clientes não têm autorização para Manter voo (atuali-
zar os dados de um voo).
Por outro caminho, no processo de Comprar passagem aérea foi utilizado o 
relacionamento de include entre os casos de uso Pesquisar voo, Selecionar voo e 
Emitir passagem aérea, já que sempre irá ocorrer essa navegação entre as telas 
(considerando que a passagem efetivamente será comprada).
2.2.3 Estudo de caso – Escola de Natação
O estudo de caso a seguir tem como objetivo mostrar o passo a passo da cons-
trução do Diagrama de Caso de Uso, desde a identificação dos atores e casos de 
uso, passando pelo nível 1 do diagrama e, finalmente, chegando à construção do 
nível 2 com todo o detalhamento.
Iremos utilizar o exemplo da Escola de Natação, considerando a Lista de Re-
quisitos desse problema, que é o produto necessário para iniciar a construção do 
Diagrama de Caso de Uso.
Quadro 1
Lista de Requisitos da Escola de Natação completa
Requisito Descrição Regras de negócio
R1 – Manter cadastro dos alu-
nos
Permitir o cadastro completo dos 
alunos.
Permitir pesquisar, incluir, alterar e consultar.
Não permitir a exclusão de um aluno, somente 
marcar como inativo.
R2 – Manter cadastro dos pro-
fessores
Permitir o cadastro completo dos 
professores.
Permitir pesquisar, incluir, alterar, excluir e 
consultar.
(Continua)
50 Análise de Sistemas
Requisito Descrição Regras de negócio
R3 – Manter cadastro das tur-
mas
Permitir o cadastro completo das 
turmas, a modalidade (natação ou 
hidroginástica), dias/horários e o 
professor responsável.
Não permitir o cadastro de duas turmas da 
mesma modalidade no mesmo horário.
R4 – Matricular alunos. Matricular os alunos nas turmas.
Pessoas com mais de 80 anos só podem se 
matricularna modalidade hidroginástica.
R5 – Registrar frequência
Registrar frequência no diário de 
classes de cada aula.
Fonte: Elaborado pelo autor.
De posse dessa Lista de Requisitos, podemos começar identificando quais se-
riam os atores desse problema, que poderiam ser:
 • o atendente da escola;
 • os professores.
Podemos relacionar cada Requisito a um caso de uso somente alterando o 
nome para o padrão dos nomes dos casos de uso (verbo no infinitivo seguido de 
um substantivo).
2.2.3.1 Diagrama de Caso de Uso de nível 1
A Figura 12 mostra o diagrama de nível 1. Note que nesse diagrama não foram 
utilizados relacionamentos entre casos de uso. Esse é um Requisito do diagrama de 
nível 1, justamente para dar uma ideia geral dos Requisitos.
Figura 12
Diagrama de Caso de Uso nível 1 – Escola de Natação
Fonte: Elaborada pelo autor.
Professor
Registrar 
frequência
Atendente
Cadastrar 
aluno
Cadastrar 
professor
Cadastrar 
turma
Realizar 
matrícula
2.2.3.2 Diagrama de Caso de Uso de nível 2
Para entendermos como funciona a passagem do nível 1 para ao nível 2, preci-
samos agora começar a pensar como serão os esboços das telas do sistema, pois 
nosso objetivo é que cada caso de uso represente uma tela física do sistema.
Vamos usar como exemplo o primeiro caso de uso Cadastrar aluno. Ora, o ter-
mo cadastrar não se resume somente ao ato de incluir um novo aluno no cadastro, 
Casos de Uso e Histórias de Usuário 51
e sim a todas as operações que podem ser feitas sobre os alunos: incluir, alterar, 
excluir, consultar e pesquisar. Então, precisamos organizar uma ou mais telas que 
sejam amigáveis ao usuário e que consigam cobrir essas cinco operações sobre os 
dados de um aluno.
A seguir, temos uma proposta de solução de telas que consegue cobrir essas 
cinco operações. Trata-se de uma sugestão, pois existem muitas formas de se fazer 
essa organização. Essa é a forma mais comum encontrada nos sistemas.
A solução para esse caso seria construir duas telas, a primeira chamada Pesqui-
sar alunos e a segunda, Manter alunos, como mostram as Figuras 13 e 14.
Figura 13
Esboço da tela Pesquisar alunos
Fonte: Elaborada pelo autor.
Nome CPF Telefone Ações
Joaquim José da Silva Xavier 12345678901 98765-8752 Alterar Excluir
Patricia Amaral 98765432101 99987-8723 Alterar Excluir
Novo Aluno
Pesquisar alunos
Escola de Natação
Voltar Pesquisa:
Figura 14
Esboço da tela Manter alunos
Fonte: Elaborada pelo autor.
Manter alunos
Escola de Natação
Nome:
CPF
Telefone:
Endereço:
Salvar Voltar
52 Análise de Sistemas
A dinâmica das duas telas para cobrir as cinco operações seria a seguinte:
1. Primeiramente o ator Atendente teria acesso à tela Pesquisar alunos.
2. Para o procedimento de inclusão de um novo aluno, o atendente pressiona 
o botão “novo aluno” nessa tela. O sistema apresenta a segunda tela, Manter 
alunos. O atendente preenche os dados do aluno e pressiona o botão “salvar”.
3. Para o procedimento de alteração dos dados de um determinado aluno já 
cadastrado, o atendente encontra esse aluno na lista (pode utilizar o campo 
de filtro “pesquisa” no canto superior direito) e, na linha do aluno que deseja 
alterar, pressiona o botão “alterar”. O sistema apresenta a segunda tela, 
Manter alunos, só que agora colocando os dados do aluno escolhido nos 
campos correspondentes. O atendente então altera os dados que desejar e 
pressiona o botão “salvar”.
4. Para o procedimento de exclusão de um aluno já cadastrado, o atendente 
encontra esse aluno na lista (pode utilizar o campo de filtro “pesquisa” no 
canto superior direito) e, na linha do aluno correspondente, pressiona o 
botão “excluir”. Nesse caso, o sistema nem chama a segunda tela, somente 
apresenta uma mensagem de confirmação da exclusão na primeira tela e o 
atendente confirma. O sistema exclui o aluno e refaz a lista de alunos sem ele.
5. No procedimento de consulta, o atendente deseja somente visualizar 
os dados do aluno. Para isso, ele clica sobre qualquer dado do aluno que 
deseja consultar e o sistema apresenta a segunda tela, Manter alunos, só que 
agora com todos os dados do aluno escolhido nos campos correspondentes 
somente com a opção de visualização. Por fim, o atendente pressiona o botão 
“voltar” para retornar à tela de pesquisa.
6. A pesquisa é o ato de visualizar a lista de alunos, seja ela com todos os 
alunos ou somente alguns. Para isso, a primeira tela de Pesquisar alunos já 
apresenta inicialmente todos os alunos. Caso o atendente queira consultar 
alunos com um determinado argumento, basta colocar esse argumento no 
campo de pesquisa.
Essa organização de telas do caso de uso Cadastrar aluno constante no diagra-
ma de nível 1 foi importante porque foi possível verificar que esse caso de uso, 
por imposição de uma organização de tela, deu origem a dois novos casos de uso, 
Pesquisar alunos e Manter alunos.
Assim, na construção do diagrama de nível 2, esses dois novos casos de uso 
irão substituir o caso de uso Cadastrar aluno. Como eles estão interligados pelas 
ações que podem ser realizadas na primeira tela chamando a segunda, os casos 
de uso então devem ser ligados no diagrama de nível 2 com o relacionamento de 
extend, já que, dependendo da operação, a segunda tela será ou não chamada.
Todos os casos de uso do tipo Cadastrar... terão a mesma estrutura, então o 
Diagrama de Caso de Uso de nível 2 ficará conforme mostra a Figura 15.
Em banco de dados, as operações 
(incluir, alterar, excluir, consultar 
e pesquisar) realizadas sobre um 
determinado elemento (no exemplo, 
um aluno) é comumente chamada 
de CRUD, um acrônimo que significa 
Create, Read, Update, Delete.
Curiosidade
Casos de Uso e Histórias de Usuário 53
Figura 15
Diagrama de Caso de Uso nível 2 – Escola de Natação
Fonte: Elaborada pelo autor.
Professor
Registrar 
frequência
Atendente
Pesquisar 
aluno
Manter aluno
Pesquisar 
professor
Pesquisar 
turma
Manter turma
Realizar 
matrícula
Manter 
professor
>
>
>
Com isso, mostramos como estruturar o Diagrama de Caso de Uso em dois 
níveis para melhor demostrar graficamente os Requisitos do sistema e o encadea-
mento das suas telas.
2.3 Prototipação de telas
Vídeo Nesta seção, iremos aprender como fazer protótipos de telas de um sistema. 
Criar protótipos de telas significa desenhar os esboços que serão efetivamente 
construídos usando as linguagens de programação. A Prototipação é de grande 
importância, já que construir as telas usando a tecnologia para a qual o software 
é programado (linguagem de programação) é muito mais difícil e requer que os 
programadores façam esse trabalho.
Os protótipos de telas são criados pelos analistas de sistemas que participaram 
da fase de Levantamento de Requisitos e têm ampla visão do negócio e da solução 
informatizada que será dada ao problema.
2.3.1 Objetivos da Prototipação
Fazer protótipos das telas do sistema torna muito fácil a avaliação por parte do 
cliente. Esse é o principal objetivo desse trabalho.
O cliente recebe um esboço que pode ser alterado e ajustado rapidamente. É 
possível corrigir erros de layout da tela que não tinham sido bem entendidos e 
ajustes de posicionamento dos seus componentes para que a tela seja amigável e 
funcional no seu uso.
54 Análise de Sistemas
Além disso, os protótipos são feitos em ferramentas que facilitam essa manu-
tenção, que muitas vezes pode ser feita durante as reuniões de apresentação, cujo 
resultado alterado já pode ser avaliado e aprovado no mesmo momento.
2.3.2 Componentes de um protótipo de tela
Existem diversos componentes que podem ser utilizados na construção de te-
las, cada um com uma finalidade específica. Esses componentes também ajudam 
na estruturação da tela e na facilitação de seu uso.
Atualmente os softwares são executados em diversas plataformas e disposi-
tivos, como computadores, tablets, celulares e até mesmo televisores, mídias de 
automóveis etc.
A seguir são apresentados vários componentes de telaque podem ser utiliza-
dos nos protótipos, bem como a função de cada um deles:
Esse componente é o mais simples e é utilizado quando se deseja escre-
ver um texto na tela, seja em títulos e textos quaisquer ou para legenda de 
campos de entrada.
Label
O campo de entrada é utilizado quando se deseja que o usuário digite um 
determinado conteúdo de texto ou número no campo da tela.
Text field
São botões disponíveis na tela para o usuário pressionar levando o siste-
ma a realizar alguma ação.
Button
É utilizado quando se deseja o calendário de meses, inclusive com nave-
gação entre as datas.
Calendar
É utilizado quando se deseja apresentar uma lista de valores para que o 
usuário selecione uma ou mais opções.
Check box
É utilizado quando se deseja mostrar dados em forma de tabelas.
Grid
Casos de Uso e Histórias de Usuário 55
É utilizado quando se deseja a entrada de uma data na tela, porém com a op-
ção de apresentação de um calendário e a possibilidade de escolha dessa data.
Date chooser
É utilizado quando se deseja montar menus de opções para escolha do 
usuário que remetem a outras telas.
Menu bar
Assim como o text field, é utilizado quando se deseja que o usuário digite 
um determinado conteúdo de texto, porém, nesse componente, é possível 
escrever um texto com várias linhas, inclusive dando a possibilidade de di-
mensionar a área.
Text area
É utilizado quando se deseja apresentar uma lista de valores para que o 
usuário selecione apenas uma opção. Normalmente a primeira opção fica 
visível como primeira da lista e, ao pressionar uma seta no componente, a 
lista é aberta e apresenta-se as demais opções.
Combo box
A Figura 16 apresenta um exemplo de cada um desses componentes.
Figura 16
Esboço da tela Pesquisar alunos
Fonte: Elaborada pelo autor.
Nome CPF Telefone Ações
Joaquim José da Silva Xavier 12345678901 98765-8752 Alterar Excluir
Patricia Amaral 98765432101 99987-8723 Alterar Excluir
Pesquisar Alunos
Escola de Natação
Novo aluno Voltar Pesquisas:
Abrir documento
Salvar
Opção1
Opção 2
Opção 3
Sair
Opção1
Opção 2
Opção 3
Casado
Solteiro
Divorciado
D
J A N E I R O
T Q SS Q S
Label
Button
Calendar
Check box
Data chooser
Grid
Combo box
Menu bar
Text Area
Text field
56 Análise de Sistemas
Existem muitos outros componentes de tela para usos mais específicos, aqui 
foram explicados os principais.
O uso correto desses componentes nos locais apropriados é de grande impor-
tância para o sucesso do software. Para a maioria dos clientes, uma tela amigável é 
a propriedade do software. De nada adianta construirmos um software que atenda 
perfeitamente às necessidades funcionais do sistema se ele tiver usabilidade difícil 
e aparência ruim.
Um software muito utilizado 
para Prototipação de tela 
chama-se Balsamiq. Nele, 
você encontra diversos com-
ponentes usados em telas 
web e em aplicativos mobile.
Disponível em: www.balsamiq.com. 
Acesso em: 17 mar. 2021.
Curiosidade
2.4 Histórias de Usuário
Vídeo O Diagrama de Caso de Uso e os protótipos de tela nos dão uma boa ideia 
de como serão os Requisitos. Porém, a tela será programada por um membro da 
equipe especialista na tecnologia que será utilizada (linguagens de programação, 
componentes de software, bancos de dados, entre outros), que teve pouca (ou ne-
nhuma) participação na fase de Levantamento de Requisitos e conhecimento do 
negócio. Isso é normal e até é importante que o processo ocorra dessa forma. Por-
tanto, o desafio do analista de sistemas nesse momento é fazer com que o progra-
mador entenda exatamente o que deve ser programado, tanto o funcionamento da 
tela quanto as regras de negócio que devem ser verificadas para que o Requisito 
seja entregue exatamente como foi solicitado.
As Histórias de Usuário, então, entram nessa fase como um instrumento de 
detalhamento de cada um dos casos de uso (telas) para que o documento seja re-
passado ao programador e transformado num programa de software.
Repassar apenas o diagrama e os desenhos de tela ao programador não é o su-
ficiente para lhe dar condições de entender e programar a tela. Algumas empresas 
acreditam que apenas dizer (verbalmente) ao desenvolvedor o que ele deve fazer 
para programar a tela seja suficiente, porém o desenvolvimento de um software 
é um processo complexo e exige uma comunicação eficaz entre os membros da 
equipe (HELM; WILDT, 2014).
Assim, o próximo passo do processo de modelagem é escrever Histórias de 
Usuário para que sejam repassadas aos programadores da equipe.
Para cada caso de uso do Diagrama de Caso de Uso de nível 2 (ou de nível 1 caso 
só tenha sido feito esse), o analista deve fazer o seu detalhamento por meio de 
uma História de Usuário, conforme o documento que será explicado na sequência.
2.4.1 Construção de uma História de Usuário
A seguir, veremos a estrutura de uma História de Usuário, os tópicos que devem 
constar e o conteúdo de cada tópico.
11 Nome e descrição
O nome da História deve ser o mesmo nome do caso de uso do Diagrama de 
Caso de Uso de nível 2 (ou nível 1). Ele deve iniciar com a sigla HU seguida de um 
número sequencial:
Casos de Uso e Histórias de Usuário 57
HU000 – Nome da História de Usuário
Em seguida, devemos fazer uma descrição no seguinte formato:
Sendo 
Quero 
Para 
Quem quer
O que quer
Por que quer
Nessa descrição, o ator deve ser aquele que está ligado ao caso de uso no Dia-
grama de Caso de Uso (Quem quer).
Já a funcionalidade deve ser o nome do caso de uso (O que quer).
O benefício deve ser uma explicação ou justificativa daquilo que a História irá con-
tribuir para o processo ou agregar valor ao negócio do cliente. É uma frase que mos-
tra ao cliente o quanto será importante a implementação da História (Por que quer).
Exemplo:
HU001 – Realizar matrícula
Sendo um aluno da escola
Quero realizar matrícula
Para estar regularizado e iniciar a atividade escolhida
22 Desenho da tela
Nesse tópico deve ser colocado o desenho da tela conforme o protótipo que foi 
feito para ela.
33 Critérios de aceitação
Os critérios de aceitação são verificações que o sistema deve fazer para conside-
rar que a História está atendendo aos Requisitos do cliente.
Uma História deve ter uma série de critérios para que seja considerada aceita 
pelo cliente.
Os critérios dizem o que a História deve fazer, ou seja, quais os procedimentos 
da tela para que se atinja o seu objetivo, e também o que não deve fazer, ou seja, 
quais consistências devem ser realizadas para evitar erros.
A História é considerada pronta somente após todos os critérios serem 
verificados.
Esse tópico deve conter somente a relação dos critérios no seguinte formato:
Critério 
58 Análise de Sistemas
Como exemplos de critérios de aceitação da História de Usuário, podería-
mos ter:
Critério: não deve aceitar CPF em branco ou inválido.
Critério: não deve aceitar matrícula para aluno não cadastrado.
Critério: deve efetivar a matrícula.
44 Critérios de aceitação – detalhamento
Após a escrita da lista de critérios de aceitação, deve-se fazer um detalhamento 
de cada um deles. Esse detalhamento tem por objetivo orientar o programador 
de como eles devem ser programados e, principalmente, quais ações devem ser 
tomadas para cada critério.
O detalhamento dos critérios deve ter o seguinte formato:
Critério 
Dado que 
Quando 
Então 
Como exemplo de um critério de aceitação da História de Usuário detalhado, 
poderíamos ter:
Exemplo 1:
Critério não deve aceitar CPF em branco ou inválido.
Dado que foi informado um CPF Inválido.
Quando o aluno pressiona o botão “Efetivar Matrícula”.
Então o sistema apresenta a mensagem “CPF Inválido”.
E o sistema não efetiva a matrícula.
Exemplo 2:
Critério não deve aceitar CPF com Dígito Verificador incorreto.
Dado que foi informado um CPF com DV incorreto (R1).
Quando o aluno pressiona o botão “Efetivar Matrícula”.
Então o sistema apresenta a mensagem“CPF Inválido”.
E o sistema não efetiva a matrícula.
Casos de Uso e Histórias de Usuário 59
Exemplo 3:
Critério deve efetivar a matrícula.
Dado que não houve inconsistências de campos.
Quando o aluno pressiona o botão “Efetivar Matrícula”.
Então o sistema salva os dados da matrícula.
E o sistema apresenta a mensagem “Matrícula 
 Realizada Com Sucesso”.
55 Regras de negócio
As regras de negócio explicam a maneira de realizar certos procedimentos. É 
uma explicação de como deve ser realizada uma determinada ação. Elas serão co-
locadas quando não estiver clara a maneira de se programar uma ação.
Note que no Exemplo 2 foi colocado (R1) no final da sentença “Dado que”. Essa 
é uma referência à Regra 1 que deve ser colocada nesse tópico para explicar como 
deve ser feita a consistência do dígito verificador do CPF.
As regras de negócio devem ser listadas da seguinte maneira:
Rn – Descrição da Regra de Negócio.
Onde n é um número sequencial da regra.
Exemplo:
R1 – A consistência do Dígito Verificador do CPF deve ser feita 
utilizando a rotina módulo 11 da Receita Federal.
66 Outros artefatos
Deve-se relacionar nesse tópico os artefatos da UML que possam ajudar o pro-
gramador na implementação da História.
Exemplos:
Clique aqui para acessar o Diagrama de Classes.
Clique aqui para acessar o Diagrama de Sequência.
60 Análise de Sistemas
77 Observações técnicas
Deve-se relacionar nesse tópico as observações que achar pertinente relacio-
nadas às ferramentas tecnológicas que serão usadas na programação da História.
Exemplo:
Usar componentes de JavaScript na saída dos campos da tela.
Observação: não se preocupe com o significado do termo JavaScript, pois isso 
não irá afetar o entendimento do tópico e se refere a um conteúdo específico de 
linguagens de programação.
88 Histórias relacionadas
Caso a História que está sendo escrita tenha relação com outras Histórias im-
portantes que o programador conheça, podemos citá-las aqui.
Exemplos:
HU002 – Pesquisar Alunos
99 Critérios de aceitação para testes
Finalmente o último tópico de uma História de Usuário são os critérios de acei-
tação para testes.
O objetivo desse tópico é balizar os testes da História, ou seja, devemos prover 
a equipe de testes do sistema com recursos para que a História seja testada após 
sua implementação.
Nesse tópico, devemos então repetir todos os critérios de aceitação, com a dife-
rença de que aqui deve ser colocado valores reais nas entradas de campos da tela 
ou consistências necessárias.
Exemplo 1:
Considere o critério de aceitação explicado anteriormente:
Critério não deve aceitar CPF em branco ou inválido.
Dado que foi informado um CPF Inválido (R1).
Quando o aluno pressiona o botão “Efetivar Matrícula”.
Então o sistema apresenta a mensagem “CPF Inválido”.
E o sistema não efetiva a matrícula.
Casos de Uso e Histórias de Usuário 61
O critério de aceitação para testes nesse exemplo seria:
Critério não deve aceitar CPF em branco ou inválido.
Dado que foi informado o CPF J98.188.888 (inválido por 
 causa da letra J no início).
Quando o aluno pressiona o botão “Efetivar Matrícula”.
Então o sistema apresenta a mensagem “CPF Inválido”.
E o sistema não efetiva a matrícula.
Exemplo 2:
Critério não deve aceitar CPF com Dígito Verificador incorreto.
Dado que foi informado o CPF 54477271935 (DV incorreto).
Quando o aluno pressiona o botão “Efetivar Matrícula”.
Então o sistema apresenta a mensagem “CPF Inválido”.
E o sistema não efetiva a matrícula.
Esses são os tópicos de uma História de Usuário. A seguir, veremos um exemplo 
de uma História completa.
2.4.2 Exemplo completo de uma História de Usuário – estudo 
de caso da Escola de Natação
A seguir será apresentada uma História de Usuário completa do caso de uso “reali-
zar matrícula da Escola de Natação” com todos os tópicos descritos na Subseção 2.4.1.
HU001 – Realizar Matrícula
Sendo um aluno da escola.
Quero realizar matrícula.
Para estar regularizado para iniciar a atividade escolhida.
DESENHO DA(S) TELA(S)
Realizar matrícula
Escola de Natação
Turma 1: Seg/Qua/Sex das 10h às 11h
Natação
CPF:
Nome:
Turma:
Professor:
Mensalidade:
Modalidade:
Pesquisar
Efetivar matrícula Voltar
(Continua)
62 Análise de Sistemas
CRITÉRIOS DE ACEITAÇÃO
1. Deve apresentar as modalidades disponíveis ao ingressar na tela.
2. Não deve prosseguir com campos inconsistentes.
3. Deve permitir a pesquisa aos alunos cadastrados.
4. Deve apresentar o nome do aluno.
5. Deve apresentar as turmas disponíveis de cada modalidade apresentada.
6. Deve apresentar os dados de uma turma.
7. Deve efetivar a matrícula.
8. Deve retornar à tela anterior.
CRITÉRIOS DE ACEITAÇÃO – DETALHAMENTO
Critério de contexto (válido como premissa para todos os critérios):
Dado que acessei o menu “Realizar Matrícula”
1. Deve apresentar as modalidades disponíveis ao ingressar na tela.
Dado que
Quando a tela é apresentada.
Então o combo modalidade deve estar preenchido.
2. Não deve prosseguir com campos inconsistentes.
Dado que
Quando o aluno insere os campos.
Então o sistema verifica se os campos estão inconsistentes (R1).
3. Deve permitir a pesquisa aos alunos cadastrados.
Dado que não houve inconsistência nos campos.
Quando pressiono o botão Pesquisar Aluno.
Então o sistema chama a HU – Pesquisar Aluno.
4. Deve apresentar o nome do aluno.
Dado que o CPF foi informado (digitado ou pesquisado).
Quando o cursor sai do campo CPF (ou retorna da tela de pesquisa).
Então o sistema preenche o campo Nome do aluno.
5. Deve apresentar as turmas disponíveis de cada modalidade apresentada.
Dado que não houve inconsistência nos campos.
E o nome do aluno está apresentado.
Quando o aluno seleciona uma modalidade.
Então o sistema preenche o combo com as turmas 
 daquela modalidade.
(Continua)
Casos de Uso e Histórias de Usuário 63
6. Deve apresentar os dados de uma turma.
Dado que não houve inconsistência nos campos.
E o nome do aluno está apresentado.
Quando o aluno seleciona uma turma.
Então o sistema preenche os campos com os dados da turma.
7. Deve efetivar a matrícula.
Dado que não houve inconsistência nos campos.
E o nome do aluno está apresentado.
E a modalidade/turma foi selecionada.
Quando o aluno pressiona o botão Efetivar Matrícula.
Então o sistema deve salvar os dados da matrícula.
8. Deve retornar à tela anterior.
Dado que
Quando o aluno pressiona o botão Voltar.
Então o sistema deve retornar ao menu do sistema.
REGRAS DE NEGÓCIO DA HISTÓRIA
R1 – Consistência dos campos:
Inconsistência Mensagem
CPF Inválido. “CPF Inválido”.
CPF não cadastrado. “CPF não cadastrado”.
Dígito Verificador Inválido (O DV deve ser con-
sistido usando a rotina módulo 11 da Receita 
Federal).
“Dígito Verificador do CPF Inválido”.
OUTROS ARTEFATOS
Clique aqui para ver o Diagrama de Classes.
Clique aqui para ver o Diagrama de Sequência.
Clique aqui para ver o Diagrama de Atividades.
OBSERVAÇÕES TÉCNICAS
Usar os componentes do JavaScript.
HISTÓRIAS RELACIONADAS
Não há.
CRITÉRIOS DE ACEITAÇÃO – DETALHAMENTO (PARA TESTES)
Critério de contexto (Válido como premissa para todos os critérios):
Dado que acessei o menu “Realizar Matrícula”.
(Continua)
64 Análise de Sistemas
1. Deve apresentar as modalidades disponíveis ao ingressar na tela.
Dado que
Quando a tela é apresentada.
Então o combo modalidade deve estar preenchido com 
 “Natação” e “Hidroginástica”.
2. Não deve prosseguir com campos inconsistentes – Teste 1.
Dado que
Quando o aluno insere o CPF 88736364789 (Inválido).
Então o sistema verifica se os campos estão inconsistentes (R1).
3. Não deve prosseguir com campos inconsistentes – Teste 2.
Dado que
Quando o aluno insere o CPF 54477271972 (Válido, porém não 
cadastrado).
Então o sistema verifica se os campos estão inconsistentes (R1).
4. Deve permitir a pesquisa aos alunos cadastrados.
Dado que não houve inconsistência nos campos.
Quando pressiono obotão Pesquisar Aluno.
Então o sistema chama a HU – Pesquisar Aluno.
5. Deve apresentar o nome do aluno.
Dado que o CPF 9876457665 foi informado.
Quando o curso sai do campo CPF (ou retorna da tela de pesquisa).
Então o sistema preenche o campo Nome com “Joaquim José”.
6. Deve apresentar as turmas disponíveis de cada modalidade apresentada – 
Teste 1.
Dado que não houve inconsistência nos campos.
E o nome do aluno está apresentado.
Quando o aluno seleciona a modalidade “Natação”.
Então o sistema preenche o combo com as turmas:
Turma 1: Seg/Qua/Sex das 10h às 11h
Turma 2: Ter/Qui das 7h às 8h
7. Deve apresentar as turmas disponíveis de cada modalidade apresentada – 
Teste 2.
Dado que não houve inconsistência nos campos.
E o nome do aluno está apresentado.
Quando o aluno seleciona a modalidade “Hidroginástica”.
Então o sistema preenche o combo com as turmas:
Turma 3: Seg/Qua/Sex das 9h às 10h
Turma 4: Ter/Qui das 9h às 10h
(Continua)
Casos de Uso e Histórias de Usuário 65
8. Deve apresentar os dados de uma turma.
Dado que não houve inconsistência nos campos. 
E o nome do aluno está apresentado.
Quando o aluno seleciona a Turma 1.
Então o sistema preenche os campos:
Professor: Ambrósio Correa.
Mensalidade: R$ 195,00.
9. Deve efetivar a matrícula.
Dado que não houve inconsistência nos campos.
E o nome do aluno está apresentado.
E a modalidade/turma foi selecionada.
Quando o aluno pressiona o botão Efetivar Matrícula.
Então o sistema deve salvar os dados da matrícula.
10. Deve retornar à tela anterior.
Dado que
Quando o aluno pressiona o botão Voltar.
Então o sistema deve retornar ao menu do sistema.
Com isso, encerramos o tópico sobre Histórias de Usuário. Vale ressaltar que 
essa é uma prática bastante comum quando se utilizam Métodos Ágeis no proces-
so de desenvolvimento.
Como a premissa desses métodos é justamente a agilidade, o analista deve fa-
zer uma avaliação criteriosa do detalhamento necessário que deve ser usado na 
construção da História, pois em certos casos não há necessidade de se escrever a 
História completa e ele pode suprimir certos tópicos ou até mesmo escrevê-los de 
uma forma mais sucinta se a situação permitir.
Por exemplo, suponha que o analista irá repassar a História para um programa-
dor experiente, cujo trabalho seja conhecido e que não seja necessário o detalha-
mento de todos os tópicos. Nada impede então que o analista escreva somente os 
três primeiros tópicos (nome e descrição, desenho da tela e critérios de aceitação).
Sabendo que a premissa de Métodos Ágeis é não produzir trabalho desnecessá-
rio, as Histórias de Usuário se mostram uma ferramenta versátil e flexível para se 
utilizar nos ambientes de desenvolvimento de software.
No vídeo Caso de uso x his-
tória de usuário o professor 
Eduardo Castro mostra as 
diferenças entre casos de 
uso (trabalhados nas seções 
anteriores) e Histórias de 
Usuário (trabalhadas nesta 
seção).
Disponível em: https://www.youtube.
com/watch?v=YbwP1omurVU&t. 
Acesso em: 17 mar. 2021.
Vídeo
CONSIDERAÇÕES FINAIS
Este capítulo trouxe a primeira abordagem que deve ser feita para a modelagem 
de um sistema.
Vimos que, após a fase de Levantamento dos Requisitos (Iniciação), temos a fase de 
Elaboração com uma visão dos processos e descrição das funcionalidades.
Para isso, usamos os artefatos da UML conhecidos como Diagramas de Caso de Uso 
para a visão geral dos Requisitos e Histórias de Usuário para o seu detalhamento.
66 Análise de Sistemas
ATIVIDADES
1. A História de Usuário é um importante artefato para o detalhamento de como 
deve ser implementado um caso de uso. Quais são os objetivos dos critérios de 
aceitação?
2. Cite e explique os elementos de um Diagrama de Caso de Uso.
3. Quais são os objetivos de se fazer protótipos das telas do sistema?
REFERÊNCIAS
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 12. ed. Rio de Janeiro: Elsevier, 2012.
DEBONI, J. E. Z. Modelagem Orientada a Objetos com a UML. São Paulo: Futura, 2003.
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2018.
HELM, R.; WILDT, D. Histórias de usuário. Por que e como escrever requisitos de forma ágil? 3. ed. Porto 
Alegre: Wildtech, 2014.
MELO, A. C. Desenvolvendo aplicações com UML 2.2. Rio de Janeiro: Brasport, 2011.
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. São Paulo: Campus, 1994.
Objetos e classes 67
3
Objetos e classes
A primeira abordagem, na fase de Elaboração por meio de uma Lista 
de Requisitos, é a construção do Diagrama de Caso de Uso. A fase seguin-
te é a Prototipação das telas; por fim, seu detalhamento ocorre por meio 
das Histórias de Usuário. Esses artefatos darão uma visão funcional dos 
processos e de seu encadeamento. Ainda, ficará registrado o funciona-
mento de cada um deles e das regras de negócio que serão verificadas 
para que cumpram seus objetivos.
O próximo passo no processo de desenvolvimento do sistema é a 
identificação e a estruturação das entidades envolvidas no problema. Tais 
entidades, na Análise Orientada a Objetos, são chamadas objetos.
Neste capítulo, iremos conhecer não só os principais conceitos de 
objetos e classes, mas também os artefatos responsáveis por organizar 
esses objetos, a fim de dar a estrutura conceitual que o software necessita 
para distribuir os processos e suas responsabilidades.
3.1 Objetos e classes 
Vídeo A grande inovação trazida pela Análise Orientada a Objetos foi justamente o 
conceito de objeto. A organização da solução, em termos de objetos, fez com que 
os sistemas tivessem uma melhor estrutura. Com isso, diversos problemas das teo-
rias anteriores foram resolvidos.
Dentre todas as tarefas de modelagem de um sistema, a organização dos ob-
jetos é a de maior importância. Construir um sistema em torno de objetos é mais 
importante do que em torno de suas funções, pois são mais adaptáveis a modifica-
ções (RUMBAUGH et al., 1994).
A seguir veremos os principais conceitos necessários para se estruturar objetos 
e classes.
3.1.1 Objetos
O conceito básico da Análise Orientada a Objetos é, obviamente, o conceito de 
objeto.
Segundo Rumbaugh et al. (1994, p. 31), “definimos um objeto como um conceito, 
uma abstração, algo com limites definidos e significado em relação ao problema”.
68 Análise de Sistemas
Essa definição por si só mostra que quase tudo que manipulamos pode ser con-
siderado um objeto, e o sistema, com todos os seus componentes, irá se enquadrar 
nesse conceito.
Um objeto, para efeitos de estruturação do sistema, possui três elementos. 
São eles:
Cada objeto é único e deve ter uma identificação que não pode ser usada em outros objetos. A 
identificação é o nome do objeto. Por exemplo, uma pessoa pode ser identificada por seu CPF, 
pois esse número, pelo menos em termos legais, é único, ou seja, não existem duas pessoas com 
o mesmo número de CPF.
Identificação
São as características ou propriedades de um objeto. Eles identificam um determinado estado 
do objeto, pois um atributo pode ter um determinado valor que pode mudar no decorrer do 
tempo. Os atributos representam peculiaridades que costumam variar de um objeto para outro 
e permitem diferenciar um objeto de outro (GUEDES, 2018). Um atributo é uma propriedade com 
um intervalo de valores que ele pode assumir (BOOCH; RUMBAUGH; JACOBSON, 2012).
Atributos
Consistem no que o objeto consegue produzir; são as suas ações, suas operações, seu 
comportamento ou suas funções. É como o objeto reage a estímulos externos. Eles representam 
uma atividade que o objeto consegue executar (GUEDES, 2018). Um método pode ou não alterar 
o valor de um ou mais atributos; é a implementação de algum serviço que pode ser solicitado por 
algum objeto para mudar um ou mais comportamentos (BOOCH; RUMBAUGH; JACOBSON, 2012). 
A UML se refere aos métodos com o termo operações, porém o termo mais comumente utilizado 
na modelagem, e também na programação, é método.
Métodos
O quadro a seguir mostra algunsexemplos de objetos com sua identificação, 
seus valores e suas operações.
Quadro 1
Exemplos de objetos com atributos e métodos
Carro com placa 
BDF-7F91
Pessoa com nome de 
Joaquim José
Venda de uma 
joia
Empréstimo de 
Joaquim José
Atributos
Marca: VW
Ano: 2012
Km: 57.543
Atributos
Altura: 1,80 m
Cor do cabelo: preto
Gênero: masculino
Atributos
Número: 415
Data: 19/11/2020
Cliente: 
Joaquim José
Atributos
Número: 31.576
Quantidade de parcelas: 
48
Valor: R$ 1.000,00
Métodos
Andar
Frear
Buzinar
Métodos
Falar
Comprar
Dormir
Métodos
Vender
Mostrar produtos
Cancelar venda
Métodos
Calcular saldo devedor
Quitar empréstimo
Pagar parcela
m
at
sa
be
/ S
hu
tte
rs
to
ck
ta
tia
na
su
n/
 S
hu
tte
rs
to
ck
BI
nt
an
g 
Aj
i P
ria
m
bo
do
/ 
Sh
ut
te
rs
to
ck
M
us
ta
fa
 A
ra
in
/ S
hu
tte
rs
to
ck
Fonte: Elaborado pelo autor
Objetos e classes 69
Pelo fato de os atributos e métodos estarem juntos no objeto, dizemos que eles 
estão encapsulados no objeto. Esse encapsulamento é um importante conceito da 
Análise Orientada a Objetos; sua função é que os métodos “protejam” os atributos 
do acesso descontrolado, ou seja, o acesso aos atributos é realizado por intermédio 
de seus métodos.
3.1.2 Classes
Uma classe é um modelo, um protótipo usado para criar vários objetos com 
características semelhantes. Para Rumbaugh et al. (1994, p. 32), “uma classe de ob-
jetos descreve um grupo de objetos com propriedades semelhantes (atributos), 
o mesmo comportamento (operações), os mesmos relacionamentos com outros 
objetos e mesma semântica”.
Deboni (2003, p. 73) afirma que “A estrutura de um software é formada pelas 
classes do sistema. Analogamente ao esqueleto dos animais, as classes formam 
uma armação que dá a sustentação e a forma ao sistema”. Já de acordo com Guedes 
(2018, p. 44), “uma classe representa uma categoria, e os objetos são os membros ou 
exemplos dessa categoria”. As classes são meras descrições dos objetos que as com-
põem, são especificações que descrevem os seus objetos.
Podemos pensar em uma classe como o projeto de uma casa a ser construída. O 
projeto não é a casa, ela vai ser construída com base no projeto (BOOCH; RUMBAUGH; 
JACOBSON, 2012). Podemos também imaginar uma classe como uma receita de bolo. 
A receita não é o bolo, mas a descrição de como fazer um bolo. Quando usamos essa 
receita para efetivamente fazer um bolo, criamos um objeto (o bolo) dessa classe. O 
quadro a seguir ilustra essa situação.
Quadro 2
Exemplo de classe e seu objeto
Classe Objetos
Ingredientes
Massa:
2 xícaras (chá) de farinha de trigo
1 xícara (chá) de óleo
1 xícara (chá) de água
1 xícara (chá) de açúcar
1 colher (sopa) de fermento
2 ovos
Cobertura:
1 caixa ou lata de creme de leite
1 colher (chá) de manteiga
3 colheres (sopa) de achocolatado em pó
Modo de preparo
Misture a farinha de trigo e o açúcar. Bata os ovos, o óleo e a 
água; em seguida, misture com os demais ingredientes da mas-
sa, colocando o fermento por último.
Coloque em uma forma untada e asse por 30 min.
Derreta a manteiga e acrescente o creme de leite e o achocola-
tado, mexendo bem até ficar homogêneo.
Jogue a cobertura por cima do bolo assado.
Decore com frutas de sua preferência.
An
ut
aB
er
g/
 S
hu
tte
rs
to
ck
Fonte: Elaborado pelo autor.
70 Análise de Sistemas
Uma classe terá atributos e métodos, porém, como é uma mera descrição dos 
diversos objetos que serão criados por meio de sua especificação, nas classes não 
serão atribuídos os valores aos atributos (já que não se tem esses valores).
Ela será representada por um retângulo com três compartimentos. No primei-
ro, temos o nome da classe, no segundo a sua relação de atributos, e no terceiro a 
relação de métodos da classe. O quadro a seguir mostra essa representação com o 
exemplo da classe Empréstimo.
Quadro 3
Classe Empréstimo
Empréstimo
Atributos
Número
Quantidade de parcelas
Valor
Métodos
Calcular saldo devedor
Quitar empréstimo
Pagar parcela
Fonte: Elaborado pelo autor.
Para um empréstimo de uma instituição financeira, teríamos outros atributos, 
porém devemos relacionar todos que forem necessários para atender ao negócio 
de empréstimos.
3.1.3 Mensagens
Uma mensagem é a invocação de um método de determinada classe para que 
um método de outra classe seja executado.
É comum que em um determinado processo um objeto necessite buscar os va-
lores de atributos de outro objeto ou mesmo fazer alterações nesse valor. Devido 
ao conceito de encapsulamento, esse objeto não tem permissão para acessar dire-
tamente atributos de outros objetos, então a forma de se comunicar é por meio de 
mensagens entre objetos.
A figura a seguir mostra o exemplo de duas classes: Cliente e Venda. A seta en-
tre elas representa a troca de mensagens pelas quais um determinado método de 
uma classe está chamando um método de outra.
Objetos e classes 71
Figura 1
Exemplo de mensagens entre classes
Cliente
incluir
vender
Venda
nome
CPF
numero
data
Fonte: Elaborada pelo autor.
3.1.4 Herança
O termo herança é bastante forte na Análise Orientada a Objetos; na verdade, esse 
conceito nasceu com essa teoria. Ele também pode ser utilizado entre atores e casos de 
uso. A herança entre classes é a capacidade de uma classe (chamada de filha) herdar 
as características (atributos e métodos) de outra classe (chamada de mãe). Nesse caso, 
a classe filha terá todas as suas características e mais as características da classe mãe.
A herança permite que as características da classe mãe possam ser expandidas 
para a filha, incluindo novas características a ela.
Uma classe mãe pode ter uma ou mais filhas. Em outras palavras, usamos he-
rança quando existem diversos tipos de uma determinada classe.
A figura a seguir mostra o exemplo da classe Cliente. Digamos que uma insti-
tuição financeira tenha dois tipos de clientes: pessoas físicas (pessoas comuns) e 
pessoas jurídicas (empresas).
Figura 2
Exemplo de herança de classes

Cliente 
– endereco : texto 
– telefone : texto
PessoaFisica
– cpf : numero 
– nome : texto 
– email : texto

PessoaJuridica
– cnpj : numero 
– razaoSocial : texto
– enderecoSite : texto
Fonte: Elaborada pelo autor.
72 Análise de Sistemas
Nesse exemplo, a classe Cliente é a classe mãe, os tipos de clientes PessoaFisi-
ca e PessoaJuridica são as classes filhas (os nomes das classes estão escritos sem 
espaços e acentuação não por erro de grafia, mas porque estão escritos em um 
padrão que veremos adiante).
Note que os atributos comuns a todos os tipos (endereço e telefone) estão na 
classe Cliente (classe mãe). A leitura que deve ser feita então é que, por exemplo, 
um objeto da classe PessoaFisica tem os atributos CPF, nome, e-mail e mais os 
atributos endereço e telefone (atributos da classe mãe). O mesmo podemos falar 
da classe PessoaJuridica, que teria os atributos CNPJ, razão social, endereço do site, 
endereço e telefone. 
3.1.5 Padrões
Os nomes de classes, atributos e métodos devem ser escritos em um deter-
minado padrão. Isso facilita o entendimento e a comunicação entre os membros 
da equipe de desenvolvimento e irá balizar a implementação em uma linguagem 
de programação, já que é a etapa seguinte no processo de desenvolvimento do 
sistema.
A seguir, apresentaremos um padrão muito comum utilizado na modelagem UML.
Padrão para nomes de classes:
 • Utilizar nomes no singular.
 • Evitar abreviaturas.
 • Não utilizar hifens, tracinhos ou espaços.
 • Não usar acentuação ou cedilha.
 • Não usar preposições (de, para, do, com, entre outras).
 • Não usar palavras desgastadas (Tabelas, Cadastro).
 • A primeira letra do nome deve ser maiúscula e as demais, minúsculas.
Exemplos de nomes de classes no padrão:
 • Cliente
 • ProdutoEstoque
 • PessoaFisica
 • Venda
 • LivroEmprestimo
Padrão para nomes de atributos:
 • Não utilizar hifens, tracinhos ou espaços.
 • Não usar acentuação ou cedilha.
 • Não usar preposições (de, para, do, com, entre outras).
 • É possívelusar abreviaturas.
 • É possível usar palavras no plural.
 • Usar letras minúsculas. Caso haja vários nomes, o primeiro inicia com minús-
cula, e a partir do segundo a primeira letra deve ser maiúscula.
Um objeto também é chamado 
de instância de classe. Esse é 
um termo bastante comum, 
principalmente nas linguagens de 
programação orientadas a objetos.
Curiosidade
Objetos e classes 73
Exemplos de nomes de atributos no padrão:
 • idade
 • nomeCliente
 • sldDevedor (Saldo devedor)
 • qtdAlunosMatriculados (quantidade de alunos matriculados)
É comum que seja colocado o tipo de atributo após o seu nome. Um atributo 
pode ser de diversos tipos, como numérico, texto, data, número com casas deci-
mais, com valores Verdadeiro/Falso (boolean), dentre outros tipos. Esse tipo é colo-
cado após o nome do atributo e separado por dois pontos (:).
Como exemplo, temos os atributos da classe Professor com seus tipos, como 
mostra a figura a seguir.
Figura 3
Exemplo de tipos de atributos
– cpf : numero 
– nome : texto 
– dataAdmissao : data
Professor
Fonte: Elaborada pelo autor.
Padrão para nomes de métodos:
 • Não utilizar hifens, tracinhos ou espaços.
 • Não usar acentuação ou cedilha.
 • Não usar preposições (de, para, do, com, entre outras).
 • É possível usar abreviaturas. 
 • É possível usar palavras no plural.
 • Usar letras minúsculas. Caso haja vários nomes, o primeiro inicia com minús-
cula, e a partir do segundo a primeira letra deve ser maiúscula.
 • Como um método é uma ação, a primeira palavra deve ser um verbo no infi-
nitivo (verbo na forma natural), ou seja, somente a leitura do nome do méto-
do já deve indicar a sua ação.
Exemplos de nomes de métodos no padrão:
 • calcularSaldoDevedor
 • imprimirBoleto
 • incluirCliente
3.2 Relacionamentos entre as classes 
Vídeo Normalmente, uma classe não está isolada em um sistema. É bem comum que 
seus objetos estejam relacionados aos objetos de outras classes.
Ao identificarmos e organizarmos as classes, descobriremos que dificilmente 
elas trabalharão sozinhas. A maioria das classes colaboram umas com as outras e 
74 Análise de Sistemas
seus objetos se relacionam entre si (BOOCH; RUMBAUGH; JACOBSON, 2012). Para 
essa relação, damos o nome de relacionamento entre as classes.
A seguir, conheceremos os principais tipos de relacionamentos entre as Classes 
e qual é a finalidade de cada um.
3.2.1 Associação
O relacionamento de associação representa a existência de alguma conexão 
entre os objetos das classes, de modo que um objeto de uma classe deve manter 
alguma referência ao objeto da outra.
A necessidade de se associar classes é que essa associação permite que se na-
vegue entre os objetos das classes, pois eles estarão conectados por atributos co-
muns entre elas (BOOCH; RUMBAUGH; JACOBSON, 2012). Isso significa que, pelo 
objeto de uma classe, pode-se criar vínculos com objetos de outras classes.
A associação faz com que uma classe colabore com a organização de outra clas-
se (MELO, 2010). Por exemplo, analise na figura a seguir a classe contendo os fun-
cionários de uma empresa e a outra contendo os dependentes dos funcionários.
Figura 4
Exemplo de classes sem associação
– matricula : numero
– nome : texto 
Funcionario
– nome : texto
– dataNascimento : data
Dependente
Fonte: Elaborada pelo autor.
Se as duas classes não estivessem associadas, o que teríamos seria um cadastro 
de todos os funcionários de um lado e um cadastro de todos os dependentes de 
outro, porém não seria possível saber quem é dependente de qual funcionário. 
Perceberíamos então que esse cadastro não teria muita utilidade para o negócio 
de uma empresa.
Para que essa ligação seja feita, devemos utilizar o relacionamento de associa-
ção; com isso, saberíamos qual é o funcionário responsável pelo dependente.
Associações simples são representadas na forma de uma linha cheia conectan-
do as duas classes, como mostra a Figura 5.
Figura 5
Exemplo de classes relacionadas com associação
– matricula : numero
– nome : texto 
Funcionario
– nome : texto
– dataNascimento : data
Dependente
Fonte: Elaborada pelo autor.
As associações são bidirecionais, pois um objeto de uma classe está ligado a um 
objeto de outra classe e vice-versa, que são definidas, na maioria das vezes, pelas 
regras de negócio do sistema (RUMBAUGH et al.,1994).
Objetos e classes 75
Por conta disso, as associações devem possuir o que chamamos de multiplicida-
de, para indicar com qual quantidade de objetos uma classe está associada a outra 
(nos dois sentidos), ou seja, se escolhemos um objeto de uma classe, queremos 
saber com quantos objetos ele está relacionado a outra classe.
No exemplo da Figura 5, devemos escolher um determinado funcionário e fazer 
a seguinte pergunta: quantos dependentes um funcionário pode ter? A resposta 
obviamente é que ele pode ter muitos dependentes. Também devemos fazer a 
pergunta inversa: um dependente pode ser dependente de quantos funcionários? 
Nesse caso, a resposta também seria: ele pode ser dependente de muitos e, mais 
exatamente, de um (se somente um dos pais é funcionário da empresa) ou dois (se 
pai e mãe trabalham na empresa).
Em termos de notação nas classes, colocamos um asterisco (*) na linha repre-
sentando a associação ao lado da classe que identificamos existirem “muitos”. No 
caso desse exemplo, são ambos os lados, pois verificamos que um funcionário 
pode ter muitos dependentes e um dependente pode ser dependente de muitos 
funcionários. Assim, a notação final da associação dessas duas classes é como apa-
rece na figura a seguir.
Figura 6
Exemplo de classes relacionadas com associação e multiplicidade
* *– matricula : numero
– nome : texto 
Funcionario
– nome : texto
– dataNascimento : data
Dependente
Fonte: Elaborada pelo autor.
A seguir, veremos mais um exemplo do relacionamento de associação. Vamos 
pensar em uma editora que publica vários livros. Poderíamos ter duas classes, 
como mostra a Figura 7.
Figura 7
Exemplo de classes associadas
*– cnpj : numero 
– nome : texto
Editora
– titulo : texto
– isbn : data
Livro
Fonte: Elaborada pelo autor.
A leitura que fazemos desse diagrama é que uma editora publica muitos livros 
(pelo * na linha ao lado da classe Livro) e que um livro é publicado por uma única 
editora (a ausência de * no lado da classe Editora indica “um único”).
Como último exemplo do relacionamento de associação, vamos pensar em uma 
classe com todos os países do mundo e outra com todas as capitais dos países. 
Poderíamos ter duas classes, como mostra a figura a seguir.
76 Análise de Sistemas
Figura 8
Exemplo de classes associadas
– nome : texto
Pais
– nome : texto
Capital
Fonte: Elaborada pelo autor.
A leitura que fazemos é que um país tem uma capital (a ausência de * no lado da 
classe Pais indica “um único”) e que cada capital é capital de um único país.
Existem refinamentos da notação para melhor demonstrar a multiplicidade en-
tre as classes, como mostra o Quadro 4.
Quadro 4
Notações de multiplicidade
Notação Significado Exemplo
* Muitos *
Editora Livro
Uma editora pode publicar muitos livros. Um livro pode ser publicado 
por somente uma editora.
0..* Zero, um ou muitos 
0.. *
Cliente Seguro
Um cliente pode ter nenhum seguro, um seguro ou muitos seguros. Um 
seguro é de um único cliente.
1..* Um ou muitos 1.. *
Motoboy Motocicleta
Um motoboy pode ter uma ou mais motocicletas (mas pelo menos 
uma). Uma motocicleta é de apenas um motoboy.
1..6 De um até seis 1.. 6
Aluno Disciplina
10.. 40
Um aluno pode ter matrícula em uma a seis disciplinas. Uma disciplina 
pode ter de 10 a 40 alunos matriculados.
Fonte: Elaborado pelo autor.
Quando associamos duas classes, na qual um objeto da primeira classe está 
associado com muitos da outra classe, comumente chamamos essa associação de 
1-para-muitos. Quando muitos objetos de uma classe se associam com muitos 
de outra classe, chamamos essa associação de muitos-para-muitos. Finalmente, 
quando somente umobjeto de uma classe está associado a somente um de outra 
classe, chamamos de associação 1-para-1.
Objetos e classes 77
3.2.2 Agregação
Uma agregação entre duas classes denota que uma delas possui as característi-
cas do todo do objeto e a outra corresponde às suas partes. Ela é um tipo especial 
de associação.
Nas agregações, as duas classes devem ter a característica de todo-parte, na qual 
uma das classes representa o todo e a outra representa as partes desse todo.
Suponhamos um time de futebol, por exemplo. Todo time é composto de atle-
tas. Se tivermos a classe Time, ela representaria o todo, e os atletas seriam as par-
tes desse todo.
Podemos perceber que o time tem seus atributos próprios, como o seu nome, o 
técnico, entre outros. Também os atletas têm seus atributos, como nome, posição 
em que jogam, entre outros. Podemos ver isso na figura a seguir.
A notação para o relacionamento de agregação é uma linha com um losango 
vazado na extremidade, que representa a classe “todo”.
Figura 9
Exemplo de agregação
– nome : texto – nome : texto
Time Atleta
– tecnico : texto – posicao : texto
Fonte: Elaborada pelo autor.
Uma agregação permite que um objeto na classe que representa o todo não es-
teja relacionado com nenhuma parte. Por exemplo, podemos ter um determinado 
time que não tenha nenhum atleta ligado a ele. Da mesma forma, um objeto da 
classe “partes” também pode não estar ligado a nenhum objeto do todo, como um 
atleta que não esteja em nenhum time.
Nesse tipo de relacionamento, um objeto da classe “partes” pode estar relacio-
nado a vários objetos da classe “todo”; por exemplo, um atleta pode jogar em vários 
times.
Fique atento a essas duas observações, pois serão as diferenças para o próximo 
tipo de relacionamento: a composição.
Outro exemplo de agregação seria uma playlist com músicas. Essa representa-
ção está na figura a seguir.
Figura 10
Exemplo de agregação
Playlist Musica
Fonte: Elaborada pelo autor.
78 Análise de Sistemas
A playlist seria a classe “todo” e as músicas dela seriam suas “partes”.
3.2.3 Composição
A composição é um tipo especial de agregação, ou seja, também tem a caracte-
rística todo-parte, porém, nesse caso, uma parte deve pertencer a um único todo.
No caso de uma composição, não faz sentido pensarmos o objeto da classe 
“todo” sem os objetos da classe que a compõem, isto é, as partes não existem sem 
o todo e vice-versa.
Na composição, o tempo de vida do todo e das partes coincidem. Uma vez 
criados os objetos de ambas as classes, eles nascem e morrem juntos (BOOCH; 
RUMBAUGH; JACOBSON, 2012).
Como exemplo, podemos pensar em um livro com capítulos. O livro não tem 
sentido sem seus capítulos e um capítulo só pode pertencer a um único livro; não 
tem sentido cadastrarmos um livro sem capítulos e vice-versa. Dizemos então que 
um livro é composto de seus capítulos. Esse exemplo é representado na Figura 11.
A notação para o relacionamento de composição também é uma linha com um 
losango na extremidade, que representa a classe “todo”, porém, nesse caso, esse 
losango é preenchido. 
Figura 11
Exemplo de composição
– titulo : texto – nome : texto
Livro Capitulo
– isbn : texto
Fonte: Elaborada pelo autor.
.3.2.4 Classe de associação
Pode ocorrer de uma associação entre duas classes necessitar de um atributo. 
Quando isso ocorre, uma classe de associação deve ser colocada entre duas classes 
com associação muitos-para-muitos.
Suponhamos uma classe com diversas receitas de pratos e outra contendo di-
versos ingredientes, como mostra a figura a seguir.
Figura 12
Associação com multiplicidade muitos-para-muitos
**– nome : texto – nome : texto
Receita Ingrediente
– modoPreparo : texto
Fonte: Elaborada pelo autor.
Inicialmente, temos uma associação com cardinalidade muitos-para-muitos, 
já que uma receita tem muitos ingredientes e um ingrediente pode estar em 
várias receitas.
Objetos e classes 79
Se pensarmos agora no atributo quantidade, podemos verificar que ele não se 
enquadra em nenhuma das duas classes, porque essa informação na verdade trata 
das duas classes, ou seja, “quantidade de um determinado ingrediente em uma 
determinada receita”.
Para acomodar então esse atributo, podemos criar o que chamamos de classe 
de associação. Ela é colocada entre as duas classes e ligada com uma linha pontilha-
da, como mostra a figura a seguir.
Figura 13
Exemplo de classe de associação
IngredienteReceita – nome : texto – nome : texto
– quantidade : numero
Receita Ingrediente
IngredienteReceita
– modoPreparo : texto
Fonte: Elaborada pelo autor.
Note que para o nome dessa nova classe foi utilizado o nome das duas classes. 
Isso é recomendado, uma vez que o atributo nela contido é um atributo que se 
refere a ambas as classes.
3.2.5 Herança
Por fim, o último tipo de relacionamento que veremos é o relacionamento de 
herança.
O conceito de herança já foi aprendido anteriormente. Veremos agora somente 
a sua notação, que é uma seta vazada saindo das classes filhas (os tipos) e apontan-
do para a classe mãe (mais geral).
Figura 14
Exemplo de herança
– cpf : numero
– nome : texto
– email : texto
– cnpj : numero
– razaoSocial : texto
– enderecoSite : texto
– endereço : texto
– telefone : texto
PessoaFisica PessoaJuridica 
Cliente

Fonte: Elaborada pelo autor.
Existem outros tipos de relacionamentos menos importantes na UML que não 
abordaremos neste livro.
Existe herança quando conseguir-
mos colocar a frase “é um” ou “é 
uma” entre a classe filha e a classe 
mãe e a relação tiver sentido. No 
exemplo, uma PessoaFisica é um 
cliente. Como isso é verdadeiro, 
existe herança entre as classes.
Importante
O vídeo Programação 
Orientada a Objetos (POO) 
// Dicionário do Programa-
dor, publicado pelo canal 
Código Fonte TV, ilustra 
de maneira lúdica alguns 
conceitos trabalhados 
nesta seção. Ele pode ser 
acessado no link a seguir.
Disponível em: https://www.youtube.
com/watch?v=QY0Kdg83orY. Acesso 
em: 17 mar. 2021.
Vídeo
80 Análise de Sistemas
3.3 Diagrama de Classes
Vídeo Depois de conhecermos todos os principais conceitos de objetos, classes e seus 
relacionamentos, devemos construir um diagrama, no qual serão colocadas todas 
as classes de um determinado sistema, com seus atributos, métodos e relaciona-
mentos. Fazemos isso construindo o Diagrama de Classes.
Esse é um dos principais diagramas da UML e é de extrema importância para 
a arquitetura da solução informatizada que está sendo construída. Ele é escrito 
pelo analista de sistemas com base nos Requisitos, Casos de Uso e nas Histórias 
de Usuário.
Para efeitos didáticos, iremos construir o diagrama em dois níveis.
3.3.1 Diagrama de Classes de nível 1
No Diagrama de Classes de nível 1, colocamos as classes do sistema, seus atri-
butos próprios e seus relacionamentos com outras classes. Nessa etapa, não co-
locaremos os métodos das classes, pois o melhor momento para se identificar os 
métodos é a construção do Diagrama de Sequência.
Como exemplo de construção do Diagrama de Classes de nível 1, iremos abor-
dar uma Escola da Natação. Com base em seus Requisitos e protótipos de telas, 
iremos identificar todas as classes e atributos necessários, bem como tentar iden-
tificar o relacionamento entre as classes.
O quadro a seguir apresenta a Lista de Requisitos, agora acrescida dos atributos 
das entidades envolvidas.
Quadro 5
Problema da Escola da Natação
(Continua)
Requisito Descrição Regras de negócio Atributos
R1 - Manter cadastro 
dos alunos
Permitir o cadas-
tro completo dos 
alunos.
Permitir pesquisar, incluir, 
alterar e consultar.
Não permitir a exclusão de 
um aluno, somente marcar 
como inativo.
CPF, nome, endereço.
R2 - Manter cadastro 
dos professores
Permitir o cadas-
tro completo dos 
professores.
Permitir pesquisar, incluir, 
alterar, excluir e consultar.
CPF, nome, data de 
admissão, modalidade 
(natação ou hidrogi-
nástica).
R3 - Manter cadastro 
das turmas
Permitir o cadas-
tro completo das 
turmas, sua mo-
dalidademuito esforço (e dinheiro) 
para mantê-lo funcionando, sempre impactando negativamente a imagem da em-
presa e seus negócios.
Nosso objetivo na tarefa de desenvolver um sistema é fazer com que todas as 
etapas do desenvolvimento sejam realizadas de modo fluente, tranquilo e, princi-
palmente, com produtividade, baixo custo e qualidade.
1.1.1 Conceitos iniciais
Segundo Stair e Reynolds (2015), sistemas de informação são componentes 
que interagem entre si, coletando, manipulando e disseminando dados e informa-
ções, a fim de atingir um objetivo. Já Laudon e Laudon (2005) definem sistemas de 
informação como um conjunto de elementos inter-relacionados que coleta, proces-
sa, armazena e distribui informações com o intuito de apoiar a tomada de decisão, 
a coordenação e o controle de uma organização.
Já um software pode ser definido como um conjunto de instruções (programa de 
computador) que, ao ser executado por um computador, produz um determinado 
resultado desejado e adequado à finalidade para a qual foi construído (PRESSMAN; 
MAXIM, 2016). É o termo genérico usado para descrever programas executados em 
um computador que manipulam dados e produzem o resultado para o qual foram 
projetados. O termo computador pode se referir a notebook, celular, tablet, smart 
TV, console de videogame etc.
Portanto, os softwares correspondem à parte lógica do computador, consistin-
do em programas que controlam o trabalho do hardware (STAIR; REYNOLDS, 2015).
A Figura 1 caracteriza um software e representa os componentes de um sistema 
de informações (SI).
Como exemplos de software podemos citar um 
site da internet, um aplicativo de celular, um editor de 
textos, planilhas eletrônicas, o programa que controla 
uma smart TV, um navegador de páginas na internet, 
um jogo, um editor de áudio ou vídeo, um app de strea-
ming, um controlador de semáforos das ruas e muitos 
outros. Por suas áreas de atuação, podem ser sistemas 
de informação, softwares embarcados, aplicativos de 
celular, softwares científicos, aplicações web, softwa-
res de inteligência artificial, dentre outros.
Figura 1
Componentes de um SI
Dados de 
entrada
Processamento
Dados de saída
• Software
Fonte: Elaborada pelo autor.
Introdução à análise de sistemas e Levantamento de Requisitos 11
Sistemas de informação e software se confundem. Tratar um deles como sendo 
o outro não traz grandes problemas, pois o que realmente importa para os usuá-
rios é a sua utilização.
1.1.2 Histórico da análise de sistemas
Os computadores surgiram na década de 1950, porém, até o início dos anos 
1970, eram utilizados basicamente no meio científico e militar. Com a populariza-
ção do seu uso, principalmente em empresas, sistemas de informações começa-
ram a ser construídos com o objetivo de resolver ou informatizar os processos de 
negócio dessas empresas.
Inicialmente as linguagens de programação eram complexas, a produção de 
programas demandava muitas linhas de código e a forma de se passar instruções 
aos computadores era difícil e exigia muita habilidade dos programadores. Não era 
rara a produção de programas imensos, porém a maioria do corpo do programa 
se referia à maneira de se comunicar com a máquina, sendo que a resolução do 
problema do negócio propriamente dito tinha de ficar em segundo plano.
Com isso, os programadores se preocupavam muito com as questões técni-
cas dos computadores e não conseguiam focar aquilo que realmente importava, 
ou seja, resolver o problema do seu usuário. Por causa disso, muitos erros eram 
cometidos, tanto de interpretação do negócio como de resolução equivocada do 
problema. Também, nessa época, não existia nenhuma estruturação dos proces-
sos a serem programados e muito menos uma organização dos dados utilizados 
pelo sistema.
A Figura 2 exemplifica essa situação. No lado esquerdo da figura, na primeira 
coluna, temos um conjunto de programas do sistema e, no lado direito, na segunda 
coluna, um exemplo de um conjunto de dados totalmente desestruturado. Podemos 
imaginar a dificuldade de manipular esses dados sem nenhuma estruturação, bem 
como de manter atualizada a estrutura depois de inserções de novos dados.
Figura 2
Programas e dados desestruturados
Fonte: Elaborada pelo autor.
Dados
Dados x
. . .
. . .
Dados y
. . . 
. . . 
Dados z
Programa 1
Programa 2
Programa 3
Programa n
12 Análise de Sistemas
Para amenizar esse cenário, nos anos 1970 surgiram as teorias de análise. Tais teo-
rias tinham o objetivo de fazer com que os profissionais tivessem um tempo para ana-
lisar o problema e estruturar uma solução antes da efetiva codificação dos programas.
1.1.2.1 Análise Estruturada
A primeira teoria de análise que surgiu foi chamada de Análise Estruturada 
(YOURDON; CONSTANTINE, 1992). Basicamente a referida teoria procurou dar uma 
estrutura aos processos e introduziu o conceito de diagramas para demonstrar a 
solução do problema. Surgiram então os dois primeiros diagramas básicos da Aná-
lise, o Fluxograma e o Diagrama de Fluxo de Dados (DFD), que foram amplamente 
utilizados até meados dos anos 1980.
As Figuras 3 e 4 mostram um exemplo de Fluxograma e um DFD (no qual está re-
presentado o negócio de uma locadora de filmes, algo que não existe mais nos dias de 
hoje, porém o exemplo foi usado para refletir como a teoria é antiga e ultrapassada).
Figura 3
Exemplo de fluxograma
Fonte: Elaborada pelo autor.
Inserir cartão
Cliente informa a senha Sistema emite a mensagem 
“Senha inválida”
Cliente informa o valor Sistema libera o dinheiro
>
>
Figura 4
Exemplo de DFD
Fonte: Elaborada pelo autor.
Admin. 
videolocadora
Manter clientes Locar fitas
Manter fitas Entidade externa
ClienteGerar relatórios
D1 Clientes D3 Mov. fitas
D2 Fitas
Comando
Dados fita
Dados fita
Dados fita
Dados fita
Dados fita
Doc. controle
Recibo
Relatórios
Solicitação
Dados cliente
Dados cliente
Dados Locação
Dados locaçãoDados Cliente
Carteira
Introdução à análise de sistemas e Levantamento de Requisitos 13
Porém, mesmo com a introdução dessa fase de análise no processo de desen-
volvimento do sistema, problemas e dificuldades continuavam acontecendo. A 
questão agora era a falta de estruturação dos dados que o sistema manipulava. 
Não existia uma forma definida e cada sistema organizava seus dados da maneira 
que imaginava ser a correta para a sua solução. Com isso, diversos problemas de 
manipulação dos dados ocorriam, sistemas diferentes não conseguiam se comuni-
car e o esforço para se trabalhar com esses dados era muito grande.
Surgiram então os Sistemas Gerenciadores de Banco de Dados (SGBD), am-
plamente utilizados até os dias de hoje. A proposta desses sistemas era armazenar 
e fornecer ferramentas de manipulação desses dados, fazendo com que os pro-
gramas somente fizessem solicitações aos SGBDs para consultar, atualizar, incluir 
e excluir seus dados. Porém, para a utilização desses sistemas, foi necessária a 
estruturação dos dados. Surgiram então as técnicas de organização dos dados em 
forma de tabelas, linhas e colunas e foram introduzidas técnicas de normalização e 
relacionamentos entre os dados. Com isso, surgiram os bancos de dados.
A Figura 5 mostra a estrutura da modelagem da Análise Estruturada.
Fonte: Elaborada pelo autor.
Admin.
videolocadora
Manter clientes Locar fitas
Manter fitas Entidade externa
ClienteGerar relatórios
D1 Clientes D3 Mov. fitas
D2 Fitas
Comando
Dados fita
Dados fita
Dados fita
Dados fita
Dados fita
Doc. Controle
Recibo
Relatórios
Solicitação
Dados cliente
Dados cliente
Dados locação
Dados LocaçãoDados cliente
Processos
Programa 1
Programa 2
Programa 3
Programas
Carteira
Figura 5
Análise estruturada Banco de dados
Aluno
cpf int PK
nome Text N
Matricula_numero int FK
Curso
codigo int PK
nome Text
Professor
cpf int PK
matricula int
nome text
Disciplina
codigo int PK
nome int
Curso_codigo int FK
Professor_cpf int FK
Matrícula
numero int PK
cpf_aluno int
codigo_disciplina int
Disciplina_codigo(natação 
ou hidroginástica), 
seus dias/horários 
e qual professor é 
responsável.
Não permitir o cadastro 
de duas turmas da mesma 
modalidade no mesmo 
horário.
Uma turma deve ter 
um nome (Turma 1, 
Turma 2 etc.), uma 
modalidade (natação 
ou hidroginástica), 
os dias da semana, a 
turma, os horários, o 
professor e o valor da 
mensalidade.
Objetos e classes 81
Requisito Descrição Regras de negócio Atributos
R4 – Matricular 
alunos
Matricular os alu-
nos nas turmas.
Pessoas com mais de 
80 anos só podem se 
matricular na modalidade 
hidroginástica.
Número da matrícula, 
data, turma e aluno.
R5 - Registrar fre-
quência
Registrar frequên-
cia no diário de 
classes de cada 
aula.
Aluno, data, 
frequência.
Fonte: Elaborado pelo autor.
A seguir serão apresentados os passos para a construção do Diagrama de Clas-
ses de nível 1.
3.3.1.1 Passo 1 – Identificação das classes e seus atributos
De posse desses Requisitos, podemos identificar as seguintes classes: Aluno, 
Professor, Turma, Modalidade, Matricula, Diario.
Inicialmente, criamos um Diagrama de Classes contendo as classes e seus atri-
butos, como mostra a figura a seguir.
Figura 15
Identificação das classes
– cpf : numero 
– nome : texto 
– endereco : texto
– codigo : numero 
– data : data
– data : data 
– frequentou : boolean 
– cpf : int 
– nome : texto 
– dataAdmissao : data 
– descricao : texto
– descricao : texto 
– valorMensalidade : int 
Aluno
Matricula 
Diario 
Professor
Modalidade 
Turma
Esta classe terá dois objetos: 
Natação 
Hidroginástica
As turmas nesta classe terão o seguinte formato: Turma 1 – 
Seg/Qua/Sex das 9h às 10h
Fonte: Elaborada pelo autor.
Algumas observações:
 • Note que foram colocados somente os atributos próprios de cada classe. Por 
exemplo, na classe Professor não foi colocado o atributo modalidade, que 
consta no Quadro 5, como um dos atributos de um professor. Isso ocorre 
porque Modalidade é uma outra classe, e a informação da modalidade em 
82 Análise de Sistemas
que o professor atua será representada pelo relacionamento entre Professor 
e Modalidade, que será colocado na sequência da construção do diagrama.
 • Na classe Turma não foi colocado o atributo professor da turma, pois existe 
uma classe Professor e essa informação (qual é o professor da turma) tam-
bém irá aparecer por meio de um relacionamento entre as classes Turma e 
Professor. O mesmo ocorre com a modalidade da turma.
 • A classe Matricula também não tem os atributos aluno e turma pelo mesmo 
motivo; serão feitos relacionamentos com essas classes.
 • Os quadros abaixo das classes Modalidade e Turma são explicativos e dão 
exemplo de quais serão os objetos das classes.
3.3.1.2 Passo 2 – Colocação dos relacionamentos entre as classes
Nesse passo, analisamos as classes para verificar quais relacionamentos deve-
mos colocar entre elas. Como vimos anteriormente, serão os relacionamentos que 
irão complementar as informações das classes.
 • Relacionamento 1: podemos perceber que a classe Aluno e a classe Profes-
sor têm atributos em comum (CPF e nome) e que aluno e professor são tipos 
de pessoa. Podemos então usar o relacionamento de herança, criando uma 
classe mãe chamada Pessoa, colocando nela esses dois atributos e relacio-
nando com as classes filhas Aluno e Professor, como mostra a Figura 16.
Figura 16
Herança entre Pessoa, Aluno e Professor
– endereco : texto – dataAdmissao : data
– cpf : numero 
– nome : texto
Aluno Professor
Pessoa

Fonte: Elaborada pelo autor.
 • Relacionamento 2: um professor poderá atuar em várias modalidades (por 
exemplo, pode dar aula de natação e de hidroginástica) e uma modalidade 
terá muitos professores. Então, identificamos que existe uma associação 
muitos-para-muitos entre as duas classes, como mostra a figura a seguir.
Objetos e classes 83
Figura 17
Associação entre as classes Professor e Modalidade
– endereco : texto – dataAdmissao : data
– descricao : texto
– cpf : numero 
– nome : texto
Aluno Professor
Modalidade 
Pessoa

Esta classe terá dois objetos: 
Natação 
Hidroginástica
*
*
Fonte: Elaborada pelo autor.
 • Relacionamento 3: uma turma terá um professor e um professor poderá 
atuar em várias turmas. Então, identificamos que existe uma associação 
1-para-muitos entre as duas classes, como mostra a figura a seguir.
Figura 18
Associação entre as classes Professor e Turma
– endereco : texto
– descricao : texto 
– valorMensalidade : int 
– dataAdmissao : data
– descricao : texto
– cpf : numero 
– nome : texto
Aluno
Turma 
Professor
Modalidade 
Pessoa

Esta classe terá dois objetos: 
Natação 
Hidroginástica
*
*
As turmas nesta classe terão o seguinte formato: 
Turma 1 – Seg/Qua/Sex das 9h às 10h
*
Fonte: Elaborada pelo autor.
84 Análise de Sistemas
 • Relacionamento 4: uma turma terá uma modalidade e uma modalidade terá 
várias turmas. Então, identificamos que existe uma associação 1-para-muitos 
entre as duas classes, como mostra a figura a seguir.
Figura 19
Associação entre as classes Turma e Modalidade
– endereco : texto
– descricao : texto 
– valorMensalidade : int 
– dataAdmissao : data
– descricao : texto
– cpf : numero 
– nome : texto
Aluno
Turma 
Professor
Modalidade 
Pessoa

Esta classe terá dois objetos: 
Natação 
Hidroginástica
*
*
As turmas nesta classe terão o seguinte formato: 
Turma 1 – Seg/Qua/Sex das 9h às 10h
*
*
Fonte: Elaborada pelo autor.
 • Relacionamento 5: a classe Matricula, por sua vez, deve ter a informação de 
qual aluno se matriculou e em qual turma. Se analisarmos as classes Aluno 
e Turma, podemos perceber que entre elas existe uma associação do tipo 
muitos-para-muitos, já que uma turma pode ter muitos alunos e um aluno 
pode ser de muitas turmas. Poderíamos então ter somente uma associação 
muitos-para-muitos. Porém, nesse caso específico, devemos guardar duas 
informações específicas dessa associação: o código e a data da matrícula. 
Temos caracterizado então o tipo de relacionamento classe de associação, 
como mostra a figura a seguir.
Objetos e classes 85
Figura 20
Classe de associação Matricula

– endereco : texto
– descricao : texto 
– valorMensalidade : int 
– dataAdmissao : data
– descricao : texto
– cpf : numero 
– nome : texto
Aluno
Turma 
– codigo : numero 
– data : data
Matricula
Professor
Modalidade 
Pessoa
Esta classe terá dois objetos: 
Natação 
Hidroginástica
*
*
As turmas nesta classe terão o seguinte formato: 
Turma 1 – Seg/Qua/Sex das 9h às 10h
*
*
Matricula
Fonte: Elaborada pelo autor.
 • Relacionamento 6: finalmente, temos o relacionamento da classe Diario, que 
deve registrar as frequências dos alunos nas turmas em que estão matriculados. 
Então, basta fazermos uma associação 1-para-muitos com a classe Matricula, na 
qual temos as informações dessas duas classes, como mostra a Figura 21.
Figura 21
Associação entre as classes Matricula e Diario
– cpf : numero 
– nome : texto
Pessoa

– endereco : texto
– descricao : texto 
– valorMensalidade : int 
– dataAdmissao : data
– descricao : texto
Aluno
Turma 
– codigo : numero 
– data : data
Matricula
– data : data 
– frequentou : boolean 
Diario 
Professor
Modalidade 
Esta classe terá dois objetos: 
Natação 
Hidroginástica
*
*
As turmas nesta classe terão o seguinte formato: 
Turma 1 – Seg/Qua/Sex das 9h às 10h
*
*
*
Matricula
Fonte: Elaborada pelo autor.
86 Análise de Sistemas
Com isso, finalizamos a construção do Diagrama de Classes de nível 1 com todas 
as classes relacionadas.
3.3.2 Diagrama de Classes de nível 2 
O Diagrama de Classes de nível 2 é uma expansão do nível 1, no qual são de-
talhados os atributos advindos das associações. Esses atributos são chamados de 
atributos associados ou atributos de ligação (RUMBAUGH et al., 1994).
Se analisarmos a associação entre as classes Modalidade e Turma, por exemplo, 
podemos perceber que uma turma é de uma modalidade. Sendo assim, podemos 
explicitar o atributo modalidade na classeTurma (aqui o termo modalidade está em 
letra minúscula porque segue o padrão para nomes de atributos). A figura a seguir 
mostra esse atributo na classe Turma e indica que o seu tipo é Modalidade (após o 
símbolo :), que está em letra maiúscula por se tratar de uma classe.
Figura 22
Indicação do atributo modalidade na classe Turma
*
– descricao : texto
Modalidade
– descricao : texto 
– valorMensalidade : int 
- modalidade : Modalidade
Turma
Fonte: Elaborada pelo autor.
Da mesma forma, se analisarmos o inverso, podemos perceber que uma mo-
dalidade é de várias turmas, então podemos explicitar o atributo turmas na classe 
Modalidade. Para representar que uma modalidade tem várias turmas, colocamos 
no tipo do atributo a indicação ArrayList, um termo usado em linguagens de progra-
mação para indicar uma lista. A Figura 23 mostra esse atributo na classe Modalida-
de e indica que o seu tipo é ArrayList (após o símbolo :). A leitura que se 
faz é a seguinte: uma Modalidade tem uma lista de turmas.
Figura 23
Indicação do atributo turmas na classe Modalidade
*
– descricao : texto
– turmas : ArrayList
Modalidade
– descricao : texto 
– valorMensalidade : int 
- modalidade : Modalidade
Turma
Fonte: Elaborada pelo autor.
Se colocarmos os atributos associados em todas as classes, o Diagrama de Clas-
ses de nível 2 ficará como mostra a figura a seguir.
Objetos e classes 87
Figura 24
Exemplo de Diagrama de Classes de nível 2
– cpf : numero 
– nome : texto
Pessoa

– endereco : texto
– matriculas: ArrayList
– dataAdmissao : data 
– turmas : ArrayList 
– modalidades: ArrayList 
– descricao : texto 
– valorMensalidade : numero 
– modalidade : Modalidade 
– matriculas : ArrayList
– codigo : numero 
– data : data 
– aluno : Aluno 
– turma : Turma 
– diarios : ArrayList 
– data : data 
– frequentou : boolean 
– matricula : Matricula
– descricao : texto 
– turmas : ArrayList 
– professores : ArrayList 
Aluno Professor
TurmaMatricula 
Diario 
Modalidade 
* *
*
*
*
Esta classe terá dois objetos: 
Natação 
Hidroginástica
Matricula
– As turmas nesta classe terão o seguinte 
formato: Turma 1 – Seg/Qua/Sex das 9h às 10h
Fonte: Elaborada pelo autor.
Podemos perceber que em nenhum momento da construção do Diagrama de 
Classes foram colocados os métodos das classes. O melhor momento para colocá-
-los é após a confecção dos Diagramas de Sequência. Após essa inclusão de méto-
dos, teremos em definitivo um Diagrama de Classes do sistema.
3.4 Diagrama de objetos 
Vídeo O Diagrama de Objetos tem por objetivo a visualização de alguns objetos nas 
classes. Com isso, é possível verificar se foram identificados todos os atributos ne-
cessários para as classes, se algum deles está na classe errada, e ter uma visão ge-
ral de como serão os objetos das classes quando o sistema for efetivamente usado.
88 Análise de Sistemas
Esse diagrama está amplamente associado ao Diagrama de Classes e pode ser 
considerado seu complemento, pois fornece uma visão dos valores armazenados 
pelos objetos em um determinado momento (GUEDES, 2018).
Segundo Melo (2010, p. 147), “o diagrama de objetos é muito útil para facilitar a 
modelagem de estruturas complexas de dados”. A construção desse diagrama tem 
como base o Diagrama de Classes de nível 1, em que cada classe é colocada e são 
atribuídos valores aos atributos ao lado de cada um deles (após os dois pontos, 
depois do nome do atributo e entre aspas).
Vamos usar como exemplo as classes Turma e Modalidade. Para cada classe, 
criamos um ou mais objetos em retângulos, cada um representando um objeto. 
Note que o nome do objeto reflete seu conteúdo e nos seus atributos são coloca-
dos valores.
Nesse exemplo, foram colocados três objetos da classe Turma, as turmas 1, 2 e 
3, e dois objetos da classe Modalidade, natação e hidroginástica. Esse exemplo está 
ilustrado na figura a seguir.
Figura 25
Exemplo dos objetos turma e modalidade
– descricao : Turma 1 Seg/Qua/Sex das 9h às 10h 
– valorMensalidade : 120,00
– descricao : “Natação”
 – descricao : “Hidroginástica”
– descricao : Turma 2 Ter/Qui das 8h às 9h 
– valorMensalidade : 110,00
– descricao : Turma 3 Seg/Qua das 7h às 8h 
– valorMensalidade : 230,00 
turma 1
modalidade Natação
modalidade Hidroginástica
turma 2
turma 3
Fonte: Elaborada pelo autor.
Podemos ter a visão de quais turmas teremos na Escola de Natação, suas 
informações e de quais modalidades elas serão. Esse é o objetivo do Diagrama 
de Objetos.
A figura a seguir mostra um Diagrama de Objetos completo do sistema da Es-
cola de Natação.
O vídeo História da Progra-
mação Orientada a Objetos, 
publicado pelo canal 
segunda.tech, apresenta 
alguns fatos bastante inte-
ressantes. Assista ao vídeo 
acessando o link a seguir.
Disponível em: https://www.youtube.
com/watch?v=UjpTvgau7mU. Acesso 
em: 17 mar. 2021.
Vídeo
Objetos e classes 89
Figura 26
Diagrama de Objetos da Escola de Natação
 – cpf : 12345678901 
– nome : “João da Silva” 
– endereco : “Rua das Carmelitas, 20” 
– codigo : 1070 
– data : “10/03/2020”
– cpf : 3765487611 
– nome : “José da Silva” 
– dataAdmissao : “01/02/2005” 
aluno João
matricula João na turma 1
– data : “10/11/2020” 
– frequentou : “Sim” 
– data : “11/11/2020” 
– frequentou : “Não” 
diario de 10/11/2020 diario de 11/11/2020
professor José
matrícula João na turma 1 
– descricao : Turma 1 Seg/Qua/Sex das 9h às 10h 
– valorMensalidade : 120,00
– descricao : “Natação”
 – descricao : “Hidroginástica”
– descricao : Turma 2 Ter/Qui das 8h às 9h 
– valorMensalidade : 110,00
– descricao : Turma 3 Seg/Qua das 7h às 8h 
– valorMensalidade : 230,00 
turma 1
modalidade Natação
modalidade Hidroginástica
turma 2
turma 3
Fonte: Elaborada pelo autor.
Esse diagrama mostra que a turma 1 é da modalidade natação e tem o profes-
sor José e o aluno João, que frequentou a aula no dia 10/11/2020 e faltou no dia 
11/11/2020.
Com isso, é possível termos uma visão geral de como serão os objetos que irão 
compor o sistema.
90 Análise de Sistemas
CONSIDERAÇÕES FINAIS
Este capítulo trouxe uma importante abordagem a ser feita para a modelagem de 
um sistema. A estruturação de objetos e classes, por meio de um Diagrama de Clas-
ses, é de vital importância para o sucesso do sistema. Sua estrutura irá balizar toda a 
arquitetura de implementação do sistema em termos de linguagens de programação 
e banco de dados.
Fazer um bom Diagrama de Classes facilita o trabalho do analista de sistemas de 
conduzir a equipe de programação e também dos próprios programadores, que terão 
uma visão geral da arquitetura criada como solução do problema.
ATIVIDADES 
1. Explique o que é uma classe.
2. Quais são os cinco tipos de relacionamentos entre classes?
3. Qual é o objetivo de um Diagrama de Objetos?
REFERÊNCIAS 
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 12. ed. Rio de Janeiro: Elsevier, 2012.
DEBONI, J. E. Z. Modelagem Orientada a Objetos com a UML. São Paulo: Futura, 2003.
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2018.
MELO, A. C. Desenvolvendo aplicações com UML 2.2. Rio de Janeiro: Brasport, 2010.
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. São Paulo: Campus, 1994.
Diagrama de Sequência 91
4
Diagrama de Sequência
Neste capítulo iremos conhecer o Diagrama de Sequência, um im-
portante artefato da UML que colabora para o desenho da arquitetura 
do sistema.
A modelagem de um sistema usando a UML se baseia em três pilares. 
O primeiro deles corresponde à visão dos processos, da organização dos 
Requisitos, das funções do sistema. Para a modelagem desses quesitos, 
trabalhamos com o Diagrama de Caso de Uso, a Prototipação de telas e as 
Histórias de Usuário. O segundo pilar é voltado à visão dos objetos e das 
classes, na qual, além de listar todos os objetos envolvidos no problema, 
identificamos seus atributos e o relacionamento entre essas classes.O 
terceiro pilar da UML é justamente a ligação desses dois primeiros por 
meio do Diagrama de Sequência.
Iremos aprender todos os elementos, bem como o modo de construir 
esse diagrama.
4.1 Elementos do Diagrama de Sequência 
Vídeo Um Diagrama de Sequência é construído partindo das Histórias de Usuário e 
do Diagrama de Classes, ou seja, construímos esse diagrama olhando tanto para 
a visão de processos (Casos de Uso e Histórias de Usuário) quanto para a visão de 
objetos e classes (Diagrama de Classes).
Percebemos na construção das Histórias de Usuário que nelas é detalhado o 
funcionamento de uma determinada tela com campos e botões. Para o preenchi-
mento do conteúdo de alguns campos, é necessário que se busquem os valores 
dos atributos de classes do Diagrama de Classes; o mesmo ocorre quando um 
usuário preenche os campos da tela e pressiona um botão em que esses valores 
digitados devem ser salvos no sistema. Para que isso ocorra, devem existir classes 
com atributos iguais aos campos da tela.
Uma classe tem atributos e métodos, e seus métodos são os únicos que têm 
permissão para manipular seus atributos. Quando uma tela é preenchida, temos 
de transferir de alguma forma esses valores digitados para os atributos da classe 
responsável por eles. Sendo assim, primeiramente devemos saber em qual clas-
se estão esses campos da tela e, em seguida, criar métodos capazes de transferir 
os valores digitados para os atributos dessa classe. O mesmo ocorre quando é 
92 Análise de Sistemas
necessário preencher campos de uma tela com valores de atributos de classes. 
Devemos primeiramente identificar qual classe possui esses atributos e, após isso, 
invocar métodos que façam a leitura dos valores desses atributos, a fim de que 
sejam transferidos para os campos da tela.
O Diagrama de Sequência procura então determinar quais métodos de quais 
classes devem ser invocados e em qual ordem (sequência), para a realização com-
pleta dos eventos da tela. Seu objetivo principal é identificar a ordem em que os 
eventos ocorrem e determinar os métodos que serão chamados para atender a 
esses eventos, refletindo assim a interação entre os objetos envolvidos em um de-
terminado processo (GUEDES, 2018).
Basicamente, esse diagrama “dá ênfase à ordenação temporal das mensagens” 
entre os objetos (BOOCH; RUMBAUGH; JACOBSON, 2012, p. 276).
A figura a seguir ilustra essa situação. Na parte de cima, temos um exemplo de 
tela de empréstimo de livros em uma biblioteca. Na parte de baixo, há um Diagra-
ma de Classes do sistema. As setas indicam as classes que estão sendo acessadas 
para que os campos da tela sejam preenchidos com valores armazenados nos atri-
butos, bem como as transferências de valores colocados na tela para os atributos.
Figura 1
Exemplo de interação entre uma tela e o Diagrama de Classes



- nome : int >
Autor
- ISBN : int
- titulo : int
Livro
- nome : int
Editora
- dataDevolucao : int
LivroEmprestimo
LivroEmprestimo
- nome : int
Usuario
Sistema de biblioteca – Empréstimo de livros
Insira o código do livro:
Livros selecionados:
Código           Título         Autores             Ação
CPF do usuário: Nome:
Data de retirada: 24/11/2020
Confirmar empréstimo   Cancelar
Data de devolução prevista: 10/12/2020
*
- nome : int
- dataEmprestimo : int
Funcionario
Emprestimo
*
**
Fonte: Elaborada pelo autor.
Diagrama de Sequência 93
Ao inserir o código de um livro que o usuário deseja emprestar, as setas trace-
jadas indicam o caminho que o sistema deve percorrer para buscar os atributos 
a serem carregados na tela. Nesse caso, será acessada a classe Livro para buscar 
o código (ISBN) e o título; o acesso à classe Autor serve para buscar os autores do 
livro; também poderia ser acessada a classe Editora, se fosse necessário buscar seu 
nome. Após esses acessos, os atributos são colocados no grid da tela.
Após isso, o usuário informa seu CPF e, na tela, deve ser apresentado seu nome. 
A seta contínua simboliza o acesso à classe Usuario para realizar essa busca.
Finalmente, ao pressionar o botão “Confirmar empréstimo”, o sistema deve in-
vocar as classes para armazenar o empréstimo. As setas pontilhadas simbolizam o 
acesso à classe Emprestimo, na qual é armazenada a data do empréstimo (atributo 
dessa classe), e à classe LivroEmprestimo em seguida, para armazenar os livros se-
lecionados. Será justamente essa sequência de acessos às classes que o Diagrama 
de Sequência irá representar.
A Figura 2 mostra um exemplo completo de Diagrama de Sequência de uma His-
tória de Usuário denominada Realizar Transferências em um caixa eletrônico. Todos 
os elementos nela contidos serão mostrados em detalhes nas seções seguintes.
Figura 2
Exemplo de Diagrama de Sequência
: Cliente
Interface
Caixa
Automático
Conta Saldo
1: Inserir Cartão() 1.1: verificarConta()
{Conta Válida}
{Solicitar Senha}
{Transferência OK}
5.2: creditar()
5.1: debitar()
2: Fornecer Senha()
2.1: validarSenha()
{Senha Válida}
{Apresentar Menu}
3: Selecionar Transferência()
{Solicitar Conta Crédito}
4: Informar Conta()
4.1: verificarConta()
{Conta Válida}
{Solicitar Valor}
5: Informar Valor()
Fonte: Elaborada pelo autor.
94 Análise de Sistemas
Podemos perceber então que, pela troca de mensagens entre os objetos, esse 
diagrama fornece uma visão dinâmica do processo, diferentemente dos Diagramas 
de Caso de Uso e de classes, que dão uma visão estática (DEBONI, 2003).
4.1.1 Elementos
A seguir veremos os principais elementos que podem ser utilizados em um Dia-
grama de Sequência.
4.1.1.1 Ator
Os atores utilizados em um Diagrama de Sequência são os mesmos que cons-
tam no Diagrama de Caso de Uso. Se uma tela pertence a uma História de Usuário 
que, por sua vez, está relacionada a um caso de uso do Diagrama de Caso de Uso, 
ela então está ligada a um determinado ator. Esse será o ator representado no 
Diagrama de Sequência.
Os atores solicitam serviços ao sistema e iniciam e/ou finalizam um determina-
do processo (GUEDES, 2018).
Nesse diagrama, os atores serão representados por um boneco magro, tal qual 
no Diagrama de Caso de Uso, porém aqui o ator terá uma linha da vida.
A linha da vida indica os momentos em que o ator está interagindo com a tela. 
Se ela estiver pontilhada, indica que o ator não está manipulando a tela. Caso a 
linha esteja no formato de um retângulo fino, indica que ele está informando ou 
recebendo dados da tela, ou realizando alguma ação. Também dizemos que o ator 
está ativo/inativo quanto ao manuseio da tela.
A Figura 3 mostra um exemplo do ator Usuario de uma biblioteca. Note que 
abaixo de sua representação foi colocada uma linha pontilhada.
Figura 3
Exemplo de ator no Diagrama de Sequência
: Ator Usuario
Fonte: Elaborada pelo autor.
Após os demais elementos serem explicados, veremos exemplos em que a linha 
da vida do ator se transforma em uma linha ativa.
Diagrama de Sequência 95
4.1.1.2 Objeto
No Diagrama de Sequência, usamos os objetos das classes envolvidas no pro-
cesso. Eles são representados com um retângulo e também contam com uma linha 
da vida; esta representa o tempo em que um objeto existiu durante um processo, 
ou seja, os momentos em que seus métodos foram executados.
A linha da vida do objeto também é pontilhada, assim como a do ator. No mo-
mento em que algum método da sua classe for invocado, a linha se transforma em 
um retângulo fino, indicando que ela ficou ativa. Essa representação também será 
vista após os demais elementos do diagrama.
A representação geral de um objeto e de uma classe no Diagrama de Sequência 
é mostrada na figura a seguir. Primeiramente é colocado o nome do objeto, depois 
o sinal de dois pontos e, finalmente, o nome da classe. O nome do objeto é opcio-
nal, então é comum que ele seja representado com dois pontos no início seguidos 
do nome da classe. A Figura 4 mostra esses dois casos.
Figura 4
Exemplo de objeto/classe no Diagrama de Sequência
: Classeobjeto : Classe
Fonte: Elaborada pelo autor.
Jáa Figura 5 mostra um exemplo de um objeto da classe Livro do sistema de 
biblioteca.
Figura 5
Exemplo de objeto no Diagrama de Sequência
: Livro
Fonte: Elaborada pelo autor.
É importante ressaltar que os objetos usados no diagrama devem ser os mes-
mos das classes do Diagrama de Classes. Isso significa que não tem sentido colocar 
objetos novos que não constem no Diagrama de Classes. Como exceção, temos as 
classes que representam a tela; elas obviamente não estão no Diagrama de Classes.
96 Análise de Sistemas
4.1.1.3 Estereótipo boundary
Um estereótipo boundary é um objeto especial que representa uma tela a ser 
manipulada pelo usuário.
A Figura 6 representa a tela que, no exemplo do sistema de biblioteca, é a tela 
Empréstimos de Livros.
Figura 6
Exemplo de objeto representando uma tela
Livros : Boundary()
Tela Empréstimo de
Fonte: Elaborada pelo autor.
Assim como veremos na construção completa do diagrama, ele começa com 
o ator, que sempre interage com a tela e, em seguida, com os demais objetos das 
classes do sistema envolvidos no processo da tela.
4.1.1.4 Mensagens
As mensagens são utilizadas para invocar um método de uma classe.
Como esse diagrama tem o objetivo de representar a sequência de chamadas 
dos métodos das classes, para que uma tela realize completamente sua função, 
usamos as mensagens nessa representação.
Basicamente, as mensagens são enviadas de um objeto para outro, da linha da 
vida de um objeto até a linha da vida de outro objeto (MELO, 2010).
Elas serão representadas por setas que saem do ator ou dos objetos e apontam 
para outros objetos. Na legenda dessas setas, serão colocados os nomes dos méto-
dos que estão sendo invocados. Somente na comunicação entre o ator e a tela essa 
legenda não indicará um método, mas sim uma ação do ator ou uma informação 
que o ator está colocando na tela.
A Figura 7 mostra um exemplo de mensagem entre o ator Usuario e a tela Em-
préstimos de Livros. Na legenda da mensagem (seta apontando para a tela), foi 
colocada a informação que o usuário está inserindo na tela (código do livro).
Diagrama de Sequência 97
Figura 7
Exemplo de mensagem entre ator e tela
: Ator Usuario
1: Código do Livro() 
Tela Empréstimo de
Livros : Boundary()
Fonte: Elaborada pelo autor.
Podemos perceber agora que a linha da vida, tanto do ator quanto da tela, 
transformou-se de uma linha pontilhada em um retângulo fino, indicando que o 
ator e a tela estão ativos e realizando alguma ação.
Esse retângulo permanecerá dessa forma até que o processo termine, transfor-
mando-se novamente em linha pontilhada.
O segundo exemplo, apresentado na Figura 8, mostra uma mensagem entre 
dois objetos: a tela Empréstimo de Livros e o objeto livro. Na legenda da mensagem 
(seta apontando para o objeto livro), foi colocado o nome do método que se deseja 
invocar, nesse caso é buscarLivro(). Note que esse nome de método está no padrão 
para esses nomes.
Figura 8
Exemplo de mensagem entre a tela e o objeto livro
1.1: buscarLivro()
1: Código do Livro()
Livros : Boundary()
Tela Empréstimo de: Ator Usuario
: Livro
Fonte: Elaborada pelo autor.
O número 1, que precede a legen-
da Código do Livro, é um número 
sequencial que será colocado em 
todas as mensagens, para ajudar 
na visualização da sequência 
de mensagens. Já o símbolo de 
abrir parênteses e fechar 
parênteses, colocado após a 
mensagens, servirá para que, na 
representação de métodos entre 
as classes, possam ser colocados 
os parâmetros que devem ser 
enviados aos métodos, o que não 
se aplica à interação entre o ator 
e a tela.
Importante
98 Análise de Sistemas
O terceiro exemplo, apresentado na Figura 9, mostra uma mensagem entre dois 
objetos: o objeto livro e o objeto autor. Na legenda da mensagem (seta apontando 
para o objeto autor), foi colocado o nome do método que se deseja invocar, nesse 
caso é buscarAutores().
Figura 9
Exemplo de mensagem entre o objeto livro e o objeto autor
1.1: buscarLivro()
1: Código do Livro()
Livros : Boundary()
Tela Empréstimo de: Ator Usuario
: Livro : Autor
1.1.1: buscarAutores()
Fonte: Elaborada pelo autor.
4.1.1.5 Autochamadas
Também denominadas autodelegações, as autochamadas são mensagens que um 
objeto passa para si mesmo. São usadas quando se deseja invocar um método da 
própria classe. Elas são representadas por setas que apontam para o próprio objeto.
No exemplo da Figura 10, suponha que, no objeto autor, queiramos um método 
para formatar os nomes dos autores antes de devolver a informação para o objeto 
livro. Assim, no próprio objeto autor, poderíamos ter o método formatarNomes e 
usaríamos uma autochamada para invocá-lo.
Figura 10
Exemplo de autochamadas
1.1.1.1: formatarNomes()
1.1.1: buscarAutores()
1.1: buscarLivro()
1: Código do Livro() 
: Autor: Livro 
Tela Empréstimo de 
Livros : Boundary()
: Ator Usuario 
Fonte: Elaborada pelo autor.
As autochamadas também são utilizadas para representar a chamada de outras Histórias 
de Usuário.
Diagrama de Sequência 99
4.1.1.6 Retorno
Após a invocação de um método de uma classe, é possível fazer o retorno ao 
objeto que o chamou. É comum que todas as chamadas (setas) tenham um retorno 
até chegarem ao ator que iniciou a sequência de chamadas. Esse retorno ao ator 
indica que o controle da tela foi devolvido para ele, ou seja, a tela foi novamente 
apresentada para que a próxima ação seja realizada. O retorno é representado por 
uma seta pontilhada com ou sem uma legenda.
A Figura 11 mostra o retorno de todas as chamadas realizadas até o momento, 
no exemplo da tela Empréstimo de Livros até a volta ao ator.
Figura 11
Exemplo de retorno
1.1.1.1: formatarNomes()
1.1.1: buscarAutores()
1.1: buscarLivro()
1: Código do Livro()
: Autor: Livro
Livros : Boundary()
Tela Empréstimo de: Ator Usuario
Fonte: Elaborada pelo autor.
Esses são os principais elementos que podem ser utilizados em um Diagrama 
de Sequência.
Vale ressaltar que esse diagrama não trata de todo o processo de empréstimo 
de livros, somente seu início. Ele foi construído para mostrar os elementos do dia-
grama. A construção de um diagrama completo será vista na próxima seção.
A Figura 12 mostra um resumo dos principais elementos.
Figura 12
Principais elementos de um Diagrama de Sequência
linha da vida inativa
linha da vida 
ativa
mensagem
autochamada
retorno
1.1.2: mensagem2()
1.1.1: autochamada1()
interação 
do autor
1.1: mensagem1()
1: Ação do usuário()
: Classe1
Tela : Boundary()
classe : 
Classe
objetoobjeto
estereótipoator
: Ator
Fonte: Elaborada pelo autor.
100 Análise de Sistemas
Pudemos aprender que é importante fazer um Diagrama de Sequência para 
cada uma das Histórias de Usuário (tela). Em cada diagrama, colocamos a chamada 
de métodos das classes. Ao final do trabalho de construção de todos os Diagramas 
de Sequência, teremos então todos os métodos em todas as classes do Diagrama 
de Classes.
O Diagrama de Classes primeiramente é construído somente com atributos. Os 
métodos das classes seriam colocados após a construção dos Diagramas de Se-
quência; agora, estamos vendo exatamente como eles surgiram.
A seguir, construiremos um Diagrama de Sequência completo do problema da 
Escola de Natação.
4.2 Práticas do Diagrama de Sequência 
Vídeo O objetivo desta seção é construir um Diagrama de Sequência completo, cobrin-
do todo o processo de uma História de Usuário (tela). Para isso, iremos utilizar o 
caso do problema da Escola de Natação.
Como foi citado anteriormente, devemos construir um Diagrama de Sequência 
para cada tela; para isso, iremos escolher a tela Realizar matrícula na escola.
Devemos lembrar que o diagrama é construído a partir dos seguintes elemen-
tos: Diagrama de Caso de Uso, Diagrama de Classes e protótipo de tela que consta 
na História de Usuário.
Para facilitar a visualização da construção do diagrama, a Figura 13 apresenta o 
Diagrama de Caso de Uso da Escola de Natação.
Figura 13
Diagrama de Caso de Uso da Escola de Natação
Professor
>Atendente
>>
Manter Aluno
aluno
Pesquisar turma
Pesquisar
professor
Pesquisar
professor
Manter
Manter turmaManter aluno
matrícula
Realizar
frequência
Registrar
Fonte: Elaborada pelo autor.
Já a Figura 14 apresenta o Diagrama de Classes desse estudo de caso.
Diagrama de Sequência 101
Figura 14
Diagrama de Classes da Escola de Natação

Hidroginástica
Natação
Esta classe terá dois objetos:
– descricao : texto
Modalidade
As turmas nesta classe terão o seguinte formato: 
Turma 1 Seg/Qua/Sex das 9h às 10h
– descricao : texto
– valorMensalidade : int
Turma
Matricula
– data : data
– frequentou : boolean
Diario
– codigo : numero
– data : data
Matricula
*
*
*
*
*
 
– dataAdmissao : data
Professor
– endereco : texto
Aluno
– cpf : numero
– nome : texto
Pessoa
Fonte: Elaborada pelo autor.
A Figura 15 mostra o protótipo da tela Realizar matrícula na Escola de Natação.
Figura 15
Protótipo da tela Realizar matrícula
Voltar Efetivar matrícula
Mensalidade:
Professor:
Turma 1 – Seg/Qua/Sex – 10h às 11hTurma: 
NataçãoModalidade:
Nome: 
PesquisarCPF:
Realizar matrícula
Escola de Natação 
Fonte: Elaborada pelo autor.
A seguir construiremos o Diagrama de Sequência seguindo um passo a passo. Nele 
serão acrescentados e explicados os componentes do diagrama.
4.2.1 Construção do Diagrama de Sequência da tela Realizar 
matrícula 
4.2.1.1 Passo 1 – Identificação do ator
O diagrama deve ser iniciado pelo ator que irá interagir com a tela. Para essa 
identificação, recorremos ao Diagrama de Caso de Uso e verificamos que o ator 
102 Análise de Sistemas
Atendente é quem está ligado ao caso de uso Realizar matrícula, conforme mostra 
a Figura 13 do Diagrama de Caso de Uso.
A Figura 16 mostra o início da construção, com o ator Atendente e a sua linha 
da vida.
Figura 16
Passo 1
: Atendente
Fonte: Elaborada pelo autor.
4.2.1.2 Passo 2 – Colocação do estereótipo boundary 
O próximo elemento que iremos colocar no diagrama é a representação da tela 
com a qual o ator irá interagir. Vimos que essa representação é chamada estereó-
tipo boundary. Então, nesse passo, iremos colocar esse elemento no diagrama, re-
presentando a tela Realizar matrícula (Figura 15).
A Figura 17 mostra essa representação.
Figura 17
Passo 2
Boundary()
Tela Realizar Matrícula :: Atendente
Fonte: Elaborada pelo autor.
4.2.1.3 Passo 3 – Primeira interação do ator com a tela
A primeira interação do ator Atendente com a tela ocorre quanto ele a aciona 
para que seja apresentada. Não precisamos nesse momento saber como ela será 
acionada: se por meio de um menu no sistema ou por um botão de alguma outra 
tela do sistema; o que importa é que, de alguma forma, ela será acionada.
A Figura 18 mostra essa representação com uma mensagem entre o ator Aten-
dente e a tela, com a legenda Aciona Tela. Note que a linha da vida de ambos, que 
estava pontilhada (inativa), tornou-se um retângulo, significando que ficou ativa.
Diagrama de Sequência 103
Figura 18
Passo 3
Tela Realizar Matrícula :: Atendente
Boundary()
1 : Aciona Tela( )
Fonte: Elaborada pelo autor.
4.2.1.4 Passo 4 – Mensagem entre a tela e o objeto 
Agora, se analisarmos os campos da tela, podemos perceber que o campo mo-
dalidade já deve vir preenchido com todas as modalidades cadastradas, quando a 
tela for apresentada pela primeira vez. Temos então que representar o acesso a 
essa classe para buscar suas informações, a fim de que sejam colocadas no campo 
respectivo da tela.
A Figura 19 mostra essa representação com uma mensagem entre a tela e 
o objeto modalidade. Na mensagem foi dado o nome pesquisar para o método 
que faz esse acesso, indicando que ele irá pesquisar e trazer todas as modali-
dades cadastradas.
Figura 19
Passo 4
Boundary4
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()
1: Aciona Tela()
: Modalidade 
Fonte: Elaborada pelo autor.
4.2.1.5 Passo 5 – Mensagem entre os objetos modalidade e turma
Da mesma forma, temos mais um campo da tela que também deve estar preen-
chido no momento da primeira apresentação. O campo turma deve vir com todas 
as turmas da modalidade, que está selecionada no campo modalidade. Então, de-
vemos chamar um método de sua classe para buscá-las. Essa ação trará o atributo 
valorMensalidade, que está na classe Turma, para ser colocado no campo da tela.
104 Análise de Sistemas
A Figura 20 mostra essa representação com uma mensagem entre o objeto moda-
lidade e o objeto turma. Na mensagem, foi dado o nome pesquisar para o método que 
faz esse acesso, indicando que ele irá pesquisar e trazer todas as turmas cadastradas.
Figura 20
Passo 5
1.1.1: pesquisar()
Boundary4
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()
1: Aciona Tela()
: Modalidade : Turma
Fonte: Elaborada pelo autor.
4.2.1.6 Passo 6 – Mensagem entre os objetos turma e professor
Olhando para os campos da tela, podemos perceber que, além da descrição da 
turma e do valor da mensalidade (atributos já acessados no objeto turma), preci-
samos mostrar o nome do professor da turma. Esse atributo pertence ao objeto 
professor. Sendo assim, temos de acrescentar agora uma invocação a um método 
desse objeto para buscar os dados do professor. Note que o atributo nome, que 
está sendo buscado, não está colocado diretamente no objeto professor, porém 
não devemos esquecer que a classe Professor está relacionada por meio de uma 
herança da classe Pessoa, na qual consta esse atributo. No Diagrama de Sequência, 
basta representar o objeto professor para fazer esse acesso.
A Figura 21 mostra essa representação com uma mensagem entre os objetos 
turma e professor. Na mensagem foi dado o nome ler para o método que faz esse 
acesso e realiza a leitura dos dados do professor de uma turma.
Figura 21
Passo 6
1.1.1.1: ler()
1.1.1: pesquisar()
Boundary4
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()
1: Aciona Tela()
: Modalidade : Turma : Professor 
Fonte: Elaborada pelo autor.
Diagrama de Sequência 105
4.2.1.7 Passo 7 – Retornos para apresentação da tela
Já que todas as informações necessárias para a primeira apresentação da tela 
foram acessadas nos respectivos objetos, agora temos de fazer o retorno até o 
ator, representando que a tela está sendo apresentada (pela primeira vez), para 
que ele comece a colocar as informações com o intuito de realizar a matrícula.
A Figura 22 mostra a representação dos retornos, desde o objeto professor até 
o ator Atendente.
Figura 22
Passo 7
1.1.1.1: ler()
1.1.1: pesquisar()
Boundary4
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()
1: Aciona Tela()
: Modalidade : Turma : Professor 
Fonte: Elaborada pelo autor.
4.2.1.8 Passo 8 – Inserção do CPF do aluno pelo ator
Com essa última representação do diagrama, a tela está sendo apresentada 
pela primeira vez ao ator Atendente. A primeira informação que ele deve inserir na 
tela é o CPF do aluno que deseja se matricular.
Essa ação está representada na Figura 23.
Figura 23
Passo 8
2: CPF do aluno()
1.1.1.1: ler()
1.1.1: pesquisar()
Boundary4
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()
1: Aciona Tela()
: Modalidade : Turma : Professor 
Fonte: Elaborada pelo autor.
106 Análise de Sistemas
4.2.1.9 Passo 9 – Busca do nome do aluno
Podemos perceber que na tela existe o campo nome do aluno, que deve ser 
apresentado. Então, nesse passo do diagrama, com o CPF digitado na tela, deve-
mos chamar um método do objeto aluno, no qual temos o CPF e o nome do aluno.
A Figura 24 mostra essa representação com uma mensagem entre a tela e o ob-
jeto aluno. Na mensagem foi dado o nome ler para o método que faz esse acesso. 
Também já está feita a representação dos retornos para a tela.
Figura 24
Passo 9
2.1: ler()
2: CPF do aluno()
1.1.1.1: ler()
1.1.1: pesquisar()
Boundary4
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()1: Aciona Tela()
: Modalidade : Turma : Professor : Aluno
Fonte: Elaborada pelo autor.
4.2.1.10 Passo 10 – Efetivação da matrícula
Agora, o ator Atendente está olhandopara a tela com todas as informações 
disponíveis para a efetivação da matrícula. Com o CPF informado, o nome do 
aluno que deseja se matricular e um campo para selecionar a modalidade que 
ele deseja, ao escolher a modalidade, o sistema mostra as turmas (com o nome 
do professor e o valor da mensalidade). Portanto, só nos resta agora pressionar 
o botão “Efetivar matrícula”.
A Figura 25 mostra essa representação com uma mensagem entre o ator Aten-
dente e a tela. Na legenda foi colocada a ação que o atendente realizou, ou seja, 
pressionar o botão “Efetivar matrícula”.
Diagrama de Sequência 107
Figura 25
Passo 10
2.1: ler()
2: CPF do aluno()
 1.1.1.1: ler()
1.1.1: pesquisar()
Boundary4
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()1: Aciona Tela()
: Modalidade : Turma : Professor : Aluno
3: Efetivar matricula()
Fonte: Elaborada pelo autor.
4.2.1.11 Passo 11 – Inclusão da matrícula no sistema
Por fim, com a solicitação do ator Atendente de efetivar a matrícula, o sistema deve 
acessar um método do objeto matrícula, responsável por incluir a matrícula no siste-
ma. Essa inclusão nada mais é do que um novo objeto da classe Matricula, na qual são 
registrados o código, a data da matrícula, o aluno e a turma em que ele se matriculou.
A Figura 26 mostra essa representação com uma mensagem entre a tela e o 
objeto matrícula. Na mensagem foi dado o nome incluir para o método que faz essa 
inclusão. Também já está feita a representação dos retornos para a tela.
Figura 26
Passo 11
3.1: incluir()
3: Efetivar matricula()
2.1: ler()
2: CPF do aluno()
 1.1.1.1: ler()
1.1.1: pesquisar()
Boundary4
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()
1: Aciona Tela()
: Modalidade : Turma : Professor : Aluno : Matricula
Fonte: Elaborada pelo autor.
108 Análise de Sistemas
Assim, está finalizada a construção do Diagrama de Sequência da História de 
Usuário Realizar matrícula do problema da Escola de Natação.
A tarefa agora é construir os diagramas de sequência para todas as telas do 
sistema, como apresentaremos na sequência.
4.2.2 Modelagem completa do estudo de caso da Escola de 
Natação
Nosso objetivo é mostrar todo o processo de modelagem de um sistema previsto 
na UML. Para isso, é necessário construir a Lista de Requisitos, o Diagrama de Caso de 
Uso, os Protótipos de Telas, as Histórias de Usuário, o Diagrama de Classes (níveis 1 e 
2) e, finalmente, os Diagramas de Sequência. Esses são os diagramas básicos da UML, 
que formam seus pilares, apesar de existirem outros opcionais e suplementares.
Agora, iremos finalizar a modelagem do estudo de caso da Escola de Natação 
com a construção dos Diagramas de Sequência das demais Histórias de Usuário, 
para, finalmente, complementar o Diagrama de Classes com os métodos das clas-
ses que surgiram durante a construção de todos os Diagramas de Sequência.
Vamos usar aqui o Diagrama de Caso de Uso de nível 2, pois nele constam todos 
os casos de uso que tiverem escritas as Histórias de Usuário, como mostra a Figura 27.
Figura 27
Diagrama de Caso de Uso de nível 2 da Escola de Natação
Professor
>
Atendente
>>
Manter Aluno
aluno
Pesquisar turma
Pesquisar
professor
Pesquisar
professor
Manter
Manter turmaManter aluno
matrícula
Realizar
frequência
Registrar
Fonte: Elaborada pelo autor.
Para cada caso de uso, iremos mostrar a sua tela e o seu respectivo Diagrama de 
Sequência. Não colocaremos aqui todas as descrições das Histórias de Usuário, pois 
elas são extremamente longas. Sendo assim, foram colocadas somente suas telas.
Diagrama de Sequência 109
A Figura 28 mostra as telas das Histórias Pesquisar aluno e Manter aluno (lado 
esquerdo) e seus respectivos Diagramas de Sequência (lado direito).
A Figura 29 mostra as telas das Histórias Pesquisar professor e Manter profes-
sor (lado esquerdo) e seus respectivos Diagramas de Sequência (lado direito).
(Continua)
Figura 28
Tela e Diagrama de Sequência – Pesquisar e Manter aluno
2.1: salvar()
2: Salvar()
1.1: ler()
: Aluno
Boundary2
Tela Manter Aluno :: Atendente
1: Aciona Tela()
VoltarSalvar
Endereço
Telefone:
CPF:
Nome:
Manter alunos
Escola de Natação
: Aluno
2.1: Chama HU – Manter Aluno()
2: Novo Aluno()
Tela Pesquisar Aluno:
Boundary2
: Atendente
1.1: pesquisar()
1: Aciona Tela()
Alterar Excluir99987-872398765432101
Pesquisa:VoltarNovo aluno
Pesquisar alunos
Escola de Natação
AçõesNome CPF Telefone
12345678901 98765-8752 Alterar ExcluirJoaquim José da Silva Xavier
Patricia Amaral
Fonte: Elaborada pelo autor.
Figura 29
Tela e Diagrama de Sequência – Pesquisar e Manter professor
: Aluno
: Atendente
1.1: pesquisar()
1: Aciona Tela()
2.1: Chama HU – Manter Professor()
2: Novo Professor()
Professor: Boundary2
Tela Pesquisar
Alterar Excluir02/02/202083655432101
Pesquisa:VoltarNovo professor
Pesquisar professores
Escola de Natação
AçõesNome CPF Data Admissão
Arnaldo Antunes 12348543901 13/12/2019 Alterar Excluir
Márcia Cristina
110 Análise de Sistemas
: Atendente
2.1: salvar()
2: Salvar()
1.1: ler()
1: Aciona Tela()
: Professor
Boundary2
Tela Manter Professor :
Salvar Voltar
Manter professores
Escola de Natação
Data Admissão :
CPF :
Nome :
Fonte: Elaborada pelo autor.
Figura 30
Tela e Diagrama de Sequência – Pesquisar e Manter turma
Alterar Excluir
Pesquisa:Voltar
Escola de Natação
Ações
Alterar Excluir
120,00HidroginásticaTurma 2 – Ter/Qui – 8h às 9h
110,00NataçãoTurma 1 – Seg/Qua/Sex – 9h às 10h
MensalidadeModalidadeDescrição
Nova turma
Pesquisar turmas 
: Atendente
1.1: pesquisar()
1: Aciona Tela()
2: Nova Turma()
: Turma
2.1: Chama HU – Manter Turma()
Boundary2
Tela Pesquisar Turma :
Salvar Voltar
Manter turmas
Escola de Natação : Atendente
2.1: salvar()
2: Salvar()
1.1: ler()
1: Aciona Tela()
: Turma
Boundary2
Tela Manter Turma :
NataçãoModalidade:
Mensalidade:
Descrição:

Fonte: Elaborada pelo autor.
A Figura 30 mostra as telas das Histórias Pesquisar turma e Manter turma (lado 
esquerdo) e seus respectivos Diagramas de Sequência (lado direito).
A Figura 31 mostra a tela da História Registrar frequência (parte superior) e seu 
respectivo Diagrama de Sequência (parte inferior).
Diagrama de Sequência 111
Figura 31
Tela e Diagrama de Sequência – Registrar frequência
 
: Turma : Aluno: Matricula
2: registrarFrequencia()
1.1.1.1: ler()
1.1.1: pesquisar()
1.1: ler()
1: Acionar Tela()
: Diario
: Boundary3
Tela Registrar Frequência: Ator Professor
Registrar frequênciaPatricia Amaral
Registrar frequênciaJoaquim José da Silva Xavier
Ação
 Turma 1 – Seg/Qua/Sex – 10h às 11hTurma:
Registrar frequência
Escola de Natação
Voltar

Nome
Fonte: Elaborada pelo autor.
Após a construção de todos os Diagramas de Sequência e, por conseguinte, a 
criação de todos os métodos, finalmente terminamos a modelagem do sistema, 
apresentando o Diagrama de Classes completo, com atributos e métodos, como 
mostra a Figura 32.
Figura 32
Diagrama de Classes completo da Escola de Natação
+ pesquisar() : void
– descricao : texto
Modalidade
+ pesquisar() : void
+ salvar() : void
+ ler() : void
– descricao : texto
Turma
Matricula
+ registrarFrequencia() : void
– frequentou : boolean
– data : data
Diario
+ incluir() : void
+ pesquisar() : void 1
– data : data
– codigo : numero
Matricula

Pessoa
– nome : texto
– cpf : numero


+ pesquisar() : void
+ salvar() : void
+ ler() : void
– dataAdmissao : data
Professor
+ pesquisar() : void
+ salvar() : void
+ ler() : void
– endereco : texto
Aluno
*
*
*
*
*
Fonte: Elaborada pelo autor.
Na sequência, veremos outros elementos utilizados para estruturar o Diagrama 
de Sequência.
O termo void após o nome 
dos métodos representa o 
tipo de dado que o método irá 
devolver. Nesse caso, como não 
foi determinado que tipo de dado 
cada método do diagrama irá 
retornar, usamos o termo void, 
que significa nenhum tipo.
1
112 Análise de Sistemas
4.3 Operadores do Diagrama de Sequência 
Vídeo Vimosque os Diagramas de Sequência foram construídos usando três elemen-
tos básicos: o ator, os objetos e as mensagens. Porém, existem outros elementos 
que podem ser utilizados para melhorar a estruturação do diagrama e para mos-
trar algumas situações que podem ocorrer ao longo dos processos.
Esses novos elementos são chamados de operadores e serão apresentados 
a seguir.
4.3.1 Operador REF
Esse operador tem por objetivo fazer uma referência a uma parte de outro Dia-
grama de Sequência; REF corresponde à abreviatura do termo em inglês reference. 
É utilizado quando uma parte do diagrama se repete em vários Diagramas de Se-
quência. Em vez de repetir essa parte nos diversos diagramas, ela é construída so-
mente uma vez, e os diagramas que necessitarem realizar o mesmo procedimento 
podem somente fazer uma referência a essa parte.
Para exemplificar esse operador, vamos analisar o Diagrama de Sequên-
cia Realizar matrícula, que construímos na seção anterior, repetido na figura 
a seguir.
Figura 33
Diagrama de Sequência Realizar matrícula
 
3.1: incluir()
3: Efetivar matricula()
2.1: ler()
2: CPF do aluno()
 1.1.1.1: ler()
1.1.1: pesquisar()
Boundary4
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()
1: Aciona Tela()
: Modalidade : Turma : Professor : Aluno : Matricula
Fonte: Elaborada pelo autor.
Podemos perceber que, no momento em que o ator Atendente insere o CPF do 
aluno, o sistema acessa o objeto aluno para buscar seus dados.
Vamos supor que esse procedimento de buscar os dados de um aluno se repita 
em vários outros Diagramas de Sequência do sistema. Desse modo, o uso do ope-
rador REF é justificado.
Diagrama de Sequência 113
Como mostra a Figura 34, o acesso ao objeto aluno foi trocado por um operador 
do tipo REF chamado Buscar aluno. Para isso, foi colocado um quadro na parte do 
diagrama original que fazia esse procedimento. Ele indica que essa busca do aluno 
se encontra em um outro Diagrama de Sequência.
Figura 34
Exemplo de operador REF
 
3.1: incluir()3: Efetivar matricula()
2: CPF do aluno()
 1.1.1.1: ler()
1.1.1: pesquisar()
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()
1: Aciona Tela()
: Modalidade : Turma : Professor : Matricula
Buscar aluno
ref
Boundary()
Fonte: Elaborada pelo autor.
O diagrama desse REF, que foi nomeado Buscar aluno, é feito separadamente, 
somente com esse procedimento de busca, como mostra a Figura 35.
Figura 35
REF Buscar aluno
1: buscarAluno()
: Aluno
Fonte: Elaborada pelo autor.
Entendemos que esse procedimento de Buscar aluno é bastante simples e po-
deria ser colocado diretamente nos Diagramas de Sequência que necessitassem, 
porém aqui foi um exemplo ilustrativo do operador do tipo REF.
114 Análise de Sistemas
4.3.2 Operador OPT
Esse operador tem por objetivo mostrar que uma parte do Diagrama de Se-
quência é opcional; OPT corresponde à abreviatura do termo em inglês optional. 
Nesse caso, utilizamos uma condição de guarda, na qual a parte só será realizada 
se a condição for verdadeira.
Como exemplo, observe o seguinte Diagrama de Sequência da Figura 36.
Figura 36
Exemplo de operador OPT
 
3: incluir()
2: CPF do aluno()
 1.1.1.1: ler()
1.1.1: pesquisar()
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()
1: Aciona Tela()
: Modalidade : Turma : Professor : Matricula
Buscar aluno
ref
Boundary0
[Se o aluno está cadastro]
otp
Fonte: Elaborada pelo autor.
Esse exemplo ilustra a seguinte situação: o operador REF Buscar aluno foi colo-
cado para indicar a busca dos dados do aluno. Logo em seguida foi colocado um 
quadro retangular envolvendo todo o processo de incluir a matrícula. No canto 
superior esquerdo, foi identificado como um operador OPT e, logo abaixo, uma 
condição (Se o aluno está cadastrado).
Esse operador indica, então, que o procedimento, dentro do quadro OPT, só 
será realizado se o aluno estiver cadastrado (se essa condição for verdadeira).
4.3.3 Operador LOOP
O operador LOOP indica que uma determinada parte do Diagrama de Sequência 
será executada repetidas vezes, enquanto uma condição de guarda for verdadeira. 
Caso a condição nunca seja verdadeira, uma condição de break (quebra) pode ser 
colocada, ou seja, uma saída forçada da repetição.
Diagrama de Sequência 115
Como exemplo, observe o seguinte Diagrama de Sequência da Figura 37, que 
ilustra a autenticação dos dados de um usuário em um procedimento de login.
Figura 37
Exemplo de operador LOOP
 
: Atendente
[cancelar login]
alt: break
3: validaSenha()
[enquanto senha não OK]
2: senha()
alt: loop 1.3
1: usuario()
: UsuarioTela
sd Login – Exemplo loop
Fonte: Melo, 2010, p. 173.
Esse exemplo ilustra a seguinte situação: após o ator Atendente inserir seus 
dados na tela, um quadro retangular simbolizando o operador LOOP foi colocado. 
No canto superior esquerdo do quadro, foi colocado loop 1.3, indicando que tudo 
que estiver no quadro será repetido três vezes, mas somente enquanto a condição 
de guarda for verdadeira. Nesse caso, a condição é “enquanto senha não OK”, ou 
seja, enquanto o ator Atendente informar uma senha inválida, o procedimento de 
receber a senha é repetido. Quando for informada uma senha válida, a repetição 
é interrompida e o diagrama segue após o quadro. No caso de o ator Atendente 
informar três vezes sua senha inválida, a condição de break é acionada e o login 
é cancelado.
4.3.4 Operador ALT
Esse operador tem o objetivo de oferecer uma alternativa ao diagrama; ALT 
corresponde à abreviatura do termo em inglês alternative. Esse operador é muito 
parecido com o operador OPT, com a diferença de que, se a condição de guarda for 
falsa, é possível escrever algum procedimento no diagrama.
Como exemplo, observe o seguinte Diagrama de Sequência da Figura 38.
116 Análise de Sistemas
Figura 38
Exemplo de operador ALT
 
3.1: incluir()
2: CPF do aluno()
 1.1.1.1: ler()
1.1.1: pesquisar()
Tela Realizar Matrícula :: Atendente
1.1: pesquisar()
1: Aciona Tela()
: Modalidade : Turma : Professor : Matricula
Buscar aluno
ref
Boundary0
[Se o aluno está cadastro]
alt
Aluno não cadastrado
4: Efetivar matricula()
[Se o aluno não está cadastrado]
3: Efetivar matricula()
Fonte: Elaborada pelo autor.
Podemos perceber que o quadro retangular do operador ALT oferece duas 
opções: os procedimentos acima da linha pontilhada, que são executados caso a 
condição de guarda seja verdadeira (Se o aluno está cadastrado), ou os que estão 
abaixo, caso a condição seja falsa.
No caso de o aluno estar cadastrado, o procedimento é incluir o aluno no ob-
jeto matrícula; caso contrário, o procedimento é emitir a mensagem “Aluno não 
cadastrado”.
Vimos então que os operadores do Diagrama de Sequência nos dão mais op-
ções para enriquecer o processo de detalhamento de como será a navegação entre 
os objetos. Temos maior flexibilidade e possibilidade de demonstrar os objetivos 
da História de Usuário para a qual o diagrama está sendo construído.
CONSIDERAÇÕES FINAIS 
Neste capítulo, vimos um importante diagrama da UML: o Diagrama de Sequência. 
Ele teve como objetivo fazer a ligação entre duas visões do problema a ser informati-
zado. Olhamos, de um lado, para os Casos de Uso e Histórias de Usuário e, de outro, 
para o Diagrama de Classes, fazendo, para cada História, uma análise da sequência 
das classes que devemos percorrer, invocando métodos para executar completamen-
te a História e chegar ao seu objetivo. Assim, foi possível finalizar o Diagrama de Clas-
ses com a colocação dos métodos das classes que nasceram durante a construção 
dos Diagramas de Sequência.
Diagrama de Sequência 117
Com os diagramas nesse nível de detalhamento, dizemos que os diagramas bási-
cos da UML estão construídos e prontos para que o sistema seja programado, isto é, 
toda a arquitetura da solução agora pode ser repassada aos programadores que, de 
posse de uma linguagem de programação orientada a objetos, conseguirão progra-
mar o software da forma que foi projetada nessa fase de modelagem.
ATIVIDADES1. Qual é o objetivo do Diagrama de Sequência?
2. Cite os três elementos básicos de um Diagrama de Sequência.
3. Cite quatro operadores que podem ser utilizados em um Diagrama de Sequência.
REFERÊNCIAS 
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 12. ed. Rio de Janeiro: Elsevier, 2012.
DEBONI, J. E. Z. Modelagem orientada a objetos com a UML. São Paulo: Futura, 2003.
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2018.
MELO, A. C. Desenvolvendo aplicações com UML 2.2. Rio de Janeiro: Brasport, 2010.
118 Análise de Sistemas
5
Diagramas suplementares 
da UML
A UML é formada por três pilares, sendo o primeiro deles a visão de 
Requisitos organizados por meio do Diagrama de Casos de Uso, dos protó-
tipos de telas e das Histórias de Usuário. O segundo pilar é a identificação 
de objetos e classes e a construção do Diagrama de Classes. E o terceiro, faz 
a ligação entre as Histórias de Usuário e as classes.
Para cada uma das Histórias, verifica-se em quais classes e em qual or-
dem os métodos devem ser invocados para atingir o objetivo da História. 
Os Diagramas de Sequência são construídos para esse fim.
A UML, porém, é dotada de outros diagramas que colaboram na mo-
delagem da solução informatizada. Tais diagramas, que são opcionais ou 
suplementares, são construídos com o objetivo de melhorar a visão dos pro-
cessos e o funcionamento de certos aspectos complexos da modelagem.
Neste capítulo, iremos conhecer três desses diagramas: o Diagrama 
de Transição de Estados, o Diagrama de Atividades e o Diagrama de 
Pacotes.
5.1 Diagrama de Transição de Estados
Vídeo Imagine a seguinte situação: o pedido, feito por meio de um aplicativo, de um 
prato em um restaurante. Desde o momento em que o pedido é feito pelo cliente, 
ele passa por um fluxo, que se inicia com o cliente fazendo o pedido e se encerra 
com o recebimento do prato em sua residência.
Podemos perceber que o pedido assume diversas situações dentro do fluxo, 
que começa no aplicativo em que foi feito, passa para um fluxo dentro do restau-
rante – nos vários passos para a confecção do prato –, depois tem-se o fluxo com 
o entregador para finalmente finalizar o processo com a entrega efetiva do prato 
ao cliente.
A Figura 1 mostra como poderia ser esse fluxo.
Diagramas suplementares da UML 119
Figura 1
Exemplo do fluxo de um pedido
Cliente
Te
ro
 V
es
al
ai
ne
n/
Sh
ut
te
rs
to
ck
Pedido
Atendente
ba
ra
nq
/S
hu
tte
rs
to
ck
Recebendo Pedido
Atendente
ba
ra
nq
/S
hu
tte
rs
to
ck
Aguardando entregador
Pizzaiolo
do
ts
ho
ck
/S
hu
tte
rs
to
ck
Produzindo Produtos
Entregador
Pr
os
to
ck
-s
tu
di
o/
Sh
ut
te
rs
to
ck
Levando pedido
Cliente
Pr
os
to
ck
-s
tu
di
o/
Sh
ut
te
rs
to
ck
Recebendo pedido
Fonte: Elaborada pelo autor.
Se analisarmos alguns artefatos da UML, como o Diagrama de Caso de Uso, as 
Histórias de Usuário, o Diagrama de Classes ou o Diagrama de Sequência, podemos 
verificar que tais diagramas não conseguem refletir esse fluxo da situação do pedi-
do, a qual vai sendo alterada no decorrer do processo.
É fato que, em diversos momentos do processo, essa situação será alterada 
durante o manuseio das telas. Por exemplo, o pedido feito pelo cliente seria in-
cluído no sistema com a situação “solicitado”; em seguida, quando o restaurante 
verificasse a chegada do pedido, um atendente poderia entrar em uma tela em 
que seria marcado como “recebido”; na sequência, quando iniciasse a produção do 
prato, poderia se marcar a situação como “produzindo” e assim por diante.
120 Análise de Sistemas
O que devemos perceber nesse momento é que todas essas alterações de situa-
ção estariam “escondidas” e pulverizadas em diversas telas do sistema. Então, para 
conhecermos todas as mudanças de situação do pedido, bem como as condições 
necessárias para tais mudanças, seria necessário um árduo trabalho de análise das 
diversas Histórias de Usuário que tratassem dessas alterações. Isso seria pratica-
mente inviável, considerando que os processos nas telas tratam de outros com-
ponentes do processo e não só da mudança da situação, ocasionando então uma 
dificuldade muito grande para o analista ter uma visão geral de todas as mudanças 
de situação.
Por outro lado, poderíamos recorrer ao Diagrama de Classes. Ora, é bem prová-
vel que para esse processo tenhamos uma classe Pedido e um de seus atributos seja 
denominado situação. Os valores desse atributo seriam todas as situações possíveis 
do pedido. Isso também não nos daria a visão das possíveis mudanças de situação.
Finalmente, se formos analisar os Diagramas de Sequência, teríamos a mesma 
dificuldade encontrada nas Histórias de Usuário, já que é construído um diagrama 
para cada uma delas, e também não teríamos essa visão que estamos procurando.
Para resolver essa questão, o Diagrama de Transição de Estados é o artefato 
da UML que mostra exatamente o que estamos querendo enxergar nesse caso: a 
mudança dos possíveis estados da situação do pedido dentro do sistema e as con-
dições para que essas mudanças ocorram.
O Diagrama de Transição de Estados (ou simplesmente Diagrama de Estados) 
demonstra graficamente a mudança de estado de um ou mais elementos ou obje-
tos de um sistema por meio de um conjunto de transições (GUEDES, 2018).
Podemos dizer que esse diagrama descreve a dinâmica interna de um objeto, 
seu ciclo de vida desde o momento que é criado até o seu término, quando finaliza 
o processo para o qual foi criado (DEBONI, 2003). Conforme afirmam Rumbaugh 
et al. (1994, p. 114), “com o tempo, os objetos estimulam uns aos outros, resultando 
em uma série de alterações em seus estados”.
Segundo Booch, Rumbaugh e Jacobson (2012, p. 293), que chamam esse diagra-
ma de Diagrama de Estados, “os diagramas de estados serão empregados para fazer 
a modelagem de aspectos dinâmicos do sistema”.
Já Melo (2010, p. 187), que o chama de Diagrama de Máquinas de Estados, “uma 
máquina de estado consiste num comportamento que especifica a sequência de 
estados que um objeto atravessa durante sua vida, em resposta a eventos, junto 
com suas responsabilidades e ações”.
O objetivo desse diagrama, então, é mostrar graficamente não só todos os 
estados que um objeto pode assumir, mas também de qual estado e para qual 
estado ele pode passar e em que condições isso ocorre. Com isso, todas as mu-
danças de estado que estão espalhadas nos processos descritos nas Histórias 
de Usuário ficam visíveis na forma de um diagrama (normalmente de uma pági-
na), facilitando a análise e as futuras alterações do fluxo, comuns nos sistemas 
de informação.
Diagramas suplementares da UML 121
5.1.1 Elementos
A seguir serão apresentados os elementos básicos que podem ser utilizados no 
Diagrama de Transição de Estados.
5.1.1.1 Estado
Representa um estado em que o objeto se encontra em um determinado mo-
mento e quais as ações que são tomadas durante a passagem por esse estado.
Um estado é representado por um retângulo com bordas arredondadas e com 
dois compartimentos, como mostra a Figura 2.
No primeiro compartimento deve ser colocado o nome do estado e na parte de 
baixo as ações que devem ser tomadas na passagem do objeto por esse estado. 
Essas ações podem ser explícitas, mostrando exatamente o que deve ser feito, ou 
pode ser mostrado somente o nome de um método da classe do objeto em ques-
tão. A palavra do é opcional no compartimento da ação, ela indica que é a ação 
principal do estado (outras opções serão explicadas na sequência).
Figura 2
Símbolo de estado
do / 
Fonte: Elaborada pelo autor.
O nome do estado (primeiro compartimento) deve ser escrito no seguinte 
padrão:
A Figura 3 mostra um exemplo de estado em que o objeto pedido está entrando 
num estado em que está sendo incluído no sistema. Note que o nome do estado 
está no padrão. No segundo compartimento, foi colocado o nome do método da 
classe Pedido encarregado por essa ação.Figura 3
Exemplo do elemento estado
do / incluirPedido()
Incluindo Pedido
Fonte: Elaborada pelo autor.
O segundo compartimento do símbolo de estado pode conter ações de três 
tipos:
 • entry – realizada quando o objeto assume o estado.
 • do – executada enquanto o objeto se encontra no estado.
 • exit – executada antes de o objeto mudar de estado.
122 Análise de Sistemas
A Figura 4 mostra o exemplo do estado Incluindo Pedido, no qual poderíamos 
ter as seguintes ações:
Figura 4
Exemplo de ações de um estado
exit / fecharbancoDados
do / incluirPedido()
entry / abrirBancoDados()
Incluindo Pedido
Fonte: Elaborada pelo autor.
5.1.1.2 Transição
É a passagem, de um determinado objeto, de um estado para outro.
O símbolo para o elemento de transição é uma seta partindo de um estado para o 
próximo. Nela pode-se colocar uma legenda indicando qual será o próximo passo do 
processo ou o resultado do estado anterior. A Figura 5 mostra esse elemento.
Figura 5
Elemento transição
 
Fonte: Elaborada pelo autor.
No exemplo da Figura 4, suponha que, após o objeto sair do estado Incluindo 
Pedido, ele entre no estado Produzindo Produtos. A Figura 6 mostra um exemplo 
dessa transição. Na legenda foi colocado o próximo passo do processo.
Figura 6
Exemplo do elemento transição
Produzir Produtosdo / incluirPedido()
Incluindo Pedido Produzindo Produtos
do / produzirProdutos()
Fonte: Elaborada pelo autor.
5.1.1.3 Barra de sincronização
Em certos processos, é possível que dois estados tenham que acontecer 
ao mesmo tempo. Se representarmos um estado com uma transição para 
outro, esses dois acontecem de modo sequencial, um após o outro, e não 
simultaneamente.
Para representar os estados acontecendo ao mesmo tempo, podemos utilizar a 
barra de sincronização. Ela faz com que uma transição permita que várias outras se 
dirijam a estados que irão ocorrer de maneira simultânea. Após essa ocorrência, a 
barra também faz com que o processo volte a ser sequencial.
A Figura 7 mostra o elemento barra de sincronização com setas de transição 
entrando e saindo da barra.
Diagramas suplementares da UML 123
Figura 7
Elemento barra de sincronização
Fonte: Elaborada pelo autor.
Suponha o procedimento de arrancar um automóvel, em que o motorista deve 
ao mesmo tempo pisar no acelerador e soltar a embreagem do carro. Esses dois 
movimentos devem ser feitos simultaneamente. Para representar essa situação 
num Diagrama de Transição de Estados, podemos usar a barra de sincronização, 
conforme mostra a Figura 8.
Figura 8
Exemplo do elemento barra de sincronização
Andando
Soltando a embreagemPressionando o acelerador
Engatando a marcha
Fonte: Elaborada pelo autor.
Dois estados especiais são o estado inicial e o final e são utilizados obviamente 
para iniciar um diagrama e para representar o seu fim. Na Figura 9 estão represen-
tados esses dois estados, antes e depois do estado Incluindo Pedido.
Figura 9
Estado inicial e final
do / incluirPedido()
Incluindo Pedido
Fonte: Elaborada pelo autor.
5.1.2 Exemplo 1 – Encerramento de uma conta corrente
Como primeiro exemplo desse diagrama, vamos supor um processo de en-
cerramento de uma conta corrente em um banco. No decorrer desse processo, o 
objeto conta passa por diversos estados até chegar ao final, quando a conta está 
124 Análise de Sistemas
 efetivamente encerrada. Nesse exemplo poderemos constatar também que o Dia-
grama de Transição de Estados permite desvios conforme o resultado da ação de 
um determinado estado. A Figura 10 mostra esse exemplo.
Figura 10
Exemplo do Diagrama de Transição de Estados para o encerramento de uma conta corrente
Encerrando Conta
Verificando Saldo
Senha Válida
Verificando Senha
do / encerrar()
Saldo zerado
do / sacar()
Sacando Saldo
[Se positivo]
[Se negativo]do / consultarSaldo()do / validarSenha()Conta Existentedo / consultarConta()
Consultando Conta
Fonte: Elaborada pelo autor.
5.1.3 Exemplo 2 – Despacho de bagagem em um aeroporto
Este segundo exemplo mostra a rotina de uma bagagem passando por diversos 
estados em um aeroporto após o despacho pelo cliente no momento do embarque.
O processo inicia pelo cliente despachando a bagagem no balcão da companhia 
aérea; depois o embarque na aeronave; a saída para o aeroporto de destino até a 
retirada pelo cliente.
A Figura 11 mostra esse exemplo e também os casos excepcionais de bagagem 
com problema de checagem e não retirada por parte do cliente.
Figura 11
Exemplo do Diagrama de Transição de Estados para o despacho de uma bagagem em um aeroporto
Aguardando retirada
Transportando para reclamações
passageiro retirou
Retirando
passageiro não retirou
Entrando na Esteira Transportando do Avião Desembarcando
Voando
Embarcando
Transportando ao avião
Aguardando Embarque
Enviando para PF
Irregular
ChecandoDespachando
Fonte: Elaborada pelo autor.
Diagramas suplementares da UML 125
5.1.4 Exemplo 3 – Pedido de comida
Finalmente faremos o Diagrama de Transição de Estados para o exemplo inicial 
desta seção, em que o cliente faz um pedido de comida, passando por todos os 
trâmites até o recebimento na sua residência. A Figura 12 mostra esse exemplo.
Figura 12
Exemplo do Diagrama de Transição de Estados para o pedido de comida
do / recebendoPedidoCliente
Recebendo Pedido
Receber pelo clientedo / receberPedidoEntregador
Recebendo Pedido
Receber pelo entregador
do / chamarEntregador
Aguardando Entregador
Chamar entregador do / produzir
Produzindo Produtos
Produzir os produtos
do / receberPedidoAtendente
Recebendo Pedido
Receber no restaurantedo / incluirPedido
Fazendo Pedido 
Fonte: Elaborada pelo autor.
Vimos a versatilidade do Diagrama de Transição de Estados para representar 
situações pelas quais um objeto pode passar durante um determinado processo. 
Por ter uma visão transversal, devido aos diversos casos de uso, esse diagrama 
fornece uma visão gráfica das mudanças de estado, permitindo maior facilidade de 
projetar a solução e, principalmente, de alterar sua estrutura quando necessário.
5.2 Diagrama de Atividades
Vídeo Esse tipo de diagrama procura modelar um determinado processo, atividade, 
ou até mesmo um algoritmo, detalhando o passo a passo da execução. É um dia-
grama utilizado não só na modelagem UML como também em quaisquer áreas que 
necessitam representar seus processos de negócio.
Nas teorias de análise mais antigas, esse diagrama era muito difundido e utiliza-
do e tinha o nome de Fluxograma. Por muitos anos, era o único diagrama construí-
do para representar a solução informatizada.
Por sua simplicidade e facilidade de construir, o Diagrama de Atividades é usado 
das mais diversas formas; numa discussão rápida de como deve ocorrer determi-
nado caso de uso, por exemplo, ele pode facilitar o entendimento com um simples 
desenho no papel, fazendo com que a comunicação entre a equipe seja eficiente. 
Também no caso de algoritmos complexos, um programador pode utilizar esse dia-
grama para esboçar uma solução, antes de efetivamente implementá-la em uma 
linguagem de programação.
Trata-se de um diagrama que mostra a sequência de ações e condições para 
coordenar comportamento de baixo nível e dá ênfase aos detalhes de um processo 
(GUEDES, 2018).
126 Análise de Sistemas
Segundo Booch, Rumbaugh e Jacobson (2012, p. 293), assim como o Diagrama de 
Transição de Estados, “os diagramas de atividades serão empregados para fazer a mo-
delagem de aspectos dinâmicos do sistema”.
Para Melo (2010, p. 199), “este diagrama tem por propósito focalizar um fluxo 
de atividades que ocorrem internamente em um processamento, dentro de um 
período de tempo”.
A Figura 13 apresenta o processo de compra de uma passagem aérea, em que 
várias telas encadeadas precisam ser acessadas desde o momento das informações 
iniciais, dadas pelo cliente, até a efetivação da compra (na figura está representada 
somente parte desse processo).
Figura 13
Processo da compra de uma passagem aérea
Fonte: Latam Airlines BrasiL, 2021.Diagramas suplementares da UML 127
O Diagrama de Atividades é o diagrama apropriado para representar esse tipo 
de situação.
5.2.1 Elementos
A seguir serão apresentados os elementos básicos que podem ser utilizados no 
Diagrama de Atividades.
5.2.1.1 Ação
Uma ação representa um dos passos da atividade do diagrama. É uma parte do 
processo que deve ser realizada, normalmente nomeada com um verbo no infiniti-
vo e um sujeito. Também pode conter uma referência ao ator que está realizando a 
ação. O símbolo desse elemento é um retângulo com bordas arredondadas.
A Figura 14 apresenta dois exemplos desse elemento, o primeiro com a ação 
Pesquisar Voo e o segundo com a ação de um cliente inserindo um cartão no 
caixa eletrônico.
Figura 14
Exemplos do elemento ação
Cliente insere cartãoPesquisar Voo
Fonte: Elaborada pelo autor.
5.2.1.2 Fluxo
Representa a ligação entre duas ações, a passagem de uma ação para outra. A 
Figura 15 apresenta esse elemento com duas ações ligadas por um fluxo.
Figura 15
Elemento fluxo
Cliente insere cartão
Sistema solicita o 
cartão do cliente
Fonte: Elaborada pelo autor.
5.2.1.3 Nó de decisão
Representa uma bifurcação na sequência de ações que pode levar a diversas 
opções (alternativas) dependendo de certas condições.
Suponha que no exemplo da Figura 15, após o cliente inserir o cartão, o sistema 
fizesse a verificação se o cartão inserido é ou não um cartão válido. Nesse caso, 
teríamos duas alternativas e duas ações a serem tomadas dependendo do resulta-
do dessa validação. Para que o diagrama apresente essas duas opções, é usado o 
elemento nó de decisão.
128 Análise de Sistemas
A Figura 16 apresenta esse elemento. Após verificar se o cartão é válido, o exem-
plo mostra um nó de decisão em que uma ação é realizada caso o cartão seja váli-
do, e outra para o cartão inválido.
Figura 16
Elemento nó de decisão
“Cartão inválido”
Sistema emite a mensagem
[Inválido][Válido]
Sistema solicita a senha
Sistema valida o cartão
Cliente insere cartão
Sistema solicita o
cartão do cliente
Fonte: Elaborada pelo autor.
5.2.1.4 Barra de sincronização
Assim como no Diagrama de Transição de Estados, nesse diagrama também po-
demos utilizar a barra de sincronização quando desejamos que duas ações sejam 
realizadas ao mesmo tempo.
Sua representação é a mesma, ou seja, uma barra de onde podem sair diversos 
fluxos apontando para as ações que precisam ser executadas de maneira simultânea.
A Figura 17 mostra um exemplo desse elemento em que o encarregado de pro-
duzir um produto (um prato de um restaurante, por exemplo), ao receber um pe-
dido deve produzir os produtos desse pedido, porém, ao mesmo tempo, não deve 
deixar de acompanhar os produtos que já estavam sendo produzidos.
Figura 17
Elemento barra de sincronização
Produzir produtos
Receber pedido
em produção
Acompanhar produtos
Fonte: Elaborada pelo autor.
5.2.2 Exemplo 1 – Emitir extrato bancário
O exemplo a seguir mostra um Diagrama de Atividades de todo o processo de 
emitir um extrato num caixa eletrônico. A Figura 17 mostra esse exemplo.
Diagramas suplementares da UML 129
Figura 18
Exemplo do Diagrama de Atividades para a atividade emitir extrato
Apresentar extrato
inválido”
“Período
mensagem
Apresentar
[Período inválido]
período
Validar
período
Solicitar
[Senha válida]
“Senha inválida”
mensagem
Apresentar
[Senha inválida]
Verificar senhasenha
Solicitar
[Inválida]
conta
Verificar
conta
Solicitar
Fonte: Adaptado de Guedes, 2018.
5.2.3 Colunas
O Diagrama de Atividades pode ser construído com colunas onde em cada uma 
delas pode ser colocado um ator que faz parte do processo. Essas colunas, tam-
bém conhecidas como raias de uma piscina, são importantes para que cada ação 
esteja colocada na respectiva coluna do ator responsável por ela.
O exemplo a seguir mostra um Diagrama de Atividades de todo o processo de 
compra de uma passagem aérea. Podemos perceber que agora o diagrama está 
com as ações distribuídas em quatro colunas: Cliente, Empresa Aérea, Operadora 
de Cartão e Programa de Milhagem.
O processo inicia na primeira coluna (Cliente), informando os dados da viagem; 
em seguida foi colocado um fluxo para a próxima ação, Pesquisar voo, porém 
quem é responsável por essa pesquisa é o sistema na Empresa Aérea, então essa 
ação foi colocada na sua coluna; em seguida vem a ação Listar voos e o nó de deci-
são na coluna do Cliente novamente para que ou sejam colocados dados de outra 
viagem, caso não encontre a primeira, ou se passe para a ação do Cliente, Escolher 
um voo. O processo continua nessa linha, com todas as ações nas suas respectivas 
colunas. A Figura 19 mostra esse exemplo.
130 Análise de Sistemas
Figura 19
Exemplo do Diagrama de Atividades utilizando colunas
Debitar Milhas
Realizar Pagamento
Emitir Passagem
[Sem milhas]
[Com milhas]
Listar Voos
Pesquisar Voo
Passagem
Imprimir
da compra
Informar dados
Escolher Voo
[Achou]
[Não achou]
da viagem
Informar dados
Programa de MilhagemOperadora de CartãoEmpresa AéreaCliente
Fonte: Elaborada pelo autor.
Esses foram os principais elementos de um Diagrama de Atividades. Vimos a sua 
importância e suas diversas utilidades no processo de modelagem de um sistema.
5.3 Diagrama de Pacotes 
Vídeo O Diagrama de Pacotes tem por objetivo organizar os elementos de um modelo 
e demonstrar as dependências entre eles (GUEDES, 2018).
Normalmente diagramas de grandes sistemas e com muitas funcionalidades fi-
cam com um número excessivo de elementos, não permitindo sua visualização em 
uma única página, o que muitas vezes é inconveniente. Então, com esse diagrama, 
é possível segmentar os diagramas em funções e subfunções, sistemas e subsiste-
mas, ou até mesmo em partições, conforme o ambiente em que um determinado 
componente irá atuar.
Segundo Guedes (2018), o Diagrama de Pacotes pode também representar:
 • um conjunto de sistemas integrados;
 • submódulos de um único sistema;
 • a arquitetura de uma linguagem de programação;
 • a arquitetura de um processo em desenvolvimento.
Diagramas suplementares da UML 131
Olhando para os diversos diagramas da UML, o Diagrama de Pacotes pode ser usa-
do em conjunto com o Diagrama de Classes com o objetivo de “empacotar” classes per-
tencentes a um mesmo módulo e demonstrar a integração desses pacotes de classe. Já 
o Diagrama de Caso de Uso pode segmentar em pacotes conjuntos de casos de uso de 
uma determinada parte do sistema e demonstrar a integração entre eles.
O Diagrama de Pacotes serve então de auxílio a outros diagramas para melho-
rar a visualização da modelagem.
5.3.1 Elementos
A seguir serão apresentados os elementos básicos que podem ser utilizados no 
Diagrama de Pacotes.
5.3.1.1 Pacote
O elemento básico desse diagrama é, obviamente, o pacote. É representado 
por um retângulo em que, no topo, é colocado o nome do pacote. Esse nome 
deve apresentar uma boa referência sobre os componentes que estão sendo 
empacotados.
A Figura 20 apresenta um exemplo de um pacote que representa um determi-
nado sistema de informação de um restaurante.
Figura 20
Exemplo do elemento pacote
Sistema de Pedidos
Fonte: Elaborada pelo autor.
Nesse exemplo colocamos somente o pacote representando o sistema. Tam-
bém é possível colocar elementos dentro do pacote para mostrar o seu conteúdo.
Na Figura 21 foram colocadas algumas classes no pacote, demonstrando o que 
ele contém. Podemos perceber que, nesse pacote, as classes não contêm atribu-
tos nem métodos e não estão relacionadas. Isso ocorre porque o objetivo desse 
diagrama é justamente dar uma visão geral e mais ampla dos componentes, e não 
seus detalhes, que podem ser visualizados no diagrama específico.
Figura 21
Exemplo de pacote com classes
Cliente
Produto
Pedido
Sistema de Pedidos
Fonte: Elaborada pelo autor.
132 Análise de Sistemas
Já a Figura 22 mostra um exemplo de como empacotar casos de uso.
Figura 22
Exemplo de pacote com casos de uso
 
Entregar Pedido
Receber Pedido
Fazer Pedido
Sistema deint FK
14 Análise de Sistemas
Entretanto, apesar do avanço que a Análise Estruturada trouxe, os problemas 
nos sistemas continuavam ocorrendo. Os processos estavam estruturados e os da-
dos organizados, porém a principal questão nesse modelo era que qualquer pro-
cesso tinha autorização para manipular qualquer dado do modelo. Mesmo que o 
processo não tivesse relação nenhuma com determinado dado, nada o impedia de 
acessá-lo. Isso causava muitos problemas de programadores inexperientes codifi-
carem programas que deveriam ter um objetivo, porém esses objetivos eram ne-
gligenciados, desse modo o programa começava a interferir em outros processos 
fora do seu escopo e, o mais grave, começava a manipular dados que não eram 
condizentes com o real objetivo daquele programa.
1.1.2.2 Análise Orientada a Objetos
Para amenizar essas questões, surgiu nos anos 1990 a Análise Orientada a Obje-
tos (RUMBAUGH et al., 1994). O princípio básico dessa teoria é o conceito de encap-
sulamento, segundo o qual determinados dados devem ser manipulados somente 
por suas operações num componente chamado Objeto. Assim, se identificamos um 
conjunto de dados relativos a um cliente de banco, por exemplo, devemos ter um 
conjunto de processos (ou operações ou funções) que será responsável por ma-
nipular esses dados. Em outras palavras, não existe a possibilidade de processos 
que tratam de financiamentos do banco manipularem diretamente os dados dos 
clientes. Isso é de grande importância, pois somente as operações relativas aos 
clientes conhecem as regras para se manipular seus dados e essas regras ficam 
concentradas nas operações desses dados.
Como mostra a Figura 6, esse encapsulamento de dados e operações está 
representado na forma de um círculo contendo os dados e um outro à sua vol-
ta contendo suas operações, dando a ideia de que os dados estão “protegidos” 
pelas operações, ou seja, suas operações são as únicas que têm permissão para 
manipulá-los.
É evidente que existe a possibilidade de outros processos necessitarem de da-
dos que não são de sua responsabilidade, porém, nesse caso, esse processo só 
consegue acessar o dado fazendo uma solicitação às suas operações (representado 
pelas setas na figura), e essa solicitação é chamada de mensagem entre os objetos. 
Essa união entre dados e operações será chamada de objeto.
Figura 6
Modelo de Objetos
Fonte: Elaborada pelo autor.
operações
dados
Objeto 1
operações
dados
Objeto 2
operações
dados
Objeto n
operações
dados
Objeto 3
Para conhecer melhor as 
teorias de análise mais 
antigas, leia a obra Análise 
Estruturada de Sistemas, 
que determinou as tendên-
cias do desenvolvimento 
de software na década de 
1970.
GANE, C.; SARSON, T. São Paulo: 
LTC, 1983.
Livro
Introdução à análise de sistemas e Levantamento de Requisitos 15
Como exemplo, suponha um sistema de vendas de produtos. Os objetos en-
volvidos nesse negócio poderiam ser: produtos, clientes, fornecedores e, princi-
palmente, a venda. A representação desse sistema orientado a objetos seria o que 
mostra a Figura 7.
Figura 7
Exemplo de modelo de objetos
Fonte: Elaborada pelo autor.
incluir
nome
CPF
Cliente
incluir
nome
CNPJ
Fornecedor
vender
numero
data
Venda
mostraTela
Campos da tela
TELA DE VENDAS
consultar
nome 
dimensoes
ProdutoBanco de dados
Vimos que a evolução das teorias de análise nos levou a modelos mais comple-
xos, porém os problemas passaram a ser mais controlados e a qualidade dos siste-
mas melhoraram, fazendo com que se chegasse a um padrão utilizado por todo o 
mercado de produção de sistemas.
Não só a teoria de Análise Orientada a Objetos se solidificou no mercado, mas 
uma grande área surgiu para dar as diretrizes para todo o processo complexo de 
desenvolvimento de um software e foi chamada de Engenharia de Software, sendo 
seus precursores nomes como Roger S. Pressman, Bruce R. Maxim (PRESSMAN; 
MAXIM, 2016) e Ian Sommerville (SOMMERVILLE, 2011).
1.1.3 Ciclo de desenvolvimento de um sistema
Para o completo desenvolvimento de um sistema, desde a necessidade de um 
cliente informatizar a solução de um determinado problema de negócio até a efe-
tiva utilização do sistema no ambiente real, existe um ciclo de desenvolvimento 
cobrindo diversas atividades. Muitas formas foram propostas para esses ciclos, que 
também foram evoluindo no decorrer dos anos, sempre com novos modelos capa-
zes de resolver os problemas dos modelos anteriores.
Independentemente do tipo de ciclo, quatro fases básicas no processo sempre 
são identificadas: Iniciação, Elaboração, Construção e Transição (KRUCHTEN, 2003). 
Essa nomenclatura pode ser diferente nas várias propostas existentes, mas pode-
mos focar esses termos para entendermos em qual dessas fases atua a análise de 
sistemas. As características de cada uma das fases são:
16 Análise de Sistemas
Como o nome já diz, é a fase em que se inicia a investigação acerca das 
necessidades do usuário, busca-se o entendimento do negócio e do proble-
ma a ser resolvido. São levantados os Requisitos (ou funcionalidades) que 
serão atendidos pelo sistema e é obtido um acordo (ou consenso) com as 
partes envolvidas (usuário e equipe de desenvolvimento).
Iniciação
Nessa fase é projetada uma solução que satisfaça os Requisitos. É feita a 
modelagem do sistema por meio de construção de documentos e diagramas 
que apresentem ao usuário uma ideia de como será o produto final. A equipe de 
analistas de sistemas toma como base os materiais produzidos na fase anterior. 
Elaboração
Nessa fase são codificados os programas e componentes de software que se 
transformarão no produto final, um software funcionando. A equipe de progra-
mação toma como base todo o material produzido na fase anterior para cons-
truir um software como foi especificado no projeto.
Construção
Com os componentes de software construídos, nessa fase é feito o plane-
jamento da entrega, os testes de software, bem como sua homologação pelo 
usuário e, finalmente, o software é liberado para o ambiente produtivo.
Transição
A Figura 8 mostra o detalhamento 
das atividades em cada uma das fases. 
Ela é comumente chamada de gráfico 
das baleias. Na coluna da esquerda, 
as disciplinas representam as ativida-
des que devem ser realizadas, na linha 
horizontal, aparecem as iterações. As 
“barrigas”, representadas horizontal-
mente, indicam a carga de trabalho de 
cada atividade em cada fase, quanto 
mais alta, maior a carga.
Atividades
Modelagem de Negócios
Requisitos
Análise e Design
Implementação
Teste 
Implementação
Gerenciamento de 
Configuração e Mudança
Gerenciamento de Projeto
Ambiente
Figura 8
Ciclo de Desenvolvimento
Fonte: Kruchten, 2003.
Introdução à análise de sistemas e Levantamento de Requisitos 17
Esse modelo foi amplamente utilizado pelas empresas durante anos. Suas 
desvantagens foram a formalização, o excesso de procedimentos e artefatos que 
eram construídos e, muitas vezes, não tinha utilidade por não agregar valor ao 
produto final.
Porém, a estrutura geral do modelo, como as fases e suas atividades, permane-
ceu nas metodologias mais modernas.
Existem outros ciclos de 
desenvolvimento mais antigos 
que não foram abordados por 
não serem mais utilizados. São 
exemplos: cascata, incremental e 
prototipação.
Curiosidade
1.2 Levantamento de Requisitos
Vídeo A fase de Iniciação do ciclo de desenvolvimento de um sistema começa com o 
Levantamento de Requisitos.
Essa tarefa é primordial para que o software seja desenvolvido da maneira 
correta e atenda totalmente às necessidades do cliente. Sua importância e sua 
abrangência são tão grandes que uma nova área foi criada, chamada Engenharia 
de Requisitos.
O uso sistemático de técnicas para obter, documentar e manter as informa-
ções para conseguir uma Lista de Requisitos que atendem aos objetivos do cliente 
no seu negócio é uma boa definição de Engenharia de Requisitos. Suas práticas e 
ferramentas facilitam a comunicação com o cliente a fim de identificar e entender 
suasPedidos – Requisitos
Fonte: Elaborada pelo autor.
5.3.1.2 Dependência
O elemento dependência faz a ligação entre os pacotes para indicar a relação 
que existe entre eles tanto na passagem de informações quanto das suas funções. 
Para essa ligação, usa-se uma seta pontilhada.
A Figura 23 apresenta um exemplo de dois pacotes ligados pelo símbolo de de-
pendência. Nesse exemplo, digamos que o restaurante tenha outros dois sistemas 
de informação, o sistema financeiro, que deve registrar os valores dos pedidos, e 
o sistema de avaliação dos pedidos. Podemos perceber que, durante o processo 
completo de realização do pedido no sistema de pedidos, em algum momento os 
dois outros sistemas serão acessados, demonstrando assim a dependência que 
existe entre eles.
Figura 23
Exemplo do elemento dependência
Sistema de Avaliação
Sistema Financeiro
Sistema de Pedidos
Fonte: Elaborada pelo autor.
5.3.2 Exemplo 1 – Pacotes de arquitetura de um sistema
Nesse exemplo vamos mostrar como seriam os pacotes para representar uma 
arquitetura de programação de um sistema. Digamos que as classes de um siste-
ma foram distribuídas em três camadas, cada uma cuidando das suas funções. A 
primeira delas poderia ser chamada de camada de apresentação, na qual estariam 
todos os programas das telas do sistema com o único objetivo de apresentar a tela 
ao usuário.
Diagramas suplementares da UML 133
Em seguida, poderíamos ter uma camada de controle, responsável pela passa-
gem dos dados da camada de apresentação para a terceira camada e, finalmente, 
uma camada de negócios, contendo as classes responsáveis por todo o processa-
mento dos dados das telas, incluindo o acesso ao banco de dados e a aplicação das 
regras de negócio. A Figura 24 mostra esse exemplo.
Figura 24
Exemplo do Diagrama de Pacotes de uma arquitetura de programação
Negócio
Controle
Apresentação
Fonte: Elaborada pelo autor.
Esse exemplo é uma arquitetura importante, amplamente utilizada em aplica-
ções web, em que as páginas HTML estão na camada de apresentação. A comuni-
cação do browser com os programas do servidor de aplicações é controlada pelas 
classes do pacote de Controle e, já no servidor, o pacote com as classes de Negócio 
fazem todos o processamento dos dados da tela.
5.3.3 Exemplo 2 – Pacotes de dois sistemas com suas classes
Nesse exemplo vamos mostrar dois pacotes interligados, cada um represen-
tando um sistema de informação com suas respectivas classes. A Figura 25 mostra 
esse exemplo.
Figura 25
Exemplo do Diagrama de Pacotes de dois sistemas de informação interligados
ProfessorAluno
Cadastro
DeliberacaoSolicitacao
Secretaria On-line
Fonte: Elaborada pelo autor.
Vimos que o Diagrama de Pacotes é bastante útil para melhorar a apresenta-
ção dos componentes de um sistema, dando uma boa visão de grandes proces-
sos e demonstrando, nos níveis que se desejar, o conteúdo e o encadeamento 
dos pacotes.
O Exemplo 1, de uma arquitetura em 
três camadas, é conhecido como MVC 
(Model/View/Controler).
Curiosidade
134 Análise de Sistemas
CONSIDERAÇÕES FINAIS 
Este capítulo apresentou diagramas da UML que são considerados opcionais ou 
suplementares por fornecer informações e visões diferentes e/ou mais detalhadas de 
alguns aspectos da modelagem.
O Diagrama de Transição de Estados, que é aplicado a uma situação específica que 
pode ou não ocorrer no sistema quando um determinado objeto passar por diversas 
situações no decorrer de um processo, é de extrema utilidade para centralizar num úni-
co diagrama e mostrar graficamente as passagens e suas condições dessas situações.
Já o Diagrama de Atividades se mostra extremamente versátil e útil para diversos fins, 
pois atende desde o detalhamento de um simples algoritmo até a apresentação de manei-
ra detalhada de processos grandes e complexos.
Por fim, o Diagrama de Pacotes serve para mostrarmos que é possível agrupar 
processos a fim de demonstrar melhor seu encadeamento e se ter uma visão mais 
ampla do sistema.
ATIVIDADES 
1. Qual é o objetivo do Diagrama de Transição de Estados?
2. Quais são os quatro elementos básicos de um Diagrama de Atividades?
3. Quais são as aplicações de um Diagrama de Pacotes?
REFERÊNCIAS 
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 12. ed. Rio de Janeiro: Elsevier, 2012.
DEBONI, J. E. Z. Modelagem orientada a objetos com a UML. São Paulo: Futura, 2003.
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2018.
LATAM AIRLINES BRASIL. Latam Airlines, 2021. Página inicial. Disponível em: https://www.latamairlines.
com/br/pt. Acesso em: 12 mar. 2021.
MELO, A. C. Desenvolvendo aplicações com UML 2.2. Rio de Janeiro: Brasport, 2010.
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. São Paulo: Campus, 1994.
Gabarito 135
GABARITO 
1 Introdução à análise de sistemas e Levantamento de Requisitos
1. Os processos estavam estruturados, os dados organizados, porém a principal 
questão nesse modelo era que qualquer processo tinha autorização para manipular 
qualquer dado do modelo. Além disso, os programas tinham autorização para 
interferir em processos fora do seu escopo.
2. Diagrama de Caso de Uso: apresenta graficamente todas os Requisitos do sistema 
bem como a interação com as entidades externas.
Diagrama de Classes: é utilizado para modelar as classes de objetos, seus atributos, 
suas operações e relacionamento com outras classes.
Diagrama de Sequência: determina a sequência de mensagens que devem 
ser trocadas entre os objetos do sistema para que um caso de uso realize 
completamente sua função.
3. Muita burocracia e grande esforço na produção de documentos, diagramas e 
artefatos inúteis. O processo era engessado em normas e padrões. Atraso na 
entrega do sistema, alto custo e equipe insatisfeita com a metodologia de trabalho. 
Desperdício de tempo e dinheiro para produzir artefatos que não tinham nenhuma 
utilidade. O mais importante era a produção de documentos, e não a produção 
efetiva do sistema.
2 Casos de Uso e Histórias de Usuário
1. Os objetivos principais são: atender aos Requisitos do cliente por meio de 
verificações que o sistema deve fazer para considerar que a História pronta; 
ter o aceite do cliente, já que somente com os critérios verificados a História é 
considerada pronta; determinar quais são os procedimentos da tela para que se 
atinja o seu objetivo.
2. Os elementos de um Diagrama de Caso de Uso são ator, caso de uso e 
relacionamento. Os atores representam entidades externas ao sistema e que 
interagem com ele. Fornecem e/ou recebem informações do sistema e irão 
interagir com ele para satisfazer suas necessidades. Existem três tipos de atores:
 • Pessoas: são os atores mais fáceis de serem identificados. Irão manipular as 
telas, receber relatórios e fazer consultas aos dados.
 • Órgãos de uma organização: em uma organização, um determinado órgão pode 
ser considerado um ator quando todas as pessoas desse órgão irão interagir 
com o sistema.
 • Outros sistemas informatizados: são softwares externos, pertencentes ou não à 
mesma organização.
Um caso de uso representa um determinado Requisito, é uma funcionalidade 
completa conforme percebida pelo ator. Ele fornece um resultado observável 
ao ator e contribui para que o ator atinja seu objetivo. Os relacionamentos têm 
por objetivo fazer as ligações entre os atores e casos de uso. Com isso, é possível 
saber com quais casos de uso um determinado ator vai se relacionar e estruturar 
136 Análise de Sistemas
os atores conforme seus tipos a fim de detalhar melhor suas responsabilidades. 
Existem cinco tipos de relacionamentos que podem ser utilizados num Diagrama 
de Caso de Uso:
 • Ligação: é feita entre atores e casos de uso para indicar exatamente com quais 
casos de uso cada ator irá interagir.
 • Herança de atores: é identificada quando existem “tipos” desse ator. Um ator 
com características mais gerais tem seus tipos mais específicos.
 • Herança de casos de uso: um caso de uso mais geral podeter diversos tipos 
mais específicos.
 • Include (ou uso): é usado quando queremos separar uma parte dos procedi-
mentos de um caso de uso criando um novo caso de uso com essa parte. Esses 
dois casos de uso poderão ficar ligados por meio de um Include.
 • Extend (ou extensão): seu funcionamento é muito parecido com o include, exis-
tindo a chamada de um caso de uso a outro para que se realize um determinado 
procedimento e retorne ao caso de uso original. Porém, no caso de um Extend, 
essa chamada ocorre segundo uma determinada condição.
3. Os objetivos principais são: facilitação da avaliação por parte do cliente; possibilidade 
de se realizar ajustes rápidos e correção de erros; ajustes de posicionamento dos 
componentes e manuseio da tela.
3 Objetos e classes
1. Uma classe é um conjunto de objetos que possuem a mesma lista de atributos, 
as mesmas operações e os relacionamentos comuns com outros objetos. É 
um modelo, um protótipo, usado para criar vários objetos com características 
semelhantes. Ela representa uma categoria, e os objetos são os membros ou 
exemplos dessa categoria. As classes são meras descrições dos objetos que as 
compõem, são especificações que descrevem os seus objetos.
2. Associação, agregação, composição, classe de associação e herança.
3. Visualização de alguns objetos nas classes. Com isso, é possível verificar se foram 
identificados todos os atributos necessários para as classes, se algum deles está 
na classe errada, e possibilita ter uma visão geral de como serão os objetos das 
classes quando o sistema estiver sendo usado efetivamente.
4 Diagrama de Sequência
1. O objetivo principal do Diagrama de Sequência é identificar a ordem em que os 
eventos ocorrem e determinar os métodos que serão chamados para atender a 
esses eventos, refletindo assim a interação entre os objetos envolvidos em um 
determinado processo.
2. Ator, objeto e mensagem.
3. REF, OPT, LOOP e ALT.
Gabarito 137
5 Diagramas suplementares da UML
1. O Diagrama de Transição de Estados demonstra graficamente a mudança de 
estado de um ou mais elementos ou objetos de um sistema por meio de um 
conjunto de transições.
2. Ação, fluxo, nó de decisão e barra de sincronização.
3. O Diagrama de Pacotes pode representar um conjunto de sistemas integrados; 
submódulos de um único sistema; a arquitetura de uma linguagem de programação; 
a arquitetura de um processo em desenvolvimento.
A
N
Á
LISE D
E SISTEM
A
S
JAIME WOJCIECHOWSKI
Código Logístico
59856
Fundação Biblioteca Nacional
ISBN 978-65-582-1013-9
9 7 8 6 5 5 8 2 1 0 1 3 9necessidades e obter um consenso para a solução que será entregue. Em suas 
principais práticas estão tarefas, técnicas, orientações, papéis e responsabilidades 
(VASQUEZ, 2016).
O profissional responsável por essas tarefas é o analista de requisitos (que tam-
bém pode ser o analista de sistemas). Ele realiza as atividades previstas na fase de 
Levantamento de Requisitos e no mapeamento dos processos de negócio. A docu-
mentação técnica de especificação de Requisitos de softwares fornece um vasto 
material aos analistas de sistemas para que possam trabalhar na fase de Elabora-
ção, fazendo a modelagem do sistema.
Levantar Requisitos significa entender o negócio e o problema do cliente, iden-
tificar suas necessidades de software, investigar quais são as suas expectativas 
em relação à solução informatizada que será adotada, em resumo, definir o que o 
software vai fazer.
Nesse quesito, o maior problema que pode ocorrer é a dificuldade de comuni-
cação entre o analista e o cliente.
Na fase de Levantamento de Requisitos, então, é definido o escopo do sistema 
para se ter claro a que o sistema vai atender (e também a que ele não vai atender) 
e, principalmente, são identificados os seus Requisitos.
1.2.1 Conceitos
O conceito principal nessa área é o de Requisito. Segundo Vasquez (2016, p. 18), 
“é uma condição ou capacidade do sistema, solicitada pelo usuário, para resolver um 
18 Análise de Sistemas
problema ou atingir um objetivo”. Na prática, os Requisitos são funções, objetivos, 
propriedades ou restrições que o sistema deve possuir para satisfazer usuários.
De modo geral, um Requisito é uma condição necessária para satisfazer um 
objetivo, é uma exigência, solicitação, desejo e necessidade. Para Vasquez (2016):
Um usuário necessita que o sistema resolva seu problema ou 
o ajude a alcançar seu objetivo.
Requisitos estão relacionados a necessidades
Um usuário deve possuir a condição dada pelo sistema para 
satisfazer um contrato, padrão, especificação ou outro documen-
to formalmente imposto.
Requisitos estão relacionados a propriedades
Uma representação documentada de uma condição ou capaci-
dade como nas duas primeiras definições.
Requisitos possuem uma especificação
Os Requisitos estão ligados ao atendimento do negócio do sistema. Por exem-
plo, uma das funções de um sistema de venda de jogos pela internet é ter uma ou 
mais telas capazes de realizar a venda de um determinado jogo. Esse é o objetivo 
principal do sistema. Portanto, vender jogos é um Requisito do sistema (provavel-
mente o principal).
1.2.2 Tipos de Requisitos
Na análise do problema para a elaboração da Lista de Requisitos, podemos 
identificar vários tipos. É importante conseguirmos separar os Requisitos nesses 
tipos com o objetivo de melhor atuarmos no seu detalhamento e implementação. 
Os tipos de Requisitos serão especificados a seguir.
1.2.2.1 Requisitos Funcionais
Descrevem o comportamento que o software deve ter em termos de serviços 
para o negócio do usuário. Têm como objetivo as necessidades do assunto de 
que trata o sistema do cliente.
Os Requisitos Funcionais se referem às funções relacionadas com o negócio do 
cliente, com as funções que atendam diretamente às suas necessidades. Definem 
o que o sistema fará para atender ao pedido do cliente. São os Requisitos mais im-
portantes. O quadro a seguir apresenta exemplos desse tipo de Requisito.
Introdução à análise de sistemas e Levantamento de Requisitos 19
Quadro 1
Exemplos de Requisitos Funcionais em diversos negócios
O sistema deve cadastrar médicos profissionais.
O sistema deve emitir um relatório de clientes.
O sistema deve passar um cliente da situação “em consulta” para “consultado” quando o cliente 
terminar de ser atendido (mudança de estado).
O cliente pode consultar seus dados no sistema.
Executar a baixa dos boletos de contas a receber.
Renovar contrato.
Emitir certificado de participação do aluno no curso.
Vender passagem aérea.
Fonte: Elaborado pelo autor.
Quando um Requisito Funcional estiver escrito em um nível macro, passando 
uma ideia ampla, ele é chamado de Requisito Funcional Agregador. Não é indicado 
trabalhar com esse tipo na fase de modelagem do sistema, pois invariavelmente 
ele terá de ser subdividido para sua implementação. Então, o mais indicado é fazer 
essa divisão na fase de Levantamento dos Requisitos. Exemplos: efetuar gestão dos 
cursos; gerenciar relacionamento com clientes etc.
De maneira contrária aos Requisitos Agregadores, um Requisito Funcional pode 
ser fragmentado em vários Requisitos chamados de Requisitos de Subfunção. Tam-
bém não é indicado relacionar somente os Requisitos de Subfunção, pois eles só 
têm a função de mostrar as partes de um Requisito.
Por exemplo: o Requisito Funcional Sacar dinheiro em um caixa eletrônico teria 
três subfunções:
1. validar senha;
2. verificar saldo;
3. debitar conta.
1.2.2.2 Requisitos não Funcionais
Representam limitações ou determinações impostas aos Requisitos Funcionais. 
Falam das condições do ambiente no qual o software será executado e como esse 
ambiente pode afetar ou restringir a perfeita realização dos Requisitos Funcionais. 
Descrevem como o sistema deve funcionar. Entre outros aspectos, falam sobre:
 • O ambiente – segurança, comunicação etc.
 • A organização – locais de operação, tipos de hardware etc.
 • A implementação – linguagem de programação, Banco de Dados e 
arquitetura.
 • A qualidade – tempo de resposta, facilidade de uso, eficiência e facilidade de 
manutenção.
20 Análise de Sistemas
O quadro a seguir apresenta exemplos desse tipo de Requisito.
Quadro 2
Exemplos de Requisitos não Funcionais
Requisito Descrição
RNF1 – Tempo de resposta on-line
Todas as solicitações on-line feitas no sistema devem ter a 
resposta num tempo inferior a 15 segundos.
RNF2 – Disponibilidade do sistema
O sistema deve estar disponível ao usuário 24 horas/dia per-
mitindo paradas de até 5 minutos nos dias úteis e 1 hora em 
dias não úteis.
RNF3 – Autenticação dos usuários
Todos os usuários devem ser autenticados ao ingressar no 
sistema e suas senhas devem estar criptografadas.
Fonte: Elaborado pelo autor.
A prioridade de tratamento deve ser para os Requisitos Funcionais. Os Requi-
sitos não Funcionais podem ser tratados em um momento secundário do projeto.
1.2.3 Elicitação de Requisitos
Elicitação de Requisitos é a ação de aplicar as técnicas para o Levantamento dos 
Requisitos (VASQUEZ, 2016). Existe um longo caminho desde os primeiros contatos 
com o cliente a fim de conhecer suas necessidades até chegar a uma Lista de Re-
quisitos. Reuniões, análise de documentos e planilhas existentes, conhecimento de 
sistemas legados, dentre outras, são atividades que devem ser realizadas para se 
chegar ao objetivo.
É importante saber aplicar as técnicas corretas para que todos os detalhes e pe-
culiaridades do sistema fiquem esclarecidos e não ocorram entendimentos confli-
tantes ou insuficientes que acarretem um sistema que não coincide com os anseios 
do cliente.
A seguir veremos algumas técnicas e como aplicá-las para levantar os Requisitos.
1.2.3.1 Entrevistas e reuniões
Uma entrevista ou reunião, no âmbito do Levantamento de Requisitos, consiste 
no processo de ouvir e registrar as necessidades e os desejos dos clientes. O obje-
tivo é deixar o cliente descrever seu problema, apontar possíveis soluções e, princi-
palmente, demonstrar o funcionamento e as regras do seu negócio. O analista de 
requisitos busca respostas sobre os Requisitos, problemas e desafios da área de ne-
gócios, então é muito importante que o escopo da entrevista ou reunião fique res-
trito ao seu objetivo e que nenhum detalhe deixe de ser tratado (VASQUEZ, 2016).
Primeiramente uma entrevista ou reunião deve ser guiada por uma pauta de 
perguntas muito bem elaboradas pelo analista de requisitos. Novas questões po-
dem ser inseridas no decorrer do encontro dependendo do caminho que o assunto 
percorra e, também, para um maior detalhamento das questões levantadas.Para o bom andamento do encontro, algumas atitudes devem ser evitadas:
Introdução à análise de sistemas e Levantamento de Requisitos 21
11
Julgar/criticar as informações emitidas pelo outro
O cliente deve se sentir à vontade para passar as informações sem que seja julgado sobre a assertividade dos 
procedimentos que realiza. A informatização do processo por meio do sistema visa justamente à criação de um novo 
processo por meio do sistema que atenda perfeitamente à sua vontade.
22
Completar frases ou cortar a fala
É comum o analista de requisitos ter um entendimento prévio sobre o negócio do usuário e ter a ansiedade de colocar 
a sua opinião acerca dos procedimentos que estão sendo descritos pelo cliente. Essa discussão é benéfica, porém 
nunca se deve perder de vista que é o cliente quem tem a última palavra e que é a sua vontade que deve ser atendida. 
Então, o analista deve se conter e não interromper ou substituir as falas do cliente com a intenção de que a conversa vá 
em alguma direção de seu interesse.
33
Ser arrogante ou deixar a impressão de que sabe mais do que o outro
Na mesma linha do tópico anterior, o analista deve ter uma postura humilde perante o cliente. Jamais usar termos ou 
ter uma postura que denote superioridade ou que diminua a figura do cliente. O cliente deve se sentir à vontade para 
expressar suas opiniões e ter a ciência de que está no controle da situação.
55
Dar a solução antes de ouvir o problema
Oficialmente é o cliente quem detém o conhecimento do assunto que está sendo levantado. Então, a solução do 
problema deve vir dele. Mesmo que o analista conheça o problema e possíveis soluções, deve se comportar como um 
colaborador e deixar com que o cliente faça sua explanação completa antes de opinar sobre a solução.
66
Falta de cortesia, pontualidade e simpatia ou visual inapropriado
Na mesma linha do tópico anterior, o analista deve ter uma postura humilde perante o cliente. Jamais usar termos ou 
ter uma postura que denote superioridade ou que diminua a figura do cliente. O cliente deve se sentir à vontade para 
expressar suas opiniões e ter a ciência de que está no controle da situação.
77
Local, hora ou duração inadequada
O local do encontro deve ser preparado, organizado, tranquilo e sem interrupções. Deve-se definir um horário para iniciar 
(e esse horário deve ser seguido, salvo atraso do cliente) e, principalmente, a duração deve ser respeitada (salvo também 
se o cliente deseja que seja estendida).
44
Corrigir, seja informação técnica ou gramática
As correções devem ser feitas no sentido de enriquecer a fala do cliente, não constrangê-lo. Se o analista entender que 
alguma informação técnica está incorreta, deve se colocar na postura de que não compreendeu direito a informação 
e necessita de mais esclarecimentos. Deve deixar que o cliente chegue à conclusão de que a informação não está 
totalmente esclarecida ou correta. Ao final da fala, pode-se até resumir, em outras palavras, a informação recebida para 
validar o entendimento entre as partes. Já os erros gramaticais e de natureza semelhante devem ser relevados e não 
devem ser corrigidos abertamente, salvo se comprometer o entendimento da informação e, mesmo assim, seguindo a 
estratégia já descrita.
22 Análise de Sistemas
88 Vocabulário impróprio
O vocabulário deve ser formal e apropriado para o assunto, evitando piadas e linguagem vulgar.
99
Demonstrar despreparo sobre o assunto
O analista precisa se preparar para a entrevista, deve estudar o assunto, ter as perguntas organizadas e ter um 
mecanismo simples e ágil para registrar as respostas.
Uma entrevista ou reunião pode ter questões abertas e/ou fechadas, dependen-
do da necessidade de entendimento do assunto:
Nesse tipo de questão, é possível investigar 
os detalhes, as opiniões e as preferências 
do cliente. Numa resposta textual, a 
tendência é que o cliente consiga explicar 
melhor o assunto. 
Nesse tipo de questão, é possível investigar 
os detalhes, as opiniões e as preferências 
do cliente. Numa resposta textual, a 
tendência é que o cliente consiga explicar 
melhor o assunto. 
Essas questões têm a vantagem de deixar o 
cliente mais à vontade para discorrer sobre 
o assunto, permitem que o analista se 
adapte ou conheça o vocabulário do cliente 
e fornecem uma riqueza maior de detalhes.
Como desvantagens, podem permitir que 
o cliente explique detalhes desnecessários 
que não são do escopo do problema e 
fazer com que o foco seja desviado. Isso 
consumirá mais tempo e poderá dificultar a 
interpretação das respostas obtidas.
Questões abertas
Nesse tipo de questão, é possível investigar 
os detalhes, as opiniões e as preferências 
do cliente. Numa resposta textual, a 
tendência é que o cliente consiga explicar 
melhor o assunto. 
Essas questões têm um conjunto de 
respostas predefinidas. Ele serve para 
delimitar o assunto em questão e restringir 
aquilo que se tem interesse em descobrir. 
A criação dessas questões deve ser muito 
bem estudada e organizada. 
As vantagens dessas questões são que 
economizam tempo, pois requerem a 
escolha de uma opção delimitada por parte 
do cliente. Pode-se fazer uma interpretação 
mais simples das respostas e facilitam o 
controle do encontro por parte do analista.
Como desvantagens, as questões 
fechadas podem dar a sensação de 
restrição para o cliente e dar a conotação 
de que outras questões que ele acha 
importante não podem ser abordadas. 
Perde-se a riqueza de detalhes que muitas 
vezes são de grande importância.
Questões fechadas
Uma boa entrevista ou reunião deve então balancear questões abertas e fecha-
das, sempre com um estudo prévio de qual tipo será mais vantajoso e apropriado 
para cada tema que se deseja levantar.
As questões de uma entrevista ou reunião (abertas ou fechadas) podem ter as 
seguintes estruturas:
Nessa estrutura, inicia-se o encontro com questões fechadas e, dependendo das respostas, 
questões abertas podem ser inseridas para o detalhamento dessas respostas. É uma estrutura 
que permite o foco em subtópicos e facilita a organização do analista.
Pirâmide
Ao contrário da anterior, inicia-se o encontro com questões abertas, e as fechadas são 
inseridas para tentar organizar ou detalhar as respostas das questões abertas.
(Continua)
Funil
Introdução à análise de sistemas e Levantamento de Requisitos 23
É uma combinação das anteriores. Inicia-se com questões fechadas e, em seguida, são 
inseridas questões abertas, podendo-se voltar às fechadas. Essa estrutura é mais dinâmica, 
porém a tendência é que o encontro fique mais longo.
Diamante
Uma entrevista ou reunião deve ser muito bem preparada. Para isso, as seguin-
tes diretrizes devem ser seguidas:
 • Defina claramente o objetivo do encontro e de quais informações você precisa.
 • Identifique as pessoas adequadas que podem participar.
 • Descubra quem é o dono do processo.
 • Avalie conversar com pessoas em vários níveis organizacionais que serão afe-
tados pelo projeto.
 • Estude bem o assunto, analise a documentação, converse com pessoas que 
conhecem o assunto.
 • Familiarize-se com o vocabulário da área de negócio.
 • Comunique claramente os participantes para que eles também se prepara-
rem para o encontro.
 • Use a técnica conhecida como 5W+2H no preparo das questões:
 • What - o que será feito?
 • Why - por que será feito?
 • Where - onde será feito?
 • When - quando será feito?
 • Who - quem fará?
 • How - como será feito?
 • How much - quanto custará?
A técnica de Elicitação de Requisitos, conhecida como entrevista ou reunião, é 
uma das técnicas mais utilizadas na tarefa de Levantamento de Requisitos e am-
plamente difundida na área de desenvolvimento de software. A imensa maioria 
dos sistemas desenvolvidos têm no seu início de desenvolvimento um conjunto de 
entrevistas e reuniões.
1.2.3.2 Análise de documentos
É uma forma de elicitar Requisitos pelo estudo da documentação disponível so-
bre uma solução existente, com o objetivo de identificarinformações relevantes 
para o desenvolvimento de uma nova solução.
A análise de documentos é parte fundamental da Elicitação de Requisitos. Nem 
sempre as partes envolvidas estarão disponíveis ou cooperarão com o projeto, en-
tão o analista de requisitos deve focar a documentação sobre o negócio que está 
disponível na corporação.
Essa análise permite obter conteúdo sobre o contexto abordado ou aumentar o 
nível de domínio sobre o problema, além de possíveis soluções a serem adotadas. 
24 Análise de Sistemas
Sempre há algo documentado previamente que deverá ser analisado para depois 
partir para outras técnicas de elicitação.
Os documentos podem trazer informações sobre o domínio do problema, ne-
cessidades do negócio (oportunidades, problemas e objetivos), partes interessadas 
e impactadas.
São exemplos de documentos a serem analisados:
 • planos de negócio, marketing e contratos;
 • pedidos de proposta e fluxos de processos atuais;
 • modelos de dados lógicos e regras de negócio;
 • guias, websites e manuais;
 • relatórios, manuais, memorandos e documentação de software.
1.2.3.3 Conhecimento dos sistemas legados
Um sistema legado é aquele que o cliente já utiliza para resolver o problema 
relacionado ao assunto e que deseja substituir pelo novo sistema. É possível e 
aconselhável levantar as informações do negócio e, consequentemente, levantar e 
compreender os Requisitos conhecendo esse sistema já existente. Esse estudo tan-
to permite que se conheça o funcionamento do sistema como as regras do negócio, 
as dificuldades existentes (já que o cliente deseja que o sistema seja substituído) e 
as facilidades (que podem ser incorporadas no novo sistema).
É importante se envolver com a equipe de usuários do sistema legado, com a 
equipe de desenvolvimento que mantém o sistema funcionando e, se possível, 
ter acesso ao sistema no papel de usuário para testar todas as suas funcionalida-
des. Com isso, é possível ter uma boa noção daquilo que o sistema atende para 
propor uma abordagem mais moderna e funcional, cobrindo todas as necessida-
des do cliente com maior dinamismo e eficiência. Também é possível analisar os 
programas desse sistema e extrair dali as regras de negócio e o funcionamento 
do processo.
1.2.4 Especificação de Requisitos
Se a tarefa de Elicitação de Requisitos descobre as peças do quebra-cabeça, 
então a análise e Especificação de Requisitos procura montá-lo (VASQUEZ, 2016).
Durante a aplicação das técnicas para levantar quais são os Requisitos, na me-
dida do possível, o analista deve procurar escrever uma Lista de Requisitos. Esse é 
o objetivo final do trabalho de levantamento.
Porém, não é uma tarefa fácil. Normalmente o cliente tem sua forma própria de 
registrar as informações e processos e nem sempre de uma maneira estruturada. 
Para ilustrar, vejamos a situação colocada na Figura 9.
Introdução à análise de sistemas e Levantamento de Requisitos 25
Ve
ct
or
_V
isi
on
/S
hu
tte
rs
to
ck
O que o senhor espera 
desse sistema?
Eu tenho uma loja de peças. Gostaria que o meu PV 
fosse interligado com o meu estoque e eu pudesse 
a qualquer momento alterar valores dos FPs. Posso 
oferecer descontos a alguns tipos de clientes, mas 
preciso autorizar essa operação.
No fim do mês, quero um relatório dos produtos que 
mais venderam. Preciso também saber a estatística 
de vendas por forma de pagamento.
De tempos em tempos deve aparecer na tela do 
sistema uma promoção relâmpago que dê um brinde 
ao cliente.
Preciso que o sistema controle os pedidos também.
Figura 9
Diálogo entre usuário e analista
Fonte: Adaptado de Melo, 2011.
Podemos perceber nesse diálogo a dificuldade que existe em entender os ter-
mos usados pelo usuário, bem como a falta de informações em alguns pontos:
Quadro 3
Diálogo entre usuário e analista – dúvidas
O que é PV e FP?
Que tipos de clientes podem receber descontos?
Como seria feita a autorização de desconto e por quem?
Quais quantidades de produtos devem aparecer no relatório dos que mais venderam?
Quanto tempo significa “de tempos em tempos”?
Fonte: Adaptado de Melo, 2011.
O processo de Levantamento dos Requisitos envolve então muitas conversas, 
reuniões, entrevistas, estudo dos sistemas legados, entre outros, em um trabalho 
criterioso de Elicitação dos Requisitos, no qual o maior desafio é chegar a um con-
senso de entendimento daquilo que o usuário deseja e principalmente extrair as 
regras e o funcionamento do seu negócio.
Como exemplo, poderíamos ter o seguinte cenário na fase de Levantamento 
dos Requisitos, conforme mostra a Figura 10.
26 Análise de Sistemas
M
on
ke
y B
us
in
es
s 
Im
ag
es
/S
hu
tte
rs
to
ck
Fonte: Elaborada pelo autor.
Figura 10
Ilustração do processo de montagem da Lista de Requisitos
Blá blá blá bli bli bli piripipi piripipi poropopó poropopó bli bli bli blá 
blá blá poropopó John Snow piripipi piripipi Dynaris Targeryan blá blá 
blá Blá blá blá bli bli bli piripipi piripipi poropopó poropopó bli bli bli 
blá blá blá poropopó John Snow piripipi piripipi Dynaris Targeryan blá 
blá blá blá blá blá bli bli bli piripipi piripipi poropopó poropopó bli bli 
bli blá blá blá poropopó John Snow piripipi piripipi Dynaris Targeryan 
blá blá blá
Nessa figura, as pessoas sentadas em uma mesa conversando simbolizam uma 
reunião na qual o problema está sendo discutido e o cliente está repassando suas 
necessidades. A tabela em forma de planilha simboliza os sistemas legados que já 
existem e que devem ser substituídos. Após o trabalho de elicitação, o objetivo final 
é chegar a uma Lista de Requisitos.
Os Requisitos devem ser especificados segundo algumas regras, com o objetivo 
de colocá-los em uma estrutura que facilite sua modelagem e implementação nas 
fases seguintes do processo de desenvolvimento. As seguintes regras são sugeri-
das (VASQUEZ, 2016):
 • Expressar um e somente um Requisito por vez.
 • Evitar cláusulas condicionais complexas.
 • Usar uma terminologia clara e consistente.
 • Expressar Requisitos em uma sentença com verbo e em voz ativa.
 • Indicar claramente o que ou quem é responsável pela ação realizada pelo 
Requisito.
O exemplo a seguir, extraído de Vasquez (2016), mostra a forma errônea de 
se escrever um Requisito. A referida escrita expressa vários Requisitos em um só 
e inclui cláusulas condicionais, além de não incluir o verbo que caracteriza a ação 
principal realizada.
Quadro 4
Exemplo de Lista de Requisitos – forma equivocada de escrita
Requisito Descrição
R1 – 
Controle de portaria
Para realizar o controle de entrada e saída da portaria, deve ser realizado o 
cadastro do visitante com os seguintes atributos: nome, RG e foto. Caso a visita 
tenha sido liberada pelo condomínio, então podem ser registradas a data e a 
hora em que o visitante acessou a portaria. Ao sair do condomínio, devem ser 
registradas a data e a hora em que o visitante saiu, mas isso só deve ser permi-
tido para visitante com registro de entrada e sem registro de saída.
Fonte: Adaptado de Vasquez, 2016.
Introdução à análise de sistemas e Levantamento de Requisitos 27
Os mesmos Requisitos deveriam ser reestruturados conforme mostra o quadro 
a seguir.
Quadro 5
Exemplo de Lista de Requisitos – forma correta de escrita
Requisito Descrição
R1 – Manter cadastro do visitante
O porteiro realiza o cadastro do visitante com os seguintes 
atributos: nome, RG e foto.
R2 – Liberar acesso ao visitante
O porteiro cadastra a liberação do acesso selecionando um 
visitante já cadastrado e indica a data e hora de início da visita.
R3 – Registrar saída do visitante O porteiro registra a data e hora do fim da visita.
Fonte: Adaptado de Vasquez, 2016.
Por exemplo, considere o seguinte estudo de caso com as especificações de um 
determinado problema e, em seguida, qual seria a lista de todos os Requisitos que 
o sistema deve atender.
Suponha uma Escola de Natação que deseja informatizar o processo de controle dos alunos e 
suas aulas. A escola oferece aulas de natação e hidroginásticaem diversas turmas com dias e 
horários definidos. Os professores podem atuar em várias turmas e nas duas modalidades. O 
aluno, ao se matricular, deve poder escolher uma modalidade e qual turma deseja. No decorrer 
das aulas, os professores devem registrar a presença dos alunos.
É normal que o próprio cliente já faça suas solicitações na forma de Requisitos. É comum ouvir 
solicitações do tipo:
• Desejo ter um cadastro de todos os meus alunos.
• Preciso de um relatório com todas as mensalidades pagas no mês.
• Tenho de ter uma tela (palavras do cliente) para fazer a matrícula dos alunos.
• Quero que os professores controlem a frequência dos alunos nas aulas.
Para esse problema, teríamos os seguintes Requisitos:
Quadro 6
Lista de Requisitos da Escola de Natação
Requisito Descrição
R1 - Manter cadastro dos alunos
Permitir o cadastro completo dos alunos (pes-
quisar, incluir, alterar, excluir e consultar).
R2 - Manter cadastro dos professores
Permitir o cadastro completo dos professores 
(pesquisar, incluir, alterar, excluir e consultar).
R3 - Manter cadastro das turmas
Permitir o cadastro completo das turmas, sua 
modalidade (natação ou hidroginástica), seus 
dias/horários e qual professor responsável.
R4 – Matricular alunos Matricular os alunos nas turmas.
R5 - Registrar frequência
Registrar frequência no diário de classes de 
cada aula.
Fonte: Elaborado pelo autor.
Estudo de caso
Para cada Requisito, devemos entender quais são as regras de negócio que cada 
um deve seguir. Por exemplo, no R4 – Matricular alunos, pode ser que o dono da es-
cola coloque algumas restrições do tipo: “pessoas com mais de 80 anos só podem se 
matricular na modalidade hidroginástica”. Esse é um exemplo de regra de negócio.
As regras de negócio impõem restrições de negócio ao Requisito, impedindo 
que informações inconsistentes sejam registradas no sistema do ponto de vista do 
negócio. Alguns aspectos sobre as regras de negócio são:
28 Análise de Sistemas
As regras que dizem respeito aos Requisitos funcionais são leis que regem o ne-
gócio e são definidas pelo especialista do assunto.
Mostram como os Requisitos devem ser feitos.
Descrevem de modo complementar o funcionamento do Requisito.
Descrevem políticas corporativas, legislação pertinente, regulamenta-
ções governamentais, padrões de mercado. 
Não são ligadas à solução (de software), mas ao domínio do problema.
Existem independentemente do software e de o processo estar automatizado 
ou não. 
Não devem ser confundidas com Requisitos não Funcionais.
Alguns exemplos de regras de negócio são:
 • Somente alunos com mais de 75% de frequência podem ser aprovados na 
disciplina.
 • Somente clientes com mais de 18 anos podem abrir conta corrente.
 • Compras acima de R$ 500,00 podem ser parceladas.
 • Crianças de até 23 meses transportadas no colo do responsável não pagam 
passagem.
O Quadro 7 mostra algumas estruturas de regras de negócio com exemplos.
Quadro 7
Estruturas de regras de negócio
Tipo de estrutura Estrutura Exemplo
Regra para obrigar
“(Sujeito da frase) 
deve...”
Um pedido de empréstimo acima de R$ 1.000,00 
deve ter dois avalistas.
Regra para restringir
“(Sujeito da frase) pode 
... somente se...”
Um saque pode ser feito somente se a conta es-
tiver ativa e o saldo for suficiente.
Regra para proibir
“(Sujeito da frase) não 
pode...”
Um cliente não pode fazer um empréstimo se ti-
ver restritivos.
Fonte: Elaborado pelo autor.
Finalmente, o resultado final da fase de Levantamento de Requisitos deve ser 
uma Lista de Requisitos no formato do Quadro 8.
Introdução à análise de sistemas e Levantamento de Requisitos 29
Quadro 8
Lista de Requisitos da Escola de Natação completa
Requisito Descrição Regras de negócio
R1 - Manter cadastro dos 
alunos
Permitir o cadastro completo dos alu-
nos.
Permitir pesquisar, incluir, alterar e consultar.
Não permitir a exclusão de um aluno, somente 
marcar como inativo.
R2 - Manter cadastro dos 
professores
Permitir o cadastro completo dos pro-
fessores.
Permitir pesquisar, incluir, alterar, excluir e 
consultar.
R3 - Manter cadastro das 
turmas
Permitir o cadastro completo das 
turmas, sua modalidade (natação ou 
hidroginástica), seus dias/horários e 
qual professor responsável.
Não permitir o cadastro de duas turmas da mes-
ma modalidade no mesmo horário.
R4 – Matricular alunos Matricular os alunos nas turmas.
Pessoas com mais de 80 anos só podem se ma-
tricular na modalidade hidroginástica.
R5 - Registrar frequência
Registrar frequência no diário de clas-
ses de cada aula.
Fonte: Elaborado pelo autor.
No ciclo de desenvolvimento do sistema, essa atividade corresponde à fase de 
Iniciação. A próxima fase, de Elaboração, consiste em informar como o sistema será 
modelado e como a solução será proposta e organizada. Os artefatos que serão 
construídos terão como base essa Lista de Requisitos.
1.3 Análise Orientada a Objetos (UML)
Vídeo No ciclo de desenvolvimento, a fase de Elaboração é a responsá-
vel pelo projeto de solução do sistema. Nela são produzidos artefatos 
(documentos e diagramas) que irão balizar a construção do software.
É nessa fase que são aplicadas as técnicas de análise vistas ante-
riormente. Inicialmente figurava a Análise Estruturada, em seguida a 
Análise Estruturada Moderna (ou Análise Essencial) e, atualmente, o 
padrão de mercado é a Análise Orientada a Objetos (UML).
1.3.1 Conceitos
O termo Unified Modeling Language ou linguagem de modelagem 
unificada (UML) surgiu da necessidade de se padronizar a linguagem 
de modelagem da Análise Orientada a Objetos e possibilitou a uni-
ficação da escrita dos diversos diagramas previstos na técnica. Com 
o tempo, esse termo passou a ser quase um sinônimo da Análise 
Orientada a Objetos (BOOCH; RUMBAUGH; JACOBSON, 2012).
A versão inicial da UML foi apresentada em 1996 por Grady Booch, 
James Rumbaugh e Ivar Jacobson como consequência da junção das 
melhores características de cada um dos métodos de representação 
do processo de software que cada um desses autores desenvolveu.
A UML tornou-se então a linguagem padrão de modelagem adota-
da pelas empresas de desenvolvimento de software (GUEDES, 2018).
30 Análise de Sistemas
O conceito básico nessa teoria é o de Objeto, no qual os componentes de software 
foram considerados como objetos (do mundo real) com suas características e funções.
Um dos grandes problemas das teorias anteriores era a grande interferência 
que um determinado componente (programa ou dado) poderia ter sobre outro, 
ou seja, não havia nenhuma restrição que um determinado programa manipulas-
se dados ou interagisse com programas que não estavam relacionados com sua 
função, que não eram de sua responsabilidade. Com isso, era comum ocorrerem 
muitos erros de programadores que, de maneira inadvertida, alteravam funções 
ou dados, os quais acabavam impactando erros em partes do sistema que diziam 
respeito a outro assunto.
Um Objeto tem encapsulado seus dados e operações responsáveis por mani-
pular esses dados. Uma operação de um determinado Objeto não tem autorização 
(ou acesso) para manipular dados de outro Objeto se não pela solicitação ao Objeto 
responsável por esse dado. Com isso, os acessos não autorizados ficavam inviabili-
zados e, em tese, cada Objeto cuidava somente de suas funções.
Podemos exemplificar esse mecanismo de encapsulamento de um Objeto na 
Figura 11.
Figura 11
Encapsulamento de um Objeto
Fonte: Elaborada pelo autor.
incluir
nome
CPF
Cliente
vender
alterarDados
pedido 
data
Venda
Nesse exemplo, digamos que é necessária uma alteração no atributo data que 
se encontra no objeto venda. A única operação que tem autorização (e conhece as 
regras de negócio para esse procedimento) é a operação alterarDados desse Objeto. 
Seria impossível a operação incluir do Objeto cliente fazer uma alteração nesse atri-
buto data. Caso o Objeto cliente realmente necessite dessa alteração, a única forma 
possível seria fazer uma solicitação à operação alterarDados do Objetovenda.
Com esse mecanismo, evita-se o acesso descontrolado aos dados do sistema, 
impõe-se um conjunto de regras que somente os responsáveis pelos dados conhe-
cem e aplicam. Assim, o sistema tem maior integridade dos seus dados.
1.3.2 Artefatos da UML
Para a modelagem do sistema e representação da solução informatizada, a UML 
dispõe de diversos diagramas. Dentre os principais, pode-se citar os apresentados 
na sequência.
1.3.2.1 Digrama de caso de uso
Apresenta graficamente todos os Requisitos do sistema, bem como a interação 
com as entidades externas. A Figura 12 apresenta um exemplo desse diagrama.
Na tese de doutorado do autor 
deste livro, foi desenvolvido um 
software totalmente orientado a 
Objetos, o JCarbon, cujo objetivo 
é estimar o carbono em florestas 
usando técnicas de inteligência 
artificial. O software pode ser 
acessado em: www.jcarbon.ufpr.
br. Acesso em: 17 mar. 2021.
Curiosidade
Introdução à análise de sistemas e Levantamento de Requisitos 31
Figura 12
Exemplo de Diagrama de Caso de Uso de uma Escola de Natação
Fonte: Elaborada pelo autor.
Manter 
modalidade
Pesquisar 
modalidade
Pesquisar 
turma
Registrar 
presença do 
aluno
Pesquisar 
professor
Manter 
turma
Manter aluno
Pesquisar 
aluno
>
>
>
>
>
>
Ator atendente
Ator professor
>
Manter 
professor
Matricular 
aluno
1.3.2.2 Diagrama de Classes
É utilizado para modelar as classes de objetos, seus atributos, suas operações e 
relacionamento com outras classes. Ele fornece uma visão estrutural do sistema. A 
Figura 13 mostra um exemplo desse diagrama.
- cpf : int
- nome : String
Pessoa


Aluno
Matricula Turma
Diario
- dataAdmissao : Date 
Professor
- descricao : int
- data : Date - descricao : String
- data : int
Modalidade
Figura 13
 Exemplo de Diagrama de Classes de uma Escola de Natação 
Fonte: Elaborada pelo autor.
* *
*
*
32 Análise de Sistemas
1.3.2.3 Diagrama de Sequência
Determina a sequência de mensagens que devem ser trocadas entre os objetos 
do sistema para que um caso de uso realize completamente sua função. A Figura 
14 mostra um exemplo desse diagrama.
 
Figura 14
Exemplo de Diagrama de Sequência do Caso de Uso de realizar matrícula de uma Escola de Natação
: Matricula: Aluno: Turma: ModalidadeTela
sd DS – Realizar Matrícula – Resolvido
: Ator Atendente 
1 : Entrada ()
1.1 : buscar ()
1.1.1 : buscar ()
2.1 : buscar ()
3.1 : buscar ()
4.1 : salvar ()
2 : CPF ()
3 : Modalidade ()
4 : Efetivar ()
Fonte: Elaborada pelo autor.
1.3.2.4 Diagrama de Atividades
Permite demonstrar os fluxos de um processo. Pode ser usado para mostrar 
vários tipos de processos: um simples algoritmo, um caso de uso, um conjunto de 
casos de uso ou para mapeamento de processos. A Figura 15 mostra um exemplo 
desse diagrama.
Introdução à análise de sistemas e Levantamento de Requisitos 33
Figura 15
Exemplo de Diagrama de Atividades da solicitação de um extrato bancário
Fonte: Elaborada pelo autor.
Solicitar 
conta
Verificar 
conta
Apresentar extrato
Solicitar 
período
Validar 
período
Apresentar 
mensagem 
Senha inválida
Apresentar 
mensagem 
Período inválido
Solicitar 
senha
>
> >
>
1.3.2.5 Diagrama de Transição de Estado
Permite demonstrar a mudança dos possíveis estados de um Objeto e as condi-
ções para que isso ocorra. A Figura 16 mostra um exemplo desse diagrama.
Figura 16
Exemplo de Diagrama de Transição de Estados da situação de uma bagagem em um aeroporto
Fonte: Elaborada pelo autor.
Despachando Checando
Enviando para PF
Aguardando embarque
Transportando ao avião
Embarcando
Voando
DesembarcandoTransportando do aviãoEntrando na esteira
Transportando para 
Reclamações
Retirando
Aguardando retirada
Irregular
Passageiro não retirouPassageiro 
retirou
34 Análise de Sistemas
1.3.2.6 Diagrama de Pacotes
Permite a visualização dos pacotes de classes ou funções. A Figura 17 mostra 
um exemplo desse Diagrama com Pacotes de classes, e a Figura 18 mostra pacotes 
de funções.
Figura 17
Exemplo de Diagrama de Pacotes com Classes
Prova
Recurso
Prova Discursiva Prova Objetiva
Avaliação
Vagas
Cargo
Localidade
Fonte: Elaborada pelo autor.
Figura 18
Exemplo de Diagrama de Pacotes de Funções
Fonte: Elaborada pelo autor.
view controller
daomodel
A UML possui outros diagramas suplementares que não serão vistos aqui.
1.4 Métodos Ágeis aplicados ao 
desenvolvimento de sistemasVídeo
Os métodos de desenvolvimento ágil de software surgiram no início de 2000. 
Seu foco central era que os processos de produção de software deveriam se con-
centrar em indivíduos e interações sobre os processos e, principalmente, no produ-
to final, ou seja, no software funcionando (COHN, 2011).
O vídeo Google Systems 
Design Interview With An 
Ex-Googler (Entrevista de 
design de sistemas do 
Google com um ex-goo-
gler), publicado pelo 
canal Clément Mihailescu, 
mostra uma entrevista de 
um ex-analista da Google e 
explica, em termos gerais, 
como é o processo de 
desenvolvimento das fun-
cionalidades das aplicações 
Google usando Análise 
Orientada a Objetos.
Disponível em: https://www.youtube.
com/watch?v=q0KGYwNbf-0. Acesso 
em: 17 mar. 2021.
Vídeo
Introdução à análise de sistemas e Levantamento de Requisitos 35
1.4.1 Motivações para a criação dos Métodos Ágeis
A indústria de produção de software tornou-se extremamente burocrática e um 
grande esforço era dedicado à produção de documentos, diagramas e artefatos de 
modelagem que, em tese, deveriam ser úteis para melhorar a qualidade do produ-
to final.
Porém, nem sempre isso ocorria. O processo era engessado em normas e pa-
drões e as equipes eram obrigadas a segui-los. O resultado, quase sempre, era o 
atraso na entrega do sistema, um alto custo e a equipe insatisfeita com a metodo-
logia de trabalho.
Segundo Prikladnicki, Willi e Milani (2014, p. XIV), “a única constante no desen-
volvimento de software é a mudança, portanto criar mecanismos para adaptar-se a 
ela é mais eficaz do que tentar combatê-la”.
O mercado não aceitava mais o desperdício de tempo e dinheiro para produ-
zir artefatos que não tinham nenhuma utilidade. Como exemplo, imagine dezenas 
de documentos e diagramas escritos e desenhados com a proposta de solução 
e arquitetura do sistema, mas que, no momento de se fazer a programação dos 
componentes de software, nenhum era visto, nada do que foi escrito servia de base 
para a construção do software e todo o esforço gasto na sua produção era inútil.
No mínimo, esse modelo era muito custoso, pois horas tinham sido gastas na 
escrita de documentos que não seriam mais usados. Era como se o mais impor-
tante do processo fosse a produção de documentos, e não a produção efetiva do 
sistema (VALENTE, 2020).
Os Métodos Ágeis surgiram então com o objetivo de adotar práticas eficientes 
em todo o processo de desenvolvimento. Nesses métodos, só se produz aquilo que 
é útil e ajuda no desenvolvimento, os artefatos são construídos na medida exata da 
necessidade, sem perda de tempo e sem uso indevido de recursos.
Considerando que a prioridade é o cliente, os Métodos Ágeis surgiram também 
com o objetivo de enxugar o processo de desenvolvimento e dar mais agilidade às 
etapas, a fim de atender aos Requisitos.
Segundo Cohn (2011), os Métodos Ágeis se justificam por algumas razões:
 • maior produtividade e menores custos;
 • maior engajamento e satisfação no trabalho por parte da equipe de 
desenvolvimento;
 • atendimento rápido às demandas do mercado;
 • maior qualidade;
 • e, principalmente, maior satisfação do cliente.
1.4.2 Princípios e valores do Manifesto Ágil
Os Métodos Ágeis surgiram então como uma filosofia de trabalho, uma forma 
de se estruturar equipes, uma nova maneira de se realizar as atividades. Essa filo-
sofia foi materializada no que foi chamado de Manifesto Ágil (BECK et al., 2001), um 
Lean Inception – Como 
alinhar pessoase construir 
o produto certo (que 
em tradução livre seria 
pensamento enxuto) traz 
excelentes reflexões sobre 
o uso de Métodos Ágeis 
no desenvolvimento de 
software com uma lingua-
gem simples e divertida.
CAROLI, P. São Paulo: Caroli, 2018.
Livro
36 Análise de Sistemas
documento que serviu de base para as organizações implantarem essa filosofia nas 
suas equipes de trabalho. Os quatro valores do Manifesto Ágil, assim como apare-
cem em Beck et al. (2001), são:
11
33
22
44
Indivíduos e interações mais 
importantes que processos e 
ferramentas.
Colaboração com o cliente mais 
que negociação de contrato.
Software funcionando mais que 
documentação abrangente.
Responder a mudanças mais que 
seguir um plano.
A seguir são apresentados os 12 princípios do Manifesto (BECK et al., 2001):
1. A maior prioridade é satisfazer o cliente por meio da entrega contínua e 
adiantada de software com valor agregado.
2. Mudanças nos Requisitos são bem-vindas, mesmo tardiamente no 
desenvolvimento. Processos ágeis tiram vantagem das mudanças visando à 
vantagem competitiva para o cliente.
3. Software deve ser entregue funcionando frequentemente, de poucas 
semanas a poucos meses, com preferência com menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em 
conjunto durante todo o projeto.
5. Projetos devem ser construídos em torno de indivíduos motivados. Eles 
devem ter o ambiente e o suporte necessário e receber confiança para 
fazerem o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma 
equipe de desenvolvimento é a conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os 
patrocinadores, desenvolvedores e usuários devem ser capazes de manter 
um ritmo constante indefinidamente.
9. Contínua atenção à excelência técnica e bom design aumentam a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho não realizado é 
essencial.
11. As melhores arquiteturas, Requisitos e designs emergem de equipes 
auto-organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, 
então, refina e ajusta seu comportamento.
Os valores e princípios desse Manifesto se aplicam a todas as etapas do desen-
volvimento de um software, desde a fase de Iniciação e Elaboração até as fases de 
construção e transição. Então, temos a tarefa de utilizar e construir os artefatos 
dessas fases seguindo esses princípios. Como o nome já diz, os Métodos Ágeis têm 
seu foco na agilidade de realizar as tarefas e isso significa que devemos otimizar 
Introdução à análise de sistemas e Levantamento de Requisitos 37
as atividades e construir os artefatos que necessariamente serão úteis, no nível de 
detalhamento que ajude os desenvolvedores nas fases seguintes.
Desse modo, a construção dos diagramas previstos na UML será ensinada mi-
nuciosamente, mas o detalhamento e a profundidade de sua utilização na prática 
devem ser avaliados. Não devemos esquecer que esses diagramas servirão de base 
aos programadores para a construção do software e alguns fatores devem ser leva-
dos em conta nessa avaliação:
A atribuição de tarefas para a equipe de programação deve levar em conta sua experiência. 
Se o conhecimento na tecnologia e no negócio do sistema é baixo, deve-se detalhar melhor os 
artefatos da UML. Caso contrário, pode-se pular algumas etapas, suprimir alguns artefatos ou 
escrevê-los de modo mais geral e sem muitos detalhes.
Experiência da equipe
Muitas vezes existe uma escassez de recursos, poucos profissionais à disposição e não existe 
a possibilidade de se realizar completamente as etapas. Nesse caso, a única alternativa é 
suprimir etapas.
Recursos
Muitas vezes a entrega tem data definida. Como o foco nos Métodos Ágeis é a entrega de 
um produto final, por vezes pode não existir tempo hábil para se realizar as tarefas de modo 
completo. Por conta disso, e com a ciência de toda a equipe e do cliente, pode-se suprimir 
etapas e diminuir o detalhamento.
Prazo
Todos esses aspectos devem ser medidos e avaliados no desenvolvimento 
e seguindo os princípios de agilidade e aplicação correta das técnicas. O “soft-
ware funcionando”, um dos principais valores do Manifesto, será entregue ao 
final do processo.
1.4.3 Introdução ao Scrum
Os Métodos Ágeis, personificados no Manifesto Ágil, trouxeram para a área de 
desenvolvimento de software uma nova filosofia de trabalho, uma nova aborda-
gem de como encarar os projetos, as equipes e, principalmente, o cliente. Porém, 
os profissionais em um determinado momento se perguntaram: e daí? O que eu 
faço agora? Gostei, mas como trabalho com isso? Concordo com todos os valores e 
princípios, mas na prática como aplico tudo isso?
Foi necessário então criar uma metodologia capaz de dotar as equipes com fer-
ramentas que transformassem uma filosofia de trabalho em algo palpável, que pu-
desse ser aplicado na prática e os resultados esperados fossem atingidos.
Nesse sentido, o Scrum é uma ferramenta (comumente chamada de framework) 
usada para implementar o desenvolvimento ágil (COHN, 2011). O conceito básico 
do Scrum é a Sprint (nome dado para os ciclos do projeto). Para entendermos esse 
conceito, temos de conhecer os termos incremental e iterativo.
Nas páginas 5 a 15 do livro 
Métodos ágeis para desen-
volvimento de software, você 
encontra, de maneira deta-
lhada, comentada e muito 
bem fundamentada, todos 
os valores e princípios do 
Manifesto Ágil, bem como 
quem são seus autores.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. 
Porto Alegre: Bookman, 2014.
Livro
38 Análise de Sistemas
O desenvolvimento de um software de maneira incremental envolve a constru-
ção “pedaço por pedaço”: primeiro uma parte é desenvolvida, depois a próxima 
parte e assim por diante. Por exemplo, um site de vendas de produtos incremental 
pode envolver primeiro o desenvolvimento do cadastro dos produtos, em seguida 
o cadastro dos clientes e, finalmente, a funcionalidade de venda dos produtos.
Por outro lado, o desenvolvimento iterativo aceita a possibilidade de retrabalho, 
de construir novamente aquilo que já foi feito, porém com um incremento de qua-
lidade nessa nova construção. Voltando ao exemplo do site de vendas de produtos, 
podemos primeiro desenvolver uma versão preliminar do site inteiro, com poucos 
detalhes, com as telas com pouca qualidade, com alguns recursos não informa-
tizados. O site é lançado para uso e recebe feedbacks do cliente e usuários; em 
seguida, passa-se para uma segunda versão, aprimorando a primeira e corrigindo 
as falhas.
Uma Sprint do Scrum, então, combina as melhores características das duas 
abordagens, incremental e iterativa. Com isso, o cliente recebe entregas rápidas do 
produto e vai contribuindo para a sua melhoria.
Os benefícios de se trabalhar com Sprints são:
 • O software funcionando encoraja o feedback do cliente.
 • O software funcionando ajuda a equipe a avaliar seu progresso.
 • O software funcionando permite que o produto seja entregue antes do 
desejado.
É consenso na área de desenvolvimento de software que uma Sprint não deve 
demorar mais do que duas semanas (apesar de se admitir Sprints de até 30 dias). 
Esse tempo é suficiente para se planejar um incremento no software e garantir que 
o cliente receba “novidades” em um curto espaço de tempo.
A Figura 19 ilustra a aplicação das Sprints no processo de entregas. O ciclo de 
14 dias representa uma Sprint, e o ciclo de 24 horas representa a avaliação diária 
do andamento da Sprint por parte da equipe de desenvolvimento.
Figura 19
Ciclo de entregas das Sprints
Fonte: Adaptada de De Paula, 2016.
SprintsRequisitos
14 dias
24 h
Incremento no 
software
Além do conceito de Sprint, o Scrum define algumas práticas para serem segui-
das (COHN, 2011; SUTHERLAND, 2019):
 • Reuniões diárias, rápidas e objetivas de apenas 15 minutos com a equipe de 
desenvolvimento.
 • Mostrar o