Referências

Os livros e documentos a seguir são referências para estas diretrizes:

• Building Web Applications with UML, de Jim Conallen [CONA99]
• The Whitepaper: Modeling Web Application Architectures with UML

Elaboração da Análise de Caso de Uso

A diferença que você encontrará aqui, se comparar com a Tarefa: Análise de Casos de Uso, é que as classes de limite são mais focadas e singulares no propósito. Os objetos dessas classes têm vida curta e qualquer estado do cliente (em páginas da Web) precisa ser gerenciado explicitamente por mecanismos específicos. Por exemplo, o Microsoft Active Server Pages utiliza "cookies" como um índice em um mapa do estado de todos os clientes ativos no momento.

Além disso, quando você lê a especificação de um caso de uso, as seguintes regras se aplicam: 

• Qualquer menção a uma página da Web é convertida em uma classe de fronteira.  
• Qualquer menção a um hyperlink é convertida em associação de uma classe de fronteira para outra classe de fronteira ou para uma classe controladora.  
• Verbos ou descrições de processos tendem a ser mapeados para classes controladoras.  
• Nomes são mapeados para classes de entidade.  

A classe de fronteira, ponto de partida da comunicação, se comunica com uma classe controladora. Geralmente, a classe controladora não responderá através da mesma instância dessa classe de fronteira.

Utilizando Diagramas de Interação

Durante a análise de caso de uso, os cenários podem ser descritos através de diagramas de seqüência. Isso ajudará a validar a existência de objetos de análise em um cenário de caso de uso. Caso descubra-se que os objetos de análise não fazem parte de nenhum dos cenários, eles serão suspeitos e terão de ser reavaliados. O risco aqui é você se aprofundar demais nos detalhes a ponto de os diagramas se tornarem grandes e impossíveis de serem gerenciados. Para evitar que isso aconteça, concentre-se em cenários curtos e distintos. Inclua somente os objetos de fronteira e os objetos controladores e de entidade principais.

Lembre-se de que os objetos de fronteira de aplicativos da Web têm vida útil curta. Uma classe de fronteira pode, todavia, ser instanciada várias vezes durante a execução de um cenário, o que significa que haverá vários objetos de fronteira instanciados a partir da mesma classe do diagrama.

O agente de um diagrama de seqüência em nível de análise interage com um objeto de fronteira. Uma mensagem de navegação é enviada do agente para o objeto de fronteira.

Criando Classes de Design Iniciais

Designs Iniciais de Classe de Fronteira

Uma classe de fronteira pode ser mapeada para uma classe de página cliente.

Se a classe de fronteira implicar em inserir informações, você normalmente a associará a um formulário (ou formulário da Web) através da agregação. Um formulário pode ser modelado como uma classe aninhada da página cliente, já que seu ciclo de vida é administrado por essa página. O relacionamento entre os formulários e uma página de servidor é sempre de submissão. A página de servidor processa os valores do formulário, culminando com o retorno de uma nova página cliente.

Se a interface do usuário exigir um comportamento dinâmico no cliente, a maneira mais fácil de fazer isso será usando a linguagem HTML dinâmica. No modelo de design, isso geralmente aparece como operações na página cliente. Essas operações são mapeadas diretamente para funções Java Script. Os atributos de uma página Java são mapeados diretamente para as variáveis da página que apresentam escopo de página. Os manipuladores de eventos em HTML dinâmica são captados como valores rotulados.

Se a interface do usuário tiver um comportamento muito sofisticado, é recomendável associar um applet à classe de fronteira através de uma agregação.

Se sua arquitetura estiver baseada em um sistema de objeto distribuído (por exemplo, RMI, IIOP ou DCOM), a página cliente poderá fazer referência a interfaces para componentes que se comunicam diretamente com o servidor através de RMI, IIOP ou DCOM, evitando assim o HTTP. Esses tipos de relacionamentos geralmente são estereotipados como <<rmi>>, <<iiop>> ou <<dcom>> para indicar ao designer quaisquer áreas nas quais o tráfego de rede ocorrerá, sendo portanto candidatas a gargalos.

Designs Iniciais de Classe de Entidade

Ao projetar um aplicativo da Web, a única diferença nas classes de entidade é que, se o objeto residir no escopo da página cliente, o objeto de entidade será mapeado para um objeto Java Script.

Designs Iniciais de Classe Controladora

As classes controladoras são mapeadas para páginas servidor. Elas expressam e coordenam a lógica de negócios, além de outras lógicas. Geralmente residem no servidor. Muitos objetos controladores são responsáveis pela criação de páginas cliente (eles usam basicamente a HTML como saída principal). Os objetos controladores podem interagir com recursos do lado do servidor, como bancos de dados, componentes de camada intermediária, monitores de transações e outros. 

Geralmente, as classes controladoras são mapeadas para páginas da Web com script residentes no servidor (páginas do Active Server, páginas servidor Java).