MODULE No 01

Titre : Analyse du titre du cours : « Génie logiciel : analyse et modélisation »

But : Avoir une idée claire de la signification des termes qui composent le titre du cours pour mieux en saisir le contenu.

Antécédents : Aucun.

Corps : Commençons par voir la signification de chaque mot et prenons-les dans l’ordre pour ne pas en privilégier aucun.

a. Génie Logiciel. « L’application d’une approche systématique, maîtrisée, quantifiable au développement, à l’exploitation et à la maintenance du logiciel : c’est-à-dire l’application de l’ingénierie au logiciel » (IEEE std. 610.12). Mais qu’est-ce que le logiciel ? Dans le langage courant par « logiciel » on entend le programme (malheureusement, souvent, les étudiants en informatique aussi considèrent que le logiciel n’est que le programme). Dans notre cours nous adopterons la définition de IEEE 610.12 : « les programmes, les procédures, et la documentation associée et les données qui concernent le fonctionnement d’un système informatique. » Donc un logiciel est constitué d’un ensemble d’artefacts qui couvrent toute « la vie » du produit : de l’idée initiale (naissance) au retrait finale (mort).

b. Analyse. 1) « Décomposition d'une chose en ses éléments, d'un tout en ses parties. » 2) « Examen permettant d'isoler ou de discerner les différentes parties d'un tout » (TLF): Et en GL ? Le même sens : décomposer le « problème » en des problèmes plus petit pour essayer de trouver plus facilement des solutions.

c. Modélisation. Création de modèles, c’est-à-dire une« Représentation simplifiée et plus ou moins formalisée d'un processus, d'un système » (Le Robert). « Une simplification de la réalité, créée pour mieux comprendre le système à créer. » (Manuel de UML) Ce qui semble être important c’est « simplification », c’est-à-dire le fait que l’on a devant nous quelque chose de plus facile à manipuler intellectuellement ou physiquement. Le modèle atomique de Bohr est un bon exemple de simplification de la réalité des atomes. Avant la fin de la session nous ferons une critique de la modélisation telle que définie actuellement en GL.

La figure suivante présente le lien entre le problème qui est dans le monde « réel » et le modèle (ou description) qui est sur papier (ou sur disque). Le papier et le disque sont eux aussi dans le monde « réel » mais les deux mondes réels ne doivent pas être confondus. Si on détruit un disque qui décrit un programme pour lancer une bombe d’un avion on ne détruit ni l’avion, ni la ville ciblée ! Ce qu’on détruit, c’est un artefact qui fait partie du logiciel et cette destruction aura un impact sur le projet (et éventuellement sur la carrière de celui qui a permis la destruction).

Dans la figure on voit deux éléments complexes du monde qui, à l’aide d’un processus d’abstraction, sont transformés en deux éléments simple (carré et rectangle). Dans le développement du logiciel à partir d’un certain moment on « oublie » le monde dans lequel il y a le problème et on travaille sur les éléments simples que l’on a extraits lors de l’analyse. Mais, un beau jour, quand le programme interagira avec le monde où il y a le problème il faudra que tout ce que l’on a fait en partant du modèle nous donne les résultats escomptés.

Et si l’on n’a pas ce que l’on attendait ? Il y a deux possibilités principales :

1) il y a eu des erreurs lors de la simplification du problème en créant le carré et le rectangle (on aurait dû créer des cercles, par exemple).

2) il y a eu des erreurs dans le passage du carré au code.

Les deux types d’erreurs sont fort différents et demandent des approches et des méthodes assez différentes

Notre cours — puisque il s’agit d’analyse et modélisation — sera surtout concerné par le premier type d’erreur. C’est-à-dire que, tout au long du cours, nous allons essayer de répondre à la question : est-ce que nous sommes en train de décrire correctement et avec assez de détail le monde du problème de manière telle que l’on puisse « facilement » créer un programme qui aide à le résoudre ?

En résumé ce cours devrait permettre d’apprendre à trouver les parties qui constituent un tout, décrire le tout et ses parties de manière que l’on puisse comprendre plus facilement et tout cela devrait être fait avec des méthodes inspirées de l’ingénierie.

Bonne chance !

Conséquents :

· Être capable de redire avec ses propres mots les définitions.

· Avoir saisi les différences entre les différentes définitions.

· Connaître l’existence de la norme (IEEE 610).

Note 01 : Les définitions présentées ci-dessus n’ont pas été données pour que l’on les retienne par cœur mais pour commencer à vous introduire aux concepts parmi lesquels vous circulerez pendant quinze semaines. En disant qu’il ne faut pas les connaître par cœur, je ne veux pas dire que l’on ne doive pas être à même de les redonner avec ses propres mots sans s’éloigner trop de l’original.

Note 02 : Voici deux adresses Internet qui peuvent être très utiles pour votre travail d’informaticien et pour votre culture générale :

TLF : http://atilf.atilf.fr/dendien/scripts/tlfiv4/showps.exe?p=combi.htm;java=no;

Synonymes : http://elsap1.unicaen.fr/dicosyn.html

Je vous invite à mettre ces adresses dans vos favoris.