DSI2 DSI2

ISET KEBILI

ISET KEBILI
L’examen des causes de succès et d’échec est instructif : la plupart des échecs

Chapitre 1 proviennent non de l’informatique, mais de la maîtrise d’ouvrage, en comprenant

sous ce terme à la fois les dirigeants et les concepteurs des métiers.
Pour ces raisons, le développement de logiciels dans un contexte professionnel suit
souvent des règles strictes encadrant la conception et permettant le travail en groupe
Introduction à la modélisation objet et la maintenance du code.
Ainsi, une nouvelle discipline est née : le génie logiciel.

1.3. Le génie logiciel

1. Le génie logiciel
Le génie logiciel est un domaine de recherche qui a été défini (fait rare) du 7 au 11
1.1 L’informatisation octobre 1968, à Garmisch-Partenkirchen, sous le parrainage de l'OTAN. Il a pour
objectif de répondre à un problème qui s'énonçait en deux constatations : d'une part
L’informatisation est le phénomène le plus important de notre époque. Elle s’immisce le logiciel n'était pas fiable, d'autre part, il était incroyablement difficile de réaliser
maintenant dans la plupart des objets de la vie courante et ce, que ce soit dans dans des délais prévus des logiciels satisfaisant leur cahier des charges.
l’objet proprement dit, ou bien dans le processus de conception ou de fabrication de
cet objet. L'objectif du génie logiciel est d'optimiser le coût de développement du logiciel.
Actuellement, l’informatique est au cœur de toutes les grandes entreprises. Le L'importance d'une approche méthodologique s'est imposée à la suite de la crise de
système d’information d’une entreprise est composé de matériels et de logiciels. Plus l'industrie du logiciel à la fin des années 1970. Cette crise de l'industrie du logiciel
précisément, les investissements dans ce système d’information se reparaissent était principalement due à :

BELHASSEN ROCHDY

BELHASSEN ROCHDY
généralement de la manière suivante : 20% pour le matériel et 80% pour le logiciel.
En effet, depuis quelques années, la fabrication du matériel est assurée par • l'augmentation des coûts ;
quelques fabricants seulement. Ce matériel est relativement fiable et le marché est • les difficultés de maintenance et d'évolution ;
standardisé. Les problèmes liés à l’informatique sont essentiellement des problèmes • la non-fiabilité ;
de logiciel.
• le non-respect des spécifications ;
• le non-respect des délais.
1.2 Les logiciels
La maintenance est devenue une facette très importante du cycle de vie d'un logiciel.
Un logiciel ou une application est un ensemble de programmes, qui permet à un En effet, une enquête effectuée aux É.-U. en 1986 auprès de 55 entreprises révèle
ordinateur ou à un système informatique d’assurer une tâche ou une fonction en que 53% du budget total d'un logiciel est affecté à la maintenance. Ce coût est
particulier (exemple : logiciel de comptabilité, logiciel de gestion des prêts). réparti comme suit :
Les logiciels, suivant leur taille, peuvent être développés par une personne seule,
une petite équipe, ou un ensemble d’équipes coordonnées. Le développement de • 34% maintenance évolutive (modification des spécifications initiales) ;
grands logiciels par de grandes équipes pose d’importants problèmes de conception
• 10% maintenance adaptative (nouvel environnement, nouveaux utilisateurs) ;
et de coordination. Or, le développement d’un logiciel est une phase absolument
cruciale qui monopolise l’essentiel du coût d’un produit et conditionne sa réussite et • 17% maintenance corrective (correction des bogues) ;
sa pérennité. • 16% maintenance perfective (améliorer les performances sans changer les
En 1995, une étude du Standish Group dressait un tableau accablant de la conduite spécifications) ;
des projets informatiques. • 6% assistance aux utilisateurs ;
Reposant sur un échantillon représentatif de 365 entreprises, totalisant 8380 • 6% contrôle qualité ;
applications, cette étude établissait que : • 7% organisation/suivi ;
• 16,2% seulement des projets étaient conformes aux prévisions initiales,
• 4% divers.
• 52,7% avaient subi des dépassements en coût et délai d’un facteur 2 à 3 avec
diminution du nombre des fonctions offertes,
Pour apporter une réponse à tous ces problèmes, le génie logiciel s'intéresse
• 31,1% ont été purement abandonnés durant leur développement. particulièrement à la manière dont le code source d'un logiciel est spécifié puis
Pour les grandes entreprises (qui lancent proportionnellement davantage de gros produit. Ainsi, le génie logiciel touche au cycle de vie des logiciels :
projets), le taux de succès est de 9% seulement, 37% des projets sont arrêtés en
cours de réalisation, 50% aboutissent hors délai et hors budget.

Chapitre1. Introduction à la modélisation objet 1 Chapitre1. Introduction à la modélisation objet 2

 DSI2 DSI2

ISET KEBILI

