Criar uma arquitetura de solução

A parte da criação de uma boa arquitetura investigando estratégias de backup arquitetônicas. As estratégias alternativas têm os benefícios diferentes com base na seleção de plataforma, as tecnologias que são usadas, e codificam reutilização. Cada estratégia é criada e as provas de conceito são criadas para investigar mais os custos e os benefícios de cada estratégia. As estratégias são avaliadas em relação ao produto e os requisitos de qualidade, e uma estratégia é escolhida finalmente para ser usada para implementar o produto. Finalmente, a segurança e o desempenho são os interesses arquitetônicos para que o trabalho deve ser feito sobre o produto inteiro.

Neste tópico

• Criar designs alternativos de particionamento de arquitetura

• Implantação da arquitetura de sistema de design

• Crie provas de conceito

• Avalie alternativas

• Selecione a arquitetura

• Para desenvolver um modelo de desempenho

Criar designs alternativos de particionamento de arquitetura

O problema é analisado, e as abordagens diferentes são consideradas. Um grupo de requisitos é selecionado que representam o negócio chave e desafios tecnologicos. Examine as características desses desafios, como a integração de sistemas herdados, e prever as necessidades futuras com base nas necessidades atuais, em capacidade de código, e no custo de manutenção.

Crie um diagrama de aplicativo

Usando o modelo e os requisitos de domínio como entrada, crie um diagrama do aplicativo que representa os elementos lógicos principais do sistema. Isso será dividido posteriormente em diagramas do sistema. Os esquemas de particionamento de backup serão considerados e valor de tabela.

Uma maneira de representar um diagrama de aplicativo é como um diagrama dos casos de uso do Unified Modeling Language (UML). Esse tipo de diagrama poderá mostrar os subsistemas principais e suas dependências. Além disso, você pode colocar casos de uso em cada subsistema para mostrar que o subsistema gerencia todo cenário do usuário.

Estabeleça critérios de avaliação

Determine os critérios para usar para identificar os requisitos e cenários que representam desafios arquitetônicos significativos. Consulte os documentos existentes da arquitetura da empresa para os critérios. Revise os requisitos empresariais, requisitos técnicos, e padrão da empresa que devem ser aplicadas a novos aplicativos. Capturar os critérios adicionais que são conhecidos para ser arquitectònica significativos, como a integração com sistemas herdados, capacidade de código, reutilizando bibliotecas existentes do fornecedor e plataformas, e os custos de manutenção do controle. Capturar os critérios adicionais que representam riscos e custo do implementar uma solução técnica.

Selecione um grupo de candidato de requisitos

Avalia cada qualidade dos requisitos de serviço e dos requisitos de produto em relação aos critérios de avaliação. Se um requisito representa um desafio arquitetônico, considere-a apenas um candidato para modelagem. Por exemplo, um requisito para que o novo produto deve oferecer suporte a um bases de dados de clientes mais antigos atende aos critérios de integração com sistemas herdados. Esse requisito é candidata para modelar como a integração funcionaria.

Selecione um grupo de candidato de cenários

Cada cenário é avaliada em relação aos critérios de avaliação. Se um cenário representa um desafio arquitetônico, considere-a apenas um candidato para modelagem. Por exemplo, um cenário no qual o usuário baixa uma atualização do cliente atende aos critérios que pertence a um custo de manutenção. Esse cenário é candidata para modelar como melhor atualizações do cliente.

Reduza o grupo de candidato

Revise os cenários e os requisitos de candidato. Remova os cenários e os requisitos que duplicam os critérios de avaliação ou melhor são representados por outros cenários e requisitos. Cortar o grupo de candidato a um grupo central que representa os desafios, os riscos, e o custo arquitetônicos chaves de aplicativos. Manter os cenários e os requisitos que representam melhor os critérios de avaliação, que têm a maioria de risco, e que apresentam o custo os mais potenciais ao architecting uma solução técnica. Manter os cenários e os requisitos que são mais abrangentes ou partes fundamentais do aplicativo.

Crie critérios de particionamento

Usando os requisitos como motivação, analisar padrões arquitetônicos estabelecidos (como fachada ou o modelo-exibição- controlador), e identificar possíveis candidatos para implementação. Identificar padrões de candidato com sua motivação e, considere suas troca de design em relação ao envolvimento, a coesão, a dimensionalidade, a adaptação, e a flexibilidade. Selecione um conjunto de candidatos para a implementação como alternativas para a avaliação.

Arquitetura e implantação do sistema de design

