Engenharia de Software

Engenharia de Software
Engenharia
de Software
Wagner Sanchez
Wagner Sanchez
Código Logístico Fundação Biblioteca Nacional
ISBN 978-65-5821-067-2
I0 0 0 3 5 8 9 786558 210672
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
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.
CDD: 005.1
21-74615
CDU: 004.41
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
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.
Vídeos
em
QR code!
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áfica 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.
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

Vídeo
APRESENTAÇÃO
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.
1
A importância da
engenharia de software
Objetivos de aprendizagem
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.
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.
A importância da engenharia de software 9

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 é apenas um conjunto de componentes de hardware inca-
pazes de executar qualquer função.
10 Engenharia de Software
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).

A seguir estão alguns exemplos de programas usados por codifica-
dores durante o desenvolvimento de software.
Compiladores: programas que convertem o código
bsd/shutterstock
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-
bsd/shutterstock mamente sofisticado.
Depuradores: programas de computador usados para

testar e “depurar” (localizar e remover erros) o código
do computador.
Linkers: programas que pegam a saída de um compi-

bsd/shutterstock
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.
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.
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,

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.
Babich Alexander/Shutterstock
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).
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,

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).
Charles Babbage/Wikimedia Commons

Máquina analítica de Charles Babbage.
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.
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.

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.
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 essa má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- Filme
to, jogos, agendas etc. Contudo, a quarta geração mudou isso. Uma visão mais lúdica e
profunda dessa geração
Melhorias nas técnicas de integração afetaram não somente os de computadores e o
processadores, mas todos os componentes presentes em um com- surgimento da Microsoft
e da Apple – empresas
putador, principalmente memórias. Desse modo, nessa época, as ícones do segmento de
memórias dinâmicas também deram um salto em sua capacidade: computadores pessoais
– podem ser vistos pela
64 kbits em 1981, 256 kbits em 1984, 1 mbit em 1984 e 4 mbits e 16 ótica do filme Piratas
mbits em 1987 (VELLOSO, 2014). do Vale do Silício. Vale a
pena conferir.
Um exemplo dessa geração foi o Apple I, que teve uma vida mui- Direção: Martyn Burke. EUA:
TNT, 1999.
to curta, tendo sido apresentado em 1976 e substituído em 1977
pelo Apple II.

Achim Baqué/Wikimedia Commons
Placa do circuito
integrado do
Apple I
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 & M
usée Bolo
/Wikimed
ia Common
s
Apple II
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.
Commons
Boffy b/Wikimedia
IBM 5150
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-

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;
• 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

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
requisitos
5 2
Análise de
Implantação
sistema
4 3
Teste Codificaçã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.
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.

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.
• 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-
Livro
nho repetido várias vezes para formar um padrão. Este refere-se
Com oito edições e mais de
à repetição de uma solução para um problema recorrente e co- 30 anos no topo dos livros
mum dentro de certo contexto. mais vendidos e recomen-
dados da engenharia de
• Ocultar informações: dados desnecessários não precisam software, a obra Engenharia
aparecer, isto é, significa ocultar as informações para que não de software: uma aborda-
gem profissional precisa
possam ser acessadas por uma parte indesejada. No projeto de estar na cabeceira de
software, a ocultação de informações é obtida projetando-se os todos os desenvolvedores,
engenheiros, programa-
módulos de modo que as informações coletadas ou contidas dores e profissionais de
neles sejam ocultadas e não possam ser acessadas por quais- tecnologia.
quer outros módulos. O livro traz um leque ri-

