ANÁLISE E PROJETO ORIENTADO A OBJETOS

Prévia do material em texto

ANÁLISE E PROJETO 
ORIENTADO
A OBJETOS
PROFESSORES
Me. Déverson Rogério Rando
Esp. Janaína Aparecida de Freitas
ACESSE AQUI 
O SEU LIVRO 
NA VERSÃO 
DIGITAL!
https://apigame.unicesumar.edu.br/qrcode/2888
EXPEDIENTE
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. 
Núcleo de Educação a Distância. RANDO, Déverson Rogério; 
FREITAS, Janaína Aparecida de.
Análise e Projeto Orientado a Objetos. 
Déverson Rogério Rando; Janaína Aparecida de Freitas.
Maringá - PR.: UniCesumar, 2020. 
176 p.
“Graduação - EaD”. 
1. Análise 2. Projeto Orientado a Objeto 3. Informática. EaD. 
I. Título. 
FICHA CATALOGRÁFICA
NEAD - Núcleo de Educação a Distância
Av. Guedner, 1610, Bloco 4Jd. Aclimação - Cep 87050-900 | Maringá - Paraná
www.unicesumar.edu.br | 0800 600 6360 
Coordenador(a) de Conteúdo 
Flavia Lumi Matuzawa
Projeto Gráfico e Capa
Arthur Cantareli, Jhonny Coelho
e Thayla Guimarães
Editoração
Flávia Thaís Pedroso
Design Educacional
Paulo Victor Souza e Silva
Revisão Textual
Carla Cristina Farinha e 
Ariane Andrade Fabreti
Ilustração
Bruno Pardinho e André Azevedo
Fotos
Shutterstock
CDD - 22 ed. 005.1 
CIP - NBR 12899 - AACR/2Impresso por: 
Bibliotecário: João Vivaldo de Souza CRB- 9-1679
Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de 
Matos Silva Filho Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva Pró-Reitor de Ensino de 
EAD Janes Fidélis Tomelin Presidente da Mantenedora Cláudio Ferdinandi
DIREÇÃO UNICESUMAR
NEAD - NÚCLEO DE EDUCAÇÃO A DISTÂNCIA
Diretoria Executiva Chrystiano Mincoff, James Prestes, Tiago Stachon Diretoria de Design Educacional 
Débora Leite Diretoria de Graduação e Pós-graduação Kátia Coelho Diretoria de Permanência Leonardo 
Spaine Head de Curadoria e Inovação Tania Cristiane Yoshie Fukushima Gerência de Processos Acadêmicos 
Taessa Penha Shiraishi Vieira Gerência de Curadoria Carolina Abdalla Normann de Freitas Gerência de Contra-
tos e Operações Jislaine Cristina da Silva Gerência de Produção de Conteúdo Diogo Ribeiro Garcia Gerência de 
Projetos Especiais Daniel Fuverki Hey Supervisora de Projetos Especiais Yasminn Talyta Tavares Zagonel
BOAS-VINDAS
Neste mundo globalizado e dinâmico, nós tra-
balhamos com princípios éticos e profissiona-
lismo, não somente para oferecer educação de 
qualidade, como, acima de tudo, gerar a con-
versão integral das pessoas ao conhecimento. 
Baseamo-nos em 4 pilares: intelectual, profis-
sional, emocional e espiritual.
Assim, iniciamos a Unicesumar em 1990, com 
dois cursos de graduação e 180 alunos. Hoje, 
temos mais de 100 mil estudantes espalhados 
em todo o Brasil, nos quatro campi presenciais 
(Maringá, Londrina, Curitiba e Ponta Grossa) e 
em mais de 500 polos de educação a distância 
espalhados por todos os estados do Brasil e, 
também, no exterior, com dezenas de cursos 
de graduação e pós-graduação. Por ano, pro-
duzimos e revisamos 500 livros e distribuímos 
mais de 500 mil exemplares. Somos reconhe-
cidos pelo MEC como uma instituição de exce-
lência, com IGC 4 por sete anos consecutivos 
e estamos entre os 10 maiores grupos educa-
cionais do Brasil.
A rapidez do mundo moderno exige dos edu-
cadores soluções inteligentes para as neces-
sidades de todos. Para continuar relevante, a 
instituição de educação precisa ter, pelo menos, 
três virtudes: inovação, coragem e compromis-
so com a qualidade. Por isso, desenvolvemos, 
para os cursos de Engenharia, metodologias ati-
vas, as quais visam reunir o melhor do ensino 
presencial e a distância.
Reitor 
Wilson de Matos Silva
Tudo isso para honrarmos a nossa mis-
são, que é promover a educação de qua-
lidade nas diferentes áreas do conheci-
mento, formando profissionais cidadãos 
que contribuam para o desenvolvimento 
de uma sociedade justa e solidária.
P R O F I S S I O N A LT R A J E T Ó R I A
Me. Déverson Rogério Rando 
Mestre em Ciência da Computação pela Universidade Estadual de Maringá (UEM). Es-
pecialista em Engenharia de Software pela Universidade Norte do Paraná. Graduado 
em Geografia pela Universidade Estadual de Londrina e Análise e Desenvolvimento 
de Sistemas pela Unicesumar. Atualmente, coordenador do Curso de Bacharelado 
em Sistemas de Informação da FAP – Faculdades Apucarana. Professor dos cursos 
de Técnico em Redes e Informática, respectivamente, no Senac e Senai, nas disci-
plinas de Banco de Dados, Análise Estruturada e OO, Organização e Arquitetura de 
Computadores, Computação Gráfica, IHC, Algoritmos, Linguagens de Programação, 
Sistemas de Informações Geográficas e Trabalho de Conclusão de Curso.
http://lattes.cnpq.br/3108532655755995
Esp. Janaína Aparecida de Freitas
Possui graduação em Informática pela Universidade Estadual de Maringá (2010) e 
especialização em MBA em Teste de Software pela Unicesumar (2012). Atualmente, 
cursa o Programa de Mestrado em Ciência da Computação na Universidade Estadual 
de Maringá (UEM) e é graduanda de Letras – Português/Inglês na Unicesumar. Atua, 
há três anos, como professora mediadora, professora conteudista em gravação de 
aulas ao vivo e conceituais nos cursos do NEAD – Núcleo de Educação a Distância, 
da Unicesumar, para os cursos de graduação de Sistemas para Internet, Análise e 
Desenvolvimento de Sistemas, Gestão da Tecnologia da Informação e Engenharia 
de Software, nas disciplinas de Engenharia de Software, Design Gráfico, Tópicos 
Especiais, Gerenciamento de Software, Design de Interação Humano-Computador, 
Projeto de Implementação e Teste de Software. Além disso, tem experiência em 
iniciativa privada na área de Análise de Sistemas e Testes de Software.
http://lattes.cnpq.br/4906244382612830
A P R E S E N TA Ç Ã O D A D I S C I P L I N A
ANÁLISE E PROJETO ORIENTADO A OBJETOS
Caro(a) aluno(a)! Seja bem-vindo(a) à disciplina de Análise e Projeto Orientado a Objetos (OO). 
Esta disciplina abordará vários aspectos relacionados à análise e ao projeto de sistemas orien-
tados a objetos, utilizando, como notação, a linguagem de modelagem UML. Apresentamos 
a você, aluno(a), o livro que conduzirá seus estudos, auxiliando no aprendizado de análise e 
projeto orientado a objetos com a UML. 
A Unidade 1 apresenta os conceitos iniciais sobre a análise e os projetos orientados a objetos. 
Estudaremos como surgiu e como ocorreu a evolução dos métodos orientados a objetos. 
Abordaremos, também, as características desses principais métodos, conheceremos os con-
ceitos básicos que envolvem a Orientação a Objetos para dar subsídio às unidades subse-
quentes. E, por fim, veremos os principais diagramas da UML utilizados na documentação 
de software.
Na Unidade 2, estudaremos as fases que compreendem a análise e o projeto de um software. 
Entraremos em contato com dois dos modelos de processos: cascata e evolucionário. Vere-
mos as vantagens e desvantagens da utilização de cada um desses métodos, abordaremos, 
também, os requisitos de software e conheceremos os procedimentos mínimos para a obten-
ção de um software de qualidade. Encerraremos a unidade falando sobre a importância da 
construção de casos de uso no levantamento de requisitos bem como a notação necessária 
para a construção de diagramas de casos de uso.
A Unidade 3 é toda dedicada à confecção do diagrama de classes responsável por demons-
trar a estrutura estática do sistema. Conheceremos, em detalhes, a notação para o diagrama 
de classes. Abordaremos os conceitos e a assinatura da declaração de atributos e métodos. 
Veremos como ocorrem as ligações entre as classes e como definir a multiplicidade entre 
elas. Discutiremos, ainda, as várias formas de associar as classes, sejam elas unária, binária, 
ternária, sejam elas associativa, de agregação ou generalização. 
D A D I S C I P L I N AA P R E S E N TA Ç Ã O
Na Unidade 4, conheceremos mais três diagramas, essenciais em análise e projeto OO, que 
utilizaremos para refinar o diagrama de classes que representa a estrutura do sistema. O 
primeiro diagrama que veremos, nesta unidade, é ode sequência, cujo objetivo é estudar as 
interações entre os objetos, considerando a dimensão tempo. O segundo diagrama que ve-
remos é o de estados, que tem como objetivo especificar o comportamento das classes mais 
complexas, utilizando máquinas de estado. Já o terceiro diagrama é o de comunicação, que 
contém as mesmas informações do diagrama de sequência, porém não considera o tempo, 
e sim a ordem da comunicação.
Por fim, na Unidade 5, resolveremos, juntos, um estudo de caso, no qual teremos a oportu-
nidade de apresentar, de forma prática, a construção dos diagramas citados na elaboração 
da análise e do projeto de um software. Dessa forma, reforçaremos todos os conceitos tra-
balhados nas unidades anteriores.
Ao longo deste livro, você encontrará indicações de leitura complementar, as quais enrique-
cerão o seu conhecimento sobre projetos. É importante que você desenvolva as atividades de 
estudo para fixar o conteúdo abordado e identificar eventuais dificuldades. Preparados(as)? 
Vamos lá!
ÍCONES
Sabe aquela palavra ou aquele termo que você não conhece? Este ele-
mento ajudará você a conceituá-la(o) melhor da maneira mais simples.
conceituando
No fim da unidade, o tema em estudo aparecerá de forma resumida 
para ajudar você a fixar e a memorizar melhor os conceitos aprendidos. 
quadro-resumo
Neste elemento, você fará uma pausa para conhecer um pouco 
mais sobre o assunto em estudo e aprenderá novos conceitos. 
explorando ideias
Ao longo do livro, você será convidado(a) a refletir, questionar e 
transformar. Aproveite este momento! 
pensando juntos
Enquanto estuda, você encontrará conteúdos relevantes 
online e aprenderá de maneira interativa usando a tecno-
logia a seu favor. 
conecte-se
Quando identificar o ícone de QR-CODE, utilize o aplicativo Unicesumar 
Experience para ter acesso aos conteúdos online. O download do aplicativo 
está disponível nas plataformas: Google Play App Store
CONTEÚDO
PROGRAMÁTICO
UNIDADE 01 UNIDADE 02
UNIDADE 03
UNIDADE 05
UNIDADE 04
FECHAMENTO
INTRODUÇÃO 
AO ESTUDO DE 
ORIENTAÇÃO A 
OBJETOS
10 
CASOS DE USO
40 
70 
DIAGRAMA DE 
CLASSES
102 
DIAGRAMAS DE 
SEQUÊNCIA, ESTADO 
E COLABORAÇÃO
130 
ESTUDO DE CASO
168 
CONCLUSÃO GERAL
1
INTRODUÇÃO
AO ESTUDO 
de orientação a objetos
PLANO DE ESTUDO 
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Introdução à Orientação a Objetos 
• Evolução dos Métodos OO • Conceitos Básicos de OO • Principais Diagramas da UML.
OBJETIVOS DE APRENDIZAGEM 
Entender a importância de análise e projeto • Conhecer a evolução dos métodos OO • Compreender as 
características dos métodos OO e seus diferentes termos • Conhecer os principais diagramas da UML.
PROFESSORES 
Me. Déverson Rogério Rando
Esp. Janaína Aparecida de Freitas
INTRODUÇÃO
Caro(a) aluno(a), iniciamos a primeira unidade do livro Análise e Projeto 
Orientado a Objetos falando sobre a importância da análise de sistemas 
dentro do projeto de produção de software.
Veremos que a análise de sistemas é a atividade inicial do processo de 
desenvolvimento de software. É nessa fase que determinamos e especifi-
camos o que um software deve fazer. Também, nessa fase, verificamos as 
circunstâncias sob as quais o software deve operar, envolvendo, geralmente, 
um esforço colaborativo entre analistas de sistemas e usuários.
Em seguida, veremos como os métodos surgiram e como aconteceu sua 
evolução. Abordaremos, a partir do primeiro método orientado a objetos, 
proposto por Shlaer e Mellor em 1988, o OOSA, até chegarmos à Unified 
Modeling Language, UML, que será a linguagem que utilizaremos para as 
nossas análises e nossos projetos OO.
Mesmo utilizando a UML, é importante conhecermos as características 
dos principais métodos OO, uma vez que a UML é a unificação de vários 
métodos que serão apresentados. Ou seja, a evolução de todos os outros 
métodos permitiu que chegássemos a uma unificação que, na verdade, 
apropria-se das melhores características dos demais métodos.
Nesta unidade, também conheceremos e entenderemos os conceitos 
e termos utilizados na análise e no projeto OO. Dentre os conceitos que 
veremos, estão os de objeto, abstração, classe, instância, atributo, operação, 
mensagem, evento, estado e parâmetro. Com esses conceitos iniciais, você 
terá uma visão geral sobre OO.
Conheceremos, ainda, os principais diagramas da UML utilizados na 
análise e no projeto de softwares, dentre eles: o diagrama de casos de uso 
utilizado na fase de análise para criar um cenário para o software, o dia-
grama de classes que modela a estrutura estática do sistema, o diagrama 
de sequência, o de colaboração e o de estado.
Então, o que estamos esperando? Vamos ao trabalho?
Boa leitura a todos.
U
N
ID
A
D
E 
1
12
1 
INTRODUÇÃO
À ORIENTAÇÃO
a objetos 
ANÁLISE E PROJETO
O processo de desenvolvimento de um sistema computacional tem, na análise, 
sua atividade inicial. Atividade esta que determina e especifica o que um sistema 
deve fazer, além das circunstâncias sob as quais ele deve operar, envolvendo um 
esforço colaborativo que abrange analistas de sistemas e usuários.
Os analistas procuram obter, a partir dos usuários, em um processo gradual 
e cumulativo, o maior conhecimento possível acerca do domínio do problema e 
do respectivo ambiente.
De acordo com Sommerville (2011), podemos chamar de “análise de sistemas” 
o que faz parte da “engenharia de requisitos”. Acrescentar o termo “engenharia” 
implica dizer que técnicas sistemáticas deverão ser utilizadas para assegurar que 
os requisitos do sistema sejam consistentes, relevantes e completos. A análise de 
sistemas é uma atividade de suma importância no processo de desenvolvimento 
destes, por ser uma etapa inicial e, também, porque as falhas terão efeitos em 
cadeia nas etapas subsequentes, assim como no produto final. A determinação 
incorreta dos requisitos levará à obtenção e à disponibilização de sistemas com-
putacionais inadequados.
U
N
IC
ES
U
M
A
R
13
Resumindo: a análise é a solução conceitual dada ao problema. Marca o início 
da definição informática, mas sem levar em conta detalhes da implementação, tais 
como a linguagem e o sistema gerenciador de banco de dados a serem utilizados. 
Preocupa-se, principalmente, com as classes do domínio do problema e suas 
relações e, também, com os casos de uso. Se, por um lado, a análise é a solução 
conceitual, por outro, o projeto consiste na solução computacional aplicada ao 
problema. Dizer onde acaba a análise e se inicia o projeto é muito complicado, 
uma vez que o projeto é o resultado de refinamentos sucessivos do modelo con-
ceitual de análise.
A Orientação a Objetos fez com que fosse alterado o enfoque necessário 
para desenvolver um sistema, enquanto que, na programação estruturada, havia, 
nitidamente, uma visão sequencial e bem dividida, como os programas, que exe-
cutam determinados processos e tratam determinados dados. Na Orientação a 
Objetos, passamos a visualizar classes responsáveis por atributos, com operações 
criadas para tratá-los, e a execução das atividades dos sistemas passa a depender 
da interação dessas classes.
Análise e projeto OO
Na década de 80, houve preponderância dos métodos estruturados para o desen-
volvimento de software. Atualmente, o paradigma OO é mais forte e, por isso, é 
importante diferenciar entre análise e projeto estruturado e orientado a objetos.
A análise e o projeto estruturados têm, como ênfase, as funções que atuam 
sobre os dados, ou seja, todo o processo que se deseja informatizar é compreendi-
do como um conjunto de funções com dados de entrada, processamento e saída. 
Yourdon (1990) apresenta as principais características:
 ■ Modularidade e coesão.
 ■ Desenvolvimento top-down (diferentes níveis de abstração).
