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?
la source
The logical view is designed to address the end user's concerns about ensuring that all of their desired functionality is captured by the system. In an object-oriented system, this is often at the class level
. Ne trouvez-vous pas que si nous voulons faire quelque chose pour les utilisateurs finaux, nous devons au moins communiquer avec eux et parler une langue. Essayez de montrer votre diagramme de classe à vos utilisateurs et voyons ce qu'ils vont dire.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.
la source
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.
la source
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
la source