Entities: Um Framework Baseado em Naked Objects para Desenvolvimento de Aplicaes Web Transientes

Marcius Brando, Mariela I. Corts

Universidade Estadual do Cear Fortaleza, Brasil marciusbrandao@gmail.com, mariela@larces.uece.br

Enyo Jos Tavares Gonalves

Universidade Federal do Cear Quixad, Brasil enyo@ufc.br

Resumo O padro arquitetural Naked Objects uma abordagem promissora para o desenvolvimento rpido de software uma vez que propicia o aumento da produtividade. Os frameworks baseados no padro Naked Objects foram desenvolvidos originalmente para a criao de aplicaes de postura soberana, ou seja, onde o usurio tratado como um solucionador de problemas. No entanto boa parte das aplicaes de mercado desenvolvida seguindo uma postura transiente, onde o usurio tratado como um seguidor do processo. Este artigo apresenta o framework Entities, projetado para prover suporte ao desenvolvimento de sistemas com postura transiente atravs de interfaces de usurio convencionais, geradas a partir de anotaes e usando uma linguagem de layout chamada Naked Objects View Language. Abstract - The architectural Naked Objects Pattern is a promising approach for a rapid software development through productivity increase. Frameworks based on Naked Objects pattern were originally developed for the creation of sovereign posture applications, ie., where the user is treated as a problem solver. However much of the market applications are developed following a transient posture, where the user is treated as a follower of the process. This paper presents the framework Entities designed to provide support to the development of transient posture systems through conventional GUIs generated from annotations and using a layout language called Naked Objects View Language. Keywords-component: Metaprogramao, Usurio, Programao Orientada a Objetos, Java. Interfeces de

com os princpios de manipulao direta. Em uma OOUI o usurio pode identificar os objetos de trabalho, averiguar os comportamentos oferecidos por esses objetos e invoc-los diretamente sobre os objetos [7][8]. Na abordagem de desenvolvimento com Naked Objects o ncleo dos objetos de negcio mostrado diretamente na interface do usurio por meio de um mecanismo de visualizao de objetos (Object Viewing Mechanism - OVM) e todas as interaes consistem em invocar os mtodos desses objetos no estilo objeto-verbo [9]. Embora a abordagem baseada em NO seja adequada para aplicaes soberanas [2] a maioria dos sistemas de negcios no de todo expressiva [8]. Isto representa um fator que inviabiliza a aplicabilidade do padro em outros domnios como, por exemplo, no caso de aplicaes transientes [2][14] onde cada interface do usurio normalmente cumpre uma nica funo e apenas os controles necessrios so disponibilizados. Este artigo apresenta o Entities, um framework de suporte ao desenvolvimento de sistemas transientes baseado no padro NO com foco na criao de aplicaes coorporativas para a web a partir da gerao automtica de interfaces de usurio grficas (GUI) convencionais altamente customizveis. A personalizao de cada interface de usurio alcanada atravs de uma linguagem de layout chamada Naked Objects View Language[10] (NOVL), suportada por um conjunto de annotations que complementam as informaes necessrias para a construo das UIs. O artigo est organizado como segue: na Seo 2, os trabalhos relacionados so apresentados. Na Seo 3 apresentado o referencial terico das tecnologias utilizadas para a concepo do Entities. Na Seo 4 apresentado o Framework Entites e a linguagem NOVL, descrevendo como a gerao de interfaces customizadas acontece. Na Seo 5 ilustrado o desenvolvimento de uma aplicao transiente utilizando o framework Entities. E por fim, na Seo 6 so apresentadas as concluses e sugestes para trabalhos futuros. II. TRABALHOS RELACIONADOS Atualmente, vrios frameworks implementam o padro NO, a saber: Naked Objects Framework (NOF)1, Domain Object Explorer2, JMatter3, Apache ISIS4. Estes frameworks seguem a filosofia de interfaces expressivas atravs de
1 2

I. INTRODUO Na busca constante pelo desenvolvimento cada vez mais rpido de aplicaes com boa relao custo-benefcio, o padro arquitetural Naked Objects (NO) [1] surge como uma abordagem promissora uma vez que elimina a necessidade de se implementar as camadas de interface com o usurio (UI) e persistncia [2][3][4][5]. Como consequncia a utilizao do padro promove os seguintes benefcios: i) reduo da quantidade de linhas de cdigo, o que representa uma diminuio substancial de erros em potencial [6]; ii) rpido ciclo de desenvolvimento; e iii) fcil anlise e alterao nos requisitos. O padro NO foi originalmente concebido para o desenvolvimento de aplicativos controlados por domnio mais expressivo [7]. Pesquisas indicam que a melhor maneira de alcanar expressividade atravs de uma interface de usurio orientada a objetos (OOUI) combinando representao grfica

