Prévia do material em texto

ANÁLISE E PROJETO 
ORIENTADO
A OBJETOS
PROFESSORES
Me. Déverson Rogério Rando
Esp. Janaína Aparecida de Freitas
ACESSE AQUI 
O SEU LIVRO 
NA VERSÃO 
DIGITAL!
https://apigame.unicesumar.edu.br/qrcode/2888
EXPEDIENTE
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. 
Núcleo de Educação a Distância. RANDO, Déverson Rogério; 
FREITAS, Janaína Aparecida de.
Análise e Projeto Orientado a Objetos. 
Déverson Rogério Rando; Janaína Aparecida de Freitas.
Maringá - PR.: UniCesumar, 2020. Reimpresso em 2023. 
176 p.
“Graduação - EaD”. 
1. Análise 2. Projeto Orientado a Objeto 3. Informática. EaD. 
I. Título. 
FICHA CATALOGRÁFICA
NEAD - Núcleo de Educação a Distância
Av. Guedner, 1610, Bloco 4Jd. Aclimação - Cep 87050-900 | Maringá - Paraná
www.unicesumar.edu.br | 0800 600 6360 
Coordenador(a) de Conteúdo 
Flavia Lumi Matuzawa
Projeto Gráfico e Capa
Arthur Cantareli, Jhonny Coelho
e Thayla Guimarães
Editoração
Flávia Thaís Pedroso
Design Educacional
Paulo Victor Souza e Silva
Revisão Textual
Carla Cristina Farinha e 
Ariane Andrade Fabreti
Ilustração
Bruno Pardinho e André Azevedo
Fotos
Shutterstock
CDD - 22 ed. 005.1 
CIP - NBR 12899 - AACR/2
978-85-459-0113-6
Impresso por: 
Bibliotecário: João Vivaldo de Souza CRB- 9-1679
DIREÇÃO UNICESUMAR
NEAD - NÚCLEO DE EDUCAÇÃO A DISTÂNCIA
Diretoria Executiva Chrystiano Mincoff, James Prestes, Tiago Stachon Diretoria de Design Educacional 
Débora Leite Diretoria Diretoria de Graduação e Pós-graduação Kátia Coelho Diretoria de Permanência 
Leonardo Spaine Head de Curadoria e Inovação Tania Cristiane Yoshie Fukushima Head de Produção de 
Conteúdo Franklin Portela Correia Gerência de Contratos e Operações Jislaine Cristina da Silva Gerência de 
Produção de Conteúdo Diogo Ribeiro Garcia Gerência de Projetos Especiais Daniel Fuverki Hey Supervisora 
de Projetos Especiais Yasminn Talyta Tavares Zagonel Supervisora de Produção de Conteúdo Daniele C. 
Correia
Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de 
Matos Silva Filho Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva Pró-Reitor de Ensino 
de EAD Janes Fidélis Tomelin Presidente da Mantenedora Cláudio Ferdinandi
BOAS-VINDAS
Neste mundo globalizado e dinâmico, nós tra-
balhamos com princípios éticos e profissiona-
lismo, não somente para oferecer educação de 
qualidade, como, acima de tudo, gerar a con-
versão integral das pessoas ao conhecimento. 
Baseamo-nos em 4 pilares: intelectual, profis-
sional, emocional e espiritual.
Assim, iniciamos a Unicesumar em 1990, com 
dois cursos de graduação e 180 alunos. Hoje, 
temos mais de 100 mil estudantes espalhados 
em todo o Brasil, nos quatro campi presenciais 
(Maringá, Londrina, Curitiba e Ponta Grossa) e 
em mais de 500 polos de educação a distância 
espalhados por todos os estados do Brasil e, 
também, no exterior, com dezenas de cursos 
de graduação e pós-graduação. Por ano, pro-
duzimos e revisamos 500 livros e distribuímos 
mais de 500 mil exemplares. Somos reconhe-
cidos pelo MEC como uma instituição de exce-
lência, com IGC 4 por sete anos consecutivos 
e estamos entre os 10 maiores grupos educa-
cionais do Brasil.
A rapidez do mundo moderno exige dos edu-
cadores soluções inteligentes para as neces-
sidades de todos. Para continuar relevante, a 
instituição de educação precisa ter, pelo menos, 
três virtudes: inovação, coragem e compromis-
so com a qualidade. Por isso, desenvolvemos, 
para os cursos de Engenharia, metodologias ati-
vas, as quais visam reunir o melhor do ensino 
presencial e a distância.
Reitor 
Wilson de Matos Silva
Tudo isso para honrarmos a nossa mis-
são, que é promover a educação de qua-
lidade nas diferentes áreas do conheci-
mento, formando profissionais cidadãos 
que contribuam para o desenvolvimento 
de uma sociedade justa e solidária.
P R O F I S S I O N A LT R A J E T Ó R I A
Me. Déverson Rogério Rando 
Mestre em Ciência da Computação pela Universidade Estadual de Maringá (UEM). Es-
pecialista em Engenharia de Software pela Universidade Norte do Paraná. Graduado 
em Geografia pela Universidade Estadual de Londrina e Análise e Desenvolvimento 
de Sistemas pela Unicesumar. Atualmente, coordenador do Curso de Bacharelado 
em Sistemas de Informação da FAP – Faculdades Apucarana. Professor dos cursos 
de Técnico em Redes e Informática, respectivamente, no Senac e Senai, nas disci-
plinas de Banco de Dados, Análise Estruturada e OO, Organização e Arquitetura de 
Computadores, Computação Gráfica, IHC, Algoritmos, Linguagens de Programação, 
Sistemas de Informações Geográficas e Trabalho de Conclusão de Curso.
http://lattes.cnpq.br/3108532655755995
Esp. Janaína Aparecida de Freitas
Possui graduação em Informática pela Universidade Estadual de Maringá (2010) e 
especialização em MBA em Teste de Software pela Unicesumar (2012). Atualmente, 
cursa o Programa de Mestrado em Ciência da Computação na Universidade Estadual 
de Maringá (UEM) e é graduanda de Letras – Português/Inglês na Unicesumar. Atua, 
há três anos, como professora mediadora, professora conteudista em gravação de 
aulas ao vivo e conceituais nos cursos do NEAD – Núcleo de Educação a Distância, 
da Unicesumar, para os cursos de graduação de Sistemas para Internet, Análise e 
Desenvolvimento de Sistemas, Gestão da Tecnologia da Informação e Engenharia 
de Software, nas disciplinas de Engenharia de Software, Design Gráfico, Tópicos 
Especiais, Gerenciamento de Software, Design de Interação Humano-Computador, 
Projeto de Implementação e Teste de Software. Além disso, tem experiência em 
iniciativa privada na área de Análise de Sistemas e Testes de Software.
http://lattes.cnpq.br/4906244382612830
A P R E S E N TA Ç Ã O D A D I S C I P L I N A
ANÁLISE E PROJETO ORIENTADO A OBJETOS
Caro(a) aluno(a)! Seja bem-vindo(a) à disciplina de Análise e Projeto Orientado a Objetos (OO). 
Esta disciplina abordará vários aspectos relacionados à análise e ao projeto de sistemas orien-
tados a objetos, utilizando, como notação, a linguagem de modelagem UML. Apresentamos 
a você, aluno(a), o livro que conduzirá seus estudos, auxiliando no aprendizado de análise e 
projeto orientado a objetos com a UML. 
A Unidade 1 apresenta os conceitos iniciais sobre a análise e os projetos orientados a objetos. 
Estudaremos como surgiu e como ocorreu a evolução dos métodos orientados a objetos. 
Abordaremos, também, as características desses principais métodos, conheceremos os con-
ceitos básicos que envolvem a Orientação a Objetos para dar subsídio às unidades subse-
quentes. E, por fim, veremos os principais diagramas da UML utilizados na documentação 
de software.
Na Unidade 2, estudaremos as fases que compreendem a análise e o projeto de um software. 
Entraremos em contato com dois dos modelos de processos: cascata e evolucionário. Vere-
mos as vantagens e desvantagens da utilização de cada um desses métodos, abordaremos, 
também, os requisitos de software e conheceremos os procedimentos mínimos para a obten-
ção de um software de qualidade. Encerraremos a unidade falando sobre a importância da 
construção de casos de uso no levantamento de requisitos bem como a notação necessária 
para a construção de diagramas de casos de uso.
A Unidade 3 é toda dedicada à confecção do diagrama de classes responsável por demons-
trar a estrutura estática do sistema. Conheceremos, em detalhes, a notação para o diagrama 
de classes. Abordaremos os conceitos e a assinatura da declaração de atributos e métodos. 
Veremos como ocorrem as ligações entre as classes e como definir a multiplicidade entre 
elas. Discutiremos, ainda, as várias formas de associar as classes, sejam elas unária, binária, 
ternária, sejam elas associativa, de agregação ou generalização. 
D A D I S C I P L I N AA P R E S E N TA Ç Ã O
Na Unidade 4, conheceremos mais três diagramas, essenciais em análise e projeto OO, que 
utilizaremos para refinar o diagrama de classes que representa a estrutura do sistema. O 
primeiro diagramaque veremos, nesta unidade, é o de sequência, cujo objetivo é estudar as 
interações entre os objetos, considerando a dimensão tempo. O segundo diagrama que ve-
remos é o de estados, que tem como objetivo especificar o comportamento das classes mais 
complexas, utilizando máquinas de estado. Já o terceiro diagrama é o de comunicação, que 
contém as mesmas informações do diagrama de sequência, porém não considera o tempo, 
e sim a ordem da comunicação.
Por fim, na Unidade 5, resolveremos, juntos, um estudo de caso, no qual teremos a oportu-
nidade de apresentar, de forma prática, a construção dos diagramas citados na elaboração 
da análise e do projeto de um software. Dessa forma, reforçaremos todos os conceitos tra-
balhados nas unidades anteriores.
Ao longo deste livro, você encontrará indicações de leitura complementar, as quais enrique-
cerão o seu conhecimento sobre projetos. É importante que você desenvolva as atividades de 
estudo para fixar o conteúdo abordado e identificar eventuais dificuldades. Preparados(as)? 
Vamos lá!
ÍCONES
Sabe aquela palavra ou aquele termo que você não conhece? Este ele-
mento ajudará você a conceituá-la(o) melhor da maneira mais simples.
conceituando
No fim da unidade, o tema em estudo aparecerá de forma resumida 
para ajudar você a fixar e a memorizar melhor os conceitos aprendidos. 
quadro-resumo
Neste elemento, você fará uma pausa para conhecer um pouco 
mais sobre o assunto em estudo e aprenderá novos conceitos. 
explorando ideias
Ao longo do livro, você será convidado(a) a refletir, questionar e 
transformar. Aproveite este momento! 
pensando juntos
Enquanto estuda, você encontrará conteúdos relevantes 
online e aprenderá de maneira interativa usando a tecno-
logia a seu favor. 
conecte-se
Quando identificar o ícone de QR-CODE, utilize o aplicativo Unicesumar 
Experience para ter acesso aos conteúdos online. O download do aplicativo 
está disponível nas plataformas: Google Play App Store
CONTEÚDO
PROGRAMÁTICO
UNIDADE 01 UNIDADE 02
UNIDADE 03
UNIDADE 05
UNIDADE 04
FECHAMENTO
INTRODUÇÃO 
AO ESTUDO DE 
ORIENTAÇÃO A 
OBJETOS
10 
CASOS DE USO
40 
70 
DIAGRAMA DE 
CLASSES
102 
DIAGRAMAS DE 
SEQUÊNCIA, ESTADO 
E COLABORAÇÃO
130 
ESTUDO DE CASO
168 
CONCLUSÃO GERAL
1
INTRODUÇÃO
AO ESTUDO 
de orientação a objetos
PLANO DE ESTUDO 
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Introdução à Orientação a Objetos 
• Evolução dos Métodos OO • Conceitos Básicos de OO • Principais Diagramas da UML.
OBJETIVOS DE APRENDIZAGEM 
Entender a importância de análise e projeto • Conhecer a evolução dos métodos OO • Compreender as 
características dos métodos OO e seus diferentes termos • Conhecer os principais diagramas da UML.
PROFESSORES 
Me. Déverson Rogério Rando
Esp. Janaína Aparecida de Freitas
INTRODUÇÃO
Caro(a) aluno(a), iniciamos a primeira unidade do livro Análise e Projeto 
Orientado a Objetos falando sobre a importância da análise de sistemas 
dentro do projeto de produção de software.
Veremos que a análise de sistemas é a atividade inicial do processo de 
desenvolvimento de software. É nessa fase que determinamos e especifi-
camos o que um software deve fazer. Também, nessa fase, verificamos as 
circunstâncias sob as quais o software deve operar, envolvendo, geralmente, 
um esforço colaborativo entre analistas de sistemas e usuários.
Em seguida, veremos como os métodos surgiram e como aconteceu sua 
evolução. Abordaremos, a partir do primeiro método orientado a objetos, 
proposto por Shlaer e Mellor em 1988, o OOSA, até chegarmos à Unified 
Modeling Language, UML, que será a linguagem que utilizaremos para as 
nossas análises e nossos projetos OO.
Mesmo utilizando a UML, é importante conhecermos as características 
dos principais métodos OO, uma vez que a UML é a unificação de vários 
métodos que serão apresentados. Ou seja, a evolução de todos os outros 
métodos permitiu que chegássemos a uma unificação que, na verdade, 
apropria-se das melhores características dos demais métodos.
Nesta unidade, também conheceremos e entenderemos os conceitos 
e termos utilizados na análise e no projeto OO. Dentre os conceitos que 
veremos, estão os de objeto, abstração, classe, instância, atributo, operação, 
mensagem, evento, estado e parâmetro. Com esses conceitos iniciais, você 
terá uma visão geral sobre OO.
Conheceremos, ainda, os principais diagramas da UML utilizados na 
análise e no projeto de softwares, dentre eles: o diagrama de casos de uso 
utilizado na fase de análise para criar um cenário para o software, o dia-
grama de classes que modela a estrutura estática do sistema, o diagrama 
de sequência, o de colaboração e o de estado.
Então, o que estamos esperando? Vamos ao trabalho?
Boa leitura a todos.
U
N
ID
A
D
E 
1
12
1 
INTRODUÇÃO
À ORIENTAÇÃO
a objetos 
ANÁLISE E PROJETO
O processo de desenvolvimento de um sistema computacional tem, na análise, 
sua atividade inicial. Atividade esta que determina e especifica o que um sistema 
deve fazer, além das circunstâncias sob as quais ele deve operar, envolvendo um 
esforço colaborativo que abrange analistas de sistemas e usuários.
Os analistas procuram obter, a partir dos usuários, em um processo gradual 
e cumulativo, o maior conhecimento possível acerca do domínio do problema e 
do respectivo ambiente.
De acordo com Sommerville (2011), podemos chamar de “análise de sistemas” 
o que faz parte da “engenharia de requisitos”. Acrescentar o termo “engenharia” 
implica dizer que técnicas sistemáticas deverão ser utilizadas para assegurar que 
os requisitos do sistema sejam consistentes, relevantes e completos. A análise de 
sistemas é uma atividade de suma importância no processo de desenvolvimento 
destes, por ser uma etapa inicial e, também, porque as falhas terão efeitos em 
cadeia nas etapas subsequentes, assim como no produto final. A determinação 
incorreta dos requisitos levará à obtenção e à disponibilização de sistemas com-
putacionais inadequados.
U
N
IC
ES
U
M
A
R
13
Resumindo: a análise é a solução conceitual dada ao problema. Marca o início 
da definição informática, mas sem levar em conta detalhes da implementação, tais 
como a linguagem e o sistema gerenciador de banco de dados a serem utilizados. 
Preocupa-se, principalmente, com as classes do domínio do problema e suas 
relações e, também, com os casos de uso. Se, por um lado, a análise é a solução 
conceitual, por outro, o projeto consiste na solução computacional aplicada ao 
problema. Dizer onde acaba a análise e se inicia o projeto é muito complicado, 
uma vez que o projeto é o resultado de refinamentos sucessivos do modelo con-
ceitual de análise.
A Orientação a Objetos fez com que fosse alterado o enfoque necessário 
para desenvolver um sistema, enquanto que, na programação estruturada, havia, 
nitidamente, uma visão sequencial e bem dividida, como os programas, que exe-
cutam determinados processos e tratam determinados dados. Na Orientação a 
Objetos, passamos a visualizar classes responsáveis por atributos, com operações 
criadas para tratá-los, e a execução das atividades dos sistemas passa a depender 
da interação dessas classes.
Análise e projeto OO
Na década de 80, houve preponderância dos métodos estruturados para o desen-
volvimento de software. Atualmente, o paradigma OO é mais forte e, por isso, é 
importante diferenciar entre análise e projeto estruturado e orientado a objetos.
A análise e o projeto estruturados têm, como ênfase, as funções que atuam 
sobre os dados, ou seja, todo o processo que se deseja informatizar é compreendi-
do como um conjunto de funções com dados de entrada, processamento e saída. 
Yourdon (1990) apresenta as principais características:
 ■ Modularidade e coesão.
 ■ Desenvolvimento top-down (diferentes níveis de abstração).
Os diagramas que apoiam a análise e o projeto estruturado são:
 ■ Diagrama Entidade e Relacionamento (DER).
 ■ Dicionários de dados.
 ■ Diagrama de Fluxo de Dados (DFD).