quíssimo de procedimen-
• Refatorar: é reconstruir algo de tal forma que não afete o com- to, roteiros, cuidados e
atalhos da engenharia de
portamento ou quaisquer outras características. Significa re-
software. Também aborda
construir o design para reduzir a complexidade sem afetar o aspectos essenciais, como
o trabalho com os usuá-
comportamento ou as funções.
rios para determinar suas
necessidades de software;
O design de software possui três diferentes níveis que devem ser
o roteiro para desenho
observados nos projetos de desenvolvimento. São eles: de diagramas e modelos
que ajudem os desenvol-
1. Projeto arquitetônico: a arquitetura de um sistema pode vedores a criar o código
ser vista como a estrutura geral do sistema e a maneira como apropriado para o sistema
ou aplicativo; indicações
esta fornece integridade conceitual. O projeto arquitetônico de como documentar o
identifica o software como um sistema com muitos componentes sistema ou aplicativo em
detalhes para ajudar os
interagindo entre si. Nesse nível, os designers têm a ideia do responsáveis pela manu-
domínio da solução proposta. tenção futura; os proce-
dimentos para manter o
2. Projeto preliminar ou de alto nível: aqui o problema é sistema ou aplicativo com
decomposto em um conjunto de módulos e a relação de controle atualizações e correções
conforme necessário etc.
entre os vários módulos e as interfaces entre os vários módulos
Enfim, por muitos é
são identificadas. O resultado desse estágio é chamado de considerado a bíblia da
arquitetura do programa. engenharia de softwares.
As técnicas de representação de design usadas nesse estágio são PRESSMAN, R. S. 8. ed. Porto Alegre:
AMGH, 2016.
gráficas de estruturas de softwares que veremos mais à frente.

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.
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.

2
Ciclo de vida do software

• 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.
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
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.
Ciclo de vida do software 31

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).
Figura 1
Ciclo de vida de software
Levantamento de
requisitos
Implantação e Sistema
proposto Análise e projeto
manutenção
Implementação e
testes
Fonte: Elaborada pelo autor com base em Ian, 2011.
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.
A etapa 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.

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.
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.

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).
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 motivo pelo 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.

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.
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.

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.
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 produto e 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.

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
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
PureSolution/Shutterstock
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.
44 Engenharia 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.

5. Considere a opção do uso de recompensas
Recompensas podem ser uma forma eficaz de incentivar um deter-

minado comportamento, 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.
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.

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.
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. Livro
O livro Não me faça
Esse esforço é classificado como manutenção preventiva ou modifi- pensar, de Steve Krug,
cação de um produto de software após a entrega para detectar e corrigir explica que os humanos
que usam software ou
possíveis falhas no produto de software antes que elas entrem em vigor. sites tendem a aceitar
a primeira solução que
Quanto mais complexo for o software, provavelmente mais manu- lhes é apresentada. Esse
tenção será necessário para garantir o uso contínuo. As perguntas ób- ponto essencial deve ser
aproveitado por enge-
vias são “por quê” e “quanto”. Isso varia e é um pouco complicado, pois nheiros de softwares que
cada produto de software é diferente. querem se diferenciar no
mercado.
É possível minimizar os custos de manutenção por meio de planeja- O livro se concentra na
mento e execução inteligentes, mas também pode-se acabar pagando simplicidade, na objeti-
vidade e no bom senso,
mais para manter o produto do que para desenvolvê-lo se o gestor não sendo considerado por
tomar cuidado. muitos essencial para
qualquer engenheiro de
Existem muitos fatores de custo de manutenção de software: ela software. A obra ajuda
os desenvolvedores a
não se trata apenas de consertar bugs; envolve qualquer esforço para entender a experiência
manter as coisas funcionando da maneira que seus usuários esperam do usuário e a mudar sua
maneira de pensar para
que funcione – e, na maioria das vezes, isso significa outra coisa do que que o design de interface
simplesmente corrigir defeitos em seu código. seja sempre a força mo-
triz por trás das decisões
Com esta etapa, concluímos o ciclo de desenvolvimento de softwa- dos desenvolvedores.
re, processo altamente importante dentro da engenharia de softwa-

