Apol Análise Orientada a Objetos I

Prévia do material em texto

2015
AnáLise orientADA A 
oBJetos i
Prof. Jean Carlos Possamai
Copyright © UNIASSELVI 2015
Elaboração:
Prof. Jean Carlos Possamai
Revisão, Diagramação e Produção:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfi ca elaborada na fonte pela Biblioteca Dante Alighieri 
UNIASSELVI – Indaial.
005.1 
P856ac Possamai, Jean Carlos
Análise orientada a objetos I / Jean Carlos Possamai. Indaial : 
UNIASSELVI, 2015.
189 p. : il.
 ISBN 978-85-7830-874-2
 
1. Programação orientada a objetos. 
I. Centro Universitário Leonardo Da Vinci. 
Impresso por:
III
ApresentAção
Prezado(a) acadêmico(a)!
Seja bem-vindo ao mundo da Programação Orientada a Objetos. 
Neste universo você vai se deparar com termos como atributos, métodos, 
abstração, encapsulamento, classes, hierarquia das classes, processo 
unificado, entre outros, que compõem o material de estudo desta disciplina 
e, por consequência, o dia a dia de um analista, desenvolvedor, programador, 
ou seja, o profissional da programação.
Este caderno pressupõe que você já possua alguma experiência 
anterior em programação, principalmente JAVA, afinal muitos dos objetos, 
classes e diagramas apresentados neste material estão voltados a esta 
linguagem de programação. É essencial você fazer uso dos conhecimentos 
adquiridos em disciplinas anteriores para então conseguir acompanhar 
o desenvolvimento de um sistema e assim auxiliar você na construção do 
entendimento em programação orientada a objetos.
Aproveito a oportunidade para destacar a importância de desenvolver 
as autoatividades, afinal cada exercício deste caderno foi desenvolvido para 
a fixação de conceitos por meio da prática. Em caso de dúvida na realização 
das atividades, sugiro que você entre em contato com seu Tutor Externo ou 
com a tutoria da Uniasselvi, não prosseguindo as atividades sem ter sanado 
todas as dúvidas que irão surgindo.
Vale destacar a necessidade de dedicação e de muita determinação, 
afinal a Programação Orientada a Objetos exige de você bem mais do que 
apenas este caderno para sua total compreensão. Aqui, você recebe somente 
um início, ou seja, os conceitos de determinados pontos importantes na 
programação, porém é somente na prática que você consegue compreender 
o mundo da programação como um todo.
Lembre-se que o mundo da informática é encantador, assim, seu 
entusiasmo por este universo depende somente de você, destacando neste 
momento a compreensão da lógica envolvida no processo de construção de 
programas. Por este motivo, destaco uma frase que considero importante 
no caso da programação, afinal: “Para se ter sucesso, é amar de verdade o 
que se faz. Caso contrário, levando em conta apenas o lado racional, você 
simplesmente desiste. É o que acontece com a maioria das pessoas “ (Steven 
Jobs – criador da Apple).
Bom estudo! Sucesso na sua trajetória acadêmica e profissional!
JEAN CARLOS POSSAMAI
IV
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para 
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há 
novidades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é 
o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um 
formato mais prático, que cabe na bolsa e facilita a leitura. 
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova 
diagramação no texto, aproveitando ao máximo o espaço da página, o que também 
contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, 
apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade 
de estudá-lo com versatilidade nas telas do celular, tablet ou computador. 
 
Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para 
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto 
em questão. 
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas 
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa 
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de 
Desempenho de Estudantes – ENADE. 
 
Bons estudos!
NOTA
V
VI
VII
UNIDADE 1 - O PARADIGMA DA ORIENTAÇÃO A OBJETOS ............................................. 1
TÓPICO 1 - HISTÓRICO .................................................................................................................... 3
1 INTRODUÇÃO .................................................................................................................................. 3
2 O QUE SÃO OBJETOS? ................................................................................................................... 3
2.1 OBJETOS COMPUTACIONAIS .................................................................................................. 5
2.2 OS DIFERENTES TIPOS DE OBJETOS COMPUTACIONAIS ............................................... 5
2.2.1 Objetos computacionais visuais......................................................................................... 5
2.2.2 Objetos com tarefa relacionada .......................................................................................... 6
2.2.3 Objetos multimídias ............................................................................................................ 7
2.2.4 Objetos de domínio do trabalho ........................................................................................ 8
2.3 ORIENTAÇÃO A OBJETOS ........................................................................................................ 9
2.3.1 Análise orientada a objetos ................................................................................................. 9
2.3.2 Análise orientada a objetos ................................................................................................. 10
2.3.3 Vantagens e benefícios da orientação a objetos ............................................................... 11
RESUMO DO TÓPICO 1..................................................................................................................... 13
AUTOATIVIDADE .............................................................................................................................. 14
TÓPICO 2 - PROCESSO UNIFICADO (UP) ................................................................................... 17
1 INTRODUÇÃO .................................................................................................................................. 17
2 CARACTERIZAÇÃO DO UP .......................................................................................................... 18
2.1 FASES DO UP ................................................................................................................................ 22
2.2 RUP – RATIONAL UNIFIED PROCESS .................................................................................... 25
2.2.1 Blocos de Construção do RUP ........................................................................................... 27
2.2.2 Papéis no RUP ...................................................................................................................... 27
 2.2.2.1 Papel do Analista ..................................................................................................... 27
 2.2.2.2 Papel do Desenvolvedor ......................................................................................... 28
 2.2.2.3 Papel de Testador ..................................................................................................... 29
 2.2.2.4 Papel de Gerente ...................................................................................................... 292.2.2.5 Outros Papéis............................................................................................................ 30
