Engenharia de Software

Prévia do material em texto

Engenharia
de Software
Wagner Sanchez
W
agner Sanchez
Engenharia de Softw
are
Fundação Biblioteca Nacional
ISBN 978-65-5821-067-2
9 786558 210672
Código Logístico
I000358
Engenharia de 
Software
Wagner Sanchez
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: garagestock/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
S195e
Sanchez, Wagner
Engenharia de software / Wagner Sanchez. - 1. ed. - Curitiba [PR] : 
Iesde, 2021. 
106 p. : il.
Inclui bibliografia
ISBN 978-65-5821-067-2
1. Engenharia de software. 2. Software - Desenvolvimento. 3. Progra-
mação orientada a objetos (Computação). 4. UML (Computação). I. Título.
21-74615 CDD: 005.1
CDU: 004.41
Wagner Sanchez Doutor e mestre em Engenharia Biomédica pela 
Universidade Mogi das Cruzes (UMC), especialista 
em Inteligência Artificial pela Pontifícia Universidade 
Católica de Campinas (PUC-Campinas), psicopedagogo 
pela Pontifícia Universidade Católica de São Paulo (PUC-
SP), pós-graduado em Engenharia de Software pela 
Universidade São Judas Tadeu (USJT) e bacharel em 
Análise de Sistemas pela Universidade Paulista (UNIP). 
Possui formação em Leadership & Innovation pelo 
Massachusetts Institute of Technology (MIT) e, também, 
no Entrepreneurship Program, na Babson College. 
Tem mais de 25 anos de experiência em docência 
e consultoria nas áreas de tecnologia, inovação e 
educação. É autor da primeira coleção digital cognitiva 
voltada à educação maker e ao desenvolvimento do 
pensamento computacional para alunos do Ensino 
Fundamental, além de mais de oito livros publicados 
nas áreas de inovação, gestão, tecnologia e educação. 
Atua como pró-reitor acadêmico, professor, escritor e 
pesquisador. 
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 A importância da engenharia de software 9
1.1 O que é um software? 10
1.2 A evolução do hardware e software 12
1.3 A engenharia de software 22
1.4 A importância do design de software 25
2 Ciclo de vida do software 30
2.1 Ciclo de vida do software 31
2.2 Levantamento de requisitos 33
2.3 Análise e projeto 37
2.4 Implementação e testes 39
2.5 Implantação e manutenção 44
3 Orientação a objetos 51
3.1 Orientação a objetos 53
3.2 Classes e objetos 53
3.3 Abstração 56
3.4 Encapsulamento 57
3.5 Polimorfismo 60
3.6 Herança 61
4 UML – Unified Modeling Language 66
4.1 UML 66
4.2 Os diagramas da UML 68
4.3 Diagrama de atividades 68
4.4 Diagrama de classe 70
4.5 Diagrama de objetos 73
4.6 Diagrama de sequência 75
5 Diagrama de caso de uso 81
5.1 Diagrama de caso de uso 82
5.2 Cenário 83
5.3 Ator 84
5.4 Relacionamentos 85
5.5 Caso prático 87
 Resolução das atividades 101
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!
Com as transformações digitais que estão ocorrendo 
nas organizações, a necessidade por desenvolvimento de 
software segue um crescente sem precedentes e sem sinais de 
desaceleração. 
As evoluções exponenciais das tecnologias estão destravando 
outras tecnologias e, por consequência, oportunidades de 
soluções computacionais corporativas nunca pensadas, sempre 
buscando alavancar diferenciais competitivos. 
A engenharia de software dá suporte para que profissionais 
de TI, usuários e gestores possam empregar seus esforços 
de maneira eficiente na construção de soluções, com mais 
assertividade e, ao mesmo tempo, com menos recursos. 
Esta obra entregará todos os recursos para os envolvidos 
no desenvolvimento de softwares, durante todas as fases de 
construção das soluções, combinando métodos, melhores 
ferramentas e técnicas, para que a garantia da qualidade seja 
alcançada com excelência. 
APRESENTAÇÃOVídeo
A importância da engenharia de software 9
1
A importância da 
engenharia de software
Com o estudo deste capítulo, você será capaz de:
• 	compreender	a	definição	de	software;	
• entender	as	características	de	sistemas	computacionais;	
• conhecer	a	evolução	do	hardware	e	do	software	ao	longo	dos	
anos	e	sua	relação	com	o	momento	atual;
• compreender	a	origem	da	engenharia	de	software;	
• reconhecer	a	importância	do	design	de	softwares.
Objetivos de aprendizagem
A	engenharia	de	software	começa	quando	há	uma	demanda	por	de-
terminado	resultado	ou	solução	para	problemas	corporativos.	De	algum	
lugar	da	equipe	de	TI,	normalmente	do	CIO,	vem	uma	solicitação	feita	ao	
desenvolvedor	para	criar	algum	tipo	de	software.
Mas	como	os	desenvolvedores	sabem	o	que	colocar	em	seu	software?		
Eles	dividem	em	necessidades	específicas	após	conduzir	entrevistas,	cole-
tar	informações,	examinar	o	portfólio	de	aplicativos	existente	e	conversar	
com	líderes	de	TI.	Em	seguida,	constroem	um	roteiro	de	como	elaborar	o	
software.	Essa	é	uma	das	partes	mais	essenciais,	pois	muito	do	“trabalho”	
é	concluído	durante	esse	estágio,	o	que	também	significa	que	quaisquer	
problemas	normalmente	ocorreram	aqui.
O	verdadeiro	ponto	de	partida	é	quando	os	desenvolvedores	come-
çam	a	escrever	código	para	o	software.	Em	muitos	casos,	essa	é	a	etapa	
mais	 longa	 do	 processo,	 pois	 o	 código	 precisa	 ser	 congruente	 com	os	
sistemas	atuais	e	a	linguagem	usada.	Infelizmente,	esses	problemas	nor-
malmente	não	são	percebidos	até	muito	mais	 tarde	no	projeto,	 logo,	o	
retrabalho	precisa	ser	concluído.
10 Engenharia de Software
Para	evitar	retrabalhos	e	desperdícios	existem	os	conceitos	de	en-
genharia	de	software,	que	busca	entregar	um	produto	de	acordo	com	
as	necessidades	do	usuário,	sendo	altamente	confiável,	eficiente	e	efi-
caz	na	sua	proposta.	Embora	a	engenharia	de	software	possa	levar	a	
produtos	que	não	cumprem	isso,	eles	quase	sempre	voltam	ao	estágio	
de	produção	(SOMMERVILLE,	2011).
Neste	capítulo	exploraremos	como	essa	engenharia	pode	otimizar	a	
produção	de	softwares,	trazendo	um	maior	valor	agregado	com	um	me-
nor	custo	de	desenvolvimento.
1.1 O que é um software? 
Vídeo Software é uma sequência de instruções escrita por um programador 
em linguagem de programação, informando a um computador como se 
comportar ou executar uma tarefa específica (ENGHOLM, 2010).
O software geralmente vem na forma de programas comerciais, 
como Microsoft Word, Excel, PowerPoint e Adobe Photoshop, jogos, sis-
temas operacionais de computador, celulares ou até mesmo malware, 
como vírus e ransomware.
Qualquer programa ou código executado em um computador é um 
exemplo de software, e qualquer coisa que façamos com um computa-
dor requer um software. Este é criado por programadores de computa-
dor, comumente chamados de desenvolvedores de softwares.
Os três principais tipos de software são: de sistema operacional, 
de aplicação e de desenvolvimento. O sistema operacional controla 
o funcionamento interno do computador e os periféricos, como mo-
nitores, impressoras e equipamentos de armazenamento de dados 
(PFLEEGER, 2007).
Sem um sistema operacional como o Windows ou o MacOS, um 
computador é apenasum conjunto de componentes de hardware inca-
pazes de executar qualquer função. 
A importância da engenharia de software 11
O sistema operacional permite que o computador execute funções 
básicas, fornecendo uma interface para que os usuários interajam com 
ele e uma plataforma na qual os aplicativos sejam executados. O sistema 
“abstrai” muitas tarefas comuns para aplicativos a fim de minimizar a re-
dundância. Por exemplo, oferece impressão como um serviço para aplica-
tivos, de modo que cada programa não precisa ter sua própria maneira de 
enviar arquivos para a impressora. 
Nesse grupo temos o firmware, um tipo de software semipermanen-
te, apresentado por muitos dispositivos e componentes, que informa 
ao dispositivo como se comportar e interagir com outros dispositivos. 
Frequentemente, pode ser atualizado, mas persiste quando não há ali-
mentação aplicada ao dispositivo. 
Os drivers de dispositivo também pertencem ao grupo dos softwares 
de sistemas operacionais. São pequenos programas que permitem a 
comunicação entre o sistema operacional e os componentes do com-
putador. Cada componente precisa de um driver para que o sistema 
saiba como usar o dispositivo. Praticamente todos os componentes de 
um computador, incluindo placa de vídeo, chip de som, teclado e mou-
se, têm seus próprios drivers. 
Para finalizar, vale ressaltar os utilitários, programas que geralmen-
te vêm com o sistema operacional ou integram-se totalmente a ele – 
como software antivírus, de limpeza de disco rígido e ferramentas de 
compactação de arquivo – para executar tarefas específicas.
Já o software de aplicação indica ao computador quais tarefes 
devem ser executadas para atender às demandas do usuário para 
determinada necessidade. Nesse grupo estão processadores de texto, 
planilhas, gerenciamento de banco de dados, inventário e programas 
de contas a pagar, folha de pagamento, controle de estoque e muitas 
outras aplicações corporativas e pessoais.
Os jogos e o software de multimídia são aplicativos populares (a câ-
mera do telefone é um aplicativo, assim como o Adobe Photoshop, usa-
do para editar gráficos e fotos). Os navegadores da web também estão 
entre os aplicativos de software mais comuns.
Por fim, o terceiro grupo são os softwares de programação. Não 
deve ser surpresa que um software seja criado com outro software. 
Os codificadores contam com várias ferramentas diferentes para criar 
programas (HIRAMA, 2011). 
12 Engenharia de Software
A seguir estão alguns exemplos de programas usados por codifica-
dores durante o desenvolvimento de software. 
Compiladores: programas que convertem o código 
escrito por humanos em forma de código de máquina 
de nível inferior que pode ser interpretado diretamen-
te pelo hardware do computador. A existência de 
compiladores torna prático criar um software extre-
mamente sofisticado. 
bs
d/
sh
ut
te
rs
to
ck
Linkers: programas que pegam a saída de um compi-
lador, geralmente muitos arquivos individuais, e com-
binam em um único arquivo executável, que pode ser 
executado por um usuário sem a necessidade de um 
ambiente de programação.
bs
d/
sh
ut
te
rs
to
ck
Depuradores: programas de computador usados para 
testar e “depurar” (localizar e remover erros) o código 
do computador.bsd
/s
hu
tte
rs
to
ck
A seguir exploraremos a evolução dos hardwares e softwares ao 
longo dos anos para compreender a importância da engenharia de 
software e as transformações que impactam atualmente as nossas vi-
das e a das empresas.
1.2 A evolução do hardware e software 
Vídeo Um engenheiro de softwares deve estar apto a trabalhar com todos 
os segmentos envolvendo a tecnologia da informação (TI), ou seja, ser 
capaz de atuar em todos os vértices da pirâmide que define um sistema 
de informação: pessoas, hardware e software.
Isso significa que esse profissional precisa entender de hardwares, ser 
capaz de especificá-los e implementá-los e fazer a sua manutenção. Tam-
bém deve desenvolver e instalar softwares e fazer a manutenção deles.
Começaremos nosso caminho rumo ao entendimento das máquinas, 
dos softwares e do comportamento humano que têm moldado e defini-
do o presente e que, certamente, continuarão a fazê-lo no futuro.
A importância da engenharia de software 13
O computador surgiu essencialmente como uma ferramenta de 
trabalho. Era utilizado por bancos, instituições financeiras, governos, 
exércitos e cientistas para a execução, em tempo hábil, de cálculos en-
volvendo uma grande quantidade de valores ou operações. Porém, na 
década de 1970, como veremos mais adiante, essas máquinas passa-
ram a ser adquiridas por pessoas não ligadas a essas áreas para, além 
do trabalho, serem usadas para diversão, aprendizagem, comunicação 
e muitas outras coisas (VELLOSO, 2014).
Há algum tempo, os computadores são muito mais do que máqui-
nas presentes em algum cômodo específico das casas ou dos escritó-
rios; eles nos acompanham na forma de um celular, monitoram nossa 
vida na forma de uma geladeira inteligente, nos levam para lugares na 
forma de um carro autônomo, nos divertem na forma de um console 
de videogame, entre muitas outras coisas.
Um bom engenheiro de software pode, entre outras atribuições, 
ser destacado para a função de programador de computadores ou 
gerenciador do parque de computadores de uma empresa. Assim, 
como podemos observar, para um profissional de TI, o computador, 
mais do que uma ferramenta de trabalho, confunde-se com a própria 
razão de sua existência.
Em função disso, começaremos com um histórico da evolução dos 
computadores. Perceberemos que determinados elementos presentes 
nas primeiras máquinas ainda fazem parte das mais atuais e, provavel-
mente, estarão presentes nas do futuro.
Embora às vezes tenhamos uma impressão contrária a isso, na 
atualidade, quase todas as pessoas, desde a infância, são capazes de 
executar operações aritméticas básicas, mas nem sempre foi assim.
Houve uma época na história que pouquíssimas pessoas tinham 
essa formação, a ponto de ela confundir-se com uma habilidade. As 
pessoas que dominavam aritmética eram aproveitadas pelo comércio, 
pelos bancos e pelas empresas. 
Com o aumento exponencial das atividades que exigiam forma-
ção matemática e o crescimento em escala inferior das pessoas que 
a tinham, inventores debruçaram-se na solução desse problema, isto 
é, desenvolver uma máquina capaz de permitir que pessoas sem for-
mação ou conhecimento executassem operações matemáticas. Assim, 
14 Engenharia de Software
surgiram as máquinas mecânicas de calcular, as quais podemos dizer 
que foram as primeiras máquinas computacionais (VELLOSO, 2014).
A primeira máquina de calcular foi desenvolvida por Blaise 
Pascal (1623-1662) – aquele mesmo do triângulo. Ele foi físico, mate-
mático e filósofo e sua máquina fazia apenas somas e subtrações. 
Ba
bi
ch
 A
le
xa
nd
er
/S
hu
tte
rs
to
ck
A Pascaline, como foi apelidada, consistia em seis engrenagens, 
cada uma com a gravação dos algarismos de 0 a 9, sendo possí-
vel somar até três parcelas por vez considerando que o total não 
ultrapassasse 999.999. Por exemplo, uma multiplicação de 30 por 10 
era feita somando 10 vezes o número 30 (VELLOSO, 2014).
Pascal recebeu do rei da França uma patente para que pudesse ven-
der a sua máquina no comércio. Ela teve uma vida útil de aproximada-
mente 200 anos (sem muitas “atualizações”); hoje um computador é 
considerado “atual” por apenas seis meses!
Com uma Pascaline, qualquer pessoa poderia executar uma soma, 
uma subtração ou mesmo uma multiplicação entre dois valores. Essa 
máquina, como não poderia deixar de ser, mostrou-se muito útil, e ou-
tros inventores dedicaram-se ao aprimoramento de seu projeto.
Depois surgiram as máquinas registradoras, mais sofisticadas que 
aquela de Pascal, pois possuíam memória para contabilizar a entrada 
de dinheiro no caixa, um grande avanço para o momento. Já imaginou 
como elas eram úteis em um comércio? 
Entre outras coisas, elas evitavam ou, pelo menos,minimizavam 
os erros no cálculo de trocos. Também contavam com uma alavan-
ca que devia ser girada para se chegar ao resultado. Na prática, o 
acionamento dessa alavanca era o equivalente ao relógio (clock) dos 
computadores atuais (PRESSMAN; MAXIM, 2016).
https://www.shutterstock.com/pt/g/suricoma
A importância da engenharia de software 15
As máquinas registradoras tornaram as operações matemáticas mui-
to mais seguras, porém ainda tinham vários pontos fracos, como a en-
trada de valores que, além de lenta, estava sujeita a erros de digitação.
Imagine, por exemplo, o caixa de um banco, ao longo do dia, ano-
tando os valores envolvidos nas transações em uma caderneta e, no 
final do dia, ao fechar o caixa, encaminhando-os para o setor de fecha-
mento geral das operações da agência. Nesse setor, novas contas são 
executadas e, mais uma vez, a entrada de valores, além de representar 
um risco, exige muito trabalho manual. Com o fechamento da agência, 
novas anotações são produzidas e, ao final de uma semana, por exem-
plo, um malote com os fechamentos da agência é encaminhado, via 
carroça, para a sede do banco, na qual, novamente, é processado, com 
todos os riscos já conhecidos.
Percebendo problemas como esse, inventores criaram os cartões 
perfurados, que podiam ser gerados pela própria máquina, ao final de 
uma operação, ou pelo caixa e que traziam informações dos valores 
envolvidos e das operações matemáticas realizadas. O caixa não preci-
sava mais anotar em uma caderneta as operações realizadas, embora, 
por algum tempo, mesmo com o cartão, isso tenha continuado.
Ao final do dia, os cartões eram colocados em outra máquina, que 
processava todas as operações da agência naquele dia, o que gerava 
novos cartões com balancetes diários da agência. Ao final de uma se-
mana, um malote com esses balancetes, na forma de cartões, era enca-
minhado, via carroça, para a sede do banco e lá era colocado em outras 
máquinas para ser processado.
Os riscos foram minimizados, pois apenas o caixa entrava com os 
valores e, depois dele, estes eram propagados diretamente nos cartões.
Devemos observar que, até esse momento da história, as má-
quinas eram destinadas apenas à realização de contas. Embora 
fundamentais, em quase todas as situações as contas eram apenas 
elementos isolados que, com muitos outros elementos, orientavam 
a tomada de decisão.
Imagine o gerenciamento de uma carteira de investimentos em 
que, a todo instante, contas são efetuadas para permitir a escolha 
da alocação dos recursos. Porém, SE determinada condição OU de-
terminado fator tornar-se relevante E determinada escolha for feita, 
16 Engenharia de Software
todas as contas devem ser refeitas para definir a parcela dos recur-
sos a serem alocados. 
Nessa situação, a análise das condições OU, E e SE depende ape-
nas de pessoas, e mais uma vez as máquinas podem nos ajudar! Foi 
para resolver situações como essa que as máquinas registradoras 
evoluíram e tornaram-se programáveis, ou seja, computadores.
Foi com o desenvolvimento da máquina analítica do matemáti-
co inglês Charles Babbage (1792-1871), a máquina de Babbage, que 
os conceitos do computador moderno começaram a ser definidos 
(VELLOSO, 2014).
Ch
ar
le
s 
Ba
bb
ag
e/
W
ik
im
ed
ia
 C
om
m
on
s
O equipamento, que somente foi construído para efeitos de-
monstrativos, possuía todas as funcionalidades do computador mo-
derno, como:
 • inserção de dados com o uso dos cartões perfurados;
 • unidade de memória para que os números pudessem ser arma-
zenados e reutilizados quando necessário;
 • desenvolvimento sequencial de instruções ao hardware, proce-
dimento que atualmente conhecemos como sistema operacional.
Máquina analítica de Charles Babbage.
A importância da engenharia de software 17
Tudo isso foi descrito originalmente em 1837, mais de um século 
antes que qualquer outro equipamento do gênero tivesse sido cons-
truído com sucesso.
Finalmente chegou a eletricidade! Primeiro, ela foi introduzida nos 
computadores completamente mecânicos, aqueles com base em engre-
nagens, na forma de motores que automatizaram a alavanca de relógio.
O Z1 foi desenvolvido em 1938, na Alemanha, e foi o primeiro com-
putador binário com base em componentes mecânicos acionados por 
um motor elétrico para gerar o sinal de clock, operando com números 
em ponto flutuante e um bit de sinal. 
O programa era lido de uma fita perfurada, os dados eram introduzi-
dos por meio de um teclado numérico e os resultados eram apresentados 
por lâmpadas elétricas que ficavam acesas ou apagadas, representando 
0 e 1. Esse feito notável foi desenvolvido por Konrad Zuse (1910-1995).
Em 1939, o Z2 substituiu a unidade aritmética mecânica do Z1 
por relês eletromecânicos. O Z3, feito em 1941, possuía uma me-
mória que utilizava cerca de 1.400 relês (podendo armazenar até 
64 números), sendo 1.200 relês utilizados nas unidades de controle 
e aritmética. Somente em 1950 o Z4 foi concluído e a memória me-
cânica voltou a ser utilizada, por ser mais compacta que a memória 
eletromecânica (VELLOSO, 2014).
Em 1936, o matemático inglês Alan Turing (1912-1954) – sim, o Turing 
do filme O jogo da imitação – desenvolveu uma teoria conhecida como 
máquina universal ou máquina de Turing, que, de maneira abstrata, mo-
delava qualquer computador digital (PRESSMAN; MAXIM, 2016).
Essa teoria serviu como premissa para o desenvolvimento posterior 
da máquina capaz de quebrar os dados criptografados pela máquina 
alemã Enigma durante a Segunda Guerra Mundial.
Mais à frente, em 1943, foi desenvolvido pela Universidade da 
Pensilvânia o conhecido Eniac (electronic numerical integrator and 
computer), que tinha capacidade de 5.000 somas por segundo, um 
marco para a sua época, pois utilizava aritmética decimal. Contava 
com uma memória de 20 acumuladores com até 10 dígitos, cada um 
utilizando 10 bits para o seu armazenamento. 
18 Engenharia de Software
Eniac
Avanços científicos na área dos semicondutores e todos aqueles 
problemas dos computadores valvulados levaram ao surgimento 
dos computadores transistorizados, os quais utilizavam transis-
tores no lugar das válvulas. Isso marcou a segunda geração dos 
computadores.
Como não deveria deixar de ser, os transistores também eram 
utilizados como válvulas, cujo entendimento, em nível superficial, 
era mais fácil do que daqueles construídos com válvulas. 
Um transistor possui apenas e exatamente três pinos: a base, o 
coletor e o emissor. Quando a base não é acionada por um sinal, ou 
seja, aplicamos o nível lógico 0 (0 V), não há passagem de corrente 
do coletor para o emissor e a chave coletor-emissor está aberta. 
Quando a base é estimulada por um sinal de nível lógico 1 (5 V), 
temos a passagem de corrente e a chave está fechada.
A importância da engenharia de software 19
Os computadores dessa geração eram muito menores que os 
valvulados, não exigiam preaquecimento, consumiam menos ener-
gia, esquentavam menos, duravam mais e eram mais rápidos e 
mais confiáveis.
Foi na terceira geração de computadores que os circuitos in-
tegrados, feitos de silício, começaram a ser utilizados. Os circui-
tos integrados ficaram conhecidos como chips e eram construídos 
integrando-se muitos transistores e outros componentes. Essa 
técnica ficou conhecida como LSI (large scale integration ou inte-
gração em larga escala).
Isso possibilitou a construção de computadores menores, pois 
um único chip podia substituir várias placas; mais baratos, pois 
além do argumento anterior, os chips eram feitos em escala; e mais 
rápidos, pois dentro de um chip os componentes ficavam mais pró-
ximos e protegidos e os sinais elétricos propagam-se mais rapida-
mente entre dois componentes e ficavam mais estáveis. 
A primeira geração de circuitos integrados apenas mostrou o 
caminho. Como os chips eram novidade, as máquinas, mesmo as 
mais simples, ainda eram bastante caras, e os desenvolvedores 
não entendiam para que serviria um computador de uso pessoal e 
como essamáquina deveria parecer para ser desejada em larga es-
cala pelas pessoas. Além disso, não existiam empresas de software 
destinadas à sua produção para uso pessoal, como editores de tex-
to, jogos, agendas etc. Contudo, a quarta geração mudou isso.
Melhorias nas técnicas de integração afetaram não somente os 
processadores, mas todos os componentes presentes em um com-
putador, principalmente memórias. Desse modo, nessa época, as 
memórias dinâmicas também deram um salto em sua capacidade: 
64 kbits em 1981, 256 kbits em 1984, 1 mbit em 1984 e 4 mbits e 16 
mbits em 1987 (VELLOSO, 2014).
Um exemplo dessa geração foi o Apple I, que teve uma vida mui-
to curta, tendo sido apresentado em 1976 e substituído em 1977 
pelo Apple II.
Uma	visão	mais	lúdica	e	
profunda	dessa	geração	
de computadores e o 
surgimento	da	Microsoft	
e da Apple – empresas 
ícones	do	segmento	de	
computadores	pessoais	
–	podem	ser	vistos	pela	
ótica	do	filme	Piratas 
do Vale do Silício.	Vale	a	
pena	conferir.
Direção: Martyn Burke. EUA: 
TNT, 1999.
Filme
20 Engenharia de Software
Placa do circuito 
integrado do 
Apple I
Ac
hi
m
 B