U
N
ID
A
D
E 
1
14
ODER modela a estrutura de dados parados, ou seja, é o modelo conceitual do 
sistema, mostra-nos as entidades e seus relacionamentos. Neste modelo, muitos 
detalhes não são mostrados, ficando a cargo do dicionário de dados os detalhes de 
nomes de atributos, tipos de dados, comprimento e demais restrições de dados. O 
DFD modela o fluxo destes, em outras palavras, mostra os dados em movimento, 
como ocorre a interação entre as diversas entidades (depósito) do sistema.
A Orientação a Objetos – ou, simplesmente, OO – é uma estratégia de de-
senvolvimento de software que o organiza como uma coleção de objetos que 
contém tanto a estrutura dos dados quanto o comportamento deles. A Orientação 
a Objetos tem, como principal característica, a forma natural de tratar a realidade, 
pois considera que o mundo real é formado por objetos.
A proposta da Orientação a Objetos é deslocar o esforço de desenvolvimento 
para a fase de análise, dando ênfase às estruturas de dados antes das funções e, 
assim, os benefícios são: a reutilização do código (componentes), a confiabilidade 
(objetos encapsulados) e o aumento de produtividade (SOMMERVILE, 2011). 
Com planejamento adequado, desenvolvedores capacitados e adoção de uma 
metodologia, o sucesso é garantido. A análise OO apresenta um conjunto de 
regras e modelos que auxiliam o analista a levantar e a modelar os requisitos dos 
usuários que o sistema deve atender.
Um sistema orientado a objetos é composto de objetos interativos que mantêm seu pró-
prio estado local e oferecem operações nesse estado. A representação do estado é privada 
e não pode ser acessada diretamente, de fora do objeto. Processos de projeto orientado a 
objetos envolvem projetar as classes de objetos e os relacionamentos entre essas classes. 
Essas classes definem os objetos no sistema e suas interações. Quando o projeto é con-
cebido como um programa em execução, os objetos são criados dinamicamente a partir 
dessas definições de classe. Sistemas orientados a objetos são mais fáceis de mudar do 
que os sistemas desenvolvidos com abordagens funcionais. Os objetos incluem os dados 
e as operações para manipulá-los. Portanto, eles podem ser entendidos e modificados 
como entidades autônomas. Como os objetos são associados com coisas, muitas vezes, 
existe um mapeamento claro entre entidades do mundo real e seus objetos de controle 
no sistema, o que melhora a inteligibilidade e, portanto, a manuteniblidade do projeto.
Fonte: Sommerville (2011, p.125).
explorando Ideias
U
N
IC
ES
U
M
A
R
15
2 
EVOLUÇÃO
DOS MÉTODOS OO
Os métodos de análise e projeto orientado a objetos surgiram assim que as lingua-
gens de programação OO começaram a estabilizar, sendo que um dos primeiros 
métodos foi o modelo OOSA, proposto por Shlaer e Mellor, em 1988, e o Wirfs-
-Brock, lançado em 1989, pelo grupo de pesquisa da Smalltalk (MEDEIROS, 2004).
A maior parte dos métodos OO, porém, passou a se tornar estável na década de 90, 
com a fusão das metodologias de Grady Boock, James Rumbaugh e Ivar Jacobson e a 
criação da UML, que teve como base outras metodologias, como a de Shlaer-Mellor. 
Buscava-se, com a criação da UML, uma padronização das metodologias OO.
Ivar Jacobson (1995)
Apresenta uma abordagem mais conceitual do que de detalhes, composta 
por cinco fases: levantamento de requerimentos, análise de robustez, projeto, 
implementação e teste. Ele segue a estratégia de métodos não lineares e em 
espiral com refinamentos sucessivos.
Coad e Yourdon (1992)
Abrangem as fases de análise, projeto e implementação; propõem uma meto-
dologia simples para iniciantes. As críticas mais fluentes destacam a ausência 
de modelagem para abranger todo o contexto necessário na fase de análise.
U
N
ID
A
D
E 
1
16
Shlaer e Mellor (1990)
Abrangem as fases de análise, projeto e implementação. Propõem mecanis-
mos para facilitar a representação de modelos dinâmicos dos objetos, dando 
ênfase à modelagem da informação, por meio dos modelos de objetos, de 
estados, de diagramas de fluxo de dados e de ações.
Grady Booch (1997)
Abrange as fases de análise, projeto e implementação. Apresenta uma poderosa 
notação utilizada para expressar as relações entre as classes, destacando-se, 
principalmente, na fase de projeto. É considerado um dos mais autênticos e 
tradicionais métodos de desenvolvimento de sistemas orientados a objetos.
James Rumbaugh (1991)
Abrange as fases de levantamento de dados com a descrição do domínio e do 
enunciado do problema, dividindo a fase de análise em modelagem de obje-
tos, modelagem dinâmica e modelagem funcional, destacando o tratamento 
de processos e dividindo a fase de projeto em projeto de objetos e de sistema. 
Martin e Odell (1995)
Abrangem as fases de análise e projeto. Propõem o uso da Engenharia da 
Informação baseada em objetos por meio de um repositório de objetos, para 
a obtenção, em alto nível, de reaproveitamento dos sistemas. 
Fusion (1996)
Abrange as fases de análise, projeto e implementação. Sintetiza os aspec-
tos mais positivos dos métodos de James Rumbaugh/OMT, Grady Booch, 
Wirfs-Brock/CRC e Ivar Jacobson/Objectory. O autor enfoca os modelos 
de objetos e processos do método OMT, a interação de objetos da CRC, a 
visibilidade do método de Booch e complementa com pré e pós-condições 
de métodos formais (COLEMAN, 1996).
U
N
IC
ES
U
M
A
R
17
UML – Unified Modeling Language (2000)
Abrange as fases de levantamento de requisitos, análise, projeto e implemen-
tação. Fusão dos métodos de James Rumbaugh/OMT, Grady Boock e Ivar 
Jacobson. A fusão inicia com o trabalho de Rumbaugh e Booch, os dois me-
todistas que ganharam mais popularização, os quais se juntaram para criar 
para o público um método comum por meio de pontos fortes em 1995. Em 
seguida, em meados de 1996, Jacobson integrou-se ao grupo, e lançaram a 
UML versão 0.9. A partir daí, criaram forças com cooperação da OMG (Object 
Management Group), em julho de 1997, considerado um padrão mundial.
A UML sugere, fortemente, a adoção de casos de uso (use cases) como dire-
cionadores de projetos de software, a utilização de diagramas de interação para 
identificação de objetos e uma série de outros conceitos. 
O projeto de software começa quando a primeira iteração da engenharia de requisitos 
chega a uma conclusão. O intuito do projeto de software é aplicar um conjunto de prin-
cípios, conceitos e práticas que levam ao desenvolvimento de um sistema ou produto de 
alta qualidade. O objetivo do projeto é criar um modelo de software que irá implementar 
corretamente todos os requisitos do cliente e trazer satisfação àqueles que o usarem. Os 
projetistas de software devem examinar completamente muitas alternativas de projeto e 
convergir para uma solução que melhor atenda às necessidades dos interessados no pro-
jeto. O processo de projeto passa de uma visão macro do software para uma visão mais 
estreita que define os detalhes necessários para implementar um sistema. O processo 
começa concentrando-se na arquitetura. São definidos subsistemas; são estabelecidos 
mecanismos de comunicação entre os subsistemas; são identificados componentes; e é 
desenvolvida uma descrição detalhada de cada componente. Além disso, são projetadas 
interfaces externas, internas e para o usuário.
Fonte: Pressman (2011, p. 226).
explorando Ideias
O modelo de projeto engloba quatro elementos distintos; à medida que cada um é desen-
volvido, evolui uma visão mais completa do projeto.
(Roger Pressman)
pensando juntos
U
N
ID
A
D
E 
1
18
3 
CONCEITOS
BÁSICOS DE OO
Conheceremos, a seguir, os principais termos e conceitos utilizados em análise 
e projeto OO. Vamos lá!
 ■ Objeto: qualquer elemento concreto ou abstrato que existe no mundo 
real, que se pode individualizar por possuir comportamentos e caracte-
rísticas próprios.
Figura 1 - Objetos concretos Figura 2 - Objetos abstratos
U
N
IC
ES
U
M
A
R
19
 ■ Abstração: abstraímos quando definimos um objeto conceitual partindo 
de objetos do mundo real com os mesmoscomportamentos e caracterís-
ticas, os quais são classificados como de um mesmo tipo.
Figura 3 - Abstração de bolsa Figura 4 - Abstração de avião
Figura 5 - Abstração de esporte
 ■ Classe: representa a abstração de um conjunto de objetos do mundo 
real que possui comportamentos e características comuns.
Figura 6 - Classe funcionário
U
N
ID
A
D
E 
1
20
 ■ Instância: é cada umas das ocorrências de um objeto formado a partir 
da sua classe.
Figura 7 - Classe e objetos / Fonte: os autores.
 ■ Atributo: é uma característica particular que os objetos de uma classe 
possuem, assumindo valores diferentes para cada objeto.
Figura 8 - Classe, objeto e valor / Fonte: os autores.
 ■ Operação: é uma ordem que faz um objeto executar uma ação. As ope-
rações são tudo o que os objetos de uma classe fazem e nada além do 
que esses objetos podem fazer. 
Figura 9 - Operação / Fonte: os autores. 
U
N
IC
ES
U
M
A
R
21
 ■ Mensagem: representa o mecanismo de chamada de uma operação. É 
utilizada na solicitação de execução de uma operação. É a maneira como 
conseguimos que um método seja executado.
Figura 10 - Mensagem / Fonte: os autores. 
 ■ Evento: é um tipo especial de operação que faz com que os objetos mu-
dem de estado. 
Figura 11 - Evento / Fonte: os autores.
 ■ Parâmetro: é um ou mais atributos que são carregados para dentro de 
uma mensagem.
Figura 12 - Parâmetro - Avião, partida (linha aérea, número do voo, cidade) / Fonte: 
os autores.
U
N
ID
A
D
E 
1
22
 ■ Estado: é a forma de apresentação dos objetos de uma classe em deter-
minado instante.
Figura 13 - Estado / Fonte: os autores. 
 ■ Transição de estado: é quando ocorre a mudança de estado de um ob-
jeto de uma classe como resposta à chegada de um evento.
Estado Criado Estado Eliminado
Estado Parado Estado Decolando
Figura 14 - Transição de estado / Fonte: os autores. 
 ■ Associação: é a forma como os objetos de uma mesma classe ou de 
classes diferentes se conectam.
Figura 15 - Associação de classes / Fonte: os autores.
 ■ Encapsulamento: é a reunião de características e comportamentos de 
objetos em uma classe.
Figura 16 - Encapsulamento / Fonte: os autores. 
U
N
IC
ES
U
M
A
R
23
 ■ Polimorfismo: é a capacidade que objetos de classes diferentes possuem 
de se comportarem de forma diferente em uma mesma operação. A es-
trutura (atributos) de cada classe é diferente.
Figura 17 - Polimorfismo / Fonte: os autores. 
 ■ Método: é o algoritmo (conjunto de passos) que um objeto executa quan-
do reage a uma operação. O método é a lógica interna de uma operação. 
public int somar( int num1, int num2 )
{
 return num1 + num2;
 }
Quadro 1 - Declaração de um método / Fonte: os autores.
 ■ Colaboração: é a troca de mensagens que acontece entre objetos e atores
 ■ Figura 18 - Troca de mensagens entre os objetos / Fonte: os autores. 
 ■ Herança: é a propriedade que possibilita que a classe herde característi-
