Architecture logicielle sur base de la méthode architecture 4+1 vues

Rami Sellami

CETIC, Belgique, le 21/01/2019

Modèle d'architecture 4 + 1 vues

  • Proposé par Philippe Kruchten en 1995
  • Décrire l'architecture logicielle en se basant sur plusieurs vues d'un point de vue de différentes parties prenantes (par exemple utilisateur, développeur, chef de projet, ...)
  • Une vue est une description complète et simplifiée du système d'un point de vue bien défini
  • Intérêt
    • Compatible avec la notation UML
    • Démarche favorable à l'utilisation de diagrammes
    • Pragmatique : ne documenter que ce qui est utile
    • Assez facile à comprendre pour des "non techniques"

Vue logique

  • La vue la plus connue de l'architecture (Souvent réalisée hors du 4+1 vues)
  • Contenu
    • Une vue « désincarnée », abstraite de l'architecture
    • Peut suivre une découpe fonctionnelle
    • Peut suivre une découpe orientée objets
  • Format suggéré
    • Diagramme global
    • Diagrammes de classes
    • Diagramme de communication
    • Diagramme d'objets

Vue de processus

  • Exprimer la dynamicité du système
  • Contenu :
    • Décrire les interactions entre processus/threads/tâches
    • Expliciter les relations entre tâches (attentes, synchronisations), les allocations / dé-allocations, les exigences non fonctionnelles (concurrence, performance, ...)
  • Formats suggérés (tout diagramme susceptible d'exprimer la communication et les changements d'état) :
    • Diagrammes de communication / collaboration
    • Diagrammes états - transitions
    • Diagrammes d'activité

Vue d'implémentation

  • Organisation des modules logiciels sous forme de composants
    • Composants réutilisés ou à réaliser
    • Expression des relations entre ces composants (hiérarchie, contraintes, héritage, ...)
  • Contenu :
    • Vue logique « instanciée » (noms des composants ajoutés)
    • Informations de configuration (versions retenues, auteurs/sources, ...)
  • Formats suggérés :
    • Diagramme de composants
    • Diagramme de paquetages

Vue de déploiement

  • Exprimer comment est déployé le système (Contribue mais ne suffit pas à décrire l'installation)
  • Contenu :
    • Décrire la répartition spatiale
    • Enumérer les contraintes (Pare-feu, bande passante, ...)
    • Décrire la scalabilité et la tolérance aux pannes
  • Formats suggérés :
    • Diagrammes de déploiement
    • Diagrammes de composants (complétés avec la répartition spatiale et les contraintes)

Vue de cas d'utilisation

  • Cas normal : comment tout s'enchaine
    • Sélection d'un sous ensemble des cas d'utilisations définis dans les spécifications pour :
      • Décrire les interactions entre éléments du système (objets / composants / processus)
      • Illustrer et valider le design d'architecture
    • Attention de ne pas réécrire les spécifications du système
  • Cas « start-up avec cahier des charges sur la nappe »
    • L'architecture est le seul document qui sera écrit ... autant y ajouter les cas d'utilisations vitaux pour la réalisation
  • Formats suggérés :
    • Diagrammes de séquence
    • Diagramme de cas d'utilisation (et diagrammes attenants)


Aéropole de Charleroi-Gosselies
Avenue Jean Mermoz 28
B-6041 Charleroi - Belgique

twitter.com/@CETIC
twitter.com/@CETIC_be
linkedin.com/company/cetic
info@cetic.be
+32 71 490 700

Architecture logicielle à base de la méthode architecture 4+1 vues




Rami Sellami

Senior researcher

+32483588850
rami.sellami@cetic.be