O RUP oferece uma fonte razoável de informações voltadas para a arquitetura de software como fluxo de trabalho (incluindo atividades e tarefas), conceitos, diretrizes, etc. Ao definir o ciclo de vida de desenvolvimento do software, constitui guia fundamental para arquitetos de software. Neste texto, citaremos algumas dessas diretrizes.

• Descoberta, Análise e Controle Arquitetural: descreve como realizar descoberta, análise e controle arquitetural com o Rational Software Architect (RSA). 
• Integrando os Aplicativos Legados às Arquiteturas Modernas: orienta sobre a modernização de sistemas legados e sua integração com novos sistemas.  
• Dependência de Manifestação: orienta como realizar o mapeamento entre elementos de desenho e os artefatos fisicos de implementacão (DLLs, executáveis e códigos).
• Dependência de Importação na Implementação: orienta a organização das dependências do modelo de implementação.
• Diagrama de Componentes: aponta utilidades de aplicação de um diagrama de componentes na descrição do modelo de implementação.
• Análise Arquitetural para os Aplicativos J2EE: fornece uma noção geral dos mecanimos de design e tecnologias de J2EE.

As seguintes diretrizes indicam técnicas para modelar sistemas J2EE. Relacionam mecanismos de desenho com as tecnologias, bem como seu melhor uso.

O Open-UP, que detalhamos em um artigo anterior, é um processo de domínio público e aberto para extensões que mescla a escola de agilidade de métodos ágeis como o XP com o rigor do ataque aos riscos do RUP.

O OpenUP é baseado em quatro princípios básicos:

• Balanço: Balanceamento entre as prioridades conflitantes do projeto (custo, tempo, qualidade, escopo) de forma a maximizar o valor para os clientes.
• Colaboração: Colaboração para alinhar os interesses e fomentar o entendimento comum da missão e prioridades do projeto.
• Foco: Desde o início, foco na arquitetura para mitigar riscos e organizar o desenvolvimento de software.
• Evolução: Evoluir através de feedbacks contínuos dos stakeholders e através da demonstração de valor agregado regularmente.

O gráfico abaixo com a espinha dorsal do Open-UP mostra o rigor do ataque a riscos neste processo ágil.

Perfil de Riscos do OpenUP

Fonte: OpenUP – Licença EPL

A fase de elaboração é normalmente finalizada por volta do 3/10 temporal de um projeto e deve apresentar um perfil de riscos muito baixos para que seja dada como encerrada. Para que os riscos estejam mitigados, é fundamental um foco permanente em atividades arquiteturais.

No OpenUP, diferentemente do RUP, a arquitetura é enfatizada como um produto coletivo e não como um produto do arquiteto. A arquitetura não deve ser arremessada para a equipe pelo arquiteto da torre de marfim. Além disso, a arquitetura é considerada evolutiva, embora ela tenha suas linhas de base salvas dentro do ciclo de vida do projeto (prática da Arquitetura Evolutiva).

O OpenUP produz apenas um único e ligeiro documento para a “disciplina” de arquitetura, chamado de Caderno Arquitetural (Architectural Notebook). Este documento compila as decisões realizadas pelo time, liderado pelo arquiteto de software, e formaliza as decisões técnicas tomadas para facilitar comunicações futuras.

A disciplina arquitetural do OpenUP pode ser observada também na lista de verificação do Caderno Arquitetural, colocada abaixo, e também na lista de atividades que documentamos anteriormente.

Lista de Verificação de Arquitetura do OpenUP

• A arquitetura está totalmente compreensível para todos os envolvidos do projeto?
• Os objetivos da arquitetura, restrições de desenho e implementação e os requisitos foram descritos e endereçados?
• Os mecanismos arquiteturais foram identificados e descritos?
• As partições do sistema foram suficientes definidas?
• Os elementos chave da arquitetura foram definidos adequadamente?
• As interfaces com sistemas externos foram representadas?
• Os pontos de reuso foram identificados?
• A arquitetura foi feita para evoluir?
• A arquitetura conseguirá ser entregue pelo time nas restrições de tempo e custo do projeto?
• O software foi mapeado adequadamente para o hardware?

O OpenUP foi originalmente desenhado para times pequenos (< 10 pessoas), embora acreditemos na sua escala até mesmo para projetos maiores. De toda forma, por ser um processo público, ágil e com forte ênfase em controle de riscos através de atividades arquiteturais, este processo é sem dúvida uma excelente escolha para desenvolvimento de software na realidade brasileira.

Um artigo bem interessante sobre o OpenUP, inspirou o método de trabalho usado para criar o Eclipse, pode ser encontrado na Rational Edge.

Curiosidade do Dia: O criador do OpenUP é o Ricardo Balduíno, um brasileiro que trabalha como Engenheiro de Software Sênior pela IBM Rational.

Diferentemente das outras abordagens ágeis, como o XP, a forte orientação à mitigação de riscos do OpenUP (premissa do UP, claro) enfatiza o trabalho arquitetural no início do ciclo de desenvolvimento. Ao balancear o ataque aos riscos técnicos com as práticas ágeis, o OpenUP adota a Arquitetura Evolucionária (Evolutionary Architecture), uma influência da Arquitetura Ágil (Agile Architecture) de Ambler. A Arquitetura Evolucionária se baseia em: realizar o trabalho arquitetural “just in time”, isto é, na medida que é necessário; documentar principais premissas arquiteturais; implementar e testar capacidades-chave através de protótipos.

