Naked Objects
•Descargar como PPT, PDF•
0 recomendaciones•1,064 vistas
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.
![“ Behavioural completeness ” ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (8)
Similar a Naked Objects
Similar a Naked Objects (20)
Más de elliando dias
Más de elliando dias (20)
Naked Objects
- 1. Naked Objects Richard Pawson e Robert Mathews Apresentação : Marcos E. B. Broinizi Orientador : João E. Ferreira
- 22. Práticas conceituadas no projeto 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, Processo ou 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 uma camada 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 sistema standalone, 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
Notas del editor
- - 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.
- 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.
- - 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.
- -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.
- -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’.
- -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.
- -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.
- 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.
- -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.
- 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.