Conception des systèmes d'information (CSI)

IUP MIAGE de Nantes

logo MEDAL

Alain VAILLY

Module d'Enseignement D'Architecture Logicielle

Le texte qui suit présente l'enseignement des spécifications tel qu'il est pratiqué à l'IUP MIAGE de Nantes, avec ses principes, ses objectifs, sa composition, son contenu, les prérequis et une bibliographie. Un pointeur sur des élements complémentaires (base de présentations Powerpoint, annales d'examens...) complète ce document.

Il comprend également quelques documents mis à disposition des étudiants par les enseignants. La plupart du temps, ceux-ci (ie. les documents, pas les enseignants) sont en format pdf.

Date de la dernière mise à jour : 7 juillet 2004.


a) principes généraux :

(extrait de la préface d'un ouvrage paru sur le sujet -cf
bibliographie)

Au travers d'expériences diverses d'enseignement, de recherche et de rencontres avec les professionnels du développement du logiciel, nous avons pu forger notre intime conviction que, par delà la multitude de méthodes existant sur le marché, seule une petite dizaine de modèles devaient être connus des étudiants comme des praticiens pour pouvoir comprendre les concepts composant les méthodes. D'une certaine façon, tout se passe comme si, alors que les recettes de cuisine sont aussi nombreuses que les chefs-cuisiniers, elles ne faisaient appel qu'à un ensemble réduit d'ingrédients, toujours les mêmes. La compréhension de toute nouvelle recette en est grandement facilitée.

