A experiência
Recentemente tivemos uma experiência com uma metáfora sistêmica que julgamos interessante e gostaríamos de dividi-la.

Em um projeto da área de telecomunicações, estávamos prestes a desenvolver um módulo cuja responsabilidade era verificar se os demais módulos estavam funcionando corretamente e, caso algum estivesse apresentando algum tipo de falhas, alertaria uma ferramenta de monitoração via SNMP. Em outras palavras, o módulo deveria observar a saúde do restante do sistema e comunicar qualquer anormalidade.

Ao usar termos como “saúde” e “batida do coração” (heartbeat é uma tática comum para detecção de falhas), alguns membros da equipe começaram a brincar que o módulo parecia uma clínica médica de diagnósticos. E da brincadeira surgiu a metáfora sistêmica para o módulo: “Clínica Médica”.

A metáfora serviu de diretriz segura para a dupla que iria desenvolver o módulo. Bastou uma sessão de modelagem rápida e coletiva (não passou de meia hora) para que a dupla estivesse pronta para meter a mão na massa. Afinal de contas, mesmo quem nunca ficou internado num hospital, assiste a filmes ou seriados médicos. Todos tinham noção muito precisa de como funcionaria o módulo. Para se ter uma idéia, após o módulo ter sido implementado (em menos de uma semana), estava repleto de classes do tipo DoctorBean, NurseBean, Patient, Heartbeat e por aí vai.

Analisando a experiência:

• A concretude da metáfora foi muito eficaz para a orientação da dupla. Tínhamos um desenho anterior, mas a modelagem estava um tanto abstrata e não estava contribuindo muito para o entendimento.
• Os nomes das classes e mensagens ficaram muito mais significativos. Mesmo um programador novato no sistema terá mais facilidades em entender o que faz o DoctorBean (diagnósticos) e que tipo de informação carrega o Heartbeat (sinal de vida). Inclusive, a ausência do heartbeat significa a morte do componente.
• O trabalho ficou mais divertido! Nurse é bem mais legal que nomes como Template Method (nada contra, mas é meio careta).

Obviamente só a metáfora não teria sido suficiente para se chegar ao código. A dupla refinou bastante o desenho do módulo e o provou com código. E o sistema como um todo dificilmente poderia ser representado somente por uma metáfora. Na verdade, o sistema todo exigiu vários meses de trabalho arquitetural intensivo.

Modelagem inicial e funcionamento
Segue uma noção da modelagem inicial (diagrama de objetos – informal). Peço desculpas por não mostrar a foto original do modelo ágil – eu a perdi.

Caso esteja curioso sobre o funcionamento:

• Os monitores dos pacientes emitem os sinais da saúde (heartbeat é um deles).
• Os componentes enfermeiras coletam dados dos pacientes (agentes implantados nos módulos) e informam ao médico remotamente (o sistema é distribuído).
• O médico realiza o diagnóstico a partir dos dados coletados e, caso necessário, comunica a morte (ou qualquer possível anormalidade) ao HP OpenView.

Agradecimentos
Gostaria de agradecer à Luíza D. e ao Diego S. pelo trabalho inspirador. E claro ao Mr. K., um dos arquitetos do sistema. Não consigo imaginar como o desenho poderia ter ficado melhor.

Algumas referências:

Extreme Programming Explained (segunda edição) – referência clássica do XP

Made to Stick: Why Some Ideas Survive and Others Die – um excelente livro que aborda aspectos das idéias bem sucedidas, como concretude e simplicidade.

A prática da Metáfora Sistêmica é uma forma de explicar a arquitetura lógica através de uma analogia familiar tanto aos desenvolvedores quanto aos usuários. Até aí, ótimo! O maior problema é como conseguir uma boa metáfora. Das 190 páginas de “Extreme Programming Explained”, Kent Beck endereça somente duas delas para explicar o que é a Metáfora Sistêmica e deixa uma lacuna real em como atingí-la. Martin Fowler, um adepto não radical de XP, afirma em “Extreme Programming Examined” que, apesar da Metáfora Sistêmica ter funcionado bem para o projeto C3 (descrito no mesmo livro), ele próprio não faz a mínima idéia em como explicar a forma de obtê-la. Ainda na série XP da Addison-Wesley, os autores de “Extreme Programming Examined” declaram que a metáfora “é uma lacuna real no XP e que os XPmistas precisam resolvê-la” (desculpe, traduzimos “XPers” por “XPmistas”).