cas e comportamento de outra classe.
Figura 19 - Herança / Fonte: os autores.
U
N
ID
A
D
E 
1
24
4 
PRINCIPAIS
DIAGRAMAS DA UML
Agora que já conhecemos os principais termos utilizados na análise e no projeto 
OO, conheceremos os diagramas utilizados para documentação de software. A 
UML 2.5 apresenta vários diagramas, classificados em estruturais e de compor-
tamento. A Figura 20 mostra esta organização em um diagrama de classes.
Figura 20 - Organização do diagrama UML / Fonte: os autores.
U
N
IC
ES
U
M
A
R
25
É comum verificarmos que a documentação do software, na maioria das vezes, não 
tem a devida atenção da equipe de desenvolvimento, por preguiça, ou por falta de 
tempo, ou mesmo por pensar que é perda de tempo elaborar inúmeros diagramas. 
Porém, bons softwares têm documentação que nos permite contar e entender a sua 
história. A seguir, conheceremos alguns dos diagramas mais utilizados na UML.
Diagramas de comportamento
Os diagramas de comportamento são utilizados para descrever o sistema mo-
delado em execução. São utilizados para especificar, visualizar, documentar e 
construir os aspectos dinâmicos de um sistema, ou seja, é a representação das 
partes que sofrem alterações. 
Diagrama de casos de uso
O diagrama de casos de uso (comportamento) é utilizado na análise de requisitos. 
Este diagrama acompanha o software desde o seu início até a conclusão.
Para conhecermos o conceito de caso de uso, temos que conhecer, primeira-
mente, o ator. Este pode ser uma pessoa (usuário), um sistema ou uma máquina. 
O ator é quem realiza as atividades e sempre atua sobre um caso de uso.
O diagrama de caso de uso da Figura 21 modela o comportamento dos atores 
no sistema de uma biblioteca. No exemplo, o diagrama mostra os atores aluno e 
bibliotecária, representados pelo stickman (“homem palito”) e suas respectivas 
ações descritas nas elipses.
Figura 21 - Diagrama de caso de uso / Fonte: os autores.
Cria livro
Cria aluno
Efetua empréstimo
Bibliotecária
Realiza
empréstimo
Realiza
consulta
Realiza
devolução
Aluno
U
N
ID
A
D
E 
1
26
Diagrama de sequência
Com o objetivo de refinar o diagrama de classes, o diagrama de sequência (com-
portamento) é um dos vários tipos de diagrama de interação disponibilizados 
pela UML, sua utilidade é estudar as interações entre os objetos, possibilitando 
a identificação de relação entre as classes.
O cenário representado na Figura 22 mostra a solicitação de um empréstimo 
pelo aluno. A partir desta ação, é desencadeado um conjunto de mensagens entre 
os objetos, que, por sua vez, permite a verificação da existência da pessoa aluno, e, 
em seguida, é criado o item de empréstimo, que verifica a existência do exemplar 
solicitado, realizando o empréstimo.
Como é possível observar, a partir das informações fornecidas pelo diagra-
ma de sequência, pode-se identificar os métodos associados às classes, além da 
identificação das relações entre elas.
s
Figura 22 - Diagrama de sequência / Fonte: os autores. 
U
N
IC
ES
U
M
A
R
27
Outra forma de representar esse cenário é pelo diagrama de comunicação (com-
portamento). Ele contém as mesmas informações que o diagrama de sequência, 
porém não considera a dimensão temporal.
Diagrama de estados
Agora, veremos o diagrama de estados (comportamento), que tem como obje-
tivo especificar o comportamento das classes mais complexas, utilizando uma 
máquina de estados.
Autômato finito ou máquina de estados finitos representa a modelagem de comporta-
mentos considerando o seu estado. O estado guarda informações sobre o passado do 
objeto, a transição indica que o objeto está mudando de estado, e uma ação é o detalha-
mento de uma atividade que deve ser executada em determinado momento.
Fonte: adaptado de Sommervile (2011).
explorando Ideias
Não são todas as classes do sistema que apresentam mais de um estado. O diagrama 
de estado a seguir mostra todos os estados do exemplar no momento empréstimo. 
O início do estado é marcado pelo círculo, e o fim é marcado pelo duplo círculo.
Figura 23 - Diagrama de estado / Fonte: os autores. 
U
N
ID
A
D
E 
1
28
Diagrama de comunicação
O diagrama de comunicação permite a identificação das classes mais próximas, e 
a ordem de envio de mensagens é identificada por números sequenciais. A seguir, 
é apresentado o diagrama de comunicação equivalente ao diagrama de sequência 
mostrado anteriormente.
Figura 24 - Diagrama de comunicação (comportamento) / Fonte: os autores. 
Diagrama de atividades
O diagrama de atividade é, em sua essência, um gráfico de fluxo demonstran-
do como ocorre o fluxo de controle entre as atividades. Este diagrama é um dos 
mais detalhistas, dando mais ênfase ao nível de algoritmo.
Os diagramas de atividades podem ser utilizados com vários propósitos. Den-
tre eles, podemos citar a captura do funcionamento interno do objeto, mostrar 
como pode ser executado um conjunto de ações relacionadas e como elas podem 
afetar os objetos ao seu redor.
U
N
IC
ES
U
M
A
R
29
Figura 25 - Diagrama de atividades / Fonte: os autores.Diagramas de estrutura
Os diagramas estruturais são utilizados para especificar, visualizar, documentar e 
construir os aspectos estáticos de um sistema, ou seja, diagramas estruturais repre-
sentam a estrutura estável. A estrutura estática de um sistema envolve a existência 
e a colocação de itens como classes, pacotes, objetos, componentes e utilização.
Diagrama de classes
Após a elaboração do diagrama de caso de uso, podemos modelar a primeira ver-
são do diagrama de classes, pois este mostra a estrutura estática do sistema. Uma 
classe é uma estrutura que modela um conjunto de objetos cujas características 
são similares. A classe, por meio dos métodos, modela o comportamento de seus 
objetos, e os possíveis estados do objeto são modelados por meio de atributos.
U
N
ID
A
D
E 
1
30
Para entendermos melhor, faremos a analogia com a construção de um veícu-
lo. Todos os veículos serão rigorosamente iguais, pois estarão baseados em uma 
planta (projeto) que esclarece o número de portas, a potência do motor, o número 
de marchas do câmbio, entre outros atributos. Portanto, o projeto do veículo é a 
classe, e os veículos são os objetos que foram baseados na classe.
O diagrama de classes a seguir modela a estrutura estática do sistema de bi-
blioteca, apresentado em análise inicial. Por meio do diagrama de caso de uso, a 
classe possibilita a abstração dos objetos mediante os atributos (data: date; nome: 
string...) e métodos (Cria(); Recupera()...). 
Toda notação do diagrama será inteiramente desmistificada na Unidade 3, mas, 
para adiantar, é possível observar, neste diagrama, além das classes, que contêm 
atributos e métodos, as conexões entre as classes, que podem ser uma agregação, 
representada pelo losango, ou uma especialização, representada pelo triângulo.
Figura 26 - Diagrama de classes / Fonte: os autores.
Diagrama de objetos
Os diagramas de objetos correspondem a um segundo nível de abstração do 
diagrama de classes. Não têm a mesma importância que ele, porém podem ser 
uma ótima opção para exemplificar os diagramas de classes mais complexos.
O diagrama de objetos é o diagrama de classes instanciado. Utiliza a mesma 
notação deste para mostrar as instâncias da classe.
U
N
IC
ES
U
M
A
R
31
PESSOA
• Nome: “João da Silva”
• Fone: “(43) 3948-4039
ALUNO
• Curso: “Programação Java”
PROFESSOR
• Disciplina: “Java”
Figura 27 - Diagrama de objetos / Fonte: os autores.
Diagrama de componentes
Um diagrama de componente mostra a organização e dependência entre todos 
os componentes. Seu objetivo é modelar a visão de implementação dos módulos 
executáveis do software.
Apesar de ser um diagrama de alto nível, a organização do sistema é depen-
dente da linguagem de programação utilizada, portanto a solução de desenvol-
vimento adotada refletirá, diretamente, neste diagrama.
Um componente corresponde a uma parte do código distribuível, a qual pode 
ser substituída por outro componente e que contém elementos que mostram um 
conjunto de interfaces fornecidas e requeridas. Podemos apresentar como exemplos 
de componentes: os executáveis, as tabelas, as bibliotecas, o documento e o arquivo.
Figura 28 - Diagrama de componente / Fonte: os autores. 
U
N
ID
A
D
E 
1
32
Diagrama de implantação
Diagramas de implantação são utilizados para modelar a arquitetura física de 
distribuição em que o software será executado. Esse diagrama mostra os nós e 
os relacionamentos de comunicação.
O diagrama de implantação mapeia a arquitetura lógica de classe no nó de 
processamento e suas dependências. Um nó representa um recurso computa-
cional com memória e processamento, ou seja, um disco rígido, um computa-
dor, uma impressora etc. É uma ferramenta importante quando queremos saber 
quais computadores e outros hardwares estão conectados, bem como saber de 
que modo estão distribuídas as classes e quando a atualização de determinado 
arquivo resulta na recompilação de outros.
Figura 29 - Diagrama de implantação / Fonte: os autores.
U
N
IC
ES
U
M
A
R
33
Diagrama de pacotes
O pacote representa um agrupamento de classes, formando uma unidade. Nor-
malmente, os pacotes apresentam relações em que um depende de outro para o 
funcionamento. Como a estrutura de uma aplicação é dada pelas classes e associa-
ções, podemos agrupar as classes em pacotes de análise, o que facilita o manuseio 
do modelo de análise. 
Podemos utilizar o diagrama de pacotes para representar um conjunto de sub-
sistemas, e, neste caso, cada subsistema é representado por um pacote. Dessa forma, 
um pacote pode representar uma biblioteca, um subsistema, um sistema, entre 
outros, e, também, um pacote pode conter outros. Os pacotes, invariavelmente, 
apresentam dependência entre si, o relacionamento de dependência indica que 
o pacote dependente precisa, de alguma forma, daquele outro do qual depende.
Figura 30 - Diagrama de pacotes / Fonte: os autores.
U
N
ID
A
D
E 
1
34
CONSIDERAÇÕES FINAIS
Nesta unidade, aprendemos que a análise é a solução conceitual dada ao proble-
ma. Ela marca o início da definição informática, preocupa-se, principalmente, 
com as classes do domínio do problema e suas relações e, também, com os casos 
de uso. Já o projeto é o resultado do refinamento da análise e considera os detalhes 
da implementação, tais como a linguagem a ser utilizada e o sistema gerenciador 
de banco de dados.
Você se familiarizou com o conceito de Orientação a Objetos, ou, simples-
mente, OO, que é um novo paradigma para o desenvolvimento de aplicações, ou 
seja, é uma estratégia de desenvolvimento de software que organiza este como 
uma coleção de objetos, que contém tanto a estrutura dos dados quanto o com-
portamento deles.
Verificamos que os métodos de análise e projeto orientado a objetos surgiram 
assim que as linguagens de programação OO começaram a se estabilizar, sendo 
que um dos primeiros métodos foi o modelo OOSA, proposto por Shlaer e Mellor, 
em 1988, e o Wirfs-Brock, lançado em 1989, pelo grupo de pesquisa da Smalltalk.
Por meio do estudo da evolução dos métodos, podemos perceber que a UML 
– Unified Modeling Language é a fusão dos métodos de James Rumbaugh/OMT, 
Grady Boock e Ivar Jacobson. A fusão inicia com o trabalho de Rumbaugh e Boo-
ch; em seguida, em meados de 1996, Jacobson integrou-se ao grupo, e lançaram a 
UML versão 0.9. A partir daí, criaram forças com a cooperação da OMG (Object 
Management Group) em julho de 1997, considerado um padrão mundial.
Estudamos as características dos principais métodos OO, e foi possível verificar 
que a maioria das propostas abrangem as fases de análise, projeto, implementação 
e testes. Após conhecermos os principais métodos e estudarmos as suas caracte-
rísticas, entramos em contato com os conceitos de OO, em que aprendemos sobre 
objetos, abstração, classes, operações, atributos, instância, mensagem, entre outros.
Por fim, conhecemos os diagramas utilizados para documentação de software. 
Os diagramas de caso de uso, classes, estado, sequência e colaboração foram apre-
sentados de forma sucinta, já que os veremos com detalhes nas unidades seguintes. 
A partir dos conceitos que foram abordados nesta unidade, conseguimos ter 
uma visão geral sobre a Orientação a Objetos. Agora, você conhecerá as etapas 
da análise e notação para o diagrama de caso de uso.
35
na prática
1. Na análise e no projeto estruturados, o processo a ser informatizado é visto como 
um conjunto de funções com dados de entrada, processamento e dados de saída, ou 
seja, a ênfase está em funções que agem sobre dados. Diferentemente da análise e 
do projeto estruturados, na Orientação a Objetos, o processo a ser informatizado é 
visto como um conjunto de objetos que interagem para realizar as funções. Sabendo 
disso, quais as vantagens do modelo OO?
2. A maior parte dos métodos OO passaram a se tornar estáveis na década de 90, 
com a fusão das metodologias de Grady Boock, James Rumbaugh e Ivar Jacobson 
e a criação da UML, que se baseou, também, em outras metodologias,como a de 
Shlaer-Mellor. Diante do exposto, quais as fases comuns aos métodos propostos 
pelos autores citados?
3. A UML – Unified Modeling Language abrange as fases de levantamento de requisi-
tos, análise, projeto e implementação. É dada como a fusão dos métodos de James 
Rumbaugh/OMT, Grady Boock e Ivar Jacobson. Quais dos conceitos elencados nas 
assertivas são próprios da orientação a objetos?
I - Objetos: qualquer elemento concreto ou abstrato com existência perceptível 
no mundo real.
II - Classes: abstração de um conjunto de objetos.
III - Atributo: característica particular possuída por todos os objetos de uma classe.
IV - Chave primária: identifica, unicamente, um objeto.
É correto o que se afirma em:
a) I, apenas.
b) I e II, apenas.
c) I, II e III, apenas.
d) III e IV, apenas.
e) I, II, III e IV.
36
na prática
4. É comum verificarmos que a documentação do software, na maioria das vezes, não 
tem a devida atenção da equipe de desenvolvimento, por preguiça, ou por falta 
de tempo, ou mesmo por pensar que é uma perda de tempo elaborar inúmeros 
diagramas. Bons softwares, porém, têm documentação que nos permite contar e 
entender a sua história, e contamos esta por meio de diagramas. Sabendo disso, 
quais diagramas são utilizados na UML e como estão organizados?
5. Leia o excerto a seguir e veja quais das alternativas preenche, corretamente, a lacuna:
O diagrama __________ contém as mesmas informações que o diagrama de sequência, 
porém não considera a dimensão temporal. 
Assinale a alternativa correta: 
a) De comunicação.
b) De caso de uso.
c) De classes.
d) De estado. 
e) De pacotes. 
37
aprimore-se
QUALIFICAÇÃO DE SOFTWARES
Como um software pode ser qualificado? É muito simplório definir isto pelo tempo 
de desenvolvimento ou pela excelência na programação. Existem casos de desen-
volvimento de softwares em que o programador ouve todas as informações e apre-
senta uma solução instantânea, quase que “mágica”, algo que resolve perfeitamente 
o que foi apresentado. Vendo desta forma, a sensação é que o atendimento foi 
excepcional, contudo, na maioria dos casos, programas feitos neste formato não 
suprem a real necessidade do cliente.
Não podemos julgar o cliente por não saber apresentar, de forma assertiva, as 
suas necessidades, pois o conhecimento da construção técnica é inexistente ou su-
perficial, não acompanha as tendências do mercado, entre outras hipóteses. E a 
consequência disso tudo é a perda de investimento financeiro e de tempo em um 
projeto que não suprirá a necessidade geral e uma programação desgastante, tanto 
para o programador quanto para o cliente. Casos assim não são exceções, é muito 
provável que você já os tenha vivenciado.
Este problema, porém, não é exclusivo do desenvolvimento de softwares, é cor-
riqueiro no mercado. Para provar isto, basta necessitarmos de um serviço que não 
temos nenhum conhecimento do processo, como consertar um carro. A solução 
só vem quando um profissional qualificado está mais preocupado em satisfazer o 
cliente do que resolver, exclusivamente, o seu problema apresentado. Os profissio-
nais que mantêm este método de atendimento são substituídos aos poucos. 
Na rotina diária de programação, normalmente, o início do projeto vem de uma 
conversa informal, e, só na primeira apresentação, depois de um bom tempo de de-
dicação, é que o cliente consegue esclarecer o que deseja, ainda de forma abstrata, 
por meio de frases como “não é bem isso que eu esperava”. Outro caso comum que 
acontece pela falta de alinhamento é o seguinte: as solicitações do cliente aumen-
tam durante o processo todo, e, como nada é estabelecido de forma clara no início 
do trabalho, você pode até prolongar o projeto, mas, possivelmente, não atenderá a 
todas as necessidades do seu cliente.
38
aprimore-se
Finalizo lembrando que o cliente não tem obrigação de entender como funciona 
toda a programação e que a preocupação em o atender deve ser do programador, 
não o contrário. Um bom profissional precisa “interpretar” a necessidade de um clien-
te e oferecer não o que ele está pedindo, mas, sim, o que suprirá a necessidade dele.
Fonte: o autor.
39
eu recomendo!
Desenvolvendo Software com UML 2.0: definitivo
Autor: Ernani Medeiros
Editora: Makron Books
Sinopse: este livro apresenta, de maneira prática e testada, o que 
é, para que serve e como usar os diagramas da UML 2.0. Além de 
sugerir o melhor momento para pensar em modelagem de banco 
de dados e propor passos dentro do processo de construção de 
software, também aborda parte técnica, notação, semântica, finalidade do con-
ceito e como usá-lo.
livro
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “A história de 
UML e seus diagramas”. Ele descreve a história da UML desde a década de 90 até 
o momento atual. É apresentada a organização dos 13 diagramas de UML, classi-
ficando-os em diagramas estruturais e comportamentais. Os quatro documentos 
pertencentes à especificação também são mencionados e explicados.
https://fdocumentos.tips/document/a-historia-de-uml-e-seus-diagramas.html
conecte-se
2
CASOS
DE USO
PROFESSORES 
Me. Déverson Rogério Rando
Esp. Janaína Aparecida de Freitas
PLANO DE ESTUDO 
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Fases da Análise e do Projeto • 
Modelos de Processo • Requisitos de Software • Diagrama de Casos de Uso.
OBJETIVOS DE APRENDIZAGEM 
Conhecer as fases de análise e projeto • Entender os modelos de processo • Compreender como ocorre 
o levantamento de requisitos • Diferenciar requisitos funcionais de não funcionais • Conhecer o diagra-
ma de caso de uso.
INTRODUÇÃO
Caro(a) aluno(a), iniciamos a segunda unidade do livro Análise e Projeto 
Orientado a Objetos falando sobre as fases da análise e do projeto de software.
Conheceremos cada uma das etapas da análise, que acreditamos ser a 
fase mais difícil e crítica da produção de um software. Difícil porque é o 
momento em que ocorrem as tentativas de delimitar o domínio do proble-
ma e entendê-lo; crítica porque uma análise malfeita comprometerá todas 
as outras fases de produção do software, além do fato de que o produto a 
ser entregue não será aquele que o cliente, inicialmente, requeria.
Entenderemos e conheceremos dois modelos de processos de software, 
dentre os diversos processos existentes. Citaremos, aqui, o modelo em cas-
cata e o evolucionário; em cascata, por ser o primeiro modelo de processo 
a ser utilizado; e evolucionário, por ser um dos modelos mais utilizados, 
principalmente, na fase de aprendizagem do problema. 
Veremos que os requisitos de software são objetivos ou restrições esta-
belecidos por clientes e usuários do sistema, que definem as diversas pro-
priedades dele. Aprenderemos como identificar os “requisitos funcionais”, 
que definem as funções do sistema, e os “requisitos não funcionais”, que 
definem outros tipos de características, os quais o sistema deverá possuir. 
Ainda, veremos a importância do levantamento de requisitos para o 
desenvolvimento de software. Aprenderemos que a definição de requisitos 
pode utilizar uma narrativa ou representações gráficas. Por meio dessas 
definições, pode ser elaborado o documento preliminar de requisitos.
E, finalmente, conheceremos o diagrama de caso de uso, em que enten-
deremos a notação e o objetivo do caso de uso na fase de análise do softwa-
re. Esses diagramas são utilizados para representar, de forma panorâmica, 
os requisitos funcionais de um sistema do ponto de vista do usuário.
Então, o que estamos esperando? Vamos ao trabalho! Boa leitura a todos.
U
N
ID
A
D
E 
2
42
1 
FASES
DA ANÁLISE
e do projeto
Como vimos na primeira unidade, a análise de sistemas é a atividade inicial do 
processo de desenvolvimento de software em que se determina e especifica o que 
um sistema deve fazer, assim como as circunstâncias sob as quais ele deve operar, 
envolvendo, geralmente, esforço colaborativo entre analistas de sistemas e usuá-
rios.De acordo com Sommervile (2011), a análise é realizada com os seguintes 
objetivos em mente: 
 ■ Identificar a necessidade do usuário.
 ■ Executar análise econômica e técnica.
 ■ Atribuir funções a hardware, software, pessoas, banco de dados e demais 
elementos do sistema.
 ■ Estabelecer as restrições de prazo e de custo.
 ■ Criar uma definição de sistema que constitua a base para todo o trabalho 
subsequente.
Independentemente do método ou processo utilizado para a análise, o projeto e 
a implementação, algumas etapas são comuns, são elas (SOMMERVILE, 2011):
 ■ Identificação da necessidade.
 ■ Estudo de viabilidade.
 ■ Análise.
 ■ Projeto (ferramentas).
U
N
IC
ES
U
M
A
R
43
 ■ Implementação (codificação).
 ■ Implantação.
 ■ Manutenção (adaptativa, corretiva e evolutiva).
A seguir, conheceremos cada uma dessas etapas de suma importância para a 
produção de um software de qualidade.
Identificação da necessidade
Comentaremos cada uma dessas etapas começando pela identificação da ne-
cessidade, que é o ponto de partida na evolução de um sistema. Nesta etapa, são 
definidas as metas globais do sistema, respondendo a algumas perguntas-chave:
 ■ Quais informações serão produzidas?
 ■ Quais informações devem ser fornecidas?
 ■ Que funções e desempenho são exigidos?
Ainda nesta etapa, após a definição das metas, o analista deve avaliar:
 ■ Existe tecnologia para construir o sistema?
 ■ Qual é o custo de produção e o tempo necessário para conclusão?
Caso o novo sistema seja um produto a ser desenvolvido para a venda direcio-
nada a muitos clientes, o analista, ainda, deve avaliar o seguinte:
 ■ Qual é o mercado em potencial para o produto?
 ■ Como este produto se compara com os produtos dos concorrentes?
Estudo de viabilidade
Na etapa seguinte, temos a análise de viabilidade, em que o analista deve determi-
nar, rapidamente, se o problema pode ser resolvido considerando cinco aspectos 
de viabilidade: técnico, legal, operacional, temporal e econômico.
No aspecto da viabilidade técnica, o analista deve determinar se o projeto 
pode ser desenvolvido e implementado usando os recursos existentes: computa-
dores, periféricos e sistema operacional. E, também, se existe pessoal competente 
à disposição para desenvolver o sistema em questão (SOMMERVILE, 2011).
U
N
ID
A
D
E 
2
44
No aspecto da viabilidade legal, o analista verifica se não existem conflitos 
entre o sistema em consideração e os compromissos legais que a empresa tem. 
O analista deve considerar as implicações legais que aparecem nos estatutos es-
taduais/federais e nas cláusulas contratuais.
No aspecto operacional, o analista faz a verificação de que o sistema será 
capaz de executar as funções projetadas no ambiente organizacional existente, 
com o pessoal atual.
No aspecto de tempo, o analista deve determinar o cronograma para desen-
volvimento e verificar se o sistema será factível no tempo determinado.
O último aspecto é o da viabilidade econômica, em que o analista deve de-
terminar se os benefícios sobrepõem os custos; se a despesa estimada ultrapassar 
a expectativa da administração ou se os benefícios não justificarem os custos, o 
projeto, provavelmente, será abandonado.
Análise
A coleção exata dos dados é essencial para a análise completa de um sistema, por-
tanto o analista deve considerar os seguintes objetivos (SOMMERVILE, 2011):
 ■ Entender os objetivos do sistema (o que o administrador/usuário espera dele).
 ■ Entender as exigências do sistema (o que processar e que saídas produzir).
 ■ Entender que os objetivos e as exigências são satisfeitos por meio de cui-
dadosa análise. 
 ■ Entender as áreas-problema do sistema.
Para tanto, são utilizadas técnicas para o levantamento de dados, tais como:
 ■ Estudo dos manuais de procedimentos.
 ■ Análise de formulários.
 ■ Entrevista.
 ■ Questionário.
 ■ Observação.
U
N
IC
ES
U
M
A
R
45
Projeto
Após a análise, ou levantamento de requisitos, ou, ainda, engenharia de requisitos 
(como quiser chamar), vem o projeto, que é a solução informática dada ao problema.
De acordo com Sommerville (2011), o projeto de software descreve a es-
trutura do software que será implementado. Nele, estão contidos os dados e a 
interface entre os componentes do sistema. Na primeira versão do projeto, ainda 
não é possível detalhar completamente o sistema, pois, ao elaborar modelos com 
diferentes níveis de abstração, é possível detectar problemas nos níveis anteriores. 
A cada nível seguinte, são criados modelos mais detalhados, diminuindo, cada vez 
mais, a abstração. O projeto de software é importante para formalizar as regras de 
negócio do sistema, melhorando a comunicação entre o cliente e o programador.
Implementação
É neste estágio de desenvolvimento de software em que se cria uma versão exe-
cutável ele, utilizando as ferramentas para desenvolvimento definidas no projeto. 
A implementação pode iniciar após o término do projeto ou pode acontecer de 
forma paralela a ele, tudo depende do modelo de processo escolhido.
Implantação
A implantação corresponde à fase na qual o software será entregue ao cliente. Na 
fase do estudo da viabilidade, foi levantada, pelo analista, a viabilidade técnica, 
em que se buscou verificar se o projeto pode ser desenvolvido e implementado 
usando os recursos existentes: computadores, periféricos, sistema operacional, 
entre outros, e, também, se existe pessoal competente à disposição para desen-
volver o sistema em questão.
Todo o projeto é construído com base no estudo de viabilidade técnica, utili-
zando ferramentas suportadas pelo hardware e entendida pelos usuários, portan-
to os riscos da implantação não funcionar são minimizados no projeto. O fator 
U
N
ID
A
D
E 
2
46
mais preocupante, nesta fase, é, justamente, o período que será necessário para a 
adaptação do usuário com o novo sistema, pois toda mudança gera transtornos, 
na maioria das vezes, o usuário está acostumado a executar suas tarefas de de-
terminada forma, e a mudança é vista com restrição.
Manutenção
A manutenção é o processo de modificar o sistema desenvolvido depois que ele é 
colocado em operação, é a fase do ciclo de vida do software que dura mais tempo, 
até que o sistema deixe de ser utilizado.
O software é continuamente modificado ao longo de seu tempo de duração, 
em resposta a requisitos em constante modificação e às necessidades do cliente. 
As manutenções não dizem respeito somente à correção do software, mas tam-
bém a motivos que não foram possíveis de observar no momento da análise, do 
projeto ou, mesmo, da implementação.
As manutenções podem ser adaptativas, cujo objetivo, como o próprio nome 
diz, é adaptar algumas tarefas ou funções para o ambiente de implantação. As 
manutenções também podem ser evolutivas, cujo objetivo é a inserção de novos 
módulos no sistema.
Projeto é o que quase todo engenheiro quer fazer. É o lugar onde a criatividade impera 
— onde os requisitos dos interessados, as necessidades da aplicação e considerações 
técnicas se juntam na formulação de um produto ou sistema. O projeto cria uma repre-
sentação ou modelo do software, mas diferentemente do modelo de requisitos (que se 
concentra na descrição do “O que” é para ser feito: dos dados, função e comportamento 
necessários), o modelo de projeto indica “O Como” fazer, fornecendo detalhes sobre a ar-
quitetura de software, estruturas de dados, interfaces e componentes fundamentais para 
implementar o sistema. Os engenheiros de software conduzem cada uma das tarefas de 
projeto. Por que é importante? O projeto permite que se modele o sistema ou produto 
a ser construído. O modelo pode ser avaliado em termos de qualidade e aperfeiçoado 
ANTES de o código ser gerado, ou de os testes serem realizados, ou de os usuários finais 
se envolverem com grandes números. 
Fonte: Pressman (2011, p. 206, grifo do autor).
explorando Ideias
U
N
IC
ES
U
M
A
R
47
2 
MODELOS
DE PROCESSO
A análise e o projeto de sistemas de software devem fornecer para os stakeholders,a equipe envolvida, composta pelo cliente, analista, programador, entre outros, 
uma única compreensão do projeto. De acordo com Medeiros (2004), a UML não 
é um método, mas, sim, uma linguagem. Um método é composto por processos 
e um modelo de linguagem. Os processos são os passos que devem ser seguidos 
para construir o projeto. O modelo de linguagem é a notação que o método usa 
para descrever o projeto, enquanto um modelo de processo de software define a 
sequência em que as atividades do processo serão realizadas.
Modelo cascata
Tomaremos como exemplo o mode-
lo de processo em cascata, ou queda 
d’água, como colocado por alguns 
autores.
Figura 1 - Modelo cascata / Fonte: adaptada de 
Sommerville (2011).
U
N
ID
A
D
E 
2
48
Conhecido como ciclo de vida clássico, o modelo em cascata é o primeiro a ser 
publicado do processo de desenvolvimento de software. O modelo considera as 
atividades de especificação, desenvolvimento, validação e evolução como fases 
separadas do processo.
A primeira fase é a análise e definição de requisitos (especificação de requi-
sitos). As funções, as restrições e os objetivos do sistema são estabelecidos por 
meio da consulta aos usuários.
A segunda fase é o projeto de sistemas e de software, em que os requisitos em 
sistemas de hardware ou de software são agrupados, estabelecendo uma arqui-
tetura do sistema geral.
A terceira fase é a implementação e o teste de unidades. Durante este estágio, 
o projeto de software é compreendido como um conjunto de programas ou de 
unidades de programa. O teste de unidade envolve verificar que cada unidade 
atende à sua especificação.
A quarta fase é a integração e o teste de sistemas. Neste estágio, as unidades de 
programa ou programas individuais são integrados e testados como um sistema 
completo, a fim de garantir que os requisitos de software foram atendidos.
A quinta fase é a operação e manutenção. Normalmente, esta é a fase mais longa 
do ciclo de vida. O sistema é instalado e colocado em operação. A manutenção envolve 
corrigir erros que não foram descobertos em estágios anteriores do ciclo de vida ou 
aumentar as funções desse sistema à medida que novos requisitos são descobertos.
Neste modelo de processo em cascata, pressupõe-se que o domínio do pro-
blema foi inteiramente compreendido, portanto é o modelo indicado quando 
conhecemos por inteiro a regra de negócio do software.
Modelo evolucionário
Quando estamos produzindo um software e ainda não conhecemos todo o do-
mínio do problema, é recomendável a utilização do modelo de desenvolvimento 
evolucionário. Este tem, como base, a ideia de desenvolver uma implementação 
inicial, expor o resultado ao comentário do usuário e fazer seu aprimoramento por 
meio de muitas versões, até que um sistema adequado seja desenvolvido.
Em vez de ter as atividades de especificação, desenvolvimento e validação em 
separado, todo esse trabalho é realizado concorrentemente, com rápido feedback 
por meio dessas atividades. A Figura 2 ilustra bem as fases do modelo evolucionário.
U
N
IC
ES
U
M
A
R
49
Figura 2 - Modelo evolucionário / Fonte: adaptada de Sommerville (2011).
Devido à característica de produzir sistemas que atendam às necessidades ime-
diatas do usuário, muitas vezes, o modelo evolucionário é mais eficaz do que a 
abordagem em cascata. A vantagem da abordagem evolucionária está na espe-
cificação, que pode ser desenvolvida gradualmente, à medida que os usuários 
compreendem melhor o problema.
Como nem tudo são flores, porém, problemas acontecem nesse modelo; enu-
meraremos alguns deles:
 ■ Como os sistemas são desenvolvidos rapidamente, não é viável produzir 