aq
ué
/W
ik
im
ed
ia
 C
om
m
on
s
O computador apresentado pela Apple tinha como grande dife-
rencial a presença de um monitor, o que fez toda a diferença, pois 
o usuário podia editar textos, programas de gerenciamento de es-
toques e clientes, entre outras funções. Essa máquina, sim, tinha 
utilidade para muitas pessoas.
Rama & Musée Bolo/Wikimedia Commons
Percebendo o rápido crescimento da Apple com o Apple II, a IBM – 
na época a maior empresa do setor de computadores – resolveu en-
trar no segmento de computadores de uso pessoal e criou o padrão 
IBM PC, apresentado em 1981.
Apple II
https://commons.wikimedia.org/wiki/User:Rama
A importância da engenharia de software 21
IBM 5150
Bo
ffy
 b
/W
ik
im
ed
ia
 C
om
m
on
s
Para competir com a Apple, a IBM adotou a estratégia de permitir 
que outros fabricantes usassem seu padrão, fazendo com que rapida-
mente esses computadores se tornassem padrão de mercado. Além 
disso, o desenvolvimento de software e hardware para essas máquinas 
era livre de qualquer restrição, o que barateou e diversificou a oferta.
Porém, a IBM ainda usava no sistema operacional uma interfa-
ce com base em linha de comando e tinha poucos recursos de áu-
dio, um monitor de fósforo e um processador inferior. Mesmo assim, 
a empresa ganhou o mercado! Devido ao seu preço muito menor (o 
do Macintosh era exorbitante) e à sua maior penetração, o padrão 
IBM PC-AT consagrou-se mundialmente.
Enquanto isso, a Apple amargou prejuízos com o Macintosh, 
tornando-o restrito às pessoas e às empresas que se disponibilizassem 
a pagar pelo seu alto preço – quanto às pessoas, pelos motivos que já 
conhecemos, e quanto às empresas, pelos seus fantásticos atributos 
quando o assunto é imagem, é aqui que a Apple ganha a fama de ter os 
computadores preferidos de estúdios de publicidade.
Novamente, como aconteceu na quarta geração dos computado-
res, a quinta geração foi marcada por um aprimoramento nas técnicas 
de integração, fazendo com que os processadores se tornassem mais 
complexos, rápidos e baratos, porém o dispositivo chaveador conti-
nuou o mesmo, o transistor.
Como percebemos, o computador pode ser entendido como algo sem 
um inventor definido. Ele é um constante aprimoramento de ideias ante-
riores proporcionado pelo avanço científico e pelas técnicas de fabricação, 
porém que mantém, desde sua origem, a presença de uma ideia funda-
22 Engenharia de Software
mental, aquela que faz uso de chaves eletrônicas organizadas logicamen-
te, de modo a permitir a solução de problemas lógicos e aritméticos.
1.3 A engenharia de software 
Vídeo
Diante da crescente demanda por desenvolvimento de software e, 
por conseguinte, do surgimento de novos softwares e hardwares, as 
indústrias de softwares precisam engajar-se nessa onda de competi-
tividade, melhorando de maneira eficaz sua produtividade para poder 
enfrentar adequadamente essa realidade em constante evolução.
Uma particularidade inerente aos sistemas de software é a dificul-
dade de seu desenvolvimento, que evolui à medida que surgem novas 
tecnologias e cresce o tamanho do sistema.
Durante as fases de desenvolvimento do software, ao combinar 
os métodos, as melhores ferramentas para automatizar isso, as técni-
cas para a garantia da qualidade do software e os procedimentos de 
controle e gestão, é possível aplicar as boas práticas sugeridas pela 
engenharia de software.
A engenharia representa uma metodologia unida ao esforço para 
empreender resultados, os quais são provenientes de trabalhos foca-
dos em diversas áreas, nas quais há um amplo conhecimento a fim de 
propor soluções às necessidades (SOMMERVILLE, 2011).
No desenvolvimento de software, em geral, encontramos os seguin-
tes tipos de problema:
 • Os recursos destinados aos projetos tornam-se insuficientes.
 • Os custos de serviços, produtos e mão de obra são altos.
 • As soluções propostas não agradam às partes interessadas.
 • Os custos dos softwares são maiores que o custo do hardware.
 • O custo de manter um software às vezes é maior do que o desen-
volvimento de um novo.
Consequentemente, de acordo com Hirama (2011), a engenharia de 
software foca a missão de executar os desafios de:
 • reduzir o custo;
 • seguir o cronograma de acordo com as expectativas;
 • incrementar a qualidade nos softwares;
A importância da engenharia de software 23
 • documentar de modo que qualquer parte interessada possa en-
tender (todos os detalhes devem ser escritos);
 • adaptar as alterações sugeridas e/ou necessárias no tempo e no 
custo adequados;
 • atender às necessidades do cliente;
 • dar suporte ao desenvolvimento de softwares de acordo com as 
mudanças tecnológicas.
A concepção e criação de um software é uma empreitada de extre-
ma complexidade, sendo essencial o conhecimento de todas as etapas 
que compõem essa missão. No desenvolvimento de um software é im-
portante que o roteiro da engenharia de software seja seguido elimi-
nando o desperdício de tempo e o custo e maximizando os resultados 
benéficos com qualidade.
Conforme Pressman e Maxim (2016), todo software deve ser desen-
volvido com base em um modelo de procedimentos predeterminado, de-
nominado de ciclo de vida de desenvolvimento de software. Este possui um 
conjunto de etapas que abrange métodos, procedimentos e ferramentas 
para que o produto final atenda às especificações do usuário.
Os problemas acontecem no desenvolvimento de softwares quan-
do os procedimentos ultrapassam prazos e custos, impactando negati-
vamente a qualidade percebida pelo cliente.
A demanda por uma engenharia de software originou-se do objeti-
vo de atender às necessidades dos usuários em um ambiente corpora-
tivo altamente volátil e competitivo.
Um software pode ser considerado de qualidade quando atinge 
ou supera as expectativas dos usuários, resolvendo os problemas cor-
porativos e alavancando os negócios. Um software de qualidade deve 
atender às seguintes áreas (TSUI; KARAM, 2013): 
 • Operacional: refere-se à funcionalidade em operações, como 
usabilidade, eficiência, correção de problemas, funcionalidade, 
proteção, confiabilidade e segurança.
 • Transição: significa a portabilidade entre as plataformas que o 
aplicativo precisa apresentar, ou seja, reutilização e adaptação 
são de extrema importância para um aplicativo de qualidade.
 • Manutenção: estabelece uma qualidade percebida no que se 
refere ao seu funcionamento em um ambiente de constantes 
24 Engenharia de Software
mudanças. Trata da modularidade, facilidade de manutenção, 
flexibilidade, adaptação e escalabilidade. 
O ciclo de vida de desenvolvimento é uma série de etapas na enge-
nharia de software para a elaboração do aplicativo proposto. Trata-se 
de uma sequência de procedimentos dentro do âmbito da engenharia 
de software, que possui as seguintes etapas (PRESSMAN; MAXIM, 2016):
1
Coleta de 
requisitos2
Análise	de	 
sistema
3
Codificação
4
Teste
5
Implantação
A engenharia de software tem seu início na primeira fase quando 
se observa uma solicitação do usuário para a solução de determina-
do problema. 
O requerimento é submetido a uma organização prestadora de ser-
viços e o próximo passo é feito pelos desenvolvedores, que fazem a 
diferenciação entre requisitos do usuário, do sistema e funcionais. 
O requisito é coletado por meio de entrevistas com um usuário, 
referência a um banco de dados, estudo do sistema existente etc. 
Após a coleta, a equipe analisa se o software pode ser feito para 
atender a todos os requisitos. 
A importância da engenharia de software 25
O desenvolvedor, então, decide um roteiro de seu plano, que in-
clui o estabelecimento das limitações e abrangências do software. De 
acordo com o requisito e a análise, é feito um projeto de software. A 
implementação do design de software começa com a escrita do código 
do programa em uma linguagem de programação adequada.
1.4 A importância do design de software 
Vídeo
O design de software é o processo de transformar os requisitos do 
usuário de alguma forma adequada, o que ajuda o programador na 
codificação e implementação do software. 
Durante a fase de design do software, o documento de design é pro-
duzido com base nos requisitos do cliente, portanto o objetivo dessa 
fase é transformar o documento de levantamento de requisitos no do-
cumento de design. 
Os seguintes artefatos são projetados, desenvolvidos e documenta-
dos durante a fase de design (SOMMERVILLE, 2011): 
 • Módulos diferentes necessários.
 • Controle das relações entre módulos.
 • Interface entre diferentes módulos.
 • Estrutura de dados entre diferentes módulos.
 • Algoritmos necessários para implementação entre módulos 
individuais.
Alguns objetivos são perseguidos no processo de elaboração de 
um bom design de software, tais como: 
 • Correção: ser correto, ou seja, implementar corretamente todas 
as funcionalidades do sistema.
 • Eficiência: abordar os problemas de otimização de recursos, 
tempo e custo.
 • Compreensibilidade: ser facilmente compreensível, modular e 
com todos os módulos dispostos em camadas.
 • Completude: ter todos os componentes, como estruturas de 
dados, módulos, interfaces externas etc.
 • Capacidade de manutenção: ser facilmente passível de altera-
ção sempre que uma solicitação for feita pelo cliente.
26 Engenharia de Software
O conceito de design de software significa simplesmente a ideia ou 
o princípio por trás do design. Ele descreve como deve ser planejada a 
resolução de problemas relacionados ao projeto do software, ou seja, a 
lógica ou o raciocínio que norteará o seu desenvolvimento.
O design de software permite que o engenheiro crie o modelo do 
sistema, ou o software ou o produto a ser desenvolvido ou construído. 
O conceito de design de software fornece uma estrutura ou modelo de 
suporte essencial para o desenvolvimento do software certo.
Para Engholm (2010), os seguintes pontos devem ser considerados 
no design: 
 • Abstração: ocultar dados irrelevantes, ou seja, simplesmente 
ocultar os detalhes para reduzir a complexidade e aumentar a 
eficiência ou a qualidade. Diferentes níveis de abstração são ne-
cessários e devem ser aplicados em cada etapa do processo de 
design para que qualquer erro presente possa ser removido, de 
modo a aumentar a eficiência da solução de software e refiná-la.
A solução deve ser descrita de maneira ampla, cobrindo uma 
gama de coisas diferentes em um nível superior de abstração, e 
uma descrição mais detalhada de solução de software deve ser 
fornecida no nível inferior de abstração.
 • Modularidade: subdividir o sistema. Significa simplesmente divi-
dir o sistema ou o projeto em partes menores para reduzir a sua 
complexidade. Da mesma forma, significa subdividir um sistema 
em partes menores para que elas possam ser criadas indepen-
dentemente e, em seguida, usadas em sistemas diferentes para 
executar funções distintas.
A modularidade no design tornou-se uma tendência, sendo im-
portante. Se o sistema contiver um menor número de compo-
nentes, significa que é complexo, exigindo muito esforço (custo). 
Porém, se formos capazes de dividi-lo em componentes, então, 
o custo será pequeno.
 • Arquitetura: trata-se de uma técnica para projetar a estrutura nor-
teadora de algo. A arquitetura no projeto de software é um concei-
to que envolve vários elementos e os dados da estrutura. Esses 
componentes interagem entre si e usam os dados na arquitetura.
A importância da engenharia de software 27
 • Refinamento: remove as impurezas, ou seja, refina algo para re-
mover quaisquer impurezas presentes e aumentar a qualidade. 
O conceito de refinamento de projeto de software é, na verdade, 
um processo de desenvolver ou apresentar o software ou o siste-
ma de modo detalhado. O refinamento é muito necessário para 
descobrir qualquer erro, se houver, e reduzi-lo.
 • Padrão: reaproveitamento de códigos. É uma forma ou um dese-
nho repetido várias vezes para formar um padrão. Este refere-se 
à repetição de uma solução para um problema recorrente e co-
mum dentro de certo contexto.
 • Ocultar informações: dados desnecessários não precisam 
aparecer, isto é, significa ocultar as informações para que não 
possam ser acessadas por uma parte indesejada. No projeto de 
software, a ocultação de informações é obtida projetando-se os 
módulos de modo que as informações coletadas ou contidas 
neles sejam ocultadas e não possam ser acessadas por quais-
quer outros módulos.
 • Refatorar: é reconstruir algo de tal forma que não afete o com-
portamento ou quaisquer outras características. Significa re-
construir o design para reduzir a complexidade sem afetar o 
comportamento ou as funções. 
O design de software possui três diferentes níveis que devem ser 
observados nos projetos de desenvolvimento. São eles: 
1. Projeto arquitetônico: a arquitetura de um sistema pode 
ser vista como a estrutura geral do sistema e a maneira como 
esta fornece integridade conceitual. O projeto arquitetônico 
identifica o software como um sistema com muitos componentes 
interagindo entre si. Nesse nível, os designers têm a ideia do 
domínio da solução proposta. 
2. Projeto preliminar ou de alto nível: aqui o problema é 
decomposto em um conjunto de módulos e a relação de controle 
entre os vários módulos e as interfaces entre os vários módulos 
são identificadas. O resultado desse estágio é chamado de 
arquitetura do programa. 
As técnicas de representação de design usadas nesse estágio são 
gráficas de estruturas de softwares que veremos mais à frente. 
Com	oito	edições	e	mais	de	
30	anos	no	topo	dos	livros	
mais	vendidos	e	recomen-
dados	da	engenharia	de	
software,	a	obra	Engenharia 
de software: uma aborda-
gem profissional	precisa	
estar	na	cabeceira	de	
todos os desenvolvedores, 
engenheiros,	programa-
dores	e	profissionais	de	
tecnologia.
O	livro	traz	um	leque	ri-
quíssimo	de	procedimen-
to,	roteiros,	cuidados	e	
atalhos	da	engenharia	de	
software.	Também	aborda	
aspectos	essenciais,	como	
o	trabalho	com	os	usuá-
rios	para	determinar	suas	
necessidades	de	software;	
o	roteiro	para	desenho	
de	diagramas	e	modelos	
que	ajudem	os	desenvol-
vedores	a	criar	o	código	
apropriado	para	o	sistema	
ou	aplicativo;	indicações	
de como documentar o 
sistema	ou	aplicativo	em	
detalhes	para	ajudar	os	
responsáveis	pela	manu-
tenção	futura;	os	proce-
dimentos	para	manter	o	
sistema	ou	aplicativo	com	
atualizações	e	correções	
conforme	necessário	etc.
Enfim,	por	muitos	é	
considerado	a	bíblia	da	
engenharia	de	softwares.
PRESSMAN, R. S. 8. ed. Porto Alegre: 
AMGH, 2016.
Livro
28 Engenharia de Software
3. Projeto detalhado: uma vez que o projeto de alto nível esteja 
completo, o projeto detalhado é realizado. Aqui, cada módulo é 
examinado cuidadosamente para projetar a estrutura de dados e 
algoritmos. O resultado do estágio é documentado na forma de 
um documento de especificação do módulo.CONCLUSÃO
Neste	capítulo	entendemos	a	definição	de	software	e	sistemas	compu-
tacionais	e	vimos	a	evolução	do	hardware	e	software	ao	longo	dos	anos,	
bem	como	os	principais	tipos	de	software.
Compreendemos	a	origem	da	engenharia	de	software	e	a	importân-
cia	do	design	de	softwares	atualmente	no	ecossistema	do	desenvolvi-
mento	de	aplicações.
Este	capítulo	foi	uma	ótima	introdução	aos	engenheiros	de	softwares	
que	desejam	ser	competentes	em	suas	 funções,	solucionando	proble-
mas	e	combinando	habilidades	de	pensamento	abstrato	com	uma	men-
talidade	prática.
A	partir	daqui,	estaremos	aptos	a	nos	aprofundar	em	todos	os	proce-
dimentos	da	engenharia	de	software,	que	busca	garantir	padronização,	
aumentar	qualidade	e	diminuir	prejuízos	nos	projetos	de	softwares.
ATIVIDADES
Atividade 1
Você	assumiu	a	missão	de	um	museu	altamente	relevante	nos	
Estados	Unidos	de	criar	uma	experiência	histórica	aos	visitantes:	
elaborar	uma	linha	do	tempo	com	os	principais	avanços	tecnoló-
gicos	ao	longo	da	história.	
Para	tanto,	utilize	os	marcos	trazidos	neste	capítulo,	bem	como	
outras	pesquisas,	para	criar	o	que	conhecemos	como	timeline 
da	tecnologia.	Use	a	criatividade	para	surpreender	a	todos	com	
gráficos,	imagens	e	até	animação	gráfica.	
Atividade 2
Escolha	um	aplicativo	que	você	utiliza	no	seu	dia	a	dia	e	de-
senvolva	um	documento	com	os	itens	do	design	de	software	
tratados	neste	capítulo.	Fale	como	a	abstração,	a	modularidade,	
a	arquitetura,	o	refinamento,	o	padrão,	a	ocultação	de	informa-
ções	e	a	refatoração	podem	ser	encontrados	no	aplicativo.	
A importância da engenharia de software 29
REFERÊNCIAS
ENGHOLM JR., H. Engenharia de software na prática. São Paulo: Novatec, 2010.
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. Rio de 
Janeiro: Elsevier, 2011.
PFLEEGER, S. L. Engenharia de software: teoria e prática. São Paulo: Pearson Prentice 
Hall, 2007.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. 
Porto Alegre: AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Education, 2011.
TSUI, F.; KARAM, O. Fundamentos de engenharia de software. São Paulo: LTC, 2013.
VELLOSO, F. de. C. Informática: conceitos básicos. 9. ed. Rio de Janeiro: Elsevier, 2014.
30 Engenharia de Software
2
Ciclo de vida do software
Com o estudo deste capítulo, você será capaz de:
• entender, analisar e implementar o ciclo de vida completo de 
um software;
• compreender análise, projeto, implementação, testes, implan-
tação e manutenção de sistemas;
• reconhecer a importância do levantamento de requisitos efi-
ciente para o sucesso da engenharia de software.
Objetivos de aprendizagem
Neste capítulo exploraremos o conhecido ciclo de vida de desen-
volvimento de sistemas que define as principais etapas do desenvolvi-
mento de software dentro da engenharia de software.
Existem muitas abordagens diferentes para essa atividade, e a 
maioria das equipes de desenvolvimento possuem uma metodologia 
iterativa, na qual os estágios são combinados e revisitados ao longo do 
projeto. O termo a que chamamos de ciclo de vida é usado para ilustrar 
que, eventualmente, mudanças na tecnologia ou nos requisitos de ne-
gócios tornarão um sistema obsoleto e o ciclo começará novamente – 
daí a importância de trazermos os conceitos ágeis para o nosso estudo.
O ciclo de vida de desenvolvimento de software é um processo de-
finido de desenvolvimento de softwares que, quando seguido, ajuda a 
criá-los de maneira rápida e eficiente.
Podemos comparar isso à receita que você segue para assar seu 
bolo favorito. Se o primeiro passo for combinar farinha com cacau em 
pó, você terá que seguir o processo para garantir um bolo bem assado. 
No entanto, se você misturar os ingredientes mencionados de uma vez, 
talvez não valha a pena saborear o bolo.
O mesmo se aplica para as etapas do ciclo de vida de desenvolvimen-
to de software: há um processo passo a passo definido para a criação 
Ciclo de vida do software 31
de software de qualidade. Se você perder alguma das etapas ou segui-
-las sem precisão, os esforços desse processo serão desperdiçados.
2.1 Ciclo de vida do software 
Vídeo O ciclo de vida do software (ou, em inglês, Software Development 
Life Cycle) é um processo sistemático de desenvolvimento de software 
que assegura a qualidade e as manutenções do software construído. 
O ciclo de vida na construção de softwares tem o objetivo de im-
plementar alta qualidade ao produto final, preferencialmente sur-
preendendo as expectativas do cliente. O desenvolvimento do sistema 
deve ser entregue no prazo e no custo orçados, sendo basicamente 
um plano detalhado que explora como planejar, construir e manter um 
software específico (PRESSMAN, 2016).
Cada fase do ciclo de vida do software tem seu próprio processo e 
resultados que deliberam a próxima etapa de modo cíclico com retroa-
limentação, mas sempre em parceria com os usuários para as devidas 
validações.
Apresentamos, a seguir, os motivos que impulsionam a implantação 
eficiente do ciclo de vida do desenvolvimento de softwares eficientes nas 
organizações que buscam diferenciais competitivos (PFLEEGER, 2007).
 • Fornecer subsídios para o planejamento, a codificação e a esti-
