Plan Détaillé du Cours

Partie 1: Introduction à l'Ingénierie du Logiciel

1. Les Activités du Cycle de Développement d'un Logiciel

1.1 Analyse des Besoins
1.2. Spécification Globale
1.3. Conception Architecturale et Détaillée
1.4. Programmation
1.5. Gestion de Configuration et Intégration
1.6. Validation et Vérification

2. Présentation des différents Modèles de Développement d'un Logiciel

2.1. Le Modèle en Cascade
2.2. Le Modèle en V
2.3. Le Modèle en Spirale
2.4. Le Modèle par Incréments
2.5. Autres Modèles

Partie 2: Différentes Méthodes de Développement des Systèmes

d'Information

1. Méthodes Cartésiennes: SADT

1.1. Concepts
1.2. Démarche

2. Méthodes Systémiques: MERISE

2.1 Le Modèle Conceptuel
2.2. Le Modèle Logique
2.3. Le Modèle Physique

3.Approche Objet
3.1. Introduction
3.2. Les Avantages de l'Approche Objet

4. Les Méthodes Orientées Objet

4.1. La Méthode OMT

5. Les 3 Modèles d'OMT

5.1. Le Modèle Objet:
5.2. Le Modèle Dynamique
5.3. Le Modèle Fonctionnel
 Introduction :
Le développement d'applications dans le domaine de l'informatique de gestion est
aujourd'hui généralement entendu comme contribution au développement des systèmes
d'information. Le système d'information intègre les dimensions organisationnelles,
humaines et technologiques de la gestion de l'information d'entreprise. Ainsi, le
développement de systèmes d'information toujours plus complexes avec des
problématiques beaucoup plus ambitieuses que par le passé, caractérise-t-il aujourd'hui le
terrain d'action de l'informatique de gestion.

Ces nouvelles contraintes obligent l’informaticien à acquérir la maîtrise de nouveaux

modèles conceptuels et logiques, à mettre en œuvre des outils de haute productivité en
matière de développement. Elles replacent le gestionnaire dans sa responsabilité
organisationnelle en matière de conception et de spécification d’applications
informatiques. Les apports conceptuels de l’orienté objet semblent directement répondre
aux besoins des utilisateurs, conditionnés dans leurs exigences par les standards de fait des
interfaces graphiques et des logiques de fonctionnement clients-serveurs consacrées
notamment par les extensions de l'intégration au monde Internet.

Les nouvelles tendances du développement peuvent apparaître comme une « nouveauté ».

Après tout, les méthodes et outils du développement d’applications s’inscrivent dans une
tradition d’évolution permanente : des méthodes cartésiennes vers les méthodes
systémiques puis les méthodes orientées objet, des langages procéduraux vers les L4G et
les langages à objets, l'intégration d'applications d'entreprises (EAI)… Ces nouvelles
tendances peuvent être appréhendées à partir de différents indicateurs d’évolutions
particulièrement significatifs :

 La consécration de la prise en compte du point de vue de l’utilisateur dans la logique

de fonctionnement des applications (ergonomie, convivialité, souplesse d’utilisation).
La "fenêtre" est le lien entre l’application et l’utilisateur qui dialogue par des actions,
notamment sur des objets graphiques.

 Les nouvelles architectures permettent de rapprocher les données et les traitements de

leurs utilisateurs, d’améliorer leur confort de travail (en réduisant par exemple les
temps de réponse), d’accroître l’autonomie des sites distants des ressources
informatiques centralisées, de minimiser le trafic sur le(s) réseau(x). Ces améliorations
technologiques posent cependant des problèmes de cohérence des données réparties
dans le cas de traitements coopératifs.
 L’approche orientée objet (mauvaise traduction d’ "object-oriented") c’est-à-dire
utilisant résolument les objets dans les techniques d’analyse et de conception, est là.
Les avantages de cette technologie sont bien connus : réutilisation des composants
logiciels (typage, encapsulation, héritage, polymorphisme...), maintenabilité accrue
des applications, cohérence avec la vision que l’utilisateur a du système, approche
décentralisée faiblement procédurale (les objets communiquent en s’envoyant des
messages). Cependant, les approches par les objets sont plus adaptées à la conception
et au développement de logiciel qu’à la conception de système d’information
(notamment dans les aspects organisationnels).

 Le succès des outils de développement de type programmation événementielle qui

dispensent de paramétrer et d’appeler les fonctions de base complexes du système
d'exploitation ou API - Application Programming Interface. Ces outils comme Visual
Basic, Delphi ou Powerbuilder, dépassent l’utilisation habituelle de processus de
conception et permettent des techniques du type RAD (Rapid Application
Development).

A la base, une nouvelle lecture du système 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 spécification des systèmes d'information mobilise des
modèles qui relèvent majoritairement aujourd'hui de l'approche objet : ainsi la référence à
UML semble s'imposer mais de manière mesurée en informatique de gestion. Cette
suprématie ne saurait cependant faire oublier les autres références classiques de
l'informatique de gestion ni l'émergence d'une réflexion portant sur l'ingénierie des besoins.
Au plan technologique, la généralisation croissante des systèmes d'information distribués
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 système d'information numérique qui permette
à l'acteur, à son poste de travail, dans sa situation, d'obtenir les informations circulantes, de
partager ses connaissances et d'accéder aux informations, sources de connaissances, qui lui
sont nécessaires pour comprendre et résoudre les problèmes qu'il rencontre, prendre des
décisions, exercer son activité et capitaliser les connaissances produites dans l'exercice de
cette activité."
 Partie1 : Introduction à l'Ingénierie du Logiciel
1. Activités du Cycle de Développement d'un Logiciel:

Les étapes suivantes permettent de décrire, en général, le cycle de développement d'un

logiciel :

 Analyse des besoins (Expression des besoins du produit)

 Spécification globale (Conception préliminaire, au niveau système)
 Conception architecturale et détaillée
 Implémentation (Programmation ou Phase de codage)
 Gestion de Configuration et Intégration
 Validation et Vérification
 Maintenance et Assistance.

Aucune ne doit commencer avant que les précédentes ne soient réellement terminées, et
lorsqu'une modification est effectuée sur un élément, tous ceux qui en dépendent doivent
être revus. Il se peut qu'un module donné soit à la fois spécifié et implémenté avant que
ceux qui en dépendent soient complètement spécifiés, situation que l'on appelle
développement avancé ou recherche.

Il est absolument essentiel que chaque phase du processus liée au génie logiciel subisse
plusieurs types de revues : revue des pairs, revue par le responsable projet et par la
direction, et revue interdisciplinaire.

Les éléments correspondant au cycle de développement du logiciel (les documentations ou

code source) doivent porter des numéros de version et faire l'objet d'un historique.
« L'enregistrement » d'une modification dans un élément impose un certain type d'examen
dont l'ampleur doit correspondre directement à l'importance des modifications.

Analyse des besoins:

La première étape du cycle de développement d'un logiciel consiste à produire un

document qui décrit les utilisateurs visés et leurs objectifs. Ce document formalise la liste
des fonctions à accomplir pour répondre aux besoins des clients. Le « Dossier de
Spécification du Logiciel » (DSL) constitue le document de référence dans lequel on
trouvera les réponses aux questions « Que doit-on faire et qui utilisera le produit ? ».

Le DSL de nombreux projets qui échouèrent avait été considéré comme constituant les
« Tables de la loi » remises par les gens du commercial aux ingénieurs, qui, alors,
ronchonnèrent longuement sur les lois de la physique et sur les raisons qu'ils avaient de ne
pas pouvoir fabriquer ce produit 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 ingénieurs doivent aussi participer en rédigeant de nombreuses sections, et non en se
contentant d'en analyser le termes.

Spécification Globale (Conception préliminaire):

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 réaliser.

Le « Dossier de Conception Préliminaire » 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 grâce à
l'architecture proposée.

Conception Architecturale et Détaillée:

C'est au niveau de la conception détaillée que chacun des modules énumérés dans le
dossier de conception préliminaire est décrit en détail. L'interface (formats de lignes de
commande, appels d'API, structures de données visibles de l'extérieur) de chacun des
modules doit être complètement définie à 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 précise de la charge de travail induite
par la réalisation de chacun des modules.

