Conceito:
|
Atividades durante o ciclo de vida: |
Tópicos adicionais:
|
O desenvolvimento baseado em componentes é uma variação do desenvolvimento geral de aplicativos em que:
- O aplicativo é montado a partir de componentes executáveis separados que são desenvolvidos e implementados de modo relativo e independente um do outro, possivelmente por equipes diferentes.
- É possível fazer upgrade do aplicativo em incrementos menores, fazendo upgrade apenas de alguns componentes que constituem o aplicativo.
- Os componentes podem ser compartilhados entre os aplicativos, criando oportunidades para reutilização, mas também criando dependências entre projetos.
- Apesar de não haver uma relação estrita com o fato de serem baseados em componentes, os aplicativos baseados em componentes tendem a ser distribuídos.
Em toda esta página, "componente" é utilizado para referir-se a esses componentes desenvolvidos e implementáveis de modo independente. No entanto, em qualquer outra parte no RUP, utilizaremos o termo "componente" no sentido mais geral, descrito em Conceitos: Componente , e qualificaremos conforme necessário.
A adaptação do RUP (Rational Unified Process) para lidar com desafios de desenvolvimento com base em componentes é discutido a seguir.
O workflow básico para a Fase de Iniciação é aplicável, com as extensões ou variações a seguir:
O foco da Atividade: Desenvolver Caso de Negócio é ajustado para considerar que a utilização de 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.
A escolha de uma abordagem de componente altera a natureza de determinados riscos e introduz riscos novos. Especificamente:
Na Atividade: Planejar Fases e Iterações, o plano da fase de Construção pode potencialmente mostrar a divisão do projeto em duas trilhas diferentes, porém paralelas: uma 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 uma de componentes não específicos do aplicativo e não específicos 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 implementados.
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 deve ter como foco documentar essas restrições.
Um plano de teste que identifique o teste geral pretendido para o projeto deve ser criado, denominado "Plano de Teste Principal".
Ao coletar e preparar diretrizes para o projeto, considere a estrutura específica de componentes e as restrições impostas por ela. As diretrizes devem incluir como projetar e codificar utilizando a estrutura. Elas também devem fornecer orientação de teste sobre como verificar a conformidade com ambos, a própria estrutura do componente e as interfaces definidas entre os componentes.
O workflow básico para a Fase de Elaboração é aplicável, com as extensões ou variações a seguir:
Adicionalmente, a Atividade: Detalhar os Requisitos de Software tem como foco os requisitos técnicos e não-técnicos e as restrições impostas nos componentes que são construídos ou comprados. 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.
A Atividade: Análise Arquitetural utiliza a estrutura de componentes e os requisitos técnicos e e não-funcionais para definir uma arquitetura, incluindo um esquema de camadas inicial 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 tem como foco a identificação de componentes arquiteturalmente significativo a partir de casos de uso arquiteturalmente significativos.
A Atividade: Estruturar O Modelo de Implementação estabelece um modelo de implementação compatível com a estrutura de componentes e a estrutura e as responsabilidades da(s) equipe(s) de desenvolvimento.
A Atividade: Identificar Mecanismos de Design refinará os mecanismos de design iniciais para considerar serviços e componentes de específicos da estrutura.
A Atividade: Identificar Elementos de Design identificará os principais componentes arquiteturalmente significativos do sistema. 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 finalidades de design, os componentes podem ser representados como Artefato: Subsistemas de Design. O Artefato: Interfaces deve ser identificado para esses componentes/subsistemas.
A Atividade: Incorporar Elementos de Design Existentes assegurará que os componentes identificados sejam consistentes e compatíveis com os componentes existentes identificados em iterações anteriores, na própria estrutura ou a partir de origens externas.
A Atividade: Descrever a Arquitetura de Tempo de Execução descreve o processo básico e a arquitetura de encadeamentos da estrutura de componentes, enquanto a Atividade: Descrever Distribuição descreve o ambiente de computação distribuída no qual o aplicativo do componente será executado.
A Atividade: Design de Subsistema refina ainda mais o design dos componentes, identificando classes no componente que fornecem o comportamento real do componente. 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 de Classe.
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 Detalhes do Workflow de Teste.
A Atividade: Implementar Elementos de Design deve estar em conformidade com as restrições impostas pela estrutura de componentes. 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.
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:
É 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.
Utilizando os subsistemas de implementação como 'unidades lógicas de responsabilidade', o trabalho de construção pode ser particionado em duas ou mais "trilhas" paralelas: uma com foco na funcionalidade específica do aplicativo e uma ou mais com foco em 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.
O workflow básico para a Fase de Construção é aplicável, com as extensões ou variações a seguir:
O planejamento da primeira iteração de construção foi descrito anteriormente, uma vez que ocorre no final da elaboração. O planejamento de iteração contínua e a capacidade de dividir as equipes de desenvolvimento e de trabalhar em paralelo dependem inteiramente da estabilidade da arquitetura e da qualidade e estabilidade das interfaces entre 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.
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. Este trabalho é executado em paralelo e iterativamente com o trabalho feito em Detalhe do Workflow: Refinar a Arquitetura e Detalha do Workflow: 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.
O trabalho aqui é semelhante àquele da Elaboração, mas a conclusão dos detalhes restantes aumenta à medida que a fase progride.
O sistema é criado de forma progressiva à medida que a fase continua.
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.
Rational Unified Process
|