Material de Estudo

Prévia do material em texto

ANÁLISE E 
PROJETO 
ORIENTADO A 
OBJETOS
Professor Me. Déverson Rogério Rando
GRADUAÇÃO
Unicesumar
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a 
Distância; RANDO, Déverson Rogério. 
 
 Análise e Projeto Orientado a Objetos. Déverson Rogério 
Rando.
 (Reimpressão) 
 Maringá-Pr.: UniCesumar, 2018. 
 176 p.
“Graduação - EaD”.
 
 1. Projeto. 2. Orientado. 3. Objetos. 4. EaD. I. Título.
ISBN 978-85-459-0113-6
CDD - 22 ed. 005.1
CIP - NBR 12899 - AACR/2
Ficha catalográfica elaborada pelo bibliotecário 
João Vivaldo de Souza - CRB-8 - 6828
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pró-Reitor de Administração
Wilson de Matos Silva Filho
Pró-Reitor de EAD
Willian Victor Kendrick de Matos Silva
Presidente da Mantenedora
Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância
Direção Operacional de Ensino
Kátia Coelho
Direção de Planejamento de Ensino
Fabrício Lazilha
Direção de Operações
Chrystiano Mincoff
Direção de Mercado
Hilton Pereira
Direção de Polos Próprios
James Prestes
Direção de Desenvolvimento
Dayane Almeida 
Direção de Relacionamento
Alessandra Baron
Gerência de Produção de Conteúdo
Juliano de Souza
Supervisão do Núcleo de Produção de 
Materiais
Nádila de Almeida Toledo
Coordenador de Conteúdo
Fabiana de Lima
Design Educacional
Paulo Victor Souza e Silva
Iconografia
Amanda Peçanha dos Santos
Ana Carolina Martins Prado
Projeto Gráfico
Jaime de Marchi Junior
José Jhonny Coelho
Arte Capa
André Morais de Freitas
Editoração
Fernando Henrique Mendes
Revisão Textual
Viviane Favaro Notari
Ilustração
Bruno Pardinho
Viver e trabalhar em uma sociedade global é um 
grande desafio para todos os cidadãos. A busca 
por tecnologia, informação, conhecimento de 
qualidade, novas habilidades para liderança e so-
lução de problemas com eficiência tornou-se uma 
questão de sobrevivência no mundo do trabalho.
Cada um de nós tem uma grande responsabilida-
de: as escolhas que fizermos por nós e pelos nos-
sos farão grande diferença no futuro.
Com essa visão, o Centro Universitário Cesumar 
assume o compromisso de democratizar o conhe-
cimento por meio de alta tecnologia e contribuir 
para o futuro dos brasileiros.
No cumprimento de sua missão – “promover a 
educação de qualidade nas diferentes áreas do 
conhecimento, formando profissionais cidadãos 
que contribuam para o desenvolvimento de uma 
sociedade justa e solidária” –, o Centro Universi-
tário Cesumar busca a integração do ensino-pes-
quisa-extensão com as demandas institucionais 
e sociais; a realização de uma prática acadêmica 
que contribua para o desenvolvimento da consci-
ência social e política e, por fim, a democratização 
do conhecimento acadêmico com a articulação e 
a integração com a sociedade.
Diante disso, o Centro Universitário Cesumar al-
meja ser reconhecido como uma instituição uni-
versitária de referência regional e nacional pela 
qualidade e compromisso do corpo docente; 
aquisição de competências institucionais para 
o desenvolvimento de linhas de pesquisa; con-
solidação da extensão universitária; qualidade 
da oferta dos ensinos presencial e a distância; 
bem-estar e satisfação da comunidade interna; 
qualidade da gestão acadêmica e administrati-
va; compromisso social de inclusão; processos de 
cooperação e parceria com o mundo do trabalho, 
como também pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educação continuada.
Seja bem-vindo(a), caro(a) acadêmico(a)! Você está 
iniciando um processo de transformação, pois quan-
do investimos em nossa formação, seja ela pessoal 
ou profissional, nos transformamos e, consequente-
mente, transformamos também a sociedade na qual 
estamos inseridos. De que forma o fazemos? Criando 
oportunidades e/ou estabelecendo mudanças capa-
zes de alcançar um nível de desenvolvimento compa-
tível com os desafios que surgem no mundo contem-
porâneo. 
O Centro Universitário Cesumar mediante o Núcleo de 
Educação a Distância, o(a) acompanhará durante todo 
este processo, pois conforme Freire (1996): “Os homens 
se educam juntos, na transformação do mundo”.
Os materiais produzidos oferecem linguagem dialó-
gica e encontram-se integrados à proposta pedagó-
gica, contribuindo no processo educacional, comple-
mentando sua formação profissional, desenvolvendo 
competências e habilidades, e aplicando conceitos 
teóricos em situação de realidade, de maneira a inse-
ri-lo no mercado de trabalho. Ou seja, estes materiais 
têm como principal objetivo “provocar uma aproxi-
mação entre você e o conteúdo”, desta forma possi-
bilita o desenvolvimento da autonomia em busca dos 
conhecimentos necessários para a sua formação pes-
soal e profissional.
Portanto, nossa distância nesse processo de cres-
cimento e construção do conhecimento deve ser 
apenas geográfica. Utilize os diversos recursos peda-
gógicos que o Centro Universitário Cesumar lhe possi-
bilita. Ou seja, acesse regularmente o AVA – Ambiente 
Virtual de Aprendizagem, interaja nos fóruns e en-
quetes, assista às aulas ao vivo e participe das discus-
sões. Além disso, lembre-se que existe uma equipe de 
professores e tutores que se encontra disponível para 
sanar suas dúvidas e auxiliá-lo(a) em seu processo de 
aprendizagem, possibilitando-lhe trilhar com tranqui-
lidade e segurança sua trajetória acadêmica.
Diretoria Operacional 
de Ensino
Diretoria de 
Planejamento de Ensino
Professor Me. Déverson Rogério Rando
Mestre em Ciência da Computação pela Universidade Estadual de Maringá 
(UEM). Especialista em Engenharia de Software pela Universidade Norte do 
Paraná. Graduado em Geografia pela Universidade Estadual de Londrina 
e Análise e Desenvolvimento de Sistemas pelo CESUMAR. 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 disciplinas 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, Trabalho de Conclusão de Curso.
A
U
TO
R
SEJA BEM-VINDO(A)!
Caro(a) Aluno(a)! Seja bem-vindo(a) à disciplina de Análise e Projeto Orientado a Ob-
jetos (OO). Sou o professor Déverson Rogério Rando. Esta disciplina abordará vários 
aspectos relacionados à análise e projeto de sistemas orientados a objetos, utilizando 
como notação a UML.
Apresento a você o livro que conduzirá seus estudos, auxiliando no aprendizado de aná-
lise e projeto orientado a objetos com a UML. O livro encontra-se estruturado em cinco 
unidades e cada uma conta com uma seção Reflita, Saiba Mais, Vídeos e Atividades de 
Autoestudo. A seção Reflita apresenta frases que te remetem ao conteúdo estudado 
na disciplina e o fazem pensar um pouco mais sobre ele. A seção Saiba Mais conta com 
links para artigos que complementam o aprendizado sobre análise de projetos. A seção 
Vídeo apresenta links para vídeos. E, por último, a seção Atividades de Autoestudo ex-
pressa um conjunto de questões sobre o conteúdo abordado.
A unidade I apresenta os conceitos iniciais sobre a análise e projetos orientados a ob-
jetos. 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. Conhece-
remos os conceitos básicos que envolvem a orientação a objetos, para dar subsídio nos 
capítulos subsequentes. E, por fim, veremos os principais diagramas da UML utilizados 
na documentação de software.
Na unidade II, estudaremos as fases que compreendem a análise e o projeto de um sof-
tware. Entraremos em contato com dois dos modelos de processos, cascata e evolucio-
nário,veremos as vantagens e desvantagens da utilização de cada um desses métodos. 
Abordaremos, também, os requisitos de software e vamos conhecer os procedimentos 
mínimos para a obtenção de um software de qualidade. Encerraremos a unidade falan-
do 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 III está toda dedicada à confecção do Diagrama de Classes responsável por 
demonstrar a estrutura estática do sistema. Conheceremos a notação para o diagrama 
de classes em detalhes. Abordaremos os conceitos e a assinatura da declaração de atri-
butos e métodos. Veremos como ocorrem as ligações entre as classes e como definir a 
multiplicidade entre elas. Discutiremos, ainda, sobre as várias formas de se associar as 
classes, sejam elas unária, binária, ternária, associativa, agregação ou generalização. 
Na unidade IV, avançaremos conhecendo mais três diagramas, essenciais na análise e 
projeto OO, que utilizaremos para refinar o diagrama de classes que representa a estru-
tura do sistema. O primeiro diagrama que veremos nessa unidade é o de sequência, que 
tem como objetivo estudar as interações entre os objetos, considerando a dimensão 
tempo. O segundo diagrama que veremos é o de estados, que tem como objetivo es-
pecificar 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 que o 
diagrama de sequência, porém não considera o tempo e sim a ordem da comunicação.
APRESENTAÇÃO
ANÁLISE E PROJETO ORIENTADO A OBJETOS
Por fim, na unidade V, resolveremos, juntos, um estudo de caso, no qual teremos a 
oportunidade de apresentar de forma prática a construção dos diagramas citados 
na elaboração da análise e projeto de um software. Dessa forma, reforçaremos to-
dos os conceitos trabalhados nas unidades anteriores.
Ao longo deste livro, você encontrará indicações de Leitura Complementar, as quais 
enriquecerão o seu conhecimento sobre projetos. É importante que você desenvol-
va as Atividades de Autoestudo para fixar o conteúdo abordado e identificar even-
tuais dificuldades. Vamos lá!?
APRESENTAÇÃO
SUMÁRIO
09
UNIDADE I
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
15 Introdução 
16 Introdução À Orientação A Objetos 
19 Evolução Dos Métodos OO 
21 Conceitos Básicos De OO 
27 Principais Diagramas da UML 
38 Considerações Finais 
UNIDADE II
CASOS DE USO
47 Introdução 
48 Fases da Análise e do Projeto 
53 Modelos de Processo 
58 Requisitos de Software 
63 Diagrama de Casos de Uso 
71 Considerações Finais 
SUMÁRIO
UNIDADE III
DIAGRAMA DE CLASSES
77 Introdução 
78 Diagrama de Classes 
79 Notação Para Classes 
81 Atributos 
83 Métodos 
85 Multiplicidade 
88 Associação Unária 
89 Associação Binária 
90 Classe Associativa 
91 Agregação 
94 Generalização 
98 Herança Múltipla 
99 Considerações Finais 
SUMÁRIO
11
UNIDADE IV
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
109 Introdução
110 Avançando nos Diagramas 
112 Diagrama de Sequência 
120 Diagrama de Estados 
125 Diagrama de Comunicação 
129 Considerações Finais 
UNIDADE V
ESTUDO DE CASO
137 Introdução
138 Ferramentas Case 
139 Estudo de Caso 
142 Diagrama de Caso de Uso 
153 Diagrama de Classes 
156 Diagrama de Sequência 
162 Diagrama de Estado 
164 Diagrama de Comunicação 
168 Considerações Finais 
173 CONCLUSÃO
175 REFERÊNCIAS
U
N
ID
A
D
E I
Professor Me. Déverson Rogério Rando
INTRODUÇÃO AO ESTUDO 
DE ORIENTAÇÃO A OBJETOS
Objetivos de Aprendizagem
 ■ Entender a importância da análise e projeto.
 ■ Conhecer a evolução dos métodos OO.
 ■ Compreender as características dos métodos OO.
 ■ Entender os diferentes termos utilizados em OO.
 ■ Conhecer os principais diagramas da UML.
