Linhas de comentário: revisão de padrões de portal

A beleza da modelagem

Por que
usamos modelos? Acho que usamos modelos principalmente porque eles são mais
rápidos e mais baratos do que tentar desenvolver a solução final diretamente.
Com um modelo, é possível pensar sobre a solução e evoluí-la sem codificar
cegamente, o que frequentemente acontece em grandes projetos.

Em 2002 e
2003, escrevi uma série de artigos sobre Modelagem de portlets do WebSphere
Portal com UML. Naquele
momento, havia muito pouca informação nessa área e o desafio de muitas pessoas
no campo era descobrir padrões reutilizáveis para desenvolvedores de portlets.

Felizmente,
fomos capazes de aproveitar a experiência no campo para desenvolver aplicativos
de portal. Isso levou a tentativas bem-sucedidas de formalizar nossa abordagem
de uma forma reutilizável, o que sempre foi o objetivo:

Formar um conjunto de
padrões reutilizáveis, seja usando modelos, padrões de projeto ou até
mesmo código encapsulado dentro de uma API.
Aprenda com sua experiência,
não reinvente a roda e diminua seu tempo e esforço de desenvolvimento o
máximo possível.

No momento
em que foram escritos, aqueles artigos originais sobre tecnologia JSP e
processamento do lado do servidor forneceram a abordagem preferencial: usar um
arquivo JPS para gerar HTML e enviá-lo para o navegador.

A maioria
das interações era realizada no servidor com pouco código do lado do cliente,
exceto, talvez, por alguns formulários simples de validação ou verificação de
erros.

O JavaScript
havia perdido muito de sua popularidade dos anos 90, quando as guerras entre
navegadores criaram muita confusão na vida dos desenvolvedores.

O retorno do desenvolvimento do lado do cliente

Desde então,
o desenvolvimento do lado do cliente voltou para se vingar. A IBM fez um
investimento substancial na biblioteca Dojo JavaScript e liderou o caminho das
especificações de desenvolvimento para a tecnologia iWidget.

A agregação
do lado do servidor na página do portal permite que ele interaja com o usuário
com uma necessidade bastante reduzida de atualizações de página.

Muita desta
interação do lado do cliente foi desenvolvida com inúmeros serviços REST com
transferência contínua de JSON e XML para a página sob demanda.

Quando
bem-implementada, esta abordagem de arquitetura pode fornecer uma experiência
interativa eficiente para o usuário que é, ao mesmo tempo, funcional e
esteticamente agradável.

Abordagem de modelagem do lado do cliente

Devo admitir
que isso foi uma luta. Pensar sobre como estender diagramas UML tradicionais
para incluir um paradigma do lado do cliente não parecia natural.

Pode ter
sido uma resistência natural contra o JavaScript como linguagem de primeira
classe, mas não acho que tenha sido este o caso. Acho que foi somente a
evolução pela qual alguns de nós precisam passar ao tentar aplicar uma nova
abordagem a técnicas existentes.

A ideia de o
JavaScript ser uma plataforma de desenvolvimento de primeira classe já acabou.
Bibliotecas como Dojo agora podem fornecer, de maneira completa, recursos
robustos entre navegadores para rivalizar com muitas outras abordagens.

A meta é
estender os modelos para o navegador. Isso é especialmente verdade para modelos
do tipo UML, muitos dos quais fornecem (intencionalmente) representações muito
simplistas de um ponto de vista particular do sistema.

Quando
comecei a tratar o navegador como outro componente no sistema, os modelos
pareceram se encaixar.

De uma forma
que não foi surpreendente, quando estava procurando pela coisa certa, encontrei
um artigo de Jim Conallen sobre Modelando Arquiteturas de Aplicativos da Web em
UML que descreve a mesma abordagem.

Estendendo diagramas de sequência

Com
aplicativos Web 2.0, diagramas de sequência podem ser uma das visualizações
mais importantes do sistema que podem ser fornecidas.