documentos que reflitam cada versão do sistema.
 ■ Os sistemas, frequentemente, são mal estruturados. A mudança constan-
te tende a corromper a estrutura do software, incorporar modificações 
torna-se cada vez mais difícil e oneroso.
Utilizando o modelo em cascata, ou o evolucionário ou qualquer outro modelo 
de desenvolvimento, é possível, nas fases de análise e projeto, optar por uma 
abordagem de análise e projeto estruturado, dessa forma, construiremos Diagra-
mas de Entidade-Relacionamento (DER), Diagrama de Fluxo de Dados (DFD), 
diagrama de contexto, dicionário de dados etc. Esses modelos fornecem uma 
compreensão única do projeto.
O foco da nossa disciplina, contudo, é a orientação a objetos, portanto, nas 
fases de análise e projeto, construiremos diagramas de caso de uso, de classes, de 
estado, de sequência etc. Esses modelos também fornecerão uma compreensão 
única do projeto.
U
N
ID
A
D
E 
2
50
Linguagem de modelagem – UML
A linguagem de modelagem é uma parte muito importante do método. Corresponde 
ao ponto principal da comunicação. Se uma pessoa quer conversar sobre o projeto 
com outra pessoa, é por meio da linguagem de modelagem que elas se entendem.
A UML define uma notação e um meta-modelo. Todos os elementos de repre-
sentação gráfica vistos no modelo (retângulo, setas, texto etc.) são a notação, essa 
é a sintaxe da linguagem de modelagem. A notação do diagrama de classes define 
a representação de itens e conceitos, tais como: classe, associação e multiplicidade. 
Visto isto, é possível concluir que, independentemente do modelo de processo de 
software que você escolheu, é de suma importância que o domínio do problema 
seja entendido por todos da equipe de desenvolvimento, inclusive o cliente.
A figura a seguir ilustra, de forma lúdica, o que ocorre em um projeto de 
software em que a equipe de desenvolvimento e o cliente não se entendem. 
U
N
IC
ES
U
M
A
R
51
Figura 3 - Charge sobre projeto de software / Fonte: Ampersand (2013, on-line, traduzido 
pelo autor)1.
Pense em quais habilidades o analista deve possuir, uma vez que lida com vários grupos 
de usuários, além de se preocupar com o desenvolvimento e com todos os componentes 
do sistema.
pensando juntos
U
N
ID
A
D
E 
2
52
3 
REQUISITOS
DE SOFTWARE
Agora que já sabemos a importância da análise e do projeto na produção de um 
software, conheceremos os procedimentos mínimos necessários para a obtenção 
de um software de qualidade.
Para tal, precisamos fazer uma engenharia de requisitos, mas o que é isso? 
Vamos por partes, então. O termo “engenharia” permite dizer que se utiliza um 
processo sistemático na definição do software. Nesse contexto, a engenharia de 
requisitos tem, como objetivo, compreender o sistema, ou seja, preocupa-se com 
“o que fazer”, e não com o “como fazer”. As principais atividades da engenharia de 
requisitos são (SOMMERVILE, 2011):
 ■ Especificar o problema (elicitar).
 ■ Compreender o problema (analisar).
 ■ Definir uma proposta (modelo válido).
 ■ Atualizar requisitos (gerenciar).
Na primeira atividade, que é elicitar, devemos obter o máximo de informações 
para o conhecimento do objeto em questão dentro do domínio do problema.
U
N
IC
ES
U
M
A
R
53
Domínio 
O que é domínio? Para entender melhor, imaginaremos que você foi contrata-
do(a) para desenvolver um software em determinada Casa de Carnes. Do lado 
direito da Casa de Carnes, existe uma farmácia, do lado esquerdo, um mercado, 
atrás, uma lanchonete e, em frente, uma igreja. Neste caso, o domínio do seu 
problema é a Casa de Carnes, os demais estabelecimentos estão na fronteira do 
seu problema, portanto não fazem parte dele. Creio que, dessa forma, fica fácil 
compreender o que é o domínio do problema.
É óbvio que determinar o domínio do problema não é uma tarefa trivial, pois 
você pode ser contratado(a) para desenvolver um software para determinado 
departamento de uma empresa, dessa forma, determinar esse domínio se torna 
mais complexo.
Sendo assim, os limites do domínio (fronteira) podem ser determinados por 
meio do estabelecimento dos objetivos pretendidos. Para tanto, não devemos 
centrar em funcionalidades, mas, sim, em finalidade.
Requisitos
Os requisitos são os objetivos e as restrições estabelecidas pelo usuário do sis-
tema. É o usuário ou o cliente o responsável por descreveras necessidades ou 
o desejo para o software (SOMMERVILE, 2011). Em um primeiro momento, é 
interessante definir os requisitos sem se preocupar em detalhá-los, isto permite 
ter uma visão global do domínio de maneira mais rápida.
Para a definição de requisitos, produzimos um documento contendo decla-
rações, em linguagem de alto nível, dos requisitos e restrições do sistema. Já na 
especificação, produzimos um documento estruturado contendo requisitos e 
restrições descritos detalhadamente. Vamos aos exemplos.
U
N
ID
A
D
E 
2
54
Definições de requisitos:
1. O software deve proporcionar um meio para representar e acessar arquivos exter-
nos criados por outros aplicativos.
Especificação de requisitos:
1.1. O usuário deverá ser provido de recursos que permitam definir os tipos de arqui-
vos externos que serão acessados.
1.2. Para cada tipo de arquivo externo, deve ser associado o aplicativo que o gerou.
1.3. A cada tipo de arquivo externo, deve ser associado um ícone específico.
1.4. Deverá ser permitido ao usuário definir os ícones que serão utilizados na repre-
sentação dos arquivos externos.
Quadro 1 - Exemplos de definições e especificação de requisitos / Fonte: o autor.
Na definição de requisitos, pode-se utilizar uma narrativa ou representações grá-
ficas. Normalmente, as informações coletadas são fornecidas pelo usuário. Por 
meio dessas definições, pode ser elaborado o documento preliminar de requisitos. 
Eles podem ser divididos em: 
 ■ Requisitos funcionais (RF).
 ■ Requisitos não funcionais (RNF).
Os requisitos funcionais definem as funções do sistema, ou seja, o que se espera 
que o sistema faça. Eles relatam as diversas funções que deverão ser providas pelo 
software ao cliente ou usuário. Por exemplo:
 ■ Monitorar sensores de temperatura.
 ■ Cancelar o débito na conta corrente caso a operação não seja completada.
 ■ Avisar quando o estoque chegar ao limite mínimo.
Os requisitos não funcionais estão relacionados às tecnologias utilizadas, à usa-
bilidade, ao desempenho, à segurança, confiabilidade, manuteniblidade e dispo-
nibilidade que o sistema deverá possuir. Por exemplo:
 ■ O sistema deverá apresentar interface gráfica (padrão Windows).
 ■ Facilidade de uso.
 ■ Possibilidade de ajuda no contexto.
U
N
IC
ES
U
M
A
R
55
A partir das definições dos requisitos, produzimos o documento preliminar deles, 
que deve conter todos os serviços (requisitos) requeridos pelo cliente, explicitados 
de forma clara, sem contradições. Atingir este objetivo é uma tarefa difícil pelas 
inúmeras dificuldades que são encontradas no domínio. Mas, para que essas 
dificuldades sejam superadas, o documento preliminar de requisitos deve conter 
algumas características de qualidade. Segundo Pressman (1995), são elas:
Característica 1 – Precisam ser corretas: cada declaração de requisito deve 
expressar, exatamente, a funcionalidade almejada. Declarações de requisitos 
que conflitam com suas respectivas necessidades não estão corretas, apenas 
o usuário pode determinar se a declaração está correta por meio de inspe-
ções. Inspeções em que não há a participação do usuário podem tornar o 
documento de requisitos um documento de adivinhações.
Característica 2 – Precisam ser possíveis: você deve ser hábil em imple-
mentar cada requisito declarado, observando os recursos e as limitações do 
sistema e ambiente. Para evitar requisitos impossíveis, trabalhe, com o pes-
soal técnico, o documento de requisitos, checando o que é ou não possível 
fazer, avaliando custos e viabilidade.
Característica 3 – Precisam ser necessários para o projeto: cada declaração 
de requisito deve documentar apenas as necessidades do cliente ou qualquer 
outra necessidade que exija atender a um requisito externo, ou a uma interfa-
ce externa ou, ainda, um padrão. Você pode pensar que “necessário” significa 
cada requisito com origem na fonte que tem autoridade para determiná-lo.
Característica 4 – É necessário definir prioridades: atribua uma prioridade 
de implementação para cada requisito, ou, ainda, defina casos de uso que 
auxiliem na indicação do quanto é essencial um requisito para o produto. 
Clientes devem ter sua parte na responsabilidade do estabelecimento de 
prioridades. Se todos os requisitos forem igualmente prioritários, você deve 
ter a habilidade de definir com o cliente a prioridade de cada um.
U
N
ID
A
D
E 
2
56
Característica 5 – Não podem ser ambíguas: cada declaração deve ser ex-
plicitada de maneira que permita somente uma interpretação. Linguagem 
natural é altamente propensa a ambiguidades, elimine termos subjetivos, 
como: amigável ao usuário, fácil, simples, rápido, eficiente, vários, aperfeiçoar, 
maximizar e minimizar. Escreva cada requisito na linguagem do cliente de 
forma sucinta, simples, direta, sem utilizar jargões técnicos.
Característica 6 – Precisam ser verificáveis: veja se é possível aplicar tes-
tes ou utilizar outras abordagens para verificações, tais como inspeções ou 
demonstrações para se certificar de que cada requisito será implementado 
apropriadamente. Requisitos que não são consistentes, possíveis ou despro-
vidos de ambiguidades também não são verificáveis.
Após o estágio de elicitação (extração), um documento contendo os requisitos 
do cliente (necessidades, restrições, objetivos etc.) é definido. Esse documento, 
que poderíamos chamar de Documento Preliminar de Requisitos, deverá sofrer 
um processo de análise.
A fase de análise, por sua vez, envolve uma série de atividades (SOMMER-
VILE, 2011):
 ■ Validação e verificação.
 ■ Análise de viabilidade.
 ■ Resolução de conflitos.
 ■ Definição de prioridade.
Os requisitos coletados devem ser verificados e validados, com o objetivo de garantir 
se estão completos, consistentes e de acordo com as reais necessidades do domínio. 
Assim como nos demais procedimentos da análise de requisitos, a participação dos 
interessados deve ser intensa, ou seja, todos os agentes que, direta ou indiretamente, 
influenciam os requisitos do sistema precisam estar envolvidos nesse processo.
U
N
IC
ES
U
M
A
R
57
Os casos de uso têm um papel importantíssimo na análise de requisitos, pois 
permitem criar um cenário do domínio, e, talvez, este seja o único instrumento 
que acompanha o software do início até seu término, além disso, casos de uso 
representam funcionalidades completas para o usuário e não funcionalidades 
internas do sistema. Outro ponto importante é que o diagrama de casos de uso 
é um artefato de comunicação entre cliente, usuários e desenvolvedores. Por ser 
extremamente simples e, consequentemente, de fácil compreensão, incentiva a 
participação do cliente e dos usuários no processo de desenvolvimento, também 
serve como um contrato entre a equipe desenvolvedora e o cliente.
A coleção de casos de uso representa todos os modos pelos quais o sistema 
pode ser utilizado pelos atores envolvidos. Um caso de uso é uma sequência de 
ações realizada, colaborativamente, pelos atores envolvidos e pelo sistema que 
produz um resultado significativo (com valor) para os atores, e estes podem ser 
um usuário ou outro sistema. 
O diagrama de casos de uso é apenas um panorama visual das funciona-
lidades do sistema, é necessária uma descrição textual para detalhar os casos. 
Portanto, a saída da fase de análise de requisitos é composta por:
 ■ Lista de requisitos funcionais e não funcionais.
 ■ Diagrama de casos de uso e definições textuais dos casos.
A especificação de requisitos é o processo de escrever os requisitos de usuário e de sis-
tema em um documento de requisitos. Idealmente, os requisitos de usuário e de sistema 
devem ser claros, inequívocos, de fácil compreensão, completos e consistentes. Na práti-
ca, isso é difícil de conseguir, pois os stakeholders interpretam os requisitos de maneiras 
diferentes, e, muitas vezes, notam-se conflitos e inconsistências inerentes aos requisitos. 
Os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não 
funcionais de modo que sejam compreensíveispara os usuários do sistema que não te-
nham conhecimentos técnicos detalhados. Idealmente, eles devem especificar somente o 
comportamento externo do sistema. O documento de requisitos não deve incluir detalhes 
da arquitetura ou projeto do sistema. 
Fonte: Sommerville (2011, p. 65).
explorando Ideias
U
N
ID
A
D
E 
2
58
4 
DIAGRAMA
DE CASOS DE USO
Agora que já conhecemos o contexto de requisito de software, vamos para a con-
fecção do diagrama de caso de uso. O modelo de casos de uso (que é mais do que 
o diagrama) é o principal resultado da fase de análise de requisitos, e, também, 
diagramas de casos de uso são utilizados para representar, de forma panorâmica, 
os requisitos funcionais de um sistema do ponto de vista do usuário. 
O modelo de caso de uso é um diagrama utilizado na análise de requisitos 
com objetivos claros:
 ■ Compreender o problema (elicitar).
 ■ Delimitar o sistema (domínio).
 ■ Definir as funcionalidades oferecidas ao usuário (não precisamos nos 
preocupar, neste momento, com a implementação).
Conhecer a notação para os diagramas de caso de uso preconizados pela UML. 
Os elementos básicos deste diagrama são:
 ■ Atores.
 ■ Casos de uso.
 ■ Relações entre atores e casos de uso.
U
N
IC
ES
U
M
A
R
59
Atores
Começaremos, então, pelo homem palito, que representa um 
ator no meu sistema. Esse ator pode ser uma pessoa, outro sis-
tema ou uma entidade externa ao sistema. 
Como encontrar os atores para um sistema? Usando as 
seguintes dicas:
 ■ Examine o problema procurando por pessoas ou sis-
temas do entorno.
 ■ Faça as seguintes perguntas:
 ■ Quais são as pessoas ou os departamentos interessados em determi-
nado requisito funcional?
 ■ Quem suprirá o sistema com informações e quem receberá informa-
ções dele?
 ■ Quais os recursos externos utilizados pelo sistema?
 ■ Uma pessoa desempenha diferentes papéis?
 ■ O sistema interage com outros sistemas existentes?
Essas dicas também não garantem que o ator foi bem escolhido da primeira vez, 
pois este é um processo iterativo; dificilmente, a primeira tentativa será a definitiva. 
Figura 4 - O ator /
Fonte: os autores. 
Os casos de uso são documentados por um diagrama de casos de uso de alto nível. O 
conjunto de casos de uso representa todas as possíveis interações que serão descritas 
nos requisitos de sistema. Atores, que podem ser pessoas ou outros sistemas, são repre-
sentados como figuras “palito”. Cada classe de interação é representada por uma elipse. 
Linhas fazem a ligação entre os atores e a interação. Opcionalmente, pontas de flechas 
podem ser adicionadas às linhas para mostrar como a interação se inicia. Não há distin-
ção entre cenários e casos de uso que seja simples e rápida. Algumas pessoas consideram 
cada caso de uso um cenário único; outros, encapsulam um conjunto de cenários em um 
único caso de uso. Cada cenário é um segmento através do caso de uso. Portanto, seria 
um cenário para a interação normal, além de cenários para cada possível exceção. Você 
pode, na prática, usá-los de qualquer forma.
Fonte: Sommerville (2011, p. 74).
explorando Ideias
U
N
ID
A
D
E 
2
60
Casos de uso
A coleção de casos de uso representa, do ponto de vista do usuário, todos os 
modos de execução do sistema. Um caso de uso é uma sequência de ações que 
produz um resultado significativo para um ator, e, assim, são necessárias as se-
guintes definições:
 ■ As tarefas de cada ator.
 ■ Quais informações o ator obtém do sistema.
 ■ Quem fornece as informações.
 ■ Quem captura as informações.
 ■ Se algum ator precisa ser informado sobre eventos produzidos pelo sistema.
 ■ Se existem eventos externos que devem ser notificados ao sistema.
