Usar modelos em seu processo de desenvolvimento

No Visual Studio, você pode usar um modelo para ajudá-lo a entender e alterar um sistema, aplicativo ou componente. Um modelo pode ajudá-lo a visualizar o mundo no qual seu sistema funciona, esclarecer as necessidades dos usuários, definir a arquitetura do sistema, analisar o código e garantir que seu código atenda aos requisitos.

Para ver quais versões do Visual Studio dão suporte a cada tipo de modelo, consulte o suporte à versão para ferramentas de arquitetura e modelagem.

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

• Desenhar diagramas de modelagem ajuda você a esclarecer os conceitos envolvidos em requisitos, arquitetura e design de alto nível. Para obter mais informações, consulte os requisitos de usuário do modelo.

• Trabalhar com modelos pode ajudá-lo a expor inconsistências nos requisitos.

• A comunicação com modelos ajuda você a comunicar conceitos importantes de forma menos ambígua do que com a linguagem natural. Para obter mais informações, consulte Modelar a arquitetura do aplicativo.

• Às vezes, você pode usar modelos para gerar código ou outros artefatos, como esquemas de banco de dados ou documentos. Por exemplo, os componentes de modelagem do Visual Studio são gerados a partir de um modelo. Para obter mais informações, consulte Gerar e configurar seu aplicativo a partir de modelos.

Você pode usar modelos em uma ampla variedade de processos, do ágil extremo ao alto nível de cerimônia.

Usar modelos para reduzir a ambiguidade

A linguagem de modelagem é menos ambígua do que a linguagem natural e foi projetada para expressar as ideias normalmente necessárias durante o desenvolvimento de software.

Se o projeto tiver uma pequena equipe seguindo práticas ágeis, você poderá usar modelos para ajudar a esclarecer histórias de usuários. Em discussões com o cliente sobre suas necessidades, a criação de um modelo pode gerar perguntas úteis muito mais rapidamente e em uma área mais ampla do produto, do que escrever código de pico ou protótipo.

Se o projeto for grande e incluir equipes em diferentes partes do globo, você poderá usar modelos para ajudar a comunicar os requisitos e a arquitetura de forma muito mais eficaz do que em texto sem formatação.

Em ambos os casos, a criação de um modelo quase sempre resulta em uma redução significativa de inconsistências e ambiguidades. Os diferentes stakeholders frequentemente têm compreensões diferentes do mundo dos negócios no qual o sistema funciona e desenvolvedores diferentes frequentemente têm compreensões diferentes de como o sistema funciona. Usar um modelo como foco de uma discussão geralmente expõe essas diferenças. Para obter mais informações sobre como usar um modelo para reduzir inconsistências, consulte os requisitos de usuário do Modelo.

Utilizar 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 com mais clareza, mas nem todos os conceitos necessários durante o design de software podem ser expressos. Portanto, os modelos devem ser usados junto com outros meios de comunicação, como páginas ou parágrafos do OneNote, documentos do Microsoft Office, itens de trabalho no Team Foundation ou anotações autoadesivas na parede da sala do projeto. Além do último item, todos esses tipos de objeto podem ser vinculados a partes de elementos do modelo.

Outros aspectos de especificação normalmente usados junto com modelos incluem o seguinte. Dependendo da escala e do estilo do seu projeto, você pode usar vários desses aspectos ou não usar nenhum:

• Histórias de usuário. Uma história de usuário é uma breve descrição, discutida com usuários e outros stakeholders, de um aspecto do comportamento do sistema que será entregue em uma das iterações do projeto. Uma história de usuário típica começa "O cliente será capaz de...." Uma história de usuário pode introduzir um grupo de casos de uso ou definir extensões de casos de uso que foram desenvolvidos anteriormente. Definir ou estender os casos de uso ajuda a tornar a história do usuário mais clara.

• Alterar Solicitações. Uma solicitação de alteração em um projeto mais formal é muito semelhante a uma história de usuário em um projeto agile. A abordagem ágil trata todos os requisitos como alterações no que foi desenvolvido em iterações anteriores.