ISET KEBILI
• l'analyse du besoin, Ces facteurs sont parfois contradictoires, le choix des compromis doit s'effectuer en
• l'élaboration des spécifications, fonction du contexte.
• la conceptualisation,
• le développement,
• la phase de test, 2. Pourquoi et comment modéliser ?
• la maintenance.
2.1 Notions de modèle et de modélisation
Les projets relatifs à l'ingénierie logicielle sont généralement de grande envergure et
dépassent souvent les 10 000 lignes de code. C'est pourquoi ces projets nécessitent a) Qu’est-ce qu’un modèle ?
une équipe de développement bien structurée. La gestion de projet se retrouve
naturellement intimement liée au génie logiciel. Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains
détails), d'une entité (phénomène, processus, système, etc.) du monde réel en vue
de le décrire, de l'expliquer ou de le prévoir. Modèle est synonyme de théorie, mais
avec une connotation pratique : un modèle, c'est une théorie orientée vers l'action
1.4. Notion de qualité pour un logiciel
qu'elle doit servir.
En génie logiciel, divers travaux ont mené à la définition de la qualité du logiciel en
Concrètement, un modèle permet de réduire la complexité d'un phénomène en
termes de facteurs, qui dépendent, entre autres, du domaine de l'application et des
éliminant les détails qui n'influencent pas son comportement de manière significative.
outils utilisés. Parmi ces derniers nous pouvons citer :
Il reflète ce que le concepteur croit important pour la compréhension et la prédiction
du phénomène modélisé. Les limites du phénomène modélisé dépendant des
Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies
objectifs du modèle.
par le cahier des charges et les spécifications.

BELHASSEN ROCHDY

BELHASSEN ROCHDY
Voici quelques exemples de modèles :
Fiabilité ou robustesse : aptitude d'un produit logiciel à fonctionner dans des
conditions anormales.
Modèle météorologique
Extensibilité (maintenance) : facilité avec laquelle un logiciel se prête à sa
• à partir de données d'observation (satellite…), il permet de prévoir les
maintenance, c'est-à-dire à une modification ou à une extension des fonctions qui lui
conditions climatiques pour les jours à venir.
sont demandées.
Modèle économique
Réutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de
nouvelles applications. • peut par exemple permettre de simuler l'évolution de cours boursiers en
fonction d'hypothèses macro-économiques (évolution du chômage, taux de
Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres croissance…).
logiciels. Modèle démographique

Efficacité : Utilisation optimale des ressources matérielles. • définit la composition d'un panel d'une population et son comportement, dans
le but de fiabiliser des études statistiques, d'augmenter l'impact de démarches
Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents commerciales, etc.
environnements matériels et logiciels. Plans
• Les plans sont des modèles qui donnent une vue d'ensemble du système
Vérifiabilité : facilité de préparation des procédures de test. concerné. Par exemple, dans le bâtiment, pour la construction d'un immeuble,
il faut préalablement élaborer de nombreux plans :
Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des o plans d'implantation du bâtiment dans son environnement ;
accès non autorisés. o plans généraux du bâtiment et de sa structure ;
o plans détaillés des différents locaux, bureaux, appartements…
Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données,
o plans des câblages électriques ;
d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.
o plans d'écoulements des eaux, etc.

Chapitre1. Introduction à la modélisation objet 3 Chapitre1. Introduction à la modélisation objet 4

 DSI2 DSI2

ISET KEBILI

ISET KEBILI
Les trois premiers exemples sont des modèles que l'on qualifie de prédictifs. Le frontière des responsabilités, ce qui contrarie parfois les informaticiens dans un
dernier, plus conceptuel, possède différents niveaux de vues comme la plupart des premier temps, avant qu'ils n'en voient apparaître les bénéfices.
modèles en génie logiciel.
Maîtrise d'ouvrage et maîtrise d'œuvre
b) Pourquoi modéliser ?
d) Maîtrise d’ouvrage et maîtrise d’œuvre
Modéliser un système avant sa réalisation permet de mieux comprendre le
fonctionnement du système. C'est également un bon moyen de maîtriser sa Maître d'ouvrage (MOA) : Le MOA est une personne morale (entreprise, direction,
complexité et d'assurer sa cohérence. Un modèle est un langage commun, précis, etc.), une entité de l'organisation. Ce n'est jamais une personne.
qui est connu par tous les membres de l'équipe et il est donc, à ce titre, un vecteur
privilégié pour communiquer. Cette communication est essentielle pour aboutir à une Maître d'œuvre (MOE) : Le MOE est une personne morale (entreprise, direction,
compréhension commune aux différentes parties prenantes (notamment entre la etc.) garante de la bonne réalisation technique des solutions. Il a, lors de la
maîtrise d'ouvrage et la maîtrise d'œuvre informatique) et précise d'un problème conception du SI, un devoir de conseil vis-à-vis du MOA, car le SI doit tirer le meilleur
donné. parti des possibilités techniques.
Dans le domaine de l'ingénierie du logiciel, le modèle permet de mieux répartir les Le MOA est client du MOE à qui il passe commande d'un produit nécessaire à son
tâches et d'automatiser certaines d'entre elles. C'est également un facteur de activité.
réduction des coûts et des délais. Par exemple, les plateformes de modélisation
savent maintenant exploiter les modèles pour faire de la génération de code (au Le MOE fournit ce produit ; soit il le réalise lui-même, soit il passe commande à un ou
moins au niveau du squelette) voire des allers-retours entre le code et le modèle plusieurs fournisseurs (« entreprises ») qui élaborent le produit sous sa direction.
sans perte d'information. Le modèle est enfin indispensable pour assurer un bon
niveau de qualité et une maintenance efficace. En effet, une fois mise en production, La relation MOA et MOE est définie par un contrat qui précise leurs engagements
l'application va devoir être maintenue, probablement par une autre équipe et, qui plus

