analise orientada a objetos i

Prévia do material em texto

Análise OrientAdA A ObjetOs i
Caderno de Estudos
Prof. jean Carlos Possamai
UNIASSELVI
2015
NEAD
Educação a Distância
GRUPO
CENTRO UNIVERSITÁRIO
LEONARDO DA VINCI
Rodovia BR 470, Km 71, nº 1.040, Bairro Benedito
89130-000 - INDAIAL/SC
www.uniasselvi.com.br
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áfica 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-882-7
 
 1. Programação orientada a objetos. 
 I. Centro Universitário Leonardo Da Vinci. 
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
iiiANÁLISE ORIENTADA A OBJETOS l
iv
UNI
Oi!! Eu sou o UNI, você já me conhece das outras disciplinas. 
Estarei com você ao longo deste caderno. Acompanharei os seus 
estudos e, sempre que precisar, farei algumas observações. 
Desejo a você excelentes estudos! 
 UNI
ANÁLISE ORIENTADA A OBJETOS l
sUMáriO
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 ................................................................................................ 29
2.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
vANÁLISE ORIENTADA A OBJETOS l
viANÁLISE ORIENTADA A OBJETOS l
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
tÓPiCO 2 - 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
viiANÁLISE ORIENTADA A OBJETOS l
2 AtOres ..................................................................................................................... 109
3 CAsO de UsO ...........................................................................................................111
4 dOCUMentAÇÃO de CAsOs de UsO ...................................................................113
5 AssOCiAÇÕes ..........................................................................................................114
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
viiiANÁLISE ORIENTADA A OBJETOS l
resUMO dO tÓPiCO 4 ............................................................................................... 183
AUtOAtiVidAde ......................................................................................................... 184
reFerÊnCiAs ............................................................................................................. 187
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
UNIDADE 1
O PARADIGMA DA ORIENTAÇÃO A 
OBJETOS
OBJETIvOS DE APRENDIzAGEM
 A partir desta unidade, você será capaz de:
	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 
Orientada, 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.
tÓPiCO 1 – O PArAdiGMA dA OrientAÇÃO A 
ObjetOs
 
tÓPiCO 2 – PrOCessO UniFiCAdO (UP)
 
