Partager via

Vue d'ensemble du scénario : modifier votre conception à l'aide de la visualisation et de la modélisation

  • Article

Pour vérifier que votre système logiciel répond aux besoins de l'utilisateur, utilisez les outils de visualisation et de modélisation dans Visual Studio Ultimate pour vous aider à mettre à jour ou à modifier la conception du système. Ces outils incluent les diagrammes UML (Unified Modeling Language), les diagrammes de couche, les graphiques de dépendance basés sur le code, les diagrammes de séquence et les diagrammes de classe. Par exemple, vous pouvez utiliser ces outils pour effectuer les tâches suivantes :

  • Clarifier les spécifications des utilisateurs et les processus d'entreprise.

  • Visualiser et explorer le code existant.

  • Décrire les modifications apportées à un système existant.

  • Vérifier que le système d'exploitation répond aux conditions requises.

  • Maintenir une cohérence entre le code et la conception.

Cette procédure pas à pas utilise un exemple de scénario visant à accomplir les objectifs suivants :

  • Fournir une vue d'ensemble des outils et des bénéfices qu'ils apportent à un projet de logiciel.

  • Indiquer comment deux équipes peuvent utiliser ces outils dans un exemple de scénario, indépendamment de leur approche de développement respective.

Pour plus d'informations sur ces outils et les scénarios qu'ils prennent en charge, consultez :

Dans cette rubrique

Section

Description

Vue d'ensemble du scénario

Décrit le scénario et ses participants.

Rôle des diagrammes d'architecture et de modélisation dans le développement de logiciels

Décrit les rôles que ces outils peuvent jouer durant le cycle de vie de développement d'un logiciel.

Compréhension et communication des informations relatives au système

Fournit une vue d'ensemble de la façon dont les participants utilisent les outils dans ce scénario.

Mise à jour du système à l'aide de la visualisation et de la modélisation

Fournit des détails à propos de chaque outil, ainsi que la façon dont ils peuvent être utilisés dans ce scénario.

Vue d'ensemble du scénario

Ce scénario décrit certains épisodes du cycle de vie de développement de logiciels de deux sociétés fictives : Dinner Now et Lucerne Publishing. Dinner Now fournit un service Internet de livraison de repas à Seattle. Les clients peuvent commander des repas et les payer sur le site Web de Dinner Now. Les commandes sont envoyées au restaurant approprié le plus proche, en vue de leur livraison. Lucerne Publishing, société située à New York, est à la tête de plusieurs entreprises, dont certaines sont basées sur Internet. L'une d'entre elles consiste à gérer un site Web sur lequel les clients peuvent donner leur avis sur des restaurants.

Lucerne vient d'acquérir Dinner Now et souhaite apporter les modifications suivantes :

  • Fusionner leurs sites Web en ajoutant des fonctions d'évaluation de restaurants à Dinner Now.

  • Remplacer le système de paiement de Dinner Now par celui de Lucerne.

  • Développer le service Dinner Now à travers tout le pays.

Dinner Now utilise SCRUM et eXtreme Programming. Leur couverture de test est très élevée et seule une petite quantité de leur code n'est pas prise en charge. Ils réduisent les risques en créant des versions, certes petites, mais fonctionnelles, d'un système, puis en ajoutant les fonctionnalités de façon incrémentielle. Ils développent leur code sur des itérations courtes et fréquentes. Cela leur permet d'aborder les changements en toute confiance, de refactoriser fréquemment le code et d'éviter le scénario d'une architecture monolithique connu sous le nom de « Big Design Up Front ».

Lucerne détient une collection de systèmes bien plus importante et bien plus complexe, dont certains ont plus de 40 ans. Ils font preuve de beaucoup de prudence en matière de modifications, en raison de la complexité et de la portée du code hérité. Ils suivent un processus de développement plus rigoureux, préférant concevoir des solutions détaillées et documenter la conception et les modifications durant le processus de développement.

Les deux équipes utilisent les diagrammes de modélisation de Visual Studio Ultimate pour développer des systèmes qui répondent aux besoins des utilisateurs. Ils utilisent Team Foundation Server, ainsi que d'autres outils pour les aider à planifier, à organiser et à gérer leur travail.

Pour plus d’informations sur Team Foundation Server, consultez :

  • Planification et suivi des travaux

  • Test, validation et archivage du code mis à jour

Rôle des diagrammes d'architecture et de modélisation dans le développement de logiciels

Le tableau suivant décrit le rôle que ces outils peuvent jouer à différentes étapes du cycle de vie de développement de logiciels :

Modélisation des besoins des utilisateurs

Modélisation des processus d'entreprise

Architecture et conception du système

Visualisation et exploration du code

Vérification

Diagramme de cas d'usage (UML)

√

√

√

Diagramme d'activités (UML)

√

√

√

√

Diagramme de classes (UML)

√

√

√

√

Diagramme de composant (UML)

√

√

√

√

Diagramme de séquence (UML)

√

√

√

√

Diagramme de langage spécifique à un domaine (DSL)

√

√

√

Diagramme de couche, validation de couche

√

√

√

Graphique de dépendance (basé sur du code)

√

√

√

Diagramme de séquence (basé sur du code)

√

√

Concepteur de classes (basé sur du code)

√

Navigateur de l'architecture

√

Pour dessiner des diagrammes UML et des diagrammes de couche, vous devez créer un projet de modélisation dans le cadre d'une solution existante ou dans un nouveau projet. Ces diagrammes doivent être créés dans le projet de modélisation. Les éléments des diagrammes UML font partie d'un modèle commun, dont les diagrammes UML constituent des vues. Les éléments des diagrammes de couche se trouvent dans le projet de modélisation, mais ne sont pas stockés dans le modèle commun. Les graphiques de dépendance basés sur du code, les diagrammes de séquence et les diagrammes de classes existent habituellement en dehors du projet de modélisation.

Reportez-vous à :

Pour afficher d'autres vues de l'architecture, vous pouvez réutiliser certains éléments du même modèle dans plusieurs diagrammes à la fois ou dans des diagrammes différents. Vous pouvez, par exemple, faire glisser un composant vers un autre diagramme de composant ou vers un diagramme de séquence, afin qu'il puisse fonctionner comme un acteur. Consultez Modifier des modèles et des diagrammes UML.

Les deux équipes utilisent également la validation de couche pour s'assurer que le code en cours de développement demeure cohérent avec la conception.

Reportez-vous à :

  • Maintien d'une cohérence entre le code et la conception

  • Décrire l'architecture logique : les diagrammes de couche

  • Valider du code avec des diagrammes de couche

    Notes

    Visual Studio Premium prend en charge la validation de couche et les versions en lecture seule de ces graphiques et diagrammes pour la visualisation et la modélisation.

Compréhension et communication des informations relatives au système

Il n'existe pas d'ordre prescrit pour l'utilisation des diagrammes de modélisation Visual Studio Ultimate, par conséquent, vous pouvez les utiliser en fonction de vos besoins ou de votre approche. Habituellement, les équipes revisitent fréquemment leurs modèles durant un projet. Chaque diagramme propose des avantages propres qui vous aident à comprendre, décrire et communiquer différents aspects du système en cours de développement.