As tarefas cujo principalmente responsável é do arquiteto são “Esboçar a Arquitetura” (Outline the Architecture) e “Refinar a Arquitetura” (Refine the Architecture). Basicamente, a tarefa de “Refinar a Arquitetura” complementa com maiores detalhes as informações identificadas em “Esboçar a Arquitetura”.

Relacionamentos do Arquiteto de Software (OpenUP)

Fonte: OpenUP – Licença EPL

Abaixo apresentamos uma correlação entre os passos das tarefas arquiteturais:

Apesar de ser um processo minimalista, as tarefas arquiteturais indicadas pelo OpenUP são suficientes para suprir as necessidades de modelagem da arquitetura de grande parte dos projetos de software. Ambas tarefas fornecem insumos para o preenchimento do “Caderno de Arquitetura” (“Architecture Notebook”, também traduzido por “Descrição Arquitetural” no OpenUP 0.9 em português). O Caderno de Arquitetura, único artefato da disciplina, registra todos os apontamentos relevantes do time de arquitetura. Não é pretensão do OpenUP documentar toda a atividade de arquitetura – para isto, conta com o valor ágil de “Comunicação”.

Para maiores informações aos interessados, seguem referências.

1. As Atividades de Arquitetura do Processo Unificado 
2. OpenUP
3. Agile Manifesto
4. Agile Architecture: Strategies for Scaling Agile Development
5. Architecture Envisioning: An Agile Best Practice
6. Agile Enterprise Architecture
7. Architecture Paradox

Na maioria das vezes, não faz muito sentido identificar requisitos fora do contexto de um projeto. Sendo assim, geralmente o QAW é empregado como uma atividade (ou conjunto de atividades) de um processo responsável por todo o ciclo de vida de desenvolvimento do software como o RUP (Rational Unified Process) ou o XP (eXtreme Programming). Neste texto, descrevemos uma possível combinação do QAW com esses processos.

QAW e o ciclo de vida do RUP
O QAW deve ser empregado antes de se modelar a arquitetura. A atividade de arquitetura do RUP mais relacionada ao contexto do QAW é “Desenvolver Especificações Suplementares” (Develop Supplementary Specifications) que deve ser realizada no início do desenvolvimento, isto é, nas fases de Iniciação (ou Concepção) e Elaboração. Conforme o gabarito do RUP, os requisitos não-funcionais podem ser enquadrados como especificações suplementares nos casos de uso.

Algumas tarefas do RUP que também podem ser influenciadas pelo método do QAW são a “Análise Arquitetural” (Architectural Analysis) e “Priorizar Casos de Uso” (Prioritize Use Cases), respectivamente associadas às disciplinas de “Análise e Desenho” e “Requisitos”.

Maiores informações podem ser encontradas no relatório técnico “Integrating Software-Architecture-Centric Methods into the Rational Unified Process”. Ponto de atenção: neste post, adaptei a nomenclatura para ficar coerente com o RUP 7.

QAW e o ciclo de vida do XP
Apesar do XP dar muito pouca ênfase à arquitetura de software (por confiar no valor da “coragem” para uma possível refatoração arquitetural, se necessário), geralmente a arquitetura é capturada na “Metáfora do Sistema” (System Metaphor).

Ao contrário do RUP, o XP originalmente não contempla um gabarito formal que inclua requisitos suplementares. Mas sugere-se suplementar as “Estórias de Usuário” (User Stories) com os requisitos de qualidade (representados com os seis tradicionais atributos). A primeira iteração do projeto é o momento perfeito para o evento de QAW, quando seriam capturados os requisitos de qualidade que devem nortear a metáfora sistêmica. A prática “Cliente presente” facilita o acontecimento do evento.

Outra prática que também contribui para o emprego do QAW é “Jogo de Planejamento” (Planning Game), pois a priorização dos requisitos de qualidade pode auxiliar na escolha das estórias de cada iteração.

Além disto, a prática “Desenvolvimento Guiado por Testes” (Test Driven Development) que potencialmente é favorecida pela identificação dos cenários no evento de QAW. Neste caso, os cenários podem ser usados posteriormente para avaliar o desenho e fornecer insumos para análise dos testes.

Maiores informações podem ser encontradas no relatório técnico “Integrating Software-Architecture-Centric Methods into Extreme Programming”.

QAW e outros processos de desenvolvimento de software
Mesmo que você não use diretamente o RUP ou o XP, possivelmente emprega alguma variante do RUP (ex: EUP, EssUP, OpenUP, etc) ou alguma metodologia ágil (ex: SCRUM, FDD, Crystal Clear). Ou ainda uma combinação de ambos como o AUP e a “dobradinha” RUP + Scrum. Assim poderá aplicar facilamente os fundamentos aqui expostos em qualquer método.

Outras referências:

1. Quality Attribute Workshops (QAWs), Third Edition
2. IBM Rational Unified Process
3. Integrating Architecture Methods: The Case of Extreme Programming
4. RUP in the dialogue with Scrum

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).