Baixe o app para aproveitar ainda mais
Prévia do material em texto
2017628 Artigo Clube Delphi 58 Análise orientada por objetos http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=12404 1/9 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. 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. R ec eb a no tif ic aç õe s :) 2017628 Artigo Clube Delphi 58 Análise orientada por objetos http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=12404 2/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: R ec eb a no tif ic aç õe s :) 2017628 Artigo Clube Delphi 58 Análise orientada por objetos http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=12404 3/9 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”! R ec eb a no tif ic aç õe s :) 2017628 Artigo Clube Delphi 58 Análise orientada por objetos http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=12404 4/9 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.). R ec eb a no tif ic aç õe s :) 2017628 Artigo Clube Delphi 58 Análise orientada por objetos http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=12404 5/9 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”, sugereque “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? R ec eb a no tif ic aç õe s :) 2017628 Artigo Clube Delphi 58 Análise orientada por objetos http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=12404 6/9 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). R ec eb a no tif ic aç õe s :) 2017628 Artigo Clube Delphi 58 Análise orientada por objetos http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=12404 7/9 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; R ec eb a no tif ic aç õe s :) 2017628 Artigo Clube Delphi 58 Análise orientada por objetos http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=12404 8/9 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? R ec eb a no tif ic aç õe s :) 2017628 Artigo Clube Delphi 58 Análise orientada por objetos http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=12404 9/9 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 trintadias 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 (!) R ec eb a no tif ic aç õe s :)
Compartilhar