Dinner Now et Lucerne communiquent l'une avec l'autre, ainsi qu'avec les parties prenantes au projet, au moyen de diagrammes utilisés comme un langage commun. Par exemple, Dinner Now utilise des diagrammes pour accomplir les tâches suivantes :

  • Visualiser le code existant.

  • Communiquer avec Lucerne à propos des récits utilisateur nouveaux ou mis à jour.

  • Identifier les modifications nécessaires pour la prise en charge des récits utilisateur nouveaux ou mis à jour.

Lucerne utilise des diagrammes pour accomplir les tâches suivantes :

  • En savoir plus sur le processus d'entreprise de Dinner Now.

  • Comprendre la conception du système.

  • Communiquer avec Dinner Now à propos des besoins utilisateurs nouveaux ou mis à jour.

  • Documenter les mises à jour du système.

Les diagrammes sont intégrés à Team Foundation Server pour permettre aux équipes de planifier, de gérer et de suivre leur travail plus facilement. Par exemple, ils utilisent des modèles pour identifier des cas de test et des tâches de développement et estimer leur travail. Lucerne lie les éléments de travail Team Foundation Server à des éléments de modèle, afin de pouvoir surveiller leur progression et s'assurer que le système réponde aux besoins des utilisateurs. Par exemple, ils lient des cas d'usage à des éléments de travail de cas de test, ce qui leur permettra de voir si les cas d'usage sont respectés en cas de réussite de tous les tests.

Avant d'archiver leurs modifications, les équipes valident le code à l'aide de tests et par rapport à la conception, en exécutant des builds comprenant la validation de couche et des tests automatisés. Cela permet de s'assurer que le code mis à jour n'est pas en conflit avec la conception, et qu'il ne va pas corrompre des fonctionnalités qui précédemment, fonctionnaient correctement.

Reportez-vous à :

  • Comprendre le rôle du système dans le processus d'entreprise

  • Description des besoins utilisateurs nouveaux ou mis à jour

  • Création de tests à partir de modèles

  • Identification des modifications apportées à un système existant

  • Maintien d'une cohérence entre le code et la conception

  • Conseils d'ordre général pour la création et l'utilisation de modèles

  • Planification et suivi des travaux

  • Test, validation et archivage du code mis à jour

Comprendre le rôle du système dans le processus d'entreprise

Lucerne souhaite en savoir plus sur le processus d'entreprise de Dinner Now. Ils créent les diagrammes suivants pour améliorer leur compréhension de Dinner Now :

Schéma

Décrit

Diagramme de cas d'usage (UML)

Reportez-vous à :

  • Les activités prises en charge par le système de Dinner Now

  • Les personnes et systèmes externes qui réalisent ces activités

  • Les principaux composants du système prenant en charge chaque activité

  • Les aspects du processus d'entreprise qui sont hors des limites du système actuel, tels que la livraison des repas

Diagramme d'activités (UML)

Reportez-vous à :

Les étapes consécutives à la commande d'un client

Diagramme de classes (UML)

Reportez-vous à :

Les entités métier et les termes utilisés dans la discussion, ainsi que les relations entre ces entités. Par exemple, les termes Commande et Menu font partie du vocabulaire de ce scénario.

Lucerne crée, par exemple, le diagramme de cas d'usage suivant, pour connaître les tâches effectuées sur le site Web Dinner Now, ainsi que les personnes qui les exécutent :

Diagramme de cas d'usage UML

Diagramme de cas d'usage UML

Le diagramme d'activités suivant décrit les étapes consécutives à la commande d'un client sur le site Web de Dinner Now. Dans cette version finale, les éléments de commentaire identifient les rôles, et les lignes créent des couloirs, qui permettent de classer les étapes en fonction de leur rôle :

Diagramme d'activités UML

Diagramme d'activités UML

Le diagramme de classes suivant décrit les entités qui participent au processus de commande :

Diagramme de classes UML

Diagramme de classes UML

Description des besoins utilisateurs nouveaux ou mis à jour

Lucerne souhaite ajouter des fonctionnalités au système de Dinner Now, afin que les clients puissent donner leur avis sur des restaurants et consulter celui des autres. Ils mettent à jour les diagrammes suivants afin de pouvoir décrire et discuter de cette nouvelle spécification avec Dinner Now :

Schéma

Décrit

Diagramme de cas d'usage (UML)

Reportez-vous à :

Un nouveau cas d'usage pour « Donner un avis sur un restaurant »

Diagramme d'activités (UML)

Reportez-vous à :

Les étapes consécutives à l'envoi de l'avis d'un client sur un restaurant

Diagramme de classes (UML)

Reportez-vous à :

Données nécessaires au stockage d'un avis

Par exemple, le diagramme de cas d'usage suivant inclut le nouveau cas d'usage « Donner un avis » pour représenter la nouvelle spécification. Il est surligné en orange sur le diagramme pour être plus facilement identifiable :

Diagramme de cas d'usage UML

Diagramme de cas d'usage UML

Le diagramme d'activités suivant inclut de nouveaux éléments en orange décrivant les étapes du nouveau cas d'usage :

Diagramme d'activités UML

Diagramme d'activités UML

Le diagramme de classes suivant inclut la nouvelle classe Avis et ses relations aux autres classes, afin que les équipes puissent en discuter en détail. Remarquez qu'un Client et un Restaurant peuvent avoir plusieurs Avis :

Diagramme de classes UML

Diagramme de classes UML

Création de tests à partir de modèles

Les deux équipes sont d'accord sur le fait qu'elles ont besoin d'un ensemble complet de tests pour le système et ses composants, avant de procéder à toute modification. Lucerne dispose d'une équipe spécialisée qui effectue des tests au niveau du système et des composants. Ils réutilisent les tests créés par Dinner Now et structurent ces tests à l'aide de diagrammes UML :

  • Chaque cas d'usage est représenté par un ou plusieurs tests. Les éléments du diagramme de cas d'usage sont liés aux éléments de travail de cas de test dans Team Foundation Server.

  • Chaque flux du diagramme d'activités ou du diagramme de séquence au niveau du système est au minimum lié à un test. L'équipe de test s'assure systématiquement de tester chaque chemin d'accès possible via le diagramme d'activités.

  • Les termes utilisés pour décrire les tests sont basés sur les termes définis par les diagrammes de cas d'usage, de classes et d'activités.

Lorsque les spécifications sont modifiées et les diagrammes mis à jour pour refléter ces modifications, les tests sont également mis à jour. Une spécification est considérée comme respectée uniquement en cas de réussite des tests. Lorsque cela se révèle possible ou pratique, les tests sont définis et basés sur des diagrammes UML avant le début de l'implémentation.

Reportez-vous à :

Identification des modifications apportées à un système existant

Dinner Now doit estimer les coûts liés à la mise en conformité à la nouvelle spécification. Cela dépend en partie de l'impact de cette modification sur les autres parties du système. Pour les aider à le comprendre, l'un des développeurs de Dinner Now crée les graphiques et les diagrammes suivants à partir de code existant :

Graphique ou diagramme

Affiche

Graphique de dépendance

Reportez-vous à :