http://nakedobjects.net http://java.net/projects/doe/pages/Home 3 http://jmatter.org/ 4 http://incubator.apache.org/isis/index.html

OOUI onde somente uma UI gerada para cada objeto de negcio. Adicionalmente, nenhum deles oferece suporte adequado customizao do layout da interface do usurio de forma consistente com o referido padro, que requer que a criao da interface de usurio seja inteiramente automatizada a partir dos objetos de domnio [1][2], tirando o foco do desenvolvimento para as demais camadas da aplicao. Estas caracteristicas torna invivel a utilizao desses frameworks para a criao de aplicaes transientes onde cada interface do usurio de natureza temporria e, portanto, deve ser simples e objetiva: normalmente cumprem uma nica funo e apenas os controles necessrios so disponibilizados. Alm destas fortes limitaes, muitos destes frameworks apresentam outras caractersticas que dificultam a sua aceitao e ou utilizao como, por exemplo, exigirem um alto nvel de acoplamento do modelo s classes do framework. III. REFERENCIAL TERICO Nesta seo apresentado o padro Naked Objects e seu mecanismo de visualizao de objetos, que constitui a base conceitual e tcnica utilizada para a criao do Entities. A. Naked Objects Pattern (NOP) O conceito bsico por trs do Naked Objects que, ao escrever um aplicativo de negcios, o desenvolvedor deve criar apenas os naked objects (os objetos de negcio que modelam o domnio [11][12]) e as suas respectivas lgicas de negcio encapsuladas. O framework que utilizar a tecnologia se encarrega de disponibilizar, a partir dos objetos de negcio, a aplicao com interface grfica, persistncia e gerenciamento desses objetos. Alm de eliminar a necessidade de escrever uma camada de interface do usurio e a camada de acesso a dados, o padro Naked Objects tambm facilita uma boa modelagem dos objetos - porque o prottipo do modelo de domnio transformado diretamente em um aplicativo que pode ser avaliado pelos usurios de negcios [3]. Os princpios do NOP [2][11] so: (i) toda a lgica de negcio deve ser encapsulada nos objetos de domnio, (ii) a interface de usurio deve refletir completamente os objetos de domnio, incluindo todas as aes do usurio, como criar e recuperar os objetos de domnio e (iii) a criao da interface de usurio deve ser inteiramente automatizada a partir dos objetos de domnio. O padro arquitetural Naked Objects (Fig. 1 direita) surgiu como uma alternativa ao padro 4-camadas (Fig. 1 esquerda). Neste padro, um simples conceito de negcio (por exemplo, um Cliente) normalmente representado em todas as quatro camadas, de diferentes formas. As relaes entre os elementos nessas quatro camadas muitas vezes exigem um mapeamento complexo (muitos-para-muitos). Embora cada uma das camadas segue a abordagem orientada a objeto, o princpio original de objetos comportamentalmente completos no se verifica uma vez que este modelo promove a separao continua entre dados e procedimentos [1].
Figura 2. Arquitetura padro 4-camadas e Arquitetura Naked Objects[1]

No padro Naked Objects as funes de view e controller (como originalmente definidas no MVC, Model-ViewController [13]) so genricas e, por tanto, as regras de negcio devem ser definidas nas entidades do domnio (ou seja, no modelo), promovendo assim a modelagem de objetos com completude comportamental [1]. B. Object Viewing Mechanism O mecanismo que gera a interface de usurio (incorporando os papis de view e controller em uma arquitetura MVC) com base nas informaes contidas nos objetos de negcios chamado de Object Viewing Mechanism (OVM)[7]. Devido natureza abstrata do padro, possvel criar OVMs sob medida para as capacidades de uma plataforma de visualizao particular. No entanto, para ser consistente com o padro NO, a interface do usurio no precisa fazer uso de cones e manipulao direta. A UI precisa apenas preservar a noo de que o usurio esta lidando diretamente com os objetos de domnio e invocar explicitamente os comportamentos nesses objetos [1]. Ou seja, o estilo de interao deve ser 'object-action' (ou 'noun-verb') [9]. O OVM independente das aplicaes, as aplicaes so independentes de OVMs e um OVM pode ser usado por todos os aplicativos NO. Assim sendo, possvel executar aplicaes NO em diferentes ambientes ou dispositivos apenas alternando o OVM. Desta forma, cdigo e tempo podem ser reduzidos ao desenvolver aplicativos para dispositivos em diferentes plataformas (desktop e dispositivos mveis) [6]. IV. ENTITIES FRAMEWORK Entities um framework escrito em Java baseado no padro arquitetural Naked Objects. O framework destinado a apoiar o desenvolvimento de sistemas corporativos transientes orientados a objetos para web, de forma gil, padronizada e capaz de responder a futuras mudanas de requisitos. Em aplicaes transientes [14] cada interface do usurio normalmente cumpre uma nica funo e apenas os controles necessrios so disponibilizados. Possuem natureza temporria (o usurio acessa, realiza sua tarefa e sai), portanto, deve ser simples, objetiva e com uma baixa exigncia de habilidades motoras do utilizador. Para prover estas caractersticas o padro NO precisa ser adaptado como mostrado na Fig. 2. Onde as OOUI devem ser substitudas por UIs convencionais altamente

