Criar uma arquitetura de solução

Parte da criação de uma boa arquitetura está investigando estratégias alternativas de arquiteturais. Estratégias alternativas têm benefícios diferentes com base na seleção de plataforma, tecnologias usadas e reutilização de código. Cada estratégia foi projetada e provas de conceito são criadas para investigar os custos e benefícios de cada estratégia. As estratégias são avaliadas em relação aos requisitos de produto e a qualidade e, por fim, uma estratégia é escolhida para ser usado para implementar o produto. Finalmente, segurança e desempenho são preocupações de arquitetura para a qual o trabalho deve ser feito sobre o product inteiro.

Neste tópico

• Criar a arquitetura alternativa Designs de particionamento

• Implantação de arquitetura do sistema de design

• Criar provas de conceito

• Avaliar alternativas

• Selecione a arquitetura

• Desenvolver um modelo de desempenho

Criar a arquitetura alternativa Designs de particionamento

O problema é analisado e abordagens diferentes são consideradas. Um grupo de requisitos são selecionados que representam os principais desafios de negócios e tecnológicos. Examinar as características desses desafios, como a integração de sistemas herdados e prever as necessidades futuras com base em necessidades atuais, a capacidade de reutilização de código e os custos de manutenção.

Criar um diagrama do aplicativo

Usando o modelo de domínio e os requisitos de entrada, crie um diagrama do aplicativo que representa os elementos lógicos do núcleo do sistema. Isso posteriormente ser particionado em diagramas de sistema. Alternativa esquemas de particionamento será considerada e avaliada.

É uma maneira de representar um diagrama do aplicativo como um diagrama de caso de uso (UML Unified Modeling Language). Este tipo de diagrama pode mostrar subsistemas principais e suas dependências. Além disso, você pode colocar os casos de uso em cada subsistema para mostrar qual subsistema gerencia cada cenário do usuário.

Estabelecer os critérios de avaliação

Determine os critérios a serem usados para identificar os requisitos e cenários que representam desafios arquitetônicos. Consulte os documentos de arquitetura empresarial existente de critérios. Revise quaisquer requisitos de negócios, requisitos técnicos e padrões corporativos que devem ser aplicados a novos aplicativos. Captura critérios adicionais que são reconhecidamente significativos arquiteturalmente, como a integração com sistemas herdados, capacidade de reutilização do código, reutilização de plataformas e bibliotecas existentes do fornecedor e controlar os custos de manutenção. Captura critérios adicionais que representam riscos e custos durante a implementação de uma solução técnica.

Selecione um grupo de candidatos de requisitos

Avalie cada qualidade dos requisitos de serviço e requisito contra os critérios de avaliação do produto. Se um requisito representa um desafio de arquitetura, considere um candidato para modelagem. Por exemplo, um requisito que o novo produto deve oferecer suporte a bancos de dados antigos do cliente atende aos critérios da integração com sistemas herdados. Esse requisito é um candidato para modelar como a integração funcionaria.

Selecione um grupo de candidatos de cenários

Avalie cada cenário de acordo com os critérios de avaliação. Se um cenário representa um desafio de arquitetura, considere um candidato para modelagem. Por exemplo, um cenário no qual o usuário baixa uma atualização de cliente atende aos critérios que preocupações com os custos de manutenção. Esse cenário é um candidato para modelagem, a melhor maneira de lidar com atualizações do cliente.

Reduzir o grupo de candidato

Examine os requisitos e cenários de candidato. Remova os cenários e requisitos de duplicar os critérios de avaliação ou melhor são representados por outros requisitos e cenários. Exclui o grupo de candidatos a um grupo de núcleo que representa os principais desafios arquitetônicos, os riscos e os custos do novo aplicativo. Mantenha os cenários e requisitos que melhor representam os critérios de avaliação, que apresentam o maior risco e que apresente o custo potencial mais ao arquitetar uma solução técnica. Mantenha os cenários e os requisitos que são as partes mais abrangentes ou chaves do aplicativo.

Criar critérios de particionamento

Usando os requisitos como motivação, analisar padrões de arquitetura estabelecidos (como fachada ou model-view-controller) e identificar possíveis candidatos para implementação. Identificar padrões de candidato por meio de sua motivação e considere suas vantagens e desvantagens do design em relação a coesão, acoplamento, extensibilidade, adaptabilidade e flexibilidade. Selecione um conjunto de candidatos à implementação como alternativas para avaliação.

Arquitetura do sistema de design e implantação

A arquitetura do sistema define os agrupamentos e configurações de elementos que são identificados no diagrama de aplicativo. Diagramas de sistema são criados que capturam a arquitetura do sistema para cada abordagem de arquitetura possível. Diagramas de implantação mostram as etapas de implantação com base em dependências e funcionalidade básica. Arquiteto de infra-estrutura cria um diagrama de datacenter lógico que descreve a estrutura lógica do Data Center onde o aplicativo será implantado. Os diagramas de implantação são validados em relação a diagrama de datacenter lógico para garantir que os sistemas podem ser implantados.