2.2.3 AUP – Agile Unified Process .............................................................................................. 32
2.2.4 Open UP – Open Unified Process ..................................................................................... 34
2.2.5 EUP – Enterprise Unified Process ..................................................................................... 35
2.2.6 RUP-SE – Rational Unified Process – Systems Engineering ......................................... 36
RESUMO DO TÓPICO 2..................................................................................................................... 38
AUTOATIVIDADE .............................................................................................................................. 39
TÓPICO 3 - ESTRUTURAS E RELACIONAMENTOS ................................................................. 41
1 INTRODUÇÃO .................................................................................................................................. 41
2 TIPOS DE ESTRUTURAS E RELACIONAMENTOS ................................................................ 41
2.1 ESTRUTURA GENERALIZAÇÃO – ESPECIALIZAÇÃO (GE) ............................................ 42
2.2 ESTRUTURA TODO – PARTE (TP) ........................................................................................... 43
2.3 CONEXÕES ................................................................................................................................... 44
2.3.1 Conexões de ocorrência ...................................................................................................... 44
sumário
VIII
2.3.2 Cardialidade ......................................................................................................................... 45
2.3.3 Conexão de mensagem ....................................................................................................... 45
2.3.4 Polimorfismo ........................................................................................................................ 47
LEITURA COMPLEMENTAR ............................................................................................................ 48
RESUMO DO TÓPICO 3..................................................................................................................... 54
AUTOATIVIDADE .............................................................................................................................. 55
UNIDADE 2 - UNIFIED MODELING LANGUAGE (UML) ........................................................ 57
TÓPICO 1 - INTRODUÇÃO A UML ................................................................................................ 59
1 INTRODUÇÃO .................................................................................................................................. 59
2 BREVE HISTÓRICO DA UML ....................................................................................................... 59
3 POR QUE MODELAR SOFTWARE? .............................................................................................. 61
3.1 LEVANTAMENTO E ANÁLISE DE REQUISITOS .................................................................. 63
3.2 PROTOTIPAÇÃO ......................................................................................................................... 65
3.3 PRAZOS E CUSTOS ..................................................................................................................... 67
3.4 MANUTENÇÃO ........................................................................................................................... 68
3.5 DOCUMENTAÇÃO HISTÓRICA .............................................................................................. 70
4 EVOLUÇÃO ........................................................................................................................................ 71
RESUMO DO TÓPICO 1..................................................................................................................... 73
AUTOATIVIDADE .............................................................................................................................. 74
FASES DO DESENVOLVIMENTO DE UM SISTEMA UML ...................................................... 77
1 INTRODUÇÃO .................................................................................................................................. 77
2 ANÁLISE DE REQUISITOS ............................................................................................................ 77
3 ANÁLISE ............................................................................................................................................. 79
4 DESIGN (PROJETO) .......................................................................................................................... 81
5 PROGRAMAÇÃO ............................................................................................................................. 82
RESUMO DO TÓPICO 2..................................................................................................................... 84
AUTOATIVIDADE .............................................................................................................................. 85
TÓPICO 3 - MODELOS DE ELEMENTOS ..................................................................................... 87
1 INTRODUÇÃO .................................................................................................................................. 87
2 CLASSES ............................................................................................................................................. 87
3 OBJETOS ............................................................................................................................................. 89
4 ESTADOS ............................................................................................................................................ 90
5 PACOTES............................................................................................................................................. 91
6 COMPONENTES ............................................................................................................................... 92
7 RELACIONAMENTOS .................................................................................................................... 93
8 MECANISMOS GERAIS ................................................................................................................. 98
LEITURA COMPLEMENTAR ............................................................................................................ 101
RESUMO DO TÓPICO 3..................................................................................................................... 103
AUTOATIVIDADE .............................................................................................................................. 104
UNIDADE 3 - DIAGRAMAS ............................................................................................................. 107
TÓPICO 1 - DIAGRAMAS DE CASOS DE USO ........................................................................... 109
1 INTRODUÇÃO .................................................................................................................................. 109
2 ATORES ............................................................................................................................................... 109
3 CASO DE USO ................................................................................................................................... 111
4 DOCUMENTAÇÃO DE CASOS DE USO .................................................................................... 113
5 ASSOCIAÇÕES.................................................................................................................................. 114
IX
6 INCLUSÃO ......................................................................................................................................... 114
7 EXTENSÃO ......................................................................................................................................... 115
8 ESPECIALIZAÇÃO/ GENERALIZAÇÃO .................................................................................... 117
9 EXEMPLOS DE DIAGRAMA DE CASOS DE USO ................................................................... 119
RESUMO DO TÓPICO 1..................................................................................................................... 122
AUTOATIVIDADE .............................................................................................................................. 123
TÓPICO 2 - DIAGRAMA DE CLASSES .......................................................................................... 125
1 INTRODUÇÃO .................................................................................................................................. 125
2 CLASSES, ATRIBUTOS E MÉTODOS ......................................................................................... 125
3 ABSTRAÇÃO...................................................................................................................................... 129
4 ENCAPSULAMENTO....................................................................................................................... 130
4.1 HIERARQUIA DAS CLASSES .................................................................................................... 133
5 HERANÇA .......................................................................................................................................... 133
5.1 HERANÇA MÚLTIPLA ............................................................................................................... 135
6 CLASSE ASSOCIATIVA .................................................................................................................. 137
7 RESTRIÇÃO ....................................................................................................................................... 139
8 PERSISTÊNCIA ................................................................................................................................. 139
9 EXEMPLOS DE DIAGRAMAS DE CLASSES ............................................................................. 140
RESUMO DO TÓPICO 2..................................................................................................................... 148
AUTOATIVIDADE .............................................................................................................................. 149
TÓPICO 3 - DIAGRAMA DE SEQUÊNCIA ................................................................................... 151
1 INTRODUÇÃO .................................................................................................................................. 151
2 ATORES ............................................................................................................................................... 151
3 OBJETOS ............................................................................................................................................. 152
4 LINHA DE VIDA ............................................................................................................................... 152
5 FOCO DE CONTROLE OU ATIVAÇÃO ...................................................................................... 153
6 MENSAGENS OU ESTÍMULOS .................................................................................................... 154
7 MENSAGENS DE RETORNO ........................................................................................................ 156
8 AUTOCHAMADAS OU AUTODELEGAÇÕES ......................................................................... 157
9 CONDIÇÕES OU CONDIÇÕES DE GUARDA ......................................................................... 158
10 EXEMPLOS DE DIAGRAMAS DE SEQUÊNCIA .................................................................... 159
RESUMO DO TÓPICO 3..................................................................................................................... 164
AUTOATIVIDADE .............................................................................................................................. 165
TÓPICO 4 - DEMAIS DIAGRAMAS EXISTENTES ..................................................................... 167
1 INTRODUÇÃO .................................................................................................................................. 167
2 DIAGRAMAS DE SERVIÇOS ........................................................................................................ 167
3 DIAGRAMA DE COLABORAÇÃO .............................................................................................. 169
4 DIAGRAMA DE ATIVIDADES ..................................................................................................... 172
5 DIAGRAMAS DE ESTADOS ......................................................................................................... 174
LEITURA COMPLEMENTAR ............................................................................................................ 176
RESUMO DO TÓPICO 4..................................................................................................................... 183
AUTOATIVIDADE .............................................................................................................................. 184
REFERÊNCIAS ...................................................................................................................................... 187
X
1
UNIDADE 1
O PARADIGMA DA 
ORIENTAÇÃO A OBJETOS
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
Esta unidade tem por objetivos:
• conhecer o histórico da programação orientada a objetos;
• identificar e caracterizar os objetos;
• compreender a cerca do Processo Unificado, sua caracterização e suas fases;
• conhecer como se comporta o Processo Unificado na Programação Orien-
tada, quais as suas caracterizações e suas fases;
• compreender como ocorre a interação entre os objetos, ou seja, a estrutura 
e relacionamentos, existentes entre os objetos.
Esta unidade de ensino está dividida em três tópicos, sendo que no final 
de cada um deles, você encontrará atividades que contribuirão para a 
apropriação dos conteúdos.
TÓPICO 1 – HISTÓRICO
 
TÓPICO 2 – PROCESSO UNIFICADO (UP)
 
TÓPICO 3 – ESTRUTURAS E RELACIONAMENTOS
2
3
TÓPICO 1
UNIDADE 1
HISTÓRICO
1 INTRODUÇÃO
Como já é de seu conhecimento, a tecnologia se encontra em constante 
evolução, seja em novos hardwares, gadgets e software.
Especificamente falando de software, também é possível perceber que a 
forma como são desenvolvidos os softwares encontra-se em constante evolução. 
Neste contexto, vale destacar que ao final da década de 60 surgiu a “Engenharia 
de Software”, que veio para tentar solucionar problemas de qualidade e 
produtividade de software. Já nas duas décadas seguintes 70 e 80, vários estudiosos 
desenvolveram técnicas com propostas para solucionar estes problemas.
Uma das técnicas desenvolvidas pela Engenharia de Software foi a 
orientação a objetos, que ocorreu na década de 90, sendo amplamente difunda 
entre a comunidade de desenvolvedores, afinal, apresentava maior fidelidade 
às situações em que são aplicadas no mundo real, como: maior produtividade, 
usabilidade e reusabilidade de funções e códigos.
Nesta unidade serão abordados aspectos sobre o paradigma da orientação 
a objetos, sua origem, seus conceitos, suas aplicações, suas vantagens e como 
utilizá-los no contexto de desenvolvimento de software.
2O QUE SÃO OBJETOS?
Para que possamos iniciar nossos estudos sobre a Orientação a Objetos, 
vamos visualizar algumas definições básicas, como por exemplo, o que é um 
objeto? Correia e Tafner (2001, p. 1) se baseiam no dicionário Aurélio, onde temos 
as seguintes definições para palavra objeto: 
[Do lat. Objectu, part. De objicere, ´por, lançar diante´, ´expor´.] S.m.
1. Tudo que é exterior ao espírito;
2. Tudo que é aprendido pelo conhecimento, que não é o sujeito do 
conhecimento;
3. Tudo que é manipulável e manufaturável;
4. Tudo que é perceptível por qualquer dos sentidos;
5. Coisa, peça, artigo de compra e venda;
6. Matéria, assunto.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
4
Ambler (1998, p. 5) em seu estudo traz uma definição computacional 
de objeto onde “considera que qualquer indivíduo, lugar, coisa, tela, relatório 
ou conceito que seja aplicável ao sistema é um objeto”. Ex.: Em um sistema 
universitário, Arthur Dent é um estudante-objeto; ele atende a diversos 
seminários-objetos e está trabalhando em um mestrado-objeto. Já em um sistema 
bancário Artur é um cliente-objeto e possui uma conta corrente-objeto da qual 
emite cheque-objetos.
FIGURA 1 – EXEMPLOS DE OBJETOS
FONTE: Disponível em: <http://www.dreamstime.com/stock-photo-retro-objects-icons-detailed-
set-image30928100>. Acesso em: 23 dez. 2014.
TÓPICO 1 | HISTÓRICO
5
Objetos são, com frequência, semelhantes a outros tipos de objetos.
Estudantes compartilham de características semelhantes (fazem os 
mesmos tipos de coisas, são descritos da mesma forma), cursos compartilham 
características semelhantes, contas bancárias compartilham características 
semelhantes e assim por diante.
Assim, ao analisar as duas citações descritas acima, podemos concluir que 
objeto é uma coisa física (pedra), ou abstrata (uma equação ou conta corrente).
2.1 OBJETOS COMPUTACIONAIS
Objetos computacionais procuram reproduzir as mesmas características 
e comportamentos dos objetos do mundo real dentro de um sistema. Correia e 
Tafner (2001) reforçam que os programadores podem interagir com estes objetos 
ativando características ou comportamentos, sem necessidade de entender o 
funcionamento interno do objeto computacional. Ou seja, para interagir com 
objetos, precisamos apenas conhecer o que estes objetos fazem e usá-los, nada 
mais.
2.2 OS DIFERENTES TIPOS DE OBJETOS 
COMPUTACIONAIS
Para que você acadêmico possa compreender melhor a relação existente 
entre os objetos computacionais e seu comportamento agregado, seguem alguns 
tipos diferentes de objetos computacionais encontrados, bem como seus exemplos.
2.2.1 Objetos computacionais visuais
A utilização de programação visual proporciona ao usuário uma 
experiência totalmente interativa. Desta forma, o usuário pode interagir 
com sistema computacional através do mouse ou teclado, apertando botões, 
selecionando itens de um calendário, escrevendo em um campo texto ou 
selecionando itens de uma lista, conforme ilustrado na figura 2.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
6
FIGURA 2 – OBJETOS COMPUTACIONAIS VISUAIS COMUNS PARA INTERFACE COM USUÁRIO
FONTE: Sistema ERP Empresa Supero Tecnologia
2.2.2 Objetos com tarefa relacionada
Os desenvolvedores de softwares utilizam os objetos computacionais 
visuais para desenvolver e realizar tarefas relacionadas a dados proporcionando 
aos usuários: janelas, campos ou botões com os quais estes possam interagir. 
Ex.: Um editor de textos qualquer, conforme representado na figura a 
seguir, é um bom exemplo. Neste editor, o documento é apresentado ao usuário 
por meio de uma interface gráfica (também orientada a objetos) que permite 
uma interação direta e praticamente total com o documento em que as barras de 
ferramentas são objetos com os quais o usuário pode interagir com o texto.
TÓPICO 1 | HISTÓRICO
7
FIGURA 3 – OBJETOS COM TAREFA RELACIONADA COMUM PARA INTERFACE COM USUÁRIO
FONTE: O autor
2.2.3 Objetos multimídias
Os objetos multimídia proporcionam uma rica experiência de interação 
com o usuário. Este tipo de objeto computacional possibilita a reprodução de 
sons, imagens, animações ou vídeos da mesma forma que nos editores de texto. 
Como podemos verificar na figura a seguir, no reprodutor de fotos as barras de 
ferramentas são objetos que permitem que o usuário interaja com o conteúdo 
alterando seu comportamento.
FIGURA 4 – OBJETOS MULTIMÍDIAS COMUNS PARA INTERFACE COM USUÁRIO
FONTE: O autor
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
8
2.2.4 Objetos de domínio do trabalho
São características ou compartimentos de um objeto ou sistema 
operacional, criado para ficar, na maioria das vezes, oculto aos usuários. Afinal, 
estes estão diretamente envolvidos com o funcionamento do sistema ou objeto 
computacional. Para exemplificar esta situação observe na figura a seguir o 
gerenciador de tarefas do sistema operacional. Ele está quase sempre oculto, 
garantindo que os milhares de objetos do sistema operacional que fazemos uso 
trabalhem adequadamente.
FIGURA 5 – OBJETOS DE DOMÍNIO DE TRABALHO COMUNS PARA INTERFACE COM USUÁRIO
FONTE: O autor
TÓPICO 1 | HISTÓRICO
9
2.3 ORIENTAÇÃO A OBJETOS
O conceito de Orientação a Objetos surgiu com o intuito de minimizar os 
problemas encontrados até então na criação de softwares complexos, projetados 
por meio de decomposição funcional e sub-rotinas (ARAÚJO, 2009).
A análise e programação orientada a objetos, não se resume apenas 
na utilização de componentes de interface gráfica, mas, sim, na definição e 
programação do sistema computacional, desde que atenda à metodologia.
Metodologia esta, que segundo Correia e Tafner (2001, p. 7) serve tanto 
para a definição lógica do sistema quanto para a sua implementação, sendo esta 
uma das vantagens da Orientação a Objetos.
2.3.1 Análise orientada a objetos
Como já foi visto anteriormente, um objeto é qualquer coisa, real ou 
abstrata, a respeito da qual armazenamos dados e os métodos que os manipulam 
disparam operações que mudam o estado dos objetos, possibilitando que eles 
interagem uns com os outros. 
Segundo Araújo (2009, p. 46), “o foco da análise Orientada a Objetos é no 
mapeamento de uma solução sistêmica para algum processo de negócio”. Assim, 
na análise orientada a objetos, os analistas e desenvolvedores têm como objetivo 
principal identificar os objetos que farão parte do sistema computacional que está 
sendo automatizado, seus atributos e principalmente no comportamento destes 
objetos dentro do sistema computacional.
 
