Utiliser des modèles dans votre processus de développement

Dans Visual Studio, vous pouvez utiliser un modèle pour vous aider à comprendre et modifier un système, une application ou un composant. Un modèle peut vous aider à visualiser le monde dans lequel votre système fonctionne, clarifier les besoins des utilisateurs, définir l’architecture de votre système, analyser le code et s’assurer que votre code répond aux exigences.

Pour voir quelles versions de Visual Studio prennent en charge chaque type de modèle, consultez La prise en charge des versions pour les outils d’architecture et de modélisation.

Les modèles peuvent vous aider de plusieurs façons :

• Les diagrammes de modélisation vous aident à clarifier les concepts impliqués dans les exigences, l’architecture et la conception de haut niveau. Pour plus d’informations, consultez Exigences de l'utilisateur modèle.

• L’utilisation de modèles peut vous aider à exposer des incohérences dans les exigences.

• La communication avec des modèles vous permet de communiquer des concepts importants moins ambigus qu’avec le langage naturel. Pour plus d’informations, consultez l’architecture de votre application.

• Vous pouvez parfois utiliser des modèles pour générer du code ou d’autres artefacts tels que des schémas de base de données ou des documents. Par exemple, les composants de modélisation de Visual Studio sont générés à partir d’un modèle. Pour plus d’informations, consultez Générer et configurer votre application à partir de modèles.

Vous pouvez utiliser des modèles dans un large éventail de processus, de l’agilité extrême au hautement cérémoniel.

Utiliser des modèles pour réduire l’ambiguïté

Le langage de modélisation est moins ambigu que le langage naturel, et il est conçu pour exprimer les idées généralement requises pendant le développement de logiciels.

Si votre projet a une petite équipe en suivant des pratiques agiles, vous pouvez utiliser des modèles pour vous aider à clarifier les récits utilisateur. Dans les discussions avec le client sur ses besoins, la création d'un modèle peut générer des questions utiles beaucoup plus rapidement, et dans des aspects plus larges du produit, que la rédaction de code spike ou de prototype.

Si votre projet est volumineux et inclut des équipes dans différentes parties du monde, vous pouvez utiliser des modèles pour vous aider à communiquer les exigences et l’architecture beaucoup plus efficacement que vous pouvez en texte brut.

Dans les deux cas, la création d’un modèle entraîne presque toujours une réduction significative des incohérences et des ambiguïtés. Les différentes parties prenantes ont souvent différentes compréhensions du monde des affaires dans lequel le système fonctionne, et les différents développeurs ont souvent des compréhensions différentes de la façon dont le système fonctionne. L’utilisation d’un modèle comme objectif d’une discussion expose généralement ces différences. Pour plus d’informations sur l’utilisation d’un modèle pour réduire les incohérences, consultez les exigences des utilisateurs du modèle.

Utiliser des modèles avec d’autres artefacts

Un modèle n’est pas lui-même une spécification requise ou une architecture. Il s’agit d’un outil permettant d’exprimer plus clairement certains aspects, mais tous les concepts requis pendant la conception logicielle ne peuvent pas être exprimés. Les modèles doivent donc être utilisés avec d’autres moyens de communication, tels que des pages ou des paragraphes OneNote, des documents Microsoft Office, des éléments de travail dans Team Foundation ou des notes collantes sur le mur de la salle de projet. Outre le dernier élément, tous ces types d’objets peuvent être liés à des parties d’éléments du modèle.

D’autres aspects de la spécification qui sont généralement utilisés avec les modèles incluent les éléments suivants. Selon la mise à l’échelle et le style de votre projet, vous pouvez utiliser plusieurs de ces aspects ou ne pas utiliser du tout :

• Récits utilisateur. Un récit utilisateur est une brève description, abordée avec les utilisateurs et d’autres parties prenantes, d’un aspect du comportement du système qui sera remis dans l’une des itérations du projet. Une histoire d’utilisateur classique commence « Le client sera en mesure de.... » Un récit utilisateur peut introduire un groupe de cas d’usage ou définir des extensions de cas d’usage qui ont déjà été développés. La définition ou l’extension des cas d’usage permet de rendre le récit utilisateur plus clair.