Plano de Estudo
A seguir, apresentam-se os tópicos 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
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 desen-
volvimento de software. É nessa fase que determinamos e especificamos 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 colabora-
tivo entre analistas de sistemas e usuários.
Em seguida, veremos como os métodos surgiram e como aconteceu a evo-
lução deles. Abordaremos a partir do primeiro método Orientado a Objetos, 
proposto por Shlaer e Mellor em 1988, o OOSA, até chegarmos a Unified Modeling 
Language-UML, que será a linguagem que utilizaremos para as nossas análises 
e 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 dos méto-
dos que serão apresentados. Ou seja, a evolução de todos os demais 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 ter-
mos utilizados na análise e no projeto OO. Dentre os conceitos que veremos, 
estão o de objeto, abstração, classe, instância, atributo, operação, mensagem, 
evento, estado, parâmetro, entre outros. 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 diagrama de classes 
que modela a estrutura estática do sistema, o diagrama de sequência, o de cola-
boração e o de estado.
Então, o que estamos esperando? Vamos ao trabalho?
Boa leitura a todos.
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
15
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E16
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 essa 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 respectivo ambiente.
De acordo com Sommerville (2011), podemos chamar “análise de sistemas” 
de “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 de sistemas, por ser uma etapa inicial e cujas falhas terão efeitos 
em cadeia nas etapas subsequentes, assim como no produto final. A determi-
nação incorreta dos requisitos levará à obtenção e disponibilização de sistemas 
computacionais inadequados.
Resumindo: a análise é a solução conceitual dada ao problema. Marca o iní-
cio da definição informática, mas sem levarem conta detalhes da implementação, 
tais como a linguagem e o sistema gerenciador de banco de dados a serem uti-
lizados. 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 con-
siste na solução computacional aplicada ao problema. Dizer onde acaba a análise 
e inicia o projeto é muito complicado, uma vez que o projeto é o resultado de 
refinamentos sucessivos do modelo conceitual de análise.
A Orientação a Objetos fez com que fosse alterado o enfoque necessário 
para desenvolver um sistema, enquanto na programação estruturada tínhamos 
Introdução à Orientação a Objetos 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
17
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 tratar esses atributos, 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 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 é compreen-
dido 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 projeto estruturado são:
 ■ Diagrama entidade e relacionamento (DER).
 ■ Dicionários de dados.
 ■ Diagrama de Fluxo de Dados (DFD).
