Utilisation de modèles dans le processus de développement

Article
06/10/2015

Dans Visual Studio Ultimate, 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 l'environnement dans lequel votre système fonctionne, clarifier les besoins des utilisateurs, définir l'architecture de votre système, analyser le code et garantir que votre code satisfait les spécifications.

Consultez Vidéo de canal la 9 : Améliorer l'architecture via la modélisation.

Comment utiliser des modèles

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

Le dessin de diagrammes de modélisation vous aide à clarifier les concepts impliqués dans les spécifications, l'architecture et la conception de niveau supérieur. Pour plus d'informations, consultez Modélisation des besoins des utilisateurs.
L'utilisation de modèles peut vous aider à exposer des incohérences dans les spécifications.
La communication avec les modèles vous aide à communiquer des concepts importants d'une manière moins ambiguë qu'avec le langage naturel. Pour plus d'informations, consultez Modélisation de l'architecture d'un système logiciel.
Vous pouvez quelquefois utiliser des modèles pour générer du code ou d'autres artefacts tels que les schémas de la base de données ou les documents. Par exemple, les composants de modélisation de Visual Studio Ultimate sont générés à partir d'un modèle. Pour plus d'informations, consultez Génération et configuration de votre application à partir de modèles.

Vous pouvez utiliser des modèles dans une large gamme de processus, du plus agile au plus cérémonieux.

Utiliser les 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 en général obligatoires pendant le développement du logiciel.

Si votre projet est mené par une petite équipe qui suit des applications pratiques agiles, vous pouvez utiliser des modèles pour vous aider à clarifier des récits utilisateur. Lors de discussions avec le client à propos de ses besoins, la création d'un modèle peut générer des questions utiles beaucoup plus rapidement, et sur une zone plus large du produit, que l'écriture de pique-notes ou de code de prototype.

Si votre projet est de taille importante et qu'il inclut des équipes à différents endroits du globe, vous pouvez utiliser des modèles pour aider à communiquer les spécifications et l'architecture de manière beaucoup plus efficace qu'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. Des parties prenantes différentes ont fréquemment une compréhension différente du monde de l'entreprise dans lequel le système fonctionne, et des développeurs différents ont fréquemment une compréhension différente du fonctionnement du système. L'utilisation d'un modèle comme focus d'une discussion expose habituellement ces différences. Pour plus d'informations sur l'utilisation d'un modèle pour réduire les incohérences, consultez Modélisation des besoins des utilisateurs.

Utiliser les modèles avec d'autres artefacts

Un modèle n'est pas en lui-même un établissement de spécifications ou une architecture. Il s'agit d'un outil pour exprimer plus clairement certains aspects de ces choses, mais pas tous les concepts requis pendant la conception de logiciel qui sont susceptibles d'être exprimés. Par conséquent, les modèles doivent être utilisés avec d'autres moyens de communication, tels que les pages ou les paragraphes OneNote, les documents Microsoft Office, les éléments de travail dans Team Foundation ou les pense-bêtes sur le mur de la pièce du projet. Mis à part le dernier élément, tous ces types d'objets peuvent être liés aux parties des éléments du modèle.

D'autres aspects de spécifications qui sont couramment utilisés avec les modèles incluent les éléments suivants. Selon l'échelle et le style de votre projet, vous pouvez utiliser plusieurs de ces aspects ou n'en utiliser aucun :