A elipse é a notação para os casos de uso, ou use case, na verdade, as duas denomi-
nações são utilizadas. Um caso de uso representa uma atividade que o ator realiza.
O caso de uso necessita de uma descri-
ção, porém, não há descrição padrão 
definida pela UML. Em geral, o diagra-
ma é bastante informal e sua estrutura-
ção (relação entre casos) não deve ser 
levada ao extremo. É importante ressal-
tar que o diagrama de casos de uso é 
uma forma de visualizar os casos, e não 
de descrevê-los detalhadamente.
Sendo assim, o diagrama, por si só, não é suficiente. Os casos de uso devem vir 
acompanhados de uma descrição em que, normalmente, relacionamos os se-
guintes itens:
 ■ Nome.
 ■ Descrição.
 ■ Requisitos funcionais providos pelo caso de uso.
 ■ Restrições, tais como pré e pós-condições.
Figura 5 - Caso de uso / Fonte: os autores.
U
N
IC
ES
U
M
A
R
61
 ■ Pré-condições: define o que deve ser verdadeiro para que o caso de uso 
seja iniciado. Por exemplo, em um sistema para seguro de veículo, para o 
caso de uso Fazer Seguro Veicular, uma pré-condição é apresentar a CNH. 
 ■ Pós-condições: o que se torna verdadeiro pela execução do caso de uso. No 
mesmo caso anterior, o sistema pode se encontrar em um dos seguintes es-
tados: seguro concedido ou seguro não concedido por reprovação da CNH.
 ■ Invariantes: condições que são verdadeiras durante a execução do caso de uso.
 ■ Fluxos de eventos: descrição de interações entre atores e sistema que ocor-
rem durante a execução do caso de uso.
 ■ Outras informações: data, autor etc.
Relações de dependência
As relações de dependência são representadas por uma seta tracejada, ela parte 
do caso de uso que depende de outro em algum momento. O diagrama da Figura 
6 nos diz que, para o cadastro de aluno, é necessária a conclusão do cadastro de 
pessoa.
´
Figura 6 - Dependência / Fonte: os autores. 
Se um caso de uso inclui o comportamento de outro, então dizemos que um usa 
o outro. Aqui, a linha tracejada com uma seta também pode representar uma 
inclusão de outro caso de uso. No exemplo da Figura 7, o caso de uso Calcular 
Contas a Receber utilizará a forma de cálculo que está na documentação de Cal-
cular Contas a Pagar; usamos este artifício para evitar a necessidade de digitar 
duas vezes a mesma especificação.
U
N
ID
A
D
E 
2
62
<<include>>
Calcular contas
a pagar
Calcular contas
receber
Figura 7 - Inclusão / Fonte: os autores.
Já as extensões adicionam um comportamento a um caso de uso que descreve 
uma variação do comportamento normal. Nesta situação, o caso de uso base 
pode ser executado mesmo sem a extensão. O modelo da Figura 8 mostra que 
existe um cálculo em Calcular Descontos que se estenderá para Calcular Contas 
a Pagar, ampliando o significado da fórmula existente em Calcular Descontos.
Figura 8 - Extensão / Fonte: os autores.
Vale lembrar que o diagrama de casos de uso é apenas um panorama visual das 
funcionalidades do sistema; é necessária uma descrição textual para detalhar os 
casos de uso. 
Ilustraremos esta documentação, por meio do caso de uso, para resolver ex-
pressões aritméticas.
Figura 9 - Diagrama de caso de uso / Fonte: os autores.
U
N
IC
ES
U
M
A
R
63
Podemos fazer a descrição textual para o caso de uso Resolver Expressões Arit-
méticas de acordo com o quadro a seguir:
Nome do caso de uso Resolver Expressões Aritméticas.
Descrição
Permite resolver expressões envolvendo 
números inteiros e reais e as operações 
básicas de soma, subtração, multiplica-
ção e divisão.
Ator Aluno.
Pré-condições O sistema deve estar em execução.
Pós-condições
Expressão aritmética resolvida ou cance-
lamento da operação pelo aluno.
Fluxo básico
Usuário Sistema
{Solicita expressão}
Solicita a expressão (A2).
Fornece a expressão
{Valida a expressão}
Avalia se a expressão é sintaticamente 
correta (A1).
{Calcula valor}
Calcula o valor da expressão.
{Mostra o resultado}
Informa o resultado da expressão.
{Fim}
Fim do caso de uso.
U
N
ID
A
D
E 
2
64
Fluxos alternativos
A1: em {Valida expressão}
Se o usuário fornecer uma expressão 
sintaticamente incorreta, informá-lo so-
bre o erro e retornar ao fluxo básico em 
{Solicita expressão}
A2: em {Solicita expressão}
O usuário pode decidir encerrar o caso de 
uso sem fornecer uma expressão. Neste 
caso, retornarao fluxo básico em {Fim}
Quadro 2 - Resolver Expressões Aritméticas / Fonte: os autores.
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; isso 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, cujo 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 cami-
nho entre muitos possíveis, visto que um caso de uso pode ser executado de vários 
modos. Existem os fluxos básicos, que demonstram o fluxo normal de eventos, e 
os alternativos, que dizem o que fazer, caso não seja possível seguir o fluxo básico. 
Para exemplificar, inspiraremo-nos na situação em que uma pessoa explica 
um caminho à outra. Primeiro, o fluxo básico é explicado, depois, o fluxo alter-
nativo. No caso de uso 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. 
U
N
IC
ES
U
M
A
R
65
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 do respectivo ambiente. Vimos que, independentemente 
do método ou processo utilizado para a análise, projeto e implementação, algu-
mas 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 construí-lo.
Familiarizamo-nos com dois modelos de processo de software: o cascata e 
o evolucionário. Verificamos que o modelo cascata é indicado quando conhe-
cemos 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 conclusão da anterior. Já 
o modelo evolucionário é indicado quando temos que aprender sobre o domínio 
e o problema no desenvolvimento da aplicação, resultando em várias 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 eles serão consistentes, completos e relevantes. Vimos, 
também, que a engenharia de requisitos é de suma importância, pois é nesta fase 
que especificamos o problema, bem como 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 preocuparmos 
com a implementação.
66
na prática
1. Quais são objetivos que 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 desenvolvimento 
e o cliente não se entendem?
6. O que são requisitos de software e como podemos classificá-los?
67
aprimore-se
COMO FAZER UM PLANO DE TESTES BASEADO EM CASOS DE USO
Qual é a função primordial de qualquer software desenvolvido? A questão parece 
simples, mas respondo que é ter acessibilidade, e, para que isto seja possível, hoje, é 
obrigatório testá-lo adequadamente. Conheceremos uma forma sistêmica de mon-
tar 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 
funcionalidades que compõem o escopo do software que está sendo desenvolvido. 
Agora, você se pergunta: onde está descrito esse escopo? Normalmente, ele pode 
estar na proposta do projeto, na especificação funcional e, em muitos projetos, nos 
casos de uso.
Eduardo Ernandes da Silva, no artigo intitulado “Como fazer um plano de testes 
baseado em casos de uso” ([2020], on-line)2, 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 
desenvolvedor, o que codificar; ao testador ou certificador, o que validar para garan-
tir a qualidade dos entregáveis.
Desse modo, podemos concluir que os casos de uso ajudam na certificação e 
validação dos requisitos implementados, simplificando e sistematizando o processo 
de teste do software, permitindo ganho de produtividade e ajudando na garantia de 
que todo o escopo 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, o autor classifica várias utilidades e destaca qua-
tro procedimentos que podemos seguir:
68
aprimore-se
 ■ Selecione o caso de uso que será testado, identifique o fluxo principal e os fluxos 
alternativos e desenhe um diagrama de atividades. Desse modo, você consegui-
rá visualizar, mais facilmente, todos os cenários que o usuário pode utilizar.
 ■ Agora que já identificou os cenários, você começará a escrever um caso de 
teste para cada cenário, detalhando todos os passos do cenário. Desse modo, 
o testador poderá executar as ações do ator e validar se a resposta do siste-
ma está de acordo com o que foi especificado.
 ■ Para iniciar os testes, será necessária a criação de uma base de dados de 
certificaçã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, de-
feitos e correções, e armazenar esta informação em algum meio permanente. 
Isto servirá para avaliar a qualidade de cada desenvolvedor da sua equipe.
Dessa maneira, podemos concluir que usar os casos de uso como modelo para os 
testes permitirá a visão mais apurada do software, bem como mais noção das ne-
cessidades dos clientes. 
Fonte: adaptado de Silva ([2020], on-line)2.
69
eu recomendo!
Fundamentos do Desenho Orientado a Objeto com UML
Autor: 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 me-
lhores práticas quanto ao desenvolvimento de OO para melhorar 
o seu código e o seu índice de sucesso em projetos fundamentados em objetos.
livroPara aprofundar os conhecimentos sobre OO, leia o artigo intitulado “Em busca 
de um modelo de referência para engenharia de requisitos em ambientes de de-
senvolvimento distribuído de software”. Este 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.
http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER03/leandro_audy.pdf 
conecte-se
3
DIAGRAMA
DE CLASSES
PROFESSORES 
Me. Déverson Rogério Rando
Esp. Janaína Aparecida de Freitas
PLANO DE ESTUDO 
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Diagrama de Classes • Notação 
para Classes • Atributos e Métodos • Multiplicidade entre as Associações de Classes • Tipos de Associação 
entre Xlasses • Herança Múltipla.
OBJETIVOS DE APRENDIZAGEM 
Entender o objetivo do diagrama de classes • Conhecer a notação UML para 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.
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 unidade. 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 dia-
grama de classes, além das convenções para os nomes das classes, atributos 
e métodos, veremos, também, as várias formas de notação para o diagrama 
de classes. A classe tem a função de individualizar o objeto (qualquer ele-
mento concreto ou abstrato) por meio de suas características (atributos) 
e comportamentos (métodos). Sendo assim, aprenderemos a sintaxe, ou 
seja, como construir a linha de declaração para os atributos e métodos, 
bem como conheceremos os tipos de dados primitivos.
Veremos que existem várias formas de associação de classes, e tais as-
sociações fazem surgir o conceito de multiplicidade. Esta é o resultado da 
necessidade de associação entre as classes, além disso, a multiplicidade nos 
mostra a cardinalidade de uma associação. Veremos, também, as várias for-
mas de associação entre classes, entre elas, a unária, a binária, a agregação 
regular e a composição, a generalização e as classes associativas.
Aprenderemos, também, que, na herança múltipla, uma subclasse é 
derivada de mais de uma superclasse, a qual evidencia somente uma parte 
do conceito representado 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.
Mesmo mais complexa, porém, a herança múltipla tem a vantagem de 
oferecer mais capacidade de especificação de classes e mais oportunidade 
de reutilização. A desvantagem é, justamente, como já citamos, a perda em 
simplicidade conceitual e implementação. 
Então, o que estamos esperando? Vamos ao trabalho! Boa leitura a todos.
U
N
ID
A
D
E 
3
72
1 
DIAGRAMA
DE CLASSES
Como vimos, após a elaboração do diagrama de caso de uso, podemos modelar a 
primeira versão do diagrama de classes, o qual 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 classificados 
como pertencentes a um mesmo tipo.
Objeto é qualquer elemento concreto ou abstrato com existência perceptí-
vel no mundo real e que possa ser individualizado por possuir características e 
comportamento próprio.
Na Figura 1, temos o exemplo de objetos de mundo real que, na verdade, são 
funcionários com características em comum, por exemplo: todos os funcionários 
possuem nome, endereço e telefone, dessa forma, podemos abstrair para criar um 
objeto conceitual a partir dos objetos do mundo real.
U
N
IC
ES
U
M
A
R
73
Figura 1 - Objetos do mundo real / Fonte: os autores. 
Uma classe é uma estrutura que modela um conjunto de objetos cujas caracterís-
ticas 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 atribu-
tos. As classes, juntamente com os atributos, as operações e associações, são de-
finidas em um diagrama de classe. Porém, não existe uma receita ou um método 
para a escolha das classes do sistema, esta tarefa depende, fundamentalmente, da 
experiência do desenvolvedor.
No início do projeto, as classes são denominadas “candidatas” ou “análise”, pois 
existe uma probabilidade muito grande de que mudem ao longo dele. Antes de 
aprendermos como fazer, apresento a notação para classes.
Os diagramas de classe são usados no desenvolvimento de um modelo de sistema orien-
tado a objetos para mostrar as classes de um sistema e as associações entre essas classes. 
Em poucas palavras, uma classe de objeto pode ser pensada como uma definição geral de 
um tipo de objeto do sistema. Uma associação é um link entre classes que indica algum 
relacionamento entre essas classes. Consequentemente, cada classe pode precisar de al-
gum conhecimento sobre sua classe associada. Quando você está desenvolvendo modelos, 
durante os estágios iniciais do processo de engenharia de software, os objetos representam 
algo no mundo real, como um paciente, uma receita médica, um médico etc. Enquanto uma 
aplicação é desenvolvida, geralmente é necessário definir objetos adicionais de implemen-
tação que são usados para fornecer a funcionalidade requerida do sistema. 
Fonte: Sommerville (2011, p. 90).
explorando Ideias
U
N
ID
A
D
E 
3
74
2 
NOTAÇÃO
PARA CLASSES
Uma classe é representada por um retângulo e 
pode ser apresentada somente com o seu estereóti-
po (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 (ca-
racteres de língua de origem latina, como caracteres acentuados). Portanto, não 
é possível declarar uma classe com qualquer caractere especial (@, #, $, %, &, *, 
_ etc.). Caso o nome de uma classe seja composto por mais de uma palavra, a 
primeira letra de cada uma delas deve ser maiúscula. 
A classe também pode ser apresentada como um 
retângulo com dois compartimentos, em que o pri-
meiro contém o nome da classe, e o segundo contém 
os atributos juntamente com seu tipo de dados.
Aluno
Figura 2 - Notação simplifica-
da de uma classe / Fonte: os 
autores.
Aluno
- Nome : String
- Endereco : String
- Data_nasc : Date
Figura 3 - Notação com nome 
da classe e atributos / Fonte: 
os autores.
U
N
IC
ES
U
M
A
R
75
Por fim, a classe também pode ser 
apresentada em um retângulo divi-
dido em três compartimentos, como 
ilustra a Figura 4. 
Figura 4 - Notação com nome, atributos e mé-
todos / Fonte: os autores.
Uma classe abstrata não gera objetos, porque, geralmente, ela tem, no mínimo, uma ope-
ração abstrata nela definida. Se ela, na verdade, criasse um objeto, uma mensagem invo-
cando a operação abstrata do objeto provocaria um erro de run-time. 
(Ian Sommerville)
pensando juntos
U
N
ID
A
D
E 
3
76
3 
ATRIBUTOS 
E MÉTODOS
Atributos 
O dicionário Michaelis ([2020], on-line)3 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 e, também, 
são denominados variáveis de classe. O atributo é um elemento da classe que 
pode representar uma característica dos objetos instanciados.
A sintaxe (assinatura) para declaração de um atributo em UML tem o se-
guinte formato:[<visibilidade>]<nome>:[<tipo>][=<valor inicial>]
Figura 5 - Sintaxe para declaração de um atributo em UML / Fonte: os autores.
Entenderemos, agora, cada um dos elementos da sintaxe. Gostaria de abrir um 
parêntese 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.
U
N
IC
ES
U
M
A
R
77
<visibilidade>
A visibilidade nos informa quais são as classes que podem ver esse atributo. Te-
mos 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.
Quadro 1 - Representação da visibilidade e seu significado / Fonte: os autores.
<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, cedilhas etc.).
 ■ 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 uma delas deve ser em maiúscula.
<tipo>
Pode-se utilizar os tipos da linguagem de programação de implementação. Lis-
taremos alguns tipos primitivos e, 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.
U
N
ID
A
D
E 
3
78
 ■ Int: 4 bytes.
 ■ Long: 8 bytes.
 ■ Reais em ponto flutuante: igual aos inteiros, também diferem nas preci-
sõ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. 
Na Figura 6, podemos observar que o 
atributo nome tem visibilidade privada, ou 
seja, somente os métodos desta classe pode-
rão realizar operações com esse atributo. O 
atributo sexo é protegido, podendo ser vis-
to somente nesta classe ou em classes deri-
vadas, observe que esse atributo é iniciado 
com o valor ‘F’, que implica dizer que sem-
pre 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.
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 aos 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.
Figura 6 - Classe com os compartimentos 
de nome e atributos / Fonte: os autores.
U
N
IC
ES
U
M
A
R
79
A sintaxe para declaração de um método é semelhante à declaração de atri-
butos, vamos lá:
[<visibilidade>]<nome>(<lista argumentos>):[<retorno>]
Figura 7 - Sintaxe para declaração de um método / Fonte: os autores.
<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.
Quadro 2 - Representação da visibilidade e seu significado / Fonte: os autores.
<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 utili-
zaremos para passar dados aos mé-
todos, e esses métodos trabalharão, 
especificamente, em cima destas in-
formações. Por exemplo:
Figura 8 - Lista de argumentos do método /
Fonte: os autores.
U
N
ID
A
D
E 
3
80
<retorno> 
Tipo do dado retornado pelo argumento. Pode-se utilizar os tipos da linguagem 
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 mesma forma que o tipo de dados de intei-
ros, os tipos de dados reais também diferem nas precisões e podem ser 
positivos ou negativos:
 ■ Float: 4 bytes.
 ■ Double: 8 bytes.
No diagrama a seguir, podemos observar que, para o método calcularIdadeEm-
Meses funcionar, deverá ser transmitida a data de nascimento e, após o cálculo 
para transformar em meses, o método retornará um valor inteiro correspondente 
à quantidade de meses de vida.
Figura 9 - Retorno do método / Fonte: os autores.
U
N
IC
ES
U
M
A
R
81
4 
MULTIPLICIDADE
ENTRE AS
ASSOCIAÇÕES 
de classes
Associação é uma relação entre duas classes, significando que os seus objetos pos-
suem 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).
Quadro 3 - Representação da notação e seu significado / Fonte: os autores.
U
N
ID
A
D
E 
3
82
Vamos exemplificar: o diagrama de classes da Figura 10 nos mostra o relacio-
namento entre as classes Aluno e Disciplina, e, 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.
 ■ Realizando a leitura do diagrama da direita para a 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 a seguir:
 ■ Da esquerda para a direita:
 ■ Um aluno pode cursar somente uma disciplina.
 ■ Da direita para a esquerda:
 ■ Uma disciplina pode ser cursada somente por um aluno.
Figura 10 - Multiplicidade um para um / Fonte: os autores.
Vamos exercitar um pouco: a Figura 11 nos mostra as classes Aluno e Disciplina 
sem a multiplicidade.
Aluno Disciplina
Figura 11 - Sem declaração de multiplicidade / Fonte: os autores.
Definiremos uma ação entre as classes para definir a multiplicidade. Pense na 
palavra “cursa”, uma vez que o aluno cursa a disciplina. Então, ficará como apre-
sentado na Figura 12:
Aluno Disciplina
1..*Cursa
Figura 12 - Identificação da associação / Fonte: os autores.
U
N
IC
ES
U
M
A
R
83
O próximo passo é fazer aquela pergunta da esquerda para a direita:
 ■ Um aluno cursa quantas disciplinas?
 ■ Nossa resposta, agora, será: no mínimo, uma, no máximo, várias dis-