A arquitetura de sistema define os agrupamentos e as configurações de elementos que são identificados no diagrama do aplicativo. Os diagramas de sistema são criados que capturam a arquitetura de sistema para cada abordagem possível da arquitetura. Os diagramas de implantação mostram as etapas da implantação que são baseadas em dependências e retiram o núcleo da funcionalidade do. Um arquiteto de infraestrutura cria um diagrama lógico do datacenter que descreve a estrutura lógica do datacenter onde o aplicativo será implantado. Os diagramas de implantação são validados em relação ao diagrama lógico do datacenter para garantir que os sistemas possam ser implantados.

Crie um modelo do sistema

O arquiteto e desenvolvedor o lead criar diagramas de sistema do diagrama do aplicativo. Em diagramas de sistema, você pode criar sistemas de aplicativo reutilizáveis como as unidades de implantação composto dos elementos do diagrama do aplicativo. Você também pode criar os sistemas maior e mais complexos que contêm outros sistemas de forma que você possa usar nos cenários de sistema distribuídas e abstrair os detalhes de aplicativos nesses sistemas. Fazer check-in de cada arquivo novo diagrama ao controle de versão.

Você pode representar diagramas do sistema em Visual Studio das seguintes maneiras:

• Use diagramas dos casos. Os principais cenários de usuário são representados como casos de uso, e os componentes principais do sistema são mostrados como subsistemas. Cada caso de uso podem ser colocados no subsistema que trata eles. Para obter mais informações, consulte Diagramas de caso de uso UML: diretrizes.

• Diagramas do componente de UML. Esses diagramas permitem mostrar os canais de comunicação entre os componentes, além de dependências. Talvez você também queira criar diagramas da classe para descrever os tipos que são visíveis nas interfaces para os 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 da camada descreve a estrutura do bloco de aplicativo. Mostra apenas componentes e as dependências entre eles. Tem o benefício que, depois que o código é gravado, 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 em mais detalhes. Para obter mais informações, consulte Definindo pacotes e namespaces.

Crie provas de conceito

Os riscos úteis ao projeto podem ser abrandados criando uma amostra de conceito arquitetônica. É importante para o risco de endereço o quanto antes no projeto de modo que as decisões estratégicas e arquitetônicas chaves podem ser feitas enquanto ainda é fácil alterar partes fundamentais da arquitetura. Criar provas de conceito antiga reduzir o risco e desconhecidos totais do projeto. Um mais baixo risco de projeto e menos desconhecidos farão o planejamento e calcular nas iterações posteriores mais precisas. As provas de conceito temporárias e podem ser descartadas após os problemas foram resolvidos, ou podem ser criados como a base da arquitetura de núcleo.

Examine o risco

Entenda os elementos que levam à ID do risco ou das decisões arquitetônicas. Examine relacionadas cenários e requisitos de qualidade de serviço. Verificação para algumas implicações de ambiente de destino.

Criar uma abordagem

Determine o formulário de prova de conceito necessário. Use os diagramas de aplicativo e do sistema ajudar no planejamento. Resolve apenas o problema arquitetônico que é identificado pelo risco. Procure à resolução mais simples.

Criar e executar a prova de conceitos

Compile a prova de conceito. Você pode implementar a prova de conceito de diagrama do aplicativo. Manter o foco no problema seja resolvido. Implantar a prova de conceito a um ambiente físico que é congruente ao diagrama lógico datacenter. O ambiente físico deve corresponder as configurações de diagrama lógico datacenter do mais próximo possível. Testar a prova de conceito contra problemas de alto risco.

Avalie alternativas

O método de análise de backup (LAAAM) da arquitetura de peso leve usado para ajudar a escolher entre arquitetônicas estratégias diferentes para criar um aplicativo. O LAAAM normalmente demora um dia para concluir. Comece criando uma árvore de utilitário que descreve a qualidade chave e drivers funcionais do aplicativo que se baseiam nos requisitos. Cada driver é gravado como um cenário que usa a forma de uma instrução que é gravada como o contexto, o estímulo, e a resposta. Use uma matriz de avaliação para avaliar como cada estratégia endereça cada cenário.

Crie uma árvore do utilitário

Examine a qualidade dos requisitos de serviço e de requisitos de produto determinar os drivers chaves de qualidade e funcionando no aplicativo. Cria uma árvore de utilitário que representa a qualidade geral do aplicativo. O nó raiz da árvore é chamado utilitário. Os nós subsequentes são rotulados normalmente no padrão - termos de qualidade como o modifiability, a disponibilidade, e a segurança. A árvore deve representar a natureza hierárquica das qualidades e fornecer uma base para a priorização. Cada nível na árvore é um refinamento adicional das qualidades. Finalmente, essas qualidades se tornam cenários.

Construir uma matriz de avaliação

