Lista de Verificação: Documento de Arquitetura de Software

Geral

Em geral, o sistema é baseado integralmente na arquitetura porque:

A arquitetura parece ser estável.
A necessidade de estabilidade é estabelecida pela natureza da fase de Construção: em Construção, o projeto normalmente se expande, incluindo desenvolvedores que trabalharão em paralelo e comunicando-se livremente com outros desenvolvedores, conforme eles produzem o produto. O grau de independência e paralelismo necessário na Construção simplesmente não pode ser atingido se a arquitetura não for estável.

A importância de uma arquitetura estável não pode ser desconsiderada. Não se engane pensando que 'o quase bom é o suficiente' \endash instável é instável e é melhor acertar a arquitetura e adiar o começo da Construção em vez de prosseguir. Os problemas de coordenação relacionados à tentativa de corrigir a arquitetura enquanto os desenvolvedores tentam utilizá-la como base facilmente anularão quaisquer benefícios aparentes de um cronograma acelerado. As alterações na arquitetura durante a Construção têm um impacto amplo: elas tendem a ser caras, destruidoras e desmoralizantes.

A dificuldade real em montar a estabilidade arquitetural é que "você não tem idéia daquilo que não sabe"; a estabilidade é medida com relação à alteração esperada. Como resultado, a estabilidade é essencialmente uma métrica subjetiva. No entanto, podemos basear essa subjetividade em mais do que simples hipóteses. A arquitetura em si é desenvolvida considerando-se 'cenários significativos do ponto de vista da arquitetura' \endash subconjuntos de casos de uso que representam o comportamento mais desafiador em termos tecnológicos que o sistema deve suportar. Avaliar a estabilidade da arquitetura envolve assegurar que ela tenha ampla cobertura, que não haverá 'surpresas' na arquitetura mais adiante.

A experiência adquirida com a arquitetura também pode ser um bom indicador: se a taxa de alterações na arquitetura for baixa e permanecer baixa, conforme novos cenários forem abordados, há um bom motivo para acreditar que a arquitetura está se estabilizando. De modo contrário, se cada novo cenário gerar mudanças na arquitetura, é sinal que ela ainda está se desenvolvendo e a definição da baseline ainda não está garantida.
A complexidade do sistema se ajusta à funcionalidade que ele oferece.
A complexidade conceitual é apropriada devido à habilidade e experiência de seus:
- users
- operadores
- desenvolvedores
O sistema tem uma única arquitetura, consistente e coerente.
O número e os tipos de componentes são razoáveis.
O sistema tem um recurso de segurança consistente em todo o sistema. Todos os componentes de segurança trabalham juntos para proteger o sistema.
O sistema atingirá os objetivos de disponibilidade.
Caso ocorra uma falha, a arquitetura permitirá que o sistema seja recuperado dentro do período necessário.
Os produtos e as técnicas nos quais o sistema é baseado correspondem à duração esperada?
- Um sistema interino (tático) de pouca duração pode ser criado com segurança utilizando-se tecnologia antiga porque em breve será descartado.
- Um sistema com expectativa de longa duração (a maioria dos sistemas) deve ser criado com base em tecnologias e métodos atualizados para que possa ser mantido e expandido de forma a atender às necessidades futuras.
A arquitetura fornecida define interfaces claras que permitem o particionamento para desenvolvimento da equipe paralela.
O designer de um elemento de modelo pode ter conhecimento suficiente de arquitetura para projetá-lo e desenvolvê-lo corretamente.
A abordagem de pacotes reduz a complexidade e melhora o entendimento.
Os pacotes foram definidos para serem altamente coerentes dentro do pacote, embora eles mesmos tenham pouca relação entre si.
Foram consideradas soluções similares dentro do domínio de aplicativo comum.
A solução proposta pode ser facilmente compreendida por um profissional com conhecimento geral do domínio de problema.
Todos os membros da equipe compartilham a mesma visão da arquitetura que a apresentada pelo arquiteto de software.
O Documento de Arquitetura de Software é atual.
O Guia de Design foi seguido.
Todos os riscos técnicos foram reduzidos ou considerados em um plano de contingência. Os novos riscos descobertos foram documentados e analisados quanto ao seu impacto em potencial.
Os principais requisitos de desempenho (orçamentos estabelecidos) foram atendidos.
Casos de teste, infra-estruturas de teste e configurações de teste foram identificados.
A arquitetura não parece estar "superprojetada".
- Os mecanismos existentes parecem ser simples o bastante para serem utilizados.
- O número de mecanismos é modesto e consistente com o escopo do sistema e as demandas do domínio de problema.
Todas as realizações de casos de uso definidas para a iteração atual podem ser executadas pela arquitetura, conforme demonstrado por diagramas que descrevem:
- Interações entre objetos,
- Interações entre tarefas e processos,
- Interação entre nós físicos.

Modelos

Considerações Sobre Análise Arquitetural

Gerais

O particionamento e a divisão em camadas dos subsistemas e pacotes são consistentes em termos lógicos.
Todos os mecanismos de análise foram identificados e descritos.

Subsistemas

Os serviços (interfaces) de subsistemas das camadas superiores foram definidos.
As dependências entre subsistemas e pacotes correspondem aos relacionamentos de dependência entre as classes contidas.
As classes de um subsistema oferecem suporte aos serviços identificados para o subsistema.

Classes

As principais classes de entidade e os respectivos relacionamentos foram identificados.
Os relacionamentos entre as principais classes de entidade foram definidos.
O nome e a descrição de cada classe reflete claramente o papel que ela desempenha.
A descrição de cada classe captura com precisão as responsabilidades da classe.
As classes de entidade foram mapeadas para mecanismos de análise quando apropriado.
Os nomes de papéis de agregações e associações descrevem com precisão o relacionamento entre as classes relacionadas.
As multiplicidades dos relacionamentos estão corretas.
As principais classes de entidade e os respectivos relacionamentos são consistentes com o modelo de negócios (se aplicável), o domínio do negócio (se aplicável), os requisitos e as entradas de glossário.

Considerações sobre Modelo Geral

O modelo está em um nível de detalhes apropriado dados os objetivos do modelo.

Para o modelo de negócios, o modelo de requisitos ou o modelo de design durante a fase de elaboração, não há uma ênfase exagerada nas questões de implementação.

Para o modelo de design na fase de construção, há um bom equilíbrio de funcionalidade entre os elementos do modelo, utilizando composição de elementos relativamente simples para criar um design mais complexo.

O modelo demonstra familiaridade e aptidão com a amplitude de conceitos de modelagem aplicáveis ao domínio de problema; as técnicas de modelagem são utilizadas adequadamente para o problema em questão.

Os conceitos são modelados com o máximo de simplicidade.

O modelo pode ser expandido com facilidade; as mudanças esperadas podem ser facilmente acomodadas.

Ao mesmo tempo, o modelo ainda não foi estruturado em demasia para lidar com mudanças improváveis, à custa de simplicidade e entendimento.

As principais suposições por trás do modelo estão documentadas e visíveis para os revisores do modelo. Se as suposições forem aplicáveis a uma dada iteração, o modelo deve poder ser desenvolvido dentro dessas suposições, mas não necessariamente fora delas. A documentação de suposições é uma forma de recompensar os designers por não examinarem "todos" os requisitos possíveis. Em um processo iterativo, é impossível analisar todos os requisitos possíveis e definir um modelo que considere todos os futuros requisitos.

Diagramas

A finalidade do diagrama é claramente especificada e facilmente compreendida.
O layout gráfico é simples e transmite com clareza as informações pretendidas.
O diagrama contém informações suficientes para atingir seu objetivo, porém não mais do que isso.
O encapsulamento é usado com eficiência para encobrir detalhes e melhorar a clareza.
A abstração é usada com eficiência para encobrir detalhes e melhorar a clareza.
A colocação de elementos do modelo transmite os relacionamentos de modo eficaz; elementos similares ou bastante relacionados são agrupados.
Os relacionamentos entre os elementos do modelo são fáceis de entender.
A identificação dos elementos do modelo colabora para o entendimento.

Documentação

Cada elemento do modelo tem uma finalidade distinta.
Não existem elementos supérfluos do modelo; cada elemento desempenha um papel fundamental no sistema.

Recuperação de Erro

Para cada erro ou exceção, uma política define como o sistema é restaurado para um estado "normal".
Para cada tipo possível de erro de entrada do usuário ou de dados errados de sistemas externos, uma política define como o sistema é restaurado para um estado "normal".
Há uma política aplicada de forma consistente no tratamento de situações excepcionais.
Há uma política aplicada de forma consistente no tratamento de dados danificados no banco de dados.
Há uma política aplicada de forma consistente no tratamento da não-disponibilidade do banco de dados, que inclusive determina se ainda é possível inserir dados no sistema e armazená-los posteriormente.
Se os dados são trocados entre os sistemas, há uma política que define como os sistemas sincronizam suas visões de dados.
Se o sistema utilizar processadores ou nós redundantes para fornecer tolerância a falhas ou alta disponibilidade, há uma estratégia para assegurar que dois processadores ou nós não 'pensem' que eles são principais ou que nenhum processador ou nó é o principal.
Os modos de falha de um sistema distribuído foram identificados e estratégias foram definidas para tratar das falhas.

Transição e Instalação

O processo para atualizar um sistema existente sem perda de dados ou capacidade operacional foi definido e testado.
O processo para converter os dados usados pelas releases anteriores foi definido e testado.
O tempo e os recursos necessários para atualizar ou instalar o produto foram informados e documentados.
A funcionalidade do sistema pode ser ativada em um caso de uso por vez.

Administração

O espaço em disco pode ser reorganizado ou recuperado enquanto o sistema está em execução.
As responsabilidades e os procedimentos de configuração do sistema foram identificados e documentados.
O acesso ao sistema operacional ou às funções de administração é restrito.
Os requisitos de licenciamento foram atendidos.
As rotinas de diagnóstico podem ser executadas enquanto o sistema está em execução.
O próprio sistema monitora o desempenho operacional (por exemplo, limite de capacidade, limite crítico de desempenho, exaustão de recursos).
- As ações executadas quando os limites são atingidos estão definidas.
- A política de tratamento de alarmes foi definida.
- O mecanismo de tratamento de alarmes foi definido e testado e seu protótipo foi construído.
- O mecanismo de manipulação de alarme pode ser 'ajustado' para evitar alarmes falsos ou redundantes.
As políticas e os procedimentos de monitoramento e administração da rede (LAN, WAN) foram definidos.
As falhas ocorridas na rede podem ser isoladas.
Há um recurso de rastreamento de eventos que pode ser ativado para auxiliar na detecção e resolução de problemas.
- As despesas gerais indiretas do recurso foram informadas.
- O pessoal de administração sabe usar o recurso com eficiência.
Um usuário mal-intencionado não pode:
- acessar o sistema.
- destruir dados importantes.
- consumir todos os recursos.

Desempenho

Os requisitos de sistema são razoáveis e refletem restrições reais no domínio de problema; a especificação desses requisitos não é arbitrária.

Existem estimativas de desempenho do sistema (modeladas conforme necessário através de um Modelo de Análise de Carga de Trabalho) e elas indicam que os requisitos de desempenho não são riscos significativos.

As estimativas de desempenho do sistema foram validadas utilizando-se protótipos arquiteturais, principalmente para requisitos cruciais de desempenho.

Utilização de Memória

A capacidade de memória do aplicativo foi definida.
Foram executadas ações para detectar e impedir problemas de memória.
Há uma política aplicada de forma consistente para definir como o sistema de memória virtual é usado, monitorado e ajustado.

Custo e Planejamento