O DER modela a estrutura de dados parados, ou seja, é o modelo conceitual do 
sistema. Mostra-nos as entidades e seus relacionamentos, nesse 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 de dados, em outras palavras, mostra os dados em movi-
mento, 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 desenvol-
vimento de software que organiza o software como uma coleção de objetos que 
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E18
contém tanto a estrutura dos dados como 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 de objetos.
A proposta da orientação a objetos é deslocar o esforço de desenvolvimento 
para a fase de análise, dando ênfase nas estruturas de dados antes do que as fun-
ções, os benefícios são: a reutilização do código (componentes), a confiabilidade 
(objetos encapsulados), o aumento de produtividade (SOMMERVILE, 2011).
Com o planejamento adequado, desenvolvedores capacitados e a 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 modelar os requisitos 
dos usuários que o sistema deve atender.
Nos anos 50, quando inicia a informática, desenvolver software era um pro-
cesso informal, sem técnicas de projeto, conceito de reusabilidade, controle 
de qualidade ou documentação. Neste artigo, Marcos Rodrigues Pinto e Sér-
gio Cosme Noronha C. Filho fazem um Estudo comparativo sobre a aborda-
gem tradicional de desenvolvimento de sistemas e a orientação a objetos.
Confira o texto completo no link disponível em: <http://www.dcc.ufrj.br/~s-
chneide/es/2002/1/g11/index.htm>. Acesso em: 28 jul. 2015.
Fonte: o autor.
Evolução dos Métodos OO
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
19
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 também, 
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 de 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 metodologia 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.
Shlaer e Mellor (1990): abrangem as fases de análise, projeto e implementa-
ção. Propõem mecanismos para facilitar a representação de modelos dinâmicos 
dos objetos, dando ênfase na modelagem da informação, por meio dos modelos 
de objetos, de estados, dos 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 orien-
tado 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 objetos, modelagem dinâmica e modelagem funcional, des-
tacando o tratamento de processos e dividindo a fase de projeto em projeto de 
objetos e projeto de sistema. 
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E20
Martin e Odell (1995): abrange as fases de análise e projeto. Propõe o uso 
da Engenharia da Informação Baseada em Objetos por meio de um repositório 
de objetos, para obtenção de um alto nível de reaproveitamento dos sistemas. 
Fusion (1996): abrange as fases de análise, projeto e implementação. 
Sintetizando os aspectos 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).
UML-Unified Method Language (2000): abrange as fases de levantamento 
de requisitos, análise, projeto e implementação. Fusão dos métodos de James 
Rumbaugh/OMT, Grady Boock e Ivar Jacobson. A fusão inicia com o trabalho 
de James Rumbaugh e Grady Booch, os dois metodistas que ganharam maior 
popularização; os quais se juntaram para criar um método comum por meio de 
pontos fortes ao público em 1995. Em seguida, em meados de 1996, Ivar Jacobson 
integrou-se ao grupo e lançarama UML versão 0.9. A partir daí, criaram forças 
com cooperação da OMG (Object Management Group), em julho de 1997, con-
siderado um padrão mundial. 
A UML sugere fortemente a adoção de casos de uso (use cases) como dire-
cionador de projetos de software, a utilização de diagramas de interação para 
identificação de objetos e uma série de outros conceitos. 
Figura 1: Objetos Concretos Figura 2: Objetos Abstratos
Figura 3: Abstração de Bolsa Figura 4: Abstração de avião
Conceitos Básicos de OO
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
21
CONCEITOS BÁSICOS DE OO
Conheceremos, a seguir, os principais termos e conceitos utilizados na análise 
e projeto OO. Vamos lá!
 ■ Objeto: qualquer coisa concreta ou abstrata que existe no mundo real, 
em que se pode individualizá-la por possuir comportamentos e caracte-
rísticas próprias.
 ■ Abstração: abstraímos quando definimos um objeto conceitual partindo 