KRUG, S. São Paulo: Alta Books,
re que busca trazer práticas, ferramentas e metodologias eficazes na 2014.
construção, entrega e manutenção dos softwares.
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.

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.
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.
TSUI, F.; KARAM, O. Fundamentos de engenharia de software. São Paulo: LTC, 2013.
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.
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
Orientação a objetos 51
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.
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).
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
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.
Figura 1
Classe
rental_car
- placa do automóvel
- modelo
- cor
- ano
- tamanho
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.
Figura 2
Classe com métodos
rental_car
- placa do automóvel
- modelo
- cor
- ano
- tamanho
inclusão()
exclusão()
saída()
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.
Figura 3
Classes de objetos – produtos e fornecedores
produtos fornecedores
- código - cnpj
- descrição - razão social
- quantidade em estoque - endereço
- preço - cidade
- peso - estado
inclusão() alteração()
consulta() relatório()
venda()
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.
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
Vídeo
Encapsulamento
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,
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.
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?
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.
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 herda de 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.
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
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.
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
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
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.
Livro
Na obra de iniciação à
Figura 7
orientação a objetos, Orien-
Herança hierárquica
tação a objetos: aprenda
seus conceitos e suas aplica-
bilidades de forma efetiva,
você poderá irá iniciar a
leitura com um breve histó- Class A
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 Class B Class C Class D
objeto são bastante claras
e objetivas, ajudando você
a se aprofundar num as-
sunto que, algumas vezes, Fonte: Elaborada pelo autor.
parece mais complicado
do que é. A obra finaliza Na herança hierárquica, conforme mostrado no diagrama da Figura
com boas práticas no uso
7, a Class C, B e D herdam atributos da superclasse A.
da orientação a objetos,
chamando atenção para
Com essas estruturas, o programador pode escolher entre a melhor
herança, polimorfismo, en-
capsulamento e abstração, opção para desenvolver seus modelos orientados a objetos, sempre
e como eles podem ser
buscando eficiência, eficácia em seus códigos.
úteis no desenvolvimento
de sistema eficientes. Dentro dos recursos da orientação a objetos, vale ressaltarmos a
CARVALHO, T. L. São Paulo: Casa do generalização e a especialização. Eles representam uma hierarquia
Código, 2016. 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
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.
AMGH, 2016.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. São Paulo: GEN LTC, 2019.
4
UML – Unified Modeling
Language

• 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.
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.
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;
UML – Unified Modeling Language 67

• 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
Vídeo
Diagrama de atividades
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.
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.

Figura 1
Diagrama de atividades: elaborando um texto
Abra o software de Salve o arquivo com

processamento de Crie um arquivo um nome exclusivo Digite o documento
texto em seu diretório
Se forem necessários gráficos
Abra o pacote de gráficos,

crie os gráficos e cole-os
no documento
Abra o pacote da planilha,

crie a planilha e cole-a no
documento
Se forem necessárias planilhas
Saia do pacote de Imprima uma

processamento de cópia impressa do Salve o arquivo
texto documento
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.
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 da equipe 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
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.
Figura 3
Diagrama de classe: salas de aula
Turma
codigo: Texto
esta-matriculado-em sala: Texto e-ministrada-por
horario: Horario
estaAberta()
definirProfessor(professor)
Aluno incluirAluno(aluno) Professor
nome: Texto nome: Texto

matricula: Inteiro titulacao: Texto
definirNome(nome) definirNome(nome)
obterNome() obterNome()
definirNome() definirTitulacao(titulo)
definirMatricula(matricula) obterTitulacao
obterMatricula

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.
Figura 4
Diagrama de classe: berçário
Uma pessoa pode ser um bebê,
um médico ou uma mãe
Pessoa
Nome
Data de nascimento
Medico Bebe Mae

faz parto possui uma
CRM Sobrenome
Endereco Endereco
Telefone celular 1 0..* 0..* 1 Telefone
0..*
Ingere
0..*
Medicamento Medicacao
Descricao Quantidade
Quantidade em estoque Data
UnidadeMedida Hora
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.
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.

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.
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.

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:

• Ator
O ator é caracterizado por desempenhar determinada função Figura 5

dentro do sistema, ou seja, tem um protagonismo no software, Ator
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- Fonte: Elaborada pelo autor.
do informação.
Figura 6
Linha do tempo
LifeLine
• Linha de vida
Uma linha de vida representa um participante individual na

interação.
Figura 7
Ativações
• Ativações
Um retângulo fino, em uma linha de vida, representa o período LifeLine
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.

Figura 8
Mensagem de chamada • Mensagem de chamada
1: message 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
Figura 9
A mensagem de retorno é um tipo de mensagem que repre- Mensagem de retorno
senta a passagem de informações de volta para o chamador de
1.1:
uma mensagem anterior correspondente.
Figura 10 • Automensagem
Automensagem
A própria mensagem é um tipo de mensagem que representa a
invocação de mensagem da mesma linha de vida.
1: message
• Mensagem recursiva
Figura 11
Mensagem recursiva é um tipo de mensagem que representa a
Autorrecursiva
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.
1: message