Os diagramas que apoiam a análise e o projeto estruturado são:
 ■ Diagrama Entidade e Relacionamento (DER).
 ■ Dicionários de dados.
 ■ Diagrama de Fluxo de Dados (DFD).
U
N
ID
A
D
E 
1
14
O DER modela a estrutura de dadosparados, ou seja, é o modelo conceitual do 
sistema, mostra-nos as entidades e seus relacionamentos. Neste modelo, muitos 
detalhes não são mostrados, ficando a cargo do dicionário de dados os detalhes de 
nomes de atributos, tipos de dados, comprimento e demais restrições de dados. O 
DFD modela o fluxo destes, em outras palavras, mostra os dados em movimento, 
como ocorre a interação entre as diversas entidades (depósito) do sistema.
A Orientação a Objetos – ou, simplesmente, OO – é uma estratégia de de-
senvolvimento de software que o organiza como uma coleção de objetos que 
contém tanto a estrutura dos dados quanto o comportamento deles. A Orientação 
a Objetos tem, como principal característica, a forma natural de tratar a realidade, 
pois considera que o mundo real é formado por objetos.
A proposta da Orientação a Objetos é deslocar o esforço de desenvolvimento 
para a fase de análise, dando ênfase às estruturas de dados antes das funções e, 
assim, os benefícios são: a reutilização do código (componentes), a confiabilidade 
(objetos encapsulados) e o aumento de produtividade (SOMMERVILE, 2011). 
Com planejamento adequado, desenvolvedores capacitados e adoção de uma 
metodologia, o sucesso é garantido. A análise OO apresenta um conjunto de 
regras e modelos que auxiliam o analista a levantar e a modelar os requisitos dos 
usuários que o sistema deve atender.
Um sistema orientado a objetos é composto de objetos interativos que mantêm seu pró-
prio estado local e oferecem operações nesse estado. A representação do estado é privada 
e não pode ser acessada diretamente, de fora do objeto. Processos de projeto orientado a 
objetos envolvem projetar as classes de objetos e os relacionamentos entre essas classes. 
Essas classes definem os objetos no sistema e suas interações. Quando o projeto é con-
cebido como um programa em execução, os objetos são criados dinamicamente a partir 
dessas definições de classe. Sistemas orientados a objetos são mais fáceis de mudar do 
que os sistemas desenvolvidos com abordagens funcionais. Os objetos incluem os dados 
e as operações para manipulá-los. Portanto, eles podem ser entendidos e modificados 
como entidades autônomas. Como os objetos são associados com coisas, muitas vezes, 
existe um mapeamento claro entre entidades do mundo real e seus objetos de controle 
no sistema, o que melhora a inteligibilidade e, portanto, a manuteniblidade do projeto.
Fonte: Sommerville (2011, p.125).
explorando Ideias
U
N
IC
ES
U
M
A
R
15
2 
EVOLUÇÃO
DOS MÉTODOS OO
Os métodos de análise e projeto orientado a objetos surgiram assim que as lingua-
gens de programação OO começaram a estabilizar, sendo que um dos primeiros 
métodos foi o modelo OOSA, proposto por Shlaer e Mellor, em 1988, e o Wirfs-
-Brock, lançado em 1989, pelo grupo de pesquisa da Smalltalk (MEDEIROS, 2004).
A maior parte dos métodos OO, porém, passou a se tornar estável na década de 90, 
com a fusão das metodologias de Grady Boock, James Rumbaugh e Ivar Jacobson e a 
criação da UML, que teve como base outras metodologias, como a de Shlaer-Mellor. 
Buscava-se, com a criação da UML, uma padronização das metodologias OO.
Ivar Jacobson (1995)
Apresenta uma abordagem mais conceitual do que de detalhes, composta 
por cinco fases: levantamento de requerimentos, análise de robustez, projeto, 
implementação e teste. Ele segue a estratégia de métodos não lineares e em 
espiral com refinamentos sucessivos.
Coad e Yourdon (1992)
Abrangem as fases de análise, projeto e implementação; propõem uma meto-
dologia simples para iniciantes. As críticas mais fluentes destacam a ausência 
de modelagem para abranger todo o contexto necessário na fase de análise.
U
N
ID
A
D
E 
1
16
Shlaer e Mellor (1990)
Abrangem as fases de análise, projeto e implementação. Propõem mecanis-
mos para facilitar a representação de modelos dinâmicos dos objetos, dando 
ênfase à modelagem da informação, por meio dos modelos de objetos, de 
estados, de diagramas de fluxo de dados e de ações.
Grady Booch (1997)
Abrange as fases de análise, projeto e implementação. Apresenta uma poderosa 
notação utilizada para expressar as relações entre as classes, destacando-se, 
principalmente, na fase de projeto. É considerado um dos mais autênticos e 
tradicionais métodos de desenvolvimento de sistemas orientados a objetos.
James Rumbaugh (1991)
Abrange as fases de levantamento de dados com a descrição do domínio e do 
enunciado do problema, dividindo a fase de análise em modelagem de obje-
tos, modelagem dinâmica e modelagem funcional, destacando o tratamento 
de processos e dividindo a fase de projeto em projeto de objetos e de sistema. 
Martin e Odell (1995)
Abrangem as fases de análise e projeto. Propõem o uso da Engenharia da 
Informação baseada em objetos por meio de um repositório de objetos, para 
a obtenção, em alto nível, de reaproveitamento dos sistemas. 
Fusion (1996)
Abrange as fases de análise, projeto e implementação. Sintetiza os aspec-
tos mais positivos dos métodos de James Rumbaugh/OMT, Grady Booch, 
Wirfs-Brock/CRC e Ivar Jacobson/Objectory. O autor enfoca os modelos 
de objetos e processos do método OMT, a interação de objetos da CRC, a 
visibilidade do método de Booch e complementa com pré e pós-condições 
de métodos formais (COLEMAN, 1996).
U
N
IC
ES
U
M
A
R
17
UML – Unified Modeling Language (2000)
Abrange as fases de levantamento de requisitos, análise, projeto e implemen-
tação. Fusão dos métodos de James Rumbaugh/OMT, Grady Boock e Ivar 
Jacobson. A fusão inicia com o trabalho de Rumbaugh e Booch, os dois me-
todistas que ganharam mais popularização, os quais se juntaram para criar 
para o público um método comum por meio de pontos fortes em 1995. Em 
seguida, em meados de 1996, Jacobson integrou-se ao grupo, e lançaram a 
UML versão 0.9. A partir daí, criaram forças com cooperação da OMG (Object 
Management Group), em julho de 1997, considerado um padrão mundial.
A UML sugere, fortemente, a adoção de casos de uso (use cases) como dire-
cionadores de projetos de software, a utilização de diagramas de interação para 
identificação de objetos e uma série de outros conceitos. 
O projeto de software começa quando a primeira iteração da engenharia de requisitos 
chega a uma conclusão. O intuito do projeto de software é aplicar um conjunto de prin-
cípios, conceitos e práticas que levam ao desenvolvimento de um sistema ou produto de 
alta qualidade. O objetivo do projeto é criar um modelo de software que irá implementar 
corretamente todos os requisitos do cliente e trazer satisfação àqueles que o usarem. Os 
projetistas de software devem examinar completamente muitas alternativas de projeto e 
convergir para uma solução que melhor atenda às necessidades dos interessados no pro-
jeto. O processo de projeto passa de uma visão macro do software para uma visão mais 
estreita que define os detalhes necessários para implementar um sistema. O processo 
começa concentrando-se na arquitetura. São definidos subsistemas; são estabelecidos 
mecanismos de comunicação entre os subsistemas; são identificados componentes; e é 
desenvolvida uma descrição detalhada de cada componente. Além disso, são projetadas 
interfaces externas, internas e para o usuário.
Fonte: Pressman (2011, p. 226).
explorando Ideias
O modelo de projeto engloba quatro elementos distintos; à medida que cada um é desen-
volvido, evolui uma visão mais completa do projeto.
(Roger Pressman)
pensando juntos
U
N
ID
A
D
E 
1
18
3 
CONCEITOS
BÁSICOS DE OO
Conheceremos, a seguir, os principais termos e conceitos utilizados em análise 
e projeto OO. Vamos lá!
 ■ Objeto: qualquer elemento concreto ou abstrato que existe no mundo 
