Partilhar via

Visão geral de cenário: Alterar o design usando visualização e modelagem

  • Artigo

Para certificar-se de que o sistema de software atenda suas necessidades de usuários, use as ferramentas de modelagem e visualização no Visual Studio Ultimate para ajudá-lo a atualizar ou alterar o design do sistema. Essas ferramentas incluem diagramas de UML (Unified Modeling Language), diagramas de camada, gráficos de dependência baseados em códigos, diagramas de sequência, e diagramas de classe. Por exemplo, você pode usar essas ferramentas para realizar estas tarefas:

  • Esclareça os requisitos dos usuários e processos empresariais.

  • Visualizar e explorar o código existente.

  • Descrever alterações para um sistema existente.

  • Verifique se o sistema atende aos seus requisitos.

  • Mantenha o código consistente com o design.

Essa explicação passo a passo usa um cenário de exemplo para obter as seguintes metas:

  • Fornece uma visão geral de alto nível de ferramentas e seus benefícios a um projeto de software.

  • Mostrar como duas equipes podem usar essas ferramentas em um cenário de exemplo, independentemente das abordagens de desenvolvimento.

Para obter mais informações sobre essas ferramentas e os cenários que elas suportam, consulte:

Neste tópico

Seção

Descrição

Visão geral do cenário

Descreve um exemplo de cenário e seus participantes.

Funções de arquitetura e diagramas de modelagem no Desenvolvimento de Software

Descreve as funções que essas ferramentas podem executar durante o ciclo de vida de desenvolvimento de software.

Informações de compreensão e comunicação sobre o sistema

Fornece uma visão geral de alto nível de como os participantes usam as ferramentas nesse cenário.

Atualizando o sistema usando a visualização e a modelagem

Fornece um detalhe mais profundo sobre cada ferramenta e como ela pode ser usada nesse cenário.

Visão geral do cenário

Este cenário descreve episódios dos ciclos de vida de desenvolvimento do software de duas empresas fictícias: Dinner Now e Lucerne Publishing. O Dinner Now fornece um serviço de entrega de refeições baseado na Web em Seattle. Os clientes podem pedir refeições e pagá-las no site Dinner Now. Os pedidos são enviados para o restaurante local apropriado para entrega. A Lucerne Publishing, uma empresa de Nova York, tem vários negócios dentro e fora da Web. Por exemplo, executam um site onde os clientes podem postar revisões de restaurante.

A Lucerne adquiriu recentemente o Dinner Now e deseja fazer as seguintes alterações:

  • Integre os sites deles ao adicionar recursos de critica de restaurante ao Dinner Now.

  • Substitua o sistema de pagamento da Dinner Now pelo sistema de Lucerne.

  • Expanda os serviços de Dinner Now em toda a região.

O Dinner Now usa A Programação extrema e SCRUM Têm uma cobertura de teste muito alta e pouco código não suportado. Minimizam os riscos criando versões pequenas e funcionais de um sistema e depois adicionando a funcionalidade incrementalmente. Desenvolvem seu código em iterações curtas e frequentes. Isso os permite adotar a alteração, refatorar o código com frequência, e evitar o "design frontal sobrecarregado".

A Lucerne mantém uma coleção de sistemas muito maior e complexa, alguns dos quais com mais de 40 anos de idade. São muito cautelosos ao fazer alterações devido à complexidade e ao escopo de código herdado. Seguem um processo de desenvolvimento mais rigoroso, preferindo criar soluções detalhadas e documentar o design e as alterações que ocorrem durante o desenvolvimento.

Ambas as equipes usam diagramas de modelagem em Visual Studio Ultimate para ajudá-los a desenvolver sistemas que atendem às necessidades de usuários. Usam o Team Foundation Server em conjunto com ferramentas para ajudá-los a planejar, organizar, e gerenciar seu trabalho.

Para obter mais informações sobre o Team Foundation Server, consulte:

  • Planejando e controlando o trabalho

  • Testando, validando e fazendo check-in no código atualizado

Funções de arquitetura e diagramas de modelagem no Desenvolvimento de Software

A tabela a seguir descreve as funções que essas ferramentas podem executar durante vários e vários estágios do ciclo de vida de programação de software:

A modelagem dos requisitos de usuário

Modelo do processo corporativo

Design da arquitetura & do sistema

Exploração & visualização de código

Verificação

Diagrama de caso de uso (UML)

√

√

√

Diagrama de atividade (UML)

√

√

√

√

Diagrama de classes (UML)

√

√

√

√

Diagrama de componente (UML)

√

√

√

√

Diagrama de sequência (UML)

√

√

√

√

Diagrama de Linguagem Específica de Domínio (DSL)

√

√

√

Diagrama de camadas, validação de camada

√

√

√

Gráfico de dependência (baseado em código)

√

√

√

Diagrama sequência (baseado em código)

√

√

Designer de Classe (baseado em código)

√

Gerenciador de arquitetura

√

Para desenhar diagramas de UML e diagramas de camadas, é necessário criar um projeto de modelagem como parte de uma solução existente ou nova. Esses diagramas devem ser criados no projeto de modelagem. Os itens em diagramas UML fazem parte de um modelo comum, e os diagramas UML são exibições desse modelo. Os itens em diagramas de camadas estão localizados no projeto de modelagem, mas não estão armazenados no modelo comum. Em geral, gráficos de dependência baseado em código, diagramas de sequência e diagramas de classes existem fora do projeto de modelagem.

Consulte:

Para mostrar exibições alternativas da arquitetura, você pode reutilizar determinados elementos do mesmo modelo em diagramas múltiplos ou diferentes. Por exemplo, é possível arrastar um componente até outro diagrama de componente ou para um diagrama de sequência de modo que possa funcionar como um ator. Consulte Editar modelos e diagramas UML.

Ambas as equipes também usam a validação de camada para certificar-se de que o código em desenvolvimento permanece consistente com o design.

Consulte:

  • Mantendo código consistente com o design

  • Descreve a arquitetura lógica: Diagramas da Camada

  • Validar o código com diagramas de camada

    Dica

    O Visual Studio Premium oferece suporte à validação de camada e a versões somente leitura desses gráficos e diagramas para visualização e modelagem.

Informações de compreensão e comunicação sobre o sistema

Não há nenhuma ordem prescrita para o uso dos diagramas de modelagem do Visual Studio Ultimate, portanto você pode usá-los de acordo com suas necessidades ou abordagem. Em geral, as equipes revisitam seus modelos frequentemente e de forma iterativa em todo um projeto. Cada diagrama oferece pontos específicos para ajudá-lo a entender, descrever e comunicar os diferentes aspectos do sistema em desenvolvimento.

