A arquitetura de um sistema de Software de modelagem.

Artigo
02/25/2013

Para ajudar a garantir que seu sistema ou aplicativo de software satisfazem às suas necessidades de usuários, você pode criar modelos em Visual Studio Ultimate como parte de sua descrição da estrutura geral e comportamento do sistema ou aplicativo de software.Usando modelos, você também pode descrever os padrões que são usados durante qualquer design.Esses modelos ajudam você a entender a arquitetura existente, para discutir as alterações, e a comunicar claramente suas intenções.

O objetivo de um modelo é reduzir ambiguidades que ocorrem em descrições de linguagem natural, e ajudar o e seus colegas para visualizar o design e a discutir designs alternativo.Um modelo deve ser usado junto com outras documentos ou discussões.Por si só, um modelo não representa uma especificação completo de arquitetura.

Observação
Em todo este tópico, “sistema” significa o software que você está desenvolvendo.Pode ser uma grande coleção de muitos componentes de software e de hardware, ou um único aplicativo, ou uma parte de um aplicativo.

A arquitetura de um sistema pode ser dividida em duas áreas:

Design de alto nível.Isso descreve os principais componentes e como interagem um com o outro para satisfazer cada requisito.Se o sistema é grande, cada componente pode ter seu próprio design de alto nível que mostra como é composta de componentes menores.
Padrões de design e convenções usados em todos os projetos de componentes.Um padrão descreve uma abordagem específico para obter um objetivo de programação.Usando os mesmos padrões em todo um design, sua equipe pode reduzir o custo de fazer o software de alterações e desenvolvendo novo.

Design de alto nível

Um design de alto nível descreve os principais componentes do sistema e como interagem um com o outro para obter as metas de design.As atividades na lista a seguir são envolvidas na desenvolver o design de alto nível, embora não necessariamente em uma sequência específica.

Se você estiver atualizando o código existente, você pode iniciar seres componentes principais.Certifique-se de que você entender as alterações aos requisitos de usuário e adicionar ou alterar interações entre os componentes.Se você estiver desenvolvendo um novo sistema, inicie entender os principais recursos das necessidades de usuários.Você pode explorar em sequências das interações para exemplos de uso de chave, e consolida em sequências em um componente design.

Em todos os casos, é útil desenvolver paralelamente as atividades diferentes, e desenvolver código e os testes em uma etapa inicial.Evite que tenta conclua um desses aspectos antes de iniciar outra.Normalmente, ambos os requisitos e seu conhecimento de melhor maneira de criar o sistema serão alterados quando você estiver escrevendo e testando o código.Portanto, você deve iniciar entender e codificar os principais recursos e dos requisitos do seu design.Preencha os detalhes em uma iterações posteriores do projeto.

Entendendo os requisitos.O ponto de partida de qualquer design é uma compreensão criptografada das necessidades de usuários.
Padrão arquitectónicos.As opções que você fez sobre tecnologias de núcleo e elementos arquitectónicos do sistema.
Componentes e suas interfaces.Você pode desenhar diagramas componentes para mostrar os maior parte do sistema, e mostra as interfaces através de que interagem um com o outro.As interfaces de cada componente incluem todas as mensagens que você tenha identificado em diagramas de sequência.
Interações entre componentes.Para cada caso de uso, evento, ou mensagens de entrada, você pode desenhar um diagrama de sequência que mostra como os componentes principais do sistema interagem para obter a resposta necessário.
Modelo de dados dos componentes e interfaces.Você pode desenhar diagramas de classe para descrever informações que são passadas entre componentes e armazenadas nos componentes.

Entendendo os requisitos

O design de alto nível de um aplicativo completo é desenvolvido o mais efetivamente juntamente com um modelo de requisitos ou outra descrição das necessidades de usuários.Para obter mais informações sobre modelos de requisitos, consulte Requisitos do usuário de modelagem..

Se o sistema que você está desenvolvendo é um componente em um sistema maior parte, ou todos os seus requisitos podem ser personificados em interfaces programação.

O modelo desses requisitos fornece informações de informações essenciais:

Como interfaces.Uma interface fornecida lista os serviços ou operações que o sistema ou componente devem fornecer aos usuários, se é usuários humanos ou outros componentes de software.
Interfaces necessárias.Uma interface necessário lista os serviços ou operações que o sistema ou componente podem usar.Em alguns casos, você poderá criar todos esses serviços como parte do seu próprio sistema.Em outros casos, especialmente se você estiver criando um componente que pode ser combinado com outros componentes em muitas configurações, será necessário a interface definida por considerações externos.
Qualidade de requisitos de serviço.O desempenho, segurança, vigor, e outros meta e restrições que o sistema deve encontrar.

O modelo de requisitos é escrito no ponto de vista de seus usuários do sistema, se forem pessoas ou outros componentes de software.Não conhecem nada de funcionamento interno do seu sistema.Por outro lado, o objetivo em um modelo arquitetural é descrever o funcionamento interno e mostrar como atendem às necessidades de usuários.

Manter os requisitos e modelos arquitectónicos separados é útil porque facilita discutir os requisitos com os usuários.Também ajuda você refatora o design e considera arquiteturas alternativos para manter os requisitos inalterados.

Você pode separar os requisitos e modelos arquitectónicos em duas maneiras alternativas:

Manter-los na mesma solução mas em projetos diferentes.Aparecerá como modelos separados no modelo de UML Explorer.Os membros da equipe diferentes podem trabalhar paralelamente modelos.Os tipos limitado de rastreamento podem ser criados entre os modelos.
Colocado no mesmo modelo de UML, mas em pacotes diferentes.Isso facilita rastreamento dependências entre os modelos, mas impede que mais de uma pessoa de cada vez de como trabalhar no modelo.Além disso, um modelo muito grande levará mais tempo para carregar no Visual Studio.Essa abordagem é portanto menos adequada para projetos grandes.

A quantidade de detalhe que você deve colocar em requisitos ou modelo de arquitetura depende de escala de projeto e de tamanho e de distribuição de equipe.Uma equipe pequena em um projeto curto pode ir não adicional de estruturar um diagrama de classe conceitos de negócios e de qualquer criar padrão; um grande projeto distribuído sobre mais de uma região precisaria significativamente mais detalhes.

Padrão arquitectónicos

No início em um desenvolvimento, você precisará escolher as tecnologias e os principais elementos de que o design depende.Nas áreas que essas opções devem ser feitas incluem o seguinte:

Opções de base de tecnologias, como a escolha entre um banco de dados e um sistema de arquivos, e a escolha entre um aplicativo e conectado um cliente da web, e assim por diante.
Opções de estruturas, como uma escolha entre Windows Workflow Foundation ou a entidade Framework ADO.NET.
Opções de método de integração, por exemplo entre um barramento serviço de empresa ou um canal ponto a ponto.

Essas opções são frequentemente determinadas qualidade de requisitos de serviço como a escala e a flexibilidade, e podem ser executadas antes que os requisitos detalhados são conhecidos.Em um grande sistema, a configuração de hardware e software são altamente relacionados.

Opções que você faz a influência como você usa e interpreta o modelo de arquitetura.Por exemplo, em um sistema que usa um banco de dados, as associações em um diagrama de classe podem representar relações ou chaves estrangeiras no banco de dados, enquanto em um sistema que é baseado em arquivos XML, as associações podem indicar as referências cruzadas que usam o XPath.Em um sistema distribuído, as mensagens em um diagrama de sequência podem representar mensagens em um fio; em um aplicativo independente, podem representar chamadas de função.

Componentes e suas interfaces

As recomendações chave desta seção são:

Crie diagramas componentes para mostrar os principais partes do seu sistema.
Desenhar dependências entre os componentes ou suas interfaces para exibir a estrutura do sistema.
Use interfaces componentes para mostrar os serviços que cada componente fornece ou requer.
Em um grande design, você pode desenhar diagramas separados para decompr cada componente em partes menores.

Esses pontos são elaborados no restante desta seção.

Componentes

Exibições central de um modelo de arquitetura diagramas são os componentes que mostram a maior parte do sistema e como dependem de outro.Para obter mais informações sobre diagramas componentes, consulte Diagramas de componente UML: referência.

UML diagrama mostrando componentes

