Accueil
 Sommaire
 1  Objectifs de ce cours de modélisation orientée objet
 2  Généralités sur la modélisation orienté objet et sur UML
 2.1  Principes de la modélisation
 2.2  Pourquoi et comment modéliser en orienté objet
 2.3  Unified Modelling Language (UML)
 2.4  Cinq façons de voir un système informatique: les 4+1 vues de Kruchten
 2.5  Phases de la modélisation, cycle en V
 2.6  Rôle de l'expression des besoins
 2.7  Rôle de l'analyse
 2.8  Rôle de la conception
 QCM
 3  Analyse, vues cas d'utilisation et processus
 4  Analyse et conception, aspects statiques de la vue logique
 5  Analyse et conception, aspects dynamiques de la vue logique
 6  Conception, aspects langage et technique
 7  Conception, vues développement et physique
 8  Conclusion
 9  Bibliographie

 Contacts

W3C validator

Département INF  
 Conception et programmation orientées objet


2.1 Principes de la modélisation

  • Objectif principal de la modélisation = maîtriser la complexité
  • Modéliser = abstraire la réalité pour mieux comprendre le système à réaliser / réalisé
  • Le modèle doit être relié au monde réel
    • Par exemple : l’existant avant les travaux, le réalisé, le restant à réaliser
  • Un modèle peut être exprimé avec différents niveaux d’abstraction / raffinement
    • Par analogie : répartition électrique de l’immeuble, de la cage d’escalier, de l’appartement, de la pièce
  • Une seule « vue » du système n’est pas suffisante
    • Les intervenants multiples du projet informatique possèdent des préoccupations multiples
      • Par analogie : plan de masse, vues de face et de côté, schéma électrique, plan de plomberie, plan de calculs de construction

    précédent     suivant 


Le processus de modélisation vise à obtenir une solution acceptable du système informatique. La solution finalement retenue n’est pas obtenue en une seule itération. Plusieurs étapes sont nécessaires ; ces étapes successives permettent de raffiner le niveau de détails du système à réaliser. Les premières étapes donnent une vision à très gros grains et permettent d’avancer dans la compréhension du problème.

Par analogie avec un architecte qui dessine plusieurs plans pour concevoir une maison, la conception d’un système informatique est organisée dans une architecture de modélisation qui prévoit plusieurs visions du même problème pour aider à trouver une solution acceptable. La cohérence entre les différentes vues du système est importante, chaque vue ciblant des catégories différentes d’intervenants ayant des besoins différents.

Lorsqu’une équipe collabore au développement d’un système informatique (de taille conséquente), trop de détails empêchent d’avoir une vue synthétique compréhensible par tous les participants (en anglais, stakeholders)1 au projet informatique, et trop peu d’informations conduit à des interprétations différentes et contradictoires. À partir d’une certaine taille et complexité, l’informatisation d’un système nécessite un processus de modélisation. Quelque soit la taille du problème, une phase de modélisation est une aide au développement du système informatique. Cependant, souvent, le nombre de personnes qui participent à la résolution du problème (clients, équipe de développement, équipe de maintenance) est un des éléments jouant fortement dans la décision de passer par une phase de modélisation. Plus le nombre de personnes est important, plus les échanges de documents sont importants. Le processus de modélisation est nécessaire pendant toute la durée de vie du projet : discussion avec les clients, analyse du système à réaliser, documentation commune entre les développeurs, etc. La pérennité de l’informatisation réalisée est un autre élément justifiant la décision de modéliser le système. En effet, le développement mais aussi la maintenance corrective et la maintenance évolutive du système bénéficient de l’existence du modèle en tant que documentation de référence.

Le modèle permet donc de spécifier le système à réaliser/réalisé, de valider le modèle vis-à-vis des clients, de fournir un guide pour la construction du système pour organiser les structures de données et le comportement du système, et de documenter le système et les décisions prises.

Cf. le glossaire pour la définition des termes « modèle », « processus de modélisation », « élément de modèle ».

D. Conan, C. Taconet, C. Bac, Télécom SudParis, CSC 4002, Octobre 2015

1.Il est d’usage d’utiliser le singulier pour nommer collectivement les participants possédant le même rôle dans le projet. Il est plus important de nommer les rôles et non de préciser si le rôle est tenu par une personne ou par une équipe. Par conséquent, le pluriel utilisé ici à « stakeholders » indique la multiplicité des rôles.