Além de se comunicarem, O Dinner Now e a Lucerne mantêm comunicação com os participantes de projeto usando diagramas como sua linguagem comum. Por exemplo, o Dinner Now usa diagramas para executar essas tarefas:

  • Visualizar o código existente.

  • Comunicar-se com Lucerne sobre histórias de usuário novas e atualizadas.

  • Identifique as alterações que são necessárias para suportar histórias novas ou atualizadas do usuário.

A Lucerne usa diagramas para executar estas tarefas:

  • Saber mais sobre o processo comercial do Dinner Now

  • Entender o design do sistema.

  • Comunicar-se com o Dinner Now sobre requisitos de usuário novos e atualizados.

  • O documento atualiza para o sistema.

Os diagramas são integrados com o Team Foundation Server, de forma que as equipes possam planejar, gerenciar e acompanhar seu trabalho de forma mais fácil. Por exemplo, usam modelos para identificar casos de teste, tarefas de desenvolvimento e estimar seu trabalho. A Lucerne vincula itens de trabalho do Team Foundation a elementos de modelo para que eles possam monitorar o andamento e ter a certeza de que o sistema atende aos requisitos dos usuários. Por exemplo, vinculam casos de uso a itens de trabalho de caso de teste para que possam ver que os casos de uso são atendidos quando todos os testes passam.

Antes que as equipes façam check-in em suas alterações, elas validam o código em comparação aos testes e ao design executando as compilações que incluem validação de camada e testes automatizados. Isso ajuda a garantir que o código atualizado não entre em conflito com o design e interrompa a funcionalidade que estava funcionando anteriormente.

Consulte:

  • Entendendo a função do sistema no processo comercial

  • Descrevendo requisitos de usuário novos ou atualizados

  • Criando testes de modelos

  • Identificação de alterações no sistema existente

  • Mantendo código consistente com o design

  • Dicas gerais para criar e usar modelos

  • Planejando e controlando o trabalho

  • Testando, validando e fazendo check-in no código atualizado

Entendendo a função do sistema no processo comercial

A Lucerne deseja saber mais sobre o processo de negócios do Dinner Now. Criam os seguintes diagramas para esclarecer seu entendimento com a Dinner Now com mais facilidade:

Diagrama

Descreve

Diagrama de caso de uso (UML)

Consulte:

  • As atividades que o sistema Dinner Now suporta

  • Pessoas e sistemas externos que executam as atividades

  • Os componentes principais do sistema que suportam cada atividade

  • As partes do processo comercial que estão fora do escopo do sistema atual, por exemplo, entrega de alimento

Diagrama de atividade (UML)

Consulte:

O fluxo das etapas que ocorrem quando um cliente cria um pedido

Diagrama de classes (UML)

Consulte:

As entidades de negócios e os termos usados na discussão e as relações entre essas entidades. Por exemplo, os itens de Menu e de Ordem são parte do vocabulário nesse cenário.

Por exemplo, a Lucerna cria o seguinte diagrama de caso de uso para entender as tarefas executadas no site Dinner Now e entender quem as executa:

Diagrama de Casos de Uso UML

Diagrama de caso de uso UML

O seguinte diagrama de atividade descreve o fluxo das etapas em que um cliente cria um ordem no site Dinner Now. Nesta versão, elementos de comentário identificam as funções e linhas criam swimlanes, que organizam as etapas por função:

Diagrama de Atividade UML

Diagrama de atividade UML

O seguinte diagrama de classe descreve as entidades que participam do processo de ordem:

Diagrama de Classes UML

Diagrama de Classes UML

Descrevendo requisitos de usuário novos ou atualizados

A Lucerne deseja adicionar funcionalidade ao sistema do Dinner Now para que os clientes possam ler e contribuir para críticas de restaurantes. Atualizam os seguintes diagramas de modo que eles possam descrever e abordar esse novo requisito com a Dinner Now:

Diagrama

Descreve

Diagrama de caso de uso (UML)

Consulte:

Um novo caso de uso para “Escrever uma revisão de um restaurante”

Diagrama de atividade (UML)

Consulte:

As etapas que ocorrem quando um cliente quer gravar uma análise de restaurante

Diagrama de classes (UML)

Consulte:

Os dados que são necessários para armazenar uma revisão

Por exemplo, o seguinte diagrama de caso de uso inclui um novo caso de uso “Gravar Revisão” para representar o novo requisito. É realçado em laranja no diagrama para uma identificação mais fácil:

Diagrama de Casos de Uso UML

Diagrama de caso de uso UML

O seguinte diagrama de atividade inclui novos elementos em laranja para descrever o fluxo das etapas no novo caso de uso:

Diagrama de Atividade UML

Diagrama de atividade UML

O seguinte diagrama de classe inclui uma nova classe de revisão e suas relações a outras classes de modo que as equipes possam discutir seus detalhes. Observe que um cliente e um restaurante podem ter várias revisões:

Diagrama de Classes UML

Diagrama de classes UML

Criando Testes de Modelos

Ambas as equipes concordam que precisam de um conjunto completo de testes para o sistema e seus componentes antes de quaisquer alterações. A Lucerne tem uma equipe especializada que executa testes do sistema e no nível de componente. Reutilizam os testes criados pela Dinner Now e estruturam os testes usando diagramas de UML:

  • Cada caso de uso é representado por um ou vários teste. Os elementos no diagrama dos casos de uso são vinculados a itens de trabalho do caso de teste no Team Foundation Server.

  • Cada fluxo em um diagrama de atividade ou no diagrama de sequência de nível de sistema é associado a um teste pelo menos. A equipe de teste certifica-se sistematicamente de que testa cada caminho possível pelo diagrama de atividade.

  • Os termos usados para descrever os testes são baseados em termos definidos por caso de uso, por classe, e por diagramas de atividade.

Conforme os requisitos mudam e os diagramas são atualizados para refletir essas alterações, os testes também são atualizados. Um requisito é considerado preenchido somente depois de passar pelos testes. Quando é possível ou prático, os testes são definidos e baseados em diagramas de UML antes do início da implementação.

Consulte:

Identificação de alterações no sistema existente

O Dinner Now deve estimar o custo de atender ao novo requisito. Isso depende em parte de quanto essa alteração afetará as outras partes do sistema. Para ajudá-las a entender isso, um dos desenvolvedores da Dinner Now cria os seguintes elementos gráficos e diagramas a partir do código existente:

Gráfico ou diagrama

Mostra

Gráficos de dependência

Consulte:

Dependências e outros relacionamentos no código.

Por exemplo, o Dinner Now pode começar examinando gráficos de dependência de assembly para obter uma visão geral dos assemblies e suas dependências. Podem se aprofundar em elementos gráficos para explorar namespaces e classes nesses assemblies.

O Dinner Now também pode criar gráficos para explorar areas particulares e outros tipos de relações no código. Usam o Architecture Explorer ou o Solution Explorer para ajudá-los a localizar e selecionar as áreas e os relacionamentos de seu interesse.