Dépendances et autres relations du code.

Par exemple, Dinner Now peut commencer par examiner les graphiques de dépendance d'assembly pour obtenir une vue d'ensemble des assemblys et de leurs dépendances. Ils peuvent examiner plus en profondeur les graphiques pour explorer les espaces de noms et les classes de ces assemblys.

Dinner Now peut également créer des graphiques pour explorer des zones particulières, ainsi que d'autres genres de relations du code. Ils utilisent le Navigateur d'architecture ou l'Explorateur de solutions pour rechercher et sélectionner les zones et les relations qui les intéressent.

Diagramme de séquence basé sur du code

Consultez Visualiser du code dans des diagrammes de séquence.

Séquence d'interactions entre instances.

Les diagrammes de séquence sont générés à partir de définitions de méthode et permettent de mieux comprendre la façon dont le code implémente le comportement de la méthode.

Diagramme de classes basé sur du code

Consultez Comment : ajouter des diagrammes de classes aux projets (Concepteur de classes).

Les classes existantes du code.

Par exemple, le développeur utilise le navigateur de l'architecture pour sélectionner les espaces de noms sur lesquels elles souhaite se concentrer et crée un graphique de dépendance de code. Il ajuste sa portée pour se concentrer sur les zones qui seront affectées par le nouveau scénario. Ces zones sont sélectionnées et mises en surbrillance sur le graphique :

Graphique de dépendance d'espace de noms

Graphique de dépendance d'espace de noms

Le développeur développe les espaces de noms sélectionnés pour consulter leurs classes, méthodes et relations :

Graphique de dépendance d'espace de noms développé

Graphique de dépendance d'espace de noms développé, avec les liens entre groupes visibles

Le développeur examine le code à la recherche des classes et méthodes affectées. Il génère des diagrammes de séquence et des diagrammes de classes à partir du code pour décrire et discuter des modifications. Consultez Visualiser du code.

Conseil

Pour connaître les effets de chaque modification au fur et à mesure que vous les apportez, regénérez des graphiques de dépendance et des diagrammes de séquence à partir du code, après chaque modification.

Pour décrire les modifications apportées à d'autres parties du système, telles que les composants ou les interactions, l'équipe peut les dessiner sur des tableaux blancs. Elle peut également dessiner les diagrammes suivants dans Visual Studio, afin que les détails puissent être capturés, gérés et compris par les deux équipes :

Diagrammes

Décrit

Diagramme d'activités (UML)

Reportez-vous à :

Les étapes consécutives au passage d'une nouvelle commande par un client auprès d'un restaurant, après invitation du client à donner son avis sur le restaurant.

Diagramme de classes (UML)

Reportez-vous à :

Les classes logiques et leurs relations. Par exemple, une nouvelle classe est ajoutée pour décrire un Avis et ses relations aux autres entités, telles que le Restaurant, le Menu et le Client.

Pour associer des avis à un client, le système doit stocker les informations relatives au client. Un diagramme de classes UML peut vous aider à clarifier ces informations.

Diagramme de classes basé sur du code

Consultez Comment : ajouter des diagrammes de classes aux projets (Concepteur de classes).

Les classes existantes du code.

Diagramme de composant (UML)

Reportez-vous à :

Les parties de haut niveau du système, telles que le site Web de Dinner Now, et leur interface. Ces interfaces définissent la façon dont les composants interagissent via les méthodes ou services qu'ils fournissent et consomment.

Diagramme de séquence (UML)

Reportez-vous à :

La séquence d'interactions entre instances.

Par exemple, le diagramme de composant suivant montre le nouveau composant, qui constitue une partie du composant du site Web de Dinner Now. Le composant ReviewProcessing gère la fonctionnalité de création des avis et apparaît surligné en orange :

Diagramme de composant UML

Diagramme de composant UML

Le diagramme de séquence suivant montre la séquence des interactions qui se produisent lorsque le site Web de Dinner Now vérifie si le client a déjà commandé auprès de ce restaurant auparavant. Si c'est le cas, il demande au client de donner un avis, qui est alors envoyé au restaurant, puis publié par le site Web :

Diagramme de séquence UML

Diagramme de séquence UML

Maintien d'une cohérence entre le code et la conception

Dinner Now doit s'assurer que le code mis à jour demeure cohérent avec la conception. Ils créent des diagrammes de couche qui décrivent les couches de fonctionnalités du système, spécifient les dépendances autorisées entre ces couches et associent les artefacts de la solution à ces couches.

Schéma

Décrit

Diagramme de couche

Reportez-vous à :

L'architecture logique du code.

Un diagramme de couche organise et mappe les artefacts d'une solution Visual Studio, afin de rendre abstraits des groupes appelés couches. Ces couches identifient les rôles, tâches ou fonctions des artefacts dans le système.

Les diagrammes de couche permettent de décrire la conception prévue du système et de valider le code en cours de développement par rapport à cette conception.

Pour créer des couches, faites glisser des éléments depuis l'Explorateur de solutions, les graphiques de dépendance ou le navigateur de l'architecture. Pour dessiner de nouvelles couches, utilisez la boîte à outils ou cliquez avec le bouton droit sur la surface du diagramme.

Pour afficher les dépendances existantes, cliquez avec le bouton droit sur la surface du diagramme de couche, puis cliquez sur Générer des dépendances. Pour spécifier des dépendances prévues, dessinez de nouvelles dépendances.

Par exemple, le diagramme de couche suivant montre les dépendances entre les couches, ainsi que le nombre d'artefacts associés à chaque couche :

Diagramme de couche du système de paiement intégré

Diagramme de couches

Pour éviter tout conflit avec la conception durant le développement du code, les équipes utilisent la validation de couche sur les builds exécutées sur Team Foundation Build. Elles créent également une tâche MSBuild personnalisée pour exiger la validation de couche lors des opérations d'archivage. Elles utilisent les rapports de build pour collecter les erreurs liées à la validation.

Reportez-vous à :

Conseils d'ordre général pour la création et l'utilisation de modèles

  • La plupart des diagrammes sont constitués de nœuds connectés par des lignes. Pour chaque type de diagramme, la boîte à outils fournit différents genres de nœuds et de lignes.

    Pour ouvrir la boîte à outils, dans le menu Affichage, cliquez sur Boîte à outils.

  • Pour créer un nœud, faites-le glisser de la boîte à outils vers le diagramme. Certains genres de nœuds doivent être glissés vers des nœuds existants. Par exemple, sur un diagramme de composant, un nouveau port doit être ajouté à un composant existant.

  • Pour créer une ligne ou une connexion, cliquez sur l'outil approprié de la boîte à outils, cliquez sur le nœud source, puis sur le nœud cible. Certaines lignes peuvent être créées uniquement entre certains genres de nœuds. Lorsque vous déplacez le pointeur sur une source ou une cible possible, le pointeur indique si une connexion est possible.

  • Lorsque vous créez des éléments dans des diagrammes UML, ils sont également ajoutés à un modèle commun. Les diagrammes UML d'un projet de modélisation constituent des vues de ce modèle. Les éléments d'un diagramme de couche font partie du projet de modélisation, bien que n'étant pas stockés dans le modèle commun.

    Pour voir le modèle, dans le menu Architecture, pointez sur Fenêtres, puis cliquez sur l'Explorateur de modèles UML.

  • Dans certains cas, vous pouvez faire glisser certains éléments depuis l'Explorateur de modèles UML vers un diagramme UML. Certains éléments d'un même modèle peuvent être utilisés dans plusieurs diagrammes à la fois ou dans différents diagrammes, afin de montrer différentes vues de l'architecture. Par exemple, vous pouvez faire glisser un composant vers un autre diagramme de composant ou vers un diagramme de séquence à utiliser comme un acteur.

  • Visual Studio Ultimate prend en charge UML 2.1.2. Cette vue d'ensemble décrit uniquement les principales fonctionnalités des diagrammes UML de cette version finale. Il existe cependant de nombreux ouvrages abordant en détail le langage UML et son utilisation.