de OBJETOS do mundo real com os mesmos comportamentos e caracte-
rísticas, os quais são classificados como de um mesmo tipo.
Figura 5: Abstração de Esporte
Figura 6: Classe Funcionário
Fonte: o autor.
Figura 7: Classe e Objetos
Fonte: o autor.
©istock
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E22
 ■ Classe: representa a ABSTRAÇÃO de um conjunto de OBJETOS do 
mundo real que possui comportamentos e características comuns.
 ■ Instância: é cada umas das ocorrências de um OBJETO formado a par-
tir da sua CLASSE.
Figura 8: Classe, objeto e valor
Fonte: o autor.
Figura 9: Operação
Fonte: o autor.
Figura 10: Mensagem
Fonte: o autor.
Conceitos Básicos de OO
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
23
 ■ Atributo: é uma característica particular que os OBJETOS de uma CLASSE 
possuem, assumindo valores diferentes para cada OBJETO.
 ■ Operação: é um protótipo de um método pensado por um analista. As 
operações são tudo o que os OBJETOS de uma CLASSE fazem e nada 
além do que esses objetos podem fazer.
 ■ 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.
Estado Criado Estado Eliminado
Estado Parado Estado Decolando
Figura 13: Estado
Fonte: o autor.
Figura 12: Parâmetro
Fonte: o autor.
Figura 11: Evento
Fonte: o autor.
Figura 14: Transição de estado
Fonte: o autor.
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E24
 ■ Evento: é um tipo especial de OPERAÇÃO que faz com que os OBJETOS 
mudem de ESTADO. 
 ■ Parâmetro: é um ou mais variáveis ou informações que são carregados 
para dentro de uma MENSAGEM.
 ■ Estado: é a condição dos OBJETOS de uma CLASSE em um determi-
nado instante.
 ■ Transição de Estado: é quando ocorre a mudança de ESTADO de um 
OBJETO de uma CLASSE como resposta à chegada de um EVENTO.
Figura 16: Encapsulamento
Fonte: o autor.
Figura 15: Associação de classes
Fonte: o autor.
Figura 17: Polimorfismo 
Fonte: o autor.
Conceitos Básicos de OO
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
25
 ■ Associação: é a forma como os OBJETOS de uma mesma CLASSE ou de 
CLASSES diferentes se conectam.
 ■ Encapsulamento: Encapsulamento: é a maneira pela qual as operações 
formam um limite de proteção em torno do objeto, ou seja, os valores 
de um atributo só podem ser manipulados por meio de suas operações.
 ■ Polimorfismo: é a capacidade que OBJETOS de CLASSES diferentes pos-
suem de se comportarem de forma diferente em uma mesma operação. No 
polimorfismo, os métodos de subclasses associadas a classes pela herança 
podem ser otimizados para necessidades específicas, gerando um tipo de 
especialização destes métodos.
Figura 18: Troca de mensagens entre os objetos
Fonte: o autor.
Quadro 1: Declaração de um método
Fonte: o autor.
Figura 19: Herança
Fonte: o autor.
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E26
 ■ Método: é o algoritmo (conjunto de passos) que um OBJETO executa 
quando 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;
 }
 ■ Colaboração: é a troca de MENSAGENS que acontece entre OBJETOS 
e atores. 
 ■ Herança: é a propriedade que possibilita que a CLASSE herde caracte-