Com a polêmica carregada pela Metáfora Sistêmica e pelo fato de boa parte dos programadores praticantes de XP afirmarem que constroem software de sucesso mesmo sem tal metáfora, Kent Beck comentou publicamente que cogita a hipótese de remover esta prática da metodologia. No site de Ron Jeffries (outro guru radical do XP), arquitetura e desenho chegam a ser tratados com um certo tom de deboche.

Por ser um dos mais proeminentes métodos de desenvolvimento da atualidade, existem muitas propostas para preencher a lacuna arquitetural do XP. A seguir, citaremos algumas.

• Estórias do Desenvolvedor (Developer stories) é um prática proposta no artigo “Architecture and Design in eXtreme Programming” dos pesquisadores da Aalborg Universitet. O principal objetivo dessas estórias é introduzir um planejamento arquitetural ao XP. É uma abordagem é razoavelmente simples e, ao mesmo tempo, apresenta razoável eficiência no tratamento de requisitos de qualidade.
• Pesquisadores da Universidade de Wellington, na Nova Zelândia e da Univerdade de Carleton, no Canadá, propõem, através de uma abordagem semiótica, técnicas para desenvolver e avaliar a Metáfora Sistêmica. A Semiótica, mesmo parecendo um termo complicado para alguns, é o estudo formal dos sinais. Ao contrário do nome, a proposta desses pesquisadores é bem simples. Contudo não encontramos referências de sua aplicação na indústria.
• O SEI publicou um artigo descrevendo possíveis aplicações de seus métodos arquiteturais em projetos XP. Sem dúvida, o uso dos consagrados métodos do SEI oferece uma forte e excelente abordagem para arquiteturas dos projetos XP. Entretanto o uso intensivo dos métodos conforme descrito no artigo pode desagradar a alguns agilistas. Mas possivelmente vale a adaptação. A tempo: postamos recentemente um pequeno texto comentando sobre a aplicação do QAW em projetos XP e RUP.
• Martin Fowler, apesar de não apresentar nenhuma teoria inédita, no artigo “Is Design Dead?“, aconselha a não ignorar aspectos arquiteturais já conhecidos e, já no início do projeto, começar com uma arquitetura que aparenta ser necessária. E, em seguida, mesmo que pareça uma contradição ao princípio YAGNI, evoluir a arquitetura simplificando-a ou adicionando complexidades na medida da necessidade.
• A Modelagem Ágil, apresentada no livro de Scott Ambler, pode ser utilizada em aderência ao processo do XP e traz alguns poucos (mas bons) conselhos em como desenvolver a metáfora sistêmica de forma a representar uma arquitetura inicial. Vale a pena também consultar a idéia de Arquitetura Inicial Ágil do Ambler.
• David West propõe a Arquitetura Mandala, um método exótico para tratar a questão arquitetural no XP. Programadores místicos devem simpatizar com o nome.

Os valores e a filosofia de Extreme Programming visam de uma forma “extrema” a simplicidade e a acomodação das mudanças. Mudanças são de fato inevitáveis. Mas, mesmo acreditando nos princípios ágeis, devemos admitir que uma reestruturação arquitetural é uma atividade cara e de alto risco. Um esforço de investigação arquitetural um pouco maior que a indicada pelo XP “puro” pode minimizar boa parte dos riscos – não vale a pena ignorar aspectos estruturais já conhecidos no início do projeto. As abordagens indicadas podem ser um bom caminho para preencher a lacuna da arquitetura de software no XP. Resta ainda a questão: basta uma boa metáfora sistêmica para termos uma arquitetura completa?

Para obter mais visões críticas sobre como a arquitetura pode ser desenvolvida em projetos XP, sugerimos as seguintes referências:

• “Software Architecture and eXtreme Programming” de Andrew Wils e Stefan Van Baelen e
• “The eXtreme Programming (XP) Metaphor and Software Architecture” de James Herbsleb, David Root e James Tomayko da CMU.
• “Metaphor, Architecture, and XP” de David West (mesmo que você não seja assim tão místico).
• Entrevista de Kent Beck publicada em 2005 no The Register a respeito da segunda edição de “Extreme Programming Explained”.
• “Agile Architecture: Strategies for Scaling Agile Development” por Scott Ambler.

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