Qu’est-ce que le Framework Modèle-Vue-Contrôleur (MVC) ? Modéliser MVC avec analyse de robustesse UML

Model-View-Controller (MVC) est un modèle de conception de base qui sépare la logique de l’interface utilisateur de la logique métier. Le modèle Modèle-Vue-Contrôleur (MVC) est un moyen de diviser une application en trois composants distincts ; le modèle, la vue et le contrôleur.

Framework MVC utilisant la modélisation UML

Ce modèle-vue-contrôleur peut être mieux décrit visuellement en utilisant une analyse de robustesse en notation UML stéréotypée, qui a été proposée pour la première fois par Ivar Jacobson dans son livre primé Object-Oriented Software Engineering (voir les références ci-dessous) et expliquée plus en détail par Doug Rosenberg et al . dans son livre Use Case-Driven UML Object Modeling.

Voici un diagramme de séquence simple et hypothétique pour MVC. Ce que vous voyez dans le diagramme ci-dessus, c’est qu’un utilisateur Web lance une requête et génère un événement qui est traité par le contrôleur pour obtenir les informations requises du modèle, valider les informations et transmettre le jeu de résultats à la vue.

Les objets d’entité (modèle) ne sont rien de plus que les informations ou les données que recherchent vos objets de frontière. Il peut s’agir de tables de base de données, de fichiers Excel ou de sessions « transitoires » ou de données mises en cache ou quelque chose comme ça.

• Décrire les objets qui existent au fil du temps et qui sont principalement concernés par l’état persistant.
• Généralement des objets du modèle de domaine
• Choses que nous devons suivre et stocker

Les objets frontières (vue) sont des objets avec lesquels les acteurs (par exemple, les utilisateurs) communiquent dans votre système logiciel. Ces objets peuvent être n’importe quelle fenêtre, écran, boîte de dialogue et menu, ou toute autre interface utilisateur de votre système. Vous pouvez facilement les identifier lors de l’analyse des cas d’utilisation.

• décrire les connexions entre le système et l’environnement qui communiquent.
• Utilisé par les acteurs lors de la communication avec le système
• Seuls les objets d’entité peuvent initier des événements
• (généralement les principaux éléments de l’interface utilisateur, par exemple les écrans)

Les objets de contrôle (contrôleurs) sont des objets métier ou vos services Web métier. C’est là que vous capturez les règles métier qui sont utilisées pour filtrer les données à présenter à l’utilisateur, ce qu’il demande. Ainsi, le contrôleur contrôle en fait la logique métier et la transformation des données.

• décrire le comportement dans un cas d’utilisation particulier.
• Le « colle » entre les objets frontières et les objets entité
• Capturez les règles et politiques commerciales
• (note : souvent implémenté comme méthodes d’autres objets)

Règles de connexion dans le modèle MVC

Considérez que les objets frontières et les objets entités sont des noms, tandis que les contrôleurs sont des verbes.

Voici les quatre règles de base de la connexion.

• Les acteurs ne peuvent interagir ou communiquer qu’avec des objets frontières.
• Les objets frontières ne peuvent communiquer qu’avec les contrôleurs et les acteurs.
• Les objets Entity ne peuvent interagir qu’avec les contrôleurs.
• Les contrôleurs peuvent communiquer avec des objets limites et des objets d’entité, ainsi qu’avec d’autres contrôleurs, mais pas avec des acteurs

N’oubliez pas que les objets de frontière et les objets d’entité sont des noms, tandis que les contrôleurs sont des verbes. Les noms ne peuvent pas parler à d’autres noms, mais les verbes peuvent parler à des noms ou à des verbes.

Diagramme d’analyse de robustesse en un coup d’œil

Supposons que nous ayons la description de cas d’utilisation simple suivante au format textuel :

À partir de la page de détail de l’étudiant, l’enseignant clique sur le bouton  »Ajouter des cours » et le système affiche la liste des cours. L’enseignant sélectionne le nom d’un cours et appuie sur le bouton  »S’inscrire ». Le système inscrit l’étudiant au cours.

Vous pouvez maintenant créer un diagramme de robustesse simple selon le cas d’utilisation ci-dessus :

Vous pouvez également utiliser une étiquette de texte pour joindre la description du cas d’utilisation sur le côté droit du diagramme de robustesse.

Cinq étapes pour créer une analyse de robustesse

1. Vous effectuez une analyse de robustesse pour un cas d’utilisation en parcourant le texte du cas d’utilisation.
2. Une phrase à la fois, et en dessinant les acteurs, la frontière appropriée, les objets d’entité et les contrôleurs, et les connexions entre les différents éléments du diagramme.
3. Vous devriez être en mesure d’adapter le cours de base et tous les cours alternatifs sur un seul diagramme.
4. Quiconque examine un diagramme de robustesse doit être capable de lire un plan d’action dans le texte du cas d’utilisation, de tracer son doigt avec les associations sur le diagramme et de voir une correspondance claire entre le texte et l’image.

Vous devrez probablement réécrire votre texte de cas d’utilisation au fur et à mesure, pour supprimer l’ambiguïté et pour référencer explicitement les objets de frontière et les objets d’entité. La plupart des gens n’écrivent pas un texte de cas d’utilisation parfait dans le premier brouillon. Nous pouvons donc utiliser l’analyse de robustesse pour combler l’écart entre le texte du cas d’utilisation et le diagramme.

Développer un scénario de cas d’utilisation à l’aide de diagrammes de séquence MVC

Sur la base de l’analyse de robustesse, nous pouvons développer des scénarios de cas d’utilisation (normaux ou alternatifs) en utilisant un ensemble de diagrammes de séquence associés au format MVC. De même, le diagramme de séquence MVC a des objets d’interface, des objets de contrôleur et des objets d’entité :

• Les entités sont des objets représentant des données système : Client, Produit, Transaction, Panier, etc.
• Les frontières sont des objets qui s’interfacent avec les acteurs du système : UserInterface, DataBaseGateway, ServerProxy, etc.
• Les contrôles sont des objets qui assurent la médiation entre les limites et les entités.

Ils orchestrent l’exécution des commandes provenant de la frontière en interagissant avec les entités à travers les objets frontières. Un objet contrôleur correspond souvent au scénario de cas d’utilisation et souvent représenté par un diagramme de séquence.

Vous pouvez utiliser des stéréotypes pour la ligne de vie dans le diagramme de séquence MVC afin de clarifier visuellement le type d’objets que vous utilisez dans le MVC, comme dans le diagramme d’analyse de robustesse ci-dessus.

Exemple de diagramme de séquence MVC

Supposons une application qui vous permette de rechercher des personnes. L’interface utilisateur doit avoir un champ de texte dans lequel l’utilisateur peut entrer une chaîne de recherche et peut avoir un bouton pour lancer la recherche. Enfin, il doit avoir une zone où les résultats de la recherche sont affichés. Dans notre cas, il est implémenté avec un composant de liste.

Le scénario de cas d’utilisation « Rechercher des personnes » est :

• L’utilisateur saisit une chaîne de recherche dans le champ de texte
• L’utilisateur clique sur le bouton de recherche.
• Le résultat de la recherche s’affiche dans la liste des résultats.

Le diagramme de séquence ci-dessus montre comment le clic du bouton de l’utilisateur se déplace dans l’application jusqu’à ce que le résultat soit finalement affiché dans le composant de liste.

Les références

• Tutoriel sur le diagramme de séquence
• Comment dessiner un diagramme de séquence ?
• Modèles de diagramme de séquence
• Outil de diagramme de séquence UML