Figura 12 • Criar mensagem
Criar mensagem
Criar mensagem é um tipo de mensagem que representa a
1: message
LifeLine2
instanciação da linha de vida (destino).
• Mensagem de destruição Figura 13

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. 1: message
Figura 14 • Mensagem de duração

Mensagem de duração
A mensagem de duração mostra a distância entre dois instantes de
1: message
tempo para uma chamada de mensagem.
• Observação Figura 15
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.
A seguir, há um exemplo genérico de diagrama de sequência.
Figura 16
Diagrama de sequência genérico
objeto 1:
objeto2 :nome da classe
nome da classe
Nome ator:
classe ator
1: evento
2: operação 3: operação (lista parâmetros)
4: operação (lista de parâmetros)

Livro
Em seguida, apresentamos mais um exemplo. Nesse caso, trazemos
No livro UML 2: uma
o diagrama de sequência para um processo genérico de um cadastro
abordagem prática,
de alunos. A ilustração mostra como ator o aluno, que é quem detém você vai poder explorar
diversos estudos de caso
as informações que serão inseridas no sistema.
modelados e demonstra-
dos com exemplos
É possível observar que temos quatro linhas de tempo identificadas
práticos, com os diversos
como interface do sistema com o ator; depois, a interface do sistema diagramas que estuda-
mos neste capítulo.
com o banco de dados e, então, o próprio banco de dados.
Além dos exemplos, a
Para conectar as linhas do tempo, foram inseridas as trocas de da- obra apresenta exercícios
para que os leitores
dos, como “inclui dados cadastrais do aluno”, “validação dos campos
possam aferir os conhe-
inseridos” e outros, que demonstram como os dados são socializados cimentos absorvidos
durante a leitura. É indi-
entre as linhas do tempo.
cado para profissionais
iniciantes e experientes,
Figura 17 sendo um ótimo livro de
Diagrama de sequência: cadastro de alunos cabeceiras para os enge-
nheiros de softwares.
GUEDES, G. T. A. São Paulo: Novatec,
Interface do sistema Interface do sistema
Aluno Banco de dados 2018.
com o ator com o banco de dados
Acesso ao banco de
Inclui dados cadastrais Validação dos campos
dados para a gravação
do aluno inseridos
dos dados
Mensagem de erro ou de Mensagem de erro ou de Mensagem de erro ou de

aluno já cadastrado aluno já cadastrado aluno já cadastrado
Gravação dos dados

Correção dos dados Correção dos campos
corrigidos
Mensagem de finalização Mensagem de finalização Mensagem de finalização

do processo do processo do processo
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-

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, dentro da
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
AMGH, 2016.
WAZLAWICK, R. Engenharia de software: conceitos e práticas. São Paulo: GEN LTC, 2019.
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.
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-

Figura 1 municação perfeito entre os interlocuto-
Modelo de caso de uso res; com isso, a eficiência na construção
do software aumenta significativamente.
Necessidade
O modelo de caso de uso contempla
do cliente
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-
Modelo de
caso de uso
lidados quando o projeto for construído
(IAN, 2011).
Requisitos Sistema a ser

definidos implementado
Diagrama de caso de uso 81

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.
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
O cliente seleciona o produto e a quantidade, o sistema
Fluxo principal
verifica o estoque e calcula o valor a pagar
O cliente pode alterar a quantidade antes de fechar a
Fluxo alternativo
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.

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.
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
quando um 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

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 >>.
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:
Etapa 1
• Contextualize as necessidades do sistema.
Etapa 2
• 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 3
• Documentação do caso de uso.
Com essas etapas cumpridas, só nos resta desenvolver o Modelo