• Use a descrição do caso. Um caso de uso representa uma maneira em que um usuário interage com o sistema para atingir uma meta específica. Uma descrição completa inclui a meta, as sequências principais e alternativas de eventos e resultados excepcionais. Um diagrama de caso de uso ajuda a resumir e fornecer uma visão geral dos casos de uso.

• Cenários. Um cenário é uma descrição bastante detalhada de uma sequência de eventos mostrando como o sistema, os usuários e outros sistemas trabalham juntos para fornecer valor aos stakeholders. Ele pode assumir a forma de uma apresentação de slides da interface do usuário ou um protótipo da interface do usuário. Ele pode descrever um caso de uso ou uma sequência de casos de uso.

• Glossário. O glossário de requisitos do projeto descreve as palavras com as quais os clientes discutem seu mundo. Os modelos de interface e requisitos do usuário 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 não apenas reduz mal-entendidos entre usuários e desenvolvedores, mas também quase sempre expõe mal-entendidos entre diferentes stakeholders de negócios.

• Regras de negócios. Muitas regras de negócios podem ser expressas como restrições invariáveis nas associações e atributos no modelo de classe de requisitos e como restrições em diagramas de sequência.

• Design de alto nível. Descreve as partes principais e como elas se encaixam. Diagramas de componente, sequência e interface são uma parte principal de um design de alto nível.

• Padrões de design. Descreva as regras de design que são compartilhadas entre as diferentes partes do sistema.

• Especificações de teste. Os scripts de teste e os designs do código de teste podem fazer um bom uso de diagramas de atividade e sequência para descrever sequências de etapas de teste. Os testes do sistema devem ser expressos em termos do modelo de requisitos para que possam ser facilmente alterados quando os requisitos forem alterados.

• Plano do projeto. O plano de projeto ou backlog define quando cada recurso será entregue. Você pode definir cada recurso informando quais casos de uso e regras de negócios ele implementa ou estende. Você pode consultar os casos de uso e as regras de negócios diretamente no plano ou pode definir um conjunto de recursos em um documento separado e usar os títulos de recurso no plano.

Usar modelos no planejamento de iteração

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

Você pode achar as sugestões a seguir úteis para ajudar a perceber os benefícios da modelagem em um projeto iterativo.

Afiar o foco à medida que cada iteração se aproxima

À medida que cada iteração se aproxima, use modelos para ajudar a definir o que será entregue no final da iteração.

• Não modele tudo em detalhes nas iterações iniciais. Na primeira iteração, crie um diagrama de classe para os itens principais no glossário do usuário, desenhe um diagrama dos principais casos de uso e desenhe um diagrama dos principais componentes. Não descreva nenhum destes em detalhes, pois os detalhes serão alterados posteriormente no projeto. Use os termos definidos neste modelo para criar uma lista de recursos ou histórias de usuários principais. Atribua os recursos a iterações de modo a equilibrar aproximadamente a carga de trabalho estimada em todo o projeto. Essas atribuições serão alteradas posteriormente no projeto.

• Tente implementar versões simplificadas de todos os casos de uso mais importantes em uma iteração inicial. Estenda esses casos de uso em iterações posteriores. Essa abordagem ajuda a reduzir o risco de descobrir uma falha nos requisitos ou a arquitetura tarde demais no projeto para fazer algo a respeito.

• Perto do final de cada iteração, realize um workshop de requisitos para definir detalhadamente os requisitos ou histórias de usuário que serão desenvolvidas na próxima iteração. Convide usuários e stakeholders de negócios que possam decidir prioridades, bem como desenvolvedores e testadores de sistema. Reserve três horas para definir os requisitos de uma iteração de duas semanas.

• O objetivo da oficina é que todos concordem com o que será realizado até o final da próxima iteração. Use modelos como uma das ferramentas para ajudar a esclarecer os requisitos. A saída do workshop é uma lista de pendências de iteração: ou seja, uma lista de tarefas de desenvolvimento no Team Foundation e conjuntos de testes no Microsoft Test Manager.