personalizveis, cada objeto de negcio possa ser representado por uma ou mais UI, e cada UI seja otimizada para a realizao de uma tarefa especfica.

no cdigo fonte; iii) JavaServer Faces (JSF), um framework de interface de usurio baseado em componentes para construo de aplicaes web; iv) Java Persistence API (JPA), uma soluo baseada em padres para persistncia de acordo com o mapeamento objeto-relacional; v) Bean Validation (BV), que define um modelo de metadados e API para validao de dados em componentes JavaBeans definidos em um nico local e compartilhados atravs das diferentes camadas; vi) Expression Language (EL), uma linguagem utilizada para acessar os objetos do sistema; e vii) a 'reflexo' [15], segundo o qual um objeto pode ser interrogado por outro objeto, em tempo de execuo, para revelar seus mtodos e a capacidade de criar novos objetos ou modificar as definies do objeto no sistema dinamicamente. D. Implementao da arquitetura A estrutura do framework apresentada de forma simplificada na Fig. 3 descrevendo os pacotes, classes e interfaces. Os pacotes anotations e entities representam a camada de domnio do framework com a qual o desenvolvedor poder, ou no, utilizar no modelo de domnio. Os pacotes descriptor e reflection representam a camada de metamodelo. Os pacotes validation e dao correspondem camada de persistncia do framework e o mdulo ovm a camada OVM. Os componentes JPA, JSF e Apache Commons representam as APIs Java ou componentes de terceiros.

Figura 2. Arquitetura Entities

C. Plataforma de desenvolvimento O framework Entities foi desenvolvido na plataforma JEE uma vez que fornece recursos adequados para o desenvolvimento baseado no padro Naked Objects para web, tais como: i) dispe de interfaces de modo a suportar polimorfismo; ii) Annotations, recurso para definir metadados

Figura 3. Viso geral da estrutura do Entities

Camada de metamodelo Esta camada a base do framework e responsvel pelo reconhecimento e manipulao das classes e objetos do modelo de domnio via reflexo. A camada possui dois pacotes:
1)

do Entities que complementam as classes do modelo de domnio com as informaes necessrias para a criao automtica das UIs. O pacote Entities possui duas classes e uma interface. A classe Repository representa o servio de persistncia em nvel de domnio, ou seja, pode ser invocado pelos objetos de domnio. Fornece o mecanismo para localizar referncias a objetos existentes, bem como cri-los, alter-los e exclu-los. Todos os mtodos necessrios para a manipulao das entidades so de propsito geral e independente do tipo da instncia. A classe Context a interface para acesso s informaes globais do ambiente da aplicao. Essa interface consiste em um conjunto de ligaes de nome-para-objeto e contm os mtodos para examinar e atualizar essas ligaes. Finalmente, a interface CurrentUser Entities prov autorizao baseada no User Peer Object Pattern [8], que basicamente um mapeamento entre o objeto de domnio com o usurio do sistema (ou seja, o seu login). Por exemplo: Context.setCurrentUser(employee); A personalizao de cada interface de usurio do Entities construda atravs de uma linguagem de layout chamada Naked Objects View Language (NOVL). Um conjunto de annotations ou anotaes (metadados) complementam as informaes necessrias para a construo das UIs. As prximas sees apresentam o detalhamento das anotaes definidas no framework e utilizadas para construir as interfaces customizadas com a linguagem NOVL. E. Anotaes para UI Annotations um recurso do JSE 5.0 5 que consiste em metadados utilizados como modificadores de classes, interfaces, mtodos e propriedades. Java fornece annotations prprias, porm novas anotaes personalizadas podem ser incorporadas. O framework Entities permite a personalizao e multiplicidade das vises para as classes de negcios atravs das annotations @View e @Views respectivamente, pelas quais o desenvolvedor pode especificar o layout, definindo quais atributos, associaes e mtodos so disponibilizados para o usurio em uma UI particular, utilizando a Naked Objects View Language. A annotation @View representa uma nica UI para uma determinada classe de negcio. Essa UI consiste sempre na exibio de uma coleo de instncias dessa classe de negcios que determinada por um comando JPQL[15]. JPQL uma linguagem da especificao JPA para consulta em objetos de entidades ao invs de tabelas de banco de dados. Sua sintaxe semelhante a SQL. A Fig. 4 mostra a estrutura de uma UI onde no [TITLE] exibido o ttulo da viso. No [FILTERS] so definidos os componentes de filtragem da coleo que permitem o usurio