ciplinas.
Nosso diagrama de classes ficará como na Figura 13:
Aluno Disciplina
* 1..*Cursa
Figura 13 - Multiplicidade um ou muitos / Fonte: os autores.
Por fim, o próximo passo é fazer aquela pergunta da direita para a esquerda:
 ■ Uma disciplina pode ser cursada por quantos alunos?
 ■ Nossa resposta, agora, será: vários alunos.
Nosso diagrama de classes ficará como na Figura 14:
Aluno Disciplina
* 1..*Cursa
Figura 14 - Multiplicidade um ou muitos para muitos / Fonte: os autores.
Perfeito! Agora nosso diagrama está completo! Fácil,não é!? Testaremos 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 15:
Aluno Disciplina
1..” 1Cursa
Figura 15 - Multiplicidade somente um para um ou muitos / Fonte: os autores.
U
N
ID
A
D
E 
3
84
5 
TIPOS DE
ASSOCIAÇÃO 
entre classes 
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 16 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 or-
dens, e um trabalhador pode ter nenhum chefe ou, no máximo, um. Mas quando 
o trabalhador não terá nenhum chefe? Resposta: quando ele for o chefe.
Funcionário
- Nome: String
- Endereço: String0..1
*
chefe
Gerência
trabalhador
Figura 16 - Associação unária / Fonte: os autores.
U
N
IC
ES
U
M
A
R
85
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 17, podemos verificar que uma instância 
de objeto da classe cliente está associada a 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).
Cliente Compra
1 *Fazer
Figura 17 - Associação binária / Fonte: os autores.
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 18 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, neste caso, pode ter uma ou várias regras para aquele contrato específico.
Contrato Cliente
Regras do
Contrato
0..” 1..”
1..”
Figura 18 - Associação ternária / Fonte: os autores.
U
N
ID
A
D
E 
3
86
Classe associativa
De acordo com Sommerville (2011), quando uma associação possuir atributos pró-
prios, pode-se criar uma classe associativa. Estas classes são úteis quando queremos 
armazenar o histórico de uma associação (relacionamentos que ocorrem e inte-
ressam ser salvos). Enumeraremos 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 19, 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 ar-
mazenar cada um dos itens de produto, juntamente com a quantidade e o valor 
total, e uma classe separada.
Produto Venda
Itens da Venda
* *
Itens da Venda
Figura 19 - Classe associativa / Fonte: os autores.
Agregação
Lee e Tepfenhart (2002) explicam que a agregação é um caso especial de associa-
çã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 
U
N
IC
ES
U
M
A
R
87
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 se 
deslocam também. A agregação pode ser regular ou de composição. Veremos a 
diferença entre elas.
Agregação regular
De acordo com Lee e Tepfenhart (2002), a agregação regular é representada por 
um losango vazado. O diagrama da Figura 20 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.
A B
B existe sem A
Figura 20 - Agregação regular / Fonte: os autores. 
No exemplo da Figura 21, verificamos que, em um quadro, podem ter uma ou 
várias figuras, ou seja, a figura é uma parte do quadro, porém ela existe mesmo 
que não exista um quadro para ela.
Quadro Figura
O objeto �gura existe sem o
objeto quadro
1..”
Figura 21 - Agregação regular / Fonte: os autores.
Para ficar ainda mais claro, utilizaremos o exemplo da Figura 22, o qual nos mos-
tra que monitor, teclado, mouse e drive são partes de CPU, porém cada uma das 
instâncias desses objetos existe sem uma instância de CPU associada. Neste caso, 
podemos afirmar que a destruição do objeto CPU não implicará a destruição dos 
demais objetos associados.
U
N
ID
A
D
E 
3
88
1 1 1 0..”
CPU
Monitor Teclado Mouse Drive
Figura 22 - Agregação regular / Fonte: os autores. 
Agregação de composição
Lee e 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 ambos, 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 23, a agregação de composição é repre-
sentada por um losango preenchido. O diagrama a seguir 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 a destruição da instância de objeto associado da classe B.
A
B não existe sem A
B
Figura 23 - Agregação de composição / Fonte: os autores. 
Na Figura 24, podemos verificar que um orçamento pode ter muitos itens, porém 
os itens de orçamento não existirão sem o orçamento.
Figura 24 - Agregação de composição / Fonte: os autores. 
U
N
IC
ES
U
M
A
R
89
Na Figura 25, 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 a 
destruição das instâncias de objetos das outras duas classes agregadas.
Figura 25 - Agregação de composição / Fonte: os autores. 
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.
Generalização
Veremos, 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, classes mãe e filha, respectivamente.
Em outras palavras, a generalização é um relacionamento entre um elemento 
geral e um outro mais específico. Este último possui todas as caracterí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 restritasse di-
videm em generalização de sobreposição, exclusiva, total e parcial. A generalizaçã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 genera-
lização, é enfatizado o conceito de herança, que tem como característica a reu-
tilização de atributos e métodos definidos nas classes mais gerais (superclasse) 
por classes mais específicas (subclasses), ou seja, permite a criação de elementos 
especializados em outros. Por sua vez, as subclasses, que representam 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.
U
N
ID
A
D
E 
3
90
A Figura 26 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 es-
pecífico que identifica a 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().
Figura 26 - Generalização / Fonte: os autores. 
Cobertura total
A generalização apresenta um conceito importante: a cobertura. A notação para 
a cobertura é uma linha tracejada com o tipo de cobertura entre chaves. Dize-
mos que a cobertura é total ou completa se cada elemento da classe genérica é 
mapeado para, pelo menos, um elemento das classes especializadas.
Na Figura 27, verificamos que a cobertura da generalização é total, o que 
significa dizer que uma pessoa, obrigatoriamente, tem que ser homem ou mulher.
Figura 27 - Generalização com cobertura total / Fonte: os autores. 
U
N
IC
ES
U
M
A
R
91
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 28, refinamos o diagrama do exemplo anterior, juntando as cober-
turas total e exclusiva. Dessa forma, temos que uma pessoa será, obrigatoriamente, 
um homem ou uma mulher, não podendo ser os dois.
Figura 28 - Generalização com cobertura total e exclusiva / Fonte: os autores. 
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 29 nos mostra que um veículo pode ser um carro ou uma bicicleta, 
podendo não ser nenhum dos dois. Percebam que, neste tipo de cobertura, não 
sou obrigado a especializar o veículo, diferentemente da cobertura total que, obri-
gatoriamente, devo mapear para, pelo menos, uma subclasse.
Figura 29 - Generalização com cobertura parcial / Fonte: os autores.
U
N
ID
A
D
E 
3
92
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 30, podemos verificar que uma pessoa pode ser aluno ou professor, 
podendo ser os dois.
Figura 30 - Generalização com cobertura de sobreposição / Fonte: os autores.
As coberturas podem ser combinadas da seguinte forma:
 ■ Total, exclusiva: nesta combinação de cobertura, uma classe genérica deve 
ser mapeada para uma única subclasse.
 ■ Total, sobreposição: nesta combinação de cobertura, uma classe genérica 
deve ser mapeada para uma ou várias subclasses.
 ■ Parcial, exclusiva: nesta combinação de cobertura, uma classe genérica 
pode ser mapeada para uma única subclasse ou para nenhuma.
 ■ Parcial, sobreposição: nesta combinação de cobertura, uma classe gené-
