1

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.
2
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."
3
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 sous-
systmes 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
4
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 logico-
mathmatique. 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,
5
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 mthodes dites d'analyse, comme CORIG, dans les annes 1960 ;
les 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
avec des spcifications plus globales l'aide du concept d'objet et de relations entre objets.
6
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.
7
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
8
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.
9
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
10
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.
11
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.
12
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.
13
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
14
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.
15
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
16
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.
17
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 :
18
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.
19
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.
20
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.
21

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.

22
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.

23
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 :

24
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.
25
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.
















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).
















AGIR
Unit de traitement
Donnes
de sortie
Donnes
d'entre
Donnes
de contrle
DONNEE
Unit de stockage
Activits
Consommatrice
s
Activits
Productrices
Activits
de contrle
26
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 diagramme-
mre) 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.



27


























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 sous-
fonctions 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.
BOITE
MERE
A-0
Plus gnral
Plus
dtaille
A0
1
3
2
E
S
C1 C2
E
S
C1
C2
A3
S
C2
28
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




Lire et
prparer
Dico
A1
Traiter info et
complter
Dico
A2
Sauver
Dico
A3
Dico
Entres utilisateur
Dico prpar
Afficher cran
Dico enrichi
Dico enrichi et sauv
A0

Analyser
la syntaxe

Dico
Entres
utilisateur
Dico enrichi
Affichage
29


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

Dico prpar

(en liste de listes)
Dico

(Sous forme texte)
Lire
le Dico
A11
Transformer
catgories
en liste
A12
Transformer
en liste
de listes
A13
catgories
A1
expression
30
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
a) SADT est un outil graphique de reprsentation.
b) 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.

31
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 :

32
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
33
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
34
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
35
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).
36
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
37
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.
4.3. Avantages:
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.
4.4. Les outils:
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
4.5. Le cycle de vie logiciel (abrg):
dfinition des besoins
spcification des besoins
spcification de conception
programmation
38
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).
39
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
a) Diagrammes d'tat:
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
40
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
41
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