Larman (2004, p. 31) descreve que durante a análise orientada a objetos, 
“o objetivo é encontrar e descrever os objetos – ou conceitos – no domínio do 
problema. No caso do sistema de informação de uma biblioteca, por exemplo, 
alguns dos conceitos incluem Livro, Biblioteca e usuário”, observe a representação 
por meio da figura a seguir, demonstrada na programação orientada a objetos.
Orientação a Objetos consiste em considerar os sistemas computacionais como 
uma coleção de objetos que interagem de maneira organizada (FARINELLI, 2007).
IMPORTANT
E
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
10
2.3.2 Análise orientada a objetos
Segundo Larman (2004, p. 31), “durante o projeto orientado a objetos, há 
uma ênfase na definição dos objetos de software e como eles colaboram para a 
satisfação dos requisitos. No sistema da biblioteca, por exemplo, um objeto de 
software Livro, pode ter um atributo título e um método obterCapítulo”, observe 
a figura a seguir.
Em seu estudo David (2007, p. 1) define que a Programação Orientada a 
Objetos “foi criada para tentar aproximar o mundo real do mundo virtual. Assim, 
a ideia fundamental é tentar simular o mundo real dentro do computador. Para 
isso, nada mais natural do que utilizar Objetos, afinal, nosso mundo é composto 
por objetos”.
Na Programação Orientada a Objetos, o analista ou desenvolvedor é 
responsável por delinear o mundo dos objetos, e assim determinar como devem 
interagir entre si. Desta forma, é possívelperceber que os objetos conversam 
entre si por meio de envio de mensagens, e, assim, a função do analista ou 
desenvolvedor é verificar quais devem ser as mensagens que cada objeto deve 
receber, e consequentemente verificar qual ação deve ser tomada ao receber cada 
mensagem.
Finalmente Larman (2004) escreve que durante a implementação ou 
programação orientada a objetos, os objetos são implementados, como uma classe 
Livro em Java, conforme demonstra a figura seguinte.
“a Análise Orientada a Objetos consiste em definir quais objetos fazem parte de 
um sistema e a maneira como se comportam” (CORREIA e TAFNER, 2001, p. 8).
IMPORTANT
E
TÓPICO 1 | HISTÓRICO
11
FIGURA 6 – A ORIENTAÇÃO A OBJETOS ENFATIZA A REPRESENTAÇÃO DE OBJETOS
FONTE: LARMAN (2004, p. 31)
2.3.3 Vantagens e benefícios da 
orientação a objetos
Ao estudar a Orientação a Objetos, fica fácil perceber que sua principal 
vantagem é a utilização de uma mesma metodologia, tanto para a análise de 
sistemas, quanto para a programação.
Neste contexto, Farinelli (2007) descreve que a Orientação a Objetos 
consiste em conceber um sistema computacional como um todo orgânico 
formado por objetos que se relacionam entre si, trazendo consigo alguns 
benefícios, como por exemplo: unificação entre dados e processos; consistência 
entre análise e desenvolvimento; reutilização e aumento da produtividade; 
multidesenvolvimento e, por último, mas não menos importante, suas facilidades 
de manutenção.
“Programação Orientada a Objetos consiste em utilizar objetos computacionais 
para implementar a funcionalidade de um sistema”. (CORREIA e TAFNER, 2001, p. 8)
IMPORTANT
E
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
12
Assim, para finalizar o pensamento acerca deste tema, pode-se verificar 
que a principal utilização desta ferramenta é a reutilização das informações 
constantes no sistema.
13
Neste tópico, vimos:
• O Paradigma da Orientação a Objetos, que trata da utilização no 
desenvolvimento de softwares, seu histórico; afinal, surgiu há algumas 
décadas e, desde então, vem sendo difundido e adaptado às necessidades do 
mercado.
• Os objetos e seus diferentes tipos: objetos computacionais, objetos visuais, 
objetos multimídias, objetos de domínio do trabalho e objetos com tarefa 
relacionada.
• A análise e programação orientada a objetos, que segundo David (2007), a 
Programação Orientada a Objetos foi criada para tentar aproximar o mundo 
real do mundo virtual. Assim, a ideia fundamental é tentar simular o mundo 
real dentro do computador. 
Neste momento, você está apto a realizar as autoatividades deste tópico 
e iniciar na sequência, o Tópico 2 desta unidade.
Bom estudo!
RESUMO DO TÓPICO 1
14
AUTOATIVIDADE
1 Na área da informática um objeto pode ser considerado qualquer indivíduo, 
lugar, coisa, tela, relatório ou conceito que seja aplicável ao sistema. Com 
base nesta definição, cite os diversos tipos de objetos computacionais.
2 São características ou compartimentos de um objeto ou sistema operacional, 
criados para ficarem, na maioria das vezes, ocultos aos usuários. Esta 
afirmação se refere a:
a) Objetos multimídias.
b) Objeto domínio de trabalho.
c) Objetos computacionais visuais.
d) Objetos com tarefa relacionada.
3 Assinale V para as sentenças verdadeiras e F para as falsas no que diz 
respeito à Orientação a Objetos.
( ) A metodologia utilizada na Orientação a Objetos serve tanto para 
programação quanto para análise.
( ) A Análise Orientada a Objetos é bem definida e consiste em apresentar 
quais os objetos que compõem um sistema e como se comportam.
( ) Com relação à Programação Orientada a Objetos, ela somente utiliza 
a estrutura de dados que pode simular o comportamento dos objetos, 
prejudicando, desta forma, a análise e programação do sistema.
( ) Uma das vantagens da Análise de Orientação a Objetos do analista ou 
desenvolvedor é de dividir com o usuário seu entendimento acerca do 
programa.
Agora, assinale a sequência CORRETA:
a) ( ) V – F – F – V.
b) ( ) F – F – V – F.
c) ( ) V – V – F – V.
d) ( ) F – V – F – F.
15
4 Utilizando-se das informações recebidas durante o estudo deste tópico, 
descreva a diferença em Análise e Programação Orientada a Objetos.
5 Descreva uma das principais vantagens da Orientação a Objetos.
16
17
TÓPICO 2
PROCESSO 
UNIFICADO (UP)
UNIDADE 1
1 INTRODUÇÃO
O Processo Unificado é um dos mais importantes padrões da indústria 
de software atual. Vale destacar que o processo unificado (UP ou Unified Process) 
foi desenvolvido por três importantes pioneiros da orientação a objetos nos anos 
1990 (Jacobson, Booch e Rumbaugh). Este é o resultado de mais de 30 anos de 
experiência acumulada em forma de projetos, notações e processos.
O UP é o primeiro modelo de processo inteiramente adaptado ao uso da 
notação UML (Unified Modeling Language). Sua concepção foi baseada nas práticas 
de maior Retorno do investimento (ROI) de mercado.
Wazlawick (2013, p. 75) descreve ainda que as atividades do UP são bem 
definidas no seguinte sentido:
a)Elas são compostas por uma descrição clara e precisa.
b)Apresentam responsáveis.
c)Nestas atividades apresentam-se os artefatos de entrada e saída.
d)Determinam as dependências entre as atividades.
e)Possuem um modelo de ciclo de vida bem definido.
f)São acompanhadas de procedimentos adequados para o uso das 
ferramentas disponibilizadas. 
g)Indicam o uso da linguagem UML.
Neste tópico será abordado acerca do Processo Unificado, principalmente 
sua caracterização, suas fases e por fim suas derivações.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
18
2 CARACTERIZAÇÃO DO UP
O UP é um framework extensível para a concepção de processos, podendo 
ser adaptada as características de diferentes empresas e projetos (WAZLAWICK, 
2013). Vejamos a seguir as principais características do UP:
a) Dirigido por Caso de Uso
Este é um processo compreendido do ponto de vista do usuário, não 
antecipando decisões de implementações. Para o UP, o conjunto de casos de uso 
deve esgotar toda a funcionalidade possível do sistema. 
Neste momento, vale destacar, a aplicação mais fundamental do caso de 
uno no desenvolvimento de sistemas é a incorporação dos requisitos funcionais 
de forma organizada. Cada passo dos fluxos principais e alternativos de um 
caso corresponde a uma função do sistema. Requisitos não funcionais podem 
ser anotados juntamente com os casos de usos de seus passos, e requisitos 
suplementares são anotados em um documento à parte (WAZLAWICK, 2013).
FIGURA 7 – CASOS DE USO
FONTE: Disponível em: <http://www.devmedia.com.br/artigo-clube-delphi-83-modelagem-uml-
com-together/11031>. Acesso em: 23 dez. 2014.
Cadastrar
Curso
Cadastrar
Professor
Cadastrar
Disciplina
Cadastrar
Aluno
Matricular
Aluno
Secretaria
TÓPICO 2 | PROCESSO UNIFICADO (UP)
19
a) Centrado na arquitetura
O UP sugere desenvolver uma sólida arquitetura de sistema. As 
funcionalidades identificadas nos diversos casos de uso devem ser incrementadas 
a esta arquitetura.
É importante destacar que a arquitetura pode ser compreendida como 
o conjunto de classes, possivelmente agrupadas em componentes que realizam 
operações definidas pelo sistema. Para Wazlawick (2013, p. 76), “a arquitetura 
é basicamente um modelo que define a estrutura da informação, suas possíveis 
operações e sua organização em componentes ou até mesmo em camadas”.
FIGURA 8 – CENTRADO NA ARQUITETURA
FONTE: Disponível em: <http://slideplayer.com.br/slide/345298/>. Acesso em: 23 dez. 2014.
A arquitetura se desenvolve por meio das visões dos usuários demonstradas 
em casos de uso, sendo esta influenciada por fatores de implementação: arquitetura 
de computador, sistema operacional, dbms, protocolos de redes, linguagem de 
programação, ambiente de interface gráfica, biblioteca de funções disponíveis, 
sistemas legados, necessidade de performance, portabilidade, entre outros.
Application-specific layer
Classes específicas de negócio
Application-general layer
Classes de ServiçosMiddleware layer
Pacotes Genéricos
System-software layer
Sistemas Operacionais
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
20
FIGURA 9 – FATORES QUE INFLUENCIAM A ARQUITETURA
FONTE: Disponível em: <http://slideplayer.com.br/slide/345298/>. Acesso em: 23 dez. 2014.
a) Interativo e Incremental
“Assim como os desenvolvimentos ágeis, o UP preconiza o 
desenvolvimento baseado em ciclos interativos de duração fixa, onde em cada 
interação a equipe incorpora à arquitetura as funcionalidades necessárias para 
realizar os casos de uso abordados”. (WAZLAWICK, 2013, p. 77).
 