reflection: As classes desse pacote so responsveis pela introspeco das classes e objetos do domnio em tempo de execuo. descriptor: As classes desse pacote so responsveis pelo reconhecimento das meta informaes contidas nas classes de domnio e servem de interface com o resto da estrutura. Todas as annotations da JPA e do BV so consideradas e utilizadas na gerao automtica das interfaces. Camada de persistncia Essa camada encapsula o framework de persistncia (JPA) atravs de um facade [16], onde um objeto fornece uma interface simplificada para um conjunto maior de cdigo. Os pacotes includos so validation e dao, responsveis pela validao das instncias das entidades do domnio e o encapsulamento do acesso a dados, respectivamente.
2)

Camada OVM O Object Viewing Mechanism (OVM) o mecanismo que gera a interface de usurio (incorporando os papis de View e Controller em uma arquitetura MVC) com base nas informaes contidas nos objetos de negcio [7]. Esse mecanismo implementado no pacote OVM e representa o corao do framework. O OVM do Entities gera UIs baseadas em pginas HTML atravs de componentes do JavaServer Faces JSF.
3)

O objeto EntityDesignerJSF monta dinamicamente a interface de usurio a partir das informaes dos objetos de negcio fornecidas pela camada de metamodelo. O objeto AutoEntityBackBean realiza a interface (ligao) da UI com as instncias de negcios obtidas atravs da camada de persistncia. Finalmente, os objetos do tipo ActionController respondem s interaes do usurio na interface repassando para as instncias de negcio ou acionando os servios de domnio. O subpacote components contem as implementaes das classes dos componentes JSF personalizados necessrios para a construo das UIs. O subpacote controllerImpl contem as implementaes da classe abstrata ActionController, responsveis pela interao do usurio com os objetos atravs da UI. No subpacote converters esto as classes de converso que implementam a interface javax.faces.convert.Converter da API JSF. Camada de domnio Nesta camada esto todas as extenses do Entities da perspectiva do desenvolver.
4)

O pacote Annotations incorpora o modelo de metadados ou anotaes utilizadas na gerao automtica da interface de usurio personalizada. Neste pacote esto todas as annotations

http://docs.oracle.com/javase/1.5.0/docs/guide/language/annotations.html