Entidade Relacionamento (MER) para que o sistema posso ser codifica-
do, testado e implementado.

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-
Dica
forma os dados do cartão: número, data de validade, nome, nome da
Ator representa um papel
que usuários, sistema operadora do cartão de crédito e o código de segurança. O sistema
externo, hardware ou dis- deve solicitar a autorização do pagamento para a operadora do cartão
positivos desempenham
à medida que interagem de crédito. Se o pagamento for por boleto, o sistema o emite.
com o sistema.
O funcionário, gerente do setor financeiro, efetua o login com a se-
nha de administrador, consulta os pagamentos e, se confirmar o paga-
Figura 2 mento, emite a nota fiscal.
Ator do cenário
O funcionário separa e envia os produtos para a transportadora que
Quem pode interagir com fará a entrega. Ao encaminhá-los, o funcionário registra o envio do pe-
um e-commerce de sucos dido para entrega, informa o status do pedido – enviado para entrega,
naturais?
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
• 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 Registrar o 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

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

Objetivo Consultar os pagamentos
Caso de uso Emitir nota fiscal

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
Dica
Com base nos casos levantados, seguimos para a identificação dos
O relacionamento indica
relacionamentos envolvidos nesse cenário.
quem solicita, quem exe-
cuta e como será executa-
Deve-se analisar se todo ator tem, no mínimo, uma associação com
da uma funcionalidade.
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:
Figura 3
Modelagem de e-commerce de sucos naturais
Pesquisar tipos de Calcular valor da

sucos compra
<<includes>>
Cliente Registrar compra Cadastrar cliente

<<extend>>
Solicitar
Registrar <<extend>> Operadora
autorização de de cartão de
pagamento
pagamento crédito
<<extend>>
Efetuar Login Emitir boleto
Consultar <<extend>>
Gerente
Emitir Nota Fiscal
pagamento
Registrar pedido Baixar pedido de

de entrega compra
funcionário
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.

Etapa 1
• Contextualize as necessidades do sistema.

Etapa 2
• 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 3
• Documentação do caso de uso.
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

Figura 4
Diagrama de caso de uso do HealthTech
Administrador do Módulo de parametrização e

aplicativo administração do aplicativo Health Track
<<Include>>
Login/cadastro de usuários/
parametrização do sistema
Controle da dieta do paciente

Médico Usuário Monitoramento
de biossinais
Controle dos exercícios físicos <<Include>>
Alerta de alterações clínicas <<Include>>
Fonte: Elaborada pelo autor com o software Astah.
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
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-
Sumário
çã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- FP02 – Solicitar credenciais para acessar como administrador
rametrização
FP02 – Administrador
insere todos os parâ- FP04 – Receber e armazenar as parametrizações do administrador do sistema
metros
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
Quadro 3
Login / Cadastro de usuários / Parametrização do sistema

Título do caso de uso Login / Cadastro de usuários / Parametrização do sistema
Deverá fazer o login e o controle de usuários validando login e senha. Além disso,
Sumário 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)

Fluxo principal
Ator Sistema
FP05 – Usuários do aplicativo
realizam o cadastro para obter as FP07 – Solicitar credenciais para o acesso do usuário
credenciais de acesso
FP06 – Usuários do aplicativo
realizam o cadastro para obter as FP08 – Solicitar credenciais para o acesso do médico
credenciais de acesso
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
Quadro 4
Monitoramento de Bio Sinais

Título do caso de uso Monitoramento de biossinais
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-
Sumário
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 FP11 – Recebe de maneira ininterrupta os biossinais para armazenamento e utilização
biossinais por meio do ce- posterior
lular ou smartwatch
FP10 – Informa anomalias FP12 – Se os biossinais estiverem em desacordo com os parâmetros do médico, o sinal
ao sistema de alertas de alerta deve ser disparado para o médico e para o usuário
Fluxo Alternativo
Não há
Regras do negócio
Se os biossinais estiverem em desacordo com os parâmetros informados pelo médico, o
RN03
sinal de alerta deve ser disparado.
Quadro 5
Alerta de alterações clínicas

Título do caso de uso Alerta de alterações clínicas
Caso o monitoramento de biossinais detecte alguma anomalia comparando-se com a para-
Sumário 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 FP15 – Sistema informa ao usuário sinal de emergência e sua gravidade
alerta de emergência
FP14 – Médico recebe
alerta de emergência FP16 – Sistema informa ao médico sinal de emergência e sua gravidade
do paciente
Fluxo Alternativo
Caso o usuário e/ou médico não confirmem o recebimento do alerta, um alerta especial
FA06
deve ser enviado ao administrador do aplicativo
Regras do negócio
Se os biossinais estiverem em desacordo com os parâmetros informados pelo médico, o
RN04
sinal de alerta deve ser disparado
Quadro 6
Controle de dieta do paciente