Chaque module doit avoir un plan de test unitaire, qui fournit aux réalisateurs la liste des
tests à effectuer ou des types de scénarios de test à créer afin de vérifier que le module
répond aux spécifications. Il faut noter qu'il existe des tests unitaires complémentaires, ne
concernant pas les fonctionnalités, dont on parlera plus tard.

Implémentation (Programmation):

Chacun des modules décrits dans le document de spécification détaillé doit être réalisé.
Cela comprend la petite activité de codage ou de programmation qui constitue le cœur et
l'âme du processus de développement du logiciel. Il est malheureux que cette petite activité
soit quelquefois l'unique partie du génie logiciel qui soit enseignée (ou étudiée), puisque
c'est également la seule partie du génie logiciel qu'un autodidacte peut réellement
appréhender.
On peut considérer qu'un module a été réalisé quand il a été créé, testé et utilisé avec
succès par un autre module (ou par un processus de test au niveau système). La création
d'un module se fait dans le cadre du cycle classique édition-compilation-répétition. Le test
des modules comprend les tests au niveau unitaire les tests de non-régression définis lors
de la conception détaillée, ainsi que les tests de performances et de charge et l'analyse de
couverture du code.

Gestion des Configurations et Intégration:

Quand tous les modules sont terminés, l'intégration, au niveau du système, peut être
réalisée. C'est là que tous les modules sont réunis en un seul ensemble de code source,
compilés et liés pour former un paquetage qui constitue le système. L'intégration peut être
réalisée de façon incrémentale, en parallèle avec la réalisation de différents modules, mais
on ne peut pas décider de manière autoritaire que « c'est fini » tant que tous les modules ne
sont pas effectivement terminés.

L'intégration comprend le développement de tests au niveau du système. Si le paquetage

réalisé est capable de s'installer lui-même (ce qui signifie simplement le décompactage
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 systèmes spécialisés, soit dans des environnements de
simulation.

Parfois, dans le cas des logiciels personnalisés, le paquetage est constitué du simple
exécutable résultant de la compilation de l'ensemble des modules, et, dans ce cas, il n'y a
pas d'outil d'installation ; les tests seront effectués tels quels.

Le système ayant été installé (s'il doit l'être), le processus de tests au niveau système doit
pouvoir lancer toutes les commandes publiques et appeler tous les points d'entrée publics,
en utilisant toutes les combinaisons raisonnables d'arguments. Si le système doit pouvoir
créer une sorte de base de données, la procédure automatisée de test au niveau système doit
en créer une et utiliser des outils extérieurs (écrits séparément) pour vérifier l'intégrité de la
base de données. Les tests unitaires peuvent être utilisés pour répondre à certains de ces
besoins, et tous les tests unitaires doivent être exécutés en séquence pendant le processus
d'intégration, de construction et de réalisation du paquetage.

Validation et Vérification:

L'opération de validation et de vérification commence généralement en interne. Ce qui

signifie que des employés de l'organisation qui a produit le logiciel vont l'essayer sur leurs
propres ordinateurs. Ceci doit inclure tous les systèmes « du niveau production », c'est-à-
dire tous les ordinateurs de bureau, les portables et les serveurs. Vous devez pouvoir dire,
au moment où vous demanderez à vos clients d'utiliser le nouveau système logiciel (ou une
nouvelle version d'un logiciel existant) « nous l'avons nous-même testé ». Les
développeurs du logiciel doivent être disponibles lors de l'assistance technique directe
assurée pendant la phase de tests interne.