mtodos dos objetos de negcios) so alinhados nesta grade ocupando uma ou mais clulas. Cada membro representado por seu respectivo controle visual na UI de acordo com o tipo da propriedade (numrico, data, texto, etc.) ou mtodo (botes, hiperlinks, etc.). Para distribuir os componentes em colunas utilizam-se vrgulas {,}, para indicar que um determinado componente ocupa mais de uma coluna (colspan) utiliza-se o smbolo dois pontos {:} seguido da quantidade de colunas como sufixo do componente. Para a distribuio em linhas utiliza-se o ponto-evrgula {;}. Para definir uma subgrade, envolvemos os componentes com colchetes {[...]}, e assim sucessivamente. Para identificar um membro utiliza-se o nome do membro em case-sensitive. Para diferenciar visualmente uma propriedade de um mtodo, estes devem ter dois parnteses {()} como sufixo. Composies podem ser aninhadas por ponto {.}. Um asterisco {*} como prefixo indica que o membro apenas para leitura, e uma hashtag {#} indica que o membro sempre estar em modo de entrada de dados pelo usurio. Por exemplo, o comando *modifiedDate indica que o membro apenas para exibio na viso. Um novo rtulo pode ser atribudo ao membro prefixando ao nome do membro o texto delimitado por aspas simples {}, pode ser prefixado ao nome e separado por dois pontos {:}. Propriedades do tipo coleo ou listas de objetos podem ter seus membros distribudos em uma subgrade que por sua vez podem ser outras colees, recursivamente. Esta subgrade definida delimitando a subview com os sinais de menor e maior {<...>} como sufixo da propriedade do tipo coleo. A Fig. 5 resume estas propriedades. Por exemplo, a Tabela 1 apresenta uma grade que distribui dez componentes necessrios para a formao de uma determinada GUI. A Fig. 6 apresenta o comando NOVL para a montagem desta grade. Na linha (1) o sufixo {:3} no componente A seguido por {;} indica que a grade principal ter 3 colunas e este componente ir ocupar todas as colunas da primeira linha da grade. Na linha (2), as vrgulas {,} distribuem os componentes B, C e D pelas trs colunas da segunda linha da grade. Na linha (3), temos a mesma distribuio da linha dois por vrgulas para os componentes E e F, sendo que o sufixo {:2} de F indica que o mesmo ocupa duas colunas. Nas linhas (4) e (5), os colchetes com o sufixo {:3} determinam uma nova grade de duas colunas e duas linhas que ocupar as trs colunas da quarta linha da grade principal.

Figura 4. Elementos de uma Viso

encontrar uma instncia especfica ou listar as instncias dessa classe que atendam a algum critrio especfico. No [HEADER] e [FOOTER] so definidas as aes que no pertencem a uma nica instncia (mtodos de classe) e dos controladores, atravs dos quais o usurio pode executar os mtodos de classe, criar uma nova instncia dessa classe, executar uma ao em todas as instncias, gerar um relatrio, etc. No [MEMBERS] so definidos os atributos e aes de instncias de cada objeto da coleo. Portanto, os elementos de @View so: name especifica o nome da UI; title corresponde ao ttulo da UI; filters, header, members e footer correspondem s regies de mesmo nome da viso e so utilizados comandos NOVL para personalizar cada regio; namedQuery corresponde ao nome de uma NamedQuery [17] (comando JPQL esttico definido em um metadado) ou comando JPQL e rows indica a quantidade de objetos a serem exibidos por pgina na regio [MEMBERS]. De forma geral, uma classe, bem como seus atributos e mtodos, no possui todas as informaes necessrias para a gerao completa de uma interface grfica. Desta forma, as anotaes @EntityDescriptor, @PropertyDescriptor, @ActionDescriptior e @ParamDescriptor podem ser utilizadas para complementarem as informaes de UI das classes, propriedades, aes e argumentos de aes respectivamente. Por padro, o Entities assume que todas as aes explcitas do usurio, tais como a de invocar uma ao, seja transiente, ou seja, no persistente. Para que as mudanas em mltiplos campos ou em outros objetos sejam refletidas no repositrio como transaes atmicas deve-se anotar o mtodo com @Transaction. Desta forma, quando cada ao ocorrer, o framework automaticamente envia uma mensagem start transaction para o repositrio de objetos, e o conclui com uma mensagem end transaction. Se alguma exceo for lanada pela ao um roolback ser enviado. Independentemente se o mtodo transacional ou no, o estado do objeto antes da execuo ser sempre restaurado aps qualquer lanamento de exceo. Exemplos do uso dessas annotations so mostrados no estudo de caso na Seo 5. F. Naked Objects View Language (NOVL) NOVL uma linguagem de descrio de layout baseada no uso de layout grid [14] onde o espao da tela dividido em uma grade (linhas e colunas) e os membros (propriedades e

Figura 5. Modificadores de membros

TABELA I. Exemplo de estrutura de layout

componentA componentB componentE componentG componentI componentC componentD

quando este o invocar. Se o mtodo retorna um valor no nulo, o framework ir exibir esse valor para o usurio de acordo com seu tipo. Por exemplo: uma String exibida como uma mensagem e um arquivo como download. Convenes para os rtulos Considerando que o padro POJO6 [18] se utiliza da notao camelcase7, por conveno, os ttulos apresentados para as classes, atributos e mtodos seguem o seguinte padro:
5)

componentF componentH componentJ

1 2 3 4 5

componentA:3; componentB,componentC,componentD; componentE,componentF:2; [componentG,componentH; componentI,componentJ]:3

Figura 6. Exemplo de um comando NOVL

i) Para as classes os ttulos so automaticamente gerados a partir do nome da classe, sem o nome do pacote, adicionando espaos na frente dos subsequentes caracteres maisculos, para separar as palavras, e adicionando um s no final. Por exemplo, uma classe denominada domain.UnitOfMeasure ser exibida como Unit Of Measures. Se o nome da classe se tornar um plural irregular, ento se utiliza a annotation @EntityDescriptor para especificar manualmente a verso do plural na propriedade pluralDisplayName. A annotation tambm permite especificar um ttulo da classe a ser mostrado aos usurios, que seja diferente do nome da classe Java, usando a propriedade displayName. Recurso necessrio para linguagens que usam acentos, por exemplo. ii) Os rtulos das propriedades, ou o nome do campo, so gerados a partir dos nomes dos mtodos de acesso eliminando o prefixo get e adicionando espaos antes de cada letra maiscula encontrada. Por exemplo: getDateOfBirth() ser exibido como Date Of Birth. iii) Os rtulos das aes so gerados a partir dos nomes dos mtodos adicionando espaos antes de cada letra maiscula encontrada. Se o mtodo possui argumentos ento reticncias ... so adicionadas ao final. Nas situaes onde a instncia do objeto deve ser exibida e no um de seus membros (por exemplo: no ttulo da caixa de dilogo das aes de instncia ou lista de valores nas associaes) o OVM usa o resultado do mtodo toString(). Portanto, o programador deve implement-lo de forma que gere uma descrio concisa, um resumo das informaes do objeto (por exemplo, uma concatenao de data e nmero da nota fiscal), ou ainda informaes sobre o status do objeto. Mecanismo de Filtragem Seguindo o princpio naked objects de implementao genrica de servios, o OVM do Entities integra os recursos de filtragem diretamente na viso atravs de um painel de consulta. A definio visual do painel de consulta feita usando NOVL na propriedade filters da annotation @View. A ordem dos filtros irrelevante, portanto podem ser organizados livremente. Atravs deste painel de consulta os
6)
6

