Vue d'ensemble du scénario : modifier votre conception à l'aide de la visualisation et de la modélisation
Pour vous assurer que votre système logiciel à ses 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 des diagrammes de (UML) de langage UML, des diagrammes de couche, des graphiques de dépendance basés sur du code, les diagrammes de séquence, et des diagrammes de classes. Par exemple, vous pouvez utiliser ces outils pour accomplir 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éveloppez dinner now entretiennent entre la zone.
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 à côté 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 à :
Comment : créer des diagrammes et projets de modélisation UML
Visualiser des dépendances de code sur les graphiques de dépendance
Comment : ajouter des diagrammes de classes aux projets (Concepteur de classes)
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 Comment : modifier des modèles et 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
[!REMARQUE]
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 afin que les équipes peuvent planifier, gérer, et effectuer le suivi de 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 des éléments de travail de Team Foundation Server vers les éléments de modèle afin de pouvoir surveiller la progression et s'assurer que le système répond 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
.gif "Ff183189.collapse_all(fr-fr,VS.110).gif")
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 à : |
|
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 :
.png "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 :
.png "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 :
.png "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 :
.png "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 :
.png "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 :
.png "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 sur le diagramme de cas d'usage présentent des éléments de travail 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 d'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 d'autres genres de relations dans le code.Ils utilisent le navigateur de l'architecture ou l'explorateur de solutions pour les aider 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 en générant des diagrammes de séquence. |
Séquence d'interactions entre les 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 qu'il souhaite concentrer sur et crée un graphique de dépendance du 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 :
.png "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 :
.png "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 Visualisation et description du code.
.gif "Conseil") 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.Ils peuvent également dessiner des diagrammes suivants dans Visual Studio afin que les détails puissent être capturés, gérés, et inclus 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 :
.png "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 :
.png "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 :
.png "Diagramme de couche du système de paiement intégré")
Diagramme de couches
Pour vérifier que les conflits avec la conception ne se produisent pendant le développement du code, les équipes utilise la validation de couche sur les builds exécutées dans Team Foundation Build.Ils créent également une tâche personnalisée MSBuild d'exiger la validation de couche dans leurs 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 afficher le modèle, dans le menu Architecture, pointez sur Fenêtres, puis cliquez sur Explorateur de modèles UML.
Dans certains cas, vous pouvez faire glisser certains éléments Explorateur de modèles UML à 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.
Prend en charge finaux UML 2.1.2 de Visual Studio.Cette vue d'ensemble décrit uniquement les principales fonctionnalités des diagrammes UML dans cette version finale, mais il existe de nombreuses livres qui traitent UML et son utilisation en détail.
Consultez Développement de modèles pour la conception logicielle.
Planification et suivi des travaux
Les diagrammes finaux de modélisation de Visual Studio sont intégrés à Team Foundation Server afin que vous puissiez planifier, gérer, et assurer le suivi de leur travail plus facilement. Les deux équipes utilisent des modèles pour identifier des cas de test et des tâches de développement et estimer leur travail.Lucerne crée et lie des éléments de travail de Team Foundation Server vers les éléments de modèle, tels que les 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.Ils également surveiller et signalent l'état sur leur travail à l'aide de les fonctionnalités suivantes de Team Foundation Server :
Des rapports de Burndown quotidiens qui montrent si le travail planifié sera terminé à la date prévue.Ils génèrent d'autres rapports semblables Team Foundation Server pour suivre la progression des bogues.
Une feuille de calcul d'itération qui utilise Microsoft Excel pour l'aider à surveiller et équilibrer la charge de travail entre ses membres.Cette feuille de calcul est liée à Team Foundation Server et fournit le focus pour la discussion au cours de les réunions normales de progression.
Un tableau de bord de développement qui utilise Office Project pour conserver l'équipe a informé sur les informations importantes de projet.
Reportez-vous à :
Créer, personnaliser et gérer des rapports pour Visual Studio ALM
Planifier des tâches et assigner des ressources à l'aide de Microsoft Project
Test, validation et archivage du code
Comme équipes terminez chaque tâche, elles contrôlent leur code dans le contrôle de version Team Foundation et reçoivent des rappels de Team Foundation Server, si elles oublient.Avant que Team Foundation Server reçoive les enregistrements, les équipes effectuent des tests unitaires et la validation de couche pour vérifier le code par rapport à leurs cas de test et la conception.Ils utilisent Team Foundation Server pour exécuter des builds, les tests unitaires automatisés, et la validation de couche régulièrement.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.Elles utilisent également Visual Studio final pour exécuter des tests manuels.
Pour s'assurer que le code est conforme à la conception, les équipes configurent leurs builds dans Team Foundation Build pour inclure la validation de couche. Si des conflits se produisent, un rapport est créé 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.Le suivantes montrent de sections les diagrammes de modélisation dans l'aide finale de Visual Studio ils effectuent 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 :
.png "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 :
.png "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 :
.png "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 maintenant également Visual Studio final pour dessiner ces diagrammes afin que les deux équipes puissent entrer, 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 :
.png "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 :
.png "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 :
.png "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 :
.png "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 :
.png "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 :
.png "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
Pour une vue d'ensemble du code source, procédez aux étapes suivantes pour générer un graphique de dépendance :
Dans le menu Architecture, pointez sur Générer un graphique de dépendance, puis cliquez sur Pour la solution.
Pour une vue d'ensemble du code compilé, créez un graphique de dépendance vide, puis faites glisser les fichiers d'assembly ou des fichiers binaires la surface du graphique.
Consultez Visualiser des dépendances de code sur les graphiques de dépendance.
Pour explorer des éléments spécifiques de code ou de solution, l'explorateur de solutions d'utilisation ou le navigateur de l'architecture pour sélectionner les éléments et les relations que vous souhaitez visualiser.Vous pouvez ensuite générer un nouveau graphique ou ajouter des éléments sélectionnés à un graphique existant.
Consultez Visualiser des dépendances de code sur les graphiques de dépendance et Rechercher du code avec le navigateur de l'architecture.
Pour faciliter l'exploration d'un graphique, réorganisez sa disposition afin de l'adapter aux genres de tâches que vous souhaitez exécuter.
Par exemple, pour visualiser la disposition du code en couches, sélectionnez une disposition d'arborescence.Consultez Parcourir et réorganiser des graphiques de dépendance.
Pour vous aider à vous concentrer sur des zones spécifiques du graphique, ajustez sa portée en filtrant des éléments ou en personnalisant leur apparence.Consultez Modifier et personnaliser des graphiques 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 :
.png "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 retourné (<<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 :
.png "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 :
.png "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 un certain type de 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 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 :
.png "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 :
.png "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 |
|
Articles et journaux techniques |
The Architecture Journal - Issue 23: Architecture Modeling and Processes |
Autres sites |
Voir aussi
Concepts
Visualisation et description 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