Naked Objects View Language

Naked Objects View Language
Marcius Gomes Brandão1, Mariela Ines Cortés1, Enyo J. T. Gonçalves 2
Abstract— A critical constraint to the use of the Naked
Objects architectural pattern is the automatic generation of a
single generic user interface. For many developers and users,
this restriction prevents the use of frameworks based on this
archetype. This article presents the Naked Objects View
Language, a language for customization of user interfaces that
uses the Naked Objects. The biggest benefit of this language is
the ability to define multiple views for the same naked object,
regardless of the platform used and maintaining the
characteristics of the pattern.
Resumo— Uma restrição crítica ao uso do padrão
arquitetural Naked Objects reside na geração automática de
uma única interface genérica de usuário. Para muitos
desenvolvedores e usuários essa restrição impede a utilização
de frameworks baseados em tal arquétipo. Este artigo
apresenta a Naked Objects View Language, uma linguagem
para a customização das interfaces de usuários que utiliza o
padrão Naked Objects. O maior benefício dessa linguagem é a
possibilidade de definir múltiplas visões para o mesmo naked
object, independentemente da plataforma utilizada e mantendo
as características do padrão.
Index Terms— Naked Objects; User Interface; Frameworks;
Object-oriented programming.
I. INTRODUÇÃO
C
om a crescente demanda por sistemas desenvolvidos
utilizando linguagens de programação orientadas a
objeto, há necessidade de implementação da „completeza
comportamental‟ por estes sistemas [1], de modo que um
objeto modele completamente o comportamento do que ele
se propõe a representar [2].
Naked Objects (NO) [3] é uma abordagem de
desenvolvimento de sistemas em que o núcleo dos objetos
de negócio é mostrado diretamente na interface do usuário e
todas as interações consistem em invocar os métodos desses
objetos. As vantagens dessa abordagem são (i) um rápido
ciclo de desenvolvimento; (ii) grande agilidade; (iii) fácil
análise de requisitos e (iv) uma interface de usuário mais
poderosa, pois tratam o usuário como um solucionador de
problemas e não como um seguidor de processo [3][4].
Embora o principal caso de sucesso do Naked Objects
tenha sido um aplicativo de missão-crítica de 1500 usuários
para um departamento do Governo irlandês, onde a interface
não-personalizável funciona perfeitamente bem, esta mesma
interface não-personalizável é um dos maiores fatores que
limitou a aplicabilidade do padrão Naked Objects em outros
domínios [5]. Outra desvantagem é o mapeamento 1:1 entre
o modelo e a visão, ou seja, para cada objeto do modelo
tem-se uma única interface gráfica.
Este artigo apresenta uma abordagem de customização da
[email protected], [email protected], [email protected]
1
Mestrado Acadêmico em Ciência da Computação - Universidade
Estadual do Ceará
2
Universidade Federal do Ceará
interface de usuário a partir de uma linguagem definida no
próprio modelo de negócio através de meta informações. O
artigo está organizado como segue: na Seção II, os trabalhos
relacionados são apresentados. Na Seção III é apresentado o
referencial teórico em relação aos padrões Naked Objects e
MVC, a notação EBNF e diagramas de sintaxe utilizados na
criação da linguagem e a técnica de design Layout Grid. Na
Seção IV é apresentada a Naked Objects View Language
(NOVL). Na Seção V é ilustrado um estudo de caso. E por
fim, na Seção VI, são apresentadas as conclusões e
sugestões para trabalhos futuros.
II. TRABALHOS RELACIONADOS
Vários frameworks têm sido implementados com a
proposta do padrão Naked Objects, no entanto praticamente
nenhum deles oferece suporte adequado à customização do
layout da interface do usuário de forma consistente com o
referido padrão.
Naked Objects Framework (NOF) [6] é a primeira
implementação do padrão, liderado pelo próprio autor do
arquétipo, Richard Pawson. As versões iniciais escritas em
Java 1.1 não permitiam nenhum tipo de personalização da
interface genérica do usuário. Só em 2010, quando foi
lançada a nova versão „Naked Objects MVC‟, agora
proprietário e para a plataforma dotNET, foi possível a
customização da interface [5]. Entretanto estas
personalizações são baseadas em código CSS e HTML que,
além de espalhar as características visuais do modelo entre as
camadas da aplicação, cria um nível de acoplamento muito
alto com a plataforma web, dificultando, por exemplo, a
reutilização do modelo em outra plataforma, como desktop.
Apache ISIS [7] está sendo desenvolvido para a
plataforma Java como alternativa gratuita ao Naked Objects
MVC para dotNET e é liderado por Dan Haywood (exintegrante do projeto original NOF) e pretende gerar
aplicações que sejam executáveis tanto na plataforma web
quanto para desktop. O projeto ainda está em
desenvolvimento e a documentação atual não explicita a
forma de customização das interfaces, mas deixa claro que
dependerá da plataforma de execução.
Domain Object Explorer [8] permite a customização dos
controles de interfaces do usuário para as propriedades do
objeto de domínio (rótulo, ordem de apresentação, tamanho,
etc.). Entretanto uma customização completa é realizada por
meio de uma ferramenta externa que gera arquivos xml ou
jfrm ou por código Java baseando na API (Application
Programming Interface) Swing [9], uma biblioteca contendo
diversos componentes que permitem a criação de interfaces
gráficas de usuários (GUI) para desktop. Em ambos os casos
os artefatos gerados devem ser anexados ao projeto na
mesma pasta e nome da classe de negócio.
JMatter [10] é um framework proprietário e tem seu
principal mecanismo de geração de interfaces do usuário
baseado em Swing. As customizações de GUI do JMatter
podem ser em arquivos XML complementados com
sobreposição de códigos em classes do framework ou pela
construção completa da GUI através de código baseado na
API Swing mais sobreposição de código e implementação
de interfaces do framework [11].
Independente da forma de customização todas as
alternativas apresentadas, além de aumentarem o nível de
acoplamento com a tecnologia utilizada, quebram um dos
princípios básicos do Naked Objects Pattern (NOP) que é a
geração automática das interfaces totalmente baseada na
definição dos objetos de domínio[1][3], tirando o foco do
desenvolvimento para as demais camadas da aplicação.
Todos eles também estão atrelados à idéia da geração de
uma única GUI para cada objeto de domínio. Outros
frameworks como dotObjects [12], Sanssouci [13] e Trails
[14] não apresentam documentação e nenhum indicativo se
o projeto está ativo ou não.
completos, pois este modelo promove a separação continua
entre dados e procedimentos [3].
Figura 1 - Arquitetura padrão em 4-camadas [3]
No padrão Naked Objects as funções de visualização e
controlador (como originalmente definidas no MVC) são
completamente genéricas e, por tanto, não há nenhum outro
lugar para por as regras de negócios exceto nas entidades do
domínio (ou seja, no modelo), promovendo assim a
modelagem de objetos com completude comportamental [3].
III. REFERENCIAL TEÓRICO
Nesta seção são apresentados, de maneira sucinta, os
padrões Naked Objects e MVC, bem como o design Layout
Grid, que formam a base conceitual e técnica utilizadas para
elaboração da linguagem NOVL. Também é apresentada a
notação EBNF e Diagrama de Sintaxe utilizados na
definição formal da linguagem para a compreensão de
compiladores e desenvolvedores, respectivamente.
A. Naked Objects Pattern (NOP)
O conceito básico por trás do Naked Objects é que, ao
escrever um aplicativo de negócios, o desenvolvedor deve
criar apenas os naked objects (os objetos de negócio que
modelam o domínio [2][15]) e as suas respectivas lógicas de
negócio encapsuladas. O framework que utilizar a
tecnologia se encarrega de disponibilizar, a partir dos
objetos de negócio, a aplicação com interface gráfica,
persistência e gerenciamento desses objetos. Além de
eliminar a necessidade de escrever uma camada de interface
do usuário e a camada de acesso a dados, o padrão Naked
Objects também facilita uma boa modelagem dos objetos porque o protótipo do modelo de domínio é transformado
diretamente em um aplicativo que pode ser avaliado pelos
usuários de negócios [16].
Os três princípios do NOP são: (i) toda a lógica de negócio
deve ser encapsulada nos objetos de domínio, (ii) a interface
de usuário deve refletir completamente os objetos de
domínio, incluindo todas as ações do usuário, como criar e
recuperar os objetos de domínio e (iii) a criação da interface
de usuário deve ser inteiramente automatizada a partir dos
objetos de domínio [1][2].
O padrão arquitetural Naked Objects surgiu como uma
alternativa ao padrão 4-camadas (Figura 1). Neste padrão,
um simples conceito de negócio (por exemplo, um Cliente)
será normalmente representado em todas as quatro camadas,
em diferentes formas. Além disso, como indicado no
diagrama, as relações entre os elementos nessas quatro
camadas muitas vezes exigem um mapeamento complexo
(muitos-para-muitos). Embora cada uma das camadas possa
ser orientada a objeto em um certo sentido, está muito longe
do princípio original de objetos comportalmentalmente
Figura 2 - Arquitetura com Naked Objects [3]
B. O padrão MVC
O padrão Model-View-Controller (MVC) [5] é amplamente
utilizado tanto pela indústria quanto pelo meio acadêmico.
Utilizado para separação das atribuições, permite que objetos
de modelo (Model) se preocupem apenas com recursos de
negócios de modelagem, não com a forma como serão
apresentados para o usuário (View) e nem com a captura ou
resposta às entradas do usuário (Controller).
MVC separa as visões e modelos através do
estabelecimento de um protocolo de inscrição/notificação
entre eles. Uma visão deve assegurar que sua aparência
reflete o estado do modelo e o modelo, sempre que é
modificado, notifica as visões que dependem dele. Essa
abordagem permite criar e adicionar vários modos de
exibição para um modelo sem reescrevê-lo [17].
O diagrama a seguir mostra um modelo com três modos de
exibição. O modelo contém alguns valores de dados e os
modos de exibição em forma de planilha, histograma e
gráfico de pizza exibem esses dados de várias maneiras [17].
Figura 3 – Exemplo de três visões do mesmo modelo [17]
C. Layout Grid
O alinhamento de elementos visuais é uma das principais
maneiras que projetistas podem ajudar os usuários a
experimentar um produto de uma forma organizada e
sistemática. Textos, controles e grupos de controles devem
ser alinhados horizontal e verticalmente (ver Figura 4). Em
geral, todos os elementos na tela devem ser alinhados com
tantos outros elementos quanto possível. A decisão de não
alinhar dois elementos ou grupos de elementos deve ser feita
criteriosamente e sempre para obter um efeito específico de
diferenciação [18].
para EBNF. Diagramas de sintaxe são mais facilmente
compreendidos pela maioria das pessoas, uma vez que
permitem a exposição concisa e lúcida de uma sintaxe de
forma rigorosa, porém amigável. A regra básica para a
interpretação de um diagrama de sintaxe é que qualquer
caminho traçado junto às direções diante das setas produzirá
um comando sintaticamente válido. A Figura 5 exibe o
digrama de sintaxe equivalente à notação EBNF do arquivo
XML:
Figura 5 - Diagrama de Sintaxe para arquivos XML
O conteúdo dentro das caixas de vértices arredondados
deve aparecer literalmente no comando, enquanto o
conteúdo das caixas retangulares indica o tipo de
informação a ser escrita.
IV. NAKED OBJECTS VIEW LANGUAGE (NOVL)
Figura 4 - Adobe Lightroom: uso eficaz de alinhamento em
uma grade de layout[18]
Um esquema em grade é uma das mais poderosas
ferramentas disponíveis para o projetista visual.
Popularizada por tipógrafos suíços após a Segunda Guerra
Mundial, o uso de uma grade fornece uma estrutura uniforme
e consistente para um layout, que é particularmente
importante durante a criação de uma interface com vários
níveis de complexidade visual ou funcional. A utilização de
um sistema de grade no projeto de interface visual fornece
vários benefícios como usabilidade, apelo estético e
eficiência. Uma grade bem projetada melhora a legibilidade
da tela, cria uma sensação de ordem e deixa o usuário
confortável e predisposto a interagir com o produto.
D. EBNF e Diagramas de Sintaxe
Componentes gerais de uma linguagem de programação
são a sua sintaxe e a sua semântica. A sintaxe de uma
linguagem influencia na maneira como os programas são
escritos pelos programadores, lidos por outros
programadores e reconhecidos pelo computador. A
semântica de uma linguagem determina como os programas
são resolvidos pelos programadores, entendidos por outros
programadores e interpretados pelo computador [19].
A Extended Backus–Naur Form [20] é uma metalinguagem utilizada para expressar e definir de maneira
formal e matematicamente a sintaxe de uma linguagem não
apenas de programação de computador, mas para definições
formais. A maioria dos padrões de linguagem de
programação usa alguma variante da EBNF para definir a
gramática da língua, possibilitando a construção de
compiladores porque o analisador para o compilador pode
ser gerado automaticamente com um compilador de
compilador como YACC[21].
Por exemplo, a seguinte notação define a sintaxe de um
arquivo XML:
XML::= "<" tag ">" ( XML+ | dado )? "</" tag ">"
A partir desta definição é possível gerar automaticamente o
diagrama de sintaxe [19][22] que é uma alternativa gráfica
Naked Objects View Language ou NOVL é uma
linguagem de descrição de layout para o padrão Naked
Objects. Seu objetivo é de personalizar as interfaces de
usuário de forma simples e rápida utilizando texto simples
no lugar de estruturas mais sofisticadas como SWING, CSS,
XML, HTML, etc., e sem a necessidade de um editor
gráfico de interface ou ferramentas externas.
NOVL se diferencia de outras linguagens de interface no
sentido em que ela especifica a forma da interface e não o
caminho para chegar a ela. Isto reduz o ciclo de aprendizado
daqueles que se iniciam na linguagem.
A NOVL é baseada no uso de layout grid [18] para dividir
o espaço da tela, onde uma grade alinha e organiza
diferentes tipos de elementos inter-relacionados. Desta
forma, a idéia é dividir a interface em linhas e colunas
flexíveis e alinhar os componentes nas células da grade
retangular que formam a tela, permitindo que cada
componente ocupe uma ou mais células.
As próximas subseções definem e detalham a NOVL.
A. Definição formal da NOVL
Para que os frameworks possam validar a sintaxe e
interpretar os comandos da NOVL para gerar a GUI
utilizou-se a meta-linguagem EBNF [20], que define formal
e matematicamente uma linguagem. Na Figura 6 temos a
descrição completa da NOVL em EBNF. A linguagem é
divida em três elementos. (i) view, que define a grade e a
distribuição dos componentes na tela, (ii) component, que
define o tipo de componente que será inserido na grade, e
(iii) member, um subcomponente que define qual e como
uma propriedade ou método de um naked object ou
controlador será apresentado.
Figura 6 – Definição EBNF da NOVL
As próximas subseções descrevem os três elementos da
NOVL utilizando diagramas de sintaxe gerados a partir da
definição EBNF [22].
B. O elemento View
A Figura 7 mostra o diagrama de sintaxe do elemento
view que define a grade do layout da tela. Para distribuir os
componentes em colunas utilizam-se vírgulas {,}, para
indicar que um determinado componente ocupa mais de uma
coluna (colspan) utiliza-se o símbolo dois pontos {:}
seguido da quantidade de colunas como sufixo do
componente. Finalmente, para a distribuição em linhas
utiliza-se o ponto-e-vírgula {;}.
nova grade de duas colunas e duas linhas que ocupará as três
colunas da quarta linha da grade principal.
1
2
3
4
5
componentA:3;
componentB,componentC,componentD;
componentE,componentF:2;
[componentG,componentH;
componentI,componentJ]:3
Figura 9 - Exemplo de um comando NOVL
Embora o rótulo de um componente, principalmente um
member, deva permanecer inalterado para manter a
consistência visual entre as diversas visões, há casos
excepcionais onde se torna necessário modificá-lo. Nestes
casos um novo rótulo, delimitado por aspas simples {‘},
pode ser prefixado ao nome do membro separado por dois
pontos {:}.
D. O elemento member
Um membro é uma propriedade ou método de um naked
object ou controlador (MVC), que será representado por seu
respectivo controle visual na GUI de acordo com o tipo da
propriedade (numérico, data, texto, etc.) e tecnologia utilizada
pelo framework. Sua sintaxe é mostrada na Figura 10.
Figura 7 - Diagrama de sintaxe do elemento View
C. O elemento Component
Um componente pode ser um simples texto (label), um
membro ou uma nova grade, e assim sucessivamente. Para
definir uma nova grade, envolvemos os componentes com
colchetes {[...]}. O diagrama de sintaxe do elemento
component é mostrado na Figura 8.
Figura 8 - Diagrama de Sintaxe do elemento Component
Por exemplo, a Tabela 1 apresenta uma grade que
distribui dez componentes necessários para a formação de
uma determinada GUI.
componentA
componentB
componentC
componentD
componentE
componentF
componentG
componentH
componentI
componentJ
Tabela 1 - Exemplo de estrutura de layout
A Figura 9 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 vírgulas {,} distribuem os
componentes B,C e D pelas três colunas da segunda linha da
grade. Na linha (3), temos a mesma distribuição da linha dois
por vírgulas 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
Figura 10 - Diagrama de sintaxe do elemento Member
Para identificar um membro utiliza-se o nome do membro
em case-sensitive. Para diferenciar visualmente uma
propriedade de um método, estes devem ter dois parênteses
{()} como sufixo e para diferenciar um membro do naked
object de um membro do controlador, estes devem ter o
prefixo {Ctrl.} mais o nome do controlador. Composições
podem ser aninhadas por ponto {.}. Por exemplo:
endereco.cidade.estado.sigla.
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 usuário.
Por exemplo, o comando *modifiedDate indica que o
membro é apenas para exibição na visão.
O suporte a propriedades do tipo coleção ou listas de
objetos é um dos diferenciais da linguagem, pois permite o
projeto de subviews em uma sub-grade com os membros dos
elementos da lista, que por sua vez podem ser outras
coleções, recursivamente. Esta sub-grade é definida
delimitando a subview com os sinais de menor e maior
{<...>} como prefixo da propriedade do tipo coleção.
Em GUIs é comum a utilização de componentes visuais que
se expandem ou se colapsam. Para determinar que um desses
componentes apareça colapsado utiliza-se como sufixo o sinal
de menos {-} e o sinal de mais {+} para expandido.
A Tabela 2 explana todos os elementos da NOVL:
Convenção
A. Interface típica de um framework NOP
Podendo variar de acordo com o framework e tecnologia
utilizados, a Figura 11 mostra um layout típicamente
empregado na maioria dos frameworks que programam o
NOP. Qualquer exibição de outro naked object seguirá o
mesmo modelo. Na tela na figura, gerada pelo NOF-MVC
para o naked object Product, todas as propriedades são
expostas verticalmente. A maioria dos frameworks permite a
definição da ordem em que as propriedades são exibidas. As
ações do naked object são expostas em um menu suspenso
acima da grade principal, e as ações dos controladores abaixo.
Usado para
property
Nome case-sensitive da propriedade do naked
object ou do controlador.
Action
Nome case-sensitive do método do naked
object ou do controlador.
,
Separador de colunas.
;
Separador de linhas.
:colspan
Colspan define quantas colunas o membro deve
ocupar na grade
*
(readonly) O membro sempre será exibido em
modo de
leitura (saída de dados)
incondicionalmente.
#
(writeonly) O membro sempre será exibido em
modo de edição (entrada de dados)
incondicionalmente.
'label'
É um texto simples que será atribuído ao
próximo elemento. No caso de um membro,
substitui o rótulo padrão.
[]
Define uma sub-grade.
+
Indica que o componente deve ser apresentado
inicialmente no modo expandido.
-
Indica que o componente deve ser apresentado
inicialmente no modo recolhido.
<...>
uma possível personalização e a notação equivalente em
NOVL utilizando vários dos recursos da linguagem.
Figura 11 - GUI gerada pelo NOF-MVC
B. Interface personalizada usando NOVL
A apresentação das mesmas informações pode ser
personalizada usando a NOVL. Na Figura 12 é apresentada
uma possível interface para Product. Observe que nesta visão
as propriedades e ações são agrupadas por co-relação.
Propriedades importantes para o usuário ficam em primeiro
plano e as menos importantes em segundo plano ou ocultas.
Delimita uma sub-grade que será apresentada a
partir dos membros do domínio de uma coleção.
Tabela 2 - Convenções da NOVL
No estudo de caso a seguir são apresentandos exemplos
mais detalhados sobre os membros.
V. ESTUDO DE CASO
Nesta seção é apresentado um estudo de caso utilizando o
banco de dados “Adventure Works Sample Database” [23],
que contem, dentre outras informações, dados sobre
produção, vendas e comercialização de uma empresa
multinacional fictícia chamada Adventure Works Cycles que
fabrica e vende bicicletas e seus acessórios. Neste estudo de
caso o foco será na personalização da interface de usuário
do naked object Product. Para fins didáticos, inicialmente
será apresentada uma interface típica dos frameworks, no
caso gerada pelo NOF-MVC, e em seguida será apresentada
Figura 12 - GUI gerada pela NOVL
A grade principal na tela é formada por duas colunas e
duas linhas (em azul), a primeira linha é preenchida por uma
sub-grade 2x4 que ocupa as duas colunas (em amarelo), e na
segunda linha cada coluna é preenchida por uma sub-grade
1x2, e assim sucessivamente (em vermelho).
Baseando-se na estrutura apresentada na Figura 12 , o
código NOVL necessário é detalhado na Figura 13.
sem o uso de editores visuais de interfaces. Com isso, o
ciclo de aprendizado pode ser reduzido, se comparado a
outras tecnologias e a manutenção facilitada.
Como trabalhos futuros é sugerido uma implementação de
referência da linguagem para alguma tecnologia de projeto
de GUI´s como Swing, JSF, HTML, etc., a utilização da
linguagem em algum framework NOP, bem como a
avaliação e extensão da linguagem para abordar outros
aspectos das interfaces gráficas de usuários.
Assim, os desenvolvedores poderão beneficiar-se do uso
de NOVL e suas futuras aplicações para concentrar seus
esforços apenas no domínio da aplicação, sem a
preocupação de como a interface será implementada.
REFERÊNCIAS BIBLIOGRÁFICAS
[1] Aruna Raja and Devika Lakshmanan, "Naked Objects Framework,"
International Journal of Computer Applications, vol. I, no. 20, 2010.
[2] Richard Pawson and Robert Matthews, Naked Objects. New York:
Wiley, 2002.
[3] Richard Pawson, Naked Objects, Phd thesis. Dublin: Trinity College,
2004.
Figura 13 – Código NOVL de customização de Product.
Inicialmente foram definidos quatro agrupamentos
principais: Product (linha 69 a 72), Dates (linha 75 a 78),
Estoque (linha 79 a 86) e Details (linha 91 a 98). Note que
este último deve aparecer no modo colapsado para o usuário
e por isto é sufixado com o sinal de menos.
O primeiro ponto-e-vírgula (linha 73) logo após o
primeiro componente sufixado com {:2} (linhas 69 a 72),
uma sub-grade com rótulo „Product‟, definem a grade
principal em duas colunas e duas linhas e este componente
ocupará as duas colunas da primeira linha, enquanto que na
segunda linha uma subgrade de duas linhas é definida para
cada coluna (linhas 74, 87 a 89 e 99).
Observe que tanto as ações do domínio como as do
controlador podem ser posicionadas livremente em qualquer
parte da visão, de acordo com as necessidades ou gosto dos
usuários (linhas 71,72, 84, 85, 86 e 90). Observe também que
a propriedade photos (linha 90) é do tipo coleção de fotos e
uma subvisão foi criada para exibir os seus membros:a
propriedade largePhoto e o método para adicionar mais
fotos addOrChangePhoto(). Como photos está prefixada com
asterisco o componente visual para este membro deve sempre
estar em modo de leitura, mesmo que a tela mude para o
modo de edição. Photos também teve seu rótulo removido
para evitar uma repetição indesejável com o rótulo do painel.
VI. CONCLUSÕES E TRABALHOS FUTUROS
Este artigo apresenta a Naked Objects View Language,
que possibilita a definição de múltiplas visualizações através
de metadados em cada objeto do domínio. Desta forma
interfaces de usuário personalizadas podem ser
especificadas através da linguagem. Com isso, 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.
Por diferenciar-se de outras linguagens de interface no
sentido em que ela especifica a forma da interface e não o
caminho para chegar a ela, é possível a codificação direta
[4] Richard Pawson and Robert Matthews, "Naked objects: a technique
for designing more expressive systems," ACM SIGPLAN Notices, vol.
36, no. 12, 2001.
[5] Richard
Pawson.
(2010,
Novembro)
http://www.infoq.com/articles/Nacked-MVC
InfoQ.
[Online].
[6] Naked Objects Group. (2010) Naked Objects MVC. [Online].
http://nakedobjects.net
[7] Apache
Isis.
(2010)
Apache
http://incubator.apache.org/isis/index.html
Isis.
[Online].
[8] Domain Object Explorer for JPA / EJB3 entity beans. [Online].
http://java.net/projects/doe/pages/Home
[9] Oracle and/or its affiliates. (2012) The Java Tutorials. [Online].
http://docs.oracle.com/javase/tutorial/ui/overview/intro.html
[10] Jmatter. [Online]. http://jmatter.org/
[11] Eitan Suez, "Customized Views and Editors," in Building Software
Applications with JMATTER.: JMatterSoft LLC, 2009, ch. 14, pp. 171182.
[12] CodePlex
Open
Source
http://dotobjects.codeplex.com/
Community.
[Online].
[13] Free Code. [Online]. http://freecode.com/projects/sanssouci
[14] Trails. [Online]. http://www.trailsframework.org/
[15] Richard Pawson and Robert Matthews, Naked Objects, tradução ed.,
Osvaldo Kotaro Takai and João Eduardo Ferreira, Eds., 2002.
[16] Richard
Pawson.
(2008,
Dezembro)
InforQ.
http://www.infoq.com/articles/RAD-Naked-Objects
[Online].
[17] Erich Gama, Richard Helm, Ralph Johnson, and John Vlissides,
Design Patterns - Elements of Reusable Object-Oriented Software.:
Addison-Wesley, 1998.
[18] Alan Cooper, Robert Reimann, and David Cronin, About Face 3 : The
Essentials of Interaction Design. Indianapolis: Wiley Publishing, Inc.,
2007.
[19] David A. Watt, Programming Language Concepts and Paradigms.:
Prentice Hall, 1990.
[20] ISO/IEC 14977, Information technology—Syntactic metalanguage—
Extended BNF., 1996.
[21] John R. Levine, Tony Mason, and Doug Brown, Lex & Yacc, 2nd ed.,
Dale Dougherty, Ed. United States of America: O'Reilly, 1992.
[22] Gunther Rademacher. (2012, Janeiro) Railroad Diagram Generator.
[Online]. http://railroad.my28msec.com/rr/ui
[23] Microsoft.
MSDN.
[Online].
http://msdn.microsoft.com/enus/library/ms124501%28v=sql.100%29.aspx