rísticas e comportamento de uma outra CLASSE.
Figura 20: Organização do Diagrama UML
Fonte: o autor.
Principais Diagramas da Uml
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
27
PRINCIPAIS DIAGRAMAS DA UML
Agora que já conhecemos os principais termos utilizados na análise e projeto 
OO, quero convidar você a conhecer os diagramas utilizados para documentação 
de software. Apresentarei, de forma sucinta, cada um dos diagramas e veremos 
com detalhes nas unidades seguintes.
A UML 2.0 apresenta treze diagramas, classificados em estruturais e de com-
portamento. A figura 20 mostra essa organização em um diagrama de classes.
É comum verificarmos que a documentação do software, na maioria das vezes, 
não tem a devida atenção da equipe de desenvolvimento, ou por preguiça, ou 
por falta de tempo, ou mesmo por achar que é uma perda de tempo elaborar 
inúmeros diagramas. Porém bons softwares têm documentação que nos permite 
contar e entender a história desse software.
Figura 21: Diagrama de Caso de Uso 
Fonte: o autor.
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E28
DIAGRAMAS DE COMPORTAMENTO
Os diagramas de comportamento são utilizados para descrever o sistema mode-
lado já 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
Iniciaremos, então, pelo Diagrama de Casos de Uso (comportamento), utilizado 
na análise de requisitos. Esse 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 stick man (homem palito) e suas res-
pectivas ações descritas nas elipses.
Principais Diagramas da Uml
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
29
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, suautilidade é 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, em que, a partir dessa ação, é desencadeado um conjunto de men-
sagens entre os objetos que permite a verificação da existência da pessoa aluno, 
em seguida, é criado o item de empréstimo, que verifica a existência do exem-
plar solicitado, realizando o empréstimo.
Como é possível observar, a partir das informações fornecidas pelo dia-
grama de sequência, pode-se identificar os métodos associados às classes, além 
da identificação das relações entre elas.
 
 
 
 
 
 
Figura 22: Diagrama de Sequência
Fonte: o autor.
1: solicita empréstimo()
2: veri�ca se existe()
2.1: veri�cação ok()
3: cria itens()
4: veri�ca se existe()
4.1 : veri�cação ok()
5 : cria item()
6: itens concluídos()
7: cria empréstimo()
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E30
Uma outra forma de representar o cenário é pelo diagrama de comunicação (com-
portamento), este contém as mesmas informações que o diagrama de sequência, 
porém não considera a dimensão temporal.
Principais Diagramas da Uml
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
31
DIAGRAMA DE ESTADOS
Em seguida, veremos o diagrama de estados (comportamento), que tem como 
objetivo 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 
comportamentos 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 detalhamento de uma atividade que deve ser execu-
tada em determinado momento.
Fonte: adaptado de Sommervile (2011).
Figura 23: Diagrama de Estado
Fonte: o autor.
Figura 24: Diagrama de Comunicação (comportamento)
Fonte: o autor.
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E32
Não são todas as classes do sistema que apresentam mais de um estado. O diagrama 
de estado abaixo mostra todos os estados do exemplar no momento empréstimo, 
o início do estado é marcado pelo círculo e o fim é mercado pelo duplo círculo.
Figura 25: Diagrama de Atividades
Fonte: o autor.
Principais Diagramas da Uml
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
33
DIAGRAMA DE COMUNICAÇÃO
O diagrama de comunicação permite a identificação das classes mais próxi-
mas e a ordem de envio de mensagens é identificada por números sequenciais. 
A seguir, é apresentado o diagrama de comunicação que é equivalente ao dia-
grama de sequência mostrado anteriormente.
DIAGRAMA DE ATIVIDADES
O diagrama de atividade é, em sua essência, um gráfico de fluxo, demonstrando 
como ocorre o fluxo de controle entre as atividades. Esse diagrama é um dos 
mais detalhistas, dando ênfase maior ao nível de algoritmo.
Os diagramas de atividades podem ser utilizados com vários propósitos. 
Dentre seus propósitos, podemos citar a captura do funcionamento interno do 
objeto, bem como mostrar como pode ser executo um conjunto de ações rela-
cionadas e como elas podem afetar os objetos ao seu redor.
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E34
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 
representam 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.
CLASSES
Após a elaboração do diagrama de caso de uso, podemos modelar a primeira 
versão do diagrama de Classes. O diagrama de classes 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 com-
portamento de seus objetos, e os possíveis estados do objeto são modelados por 
meio de atributos. 
Para entendermos melhor, vamos fazer a analogia com a construção de 
um veículo. Todos os veículos serão rigorosamente iguais, pois estarão basea-
dos em uma planta (projeto) que esclarece o número de portas, potência do 
motor, número de marchas do câmbio, dentre outros atributos. Portanto, o 
projeto do veículo é a classe e os veículos são os objetos que foram basea-
dos na classe.
O diagrama de classes, abaixo, modela a estrutura estática do sistema de 
biblioteca 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 03, 
mas, para adiantar, é possível observar nesse 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.
- nome : String = João da Silva
+ cria() : void
+ recupera() : void
+ atualiza() : void
+ cria() : void
+ curso : int = 1 - disciplina : int = 2
+ recupera() : void
+ atualiza() : void
+ cria() : void
+ recupera() : void
+ cria() : void
+ recupera() : void
+ elimina() : void+ atualiza() : void
+ bloqueia() : void
+ cria() : void
+ recupera() : void
+ atualiza() : void
+ libera() : void
= Rua Jabuti Peralta, 2
Figura 26: Diagrama de Classes
Fonte: o autor.
- nome : String = João da Silva
- endereço : String = Rua Jabuti Peralta, 2
- cria() : void
- recupera() : void
- atualiza() : void
- libera() : void
- curso : int = 1 - disciplina : inte = 2
Figura 27: Diagrama de Objetos
Fonte: o autor.
Principais Diagramas da Uml
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
35
DIAGRAMA DE OBJETOS
Os diagramas de objetos correspondem a um segundo nível de abstração do dia-
grama de classes. Não têm a mesma importância do diagrama de classes, porém pode 
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 do diagrama de classes para mostrar as instâncias da classe.
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ódu-
los executáveis do software.
Apesar de ser um diagrama de alto nível, a organização do sistema é 
dependente da linguagem de programação utilizada, portanto, a solução de 
desenvolvimento adotada refletirá diretamente nesse diagrama.
Figura 28: Diagrama de Componentes
Fonte: o autor.
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E36
Um componente corresponde a uma parte do código distribuível que pode ser 
substituída por outro componente e que contém elementos que mostram um 
conjunto de interfaces fornecidase requeridas. Podemos apresentar como exem-
plos de componentes os executáveis, tabelas, bibliotecas, documento e arquivo.
DIAGRAMA DE IMPLANTAÇÃO
Diagramas de implantação são utilizados para modelar a arquitetura física de 
distribuição onde 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 computacio-
nal com memória e processamento, ou seja, um disco rígido, um computador, 
uma impressora etc.
O diagrama de implantação é uma ferramenta importante quando qui-
ser saber quais computadores e outros hardwares estão conectados, bem como 
saber como estão distribuídas as classes e quando a atualização de determinado 
arquivo resulta na recompilação de outros.
Principais Diagramas da Uml
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
37
DIAGRAMA DE PACOTES
O pacote representa um agrupamento de classes, formando uma unidade. 
Normalmente, os pacotes apresentam relações, em que um pacote depende de 
outro para o funcionamento.
Como a estrutura de uma aplicação é dada pelas classes e associações, pode-
mos 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 
subsistemas, que, nesse caso, cada subsistema é representado por um pacote. 
Dessa forma, um pacote pode representar uma biblioteca, um subsistema, um 
sistema, entre outros. Um pacote, também, pode conter outros pacotes.
Os pacotes, invariavelmente, apresentam dependência entre si. O relaciona-
mento de dependência indica que o pacote dependente precisa de alguma forma 
do pacote do qual depende.
Figura 29: Diagrama de Implantação
Fonte: o autor.
Figura 30: Diagrama de Pacotes
Fonte: o autor.
INTRODUÇÃO AO ESTUDO DE ORIENTAÇÃO A OBJETOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E38
CONSIDERAÇÕES FINAIS
Nesta unidade, aprendemos que a análise é a solução conceitual dada ao problema. 
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 gerencia-
dor 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 o software 
como uma coleção de objetos, que contém tanto a estrutura dos dados como o 
comportamento 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 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 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 James Rumbaugh 
e Grady Booch, em seguida, em meados de 1996, Ivar Jacobson integrou-se ao 
grupo e lançaram a UML versão 0.9. A partir daí, criaram forças com a coope-
ração da OMG (Object Management Group) em julho de 1997, considerado um 
padrão mundial.
Considerações Finais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
39
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, dentre 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ê vai conhecer as eta-
pas da análise e a notação para o diagrama de caso de uso.
 
 
 
 
 
 
1. Na análise e 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 projeto estruturados, na orientação a objetos, o processo a ser infor-
matizado é 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 Jacob-
son 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 pro-
postos pelos autores citados?
I. A UML – Unified Modeling Language abrange as fases de levantamento 
de requisitos, 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 ob-
jetos?
II. Objetos: qualquer coisa concreta ou abstrata com existência perceptível 
no mundo real.
III. Classes: ABSTRAÇÃO de um conjunto de OBJETOS.
IV. Atributo: característica particular possuída por todos os OBJETOS de uma 
CLASSE.
5. Chave Primária: identifica unicamente um objeto.
Está(ão) correta(s) somente:
A. ( ) I.
B. ( ) I e II.
C. ( ) I, II e III.
D. ( ) III e IV.
E. ( ) I, II, III e IV.
4. É comum verificarmos que a documentação do software, na maioria das vezes, 
não tem a devida atenção da equipe de desenvolvimento, ou por preguiça, ou 
por falta de tempo, ou mesmo por achar que é uma perda de tempo elaborar 
inúmeros diagramas. Bons softwares, porém, têm documentação que nos per-
mite contar e entender a história desse software. Contamos essa história por 
meio de diagramas, sabendo disso, quais diagramas são utilizados na UML e 
como estão organizados?
41 
5. O Diagrama _____________ contém as mesmas informações que o diagrama de 
sequência, porém não considera a dimensão temporal. Observe os Diagramas:
I. Comunicação
II. Caso de Uso
III. Classes
IV. Estado
A(s) afirmativa(s) que pode(m) completar a lacuna é(são) somente:
A. ( ) I.
B. ( ) I e II.
C. ( ) I, II e III.
D. ( ) III e IV.
E. ( ) I, II, III e IV.
QUALIFICAÇÃO DE SOFTWARES
Como pode ser qualificado um software? É muito simplório definir isso pelo tempo de 
desenvolvimento ou pela excelência na programação. Existe caso de desenvolvimento 
de softwares em que o programador ouve todas as informações e apresenta uma solu-
ção instantânea, quase que “mágica”. Algo que resolve perfeitamente o que foi apresen-
tado. Olhando assim, a sensação que temos parece que o atendimento foi excepcional, 
contudo, na maioria dos casos, programas feitos nesse formato não suprem a real ne-
cessidade do cliente.
Não podemos julgar o cliente por não saber apresentar de forma assertiva as suasne-
cessidades, pois o conhecimento da construção técnica é inexistente ou superficial, 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 vai 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á tenha viven-
ciado isso.
Mas esse problema não é exclusivo do desenvolvimento de softwares, é algo corriquei-
ro no mercado. Para provar isso, basta precisarmos de um serviço em que não tenha 
nenhum conhecimento do processo, como consertar um carro. A solução só vem quan-
do um profissional qualificado está mais preocupado em te satisfazer como cliente do 
que resolver exclusivamente o seu problema apresentado. Os profissionais que mantêm 
esse método de atendimento vão sendo substituídos aos poucos. 
Na rotina diária de programação, normalmente, o início do projeto vem de um conversa 
informal e só lá na primeira apresentação, depois de um grande tempo de dedicação, é 
que o cliente consegue esclarecer ainda de forma abstrata com frases como “não é bem 
isso que eu esperava”. Outro caso comum que acontece pela falta de alinhamento é as 
solicitações do cliente irem aumentando durante o processo todo, e, como nada é esta-
belecido de forma clara no início do trabalho, você pode até prolongar o projeto, mas, 
possivelmente, não atenderá todas as necessidades do seu cliente.
Finalizo lembrando que cliente não tem obrigação de entender como funciona toda 
a programação e que a preocupação deve ser do programador de atender o cliente, e 
não o contrário. Um bom profissional precisa “interpretar” a necessidade de um cliente e 
oferecer não o que ele está pedindo, mas sim o que vai suprir sua necessidade.
Fonte: Autor.
Material Complementar
MATERIAL COMPLEMENTAR
Desenvolvendo software com UML 2.0 defi nitivo
Ernani Medeiros
Editora: Makron Books
Sinopse: Este livro apresenta, de maneira prática e já testada, o que é, 
para que serve e como usar os diagramas da UML 2.0. Além de sugerir o 
melhor momento para se 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, 
fi nalidade do conceito e como usá-lo.
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “A história de UML e seus 
diagramas”. Esse artigo descreve a história de UML desde a década de 1990 até o momento 
atual. Apresenta-se a organização dos treze diagramas de UML, classifi cando-os em diagramas 
estruturais e comportamentais. Os quatro documentos pertencentes à especifi cação também são 
mencionados e explicados.
O artigo encontra-se disponível em: <https://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/
artigo.tcc.pdf>. Acesso em: 28 jul. 2015.
U
N
ID
A
D
E II
Professor Me. Déverson Rogério Rando
CASOS DE USO
Objetivos de Aprendizagem
 ■ Conhecer as fases da 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 diagrama de Caso de Uso.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Fases da análise e do projeto 
 ■ Modelos de processo
 ■ Requisitos de software 
 ■ Diagrama de Casos 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 acredito ser a fase mais 
