Demonstra Passo a passo: Atualizar um sistema usando a visualização e ferramentas de modelagem.

  • Artigo

Para certificar-se de que um sistema de software atenda aos seus usuários precisa, usar ferramentas de modelagem e a arquitetura Visual Studio Ultimate para ajudá-lo a atualizar o sistema. Essas ferramentas incluem os diagramas de linguagem UML (Unified Modeling), diagramas de camada, gráficos de dependência baseada em código, diagramas de seqüência e diagramas de classe. Por exemplo, você pode usar essas ferramentas para executar essas tarefas:

  • Esclarecer os usuários requisitos e processos de negócios.

  • Visualize e explore o código existente.

  • Descrevem alterações em um sistema existente.

  • Verifique se o sistema atende a seus requisitos.

  • Manter consistente com o design de código.

Esta explicação passo a passo usa um cenário de exemplo para atingir os seguintes objetivos:

  • Fornece uma visão geral das ferramentas e seus benefícios para um projeto de software.

  • Mostrar como as duas equipes pode usar essas ferramentas em um cenário de exemplo, independentemente de suas metodologias de desenvolvimento.

Para obter mais informações sobre essas ferramentas e os cenários em que eles oferecem suporte, consulte:

Neste tópico.

Section

Descrição

Visão geral do cenário

Descreve o cenário de exemplo e seus participantes.

Funções de arquitetura e diagramas no desenvolvimento de Software de modelagem.

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

Compreender e comunicar informações sobre o sistema

Fornece uma visão geral de como os participantes usam as ferramentas neste cenário.

Atualizando o sistema usando a visualização e modelagem

Fornece mais detalhes sobre cada ferramenta e como ele pode ser usado neste cenário.

Visão geral do cenário

Este cenário descreve episódios de ciclos de vida de desenvolvimento de software das duas empresas fictícios: Jantar agora e a Lucerne Publishing. Jantar agora fornece um serviço de entrega de refeições baseado na Web em Seattle. Os clientes podem solicitar refeições e pagá-los no site da Web agora para jantar. Os pedidos são enviados para o restaurante local apropriado para entrega. A Lucerne Publishing, uma empresa em Nova York, várias empresas é executado fora e na Web. Por exemplo, eles executarem um site onde os consumidores podem postar restaurante revisões.

Zulu recentemente adquirida jantar agora e deseja fazer as seguintes alterações:

  • Integre seus sites da Web, adicionando recursos de revisão do restaurante para jantar agora.

  • Substitua o sistema de pagamento do jantar agora por da Lucerne.

  • Expanda o serviço jantar agora em todo o país.

Jantar agora usa o SCRUM e programação eXtreme. Eles têm cobertura de teste muito alto e o código muito pouco sem suporte. Eles minimizam os riscos por criação de pequenas, mas as versões do trabalho de um sistema e adicionando incrementalmente a funcionalidade. Desenvolvem seus códigos sobre iterações curtas e freqüentes. Isso permite que eles absorver alterações com confiança, refatorar o código com freqüência e evitar o "design grande parte da frente".

Zulu mantém uma coleção de imensamente maior e mais complexa de sistemas, dos quais alguns são mais de 40 anos. Eles são muito cuidados ao fazer alterações devido a complexidade e o escopo do código herdado. Eles seguem um processo de desenvolvimento mais rigoroso, preferindo para projetar soluções detalhadas e documentar o design e as alterações que ocorrem durante o desenvolvimento.

Ambas as equipes usam diagramas de modelagem no Visual Studio Ultimate para ajudá-lo a desenvolver sistemas que atendem os usuários precisa. Eles usam Visual Studio Team Foundation Server juntamente com outras ferramentas para ajudá-los para planejar, organizar e gerenciar seus trabalhos.

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

  • Planejamento e acompanhamento de trabalho

  • Testes, validação e verificação no código atualizado

Funções de arquitetura e diagramas no desenvolvimento de Software de modelagem.

A tabela a seguir descreve as funções que essas ferramentas podem reproduzir durante várias e várias de estágios do ciclo de vida de desenvolvimento de software:

Modelagem de requisitos de usuário

Modelagem de processos de negócios

Arquitetura de sistema & Design

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

Verificação

Diagrama de caso de uso (UML)

√

√

√

Diagrama de atividade (UML)

√

√

√

√

Diagrama de classe (UML)

√

√

√

√

Diagrama de componente (UML)

√

√

√

√

Diagrama de seqüência (UML)

√

√

√

√

Diagrama de domínio-DSL (linguagem específica)

√

√

√

Diagrama de camada, validação de camada

√

√

√

Class Designer (baseada em código)

√

Diagrama de seqüência (baseada em código)

√

√

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

√

√

Explorer de arquitetura

√

Para desenhar os diagramas UML e diagramas de camada, você deve criar um projeto de modelagem como parte de uma solução existente ou um novo. Esses diagramas devem ser criados no projeto da modelagem. Itens em diagramas UML são parte de um modelo comum e os diagramas UML são modos de exibição desse modelo. Itens em diagramas de camada estão localizados no projeto de modelagem, mas elas não são armazenadas no modelo comum. Geralmente existem dependência baseada em código gráficos, diagramas de seqüência e diagramas de classe fora do projeto de modelagem.

Para obter mais informações, consulte:

Para mostrar exibições alternativas da arquitetura, você pode reutilizar certos elementos do mesmo modelo em vários ou diagramas diferentes. Por exemplo, você pode arrastar um componente para outro diagrama de componente ou um diagrama de seqüência, para que ele pode funcionar como um ator. Para obter mais informações, consulte Como: Editar um modelo UML e diagramas.

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.

Para obter mais informações, consulte:

Compreender e comunicar informações sobre o sistema

Há uma ordem recomendada para usar o Visual Studio Ultimate a modelagem de diagramas, para que possa usá-los como elas se encaixam com suas necessidades ou método. Geralmente, as equipes revisitar seus modelos iterativamente e freqüentemente em todo o projeto. Cada diagrama oferece vantagens específicas para ajudá-lo a compreender, descrever e comunicar os diferentes aspectos do sistema em desenvolvimento.

