ANALISE E PROJETO ORIENTADO A OBJETOS

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).■ Delimitar o sistema (Domínio).
 ■ Definir as funcionalidades oferecidas ao usuário (não precisamos nos pre-
ocupar nesse momento com a implementação).
Figura 34: 0 Ator
Fonte: o autor.
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 E64
Vamos conhecer a notação para os diagramas de caso de uso preconizados pela 
UML. Os elementos básicos de um diagrama de casos de uso são:
 ■ Atores.
 ■ Casos de uso.
 ■ Relações entre atores e casos de uso.
Atores
Começaremos, então, pelo homem palito, que representa um ator no meu 
sistema, este ator pode ser uma pessoa, outro sistema ou uma entidade externa 
ao sistema. 
Como encontrar os atores para um sistema? Usando as seguintes dicas:
 ■ Examine o problema procurando por pessoas ou sistemas do entorno.
 ■ Faça as seguintes perguntas:
• Quais as pessoas ou departamentos interessados em um determinado requi-
sito funcional?
• Quem irá suprir o sistema com informações e quem irá receber informa-
ções do sistema?
• Quais os recursos externos utilizados pelo sistema?
• Uma pessoa desempenha diferentes papéis?
• O sistema interage com outros sistemas já existentes?
Essas dicas também não garantem que o ator foi bem escolhido da primeira vez, 
pois esse é um processo iterativo, a primeira tentativa dificilmente será a definitiva. 
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
.
65
Casos de Uso
A coleção de casos de uso representa todos os modos de execução do sis-
tema do ponto de vista do usuário. Um caso de uso é uma sequência de ações 
que produz um resultado significativo para um ator.
Em um caso de uso, são necessárias as seguintes 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, as duas denominações são 
utilizadas. Um caso de uso representa uma atividade que o ator realiza.
“As empresas vivem os desafios constantes de produzir software de alta 
qualidade, de impacto no sucesso de seus negócios, com ótima relação cus-
to benefício e, acima de tudo, em curto prazo. A engenharia de software 
estabelece a importância de considerar a estratégia da organização e a ge-
ração de valor no planejamento e na implantação dos seus projetos”.
O texto completo do artigo “Proposta de integração da engenharia de sof-
tware nas estratégias empresariais”, de Adalberto Faria dos Reis e Ivanir da 
Costa, você encontra no link disponível em: <http://www.scielo.br/scielo.
php?script=sci_arttext&pid=S0103-65132005000300013&lang=pt>. Aces-
so em: 29 jul. 2015.
Fonte: Reis e Costa (online).
Figura 35: Caso de Uso
Fonte: o autor.
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 E66
O caso de uso necessita de uma descrição, porém não há descrição padrão defi-
nida pela UML. Em geral, o diagrama é bastante informal e sua estruturação 
(relação entre casos) não deve ser levada ao extremo. 
É importante ressaltar que o diagrama de casos de uso é uma forma de visua-
lizar 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 onde normalmente relacionamos os seguin-
tes itens:
 ■ Nome.
 ■ Descrição.
 ■ Requisitos funcionais providos pelo caso de uso.
 ■ Restrições, tais como pré e pós-condições.
 ■ 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 de uso acima, o sistema pode se encontrar em um dos 
seguintes estados: seguro concedido ou seguro não concedido por repro-
vaçã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.
Veri�car data de 
vencimento
Calcular contas a 
pagar
Financeiro
Veri�car saldo 
disponível
Figura 37: Inclusão
Fonte: o autor. 
Figura 36: Dependência
Fonte: o autor. 
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
.
67
Relações de dependência
As relações de dependência são representadas por uma seta tracejada, a seta 
parte do caso de uso que depende de outro em algum momento, o diagrama da 
figura 36 nos diz que para o cadastro de aluno é necessária conclusão do cadas-
tro de pessoa.
Se um caso de uso inclui o comportamento de outro caso de uso, então, dize-
mos que um usa o outro. Nesse caso, a linha tracejada com uma seta também 
pode representar uma inclusão de outro caso de uso. No exemplo da figura 37, 
o caso de uso Calcular Contas a Receber verificará a data do vencimento e se 
tem saldo disponível.
Já as extensões adicionam um comportamento a um caso de uso que descreve 
uma variação do comportamento normal. Nessa situação, o caso de uso base 
pode ser executado mesmo sem a extensão. O modelo da figura 38 mostra que 
existe um cálculo em Calcular Descontos que irá se estender para Calcular Contas 
a Pagar, ampliando o significado da fórmula existente em Calcular Descontos.
Figura 38: Extensão
Fonte: o autor.
Figura 39: Diagrama de Caso de Uso
Fonte: o autor.
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 E68
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. 
Vamos ilustrar essa documentação por meio do caso de uso para resolver 
expressões aritméticas.
Podemos fazer a descrição textual para o caso de uso Resolver Expressões 
Aritmé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, sub-
traçã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 cancelamento da 
operação pelo aluno.
Fluxo Básico
Usuário Sistema
{Solicita Expressão}
Solicita a expressão. (A2)
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
.
69
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
Fluxos alternativos
A1: em {Valida expres-
são}
Se o usuário fornecer uma expressão sintaticamente 
incorreta, informá-lo sobre o erro e retornar ao fluxo 
básico em {Solicita expressão}
A2: em {Solicita expres-
são}
O usuário pode decidir encerrar o caso de uso sem 
fornecer uma expressão. Nesse caso, retornar ao fluxo 
básico em {Fim}
Quadro 1:Resolver expressões aritmética
Essa descrição textual detalha o caso de uso, mostrando prés e pós-condições 
para execução, bem como o fluxo básico de execução, que significa dizer que 
o sistema solicitará a expressão aos alunos que poderão cancelar, se desejarem, 
sendo desviado o fluxo de execução para o fluxo alternativo A2, porém, caso não 
cancele, o sistema validará a expressão fornecida pelo aluno, desviando para o 
fluxo alternativo A1, que tem como objetivo validar a expressão de entrada, se 
passar pela validação, o sistema calculará o valor e mostrará o resultado.
Um fluxo descreve como o sistema e os atores colaboram para produzir algo 
de valor aos atores e o que pode impedir sua obtenção. Um fluxo descreve um 
caminho entre muitos possíveis, visto que um caso de uso pode ser executado 
de vários modos.
Existem fluxos básicos, que demonstram o fluxo normal de eventos, e alter-
nativos, que dizem o que fazer, caso não seja possível seguir o fluxo básico. 
Para exemplificar, vamos nos inspirar na situação em que uma pessoa 
explica um caminho à outra. Primeiro, o fluxo básico é explicado, depois, o 
fluxo alternativo. 
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 E70
No caso de uso acima “Resolver expressões aritméticas”, o usuário pode tanto 
fornecer a expressão para o cálculo (fluxo básico) quanto cancelar a operação, 
desviando o fluxo alternativo A2, porém, caso o usuário siga no fluxo básico, 
após o fornecimento da expressão para cálculo, o fluxo será desviado para um 
caminho alternativo A1 que valida a entrada.
Dessa forma, podemos dizer que um fluxo alternativo apresenta um compor-
tamento opcional, de outra forma, que não é parte do comportamento normal 
de um caso de uso. 
Fluxos alternativos são utilizados para representar tratamento de exceções 
ou um comportamento alternativo complexo que tornaria o fluxo básico muito 
longo ou de difícil compreensão. 
 
 
 
 
 
 
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
.
71
CONSIDERAÇÕES FINAIS
 Nesta unidade, aprendemos que o papel da análise é 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.
Vimos que, independente do método ou processo utilizado para a análise, 
projeto e implementação, algumas etapas são comuns, por exemplo, a identifica-
ção da necessidade, o estudo de viabilidade, a análise, o projeto, a implementação, 
a implantação e a manutenção.
Aprendemos que um método precisa de um modelo de linguagem e um 
processo. O primeiro diz respeito à notação que o método usa para descrever o 
projeto. Já o segundo descreve os passos que devem ser seguidos para se cons-
truir o projeto.
Familiarizamo-nos com dois modelos de processo de software: o “modelo 
cascata” e o “modelo evolucionário”. Verificamos que o modelo cascata é indi-
cado quando conhecemos o domínio e o problema por completo, pois as fases 
são bem definidas e pressupõem que o início de uma nova fase depende da con-
clusão da fase anterior. Já o modelo evolucionário é indicado quando temos que 
aprender sobre o domínio e o problema no desenvolvimento da aplicação, o que 
resulta em “N” versões intermediárias até chegarmos ao produto final.
Aprendemos que a adição do termo engenharia à análise de requisitos pres-
supõe que técnicas sistemáticas são utilizadas no processo de levantamento de 
requisitos, garantindo que os requisitos serão consistentes, completos e relevantes.
Vimos que a engenharia de requisitos é de suma importância, pois é nessa 
fase que especificamos o problema, compreendemos e definimos uma proposta 
por meio de um modelo válido.
Por fim, aprendemos que o modelo de caso de uso é um diagrama utilizado 
na análise de requisitos, com o objetivo de compreender o problema, delimitar 
o sistema e definir as funcionalidades oferecidas ao usuário sem nos preocupar-
mos com a implementação.
1. Quais objetivos o analista deve ter no momento da análise? Explique cada um 
deles.
2. O que é um domínio do problema e qual a importância de conhecê-lo?
3. Conceitue linguagem de modelagem, método e processo.
4. Quando devemos utilizar o modelo de processo cascata e o modelo de processo 
evolucionário?
5. O que acontece em um projeto de software no qual a equipe de desenvolvimen-
to e o cliente não se entendem?
6. O que são requisitos de software e como podemos classificá-los? 
Material Complementar
MATERIAL COMPLEMENTAR
Fundamentos do desenho orientado a objetos com UML
Meilir Page-Jones
Editora: Makron Books
Sinopse: Fundamentos do Desenho Orientado a Objeto com UML 
mostra, tanto a programadores novatos quanto aos experientes, como aplicar os conceitos de 
desenhos a UML, assim como as melhores práticas quanto ao desenvolvimento de OO para 
melhorar o seu código e o seu índice de sucesso em projetos fundamentados em objetos.
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “Em busca de um modelo 
de referência para engenharia de requisitos em ambientes de desenvolvimento distribuído de 
software”. Esse artigo visa apresentar um modelo de referência para engenharia de requisitos em 
ambientes de desenvolvimento distribuído de software, reunindo resultados de pesquisa teórica 
e prática.
O artigo encontra-se disponível em: <http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_
WER03/leandro_audy.pdf>. Acesso em: 29 jul. 2015.
Qual é a função primordial de qualquer 
software desenvolvido? Parece simples a 
questão, mas respondo que é ter acessi-
bilidade. Para que isso seja possível, hoje, 
já é obrigatório testá-lo adequadamente. 
Vamos conhecer uma forma sistêmica de 
montar toda a linha de testes embasada 
em casos de uso.
Uma das primeiras perguntas que devem 
ser levantada para iniciar a montagem de 
um plano de testes é: o que testar? Parece 
visível a resposta que é testar as funcio-
nalidades que compõem o escopo do 
software que está sendo desenvolvido. 
Agora, você se pergunta: onde está des-
crito esse escopo? Normalmente, ele pode 
estar na proposta do projeto, na especifi-
cação funcional e, em muitos projetos, nos 
casos de uso.
Eduardo Ernandes da Silva, no artigo inti-
tulado “Como fazer um plano de testes”, 
descreve os casos de uso como requisi-
tos, que identificam o valor que o cliente 
espera obter da funcionalidade e represen-
tam a forma como o sistema será utilizado. 
Além disso, permitem identificar todos os 
caminhos que o usuário pode percorrer 
para conseguir o que deseja e se podem 
ocorrer problemas. E, também, mostram ao 
cliente o que esperar do software, ao desen-
volvedor, o que codificar e, ao testador ou 
certificador, o que validar para garantir a 
qualidade dos entregáveis.
Desse modo, podemos concluir que os casos 
de uso ajudam na certificação e validação 
dos requisitos implementados, simplifi-
cando e sistematizando o processo de teste 
do software, permitindo um ganho de pro-
dutividade e ajudando na garantia de que 
todo o escopo vai ser abrangido pelo teste.
Sabendo onde os casos de uso podem nos 
ajudar, vem a próxima pergunta: o que fazer 
agora? No artigo citado, Silva classifica que 
são várias as utilidades e destaca quatro 
procedimentos que podemos seguir:
• Selecione o caso de uso que será tes-
tado, identifique o fluxo principal e os 
fluxos alternativos e desenhe um dia-
grama de atividades. Desse modo, vai 
conseguir visualizar mais facilmente 
todos os cenários que o usuário pode 
utilizar.
• Agora que já identificou os cenários, 
você vai começar a escrever um caso 
de teste para cada cenário, detalhandotodos os passos do cenário. Desse 
modo, o testador vai poder executar 
as ações do ator e validar se a resposta 
do sistema está de acordo com o que 
foi especificado.
• Para iniciar os testes, vai ser necessária 
a criação de uma base de dados de cer-
tificação, se ela ainda não existir (não 
é prudente fazer os testes na base de 
desenvolvimento e muito menos em 
produção), e identificar os dados de 
entrada que serão utilizados nos testes.
• É importante tabular o resultado dos 
testes, como quantidade de acertos, 
defeitos e correções, e armazenar essa 
informação em algum meio perma-
nente. Isso vai servir para avaliar a 
qualidade de cada desenvolvedor da 
sua equipe.
Dessa maneira, podemos concluir que usar 
o casos de uso como modelo para os tes-
tes vai permitir uma visão mais apurada do 
software e ter maior noção das necessida-
des dos clientes. 
Fonte: adaptada de Silva (online). 
U
N
ID
A
D
E III
Prof. Me. Déverson Rogério Rando
DIAGRAMA DE CLASSES
Objetivos de Aprendizagem
 ■ Entender a notação UML para o Diagrama de Classes.
 ■ Entender o objetivo do Diagrama de Classes.
 ■ Conhecer a Notação UML para a o Diagrama de Classes.
 ■ Compreender as características dos Atributos, métodos e tipos de 
dados.
 ■ Entender como ocorre a multiplicidade entre as associações de 
classes.
 ■ Conhecer os tipos de associação entre classes (unária, binária, 
associativa, agregação, generalização).
 ■ Compreender o conceito de Herança múltipla.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Diagrama de Classes
 ■ Notação para classes
 ■ Atributos
 ■ Métodos
 ■ Multiplicidade
 ■ Associação Unária
 ■ Associação Binária
 ■ Classe Associativa
 ■ Agregação
 ■ Generalização
 ■ Herança Múltipla
INTRODUÇÃO
Caro(a) aluno(a), iniciamos a terceira unidade do livro Análise e Projeto Orientado 
a Objetos relembrando e reforçando o conceito de classes visto na primeira uni-
dade. Relembrar conceitos é somente um aperitivo para desvendarmos os segredos 
da modelagem de um diagrama de classes.
Motivados pela descoberta, aprenderemos a notação UML para o diagrama 
de classes, além das convenções para os nomes das classes, atributos e métodos, 
veremos as várias formas de notação para o diagrama de classes.
A classe tem a função de individualizar o objeto (qualquer coisa concreta ou 
abstrata) por meio de suas características (atributos) e comportamentos (méto-
dos). Sendo assim, aprenderemos a sintaxe, ou seja, como construir a linha de 
declaração para os atributos e métodos, além de conhecermos os tipos de dados 
primitivos.
Veremos que existem várias formas de associação de classes e tais associa-
ções fazem surgir o conceito de multiplicidade. A multiplicidade é o resultado 
da necessidade de associação entre as classes, a multiplicidade nos mostra a car-
dinalidade de uma associação.
Veremos as várias formas de associação entre classes, dentre elas, a asso-
ciação unária, binária, agregação regular e composição, generalização e classes 
associativas.
Aprenderemos, também, que na herança múltipla uma subclasse é derivada 
de mais de uma superclasse que evidencia somente uma parte do conceito repre-
sentado na subclasse. 
Veremos que a herança múltipla é uma forma mais complexa de generaliza-
ção, haja vista que a herança simples restringe a hierarquia de classes a somente 
uma árvore.
Porém, mesmo mais complexa, a herança múltipla tem a vantagem de ofe-
recer maior capacidade de especificação de classes e a maior oportunidade de 
reutilização. A desvantagem é justamente, como já citamos, a perda em simpli-
cidade conceitual e implementação. 
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
.
77
Figura 40: Objetos do mundo real
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E78
DIAGRAMA DE CLASSES
Como já vimos, após a elaboração do diagrama de caso de uso, podemos mode-
lar a primeira versão do Diagrama de Classes. O diagrama de classes mostra a 
estrutura estática do sistema. 
A classe representa a ABSTRAÇÃO de um conjunto de OBJETOS do mundo 
real que possui tipos, características e comportamento comuns. A Abstração 
ocorre quando definimos um objeto conceitual a partir de OBJETOS do mundo 
real que possuam as mesmas características e comportamento, podendo ser clas-
sificados como pertencentes a um mesmo tipo.
Objeto é qualquer coisa concreta ou abstrata com existência perceptível no 
mundo real que possa ser individualizado por possuir características e compor-
tamento próprio.
Na figura 40, temos o exemplo de objetos de mundo real que, na verdade, são 
funcionários que têm características em comum, por exemplo: todos os funcio-
nários possuem nome, endereço e telefone, dessa forma, podemos abstrair para 
criar um objeto conceitual a partir dos objetos do mundo real.
Uma classe é uma estrutura que modela um conjunto de objetos cujas característi-
cas sejam similares. A classe, por meio dos métodos, modela o comportamento de 
seus objetos, e os possíveis estados do objeto, são modelados mediante atributos.
As classes juntamente com os atributos, operações e associações são defi-
nidas em um diagrama de classe. Porém não existe uma receita ou um método 
Aluno
Aluno
- Nome : String
- Endereco : String
- Data_nasc : Date
Figura 41: Notação simplificada de um classe
Fonte: o autor. 
Figura 42: Notação com nome da classe e atributos
Fonte: o autor. 
Notação Para Classes
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
.
79
para a escolha das classes do sistema. Essa tarefa depende fundamentalmente 
da experiência do desenvolvedor.
 No início do projeto, as classes são denominadas de “candidatas” ou de 