Consultez Développement de modèles pour la conception logicielle.

Planification et suivi des travaux

Les diagrammes de modélisation de Visual Studio Ultimate sont intégrés à Team Foundation Server afin de faciliter la planification, la gestion et le suivi du travail. Les deux équipes utilisent des modèles pour identifier des cas de test et des tâches de développement afin d'estimer leur travail. Lucerne crée et lie des éléments de travail Team Foundation Server à des éléments de modèle, tels que des cas d'usage ou des composants. Cela leur permet de surveiller leur progression et de faire le suivi des travaux, en remontant jusqu'aux spécifications des utilisateurs. Cela les aide également à s'assurer que leurs modifications soient toujours conformes aux spécifications.

À mesure que leur travail progresse, les équipes mettent à jour leurs éléments de travail pour refléter le temps qu'elles ont passé à ces tâches. Elles surveillent et signalent l'état des travaux à l'aide des fonctionnalités Team Foundation Server suivantes :

  • Des rapports d'avancement quotidiens qui montrent si le travail planifié sera terminé à la date prévue. Elles créent d'autres rapports semblables depuis Team Foundation Server pour suivre la progression des bogues.

  • Une feuille de calcul d'itération qui utilise Microsoft Excel pour permettre à l'équipe de surveiller et de répartir la charge de travail entre ses membres. Cette feuille de calcul est liée à Team Foundation Server et fournit le thème de discussion des réunions d'avancement.

  • Un tableau de bord de développement qui utilise Office Project pour que l'équipe reste informée des détails importants du projet.

Reportez-vous à :

Test, validation et archivage du code

Lorsque les équipes terminent chaque tâche, elles vérifient leur code dans le contrôle de version Team Foundation et reçoivent des rappels de Team Foundation Server en cas d'oubli. Avant que Team Foundation Server n'accepte leur archivage, les équipes effectuent les tests unitaires et la validation de couche pour vérifier le code par rapport aux cas de test et à la conception. Elles utilisent Team Foundation Server pour exécuter régulièrement des générations, des tests unitaires automatisés et une validation de couche. Cela permet de s'assurer que le code :

  • fonctionne ;

  • ne corrompt pas du code qui fonctionnait précédemment ;

  • n'est pas en conflit avec la conception.

Dinner Now possède une importante collection de tests automatisés, dont Lucerne peut réutiliser la quasi totalité car ils s'appliquent également à leur activité. Lucerne peut également améliorer ces tests et en ajouter de nouveaux pour couvrir de nouvelles fonctionnalités. Les deux utilisent également Visual Studio Ultimate pour exécuter des tests manuels.

Pour garantir que le code est conforme à la conception, les équipes configurent leurs builds dans Team Foundation Build pour inclure la validation de couche. En cas de conflit, un rapport est généré avec les détails.

Reportez-vous à :

Mise à jour du système à l'aide de la visualisation et de la modélisation

Lucerne et Dinner Now doivent fusionner leurs systèmes de paiement. Les sections suivantes montrent comment les diagrammes de modélisation dans Visual Studio Ultimate les aident à accomplir cette tâche :

  • Comprendre les besoins des utilisateurs : les diagrammes de cas d'usage

  • Comprendre le processus d'entreprise : les diagrammes d'activités

  • Décrire la structure du système : les diagrammes de composant

  • Décrire les interactions : les diagrammes de séquence

  • Visualiser le code existant : les graphiques de dépendance

  • Définir un glossaire de types : les diagrammes de classes

  • Décrire l'architecture logique : les diagrammes de couche

Reportez-vous à :

Comprendre les besoins des utilisateurs : les diagrammes de cas d'usage

Les diagrammes de cas d'usage résument les activités prises en charge par un système, ainsi que les personnes qui entreprennent ces activités. Lucerne utilise un diagramme de cas d'usage pour connaître ce qui suit au sujet du système de Dinner Now :

  • Les clients qui passent des commandes.

  • Les restaurants qui reçoivent des commandes.

  • La passerelle de traitement des paiements externes, que le système de paiement de Dinner Now utilise pour valider les paiements, est hors de portée du site Web.

Le diagramme montre également comment certains des principaux cas d'usage sont divisés en cas d'usage plus petits. Lucerne souhaite utiliser son propre système de paiement. Le cas d'usage Traiter le paiement est signalé dans une couleur différente pour indiquer qu'il requiert des modifications :

Mise en surbrillance du cas d'usage Traiter le paiement sur un diagramme de cas d'usage

Mise en surbrillance du cas d'usage Traiter le paiement sur le diagramme de cas d'usage

Si la durée du développement a été restreinte, l'équipe peut discuter de l'éventualité de permettre aux clients de payer directement au restaurant. Pour cela, elle remplacerait le cas d'usage Traiter le paiement par un cas d'usage situé en dehors des limites du système Dinner Now. Elle lierait ensuite directement le Client au Restaurant, en indiquant que Dinner Now traiterait uniquement les commandes suivantes :

Redéfinition de la portée du cas d'usage Payer le restaurant sur le diagramme de cas d'usage

Redéfinition de la portée du cas d'usage Payer le restaurant sur le diagramme de cas d'usage

Reportez-vous à :

Dessin d'un diagramme de cas d'usage

Un diagramme de cas d'usage possède les principales fonctionnalités suivantes :

  • Les acteurs représentent les rôles joués par des personnes, des organisations, des ordinateurs ou des systèmes logiciels. Par exemple, le Client, le Restaurant et le Système de paiement de Dinner Now sont des acteurs.

  • Les cas d'usage représentent les interactions entre les acteurs et le système en cours de développement. Il peut s'agir de tout niveau d'interaction, depuis un clic de souris ou un message unique, à une transaction étendue sur plusieurs jours.

  • Les associations lient les acteurs aux cas d'usage.

  • Un cas d'usage de taille importante peut inclure des cas d'usage plus petits. Par exemple, Passer une commande inclut Sélectionner un restaurant. Vous pouvez étendre un cas d'usage, en lui ajoutant des objectifs et des étapes, afin d'indiquer que le cas d'usage doit se produire uniquement sous certaines conditions. Les cas d'usage peuvent également hériter l'un de l'autre.

  • Un sous-système représente le système logiciel en cours de développement ou l'un de ses composants. Il s'agit d'une grande boîte qui contient des cas d'usage. Un diagramme de cas d'usage permet de déterminer ce qui se trouve à l'intérieur ou hors des limites du sous-système. Pour indiquer que l'utilisateur doit accomplir certains objectifs d'une autre façon, dessinez ces cas d'usage en dehors des limites du sous-système.

  • Les artefacts lient les éléments d'un diagramme à d'autres diagrammes ou documents.