Diagrama de sequência baseado em código

Consulte Visualizar o código em diagramas de sequência.

Sequência de interações entre as instâncias.

Os diagramas de sequência são gerados das definições do método e são úteis para entender como o código implementa o comportamento do método.

Diagrama de classes baseado em código

Consulte Como adicionar diagramas de classe a projetos (Designer de Classe).

Classes existentes no código

Por exemplo, o desenvolvedor usa o Gerenciador de arquitetura para selecionar os namespaces que deseja focar e cria um gráfico de dependência de código. Ela ajusta seu escopo para focalizar nas áreas que serão afetadas pelo novo cenário. Essas áreas são selecionadas e realçadas no gráfico:

Gráfico de dependência de namespace

Gráfico de dependência de namespace

O desenvolvedor expande namespaces selecionadas para ver as classes, métodos e relações:

Gráfico de dependência de namespace expandido

O gráfico expandido de dependência de namespace com links entre grupos visíveis

O desenvolvedor examinar o código para localizar as classes e métodos afetados. Gera diagramas de sequência e diagramas de classe de código para descrever e discutir as alterações. Consulte Visualizar código.

Dica

Para ver os efeitos de cada alteração à medida que são feitas, gere novamente os gráficos de dependência e os diagramas de sequência do código após cada alteração.

Para descrever alterações em outras partes do sistema, como componentes ou interações, a equipe pode desenhar esses elementos em whiteboards. Também podem desenhar os seguintes diagramas no Visual Studio para que os detalhes possam ser detectados, gerenciados, e compreendidos por ambas equipes:

Diagramas

Descreve

Diagrama de atividade (UML)

Consulte:

O fluxo das etapas que ocorrem quando o sistema observa que um cliente coloca um pedido de um restaurante novamente, através do cliente para escrever uma revisão.

Diagrama de classes (UML)

Consulte:

Classes lógicas e suas relações. Por exemplo, uma nova classe é adicionada para descrever Revisar e suas relações com outras entidades, como Restaurante, Menu e Cliente.

Para associar revisões com um cliente, o sistema deve armazenar detalhes de cliente. Um diagrama de classe de UML pode ajudar a esclarecer esses detalhes.

Diagrama de classes baseado em código

Consulte Como adicionar diagramas de classe a projetos (Designer de Classe).

Classes existentes no código.

Diagrama de componente (UML)

Consulte:

As partes de alto nível do sistema, como o site Dinner Now e suas interfaces. Essas interfaces definem como os componentes interagem uns com os outros através dos métodos ou serviços que eles fornecem e consomem.

Diagrama de sequência (UML)

Consulte:

A sequência de interações entre as instâncias.

Por exemplo, o seguinte diagrama de componente mostra o novo componente, o qual é parte do componente do site Dinner Now. O componente ReviewProcessing trata a funcionalidade de criar revisões e é realçado em laranja:

Diagrama de Componente UML

Diagrama de componente UML

O diagrama a seguir mostra a sequência de interações que ocorre quando o site Dinner Now verifica se o cliente fez pedido em um restaurante antes. Se isso for verdadeiro, será solicitado que o cliente crie uma análise, que será enviada para o restaurante e publicada pelo site:

Diagrama de Sequência UML

Diagrama de sequência UML

Mantendo código consistente com o design

O Dinner Now deve se certificar de que os códigos atualizados ficaram consistentes com o design. Criam diagramas de camada que descrevem as camadas de funcionalidade no sistema, especificam as dependências permitidas entre eles, e associam artefatos de solução para essas camadas.

Diagrama

Descreve

Diagrama de camadas

Consulte:

A arquitetura lógica do código.

Um diagrama de camada organiza e mapeia os artefatos em uma solução de Visual Studio para grupos abstratos chamados camadas. Essas camadas identificam os papéis, as tarefas, ou as funções que esses artefatos executam no sistema.

Os diagramas de camadas são úteis para descrever o design pretendido do sistema e para validar o código em evolução em relação ao design.

Para criar camadas, arraste os itens do gerenciador de soluções, gráficos de dependência, ou do gerenciador de arquitetura. Para desenhar novas camadas, use a caixa de ferramentas ou clique com o botão direito do mouse na superfície do diagrama.

Para exibir as dependências existentes, clique com o botão direito do mouse na superfície do diagrama de camada e, em seguida, clique em Gerar dependências. Para especificar dependências destinadas, desenhe novas dependências.

Por exemplo, o seguinte diagrama de camada descreve as dependências entre camadas e o número de artefatos que são associados a cada camada:

Diagrama de camada do sistema integrado de pagamento

Diagrama de camadas

Para certificar-se de que os conflitos com o design não ocorram durante o desenvolvimento de código, a equipe usa a validação de camada nas compilações que são executadas no Team Foundation Build. Também criam uma tarefa personalizada do MSBuild para requerer a validação de camada nas operações de check-in. Usam relatórios de compilação para coletar erros de validação.

Consulte:

Dicas gerais para criar e usar modelos

  • A maioria de diagramas consiste em nós conectados por linhas. Para cada tipo de diagrama, a caixa de ferramentas fornece tipos diferentes de nós e linhas.

    Para abrir a caixa de ferramentas, no menu Modo de Exibição, clique em Caixa de Ferramentas.

  • Para criar um nó, arraste-o da caixa de ferramentas para o diagrama. Certos tipos de nós devem ser arrastados para nós existentes. Por exemplo, em um diagrama de componente, uma nova porta deve ser adicionada a um componente existente.

  • Para criar uma linha ou uma conexão, clique na ferramenta apropriado na caixa de ferramentas, clique no nó de origem e, em seguida, clique no nó de destino. Algumas linhas podem ser criadas somente entre determinados tipos de nós. Quando você move o ponteiro sobre uma fonte ou destino possível, o ponteiro indica se você pode criar uma conexão.

  • Ao criar itens em diagramas de UML, você também os adiciona a um modelo comum. Os diagramas de UML em um projeto de modelagem são exibições do modelo. Os itens em um diagrama de camadas fazem parte do projeto de modelagem, mesmo que não estejam armazenados no modelo comum.

    Para ver o modelo, no menu Arquitetura, aponte para Windows, e clique em Gerenciador de Modelos UML.

  • Em alguns casos, você pode arrastar determinados itens de Gerenciador de Modelo UML para um diagrama UML. Alguns elementos dentro do mesmo modelo podem ser usados em vários diagramas diferentes para mostrar exibições alternativas da arquitetura. Por exemplo, é possível arrastar um componente até outro diagrama de componente ou para um diagrama de sequência que será usado como um ator.

  • Visual Studio Ultimate suporta UML 2.1.2. Esta visão geral descreve somente os recursos principais de diagramas de UML nesta versão, mas há muitos livros que abordam o UML e seu uso em detalhes.