real, que se pode individualizar por possuir comportamentos e caracte-
rísticas próprios.
Figura 1 - Objetos concretos Figura 2 - Objetos abstratos
U
N
IC
ES
U
M
A
R
19
 ■ Abstração: abstraímos quando definimos um objeto conceitual partindo 
de objetos do mundo real com os mesmos comportamentos e caracterís-
ticas,os quais são classificados como de um mesmo tipo.
Figura 3 - Abstração de bolsa Figura 4 - Abstração de avião
Figura 5 - Abstração de esporte
 ■ Classe: representa a abstração de um conjunto de objetos do mundo 
real que possui comportamentos e características comuns.
Figura 6 - Classe funcionário
U
N
ID
A
D
E 
1
20
 ■ Instância: é cada umas das ocorrências de um objeto formado a partir 
da sua classe.
Figura 7 - Classe e objetos / Fonte: os autores.
 ■ Atributo: é uma característica particular que os objetos de uma classe 
possuem, assumindo valores diferentes para cada objeto.
Figura 8 - Classe, objeto e valor / Fonte: os autores.
 ■ Operação: é uma ordem que faz um objeto executar uma ação. As ope-
rações são tudo o que os objetos de uma classe fazem e nada além do 
que esses objetos podem fazer. 
Figura 9 - Operação / Fonte: os autores. 
U
N
IC
ES
U
M
A
R
21
 ■ Mensagem: representa o mecanismo de chamada de uma operação. É 
utilizada na solicitação de execução de uma operação. É a maneira como 
conseguimos que um método seja executado.
Figura 10 - Mensagem / Fonte: os autores. 
 ■ Evento: é um tipo especial de operação que faz com que os objetos mu-
dem de estado. 
Figura 11 - Evento / Fonte: os autores.
 ■ Parâmetro: é um ou mais atributos que são carregados para dentro de 
uma mensagem.
Figura 12 - Parâmetro - Avião, partida (linha aérea, número do voo, cidade) / Fonte: 
os autores.
U
N
ID
A
D
E 
1
22
 ■ Estado: é a forma de apresentação dos objetos de uma classe em deter-
minado instante.
Figura 13 - Estado / Fonte: os autores. 
 ■ Transição de estado: é quando ocorre a mudança de estado de um ob-
jeto de uma classe como resposta à chegada de um evento.
Estado Criado Estado Eliminado
Estado Parado Estado Decolando
Figura 14 - Transição de estado / Fonte: os autores. 
 ■ Associação: é a forma como os objetos de uma mesma classe ou de 
classes diferentes se conectam.
Figura 15 - Associação de classes / Fonte: os autores.
 ■ Encapsulamento: é a reunião de características e comportamentos de 
objetos em uma classe.
Figura 16 - Encapsulamento / Fonte: os autores. 
U
N
IC
ES
U
M
A
R
23
 ■ Polimorfismo: é a capacidade que objetos de classes diferentes possuem 
de se comportarem de forma diferente em uma mesma operação. A es-
trutura (atributos) de cada classe é diferente.
Figura 17 - Polimorfismo / Fonte: os autores. 
 ■ Método: é o algoritmo (conjunto de passos) que um objeto executa quan-
do reage a uma operação. O método é a lógica interna de uma operação. 
public int somar( int num1, int num2 )
{
 return num1 + num2;
 }
Quadro 1 - Declaração de um método / Fonte: os autores.
 ■ Colaboração: é a troca de mensagens que acontece entre objetos e atores
 ■ Figura 18 - Troca de mensagens entre os objetos / Fonte: os autores. 
 ■ Herança: é a propriedade que possibilita que a classe herde característi-
