Visão geral de cenário: Alterar o design usando visualização e modelagem
Para certificar-se que o sistema de software atender suas necessidades de usuários, use a visualização e ferramentas modelar em Visual Studio Ultimate para ajudá-lo a atualizar ou alterar o design do sistema. Essas ferramentas incluem diagramas de UML (UML), diagramas de camada, arquivos gráficos baseados de dependência, diagramas de sequência, e diagramas de classe. Por exemplo, você pode usar essas ferramentas para executar essas tarefas:
Para os requisitos e os processos comerciais de usuários.
Visualize e explorar o código existente.
Descreve alterações para um sistema existente.
Verifique se o sistema atende aos requisitos.
Manter o código consistente com o design.
Essa explicação passo a passo usa um cenário exemplo para obter os seguintes metas:
Fornece uma visão geral de alto nível de ferramentas e seus benefícios a um projeto de software.
Mostrar como dois equipes podem usar essas ferramentas em um cenário exemplo, independentemente do desenvolvimento aproxima-se.
Para obter mais informações sobre essas ferramentas e cenários que suportam, consulte:
Neste tópico.
Seção |
Descrição |
---|---|
Visão geral do cenário |
Descreve o cenário de exemplo e seus participantes. |
Funções de arquitetura e diagramas de modelagem durante a programação de software |
Descreve as funções que essas ferramentas podem executar durante o ciclo de vida de programação de software. |
Compreensão e informações de comunicação sobre o sistema |
Fornece uma visão geral de alto nível de como os participantes usando as ferramentas nesse cenário. |
Atualizando o sistema usando o visualizador e modelar-lo |
Fornece um detalhe mais profundo sobre cada ferramenta e como ele pode ser usada nesse cenário. |
Visão geral do cenário
Este cenário descreve episódios de ciclos de vida de programação de software de duas empresas fictícias: Comensal agora e publicação de lucerna.O comensal agora fornece um serviço baseados na web de entrega de refeição em Seattle.Os clientes podem pedir refeições e pagá-las por eles no site de comensal agora.Os pedidos são enviados para o restaurante local apropriado para entrega.A publicação de lucerna, uma empresa em New York, executa vários negócios ambos em vez da Web.Por exemplo, efetuam um site onde os clientes podem postar revisões de restaurante.
A lucerna adquiriu recentemente o comensal agora e desejar-lo para fazer as seguintes alterações:
Integre sites adicionar recursos de revisão de restaurante ao comensal agora.
Substitua o comensal é agora sistema de pagamento com o sistema de lucerna.
Expanda o comensal os serviços de aplicativos agora em toda a região.
O comensal agora usa o SCRUM e a extrema programação.Têm a tinta muito alta e de uma vez de teste código sem suporte.Minimizam riscos criando pequeno mas trabalhando versões de um sistema e depois adicionando funcionalidade incremental.Desenvolvem o código iterações sobre curtas e frequentes.Isso deixa-os abraçar segura a alteração, o código do refatorar geralmente, e evita-o “design” grande honesto.
A lucerna mantém uma coleção vastamente maior e complexa de sistemas, alguns dos quais são mais de 40 anos antigo.São muito cuidado sobre a feitura de alterações devido à complexidade e o 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.
Uso de dois equipes que modela diagramas em Visual Studio Ultimate para ajudá-los a desenvolver sistemas que atendem às necessidades de usuários.Usam o Team Foundation Server ao lado de outras ferramentas para ajudá-las a planejar, organizar, e gerenciar seu trabalho.
Para obter mais informações sobre do Team Foundation Server, consulte:
Planejamento de trabalho e de rastreamento
Testando, validação, e no código atualizado
Funções de arquitetura e diagramas de modelagem durante a programação 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 |
A modelagem do processo enterprise |
Arquitetura e design do sistema |
Visualização e exemplos de código |
Verificação |
|
---|---|---|---|---|---|
Use o diagrama dos casos (UML) |
√ |
√ |
√ |
||
Diagrama de atividade (UML) |
√ |
√ |
√ |
√ |
|
Diagrama de classe (UML) |
√ |
√ |
√ |
√ |
|
Diagrama de componente (UML) |
√ |
√ |
√ |
√ |
|
Diagrama de sequência (UML) |
√ |
√ |
√ |
√ |
|
Diagrama de domínio específico de (DSL) de linguagem |
√ |
√ |
√ |
||
Diagrama de camada, a validação de camada |
√ |
√ |
√ |
||
Gráfico de dependência (código baseado) |
√ |
√ |
√ |
||
Diagrama de sequência (código baseado) |
√ |
√ |
|||
Designer de classe (código baseado) |
√ |
||||
Arquitetura Explorer |
√ |
Para desenhar diagramas de UML e diagramas de camadas, você deve criar um projeto modelando como parte de uma solução existente ou um novo.Esses diagramas devem ser criados no projeto modelando.Os itens em diagramas de UML são parte de um modelo comum, e os diagramas de UML são exibições do modelo.Os itens em diagramas de camada estão localizados no projeto modelagem, mas não são armazenados no modelo comum.Gráficos de dependência, os diagramas de sequência, e os arquivos com base diagramas de classe existem geralmente fora do projeto modelando.
Consulte:
Visualizar dependências de código em gráficos de dependência
Como: Adicionar diagramas de classes a projetos (Designer de classe)
Visualização e modelagem SDK - linguagens específicas de domínio
Para mostrar exibições alternativas da arquitetura, você pode reutilizar determinados elementos do mesmo modelo em vários ou diagramas diferentes.Por exemplo, você pode arrastar um componente para outro diagrama componente ou um diagrama de sequência de modo que pode funcionar como um ator.Consulte Como: Editar modelos e diagramas UML.
Ambas as equipes também usam a validação de camada para certificar-se que o código permaneça em desenvolvimento consistente com o design.
Consulte:
Mantendo o código consistente com o design
Descreve a arquitetura lógica: Mergulhe diagramas
Validar o código com diagramas de camada
Observação suporte deVisual Studio Premium mergulham validação e versões somente leitura desses elementos gráficos e diagramas para a visualização e modelagem.
Compreensão e informações de comunicação sobre o sistema
Não há nenhum pedido prescrito para usar Visual Studio Ultimate que modela diagramas, então você pode usá-las como cabem com suas necessidades ou abordagem.Em geral, as equipes revisitam seus modelos iterativa e frequentemente em todo um projeto.Cada diagrama oferece pontos específicos para ajudar você a entender, descrever, e comunicar desenvolvimento em diferentes aspectos do sistema.
O comensal agora e a lucerna se comunicam com cada outro e com os participantes de projeto usando diagramas como sua linguagem comum.Por exemplo, o comensal agora usa diagramas para executar essas tarefas:
Visualize o código existente.
Comunique-se com a lucerna sobre novos ou artigos atualizados do usuário.
Identifica as alterações que são necessárias para suportar novos ou artigos atualizados do usuário.
A lucerna usa diagramas para executar essas tarefas:
Aprender sobre o processo enterprise de comensal agora.
Compreender o design do sistema.
Comunique-se com o comensal agora sobre novos ou requisitos de usuário atualizados.
Documento atualizações para o sistema.
Os diagramas são integrados com o Team Foundation Server para que os equipes pode imaginar, gerenciamento, e acompanhar seu trabalho mais facilmente. Por exemplo, usam modelos para identificar situações de teste e tarefas de desenvolvimento e para estimar seu trabalho.Itens de trabalho Team Foundation Server de links de lucerna para modelar os elementos de modo que podem monitorar o progresso e se certificar de que o sistema atende aos requisitos de usuários.Por exemplo, vinculam caso de uso de itens de trabalho de situação de teste para que eles possam ver que o caso de uso são atendidos quando todos os testes passam.
Antes que as equipes fazer check-in de suas alterações, validam código para os testes e o 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 está em conflito com o design e a quebra que funcionam anteriormente funcionalidade.
Consulte:
Entendendo a função do sistema no processo enterprise
Descrevendo novos ou requisitos de usuário atualizados
Criando modelos de teste
Identificar alterações ao sistema existente
Mantendo o código consistente com o design
Dicas gerais para criar e usar modelos
Planejamento de trabalho e de rastreamento
Testando, validação, e no código atualizado
Entendendo a função do sistema no processo enterprise
A lucerna deseja saber mais sobre agora o processo de comensal enterprise.Criar os seguintes diagramas para esclarecer agora a compreensão com comensal mais facilmente:
Diagrama |
Descreve |
---|---|
Use o diagrama dos casos (UML) Consulte: |
|
Diagrama de atividade (UML) Consulte: |
O fluxo das etapas que ocorrem quando um cliente criar um pedido |
Diagrama de classe (UML) Consulte: |
As entidades de negócios e os termos que 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 nesse cenário. |
Por exemplo, a lucerna cria o seguinte diagrama dos casos de uso para entender as tarefas que são executados no site de comensal agora e que as executa:
Diagrama dos casos de uso de UML
O seguinte diagrama de atividade descreve o fluxo das etapas em que um cliente cria um ordem no site de comensal agora.Nesta versão, os elementos de comentário identificam as funções, e as linhas criam os swimlanes, que organiza as etapas pela função:
Diagrama de atividade de UML
O seguinte diagrama de classe descreve as entidades que participam do processo de ordem:
Diagrama de classe de UML
Descrevendo novos ou requisitos de usuário atualizados
A lucerna agora deseja adicionar funcionalidade ao sistema de comensal de modo que os clientes podem ler e contribuir revisões de restaurante.Atualizar os seguintes diagramas de modo que eles possam descrever e abordar esse novo requisito com o comensal agora:
Diagrama |
Descreve |
---|---|
Use o diagrama dos casos (UML) Consulte: |
Um novo exemplos de uso para “gravar uma revisão de restaurante” |
Diagrama de atividade (UML) Consulte: |
As etapas que ocorrem quando um cliente querer escrever uma revisão de restaurante |
Diagrama de classe (UML) Consulte: |
Os dados que são necessários para armazenar uma revisão |
Por exemplo, o seguinte diagrama dos casos de uso inclui um novo “exemplos de uso de revisão gravar” para representar o novo requisito.É realçado em laranja no diagrama para uma identificação mais fácil:
Diagrama dos casos de uso de UML
O seguinte diagrama de atividade inclui novos elementos em laranja para descrever o fluxo das etapas em novos exemplos de uso:
Diagrama de atividade de 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 pode discutir seus detalhes.Observe que um cliente e um restaurante podem ter mais revisões:
Diagrama de classe de UML
Criando modelos de teste
Ambos os concordam equipes que precisam um conjunto completo de teste para o sistema e seus componentes antes de quaisquer alterações.A lucerna tem uma equipe especializado que execute testes do sistema e de nível por componente.Reutilizam os testes criados pelo comensal agora estrutura e os testes usando os diagramas de UML:
Cada caso de uso são representados por um ou por teste de vários.Os elementos no link de diagrama dos casos de uso a situação de teste itens de trabalho em Team Foundation Server.
Cada fluxo em um diagrama de atividade ou no diagrama de sequência o nível do sistema é associado a um teste pelo menos.A equipe de teste sistematicamente certifique-se de que testa cada caminho possível pelo diagrama de atividade.
Os termos usados para descrever os testes são baseados em termos definidos pelo caso de uso, por classe, e por diagramas de atividade.
Como os requisitos mudarem e os diagramas são atualizados para refletir essas alterações, os testes são atualizados também.Um requisito é considerado atingido somente quando os testes passam.Quando é possível ou prático, os testes está definido e baseados em diagramas de UML antes que começa de implementação.
Consulte:
Identificar alterações ao sistema existente
O comensal agora deve estimar o custo de atender ao novo requisito.Isso depende em parte de quanto essa alteração afetará outras partes do sistema.Para ajudá-los a entender esta, um dos desenvolvedores de comensal agora cria os seguintes elementos gráficos e diagramas de código existente:
Gráfico ou diagrama |
Mostra |
---|---|
Gráfico de dependência Consulte: |
Dependências e outras relacionamentos no código. Por exemplo, o comensal agora pode iniciar examinando gráficos de dependência de assembly para obter uma visão geral sobre assemblies e suas dependências.Podem furar em elementos gráficos para explorar namespaces e classes nesses assemblies. O comensal agora também pode criar gráficos para explorar áreas específicas e outros tipos relações no código.Usam a arquitetura Explorer ou o solution Explorer para ajudá-los a localizar e selecionar as áreas e relacionamentos que os seu interesse. |
Diagrama de sequência código baseado Consulte Visualizar o código gerando diagramas de sequência. |
Sequência de interações entre instâncias. Os diagramas de sequência são gerados as definições do método e são úteis para entender como o código implementa o comportamento do método. |
o diagrama de classe base Consulte Como: Adicionar diagramas de classes a projetos (Designer de classe). |
Classes existentes no código |
Por exemplo, o desenvolvedor usa a arquitetura Explorer para selecionar os namespaces que deseja passa sobre e cria um gráfico de dependência de código.Ajustar seu escopo para focalizar nas áreas que serão afetados pelo novo cenário.Essas áreas são selecionadas e realçadas no gráfico:
Gráfico de dependência de namespace
O desenvolvedor expande namespaces selecionadas para ver os classes, métodos, e relações:
O gráfico expandido de dependência de namespace com o grupo cruzado visível links
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 Visualizando e entendendo o código.
Dica |
---|
Para ver os efeitos de cada alteração como você faz, dos elementos gráficos de dependência de diagramas de sequência regenerados de 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 pode desenhar os seguintes diagramas no Visual Studio para que os detalhes possam ser detectados, gerenciado, e compreendida por ambos equipes:
Diagramas |
Descreve |
---|---|
Diagrama de atividade (UML) Consulte: |
O fluxo das etapas que ocorrem quando o sistema observe que um cliente coloca uma ordem de um restaurante novamente, através do cliente para escrever uma revisão. |
Diagrama de classe (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. |
o diagrama de classe base Consulte Como: Adicionar diagramas de classes 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 comensal agora, e suas interfaces.Essas interfaces definem como os componentes interagem com cada com outros métodos ou serviços que fornecem e consumir. |
Diagrama de sequência (UML) Consulte: |
A sequência de interações entre instâncias. |
Por exemplo, o diagrama a seguir mostra o componente novo componente, que é uma parte do componente do site de comensal agora.O componente de ReviewProcessing trata a funcionalidade de criar revisões e é realçado em laranja:
Diagrama de componente de UML
O seguinte diagrama de sequência mostra a sequência de interações que ocorrem quando o site de comensal agora verifica se o cliente regra de um restaurante antes.Se isso é verdadeiro, então requer que o cliente crie uma revisão, que é enviada para o restaurante e publicado pelo site:
Diagrama de sequência de UML
Mantendo o código consistente com o design
O comensal agora deve certificar-se que as permanece atualizados de código consistentes com o design.Criar os diagramas de camada que descrevem as camadas de funcionalidade no sistema, especifique as dependências permitidas entre elas, e associe artefatos de solução 2 essas camadas.
Diagrama |
Descreve |
---|---|
Diagrama de camada Consulte: |
A arquitetura lógica de código. Um diagrama de camada organiza e mapeia os artefatos em uma solução de Visual Studio para abstract os grupos chamados camadas.Essas camadas identificam as funções, as tarefas, ou funções que esses artefatos executam no sistema. Os diagramas de camada são úteis para descrever o design ativo do sistema e validar o código em desenvolvimento contra esse design. Para criar camadas, arraste itens solution Explorer, gráficos de dependência, ou a arquitetura Explorer.Para desenhar novos camadas, usar a caixa de ferramentas ou clique com o botão direito do mouse na superfície do diagrama. Para exibir dependências existentes, clique com o botão direito do mouse na superfície de diagrama de camada, clique em Gerar dependências.Para especificar pretendesse dependências, desenha 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
Para certificar-se que os conflitos com o design não ocorrem durante o desenvolvimento de código, a validação da camada dos usos de equipes em compilações que são executadas em team foundation build.Também cria uma tarefa personalizado do MSBuild requerer 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 consistem de nós que estão 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 de Modo de Visualização , clique em Caixa de Ferramentas.
Para criar um nó, arrastá-lo da caixa de ferramentas para o diagrama.Certos tipos de nós devem ser arrastados em nós existentes.Por exemplo, em um diagrama componente, uma nova porta deve ser adicionada a um componente existente.
Para criar uma linha ou uma conexão, clique a ferramenta apropriado na caixa de ferramentas, clique no nó de origem, 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 um destino possível, o ponteiro indica se você pode criar uma conexão.
Quando você cria itens em diagramas de UML, você também é adicioná-los para um modelo comum.Os diagramas de UML em um projeto modelando são exibições do modelo.Os itens em um diagrama de camada são parte do projeto modelagem, mesmo que não sejam armazenados no modelo comum.
Para ver o modelo, no menu Arquitetura, aponte para Janelas e clique em Modelo de UML Explorer.
Em alguns casos, você pode arrastar determinados itens de Modelo de UML Explorer para um diagrama de UML.Alguns elementos dentro do mesmo modelo podem ser usados em vários ou diagramas diferentes para mostrar exibições alternativas de arquitetura.Por exemplo, você pode arrastar um componente para outro diagrama componente ou um diagrama de sequência para usar como um ator.
Suporte finais UML 2.1.2 do Visual Studio.Esta visão geral descreve somente os recursos chave de diagramas de UML nesta versão, mas há muitos livros que abordam UML e seu uso em detalhes.
Consulte Desenvolvendo modelos para design de software.
Planejamento de trabalho e de rastreamento
Os diagramas modelando finais do Visual Studio são integrados com o Team Foundation Server para que você possa planejar, gerenciamento, e controlar o trabalho com mais facilidade. O uso de dois equipes modelos para identificar situações de teste e tarefas de desenvolvimento e para estimar seu trabalho.A lucerna cria e links itens de trabalho Team Foundation Server para modelar elementos, como caso de uso ou componentes.Isso ajuda-os para monitorar o andamento e a rastrear seu trabalho de volta para os requisitos de usuários.Isso ajuda-os para certificar-se de que as alterações aumentam a atender aos requisitos.
Como seu trabalho progride, equipes atualizam seus itens de trabalho para refletir a hora que passaram em suas tarefas.Também monitoram e relatórios o status em seu trabalho usando os seguintes recursos do Team Foundation Server:
Relatórios de burndown diários que apresentam se concluirão o trabalho planejado no tempo esperado.Geram outros relatórios semelhantes do Team Foundation Server para acompanhar o progresso de erro.
Uma planilha de iteração que usa o Microsoft Excel para ajudar a equipe para 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 de progresso normal.
Um painel de desenvolvimento que usa o Office Project para manter o team informou sobre informações sobre o projeto importante.
Consulte:
Criar, personalizar e gerenciar relatórios para o Visual Studio ALM
Programar tarefas e atribuir recursos usando o Microsoft Project
Testando, validação, e no código
Como as equipes usa cada tarefa, verifique seu código em controle de versão do team foundation e recebem lembretes do Team Foundation Server, se esquecem.Antes que o Team Foundation Server aceita seus registros, as equipes executar testes de unidade e de camada validação para verificar o código contra as situações de teste e o design.Usam o Team Foundation Server para executar compilações regularmente, automação de testes de unidade, e validação de camada.Isso ajuda a garantir que o código encontra os seguintes critérios:
Funciona.
Não quebra anteriormente trabalhar código.
Não está em conflito com o design.
O comensal agora tem uma grande coleção de testes automatizados, que a lucerna pode reutilizar porque quase todos ainda se aplicam.A lucerna também pode criar nesses testes e adicionar novos para cobrir a nova funcionalidade.Ambos também usam o Visual Studio final para executar testes manual.
Para certificar-se que o código está de acordo com o design, as equipes configurar suas compilações em team foundation build para incluir validação de camada. Se qualquer conflito ocorre, um relatório é gerado com os detalhes.
Consulte:
Atualizando o sistema usando o visualizador e modelar-lo
A lucerna e o comensal agora devem integrar seus sistemas de pagamento.A seguir mostram as seções os diagramas modelando no Visual Studio final ajuda-os a executar esta tarefa:
Entenda os requisitos de usuário: Use diagramas dos casos
Entender o processo enterprise: Diagramas de atividades
Descreve a estrutura do sistema: Diagramas componentes
Descreve as interações: Diagramas de sequência
Visualize o código existente: Gráficos de dependência
Defina um glossário de tipos: Classe diagramas
Descreve a arquitetura lógica: Mergulhe diagramas
Consulte:
Entenda os requisitos de usuário: Use diagramas dos casos
Os diagramas dos casos de uso resumem as atividades que sistemas de suporte e que executam essas atividades.A lucerna usa um diagrama dos casos de uso para saber agora o seguinte sobre o sistema de comensal:
Os clientes criar pedidos.
Os restaurantes recebem pedidos.
O gateway externo do processador de pagamento, que o sistema de pagamento de comensal agora usa para validar pagamentos, está fora do escopo do site.
O diagrama também mostra como alguns dos principais exemplos de uso se dividem em casos menores de uso.A lucerna deseja usar seu próprio sistema de pagamento.Os exemplos realçam do pagamento do processo em uma cor diferente para indicar que requer alterações:
Para o pagamento do processo em uso case o diagrama
Se o tempo de desenvolvimento foram curtas, a equipe pode discutir se deseja permitir que clientes pagar diretamente restaurantes.Para mostrar isso, substituiriam exemplos de uso de pagamento do processo por uma que está fora do limite do sistema de comensal agora.Vinculariam no cliente diretamente para o restaurante, indicando que o comensal agora processaria somente pedidos:
Restaurante de pagamento de Rescoping no diagrama dos casos de uso
Consulte:
Desenhando um diagrama dos casos de uso
Um diagrama dos casos de uso possui os seguintes recursos principais:
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 de comensal agora são atores.
O caso de uso representam interações entre atores e o sistema em desenvolvimento.Podem representar qualquer escala de interação de um único clique do mouse ou mensagem a uma transação estendida sobre muitos dias.
Atoresassociações de link para usar casos.
Os exemplos de uso mais podem incluir o menores, por exemplo, crie a ordem inclui o restaurante.Você pode estender os exemplos de uso, que adicionar meta e etapas para exemplos de uso estendidos, para indicar que os exemplos de uso surgem somente sob certas condições.O caso de uso também podem herdar de cada outros.
Um subsistema representa o sistema de software que é desenvolvido ou um dos seus componentes.É uma grande caixa que contém caso de uso.Um diagrama dos casos de uso do que está dentro ou fora dos limites do subsistema.Para indicar que o usuário deve fazer determinados metas de outras maneiras, desenhar esses casos de uso fora dos limites do subsistema.
Os artefatos vinculam os elementos no diagrama a outros diagramas ou documentos.
Consulte:
Resumo: Pontos de diagramas dos casos de uso
Use a ajuda de diagramas dos casos você visualiza:
As atividades que sistemas de suporte ou não suportam
Pessoas e sistemas externos que executam essas atividades
Os componentes principais do sistema que suportam cada atividade, que você pode representar como os subsistemas se aninhados dentro do sistema pai
Como os exemplos de uso pode dividir em menores ou em variações
Relação a outros diagramas
Diagrama |
Descreve |
---|---|
Diagrama de atividades |
O fluxo das etapas nos exemplos de uso e dessas que executam essas etapas nesse caso de uso. Os nomes dos casos de uso com freqüência espelham as etapas em um diagrama de atividade.Os diagramas de atividade suporte a elementos como decisões, mesclagens, entrada e saída, fluxos simultâneas, 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 classe (UML) |
As entidades ou tipos que participam de exemplos de uso. Consulte: |
Entender o processo enterprise: Diagramas de atividades
Os diagramas de atividade descrevem o fluxo das etapas em um processo enterprise e fornecem uma maneira simples de informar o fluxo de trabalho.Um projeto de desenvolvimento pode ter vários diagramas de atividade.Geralmente, uma atividade aborda todas as ações que resultam de uma ação externa, como ordenar uma refeição, atualizar um menu, ou adicione um novo restaurante ao lidar.Uma atividade também pode descrever os detalhes de uma ação complexa.
A lucerna atualiza o seguinte diagrama de atividade para mostrar que a lucerna processa o pagamento e paga o restaurante.Substitui o sistema de pagamento de comensal agora com o sistema de pagamento de lucerna como destacado:
Substituindo o sistema de pagamento de comensal agora no diagrama de atividades
Ajuda atualizados lucerna e comensal do diagrama visualizam agora onde os ajustes do sistema de pagamento de lucerna no processo enterprise.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 os swimlanes, que organiza as etapas função.
Equipes podem também considerar discutir um artigo alternativo onde o cliente pagasse o restaurante vez após a ordem é entregue.Isso deve criar diferentes requisitos do sistema de software.
Anteriormente, o comensal desenhou agora esses diagramas em um whiteboard ou no Powerpoint.Agora também usam o Visual Studio final para desenhar esses diagramas de modo que ambos equipes pode capturar, compreender, 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 onde o usuário ou o software executar uma tarefa.
Fluxos de controle que mostra o fluxo entre ações.
Nós de decisão que representam ramificações condicionais no fluxo.
Nós de bifurcação que divide únicos fluxos fluxos simultâneas.
Nós final de atividade que mostra fins de atividade.
Embora esses nós são opcionais, é útil incluí-los no diagrama para mostrar onde a atividade termina.
Consulte:
Resumo: Pontos de diagramas de atividades
Ajuda de diagramas de atividade você visualiza e descreve o fluxo de controle e informações entre as ações de um windowsver, o sistema, ou programa.Esta é uma maneira simples e útil de descrever o fluxo de trabalho para se comunicar com outras pessoas.
Relação a outros diagramas
Diagrama |
Descrição |
---|---|
Use o diagrama dos casos |
Resume as atividades que cada ator executa. Consulte: |
Diagrama de componente |
Visualize 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 componentes
Os componentes diagramas descrevem um 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 em qualquer maneira.
Para ajudar agora a lucerna e o comensal para visualizar e discutir as interfaces do sistema e os componentes, diagramas criar os seguintes componentes:
Componentes do sistema de pagamento de comensal agora
Este diagrama mostra tipos diferentes componentes e suas dependências.Por exemplo, comensal do site agora e o sistema de pagamento de lucerna requerem o gateway externo do processador de pagamento validar pagamentos.As setas entre componentes representam as dependências que indicam que componentes requerem funcionalidade de outros componentes.
Para usar o sistema de pagamento de lucerna site, de comensal agora deve ser atualizados para usar o PaymentApproval e PayableInsertion interface no sistema de pagamento de lucerna.
O diagrama a seguir mostra uma configuração específica de componentes para o site de comensal agora.Essa configuração indica que qualquer instância do site consiste de quatro partes:
CustomerProcessing
OrderProcessing
ReviewProcessing
PaymentProcessing
Essas partes são instâncias de tipos componentes especificados e são conectadas como segue:
Componentes dentro do site de comensal agora
O site de comensal agora 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 enviar através das suas interfaces.
Nesta configuração, o componente de 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 componente
Um diagrama componente possui os seguintes recursos principais:
Componentes que representam pedaços separáveis da funcionalidade do sistema.
Como as portas de interface que representam grupos de mensagens ou chamar que implementam os componentes e são usados por outros componentes ou sistemas externos.
As portas necessárias de interface que representam grupos de mensagens ou chame os componentes que envia a outros componentes ou sistemas externos.Esse tipo de porta descreve as operações que um componente espera pelo menos de outros componentes ou sistemas externos.
As partes são membros de componentes e são normalmente instâncias de outros componentes.Uma parte é uma parte de design interno do componente pai.
As dependências que indicam componentes requerem funcionalidade de outros componentes.
As delegações que indicam as partes de um identificador componente as mensagens de executar ou recebido pelo componente pai.
Consulte:
Resumo: Pontos diagramas de componentes
Ajuda que componente de diagramas você visualiza:
O sistema como uma coleção de partes separáveis independentemente do seu idioma ou estilo de implementação.
Componentes com as interfaces bem definido, tornando design compreender e atualizar quando os requisitos mudarem.
Relação a outros diagramas
Diagrama |
Descrição |
---|---|
Gráfico de dependência |
Visualize a organização e relacionamentos no código existente. Para identificar candidatos para componentes, crie itens de dependência de um gráfico e de grupo por sua função no sistema. Consulte: |
Diagrama de sequência |
Visualize a sequência de interações entre componentes ou as partes de um componente. Para criar uma corda de salvamento em um diagrama de sequência de um componente, clique com o botão direito do mouse o componente, e clique em Criar Linha de Vida. Consulte: |
Diagrama de classe (UML) |
Defina as interfaces fornecidas ou nas portas necessárias e as classes que implementam a funcionalidade dos componentes. Consulte: |
Diagrama de camada |
Descreve a arquitetura lógica do sistema como ele se relaciona a componentes.Use a validação de camada para certificar-se de que o código consistentes com o design. Consulte: |
Diagrama de atividades |
Visualize processamento interno que componentes executam em resposta às mensagens de entrada. Consulte: |
Visualize o código existente: Gráficos de dependência
Gráficos de dependência mostram a organização e relacionamentos atual no código.Os itens são representados por nós no gráfico, e 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 estranhos.
Entenda 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 de melhoria.
Por exemplo, o comensal agora deve estimar o custo de atualizar o componente de PaymentProcessing.Isso depende em parte de quanto essa alteração afetará outras partes do sistema.Para ajudá-los a entender isso, um dos desenvolvedores de comensal agora gerar gráficos de dependência de código e ajusta o foco de escopo em áreas que podem ser afetados pela alteração.
O gráfico a seguir mostra as dependências entre a classe de PaymentProcessing e outras partes do sistema de comensal agora, que aparecem selecionadas:
Gráfico de dependência para comensal do sistema de pagamento agora
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 da classe de PaymentProcessing e as suas dependências
Gera 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 de lucerna também pode exigir que o trabalho agora interagir com as outras partes do comensal:
Gráfico de dependência para o sistema de pagamento de lucerna
Ambas as equipes funcionam juntos para determinar as alterações que são necessárias para integrar os dois sistemas.Decidir refatorar qualquer de código para que é mais fácil atualizar.A classe de PaymentApprover se para o espaço de DinnerNow.Business e exigir-se-á alguns novos métodos.O comensal classe agora que as transações de forma terão seu próprio namespace.Equipes criar e usar itens de trabalho para planejar, organizar, e acompanhar seu trabalho.Vinculam os itens de trabalho para modelar elementos onde é útil.
Após reorganizado o código, as equipes geram um novo elemento gráfico de dependência para ver a estrutura e relacionamentos atualizados:
Gráfico de dependência com código reorganizado
Este gráfico que mostra a classe de PaymentApprover agora está no espaço de DinnerNow.Business e tem alguns novos métodos.As classes de transação de comensal agora agora tem seu próprio namespace de PaymentSystem, que facilita manipular esse código mais tarde.
Criando um gráfico de dependência
Para obter uma visão geral rápido de origem, siga estas etapas para gerar um gráfico de dependência:
No menu de Arquitetura , aponte para Gerar o gráfico de dependência, e clique Para a solução.
Para obter uma visão geral rápido do código compilado, crie um elemento gráfico em branco de dependência em seguida, arraste arquivos de assembly ou arquivos binários para o gráfico ocorrem.
Consulte Visualizar dependências de código em gráficos de dependência.
Para explorar itens específicos de código ou solução, solution Explorer de uso ou arquitetura Explorer para selecionar 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 Visualizar dependências de código em gráficos de dependência e Localizar o código com o Explorer de Arquitetura.
Para ajudá-lo a explorar o gráfico, reordenar o layout para que atende aos tipos das tarefas que você deseja executar.
Por exemplo, para visualizar 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 fora itens ou personalizar sua aparência.Consulte Editar e personalizar gráficos de dependência.
Resumo: Pontos de elementos gráficos de dependência
Ajuda gráficos de dependência você:
Aprender sobre a organização e relacionamentos no código existente.
Identifica as áreas que podem ser afetadas por uma alteração proposta.
Localizar áreas de complexidade, padrões, as camadas, ou outras áreas que você pode melhorar para facilitar o código manter, alterar, e reutilização.
Relação a 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 consistentes com o design. Para ajudá-lo a identificar camadas existentes ou camadas pretendidas, para criar um gráfico de dependência e um grupo itens relacionados.Para criar um diagrama de camada, arraste itens de gráfico ou de Arquitetura Explorer. Consulte: |
Diagrama de componente |
Componentes, suas interfaces, e suas relações. Para ajudá-lo a identificar componentes, crie itens de gráfico de dependência de grupo por sua função no sistema. Consulte: |
Diagrama de classe (UML) |
Suas classes, atributos e operações, e suas relações. Para ajudá-lo a identificar esses elementos, crie um documento de gráfico que mostra esses elementos. Consulte: |
Ordena o diagrama (código baseado) |
Classes existentes no código. Para visualizar e alterar uma classe existente no código, designer de classe de uso. Consulte Como: Adicionar diagramas de classes 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 digite.Por exemplo, podem variar de mensagens individuais a transações estendidos e podem ser chamadas de função ou mensagens de serviço Web.
Para ajudar agora a lucerna e o comensal a descrever e discutir as etapas no pagamento do processo para usar caso, criam o seguinte diagrama de sequência de diagrama componente.As cordas de salvamento espelham o componente do site de comensal agora e as partes.As mensagens que aparecem entre cordas de salvamento seguem as conexões em diagramas componentes:
Diagrama de sequência para exemplos de uso de pagamento do processo
O diagrama de sequência mostra que quando o cliente cria uma ordem, o site de comensal agora 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 pagamento valida o pagamento.Somente em controla o retorno para o site de comensal agora.
A lucerna deve estimar o custo de atualizar seu sistema de pagamento para integrar agora com o sistema de comensal.Para ajudá-los a entender isso, um de seus desenvolvedores gera diagramas de sequência de código para visualizar as interações existentes.
Consulte:
Desenhando um diagrama de sequência
Um diagrama de sequência possui os seguintes recursos principais:
As cordas de salvamento verticais representam atores ou instâncias de objetos de software.
Para adicionar um símbolo de ator, que indica um participante está fora do sistema em desenvolvimento, clique na corda de salvamento.Na janela de Propriedades , defina a AtorVerdadeiro.Se a janela de Propriedades não estiver aberta, pressione F4.
As mensagens horizontais representam chamadas de método, mensagens de serviço Web, ou alguma outra comunicação.As ocorrências de execução retângulos são protegidos vertical que aparecem em cordas de salvamento e representam períodos durante que recebe o processo de objetos chama.
Durante uma mensagem síncrona, o objeto remetente espera o controle <<return>> como em uma chamada de função normal.Durante uma mensagem assíncrono , o remetente pode continuar imediatamente.
Use mensagens <<create>> para indicar a construção de objetos por outros objetos.Deve ser a primeira mensagem enviada ao objeto.
Consulte:
Resumo: Pontos de diagramas de sequência
Ajuda de diagramas de sequência você visualiza:
O fluxo de controle que transfere entre atores ou objetos durante a execução de um uso encaixotam.
A implementação de uma chamada ou uma mensagem de método.
Relação a outros diagramas
Diagrama |
Descrição |
---|---|
Diagrama de classe (UML) |
Defina as classes que as cordas de salvamento e representam os parâmetros e retornar valores que são usados nas mensagens enviadas entre cordas de salvamento. Para criar uma classe de um corda de salvamento, clique com o botão direito do mouse na corda de salvamento, clique em Criar Classe ou Criar Interface.Para criar uma corda de salvamento de um tipo em um diagrama de classe, clique com o botão direito do mouse no tipo, e clique em Criar Linha de Vida. Consulte: |
Diagrama de componente |
Descreve os componentes que as cordas de salvamento representam e interfaces que fornecem e consumir o comportamento representado por mensagens. Para criar uma corda de salvamento de um diagrama componente, clique com o botão direito do mouse o componente, e clique em Criar Linha de Vida. Consulte: |
Use o diagrama dos casos |
Resume as interações entre usuários e componentes em um diagrama de sequência porque os exemplos de uso, que representam o objetivo de um usuário. Consulte: |
Defina um glossário de tipos: Classe diagramas
Os diagramas de classe definem as entidades, os termos, ou os conceitos que participam do sistema e suas relações em um com o outro.Por exemplo, você pode usar esses diagramas durante o desenvolvimento para descrever os atributos e as operações para cada classe, independentemente do seu idioma de implementação ou estilo.
Para ajudar a lucerna a descrever e discutir as entidades que participam de exemplos de uso de pagamento de processo, desenha o seguinte diagrama de classe:
Entidades de pagamento do processo em um diagrama de classe
Este diagrama mostra que um cliente pode ter vários pedidos e maneiras diferentes pagar por pedidos.BankAccount e CreditCard ambos herdam de pagamento.
Durante o desenvolvimento, usa de lucerna o seguinte diagrama de classe descrever e discutir os detalhes de cada classe:
Detalhes de pagamento do processo no diagrama de classe
Consulte:
Desenhando um diagrama de classe
Um diagrama de classe possui os seguintes recursos principais:
Tipos como classes, interfaces, e enumerações:
Uma classe é 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 mesmo atores.
As 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 uma relação entre dois classificadores.
Uma agregação é uma associação que indica uma propriedade compartilhado entre classificadores.
Uma configuração é uma associação que indica uma relação de inteiro- parte entre classificadores.
Para mostrar agregados ou composições, defina a propriedade de Agregação em uma associação.Compartilhado mostra agregados e mostra de Composto 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 a 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 representado como um pirulito.
Pacotes são grupos de classificadores, associações, cordas de salvamento, componentes, e outros pacotes.As relaçõesde 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 de diagramas de classe
Ajuda de diagramas de classe você define:
Um glossário de termos comum para usar ao abordar as necessidades de usuários e as entidades que participem no sistema.Consulte Requisitos do usuário de modelagem..
Tipos que é usado pela partes do sistema, como componentes, independentemente da sua implementação.Consulte A arquitetura de um sistema de Software de modelagem..
Relações, como dependências, entre tipos.Por exemplo, você pode mostrar que um tipo pode ser associado com várias instâncias de um outro tipo.
Relação a outros diagramas
Diagrama |
Descrição |
---|---|
Use o diagrama dos casos |
Defina os tipos que são usados para descrever meta e etapas no caso de uso. Consulte: |
Diagrama de atividades |
Defina os tipos de dados que passam pelos nós de objeto, de pinos de entrada, de pinos de saída, e os nós de parâmetro de atividade. Consulte: |
Diagrama de componente |
Descreve componentes, suas interfaces, e suas relações.Uma classe pode também descrever um componente completo. Consulte: |
Diagrama de camada |
Defina a arquitetura lógica do sistema como ele se relaciona as classes. Use a validação de camada para certificar-se de que o código consistentes com o design. Consulte: |
Diagrama de sequência |
Defina os tipos de cordas de salvamento e as operações, os parâmetros, e valores de retorno para todas as mensagens que a corda de salvamento pode receber. Para criar uma corda de salvamento de um tipo em um diagrama de classe, clique com o botão direito do mouse no tipo, e clique em Criar Linha de Vida. Consulte: |
Gráfico de dependência |
Visualize a organização e relacionamentos no código existente. Para identificar classes, as relações, e seus métodos, crie um documento de gráfico que mostra esses elementos. Consulte: |
Descreve a arquitetura lógica: Mergulhe diagramas
Os diagramas de camada 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 descreve as funções ou as tarefas que os artefatos executam no sistema.Você também pode incluir validação de camada na compilação e observações operações para certificar-se de que o código consistentes com seu design.
Para manter o código consistente com o design, o comensal agora e uso de lucerna o seguinte diagrama de camada validar seu código como evolui:
Mergulhe o diagrama para o comensal agora integrado com lucerna
As camadas neste diagrama links para a comensal correspondente artefatos de solução agora e de lucerna.Por exemplo, a camada comercial links para o espaço de DinnerNow.Business e a seus membros, que incluem agora a classe de PaymentApprover.A camada de acesso a recursos links para o espaço de DinnerNow.Data.As setas, ou dependências, que especificam somente a camada comercial pode usar a funcionalidade na camada de acesso a recursos.Porque as equipes atualizar seu código, a camada de validação é executada regularmente para capturar conflitos como ocorrem e para ajudar equipes aos resolver rapidamente.
Equipes funcionam juntos para integrar e testar incremental os dois sistemas.Primeiro certificam-se de que PaymentApprover e o restante de comensal funcionam agora um com o outro com êxito antes que manipula o PaymentProcessing.
O gráfico a seguir de dependência mostra os novos chamadas entre o comensal agora e PaymentApprover:
Gráfico de dependência atualizados com chamadas de método
Depois confirmando que o sistema funciona como esperado, o comensal para agora para fora o código de PaymentProcessing.Os relatórios de validação da camada estão vazios, e o gráfico resultante de dependência mostra que não mais dependência de PaymentProcessing existe:
Gráfico de dependência sem PaymentProcessing
Consulte:
Desenhando um diagrama de camada
Um diagrama de camada possui os seguintes recursos principais:
As camadas descrevem grupos lógicos de artefatos.
Um link é uma associação entre uma camada e um produto.
Para criar camadas de artefatos, arraste itens solution Explorer, gráficos de dependência, ou a arquitetura Explorer.Para desenhar novos camadas e então links para artefatos, usar a caixa de ferramentas ou clique com o botão direito do mouse na superfície do diagrama para criar as camadas, e para arrastar itens em 2 essas camadas.
O número em uma camada mostra o número de artefatos que são associados à camada.Esses artefatos podem ser namespaces, projetos, classes, métodos, e assim por diante.Quando você interpreta o número de artefatos em uma camada, lembre-se do seguinte:
Se uma camada vincula a um produto que contém outros artefatos, mas a camada não vai diretamente outros artefatos, então o número inclui somente o produto associado.No entanto, os outros artefatos são incluídos para análise durante a validação de camada.
Por exemplo, se uma camada é vinculada a uma única namespace, então o número de artefatos associados é 1, mesmo se o namespace contém classes.Se a camada também possui links para cada classe no namespace, então o número incluirá as classes vinculadas.
Se uma camada contém outras camadas que estão vinculadas a artefatos, então a camada recipiente é vinculada também 2 os artefatos, mesmo que o número na camada contêiner não inclui os artefatos.
Para ver os artefatos que são associados a uma camada, clique com o botão direito do mouse na camada, clique em Exibir Links para abrir Mergulhe Explorer.
Uma dependência indica que uma camada pode usar a funcionalidade em outra camada, mas não vice-versa.Uma dependência bidirecional indica que uma camada pode usar a funcionalidade em outra camada, e vice-versa.
Para exibir dependências existentes no diagrama de camada, clique com o botão direito do mouse na superfície do diagrama, clique em Gerar dependências.Para descrever dependências pretendesse, desenha novos.
Consulte:
Resumo: Pontos de diagramas de camada
Ajuda de diagramas de camada você:
Descreve a arquitetura lógica de um sistema de acordo com a funcionalidade dos artefatos.
Certifique-se que o código está de acordo com desenvolvimento no design especificado.
Relação a outros diagramas
Diagrama |
Descrição |
---|---|
Gráfico de dependência |
Visualize a organização e relacionamentos no código existente. Para criar camadas, gerar um gráfico de dependência, e então itens de grupo no elemento gráfico como camadas em potencial.Arraste os grupos de gráfico ao diagrama de camada. Consulte: |
Diagrama de componente |
Descreve componentes, suas interfaces, e suas relações. Para visualizar camadas, crie um diagrama componente que descreve a funcionalidade de diferentes componentes no sistema. Consulte: |
Recursos externos
Categoria |
Links |
---|---|
Fóruns |
|
Blogs |
|
Artigos técnicos e diários |
O journal de arquitetura - problema 23: A modelagem e processos de arquitetura |
Outros sites |
Consulte também
Conceitos
Visualizando e entendendo o código
Desenvolvendo modelos para design de software
Usando modelos dentro do processo de desenvolvimento
Usar os modelos no desenvolvimento ágil