• No workshop de requisitos, discuta o design apenas na medida em que você precisa determinar estimativas para as tarefas de desenvolvimento. Caso contrário, mantenha a discussão sobre o comportamento do sistema que os usuários podem experimentar diretamente. Mantenha o modelo de requisitos separado do modelo de arquitetura.

• Os stakeholders não técnicos geralmente não têm problemas para entender os diagramas UML, com alguma orientação sua.

Vincular modelo a itens de trabalho

Após o workshop de requisitos, elabore os detalhes do modelo de requisitos e vincule o modelo às tarefas de desenvolvimento. Você pode fazer isso vinculando itens de trabalho no Team Foundation a elementos no modelo.

Você pode vincular qualquer elemento a itens de trabalho, mas os elementos mais úteis são os seguintes:

• Comentários que descrevem regras de negócios ou qualidade dos requisitos de serviço. Para obter mais informações, consulte os requisitos de usuário do modelo.

Vincular modelo a testes

Use o modelo de requisitos para orientar o design dos testes de aceitação. Crie esses testes simultaneamente com o trabalho de desenvolvimento.

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

Estimar o trabalho restante

Um modelo de requisitos pode ajudar a estimar o tamanho total do projeto em relação ao tamanho de cada iteração. Avaliar o número e a complexidade dos casos de uso e das classes pode ajudá-lo a estimar o trabalho de desenvolvimento que será necessário. Quando você concluiu as primeiras iterações, uma comparação dos requisitos abordados e os requisitos que ainda serão abordados podem fornecer uma medida aproximada do custo e do escopo do restante do projeto.

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

Níveis de abstração

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

Um modelo pode ser exibido por meio de vários tipos de diagramas. Para obter informações sobre modelos e diagramas, consulte Criar modelos para seu aplicativo.

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 em mais de um nível. Esta tabela mostra como cada tipo de diagrama pode ser usado.

Nível de design	Tipos de diagrama
Processo Empresarial Entender o contexto no qual seu sistema será usado ajuda você a entender o que os usuários precisam dele.	- Diagramas de classe conceitual descrevem os conceitos de negócios usados no processo de negócios.
Requisitos do usuário Definição do que os usuários precisam do seu sistema.	– As regras de negócios e os requisitos de qualidade do serviço podem ser descritos em documentos separados.
Design de alto nível A estrutura geral do sistema: os principais componentes e como eles se juntam.	- Diagramas de dependência descrevem como o sistema é estruturado em partes interdependentes. Você pode validar o código do programa em relação a diagramas de dependência para garantir que ele adere à arquitetura.
Análise de código Diagramas podem ser gerados a partir do código.	- Diagramas de dependência mostram as dependências entre classes. O código atualizado pode ser validado em relação a um diagrama de dependência. - Diagramas de classe mostram as classes no código.

Recursos externos

Categoria	Links
vídeos	MSDN Como faço para Vídeos: Como Criar e Utilizar Modelos e Diagramas UML (Visual Studio Ultimate) MSDN How Do I Series: Ferramentas UML e Extensibilidade (Visual Studio Ultimate)
Fóruns	- Visual Studio Visualization &Modeling Tools - Visual Studio Visualization &Modeling SDK (Ferramentas DSL)
Blogs	Microsoft DevOps
Artigos técnicos e diários	Centro de Arquitetura do MSDN

Conteúdo relacionado

• Usar modelos no desenvolvimento agile
• Criar modelos para seu aplicativo
• Requisitos de usuário de modelo
• Modelar a arquitetura do aplicativo
• Desenvolver testes de um modelo
• Estruturar sua solução de modelagem

Observação

O componente Transformação de Modelo de Texto é instalado automaticamente como parte da carga de trabalho de desenvolvimento de extensões do Visual Studio. Você também pode instalá-lo na guia Componentes individuais do Instalador do Visual Studio, na categoria SDKs, bibliotecas e estruturas . Instale o componente SDK de Modelagem da guia Componentes individuais .