Reportez-vous à :

Résumé : avantages des diagrammes de cas d'usage

Les diagrammes de cas d'usage vous aident à visualiser :

  • Les activités prises ou non en charge par le système.

  • Les personnes et systèmes externes qui réalisent ces activités.

  • Les principaux composants du système qui prennent en charge chaque activité, et que vous pouvez représenter en tant que sous-systèmes imbriqués au sein d'un système parent.

  • La façon dont un cas d'usage peut être divisé en cas d'usage plus petits ou en variantes.

Relation aux autres diagrammes

Schéma

Décrit

Diagramme d'activités

Les étapes d'un cas d'usage et les personnes qui y procèdent.

Le nom des cas d'usage reflète souvent les étapes d'un diagramme d'activités. Les diagrammes d'activités prennent en charge les éléments tels que les décisions, les fusions, les entrées et sorties, les flux simultanés, etc.

Reportez-vous à :

Diagramme de séquence

La séquence d'interactions entre les participants dans un cas d'usage.

Reportez-vous à :

Diagramme de classes (UML)

Les entités ou les types qui participent au cas d'usage.

Reportez-vous à :

Comprendre le processus d'entreprise : les diagrammes d'activités

Les diagrammes d'activités décrivent les étapes d'un processus d'entreprise et constituent un moyen facile de communiquer le flux de travail. Un projet de développement peut avoir plusieurs diagrammes d'activités. Habituellement, une activité comprend toutes les actions qui résultent d'une action externe, telle que la commande d'un repas, la mise à jour d'un menu ou l'ajout d'un nouveau restaurant. Une activité peut également décrire les détails d'une action complexe.

Lucerne met à jour le diagramme d'activités suivant pour montrer que Lucerne traite le paiement et paie le restaurant. Ils remplacent le système de paiement de Dinner Now par le système de paiement de Lucerne, comme le montre le diagramme ci-dessous :

Système de paiement Lucerne sur le diagramme d'activités

Remplacement du système de paiement de Dinner Now sur le diagramme d'activités

Le diagramme mis à jour aide Lucerne et Dinner Now à visualiser où le système de paiement de Lucerne s'intègre au processus d'entreprise. Dans cette version finale, les commentaires sont utilisés pour identifier les rôles qui exécutent les étapes. Les lignes sont utilisées pour créer des couloirs, qui permettent d'organiser les étapes en fonction des rôles.

Les équipes peuvent également envisager un récit différent, dans lequel le client paie le restaurant à la livraison du repas. Le système logiciel aurait, dans ce cas, des spécifications différentes.

Précédemment, Dinner Now dessinait ces diagrammes sur un tableau blanc ou dans PowerPoint. Ils utilisent également Visual Studio Ultimate pour dessiner ces diagrammes, afin que les deux équipes puissent capturer, comprendre et gérer les détails.

Reportez-vous à :

Dessin d'un diagramme d'activités

Un diagramme d'activités possède les principales fonctionnalités suivantes :

  • Un nœud initial indiquant la première action de l'activité.

    Le diagramme doit toujours avoir l'un de ces nœuds.

  • Les actions qui décrivent les étapes durant lesquelles une tâche est accomplie par un utilisateur ou un logiciel.

  • Les flux de contrôle qui montrent les transitions entre chaque action.

  • Les nœuds de décision qui représentent les branches conditionnelles d'un flux.

  • Les nœuds de bifurcation qui divisent les flux uniques en flux simultanés.

  • Les nœuds finaux d'activité qui montrent les terminaisons d'une activité.

    Ces nœuds sont facultatifs, cependant il est utile de les inclure dans un diagramme pour montrer où l'activité se termine.

Reportez-vous à :

Résumé : avantages des diagrammes d'activités

Les diagrammes d'activités vous permettent de visualiser et de décrire le flux de contrôle et les informations en rapport avec les actions d'une entreprise, d'un système ou d'un programme. Il s'agit d'une méthode simple et utile permettant de décrire le flux de travail dans le cadre d'une communication avec d'autres personnes.

Relation aux autres diagrammes

Schéma

Description

Diagramme de cas d'usage

Résumer les activités réalisées par chaque acteur.

Reportez-vous à :

Diagramme de composant

Visualiser le système comme une collection de parties réutilisables, qui fournissent ou consomment le comportement via un ensemble bien défini d'interfaces.

Reportez-vous à :

Décrire la structure du système : les diagrammes de composant

Les diagrammes de composant décrivent un système comme une collection de parties séparables, qui fournissent ou consomment le comportement via un ensemble bien défini d'interfaces. Ces parties peuvent être à n'importe quelle échelle et être connectées de n'importe quelle façon.

Pour mieux visualiser et discuter des composants du système et de leur interface, Lucerne et Dinner Now créent les diagrammes de composant suivants :

Composants externes au système de paiement

Composants du système de paiement de Dinner Now

Ce diagramme montre les différents types de composants et leurs dépendances. Par exemple, le site Web de Dinner Now et le système de paiement de Lucerne requièrent tous deux la passerelle de traitement des paiements externes pour valider les paiements. Les flèches situées entre les composants représentent les dépendances indiquant les composants qui nécessitent les fonctionnalités d'autres composants.

Pour utiliser le système de paiement de Lucerne, le site Web Dinner Now doit être mis à jour, afin d'utiliser les interfaces PaymentApproval et PayableInsertion du système de paiement de Lucerne.

Le diagramme suivant montre une configuration spécifique de composants pour le site Web de Dinner Now. Cette configuration indique que toute instance du site Web consiste en quatre parties :

  • CustomerProcessing

  • OrderProcessing

  • ReviewProcessing

  • PaymentProcessing

Ces parties sont des instances des types de composants spécifiés, et sont connectées de la façon suivante :

Composants présents dans le site web Dinner Now

Composants à l'intérieur du site Web de Dinner Now

Le site Web de Dinner Now délègue son comportement à ces parties, qui gèrent alors les fonctions du site Web. Les flèches situées entre le composant parent et ses composants membres montrent les délégations qui indiquent quelles parties gèrent les messages que le parent reçoit ou envoie via ses interfaces.

Dans cette configuration, le composant PaymentProcessing traite les paiements des clients. Par conséquent, il doit être mis à jour en vue d'être intégré au système de paiement de Lucerne. Dans d'autres scénarios, plusieurs instances d'un type de composant peuvent exister au sein d'un même composant parent.

Reportez-vous à :

Dessin d'un diagramme de composant