Enfin, il sera nécessaire de faire fonctionner le logiciel à l'extérieur, c'est-à-dire sur les
ordinateurs des clients (ou de ceux que l'on espère voir devenir des clients). Il vaut mieux
choisir des « clients amicaux » pour ce genre d'exercice, puisqu'ils découvriront peut-être
de nombreux défauts, même évidents, tout simplement parce que leur manière de travailler
et leurs habitudes sont différentes de celles de vos utilisateurs internes. Les développeurs
du logiciel doivent être en première ligne pendant cette phase de test externe.

Les défauts rencontrés pendant la phase de test devront être étudiés par des développeurs
confirmés et des ingénieurs commerciaux, pour déterminer ceux qui doivent être corrigés
dans la documentation, ceux qui doivent être corrigés avant que cette version du logiciel ne
soit diffusée et ceux qui le seront dans la prochaine version (ou jamais).

Maintenance et assistance:

Les défauts du logiciel rencontrés, soit pendant la phase de test in situ soit après sa
diffusion, doivent être enregistrés dans un système de suivi. Il faudra affecter un ingénieur
logiciel pour la prise en charge de ces défauts, qui proposera de modifier soit la
documentation du système, soit la définition d'un module ou la réalisation de ce module.
Ces modifications devront entraîner l'ajout de tests unitaires ou au niveau système, sous
forme de tests de non-régression pour mettre en évidence le défaut et montrer qu'il a bien
été corrigé (et pour éviter de le voir réapparaître plus tard).

Exactement comme le DSL a constitué une entreprise en commun entre les commerciaux
et les ingénieurs, la maintenance est une entreprise commune aux ingénieurs et au service
client. La liste des bogues, la description de bogues particuliers, le nombre maximum de
défauts critiques dans une version diffusée du logiciel,... constituent les pièces maîtresses
de cet édifice.

Avant la livraison à un client, le développement d'un logiciel passe par plusieurs étapes
définies au cours des deux dernières décennies :

 L'analyse préalable d'un cahier des charges,

 La conception,
 Le codage,
 Les tests, la validation,
 L'intégration,
 La mise en production,
 La recette* du système et sa validation,
 La maintenance du système.

(*) La recette est une vérification de conformité du logiciel par rapport aux spécifications
théoriques définies au début du projet, avant son déploiement final.

2. Présentation des Différents Modèles de Développement d'un

Logiciel:

 Le Modèle en Cascade: consiste en une succession de phases dont chacune est

méthodiquement vérifiée avant de passer à l'étape suivante :
1. faisabilité et analyse des besoins : validation,
2. conception générale et détaillée : vérification,
3. intégration : tests d'intégration et tests d'acceptation,
4. installation : tests du système.

Le principe de modèle en cascade est de découper le projet en phases distinctes sur le

principe du non-retour. Lorsque une phase est achevée, son résultat sert de point
d'entrée à la phase suivante. Ce modèle, développé dans les années 1970 par W.
ROYCE a servi pendant des années de modèle de référence.
 L'avantage de ce modèle est de proposer au fur et à mesure une démarche de réduction
des risques, en minimisant au fur et à mesure l'impact des incertitudes. L'impact d'une
incertitude dans la phase de développement étant plus faible que l'impact d'une
incertitude dans les phases de Conception ou de Spécifications, plus le projet avance,
plus les risques diminuent.

Néanmoins, cette démarche, basée sur un processus de contrôle qualité en fin de

chaque phase, a l'inconvénient d'exclure l'utilisateur dès la phase de conception car
trop technique. Le contrôle qualité significatif survient alors en fin de projet, et, à ce
moment, si l'utilisateur s'aperçoit que le système ne répond pas correctement aux
besoins exprimés, il peut être trop tard.

Le modèle en cascade est adapté aux projets de durée inférieure à l'année, sur des
projets à forte composante réglementaire, comme les projets de back-office.

Pour de grands systèmes, cette démarche présente également l'inconvénient de ne pas

permettre de mener, en parallèle, le développement de modules d'applications.

 Le Modèle en V: repose sur une étroite interdépendance des étapes soumises à une
validation avant la prochaine étape et une vérification anticipatoire du produit final :
1. spécification textuelle,
2. conception générale,
3. conception détaillée,
4. codage,
5. tests unitaires,
6. tests d'intégration,
7. validation.
 Il permet de vérifier en continu que le projet progresse vers un produit répondant aux
besoins initiaux

Ce modèle est adapté aux projets de taille et de complexité moyenne. C'est une
amélioration du modèle en cascade traditionnel. Il permet d'identifier et d'anticiper très
tôt les éventuelles évolutions des besoins. C'est aussi un moyen de vérifier de la
maturité des utilisateurs, car s'il en était autrement, ils se trouveraient dans l'incapacité
de fournir des tests de recettes dès la phase de spécification. C'est un modèle
avantageux pour une maîtrise d'oeuvre, rassurant pour une maîtrise d'ouvrage qui doit
cependant s'engager significativement. Le modèle en V demeure actuellement le cycle
de vie le plus connu et certainement le plus utilisé.
 La première étape, appelé spécification ou analyse des besoins, a pour but de dégager
du cahier des charges, toutes les contraintes nécessaires à l'élaboration du logiciel.
Trois sortes de contraintes logicielles sont à prendre en considération :

 Les contraintes externes: définissent les caractéristiques d'entrée/sortie du logiciel

attendues par le client (données à utiliser et à afficher, les exigences ergonomiques, le
parc informatique, etc.).
 Les contraintes fonctionnelles: caractérisent le fonctionnement interne du logiciel,
c'est-à-dire, quels moyens seront mis en oeuvre pour traiter les informations
d'entrée/sortie du logiciel (méthode de calcul, intervalle des données, etc.).
 Les contraintes de performances: indiquent la vitesse d'exécution du logiciel ou de
ses modules, la résolution d'affichage, la précision des données, etc..

Les documents produits (plan de développement du logiciel, spécifications des

besoins du logiciel et cahier de recette) au cours de cette phase permettent de passer
à l'étape suivante et également de préparer les vérifications de conformité du
logiciel.

Cette phase constitue environ 15 pourcents du temps total du cycle de

développement.
La conception générale (ou analyse organique générale) a pour objectif de déduire de
la spécification, l'architecture du logiciel. Lors de cette phase, plusieurs solutions
peuvent être envisagées afin d'en étudier leur faisabilité. A l'issue, un document de
conception générale du logiciel est réalisé afin de décrire la structure générale de
l'alternative approuvée.

Lors de cette phase, il peut être décider de découper le logiciel en plusieurs modules
distincts afin de les sous-traiter par plusieurs équipes de développement. Un module
possède une interface permettant son intégration au logiciel global ou à d'autres
modules, et un corps pour son fonctionnement interne. Ils sont hiérarchisés de telle
façon que des modules de bas niveau s'emboîtent dans des modules intermédiaires,
lesquels s'intègrent à un module de haut niveau (noyau logiciel).

Un autre découpage peut être aussi utilisé pour scinder le logiciel en tâches distinctes.
L'application contient alors plusieurs sous-ensembles ayant en charge des traitements
spécifiques (tâches externes et tâches internes au logiciel), lesquels s'interconnectent
entre eux

La phase de conception détaillée (ou analyse organique détaillée) en s'appuyant sur le

document de conception générale, énumère 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
données (variables, constantes, attributs, champs, etc.) et fonctions (procédures,
méthodes, etc.) de l'application vue de l'extérieur. Le logiciel peut être entièrement
écrit en algorithme. Un langage de programmation est en général validé lors de cette
phase. Un document de conception détaillée, ainsi qu'un manuel d'utilisation sont
édités afin de respectivement de décrire l'architecture détaillée et la mise en oeuvre du
logiciel. Les phases de conception doivent prendre environ 25 pourcents du temps
total du cycle de développement.

Des spécifications de tests d'intégration et unitaire sont également produites, à l'issue

des deux phases de conception. Elles permettront de confronter le fonctionnement de
l'application à son architecture générale et détaillée.

Le codage consiste à écrire avec un langage de programmation chacune des sous-

programmes du logiciel. Le développement peut être confié à une seule personne dans
le cas d'une application simple ou divisé entre plusieurs équipes de développeurs dans
le cas de projets 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 vérifier individuellement la conformité de
chaque élément du logiciel (fonctions et variables) par rapport aux documents de
conception détaillée. Toutes les fonctionnalités internes et externes de chaque sous-
programme sont contrôlées méthodiquement. En outre, un contrôle 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 rédaction des résultats des
tests.

La phase d'intégration permet de vérifier l'assemblage des différentes parties du

logiciel. Les différents modules du logiciel sont successivement intégrés jusqu'à
aboutir à la construction complète, en respectant rigoureusement les spécifications des
tests d'intégration. Chaque module doit parfaitement être assimilé sans que le
fonctionnement des modules précédemment intégrés n'en soit aucunement affecté. Les
résultats de cette phase sont consignés dans un document des tests d'intégration. En
général, une présentation du logiciel est également réalisée. Les tests d'intégration
représentent en moyenne 20 pourcents du temps total du cycle de développement.

La dernière phase a pour vocation de valider le logiciel dans son environnement

extérieur. Le produit applicatif est mis en situation d'utilisation finale afin de vérifier
s'il répond parfaitement aux besoins énoncés dans les spécifications textuelles
(première phase). Un document appelé résultat de la recette est produit au terme de la
phase de validation qui dure 10 pourcents du temps total du cycle de vie du
développement 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 spécification textuelle,
une négociation 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
spécification est validée, la suite du processus de développement doit être parfaitement
encadré, contrôlé et approuvé de telle sorte qu'à aucun moment, il ne soit possible de
diverger des règles énoncées lors de la première phase.

 Le Modèle en Spirale: s'appuie sur une succession de cycles dont chacun se déroule
en quatre phases :

1. analyse initiale des besoins et des objectifs du cycle (solutions et contraintes)

ou analyse à partir du cycle précèdent,
2. étude des risques, évaluation des solutions de remplacement et éventuellement
conception,
3. développement et vérification de la solution résultant de l'étape précédente,
 4. examen du produit et projection vers le cycle suivant.

Le cycle de vie en spirale est un modèle générique de cycle de vie évolutif qui a été
proposé par Barry W. Boehm en 1984. Ce modèle, axé sur la maîtrise et la réduction
des risques, est davantage un cadre de travail guidant la construction d'une démarche
spécifique de projet, plutôt qu'une démarche formalisée.

Le cycle de vie en spirale est plutôt adapté aux grands projets complexes.
Difficilement contractualisable, il est davantage applicable pour de projets internes à
l'entreprise. Il nécessite un patron de projet expérimenté. Les maîtrises d'ouvrage
peuvent voir dans le cycle de vie en spirale une méthode de conduite de programme,
dont chaque boucle serait un sous projet, éventuellement outsourcé sous la forme d'une
démarche en cascade. Chaque boucle de spirale permet :

D’identifier 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 échéant, et à
l'exécution de l'alternative choisie. A l'issue de la boucle, une revue des produits et des
résultats fournit une évaluation qui sert d'entrée pour la boucle suivante.

La dernière boucle est séquencée comme un cycle de vie en cascade.

 Le Modèle par Incrément: propose un développement du logiciel par morceaux,
lesquels sont livrés successivement au client, en venant se greffer à un noyau logiciel.

Le modèle incrémental ou loti permet de gérer les projets de développement de grands

systèmes. Il découpe le système en domaines qui sont traités individuellement sur le
modèle en cascade.

C'est un modèle adapté aux grands projets. Néanmoins, l'architecture du système doit
permettre de définir des domaines suffisamment découplés. Dans le cas contraire,
certains incréments doivent attendre que les incréments avec lesquels ils sont liés,
soient suffisamment développés. Lorsqu'on leur propose un développement par lot, les
Maîtrises d'Ouvrage doivent vérifier le couplage des domaines.

 Le Modèle en B :

Le modèle en B est du à Birrel et Ould d'après " a Practical Handbook for software
developpement " (1985).
 Similaire au modèle en cascade, il met l'accent sur le processus de maintenance qui est
évalué à 70% du cycle complet. Ce modèle réutilise les scénarios de tests bâtis pendant
la phase de développement, notamment pour les tests de non-régression, ainsi que les
procédures de mise en exploitation.

Ce modèle se projette plus loin que le traditionnel cycle en cascade. Il peut servir de
base à une maîtrise d'ouvrage pour bâtir un projet complet de développement et de
maintenance d'une grosse application de Back-Office. Son intérêt est de prévoir lors de
la phase projet la réutilisation des tests et des procédures de mise en exploitation.

 Le Modèle par Prototype :

Si l'on en croit le Robert, "un prototype est la première version d'un produit qui vient
d'être réalisé afin d'être mis au point". Autrement il faut parler de maquette qui
recouvre la réalisation à petite échelle de tout ou partie d'un produit à réaliser. Par abus
de langage, nous nommerons prototype les maquettes réutilisables.

Les prototypes peuvent être construits suivant un axe horizontal ou vertical.

Horizontaux, ils couvrent une couche technique du système sur l'ensemble des
fonctions à développer. Verticaux, ils couvrent un échantillon de fonctions sur
l'ensemble des couches techniques. Généralement les prototypes réalisés sont des 2
types.
Les prototypes peuvent être réutilisables, comme lors d'un cycle de vie itératif qui
étoffe à chaque itération le prototype initial jusqu'au produit fini. Ils peuvent être
également jetables à des fins de vérification fonctionnelle ou technique (faisabilité).

Réellement, 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 nécessaire
aux projets plus importants. On préfèrera des cycles de vie en spirale, RAD ou DSDM
qui tout en intégrant des phases de prototypage, proposent de par ailleurs un
formalisme adapté aux grands projets.

Sur les petits projets, plutôt techniques, mené par des petites équipes, l'intérêt est peut-
être de gagner en flexibilité, et de s'abstraire des contraintes d'une méthodologie plus
large. Pour des projets où les utilisateurs sont largement impliqués, on préfèrera
toujours un cycle de vie RAD.
 Le Modèle Parallèle :

Le modèle parallèle est un modèle incrémental couplé:

- Soit par le temps: les différents domaines doivent être mis en production au
même moment,
- Soit par les composants: certains composants du système sont étroitement liés.

Bien qu'il réduise la complexité, comme le modèle incrémental, il ne parvient pas à

contenir les risques de délai. Il suppose des montées en charge rapide, avec des
équipes relativement fournies. Adopter ce modèle suppose que les autres facteurs du
projet ne présentent pas de risques significatifs. Néanmoins, la maîtrise d'ouvrage
devra être attentive à la composition de l'équipe projet et à son mode de management.
 Le Modèle RAD :

Le cycle de vie RAD est employé lorsque l'implication forte de l'utilisateur est
nécessaire. Il permet de construire le système avec l'utilisateur, et participe ainsi de
l'assurance qualité. Néanmoins la condition sine qua non pour mettre en oeuvre un
cycle RAD est de s'appuyer sur un solide atelier de génie logiciel qui seul peut garantir
un passage rapide du concept à la mise en oeuvre. L'équipe projet doit nécessairement
maîtriser 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 périmètre et la planification de l'itération

2. Conception (Joint Application Design) qui couvre la conception,

description et organisation des données et des traitements avec les
utilisateurs

3. Construction (Construction Assistance Team) qui couvrement le

développement et les tests.

L'équipe de projet RAD doit nécessairement être composée d'experts capables de

proposer dans un temps réduit des solutions aux demandes des utilisateurs.

Enfin, l'intégration des applications dans un système 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'intégration est maîtrisée voire masquée
vis à vis de l'utilisateur. Il peut en résulter une impression de facilité qui peut mener
l'utilisateur à des exigences difficiles à remplir, ou des contestations sur les coûts.
 Partie2 : Les Méthodes de Développement des
Systèmes d'Information

1. Les Méthodes Cartésiennes :

La Méthode SADT : Méthode d'analyse fonctionnelle
La méthode SADT (Structured Analysis Design Technic) est une méthode
d'analyse hiérarchique et descendante apparue en 1977 au sein de la société
Sof'Tech Inc. C'est une méthode 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 présentent comme une méthode pour « communiquer des
problèmes ». On peut appliquer SADT à la gestion d'une entreprise tout comme à
un système automatisé

La méthode SADT est fondée sur un formalisme graphique et textuel facile à

apprendre. Elle permet d'une part de modéliser le problème posé (informatique,
automatique ou autre), avant de chercher à en extraire une solution, et d'autre part
d'assurer une communication efficace entre les différents intervenants concernés par
le système à analyser.