cas e comportamento de outra classe.
Figura 19 - Herança / Fonte: os autores.
U
N
ID
A
D
E 
1
24
4 
PRINCIPAIS
DIAGRAMAS DA UML
Agora que já conhecemos os principais termos utilizados na análise e no 
projeto OO, conheceremos os diagramas utilizados para documentação de 
software. A UML 2.5 apresenta vários diagramas, classificados em estruturais e de 
comportamento. A Figura 20 mostra esta organização em um diagrama de classes.
Figura 20 - Organização do diagrama UML / Fonte: os autores.
U
N
IC
ES
U
M
A
R
25
É comum verificarmos que a documentação do software, na maioria das vezes, não 
tem a devida atenção da equipe de desenvolvimento, por preguiça, ou por falta de 
tempo, ou mesmo por pensar que é perda de tempo elaborar inúmeros diagramas. 
Porém, bons softwares têm documentação que nos permite contar e entender a sua 
história. A seguir, conheceremos alguns dos diagramas mais utilizados na UML.
Diagramas de comportamento
Os diagramas de comportamento são utilizados para descrever o sistema mo-
delado em execução. São utilizados para especificar, visualizar, documentar e 
construir os aspectos dinâmicos de um sistema, ou seja, é a representação das 
partes que sofrem alterações. 
Diagrama de casos de uso
O diagrama de casos de uso (comportamento) é utilizado na análise de requisitos. 
Este diagrama acompanha o software desde o seu início até a conclusão.
Para conhecermos o conceito de caso de uso, temos que conhecer, primeira-
mente, o ator. Este pode ser uma pessoa (usuário), um sistema ou uma máquina. 
O ator é quem realiza as atividades e sempre atua sobre um caso de uso.
O diagrama de caso de uso da Figura 21 modela o comportamento dos atores 
no sistema de uma biblioteca. No exemplo, o diagrama mostra os atores aluno e 
bibliotecária, representados pelo stickman (“homem palito”) e suas respectivas 
ações descritas nas elipses.
Figura 21 - Diagrama de caso de uso / Fonte: os autores.
U
N
ID
A
D
E 
1
26
Diagrama de sequência
Com o objetivo de refinar o diagrama de classes, o diagrama de sequência (com-
portamento) é um dos vários tipos de diagrama de interação disponibilizados 
pela UML, sua utilidade é estudar as interações entre os objetos, possibilitando 
a identificação de relação entre as classes.
O cenário representado na Figura 22 mostra a solicitação de um empréstimo 
pelo aluno. A partir desta ação, é desencadeado um conjunto de mensagens entre 
os objetos, que, por sua vez, permite a verificação da existência da pessoa aluno, e, 
em seguida, é criado o item de empréstimo, que verifica a existência do exemplar 
solicitado, realizando o empréstimo.
Como é possível observar, a partir das informações fornecidas pelo diagra-
ma de sequência, pode-se identificar os métodos associados às classes, além da 
identificação das relações entre elas.
s
Figura 22 - Diagrama de sequência / Fonte: os autores. 
U
N
IC
ES
U
M
A
R
27
Outra forma de representar esse cenário é pelo diagrama de comunicação (com-
portamento). Ele contém as mesmas informações que o diagrama de sequência, 
porém não considera a dimensão temporal.
Diagrama de estados
Agora, veremos o diagrama de estados (comportamento), que tem como obje-
tivo especificar o comportamento das classes mais complexas, utilizando uma 
máquina de estados.
Autômato finito ou máquina de estados finitos representa a modelagem de comporta-
mentos considerando o seu estado. O estado guarda informações sobre o passado do 
objeto, a transição indica que o objeto está mudando de estado, e uma ação é o detalha-
mento de uma atividade que deve ser executada em determinado momento.
Fonte: adaptado de Sommervile (2011).
explorando Ideias
Não são todas as classes do sistema que apresentam mais de um estado. O diagrama 
de estado a seguir mostra todos os estados do exemplar no momento empréstimo. 
O início do estado é marcado pelo círculo, e o fim é marcado pelo duplo círculo.
Figura 23 - Diagrama de estado / Fonte: os autores. 
U
N
ID
A
D
E 
1
28
Diagrama de comunicação
O diagrama de comunicação permite a identificação das classes mais próximas, e 
a ordem de envio de mensagens é identificada por números sequenciais. A seguir, 
é apresentado o diagrama de comunicação equivalente ao diagrama de sequência 
mostrado anteriormente.
Figura 24 - Diagrama de comunicação (comportamento) / Fonte: os autores. 
Diagrama de atividades
O diagrama de atividade é, em sua essência, um gráfico de fluxo demonstran-
do como ocorre o fluxo de controle entre as atividades. Este diagrama é um dos 
mais detalhistas, dando mais ênfase ao nível de algoritmo.
Os diagramas de atividades podem ser utilizados com vários propósitos. Den-
tre eles, podemos citar a captura do funcionamento interno do objeto, mostrar 
como pode ser executado um conjunto de ações relacionadas e como elas podem 
afetar os objetos ao seu redor.
U
N
IC
ES
U
M
A
R
29
Figura 25 - Diagrama de atividades / Fonte: os autores. 
Diagramas de estrutura
Os diagramas estruturais são utilizados para especificar, visualizar, documentar e 
construir os aspectos estáticos de um sistema,ou seja, diagramas estruturais repre-
sentam a estrutura estável. A estrutura estática de um sistema envolve a existência 
e a colocação de itens como classes, pacotes, objetos, componentes e utilização.
Diagrama de classes
Após a elaboração do diagrama de caso de uso, podemos modelar a primeira ver-
são do diagrama de classes, pois este mostra a estrutura estática do sistema. Uma 
classe é uma estrutura que modela um conjunto de objetos cujas características 
são similares. A classe, por meio dos métodos, modela o comportamento de seus 
objetos, e os possíveis estados do objeto são modelados por meio de atributos.
U
N
ID
A
D
E 
1
30
Para entendermos melhor, faremos a analogia com a construção de um veícu-
lo. Todos os veículos serão rigorosamente iguais, pois estarão baseados em uma 
planta (projeto) que esclarece o número de portas, a potência do motor, o número 
de marchas do câmbio, entre outros atributos. Portanto, o projeto do veículo é a 
classe, e os veículos são os objetos que foram baseados na classe.
O diagrama de classes a seguir modela a estrutura estática do sistema de bi-
blioteca, apresentado em análise inicial. Por meio do diagrama de caso de uso, a 
classe possibilita a abstração dos objetos mediante os atributos (data: date; nome: 
string...) e métodos (Cria(); Recupera()...). 
Toda notação do diagrama será inteiramente desmistificada na Unidade 3, mas, 
para adiantar, é possível observar, neste diagrama, além das classes, que contêm 
atributos e métodos, as conexões entre as classes, que podem ser uma agregação, 
representada pelo losango, ou uma especialização, representada pelo triângulo.
Figura 26 - Diagrama de classes / Fonte: os autores.
Diagrama de objetos
Os diagramas de objetos correspondem a um segundo nível de abstração do 
diagrama de classes. Não têm a mesma importância que ele, porém podem ser 
uma ótima opção para exemplificar os diagramas de classes mais complexos.
O diagrama de objetos é o diagrama de classes instanciado. Utiliza a mesma 
notação deste para mostrar as instâncias da classe.
U
N
IC
ES
U
M
A
R
31
PESSOA
• Nome: “João da Silva”
• Fone: “(43) 3948-4039
ALUNO
• Curso: “Programação Java”
PROFESSOR
• Disciplina: “Java”
Figura 27 - Diagrama de objetos / Fonte: os autores.
Diagrama de componentes
Um diagrama de componente mostra a organização e dependência entre todos 
os componentes. Seu objetivo é modelar a visão de implementação dos módulos 
executáveis do software.
Apesar de ser um diagrama de alto nível, a organização do sistema é depen-
dente da linguagem de programação utilizada, portanto a solução de desenvol-
vimento adotada refletirá, diretamente, neste diagrama.
Um componente corresponde a uma parte do código distribuível, a qual pode 
ser substituída por outro componente e que contém elementos que mostram um 
conjunto de interfaces fornecidas e requeridas. Podemos apresentar como exemplos 
de componentes: os executáveis, as tabelas, as bibliotecas, o documento e o arquivo.
Figura 28 - Diagrama de componente / Fonte: os autores. 
U
N
ID
A
D
E 
1
32
Diagrama de implantação
Diagramas de implantação são utilizados para modelar a arquitetura física de 
distribuição em que o software será executado. Esse diagrama mostra os nós e 
os relacionamentos de comunicação.
O diagrama de implantação mapeia a arquitetura lógica de classe no nó de 
processamento e suas dependências. Um nó representa um recurso computa-
cional com memória e processamento, ou seja, um disco rígido, um computa-
dor, uma impressora etc. É uma ferramenta importante quando queremos saber 
quais computadores e outros hardwares estão conectados, bem como saber de 
que modo estão distribuídas as classes e quando a atualização de determinado 
arquivo resulta na recompilação de outros.
Figura 29 - Diagrama de implantação / Fonte: os autores.
U
N
IC
ES
U
M
A
R
33
Diagrama de pacotes
O pacote representa um agrupamento de classes, formando uma unidade. Nor-
malmente, os pacotes apresentam relações em que um depende de outro para o 
funcionamento. Como a estrutura de uma aplicação é dada pelas classes e associa-
ções, podemos agrupar as classes em pacotes de análise, o que facilita o manuseio 
do modelo de análise. 
Podemos utilizar o diagrama de pacotes para representar um conjunto de sub-
sistemas, e, neste caso, cada subsistema é representado por um pacote. Dessa forma, 
um pacote pode representar uma biblioteca, um subsistema, um sistema, entre 
outros, e, também, um pacote pode conter outros. Os pacotes, invariavelmente, 
apresentam dependência entre si, o relacionamento de dependência indica que 
o pacote dependente precisa, de alguma forma, daquele outro do qual depende.
Figura 30 - Diagrama de pacotes / Fonte: os autores.
U
N
ID
A
D
E 
1
34
CONSIDERAÇÕES FINAIS
Nesta unidade, aprendemos que a análise é a solução conceitual dada ao proble-
ma. Ela marca o início da definição informática, preocupa-se, principalmente, 
com as classes do domínio do problema e suas relações e, também, com os casos 
de uso. Já o projeto é o resultado do refinamento da análise e considera os detalhes 
da implementação, tais como a linguagem a ser utilizada e o sistema gerenciador 
de banco de dados.
Você se familiarizou com o conceito de Orientação a Objetos, ou, simples-
mente, OO, que é um novo paradigma para o desenvolvimento de aplicações, ou 
seja, é uma estratégia de desenvolvimento de software que organiza este como 
uma coleção de objetos, que contém tanto a estrutura dos dados quanto o com-
portamento deles.
Verificamos que os métodos de análise e projeto orientado a objetos surgiram 
assim que as linguagens de programação OO começaram a se estabilizar, sendo 
que um dos primeiros métodos foi o modelo OOSA, proposto por Shlaer e Mellor, 
em 1988, e o Wirfs-Brock, lançado em 1989, pelo grupo de pesquisa da Smalltalk.
Por meio do estudo da evolução dos métodos, podemos perceber que a UML 
– Unified Modeling Language é a fusão dos métodos de James Rumbaugh/OMT, 
Grady Boock e Ivar Jacobson. A fusão inicia com o trabalho de Rumbaugh e Boo-
ch; em seguida, em meados de 1996, Jacobson integrou-se ao grupo, e lançaram a 
UML versão 0.9. A partir daí, criaram forças com a cooperação da OMG (Object 
Management Group) em julho de 1997, considerado um padrão mundial.
Estudamos as características dos principais métodos OO, e foi possível verificar 
que a maioria das propostas abrangem as fases de análise, projeto, implementação 
e testes. Após conhecermos os principais métodos e estudarmos as suas caracte-
rísticas, entramos em contato com os conceitos de OO, em que aprendemos sobre 
objetos, abstração, classes, operações, atributos, instância, mensagem, entre outros.
Por fim, conhecemos os diagramas utilizados para documentação de software. 
Os diagramas de caso de uso, classes, estado, sequência e colaboração foram apre-
sentados de forma sucinta, já que os veremos com detalhes nas unidades seguintes. 
A partir dos conceitos que foram abordados nesta unidade, conseguimos ter 
uma visão geral sobre a Orientação a Objetos. Agora, você conhecerá as etapas 
da análise e notação para o diagrama de caso de uso.
35
na prática
1. Na análise e no projeto estruturados, o processo a ser informatizado é visto como 
um conjunto de funções com dados de entrada, processamento e dados de saída, ou 
seja, a ênfase está em funções que agem sobre dados. Diferentemente da análise e 
do projeto estruturados, na Orientação a Objetos, o processo a ser informatizado é 
visto como um conjunto de objetos que interagem para realizar as funções. Sabendo 
disso, quais as vantagens do modelo OO?
2. A maior parte dos métodos OO passaram a se tornar estáveis na década de 90, 
com a fusão das metodologias de Grady Boock, James Rumbaugh e Ivar Jacobson 
e a criação da UML, que se baseou, também, em outras metodologias, como a de 
Shlaer-Mellor. Diante do exposto, quais as fases comuns aos métodos propostos 
pelos autores citados?
3. A UML – Unified Modeling Languageabrange as fases de levantamento de requisi-
tos, análise, projeto e implementação. É dada como a fusão dos métodos de James 
Rumbaugh/OMT, Grady Boock e Ivar Jacobson. Quais dos conceitos elencados nas 
assertivas são próprios da orientação a objetos?
I - Objetos: qualquer elemento concreto ou abstrato com existência perceptível 
no mundo real.
II - Classes: abstração de um conjunto de objetos.
III - Atributo: característica particular possuída por todos os objetos de uma classe.
IV - Chave primária: identifica, unicamente, um objeto.
É correto o que se afirma em:
a) I, apenas.
b) I e II, apenas.
c) I, II e III, apenas.
d) III e IV, apenas.
e) I, II, III e IV.
36
na prática
4. É comum verificarmos que a documentação do software, na maioria das vezes, não 
tem a devida atenção da equipe de desenvolvimento, por preguiça, ou por falta 
de tempo, ou mesmo por pensar que é uma perda de tempo elaborar inúmeros 
diagramas. Bons softwares, porém, têm documentação que nos permite contar e 
entender a sua história, e contamos esta por meio de diagramas. Sabendo disso, 
quais diagramas são utilizados na UML e como estão organizados?
5. Leia o excerto a seguir e veja quais das alternativas preenche, corretamente, a lacuna:
O diagrama __________ contém as mesmas informações que o diagrama de sequência, 
porém não considera a dimensão temporal. 
Assinale a alternativa correta: 
a) De comunicação.
b) De caso de uso.
c) De classes.
d) De estado. 
e) De pacotes. 
37
aprimore-se
QUALIFICAÇÃO DE SOFTWARES
Como um software pode ser qualificado? É muito simplório definir isto pelo tempo 
de desenvolvimento ou pela excelência na programação. Existem casos de desen-
volvimento de softwares em que o programador ouve todas as informações e apre-
senta uma solução instantânea, quase que “mágica”, algo que resolve perfeitamente 
o que foi apresentado. Vendo desta forma, a sensação é que o atendimento foi 
excepcional, contudo, na maioria dos casos, programas feitos neste formato não 
suprem a real necessidade do cliente.
Não podemos julgar o cliente por não saber apresentar, de forma assertiva, as 
suas necessidades, pois o conhecimento da construção técnica é inexistente ou su-
perficial, não acompanha as tendências do mercado, entre outras hipóteses. E a 
consequência disso tudo é a perda de investimento financeiro e de tempo em um 
projeto que não suprirá a necessidade geral e uma programação desgastante, tanto 
para o programador quanto para o cliente. Casos assim não são exceções, é muito 
provável que você já os tenha vivenciado.
Este problema, porém, não é exclusivo do desenvolvimento de softwares, é cor-
riqueiro no mercado. Para provar isto, basta necessitarmos de um serviço que não 
temos nenhum conhecimento do processo, como consertar um carro. A solução 
só vem quando um profissional qualificado está mais preocupado em satisfazer o 
cliente do que resolver, exclusivamente, o seu problema apresentado. Os profissio-
nais que mantêm este método de atendimento são substituídos aos poucos. 
Na rotina diária de programação, normalmente, o início do projeto vem de uma 
conversa informal, e, só na primeira apresentação, depois de um bom tempo de de-
dicação, é que o cliente consegue esclarecer o que deseja, ainda de forma abstrata, 
por meio de frases como “não é bem isso que eu esperava”. Outro caso comum que 
acontece pela falta de alinhamento é o seguinte: as solicitações do cliente aumen-
tam durante o processo todo, e, como nada é estabelecido de forma clara no início 
do trabalho, você pode até prolongar o projeto, mas, possivelmente, não atenderá a 
todas as necessidades do seu cliente.
38
aprimore-se
Finalizo lembrando que o cliente não tem obrigação de entender como funciona 
toda a programação e que a preocupação em o atender deve ser do programador, 
não o contrário. Um bom profissional precisa “interpretar” a necessidade de um clien-
te e oferecer não o que ele está pedindo, mas, sim, o que suprirá a necessidade dele.
Fonte: o autor.
39
eu recomendo!
Desenvolvendo Software com UML 2.0: definitivo
Autor: Ernani Medeiros
Editora: Makron Books
Sinopse: este livro apresenta, de maneira prática e testada, o que 
é, para que serve e como usar os diagramas da UML 2.0. Além de 
sugerir o melhor momento para pensar em modelagem de banco 
de dados e propor passos dentro do processo de construção de 
software, também aborda parte técnica, notação, semântica, finalidade do con-
ceito e como usá-lo.
livro
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “A história de 
UML e seus diagramas”. Ele descreve a história da UML desde a década de 90 até 
o momento atual. É apresentada a organização dos 13 diagramas de UML, classi-
ficando-os em diagramas estruturais e comportamentais. Os quatro documentos 
pertencentes à especificação também são mencionados e explicados.
https://fdocumentos.tips/document/a-historia-de-uml-e-seus-diagramas.html
conecte-se
2
CASOS
DE USO
PROFESSORES 
Me. Déverson Rogério Rando
Esp. Janaína Aparecida de Freitas
PLANO DE ESTUDO 
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Fases da Análise e do Projeto • 
Modelos de Processo • Requisitos de Software • Diagrama de Casos de Uso.
OBJETIVOS DE APRENDIZAGEM 
Conhecer as fases de análise e projeto • Entender os modelos de processo • Compreender como ocorre 
o levantamento de requisitos • Diferenciar requisitos funcionais de não funcionais • Conhecer o diagra-
ma de caso de uso.
INTRODUÇÃO
Caro(a) aluno(a), iniciamos a segunda unidade do livro Análise e Projeto 
Orientado a Objetos falando sobre as fases da análise e do projeto de software.
Conheceremos cada uma das etapas da análise, que acreditamos ser a 
fase mais difícil e crítica da produção de um software. Difícil porque é o 
momento em que ocorrem as tentativas de delimitar o domínio do proble-
ma e entendê-lo; crítica porque uma análise malfeita comprometerá todas 
as outras fases de produção do software, além do fato de que o produto a 
ser entregue não será aquele que o cliente, inicialmente, requeria.
Entenderemos e conheceremos dois modelos de processos de software, 
dentre os diversos processos existentes. Citaremos, aqui, o modelo em cas-
cata e o evolucionário; em cascata, por ser o primeiro modelo de processo 
a ser utilizado; e evolucionário, por ser um dos modelos mais utilizados, 
principalmente, na fase de aprendizagem do problema. 
Veremos que os requisitos de software são objetivos ou restrições esta-
belecidos por clientes e usuários do sistema, que definem as diversas pro-
priedades dele. Aprenderemos como identificar os “requisitos funcionais”, 
que definem as funções do sistema, e os “requisitos não funcionais”, que 
definem outros tipos de características, os quais o sistema deverá possuir. 
Ainda, veremos a importância do levantamento de requisitos para o 
desenvolvimento de software. Aprenderemos que a definição de requisitos 
pode utilizar uma narrativa ou representações gráficas. Por meio dessas 
definições, pode ser elaborado o documento preliminar de requisitos.
E, finalmente, conheceremos o diagrama de caso de uso, em que enten-
deremos a notação e o objetivo do caso de uso na fase de análise do softwa-
re. Esses diagramas são utilizados para representar, de forma panorâmica, 
os requisitos funcionais de um sistema do ponto de vista do usuário.
Então, o que estamos esperando? Vamos ao trabalho! Boa leitura a todos.
U
N
ID
A
D
E 
2
42
1 
FASES
DA ANÁLISE
e do projeto
Como vimos na primeira unidade, a análise de sistemas é a atividade inicial do 
processo de desenvolvimento de software em que se determina e especifica o que 
um sistema deve fazer, assim como as circunstâncias sob as quais ele deve operar, 
envolvendo, geralmente, esforço colaborativo entre analistas de sistemas e usuá-
rios. De acordo com Sommervile (2011), a análise é realizada com os seguintes 
objetivos em mente: 
 ■ Identificar a necessidade do usuário.
 ■ Executaranálise econômica e técnica.
 ■ Atribuir funções a hardware, software, pessoas, banco de dados e demais 
