Modlisation des Systmes d'Information

Partie I: Introduction l'Ingnierie du Logiciel I. Introduction :

Le dveloppement d'applications dans le domaine de l'informatique de gestion est aujourd'hui gnralement entendu comme contribution au dveloppement des systmes d'information. Le systme d'information intgre les dimensions organisationnelles, humaines et technologiques de la gestion de l'information d'entreprise. Ainsi, le dveloppement de systmes d'information toujours plus complexes avec des problmatiques beaucoup plus ambitieuses que par le pass, caractrise-t-il aujourd'hui le terrain d'action de l'informatique de gestion. Ces nouvelles contraintes obligent linformaticien acqurir la matrise de nouveaux modles conceptuels et logiques, mettre en uvre des outils de haute productivit en matire de dveloppement. Elles replacent le gestionnaire dans sa responsabilit organisationnelle en matire de conception et de spcification dapplications informatiques. Les apports conceptuels de lorient objet semblent directement rpondre aux besoins des utilisateurs, conditionns dans leurs exigences par les standards de fait des interfaces graphiques et des logiques de fonctionnement clients-serveurs consacres notamment par les extensions de l'intgration au monde Internet. Les nouvelles tendances du dveloppement peuvent apparatre comme une nouveaut . Aprs tout, les mthodes et outils du dveloppement dapplications sinscrivent dans une tradition dvolution permanente : des mthodes cartsiennes vers les mthodes systmiques puis les mthodes orientes objet, des langages procduraux vers les L4G et les langages objets, l'intgration d'applications d'entreprises (EAI) Ces nouvelles tendances peuvent tre apprhendes partir de diffrents indicateurs dvolutions particulirement significatifs :
La

conscration de la prise en compte du point de vue de lutilisateur dans la logique de

fonctionnement des applications (ergonomie, convivialit, souplesse dutilisation). La "fentre" est le lien entre lapplication et lutilisateur qui dialogue par des actions, notamment sur des objets graphiques.
Les

nouvelles architectures permettent de rapprocher les donnes et les traitements de leurs

utilisateurs, damliorer leur confort de travail (en rduisant par exemple les temps de rponse), daccrotre lautonomie des sites distants des ressources informatiques centralises, de minimiser le trafic sur le(s) rseau(x). Ces amliorations technologiques posent cependant des problmes de cohrence des donnes rparties dans le cas de traitements coopratifs. 1

 Lapproche

oriente objet (mauvaise traduction d "object-oriented") cest--dire utilisant

rsolument les objets dans les techniques danalyse et de conception, est l. Les avantages de cette technologie sont bien connus : rutilisation des composants logiciels (typage, encapsulation, hritage, polymorphisme...), maintenabilit accrue des applications, cohrence avec la vision que lutilisateur a du systme, approche dcentralise faiblement procdurale (les objets communiquent en senvoyant des messages). Cependant, les approches par les objets sont plus adaptes la conception et au dveloppement de logiciel qu la conception de systme dinformation (notamment dans les aspects organisationnels).
Le

succs des outils de dveloppement de type programmation vnementielle qui dispensent de

paramtrer et dappeler les fonctions de base complexes du systme d'exploitation ou API Application Programming Interface. Ces outils comme Visual Basic, Delphi ou Powerbuilder, dpassent lutilisation habituelle de processus de conception et permettent des techniques du type RAD (Rapid Application Development). A la base, une nouvelle lecture du systme d'information (SI) traduit l'volution du lien entre l'informatique et l'organisation de l'entreprise : le SI devient un vecteur de changement, voire le vecteur principal du changement dans l'organisation, sa conception suppose donc d'autres approches. La spcification des systmes d'information mobilise des modles qui relvent majoritairement aujourd'hui de l'approche objet : ainsi la rfrence UML semble s'imposer mais de manire mesure en informatique de gestion. Cette suprmatie ne saurait cependant faire oublier les autres rfrences classiques de l'informatique de gestion ni l'mergence d'une rflexion portant sur l'ingnierie des besoins. Au plan technologique, la gnralisation croissante des systmes d'information distribus permet d'aborder de nouvelles architectures dans le domaine de la communication, comme dans celui de la gestion des connaissances. L'enjeu est aujourd'hui de mettre en place la meilleure solution, aussi bien technologique qu'organisationnelle, pour " concevoir un systme d'information numrique qui permette l'acteur, son poste de travail, dans sa situation, d'obtenir les informations circulantes, de partager ses connaissances et d'accder aux informations, sources de connaissances, qui lui sont ncessaires pour comprendre et rsoudre les problmes qu'il rencontre, prendre des dcisions, exercer son activit et capitaliser les connaissances produites dans l'exercice de cette activit."

Une nouvelle lecture du systme d'information Aux trois rles traditionnels jous par l'information dans les organisations : support pour l'action, mmoire des activits, aide la prise de dcision, les technologies de l'information et de la communication ont ajout des fonctions considrables qui largissent l'tendue des systmes d'information et en modifient profondment la structure. Ce phnomne est particulirement visible travers, par exemple, l'exigence systmatique de qualit ou l'mergence de structures informationnelles virtuelles lies aux structures relles. L'approche traditionnelle voit l'organisation comme un systme, lui-mme dcompos en trois soussystmes en interaction : le systme oprant, le systme d'information et le systme de pilotage. Dans cette vision, le systme d'information joue le rle de mmoire entre le systme de pilotage (la direction) et le systme oprant (la sphre de production). Selon cette approche, le SI est une reprsentation abstraite du monde rel qui permet d'asseoir le processus de conception de la base de donnes support du SI. La confusion ou l'intgration entre le systme d'information et le systme informatique tient autant au phnomne de numrisation croissante de la ralit informationnelle qu' l'volution dterminante du rle de l'informatique dans l'organisation. L'volution du lien entre l'informatique et lorganisation: Le sigle SIC dsigne le Systme d'Information et de Communication ; il a t propos notamment par Robert REIX. Nous retenons la dfinition propose par Chantal Morley, Jean Hugues et Bernard Leblanc[3] : "Le systme d'information est la partie du rel constitue d'informations organises, d'vnements ayant un effet sur ces informations, et d'acteurs qui agissent sur ces informations ou partir de ces informations, selon des processus visant une finalit de gestion et utilisant les technologies de l'information." Par ailleurs, le systme informatique est dfini comme " un ensemble organis d'objets techniques matriels, logiciels dont la mise en uvre ralise l'infrastructure d'un systme d'information." Dans la ralit du fonctionnement des organisations, le systme informatique ne prend pas en charge la totalit des situations de gestion. D'une part, parce qu'un grand nombre de modalits de fonctionnement ne sont pas formelles, d'autre part, parce que l'histoire de l'laboration du logiciel, son origine, dtermine souvent un formatage des rgles de gestion introduites comme des 3