mativa de custo e tempo do projeto.
 • Entregar uma modelagem estruturada para as atividades que 
irão compor o desenvolvimento dos softwares.
 • Ser um dispositivo que propicia o acompanhamento e o monito-
ramento do projeto.
 • Dar ênfase à visibilidade de todo o planejamento estrutural do pro-
jeto para todos os envolvidos no processo de desenvolvimento.
 • Aumentar e melhorar a velocidade de desenvolvimento dos 
softwares.
 • Aprimorar as relações com o cliente.
 • Contribuir para a diminuição dos riscos relacionados ao projeto.
 • Eliminar sobrecargas no gerenciamento prático do projeto de 
software.
32 Engenharia de Software
O ciclo de vida também reduz o custo de desenvolvimento de 
software e, ao mesmo tempo, melhora a qualidade e reduz o tempo 
de produção, atingindo essas metas que aparentemente divergem, 
mas que na verdade são essenciais no desenvolvimento de softwares 
(PFLEEGER, 2007).
O ciclo segue um plano que remove as armadilhas típicas de proje-
tos de desenvolvimento de software. Esse plano começa avaliando os 
sistemas existentes, em busca de deficiências. Posteriormente, parte 
para a definição dos requisitos do novo sistema e, em seguida, ruma-se 
à criação do software por meio dos estágios de análise, planejamento, 
design, desenvolvimento, teste e implantação.
Ao prever erros com alto custo, como deixar de pedir feedback ao 
usuário final ou cliente, o ciclo de desenvolvimento eficaz pode eliminar 
retrabalho redundante e correções posteriores.
É importante, ainda, saber que há um grande foco na fase de tes-
te – com uma metodologia repetitiva, é possível garantir a qualidade 
do código a cada ciclo. Muitas organizações tendem a investir poucos 
esforços em testes, o que é um erro, pois um foco mais eficiente em 
testes pode economizar muito retrabalho, tempo e dinheiro.
O ciclo de vida tradicional e mais utilizado nas organizações é apre-
sentado na figura a seguir (IAN, 2011).
Sistema 
proposto
Figura 1
Ciclo de vida de software
Implementação e 
testes
Análise e projeto
Levantamento de 
requisitos
Implantação e 
manutenção
Fonte: Elaborada pelo autor com base em Ian, 2011.
Ciclo de vida do software 33
Em seguida, vamos explorar cada uma das etapas: levantamento 
de requisitos; análise e projeto; implementação e testes; implantação 
e manutenção.
2.2 Levantamento de requisitos 
Vídeo O levantamento de requisito é estágio inicial e essencial para um 
bem-sucedido processo de desenvolvimento de software. Esse proces-
so deve ser liderado por profissionais experientes e conhecedores do 
negócio. É a fase que dará uma visão mais clara e ampla sobre o escopo 
de todo o projeto e sobre as questões, oportunidades e diretrizes pre-
vistas que o desencadearam.
Aetapa de coleta de requisitos necessita de uma equipe capacitada 
em obter condições, dados, informações o mais detalhadas e confiá-
veis possível, contribuindo para no cumprimento do cronograma esta-
belecido (IAN, 2011).
Esta etapa se refere especificamente à prática de definir requisitos 
de software, mas na verdade todo projeto tem requisitos, desde uma 
nova plataforma de suporte ao cliente até uma cozinha remodelada. 
Em sua essência, trata-se do processo de compreensão para que o de-
senvolvedor saiba o que ele deve estar construindo e por que o está 
fazendo.
O processo geralmente envolve um conjunto de atividades, incluin-
do (SOMMERVILLE, 2011):
 • Levantamento de requisitos: obter os requisitos de negócios 
das partes interessadas e que são relevantes para compreender 
as necessidades do usuário.
 • Documentação de requisitos: codificação dessas informações 
em formato legível aos usuários para que eles possam confirmar 
o entendimento das necessidades.
 • Entendimento dos requisitos: etapa para que todos tenham 
certeza do entendimento dos requisitos que formarão o software.
É sempre fundamental lembrar que tudo depende do usuário! Ele 
é o personagem mais importante nesse processo. Descubra como os 
usuários desempenham suas tarefas e como desejam realizá-las de-
pois do software.
34 Engenharia de Software
1. O que os usuários precisam fazer?
2. Quais problemas precisam ser sanados?
3. Como os usuários querem resolver os problemas?
4. Quais tipos de recursos os usuários terão disponíveis?
5. Com que eficiência podemos fazer isso acontecer? 
6. Que tipo de flexibilidade pode ser necessária?
Essas são algumas perguntas que precisam ser respondidas nessa 
etapa.
A coleta de requisitos bem-sucedida é uma arte em entrevistar pes-
soas e conseguir informações. A seguir apresentamos algumas dicas 
que podem ajudar.
Estabeleça metas e objetivos do projeto desde o início
Isso pode parecer redundante: é claro que sabemos por que esta-
mos fazendo este projeto...Não é? 
Mesmo tendo-se a impressão de saber tudo, anotar e pedir aos 
stakeholders que assinem é o mais indicado.
Sem metas e objetivos claramente definidos, faltará uma estrutura 
para orientar as futuras tomadas de decisões. 
Documentar todas as atividades de obtenção de requisitos
Quando está no meio de entrevistas com as partes interessadas e 
na análise de documentação, muitas vezes o desenvolvedor pode sen-
tir que tem um grande domínio sobre as coisas. Mas, então, uma se-
mana se passa e alguns detalhes começam a ficar um pouco confusos, 
e o desenvolvedor percebe que não tem uma compreensão completa 
sobre os requisitos do seu negócio.
Parece óbvio, mas certificar-se de estar fazendo anotações detalha-
das durante as entrevistas com as partes interessadas é um passo po-
deroso para uma coleta de requisitos bem-sucedida. 
Seja transparente com a documentação de requisitos
Claro que você entende os requisitos e seus stakeholders também. 
Porém, todas as demais partes envolvidas entendem sua compreensão 
sobre os requisitos?
Após cada reunião, analise suas anotações, refine-as e, em segui-
da, compartilhe-as com a equipe do projeto, incluindo todas as partes 
interessadas. 
Ciclo de vida do software 35
Essa transparência não apenas ajuda a garantir que todos estejam 
na mesma página, mas também promove um senso de aceitação do 
projeto em todo o seu planejamento, começando com os requisitos do 
negócio. 
Fale com as partes interessadas e usuários certos
Um projeto geralmente pode ter partes interessadas “ocultas”. Faça 
perguntas de sondagem em suas reuniões iniciais para tentar desco-
brir quem são os usuários reais.
Frequentemente, essas pessoas não serão os principais tomadores 
de decisão, mas sua adesão é essencial para um projeto bem-sucedido. 
Usuários insatisfeitos que são forçados a usar um sistema que foi pro-
jetado sem as suas contribuições são um ingrediente-chave para um 
projeto fracassado.
Não faça suposições sobre os requisitos
Não presuma que compreendeu tudo, mesmo que tudo pareça 
óbvio. Um requisito aparentemente simples como “queremos um blog” 
pode mascarar todos os tipos de suposições, requisitos etc. 
1. Quais são os campos de uma postagem de blog? 
2. Como os autores são gerenciados? 
3. E quanto à marcação? 
4. Quais são as categorias? 
5. Como as postagens são exibidas? 
6. Eles estão agregados em um arquivo? 
7. Existe um feed? 
8. Quem são os autores e qual é seu nível de proficiência técnica? 
O ponto-chave está realmente nos detalhes que o desenvolvedor 
pode conseguir se fizer as perguntas certas e não acelerar o processo 
de coleta de dados. 
Confirmar, confirmar, confirmar
Isso significa “ser transparente”? No entanto, não é totalmente a 
mesma coisa. 
É ótimo apenas compartilhar suas anotações com uma parte inte-
ressada, mas muito mais valioso é fazer uma revisão rápida junto a ela 
e obter sua aprovação oficial. 
36 Engenharia de Software
O silêncio das pessoas não é um indicador de sucesso. Obtenha a con-
firmação formal das partes interessadas para só depois seguir em frente.
Pratique a escuta ativa
Conseguir que alguém se sinta ouvido é uma das melhores coisas 
que o desenvolvedor pode fazer pelo usuário. Entretanto, isso vai além 
de apenas ouvir o que eles dizem: o desenvolvedor também precisa 
ouvir o que os usuários não dizem e como eles dizem as coisas, bem 
como tentar ler sua linguagem corporal e outros indicativos de que ain-
da existem informações para serem passadas por parte dos usuários.
Isso é chamado de escuta ativa e trata-se de um componente-chave 
para o sucesso levantamento de requisitos. Não presuma que está sem-
pre entendendo a história, preste atenção às pequenas pistas que revelam 
pontos problemáticos, desejos, objetivos não declarados e suposições.
Foco nos requisitos de negócios, não nas ferramentas
Tenha cuidado ao reunir requisitos nos quais está realmente se con-
centrando e ao ouvir as necessidades dos stakeholders em vez de se pren-
der à ferramenta que está usando. Qualquer metodologia ou software 
pode ser utilizado desde que não atrapalhe a coleta de requisitos.
Lembre-se: você pode não ter entendido tudo 
Mesmo o melhor coletor de requisitos vai perder coisas, e sabe por 
quê? Porque o desenvolvedor e seus stakeholders são seres humanos, 
e seres humanos cometem erros. Mais tarde, o desenvolvedor vai pen-
sar em coisas que se esqueceu de perguntar. O stakeholder pensará 
em coisas que se esqueceu de mencionar (SOMMERVILLE, 2011).
As coisas podem mudar, as prioridades podem mudar. A boa notí-
cia é que o planejamento com antecedência poderá proporcionar uma 
construção de software interativa e eficiente durante o ciclo de vida do 
projeto; com isso, o gerenciamento contínuo de requisitos será garantido. 
Esse tempo é essencial porque os requisitos (orientados e criados 
por humanos) simplesmente não são estáticos. Dar a si mesmo tempo 
para gerenciar ativamente os requisitos ao longo de todo o projeto pode 
ajudá-lo a interromper o aumento do escopo antes de iniciá-lo e garan-
tir que sua equipe esteja sempre se concentrando no conjunto certo de 
prioridades que correspondem aos requisitos reais (IAN, 2011).
Ciclo de vida do software 37
Obviamente, há muito mais que pode ser dito sobre a arte e a ciência 
da coleta de requisitos, mas espero que esta lista tenha fornecido algumas 
ferramentas úteis para gerenciar esse processo com sucesso. Agora que já 
se sabe como definir o que está construindo vamos seguir para a próxima 
etapa do ciclo de vida do processo de desenvolvimento de software. 
2.3 Análise e projeto 
Vídeo O estágio de análise e projeto é uma etapa do desenvolvimento em 
que precisamos identificar quais são os principais aspectos do proble-
ma que se pretende resolver com o software.
Existem quatro pontos que precisamos identificar quando analisa-
mos um problema. São eles (HIRAMA, 2011):
1. Finalidade do software: muitas vezes se consegue isso com 
um texto que detalha o motivopelo qual o software está sendo 
desenvolvido.
2. Entregas: lista do que deve ser entregue ao longo do projeto. 
Esses elementos serão entregues ao cliente ou usuário final. 
3. Limites: limites definidos aos quais o software atenderá, suas 
fronteiras entre o que deve ou não ser atendido.
4. Requisitos funcionais: especifica as entradas, os processos e as 
saídas.
Esses quatro aspectos podem ser detalhados quando definimos 
entradas, processamentos e saídas esperadas. Para ficar mais claro, 
vamos a um exemplo bastante simples.
Exemplo 1
Objetivo: o software deve ser criado para permitir que um usuário 
insira dez números. Cada número deve ser validado para garantir que 
não seja inferior a 0 e nem superior a 100.
O programa deve manter um total contínuo dos números inseridos 
e produzir o total final.
Entregas: o escopo deste exemplo seria o projeto entregue, incluin-
do os aspectos: design, programa concluído, plano de teste, resultados 
de teste e relatório de avaliação. Um curto limite de tempo também 
seria definido no projeto, provavelmente menos de 30 minutos.
38 Engenharia de Software
Requisitos funcionais:
 • entradas: dez números;
 • processos: “validar dez números” e “calcular total”;
 • saídas: total digitado até o momento;
 • limites: cada número deve ser validado para garantir que não 
seja inferior a 0 e nem superior a 100. Portanto, os limites seriam 
0 e 100.
Exemplo 2
Objetivo: os proprietários de um parque temático pediram que fos-
se desenvolvido um programa para registrar o número médio de visi-
tantes em uma semana.
Para tanto, o usuário digitará o número total de visitantes para cada 
dia da semana. O programa deve, então, gerar o número médio de 
visitantes durante a semana.
Entregas: o escopo deste exemplo seria o projeto entregue, incluin-
do os aspectos: design, programa concluído, plano de teste, resultados 
de teste e relatório de avaliação. O limite de tempo desse programa 
seria relativamente curto, possivelmente algo entre 1 e 2 horas.
Requisitos funcionais:
 • entradas: total diário de pessoas;
 • processos: calcular média diária;
 • saídas: média de pessoas;
 • limites: pode ser difícil encontrar alguns limites neste exemplo. 
Nele, estamos usando dias da semana, portanto não usaríamos 
mais do que sete dias da semana. Outro limite seria que o total 
de visitantes deve ser maior que zero, pois não pode haver visi-
tantes negativos.
Na fase de análise e projeto também é necessário, geralmente, 
delinear claramente quaisquer recursos que serão necessários, por 
exemplo:
 • hardware necessário para executar o software;
 • compatibilidade de software;
 • necessidade de uma conexão com a internet durante o uso;
 • competência de TI e do grupo de usuários para a implementação 
da solução.
Ciclo de vida do software 39
A fase de análise e projeto de software é o momento em que os ar-
quitetos e desenvolvedores elaboram especificações técnicas avança-
das de que precisam para criar o software de acordo com os requisitos. 
As partes interessadas discutirão fatores como níveis de risco, com-
posição da equipe, tecnologias aplicáveis, tempo, orçamento, limita-
ções do projeto, método e projeto arquitetônico.
Com base nas definições, desenvolve-se um documento chamado 
Documento de Especificação de Projeto que irá balizar o projeto arqui-
tetônico, os componentes, a comunicação, a representação de telas e 
os fluxos de usuário do produto. Essa etapa fornece um modelo para 
desenvolvedores e testadores e reduz as chances de falhas e atrasos 
no produto final (ENGHOLM, 2010).
Agora vamos à próxima fase!
2.4 Implementação e testes 
Vídeo A implementação ou codificação do software é o momento em que 
os desenvolvedores, de posse dos requisitos e da documentação da 
fase de análise e projeto, debruçam-se sobre a programação.
Uma linguagem é escolhida e o processo se inicia, levando em consi-
deração um padrão de programação dentro da equipe. Os padrões de 
codificação são uma série de procedimentos que podem ser definidos 
para uma linguagem de programação específica, determinando um es-
tilo de programação, os métodos e os procedimentos diferentes. 
Esses procedimentos podem ser realizados para vários aspectos do 
programa escrito nessa linguagem e podem ser considerados atributos 
essenciais do desenvolvimento de software.
Um padrão de codificação garante que todos os desenvolvedores 
que trabalham no projeto sigam certas diretrizes especificadas. O có-
digo pode ser facilmente compreendido e a consistência adequada é 
mantida (TSUI; KARAM, 2013).
A consistência tem um impacto positivo na qualidade do programa 
e deve-se mantê-la durante a codificação. Além disso, é importante cui-
dar para que as diretrizes sejam seguidas de maneira homogênea nos 
diferentes níveis do sistema e não se contradigam.
40 Engenharia de Software
A codificação deve seguir algumas premissas para que apresente 
uma fácil leitura por parte das equipes técnica e não técnica, tais como:
 • Tentar definir diferentes seções do código segmentando blocos 
de código em um parágrafo. Para tanto, é aconselhável usar 
indentação para indicar o início e o fim das estruturas de con-
trole, juntamente a uma especificação clara do local entre elas no 
qual o código está.
 • Atribuir consistência na convenção de nomenclatura das variá-
veis em todo o código. Além disso, devem ser descritos os dados 
que estão no código.
 • Nomear as funções de acordo com o que executam.
 • O código deve ser entendível mesmo depois de se retornar a ele 
após algum intervalo de tempo, sem que o programador tenha 
que olhar para cada linha do código-fonte.
 • Seguir um método específico para comentar o trabalho.
 • As funções da linguagem que são complexas ou a estrutura que é 
difícil de ser compreendida devem ser evitadas.
Com simples atitudes dos programadores, é possível evitar que os 
desenvolvedores de software gastem uma parte maior do seu tempo 
resolvendo os problemas que poderiam ter sido evitados. Implementar 
padrões de codificação ajuda a equipe a detectar os problemas anteci-
padamente ou até mesmo evitá-los completamente, o que aumenta a 
eficiência em todo o processo de software.
Após uma codificação eficiente e padronizada, parte-se para os testes. 
A implementação dos testes em software é o processo de desenvolver e 
priorizar procedimentos de teste, criando dados e, opcionalmente, prepa-
rando e escrevendo scripts de teste automatizados (TSUI; KARAM, 2013).
É de grande importância escolher os testes certos e executá-los na 
ordem certa. A importância disso cresce exponencialmente nas estra-
tégias baseadas em risco quando criamos prioridades com base na 
probabilidade de risco e problemas.
O procedimento teste é considerado uma atividade básica destinada 
a detectar e resolver problemas técnicos no código-fonte do software e 
avaliar a usabilidade geral do produto – desempenho, segurança e compa-
tibilidade. Não apenas é a parte principal da garantia de qualidade como 
também é parte integrante do processo de desenvolvimento de software.
Ciclo de vida do software 41
Um ponto importante no processo de teste é que a empresa esta-
beleça uma política de testes. Trata-se de um documento que contenha 
os princípios dos testes adotados pela empresa e os principais objeti-
vos de teste dela. Também explica como serão realizados e como uma 
empresa mede a eficácia e o sucesso dos testes (PRESSMAN, 2016).
A seguir listamos os itens essenciais de uma política de testes de 
softwares eficaz:
 • Definição do que o teste significa para a empresa.
 • Objetivos dos testes para a organização.
 • Padrões e critérios gerais para teste de software em projetos.
 • Lista de ferramentas para apoiar o processo de teste.
 • Métodos e métricas para avaliar a eficiência dos testes.
 • Maneiras de como melhorar os processos de teste.
Apoiando a política de testes se faz necessário um plano de gestão 
de qualidade, documento que define um nível aceitável de qualidade 
do produtoe descreve como o projeto alcançará esse nível. 
Não se trata de um documento obrigatório, mas ele ajudará a agen-
dar todas as tarefas necessárias para garantir que o projeto atenda às 
necessidades e expectativas do cliente. 
O principal objetivo desse plano é apoiar os gerentes de projeto e 
ajudar a organizar o processo, definindo funções, responsabilidades e 
padrões de qualidade a serem alcançados. Consequentemente, deve 
incluir os requisitos de qualidade do software e descrever como eles 
devem ser avaliados (PRESSMAN, 2016).
A seguir temos alguns tópicos essenciais para o desenvolvimento 
do plano: 
 • Objetivos de qualidade perseguida.
 • Principais entregas do projeto e processos a serem revisados 
para um nível de qualidade satisfatório.
 • Padrões de qualidade adotados.
 • Atividades de controle e garantia de qualidade.
 • Funções e responsabilidades de qualidade.
 • Ferramentas de qualidade.
 • Plano para relatar problemas de controle e garantia de qualidade.
42 Engenharia de Software
Depois do plano de qualidade, o gestor deve se debruçar sobre o 
desenvolvimento da estratégia de teste, documento de nível de pro-
duto mais específico que deriva dos requisitos de sistema, levantados 
junto aos usuários.
A estratégia de teste deve ser desenvolvida para definir as abor-
dagens de teste de software usadas para atingir os objetivos de teste. 
Uma estratégia de teste é orientada pelos requisitos de negócios do 
projeto, razão pela qual ela se confunde com as responsabilidades de 
um gerente de projeto.
Os principais componentes de uma estratégia de teste são:
 • escopo do teste;
 • objetivos de teste;
 • limitações de orçamento;
 • comunicação e relatório de status;
 • padrões industriais;
 • teste de medição e métricas;
 • relatórios e rastreamento de defeitos;
 • gerenciamento de configurações;
 • prazos;
 • cronograma de execução de teste;
 • identificação de risco.
Em um projeto pequeno, a estratégia de teste faz parte de um plano 
de teste. Porém, para um projeto maior, o gestor de projetos precisa 
criar uma estratégia de teste como um documento estático separado e 
a partir do qual cada plano de teste pode ser desenvolvido.
Um bom documento de estratégia de teste responde às seguintes 
perguntas:
 • Qual é o produto?
 • Qual(is) parte(s) deve(m) ser testada(s)?
 • Como eles devem ser testados?
 • Quando o teste deve começar?
 • Quais são os critérios de início/fim?
Por fim, é recomendado o desenvolvimento do plano de teste, docu-
mento que descreve o que testar, quando testar, como testar e quem 
Ciclo de vida do software 43
fará os testes. Ele também descreve o escopo e as atividades do teste. O 
plano de teste inclui os objetivos dos testes a serem executados e ajuda 
a controlar os riscos. É uma boa prática ter um plano de teste escrito 
por uma pessoa experiente, como um líder ou gerente de qualidade.
Um bom plano de teste deve incluir a programação de todas as ativi-
dades necessárias para controlar o tempo de teste de sua equipe. Deve 
também definir as funções de cada membro da equipe para que todos 
saibam o que é necessário. 
Não existe uma maneira universal de se criar um plano de teste por-
que ele depende dos processos, dos padrões e das ferramentas de ge-
renciamento de teste implementados na empresa. Mas aqui seguem as 
principais informações que um plano de testes de softwares deve conter. 
 • Introdução.
 • Itens de teste (o produto e suas versões).
 • Problemas de risco de software.
 • Recursos a serem testados.
 • Recursos a não serem testados.
 • Abordagem (estratégia).
 • Critérios de aprovação ou reprovação do item.
 • Critérios de suspensão.
 • Produtos (documento de plano de teste, casos de teste, ferra-
mentas, registros de erros, relatórios de problemas etc.).
 • Ambiente de teste (hardware, software, ferramentas).
 • Cronograma.
 • Necessidades de pessoal e treinamento.
 • Responsabilidades.
 • Riscos.
 • Aprovações.