Criar um modelo de sistema

O arquiteto e desenvolvedor-chefe criam diagramas de sistema do diagrama de aplicativo. Por meio de diagramas de sistema, você pode criar sistemas de aplicativos reutilizáveis como unidades de implantação compondo-los de elementos no diagrama de aplicativo. Você também pode criar sistemas maiores e mais complexos que contêm outros sistemas de forma que você pode usá-los em cenários de sistema distribuído e abstraem os detalhes dos aplicativos desses sistemas. Verifique cada novo arquivo de diagrama para controle de versão.

Você pode representar os diagramas de sistema no Visual Studio das seguintes maneiras:

• Use diagramas de caso. Os cenários de usuário principal são representados como casos de uso e os principais componentes do sistema são mostrados como subsistemas. Cada caso de uso pode ser colocado dentro do subsistema que lida com ele. Para obter mais informações, consulte Diagramas de caso de uso UML: diretrizes.

• Diagramas de componente UML. Esses diagramas permitem que você mostrar os canais de comunicação entre os componentes, além de dependências. Você também poderá criar diagramas de classe para descrever os tipos que são visíveis nas interfaces dos componentes, e você pode criar diagramas de sequência para mostrar suas interações. Para obter mais informações, consulte Diagramas de componente UML: diretrizes, Diagramas de classe UML: diretrizes, e Diagramas de sequência UML: diretrizes.

• Diagramas de camada. Um diagrama de camada descreve a estrutura de bloco do aplicativo. Ela mostra apenas os componentes e as dependências entre elas. Ele tem a vantagem de que, depois que o código é escrito, você pode validar o código e as dependências no diagrama. Para obter mais informações, consulte Diagramas de camada: diretrizes.

Para cada subsistema, você pode criar um pacote que descreve seus tipos e o comportamento mais detalhadamente. Para obter mais informações, consulte Definir pacotes e namespaces.

Criar provas de conceito

Riscos significativos para o projeto podem ser reduzidos com a criação de uma arquitetura à prova de conceito. É importante ao risco de endereço mais cedo possível no projeto para que as decisões estratégicas e arquiteturais principais podem ser feitas enquanto ainda é fácil modificar partes fundamentais da arquitetura. Criar antecipadas provas de conceito reduz incertezas e o risco geral do projeto. Menor risco de projeto e menos incertezas tornam planejamento e estimativa de iterações posteriores mais precisas. Provas de conceito podem ser temporárias e descartados depois que os problemas foram resolvidos, ou eles podem ser criados como a base da arquitetura do núcleo.

Examine o risco

Compreenda os elementos que levam à identificação de riscos ou decisões arquitetônicas. Examine cenários relacionados e a qualidade do serviço. Verifique se há alguma implicação do ambiente de destino.

Planeje a abordagem

Determine a forma de prova de conceito que é necessário. Use os diagramas de aplicativos e do sistema para ajudar a planejar. Resolve apenas o problema arquitetônico é identificado pelo risco. Procure a resolução mais simples.

Compilar e executar a prova de conceitos

Crie a prova de conceito. Você pode implementar a prova de conceito do diagrama de aplicativo. Manter o foco no problema a ser resolvido. Implante a prova de conceito em um ambiente físico que corresponde ao diagrama de datacenter lógico. O ambiente físico deve corresponder às configurações do diagrama lógico de datacenter mais próximo possível. Teste a prova de conceito contra os problemas de alto risco.

Avaliar alternativas

O método de análise do Lightweight arquitetura alternativa (LAAAM) é usado para ajudar a decidir entre diferentes estratégias de arquiteturais para a criação de um aplicativo. O LAAAM normalmente leva um dia para concluir. Comece a criar uma árvore de utilitário que descreve drivers funcionais do aplicativo com base nos requisitos e qualidade de chave. Cada driver é gravada como um cenário que assume a forma de uma instrução que é escrita como contexto, estímulo e resposta. Use uma matriz de avaliação para avaliar como cada estratégia endereça cada cenário.

Criar uma árvore de utilitário

Examine a qualidade dos requisitos de serviço e os requisitos de produto para determinar os principais propulsores da qualidade e a função no aplicativo. Construa uma árvore de utilitário que represente a qualidade geral do aplicativo. O nó raiz da árvore é rotulado utilitário. Normalmente são chamados de nós subsequentes em termos de qualidade padrão como modificação, disponibilidade e segurança. A árvore deve representar a natureza hierárquica das qualidades e fornecer uma base para a priorização. Cada nível da árvore é um ajuste adicional das qualidades. Por fim, essas qualidades tornam-se cenários.

Construir uma matriz de avaliação

Para cada folha na árvore de utilitário, escreva um cenário. O cenário é na forma de contexto, o estímulo e resposta (por exemplo, "em uma operação normal, execute uma transação de banco de dados em menos de 100 milissegundos").