Título do caso de uso Controle de dieta do paciente
Por meio das informações do médico e do paciente, uma dieta balanceada é
Sumário
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)

FP17 – Usuários do aplicativo rece-
FP19 – Sistema informa ao usuário dieta adequada
bem dieta adequada
FP18 – Médico informa parâmetros
FP20 – Médico informa dieta adequada ao paciente
para a 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
Quadro 7
Controle dos exercícios físicos

Título do caso de uso Controle dos exercícios físicos
Por meio das informações do médico e do paciente, uma sequência de
Sumário
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
FP23 – Sistema informa ao usuário a sequência de exercícios
sequência de exercícios adequada
FP22 – Médico informa parâmetros para

FP24 – Médico informa sequência de exercícios para o paciente
a sequência de exercícios ao paciente
Fluxo Alternativo
FA07 Aceite do usuário quanto aos exercícios
Aplicativo solicita ao médico sequência de exercícios caso não tenha en-
FA08
viado
Regras do negócio
Os exercícios precisam ser informados e validados pelo médico do pa-
RN04
ciente
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.
Figura 5
MER – Modelo Entidade Relacionamento do sistema do health tech
Tabela Fato:
Dimensão: Paciente Dimensão: Dieta
Dieta_Paciente
ID_Paciente PK
Paciente_nome FK ID_dieta ID_dieta PK
Paciente_endereço ID_paciente FK dieta_nome
Paciente_email ID_medico dieta_calorias
Paciente_convenio Data_inicio dieta_procedimento
Paciente_celular Data_termino dieta_lista_de_alimentos
Paciente_senha
Tabela Fato:
Tabela Fato: Login Dimensão: Bio_sinais
Monitoramento
FK ID_Bio ID_Bio PK
FK ID_usuario (médico ou
ID_paciente FK Bio_descricao
paciente)
Data Bio_medicao maxima
Data
Hora Bio_medicao minima
Hora
Medicao Bio_importancia
Tabela Fato: Dimensão:

Dimensão: Medico
Atividade_Paciente Atividades_Fisicas
ID_medico PK
Medico_nome FK ID_atividade
ID_atividade PK
Medico_endereco ID_paciente FK
atividade_nome
Medico_email ID_medico FK
atividade_calorias
Medico_especialidade Data_inicio
atividade_procedimento
Medico_celular Data_termino
Medico_senha
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

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
Chave primária das Atividades Físicas, será armazenado um código único para
ID_atividade
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
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_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
Informações úteis para o usuário paciente Livro
Nesta indicação temos
Consultar suas dietas
uma abordagem prática
Consultar suas atividades físicas do uso do UML na cons-
trução de softwares. São
Consultar os resultados de suas medições de biossinais apresentados exemplos
práticos de como o enge-
Informações para o usuário médico nheiro pode iniciar suas
primeiras modelagens de
Inserir dietas ao paciente sistemas computacionais.
O mapeamento das
Inserir atividades físicas ao paciente classes é bem prático e
objetivo, levando ao leitor
Analisar os biossinais dos pacientes a uma grande viagem
dentro da engenharia
Questões de negócio de software sem haver
descuidos quanto aos
Quantos usuários do perfil Médicos estão cadastros no aplicativo? conceitos essenciais,
principalmente a genera-
Quantos usuários do perfil Paciente estão cadastros no aplicativo?
lização, tão importante na
otimização dos códigos.
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? LIMA, A. S. G. UML 2.5: do requisito
à solução. São Paulo: Érica, 2014.
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.
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.

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
IAN, S. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
AMGH, 2016.
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

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:

rental_car produtos fornecedores
- placa do automóvel - código - cnpj
- modelo - descrição - razão social
- cor - quantidade em estoque - endereço
- ano - preço - cidade
- tamanho - peso - estado
inclusão() inclusão() alteração()