BELHASSEN ROCHDY

BELHASSEN ROCHDY
mutuels.
est, pas nécessairement de la même société que celle ayant créé l'application.
Lorsque le produit est compliqué, il peut être nécessaire de faire appel à plusieurs
Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les fournisseurs. Le MOE assure leur coordination ; il veille à la cohérence des
systèmes non triviaux sont mieux modélisés par un ensemble de modèles fournitures et à leur compatibilité. Il coordonne l'action des fournisseurs en contrôlant
indépendants. Selon les modèles employés, la démarche de modélisation n'est pas la qualité technique, en assurant le respect des délais fixés par le MOA et en
la même. minimisant les risques.
c) Qui doit modéliser ? Le MOE est responsable de la qualité technique de la solution. Il doit, avant toute
livraison au MOA, procéder aux vérifications nécessaires (« recette usine »).
La modélisation est souvent faite par la maîtrise d'œuvre informatique (MOE). C'est
malencontreux, car les priorités de la MOE résident dans le fonctionnement de la
2.2 Le cycle de vie d’un logiciel
plateforme informatique et non dans les processus de l'entreprise.
Le cycle de vie d'un logiciel (en anglais software lifecycle), désigne toutes les étapes
Il est préférable que la modélisation soit réalisée par la maîtrise d'ouvrage (MOA) de
du développement d'un logiciel, de sa conception à sa disparition. L'objectif d'un tel
sorte que le métier soit maître de ses propres concepts. La MOE doit intervenir dans
découpage est de permettre de définir des jalons intermédiaires permettant la
le modèle lorsque, après avoir défini les concepts du métier, on doit introduire les
validation du développement logiciel, c'est-à-dire la conformité du logiciel avec les
contraintes propres à la plateforme informatique.
besoins exprimés, et la vérification du processus de développement, c'est-à-dire
l'adéquation des méthodes mises en œuvre.
Il est vrai que certains métiers, dont les priorités sont opérationnelles, ne disposent
pas toujours de la capacité d'abstraction et de la rigueur conceptuelle nécessaires à
L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant
la formalisation. La professionnalisation de la MOA a pour but de les doter de ces
plus élevé qu'elles sont détectées tardivement dans le processus de réalisation. Le
compétences. Cette professionnalisation réside essentiellement dans l'aptitude à
cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité
modéliser le système d'information du métier : le maître mot est modélisation.
du logiciel, les délais de sa réalisation et les coûts associés.
Lorsque le modèle du système d'information est de bonne qualité, sobre, clair,
stable, la maîtrise d'œuvre peut travailler dans de bonnes conditions. Lorsque cette
Le cycle de vie du logiciel comprend généralement au minimum les étapes
professionnalisation a lieu, elle modifie les rapports avec l'informatique et déplace la
suivantes :

Chapitre1. Introduction à la modélisation objet 5 Chapitre1. Introduction à la modélisation objet 6

 DSI2 DSI2

ISET KEBILI

ISET KEBILI
Analyse des besoins et faisabilité
• c'est-à-dire l'expression, le recueil et la formalisation des besoins du 2.3 Modèles de cycles de vie d’un logiciel
demandeur (le client) et de l'ensemble des contraintes, puis l'estimation de la
faisabilité de ces besoins ; a) Modèle de cycle de vie en cascade
Spécifications ou conception générale
• il s'agit de l'élaboration des spécifications de l'architecture générale du
logiciel ;
Conception détaillée
• cette étape consiste à définir précisément chaque sous-ensemble du logiciel ;
Codage (Implémentation ou programmation)
• c'est la traduction dans un langage de programmation des fonctionnalités
définies lors de phases de conception ;
Tests unitaires
• ils permettent de vérifier individuellement que chaque sous-ensemble du
logiciel est implémenté conformément aux spécifications ;
Intégration
• l'objectif est de s'assurer de l'interfaçage des différents éléments (modules) du
logiciel. Elle fait l'objet de tests d'intégration consignés dans un document ;
Qualification (ou recette)
• c'est-à-dire la vérification de la conformité du logiciel aux spécifications
initiales ;
Documentation
• elle vise à produire les informations nécessaires pour l'utilisation du logiciel et

BELHASSEN ROCHDY