Lembre-se, acadêmico(a), para cada interação os desenvolvedores 
identificam os casos de uso relevante, analisando-os segundo a arquitetura 
selecionada. Ao final, o produto da interação é componente (modelos ou módulos 
executáveis). Desta forma, verifica-se então se os componentes satisfazem os 
casos de uso e a arquitetura. Se a implementação atinge os objetivos, ou seja, 
seus componentes satisfazem os casos de uso e a arquitetura, o desenvolvimento 
passa para a próxima interação, caso contrário, os desenvolvedores devem 
revisar as decisões anteriores e tentar uma nova abordagem (REBOUÇAS, 2007).
System software
Middleware (including frameworks)
Legacy systems
Standards and policies
Nonfunctional requirements
Distribution needs
Constraints and Enablers
Use Cases
Architecture
Experience:
Previous architectures
Architectural patterns
TÓPICO 2 | PROCESSO UNIFICADO (UP)
21
FIGURA 10 – DESENVOLVIMENTO INTERATIVO E INCREMENTAL
FONTE: Disponível em: <http://www.devmedia.com.br/introducao-ao-processo-unificado/3931>. 
Acesso em: 23 dez. 2014.
Como principais benefícios do desenvolvimento interativo, Larman (2004, 
p. 41) destaca: 
a)Mitigação precoce.
b)Progresso visível desde o início.
c)Realimentação, envolvimento do usuário e adaptação imediatos, 
levando a um sistema refinado que atenda, de forma mais adequada, 
às reais necessidades dos interessados no projeto.
d)A complexidade é administrada, desta forma, a equipe não é 
sobrecarregada pela paralisia da análise ou por passos muito longos 
e complexos.
e)O aprendizado obtido em uma interação pode ser metodicamente 
usado para melhorar o próprio processo de desenvolvimento, 
interação por interação.
a) Focado em riscos
Este tipo de abordagem prioriza os casos de uso mais crítico onde são 
tratados primeiro os problemas mais difíceis. Neste caso, os requisitos ou casos 
de uso de maior risco são os mais imprevisíveis, assim, estudá-los primeiramente 
além de garantir maior aprendizado sobre o sistema e decisões arquiteturais, vai 
fazer com que riscos arquiteturais sejam dominados o mais cedo possível.
Realimentação 
da iteração N leva 
ao refinamento 
e adaptação dos 
requisitos e do 
projeto na iteração 
N+1
RequisitosTempo
N
N+1
Quatro semanas por exemplo.
O sistema cresce incrementalmente.
Requisitos
Implementação
Implementação
Testes e 
Integração
Testes e 
Integração
Projeto
Projeto
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
22
2.1 FASES DO UP
Caro(a) acadêmico(a)! Observe, a seguir, quais são as fases que compõem 
a construção de um UP, e ao final das descrições, observe a figura que demonstra 
como essas fases se comportam durante o processo.
a) Concepção (inception)
Busca-se obter uma visão da abrangência do sistema. 
Nesta fase são levantados os requisitos, e um modelo conceitual preliminar 
é construído, bem como ocorre a identificação dos casos de uso de alto nível, que 
implementam as funcionalidades requeridas pelo cliente.
 
Neste momento calcula-se também o esforço de desenvolvimento dos 
casos de uso e é construído o plano de desenvolvimento, sendo este composto 
por um conjunto de ciclos interativos nos quais são acomodados os casos de 
uso. Pode haver, nesta fase, alguma implementação e testes, caso seja necessário 
elaborar protótipos para reduzir riscos, possibilitando assim a verificação dos 
casos de uso que requerem um maior cuidado. 
b) Elaboração (elaboration)
As interações que ocorrem nesta fase têm como objetivo detalhar a análise 
e expandir os casos de uso, para obter assim sua descrição detalhada e verificar 
as situações excepcionais, ou seja, são voltadas para a produção da arquitetura 
básica, e vários casos de uso são demonstrados com detalhes, possuindo uma 
arquitetura projetada a qual utiliza-se de artefatos, os quais podem ser estáticos 
ou dinâmicos.
O modelo conceitual será transformado em definitivo, cada vez mais 
refinado, sobre o qual serão aplicados padrões de análise e uma descrição 
funcional poderá ser feita, bem como o design lógico e físico do sistema.
 
Ao final desta fase, é necessário que os desenvolvedores estejam aptos a 
planejar a fase seguinte a construção.
TÓPICO 2 | PROCESSO UNIFICADO (UP)
23
c) Construção (construction)
A fase de construção possui interações nas quais os casos de uso mais 
complexos já foram tratados e a arquitetura já foi estabilizada, afinal, o produto é 
construído no decorrer desta fase.
Assim, as atividades de suas interações consistem predominantemente na 
geração de código e teste do sistema. 
Com a automação da geração de código e a introdução de modelos de 
desenvolvimento dirigidos a teste, pressupõe-se que um bom design possa dar 
origem rapidamente a um código de alta qualidade, ou seja, o sistema será 
composto por todos os casos de uso que a gerência e os usuários concordaram em 
desenvolver para esta versão do produto.
 
 Vale lembrar que mesmo que ocorram erros, estes podem ser corrigidos, 