tÓPiCO 3 – estrUtUrAs e relACiOnAMentOs
PLANO DE ESTUDOS
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.
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
HistÓriCO
1 intrOdUÇÃO
tÓPiCO 1
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.
UnidAde 1
2 O 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 
UNIDADE 1TÓPICO 14
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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 conheci-
mento;
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.
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.
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).
UNIDADE 1 TÓPICO 1 5
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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 comestes 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 1TÓPICO 16
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 1 7
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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 1TÓPICO 18
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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
UNIDADE 1 TÓPICO 1 9
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
IMP
OR
TAN
TE! �
Orientação a Objetos consiste em considerar os sistemas 
computacionais como uma coleção de objetos que interagem 
de maneira organizada (FARINELLI, 2007).
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 
UNIDADE 1TÓPICO 110
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
é 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.
IMP
OR
TAN
TE! �
“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).
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ível perceber 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.
UNIDADE 1 TÓPICO 1 11
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
FIGURA 6 – A ORIENTAÇÃO A OBJETOS ENFATIZA A REPRESENTAÇÃO DE OBJETOS
FONTE: LARMAN (2004, p. 31)
IMP
OR
TAN
TE! �
“Programação Orientada a Objetos consiste em utilizar objetos 
computacionais para implementar a funcionalidade de um 
sistema”. (CORREIA e TAFNER, 2001, p. 8)
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 
UNIDADE 1TÓPICO 112
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
de manutenção.
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.
UNIDADE 1 TÓPICO 1 13
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
resUMO dO tÓPiCO 1
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!
UNIDADE 1TÓPICO 114
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
AUT
OAT
IVID
ADE �
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.
UNIDADE 1 TÓPICO 1 15
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1TÓPICO 116
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
PrOCessO UniFiCAdO (UP)
1 intrOdUÇÃO
tÓPiCO 2
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
UNIDADE 1TÓPICO 218
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 2 19
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1TÓPICO 220
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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).
UNIDADE 1 TÓPICO 2 21
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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 necessi-
dades 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.
UNIDADE 1TÓPICO 222
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 2 23
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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 1TÓPICO 224
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 2 25
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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
“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 
UNIDADE 1TÓPICO 226
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
organizações”. 
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.
UNIDADE 1 TÓPICO 2 27
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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 1TÓPICO 228
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 2 29
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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 1TÓPICO 230
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 2 31
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1TÓPICO 232
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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 
UNIDADE 1 TÓPICO 2 33
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
dos conceitos aplicados às metodologias já existentes.
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.
UNIDADE 1TÓPICO 234
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 2 35
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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 desenvolvimentode 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.
UNIDADE 1TÓPICO 236
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 2 37
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
IMP
OR
TAN
TE! �
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/>. 
UNIDADE 1TÓPICO 238
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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!
UNIDADE 1 TÓPICO 2 39
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
AUT
OAT
IVID
ADE �
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?
UNIDADE 1TÓPICO 240
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
estrUtUrAs e relACiOnAMentOs
1 intrOdUÇÃO
tÓPiCO 3
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, ou quando um método de um objeto é ativado por outro objeto.
UnidAde 1
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).
UNIDADE 1TÓPICO 342
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 3 43
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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ÁTICAFONTE: Disponível em: <http://slideplayer.com.br/slide/298878/>. Acesso em: 26 dez. 2014.
UNIDADE 1TÓPICO 344
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 3 45
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1TÓPICO 346
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1 TÓPICO 3 47
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1TÓPICO 348
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
leitUrA COMPleMentAr
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 forma natural 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;
};
A parte protected: da classe permite:
• Definição de variáveis e métodos por forma a melhorar o acesso à classe base, por 
UNIDADE 1 TÓPICO 3 49
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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 membrosprivate da classe BASE não podem ser acedidos pela classe NATO.
1.2. Herança Múltipla
UNIDADE 1TÓPICO 350
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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
{
public:
int x;
};
UNIDADE 1 TÓPICO 3 51
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1TÓPICO 352
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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:
UNIDADE 1 TÓPICO 3 53
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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.
UNIDADE 1TÓPICO 354
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
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!
UNIDADE 1 TÓPICO 3 55
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
AUT
OAT
IVID
ADE �
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 definição, desenvolva uma figura que 
apresenta estas características:
UNIDADE 1TÓPICO 356
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
UNIDADE 2
UNIFIED MODELING LANGUAGE (UML)
OBJETIvOS DE APRENDIzAGEM
nessa unidade vamos:
	conhecer sobre a introdução à UML, por meio de seu histórico;
 compreender a utilização do Levantamento de Requisitos, 
Prototipação, Prazos e Custos, entre outros;
 conhecer a respeito das fases do desenvolvimento de um sistema 
UML;
 compreender os modelos de elementos por meio das Classes, 
Objetos, Estados, entre outros. 
tÓPiCO 1 – intrOdUÇÃO A UMl
 
tÓPiCO 2 – FAses de desenVOlViMentO de 
UM sisteMA UMl
 
tÓPiCO 3 – MOdelOs de eleMentOs
PLANO DE ESTUDOS
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.
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
A
N
Á
L
I
S
E
O
R
I
E
N
T
A
D
E
A
 
O
B
J
E
T
O
S
I
intrOdUÇÃO A UMl
1 intrOdUÇÃO
tÓPiCO 1
Neste primeiro tópico, você terá acesso às especificidades do desenvolvimento de 
software, respondendo assim a uma pergunta básica: Por que modelar software?
Para responder a esta pergunta, no decorrer do tópico, será apresentado a você