Diretrizes: Descoberta Arquitetural, Análise e Controle
Tópicos
Introdução
Em várias atividades no RUP, pesquisamos a necessidade de examinar o
Modelo de Design emergente, julgamos vários aspectos de qualidade e, em seguida,
se necessário, refatorar o modelo. Também é importante manter a integridade arquitetural de um sistema assim que tiver
sido movido para implementação, para garantir que as restrições arquiteturais e de design não sejam violadas e que o sistema, conforme implementado, continue a alinhar com a visão arquitetural. No RUP, esses pontos de verificação principais ocorrem em Atividades:
Revisar a Arquitetura,
Revisar o Design
e
Revisar o Código.
Um problema diferente, mas associado, surge durante a síntese arquitetural e de design:
em Atividades:
Análise Arquitetural
(consulte
Desenvolver
Visão Geral da Arquitetura,
Recursos Disponíveis
do Relatório Sintético) e
Incorporar os Elementos de Design Existentes, o Arquiteto de Software
é aconselhado a procurar oportunidades para reutilizar os recursos de design e de código existentes, incorporando-os
no Modelo de Design, depois de reverter a engenharia se necessário. A menos que os recursos reutilizados venham com algum tipo de certificação de qualidade, o Arquiteto do Software desejará sujeitá-los ao mesmo exame detalhado do design e do código criados recentemente.
Em ambos os casos, as conseqüentes necessidades do Arquiteto de Software são as mesmas
para esta análise estática:
- Para pegar um aplicativo codificado (ou fragmento dele), descubra sua estrutura simbólica
e recupere isso, idealmente em um Modelo de Design, no formulário de UML. A recuperação dos artefatos de documentário navegáveis também tem valor significativo na permissão para que o Arquiteto de Software veja como o código está realmente estruturado, quando a documentação não existe ou está fora da data
- Para analisar qualquer Modelo de Design, colete as métricas de qualidade (como
acoplamento) que estão relacionadas em
Artefato: Plano de Medida
e verifique a conformidade com o
Artefato: Documento de Arquitetura de Software
e as
Diretrizes de Design
- Para saber sobre as mudanças arquiteturais ou o design significativos para que
a ação corretiva possa ser realizada, se necessário. A importância é avaliada pelos
critérios definidos pelo Arquiteto de Software
Teoricamente, essas necessidades poderiam ser preenchidas por inspeção; na prática,
para sistemas maiores, mais complexos, algum tipo de assistência automatizada é essencial.
As seguintes seções fornecem alguma elaboração desses tópicos e exemplos do suporte da
ferramenta.
Descoberta da Arquitetura e Recuperação
Informações Detalhadas
No desenvolvimento Greenfield, o arquiteto de software emerge dos requisitos, do contexto de
domínio e das convenções (incluindo padrões e mecanismos);
o artefato de Especificações Suplementares
tem uma função importante na determinação da arquitetura. Esse processo de
modelagem da arquitetura de software é, às vezes, chamado de descoberta porque raramente
é um mapeamento direto e mecânico dos requisitos para a arquitetura.
Aqui, no entanto, estamos utilizando a decoberta em um sentido diferente, para descrever
o processo de ajuda ao Arquiteto de Software para compreender um aplicativo existente ou um fragmento
do aplicativo no formulário codificado. A recuperação arquitetural é mais ambiciosa:
por meio da recuperação, não somente o Arquiteto de software procura compreender um aplicativo
masn também extrai um modelo desse aplicativo, idealmente em um nível de abstração compatível
com o Modelo de Design. Existe a possibilidade de mesclar
esses modelos e, por meio da
transformação, gerar um novo
aplicativo, talvez para uma
plataforma diferente.
Descoberta
Nas Atividades:
Análise Arquitetural
(consulte
Desenvolver
Visão Geral da Arquitetura
e
Recursos Disponíveis do
Relatório Sintético) e
Incorporar Elementos de Design Existentes, o Arquiteto de Software procura oportunidades para reutilizar o design existente e os recursos de código. Por exemplo, uma organização pode ter várias Arquiteturas de Referência
em sua base de recurso e idealmente elas estão completas com a documentação e os modelos
atualizados. No entanto, freqüentemente há um pouco mais do que o código fonte e, se há documentação
arquitetural, não é atual.
Em muitos casos, o Arquiteto de Software não pode tratar esse código como black box
(mesmo se as interfaces estiverem claramente definidas) mas precisa entender sua estrutura.
Esse processo é amplamente assistido pela habilidade de gerar automaticamente descrições
navegáveis do código. O Arquiteto de Software pode visualmente 'descobrir'
padrões e antipadrões no código. Um exemplo desse tipo de assistência está localizado
na ferramenta do Rational Software Architect em que o recurso de descoberta da arquitetura
automaticamente ocupará os diagramas de tópico, como a estrutura de pacote, qualidades internas
da classe, árvores de herança e colaborações para aplicativos Java.
Para obter informações adicionais, consulte a documentação de Arquitetura de Software Rational .
Recuperação e Transformação
Quando os recursos reutilizáveis estão completos com modelos, é possível combinar esses
modelos com modelos específicos para o projeto e, em seguida, prosseguir para implementação
específica da plataforma utilizando técnicas de transformação. Quando o código é tudo que existe,
ainda pode ser possível reutilizá-lo mesmo com uma abordagem com base em transformação,
integrando o código produzido a partir da transformação com o código legado.
O Arquiteto de Software tem a maior parte do poder e da flexibilidade por meio da utilização
da recuperação da arquitetura: o recurso de recuperação irá gerar um modelo semanticamente rico
do aplicativo que pode ser utilizado para geração do código assim como para navegação.
Na prática, o código de engenharia reversa de volta a uma representação visual direta
é freqüentemente tratável; abstraindo um modelo de volta ao mesmo nível como um Modelo de Design
independente da plataforma
, em geral, difícil de automatizar completamente.
Isso é essencialmente um
PSM
para a transformação de
PIM
(consulte
Conceitos: MDD (Model-Driven Development )
e MDA® ( Model Driven Architecture®)); o PIM (fragmento) recuperado é combinado com o Modelo de Design (ele mesmo
um PIM) utilizando uma mesclagem de modelo (consulte [OMG03]) tipo de transformação.
Análise de Arquiteturas
ter modelos navegáveis permite que o Arquiteto de Software verifique a qualidade
arquitetural por meio da inspeção. No entanto, isso pode ser tedioso e demorado e verificar
a conformidade de padrões e regras e reunir métricas desse modo é passível de erro. O Arquiteto de Software deve procurar automatizar o máximo possível desse processo, e assim gastar mais tempo localizando e aplicando soluções; a automação
permite que o Arquiteto de Software experimente, pergunte "e se"
e rapidamente verifique o resultado.
O Que Pode ser Automatizado?
A análise arquitetural automatizada pode:
- Localizar padrões e antipadrões (estruturas patológicas) na arquitetura
- Executar medidas em várias estruturas e relatar
métricas
- Verificar a conformidade com as restrições definidas pelo Arquiteto de Software (consulte o
Controle Arquitetural)
A utilização de
padrões
é ditada pelos padrões do projeto e da organização e o rationale para sua utilização
é capturado no Documento de Arquitetura de Software (se tiver significância arquitetural)
ou as Diretrizes de Design. Por meio da análise automatizada, o Arquiteto de Software
pode rapidamente verificar o uso padrão, para verificar se a intenção do Documento do
Arquiteto de Software e as Diretrizes de Design são atendidas. Os antipadrões são
estruturas patológicas, arquiteturais e de design que, de algum modo, enfraquecem
a arquitetura, tornando-a menos robusta, mais complexa ou mais difícil de manter,
por exemplo.
As medidas a serem executadas são relacionadas em Artefato: Plano de Medida
(algumas métricas sugeridas devem ser localizadas em
Diretrizes: Métricas). O Plano de Medida também descreve como uma
métrica deve ser utilizada, por exemplo, se os valores mais altos ou mais baixos são melhores
ou se é a tendência que é importante, então é útil que a análise de métricas também identifique pontos
importantes - locais na arquitetura em que as mudanças gerariam significante aprimoramento nas
métricas coletadas. Não surpreendentemente, isso freqüentemente será associado às
patologias na estrutura. A Arquitetura de Software tem uma base objetiva para aprimoramento,
pode fazer mudanças ou delegar ações de acompanhamento que podem ser testadas assim que estiverem
concluídas.
Qual É o Destino da Análise?
O destino da análise pode variar no ciclo de vida, dependendo da abordagem de desenvolvimento
escolhida. Quando um projto utiliza uma abordagem transformacional (geracional),
o destino normalmente será o Modelo de Design na suposição de que o aplicativo gerado
está sempre sincronizado com o design. Quando um
Artefato: Modelo de Implementação
é criado e mantido separadamente ou quando o código é reutilizado, enfatize as mudanças para o
código, para garantir que retém a integridade arquitetural quando medido no Documento de Arquitetura
de Software e as Diretrizes de Design.
Esse tipo de análise (em um Modelo de Implementação) pode não recuperar um Modelo de Design
explícito do código, para finalidades de análise; ela está, no entanto, preocupada com questões
de arquitetura e design (na medida em que são manifestados no código),
não padrões de codificação.
Um Exemplo desses Conceitos e Recursos
A ferramenta do Arquiteto de Software Rational, além de sua habilidade de recuperar
a documentação para aplicativos Java por meio da descoberta de arquitetura, pode identificar
e relatar em um conjunto de padrões predefinidos que poderiam indicar potenciais locais com problemas
na arquitetura. Esses padrões incluem, entre outros:
- A Borboleta
- O Frágil
- O Hub
- O Nó
A Borboleta
Uma borboleta é um elemento, como uma classe, que tem muitos relacionamentos
com outros elementos dependentes que seriam afetados se a borboleta fosse alterada.
Se os relacionamentos forem diretos, esses elementos serão chamados borboletas
locais. O Arquiteto de Software Rational também pode rastrear relacionamentos na medida
que eles descem por um aplicativo e determinam se as mudanças em um elemento poderiam
afetar não somente os dependentes diretos, mas seus dependentes em vez disso, e assim por
diante transitivamente por todo o aplicativo. Um elemento com muitas dependências diretas
é chamado de borboleta global. Uma ilustração de uma borboleta local
é mostrada a seguir. O diagrama também mostra que os relacionamentos podem ser diferentes das
dependências UML: por exemplo, um elemento é dependente de outro quando o percebe; uma alteração
no elemento de especificação afetará o elemento que o percebe.
Uma Borboleta Local
O Frágil
Um frágil é um elemento que tem muitas dependências; ou seja, tem muitos
relacionamento em que ele depende de outro elemento. Uma alteração para qualquer
desses elementos afetará o frágil. Como com as borboletas, quando os relacionamentos
são diretos, esses elementos são chamados frágeis locais
e frágeis globais se há muitos relacionamentos indiretos que
impactam o elemento. Um frágil global é vulnerável para mudanças em muitas partes de um
aplicativo e indica a falta de modularidade. Uma ilustração de um frágil local
é mostrada a seguir.
Um Frágil Local
O Hub
Um hub é um elemento que combina as características de uma borboleta de
de um frágil. Também tem as formas local e global. A presença de
hubs globais é uma indicação de particionamento fraco, resultando no software que é extremamente
sensível à mudanças que tendem a ondular em todo o aplicativo.
O Nó
Um nó é um grande grupo de elementos cujos relacionamentos são tão enrolados
que uma alteração em qualquer um deles poderia afetar todos os outros. Tais estruturas
são uma origem de maior instabilidade.
O Arquiteto de Software, trabalhando com a ferramenta de Arquiteto de Software Rational,
pode descobrir esses pontos importantes rapidamente e trabalhar com o Designer para retificá-los.
Para obter informações adicionais, consulte a documentação de Arquitetura de Software Rational .
Ocorrência
Os resultados dessas análises são valiosos em qualquer marco de revisão, como evidência
objetiva e quantificável de qualidade arquitetural e de design, ou quando, como em
Atualizar
a Organização do Modelo de Design
(em Atividade: Incorporar Elementos de Design Existente) há mudanças arquiteturais significantes.
Controle Arquitetural
A visão do Arquiteto de Software é capturada no Documento de Arquitetura de Software
e a orientação prática para o Designer é localizada nas Diretrizes de Design.
Mesmo quando essa visão é compartilhada por toda a equipe, às vezes, é obscura pelas exigências
do dia a dia do trabalho do projeto. Com os prazos finais a serem atendidos, os cantos podem
ser cortados e o Arquiteto de software normalmente não pode participar de todas as decisões.
Então surge a questão do controle: como o coordenador de Projeto tem que configurar limites
e monitorá-los (consulte
Atividade: Monitorar Status do Projeto), o Arquiteto do Software
tem uma tarefa análoga para emergir o design e a implementação do software.
O controle arquitetural fornece ao Arquiteto de Software o recurso para criar
regras para reforçar as restrições arquiteturais. Por exemplo, o Arquiteto de Software
pode definir uma regra que levantaria um aviso em todas as realizações de uma interface
específica. A expressão simples dessa regra sem suporte de ferramenta exigiria uma revisão
mais ou menos constante para capturar violações. Com automação, as regras podem ser
codificadas para que as violações do conjunto de regras possa ser capturado durante a análise de
arquitetura. Isso ainda está ocorrendo depois do fato e um ambiente de controle avançado
codificaria as regras no processo de produção do código e do design, evitando que sejam
quebradas em primeiro lugar, mesmo assim, aprimora muito o processo de revisão manual.
A ferramenta do Arquiteto de Software Rational inclui um recurso para aplicativos Java:
o Arquiteto de Software pode definir regras e, em seguida, executar análises para verificar a conformidade.
Para obter informações adicionais, consulte a documentação de Arquitetura de Software Rational .
|