Todos esses itens são necessários para que se possa estabelecer 
um plano de testes que seja objetivo, evitar repetições e desperdícios 
e, principalmente, aprovar o software de acordo com as necessidades 
dos usuários e sem anomalias operacionais 
Por último, é importante que o plano de testes seja compartilhado 
com todas as partes interessadas, pois ele fornecerá informações so-
bre os processos de teste e, consequentemente, de qualidade.
2.5 Implantação e manutenção 
Vídeo Após meses ou anos de trabalho, você finalmente desenvolveu o 
software ou parte dele pode ser implementado. Que alívio!
Infelizmente, no entanto, normalmente não temos a “casa livre”, ou 
seja, existem softwares antigos rodando, usuários acostumados com o 
padrão antigo – enfim, uma série de desafios a serem superados.
A implementação de qualquer tipo de nova tecnologia no local de 
trabalho, incluindo esse novo software, pode ser uma mudança que 
ocorre com muito estresse.
As pessoas geralmente resistem a qualquer mudança que afete seu 
status quo, ou seja, o estado atual das coisas. E pedir para que as pes-
soas aprendam uma nova ferramenta certamente parecerá uma inter-
rupção indesejável.
O importante é passar a confiança de que a implementação trará 
benefícios para a empresa, para todos individualmente, bem como de 
que ninguém será desligado, se for possível afirmar isso.
Todos os impactados precisam estar de “braços abertos” para o 
novo software!
Apresentamos cinco dicas essenciais para essa missão 
(SOMMERVILLE, 2011):
1. Encontre seus campeões
Se você puder aproveitar o entusiasmo dos colaboradores empol-
gados com o novo para dar impulso em torno desse novo software, 
essa empolgação pode ajudar a convencer o restante dos funcionários 
a utilizá-lo.
Encontre pessoas que se sintam naturalmente à vontade com 
os conceitos do novo software e incentive-as a defendê-
-lo. Você pode considerar as pessoas da equipe pi-
loto que ajudaram a avaliar a ferramenta ou as 
pessoas que usarão o software com maior 
frequência. Ver o entusiasmo 
desses campeões ajudará a con-
verter as pessoas mais céticas 
ou hesitantes.
Pu
re
So
lu
tio
n/
Sh
ut
te
rs
to
ck
4444 Engenharia de softwareEngenharia de software
2. Crie um entendimento compartilhado
Se os funcionários não encontrarem um motivo convincente para 
usar o novo software, é possível que a empresa receba taxas de adoção 
baixas. Portanto, ajude os colaboradores campeões a entender exata-
mente o que é a ferramenta, o que ela faz e por que foi desenvolvida. 
Envolva as pessoas desde o início do processo de implementação e in-
centive as perguntas apresentando transparência nas respostas.
3. Realizar eventos de treinamento
Os eventos de treinamento podem ser uma forma eficaz de treinar 
os funcionários em um novo software. Use esses eventos para estimu-
lar o diálogo e responder a perguntas, reforçar os benefícios da ferra-
menta e demonstrar sua aplicação prática diária no fluxo de trabalho 
da equipe.
É importante encontrar maneiras criativas de incorporar o novo 
software à rotina off-line ou à rotina com o software antigo com a 
maior frequência possível.
4. Mova conteúdos importantes para o novo software
Uma maneira de aumentar a adoção é tornar as informações im-
portantes de que os funcionários precisam acessíveis apenas por meio 
da nova ferramenta. Na verdade, definir um prazo rígido de migração 
para o novo software pode ser a única maneira de fazer com que os 
retardatários se convertam.
Mas tome cuidado! Essa é uma etapa ousada que corre o risco de 
frustrar os funcionários, especialmente se implementada muito cedo. 
Para ajudar nesse processo, comunique e enfatize as razões para a 
adoção do novo software de maneira eficaz, ressaltando como a nova 
ferramenta beneficiará a todos.
Pu
re
So
lu
tio
n/
Sh
ut
te
rs
to
ck
Ciclo de vida do softwareCiclo de vida do software 4545
46 Engenharia de Software
5. Considere a opção do uso de recompensas
Recompensas podem ser uma forma eficaz de incentivar um deter-
minadocomportamento, mas isso depende da cultura e da filosofia da 
organização. É importante notar que as “cenouras” e os “por-
retes” tendem a falhar quando aplicamos essas metodolo-
gias em pessoas pensadoras e criativas, podendo até ser 
prejudiciais.
A verdadeira motivação é impulsionada por um senso 
de propósito e busca de domínio, razão pela qual transmitir 
o valor do software é tão importante. Dito isso, pequenas 
recompensas voltadas a incentivar a participação podem 
ser bastante eficazes quando relacionadas a tarefas menos 
criativas, como controle de tempo.
Finalmente chegamos à última etapa do ciclo de desenvolvi-
mento de software: a manutenção. Para essa etapa, é essencial que o 
gestor desenvolva um plano de manutenção.
Um plano de manutenção é um documento que define o trabalho 
realizado para manter ativos operacionais. O conteúdo do documento 
ajuda a facilitar o uso contínuo de um ativo com desempenho ideal. 
Sua instalação pode evitar avarias significativas ou renovações impre-
vistas se você seguir as diretrizes fornecidas aqui.
A ideia por trás do planejamento de manutenção é garantir que se 
possa manter as condições de funcionamento adequadas dos equipa-
mentos. Embora um plano comum faça esse trabalho, qualquer ins-
talação requer um programa eficaz para que se aproveitem todos os 
benefícios da política de manutenção.
O principal objetivo da manutenção de software é modificar e atua-
lizar o seu aplicativo após a entrega para corrigir falhas e melhorar o 
desempenho dele.
As principais necessidades de manutenção em softwares são exigi-
das para: 
 • corrigir as falhas;
 • melhorar o design;
 • implementar melhorias;
 • incluir interface com outros sistemas.
Pu
re
So
lu
tio
n/
Sh
ut
te
rs
to
ck
Ciclo de vida do software 47
Dentro dessas necessidades, vale ressaltar os tipos de manutenção 
que precisam ser contemplados no plano de manutenção (HIRAMA, 
2011):
Manutenção corretiva
A manutenção corretiva de um software pode ser essencial para 
corrigir alguns erros observados enquanto o sistema está em uso ou 
para aprimorar o desempenho do sistema.
Para exemplificar, suponha que você acabou de lançar o software 
na noite passada, mas recebe a informação de que os usuários não 
conseguem fazer o login com suas credenciais do Facebook. Você con-
tata seu desenvolvedor e descobre que o código de autenticação que 
se comunica com o Facebook tem um pequeno defeito e precisa ser 
atualizado para restaurar a funcionalidade de login.
A manutenção corretiva, também conhecida como manutenção rea-
tiva, emprega esforços na correção de problemas encontrados após a 
entrega do software.
Manutenção adaptativa
Abrange alterações, atualizações e incrementos em função das ne-
cessidades dos usuários que estão em locais em que o produto seja 
executado em novas plataformas, sistemas operacionais e hardwares.
Para exemplificar esse tipo de manutenção, vamos supor que os 
usuários têm feito login com sucesso no sistema há vários dias e as 
coisas estão indo muito bem, mas você descobre que o problema está 
de volta e os usuários não podem mais acessar suas contas. 
Após várias horas de investigação por seu desenvolvedor, você des-
cobre que o Facebook mudou a maneira como você autentica com sua 
API, portanto seu site precisa ser atualizado para oferecer suporte ao 
novo método. 
Seu desenvolvedor passa mais algumas horas atualizando o site 
para suportar o novo método de autenticação do Facebook e tudo vol-
ta ao normal.
Esse problema requer manutenção adaptativa, que é a modificação 
de um produto de software realizada após sua entrega para manter um 
produto de software utilizável em um ambiente alterado ou em mutação.
48 Engenharia de Software
Manutenção para aumento de qualidade
Um software necessita de manutenção de qualidade para entregar 
aos usuários novas experiências, para que ele possa levar encantamen-
to e uma aproximação ainda maior com seu público-alvo.
Seguindo exemplo anterior, o Facebook encerrou suas alterações e 
parou de comprometer o seu site, mas você começa a receber alguns 
comentários de seus usuários depois de mais alguns dias. 
Acontece que, em vez de o usuário ser enviado para o perfil após 
o login, faz mais sentido ver o painel de atividades recentes. Um pedi-
do razoável; você trabalha com seu desenvolvedor e, após uma rápida 
atualização do sistema, os usuários agora são recebidos com as últimas 
ações do produto para que possam estar sempre atualizados.
A manutenção do software em busca de qualidade, que normal-
mente resulta do feedback do usuário, é de extrema importância, pois 
busca atender especificamente às solicitações de quem o utiliza.
O objetivo é garantir que seus usuários fiquem satisfeitos com a 
experiência e continuem usando seu produto como resultado do valor 
agregado com que a manutenção perfectiva contribui. 
Novos recursos e aprimoramentos para recursos existentes não são 
considerados manutenção perfeita. Se o painel de atividades recentes 
não existisse, ele seria um novo recurso em vez de uma manutenção 
perfeita.
Manutenção preventiva
A manutenção preventiva atua para evitar futuros problemas e insa-
tisfações dos usuários. Seu grande objetivo é antecipar o acontecimen-
to de anomalias futuras que trarão prejuízos ao software.
Continuando com o nosso exemplo, temos que, com as mudanças 
em seu sistema (estamos falando muito hipoteticamente aqui), você 
atrai um grande interesse de sua base de usuários e precisa se prepa-
rar para um evento de alto tráfego nos próximos dias. 
Você não tem certeza se o seu servidor pode suportar esse tipo de 
carga, mas sabe que, se o site cair com tanta atenção, você terá muitos 
usuários irritados que podem abandonar o seu produto. 
Assim, você incumbe seu desenvolvedor de proteção contra esse 
desastre, e ele passa um tempo considerável atualizando o ambiente 
de hospedagem para que este seja mais escalonável. 
Ciclo de vida do software 49
Quando muito tráfego atinge um servidor, suas atualizações garan-
tem que novos servidores fiquem on-line automaticamente para lidar 
com o tráfego extra. Não fazia sentido configurar essa infraestrutura 
de escalonamento automático durante o desenvolvimento, mas, agora 
que você precisa dela, é fundamental para o sucesso do seu produto.
Esse esforço é classificado como manutenção preventiva ou modifi-
cação de um produto de software após a entrega para detectar e corrigir 
possíveis falhas no produto de software antes que elas entrem em vigor.
Quanto mais complexo for o software, provavelmente mais manu-
tenção será necessário para garantir o uso contínuo. As perguntas ób-
vias são “por quê” e “quanto”. Isso varia e é um pouco complicado, pois 
cada produto de software é diferente. 
É possível minimizar os custos de manutenção por meio de planeja-
mento e execução inteligentes, mas também pode-se acabar pagando 
mais para manter o produto do que para desenvolvê-lo se o gestor não 
tomar cuidado.
Existem muitos fatores de custo de manutenção de software: ela 
não se trata apenas de consertar bugs; envolve qualquer esforço para 
manter as coisas funcionando da maneira que seus usuários esperam 
que funcione – e, na maioria das vezes, isso significa outra coisa do que 
simplesmente corrigir defeitos em seu código.
Com esta etapa, concluímos o ciclo de desenvolvimento de softwa-
re, processo altamente importante dentro da engenharia de softwa-
re que busca trazer práticas, ferramentas e metodologias eficazes na 
construção, entrega e manutenção dos softwares.
O livro Não me faça 
pensar, de Steve Krug, 
explica que os humanos 
que usam software ou 
sites tendem a aceitar 
a primeira solução que 
lhes é apresentada. Esse 
ponto essencial deve ser 
aproveitado por enge-
nheiros de softwares que 
querem se diferenciar no 
mercado.
O livro se concentra na 
simplicidade, na objeti-
vidade e no bom senso, 
sendo considerado por 
muitos essencial para 
qualquer engenheiro de 
software. A obra ajuda 
os desenvolvedores aentender a experiência 
do usuário e a mudar sua 
maneira de pensar para 
que o design de interface 
seja sempre a força mo-
triz por trás das decisões 
dos desenvolvedores.
KRUG, S. São Paulo: Alta Books, 
2014.
Livro
CONSIDERAÇÕES FINAIS 
Neste capítulo percorremos todas as etapas que compõem um ciclo 
de desenvolvimento de software e foi possível entender que o desenvol-
vimento de software está em seu ponto de inflexão, considerando a alta 
frequência de interrupções tecnológicas. 
Quase todos os setores estão aproveitando o software para resolver 
os problemas do usuário. A tendência do software está crescendo em um 
ritmo que as empresas precisam acompanhar vigorosamente e seguir em 
frente com o ciclo de vida de desenvolvimento de software para garantir 
uma entrega rápida e de qualidade.
50 Engenharia de Software
Conseguimos compreender que o ciclo de vida do desenvolvimento de 
software é fundamental para criar um software que se encaixe no produto 
e no mercado. A construção de software é uma jornada com vários mar-
cos ao longo de um percurso de A para B.
As organizações vencedoras enfrentam os desafios do processo de 
desenvolvimento de produtos de software e abraçam a mudança em um 
nível holístico. O processo começa com a análise de requisitos, design, 
codificação, teste, implantação e manutenção. Porém, a forma como uma 
equipe aborda as etapas mencionadas depende da respectiva metodolo-
gia de desenvolvimento de software.
Concluímos que o objetivo do ciclo de desenvolvimento de software 
é apresentar um caminho padrão a ser seguido pela equipe que realiza 
essa atividade. Sem um caminho traçado e um senso de direção, os esfor-
ços de desenvolvimento provavelmente fracassarão.
ATIVIDADES
Atividade 1
Neste momento você é o engenheiro de software chefe de uma 
grande empresa de cosmético e precisa convencer todo o seu 
time de desenvolvedores de que o ciclo de vida de desenvolvi-
mento de software eficiente é importante. Ressalte os principais 
benefícios conseguidos com a implantação de um ciclo de vida. 
Se preferir, use um ou mais slides ou, ainda, apresente esses 
benefícios em um texto de no máximo uma página.
Atividade 2
Ainda como engenheiro de software chefe de uma grande 
empresa de cosmético, você precisa, agora, apresentar as etapas 
que compõem o ciclo de desenvolvimento de software e explicar 
rapidamente cada uma dessas fases.
REFERÊNCIAS
ENGHOLM JR., H. Engenharia de software na prática. São Paulo: Novatec, 2010.
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. Rio de 
Janeiro: Elsevier, 2011.
IAN, S. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
PFLEEGER, S. L. Engenharia de software: teoria e prática. São Paulo: Pearson Prentice Hall, 
2007.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: 
AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Education, 2011.
TSUI, F.; KARAM, O. Fundamentos de engenharia de software. São Paulo: LTC, 2013.
Orientação a objetos 51
3
Orientação a objetos
Ao final do estudo deste capítulo, você será capaz de: 
• entender, desenvolver e implementar o conceito de orientação 
a objetos; 
• compreender conceitos de classe e mensagem;
• reconhecer métodos e operações; 
• explorar a abstração da orientação a objetos em soluções 
computacionais;
• modelar softwares utilizando os conceitos de UML.
Objetivos de aprendizagem
O desenvolvimento de software é uma atividade complexa e, como 
tal, quando não há um padrão comum de comunicação e interpretação 
da equipe envolvida, surgem problemas. Para que um software seja de-
senvolvido sem retrabalho e seja fácil mantê-lo no futuro, os envolvidos 
devem interpretar a mesma linguagem. 
Assim como vimos que, para documentar processos, temos o BPMN 
como linguagem universal, para a tarefa de documentar sistemas, temos 
a Linguagem de Modelagem Unificada (UML, do inglês Unified Modeling 
Language). Essa linguagem propõe a construção de diagramas para o de-
senvolvimento de sistemas orientados a objetos, facilitando o desenvolvi-
mento do software (WAZLAWICK, 2019).
Esta obra apresenta um breve histórico sobre a visão da análise de 
sistema até o surgimento da UML como melhor proposta para a repre-
sentação na orientação a objetos. Mostraremos também alguns exemplos 
de diagramas da UML e seus propósitos de maneira geral, pois aprofun-
daremos alguns deles quando for necessário.
A UML é um formato visual muito empregado atualmente para ilustrar 
softwares com base nos conceitos da orientação a objetos. Esse formato 
de modelagem de sistemas fundamentados em objetos pode ser utilizado 
52 Engenharia de Software
em todas as etapas do desenvolvimento das soluções e já é a forma mais 
utilizada no mundo (HASSAN, 2011).
Nas décadas de 1950 e 1960, o desenvolvimento de sistema era 
tecnicista, ou seja, o usuário solicitava ao programador um sistema 
que ele programava sem metodologia ou padrão, somente com a visão 
da necessidade estabelecida, tudo era feito ad hoc, sob demanda. De 
acordo com Hassan (2011), talvez o uso desse termo denote a abor-
dagem da primeira fase de desenvolvimento de sistema, na qual não 
havia planejamento inicial.
A falta desse estudo prévio causava grandes problemas no desen-
volvimento de sistemas: os projetos extrapolavam os prazos, e nós sa-
bemos que controlar o orçamento de um projeto é fundamental. Isso 
acontecia principalmente pela falta de entendimento da real necessi-
dade do usuário. 
Não havia padrões, ferramentas, técnicas e, muito menos, métodos 
para o desenvolvimento de sistemas. Essa situação começou a mudar na 
década de 1970, quando surgiram os primeiros modelos e padrões estru-
turados para facilitar o entendimento da necessidade do usuário. 
Hassan (2011) explica que o rápido crescimento da capacidade com-
putacional das máquinas resultou na demanda por sistemas cada vez 
mais complexos. Por isso, as formas de desenvolvimento dos sistemas 
precisaram ser reavaliadas, o que fez surgirem metodologias, práticas, 
técnicas e padrões para sua modelagem.
Na década de 1980, com o surgimento dos computadores pessoais 
(PCs), aumentou ainda mais a necessidade de desenvolvimento de siste-
mas mais complexos, e a análise estruturada se consolidou na primeira 
metade da década.
Em 1980, Edward Yourdon lançou o livro clássico Análise estrutu-
rada moderna, considerado referência nesse assunto. A análise es-
truturada foi utilizada para modelagem de sistemas estruturados 
por meio da representação gráfica de diagramas de fluxos de dados 
(PRESSMAN, 2016).
Embora já existisse há décadas, foi na década de 1980 que o para-
digma para a modelagem de sistemas orientados a objetos ganho força, 
exigindo uma análise que fosse além do paradigma estruturado. 
Orientação a objetos 53
3.1 Orientação a objetos 
Vídeo
A orientação a objetos (OO) é um paradigma alcançado pelos pro-
gramadores de softwares que emprega na modelagem objetos, ao 
passo que a programação tradicional utiliza em sua modelagem fun-
ções e procedures. Um objeto pode ser entendido como um agente 
abstrato que pertencerá ao sistema com atributos e métodos específi-
cos (WAZLAWICK, 2019).
A OO foca os objetos que os engenheiros de softwares precisam 
operar dentro do sistema ao contrário da lógica necessária para 
manipulá-los. Esse tipo de procedimento na programação é indicado 
para qualquer tipo de software que desejamos desenvolver, pois otimi-
za recursos e incrementa qualidade.
Os benefícios da OO incluem (PRESSMAN, 2016):
 • Modularidade: os sistemas se tornam modulares como se esti-
vem em caixas, com isso, a manutenção e a reutilização são mui-
to mais fáceis.
 • Reutilização: com os objetos, a reutilização se torna ágil, basta o 
programador entender que uma classe de determinado sistema 
funcionará em outro sistema para reutilizá-lo.
 • Produtividade: a produção de software se torna acelerada com a 
reutilização de classes em vários sistemas.• Facilmente atualizável e escalável.
 • Segurança: como as caixinhas de softwares já foram implemen-