BELHASSEN ROCHDY
pour des développements ultérieurs ;
Mise en production
• c'est le déploiement sur site du logiciel ;
Maintenance
• elle comprend toutes les actions correctives (maintenance corrective) et
évolutives (maintenance évolutive) sur le logiciel.
Figure 1.1 : Modèle du cycle de vie en cascade.
La séquence et la présence de chacune de ces activités dans le cycle de vie
dépendent du choix d'un modèle de cycle de vie entre le client et l'équipe de Le modèle de cycle de vie en cascade (cf. figure 1.1) a été mis au point dès 1966,
développement. Le cycle de vie permet de prendre en compte, en plus des aspects puis formalisé aux alentours de 1970.
techniques, l'organisation et les aspects humains.
Dans ce modèle le principe est très simple : chaque phase se termine à une date
précise par la production de certains documents ou logiciels. Les résultats sont
définis sur la base des interactions entre étapes, ils sont soumis à une revue
approfondie et on ne passe à la phase suivante que s'ils sont jugés satisfaisants.

Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été

rajoutée ultérieurement sur la base qu'une étape ne remet en cause que l'étape
précédente, ce qui, dans la pratique, s'avère insuffisant.

L'inconvénient majeur du modèle de cycle de vie en cascade est que la vérification

du bon fonctionnement du système est réalisée trop tardivement : lors de la phase
d'intégration, ou pire, lors de la mise en production.

Chapitre1. Introduction à la modélisation objet 7 Chapitre1. Introduction à la modélisation objet 8

 DSI2 DSI2

ISET KEBILI

ISET KEBILI
b) Modèle de cycle de vie en V L'analyse préliminaire est affinée au cours des premiers cycles. Le modèle utilise des
maquettes exploratoires pour guider la phase de conception du cycle suivant. Le
dernier cycle se termine par un processus de développement classique.

d) Modèle par incrément

Dans les modèles précédents, un logiciel est décomposé en composants développés

séparément et intégrés à la fin du processus.

Dans les modèles par incrément un seul ensemble de composants est développé à
la fois : des incréments viennent s'intégrer à un noyau de logiciel développé au
préalable. Chaque incrément est développé selon l'un des modèles précédents.

Les avantages de ce type de modèle sont les suivants :

• chaque développement est moins complexe ;

Figure 1.2 : Modèle du cycle de vie en V. • les intégrations sont progressives ;
• il est ainsi possible de livrer et de mettre en service chaque incrément ;
Le modèle en V (cf. figure 1.2 ) demeure actuellement le cycle de vie le plus connu et • il permet un meilleur lissage du temps et de l'effort de développement grâce à
certainement le plus utilisé. Il s'agit d'un modèle en cascade dans lequel le la possibilité de recouvrement (parallélisation) des différentes phases.
développement des tests et du logiciel sont effectués de manière synchrone.
Les risques de ce type de modèle sont les suivants :

BELHASSEN ROCHDY

BELHASSEN ROCHDY
Le principe de ce modèle est qu'avec toute décomposition doit être décrite la
recomposition et que toute description d'un composant est accompagnée de tests qui • remettre en cause les incréments précédents ou pire le noyau ;
permettront de s'assurer qu'il correspond à sa description. • ne pas pouvoir intégrer de nouveaux incréments.

Ceci rend explicite la préparation des dernières phases (validation-vérification) par Les noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés
les premières (construction du logiciel), et permet ainsi d'éviter un écueil bien connu globalement, au début du projet. Les incréments doivent être aussi indépendants que
de la spécification du logiciel : énoncer une propriété qu'il est impossible de vérifier possible, fonctionnellement, mais aussi sur le plan du calendrier du développement.
objectivement après la réalisation.
2.4 Méthodes d’analyse et de conception
Cependant, ce modèle souffre toujours du problème de la vérification trop tardive du
bon fonctionnement du système. Les méthodes d'analyse et de conception fournissent une méthodologie et des
notations standards qui aident à concevoir des logiciels de qualité. Il existe
c) Modèle de cycle de vie en spirale différentes manières pour classer ces méthodes, dont :
Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le La distinction entre composition et décomposition :
précédent. Il met l'accent sur l'activité d'analyse des risques : chaque cycle de la
spirale se déroule en quatre phases : • Elle met en opposition d'une part les méthodes ascendantes qui consistent à
construire un logiciel par composition à partir de modules existants et, d'autre
1. Détermination, à partir des résultats des cycles précédents, ou de l'analyse part, les méthodes descendantes qui décomposent récursivement le système
préliminaire des besoins, des objectifs du cycle, des alternatives pour les jusqu'à arriver à des modules programmables simplement ;
atteindre et des contraintes ;
La distinction entre fonctionnelle (dirigée par le traitement) et orientée objet :
2. Analyse des risques, évaluation des alternatives et, éventuellement
maquettage ; • Dans la stratégie fonctionnelle (également qualifiée de structurée) un système
3. Développement et vérification de la solution retenue, un modèle « classique » est vu comme un ensemble hiérarchique d'unités en interaction, ayant
(cascade ou en V) peut être utilisé ici ; chacune une fonction clairement définie. Les fonctions disposent d'un état
4. Revue des résultats et vérification du cycle suivant. local, mais le système a un état partagé, qui est centralisé et accessible par
l'ensemble des fonctions. Les stratégies orientées objet considèrent qu'un