Historique
 Développée à SOFTTECH (U.S.A.) en 1976 ;
 Utilisée dans des projets industriels à ITT, THOMSON, AÉROSPATIALE etc.
 Peut être utilisée pour décrire (spécifier) n'importe quel système
 Sert à définir des modèles de systèmes existants, idéaux, réalisables compte tenu des
contraintes d'un projet, etc.

Le Modèle SADT

Un modèle SADT représente une image d'un système qu'on veut appréhender. La
technique d'analyse structurée identifie et organise les détails d'un tel système suivant
une hiérarchie parfaitement référencée.

Un modèle SADT est composé de :

 Diagrammes d'activités ou actigrammes, représentant l'ensemble des activités du

système.
 Diagrammes de données ou datagrammes, montrant l'ensemble des données du
système.
 Textes explicatifs sur les diagrammes.
 Diagrammes Pour Explication Seulement (PES).
 Schéma de la hiérarchie du système analysé.
 Glossaire définissant les principaux termes employés.
 Conditions d'activation.

Le « langage » SADT est composé de diagrammes (actigrammes et datagrammes)

obtenus par raffinements successifs et organisés en hiérarchie. Plus concrètement, il
s'agit de boîtes et de flèches utilisées pour représenter les notions suivantes :

Les entrées : ce sont les flèches horizontales entrant dans les boîtes.

Les sorties : ce sont les flèches horizontales sortant des boîtes.

Les mécanismes : ce sont les flèches venant du bas du schéma vers le bas des boîtes.

Les contrôles : les flèches venant du haut du schéma et pointant vers le haut des
boîtes.

Actigrammes
Un actigramme est identifié par un verbe d'action, il gère des données désignés par
des noms à partir de directives de contrôle (désignés par des noms aussi) en
s'appuyant sur lespotentialités des mécanismes. Il génère des données en sortie par
création ou par modifications des données en entrée.