Jantar agora e Lucerne se comunicam entre si e com os participantes do projeto, usando diagramas como sua linguagem comum. Por exemplo, jantar agora usa diagramas para executar essas tarefas:

  • Visualize o código existente.

  • Se comunicar com a Lucerne sobre histórias de usuários novos ou atualizados.

  • Identifica as alterações necessárias para suportar as histórias de usuários novos ou atualizados.

A Lucerne usa diagramas para executar essas tarefas:

  • Saiba mais sobre o processo de negócios jantar agora.

  • Compreenda o design do sistema.

  • Comunicar-se com jantar agora sobre os requisitos do usuário novo ou atualizado.

  • Atualizações de documento para o sistema.

Os diagramas são integrados com Team Foundation Server para que as equipes podem planejar, gerenciar e controlar o seu trabalho mais facilmente. Por exemplo, eles usam modelos para identificar os casos de teste e tarefas de desenvolvimento e estimam seu trabalho. Links de Zulu Visual Studio Team Foundation Server itens para os elementos de modelo de trabalho, para que eles podem monitorar o progresso e certificar-se de que o sistema atende os usuários requisitos. Por exemplo, eles vincular casos de uso para os itens de trabalho do caso de teste para que eles possam ver que os casos de uso são cumpridos quando todos os testes passarem.

Antes de verificar se as equipes em suas alterações, eles validam o código contra os testes e o design executando compilações incluem validação de camada e testes automatizados. Isso ajuda a garantir que o código atualizado não entrem em conflito com o design e interromper a funcionalidade de trabalho anteriormente.

Para obter mais informações, consulte as seções a seguir:

  • Noções básicas sobre a função do sistema no processo de negócios

  • Descrever os requisitos do usuário novo ou atualizado

  • Criar testes de modelos

  • Identificando alterações ao sistema existente

  • Manter o código consistentes com o design.

  • Dicas gerais para criação e uso de modelos

  • Planejamento e acompanhamento de trabalho

  • Testes, validação e verificação no código atualizado

Noções básicas sobre a função do sistema no processo de negócios

Zulu quer saber mais sobre o processo de negócios jantar agora. Eles criam os diagramas a seguir para esclarecer seu entendimento com jantar agora com mais facilidade:

Diagrama

Descreve

Diagrama de caso de uso (UML)

Para obter mais informações, consulte:

  • As atividades que o sistema jantar agora oferece suporte

  • As pessoas e sistemas externos, executam as atividades

  • Os principais componentes do sistema que suportam cada atividade.

  • As partes do processo de negócios que estão fora do escopo do sistema atual, por exemplo, a entrega de alimentos

Diagrama de atividade (UML)

Para obter mais informações, consulte:

O fluxo de etapas que ocorrem quando um cliente cria uma ordem

Diagrama de classe (UML)

Para obter mais informações, consulte:

As entidades comerciais e termos usados na discussão e as relações entre essas entidades. Por exemplo, a ordem e o Item de Menu são parte do vocabulário neste cenário.

Por exemplo, a Lucerne cria o seguinte diagrama de caso de uso para compreender as tarefas que são executadas no site da Web agora para jantar e quem os executa:

Casos de uso UML Diagrama

Diagrama de caso de uso UML

O diagrama de atividade a seguir descreve o fluxo das etapas, quando um cliente cria uma ordem no site da Web agora para jantar. Nesta versão, os elementos de comentário identificam as funções e linhas criam as raias, que organize as etapas por função:

Atividade UML Diagrama

Diagrama de atividade UML

O diagrama de classe a seguir descreve as entidades que participam do processo de pedido:

Em Diagramade classe UML

Diagrama de classe UML

Descrever os requisitos de usuário novo ou atualizado

Zulu quer adicionar funcionalidade ao sistema jantar agora para que os clientes podem ler e revisões do restaurante do contribute. Eles atualizar os diagramas a seguir para que eles possam descrever e discutir esse novo requisito com jantar agora:

Diagrama

Descreve

Diagrama de caso de uso (UML)

Para obter mais informações, consulte:

Um novo caso de uso para "Gravação de um restaurante"

Diagrama de atividade (UML)

Para obter mais informações, consulte:

As etapas que ocorrem quando um cliente quiser escrever uma revisão de restaurante

Diagrama de classe (UML)

Para obter mais informações, consulte:

Os dados que é necessário para armazenar uma revisão

Por exemplo, o diagrama de caso de uso a seguir inclui um novo "gravar revisão" caso de uso para representar o novo requisito. Ele é realçado em laranja no diagrama para facilitar a identificação:

Casos de uso UML Diagrama

Diagrama de caso de uso UML

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

Atividade UML Diagrama

Diagrama de atividade UML

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

Em Diagramade classe UML

Diagrama de classe UML

Criar testes de modelos

Ambas as equipes concordam que eles precisam um conjunto completo de testes para o sistema e seus componentes, antes que eles tomem as alterações. A Lucerne possui uma equipe especializada que executa o sistema e testes no nível do componente. Eles reutilizam os testes criados pelo jantar agora e a estrutura desses testes usando os diagramas UML:

  • Cada caso de uso é representado por um ou vários testes. Os elementos no link de diagrama de caso de uso para o caso de teste de itens de trabalho Visual Studio Team Foundation Server.

  • Cada fluxo de um diagrama de seqüência de nível de sistema ou o diagrama de atividade está vinculado a um teste, na pior das hipóteses. A equipe de teste sistematicamente certifica-se de que eles testar todos os caminhos possíveis por meio de diagrama de atividade.

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

Conforme as necessidades mudam e os diagramas são atualizados para refletir essas alterações, os testes também são atualizados. Um requisito é considerado preenchido somente quando os testes foram bem-sucedidos. Quando for possível ou prático, os testes são definidos e com base em diagramas UML, antes de inicia a implementação.

