O documento apresenta o framework Entities, que fornece suporte para o desenvolvimento de sistemas web com interfaces personalizáveis geradas a partir de mapeamentos entre objetos e interfaces de usuário. O framework implementa o padrão arquitetural Naked Objects e permite a geração automática de interfaces customizadas através da linguagem NOVL e anotações nas classes de domínio. Exemplos demonstram como o framework pode ser usado para desenvolver uma aplicação de aprovação de horas extras com diferentes visões geradas para cada caso de uso.

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