tadas e testadas, a segurança do programador em usar aumenta.
A seguir exploraremos os principais conceitos da orientação a 
objetos: classes, objetos, abstração, encapsulamento, polimorfismo 
e herança.
3.2 Classes e objetos 
Vídeo Objetos são pessoas, lugares ou coisas que são relevantes para os 
sistemas que serão desenvolvidos. Estes quando orientados a obje-
tos descrevem entidades como objetos. Os objetos típicos podem ser 
clientes, itens, pedidos e assim por diante (PRESSMAN, 2016).
54 Engenharia de Software
Eles normalmente fazem parte de um grupo de itens semelhantes 
chamados classes. O desejo de colocar itens em classes não é novo. 
Descrever o mundo como sendo feito de animais, vegetais e minerais é 
um exemplo de classificação.
A ideia por trás das classes é ter um ponto de referência e descrever 
um objeto específico em termos de suas semelhanças ou diferenças 
em relação aos membros de sua própria classe. 
Ao fazer isso, é mais eficiente para alguém dizer: “o urso coala é um 
marsupial (ou animal com bolsa) com uma grande cabeça redonda e 
orelhas peludas”, do que descrever um urso coala com todas suas ca-
racterísticas como um mamífero. 
É mais eficiente descrever características, aparências e até mesmo 
comportamentos dessa maneira. Quando ouvimos a palavra reutili-
zável no mundo orientado a objetos, significa que podemos ser mais 
eficientes, porque não precisamos começar do início para descrever 
um objeto sempre que ele for necessário para o desenvolvimento de 
software (WAZLAWICK, 2019).
Uma classe é um dispositivo abstrato, utilizado para demonstrar 
objetos relevantes aos sistemas de maneira concreta. As classes de 
objetos são formas de categorizar instâncias dentro do sistema que 
será desenvolvido, tais como: Produtos, Alunos, Professores, Nota Fis-
cal, Contas a Pagar, Contas a receber, entre outros. 
Dentro das classes temos os atributos que irão especificar os 
objetos, por exemplo: CPF do cliente, E-mail, Endereço, Preço, Nota 
(HIRAMA, 2011).
Além dos atributos, as classes possuem métodos, que são as ope-
rações que os objetos podem desempenhar dentro do sistema, como: 
Incluir cliente, Vender produto, Excluir aluno etc.
Um método é um pedaço de código-fonte escrito dentro de uma 
classe que foi nomeada e tem a capacidade de ser chamada. Ele sem-
pre faz parte de alguma classe e é frequentemente usado para modifi-
car o estado interno de um objeto instanciado de uma classe.
Cada classe deve ter um nome que a diferencie de todas as outras 
classes, geralmente são substantivos ou frases curtas e começam com 
uma letra maiúscula. 
Na Figura 1, a classe é chamada Rental_Car, representada por um 
retângulo. Ele contém dois outros recursos importantes: uma lista de 
Orientação a objetos 55
atributos e uma série de métodos. Esses itens descrevem uma classe, 
a unidade de análise que é uma grande parte do que chamamos de 
análise e design orientado a objetos.
rental_car
- placa do automóvel
- modelo
- cor
- ano
- tamanho
Figura 1
Classe
Fonte: Elaborada pelo autor.
Um atributo descreve alguma propriedade que todos os objetos da 
classe possuem. Observe que a classe Rental_Car possui os atributos 
de tamanho, cor, ano, placa e modelo. Todos os carros apresentam 
esses atributos, mas cada carro terá valores diferentes para eles. 
Por exemplo, um carro pode ser azul, branco ou de alguma outra cor. 
Mais adiante, demonstraremos que você pode ser mais específico sobre 
o intervalo de valores dessas propriedades. Ao especificar atributos, a 
primeira letra geralmente é minúscula.
Além dos atributos, a classe possui métodos. Um método é uma 
ação que pode ser solicitada de qualquer objeto da classe. Métodos são 
os processos que uma classe pode realizar.
Os métodos também são chamados de operações. Para a classe de 
Rental_Car, inclusão(), exclusão() e saída() são exemplos de métodos. 
Ao especificá-los, a primeira letra geralmente é minúscula.
A seguir, segue a classe Rental_Car com os métodos.
rental_car
- placa do automóvel
- modelo
- cor
- ano
- tamanho
inclusão()
exclusão() 
saída()
Figura 2
Classe com métodos
Fonte: Elaborada pelo autor.
56 Engenharia de Software
Para ficar mais claro, vamos hipoteticamente definir os métodos do 
Rental_Car:
 • inclusão(): será responsável por incluir carros no cadastro;
 • exclusão(): executará a exclusão de carros do cadastro;
 • saída(): controlará as saídas de carros para locação.
Dessa forma, podemos concluir que as classes precisam ter 
nome, atributos e métodos. A seguir, seguem mais dois exemplos 
de classes de objetos.
 
produtos
- código
- descrição
- quantidade em estoque
- preço
- peso 
inclusão()
consulta() 
venda()
fornecedores
- cnpj
- razão social
- endereço
- cidade
- estado
alteração()
relatório() 
Figura 3
Classes de objetos – produtos e fornecedores
Fonte: Elaborada pelo autor.
3.3 Abstração 
Vídeo
Este é um processo de selecionar o método e os atributos necessários 
para especificar o objeto. A abstração se concentra nas características es-
senciais de um objeto em relação à perspectiva do usuário (HIRAMA, 2011).
Abstração significa a arte de representar as características essenciais 
sem se preocupar com os detalhes das classes, com ela temos os se-
guintes benefícios: 
 • reduzir a complexidade de ver as coisas;
 • evitar a duplicação de classes e aumentar a capacidade de 
reutilização;
 • ajudar a aumentar a segurança de um aplicativo ou programa, 
pois apenas detalhes importantes são fornecidos ao usuário;
 • esconder a complexidade subjacente dos dados;
 • ajudar a evitar códigos repetitivos;
 • dar flexibilidade aos programadores para alterarem a implemen-
tação do comportamento abstrato.
Orientação a objetos 57
Abstrair significa mostrar apenas dados relevantes e esconder deta-
lhes desnecessários de um objeto do usuário. Por exemplo, quando você 
faz login em sua conta Amazon on-line, você insere seu user_id e senha e 
clica em login. Nesse momento, o processo acessa seu banco de dados e 
retorna com o acesso ou uma mensagem de senha incorreta.
O processo de validação de senha junto ao banco de dados é abs-
traído do usuário, ele não precisa conhecer o processo, só precisa rece-
ber o acesso ou uma mensagem de erro.
Outro exemplo de abstração, um automóvel é um objeto que é com-
posto de vários outros objetos menores, como um sistema de engrena-
gens, mecanismo de direção, motor, suspensão, tanque de combustível, 
e inúmeros outros componentes. Mas para o motorista comum, o carro 
é um único objeto que irá levá-lo de um lugar para outro.
A abstração permite que os engenheiros de software tenham uma 
visão panorâmica do sistema. Ao contrário do encapsulamento (que 
veremos mais à frente), ela tende a generalizar as coisas, ocultando 
dados indesejados e revelando os dados necessários, com isso, os de-
senvolvedores conseguem escrever códigos limpos, economizando es-
paços e mantendo programas facilmente (SOMMERVILLE, 2011).
Vamos imaginar mais um exemplo para ficar mais claro, pense 
na interface do seu celular. Quer você use um sistema operacional 
Android ou iOS, você não interage diretamente com o código que per-
mite que seu telefone se conecte à internet, envie uma mensagem de 
texto ou jogue um videogame. 
Em vez disso, você interage com o código por meio de uma interface 
de usuário projetada para otimizar sua experiência e facilitar o acesso 
às funções e aos métodos necessários para concluir uma tarefa. Nesse 
caso, a interface é abstraída da implementação real do código.
A abstração pode ser impactada pelo perfil do usuário e pelos direi-
tos de acesso, por exemplo: o presidente da empresa poderá ter uma 
visão de muito mais.
3.4 Encapsulamento 
Vídeo
Encapsular, na orientação a objetos, significa agrupar atributos e 
métodos com um funcionamento único. Esse conceito também é fre-
quentemente usado para ocultar a representação interna,ou estado, 
58 Engenharia de Software
de um objeto de fora. Isso é chamado de ocultação de informações 
(SOMMERVILLE, 2011).
Getter e Setter são os métodos mais presentes nas linguagens de 
programação, assim, quando for encapsular objetos, procure por essas 
duas palavras. No encapsulamento, é possível fazer com que um mé-
todo ou atributo seja excluído, omitido ou deixado apenas para leitura.
Vamos dar uma olhada em um exemplo que mostra o conceito de 
encapsulamento e como você pode usá-lo para implementar a oculta-
ção de informações e aplicar a validação adicional antes de alterar os 
valores de seus atributos de objeto.
Para ficar mais claro, vamos imaginar uma classe de objetos cha-
mada Maquina de Café, sendo que seus atributos poderiam ser: vol-
tagem da Máquina de café, capacidade de cafés por dia, método de 
moagem de café, cor, tamanho, entre outros. Para o conceito do en-
capsulamento, podemos ter um método, por exemplo, “fazer café”, 
que engloba vários outros métodos, ficando invisível para o usuário 
os métodos mais simples.
Olhe outro exemplo elucidador, imagine uma calculadora, enten-
demos sua interface à primeira vista e não precisamos saber como 
funciona por dentro. Somente precisamos ter a ciência de que ao 
pressionarmos “2 + 2” e, em seguida, “=”, teremos o resultado 4 no vi-
sor. Ou seja, a calculadora é um encapsulamento de todas as opera-
ções matemáticas que acontecem internamente nela.
O objeto gerencia seu próprio estado por meio dessas funções, e 
nenhuma outra classe pode alterá-lo, a menos que seja explicitamente 
permitido. Para se comunicar com o objeto, o programador precisará 
utilizar os métodos fornecidos.
Vamos utilizar mais um exemplo para o conceito ficar mais explícito, 
falaremos de uma classe de objetos chamada Conta Bancária. Pressu-
pomos que nessa classe inserimos somente os atributos nome e saldo, 
com o objetivo de simplificar a visualização dos usuários.
Nela iremos inserir o método “depositar”, que, como o próprio nome 
diz, será responsável por receber o crédito na conta corrente.
O cálculo interno será simples, ou seja, soma-se o valor atual com o 
valor a ser depositado, com isso, o atributo saldo é atualizado, sendo 
que o atributo nome não deverá ser alterado.
Orientação a objetos 59
Se houve a possibilidade dos atributos serem acessados diretamen-
te em qualquer parte do código-fonte, o programador estará correndo o 
risco do saldo ser atualizado sem que o método de depositar tenha sido 
executado. Para evitar esse problema, é indicado que o engenheiro use os 
métodos específicos para esse fim, por exemplo: “atualiza saldo”.
Com o encapsulamento, não percebemos que temos um método cha-
mado “atualiza saldo” que está encapsulado dentro do método “depositar”.
Com esse exemplo, podemos perceber que o encapsulamento evita 
o acesso indevido a alguns dados sensíveis, além de outras vantagens 
importantes no desenvolvimento orientado a objetos. A seguir mostra-
remos alguns benefícios essenciais. 
Manutenção de código
É possível afirmar que todo código vai precisar de manutenção 
depois de algum tempo, tudo muda muito rapidamente, e os códigos 
precisam se adaptar às novas necessidades. Imagine códigos muito ex-
tensos, como o Facebook, estima-se que ele tenha mais de 60 milhões 
de linhas de códigos.
A manutenção em um software desse tamanho parece impossível, 
não é? O encapsulamento facilita muito as operações de manutenção, 
pois o programador encontrará mais rapidamente o ponto exato da 
alteração do código, é como procurar caixinhas identificadas dentro de 
um armário. Sem o encapsulamento, seria procurar um par de meia 
dentro de um grande armário totalmente desorganizado.
Reuso de código
O encapsulamento propicia que o desenvolvedor reutilize seus códi-
gos já testados e funcionando. Suponha que um programador precise 
criar uma tela de login e senha e ele já tenha uma operação dessa funcio-
nando em sua empresa, basta ele pegar a rotina encapsulada, alterar tal-
vez cor e fonte, ou nem isso, e colocar para funcionar em outro sistema.
Com isso, ele ganha tempo de programação e evita disponibilizar 
rotinas não testadas ou com problemas, o ganho é muito alto quando 
pensamos em escala.
Desenvolvimento acelerado e simplificado
Com o reuso de código, é óbvio que aceleramos e simplificamos o 
desenvolvimento de sistemas. Os encapsulamentos já estão testados e 
funcionando, então, por que não os reutilizar para ganharmos agilidade?
60 Engenharia de Software
O pilar do encapsulamento auxilia de maneira incrível o desen-
volvimento orientado a objetos, trazendo também proteção aos da-
dos sensíveis ou sigilosos. 
3.5 Polimorfismo 
Vídeo Polimorfismo é originalmente uma palavra grega que significa a ca-
pacidade de assumir várias formas. No paradigma orientado a objetos, 
ele implica o uso de operações de maneiras diferentes, dependendo da 
instância na qual estão operando. 
O polimorfismo permite que objetos com diferentes estruturas in-
ternas tenham uma interface externa comum. É particularmente eficaz 
ao implementar a herança que veremos a seguir.
Vamos começar com um exemplo simples para o conceito ficar mais 
claro. Imaginem duas classes, Circulo e Quadrado, cada uma com um 
método Calcula_Area(). Embora o nome e a finalidade dos métodos nas 
classes sejam os mesmos, a implementação interna, ou seja, o procedi-
mento de cálculo da área, é diferente para cada classe. 
Cada figura tem sua fórmula para calcular a área. Quando um objeto 
da classe Circulo invoca seu método Calcula_Area (), a operação encontra 
a área do círculo sem nenhum conflito com o método Calcula_Area() da 
classe Quadrado, eles entendem que devem usar fórmulas diferentes.
O polimorfismo é considerado uma das características importantes 
da Programação Orientada a Objetos e nos permite realizar uma única 
ação de modos diferentes. Em outras palavras, o polimorfismo permite 
definir uma interface e ter várias implementações. 
A palavra poli significa muitos, e morfos significa formas, então, a 
palavra polimorfismo significa ter muitas formas, em outras palavras, 
podemos definir polimorfismo como a capacidade de uma mensagem 
ser exibida em mais de uma forma.
Olhe outro exemplo da vida real de polimorfismo, uma pessoa ao 
mesmo tempo pode ter características diferentes. Como um homem 
ao mesmo tempo pode ser pai, marido, empregado. Portanto, a mes-
ma pessoa possui um comportamento diferente em várias situações 
dentro de um sistema computacional.
Orientação a objetos 61
E para finalizar, outro exemplo, o jogo de xadrez apresenta várias 
peças, certo? Para sermos mais precisos, no xadrez moderno cada jo-
gador irá dispor de 16 peças, sendo oito peões, dois bispos, dois ca-
valos, duas torres, um rei e uma dama, sendo que cada componente 
possui um movimento particular.
O peão, por exemplo, se desloca para frente, o cavalo, por sua vez, 
anda em L, enquanto o bispo se movimenta na diagonal e assim por 
diante. Dentro do conceito do polimorfismo, podemos afirmar que to-
dos são peças, porém com métodos de deslocamentos diferentes.
Podemos concluir que o polimorfismo abre a possibilidade para que 
os programadores se preocupem com as generalidades, deixando que 
o ambiente de tempo de execução trate as especificidades. Agora va-
mos explorar o conceito de herança.
3.6 Herança 
Vídeo Herança é um dos principais conceitos da OO, pois é onde o progra-
mador pode derivar uma classe de outra classe para uma hierarquia de 
classes que compartilham um conjunto de atributos e métodos.
É possível declarar diferentes tipos de exceções, adicionar lógica 
personalizada a estruturas existentes e até mesmo mapear seu mode-
lo de domínio para um banco de dados.
A herança visa otimizar o trabalho dos programadores, pois permite 
que aconteça a tão buscada otimização, deixando que os engenheiros 
de software criem hierarquias de classes, em que classes e objetos her-
dam propriedades e comportamentos de sua classe pai.
Uma classe que herdade uma classe pai é chamada de subclasse ou 
classe filha, e os objetos que recebem propriedades e comportamentos 
de um pai por meio de herança são chamados de objetos filhos.
Como isso é útil? 
Um grande diferencial da herança é a possibilidade da reutilização 
de procedimentos já testados e validados. Vamos usar como exemplo 
um zoológico que possui duas ou mais espécies de cada animal, sem-
pre com o objetivo da preservação. 
62 Engenharia de Software
Suponhamos que você desenvolverá um software para o controle 
dos animais, provavelmente seria essencial criar uma classe chama-
da animal. 
Lembrando que criar uma classe única para cada animal rapidamen-
te se tornaria muito repetitivo, porque existem algumas propriedades 
e comportamentos que se aplicam a cada animal, desde um papagaio 
até uma girafa. 
As funções compartilhadas podem incluir alimentar(), hidratar(), 
limpar_ambiente(). Em vez de criar esses atributos compartilhados re-
petidamente para cada animal, poderíamos criar uma classe Animal pai. 
Essa classe pai iria conter as propriedades e os comportamen-
tos universais para todos os animais e nos salvaria de ter que criar 
essas funções compartilhadas. Deu para perceber a importância do 
conceito herança?
Ou seja, herança é um caminho dentro da Programação Orientada 
a Objetos que possibilita ao engenheiro utilizar propriedades de outras 
classes sem a necessidade de reprogramação.
Uma criança herda as características de seus pais, por exemplo. Com 
a herança, podemos reutilizar os campos e os métodos da classe exis-
tente. Consequentemente, a herança facilita a reutilização de códigos.
Dentro dela temos alguns tipos de herança que iremos explorar a 
seguir (HASSAN, 2011).
Herança única: uma única classe fornece seus atributos a uma 
outra classe.
Figura 4
Herança única
Class A Class B
Fonte: Elaborada pelo autor.
No diagrama da Figura 4, a Class A fornece atributos apenas a Class 
B. A Class A é uma superclasse e a Class B é uma subclasse.
Orientação a objetos 63
Herança múltipla: é uma herança em que uma classe se estende a 
mais de uma classe. 
Figura 5
Herança múltipla
Class A Class B
Class C
Fonte: Elaborada pelo autor.
Conforme o diagrama da Figura 5, a Class C herda atributos da 
Class A e da Class B.
Herança multinível: uma classe pode herdar de uma classe deriva-
da. Portanto, a classe derivada se torna a classe base para a nova classe.
Figura 6
Herança multinível
Class A Class B Class C
Fonte: Elaborada pelo autor.
Conforme mostrado no diagrama da Figura 6, a Class C é uma 
subclasse de B, e B é uma subclasse da Class A. Sendo que a Class B 
herda atributos da A e a Class C herda atributos da Class A e também 
da Class B.
Herança hierárquica: uma classe herda atributos de muitas ou-
tras superclasses.
64 Engenharia de Software
Figura 7
Herança hierárquica
Class B Class C
Class A
Class D
Fonte: Elaborada pelo autor.
Na herança hierárquica, conforme mostrado no diagrama da Figura 
7, a Class C, B e D herdam atributos da superclasse A.
Com essas estruturas, o programador pode escolher entre a melhor 
opção para desenvolver seus modelos orientados a objetos, sempre 
buscando eficiência, eficácia em seus códigos.
Dentro dos recursos da orientação a objetos, vale ressaltarmos a 
generalização e a especialização. Eles representam uma hierarquia 
de relacionamentos entre classes, em que as subclasses herdam de 
superclasses.
CONCLUSÃO
Neste capítulo foi possível compreender como os princípios de obje-
tos, encapsulamento, herança e polimorfismo são as bases para o desen-
volvimento de sistemas orientados a objetos. 
Para compreender e expressar os recursos essenciais e interessantes 
de um aplicativo no complexo mundo real, um modelo orientado a ob-
jetos é construído em torno destes. Um objeto encapsula dados e com-
portamentos, o que implica que os analistas podem usar a abordagem 
orientada a objetos para modelagem de dados e modelagem de processo.
Vimos também que objetos específicos em um sistema podem herdar 
características da instância global de um objeto. Por exemplo, muitos ti-
pos de objetos podem ter um nome e uma data de criação. 
Objetos específicos podem herdar essas características globais de 
objetos pais que incluem apenas características globais e podem herdar 
características de mais de um objeto pai. A herança tenta evitar a definição 
Na obra de iniciação à 
orientação a objetos, Orien-
tação a objetos: aprenda 
seus conceitos e suas aplica-
bilidades de forma efetiva, 
você poderá irá iniciar a 
leitura com um breve histó-
rico do tema conhecendo 
o início desse conceito 
que surgiu na Noruega, 
aprofundando os conceitos 
de reuso, coesão e acopla-
mento. Suas definições de 
classe, atributo, método e 
objeto são bastante claras 
e objetivas, ajudando você 
a se aprofundar num as-
sunto que, algumas vezes, 
parece mais complicado 
do que é. A obra finaliza 
com boas práticas no uso 
da orientação a objetos, 
chamando atenção para 
herança, polimorfismo, en-
capsulamento e abstração, 
e como eles podem ser 
úteis no desenvolvimento 
de sistema eficientes.
CARVALHO, T. L. São Paulo: Casa do 
Código, 2016.
Livro
Orientação a objetos 65
redundante de características semelhantes que podem ser incorporadas 
em níveis superiores do sistema.
Outro conceito importante abordado foi o polimorfismo, funcionalida-
de conceitualmente semelhante entre objetos diferentes, é extraída em 
um nível global.
Esse processo limita a produção de funcionalidade paralela e agiliza 
a interface de informações. O polimorfismo direciona o redator da es-
pecificação a compreender a funcionalidade de um processo e torná-lo 
disponível para qualquer objeto que requeira uma instância semelhante 
de funcionalidade.
E foi assim que exploramos melhores práticas para a análise e o de-
senvolvimento de sistemas computacionais, sempre visando não só aten-
der às necessidades dos usuários, e sim surpreendê-los em menor tempo 
com menor custo possível.
ATIVIDADES
Atividade 1
Você foi chamado para convencer um time de engenheiros de 
softwares que a orientação a objetos é muito mais adequada para 
o atual momento quando comparamos com os antigos padrões 
de análise e desenvolvimento de software. Para essa missão, você 
deverá construir um quadro que compare e ressalte os benefícios 
entre a orientação a objetos e os métodos tradicionais.
Atividade 2
Seguindo os exemplos vistos, escolha e desenvolva mais três 
classes de objetos com no mínimo três atributos e três métodos 
para um sistema de supermercado.
REFERÊNCIAS 
HASSAN, G. Software modeling and design: UML, use cases, patterns, and software 
architectures. Cambridge: Cambridge University Press, 2011.
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. Rio de 
Janeiro: Elsevier, 2011.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: 
AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Education, 2011.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. São Paulo: GEN LTC, 2019.
66 Engenharia de Software
4
UML – Unified Modeling 
Language
Com o estudo deste capítulo, você será capaz de: 
• compreender conceitos da Unified Modeling Language (UML);
• desenvolver notações gráficas de engenharia de softwares;
• explorar atividades práticas de diagramas de caso de uso;
• entender e implementar os diagramas da UML, que são o dia-
grama de atividades, diagrama de classe, diagrama de objetos e 
diagrama de sequência.
Objetivos de aprendizagem
O desenvolvimento de software é uma atividade complexa e, como tal, 
quando não há um padrão comum de comunicação e interpretação da 
equipe envolvida, surgem problemas. 
Para que um projeto de software seja desenvolvido sem prejuízos e 
seja fácil mantê-lo no futuro, os envolvidos devem interpretar a mesma 
linguagem. Assim como vimos, para desenvolver um software, seguimos 
algumas etapas indicadas pela engenharia de softwares; jápara a tarefa 
de documentar sistemas, temos a Linguagem de Modelagem Unificada, 
do inglês Unified Modeling Language (UML).
Essa linguagem gráfica descreve o desenvolvimento de diagramas 
ilustrativos para o desenvolvimento de softwares orientados a objetos, 
atribuindo mais eficiência e assertividade ao processo (HIRAMA, 2011).
4.1 UML 
Vídeo
UML é como é conhecida no mercado a Unified Modeling Language 
– ou, em português, Linguagem de Modelagem Unificada. Trata-se de 
uma forma padronizada e gráfica para a ilustração de sistemas.
UML – Unified Modeling Language 67
O UML é composto por um conjunto de diagramas confeccionado, 
ao longo do tempo, por profissionais de tecnologia, buscando a espe-
cialização, visualização, construção e documentação de partes ou siste-
mas completos (HASSAN, 2011). Essa coleção de melhores práticas em 
engenharia de softwares apresenta um passo a passo para que enge-
nheiros de softwares e todos os envolvidos possam dialogar de modo 
eficiente na construção dos projetos. 
A linguagem visual é uma parte muito importante do desenvolvi-
mento de software orientado a objetos e, também, do processo de 
desenvolvimento de software. A UML usa, principalmente, notações 
gráficas para expressar o design de projetos de software. Seu uso aju-
da as equipes de projeto a se comunicarem, a explorarem projetos po-
tenciais e a validarem o projeto arquitetônico do software.
No ano de 1994, o engenheiro de software Jim Rumbaugh, um dos 
idealizadores do Object Modeling Technique (OMT) – técnica de mo-
delagem de objetos da época –, deu um grande passo na carreira, 
deixando o emprego na General Electric e se unindo com outro enge-
nheiro, Grady Booch, da Rational Corp, para o desenvolvimento do mé-
todo unificado, que deu origem à UML atual (PRESSMAN, 2016).
À medida que o valor estratégico do software aumenta para muitas em-
presas, a indústria busca técnicas para automatizar a produção de software, 
melhorar a qualidade e reduzir o custo e tempo de colocação no mercado. 
Além disso, o desenvolvimento para a World Wide Web (WWW), que é 
a internet, embora torne algumas coisas mais simples, exacerbou esses 
problemas de arquitetura. A UML foi projetada para responder a essas 
necessidades, ou seja, ela (PRESSMAN, 2016):
 • entrega aos interessados no processo uma linguagem de mode-
