A arquitetura de um sistema de Software de modelagem.

Artigo
08/08/2011

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

A finalidade de um modelo é para reduzir as ambigüidades que ocorrem nas descrições de linguagem natural e para ajudar você e seus colegas para visualizar o design e discutir projetos alternativos. Um modelo deve ser usado juntamente com outros documentos ou discussões. Por si só, um modelo não representa uma especificação completa da arquitetura.

Observação
Em todo este tópico, "sistema" significa que o software que você está desenvolvendo. Pode ser uma grande coleção de muitos componentes de hardware e software, 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. Descreve os principais componentes e como eles interagem uns com os outros para atender a cada necessidade. Se o sistema for grande, cada componente pode ter seu próprio design de alto nível que mostra como é composto de componentes menores.
Padrões de design e convenções usadas em todo os designs dos componentes. Um padrão descreve uma abordagem específica para atingir uma meta de programação. Usando os mesmos padrões ao longo de um design, sua equipe pode reduzir o custo de fazer alterações e desenvolvimento de novos softwares.

Design de alto nível

Um design de alto nível descreve os principais componentes de seu sistema e como eles interagem uns com os outros para atingir as metas do projeto. As atividades na lista a seguir estão envolvidas no desenvolvimento de design de alto nível, embora não necessariamente em uma seqüência específica.

Se você estiver atualizando o código existente, você pode começar descrevendo os principais componentes. Certifique-se de compreender as alterações para os requisitos do usuário e adicionar ou modificar as interações entre os componentes. Se você estiver desenvolvendo um novo sistema, comece a Noções básicas sobre os principais recursos do que os usuários precisa. Em seguida, explore as seqüências de interações para os casos de uso principal e, depois, consolidar as seqüências em um projeto do componente.

Em cada caso, ele é útil para desenvolver as diferentes atividades em paralelo e desenvolver o código e testes em uma etapa inicial. Evite tentando concluir um dos seguintes aspectos antes de iniciar outro. Normalmente, os requisitos e o seu conhecimento sobre a melhor maneira de projetar o sistema serão alterado enquanto você estiver escrevendo e testando o código. Portanto, você deve começar a compreensão e os principais recursos do seu projeto e os requisitos de codificação. Preencha os detalhes de iterações posteriores do projeto.

Noções básicas sobre os requisitos de. O ponto de partida de qualquer design é uma compreensão clara de que os usuários precisa.
Padrões arquitetônicos. As escolhas feitas sobre tecnologias e principais elementos de arquitetura do sistema.
Componentes e suas Interfaces. Você pode desenhar diagramas de componente para mostrar as partes principais do sistema e mostrar as interfaces através do qual eles interagem uns com os outros. As interfaces de cada componente incluem todas as mensagens que você identificou em diagramas de seqüência.
Interações entre os componentes. Para cada caso de uso, um evento ou uma mensagem de entrada, você pode desenhar um diagrama de seqüência mostra como os principais componentes do sistema interagem para atingir a resposta necessária.
Modelo de dados dos componentes e Interfaces. Você pode desenhar diagramas de classe para descrever as informações passadas entre componentes e armazenadas dentro de componentes.

Noções básicas sobre os requisitos

O design de alto nível de um aplicativo completo com mais eficiência é desenvolvido em conjunto com um modelo de requisitos ou outra descrição dos usuários precisa. 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 todas as suas necessidades podem ser incorporadas em interfaces programáticas.

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

Fornecido interfaces. Uma interface fornecida lista os serviços ou operações que o componente ou o sistema deve fornecer aos seus usuários, independentemente de estarem usuários humanos ou outros componentes de software.
Interfaces necessárias. Uma interface necessária lista os serviços ou operações que o sistema ou o componente pode usar. Em alguns casos, você será capaz de 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 diversas configurações, a interface necessária será definida por considerações externas.
Qualidade de requisitos de serviço. O desempenho, segurança, robustez e outros objetivos e restrições que o sistema deve atender.

O modelo de requisitos é escrito do ponto de vista dos usuários do sistema, independentemente de estarem pessoas ou outros componentes de software. Eles não sabem nada do funcionamento interno do seu sistema. Por outro lado, o seu objetivo um modelo de arquitetura é descrever o funcionamento interno e mostrar como eles atenderem os usuários precisa.

Manter os requisitos e modelos arquitetônicos separados é útil porque ela facilita discutir os requisitos de usuários. Ele também ajuda você refatorar o design e considere a possibilidade de arquiteturas alternativas enquanto os requisitos de manter inalterada.