Chapitre1. Introduction à la modélisation objet 9 Chapitre1. Introduction à la modélisation objet 10

 DSI2 DSI2

ISET KEBILI

ISET KEBILI
système est un ensemble d'objets interagissants. Chaque objet dispose d'un évidence les parties qui constituent le système, la finalité et le fonctionnement de
ensemble d'attributs décrivant son état et l'état du système est décrit (de façon chacune, ainsi que les interfaces entre ces diverses parties. Le système ainsi
décentralisée) par l'état de l'ensemble. modélisé n'est pas une simple collection d'éléments indépendants, mais une
organisation structurée de ceux-ci dans une finalité précise.

En résumé, l'architecture du système est dictée par la réponse au problème

3. De la programmation structurée à l’approche orientée (i.e. la fonction du système).
objet
3.2 L’approche orientée objet
3.1 Méthodes fonctionnelles ou structurées
L'approche considère le logiciel comme une collection d'objets dissociés, identifiés et
possédant des caractéristiques. Une caractéristique est soit un attribut (i.e. une
donnée caractérisant l'état de l'objet), soit une entité comportementale de l'objet
(i.e. une fonction). La fonctionnalité du logiciel émerge alors de l'interaction entre les
différents objets qui le constituent. L'une des particularités de cette approche est
qu'elle rapproche les données et leurs traitements associés au sein d'un unique
objet.

Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :

L'identité

BELHASSEN ROCHDY

BELHASSEN ROCHDY
• 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
Figure 1.3 : Représentation graphique d'une approche fonctionnelle. à 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, etc.) ;
Les méthodes fonctionnelles (également qualifiées de méthodes structurées) Les attributs
trouvent leur origine dans les langages procéduraux. Elles mettent en évidence les
fonctions à assurer et proposent une approche hiérarchique descendante et • il s'agit des données caractérisant l'objet. Ce sont des variables stockant des
modulaire. informations sur l'état de l'objet ;
Les méthodes
Ces méthodes utilisent intensivement les raffinements successifs pour produire des
spécifications dont l'essentiel est sous forme de notation graphique en diagrammes
• les méthodes d'un objet caractérisent son comportement, c'est-à-dire
de flots de données. Le plus haut niveau représente l'ensemble du problème (sous
l'ensemble des actions (appelées opérations) que l'objet est à même de
forme d'activité, de données ou de processus, selon la méthode). Chaque niveau est
réaliser. Ces opérations permettent de faire réagir l'objet aux sollicitations
ensuite décomposé en respectant les entrées/sorties du niveau supérieur. La
extérieures (ou d'agir sur les autres objets). De plus, les opérations sont
décomposition se poursuit jusqu'à arriver à des composants maîtrisables (cf.
étroitement liées aux attributs, car leurs actions peuvent dépendre des valeurs
figure 1.3).
des attributs, ou bien les modifier.
L'approche fonctionnelle dissocie le problème de la représentation des données, du
La difficulté de cette modélisation consiste à créer une représentation abstraite, sous
problème du traitement de ces données. Sur la figure 1.3, les données du problème
forme d'objets, d'entités ayant une existence matérielle (chien, voiture, ampoule,
sont représentées sur la gauche. Des flèches transversales matérialisent la
personne…) ou bien virtuelle (client, temps…).
manipulation de ces données par des sous-fonctions. Cet accès peut-être direct
(c'est parfois le cas quand les données sont regroupées dans une base de données),
ou peut être réalisé par le passage de paramètre depuis le programme principal. La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures
logicielles fondées sur les objets du système, plutôt que sur la fonction qu'il est censé
réaliser.
La SADT (Structured Analysis Design Technique) est probablement la méthode
d'analyse fonctionnelle et de gestion de projets la plus connue. Elle permet non
seulement de décrire les tâches du projet et leurs interactions, mais aussi de décrire En résumé, l'architecture du système est dictée par la structure du problème.
le système que le projet vise à étudier, créer ou modifier, en mettant notamment en

Chapitre1. Introduction à la modélisation objet 11 Chapitre1. Introduction à la modélisation objet 12

 DSI2 DSI2

ISET KEBILI

ISET KEBILI
3.3 Approche fonctionnelle vs. approche objet L'encapsulation garantit l'intégrité des données, car elle permet d'interdire, ou de
restreindre, l'accès direct aux attributs des objets.
La différence entre une approche fonctionnelle et une approche objet n'est donc pas
d'ordre logique, mais pratique. c) Héritage, Spécialisation, Généralisation et polymorphisme

L'approche structurée privilégie la fonction comme moyen d'organisation du logiciel. L'héritage est un mécanisme de transmission des caractéristiques d'une classe (ses
Ce n'est pas pour cette raison que l'approche objet est une approche non attributs et méthodes) vers une sous-classe. Une classe peut être spécialisée en
fonctionnelle. En effet, les méthodes d'un objet sont des fonctions. Ce qui différencie d'autres classes, afin d'y ajouter des caractéristiques spécifiques ou d'en adapter
sur le fond l'approche objet de l'approche fonctionnelle, c'est que les fonctions certaines. Plusieurs classes peuvent être généralisées en une classe qui les
obtenues à l'issue de la mise en œuvre de l'une ou l'autre méthode sont distinctes. factorise, afin de regrouper les caractéristiques communes d'un ensemble de
L'approche objet est une approche orientée donnée. classes.

En approche objet, l'évolution des besoins aura le plus souvent tendance à se Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies
présenter comme un changement de l'interaction des objets. S'il faut apporter une de classes. L'héritage peut être simple ou multiple. L'héritage évite la duplication et
modification aux données, seul l'objet incriminé (encapsulant cette donnée) sera encourage la réutilisation.
modifié. Toutes les fonctions à modifier sont bien identifiées : elles se trouvent dans
ce même objet : ce sont ses méthodes. Dans une approche structurée, l'évolution Le polymorphisme représente la faculté d'une méthode à pouvoir s'appliquer à des
des besoins entraîne souvent une dégénérescence, ou une profonde remise en objets de classes différentes. Le polymorphisme augmente la généricité, et donc la
question, car la décomposition des unités de traitement (du programme principal aux qualité, du code.
sous-fonctions) est directement dictée par ces besoins.
d) Agrégation
La technologie objet est la conséquence ultime de la modularisation du logiciel,

