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

Mesmo com a contínua popularidade de metodologias ágeis de desenvolvimento, a modelagem continua a ser uma prática valiosa em várias organizações. A modelagem ajuda a pensar em um projeto complexo e compartilhar visualmente sua abordagem. Com modelos de desenvolvimento no lado do cliente ou com base no navegador na linha principal, era preciso uma nova visão da modelagem para garantir que a abordagem acompanharia a tecnologia em evolução. Este conteúdo é parte do IBM WebSphere Developer Technical Journal.

Anthony Bernal, Executive IT Specialist, IBM

Anthony (Joey) Bernal é IT Specialist Executivo no IBM Software Group, Industry Solutions Development. Ele tem um extenso histórico no projeto e desenvolvimento de aplicativos do WebSphere e WebSphere Portal. 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.


nível de autor Profissional do
        developerWorks

13/Jan/2011

A beleza da modelagem

Recentemente, estive pensando sobre e desenvolvendo vários modelos. Muitos me conhecem como uma pessoa de portal, mas recentemente assumi uma nova função na equipe de desenvolvimento do Software Group Industry Solutions, trabalhando com a iniciativa Intelligent Cities da IBM. A solução que estamos desenvolvendo reúne alguns dos melhores produtos e soluções dentro da IBM e é nosso trabalho uni-las de forma que permitam que executivos municipais e gerentes de departamento identifiquem e coordenem atividades e eventos em todos os domínios e departamentos específicos que compõem o domínio de uma cidade. Como se pode imaginar, essa é uma tarefa e tanto e a única forma de entender a complexidade deste tipo de ambiente é por meio do uso de 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
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
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

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere, Lotus
ArticleID=608066
ArticleTitle=Linhas de comentário: Revisão de padrões de portal
publish-date=01132011