contraintes. Ainsi il faut admettre qu'une partie de l'organisation chappe la couverture du systme et qu'une part des procdures restera "manuelle" ou " informelle". Du systme d'information au systme informatique : la modlisation Entre la pesanteur de l'existant qui empche souvent de tirer le meilleur parti des technologies disponibles et la nature mme de l'expression des besoins, base sur un travail d'analyse, de critique, de rflexion et de crativit, la conception de SI exige le recours des modles qui favorisent rigueur et communicabilit entre les diffrents acteurs : informaticiens et gestionnaires. Le but de la modlisation d'un SI est d'aboutir une spcification qui soit une reprsentation simplifie de sa ralit passive ou active. Si l'activit de modlisation n'est pas propre au domaine des SI, elle y prend une importance croissante lie la complexit des nouveaux SIs. Les ingrdients de la modlisation des SIs sont bien connus : modle, langage, dmarche, outil et mthode. Un modle est un instrument de travail intellectuel et pratique qui permet de reprsenter une ralit observe l'aide d'un formalisme conventionnel et de rgles de reprsentation de type logicomathmatique. Certains modles sont limits aux questions de structuration des informations (modle relationnel n-aire, modle entit-association, modle relationnel binaire, modle statique objet), d'autres traitent des questions lies la dynamique des systmes (modle des automates d'tats finis, modles des rseaux de Petri). Afin d'assurer la cohrence de la modlisation, on a recours, dans chacun des modles, des contraintes ou des rgles (contraintes d'intgrit, cls, dpendances fonctionnelles, pr-condition, post-condition, synchronisation, squence). Cela peut tre aussi le cas entre modles. De nombreux auteurs tirent argument de cette diversit de modles de rfrence pour argumenter en faveur des modles de type objet. La meilleure coordination de l'ensemble des modles spcifiques est ralise autour du concept d'objet pour en unifier les diffrentes perceptions : informationnelle, fonctionnelle, volutive, organisationnelle, logicielle Les langages de modlisation sont les conventions d'criture et de reprsentation formelle de modles ; ils vont du langage naturel aux langages formels en passant par des diagrammes, graphiques Ils traduisent le souci de favoriser la communication entre le dveloppeur et le gestionnaire en rduisant la complexit. Le processus de modlisation d'un SI est un processus d'abstraction complexe qui fait appel des approches utilises dans d'autres domaines scientifiques : classification, association, agrgation, 4

gnralisation Si ces techniques sont soumises des contraintes par les types de modles retenus, l'ensemble du processus doit tre organis selon une dmarche rationnelle, reproductible par le concepteur. Il s'agit de dfinir l'enchanement des modles selon les besoins et la nature du SI (ou ventuellement selon le savoir-faire du concepteur). Historiquement, cet enchanement qualifi de "cycle de vie du logiciel" est pass d'une forme linaire (cycle de vie en cascade) des formes itratives et incrmentales (cycle de vie en spirale, en fontaine) mieux adaptes. Des outils logiciels facilitent le processus de modlisation en fonction de diverses entres : recensement des besoins, contrle de cohrence, conception de la base de donnes, conception de l'architecture logicielle, documentation, prototypage, simulation, gnration de code, gnration de tests, rtroconception, rutilisation de composants, gestion et suivi de projets La matrise de cette diversit des outils de gnie logiciel est facilite par leur intgration dans des plates-formes dites "ateliers de gnie logiciel" (AGL) et ralise de diffrentes manires: rfrentiel, bus de messages, etc. Les rfrentiels sont gnralement fonds sur des modles de type entit-association. Les auteurs considrent que les AGL constituent actuellement une bonne rponse en termes d'aide la modlisation en prenant en charge correctement deux dimensions : assistance au dessin des diagrammes spcialiss et gestion d'une base des lments modliss. Leur faiblesse se situe aux niveaux des contrles de cohrence des spcifications ralises, de l'absence de guidage dans la dmarche, du manque de traabilit entre les modles conceptuels et les lments logiciels "Une mthode est une combinaison de ces composantes essentielles que sont les modles, les langages, les outils et les dmarches. De ces composantes, on peut tirer deux avantages importants : fixer un vocabulaire et des normes de spcification prcises, mais aussi organiser une conception collective (par opposition une conception individuelle)."[1] Ces aspects sont des constantes historiques des mthodes que l'on peut classer en quatre catgories (gnrations):
les les

mthodes dites d'analyse, comme CORIG, dans les annes 1960 ; mthodes dites cartsiennes, comme SADT, des annes 1970 qui sont le prolongement des

prcdentes, compltes par une dcomposition fonctionnelle des traitements et une dmarche par tapes successives jusqu' l'application des rgles de la programmation structure ;
les

mthodes systmiques, comme MERISE, des annes 1980 qui marquent une rupture avec les

prcdentes afin de privilgier une approche conceptuelle globale du SI base sur la recherche des lments pertinents du SI et de leurs relations, qu'il s'agisse de donnes, actions ou vnements ;
les

mthodes objets, comme UML, des annes 1990, combinent des spcifications dtailles 5

avec des spcifications plus globales l'aide du concept d'objet et de relations entre objets.

Les perspectives venir semblent privilgier une approche base sur les connaissances et leur gestion. L'informatique de gestion poursuit son volution vers un enrichissement mthodologique qui satisfasse deux contraintes en apparence opposes : restituer la plus grande part de la richesse smantique du rel, s'inscrire dans un cadre matrisable en termes de complexit, de dlais et de cots de ralisation. La modlisation reste un dtour ducatif irremplaable pour l'enseignement technologique. L'informatique rend possible la mise en uvre mthodique d'une dmarche fonde sur un ou plusieurs modles, exprime travers des langages qui facilitent la comprhension par l'analyse et la reprsentation. Les outils fournissent des procds de simulations et d'interactions aux apports pdagogiques innombrables.

II. Les Activits du Cycle de Dveloppement dun Logiciel :

Les tapes suivantes permettent de dcrire, en gnral, le cycle de dveloppement du logiciel :

Analyse des besoins (Expression des besoins du produit) Spcification globale (Conception prliminaire, au niveau systme) Conception architecturale et dtaille Programmation (Implmentation, ou phase de codage) Gestion de Configuration et Intgration Validation et Vrification Maintenance et Assistance.

Aucune ne doit commencer avant que les prcdentes ne soient rellement termines, et lorsqu'une modification est effectue sur un lment, tous ceux qui en dpendent doivent tre revus. Il se peut qu'un module donn soit la fois spcifi et implment avant que ceux qui en dpendent soient compltement spcifis, situation que l'on appelle dveloppement avanc ou recherche. Il est absolument essentiel que chaque phase du processus lie au gnie logiciel subisse plusieurs types de revues : revue des pairs, revue par le responsable projet et par la direction, et revue interdisciplinaire. Les lments correspondant au cycle de dveloppement du logiciel (les documentations ou code source) doivent porter des numros de version et faire l'objet d'un historique. L'enregistrement d'une modification dans un lment impose un certain type d'examen dont l'ampleur doit correspondre directement l'importance des modifications.

Expression des besoins:

La premire tape du cycle de dveloppement d'un logiciel consiste produire un document qui dcrit les utilisateurs viss et leurs objectifs. Ce document formalise la liste des fonctions accomplir pour rpondre aux besoins des clients. Le Dossier de Spcification du Logiciel (DSL) constitue le document de rfrence dans lequel on trouvera les rponses aux questions Que doit-on faire et qui utilisera le produit ? . Le DSL de nombreux projets qui chourent avait t considr comme constituant les Tables de la loi remises par les gens du commercial aux ingnieurs, qui, alors, ronchonnrent longuement sur les lois de la physique et sur les raisons qu'ils avaient de ne pas pouvoir fabriquer ce produit 7

puisqu'ils n'tait pas possible de s'approvisionner en Kryptonite ou quoi que ce soit d'autre. Le DSL est le fruit d'un effort conjoint auquel les ingnieurs doivent aussi participer en rdigeant de nombreuses sections, et non en se contentant d'en analyser le termes.

Spcification Globale (Conception prliminaire):

C'est une description de haut niveau du produit, en termes de modules (ou quelquefois de programmes ) et de leurs interactions. Ce document doit en premier lieu asseoir la confiance en la finalit et la faisabilit du produit, et, en second lieu, servir de base pour l'estimation de la quantit de travail fournir pour le raliser. Le Dossier de Conception Prliminaire doit galement mettre en vidence le plan de test, en termes de besoins de l'utilisateur, et montrer ce que l'on peut y satisfaire grce l'architecture propose.

Conception Architecturale et Dtaille:

C'est au niveau de la conception dtaille que chacun des modules numrs dans le dossier de conception prliminaire est dcrit en dtail. L'interface (formats de lignes de commande, appels d'API, structures de donnes visibles de l'extrieur) de chacun des modules doit tre compltement dfinie ce niveau. Deux choses doivent merger lors de cette tape : un diagramme de PERT ou de GANTT, montrant comment le travail doit tre fait et dans quel ordre, ainsi qu'une estimation plus prcise de la charge de travail induite par la ralisation de chacun des modules. Chaque module doit avoir un plan de test unitaire, qui fournit aux ralisateurs la liste des tests effectuer ou des types de scnarios de test crer afin de vrifier que le module rpond aux spcifications. Il faut noter qu'il existe des tests unitaires complmentaires, ne concernant pas les fonctionnalits, dont on parlera plus tard.

Implmentation (Programmation):
Chacun des modules dcrits dans le document de spcification dtaill doit tre ralis. Cela comprend la petite activit de codage ou de programmation qui constitue le cur et l'me du processus de dveloppement du logiciel. Il est malheureux que cette petite activit soit quelquefois l'unique partie du gnie logiciel qui soit enseigne (ou tudie), puisque c'est galement la seule partie du gnie logiciel qu'un autodidacte peut rellement apprhender.

On peut considrer qu'un module a t ralis quand il a t cr, test et utilis avec succs par un autre module (ou par un processus de test au niveau systme). La cration d'un module se fait dans le cadre du cycle classique dition-compilation-rptition. Le test des modules comprend les tests au niveau unitaire les tests de non-rgression dfinis lors de la conception dtaille, ainsi que les tests de performances et de charge et l'analyse de couverture du code.

Gestion des Configurations et Intgration:

Quand tous les modules sont termins, l'intgration, au niveau du systme, peut tre ralise. C'est l que tous les modules sont runis en un seul ensemble de code source, compils et lis pour former un paquetage qui constitue le systme. L'intgration peut tre ralise de faon incrmentale, en parallle avec la ralisation de diffrents modules, mais on ne peut pas dcider de manire autoritaire que c'est fini tant que tous les modules ne sont pas effectivement termins. L'intgration comprend le dveloppement de tests au niveau du systme. Si le paquetage ralis est capable de s'installer lui-mme (ce qui signifie simplement le dcompactage d'une archive ou la copie de fichiers d'un CD-ROM) il doit alors exister un moyen de le faire automatiquement, soit sur des systmes spcialiss, soit dans des environnements de simulation. Parfois, dans le cas des logiciels personnaliss, le paquetage est constitu du simple excutable rsultant de la compilation de l'ensemble des modules, et, dans ce cas, il n'y a pas d'outil d'installation ; les tests seront effectus tels quels. Le systme ayant t install (s'il doit l'tre), le processus de tests au niveau systme doit pouvoir lancer toutes les commandes publiques et appeler tous les points d'entre publics, en utilisant toutes les combinaisons raisonnables d'arguments. Si le systme doit pouvoir crer une sorte de base de donnes, la procdure automatise de test au niveau systme doit en crer une et utiliser des outils extrieurs (crits sparment) pour vrifier l'intgrit de la base de donnes. Les tests unitaires peuvent tre utiliss pour rpondre certains de ces besoins, et tous les tests unitaires doivent tre excuts en squence pendant le processus d'intgration, de construction et de ralisation du paquetage.

Validation et Vrification:
L'opration de validation et de vrification commence gnralement en interne. Ce qui signifie que des employs de l'organisation qui a produit le logiciel vont l'essayer sur leurs propres ordinateurs. Ceci doit inclure tous les systmes du niveau production , c'est--dire tous les ordinateurs de 9

bureau, les portables et les serveurs. Vous devez pouvoir dire, au moment o vous demanderez vos clients d'utiliser le nouveau systme logiciel (ou une nouvelle version d'un logiciel existant) nous l'avons nous-mme test . Les dveloppeurs du logiciel doivent tre disponibles lors de l'assistance technique directe assure pendant la phase de tests interne. Enfin, il sera ncessaire de faire fonctionner le logiciel l'extrieur, c'est--dire sur les ordinateurs des clients (ou de ceux que l'on espre voir devenir des clients). Il vaut mieux choisir des clients amicaux pour ce genre d'exercice, puisqu'ils dcouvriront peut-tre de nombreux dfauts, mme vidents, tout simplement parce que leur manire de travailler et leurs habitudes sont diffrentes de celles de vos utilisateurs internes. Les dveloppeurs du logiciel doivent tre en premire ligne pendant cette phase de test externe. Les dfauts rencontrs pendant la phase de test devront tre tudis par des dveloppeurs confirms et des ingnieurs commerciaux, pour dterminer ceux qui doivent tre corrigs dans la documentation, ceux qui doivent tre corrigs avant que cette version du logiciel ne soit diffuse et ceux qui le seront dans la prochaine version (ou jamais).

Maintenance et assistance:
Les dfauts du logiciel rencontrs, soit pendant la phase de test in situ soit aprs sa diffusion, doivent tre enregistrs dans un systme de suivi. Il faudra affecter un ingnieur logiciel pour la prise en charge de ces dfauts, qui proposera de modifier soit la documentation du systme, soit la dfinition d'un module ou la ralisation de ce module. Ces modifications devront entraner l'ajout de tests unitaires ou au niveau systme, sous forme de tests de non-rgression pour mettre en vidence le dfaut et montrer qu'il a bien t corrig (et pour viter de le voir rapparatre plus tard). Exactement comme le DSL a constitu une entreprise en commun entre les commerciaux et les ingnieurs, la maintenance est une entreprise commune aux ingnieurs et au service client. La liste des bogues, la description de bogues particuliers, le nombre maximum de dfauts critiques dans une version diffuse du logiciel,... constituent les pices matresses de cet difice.

10

Avant la livraison un client, le dveloppement d'un logiciel passe par plusieurs tapes dfinies au cours des deux dernires dcennies :

l'analyse pralable d'un cahier des charges, la conception, le codage, les tests, la validation, l'intgration, la mise en production, la recette* du systme et sa validation, la maintenance du systme.

(*) La recette est une vrification de conformit du logiciel par rapport aux spcifications thoriques dfinies au dbut du projet, avant son dploiement final.

11

III. Prsentation des Diffrents Modles de Dveloppement du Logiciel :

Le modle en cascade: consiste en une succession de phases dont chacune est mthodiquement vrifie avant de passer l'tape suivante : 1. faisabilit et analyse des besoins : validation, 2. conception gnrale et dtaille : vrification, 3. intgration : tests d'intgration et tests d'acceptation, 4. installation : tests du systme. Le principe de modle en cascade est de dcouper le projet en phases distinctes sur le principe du non-retour. Lorsque une phase est acheve, son rsultat sert de point d'entre la phase suivante. Ce modle, dvelopp dans les annes 1970 par W. ROYCE a servi pendant des annes de modle de rfrence.

L'avantage de ce modle est de proposer au fur et mesure une dmarche de rduction des risques, en minimisant au fur et mesure l'impact des incertitudes. L'impact d'une incertitude dans la phase de dveloppement tant plus faible que l'impact d'une incertitude dans les phases de Conception ou de Spcifications, plus le projet avance, plus les risques diminuent. Nanmoins, cette dmarche, base sur un processus de contrle qualit en fin de chaque phase, a l'inconvnient d'exclure l'utilisateur ds la phase de conception car trop technique. Le contrle qualit significatif survient alors en fin de projet, et, ce moment, si l'utilisateur s'aperoit que le systme ne rpond pas correctement aux besoins exprims, il peut tre trop tard. 12

Le modle en cascade est adapt aux projets de dure infrieure l'anne, sur des projets forte composante rglementaire, comme les projets de back-office. Pour de grands systmes, cette dmarche prsente galement l'inconvnient de ne pas permettre de mener, en parallle, le dveloppement de modules d'applications.

Le modle en V: repose sur une troite interdpendance des tapes soumises une validation avant la prochaine tape et une vrification anticipatoire du produit final : 1. spcification textuelle, 2. conception gnrale, 3. conception dtaille, 4. codage, 5. tests unitaires, 6. tests d'intgration, 7. validation. Il permet de vrifier en continu que le projet progresse vers un produit rpondant aux besoins initiaux

Ce modle est adapt aux projets de taille et de complexit moyenne. C'est une amlioration du modle en cascade traditionnel. Il permet d'identifier et d'anticiper trs tt les ventuelles volutions des besoins. C'est aussi un moyen de vrifier de la maturit des utilisateurs, car s'il en tait autrement, ils se trouveraient dans l'incapacit de fournir des tests de recettes ds la phase de spcification. C'est un modle avantageux pour une matrise d'oeuvre, rassurant pour une

13

matrise d'ouvrage qui doit cependant s'engager significativement. Le modle en V demeure actuellement le cycle de vie le plus connu et certainement le plus utilis.

La premire tape, appel spcification ou analyse des besoins, a pour but de dgager du cahier des charges, toutes les contraintes ncessaires l'laboration du logiciel. Trois sortes de contraintes logicielles sont prendre en considration :

Les contraintes externes: dfinissent les caractristiques d'entre/sortie du logiciel attendues par le client (donnes utiliser et afficher, les exigences ergonomiques, le parc informatique, etc.).

Les contraintes fonctionnelles: caractrisent le fonctionnement interne du logiciel, c'est-dire, quels moyens seront mis en oeuvre pour traiter les informations d'entre/sortie du logiciel (mthode de calcul, intervalle des donnes, etc.).

Les contraintes de performances: indiquent la vitesse d'excution du logiciel ou de ses modules, la rsolution d'affichage, la prcision des donnes, etc..

Les documents produits (plan de dveloppement du logiciel, spcifications des besoins du logiciel et cahier de recette) au cours de cette phase permettent de passer l'tape suivante et galement de prparer les vrifications de conformit du logiciel. 14

Cette phase constitue environ 15 pourcents du temps total du cycle de dveloppement. La conception gnrale (ou analyse organique gnrale) a pour objectif de dduire de la spcification, l'architecture du logiciel. Lors de cette phase, plusieurs solutions peuvent tre envisages afin d'en tudier leur faisabilit. A l'issue, un document de conception gnrale du logiciel est ralis afin de dcrire la structure gnrale de l'alternative approuve. Lors de cette phase, il peut tre dcider de dcouper le logiciel en plusieurs modules distincts afin de les sous-traiter par plusieurs quipes de dveloppement. Un module possde une interface permettant son intgration au logiciel global ou d'autres modules, et un corps pour son fonctionnement interne. Ils sont hirarchiss de telle faon que des modules de bas niveau s'embotent dans des modules intermdiaires, lesquels s'intgrent un module de haut niveau (noyau logiciel). Un autre dcoupage peut tre aussi utilis pour scinder le logiciel en tches distinctes. L'application contient alors plusieurs sous-ensembles ayant en charge des traitements spcifiques (tches externes et tches internes au logiciel), lesquels s'interconnectent entre eux La phase de conception dtaille (ou analyse organique dtaille) en s'appuyant sur le document de conception gnrale, numre l'architecture approfondie du logiciel jusqu' parvenir une description externe de chaque sous-ensemble et information utilisable dans le futur logiciel. A partir de cette tape, seront connus toutes les donnes (variables, constantes, attributs, champs, etc.) et fonctions (procdures, mthodes, etc.) de l'application vue de l'extrieur. Le logiciel peut tre entirement crit en algorithme. Un langage de programmation est en gnral valid lors de cette phase. Un document de conception dtaille, ainsi qu'un manuel d'utilisation sont dits afin de respectivement de dcrire l'architecture dtaille et la mise en oeuvre du logiciel. Les phases de conception doivent prendre environ 25 pourcents du temps total du cycle de dveloppement. Des spcifications de tests d'intgration et unitaire sont galement produites, l'issue des deux phases de conception. Elles permettront de confronter le fonctionnement de l'application son architecture gnrale et dtaille. Le codage consiste crire avec un langage de programmation chacune des sous-programmes du logiciel. Le dveloppement peut tre confi une seule personne dans le cas d'une application simple ou divis entre plusieurs quipes de dveloppeurs dans le cas de projets 15

importants. Cette phase durant environ 15 pourcents du temps total du cycle de vie se termine par la production d'un code source. Les tests unitaires ont pour objectif de vrifier individuellement la conformit de chaque lment du logiciel (fonctions et variables) par rapport aux documents de conception dtaille. Toutes les fonctionnalits internes et externes de chaque sous-programme sont contrles mthodiquement. En outre, un contrle des performances globales et locales est galement entrepris. Cette phase consomme aux alentours de 5 pourcents du temps total du cycle de vie et se finalise par la rdaction des rsultats des tests. La phase d'intgration permet de vrifier l'assemblage des diffrentes parties du logiciel. Les diffrents modules du logiciel sont successivement intgrs jusqu' aboutir la construction complte, en respectant rigoureusement les spcifications des tests d'intgration. Chaque module doit parfaitement tre assimil sans que le fonctionnement des modules prcdemment intgrs n'en soit aucunement affect. Les rsultats de cette phase sont consigns dans un document des tests d'intgration. En gnral, une prsentation du logiciel est galement ralise. Les tests d'intgration reprsentent en moyenne 20 pourcents du temps total du cycle de dveloppement. La dernire phase a pour vocation de valider le logiciel dans son environnement extrieur. Le produit applicatif est mis en situation d'utilisation finale afin de vrifier s'il rpond parfaitement aux besoins noncs dans les spcifications textuelles (premire phase). Un document appel rsultat de la recette est produit au terme de la phase de validation qui dure 10 pourcents du temps total du cycle de vie du dveloppement du logiciel. La finalit du cycle de vie en V consiste parvenir sans incident livrer un logiciel totalement conforme au cahier des charges. Lors de la phase de spcification textuelle, une ngociation avec le client permet d'affiner ou d'enrichir les besoins propos de certains points techniques omis ou obscurs dans le cahier des charges. Lorsque la spcification est valide, la suite du processus de dveloppement doit tre parfaitement encadr, contrl et approuv de telle sorte qu' aucun moment, il ne soit possible de diverger des rgles nonces lors de la premire phase.

16

Le modle en spirale: s'appuie sur une succession de cycles dont chacun se droule en quatre phases : 1. analyse initiale des besoins et des objectifs du cycle (solutions et contraintes) ou analyse partir du cycle prcdent, 2. tude des risques, valuation des solutions de remplacement et ventuellement conception, 3. dveloppement et vrification de la solution rsultant de l'tape prcdente, 4. examen du produit et projection vers le cycle suivant. Le cycle de vie en spirale est un modle gnrique de cycle de vie volutif qui a t propos par Barry W. Boehm en 1984. Ce modle, ax sur la matrise et la rduction des risques, est davantage un cadre de travail guidant la construction d'une dmarche spcifique de projet, plutt qu'une dmarche formalise.

Le cycle de vie en spirale est plutt adapt aux grands projets complexes. Difficilement contractualisable, il est davantage applicable pour de projets internes l'entreprise. Il ncessite un patron de projet expriment. Les matrises d'ouvrage peuvent voir dans le cycle de vie en spirale une mthode de conduite de programme, dont chaque boucle serait un sous projet, ventuellement outsourc sous la forme d'une dmarche en cascade. Chaque boucle de spirale permet : 17

Didentifier les objectifs propres de la boucle Les moyens alternatifs pour atteindre les objectifs Les contraintes de chaque alternative Elle donne lieu au choix d'une alternative, valid par un prototype le cas chant, et l'excution de l'alternative choisie. A l'issue de la boucle, une revue des produits et des rsultats fournit une valuation qui sert d'entre pour la boucle suivante. La dernire boucle est squence comme un cycle de vie en cascade.

Le modle par incrment: propose un dveloppement du logiciel par morceaux, lesquels sont livrs successivement au client, en venant se greffer un noyau logiciel. Le modle incrmental ou loti permet de grer les projets de dveloppement de grands systmes. Il dcoupe le systme en domaines qui sont traits individuellement sur le modle en cascade.

C'est un modle adapt aux grands projets. Nanmoins, l'architecture du systme doit permettre de dfinir des domaines suffisamment dcoupls. Dans le cas contraire, certains incrments doivent attendre que les incrments avec lesquels ils sont lis, soient suffisamment dvelopps. Lorsqu'on leur propose un dveloppement par lot, les Matrises d'Ouvrage doivent vrifier le couplage des domaines.

18

Le Modle en B : Le modle en B est du Birrel et Ould d'aprs " a Practical Handbook for software developpement " (1985). Similaire au modle en cascade, il met l'accent sur le processus de maintenance qui est valu 70% du cycle complet. Ce modle rutilise les scnarios de tests btis pendant la phase de dveloppement, notamment pour les tests de non-rgression, ainsi que les procdures de mise en exploitation.

Ce modle se projette plus loin que le traditionnel cycle en cascade. Il peut servir de base une matrise d'ouvrage pour btir un projet complet de dveloppement et de maintenance d'une grosse application de Back-Office. Son intrt est de prvoir lors de la phase projet la rutilisation des tests et des procdures de mise en exploitation.

Le Modle par Prototype : Si l'on en croit le Robert, "un prototype est la premire version d'un produit qui vient d'tre ralis afin d'tre mis au point". Autrement il faut parler de maquette qui recouvre la ralisation petite chelle de tout ou partie d'un produit raliser. Par abus de langage, nous nommerons prototype les maquettes rutilisables. Les prototypes peuvent tre construits suivant un axe horizontal ou vertical. Horizontaux, ils couvrent une couche technique du systme sur l'ensemble des fonctions dvelopper. 19

Verticaux, ils couvrent un chantillon de fonctions sur l'ensemble des couches techniques. Gnralement les prototypes raliss sont des 2 types.

Les prototypes peuvent tre rutilisables, comme lors d'un cycle de vie itratif qui toffe chaque itration le prototype initial jusqu'au produit fini. Ils peuvent tre galement jetables des fins de vrification fonctionnelle ou technique (faisabilit).

Rellement, dire que l'on adopte un cycle de vie par prototype est un raccourci qui, hors des petits projets, n'est pas assez formalis pour soutenir l'organisation ncessaire aux projets plus importants. On prfrera des cycles de vie en spirale, RAD ou DSDM qui tout en intgrant des phases de prototypage, proposent de par ailleurs un formalisme adapt aux grands projets. Sur les petits projets, plutt techniques, men par des petites quipes, l'intrt est peut-tre de gagner en flexibilit, et de s'abstraire des contraintes d'une mthodologie plus large. Pour des projets o les utilisateurs sont largement impliqus, on prfrera toujours un cycle de vie RAD.

20

Le Modle Parallle : Le modle parallle est un modle incrmental coupl : soit par le temps : les diffrents domaines doivent tre mise en production au mme moment soit par les composants : certains composants du systme sont troitement lis

Bien qu'il rduise la complexit, comme le modle incrmental, il ne parvient pas contenir les risques de dlai. Il suppose des montes en charge rapide, avec des quipes relativement fournies. Adopter ce modle suppose que les autres facteurs du projet ne prsentent pas de risques significatifs. Nanmoins, la matrise d'ouvrage devra tre attentive la composition de l'quipe projet et son mode de management.

21

Le Modle RAD : Le cycle de vie RAD est employ lorsque l'implication forte de l'utilisateur est ncessaire. Il permet de construire le systme avec l'utilisateur, et participe ainsi de l'assurance qualit. Nanmoins la condition sine qua non pour mettre en oeuvre un cycle RAD est de s'appuyer sur un solide atelier de gnie logiciel qui seul peut garantir un passage rapide du concept la mise en oeuvre. L'quipe projet doit ncessairement matriser l'AGL employ, c'est le risque principal des projets RAD. Le cycle RAD a t introduit par James Martin. Il comporte 3 phases: 1. Cadrage (Joint Requitement Planning) qui couvre l'analyse des besoins, le primtre et la planification de l'itration 2. Conception (Joint Application Design) qui couvre la conception, description et organisation des donnes et des traitements avec les utilisateurs 3. Construction (Construction Assistance Team) qui couvrement le dveloppement et les tests. L'quipe de projet RAD doit ncessairement tre compose d'experts capables de proposer dans un temps rduit des solutions aux demandes des utilisateurs. Enfin, l'intgration des applications dans un systme d'information complexe requiert un effort qui peut rebuter les utilisateurs. Un projet RAD trouvera d'autant mieux sa place dans un contexte o la complexit de l'intgration est matrise voire masque vis vis de l'utilisateur. Il peut en rsulter une impression de facilit qui peut mener l'utilisateur des exigences difficiles remplir, ou des contestations sur les cots.

22

Modlisation des Systmes d'Information

Partie 2 : Diffrentes Mthodes de Dveloppement des Systmes dInformation
I. SURVOL DES DIFFERENTES METHODES: 1. Les Mthodes Cartsiennes : La Mthode SADT : Mthode d'analyse fonctionnelle La mthode SADT (Structured Analysis Design Technic) est une mthode d'analyse hirarchique et descendante apparue en 1977 au sein de la socit Sof'Tech Inc. C'est une mthode d'analyse par niveaux successifs d'approche descriptive d'un ensemble quel qu'il soit. Elle a t introduite en Europe partir de 1982. Les auteurs la prsentent comme une mthode pour communiquer des problmes . On peut appliquer SADT la gestion d'une entreprise tout comme un systme automatis La mthode SADT est fonde sur un formalisme graphique et textuel facile apprendre. Elle permet d'une part de modliser le problme pos (informatique, automatique ou autre), avant de chercher en extraire une solution, et d'autre part d'assurer une communication efficace entre les diffrents intervenants concerns par le systme analyser.

Historique
Dveloppe SOFTTECH (U.S.A.) en 1976 ; Utilise dans des projets industriels ITT, THOMSON, AROSPATIALE etc. Peut tre utilise pour dcrire (spcifier) n'importe quel systme Sert dfinir des modles de systmes existants, idaux, ralisables compte tenu des contraintes d'un projet, etc. Le Modle SADT Un modle SADT reprsente une image d'un systme qu'on veut apprhender. La technique d'analyse structure identifie et organise les dtails d'un tel systme suivant une hirarchie parfaitement rfrence. Un modle SADT est compos de :

Diagrammes d'activits ou actigrammes, reprsentant l'ensemble des activits du systme. Diagrammes de donnes ou datagrammes, montrant l'ensemble des donnes du systme. Textes explicatifs sur les diagrammes. Diagrammes Pour Explication Seulement (PES). Schma de la hirarchie du systme analys. Glossaire dfinissant les principaux termes employs. Conditions d'activation.

Le langage SADT est compos de diagrammes (actigrammes et datagrammes) obtenus par raffinements successifs et organiss en hirarchie. Plus concrtement, il s'agit de botes et de flches utilises pour reprsenter les notions suivantes :

23

Les entres : ce sont les flches horizontales entrant dans les botes. Les sorties : ce sont les flches horizontales sortant des botes. Les mcanismes : ce sont les flches venant du bas du schma vers le bas des botes. Les contrles : les flches venant du haut du schma et pointant vers le haut des botes. Actigrammes Un actigramme est identifi par un verbe d'action, il gre des donnes dsigns par des noms partir de directives de contrle (dsigns par des noms aussi) en s'appuyant sur les potentialits des mcanismes. Il gnre des donnes en sortie par cration ou par modifications des donnes en entre. Les donnes de contrle ne sont pas modifies par l'activit mais influent sur son droulement (ex. choix de l'utilisateur dans un menu). Les mcanismes, ou supports, de l'activit dsignent le comment de la ralisation de l'activit. Ils peuvent aussi reprsenter qui la ralise. Les mcanismes peuvent tre dvelopps par des modles SADT indpendants. Datagrammes Un datagramme reprsente des donnes cres par des activits Gnratrices (en entre) et consommes par des activits Utilisatrices (en sortie), sous le contrle d'activit de contrle. Pour une donne, les mcanismes expriment le support de stockage (physique ou logique) de la donne. Les textes explicatifs Ils accompagnent les diagrammes pour prsenter brivement des gnralits sur le diagramme et les faits auxquels l'auteur accorde un intrt particulier, sans toutefois dupliquer l'information prsente par le diagramme lui-mme. Ce texte doit tre crit uniquement lorsque le diagramme aura atteint son niveau d'approbation, permettant ainsi de vrifier la lisibilit du diagramme lors du cycle criture/lecture. Le texte explicatif du niveau global doit prsenter les faits qui s'appliquent l'ensemble du modle, fournissant ainsi une description globale du systme. Les diagrammes pour explication seulement Ils ne font pas vraiment partie du modle. Il illustrent ou clarifient un aspect particulier du systme. Il est par exemple utile de produire une copie simplifie des schmas complexes. Liste hirarchique et numrotation des diagrammes Les n uds d'un modle SADT sont numrots d'une faon prcise. Le premier noeud reprsente le systme global. Il porte le numro particulier A-0 (resp. D-0) pour le modle des actigrammes (resp. datagrammes). Il sera dcompos sur la feuille A0 (resp. D0) en plusieurs noeuds portant les numros A1, A2 ...An (resp. D1, D2, ...Dn), dcomposs leur tours en A11, A12 etc. Les pages de textes et de glossaires sont numrotes de manire identique avec les lettres G et T respectivement.

24

Les Actigrammes :
La bote reprsente une action (indique par un verbe l'infinitif). Les entres sont transformes en sorties par l'action ou servent alimenter laction. Elles ne sont donc pas forcment modifies mais sont ncessaires au fonctionnement de laction. Elles sont interprtes comme tant des donnes. Le mcanisme effectue la transformation (nous pouvons interprter ainsi : le mcanisme est le processeur , l'action tant le processus ). Le contrle n'est pas transform par l'action mais permet la transformation. Le contrle peut tre vu soit comme des paramtres ou soit comme un dclencheur. Donnes de contrle

Donnes d'entre

AGIR

Donnes de sortie

Unit de traitement

Les datagrammes
La bote reprsente les donnes (indiques par un nom). Les entres reprsentent les actions qui produisent les donnes de la bote. Les sorties reprsentent les actions qui utilisent les donnes de la bote. Le mcanisme est le support des donnes.

On peut ajouter des tiquettes aux flches en les reliant par un zigzag. En outre, les flches qui relient les botes reprsentent les contraintes fonctionnelles qui existent entre les botes, mais ne reprsentent en aucun cas un flux de commande et n'ont pas de signification squentielle (n'impliquent pas de notion d'ordre d'excution dans le temps). Activits de contrle

Activits Productrices

DONNEE

Activits Consommatrice s

Unit de stockage

25

Analyse descendante
La mthode danalyse descendante permet de comprendre pourquoi un systme existe, ou doit tre conu, quelles fonctions il doit remplir et enfin, comment elles sont ralises. Et cela, quelle quen soit la complexit. La mthode, appuye par un modle graphique, procde par approche descendante en ce sens que lon va du plus gnral au plus dtaill, en sintressant aux activits du systme. Plusieurs modles SADT correspondant diffrents points de vue du systme sont souvent tablis pour une meilleure comprhension. En particulier, la perception d'un systme n'est pas la mme pour l'utilisateur, le concepteur ou le programmeur. De la mme manire, plusieurs modles SADT diffrents peuvent tre conus pour rpondre une mme demande. Les deux principes de base sont : 1. Procder par analyse descendante : Le premier niveau du modle est en gnral trs abstrait, et progressivement les activits et les moyens ncessaires leur ralisation sont dtaills. 2. Dlimiter le cadre de lanalyse : afin daborder lanalyse et la description du systme, il est fondamental de prciser le contexte (limite du systme), le point de vue et lobjectif de lanalyse.

Description de la mthode
La premire phase est la modlisation du systme dcrit prcdemment qui en montre les fonctions. Le contexte est identifi par les flches qui entrent ou sortent de cette bote mre. La dcomposition en lments, ou sous-fonctions de cette bote-mre permet daffiner la perception du systme et sa structure. Cette dcomposition doit faire apparatre de trois six lments maximum. Ces lments ou botes sont des activits. Les flches qui les relient reprsentent les contraintes qui existent entre elles, mais ne reprsentent en aucun cas un flux de commande et nont pas de signification squentielle (nimpliquent pas de notions dordre dexcution dans le temps). Les diagrammes ainsi construits sont des actigrammes ou encore diagrammes dactivit. Si le niveau de dcomposition ne permet pas une totale comprhension du systme, on procde une nouvelle construction dactigrammes correspondant aux botes analyser plus en dtail. On dfinit ainsi successivement : La bote-mre A-0 (lire A moins zro). Le diagramme enfant de premier niveau A0. Les diagrammes enfants de chaque bote du diagramme prcdent (qui devient diagrammemre) soit : A1, A2, A23,... Les principales rgles rgissant la construction des diagrammes sont : Chaque flche entrant ou sortant de sa bote-mre doit se retrouver sur le diagramme enfant. Les flches sont affectes dun label indiquant leur nature. Celui-ci peut tre remplac par un code dont la signification est donne en marge. Les supports peuvent ne pas tre mentionns si cela nclaire pas la comprhension. On ne mentionne que les lments ncessaires ce que lon veut montrer.

26

C1

C2

BOITE MERE
C1 E

A-0

Plus gnral

1 2 3
C2

C2

A0
S

A3
S

Plus dtaille

Dmarche
1. On commence par le diagramme de plus haut niveau A-0 (A moins zro) reprsentant la finalit du systme. 2. Ensuite, on descend dans les niveaux en traant le diagramme de niveau A0 (A zro) puis A1 et ainsi de suite en respectant la hirarchie des niveaux. On dcrit de cette manire les sousfonctions du systme ce qui permet d'en affiner la perception et la structure. Si le niveau de dcomposition ne permet pas une totale comprhension du systme, on procde une nouvelle construction d'actigrammes. Enfin, il est fondamental que le modle circule entre les partenaires du projet afin qu'un consensus soit clairement tabli avant de passer au dbut de la phase de conception et dimplmentation.

Rgles d'critures des diagrammes

Chaque flche entrant ou sortant de sa bote-mre doit se retrouver sur le diagramme enfant. Les flches sont affectes d'un label indiquant leur nature. Les supports peuvent ne pas tre mentionns si cela n'claire pas la comprhension. Il est recommand de dcomposer une bote en trois botes au minimum et sept botes au maximum. Il est recommand de prsenter les botes suivant une mme diagonale. 27

 Les flches parenthses, galement appeles flches tunnel , indiquent qu'un flux de donnes est prsent dans une partie du modle bien qu'il ne soit pas dessin. On trouve deux types de flches tunnel : La flche tunnel dont les parenthses entourent l'extrmit de la flche qui est connecte une bote, qui signifie que cette flche existe implicitement dans toutes les botes rsultant de la dcomposition de celle-ci.

( )

La flche tunnel dont les parenthses se trouvent l'autre extrmit, donc prs des frontires du diagramme, qui signifie que cette flche existe implicitement dans toutes les botes qui sont hirarchiquement au dessus de la bote concerne ; c'est--dire sa bote mre, grand-mre, ... jusqu' A0 compris. ( )

Exemple de dcomposition

Dico Entres utilisateur

Analyser la syntaxe

Dico enrichi

Affichage

Dico

Lire et prparer Dico A1

Dico prpar Afficher cran Traiter info et complter Dico A2 Dico enrichi Sauver Dico A3
A0

Entres utilisateur

Dico enrichi et sauv

28

Dico (Sous forme texte)

Lire le Dico A11

catgories

Transformer catgories en liste A12 expression Transformer en liste de listes A13

A1

Dico prpar (en liste de listes)

Position de SADT dans la gestion d'un projet

SADT va permettre d'aider la gestion d'un projet. Par son rle d'analyse, il sera possible de l'utiliser tous niveaux de la conception du SA au codage (programmation du systme automatis). SADT est avant tout un langage de communication. Cette communication se fait diffrents niveaux. Au niveau de l'laboration du projet tout d'abord en permettant par son formalisme 29

 chacun de participer, ensuite lors d'explications des intervenants extrieurs son formalisme permet chacun d'apprhender le SA.

Objectifs d'une analyse S.A.D.T :

L'objectif de cette tude doit mener les intervenants (ingnieurs, techniciens, oprateurs) un tout qui soit cohrent et homogne avec le systme tudier. Dans n'importe quel systme automatis, circulent un certain nombre de flux de donnes. Les flux les plus caractristiques sont : - les flux de pices : flux qui caractrisent la valeur ajoute un produit. - Les flux d'informations : ces flux vont permettre l'outil de production de pouvoir voluer. - Les flux nergtiques. - les flux divers (copeaux, fluides de coupe, rejets divers, etc...). L'analyse SADT va permettre d'organiser ces flux de donnes pour donner une vision globale du systme puis par une analyse des niveaux successifs, permettre de prciser de plus en plus finement le rle de chacun des lments du systme. La finesse de cette description dpendra directement des besoins des utilisateurs.

Conclusions
SADT est un outil graphique de reprsentation. SADT oblige consigner par crit les dcisions d'une quipe de travail. Ceci permet progressivement de crer une documentation complte. c) SADT est un travail d'quipe qui demande discipline et coordination. Le SADT est un produit pour communiquer et pour tre diffus. d) Son formalisme conduit une reprsentation structure ascendante ou descendante. e) Si SADT est utilis compltement (Actigrammes et Datagrammes) il permet de programmer directement un systme automatis.
a) b)