“análise”, pois existe uma probabilidade muito grande de que mudem ao longo 
do projeto. Antes de aprendermos como fazer, apresento a notação para classes.
NOTAÇÃO PARA CLASSES
Uma classe é representada por um retângulo e pode ser apresentada somente 
com o seu estereótipo (nome da classe). 
Por convenção, todo nome de classe deve começar com uma letra maiúscula 
e, de preferência, não pode conter letras não ASCII (caracteres de língua de ori-
gem latina, como caracteres acentuados). Portanto, não é possível declarar uma 
classe com qualquer caracter especial (@, #, $, %, &, *, _, etc...).
Caso o nome de uma classe seja composto por mais de uma palavra, a pri-
meira letra de cada palavra deve ser em maiúscula. 
A classe também pode ser apresentada como um retângulo com dois compar-
timentos, em que o primeiro contém o nome da classe e o segundo contém os 
atributos juntamente com seu tipo de dados.
Aluno
- Nome : String
- Endereco : String
- Data_Nasc : Date
- Criar() : void
- Eliminar() : void
Nome da Classe
(Estereótipo)
Atributos
Métodos
(Operação)
Figura 43: Notação com nome, atributos e métodos
Fonte: o autor.
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E80
Por fim, a classe também pode ser apresentada em um retângulo dividido em 
três compartimentos, como ilustra a figura 43. 
Uma classe abstrata não gera objetos, porque geralmente ela tem, no míni-
mo, uma operação abstrata nela definida. Se ela na verdade criasse um ob-
jeto, uma mensagem invocando a operação abstrata do objeto provocariaum erro de rum-time. 
Fontes: Page-Jones (2001)
 
 
 
 
 
 
Atributos
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
.
81
ATRIBUTOS
O dicionário Aurélio explica que atributo é aquilo que é próprio de alguém ou 
de algo, resumindo, atributo é uma característica.
Dessa forma, os atributos são os elementos que definem a estrutura de uma 
classe, também são denominados de variáveis de classe. O atributo é um ele-
mento da classe que pode representar uma característica dos objetos instanciados.
A sintaxe (assinatura) para declaração de um atributo em UML tem o seguinte 
formato:
[<visibilidade>]<nome>:[<tipo>][=<valor inicial>]
Vamos entender cada um dos elementos da sintaxe. Gostaria de abrir um parên-
tese para explicar que sintaxe corresponde a um conjunto de regras que diz como 
a instrução deve ser escrita, a ordem com que os elementos devem aparecer.
 <visibilidade>
A visibilidade nos informa quais são as classes que podem ver esse atributo, 
temos as seguintes opções:
Notação Nome Significado
+ Público Todas as classes têm acesso.
- Privado Somente métodos definidos na classe podem vê-lo.
# Protegido Métodos definidos na classe e nas classes derivadas 
podem vê-lo.
~ Pacote Visível dentro das classes do pacote.
<nome>
 ■ O nome do atributo deve obedecer algumas regras também, tais como:
 ■ O nome pode começar com qualquer letra e os caracteres $ ou _.
 ■ Não conter caracteres exclusivos da língua portuguesa (acentos, cedi-
lhas etc.).
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E82
 ■ Não começar por números.
 ■ Caso o nome de um atributo seja composto por mais de uma palavra, a 
primeira letra de cada palavra deve ser em maiúscula.
 <tipo>
Pode-se utilizar os tipos da linguagem de programação de implementação. 
Vamos listar alguns tipos primitivos, por primitivo entendemos aqueles tipos 
de dados mais usuais e básicos. Por exemplo:
 ■ Boolean: admite os valores true ou false.
 ■ Char: usa o código UNICODE e ocupa cada caractere 16 bits.
 ■ Inteiros: diferem nas precisões e podem ser positivos ou negativos:
• Byte: 1 byte.
• Short: 2 bytes.
• Int: 4 bytes.
• Long: 8 bytes.
Reais em ponto flutuante: igual aos inteiros, também diferem nas precisões e 
podem ser positivos ou negativos:
• Float: 4 bytes.
• Double: 8 bytes.
<valor inicial> 
Valor inicial para o atributo que respeite o tipo de dado, ou seja, se o tipo de 
dado for um inteiro, não poderei informar uma data como valor inicial. 
No figura 44, podemos observar que o atributo nome tem visibilidade pri-
vada, ou seja, somente os métodos dessa classe poderão realizar operações com 
esse atributo. O atributo sexo é protegido, podendo ser visto somente nessa 
classe ou em classes derivadas, observe que esse atributo é iniciado com o valor 
‘F’, que implica dizer que sempre que um objeto for instanciado receberá o valor 
‘F’. Por fim, o atributo código tem a visibilidade pública, que significa dizer que 
esse atributo está visível para todas as classes.
Classe
- Nome: String
# Sexo: char = ‘F’
+ Codigo: Integer = 20
Figura 44: Classe com os compartimentos de nome e atributos
Fonte: o autor. 
Métodos
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
.
83
MÉTODOS
De maneira geral, um método é uma maneira de ordenar a ação de acordo com 
certos princípios, ou seja, é a maneira ou forma de proceder que determina um 
comportamento.
Sendo assim, os métodos determinam o comportamento dos objetos de 
uma classe e são semelhantes às funções ou procedimentos da programação 
estruturada.
Os métodos possuem uma propriedade especial que, quando em tempo de 
execução, possuem acesso aos dados armazenados em um objeto e são, dessa 
forma, capazes de controlar o estado do objeto.
[<visibilidade>]<nome>(<lista argumentos>):[<retorno>]
A sintaxe para declaração de um método é semelhante à declaração de atribu-
tos, vamos lá:
<visibilidade>:
Notação Nome Significado
+ Público Todas as classes têm acesso.
- Privado Somente métodos definidos na classe podem vê-lo.
# Protegido Métodos definidos na classe e nas classes derivadas 
podem vê-lo.
~ Pacote Visível dentro das classes de um pacote.
Classe
- Nome: String
# Sexo : char = ‘F’
Argumento
+ calcularIdadeEmMeses(data : Date) : int
+ Codigo : Integer = 20
Figura 45: Lista de Argumentos do método
Fonte: o autor.
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E84
<nome>: 
O nome do método segue as mesmas regras para o nome dos atributos e 
da classe.
 <lista de argumentos>
Argumentos são os meios que utilizaremos para passar dados para o método 
e esses métodos irão trabalhar, especificamente, em cima dessas informações. 
Por exemplo:
<retorno> 
Tipo do dado retornado pelo argumento. Pode-se utilizar os tipos da lin-
guagem de implementação:
 ■ Boolean: não é um valor numérico, só admite os valores true ou false.
 ■ Char: usa o código UNICODE e ocupa cada caractere 16 bits.
 ■ Inteiros: diferem nas precisões e podem ser positivos ou negativos:
• Byte: 1 byte.
• Short: 2 bytes.
• Int: 4 bytes.
• Long: 8 bytes.
 ■ Reais em ponto flutuante: da mesmas forma que o tipo de dados de intei-
ros, os tipo de dados Reais também diferem nas precisões e podem ser 
positivos ou negativos:
• Float: 4 bytes.
• Double: 8 bytes.
Classe
+ calcularIdadeEmMeses(data : Date) : int
- Nome: String
# Sexo : char = ‘F’
Retorno
+ Codigo : Integer = 20
Figura 46: Retorno do método
Fonte: o autor. 
Multiplicidade
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
.
85
No diagrama a seguir, podemos observar que, para o método calcularIdadeEm-
Meses funcionar, deverá ser passada a data de nascimento e, após o cálculo para 
transformar em meses, o método retornará um valor inteiro correspondente a 
quantidade de meses de vida.
MULTIPLICIDADE
Associação é uma relação entre duas classes significando que os objetos des-
tas classes possuem uma ligação. Um conceito importante para as associações 
entre as classes é a multiplicidade que mostra a cardinalidade de uma associação. 
A multiplicidade especifica quantas instâncias de uma classe relacionam-se 
a uma única instância de uma classe associada. A tabela a seguir mostra a repre-
sentação da notação e seu significado.
Representação Significado
1 Exatamente um.
0..* Zero ou mais.
* Zero ou mais.
1..* Um ou mais.
0..1 Zero ou um.
5..8 Intervalo específico (5, 6, 7 ou 8).
4..7,9 Combinação (4,5,6,7 ou 9).
Aluno Disciplina
1 1Cursa
Figura 47: Multiplicidade um para um
Fonte: o autor.
Figura 48: Sem declaração de multiplicidade
Fonte: o autor.
Aluno Disciplina
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E86
Vamos exemplificar: o diagrama de classes da figura 46 nos mostra o relacio-
namento entre as classes Aluno e Disciplina, para definir a multiplicidade do 
relacionamento, fazemos as seguintes perguntas:
 ■ Realizando a leitura do diagrama da esquerda para a direita:
• Um aluno pode cursar quantas disciplinas?
 ■ A sua resposta será a multiplicidade que deverá ser informada ao 
lado da classe disciplina.
 ■ Realizandoa leitura do diagrama da direita para esquerda:
• Uma disciplina pode ser cursada por quantos alunos?
 ■ A sua resposta será a multiplicidade que deverá ser informada ao 
lado da classe aluno.
Dessa forma, podemos fazer a seguinte leitura para o diagrama de classes abaixo:
 ■ Da esquerda para a direita:
• Um Aluno pode cursar somente uma disciplina.
 ■ Da direita para esquerda:
• Uma Disciplina pode ser cursada somente por um aluno.
Vamos exercitar um pouco: a figura 48 nos mostra as classes aluno e disciplina 
sem a multiplicidade.
Vamos definir uma ação entre as classes para definir a multiplicidade, pensei na palavra 
“cursa”, uma vez que o aluno cursa a disciplina, ficará como apresentado na figura 49:
Aluno Disciplina
Cursa
Figura 52: Multiplicidade somente um para um ou muitos
Fonte: o autor.
Figura 50: Multiplicidade um ou muitos
Fonte: o autor. 
Figura 49: Identificação da associação
Fonte: o autor. 
Aluno Disciplina
1..*Cursa
Multiplicidade
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
.
87
O próximo passo é fazer aquela perguntinha da esquerda para a direita:
 ■ Um aluno cursa quantas disciplinas?
• Nossa resposta, agora, será, no mínimo, uma e, no máximo, várias 
disciplinas.
Nosso diagrama de classes ficará como na figura 50:
Por fim, o próximo passo é fazer aquela perguntinha da direita para esquerda:
 ■ Uma disciplina pode ser cursada por quantos alunos?
• Nossa resposta, agora, será várias disciplinas.
Nosso diagrama de classes ficará como na figura 51:
Aluno Disciplina
* 1..*Cursa
Figura 51: Multiplicidade um ou muitos para muitos
Fonte: o autor.
Perfeito, agora nosso diagrama está completo, fácil, não é!? Vamos testar outras 
cardinalidades, supondo que um aluno pode cursar somente uma disciplina, mas 
a disciplina pode ser cursada por, no mínimo, um e, no máximo, muitos alunos, 
nosso diagrama ficará como na figura 52:
Aluno Disciplina
1..” 1Cursa
Funcionário
- Nome: String
- Endereço: String0..1
*
chefe
Gerência
trabalhador
Figura 53: Associação Unária
Fonte: o autor.
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E88
ASSOCIAÇÃO UNÁRIA
Vimos que a multiplicidade entre as associações de classes nos informa quantas 
instâncias de objetos da classe A se associam a quantas instâncias de objetos da 
classe B, porém as classes podem se associar de várias formas.
O diagrama da figura 53 nos mostra uma associação unária, em que, de 
acordo com Medeiros (2004), a classe se associa com ela mesma, ou seja, uma 
autoassociação. Interpretando o diagrama, verificamos que um funcionário 
pode ser “chefe” ou “trabalhador”, que o chefe pode ter vários trabalhadores sob 
suas ordens e um trabalhador pode ter nenhum chefe e, no máximo, um. Mas 
quando o trabalhador não terá nenhum chefe? Resposta: quando ele for o chefe.
 
 
 
 
 
 
Cliente Compra
1 *Fazer
Contrato Cliente
Regras do
Contrato
0..” 1..”
1..”
Figura 54: Associação binária
Fonte: o autor.
Figura 55: Associação Ternária
Fonte: o autor.
Associação Binária
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
.
89
ASSOCIAÇÃO BINÁRIA
As associações binárias são as mais comuns, elas acontecem entre duas classes. 
Fazendo a leitura do diagrama da figura 54 podemos verificar que uma instância 
de objeto da classe cliente está associada com várias instâncias da classe compra, 
porém cada instância de objeto da classe compra está associada a somente um 
cliente, resumindo, um cliente pode realizar muitas compras, mas cada compra 
pode ser somente de um cliente (MEDEIROS, 2004).
ASSOCIAÇÃO TERNÁRIA
A associação ternária associa três classes. A notação para essa associação é 
um losango (diamante) e ainda suporta uma associação de classe ligada a ela 
(MEDEIROS, 2004).
O diagrama da figura 55 mostra que um cliente pode não ter nenhum contrato 
ou vários e um contrato pode ser de um cliente ou de vários, porém a associação 
entre as classes cliente e contrato associa, também, a classe regras do contrato, 
que, nesse caso, pode ter uma ou várias regras para aquele contrato específico.
Produto Venda
Ítens da Venda
* *
Ítens da Venda
Figura 56: Classe associativa
Fonte: o autor.
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E90
CLASSE ASSOCIATIVA
De acordo com Summerville (2011), quando uma associação possuir atributos 
próprios, pode-se criar uma classe associativa. Essas classes são úteis quando 
queremos armazenar o histórico de uma associação (relacionamentos que ocor-
rem e interessam ser salvos). 
Vamos enumerar algumas características das classes associativas:
 ■ São comuns em associações de multiplicidade *:* (muitos para muitos), 
embora não seja uma regra.
 ■ A linha que representa a associação não é nomeada, o nome da classe 
associativa deve ser suficiente para identificar a associação.
 ■ Classes associativas podem estar relacionadas a outras classes.
No modelo da figura 56, podemos observar que a multiplicidade em ambos os 
lados da associação é “*” (várias), o que implica dizer que, em uma venda, podem 
ser vendidos vários produtos e um produto pode ser vendido em várias vendas. 
Como resultado dessa associação, temos uma classe associativa, que permite que 
armazene cada um dos itens de produto juntamente com a quantidade e valor 
total, e uma classe separada.
A B
B existe sem A
Figura 57: Agregação Regular
Fonte: o autor.
Agregaçã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
.
91
AGREGAÇÃO
Lee & Tepfenhart (2002) explicam que a agregação é um caso especial de asso-
ciação utilizado para representar relacionamentos de pertinência “parte-todo” 
ou “uma parte de”. Permite representar o fato de que um objeto ou mais objetos 
de uma classe fazem parte de um objeto de outra classe. 
Um exemplo típico é uma janela de interface com o usuário composta por 
diversos botões, caixas de textos, barra de rolagem, entre outros. A agregação 
representa uma ligação entre o objeto todo (a janela) e as partes (botão, caixas 
de textos, barra de rolagem). Um comportamento que se aplica ao todo se pro-
paga às partes, por exemplo, ao movimentar a janela, todos seus elementos de 
deslocam também.
A agregação pode ser regular ou de composição, vamos ver a diferença entre 
elas.
AGREGAÇÃO REGULAR
De acordo com Lee & Tepfenhart (2002), a agregação regular é representada 
por um losango vazado, o diagrama da figura 57 nos diz que a classe B é “uma 
parte” da classe A, porém as instâncias de objetos da classe B existem sem um 
objeto associado na classe A.
No exemplo da figura 58, verificamos que em um quadro pode ter uma ou várias 
figuras, ou seja, a figura é uma parte do quadro, porém a figura existe mesmo 
que não exista um quadro para ela.
Quadro Figura
O objeto �gura existe sem o
objeto quadro
1..”
Figura 58: Agregação Regular
Fonte: o autor.
Figura 59: Agregação Regular
Fonte: o autor.
1 1 1 0..”
CPU
Monitor Teclado Mouse Drive
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E92
Para ficar ainda mais claro, vamos utilizar o exemplo da figura 59, que nos mos-
tra que monitor, teclado, mouse edrive são partes de CPU, porém cada uma das 
instâncias desses objetos existe sem uma instância de CPU associada. Nesse caso, 
podemos afirmar que a destruição do objeto CPU não implicará na destruição 
dos demais objetos associados.
AGREGAÇÃO DE COMPOSIÇÃO
Lee & Tepfenhart (2002) explicam que a agregação de composição é uma agre-
gação de fato, em que o todo é composto pelas partes. Existe uma relação forte 
entre o todo e as partes, pois, quando o todo é destruído, as partes também serão, 
ou seja, a eliminação do todo se propaga para as partes. De outra forma, o todo 
e as partes têm tempos de vida semelhantes.
Como podemos verificar na figura 60, a agregação de composição é repre-
sentada por um losango preenchido, o diagrama abaixo nos diz que a classe B 
é “parte-todo” da classe A, dessa forma, as instâncias de objetos da classe B não 
existem sem um objeto associado na classe A. A destruição da instância de objeto 
de A implica na destruição da instância de objeto associado da classe B.
A B
Figura 62: Agregação de composição
Fonte: o autor.
Figura 61: Agregação de composição
Fonte: o autor.
Figura 60: Agregação de Composição
Fonte: o autor.
Orçamento Ítens Orçamento
*
Agregaçã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
.
93
Na figura 61, podemos verificar que um orçamento pode ter muitos itens de orça-
mento, porém os itens de orçamento não existirão sem o orçamento.
Na figura 62, o diagrama nos diz que um documento é composto de nenhum 
ou muitos parágrafos e um parágrafo é composto por uma ou muitas sentenças, 
as sentenças não existem sem o parágrafo e o parágrafo não existe sem o docu-
mento. A destruição de uma instância de objeto da classe documento implica na 
destruição das instâncias de objetos das outras duas classes agregadas.
Documento Parágrafo Sentença
1..* 1..*
A decisão de utilizar a agregação é uma questão de julgamento, nem sempre é 
evidente que uma associação deve ser modelada como agregação.
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E94
GENERALIZAÇÃO
Vamos ver, agora, outro tipo de associação de classes, denominado generalização. 
Uma generalização é uma associação hierárquica que indica um relacionamento 
entre a classe de mais alto nível, denominada superclasse, e outra de mais baixo 
nível, denominada subclasse, ou, ainda, classe mãe e filha, respectivamente.
Em outras palavras, a generalização é um relacionamento entre um elemento 
geral e um outro mais específico. O elemento mais específico possui todas as carac-
terísticas do elemento geral e contém, ainda, mais particularidades. Um objeto 
mais específico pode ser usado como uma instância do elemento mais geral. 
Existem alguns tipos de generalizações que variam em sua utilização a partir 
da situação. São eles: generalização normal e restrita. As generalizações restritas 
se dividem em generalização de sobreposição, exclusiva, total e parcial. A gene-
ralização recebeu muitos nomes, podendo ser denominada especialização ou, 
ainda, herança. 
A diferença entre a generalização e as demais associações é que, na gene-
ralização, é enfatizado o conceito de herança que tem como característica a 
reutilização de atributos e métodos definidos nas classes mais gerais (super-
classe) por classes mais específicas (subclasses). Ou seja, permite a criação de 
elementos especializados em outros. Por sua vez, as subclasses, que represen-
tam as classes mais especializadas, herdam atributos, métodos e associações da 
superclasse, que representa a classe mais genérica. A notação para a generaliza-
ção é uma seta em branco apontando sempre para a superclasse.
A figura 62 modela uma generalização para pessoa. Uma pessoa pode ser 
física ou jurídica, porém o que diferencia os tipos de pessoas é um atributo espe-
cífico que identifica e pessoa física (CPF) e a pessoa jurídica (CNPJ), ambas têm 
os atributos nome e endereço que serão herdados da superclasse (pessoa), além 
dos métodos Criar() e Eliminar().
Pessoa
- Nome : String
- Endereço : String
- Criar() : void
- Eliminar() : void
Jurídica
- CNPJ : String
Física
- CPF : String
Homem Mulher
Pessoa
{Total}
Figura 62: Generalização
Fonte: o autor.
Figura 63: Generalização com cobertura total
Fonte: o autor.
Generalizaçã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
.
95
COBERTURA TOTAL
A generalização apresenta um conceito importante que é a cobertura. A nota-
ção para a cobertura é uma linha tracejada com o tipo de cobertura entre chaves.
Dizemos que a cobertura é total ou completa, se cada elemento da classe 
genérica é mapeado para, pelo menos, um elemento das classes especializadas.
Na figura 63, verificamos que a cobertura da generalização é total, o que sig-
nifica dizer que uma pessoa, obrigatoriamente, tem que ser homem ou mulher.
Homem Mulher
Pessoa
{Total, Exclusiva}
Figura 64: Generalização com cobertura total e exclusiva
Fonte: o autor.
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E96
EXCLUSIVA
 A cobertura de uma generalização é exclusiva, se cada elemento da classe gené-
rica é mapeado para, no máximo, um elemento das subclasses.
Na figura 64, refinei o diagrama do exemplo anterior, juntando as cobertu-
ras total e exclusiva, dessa forma, temos que uma pessoa será, obrigatoriamente, 
um homem ou uma mulher, não podendo ser os dois.
PARCIAL
A cobertura é parcial ou incompleta se existe algum elemento da classe genérica 
que não é mapeado para nenhum elemento das subclasses.
A figura 65 nos mostra que um veículo pode ser um carro ou uma bicicleta, 
podendo não ser nenhum dos dois, percebam que, nesse tipo de cobertura, não 
sou obrigado a especializar o veículo, diferente da cobertura total que, obriga-
toriamente, devo mapear para, pelo menos, uma subclasse.
Aluno Professor
Pessoa
{Sobreposição}
Figura 65: Generalização com cobertura parcial
Fonte: o autor.
Figura 66: Generalização com cobertura de sobreposição
Fonte: o autor.
Generalizaçã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
.
97
SOBREPOSIÇÃO
A cobertura de uma generalização é de sobreposição, se existe algum elemento 
da classe genérica que é mapeado para elementos de duas ou mais subclasses 
diferentes.
Na figura 66, podemos verificar que uma pessoa pode ser aluno ou profes-
sor, podendo ser os dois.
Carro Bicicleta
Veículo
{Parcial}
Graduação Pós-graduação Extensão
Evento
Curso
Figura 67: Herança múltipla
Fonte: o autor.
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E98
As coberturas podem ser combinadas da seguinte forma:
 ■ Total, Exclusiva: nessa combinação de cobertura, uma classe genérica 
deve ser mapeada para uma única subclasse.
 ■ Total, Sobreposição: nessa combinação de cobertura, uma classe genérica 
deve ser mapeada para uma ou várias subclasses.
 ■ Parcial, Exclusiva: nessa combinação de cobertura, uma classe genérica 
pode ser mapeada para uma única subclasse ou para nenhuma.
 ■ Parcial, Sobreposição: nessa combinação de cobertura, uma classe gené-
rica pode ser mapeada para uma ou mais subclasses ou para nenhuma.
HERANÇA MÚLTIPLA
Na herança múltipla,uma classe (subclasse) é derivada de mais de uma classe 
base (superclasse). Porém ocorre uma perda conceitual, uma vez que uma super-
classe não representa um caso geral completo da subclasse. Ou seja, a superclasse 
representa uma parte do conceito representado na subclasse. 
Na figura 67, Curso não é uma generalização completa de Extensão, pois 
não leva em conta aspectos de Extensão ligados a Eventos. Dessa forma, a sub-
classe Extensão herdará atributos e métodos das superclasses Curso e Evento.
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
.
99
A herança múltipla permite a concatenação (mesclagem) de informações de duas 
ou mais origens. Essa é uma forma um pouco mais complexa de generalização 
do que a herança simples, que restringe a hierarquia de classes a uma árvore. 
A vantagem da herança múltipla é a maior capacidade de especificação de 
classes e a maior oportunidade de reutilização. Ela traz a modelagem de obje-
tos para mais próxima da maneira como se costuma pensar. A desvantagem é a 
perda em simplicidade conceitual e de implementação. 
CONSIDERAÇÕES FINAIS
Nesta unidade, aprendemos que o diagrama de classes mostra a estrutura estática 
do domínio das abstrações (classes) do sistema. Ele descreve os tipos de obje-
tos no sistema e os vários tipos de relacionamentos estáticos que existem entre 
eles. Mostra os atributos e operações de uma classe e checa a maneira com que 
os objetos colaboram entre si.
Vimos que essa ferramenta de modelagem produz o diagrama mais impor-
tante do sistema, pois é usada para modelar um entendimento do domínio da 
aplicação (essencialmente parte do sistema de atividades humanas), e os obje-
tos também são entendidos como partes do sistema resultante. 
Conhecemos a notação UML para o Diagrama de Classes em suas diversas 
apresentações, além de compreendermos que o objetivo do diagrama de classes 
é mostrar a estrutura estática do sistema, modelado a partir do levantamento de 
requisitos representado no diagrama de caso de uso.
Herança múltipla dá-se quando uma subclasse herda atributos e operações 
de duas ou mais superclasses. Esse tipo de situação deve ser evitado. Apesar 
de a orientação a objetos prever essa situação, ela introduz possibilidades 
de difícil solução.
Fonte: Medeiros (2004, p. 80).
DIAGRAMA DE CLASSES
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIIU N I D A D E100
Familiarizamo-nos com o conceito e a sintaxe dos atributos e aprendemos 
que são esses elementos que definem a estrutura de uma classe, representando 
uma característica dos objetos instanciados.
Aprendemos que são os métodos que determinam o comportamento dos 
objetos de uma classe e são semelhantes às funções ou procedimentos da pro-
gramação estruturada.
Entendemos como ocorre a multiplicidade entre as associações de classes e 
que a multiplicidade especifica quantas instâncias de uma classe relacionam-se 
a uma única instância de uma classe associada.
Conhecemos os vários tipos de associação entre classes, entre elas, a asso-
ciação unária e binária, classes associativas, agregação regular e de composição, 
generalização e especialização. 
Compreendemos que Herança múltipla permite que uma classe possua mais 
de uma superclasse e herde características de todos os seus ancestrais.
Na próxima unidade, conheceremos os diagramas de sequência, comuni-
cação e estado. Esses diagramas permitirão que tenhamos uma nova visão do 
domínio de problema que resulta, na maioria das vezes, na alteração do dia-
grama de classes.
 
 
 
 
 
 
101 
1. Uma classe é o mesmo que um objeto? Explique.
2. O que é a herança?
3. O que é a herança múltipla e quais seus perigos?
4. Qual a diferença entre as visibilidades ‘pública’ e ‘protegida’?
5. Quando devemos utilizar a agregação de composição e a agregação regular?
6. O que é uma classe associativa?
MATERIAL COMPLEMENTAR
Engenharia de Software
Ian Sommerville
Editora: Makron Books
Sinopse: A engenharia de software é uma área relativamente 
nova, mas adquiriu rapidamente uma posição central entre as 
diferentes vertentes da engenharia. Englobando todos os aspectos 
da produção de software, ela é multidisciplinar e está em constante 
mudança.
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “AspectJ—Programação 
orientada a aspectos em Java”. Esse artigo apresenta um tutorial sobre AspectJ, uma extensão 
orientada a aspectos de Java. Programação orientada a aspectos (AOP) procura solucionar 
algumas inefi ciências da orientação a objetos, como o entrelaçamento e espalhamento de 
código com diferentes propósitos. O artigo encontra-se disponível em: <http://andremoraes-tcc.
googlecode.com/svn-history/r21/trunk/tcc/referencias/Soares_Borba_AspectJ.pdf>. Acesso em: 
29 jul. 2015.
103 
Prezado(a) aluno(a), segue uma matéria 
muito interessante que faz a demonstração 
de uma modelagem de dados orientada 
a objetos com agentes inteligentes, para 
o desenvolvimento e análise da informa-
ção de acordo com as necessidades dos 
usuários.
SISTEMA DE INFORMAÇÃO ORIENTADO A 
OBJETOS COM AGENTES INTELIGENTES
Marcelo Botelho da Costa Moraes; Marcelo 
Seido Nagano
O modelo apresentado é baseado na apli-
cação da tecnologia de agentes inteligentes 
aos sistemas de informação contábeis, 
buscando aperfeiçoar a maneira como os 
sistemas disponibilizam a informação aos 
usuários, proporcionando variações de for-
matação e detalhamento da informação.
Mesmo sendo o modelo REA o mais aceito 
para estruturar os fenômenos contábeis, 
este é eficiente no armazenamento dos 
dados, mas não no tratamento da infor-
mação (VERDAASDONK, 2003, p. 45). Dessa 
maneira, se torna necessário o desenvol-
vimento de um sistema destinado ao 
tratamento dos dados, gerando informação 
relevante, confiável e comparável, caracte-
rísticas estas que determinam a utilidade 
da informação contábil (FASB, 1980, p.7).
O desenvolvimento deste modelo é feito 
através da linguagem de banco de dados 
orientado a objetos. A utilização de mode-
lagem orientada a objetos foi introduzida 
no desenvolvimento de sistemas de infor-
mação contábeis por Knaus (2001), mas sua 
proposta utiliza como base o modelo DCA, 
sendo cada conta contábil como classe dis-
tinta (KNAUS, 2001, p. 78).
A modelagem de banco de dados orien-
tados a objeto surgiu das limitações dos 
bancos de dados relacionais, seu obje-
tivo básico é o gerenciamento de grandes 
volumes de informação, possuindo maior 
facilidade no tratamento de dados e aten-
dendo aos requisitos atuais de sistemas 
com outros tipos de bancos de dados, 
como o hipertexto, tão amplamente utili-
zado (SILBERSCHATZ; KORTH; SUDARSHAN, 
1999, p.249).
Dentro desta característica a linguagem 
UML (Unified Modeling Language) pode 
ser aplicada, principalmente por ser uma 
ferramenta apropriada para modelagem 
de agentes inteligentes (HEINZE, 2004, p. 
41) e baseada em bancos de dados orien-
tados a objetos. Esta abordagem se difere 
dos sistemas de informação contábeis tradi-
cionais por separar os dados das operações 
de modelagem da informação ao mesmo 
tempo em que utiliza uma abordagem 
orientada a objetos.
Visando um melhor desempenho da 
modelagem proposta, a forma de desenvol-
vimento por UML é utilizada para facilitar 
a visualização e a integração entre os dife-
rentes objetivos.
Nos sistemas tradicionais os relatórios são 
desenvolvidos no próprio banco de dados, 
enquanto neste modelo REA orientado a 
objetos (REAOO) os relatórios e suas análi-
ses são desenvolvidos através de agentes 
inteligentes, baseados em sistemas espe-
cialistas. A grande diferençase dá na 
separação da aplicação de contabilidade 
do banco de dados, o que não ocorre nor-
malmente.
Assim, para tal desenvolvimento, a utiliza-
ção da linguagem UML para a modelagem 
do sistema é de grande auxílio, é impor-
tante ressaltar que o modelo é uma 
simplificação da realidade, apresentando 
um caso geral de um sistema de informação 
para qualquer atividade que se deseje assu-
mir. Desse modo, enquanto a modelagem 
E-R no modelo REA assume 3 entidades 
(Recursos, Eventos e Agentes), para o 
desenvolvimento da modelagem orientada 
a objetos estes recursos, eventos e agen-
tes são as classes a serem implementadas.
Assim, com a utilização de Agentes Inte-
ligentes para o desenvolvimento da 
informação para os diferentes tipos de usu-
ário, o esquema externo (conforme modelo 
REA) pode ser desenvolvido por meio de 
Agentes Inteligentes, onde este agente será 
um novo ator neste diagrama.
Enquanto os agentes externos podem 
tomar parte nos eventos de transação 
como clientes e fornecedores, os agentes 
internos atuam na transação, são responsá-
veis pela intra-ação e alocação de recursos. 
Além disso, com a inserção de agentes inte-
ligentes no desenvolvimento e análises de 
relatórios.
Normalmente, existem muitos objetos simi-
lares em um banco de dados, ou seja, eles 
respondem às mesmas mensagens, usam 
os mesmos métodos e têm variáveis de 
mesmo nome e tipo. Dessa forma, o agru-
pamento desses objetos similares se dá por 
meio das classes (SILBERSCHATZ; KORTH; 
SUDARSHAN, 1999, p. 252).
Com isso, as entidades utilizadas no modelo 
REA podem ser consideradas como clas-
ses. Na modelagem orientada a objetos 
para banco de dados, uma classe pode pos-
suir hierarquia de especialização, ou seja, o 
relacionamento ISA, que indica uma classe 
como sendo especialização de outra (SIL-
BERSCHATZ; KORTH; SUDARSHAN, 1999, 
p. 253).
Assim, como na generalização do modelo 
REA, é possível determinar uma especiali-
zação para as classes de Recursos, Eventos 
e Agentes, conforme exemplo.
A partir da determinação das classes e 
suas especializações é possível compor o 
modelo geral do diagrama de classes den-
tro da proposta apresentada no modelo 
REA.
No modelo REA orientado a objetos 
(REAOO), um agente econômico, que pode 
ser interno ou externo, realiza um ou mais 
eventos econômicos e o próprio evento 
econômico gerado ocasiona a dualidade 
em relação aos recursos, proporcionando 
consumo (custo) e geração (benefício) de 
um ou mais recursos simultaneamente.
No caso geral da comercialização de um 
produto fabricado na própria entidade, um 
cliente (agente econômico externo) pode 
adquirir um ou mais produtos com um 
vendedor (agente econômico interno), oca-
sionando um evento econômico (venda) 
que terá impacto nos recursos econômi-
cos, seja sob a forma de custo de uma ou 
mais unidades, seja na forma de benefício 
com o recebimento financeiro ou direito 
de recebimento futuro.
105 
Este modelo, assim como o formato ori-
ginal do modelo REA, pode ser aplicado 
a qualquer situação dentro dos diversos 
tipos de organizações que realizem ativi-
dades econômicas.
A atuação do agente inteligente se dá de 
maneira autônoma, ou seja, o agente inte-
ligente é um software separado do banco 
de dados, que o acessa remotamente e, atu-
ando por meio de buscas, obtém os dados 
desejados que sejam necessários para sua 
atividade de desenvolvimento e/ou aná-
lise da informação.
Confira o texto completo disponível em: <http://www.scielo.br/scielo.php?script=sci_art-
text&pid=S1807-17752009000300005&lng=pt&nrm=iso>.
Fonte: Moraes e Nagano (2009, online).
U
N
ID
A
D
E IV
Prof. Me. Déverson Rogério Rando
DIAGRAMAS DE 
SEQUÊNCIA, ESTADO E 
COLABORAÇÃO
Objetivos de Aprendizagem
 ■ Avançar no conhecimento de diagramas UML.
 ■ Aprender sobre o Diagrama de Sequência.
 ■ Aprender sobre o Diagrama de Estados.
 ■ Aprender sobre o Diagrama de Comunicação.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Avançando nos diagramas
 ■ Diagrama de Sequência
 ■ Diagrama de Estados
 ■ Diagrama de Comunicação
INTRODUÇÃO
Caro(a) aluno(a), iniciamos a quarta unidade do livro Análise e Projeto Orientado 
a Objetos mostrando mais alguns diagramas importantíssimos que complemen-
tam e refinam o diagrama de casos de uso e de classes.
Aprenderemos a notação e como utilizar o diagrama de sequência, veremos 
que a utilidade desse diagrama é a de se estudar as interações entre os objetos. 
O diagrama de sequência tem o propósito de refinar o diagrama de classes, uma 
vez que possibilita a identificação de relação entre as classes.
Conheceremos com detalhes o diagrama de estado, esse diagrama tem como 
objetivo especificar o comportamento das classes por meio da utilização de 
máquinas de estado. Veremos que as classes com necessidade da representação 
por esse diagrama são somente as que possuem um número quantificável de 
estados, portanto, não são todas as classes que terão a necessidade de ter o com-
portamento modelado por esse diagrama.
Por fim, aprenderemos o diagrama de comunicação, conhecido também 
como diagrama de colaboração (UML 1.5). Veremos que esse diagrama nos dá 
outra forma de representar o cenário. Aprenderemos que, apesar de conter as 
mesmas informações que o diagrama de sequência, o diagrama de comunica-
ção representa a ordem com que ocorre a comunicação, e não o tempo, como 
ocorre no diagrama de sequência.
Dessa forma, será possível perceber que a colaboração entre as classes ocorre 
por meio das trocas de mensagem. Quando desejarmos verificar essa troca, consi-
derando o tempo com que elas acontecem, utilizaremos o diagrama de sequência, 
porém, se o objetivo é verificar essas trocas de mensagens de acordo com sua 
ordem, utilizaremos o diagrama de colaboração.
Concluiremos nossos estudos sobre análise e projeto OO na próxima uni-
dade, em que teremos a oportunidade de modelar um sistema OO. 
Então, o que estamos esperando? Vamos ao trabalho! Boa leitura para você.
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
.
109
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E110
AVANÇANDO NOS DIAGRAMAS
Agora que já conhecemos o objetivo e a notação dos diagramas de caso de uso 
e de classes, vamos avançar um pouco conhecendo mais três diagramas, essen-
ciais na análise e projeto OO, que utilizaremos para refinar o diagrama de classes 
que representa a estrutura do sistema.
Já verificamos que a documentação do software, na maioria das vezes, não 
tem a devida atenção da equipe de desenvolvimento, ou por não querer, ou por 
falta de tempo, ou mesmo por achar que é uma perda de tempo elaborar inú-
meros diagramas. 
Porém bons softwares tem documentação que nos permite contar e entender 
a história do software. Uma análise criteriosa e um projeto bem fundamentado 
na análise são aspectos que definem o sucesso e o tempo de vida de um software.
É fato que manter uma documentação atualizada demanda um esforço, 
porém o esforço será maior no momento da manutenção, quando nos depara-
mos com um software sem documentação, a experiência vai ensinar isso a você 
muito mais do que poderia estar escrito em qualquer livro.
Dada a importância de se adotar um método – para relembrar: o método 
pressupõe a utilização de uma linguagem (notação) e um modelo de processo 
- a relevância na construção e manutenção da documentação é imensurável.
Vimos na unidade II que o diagrama de Caso de Uso é utilizado na aná-
lise de requisitos e acompanhará o softwaredesde o seu início até a conclusão.
No diagrama de Caso de Uso, surge a figura do ator, que pode ser uma pes-
soa, um sistema, um roteador. O ator é quem realiza as atividades e sempre atua 
sobre um caso de uso. Portanto, o diagrama de caso de uso modela o compor-
tamento dos atores no sistema.
Olhando para o diagrama de caso de uso da Figura 68, fica claro que o aluno 
realiza empréstimos, consultas e devoluções, enquanto a bibliotecária é quem 
cria o livro, o aluno e os empréstimos no sistema.
Aluno
Realiza
consulta
Realiza
empréstimo
Realiza
devolução
Cria
aluno
Cria
livro
Efetua
empréstimo
Bibliotecária
Figura 68: Diagrama de Caso de Uso
Fonte: o autor.
Avançando nos Diagramas
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
.
111
Porém o diagrama de casos de uso nos fornece apenas um panorama visual das 
funcionalidades do sistema, é necessário um detalhamento por meio de uma 
descrição textual, mas não há descrição padrão definida pela UML, em geral, o 
diagrama é bastante informal. 
Ficou claro então que o diagrama por si só não é suficiente. Os casos de uso 
devem vir acompanhados de uma descrição. Após a elaboração do diagrama 
de caso de uso e sua descrição, teremos conhecimento suficiente a respeito do 
domínio para modelar a primeira versão do diagrama de Classes que nos mos-
trará a estrutura estática do sistema.
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E112
DIAGRAMA DE SEQUÊNCIA
O diagrama de sequência é o próximo diagrama que conheceremos a notação, 
sua utilidade é estudar as interações entre os objetos, possibilitando a identifi-
cação de relação entre as classes, servindo para refinar o diagrama de classes.
O cenário da figura 60 mostra a solicitação de um empréstimo pelo aluno, 
a partir dessa ação, é desencadeado um conjunto de mensagens 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 exemplar solicitado, realizando 
o empréstimo.
Observamos que a partir das informações fornecidas pelo diagrama de 
sequência é possível identificar os métodos associados às classes, além da iden-
tificação das relações entre as classes.
É a classe que nos fornecerá a estrutura para modelar um conjunto de ob-
jetos com características similares. A classe contém métodos e atributos. Os 
métodos são responsáveis por modelar o comportamento dos objetos da 
classe e os atributos modelam os possíveis estados do objeto.
Fonte: o autor.
1: Solicita
Empréstimo()
Empréstimo ExemplarÍtem_EmpréstimoAluno
2: Veri�ca se
existe()
3: Cria Ítens()
5: Cria Ítens ()
2.1: Veri�cação
OK()
6: Cria Ítens()
4: Veri�ca se existe()
4.1: Veri�cação OK()
7: Cria empréstimo()
Pessoa
Figura 69: Diagrama de Sequência
Fonte: o autor.
Diagrama de Sequência
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
.
113
Muito bem, mas como posso interpretar esse diagrama? A resposta é conhe-
cendo sua notação. Vamos lá!
NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA
O diagrama de sequência da figura 70 tem todos os elementos da notação des-
tacados por uma elipse vermelha, em que é possível observar as mensagens 
(síncronas, assíncronas, reflexiva), linha do tempo, tempo de atividade e obje-
tos. Vamos conhecê-los em detalhes.
1: Mensagem
Sincrona() 1.1: Mensagem
Sincrona()
3: MensagemSincrona()
3.1: Mensagem
Sincrona()
2: MensagemAssincrona()
Mensagem
de retorno
4: AutoMensagem()
: AtorPrimário : ObjetoDeControle : ObjetoDeEntidade : AtorSecundario: ObjetoDeFronteira
Figura 70: Modelo de Diagrama de Sequência
Fonte: o autor.
Figura 71: Timeline (linha de vida ou tempo)
Fonte: o autor.
Linha do Tempo
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E114
TIMELINE
As timelines ou linhas de vidas fazem parte da dimensão vertical do diagrama. 
A linha de vida é composta de duas partes: a cabeça e a cauda. A cabeça é repre-
sentada por um retângulo, no qual é exibida a identificação do objeto, a cauda 
corresponde a uma linha vertical tracejada.
Pessoa Compra
1: Sincrona()
2: Assincrona()
Figura 72: Mensagens síncrona e assíncrona
Fonte: o autor.
Diagrama de Sequência
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
.
115
MENSAGENS
Uma Mensagem é representada por uma seta horizontal, do emissor para o 
receptor, com o nome e possíveis argumentos, ligando uma linha de vida a outra. 
O objeto do qual parte a seta é aquele que está enviando a mensagem (objeto 
remetente). O objeto para o qual a seta aponta é aquele que está recebendo a 
mensagem (objeto receptor). 
O formato da ponta da seta indica o tipo de mensagem sendo enviada, que 
pode ser síncrona ou assíncrona. O rótulo da mensagem é posicionado acima 
dessa seta.
Como podemos verificar na figura 72, uma Mensagem é representada por uma 
seta horizontal, do emissor para o receptor, com o nome e possíveis argumentos.
As mensagens são síncronas, quando quem envia (emissor) fica no aguardo 
da resposta pelo receptor, e são representadas por uma seta com a ponta preen-
chida. O retorno de Mensagem Síncrona é representado por uma linha tracejada.
As mensagens são assíncronas, quando quem envia (emissor) a mensagem 
NÃO fica no aguardo da resposta pelo receptor, e são representadas por uma seta 
com a ponta vazada. Não tem notação de retorno para essa mensagem.
As mensagens também podem ser reflexivas, de autodelegação ou, ainda, 
automensagem, nesse caso, são representadas por uma seta que retorna para a 
mesma linha do tempo de partida. Como apresentado na figura 73:
Lifeline1
1: Auto Mensagem()
Figura 73: Auto mensagem síncrona
Fonte: o autor.
Figura 74: Tempo de atividade
Fonte: o autor.
Lifeline1
1: Mensagem()
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E116
TEMPO DE ATIVIDADE
Os objetos também apresentam um tempo de atividade na linha do tempo, essa 
atividade corresponde ao tempo durante o qual um objeto exerce sua ação, direta 
ou indiretamente, por meio de um objeto que lhe presta o serviço.
A notação é um retângulo na linha do tempo em que as bordas representam 
o período de atividade, como podemos observar na figura 74:
EXEMPLO
Já conhecemos a notação do diagrama de sequência, agora vamos praticar um 
pouco. Para facilitar o entendimento da notação, vamos utilizar um exemplo da uni-
dade II, que apresento um caso de uso para a resolução de expressões aritméticas. 
Lembrando que o diagrama de casos de uso é apenas um panorama visual 
das funcionalidades do sistema, é necessária uma descrição textual para deta-
lhar os casos de uso. 
Na figura 75, é apresentado um diagrama de casos de uso que mostra o ator 
“Operador” interagindo com o caso de uso “Cadastrar Pessoas”.
Operador
Cadastrar Pessoas
Figura 75: Caso de Uso
Fonte: o autor.
Quadro 02: Descrição textual para o caso de uso
Fonte: o autor.
Diagrama de Sequência
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
10d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
117
O quadro 2 mostra a descrição textual para o caso de uso “Cadastrar Pessoas”:
NOME DO CASO DE USO CADASTRAR PESSOAS
Descrição Permite inserir novos dados cadastrais de pessoas no 
sistema.
Ator Operação
Pré-condições O sistema deve estar em execução
Pós-condições Dados gravados ou cancelamento da operação pelo Ope-
rador.
Fluxo Básico
Usuário Sistema
{Solicita Dados}
Solicita os dados do cliente. (A2)
Fornece os dados
{Valida os dados}
Verifica se os dados obedecem às regras de entrada (A1)
{Grava os dados}
{Fim}
Fim do caso de uso
Fluxos alternativos
A1: em {Valida expressão} Se o usuário fornecer entradas que não obedecem as 
regras de entrada (máscara de entrada, intervalo, datas...
etc.), informá-lo sobre 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 forne-
cer os dados. Nesse caso, retornar ao fluxo básico em {Fim}
Usuário
Sistema CalculadoraInterfaceUsuário
Figura 76: Linhas do tempo para calculadora
Fonte: o autor.
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E118
Essa descrição textual detalha o caso de uso, mostrando as prés e pós-condi-
ções para execução, bem como o fluxo básico de execução, que significa dizer 
que o sistema solicitará a entrada de dados ao operador que poderá cancelar, se 
desejar, sendo desviado o fluxo de execução para o fluxo alternativo A2, porém, 
caso não cancele, o sistema validará a entrada de dados fornecida pelo operador, 
desviando para o fluxo alternativo A1, que tem como objetivo validar a entrada 
de dados, verificando as máscaras de entrada, intervalo de valores, entre outras 
regras. Se passar pela validação, o sistema gravará os dados na base de dados.
Um fluxo descreve como o sistema e os atores colaboram para produzir algo 
de valor aos atores e o que pode impedir sua obtenção. Um fluxo descreve um 
caminho entre muitos possíveis, visto que um caso de uso pode ser executado de 
vários modos. Existem fluxos básicos, que demonstram o fluxo normal de eventos, 
e alternativos, que dizem o que fazer caso não seja possível seguir o fluxo básico. 
No caso de uso “Resolver expressões aritméticas”, o usuário pode tanto for-
necer a expressão para o cálculo (fluxo básico) quanto cancelar a operação, 
desviando o fluxo alternativo A2, porém, caso o usuário siga no fluxo básico, 
após o fornecimento da expressão para cálculo, o fluxo será desviado para um 
caminho alternativo A1 que valida a entrada.
Para ficar mais fácil o entendimento da sequência dos fluxos de mensagens, 
construiremos o diagrama de sequência para esse caso de uso.
Primeiramente, vamos definir as linhas do tempo, teremos uma para o usuá-
rio, outra para a interface do usuário com o sistema, outra para o controle do 
sistema e a última para a calculadora, como mostrado na figura a seguir.
1.1: Expressão? ( )
{Exp}
1: SolicitarExpressao ( )
Usuário
Sistema CalculadoraInterfaceUsuário
{Exp}
Figura 77: Diagrama de Sequência com troca de mensagens entre usuário e sistema.
Fonte: o autor.
2: Calcular(exp) ( ) 2.1: Validar ( )
2.2: Calcular(exp) ( )
1.1: Expressão? ( )
{Exp}
1: SolicitarExpressao ( )
Usuário
Sistema CalculadoraInterfaceUsuário
3.1: Resultado ( ) 3: MostraResultado ( ) <<Resultado>>
{Exp}
Figura 78: Diagrama de sequência para Resolver expressões aritméticas
Fonte: o autor.
Diagrama de Sequência
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
.
119
Em seguida, o sistema irá solicitar a expressão para o Usuário, enviando uma 
mensagem síncrona para a interface Usuário que deverá aguardar a resposta do 
Usuário para a continuação, conforme a figura:
Após o recebimento da expressão, o sistema enviará uma mensagem síncrona 
para a calculadora, que validará a entrada e calculará se ela for válida, em seguida, 
mostrará o resultado na interface com o usuário.
Figura 79: Estado Inicial 
Fonte: o autor.
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E120
DIAGRAMA DE ESTADOS
Veremos o diagrama de estados, que tem como objetivo especificar o compor-
tamento das classes mais complexas utilizando máquinas de estado.
Somente as classes que possuem um número finito de estados conhecidos 
têm a necessidade de uma representação por um diagrama de estado. É possí-
vel prever os possíveis comportamentos de um objeto por meio da análise da 
mudança de estados dos tipos de objetos de um sistema.
Dessa forma, o diagrama de estado representa o comportamento interno da 
classe, permitindo a especificação da sua dinâmica. Uma especificação corres-
ponde a como deve ser implementada uma classe.
ESTADO
O estado representa a situação ou momento no tempo de vida de um objeto, 
o objeto pode passar por vários momentos ao longo de sua vida, por exemplo:
 ■ Momento de criação.
 ■ Momento de inicialização.
 ■ Momento que realizou alguma solicitação.
 ■ Momento que é destruído.
Todos os objetos possuem um estado que, normalmente, é determinado pelos 
valores de seus atributos, que é o resultado de atividades executadas pelo objeto. 
A NOTAÇÃO PARA ESTADOS 
A notação para o estado inicial é um círculo preenchido, como mostra a figura 
a seguir:
State0
StateName
entry / action
do / action
exit / action
Figura 80: Estado final 
Fonte: o autor.
Figura 81: Estado simples
Fonte: o autor.
Figura 82: Estado
Fonte: o autor.
Diagrama De Estados
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
.
121
A notação para o estado final é um círculo preenchido com borda, como mos-
tra a figura a seguir:
Um retângulo com os cantos arredondados representa um estado simples que 
é o estado mais comum, somente um valor de um atributo de uma classe pode 
ser representado por esse estado.
O estado simples também pode ser representado por um retângulo com dois 
compartimentos, no primeiro compartimento, é informado o nome para o estado 
e, no segundo compartimento, as ações.
O Estado também pode ser composto, nesse caso, um retângulo maior identifica 
o estado composto, o que significa dizer que dentro dele terão outros estados.
Estado Composto
Estado Estado
Figura 76: Linhas do tempo para calculadora
Fonte: o autor.
Figura 84: Estado de escolha
Fonte: o autor.
Disponível Emprestado
Reservado
Manutenção
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E122
O diagrama pode representar, também, um estado de escolha com um losango 
simples e vazado. O que significa dizer que o programa deve decidir e ir para 
um dos estados possíveis a partir do estado de escolha.
A junção é o contrário do estado de escolha, ou seja, vários estados podem che-
gar a um único estado. Nesse caso, a representação é feita por meio de um círculo 
preenchido.
Estado 1 Estado 3
Estado 2
Estado 4
Estado 1
Estado 3Estado 2 Estado 4
Figura 86: Estado fork
Fonte: o autor.
Figura 85: Estado de junção
Fonte: o autor.
Diagrama De Estados
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
 de 
19
98
.
123
O fork, representado por um retângulo preenchido, indica estados concorrentes. 
Quando um estado chega ao fork, desencadeia um ou mais estados concorrentes.
O join (junção) é representado também por um retângulo preenchido, porém, 
ao contrário do fork, representa todos os estados chegando em um.
Estado 1 Estado 2
Estado 3
Figura 87: Estado de join (junção)
Fonte: o autor.
Figura 88: Ações do Estado
Fonte: o autor.
Estado 1
entry / funcaoX
Estado 2
exit / funcaoYfuncaoZ( ) (Z>1)
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E124
E, por último, as ações, elas ocorrem em três eventos: quando entra (entry), sai 
(exit) ou está (do) em um estado.
De acordo com o diagrama de estados apresentado na figura 83, a funcaoX será 
executada no momento em que entrar no Estado1. Na transição do Estado1 para 
o Estado2, será executa a funcaoZ somente se o Z for maior que 1. Por fim, na 
saída do Estado2, será executada a funcaoY. 
A ação “do” é executada durante todo o tempo de permanência no estado 
que disparou a função. 
O diagrama de estado da figura 80 mostra que, quando um exemplar tiver 
DISPONÍVEL para empréstimo, será executada a função atualiza() enquanto o 
objeto permanecer nesse estado. Na transição para o estado EMPRESTADO, é 
executada a função empresta (exemplar_id), passando como parâmetro o exem-
plar_id. Na transição de EMPRESTADO para disponível, é executada a função 
libera (exemplar_id). Por fim, na transição de DISPONÍVEL para ENCERRADO, 
é executada a função encerra_id (exemplar_id).
en
ce
rr
a(
ex
em
pl
ar
_i
d
libera(exemplar_id)
empresta(exemplar_id)
DISPONÍVEL
do / atualiza( )
ENCERRADO
do / atualiza( )
EMPRESTADO
do / atualiza( )
Figura 89: Diagrama de Estado
Fonte: o autor.
Diagrama de Comunicaçã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
.
125
DIAGRAMA DE COMUNICAÇÃO 
Vamos para o último diagrama, conhecido como diagrama de colaboração até a 
versão 1.5 da UML, teve sua denominação modificada para diagrama de comu-
nicação na versão 2.0 da UML.
O diagrama de comunicação é outra forma de representar o cenário, esse 
diagrama 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.
O diagrama de comunicação identifica as classes mais próximas e a ordem 
de envio de mensagens que é identificada por números sequenciais, mostrando 
a interação de forma organizada em torno dos objetos.
As classes colaboram entre si trocando mensagens, se o objetivo é verificar 
o envio de mensagens no decorrer do tempo, devemos utilizar o diagrama de 
sequência, porém, se quisermos verificar a troca de mensagens no contexto do 
sistema, utilizamos o diagrama de comunicação.
O diagrama de comunicação é composto, basicamente, por 4 elementos:
:Ator
Figura 90: Ator 
Fonte: o autor.
Figura 91: Instância identificada
Fonte: o autor.
umaPessoa : Pessoa
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E126
 ■ Ator.
 ■ Objetos.
 ■ Vínculos.
 ■ Mensagens.
NOTAÇÃO PARA O DIAGRAMA DE COMUNICAÇÃO
Ator
O ator tem a mesma representação dos demais diagramas, ou seja, o homem 
palito, com seu rótulo precedido de dois pontos.
Objeto
O objeto é representado por um retângulo, em que, em seu interior, é infor-
mado o objeto e o nome da classe a qual aquele objeto pertence, separados por 
dois pontos, que definimos como instância identificada.
StateName
entry / action
do / action
exit / action
: umaPessoa
Figura 94: Vínculo
Fonte: o autor.
Figura 92: Classe
Fonte: o autor.
Diagrama de Comunicaçã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
.
127
: umaPessoa
Figura 93: Instância
Fonte: o autor.
O objeto também pode ser representado somente com a identificação da classe 
em seu rótulo.
Ainda, o objeto pode ser representado somente com a identificação da instância 
da classe em seu rótulo, nesse caso, o rótulo deve vir precedido por dois pontos.
VÍNCULO
O vínculo é a ligação entre dois objetos, que identifica o envio e recebimento 
de mensagens.
MENSAGENS
As mensagens enviadas e recebidas são representadas por setas que apontam suas 
direções, a descrição da mensagem vem acompanhada do seu número de ordem.
: umPaciente
1: Consulta ( )
2: fazDiagnóstico ( )
3: aplicaMedicação ( )
4: Sara ( ): Médico
Figura 95: Troca de Mensagens
Fonte: o autor.
Figura 96: Diagrama de Comunicação 
Fonte: o autor.
Empréstimo
Exemplar
Ítem Empréstimo
GUI Bibliotecária Aluno
1: Cria ( ) 2: Valida ( )
3: Valida ( )
4: Valida ( )
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E128
EXEMPLO
O diagrama de comunicação da figura 96 exemplifica a troca de mensagens entre 
os objetos. Podemos verificar que o objeto GUI Bibliotecária envia uma men-
sagem para criar (1) um novo empréstimo. O objeto empréstimo, por sua vez, 
envia uma mensagem para validar (2) o aluno, ou seja, verificar se aquele aluno 
realmente existe. 
Após a validação do aluno, o objeto empréstimo envia uma mensagem para 
item empréstimo validar (3) o exemplar que está sendo emprestado, porém, para 
item empréstimo validar (4) o exemplar é necessário enviar uma mensagem de 
validação para o objeto exemplar.
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
.
129
CONSIDERAÇÕES FINAIS
Nesta unidade, aprendemos mais três diagramas importantes para análise e pro-
jeto orientado a objetos, são eles: os diagramas de sequência, colaboração e estado.
Familiarizamo-nos com a notação e com como utilizar o diagrama de sequên-
cia, vimos como ele pode nos auxiliar no estudo das interações entre os objetos, 
bem como fornecer subsídios para o refinamento da identificação da relação 
entre as classes.
Estudamos as principais características do diagrama de estados, vimos que 
o comportamento de uma classe pode ser modelado por meio desse diagrama. 
Porém, não são todas as classes que necessitam dessa representação, pois não 
apresentam um número de estados que se possa quantificar. 
Por fim, estudamos outra forma de representação do cenário em que o sis-
tema irá funcionar, representando toda a ordem de comunicação entre classes 
por meio do diagrama de colaboração. Aprendemos que, diferentemente do dia-
grama de sequência, o diagrama de colaboração não se importa com o tempo 
em que as mensagens ocorrem e sim com sua ordem de ocorrência.
Na verdade, a análise e o projeto de um software são extremamente depen-
dentes da habilidade do analista em articular todos os elementos do sistema. Essa 
articulação se faz necessária uma vez que o software não se resume a um arquivo 
executável. O software é dependente do hardware, que executará o sistema, bem 
como dos usuários, que interagirão com ele, e da cultura da organização.
Se o diagrama de sequência já cria o cenário que mostra a troca de mensa-
gens entre os objetos, qual a necessidade de elaborar, também, diagrama 
de comunicação? 
Fonte: o autor.
DIAGRAMAS DE SEQUÊNCIA, ESTADO E COLABORAÇÃOReprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IVU N I D A D E130
É difícil, em um primeiro momento, saber por onde começar o levantamento 
de requisitos ou qual diagrama elaborar primeiro, porém a prática nos ensina 
atalhos e o tempo tratará de refinar sua arte.
Então, programar é uma arte? Sim, considero dessa forma, porque o software 
é uma produção intelectual, ou seja, é uma obra do espírito, assim como aquele 
bom livro que lemos, aquele excelente filme que assistimos ou, ainda, aquela 
escultura que apreciamos seus contornos. A diferença é que nem sempre pro-
duzimos aquilo que gostaríamos, mas sim aquilo para o qual fomos contratados, 
por isso, há necessidade de apresentar habilidades que permitam agregar pessoas.
 
 
 
 
 
 
131 
1. Qual o objetivo do diagrama de sequência e quais são os principais elementos 
de sua notação.
2. Quais classes são candidatas para a elaboração de um diagrama de estado? Ex-
plique.
3. Sabemos que o diagrama de comunicação é outra forma de modelar o cenário 
do software, quando devemos utilizá-lo?
4. Qual a diferença entre os diagramas de sequência e comunicação?
MATERIAL COMPLEMENTAR
UML e C++: Guia Prático de Desenvolvimento 
Orientado a Objetos
Richard C. Lee; William M. Tepfenhart
Editora: Makron Books
Sinopse: Este livro prático é um guia autoexplicativo para 
analistas e desenvolvedores de software. Ele ensina como, 
realmente, praticar modelagem orientada a objeto usando a 
notação da UML e implementar o modelo com C++. Os autores 
apresentam todos os conceitos básicos da tecnologia orientada 
a objeto necessários para que os leitores possam entender e 
aplicar o paradigma orientado a objeto. 
Da mesma forma que é impossível construir uma casa sem, primeiramente, defi nir sua planta, 
também é impossível construir um software sem, inicialmente, defi nir sua arquitetura.
Leia mais sobre o assunto no link disponível em: <http://www.dsc.ufcg.edu.br/~jacques/cursos/
map/html/uml/motivacao/motivacao1.htm>. Acesso em: 30 jul. 2015.
133 
Prezado(a) aluno(a), segue uma matéria 
muito interessante sobre UP, que é um 
processo unificado estabelecido para o 
desenvolvimento de software resultado 
de três décadas de desenvolvimento e de 
uso prático.
ENGENHARIA DE REQUISITOS E O UP
Delmir Peixoto de Azevedo Junior; 
Renato de Campos
A engenharia de software se produz atra-
vés de um conjunto de fases. Cada uma 
das fases pode envolver métodos, ferra-
mentas e procedimentos, cujas formas de 
estruturação são citadas como modelo 
de engenharia de software (PRESSMAN, 
2002). Ainda segundo Pressman (2002), 
independentemente do modelo de desen-
volvimento de software, o processo contém 
três fases genéricas: definição, desenvolvi-
mento e manutenção.
Quatro modelos de engenharia de software 
têm sido amplamente discutidos: o ciclo de 
vida clássico (ou cascata), a prototipação, 
o modelo espiral e as técnicas de Quarta 
Geração (PRESSMAN, 2002). Atualmente 
um novo modelo tem sido bastante usado: 
o modelo iterativo e incremental (JACOB-
SON; BOOCH; RUMBAUGH, 1999; PAULA 
FILHO, 2001).
A análise de requisitos é uma etapa pre-
sente na fase de definição do software, 
independentemente do modelo de enge-
nharia de software adotado. Paula Filho 
(2001) afirma que a engenharia de requi-
sitos é formada por um conjunto de 
técnicas empregadas para levantar, deta-
lhar, documentar e validar os requisitos de 
um produto de software. Assim, é possível 
definir a engenharia de requisitos como 
um campo da engenharia de software que 
visa a aplicação de técnicas de engenha-
ria em métodos de análise de requisitos, 
que efetua a ligação entre a necessidade de 
informatização de processos e o projeto do 
software que atenderá a tais necessidades.
No decorrer das duas últimas décadas, uma 
série de métodos de análise e especificação 
de requisitos foi desenvolvida, sendo pou-
cas as propostas que visam a sistematização 
da definição de requisitos de forma menos 
subjetiva (SANTANDER, 2002).
O UP (Processo Unificado) é um processo 
estabelecido para o desenvolvimento 
de software resultado de três décadas de 
desenvolvimento e de uso prático. Jacob-
son, Booch e Rumbaugh (1999) apresentam 
as origens do UP no processo Objectory, 
que teve sua primeira versão apresentada 
em 1987, passando pelas contribuições 
do Processo Rational Objectory (1997), até 
chegar ao Processo Unificado da Rational – 
RUP (KRUCHTEN, 2003). O propósito do UP, 
como qualquer outro processo de desen-
volvimento, é determinar um conjunto de 
atividades necessárias para transformar 
requisitos em sistemas de software. Neste 
caso, utiliza a UML como linguagem para 
a modelagem dos artefatos de software 
produzidos ao longo do processo de desen-
volvimento. O UP é fundamentado em três 
boas práticas: dirigido por caso de uso, cen-
trado em arquitetura, iterativo e incremental. 
Os casos de uso definidos para um sistema 
são a base de todo o processo de desen-
volvimento. A partir de uma perspectiva de 
gerenciamento, o ciclo de vida de software 
do UP é dividido em quatro fases seqüen-
ciais (Concepção, Elaboração, Construção 
e Transição), sendo que cada fase refere-se 
a uma determinada meta a ser atingida ao 
longo do desenvolvimento.
Cada uma das quatro fases do UP é adicio-
nalmente dividida em iterações e finalizada 
com um ponto de checagem que verifica se 
os objetivos daquela fase foram alcançados. 
Toda iteração é organizada em termos de 
workflows de processo, que são conjuntos 
de atividades realizadas pelos responsáveis 
pela produção dos artefatos. Os principais 
workflows de processo do UP são Levan-
tamento de Requisitos, Análise, Projeto, 
Implementação, Teste e Implantação, sendo 
que o RUP se diferencia, principalmente, 
em relação ao workflow de Modelagem 
de Negócio.
A UML foi adotada pela OMG (Object 
Management Group) em 1997 como lin-
guagem padrão para a modelagem de 
sistemas orientados a objeto. É uma lin-
guagem para especificação, visualização, 
construção e documentação de artefatos 
de sistemas de software, como também 
para a modelagem de negócios e outros 
sistemas não necessariamente relaciona-
dos a software, e representa uma coleção 
das melhores práticas de engenharia que 
comprovaram bom êxito na modelagem 
de sistemas grandes e complexos (OMG, 
1997). Os principais diagramas da UML são: 
Diagrama de Classes, Diagrama de Obje-
tos, Diagrama de Casos de Uso, Diagrama 
de Seqüência, Diagrama de Colaborações, 
Diagrama de Gráficos de Estados, Diagrama 
de Atividades, Diagrama de Componentes, 
Diagrama de Implantação.
A UML também permite a ampliação da 
linguagem de maneira controlada, atra-
vés de mecanismos de extensão, de forma 
a expressar todas as nuances possíveis de 
todos os modelos em qualquer domínio 
de análise (exemplo: análise de negócios), 
fornecendo alguma flexibilidade.
Leia mais: http://www.scielo.br/scielo.php?script=sci_arttext&pi-
d=S0103-65132008000100003&lang=pt
U
N
ID
A
D
E V
Professor Me. Déverson Rogério Rando
ESTUDO DE CASO
Objetivos de Aprendizagem
 ■ Conhecer uma ferramenta case para modelagem OO.
 ■ Fazer a análise e projeto a partir de um estudo de caso.
 ■ Elaborar um diagrama de caso de uso.
 ■ Elaborar um diagrama de classes.
 ■ Elaborar um diagrama de sequência.
 ■ Elaborar um diagrama de estado.
 ■ Elaborar um diagrama de colaboração.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Ferramentas Case
 ■ Estudo de caso
 ■ Diagrama de caso de uso
 ■ Diagrama de classes
 ■ Diagrama de sequência
 ■ Diagrama de estado
 ■ Diagrama de comunicação
INTRODUÇÃO
Caro(a) aluno(a), chegamos a quinta e última unidade do livro Análise e ProjetoOrientado a Objetos fazendo a análise e o projeto orientado a objetos para um 
estudo de caso que será apresentado.
O objetivo dessa unidade é que você desenvolva junto comigo a análise e o 
projeto de um software, porém, para não precisarmos desenhar os diagramas à 
mão, vamos utilizar um software para nos auxiliar. Esse software é denominado 
ferramenta CASE.
Existem muitas ferramentas CASE no mercado, como todo produto de software, 
existem os softwares proprietários, que necessitam uma licença de uso, e os softwares 
livres, que não necessitam de uma licença de uso. Vamos optar aqui por uma ferra-
menta que seja livre e que atenda as nossas necessidades.
Apresentarei a vocês um estudo de caso em que teremos a oportunidade de 
modelar um software orientado a objetos, utilizando uma ferramenta CASE que 
nos auxiliará na construção dos diagramas.
Construiremos, primeiramente, o diagrama de caso de uso para criarmos o 
cenário para o software, definindo quais serão os atores e seus respectivos casos 
de uso. Faremos, também, a especificação para os casos de uso.
Em seguida, a partir das informações coletadas na construção do diagrama 
de caso de uso, poderemos, então, elaborar o diagrama de classes, que repre-
senta a estrutura estática do sistema. Esse diagrama sofrerá vários refinamentos 
até sua versão final.
O diagrama que construiremos em seguida é o de sequência, que nos mostrará 
como e quando ocorrem as trocas de mensagens entre os objetos. A elaboração 
desse diagrama, invariavelmente, provoca um refinamento do diagrama de classes.
Logo após, construiremos o diagrama de colaboração, em uma tentativa de 
representar o cenário de forma semelhante ao diagrama de sequência.
Por fim, construiremos o diagrama de estado, que mostrará o comporta-
mento da classe por meio de máquinas 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
.
137
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E138
FERRAMENTAS CASE
Modelar um sistema na mão ou com softwares que não foram construídos para 
tal pode ser um barato que sai caro. O ideal é adotarmos uma ferramenta CASE.
Uma ferramenta CASE (Computer-Aided Software Engineering), em uma 
tradução livre “engenharia de software auxiliada por computador”, é uma clas-
sificação de software que abrange aquelas ferramentas computacionais que têm 
como objetivo auxiliar a atividade de engenharia de software.
Todas as imagens de diagramas que adicionei foram feitas com a ferramenta 
CASE produzida pela empresa Astah, no material complementar tem o link para 
o download dessa ferramenta que é gratuita.
Muito bem, para nossa análise e projeto orientado a objetos, adotaremos ferra-
menta CASE Astah Community, por oferecer suporte para o modelo de linguagem 
que utilizaremos, ou seja, a UML.
O modelo de processo de desenvolvimento que adotaremos será o cascata, por 
ser um processo clássico e ter as fases bem definidas. As fases para esse modelo 
são: análise, projeto, implementação, teste, integração, implantação, manutenção.
No estudo de caso que desenvolveremos, cobriremos duas fases do modelo 
em cascata, que é a análise e o projeto.
É imprescindível que, ao adotar uma ferramenta CASE, também adotemos 
um processo de desenvolvimento de software. Lembra-se de que falamos 
que um método pressupõe a existência de um processo e um modelo de 
linguagem?
Fonte: o autor.
Estudo De Caso
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
.
139
Penso que não é possível utilizar um modelo de processo sem ferramentas 
CASE que o suportem. Invariavelmente, ocorre que na primeira manutenção a 
documentação fica desatualizada, já discutimos que documentação desatualizada 
não serve para muita coisa. Porém, com a utilização de uma ferramenta CASE 
adequada, fica fácil atualizar a documentação a cada manutenção.
ESTUDO DE CASO
Apresentarei, agora, um estudo de caso que utilizaremos para a nossa análise e 
projeto orientado a objetos.
O sistema é simples e de fácil entendimento, o objetivo é que façamos a 
construção dos diagramas UML, faremos isso passo a passo. Então, para você 
acompanhar a atividade, sugiro que faça o download do Astah Community ou 
qualquer outra ferramenta CASE que esteja habituado.
O trabalho com a ferramenta CASE Astah Community é bem intuitivo e 
você não terá dificuldades em desenvolver. Vamos por a mão na massa.
A distribuidora de filmes Fenix é proprietária de vários cinemas, em diver-
sas cidades, e precisa de um sistema para controlar as exibições de filmes em 
todas as salas de seus cinemas.
O FAST CASE provê todas as funcionalidades necessárias para a construção 
dos modelos, tais como o Modelo de Requisitos, suportando a técnica de 
casos de usos, e os Modelos de Análise e Projeto, suportando os modelos 
de Classes, Interações e de Ciclo de vida. O sistema, que é distribuído livre-
mente, já vem sendo utilizado há mais de um ano por mais de uma centena 
de alunos. 
Saiba mais sobre o FAST CASE em: <http://www.inf.ufsc.br/sbes99/anais/
Sessao-Ferramenta-Completo/12-fastcase.pdf>. Acesso em: 31 jul. 2015.
Fonte: o autor.
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E140
No fluxo básico do sistema, o operador é responsável por alimentar todos 
os cadastros que envolvem a movimentação de exibição ou suspensão do filme.
Não temos interesse em controlar os ingressos para os filmes, mas sim as 
datas, horários e salas onde os filmes estão sendo exibidos, dessa forma, pode-
mos simplesmente exibi-lo ou suspendê-lo.
Cada cinema possui uma sala ou várias salas de exibição. Um filme pode estar 
em cartaz em mais de um cinema ao mesmo tempo, isto é, pode estar sendo exi-
bido em vários cinemas e, é claro, em várias cidades ao mesmo tempo.
Cada cinema possui uma identificação, um nome de fantasia, um endereço 
e sua capacidade de lotação. Cada filme é registrado com um título, sua dura-
ção, sua impropriedade e um conjunto de atores que formam seu elenco, bem 
como seu diretor. 
Os atores de um filme podem atuar em diversos filmes, assim como o dire-
tor de um filme pode, também, ser ator nesse ou em outro filme. Um ator possui 
código, nome, nacionalidade e idade. Existe um único diretor para cada filme.
Primeiramente, vamos definir os requisitos funcionais do sistema. Lembrando 
que, requisitos funcionais é tudo aquilo que o sistema deve fazer.
REQUISITOS
O sistema de exibição de filmes MovieShow auxiliará o operador de cinema a 
exibir e suspender a exibição dos filmes nos vários cinemas que compõem a 
Distribuidora Fenix. Para isso, algumas funcionalidades são necessárias:
 
 
 
 
 
Estudo De Caso
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
.
141
1. O sistema deve permitir que os usuários acessem, de maneira “on-line” 
e a qualquer momento, o sistema, utilizando dispositivos que suportem 
navegadores web “atuais”.
2. A autenticação deve ser feita utilizando uma conta criada no próprio 
sistema. Para criar a conta, o usuário deve solicitar o cadastro que será 
aprovado por um usuário “administrador”. O usuário cadastrado deverá 
confirmar que leu os termos de aceite do sistema e mudar sua senha na 
primeira autenticação. O sistemadeve ter uma política para criação e 
manutenção de senhas.
3. O controle de permissões deve ser feito por um usuário “administrador” 
que diz o que cada usuário pode acessar.
4. Os tipos possíveis de usuários são:
a. Administrador: que gerencia questões administrativas, como permissões, blo-
queio de usuários, configurações etc.
b. Operador: responsável pelo cadastro e exibição dos filmes.
5. O menu principal do sistema deve listar os filmes e salas que estão sendo 
exibidos.
6. O operador deve cadastrar os filmes, cinemas e salas.
7. O sistema deve permitir ao operador exibir ou suspender a exibição de 
um filme.
Figura 97: Tela principal do Astah Community
Fonte: o autor.
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E142
DIAGRAMA DE CASO DE USO
Vamos começar, então, compondo nosso cenário, construindo, primeiro, o 
diagrama de caso de uso. Lembrando que esse diagrama nos fornecerá uma 
panorâmica dos requisitos funcionais.
Os requisitos funcionais dizem a respeito àquilo que o software deve fazer, 
ou pelo menos o que se espera que faça.
Vamos lá, primeiramente, abra o Astah Community e clique na opção UseCase 
Diagram, como mostrado na imagem abaixo, ou clique no menu Diagram e esco-
lha a opção UseCase Diagram.
Em seguida, abrirá a tela apresentada na figura 98, na elipse vermelha, estão todas 
as ferramentas que precisaremos para a confecção do diagrama de caso de uso. 
Como você pode observar, o software é bem intuitivo: 
Figura 98: Ferramentas para o Diagrama de Caso de Uso
Fonte: o autor.
De�nir permissões
para usuário
Cadastrar novos
usuários
Administrador
Figura 99: Ator Administrador
Fonte: o autor.
Diagrama De Caso 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
.
143
Vamos iniciar modelando o ator que será o administrador do sistema, esse usu-
ário será responsável pela administração de novos acessos no sistema.
O diagrama da figura 100, agora completo, mostra o operador do cinema e suas 
atribuições de realizar os cadastros de ator, filme, cinemas, salas e fazer as movi-
mentações de exibir e suspender a exibição de um filme.
Suspender exibição
de �lme
Cadastrar Salas
Cadastrar FilmesCadastrar Ator
Exibir Filme
Operador
Cadastrar Cinemas
De�nir permissões
para usuário
Cadastrar novos
usuários
Administrador
Figura 100: Diagrama de Caso de Uso
Fonte: o autor.
Figura 101: Cadastrar novos usuários 
Fonte: o autor.
Cadastrar novos
usuários
Administrador
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E144
Para completarmos o diagrama de caso de uso, devemos adicionar a cada um 
deles uma descrição textual, vamos lá!
ATOR: ADMINISTRADOR
De�nir permissões
para usuário
Administrador
Figura 102: Definir permissões para usuário
Fonte: o autor.
Diagrama De Caso 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
.
145
NOME DO CASO DE USO CADASTRAR NOVOS USUÁRIOS
Descrição Permite inserir novos usuários no sistema.
Ator Administrador
Pré-condições O sistema deve estar em execução
Pós-condições Novo usuário inserido
Fluxo Básico
Ações do Ator Ações do Sistema
Solicitar a criação do 
novo usuário
Abre a Janela de Cadastro (A2)
Usuário informa os 
dados
Sistema valida a entrada (A1)
Sistema salva os dados
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incorreta, informá-
-lo sobre o erro e retornar ao campo incorreto.
A2: em {Solicita Cancela-
mento}
O usuário pode decidir encerrar o caso de uso sem 
fornecer uma entrada. Nesse caso, retornar ao fluxo 
básico em {Fim}
Quadro 3: Caso de Uso Cadastrar Novos Usuários.
Fonte: autor
Operador
Cadastrar Elenco
Figura 103: Cadastrar ator
Fonte: o autor.
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E146
NOME DO CASO DE USO DEFINIR PERMISSÕES PARA OS USUÁRIOS
Descrição Permite definir permissões para os usuá-
rios.
Ator Administrador
Pré-condições O sistema deve estar em execução
Pós-condições Permissões concedidas
Fluxo Básico
Ações do Ator Ações do Sistema
Solicitar a definição de permissões
Abre a Janela de definição de permissões 
(A2)
Usuário informa as permissões
Sistema valida a entrada (A1)
Sistema salva os dados
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incor-
reta, informá-lo sobre o erro e retornar ao 
campo incorreto.
A2: em {Solicita Cancelamento} O usuário pode decidir encerrar o caso 
de uso sem fornecer uma entrada. Nesse 
caso, retornar ao fluxo básico em {Fim}
Quadro 4: Caso de Uso Definir Permissões para os Usuários.
Fonte: autor
ATOR: OPERADOR
Figura 104: Cadastrar Filmes
Fonte: o autor.
Diagrama De Caso 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
.
147
NOME DO CASO DE USO CADASTRAR ELENCO
Descrição Permite inserir novos atores ou diretores no sistema.
Ator Operador
Pré-condições O sistema deve estar em execução
Pós-condições Novo ator inserido
Fluxo Básico
Ações do Ator Ações do Sistema
Solicitar a criação do 
novo ator
Abre a Janela de Cadastro (A2)
Usuário informa os 
dados
Sistema valida a entrada (A1)
Sistema salva os dados
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incorreta, informá-
-lo sobre o erro e retornar ao campo incorreto.
A2: em {Solicita Cance-
lamento}
O usuário pode decidir encerrar o caso de uso sem 
fornecer uma entrada. Nesse caso, retornar ao fluxo 
básico em {Fim}
Quadro 5: Caso de Uso Cadastrar Elenco.
Fonte: autor
Operador
Cadastrar Filmes
Figura 105: Cadastrar Cinemas
Fonte: o autor.
Operador
Cadastrar Cinemas
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E148
NOME DO CASO DE USO CADASTRAR NOVOS FILMES
Descrição Permite inserir novos filmes no sistema
Ator Operador
Pré-condições O sistema deve estar em execução
Pós-condições Novo filme inserido
Fluxo Básico
Ações do Ator Ações do Sistema
Solicitar a criação do 
novo filme
Abre a Janela de Cadastro (A2)
Usuário informa os dados
Sistema valida a entrada (A1)
Sistema salva os dados
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incorreta, infor-
má-lo sobre o erro e retornar ao campo incorreto.
A2: em {Solicita Cancela-
mento}
O usuário pode decidir encerrar o caso de uso sem 
fornecer uma entrada. Nesse caso, retornar ao fluxo 
básico em {Fim}
Quadro 6: Caso de Uso Cadastrar Novos Filmes.
Fonte: autor
Operador
Cadastrar Salas
Figura 106: Cadastrar Salas
Fonte: o autor.
Diagrama De Caso 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
.
149
NOME DO CASO DE USO CADASTRAR NOVOS CINEMAS
Descrição Permite inserir novos cinemas no sistema
Ator Operador
Pré-condições O sistema deve estar em execução
Pós-condições Novo cinema inserido
Fluxo Básico
Ações do Ator Açõesdo Sistema
Solicitar a criação do novo 
cinema
Abre a Janela de Cadastro (A2)
Usuário informa os dados
Sistema valida a entrada (A1)
Sistema salva os dados
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incorreta, 
informá-lo sobre o erro e retornar ao campo 
incorreto.
A2: em {Solicita Cancelamen-
to}
O usuário pode decidir encerrar o caso de uso 
sem fornecer uma entrada. Nesse caso, retornar 
ao fluxo básico em {Fim}
Quadro 7: Caso de Uso Cadastrar Novos Cinemas.
Fonte: autor
Figura 107: Exibir Filme
Fonte: o autor.
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E150
NOME DO CASO DE USO CADASTRAR SALAS
Descrição Permite inserir novas salas no sistema
Ator Operador
Pré-condições O sistema deve estar em execução
Pós-condições Nova sala inserida
Fluxo Básico
Ações do Ator Ações do Sistema
Solicitar a criação do nova 
sala
Abre a Janela de Cadastro (A2)
Usuário informa os dados
Sistema valida a entrada (A1)
Sistema salva os dados
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incorreta, 
informá-lo sobre o erro e retornar ao campo 
incorreto.
A2: em {Solicita Cancela-
mento}
O usuário pode decidir encerrar o caso de uso 
sem fornecer uma entrada. Nesse caso, retornar 
ao fluxo básico em {Fim}
Quadro 8: Caso de Uso Cadastrar Novas Salas.
Fonte: autor
Operador
Exibir Filme
Operador
Suspender exibição
de �lme
Figura 108: Suspender filme
Fonte: o autor.
Diagrama De Caso 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
.
151
NOME DO CASO DE USO EXIBIR FILME
Descrição Permite colocar um filme em exibição
Ator Operador
Pré-condições O sistema deve estar em execução
Pós-condições Status de exibição alterado
Fluxo Básico
Ações do Ator Ações do Sistema
Solicitar a exibição do filme
Abre a Janela de Movimentação (A2)
Usuário altera o status
Sistema valida a entrada (A1)
Sistema solicita horário de exibição
Usuário informa o horário de 
exibição
Sistema valida a entrada (A1)
Sistema salva os dados
Fim
Fluxos alternativos
A1: em {Valida entrada} Se o usuário fornecer uma entrada incorreta, 
informá-lo sobre o erro e retornar ao campo 
incorreto.
A2: em {Solicita 
Cancelamento}
O usuário pode decidir encerrar o caso de uso 
sem fornecer uma entrada. Nesse caso, retornar 
ao fluxo básico em {Fim}
Quadro 9: Caso de Uso Exibir Filmes.
Fonte: autor
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E152
NOME DO CASO DE USO SUSPENDER A EXIBIÇÃO DO FILME
Descrição Permite suspender a exibição do filme no sistema
Ator Operador
Pré-condições O sistema deve estar em execução
Pós-condições Suspensão da exibição do filme
Fluxo Básico
Ações do Ator Ações do Sistema
Solicitar a suspensão 
de exibição
Abre a Janela de Movimentação (A2)
Usuário informa o 
filme
Sistema valida a entrada (A1)
Usuário altera o status
Sistema salva os dados
Fim
Fluxos alternativos
A1: em {Valida entra-
da}
Se o usuário fornecer uma entrada incorreta, informá-lo 
sobre o erro e retornar ao campo incorreto
A2: em {Solicita Cance-
lamento}
O usuário pode decidir encerrar o caso de uso sem for-
necer uma entrada. Nesse caso, retornar ao fluxo básico 
em {Fim}
Quadro 10: Caso de Uso Suspender a Exibição de Filmes.
Fonte: autor
O que fizemos até agora?
 ■ Levantamos os requisitos do sistema.
 ■ Elaboramos o diagrama de caso de uso.
 ■ Elaboramos a descrição de cada um dos casos de uso.
O que falta para terminar?
 ■ Elaborar o diagrama de classes.
Diagrama de Classes
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
.
153
 ■ Elaborar o diagrama de sequência.
 ■ Elaborar o diagrama de colaboração.
 ■ Elaborar o diagrama de estado.
DIAGRAMA DE CLASSES
Após o levantamento de requisitos, juntamente com sua especificação, podemos 
elaborar o diagrama de classes, pois já contamos com subsídios suficientes após 
a criação do cenário do sistema.
Para relembrarmos, o diagrama de classes modela a estrutura estática do 
sistema. Uma classe é uma estrutura que modela um conjunto de objetos cujas 
características sejam similares. O comportamento é modelado por meio dos 
métodos, e os possíveis estados do objeto, são modelados mediante atributos.
Verificando o diagrama de caso de uso, podemos levantar as classes: usuário, 
filme, elenco, cinema, sala. Vamos definir seus principais atributos de acordo com 
o estudo de caso. Leia o estudo de caso novamente para compreender melhor.
Na classe usuário, precisamos registrar o nome do usuário, sua senha e per-
missões de acesso.
Na classe filme, precisamos registrar seu título, duração e indicação 
(impropriedade).
Na classe elenco, precisamos registrar o nome do diretor/ator, a data de nas-
cimento e nacionalidade.
Na classe cinema, precisamos registrar o nome do cinema, endereço, lota-
ção, bairro e CEP.
Na classe salas, precisamos registrar o cinema ao qual ela pertence, o filme 
que está sendo exibido no momento, horário de exibição e capacidade.
A primeira versão do diagrama de classes ficará de acordo com a figura 109.
Figura 109: Diagrama de Classes - Versão 1.0
Fonte: o autor.
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E154
Como podem ter percebido, o nosso diagrama de classes está sem as associações, 
vamos completá-lo, então, com as associações e multiplicidades.
Vamos começar pela classe cinema. Cinema não tem uma associação direta 
com filmes, porque filmes são exibidos em salas. Também não tem uma relação 
direta com elenco, porque elenco faz parte do filme. Porém, com salas, o cinema 
associa, uma vez que o cinema é composto por salas. Olha que interessante, subli-
nhei a palavra composto para indicar que, se não existir cinema, também não 
existirá a sala, portanto, a associação é de agregação por composição.
Já vamos aproveitar para definir a multiplicidade para associação fazendo 
uma pergunta em duas direções:
 ■ Um cinema é composto de quantas salas?
• Resposta: por uma ou várias.
 ■ Uma sala compõe quantos cinemas?
• Resposta: somente um.
Sendo assim, nosso diagrama ficou como mostrado na figura 110, observe que 
na agregação por composição o losango é preenchido.
Cinema
- Cinema_id: int
- Nome: String
- Endereço: String
- Lotação: int
- Bairro: String
- Cidade: String
- UF: String
- CEP: String
- Inserir( ): void
- Cancelar( ): void
Filme
- Filme_id: int
- Título: String
- Curação: String
- Indicação: int
- Status: String
- Inserir( ): void
- Cancelar( ): void
Elenco
- Elenco_id: int
- Nome: String
- Data de Nascimento: Date
- Nacionalidade: String
- Inserir( ): void
- Cancelar( ): void
Sala
- Sala_id: int
- Horário: String
- Capacidade: String
- Inserir( ): void
- Cancelar( ): void
Cinema
- Cinema_id: int
- Nome: String
- Endereço: String
- Lotação: int
- Bairro: String
- Cidade: String
- UF: String
- CEP: String
- Inserir( ): void
- Cancelar( ): void
Filme
- Filme_id: int
- Título: String
- Curação: String
- Indicação: int
- Status: String
- Inserir( ): void
- Cancelar( ): void
Sala
- Sala_id: int
- Horário: String
- Capacidade: String
- Inserir( ): void
- Cancelar( ): void
1 1...” 0..” 1
Figura110: Associação por agregação
Fonte: o autor.
Figura 111: Associação por agregação e simples
Fonte: o autor.
Diagrama de Classes
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
.
155
Agora, vamos verificar a associação entre sala e filme, uma vez que os filmes são 
projetados nas salas. Essa é uma associação simples, pois tanto os objetos da 
classe filme quanto os objetos da classe sala não dependem do outro para exis-
tir. Vamos fazer aquelas perguntinhas para verificar a multiplicidade:
 ■ Uma Sala pode exibir quantos filmes?
• Somente 1.
 ■ Um filme pode estar sendo exibido em quantas salas?
• Em nenhuma ou em várias.
Vamos para a última associação entre filme e elenco. Nós sabemos que um ator 
pode atuar em vários filmes e que um filme por ter vários atores. Podemos verifi-
car, então, que a multiplicidade para essa associação é de vários(n) para vários(n). 
Cinema
- Cinema_id: int
- Nome: String
- Endereço: String
- Lotação: int
- Bairro: String
- Cidade: String
- UF: String
- CEP: String
- Inserir( ): void
- Cancelar( ): void
Sala
- Sala_id: int
- Horário: String
- Capacidade: String
- Inserir( ): void
- Cancelar( ): void
1 1...”
Cinema
- Cinema_id: int
- Nome: String
- Endereço: String
- Lotação: int
- Bairro: String
- Cidade: String
- UF: String
- CEP: String
- Inserir( ): void
- Cancelar( ): void
Filme
- Filme_id: int
- Título: String
- Curação: String
- Indicação: int
- Status: String
- Inserir( ): void
- Cancelar( ): void
Elenco
- Elenco_id: int
- Nome: String
- Data de Nascimento: Date
- Nacionalidade: String
- Inserir( ): void
- Cancelar( ): void
Sala
- Sala_id: int
- Horário: String
- Capacidade: String
- Inserir( ): void
- Cancelar( ): void
Ator
Ator
1 1...” 0..” 1
Figura 112: Diagrama de Classes versão final
Fonte: o autor.
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E156
Quando temos uma multiplicidade “n” para “n”, obrigatoriamente, devemos criar 
uma entidade associativa. Dessa forma, podemos conferir a versão final do nosso 
diagrama de classes na figura 112.
DIAGRAMA DE SEQUÊNCIA
Vamos elaborar, agora, o diagrama de sequência. Lembre-se de que a utilidade 
desse diagrama é estudar as interações entre os objetos, possibilitando a identi-
ficação de relação entre as classes, servindo para refinar o diagrama de classes.
Pode ser que ocorram mudanças nas classes após a análise do diagrama de 
sequência, mas também pode ser que não ocorra nenhuma mudança significa-
tiva. Porém o objetivo é estudar as interações de forma mais profunda.
Vamos iniciar pelo caso de uso “Cadastrar Filme”, vamos verificar toda a 
sequência de mensagens entre os objetos até a conclusão do cadastro.
Nesse caso de uso, o operador solicita a inserção de uma nova instância para 
a classe filme, a classe verifica se a entrada está correta, salva os dados e retorna 
um ok para o operador.
1: Solicita Inserir ( )
2: Veri�ca entrada ( )
4: OK ( )
Operador
Filme
3: Salva Dados ( )
Figura 113: Diagrama de sequência para inserir filme
Fonte: o autor.
Diagrama de Sequência
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
.
157
O próximo diagrama de sequência é para o caso de uso “Cadastrar Cinema”. 
Nesse caso de uso, o operador solicita a inserção de uma nova instância para a 
classe cinema, a classe verifica se a entrada está correta, salva os dados e retorna 
um ok para o operador.
A figura 114 representa um diagrama de sequência ilustrando o caso de uso 
“Cadastrar Cinema”. Neste caso de uso, o operador solicita a inserção de uma 
nova instância para a classe cinema. A classe verifica se a entrada está correta, 
salva os dados e retorna um ok para o operador.
1: Solicita Inserir ( )
2: Veri�ca entrada ( )
4: OK ( )
Cinema
3: Salva Dados ( )
Operador
Figura 114: Diagrama de sequência para cadastrar cinema
Fonte: o autor.
 
 
 
 
 
 
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E158
O diagrama da figura 115 representa um diagrama de sequência para o caso de 
uso “Cadastrar Elenco”. Nesse caso de uso, o operador solicita a inserção de uma 
nova instância para a classe sala, a classe verifica se a entrada está correta, veri-
fica se o cinema para aquela sala existe, salva os dados e retorna um ok para o 
operador.
5: Veri�ca Filme ( )
5.1: OK ( )
1: Solicita Inserir ( )
2: Veri�ca entrada ( )
AtorElenco Filme
8: OK( )
7: OK( )
4: Informa Filme ( )
6: Salva os dados ( )
3: Salva os dados ( )
Operador
Figura 115: Diagrama de sequência para inserir elenco
Fonte: o autor.
Diagrama de Sequência
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
.
159
O diagrama 116 representa um diagrama de sequência para o caso de uso 
“Cadastrar Sala”. Nesse caso de uso, o operador solicita a edição de uma instân-
cia da classe sala para informar qual filme está sendo exibido, o sistema verifica 
o status do filme e altera para em exibição. O sistema solicita o horário para a 
exibição, verifica a entrada e salva.
1: Solicita Inserir ( )
2: Veri�ca entrada ( )
3: Veri�ca Cinema ( )
3.1: OK ( )
5: OK ( )
CinemaSala
4: Salva Dados ( )
Operador
Figura 116: Diagrama de sequência para cadastrar sala
Fonte: o autor.
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E160
O diagrama 117 representa um diagrama de sequência para o caso de uso “Exibir 
Filme”. Nesse caso de uso, o operador solicita a suspensão do filme, o sistema 
solicita qual filme, o operador informa o filme, o sistema altera o status para sus-
penso e exclui de todas as salas que estão sendo exibidas.
1: Solicita Exibição ( )
2: Veri�ca entrada ( )
3: Veri�ca Status ( )
3.2: OK ( )
3.1: Altera Status ( )
8: OK ( )
FilmeSala
5: Informa Horário ( )
4: Solicita Horário ( )
6: Veri�ca Entrada ( )
7: Salva Dados ( )
Operador
Figura 117: Diagrama de Sequência para exibir filme
Fonte: o autor.
Diagrama de Estado
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
.
161
DIAGRAMA DE ESTADO
Vamos para a confecção, agora, do diagrama de estado. Esse diagrama representa 
o comportamento interno da classe, permitindo a especificação de sua dinâ-
mica. Não precisaremos de um diagrama para cada classe ou cada caso de uso, 
somente as classes que possuem um número finito de estados conhecidos têm a 
necessidade de uma representação por um diagrama de estado. 
O diagrama 118 representa um diagrama de sequência para o caso de uso 
Suspender a Exibição do Filme”.
1: Solicita Suspensão ( )
2: Solicita Filme ( )
2.1: Informa Filme ( )
3: Altera Status ( )
4: Exclui Filme( )
6: OK ( )
5: Salva Dados ( )
7: OK ( )
SalaFilme
Operador
Figura 118: Diagrama de sequência para suspender a exibição do filme
Fonte: o autor.
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E162
Dessa forma, conseguimos prever os possíveis comportamentosde um objeto 
por meio da análise da mudança de estados dos tipos de objetos de um sistema. 
O objeto, normalmente, tem um estado que é determinado por um atributo da 
classe daquele objeto.
Em nosso estudo de caso, a classe Filme tem um estado que é modelado por 
um atributo denominado “Status”, seu tipo de dado é string, o que significa que 
esse atributo aceita como valor uma cadeia genérica de caractere (letras, núme-
ros, símbolos).
Por meio do atributo “status” é possível colocar o filme em dois estados dife-
rentes (“exibindo”, “suspenso”). Portanto, modelaremos o diagrama de estado 
somente para a classe Filme.
O diagrama de estado da figura 119 nos mostra que, caso o objeto esteja no 
estado “SUSPENSO”, seu estado será modificado para “EXIBINDO” e finaliza. 
Porém, se o status já for “EXIBINDO”, então o objeto não sofrerá nenhuma alteração.
Status = “EXIBINDO”
St
at
us
 =
 “S
U
SP
EN
SO
”
SUSPENSO
do / atualiza
EXIBINDO
exit / gravar
Figura 119: Estado inicial SUSPENSO
Fonte: o autor.
Diagrama de Comunicaçã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
.
163
O início é marcado pela notação do círculo preenchido, os estados possíveis 
estão sendo identificados pela notação do retângulo com cantos arredondados. 
O losango indica um estado de escolha, em que deve ser verificado o estado atual 
do objeto para decidir se muda seu valor ou não.
O diagrama de estado da figura 120 nos mostra o caso contrário, ou seja, 
caso o objeto esteja no estado “EXIBINDO”, seu estado será modificado para 
“SUSPENSO” E finaliza. Porém, se o status já for “SUSPENSO”, então, o objeto 
não sofrerá nenhuma alteração.
DIAGRAMA DE COMUNICAÇÃO
Finalmente, vamos para a confecção do nosso último diagrama. O diagrama de 
comunicação nos permite representar o cenário de outra forma. Ele considera a 
ordem com que ocorre a comunicação, sem se preocupar com o tempo em que 
ocorre, pois, considerando o tempo, já modelamos no diagrama de sequência.
St
at
us
 =
 “E
XI
BI
N
D
O
”
Status = “SUSPENSO”
EXIBINDO
do / atualiza
SUSPENSO
exit / gravar
Figura 120: Estado inicial EXIBINDO
Fonte: o autor.
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E164
O diagrama de comunicação identifica as classes mais próximas e a ordem 
de envio de mensagens que é identificada por números sequenciais, mostrando 
a interação de forma organizada em torno dos objetos.
A figura 121 apresenta diagrama de comunicação para cadastrar um novo filme. 
O operador insere novos dados para o filme, os dados são validados e salvos pela 
classe, e retorna uma mensagem de confirmação da operação para o operador.
Filme
1: Insere ( )( )
2: Valida ( )
3: Salva ( )
4: OK ( )
Operador
Cinema
1: Insere ( )( )
2: Valida ( )
3: Salva ( )
4: OK ( )Operador
Figura 121: Cadastrar Filmes
Fonte: o autor.
Figura 122: Diagrama de comunicação para cadastrar cinema
Fonte: o autor.
Diagrama de Comunicaçã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
.
165
A figura 122 apresenta diagrama de comunicação para cadastrar um novo cinema. 
O operador insere novos dados para o cinema, os dados são validados e salvos pela 
classe, e retorna uma mensagem de confirmação da operação para o operador.
A figura 123 apresenta diagrama de comunicação para cadastrar um novo elenco. 
O operador insere novos dados para o elenco, os dados são validados e salvos 
pela classe, que envia uma mensagem para a classe ator informando qual filme 
aquele elenco participa como ator.
AtorElenco Filme
1: Insere ( )( ) 4: Informa Filme ( )
2: Valida ( )
5: Veri�ca Cinema ( )
3: Salva ( )
8: OK ( ) 7: OK ( ) 6: OK ( )Operador
Figura 123: Diagrama de comunicação para inserir elenco
Fonte: o autor.
Figura 124: Diagrama de comunicação para inserir novas salas
Fonte: o autor.
Sala Cinema
1: Insere ( )[ ]
2: Veri�ca entrada ( )
3: Veri�ca Cinema ( )
5: Salva ( )
6: OK ( ) 4: OK ( )Operador
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E166
A figura 124 apresenta diagrama de comunicação para cadastrar novas salas. O 
operador insere novos dados para a sala, os dados são validados pela classe, que 
envia uma mensagem para a classe cinema, verificando a existência do cinema, 
que retorna uma confirmação para classe sala, que salva os dados e confirma a 
operação para o operador.
A figura 125 apresenta o diagrama de comunicação para colocar o filme em exi-
bição. O operador insere novos dados para a sala, os dados são validados pela 
classe, que envia uma mensagem para a classe cinema, verificando a existência 
do cinema, que retorna uma confirmação para classe sala e solicita o horário ao 
operador que por sua vez informa o horário em seguida a entrada é verificada, 
então os dados são salvos e a operação é confirmada para o operador.
Operador
Sala Cinema
1: Solicita Exibição ( )
8: Veri�ca entrada ( )
2: Veri�ca Exibição ( )
3: Veri�ca Cinema ( )
9: Salva ( ) 4: Altera Status ( )
6: Solicita Horário ( )
7: Informa Horário ( )
10: OK ( )
5: OK ( )
Operador
Filme Sala
1: Solicita Suspensão ( )
4: Altera Status ( )
5: Exclui Filme ( )
6: Salva ( )
2: Solicita Filme ( )
3: Informa Filme ( )
8: OK ( )
7: OK ( )
Diagrama de Comunicaçã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
.
167
A figura 126 apresenta um diagrama de comunicação para suspender a exibição 
de filme. O operador insere novos dados para a sala, os dados são validados pela 
classe, que envia uma mensagem para a classe cinema, verificando a existência 
do cinema, que retorna uma confirmação para classe sala e solicita o horário ao 
operador que por sua vez informa o horário em seguida a entrada é verificada, 
então os dados são salvos e a operação é confirmada para o operador.
Figura 125: Diagrama de comunicação para exibição do filme
Fonte: o autor.
Figura 126: Diagrama de comunicação para suspender a exibição do filme
Fonte: o autor.
ESTUDO DE CASO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
VU N I D A D E168
CONSIDERAÇÕES FINAIS
Nesta unidade, aprendemos como usar uma ferramenta CASE para a modelagem 
do sistema, pois, sem o suporte do aplicativo, o trabalho de análise e projeto se 
torna bem mais difícil, principalmente quando necessitamos realizar alterações.
Por meio de um estudo de caso para uma distribuidora de filmes, tivemos 
a oportunidade de construir os diagramas necessários para a análise e projeto, 
aplicando os conceitos trabalhados de forma prática.
Familiarizamo-nos com a construção do diagrama de caso de uso. Este foi 
o primeiro diagrama que criamos para o estudo de caso, justamente para criar-
mos um cenário do sistema, com ele, podemos verificar quais são os atores que 
interagem com o sistema e quais tarefas cada um pode realizar no domínio.
Tivemos a oportunidade, também, de colocar em prática a confecção do dia-
grama de classes, que representa a estrutura estática do sistema. Vimos como 
definir as classes, associações e multiplicidades.
Vimos, ainda, como construir o diagrama de sequência, que mostra as trocas 
de mensagens entre os objetos considerando o tempo.Esse diagrama nos ser-
viu para verificar como e quando ocorrem as trocas. Alterações no diagrama de 
classes são comuns após a elaboração do diagrama de sequência. 
Estudamos a elaboração do diagrama de estados. Esse diagrama modela o 
comportamento da classe com utilização de máquinas de estado, mostrando-nos 
quais valores podem ser assumidos pelo atributo que representa o estado da classe.
Por fim, em uma tentativa de mostrar as trocas de mensagens de outra forma, 
elaboramos o diagrama de colaboração. Na verdade, esse diagrama é semelhante 
ao diagrama de sequência, porém não considera o tempo nas trocas de mensa-
gens, mas sim a ordem com que as mensagens ocorrem.
Chegamos ao final do nosso curso e, para desenvolvermos nossa habilidade 
na análise e projeto OO, é extremamente necessária a prática, então, não perca 
tempo e coloque a mão na massa. Bom trabalho e sucesso.
169 
1. Elabore um diagrama de objetos para as classes cinema e sala.
2. Elabore um diagrama de implantação para o sistema da Distribuidora Fênix.
3. Elabore um diagrama de componentes para o sistema da distribuidora Fênix.
4. Elabore um diagrama de atividades para incluir um filme para exibição.
Prezado(a) aluno(a), segue uma matéria 
que mostra como a Linguagem de Modela-
gem Unificada (UML) pode ser aplicada em 
conjunto com o Modelo de Referência para 
Processamento Distribuído Aberto (ISO/
RM-ODP), para o apoio ao desenvolvimento 
de sistemas de informações orientados a 
objetos.
A LINGUAGEM DE MODELAGEM 
UNIFICADA (UML) E USE CASES
Carlos Alberto Costa
A UML (Unified Modelling Language - Lingua-
gem de Modelagem Unificada) surgiu, nos 
últimos anos, da união de métodos anteriores 
para análise e projeto de sistemas orienta-
dos a objetos e em 1997 passou a ser aceita 
e reconhecida como um padrão potencial 
de notação para modelagem de múltiplas 
perspectivas de sistemas de informações 
pela OMG (“Object Management Group”) 
(BOOCH et al., 1999). Entre os métodos que 
deram origem a esta linguagem de mode-
lagem visual estão: Booch (BOOCH, 1994), 
OMT (Object Modelling Technique) e OOSE 
(Object Oriented Software Engineering). A 
UML define um conjunto básico de diagra-
mas e notações que permitem representar as 
múltiplas perspectivas (estruturais / estáticas 
e comportamentais / dinâmicas) do sistema 
sobre análise e desenvolvimento. Dentre os 
diagramas podem ser citados: Diagramas de 
Use Cases, Diagramas de Classes, Diagramas 
de Interações (Seqüência ou Colaboração), 
Diagramas de Atividades e Diagramas de 
Estado e Transição. As Tabela 1.1, Tabela 1.2 
e Tabela 1.3 descrevem brevemente alguns 
destes diagramas. Informações complemen-
tares sobre outros tipos de representações 
diagramáticas da UML podem ser encon-
tradas em (BOOCH et al., 1999; JACOBSON 
et al., 1999). O ambiente de projeto de mol-
des de injeção foi genericamente utilizado 
como exemplo para a representação de tais 
diagramas.
Diferente do RM-ODP, a UML oferece um 
suporte direto para o projeto e implemen-
tação de cada perspectiva do sistema em 
desenvolvimento e também uma notação 
para sua representação. Por esta razão, para 
a sua completa utilização, torna-se necessá-
rio um processo/metodologia que permita 
a migração e evolução das informações 
através das diferentes fases de represen-
tação, tais como funcionalidade, análise e 
projetos, implementação, etc. JACOBSON et 
al. (1999) fornecem um processo chamado 
Processo de Desenvolvimento de Software 
Unificado (UML process).
TEXEL & WILLIAMS (1997) propõem um pro-
cesso baseado em Use Cases combinado 
com Booch, OMT e UML, para o desenvol-
vimento de sistemas orientados a objetos.
Em ambos os processos, os Use Cases defi-
nem o primeiro nível de representação do 
sistema e resultam de uma fase de captura 
das “necessidades” a serem atendidas pelo 
mesmo. Os Use Cases representarão, num 
nível mais geral, as funcionalidades do sis-
tema em desenvolvimento e guiarão todas 
as fases subseqüentes de análise, projeto, 
implementação e testes do sistema com-
putacional.
Este artigo não tem como objetivo maior 
explorar o processo a ser aplicado para a 
modelagem das informações, visto que 
se trata de um outro tópico bastante 
abrangente. A Figura 3 mostra, de forma 
simplificada, como tal processo pode ser 
desenvolvido (TEXEL & WILLIAMS, 1997).
171 
Com base em uma descrição detalhada 
do sistema, principalmente enfocando as 
expectativas dos usuários em termos de 
“o que o sistema deveria fazer”, Use Cases 
potenciais são extraídos, bem como as 
Categorias do sistema. As Categorias (ou 
Pacotes) são outros tipos de elementos da 
UML e representam os módulos principais 
(grupo de objetos com funcionalidade simi-
lar) do sistema em desenvolvimento. Com 
base nestes dois elementos, uma descri-
ção geral de como as Categorias interagem 
entre si para executar cada Use Case, pode 
ser representada por diagramas de Seqüên-
cia. Esta fase é definida como análise do 
sistema onde tais representações podem 
ser utilizadas para um melhor esclareci-
mento e discussão com os usuários e 
responsáveis pela implementação do sis-
tema. Numa fase seguinte, caracterizada 
com maior ênfase no projeto do sistema, 
busca-se um refinamento destas represen-
tações, a nível dos objetos que farão parte 
do sistema. Ambos os diagramas, Classes 
e Interações são utilizados e apoiados por 
representações mais detalhadas dos aspec-
tos comportamentais dos objetos, através 
de diagramas de Estado e Transição e dia-
gramas de Atividades.
Leia mais em: <http://www.scielo.br/scielo.php?script=sci_arttext&pi-
d=S0104-530X2001000100003&lng=pt&nrm=iso>. Fonte: Costa (2001, online).
MATERIAL COMPLEMENTAR
Programação Orientada a Objetos com Java
David J. Barnes. 
Editora: Person Prentice Hall
Sinopse: O BlueJ é um ambiente Java de desenvolvimento 
que executa em cima do Sun Microsystems Java Development 
Kit utilizando o compilador-padrão e a máquina virtual. Ele 
foi especi� camente projetado para o ensino introdutório da 
programação orientada a objetos, permitindo ao aluno criar 
objetos de qualquer classe e interagir com seus métodos. Essa 
primeira abordagem verdadeiramente orientada a objetos 
dentro do ambiente BlueJ personalizado está revolucionando a 
maneira como a programação é ensinada.
Existem duas versões para a ferramenta Astah Community, a versão professional e community. Faça 
o download da versão Astah Community, pois esta é gratuita e sufi ciente para o que precisamos. 
Faça o download da ferramenta CASE para a elaboração dos diagramas estados nesse livro no link 
disponível em: <http://astah.net/download>. Acesso em: 31 jul. 2015.
Caso tenha difi culdades na confecção do diagrama de caso de uso, sugiro que assistam ao vídeo da 
professora Decíola Fernandes, da Universidade Rural da Amazônia. O vídeo apresenta um tutorial 
de 4 minutos mostrando como usar as ferramentas. Acesse-o no link disponível em: <https://www.
youtube.com/watch?v=VMG0EOangKY>. Acesso em: 31 jul. 2015.
Para aprofundar os conhecimentos sobre OO, leia a tese intitulada “DESENVOLVIMENTO 
DE UM SISTEMA COMPUTACIONAL ORIENTADO A OBJETOS PARA SISTEMAS ELÉTRICOS 
DE POTÊNCIA: APLICAÇÃO A SIMULAÇÃO RÁPIDA E ANÁLISE DA ESTABILIDADE DE 
TENSÃO”. Esse trabalho tem por objetivo aplicar a Modelagem Orientada a Objetos para o 
desenvolvimento de uma base computacional capaz de integrar e dar suporte à construção 
de um amplo conjunto de ferramentas para simulação e análise de sistemas elétricos. 
Acesse o trabalho no link disponível em: <http://www.coep.ufrj.br/~tarang/Simulight/Tese_Manzoni.
pdf>. Acesso em: 31 jul. 2015.
CONCLUSÃO
173
Com esta unidade, encerramos mais uma etapa e chegamos ao final da disciplina de 
Análise e Projeto Orientado a Objetos. Espero que o material tenha sido de grande 
valiae que possa somar com o seu conhecimento.
O livro Análise e Projeto Orientado a Objetos foi desenvolvido para proporcionar o 
contato com conceitos, ferramentas e métodos para direcioná-lo em sua vida aca-
dêmica e profissional. Procurei focar em elementos práticos e teóricos que contribu-
am para sua formação e aperfeiçoamento. Os exemplos de estudos de casos apre-
sentados são totalmente aplicáveis no dia a dia da engenharia de software.
Sabemos que a análise e o projeto de qualquer sistema, por mais simples que se-
jam, não são tarefas triviais, pois envolvem uma habilidade e perícia do analista em 
permear pelas necessidades do usuário, para extrair dele o que realmente deseja 
para a solução. Estabelecer domínios e levantar requisitos são atividades que exi-
gem muito do raciocínio lógico formal do analista e tal raciocínio se desenvolve com 
a experiência. Este livro representa somente o primeiro passo da sua jornada rumo 
ao conhecimento. 
Pode ser que, em algum momento da sua caminhada ao encontro do conhecimen-
to, você se depare com dificuldades que, naquele momento, parecem insolúveis e te 
desmotivem, talvez, faça você até pensar em desistir, porém a persistência o levará a 
solução, por isso, insista e nunca desista, todo problema tem solução, você somente 
ainda não a encontrou.
Para os(as) futuros(as) engenheiros(as) de software, fica a dica de leituras dos livros 
mencionados no final de cada unidade. São apresentadas situações de análise, pro-
jeto e desenvolvimento que serão muito úteis em sua vida profissional.
Um grande abraço, saúde, paz e luz na sua caminhada.
Prof. Me. Déverson Rogério Rando
CONCLUSÃO
REFERÊNCIAS
175
BOOCH, G. Object-oriented Analysis and Design. San Francisco-EUA: Editora 
Benjamin/ Cummings, 1997.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. Uml - Guia do Usuário. Rio de Janeiro: 
Editora: Campus, 2000.
COAD, P.; YOURDON, E. Análise Baseada em Objetos. Rio de Janeiro: Editora 
Campos, 1992.
COLEMAN, D. Desenvolvimento Orientado a Objetos: o Método Fusion. Rio de 
Janeiro: Editora: Campus, 1996.
COSTA, C. A. A aplicação da Linguagem de Modelagem Unificada (UML) para o su-
porte ao projeto de sistemas computacionais dentro de um modelo de referência. 
Gest. Prod.,  v.8,  n.1,  São Carlos,  abr.  2001. Disponível em: <http://www.scielo.br/
scielo.php?script=sci_arttext&pid=S0104-530X2001000100003&lng=pt&nrm=i-
so>.
JACOBSON, I. Object Oriented Software Engineering. Boston-EUA: Addison-Wes-
ley. 1995.
LEE, R. C.; TEPFENHART, W. M. UML e C++: Guia Prático de Desenvolvimento Orien-
tado a Objetos. São Paulo: Pearson Prentice Hall, 2002.
MARTIN, J.; ODELL, J. J. Análise e Projeto Orientados a Objeto. São Paulo: Editora: 
Makron, 1995
MEDEIROS, E. S. de. Desenvolvendo software com UML 2.0: definitivo. São Paulo: 
Pearson Makron Books, 2004.
MORAES, M. B. da C.; NAGANO, M. S. Sistemas de informação contábeis: uma abor-
dagem orientada a objetos com agentes inteligentes. JISTEM J.Inf.Syst. Technol. 
Manag (online), v. 6, n. 3, São Paulo, 2009. Disponível em: <http://www.scielo.br/
scielo.php?script=sci_arttext&pid=S1807-17752009000300005&lng=pt&nrm=iso>. 
Acesso em: 30 jul. 2015.
REIS, A. F. dos; COSTA, I. da. Proposta de integração da engenharia de softwa-
re nas estratégias empresariais. Production,  v.15  n.3.  São Paulo,  sept./dec. 
2005. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pi-
d=S0103-65132005000300013&lang=pt>. Acesso em: 29 jul. 2015.
RUMBAUGH, J. Object Oriented Modeling and Design. New Jersey-EUA: Editora: 
Prentice Hall, 1991.
SHLAER, S.; MELLOR, S.J. Análise de Sistemas Orientada a Objetos. São Paulo: 
Editora Makron Books, 1990.
REFERÊNCIAS
REFERÊNCIAS
SILVA, R. P. Avaliação das metodologias de análise e projeto orientadas a obje-
tos voltadas ao desenvolvimento de aplicações, sob a ótica de sua utilização 
no desenvolvimento de frameworks orientados a objetos. UFRGS, Rio Grande 
do Sul, 1996. Disponível em: <http://www.inf.ufsc.br/~ricardo/download/metodo-
logiasOOAD.pdf>. Acesso em: 31 jul. 2015.
SILVA, E. E. da. Como fazer um plano de testes baseado em casos de uso. Linha de 
Código. Disponível em: <http://www.linhadecodigo.com.br/artigo/2958/como-fa-
zer-um-plano-de-testes-baseado-em-casos-de-uso.aspx#ixzz3fJNU7NrE>. Acesso 
em: 29 jul. 2015.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 
2011.
YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1990.