difícil e crítica da produção de um software, difícil porque é o momento que 
ocorrem as tentativas de delimitar o domínio do problema e entendê-lo, crítica 
porque uma análise mal feita comprometerá todas as outras fases de produção 
do software, além do que o produto a ser entregue não será o que o cliente ini-
cialmente requeria.
Entenderemos e conheceremos dois modelos de processos de software, 
entre os “N” processos existentes. Citarei, aqui, o modelo em cascata e o evo-
lucioná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 estabele-
cidas por clientes e usuários do sistema que definem as diversas propriedades 
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 que o sistema deverá possuir. 
Ainda, veremos a importância do levantamento de requisitos para o desen-
volvimento de software. Aprenderemos que a definição de requisitos pode se 
utilizar de uma narrativa ou de 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 software. 
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. 
Então, o que estamos esperando? Vamos ao trabalho.
Boa leitura a todos.
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
47
CASOS DE USO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E48
FASES DA ANÁLISE E DO PROJETO
Como vimos na unidade 1, a análise de sistemas é a atividade inicial do pro-
cesso de desenvolvimento de software em que se determina e especifica o que um 
sistema deve fazer, bem como as circunstâncias sob as quais deve operar, envol-
vendo, geralmente, um 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.
 ■ Executar análise econômica e técnica.
 ■ Atribuir funções ao hardware, software, pessoas, banco de dados e aos 
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 traba-
lho subsequente.
Independente do método ou processo utilizado para a análise, projeto e imple-
mentação, algumas etapas são comuns, são elas (SOMMERVILE, 2011):
 ■ Identificação da Necessidade.
 ■ Estudo de Viabilidade.
 ■ Análise.
 ■ Projeto (Ferramentas).
 ■ Implementação (Codificação).
 ■ Implantação.
 ■ Manutenção (Adaptativa, Corretiva e Evolutiva).