BELHASSEN ROCHDY

BELHASSEN ROCHDY
démarche qui vise à maîtriser sa production et son évolution. Mais malgré cette Il s'agit d'une relation entre deux classes, spécifiant que les objets d'une classe sont
continuité logique les langages objet ont apporté en pratique un profond changement des composants de l'autre classe. Une relation d'agrégation permet donc de définir
dans l'art de la programmation : ils impliquent en effet un changement de l'attitude des objets composés d'autres objets. L'agrégation permet donc d'assembler des
mentale du programmeur. objets de base, afin de construire des objets plus complexes.

3.4 Concepts importants de l’approche objet 3.5 Historique la programmation par objets

Dans la section 3.2, nous avons dit que l'approche objet rapproche les données et Les premiers langages de programmation qui ont utilisé des objets sont Simula I
leurs traitements. Mais cette approche ne fait pas que ça, d'autres concepts (1961-64) et Simula 67 (1967), conçus par les informaticiens norvégiens Ole-Johan
importants sont spécifiques à cette approche et participent à la qualité du logiciel. Dahl et Kristan Nygaard. Simula 67 contenait déjà les objets, les classes, l'héritage,
l'encapsulation, etc.
a) Notion de classe
Alan Kay, du PARC de Xerox, avait utilisé Simula dans les années 1960. Il réalisa en
Tout d'abord, introduisons la notion de classe. Une classe est un type de données 1976 Smalltalk qui reste, aux yeux de certains programmeurs, le meilleur langage de
abstrait qui précise des caractéristiques (attributs et méthodes) communes à toute programmation par objets.
une famille d'objets et qui permet de créer (instancier) des objets possédant ces
caractéristiques. Les autres concepts importants qu'il nous faut maintenant introduire Bjarne Stroustrup a mis au point C++, une extension du langage C permettant la
sont l'encapsulation, l'héritage et l'agrégation. programmation orientée objet, aux Bell Labs d'AT&T en 1982. C++ deviendra le
langage le plus utilisé par les programmeurs professionnels. Il arrivera à maturité en
b) Encapsulation 1986, sa standardisation ANSI / ISO date de 1997.

L'encapsulation consiste à masquer les détails d'implémentation d'un objet, en Java est lancé par Sun en 1995. Comme il présente plus de sécurité que C++, il
définissant une interface. L'interface est la vue externe d'un objet, elle définit les deviendra le langage favori de certains programmeurs professionnels.
services accessibles (offerts) aux utilisateurs de l'objet.

L'encapsulation facilite l'évolution d'une application, car elle stabilise l'utilisation des
objets : on peut modifier l'implémentation des attributs d'un objet sans modifier son
interface, et donc la façon dont l'objet est utilisé.

Chapitre1. Introduction à la modélisation objet 13 Chapitre1. Introduction à la modélisation objet 14

 DSI2 DSI2

ISET KEBILI

