Roteiro: Desenvolvimento de Soluções de Componentes

Tópicos

Introdução

O desenvolvimento baseado em componentes é uma variação do desenvolvimento geral de aplicativos em que:

• O aplicativo é criado a partir de componentes executáveis discretos que são desenvolvidos e implantados com relativa independência entre si, possivelmente por equipes distintas.
• O aplicativo pode ser atualizado em incrementos menores através da atualização de apenas alguns componentes que o compõem.
• Os componentes podem ser compartilhados entre aplicativos, criando oportunidades para reutilização, mas também criando dependências entre os projetos.
• Os aplicativos baseados em componentes tendem a ser distribuídos, apesar de não haver uma relação precisa com o fato de serem baseados em componentes.

A adaptação do Rational Unified Process (RUP) para lidar com esses desafios é discutida abaixo.

Atividades da Fase de Iniciação

O fluxo de trabalho básico da Fase de Iniciação é aplicável, com as seguintes extensões ou variações:

Gerenciamento de Projeto

• Detalhamento do Fluxo de Trabalho: Conceber Novo Projeto

O foco da Atividade: Desenvolver Caso de Negócio é ajustado para levar em conta que o uso dos componentes altera a estrutura do custo de desenvolvimento. Em especial, o custo de desenvolvimento de componentes diminui, mas há um esforço maior para identificar componentes e garantir que os componentes selecionados atendam aos requisitos.

• Detalhamento do Fluxo de Trabalho: Avaliar Escopo e Risco do Projeto

A escolha de uma abordagem de componente altera a natureza de determinados riscos e introduz riscos novos. Especificamente:

• componentes externos aumentam o risco, pois introduzem elementos críticos fora do controle direto da equipe de projeto.
• componentes externos podem reduzir o tempo de desenvolvimento, reduzindo os riscos do recurso
• componentes externos podem distorcer a arquitetura do sistema se impuserem suas próprias restrições de arquitetura

• Detalhamento do Fluxo de Trabalho: Elaborar Plano de Desenvolvimento de Software

Na Atividade: Planejar Fases e Iterações, o plano para a fase de Construção pode mostrar a divisão do projeto em dois caminhos distintos, mas paralelos: um que desenvolve os componentes específicos do aplicativo e específicos do domínio (organizados nas camadas superiores da arquitetura. Consulte Conceitos: Divisão em camadas) e os componentes não específicos do aplicativo e do domínio, organizados em camadas inferiores. Em alguns casos, os componentes reutilizáveis serão desenvolvidos por equipes de desenvolvimento gerenciadas de modo independente. A decisão de introduzir caminhos paralelos é, em grande parte, uma questão de equipe e de recursos introduzida por um desejo de gerenciar componentes reutilizáveis como recursos valiosos, independentes dos aplicativos em que estiverem implantados.

Requisitos

• Detalhamento do Fluxo de Trabalho: Refinar a Definição do Sistema

No refinamento dos requisitos do sistema, é necessário capturar as restrições impostas pelo framework do componente selecionado. Os frameworks de componentes melhoram a produtividade do desenvolvimento em parte por limitar o grau de liberdade oferecido ao arquiteto e ao designer de software. A Atividade: Detalhar os Requisitos de Software precisa se concentrar na documentação dessas restrições.

Teste

• Detalhamento do Fluxo de Trabalho: Definir Missão de Avaliação

Um plano de teste que identifique o teste geral pretendido para o projeto deve ser criado, denominado "Plano de Teste Mestre".

Ambiente

• Detalhamento do Fluxo de Trabalho: Preparar Diretrizes para uma Iteração

A Atividade: Desenvolver Guia de Design e a Atividade: Desenvolver Guia de Programação precisam considerar o framework específico do componente e as restrições por ele impostas. A Atividade: Desenvolver Guia de Teste também precisa refletir o framework do componente, proporcionando orientação sobre como verificar a conformidade com o framework do próprio componente e com as interfaces definidas entre componentes.

Atividades da Fase de Elaboração

O fluxo de trabalho básico da Fase de Elaboração é aplicável, com as seguintes extensões ou variações:

Requisitos