A seguir, detalharei cada uma dessas etapas de suma importância para a produ-
ção de um software de qualidade.
Fases da Análise e do Projeto
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
49
IDENTIFICAÇÃO DA NECESSIDADE
Vamos comentar cada uma dessas etapas começando pela identificação da neces-
sidade, que é o ponto de partida na evolução de um sistema. Nessa etapa, são 
definidas as metas globais do sistema, respondendo algumas perguntas-chave:
 ■ Quais informações serão produzidas?
 ■ Quais informações devem ser fornecidas?
 ■ Que funções e desempenho são exigidos?
Ainda nessa 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 tempo necessário para conclusão?
Caso o novo sistema seja um produtoa ser desenvolvido para venda a muitos 
clientes, o analista ainda deve avaliar o seguinte:
 ■ Qual é o mercado em potencial para o produto?
 ■ Como esse 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 deter-
minar 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, sistema operacional. E, também, se existe pessoal competente 
à disposição para desenvolver o sistema em questão (SOMMERVILE, 2011).
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 esta-
duais/federais e nas cláusulas contratuais.
CASOS DE USO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E50
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 deter-
minar 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 uma análise completa de um sistema, 
portanto, o analista deve considerar os seguintes objetivos (SOMMERVILE, 2011):
 ■ Entender os objetivos do sistema (o que o administrador/usuário espera 
do sistema).
 ■ Entender as exigências do sistema (o que processar e que saídas produzir).
 ■ Entender que os objetivos e 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.
Fases da Análise e do Projeto
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
51
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 estrutura 
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 se elaborar modelos com 
diferentes níveis de abstração, é possível detectar problemas nos níveis anterio-
res. 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 no qual se cria uma versão 
executável do software, utilizando as ferramentas para desenvolvimento defini-
das no projeto.
A implementação pode iniciar após o término do projeto, ou pode acontecer 
de forma paralela ao projeto, 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 imple-
mentado usando os recursos existentes: computadores, periféricos, sistema 
operacional, dentre outros, e, também, se existe pessoal competente à disposi-
ção para desenvolver o sistema em questão.
Todo o projeto é construído com base no estudo de viabilidade técnica, 
utilizando ferramentas suportadas pelo hardware e entendida pelos usuários, 
portanto, os riscos da implantação não funcionar são minimizados no projeto.
CASOS DE USO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E52
O fator de maior preocupação 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 determinada 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 por 
motivos que não foram possíveis observar no momento da análise, projeto ou 
mesmo na implementação.
As manutenções podem ser adaptativas, que têm o objetivo, como o próprio 
nome diz, de adaptar algumas tarefas ou funções para o ambiente de implanta-
ção. As manutenções também podem ser evolutivas, que têm como objetivo a 
inserção de novos módulos no sistema.
 
 
 
 
 
 
Figura 53: Modelo Cascata
Fonte: adaptada de Sommervile (2011).
Modelos De Processo
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
53
MODELOS DE PROCESSO
A análise e o projeto de sistemas de software deve fornecer para os stakeholders 
(equipe envolvida), composto pelo cliente, analista, programador, entre outros, 
uma única compreensão do projeto. 
De acordo com Medeiros (2004), a UML não se trata de um método, mas 
sim de uma linguagem. Um método é composto por processo e um modelo de 
linguagem. Os processos são os passos que devem ser seguidos para se construir 
o projeto. O modelo de linguagem é a notação que o método usa para descrever 
o projeto. Um modelo de processo de software define a sequência em que as ati-
vidades do processo serão realizadas.
MODELO CASCATA
Vamos tomar como exemplo o modelo de processo em cascata, ou queda d’água, 
como colocado por alguns autores.
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.
CASOS DE USO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E54
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 requisi-
tos em sistemas de hardware ou de software são agrupados, estabelecendo uma 
arquitetura do sistema geral.
A terceira fase é a Implementação e teste de unidades, durante esse 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 
atenda a sua especificação.A quarta fase é a Integração e teste de sistemas; nesse estágio, as unidades 
de programa ou programas individuais são integrados e testados como um sis-
tema completo, a fim de garantir que os requisitos de software foram atendidos.
A quinta fase é a Operação e Manutenção, normalmente, essa é a fase mais 
longa do ciclo de vida. O sistema é instalado e colocado em operação. A manu-
tençã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 requi-
sitos são descobertos.
Nesse 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 domí-
nio do problema, é recomendável a utilização do modelo de desenvolvimento 
evolucionário.
O modelo evolucionário tem como base a ideia de desenvolver uma imple-
mentaçã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 
tenha sido desenvolvido.
Figura 32: Modelo Evolucionário
Fonte: adaptada de Sommervile (2011).
Modelos De Processo
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
55
Em vez de ter as atividades de especificação, desenvolvimento e validação 
em separado, todo esse trabalho é realizado concorrentemente com um rápido 
feedback por meio dessas atividades.
A figura 32 ilustra bem as fases do modelo evolucionário.
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 especi-
ficação que pode ser desenvolvida gradualmente, na medida em que os usuários 
compreendem melhor o problema.
Porém, como nem tudo são flores, problemas acontecem nesse modelo, 
vamos enumerar alguns:
 ■ 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 constante 