Demais recursos da linguagem so apresentados no estudo de caso. G. Gerao automtica de interfaces com Entities e NOVL Quando o conjunto de classes de negcio compilado e executado, o OVM do framework usa a reflexo para inspecionar o modelo e retrat-lo na tela a partir das vises das classes de negcios descritas atravs de @Views/@View, onde para cada @View gerada a UI correspondente. Para as classes que no tem @Views/@View associadas o OVM gera uma UI padro com todos os membros da entidade e as aes bsicas dos controladores necessrios para que o usurio possa realizar as operaes de CRUD. Para cada membro (propriedades e aes) de um objeto de negcio o OVM pode represent-lo na UI a partir de trs componentes visuais, um para edio, um para simples exibio e outro para filtragem, de acordo com o a posio na UI, estado da instncia e o tipo do membro e suas metainformaes. Membros so divididos em 4 categorias: i) valores bsicos (propriedades do tipo primitivo), ii) associaes (propriedade de outro objeto de negcio), iii) colees (propriedade com vrias referncias a outros objetos de negcio) e iv) comportamentos ou aes (mtodos de classe e de instncia). Por exemplo: propriedades do tipo String so representadas por caixas de textos, booleanos com caixas de seleo, associaes com lista de valores, colees com tabelas e aes com botes ou hiperlinks. As aes so a essncia do modelo, pois elas contm todas as regras do domnio e representam uma troca de mensagens entre os objetos de negcios, e destes com o usurio em forma de botes ou hiperlinks. Essa troca de mensagens depende da assinatura do mtodo. Se o mtodo possuir parmetros na sua assinatura, uma caixa de dilogo ser exibida para o usurio

Acrnimo para Plain Old Java Object, termo usado para enfatizar que um determinado objeto um objeto Java comum, no um objeto especial. 7 Denominao em ingls da prtica de escrever palavras compostas ou frases onde cada palavra iniciada com letra maiscula e concatenada, sem espaos.

usurios podem especificar os critrios de seleo que sero aplicados viso. Toda a implementao automtica e independente do domnio em questo, eliminando desta forma qualquer necessidade dos desenvolvedores programarem suas prprias camadas de pesquisa. O OVM do Entities apresenta uma forma avanada de filtragem baseada em expresses condicionais para prover flexibilidade e facilidade de uso. Para cada membro do tipo valor bsico uma caixa de texto apresentada, onde o usurio pode montar as expresses e para membros do tipo associao uma caixa de seleo. A montagem das expresses simples, mas poderosa, permitindo criar expresses de filtro bastante complexas, bem como combinar expresses. Ao construir um filtro (ou consulta) o usurio precisa informar OVM critrios de procura para os campos de interesse, digitando uma expresso nas caixas de textos de acordo com o tipo da informao. Ao aplicar os critrios de filtragem o OVM ir validar as expresses e atualizar a UI com as instncias que atendam aos critrios. A filtragem de propriedades do tipo string pode ser realizada de forma exata ou no exata. No ltimo caso so utilizados caracteres curinga para se referir a um nico caractere ou uma cadeia de caracteres. A OVM reconhece dois curingas: i) o asterisco (*) que indica zero ou mais caracteres e ii) o ponto de interrogao (?) que representa um nico caractere desconhecido (dois pontos de interrogaes representam dois caracteres desconhecidos). No caso de filtragem de propriedades do tipo numrico, operadores matemticos (<, >, =, >=, =<) podem ser usados para definir um intervalo que se quer selecionar. Para localizar valores em um intervalo de nmeros deve se digitar a expresso x..y onde x e y representam os extremos do intervalo. Os mesmos operadores podem ser utilizados para o caso de propriedades do tipo data/hora. Expresses podem ser combinadas atravs do operador {;}. V. DESENVOLVENDO UMA APLICAO O estudo de caso apresenta uma aplicao transiente de um fluxo de solicitao e aprovao de horas extras adaptado de um caso real para este artigo8. Por conta da limitao de espao, aspectos referentes segurana foram omitidos. O diagrama de caso de uso da Fig. 7 apresenta os papis e as funcionalidades da aplicao onde: o colaborador solicita a realizao de horas extras com uma justificativa e o perodo. As solicitaes so ento analisadas pelo supervisor, que pode autorizar ou no. As solicitaes autorizadas pelo supervisor so analisadas pelo setor de RH para clculo e autorizao de pagamento. Caso o RH tenha alguma dvida ou as informaes estiverem incompletas, a solicitao poder ser retornada para o supervisor.

