As Atividades de Arquitetura do Processo Unificado da Rational (RUP)

O processo unificado e suas derivações (RUP, EUP, AUP e o Open-UP) são dirigidos por arquitetura, i.e., enfatizam fortemente as atividades arquiteturais ao longo de um projeto de TI. Resumo aqui as principais tarefas arquiteturais que devem ser realizadas dentro de um projeto.

1. Coletar Requisitos Suplementares. O RUP enfatiza através de um método chamado FURPS+ criado por Robert Grady e disponibilizado no livro Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall, 1992. Este método enfatiza a captura de requisitos como usabilidade, confiabilidade, desempenho, suportabilidade, entre diversos outros. Um artigo chave para o entendimento do método FURPS+ é o artigo Capturing Architectural Requirements, de Peter Eeles. Um versão em formato de questionário pode ser encontrado aqui.
2. Identificar os casos de uso significativos para análise arquitetural. Em um sistema, apenas um sub-conjunto dos casos de uso são críticos para o negócio e complexos tecnicamente. Este sub-conjunto deve ser exercitado e provado através de uma arquitetura.
3. Realizar a análise arquitetural. A análise arquitetural visa produzir uma arquitetura candidata e refiná-la sucessivamente ao longo do projeto. Esta é uma atividades claramente iterativa e incremental e compreende as definições dos mecanismos (Soluções) que irão realizar os requisitos do projeto.  Um aspecto endereçado aqui é a decomposição em camadas.  A série de artigos referenciados ao final deste blog fornece, também, mais informações sobre este processo.
4. Construir Provas de Conceito Arquiteturais. Durante o processo da análise arquitetural, aspectos de risco do projeto podem merecer uma investigação mais detalhada. Uma prova de conceito no processo unificado pode tomar as seguintes formas: Modelagem conceitual; Protótipo ‘Rápido; Simulação; Conversão automática de especificações em código; Especificações ‘executáveis’ou a Construção de  ‘picos invertidos’ como protótipos – fatias verticais através de camadas.
5. Avaliar Viabilidade das Provas de Conceito Arquiteturais. Toda prova de conceito deve ser avaliada contra os objetivos e requisitos que ela pretende realizar de forma que os riscos associados sejam mitigados.
6. Identificar os mecanismos de design. Esta tarefa lida com o processo de seleção e escolha das tecnologias que irão realizar uma arquitetura.
7. Identificar e incorporar elementos de design. Dado que uma tecnologia esteja escolhida, é necessário refinar os elementos da arquitetura em elementos de design e também melhorá-lo através de soluções como design patterns.
8. Estrutura o modelo de implementação. Esta tarefa estabelece a estrutura dos elementos de implementação baseados nas responsabilidades designadas para subsistemas de implementação e seu conteúdo.

Os principais artefatos produzidos pelo time de arquitetura (arquiteto de software, analistas de sistemas,  analista de requisitos e projetistas) são:

• Requisitos Suplementares
• Documento de Arquitetura de Software
• Provas de Conceito
• Modelo de Design
• Modelo de Implementação

Um outro aspecto importante no RUP é o momento temporal onde estas tarefas se concentram – até 3/10 do tempo do projeto. Por exemplo, se tivéssemos executando um projeto de 4 meses (18 semanas), teríamos o seguinte padrão:

• Até duas semanas (1/10 do tempo) para identificar os requisitos suplementares.
• Até duas semanas para gerar uma primeira proposta de arquitetura candidata e mais quatro semanas (+ 2/10 do tempo) para refinamentos desta arquitetura.
• Até seis semanas (3/10 do tempo) para a execução de provas de conceito e verificação da viabilidade destas provas de conceito.
• Até seis semanas (3/10 do tempo) para o detalhamento de uma arquitetura com os elementos de desenho instalados e um modelo de implementação definido.

Temporalmente do RUP, portanto, o alvo a ser atingido até o 3/10 do tempo de um projeto  com as tarefas acima é produzir um artefato chave chamado arquitetura executável. Esta arquitetura executável acomoda entre 5 e 20% dos casos de uso de um sistema (que foram implementados em paralelo as atividades acima por um pequeno time de projetistas e desenvolvedores) e cria a fundação para acomodar o restante dos casos de uso. É o fim da fase de elaboração no RUP!

Para mais informações a respeito, coloco abaixo algumas referências interessantes sobre atividades de arquitetura no RUP

• Architectural Manifesto – The Benefits of The Software Architecture
• Developing a J2EE Architecture with Rational Software Architect Using the Rational Unified Process
• Architectural manifesto: Evaluating architectures
• Designing Software Architectures – Parte 1
• Designing Software Architectures – Parte 2
• Designing Software Architectures – Parte 3
• Designing Software Architectures – Parte 4
• Designing Software Architectures – Parte 5
• Planejamento de Iterações no RUP (Descreve o fluxo de arquitetura do RUP e principais artefatos associados).