Um diagrama componente típico para um grande sistema pode incluir como esses componentes:

Apresentação.O componente que fornece acesso ao usuário, executando normalmente em um navegador da Web.
Componentes de serviço Web.Fornece a conexão entre servidores e clientes.
Use controladores dos casos.Unidade o usuário pelas etapas de cada cenário.
Núcleo de negócios.Contém classes que são baseados em classes nos requisitos de padrão, implementam as operações principais, e impor restrições de negócios.
Banco de dados.Armazena os objetos de negócios.
Componentes de log e de manipulação de erro.

Dependências entre componentes

Além dos componentes eles mesmos, você pode mostrar as dependências entre eles.Uma seta de dependência entre dois componentes que mostra as alterações no design de um podem afetar o design do outro.Isso geralmente ocorre porque um componente usa os serviços ou funções que são fornecidos por outro componente, direta ou indiretamente.

Uma arquitetura bem estruturado tem uma organização criptografada das dependências, em que essas condições forem verdadeiras:

Não há nenhum loop no gráfico de dependência.
Componentes podem ser organizados em camadas em que cada dependência vai de um componente em uma camada a um componente do seguir.Todas as dependências entre todas as duas camadas vão na mesma direção.

Você pode mostrar dependências diretamente entre componentes, ou você pode mostrar as dependências entre necessário e como as interfaces que estão anexados a componentes.Usando interfaces, você pode definir operações que são usadas em cada dependência.Normalmente, as dependências entre componentes são mostradas quando os diagramas são primeiro desenhado, e então substituídas pelas dependências entre interfaces como obter mais informações é adicionada.Ambas as versões corretas são descrições de software, mas a versão com interfaces fornece mais detalhes da versão anterior.

Gerencie dependências é o mais importante para a produção de software sustentável.Diagramas os componentes devem refletir todas as dependências em seu código.Se o código já existir, certifique-se de que todas as dependências são mostradas em diagramas.Se o código está sendo desenvolvido, certifique-se de que não inclui as dependências que são não planejado no diagrama componente.Para ajudá-lo a descobrir dependências no código, você pode gerar diagramas de camada.Para ajudar a garantir que as restrições planejado de dependência estão localizadas, você pode validar o código contra diagramas de camada.Para obter mais informações, consulte Diagramas de camada: referência.

Interfaces

Colocando interface em seus componentes, você pode separar e nomear os grupos de operações principais que são fornecidas por cada componente.Por exemplo, os componentes em um sistema baseados na web de vendas podem ter uma interface através do qual os clientes bens compram, uma interface com que fornecedores atualizar seus catálogos, e uma terceira interface através do sistema é gerenciado.

Um componente pode ter qualquer número de interfaces fornecidas e necessárias.Como as interfaces mostram a serviços que o componente fornece outros componentes para uso.As interfaces necessárias mostram serviços que o componente usa em outros componentes.

Se você define como e interfaces necessárias, esta ajudam a separação limpa o componente do restante de design, para que você possa usar essas técnicas:

Coloque o componente em um chicote de fios de teste em que os componentes adjacentes são simulados pelo chicote de fios de teste.
Desenvolva o componente independentemente dos outros componentes.
Reutilizar o componente em outros contextos acoplando suas interfaces para diferentes componentes.

Quando você deseja definir a lista de operações em uma interface, você pode criar outra exibição de interface em um diagrama de classe de UML.Para fazer isso, localizar a interface no modelo de UML Explorer, e arraste-a em um diagrama de classe.Você pode adicionar operações a interface.

Uma operação em uma interface de UML pode representar qualquer maneira na qual um comportamento de um componente pode ser chamado.Pode representar uma solicitação de serviço da Web, um sinal ou uma interação de qualquer outro tipo, ou uma chamada de função comum de programa.

Para determinar que operações a adicionar, crie diagramas de sequência para mostrar como os componentes interagem um com o outro.Consulte Interações entre componentes.Cada um desses diagramas de sequência mostra as interações que ocorrem nos exemplos diferentes de uso.Assim, você pode gradualmente adicionar à lista de operações na interface de cada componente, pois você explora os exemplos de uso.

Decompor um componente em partes