Figura 7. Diagrama de Caso de uso

Em geral, os objetos de negcio so codificados da mesma forma que os objetos de negcio comportamentalmente completos deveriam ser escritos para a camada de modelo de negcio de qualquer sistema multicamadas. Do ponto de vista do programador, um sistema na abordagem naked objects consiste unicamente desse modelo, e cada classe de negcio efetivamente herda a capacidade de exibir a si e seus comportamentos de negcios diretamente para o usurio. A Fig. 8 mostra o diagrama de classes resultante do diagrama de caso de uso.

Figura 8. Diagrama de Classes

8

A aplicao completa est disponvel para download em https://dl.dropbox.com/u/3753780/Entities/Downloads/clei2012.rar

Para desenvolver uma aplicao usando Entities tudo que o desenvolvedor deve descrever so os naked objects, ou seja, as classes de negcio que modelam o domnio (Employee, OverTime, ...) com seus respectivos atributos, associaes, validaes e comportamentos (regras de negcios). Por exemplo, os mtodos request, approve, pay, rejects e revert da classe Overtime. Esta implementao deve seguir as convenes de uma classe Java Entity [17], i.e., um objeto Java regular (POJO) com propriedades de mapeamento para uma tabela do banco de dados. A Fig. 9 mostra a definio da classe Java Entity Employee. A classe deve ser anotada com @Entity, programar a interface java.io.Serializable (linha 71), apresentar um construtor sem argumentos (default em Java), mtodos de acessos gets e sets (linha 92-123) para as propriedades, ter uma propriedade anotada com @Id (linha 73) para indicar sua unicidade, as demais propriedades (linhas 79, 85 e 90) podem ter anotaes de mapeamento objeto-relacional e implementao dos mtodos equals() e hasCode() (linha 125). Para complementar as informaes necessrias para a gerao das interfaces, a annotation @PropertyDescriptor (linha 83) do Entities utilizada para indicar que a propriedade password secreta e que o tamanho do componente visual deve ser de 25 caracteres. Para uma aplicao soberana, somente essa implementao das classes de negcio seria suficiente para executar a aplicao. Por exemplo, a Fig. 10 mostra a interface padro do Entities para todas as classes de negcio.
Figura 10. Cadastro de Employees

A interface composta por todos os membros da entidade disposta em um modelo tipo formulrio, onde as aes bsicas dos controladores necessrios para que o usurio possa realizar as operaes CRUD so disponibilizados. Entretanto, em aplicaes transientes necessrio disponibilizar telas para cada tarefa que o usurio pode realizar. No caso da entidade OverTime trs casos de uso foram identificados. Portanto o sistema deve dispor de uma viso especfica e otimizada para cada caso. Nestes casos o desenvolvedor deve utilizar a NOVL e as anotaes @View e @Views (Fig. 11). A viso para o caso de uso RequestOvertime foi definida nas linhas 25 a 30, AuthorizedOvertime nas linhas 31 a 39 e AuthorizePaymentOfOvertime nas linhas 40 a 49.

Figura 9. Classe Employee Figura 11. Classe Overtime

Para que as mudanas de estado do objeto OverTime sejam refletidas no repositrio deve-se anotar os mtodos com @Transaction. (linhas 150, 156, 164, 171 e 182 do cdigo da Fig. 12). A Fig. 13 mostra o caso de uso RequestOvertime onde o colaborador simplesmente informa o perodo da hora extra e a descrio do servio realizado e envia para a superviso. A Fig. 14 mostra a viso do caso de uso Authorize Overtime que lista todas as solicitaes aguardando aprovao (linhas 37-39) para a aprovao ou rejeio do supervisor simplesmente clicando no boto Approve ou Reject de cada solicitao. A Fig. 15 mostra a viso do caso de uso Authorize Payment of Overtime que lista para o responsvel pelo RH todas as solicitaes aprovadas pelos supervisores (linhas 4649) para a aprovao, rejeio ou, no caso de haver alguma dvida, retornar a solicitao para a superviso.

Figura 13. Caso de uso RequestOvertime

Figura 14. Caso de Uso Authorize Overtime

Figura 12. Aes da Classe OverTime

Figura 15. Caso de Uso Authorize Payment