Consulte Desenvolvendo modelos para design de software.

Planejando e Controlando o Trabalho

Os diagramas de modelagem do Visual Studio Ultimate são integrados com o Team Foundation Server para que você possa planejar, gerenciar, e controlar o trabalho com mais facilidade. Ambas as equipes usam modelos para identificar casos de teste e tarefas de desenvolvimento e para estimar o trabalho. A Lucerne cria e vincula itens de trabalho do Team Foundation Server para modelar elementos, como casos de uso ou componentes. Isso os ajuda a monitorar o andamento e a rastrear seu trabalho de volta para os requisitos de usuários. Isso os ajuda a certificar-se de que as alterações continuam atendendo aos requisitos.

Conforme seu trabalho progride, as equipes atualizam seus itens de trabalho para refletir a hora que eles passam em suas tarefas. Também monitoram e relatam o status em seu trabalho usando os seguintes recursos do Team Foundation Server:

  • Relatórios de burndown diários que mostram se o trabalho planejado será concluído dentro do tempo esperado. Geram outros relatórios semelhantes do Team Foundation Server para acompanhar o progresso dos erros.

  • Uma planilha de iteração que usa o Microsoft Excel para ajudar a equipe a monitorar e equilibrar a carga de trabalho entre seus membros. Esta planilha é vinculada ao Team Foundation Server e fornece o foco para discussão durante as reuniões regulares de progresso.

  • Um painel de desenvolvimento que usa o Office Project para manter a equipe informada sobre informações importantes do projeto.

Consulte:

Testando, validando e fazendo check-in do código

Conforme as equipes concluem cada tarefa, eles verificam o código no Controle de versão do Team Foundation e recebem lembretes do Team Foundation Server, caso se esqueçam. Antes que o Team Foundation Server aceite seus registros, as equipes executam testes de unidade e validação de camada para verificar o código diante de casos de teste e design. Usam o Team Foundation Server para executar compilações, testes de unidade automatizados, e validação de camada regularmente. Isso ajuda a garantir que o código atenda aos seguintes critérios:

  • Funciona.

  • Não interrompe o código que estava trabalhando anteriormente.

  • Não está em conflito com o design.

O Dinner Now tem uma grande coleção de testes automatizados, que a Lucerne pode reutilizar porque quase todos ainda se aplicam. A Lucerne também pode criar esses testes e adicionar novos para cobrir a nova funcionalidade. Ambos usam o Visual Studio Ultimate para executar testes manuais.

Para certificar-se de que o código está de acordo com o design, as equipes configuram suas compilações no Team Foundation Build para incluir a validação de camada. Se qualquer conflito ocorrer, um relatório será gerado com os detalhes.

Consulte:

Atualizando o sistema usando a visualização e a modelagem

A Lucerne e o Dinner Now devem integrar seus sistemas de pagamento. As seções a seguir mostram os diagramas de modelagem no Visual Studio Ultimate e ajuda-os a executar esta tarefa:

  • Entender os requisitos de usuário: Usar diagramas de caso

  • Entender o processo comercial: Diagramas de atividades

  • Descreve a estrutura do sistema: Diagramas de Componente

  • Descreve as interações: Diagramas de sequência

  • Visualizar o código existente: Gráficos de dependência

  • Defina um glossário de tipos: Diagrama de Classe

  • Descreve a arquitetura lógica: Diagramas da Camada

Consulte:

Entender os requisitos de usuário: Usar diagramas de caso

Os diagramas de caso de uso resumem as atividades que um sistema suporta e quem executa essas atividades. A Lucerne usa um diagrama de casos de uso para aprender o seguinte sobre o sistema do Dinner Now:

  • Os clientes criam pedidos.

  • Os restaurantes recebem pedidos.

  • Por exemplo, o Gateway Externo do Processador de Pagamento, que o Sistema de Pagamento do Dinner Now usa para validar pagamento está fora do escopo do site.

O diagrama também mostra como alguns dos principais casos de uso se dividem em casos menores de uso. A Lucerne deseja usar seu próprio sistema de pagamentos. Realçam o caso de uso do pagamento do processo em uma cor diferente para indicar que requer alterações:

Realce o processo de pagamento em um diagrama de caso de uso

Realce do pagamento do processo no diagrama de caso de uso

Se o tempo de desenvolvimento foi curto, a equipe pode discutir se deseja permitir que os clientes paguem diretamente os restaurantes. Para mostrar isso, substituiriam o caso de uso de processamento de pagamento por uma que está fora do limite do sistema da Dinner Now. Vinculariam o cliente diretamente ao restaurante, indicando que o Dinner Now processaria somente pedidos:

Mudança de escopo pagamento restaurante no diagrama de caso de uso

Compor escopo de pagar restaurante no diagrama de caso

Consulte:

Desenhando um diagrama dos casos de uso

Um diagrama de caso de uso tem os principais recursos a seguir:

  • Os atores representam as funções executadas por pessoas, por organizações, por computadores ou por sistemas de software. Por exemplo, o cliente, o restaurante e o sistema de pagamento do Dinner Now são atores.

  • Os casos de uso representam interações entre os atores e o sistema em desenvolvimento. Podem representar qualquer escala de interação a partir de um único clique de mouse ou mensagem para uma transação que se estendeu por muitos dias.

  • Associações vinculam atores a casos de uso.

  • Um caso de uso maior pode incluir menores, por exemplo, Criar pedido inclui Selecionar Restaurante. Você pode estender um exemplo de uso, o que adiciona metas e etapas ao exemplo de uso estendido, para indicar que os exemplos de uso surgem somente sob certas condições. Os casos de uso também podem herdar uns dos outros.

  • Um subsistema representa o sistema de software que está sendo desenvolvido ou um dos seus componentes. É uma grande caixa que contém casos de uso. Um diagrama de casos esclarece o que está dentro e fora dos limites do subsistema. Para indicar que o usuário deve cumprir determinadas metas de outras maneiras, desenhe esses casos de uso fora dos limites do subsistema.

  • Os artefatos vinculam os elementos do diagrama a outros diagramas ou documentos.

Consulte:

Resumo: Pontos fortes de diagramas de caso de uso

Os diagramas de caso de uso ajudam você a visualizar:

  • As atividades que um sistema suporta ou não suporta

  • Pessoas e sistemas externos que executam as atividades

  • Os componentes principais do sistema que suportam cada atividade, os quais você pode representar como subsistemas se aninhados dentro do sistema pai

  • Como um caso de uso pode se dividir em casos menores ou em variações

Relação a outros diagramas

Diagrama

Descreve

Diagrama de atividades