Para obter mais informações, consulte:

Identificando alterações ao sistema existente

Jantar agora deve estimar o custo do novo requisito de reunião. Isso depende parcialmente quanto essa alteração afetará outras partes do sistema. Para ajudá-los a entender isso, um dos desenvolvedores jantar agora cria gráficos e diagramas a seguir a partir do código existente:

Gráfico ou diagrama

Mostra

Gráfico de dependência

Para obter mais informações, consulte:

As dependências e outros relacionamentos de código existente.

Por exemplo, jantar agora pode começar revendo os gráficos de dependência do assembly para uma visão geral sobre assemblies e suas dependências. Eles podem analisar gráficos para explorar os namespaces e classes nesses módulos.

Jantar agora também pode gerar gráficos explorar áreas particulares e outros tipos de relacionamentos no código. Eles usam a arquitetura Explorer para ajudar a localizar e selecionar as áreas e os relacionamentos que interessam.

Diagrama de seqüência baseada em código

Para obter mais informações, consulte Como: Explore o código com diagramas de seqüência.

A seqüência de interações entre instâncias.

Diagramas de seqüência são gerados as definições de método e são úteis para compreender como o código implementa o comportamento do método.

Diagrama de classes baseadas em código

Para obter mais informações, consulte Como: Adicionar diagramas de classe para projetos (Designer de classe).

Classes existentes no código

Por exemplo, o desenvolvedor gera um gráfico de dependência do namespace do código. Ele ajusta seu escopo para se concentrar em áreas que serão afetadas pela nova situação. Essas áreas estão selecionadas e realçadas no gráfico:

Gráfico de dependência do namespace

Gráfico de dependência do namespace

O desenvolvedor expande os namespaces selecionados para ver suas classes, métodos e relações:

Expandida<>gráfico de dependência do namespace>

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

O desenvolvedor examina o código para localizar os métodos e classes afetados. Ela gera diagramas de seqüência e diagramas de classe do código para descrever e discutir as alterações. Para obter mais informações, consulte Visualizando o código existente.

Dica

Para ver os efeitos de cada alteração torná-los, regenerar os gráficos de dependência e diagramas de seqüência do código após cada alteração.

Descrever as alterações em outras partes do sistema, como, por exemplo, componentes ou interações, a equipe pode desenhar esses elementos em quadros de comunicações. Eles também podem desenhar os diagramas a seguir Visual Studio de modo que os detalhes podem ser capturados, gerenciados e compreendido por ambas as equipes:

Diagramas

Descreve

Diagrama de atividade (UML)

Para obter mais informações, consulte:

O fluxo de etapas que ocorrem quando um cliente faz um pedido de um restaurante novamente, solicitando que o cliente para escrever uma revisão de avisos de sistema.

Diagrama de classe (UML)

Para obter mais informações, consulte:

Classes de lógicas e suas relações. Por exemplo, uma nova classe é adicionada para descrever um revisão e suas relações com outras entidades, como restaurante, Menu, e Customer.

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

Diagrama de classes baseadas em código

Para obter mais informações, consulte Como: Adicionar diagramas de classe para projetos (Designer de classe).

Classes existentes no código.

Diagrama de componente (UML)

Para obter mais informações, consulte:

As partes de alto nível de sistema, como, por exemplo, o jantar agora site e suas interfaces. Essas interfaces definem como componentes interagem com cada outro por meio de métodos ou serviços que fornecem e consomem.

Diagrama de seqüência (UML)

Para obter mais informações, consulte:

A seqüência de interações entre instâncias.

Por exemplo, o diagrama de componente a seguir mostra o novo componente, o que é uma parte do componente jantar agora Web Site. O componente ReviewProcessing lida com a funcionalidade de criação de revisões e aparece realçado em laranja:

Componente UML Diagrama

Diagrama de componente UML

O diagrama de seqüência a seguir mostra a seqüência de interações que ocorrem quando o jantar agora Site verifica se o cliente pediu a partir de um restaurante antes. Se isso for verdadeiro, ele pergunta ao cliente para criar uma revisão, o que é enviada para o restaurante e publicada pelo site da Web:

Seqüência UML Diagrama

Diagrama de seqüência UML

Manter o código consistentes com o Design.

Jantar agora deve se certificar de que o código atualizado permaneça consistente com o design. Eles criam diagramas de camada que descrevem as camadas de funcionalidade no sistema, especificar as dependências permitidas entre os artefatos de solução-las e associar a essas camadas.

Diagrama

Descreve

Diagrama de camada

Para obter mais informações, consulte:

A arquitetura lógica do código.

Um diagrama de camada organiza e mapeia os artefatos em um Visual Studio solução abstrair grupos chamados camadas. Essas camadas identificam as funções, tarefas ou funções que esses artefatos realizar no sistema.

Diagramas de camada são úteis para descrever o design pretendido do sistema e validação de código em evolução contra esse design.

Para criar camadas, arraste os itens no Solution Explorer, gráficos de dependência ou arquitetura Explorer. Para desenhar novas camadas, use a caixa de ferramentas ou o botão direito do mouse na superfície de diagrama.

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

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

Diagrama de camada do sistema de pagamento integrado

Diagrama de camada

Para certificar-se de que está em conflito com o design não ocorre durante o desenvolvimento de código, as equipes usa validação da camada em compilações são executadas em Team Foundation Build. Eles também criam um personalizado MSBuild tarefa exigir validação da camada no seu check-in operações. Eles usam os relatórios de compilação para coletar os erros de validação.

Para obter mais informações, consulte:

