Qu’est ce qu’un modèle ? fondamentaux de modélisation

Un modèle est une représentation d’une réalité matérielle ou immatérielle, un modèle n’est PAS cette réalité. Modéliser est donc l’acte de représenter nos concepts et les objets de notre réalité. Cette réalité pouvant être immatériel et exister uniquement comme construction mentale, par exemple un compte bancaire n’a pas d’existence physique mais est une réalité pour beaucoup de gens, le relevé de compte papier rend concrète et matérielle la réalité du compte bancaire.

 

 

 

Un modèle est forcément une description limitée et orientée de la réalité. Il est impossible de décrire de manière absolue la réalité à des fins descriptives ou prédictives, sans même parler de l’intérêt d’une telle démarche (c’était l’utopie de Laplace et du déterminisme associé au paradigme mécaniste du XIXéme siècle). J’aime bien cette citation « Tous les modèles sont faux, certains sont utiles » de G. Box, statisticien, qui illustre bien qu’un modèle n’est pas conçu pour être vrai et représenter parfaitement la réalité mais pour répondre à un usage. Cela me permet d’introduire la notion de validité d’un modèle, en effet un modèle n’est ni bon ni mauvais, un modèle est juste adapté ou pas à un usage.

Que va contenir mon modèle ?

Un modèle va décrire la réalité avec un certain filtre, en utilisant certains concepts permettant de classifier la réalité observée. Par exemple, un processus de demande de prêt bancaire sera décrit avec les notions d’événements (dossier client déposé), d’activités (vérifier les pièces, remplir le dossier, demander assurance), de transitions (les conditions de revenus sont respectées alors le dossier est transmis à  la direction).

De manière très simplifié, un modèle décrit toujours une réalité observable ou, encore mieux, mesurable et donc numérique.

La réalité observable peut être décrite en répondant aux questions : « Quoi ? Qui ? Quand ? Où ? Comment ? » ainsi qu’en décrivant les contraintes qui définissent les limites du modèle. Un modèle va donc contenir :

• Des objets – quoi : objets ou concepts, dénommés par un nom ou groupe nominal. Ces objets peuvent être catégorisés suivant leur identifiant et leur cycle de vie : à savoir, pour reprendre les termes du Domain Driven Design, des entity et des value object selon respectivement que l’objet est identifiable de manière unique et clairement distinguable (ex : un client et son numéro client interne, une entreprise et son SIREN) ou que seul ses attributs importent (ex : un billet de 10 €). A ces objets sont souvent associés les notions de comptes (un compte contient des choses de valeurs : biens ou argent, qui peuvent être ajoutés ou supprimés par des mouvements) et de stock (voir Analysis patterns de M. Fowler).
• Des tiers – qui : tiers physique/moral (Party en anglais) ou rôle, dénommés par un nom se rapportant à cette entité ou ce rôle.
• Des éléments temporels – quand : l’utilisation du temps dans un modèle est souvent associé aux instants (qu’ils soient absolus : le 22 janvier 2011 à 19H00, ou relatif : 2H après la réception du paiement) qui sont eux mêmes souvent associés à un événement déclencheur qui constate un changement ou un fait intervenu à l’extérieur du système (ex : bon de commande du client reçu, facture reçue). Mais également un événement interne qui constate un changement intervenu sur un objet du système ou sa création (ex : factures émises qui correspondent à la création de l’objet puis son impression avec un système d’éditique). Concernant le temps, un modèle va également comporter des durées (ex : 10 jours) et des intervalles de temps (entre deux instants ou la combinaison d’un instant et d’une durée).
• Des endroits – où : rarement décrit dans les modèles que je rencontre ou alors rarement formalisé (de simples chaînes de caractères décrivant une adresse ou un bâtiment), mais cela va à mon avis changer avec les fonctions de géo-localisation de nos appareils mobiles qui permettent une localisation absolue sous forme de coordonnées terrestre.
• Des actions – comment : décrit ce que font les acteurs humains ou machine sur les objets ou leur représentation, ainsi que l’enchaînement de ces actions. Le comment est d’ailleurs le talon d’achille du paradigme objet où la fonction n’est pas un concept de premier ordre et les outils du paradigme fonctionnel sont un bon complément pour décrire les transformations intervenant sur le quoi. D’ailleurs, l’utilisation de pseudo-code est souvent un moyen très efficace pour décrire les transformations. Quant aux actions des tiers en dehors du système, le modèle va souvent décrire la planification de ces actions futures réalisées par les tiers. Ce genre de modèle générique se retrouve d’ailleurs dans les systèmes de workflow avec la notion de tâche, de corbeille de tâches, de date d’échéance, etc.

Ces caractéristiques sont très larges, par exemple dans le cas de modèle en physique, le quoi est majoritairement numérique, le comment décrit les fonctions de transformations, les équations décrivent les contraintes du modèle, quant au quand il transparait avec la notion de dérivée. Mais bon, vous êtes sur un blog d’une boite de conseil en informatique et pas d’un constructeur d’accélérateurs de particules 🙂

Les contraintes

Un modèle va ensuite inclure des contraintes sur les liens entre les différents éléments qu’il contient. Par exemple, le concept « Commande » est lié à un et un seul « Client », le montant maximal d’un virement est de 1000 €, etc. Le langage de modélisation UML inclut un langage déclaratif pour ces contraintes : OCL. Pour des raisons de clarté et de compréhensibilité, je trouve qu’un texte libre exprimant la contrainte est souvent suffisant.

Les concepts utilisés dans le modèle : le méta-modèle

Un modèle va contenir ces concepts de base (qui, quoi, quand, où, comment, contraintes) mais également d’autres ou un approfondissement de ces concepts permettant de préciser ce que le modèle représente de la réalité (par exemple les concepts ensemblistes comme dans Alloy ou les diagrammes d’états UML qui précise le cycle de vie de l’objet). Le choix du méta-modèle est donc crucial afin d’aboutir à une représentation de qualité. Dans notre domaine informatique, le paradigme objet est le méta-modèle incontournable qui s’est imposé pour la description et l’exécution de modèles grâce à sa richesse et sa pertinence pour décrirer le monde réel, également grâce aux nombreux langages de programmation ayant adoptés ce paradigme. Ses fondations sont solides mais sont toutefois remises en cause actuellement quant à leur complétude : le retour en force des paradigmes fonctionnels, événementiels et  concurrents en est l’illustration.

Conclusion

Cet article présente les fondamentaux de la modélisation et exclut volontairement la représentation que peuvent prendre les modèles (graphique, textuel, etc.) ainsi que les outils intellectuels associés (niveaux d’abstraction, encapsulation, etc.), cela fera l’objet des prochains articles avec également des points de vue sur les activités de modélisation, de conception et les formes qu’elles peuvent prendre. Pour au final obtenir le meilleur de l’excellent outil qu’est le modèle afin de communiquer, réfléchir et transformer nos organisations et nos systèmes qui les structurent.