Você pode separar os requisitos e modelos arquitetônicos de duas maneiras alternativas:

Para mantê-los na mesma solução mas diferentes projetos. Eles serão exibidos como modelos separados no Gerenciador de modelos UML. Diferentes membros da equipe possam trabalhar em paralelo nos modelos. Limitado de tipos de rastreamento podem ser criados entre os modelos.
Colocá-los no mesmo modelo UML, mas em diferentes pacotes. Isso facilita a dependências de rastreamento entre os modelos, mas impede que mais de uma pessoa por vez trabalhando no modelo. Além disso, um modelo muito grande levará mais tempo para carregar o Visual Studio. Portanto, essa abordagem é menos adequada para projetos grandes.

A quantidade de detalhes que devem ser colocadas em um requisitos ou em um modelo de arquitetura depende da escala do projeto e o tamanho e a distribuição da equipe. Uma pequena equipe em um projeto pequeno pode ir de não mais do que fazer um rascunho de um diagrama de classes de conceitos de negócios e alguns padrões de design; um projeto grande, distribuído ao longo de mais de um país precisaria significativamente mais detalhes.

Padrões arquitetônicos

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

Basear as opções de tecnologia, como, por exemplo, a escolha entre um banco de dados e um sistema de arquivos e a escolha entre um aplicativo de rede e um cliente de Web e assim por diante.
Opções de estruturas, como, por exemplo, uma escolha entre o Windows Workflow Foundation ou ADO.NET Entity Framework.
Opções de método de integração, por exemplo, entre um barramento de serviço corporativo ou de um canal de ponto a ponto.

Essas opções freqüentemente são determinadas pela qualidade de requisitos de serviço, como escala e a flexibilidade e podem ser feitas antes dos requisitos detalhados são conhecidos. Em um sistema grande, a configuração de hardware e software são altamente inter-relacionadas.

As seleções que você faz afetam a maneira de usar e interpretar o modelo de arquitetura. Por exemplo, em um sistema que usa um banco de dados de associações em um diagrama de classe podem representar relações ou chaves estrangeiras no banco de dados, enquanto que em um sistema baseado em arquivos XML, associações podem indicar referências cruzadas que usam o XPath. Em um sistema distribuído, mensagens em um diagrama de seqüência podem representar mensagens em um cabo; em um aplicativo independente, podem representar chamadas de função.

Componentes e suas Interfaces.

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

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

Esses pontos são fosse o elaborado de acordo no restante desta seção.

Componentes

Os modos de exibição de um modelo de arquitetura central são os diagramas de componente mostram as partes principais do sistema e como eles dependem uma da outra. Para obter mais informações sobre os diagramas de componente, consulte Diagramas de componente UML: Referência.

UML <>>diagrama de componente mostrando partes

Um diagrama de componente típico para um grande sistema pode incluir componentes, como estes:

Apresentação. O componente que fornece acesso ao usuário, geralmente executados em um navegador da Web.
Componentes de serviço da Web. Fornece a conexão entre clientes e servidores.
Use maiúsculas controladores. Conduza o usuário pelas etapas de cada cenário.
Núcleo de negócios. Contém classes que são baseados em classes no modelo de requisitos, implementa as operações de chaves e impõe restrições de negócios.
O banco de dados. Armazena os objetos de negócios.
O log e componentes de tratamento de erros.

Dependências entre componentes

Além dos próprios componentes, você pode mostrar as dependências entre elas. Uma seta de dependência entre dois componentes mostra que 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 fornecidas por outro componente, direta ou indiretamente.

Uma arquitetura bem estruturada possui uma organização clara de dependências, na qual essas condições forem verdadeiras:

Não há nenhum loops no gráfico de dependência.
Os componentes podem ser organizados em camadas nas quais cada dependência vai de um componente em uma camada para um componente no próximo. Vá de todas as dependências entre as duas camadas na mesma direção.

Você pode mostrar as dependências diretamente entre os componentes ou você pode mostrar dependências entre necessário e fornecido interfaces que estão anexados aos componentes. Usando as interfaces, você pode definir as operações que são usadas em cada dependência. Normalmente, as dependências são mostradas entre componentes quando os diagramas são desenhados primeiro e, em seguida, substituídos pelas dependências entre interfaces conforme são adicionadas mais informações. Ambas as versões são descrições corretas do software, mas a versão com interfaces fornece mais detalhes do que a versão anterior.