O fluxo das etapas em um caso de uso e aqueles que executam essas etapas nesse caso de uso.

Os nomes dos casos de uso frequentemente espelham as etapas em um diagrama de atividade. Os diagramas de atividade suportam elementos como decisões, mesclagens, entradas e saídas, fluxos simultâneos, e assim por diante.

Consulte:

Diagrama de sequência

A sequência de interações entre os participantes nos exemplos de uso.

Consulte:

Diagrama de classes (UML)

As entidades ou tipos que participam de exemplos de uso.

Consulte:

Entender o processo comercial: Diagramas de atividades

Os diagramas de atividade descrevem o fluxo das etapas em um processo comercial e fornecem uma maneira simples de informar o fluxo de trabalho. Um projeto de desenvolvimento pode ter vários diagramas de atividades. Geralmente, uma atividade aborda todas as ações que resultam de uma ação externa, como ordenar uma refeição, atualizar um menu, ou adicionar um novo restaurante ao negócio. Uma atividade também pode descrever os detalhes de uma ação complexa.

A Lucerne atualiza o seguinte diagrama de atividades para mostrar que processa o pagamento e paga o restaurante. Substituem o sistema de pagamento da Dinner Now pelo sistema de pagamento de Lucerna, conforme destacado:

Sistema de pagamento Zulu no diagrama de atividade

Substituindo o sistema de pagamento do Dinner Now no diagrama de atividades

O diagrama atualizado ajuda a Lucerna e a Dinner Now a visualizarem onde o sistema de pagamento Lucerna se encaixa no processo comercial. Nesta versão, os comentários são usados para identificar as funções que executam as etapas. As linhas usadas para criar swimlanes, que organizam as etapas por função.

As equipes também podem considerar discutir um artigo alternativo onde o cliente paga o restaurante após a ordem ser entregue. Isso deve criar diferentes requisitos do sistema de software.

Anteriormente, o Dinner Now desenhou esses diagramas em um painel ou no PowerPoint. Agora usam o Visual Studio Ultimate para desenhar esses diagramas para que ambas equipes possam detectar, entender, e gerenciar os detalhes.

Consulte:

Desenhando um diagrama de atividades

Um diagrama de atividade possui os seguintes recursos principais:

  • Um nó inicial que indica a primeira ação de atividade.

    O diagrama deve sempre ter um desses nós.

  • Ações que descrevem as etapas em que o usuário ou o software executam uma tarefa.

  • Fluxos de controle que exibem o fluxo entre ações.

  • Nós de decisão que representam ramificações condicionais no fluxo.

  • Nós de bifurcação que dividem fluxos únicos em fluxos simultâneos.

  • Nós de final de atividade que mostram fins de atividades.

    Embora esses nós sejam opcionais, é útil incluí-los no diagrama para mostrar onde a atividade termina.

Consulte:

Resumo: Pontos fortes de diagramas de atividades

Diagramas de atividades ajudam a visualizar e descrever o fluxo de controle e informações entre as ações de um negócio, o sistema ou programa. Esta é uma maneira simples e útil de descrever o fluxo de trabalho ao se comunicar com outras pessoas.

Relação a outros diagramas

Diagrama

Descrição

Diagrama de caso de uso

Resume as atividades que cada ator executa.

Consulte:

Diagrama de componente

Visualizar o sistema como uma coleção de partes reutilizáveis que fornecem ou consomem o comportamento através de um conjunto bem definido de interfaces.

Consulte:

Descreve a estrutura do sistema: Diagramas de Componente

Os diagramas de componente descrevem o sistema como uma coleção de partes separáveis que fornecem ou consomem o comportamento através de um conjunto bem definido de interfaces. As partes podem estar em qualquer escala e podem se conectar de qualquer maneira.

Para ajudar Lucerne e Dinner Now a visualizar e discutir as interfaces do sistema e os componentes, eles criam os seguintes componentes:

Componentes externos no sistema de pagamento

Componentes do sistema de pagamento do Dinner Now

Este diagrama mostra tipos diferentes de componentes e suas dependências. Por exemplo, tanto o site Dinner Now quanto o sistema de pagamento de Lucerna precisam do gateway externo do processador de pagamentos para validar pagamentos. As setas entre componentes representam as dependências que indicam que os componentes requerem funcionalidade de outros componentes.

Para usar o sistema de pagamento de Lucerne, o site da Dinner Now deve ser atualizado para usar as interfaces de inserção e aprovação de pagamentos no sistema de pagamento de Lucerne.

O diagrama a seguir mostra uma configuração específica de componentes para site do Dinner Now. Essa configuração indica que qualquer instância do site consiste de quatro partes:

  • CustomerProcessing

  • OrderProcessing

  • ReviewProcessing

  • PaymentProcessing

Essas partes são instâncias dos tipos de componente especificados e são conectadas como a seguir:

Componentes de site da Web agora jantar

Componentes dentro do site Dinner Now

O site Dinner Now delega seu comportamento a essas partes, que manipulam as funções do site. As setas entre o componente pai e seus componentes do membro mostram as delegações que indicam quais partes manipulam as mensagens que o pai recebe ou envia através das suas interfaces.

Nesta configuração, o componente PaymentProcessing processa pagamentos de cliente. Portanto, deve ser atualizado para integrar com o sistema de pagamento de Lucerna. Em outros cenários, várias instâncias de um tipo de componente podem existir no mesmo componente pai.

Consulte:

Desenhando um diagrama de componente

Um diagrama de componentes tem os principais recursos a seguir:

  • Componentes que representam partes separáveis da funcionalidade do sistema.

  • Portas da interface fornecidas que representam grupos de mensagens ou chamadas que os componentes implementam são usadas por outros componentes ou sistemas externos.

  • Portas da interface fornecidas que representam grupos de mensagens ou chamadas que os componentes enviam para outros componentes ou sistemas externos. Esse tipo de porta descreve as operações que um componente pelo menos espera de outros componentes ou sistemas externos.

  • As partes são membros de componentes e normalmente são instâncias de outros componentes. Uma parte é uma parte de design interno do componente pai.

  • Dependências que indicam componentes requerem a funcionalidade de outros componentes.

  • Delegações que indicam partes de um componente que controlam as mensagens enviadas de ou recebidas pelo componente pai.

Consulte:

Resumo: Pontos fortes de diagramas de componentes

Os diagramas de componente ajudam a visualizar:

  • O sistema como uma coleção de partes separáveis independentemente do seu idioma ou estilo de implementação.

  • Componentes com interfaces bem definidas, tornando mais fácil a compreensão e atualização do design durante a alteração dos requisitos.

Relação a outros diagramas

Diagrama

Descrição

Gráficos de dependência

Visualizar a organização e os relacionamentos no código existente.

Para identificar os candidatos a componentes, crie um gráfico de dependência e agrupe os itens de acordo com sua função no sistema.