Páginas da
Web que realizam muito processamento do lado do cliente podem exigir muita
transferência de dados quando a página busca informações no servidor.

Esse é um
padrão muito comum usado para fornecer um senso de reação instantânea a alguma
ação realizada pelo usuário.

Por exemplo,
preencher uma caixa de procura poderá resultar na atualização contínua de uma
parte da tela, como tentativa de identificar o que o usuário está buscando.

Aplicativos
Dojo que conversam com serviços REST complementares precisam ser modelados em
algum detalhe, de forma que os desenvolvedores entendam quais serviços são
necessários ou, talvez, quais serviços já existem.

A Figura 1
ilustra como é possível modelar esse tipo de comportamento estendendo a
sequência para incluir a interação da página da Web com serviços de backend
existentes.

Tradicionalmente,
é possível simplesmente devolver o HTML para o usuário com base em um pedido,
mas, neste caso, e exceto para o carregamento inicial, a página da Web em si
inicia muitas das interações com componentes e serviços do lado do servidor.

Figura 1. Sequência com interação do lado do
cliente

Para todos os modelos, é importante fazer uso massivo de
estereótipos para garantir que seja possível identificar componentes de
tecnologias diferentes. De fato, o uso de estereótipos é o que torna o UML tão
flexível em sua capacidade de se manter atual à medida que a tecnologia evolui
no decorrer dos anos (ou, neste caso, décadas).

Páginas da Web como
classes

No diagrama de classes mostrado na Figura 2, muitos dos
recursos que anteriormente estariam no controlador ou nas classes de
assistentes, agora são levados para a página da Web.

Neste caso, é possível tratar a página da Web como um objeto
de classe padrão, com atributos e métodos similares àqueles de uma classe Java.

Este tipo de abordagem mescla-se bem com o JavaScript porque
a maioria dos esforços de desenvolvimento é encapsulada em funções.

Figura 2. Modelando
bibliotecas JavaScript

Com a camada do cliente agora adequadamente dentro da
arquitetura, começar a incluir dependências em componentes adicionais do lado
do cliente se torna uma simples etapa.

Bibliotecas JavaScript, sejam existentes ou que precisem ser
desenvolvidas, podem ser mapeadas dentro do projeto.

Ao usar uma estrutura como Dojo, essa abordagem pode ser
usada para mostrar quaisquer widgets personalizados que tenham que ser criados
para seu aplicativo.

Conclusão

De fato, esses exemplos são muito
simples, mas espero que tenham deixado a questão clara e fornecido um ponto de
partida para pensar sobre seus próprios requisitos de modelagem.

Nem todos os modelos são diagramas de UML e,
algumas vezes, visuais, como uma estrutura de conexão ou diagrama Visio, podem
transmitir mais informações ao leitor do que UML.

Nesse caso, pode ser útil ter o
visual certo capturando corretamente a interação da página. Scott Wilson
fornece alguns estênceis de mashup excelentes para diagramas Visio
que podem adicionar algum poder a esses tipos de diagramas.

Espero que essas ideias sejam
úteis quando você começar a pensar sobre como poderá modelar seus aplicativos e
portlets que tenham como foco interações do lado do cliente.

Aproveite!

Recursos

***

Artigo publicado originalmente no developerWorks Brasil, por Anthony (Joey) Bernal

Anthony
(Joey) Bernal
é IT Specialist Executivo no IBM Software Group, Industry Solutions
Development. Ele é um autor profissional do developerWorks e autor ou
coautor de vários livros, incluindo Web 2.0 and Social Networking
for the Enterprise, Application Architecture for
WebSphere, Programming Portletse
vários outros. Atualmente, ele está ajudando a construir um planeta mais
inteligente trabalhando no Intelligent Cities Operations Center da IBM.

De 0 a 10, o quanto você recomendaria este artigo para um amigo?