Artigo Clube Delphi 58 - Análise Orientada Por Objetos PDF

2017628 Artigo Clube Delphi 58 Análise orientada por objetos
www.devmedia.com.br
[versão para impressão]
Link original: http://www.devmedia.com.br/articles/viewcomp.asp?
comp=12404
Artigo Clube Delphi 58 - Aná

lise orientada por objetos
Artigo da Revista Clube Delphi Edição 58.
Receba notificações :)
Esse artigo faz parte da revista Clube Delphi Edição 58.
Clique aqui para ler todos os artigos desta edição
Análise Orientada por Objetos
O mundo como ele é!
Nas edições 50, 51 e 52 mostrei como o paradigma de programação
orientada por objetos (OOP – ObjectOriented Programming) pode significar
uma melhor organização, planejamento, desenvolvimento e manutenção de
uma aplicação. Porém, programar OO sem um projeto (design) OO pode ser
uma tarefa difícil, levando a uma implementação deficiente, sem os
benefícios de médio e longo prazo esperados da OO.
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=12404 1/9
E para obter um bom design (modelo de objetos) precisamos de um método
de análise adequado, ou seja, orientado por objetos. Sem uma visão de
mundo OO, derivar um projeto para uma boa implementação OO tornase um
enorme desafio, senão inútil. Assim, nas próximas edições, mostrarei os
princípios fundamentais da OOAD (Object Oriented Analysis and Design), que
naturalmente levam a uma boa OOP.
O material apresentado será uma síntese de diversas metodologias, mas há
muito tempo tenho usado preferencialmente a abordagem sugerida pelo Dr.
Peter Coad, a quem tenho muito a agradecer, tanto pela OOAD quanto pela
metodologia ágil conhecida como FDD (Feature Driven Development).
Antes da Análise OO
A visão de mundo orientada por objetos oferece um excelente paradigma
para o entendimento de um determinado contexto ou situação, denominado
domínio do problema. Anteriormente, dois outros enfoques eram muito
comuns: o enfoque funcional e o enfoque de dados.
No enfoque funcional decompõese o domínio do problema de acordo com
suas funções, algoritmos e procedimentos. Os dados recebem um tratamento
secundário, às vezes em forma de repositórios (arquivos), outras vezes
simplesmente figurando entre as operações. Dois diagramas são comumente
usados para modelagem:
 DHF (Diagrama Hierárquico de Funções): mostra como os módulos
estão organizados e conectados, seguindo uma hierarquia
arquitetural e funcional;
 Fluxograma: demonstra de forma gráfica o fluxo de operações de
um determinado algoritmo.
No enfoque de dados há uma enorme preocupação em mostrar o que
acontece com os dados na medida em que esses transitam entre as diversas
“bolhas” de processamento. As funções, quando necessário, são explicitadas
separadamente. Os dois diagramas mais usados são:
 DFD (Diagrama de Fluxo de Dados): mostra as “bolhas” de
processamento, os dutos de dados e os repositórios, normalmente
seguindo um esquema de refinamento, onde as “bolhas” principais
são detalhadas (“explodidas”) em outros diagramas, formando uma
hierarquia de diagramas;
 DER (Diagrama de EntidadeRelacionamento): demonstra a
estrutura das entidades presentes no domínio do problema e os
relacionamentos existentes entre elas. Geralmente é usado para
derivar o script para um banco de dados relacional.
Um pouco de história
É interessante notar que, historicamente, dados e funções sempre foram
considerados separadamente, desde a arquitetura do hardware até muitas
linguagens de programação nãoOO. No hardware, foi o húngaro Johann Louis
von Neumann, por volta de 1945, quem sugeriu que tanto os dados quanto os
programas fossem armazenados na mesma memória. Os computadores que
usamos hoje ainda usam muito da “arquitetura von Neumann” (pronunciase
algo como “fon nóiman”).
No mundo do software, os conceitos OO já começaram a aparecer por volta
de 1959. Alguns anos depois, a linguagem Simula67 apareceu justamente
para facilitar simulações, oferecendo várias características de orientação por
objetos. Smalltalk foi desenvolvida nas décadas de 1970 e 1980 e é
considerada uma das mais puras e completas linguagens OO. C++ apareceu
na década de 1980, e Eiffel, por volta de 1985. Java só apareceu em 1995 e
C#, em 2000.
E o que tudo isso tem a ver com você? Bom, talvez seja surpresa para
muitos, mas em 1989 a Borland lançou o Turbo Pascal 5.5 com Object Pascal,
com extensões para OOP! Um novo tipo de dados chamado object permitia a
definição de um “registro” que possuía, além de variáveis, declarações de
funções e procedimentos. E diferentemente de um record, um object podia
herdar de um outro object! O mundo OO estava aberto para os “pascaleiros”!
Cinco anos e várias melhorias depois, a Borland fez um grande favor ao
mundo e lançou o Delphi 1.0, onde o object virou class (para desfazer um
dilema filosófico)! Agora vivemos a experiência .NET e como de costume, a
Borland salva o dia e lança o Delphi for .NET! A experiência OO será elevada
a um nível ainda maior, suportada por um ambiente de execução totalmente
OO, a CLR (Common Language Runtime), que é a máquina virtual do .NET.
Nesses 15 anos, aprendemos a programar OO, criar componentes, construir
hierarquias e organizar melhor as aplicações. Mas creio que ainda não temos
aplicado a OO onde ela pode ajudar mais (e para a qual foi originalmente
concebida): entender e simular o mundo ao nosso redor!
Afinal, o que é Análise OO?
É um método de análise que examina os requisitos a partir da perspectiva
das classes e objetos encontrados no vocabulário do domínio do problema,
enfatizando a construção de modelos do mundo real usando uma visão de
mundo orientada por objetos.
Construir uma VCL é realmente engenhoso e eu sou muito grato por isso! Mas
e quanto à aplicação, ao domínio do problema? Continuamos a programar nas
decomposições funcionais e / ou orientadas pelos dados...
E como mudar? Como “começar de novo”? Felizmente não é tão difícil quanto
se imagina. É só prestarmos atenção em como as crianças aprendem...
A Teoria da Classificação diz que na compreensão do mundo real costumamos
empregar três métodos:
 Diferenciação, baseada na experiência de cada um (as pessoas e os
outros objetos);
 Distinção entre o todo e suas partes (a pessoa e seus órgãos e
tecidos);
 Formação de, e distinção entre, as diferentes classes de objetos