lagem visualmente eficiente e pronta para utilizar, com o objetivo 
de desenvolver e socializar modelos;
 • fornece dispositivos visuais para demonstrar o desenvolvimento 
de softwares, explorando os conceitos principais;
 • é independente de determinadas linguagens de programação e 
processos de desenvolvimento;
 • fornece uma base formal para a compreensão da linguagem 
de modelagem;
 • incentiva o crescimento do mercado de ferramentas voltadas à 
orientação a objetos;
68 Engenharia de Software
 • suporta conceitos de desenvolvimento macros, como colabora-
ções, estruturas, padrões e componentes;
 • integra as melhores práticas.
A seguir, vamos explorar os seus vários diagramas que representam 
os softwares e seus projetos a todos os interessados, desde o usuário 
e o presidente da empresa até os engenheiros, os programadores e os 
analistas de sistemas.
4.2 Os diagramas da UML 
Vídeo Em um desenvolvimento de software, temos muitas partes inte-
ressadas participando, como: analistas, designers, programadores, 
testadores, usuários, clientes, autores técnicos entre outros.
Todas essas pessoas estão interessadas em diferentes aspectos do 
sistema, e cada um deles requer um nível diferente de detalhe. Por 
exemplo, um programador precisa entender o design do sistema e ser 
capaz de converter esse design em um código-fonte (PRESSMAN, 2016).
Por outro lado, se um redator técnico está interessado no comporta-
mento do sistema como um todo, precisa entender como o produto 
funciona. Assim, a UML tenta fornecer uma linguagem bem expressiva, 
de modo que todos os interessados possam se beneficiar de pelo me-
nos um diagrama.
A UML é composta por diversos tipos de diagramas que ilustram os 
projetos com diversas visões. Em seguida, vamos conhecer os seguin-
tes diagramas:
 • diagrama de atividades;
 • diagrama de classe;
 • diagrama de objetos;
 • diagrama de sequência.
4.3 Diagrama de atividades 
Vídeo
Os diagramas de atividades são usados para desenvolver representa-
ções gráficas que ilustram os fluxos de trabalho e as atividades dos partici-
pantes do sistema, com suporte para escolha, interação e simultaneidade. 
UML – Unified Modeling Language 69
Ele descreve o fluxo de controle do sistema de destino, como a 
exploração de regras e as operações de negócios complexas, descre-
vendo o caso de uso e, também, o processo de negócios. 
Na UML, os diagramas de atividades têm como objetivo modelar 
processos computacionais e organizacionais, ou seja, os fluxos de 
trabalho (HASSAN, 2011). Esses diagramas descrevem como as ativi-
dades são coordenadas, para fornecer um serviço que pode estar em 
diferentes níveis de abstração. 
Normalmente, um evento precisa ser alcançado por algumas opera-
ções, particularmente quando a operação se destina a atingir uma série 
de coisas diferentes que requer coordenação. Ainda, como os eventos 
em um único caso de uso se relacionam entre si, em particular, há casos 
de uso em que atividades podem se sobrepor e exigir coordenação. 
Esse diagrama também é adequado para modelar como uma coleção 
de casos de uso é coordenada para representar fluxos de trabalho de 
negócios. Para ilustrar o entendimento, vamos tomar alguns exemplos.
O primeiro exemplo é o processo de escrever um texto em um 
software de editor de texto; é um caso simples, que todos nós faze-
mos automaticamente, mas vamos aceitar o desafio de modelar 
esse processo.
A seguir são apresentadas as atividades que desempenhamos para 
desenvolver um texto (WAZLAWICK, 2019): 
1. abra o software de processamento de texto;
2. crie um arquivo;
3. salve o arquivo com um nome exclusivo em seu diretório;
4. digite o documento;
5. se forem necessários gráficos, abra o pacote de gráficos, crie os 
gráficos e cole-os no documento;
6. se for necessária uma planilha, abra o pacote da planilha, crie a 
planilha e cole-a no documento;
7. salve o arquivo;
8. imprima uma cópia impressa do documento;
9. saia do pacote de processamento de texto.
De posse dessas nove atividades, vamos ao desenvolvimento do 
diagrama de atividades.
70 Engenharia de Software
Imprima uma 
cópia impressa do 
documento
Salve o arquivo
Abra o pacote da planilha, 
crie a planilha e cole-a no 
documento
Abra o pacote de gráficos, 
crie os gráficos e cole-os 
no documento
Digite o documento
Salve o arquivo com 
um nome exclusivo 
em seu diretório
Crie um arquivo
Abra o software de 
processamento de 
texto
Saia do pacote de 
processamento de 
texto
Se forem necessárias planilhas
Se forem necessários gráficos
Figura 1
Diagrama de atividades: elaborando um texto
Fonte: Elaborada pelo autor.
4.4 Diagrama de classe 
Vídeo O diagrama de classes é uma ferramenta que auxilia na modela-
gem de todos os métodos da orientação a objetos. Ele impulsiona a 
descrição dos tipos de objetos nos projetos e os respectivos tipos de 
relacionamentos que existem entre esses objetos. Há três tipos de re-
lacionamento essenciais, a saber (WAZLAWICK, 2019): 
1. Associação: representa relacionamentos entre instâncias de 
tipos – uma pessoa trabalha para uma empresa, e uma empresa 
possui vários escritórios.
2. Herança: ocorre quando entidades herdam atributos e métodos 
de outras entidades; ajuda muito na otimização de códigos.
3. Agregação: é uma forma de composição de objetos no design 
orientado a objetos.
UML – Unified Modeling Language 71
O diagrama de classes possui alguns objetivos específicos:
 • mostrar a estrutura estática dos classificadores em um sistema;
 • fornecer uma notação básica para outros diagramas de estrutu-
ra, prescritos pela UML;
 • ser útil para desenvolvedores e outros membros daequipe também;
 • ser usado pelos analistas de negócios para modelar sistemas 
por meio de uma perspectiva de negócios.
Para o desenvolvimento dos diagramas de classe, é preciso seguir 
uma notação específica que pode ser compreendida por todos os 
envolvidos e padronizada no mundo todo: 
• Nome da classe: aparece na primeira partição.
• Atributos de classe: são mostrados na segunda partição.
• Operações de classe (métodos): são mostradas na terceira partição, sendo 
entendidas como serviços que a classe oferece.
Veja, na Figura 2, como deve ser usada a notação para classes 
de objeto.
Figura 2
Classe de objetos 
Nome da classe
Atributo da classe
Métodos da classe
Fonte: Elaborada pelo autor.
Para ficar mais claro, vamos usar um exemplo simples, pensando 
em um sistema que irá controlar alunos alocados em uma turma, com 
professores destacados para ministrar aulas.
Aluno
nome: Texto
matricula: Inteiro
definirNome(nome)
obterNome()
definirNome()
definirMatricula(matricula)
obterMatricula
Professor
nome: Texto
titulacao: Texto
definirNome(nome)
obterNome()
definirTitulacao(titulo)
obterTitulacao
Turma
codigo: Texto
sala: Texto
horario: Horario
estaAberta()
definirProfessor(professor)
incluirAluno(aluno)
esta-matriculado-em e-ministrada-por 
Figura 3
Diagrama de classe: salas de aula
Fonte: Elaborada pelo autor.
72 Engenharia de Software
Vamos destacar algumas características do diagrama apresentado.
A classe Aluno possui como atributos: “nome”, como texto; e 
“matrícula”, como número inteiro. Ainda, possui como métodos: 
definirNome, ObterNome, definirMatrícula e obterMatricula – todos 
eles relacionados à classe Aluno.
O mesmo ocorre com as classes Turma e Professor; entre elas, te-
mos relacionamentos simples, em que um Aluno está matriculado em 
uma Turma, e uma Turma é ministrada por professores.
No próximo exemplo, usamos as chamadas cardinalidades, nas 
quais é possível indicar as quantidades nos relacionamentos. Vamos 
hipoteticamente desenvolver um sistema para um berçário. 
Medico
CRM
Endereco
Telefone celular
Bebe
Medicamento
Descricao
Quantidade em estoque
UnidadeMedida
Mae
Sobrenome
Endereco
Telefone
Medicacao
Quantidade
Data
Hora
Pessoa
Nome
Data de nascimento
Figura 4
Diagrama de classe: berçário
Uma pessoa pode ser um bebê, 
um médico ou uma mãe
faz parto
0..* 0..* 
0..* 
0..* 
1 1
possui uma
Ingere
Fonte: Elaborada pelo autor.
Nesse exemplo, temos que um médico pode fazer o parto de zero a 
infinitos bebês, com a notação “0...*”, enquanto um bebê terá exclusi-
vamente “1” médico responsável pelo parto.
Vamos a outra ilustração para ficar claro o entendimento: uma 
classe Mae pode possuir de zero a infinitos bebês, e um bebê tem 
exclusivamente uma mãe. Já uma classe Bebe pode ter de zero a infini-
tos medicamentos, e um medicamento pode ser ministrado de zero a 
infinitos bebês.
UML – Unified Modeling Language 73
O diagrama de classes é um modelo estático utilizado para ilustrar, 
com uma visão estática, o funcionamento de um sistema a ser projeta-
do. Esse tipo de diagrama é essencial, também, para os codificadores 
implementarem seus códigos.
Alguns pontos devem ser lembrados ao desenhar um diagrama de 
classe, a saber (WAZLAWICK, 2019):
 • o nome do diagrama de classes precisa ser significativo para de-
monstrar o aspecto do sistema;
 • cada elemento e as suas relações devem ser levantados junto aos 
usuários com antecedência;
 • os atributos e métodos de cada classe devem ser claramente 
identificados;
 • as propriedades essenciais devem ser especificadas para cada 
classe, desconsiderando-se os desnecessários;
 • as notas podem ser utilizadas à vontade para descrever e informar 
aos interessados sobre as particularidades do sistema.
Antes de finalizar, faça a revisões necessárias. Não se preocupe em 
chegar à versão final, porque, depois que as codificações se iniciam, os 
custos aumentam.
4.5 Diagrama de objetos 
Vídeo Um diagrama de objeto é uma ilustração gráfica de um software, 
em que é possível demonstrar os relacionamentos entre os objetos, 
com seus respectivos valores e instanciamento. Com o diagrama de 
objeto, pode-se entregar uma visão estática e momentânea do funcio-
namento do sistema a ser desenvolvido.
Alguns profissionais podem achar difícil entender a diferença entre 
um diagrama de classes UML e um diagrama de objetos UML, pois 
ambos são compostos de “blocos retangulares” nomeados, com atri-
butos e ligações entre eles, que fazem com que os dois diagramas UML 
pareçam semelhantes. 
Além disso, algumas pessoas podem até pensar que eles são iguais, 
porque na ferramenta UML eles usam as notações para diagrama de 
classes e diagrama de objetos, que são colocadas dentro do mesmo 
editor de diagramas – diagrama de classes.
74 Engenharia de Software
O objeto é uma instância de uma classe, em um determinado mo-
mento no tempo de execução, que pode ter seu próprio estado e valores 
de dados. Da mesma forma, um diagrama de objeto, dentro dos conceitos 
da UML, pode ser considerado um instanciamento estático do software.
O diagrama de objetos mostra um instantâneo do estado detalhado 
de um sistema em um ponto no tempo; portanto, esse tipo de diagra-
ma engloba objetos e seus relacionamentos, que podem ser conside-
rados um caso especial de um diagrama de classes ou de um diagrama 
de comunicação (HASSAN, 2011).
O uso de diagramas de objetos é limitado, principalmente para 
mostrar exemplos de estruturas de dados.
Durante a fase de análise de um projeto, o engenheiro pode criar 
um diagrama de classes para descrever a estrutura de um sistema e, 
em seguida, criar um conjunto de diagramas de objetos, como teste 
para verificar a precisão e integridade do diagrama de classes.
Antes de criar um diagrama de classe, o profissional pode criar um 
diagrama de objeto, para descobrir fatos sobre elementos de mode-
los específicos e seus links ou para ilustrar exemplos específicos dos 
classificadores que são necessários.
Um diagrama de objetos mostra essa relação entre as classes 
instanciadas e a classe definida, bem como a relação entre esses obje-
tos no sistema. Ele é útil para explicar porções menores do seu sistema, 
quando o diagrama de classes é muito complexo, e, também, às vezes, 
para modelar relacionamentos recursivos no diagrama.
A seguir, destacamos alguns aspectos importantes do diagrama 
de objeto:
 • realiza ilustração estática estrutural das instâncias e dos objetos 
do software;
 • faz uso de uma notação que se assemelha à notação utilizada nos 
diagramas de classes;
 • demonstra de modo eficiente os relacionamentos entre as classes 
dentro do sistema;
 • ilustra as instâncias e os respectivos links entre elas de 
maneira estática; 
 • pode ser criado pelo engenheiro, instanciando os classificadores 
em diagramas de classe, implantação, componente e caso de uso.
UML – Unified Modeling Language 75
Com isso, podemos concluir que, com o diagrama de objetos, 
é possível demonstrar a todos os interessados os objetos com seus 
respectivos relacionamentos, para o pleno funcionamento do sistema 
a ser desenvolvido. 
4.6 Diagrama de sequência 
Vídeo
O diagrama de sequência modela a colaboração de objetos, com 
base em uma sequência de tempo. Assim, mostra como os objetos 
interagem uns com outros em um cenário particular de um caso de 
uso. Com a capacidade de modelagem visual avançada, o engenheiro 
pode criar diagramas de sequência complexos com poucos cliques.
Logo, os diagramas de sequência UML são diagramas de interação, 
que detalham como as operações são realizadas. Eles capturam a inte-
ração entre objetos no contexto de uma colaboração. 
Esse tipo de diagrama é focado no tempo e mostra a ordem da inte-
ração visualmente, usando o eixo vertical do diagrama para representar 
o tempo em que as mensagens são enviadas e quando.
Os diagramas de sequência capturam (WAZLAWICK, 2019):
 • a interação que ocorre em uma colaboração que realiza um caso 
de uso ou uma operação;• as interações de alto nível entre o usuário do sistema e o sistema, 
e entre o sistema e outros sistemas.
Esses diagramas possuem o objetivo de modelar:
 • a interação de alto nível entre objetos ativos em um sistema;
 • a interação entre instâncias de objeto em uma colaboração que 
realiza um caso de uso;
 • a interação entre objetos em uma colaboração que realiza 
uma operação;
 • tanto as interações genéricas do modelo, mostrando todos os 
caminhos possíveis por meio da interação, quanto as instâncias 
específicas de uma interação, mostrando apenas um caminho 
por meio da interação.
76 Engenharia de Software
Os diagramas de sequência mostram os elementos conforme eles 
interagem ao longo do tempo e são organizados de acordo com o obje-
to (horizontalmente) e o tempo (verticalmente).
No diagrama de sequência, o eixo horizontal mostra os elementos 
que estão envolvidos na interação. Convencionalmente, esses objetos 
envolvidos são listados da esquerda para a direita, de acordo com o 
momento em que participam da sequência de mensagens. No entanto, 
os elementos no eixo horizontal podem aparecer em qualquer ordem 
(HIRAMA, 2011).
O eixo vertical representa os processos de tempo (ou progresso) 
ao longo da página. O tempo em um diagrama de sequência tem tudo 
a ver com ordenação, e não com duração. O espaço vertical em um 
diagrama de interação não é relevante para a duração da interação.
Notação do diagrama de sequência
Para o diagrama de sequência, temos os seguintes componentes:
Figura 5
Ator
Fonte: Elaborada pelo autor.
Figura 6
Linha do tempo
Fonte: Elaborada pelo autor.
LifeLine
 • Ator
O ator é caracterizado por desempenhar determinada função 
dentro do sistema, ou seja, tem um protagonismo no software, 
recebendo e inserindo dados. Demonstra atuações humanas no 
processo.
Pessoas, empresas e outros sistemas podem ser considerados 
atores, isto é, tudo aquilo que, de alguma forma, interage com o 
software, inserindo, alterando, excluindo, consultando ou receben-
do informação.
 • Linha de vida
Uma linha de vida representa um participante individual na 
interação.
UML – Unified Modeling Language 77
Figura 7
Ativações
Fonte: Elaborada pelo autor.
LifeLine
Figura 8
Mensagem de chamada
Fonte: Elaborada pelo autor.
1: message
Figura 9
Mensagem de retorno
Fonte: Elaborada pelo autor.
1.1:
 • Ativações
Um retângulo fino, em uma linha de vida, representa o período 
durante o qual um elemento está executando uma operação. As 
partes superior e inferior do retângulo estão alinhadas com o 
tempo de iniciação e conclusão, respectivamente.
 • Mensagem de chamada
Uma mensagem define uma comunicação particular entre linhas de 
vida de uma interação.
A mensagem de chamada é um tipo de mensagem que representa 
uma chamada de operação da linha de vida de destino.
 • Mensagem de retorno
A mensagem de retorno é um tipo de mensagem que repre-
senta a passagem de informações de volta para o chamador de 
uma mensagem anterior correspondente.
• Automensagem
A própria mensagem é um tipo de mensagem que representa a 
invocação de mensagem da mesma linha de vida.
 • Mensagem recursiva
Mensagem recursiva é um tipo de mensagem que representa a 
invocação de mensagem da mesma linha de vida. Seu alvo aponta para 
uma ativação em cima da ativação de onde a mensagem foi invocada.
Figura 10
Automensagem
Fonte: Elaborada pelo autor.
1: message
Figura 11
Autorrecursiva
Fonte: Elaborada pelo autor.
1: message
78 Engenharia de Software
 • Criar mensagem
Criar mensagem é um tipo de mensagem que representa a 
instanciação da linha de vida (destino).
 • Mensagem de destruição
Mensagem de destruição é um tipo de mensagem que representa 
a solicitação de destruição do ciclo de vida da linha de vida de destino.
 • Mensagem de duração
A mensagem de duração mostra a distância entre dois instantes de 
tempo para uma chamada de mensagem.
• Observação
Uma nota (comentário) permite anexar várias observações aos ele-
mentos. Um comentário não carrega nenhuma força semântica, mas 
pode conter informações que são úteis para um modelador.
Figura 12
Criar mensagem
Fonte: Elaborada pelo autor.
1: message
LifeLine2
Figura 13
Mensagem de destruição
Fonte: Elaborada pelo autor.
1: message
Figura 14
Mensagem de duração
Fonte: Elaborada pelo autor.
1: message
Figura 15
Observação
Fonte: Elaborada pelo autor.
A seguir, há um exemplo genérico de diagrama de sequência.
Figura 16
Diagrama de sequência genérico
classe ator
1: evento
2: operação 3: operação (lista parâmetros)
4: operação (lista de parâmetros)
Nome ator:
objeto 1:
nome da classe objeto2 :nome da classe
Fonte: Elaborada pelo autor.
UML – Unified Modeling Language 79
Em seguida, apresentamos mais um exemplo. Nesse caso, trazemos 
o diagrama de sequência para um processo genérico de um cadastro 
de alunos. A ilustração mostra como ator o aluno, que é quem detém 
as informações que serão inseridas no sistema.
É possível observar que temos quatro linhas de tempo identificadas 
como interface do sistema com o ator; depois, a interface do sistema 
com o banco de dados e, então, o próprio banco de dados.
Para conectar as linhas do tempo, foram inseridas as trocas de da-
dos, como “inclui dados cadastrais do aluno”, “validação dos campos 
inseridos” e outros, que demonstram como os dados são socializados 
entre as linhas do tempo.
Figura 17
Diagrama de sequência: cadastro de alunos
Aluno Interface do sistema com o ator
Interface do sistema 
com o banco de dados Banco de dados
Fonte: Elaborada pelo autor.
Inclui dados cadastrais 
do aluno
Correção dos dados
Mensagem de erro ou de 
aluno já cadastrado
Mensagem de finalização 
do processo
Validação dos campos 
inseridos
Correção dos campos
Mensagem de erro ou de 
aluno já cadastrado
Mensagem de finalização 
do processo
Acesso ao banco de 
dados para a gravação 
dos dados
Gravação dos dados 
corrigidos
Mensagem de erro ou de 
aluno já cadastrado
Mensagem de finalização 
do processo
No livro UML 2: uma 
abordagem prática, 
você vai poder explorar 
diversos estudos de caso 
modelados e demonstra-
dos com exemplos 
práticos, com os diversos 
diagramas que estuda-
mos neste capítulo.
Além dos exemplos, a 
obra apresenta exercícios 
para que os leitores 
possam aferir os conhe-
cimentos absorvidos 
durante a leitura. É indi-
cado para profissionais 
iniciantes e experientes, 
sendo um ótimo livro de 
cabeceiras para os enge-
nheiros de softwares. 
GUEDES, G. T. A. São Paulo: Novatec, 
2018.
Livro
CONCLUSÃO
Neste capítulo foi possível compreender como os diagramas UML são 
essenciais para a construção de um software. Eles devem ser usados pe-
los engenheiros de softwares antes de começarem a codificar; ainda, os 
diagramas UML podem ajudar todos a estarem na mesma página. 
Compreender o sistema que eles estão tentando criar permite que 
os desenvolvedores deleguem trabalho, identifiquem problemas em po-
80 Engenharia de Software
tencial antes do início desse trabalho e trabalhem com eficiência, em prol 
de um objetivo comum.
Foi possível entender, ainda, a importância da UML também após a 
codificação do software. Depois que o código é escrito, um diagrama UML 
pode ajudar os desenvolvedores a entender as decisões tomadas e as 
estruturas desenvolvidas para o projeto. Essas informações auxiliam as 
equipes na busca por melhorias no projeto para o futuro.
ATIVIDADES
Atividade 1
Dentro do ecossistema do UML, temos vários diagramas que 
colaboram integralmente na construção de softwares. Nesse 
sentido, você deve se colocar como um engenheiro de softwares 
de uma grande empresa e desenvolver um documento de no 
máximo duas páginas, que ilustre de maneira resumida as dife-
renças entre os seguintes diagramas:
a) Diagrama de atividades
b) Diagrama de classe
c) Diagrama de objetos
d) Diagrama de sequência
Atividade 2
Nesta atividade, a missão é compreender a figura deste livro, 
chamada Diagrama de atividades: elaborando um texto, dentroda 
Seção 4.3, e transformá-la para atender a um processo de login 
em um aplicativo comum, como o Facebook ou Instagram. 
Imagine o passo a passo que você executa para acessar sua rede 
social preferida. Para tanto, você pode usar qualquer software 
que tenha mais facilidade ou pegar um lápis e folha de papel e 
soltar sua criatividade.
REFERÊNCIAS 
HASSAN, G. Software modeling and design: UML, use cases, patterns and software 
architectures. Cambridge: Cambridge University Press, 2011.
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. Rio de 
Janeiro: Elsevier, 2011.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: 
AMGH, 2016.
WAZLAWICK, R. Engenharia de software: conceitos e práticas. São Paulo: GEN LTC, 2019.
Diagrama de caso de uso 81
 5