Un diagramme de composant possède les principales fonctionnalités suivantes :

  • Les composants qui représentent des morceaux séparables d'une fonctionnalité du système.

  • Les ports d'interface fournis qui représentent des groupes de messages ou d'appels, dont les composants implémentent et sont utilisés par les autres composants ou systèmes externes.

  • Les ports d'interface requis qui représentent des groupes de messages ou d'appels, dont les composants sont envoyés aux autres composants ou systèmes externes. Ce genre de port décrit les opérations qu'un composant attend au minimum d'autres composants ou systèmes externes.

  • Les parties sont des membres de composants et sont en général des instances d'autres composants. Une partie est un morceau d'une conception interne d'un composant parent.

  • Les dépendances qui indiquent les composants qui requièrent les fonctionnalités d'autres composants.

  • Les délégations qui indiquent les parties d'un composant qui gèrent les messages envoyés ou reçus par le composant parent.

Reportez-vous à :

Résumé : avantages des diagrammes de composant

Les diagrammes de composant vous aident à visualiser :

  • Le système comme une collection de parties séparables, indépendamment de leur langage d'implémentation ou de leur style.

  • Les composants avec une interface bien définie, qui facilite la compréhension et la mise à jour de la conception, en cas de modification des spécifications.

Relation aux autres diagrammes

Schéma

Description

Graphique de dépendance

Visualiser l'organisation et les relations dans du code existant.

Pour identifier des candidats pour les composants, créez un graphique de dépendance et regroupez les éléments selon leur fonction dans le système.

Reportez-vous à :

Diagramme de séquence

Visualiser la séquence d'interactions entre composants ou les parties d'un composant.

Pour créer une ligne de vie dans un diagramme de séquence à partir d'un composant, cliquez avec le bouton droit sur le composant, puis cliquez sur Créer la ligne de vie.

Reportez-vous à :

Diagramme de classes (UML)

Définir les interfaces sur les ports fournis ou requis, ainsi que les classes qui implémentent les fonctionnalités des composants.

Reportez-vous à :

Diagramme de couche

Décrire l'architecture logique du système par rapport aux composants. Utilisez la validation de couche pour vous assurer que le code demeure cohérent avec la conception.

Reportez-vous à :

Diagramme d'activités

Visualiser le traitement interne exécuté par les composants, en réponse à des messages entrants.

Reportez-vous à :

Visualiser le code existant : les graphiques de dépendance

Les graphiques de dépendance montrent l'organisation actuelle et les relations du code. Les éléments sont représentés par des nœuds sur le graphique, et les relations sont représentées par des liens. Les graphiques de dépendance peuvent vous aider à accomplir les genres de tâches suivants :

  • Explorer du code inconnu.

  • Comprendre où et comment une modification suggérée peut affecter le code existant.

  • Rechercher des zones de complexité, des couches ou des modèles naturels, ou d'autres zones pouvant bénéficier de cette amélioration.

Par exemple, Dinner Now doit estimer le coût de la mise à jour du composant PaymentProcessing. Cela dépend en partie de l'impact de cette modification sur les autres parties du système. Pour les aider à comprendre cela, l'un des développeurs de Dinner Now génère des graphiques de dépendance à partir du code et concentre la portée sur les zones pouvant être affectées par la modification.

Le graphique suivant montre les dépendances entre la classe PaymentProcessing et d'autres parties du système Dinner Now, qui apparaissent de la façon suivante :

Graphique de dépendance pour le système de paiement Dinner Now

Graphique de dépendance pour le système de paiement de Dinner Now

Le développeur explore le graphique en développant la classe PaymentProcessing et en sélectionnant ses membres pour voir les zones susceptibles d'être affectées :

Méthodes dans PaymentProcessing et dépendances

Méthodes à l'intérieur de la classe PaymentProcessing et leurs dépendances

Ils génèrent le graphique suivant pour le système de paiement de Lucerne, afin d'inspecter ses classes, méthodes et dépendances. L'équipe y voit que le système de Lucerne peut également nécessiter un certain travail afin de permettre son interaction avec les autres parties du système Dinner Now :

Graphique de dépendance pour le système de paiement Lucerne

Graphique de dépendance du système de paiement de Lucerne

Les deux équipes collaborent pour déterminer les modifications nécessaires à la fusion des deux systèmes. Elles décident de refactoriser une partie du code afin qu'il soit plus facile à mettre à jour. La classe PaymentApprover sera déplacée vers l'espace de noms DinnerNow.Business et nécessitera de nouvelles méthodes. Les classes Dinner Now qui gèrent les transactions auront leur propre espace de noms. Les équipes créent et utilisent des éléments de travail pour planifier, organiser et réaliser le suivi de leur travail. Elles lient les éléments de travail aux éléments de modèle lorsque cela se révèle utile.

Après avoir réorganisé le code, les équipes génèrent un nouveau graphique de dépendance pour voir la structure et les relations mises à jour :

Graphique de dépendance avec code réorganisé

Graphique de dépendance après réorganisation du code

Ce graphique montre que la classe PaymentApprover se trouve maintenant dans l'espace de noms DinnerNow.Business et possède de nouvelles méthodes. Les classes de transaction Dinner Now ont maintenant leur propre espace de noms PaymentSystem, ce qui simplifie la gestion ultérieure du code.

Création d'un graphique de dépendance

Résumé : avantages des graphiques de dépendance

Les graphiques de dépendance vous aident à :

  • Connaître l'organisation et les relations du code existant.

  • Identifier les zones pouvant être affectées par une suggestion de modification.

  • Rechercher des zones de complexité, des modèles, des couches ou d'autres zones que vous pourriez améliorer pour simplifier la maintenance, la modification et la réutilisation du code.

Relation aux autres diagrammes

Schéma

Décrit

Diagramme de couche

L'architecture logique du système. Utilisez la validation de couche pour vous assurer que le code demeure cohérent avec la conception.

Pour identifier plus facilement les couches existantes ou les couches prévues, créez un graphique de dépendance et regroupez les éléments connexes. Pour créer un diagramme de couche, faites glisser les éléments depuis un graphique ou depuis le navigateur d'architecture.

Reportez-vous à :

Diagramme de composant

Les composants, leurs interfaces et leurs relations.

Pour faciliter l'identification des composants, créez un graphique de dépendance et regroupez les éléments selon leur fonction dans le système.

Reportez-vous à :

Diagramme de classes (UML)

Les classes, leurs attributs, leurs opérations et leurs relations.

Pour faciliter l'identification de ces éléments, créez un document de graphique montrant ces éléments.

Reportez-vous à :

Diagramme de classes (basé sur du code)

Les classes existantes du code.

Pour visualiser et modifier une classe existante du code, utilisez le Concepteur de classes.

Consultez Comment : ajouter des diagrammes de classes aux projets (Concepteur de classes).

Décrire les interactions : les diagrammes de séquence

Les diagrammes de séquence montrent une série d'interactions entre les différentes parties d'un système. Les parties peuvent être à n'importe quelle échelle. Il peut s'agir d'objets d'un programme comme de grands sous-systèmes ou acteurs externes. Les interactions peuvent être de tout type et à n'importe quelle échelle. Cela peut aller d'un simple message à une transaction étendue. Il peut également s'agir d'appels de fonction ou de messages de service Web.

Pour faciliter la description et la discussion des étapes relatives au cas d'usage Traiter le paiement, Lucerne et Dinner Now créent le diagramme de séquence ci-dessous, à partir du diagramme de composant. Les lignes de vie reflètent le composant du site Web de Dinner Now et les parties qui le constituent. Les messages apparaissant entre les lignes de vie suivent les connexions des diagrammes de composant :