Dicas gerais para criação e uso de modelos

  • A maioria dos diagramas consistem em nós são conectados por linhas. Para cada tipo de diagrama, o toolbox fornece diferentes tipos de nós e linhas.

    Para abrir a caixa de ferramentas na Exibir menu, clique em caixa de ferramentas.

  • Para criar um nó, arraste-o na caixa de ferramentas para o diagrama. Determinados 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 apropriada 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 possível origem ou destino, o ponteiro indica se você pode criar uma conexão.

  • Quando você criar itens em diagramas UML, você está adicionando-os para um modelo comum. Os diagramas UML em um projeto de modelagem são modos de exibição desse modelo. Itens em um diagrama de camada são parte do projeto de modelagem, mesmo que elas não são armazenadas no modelo comum.

    Para usar o Gerenciador de modelos para exibir o modelo, clique em Exibir, aponte para Other Windowse em seguida, clique em Gerenciador de modelos.

  • Em alguns casos, você pode arrastar certos itens de Gerenciador de modelos a um diagrama UML. Alguns elementos dentro do mesmo modelo podem ser usados em vários ou alternam de diagramas diferentes para mostrar modos de exibição da arquitetura. Por exemplo, você pode arrastar um componente para outro diagrama de componente ou um diagrama de seqüência a ser usado como um ator.

  • Visual Studio 2010 Ultimateoferece suporte a UML 2.1.2. Esta explicação passo a passo descreve os principais recursos dos diagramas UML nesta versão, mas existem muitos livros que abordam o UML e seu uso em detalhes.

Para obter mais informações, consulte O desenvolvimento de modelos de Design de Software.

Planejamento e acompanhamento de trabalho

O Visual Studio Ultimate diagramas de modelagem são integrados com Acompanhamento de item de trabalho do Team Foundation para que você possa planejar, gerenciar e controlar o trabalho com mais facilidade. Ambas as equipes usam os modelos para identificar os casos de teste e tarefas de desenvolvimento e estimam seu trabalho. Zulu cria e links Visual Studio Team Foundation Server itens para os elementos de modelo, como casos de uso ou componentes. Isso ajuda a monitorar seu progresso e rastrear o seu trabalho de volta para os requisitos dos usuários. Isso ajuda a certificar-se de que suas alterações continuam atender a esses requisitos.

Como seus trabalhos em andamento, a atualização de equipes, itens de trabalho para refletir o tempo gastam por eles em suas tarefas. Também monitorar e relatar o status em seu trabalho usando o seguinte Visual Studio Team Foundation Server recursos:

  • Diariamente relatórios de burndown para mostrar se concluirá o trabalho planejado no tempo esperado. Elas geram outros relatórios semelhantes de Visual Studio Team Foundation Server para controlar o progresso de bugs.

  • Um a planilha de iteração que usa Microsoft Excel para ajudar a monitorar a equipe e equilibrar a carga de trabalho entre membros. Esta planilha está vinculada a Visual Studio Team Foundation Server e fornece o foco da discussão durante suas reuniões de progresso regular.

  • A painel de controle de desenvolvimento que usa Office Project para manter a equipe informada sobre informações de projetos importantes.

Para obter mais informações, consulte:

Testes, validação e verificação de código

Como as equipes de concluir cada tarefa, eles verificam seu código em Controle de versão do Team Foundation e receba lembretes de Visual Studio Team Foundation Server, se esquecerem. Antes de Visual Studio Team Foundation Server aceita seus check-ins, as equipes de executar testes de unidade e a validação de camada para verificar o código contra seus casos de teste e design. Eles usam Team Foundation executar compilações, testes de unidade automatizados e validação da camada regularmente. Isso ajuda a verificar se o código atende aos seguintes critérios:

  • Ele funciona.

  • Ele não quebrará anteriormente o código de trabalho.

  • Ele não entre em conflito com o design.

Jantar agora tem uma grande coleção de testes automatizados, que Lucerne pode reutilizar porque quase tudo ainda se aplicam. Zulu também pode aproveitar esses testes e adicionar novos para cobrir a nova funcionalidade. Ambos usam também Visual Studio Ultimate para executar testes manuais.

Para certificar-se de que o código está de acordo com o design, as equipes de configurar suas compilações em Team Foundation Build para incluir a validação da camada. Se ocorrerem quaisquer conflitos, é gerado um relatório com detalhes.

Para obter mais informações, consulte:

A visualização do sistema usando a atualização e modelagem

Zulu e o jantar agora devem integrar seus sistemas de pagamento. As seções a seguintes mostram os diagramas de modelagem no Visual Studio Ultimate ajudá-los a executar essa tarefa:

  • Compreenda os requisitos do usuário: Diagramas de caso de uso

  • Entenda o processo de negócios: Diagramas de atividade

  • Descreva a estrutura do sistema: Diagramas de componente

  • Descreva as interações: Diagramas de seqüência

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

  • Defina um glossário de tipos: Diagramas de classe

  • Descreva a arquitetura lógica: Diagramas de camada

Para obter mais informações, consulte:

Compreenda os requisitos do usuário: Diagramas de caso de uso

Diagramas de caso de uso resumem as atividades que oferece suporte a um sistema e que realiza essas atividades. A Lucerne usa um diagrama de caso de uso para saber o seguinte sobre o sistema jantar agora:

  • Os clientes criar ordens.

  • Restaurantes recebem ordens.

  • O Gateway de processador de pagamento externo, o que o sistema de pagamento agora jantar usa para validar os pagamentos, está fora do escopo do site da Web.

O diagrama também mostra como alguns dos principais usam a divisão de casos em casos de uso menores. Zulu quer usar seu próprio sistema de pagamento. Eles realçam o caso de uso do processo de pagamento em uma cor diferente para indicar que ele requer alterações:

Realce o processo de pagamento em um <>diagrama de caso de use\ de>

Realce o processo de pagamento no diagrama de caso de uso

Se o tempo de desenvolvimento foi curto, a equipe pode discutir se deseja permitir que os clientes pagam restaurantes diretamente. Para mostrar isso, eles substituiria o caso de uso do processo de pagamento com aquele que está fora do limite de sistema jantar agora. Eles seriam vincule o cliente diretamente para o restaurante, indicando que agora jantar seria apenas processar pedidos:

Rescoping restaurante de pagamento sobre o <>diagrama de caso de use\ de>

Rescoping restaurante de pagamento no diagrama de caso de uso