tende a corromper a estrutura do software. Incorporar modificações tor-
na-se cada vez mais difícil e oneroso.
Utilizando o modelo em cascata ou modelo 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 dia-
gramas de entidade-relacionamento (DER), diagrama de fluxo de dados (DFD), 
CASOS DE USO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E56
diagrama de contexto, dicionário de dados etc. Esses modelos fornecem uma 
compreensão única do projeto.
Contudo, o foco da nossa disciplina é a orientação a objetos, portanto, nas 
fases de análise e projeto, construiremos Diagramas de Caso de Uso, Diagramas 
de Classes, Diagramas de Estado, Diagramas de Sequência etc. Esses modelos 
fornecerão uma compreensão única do projeto.
 LINGUAGEM DE MODELAGEM
A Linguagem de modelagem é uma parte muito importante do método. 
Corresponde ao ponto principal da comunicação. Se uma pessoa quer conver-
sar 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 
representação gráfica vistos no modelo (retângulo, setas, o texto etc.) são a nota-
ção, esta é 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 isso, é possível concluir que, independente 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 charge a seguir ilustra de forma lúdica o que ocorre em um projeto de soft-
ware em que a equipe de desenvolvimento e o cliente não se entendem. 
Figura 33: Projeto de Software 
Modelos De Processo
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
57
CASOS DE USO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E58
REQUISITOS DE SOFTWARE
Agora que já sabemos a importância da análise e do projeto na produção de um 
software, vamos conhecer 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 é enge-
nharia de requisitos? Vamos por partes, então. O termo “ENGENHARIA” permite 
dizer que é utilizado 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 é a de elicitar, devemos obter o máximo de informa-
ções para o conhecimento do objeto em questão, dentro do domínio do problema.
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.
Fonte: o autor.
Requisitos De Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
59
DOMÍNIO 
E o que é domínio? Para entender melhor, vamos imaginar que você foi contra-
tado para desenvolver um software em uma determinada Casa de Carnes. Do 
lado direito da Casa de Carnes, existe uma farmácia, do lado esquerdo, um mer-
cado, atrás, uma lanchonete e, em frente, uma igreja. 
Nesse caso, o domínio do seu problema é a Casa de Carnes, os demais esta-
belecimentos 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 para desenvolver um software para determinado 
departamento de uma empresa, dessa forma, determinar o domínio do problema 
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 deve-
mos centrar em funcionalidades, e sim na finalidade.
REQUISITOS
E o que são requisitos?
Os requisitos são os objetivos e as restrições estabelecidas pelo usuário do 
sistema. É o usuário ou cliente o responsável por descrever as necessidades ou 
desejo para o software (SOMMERVILE, 2011).
Em um primeiro momento, é interessante definir os requisitos sem se preo-
cupar em detalhá-los. Isso 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 de requisitos, produzimos um documento estruturado contendo 
requisitos e restrições descritos detalhadamente.
Vamos aos exemplos:
CASOS DE USO
Reprodução proibida. A
rt. 184do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E60
Especificação de requisitos:
1.1. O usuário deverá ser provido de recursos que permitam definir os 
tipos de arquivos 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 utiliza-
dos na representação dos arquivos externos.
Na definição de requisitos, pode se utilizar de uma narrativa ou de represen-
tações gráficas. Normalmente, as informações coletadas são fornecidas pelo 
usuário. Por meio dessas definições, pode ser elaborado o documento prelimi-
nar de requisitos.
Requisitos 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 pro-
vidas 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, usabili-
dade, desempenho, segurança, confiabilidade, manutenibilidade, disponibilidade 
que o sistema deverá possuir. Por exemplo:
 ■ O sistema deverá apresentar interface gráfica (padrão windows).
 ■ Facilidade de uso.
Requisitos De Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
61
 ■ Possibilitar ajuda no contexto.
 A partir das definições dos requisitos, produzimos o documento preliminar de 
requisitos, que deve conter todos os serviços (requisitos) requeridos pelo cliente 
explicitados de forma clara, sem contradições. Atingir esse objetivo é uma tarefa 
difícil pelas inúmeras dificuldades que são encontradas no domínio. 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 pode tornar o documento de requisi-
tos um documento de adivinhações.
Característica 2 - precisam ser possíveis: você precisa ser hábil para imple-
mentar cada requisito declarado, observando os recursos e limitações do sistema 
e ambiente. Para evitar requisitos impossíveis, trabalhe com o pessoal técnico o 
documento de requisitos, checando o que é possível e o que 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 uma interface externa, 
ou, ainda, um padrão. Você pode pensar que “necessário” significa cada requi-
sito que tem 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 auxi-
liem 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 conjuntamente com o cliente a prioridade de cada requisito.
Característica 5: não podem ser ambíguas: cada declaração deve ser expli-
citada de maneira que permita somente uma interpretação. Linguagem natural 
é altamente propensa a ambiguidades. Elimine termos subjetivos, como ami-
gável ao usuário, fácil, simples, rápido, eficiente, vários, aperfeiçoar, maximizar 
CASOS DE USO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E62
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 testes 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 desprovidos de ambiguidades 
também não são verificáveis.
Após o estágio de elicitação (extração), um documento contendo os requisi-
tos 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 envolve uma série de atividades (SUMMERVILE, 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.
Os casos de uso têm um papel importantíssimo na análise de requisitos, pois 
permitem criar um cenário do domínio. Talvez esse seja o único instrumento 
que acompanha o software do início até seu término.
Casos de uso representam funcionalidades completas para o usuário e 
não funcionalidades internas do sistema. Outro ponto importante é que o dia-
grama 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 usuários no processo de desenvolvimento. 
Diagrama de Casos de Uso
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
63
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. Um ator pode ser 
um usuário ou outro sistema.
O diagrama de casos de uso é apenas um panorama visual das funcionalida-
des do sistema, é necessária uma descrição textual para detalhar os casos de uso.
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.
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. 
Diagramas de casos de uso são utilizados para representar, de forma pano-
râ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).