Para cada folha na árvore do utilitário, grave um cenário. O cenário está na forma de contexto, de estímulo, e de resposta (por exemplo, “na operação comum, execute uma transação de base de dados com menos de 100 milissegundos”).

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

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

• Os custos de desenvolvimento Essa solução é fácil ou difícil de implementar? Que é seu impacto em outras áreas?

• Custo operacionais Em tempo de execução, esse trabalho da solução facilmente, ou afetará negativamente a usabilidade, o desempenho, e assim por diante?

• Risco Este endereço é determinado da solução o cenário bem, ou há custo desconhecidos? Essa solução pode ter um impacto adverso na capacidade da equipe de acomodar os aperfeiçoamentos futuros os requisitos?

Se uma amostra de conceito foi criada para uma estratégia, use as informações dessa responsabilidade de conceito para ajudar a determinar os valores.

Na parte inferior da tabela, some os valores dos cenários. Use estes números como uma entrada para a discussão que resulta em resoluções sobre as arquiteturas de backup.

Carregar a matriz completa de avaliação ao portal do projeto.

Selecione a arquitetura

Depois que a matriz de classificação é criada, uma atendem a análise será mantida para determinar quais arquitetura deve ser usada na próxima iteração. A matriz e as informações de avaliação que é descoberta de criar as provas de conceito são usadas para ajudar a tomar uma decisão. Depois que a arquitetura é selecionada, os diagramas para a arquitetura farão check-in como a solução de referência, e um documento de justificação é criado que captura as razões por trás de seleção.

Preparar para revisão

O arquiteto e desenvolvedor o lead identificam os revisores apropriadas para examinar as arquiteturas propostos e circulam a documentação para as arquiteturas a cada participante.

Arquitetura de sistema revisão e arquitetura de implantação

Durante a análise, atendem aos diagramas do sistema, o relatório de implantação, e o diagrama lógico do datacenter são verificados. A meta é escolher uma arquitetura para implementar na próxima iteração.

Considere as classificações da matriz de avaliação para cada arquitetura ajuda a avaliar a conformidade de cada arquitetura. Considere todas as informações que é descoberta de provas de conceito como o custo ou a complexidade que são envolvidos com implementar as arquiteturas diferentes. Se o diagrama lógico do datacenter representa um datacenter existente que não pode ser alterado, não o revisar. Se um datacenter estiver sendo criado, revise o diagrama para considerações de implantação. Selecione a arquitetura a ser usada. Revise o conceito arquitetônico nos cenários para validar a solução que atende às necessidades de cliente e está cheio.

Crie uma solução de referência

Criar um documento de justificação que captura as decisões de atendidos. Carregá-lo no portal do projeto. Para a arquitetura selecionada, fazer check-in de qualquer aplicativo, o sistema, ou diagramas lógicos datacenter como a solução de referência usar para implementar recursos na próxima iteração. Se comunique a equipe inteiro e todos as equipes dependentes a resolução sobre a arquitetura é selecionada para a próxima iteração.

Para desenvolver um modelo de desempenho

Modelagem de desempenho é usado para identificar e resolver problemas de desempenho potencial no aplicativo. Um modelo de desempenho é desenvolvido de uma qualidade dos requisitos de serviço, em que é quebrado em tarefas de desenvolvimento. Cada tarefa de desenvolvimento é atribuída um orçamento de desempenho para implementação.

Identifique os cenários que são vinculados à qualidade de desempenho dos requisitos de serviço. Mapeie as tarefas de desenvolvimento para cenários. A qualidade de serviço que os requisitos a seguir, determinam a carga de trabalho para o aplicativo. Usando as estimativas de carga de trabalho e a qualidade dos requisitos de serviço listar, identifique os objetivos de desempenho para cada cenário chave. Esses incluem objetivos como o tempo de resposta, a taxa de transferência, e o uso de recursos. Identifique os recursos relacionados a desempenho que foram incluídos no orçamento para localizar os objetivos de desempenho. Alguns exemplos de recursos relacionados a desempenho são tempo de execução e largura de banda de rede. Determine o máximo de alocação de cada recurso permitida.

Espalhar os recursos incluídos no orçamento pelas etapas de processamento para cada cenário. Quando não se esqueça de como atribuir o orçamento, faça suposições de melhor, ou divida os recursos uniformemente entre as etapas. Orçar é restrita durante a validação. Anexar ou gravar a alocação da tarefa apropriada de desenvolvimento.

Localizar as alocações de orçamento que representa um risco a localizar os objetivos de desempenho. Considere troca que os objetivos de desempenho de atendem a ajuda como alternativas de design e implantação. Reavalie a qualidade de requisitos do serviço se necessário.

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

Para desenvolver um modelo de ameaça

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