elementos do sistema.
 ■ Estabelecer as restrições de prazo e de custo.
 ■ Criar uma definição de sistema que constitua a base para todo o trabalho 
subsequente.
Independentemente do método ou processo utilizado para a análise, o projeto e 
a implementação, algumas etapas são comuns, são elas (SOMMERVILE, 2011):
 ■ Identificação da necessidade.
 ■ Estudo de viabilidade.
 ■ Análise.
 ■ Projeto (ferramentas).
U
N
IC
ES
U
M
A
R
43
 ■ Implementação (codificação).
 ■ Implantação.
 ■ Manutenção (adaptativa, corretiva e evolutiva).
A seguir, conheceremos cada uma dessas etapas de suma importância para a 
produção de um software de qualidade.
Identificação da necessidade
Comentaremos cada uma dessas etapas começando pela identificação da ne-
cessidade, que é o ponto de partida na evolução de um sistema. Nesta etapa, são 
definidas as metas globais do sistema, respondendo a algumas perguntas-chave:
 ■ Quais informações serão produzidas?
 ■ Quais informações devem ser fornecidas?
 ■ Que funções e desempenho são exigidos?
Ainda nesta etapa, após a definição das metas, o analista deve avaliar:
 ■ Existe tecnologia para construir o sistema?
 ■ Qual é o custo de produção e o tempo necessário para conclusão?
Caso o novo sistema seja um produto a ser desenvolvido para a venda direcio-
nada a muitos clientes, o analista, ainda, deve avaliar o seguinte:
 ■ Qual é o mercado em potencial para o produto?
 ■ Como este produto se compara com os produtos dos concorrentes?