rica pode ser mapeada para uma ou mais subclasses ou para nenhuma.
U
N
IC
ES
U
M
A
R
93
6 
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 31, 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 subclasse 
Extensão herdará atributos e métodos das superclasses Curso e Evento.
Figura 31 - Herança múltipla / Fonte: os autores. 
U
N
ID
A
D
E 
3
94
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 é ter mais capacidade de especificação de classes e 
mais oportunidade de reutilização. Ela traz a modelagem de objetos mais próxima 
da maneira como se costuma pensar. A desvantagem é a perda em simplicidade 
conceitual e de implementação. 
Herança múltipla dá-se quando uma subclasse herda atributos e operações de duas ou 
mais superclasses. Este tipo de situação deve ser evitado. Apesar de a orientação a obje-
tos prever esta situação, ela introduz possibilidades de difícil solução.
Fonte: Medeiros (2004, p. 80).
explorando Ideias
U
N
IC
ES
U
M
A
R
95
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 objetos 
no sistema e os vários tipos de relacionamentos estáticos que existem entre eles. 
Mostra os atributos e as 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 objetos 
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.
Familiarizamo-nos com o conceito e a sintaxe dos atributos e aprendemos 
que são estes elementos que definem a estrutura de uma classe, representando 
uma característica dos objetos instanciados. Aprendemos, também, que são os 
métodos que determinam o comportamento dos objetos de uma classe e são 
semelhantes às funções ou aos procedimentos da programaçã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: a associação unária 
e binária, as classes associativas, a agregação regular e de composição, a genera-
lização e a especialização. Compreendemos que a 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, comunicaçã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 diagrama de classes.
96
na prática
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 são 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?
97
aprimore-se
SISTEMA DE INFORMAÇÃO ORIENTADO A OBJETOS COM AGENTES INTE-
LIGENTES
[...] O modelo apresentado é baseado na aplicação da tecnologia de agentes inte-
ligentes 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 formatação e detalhamento da informação.
Mesmo sendo o modelo REA o mais aceito para estruturar os fenômenoscon-
tábeis, este é eficiente no armazenamento dos dados, mas não no tratamento da 
informação (VERDAASDONK, 2003, p. 45). Dessa maneira, se torna necessário o de-
senvolvimento de um sistema destinado ao tratamento dos dados, gerando infor-
mação relevante, confiável e comparável, caracterí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 da-
dos orientado a objetos. A utilização de modelagem orientada a objetos foi intro-
duzida no desenvolvimento de sistemas de informação contábeis por Knaus (2001), 
mas sua proposta utiliza como base o modelo DCA, sendo cada conta contábil como 
classe distinta (KNAUS, 2001, p. 78).
A modelagem de banco de dados orientados a objeto surgiu das limitações dos 
bancos de dados relacionais, seu objetivo básico é o gerenciamento de grandes volu-
mes de informação, possuindo maior facilidade no tratamento de dados e atendendo 
aos requisitos atuais de sistemas com outros tipos de bancos de dados, como o hiper-
texto, tão amplamente utilizado (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 
tradicionais por separar os dados das operações de modelagem da informação ao 
mesmo tempo em que utiliza uma abordagem orientada a objetos.
98
aprimore-se
Visando um melhor desempenho da modelagem proposta, a forma de desen-
volvimento por UML é utilizada para facilitar a visualização e a integração entre os 
diferentes 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álises são desenvolvidos através de agentes inteligentes, baseados em siste-
mas especialistas. A grande diferença se dá na separação da aplicação de contabili-
dade do banco de dados, o que não ocorre normalmente.
Assim, para tal desenvolvimento, a utilização da linguagem UML para a mode-
lagem do sistema é de grande auxílio, é importante ressaltar que o modelo é uma 
simplificação da realidade, apresentando um caso geral de um sistema de infor-
mação para qualquer atividade que se deseje assumir. 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 agentes são as classes a serem implementadas.
Assim, com a utilização de Agentes Inteligentes para o desenvolvimento da infor-
maçã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 respon-
sáveis pela intra-ação e alocação de recursos. Além disso, com a inserção de agentes 
inteligentes no desenvolvimento e análises de relatórios.
Normalmente, existem muitos objetos similares 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 agrupamento 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 possuir 
hierarquia de especialização, ou seja, o relacionamento ISA, que indica uma classe como 
sendo especialização de outra (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 253).
99
aprimore-se
Assim, como na generalização do modelo REA, é possível determinar uma espe-
cializaçã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 dentro 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), ocasionando um evento econômico (venda) 
que terá impacto nos recursos econômicos, 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.
Este modelo, assim como o formato original do modelo REA, pode ser aplicado a 
qualquer situação dentro dos diversos tipos de organizações que realizem ativida-
des econômicas.
A atuação do agente inteligente se dá de maneira autônoma, ou seja, o agente 
inteligente é um software separado do banco de dados, que o acessa remotamente 
e, atuando 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.
Fonte: Moraes e Nagano (2009, p. 474-475).
100
eu recomendo!
Engenharia de Software
Autor: 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 as-
pectos da produção de software, ela é multidisciplinar e está em 
constante mudança.
livro
Para aprofundar os conhecimentos sobre OO, leia o artigo intitulado “AspectJ – 
Programação orientada a aspectos em Java”. A Programação Orientada a Aspec-
tos (AOP) procura solucionar algumas ineficiências da Orientação a Objetos, como 
o entrelaçamento e o espalhamento de código com diferentes propósitos. 
https://homepages.dcc.ufmg.br/~mariza/CELP/sblp2003/sblp2003_files/aspectj.pdf
conecte-se
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
anotações
4
DIAGRAMAS DE
SEQUÊNCIA,
ESTADO
e colaboração
PROFESSORES 
Me. Déverson Rogério Rando
Esp. Janaína Aparecida de Freitas
PLANO DE ESTUDO 
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Avançando nos Diagramas • Dia-
grama de Sequência • Diagrama de Estados • Diagrama de Comunicaçã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.
INTRODUÇÃO
Caro(a) aluno(a), nesta quarta unidade do livro de Análise e Projeto Orien-
tado a Objetos, mostraremos mais alguns diagramas importantíssimos que 
complementam e refinam o diagrama de casos de uso e de classes.
Aprenderemos a notação e como utilizar o diagrama de sequência; 
desse modo, 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 necessida-
de 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 comportamento modelado por esse diagrama.
Por fim, aprenderemos o diagrama de comunicação, conhecido, tam-
bém, como diagrama de colaboração (UML 1.5). Veremosque esse diagra-
ma 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, considerando 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 
unidade, em que teremos a oportunidade de modelar um sistema OO. 
Então, o que estamos esperando? Vamos ao trabalho! Boa leitura para você.
U
N
ID
A
D
E 
4
104
1 
AVANÇANDO 
NOS DIAGRAMAS
Agora que já conhecemos o objetivo e a notação dos diagramas de caso de uso e 
de classes, avançaremos um pouco e conheceremos 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, 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 têm documentação que nos permite contar e 
entender a sua história. 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, po-
rém o esforço será maior no momento da manutenção, quando nos depararmos 
com um software sem documentação; a experiência 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.
U
N
IC
ES
U
M
A
R
105
É a classe que nos fornecerá a estrutura para modelar um conjunto de objetos com carac-
terí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: os autores.
explorando Ideias
Vimos, na Unidade 2, que o diagrama de caso de uso é utilizado na análise 
de requisitos e acompanha o software desde o seu início até a conclusão. Nesse 
diagrama, surge a figura do ator, que pode ser uma pessoa, um sistema, um ro-
teador. O ator é quem realiza as atividades e sempre atua sobre um caso de uso. 
Portanto, o diagrama de caso de uso modela o comportamento dos atores no 
sistema. Olhando para o diagrama de caso de uso da Figura 1, 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
Aluno
Realiza
consulta
Realiza
empréstimo
Realiza
devolução
Cria
aluno
Cria
livro
Efetua
empréstimo
Bibliotecária
Figura 1 - Diagrama de caso de uso / Fonte: os autores.
Porém, o diagrama de casos de uso nos fornece apenas um panorama visual das 
funcionalidades do sistema, sendo 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.
É evidente, 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 do-
mínio para modelar a primeira versão do diagrama de classes, que nos mostrará 
a estrutura estática do sistema.
U
N
ID
A
D
E 
4
106
2 
DIAGRAMA
DE SEQUÊNCIA
O diagrama de sequência é o próximo que conheceremos a notação. Sua utilidade 
é estudar as interações entre os objetos, possibilitando a identificação de relação 
entre as classes, servindo para refinar o diagrama delas.
O cenário da Figura 2 mostra a solicitação de um empréstimo pelo aluno. A 
partir dessa ação, desencadeia-se um conjunto de mensagens entre os objetos 
que permitem a verificação da existência da pessoa aluno, e, em seguida, cria-se 
o item de empréstimo, o qual verifica a existência do exemplar solicitado, reali-
zando 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 identificação das relações entre elas.
U
N
IC
ES
U
M
A
R
107
s
Figura 2 - Diagrama de sequência / Fonte: os autores.
Muito bem, mas como posso interpretar esse diagrama? A resposta é: conhecendo 
sua notação. Vamos lá!
U
N
ID
A
D
E 
4
108
Notação do Diagrama de Sequência
O diagrama de sequência da Figura 3 tem todos os elementos da notação desta-
cados por uma elipse vermelha, em que é possível observar as mensagens (sín-
cronas, assíncronas, reflexiva), a linha do tempo, o tempo de atividade e objetos. 
Vamos conhecê-los em detalhes.
Figura 3 - Modelo de diagrama de sequência / Fonte: os autores.
Timeline
As timelines, ou linhas de vidas, fazem 
parte da dimensão vertical do diagra-
ma. A linha de vida é composta por 
duas partes: cabeça e cauda. A cabeça 
é representada por um retângulo, no 
qual é exibida a identificação do objeto, 
a cauda corresponde a uma linha verti-
cal tracejada.
Linha do Tempo
Figura 4 - Timeline (linha de vida ou tempo) / 
Fonte: os autores.
U
N
IC
ES
U
M
A
R
109
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 par-
te a seta é aquele que está enviando 
a mensagem (objeto remetente). O 
objeto para o qual a seta aponta é 
aquele que está recebendo a mensa-
gem (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 5, 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 aguardando a 
resposta do receptor e são representadas por uma seta com a ponta preenchida. 
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 aguardando a resposta do receptor e são representadas por uma seta com 
a ponta vazada. Não há 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 6:
Figura 6 - Auto mensagem síncrona / Fonte: os autores.
Figura 5 - Mensagens síncrona e assíncrona / 
Fonte: os autores.
U
N
ID
A
D
E 
4
110
Tempo de atividade
Os objetos, também, apresentam um tempo de atividade na linha do tempo, e 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 7:
Figura 7 - Tempo de atividade / Fonte: os autores.
Exemplo
Já conhecemos a notação do diagrama de sequência, agora, praticaremos um pouco. 
Para facilitar o entendimento da notação, utilizaremos um exemplo da Unidade 2, 
na qual apresentamos 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 
dasfuncionalidades do sistema, é necessária uma descrição textual para detalhar 
os casos de uso. Na Figura 8, apresentaremos um diagrama de casos de uso que 
mostra o ator “Operador” interagindo com o caso de uso “Cadastrar Pessoas”.
Operador
Cadastrar Pessoas
Figura 8 - Caso de uso / Fonte: os autores.
U
N
IC
ES
U
M
A
R
111
O Quadro 1 mostra a descrição textual para o caso de uso “Cadastrar Pessoas”, 
vejamos:
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 Operador.
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 às regras de entrada (más-
cara 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 fornecer os dados. Nesse 
caso, retornar ao fluxo básico em {Fim}.
Quadro 1 - Descrição textual para o caso de uso / Fonte: os autores.
U
N
ID
A
D
E 
4
112
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, dentre 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, des-
viando 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, 
definiremos as linhas do tempo, teremos uma para o usuário, outra para a inter-
face do usuário com o sistema, outra para o controle do sistema e a última para 
a calculadora, como mostrado na figura a seguir.
Usuário
Sistema CalculadoraInterfaceUsuário
Figura 9 - Linhas do tempo para calculadora / Fonte: os autores.
U
N
IC
ES
U
M
A
R
113
Em seguida, o sistema solicitará a expressão para o usuário, enviando uma mensa-
gem síncrona para a interface usuário, que deverá aguardar a resposta do Usuário 
para a continuação, conforme a figura a seguir.
1.1: Expressão? ( )
{Exp}
1: SolicitarExpressao ( )
Usuário
Sistema CalculadoraInterfaceUsuário
{Exp}
Figura 10 - Diagrama de sequência com troca de mensagens entre usuário e sistema / Fonte: 
os autores.
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.
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 10 - Diagrama de sequência para Resolver Expressões Aritméticas / Fonte: os autores.
U
N
ID
A
D
E 
4
114
3 
DIAGRAMA
DE ESTADOS
Nesta aula, veremos o diagrama de estados, que tem como objetivo especificar o com-
portamento 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 com-
portamentos 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 comporta-
mento interno da classe, permitindo a especificação da sua dinâmica. Uma especifi-
cação corresponde a como deve ser implementada uma classe.
Estado
O estado representa a situação ou momento no tempo de vida de um objeto, o 
qual 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.
U
N
IC
ES
U
M
A
R
115
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 11:
A notação para o estado final é um 
círculo preenchido com borda, como 
mostra a figura a seguir:
Figura 11 - Estado inicial / Fonte: os autores. Figura 12 - Estado final / Fonte: os autores.
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.
State0
Figura 13 - Estado simples / Fonte: os autores.
O estado simples, também, pode ser representado por um retângulo com dois 
compartimentos. No primeiro compartimento, é informado o nome para o es-
tado, e, no segundo compartimento, as ações.
StateName
entry / action
do / action
exit / action
Figura 14 - Estado / Fonte: os autores.
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.
U
N
ID
A
D
E 
4
116
Estado Composto
Estado Estado
Figura 15 - Estado composto / Fonte: os autores.
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.
Disponível Emprestado
Reservado
Manutenção
Figura 16 - Estado de escolha / Fonte: os autores.
A junção é o contrário do estado de escolha, ou seja, vários estados podem chegar 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
Figura 17 - Estado de junção / Fonte: os autores.
U
N
IC
ES
U
M
A
R
117
O fork, representado por um retângulo preenchido, indica estados concorrentes. 
Quando um estado chega ao fork, desencadeia um ou mais estados concorrentes.
Estado 1
Estado 3Estado 2 Estado 4
Figura 18 - Estado fork / Fonte: os autores.
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 19 - Estado de join (junção) / Fonte: os autores.
E, por último, as ações. Elas ocorrem em três eventos: quando entra (entry), sai 
(exit) ou quando está (do) em um estado.
Estado 1
entry / funcaoX
Estado 2
exit / funcaoYfuncaoZ( ) (Z>1)
Figura 20 - Ações do estado / Fonte: os autores.
U
N
ID
A
D
E 
4
118
De acordo com o diagrama de estados apresentado na Figura 15, a funcaoX será 
executada no momento em que entrar no Estado1. Na transição do Estado1 para 
o Estado2, será executada a funcaoZ somentese 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 12 mostra que, quando 
um exemplar estiver 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 exemplar_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 21 - Diagrama de estado / Fonte: os autores.
U
N
IC
ES
U
M
A
R
119
4 
DIAGRAMA 
DE COMUNICAÇÃO
Vamos para o último diagrama, conhecido como diagrama de colaboração até 
a versão 1.5 da UML, e que teve sua denominação modificada para diagrama de 
comunicação na versão 2.0 da UML.
O diagrama de comunicação é outra forma de representar o cenário. Ele con-
té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 quatro elementos:
 ■ Ator.
 ■ Objetos.
 ■ Vínculos.
 ■ Mensagens.
U
N
ID
A
D
E 
4
120
Notação para o Diagrama de Co-
municação
Ator
O ator tem a mesma representação dos demais diagra-
mas, 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, são infor-
mados o objeto e o nome da classe à qual aquele objeto pertence, separados por 
dois pontos, que definimos como instância identificada.
umaPessoa : Pessoa
Figura 23 - Instância identificada / Fonte: os autores.
O objeto, também, pode ser representado somente com a identificação da classe 
em seu rótulo.
Pessoa
Figura 24 - Classe / Fonte: os autores.
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.
: umaPessoa
Figura 25 - Instância / Fonte: os autores.
:Ator
Figura 22 - Ator /
Fonte: os autores.
U
N
IC
ES
U
M
A
R
121
Vínculo
O vínculo é a ligação entre dois objetos, que identifica o envio e o recebimento 
de mensagens.
: umaPessoa
: Médico
Figura 26 - Vínculo / Fonte: os autores.
Mensagens
As mensagens enviadas e recebidas são representadas por setas que apontam suas 
direções, e 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 27 - Troca de Mensagens / Fonte: oss autores.
Exemplo
O diagrama de comunicação da Figura 28 exemplifica a troca de mensagens 
entre os objetos. Podemos verificar que o objeto GUI Bibliotecária envia uma 
mensagem 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. 
U
N
ID
A
D
E 
4
122
Após a validação do aluno, o objeto empréstimo envia uma mensagem para o 
item empréstimo validar (3) o exemplar que está sendo emprestado, porém, para 
o item empréstimo validar (4) o exemplar, é necessário enviar uma mensagem de 
validação para o objeto exemplar.
Empréstimo
Exemplar
Item Empréstimo
GUI Bibliotecária Aluno
1: Cria ( ) 2: Valida ( )
3: Valida ( )
4: Valida ( )
Figura 28 - Diagrama de Comunicação / Fonte: o autor.
Se o diagrama de sequência já cria o cenário que mostra a troca de mensagens entre os 
objetos, qual é a necessidade de elaborar, também, o diagrama de comunicação? 
pensando juntos
U
N
IC
ES
U
M
A
R
123
CONSIDERAÇÕES FINAIS
Nesta unidade, aprendemos mais três diagramas importantes para análise e projeto 
orientado a objetos, sendo eles: diagramas de sequência, de colaboração e de estado.
Familiarizamo-nos com a notação e com o modo de utilizar o diagrama de 
sequência; 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 sistema 
irá funcionar, representando toda a ordem de comunicação entre classes por meio 
do diagrama de colaboração. Aprendemos que, diferentemente do diagrama 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.
É 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, 
consideramos 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 os contornos. A 
diferença é que nem sempre produzimos aquilo que gostaríamos, mas, sim, aquilo 
para o qual fomos contratados, por isso, há necessidade de apresentar habilidades 
que permitam agregar pessoas.
124
na prática
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? Explique.
3. Sabemos que o diagrama de comunicação é outra forma de modelar o cenário do 
software; então, quando devemos utilizá-lo?
4. Qual é a diferença entre os diagramas de sequência e comunicação?
125
aprimore-se
Prezado(a) aluno(a), segue uma matéria muito interessante sobre UP, um processo 
unificado e 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
A engenharia de software se produz por meio de um conjunto de fases. Cada uma 
das fases pode envolver métodos, ferramentas 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, desen-
volvimento 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 (JACOBSON; BOOCH; RUMBAUGH, 1999; 
PAULA FILHO, 2001).
A análise de requisitos é uma etapa presente na fase de definiçãodo software, in-
dependentemente do modelo de engenharia de software adotado. Paula Filho (2001) 
afirma que a engenharia de requisitos é formada por um conjunto de técnicas em-
pregadas para levantar, detalhar, 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 engenharia 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 especi-
ficação de requisitos foi desenvolvida, sendo poucas as propostas que visam a siste-
matização da definição de requisitos de forma menos subjetiva (SANTANDER, 2002).
126
aprimore-se
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 de-
senvolvimento, é 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, 
centrado em arquitetura, iterativo e incremental. Os casos de uso definidos para um 
sistema são a base de todo o processo de desenvolvimento. A partir de uma perspec-
tiva de gerenciamento, o ciclo de vida de software do UP é dividido em quatro fases 
sequenciais (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 é adicionalmente dividida em iterações e fina-
lizada 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 arte-
fatos. Os principais workflows de processo do UP são Levantamento de Requisitos, 
Análise, Projeto, Implementação, Teste e Implantação, sendo que o RUP se diferen-
cia, principalmente, em relação ao workflow de Modelagem de Negócio.
127
aprimore-se
A UML foi adotada pela OMG (Object Management Group), em 1997, como lingua-
gem padrão para a modelagem de sistemas orientados a objeto. É uma linguagem 
para especificação, visualização, construção e documentação de artefatos de sis-
temas de software, como também para a modelagem de negócios e outros siste-
mas não necessariamente relacionados 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 Objetos, Diagrama de Casos de Uso, Diagrama 
de Sequência, Diagrama de Colaborações, Diagrama de Gráficos de Estados, Diagra-
ma de Atividades, Diagrama de Componentes, Diagrama de Implantação.
A UML também permite a ampliação da linguagem de maneira controlada, por 
meio 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.
Fonte: adaptado de Junior e Campos (2008, p. 28).
128
eu recomendo!
Da mesma forma que é impossível construir uma casa sem, primeiramente, de-
finir sua planta, também, é impossível construir um software sem, inicialmente, 
definir sua arquitetura. Leia mais sobre o assunto no link disponível em: 
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/motivacao/motiva-
cao1.htm
conecte-se
UML e C++: guia prático de desenvolvimento orientado a 
objetos
Autores: Richard C. Lee e William M. Tepfenhart
Editora: Makron Books
Sinopse: este livro prático é um guia autoexplicativo para ana-
listas e desenvolvedores de software. Ele ensina como realmen-
te praticar modelagem orientada a objeto, usando a notação da 
UML, e implementar o modelo com C++. Os autores apresentam todos os con-
ceitos básicos da tecnologia orientada a objeto, que são necessários para que os 
leitores possam entender e aplicar o paradigma orientado a objeto. 
livro
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
anotações
5
ESTUDO 
DE CASO
PLANO DE ESTUDO 
A seguir, apresentam-se as aulas 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.
OBJETIVOS DE APRENDIZAGEM 
Conhecer uma ferramenta CASE para modelagem OO • Fazer a análise e projeto a partir de um estu-
do 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.
PROFESSORES 
Me. Déverson Rogério Rando
Esp. Janaína Aparecida de Freitas
INTRODUÇÃO
Caro(a) aluno(a), chegamos à quinta e última unidade do livro Análise e 
Projeto Orientado a Objetos. Assim, faremos 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 conosco, a análise e o projeto de 
um software, porém, para não precisarmos desenhar os diagramas à mão, 
utilizaremos 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 de uma 
licença de uso, e os softwares livres, que não necessitam de uma licença de 
uso. Optaremos, aqui, por uma ferramenta que seja livre e que atenda às 
nossas necessidades.
Apresentaremos a você um estudo de caso em que teremos a oportu-
nidade de modelar um software orientado a objetos, utilizando uma fer-
ramenta CASE que nos auxiliará na construção dos diagramas. Construi-
remos, 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 dia-
grama de caso de uso, poderemos, então, elaborar o diagrama de classes, 
que representa 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 colabo-
raçã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 compor-
tamento da classe por meio de máquinas de estado. Então, o que estamos 
esperando? Vamos ao trabalho! Boa leitura!
U
N
ID
A
D
E 
5
132
1 
FERRAMENTAS 
CASE
Modelar um sistema à 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 tra-
dução livre, significa “engenharia de software auxiliada por computador”. É uma 
classificaçã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 inseridas neste material foramfeitas com a fer-
ramenta CASE, produzida pela empresa Astah. Desse modo, no material comple-
mentar, disponibilizamos o link para o download dessa ferramenta, que é gratuita.
É 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?
pensando juntos
U
N
IC
ES
U
M
A
R
133
Muito bem, para nossa análise e projeto orientado a objetos, adotaremos a ferra-
menta CASE Astah Community, por oferecer suporte para o modelo de lingua-
gem 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. Pensa que não é possível utilizar um mo-
delo de processo sem ferramentas CASE que o suportem. Invariavelmente, ocorre 
que, na primeira manutenção, a documentação fica desatualizada, e, conforme 
já discutimos, 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 docu-
mentação a cada manutenção.
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 livremente, já vem sendo utilizado há mais de um ano por mais 
de uma centena de alunos. Para saber mais sobre o FAST CASE, acesse: http://www.inf.
ufsc.br/sbes99/anais/Sessao-Ferramenta-Completo/12-fastcase.pdf 
Fonte: o autor.
explorando Ideias
U
N
ID
A
D
E 
5
134
2 
ESTUDO
DE CASO
Apresentaremos, 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, e o ob-
jetivo é que façamos a construção dos diagramas UML 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 re-
ferida ferramenta é bem intuitivo, e você não terá dificuldades em desenvolver. 
Vamos pôr a mão na massa!
A distribuidora de filmes Fenix é proprietária de vários cinemas em diversas 
cidades e precisa de um sistema para controlar as exibições de filmes em todas 
as salas de seus cinemas. 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, podemos, 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 ser exibido em 
vários cinemas e, é claro, em várias cidades ao mesmo tempo.
Cada cinema possui uma identificação: um nome fantasia, um endereço e 
uma capacidade de lotação. Cada filme é registrado com título, duração, impro-
priedade e um conjunto de atores que formam seu elenco, bem como seu diretor.
U
N
IC
ES
U
M
A
R
135
Os atores de um filme podem atuar em diversos filmes, assim como o diretor 
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, definiremos os requisitos funcionais do sistema. Lembrando que 
requisito funcional é 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:
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 sistema deve 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: aquele que gerencia questões administrativas, como 
permissões, bloqueio 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.
U
N
ID
A
D
E 
5
136
3 
DIAGRAMA 
DE CASO DE USO
Começaremos, então, compondo nosso cenário ao construir, primeiro, o diagra-
ma de caso de uso. Lembrando que esse diagrama nos fornecerá um panorama 
dos requisitos funcionais. Estes 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 Use-
Case Diagram, como mostrado na figura a seguir, ou clique no menu Diagram 
e escolha a opção UseCase Diagram.
Figura 1 - Tela principal do Astah Community / Fonte: os autores.
U
N
IC
ES
U
M
A
R
137
Em seguida, abrirá a tela apresentada na Figura 2. 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 2 - Ferramentas para o diagrama de caso de uso / Fonte: os autores.
Iniciaremos modelando o ator que será o administrador do sistema, pois esse 
usuário será responsável pela administração de novos acessos no sistema.
De�nir permissões
para usuário
Cadastrar novos
usuários
Administrador
Figura 3 - Ator administrador / Fonte: os autores.
U
N
ID
A
D
E 
5
138
O diagrama da Figura 4, agora, completo, mostra o operador do cinema e suas 
atribuições de realizar os cadastros de ator, filme, cinemas, salas, bem como fazer 
as movimentaçõ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 4 - Diagrama de caso de uso / Fonte: os autores.
Para completarmos o diagrama de caso de uso, devemos adicionar, a cada um 
deles, uma descrição textual, vamos lá!
U
N
IC
ES
U
M
A
R
139
Ator: Administrador
Cadastrar novos
usuários
Administrador
Figura 5 - Cadastrar novos usuários / Fonte: os autores.
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
1. Solicitar a criação do novo usuário
2. Abre a Janela de Cadastro (A2)
3. Usuário informa os dados
4. Sistema valida a entrada (A1)
5. Sistema salva os dados
6. 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 1 - Caso de uso: cadastrar novos usuários / Fonte: os autores.
U
N
ID
A
D
E 
5
140
De�nir permissões
para usuário
Administrador
Figura6 - Definir permissões para usuário / Fonte: os autores.
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
1. Solicitar a definição de permissões
2. Abre a Janela de Definição de Permis-
sões (A2)
3. Usuário informa as permissões
4. Sistema valida a entrada (A1)
5. Sistema salva os dados
6. 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 2 - Caso de uso: definir permissões para os usuários / Fonte: os autores.
U
N
IC
ES
U
M
A
R
141
Ator: operador
Operador
Cadastrar Elenco
Figura 7 - Cadastrar ator / Fonte: os autores.
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
1. Solicitar a criação do novo ator
2. Abre a Janela de Cadastro (A2)
3. Usuário informa os dados
4. Sistema valida a entrada (A1)
5. Sistema salva os dados
6. 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 3 - Caso de uso: cadastrar elenco / Fonte: os autores.
U
N
ID
A
D
E 
5
142
Operador
Cadastrar Filmes
Figura 8 - Cadastrar filmes / Fonte: os autores.
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
1. Solicitar a criação do novo filme
2. Abre a Janela de Cadastro (A2)
3. Usuário informa os dados
4. Sistema valida a entrada (A1)
5. Sistema salva os dados
6. 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: cadastrar novos filmes / Fonte: os autores.
U
N
IC
ES
U
M
A
R
143
Operador
Cadastrar Cinemas
Figura 9 - Cadastrar cinemas / Fonte: os autores.
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ções do Sistema
1. Solicitar a criação do novo cinema
2. Abre a Janela de Cadastro (A2)
3. Usuário informa os dados
4. Sistema valida a entrada (A1)
5. Sistema salva os dados
6. 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 5 - Caso de uso: cadastrar novos cinemas / Fonte: os autores.
U
N
ID
A
D
E 
5
144
Operador
Cadastrar Salas
Figura 10 - Cadastrar salas / Fonte: os autores.
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
1. Solicitar a criação da nova sala
2. Abre a Janela de Cadastro (A2)
3. Usuário informa os dados
4. Sistema valida a entrada (A1)
5. Sistema salva os dados
6. 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 8 - Caso de uso: cadastrar novas salas / Fonte: os autores.
U
N
IC
ES
U
M
A
R
145
Operador
Exibir Filme
Figura 11 - Exibir filme / Fonte: os autores.
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
1. Solicitar a exibição do filme
2. Abre a Janela de Movimentação (A2)
3. Usuário altera o status
4. Sistema valida a entrada (A1)
5. Sistema solicita horário de exibição
6. Usuário informa o horário de exibição
7. Sistema valida a entrada (A1)
8. Sistema salva os dados
9. 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 9 - Caso de uso: exibir filmes / Fonte: os autores.
U
N
ID
A
D
E 
5
146
Operador
Suspender exibição
de �lme
Figura 12 - Suspender filme / Fonte: os autores.
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
1. Solicitar a suspensão de exibição
2. Abre a Janela de Movimentação (A2)
3. Usuário informa o filme
4. Sistema valida a entrada (A1)
5. Usuário altera o status
6. Sistema salva os dados
7. 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 10 - Caso de uso: suspender a exibição de filmes / Fonte: os autores.
U
N
IC
ES
U
M
A
R
147
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.
 ■ Elaborar o diagrama de sequência.
 ■ Elaborar o diagrama de colaboração.
 ■ Elaborar o diagrama de estado.
U
N
ID
A
D
E 
5
148
4 
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 mo-
dela 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. Definiremos 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 indi-
cação (impropriedade). Na classe elenco, precisamos registrar o nome do diretor/
ator, a data de nascimento 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 queestá sendo exibido no momen-
to, horário de exibição e capacidade. A primeira versão do diagrama de classes 
ficará de acordo com a Figura 13.
U
N
IC
ES
U
M
A
R
149
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
Figura 13 - Diagrama de classes - Versão 1.0 / Fonte: os autores.
Como pôde ter percebido, o nosso diagrama de classes está sem as associações, 
então vamos completá-lo 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 se associa, uma vez 
que o cinema é composto por salas. 
Olhe que interessante: sublinhei 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 por quantas salas?
 ■ Resposta: por uma ou várias.
 ■ Uma sala compõe quantos cinemas?
 ■ Resposta: somente um.
U
N
ID
A
D
E 
5
150
Sendo assim, nosso diagrama ficou conforme mostrado na Figura 14. 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
Sala
- Sala_id: int
- Horário: String
- Capacidade: String
- Inserir( ): void
- Cancelar( ): void
1 1...”
Figura 14 - Associação por agregação / Fonte: os autores.
Agora, verificaremos 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 existir. Vamos 
fazer aquelas perguntinhas para verificar a multiplicidade:
 ■ Uma sala pode exibir quantos filmes?
 ■ Resposta: somente um.
 ■ Um filme pode ser exibido em quantas salas?
 ■ Resposta: em nenhuma ou em várias.
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
Figura 15 - Associação por agregação e simples / Fonte: os autores.
U
N
IC
ES
U
M
A
R
151
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 pode ter vários atores. Podemos verifi-
car, então, que a multiplicidade para essa associação é de vários(n) para vários(n). 
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 16.
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 16 - Diagrama de classes versão final / Fonte: os autores.
U
N
ID
A
D
E 
5
152
5 
DIAGRAMA
DE SEQUÊNCIA
Elaboraremos, 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 mu-
danç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 
significativa. Porém o objetivo 
é estudar as interações de for-
ma mais profunda. Iniciaremos 
pelo caso de uso “Cadastrar 
Filme”; verificaremos 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 17 - Diagrama de sequência para inserir filme / 
Fonte: os autores.
U
N
IC
ES
U
M
A
R
153
O próximo diagrama de se-
quência é para o caso de uso 
“Cadastrar Cinema”. Nesse 
caso de uso, o operador solici-
ta a inserção de uma nova ins-
tância para a classe cinema, a 
classe verifica se a entrada está 
correta, salva os dados e retor-
na um ok para o operador.
Figura 18 - Diagrama de sequência para cadastrar
cinema / Fonte: os autores.
O próximo 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 
elenco, a classe verifica se a entrada está correta, salva os dados, informa o filme 
no qual atua como ator, verifica se o filme 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 19 - Diagrama de sequência para inserir elenco / Fonte: os autores.
1: Solicita Inserir ( )
2: Veri�ca entrada ( )
4: OK ( )
Cinema
3: Salva Dados ( )
Operador
U
N
ID
A
D
E 
5
154
O próximo diagrama de sequência é para o caso de uso “Cadastrar Sala”. 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, verifica se o cinema para aquela 
sala existe, salva os dados e retorna um ok para o operador.
1: Solicita Inserir ( )
2: Veri�ca entrada ( )
3: Veri�ca Cinema ( )
3.1: OK ( )
5: OK ( )
CinemaSala
4: Salva Dados ( )
Operador
Figura 20 - Diagrama de sequência para cadastrar sala / Fonte: os autores.
U
N
IC
ES
U
M
A
R
155
O próximo diagrama de sequência é para o caso de uso “Exibir Filme”. Nesse caso 
de uso, o operador solicita a edição de uma instância 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 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 21 - Diagrama de sequência para exibir filme / Fonte: os autores.
U
N
ID
A
D
E 
5
156
O próximo diagrama de sequência é para o caso de uso “Suspender a Exibição 
do 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 
suspenso e exclui de todas as salas que estão sendo exibidas.
1: Solicita Suspensão ( )
2: Solicita Filme ( )
2.1: Informa Filme ( )
3: Altera Status ( )
4: Exclui Filme( )
6: OK ( )
5: SalvaDados ( )
7: OK ( )
SalaFilme
Operador
Figura 22 - Diagrama de sequência para suspender a exibição do filme / Fonte: os autores.
U
N
IC
ES
U
M
A
R
157
6 
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 necessi-
dade de uma representação por um diagrama de estado.
Dessa forma, conseguimos 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. O 
objeto, normalmente, tem um estado que é determinado por um atributo de sua classe.
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 diferentes (“exibindo”, “suspenso”). Portanto, modelaremos o diagrama 
de estado somente para a classe Filme.
U
N
ID
A
D
E 
5
158
O diagrama de estado da Figura 24 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 “SUS-
PENSO”, então o objeto não sofrerá nenhu-
ma alteração.
O diagrama de estado da Figura 23 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. O início é 
marcado pela notação do círculo preenchi-
do, os estados possíveis são identificados 
pela notação do retângulo com cantos arre-
dondados. O losango indica um estado de 
escolha, em que se deve verificar o estado 
atual do objeto para decidir se muda seu 
valor ou não.
Status = “EXIBINDO”
St
at
us
 =
 “S
U
SP
EN
SO
”
SUSPENSO
do / atualiza
EXIBINDO
exit / gravar
St
at
us
 =
 “E
XI
BI
N
D
O
”
Status = “SUSPENSO”
EXIBINDO
do / atualiza
SUSPENSO
exit / gravar
Figura 23 - Estado inicial SUSPENSO / 
Fonte: os autores.
Figura 24 - Estado inicial EXIBINDO / 
Fonte: os autores.
U
N
IC
ES
U
M
A
R
159
7 
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 em 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.
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 25 apresenta 
o 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
Figura 25 - Cadastrar filmes / Fonte: os autores.
U
N
ID
A
D
E 
5
160
A Figura 26 apresenta o diagrama de comunicação para cadastrar um novo cine-
ma. 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.
Cinema
1: Insere ( )( )
2: Valida ( )
3: Salva ( )
4: OK ( )Operador
Figura 26 - Diagrama de comunicação para cadastrar cinema / Fonte: os autores.
A Figura 27 apresenta o diagrama de comunicação para cadastrar um novo elen-
co. 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 27 - Diagrama de comunicação para inserir elenco / Fonte: os autores.
A Figura 28 apresenta o 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 a classe sala, que salva os dados e confirma a 
operação para o operador.
U
N
IC
ES
U
M
A
R
161
Sala Cinema
1: Insere ( )[ ]
2: Veri�ca entrada ( )
3: Veri�ca Cinema ( )
5: Salva ( )
6: OK ( ) 4: OK ( )Operador
Figura 28 - Diagrama de comunicação para inserir novas salas / Fonte: os autores.
A Figura 29 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 a 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 ( )
Figura 29 - Diagrama de comunicação para exibição do filme / Fonte: os autores.
U
N
ID
A
D
E 
5
162
A Figura 30 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 a 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
Filme Sala
1: Solicita Suspensão ( )
4: Altera Status ( )
5: Exclui Filme ( )
6: Salva ( )
2: Solicita Filme ( )
3: Informa Filme ( )
8: OK ( )
7: OK ( )
Figura 30 - Diagrama de comunicação para suspender a exibição do filme / Fonte: os autores.
U
N
IC
ES
U
M
A
R
163
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 criarmos 
um cenário do sistema; com ele, podemos verificar quais são os atores que inte-
ragem 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 
aodiagrama 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!
164
na prática
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.
165
aprimore-se
A LINGUAGEM DE MODELAGEM UNIFICADA (UML) E USE CASES
A UML (Unified Modelling Language - Linguagem de Modelagem Unificada) surgiu, nos 
últimos anos, da união de métodos anteriores para análise e projeto de sistemas 
orientados 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 modelagem visual estão: Booch 
(BOOCH, 1994), OMT (Object Modelling Technique) e OOSE (Object Oriented Software 
Engineering). A UML define um conjunto básico de diagramas e notações que permi-
tem representar as múltiplas perspectivas (estruturais / estáticas e comportamen-
tais / 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 (Sequê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 brevemen-
te alguns destes diagramas. Informações complementares sobre outros tipos de 
representações diagramáticas da UML podem ser encontradas em (BOOCH et al., 
1999; JACOBSON et al., 1999). O ambiente de projeto de moldes de injeção foi gene-
ricamente utilizado como exemplo para a representação de tais diagramas.
Diferente do RM-ODP, a UML oferece um suporte direto para o projeto e im-
plementaçã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 representação, tais como funcio-
nalidade, 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 processo baseado em Use Cases 
combinado com Booch, OMT e UML, para o desenvolvimento de sistemas orienta-
dos a objetos.
166
aprimore-se
Em ambos os processos, os Use Cases definem o primeiro nível de representa-
ção do sistema e resultam de uma fase de captura das "necessidades" a serem aten-
didas pelo mesmo. Os Use Cases representarão, num nível mais geral, as funciona-
lidades do sistema em desenvolvimento e guiarão todas as fases subsequentes de 
análise, projeto, implementação e testes do sistema computacional.
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).
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 princi-
pais (grupo de objetos com funcionalidade similar) do sistema em desenvolvimento. 
Com base nestes dois elementos, uma descrição geral de como as Categorias intera-
gem entre si para executar cada Use Case, pode ser representada por diagramas de 
Sequência. Esta fase é definida como análise do sistema onde tais representações 
podem ser utilizadas para um melhor esclarecimento e discussão com os usuários 
e responsáveis pela implementação do sistema. Numa fase seguinte, caracterizada 
com maior ênfase no projeto do sistema, busca-se um refinamento destas repre-
sentaçõ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 aspectos comportamentais dos objetos, através de diagramas de Estado e Tran-
sição e diagramas de Atividades.
Fonte: Costa (2001, p. 22-26).
167
eu recomendo!
167
eu recomendo!
Programação Orientada a Objetos com Java
Autor: 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, uti-
lizando o compilador-padrão e a máquina virtual. Ele foi especi-
ficamente projetado para o ensino introdutório da programação 
orientada a objetos, permitindo ao aluno criar objetos de qualquer classe e inte-
ragir 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.
livro
Existem duas versões para a ferramenta Astah Community, a versão professional 
e a community. Faça o download da versão Astah Community, pois esta é gratuita 
e suficiente para o que precisamos. Faça o download da ferramenta CASE para a 
elaboração dos diagramas inseridos neste livro no link a seguir: 
http://astah.net/download
Caso tenha dificuldades na confecção do diagrama de caso de uso, sugiro que 
assista ao vídeo da professora Decíola Fernandes, da Universidade Rural da Ama-
zônia. O vídeo apresenta um tutorial de quatro minutos, mostrando como usar as 
ferramentas. Acesse-o no link disponível em: 
https://www.youtube.com/watch?v=VMG0EOangKY 
Para aprofundar os conhecimentos sobre OO, leia a tese intitulada “Desenvolvi-
mento 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 em: 
http://www.coep.ufrj.br/~tarang/Simulight/Tese_Manzoni.pdf 
conecte-se
168
conclusão geral
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 
valia e 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(a) em sua vida 
acadêmica e profissional. Procuramos focar em elementos práticos e teóricos que 
contribuam para sua formação e aperfeiçoamento. Os exemplos de estudos de ca-
sos apresentados 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 
o(a) desmotivem, talvez, façam você até pensar em desistir, porém a persistênciao(a) levará à 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 leitura 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!
referências
169
BOOCH, G. Object-oriented Analysis and Design. San Francisco: Benjamin- Cummings, 1997.
COLEMAN, D. Desenvolvimento Orientado a Objetos: o Método Fusion. Rio de Janeiro: Cam-
pus, 1996.
COSTA, C. A. A aplicação da linguagem de modelagem unificada (UML) para o suporte ao pro-
jeto de sistemas computacionais dentro de um modelo de referência. Gestão e produção, v. 
8, n. 1, p. 19-36, abr. 2001. Disponível em: https://www.scielo.br/pdf/gp/v8n1/v8n1a02.pdf. 
Acesso em: 27 jul. 2020.
JACOBSON, I. Object Oriented Software Engineering. Boston: Addison-Wesley, 1995.
JUNIOR, A. P. de A.; CAMPOS, R. de. Definição de requisitos de software baseada numa arquite-
tura de modelagem de negócios. Produção, São Paulo, v. 18, n. 1, 2008. Disponível em: https://
www.scielo.br/pdf/prod/v18n1/a03v18n1.pdf. Acesso em: 27 jul. 2020.
MARTIN, J.; ODELL, J. J. Análise e Projeto Orientados a Objeto. São Paulo: Makron Books, 1995.
MEDEIROS, E. S. de. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Pearson 
Makron Books, 2004.
PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995. 
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. Porto Alegre: 
AMGH, 2011.
SHLAER, S.; MELLOR, S. J. Análise de Sistemas Orientada a Objetos. São Paulo: Makron Books, 1990. 
SILVEIRA, D. S.; SCHMITZ, E. A. Fast case: uma ferramenta case para o desenvolvimento visual 
de sistemas orientados a objetos. 1999. 4 f. Tese (Mestrado) — Instituto de Matemática / Nú-
cleo de Computação Eletrônica, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 1999.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
RUMBAUGH, J. Object Oriented Modeling and Design. New Jersey: Prentice Hall, 1991.
YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1990.
REFERÊNCIAS ONLINE
1 Em: https://ampersandcommerce.com/news/agile-test-driven-development-our-way/. Aces-
so em: 27 jul. 2020. 
2 Em: http://www.linhadecodigo.com.br/artigo/2958/como-fazer-um-plano-de-testes-basea-
do-em-casos-de-uso.aspx#ixzz3fJNU7NrE. Acesso em: 27 jul. 2020.
³ Em: http://michaelis.uol.com.br/busca?r=0&f=0&t=0&palavra=atributo. Acesso em: 27 jul. 
2020.
gabarito
170
UNIDADE 1
1. Maior grau de abstração, pois trata a 
realidade de forma natural, conside-
rando que o mundo real é formado por 
objetos.
Encapsulamento que adiciona segu-
rança à aplicação pelo fato de ocultar 
suas propriedades.
Herança permite o reuso do código, 
otimizando a produção da aplicação. 
Polimorfismo consiste na mudança do 
funcionamento de um método herda-
do de um ancestral.
2. Análise, projeto, implementação, teste, 
implantação, manutenção.
3. A.
4. São 13 diagramas ao todo, divididos em 
diagrama estruturais, que definem a es-
trutura estática do software, e os diagra-
mas comportamentais, que definem 
a dinâmica dos objetos. Os diagramas 
estruturais são: classes, pacotes, compo-
nentes, objetos, implantação e estrutu-
ra composta. Os diagramas comporta-
mentais são: caso de uso, estados, visão 
geral, comunicação, sequência, tempo-
rização.
5. A.
UNIDADE 2
1. Identificar a necessidade do usuário; 
executar análise econômica e técnica; 
atribuir funções ao hardware, ao soft-
ware, às pessoas, ao banco de dados e 
aos demais elementos do sistema; esta-
belecer as restrições de prazo e de cus-
to; criar uma definição de sistema que 
constitua a base para todo o trabalho 
subsequente.
2. O domínio do problema diz respeito 
ao contexto onde o sistema funcionará, 
portanto, o domínio é a área de alcan-
ce do sistema ou o seu escopo. Quando 
conhecemos o domínio, estabelecemos 
fronteiras, possibilitando a definição de 
objetivos claros.
3. Linguagem de modelagem correspon-
de à notação, que corresponde ao ponto 
principal da comunicação entre os sta-
keholders. Os processos são os passos 
que devem ser seguidos para construir 
o projeto. Um modelo de processo de 
software define a sequência em que as 
atividades do processo serão realizadas.
4. Como o modelo de processo em cas-
cata tem suas fases bem definidas, é 
necessário um amplo entendimento 
do domínio do problema para a sua 
utilização. O modelo de processo evo-
lucionário permite compreendermos 
o domínio do problema durante o de-
senvolvimento, portanto é mais indica-
do quando não há amplo domínio do 
problema.
5. O resultado será a implementação de 
um produto que não condiz com a ne-
cessidade do cliente.
6. Requisitos são descrições das neces-
sidades para o software. São objetivos 
ou restrições estabelecidas por clientes 
e usuários do sistema que definem as 
gabarito
171
diversas propriedades do sistema e são 
classificados como: funcionais (definem 
as funções do sistema, ou seja, o que se 
espera que o sistema realize) e não fun-
cionais (definem as características de 
qualidade que o sistema deve possuir).
UNIDADE 3
1. Não. A classe representa a abstração de 
um conjunto de objetos do mundo real 
que possui comportamentos e caracte-
rísticas comuns, o objeto é uma ocor-
rência da classe.
2. É uma característica da Orientação a 
Objetos que possibilita que a classe 
herde todas as características e com-
portamentos de outra classe.
3. A herança múltipla acontece quando 
uma classe é derivada de mais de uma 
superclasse, em que cada superclasse 
ou classe ancestral representa somente 
uma parte do conceito representado na 
subclasse ou classe filha.
4. Métodos e atributos declarados como 
protegidos são vistos pela própria classe 
e pelas classes derivadas. Já os métodos 
e atributos declarados como públicos 
são vistos por todas as classes.
5. Na agregação regular, uma classe é uma 
parte de outra, porém uma existe sem 
a outra. Já a agregação de composição 
é uma agregação de fato, pois o todo é 
composto pelas partes, e, quando o todo 
é destruído, as partes também serão, 
portanto, na agregação de composição, 
as partes não existem sem o todo.
6. É uma classe que surge a partir da as-
sociação de duas outras classes, em que 
a associação possui atributos próprios.
UNIDADE 4
1. O objetivo do diagrama de sequência é 
fornecer elementos para o refinamento 
do diagrama de classes a partir dos es-
tudos das interações entre os objetos, o 
que possibilita a identificação de rela-
ção entre as classes. Os principais ele-
mentos de sua notação é o ator, a time-
line ou linha da vida, as mensagens e o 
tempo de atividade.
2. O diagrama de estados mostra o com-
portamento das classes mais comple-
xas; esse diagrama é indicado para as 
classes que apresentam um número 
conhecido de estados, dessa forma, 
conseguimos prever o comportamen-
to do objeto por meio da mudança de 
estados.
3. Devemos utilizar o diagrama de co-
municação quando desejarmos saber 
quais são as classes e a ordem de envio 
de mensagens, sem nos preocuparmos 
com o tempo em que ocorrem as men-
sagens.
4. Ambos os diagramas, diagramas de se-
quência e comunicação, mostram-nos 
as mensagens que são trocadas entre 
as classes e objetos, porém o diagrama 
de sequência considera o tempo em 
que acontece, as mensagens, e o dia-
grama de comunicação considera a or-
dem em que elas acontecem.
gabarito
172
UNIDADE 5
1. Diagrama de objetos para as classes cinema e sala.
CINEMA
• Cinema_id: “1”
• Nome: “Cine XV”
• Endereço: “Rua Flamingos, 381”
• Lotação: “150”
• Bairro: “Centro”
• Cidade: “Apucarana”
• UF: “PR”
• CEP: “86800-00”
1 1...
SALA
• Sala_id: “2”
• Horário: “14:00”
• Capacidade: 75
2. Diagrama de implantação para a Distribuidora Fênix
Browser
Operador
<<HTTP>>
XAMPP
Servidor Web<<SSL>>
<<MySQL>>
Sitema Gerenciador de Banco de Dados 
gabarito
173
3. Diagrama de componentes
Pesquisar Interface
Xampp browserMysql
4. Diagrama de atividades
OPERADOR SISTEMA
Solicita a
exibição
Altera o
status
Informa
horário
Encerra
Validação
Mostra
interface
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
anotações
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
anotações
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
anotações
	INTRODUÇÃO
	AO ESTUDO 
	de orientação a objetos
	CASOS
	DE USO
	DIAGRAMA
	DE CLASSES
	DIAGRAMAS DE
	SEQUÊNCIA,
	ESTADO
	e colaboração
	ESTUDO 
	DE CASO
	Botão 1: