Pontos de Verificação: Documento de Arquitetura de Software
Tópicos
Em geral, o sistema é baseado integralmente na arquitetura porque:
- A arquitetura parece ser estável.
A necessidade de estabilidade é ditada pela natureza da fase de Construção: na Construção, normalmente o projeto se expande, acrescentando desenvolvedores que trabalharão em paralelo, comunicando-se com outros desenvolvedores à medida que elaboram 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 é 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' - 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 mudanças na arquitetura durante a Construção têm um grande impacto: elas tendem a ser dispendiosas e desanimadoras e a produzir rupturas.
A real dificuldade de analisar a estabilidade da arquitetura é que "você não sabe o que não conhece"; a estabilidade é medida em relação à mudança 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' - 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.
Experiências anteriores com a arquitetura também podem ser um bom indicador: se a taxa de mudanças na arquitetura for baixa e permanecer baixa mesmo com a abrangência de novos cenários, existem bons motivos para crer que ela 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:
- usuários
- 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 que abrange todo o sistema. Todos os componentes de segurança trabalham em conjunto 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 parecer ter sido "projetada com exageros".
- 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.
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.
- 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. Documentar as suposições é uma forma de isentar os designers da responsabilidade de considerar "todos" os requisitos. Em um processo iterativo, é impossível analisar todos os requisitos possíveis e definir um modelo que considere todos os futuros requisitos.
- 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.
- Cada elemento do modelo tem uma finalidade distinta.
- Não existem elementos supérfluos do modelo; cada elemento desempenha um papel fundamental no sistema.
- Para cada erro ou exceção, há uma política que define como o sistema é restaurado para um estado "normal".
- Para cada tipo possível de erro de entrada do usuário ou dados errados de sistemas externos, há uma política que 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 utiliza nós ou processadores redundantes para possibilitar tolerância a falhas ou alta disponibilidade, há uma estratégia para garantir que nenhum par de processadores ou nós 'pense' que eles são os processadores ou nós 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.
- 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.
- 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 tratamento de alarmes pode ser 'ajustado' para impedir 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.
Consulte Pontos de Verificação: Documento de Análise de Carga de Trabalho
- 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.
- 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.
- 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.
- 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.
- Os requisitos de segurança foram atendidos.
- 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 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.
Tópicos
- 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 tratar de condições do tipo "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.
- 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 abrangem o comportamento "extra-normal" do sistema (inicialização e shutdown, 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.
- 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 registro de alarmes;
- 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 impacto sobre o desempenho (ciclos de processo, memória etc.) do mecanismo de registro de alarmes foi avaliado e está dentro de limites de desempenho aceitáveis, conforme estabelecido nos requisitos correspondentes.
- 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.
- 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 - 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.
- 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 reserva foram definidos de forma que não seja possível designar mais de um servidor como o "principal".
- Todos os possíveis modos de falha foram documentados.
- As falhas na rede podem ser isoladas, diagnosticadas e resolvidas.
- O volume de "espaço livre" na utilização da CPU foi identificado e o método de avaliação 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.
Copyright
(c) 1987 - 2001 Rational Software Corporation
| |
|
