Entities: Um Framework Baseado em Naked Objects para

Desenvolvimento de Aplicações com Interfaces Customizáveis

Marcius Brandão1, Mariela Inés Cortés

1, Enyo J. T. Gonçalves

2

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].

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.

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

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. }

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

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.