ISET KEBILI
4. UML commune qui fédérerait leurs apports respectifs (on les surnomme depuis « the
Amigos »). UML (Unified Modeling Language) est né de cet effort de convergence.
L'adjectif unified est là pour marquer qu'UML unifie, et donc remplace.
4.1. Introduction
En fait, et comme son nom l'indique, UML n'a pas l'ambition d'être exactement une
La description de la programmation par objets a fait ressortir l'étendue du travail méthode : c'est un langage.
conceptuel nécessaire : définition des classes, de leurs relations, des attributs et
méthodes, des interfaces, etc. L'unification a progressé par étapes. En 1995, Booch et Rumbaugh (et quelques
autres) se sont mis d'accord pour construire une méthode unifiée, Unified Method
Pour programmer une application, il ne convient pas de se lancer tête baissée dans 0.8 ; en 1996, Jacobson les a rejoints pour produire UML 0.9 (notez le remplacement
l'écriture du code : il faut d'abord organiser ses idées, les documenter, puis organiser du mot méthode par le mot langage, plus modeste). Les acteurs les plus importants
la réalisation en définissant les modules et étapes de la réalisation. C'est cette dans le monde du logiciel s'associent alors à l'effort (IBM, Microsoft, Oracle, DEC,
démarche antérieure à l'écriture que l'on appelle modélisation ; son produit est HP, Rational, Unisys, etc.) et UML 1.0 est soumis à l'OMG(5). L'OMG adopte en
un modèle. novembre 1997 UML 1.1 comme langage de modélisation des systèmes
d'information à objets. La version d'UML en cours en 2008 est UML 2.1.1 et les
Les spécifications fournies par la maîtrise d'ouvrage en programmation impérative travaux d'amélioration se poursuivent.
étaient souvent floues : les articulations conceptuelles (structures de données,
algorithmes de traitement) s'exprimant dans le vocabulaire de l'informatique, le UML est donc non seulement un outil intéressant, mais une norme qui s'impose en
modèle devait souvent être élaboré par celle-ci. L'approche objet permet en principe technologie à objets et à laquelle se sont rangés tous les grands acteurs du
à la maîtrise d'ouvrage de s'exprimer de façon précise selon un vocabulaire qui, tout domaine, acteurs qui ont d'ailleurs contribué à son élaboration.
en transcrivant les besoins du métier, pourra être immédiatement compris par les
informaticiens. En principe seulement, car la modélisation demande aux maîtrises
d'ouvrage une compétence et un professionnalisme qui ne sont pas aujourd'hui
4.3. UML en œuvre

BELHASSEN ROCHDY

BELHASSEN ROCHDY
répandus.
UML n'est pas une méthode (i.e. une description normative des étapes de la
modélisation) : ses auteurs ont en effet estimé qu'il n'était pas opportun de définir
4.2. Histoire des modélisations par objets une méthode en raison de la diversité des cas particuliers. Ils ont préféré se borner à
définir un langage graphique qui permet de représenter et de communiquer les
Les méthodes utilisées dans les années 1980 pour organiser la programmation divers aspects d'un système d'information. Aux graphiques sont bien sûr associés
impérative (notamment Merise) étaient fondées sur la modélisation séparée des des textes qui expliquent leur contenu. UML est donc un métalangage, car il fournit
données et des traitements. Lorsque la programmation par objets prend de les éléments permettant de construire le modèle qui, lui, sera le langage du projet.
l'importance au début des années 1990, la nécessité d'une méthode qui lui soit
adaptée devient évidente. Plus de cinquante méthodes apparaissent entre 1990 et Il est impossible de donner une représentation graphique complète d'un logiciel, ou
1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE, de tout autre système complexe, de même qu'il est impossible de représenter
etc.), mais aucune ne parvient à s'imposer. En 1994, le consensus se fait autour de entièrement une statue (à trois dimensions) par des photographies (à deux
trois méthodes : dimensions). Mais il est possible de donner sur un tel système des vues partielles,
analogues chacune à une photographie d'une statue, et dont la conjonction donnera
• OMT de James Rumbaugh (General Electric) fournit une représentation une idée utilisable en pratique sans risque d'erreur grave.
graphique des aspects statique, dynamique et fonctionnel d'un système ;
• OOD de Grady Booch, définie pour le Department of Defense, introduit le UML 2.0 comporte ainsi treize types de diagrammes représentant autant
concept de paquetage (package) ; de vues distinctes pour représenter des concepts particuliers du système
• OOSE d'Ivar Jacobson (Ericsson) fonde l'analyse sur la description des d'information. Ils se répartissent en deux grands groupes :
besoins des utilisateurs (cas d'utilisation, ou use cases).
Diagrammes structurels ou diagrammes statiques (UML Structure)
Chaque méthode avait ses avantages et ses partisans. Le nombre de méthodes en
compétition s'était réduit, mais le risque d'un éclatement subsistait : la profession • diagramme de classes (Class diagram)
pouvait se diviser entre ces trois méthodes, créant autant de continents intellectuels • diagramme d'objets (Object diagram)
qui auraient du mal à communiquer. • diagramme de composants (Component diagram)
• diagramme de déploiement (Deployment diagram)
Événement considérable et presque miraculeux, les trois gourous qui régnaient
chacun sur l'une des trois méthodes se mirent d'accord pour définir une méthode • diagramme de paquetages (Package diagram)

Chapitre1. Introduction à la modélisation objet 15 Chapitre1. Introduction à la modélisation objet 16

 DSI2 DSI2

ISET KEBILI

ISET KEBILI
• diagramme de structures composites (Composite structure diagram) e) Diagramme d'activités

Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) Le diagramme d'activités n'est autre que la transcription dans UML de la
représentation du processus telle qu'elle a été élaborée lors du travail qui a préparé
• diagramme de cas d'utilisation (Use case diagram) la modélisation : il montre l'enchaînement des activités qui concourent au processus.
• diagramme d'activités (Activity diagram)
• diagramme d'états-transitions (State machine diagram) f) Diagramme de séquence et de communication
• Diagrammes d'interaction (Interaction diagram)
o diagramme de séquence (Sequence diagram)
Le diagramme de séquence représente la succession chronologique des opérations
réalisées par un acteur. Il indique les objets que l'acteur va manipuler et les
o diagramme de communication (Communication diagram)
opérations qui font passer d'un objet à l'autre. On peut représenter les mêmes
o diagramme global d'interaction (Interaction overview diagram) opérations par un diagramme de communication , graphe dont les nœuds sont des
o diagramme de temps (Timing diagram) objets et les arcs (numérotés selon la chronologie) les échanges entre objets. En fait,
diagramme de séquence et diagramme de communication sont deux vues
Ces diagrammes, d'une utilité variable selon les cas, ne sont pas nécessairement différentes, mais logiquement équivalentes (on peut construire l'une à partir de
tous produits à l'occasion d'une modélisation. Les plus utiles pour la maîtrise l'autre) d'une même chronologie. Ce sont des diagrammes d'interaction.
d'ouvrage sont les diagrammes d'activités, de cas d'utilisation, de classes, d'objets,
de séquence et d'états-transitions. Les diagrammes de composants, de déploiement 4.4. Comment présenter un modèle UML ?
et de communication sont surtout utiles pour la maîtrise d'œuvre à qui ils permettent
de formaliser les contraintes de la réalisation et la solution technique. La présentation d'un modèle UML se compose de plusieurs documents écrits en
langage courant et d'un document formalisé : elle ne doit pas se limiter au seul
a) Diagramme de cas d'utilisation document formalisé, car celui-ci est pratiquement incompréhensible si on le présente