Diagramme de séquence pour le cas d'usage Traiter le paiement

Diagramme de séquence pour le cas d'usage Traiter le paiement

Le diagramme de séquence montre que lorsque le client passe une commande, le site Web de Dinner Now appelle ProcessOrder sur une instance d'OrderProcessing. Ensuite, OrderProcessing appelle ProcessPayment sur PaymentProcessing. Cela continue jusqu'à ce que la passerelle de traitement des paiements externes valide le paiement. Après la validation, le contrôle est enfin retourné au site Web de Dinner Now.

Lucerne doit estimer le coût de la mise à jour de son système de paiement, en vue de son intégration au système de Dinner Now. Pour mieux comprendre ce processus, l'un de leurs développeurs génère des diagrammes de séquence à partir du code, afin de visualiser les interactions existantes.

Reportez-vous à :

Dessin d'un diagramme de séquence

Un diagramme de séquence possède les principales fonctionnalités suivantes :

  • Les lignes de vie verticales représentent les acteurs ou les instances d'objets d'un logiciel.

    Pour ajouter un symbole d'acteur, qui indique qu'un participant se trouve en dehors du système en cours de développement, cliquez sur la ligne de vie. Dans la fenêtre Propriétés, attribuez la valeur True à Acteur : Si la fenêtre Propriétés n'est pas ouverte, appuyez sur F4.

  • Les messages horizontaux représentent des appels de méthode, des messages de service Web ou tout autre type de communication. Les occurrences d'exécution sont des rectangles grisés verticaux présents sur les lignes de vie, qui représentent les périodes durant lesquelles les objets de réception traitent les appels.

  • Durant un message synchrone, l'objet expéditeur attend que le contrôle soit <<return>> comme dans un appel de fonction normal. Durant un message asynchrone, l'expéditeur peut poursuivre immédiatement.

  • Utilisez les messages <<create>> pour indiquer la construction d'objets par d'autres objets. Il doit s'agir du premier message envoyé à l'objet.

Reportez-vous à :

Résumé : avantages des diagrammes de séquence

Les diagrammes de séquence vous aident à visualiser :

  • Le flux de contrôle transféré entre acteurs ou entre objets pendant l'exécution d'un cas d'usage.

  • L'implémentation d'un appel de méthode ou d'un message.

Relation aux autres diagrammes

Schéma

Description

Diagramme de classes (UML)

Définir les classes que les lignes de vie représentent, ainsi que les paramètres et les valeurs de retour utilisées dans les messages envoyés entre les lignes de vie.

Pour créer une classe à partir d'une ligne de vie, cliquez avec le bouton droit sur la ligne de vie et cliquez sur Créer une classe ou Créer l'interface. Pour créer une ligne de vie à partir d'un type d'un diagramme de classes, cliquez avec le bouton droit sur le type, puis cliquez sur Créer la ligne de vie.

Reportez-vous à :

Diagramme de composant

Décrire les composants que les lignes de vie représentent, ainsi que les interfaces qui fournissent et consomment le comportement représenté par des messages.

Pour créer une ligne de vie à partir d'un diagramme de composant, cliquez avec le bouton droit sur le composant, puis cliquez sur Créer la ligne de vie.

Reportez-vous à :

Diagramme de cas d'usage

Résumer les interactions entre utilisateurs et composants d'un diagramme de séquence pour créer un cas d'usage, qui représente l'objectif d'un utilisateur.

Reportez-vous à :

Définir un glossaire de types : les diagrammes de classes

Les diagrammes de classes définissent les entités, les termes ou les concepts qui participent au système, ainsi que leurs relations les uns aux autres. Par exemple, vous pouvez utiliser ces diagrammes pendant le développement, afin de décrire les attributs et les opérations de chaque classe, indépendamment de leur langage d'implémentation ou de leur style.

Pour faciliter la description et la discussion des entités qui participent au cas d'usage Traiter le paiement, Lucerne dessine le diagramme de classes suivant :

Entités Traiter le paiement sur le diagramme de classes

Entités Traiter le paiement d'un diagramme de classes

Ce diagramme indique qu'un Client peut être associé à plusieurs commandes et moyens de paiement. BankAccount et CreditCard héritent tous deux de Paiement.

Pendant le développement, Lucerne utilise le diagramme de classes suivant pour décrire et discuter des détails de chaque classe :

Détails des entités Traiter le paiement sur un diagramme de classes

Détails de Traiter le paiement dans le diagramme de classes

Reportez-vous à :

Dessin d'un diagramme de classes

Un diagramme de classes possède les principales fonctionnalités suivantes :

  • Les types tels que les classes, les interfaces et les énumérations :

    • Une classe est la définition d'objets qui partagent des caractéristiques structurelles ou comportementales spécifiques.

    • Une interface définit une partie du comportement extérieurement visible d'un objet.

    • Une énumération est un classifieur qui contient une liste de valeurs littérales.

  • Les attributs sont des valeurs d'un certain type qui décrivent chaque instance d'un classifieur. Un classifieur est un terme générique regroupant les types, les composants, les cas d'usage et même les acteurs.

  • Les opérations sont des méthodes ou des fonctions que les instances d'un classifieur peuvent exécuter.

  • Une association indique la relation entre deux classifieurs.

    • Une agrégation est une association qui indique une propriété partagée par plusieurs classifieurs.

    • Une composition est une association qui indique une relation de partie entière entre des classifieurs.

    Pour afficher des agrégations ou des compositions, définissez la propriété Agrégation sur une association. Partagé montre les agrégations et Composite montre les compositions.

  • Une dépendance indique que la modification de la définition d'un classifieur peut modifier la définition d'un autre classifieur.

  • Une généralisation indique qu'un classifieur spécifique hérite une partie de sa définition d'un classifieur général. Une réalisation indique qu'une classe implémente les attributs et les opérations proposés par une interface.

    Pour créer ces relations, utilisez l'outil Héritage. Une réalisation peut également être représentée comme un symbole d'interface (lollipop).

  • Les packages sont des groupes de classifieurs, d'associations, d'actions, de lignes de vie, de composants et d'autres packages. Les relations d'Importation, indiquent qu'un package inclut toutes les définitions d'un autre package.

Pour commencer, vous pouvez utiliser le Concepteur de classes pour créer des diagrammes de classes à partir du code, afin d'explorer et de discuter des classes existantes.

Reportez-vous à :

Résumé : avantages des diagrammes de classes

Les diagrammes de classes vous aident à définir :

  • Un glossaire commun des termes à utiliser lors des discussions sur les besoins des utilisateurs et les entités qui participent au système. Consultez Modélisation des besoins des utilisateurs.

  • Les types utilisés par certaines parties du système, telles que les composants, indépendamment de leur implémentation. Consultez Modélisation de l'architecture d'un système logiciel.

  • Les relations, telles que les dépendances, entre les types. Par exemple, vous pouvez montrer qu'un type peut être associé à plusieurs instances d'un autre type.

Relation aux autres diagrammes

Schéma

Description

