Técnicas de Arquitetura
Abordagem Iterativa e Incremental
É uma abordagem iterativa e incremental que consiste em cinco etapas principais que ajudam a gerar soluções candidatas. Essa solução candidata pode ser refinada ainda mais pela repetição dessas etapas e, finalmente, criar um design de arquitetura que melhor se adapte ao nosso aplicativo. No final do processo, podemos revisar e comunicar nossa arquitetura a todas as partes interessadas.
É apenas uma abordagem possível. Existem muitas outras abordagens mais formais que definem, revisam e comunicam sua arquitetura.
Identificar o objetivo da arquitetura
Identifique o objetivo da arquitetura que forma a arquitetura e o processo de design. Objetivos perfeitos e definidos enfatizam a arquitetura, resolvem os problemas certos no projeto e ajudam a determinar quando a fase atual foi concluída e está pronta para passar para a próxima fase.
Esta etapa inclui as seguintes atividades -
- Identifique seus objetivos de arquitetura no início.
- Identifique o consumidor de nossa arquitetura.
- Identifique as restrições.
Exemplos de atividades de arquitetura incluem construir um protótipo para obter feedback sobre a IU de processamento de pedidos para um aplicativo da Web, construir um aplicativo de rastreamento de pedidos do cliente e projetar a autenticação e arquitetura de autorização para um aplicativo a fim de realizar uma revisão de segurança.
Cenários Chave
Esta etapa coloca ênfase no design que mais importa. Um cenário é uma descrição extensa e abrangente da interação de um usuário com o sistema.
Os cenários principais são aqueles considerados os cenários mais importantes para o sucesso de seu aplicativo. Ajuda a tomar decisões sobre a arquitetura. O objetivo é alcançar um equilíbrio entre os objetivos do usuário, negócio e sistema. Por exemplo, a autenticação do usuário é um cenário-chave porque eles são uma interseção de um atributo de qualidade (segurança) com uma funcionalidade importante (como um usuário se conecta ao seu sistema).
Visão geral do aplicativo
Crie uma visão geral do aplicativo, o que torna a arquitetura mais tangível, conectando-a às restrições e decisões do mundo real. Consiste nas seguintes atividades -
Identificar o tipo de aplicativo
Identifique o tipo de aplicativo, seja ele um aplicativo móvel, um cliente avançado, um aplicativo avançado da Internet, um serviço, um aplicativo da web ou alguma combinação desses tipos.
Identificar restrições de implantação
Escolha uma topologia de implementação apropriada e resolva os conflitos entre o aplicativo e a infraestrutura de destino.
Identificar estilos de design de arquitetura importantes
Identifique estilos de design de arquitetura importantes, como cliente / servidor, em camadas, barramento de mensagens, design orientado por domínio, etc. para melhorar o particionamento e promover a reutilização de design, fornecendo soluções para problemas recorrentes com frequência. Os aplicativos geralmente usam uma combinação de estilos.
Identifique as tecnologias relevantes
Identifique as tecnologias relevantes considerando o tipo de aplicativo que estamos desenvolvendo, nossas opções preferidas para topologia de implementação de aplicativo e estilos de arquitetura. A escolha de tecnologias também será direcionada por políticas da organização, limitações de infraestrutura, habilidades de recursos e assim por diante.
Principais problemas ou principais pontos de acesso
Ao projetar um aplicativo, os pontos críticos são as zonas onde os erros são cometidos com mais frequência. Identifique os principais problemas com base em atributos de qualidade e interesses transversais. Os problemas potenciais incluem o surgimento de novas tecnologias e requisitos críticos de negócios.
Os atributos de qualidade são os recursos gerais de sua arquitetura que afetam o comportamento do tempo de execução, o design do sistema e a experiência do usuário. Interesses transversais são os recursos de nosso design que podem ser aplicados a todas as camadas, componentes e camadas.
Essas também são as áreas em que erros de projeto de alto impacto são cometidos com mais frequência. Exemplos de interesses transversais são autenticação e autorização, comunicação, gerenciamento de configuração, gerenciamento de exceção e validação, etc.
Soluções Candidatas
Depois de definir os pontos de acesso principais, construa a arquitetura de linha de base inicial ou primeiro design de alto nível e, em seguida, comece a preencher os detalhes para gerar a arquitetura candidata.
A arquitetura candidata inclui o tipo de aplicativo, a arquitetura de implantação, o estilo arquitetônico, as opções de tecnologia, os atributos de qualidade e questões transversais. Se a arquitetura candidata for uma melhoria, ela pode se tornar a linha de base a partir da qual novas arquiteturas candidatas podem ser criadas e testadas.
Valide o design da solução candidata em relação aos principais cenários e requisitos que já foram definidos, antes de seguir iterativamente o ciclo e melhorar o design.
Podemos usar picos arquitetônicos para descobrir as áreas específicas do projeto ou para validar novos conceitos. Picos arquitetônicos são um protótipo de design, que determinam a viabilidade de um caminho de design específico, reduzem o risco e determinam rapidamente a viabilidade de diferentes abordagens. Teste picos arquitetônicos em cenários e pontos de acesso principais.
Revisão de Arquitetura
A revisão da arquitetura é a tarefa mais importante para reduzir o custo de erros e para localizar e corrigir problemas de arquitetura o mais cedo possível. É uma maneira bem estabelecida e econômica de reduzir os custos e as chances de falha do projeto.
Reveja a arquitetura frequentemente nos principais marcos do projeto e em resposta a outras mudanças arquitetônicas significativas.
O principal objetivo de uma revisão de arquitetura é determinar a viabilidade de arquiteturas de linha de base e candidatas, que verificam a arquitetura corretamente.
Vincula os requisitos funcionais e os atributos de qualidade com a solução técnica proposta. Também ajuda a identificar problemas e reconhecer áreas de melhoria
As avaliações baseadas em cenários são um método dominante para revisar um design de arquitetura que se concentra nos cenários que são mais importantes do ponto de vista do negócio e que têm o maior impacto na arquitetura. A seguir estão as metodologias de revisão comuns -
Método de Análise de Arquitetura de Software (SAAM)
Ele foi originalmente projetado para avaliar a capacidade de modificação, mas mais tarde foi estendido para revisar a arquitetura com relação aos atributos de qualidade.
Método de Análise de Tradeoff de Arquitetura (ATAM)
É uma versão refinada e aprimorada do SAAM, que analisa as decisões arquitetônicas com relação aos requisitos de atributos de qualidade e como eles satisfazem objetivos de qualidade específicos.
Revisão de Design Ativa (ADR)
É mais adequado para arquiteturas incompletas ou em andamento, que se concentram mais em um conjunto de problemas ou seções individuais da arquitetura por vez, em vez de realizar uma revisão geral.
Avaliações ativas de designs intermediários (ARID)
Ele combina o aspecto ADR de revisão da arquitetura em andamento com foco em um conjunto de questões e a abordagem ATAM e SAAM de revisão baseada em cenários com foco em atributos de qualidade.
Método de Análise de Custo-Benefício (CBAM)
Ele se concentra na análise de custos, benefícios e implicações de cronograma das decisões arquitetônicas.
Análise de Modificabilidade de Nível de Arquitetura (ALMA)
Ele estima a capacidade de modificação da arquitetura para sistemas de informações de negócios (BIS).
Método de Avaliação de Arquitetura Familiar (FAAM)
Ele estima arquiteturas de família de sistemas de informação para interoperabilidade e extensibilidade.
Comunicando o Projeto de Arquitetura
Depois de concluir o design da arquitetura, devemos comunicar o design às outras partes interessadas, que incluem equipe de desenvolvimento, administradores de sistema, operadores, proprietários de negócios e outras partes interessadas.
Existem vários métodos conhecidos a seguir para descrever a arquitetura para outras pessoas: -
4 + 1 modelo
Essa abordagem usa cinco visualizações da arquitetura completa. Entre eles, quatro pontos de vista (ological view, a process view, a physical view, e a development view) descrevem a arquitetura de diferentes abordagens. Uma quinta visualização mostra os cenários e casos de uso do software. Ele permite que os interessados vejam os recursos da arquitetura que os interessam especificamente.
Linguagem de Descrição de Arquitetura (ADL)
Essa abordagem é usada para descrever a arquitetura do software antes da implementação do sistema. Ele aborda as seguintes questões - comportamento, protocolo e conector.
A principal vantagem do ADL é que podemos analisar a arquitetura quanto à integridade, consistência, ambiguidade e desempenho antes de iniciar formalmente o uso do design.
Modelagem Ágil
Esta abordagem segue o conceito de que “o conteúdo é mais importante do que a representação”. Ele garante que os modelos criados sejam simples e fáceis de entender, suficientemente precisos, detalhados e consistentes.
Os documentos de modelo Agile têm como alvo clientes específicos e cumprem os esforços de trabalho desse cliente. A simplicidade do documento garante que haja participação ativa das partes interessadas na modelagem do artefato.
IEEE 1471
IEEE 1471 é o nome abreviado de um padrão formalmente conhecido como ANSI / IEEE 1471-2000, “Prática Recomendada para Descrição de Arquitetura de Sistemas de Software Intensivo”. O IEEE 1471 aprimora o conteúdo de uma descrição arquitetônica, em particular, dando um significado específico para contexto, visualizações e pontos de vista.
Linguagem de modelagem unificada (UML)
Esta abordagem representa três visões de um modelo de sistema. ofunctional requirements view (requisitos funcionais do sistema do ponto de vista do usuário, incluindo casos de uso); the static structural view(objetos, atributos, relacionamentos e operações, incluindo diagramas de classes); e adynamic behavior view (colaboração entre objetos e mudanças no estado interno dos objetos, incluindo sequência, atividade e diagramas de estado).