Para obter mais informações, consulte:

Um diagrama de caso de uso de desenho.

Um diagrama de caso de uso possui os seguintes recursos principais:

  • Atores representam funções executadas por pessoas, organizações, máquinas ou sistemas de software. Por exemplo, o cliente, restaurante e o sistema de pagamento agora jantar são atores.

  • Casos de uso representam as interações entre os atores e o sistema em desenvolvimento. Eles podem representar qualquer escala de interação de um único clique de mouse ou a mensagem para uma transação estendida sobre o número de dias.

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

  • Um caso de uso maior pode incluem menores, por exemplo, criar pedido inclui selecione restaurante. Você pode Estender um caso de uso, adiciona as metas e etapas para o caso de uso estendido, para indicar que o caso de uso ocorre somente sob certas condições. Casos de uso também podem herdar de cada outro.

  • A subsistema representa o sistema de software que está em desenvolvimento ou um de seus componentes. É uma grande caixa que contém os casos de uso. Um diagrama de caso de uso esclarece o que está dentro ou fora do limite do subsistema. Para indicar que o usuário deve realizar certas metas de outras maneiras, desenhar os casos fora do limite do subsistema de uso.

  • Artefatos vincular elementos no diagrama para outros documentos ou diagramas.

Para obter mais informações, consulte:

Resumo: Pontos fortes dos diagramas de caso de uso

Diagramas de caso de uso o ajudará a visualizar:

  • As atividades que um sistema de suporte ou não oferece suporte

  • As pessoas e sistemas externos, realizar essas atividades.

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

  • Como um caso de uso pode dividir em variações ou aqueles de menor

Relação com outros diagramas

Diagrama

Descreve

Diagrama de atividade

O fluxo de etapas em um caso de uso e para aqueles que executar essas etapas em que o caso de uso.

Os nomes de casos de uso freqüentemente espelham as etapas em um diagrama de atividade. Diagramas de atividade dão suporte a elementos como, por exemplo, decisões, mesclagens, entradas e saídas, fluxos simultâneos e assim por diante.

Para obter mais informações, consulte:

Diagrama de seqüência

A seqüência de interações entre os participantes de um caso de uso.

Para obter mais informações, consulte:

Diagrama de classe (UML)

Os tipos que participam no caso de uso ou entidades.

Para obter mais informações, consulte:

Entenda o processo de negócios: Diagramas de atividade

Diagramas de atividade descrevem o fluxo de etapas de um processo de negócios e fornecem uma maneira simples de se comunicar de fluxo de trabalho. Um projeto de desenvolvimento pode ter vários diagramas de atividade. Normalmente, uma atividade engloba todas as ações resultantes de uma ação externa, como, por exemplo, pedidos refeição, atualizando um menu ou a adição de um restaurante novo para os negócios. Uma atividade também pode descrever os detalhes de uma ação complexa.

Zulu atualiza o diagrama de atividade para mostrar que a Lucerne processa o pagamento e paga o restaurante. Eles substituem o sistema de pagamento agora jantar com o sistema de pagamento Lucerne conforme realçado:

Sistema de pagamento Lucerne em <>diagrama de atividade de>

Substituindo o jantar agora pagamento sistema no diagrama de atividade

A Ajuda do diagrama atualizado Zulu e o jantar agora visualizar onde o sistema de pagamento Lucerne se encaixa no processo de negócios. Nesta versão, os comentários são usados para identificar as funções que executam as etapas. As linhas são usadas para criar as raias, que organize as etapas por função.

As equipes também podem considerar a discussão de um texto alternativo, onde o cliente paga o restaurante em vez disso, após o pedido for entregue. Isso criaria a diferentes requisitos do sistema de software.

Anteriormente, agora jantar desenhei esses diagramas em um quadro branco ou no PowerPoint. Agora também usarem Visual Studio Ultimate para desenhar esses diagramas que ambas as equipes podem capturar, entender e gerenciar os detalhes.

Para obter mais informações, consulte:

Um diagrama de atividade de desenho.

Um diagrama de atividade possui os seguintes recursos principais:

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

    O diagrama deve sempre ter um de nós.

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

  • Controlar fluxos de que mostram o fluxo entre ações.

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

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

  • Nós finais da atividade que mostra extremidades da atividade.

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

Para obter mais informações, consulte:

Resumo: Pontos fortes dos diagramas de atividade

Diagramas de atividades ajudam você a visualizar e descrever o fluxo de controle e de informações entre as ações de uma empresa, o sistema ou o programa. Esta é uma maneira simple e útil para descrever o fluxo de trabalho ao se comunicar com outras pessoas.

Relação com outros diagramas

Diagrama

Descrição

Diagrama de caso de uso

Resuma as atividades que realiza a cada ator.

Para obter mais informações, consulte:

Diagrama de componente

Para visualizar o sistema como uma coleção de partes reutilizáveis que forneça ou consuma comportamento por meio de um conjunto bem definido de interfaces.

Para obter mais informações, consulte:

Descreva a estrutura do sistema: Diagramas de componente

Diagramas de componente descrevem um sistema como uma coleção de partes separável que forneça ou consuma comportamento por meio de um conjunto bem definido de interfaces. As partes podem estar em qualquer escala e podem se conectar de qualquer maneira.

Para ajudar a Lucerne e jantar agora visualizar e discuta os componentes do sistema e suas interfaces, eles criam os diagramas de componente a seguir:

ComponentesExterno do sistema de pagamento

Componentes do sistema de pagamento jantar agora

Este diagrama mostra os tipos diferentes de componente e seus dependências. Por exemplo, o jantar agora Site e o sistema de pagamento Lucerne exigem o Gateway de processador de pagamento externo validar os pagamentos. As setas entre componentes representam as dependências que indicam quais componentes requerem a funcionalidade de outros componentes.

Para usar o sistema de pagamento Zulu, o jantar agora Site deve ser atualizado para usar as interfaces PaymentApproval e PayableInsertion no sistema de pagamento Lucerne.