En tant qu'enseignants de Conception de systèmes d'information, nous voulons placer notre enseignement dans la durée et avons depuis longtemps renoncé à former des étudiants spécialistes d'une seule méthode. Ne pouvant définir avec précision l'avenir de la CSI (quelle sera la méthode qui sera la plus utilisée en 2005 ? en 2010 ?), n'ayant aucune idée de l'évolution de la carrière de nos étudiants (seront-ils embauchés dans une PME ? dans un grand groupe ? en France ? à l'Etranger ?), nous avons mis l'accent sur les modèles de base. Ce cours en présente huit, certains de façon plus approfondie que d'autres.

Nous avons choisi de regrouper les présentations par rapport aux trois dimensions d'un problème, informations, fonctions et comportement. Sont ainsi successivement abordés : le modèle entité-association-propriété, le modèle relationnel, les automates, les réseaux de PETRI, les arbres JSD, les expressions régulières, les diagrammes de flots de données, les modèles de traitements de Merise. Munis de cette boîte à outils, le lecteur peut s'adapter en souplesse à des contextes très variés. En effet, dans le domaine des méthodes, la culture d'entreprise prédomine et les méthodes standard sont adaptées pour tenir compte des applications et du savoir-faire de l'entreprise.

Ce travail méthodologique nous semble important. Il permet à l'étudiant, par la confrontation, par l'étude des analogies et des différences, de mieux fonder ses connaissances. Il lui offre aussi (à nos yeux, c'est un objectif) la vision d'un monde méthodologique très riche en symboles et très varié. De la même façon, il est nécessaire de fournir quelques repères tels que la vision en trois axes des systèmes d'information et la confrontation finale des points de vue (pour assurer la cohérence de l'ensemble). Dans l'absolu, il faut que l'étudiant puisse être aussi à l'aise avec les modèles que nous avons présenté qu'un mathématicien qui, pour résoudre un problème, effectue un changement de variables. Changer de modèle doit être aussi facile que changer de variable.

La maîtrise, même absolue, de ces huit modèles ne suffit hélàs pas ! Certes, pour développer une solution avec la méthode SSADM, faut-il connaître le modèle relationnel, les arbres JSD et les diagrammes de flots de données. Certes, pour faire le même travail en OMT, faut-il connaître le modèle E-A-P (modifié), les automates et les diagrammes de flots de données. Mais encore faut-il savoir dans quel ordre les étapes doivent-elles être franchies. Il manque une démarche. Enseigner une démarche n'est pas véritablement le but de ce cours. Nous faisons porter notre effort sur les techniques, les paradigmes. Nous proposons des démarches de modélisation et des règles de vérification pour chacun des formalismes. Le processus de développement est bien plus ambitieux car il définit chaque étape, chaque tâche du développement, chaque document et chaque modèle produit au cours des tâches. L'agencement de ces éléments pour produire un logiciel dans un temps bien déterminé est l'enjeu majeur des méthodes.

Nous sommes persuadés que hormis les grandes lignes que sont l'analyse, la conception, la réalisation, le test et la mise en production, l'acceptation d'un processus de développement standard n'est pas pour demain. De nombreux facteurs influent sur le processus : taille des projets, moyens mis en oeuvre, type d'application, expérience de l'équipe de développement. Contrairement au formalisme, le processus dépend intimement de la méthode utilisée et surtout du savoir-faire et l'expérience de ceux qui l'utilisent. Bien entendu, nous ne pouvons pas faire une impasse totale sur cet aspect des choses. Ainsi, dans nos cours, nous avons pu enseigner la méthode Merise, qui s'adapte à n'importe quelle application de type gestion (beaucoup de données et des traitements transactionnels).

Nous abordons aussi ce travail méthodologique dans les deux contextes très différents que sont la culture objet et la culture formelle. La culture objet induit un développement par et pour la réutilisation. L'objectif clairement affiché est de rentabiliser et de fiabiliser le développement en construisant de petits modules aisément adaptables et réutilisables. Ces modules (objets) encapsulent des données, du contrôle et des fonctions de manière cohérente. Cette culture est symbolisée à l'heure actuelle par la notation Unified Modeling Language (UML). Pourquoi UML ? Parce que c'est une "méthode" (nous y mettons des guillemets, car il s'agit plutôt d'un langage que d'une méthode, dans le sens où il n'y a pas de démarche proposée dans UML) émergente et qu'il nous apparaît aujourd'hui à peu près évident que nos étudiants croiseront un jour sa route. Ils doivent donc la connaître.

La culture formelle est celle dans laquelle il nous faut nous placer quand nous abordons des logiciels que nous pourrions qualifier de logiciels "à risque". Les problèmes qu'ils contribuent à résoudre sont sensibles, dans la mesure où ils concernent des personnes physiques (logiciels embarqués, par exemple) ou où leurs enjeux (financiers notamment, mais pas seulement) sont très importants (logiciels de salles de marchés, par exemple). Les solutions informatiques mises en place doivent, dans ce contexte-là, être de bien meilleure qualité que les autres. Il n'est pas rare que, dans ce cas-là, il faille spécifier le logiciel en faisant appel à des méthodes formelles, méthodes dans lesquelles la démarche est rigoureuse, la notation précise et les preuves possibles (et obligatoires). Nous proposons, dans le cadre des enseignements proches, d'enseigner Z.

Comme leur nom l'indique, ces cultures désignent plus des formalismes que des processus de développement ; nous revenons au point de départ (!). En fait, elles représentent aussi deux formes de développement. Le développement avec UML est itératif, par morceaux (les cas d'utilisation), et se base sur une architecture adoptée pour le système (client/serveur, distribué, etc). Le développement avec Z est linéaire et basé sur un raffinement progressif de la spécification au programme.


b) objectifs affichés :

En vrac, et sous forme d'une liste que l'on pourrait qualifier de liste "à la Prévert", les objectifs suivants sont affichés :

fin de l'IUP1
connaissance de techniques permettant de modéliser les données et les fonctions d'un problème, maîtrise des notions utilisées dans ACCESS.
fin de l'IUP2
connaissance de techniques permettant de modéliser le comportement d'un système.
fin de l'IUP3
connaissance et maîtrise de la "méthode" UML (ie. notation UML et processus UP) et sensibilisation aux spécifications formelles (au travers de la notation Z).

Un étudiant qui souhaite intégrer directement la deuxième ou la troisième année d'IUP doit donc vérifier qu'il a bien atteint ces objectifs. Il pourra, si tel n'était pas le cas, le faire en travaillant par lui-même (l'ouvrage référencé 1 dans la bibliographie -c'est le même qui sert pour les deux premières années- lui fournira tous les éléments théoriques dont il pourrait avoir besoin).


