Usando modelos dentro do processo de desenvolvimento

Artigo
02/25/2013

Em Visual Studio Ultimate, você pode usar um modelo para ajudar você a entender e modificar um sistema, um aplicativo, ou componente.Um modelo pode ajudar a visualizar o mundo no seu sistema funciona, para as necessidades de usuários, define a arquitetura do seu sistema, analisa o código, e garante que seu código atende aos requisitos.

Consulte Exibição do canal 9: Aumenta a arquitetura com a modelagem.

Como usar modelos

Os modelos podem ajudá-lo em várias maneiras:

Desenhando modelagem de ajuda diagramas você para os conceitos envolvidos nos requisitos, na arquitetura, e o design de alto nível.Para obter mais informações, consulte Requisitos do usuário de modelagem..
Trabalhando com modelos pode ajudar a expor inconsistências nos requisitos.
Se comunicar com ajuda modelos você comunica conceitos importantes menos ambìgua do que com o de linguagem natural.Para obter mais informações, consulte A arquitetura de um sistema de Software de modelagem..
Às vezes você pode usar modelos para gerar código ou outros artefatos como esquemas ou documentos de banco de dados.Por exemplo, os componentes modelagem de Visual Studio Ultimate são gerados de um modelo.Para obter mais informações, consulte Gerar e configurar seu aplicativo de modelos.

Você pode usar modelos em uma variedade de processos de desenvolvimento, extremo a cerimónia alta.

Usar modelos para reduzir a ambiguidade

A modelagem o idioma é ambíguo menos do que de linguagem natural, e é criado para expressar as exibições necessárias normalmente durante a programação de software.

Se o projeto tiver uma equipe pequena que segue práticas ágeis, você pode usar modelos para ajudá-lo a esclarecer as histórias de usuário.Em discussões com o cliente sobre as suas necessidades, criar um modelo pode gerar perguntas úteis muito mais rápido, e através de uma área maior do produto, do ponto de gravação ou código de protótipo.

Se seu projeto é grande e inclui equipes em diferentes partes de globo, você pode usar modelos para ajudar a comunicar muito mais efetivamente os requisitos e a arquitetura de que você pode em texto sem formatação.

Em ambos os casos criar um modelo quase sempre resulta em uma redução significativa em inconsistências e em ambiguidades.Os participantes diferentes geralmente têm compreensões diferentes do business em que o sistema funciona, e os diferentes desenvolvedores geralmente têm compreensões diferentes de como o sistema funciona.Usar um modelo como o foco de uma discussão geralmente apresentado essas diferenças.Para obter mais informações sobre como usar um modelo para reduzir inconsistências, consulte Requisitos do usuário de modelagem..

Use modelos com outros artefatos

Um modelo não é por si só uma especificação de requisitos ou uma arquitetura.É uma ferramenta para expressar alguns aspectos dessas coisas mais claramente, mas não todos os conceitos necessários durante o design de software podem ser expressos.Os modelos portanto devem ser usados em conjunto com outros meios de comunicação, como páginas ou parágrafos de OneNote, documentos Microsoft Office, itens de trabalho em Team Foundation, ou notas autoadesivas em parede de sala do projeto.Independentemente do último item, todos esses tipos de objeto podem ser associados a partes dos elementos do modelo.

Outros aspectos da especificação que são normalmente usados juntos com modelos incluem o seguinte.Dependendo da escala e estilo de seu projeto, você pode usar vários aspectos desses ou não usar qualquer um dos:

Artigos de usuário.Um artigo de usuário é uma breve descrição, discutida com os usuários e outros participantes, um aspecto do comportamento do sistema que será entregado em uma de iterações do projeto.Um usuário que típico a artigo “inicia o cliente poderá….” Um artigo do usuário pode introduzir um grupo de caso de uso, ou pode definir extensões dos casos de uso que foram desenvolvidos anteriormente.Definir ou estender o uso encaixotam ajuda tornam o esclarecedor de artigo de usuário.
Solicitações de alteração.Uma solicitação de alteração em um projeto mais formal é muito semelhante a um artigo de usuário em um projeto agile.A abordagem agile trata todos os requisitos como alterações ao que foi desenvolvido em iterações anteriores.
Use a descrição dos casos.Os exemplos de uso representam uma maneira na qual um usuário interage com o sistema para obter um objetivo específico.Uma descrição completa inclui o objetivo, sequências de main e alternativo de eventos, e resultados excepcionais.Ajuda de um diagrama dos casos de uso resumem e fornece uma visão geral dos exemplos de uso.
Cenários.Um cenário é bastante uma descrição detalhada de uma sequência de eventos que mostram como o sistema, os usuários e outros sistemas funcionam juntos para fornecer o valor para os participantes.Pode tomar a forma de uma apresentação de slides de interface do usuário ou de um protótipo de interface do usuário.Pode descrever um caso de uso ou uma sequência de caso de uso.
Glossário.O glossário dos requisitos de projeto descreve a palavra com que os clientes abordam o mundo.A interface do usuário e modelos de requisitos também devem usar esses termos.Um diagrama de classe pode ajudar a esclarecer as relações entre a maioria desses termos.Criar os diagramas e o glossário reduz não apenas enganos entre usuários e desenvolvedores, mas também expõe quase sempre enganos entre participantes comerciais diferentes.
Regras de negócios.Várias regras de negócios podem ser expressas como restrições invariável em associações e atributos dos requisitos de classe do modelo, e como diagramas de restrições em sequência.
Design de alto nível.Descreve as principais partes e como cabem juntos.Os diagramas do componente, e a sequência de interface são maior parte de um design de alto nível.
Padrões de design.Descreve as regras de design que são compartilhados entre as partes diferentes do sistema.
Especificações de teste.Scripts de teste e os projetos para o código de teste podem fazer bom uso de diagramas de atividade de sequência e descrever sequências de etapas de teste.Os testes do sistema devem ser expressos em termos dos requisitos de padrão de modo que eles possam facilmente ser modificada quando os requisitos mudarem.
Plano de projeto.O plano de projeto ou a reserva definem quando cada recurso será entregue.Você pode definir cada recurso indicando que uso encaixota e regras comerciais ele implementam ou estendem.Ou você pode consultar os exemplos de uso e regras comerciais diretamente no plano, ou você pode definir um conjunto de recursos em um documento separado, e usa os títulos de recurso no plano.

Use modelos no planejamento de iteração

Embora todos os projetos são diferentes em suas escala e organização, um projeto típico é planejado como uma série de iterações entre de duas e seis semanas.É importante planejar iterações suficiente para permitir que os comentários de iterações adiantadas sejam usados para ajustar o escopo e os planos para uma iterações posteriores.

Você pode localizar as sugestões úteis ajudá-lo a executar os benefícios de modelagem em um projeto iterativo.

Aponte o foco como abordagens de cada iteração

Como cada iteração aproxima-se, use modelos para ajudar a definir o que deve ter entregue no final da iteração.

Não modelar tudo em detalhes em iterações adiantadas.Na primeira iteração, crie um diagrama de classe para os itens principais no glossário de usuário, desenhar um diagrama de chave exemplos de uso, e desenhar um diagrama dos componentes principais.Não descreve qualquer um in fine detalhes, porque o detalhe se alterarão posteriormente no projeto.Use os termos definidos nesse modelo para criar uma lista de recursos ou de artigos chave do usuário.Atribuir os recursos em iterações para equilibrar aproximadamente a carga de trabalho estimada em todo o projeto.Essas atribuições serão alterados posteriormente no projeto.
Tente implementar versões simplificadas de todos os exemplos os mais importantes de uso em uma iteração inicial.Estender os casos de uso em uma iterações posteriores.Essa abordagem ajuda a reduzir o risco de descobrir uma falha dos requisitos ou a arquitetura muito tarde no projeto fazer nada sobre ele.
Próximo ao final da cada iteração, mantenha uma oficina de requisitos para definir detalhadamente os requisitos ou as histórias de usuário que serão desenvolvidos na próxima iteração.Convidar os usuários e os participantes de negócio que podem decidir prioridades, bem como os desenvolvedores e testadores do sistema.Allow três horas definir requisitos para uma iteração de 2 semanas.
O objetivo de oficina é para todos concorde o que será feito para o final da próxima iteração.O uso de padrões como uma das ferramentas para ajudar a esclarecer os requisitos.A saída de oficina são uma reserva de iteração: ou seja, uma lista de desenvolvimento tarefas em Team Foundation e em pacotes de teste em Microsoft Test Manager.
Em oficina os requisitos, discutir o design somente até que você precisa determinar avaliações para as tarefas de desenvolvimento.Se não, manter a discussão o comportamento do sistema que os usuários podem apresentar diretamente.Manter o modelo dos requisitos de separar-se do modelo de arquitetura.
Os participantes não técnicos geralmente não têm nenhum problema que compreende diagramas de UML, com alguma orientação de você.

Modelo de link para trabalhar itens

Após a oficina os requisitos, elaboram os detalhes dos requisitos de padrão, e links o modelo as tarefas de desenvolvimento.Você pode fazer isso vinculando itens de trabalho em Team Foundation elementos no modelo.Para saber como fazer isso, consulte Vincular elementos de modelo e itens de trabalho.

Você pode vincular qualquer elemento para trabalhar itens, mas os elementos os mais úteis são:

Use casos.Você pode vincular um exemplos de uso as tarefas de desenvolvimento que os implementarão.
Usar as extensões dos casos.Se apenas um aspecto dos exemplos de uso será implementado em uma iteração, você pode a separa nos exemplos de base de uso juntamente com um ou mais extensões.As extensões são casos de uso associados aos casos de base “com” estendem a relação.Para obter mais informações sobre a extensão dos casos de uso, consulte Diagramas de caso de uso UML: referência.
Comentários que descrevem as regras de negócio ou qualidade de requisitos de serviço.Para obter mais informações, consulte Requisitos do usuário de modelagem..

Modelo de link para teste

Use os requisitos modelos para guiar o design de teste de aceitação.Criar esses testes simultaneamente com o trabalho de desenvolvimento.

Para saber mais sobre essa técnica, consulte O desenvolvimento de testes de um modelo.

Estimar trabalho restante

Um modelo de requisitos pode ajudar a estimar o tamanho total de projeto com relação ao tamanho de cada iteração.Avaliar o número e complexidade de exemplos e as classes de uso pode ajudar a estimar o trabalho de desenvolvimento que será necessário.Quando você concluiu as primeiras iterações, uma comparação entre os requisitos abordados e os requisitos cobrir ainda pode dar uma medida de aproximada custo e do escopo do restante do projeto.

Próximo ao final da cada iteração, revise a atribuição de requisitos para iterações futuras.Pode ser útil representar o estado do seu software no final da cada iteração como um subsistema em um diagrama dos casos de uso.Em suas discussões, você pode mover caso de uso e usar extensões dos casos de um desses subsistemas para outro.

Níveis de abstração

Modelos têm um intervalo de abstração com relação ao software.Os modelos os mais concretos representam diretamente o código de programa, e os modelos os mais abstratos representam os conceitos de negócios que podem ou não podem ser representados no código.

Um modelo pode ser exibido com vários tipos de diagramas.Para obter informações sobre modelos e de diagramas, consulte Desenvolvendo modelos para design de software.

Os diferentes tipos de diagrama são úteis para descrever o design em diferentes níveis de abstração.Muitos dos tipos de diagrama são úteis para mais de um nível.Esta tabela mostra como cada tipo de diagrama pode ser usado.

Nível de design	Tipos de diagrama
Processo enterprise Entender o contexto no qual seu sistema será usado ajuda você a entender o que a necessidade de usuários de ela.	Os diagramas de atividade descrevem o fluxo de trabalho entre pessoas e sistemas para obter metas de negócios. Os conceituais diagramas de classe descrevem os conceitos de negócios usados dentro do processo enterprise.
Requisitos de usuário Definição de que a necessidade de usuários do seu sistema.	Os diagramas dos casos de uso resumem as interações que os usuários e outros sistemas externos têm com o sistema que você está desenvolvendo.Você pode anexar outros documentos para cada caso de uso para descrevê-los em detalhes. Os diagramas de classe de UML descrevem os tipos de informação que os usuários e se comunicam o sistema sobre. As regras comerciais e a qualidade de requisitos de serviço podem ser descritas em documentos separados.
Design de alto nível A estrutura geral do sistema: os componentes essenciais e como se acoplam juntos.	Os diagramas de camada descrevem como o sistema é estruturado em partes interdependentes.Você pode validar o código de programa contra diagramas de camada para garantir que adira a arquitetura. Os componentes diagramas mostram as interfaces de partes, especificando as mensagens e serviços que são fornecidos e necessários para cada componente. Os diagramas de sequência mostram como os componentes se comunicam para implementar cada caso de uso. Os diagramas de classe de UML descrevem as interfaces de componentes e os tipos de dados passados entre os componentes.
Padrões de design Convenções e métodos de resolver problemas de design que são usados em todas as partes de design	Os diagramas de classe de UML descrevem as estruturas de um padrão Os diagramas da sequência ou de atividade mostram as interações e os algoritmos
Análise de código Vários tipos de diagrama podem ser geradas de código.	Os diagramas de sequência mostram a interação entre objetos no código. Os diagramas de camada mostram as dependências entre classes.O código atualizado pode ser validado contra um diagrama de camada. Os diagramas de classe mostram as classes no código.

Recursos externos

Categoria	Links
Vídeos
Fóruns	Visualização do Visual Studio e ferramentas modelar SDK de visualização e modelagem do Visual Studio (ferramentas de DSL)
Blogs	Visual Studio ALM + blog do Team Foundation Server
Artigos técnicos e diários	O journal de arquitetura - problema 23: A modelagem e processos de arquitetura
Outros sites	Centro da arquitetura do MSDN Orientação sobre as ferramentas de arquitetura de Visual Studio