O diagrama a seguir mostra uma configuração específica de componentes para o jantar agora Site. Essa configuração indica que qualquer instância do site consiste em quatro peças:

  • CustomerProcessing

  • OrderProcessing

  • ReviewProcessing

  • PaymentProcessing

Essas partes são instâncias dos tipos de componente especificado e estão conectados como segue:

Componentes dentro de jantar agora <>>Web site.

Componentes dentro do jantar agora Site da Web

O jantar agora Site delega o seu comportamento para essas partes, que lidam com as funções do site. As setas entre o componente pai e seus componentes de membro mostram as delegações de que indicam quais partes tratar as mensagens que o pai recebe ou envia através das interfaces.

Nessa configuração, o componente de PaymentProcessing processos de pagamentos do cliente. Portanto, deve ser atualizado para integrar o sistema de pagamento da Lucerne. Em outras situações, várias instâncias de um tipo de componente podem existir no mesmo componente pai.

Para obter mais informações, consulte:

Um diagrama de componente de desenho.

Um diagrama de componente possui os seguintes recursos principais:

  • Componentes que representam partes separável de funcionalidade do sistema.

  • Fornecido portas de interface que representam grupos de mensagens ou chamadas que a implementação de componentes e são usados por outros componentes ou sistemas externos.

  • Portas de interface necessárias que representam grupos de mensagens ou chamadas que 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.

  • Partes são membros dos componentes e geralmente são instâncias de outros componentes. Uma parte é uma parte do design interno do componente pai.

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

  • Delegações que indicam a partes de um componente tratar as mensagens enviados e recebidos pelo componente pai.

Para obter mais informações, consulte:

Resumo: Pontos fortes dos diagramas de componente

Diagramas de componente ajudam a visualizar:

  • O sistema como uma coleção de partes separável, independentemente de sua linguagem de implementação ou o estilo.

  • Componentes com interfaces bem definidas, facilitando o design compreender e atualizar quando os requisitos mudam.

Relação com outros diagramas

Diagrama

Descrição

Gráfico de dependência

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

Para identificar os candidatos para componentes, crie uma dependência gráfico e o grupo de itens por sua função no sistema.

Para obter mais informações, consulte:

Diagrama de seqüência

Visualize a seqüência de interações entre os componentes ou as partes dentro de um componente.

Para criar uma linha de vida em um diagrama de seqüência de um componente, clique com o botão direito do componente e, em seguida, clique em Criar Lifeline.

Para obter mais informações, consulte:

Diagrama de classe (UML)

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

Para obter mais informações, consulte:

Diagrama de camada

Descreva a arquitetura lógica do sistema, como ele se relaciona aos componentes. Use a validação de camada para certificar-se de que o código permanece consistente com o design.

Para obter mais informações, consulte:

Diagrama de atividade

Visualize o processamento interno, os componentes executam em resposta às mensagens de entrada.

Para obter mais informações, consulte:

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

Gráficos de dependência mostram a organização atual e as relações no código. Elementos são representados por nós no gráfico, e os relacionamentos são representados por links. Gráficos de dependência podem ajudá-lo a realizar os seguintes tipos de tarefas:

  • Explore o código não familiar.

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

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

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

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

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

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

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

Métodos dentro de PaymentProcessing e dependências

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

Eles geram o gráfico a seguir para o sistema de pagamento Lucerne inspecionar suas classes, métodos e dependências. A equipe vê que o sistema Lucerne também pode exigir trabalho para interagir com outras partes do jantar agora:

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

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

Ambas as equipes trabalham juntos para determinar as alterações necessárias para integrar os dois sistemas. Decidirem refatorar alguns códigos para que ele será mais fácil de atualizar. A classe PaymentApprover se moverá para o namespace DinnerNow.Business e exige alguns novos métodos. Jantar agora classes que lidam com transações terá seu próprio namespace. As equipes de criar e usam os itens de trabalho para planejar, organizar e controlar o seu trabalho. Eles vincular os itens de trabalho para os elementos de modelo em que é útil.

Após o código de reorganização, as equipes de geram um novo gráfico de dependência para ver a estrutura atualizada e relacionamentos:

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

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

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

Criando um gráfico de dependência

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

    Sobre o arquitetura , aponte para Gerar o gráfico de dependênciae, em seguida, clique em Pelo Assembly, Por Namespace, ou Por classe. Para incluir uma combinação desses elementos, clique em personalizado.

    Para obter uma visão geral rápida de código compilado, criar um gráfico de dependência em branco e em seguida, arraste os arquivos de assembly ou arquivos executáveis para a superfície do gráfico.

    Para obter mais informações, consulte Como: Gere gráficos de dependência para.NET de código.

  • Para explorar o código específico ou itens de solução, use o Explorer de arquitetura para selecionar os elementos e relacionamentos que você deseja visualizar. Você pode, em seguida, gerar um novo gráfico ou adicionar itens selecionados para um gráfico existente.

    Para obter mais informações, consulte Como: Localizar o código usando o Explorer de arquitetura.

  • Para ajudá-lo a explorar o gráfico, reorganize o layout para que ela fique adequada para os tipos de tarefas que você deseja executar.

    Por exemplo, para visualizar as camadas no código, selecione um layout de árvore. Para obter mais informações, consulte Como: Procurar e navegar por documentos do gráfico.

  • Para ajudá-lo a se concentrar em áreas específicas do gráfico, ajustar seu escopo por filtragem de elementos ou personalizar sua aparência. Para obter mais informações, consulte Como: Editar e personalizar documentos do gráfico.

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

Gráficos de dependência ajudam você a:

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

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

  • Encontre áreas de complexidade, padrões, camadas ou outras áreas que você possa melhorar para tornar o código mais fácil de manter, alterar e reutilização.

Relação com outros diagramas

Diagrama

Descreve

Diagrama de camada

A arquitetura lógica do sistema. Use a validação de camada para certificar-se de que o código permanece consistente com o design.

