Você está na página 1de 54

Conceitos Iniciais

Introdu¸c˜ao
Gerenciamento da Complexidade do
Software (I)
• Sistemas de software s˜ao intrinsicamente complicados
• Os requisitos modernos tendem a complic´a-lo cada vez mais:
– Alta confiabilidade; alto desempenho; desenvolvimento r´apido e
barato
• S˜ao necess´arios mecanismos de gerenciamento da complexidade:
– Abstra¸ c˜ao; generaliza¸ c˜ao; agrega¸ c˜ao
Gerenciamento da Complexidade do
Software (II)
• O software deve passar uma “ilus˜ao” de simplicidade:
Crise de software X Orienta¸c˜ao a Objetos
Crise de software X Orienta¸c˜ao a Objetos
• Crise de Software -1968, Conferˆencia OTAN na Europa
Problemas com o Desenvolvimento Beneficios do Modelo
de Software de Objetos
• pouco prediz´ıvel, • abstra¸ c˜ao de dados,
• qualidade baixa dos programas, • flexibilidade,
• custo alto de manuten¸ c˜ao, • reutiliza¸ c˜ao,
• duplica¸ c˜ao de esfor¸ cos. • manuten¸ c˜ao.
Modelo de Objetos
Id´eias B´asicas
• Representa o software atrav´es de elementos do mundo real
– Entidades f´ısicas (avi˜oes, robˆ os, etc.)
– Entidades abstratas (listas, pilhas, filas, etc.)
• Unifica¸ c˜ao dos conceitos de dados e fun¸ c˜ oes (encapsulamento)
Fundamentos do Modelo de Objetos
• Encapsulamento
• Modularidade
• Abstra¸ c˜ao de dados
• Hierarquia de Abstra¸ c˜ao
Encapsulamento (I)
Encapsulamento ´e o processo de esconder todos os detalhes de um
objeto que n˜ao contribuem para suas caracter´ısticas essenciais.
Encapsulamento (II)
Modularidade (I)
Modularidade ´e a propriedade de um sistema que foi decomposto num
conjunto de m´ odulos altamente coesos e fracamente acoplados
Modularidade (II)
Pacotes

sistema
interfaceGráfica persistência núcleo

