Entities: Um Framework Baseado em Naked Objects para
Desenvolvimento de Aplicações com Interfaces Customizáveis
Marcius Br...
Atualmente, vários frameworks implementam o padrão Naked Obejcts (Naked
Objects Framework, Domain Object Explorer, JMatter...
2.2.1.Anotações para UI
O framework Entities permite a personalização e multiplicidade das visões para as
classes de negóc...
Para desenvolver uma aplicação usando Entities o desenvolvedor deve
implementar os naked objects, ou seja, as classes de n...
Figura 3(A) mostra o caso de uso “Request Overtime” onde o colaborador informa o
período da hora extra e a descrição do se...
observado é o baixo custo de manutenção, consequência de o aplicativo ser
desenvolvido com aproximadamente 2/3 de linhas d...
Próximos SlideShares
Carregando em…5
×

Framework Entities na CBSoft

2.866 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.866
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2.378
Ações
Compartilhamentos
0
Downloads
22
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Framework Entities na CBSoft

  1. 1. Entities: Um Framework Baseado em Naked Objects para Desenvolvimento de Aplicações com Interfaces Customizáveis Marcius Brandão1 , Mariela Inés Cortés1 , Enyo J. T. Gonçalves2 1 Universidade Estadual do Ceará, Campus Itapery, Fortaleza, CE, Brasil 2 Universidade Federal do Ceará, Campus Quixadá, Fortaleza, CE, Brasil marcius.brandao@uece.br, mariela@larces.br, enyo@ufc.br Abstract. The Naked Objects architectural pattern was originally designed for developing applications controlled by more "expressive" domain through standard OOUI, suitable for sovereign posture applications. This paper presents the Entities framework, a tool designed to provide support to the development of systems through conventional GUIs, highly customizable, generated from a mapping Object-User Interface. Resumo. O padrão arquitetural Naked Objects foi originalmente concebido para o desenvolvimento de aplicativos controlados por domínio mais “expressivo” através de OOUI padronizadas, adequado para aplicações sovereign posture. Este artigo apresenta o framework Entities, uma ferramenta projetada para prover suporte ao desenvolvimento de sistemas através de GUIs convencionais, altamente personalizáveis, geradas a partir de um mapeamento Object-User Interface. 1. Introdução Pesquisas do Standish Group mostram que 70% do código de um aplicativo está relacionado à infraestrutura e que a construção de interface de usuário (UI) consome cerca de 50% do código e do tempo de desenvolvimento [Myers, et al., 1992], principalmente nas Rich Internet Applications (RIA) [Daniel, et al., 2007]. Estas aplicações são tipicamente baseadas na arquitetura n-camadas [Fowler, 2003] onde a mudança nos requisitos pode implicar em mudanças nos objetos de domínio e, consequentemente, na propagação dessas alterações para as outras camadas [Läufer, 2008]. Além disso, esta arquitetura promove o código spaghetti [Yoder, 1997] que torna difícil lidar de forma ágil ou precoce com as mudanças nos requisitos, pois o código se torna extremamente difícil de visualizar, entender, testar, dificultando a rastreabilidade dos requisitos [Evans, 2003]. Neste cenário, o padrão arquitetural Naked Objects [Pawson, 2004] surgiu como uma alternativa e mostrou-se promissor uma vez que elimina a necessidade de se implementar as camadas de UI e persistência reduzindo a quantidade de código duplicado (e consequentemente dos erros em potencial) e o tempo de desenvolvimento [Raja e Lakshmanan, 2010]. O padrão impõe o uso de Object Oriented User Interface (OOUI) que combina representação gráfica com os princípios de manipulação direta. Embora esta abordagem seja adequada para aplicações soberanas[Cooper,2007], onde o usuário é tratado como um solucionador de problemas, a maioria dos sistemas de negócios não é de todo expressiva e tratam os usuários como seguidores de processos [Haywood, 2009]. Isto representa um fator que inviabiliza a aplicabilidade do padrão em outros domínios [Raja e Lakshmanan, 2010].
  2. 2. Atualmente, vários frameworks implementam o padrão Naked Obejcts (Naked Objects Framework, Domain Object Explorer, JMatter, Apache ISIS). Estes frameworks seguem a filosofia de interfaces “expressivas” através de OOUI onde somente uma UI é gerada para cada objeto de negócio. Adicionalmente, nenhum deles oferece suporte adequado à personalização do layout da interface do usuário de forma consistente com o referido padrão [Brandão, et al., 2012] [Kennard, 2011], que requer que a criação da interface de usuário seja inteiramente automatizada a partir dos objetos de domínio (Raja, et al., 2010) (Pawson, 2004). Além destas fortes limitações, muitos destes frameworks apresentam outras características que dificultam a sua aceitação e/ou utilização como, por exemplo, exigirem um alto nível de acoplamento do modelo às classes e/ou com a tecnologia utilizada pelo framework. Outros frameworks como dotObjects, Sanssouci e Trails não apresentam documentação e nenhum indicativo se o projeto está ativo ou não. Este artigo apresenta o framework Entities baseado no padrão arquitetural Naked Objects para viabilizar a criação de aplicações WEB através de GUIs convencionais, altamente personalizáveis, geradas a partir de um mapeamento Object-User Interface. A organização deste trabalho é a seguinte: na Seção 2 é apresentada uma visão geral do Framework, em seguida (Seção 3) um exemplo de uso do framework para criação de aplicações WEB é demonstrado. Por fim (Seção 4), as conclusões e trabalhos futuros. 2. Entities: Visão Geral O framework é destinado a apoiar o desenvolvimento de sistemas corporativos orientados a objetos para web, de forma ágil, padronizada e capaz de responder a futuras mudanças de requisitos. O Entities está disponível para download no endereço http://code.google.com/p/entities-framework/ e é um software livre sob licença Creative-Commons. Esta ferramenta também dispõe de manual de uso, disponível em http://entities-framework.googlecode.com/files/Entities-Dissertacao.pdf e um “Quick Start” em http://entitiesframework.blogspot.com.br/p/entities-em-1-minuto.html. 2.2. Principais Recursos O Entities propõe o uso de GUIs convencionais baseadas em UI Conceptual Patterns [Molina, et al., 2002]. Aplicativos de negócios comerciais baseados em Sistemas de Informação tem interfaces estruturalmente semelhantes e são essencialmente baseadas em formulários ou uma web page que constituem uma unidade de iteração ou Presentation Unit [Molina, et al., 2002]. Estes formulários podem ser criados a partir de padrões de interfaces chamados de Presentation Patterns [Molina, et al., 2002]. A personalização de cada interface de usuário do Entities é construída através de uma linguagem de layout chamada Naked Objects View Language (NOVL) [Brandão, Cortés e Gonçalves, 2012] baseada em texto simples, portanto independente de tecnologia, no lugar de estruturas mais sofisticadas como css, html, xml e um dos diferenciais da NOVL é o suporte a criação de UI´s do tipo Master-Details.Um conjunto de annotations ou anotações (metadados) complementam as informações necessárias para a construção das UI´s. As próximas seções apresentam o detalhamento das anotações definidas no framework e utilizadas para construir as interfaces customizadas a linguagem NOVL.
  3. 3. 2.2.1.Anotações para UI O framework Entities permite a personalização e multiplicidade das visões para as classes de negócio através das annotations @View e @Views respectivamente, através da definição de uma UI específica através de NOVL. Os elementos de @View são: name (nome da UI); title (título da UI); filters, header, members e footer correspondem às regiões de mesmo nome da visão; namedQuery corresponde ao nome de uma NamedQuery [Oracle, 2010] ou comando JPQL e rows indica a quantidade de objetos a serem exibidos por página. Uma classe, bem como seus atributos e métodos, não possuem todas as informações necessárias para a geração completa de uma interface gráfica. Desta forma, as anotações @EntityDescriptor, @PropertyDescriptor, @ActionDescriptior e @ParamDescriptor podem ser utilizadas para complementarem as informações de UI das classes, propriedades, ações e argumentos respectivamente. 2.2.2.Geração automática de interfaces com Entities Quando o conjunto de classes de negócio é compilado e executado, o framework usa a reflexão para inspecionar o modelo e retratá-lo na tela a partir das visões das classes de negócios descritas através de @Views/@View, onde para cada @View é gerada a UI correspondente. Para as classes que não tem @Views/@View associadas o Entities gera uma UI padrão com todos os membros da entidade e as ações básicas dos controladores para que o usuário possa realiza as operações de CRUD. Os membros são divididos em 4 categorias: i) valores básicos (propriedade do tipo primitivo), ii) associações (propriedade de um outro objeto de negócio), iii) coleções (quando uma propriedade contem várias referências à outros objetos de negócio) e iv) comportamentos ou ações (métodos de classe e de instância). Por exemplo: propriedades do tipo String são representadas por caixas de textos, booleanos com caixas de seleção, associações com “lista de valores”, coleções com tabelas e ações com botões ou hiperlinks. Se o método possuir parâmetros na sua assinatura, uma caixa de diálogo será exibida para o usuário quando este o invocar. Se o método retorna um valor não nulo, o framework irá exibir esse valor para o usuário de acordo com seu tipo. Por convenção os títulos apresentados para as classes, atributos e métodos seguem um padrão são automaticamente gerados seguindo um padrão para a sua construção. 3. Exemplo de Uso O estudo de caso é uma aplicação de aprovação de horas extras, trata-se de um caso real adaptado para este artigo. Por conta da limitação de espaço, aspectos referentes à segurança foram omitidos. A Figura 1 apresenta o diagrama de casos de uso onde podemos observar as funcionalidades do sistema. Figura 1 - Diagrama de Caso de uso
  4. 4. Para desenvolver uma aplicação usando Entities o desenvolvedor deve implementar os naked objects, ou seja, as classes de negócio que modelam o domínio (Employee, OverTime, ...) com seus respectivos atributos, associações, validações e comportamentos. Esta codificação deve seguir as convenções de uma classe java Entity [Oracle, 2010]. A classe deve ser anotada com @Entity, implementar a interfaces Java.io.Serializable, apresentar um construtor sem argumentos (default em Java), métodos de acessos get´s e set´s e uma propriedade @Id para indicar sua unicidade. A Figura 2 mostra a definição da classe Java Entity OverTime. Nas linhas 20 a 26 estão definidas as propriedades com suas respectivas validações e mapeamentos objeto- relacional. Nas linhas 28 a 39 estão definidos os comportamentos, ou seja, os métodos approve, reject, pay e revert. Três casos de uso foram identificados para a entidade OverTime, e cada um foi implementado utilizando a NOVL e as anotações @View e @Views. A visão para o caso de uso “Request Overtime” foi definida nas linhas 3 a 6, “Authorized Overtime” nas linhas 7 a 12 e “Authorize Payment Of Overtime” de 13 a 18. Figura 2. Classe OverTime O Entities requer apenas as classes de negócio,ou naked objects, portanto o modelo implementado é o aplicativo inteiro. Quando o modelo é executado pelo Entities um menu (Figura 3), será apresentado com as opções de links para todas as visões. A 01. @Entity 02. @Views({ 03. @View(name = "RequestOvertime", 04. title = "Request Overtime", 05. Members ="[#employee;#beginning;#ending;#description;request()]", 06. namedQuery = "Select new domain.Overtime()"), 07. @View(name = "AuthorizeOvertime", 08. title = "Authorize Overtime", 09. members = "[employee:2;beginning,ending;#description,remark;"+ 10. "[approve(),reject()]]", 11. namedQuery = "Select ot from Overtime ot,WaitingForApproval st"+ 12. " where ot.status = st"), 13. @View(name = "AuthorizePaymentOfOvertime", 14. title = "Authorize Payment of Overtime", 15. Members = "RequestOvertime[[employee;beginning;ending],"+ 16. "description],Action[pay();revert();reject()]", 17. namedQuery = "Select ot from Overtime ot,WaitingForPayment st"+ 18. " where ot.status = st")}) 19. public class Overtime implements Serializable { 20. @Id @GeneratedValue private Integer id; 21. @NotNull @ManyToOne private Employee employee; 22. @NotNull @Temporal(TemporalType.TIMESTAMP) private Date beginning; 23. @NotNull @Temporal(TemporalType.TIMESTAMP) private Date ending; 24. @Lob @NotEmpty private String description; 25. @Lob private String remark; 26. @NotNull @ManyToOne private Status status; 27. 28. public void approve() { ... } 29. 30. @ActionDescriptor(confirm=true, image="trash") 31. public void reject() { ... } 32. 33. @ActionDescriptor(image = "round_ok") 34. public void pay() { ... } 35. 36. @ActionDescriptor(image = "trackback") 37. public void revert(@Editor(propertyType = PropertyType.MEMO) 38. @ParameterDescriptor(displayName = "Remark") 39. String remark) { . . . } 40. //imports, Get´s, Set´s, equals() e hashCode() omitted 41. }
  5. 5. Figura 3(A) mostra o caso de uso “Request Overtime” onde o colaborador informa o período da hora extra e a descrição do serviço a ser realizado e envia para a supervisão. Figura 3 – Menu Principal e Caso de Uso “Request Overtime” A Figura 4(B) mostra a visão do caso de uso “Authorize Overtime” que lista todas as solicitações aguardando aprovação para a aprovação ou rejeição do supervisor simplesmente clicando no botão “Approve” ou “Reject” de cada solicitação. A Figura 4(C) mostra a visão do caso de uso “Authorize Payment of Overtime” que lista para o responsável pelo RH todas as solicitações aprovadas pelos supervisores para avaliação. Figura 4 - Casos de uso RequestOvertime, Authorize Overtime e Authorize Payment 5. Considerações Finais Este artigo apresenta o framework Entities que vem sendo desenvolvido desde 2008 e usado no desenvolvimento de diversas aplicações críticas por órgãos do governo do estado do Ceará, organizações particulares e profissionais autônomos. Os principais projetos são o SIGDER-Sistema Integrado de Gestão do DER desenvolvido pelo Departamento Estadual de Rodovias do Ceará, SIGEO-Sistema de Informações Georeferenciadas desenvolvido pela ETICe-Empresa de Tecnologia da Informação do Ceará, o projeto Avalere-Sistema de Autoavaliação desenvolvido pelo Departamento de Informática da UECE – Universidade Estadual do Ceará, o SISO- Sistema Odontológico desenvolvido pelo Núcleo de práticas da Universidade Federal do Ceará e o projeto SGC–Sistema de Gestão de Competências desenvolvido pela fábrica de software da Faculdade Lourenço Filho. Embora ainda não tenhamos concluido nenhuma avaliação formal, alguns resultados empíricos podem ser relatados informalmente, a partir do retorno obtido pelos usuários do framework ao longo de 4 anos nesses projetos, quando comparado às tecnologias java mais utilizadas atualmente no Mercado: i)Em relação à produtividade foi relatado um aumento significativo (triplo ou mais); ii) Outro ponto que temos
  6. 6. observado é o baixo custo de manutenção, consequência de o aplicativo ser desenvolvido com aproximadamente 2/3 de linhas de código a menos; iii) Quanto à usabilidade temos tido uma boa aceitação de aproximadamente 80% dos usuários, no entanto, este aspecto ainda está sendo melhorado. A utilização da NOVL possibilitou a definição de múltiplas visualizações altamente personalizadas através de metadados nos objetos do domínio, bem como a sua manipulação independentemente da tecnologia. Reduziu o ciclo de aprendizado e facilitou a manutenção. Desta forma, um dos principais limitadores da utilização do padrão Naked Objects pode ser contornado, sem ferir o padrão, pois nem o comportamento nem a forma de armazenamento dos objetos são modificados. Assim, os desenvolvedores continuam focando seus esforços apenas no domínio da aplicação, sem a preocupação nos aspecto de infraestrutura. Por outro lado, a abordagem proporciona mais modularidade e propicia o reuso do modelo, tornando-o mais fácil de manter e evoluir ao longo do tempo. Reduz a quantidade de código repetitivo propenso a erros, reduzindo o tempo e os custos. References Brandão, M.; Cortés, M.; Gonçalves, E. NOVL: Uma linguagem de layout para Naked Objects. InfoBrasil, Fortaleza, 2012. Brandão, M.; Cortés, M.; Gongalves, Ê. Entities: Um Framework Baseado em Naked Objects para Desenvolvimento de Aplicações Web Transientes. CLEI - Latin American Symposium on Software Engineering Technical, Medellim, 4 Outubro 2012. Cooper, A.; Reimann, R.; Cronin, D. About Face 3 - The Essentials of Interaction Design, 3rd ed. Indianapolis, Indiana, United States of America: Wiley Publishing, 2007. Evans, E. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston, MA: Addison Wesley, 2003. ISBN ISBN: 0-321-12521-5. Fowler, M. Patterns of Enterprise Application Architecture. 1. ed. Boston: Addison-Wesley Professional, 2003. ISBN 0321127420. Kennard, R. Derivation of a General Purpose Architecture for Automatic User Interface Generation. University of Technology, Sydney. Faculty of Engineering and Information Technology, 2011. Läufer, K. A Stroll through Domain-Driven Development with Naked Objects. Computing in Science & Engineering, June 2008. 76-83p. Molina, P.; Meliá, S.; Pastor, O. User Interface Conceptual Patterns. 9th International Workshop on Design,Specification and Verification of Interative Systems (DSV-IS), Berlin, Germany, December 2002. Oracle and/or its affiliates, The Java EE 5 Tutorial., 2010. Pawson, R. Naked Objects, Phd thesis. Dublin: Trinity College, 2004. Haywood, D. Domain-Driven Design using Naked Objects, Susannah Davidson Pfalzer, Ed. USA: Pragmatic Bookshelf, 2009. Raja, A.; Lakshmanan, D. "Naked Objects Framework," International Journal of Computer Applications, vol. I, no. 20, 2010. Foote, B; Yoder, J. Big Ball of Mud. Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997.

×