Cartographie entre modèle de vue architecturale 4 + 1 et UML

Je suis un peu confus quant à la façon dont le modèle de vue architecturale 4 + 1 correspond à UML.

Wikipedia donne la cartographie suivante:

• Vue logique: diagramme de classes, diagramme de communication, diagramme de séquence.
• Vue de développement: diagramme de composants, diagramme de package
• Vue de processus: diagramme d'activité
• Vue physique: diagramme de déploiement
• Scénarios: diagramme de cas d'utilisation

L'article Rôle des constructions de diagrammes de séquence UML dans le concept de cycle de vie d'objet donne le mappage suivant:

• Vue logique (diagramme de classe (CD), diagramme d'objet (OD), diagramme de séquence (SD), diagramme de collaboration (COD), diagramme de diagramme d'état (SCD), diagramme d'activité (AD))
• Vue de développement (diagramme de package, diagramme de composants),
• Vue du processus (diagramme de cas d'utilisation, CD, OD, SD, COD, SCD, AD),
• Vue physique (diagramme de déploiement), et
• Utilisez la vue de cas (diagramme de cas d'utilisation, OD, SD, COD, SCD, AD) qui combine les quatre mentionnés ci-dessus.

La page Web UML 4 + 1 View Materials présente la cartographie suivante:

Enfin, le livre blanc Application de l'architecture de vue 4 + 1 avec UML 2 donne un autre mappage:

• Diagrammes de classes de vues logiques , diagrammes d'objets, diagrammes d'états et structures composites
• Diagrammes de séquence de vue de processus , diagrammes de communication, diagrammes d'activité, chronogrammes, diagrammes de présentation d'interaction
• Diagrammes des composants de la vue de développement
• Diagramme de déploiement de la vue physique
• Vue de cas d' utilisation diagramme de cas d'utilisation, diagrammes d'activité

Je suis sûr que d'autres recherches révéleront également d'autres mappages.

Bien que diverses personnes aient généralement des perspectives différentes, je ne vois pas pourquoi c'est le cas ici. En particulier, chaque diagramme UML décrit le système sous un aspect particulier. Ainsi, par exemple, pourquoi le "diagramme de séquence" est considéré comme décrivant la "vue logique" du système par un auteur, alors qu'un autre auteur le considère comme décrivant la "vue de processus"?

Pourriez-vous s'il vous plaît m'aider à clarifier la confusion?

Bien que je sois généralement d'accord avec la réponse de Bart van Ingen Schenau , je pense que quelques points nécessitent des précisions supplémentaires.

L'avantage du modèle de vue 4 + 1 est qu'il mappe les parties prenantes au type d'informations dont elles ont besoin, sans nécessiter l'utilisation de notations de modélisation spécifiques. L'accent est mis sur la garantie que tous les groupes disposent des informations nécessaires pour comprendre le système et continuer à faire leur travail.

Le modèle de vue d'architecture logicielle 4 + 1 a été décrit dans l'article Architectural Blueprints de Philippe Kruchten - Le modèle de vue d'architecture logicielle "4 + 1" qui a été initialement publié dans IEEE Software (novembre 1995). Cette publication ne fait pas de références spécifiques à UML. En fait, l'article utilise la notation Booch pour la vue logique, des extensions de la notation Booch pour la vue de processus et la vue de développement, appelle l'utilisation de "plusieurs formes" de développement d'une vue physique et une nouvelle notation pour les scénarios.

Au lieu d'essayer de mapper chacune des vues à des types de diagrammes particuliers, déterminez qui est le public cible de chaque vue et quelles informations ont besoin. Sachant cela, examinez les différents types de modèles et lesquels fournissent les informations requises.

La vue logique est conçue pour répondre aux préoccupations de l'utilisateur final quant à la garantie que toutes les fonctionnalités souhaitées sont capturées par le système. Dans un système orienté objet, cela se fait souvent au niveau de la classe. Dans les systèmes complexes, vous pouvez avoir besoin d'une vue de package et décomposer les packages en plusieurs diagrammes de classes. Dans d'autres paradigmes, vous pourriez être intéressé à représenter les modules et les fonctions qu'ils fournissent. Le résultat final doit être un mappage de la fonctionnalité requise avec les composants qui fournissent cette fonctionnalité.

La vue de processus est conçue pour les personnes qui conçoivent l'ensemble du système, puis intègrent les sous-systèmes ou le système dans un système de systèmes. Cette vue montre les tâches et les processus du système, les interfaces avec le monde extérieur et / ou entre les composants du système, les messages envoyés et reçus, et comment les performances, la disponibilité, la tolérance aux pannes et l'intégrité sont prises en compte.

La vue de développement est principalement destinée aux développeurs qui construiront les modules et les sous-systèmes. Il doit montrer les dépendances et les relations entre les modules, la façon dont les modules sont organisés, la réutilisation et la portabilité.

La vue physique est principalement destinée aux concepteurs de systèmes et aux administrateurs qui doivent comprendre les emplacements physiques du logiciel, les connexions physiques entre les nœuds, le déploiement et l'installation et l'évolutivité.

Enfin, les scénarios aident à saisir les exigences afin que toutes les parties prenantes comprennent comment le système doit être utilisé.

Une fois que vous comprenez ce que chaque vue est censée fournir, vous pouvez choisir les notations de modélisation à utiliser et le niveau de détail requis. Le dernier paragraphe de Bart est particulièrement vrai - vous pouvez afficher différents niveaux de détails dans vos modèles UML en vous concentrant sur des éléments de conception particuliers ou en combinant différents types de diagrammes dans un ensemble. De plus, vous voudrez peut-être envisager d'aller au-delà d'UML vers d'autres notations de modélisation pour mieux décrire l'architecture de votre système - SysML , modélisation d'entité-relation ou IDEF .

La raison pour laquelle vous ne pouvez pas trouver de mappage un à un entre les vues du modèle architectural 4 + 1 et les différents diagrammes UML est dû au fait qu'un tel mappage n'existe pas.

Ce que tous ces auteurs essaient de dire avec leurs `` mappages '', c'est que pour chaque vue, il existe un ensemble différent de diagrammes UML qui peuvent être utiles pour transmettre les informations que vous souhaitez dire dans cette vue.

De plus, certains diagrammes UML peuvent être utilisés de différentes manières, en mettant l'accent sur différents éléments du diagramme, ce qui les rend utiles pour plusieurs vues. Mais même si un type de diagramme UML peut être utilisé dans plusieurs vues, vous dessinez un diagramme (ou un ensemble de diagrammes) différent pour chaque vue.

Bien que je sois d'accord avec l' approche des réponses de Thomas Owens pour répondre aux besoins de vos utilisateurs finaux, une chose qui n'a pas été mentionnée est que la raison pour laquelle la définition originale de la "4 + 1 View Model Architecture" par Kruchten ne fait aucune des références spécifiques à UML sont dues au fait que l'article a été écrit en 1995 (comme l'indique la réponse), mais UML n'a pas vraiment été adopté comme norme avant 1997 .

L'utilisation continue de la notation Booch dans l'article suggère que relier chacune des vues des modèles à un diagramme UML spécifique pourrait être approprié, car Grady Booch était l'une des personnes impliquées dans le développement d'UML.

C'est pour cette raison que tant d'auteurs différents considèrent que différents diagrammes UML sont applicables à chaque vue, car plusieurs diagrammes UML pourraient être considérés dans une certaine mesure comme des «abstractions» de la notation Booch sur lesquelles la définition originale du modèle 4 + 1 s'appuie pour représenter chaque vue.

J'espère que cela clarifiera un peu plus les choses pour quiconque étudie la question.

Utilisez-vous toujours un magnétoscope que vous avez acheté en 1995.? 4 + 1 était applicable à l'époque lorsque le logiciel était à ses balbutiements. Mais même alors, personne n'a jamais utilisé plus de 2 ou 3 "vues". Au cours des 20 dernières années, l'ingénierie logicielle a changé. De nos jours, portée / contexte et conceptuel et logique et physique et ... sont tous différenciés. De nombreuses solutions COTS doivent être intégrées, etc. Aujourd'hui, nous parlons de cartes du paysage, de réalisations de services et de dizaines d'autres vues et points de vue. La meilleure façon de le voir est à travers un cadre de taxonomie simple comme Zachman: 6 vues et 6 points de vue. Que ce soit votre point de départ. Les 6 vues sont les suivantes: conceptuel contextuel ou logique métier ou physique physique ou technologique du système ou artefacts entreprise fonctionnelle

6 points de vue sont: les données ou quelle fonction ou comment le réseau ou où les gens ou qui le temps ou quand la motivation ou pourquoi

Regardons un exemple. Si nous ne sommes intéressés que par les données, nous commencerons par la vue de la portée et dirons: «Notre portée est CRM». Dans la vue conceptuelle du point de vue des données, nous proposerons un modèle sémantique pour CRM. Le modèle sera conceptuel, des concepts d'informations commerciales plutôt que des objets de données. Ensuite, dans la vue logique, nous produirons un modèle de données logique à partir de notre modèle conceptuel de CRM. Nous pouvons utiliser la méthodologie ER pour produire un modèle de données logique. Ensuite, dans la vue physique, nous produirons un modèle de données physiques. Ici, nous allons définir des types de données concrets pour la plate-forme db de notre choix, des index, etc. Enfin, dans la vue de livraison, nous aurons notre script DDL, tandis que dans la vue d'entreprise fonctionnelle, nous aurons un fichier binaire déployé sur un serveur de base de données et mappé dans les structures de données internes du fournisseur de DBM. Nous répétons cela pour chaque point de vue ou colonne. De plus, s'il y a plus d'une partie prenante, nous créerons plus d'un modèle pour chaque combinaison point de vue / vue. Maintenant que cette taxonomie est en place, vous pouvez définir vos propres points de vue et vues et les aligner dans cette taxonomie. Par exemple, pour les initiatives au niveau de l'entreprise, les points de vue suivants sont tous importants: coopération des acteurs comportement des applications coopération des applications structure de l'application utilisation de l'application fonction métier processus métier coopération processus implémentation et déploiement structure des informations infrastructure infrastructure utilisation paysage carte vue d'ensemble couches organisationnelles réalisation des services etc. Maintenant que cette taxonomie est en place, vous pouvez définir vos propres points de vue et vues et les aligner dans cette taxonomie. Par exemple, pour les initiatives au niveau de l'entreprise, les points de vue suivants sont tous importants: coopération des acteurs comportement des applications coopération des applications structure de l'application utilisation de l'application fonction métier processus métier coopération processus implémentation et déploiement structure des informations infrastructure infrastructure utilisation paysage carte vue d'ensemble couches organisationnelles réalisation des services etc. Maintenant que cette taxonomie est en place, vous pouvez définir vos propres points de vue et vues et les aligner dans cette taxonomie. Par exemple, pour les initiatives au niveau de l'entreprise, les points de vue suivants sont tous importants: coopération des acteurs comportement des applications coopération des applications structure de l'application utilisation de l'application fonction métier processus métier coopération processus implémentation et déploiement structure des informations infrastructure infrastructure utilisation paysage carte vue d'ensemble couches organisationnelles réalisation des services etc.

Le 4 + 1 de Krutchen ne pouvait pas satisfaire tous ces besoins