Diagrama de caso de uso
 Ao final do estudo deste capítulo, você será capaz de:
• implementar diagramas de caso de uso;
• esboçar e interpretar o conceito dos elementos do modelo de 
caso de uso;
• interpretar e utilizar cenário e atores;
• estabelecer relacionamentos, associações e generalização.
Objetivos de aprendizagem
O diagrama de caso de uso é uma das principais ferramentas para o 
engenheiro de software, e com ela é possível trazer todos os interessa-
dos para um mesmo ponto de entendimento do sistema computacio-
nal que será desenvolvido.
O diagrama de caso de uso tem a característica que o difere dos demais 
diagramas: ele pode ser compreendido por todos os envolvidos, desde 
pessoas sem conhecimentos técnicos até desenvolvedores experientes.
Podemos afirmar que esse diagrama estabelece um protocolo de co-
municação perfeito entre os interlocuto-
res; com isso, a eficiência na construção 
do software aumenta significativamente.
O modelo de caso de uso contempla 
três objetivos: descrever a necessidade 
do cliente, estabelecer a base do sistema 
a ser implementado e definir um con-
junto de requisitos que possam ser va-
lidados quando o projeto for construído 
(IAN, 2011). 
Figura 1
Modelo de caso de uso
Fonte: Elaborada pelo autor.
Modelo de 
caso de uso
Requisitos 
definidos
Sistema a ser 
implementado
Necessidade 
do cliente
82 Engenharia de Software
Ou seja:
 • Necessidade do cliente: consenso de ideias.
 • Requisitos definidos: o que o sistema deverá fazer.
 • Sistema a ser implementado: desenvolvimento deve ser de acor-
do com as necessidades do cliente.
Neste capítulo iremos explorar o desenvolvimento dos diagramas 
de caso de uso e seus componentes.
5.1 Diagrama de caso de uso
Vídeo
O modelo de casos de uso é uma forma de representação gráfica das 
funcionalidades possível de detectar no sistema, antes de seu desenvol-
vimento, junto a todas as entidades externas que trocam informações.
Além disso, esse modelo detalha os chamados requisitos funcionais 
de um sistema levando em consideração a visão do usuário, e assim os 
desenvolvedores podem ter a certeza de que os usuários serão atendi-
dos plenamente.
Sua construção desse modelo relaciona todas as funções do siste-
ma, seu ambiente de processamento, usuários e seus respectivos pa-
péis dentro da operação do software.
De acordo com Hassan (2011), o diagrama de caso de uso especifica 
uma ordem precisa das ações que o sistema irá desempenhar, bem 
como o resultado esperado.
É importante ressaltar que o caso de uso não representa um passo 
ou uma etapa em uma funcionalidade do sistema; ele é a especificação 
detalhada de uma das funcionalidades.
O modelo de caso de uso é elaborado durante as reuniões entre 
todos os envolvidos no desenvolvimento, desde a equipe técnica até 
usuários leigos, pois somente assim se assegura que a solução será 
entregue conforme as necessidades dos usuários e não como os ana-
listas desejam.
De posse dos relatos dos envolvidos, os engenheiros iniciam a mon-
tagem de uma ilustração, seguindo premissas e padrões para que o sis-
tema seja visualizado em um formato agradável e intuitivo. Com isso, 
o tempo que se leva para traduzir códigos, por exemplo, é poupado.
Diagrama de caso de uso 83
Podemos afirmar que o diagrama de caso de uso deixa a relação en-
tre a pessoas envolvidas no desenvolvimento do software muito mais 
harmônica e produtiva (SOMMERVILLE, 2011).
5.2 Cenário
Vídeo
De acordo com Pressman (2016), conforme os requisitos são levan-
tados, uma visão geral sobre as características e funções do sistema 
começa a se concretizar. No entanto, é difícil entender como essas ca-
racterísticas e funções serão usadas por diferentes usuários. Para isso, 
é possível criar um conjunto de cenários que identifique um roteiro de 
uso para o sistema a ser desenvolvido.
Um cenário é a ilustração do ambiente no qual o sistema irá operar. 
Ele representa a ordem com que as interações entre os usuários e o sis-
tema acontece, desde a entrada de dados até a saída esperada, sempre 
visando resolver um problema.
O cenário do diagrama de caso de uso pode ser comparado ao de 
um filme, desenho ou um game, e descreve em qual ambiente o siste-
ma irá operar com suas características.
A seguir, ilustramos um cenário de um ambiente que comercializa 
laranjas, em que temos como ator o cliente que irá realizar a compra 
informando a quantidade e fazendo o pagamento.
Quadro 1
Cenário – venda de laranjas
Item Descrição
Caso de uso Comprar laranjas
Ator Cliente
Pré-condição Ter estoque disponível
Pós-condição Registrar a compra
Fluxo principal
O cliente seleciona o produto e a quantidade, o sistema 
verifica o estoque e calcula o valor a pagar
Fluxo alternativo
O cliente pode alterar a quantidade antes de fechar a 
 compra
Fluxo exceção Cartão de crédito inválido
Fonte: Elaborado pelo autor.
Conheceremos, a seguir, o conceito de ator, que tem papel fundamen-
tal nos cenários que serão criados para o desenvolvimento de softwares.
84 Engenharia de Software
5.3 Ator 
Vídeo Os atores são todos aqueles que inserem ou recebem informação 
do sistema. Podemos encontrar atores seres humanos específicos, por 
exemplo, o presidente da empresa, e até grupos de pessoas, como 
vendedores.
Empresas também podem ser atores; seguindo o mesmo raciocínio 
que tivemos com as pessoas, podemos ter empresas específicas, como 
a Receita Federal, ou grupo de empresas, por exemplo, fornecedores 
de matéria-prima.
Um outro sistema também pode ser um ator. Imagine um sistema 
contábil que recebe informação de um sistema de vendas. Esse sistema 
contábil será ator no cenário de funcionamento do sistema de vendas 
e vice-versa, ou seja, o sistema de vendas será ator no cenário de fun-
cionamento do sistema contábil.
Uma boa dica para encontrarmos os atores é fazer algumas pergun-
tas, como (HASSAN, 2011):
 • Quem usa o sistema?
 • Quem inicializa o sistema?
 • Quem fornece os dados?
 • Quem remove os dados?
 • Quem usa as informações?
 • Quem autoriza a venda?
 • Quem tem a senha do administrador?
Com as respostas para essas perguntas, o analista tem os atores 
que interagem com o sistema; depois disso, o próximo passo é tentar 
agrupar os atores, se possível. O agrupamento de atores somente é 
realizável quando os agrupados recebem e inserem as mesmas infor-
mações – se houver alguma divergência, eles devem ficar desagrupados.
Imagine um time de vendedores no qual um deles tem a função 
de inserir a senha de liberação de crédito. Nesse caso, teremos o ator 
“vendedores” e outro ator “vendedor detentor da senha de liberação 
de crédito”.
Agora vamos entender como os atores se relacionam no cenário do 
sistema.
Diagrama de caso de uso 85
5.4 Relacionamentos 
Vídeo O estabelecimento de relacionamentos entre os elementos dos 
casos de uso permite a reutilização daqueles casos de uso que preci-
sam ser definidos repetidamente, e isso reduz os esforços dos desen-
volvedores. Nos casos de uso, podemos utilizar os seguintes tipos de 
relacionamentos:
 • incluir;
 • estender;
 • generalizar.
Incluir
O relacionamento de inclusão é utilizado entre os casos de uso 
quandoum componente inclui a sequência de métodos e funções de 
outro componente. Os casos de uso que precisam ser descritos repeti-
damente para um sistema complexo ou grande são modelados uma vez 
e incluídos nos demais casos de uso, quando necessário (WAZLAWICK, 
2019).
Incluir, nos cenários de casos de uso, é semelhante a sub-rotinas, 
pois corresponde ao conjunto de instruções usadas repetidamente no 
programa, mas esse conjunto de instruções é escrito apenas uma vez 
e é chamado sempre que necessário. A inclusão pode ou não aparecer 
como uma sequência de comportamento por conta própria.
Vamos prosseguir com um outro exemplo para ajudar no entendi-
mento dos relacionamentos de inclusão entre os componentes de um 
caso de uso. Considere um sistema de corretagem de ações on-line que 
envolve vários casos de uso, sendo três deles “sessão segura”, “fazer 
uma negociação” e “validar a senha”.
Sempre que um usuário estabelece uma sessão segura, ela inclui a 
validação de senhas; e sempre que o usuário faz uma negociação com 
ações, as senhas são validadas.
Assim, a sessão segura de casos de uso inclui o caso de uso “validar 
senha” e, da mesma forma, fazer um caso de uso de troca também in-
clui o caso de uso de validação de senha. Com isso, observamos que a 
86 Engenharia de Software
senha de validação de caso de uso é usada repetidamente por outros 
casos de uso e modelada apenas uma vez.
O relacionamento de inclusão é apresentado, dentro dos casos de 
uso, com uma seta tracejada nos diagramas que representam o siste-
ma a ser desenvolvido. A ponta da seta está apontando para o caso de 
uso incluído, enquanto a seta tracejada é sempre anotada pela palavra-
-chave << include >> para mostrar a relação de inclusão.
Estender
Estender relacionamento adiciona a sequência de comportamento 
ao caso de uso padrão. É semelhante ao relacionamento de inclusão, 
mas a direção de adição da sequência de comportamento ao caso de 
uso base é oposta.
Nos relacionamentos com relacionamento de inclusão, os compo-
nentes do caso de uso base incorporam os componentes do caso de 
uso a ser incluído. Porém, no relacionamento de extensão, o caso de 
uso estendido adiciona sua sequência de comportamento ao caso de 
uso base (WAZLAWICK, 2019).
Se observarmos os relacionamentos “incluir” e “estendido”, ambos 
adicionam a sequência de comportamento ao caso de uso base. Esse é 
o cenário em que inicialmente os elementos básicos são modelados e, 
em seguida, os recursos avançados são adicionados à base.
Imagine um sistema de corretagem de ações que possui um caso 
de uso de ações comerciais, o que permite ao cliente comprar as ações 
com o dinheiro da conta corrente. E se o cliente tiver saldo insuficiente 
em sua conta, mas ainda assim ele desejar comprar o estoque, temos 
que “estender” o relacionamento do caso de uso.
Para essa situação, o sistema de corretagem de valores adiciona 
um recurso ou extensão – negociação de margem –, que permite ao 
cliente tomar um empréstimo para comprar as ações. Esse recurso é 
adicionado ao caso de uso base quando o custo de compra do estoque 
é verificado com relação ao saldo disponível na conta do cliente. Nesse 
momento, verifica-se que o saldo é insuficiente para comprar o estoque.
O relacionamento de extensão na notação UML é representado 
com a seta tracejada. A ponta da seta aponta para o caso de uso base. 
Essa seta tracejada é anotada pela palavra-chave << extend >>.
Diagrama de caso de uso 87
Generalização
Generalização é o termo mais comum em computadores. Na gene-
ralização existe uma classe pai que consiste em atributos e operações 
comuns, e a classe filha contém os atributos e operações particulares 
(WAZLAWICK, 2019).
Análogo à generalização em classes, há um conceito de generalização 
no relacionamento de caso de uso. O caso de uso pai contém a sequên-
cia de comportamento comum, e o caso de uso filho contém os recursos 
particulares. A generalização no caso de uso é representada com a seta 
triangular onde a ponta da seta indica para o caso de uso pai.
Agora que já conhecemos os relacionamentos, vamos aos casos 
práticos.
5.5 Caso prático 
Vídeo Para iniciarmos um caso prático de diagrama de caso de uso, vale 
seguir os seguintes passos:
• Contextualize as necessidades do sistema.
Etapa 1
• Identifique os atores.
• Identifique os casos de usos com seus respectivos cenários.
• Identifique os relacionamentos entre os atores e os casos de usos.
• Identifique os relacionamentos entre os atores, se houver.
• Desenvolva o caso de uso.
Etapa 2
• Documentação do caso de uso.
Etapa 3
Com essas etapas cumpridas, só nos resta desenvolver o Modelo 
Entidade Relacionamento (MER) para que o sistema posso ser codifica-
do, testado e implementado.
88 Engenharia de Software
Vale ressaltar que, além da modelagem gráfica, o diagrama de caso 
de uso deve apresentar a especificação de detalhamento do diagrama 
de caso de uso. Essa descrição também é conhecida por documentação 
de caso de uso.
Antes de entrarmos no caso do aplicativo voltado para o health tech, 
vamos imaginar um cenário de um e-commerce de sucos naturais. O 
cliente entra no site da loja “Amantes de Sucos Naturais” e pesquisa os 
tipos de sucos desejados; seleciona as frutas, a base, complementos, e 
o sistema deve exibir os dados da pesquisa em até três segundos.
Para efetuar o pedido de compra, o cliente seleciona o suco e infor-
ma a quantidade desejada. O sistema calcula o preço total e o apresen-
ta ao usuário.
Para finalizar a compra, o cliente preenche o cadastro, caso não o 
possua; preenche o campo “Dados do cliente”, informando nome, en-
dereço de entrega, telefone e CPF. Os dados devem ser armazenados 
em banco de dados para futuras compras.
Então o cliente efetua o pagamento. Para isso, seleciona a forma 
como o fará. Se o pagamento for por cartão de crédito, o cliente in-
forma os dados do cartão: número, data de validade, nome, nome da 
operadora do cartão de crédito e o código de segurança. O sistema 
deve solicitar a autorização do pagamento para a operadora do cartão 
de crédito. Se o pagamento for por boleto, o sistema o emite.
O funcionário, gerente do setor financeiro, efetua o login com a se-
nha de administrador, consulta os pagamentos e, se confirmar o paga-
mento, emite a nota fiscal.
O funcionário separa e envia os produtos para a transportadora que 
fará a entrega. Ao encaminhá-los, o funcionário registra o envio do pe-
dido para entrega, informa o status do pedido – enviado para entrega, 
por exemplo.
Ao receber os produtos, o cliente assina a nota de entrega. A nota 
de entrega possui um QR Code que identifica o pedido efetuado pelo 
cliente; por meio desse código, o funcionário efetua a baixa do pedido 
caso haja a assinatura do cliente e a data de entrega.
Iniciamos identificando os atores envolvidos nesse cenário.
Então, quem são os atores?
 • Cliente
Fonte: Elaborada pelo autor.
Figura 2
 Ator do cenário
Quem pode interagir com 
um e-commerce de sucos 
naturais?
Ator representa um papel 
que usuários, sistema 
externo, hardware ou dis-
positivos desempenham 
à medida que interagem 
com o sistema.
Dica
Diagrama de caso de uso 89
 • Gerente
 • Funcionário
 • Operadora do cartão de crédito