estando aptos assim para seguir no processo e iniciar a próxima fase.
d) Transição (deployment)
Esta fase consiste na implementação do sistema no ambiente de produção, 
com a realização de teste e operação, onde a primeira versão do sistema é entregue 
ao usuário.
Também, neste momento, é feita a transferência de dados de possíveis 
sistemas antigos para o novo sistema e o treinamento dos usuários, caso ocorram 
divergências no sistema, os usuários reportam-nas para os desenvolvedores, 
incorporando as melhorias.
Nesta fase ainda pode haver alguma revisão de requisitos e geração de 
código, mas não de forma significativa.
Após todas as definições, conforme mencionado no início deste tópico, 
observe a figura que demonstra as fases, bem como os fluxos de trabalhos no 
decorrer do processo de construção de um UP.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
24
FIGURA 11 – FASES DO UP – FLUXOS DE TRABALHO
FONTE: Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software-o-
processo-unificado-integrado-ao-desenvolvimento-web/803>. Acesso em: 23 dez. 2014.
FIGURA 12 – EXEMPLO DE UM PROCESSO UNIFICADO
FONTE: Disponível em: <http://slideplayer.com.br/slide/345298/>. Acesso em: 23 dez. 2014.
Concepção Elaboração Construção Transição
Inicial Elab.nº 1
Elab.
nº 2
Const.
nº 1
Const.
nº 2
Const.
nº N
Trans.
nº 1
Trans.
nº 2
Teste
Fluxo de trabalho
Interações
Ambiente
Gerenciamento de Projeto
Geren. de
Configuração e Mudança
Implantação
Implementação
Requisitos
Análise e Design
Modelagem de Negócios
Fases
Use-Case
Model
Analysis
Model
Design
Model Deployment
Model
Implementation
Model
Test
Model
Specified by
realized by
distributed by
implemented by
verified by
X
OK
X
OK
X
OK
TÓPICO 2 | PROCESSO UNIFICADO (UP)
25
Observe como se apresenta o ciclo de desenvolvimento de um UP.
FIGURA 13 – CICLO DE DESENVOLVIMENTO UP
FONTE: Disponível em: <http://open2up.blogspot.com.br/>. Acesso em: 23 dez. 2014.
Agora, acadêmico(a), que você conhece a definição de UP, bem como 
suas fases, chegou o momento de conhecer as derivações desta ferramenta de 
programação, as quais se apresentam a seguir, iniciando-se por: RUP (Rational 
Unified Process), AUP (Agile Unified Process), OpenUp (Open Unified Process), EUP 
(Enterprise Unified Process), e finalizando com RUP-SE (Rational Unified Process – 
Systems Engineering).
2.2 RUP – RATIONAL UNIFIED PROCESS
Micro Incremento
Ciclo de 
Vida deIteração
Ciclo de 
Vida de 
Projeto
Dias
Semanas
Meses
Item de Trabalho
Plano de Interação
Plano de Projeto
Foco no
Indivíduo
Foco na
Equipe
Foco nos
Envolvidos
Iniciação Elaboração Construção Trânsição
Valor
Ríscos
Executável 
Estável
Incremento
Interação
“Este processo de engenharia de software fornece uma abordagem 
para assumir tarefas e responsabilidades dentro de uma organização de 
desenvolvimento, cujo objetivo é assegurar a produção de software de alta 
qualidade dentro de prazos e orçamentos previsíveis”. (KRUCHTEN, 2003, p. 
14). O autor ainda afirma que “Derivado dos trabalhos sobre UML e do Processo 
Unificado de Desenvolvimento de Software, ele captura seis das melhores práticas 
no desenvolvimento de software de forma satisfatória para uma grande faixa de 
projetos e organizações”. 
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
26
Em outras palavras, o autor quer dizer que o RUP é um método que pode 
ser utilizado no desenvolvimento de software, contemplando técnicas que os 
membros da equipe de desenvolvimento devem seguir para atingir o objetivo de 
aumentar sua produtividade.
O RUP representa uma nova geração de processos genéricos, a 
mais importante inovação é a separação de fases e workflows, e sobretudo, o 
reconhecimento de que a implantação de software no ambiente do usuário é parte 
do processo. (SENE, 2015).
FIGURA 14 – QUANDO DEVO UTILIZAR O RUP
FONTE: Disponível em: <http://www.wthreex.com/rup/v711_ptbr/rup/guidances/supportingmaterials/
introduction_to_rup,_uRs44C8CEdqfj_h52-wqcw.html> e <http://www.tiespecialistas.com.br/2011/02/
rup-primeiros-passos/>. Acesso em: 23 dez. 2014.
Maior Complexibilidade Técnica
- Tempo real incorporado, distribuído, tolerância aos defeitos
- Reengenharia de arquitetura sem precedentes, personalizada
- Alto desempenho
Menos Complexibilidade Técnica
- Maioria 4 GL ou baseada em componentes
- Reengenharia de aplicativo
- Desempenho interativo
Menor 
Complexibilidade de 
Gerenciamento
- Pequena escala
- Informal
- Investidor único
Maior 
Complexibilidade de 
Gerenciamento
- Larga escala
- Contratual
- Muitos investidores
Necessidade de alto 
"nível de cerimônia"
TÓPICO 2 | PROCESSO UNIFICADO (UP)
27
2.2.1 Blocos de Construção do RUP
Identificamos o conjunto de elementos básicos (building blocks) da seguinte 
forma:
a) Quem: define o conjunto de habilidades necessário para realizar determinadas 
atividades.
b) O quê: define algo produzido por uma atividade, como diagramas, relatórios 
ou código.
c) Como: descreve uma unidade de trabalho atribuída a um papel que produz 
determinado conjunto de artefatos.
d) Quando: definem as tendências entre as diferentes atividades.
2.2.2 Papéis no RUP
O papel define um conjunto de comportamentos, habilidades e 
responsabilidades de uma pessoa da equipe. Os papéis dentro de um projeto não 
são necessariamente para pessoas específicas nem para cargos dentro da equipe. 
A mesma pessoa pode exercer vários papéis em diferentes momentos do dia, no 
mesmo projeto.
Vejamos a seguir as categorias em que são organizados os papéis:
2.2.2.1 Papel do Analista
O analista é o responsável por realizar o relacionamento ou contato com 
usuário ou cliente do sistema. As pessoas que exercem este papel devem ser 
capazes de entender quais são as necessidades do sistema, e criar descrições que 
sejam compreendidas pelos designers, desenvolvedores e testadores. 
Além de terem a responsabilidade de atentarem para as adequações de 
reais necessidades, bem como verificar a conformidade com normas e padrões 
estabelecidos.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
28
FIGURA 15 – PAPEL DO ANALISTA
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_implm.
htm>. Acesso em: 23 dez. 2014.
2.2.2.2 Papel do Desenvolvedor
Os desenvolvedores transformam os requisitos em produto de software 
e devem ter o conhecimento necessário para desenvolver os códigos-fonte e 
testá-los.
FIGURA 16 – PAPEL DO DESENVOLVEDOR
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_implm.
htm>. Acesso em: 23 dez. 2014.
Implementar
Componente
Componente
Realizar
Teste Unitário
Corrigir
um Defeito
Desenvolver
Artefatos de
Instalação
Artefatos
de Instalação
Implementar
Componentes de
Teste e de Subsistemas
Componente
de Teste
Subsistema de 
Implementação
Implementador
TÓPICO 2 | PROCESSO UNIFICADO (UP)
29
2.2.2.3 Papel de Testador
É responsável por definir técnicas, estratégias, e principalmente definir os 
casos de testes que serão aplicados no sistema, ou seja, tem a função de analisar 
os resultados dos testes e no caso de necessidade, informar aos responsáveis que 
providenciem a correção.
FIGURA 17 – PAPEL DO TESTADOR
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_tstr.
htm>. Acesso em: 23 dez. 2014.
2.2.2.4 Papel de Gerente
O papel de gerente está relacionado principalmente com as atividades de 
planejamento, controle e sobre tudo a organização do projeto.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
30
FIGURA 18 – PAPEL DE GERENTE
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_projm.
htm>. Acesso em: 23 dez. 2014.
2.2.2.5 Outros Papéis
Neste item é possível encontrar outros papéis que não foram classificados 
nos tipos anteriores como: interessados, desenvolvedor de curso, redator técnico 
e administrador de sistemas.
Como o RUP é uma ferramenta adaptável, novos papéis podem ser 
necessários e adicionados a um projeto ou processo específico.
TÓPICO 2 | PROCESSO UNIFICADO (UP)
31
FIGURA 19 – DESENVOLVEDOR DE CURSO
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/
workers/wk_crsdv.htm>. Acesso em: 23 dez. 2014.
FIGURA 20 – ADMINISTRADOR DE SISTEMA
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/
workers/wk_sysad.htm>. Acesso em: 23 dez. 2014.
Desenvolvedor
do Curso
Materiais de 
Treinamento
Desenvolver 
Materiais de 
Treinamento
responsável por
Administrador
do Sistema
Suportar o 
Desenvolvimento
Infraestrutura de 
Desenvolvimento
responsável por
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
32
FIGURA 21 – REVISOR DE PROJETO
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workflow/ovu_mgm.
htm>. Acesso em: 23 dez. 2014.
2.2.3 AUP – Agile Unified Process
O Agile Unified Process é uma versão simplificada do RUP, que aplica 
técnicas ágeis de desenvolvimento dirigido por testes (TDD), modelagem ágil e 
fatoração. 
A AUP teve sua origem no início do século XXI, por meio de um grupo 
de engenheiros, consultores, autores, os quais, após muito estudo, denominaram 
esta pesquisa de The Agile Manifesto, tendo então como objetivo a apresentação 
e discussão de novas técnicas que poderiam ser utilizadas para desenvolver 
softwares, disponibilizando maior agilidade por meio dos conceitos aplicados às 
metodologias já existentes.
TÓPICO 2 | PROCESSO UNIFICADO (UP)
33
Após a criação deste manifesto, percebeu-se que a AUP seria um método 
ágil e que poderia atender às seguintes prerrogativas:
a) Valorizar os indivíduos envolvidos no processo e as interações entre ambos.
b) Produzir softwares funcionais, não somente documentações completas e 
atualizadas.
c) Colaborar com os clientes e não apenas discutir picuinhas contratuais.
d) Estar preparado para a adaptação e introdução de mudanças.
Em sentido complementar, vale destacar os princípios que denominam a 
AUP:
a) Assumir simplicidade.
b) Flexibilidade para mudanças.
c) O software é o primeiro objetivo.
d) Viabilizar esforços futuros.
e) Alterações incrementais.
f) Maximizar o investimento dos interessados no software.
g) Modelar com propósito.
h) Múltiplos modelos.
i) Trabalho com qualidade. 
FIGURA 22 – FASES DO AUP
FONTE: Disponível em: <http://www.cs.sjsu.edu/~pearce/modules/lectures/se/aup.
htm>. Acesso em: 23 dez. 2014.
Testing
Implementation
Modeling
Deployment
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS34
FIGURA 23 – Fases do AUP
FONTE: Disponível em: <http://pt.slideshare.net/redecharles21/aup-seminario-final>. Acesso em: 
23 dez. 2014.
Ao contrário do RUP, conforme demonstra a figura acima, a AUP possui 
apenas sete disciplinas (Modelagem, Implementação, Teste, Implantação, 
Gerenciamento de configuração, Gerenciamento de projeto, Ambiente).
A filosofia de produção de artefatos é minimalista, ou seja, deve gerar o 
mínimo necessário de artefatos para produzir um sistema com qualidade.
2.2.4 Open UP – Open Unified Process
A OpenUP é uma implementação aberta da UP desenvolvida como parte 
do Eclipse Processes Framework, conhecida anteriormente como Basic Unified 
Process (BUP). OpenUP aceita, grande parte dos princípios utilizados no Processo 
Unificado, porém é um método independente de ferramenta, não exigindo grande 
precisão e detalhes nos documentos.
O processo baseia-se em quatro princípios (Colaboração, Evolução, 
Balanceamento e Foco).
O ciclo de vida também é dividido em quatro fases como no UP. Estas 
fases são divididas em interações, porém aqui as equipes se auto-organizam para 
planejar cada uma delas.
Test
Project Management
Configuration Management
Implementation
Deployment
Environment
Model
Inception
I1 E1 C1 T1 T2C2 Cn
Elaboration TransitionConstruction
Phases
Iterations
TÓPICO 2 | PROCESSO UNIFICADO (UP)
35
FIGURA 24 – CICLO DE VIDA OpenUP
FONTE: Disponível em: <http://open2up.blogspot.com.br/>. Acesso em: 23 dez. 2014.
Em relação ao UP, a maioria dos processos opcionais foi eliminada e 
outros foram mesclados. O resultado é um processo mais simples, mais ainda fiel 
aos princípios do RUP.
FIGURA 25 – MODELO DE CICLO DE VIDA DE UMA INTERAÇÃO OpenUp
FONTE: Disponível em: <http://pt.slideshare.net/jeanstreleski/open-up-gerenciando-projetos-
sob-principios-geis>. Acesso em: 23 dez. 2014.
2.2.5 EUP – Enterprise Unified Process
O modelo EUP visualiza ao desenvolvimento de software não apenas 
como um projeto a ser desenvolvido, mais como algo intrínseco ao ciclo de vida 
da empresa. Este modelo foi proposto como uma extensão ao modelo RUP para 
prover, além das fases do RUP, duas novas fases para tratar a evolução ou suporte 
ao sistema e à aposentadoria do sistema.
Iteration planning Stable weekly build Stable iteration 
build
Iteration review / 
Retrospective
Upfront planning
and architecture
Continuous
micro-increments / 
bug-fixing / builds
Continuous
bug-fixing / 
micro-increments / 
builds
A few 
hours
A few 
hours
A few 
days
- Escopo do sistema
- Requisitos do sistema
- Custo geral do sistema
- Riscos em potencial
- Baseline da Arquitetura
- Riscos em potencial
- Componentes do sistema
- Reusabilidade
- Qualidade do sistema
- Versões Alfa e Beta
- Release do sistema
- Teste Beta
- Conversão do BD
- Treinamentos
- Distribuição
- Documento de visão
- Lista de riscos
- Plano de interação
- Glossário
- Modelo de Caso de Uso
- Protótipos
- Protótipo
- Modelo de Design
- Modelo de Dados
- Modelo de Implantação
- Release do sistema
- Casos de Testes
- Material de Suporte
- Release
- Material de Suporte
- Casos de Testes
- Pacote de Distribuição
Objetivos do
Ciclo de Vida
FASES MARCOS OBJETIVOS ARTEFATOS
ElaboraçãoIniciação
Arquitetura do
Ciclo de Vida
Construção
Recurso Opera-
cional Inicial
Transição
Liberação do
Produto
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
36
FIGURA 26 – FASES EUP
FONTE: Disponível em: <http://www.enterpriseunifiedprocess.com/>. Acesso em: 23 dez. 2014.
O objetivo principal da disciplina de operação e suporte é manter o 
produto funcionando em produção. Afinal, estes devem garantir o correto 
funcionamento do software, a evolução dos processos, a realização dos backups, 
planos de recuperação de desastre devem ser criados e executados se necessário.
A fase de aposentadoria consiste na retirada de um sistema de operação 
onde sistemas antigos são substituídos por sistemas novos ou retirados de 
operação.
2.2.6 RUP-SE – Rational Unified Process 
– Systems Engineering 
O RUP-SE é uma extensão do modelo RUP, especialmente adequada para 
o desenvolvimento de sistemas de grande porte, envolvendo software, hardware, 
pessoas e componentes de informação.
TÓPICO 2 | PROCESSO UNIFICADO (UP)
37
FIGURA 27 – CICLO DE VIDA RUP-SE
FONTE: Disponível em: <http://www.devarticles.com/c/a/Development-Cycles/Organizing-RUP-
SE-Projects/1/>. Acesso em: 26 dez. 2014.
O Framework permite, neste caso, considerar o sistema a partir de 
diferentes perspectivas (lógica, física ou informacional). Isto pode ser bastante útil 
quando se deseja demonstrar ou discutir aspectos de um sistema com diferentes 
interessados.
Maiores informações acerca do processo unificado, bem como selecionar 
versões do processo unificado é possível por meio dos seguintes sites:
<www.rational.com/rup>. 
<http://.flylib.com/books>. 
<http://savannah.nongnu.org/>. 
<http://www.git-scm.com/>. 
<http://mercurial.selenic.com/>. 
IMPORTANT
E
38
RESUMO DO TÓPICO 2
Neste tópico, vimos:
• O Processo Unificado (UP), bem como conhecer suas principais definições, 
sua caracterização, suas fases, bem como suas derivações (RUP – Rational 
Unified Process; AUP – Agile Unified Process; OpenUp – Open Unifies Process; 
EUP – Enterprise Unified Process; RUP-SE – Rational Unified Process – Systems 
Engineering).
• A importância de cada uma das derivações apresentadas, e como podemos 
utilizá-las nos diferentes tipos de projetos. Afinal cada uma possui suas 
especificidades e suas características próprias. Neste sentido, para auxiliar 
na compreensão, foram apresentadas por meio das figuras as fases de cada 
processo.
Neste Momento, você está apto a realizar as autoatividades deste tópico, 
e, na sequência, iniciar o estudo do Tópico 3 desta unidade.
Bom estudo!
39
AUTOATIVIDADE
1 Descreva como se caracteriza processo unificado.
2 Explique as fases do processo unificado.
3 Entre os diversos papéis assumidos no RUP, quais são os que definem um 
conjunto de comportamentos e responsabilidades para determinada pessoa? 
Com base nesta afirmação, analise a figura a seguir:
Agora, assinale a alternativa CORRETA:
a) ( ) Outros papéis.
b) ( ) Papel do testador.
c) ( ) Papel do gerente.
d) ( ) Papel do desenvolvedor.
4 A figura a seguir se refere a qual das derivações apresentadas no Processo 
Unificado?
40
a) Open-Up – Open Unified Process.
b) AUP – Agile Unified Process.
c) RUP – Rational Unifies Process.
d) EUP – Enterprise Unified Process.
5 As interações que ocorrem nesta fase têm como objetivo detalhar a análise e 
expandir os casos de uso, para obter assim sua descrição detalhada e verificar 
as situações excepcionais, ou seja, são voltadas para a produção da arquitetura 
básica, e vários casos de uso são demonstrados com detalhes, possuindo uma 
arquitetura projetada que se utiliza de artefatos, que podem ser estáticos ou 
dinâmicos. A qual das fases esta afirmação se refere?
a) Construção.
b) Concepção.
c) Transição.
d) Elaboração.
Test
Project Management
Configuration Management
Implementation
Deployment
Environment
Model
Inception
I1 E1 C1 T1 T2C2 Cn
Elaboration TransitionConstruction
Phases
Iterations
41
TÓPICO 3
ESTRUTURAS E 
RELACIONAMENTOS
UNIDADE 1
1 INTRODUÇÃO
Conforme foi abordado nos tópicos anteriores, você entrou em contato 
com as definições acerca dos objetos, seus diferentes tipos e uma prévia sobre a 
Análise e Programação Orientada a Objetos.
Teve contato também com os princípios básicos da Orientação a Objetos, 
bem como seus principais conceitos. Agora, neste tópico, iremos abordar sobre as 
estruturas de relacionamento dos objetos, ou seja, de que forma estas estruturas 
auxiliam os analistas e desenvolvedores na composição e apresentação dos objetos 
dentro do contexto de software, possibilitando assim uma melhor visualização 
do problema a ser estudado.
Ainda neste contexto, vale frisar que o relacionamento entre os objetos 
ocorre quando um objeto se referencia ao outro, ouquando um método de um 
objeto é ativado por outro objeto.
2 TIPOS DE ESTRUTURAS E RELACIONAMENTOS
Segundo Correia e Tafner (2001, p. 39), “Na Programação Orientada a 
Objetos, as estruturas possibilitam os analistas ou programadores arranjar os 
objetos de forma que possa visualizar melhor o domínio e a complexidade do 
problema em estudo”. Existem dois tipos básicos de estrutura: Generalização-
Especialização e Todo-Parte, que serão estudadas na sequência.
E com relação aos relacionamentos, os autores descrevem que os 
relacionamentos ocorrem quando os objetos se referenciam uns aos outros 
(conexão de ocorrência), ou quando um objeto ativa um método de outro objeto 
(conexão de mensagem).
42
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
42
2.1 ESTRUTURA GENERALIZAÇÃO 
– ESPECIALIZAÇÃO (GE)
A Generalização é conhecida pelo conceito de associar indivíduos com 
atributos em comum, e ao mesmo tempo despreza as diferenças.
Quando adaptamos pela generalização, não estamos distorcendo seu 
conceito, estamos ampliando-o não apenas para o grupo de indivíduos, mas 
também vamos generalizar alguns atributos para que a aderência do conceito seja 
maior (ANGELANTONIO, 2014).
FIGURA 28 – EXEMPLO DE GENERALIZAÇÃO – ESPECIALIZAÇÃO
FONTE: Disponível em: <https://alexevalerio.wordpress.com/2014/04/07/modelagem-de-
banco-de-dados-generalizacaoespecializacao/>. Acesso em: 26 dez. 2014.
A Especialização é muito semelhante à herança, a qual já estudamos 
anteriormente. Assim, caso tenha interesse em realizar uma herança, deve utilizar 
a estrutura Generalização-Especialização.
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
43
2.2 ESTRUTURA TODO – PARTE (TP)
Este tipo de estrutura é bastante característico, uma vez que trata 
de agregação ou decomposição de objetos. “Essa estratégia é muito útil na 
identificação dos objetos e dos seus componentes diante de um determinado 
problema em estudo”. (CORREIA E TAFNER, 2001, p. 41).
FIGURA 29 – ESTRUTURA TODO-PARTE
FONTE: Disponível em: <http://slideplayer.com.br/slide/298878/>. 
Acesso em: 26 dez. 2014.
Além desta definição, é importante destacar que a estrutura Todo-Parte é 
composta por uma característica conhecida por cardinalidade, que é importante 
para determinar o número de ocorrências em um relacionamento.
FIGURA 30 – CARDINALIDADE NA PRÁTICA
FONTE: Disponível em: <http://slideplayer.com.br/slide/298878/>. Acesso em: 26 dez. 2014.
Todo
Parte 1 Parte 2
Automóvel Automóvel
0..1
4..5
Roda Roda Roda Roda Roda
44
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
44
No exemplo apresentado na figura 30, um carro, como todos sabem, é 
composto por quatro rodas (cinco, considerando o estepe), sendo todas iguais. 
Desta forma denominamos roda um objeto e se repete quatro vezes dentro do 
objeto carro. Em outras palavras, conforme a definição, roda ocorre quatro vezes 
neste relacionamento entre carro e roda.
2.3 CONEXÕES
Na Programação Orientada a Objetos, existem dois tipos de conexão 
entre os objetos, que são conhecidas por Conexões de Ocorrência e Conexões de 
Mensagens (serão estudadas posteriormente), porém é importante destacar que 
ambas não possuem nenhum tipo de hierarquia ou estrutura.
2.3.1 Conexões de ocorrência
Uma Conexão de Ocorrência existe quando um atributo de um objeto 
contém uma referência a outro objeto. Sendo assim, “a necessidade de criar uma 
conexão de ocorrência com frequência surge da identificação de atributos em um 
objeto que é redundante e que sob uma análise mais atenta, percebe-se fazerem 
parte de outro objeto”. (CORREIA e TAFNER, 2001, p. 43).
FIGURA 31 – CONEXÃO DE OCORRÊNCIA
FONTE: Correia e Tafner (2001, p. 44)
No diagrama representado pela Figura 31 existe uma conexão de 
ocorrência entre carro e pessoa, neste objeto carro contém um atributo chamado 
proprietário, que contém uma ocorrência para um objeto da classe pessoa.
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
45
2.3.2 Cardialidade
Conforme já foi visto anteriormente, Cardinalidade determina o número 
de vezes que um objeto é referenciado ou se referencia ao outro. Quando se refere 
à estrutura todo-parte, a cardinalidade é demonstrada por meio de pares de 
números adjacentes à linha que representa a relação entre os objetos.
FIGURA 32 – CARDINALIDADE ENTRE ALUNO, MATRÍCULA E MATÉRIA
FONTE: Disponível em: <http://e-reality-database.blogspot.com.br/2007/09/cardinalidade.html>. 
Acesso em: 26 dez. 2014.
Observando a Figura 32, contata-se que na cardinalidade existe o aluno que 
pode se matricular em no mínimo uma disciplina e no máximo três disciplinas, e 
neste contexto, cada matéria relaciona-se com as matrículas, e que podem ser de 
no mínimo 0 e no máximo n alunos matriculados.
2.3.3 Conexão de mensagem
Com relação à conexão de mensagem, pode-se dizer que uma mensagem 
é uma ação que envia um método específico no objeto receptor, fazendo com que 
este efetue um comportamento determinado. Este método, por sua vez, retorna 
ou não uma resposta para o objeto transmissor. Para simplificar, a conexão de 
mensagem ocorre sempre que um objeto envia uma mensagem a outro objeto, 
neste contexto apresenta-se o método transmissor e o receptor.
46
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
46
FIGURA 33 – CONEXÃO DE MENSAGEM
FONTE: Disponível em: <http://slideplayer.com.br/slide/365068/>. Acesso em: 
26 dez. 2014.
Para ajudar em sua compreensão, segue mais um exemplo de conexão de 
mensagem.
FIGURA 34 – OUTRO EXEMPLO DE CONEXÃO DE MENSAGEM
FONTE: Disponível em: <http://slideplayer.com.br/slide/365068/>. Acesso em: 26 dez. 2014.
Analisando as figuras que se referem à conexão de mensagem, pode-se 
perceber que na Figura 33 ocorre a transmissão de uma mensagem entre duas 
pessoas, ou seja, uma realiza uma pergunta e a outra consequentemente a 
responde.
Já na figura 34, estamos falando de um sistema que se refere à locação 
de filmes, neste a locação envia uma mensagem para verificar se o cliente está 
cadastrado para realizar a locação do filme, caso não esteja cadastrado retorna a 
mensagem solicitando o cadastro do cliente.
Cadastro_Cliente
Criar_Cliente
Consultar_Cliente Criar_C
liente
Cliente
Locação
A_Fita
A _Cliente
Locar_Fita_Cliente
Cliente
Locar_Fita
Liberar_Fita
Consultar_Disp
Cadastro_Fita
Consultar_Fita
1,1 1,1
1,1 1,1
0,n
0,n
0,n 0,n
C
onsultar_C
liente
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
47
2.3.4 Polimorfismo
Segundo a definição de Lima (2005), polimorfismo é o princípio em que 
classes derivadas de uma mesma superclasse podem invocar operações que 
têm a mesma assinatura, mas comportamentos diferentes em cada subclasse, 
produzindo resultados diferentes, dependendo de como cada objeto implementa 
a operação. Continuando, o autor destaca que é a capacidade de objetos diferentes 
possuírem operações com o mesmo nome e a mesma lista de argumentos, mas 
que executam tarefas de formas diferentes.
FIGURA 35 – POLIMORFISMO
FONTE: Disponível em: <http://www.tomasvasquez.com.br/cursocsharp/programacao_orientada_
objetos/polimorfismo>. Acesso em: 26 dez. 2014.
Por meio da figura apresentada sobre polimorfismo, foi possível perceber 
certa semelhança com a Herança que já foi estudada anteriormente, ou seja, a 
subclasse bicicleta e a subclasse carro, ambos herdaram da superclasse veículo os 
métodos movimentar e parar, assim cada objeto responde à mesma mensagem, 
porém cada um a sua maneira. Ou seja, a bicicleta movimenta-se em duas rodas, 
enquanto o carro necessita de quatro rodas para se movimentar, mas ambos 
pertencem à mesma superclasse veículo.
Processos de Herança
Membros de Herdados
Classe Veículo
• ...
• Movimentar
• Parar
• ...
Classe Bicicleta
• ...
• Movimentar
• Parar
• ...
Classe Carro
• ...
• Movimentar
• Parar
• ...
48
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
Herança
A herança é um mecanismo que permite a uma dada classe (classe 
derivada-subclasse) aceder a dados e métodos de uma outra classe (classe base-
superclasse). A utilização de herança aplica-se de uma formanatural a todos os 
procedimentos definidos de uma forma hierárquica, onde as classes derivadas 
herdam as propriedades da(s) classe(s) base(s).
O processo da criação de uma classe derivada, permite:
• Especialização: criação de uma classe específica de uma dada classe, como por 
exemplo a definição de uma classe para vectores de números inteiros com base 
na classe genérica vector.
• Generalização: criação de uma classe que prolonga o comportamento da classe 
base (oposto a especialização).
• Extensão: a classe derivada introduz novas funcionalidades à classe base, mas 
não altera as existentes.
• Limitação: a classe derivada restringe as funcionalidades de uma classe base, 
como, por exemplo, restringir as funcionalidades da classe vector por forma a 
implementar só as funcionalidades pretendidas.
• Combinação: utilização de herança múltipla por forma a criar novas classes de 
alto nível.
Visibilidade externa de uma classe:
class TESTE
{public: // Pode ser acedido por qualquer função
int f();
int x;
protected: // Pode ser acedido por qualquer função membro,
// função amiga ou classes derivadas;
int g();
int y;
private: // Só pode ser acedido pelas funções membro da
// própria classe ou por funções membro amigas
int h();
int z;
};
LEITURA COMPLEMENTAR
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
49
A parte protected: da classe permite:
• Definição de variáveis e métodos por forma a melhorar o acesso à classe base, 
por parte da classe derivada.
• Obter uma maior eficiência no acesso à classe base.
1.1. Herança Simples
class BASE
{public:
int x;
protected:
int y;
int h(int a);
private:
int z;
};
class NATO: public BASE
{public:
int f() { return(x + BASE::x + y);
int g() { return( h() ); }
private:
int x;
};
ou
class NATO: private BASE
{public:
int f() { return(x + BASE::x + y);
int g() { return( h() ); }
private:
int x;
};
class NATO: public BASE
Todos os membros public e protected da classe BASE são membros
public e protected da classe NATO
Todos os membros private da classe BASE não podem ser acedidos pela classe 
NATO.
class NATO: private BASE
Todos os membros public e protected da classe BASE são membros
private da classe NATO
Todos os membros private da classe BASE não podem ser acedidos pela classe 
NATO.
50
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
1.2. Herança Múltipla
class BASE1
{
public:
int x;
};
class BASE2
{
public:
int y;
};
class BASE3
{
public:
int z;
};
class NATO: public BASE1, public BASE2, public BASE3
{
public:
void f() { return(BASE1::x+BASE2::y+BASE3::z);
};
A Ordem de Derivação é Importante?
É importante para a inicialização (por omissão) das variáveis das classes 
bases e derivadas (ver inicialização de construtores).
Pode-se especificar várias vezes uma classe base numa classe derivada?
Não. Não se pode especificar mais de uma vez como classe básica de uma 
classe derivada, uma vez que uma referência à classe base seria ambígua.
class NATO: public BASE1, public BASE1 // erro
{
public:
void f() { return(BASE1::x+BASE2::y+BASE3::z);
};
Considere o seguinte conjunto de classes bases e derivadas, utilizando herança 
simples e múltipla.
class L
{
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
51
public:
int x;
};
class A: public L
{
public:
int y;
};
class B: public L
{
public:
int z;
};
class C: public A, public B
{
public:
int f() { return(A::y + A::L::x + B::z + B::L::x + y + z); }
};
Em problemas onde existam diversas herança, por vezes torna-se mais 
fácil visualizar a interligação destas classes, através da utilização de um esquema 
representativo da interligação (herança) entre as classes.
Visualização da herança para melhor compreender heranças complicadas
Como aceder à variável “x“ da classe “L“ pertencente à classe “A“?
int main()
{
C derivada;
derivada::A::x = 1; // aceder à variável “x“ da classe “L“ da classe “A“
derivada::B::x = 2; // aceder à variável “x“ da classe “L“ da classe “B“
}
FONTE: Disponível em: <http://www.estig.ipbeja.pt/~rmcp/estig/20062007/1s/lp/cplusplus/
heranca.pdf>. Acesso em: 26 dez. 2014.
52
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
Cardinalidade
Entenda quais são os tipos de relacionamentos e cardinalidade que usamos 
na análise de relacionamento no processo de modelagem de dados, o Modelo de 
Entidade e Relacionamento.
Relacionamento entre entidades é o tipo de ocorrência existente entre 
entidades e aplicáveis no processo de modelar dados. Entender isso é importante 
pois um modelo consistente é a base para um banco de dados de sucesso. O símbolo 
que representa o relacionamento no Modelo de Entidade e Relacionamento 
(MER) é um losango com o nome do relacionamento escrito no seu interior, como 
no exemplo a seguir.
Em um modelo de entidade e relacionamento, nem todas as entidades 
serão relacionadas, há casos em que não há ligação entre elas, nestes casos 
consideramos como entidades isoladas. Embora não seja tão comum, é importante 
levar em conta esta possibilidade. Mas quando as ligações existirem, elas serão 
classificadas de acordo com os tipos a seguir.
Tipos de relacionamento
Existem três tipos de relacionamento entre entidades:
• um-para-um
• um-para-muitos
• muitos-para-muitos
Relacionamento um-para-um
O relacionamento um-para-um é usado quando uma entidade A se 
relaciona com uma entidade B e vice-versa.
Este relacionamento é representado pelo sinal: 1:1
Veja o exemplo:
Pertence
Chefia1 1Gerente Seleção
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
53
Relacionamento um-para-muitos
O relacionamento um-para-muitos é usado quando uma entidade A pode 
se relacionar com uma ou mais entidades B.
Este relacionamento é representado pelo sinal: 1:N
Veja o exemplo:
Relacionamento muitos-para-muitos
O relacionamento muitos-para-muitos é usado quando várias entidades 
A se relacionam com várias entidades B.
Este relacionamento é representado pelo sinal: N:N ou N:M
Veja o exemplo:
Cardinalidade
A cardinalidade é um conceito importante para ajudar a definir o 
relacionamento, ela define o número de ocorrências em um relacionamento. Para 
determinar a cardinalidade, deve-se fazer a pergunta relativa ao relacionamento 
em ambas as direções.
Um departamento possui quantos empregados?
- no mínimo 1 e no máximo N.
Um empregado está alocado em quantos departamentos?
- no mínimo em 1 e no máximo em 1
Somando-se as cardinalidades, definimos o resultado final do 
relacionamento, ou seja, 1:N
 FONTE: Disponível em: <http://www.luis.blog.br/relacionamento-entre-entidades-tipos-e-
cardinalidade.aspx> Acesso em: 26 dez. 2014.
ForneceN NFornecedor Produto
Trabalha1 NSeção Funcionário
54
RESUMO DO TÓPICO 3
Neste tópico, vimos:
• As estruturas de relacionamento dos objetos, e como estas estruturas auxiliam 
os analistas e desenvolvedores na composição e apresentação dos objetos 
dentro do contexto de software, possibilitando, assim, uma melhor visualização 
do problema a ser estudado, facilitando a compreensão deste por parte de 
usuários de negócio e desenvolvedores. 
• O relacionamento entre os objetos ocorre quando um objeto se referencia ao 
outro, ou quando um método de um objeto é ativado por outro objeto.
Assim, ao término deste tópico concluímos a Unidade 1. Com isso, você, 
acadêmico(a), está apto(a) a aplicar os conhecimentos de Orientação a Objetos em 
suas atividades diárias.
Bom estudo!
55
AUTOATIVIDADE
1 Descreva os dois tipos básicos de estruturas que auxiliam os analistas na 
Análise e Orientação a Objetos: 
2 É conhecida pelo conceito de associar indivíduos com atributos em comum, 
e ao mesmo tempo despreza as diferenças. Assinale a alternativa CORRETA 
para esta definição:
a) ( ) Encapsulamento.
b) ( ) Generalização-Especialização.
c) ( ) Classe Abstrata.
d) ( ) Todo-Parte.
3 Observe a figura a seguir e identifique a quem ela pertence:
FONTE: Disponível em: <http://slideplayer.com.br/slide/298878/>. Acesso em: 26 dez. 2014. 
4 Cardinalidade determina o número de vezes que um objeto é referenciado 
ou referencia ao outro, assim, com base nesta