´
E um mecanismo para organizar elementos hierarqui-
camente em grupos
• Um pacote pode agrupar classes, casos de uso, repre-
senta¸ c˜ oes dinˆamicas, ou outros pacotes
Abstra¸c˜ao de Dados (I)
Uma abstra¸ c˜ao descreve as caracter´ısticas essenciais de um objeto que
o disting¨ ue de todos os outros tipos de objetos, e portanto proporciona
limites conceituais bem definidos, relativo `a perspectiva do observador.
Abstra¸c˜ao de Dados (II)
Hierarquia de Abstra¸c˜ao (I)
• Quando um sistema tem muitos detalhes para serem descritos
atrav´es de uma ´ unica abstra¸ c˜ao, ele pode ser decomposto numa
hierarquia de abstra¸ c˜ oes
• Uma hierarquia permite que detalhes relevantes sejam
introduzidos de uma maneira controlada
• Hierarquia ´e um “ranking” ou uma ordena¸ c˜ao de abstra¸ c˜ oes
• Duas categorias de hierarquias de abstra¸ c˜ oes importantes:
1. Hierarquia de agrega¸ c˜ao/decomposi¸ c˜ao
2. Hierarquia de generaliza¸ c˜ao/especializa¸ c˜ao
Hierarquia de Abstra¸c˜ao (II)
Orienta¸c˜ao a Objetos
• Programa¸ c˜ao Orientada a Objetos (POO) ´e um modelo de
programa¸ c˜ao baseado em conceitos, tais como, objetos, classes,
encapsulamento, ocultamento da informa¸ c˜ao (“information
hiding”), heran¸ ca, polimorfismo, etc.
• Projeto Orientado a Objetos (“Object-Oriented Design”) ´e
um modo de usar esses conceitos para estruturar e construir
sistemas.
Pontos Importantes da Orienta¸c˜ao a Objetos
• Obten¸ c˜ao de componentes de software reutiliz´aveis e flexiv´eis,
• O paradigma de Objetos ´e ortogonal a outros paradigmas de
program¸ c˜ao.
• Os conceitos de heran¸ ca e acoplamento dinˆamico (“dynamic
binding”) s˜ao espec´ıficos do modelo de objetos.
Limita¸c˜ oes do Passado do Modelo de
Objetos (I)
• Foco em programa¸ c˜ao OO
• Trabalho em grupo pouco desenvolvido
• M´etodos tradicionais s˜ao inapropriados
• Necessidade de maneiras novas para gerˆencia
Limita¸c˜ oes do Passado do Modelo de
Objetos (II)
• Trabalho em grupo pouco desenvolvido
• M´etodos tradicionais s˜ao inapropriados
• Necessidade de maneiras novas para gerˆencia
• Baixa granularidade de reutiliza¸ c˜ao (objeto) =¿ Com-
ponentes de Software
Breve Hist´oria de Orienta¸c˜ao a Objetos
1967 Simula – 67 (Kristen Nygaard e Ole-Johan Dahl)
1970 Pascal (Niklaus Wirth)
1972 Artigo de Dahl sobre ocultamento da informa¸ c˜ao
1976 Primeira vers˜ao de Smalltalk
(Alan Kay, Dan Ingalls e Adele Goldberg)
1983 Primeira vers˜ao de C++ (Bjarne Stroustrup)
1988 Primeira vers˜ao de Eiffel (Bertrand Meyer)
1995 Primeira vers˜ao de Java
(Patrick Naughton, Mike Sheridan, e James Gosling)
Paradigma Procedural vs. POO
Procedural POO
• tipos de dados • classes/TAD
• vari´avel • objeto/instˆancia
• fun¸ c˜ao/procedimento • opera¸ c˜ao/servi¸ co
• chamada de fun¸ c˜ao • passagem de mensagem
Paradigma Estruturado vs. POO



Funções
e
Procedimentos

Dados
objeto1 Objeto2
objeto3 objeto4
mensagens
Uma Aplicação Estruturada Uma Aplicação Orientada a Objetos
OPERAÇÕES (visíveis
externamente)
DADOS (encapsulados
internamente)
Programa Pascal (I)
program P;
const MAX = 100;
type {declara¸c~oes de tipos}
TipoT1 = ...;
TipoT2 = ...;
procedure E(...);
{variaveis locais}
begin
...
end;
procedure C(...);
begin
...
end;
Programa Pascal (II)
procedure B(...);
begin
...
end;
procedure D(...);
begin
...
end;
procedure A(...); begin ... end;
var i, j: integer; {variaveis globais}
begin {corpo principal}
{chamadas para procedimentos}
A();
end.
Programa Pascal (III)

A

B

C

D

E
Programa Estruturado - Paradigma OO
A( )
B( )
C( )
D( )
E( )
i
j
Variáveis
locais
Variáveis
locais
Variáveis
locais
Variáveis
locais
A()
D()
C()
B()
procedimentos interface pública
Paradigma Estruturado Paradigma OO
Objeto 4
(tipo T4)
Objeto 1
(tipo T1)
Objeto 3
(tipo T3)
Objeto 2
(tipo T2)
Ling. Orientadas a Objetos vs. Ling.
Baseadas em Objetos
• Linguagem Baseada em Objetos (“Object-
based Language”): ´e aquela linguagem baseada so-
mente no conceito de objetos. Ex.: Ada 85 e CLU.
• Linguagem Orientada a Objetos: ´e aquela que
proporciona suporte ling¨ uistico para objetos, classes,
e um mecanismo de heran¸ ca. Ex.: C++, Smalltalk,
Modula-3, Self, Actor, Ada93, Java.
POO = Objetos + Classes + Heran¸ ca
Classifica¸c˜ao de Wegner
+ Herança
+ Classes
Baseado
em
Classes
Orientado
Objetos
Baseado
em
Objetos
a
Desenvolvimento de Software (I)
Etapas do processo de desenvolvimento de software:
1. especifica¸ c˜ao do problema,
2. entendimento dos requisitos,
3. planejamento da solu¸ c˜ao, e
4. implementa¸ c˜ao de um programa numa dada lingua-
gem de programa¸ c˜ao
Desenvolvimento de Software (II)
• Uma metodologia de projeto consiste em construir um
modelo do dom´ınio de um problema e ent˜ao adicio-
nar detalhes de implementa¸ c˜ao ao modelo durante o
projeto do sistema.
• A abordagem orientada a objetos para constru¸ c˜ao de
sistemas permite que um mesmo conjunto de concei-
tos e uma mesma nota¸ c˜ao sejam usados atrav´es de
todo o ciclo de vida do software: an´alise, projeto
e implementa¸ c˜ao.
Modelos Tradicionais
• No modelo cascata, a fase de projeto usa decom-
posi¸ c˜ao funcional “top-down”.
• Inicialmente, as fun¸ c˜ oes (procedimentos) a serem re-
alizadas pelo sistema s˜ao identificadas.
• Essas fun¸ c˜ oes s˜ao divididas em subtarefas, que por sua
vez s˜ao refinadas.
• Resultado: uma descri¸ c˜ao hier´arquica da estrutura do
sistema.
Limita¸c˜ oes dos Modelos Tradicionais
Limita¸ c˜oes:
• o sistema ´e inflex´ıvel, n˜ao pode ser adaptado facil-
mente a mudan¸ cas,
• o modelo n˜ao considera o uso de componentes de soft-
wre j´a dispon´ıveis. Abordagem “top-down”dificulta a
reutiliza¸ c˜ao de software. Por exemplo, projetistas de
hardware iniciam um projeto examinando um cat´alogo
de componentes j´a projetados (“bottom-up”),
• as diferentes fases n˜ao se integram de forma elegante
e simples. Modelos e nota¸ c˜ oes diferentes s˜ao usados
para especifica¸ c˜ao, analise, projeto e implementa¸ c˜ao,
dificultando as transi¸ c˜ oes entre fases.
Modelo Cascata
Documentação
Especificação
de Requisitos
Análise
Projeto
Codificação
Testes de Unidade
e Integração
Teste de
Sistema
Operação e
Manutenção
Teste de
Aceitação
Modelo Espiral
Compara¸c˜ao entre as Processos Tradicionais
vs. Orientados a Objetos
Análise Projeto
Diagramas de
Entidade-
Relacionamento
Diagramas de
Dependência
de Processos
Diagramas de
Fluxo de Dados
Decomposição
Funcional
Diagramas de
Estrutura de
Módulos
Diagramas de
Ação
A tecnologia de objetos usa um modelo unificado
Nas metodologias tradicionais, analistas, projetistas e
programadores têm diferentes modelos conceituais
Programação
COBOL
FORTRAN
C
PASCAL
Análise OO Projeto OO Programação OO
Modelo do Objeto
Processo Orientado a Objetos (I)
Id´eias Chaves:
• Baseia-se em objetos e n˜ao em procedimentos
• O projetista n˜ao inicia o processo pela identifica¸ c˜ao das fun¸ c˜ oes
do sistema, mas sim pela identifica¸ c˜ao dos objetos
Processo Orientado a Objetos (II)
Motiva¸c˜ao:
• Mudan¸ cas nos requisitos da especifica¸ c˜ao tendem a afetar menos
os objetos do que as suas fun¸ c˜ oes, portanto, o software se torna
menos vulner´avel.
• Os componentes de um sistema orientado a objetos s˜ao mais
facilmente reutilizados pois eles escondem a representa¸ c˜ao de
dados e sua implementa¸ c˜ao.
• O projeto orientado a objetos leva a uma melhor integra¸ c˜ao das
diferentes fases, porque cada uma das fases lida com o mesmo
tipo de entidades: os objetos.
Modelagem da Realidade
O modelo deve refletir a realidade
de uma maneira significativa para
os usuários finais.
O código deve ser gerado
tão automaticamente quanto
possível a partir do projeto.
O projeto deve ter a mesma
conceitual.
estrutura básica que o modelo
Realidade
Modelo OO
da Realidade
OO
Projeto
Código
Unified Modeling Language (UML)

´
E uma linguagem de nota¸ c˜ao que pode ser utilizada para
representar modelos OO
• Sua especifica¸ c˜ao iniciou-se em 1994 pela rec´em criada Rational
Software Corporation
• Tornou-se padr˜ao do Object Management Group (OMG) em 1997
• Se popularizou ap´ os a cria¸ c˜ao do Rational Unified Process (RUP),
em 1998
Exemplos de Hierarquias de Abstra¸c˜ oes no
Modelo OO
• Abstra¸ c˜ oes podem formar uma hierarquia
• Trˆes opera¸ c˜ oes mentais s˜ao essenciais:
1. Classifica¸c˜ao/instancia¸c˜ao para construir uma abstra¸ c˜ao
2. Agrega¸c˜ao/decomposi¸c˜ao para construir uma hierarquia de
agrega¸ c˜ao
3. Generaliza¸c˜ao/especializa¸c˜ao para construir uma hierarquia de
generaliza¸ c˜ao
Classifica¸c˜ao/Instancia¸c˜ao (I)

OBS.: No contexto de um sistema de controle de bibliotecas
objeto
classe
joao:Usuario
Instanciação
(os objetos depen−
dem da classe)
Classificação
maria:Usuario
objeto
<< instance_of >>
.
<< instance_of >> .
Usuario
−nome :String
−codigo :String
+ verificarCodigo (cod:String ):boolean
• Um objeto ´e instˆancia de uma ´ unica classe, nunca de 2 ao mesmo
tempo.
• Uma classe pode possuir v´arias instˆancias (objetos).
Classifica¸c˜ao/Instancia¸c˜ao (II)
Generaliza¸c˜ao/Especializa¸c˜ao (I)
• Implementa o conceito de heran¸ ca de tipos: ´e-um-tipo-de
• Permite que todas as instˆancias de uma categoria espec´ıfica
tamb´em perten¸ cam a instˆancias de uma categoria mais abrangente
Generaliza¸c˜ao/Especializa¸c˜ao (II)
• Diagrama de Objetos:
marcos:Aluno
−nome = "Marcos" :String
−codigo = "ra147" :String
−anoEscolar = 2 :int
+ verificarCodigo (cod:String ):boolean
+ suspender ():void
jose:Usuario
−nome = "José" :String
−codigo = "ra123" :String
+ verificarCodigo (cod:String ):boolean
carlos:Professor
−nome = "Carlos" :String
−codigo = "rf258" :String
−tempoServico = 20 :int
+ verificarCodigo (cod:String ):boolean
+ aposentar ():void
Generaliza¸c˜ao/Especializa¸c˜ao (III)
Agrega¸c˜ao/Decomposi¸c˜ao (I)

Usuario
−nome :String
−codigo :String
+ verificarCodigo (cod:String ):boolean
Publicacao
−numeroTombo :String
−nome :String
+ reservar ():void
Biblioteca
−identificador :String
−endereco :String
+ listarPublicacoes ():void
+ listarUsuarios ():void
Agregação Decomposição
• Agrega¸ c˜ao ´e um relacionamento estrutural entre o todo e suas
partes.
• Ela implementa o conceito de decomposi¸ c˜ao hier´arquica:
´e-parte-de

´
E um mecanismo que permite a montagem do todo a partir de
suas partes
Agrega¸c˜ao/Decomposi¸c˜ao (II)
• Diagrama de Objetos:
dp:Publicacao
−numeroTombo = "M14T" :String
−nome = "Design Patterns" :String
+ reservar ():void
bc:Biblioteca
−identificador = "BC" :String
−endereco = "Rua Jacarandá" :String
+ listarPublicacoes ():void
+ listarUsuarios ():void
jose:Usuario
−nome = "José" :String
−codigo = "ra123" :String
+ verificarCodigo (cod:String ):boolean
cj:Publicacao
−numeroTombo = "S14G" :String
−nome = "Core Java" :String
+ reservar ():void
maria:Usuario
−nome = "Maria" :String
−codigo = "ra321" :String
+ verificarCodigo (cod:String ):boolean
link
• A agrega¸ c˜ao ´e representada como um conjunto de “links”;
• Um “link” ´e uma conex˜ao entre dois objetos.
Associa¸c˜ao (I)
Reserva
−codigo :String
−dataInicio :Date
−dataFim :Date
+ cancelar ():void
+ efetuar ():void
* efetua
1
Usuario
−nome :String
−codigo :String
+ verificarCodigo (cod:String ):boolean
• Uma associa¸ c˜ao ´e um relacionamento estrutural que descreve um
conjunto de “links”;
• Agrega¸ c˜ao ´e um tipo especial de associa¸ c˜ao;
• Um usu´ario pode efetuar v´arias reservas e uma reserva ´e feita por
apenas um usu´ario.
Associa¸c˜ao (II)
• Diagrama de Objetos:
r1:Reserva
−codigo = "R125A07" :String
−dataInicio = 16/03/2007 :Date
−dataFim = 30/03/2007 :Date
+ cancelar ():void
+ efetuar ():void
r2:Reserva
−codigo = "R098A07" :String
−dataInicio = 06/01/2007 :Date
−dataFim = 24/03/2007 :Date
+ cancelar ():void
+ efetuar ():void
jose:Usuario
−nome = "José" :String
−codigo = "ra123" :String
+ verificarCodigo (cod:String ):boolean
maria:Usuario
−nome = "Maria" :String
−codigo = "ra321" :String
+ verificarCodigo (cod:String ):boolean
r3:Reserva
−codigo = "R198A07" :String
−dataInicio = 20/03/2007 :Date
−dataFim = 10/04/2007 :Date
+ cancelar ():void
+ efetuar ():void
Exemplos de Modelagem Orientada a
Objetos
Enunciado 1: Dom´ınio Universidade
Considere como dom´ınio do problema uma universidade como a
UNICAMP, onde existem diversas unidades, que podem ser
institutos, faculdades e n´ ucleos. Unidades s˜ ao subdivididas em
departamentos. Uma universidade tem um quadro de pessoal
permanente composto por funcin´ arios, que podem ser professores,
secret´ arios, analistas, copeiras, etc...
Nos cursos oferecidos pela universidade ingressam alunos de
gradua¸ c˜ ao, p´ os-gradua¸ c˜ ao e de extens˜ ao universit´ aria. Cursos s˜ ao
compostos por disciplinas de acordo com o cat´alogo da
universidade. Alunos podem se matricular em turmas de uma
disciplina espec´ıfica. A p´ os-gradua¸ c˜ ao pode ter programas de
mestrado acadˆemico, mestrado profissional e de doutorado.
Enunciado 2: Dom´ınio Zool´ ogico
Considere como dom´ınio do problema um zool´ ogico onde existem
diversos tipos de animais com uma estrutura administrativa, como
por exemplo, diretor, tratadores, veterin´ arios, etc... A
administra¸ c˜ ao do zoo envolve o preparo de card´ apios espec´ıficos
para cada tipo de bicho.
Al´em disso, o sistema deve possibilitar o cadastro dos animais
existentes no zoo, classificados de acordo com a respectiva classe:
mam´ıfero, r´eptil ou ave.