As práticas do AUP se baseiam em técnicas ágeis como, como exemplo, Test Driven Development (TDD), Agile Model Driven Development (AMDD), Agile Change Management, Database Refactoring e Agile Architecture. Além disso, a filosofia do AUP parte dos seguintes princípios:

1. A equipe sabe o que está fazendo.
2. Simplicidade.
3. Agilidade.
4. Foco em atividades de alto valor.
5. O processo será personalizável conforme as necessidades de quem o usa.

O AUP concentra as atividades de análise, desenho e requisitos em uma única disciplina conhecida por Modelagem. Exatamente por interessar ao tema de Arquitetura de Software, nos concentraremos nessa disciplina. Afinal, como o AUP orienta o trabalho de arquitetura?

Arquitetura Ágil é o conceito que permeia o trabalho arquitetural. Para Ambler, a arquitetura é um dos fatores que, assim como no EUP, permitem escalar o desenvolvimento de software sem perder o caráter ágil. De uma forma geral, a proposta da Arquitetura Ágil, assim como várias outras práticas propostas por Ambler, é dirigida pelo conceito de bom o suficiente (nossa tradução contextualizada para Just Barely Good Enough ou JBGE). Nenhum excesso é cometido e procura-se sempre obter a melhor relação valor/tempo. Não significa que os modelos devam ser ruins ou o trabalho negligenciado – apenas destaca-se que uma atividade não precisa ser executada até a perfeição do produto e, sim, apenas o suficiente para a otimização do esforço.

Da mesma forma que o RUP e o EUP, o AUP propõe a evolução da arquitetura ao longo de duas fases. Na Iniciação, obtém-se uma arquitetura de alto nível, levando em consideração os requisitos técnicos. O objetivo é identificar uma estratégia arquitetural viável capaz de oferecer insumos ao planejamento do projeto e ao cálculo de esforços (lembre-se, o UP é dirigido pela arquitetura). Nesse momento, o diagrama recomendado mais importante é o esboço do modelo de implantação.

Já na Elaboração, o objetivo é refinar a arquitetura até atingir sua estabilidade. A modelagem da arquitetura é dirigida aos maiores riscos técnicos identificados. Tipicamente, protótipos são construídos para provar alguns aspectos da arquitetura. O principal objetivo dessa fase é a arquitetura estável, comprovada através da implementação dos requisitos estruturalmente críticos.

Historicamente, o AUP foi derivado da compreensão e refinamento dos princípios e valores expostos no livro Modelagem Ágil (Agile Modeling), quando Scott Ambler demonstra a possível aplicação da Modelagem Ágil através do RUP. O AUP, influenciado por métodos populares como o XP, RUP e EUP, foi um dos primeiros processos a tentar convergir conceitos do UP e técnicas ágeis Por sua vez, o AUP influenciou fortemente outros processos mais recentes como o notável OpenUP.

Para mais informações:

• The Agile Unified Process (AUP)
• Agile Architecture: Strategies for Scaling Agile Development
• Agile Modeling and the Rational Unified Process (RUP)
• The Enterprise Architecture Discipline: Scaling Agile Software Development
• Making RUP Agile, por Michael Hirsch 
• Modelagem Ágil (Agil Modeling), de Scott Ambler 

A grande maioria dos processos de software traz um forte acoplamento entre disciplinas, atividades, artefatos e papéis. Este desenho torna complexo ou às vezes impossível adotar uma determinada “prática” isoladamente. A partir das idéias de “separação de preocupações” do paradigma de programação por aspectos, um processo chamado EssentialUP (ou EssUP) foi desenhado como um conjunto de práticas que podem ser adotadas isoladamente ou em conjunto. O EssentialUP é inspirado no RUP e o seu criador, Ivar Jacobson, é um dos pais do processo unificado. Diferentemente no RUP 7.0, entretanto, a arquitetura de software é endereçada como uma prática. Uma prática é corpo de conhecimento que pode ser adotado isoladamente ou em conjunto com outras práticas. As práticas do EssentialUP são colocadas abaixo e se dividem nas categorias de práticas técnicas e práticas “Cross-Cutting”, que são ortogonais a todas as práticas técnicas.

Práticas do EssentialUP

(c) Ivar Jacobson International

Neste post, endereçamos a prática chamada Architecture Essentials, que descreve atividades arquiteturais ágeis. Os principais objetivos desta prática são:

• Estabelecer um alicerce sólido para o desenvolvimento de um produto.
• Endereçar e mitigar os riscos técnicos de um projeto.
• Compartilhar as principais decisões técnicas sobre a arquitetura.
• Verificar se o sistema atende às expectativas dos clientes.
• Provar objetivamente se a abordagem arquitetural adotada atende o seu propósito no projeto.

As atividades arquiteturais do EssentialUP são resumidas na figura abaixo:

Atividades de Arquitetura do Essential UP

(c) Ivar Jacobson International

As atividades de arquitetura, em resumo, vão da captura de requisitos arquiteturais até o teste da arquitetura executável que prova a viabilidade destes requisitos. A atividade de espalhamento dos resultados para a equipe (coaching) é também bastante enfatizada, como pode ser observado na atividade “Coach Team on Architecture”.

Os principais resultados (entregáveis deste processo) são colocados abaixo:

Produtos de Arquitetura do EssentialUP

(c) Ivar Jacobson International

Notável neste figura é que a arquitetura é documentada através do artefato Descritivo Arquitetural, que guarda a idéia de agilidade do bloco de notas arquitetural do OpenUP, para então ser desenhada no Modelo de Desenho e então provada (verificada) através de testes no sistema executável que foi derivado dos protótipos arquiteturas evolutivos.

Infelizmente o EssentialUP não é um processo gratuito como o OpenUp ou o AUP, mas ele é mais uma ferramenta das escolas ágeis que renova as excelentes idéias apresentadas no UP ainda nos anos 90.

Informações mais detalhadas podem ser obtidas nos links abaixo:

• Artigo da Dr. Dobb’s – The Essential Unified Process: New Life For the Unified Process.
• Prática “Architecture Essentials” do site da Ivar Jacobson International.

Nota: Interessante notar que o novo RMC 7.5, que acabou de ser lançado agora adota o conceito de práticas.Mais informações sobre o conceito de práticas e as práticas do RUP/RMC 7.5 estão aqui. 

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.