Usar modelos no 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, confira Suporte de versão para ferramentas de arquitetura e modelagem.
Os modelos podem ajudá-lo de várias maneiras:
Diagramas de modelagem de desenho ajudam você a esclarecer os conceitos envolvidos em requisitos, arquitetura e design de alto nível. Para obter mais informações, consulte Requisitos do usuário de Modelo.
Trabalhar com modelos pode ajudar a expor inconsistências nos requisitos.
A comunicação com modelos ajuda a comunicar conceitos importantes de maneira 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 agile extremo à alta 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 um pico ou um código de protótipo.
Se o projeto for grande e incluir equipes em diferentes partes do mundo, você poderá usar modelos para ajudar a comunicar os requisitos e a arquitetura de forma muito mais eficaz do que você pode 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 diferentes desenvolvedores 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 Requisitos de usuário de modelo.
Usar modelos com outros artefatos
Um modelo não é por si só uma especificação de requisitos ou uma arquitetura. Ele é uma ferramenta para expressar alguns aspectos desses elementos 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 da especificação que normalmente são usados junto com modelos incluem o seguinte. Dependendo da escala e do estilo do 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 poderá...." 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.
Solicitações de alteração. Uma solicitação de alteração em um projeto mais formal é muito semelhante a uma história de usuário em um projeto ágil. A abordagem ágil trata todos os requisitos como alterações no que foi desenvolvido em iterações anteriores.
Descrição de caso de uso. 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, 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 ter 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 diagramas e 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 importante 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 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 de projeto. O plano de projeto ou a lista de pendências 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 definir um conjunto de recursos em um documento separado e usar os títulos do 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.
Aprimorar o foco à medida que cada iteração se aproxima
À medida que cada iteração se aproxima, use modelos para ajudar a definir o que deve 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 componentes principais. Não descreva nenhum deles 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ário principais. Atribua os recursos a iterações para 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.
Próximo ao final de cada iteração, realize um workshop de requisitos para definir detalhadamente os requisitos ou histórias do usuário que serão desenvolvidos na próxima iteração. Convide usuários e stakeholders de negócios que possam decidir prioridades, bem como desenvolvedores e testadores de sistema. Dedique três horas para definir os requisitos para uma iteração de duas semanas.
O objetivo do workshop é 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. O resultado 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 algumas diretrizes de você.
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 requisitos de qualidade de serviço. Para obter mais informações, consulte Requisitos do usuário de 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, confira 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 ainda a serem abordados podem fornecer uma medida aproximada do custo e do escopo do restante do projeto.
Próximo ao 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 usar extensões de caso 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 de usuário Definição do que os usuários precisam do sistema. |
- As regras de negócios e a qualidade dos requisitos de serviço podem ser descritas 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 diagramas de dependência para garantir que ele adere à arquitetura. |
| Análise de código Diagramas podem ser gerados com base no 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
Conteúdo relacionado
- Usar modelos no desenvolvimento de Agile
- Criar modelos para o aplicativo
- Requisitos de usuário do modelo
- Modelar a arquitetura do aplicativo
- Desenvolver testes por meio de um modelo
- Estruturar a 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 na guia Componentes individuais.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de