Agora vamos identificar os casos de uso envolvidos nesse cenário. 
A seguir, temos alguns casos do sistema de e-commerce. Você poderá 
identificar outros, caso queira.
Caso de uso Pesquisar sabores de sucos naturais
Ator Cliente
Objetivo Pesquisar os tipos de suco desejados
Caso de uso Efetuar compra
Ator Cliente
Objetivo Registrar o pedido de compra
Caso de uso Calcular valor da compra
Ator secundário Ação executada pelo sistema e desencadeada pelo 
usuário
Objetivo Ativar o sistema a fim de calcular o preço total da compra 
quando o cliente seleciona os sucos e as quantidades
Caso de uso Cadastrar cliente
Ator Cliente
Objetivo Efetuar o cadastro dos dados do cliente na base de 
dados
Caso de uso Registrar pagamento
Ator Cliente
Objetivo Registraro pagamento da compra
Caso de uso Solicitar autorização do pagamento
Ator secundário Sistema e sistema externo da operadora do cartão de 
crédito
Objetivo Solicitar a autorização do pagamento para a operadora 
do cartão de crédito quando o cliente informa os dados 
do cartão
Caso de uso Emitir boleto
Ator secundário Ação executada pelo sistema desencadeada pelo 
usuário
90 Engenharia de Software
Objetivo Ativar o sistema para emitir o boleto quando o cliente 
seleciona a forma de pagamento: boleto
Caso de uso Efetuar login
Ator secundário Gerente financeiro
Objetivo Validar a senha para efetuar o login
Caso de uso Consultar pagamento
Ator secundário Gerente financeiro
Objetivo Consultar os pagamentos
Caso de uso Emitir nota fiscal
Ator secundário Gerente financeiro
Objetivo Emitir o boleto após o gerente financeiro consultar o 
registro do pagamento
Caso de uso Registrar pedido para entrega
Ator secundário Funcionário
Objetivo Registrar o pedido de entrega a fim de atualizar o status 
do pedido
Caso de uso Caso de uso: baixar pedido de compra
Ator secundário Funcionário
Objetivo Baixar o pedido de compra após a confirmação de 
entrega
Com base nos casos levantados, seguimos para a identificação dos 
relacionamentos envolvidos nesse cenário.
Deve-se analisar se todo ator tem, no mínimo, uma associação com 
um caso de uso e se todo caso de uso interage com algum ator ou com 
outro caso de uso.
Agora, vamos identificar os relacionamentos entre os casos de usos, 
se houver.
Deve-se verificar se existe a necessidade do relacionamento de in-
clusão, extensão ou generalização. Em seguida, deve-se identificar os 
relacionamentos entre os atores, se houver.
É preciso verificar se existe a necessidade do relacionamento de ge-
neralização entre os atores.
Após todos esses levantamentos, chegamos à seguinte solução:
O relacionamento indica 
quem solicita, quem exe-
cuta e como será executa-
da uma funcionalidade.
Dica
Diagrama de caso de uso 91
Pesquisar tipos de 
sucos
Calcular valor da 
compra
Registrar compra Cadastrar cliente
Registrar 
pagamento
Solicitar 
autorização de 
pagamento
<<includes>>
<<extend>>
<<extend>>
<<extend>>
funcionário
Operadora 
de cartão de 
crédito
Gerente
Cliente
Consultar 
pagamento Emitir Nota Fiscal
Efetuar Login Emitir boleto
Registrar pedido 
de entrega
Baixar pedido de 
compra
Figura 3
Modelagem de e-commerce de sucos naturais
Fonte: Elaborada pelo autor.
Como segundo exemplo, usaremos a aplicação em health tech 
objetivando cuidar mais da saúde e menos da doença. Vamos propor 
uma solução de como a tecnologia pode ajudar as pessoas na preven-
ção de doenças. 
Para isso, vamos usar as três etapas citadas anteriormente.
• Contextualize as necessidades do sistema.
Etapa 1
<<extend>>
92 Engenharia de Software
• Identifique os atores.
• Identifique os casos de usos com seus respectivos cenários.
• Identifique os relacionamentos entre os atores e os casos de usos.
• Identifique os relacionamentos entre os atores, se houver.
• Desenvolva o caso de uso.
Etapa 2
• Documentação do caso de uso.
Etapa 3
Vamos à solução!
Etapa 1: Contextualize as necessidades do sistema
O aplicativo health tech virá para atender a uma grande demanda 
de usuários que buscam aumentar sua qualidade de vida, cuidando 
mais da saúde e menos da doença. A tecnologia pode ser uma grande 
aliada para que se possa monitorar o estado clínico das pessoas.
O aplicativo irá colaborar com o monitoramento dos biossinais, aler-
tando o paciente e o médico quando algo estiver fora do padrão, bem 
como irá colaborar indicando uma dieta balanceada e atividades físicas 
indicadas para que cada paciente tenha uma vida saudável.
Etapa 2: Diagrama de caso de uso
Fonte: Elaborada pelo autor com o software Astah.
Administrador do 
aplicativo
Módulo de parametrização e 
administração do aplicativo
Login/cadastro de usuários/
parametrização do sistema
Controle dos exercícios físicos
Monitoramento 
de biossinais
Controle da dieta do paciente
Alerta de alterações clínicas
UsuárioMédico
Health Track
<<Include>>
<<Include>>
<<Include>>
Figura 4
Diagrama de caso de uso do HealthTech
Diagrama de caso de uso 93
Etapa 3: Documentação do caso de uso
Quadro 2
Módulo de parametrização e administração do aplicativo
Documentação de caso de uso
Título do caso de uso Módulo de parametrização e administração do aplicativo
Código identificado HT01
Sumário
Este módulo será responsável por toda a parametrização dos aplicativo. Nele, o administra-
do do sistema poderá inserir diversas informações para o pleno funcionamento da aplica-
ção, como: quantidade de vezes que o usuário poderá erra a senha, cadastro de usuários, 
formato das mensagens de alertas, reset de senha e usuários, entre outras.
Ator primário Administrador do sistema
Ator secundário
Pré-condição Login e senha de Admin
Fluxo principal
Ator Sistema
FP01 – Administrador 
seleciona botão de pa-
rametrização
FP02 – Solicitar credenciais para acessar como administrador
FP02 – Administrador 
insere todos os parâ-
metros
FP04 – Receber e armazenar as parametrizações do administrador do sistema
Fluxo Alternativo
FA01 Administrador não possui as credenciais necessárias para o acesso
FA02 Aplicativo sem acesso à internet – Mensagem de erro
FA03 Gravação dos parâmetros com sucesso
Regras do negócio
RN01 O administrador deve ter a senha do Admin
Sem a senha do Admin, o acesso não deve ser permitido
Fonte: Elaborada pelo autor.
Quadro 3
Login / Cadastro de usuários / Parametrização do sistema
Documentação de caso de uso
Título do caso de uso Login / Cadastro de usuários / Parametrização do sistema
Código identificado HT02
Sumário
Deverá fazer o login e o controle de usuários validando login e senha. Além disso, 
faz a leitura do módulo de parametrização para que a aplicação funcione perfei-
tamente
Ator primário Usuários do aplicativo
Ator secundário Médico
Pré-condição
(Continua)
94 Engenharia de Software
Documentação de caso de uso
Fluxo principal
Ator Sistema
FP05 – Usuários do aplicativo 
realizam o cadastro para obter as 
credenciais de acesso
FP07 – Solicitar credenciais para o acesso do usuário
FP06 – Usuários do aplicativo 
realizam o cadastro para obter as 
credenciais de acesso
FP08 – Solicitar credenciais para o acesso do médico
Fluxo Alternativo
FA04 Usuário não tem as credenciais de acesso
FA05 Médico não tem as credenciais de acesso
Regras do negócio
RN02 Usuário e médico necessitam ter as credenciais para acessar o sistema
Fonte: Elaborada pelo autor.
Quadro 4
Monitoramento de Bio Sinais
Documentação de caso de uso
Título do caso de uso Monitoramento de biossinais
Código identificado HT03
Sumário
Receberá os biossinais do paciente, bem como, quando autorizado, os parâmetros do 
médico. Com essas informações, criará condições para alertas ou não de alterações cli-
nicas. Com essa função, o médico poderá ter um “filme” de todo o estado clínico do 
paciente e não somente uma “foto” como acontece nas consultas presenciais.
Ator Primário Usuários
Ator Secundário Médicos
Pré-condição Login e senha válidos
Fluxo principal
Ator Sistema
FP09 – Usuários do apli-
cativo fornecem a ele os 
biossinais por meio do ce-
lular ou smartwatch
FP11 – Recebe de maneira ininterrupta os biossinais para armazenamento e utilização 
posterior
FP10 – Informa anomalias 
ao sistema de alertas
FP12 – Se os biossinais estiverem em desacordo com os parâmetros do médico, o sinal 
de alerta deve ser disparado para o médico e para o usuário
Fluxo Alternativo
Não há
Regras do negócio
RN03
Se os biossinais estiverem em desacordo com os parâmetros informados pelo médico, o 
sinal de alerta deve ser disparado.
Fonte: Elaborada pelo autor.
Diagrama de caso de uso 95
Quadro 5
Alerta de alterações clínicas
Documentação de caso de uso
Título do caso de uso Alerta de alterações clínicas
Código identificado HT04
Sumário
Caso o monitoramento de biossinais detecte algumaanomalia comparando-se com a para-
metrização do médico, um sinal de alerta é enviado ao usuário e ao médico quando autori-
zado pelo usuário.
Ator primário Monitoramento de biossinais
Ator secundário Usuário e médico
Pré-condição Input do monitoramento de biossinais
Fluxo principal
Ator Sistema
FP13 – Usuários do 
aplicativo recebem 
alerta de emergência
FP15 – Sistema informa ao usuário sinal de emergência e sua gravidade
FP14 – Médico recebe 
alerta de emergência 
do paciente
FP16 – Sistema informa ao médico sinal de emergência e sua gravidade
Fluxo Alternativo
FA06
Caso o usuário e/ou médico não confirmem o recebimento do alerta, um alerta especial 
deve ser enviado ao administrador do aplicativo 
Regras do negócio
RN04
Se os biossinais estiverem em desacordo com os parâmetros informados pelo médico, o 
sinal de alerta deve ser disparado
Fonte: Elaborada pelo autor.
Quadro 6
Controle de dieta do paciente
Documentação de caso de uso
Título do caso de uso Controle de dieta do paciente
Código identificado HT05
Sumário
Por meio das informações do médico e do paciente, uma dieta balanceada é 
apresentada ao paciente todos os dias
Ator primário Usuário
Ator secundário Médico
Pré-condição Parametrização por parte do usuário e do médico
Fluxo principal
Ator Sistema
(Continua)
96 Engenharia de Software
Documentação de caso de uso
FP17 – Usuários do aplicativo rece-
bem dieta adequada
FP19 – Sistema informa ao usuário dieta adequada
FP18 – Médico informa parâmetros 
para a dieta adequada ao paciente
FP20 – Médico informa dieta adequada ao paciente
Fluxo Alternativo
FA07 Aceite do usuário quanto a dieta
FA08 Aplicativo solicita ao médico dieta caso não tenha enviado
Regras do negócio
RN04 As dietas precisam ser informadas e validadas pelo médico do paciente
Fonte: Elaborada pelo autor.
Quadro 7
Controle dos exercícios físicos
Documentação de caso de uso
Título do caso de uso Controle dos exercícios físicos
Código identificado HT06
Sumário
Por meio das informações do médico e do paciente, uma sequência de 
exercícios físicos é apresentada ao paciente todos os dias
Ator Primário Usuário
Ator Secundário Médico
Pré-condição Parametrização por parte do usuário e médico
Fluxo principal
Ator Sistema
FP21 – Usuários do aplicativo recebem 
sequência de exercícios adequada
FP23 – Sistema informa ao usuário a sequência de exercícios
FP22 – Médico informa parâmetros para 
a sequência de exercícios ao paciente
FP24 – Médico informa sequência de exercícios para o paciente
Fluxo Alternativo
FA07 Aceite do usuário quanto aos exercícios
FA08
Aplicativo solicita ao médico sequência de exercícios caso não tenha en-
viado
Regras do negócio
RN04
Os exercícios precisam ser informados e validados pelo médico do pa-
ciente
Fonte: Elaborada pelo autor.
Como foi citado, para complementarmos a documentação do siste-
ma para seu desenvolvimento, falta apenas a modelagem dimensional 
do data mart da aplicação em health tech, ou seja, vamos apresentar o 
MER – Modelo Entidade Relacionamento do sistema.
Diagrama de caso de uso 97
Figura 5
MER – Modelo Entidade Relacionamento do sistema do health tech
Dimensão: Paciente
ID_Paciente
Paciente_nome
Paciente_endereço
Paciente_email
Paciente_convenio
Paciente_celular
Paciente_senha
Tabela Fato: Login
ID_usuario (médico ou 
paciente)
Data
Hora
Dimensão: Medico
ID_medico
Medico_nome
Medico_endereco
Medico_email
Medico_especialidade
Medico_celular
Medico_senha
Tabela Fato:
Dieta_Paciente
ID_dieta
ID_paciente
ID_medico
Data_inicio
Data_termino
Tabela Fato:
Monitoramento
ID_Bio
ID_paciente
Data
Hora
Medicao
Tabela Fato:
Atividade_Paciente
ID_atividade
ID_paciente
ID_medico
Data_inicio
Data_termino
Dimensão: Dieta
ID_dieta
dieta_nome
dieta_calorias
dieta_procedimento
dieta_lista_de_alimentos
Dimensão: Bio_sinais
ID_Bio
Bio_descricao
Bio_medicao maxima
Bio_medicao minima
Bio_importancia
Dimensão:
Atividades_Fisicas
ID_atividade
atividade_nome
atividade_calorias
atividade_procedimento
FK FK FK
FK
FK
FK
FK
FK
PK
PK
PK
PK
PK
Fonte: Elaborado pelo autor.
Complementando o Modelo Entidade Relacionamento, temos a 
descrição das dimensões: 
Dimensão Paciente
ID_Paciente Chave primária de paciente, será armazenado um código único para cada paciente
Paciente_nome Será armazenado o nome do paciente
Paciente_endereco Será armazenado o endereço do paciente
Paciente_email Será armazenado o e-mail do paciente
Paciente_convenio Será armazenado o convênio do paciente
Paciente_celular Será armazenado o celular do paciente
Paciente_senha Será armazenada a senha do paciente
Dimensão Médico
ID_medico Chave primária de médico, será armazenado um código único para cada médico
Medico_nome Será armazenado o nome do médico
Medico_endereco Será armazenado o endereço do médico
Medico_email Será armazenado o e-mail do médico
Medico_especialidade Será armazenada a especialidade do médico
Medico_celular Será armazenado o celular do médico
Medico_senha Será armazenada a senha do médico
98 Engenharia de Software
Dimensão Dieta
ID_dieta Chave primária de dieta, será armazenado um código único para cada dieta
dieta_nome Será armazenado o nome da dieta
dieta_calorias Será armazenada a quantidade de calorias da dieta
dieta_procedimento Será armazenado o procedimento para a dieta
dieta_lista_de_alimentos Será armazenada a lista de alimentos da dieta
Dimensão Biossinais
ID_Bio Chave primária de biossinais, será armazenado um código único para biossinal
Bio_descricao Será armazenada a descrição do biossinal
Bio_medicao maxima Será armazenado o limite máximo do biossinal
Bio_medicao minima Será armazenado o limite mínimo do biossinal
Bio_importancia Será armazenada a importância do biossinal
Dimensão Atividades_Físicas
ID_atividade
Chave primária das Atividades Físicas, será armazenado um código único para 
cada atividade física
atividade_nome Será armazenado o nome da atividade física
atividade_calorias Será armazenada a quantidade de calorias gastas com a atividade física
atividade_procedimento Será armazenado o procedimento para executar as atividades físicas
Tabela fato Dieta_Paciente
ID_dieta Chave primária da dieta
ID_paciente Chave primária do paciente
ID_medico Chave primária do médico
Data_inicio Data de início da dieta
Data_termino Data de término da dieta
Tabela Fato Monitoramento
ID_Bio Chave primária de bio sinais
ID_paciente Chave primária do paciente
Data Data do monitoramento
Hora Hora do monitoramento
Medicao Medição do monitoramento
Tabela Fato Atividade_Paciente
ID_atividade Chave primária de atividade física
ID_paciente Chave primária do paciente
ID_medico Chave primária do médico
Data_inicio Data de início da atividade física
Data_termino Data de término da atividade física
Diagrama de caso de uso 99
Informações úteis para o usuário paciente
Consultar suas dietas
Consultar suas atividades físicas
Consultar os resultados de suas medições de biossinais
Informações para o usuário médico
Inserir dietas ao paciente
Inserir atividades físicas ao paciente
Analisar os biossinais dos pacientes
Questões de negócio
Quantos usuários do perfil Médicos estão cadastros no aplicativo?
Quantos usuários do perfil Paciente estão cadastros no aplicativo?
Qual é o índice de utilização do aplicativo por parte dos médicos?
Qual é o índice de utilização do aplicativo por parte dos pacientes?
Qual é o índice de cadastros cancelados do perfil Paciente?
Qual é o índice de cadastros cancelados do perfil Médico?
Qual é o índice de cadastros cancelados de todos os perfis?
Quantos monitoramentos de biossinais são analisados?
Quantos novos pacientes entram no aplicativo por mês?
Quantos novos médicos acessam o aplicativo por mês?
Com essas perguntas, é possível entender as questões do negócio 
para que a modelagem tenha êxito atendendo a todas as expectativas 
do cliente.
Nesta indicação temos 
uma abordagem prática 
do uso do UML na cons-
trução de softwares. São 
apresentados exemplospráticos de como o enge-
nheiro pode iniciar suas 
primeiras modelagens de 
sistemas computacionais.
O mapeamento das 
classes é bem prático e 
objetivo, levando ao leitor 
a uma grande viagem 
dentro da engenharia 
de software sem haver 
descuidos quanto aos 
conceitos essenciais, 
principalmente a genera-
lização, tão importante na 
otimização dos códigos.
LIMA, A. S. G. UML 2.5: do requisito 
à solução. São Paulo: Érica, 2014.
Livro
CONCLUSÃO
Neste capítulo foi possível compreender e interpretar diagramas de 
caso de uso e como eles são importantes na construção de softwares, 
apresentando a todos os envolvidos ilustrações que posteriormente irão 
se tornar códigos executáveis.
Pudemos também entender o papel de cada componente dentro dos 
cenários onde irão operar o sistema; vimos como ator, relacionamentos e 
cenários se fundem em um só projeto para dar vida aos sistemas.
100 Engenharia de Software
ATIVIDADES
Atividade 1
O diagrama de caso de uso é uma das principais ferramentas 
para o engenheiro de software. Com ela é possível trazer todos 
os interessados para um mesmo ponto de entendimento do 
sistema computacional que será desenvolvido. Ele contempla três 
objetivos, cite quais são.
Atividade 2
Nesta atividade a missão é desenvolver um caso de uso simples, 
no qual o usuário irá inserir seu login e senha, e o sistema irá 
validar e devolver uma mensagem de erro ou acesso concebido.
REFERÊNCIAS 
HASSAN, G. Software modeling and design: UML, use cases, patterns and software 
architectures. Cambridge: Cambridge University Press, 2011.
IAN, S. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: 
AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Education, 2011.
WAZLAWICK, R. Engenharia de software: conceitos e práticas. São Paulo: GEN LTC, 2019.
Resolução das atividades
1 A importância da engenharia de software
1. Você assumiu a missão de um museu altamente relevante nos 
Estados Unidos de criar uma experiência histórica aos visitantes: 
elaborar uma linha do tempo com os principais avanços 
tecnológicos ao longo da história. Para tanto, utilize os marcos 
trazidos neste capítulo, bem como outras pesquisas, para criar o que 
conhecemos como timeline da tecnologia. Use a criatividade para 
surpreender a todos com gráficos, imagens e até animação gráfica. 
Nesta atividade você deverá citar as principais evoluções tecnológicas 
abordadas no capítulo, bem como outras que porventura sejam 
pesquisadas. O principal objetivo é demonstrar uma linha do tempo 
identificando o ano das inovações e uma breve descrição delas.
2. Escolha um aplicativo que você utiliza no seu dia a dia e desenvolva 
um documento com os itens do design de software tratados neste 
capítulo. Fale como a abstração, a modularidade, a arquitetura, o 
refinamento, o padrão, a ocultação de informações e a refatoração 
podem ser encontrados no aplicativo. 
Nesta atividade você deverá escolher um aplicativo e descrever em 
curtos textos como a abstração, a modularidade, a arquitetura, o 
refinamento, o padrão, a ocultação de informações e a refatoração 
estão presentes no aplicativo.
2 Ciclo de vida do software
1. Neste momento você é o engenheiro de software chefe de uma 
grande empresa de cosmético e precisa convencer todo o seu time 
de desenvolvedores de que o ciclo de vida de desenvolvimento de 
software eficiente é importante. Ressalte os principais benefícios 
conseguidos com a implantação de um ciclo de vida. Se preferir, 
use um ou mais slides ou, ainda, apresente esses benefícios em um 
texto de no máximo uma página.
Nesta atividade você deverá citar os principais benefícios de 
um ciclo de vida eficiente, ressaltando que ele reduz o custo de 
desenvolvimento de software e, ao mesmo tempo, melhora a 
qualidade e reduz o tempo de produção, atingindo essas metas que 
Resolução das atividades 101
se mostram aparentemente divergentes, mas que na verdade são 
essenciais no desenvolvimento de softwares. Além disso, ele entrega 
ao usuário uma nova experiência, deixando todos os envolvidos 
satisfeitos com os resultados.
2. Ainda como engenheiro de software chefe de uma grande 
empresa de cosmético, você precisa, agora, apresentar as etapas 
que compõem o ciclo de desenvolvimento de software e explicar 
rapidamente cada uma dessas fases.
Nesta atividade você deverá listar e detalhar as seguintes fases: 
• levantamento de requisitos;
• análise e projeto;
• implementação e testes;
• implantação e manutenção.
3 Orientação a objetos
1. Você foi chamado para convencer um time de engenheiros de 
softwares que a orientação a objetos é muito mais adequada para 
o atual momento quando comparamos com os antigos padrões 
de análise e desenvolvimento de software. Para essa missão, você 
deverá construir um quadro que compare e ressalte os benefícios 
entre a orientação a objetos e os métodos tradicionais.
Nesta atividade você deverá citar os principais benefícios da orientação 
a objetos ressaltando seus pontos positivos em relação aos métodos 
tradicionais, tais como: reutilização de código, manutenção do código, 
forma de execução, entre outros. Ressaltando que provê uma melhor 
organização do código, ajuda para o reaproveitamento de código, 
alinhamento com os novos mindsets dos programadores etc.
2. Seguindo os exemplos vistos, escolha e desenvolva mais três 
classes de objetos com no mínimo três atributos e três métodos 
para um sistema de supermercado.
Você deverá imaginar quais classes podemos ter em um supermercado 
e indicar três atributos e três métodos, na obra, demos alguns 
exemplos de classes, tais como:
102 Engenharia de Software
produtos
- código
- descrição
- quantidade em estoque
- preço
- peso 
inclusão()
consulta() 
venda()
rental_car
- placa do automóvel
- modelo
- cor
- ano
- tamanho
inclusão()
exclusão() 
fornecedores
- cnpj
- razão social
- endereço
- cidade
- estado
alteração()
relatório() 
Você deverá fazer o mesmo com outras classes de um supermercado, 
como por exemplo: Produtos, Fornecedor, Cliente, Contas a pagar, 
Contas a receber, Fluxo de caixa, Nota Fiscal de Compra, Nota 
Fiscal de Venda, enfim, qualquer classe que possa pertencer a um 
supermercado.
4 UML – Unified Modeling Language
1. Dentro do ecossistema do UML, temos vários diagramas que 
colaboram integralmente na construção de softwares. Nesse 
sentido, você deve se colocar como um engenheiro de softwares de 
uma grande empresa e desenvolver um documento de no máximo 
duas páginas, que ilustre de maneira resumida as diferenças entre 
os seguintes diagramas:
a) Diagrama de atividades
• É utilizado para desenvolver representações gráficas 
que ilustram os fluxos de trabalho e as atividades dos 
participantes do sistema.
• Descreve o fluxo de controle do sistema de destino.
• Tem como objetivo modelar processos computacionais 
e organizacionais.
• Descreve como as atividades são coordenadas para fornecer 
um serviço que pode estar em diferentes níveis de abstração. 
b) Diagrama de classes
• Auxilia na modelagem de todos os métodos da orientação 
a objetos.
• Impulsiona a descrição dos tipos de objetos nos projetos 
e os respectivos tipos de relacionamentos que existem 
entre eles.
Resolução das atividades 103
• Mostra a estrutura estática dos classificadores em um 
sistema.
• Fornece uma notação básica para outros diagramas de 
estrutura prescritos pela UML.
• É útil para desenvolvedores e para outros membros da 
equipe também.
• Pode ser usado por analistas de negócios para modelar 
sistemas por meio de uma perspectiva de negócios.
c) Diagrama de objetos
• É gráfico de instâncias, incluindo objetos e valores de dados.
• É uma instância de um diagrama de classe.
• Mostra um instantâneo do estado detalhado de um sistema 
em determinado momento. 
• É limitado, principalmente para mostrar exemplos de 
estruturas de dados.
d) Diagrama de sequência
• Modela a colaboraçãode objetos, com base em uma 
sequência de tempo. 
• Mostra como os objetos interagem com outros em um 
cenário particular de um caso de uso. 
• Trata-se de diagramas de interação que detalham como as 
operações são realizadas. 
• Captura a interação entre objetos no contexto de uma 
colaboração. 
• É focado no tempo e mostra a ordem da interação 
visualmente, usando o eixo vertical do diagrama para 
representar o tempo em que as mensagens são enviadas 
e quando.
• Captura a interação que ocorre em uma colaboração, 
realizando um caso de uso ou uma operação.
• Mostra as interações de alto nível entre o usuário do sistema 
e o sistema, e entre o sistema e outros sistemas.
2. Nesta atividade, a missão é compreender a figura deste livro, 
chamada Diagrama de atividades: elaborando um texto, dentro da 
104 Engenharia de Software
Seção 4.3, e transformá-la para atender a um processo de login em 
um aplicativo comum, como o Facebook ou Instagram. 
 Imagine o passo a passo que você executa para acessar sua rede 
social preferida. Para tanto, você pode usar qualquer software que 
tenha mais facilidade ou pegar um lápis e folha de papel e soltar 
sua criatividade.
Login com sucesso
Mensagem de erro 
Clicar no botão de 
acesso
Inserir senhaInserir login
Abrir o aplicativo 
da rede social
Se dados incorretos
5 Diagrama de caso de uso
1. O diagrama de caso de uso é uma das principais ferramentas 
para o engenheiro de software. Com ela é possível trazer todos 
os interessados para um mesmo ponto de entendimento do 
sistema computacional que será desenvolvido. Ele contempla três 
objetivos, cite quais são.
Nesta atividade você deverá descrever os três objetivos do diagrama 
de caso de uso, que são: necessidade do cliente, sistema a ser 
implementado e requisitos definidos.
2. Nesta atividade a missão é desenvolver um caso de uso simples, no 
qual o usuário irá inserir seu login e senha, e o sistema irá validar e 
devolver uma mensagem de erro ou acesso concebido.
Como nesta atividade temos como ator somente o usuário, um 
cenário de autenticação de login e senha e uma resposta positiva ou 
negativa do acesso, seu diagrama deve ter a seguinte estrutura:
Resolução das atividades 105
Solicitação de 
login e senha
Resposta do 
acesso
Valida dados
106 Engenharia de Software
Engenharia
de Software
Wagner Sanchez
W
agner Sanchez
Engenharia de Softw
are
Fundação Biblioteca Nacional
ISBN 978-65-5821-067-2
9 786558 210672
Código Logístico
I000358
	Página em branco
	Página em branco