O número real de linhas de código desenvolvidas corresponde ao número estimado de linhas de código no marco atual.
As hipóteses de cálculo foram revisadas e continuam válidas.
As estimativas de custo e cronograma foram recalculadas utilizando-se a experiência do projeto e o desempenho de produtividade mais atuais.

Portability

Os requisitos de portabilidade foram atendidos.
O Guia de Programação oferece orientações específicas sobre como criar um código portátil.
O Guia de Design oferece orientações específicas sobre como projetar aplicativos portáteis.
Uma 'porta de teste' foi criada para verificar as reivindicações de portabilidade.

Confiabilidade

As medidas de qualidade (MTBF, número de defeitos pendentes, etc.) foram atendidas.
A arquitetura permite a recuperação em caso de erro irreversível ou falha do sistema.

Segurança

Os requisitos de segurança foram atendidos.

Problemas Organizacionais

As equipes estão bem-estruturadas? As responsabilidades foram bem divididas entre as equipes?
Existem questões políticas, organizacionais ou administrativas que restringem a eficiência das equipes?
Existem conflitos de personalidade?

A Visualização de Casos de Uso

A seção Visualização de Casos de Uso do Documento de Arquitetura de Software:

cada caso de uso é arquiteturalmente significativo, identificado como tal porque:
- é vitalmente importante para o cliente
- motiva elementos-chave nas outras visualizações
- é um condutor para atenuar um ou mais riscos importantes, incluindo qualquer requisito desafiador não-funcional.
não há nenhum caso de uso cujas preocupações arquiteturais já estejam abordadas por outro caso de uso
os aspectos arquiteturalmente significativos do caso de uso são claros e não se perdem em detalhes
o caso de uso é claro e provavelmente não é alterado de maneira que afete a arquitetura ou há um plano no local para como atingir tal clareza e estabilidade
nenhum caso de uso arquiteturalmente significativo foi perdido (pode requer alguma análise dos casos de uso não selecionados para esta visualização).

A Visualização Lógica

A seção Visão Lógica do Documento de Arquitetura de Software:

apresenta de forma precisa e completa uma visão geral dos elementos do design que são significativos do ponto de vista da arquitetura.
apresenta o conjunto completo de mecanismos de arquitetura utilizados no design e os fundamentos usados para selecioná-los.
apresenta a divisão em camadas do design, junto com os fundamentos usados para dividir as camadas.
apresenta quaisquer frameworks ou padrões utilizados no design, junto com os fundamentos usados para selecioná-los.
O número de elementos do modelo que são significativos do ponto de vista da arquitetura é proporcional ao tamanho e ao escopo do sistema e seu tamanho ainda torna compreensíveis os principais conceitos em atividade no sistema.

A Visualização do Processo

Utilização de Recursos

As condições de disputa em potencial (concorrência de processos para recursos críticos) foram identificadas e foram definidas estratégias de prevenção e resolução.
Há uma estratégia definida para manipular condições "fila de E/S cheia" ou "buffer cheio".
O próprio sistema monitora seu desempenho (limite de capacidade, limite de desempenho crítico, exaustão de recursos) e é capaz de executar ações corretivas quando um problema é detectado.

Desempenho

Os requisitos de tempo de resposta de cada mensagem foram identificados.
Há um modo de diagnóstico do sistema que permite medir os tempos de resposta das mensagens.
Os requisitos de desempenho nominal e máximo para operações importantes foram especificados.
Há um conjunto de testes de desempenho capaz de avaliar se os requisitos de desempenho foram atendidos.
Os testes de desempenho abordam o comportamento "extra-normal" do sistema (inicialização e encerramento, fluxos de eventos alternativos e excepcionais dos casos de uso, modos de falha do sistema).
Foram identificadas as deficiências de arquitetura que geram possibilidades de gargalos de desempenho. Foi dada ênfase específica:
- Ao uso de alguns recursos compartilhados finitos, incluindo, entre outros, semáforos, handles de arquivo, bloqueios, travas, memória compartilhada etc.
- À comunicação entre os processos. A comunicação entre as fronteiras dos processos sempre é mais dispendiosa do que a comunicação dentro do processo.
- À comunicação entre os processadores. A comunicação entre as fronteiras dos processos sempre é mais dispendiosa do que a comunicação entre os processos.
- Ao uso de memória física e virtual; no momento em que o sistema fica sem memória física e começa a usar a memória virtual, o desempenho costuma cair abruptamente.