• Demandes de changement. Une demande de modification dans un projet plus formel est très similaire à une histoire utilisateur dans un projet agile. L’approche agile traite toutes les exigences comme des modifications apportées à ce qui a été développé dans les itérations précédentes.

• Description du cas d’usage. Un cas d’usage représente une façon dont un utilisateur interagit avec le système pour atteindre un objectif particulier. Une description complète comprend l’objectif, les séquences principales et alternatives d’événements et les résultats exceptionnels. Un diagramme de cas d’usage permet de résumer et de fournir une vue d’ensemble des cas d’usage.

• Scénarios. Un scénario est une description assez détaillée d’une séquence d’événements montrant comment le système, les utilisateurs et d’autres systèmes fonctionnent ensemble pour fournir de la valeur aux parties prenantes. Il peut prendre la forme d’un diaporama de l’interface utilisateur ou d’un prototype de l’interface utilisateur. Il peut décrire un cas d’usage ou une séquence de cas d’usage.

• Glossaire. Le glossaire des exigences du projet décrit les mots avec lesquels les clients discutent de leur monde. Les modèles d’interface utilisateur et de configuration requise doivent également utiliser ces termes. Un diagramme de classes peut aider à clarifier les relations entre la plupart de ces termes. La création des diagrammes et du glossaire réduit non seulement les malentendus entre les utilisateurs et les développeurs, mais expose également presque toujours les malentendus entre les différentes parties prenantes de l’entreprise.

• Règles métier. De nombreuses règles métier peuvent être exprimées sous forme de contraintes invariantes sur les associations et les attributs dans le modèle de classe d’exigences, et en tant que contraintes sur les diagrammes de séquence.

• Conception générale. Décrit les parties principales et la façon dont elles s’adaptent ensemble. Les diagrammes de composants, de séquence et d’interface font partie intégrante d’une conception générale.

• Modèles de conception. Décrivez les règles de conception partagées entre les différentes parties du système.

• Spécifications de test. Les scripts de test et les conceptions pour le code de test peuvent utiliser les diagrammes d’activité et de séquence pour décrire les séquences d’étapes de test. Les tests système doivent être exprimés en termes de modèle d’exigences afin qu’ils puissent facilement être modifiés lorsque les exigences changent.

• Plan de projet. Le plan de projet ou le backlog définit le moment où chaque fonctionnalité sera remise. Vous pouvez définir chaque fonctionnalité en indiquant les cas d’usage et les règles métier qu’il implémente ou étend. Vous pouvez faire référence aux cas d’usage et aux règles métier directement dans le plan, ou vous pouvez définir un ensemble de fonctionnalités dans un document distinct et utiliser les titres des fonctionnalités dans le plan.

Utiliser des modèles dans la planification des itérations

Bien que tous les projets soient différents dans leur échelle et leur organisation, un projet classique est planifié sous la forme d’une série d’itérations comprises entre deux et six semaines. Il est important de planifier suffisamment d’itérations pour permettre aux commentaires des premières itérations d’être utilisées pour ajuster l’étendue et les plans des itérations ultérieures.

Vous trouverez peut-être les suggestions suivantes utiles pour vous aider à réaliser les avantages de la modélisation dans un projet itératif.

Affiner la concentration au fur et à mesure que chaque itération se rapproche

À mesure que chaque itération approche, utilisez des modèles pour vous aider à définir ce qui doit être remis à la fin de l’itération.

• Ne modélisez pas tout en détail dans les premières itérations. Dans la première itération, créez un diagramme de classes pour les éléments principaux du glossaire utilisateur, dessinez un diagramme des cas d’usage principaux et dessinez un diagramme des composants principaux. Ne décrivez pas ces éléments en détail, car les détails changeront plus loin dans le projet. Utilisez les termes définis dans ce modèle pour créer une liste de fonctionnalités ou de récits utilisateur majeurs. Affectez les fonctionnalités aux itérations afin d’équilibrer approximativement la charge de travail estimée tout au long du projet. Ces affectations changeront ultérieurement dans le projet.

• Essayez d’implémenter des versions simplifiées de tous les cas d’usage les plus importants dans une itération anticipée. Étendez ces cas d’usage dans les itérations ultérieures. Cette approche permet de réduire le risque de découvrir une faille dans les exigences ou l’architecture trop tard dans le projet pour y remédier.

