Usando modelos dentro do processo de desenvolvimento

Artigo
08/08/2011

Em Visual Studio Ultimate, você pode usar um modelo para ajudar a entender e alterar um sistema, aplicativo ou componente. Um modelo pode ajudá-lo a visualizar o mundo em que o seu sistema funciona, esclarecer dos usuários. precisa, definir a arquitetura do seu sistema, analisar o código e garantir que seu código atende aos requisitos.

Como usar modelos

Modelos podem ajudá-lo de várias maneiras:

Diagramas de modelagem de desenho ajuda a esclarecer os conceitos envolvidos na requisitos, arquitetura e design de alto nível. Para obter mais informações, consulte Requisitos do usuário de modelagem..
Trabalhar com modelos pode ajudá-lo a expor inconsistências nos requisitos.
Comunicação com modelos ajuda você a se comunicar conceitos importantes menos ambiguamente com idioma natural. Para obter mais informações, consulte A arquitetura de um sistema de Software de modelagem..
Às vezes, você pode usar modelos para gerar o código ou outros artefatos como, por exemplo, esquemas de banco de dados ou documentos. Por exemplo, os componentes de modelagem de Visual Studio Ultimate gerado a partir de um modelo. Para obter mais informações, consulte Gerar e configurar seu aplicativo de modelos.

Você pode usar os modelos em uma ampla variedade de processos, desde extreme cerimônia ágil para alta.

Use modelos para reduzir a ambigüidade

Linguagem de modelagem é menos ambígua de linguagem natural e é projetado para expressar as idéias normalmente necessárias durante o desenvolvimento de software.

Se seu projeto possui uma pequena equipe seguir práticas agile, você pode usar modelos para ajudá-lo a esclarecer as 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 rápido e, em uma área maior do produto, de escrever o código de pico ou protótipo.

Se seu projeto for grande e inclui as equipes em diferentes partes do mundo, você pode usar modelos para ajudar a comunicar os requisitos e a arquitetura de forma muito mais eficiente 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 no inconsistências e ambigüidades. Os diferentes interessados freqüentemente têm diferentes entendimentos do mundo dos negócios em que o sistema funciona e diferentes desenvolvedores freqüentemente têm diferentes entendimentos do funcionamento do sistema. Usando um modelo como o foco de uma discussão geralmente expõe essas diferenças. Para obter mais informações sobre como usar um modelo para reduzir as inconsistências, consulte Requisitos do usuário de modelagem..

Modelos de uso com outros artefatos.

Um modelo não é por si só, uma arquitetura ou uma especificação de requisitos. É uma ferramenta para expressar alguns aspectos dessas coisas mais claramente, mas nem 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, por exemplo, páginas do OneNote ou parágrafos, Microsoft Office documentos, itens de trabalho em Team Foundation, ou as notas auto-adesivas na parede de sala de 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 com os modelos incluem o seguinte. Dependendo da escala e o estilo do seu projeto, você pode utilizar vários desses aspectos ou não usar qualquer todo:

Histórias de usuários. Uma história de usuário é uma breve descrição, discutida com usuários e outros investidores, de um aspecto do comportamento do sistema que serão entregues em uma das iterações do projeto. Uma história de usuário típica começa "O cliente será poderá...". Uma história de usuário pode introduzir um grupo de casos de uso, ou pode definir as extensões de casos de uso que foram desenvolvidos anteriormente. Definindo ou estendendo os casos de uso ajuda a tornar mais clara de história de usuário.
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 agile. A abordagem ágil trata todos os requisitos, como as alterações para o que foi desenvolvido em iterações anteriores.
Use a descrição do caso. Um caso de uso representa uma maneira na qual um usuário interage com o sistema para alcançar uma meta específica. Uma descrição completa inclui o objetivo, o principais e alternativas de seqüências de eventos e resultados excepcionais. Um diagrama de caso de uso ajuda resumir e fornecer uma visão geral dos casos de uso.
Cenários. Um cenário é uma descrição bem detalhada de uma seqüência de eventos, mostrando como o sistema, usuários e outros sistemas trabalham juntos para fornecer valor às partes interessadas. Pode levar 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 de uma seqüência de casos de uso.
Glossário. Glossário de requisitos do projeto descreve as palavras com o qual os clientes discutem seu mundo. Os modelos de requisitos e a interface do usuário também devem usar esses termos. Um diagrama de classes pode ajudar a esclarecer as relações entre a maioria destes termos. Criação de diagramas e do glossário não apenas reduz o mal-entendidos entre desenvolvedores e usuários, mas também quase sempre expõe mal-entendidos entre as partes interessadas no negócio diferente.
Regras de negócios. Muitas regras de negócios podem ser expressos como invariável restrições nas associações e atributos do modelo de classe de requisitos e como restrições de diagramas de seqüência.
Design de alto nível. Descreve as principais partes e como elas se encaixam. Diagramas de interface, de seqüência e de componente 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. Scripts de teste e os designs de código de teste podem fazer um bom uso de diagramas de seqüência e de atividade para descrever as seqüências de etapas de teste. Testes de sistema devem ser expressos em termos de modelo de requisitos para que eles podem ser alterados facilmente quando as necessidades mudam.
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 usar casos e ela implementa ou estende as regras de negócios. Ou você pode se referir aos casos de uso e as regras de negócios diretamente no plano, ou você pode definir um conjunto de recursos em um documento separado e use os títulos de recurso no plano.

Usar os modelos no planejamento de iteração

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

As sugestões a seguir pode ser útil para ajudar a obter os benefícios da modelagem em um projeto iterativo.