Você pode aplicar o procedimento que é descrito nas seções anteriores para cada componente.

Em cada componente, você pode mostrar os subcomponentes como as partes.Uma parte é efetivamente um atributo do seu componente pai, que é um tipo de classe.Cada parte tem seu próprio tipo, que pode ser um componente.Você pode colocar esse componente em um diagrama e mostrar as partes.Para obter mais informações, consulte Diagramas de componente UML: diretrizes.

É útil aplicar essa técnica para o sistema inteiro.Certifique-se como um único componente, e mostrar os componentes principais como as partes.Isso ajuda a identificar claramente as interfaces do seu sistema com o mundo externo.

Quando seu design para um componente usa outro componente, você geralmente possui uma opção sobre se representá-la como uma parte ou como um componente separado que você acesse com a requer a interface.

Use as partes nas seguintes situações:

O design do componente pai sempre deve usar o tipo de componente parte.Portanto, o design da parte é integral o design de um componente pai.
O componente pai não tem nenhuma concreta existência de seus próprios.Por exemplo, você poderia ter um componente chamado conceitual a camada de apresentação que representa uma coleção de componentes reais que tratam modos de exibição e interações do usuário.

Componentes separados de uso acessados através das interfaces necessárias nessas situações:

O componente de exigir pode ser acoplado através das suas interfaces para componentes de fornecer diferentes em tempo de execução.
O design é tal que seria fácil substituir um provedor com o outro.

O uso de interfaces necessárias geralmente é preferível o uso das partes.Embora o design possa levar mais tempo, o sistema resultante é mais flexível.Também é mais fácil testar separada os componentes.Isso permite menos encaixe nos planos de desenvolvimento.

Interações entre componentes

As recomendações chave desta seção são:

Identifica os exemplos de uso do seu sistema.
Para cada caso de uso, desenhar um ou mais diagramas para mostrar como os componentes do sistema obtém o resultado necessário colaborando um com o outro e com os usuários.Geralmente, eles são diagramas de sequência ou diagramas de atividade.
O uso interface para especificar as mensagens recebidas por cada componente.
Descreve os efeitos das operações em interfaces.
Repita o procedimento para cada componente, mostrando como as partes interagem.

Por exemplo, em um sistema baseados na web de vendas, o modelo de requisitos pode definir uma compra do cliente como um exemplos de uso.Você pode criar um diagrama de sequência para mostrar as interações que o cliente tem com componentes na camada de apresentação, e para mostrar às interações com que têm depósito e componentes de contabilidade.

Identificando os eventos iniciando

O trabalho feito pela maioria dos sistemas de software convenientemente pode ser dividido por anterior respostas que fornece as entradas ou a eventos diferentes.Iniciando o evento pode ser um dos seguintes eventos:

A primeira ação nos exemplos de uso.Pode aparecer no modelo dos requisitos como uma etapa nos exemplos de uso, ou uma ação em um diagrama de atividade.Para obter mais informações, Diagramas de caso de uso UML: diretrizes e Diagramas de atividade UML: diretrizes.
Uma mensagem em uma interface programática.Se o sistema que você está desenvolvendo é um componente em um sistema maior, deve ser descrito como uma operação em uma das interfaces do componente.Consulte Componentes e suas interfaces.
Uma condição específica que é monitorado pelo seu sistema, ou um evento normal como uma hora.

Descreve computações

Desenhar diagramas de sequência para mostrar como os componentes respondem ao evento inicial.

Desenhar uma corda de salvamento para cada instância de componente que participa em uma sequência típica.Em alguns casos, pode haver mais de uma instância de cada tipo.Se você descreveu o seu sistema inteiro como um único componente, deve haver uma corda de salvamento para cada parte que ele contém.

Para obter mais informações, consulte Diagramas de seqüência UML: diretrizes.

Os diagramas de atividade também são úteis em alguns casos.Por exemplo, se seus componentes têm um fluxo contínuo de dados, você pode descrevê-lo como um fluxo de objeto.Se o componente tem um algoritmo complexo, você pode descrevê-lo como um fluxo de controle.Certifique-se de que você faz claro que o componente é executado cada ação, por exemplo usando comment.Para obter mais informações, consulte Diagramas de atividade UML: diretrizes.