Para ajudá-lo a identificar as camadas existentes ou camadas pretendidas, criar um gráfico de dependência e agrupar itens relacionados. Para criar um diagrama de camada, arraste os itens de gráfico ou de Explorer de arquitetura.

Para obter mais informações, consulte:

Diagrama de componente

Componentes, suas interfaces e suas relações.

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

Para obter mais informações, consulte:

Diagrama de classe (UML)

Classes, seus atributos e operações e seus relacionamentos.

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

Para obter mais informações, consulte:

Diagrama de classe (baseada em código)

Classes existentes no código.

Para visualizar e modificar uma classe existente no código, use o Class Designer.

Para obter mais informações, consulte Como: Adicionar diagramas de classe para projetos (Designer de classe).

Descreva as interações: Diagramas de seqüência

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

Para ajudar a Lucerne e jantar agora descrever e discutir as etapas no caso de uso do processo de pagamento, criarão o diagrama de seqüência a seguir do diagrama de componente. As linhas de vida espelham o jantar agora componente do Site e suas partes. As mensagens que aparecem entre linhas de vida sigam as conexões nos diagramas de componente:

Diagrama de seqüência para pagamento do processo <>>use\ case

Caso de uso do diagrama de seqüência para o processo de pagamento

O diagrama de seqüência mostra que, quando o cliente cria uma ordem, o jantar agora Site chama ProcessOrder em uma instância de OrderProcessing. Em seguida, o OrderProcessing chama o ProcessPayment em PaymentProcessing. Isso continua até que o Gateway de processador de pagamento externo valida o pagamento. Só então o controle retorne para o jantar agora Site.

Zulu deve estimar o custo de atualização de seu sistema de pagamento para integrar com o sistema de jantar agora. Para ajudá-los a entender isso, um dos seus desenvolvedores gera diagramas de seqüência do código para visualizar as interações existentes.

Para obter mais informações, consulte:

Um diagrama de seqüência de desenho.

Um diagrama de seqüência possui os seguintes recursos principais:

  • Vertical linhas de vida representam os atores ou instâncias de objetos de software.

    Para adicionar um símbolo de ator, o que indica que um participante está fora do sistema em desenvolvimento, clique em linha de vida. No Propriedades janela, defina ator para True. Se o Propriedades janela não estiver aberta, pressione F4.

  • Horizontal mensagens representar chamadas de método, mensagens de serviço da Web ou algum outro tipo de comunicação. Ocorrências de execução estão recebendo de retângulos de sombreado verticais que aparecem em linhas de vida e representam os períodos durante os quais chamadas do processo de objetos.

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

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

Para obter mais informações, consulte:

Resumo: Pontos fortes dos diagramas de seqüência

Diagramas de seqüência ajudam a visualizar:

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

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

Relação com outros diagramas

Diagrama

Descrição

Diagrama de classe (UML)

Definir as classes que representa a vida e os parâmetros e retornar valores que são usados em mensagens enviadas entre linhas de vida.

Para criar uma classe a partir de uma linha de vida, clique com o botão direito na linha de vida e, em seguida, clique em Criar classe ou Criar Interface. Para criar uma linha de vida de um tipo em um diagrama de classe, o tipo de atalho e clique em Criar Lifeline.

Para obter mais informações, consulte:

Diagrama de componente

Descreva os componentes que representam a vida e as interfaces que fornecem e consomem o comportamento representado pelas mensagens.

Para criar uma linha de vida de um diagrama de componente, clique com o botão direito do componente e, em seguida, clique em Criar Lifeline.

Para obter mais informações, consulte:

Diagrama de caso de uso

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

Para obter mais informações, consulte:

Defina um glossário de tipos: Diagramas de classe

Diagramas de classe definem as entidades, termos ou conceitos que participam no sistema e suas relações uns com os outros. Por exemplo, você pode usar esses diagramas durante o desenvolvimento para descrever os atributos e operações para cada classe, independentemente de sua linguagem de implementação ou o estilo.

Para ajudar a Lucerne descrever e discutir as entidades que participam do caso de uso do processo de pagamento, eles desenhar o diagrama de classe a seguir:

Entidades de pagamento de processo de <>diagrama de classes de>

Entidades de pagamento em um diagrama de classe de processo.

Este diagrama mostra que um cliente pode ter muitos pedidos e diferentes maneiras para ordens de pagamento. BankAccount e CreditCard herdam o pagamento.

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

Processar pagamentos <>>entidade detalhes sobre um <>diagrama de classes de>

Detalhes de pagamento no diagrama de classe de processo.

Para obter mais informações, consulte:

Um diagrama de classes de desenho.

Um diagrama de classe tem os seguintes recursos principais:

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

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

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

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

  • Atributos são valores de um determinado tipo que descrevem cada instância de um classificador. Um classificador é um nome geral para tipos, componentes, casos de uso e atores mesmo.

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

  • Um umssociação indica algum tipo de relação entre dois classificadores.

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

    • A composição é uma associação que indica uma relação de parte do todo entre classificadores.

    Para mostrar as agregações ou composições, defina a agregação propriedade em uma associação. Compartilhados mostra as agregações e composto mostra composições.

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

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

    Para criar essas relações, use o herança ferramenta. Como alternativa, uma percepção pode ser representada como uma pirulito.

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

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

Para obter mais informações, consulte:

Resumo: Pontos fortes dos diagramas de classe

Diagramas de classe ajudam a definir:

  • Um glossário comum de termos para usar ao discutir os usuários necessidades e as entidades que participam no sistema. Para obter mais informações, consulte Requisitos do usuário de modelagem..

  • Tipos que são usados por partes do sistema, como, por exemplo, componentes, independentemente de sua implementação. Para obter mais informações, consulte A arquitetura de um sistema de Software de modelagem..

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

Relação com outros diagramas

Diagrama

Descrição

Diagrama de caso de uso

Definir os tipos que são usados para descrever as metas e etapas em casos de uso.

Para obter mais informações, consulte:

Diagrama de atividade

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

