Conceitos Iniciais

Introducao
Gerenciamento da Complexidade do
Software (I)
Sistemas de software sao intrinsicamente complicados
Os requisitos modernos tendem a complica-lo cada vez mais:
Alta conabilidade; alto desempenho; desenvolvimento rapido e
barato
Sao necessarios mecanismos de gerenciamento da complexidade:
Abstra cao; generaliza cao; agrega cao
Gerenciamento da Complexidade do
Software (II)
O software deve passar uma ilusao de simplicidade:
Crise de software X Orientacao a Objetos
Crise de software X Orientacao a Objetos
Crise de Software -1968, Conferencia OTAN na Europa
Problemas com o Desenvolvimento Benecios do Modelo
de Software de Objetos
pouco predizvel, abstra cao de dados,
qualidade baixa dos programas, exibilidade,
custo alto de manuten cao, reutiliza cao,
duplica cao de esfor cos. manuten cao.
Modelo de Objetos
Ideias Basicas
Representa o software atraves de elementos do mundo real
Entidades fsicas (avioes, rob os, etc.)
Entidades abstratas (listas, pilhas, las, etc.)
Unica cao dos conceitos de dados e fun c oes (encapsulamento)
Fundamentos do Modelo de Objetos
Encapsulamento
Modularidade
Abstra cao de dados
Hierarquia de Abstra cao
Encapsulamento (I)
Encapsulamento e o processo de esconder todos os detalhes de um
objeto que nao contribuem para suas caractersticas 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
interfaceGrfica persistncia ncleo