exclusão() consulta() relatório()
venda()
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.

• 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ção de 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

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.
Abrir o aplicativo Clicar no botão de

Inserir login Inserir senha
da rede social acesso
Se dados incorretos
Mensagem de erro
Login com sucesso
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:

Solicitação de
login e senha
Valida dados
Resposta do
acesso

Engenharia de Software
Engenharia
de Software
Wagner Sanchez
Wagner Sanchez
Código Logístico Fundação Biblioteca Nacional
ISBN 978-65-5821-067-2
I0 0 0 3 5 8 9 786558 210672

Engenharia de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Software

CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO

1. Engenharia de software. 2. Software - Desenvolvimento. 3. Progra-

Todos os direitos reservados.

IESDE BRASIL S/A.

Acesse os vídeos automaticamente, direcionando

Em alguns dispositivos é necessário ter instalado

2 Ciclo de vida do software 30

4 UML – Unified Modeling Language 66

5 Diagrama de caso de uso 81

Resolução das atividades 101

Com o estudo deste capítulo, você será capaz de:

A engenharia de software começa quando há uma demanda por de-

A importância da engenharia de software 9

1.1 O que é um software?

O software geralmente vem na forma de programas comerciais,

Qualquer programa ou código executado em um computador é um

Os três principais tipos de software são: de sistema operacional,

Sem um sistema operacional como o Windows ou o MacOS, um

Nesse grupo temos o firmware, um tipo de software semipermanen-

Os drivers de dispositivo também pertencem ao grupo dos softwares

Para finalizar, vale ressaltar os utilitários, programas que geralmen-

Já o software de aplicação indica ao computador quais tarefes

Os jogos e o software de multimídia são aplicativos populares (a câ-

Por fim, o terceiro grupo são os softwares de programação. Não

A importância da engenharia de software 11

Compiladores: programas que convertem o código

Depuradores: programas de computador usados ​​para

Linkers: programas que pegam a saída de um compi-

lador, geralmente muitos arquivos individuais, e com-

A seguir exploraremos a evolução dos hardwares e softwares ao

1.2 A evolução do hardware e software

Isso significa que esse profissional precisa entender de hardwares, ser

Começaremos nosso caminho rumo ao entendimento das máquinas,

Há algum tempo, os computadores são muito mais do que máqui-

Um bom engenheiro de software pode, entre outras atribuições,

Em função disso, começaremos com um histórico da evolução dos

Embora às vezes tenhamos uma impressão contrária a isso, na

Houve uma época na história que pouquíssimas pessoas tinham

Com o aumento exponencial das atividades que exigiam forma-

A importância da engenharia de software 13

A primeira máquina de calcular foi desenvolvida por Blaise

Com uma Pascaline, qualquer pessoa poderia executar uma soma,

Depois surgiram as máquinas registradoras, mais sofisticadas que

Entre outras coisas, elas evitavam ou, pelo menos, minimizavam

Imagine, por exemplo, o caixa de um banco, ao longo do dia, ano-

Percebendo problemas como esse, inventores criaram os cartões

Ao final do dia, os cartões eram colocados em outra máquina, que

Os riscos foram minimizados, pois apenas o caixa entrava com os

Devemos observar que, até esse momento da história, as má-

Imagine o gerenciamento de uma carteira de investimentos em

A importância da engenharia de software 15

Nessa situação, a análise das condições OU, E e SE depende ape-

Foi com o desenvolvimento da máquina analítica do matemáti-

Charles Babbage/Wikimedia Commons

Finalmente chegou a eletricidade! Primeiro, ela foi introduzida nos

O Z1 foi desenvolvido em 1938, na Alemanha, e foi o primeiro com-

O programa era lido de uma fita perfurada, os dados eram introduzi-

Em 1939, o Z2 substituiu a unidade aritmética mecânica do Z1

Em 1936, o matemático inglês Alan Turing (1912-1954) – sim, o Turing

Essa teoria serviu como premissa para o desenvolvimento posterior

Mais à frente, em 1943, foi desenvolvido pela Universidade da

A importância da engenharia de software 17

Avanços científicos na área dos semicondutores e todos aqueles

Depuradores: programas de computador usados para