c) "carte" de l'enseignement de CSI dans le cursus :

NB : chacun pourra le vérifier sur le schéma suivant, ce cours est appelé Spécification à l'IUP MIAGE de Nantes.

Ci-après la répartition des enseignements dits de Spécification (fond semé de points) et des matières connexes (fond hachuré) pour les deux premières années, toutes filières confondues, et de troisième année, filière ISI.

Compte-tenu de la taille des plages, le "gros" du travail est effectué en période 2 pour l'IUP1, en période 3 pour l'IUP2 et en période 1 pour l'IUP3. Les interventions prévues en période 1 en IUP1 et en IUP2 sont des mises-à-niveau.


d) contenu des enseignements :

Ci-après un plan plus détaillé des enseignements correspondant à ce qui a été appelé le "gros" du travail dans le paragraphe précédent :

NB : un plan encore plus détaillé peut être obtenu dans les ouvrages référencés 1 et 2 dans la bibliographie. La quasi-totalité des enseignements magistraux ont, en effet, fait l'objet d'une publication en librairie.


e) attentes de l'enseignement de CSI vis-à-vis des autres enseignements et pré-requis :


f) bibliographie indicative :

  1. Pascal ANDRE et Alain VAILLY. Conception des systèmes d'information ; panorama des méthodes et des techniques. Collection Technosup, Editions Ellipses. Janvier 2001. ISBN n° 2-7298-0479-X.
  2. Pascal ANDRE et Alain VAILLY. Spécifiation des logiciels ; Deux exemples de pratiques récentes, Z et UML. Collection Technosup. Editions Ellipses. Juin 2002. ISBN n° 2-7298-0774-8.
  3. Pascal ANDRE et Alain VAILLY. Exercices corrigés de conception logicielle. Modélisation des systèmes d'information par la pratique. Collection Technosup. Editions Ellipses. Janvier 2003. ISBN n° 2-7298-1289-X.
  4. Pascal ANDRE et Alain VAILLY. Exercices corrigés en langage Z ; Les spécifications formelles par l'exemple. Collection Technosup. Editions Ellipses. Février 2004. ISBN n° 2-7298-1942-8.
  5. Pascal ANDRE et Alain VAILLY. Exercices corrigés en UML ; Passeport pour une maîtrise de la notation. Collection Technosup. Editions Ellipses. Septembre 2003. ISBN n° 2-7298-1725-5.

  6. ACSIOME. Modélisation dans la conception des systèmes d'information. Editions MASSON. 1990. ISBN n° 2-225-81970-X
  7. Jean-Paul MATHERON. Comprendre Merise ; outils conceptuels et organisationnels. Editions EYROLLES. 5e édition. 1998. ISBN n° 2-212-07502-2
  8. Jean-Marie PROTH et Xialan XIE. Les réseaux de PETRI pour la conception et la gestion des systèmes de production. Editions MASSON. 1995. ISBN n° 2-225-84649-9
  9. Mike SPIVEY. La notation Z. Editions MASSON. 1994. Traduction de Michel LEMOINE.
plus un des derniers ouvrages sur UML, à choisir le plus tard possible, compte-tenu de l'évolution rapide des concepts sous-jacents.

Les ouvrages référencés de 1 à 5 dans la liste précédente correspondent exactement aux cours dispensés dans cet enseignement. Des informations complémentaires sont disponibles sur Internet (errata, annonces diffusions documents...).

tome 3
tome 1
tome 4
tome 2
tome 5
ref. 3 : exercices IUP1 et IUP2
ref. 1 : cours IUP1 et IUP2

ref. 4 : exercices IUP3

ref. 2 : cours IUP3

ref. 5 : exercices IUP3

Vous voulez nous signaler des erreurs ; Vous n'avez pas compris quelque chose ; Vous avez apprécié ; Vous n'aimez pas...

Dites-le nous en nous envoyant un message. Nous vous répondrons.