O gerenciamento de dependências é mais importante para a produção de software de fácil manutenção. Os diagramas de componente 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 nos diagramas. Se o código está sendo desenvolvido, certifique-se de que ele não inclui dependências que não estão previstas no diagrama de componente. Para ajudá-lo a descobrir dependências no código, você pode gerar diagramas de camada. Para ajudá-lo a garantir que suas restrições de dependência planejadas sejam atendidas, você pode validar o código contra os diagramas de camada. Para obter mais informações, consulte Diagramas de camada: Referência.

Interfaces

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

Um componente pode ter qualquer número de interfaces necessárias e fornecidos. Fornecido interfaces de serviços de mostrar que o componente fornece para outros componentes usar. Interfaces necessárias mostram os serviços que o componente usa em outros componentes.

Se você definir ambas fornecidas e as interfaces necessárias, isso ajuda a separar o componente completamente do restante do projeto, para que você possa usar essas técnicas:

Coloque o componente em uma estrutura de teste no qual os componentes adjacentes são simulados pelo equipamento de teste.
Desenvolva seu componente independentemente dos outros componentes.
Reutilize o componente em outros contextos, combinando suas interfaces para componentes diferentes.

Quando você deseja definir a lista de operações em uma interface, você pode criar outro modo de exibição da interface em um diagrama de classe UML. Para fazer isso, localize a interface no Gerenciador de modelos UML e arraste-o para um diagrama de classe. Você pode então adicionar operações na interface.

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

Para determinar quais operações para adicionar, crie diagramas de seqüência para mostrar como os componentes interagem uns com os outros. Consulte interações entre os componentes. Cada um desses diagramas de seqüência mostra as interações que ocorrem em um caso de uso diferentes. Dessa maneira, você gradualmente pode adicionar à lista de operações na interface do componente, como você explorar os casos de uso.

Decomposição de um componente em partes

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

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

É útil aplicar essa técnica para todo o sistema. Desenhá-la como um componente único e mostrar seus componentes principais, como partes. Isso ajuda você a identificar claramente as interfaces do sistema com o mundo externo.

Quando o design de um componente usa outro componente, você freqüentemente tem uma escolha sobre o representá-lo como uma parte ou como um componente separado, você pode acessar através de uma Interface requer.

Use as partes nas seguintes situações:

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

Use componentes separados acessados por meio de interfaces necessárias nestas situações:

O componente de exigência pode ser combinado através das interfaces para componentes diferentes de fornecimento em tempo de execução.
O design é que seria fácil substituir um provedor, por outro.

O uso de interfaces necessárias geralmente é preferível o uso de partes. Embora o design pode levar mais tempo, o sistema resultante é mais flexível. Também é mais fácil de testar os componentes separadamente. Isso permite que o menor acoplamento em seus planos de desenvolvimento.

Interações entre os componentes

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

Identifica os casos de uso do seu sistema.
Para cada caso de uso, desenhe um ou mais diagramas para mostrar como os componentes do sistema alcançar o resultado de necessário ao colaborar entre si e com os usuários. Normalmente, esses são os diagramas de seqüência ou diagramas de atividade.
Use Interfaces para especificar as mensagens recebidas por cada componente.
Descreva os efeitos das operações nas Interfaces.
Repita o procedimento para cada componente, mostrando como suas partes interagem.

Por exemplo, em um sistema de venda baseado na web, o modelo de requisitos pode definir uma compra do cliente como um caso de uso. Você pode criar um diagrama de seqüência para mostrar as interações de que o cliente tem com os componentes na camada de apresentação e para mostrar as interações de que eles têm com os componentes de contabilidade e um depósito.

Identificar os eventos de inicialização

O trabalho feito pela maioria dos sistemas de software puder ser convenientemente dividido pelas respostas que ele proporciona a eventos ou entradas diferentes. O evento de inicialização pode ser um dos seguintes eventos:

A primeira ação em um caso de uso. Pode aparecer no modelo de requisitos como uma etapa em um caso 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 de programação. Se o sistema que você está desenvolvendo um componente em um sistema maior, devem ser descrita como uma operação em uma das interfaces do componente. Consulte componentes e suas Interfaces.
Uma determinada condição é monitorada pelo seu sistema ou um evento regular, como, por exemplo, uma hora do dia.

Descrever as computações

Desenhe diagramas de seqüência para mostrar como os componentes são responder ao evento inicial.