Consulte:

Diagrama de sequência

Visualizar a sequência das interações entre os componentes ou as partes de um componente.

Para criar uma linha de vida em um diagrama de sequência de um componente, clique com o botão direito no componente e, em seguida, clique em Criar Linha de Vida.

Consulte:

Diagrama de classes (UML)

Defina as interfaces nas portas necessárias ou fornecidas e as classes que implementam a funcionalidade dos componentes.

Consulte:

Diagrama de camadas

Descreva a arquitetura lógica do sistema enquanto está relacionado aos componentes. Use a validação de camada para certificar-se de que os códigos atualizados ficaram consistentes com o design.

Consulte:

Diagrama de atividades

Visualizar processamento interno que os componentes executam em resposta às mensagens de entrada.

Consulte:

Visualizar o código existente: Gráficos de dependência

Os gráficos de dependência mostram a organização e os relacionamentos atuais no código. Os itens são representados por nós no gráfico, e os relacionamentos são representadas por links. Gráficos de dependência podem ajudá-lo a executar os seguintes tipos de tarefas:

  • Explore o código desconhecido.

  • Entender como e onde uma alteração proposta pode afetar o código existente.

  • Localizar áreas de complexidade, camadas ou padrões naturais, ou outras áreas que podem se beneficiar com melhorias.

Por exemplo, o Dinner Now deve estimar o custo da atualização do componente PaymentProcessing. Isso depende em parte de quanto essa alteração afetará as outras partes do sistema. Para ajudá-las a entender isso, um dos desenvolvedores da Dinner Now gera gráficos de dependência de código e ajusta o foco do escopo nas áreas que podem ser afetadas pela alteração.

O gráfico a seguir mostra as dependências entre a classe de PaymentProcessing e outras partes do sistema Dinner Now, que aparecem selecionadas:

Gráfico de dependência para jantar agora o sistema de pagamento

Gráfico de dependência do sistema de pagamento do Dinner Now

O desenvolvedor explora o gráfico expandindo a classe de PaymentProcessing e selecionando seus membros para ver as áreas que são potencialmente afetadas:

Métodos dentro de PaymentProcessing e dependências

Métodos dentro da classe PaymentProcessing e suas dependências

Geram o gráfico a seguir para o sistema de pagamento de Lucerna verificar suas classes, métodos, e dependências. O consultas de equipe que o sistema Lucerne também pode exigir para interagir com as outras partes da Dinner Now:

Gráfico de dependência para o sistema de pagamento Zulu

Gráfico de dependência do sistema de pagamento de Lucerne

Ambas as equipes funcionam juntas para determinar as alterações que são necessárias para integrar os dois sistemas. Decidem refatorar qualquer código para que a atualização fique mais fácil. A classe de PaymentApprover se moverá para o espaço DinnerNow.Business e precisará de alguns métodos novos. As classes de Dinner Now que tratam transações terão seu próprio namespace. As equipes criam e usam os itens de trabalho para planejar, organizar, e acompanhar seu trabalho. Vinculam os itens de trabalho para modelar elementos onde for útil.

Após reorganizar o código, as equipes gerarão um novo gráfico de dependência para ver a estrutura e as relações atualizadas:

Gráfico de dependência com código reorganizado

Gráfico de dependência com código reorganizado

Este gráfico mostra que a classe PaymentApprover agora está no espaço DinnerNow.Business e tem alguns novos métodos. As classes de transação Dinner Now agora têm seu próprio namespace de PaymentSystem, que torna mais fácil lidar com esse código mais tarde.

Criando um Gráfico de Dependência

  • Para obter uma rápida visão geral do código-fonte, siga estas etapas para gerar um gráfico de dependência:

    No menu de Arquitetura , aponte para Gerar Gráfico de Dependência e, em seguida, clique em Para Solução.

    Para obter uma rápida visão geral do código compilado, crie um gráfico de dependência em branco e arraste arquivos de assembly ou arquivos binários até a superfície do gráfico.

    Consulte Mapear dependências em seu código nos gráficos de dependência.

  • Para explorar itens específicos de código ou solução, use o Gerenciador de Soluções ou Gerenciador de Arquitetura para selecionar os itens e as relações que você deseja visualizar. Você pode então gerar um novo gráfico ou adicionar itens selecionados a um gráfico existente.

    Consulte Mapear dependências em seu código nos gráficos de dependência e Localizar código com o Architecture Explorer.

  • Para ajudá-lo a explorar o gráfico, reorganize o layout para que atenda aos tipos de tarefa que você deseja executar.

    Por exemplo, para visualizar em camadas no código, selecione um layout de árvore. Consulte Procurar e reorganizar gráficos de dependência.

  • Para ajudá-lo a focalizar em áreas específicas de gráfico, ajuste seu escopo filtrando para os itens ou personalizando sua aparência. Consulte Editar e personalizar gráficos de dependência.

Resumo: Pontos fortes de elementos gráficos de dependência

Gráficos de dependência ajudam a:

  • Saiba mais sobre a organização e os relacionamentos no código existente.

  • Identifique as áreas que podem ser afetadas por uma alteração de proposta.

  • Localizar áreas de complexidade, padrões, camadas ou outras áreas que você pode melhorar de modo a facilitar a manutenção, a alteração e a reutilização do código.

Relação a outros diagramas

Diagrama

Descreve

Diagrama de camadas

A arquitetura lógica do sistema. Use a validação de camada para certificar-se de que os códigos atualizados ficaram consistentes com o design.

Para ajudá-lo a identificar as camadas existentes ou camadas pretendidas, crie um gráfico de dependência e agrupe os itens relacionados. Para criar um diagrama de camada, arraste os itens do gráfico ou do Gerenciador de Arquitetura.

Consulte:

Diagrama de componente

Componentes, suas interfaces e suas relações.

Para ajudá-lo a identificar os componentes, crie o gráfico de dependência e agrupe os itens de acordo com sua função no sistema.

Consulte:

Diagrama de classes (UML)

As classes, seus atributos e operações e relações

Para ajudá-lo a identificar esses elementos, crie um documento gráfico que mostre esses elementos.

Consulte:

Diagrama de Classes (baseado em código)

Classes existentes no código.

Para visualizar e alterar uma classe existente no código, use o designer de classe.

Consulte Como adicionar diagramas de classe a projetos (Designer de Classe).

Descreve as interações: Diagramas de sequência

Os diagramas de sequência descrevem uma série de interações entre as partes de um sistema. As partes podem ser de qualquer escala. Por exemplo, podem variar de objetos individuais em um programa para grandes subsistemas ou a atores externos. As interações podem ser de qualquer escala e tipo. Por exemplo, podem variar de mensagens individuais para transações estendidas e podem ser chamadas de função ou mensagens de serviço Web.