Diagramme de cas d'usage

Définir les types utilisés pour décrire les objectifs et les étapes de cas d'usage.

Reportez-vous à :

Diagramme d'activités

Définir le type des données passées dans les nœuds d'objets, les broches d'entrée et de sortie, et les nœuds de paramètre d'activité.

Reportez-vous à :

Diagramme de composant

Décrire les composants, leurs interfaces et leurs relations. Une classe peut également décrire un composant complet.

Reportez-vous à :

Diagramme de couche

Définir l'architecture logique du système par rapport aux classes.

Utilisez la validation de couche pour vous assurer que le code demeure cohérent avec la conception.

Reportez-vous à :

Diagramme de séquence

Définir les types des lignes de vie, ainsi que les opérations, paramètres et valeurs de retour pour tous les messages qu'une ligne de vie peut recevoir.

Pour créer une ligne de vie à partir d'un type d'un diagramme de classes, cliquez avec le bouton droit sur le type, puis cliquez sur Créer la ligne de vie.

Reportez-vous à :

Graphique de dépendance

Visualiser l'organisation et les relations dans du code existant.

Pour identifier des classes, leurs relations et leurs méthodes, créez un document de graphique qui affiche ces éléments.

Reportez-vous à :

Décrire l'architecture logique : les diagrammes de couche

Les diagrammes de couche décrivent l'architecture logique d'un système en organisant les artefacts de votre solution en groupes abstraits ou couches. Les artefacts peuvent être aussi bien des espaces de noms que des projets, des classes ou des méthodes, par exemple. Les couches représentent et décrivent les rôles ou les tâches que les artefacts exécutent dans le système. Vous pouvez également inclure la validation de couche à vos opérations d'archivage et de génération pour vous assurer que le code demeure cohérent avec sa conception.

Pour garantir la cohérence du code avec la conception, Dinner Now et Lucerne utilisent le diagramme de couche suivant pour valider leur code à mesure de son évolution :

Diagramme de couche du système de paiement intégré

Diagramme de couche pour le système de Dinner Now intégré au système de Lucerne

Les couches du diagramme dirigent vers les artefacts correspondants des solutions de Dinner Now et de Lucerne. Par exemple, la couche Métier est liée à l'espace de noms DinnerNow.Business et à ses membres, qui désormais incluent la classe PaymentApprover. La couche Accès aux ressources vers l'espace de noms DinnerNow.Data. Les flèches, ou dépendances, spécifient que seule la couche Métier peut utiliser les fonctionnalités de la couche Accès aux ressources. Lorsque les équipes mettent à jour leur code, la validation de couche est exécutée régulièrement afin d'intercepter les conflits à mesure qu'ils se produisent et ainsi aider les équipes à les résoudre rapidement.

Les équipes collaborent afin d'intégrer de façon incrémentielle et de tester les deux systèmes. Elles s'assurent en premier que PaymentApprover fonctionne correctement avec le reste du système Dinner Now, avant de s'attaquer à PaymentProcessing.

Le graphique de dépendance suivant montre les nouveaux appels entre Dinner Now et PaymentApprover :

Graphique de dépendance mis à jour avec système intégré

Graphique de dépendance avec les appels de méthode mis à jour

Après avoir confirmé que le système fonctionne comme prévu, Dinner Now supprime le code PaymentProcessing. Les rapports de validation de couche ne comportent pas d'erreur, et le graphique de dépendance résultant indique qu'aucune dépendance PaymentProcessing n'existe :

Graphique de dépendance sans PaymentProcessing

Graphique de dépendance sans PaymentProcessing

Reportez-vous à :

Dessin d'un diagramme de couche

Un diagramme de couche possède les principales fonctionnalités suivantes :

  • Les couches décrivent des groupes logiques d'artefacts.

  • Un lien est une association entre une couche et un artefact.

    Pour créer des couches à partir d'artefacts, faites glisser des éléments depuis l'Explorateur de solutions, les graphiques de dépendance ou le navigateur de l'architecture. Pour dessiner de nouvelles couches puis les lier aux artefacts, utilisez la boîte à outils ou cliquez avec le bouton droit sur la surface du diagramme pour créer les couches, puis faites glisser des éléments vers ces couches.

    Le nombre indiqué sur une couche représente le nombre d'artefacts liés à cette couche. Ces artefacts peuvent être des espaces de noms, des projets, des classes, des méthodes, etc. Lorsque vous interprétez le nombre d'artefacts d'une couche, souvenez-vous des éléments suivants :

    • Si une couche est liée à un artefact contenant d'autres artefacts, mais n'est pas directement liée à ces autres artefacts, le nombre représentera uniquement les artefacts auxquels elle est directement liée. Toutefois, les autres artefacts sont inclus dans l'analyse pendant la validation de couche.

      Par exemple, si une couche est liée à un espace de noms unique, le nombre d'artefacts liés est égal à 1, même si l'espace de noms contient des classes. Si la couche a également des liens vers chaque classe de l'espace de noms, le nombre comprendra les classes liées.

    • Si une couche contient d'autres couches liées à des artefacts, la couche du conteneur est également liée à ces artefacts, même si le nombre indiqué sur la couche du conteneur ne comprend pas ces artefacts.

    Pour voir la liste des artefacts liés à une couche, cliquez avec le bouton droit sur la couche, puis cliquez sur Afficher les liens pour ouvrir l'Explorateur de couches.

  • Une dépendance indique qu'une couche peut utiliser les fonctionnalités d'une autre couche, mais pas l'inverse. Une dépendance bidirectionnelle indique qu'une couche peut utiliser les fonctionnalités d'une autre couche, et vice versa.

    Pour afficher les dépendances existantes d'un diagramme de couche, cliquez avec le bouton droit sur la surface du diagramme de couche, puis cliquez sur Générer des dépendances. Pour décrire des dépendances prévues, dessinez-en de nouvelles.

Reportez-vous à :

Résumé : avantages des diagrammes de couche

Les diagrammes de couche vous aident à :

  • Décrire l'architecture logique d'un système d'après les fonctionnalités de ses artefacts.

  • Garantir que le code en cours de développement est conforme à la conception spécifiée.

Relation aux autres diagrammes

Schéma

Description

Graphique de dépendance

Visualiser l'organisation et les relations dans du code existant.

Pour créer des couches, générez un graphique de dépendance, puis regroupez les éléments d'un graphique comme couches potentielles. Faites glisser les groupes depuis le graphique vers le diagramme de couche.

Reportez-vous à :

Diagramme de composant

Décrire les composants, leurs interfaces et leurs relations.

Pour visualiser les couches, créez un diagramme de composant décrivant les fonctionnalités des différents composants du système.

Reportez-vous à :

Ressources externes

Catégorie

Liens

Forums

Blogs

Blog Visual Studio ALM + Team Foundation Server

Articles et journaux techniques

The Architecture Journal - Issue 23: Architecture Modeling and Processes

Autres sites

Centre d'architecture MSDN

Voir aussi

Concepts

Visualiser du code

Développement de modèles pour la conception logicielle

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

Utiliser des modèles dans le développement Agile

Validation de votre système lors du développement

Extension de modèles et de diagrammes UML