Desenhe uma linha de vida para cada instância de componente que leva a parte de uma seqüência típica. Em alguns casos, pode haver mais de uma instância de cada tipo. Se você descreveu o sistema inteiro como um único componente, deve haver uma linha de vida para cada parte que ela contém.

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

Diagramas de atividade também são úteis em alguns casos. Por exemplo, se seus componentes tem um fluxo contínuo de dados, você pode descrevê-lo como um fluxo de objeto. Se o seu componente tem um algoritmo complexo, você pode descrevê-lo como um fluxo de controle. Certifique-se de que você torna claro qual componente executa cada ação, por exemplo, usando os comentários. Para obter mais informações, consulte Diagramas de atividade UML: Diretrizes.

Especificar as operações

Os diagramas mostram as operações executadas por cada componente seja representado como mensagens em um diagrama de seqüência ou ações em um diagrama de atividade.

Colete essas operações juntos para cada componente. Crie Interfaces fornecidas no componente e adicionar as operações para as interfaces. Normalmente, uma interface separada é usada para cada tipo de cliente. As operações mais facilmente são adicionadas a interfaces no Gerenciador de modelos UML. Da mesma maneira, coletar as operações de cada componente usa a partir de outros componentes e colocá-los em Interfaces necessárias, conectados ao componente.

É útil adicionar comentários os diagramas de atividade ou seqüência, observar o que foi obtido após cada operação. Você também pode escrever o efeito de cada operação em seus Pós-condição Local propriedade.

Modelo de dados dos componentes e Interfaces

Defina os parâmetros e retornar valores de cada operação as interfaces de componente. Onde as operações representam invocações como, por exemplo, solicitações de serviço da Web, os parâmetros são essas informações que são enviadas como parte da solicitação. Onde vários valores são retornados de uma operação, você pode usar parâmetros com o direção propriedade definida como Check-Out.

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

Use os comentários para descrever as restrições de negócios sobre os atributos e associações. Por exemplo, se todos os itens do pedido do cliente devem vir do mesmo fornecedor, você pode descrever isso por referência para as associações entre os itens do pedido e os itens no catálogo de produtos e entre o item do catálogo e seus fornecedores.

Padrões de design

Um padrão de design é uma estrutura de tópicos de como criar um determinado aspecto do software, principalmente aquele que ocorre em diferentes partes do sistema. Adotando uma abordagem uniforme entre o projeto, reduzir o custo de design, garantir a consistência na interface do usuário e reduzir o custo de compreensão e a alteração do código.

Alguns padrões de design geral como observador são conhecidos e amplamente aplicáveis. Além disso, existem padrões que são aplicáveis para o seu projeto. Por exemplo, em um sistema de venda na Web, haverá diversas operações no código onde as alterações são feitas para o pedido do cliente. Para garantir que o estado do pedido seja exibido corretamente em cada estágio, todas essas operações devem seguir um protocolo específico para atualizar o banco de dados.

Parte do trabalho de arquitetura de software é determinar quais padrões devem ser adotadas em design. Geralmente, é uma tarefa em andamento, porque novos padrões e melhorias para os padrões existentes serão descobertas conforme o andamento do projeto. É útil organizar o plano de desenvolvimento para que cada um dos seus padrões de design principais você exercício mais cedo possível.

A maioria dos padrões de design podem ser parcialmente incorporados no código de estrutura. Parte do padrão pode ser reduzido para exigir que o desenvolvedor use classes específicos ou componentes, como, por exemplo, uma camada de acesso a banco de dados que garante que o banco de dados é tratado corretamente.

Um padrão de design é descrito em um documento e geralmente inclui estas partes:

Nome.
Descrição do contexto é aplicável. O critério deve tomar um desenvolvedor apliquem a esse padrão?
Breve explicação do problema que ele resolve.
Modelo de partes mais importantes e suas relações. Podem ser classes ou componentes e interfaces com associações e dependências entre elas. Geralmente, os elementos se encaixam em duas categorias:
- Elementos que o desenvolvedor deve ser replicada em cada parte do código onde o padrão é usado. Você pode usar os tipos de modelo para descrevê-los. Para obter mais informações, consulte Diagramas de caso de uso UML: Referência.
- Elementos que descreve as classes do framework que o desenvolvedor deve usar.
Modelo das interações entre as partes, usando diagramas de seqüência ou atividade.
Convenções de nomenclatura.
Descrição de como o padrão resolve o problema.
Descrição de variações de que os desenvolvedores poderão adotar.