Récits utilisateur. Un récit utilisateur est une description courte, discutée avec les utilisateurs et autres parties prenantes, d'un aspect du comportement du système qui sera fourni dans l'une des itérations du projet. Un récit utilisateur typique commence par « Le client sera en mesure de... ». Un récit utilisateur peut présenter un groupe de cas d'usage ou définir des extensions des cas d'usage précédemment développés. La définition ou l'extension des cas d'usage clarifie le récit utilisateur.
Demandes de modification. Une demande de modification dans un projet plus formel est très semblable à un récit utilisateur dans un projet agile. L'approche agile traite toutes les spécifications en tant que modifications apportées à ce qui a été développé lors des itérations précédentes.
Description de cas d'usage. Un cas d'usage représente une manière dont l'utilisateur interagit avec le système pour accomplir un objectif particulier. Une description complète inclut l'objectif, les séquences d'événements alternatives et des résultats exceptionnels. Un diagramme de cas d'usage aide à résumer et 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 qui affichent la façon dont le système, les utilisateurs et les autres systèmes fonctionnent ensemble pour fournir de la valeur aux parties prenantes. Il peut apparaître sous 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 de spécifications du projet décrit les mots avec lesquels les clients discutent de leur environnement. L'interface utilisateur et les modèles de spécifications 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 non seulement réduit les malentendus entre les utilisateurs et les développeurs, mais aussi expose presque toujours les malentendus entre des parties prenantes d'entreprise différentes.
Règles métier. De nombreuses règles métier peuvent être exprimées en tant que contraintes invariant sur les associations et les attributs dans le modèle de classe de spécifications, et en tant que contraintes sur les diagrammes de séquences.
Conception de niveau supérieur. Décrit les parties importantes et comment elles s'adaptent. Les diagrammes de composants, de séquences et d'interfaces sont des parties importantes d'une conception de niveau supérieur.
Modèles de conception. Décrit les règles de conception partagées par les différentes parties du système.
Caractéristiques de test. Les scripts de test et les conceptions pour le code de test peuvent faire bon usage des diagrammes d'activités et de séquences pour décrire des séquences d'étapes de test. Les tests de systèmes doivent être exprimés en termes de modèle de spécifications afin qu'ils puissent être modifiés facilement lorsque les spécifications changent.
Plan de projet. Le plan de projet ou le journal des travaux en souffrance (backlog) définit quand chaque fonctionnalité sera fournie. Vous pouvez définir chaque fonctionnalité en déclarant les cas d'usage et les règles métier qu'elle implémente ou étend. Vous pouvez directement faire référence aux cas d'usage et règles métier dans le plan, ou vous pouvez définir un ensemble de fonctionnalités dans un document séparé et utiliser les titres des fonctionnalités dans le plan.

Utiliser les modèles dans la planification d'itérations

Bien que tous les projets soient différents en termes d'échelle et d'organisation, un projet typique est planifié comme une série d'itérations qui durent entre deux et six semaines. Il est important de planifier suffisamment d'itérations pour autoriser l'utilisation de commentaires des premières itérations pour ajuster la portée et les plans d'itérations ultérieures.

Vous pouvez considérer utiles les suggestions suivantes pour vous permettre de tirer profit des avantages de la modélisation dans un projet itératif.

Affinez le focus à l'approche de chaque itération

À l'approche de chaque itération, utilisez les modèles permettant de définir ce qui sera fourni à la fin de l'itération.

Ne modélisez pas tout en détail dès les premières itérations. Lors de la première itération, créez un diagramme de classes pour les éléments principaux dans le glossaire utilisateur, dessinez un diagramme des cas d'usage importants et dessinez un diagramme des composants importants. Ne les décrivez pas de manière très détaillée, parce que les détails changeront ultérieurement 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 importants. Assignez ainsi les fonctionnalités aux itérations afin d'équilibrer approximativement la charge de travail estimée tout au long du projet. Ces assignations 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 des premières itérations. Étendez ces cas d'usage aux itérations ultérieures. Cette approche contribue à réduire le risque de découverte d'un défaut dans les spécifications ou l'architecture du projet trop tardivement sans pouvoir le résoudre.
À l'approche de la fin de chaque itération, tenez un atelier de spécifications pour définir en détail les spécifications ou récits utilisateur qui seront développés dans l'itération suivante. Invitez les utilisateurs et les parties prenantes d'entreprise qui peuvent décider des priorités, ainsi que les développeurs et les testeurs du système. Trois heures permettront de définir des spécifications pour une itération de 2 semaines.
L'objectif de l'atelier vise l'acceptation par tout le monde de ce qui sera accompli à la fin de l'itération suivante. Utilisez les modèles comme un des outils permettant d'aider à clarifier les spécifications. Le résultat de l'atelier est un journal des travaux en souffrance (backlog) d'itération : 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 de spécifications, discutez uniquement de la conception dans la mesure où vous devez estimer les tâches de développement. Autrement, faites porter la discussion sur le comportement du système que les utilisateurs peuvent directement expérimenter. Conservez le modèle de spécifications à part du modèle architectural.
Les parties prenantes non techniques n'ont habituellement aucun problème de compréhension à l'égard des diagrammes UML, avec un peu d'aide de votre part.

Lier le modèle aux éléments de travail

Après l'atelier de spécifications, élaborez les détails du modèle de spécifications 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 dans le modèle. Pour savoir comment procéder, consultez Lier des éléments de modèle et des éléments de travail.

Vous pouvez lier tout élément aux éléments de travail, mais les éléments les plus utiles sont les suivants :