Para ajudar Lucerna e Dinner Now a descrever e discutir as etapas no caso de uso de processamento de pagamento, eles criam o seguinte diagrama de sequência a partir do diagrama de componente. As linhas de vida espelham o componente do site Dinner Now e suas partes. As mensagens que aparecem entre as linhas de vida seguem as conexões nos diagramas componentes:

Diagrama de sequência para pagamento do processo de caso de uso

Diagrama de sequência para o caso de uso Processar Pagamento

O diagrama de sequência mostra que quando o cliente cria uma ordem, o site da Dinner Now chama ProcessOrder em uma instância de OrderProcessing. Em seguida, OrderProcessing chama ProcessPayment em PaymentProcessing. Isso continua até que o gateway externo do processador de pagamentos valide o pagamento. Somente depois executa o retorno de controle para o site Dinner Now.

A Lucerne deve estimar o custo de atualização do sistema de pagamentos a ser integrado ao sistema do Dinner Now. Para ajudá-las a entender isso, um dos seus desenvolvedores gera diagramas de sequência a partir do código para visualizar as interações existentes.

Consulte:

Desenhando um diagrama de sequência

Um diagrama de sequencia tem os principais recursos a seguir:

  • As linhas de vida verticais representam atores ou instâncias de objetos de software.

    Para adicionar um símbolo de ator, que indica que um participante está fora do sistema em desenvolvimento, clique na linha de vida. Na janela Propriedades, defina Ator como Verdadeiro. Se a janela Propriedades não abre, pressione F4.

  • As mensagens horizontais representam chamadas de método, mensagens de serviço da Web ou alguma outra comunicação. As ocorrências de execução são retângulos verticais sombreados que aparecem nas linhas de vida e representam os períodos durante os quais os objetos de recebimento processam chamadas.

  • Durante uma mensagem síncrona, o objeto do remetente aguarda o controle <<para retornar>> como em uma chamada de função normal. Durante uma mensagem assíncrona, o remetente pode continuar imediatamente.

  • Use <<criar>> mensagens para indicar a construção de objetos por outros objetos. Deve ser a primeira mensagem enviada ao objeto.

Consulte:

Resumo: Pontos fortes de diagramas de sequência

Os diagramas de sequência ajudam a visualizar:

  • O fluxo de controle que transferido entre atores ou objetos durante a execução de um caso de uso.

  • A implementação de uma chamada ou uma mensagem de método.

Relação a outros diagramas

Diagrama

Descrição

Diagrama de classes (UML)

Defina os parâmetros, as classes que as linhas de vida representam e os valores de retorno usados em mensagens enviadas entre as linhas de vida.

Para criar uma classe a partir de uma linha de vida, clique com o botão direito do mouse na linha de vida, clique em Criar Classe ou Criar Interface. Para criar uma linha de vida a partir de um tipo em um diagrama de classe, clique com o botão direito no tipo e, em seguida, clique em Criar Linha de Vida.

Consulte:

Diagrama de componente

Descreve os componentes que as linhas de vida representam e as interfaces que fornecem e dissipam o comportamento representado por mensagens.

Para criar uma linha de vida a partir de um diagrama de componente, clique com o botão direito no componente e, em seguida, clique em Criar Linha de Vida.

Consulte:

Diagrama de caso de uso

Resume as interações entre usuários e componentes em um diagrama de sequência como um caso de uso, que representa o objetivo de um usuário.

Consulte:

Defina um glossário de tipos: Diagrama de Classe

Os diagramas de classe definem as entidades, os termos ou os conceitos que participam do sistema e suas relações uns com os outros. Por exemplo, é possível usar esses diagramas durante o desenvolvimento para descrever os atributos e as operações de cada classe, independentemente do seu estilo ou idioma de implementação.

Para ajudar Lucerne a descrever e discutir as entidades que participam do caso de uso de processamento de pagamento, eles desenham o seguinte diagrama de classe:

Entidades de pagamento do processo no diagrama de classes

Processar as entidades de pagamento do processo no diagrama de classe

Este diagrama mostra que um cliente pode ter vários pedidos e maneiras diferentes de pagar os pedidos. BankAccount e CreditCard herdam de Pagamento.

Durante o desenvolvimento, Lucerne usa o seguinte diagrama de classes para descrever e discutir os detalhes de cada classe:

Processar os detalhes da entidade de pagamento em um diagrama de classe

Detalhes de pagamento do processo no diagrama de classe

Consulte:

Desenhando um diagrama de classes

Um diagrama de classe tem os seguintes recursos:

  • Tipos, como classes, interfaces, e enumerações:

    • A class é a definição de objetos que compartilham características estruturais ou comportamentais específicas.

    • Uma interface define uma parte do comportamento externamente visível de um objeto.

    • Uma enumeração é um classificador que contém uma lista de valores literais.

  • Os atributos são os valores de qualquer tipo que descrevem cada instância de um classificador. Um classificador é um nome geral para tipos, componentes, caso de uso e até atores.

  • Operações são métodos ou funções que as instâncias de um classificador podem executar.

  • Uma associação indica qualquer tipo de relação entre os dois classificadores.

    • Uma agregação é uma associação que indica uma propriedade compartilhada entre os classificadores.

    • Uma composição é uma associação que indica uma relação de inteiro- parte entre classificadores.

    Para mostrar agregações ou composições, defina a propriedade de Agregação em uma associação. Compartilhado mostra agregações e Composto mostra composições.

  • Uma dependência indica que alterar a definição de um classificador pode alterar a definição de outro classificador.

  • Uma generalização indica que um classificador específico herda parte de sua definição de um classificador geral. Uma realização indica que uma classe implementa as operações e atributos oferecidos por uma interface.

    Para criar estas relações, use a ferramenta de Herança. Como alternativa, uma realização pode ser representada como um pirulito.

  • Pacotes são grupos de classificadores, associações, linhas de vida, componentes e outros pacotes. As relações de Importação indicam que um pacote inclui todas as definições de outro conjunto.

Como um ponto de partida para explorar e discutir as classes existentes, você pode usar o Designer de Classe para criar diagramas de classe do código.

Consulte:

Resumo: Pontos fortes de diagramas de atividades

Os diagramas de classe ajudam a definir:

  • Um glossário de termos comuns para usar ao abordar as necessidades de usuários e as entidades que participam do sistema. Consulte Requisitos de usuário da modelagem.

  • Tipos que são usados pela partes do sistema, como componentes, independentemente da sua implementação. Consulte Modelando a arquitetura de um sistema de software.

  • Relações, como dependências entre tipos. Por exemplo, é possível mostrar que um tipo pode ser associado a várias instâncias de outro tipo.

Relação a outros diagramas

Diagrama

Descrição

Diagrama de caso de uso