BELHASSEN ROCHDY

BELHASSEN ROCHDY
seul. Un expert en UML sera capable dans certains cas de reconstituer les intentions
Le diagramme de cas d'utilisation représente la structure des grandes fonctionnalités initiales en lisant le modèle, mais pas toujours ; et les experts en UML sont rares.
nécessaires aux utilisateurs du système. C'est le premier diagramme du modèle Voici la liste des documents qui paraissent nécessaires :
UML, celui où s'assure la relation entre l'utilisateur et les objets que le système met
en œuvre. Présentation stratégique :

b) Diagramme de classes • elle décrit pourquoi l'entreprise a voulu se doter de l'outil considéré, les buts
qu'elle cherche à atteindre, le calendrier de réalisation prévu, etc. ;
Le diagramme de classes est généralement considéré comme le plus important dans Présentation des processus de travail par lesquels la stratégie entend se
un développement orienté objet. Il représente l'architecture conceptuelle du réaliser :
système : il décrit les classes que le système utilise, ainsi que leurs liens, que ceux-ci
représentent un emboîtage conceptuel (héritage) ou une relation organique • pour permettre au lecteur de voir comment l'application va fonctionner en
(agrégation). pratique, elle doit être illustrée par une esquisse des écrans qui seront affichés
devant les utilisateurs de terrain ;
c) Diagramme d'objets Explication des choix qui ont guidé la modélisation formelle :
Le diagramme d'objets permet d'éclairer un diagramme de classes en l'illustrant par •il s'agit de synthétiser, sous les yeux du lecteur, les discussions qui ont
des exemples. Il est, par exemple, utilisé pour vérifier l'adéquation d'un diagramme présidé à ces choix ;
de classes à différents cas possibles. Modèle formel :
d. Diagramme d'états-transitions • c'est le document le plus épais et le plus difficile à lire. Il est préférable de le
présenter sur l'Intranet de l'entreprise. En effet, les diagrammes peuvent être
Le diagramme d'états-transitions représente la façon dont évoluent (i.e. cycle de vie) alors équipés de liens hypertextes permettant l'ouverture de diagrammes plus
les objets appartenant à une même classe. La modélisation du cycle de vie est détaillés ou de commentaires.
essentielle pour représenter et mettre en forme la dynamique du système.
On doit présenter en premier le diagramme de cas d'utilisation qui montre
l'enchaînement des cas d'utilisation au sein du processus, enchaînement

Chapitre1. Introduction à la modélisation objet 17 Chapitre1. Introduction à la modélisation objet 18

 DSI2

ISET KEBILI
immédiatement compréhensible ; puis le diagramme d'activités, qui montre le
contenu de chaque cas d'utilisation ; puis le diagramme de séquence, qui montre
l'enchaînement chronologique des opérations à l'intérieur de chaque cas d'utilisation.
Enfin, le diagramme de classes, qui est le plus précis conceptuellement, mais aussi
le plus difficile à lire, car il présente chacune des classes et leurs relations
(agrégation, héritage, association, etc.).

BELHASSEN ROCHDY
1-4-1. Introduction

Chapitre1. Introduction à la modélisation objet 19