• Detalhamento do Fluxo de Trabalho: Refinar a Definição do Sistema

A Atividade: Detalhar os Requisitos de Software concentra-se, adicionalmente, nas restrições e nos requisitos técnicos e não funcionais impostos aos componentes criados ou adquiridos. Os requisitos específicos não funcionais a serem considerados são: tamanho, desempenho, memória ou espaço usado no disco, questões de licença em tempo de execução e restrições semelhantes que influenciarão a seleção ou a criação do componente.

Análise e Design

• Detalhamento do Fluxo de Trabalho: Definir uma Sugestão de Arquitetura

A Atividade: Análise Arquitetural usa o framework do componente e os requisitos técnicos e não funcionais para definir uma arquitetura inicial, contendo um esquema inicial de divisão em camadas e um conjunto padrão de componentes e serviços (representados como mecanismos de análise e design). A Atividade: Análise de Caso de Uso concentra-se na identificação de componentes significativos do ponto de vista da arquitetura a partir de casos de uso também significativos nesse aspecto.

• Detalhamento do Fluxo de Trabalho: Refinar a Arquitetura

A Atividade: Estruturar o Modelo de Implementação estabelece um modelo de implementação compatível com a estrutura do framework do componente e com a estrutura e as responsabilidades das equipes de desenvolvimento.

A Atividade: Identificar Mecanismos de Design refinará os mecanismos iniciais de design para considerar serviços e componentes específicos do framework.

A Atividade: Identificar Elementos de Design identificará os principais componentes do sistema significativos do ponto de vista da arquitetura. As responsabilidades com potencial de reutilização devem ser agrupadas para aumentar a reutilização; as funcionalidades específicas de aplicativo devem ser separadas das funcionalidades específicas de domínio e das funcionalidades independentes de aplicativo e de domínio. Para fins de design, os componentes podem ser representados como Artefato: Subsistemas de Design. O Artefato: Interfaces deve ser identificado por estes componentes/subsistemas.

A Atividade: Incorporar Elementos de Design Existentes garantirá que os componentes identificados sejam consistentes e compatíveis com os componentes existentes identificados em iterações anteriores, no próprio framework ou em fontes externas.

A Atividade: Descrever a Arquitetura em Tempo de Execução descreve o processo básico e a arquitetura de thread do framework do componente, enquanto a Atividade: Descrever Distribuição descreve o ambiente computacional distribuído no qual o aplicativo do componente será executado.

• Detalhamento do Fluxo de Trabalho: Projetar Componentes

A Atividade: Design do Subsistema amplia o refinamento do design dos componentes, identificando classes dentro deles que fornecem o seu comportamento real. Nos primeiros estágios da fase de Elaboração, provavelmente há uma única classe, um tipo de 'proxy de subsistema/componente' que atua como um stub para simular o comportamento do componente com finalidades de criação de protótipo de arquitetura. Mais tarde, o comportamento dessa classe é distribuído para uma colaboração de classes contidas no subsistema. Essas classes contidas são refinadas na Atividade: Design da Classe.

• Detalhamento do Fluxo de Trabalho: Projetar o Banco de Dados

O foco na elaboração é garantir que a estratégia de persistência seja ajustável e que o design do banco de dados e o mecanismo de persistência suportem os requisitos de taxa de transferência do sistema. Classes persistentes são identificadas e mapeadas para o mecanismo de persistência. Os casos de uso intensivo de dados são analisados para garantir que os mecanismos sejam ajustáveis. O design do mecanismo de persistência e banco de dados é avaliado e validado em conjunto com os Detalhamentos do Fluxo de Trabalho de Teste.

Implementação

• Detalhamento do Fluxo de Trabalho: Implementar Componentes

  A Atividade: Implementar Componentes deve estar de acordo com as restrições impostas pelo framework do componente, conforme descrito no Artefato: Guia de Programação. Na fase de Elaboração, a maioria dos componentes conterá grande parte de código 'stub', já que a implementação aqui se concentra na validação da arquitetura e não na produção de código de qualidade.

Teste