Les données de contrôle ne sont pas modifiées par l'activité mais influent sur son
déroulement (ex. choix de l'utilisateur dans un menu).

Les mécanismes, ou supports, de l'activité désignent le « comment » de la réalisation

de l'activité. Ils peuvent aussi représenter « qui » la réalise. Les mécanismes peuvent
être développés par des modèles SADT indépendants.

Datagrammes
Un datagramme représente des données créées par des activités Génératrices (en
entrée) et consommées par des activités Utilisatrices (en sortie), sous le
contrôle d'activité de contrôle.

Pour une donnée, les mécanismes expriment le support de stockage (physique ou

logique) de la donnée.

Les textes explicatifs

Ils accompagnent les diagrammes pour présenter brièvement des généralités sur le
diagramme et les faits auxquels l'auteur accorde un intérêt particulier, sans toutefois
dupliquer l'information présentée par le diagramme lui-même. Ce texte doit être écrit
uniquement lorsque le diagramme aura atteint son niveau d'approbation, permettant
ainsi de vérifier la lisibilité du diagramme lors du cycle écriture/lecture. Le texte
explicatif du niveau global doit présenter les faits qui s'appliquent à l'ensemble du
modèle, fournissant ainsi une description globale du système.
 Les diagrammes pour explication seulement

Ils ne font pas vraiment partie du modèle. Il illustrent ou clarifient un aspect particulier
du système. Il est par exemple utile de produire une copie simplifiée des schémas
complexes.

Liste hiérarchique et numérotation des diagrammes

Les n uds d'un modèle SADT sont numérotés d'une façon précise. Le premier n ud
représente le système global. Il porte le numéro particulier A-0 (resp. D-0) pour le
modèle des actigrammes (resp. datagrammes). Il sera décomposé sur la feuille A0
(resp. D0) en plusieurs n uds portant les numéros A1, A2 ...An (resp. D1, D2, ...Dn),
décomposés à leur tours en A11, A12 etc.

Les pages de textes et de glossaires sont numérotées de manière identique avec les
lettres G et T respectivement.
Les Actigrammes :

 La boîte représente une action (indiquée par un verbe à l'infinitif).

 Les entrées sont transformées en sorties par l'action ou servent à alimenter l’action.
Elles ne sont donc pas forcément modifiées mais sont nécessaires au fonctionnement de
l’action. Elles sont interprétées comme étant des données.
 Le mécanisme effectue la transformation (nous pouvons interpréter ainsi : « le
mécanisme est le processeur », l'action étant « le processus »).
 Le contrôle n'est pas transformé par l'action mais permet la transformation. Le contrôle
peut être vu soit comme des paramètres ou soit comme un déclencheur.

Les Datagrammes
La boîte représente les données (indiquées par un nom).

Les entrées représentent les actions qui produisent les données de la boîte.

Les sorties représentent les actions qui utilisent les données de la boîte.

Le mécanisme est le support des données.

 On peut ajouter des étiquettes aux flèches en les reliant par un zigzag. En outre, les
flèches qui relient les boîtes représentent les contraintes fonctionnelles qui existent
entre les boîtes, mais ne représentent en aucun cas un flux de commande et n'ont pas
de signification séquentielle (n'impliquent pas de notion d'ordre d'exécution dans le
temps).

Analyse descendante

La méthode d’analyse descendante permet de comprendre pourquoi un système existe,

ou doit être conçu, quelles fonctions il doit remplir et enfin, comment elles sont
réalisées. Et cela, quelle qu’en soit la complexité.

La méthode, appuyée par un modèle graphique, procède par approche descendante en

ce sens que l’on va du plus général au plus détaillé, en s’intéressant aux activités du
système.

Plusieurs modèles SADT correspondant à différents points de vue du système sont

souvent établis pour une meilleure compréhension. En particulier, la perception d'un
système n'est pas la même pour l'utilisateur, le concepteur ou le programmeur. De la
même manière, plusieurs modèles SADT différents peuvent être conçus pour répondre
à une même demande.

Les deux principes de base sont :

1. Procéder par analyse descendante : Le premier niveau du modèle est en général très
abstrait, et progressivement les activités et les moyens nécessaires à leur réalisation sont
détaillés.
2. Délimiter le cadre de l’analyse : afin d’aborder l’analyse et la description du système, il
est fondamental de préciser le contexte (limite du système), le point de vue et l’objectif
de l’analyse.

Description de la méthode
 La première phase est la modélisation du système décrit précédemment qui en montre
les fonctions. Le contexte est identifié par les flèches qui entrent ou sortent de cette
boîte mère.

La décomposition en éléments, ou sous-fonctions de cette boîte-mère permet d’affiner

la perception du système et sa structure. Cette décomposition doit faire apparaître de
trois à six éléments maximum. Ces éléments ou boîtes sont des activités. Les flèches
qui les relient représentent les contraintes qui existent entre elles, mais ne représentent
en aucun cas un flux de commande et n’ont pas de signification séquentielle
(n’impliquent pas de notions d’ordre d’exécution dans le temps).

Les diagrammes ainsi construits sont des actigrammes ou encore diagrammes

d’activité.
Si le niveau de décomposition ne permet pas une totale compréhension du système, on
procède à une nouvelle construction d’actigrammes correspondant aux boîtes à
analyser plus en détail.

On définit ainsi successivement :

La boîte-mère A-0 (lire A moins zéro).

Le diagramme enfant de premier niveau A0.

Les diagrammes enfants de chaque boîte du diagramme précédent (qui devient

diagramme-mère) soit : A1, A2, A23,...

Les principales règles régissant la construction des diagrammes sont :

Chaque flèche entrant ou sortant de sa boîte-mère doit se retrouver sur le diagramme

enfant. Les flèches sont affectées d’un label indiquant leur nature. Celui-ci peut être
remplacé par un code dont la signification est donnée en marge.

Les supports peuvent ne pas être mentionnés si cela n’éclaire pas la compréhension.
On ne mentionne que les éléments nécessaires à ce que l’on veut montrer.

Diagramme multi-niveaux (A0, A1, ... ):

 Démarche
1. On commence par le diagramme de plus haut niveau A-0 (A moins zéro) représentant la
finalité du système.
2. Ensuite, on descend dans les niveaux en traçant le diagramme de niveau A0 (A zéro)
puis A1 et ainsi de suite en respectant la hiérarchie des niveaux. On décrit de cette
manière les sous-fonctions du système ce qui permet d'en affiner la perception et la
structure.

Si le niveau de décomposition ne permet pas une totale compréhension du système,

on procède à une nouvelle construction d'actigrammes.

Enfin, il est fondamental que le modèle circule entre les partenaires du projet afin
qu'un consensus soit clairement établi avant de passer au début de la phase de
conception et d’implémentation.

Règles d'écritures des diagrammes

 Chaque flèche entrant ou sortant de sa boîte-mère doit se retrouver sur le diagramme

enfant.
 Les flèches sont affectées d'un label indiquant leur nature.
 Les supports peuvent ne pas être mentionnés si cela n'éclaire pas la compréhension.
 Il est recommandé de décomposer une boîte en trois boîtes au minimum et sept boîtes
au maximum.
 Il est recommandé de présenter les boîtes suivant une même diagonale.
  Les flèches parenthésées, également appelées « flèches tunnel », indiquent qu'un flux de
données est présent dans une partie du modèle bien qu'il ne soit pas dessiné. On trouve
deux types de flèches tunnel :

La flèche tunnel dont les parenthèses entourent l'extrémité de la flèche qui est connectée à une
boîte, qui signifie que cette flèche existe implicitement dans toutes les boîtes résultant de la
décomposition de celle-ci.

La flèche tunnel dont les parenthèses se trouvent à l'autre extrémité, donc près des frontières
du diagramme, qui signifie que cette flèche existe implicitement dans toutes les boîtes qui
sont hiérarchiquement au dessus de la boîte concernée ; c'est-à-dire sa boîte mère, grand-
mère, ... jusqu'à A0 compris.
Exemple 1:

Exemple 2

Position de SADT dans la gestion d'un projet

 SADT va permettre d'aider à la gestion d'un projet. Par son rôle d'analyse, il sera
possible de l'utiliser à tous niveaux de la conception du SA au codage
(programmation du système automatisé).
SADT est avant tout un langage de communication. Cette communication se fait à
différents niveaux. Au niveau de l'élaboration du projet tout d'abord en permettant
par son formalisme à chacun de participer, ensuite lors d'explications à des
intervenants extérieurs son formalisme permet à chacun d'appréhender le SA.

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

L'objectif de cette étude doit mener les intervenants (ingénieurs, techniciens,
opérateurs) à un tout qui soit cohérent et homogène avec le système à étudier.
Dans n'importe quel système automatisé, circulent un certain nombre de flux de
données. Les flux les plus caractéristiques sont :
- les flux de pièces : flux qui caractérisent la valeur ajoutée à un produit.
- Les flux d'informations : ces flux vont permettre à l'outil de production de pouvoir
évoluer.
- Les flux énergétiques.
- les flux divers (copeaux, fluides de coupe, rejets divers, etc...).
L'analyse SADT va permettre d'organiser ces flux de données pour donner une
vision globale du système puis par une analyse des niveaux successifs, permettre de
préciser de plus en plus finement le rôle de chacun des éléments du système. La
finesse de cette description dépendra directement des besoins des utilisateurs.

Conclusions
a) SADT est un outil graphique de représentation.
b) SADT oblige à consigner par écrit les décisions d'une équipe de travail. Ceci
permet progressivement de créer une documentation complète.
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 représentation structurée ascendante ou
descendante.
e) Si SADT est utilisé complètement (Actigrammes et Datagrammes) il permet
de programmer directement un système automatisé.

2. Les Méthodes Systémiques:

La Méthode MERISE: (Les grandes lignes uniquement, le contenu plus
détaillé est en train d'être finalisé)

MERISE est une méthode de conception, de développement et de réalisation de

projets informatiques. Le but de cette méthode est d'arriver à concevoir un système
d'information. La méthode MERISE est basée sur la séparation des données et des
traitements à effectuer en plusieurs modèles conceptuels et physiques. La
 séparation des données et des traitements assure une longévité au modèle. En effet,
l'agencement des données n'a pas à être souvent remanié, tandis que les traitements
le sont plus fréquemment.

La méthode MERISE date de 1978-1979, et fait suite à une consultation nationale

lancée en 1977 par le ministère de l'Industrie dans le but de choisir des sociétés de
conseil en informatique afin de définir une méthode de conception de systèmes
d'information. Les deux principales sociétés ayant mis au point cette méthode sont
le CTI (Centre Technique d'Informatique) chargé de gérer le projet, et le CETE
(Centre d'Etudes Techniques de l'Equipement) implanté à Aix-en-Provence.

Cycle d'abstraction de conception des systèmes d'information:

La conception du système d'information se fait par étapes, afin d'aboutir à un

système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de
valider une à une chacune des étapes en prenant en compte les résultats de la phase
précédente. D'autre part, les données étant séparées des traitements, il faut vérifier
la concordance entre données et traitements afin de vérifier que toutes les données
nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues.

Cette succession d'étapes est appelée cycle d'abstraction pour la conception des
systèmes d'information :

L'expression des besoins est une étape consistant à définir ce que l'on attend du système
d'information automatisé, il faut pour cela :

 Faire l'inventaire des éléments nécessaires au système d'information

 Délimiter le système en s'informant auprès des futurs utilisateurs

Cela va permettre de créer le MCC (Modèle Conceptuel de la Communication) qui définit les
flux d'informations à prendre en compte.
L'étape suivante consiste à mettre au point le MCD (Modèle Conceptuel des Données) et
le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre
en compte.
Le modèle organisationnel consiste à définir le MOT (Modèle Organisationnel
des Traitements), décrivant les contraintes dues à l'environnement (organisationnel, spatial et
temporel).
Le modèle logique, MLD (Modèle Logique des Données), représente un choix logiciel pour
le système d'information.
Le modèle physique reflète un choix matériel pour le système d'information.

3. Approche Objet:
3.1. Introduction :

Dans une approche fonctionnelle, vos programmes sont composés d'une série de fonctions,
qui assurent ensemble certains services. Il s'agit d'une approche logique, cohérente et intuitive
de la programmation.
Cette approche a un avantage certain appelé la factorisation des comportements (c'est à dire
que pour créer une fonction d'une application, rien ne vous empêche d'utiliser un autre
ensemble de fonctions (qui sont donc déjà écrites)).
Mais, l'approche fonctionnelle a aussi ses défauts, 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 retouchée dans sa globalité.

L'approche fonctionnelle n'est pas adaptée au développement 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 répond aux limites de l'approche fonctionnelle par le concept

d’encapsulation (qui applique le principe d’abstraction) des données et des opérations qui les
manipulent dans les objets, c’est-à-dire qu’un objet n’est accessible que par ces opérations
visibles (son interface externe) et son implémentation (les structures de données associées) est
cachée.

Elle apporte l’indépendance entre les programmes, les données et les procédures parce que les
programmes peuvent partager les mêmes objets sans avoir à se connaître.

La programmation orientée objet consiste à modéliser informatiquement un ensemble

d'éléments d'une partie du monde réel (que l'on appelle domaine) en un ensemble d'entités
informatiques. Ces entités informatiques sont appelées objets. Il s'agit de données
informatiques regroupant les principales caractéristiques des éléments du monde réel (taille,
couleur, ...).
L'approche objet est une idée qui a désormais fait ses preuves. Simula a été le premier langage
de programmation à implémenter le concept de classes en 1967 ! En
1976, Smalltalkimplémente les concepts d'encapsulation, d'agrégation, et d'héritage (les
principaux concepts de l'approche objet). D'autre part, de nombreux langages orientés objets
ont été mis au point dans un but universitaire (Eiffel, Objective C, Loops, etc.).
La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme
d'objets, d'entités ayant une existence matérielle (chien, voiture, ampoule, ...) ou bien virtuelle
(sécurité sociale, temps, ...).

L’approche objet a introduit indépendamment de tout langage de programmation à

l’objet trois concepts de base : objet, classe et héritage entre classes. Les concepts objet et
classe sont interdépendants, c’est-à-dire qu’un objet est une instance d’une classe et la classe
décrit la structure et le comportement communs d’objets (ses instances).

L'Objet: Un objet est une abstraction d’un élément du monde réel. Il possède des
informations, par exemple nom, prénom, adresse, etc., et se comporte suivant un ensemble
d’opérations qui lui sont applicables.

De plus, un ensemble d'attributs caractérisent l'état d'un objet, et l'on dispose d'un ensemble
d'opérations (les méthodes) 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 données abstrait, caractérisé
par des propriétés (ses attributs et ses méthodes) communes à des objets, qui permet de créer
des objets possédant ces propriétés.

Objet = identité + état (attributs) + comportement (méthodes)

• L’identité:

L’objet possède une identité, qui permet de le distinguer des autres objets, indépendamment
de son état. On construit généralement cette identité grâce à un identifiant découlant
naturellement du problème (par exemple un produit pourra être repéré par un code, une
voiture par un numéro de série, ...)

• Les attributs:

Il s’agit des données caractérisant l’objet. Ce sont des variables stockant des informations
d’état de l’objet

• Les méthodes (appelées parfois fonctions membres):

Les méthodes d’un objet caractérisent son comportement, c’est-à-dire l’ensemble des actions
(appelées opérations) que l’objet est à même de réaliser. Ces opérations permettent de faire
réagir l’objet aux sollicitations extérieures (ou d’agir sur les autres objets). De plus, les
opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des valeurs
des attributs, ou bien les modifier.
La Notion de Classe:
On appelle classe la structure d’un objet, c’est-à-dire la déclaration de l’ensemble des entités
qui composeront un objet. Les objets de même nature ont en général la même structure et le
même comportement. La classe factorise les caractéristiques communes de ces objets et
permet de les classifier. Un objet est donc, une instanciation d’une classe, c’est la raison pour
laquelle on pourra parler indifféremment d’objet ou d’instance (éventuellement d’occurrence).
Toutes les instances d'une classe constituent l'extension de la classe.
Classe = instanciation + attributs (variables d'instances) + opérations

• L’instanciation:

L’objet possède une identité, qui permet de le distinguer des autres objets, indépendamment
de son état. L'instanciation représente la relation entre un objet et sa classe d'appartenance qui
a permis de le créer.

• Les attributs: (appelés aussi variables d'instances ou données membres)

Il s'agit des données représentant l'état de l'objet. Ils ont un nom et soit un type de base
(simple ou construit) soit une classe (l'attribut référençant un objet de la même classe ou une
autre classe).

• Les opérations: (appelées parfois méthodes ou fonctions membres)

Il s'agit des opérations applicables aux objets de la classe. Elles peuvent modifier tout ou en
partie l'état d'un objet et retourner des valeurs calculées à partir de cet état.

Exemple: Si on définit la classe voiture, les objets Peugeot 406, Renault 18 seront des
instanciations de cette classe. Il pourra éventuellement exister plusieurs objets Peugeot 406,
différenciés par leur numéro de série. Mieux: deux instanciations de classes pourront avoir
tous leurs attributs égaux sans pour autant être un seul et même objet. C'est le cas dans le
monde réel, deux T-shirts peuvent être strictement identiques et pourtant ils sont distincts.
D'ailleurs en les mélangeant il serait impossible de les distinguer...
L’Encapsulation:
Le concept d’encapsulation est un mécanisme consistant à rassembler les données et les
méthodes au sein d’une structure en cachant l’implémentation de l’objet, c’est-à-dire en
empêchant l’accès aux données par un autre moyen que les services proposés. L'utilisateur
d'une classe n'a pas forcément à savoir de quelle façon sont structurées les données dans
l'objet, cela signifie qu'un utilisateur n'a pas à connaître l'implémentation. Ainsi, en interdisant
l'utilisateur de modifier directement les attributs, et en l'obligeant à utiliser les fonctions
définies pour les modifier (appelées interfaces). L’encapsulation permet donc de garantir
l’intégrité des données contenues dans l’objet (on pourra par exemple s'assurer que le type
des données fournies est conforme à nos attentes, ou encore que les données se trouvent bien
dans l'intervalle attendu)..
L’encapsulation permet de définir des niveaux de visibilité des éléments de la classe. Ces
niveaux de visibilité définissent les droits d’accès aux données selon que l’on y accède par
une méthode de la classe elle-même, d’une classe héritière, ou bien d’une classe quelconque.
Il existe trois niveaux de visibilité :

• Publique : Les fonctions de toutes les classes peuvent accéder aux données ou aux
méthodes d’une classe définie avec le niveau de visibilité public. Il s’agit du plus bas niveau
de protection des données.

• Protégée : l’accès aux données est réservé aux fonctions des classes héritières, c’est-à-dire
par les fonctions membres de la classe ainsi que des classes dérivées.

• Privée : l’accès aux données est limité aux méthodes de la classe elle-même. Il s’agit du
niveau de protection des données le plus élevé.

La Notion d'Héritage:

L’héritage (en anglais inheritance) est un principe propre à la programmation orientée objet,
permettant de créer une nouvelle classe à partir d’une classe existante. Le nom d’"héritage"
(ou parfois dérivation de classe) provient du fait que la classe dérivée (la classe nouvellement
créée) contient les attributs et les méthodes de sa superclasse (la classe dont elle dérive).

L’intérêt majeur de l’héritage est de pouvoir définir de nouveaux attributs et de nouvelles

méthodes pour la classe dérivée, qui viennent s’ajouter à ceux et celles héritées. Par ce moyen
on crée une hiérarchie de classes de plus en plus spécialisées. Cela a comme avantage majeur
de ne pas avoir à repartir de zéro lorsque l'on veut spécialiser une classe existante. De cette
manière il est possible d'acheter dans le commerce des librairies de classes, qui constituent
une base, pouvant être spécialisées à loisir (on comprend encore un peu mieux l'intérêt pour
l'entreprise qui vend les classes de protéger les données membres grâce à l'encapsulation...).
Hiérarchie des Classes:

La hiérarchie des classes ou l'association (relationship) est un concept essentiel pour la

modélisation des données. On peut représenter sous forme de hiérarchie de classes, parfois
appelée arborescence de classes, la relation de parenté qui existe entre les différentes
classes. La hiérarchie ou arborescence commence par une classe générale
appelée superclasse (classe de base, classe parent, classe ancêtre, classe mère ou classe père).
Puis les classes dérivées (classe fille ou sous-classe) deviennent de plus en plus
spécialisées. Ainsi, on peut généralement exprimer la relation qui lie une classe fille à sa mère
par la phrase "est un" (de l'anglais "is a").

Héritage Multiple:

Certains langages orientés objet, tels que le C++, permettent de faire de l’héritage
multiple. Ce qui signifie qu’ils offrent la possibilité de faire hériter une classe de deux
superclasses. Ainsi, cette technique permet de regrouper au sein d’une seule et même classe
les attributs et les méthodes de plusieurs classes. L'héritage multiple représente le mécanisme
par lequel une sous-classe hérite des propriétés de plus d'une super-classe.
Polymorphisme:
Le nom de polymorphisme vient du grec et signifie qui peut prendre plusieurs formes. Cette
caractéristique essentielle de la programmation orientée objet caractérise la possibilité de
définir plusieurs fonctions de même nom mais possédant des paramètres différents (en
nombre et/ou en type), si bien que la bonne fonction sera choisie en fonction de ses
paramètres lors de l’appel.

Le polymorphisme représente la faculté d'une opération de s'appliquer à des objets de classes

différentes.

On distingue généralement trois types de polymorphisme :

 Le polymorphisme ad hoc (également surcharge ou overloading)

 Le polymorphisme d'héritage
(également redéfinition, spécialisation ou overriding)
 Le polymorphisme paramétrique (également généricité ou template)

Le Polymorphisme Ad Hoc:

Le polymorphisme ad hoc permet d'avoir des fonctions de même nom, avec des
fonctionnalités 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 définir des opérateurs dont l'utilisation sera
différente selon le type des paramètres qui lui sont passés. Il est donc possible par exemple de
surcharger l'opérateur + et de lui faire réaliser des actions différentes selon qu'il s'agit d'une
opération entre deux entiers (addition) ou entre deux chaînes de caractères (concaténation).

Le Polymorphisme d'Héritage:

La possibilité de redéfinir une méthode dans des classes héritant d'une classe de base s'appelle
la spécialisation. Il est alors possible d'appeler la méthode d'un objet sans se soucier de son
type intrinsèque : il s'agit du polymorphisme d'héritage. Ceci permet de faire abstraction des
détails des classes spécialisées 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, héritant
chacun de l'objet pièce. La méthode mouvement () pourra, grâce au polymorphisme d'héritage,
effectuer le mouvement approprié en fonction de la classe de l'objet référencé au moment de
l'appel. Cela permettra notamment au programme de dire piece.mouvement sans avoir à se
préoccuper de la classe de la pièce.

Le Polymorphisme Paramétrique:

Le polymorphisme paramétrique, appelé généricité, représente la possibilité de définir

plusieurs fonctions de même nom mais possédant des paramètres différents (en nombre et/ou
en type). Le polymorphisme paramétrique rend ainsi possible le choix automatique de la
bonne méthode à adopter en fonction du type de donnée passée en paramètre.
Le polymorphisme rend possible le choix automatique de la bonne méthode à adopter en
fonction du type de donnée passée en paramètre. Ainsi, on peut par exemple définir plusieurs
méthodes 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 définit au gré de l’auteur la somme de deux
caractères.
 etc. ….

On appelle signature le nombre et le type (statique) des arguments d'une fonction. C'est donc
la signature d'une méthode qui détermine quelle méthode sera appelée.
3.2. Les Avantages de l’Approche Objet:

* La modélisation des objets de l’application:

Consiste à modéliser informatiquement un ensemble d’éléments d’une partie du monde réel

en un ensemble d’entités informatiques. Ces entités informatiques sont appelées objet.

* La modularité et la réutilisabilité:

La programmation modulaire permet la réutilisation du code, via l'écriture de librairies.

* L’extensibilité:

Pour une meilleure productivité des développeurs et une plus grande qualité des applications).
La maîtrise de la complexité d’un système repose sur trois principes :

 L’abstraction (voir le comportement des objets indépendamment de leur

représentation interne).
 La décomposition (des objets complexes en objets plus simples)
 La connexion (des objets suivant leurs interactions)

3. Les Méthodes Orientées Objet:

3.1. Les méthodes objet:

La modélisation objet consiste à créer une représentation informatique des éléments du monde
réel, sans se préoccuper de l’implémentation, ce qui signifie indépendamment d’un langage
de programmation. Il s’agit donc de déterminer les objets présents et d’isoler leurs données
et les fonctions qui les utilisent. Pour cela, des méthodes de conception et de développement
orientées objet ont été mises au point. Entre 1970 et 1990, de nombreux analystes ont mis au
point des approches orientées objets, si bien qu’en 1994 il existait plus de 50 méthodes objet.
Toutefois seules 3 méthodes ont véritablement émergées :
  La méthode OMT de Rumbaugh
 La méthode BOOCH’93 de Booch
 La méthode OOSE de Jacobson

A partir de 1994, Rumbaugh et Booch (rejoints en 1995 par Jacobson) ont unis leurs efforts
pour mettre au point la méthode UML (Unified Modeling Language), qui permet de définir
une notation standard en incorporant les avantages de chacune des méthodes précédentes
(ainsi que celles d’autres analystes).
3.2. Présentation générale de la méthode OMT:
Introduction:

OMT (Object Modeling Technique) utilise trois modèles pour décrire un système : objet,
dynamique et fonctionnel. Ces trois modèles sont complémentaires et inter-reliés. Le modèle
objet est fondamental et préalable aux deux autres.

OMT permet de modéliser un système selon trois points de vue complémentaires, chacun
capturant des aspects essentiels du système, tous requis pour une description complète:

Le modèle objet est le point de vue des données.

 Le modèle dynamique est le point de vue du contrôle et des comportements.

 Le modèle fonctionnel est le point de vue des transformations apportées aux
données.

Un logiciel combine normalement ces trois aspects: il transforme (modèle 3) des données
(modèle 1) d'une façon ordonnée dans le temps (modèle 2).
Esprit de la méthode:

 Modélisation d'objets du monde réel.

 Utilisation de ces objets pour concevoir un système indépendamment des
langages d'implantation.

Avantages:

 Meilleure compréhension des besoins

 Spécification et conception plus précise
 Meilleure maintenabilité des systèmes réalisés
 La même méthode (concepts + notations) peut être utilisée tout au long du cycle
de développement. Il n'est donc pas nécessaire de traduire une formulation en une
autre à chaque étape, comme le nécessitent d'autres approches.

Les outils:

 Un jeu de concepts orientés objet

 Une notation graphique indépendante du langage de programmation, utilisable
pour :

o Analyser les besoins

o Spécifier et concevoir
 o Implanter la solution

Le cycle de vie logiciel (abrégé):

 Définition des besoins

 Spécification des besoins
 Spécification de conception
 Programmation

Généralité de la méthode:

OMT n'est pas une méthode dédiée explicitement à la programmation orientée objet. On
montre l'intérêt de la méthode pour spécifier des applications dont le langage cible n'est pas
orienté objet.

OMT permet l'échange clair et non ambigu des idées.

Aspect fondamentaux de OMT:

 l'accent est mis sur l'utilisation des objets pour modéliser le monde réel plutôt que
comme un mécanisme d'un langage particulier.
 les relations inter objets sont élevées à un rang aussi élevé que les classes
 moins d'accent est mis sur l'héritage et les méthodes
 les mécanismes subtils liés à l'héritage sont laissés de côté
 un accent particulier est mis sur le typage, les classes, la modélisation
 la terminologie utilisée est celle qui domine quand elle existe

Exercices:

Tous les objets ont une identité et sont identifiables. D'un point de vue informatique, il n'est
pas toujours évident de prévoir tout ce qui permet de les distinguer. Pour chacun de ces
collections d'objets, décrire de quelle façon on pourrait les distinguer :

 Tous les humains, dans l'idée de leur envoyer du courrier

 Tous les humains, pour des enquêtes criminelles
 Tous les clients qui possèdent un coffre dans une banque
 Tous les téléphones d'Algérie
 Tous les clients d'une compagnie de téléphone, pour la facturation
 Toutes les adresses électroniques

4. Les Trois Modèles d'OMT:

OMT utilise trois modèles pour décrire un système : objet, dynamique et fonctionnel

QUOI : le modèle objet définit la structure statique des objets et leurs inter-relations

 Classes
 Liens
 Héritage
QUAND : le modèle dynamique décrit les interactions entre les objets

 Diagrammes de transition d'états

 Contrôle (conditions de déclenchement d'une opération)
 Evénements, messages

COMMENT : le modèle fonctionnel décrit les transformations appliquées aux données

 Diagrammes de flots de données

 Processus

Ces trois modèles sont complémentaires et interreliés.

Le modèle objet est fondamental et préalable aux deux autres.

OMT permet de modéliser un système selon trois points de vue complémentaires, chacun
capturant des aspects essentiels du système, tous requis pour une description complète:

 Le modèle objet est le point de vue des données.

 Le modèle dynamique est le point de vue du contrôle, des comportements.
 Le modèle fonctionnel est le point de vue des transformations apportées aux données.

Un logiciel combine normalement ces trois aspects :

Il transforme (modèle 3) des données (modèle 1) d'une façon ordonnée dans le temps
(modèle 2).

 Chaque modèle comporte des références aux deux autres ; ces liens sont limités et
explicites
 Chaque modèle peut être examiné d'une façon relativement indépendante des deux
autres
 Chaque modèle évolue durant le cycle de développement :

o Pendant l'analyse un modèle du domaine applicatif est réalisé sans idée

d'implantation
o Pendant la conception, ce modèle est complété par des éléments relatifs au
domaine de la solution
o Pendant l'implantation, ces deux aspects sont réalisés

ATTENTION : le terme "modèle" recouvre deux réalités distinctes, généralement claires

par le contexte:

 La vue du système : modèle objet, dynamique, fonctionnel. On devrait dire sous

modèle
 Une étape dans le développement : analyse, conception, implantation

5.1. Le modèle objet: (Le "Quoi?")

Ce modèle décrit la structure des objets d'un système :
  Leur identité
 Leurs relations
 Leurs attributs
 Leurs opérations

Les objets sont les éléments sur lesquels les autres modèles s'appuient. Ce sont les atomes (au
sens grec : insécable) de nos modèles a l'issue de l'analyse le modèle objet comporte des
termes familiers aux personnes du domaine, et normalement aucune référence informatique.
Par contre, le modèle de conception comporte des références informatiques. Bien évidemment
le modèle objet est représenté par des diagrammes décrivant les différentes classes,
hiérarchisées, et comportant les attributs et les opérations utiles.
5.2. Le modèle dynamique: (Le "Quand?")
Le modèle dynamique décrit les interactions entre les objets. Il décrit les aspects d'un système
où interviennent :

 Le temps
 Les séquences
 Les événements
 Séquences d'événements
 Les états qui définissent le contexte pour des événements
 L'organisation des événements et des états

Le modèle dynamique décrit également le contrôle (conditions de déclenchement d'une

opération). Les séquences d'opérations ont lieu sans se préoccuper de:

 Ce qu'elles font
 Ce sur quoi elles opèrent
 Comment elles sont programmées

Diagrammes d'état:

Le modèle dynamique est représenté graphiquement à l'aide de diagrammes d'états. Chaque

diagramme décrit les états et séquences d'événements permises pour une classe d'objets. Ces
diagrammes comportent des références aux autres modèles :

 Les actions correspondent aux fonctions du modèle fonctionnel

 Les événements deviennent des opérations sur des objets du modèle objet

5.3. Le modèle fonctionnel: (Le "Comment?")

Ce modèle décrit les aspects d'un système concernés par des changements de valeurs :

 Fonctions
 Applications
 Contraintes
 Dépendances fonctionnelles
Ce modèle décrit ce que fait un système, sans considération pour quand ou comment il le fait.
Le modèle fonctionnel est représenté par des Diagrammes de Flux de Données (DFD).
Les DFD montrent :

 Les dépendances entre valeurs

 Le calcul de données de sortie en fonction de données en entrée et de traitements sans
considérer quand, ni si les fonctions correspondantes sont exécutées.

5.4. Relations entre les modèles:

On a vu que chaque modèle décrit un aspect d'une réalité, avec des références aux deux autres
modèles. Le modèle objet décrit les structures de données utilisées par les modèles dynamique
et fonctionnel. Les opérations du modèle objet correspondent à des événements du modèle
dynamique et à des fonctions du modèle fonctionnel. Le modèle dynamique décrit la structure
de contrôle des objets. Il montre les décisions qui dépendent de valeurs dans l'objet et qui
provoquent des actions qui changent cet état et appellent des fonctions. Le modèle fonctionnel
décrit les fonctions invoquées par des opérations du modèle objet et des actions du modèle
dynamique. Les fonctions opèrent sur des données décrites dans le modèle objet. Le modèle
fonctionnel décrit aussi des contraintes sur les valeurs des objets

5.5. Difficultés:
On ne sait pas toujours décider si une information doit ou non figurer dans un modèle. Ceci
est normal car un modèle décrit ses frontières de façon toujours brutale au début, et certaines
limites doivent être déplacées. Certaines propriétés d'un système peuvent parfois être mal
représentées par OMT. C'est également normal, aucune méthode ne peut être complète. Dans
ce cas, le recours à tout autre langage ou méthode (graphique ou non, spécifique au domaine
ou non) est souhaitable ou même nécessaire.

5.6. Exercices:
1) Parmi les caractéristiques d'un pneu on trouve sa taille, son composant, sa construction
interne, dessin, prix, poids, durée de vie.

Quels facteurs sont importants pour celui qui :

 Achète un pneu pour sa voiture?

 réalise un système de simulation de performance d'un système anti-glissement pour
voitures?
 construit une balançoire à laide d'un pneu?

2) Décider quel modèle (objet, dynamique, fonctionnel) est pertinents pour les aspects
suivants d'un programme de jeu aux échecs. Le jeu et les pièces sont visualisés sur un écran.
Les coups de l'humain sont décrits par un curseur et une souris

 l'interface utilisateur qui décrit les coups

 représentation d'une configuration de pièces sur le plateau de jeu
 représentation d'une séquence de coups possibles
 validation d'un coup joué par l'humain