Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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 em que seu sistema funciona, esclarecer as necessidades dos usuários, definir a arquitetura do seu sistema, analisar o código e garantir que seu código atenda aos requisitos.
Para ver quais versões do Visual Studio oferecem suporte a cada tipo de modelo, consulte Suporte de versão para ferramentas de arquitetura e modelagem.
Os modelos podem ajudá-lo de várias maneiras:
Desenhar diagramas de modelagem ajuda a esclarecer os conceitos envolvidos em requisitos, arquitetura e design de alto nível. Para obter mais informações, consulte Requisitos do usuário do modelo.
Trabalhar com modelos pode ajudá-lo a expor inconsistências nos requisitos.
A comunicação com modelos ajuda-o 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 seu 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 numa vasta gama de processos, desde metodologia ágil extrema até cerimônia elevada.
Use modelos para reduzir a ambiguidade
A linguagem de modelagem é menos ambígua do que a linguagem natural, e é projetada para expressar as ideias normalmente necessárias durante o desenvolvimento de software.
Se o seu projeto tem uma pequena equipe seguindo práticas ágeis, você pode usar modelos para ajudá-lo 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 seu 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 em texto simples.
Em ambos os casos, a criação de um modelo resulta quase sempre numa redução significativa das incoerências e ambiguidades. Diferentes partes interessadas frequentemente têm entendimentos diferentes do mundo dos negócios em que o sistema funciona, e diferentes desenvolvedores frequentemente têm entendimentos 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 do usuário do modelo.
Usar modelos com outros artefatos
Um modelo não é, por si só, uma especificação de requisitos ou uma arquitetura. É uma ferramenta para expressar alguns aspetos dessas coisas com mais clareza, mas nem todos os conceitos necessários durante o design de software podem ser expressos. Os modelos devem, portanto, ser usados em conjunto 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 notas adesivas na parede da sala de projeto. Além do último item, todos esses tipos de objeto podem ser vinculados a partes de elementos do modelo.
Outros aspetos da especificação que são normalmente usados em conjunto com os modelos incluem o seguinte. Dependendo da escala e do estilo do seu projeto, você pode usar vários desses aspetos ou não usar nenhum:
Histórias de usuários. Uma história de usuário é uma breve descrição, discutida com usuários e outras partes interessadas, de um aspeto 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 apresentar um grupo de casos de uso ou pode 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.
Pedidos 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 ao que foi desenvolvido em iterações anteriores.
Descrição do caso de uso. Um caso de uso representa uma maneira pela qual um usuário interage com o sistema para atingir um objetivo específico. Uma descrição completa inclui o objetivo, sequências principais e alternativas de eventos e resultados excecionais. 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 que mostra como o sistema, os usuários e outros sistemas trabalham juntos para fornecer valor às partes interessadas. Pode tomar a forma de uma apresentação de diapositivos da interface do utilizador ou de um protótipo desta. 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 o seu mundo. A interface do utilizador e os modelos de requisitos também devem utilizar estes termos. Um diagrama de classes pode ajudar a esclarecer as relações entre a maioria desses termos. A criação dos diagramas e glossários não só reduz mal-entendidos entre usuários e desenvolvedores, mas também quase sempre expõe mal-entendidos entre diferentes partes interessadas do negócio.
Regras de negócio. Muitas regras de negócios podem ser expressas como restrições invariantes 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. Os diagramas de componentes, sequências e interfaces 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 para 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 mudam.
Plano de projeto. O plano de projeto ou 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 dos recursos 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 de entre duas e seis semanas. É importante planejar iterações suficientes para permitir que o feedback das iterações iniciais seja usado 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.
Aprimore 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 primeiras iterações. Na primeira iteração, crie um diagrama de classes 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, porque o detalhe mudará mais tarde no projeto. Use os termos definidos neste modelo para criar uma lista de recursos ou histórias de usuários principais. Atribua as funcionalidades a iterações de modo a equilibrar aproximadamente a carga de trabalho estimada ao longo do 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 na arquitetura muito tarde no projeto para fazer algo a respeito.
Perto do final de cada iteração, realize um workshop de requisitos para definir em detalhes os requisitos ou histórias de usuários que serão desenvolvidos na próxima iteração. Convide usuários e partes interessadas de negócios que podem decidir prioridades, bem como desenvolvedores e testadores de sistema. Permita três horas para definir os requisitos para uma iteração de 2 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. 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 pacotes de teste 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.
As partes interessadas não técnicas geralmente não têm problemas para entender diagramas UML, com algumas orientações suas.
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 em Team Foundation para 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 as regras de negócio ou os requisitos de qualidade do serviço. Para obter mais informações, consulte Requisitos do 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 a partir 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 classes pode ajudá-lo a estimar o trabalho de desenvolvimento que será necessário. Quando você tiver concluído as primeiras iterações, uma comparação entre os requisitos cobertos e os requisitos ainda a cobrir pode fornecer uma medida aproximada do custo e do escopo do restante do projeto.
Perto do final de cada iteração, revise a atribuição de requisitos para iterações futuras. Pode ser útil representar o estado do seu 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 caso de uso de um desses subsistemas para outro.
Níveis de abstração
Os modelos têm uma gama 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 visualizado através 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 diagramas são úteis em mais de um nível. Esta tabela mostra como cada tipo de diagrama pode ser usado.
| Nível de conceção | Tipos de diagrama |
|---|---|
| Processo de Negócio Compreender o contexto dentro do qual seu sistema será usado ajuda você a entender o que os usuários precisam dele. |
- Diagramas de classes conceituais descrevem os conceitos de negócios usados dentro do processo de negócios. |
| Requisitos do utilizador Definição do que os usuários precisam do seu sistema. |
- As regras de negócio 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 unem. |
- Os diagramas de dependência descrevem como o sistema está estruturado em partes interdependentes. Você pode validar o código do programa em diagramas de dependência para garantir que ele adira à arquitetura. |
| Análise de código Os diagramas podem ser gerados a partir do código. |
- Os 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. - Os diagramas de classes mostram as classes no código. |
Recursos externos
Conteúdo relacionado
- Use modelos no desenvolvimento ágil
- Criar modelos para seu aplicativo
- Requisitos do usuário do modelo
- Modele a arquitetura do seu aplicativo
- Desenvolver testes a partir de um modelo
- Estruture 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ão do Visual Studio . Você também pode instalá-lo na guia Componentes individuais do Visual Studio Installer, na categoria SDKs, bibliotecas e estruturas . Instale o componente SDK de modelagem na guia Componentes individuais .