Professores e Trajetória Profissional

Prévia do material em texto

PROGRAMAÇÃO III 
PROFESSORES
Dr. Edson Alves de Oliveira Junior
Me. Andre Abdala Noel
Me. Márcia Cristina Dadalto Pascutti 
Me. Rafael Alves Florindo
Esp. Janaina Aparecida de Freitas
Esp. Victor de Marqui Pedroso
EXPEDIENTE
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. 
Núcleo de Educação a Distância. NOEL, Andre Abdala; OLIVEIRA JR, 
Edson Alves de; FREITAS, Janaina Aparecida de; PASCUTTI, Márcia Cris-
tina Dadalto; FLORINDO, Rafael Alves; PEDROSO, Victor de Marqui.
Programação III. 
Andre Abdala Noel, Edson Alves de Oliveira Junior, Janaina Apa-
recida de Freitas, Márcia Cristina Dadalto Pascutti, Rafael Alves 
Florindo e Victor de Marqui Pedroso.
Maringá - PR.: UniCesumar, 2020. 
216 p.
“Graduação - EaD”. 
1. Programação 2. Software 3. Sistema. EaD. I. Título. 
FICHA CATALOGRÁFICA
NEAD - Núcleo de Educação a Distância
Av. Guedner, 1610, Bloco 4 Jd. Aclimação - Cep 87050-900 | Maringá - Paraná
www.unicesumar.edu.br | 0800 600 6360 
Coordenador(a) de Conteúdo 
Danillo Xavier Saes
Projeto Gráfico e Capa
Arthur Cantareli, Jhonny Coelho
e Thayla Guimarães
Editoração
Sabrina Maria Pereira de Novaes
Design Educacional
Rossana Costa Giani
Revisão Textual
Ariane Andrade Fabreti
Ilustração
Marta Sayuri Kakitani
Fotos
Shutterstock CDD - 22 ed. 005.1 
CIP - NBR 12899 - AACR/2
ISBN 978-85-459-1712-0
Impresso por: 
Bibliotecário: João Vivaldo de Souza CRB- 9-1679
Diretoria Executiva Chrystiano Mincoff, James Prestes, Tiago Stachon Diretoria de Design Educacional 
Débora Leite Diretoria de Graduação Kátia Coelho Diretoria de Permanência Leonardo Spaine Diretoria 
de Pós-graduação, Extensão e Formação Acadêmica Bruno Jorge Head de Produção de Conteúdos Celso 
Luiz Braga de Souza Filho Gerência de Produção de Conteúdo Diogo Ribeiro Garcia Gerência de Projetos 
Especiais Daniel Fuverki Hey Supervisão do Núcleo de Produção de Materiais Nádila Toledo Supervisão 
de Projetos Especiais Yasminn Zagonel
NEAD - NÚCLEO DE EDUCAÇÃO A DISTÂNCIA
Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de 
Matos Silva Filho Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva Pró-Reitor de Ensino de 
EAD Janes Fidélis Tomelin Presidente da Mantenedora Cláudio Ferdinandi 
DIREÇÃO UNICESUMAR
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 dezenasde 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
Dr. Edson Alves de Oliveira Junior
Pós-Doutorando em Experimentação em Computação Forense na PUC-RS. Possui 
doutorado em Ciências de Computação e Matemática Computacional pelo Instituto 
de Ciências Matemáticas e de Computação da Universidade de São Paulo (ICMC-
-USP). Possui mestrado e graduação em Ciência da Computação pela Universidade 
Estadual de Maringá (UEM). Professor adjunto do Departamento de Informática 
(DIN) da Universidade Estadual de Maringá (UEM). Possui experiência na área de 
Ciência da Computação, com ênfase em Engenharia de Software, atuando, principal-
mente, nos seguintes temas: Processos de Software, Linha de Produto de Software, 
Avaliação de Arquitetura de Software e de Linhas de Produto, Linha de Processo 
de Software, Gerenciamento de Variabilidades, Métricas e Modelos de Software, 
Frameworks, Modelagem e Metamodelagem UML, Ambientes de Desenvolvimento 
e Tecnologias Java.
http://lattes.cnpq.br/8717980588591239.
Me. Márcia Cristina Dadalto Pascutti
Possui mestrado em Ciência da Computação pela Universidade Federal do Rio Gran-
de do Sul (2002) e graduação em Processamento de Dados pela Universidade Es-
tadual de Maringá (1989). Atualmente, é professora no Instituto Federal do Paraná 
- Campus Umuarama, e está cursando o doutorado na PUC-PR. Atua, principalmente, 
nos seguintes temas: arquitetura de computadores, engenharia de software, proces-
samento de imagens, reconhecimento de padrões, visão computacional.
http://lattes.cnpq.br/0297217008123332
Me. Andre Abdala Noel
Mestre em Ciência da Computação pela Universidade Estadual de Maringá, com 
ênfase em sistemas de computação e bacharel em Ciência da Computação pela 
Universidade Estadual de Maringá.
É professor e programador. Possui boa experiência em programação, aplicando, 
também, na docência superior, desde 2008. Autor do site Vida de Programador, 
mantém-se ativo na comunidade de desenvolvedores.
http://lattes.cnpq.br/9035823171388697
P R O F I S S I O N A LT R A J E T Ó R I A
Esp. Janaina 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 UNICEUMA (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 
como professora mediadora, professora conteudista em gravação de aulas ao vivo e 
gravação de aulas 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 Implementação e Teste de Software. Além disso, tem experiência em inicia-
tiva privada na área de Análise de Sistemas e Testes de Software.
http://lattes.cnpq.br/4906244382612830
Esp. Victor de Marqui Pedroso
Possui Pós-Graduação em Banco de dados Oracle e DB2 pelo Centro Universitário 
de Maringá (2009) e graduação em Tecnologia em Processamento de Dados pelo 
Centro Universitário de Maringá (2003). Tem experiência como analista de sistemas, 
documentador, homologador e programador de software. Possui experiência em 
desenvolvimento utilizando a ferramenta Delphi. Já trabalhou como Professor Me-
diador e, atualmente, trabalha como Professor Formador dos cursos de Análise e 
Desenvolvimento de Sistemas e Sistemas para Internet, ministrando as disciplinas 
de Banco de Dados e Design de Interação.
http://lattes.cnpq.br/8611697826182780
Me. Rafael Alves Florindo
Mestrado em Gestão do Conhecimento nas Organizações na linha de pesquisa Edu-
cação e Conhecimento pela PPGGCO – Unicesumar – Centro Universitário de Maringá 
(2017). É especialista em Desenvolvimento de Sistema para Web pela UEM – Universi-
dade Estadual de Maringá (2008). Graduado em Ciência da Computação pela FAI – Fa-
culdadesAdamantinenses Integrada. Pós-graduando em Docência no Ensino Superior: 
Tecnologias Educacionais e Inovação e Banco de Dados pela Unicesumar. Professor 
– Ensino Técnico pela SEED-PR desde 2009. Professor autor, formador e mediador do 
EAD - Ensino a Distância da Unicesumar desde 2014, nos Cursos de TI: Sistemas para 
Internet, Análise e Desenvolvimento de Sistemas, Gestão da Tecnologia da Informação 
e Engenharia de Software. Professor presencial da Faculdade Unifamma desde 2019, 
no curso de Engenharia de Software e Sistema de Informação.
http://lattes.cnpq.br/7246554526271622
D A D I S C I P L I N AA P R E S E N TA Ç Ã O
PROGRAMAÇÃO III
Seja bem-vindo(a)!
Prezado(a) acadêmico(a), é com muito prazer que lhe apresentamos o livro de Programação III.
Este livro está organizado em cinco unidades e todas estão, estreitamente, relacionadas. Na 
Unidade 1, apresentaremos alguns conceitos referentes à disciplina. Você notará, durante a 
leitura das outras unidades, que esses conceitos são utilizados com frequência.
A engenharia de software surgiu mediante a necessidade de tornar o desenvolvimento de 
software confiável, com etapas bem definidas, custo e cronograma previsíveis, fatos que não 
aconteciam até 1968, quando o termo engenharia de software foi proposto. Além disso, gosta-
ríamos de ressaltar que o software compreende, além dos programas, toda a documentação 
referente a ele, e a engenharia de software é a disciplina que trata dessa documentação.
Na Unidade 2, daremos início à aplicação dos conhecimentos da engenharia de software na 
linguagem de programação Java. Abordaremos, primeiramente, os conceitos relacionados 
a modificadores de acesso e a encapsulamento. Esses recursos formam um dos pilares da 
programação orientada a objetos, recurso este que garante a integridade e o controle de 
acesso aos atributos e métodos.
Continuando a aplicação dos conceitos de engenharia de software, na Unidade 3, abarcaremos 
mais dois pilares da programação orientada a objetos: a herança e o polimorfismo. Ambos 
estão relacionados, uma vez que, a partir do recurso da herança, ou seja, quando o filho herda 
A P R E S E N TA Ç Ã O D A D I S C I P L I N A
características do pai, é possível especializar alguma operação. Nesse caso, temos que o filho 
pode implementar uma ação que o pai desenvolve, contudo ela pode ser diferente ou igual.
Na Unidade 4, abordaremos algumas regras de desenvolvimento. A primeira será as classes 
abstratas, que funcionarão como modelo de desenvolvimento para outras classes que estão 
recebendo herança dela, ou seja, a classe que herda de uma classe abstrata deve implementar 
os métodos que estão marcados para serem implementados nas classes filhas. Outra regra é 
a interface, esta rege um contrato entre analista e desenvolvedor; aqui, quando construímos 
uma interface e uma classe a implementa, ela é obrigada a implementar todos os métodos, 
funcionando, assim, como um contrato.
Finalmente, chegamos à última unidade do nosso material. Esta unidade é o fechamento 
das etapas do processo de software, onde realizaremos a implementação de um estudo de 
caso por meio da realização da nova análise desse estudo, agora, na visão do desenvolvedor.
Assim, chegamos ao final do nosso livro. Esperamos, sinceramente, que a sua leitura 
seja agradável e que este conteúdo possa contribuir para o seu crescimento pessoal, 
acadêmico e profissional.
Í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
MODELAGEM DE 
SISTEMAS
10
MODIFICADORES JAVA 
E ENCAPSULAMENTO
45
78
HERANÇA E 
POLIMORFISMO
115
CLASSES ABSTRATAS 
E INTERFACES
150
ESTUDO DE CASO: 
ANÁLISE CLÍNICA
202
CONCLUSÃO GERAL
1
MODELAGEM DE
SISTEMAS
PLANO DE ESTUDO 
A seguir, apresentam-se as aulas que você estudará nesta unidade: • Modelagem de sistemas • Ferra-
mentas CASE (Computer-Aided Software Engineering) • Introdução à UML (Unified Modeling Langua-
ge) • Conceitos básicos de orientação a objetos • Diagrama de classes.
OBJETIVOS DE APRENDIZAGEM 
• Expor a importância da modelagem de sistemas • Entender as Ferramentas CASE (Computer-Aided 
Software Engineering) • Entender a UML (Unified Modeling Language ou Linguagem de Modelagem 
Unificada) • Apresentar os conceitos básicos de orientação a objetos • Entender a estrutura do sistema 
por meio de elementos, tais como classes, atributos e associações entre os objetos.
PROFESSORES 
Dr. Edson Alves de Oliveira Junior
Me. Andre Abdala Noel
Me. Márcia Cristina Dadalto Pascutti 
Me. Rafael Alves Florindo 
Esp. Janaina Aparecida de Freitas
Esp. Victor de Marqui Pedroso
INTRODUÇÃO
Caro(a) aluno(a), nesta primeira unidade, você verá uma revisão dos 
conceitos de modelagem de sistema. Este é o processo de elaboração de 
modelos abstratos de um sistema, normalmente, representado por meio 
de um diagrama, em que cada um desses modelos apresenta uma visão 
ou uma perspectiva diferente do sistema (SOMMERVILLE, 2011). Esses 
modelos, normalmente, são elaborados utilizando uma notação gráfica, 
que, em nosso caso, será a UML(Unified Modeling Language ou Lingua-
gem de Modelagem Unificada).
A UML define, em sua versão atual, 21 tipos de diagramas para o uso 
na modelagem de software. Nesta unidade, veremos, somente, o diagrama 
de classe. Se você quiser conhecer os outros, consulte alguns livros relacio-
nados nas referências. Como nosso objetivo, aqui, é mostrar a modelagem 
de um sistema, utilizaremos, somente, esse diagrama.
Primeiramente, exporemos a importância de realizar a modelagem de 
um sistema de software. Esta se baseia na utilização de notações gráficas 
e textuais com o objetivo de construir modelos que representem as partes 
essenciais de um sistema. Depois, passaremos a entender as Ferramentas 
CASE (Computer-aided Software Engineering) e UML (Unified Modeling 
Language ou Linguagem de Modelagem Unificada). Todos os artefatos de 
software produzidos durante a modelagem serão usados como base para 
as fases seguintes do ciclo de desenvolvimento de sistemas, como as fases 
de projeto e de implementação. 
Em seguida, apresentaremos a você os conceitos básicos de Orientação a 
Objetos (OO) para entender, por meio de elementos, a estrutura do sistema. 
Por último, mostraremos o diagrama de classes. Este é o mais importante 
e, também, o mais utilizado da UML, além de servir de apoio para a maioria 
dos diagramas. O diagrama de classes define a estrutura das classes identi-
ficadas para o sistema, mostrando os atributos e os métodos de cada uma, 
além de estabelecer como elas se relacionam e trocam informações entre si. 
U
N
ID
A
D
E 
1
12
1 
MODELAGEM DE 
SISTEMAS
Caro(a) aluno(a), a necessidade de planejamento no desenvolvimento de sistemas 
de informação leva ao conceito de modelagem de software, ou seja, antes de o 
software ser concebido, deve-se criar um modelo para ele. Um modelo pode ser 
entendido como uma representação idealizada de um sistema a ser construído. 
São exemplos: maquetes de edifício, plantas de casa, fluxogramas etc.
A modelagem de sistemas de software se baseiana utilização de notações gráficas 
e textuais com o objetivo de construir modelos que representem as partes essenciais 
de um sistema. São várias as razões para utilizar modelos na construção de sistemas:
1. No desenvolvimento do software, usamos desenhos gráficos denomina-
dos diagramas, a fim de representar o comportamento do sistema. Esses 
diagramas seguem um padrão lógico e possuem uma série de elementos 
gráficos que carregam um significado pré-definido.
2. Apesar de um diagrama expressar diversas informações de forma gráfica, 
em diversos momentos, há a necessidade de adicionar informações em 
forma de texto, com o objetivo de explicar ou definir certas partes. A 
modelagem de um sistema em forma de diagrama, em conjunto com a 
informação textual, forma a documentação de um sistema de software.
3. O rápido crescimento da capacidade computacional das máquinas re-
sultou na demanda de sistemas de software cada vez mais complexos, 
que tirassem proveito de tal capacidade. Por sua vez, o surgimento desses 
U
N
IC
ES
U
M
A
R
13
sistemas gerou a necessidade de reavaliação no desenvolvimento de siste-
mas. Desde o aparecimento do primeiro computador até os dias de hoje, 
as técnicas para a construção de sistemas computacionais têm evoluído 
para suprir as necessidades do desenvolvimento de software. A seguir, a 
Figura 1 ilustra um parâmetro histórico da evolução digital:
O processo de desenvolvimento de software é uma atividade bastante complexa. 
Isto se reflete no alto número de projetos de software que não chegam ao fim ou que 
Os sistemas de software eram bastante simples e, 
dessa forma, as técnicas de modelagem também. Era 
a época dos �uxogramas e diagramas de módulos.
Nesta época, houve a expansão do mercado 
computacional. Sistemas complexos começavam 
a surgir e, por consequência, modelos mais 
robustos foram propostos. Além disso, surge a 
programação estruturada e, no �nal da década, a 
análise e o projeto estruturado.
Surge a necessidade de interfaces 
homem-máquina mais so�sticadas, o que 
originou a produção de sistemas de software 
mais complexos. A análise estruturada se conso-
lidou na primeira metade da década, e, em 1989, 
Edward Yourdon lançou o livro Análise Estrutura-
da Moderna, tornando-se referência no assunto.
Inicia-se um novo paradigma de modelagem, a 
análise orientada a objetos, como resposta para 
as di�culdades encontradas na aplicação da 
análise estruturada em certos domínios de 
aplicação.
O paradigma da orientação a objetos atinge a sua 
maturidade. Os conceitos de padrões de projetos 
(design patterns), frameworks de desenvolvimen-
to, componentes e padrões de qualidade 
começam a ganhar espaço. Surge, também, a 
Linguagem de Modelagem Uni�cada (UML), que 
é a ferramenta de modelagem utilizada no 
desenvolvimento atual de sistemas.
1950/60
Era a época dos �uxogramas e 
diagramas de módulos
1970
Expansão do mercado 
tecnológico
1980
Sistema da interface de 
usuário
1990
Novo paradigma de 
modelagem de sistemas de 
software
1990 e atualidade
Maturidade Digital
Figura 1 - Parâmetros históricos da evolução dos modelos na construção de sistemas.
Fonte: os autores.
U
N
ID
A
D
E 
1
14
Modelagem de sistema é o processo de desenvolvimento de modelos abstratos de um 
sistema, em que cada modelo apresenta uma visão ou perspectiva diferente desse. A 
modelagem, geralmente, representa o sistema com algum tipo de notação gráfica que, 
atualmente, quase sempre, é baseada em notações de UML (linguagem de modelagem 
unificada, do inglês Unified Modeling Language). Os modelos são usados durante o pro-
cesso de engenharia de requisitos para ajudar a extrair os requisitos do sistema; duran-
te o processo de projeto, são usados para descrever o sistema aos engenheiros que o 
implementam; e, após isso, são usados para documentar a estrutura e a operação do 
sistema. Um modelo é uma abstração do sistema a ser estudado, e não uma representa-
ção alternativa dele. Idealmente, uma representação deve manter todas as informações 
sobre a entidade representada. Uma abstração, deliberadamente, simplifica e seleciona 
as características mais salientes.
Fonte: adaptado de Sommerville (2011, p. 96).
explorando Ideias
extrapolam recursos de tempo e de dinheiro alocados. Em um estudo clássico sobre 
projetos de desenvolvimento de software, realizado em 1994, constatou-se que:
 ■ Porcentagem de projetos que terminam dentro do prazo estimado: 10%.
 ■ Porcentagem de projetos que são descontinuados antes de chegarem 
ao fim: 25%.
 ■ Porcentagem de projetos acima do custo esperado: 60%.
 ■ Atraso médio nos projetos: um ano.
Os modelos construídos na fase de análise devem ser, cuidadosamente, validados e 
verificados. O objetivo da validação é o de assegurar que as necessidades do cliente es-
tão sendo atendidas. Nessa atividade, os analistas apresentam os modelos criados para 
representar o sistema aos futuros usuários a fim de que esses modelos sejam validados.
Já a verificação objetiva analisar se os modelos construídos estão em conformi-
dade com os requisitos definidos. Na verificação dos modelos, é analisada a exatidão 
de cada um, separadamente, bem como a consistência entre eles. A verificação é uma 
etapa típica da fase de projeto e é a próxima etapa do desenvolvimento de software.
Caro(a) aluno(a), utilizaremos a UML para realizar a modelagem de sistemas. 
Nesse primeiro tópico, estudamos alguns conceitos relacionados à orientação 
de objetos e fizemos uma introdução à linguagem UML. Lembre-se de que os 
artefatos de software produzidos durante a modelagem servirão de base para a 
fase seguinte do ciclo de desenvolvimento de sistemas, ou seja, a fase de projeto.
U
N
IC
ES
U
M
A
R
15
2 
FERRAMENTAS 
CASE 
(Computer-Aided
Software Engineering)
Uma ferramenta CASE é um software que pode ser utilizado para apoiar as ati-
vidades do processo de software, como a engenharia de requisitos, o projeto, o 
desenvolvimento de programa e os testes. As ferramentas CASE podem incluir 
editores de projeto, dicionários de dados, compiladores, depuradores, ferramentas 
de construção de sistemas, entre outros (SOMMERVILLE, 2011).
Sommerville (2011) expõe alguns exemplos de atividades que podem ser 
automatizadas utilizando a CASE. Dentre elas, estão:
1. O desenvolvimento de modelos gráficos de sistemas enquanto parte das 
especificações de requisitos ou do projeto de software.
2. A compreensão de um projeto utilizando um dicionário de dados que 
carrega informações sobre as entidades e a sua relação em um projeto.
3. A geração de interfaces com usuários a partir de uma descrição gráfica 
da interface, que é criada interativamente pelo usuário.
4. A depuração de programas pelo fornecimento de informações sobre um 
programa em execução.
5. A tradução automatizada de programas a partir da antiga versão de uma 
linguagem de programação, como a Cobol, para uma versão mais recente.
A tecnologia CASE está, atualmente, disponível para a maioria das atividades de 
rotina no processo de software, proporcionando, assim, algumas melhorias na 
qualidade e na produtividade de software.
U
N
ID
A
D
E 
1
16
Existem, basicamente, duas formas de classificação geral para as ferramentas 
CASE. A primeira delas divide-se em: Upper CASE, Lower CASE, Integrated-
-CASE e Best in Class:
 ■ Upper CASE ou U-CASE ou Front-End: são as ferramentas voltadas 
para as primeiras fases do processo de desenvolvimento de sistemas, 
como a análise de requisitos, o projeto lógico e a documentação. São uti-
lizadas por analistas e pessoas mais interessadas na solução do problema 
do que na implementação.
 ■ Lower CASE ou L-CASE ou Back-End: são, praticamente, o oposto das 
ferramentas Upper CASE. Elas oferecem suporte nas últimas fases do 
desenvolvimento, como a codificação, os testes e a manutenção.
 ■ Integrated CASE ou I-CASE: são ferramentas que, além de englobarem 
características das Upper e Lower CASEs, oferecem, ainda, outras carac-
terísticas, como controle de versão,por exemplo. Entretanto são utiliza-
das somente em projetos de desenvolvimento muito extensos, por serem 
bastante caras e difíceis de operar.
 ■ Best in Class ou Kit de Ferramenta: semelhante às I-CASEs, os Kits de Fer-
ramenta, também, acompanham todo o ciclo de desenvolvimento. Entretanto 
possuem a propriedade de conjugar a sua capacidade a outras ferramentas 
externas complementares, as quais variam de acordo com as necessidades do 
usuário. Para melhor entendimento, podemos compará-las a um computador 
sem o kit multimídia: as Best in Class seriam o computador que funciona nor-
malmente, enquanto as outras ferramentas fariam o papel do kit multimídia, 
promovendo mais potencial de trabalho para a máquina. São mais usadas 
para o desenvolvimento corporativo, apresentando controle de acesso, versão 
e repositórios de dados, entre outras características.
A segunda forma divide as ferramentas CASE em orientadas à função e em orien-
tadas à atividade:
 ■ Orientadas à função: seriam as Upper CASE e Lower CASE. Baseiam-
-se na funcionalidade das ferramentas, ou seja, são as que têm funções 
diferentes no ciclo de vida de um projeto. Por exemplo, a representação, 
apenas, do Diagrama de Entidades e Relacionamentos (DER) ou do Dia-
grama de Fluxo de Dados (DFD).
 ■ Orientadas à atividade: seriam as Best in Class e as I-CASE, as quais pro-
cessam atividades, tais como especificações, modelagem e implementação.
U
N
IC
ES
U
M
A
R
17
Além dos ambientes completos de engenharia de software, ferramentas de solução pon-
tual que resolvem tudo, desde reunião de requisitos até refatoração de projeto/código e 
teste, continuarão a evoluir e se tornarão mais capazes em funcionalidade. 
(Roger Pressman e Bruce Maxim)
pensando juntos
3 
INTRODUÇÃO 
À UML
(Unified Modeling
Language)
Segundo Booch, Rumbaugh e Jacobson (2006, p. 13), “a UML (Unified Modeling 
Language ou Linguagem de Modelagem Unificada) é uma linguagem-padrão 
para a elaboração da estrutura de projetos de software”, podendo ser utilizada 
para visualização, especificação, construção e documentação de artefatos de soft-
ware, por meio do paradigma de orientação a objetos. Além disso, a UML é a 
linguagem-padrão de modelagem de software adotada, internacionalmente, pela 
indústria de engenharia de software (GUEDES, 2007).
A UML não é uma linguagem de programação, mas uma linguagem de modelagem 
cuja meta é auxiliar os engenheiros de software a definirem as características do softwa-
re, tais como: os seus requisitos, o seu comportamento, a sua estrutura lógica, a dinâmica 
de seus processos e, até mesmo, as suas necessidades físicas em relação ao equipamento 
em que o sistema deverá ser implantado. Todas essas características são definidas por 
meio da UML antes do início do desenvolvimento do software (GUEDES, 2007).
U
N
ID
A
D
E 
1
18
De acordo com Booch, Rumbaugh e Jacobson (2006), a UML é apenas uma 
linguagem de modelagem e, também, é independente de processo de software, 
visto que pode ser utilizada em modelo cascata, em desenvolvimento evolucioná-
rio ou em qualquer outro processo utilizado para o desenvolvimento do software.
A notação UML utiliza diversos símbolos gráficos, existindo uma se-
mântica bem definida para cada um deles, o que permite elaborar diversos 
modelos. Além disso, a UML tem sido empregada, de maneira efetiva, em 
sistemas cujos domínios abrangem os sistemas de informações corporativos, 
os serviços bancários e os financeiros, os transportes, os serviços distribuídos 
baseados na web, entre outros. No entanto ela não se limita à modelagem de 
software, pois pode modelar sistemas, tais como o fluxo de trabalho no sis-
tema legal, a estrutura e o comportamento de sistemas de saúde e o projeto 
de hardware (BOOCH; RUMBAUGH; JACOBSON, 2006).
Ferramentas Case baseadas na Linguagem UML
Nesta unidade, já constatamos que as ferramentas CASE (Computer-Aided Soft-
ware Engineering – Engenharia de Software Auxiliada por Computador, em por-
tuguês) são softwares que, de alguma forma, colaboram na realização de uma ou 
mais atividades realizadas durante o processo de desenvolvimento de software. 
Agora, veremos alguns exemplos de ferramentas CASE que suportam a UML, a 
qual é, em geral, a sua principal característica. Existem várias delas no mercado, 
dentre as quais podemos destacar:
 ■ Rational Rose: esta ferramenta foi desenvolvida pela Rational Software 
Corporation, empresa que estimulou a criação da UML, sendo a primeira 
ferramenta CASE baseada nessa linguagem. Atualmente, a Rational Rose 
é bastante usada pelas empresas desenvolvedoras de software. Ela permite 
a modelagem dos diversos diagramas da UML e a construção de modelos 
de dados com a possibilidade de exportação para a construção da base 
de dados ou a realização de engenharia reversa de uma base de dados 
existente. Em 20 de fevereiro de 2003, a empresa Rational foi adquirida 
pela IBM, e a ferramenta foi renomeada como IBM Rational Architect. 
U
N
IC
ES
U
M
A
R
19
 ■ Astah Professional: é uma ferramenta para a criação de diagramas UML 
e possui uma versão gratuita, o Astah Community, bem como outras ver-
sões pagas. A versão gratuita possui algumas restrições de funções, porém, 
para as que necessitaremos nesta unidade, ela será suficiente. Portanto, 
será essa a ferramenta que utilizaremos para modelar os diagramas da 
UML que aprenderemos. Anteriormente, ela era conhecida como Jude.
 ■ Visual Paradigm for UML ou VP-UML: esta ferramenta oferece uma 
versão que pode ser baixada gratuitamente, a Community Edition, porém 
ela não suporta todos os serviços e opções disponíveis nas versões stan-
dard ou professionais da ferramenta. Para quem deseja praticar a UML, 
a versão gratuita é uma boa alternativa, apresentando um ambiente ami-
gável e de fácil compreensão. 
 ■ Enterprise Architect: esta ferramenta não possui edição gratui-
ta como as anteriores, mas é uma das que mais oferecem recursos 
compatíveis com a UML 2.
O importante, em nossos estudos, é que você consiga entender como se inicia a 
modelagem do seu sistema. Para tanto, queremos que a informação não fique, 
apenas, anotada em um documento, mas que você facilite o processo de desen-
volvimento utilizando os recursos de modelagem e de construção de diagramas.
U
N
ID
A
D
E 
1
20
A UML é, totalmente, baseada no paradigma de Orientação a Objetos (OO). 
Sendo assim, para compreendê-la corretamente, precisamos, antes, estudar alguns 
dos conceitos relacionados à orientação a objetos.
Objetos
Segundo Melo (2004), um objeto é qualquer coisa, em forma concreta ou abstrata, 
que exista física ou apenas conceitualmente no mundo real. São exemplos de ob-
jetos: cliente, professor, carteira, caneta, carro, disciplina, curso, caixa de diálogo. 
Além disso, eles possuem características e comportamentos.
Classes
Uma classe é uma abstração de um conjunto de objetos que possuem os mesmos 
tipos de características e comportamentos, sendo representada por um retân-
gulo que possui três divisões. A primeira divisão armazena o nome da classe; a 
segunda, os atributos (características); enquanto a terceira carrega os métodos.
Geralmente, uma classe possui atributos e métodos, mas é possível encontrar 
aquelas com apenas uma dessas características ou, até mesmo, nenhuma, quando 
se trata de classes abstratas. A Figura 2 apresenta um exemplo de classe:
4 
CONCEITOS BÁSICOS 
DE ORIENTAÇÃO 
a Objetos
U
N
IC
ES
U
M
A
R
21
De acordo com Melo (2004), o momento inicial para 
a identificação de classes, em um documento de re-
quisitos, é assinalar os substantivos. Note que esses 
substantivos podem levar a objetos físicos (cliente, 
livro, computador) ou a objetos conceituais (reserva, 
cronograma, norma). Em seguida, é preciso identifi-
car, somente, aqueles que possuem importância para 
o sistema, verificando o que, realmente, consiste em objeto e o que consiste em 
atributo. Ainda, é preciso fazer nova análise dos requisitos para identificar as classes 
implícitas no contextotrabalhado, excluir classes parecidas ou juntar duas classes 
em uma. Vale a pena ressaltar que esse processo será iterativo, sem a possibilidade 
de definir todas as classes de uma só vez.
Atributos
Uma classe, normalmente, possui atributos que representam as suas característi-
cas, as quais costumam variar de um objeto a outro, como o nome de um objeto 
da classe cliente ou a cor em um objeto da classe carro, por exemplo. Tais aspectos 
são os responsáveis por diferenciar um objeto de outro da mesma classe.
De acordo com Guedes (2007), na segunda divisão da classe, aparecem os 
atributos. Cada atributo deve possuir um nome e, eventualmente, o tipo de dado 
que armazena, por exemplo, integer, float ou char. Assim, a classe especifica a 
estrutura de um objeto sem informar quais serão os seus valores. Em relação ao 
objeto, esse corresponde à instância de uma classe, em determinado momento. 
Apresentaremos um exemplo para facilitar o seu entendimento:
Uma classe pessoa possui os atributos: nome, sexo e data de nascimento. Essa 
classe pode ter um objeto ou uma instância com 
os seguintes valores para cada atributo, respec-
tivamente: Márcia, feminino, 22/03/1969. Dessa 
forma, em um sistema, devemos trabalhar com 
as instâncias (objetos) de uma classe, pois os va-
lores de cada atributo são carregados nas ins-
tâncias (MELO, 2004). A figura, a seguir, mostra 
um exemplo de classe com atributos:
Cliente
Figura 2 - Exemplo de classe.
Fonte: os autores.
Figura 3 - Exemplo de classe com 
atributos / Fonte: os autores.
Pessoa
- nome : string
- sexo : string
- data_nascimento : date
+ operation1() : void
U
N
ID
A
D
E 
1
22
Métodos
Métodos são processos ou serviços realizados por uma classe e disponibilizados 
para o uso de outras classes em um sistema. Além disso, devem ficar armazenados 
na terceira divisão da classe. Os métodos são as atividades que a instância de uma 
classe pode executar (GUEDES, 2007).
Um método pode ou não receber parâmetros (valores que são utilizados du-
rante a execução do método) bem como retornar 
valores os quais podem representar o resultado da 
operação executada ou somente indicar se o pro-
cesso foi concluído com sucesso. Assim, um méto-
do representa um conjunto de instruções que são 
executadas quando o método é chamado. Um ob-
jeto da classe cliente, por exemplo, pode executar a 
atividade de incluir novo cliente. A Figura 4 apre-
senta um exemplo de uma classe com métodos:
Visibilidade
De acordo com Guedes (2007), a visibilidade é um símbolo que antecede um 
atributo ou um método e é utilizada para indicar o seu nível de acessibilidade. 
Existem, basicamente, três modos de visibilidade: o público, o protegido e o pri-
vado. Saiba mais sobre cada um nos tópicos a seguir, na Figura 5:
Figura 5 - Modos de visibilidade / Fonte: os autores.
Cliente
- nome : string
- endereço : string
- cidade : string
- UF : char
- CEP : char
+ incluirNovoCliente() : void
+ atualizarCliente() : void
Figura 4 - Exemplo de classe com 
métodos / Fonte: os autores.
O símbolo mais (+) 
indica visibilidade 
pública, ou seja, 
signi�ca que o 
atributo ou o 
método pode ser 
utilizado por objetos 
de qualquer classe.
O símbolo sustenido 
(#) indica que a 
visibilidade é 
protegida, ou seja, 
determina que apenas 
objetos da classe 
possuidora do atributo 
ou do método ou de 
suas subclasses 
podem acessá-lo.
O símbolo menos (-) 
indica que a 
visibilidade é 
privada, ou seja, 
somente os objetos 
da classe possuidora 
do atributo ou do 
método poderão 
utilizá-lo.
(+) (#) (-)
U
N
IC
ES
U
M
A
R
23
Note que, no exemplo da classe cliente, tanto os atributos quanto os 
métodos apresentam a sua visibilidade representada à esquerda de seus 
nomes. Assim, os atributos nome, sexo e data_nascimento possuem visi-
bilidade privada, pois apresentam o símbolo de menos (-) à esquerda da 
sua descrição. Já os métodos IncluirNovoCliente() e AtualizarCliente() 
apresentam visibilidade pública, assim como indica o símbolo +, acres-
centado à esquerda de sua descrição.
Herança (generalização/especialização)
A herança permite que as classes de um sistema compartilhem atributos e mé-
todos, otimizando, assim, o tempo de desenvolvimento com a diminuição de 
linhas de código, o que facilita futuras manutenções (GUEDES, 2007). A herança 
(ou generalização/especialização) acontece entre classes gerais (chamadas de 
superclasses ou classes-mãe) e classes específicas (chamadas de subclasses ou 
classes-filha) (BOOCH; RUMBAUGH; JACOBSON, 2006).
A herança significa que os objetos da subclasse podem ser utilizados em 
qualquer local em que a superclasse ocorra, e não vice-versa. A subclasse herda 
as propriedades da mãe, ou seja, os seus atributos e métodos, bem como pode 
possuir atributos e métodos próprios, além dos herdados.
De acordo com Guedes (2007), a vantagem do uso da herança é que, 
quando uma classe é declarada com os seus atributos e métodos especí-
ficos e, após isto, uma subclasse é derivada, não é necessário redeclarar 
os atributos e métodos já definidos. Em outras palavras, por meio da 
herança, a subclasse herda tais atributos e métodos automaticamente, 
permitindo a reutilização do código já pronto. 
Assim, é preciso, somente, declarar os atributos ou métodos restritos 
da subclasse, o que torna o processo de desenvolvimento mais ágil, além 
de facilitar as manutenções futuras, pois, em caso de alteração, será ne-
cessário alterar, somente, o método da superclasse para que todas as sub-
classes estejam, também, atualizadas. A Figura 6 apresenta um exemplo 
de herança, explicitando os papéis de superclasse e subclasse e, também, 
apresenta o símbolo de herança da UML, uma linha que liga as classes 
com um triângulo que toca a superclasse:
U
N
ID
A
D
E 
1
24
Figura 6 - Exemplo de herança / Fonte: os autores.
A figura apresentada mostra a superclasse cliente com os atributos nome, en-
dereço, cidade, UF e CEP, bem como os métodos incluirNovoCliente() e atuali-
zarCliente(). A subclasse PessoaFisica herda esses atributos e métodos, além de 
possuir os atributos CPF e RG e o método validarCPF(). A seta que aponta para 
a superclasse cliente indica a herança. A subclasse PessoaJuridica herda, também, 
todos os atributos e métodos da superclasse cliente, além de possuir os atributos 
CNPJ, inscrição_estadual e razão_social e o método validarCNPF().
Quando olhamos para a Figura 6, notamos que a classe cliente é a mais gené-
rica e as classes PessoaFisica e PessoaJuridica são as mais especializadas. Então, 
podemos afirmar que generalizamos quando partimos das subclasses para a su-
perclasse e especializamos quando fazemos o contrário, ou seja, quando partimos 
da superclasse para as subclasses.
Polimorfismo
O conceito de polimorfismo está associado à herança, pois trabalha com a re-
declaração de métodos previamente herdados por uma classe. Esses métodos, 
embora parecidos, diferem-se, de alguma forma, da implementação utilizada na 
Cliente
- nome : string
- endereço : string
- cidade : string
- UF : char
- CEP : char
+ incluirNovoCliente() : void
+ atualizarCliente() : void
- cnpj : int
- inscricao_estadual : int
- razão_social: string
+ validarCnpj() : void
PessoaJurídica
- cpf: int
- RG : int
+ validarCpf() : void
PessoaFísica
U
N
IC
ES
U
M
A
R
25
superclasse, sendo necessário implementá-los, novamente, na subclasse. Todavia, 
a fim de não ter que alterar o código-fonte, acrescentando uma chamada a um 
método com nome diferente, redeclara-se o método com o mesmo nome decla-
rado na superclasse (GUEDES, 2007).
De acordo com Lima (2009), o polimorfismo é o princípio em que classes 
derivadas (as subclasses) e uma mesma superclasse podem chamar métodos que 
têm o mesmo nome (ou a mesma assinatura), mas que possuem comportamentos 
diferentes em cada subclasse, produzindo resultados diferentes, dependendo de 
como cada objeto implementa o método.
Em outras palavras, podem existir dois ou mais métodos com a 
mesma nomenclatura, diferenciando-sena maneira como foram im-
plementados. O sistema é o responsável por verificar se a classe da 
instância em questão possui o método declarado nela própria ou se o 
herda de uma superclasse (GUEDES, 2007).
Por ser um exemplo bastante claro, para ilustrar o polimorfismo, 
apresentamos a Figura 7:
Figura 7 - Exemplo de poliformismo / Fonte: os autores.
No exemplo apresentado, há uma classe geral chamada Conta_Comum 
(que, neste caso, é a superclasse), a qual possui um atributo chamado 
saldo, que contém o valor total depositado em determinada instância 
da classe, e um método chamado saque. Esse método, somente, diminui 
o valor a ser debitado do saldo da conta se este possuir valor suficiente. 
Caso contrário, a operação não poderá ser realizada, ou seja, o saque deve 
ser recusado pelo sistema (GUEDES, 2007).
Conta_Comum
- saldo : double
+ saque() : void
- aniversario : date
Conta_Poupança
- limite : double 
+ saque() : void
Conta_Especial
U
N
ID
A
D
E 
1
26
5 
DIAGRAMA DE 
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 elas. Em pou-
cas palavras, uma classe de objeto pode ser pensada como a definição geral de um tipo 
de objeto do sistema. Uma associação é um link entre classes que indica algum relaciona-
mento entre elas. Consequentemente, cada classe pode precisar de certo conhecimento 
de sua classe associada. Quando você está desenvolvendo modelos durante os estágios 
explorando Ideias
O diagrama de classes tem como objetivo permitir a visualização das classes uti-
lizadas pelo sistema e como elas se relacionam, apresentando a visão estática de 
como estão organizadas, preocupando-se, apenas, em definir a sua estrutura lógica 
(GUEDES, 2007). Ainda, de acordo com o estudioso, um diagrama de classes pode 
ser utilizado para modelar o modelo lógico de um banco de dados, parecendo-se, 
neste caso, com o diagrama de entidade-relacionamento (o modelo entidade-re-
lacionamento, o qual você estuda na disciplina de banco de dados). No entanto 
deve ficar bem claro que o diagrama de classes não é utilizado, unicamente, para 
esta finalidade, e que uma classe não corresponde, necessariamente, a uma tabela.
U
N
IC
ES
U
M
A
R
27
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 é desenvol-
vida, geralmente, é necessário definir objetos adicionais de implementação que são usados 
para fornecer a funcionalidade requerida do sistema. 
Fonte: adaptado de Sommerville (2011, p. 90).
Estrutura da classe
Uma classe pode representar o repositório lógico dos atributos de uma tabe-
la, mas a classe não é a tabela. Isto se deve ao fato de que os atributos de seus 
objetos são armazenados em memória enquanto uma tabela armazena os seus 
registros fisicamente, em disco. Podemos definir classe como a descrição de 
uma coleção de objetos que possuem propriedades (atributos, métodos e as-
sociações), conforme mostra a Figura 8:
Figura 8 - Estrutura da classe / Fonte: os autores.
Relacionamentos
As classes não trabalham sozinhas. Pelo contrário, elas colaboram umas com 
as outras, por meio de relacionamentos (MELO, 2004). No diagrama de clas-
ses, temos alguns tipos de relacionamentos, como o de associação (que pode ser 
unária ou binária), de generalização ou de agregação, por exemplo. Na sequência, 
detalharemos esses e outros tipos.
+ Nome : string = Fernando
+Idade : int = 18
+ andar(entrada direção: Direção) : bool
+ dormir() : bool
Pessoa
Nome da classe 
Métodos
São as operações que podem ser
executadas sobre um objeto
Atributos e tipo de dado
Informação associada a
um objeto
U
N
ID
A
D
E 
1
28
Associação
De acordo com Melo (2004), a associação é um relacionamento que conecta duas 
ou mais classes, demonstrando a colaboração entre as instâncias de classe. Pode, 
também, existir o relacionamento de uma classe com ela mesma e, neste caso, 
tem-se uma associação unária ou reflexiva. A seguir, apresentaremos, na Figura 
9, um exemplo de uma associação entre classes:
Figura 9 - Exemplo de associação / Fonte: os autores.
Associação unária ou reflexiva
Segundo Guedes (2007), a associação 
unária ocorre quando existe o rela-
cionamento da instância de uma clas-
se com instâncias da mesma classe, 
conforme ilustra a Figura 10:
No exemplo apresentado, temos a classe funcionário, cujos atributos são código 
e nome bem como o código do possível chefe do funcionário. Pelo fato de esse 
chefe, também, ser um funcionário, a associação chamada “chefia” indica possí-
vel relação entre uma ou mais instâncias dessa classe com outras instâncias da 
mesma classe, ou seja, tal associação determina que um funcionário pode ou não 
chefiar outros. Além disso, essa associação faz com que a classe possua o atributo 
codChefe para armazenar o código do funcionário, atributo esse que é o respon-
sável pela instância do funcionário em questão. Desse modo, após consultar uma 
instância da classe funcionário, pode-se utilizar o atributo codChefe da instância 
consultada para pesquisar outra instância da classe (GUEDES, 2007).
- Codigo : int
- Nome : char
+ CalcPreco() : void
+ CalcImposto() : void
Produto
- NumeroVenda: int
+ Data() : int
Venda
Associação
0..* 0..*
- codigo : int
- nome : char
- codChefe : int
Funcionario
Che�a
0..*
Figura 10 - Exemplo de associação unária.
Fonte: os autores. 
U
N
IC
ES
U
M
A
R
29
Associação binária
A associação binária conecta duas classes por meio de uma reta que liga uma 
classe a outra. A Figura 11 demonstra um exemplo de associação binária:
Figura 11 – Exemplo de associação binária / Fonte: os autores. 
No exemplo, um objeto da classe cidade pode ou não se relacionar com instâncias 
da classe cliente, conforme demonstra a multiplicidade 0..*. Entretanto, se existir 
um objeto da classe cliente, ele terá que se relacionar com um objeto da classe 
cidade, pois, pelo fato de que não foi definida a multiplicidade na extremidade 
da classe cidade, isto significa que ela é 1..1. Após termos explicado os relaciona-
mentos em um diagrama de classes, explicaremos o conceito de multiplicidade.
Agregação
Uma agregação pode ocorrer, somente, entre duas classes. De acordo com as re-
gras da UML, esse tipo de relacionamento ou associação é identificável a partir da 
notação de uma linha sólida entre duas classes: a classe denominada “todo-agre-
gado” recebe um diamante vazio, enquanto a outra ponta da linha é ligada à classe 
denominada “parte-constituinte”. Ambas podem “viver” de forma independente, 
ou seja, não existe ligação forte entre as duas. Objetos da parte constituinte ou da 
parte agregada são independentes em termos de vida, mas ambas são partes do 
todo único. Essa análise dependerá do domínio do problema em estudo.
Para sabermos se um relacionamento é de agregação, basta perguntarmos se, em 
primeiro lugar, ele comporta a estrutura todo-parte. Em seguida, questionamos se o 
objeto constituinte-parte “vive” sem o objeto agregado. Se a resposta for sim a ambas 
Cliente
- nome : string
- sexo : char
- data_nascimento : Date 
- endereco : String
- CEP : int
- nome : String
- UF : String
- DDD : int
Cidade
0..*
U
N
ID
A
D
E 
1
30
as perguntas, teremos uma agregação. A Figura 12 apresenta a notação para esta se-
mântica. Em determinado domínio de problema que trata de apartamentos e con-
domínios, observamos que um apartamento tem depósitos. Quando nos referimos 
a um depósito, podemos perguntar a qual apartamento ele pertence. Por outro lado, 
determinado proprietário pode ter decidido vender 
um depósito para alguém que sequer mora no prédio. 
Assim, teremos os dois objetos, neste exemplo, viven-
do separadamente, sem incômodo algum.
Poderíamos ter a situação em que um aparta-
mento é interditado ou passa por extensa reforma. 
Durante algum tempo, não temos movimentação 
naquele local,mas o depósito que faz parte daquele 
jogo apartamento-depósito continua sendo usado 
livremente. Assim, o mesmo exemplo valeria para 
garagens de um apartamento:
Composição
Uma composição ocorre quando temos uma situação semelhante à da agrega-
ção entre duas classes, mas os objetos da classe parte não podem viver quando 
o todo é destruído. Esse tipo de relacionamento é identificável pela notação de 
uma linha sólida entre duas classes: a classe denominada todo-composta, a qual 
recebe um diamante preenchido, enquanto a outra ponta da linha é ligada à classe 
denominada “parte-componente”.
Ambas as classes “vivem” unidas de forma dependente, ou seja, existe uma ligação 
forte entre as duas. Os objetos-parte não podem ser destruídos por um objeto diferen-
te do objeto-todo ao qual estão relacionados (GUEDES, 2011). Essa análise depen-
derá do domínio do problema em estudo. Para sabermos se um relacionamento é de 
composição, basta perguntarmos se, em primeiro lugar, cabe a estrutura todo-parte. 
Em seguida, questionamos se o objeto parte “vive” sem o objeto todo. Se a resposta for 
sim para a primeira pergunta e não para segunda, teremos uma composição. 
clsApartamento
- dMetragem : double
- IcountApartamento: double
+ obterMetragem() : void
+ obterNrAptsInstanciados() : int
clDeposito
Figura 12 - Uma agregação en-
tre duas classes.
Fonte: os autores.
U
N
IC
ES
U
M
A
R
31
A Figura 13 apresenta uma visão da notação para esse tipo de relacio-
namento. Em relação a este domínio de problema, precisamos pensar o pré-
dio como um todo. Isso parece plausível, pois, nesse domínio de problema, 
necessariamente, um prédio deveria existir para que haja um apartamento. 
Caso não pudesse qualificar um prédio, nada poderia ser feito em relação 
àquele apartamento. Não se pode fazer nada com um apartamento, vender 
ou alugar, enquanto ele não possuir um endereço. O endereço é o do pré-
dio, o apartamento possui, apenas, complemento. Assim, para os fins deste 
software, não seria possível instanciar um objeto clsApartamento, caso não 
fosse designado um objeto clsPredio:
Figura 13 - Composição entre duas classes / Fonte: os autores. 
Generalização/especialização
Esta associação identifica as classes-mãe (superclasses), as quais são chamadas 
gerais, e as classes-filhas (subclasses), as chamadas especializadas, demonstrando 
a ocorrência de herança e, possivelmente, de métodos polimórficos nas classes 
especializadas. A seguir, na Figura 14, há um exemplo entre classes que demonstra 
o uso de generalização/especialização:
clsApartamento
- dMetragem : double
- IcountApartamento: int
+ obterMetragem()
+ obterNumAptsInstanciados() : int
clsDeposito
clsPredio
- Nome : String
- Endereco : String
U
N
ID
A
D
E 
1
32
Figura 14 - Generalização/especialização entre duas classes.
Fonte: Guedes (2011, p. 114).
Multiplicidade
De acordo com Guedes (2007), a multiplicidade determina o número mínimo e 
máximo de instâncias envolvidas em cada uma das extremidades da associação, 
permitindo, também, especificar o nível de dependência de um objeto com os ou-
tros. Quando não existe multiplicidade explícita, entende-se que ela é 1..1, o que 
significa que, somente, uma instância dessa extremidade da associação relaciona-se 
com as instâncias da outra extremidade. A Tabela 1, a seguir, demonstra alguns dos 
diversos valores de multiplicidade que podem ser utilizados em uma associação:
Conta_Comum
# nro_conta : long
# dt_abertura : Date
# dt_encerramento : Date
# situracao : int
# senha : int
# saldo : double
+ abrir_conta(int : int) : long
+ consultar_Conta(long : int) : int
+ validar_Senha(int : int) : int
+ saldo_Conta() : double
+ extrato_Conta() : String
+ sacar_Valor(double : int) : int
+ depositar_Valor(long : int, double : int) : int
+ encerrar_Conta() : int
- limite_conta : double 
+ abrir_conta(int : int, double : int) : long
+ sacar_valor(double : int) : int
+ juros_Conta(double : int) : double
Conta_Especial
- dt_aniversario : Date
+ renda_conta(Date : int, double : int) : double
Conta_Poupanca
U
N
IC
ES
U
M
A
R
33
Multiplicidade Significado
0..1
No mínimo, zero (nenhum), no máximo, um. Indica que os 
objetos das classes associadas não precisam, obrigatoria-
mente, estar relacionados, mas, se houver relacionamento, 
indica que apenas uma instância da classe se relaciona com 
as instâncias da outra classe.
1..1
Um e somente um. Indica que apenas um objeto da classe 
se relaciona com os objetos da outra classe.
0..*
No mínimo, nenhum, no máximo, muitos. Indica que pode ou 
não haver instâncias da classe participando do relacionamento.
*
Muitos. Indica que muitos objetos da classe estão envolvi-
dos no relacionamento.
1..*
No mínimo, um, no máximo, muitos. Indica que há, pelo 
menos, um objeto envolvido no relacionamento e que pode 
haver muitos objetos envolvidos.
2..5
No mínimo, dois, no máximo, cinco. Indica que existem, pelo 
menos, duas instâncias envolvidas no relacionamento e que 
podem ser três, quatro ou cinco as instâncias envolvidas, 
porém não mais do que isso.
Tabela 1 - Exemplos de multiplicidade / Fonte: adaptada de Guedes (2011, p. 108).
As associações que possuem multiplicidade do tipo muitos (*), em qualquer de suas 
extremidades, forçam a transmissão do atributo-chave na classe da outra extremida-
de da associação. Entretanto esse atributo-chave não aparece desenhado na classe.
Figura 15 – Multiplicidade / Fonte: os autores.
Pessoa Empresa
1..* *
trabalha para
multiplicidade associação
U
N
ID
A
D
E 
1
34
Classe associativa
Quando um relacionamento possui multiplicidade, ou seja, muitos (*) em suas 
duas extremidades, é necessário criar uma classe associativa para guardar os ob-
jetos envolvidos nessa associação. Na classe associativa, são definidos o conjunto 
de atributos que participam da associação, e não as classes que participam do 
relacionamento. Nesse caso, pelo menos os atributos-chave devem fazer parte da 
classe associativa, mas ela, também, pode ter atributos próprios.
Uma classe associativa é representada por uma reta tracejada que parte do 
meio da associação e atinge uma classe. A Figura 16 apresenta um exemplo de 
classe associativa que possui atributos próprios, além dos atributos-chave das 
classes que participam da associação. Contudo é necessário reforçar que, neste 
caso, esses atributos-chave não são representados no diagrama.
Figura 16 - Exemplo de classe associativa / Fonte: os autores.
No exemplo apresentado, uma instância da classe curso pode se relacionar com 
muitas instâncias da classe disciplina, bem como uma instância da classe disci-
plina pode se relacionar com muitas instâncias da classe curso. Como existe a 
multiplicidade nas extremidades de ambas as classes da associação, não há como 
reservar atributos para armazenar as informações decorrentes da associação, já 
que não é possível determinar um limite para a quantidade de disciplinas que 
um curso pode ter e nem saber a quantos cursos uma disciplina pode pertencer.
Assim, é preciso criar uma classe para guardar essa informação, além das 
informações próprias da classe, que são a carga horária da disciplina no curso e a 
Curso
- nome : int
- area : int
Disciplina_Curso
- carga_horaria : int
- serie : int
Disciplina
- nome : int
Disciplina_Curso
1..* 1..*
U
N
IC
ES
U
M
A
R
35
série a qual essa disciplina estará vinculada. Os atributos-chave das classes curso 
e disciplina são transmitidos de forma transparente pela associação, não sendo 
necessário, portanto, escrevê-los como atributos da classe associativa.
Segundo Guedes (2007), as classes associativas podem ser substituídas por 
classes normais, que, neste caso, são chamadas de classes intermediárias, mas 
que desempenham, exatamente, a mesma função das associativas. A Figura 17 
mostra o mesmo exemplo da figura anterior, porém com a classe intermediária 
no lugar da classe associativa:
Figura 17 - Exemplo de classe intermediária / Fonte: os autores.
Curso
- nome: int
- area : int
Disciplina_Curso
- carga_horaria : int
- serie : int
Disciplina
- nome : int
1..* 1..*
U
N
ID
A
D
E 
1
36
CONSIDERAÇÕES FINAIS
No decorrer desta unidade, estudamos a importância da modelagem de um siste-
ma e como ela é a parte fundamental de todas as atividades de desenvolvimento, 
dentro de um processo de software, as quais levam à implantação de um bom 
software. Esses modelos, normalmente, são representados por meio de diagramas 
em que é utilizada uma notação gráfica, a qual, em nosso caso, foi a UML (Unified 
Modeling Language ou Linguagem de Modelagem Unificada).
Iniciamos a unidade aprendendo que a modelagem de software se baseia na 
utilização de notações gráficas e textuais com o objetivo de construir modelos que 
representem as partes essenciais de um sistema. Na sequência, estudamos alguns 
conceitos das Ferramentas CASE (Computer-Aided Software Engineering) e 
da UML. Aprendemos, também, que todos os artefatos de software produzidos 
durante a modelagem, dentre eles, o diagrama de classe, podem ser usados como 
base para as fases seguintes do ciclo de vida do programa. 
Aprendemos que, pelo fato de a UML ser, totalmente, baseada no paradigma 
de Orientação a Objetos (OO), foi necessário, para compreendê-la, estudar alguns 
dos conceitos relacionados a tal orientação. Portanto, na sequência, abordamos 
os conceitos básicos desse paradigma para entender, por meio de elementos, a 
estrutura do sistema.
Por último, relembramos o diagrama de classes, sendo o mais importante e 
utilizado da UML, pois é ele que define a estrutura das classes identificadas para 
o sistema, mostrando os atributos e os métodos de cada uma das classes bem 
como os seus relacionamentos. 
Na próxima unidade, você estudará conceitos de encapsulamento e mo-
dificadores de acesso denominados public, protected e private. Entenderá 
a diferença dos modificadores static, abstract e final e, também, o que são 
os construtores de classes. 
Preparados para seguir em frente? Bons estudos!
37
na prática
1. Uma classe é um conjunto de objetos que possuem os mesmos tipos de caracterís-
ticas e comportamentos, sendo representada por um retângulo que pode possuir 
até três divisões. Partindo desse conceito, elabore um diagrama de classes com 
duas classes que tenham as características citadas a seguir. Lembre-se que classes 
não trabalham sozinhas, portanto, construa, entre elas, um relacionamento 1..* (no 
mínimo, um, no máximo, muitos):
Nome da classe:
FUNCIONÁRIO
Descrição:
Contém dados cadastrais dos funcionários
Campo Tipo Visibilidade Chave Descrição
Matricula Integer Pública PK Matrícula
CpfCnpj String Pública CPF ou CNPJ
NomeFunc String Pública --- Nome do funcionário
DtAdmissao Date Pública --- Data da admissão
Métodos:
+IncluirNovoFunc
+BuscarFunc
+ExcluirFunc
Nome da Classe:
DEPENDENTE
Descrição:
Contém dados cadastrais do dependente
Campo Tipo Visibilidade Chave Descrição
IdDep Integer Privada PK Número do dependente
NomeDep String Privada --- Nome do dependente
DtNasci-
mento
Date Privada --- Data de nascimento
IdFunc Integer Pública FK Código do funcionário
Métodos:
+IncluirNovoDep
+ExcluirDep
38
na prática
2. Faça um diagrama de classes para um sistema de locações de ônibus, levando em 
consideração os seguintes requisitos:
• A empresa tem muitos ônibus. Cada ônibus tem os seguintes atributos: número 
de placa, cor, ano, tipo de combustível, número de portas, quilometragem, Re-
navame valor de locação.
• Cada ônibus tem um modelo e uma marca, mas um modelo pode relacionar-se 
a muitos ônibus e uma marca pode referir-se a muitos modelos, embora cada 
modelo só tenha uma marca específica.
• Um ônibus pode ser alugado por muitos clientes, em momentos diferentes, e 
um cliente pode alugar muitos ônibus. É preciso saber quais estão locados ou 
não. Sempre que locar um ônibus, é necessário armazenar a data e a hora de 
sua locação e, quando for devolvido, a data e a hora da devolução.
Com base nesse cenário, identifique as classes, os atributos, os métodos 
e os relacionamentos.
3. O diagrama de classe é uma representação da estrutura e das relações das classes 
que servem de modelo para objetos. Partindo disso, analise o diagrama de classe, 
a seguir, e assinale a alternativa correta:
a) Entre as entidades ônibus e passageiro, temos um rela-
cionamento de composição.
b) Entre as entidades ônibus e passageiro, temos um rela-
cionamento de agregação.
c) Entre as entidades ônibus e passageiro, temos um relacio-
namento de generalização/especialização (herança).
d) Entre as entidades ônibus e passageiro, temos um rela-
cionamento unário.
e) Entre as entidades ônibus e passageiro, temos um rela-
cionamento de realização.
Onibus
Passageiro
39
na prática
4. Maria controla, em Excel, a sua lista mensal de compras de produtos. Na planilha, 
ela cadastra: 
• Nome do produto.
• Unidade de compra (quilos, litros, metros etc.).
• Quantidade prevista para o mês.
• Quantidade comprada.
• Preço estimado (que é atualizado todo mês).
• Valor total da compra.
A quantidade comprada pode variar em função da sobra do produto de um mês 
para o outro ou da necessidade de um gasto menor ou maior no mês. Com base 
nesse cenário, identifique as classes, os atributos, os métodos e os relacionamentos. 
5. Os símbolos menos (-) e mais (+), na frente dos atributos e métodos, representam 
a sua visibilidade. Esta, por sua vez, é utilizada para indicar o nível de acessibilidade 
de determinado atributo ou método, sendo, sempre, representada à esquerda. 
A partir da informação apresentada, descreva os principais três modos de visibilidade 
utilizados na UML.
40
aprimore-se
A UML – Unified Modeling Language ou Linguagem de Modelagem Unificada – é 
uma linguagem visual utilizada para modelar softwares baseados no paradigma de 
orientação a objetos. É uma linguagem de modelagem de propósito geral que pode 
ser aplicada a todos os domínios de aplicação. Essa linguagem tornou-se, nos úl-
timos anos, a linguagem-padrão de modelagem adotada internacionalmente pela 
indústria de engenharia de software.
Deve ficar bem claro, porém, que a UML não é uma linguagem de programa-
ção, e sim uma linguagem de modelagem, uma notação, cujo objetivo é auxiliar os 
engenheiros de software a definirem as características do sistema, tais como seus 
requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus proces-
sos e até mesmo suas necessidades físicas em relação ao equipamento sobre o 
qual o sistema deverá ser implantado. Tais características podem ser definidas por 
meio da UML antes do software começar a ser realmente desenvolvido. Além disso, 
cumpre destacar que a UML não é um processo de desenvolvimento de software e 
tampouco está ligada a um de forma exclusiva, sendo totalmente independente, po-
dendo ser utilizada por muitos processos de desenvolvimento diferentes ou mesmo 
da forma que o engenheiro considerar mais adequada. 
A UML surgiu da união de três métodos de modelagem: o método de Booch, o 
método OMT (Object Modeling Technique) de Jacobson, e o método OOSE (Objec-
t-Oriented Software Engineering) de Rumbaugh. Estes eram, até meados da déca-
da de 1990, os métodos de modelagem orientada a objetos mais populares entre 
os profissionais da área de desenvolvimento de software. A união desses métodos 
contou com o amplo apoio da Rational Software, que a incentivou e financiou. O 
esforço inicial do projeto começou com a união do método de Booch ao OMT de 
Jacobson, o que resultou no lançamento do Método Unificado no final de 1995. Logo 
em seguida, Rumbaugh juntou-se a Booch e Jacobson na Rational Software, e seu 
método OOSE começou também a ser incorporado à nova metodologia. O trabalho 
41
aprimore-se
de Booch, Jacobson e Rumbaugh, conhecidos popularmente como “Os Três Ami-
gos”, resultou no lançamento, em 1996, da primeira versão da UML propriamente 
dita. Tão logo a primeira versão foi lançada, muitas empresas atuantesna área de 
modelagem e desenvolvimento de software passaram a contribuir para o projeto, 
fornecendo sugestões para melhorar e ampliar a linguagem. Finalmente, a UML foi 
adotada, em 1997, pela OMG (Object Management Group ou Grupo de Gerencia-
mento de Objetos), como uma linguagem-padrão de modelagem. 
A versão 2.0 da linguagem foi oficialmente lançada em julho de 2005, encontran-
do-se, atualmente, na versão 2.3 beta. A documentação oficial da UML pode ser con-
sultada no site da OMG em www.omg.org ou mais exatamente em www.uml.org.
POR QUE MODELAR SOFTWARE?
Qual a real necessidade de se modelar um software? Muitos “profissionais” podem 
afirmar que conseguem determinar todas as necessidades de um sistema de in-
formação de cabeça, e que sempre trabalharam assim. Qual a real necessidade de 
se projetar uma casa? Um pedreiro experiente não é capaz de construí-la sem um 
projeto? Isso pode ser verdade, mas a questão é muito mais ampla, envolvendo 
fatores extremamente complexos, como levantamento e análise de requisitos, pro-
totipação, tamanho do projeto, complexidade, prazos, custos, documentação, ma-
nutenção e reusabilidade, entre outros.
Existe uma diferença gritante entre construir uma pequena casa e construir um 
prédio de vários andares. Obviamente, para se construir um edifício é necessário, 
em primeiro lugar, desenvolver um projeto muito bem-elaborado, cujos cálculos 
têm de estar extremamente corretos e precisos. Além disso, é preciso fornecer uma 
estimativa de custos, determinar em quanto tempo a construção estará concluída, 
avaliar a quantidade de profissionais necessária à execução da obra, especificar a 
http://www.uml.org
42
aprimore-se
quantidade de material a ser adquirida para a construção, escolher o local onde o 
prédio será erguido etc. Grandes projetos não podem ser modelados de cabeça, 
nem mesmo a maioria dos pequenos projetos pode sê-lo, exceto, talvez, aqueles 
extremamente simples.
Na realidade, por mais simples que seja, todo e qualquer sistema deve ser mode-
lado antes de se iniciar sua implementação, entre outras coisas, porque os sistemas 
de informação frequentemente costumam ter a propriedade de “crescer”, isto é, au-
mentar em tamanho, complexidade e abrangência. Muitos profissionais costumam 
afirmar que sistemas de informação são “vivos”, porque nunca estão completamen-
te finalizados. Na verdade, o termo correto seria “dinâmicos”, pois normalmente os 
sistemas de informação estão em constante mudança. Tais mudanças são devidas a 
diversos fatores, como, por exemplo:
• Os clientes desejam constantemente modificações ou melhorias no sistema.
• O mercado está sempre mudando, o que força a adoção de novas estraté-
gias por parte das empresas e, consequentemente, de seus sistemas.
• O governo seguidamente promulga novas leis e cria novos impostos e alí-
quotas ou, ainda, modifica as leis, os impostos e alíquotas já existentes, o 
que acarreta a manutenção no software.
Assim, um sistema de informação precisa ter uma documentação extremamente de-
talhada, precisa e atualizada para que possa ser mantido com facilidade, rapidez e 
correção, sem produzir novos erros ao corrigir os antigos. Modelar um sistema é uma 
forma bastante eficiente de documentá-lo, mas a modelagem não serve apenas para 
isso: a documentação é apenas uma das vantagens fornecidas pela modelagem. 
Fonte: Guedes (2011, p. 19-21). 
43
eu recomendo!
UML 2 – Uma Abordagem Prática
Autor: Gilleanes Thorwald Araújo Guedes
Editora: Novatec
Sinopse: a UML – Unified Modeling Language ou Linguagem de 
Modelagem Unificada – é uma linguagem utilizada para modelar 
softwares baseados no paradigma de orientação a objetos, aplica-
da, principalmente, durante as fases de análise de requisitos e de 
projeto de software. A UML consagrou-se como a linguagem-padrão de modelagem 
adotada, internacionalmente, pela indústria de Engenharia de Software e, assim, há 
amplo mercado para profissionais que a dominam. Este livro procura ensinar ao 
leitor, por meio de exemplos práticos, como modelar softwares pela UML. A lingua-
gem é ensinada mediante a apresentação de seus muitos diagramas, detalhando o 
propósito e a aplicação de cada um deles e os elementos que os compõem, as suas 
funções e formas de aplicação. A obra enfatiza, ainda, a importância da UML para a 
Engenharia de Software, além de abordar o paradigma de orientação a objetos, um 
conceito imprescindível para a compreensão correta da linguagem. 
livro
44
eu recomendo!
Este vídeo mostra uma introdução aos conceitos de orientação a objetos.
http://www.youtube.com/watch?v=MnJLeYAno4o&feature=relmfu.
O vídeo mostra a importância da modelagem de sistemas bem como da elabora-
ção do diagrama de casos de uso.
http://www.youtube.com/watch?v=hfN6n5fJfLc&feature=relmfu.
conecte-se
UML – Guia do Usuário
Autor: Grady Booch, James Rumbaugh e Ivar Jacobson
Editora: Campus
Sinopse: há quase 10 anos, a Unified Modeling Language (UML) é o 
padrão para visualizar, especificar, construir e documentar os arte-
fatos de um sistema de software. A UML 2.0 vem para assegurar as 
contínuas popularidade e viabilidade da linguagem. As suas simpli-
cidade e expressividade permitem que os usuários modelem tudo, desde sistemas 
empresariais de informação, passando por aplicações distribuídas baseadas na 
Web até sistemas embutidos de tempo real. Nesta nova edição, totalmente revista, 
os criadores da linguagem fornecem um tutorial dos aspectos centrais da UML. 
Começando com um modelo conceitual da UML, o livro aplica, progressivamente, 
a linguagem em uma série de problemas de modelagem cada vez mais complexos, 
usando diversos domínios de aplicação. A abordagem em tópicos é recheada de 
exemplo, o que fez da primeira edição um recurso indispensável. Entretanto, o con-
teúdo reflete as mudanças na notação e no uso exigidos pela UML 2.0.
livro
2
PLANO DE ESTUDO 
A seguir, apresentam-se os tópicos que você estudará nesta unidade: • O que é encapsulamento? 
• Modificadores de acesso: default, public, protected e private • Utilizando modificadores de acesso 
(getters e setters) • Modificadores static, abstract e final • Construtores de classe.
OBJETIVOS DE APRENDIZAGEM 
• Entender o conceito de encapsulamento • Estudar os modificadores de acesso default, public, protec-
ted e private • Controlar o acesso a métodos, atributos e construtores por meio de modificadores • En-
tender a diferença dos modificadores static, abstract e final • Entender o que são construtores de classes.
MODIFICADORES
JAVA E
ENCAPSULAMENTO
PROFESSORES 
Dr. Edson Alves de Oliveira Junior
Me. Andre Abdala Noel
Me. Márcia Cristina Dadalto Pascutti
Me. Rafael Alves Florindo 
Esp. Victor de Marqui Pedroso
Esp. Janaina Aparecida de Freitas 
INTRODUÇÃO
Caro(a) aluno(a), após estudarmos a importância da modelagem de 
um sistema em UML, e como ela é a parte fundamental de todas as 
atividades dentro de um processo de software, nesta segunda unidade, 
você verá a revisão dos conceitos de encapsulamento, de modificadores 
de acesso e construtores em Java. 
A ideia de encapsulamento remete ao fato de que é possível agru-
par estados e comportamentos de um objeto em um mesmo módulo 
e, ainda, controlar as suas propriedades e o seu acesso, ou seja, trata 
dos padrões de visibilidade de acessos para as classes, os atributos e os 
métodos. Para estudar o encapsulamento, escreveremos métodos de 
acesso que são mais conhecidos como modificadores de acesso. Estes 
atuarão em elementos de uma classe, utilizando os chamados métodos 
setters (armazenamento) e getters (resgate).
Nos modificadores de acesso setters e getters, a linguagem Java permite 
o uso dos modificadores static, final e abstract. O modificador static permite 
que um método de uma classe seja invocada sem ter a instância de uma. O 
modificador final bloqueará a herança da classe ou o reuso de um método 
em outra classe. O modificador abstract permite modelar uma classe de 
forma que elaseja um modelo para as outras que a estendem.
Por fim, abordaremos o momento em que uma classe é instanciada, 
ou seja, quando criamos um objeto de uma classe que, automaticamente, 
é executado o seu método construtor, que pode inicializar atributos ou 
outras instruções essenciais para o início da classe. Dessa forma, con-
trolaremos como os objetos de uma classe serão inicializados e de qual 
forma podemos melhor aproveitá-los.
Para mostrar a você como utilizar estes recursos, empregaremos alguns 
exemplos que usam essas técnicas de modificadores de acesso e de cons-
trutores de classe. Discutiremos, ao longo da unidade, um exemplo para a 
apresentação do tema e, também, outro exemplo, em que será construído 
um projeto completo, desenvolvido com as técnicas apresentadas.
U
N
IC
ES
U
M
A
R
47
1 
O QUE É 
ENCAPSULAMENTO?
Classes (e seus objetos) encapsulam, isto é, contêm seus atributos e métodos. Os atri-
butos e métodos de uma classe (e de seu objeto) estão intimamente relacionados. Os 
objetos podem se comunicar entre si, mas eles, em geral, não sabem como outros ob-
jetos são implementados – os detalhes de implementação permanecem ocultos dentro 
dos próprios objetos. Esse ocultamento de informações, como veremos, é crucial à boa 
engenharia de software. 
Fonte: Deitel e Deitel (2017, p. 9). 
conceituando
Caro(a) aluno(a), quando se fala de encapsulamento, você, provavelmente, ima-
gina um objeto fechado, dentro de uma cápsula, e isto não é muito diferente 
na programação orientada a objetos, pois a ideia principal do encapsulamento 
envolve omitir os membros de uma classe, além de esconder como funcionam 
as rotinas ou as regras de negócio. Dessa forma, o programador deve se atentar 
às funcionalidades da classe, e não como ela foi implementada. Isto é bom, uma 
vez que há a expansão na modularidade do seu projeto.
Sendo assim, realizar o encapsulamento de um projeto é fundamental para a 
possibilidade de minimizar o impacto de problemas referentes a alterações do 
U
N
ID
A
D
E 
2
48
projeto, uma vez que não é preciso alterar uma regra de negócio em vários lugares, 
mas, sim, em apenas um lugar, já que tal regra está encapsulada.
Para exemplificar, focaremos no problema de realização de operações bancá-
rias em um caixa eletrônico. No caixa, é possível: sacar dinheiro, depositar, verifi-
car saldo, verificar extrato, pagar contas e fazer transferências. Para utilizar o caixa 
eletrônico, não é necessário conhecer como as operações foram implementadas 
em nível de programação, mas, sim, saber o que cada operação afeta em sua conta.
Analise a Figura 1, a seguir, e verifique a classe Conta, com atributos e méto-
dos para uma Conta Corrente. Note, por exemplo, que o método transferir rece-
be, como parâmetro, o número da conta 
(numContaDestino) e um valor a ser 
transferido (valor). Para utilizar esse 
método, o programador não precisa saber 
como o criador dessa classe o implemen-
tou, basta saber que esse método é respon-
sável por enviar um valor para outra conta 
corrente, e que essa transferência implica 
subtração do saldo da conta remetente.
Ainda em relação à Figura 1, que ilustra um diagrama de Classe UML, o símbo-
lo soma (+) indica que tanto os atributos quanto os métodos são públicos. Isso 
significa que eles podem ser acessados e modificados de qualquer outra classe 
do projeto, e isto não é uma boa prática de programação, uma vez que os seus 
atributos estão expostos e qualquer outro objeto pode alterar os valores dos ele-
mentos das classes, comprometendo, assim, a coesão do seu projeto. Por exemplo, 
na Figura 2: 
//Criação da referência a Conta
ContaCorrente cc = new Conta();
//Modificação do atributo saldo de forma direta
cc.saldo = 0;
System.out.println("Saldo Conta: R$"+cc.saldo);
Para solucionar este problema, faz-se necessária a utilização de modificadores de 
acesso, sendo que eles farão o papel de restringir ou autorizar o acesso a determi-
nados atributos ou métodos das classes, e isto será visto a partir da próxima seção.
Conta
+ saldo : �oat
+ titular : String
+ cpfTitular : String
+ numConta : int
+ sacar(valorSaque : �oat) : void
+ depositar(valorDep : �oat) : void
+ veri�carSaldo() : void
+ transferir(numContaDestino : int, valor : int) : �oat 
Figura 1 - Classe Conta com atributos e 
métodos públicos / Fonte: os autores.
U
N
IC
ES
U
M
A
R
49
2 
MODIFICADORES 
DE ACESSO:
Default, Public, Protected e 
Private
Segundo Deitel e Deitel (2017), projeto e pacotes de projeto são conceitos básicos da 
programação em Java: 
Um projeto é a base para o desenvolvimento em Java, é nele que estarão todos os paco-
tes, as classes, as interfaces, as imagens da sua aplicação (2017).
O rico conjunto do Java de classes predefinidas é agrupado em pacotes – chamados de 
grupos de classes. Estes são referidos como biblioteca de classes Java, ou Interface de 
Programação de Aplicativo Java (API Java). 
Fonte: os autores. 
conceituando
É a partir dos modificadores de acesso que poderemos restringir ou não o acesso 
aos atributos e métodos de uma classe. Na programação orientada a objetos, os 
modificadores de acesso mais utilizados são o public e o private.
Antes de abordarmos os modificadores, é importante frisar alguns conceitos 
básicos sobre a programação em Java: projeto e pacotes do projeto.
Quando trabalhamos com o Netbeans para a criação de um projeto, basta aces-
sarmos o menu “Arquivo” e, em seguida, selecionar a opção “Novo Projeto”. Feito 
isto, aparecerá uma tela, como você pode verificar na Figura 2, a seguir:
U
N
ID
A
D
E 
2
50
Figura 2 - Criando um projeto em Java no Netbeans / Fonte: os autores. 
Como o Netbeans é uma IDE que suporta diversas linguagens de programação, 
ao criar o projeto, é necessário, previamente, selecionar a linguagem e, em segui-
da, o tipo de projeto. Sendo assim, criaremos um Aplicativo Java selecionando a 
opção “Aplicativo Java”. Feito isso, uma nova tela solicitará o preenchimento do 
nome do projeto, como você pode verificar na Figura 3:
Figura 3 - Configurando o nome do projeto / Fonte: os autores.
U
N
IC
ES
U
M
A
R
51
Após essas etapas, o seu projeto estará 
criado e poderá ser visualizado na Paleta 
“Projetos” do Netbeans, como pode ser ve-
rificado na Figura 4. Você pode notar que 
um projeto envolve pacotes e bibliotecas 
que, talvez, a sua aplicação necessite utilizar.
Figura 4 - Projeto em Java Fonte: os autores.
Para criar um novo pacote na pasta “Pacotes de código-fonte”, por exemplo, é neces-
sário clicar sobre a pasta com o botão direito e selecionar a opção: “Novo” -> “Pacote 
Java” e, em seguida, dar um nome ao seu novo pacote, como mostra a Figura 5.
Figura 5 - Criando um novo pacote Fonte: os autores.
Agora que você já entendeu o conceito de pacotes, iniciaremos a teoria sobre 
modificadores de acesso. Temos quatro deles: default, public, private e protected. 
O modificador default não precisa ser declarado, ou seja, atributos ou mé-
todos que não têm a declaração de um modificador de acesso são considerados 
default (do inglês, significa “padrão”). Como exemplo, você pode notar, no código, 
a criação de um atributo com modificador de acesso default. No pacote em que 
está localizada a classe criada, o atributo com esse modificador pode ser acessa-
do de forma direta por qualquer classe, agora, se a classe que instanciar a classe 
estiver em outro pacote, este não será acessível de forma direta.
U
N
ID
A
D
E 
2
52
//exemplo de atributo default
String valorTransitorio;
Atributos e métodos públicos (public) podem ser acessados e modificados de 
qualquer classe do projeto a partir da instância do objeto, ou seja, é possível, até 
de outros pacotes, ter acesso a atributos/métodos do tipo public, de forma direta. 
Para declarar esse tipo de modificador, é necessário utilizar a palavra reservada 
public antes de indicar o tipo de variável, isso pode ser verificado no exemplo de 
código-fonte, a seguir.
//exemplo de atributo public
public int idade;