Estudo de viabilidade
Na etapa seguinte, temos a análise de viabilidade, em que o analista deve determi-
nar, rapidamente, se o problema pode ser resolvido considerando cinco aspectos 
de viabilidade: técnico, legal, operacional, temporal e econômico.
No aspecto da viabilidade técnica, o analista deve determinar se o projeto 
pode ser desenvolvido e implementado usando os recursos existentes: computa-
dores, periféricos e sistema operacional. E, também, se existe pessoal competente 
à disposição para desenvolver o sistema em questão (SOMMERVILE, 2011).
U
N
ID
A
D
E 
2
44
No aspecto da viabilidade legal, o analista verifica se não existem conflitos 
entre o sistema em consideração e os compromissos legais que a empresa tem. 
O analista deve considerar as implicações legais que aparecem nos estatutos es-
taduais/federais e nas cláusulas contratuais.
No aspecto operacional, o analista faz a verificação de que o sistema será 
capaz de executar as funções projetadas no ambiente organizacional existente, 
com o pessoal atual.
No aspecto de tempo, o analista deve determinar o cronograma para desen-
volvimento e verificar se o sistema será factível no tempo determinado.
O último aspecto é o da viabilidade econômica, em que o analista deve de-
terminar se os benefícios sobrepõem os custos; se a despesa estimada ultrapassar 
a expectativa da administração ou se os benefícios não justificarem os custos, o 
projeto, provavelmente, será abandonado.
Análise
A coleção exata dos dados é essencial para a análise completa de um sistema, por-
tanto o analista deve considerar os seguintes objetivos (SOMMERVILE, 2011):
 ■ Entender os objetivos do sistema (o que o administrador/usuário espera dele).
 ■ Entender as exigências do sistema (o que processar e que saídas produzir).
 ■ Entender que os objetivos e as exigências são satisfeitos por meio de cui-
dadosa análise. 
 ■ Entender as áreas-problema do sistema.
Para tanto, são utilizadas técnicas para o levantamento de dados, tais como:
 ■ Estudo dos manuais de procedimentos.
 ■ Análise de formulários.
 ■ Entrevista.
 ■ Questionário.
 ■ Observação.
U
N
IC
ES
U
M
A
R
45
Projeto
Após a análise, ou levantamento de requisitos, ou, ainda, engenharia de requisitos 
(como quiser chamar), vem o projeto, que é a solução informática dada ao problema.
De acordo com Sommerville (2011), o projeto de software descreve a es-
trutura do software que será implementado. Nele, estão contidos os dados e a 
interface entre os componentes do sistema. Na primeira versão do projeto, ainda 
não é possível detalhar completamente o sistema, pois, ao elaborar modelos com 
diferentes níveis de abstração, é possível detectar problemas nos níveis anteriores. 
A cada nível seguinte, são criados modelos mais detalhados, diminuindo, cada vez 
mais, a abstração. O projeto de software é importante para formalizar as regras de 
negócio do sistema, melhorando a comunicação entre o cliente e o programador.
Implementação
É neste estágio de desenvolvimento de software em que se cria uma versão exe-
cutável ele, utilizando as ferramentas para desenvolvimento definidas no projeto. 
A implementação pode iniciar após o término do projeto ou pode acontecer de 
forma paralela a ele, tudo depende do modelo de processo escolhido.
Implantação
A implantação corresponde à fase na qual o software será entregue ao cliente. Na 
fase do estudo da viabilidade, foi levantada, pelo analista, a viabilidade técnica, 
em que se buscou verificar se o projeto pode ser desenvolvido e implementado 
usando os recursos existentes: computadores, periféricos, sistema operacional, 
entre outros, e, também, se existe pessoal competente à disposição para desen-
volver o sistema em questão.
Todo o projeto é construído com base no estudo de viabilidade técnica, utili-
zando ferramentas suportadas pelo hardware e entendida pelos usuários, portan-
to os riscos da implantação não funcionar são minimizados no projeto. O fator 
U
N
ID
A
D
E 
2
46
mais preocupante, nesta fase, é, justamente, o período que será necessário para a 
adaptação do usuário com o novo sistema, pois toda mudança gera transtornos, 
na maioria das vezes, o usuário está acostumado a executar suas tarefas de de-
terminada forma, e a mudança é vista com restrição.
Manutenção
A manutenção é o processo de modificar o sistema desenvolvido depois que ele é 
colocado em operação, é a fase do ciclo de vida do software que dura mais tempo, 
até que o sistema deixe de ser utilizado.
O software é continuamente modificado ao longo de seu tempo de duração, 
em resposta a requisitos em constante modificação e às necessidades do cliente. 
As manutenções não dizem respeito somente à correção do software, mas tam-
bém a motivos que não foram possíveis de observar no momento da análise, do 
projeto ou, mesmo, da implementação.
As manutenções podem ser adaptativas, cujo objetivo, como o próprio nome 
diz, é adaptar algumas tarefas ou funções para o ambiente de implantação. As 
manutenções também podem ser evolutivas, cujo objetivo é a inserção de novos 
módulos no sistema.
Projeto é o que quase todo engenheiro quer fazer. É o lugar onde a criatividade impera 
— onde os requisitos dos interessados, as necessidades da aplicação e considerações 
técnicas se juntam na formulação de um produto ou sistema. O projeto cria uma repre-
sentação ou modelo do software, mas diferentemente do modelo de requisitos (que se 
concentra na descrição do “O que” é para ser feito: dos dados, função e comportamento 
necessários), o modelo de projeto indica “O Como” fazer, fornecendo detalhes sobre a ar-
quitetura de software, estruturas de dados, interfaces e componentes fundamentais para 
implementar o sistema. Os engenheiros de software conduzem cada uma das tarefas de 
projeto. Por que é importante? O projeto permite que se modele o sistema ou produto 
a ser construído. O modelo pode ser avaliado em termos de qualidade e aperfeiçoado 
ANTES de o código ser gerado, ou de os testes serem realizados, ou de os usuários finais 
se envolverem com grandes números. 
Fonte: Pressman (2011, p. 206, grifo do autor).
explorando Ideias
U
N
IC
ES
U
M
A
R
47
2 
MODELOS
DE PROCESSO
A análise e o projeto de sistemas de software devem fornecer para os stakeholders, 
a equipe envolvida, composta pelo cliente, analista, programador, entre outros, 
uma única compreensão do projeto. De acordo com Medeiros (2004),a UML não 
é um método, mas, sim, uma linguagem. Um método é composto por processos 
e um modelo de linguagem. Os processos são os passos que devem ser seguidos 
para construir o projeto. O modelo de linguagem é a notação que o método usa 
para descrever o projeto, enquanto um modelo de processo de software define a 
sequência em que as atividades do processo serão realizadas.
Modelo cascata
Tomaremos como exemplo o mode-
lo de processo em cascata, ou queda 
d’água, como colocado por alguns 
autores.
Figura 1 - Modelo cascata / Fonte: adaptada de 
Sommerville (2011).
U
N
ID
A
D
E 
2
48
Conhecido como ciclo de vida clássico, o modelo em cascata é o primeiro a ser 
publicado do processo de desenvolvimento de software. O modelo considera as 
atividades de especificação, desenvolvimento, validação e evolução como fases 
separadas do processo.
A primeira fase é a análise e definição de requisitos (especificação de requi-
sitos). As funções, as restrições e os objetivos do sistema são estabelecidos por 
meio da consulta aos usuários.
A segunda fase é o projeto de sistemas e de software, em que os requisitos em 
sistemas de hardware ou de software são agrupados, estabelecendo uma arqui-
tetura do sistema geral.
A terceira fase é a implementação e o teste de unidades. Durante este estágio, 
o projeto de software é compreendido como um conjunto de programas ou de 
unidades de programa. O teste de unidade envolve verificar que cada unidade 
atende à sua especificação.
A quarta fase é a integração e o teste de sistemas. Neste estágio, as unidades de 
programa ou programas individuais são integrados e testados como um sistema 
completo, a fim de garantir que os requisitos de software foram atendidos.
A quinta fase é a operação e manutenção. Normalmente, esta é a fase mais longa 
do ciclo de vida. O sistema é instalado e colocado em operação. A manutenção envolve 
corrigir erros que não foram descobertos em estágios anteriores do ciclo de vida ou 
aumentar as funções desse sistema à medida que novos requisitos são descobertos.
Neste modelo de processo em cascata, pressupõe-se que o domínio do pro-
blema foi inteiramente compreendido, portanto é o modelo indicado quando 
conhecemos por inteiro a regra de negócio do software.
Modelo evolucionário
Quando estamos produzindo um software e ainda não conhecemos todo o do-
mínio do problema, é recomendável a utilização do modelo de desenvolvimento 
evolucionário. Este tem, como base, a ideia de desenvolver uma implementação 
inicial, expor o resultado ao comentário do usuário e fazer seu aprimoramento por 
meio de muitas versões, até que um sistema adequado seja desenvolvido.
Em vez de ter as atividades de especificação, desenvolvimento e validação em 
separado, todo esse trabalho é realizado concorrentemente, com rápido feedback 
por meio dessas atividades. A Figura 2 ilustra bem as fases do modelo evolucionário.
U
N
IC
ES
U
M
A
R
49
Figura 2 - Modelo evolucionário / Fonte: adaptada de Sommerville (2011).
Devido à característica de produzir sistemas que atendam às necessidades ime-
diatas do usuário, muitas vezes, o modelo evolucionário é mais eficaz do que a 
abordagem em cascata. A vantagem da abordagem evolucionária está na espe-
cificação, que pode ser desenvolvida gradualmente, à medida que os usuários 
compreendem melhor o problema.
Como nem tudo são flores, porém, problemas acontecem nesse modelo; enu-
meraremos alguns deles:
 ■ Como os sistemas são desenvolvidos rapidamente, não é viável produzir 
documentos que reflitam cada versão do sistema.
 ■ Os sistemas, frequentemente, são mal estruturados. A mudança constan-
te tende a corromper a estrutura do software, incorporar modificações 
torna-se cada vez mais difícil e oneroso.
Utilizando o modelo em cascata, ou o evolucionário ou qualquer outro modelo 
de desenvolvimento, é possível, nas fases de análise e projeto, optar por uma 
abordagem de análise e projeto estruturado, dessa forma, construiremos Diagra-
mas de Entidade-Relacionamento (DER), Diagrama de Fluxo de Dados (DFD), 
diagrama de contexto, dicionário de dados etc. Esses modelos fornecem uma 
compreensão única do projeto.
O foco da nossa disciplina, contudo, é a orientação a objetos, portanto, nas 
fases de análise e projeto, construiremos diagramas de caso de uso, de classes, de 
estado, de sequência etc. Esses modelos também fornecerão uma compreensão 
única do projeto.
U
N
ID
A
D
E 
2
50
Linguagem de modelagem – UML
A linguagem de modelagem é uma parte muito importante do método. Corresponde 
ao ponto principal da comunicação. Se uma pessoa quer conversar sobre o projeto 
com outra pessoa, é por meio da linguagem de modelagem que elas se entendem.
A UML define uma notação e um meta-modelo. Todos os elementos de repre-
sentação gráfica vistos no modelo (retângulo, setas, texto etc.) são a notação, essa 
é a sintaxe da linguagem de modelagem. A notação do diagrama de classes define 
a representação de itens e conceitos, tais como: classe, associação e multiplicidade. 
Visto isto, é possível concluir que, independentemente do modelo de processo de 
software que você escolheu, é de suma importância que o domínio do problema 
seja entendido por todos da equipe de desenvolvimento, inclusive o cliente.
A figura a seguir ilustra, de forma lúdica, o que ocorre em um projeto de 
software em que a equipe de desenvolvimento e o cliente não se entendem. 
U
N
IC
ES
U
M
A
R
51
Figura 3 - Charge sobre projeto de software / Fonte: Ampersand (2013, on-line, traduzido 
pelo autor)1.
Pense em quais habilidades o analista deve possuir, uma vez que lida com vários grupos 
de usuários, além de se preocupar com o desenvolvimento e com todos os componentes 
do sistema.
pensando juntos
U
N
ID
A
D
E 
2
52
3 
REQUISITOS
DE SOFTWARE
Agora que já sabemos a importância da análise e do projeto na produção de um 
software, conheceremos os procedimentos mínimos necessários para a obtenção 
de um software de qualidade.
Para tal, precisamos fazer uma engenharia de requisitos, mas o que é isso? 
Vamos por partes, então. O termo “engenharia” permite dizer que se utiliza um 
processo sistemático na definição do software. Nesse contexto, a engenharia de 
requisitos tem, como objetivo, compreender o sistema, ou seja, preocupa-se com 
“o que fazer”, e não com o “como fazer”. As principais atividades da engenharia de 
requisitos são (SOMMERVILE, 2011):
 ■ Especificar o problema (elicitar).
 ■ Compreender o problema (analisar).
 ■ Definir uma proposta (modelo válido).
 ■ Atualizar requisitos (gerenciar).
Na primeira atividade, que é elicitar, devemos obter o máximo de informações 
para o conhecimento do objeto em questão dentro do domínio do problema.
U
N
IC
ES
U
M
A
R
53
Domínio 
O que é domínio? Para entender melhor, imaginaremos que você foi contrata-
do(a) para desenvolver um software em determinada Casa de Carnes. Do lado 
direito da Casa de Carnes, existe uma farmácia, do lado esquerdo, um mercado, 
atrás, uma lanchonete e, em frente, uma igreja. Neste caso, o domínio do seu 
problema é a Casa de Carnes, os demais estabelecimentos estão na fronteira do 
seu problema, portanto não fazem parte dele. Creio que, dessa forma, fica fácil 
compreender o que é o domínio do problema.
É óbvio que determinar o domínio do problema não é uma tarefa trivial, pois 
você pode ser contratado(a) para desenvolver um software para determinado 
departamento de uma empresa, dessa forma, determinar esse domínio se torna 
mais complexo.
Sendo assim, os limites do domínio (fronteira) podem ser determinados por 
meio do estabelecimento dos objetivos pretendidos. Para tanto, não devemos 
centrar em funcionalidades, mas, sim, em finalidade.
Requisitos
Os requisitos são os objetivos e as restrições estabelecidas pelo usuário do sis-
tema. É o usuário ou o cliente o responsável por descrever as necessidades ou 
o desejo para o software (SOMMERVILE, 2011). Em um primeiro momento, é 
interessante definir os requisitos sem se preocuparem detalhá-los, isto permite 
ter uma visão global do domínio de maneira mais rápida.
Para a definição de requisitos, produzimos um documento contendo decla-
rações, em linguagem de alto nível, dos requisitos e restrições do sistema. Já na 
especificação, produzimos um documento estruturado contendo requisitos e 
restrições descritos detalhadamente. Vamos aos exemplos.
U
N
ID
A
D
E 
2
54
Definições de requisitos:
1. O software deve proporcionar um meio para representar e acessar arquivos exter-
nos criados por outros aplicativos.
Especificação de requisitos:
1.1. O usuário deverá ser provido de recursos que permitam definir os tipos de arqui-
vos externos que serão acessados.
1.2. Para cada tipo de arquivo externo, deve ser associado o aplicativo que o gerou.
1.3. A cada tipo de arquivo externo, deve ser associado um ícone específico.
1.4. Deverá ser permitido ao usuário definir os ícones que serão utilizados na repre-
sentação dos arquivos externos.
Quadro 1 - Exemplos de definições e especificação de requisitos / Fonte: o autor.
Na definição de requisitos, pode-se utilizar uma narrativa ou representações grá-
ficas. Normalmente, as informações coletadas são fornecidas pelo usuário. Por 
meio dessas definições, pode ser elaborado o documento preliminar de requisitos. 
Eles podem ser divididos em: 
 ■ Requisitos funcionais (RF).
 ■ Requisitos não funcionais (RNF).
Os requisitos funcionais definem as funções do sistema, ou seja, o que se espera 
que o sistema faça. Eles relatam as diversas funções que deverão ser providas pelo 
software ao cliente ou usuário. Por exemplo:
 ■ Monitorar sensores de temperatura.
 ■ Cancelar o débito na conta corrente caso a operação não seja completada.
 ■ Avisar quando o estoque chegar ao limite mínimo.
Os requisitos não funcionais estão relacionados às tecnologias utilizadas, à usa-
bilidade, ao desempenho, à segurança, confiabilidade, manuteniblidade e dispo-
nibilidade que o sistema deverá possuir. Por exemplo:
 ■ O sistema deverá apresentar interface gráfica (padrão Windows).
 ■ Facilidade de uso.
 ■ Possibilidade de ajuda no contexto.
U
N
IC
ES
U
M
A
R
55
A partir das definições dos requisitos, produzimos o documento preliminar deles, 
que deve conter todos os serviços (requisitos) requeridos pelo cliente, explicitados 
de forma clara, sem contradições. Atingir este objetivo é uma tarefa difícil pelas 
inúmeras dificuldades que são encontradas no domínio. Mas, para que essas 
dificuldades sejam superadas, o documento preliminar de requisitos deve conter 
algumas características de qualidade. Segundo Pressman (1995), são elas:
Característica 1 – Precisam ser corretas: cada declaração de requisito deve 
expressar, exatamente, a funcionalidade almejada. Declarações de requisitos 
que conflitam com suas respectivas necessidades não estão corretas, apenas 
o usuário pode determinar se a declaração está correta por meio de inspe-
ções. Inspeções em que não há a participação do usuário podem tornar o 
documento de requisitos um documento de adivinhações.
Característica 2 – Precisam ser possíveis: você deve ser hábil em imple-
mentar cada requisito declarado, observando os recursos e as limitações do 
sistema e ambiente. Para evitar requisitos impossíveis, trabalhe, com o pes-
soal técnico, o documento de requisitos, checando o que é ou não possível 
fazer, avaliando custos e viabilidade.
Característica 3 – Precisam ser necessários para o projeto: cada declaração 
de requisito deve documentar apenas as necessidades do cliente ou qualquer 
outra necessidade que exija atender a um requisito externo, ou a uma interfa-
ce externa ou, ainda, um padrão. Você pode pensar que “necessário” significa 
cada requisito com origem na fonte que tem autoridade para determiná-lo.
Característica 4 – É necessário definir prioridades: atribua uma prioridade 
de implementação para cada requisito, ou, ainda, defina casos de uso que 
auxiliem na indicação do quanto é essencial um requisito para o produto. 
Clientes devem ter sua parte na responsabilidade do estabelecimento de 
prioridades. Se todos os requisitos forem igualmente prioritários, você deve 
ter a habilidade de definir com o cliente a prioridade de cada um.
U
N
ID
A
D
E 
2
56
Característica 5 – Não podem ser ambíguas: cada declaração deve ser ex-
plicitada de maneira que permita somente uma interpretação. Linguagem 
natural é altamente propensa a ambiguidades, elimine termos subjetivos, 
como: amigável ao usuário, fácil, simples, rápido, eficiente, vários, aperfeiçoar, 
maximizar e minimizar. Escreva cada requisito na linguagem do cliente de 
forma sucinta, simples, direta, sem utilizar jargões técnicos.
Característica 6 – Precisam ser verificáveis: veja se é possível aplicar tes-
tes ou utilizar outras abordagens para verificações, tais como inspeções ou 
demonstrações para se certificar de que cada requisito será implementado 
apropriadamente. Requisitos que não são consistentes, possíveis ou despro-
vidos de ambiguidades também não são verificáveis.
Após o estágio de elicitação (extração), um documento contendo os requisitos 
do cliente (necessidades, restrições, objetivos etc.) é definido. Esse documento, 
que poderíamos chamar de Documento Preliminar de Requisitos, deverá sofrer 
um processo de análise.
A fase de análise, por sua vez, envolve uma série de atividades (SOMMER-
VILE, 2011):
 ■ Validação e verificação.
 ■ Análise de viabilidade.
 ■ Resolução de conflitos.
 ■ Definição de prioridade.
Os requisitos coletados devem ser verificados e validados, com o objetivo de garantir 
se estão completos, consistentes e de acordo com as reais necessidades do domínio. 
Assim como nos demais procedimentos da análise de requisitos, a participação dos 
interessados deve ser intensa, ou seja, todos os agentes que, direta ou indiretamente, 
influenciam os requisitos do sistema precisam estar envolvidos nesse processo.
U
N
IC
ES
U
M
A
R
57
Os casos de uso têm um papel importantíssimo na análise de requisitos, pois 
permitem criar um cenário do domínio, e, talvez, este seja o único instrumento 
que acompanha o software do início até seu término, além disso, casos de uso 
representam funcionalidades completas para o usuário e não funcionalidades 
internas do sistema. Outro ponto importante é que o diagrama de casos de uso 
é um artefato de comunicação entre cliente, usuários e desenvolvedores. Por ser 
extremamente simples e, consequentemente, de fácil compreensão, incentiva a 
participação do cliente e dos usuários no processo de desenvolvimento, também 
serve como um contrato entre a equipe desenvolvedora e o cliente.
A coleção de casos de uso representa todos os modos pelos quais o sistema 
pode ser utilizado pelos atores envolvidos. Um caso de uso é uma sequência de 
ações realizada, colaborativamente, pelos atores envolvidos e pelo sistema que 
produz um resultado significativo (com valor) para os atores, e estes podem ser 
um usuário ou outro sistema. 
O diagrama de casos de uso é apenas um panorama visual das funciona-
lidades do sistema, é necessária uma descrição textual para detalhar os casos. 
Portanto, a saída da fase de análise de requisitos é composta por:
 ■ Lista de requisitos funcionais e não funcionais.
 ■ Diagrama de casos de uso e definições textuais dos casos.
A especificação de requisitos é o processo de escrever os requisitos de usuário e de sis-
tema em um documento de requisitos. Idealmente, os requisitos de usuário e de sistema 
devem ser claros, inequívocos, de fácil compreensão, completos e consistentes. Na práti-
ca, isso é difícil de conseguir, pois os stakeholders interpretam os requisitos de maneiras 
diferentes, e, muitas vezes, notam-se conflitos e inconsistências inerentes aos requisitos. 
Os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não 
funcionais de modo que sejam compreensíveis para os usuários do sistema que não te-
nham conhecimentos técnicos detalhados. Idealmente, eles devem especificar somente o 
comportamentoexterno do sistema. O documento de requisitos não deve incluir detalhes 
da arquitetura ou projeto do sistema. 
Fonte: Sommerville (2011, p. 65).
explorando Ideias
U
N
ID
A
D
E 
2
58
4 
DIAGRAMA
DE CASOS DE USO
Agora que já conhecemos o contexto de requisito de software, vamos para a con-
fecção do diagrama de caso de uso. O modelo de casos de uso (que é mais do que 
o diagrama) é o principal resultado da fase de análise de requisitos, e, também, 
diagramas de casos de uso são utilizados para representar, de forma panorâmica, 
os requisitos funcionais de um sistema do ponto de vista do usuário. 
O modelo de caso de uso é um diagrama utilizado na análise de requisitos 
com objetivos claros:
 ■ Compreender o problema (elicitar).
 ■ Delimitar o sistema (domínio).
 ■ Definir as funcionalidades oferecidas ao usuário (não precisamos nos 
preocupar, neste momento, com a implementação).
Conhecer a notação para os diagramas de caso de uso preconizados pela UML. 
Os elementos básicos deste diagrama são:
 ■ Atores.
 ■ Casos de uso.
 ■ Relações entre atores e casos de uso.
U
N
IC
ES
U
M
A
R
59
Atores
Começaremos, então, pelo homem palito, que representa um 
ator no meu sistema. Esse ator pode ser uma pessoa, outro sis-
tema ou uma entidade externa ao sistema. 
Como encontrar os atores para um sistema? Usando as 
seguintes dicas:
 ■ Examine o problema procurando por pessoas ou sis-
temas do entorno.
 ■ Faça as seguintes perguntas:
 ■ Quais são as pessoas ou os departamentos interessados em determi-
nado requisito funcional?
 ■ Quem suprirá o sistema com informações e quem receberá informa-
ções dele?
 ■ Quais os recursos externos utilizados pelo sistema?
 ■ Uma pessoa desempenha diferentes papéis?
 ■ O sistema interage com outros sistemas existentes?
Essas dicas também não garantem que o ator foi bem escolhido da primeira vez, 
pois este é um processo iterativo; dificilmente, a primeira tentativa será a definitiva. 
Figura 4 - O ator /
Fonte: os autores. 
Os casos de uso são documentados por um diagrama de casos de uso de alto nível. O 
conjunto de casos de uso representa todas as possíveis interações que serão descritas 
nos requisitos de sistema. Atores, que podem ser pessoas ou outros sistemas, são repre-
sentados como figuras “palito”. Cada classe de interação é representada por uma elipse. 
Linhas fazem a ligação entre os atores e a interação. Opcionalmente, pontas de flechas 
podem ser adicionadas às linhas para mostrar como a interação se inicia. Não há distin-
ção entre cenários e casos de uso que seja simples e rápida. Algumas pessoas consideram 
cada caso de uso um cenário único; outros, encapsulam um conjunto de cenários em um 
único caso de uso. Cada cenário é um segmento através do caso de uso. Portanto, seria 
um cenário para a interação normal, além de cenários para cada possível exceção. Você 
pode, na prática, usá-los de qualquer forma.
Fonte: Sommerville (2011, p. 74).
explorando Ideias
U
N
ID
A
D
E 
2
60
Casos de uso
A coleção de casos de uso representa, do ponto de vista do usuário, todos os 
modos de execução do sistema. Um caso de uso é uma sequência de ações que 
produz um resultado significativo para um ator, e, assim, são necessárias as se-
guintes definições:
 ■ As tarefas de cada ator.
 ■ Quais informações o ator obtém do sistema.
 ■ Quem fornece as informações.
 ■ Quem captura as informações.
 ■ Se algum ator precisa ser informado sobre eventos produzidos pelo sistema.
 ■ Se existem eventos externos que devem ser notificados ao sistema.
A elipse é a notação para os casos de uso, ou use case, na verdade, as duas denomi-
nações são utilizadas. Um caso de uso representa uma atividade que o ator realiza.
O caso de uso necessita de uma descri-
ção, porém, não há descrição padrão 
definida pela UML. Em geral, o diagra-
ma é bastante informal e sua estrutura-
ção (relação entre casos) não deve ser 
levada ao extremo. É importante ressal-
tar que o diagrama de casos de uso é 
uma forma de visualizar os casos, e não 
de descrevê-los detalhadamente.
Sendo assim, o diagrama, por si só, não é suficiente. Os casos de uso devem vir 
acompanhados de uma descrição em que, normalmente, relacionamos os se-
guintes itens:
 ■ Nome.
 ■ Descrição.
 ■ Requisitos funcionais providos pelo caso de uso.
 ■ Restrições, tais como pré e pós-condições.
Figura 5 - Caso de uso / Fonte: os autores.
U
N
IC
ES
U
M
A
R
61
 ■ Pré-condições: define o que deve ser verdadeiro para que o caso de uso 
seja iniciado. Por exemplo, em um sistema para seguro de veículo, para o 
caso de uso Fazer Seguro Veicular, uma pré-condição é apresentar a CNH. 
 ■ Pós-condições: o que se torna verdadeiro pela execução do caso de uso. No 
mesmo caso anterior, o sistema pode se encontrar em um dos seguintes es-
tados: seguro concedido ou seguro não concedido por reprovação da CNH.
 ■ Invariantes: condições que são verdadeiras durante a execução do caso de uso.
 ■ Fluxos de eventos: descrição de interações entre atores e sistema que ocor-
rem durante a execução do caso de uso.
 ■ Outras informações: data, autor etc.
Relações de dependência
As relações de dependência são representadas por uma seta tracejada, ela parte 
do caso de uso que depende de outro em algum momento. O diagrama da Figura 
6 nos diz que, para o cadastro de aluno, é necessária a conclusão do cadastro de 
pessoa.
´
Figura 6 - Dependência / Fonte: os autores. 
Se um caso de uso inclui o comportamento de outro, então dizemos que um usa 
o outro. Aqui, a linha tracejada com uma seta também pode representar uma 
inclusão de outro caso de uso. No exemplo da Figura 7, o caso de uso Calcular 
Contas a Receber utilizará a forma de cálculo que está na documentação de Cal-
cular Contas a Pagar; usamos este artifício para evitar a necessidade de digitar 
duas vezes a mesma especificação.
U
N
ID
A
D
E 
2
62
<<include>>
Calcular contas
a pagar
Calcular contas
receber
Figura 7 - Inclusão / Fonte: os autores.
Já as extensões adicionam um comportamento a um caso de uso que descreve 
uma variação do comportamento normal. Nesta situação, o caso de uso base 
pode ser executado mesmo sem a extensão. O modelo da Figura 8 mostra que 
existe um cálculo em Calcular Descontos que se estenderá para Calcular Contas 
a Pagar, ampliando o significado da fórmula existente em Calcular Descontos.
Figura 8 - Extensão / Fonte: os autores.
Vale lembrar que o diagrama de casos de uso é apenas um panorama visual das 
funcionalidades do sistema; é necessária uma descrição textual para detalhar os 
casos de uso. 
Ilustraremos esta documentação, por meio do caso de uso, para resolver ex-
pressões aritméticas.
Figura 9 - Diagrama de caso de uso / Fonte: os autores.
U
N
IC
ES
U
M
A
R
63
Podemos fazer a descrição textual para o caso de uso Resolver Expressões Arit-
méticas de acordo com o quadro a seguir:
Nome do caso de uso Resolver Expressões Aritméticas.
Descrição
Permite resolver expressões envolvendo 
números inteiros e reais e as operações 
básicas de soma, subtração, multiplica-
ção e divisão.
Ator Aluno.
Pré-condições O sistema deve estar em execução.
Pós-condições
Expressão aritmética resolvida ou cance-
lamento da operação pelo aluno.
Fluxo básico
Usuário Sistema
{Solicita expressão}
Solicita a expressão (A2).
Fornece a expressão
{Valida a expressão}
Avalia se a expressão é sintaticamente 
correta (A1).
{Calcula valor}
Calcula o valor da expressão.
{Mostra o resultado}
Informa o resultado da expressão.
{Fim}
Fim do caso de uso.
U
N
ID
A
D
E 
2
64
Fluxos alternativos
A1: em {Valida expressão}
Se o usuário fornecer uma expressão 
sintaticamente incorreta, informá-lo so-
bre o erro e retornar ao fluxo básico em 
{Solicita expressão}
A2: em {Solicita expressão}
O usuário pode decidir encerrar o caso de 
uso sem fornecer uma expressão. Neste 
caso, retornar ao fluxo básico em {Fim}
Quadro 2 - Resolver Expressões Aritméticas / Fonte: os autores.
Essa descrição textual detalha o caso de uso,