Defina os tipos usados para descrever metas e etapas nos casos de uso.

Consulte:

Diagrama de atividades

Defina os tipos de dados que passam pelos nós de objeto, pinos de entrada, pinos de saída e nós de parâmetro de atividade.

Consulte:

Diagrama de componente

Descrever componentes, suas interfaces e suas relações. Uma classe também pode descrever um componente completo.

Consulte:

Diagrama de camadas

Defina a arquitetura lógica do sistema enquanto está relacionada às classes.

Use a validação de camada para certificar-se de que os códigos atualizados ficaram consistentes com o design.

Consulte:

Diagrama de sequência

Defina os tipos de linhas de vida, as operações, parâmetros e valores de retorno de todas as mensagens que as linhas de vida recebem.

Para criar uma linha de vida a partir de um tipo em um diagrama de classe, clique com o botão direito no tipo e, em seguida, clique em Criar Linha de Vida.

Consulte:

Gráficos de dependência

Visualizar a organização e os relacionamentos no código existente.

Para identificar classes, suas relações, e seus métodos, crie um documento gráfico que mostre esses elementos.

Consulte:

Descreve a arquitetura lógica: Diagramas da Camada

Os diagramas de camadas descrevem a arquitetura lógica de um sistema organizando os artefatos em sua solução em grupos abstratos ou em camadas. Os artefatos podem ser várias coisas, como namespaces, projetos, classes, métodos, e assim por diante. As camadas representam e descrevem as funções ou tarefas realizadas pelos artefatos no sistema. Você também pode incluir a validação de camada na compilação e operações de check-in para certificar-se de que o código fique consistente com o design dele.

Para manter o código consistente com o design, a Dinner Now e a Lucerna usam o seguinte diagrama de camada para validar seu código à medida que ele evolui:

Diagrama de camada do sistema integrado de pagamento

Diagrama de camada para o Dinner Now integrado à Lucerne

As camadas neste diagrama fazem ligação com os artefatos de solução Dinner Now e Lucerne correspondentes. Por exemplo, a camada Negócios está vinculada ao namespace DinnerNow.Business e seus membros, que agora incluem a classe PaymentApprover. A camada de acesso a recursos é vinculada ao espaço DinnerNow.Data. As setas, ou dependências, especificam que somente a camada comercial pode usar a funcionalidade na camada de acesso a recursos. Conforme as equipes atualizam o código, a camada de validação é executada regularmente para capturar conflitos à medida que eles ocorrem e para ajudar equipes a resolvê-los rapidamente.

As equipes trabalham juntas para integrar e testar continuamente os dois sistemas. Primeiro certificam-se de que o PaymentApprover e o restante da Dinner Now estejam funcionando corretamente um com o outro antes de lidar com o PaymentProcessing.

O gráfico de dependência a seguir mostra as novas chamadas entre o Dinner Now e o PaymentApprover:

Gráfico de dependência atualizado com o sistema integrado

Gráfico de dependência com chamadas de método atualizado

Após a confirmação de que o sistema funciona conforme o esperado, o Dinner Now assinará o código de PaymentProcessing como comentário. Os relatórios de validação da camada estão vazios, e o gráfico resultante de dependência mostra que não existe mais nenhuma dependência de PaymentProcessing:

Gráfico de dependência sem PaymentProcessing

Gráfico de dependência sem PaymentProcessing

Consulte:

Desenhando um diagrama da camada

Um diagrama de camada tem os seguintes recursos principais:

  • Camadas descrevem grupos lógicos de artefatos.

  • Um link é uma associação entre uma camada e um artefato.

    Para criar camadas a partir de artefatos, arraste os itens do gerenciador de soluções, gráficos de dependência, ou do gerenciador de arquitetura. Para desenhar novas camadas e, em seguida, vinculá-las aos artefatos, use a caixa de ferramentas ou clique com o botão direito do mouse na superfície do diagrama para criar as camadas e, em seguida, arraste os itens para essas camadas.

    O número em uma camada mostra o número de artefatos que estão associados à camada. Esses artefatos podem ser namespaces, projetos, classes, métodos, e assim por diante. Ao interpretar o número de artefatos em uma camada, lembre-se do seguinte:

    • Se uma camada contém um link para um artefato que contém outros artefatos, mas a camada contém um link direto para os outros artefatos, o número inclui somente o artefato vinculado. No entanto, os outros artefatos são incluídos para análise durante a validação da camada.

      Por exemplo, se uma camada é vinculada a um único namespace, logo o número de artefatos associados é 1, mesmo que o namespace contenha classes. Se a camada também possui links para cada classe do namespace, o número incluirá as classes vinculadas.

    • Se uma camada contém outras camadas que estão vinculadas a artefatos, a camada do recipiente também é vinculada a esses artefatos, embora o número na camada do recipiente não inclua esses artefatos.

    Para ver os artefatos que estão associados a uma camada, clique com o botão direito do mouse na camada e, em seguida, clique em Exibir Links para abrir o Gerenciador de Camadas.

  • Uma dependência indica que uma camada pode usar a funcionalidade em outra camada, mas não o contrário. Uma dependência bidirecional indica que uma camada pode usar a funcionalidade em outra camada, e vice-versa.

    Para exibir as dependências existentes no diagrama de camada, clique com o botão direito do mouse na superfície do diagrama e, em seguida, clique em Gerar dependências. Para descrever dependências destinadas, desenhe novas dependências.

Consulte:

Resumo: Pontos fortes de diagramas de camada

Os diagramas de camadas ajudam você a:

  • Descreve a arquitetura lógica de um sistema de acordo com a funcionalidade dos artefatos.

  • Verifique se o código em desenvolvimento está de acordo com o design especificado.

Relação a outros diagramas

Diagrama

Descrição

Gráficos de dependência

Visualizar a organização e os relacionamentos no código existente.

Para criar camadas, gere um gráfico de dependência e, em seguida, agrupe os itens no gráfico como camadas potenciais. Arraste os grupos do gráfico para os diagramas da camada.

Consulte:

Diagrama de componente

Descrever componentes, suas interfaces e suas relações.

Para visualizar camadas, crie um diagrama de componente que descreve a funcionalidade de diferentes componentes no sistema.

Consulte:

Recursos externos

Categoria

Links

Fóruns

Blogs

Blog do Visual Studio ALM + Team Foundation Server

Artigos técnicos e diários

O journal de arquitetura - problema 23: A modelagem e os processos de arquitetura

Outros Sites

Centro de Arquitetura do MSDN

Consulte também

Conceitos

Visualizar código

Desenvolvendo modelos para design de software

Usando modelos dentro do processo de desenvolvimento

Usar modelos no desenvolvimento do Agile

Validando o sistema durante o desenvolvimento

Estendendo modelos e diagramas UML