Para obter mais informações, consulte:

Diagrama de componente

Descreva os componentes, suas interfaces e suas relações. Uma classe também pode descrever o total do componente.

Para obter mais informações, consulte:

Diagrama de camada

Defina a arquitetura lógica do sistema como ele se relaciona às classes.

Use a validação de camada para certificar-se de que o código permanece consistente com o design.

Para obter mais informações, consulte:

Diagrama de seqüência

Definir os tipos de linhas de vida e as operações, parâmetros e retornar valores para todas as mensagens que pode receber a linha de vida.

Para criar uma linha de vida de um tipo em um diagrama de classe, o tipo de atalho e clique em Criar Lifeline.

Para obter mais informações, consulte:

Gráfico de dependência

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

Para identificar seus métodos de classes e seus relacionamentos, crie um documento de gráfico que mostra esses elementos.

Para obter mais informações, consulte:

Descreva a arquitetura lógica: Diagramas de camada

Diagramas de camada descrevem a arquitetura lógica de um sistema, organizando os artefatos em sua solução em grupos abstratos, ou camadas. Artefatos podem ser muitas coisas, como, por exemplo, namespaces, projetos, classes, métodos e assim por diante. Camadas representam e descrevem as funções ou tarefas que os artefatos executam no sistema. Você também pode incluir a validação da camada em suas operações de check-in para certificar-se de que o código permanece consistente com o seu design e a compilação.

Para manter o código consistentes com o design, jantar agora e Lucerne usam o diagrama de camada a seguir para validar o seu código conforme ela evolui:

Diagrama de camada do sistema de pagamento integrado

Diagrama de camada para jantar agora integrado com Lucerne

As camadas neste diagrama vincular os artefatos de solução de jantar agora e Lucerne correspondentes. Por exemplo, os links de camada de negócios para o namespace DinnerNow.Business e seus membros, que agora incluem a classe PaymentApprover. Os links de camada de acesso a recursos para o namespace DinnerNow.Data. As setas ou dependências, especificar que a camada de negócios pode usar a funcionalidade na camada de acesso a recursos. Como as equipes de atualizar seu código, validação de camada é executada regularmente para detectar conflitos que ocorrem e para ajudar as equipes a resolvê-los imediatamente.

As equipes trabalham juntas para integrar de forma incremental e testar os dois sistemas. Eles primeiro certifique-se de que PaymentApprover e o resto do jantar agora funcionam com um outro com êxito antes de lidar com o PaymentProcessing.

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

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

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

Jantar agora comentários após eles confirmarem se o sistema funciona conforme esperado, o código de PaymentProcessing. Os relatórios de validação de camada estão limpos e o gráfico de dependência resultante mostra que não há mais dependências PaymentProcessing existem:

Gráfico de dependência sem PaymentProcessing

Gráfico de dependência sem PaymentProcessing

Para obter mais informações, consulte:

Um diagrama de camada de desenho.

Um diagrama de camada tem os seguintes recursos principais:

  • Camadas grupos lógicos de artefatos de descrever.

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

    Para criar camadas de artefatos, arraste os itens no Solution Explorer, gráficos de dependência ou arquitetura Explorer. Para desenhar novas camadas e, em seguida, vinculá-las para artefatos, use a caixa de ferramentas ou botão direito do mouse na superfície de diagrama para criar as camadas e arraste os itens a essas camadas.

    O número em uma camada mostra o número dos artefatos que estão vinculados à camada. Esses artefatos podem ser namespaces, projetos, classes, métodos e assim por diante. Quando você interpretar o número de artefatos em uma camada, lembre-se de:

    • Se uma camada de links para um artefato que contém outros artefatos, mas a camada não se vincular diretamente a outros artefatos, o número inclui somente o artefato vinculado. No entanto, 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, o número de artefatos vinculados é 1, mesmo se o namespace contém classes. Se a camada também tem links para cada classe no namespace, o número incluirá as classes vinculadas.

    • Se uma camada contém outras camadas vinculadas a artefatos, em seguida, a camada de recipiente também está vinculada a esses artefatos, mesmo que o número da camada de contêiner não inclui esses artefatos.

    Para ver os artefatos que estão vinculados a uma camada, clique com o botão direito na camada e clique em Exibir Links abrir Explorer de camada de.

  • A dependência indica que uma camada pode usar a funcionalidade em outra camada, mas não vice-versa. A bidirecional dependência 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 na superfície de diagrama e clique em Gerar dependências. Para descrever as dependências pretendidas, desenhe as novas.

Para obter mais informações, consulte:

Resumo: Pontos fortes dos diagramas de camada

Diagramas de camada ajudam você a:

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

  • Certifique-se de que o código em desenvolvimento está de acordo com o projeto especificado.

Relação com outros diagramas

Diagrama

Descrição

Gráfico de dependência

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

Para criar camadas, gerar um gráfico de dependência e agrupe itens no gráfico como camadas possíveis. Arraste os grupos do gráfico para o diagrama de camada.

Para obter mais informações, consulte:

Diagrama de componente

Descreva os componentes, suas interfaces e suas relações.

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

Para obter mais informações, consulte:

Recursos externos

Vídeos

link para vídeo

link para vídeo

link para vídeo

link para vídeo

Fóruns

Visualização de 2010 Visual Studio & Ferramentas de modelagem

Visualização de 2010 Visual Studio & Modelagem SDK (ferramentas DSL)

Blogs

Blog do Skinner

Recursos favoritos do VS2010: Camada de validação

Recursos favoritos do VS2010: Gráficos de dependência e DGML

Artigos técnicos e diários

O Architecture Journal - 23 do problema: Modelagem de arquitetura e processos

Outros Sites.

MSDN Architecture Center

Consulte também

Conceitos

Visualizando o código existente

O desenvolvimento de modelos de Design de Software

Usando modelos dentro do processo de desenvolvimento

Validando o sistema durante o desenvolvimento

Diagramas e modelos UML estendendo

Outros recursos

Using Models in Agile Development