• Près de la fin de chaque itération, organisez un atelier de configuration requise pour définir en détail les exigences ou les récits utilisateur qui seront développés dans l’itération suivante. Invitez les utilisateurs et les parties prenantes de l’entreprise qui peuvent décider des priorités, ainsi que des développeurs et des testeurs système. Prévoyez trois heures pour définir les exigences pour une itération de deux semaines.

• L’objectif de l’atelier est que tout le monde accepte ce qui sera accompli à la fin de l’itération suivante. Utilisez des modèles comme l’un des outils pour clarifier les exigences. La sortie de l’atelier est un backlog d’itérations : c’est-à-dire une liste de tâches de développement dans Team Foundation et des suites de tests dans Microsoft Test Manager.

• Dans l’atelier des exigences, discutez de la conception uniquement dans la mesure où vous devez déterminer les estimations des tâches de développement. Sinon, gardez la discussion sur le comportement système que les utilisateurs peuvent expérimenter directement. Séparez le modèle de configuration requise du modèle architectural.

• Les parties prenantes non techniques n’ont généralement aucun problème de compréhension des diagrammes UML, avec quelques conseils de vous.

Lier un modèle à des éléments de travail

Après l’atelier des exigences, développez les détails du modèle de configuration requise et liez le modèle aux tâches de développement. Pour ce faire, vous pouvez lier des éléments de travail dans Team Foundation aux éléments du modèle.

Vous pouvez lier n’importe quel élément à des éléments de travail, mais les éléments les plus utiles sont les suivants :

• Commentaires décrivant les règles d’entreprise ou la qualité des exigences de service. Pour plus d’informations, consultez Exigences de l'utilisateur modèle.

Lier un modèle à des tests

Utilisez le modèle de configuration requise pour guider la conception des tests d’acceptation. Créez ces tests simultanément avec le travail de développement.

Pour en savoir plus sur cette technique, consultez Développer des tests à partir d’un modèle.

Estimer le travail restant

Un modèle de configuration requise peut aider à estimer la taille totale du projet par rapport à la taille de chaque itération. L’évaluation du nombre et de la complexité des cas d’usage et des classes peut vous aider à estimer le travail de développement qui sera nécessaire. Lorsque vous avez terminé les premières itérations, une comparaison des exigences couvertes et des exigences toujours à couvrir peut donner une mesure approximative du coût et de l’étendue du reste du projet.

À la fin de chaque itération, passez en revue l’affectation des exigences aux itérations futures. Il peut être utile de représenter l’état de votre logiciel à la fin de chaque itération en tant que sous-système dans un diagramme de cas d’usage. Dans vos discussions, vous pouvez déplacer des cas d’usage et des extensions de cas d’usage d’un de ces sous-systèmes vers un autre.

Niveaux d’abstraction

Les modèles ont une plage d’abstraction par rapport au logiciel. Les modèles les plus concrets représentent directement le code du programme, et les modèles les plus abstraits représentent des concepts métier susceptibles ou non d’être représentés dans le code.

Un modèle peut être consulté par le biais de plusieurs types de diagrammes. Pour plus d’informations sur les modèles et les diagrammes, consultez Créer des modèles pour votre application.

Différents types de diagrammes sont utiles pour décrire la conception à différents niveaux d’abstraction. De nombreux types de diagrammes sont utiles à plusieurs niveaux. Ce tableau montre comment chaque type de diagramme peut être utilisé.

Ressources externes

Catégorie	Liens
vidéos	MSDN How Do I Videos : How to Create and Use UML Models and Diagrams (Visual Studio Ultimate) MSDN How Do I Series : UML Tools and Extensibility (Visual Studio Ultimate)
Forums	- Visual Studio Visualisation & Outils de modélisation - Visual Studio Visualization &Modeling SDK (Outils DSL)
Blogs	Microsoft DevOps
Articles techniques et revues	Centre d’architecture MSDN

Contenu connexe

• Utiliser des modèles dans le développement Agile
• Créer des modèles pour votre application
• Configuration requise pour l’utilisateur de modèle
• Modéliser l’architecture de votre application
• Développer des tests à partir d’un modèle
• Structurez votre solution de modélisation