Criar uma planilha ou em uma tabela e insira cada cenário como uma linha nesta matriz de avaliação. Insira cada estratégia de arquitetura como uma coluna. Em cada intersecção das estratégias e cenários, insira uma classificação em uma escala entre 1 e 4.

A classificação deve levar em consideração os seguintes fatores:

• Custo de desenvolvimento é essa solução fácil ou difícil de implementar? Qual é seu impacto em outras áreas?

• Custos operacionais em tempo de execução, essa solução funcionará facilmente ou negativamente afetará usabilidade, desempenho e assim por diante?

• Risco é essa solução certas para o cenário de endereço ou há custos desconhecidos? Essa solução pode ter um impacto negativo na capacidade de acomodar futuros aprimoramentos nos requisitos da equipe?

Se uma verificação de conceito foi criada para uma estratégia, use informações de que uma prova de conceito para ajudar a determinar os valores.

Na parte inferior da tabela, some os valores dos cenários. Use esses valores como entrada para a discussão leva a decisões sobre as arquiteturas alternativas.

Carregue a matriz de avaliação concluída do portal do projeto.

Selecione a arquitetura

Depois que a matriz de avaliação é criada, uma reunião de revisão é mantida para determinar qual arquitetura usar na próxima iteração. A matriz de avaliação e informações que são descobertas de criar provas de conceito é usado para ajudar a tomar uma decisão. Após a arquitetura é selecionada, diagramas da arquitetura são verificados em que a solução de referência e criação de um documento de justificação que captura as razões por trás da seleção.

Preparar para revisão

O arquiteto e desenvolvedor-chefe identificam os revisores apropriados para revisar as arquiteturas propostas e circular documentação para as arquiteturas para cada participante.

Examine a arquitetura do sistema e a arquitetura de implantação

Durante a reunião de revisão, os diagramas de sistema, o relatório de implantação e o diagrama de datacenter lógico são revisadas. O objetivo é escolher uma arquitetura para implementar na próxima iteração.

Considere a avaliação classificações de matriz para cada arquitetura ajudar a avaliar a adequação de cada arquitetura. Considere todas as informações descobertas das provas de conceito, como custo ou complexidade envolvida com a implementação de arquiteturas diferentes. Se o diagrama de datacenter lógico representa um datacenter existente não pode ser modificado, não revisá-lo. Se um Data Center está sendo criado, examine o diagrama de considerações de implantação. Selecione a arquitetura para ser usado. Examine o conceito de arquitetura contra os cenários para validar que a solução atenda às necessidades do cliente e completa.

Criar uma solução de referência

Crie um documento de justificação que captura as decisões da reunião. Carregue-o portal do projeto. Para a arquitetura selecionada, verifique em qualquer aplicativo, sistema ou diagramas de datacenter lógico, como a solução de referência a ser usado para implementar recursos na próxima iteração. Se comunicam com toda a equipe e outras equipes dependentes a decisão sobre qual é a arquitetura é selecionada para a próxima iteração.

Desenvolver um modelo de desempenho

Modelagem de desempenho é usada para identificar e solucionar possíveis problemas de desempenho no aplicativo. Um modelo de desempenho é desenvolvido a partir de uma qualidade de requisito de serviço, em seguida, é dividido em tarefas de desenvolvimento. Cada tarefa de desenvolvimento é atribuída um orçamento de desempenho para implementação.

Identifique os cenários que estão vinculados a qualidade do desempenho do requisito de serviço. Mapear as tarefas de desenvolvimento para os cenários. A qualidade da lista de requisitos de serviço, determine a carga de trabalho para o aplicativo. Usando a carga de trabalho previsões e a qualidade da lista de requisitos de serviço, identificar os objetivos de desempenho para cada cenário de chave. Eles incluem os objetivos como uso de tempo, a taxa de transferência e o recurso de resposta. Identifique os recursos relacionados ao desempenho que foram orçados para atingir os objetivos de desempenho. Alguns exemplos de recursos relacionados ao desempenho são o tempo de execução e largura de banda de rede. Determine a alocação máxima permitida de cada recurso.

Difundir os recursos orçados entre as etapas de processamento para cada cenário. Quando não tem certeza de como alocar o orçamento, fazer suposições melhores ou dividir os recursos uniformemente entre as etapas. Orçamento é ajustado durante a validação. Anexar ou escrever a alocação da tarefa de desenvolvimento apropriadas.

Encontre as alocações de orçamento que representam um risco para alcançar os objetivos de desempenho. Considere as vantagens e desvantagens que ajudam a atender aos objetivos de desempenho, como alternativas de design e implantação. Reavalie a qualidade dos requisitos de serviço, se necessário.

Identifique os cenários que não satisfazem as alocações de orçamento. Medir o desempenho dos cenários. Use protótipos em primeiras iterações se o código não está disponível. Repita as etapas de orçamento, avaliação e validação conforme necessário, usando dados adquirido durante a validação.

Desenvolver um modelo de ameaças

Para obter mais informações, consulte a seguinte página no site da Microsoft: Security Developer Center.