VI.CONCLUSES E TRABALHOS FUTUROS Este artigo apresenta o framework Entities baseado no padro Naked Objects para o desenvolvimento de aplicaes transientes para web atravs da plataforma JEE. Com o framework Entities possvel, dentre outras atividades, beneficiar-se de todas as vantagens oferecidas pelo padro NO em projetos de aplicaes transientes para web. A implementao do padro Naked Objects para lidar adequadamente com sistemas transientes envolveu a criao da linguagem Naked Objects View Language (NOVL), de forma a possibilitar a definio de mltiplas visualizaes customizadas. Com NOVL possvel a codificao direta sem o uso de editores visuais de interfaces. Com isso, o ciclo de aprendizado pode ser reduzido e a manuteno facilitada. A customizao vivel a partir de um conjunto de anotaes (ou metadados) para os objetos do domnio. Desta forma, um dos principais limitadores da utilizao do padro Naked Objects pode ser contornado, sem ferir o padro, pois nem o comportamento nem a forma de armazenamento dos objetos so modificados. Assim, os desenvolvedores continuam focando seus esforos apenas no domnio da aplicao, sem a preocupao de como a interface ser implementada, nem com as tecnologias envolvidas. Podem ser estabelecidos os seguintes trabalhos futuros relacionados ao framework Entities: i) Implementar servios de Restfull Objects, uma tendncia dos demais frameworks NO; ii) Adequar a NOVL para a gerao de relatrios; iii) Introduzir no framework Entities o suporte ao desenvolvimento dirigido pelo domnio, baseando-se nos conceitos estabelecidos pelo Domain-Driven Design (DDD); iv) Criao de uma ferramenta baseada em Model Driven Development (MDD) para gerar as classes de negcio automaticamente, para estas serem utilizadas pelo Entities.

[9] [10] [11] [12] [13] [14]

[15]

[16]

[17] [18] [19] [20] [21] [22] [23]

Jef Raskin, Human Interface, The: New Directions for Designing Interactive Systems.: Addison Wesley, 2000. Marcius Brando, Mariela Corts e nyo Gonalves, Naked Objects View Language, InfoBrasil, 2012. Richard Pawson and Robert Matthews, Naked Objects. New York: Wiley, 2002. Richard Pawson and Robert Matthews, Naked Objects, traduo ed., Osvaldo Kotaro Takai and Joo Eduardo Ferreira, Eds., 2002. Richard Pawson. (2010, Novembro) InfoQ. [Online]. http://www.infoq.com/articles/Nacked-MVC Alan Cooper, Robert Reimann, and David Cronin, About Face 3 - The Essentials of Interaction Design, 3rd ed. Indianapolis, Indiana, United States of America: Wiley Publishing, 2007. Oracle and/or its affiliates. (1998) Java Core Reflection. [Online]. http://docs.oracle.com/javase/1.5.0/docs/guide/reflection/spec/javareflectionTOC.doc.html Erich Gama, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns - Elements of Reusable Object-Oriented Software.: AddisonWesley, 1998. Oracle and/or its affiliates, The Java EE 5 Tutorial., 2010. Martin Fowler, Patterns of Enterprise Application Architecture, 1st ed. Boston, USA: Addison-Wesley Professional, 2003. TIOBE Software. TIOBE Software. [Online]. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Richard Pawson and Robert Matthews, Naked Objects, 1st ed. New York: John Wiley & Sons, 2002, online www.nakedobjects.org/book. Heikki Kernen. (2004, Feb.) Mobile OVM's for Naked Objects. [Online]. http://opensource.erve.vtt.fi/pdaovm/pda-ovm/index.html Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston, MA: Addison Wesley, 2003. Roger S. Pressman, Engenharia de Software, 6th ed., Giselia Costa, Ed. So Paulo, Brasil: McGraw-Hill, 2006.

REFERNCIAS
[1] [2] [3] [4] Richard Pawson, Naked Objects, Phd thesis. Dublin: Trinity College, 2004. Aruna Raja and Devika Lakshmanan, "Naked Objects Framework," International Journal of Computer Applications, vol. I, no. 20, 2010. Richard Pawson. (2008, Dezembro) InforQ. [Online]. http://www.infoq.com/articles/RAD-Naked-Objects Heikki Kernen and Pekka Abrahamsson, "A case study on naked objects in agile software development," Proceedings of the 6th international conference on Extreme Programming and Agile Processes in Software Engineering, no. XP'05, pp. 189-197, 2005, http://dx.doi.org/10.1007/11499053_22. Richard Pawson and Vincent Wade, "Agile Development using Naked Objects," In Proceedings of the 4th international conference on Extreme programming and agile processes in software engineering (XP'03), pp. 97-103, 2003. Heikki Kernen and Pekka Abrahamsson, "Naked Objects versus Traditional Mobile Platform Development:A Comparative Case Study," Proceedings of the 31st EUROMICRO Conference on Software Engineering and Advanced Applications, no. EUROMICRO '05, pp. 274-283, 2005, http://dx.doi.org/10.1109/EUROMICRO.2005.42. Richard Pawson and Robert Matthews, "Naked objects: a technique for designing more expressive systems," ACM SIGPLAN Notices, vol. 36, no. 12, 2001. Dan Haywood, Domain-Driven Design using Naked Objects, Susannah Davidson Pfalzer, Ed. USA: Pragmatic Bookshelf, 2009.

[5]

[6]

[7]

[8]