30

2. Les Mthodes Systmiques :

2.1. Prsentation de la mthode MERISE: MERISE est une mthode de conception, de dveloppement et de ralisation de projets informatiques. Le but de cette mthode est d'arriver concevoir un systme d'information. La mthode MERISE est base sur la sparation des donnes et des traitements effectuer en plusieurs modles conceptuels et physiques. La sparation des donnes et des traitements assure une longvit au modle. En effet, l'agencement des donnes n'a pas tre souvent remani, tandis que les traitements le sont plus frquemment. La mthode MERISE date de 1978-1979, et fait suite une consultation nationale lance en 1977 par le ministre de l'Industrie dans le but de choisir des socits de conseil en informatique afin de dfinir une mthode de conception de systmes d'information. Les deux principales socits ayant mis au point cette mthode sont le CTI (Centre Technique d'Informatique) charg de grer le projet, et le CETE (Centre d'Etudes Techniques de l'Equipement) implant Aix-en-Provence. 2.2. Cycle d'abstraction de conception des systmes d'information: La conception du systme d'information se fait par tapes, afin d'aboutir un systme d'information fonctionnel refltant une ralit physique. Il s'agit donc de valider une une chacune des tapes en prenant en compte les rsultats de la phase prcdente. D'autre part, les donnes tant spares des traitements, il faut vrifier la concordance entre donnes et traitements afin de vrifier que toutes les donnes ncessaires aux traitements sont prsentes et qu'il n'y a pas de donnes superflues. Cette succession d'tapes est appele cycle d'abstraction pour la conception des systmes d'information :

31

L'expression des besoins est une tape consistant dfinir ce que l'on attend du systme d'information automatis, il faut pour cela :

faire l'inventaire des lments ncessaires au systme d'information dlimiter le systme en s'informant auprs des futurs utilisateurs

Cela va permettre de crer le MCC (Modle Conceptuel de la Communication) qui dfinit les flux d'informations prendre en compte. L'tape suivante consiste mettre au point le MCD (Modle Conceptuel des Donnes) et le MCT (Modle conceptuel des traitements) dcrivant les rgles et les contraintes prendre en compte. Le modle organisationnel consiste dfinir le MOT (Modle Organisationnel des Traitements), dcrivant les contraintes dues l'environnement (organisationnel, spatial et temporel). Le modle logique reprsente un choix logiciel pour le systme d'information. Le modle physique reflte un choix matriel pour le systme d'information. 3. lApproche Objet : 3.1. Introduction : Aujourd'hui, en programmation, il existe 2 principaux modles de reprsentation du monde : Le modle fonctionnel (que nous venons de voir). Le modle objet (que nous allons tudier). Dans une approche fonctionnelle, vos programmes sont composs d'une srie de fonctions, qui assurent ensemble certains services. Il s'agit d'une approche logique, cohrente et intuitive de la programmation. Cette approche a un avantage certain appel la factorisation des comportements (c'est dire que pour crer une fonction d'une application, rien ne vous empche d'utiliser un autre ensemble de fonctions (qui sont donc dj crites)). Mais, l'approche fonctionnelle a aussi ses dfauts, comme par exemple une maintenance complexe en cas d'volution de votre application (une simple mise jour de l'application un point donn peut avoir un impact en cascade sur d'autres fonctions de notre application). L'application sera alors retouche dans sa globalit. L'approche fonctionnelle n'est pas adapte au dveloppement d'applications qui voluent sans cesse et dont la complexit croit continuellement (plusieurs dizaines de milliers de lignes de code). Exemple: les langages Pascal, C, Algol, etc. L'approche objet rpond aux limites de l'approche fonctionnelle par le concept dencapsulation (qui applique le principe dabstraction) des donnes et des oprations qui les manipulent dans les objets, cest--dire quun objet nest accessible que par ces oprations visibles (son interface externe) et son implmentation (les structures de donnes associes) est cache. Elle apporte lindpendance entre les programmes, les donnes et les procdures parce que les programmes peuvent partager les mmes objets sans avoir se connatre. La programmation oriente objet consiste modliser informatiquement un ensemble d'lments d'une partie du monde rel (que l'on appelle domaine) en un ensemble d'entits informatiques. Ces entits informatiques sont appeles objets. Il s'agit de donnes 32

informatiques regroupant les principales caractristiques des lments du monde rel (taille, couleur, ...). L'approche objet est une ide qui a dsormais fait ses preuves. Simula a t le premier langage de programmation implmenter le concept de classes en 1967 ! En 1976, Smalltalk implmente les concepts d'encapsulation, d'agrgation, et d'hritage (les principaux concepts de l'approche objet). D'autre part, de nombreux langages orients objets ont t mis au point dans un but universitaire (Eiffel, Objective C, Loops, etc.). La difficult de cette modlisation consiste crer une reprsentation abstraite, sous forme d'objets, d'entits ayant une existence matrielle (chien, voiture, ampoule, ...) ou bien virtuelle (scurit sociale, temps, ...). Lapproche objet a introduit indpendamment de tout langage de programmation lobjet trois concepts de base : objet, classe et hritage entre classes. Les concepts objet et classe sont interdpendants, cest--dire quun objet est une instance dune classe et la classe dcrit la structure et le comportement communs dobjets (ses instances). L'objet: Un objet est une abstraction dun lment du monde rel. Il possde des informations, par exemple nom, prnom, adresse, etc., et se comporte suivant un ensemble doprations qui lui sont applicables. De plus, un ensemble d'attributs caractrisent l'tat d'un objet, et l'on dispose d'un ensemble d'oprations (les mthodes) qui permettent d'agir sur le comportement de notre objet. Un objet est l'instance d'une classe, et une classe est un type de donnes abstrait, caractris par des proprits (ses attributs et ses mthodes) communes des objets, qui permet de crer des objets possdant ces proprits. Objet = identit + tat (attributs) + comportement (mthodes) Lidentit : Lobjet possde une identit, qui permet de le distinguer des autres objets, indpendamment de son tat. On construit gnralement cette identit grce un identifiant dcoulant naturellement du problme (par exemple un produit pourra tre repr par un code, une voiture par un numro de srie, ...) Les attributs : Il sagit des donnes caractrisant lobjet. Ce sont des variables stockant des informations dtat de lobjet Les mthodes (appeles parfois fonctions membres): Les mthodes dun objet caractrisent son comportement, cest--dire lensemble des actions (appeles oprations) que lobjet est mme de raliser. Ces oprations permettent de faire ragir lobjet aux sollicitations extrieures (ou dagir sur les autres objets). De plus, les oprations sont troitement lies aux attributs, car leurs actions peuvent dpendre des valeurs des attributs, ou bien les modifier. La notion de classe: On appelle classe la structure dun objet, cest--dire la dclaration de lensemble des entits qui composeront un objet. Les objets de mme nature ont en gnral la mme structure et le mme comportement. La classe factorise les caractristiques communes de ces objets et permet de les classifier. Un objet est donc, une instanciation dune classe, cest la raison pour laquelle on pourra parler indiffremment dobjet ou dinstance (ventuellement doccurrence). Toutes les instances d'une classe constituent l'extension de la classe. Classe = instanciation + attributs (variables d'instances) + oprations 33

 Linstanciation : Lobjet possde une identit, qui permet de le distinguer des autres objets, indpendamment de son tat. L'instanciation reprsente la relation entre un objet et sa classe d'appartenance qui a permis de le crer. Les attributs: (appels aussi variables d'instances ou donnes membres) Il s'agit des donnes reprsentant l'tat de l'objet. Ils ont un nom et soit un type de base (simple ou construit) soit une classe (l'attribut rfrenant un objet de la mme classe ou une autre classe). Les oprations: (appeles parfois mthodes ou fonctions membres) Il s'agit des oprations applicables aux objets de la classe. Elles peuvent modifier tout ou en partie l'tat d'un objet et retourner des valeurs calcules partir de cet tat. Exemple: Si on dfinit la classe voiture, les objets Peugeot 406, Renault 18 seront des instanciations de cette classe. Il pourra ventuellement exister plusieurs objets Peugeot 406, diffrencis par leur numro de srie. Mieux: deux instanciations de classes pourront avoir tous leurs attributs gaux sans pour autant tre un seul et mme objet. C'est le cas dans le monde rel, deux T-shirts peuvent tre strictement identiques et pourtant ils sont distincts. D'ailleurs en les mlangeant il serait impossible de les distinguer... Lencapsulation: Le concept dencapsulation est un mcanisme consistant rassembler les donnes et les mthodes au sein dune structure en cachant limplmentation de lobjet, cest--dire en empchant laccs aux donnes par un autre moyen que les services proposs. L'utilisateur d'une classe n'a pas forcment savoir de quelle faon sont structures les donnes dans l'objet, cela signifie qu'un utilisateur n'a pas connatre l'implmentation. Ainsi, en interdisant l'utilisateur de modifier directement les attributs, et en l'obligeant utiliser les fonctions dfinies pour les modifier (appeles interfaces). Lencapsulation permet donc de garantir lintgrit des donnes contenues dans lobjet (on pourra par exemple s'assurer que le type des donnes fournies est conforme nos attentes, ou encore que les donnes se trouvent bien dans l'intervalle attendu).. Lencapsulation permet de dfinir des niveaux de visibilit des lments de la classe. Ces niveaux de visibilit dfinissent les droits daccs aux donnes selon que lon y accde par une mthode de la classe elle-mme, dune classe hritire, ou bien dune classe quelconque. Il existe trois niveaux de visibilit : Publique : Les fonctions de toutes les classes peuvent accder aux donnes ou aux mthodes dune classe dfinie avec le niveau de visibilit public. Il sagit du plus bas niveau de protection des donnes. Protge : laccs aux donnes est rserv aux fonctions des classes hritires, cest-dire par les fonctions membres de la classe ainsi que des classes drives. Prive : laccs aux donnes est limit aux mthodes de la classe elle-mme. Il sagit du niveau de protection des donnes le plus lev. La notion d'hritage: Lhritage (en anglais inheritance) est un principe propre la programmation oriente objet, permettant de crer une nouvelle classe partir dune classe existante. Le nom d"hritage" (ou parfois drivation de classe) provient du fait que la classe drive (la classe nouvellement cre) contient les attributs et les mthodes de sa superclasse (la classe dont elle drive). Lintrt majeur de lhritage est de pouvoir dfinir de nouveaux attributs et de nouvelles mthodes pour la classe drive, qui viennent sajouter ceux et celles hrites. Par ce 34

moyen on cre une hirarchie de classes de plus en plus spcialises. Cela a comme avantage majeur de ne pas avoir repartir de zro lorsque l'on veut spcialiser une classe existante. De cette manire il est possible d'acheter dans le commerce des librairies de classes, qui constituent une base, pouvant tre spcialises loisir (on comprend encore un peu mieux l'intrt pour l'entreprise qui vend les classes de protger les donnes membres grce l'encapsulation...). Hirarchie des classes: La hirarchie des classes ou l'association (relationship) est un concept essentiel pour la modlisation des donnes. On peut reprsenter sous forme de hirarchie de classes, parfois appele arborescence de classes, la relation de parent qui existe entre les diffrentes classes. La hirarchie ou arborescence commence par une classe gnrale appele superclasse (classe de base, classe parent, classe anctre, classe mre ou classe pre). Puis les classes drives (classe fille ou sous-classe) deviennent de plus en plus spcialises. Ainsi, on peut gnralement exprimer la relation qui lie une classe fille sa mre par la phrase "est un" (de l'anglais "is a"). Hritage multiple: Certains langages orients objet, tels que le C++, permettent de faire de lhritage multiple. Ce qui signifie quils offrent la possibilit de faire hriter une classe de deux superclasses. Ainsi, cette technique permet de regrouper au sein dune seule et mme classe les attributs et les mthodes de plusieurs classes. L'hritage multiple reprsente le mcanisme par lequel une sous-classe hrite des proprits de plus d'une super-classe. Polymorphisme: Le nom de polymorphisme vient du grec et signifie qui peut prendre plusieurs formes. Cette caractristique essentielle de la programmation oriente objet caractrise la possibilit de dfinir plusieurs fonctions de mme nom mais possdant des paramtres diffrents (en nombre et/ou en type), si bien que la bonne fonction sera choisie en fonction de ses paramtres lors de lappel. Le polymorphisme reprsente la facult d'une opration de s'appliquer des objets de classes diffrentes. On distingue gnralement trois types de polymorphisme :

Le polymorphisme ad hoc (galement surcharge ou overloading) Le polymorphisme d'hritage (galement redfinition, spcialisation ou overriding) Le polymorphisme paramtrique (galement gnricit ou template)

Le polymorphisme ad hoc: Le polymorphisme ad hoc permet d'avoir des fonctions de mme nom, avec des fonctionnalits similaires, dans des classes sans aucun rapport entre elles (si ce n'est bien sur d'tre des filles de la classe objet). Par exemple, la classe complexe, la classe image et la classe lien peuvent avoir chacune une fonction "afficher". Cela permettra de ne pas avoir se soucier du type de l'objet que l'on a si on souhaite l'afficher l'cran. Le polymorphisme ad hoc permet ainsi de dfinir des oprateurs dont l'utilisation sera diffrente selon le type des paramtres qui lui sont passs. Il est donc possible par exemple de surcharger l'oprateur + et de lui faire raliser des actions diffrentes selon qu'il s'agit d'une opration entre deux entiers (addition) ou entre deux chanes de caractres (concatnation).

35

Le polymorphisme d'hritage: La possibilit de redfinir une mthode dans des classes hritant d'une classe de base s'appelle la spcialisation. Il est alors possible d'appeler la mthode d'un objet sans se soucier de son type intrinsque : il s'agit du polymorphisme d'hritage. Ceci permet de faire abstraction des dtails des classes spcialises d'une famille d'objet, en les masquant par une interface commune (qui est la classe de base). Imaginons un jeu d'chec comportant des objets roi, reine, fou, cavalier, tour et pion, hritant chacun de l'objet pice. La mthode mouvement () pourra, grce au polymorphisme d'hritage, effectuer le mouvement appropri en fonction de la classe de l'objet rfrenc au moment de l'appel. Cela permettra notamment au programme de dire piece.mouvement sans avoir se proccuper de la classe de la pice. Le polymorphisme paramtrique: Le polymorphisme paramtrique, appel gnricit, reprsente la possibilit de dfinir plusieurs fonctions de mme nom mais possdant des paramtres diffrents (en nombre et/ou en type). Le polymorphisme paramtrique rend ainsi possible le choix automatique de la bonne mthode adopter en fonction du type de donne passe en paramtre. Le polymorphisme rend possible le choix automatique de la bonne mthode adopter en fonction du type de donne passe en paramtre. Ainsi, on peut par exemple dfinir plusieurs mthodes homonymes addition () effectuant une somme de valeurs: - int addition (int, int) pourra retourner la somme de deux entiers. - float addition (float, float) pourra retourner la somme de deux flottants. - char addition (char, char) pourra dfinit au gr de lauteur la somme de deux caractres. - etc. . On appelle signature le nombre et le type (statique) des arguments d'une fonction. C'est donc la signature d'une mthode qui dtermine quelle mthode sera appele. 3.2. Les avantages de lapproche objet: La modlisation des objets de lapplication: Consiste modliser informatiquement un ensemble dlments dune partie du monde rel en un ensemble dentits informatiques. Ces entits informatiques sont appeles objet. La modularit et la rutilisabilit: La programmation modulaire permet la rutilisation du code, via l'criture de librairies. Lextensibilit: Pour une meilleure productivit des dveloppeurs et une plus grande qualit des applications). La matrise de la complexit dun systme repose sur trois principes : Labstraction (voir le comportement des objets indpendamment de leur reprsentation interne). La dcomposition (des objets complexes en objets plus simples) La connexion (des objets suivant leurs interactions)

3.3. Les mthodes objet: La modlisation objet consiste crer une reprsentation informatique des lments du monde rel, sans se proccuper de limplmentation, ce qui signifie indpendamment dun langage de programmation. Il sagit donc de dterminer les objets prsents et disoler leurs donnes et les fonctions qui les utilisent. Pour cela, des mthodes de conception et de dveloppement orientes objet ont t mises au point. Entre 1970 et 1990, de nombreux 36

analystes ont mis au point des approches orientes objets, si bien quen 1994 il existait plus de 50 mthodes objet. Toutefois seules 3 mthodes ont vritablement merges : La mthode OMT de Rumbaugh La mthode BOOCH93 de Booch La mthode OOSE de Jacobson A partir de 1994, Rumbaugh et Booch (rejoints en 1995 par Jacobson) ont unis leurs efforts pour mettre au point la mthode UML (Unified Modeling Language), qui permet de dfinir une notation standard en incorporant les avantages de chacune des mthodes prcdentes (ainsi que celles dautres analystes). 4. Prsentation gnrale de la mthode OMT: 4.1. Introduction: OMT (Object Modeling Technique) utilise trois modles pour dcrire un systme : objet, dynamique et fonctionnel. Ces trois modles sont complmentaires et inter-relis. Le modle objet est fondamental et pralable aux deux autres. OMT permet de modliser un systme selon trois points de vue complmentaires, chacun capturant des aspects essentiels du systme, tous requis pour une description complte: Le modle objet est le point de vue des donnes. Le modle dynamique est le point de vue du contrle et des comportements. Le modle fonctionnel est le point de vue des transformations apportes aux donnes.

Un logiciel combine normalement ces trois aspects: il transforme (modle 3) des donnes (modle 1) d'une faon ordonne dans le temps (modle 2). 4.2. Esprit de la mthode: Modlisation d'objets du monde rel. Utilisation de ces objets pour concevoir un systme indpendamment des langages d'implantation. Meilleure comprhension des besoins Spcification et conception plus prcise Meilleure maintenabilit des systmes raliss La mme mthode (concepts + notations) peut tre utilise tout au long du cycle de dveloppement. Il n'est donc pas ncessaire de traduire une formulation en une autre chaque tape, comme le ncessitent d'autres approches. un jeu de concepts orients objet une notation graphique indpendante du langage de programmation, utilisable pour : analyser les besoins spcifier et concevoir implanter la solution dfinition des besoins spcification des besoins spcification de conception programmation 37

4.3. Avantages:

4.4. Les outils:

4.5. Le cycle de vie logiciel (abrg):

4.6. Gnralit de la mthode: OMT n'est pas une mthode ddie explicitement la programmation oriente objet. On montre l'intrt de la mthode pour spcifier des applications dont le langage cible n'est pas orient objet. OMT permet l'change clair et non ambigu des ides. 4.7. Aspect fondamentaux de OMT: l'accent est mis sur l'utilisation des objets pour modliser le monde rel plutt que comme un mcanisme d'un langage particulier. les relations inter objets sont leves un rang aussi lev que les classes moins d'accent est mis sur l'hritage et les mthodes les mcanismes subtils lis l'hritage sont laisss de ct un accent particulier est mis sur le typage, les classes, la modlisation la terminologie utilise est celle qui domine quand elle existe

4.8. Exercices: Tous les objets ont une identit et sont identifiables. D'un point de vue informatique, il n'est pas toujours vident de prvoir tout ce qui permet de les distinguer. Pour chacun de ces collections d'objets, dcrire de quelle faon on pourrait les distinguer : tous les humains, dans l'ide de leur envoyer du courrier tous les humains, pour des enqutes criminelles tous les clients qui possdent un coffre dans une banque tous les tlphones d'Algrie tous les clients d'une compagnie de tlphone, pour la facturation toutes les adresses lectroniques

5. Les trois modles de OMT: OMT utilise trois modles pour dcrire un systme : objet, dynamique et fonctionnel QUOI : le modle objet dfinit la structure statique des objets et leurs inter-relations classes liens hritage QUAND : le modle dynamique dcrit les interactions entre les objets diagrammes de transition d'tats contrle (conditions de dclenchement d'une opration) vnements, messages COMMENT : le modle fonctionnel dcrit les transformations appliques aux donnes diagrammes de flots de donnes processus Ces trois modles sont complmentaires et interrelis. Le modle objet est fondamental et pralable aux deux autres. OMT permet de modliser un systme selon trois points de vue complmentaires, chacun capturant des aspects essentiels du systme, tous requis pour une description complte: Le modle objet est le point de vue des donnes. Le modle dynamique est le point de vue du contrle, des comportements. Le modle fonctionnel est le point de vue des transformations apportes aux donnes. Un logiciel combine normalement ces trois aspects : Il transforme (modle 3) des donnes (modle 1) d'une faon ordonne dans le temps (modle 2). 38

 Chaque modle comporte des rfrences aux deux autres ; ces liens sont limits et explicites Chaque modle peut tre examin d'une faon relativement indpendante des deux autres Chaque modle volue durant le cycle de dveloppement : Pendant l'analyse un modle du domaine applicatif est ralis sans ide d'implantation Pendant la conception, ce modle est complt par des lments relatifs au domaine de la solution Pendant l'implantation, ces deux aspects sont raliss ATTENTION : le terme "modle" recouvre deux ralits distinctes, gnralement claires par le contexte: La vue du systme : modle objet, dynamique, fonctionnel. On devrait dire sous modle Une tape dans le dveloppement : analyse, conception, implantation 5.1. Le modle objet: (Le "Quoi?") Ce modle dcrit la structure des objets d'un systme : Leur identit Leurs relations Leurs attributs Leurs oprations

Les objets sont les lments sur lesquels les autres modles s'appuient. Ce sont les atomes (au sens grec : inscable) de nos modles a l'issue de l'analyse le modle objet comporte des termes familiers aux personnes du domaine, et normalement aucune rfrence informatique. Par contre, le modle de conception comporte des rfrences informatiques. Bien videment le modle objet est reprsent par des diagrammes dcrivant les diffrentes classes, hirarchises, et comportant les attributs et les oprations utiles 5.2. Le modle dynamique: (Le "Quand?") Le modle dynamique dcrit les interactions entre les objets. Il dcrit les aspects d'un systme o interviennent : Le temps Les squences Les vnements Squences d'vnements Les tats qui dfinissent le contexte pour des vnements L'organisation des vnements et des tats

Le modle dynamique dcrit galement le contrle (conditions de dclenchement d'une opration). Les squences d'oprations ont lieu sans se proccuper de: Ce qu'elles font Ce sur quoi elles oprent Comment elles sont programmes Le modle dynamique est reprsent graphiquement l'aide de diagrammes d'tats. Chaque diagramme dcrit les tats et squences d'vnements permises pour une classe d'objets. Ces diagrammes comportent des rfrences aux autres modles : Les actions correspondent aux fonctions du modle fonctionnel Les vnements deviennent des oprations sur des objets du modle objet

a) Diagrammes d'tat:

39

5.3. Le modle fonctionnel: (Le "Comment?") Ce modle dcrit les aspects d'un systme concerns par des changements de valeurs : Fonctions Applications Contraintes Dpendances fonctionnelles

Ce modle dcrit ce que fait un systme, sans considration pour quand ou comment il le fait. Le modle fonctionnel est reprsent par des Diagrammes de Flux de Donnes (DFD). Les DFD montrent : Les dpendances entre valeurs Le calcul de donnes de sortie en fonction de donnes en entre et de traitements sans considrer quand, ni si les fonctions correspondantes sont excutes.

5.4. Relations entre les modles: On a vu que chaque modle dcrit un aspect d'une ralit, avec des rfrences aux deux autres modles. Le modle objet dcrit les structures de donnes utilises par les modles dynamique et fonctionnel. Les oprations du modle objet correspondent des vnements du modle dynamique et des fonctions du modle fonctionnel. Le modle dynamique dcrit la structure de contrle des objets. Il montre les dcisions qui dpendent de valeurs dans l'objet et qui provoquent des actions qui changent cet tat et appellent des fonctions. Le modle fonctionnel dcrit les fonctions invoques par des oprations du modle objet et des actions du modle dynamique. Les fonctions oprent sur des donnes dcrites dans le modle objet. Le modle fonctionnel dcrit aussi des contraintes sur les valeurs des objets 5.5. Difficults: On ne sait pas toujours dcider si une information doit ou non figurer dans un modle. Ceci est normal car un modle dcrit ses frontires de faon toujours brutale au dbut, et certaines limites doivent tre dplaces. Certaines proprits d'un systme peuvent parfois tre mal reprsentes par OMT. C'est galement normal, aucune mthode ne peut tre complte. Dans ce cas, le recours tout autre langage ou mthode (graphique ou non, spcifique au domaine ou non) est souhaitable ou mme ncessaire. 5.6. Exercices: 1) Parmi les caractristiques d'un pneu on trouve sa taille, son composant, sa construction interne, dessin, prix, poids, dure de vie. Quels facteurs sont importants pour celui qui : achte un pneu pour sa voiture? ralise un systme de simulation de performance d'un systme anti-glissement pour voitures? construit une balanoire laide d'un pneu? 2) Dcider quel modle (objet, dynamique, fonctionnel) est pertinents pour les aspects suivants d'un programme de jeu aux checs. Le jeu et les pices sont visualiss sur un cran. Les coups de l'humain sont dcrits par un curseur et une souris l'interface utilisateur qui dcrit les coups reprsentation d'une configuration de pices sur le plateau de jeu reprsentation d'une squence de coups possibles validation d'un coup jou par l'humain

40

6. Bibliographie Michel Lissandre, "Matriser SADT", Armand Colin, 1990, 219 pages, ISBN 2200420226 "SADT, un langage pour communiquer", IGL Technology, Eyrolles, 1989, 336 pages, ISBN 2212081855 CAUVET C., ROSENTHAL-SABROUX C., (sous la direction de), Ingnierie des systmes d'information, Informatique et systme d'information, Herms Science Publications, 2001. KARSENTI G., La fin du paradoxe de l'informatique, ditions d'Organisation, Paris, 1999. MORLEY C, HUGUES J, LEBLANC B, UML pour l'analyse d'un systme d'information, Dunod Informatiques, 2000.

http://www.cyber.uhp-nancy.fr/demos/MAIN-002/chap_deux/pourq.html http://philippe.berger2.free.fr/automatique/cours/sadt/sadt.htm http://www.univ-pau.fr/~nancy/sadt/ http://www.ac-reunion.fr/pedagogie/si/Ressources/les_dossiers_techniques_par_syst.htm

41