Como cada abordagens de iteração nítido

Conforme se aproxima de cada iteração, use modelos para ajudar a definir o que deve ser entregue ao final da iteração.

Não é modelo tudo em detalhes nas primeiras iterações. Na primeira iteração, criar um diagrama de classe para os itens principais no Glossário do usuário, desenhe um diagrama, os principais casos de uso e desenhe um diagrama dos principais componentes. Não descreva qualquer um desses detalhes finos, porque o detalhe será alterada 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 de iterações para aproximadamente equilibrar 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 antecipada. Estender os casos de uso em iterações posteriores. Essa abordagem ajuda a reduzir o risco de descobrir uma falha nos requisitos ou a arquitetura muito atrasado no projeto fazer nada sobre ela.
Próximo ao final de cada iteração, mantenha um workshop de requisitos para definir em detalhes os requisitos ou histórias de usuários que serão desenvolvidas na próxima iteração. Convide usuários e partes interessadas no negócio quem podem decidir prioridades, bem como os desenvolvedores e testadores do sistema. Permita a três horas definir requisitos para uma iteração de 2 semanas.
O objetivo do workshop é todos concordam que será obtido no 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 desenvolvimento de tarefas no Team Foundation e testar conjuntos em Microsoft Test Manager.
O workshop de requisitos, aborde o design somente na medida você precisa determinar estimativas para as tarefas de desenvolvimento. Caso contrário, mantenha a discussão para o comportamento do sistema que os usuários podem enfrentar diretamente. Manter o modelo de requisitos separado do modelo de arquitetura.
Os participantes não-técnicos geralmente não têm problemas Noções básicas sobre os diagramas UML, com a orientação de você.

Modelo de link para itens de trabalho

Após o workshop de requisitos, elaborar os detalhes do modelo de requisitos e vincular o modelo para tarefas de desenvolvimento. Você pode fazer isso vinculando itens de trabalho em Team Foundation a elementos do modelo. Para saber como fazer isso, consulte Como: Link de elementos de modelo para os itens de trabalho.

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

Casos de uso. Você pode vincular um caso de uso para as tarefas de desenvolvimento que irão implementá-lo.
Use as extensões de maiúsculas. Se apenas um aspecto de um caso de uso será implementado em uma iteração, você pode separá-lo em um caso de uso base juntamente com uma ou mais extensões. As extensões são vinculados a ocorrência de base com o relacionamento «estender» de casos de uso. Para obter mais informações sobre a extensão de casos de uso, consulte Diagramas de caso de uso UML: Referência.
Comentários que descrevam as regras de negócios ou a qualidade dos requisitos de serviço. Para obter mais informações, consulte Requisitos do usuário de modelagem..

Modelo de link para testes

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

Para saber mais sobre essa técnica, consulte O desenvolvimento de 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 das classes e casos de uso pode ajudá-lo a estimar o trabalho de desenvolvimento que serão necessário. Quando você concluiu as primeira algumas iterações, uma comparação dos requisitos abordados e os requisitos ainda para cobrir pode dar uma medida aproximada do custo e escopo do restante do projeto.

Próximo ao final de cada iteração, revise a atribuição dos requisitos de iterações futuras. Pode ser útil representar o estado do seu software no final de cada iteração, como um subsistema de um diagrama de caso de uso. Em suas discussões, você pode mover os casos de uso e usar as extensões de casos de um dos seguintes 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 de programa e os modelos mais abstratos representam conceitos de negócios que podem ou não podem ser representados no código.

Um modelo pode ser visualizado por meio de vários tipos de diagramas. Para obter informações sobre modelos e diagramas, consulte O desenvolvimento de modelos de Design de Software.

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 de negócios Noções básicas sobre o contexto no qual o sistema será usado o ajudará a compreender o que os usuários que precisam dele.	Diagramas de atividade descrevem o fluxo de trabalho entre pessoas e sistemas para atingir metas de negócios. Diagramas de classe conceitual descrevem os conceitos de negócios usados dentro do processo de negócios.
Requisitos do usuário Definição de que os usuários precisam do seu sistema.	Diagramas de caso de uso resumem as interações de usuários e outros sistemas externos têm no sistema que você está desenvolvendo. Você pode anexar outros documentos para cada caso de uso para descrevê-lo em detalhes. Diagramas de classe UML descrevem os tipos de informações que os usuários e o sistema se comunique. Regras de negócios e a qualidade dos requisitos de serviço podem ser descritos em documentos separados.
Design de alto nível A estrutura geral do sistema: os principais componentes e como eles associam juntos.	Os diagramas de camada descrevem como o sistema está estruturado em partes interdependentes. Você pode validar código de programa contra diagramas para garantir que ele adere à arquitetura de camada. Diagramas de componente mostram as interfaces das partes, especificando as mensagens e serviços que são fornecidos e exigidos por cada componente. Os diagramas de seqüência mostram como os componentes se comunicam para implementar cada caso de uso. Diagramas de classe UML descrevem as interfaces dos componentes e os tipos de dados passados entre os componentes.
Padrões de design Convenções e métodos para solucionar problemas de design que são usados em todas as partes do design	Diagramas de classe UML descrevem as estruturas de um padrão Diagramas de seqüência ou atividade mostram as interações e algoritmos
Análise de código Vários tipos de diagrama podem ser gerados a partir do código.	Diagramas de seqüência mostram a interação entre objetos no código. Diagramas de camada mostram as dependências entre as classes. Código atualizado pode ser validado em relação a um diagrama de camada. Os diagramas de classe mostram as classes no código.