Conceito:
|
Atividades durante o ciclo de vida: |
Conceitos:
Artigo: |
Criar aplicativos de comércio eletrônico significa criar soluções de Internet para implementar processos de negócios. Isso inclui o e-commerce, mas estende-se a todos os processos de negócios em toda uma organização.
Os sistemas de comércio eletrônico podem ser divididos em:
Quanto mais avançada a geração dos sistemas, mais complexo é seu desenvolvimento.
O workflow básico para a Fase de Iniciação é aplicável, com as extensões ou variações a seguir.
Isso tem menor destaque.
Esse requer menor destaque. A maior parte das necessidades dos envolvidos deve ter sido descoberta durante a modelagem de negócios. Contudo, será necessário fazer alguns exercícios que tenham como objetivo descobrir requisitos não funcionais no sistema.
Esse requer menor destaque. O limite do sistema é definido pelo limite do negócio, uma vez que o sistema reflete o negócio de modo mais fiel que os aplicativos tradicionais (em alguns aspectos, o sistema é o negócio).
A Atividade: Projetar a Interface com o Usuário produz um Mapa de Navegação. Um Mapa de Navegação é uma visualização da solução da Web que mostra como os usuários do site navegarão nele, possivelmente representada em um diagrama hierárquico em "árvore". Cada nível do diagrama mostra o número de cliques necessários para chegar a uma determinada tela ou página. Em geral, deseja-se, com apenas um clique, ir da primeira página (normalmente conhecida como "home page") até as áreas mais importantes do Web site. O Mapa de Navegação é efetivamente um resumo dos Esboços Seqüenciais, que inicia identificando as principais janelas ou páginas da Web para cada Caso de Uso e considera como o usuário navega entre estes elementos.
O workflow básico para a Fase de Elaboração é aplicável, com as extensões ou variações a seguir.
A Atividade: Análise Arquitetural aproveita a vantagem do conhecimento de que um aplicativo da Web tem uma arquitetura relativamente bem definida, inclusive um conjunto de mecanismos bem definidos (navegadores da Web, applets e servlets Java, ASPs e JSPs etc.). Geralmente uma estrutura em camadas simples, conforme descrito em Conceitos: Divisão em Camadas, é suficiente, a menos que a estrutura de desenvolvimento de aplicativos da Web seja mais específica. Em muitos casos, pode haver arquiteturas predefinidas que podem ser adquiridas prontas ou reutilizadas a partir de projetos de desenvolvimento de Web anteriores. Alguns frameworks de aplicativos da Web, como WebSphere da IBM ou Windows DNA da Microsoft, fornecem esse tipo de modelo arquitetural.
Aplicativos da Web, em geral, não possuem tempo de inatividade programado. A arquitetura pode permitir (e normalmente o faz) a atualização do sistema durante sua execução e a comutação para servidores de reserva durante falhas do servidor principal ou na ocorrência de manutenção ou atualizações do servidor. Alguns frameworks de aplicativos da Web fornecem ferramentas para o suporte à produção. Apesar disso, se o aplicativo requisitar alta disponibilidade, será necessário planejar a compra ou a criação da infra-estrutura necessária para suportar esse requisito e para integrar o suporte dessa capacidade na arquitetura.
A Atividade: Projetar a Interface com o Usuário é executada iterativamente nas iterações de Elaboração. O foco das execuções anteriores dessa atividade é a produção de 'amostras de design criativo', que são representações em maquetes do design das principais páginas da Web no site. Geralmente, essas 'amostras' são figuras "planas" graficamente enquadradas como a janela do navegador para que se pareçam com ela. A principal vantagem das 'amostras' é adiar o investimento em protótipos HTML mais elaborados e caros até que haja um consenso sobre a orientação gráfica específica do site.
As 'Amostras de Design Criativo' são criadas observando-se os requisitos de interface dos Casos de Uso mais importantes e desenvolvendo-se vários designs alternativos (talvez 10 ou mais) para a aparência e o comportamento. A partir desse conjunto, são escolhidas as três opções mais promissoras para apresentação aos envolvidos. Isso é feito de forma iterativa até que haja um acordo sobre o design da Web final, resultando em um conjunto de Esboços Seqüenciais e um Mapa de Navegação.
Após o acordo e a aprovação, as amostras de design criativo evoluem para um Protótipo de Interface com o Usuário funcional por meio da repetição da Atividade: Criar Protótipo da Interface com o Usuário. O Protótipo de UI da Web Inicial suporta, normalmente, apenas partes do sistema, os casos de uso mais importantes e arquiteturalmente significativos. É importante estruturar bem o fluxo de eventos do Caso de Uso antes de desenvolver protótipos, para assegurar que a funcionalidade controle o layout da interface com o usuário e não o contrário.
Em iterações subseqüentes, o protótipo da Web é expandido, ampliando-se gradualmente a abrangência dos casos de uso e o emprego maior da arquitetura.
A Atividade: Análise de Caso de Uso é relativamente inalterável, exceto pelo fato de ser importante ter o foco não apenas no comportamento da GUI, mas também ma lógica de negócios subjacente - a parte que normalmente será executada no servidor da Web ou no servidor de aplicativos. Se esse detalhe for esquecido, a parte mais significativa do comportamento do sistema será negligenciada. As próprias páginas da Web são representadas como classes 'fronteira', elementos de dados são representados como classes de 'entidade' e o comportamento no servidor (por exemplo, páginas do servidor ativo, servlets, etc.) é representado por meio de objetos de 'controle'.
Imediatamente após a análise de caso de uso, a Atividade: Identificar Elementos de Design refina o Artefato: Classes de Análise, mapeando-as para mecanismos existentes na estrutura de desenvolvimento da Web, reutilizando os elementos de design existentes de projetos anteriores ou da iteração, onde possível. Isso, muitas vezes, requer o reajuste do escopo e a definição das classes de análise identificadas para alcançar o grau de reutilização desejado.
Uma descrição mais detalhada do uso de UML para descrever aplicativos da Web é apresentada em Modelando Arquiteturas de Aplicativo da Web com UML.
Além de desenvolver diretrizes da interface com o usuário, os elementos de design da Web - as imagens gráficas separadas que são montadas para construir as páginas da Web para um site - são criados. A consistência da interface do usuário por todo o site da Web é essencial para a usabilidade; o site da Web deve proporcionar uma experiência consistente para o usuário. Para assegurar isso, o projeto deve utilizar de forma consistente um conjunto de elementos gráficos padrão em todo o site.
O desenvolvimento desses elementos inclui a criação de diretrizes para seu uso. Assegure-se de que todos os membros da equipe entendam quando e como utilizar esses elementos. Exemplo de elementos de design da Web incluem elementos gráficos como, por exemplo, dispositivos de navegação e planos de fundo de página. A reutilização de elementos gráficos padrão de alta qualidade em todo o site assegura consistência, reduz o tempo para comercialização e reduz o custo de desenvolvimento, assim como aumenta a qualidade por meio da implementação de um conjunto menor de elementos de alta qualidade.
A preparação de diretrizes é feita em conjunto com o desenvolvimento do Protótipo da Interface com o Usuário da Web inicial para produzir o guia de estilo para o site. Esse guia de estilo irá, entre outras coisas, especificar como e quando os elementos de design da Web devem ser utilizados, esquemas de cores, fontes, folhas de estilo em cascata e detalhes sobre como elementos de navegação devem funcionar e ser posicionados.
A Atividade: Identificar Mecanismos de Design passa a ter mais foco no mapeamento dos requisitos não funcionais do sistema para os mecanismos fornecidos pela estrutura de desenvolvimento da Web; os mecanismos não fornecidos pela estrutura (se existir) precisarão ser identificados e encontradas soluções alternativas.
A Atividade: Descrever a Arquitetura de Tempo de Execução passa a ter mais foco principalmente nas camadas do servidor Web e do servidor de aplicativos (consulte Conceitos: Padrões de Distribuição) e nos processos e encadeamentos utilizados para gerenciar a simultaneidade no aplicativo. Normalmente, há pouco ou nenhum controle sobre o processamento nas máquinas do cliente.
A Atividade: Descrever Distribuição altera o foco de decidir 'que tipos de nós de servidor deve-se ter' para 'ter quantos nós de servidor de cada tipo'. Em geral, o framework de desenvolvimento da Web fornecerá um número fixo de tipos de servidor (por exemplo, servidores da Web, servidores de aplicativo, servidores de correio eletrônico, servidores de gateway de comunicação) com fronteiras funcionais relativamente bem definidas. A habilidade do arquiteto de software, como resultado, será concentrada em determinar como lidar com os requisitos de capacidade de ajuste e de tolerância a falhas, usando os tipos de servidor disponíveis, normalmente por meio da determinação de quantos servidores de cada tipo são necessários. Além disso, precisam ser elaborados planos de métricas para determinar como saber em que momento são necessários servidores adicionais.
O planejamento destaca, de forma ampla, o teste de desempenho para garantir que o aplicativo da Web possa suportar aumentos significativos do número de usuários simultâneos.
Como resultado, os Detalhes do Workflow de Teste,
Testar
e Avaliar,
Realizar
Missão Aceitável também terão foco mais sobre o teste de desempenho, para assegurar
que a arquitetura seja escalável.
Outros tipos
importantes de teste são o teste
de desempenho e o
teste de
estrutura. É necessário testar a interação com o usuário para verificar se
a estrutura do aplicativo da Web é adequada aos usuários. Em alguns casos, você é forçado a colocar o aplicativo na Internet, para poder monitorar como os usuários estão usando o aplicativo.
Outro tipo de teste que consome muito tempo é o teste de navegação, já que a compatibilidade entre navegadores muitas vezes limita as opções de design na interface do usuário.
Para validar as decisões arquiteturais tomadas até o momento no projeto, um ou mais protótipos arquiteturais são desenvolvidos e testados, envolvendo a execução sucessiva de Detalhe do Workflow: Implementar Componentes, Detalhe do Workflow: Integrar Cada Subsistema e Detalhe do Workflow: Integrar o Sistema. O teste, como mencionado acima, deve destacar especialmente a capacidade de ajuste do aplicativo aos aumentos imprevisíveis de carga no sistema.
O workflow básico para a Fase de Construção é aplicável, com as extensões ou variações a seguir.
Atividade: Planejar a Integração do Subsistema e Atividade: Planejar a Integração do Sistema precisam tratar dos diferentes tipos de elementos de implementação criados na fase de construção.
A Atividade: Implementar Elementos de Design tem como foco os diferentes tipos de elementos:
- Páginas da Web, applets, scripts, gráficos e outros elementos que são "executados" no ambiente do navegador
- Páginas do lado do servidor, scripts, servlets e outros elementos que são "executados" no ambiente do servidor Web
- Aprimoramentos do código executável para aplicativos legados
- Tabelas de banco de dados, triggers, procedimentos armazenados e outros elementos executados no sistema de gerenciamento do banco de dados
As diferenças nas ferramentas e nas tecnologias de implementação entre os diferentes tipos de elementos significam que haverá um número semelhante de variações na Atividade: Implementar Elementos de Design. Haverá adaptações semelhantes no Detalhe do Workflow: Integrar Cada Subsistema e Detalhe do Workflow: Integrar o Sistema.
O planejamento de teste continua a destacar o testes de desempenho, mas com ênfase no teste funcional.
Uma abordagem de teste ligeiramente diferente
é necessária para cada um dos tipos diferentes de elementos que compreendem um
aplicativo da Web. Haverá adaptações semelhantes nos Detalhes do Workflow de
Teste,
Testar e Avaliar,
Alcançar Missão Aceitável
, nos quais o foco desloca-se cada vez mais do teste
com foco no desempenho arquitetural para o teste funcional, assegurando que os
detalhes do comportamento do sistema estejam corretos.
Partes desta página são desenvolvidas em cooperação com a Context Integration. | ![]() |
Rational Unified Process
|