(classes de pessoas, classes de veículos, etc.).
Assim, muito do que sabemos hoje seguiu essa metodologia. Primeiro vemos
um monte de objetos passando a nossa frente. Daí conseguimos distinguir
determinados grupos, através de suas similaridades e diferenças. Um pouco
adiante começamos a perceber que certas coisas possuem outras coisas
dentro delas (quem nunca desmontou ou quebrou um brinquedo ou um
rádio?). Depois começamos a dar nome aos grupos que montamos,
classificandoos. Adão provavelmente seguiu esse processo em seu primeiro
emprego (leia em Gênesis 2:1920)!
Robert Kiyosaki, autor de “Pai Rico, Pai Pobre”, sugere que “inteligência é a
capacidade de fazer distinções mais refinadas”. Assim, podemos dizer que
uma análise é “melhor” que outra pela forma com que fazem as distinções.
Um analista é mais “inteligente” que outro por causa de sua capacidade de
observação e distinção, que leva a uma melhor especificação.
Boas notícias, certo? Se já fazemos isso instintivamente, será apenas uma
questão de praticar de forma metódica e habitual e teremos dado um passo
significativo para adotar a OOA em nossos projetos!
Conceitos Fundamentais
A orientação por objetos está baseada em conceitos essenciais, que a
distingue de outros paradigmas. E eles não são restritos à programação, mas
estendemse à análise e ao projeto. Entre outros, os principais são:
Abstração: princípio de ignorar os aspectos de um assunto não relevante para
o propósito em questão, tornando possível uma concentração maior nos
assuntos principais. Pense no objeto “pessoa”. Se você estiver criando um
sistema para um hospital, provavelmente irá considerar aspectos tais como
peso, altura e tipo sangüíneo. Mas eles seriam necessários numa vídeo
locadora?
Encapsulamento: princípio de que cada componente do programa deve conter
uma única decisão de projeto, isso é, um agrupamento de aspectos
relacionados a uma idéia ou entidade. Além disso, a interface para cada
módulo é definida de forma a revelar o menos possível sobre seu
funcionamento interno, implementando o ocultamento de informação. Assim,
se for necessário alterar alguma coisa dentro da “cápsula”, o mundo exterior
não precisa (ou pelo menos não deveria precisar) ser alterado por causa
disso. Nosso objeto “pessoa”, por exemplo, agrupa as informações e
comportamentos de um ser humano, enquanto esconde como isso é feito.
Identidade: um objeto distinguese de outro pelo simples fato de existir. Sua
identidade independe dos valores de seus atributos. Podemos ter dois objetos
idênticos (dois gêmeos, por exemplo), mas ainda assim sabemos que são
dois objetos independentes. Ao alocarmos dois objetos na memória do
computador, embora possam ter todos os atributos iguais, seus endereços de
memória são diferentes. Dois registros idênticos em uma tabela diferenciam
se pela sua chave primária única.
Herança: mecanismo para expressar a similaridade entre classes,
simplificando a definição de classes iguais a outras que já foram definidas
(reutilização de código). Representa generalização e especialização, tornando
explícitos os atributos e serviços comuns em uma hierarquia de classes. Um
empregado é uma pessoa. Portanto, se definimos uma classe com os
atributos e serviços típicos de uma pessoa, podemos aproveitar tudo isso
para especificar um empregado, concentrandonos agora apenas no que ele
tem de diferente (normalmente a mais).
Polimorfismo: capacidade de uma mesma mensagem ser entendida e
executada de forma diferente por objetos distintos. Peça a uma pessoa para
“cantar”. Cada tipo de pessoa irá responder ao pedido de forma diferente
(algumas melhores que outras). Polimorfismo é também a possibilidade de
manipular objetos mais especializados como se fossem objetos mais
genéricos. Se você pedir a um empregado, um gerente ou um cantor, para
“cantar”, você não precisa saber a priori que tipo de pessoa ele é, pois
“cantar” está definido na classe Pessoa e mesmo que os indivíduos pertençam
a classes mais especializadas, por herança eles continuam sendo da classe
Pessoa e, portanto, conseguem responder ao pedido para “cantar”. Os
programas de calouros na TV atestam isso de forma irrefutável!
Associação: união ou conexão de idéias. Agrupar certas coisas que acontecem
em algum ponto no tempo ou sob circunstâncias similares. Pessoas associam
se para os mais diversos fins: sociedade comercial, esportes,
relacionamentos, projetos, etc. A definição do tipo de associação busca
espelhar o que acontece na vida real. Pessoas também estão associadas a
coisas (carros, livros), lugares (imóveis, aeroportos), serviços (empréstimos,
exames), etc. Além das associações simples, também podemos ter
composições (carro=motor+rodas) e agregações (um curso é um agregado
de disciplinas).
Mãos à obra?
Então, vamos começar a tão aguardada análise OO! Mas antes temos que
arranjar um problema, um contexto, um domínio de negócios. Que tal a
vídeolocadora citada acima? Não, isso está muito manjado... Controle
acadêmico? Boa tentativa... Um hospitalzinho? Outra hora...
Enquanto não decido, saiba que não importa qual o domínio do problema,
fatalmente encontraremos quatro tipos básicos de objetos em todos eles:
Pessoas, lugares ou coisas: esses são os objetos mais fáceis de observar,
pois são físicos. Mesmo se forem entidades abstratas, pelo próprio estudo do
processo de negócio são rapidamente detectados;
Momentos ou intervalos: são eventos que ocorrem no processo real e que
precisam ser registrados. O evento pode ser instantâneo (uma venda, um
depósito) ou ocorrer durante um intervalo de tempo (uma locação, uma
viagem);
Papéis: geralmente as pessoas, lugares ou coisas participam dos eventos
desempenhando algum tipo de papel específico. Por exemplo, uma pessoa
participa de uma venda como cliente ou vendedor. Um aeroporto pode
desempenhar o papel de destino, origem ou escala de um vôo;
Descrições (tipo catálogo): quando uma coisa ou lugar possui uma descrição
razoavelmente constante, essa descrição pode ficar separada do objeto real e
ser reutilizada por outros objetos. Um carro tem sua placa, cor e número de
chassi, mas sua descrição geral (número de portas, potência, etc.) pode ficar
em um catálogo reutilizável por diversos carros do mesmo modelo.
Só quatro? Claro, é possível que você encontre um ou outro desvio dessa
classificação geral, mas tenha isso como base e vá se acostumando com a
idéia. Isso pode lhe economizar muito tempo na hora de analisar e projetar!
Esses quatro tipos básicos são chamados de arquétipos.
Ah, sim! Nosso domínio de negócio... Bom, nos próximos artigos
desenvolveremos uma análise, projeto e programação de uma aplicação que
nos possibilite controlar a nossa rede de estacionamentos de veículos, a
OOPark. Ela é dona dos melhores pontos da cidade e oferece alguns serviços
adicionais para os clientes, mas precisa de uma boa aplicação que lhe ajude
a melhorar tanto o atendimento aos fregueses quanto a gestão do negócio.
Lição de Casa
Pense e pesquise sobre o assunto. Faça visitas a alguns estacionamentos e
pergunte como funcionam. A tentação é grande, mas tente não criar tabelas
ou formulários, mesmo que mentalmente. Aprenda sobre o processo de
negócio. Afinal, estamos na fase de análise, OK?
Sua tarefa aqui é identificar os objetos participantes do sistema real, suas
características, comportamentos e relacionamentos principais. Não tente
detalhar muito agora. Faremos isso quando estivermos projetando. Com a
lista de objetos em mãos, tente classificálos com relação aos quatro
arquétipos apresentados. Vocês têm trinta dias para terminar. Quem não
fizer a lição de casa ficará de castigo, pois não aprenderá na prática!
Um grande abraço e até a próxima aula! Ops, artigo...
Links
www.pcoad.com
Site pessoal do Dr. Peter Coad
www.jot.fm
Journal of Object Technology. Revista eletrônica sobre a tecnologia de objetos
www.oopsla.org
Site oficial da conferência mundial de OO (ObjectOriented Programming,
Systems, Languages and Applications)
www.featuredrivendevelopment.com
Site oficial da FDD
br.groups.yahoo.com/group/gufdd
Grupo de usuários da FDD em português
por Adail Muniz
Delphi na veia (!)

Artigo Clube Delphi 58 - Análise Orientada Por Objetos PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Artigo Clube Delphi 58 - Análise Orientada Por Objetos PDF

Uploaded by

Copyright:

Available Formats

2017628 Artigo Clube Delphi 58 Análise orientada por objetos