Cas d'usage. Vous pouvez lier un cas d'usage aux tâches de développement qui l'implémenteront.
Extensions du cas d'usage. Si un seul aspect d'un cas d'usage sera implémenté dans une itération, vous pouvez le séparer dans un cas d'usage de base avec une ou plusieurs extensions. Les extensions sont des cas d'usage liés au cas de base avec la relation « étendre ». Pour plus d'informations sur l'extension du cas d'usage, consultez Diagrammes de cas d'usage UML : référence.
Commentaires qui décrivent des règles métier ou des impératifs de qualité de service. Pour plus d'informations, consultez Modélisation des besoins des utilisateurs.

Lier le modèle aux tests

Utilisez le modèle de spécifications pour guider la conception des tests d'acceptation. Créez ces tests simultanément au travail de développement.

Pour en savoir plus sur cette technique, consultez Mise au point de tests à partir d'un modèle.

Estimer le travail restant

Un modèle de spécifications 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 requis. Lorsque vous avez terminé les premières itérations, une comparaison des spécifications couvertes et des spécifications restant à couvrir peut donner une mesure approximative du coût et de la portée du reste du projet.

À l'approche de la fin de chaque itération, examinez l'assignation des spécifications aux futures itérations. Il peut être utile de représenter l'état de votre logiciel à la fin de chaque itération comme un 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 de l'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 d'entreprise qui sont susceptibles d'être représentés ou non dans le code.

Un modèle peut être affiché via plusieurs genres de diagrammes. Pour plus d'informations sur les modèles et les diagrammes, consultez Développement de modèles pour la conception logicielle.

Les différents genres de diagrammes sont utiles pour décrire la conception à différents niveaux d'abstraction. Nombre de ces types de diagrammes sont utiles à plusieurs niveaux. Ce tableau montre comment chaque type de diagramme peut être utilisé.

Niveau de conception	Types de diagrammes
Processus d'entreprise Le fonctionnement du contexte dans lequel votre système sera utilisé vous aide à comprendre ce que les utilisateurs tirent de ce dernier.	Les diagrammes d'activités décrivent le flux de travail entre les personnes et les systèmes pour accomplir des objectifs métier. Les diagrammes de classes conceptuels décrivent les concepts d'entreprise utilisés dans le processus d'entreprise.
Besoins des utilisateurs Définition de ce que les utilisateurs tirent de votre système.	Les diagrammes de cas d'usage résument les interactions que les utilisateurs et d'autres systèmes externes ont avec le système que vous développez. Vous pouvez joindre d'autres documents à chaque cas d'usage pour le décrire en détail. Les diagrammes de classes UML décrivent les types d'informations à propos desquels les utilisateurs et le système communiquent. Les règles métier et les impératifs de qualité de service peuvent être décrites dans des documents séparés.
Conception de niveau supérieur Structure globale du système : composants principaux et comment ils s'associent.	Les diagrammes de couche décrivent la façon dont le système est structuré en parties interdépendantes. Vous pouvez valider le code du programme par rapport à des diagrammes de couche pour vérifier qu'il adhère à l'architecture. Les diagrammes de composant montrent les interfaces des différentes parties, en spécifiant les messages et les services qui sont fournis et requis par chaque composant. Les diagrammes de séquences indiquent comment les composants communiquent pour implémenter chaque cas d'usage. Les diagrammes de classes UML décrivent les interfaces des composants et les types de données passées entre les composants.
Modèles de conception Conventions et méthodes de résolution des problèmes de conception utilisés dans toutes les parties de la conception	Les diagrammes de classes UML décrivent les structures d'un modèle Les diagrammes de séquences ou d'activités affichent les interactions et les algorithmes
Analyse du code Plusieurs types de diagrammes peuvent être générés à partir du code.	Les diagrammes de séquences affichent l'interaction entre les objets dans le code. Les diagrammes de couche affichent les dépendances entre les classes. Le code mis à jour peut être validé par rapport à un diagramme de couche. Les diagrammes de classes montrent les classes présentes dans le code.

Ressources externes

Catégorie	Liens
Videos
Forums	Outils de visualisation et de modélisation Visual Studio (page éventuellement en anglais) Kit de développement logiciel de visualisation et de modélisation Visual Studio (outils DSL) (page éventuellement en anglais)
Blogs	Visual Studio ALM + Team Foundation Server Blog
Articles et journaux techniques	The Architecture Journal - Issue 23: Architecture Modeling and Processes
Autres sites	Portail Architectes Guide des outils d'architecture Visual Studio