Baixado 11 vezes
Carregado porelliando dias
Naked Objects
O documento discute o framework Naked Objects, que facilita a construção de aplicações orientadas a objetos a partir de objetos comportamentalmente completos. O framework fornece mecanismos de visualização e persistência que refletem automaticamente o modelo de objetos, poupando esforços do desenvolvedor. A abordagem promove sistemas verdadeiramente orientados a objetos e mais flexíveis às mudanças de requisitos.
Naked Objects
- 1. Naked Objects RichardPawson e Robert Mathews Apresentação : Marcos E. B. Broinizi Orientador : João E. Ferreira
- 2. “ Behavioural completeness” As pessoas acham que estão usando a OO para projetar e desenvolver sistemas; mas não estão. Elas ignoram um princípio fundamental da OO, “ behavioural completeness ”: um objeto deve modelar, por completo, o comportamento daquilo que ele representa. “ Behavioural completeness ” é essencial porque é a chave para obter um dos principais benefícios da orientação a objetos: a habilidade de lidar com as mudanças inesperadas nos requisitos.
- 3. Encapsulamento: significado Oprimeiro tem a ver com existência fechada, como uma cápsula medicinal. Este é o significado que muitas pessoas usam no contexto de orientação a objetos: um objeto é fechado por uma interface de mensagem, com uma implementação interna escondida. O segundo significado de encapsulamento é que alguma coisa exemplifica as características essenciais de outra coisa, como em ‘este documento encapsula nossa estratégia de marketing’.
- 4. Separação dos Dadose Processos As pessoas projetam sistemas que separam o processo de seus dados, embora revestidos com linguagens e tecnologias OO. A separação dos processos de seus dados pode estar relacionada principalmente a inércia: Isto é, as pessoas aprenderam a projetar sistemas dessa forma e têm dificuldades de pensar de outra maneira. Objeto Dado Objeto Processo Objeto
- 5. Separação dos Dadose Processos A inércia individual é reforçada por práticas organizacionais consagradas que forçam a separação dos processos de seus dados, mesmo que o projetista de software queira adotar uma abordagem mais pura de OO: Orientação a processos de negócio. Interfaces de usuário otimizadas a tarefas. Métodos orientados a use-cases. O padrão Model-View-Controller. Desenvolvimento de software baseado em componentes. Essas cinco forças são consideradas melhores práticas da OO. Não se pode simplesmente descartá-las, pois: São práticas conscientes que claramente geram benefícios. Foram projetados para reduzir riscos conhecidos no processo de desenvolvimento. Porém, essas práticas provocam um efeito colateral: desencorajam o projeto de objetos comportamentalmente completos.
- 6. Orientação a processosde negócio A orientação a processos envolve duas idéias: A primeira é a de focar, organizar e alcançar os resultados definidos externamente (tais como preencher um pedido) ao invés de atividades puramente definidas internamente. Isto é uma contribuição útil. A segunda idéia é a de que processos podem e devem ser reduzidos a um processo determinista que transforma entradas em saídas. O problema dessa abordagem é que muitas coisas que o negócio faz, simplesmente não se encaixam no modelo de processos : existem várias atividades onde não se pode identificar entradas e saídas discretas, muito menos os passos seqüenciais.
- 7. Orientação a processosde negócio Stabell e Fjeldstadt argumentam que existem três modelos fundamentais de criação de valores de negócio: a Cadeia de Valor (esquerda), a Loja de Valor (centro) e a Rede de Valor (direita). O modelo da loja de valor, em que recursos são organizados para resolver problemas individuais e que representa uma proporção crescente do negócio, normalmente sofrem pelo apoio pobre de TI.
- 8. Interfaces de usuáriootimizadas a tarefas Muitas interfaces de usuário são projetadas para implementar um conjunto finito de tarefas programadas. Isso está implícito no método de projeto de interfaces, como também fica explícito no projeto resultante: um menu de tarefas, o qual permite ao usuário escolher a tarefa desejada selecionando as sub-opções. O estilo de interface de usuário é conveniente para desenvolvedores de sistemas, pois é fácil de realizar o mapeamento para um conjunto de transações definidas, as quais uma após a outra manipulam suas estruturas de dados.
- 9. The Incredible MachineÉ apresentado ao usuário um problema a ser resolvido – neste caso um balão de prata que tem que ser estourado usando algumas das peças disponíveis (objetos), sendo que cada um pode ser inspecionado para revelar suas propriedades físicas e seus comportamentos
- 10. Métodos orientados aUse-Cases O conceito de use-case foi definido por Ivar Jacobson (1995) como ‘uma seqüência de transações num sistema cuja tarefa produz um valor mensurável para um particular ator do sistema’. Na abordagem de desenvolvimento de sistemas orientado a use-case, os use-cases que capturam os requisitos de um sistema são descritos e, então, procura-se identificar objetos comuns entre eles. Os métodos orientados a objetos mais populares são orientados a use-cases.
- 11. Métodos orientados aUse-Cases O caso contra use-cases foi bem resumido por Don Firesmith (1996): Use cases não são orientados a objetos. Cada use case captura uma grande abstração funcional que pode causar inúmeros problemas associados à decomposição funcional que a tecnologia de objetos supostamente deveria evitar. Uma vez que os use cases são criados antes que os objetos e classes tenham sido identificados, use cases ignoram o encapsulamento de atributos e operações em objetos.
- 12. Métodos orientados aUse-Cases Os autores sugerem que use-cases são muito poderosos quando: São descritos em termos de operações sobre objetos que já tenham sido identificados e especificados, e são usados para testar esse modelo de objetos. Por outro lado, use-cases são muito perigosos quando: São descritos antes do modelo de objetos e usados para identificar objetos e suas responsabilidades compartilhadas – que é precisamente o que a abordagem orientada a use-cases defende.
- 13. O padrão Model-View-ControllerUm padrão arquitetural comum que explicitamente separa três papéis: os objetos de negócio fundamentais que correspondem às entidades de negócio, Modelo , objetos que fornecem a visão do modelo ao usuário, Visão, e objetos que controlam a interação entre o usuário e o modelo, Controlador . O resultado final é que o conhecimento específico de negócio é espalhado através dos domínios do Modelo, Visão e Controlador.
- 14. Desenvolvimento de sistemasbaseados em componentes O desenvolvimento baseado em componentes está principalmente interessado em fornecer uma abordagem plug-and-play para o desenvolvimento de sistemas. A modelagem orientada a objetos não deveria estar preocupada com o plug-and-play . Ela deveria estar preocupada em adequar a estrutura do software à estrutura do domínio de negócio do mundo real, seja ocasionalmente em resposta às mudanças nos requisitos de negócio, ou dinamicamente em resposta a um problema específico.
- 15. Desenvolvimento de sistemasbaseados em componentes Mas a redução da granularidade dos componentes de negócio não tem no final aparência de objetos – ao menos no sentido de entidades instanciáveis comportamentalmente completas – mas a aparência de sub-rotinas – blocos de código que podem transformar uma entrada numa saída. A visão dos autores é que é melhor deixar esses dois conceitos separados: Aplique o conceito de montagem de componentes na sua infra-estrutura técnica e continue com a modelagem pura de objetos na camada de negócio.
- 16.
- 17. Orientação a processosde negócio Ao invés de apenas imaginar o papel dos sistemas de negócio como um meio de executar um processo determinístico, que transforma informações de entrada para informações de saída através de uma seqüência de passos que adicionam valor, precisamos encontrar metáforas alternativas. Uma dessas metáforas é a da loja de valores, onde o usuário constrói uma solução para um problema específico. (é muito fácil adicionar roteiros/ scripts otimizados para um modelo de cadeia de valores).
- 18. Interfaces de usuáriootimizadas a tarefas Ao invés de perseguir a eficiência ótima na execução de cada um dos conjuntos finitos de tarefas roteirizadas, projete uma forma de interação com o usuário que maximize a efetividade geral do usuário em satisfazer sua gama de responsabilidades. Isso significa dar aos usuários maior controle, por exemplo na ordem em que as capacidades são chamadas a fim de alcançar uma meta. Devemos também projetar sistemas que permitam aos usuários tornarem-se mais experientes conforme eles aprendem, ao invés de restringir todos para o menor denominador comum.
- 19. Métodos orientados ause-cases Ao invés de capturar os requisitos de um sistema como um conjunto de use-cases e então usá-los para identificar os objetos compartilhados e suas responsabilidades, procure identificar os objetos e suas responsabilidades diretamente, em conversas com usuários ou outras formas. Precisamos de algum meio de capturar o modelo de objetos emergente de maneira que os usuários possam, de forma concreta, se identificar com esse meio e obter benefícios.
- 20. Model-View-Controller Como nocaso de outras forças, qualquer solução alternativa deve evitar cair no problema para o qual o MVC foi projetado para evitar: Ela deve facilitar a portabilidade de uma aplicação entre múltiplas plataformas técnicas, até entre múltiplos estilos de interação, sem necessitar que o modelo de negócio seja editado. Ao mesmo tempo, ela deve acomodar a necessidade de representar múltiplas visões do modelo sob a mesma plataforma, onde genuinamente exista tal necessidade. Forneça um mecanismo genérico de visualização, incorporando os papéis dos objetos de Visão e Controlador . Tudo que o desenvolvedor precisa é escrever os objetos do Modelo de Negócio.
- 21. Desenvolvimento de softwarebaseado em componentes Ao invés de permitir que a arquitetura de nossos sistemas seja dominada pelas idéias de poder comprar peça por peça da arquitetura de diferentes fornecedores, reconheça que a verdadeira vida do sistema precisa do modelo de objetos de negócio homogêneo que não pode ser comprado, tem que ser projetado internamente para refletir as verdadeiras necessidades de negócio
- 22. Práticas conceituadas noprojeto de sistemas de negócio contemporâneos dividem uma aplicação em quatro camadas principais Apresentação Aplicação, Processo ou Controlador de Use-Case Modelo de objetos de domínio Persistência
- 23. Apresentação Aplicação, Processoou Controlador de Use-Case Modelo de objetos de domínio Persistência O Padrão Naked Objects elimina a camada controlador encapsulando todas as funcionalidades de negócio nos objetos entidade
- 24. E tem umacamada de apresentação genérica que automaticamente reflete o modelo de objetos de domínio como uma interface de usuário orientada a objetos Apresentação Aplicação, Processo ou Controlador de Use-Case Modelo de objetos de domínio Persistência
- 25. Para um sistemastandalone, ou para prototipação, é também possível autogerar a persistência a partir do mesmo modelo de domínio Presentation Aplicação, Processo ou Controlador de Use-Case Modelo de objetos de domínio Persistência
- 26.
- 27. Framework NakedObjects O framework Naked Objects é uma pacote de software open-source, escrito em Java, que facilita a construção completa de aplicações de negócio a partir de naked objects (objetos comportamentalmente completos). Um ambiente de execução , que inclui : Um mecanismo de visualização que cria, em tempo real, uma representação manipulável pelo usuário de qualquer naked object que o usuário precisar acessar. Um mecanismo de persistência , o qual torna o naked objects persistente via uma classe de persistência específica. O framework já vem com uma classe de persistência que armazena cada naked object como um arquivo XML. Isso é bom para realizar a prototipação rápida, mas não é escalável. Classes de persistência mais sofisticadas devem ser escritas em sistemas reais.
- 28. Framework NakedObjects O programador não precisa se preocupar diretamente com os mecanismos de visualização ou de persistência. Um conjunto de frameworks de teste. O framework de testes unitários é uma simples extensão do popular framework JUnit , tratando as capacidades específicas dos naked objects. Existe um framework separado para testes de aceitação, o qual facilita a confecção dos testes de aceitação antes de escrever as funcionalidades (como defende a Extreme Programming ). Como a maioria desses cenários de teste representam tarefas comuns executadas pelos usuários, este framework tem a vantagem adicional de poder gerar a documentação do usuário dessas tarefas diretamente a partir da definição dos testes.
- 29. Exemplo Vamos suporque temos a missão de construir uma aplicação que gerencie os papéis existentes em um projeto (Encanador, Pedreiro, Ajudante, etc.), bem como os empregados que exercem esses papéis. O diagrama de classes em UML é apresentado ao lado: Objetos da classe Projeto referenciam objetos da classe Papel Objetos da classe Papel referenciam objetos da classe Empregado
- 30. A abordagem atravésde objetos comportamentalmente completos Construir sistemas de negócio consiste apenas de definir os objetos do domínio específico. Todas as ações de usuários consistem em criar ou recuperar objetos, especificando seus atributos, estabelecendo associações entre eles, ou invocando métodos em um objeto(ou coleção) – em outras palavras através de uma interface com o usuário realmente orientada a objetos. Associado ao framework encoraja o desenvolvimento de sistemas de negócio realmente orientados a objetos. Fazendo isso de uma maneira negativa, tornando muito difícil para o desenvolvedor separar os dados dos procedimentos; e de uma maneira positiva, tornando a idéia de objetos comportamentalmente completos concreta e rápida para desenvolver sistemas.
- 31. Benefícios Aumento naprodutividade de desenvolvimento, não é necessário escrever a interface com o usuário. Aumento na produtividade para manter e evoluir o sistema. Os sistemas se tornam mais ágeis sendo capazes de melhor acomodar futuras alterações nos requisitos de negócio. Facilita a identificação dos requisitos de negócio uma vez que os naked objects podem constituir uma linguagem comum entre desenvolvedores e usuários.
- 32. Questões levantadas Consegue-seidentificar a essência dos objetos de negócio? Os protótipos assim criados estão muito distantes dos objetos finais do sistema? Seria possível criar simultaneamente um protótipo de qualidade da base de dados? As idéias de Naked Objects podem gerar um método para desenvolvimento de software?
- 33. Referências www.nakedobjects.org http://www.theserverside.com/articles/article.tss?l=NakedObjectSeries_1 http://malariadb.ime.usp.br/labd/
Notas do Editor
- #3 - A noção de BC retoma as origens de OO com Simula, cujos inventores trouxeram a idéia de construir sistemas a partir de objetos, cada um representando algum elemento do domínio a ser simulado.Uma simulação envolvia diversas classes de objetos, que representavam “templates” a partir dos quais eram criadas instâncias individuais de acordo com a necessidade da simulação. Esse princípio foi resgatado pelos autores sobre o nome de BC. Cada objeto do sistema não só conhece as propriedades da entidade que representa mas também como modelar o comportamento dessa entidade. Isso não significa que cada objeto deve implementar todo comportamento possível que possa ser necessário em algum momento. Isso significa que todos os comportamentos necessários associados a algum objeto que são necessários para a aplicação sendo desenvolvida devem pertencer a esse objeto e não ser implementadas em algum outro lugar do sistema. Alguns acreditam que essa é apenas uma utopia. Alguns argumentam que a separação de dados e processos em algum nível é necessária e desejada. Outros argumentam que não importa como considerar dados e processos. Riel em OO Design Heuristics identifica algumas heuristicas valorizadas de design OO. Manter dados e comportamentos relacionados em um único lugar. Classes de nível mais alto devem distribuir o trabalho uniformemente. Não criar classes ou objetos “divinas”. Cuidado com classes cujos nomes contenham Controlador, Gerenciador, Sistema ou Subsistema no nome.
- #4 O Pequeno Dicionário Oxford revela os dois significados da palavra ‘encapsulamento’. No contexto de orientação a objetos, muitas pessoas assumem o primeiro significado, mas o segundo significado é a mais importante.
- #8 - Na cadeia de valor , o produto é o meio de transferência de valor entre a empresa e seus consumidores. - A idéia de Cadeia de Valor tem sido desafiada por Charles Stabell e Oystein Fjeldstadt que dizem que a cadeia de valor é atualmente um modelo de negócio muito pobre, e seu uso pode conduzir a falhas perigosas no nível estratégico. - Eles também argumentam que a proporção do negócio compatível com o modelo de cadeia está decaindo rapidamente. Eles afirmam que o conceito de cadeia de valor é melhor aplicado para a análise de setores industriais que produzem bens manufaturados e homogêneos. Loja de valor (tal como consultorias, construtores e principalmente organizações de saúde) cria valor aplicando recursos para resolver problemas individuais . Suas atividades raramente seguem uma seqüência linear e são freqüentemente iterativos por natureza. -A distinção principal em relação ao conceito de cadeia de valor é que as empresas que prestam serviços tendem a trabalhar em tempo real para entregar aos seus clientes novas soluções ao invés de definirem uma solução e a reproduzem continuamente. -Essas empresas selecionam, combinam e ordenam a aplicação dos seus recursos e de suas atividades de acordo com os requisitos do problema. - Rede de valor (que inclui muitas companhias de telecomunicações, bancos e seguradoras) cria valor pela venda de clientes a outros clientes. A rede de valor é a configuração de valor baseada na reunião de diversos compradores e vendedores independentes, por uma empresa que atua como intermediária, através das tecnologias de mediação.
- #9 -Uma idéia por trás desta abordagem é a de que as ações programadas é a chave para a otimização. -Isso pode ser rastreada diretamente recordando Frederick Taylor (1911) e seus princípios de gerenciamento científico. -A solução foi remover todos os direitos de decisões dos trabalhadores criando roteiros de todas as suas ações. -Muitos sistemas de negócio tratam o usuário como um mero seguidor de roteiros. -O sistema controla todo o processo, subcontratando o usuário somente para aquelas subtarefas que ele não está capacitado a realizar autonomamente. -A alternativa é projetar sistemas que tratem os usuários como solucionadores de problemas. -Muitos negócios já possuem alguns sistemas que são, por natureza, problemas a serem resolvidos. -Todos os programas de desenho, do PowerPoint aos sistemas CAD/CAE, são desse tipo, assim como as planilhas eletrônicas. - No entanto, na maioria dos negócios, esses sistemas não são considerados ‘tradicionais’. - Os sistemas tradicionais estão normalmente preocupados com o processamento padronizado das transações de negócio, e são otimizados para um conjunto de tarefas, os quais são quase sempre implementados como processos seqüenciais.
- #10 -Muitas pessoas acham que sistemas de problemas a serem resolvidos e sistemas transacionais refletem duas necessidades muito diferentes dentro do negócio, que não existe necessidade de uni-los, e que fazer tal coisa só iria tirar a otimização do processamento das tarefas padrão que representam a maior parte das atividades de negócio. -Pawson sugere que existe uma necessidade muito real de trazer as duas idéias próximas uma da outra: em outras palavras, a de tornar os sistemas transacionais tradicionais tão ‘expressivos’ quanto um programa de desenho. Colocar estas duas idéias juntas não significa apenas colocar interfaces de usuários gráficas em sistemas transacionais tradicionais. -Um outro preconceito é que introduzir mais expressividade num sistema transacional tradicional irá reduzir sua eficiência. -Isso pode ser verdade num contexto reduzido de tarefas padrões específicas, mas no sentido amplo a eficiência pode, na verdade, aumentar. Todos podem relatar suas frustrações quando se relacionou com um representante de serviços ao cliente, talvez num call center , onde toda as interações são ou definidas ou restritas pelo roteiro do sistema de computador -Assim, a proporção crescente de chamadas ou visitas a um centro de serviços ao cliente está relacionada: -Ou aos problemas não “padrão”, -ou às pessoas que simplesmente não desejam trabalhar confinadas a uma abordagem limitada. -Mesmo assim, infelizmente os sistemas de call center continuam se esforçando para aparar segundos na duração média de chamadas tentando ‘otimizar os roteiros’.
- #14 -O argumento do MVC é que os objetos de negócio fundamentais de uma classe de objetos de negócio fundamental, podem ser visualizados de várias maneiras diferentes: -sobre diferentes plataformas, -em diferentes contextos -e usando diferentes representações visuais. -O conhecimento combinado de todas essas visões diferentes, bem como o conhecimento de como afetá-los dentro de objetos de negócio faz com que os objetos fiquem inchados e pesados devido à duplicação de funcionalidades nesses objetos. -Usando MVC, os objetos do Modelo não têm conhecimento dessas diferentes visões. -Objetos de Visão dedicados especificam o que aparece em cada visão, e de que forma, e têm o know-how de criar a apresentação visual. -Objetos Controladores fornecem a cola entre os dois: -povoando as visões com atributos a partir dos objetos de entidade de negócio, e chamando métodos desses objetos em resposta a eventos do usuário. - Esse pensamento é legítimo, mas tem alguns efeitos colaterais negativos. -Embora não tenha sido a intenção original da abordagem MVC, os objetos Controladores tendem a ser uma representação explícita das tarefas de negócio – especialmente se a abordagem de projeto for orientada a use-case, mas isso ocorre também em outros casos. -Os objetos Controladores deixam de exercer o papel limitado de ser apenas uma ‘cola’ técnica entre interfaces de usuários e objetos de negócio, e passam a assumir o papel de roteiro de tarefas, incorporando não apenas a seqüência de atividades otimizadas, como também regras de negócio – com isso usurpando as responsabilidades que deveriam ser dos objetos de negócio fundamentais.
- #16 -Pode-se argumentar que uma das razões que levou várias organizações para o lado de componentes no debate ‘objetos versus componentes’ é que elas desenvolveram um medo quase patológico de fazer seus próprios projetos e desenvolvimentos. -Elas foram atormentadas pela lembrança da paralisia de análise, desenvolvimento interminável e de sistemas finalmente liberados cujas especificações falharam ao atender as necessidades reais de negócio. -Nós esperamos demonstrar que isso não tem que ser assim. -O desenvolvimento de seus próprios modelos de objetos de negócio não precisa ser uma experiência tão dolorosa.
- #21 Isso significa escrever um mecanismo de visualização para cada plataforma de cliente solicitada (por exemplo: Windows, Linux, browser web ou Palm Pilot). -O mecanismo de visualização genérica é obtida automaticamente, a partir dos objetos do Modelo de negócio contendo comportamentos disponíveis. -Os objetos do Modelo e suas associações podem ser apresentados, por exemplo, como ícones com métodos ou comportamentos disponibilizados em opções sobre um menu pop-up. -Essa abordagem não viola a essência do MVC, mas é uma re-interpretação radical de como aplicá-la: -Uma maneira de enxergar isso é que ela gera os objetos de Visão e Controlador considerando o Modelo. -A idéia de auto-gerar a interface do usuário a partir do modelo subjacente não é nova. -O conceito existia em muitas linguagens proprietárias de quarta geração e nos geradores de aplicações, e re-emergiu em várias iniciativas baseadas em XML tais como o Xforms da W3C. -No entanto, poucas dessas abordagens são orientadas a objetos: -A interface do usuário é normalmente uma representação explícita da estrutura de dados e módulos ou processos funcionais. Eles continuam a encorajar a separação dos processos e dados.
- #30 -All fields usable by the user need to be of type org.nakedobjects.object.Naked. The framework does not know how to display or persist the standard Java types. The framework does provide a number of generic Naked types such as TextString, Money, WholeNumber and Date (all part of the org.nakedobjects.object.value package), which both encompass and extend the types provided by Java. -It is important to access variables through their accessor (get... and set...) methods rather than directly. The persistence mechanism relies on such methods to store away and reload the object's data. -To create an intialized and persistent object, use the factory method createInstance. New instances of business objects should not be created using just the standard Java new operator - this would not initialize them properly. Related to this, a persisted object's constructor will be invoked every time it is restored. -Every persistent object must have a unique ID that does not change between instantiations. The equals and hashCode methods are based on this ID and should not be changed. If a business object class is defined as a subclass of AbstractNakedObject, then you must also do the following in order for the framework to be able to access and manipulate these objects, and thereby make them available to users: -Declare the class as public. -Ensure the class has a zero-parameter constructor (this is often referred to as the default constructor). -Declare as public all of its methods that are to be made available to the framework. -Implement the abstract title method from the superclass so that it returns a non-null reference. The title method will help users to distinguish each object from the rest of the instances of a specific type - but it could also be used for other purposes, such as searching or report generation.
- #31 With the naked objects approach, building a business system consists solely of defining the domain objects All user actions consist of creating or retrieving objects, specifying their attributes, forming associations between them, or invoking methods on an object (or collection of objects) - in other words through a truly object-oriented user interface. The naked objects approach encourages the design of truly object-oriented business systems. It does so in a negative sense, by making it very difficult for the designer to separate procedure and data; it does so in a positive sense, by making the idea of behaviourally-complete domain objects very concrete and very fast to develop I originally predicted that the naked objects approach should deliver four benefits: -Higher development productivity through not having to write a user interface -More maintainable systems through the enforced use of behaviourally-complete objects. More agile -Improved usability deriving from a pure object-oriented user interface -Easier capture of business requirements because the naked objects would constitute a common language between developers and users. Our experience to date has demonstrated four such benefits: Naked objects can better accommodate future changes to business requirements. Naked objects empower the user. Naked objects improve communication between developers and users. Naked objects can speed up the development process.