Especifique as operações

Os diagramas mostram as operações que são executadas por cada componente, representado como mensagens em um diagrama de sequência, ou em ações em um diagrama de atividade.

Coletar essas operações juntos para cada componente.Crie interfaces fornecidas componente, e adicione as operações para interfaces.Normalmente, uma interface separada é usada para cada tipo de cliente.As operações são adicionadas o mais facilmente as interfaces no Modelo de UML Explorer.Da mesma forma, coletar as operações que cada componente usa outros componentes, e os coloca nas interfaces necessárias anexadas componente.

É útil adicionar comentários a diagramas de atividade de sequência, ou para observar o que foi obtido após cada operação.Você também pode gravar o efeito de cada operação em sua propriedade de Local Postcondition .

Modelo de dados dos componentes e interfaces

Defina os parâmetros e valores de retorno de cada operação em interfaces componentes.Onde as operações representam invocações como solicitações de serviço Web, os parâmetros são os fragmentos de informações que são fornecidos como parte da solicitação.Onde vários valores são retornados de uma operação, você pode usar parâmetros com a propriedade de Direção definida Para fora.

Cada parâmetro e valor de retorno tem um tipo.Você pode definir esses tipos usando diagramas de classe de UML.Você não tem que represente o detalhes de implementação nesses diagramas.Por exemplo, se você estiver descrevendo os dados que são passados como XML, você pode usar uma associação para representar qualquer tipo de referência cruzada entre nós XML, e usa classes para representar nós.

Use comentários para descrever restrições de negócios em associações e atributos.Por exemplo, se todos os itens na ordem de um cliente devem vir do mesmo fornecedor, você pode descrever essa função em associações entre os itens do pedido e os itens no catálogo do produto, e entre o item de catálogo e o fornecedor.

Padrões de design

Um padrão de design é um contorno de como criar um aspecto específico de software, principalmente um que retorna as partes diferentes do sistema.Adotando uma abordagem uniforme através do projeto, você pode reduzir o custo de design, garantir a consistência na interface do usuário, e reduzir o custo de entender e de alterar o código.

Alguns padrões gerais de design como o observador são conhecidos e diversos aplicável.Além disso, há padrões que são aplicáveis apenas ao seu projeto.Por exemplo, em um sistema de vendas da Web, haverá várias operações no código onde as alterações são feitas para a ordem de um cliente.Para garantir que o estado do pedido é exibido exatamente em cada etapa, todas essas operações devem seguir um protocolo específico para atualizar o banco de dados.

A parte de trabalho da arquitetura de software é determinar qual padrão devem ser adotados através de design.Isso é geralmente uma tarefa em traço, porque os novos padrões e aperfeiçoamentos dos padrões existentes serão descobertos como o projeto progride.É útil organizar o plano de desenvolvimento de modo que você exercite cada um dos padrões-chave de design em uma etapa inicial.

A maioria dos padrões de design em podem ser parte personificados no código de estrutura.A parte do padrão pode ser reduzida a exigir que o desenvolvedor usar classes específicas ou componentes, como uma camada de acesso ao banco de dados que garante que o banco de dados são tratados corretamente.

Um padrão de design é descrito em um documento, e normalmente inclui essas partes:

Nome.
Descrição de contexto no qual é aplicável.Critérios que devem fazer um desenvolvedor considerar aplicar esse padrão?
Breve explicação o problema que resolve.
Modelo de maior parte e suas relações.Essas classes podem ser ou componentes e interfaces, com associações e dependências entre eles.Os elementos geralmente se enquadram em duas categorias:
- Elementos que o desenvolvedor deve replicar em cada parte do código onde o padrão é usado.Você pode usar tipos de modelo para descrever esses.Para obter mais informações, consulte Diagramas de caso de uso UML: referência.
- Elementos que descrevem as classes de estrutura que o desenvolvedor deve usar.
Modelo das interações entre as partes, usando a sequência ou os diagramas de atividade.
Convenções de nomenclatura.
Descrição de como o padrão resolve o problema.
Descrição das variações que os desenvolvedores podem ser capaz adotar.