• Detalhamentos do Fluxo de Trabalho: Definir Missão de Avaliação, Verificar Abordagem do Teste, Testar e Avaliar, Realizar Missão Aceitável, Aprimorar Vantagens do Teste

  O foco das atividades de teste na Elaboração é a validação da arquitetura. Para um sistema baseado em componente, esse foco traduz-se em:

  • testar as interfaces entre componentes para garantir que as fronteiras do componente sejam adequadas e
  • maior concentração no teste de desempenho, especialmente nos testes de escala de desempenho, para garantir que poderá suportar os volumes de transação previstos

  É necessário avaliar também todas as suposições básicas existentes no framework do componente. Essas incluem, em geral, a capacidade de ajuste e a taxa de transferência dos mecanismos de gerenciamento de persistência e transação, em que suposições ocultas feitas pelo designer do mecanismo muitas vezes minam efetivamente a arquitetura do aplicativo, se ela não entender essas suposições. Um exemplo clássico é o Microsoft Transaction Server, cujo requisito para que os objetos de transação sejam 'sem estado' surpreendeu muitos arquitetos de software incautos.

Atividades da Fase de Construção

O fluxo de trabalho básico da Fase de Construção é aplicável, com as seguintes extensões ou variações:

Gerenciamento de Projeto

• Detalhamento do Fluxo de Trabalho: Planejar Próxima Iteração

  Com a utilização dos subsistemas de implementação como 'unidades lógicas de responsabilidade', o trabalho de construção pode ser dividido em dois ou mais "caminhos" paralelos: um destaca a funcionalidade específica do aplicativo, e um ou mais destacam componentes genéricos, reutilizáveis. Isso, é claro, depende da existência de recursos suficientes para obter esforços de desenvolvimento paralelos. A capacidade de dividir as equipes de desenvolvimento e de trabalhar em paralelo depende inteiramente da estabilidade da arquitetura e, mais especificamente, da qualidade e estabilidade das interfaces entre componentes. Um esforço concentrado na fase de Elaboração permitirá essa divisão.

Análise e Design

• Detalhamento do Fluxo de Trabalho: Refinar a Arquitetura e Detalhamento do Fluxo de Trabalho: Projetar Componentes

  O foco da construção é a análise do restante dos casos de uso e a identificação de componentes apropriados e colaborações de componentes que realizam os casos de uso. A arquitetura existente é expandida e concluída, e os 'comportamentos internos' do componente são totalmente projetados e implementados.

• Detalhamento do Fluxo de Trabalho: Projetar o Banco de Dados

  O foco da construção é a conclusão do design do banco de dados, garantindo que todas as classes persistentes sejam suportadas pelo banco de dados e pelo mecanismo de persistência. Esse trabalho é executado em paralelo e de forma iterativa com o trabalho feito em Detalhamento do Fluxo de Trabalho: Refinar a Arquitetura e Detalhamento do Fluxo de Trabalho: Projetar Componentes A organização ideal é a integração das equipes de componentes, com coordenação entre as equipes sobre problemas de persistência, para garantir um bom design do banco de dados.

Implementação

• Detalhamento do Fluxo de Trabalho: Implementar Componentes

O trabalho aqui é semelhante àquele da Elaboração, mas a conclusão dos detalhes restantes aumenta à medida que a fase progride.

• Detalhamento do Fluxo de Trabalho: Integrar cada Subsistema e Detalhamento do Fluxo de Trabalho: Integrar o Sistema

O sistema é criado de forma progressiva à medida que a fase continua.

Teste

• Detalhamentos do Fluxo de Trabalho: Definir Missão de Avaliação, Verificar Abordagem do Teste, Validar Estabilidade do Build, Testar e Avaliar, Realizar Missão Aceitável, Aprimorar Vantagens do Teste

O teste de desempenho continua sendo importante, mas há um foco crescente no teste funcional. A abrangência da funcionalidade, o teste de regressão da funcionalidade existente e a conformidade com as expectativas de desempenho precisam ser tratados.

Atividades da Fase de Transição

• O release do produto tende a ser incremental e contínuo no ambiente da Web e menos concentrado na distribuição tradicional de mídia. O planejamento do release deve ser ajustado adequadamente.
• O suporte a produção é, cada vez mais, o foco da fase.
• As atividades de conversão de dados são realizadas.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process