E um mecanismo para organizar elementos hierarqui-
camente em grupos
Um pacote pode agrupar classes, casos de uso, repre-
senta c oes dinamicas, ou outros pacotes
Abstracao de Dados (I)
Uma abstra cao descreve as caractersticas essenciais de um objeto que
o disting ue de todos os outros tipos de objetos, e portanto proporciona
limites conceituais bem denidos, relativo `a perspectiva do observador.
Abstracao de Dados (II)
Hierarquia de Abstracao (I)
Quando um sistema tem muitos detalhes para serem descritos
atraves de uma unica abstra cao, 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 cao de abstra c oes
Duas categorias de hierarquias de abstra c oes importantes:
1. Hierarquia de agrega cao/decomposi cao
2. Hierarquia de generaliza cao/especializa cao
Hierarquia de Abstracao (II)
Orientacao a Objetos
Programa cao Orientada a Objetos (POO) e um modelo de
programa cao baseado em conceitos, tais como, objetos, classes,
encapsulamento, ocultamento da informa cao (information
hiding), heran ca, polimorsmo, etc.
Projeto Orientado a Objetos (Object-Oriented Design) e
um modo de usar esses conceitos para estruturar e construir
sistemas.
Pontos Importantes da Orientacao a Objetos
Obten cao de componentes de software reutilizaveis e exiveis,
O paradigma de Objetos e ortogonal a outros paradigmas de
program cao.
Os conceitos de heran ca e acoplamento dinamico (dynamic
binding) sao especcos do modelo de objetos.
Limitac oes do Passado do Modelo de
Objetos (I)
Foco em programa cao OO
Trabalho em grupo pouco desenvolvido
Metodos tradicionais sao inapropriados
Necessidade de maneiras novas para gerencia
Limitac oes do Passado do Modelo de
Objetos (II)
Trabalho em grupo pouco desenvolvido
Metodos tradicionais sao inapropriados
Necessidade de maneiras novas para gerencia
Baixa granularidade de reutiliza cao (objeto) = Com-
ponentes de Software
Breve Historia de Orientacao a Objetos
1967 Simula 67 (Kristen Nygaard e Ole-Johan Dahl)
1970 Pascal (Niklaus Wirth)
1972 Artigo de Dahl sobre ocultamento da informa cao
1976 Primeira versao de Smalltalk
(Alan Kay, Dan Ingalls e Adele Goldberg)
1983 Primeira versao de C++ (Bjarne Stroustrup)
1988 Primeira versao de Eiel (Bertrand Meyer)
1995 Primeira versao de Java
(Patrick Naughton, Mike Sheridan, e James Gosling)
Paradigma Procedural vs. POO
Procedural POO
tipos de dados classes/TAD
variavel objeto/instancia
fun cao/procedimento opera cao/servi co
chamada de fun cao passagem de mensagem
Paradigma Estruturado vs. POO



Funes
e
Procedimentos

Dados
objeto1 Objeto2
objeto3 objeto4
mensagens
Uma Aplicao Estruturada Uma Aplicao Orientada a Objetos
OPERAES (visveis
externamente)
DADOS (encapsulados
internamente)
Programa Pascal (I)
program P;
const MAX = 100;
type {declarac~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
Variveis
locais
Variveis
locais
Variveis
locais
Variveis
locais
A()
D()
C()
B()
procedimentos interface pblica
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
Classicacao de Wegner
+ Herana
+ Classes
Baseado
em
Classes
Orientado
Objetos
Baseado
em
Objetos
a
Desenvolvimento de Software (I)
Etapas do processo de desenvolvimento de software:
1. especica cao do problema,
2. entendimento dos requisitos,
3. planejamento da solu cao, e
4. implementa cao de um programa numa dada lingua-
gem de programa cao
Desenvolvimento de Software (II)
Uma metodologia de projeto consiste em construir um
modelo do domnio de um problema e entao adicio-
nar detalhes de implementa cao ao modelo durante o
projeto do sistema.
A abordagem orientada a objetos para constru cao de
sistemas permite que um mesmo conjunto de concei-
tos e uma mesma nota cao sejam usados atraves de
todo o ciclo de vida do software: analise, projeto
e implementa cao.
Modelos Tradicionais
No modelo cascata, a fase de projeto usa decom-
posi cao funcional top-down.
Inicialmente, as fun c oes (procedimentos) a serem re-
alizadas pelo sistema sao identicadas.
Essas fun c oes sao divididas em subtarefas, que por sua
vez sao renadas.
Resultado: uma descri cao hierarquica da estrutura do
sistema.
Limitac oes dos Modelos Tradicionais
Limita coes:
o sistema e inexvel, nao pode ser adaptado facil-
mente a mudan cas,
o modelo nao considera o uso de componentes de soft-
wre ja disponveis. Abordagem top-downdiculta a
reutiliza cao de software. Por exemplo, projetistas de
hardware iniciam um projeto examinando um catalogo
de componentes ja projetados (bottom-up),
as diferentes fases nao se integram de forma elegante
e simples. Modelos e nota c oes diferentes sao usados
para especica cao, analise, projeto e implementa cao,
dicultando as transi c oes entre fases.
Modelo Cascata
Documentao
Especificao
de Requisitos
Anlise
Projeto
Codificao
Testes de Unidade
e Integrao
Teste de
Sistema
Operao e
Manuteno
Teste de
Aceitao
Modelo Espiral
Comparacao entre as Processos Tradicionais
vs. Orientados a Objetos
Anlise Projeto
Diagramas de
Entidade-
Relacionamento
Diagramas de
Dependncia
de Processos
Diagramas de
Fluxo de Dados
Decomposio
Funcional
Diagramas de
Estrutura de
Mdulos
Diagramas de
Ao
A tecnologia de objetos usa um modelo unificado
Nas metodologias tradicionais, analistas, projetistas e
programadores tm diferentes modelos conceituais
Programao
COBOL
FORTRAN
C
PASCAL
Anlise OO Projeto OO Programao OO
Modelo do Objeto
Processo Orientado a Objetos (I)
Ideias Chaves:
Baseia-se em objetos e nao em procedimentos
O projetista nao inicia o processo pela identica cao das fun c oes
do sistema, mas sim pela identica cao dos objetos
Processo Orientado a Objetos (II)
Motivacao:
Mudan cas nos requisitos da especica cao tendem a afetar menos
os objetos do que as suas fun c oes, portanto, o software se torna
menos vulneravel.
Os componentes de um sistema orientado a objetos sao mais
facilmente reutilizados pois eles escondem a representa cao de
dados e sua implementa cao.
O projeto orientado a objetos leva a uma melhor integra cao 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 usurios finais.
O cdigo deve ser gerado
to automaticamente quanto
possvel a partir do projeto.
O projeto deve ter a mesma
conceitual.
estrutura bsica que o modelo
Realidade
Modelo OO
da Realidade
OO
Projeto
Cdigo
Unied Modeling Language (UML)

E uma linguagem de nota cao que pode ser utilizada para
representar modelos OO
Sua especica cao iniciou-se em 1994 pela recem criada Rational
Software Corporation
Tornou-se padrao do Object Management Group (OMG) em 1997
Se popularizou ap os a cria cao do Rational Unied Process (RUP),
em 1998
Exemplos de Hierarquias de Abstrac oes no
Modelo OO
Abstra c oes podem formar uma hierarquia
Tres opera c oes mentais sao essenciais:
1. Classicacao/instanciacao para construir uma abstra cao
2. Agregacao/decomposicao para construir uma hierarquia de
agrega cao
3. Generalizacao/especializacao para construir uma hierarquia de
generaliza cao
Classicacao/Instanciacao (I)

OBS.: No contexto de um sistema de controle de bibliotecas
objeto
classe
joao:Usuario
Instanciao
(os objetos depen
dem da classe)
Classificao
maria:Usuario
objeto
<< instance_of >>
.
<< instance_of >> .
Usuario
nome :String
codigo :String
+ verificarCodigo (cod:String ):boolean
Um objeto e instancia de uma unica classe, nunca de 2 ao mesmo
tempo.
Uma classe pode possuir varias instancias (objetos).
Classicacao/Instanciacao (II)
Generalizacao/Especializacao (I)
Implementa o conceito de heran ca de tipos: e-um-tipo-de
Permite que todas as instancias de uma categoria especca
tambem perten cam a instancias de uma categoria mais abrangente
Generalizacao/Especializacao (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
Generalizacao/Especializacao (III)
Agregacao/Decomposicao (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
Agregao Decomposio
Agrega cao e um relacionamento estrutural entre o todo e suas
partes.
Ela implementa o conceito de decomposi cao hierarquica:
e-parte-de

E um mecanismo que permite a montagem do todo a partir de
suas partes
Agregacao/Decomposicao (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 cao e representada como um conjunto de links;
Um link e uma conexao entre dois objetos.
Associacao (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 cao e um relacionamento estrutural que descreve um
conjunto de links;
Agrega cao e um tipo especial de associa cao;
Um usuario pode efetuar varias reservas e uma reserva e feita por
apenas um usuario.
Associacao (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: Domnio Universidade
Considere como domnio 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 catalogo da
universidade. Alunos podem se matricular em turmas de uma
disciplina especca. A p os-gradua c ao pode ter programas de
mestrado academico, mestrado prossional e de doutorado.
Enunciado 2: Domnio Zool ogico
Considere como domnio 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 especcos
para cada tipo de bicho.
Alem disso, o sistema deve possibilitar o cadastro dos animais
existentes no zoo, classicados de acordo com a respectiva classe:
mamfero, reptil ou ave.