Tolerância a Falhas

Quando há processos principais e de backup, foi considerada a possibilidade de existir mais de um processo que acredite ser o principal (ou a possibilidade de não existir um processo que acredite ser o principal) e ações de design específicas foram executadas para resolver o conflito.
Há processos externos que restaurarão o sistema para um estado consistente quando um evento, como uma falha de processo, colocar o sistema em um estado inconsistente.
Quando o sistema tem recursos de tolerância a erros e exceções, como quando ocorre um erro ou exceção, ele pode voltar para um estado consistente.
Os testes de diagnóstico podem ser executados enquanto o sistema está em execução.
Se necessário, o sistema pode ser atualizado (hardware, software) enquanto está em execução.
Há uma política consistente para lidar com alarmes do sistema e a política foi aplicada de forma consistente. A política de alarmes leva em consideração:
- a "sensibilidade" do mecanismo de relatório de alarme;
- a prevenção de alarmes falsos ou redundantes;
- os requisitos de treinamento e interface de usuário do pessoal que utilizará o mecanismo de registro de alarmes.
O desempenho do mecanismo de relatório de alarme foi avaliado e está dentro dos limites de desempenho aceitáveis, conforme estabelecido nos requisitos de desempenho.
Os requisitos de carga de trabalho/desempenho foram analisados e atendidos. Nas situações em que os requisitos de desempenho são impraticáveis, eles foram renegociados.
A capacidade de memória, se houver, foi identificada e o software foi verificado para atender a esses requisitos. Foram tomadas medidas para detectar e impedir problemas de memória.
Existe uma política para uso do sistema de memória virtual que define inclusive como monitorar e ajustar o uso.

Modularidade

Os processos são suficientemente independentes uns dos outros e, quando necessário, podem ser distribuídos entre processadores ou nós.
Foram identificados os processos que devem permanecer no mesmo local (devido aos requisitos de desempenho e taxa de transferência ou ao mecanismo de comunicação entre os processos \endash por exemplo, semáforos ou memória compartilhada) e o impacto de impossibilidade de distribuição desta carga de trabalho foi levado em consideração.
As mensagens que podem se tornar assíncronas, para que possam ser processadas quando houver mais recursos disponíveis, foram identificadas.

A Visualização da Implementação

Os requisitos de taxa de transferência foram atendidos mediante a distribuição do processamento entre os nós e as possibilidades de gargalos de desempenho foram consideradas.
A integridade das informações é assegurada nas situações em que elas são distribuídas e possivelmente replicadas entre diversos nós.
Foram atendidos os requisitos para o transporte confiável de mensagens, como, por exemplo, verificar se elas existem.
Foram atendidos os requisitos para o transporte seguro de mensagens, como, por exemplo, verificar se elas existem.
O processamento foi distribuído entre os nós para minimizar o tráfego de rede e o tempo de resposta, estando sujeitos a restrições de consistência e recursos.
Os requisitos de disponibilidade do sistema, se houver, foram atendidos.
- O tempo máximo de inatividade do sistema, caso ocorra uma falha no servidor ou na rede, foi determinado e está dentro dos limites aceitáveis, conforme definido pelos requisitos.
- Servidores redundantes e de espera foram definidos de tal forma que não é possível para mais de um servidor ser designado como o servidor "principal".
Todos os possíveis modos de falha foram documentados.
As falhas na rede podem ser isoladas, diagnosticadas e resolvidas.
A quantidade de "espaço livre" na utilização da CPU foi identificada e o método de medida foi definido
Há uma política definida para as ações a serem tomadas quando a capacidade de utilização máxima da CPU for atingida.