PARTIE 1 : PRINCIPES DU GENIE LOGICIEL

- Quest-ce que le Gnie logiciel ?

- Etat des connaissances en Gnie logiciel

- Dmarche du dveloppement et cycle de vie du logiciel

- Qualit du logiciel

- Sret de fonctionnement
1 Quest-ce que le Gnie logiciel ?
Gnie logiciel ou Ingnierie du logiciel :
Thories , mthodes , outils et ressources humaines permettant de construire des systmes logiciels et den
assurer lvolution .
Programmation vs. Gnie logiciel
- Programmation = Activit personnelle
- Gnie logiciel = Activit dquipe structure organise autour dun projet
Quelques faits sur lindustrie du logiciel
- Lconomie de toutes les nations dveloppes dpend du logiciel ( part du PNB trs importante )
- Le cot du logiciel domine maintenant celui du matriel
- Le logiciel cote plus maintenir qu dvelopper
- Le cot de production du logiciel est trs variable et difficile valuer
- Le logiciel a une importance croissante dans les systmes critiques ( centrales nuclaires , systmes de
transport : avion , train , auto , donnes bancaires ,etc ) => il doit tre fiable et sr
- Les utilisateurs sont de plus en plus exigeants : certains critres de qualit doivent tre satisfaits :
fiabilit , efficacit , possibilit dvolution , ergonomie , etc
- La concurrence est norme dans chaque secteur de lindustrie du logiciel .
2 Etat des connaissances en Gnie logiciel ( Suite )
Facteurs positifs :
Economie en pleine volution : 1985 : 140 Mrd $ - 1995 : 450 Mrd $ -2000 : 900 Mrd $
Nombreuses collaborations acadmie industrie ( projets de recherche mixtes )
Concurrence trs importante pour la domination du march du logiciel ( Microsoft , Sun Microsystems ,
Oracle , Borland , Netscape , etc )
Effet dentranement dans la comptition pour les petits diteurs de logiciel
Facteurs ngatifs :
Monopole conomique
Plusieurs faillites et dbcles conomiques
Enseignements inadapts dans beaucoup duniversits
Pas encore de vritable dmarche scientifique dans la production de logiciel ( thories et mthodologies
jeunes et en cours de dveloppement )
Evolution vers une science de lingnieur
2 Etat des connaissances en Gnie logiciel
Discipline informatique jeune et en pleine volution . ( a dbut dans les annes 60 )
Beaucoup de techniques informelles ( pas de consensus sur ce que doit faire un systme logiciel )
Remarque : Dautres disciplines de lingnieur telles que llectricit , la mcanique possdent des mthodes
prcises pour dcrire leurs besoins . En informatique , les mthodes mathmatiques commencent seulement
se dvelopper .
Consquence : Beaucoup dincertitudes associes au processus de dveloppement :
Evolution des cots et de la confiance en lissue du dveloppement
Mthodes non structures Mthodes structures







La 1re version est trs loigne du produit final Est-on sr dtre sur la bonne voie ?

tude
Confiance
Ralisation
Exploitation
Cots
tude
Confiance
Ralisation
Exploitation
Cots
6

3 Dmarche de dveloppement logiciel
Dfinitions :
Une dmarche de dveloppement repose sur :
Un formalisme ( exemple : orientation objet )
Une mthode ( Merise , SADT , FUSION , OMT , RUP / UML , )
Un processus et un cycle de vie
Notion de processus de dveloppement :
Un processus de dveloppement reprsente un ensemble dtapes ou activits successives permettant la
production dun systme logiciel dans les dlais ( et le budget ) fixs par le client et rpondant aux besoins
des utilisateurs .
tapes dun processus de dveloppement
- Spcification : tablissement du cahier des charges et des contraintes du systme ( capture des besoins )
- Analyse : Dtermination des lments constituant le systme
- Conception : Production dun modle du systme final tel quil doit fonctionner
- Implmentation : ralisation du systme ( codage des composants et assemblage )
- Test : Vrification de ladquation entre les fonctionnalits du systme et la description des besoins
- Installation : livraison du systme au client et vrification de son fonctionnement .
- Maintenance : rparation des fautes dans le systme au fur et mesure de leur dcouverte .
3 Dmarche de dveloppement logiciel ( Suite 1 )
Dfinitions :
Modle de cycle de vie :
Un modle de cycle de vie dbute par une ide et se termine par un logiciel .
Il permet de grer lexcution dun processus de dveloppement sous forme dune seule itration ou par
itrations successives dans le cadre dun projet jusqu la satisfaction des besoins du client .
Dans le cas de plusieurs itrations , chaque itration reprsente un processus ou mini-projet complet
( spcification + analyse + Conception + Implmentation + Test ) .
Les principaux modles de cycle de vie

A - Modle en Chute deau ( Waterfall )

Principe : Chaque activit est relative lentiret
du cahier des charges ( cycle de vie une seule itration )

Inconvnients :
- Modle structure linaire bien adapt certaines disciplines
( exemple : gnie civil ) mais pas au gnie logiciel .
- Modle trop rigide : une activit ne peut commencer que si lactivit
prcdente est compltement termine
- Pas de possibilit de travail en parallle et validation finale tardive
3 Dmarche de dveloppement logiciel ( Suite 2 )
B - Modle en V

Principe : Similaire au modle en chute deau mais avec une
validation rtrograde et plus longue

Inconvnients :
- Modle structure linaire et validation tardive comme le
modle en cascade ( waterfall )
- Mise en uvre et installation tardives entranant des erreurs
trs coteuses .
C - Modle par prototypage jetable

Principe : On effectue une ou plusieurs itrations (prototypes)
sous forme de processus distincts uniquement pour aboutir une
spcification exacte du systme ( concertation avec le client )

Avantages :
- On arrive satisfaire le client aprs avoir test diffrents
prototypes du systme
Inconvnients :
- Approche trs coteuse en terme de dure de dveloppement
( elle ncessite des ressources humaines importantes )
Spcification shmatique
Codage du prototype
Evaluation du prototype
Spcification du systme
3 Dmarche de dveloppement logiciel ( Suite 3 )
D - Modle incrmental ou itratif

Principe :
- Aprs lanalyse des besoins ( spcification ) , on
effectue plusieurs cycles de dveloppements
successifs ( itrations )
- Chaque cycle conduit une version utilisable du
produit et traite un petit nombre de besoins

Avantages :
- A chaque itration , la complexit du systme
diminue
- Des implmentations de parties du systme sont
disponibles trs rapidement . On peut disposer alors
dinformations utiles sur le comportement du
systme ( early feedback ) et son adquation aux
besoins .
- Ce modle permet le travail en parallle des quipes

3 Dmarche de dveloppement logiciel ( Suite 4 )
E - Modle en spirale

Principe :
- On effectue plusieurs cycles de dveloppement
manire itrative incluant chacun une spcification
( analyse ou ranalyse des besoins )
- Chaque cycle conduit une version utilisable du
produit et peut faire appel un modle de
dveloppement diffrent : modle en chute deau ,
modle de prototypage jetable , etc

Avantages :
- Ce modle est plus flexible que le modle
incrmental avec la possibilit de changer de
stratgie chaque itration ( sous-modle )
- La spcification est constamment remise en cause
( rexamine )
- Ce modle permet le travail en parallle des quipes
comme dans le cas du modle incrmental .

Dfinition et mesure de la qualit atteindre

La qualit est dfinie de manire gnrale par laptitude dun produit ou dun service
satisfaire les besoins des utilisateurs . Cette dfinition sapplique aux systmes
informatiques.


La difficult principale rside dans la capacit exprimer ces besoins. On constate
trop souvent que lutilisateur nest pas satisfait a posteriori ! Certes le cycle de vie en
spirale, ou des approches par maquettage rduisent ces risques, mais, il est fondamental
de permettre lutilisateur (et/ou au client) dexprimer ces exigences; ce sur quoi il va
juger la qualit du systme.



La qualit est un processus qui dpasse la notion de logiciel. On peut lappliquer tout
processus industriel pour peu quon souhaite lamliorer. Amliorer quoi ? le produit, le
service, la faon de dvelopper le produit, les dlais, les cots, etc. Peu importe, ce qui
compte cest la volont de mesurer, observer, contrler, apprendre pour amliorer quelque
chose.
4 -Qualit du logiciel et Sret de fonctionnement
Les premires tudes systmatique de la qualit des logiciels datent de 1977. Depuis des
modles de qualits se sont dvelopps, mais on retrouve toujours 3 niveaux :



Les facteurs qualit : expression des exigences (point de vue externe, client)



Les critres qualit : caractristiques du produit (point de vue interne, technique)



Les mtriques : ce qui permet de mesurer un critre
1. Conformit : satisfaire aux spcifications - il faut quelles existent !

2. Robustesse : ne pas tomber en panne (tolrance aux pannes, recouvrement
derreurs, etc.)

3. Efficacit : optimisation des ressources (cpu, E/S, mmoire, etc.)

4. Scurit : surveiller, contrler, interdire les accs

5. Maniabilit : minimiser leffort dapprentissage de lutilisation du systme

6. Maintenabilit : minimiser leffort pour localiser et corriger les fautes

7. Testabilit : minimiser, automatiser leffort de test

8. Adaptabilit : minimiser leffort dvolution du systme

9. Portabilit : minimiser leffort pour changer de plate-forme

10. Rutilisabilit : optimiser la conception pour faciliter la rutilisation de parties du
systme

11. Interoprabilit: garantir louverture du systme dautres systmes Ils doivent tre
apprcis par le client pour dfinir les points quil juge capitaux ou
secondaires.
Les facteurs de qualit du logiciel sont les suivants :
Les techniques mises en uvre couvrent les critres qualit. On y retrouve les
bons principes de programmation comme

la modularit,
lauto-descriptivit (les commentaires),
lindpendance matrielle logiciel,
la concision, etc.


Mais aussi des bons principes dorganisation comme




lutilisation de standards
la traabilit. Cette dernire est la capacit suivre dans le temps lvolution
dun produit et de ses plans et de pouvoir associer les lments de la solutions aux
lments du problme.
Pour mesurer la qualit du logiciel, des mtriques sont associs aux critres eux
mme rattachs aux facteurs. Ces mtriques peuvent caractriser les qualits :

du produit
du processus de dveloppement
du service rendu

Elles peuvent se faire par des mesures objectives (comptages) ou par des enqutes
dopinion ( pensez-vous que les rsultats soient prsents clairement ? - de 0 5
). Les exemples des mtriques concernant le logiciel sont :

nombre de lignes de code, de fonctions, doprateur par fonction, (concision)
nombre de lignes de commentaires, (auto-descriptivit)
nombre des modules, nombre de liens avec dautres modules - couplage
(modularit)
nombre de chemins possibles dans une fonction (simplicit)
nombre de donnes en entres, en sortie, frquence...(simplicit)
Facteur de qualit : aptitude du logiciel Note
Adaptabilit : minimiser l'effort ncessaire pour le modifier par suite
d'volution des spcifications
Conformit : contenir un minimum d'erreurs, satisfaire aux
spcifications et remplir ses missions dans les situations
oprationnelles dfinies.
Efficacit : se limiter l'utilisation des ressources strictement
ncessaires l'accomplissement de ses fonctions.
Maintenabilit : minimiser leffort pour localiser et corriger les fautes.
Maniabilit : minimiser l'effort ncessaire pour l'apprentissage, la mise
en uvre des entres et l'exploitation des sorties.
Rutilisabilit : tre partiellement ou totalement utilis dans une autre
application.
Scurit : surveiller, recenser, protger et contrler les accs au code et
aux donnes ou fichiers.
Robustesse : accomplir sans dfaillance l'ensemble des fonctionnalits
spcifies, dans un environnement oprationnel de rfrence et pour une
dure d'utilisation donne.
Interoprabilit : s'interconnecter d'autres systmes.
Portabilit : minimiser leffort pour se faire transporter dans un autre
environnement matriel et/ou logiciel.
Testabilit : faciliter les procdures de test permettant de s'assurer de
l'adquation des fonctionnalits
En 1994, plus de 50 mthodes OO
Fusion, Shlaer-Mellor, ROOM, Classe-Relation, Wirfs-Brock, Coad-Yourdon,
MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis, COMMA, HOOD,
Ooram, DOORS...
Les mta-modles se ressemblent de plus en plus
( 1 mta-modle = modle de structure dune mthode )
Les notations graphiques sont toutes diffrentes
Lindustrie a besoin de standards
1 - Evolution des Mthodes de Conception Orientes Objet
Naissance dUML :
1993-1994: Les 2 mthodes ( Booch93 et OMT-2 ) deviennent leaders sur le march,
elles sont de plus en plus proches
Octobre 1994
J. Rumbaugh (OMT) rejoint G. Booch chez Rational
Annonce de lunification des deux mthodes
Octobre 1995: Mthode Unifie v0.8
Fin 1995: le fondateur d Objectory, Ivar Jacoson, rejoint son tour Rational
Janvier 97 : Soumission lOMG de la version UML 1.0
OMG: Object Management Group
Organisme but non lucratif fond en 1989
Plus de 700 entreprises y adhrent
Connu pour la norme CORBA
Septembre 97 : UML 1.1
2 Historique dUML
UML: Prendre le meilleur de chacune des 3 mthodes ( OOSE (Jacobson): Use Cases , OMT
(Rumbaugh): Analyse et Booch: Conception, Architecture )
UML a t standardise par lOMG ds Janvier 1997 et soutenu depuis par le march ( Microsoft, HP,
Oracle, IBM) et par les universits .

UML ne dfinit pas de processus standard de dveloppement
Ce nest le but ni d UML, ni de l OMG
Les processus de dveloppement de Booch, OMT, et OOSE restent applicables
Rational propose pour UML Objectory et RUP ( Rational Unified Process )

RUP = Processus itratif et incrmental
Segmentation du travail d aprs les cas d utilisation, et l tude des risques
Les premires itrations sont des prototypes
Dveloppement incrmental
Possibilit de parallliser les itrations
3 Le Processus de dveloppement dans UML
UML est une notation, pas une mthode
UML est un langage de modlisation objet : il convient toutes les mthodes
objets et convient tous les langages objets ( C++ , Java , Eiffel , VB , etc )

UML n'est pas propritaire, elle est accessible toute entreprise qui peut librement en faire usage. En
fonction du type d'application, des comptences ou des contraintes imposes l'quipe de dveloppement,
le processus d'analyse peut-tre diffrent et l'accent peut tre mis sur tel ou tel autre modle.

Certains fabricants offrent des ateliers, supportant UML, qui permettent l'laboration des diagrammes
et assurent la cohrence entre les modles. Des gnrateurs de code Java, VB ou C++ permettent de
passer aisment de l'analyse au codage. Certains intgrent mme des outils de "reverse engineering" pour
maintenir la cohrence entre le code et la conception.

Parmi les offres du march les principaux sont:

RATIONAL avec Rational Rose 2001 www.rational.com
SOFTEAM avec Objecteering UML Modeler 5.1 www.softeam.com
MICROSOFT avec Visual Modeler pour VB www.microsoft.com
etc

Chaque atelier supportant UML propose un processus d'analyse. Un processus peut tre assimil une
mthode de dveloppement logiciel par le fait qu'il propose une dmarche et une chronologie dans
l'analyse. Par exemple Rational utilise RUP (Rational Unified Process). D'autres entreprises proposent un
processus de dveloppement propritaire bas sur UML, comme Communications & Systems avec
UML/CS SI Development Process.

Diagramme UML
Classe Objet Use case Composant Deploiement Etats-transitions Squence Collaboration Activit
Modles statiques Modle d'usage Modles dynamiques Modles architecturaux

DEMARCHE GENERALE

La dmarche propose est parfois appele "Approche dirige par les cas". Elle consiste en:

Vue des cas d'utilisation
1. Identification des acteurs qui agissent sur le systme tudier
2. Dfinition et description des cas d'utilisations qui montreront les interactions entre les
acteurs actifs externes et le systme vu comme une bote noire,
3. Construction de diagrammes de collaboration entre les acteurs et le systme afin de
visualiser les changes d'information,
4. Pour chaque cas d'utilisation seront dcrits les principaux scnarios qui visualisent la
chronologie des changes entre les acteurs et le systme,
Vue logique
5. A chaque scnario sera associ un diagramme de squence qui mettra en avant
l'aspect temporel des interactions entre les objets de l'application qui participent au
scnario,
6. En parallle avec les diagrammes prcdent, seront construits les diagrammes de
classes qui visualisent l'architecture du logiciel, la hirarchie et les associations entre
classes
Diagrammes de
collaboration
3
Cas d'utilisation
2
Diagrammes de squence
5
Diagrammes de
classes
6
Scnarios
4

Acteur
s
1
Dmarche dirige
par les cas
Une autre dmarche est possible, c'est "L'approche dirige par les classes" o sont d'abord identifies les
classes de l'application puis les cas d'utilisation
4 Mise en uvre dune itration dans le processus de
dveloppement UML
Itration = Spcification + Analyse + Conception + Implmentation + Test
4.1 - La Phase de spcification
Cette phase sert la capture des besoins du systme raliser ; elle permet de :
- Prendre connaissance du cahier des charges
- Dfinir le cadre du systme
- Dlimiter la porte du projet
Tches effectuer :
- tablir le dictionnaire
- laborer le modle des concepts saillants
- Identifier les acteurs et la description de leurs besoins
- Identifier et Regrouper les cas dutilisation en packages
a - Le Dictionnaire
4.1 - La Phase de spcification
a - Le Dictionnaire ( Suite 1 )
: Exemple => Gestion dune bibliothque publique
4.1 - La Phase de spcification
a - Le Dictionnaire ( Suite 2 )
Exemple de Dictionnaire des Actions
Le modle des concepts saillants est a reprsentation graphique laide de classes des concepts importants
du domaine informatiser et des liens entre ces concepts .
Ce diagramme est compos de rectangles reprsentants les concepts fondamentaux et importants ( objets )
du systme relis par des segments de droite ( liens entre ces concepts ) .
Le diagramme rsultant du modle des concepts saillants est un premier brouillon qui permettra dvoluer
aprs plusieurs itrations vers le diagramme de classes .
4.1 - La Phase de spcification
b - Le Modle des Concepts Saillants
La prochaine tape est didentifier le plus clairement possible les limites ( ou frontires ) du systme .
On dcouvre ces limites en dfinissant les Acteurs et les Cas dutilisation du systme .
Notion dActeur :
Un Acteur est une entit externe au systme qui est amene interagir avec lui .
Un Acteur peut tre une personne , un autre systme , un priphrique dordinateur , une base de donnes , un
rseau , etc Chaque acteur dfinit un rle prcis .
Comment dterminer les acteurs dun systme ?
En trouvant une rponse aux questions suivantes : Qui utilise , installe dmarre , maintient ou arrte le
systme ? Qui obtient ou entre linformation dans le systme ? Le systme interagit-il avec dautres systmes ?
4.1 - La Phase de spcification
c Identifier les Acteurs et la description de leurs besoins
4.1 - La Phase de spcification
d Identifier les Cas dUtilisation fondamentaux du systme ( Use Cases )
4.1 - La Phase de spcification
d Identifier les Cas dUtilisation ( Suite 1 )
Relation entre les Cas dUtilisation dun systme
Notation des Cas dutilisation ( diagramme )
4.1 - La Phase de spcification
d Identifier les Cas dUtilisation ( Suite 2 )
4.1 - La Phase de spcification
e - Dtailler chaque Cas dUtilisation
Dans lexemple
de la bibliothque :
4.1 - La Phase de spcification
e - Dtailler chaque Cas dUtilisation
Dans lexemple
de la bibliothque :
4.1 - La Phase de spcification
e - Dtailler chaque Cas dUtilisation ( Suite 1 )
Suite de lexemple sur la bibliothque ( description des scnarios ) :
4.1 - La Phase de spcification
e - Dtailler chaque Cas dUtilisation ( Suite 1 )
Suite de lexemple sur la bibliothque ( description des scnarios ) :
4.1 - La Phase de spcification
e - Dtailler chaque Cas dUtilisation ( Suite 1 )
Suite de lexemple sur la bibliothque ( description des scnarios ) :
4.1 - La Phase de spcification
e - Dtailler chaque Cas dUtilisation ( Suite 2 )
Suite de lexemple sur la bibliothque :
Besoin dinterface graphique pour le Cas dutilisation : Oui

Contraintes non fonctionnelles :

- Population du quartier = 35 000 habitants avec environ 12 000 inscrits la bibliothque
- Le Systme devra tre accessible tous les jours de 13 H 22 H .
- Besoins en quipement : 1 Serveur + 8 terminaux
Terminal n 1 : Prt des documents
Terminal n 2 : Retour des documents
Terminal n 3 : Inscription des nouveaux clients
Terminal n 4,5 et 6 : Consultation des usagers
Terminal n 7 et 8 : Bibliothcaire
Certains terminaux devront tre munis dun lecteur optique permettant de lire le code barre
des documents et des cartes des clients .
Niveau de priorit retenu :
1 Inscription des nouveaux clients
2 Comptoir de prt
3 Comptoir de retour
4 Terminaux de consultation des index
5 Terminaux pour ladministration ( bibliothcaire )
4.1 - La Phase de spcification
e - Dtailler chaque Cas dUtilisation ( Suite 2 )
Suite de lexemple sur la bibliothque :
Besoin dinterface graphique pour le Cas dutilisation : Oui

Contraintes non fonctionnelles :

- Population du quartier = 35 000 habitants avec environ 12 000 inscrits la bibliothque
- Le Systme devra tre accessible tous les jours de 13 H 22 H .
- Besoins en quipement : 1 Serveur + 8 terminaux
Terminal n 1 : Prt des documents
Terminal n 2 : Retour des documents
Terminal n 3 : Inscription des nouveaux clients
Terminal n 4,5 et 6 : Consultation des usagers
Terminal n 7 et 8 : Bibliothcaire
Certains terminaux devront tre munis dun lecteur optique permettant de lire le code barre
des documents et des cartes des clients .
Niveau de priorit retenu :
1 Inscription des nouveaux clients
2 Comptoir de prt
3 Comptoir de retour
4 Terminaux de consultation des index
5 Terminaux pour ladministration ( bibliothcaire )
4.1 - La Phase de spcification
e - Dtailler chaque Cas dUtilisation ( Suite 2 )
Suite de lexemple sur la bibliothque :
Besoin dinterface graphique pour le Cas dutilisation : Oui

Contraintes non fonctionnelles :

- Population du quartier = 35 000 habitants avec environ 12 000 inscrits la bibliothque
- Le Systme devra tre accessible tous les jours de 13 H 22 H .
- Besoins en quipement : 1 Serveur + 8 terminaux
Terminal n 1 : Prt des documents
Terminal n 2 : Retour des documents
Terminal n 3 : Inscription des nouveaux clients
Terminal n 4,5 et 6 : Consultation des usagers
Terminal n 7 et 8 : Bibliothcaire
Certains terminaux devront tre munis dun lecteur optique permettant de lire le code barre
des documents et des cartes des clients .
Niveau de priorit retenu :
1 Inscription des nouveaux clients
2 Comptoir de prt
3 Comptoir de retour
4 Terminaux de consultation des index
5 Terminaux pour ladministration ( bibliothcaire )
4.1 - La Phase de spcification
e - Dtailler chaque Cas dUtilisation ( Suite 3 )
Suite de lexemple sur la bibliothque :
Temps de rponse du systme : Temps maximal acceptable : 10 secondes
Temps normal : 5 secondes
Temps idal : <= 3 secondes
Normes gnrales du systme :
4.1 - La Phase de spcification
f - Regrouper les Cas dutilisation en Packages
On regroupe les Cas dUtilisation en Packages en sinspirant des acteurs et des rles .
Suite de lexemple sur la bibliothque :
4.2 - La Phase dlaboration
Cette phase se concentre sur lAnalyse et la Conception .

Elle permet pour chaque cas dutilisation du systme de :

- Capturer les requis ( description de ce que le systme doit faire ( le Quoi ? )
= > Analyse
- Identifier et dtailler les classes et leur interaction ( associations entre classes )
=> Conception du comportement statique
- Identifier les messages changs entre les objets ( instances des classes ) et leur synchronisation
+ Traduire ces messages en mthodes de classe
=> Conception du comportement dynamique
- Regrouper les classes en Packages ( composants assurant chacun une activit principale dans le cas
dutilisation)


Les diagrammes produire dans la phase dlaboration sont :



1 Notion dObjet et de Classe
4.2 - La Phase dlaboration
On va rappeler ici les principaux concepts objets, car en effet, ces notions sont trs importantes pour la
comprhension des diffrents modles dUML et leurs implmentations, plus exactement les diagrammes
qui vont dcrire les concepts de UML (qui est avant tout un langage graphique).
Un objet est une entit hermtique qui contient la fois des donnes et des traitements (les donnes
sont appeles attributs et les traitements oprations ou mthodes).

Une classe est une abstraction dobjets (ne pas confondre avec labstraction des concepts objets).
Cest dire une structure qui rassemble des proprits communes une collection dobjets.

On dit quun objet est une instance de classe, cest dire une valeur particulire de la classe (notion
dinstanciation). Par exemple une instance de la classe Voiture est : Renault Laguna .
NomDeLaClasse

attributs

oprations ( )
Reprsentation graphique d'une classe :

Le premier compartiment contient le nom de la classe
Le second compartiment contient la liste des attributs
Le troisime compartiment contient la liste des oprations

A- Encapsulation et abstraction

On dit que les informations (qui sont des donnes) et les comportements (qui sont les traitements
ou encore mthodes ou oprations) dun objet sont encapsuls. En effet celles-ci sont lintrieur
dune entit
Les informations (donnes) et les comportements (traitements ou oprations) de lobjet
Personne sont encapsuls cest dire regroups dans une entit qui est lobjet Personne.
2 PARADIGMES OBJET
Intrt de lencapsulation : On peut protger le contenu des classes dune manipulation maladroite
et ou mal intentionne.
Un objet est caractris par ses donnes et ses traitements mais il est aussi caractris par une partie
publique, une partie prive et une partie implmentation, cest ce que lon appelle labstraction.

On dit que les donnes ont un accs priv cest dire que seuls les traitements de cet objet peuvent, le
cas chant, modifier ces donnes (attention les donnes peuvent tre aussi publiques mais cela na aucun
intrt). Les traitements ont un accs priv ou public. Si les traitements sont publics, ceux-ci
appartiennent lobjet et peuvent tre appels et modifier les donnes. Si les traitements sont privs, alors
seuls des traitements publics appartenant lobjet pourront dclencher lexcution des traitements privs
( condition quils figurent dans le codage). Les traitements privs sont appels mthodes
dimplmentation
Nom = Dupont
Age
ChangerNom(UnNom)
Les attributs et les mthodes sont
publics. Les attributs peuvent tre
modifis directement sans passer par
les mthodes.
Nom = DUPONT
Age
NomEnMajuscule
ChangerNom(UnNom)
Les attributs sont privs. Les
attributs ne peuvent tre modifis
que par la mthode publique (ici
ChangerNom) qui fait appel
une mthode dimplmentation (ici
NomEnMajuscule)
Nom = Dupont
ChangerNom(Dupont)
Parties
prives
B Hritage

On parle dhritage lorsque lon a affaire des objets et des classes et de gnralisation /
spcialisation uniquement pour des classes.

On distingue deux types dhritage :
lhritage simple
lhritage multiple

On va factoriser les attributs et les mthodes communs plusieurs classes dans une classe
principale : on parle de gnralisation. Les classes drives deviennent des sous-classes : on parle de
spcialisation.
Nom
Prnom
Adresse
Age
ChangerNom
ChangerAdresse
ChangerAge
Personne
Statut
Matire
ChangerStatut
ChangerMatire
Professeur
Filire
ChangerFilire
Etudiant
Gnralisation
Spcialisation
Montant
CompteBancaire
ChquierEmis
Dbiter(1)
CompteChque
CompteEpargne
Intrts
Dbiter(2)
CompteChqueRmunr
Intrts de lhritage : Lhritage permet la rutilisation du code. En effet lorsque lon va instancier une
classe spcialise, le code des attributs et des mthodes de la classe hrite ne seront pas implments
nouveau. Lautre avantage de lhritage et quil permet lorganisation hirarchique des classes. Cest
dire quil rend plus ais lexploration et la maintenance dune bibliothque de classe pour une quipe de
dveloppement.
C Polymorphisme

Le polymorphisme est la possibilit pour un mme message de dclencher des traitements diffrents,
suivant les objets auxquels il est adress. Le mcanisme de polymorphisme permet donc de donner le
mme nom des traitements diffrents
n immatriculation
Voiture
Porsche 911
AcclrerAFond
Renault 21
AcclrerAFond
Intrt du polymorphisme : Le polymorphisme permet de donner le mme nom des traitements
diffrents ou encore, permet le choix dynamique dun traitement en fonction de lobjet auquel il est
appliqu (en effet le choix de la mthode polymorphe excuter est dtermin lexcution du
programme. Cest pour cela quon dit quelle est dynamique, par oppos statique qui est dtermin lors
de la compilation).
Prsentation gnrale d'une classe
carburant
capacite
Voiture
On considre l exemple d une voiture caractrise par:
la capacit du rservoir
la quantit du carburant
Il est vident que le champ capacit est une caractristique commune toutes
les voitures. Il devra donc tre dclar statique.
En plus les utilisateurs ne doivent pas avoir la possibilit de modifier cette
valeur de capacit.
En revanche, il serait utile de leurs donner la possibilit de lire cette valeur.
Il est aussi vident que les utilisateurs de cette classe doivent avoir la
possibilit de lire et de modifier la valeur du champ carburant.

Accessibilit : Exemple
Accessibilit /
visibilit: Exemple
carburant
capacite
Voiture
Il faudra galement s assurer que l utilisateur ne puisse pas donner une valeur au
champ carburant qui dpasse la capacit de la voiture.
Nous pourrions dfinir deux mthodes capacite() et carburant() permettant de renvoyer
respectivement les valeurs de capacite et carburant.
Ce genre de mthodes s appellent Accesseurs .
Gnralement, le nom de ces mthodes commencent par get : on nommera alors les
mthodes capacite() et carburant() resp. getCapacite() et getCarburant().
Nous pourrions galement dfinir une mthode qui permet de modifier la valeur de
carburant nomme setCarburant(int c).
Ce genre de mthodes s appellent mutateur . Le nom de ces mthodes
commencent gnralement par set.

getCapacite()
getCarburant()
setCarburant(int c)
Voiture
- carburant : int
- capacit :int
+ Voiture()
+ setCarburant(int c) : void
+ getCarburant() :int
+ getCapacite() :int
class Voiture{
private int carburant ;
private static int capacite=80 ;
Voiture(){
carburant=0 ;
}
public setCarburant(int c){
if ((c<capacite)&&(c>0))
carburant=c ;
}
public int getCarburant(){
return carburant;
}
public int getCapacite(){
return capacite;
}
}


class Parc{
public static void main(String[] args){
Voiture v1=new Voiture(30);
v1.carburant=30; // interdit
v1.setCarburant(30) ; // solution
int car=v1.carburant ; // interdit
int car=v1.getCarburant() ; Solution
v1.capacite=100 ; // interdit de modifier
System.out.println(v1.capacite) ;interdit
System.out.println(v1.getCapacite()); Sol.
}
}
Accessibilit / visibilit: Exemple
dimplmentation en java
B Le Diagramme de Classe
4.2 - La Phase dlaboration
Dfinition

Cest un diagramme qui montre une collection dlments statiques (classes), leur contenu et les
relations entre eux.
Exemple :









Figure IV-7 : Exemple de diagramme de classe (Atelier Rational Rose)


Chaque diagramme de classe est form des entits suivantes :

Voiture Bus
Vhicule Moteur
Constructeur
les classes : Les classes se dsignent par un nom (1
re
partie), contiennent des attributs (2
me
partie) et
des mthodes associes (3
me
partie) :


les relations interclasses : Elles sont appeles associations. On a dfini diffrents
types dassociations :
association simple (binaire ou n-aire)
agrgation, composition
hritage (spcialisation, gnralisation)
les noms de rle : ceux sont les noms des relations interclasses ;

les multiplicits : associes aux relations, les multiplicits permettent de dterminer le nombre
doccurrence dune classe par rapport une autre classe en utilisant le nom de rle ;
La notation gnrale adopte est : min . . max
1 obligatoire
0..1 optionnel
0..* ou * quelconque (cas gnral)
1..* au moins 1
1..5, 10 entre 1 et 5, ou 10
Association Simple binaire une association binaire exprime une relation smantique bi-
directionnelle entre deux classes, le sens dune association peut tre prcis par une
flche.Exemples :
B Le Diagramme de Classe : Association n-aire ( Suite )
4.2 - La Phase dlaboration
..*
..*
1..*
B Le Diagramme de Classe : les Attributs dassociation ( Suite )
4.2 - La Phase dlaboration
*
B Le Diagramme de Classe : Classe dassociation ( Suite )
4.2 - La Phase dlaboration
B Le Diagramme de Classe : Compositions et Agrgations ( Suite )
4.2 - La Phase dlaboration
Agrgation et composition :
Les relations dagrgation et de composition sont 2 types particuliers dassociations permettant
dexprimer lappartenance dune partie un tout .
B Le Diagramme de Classe : Compositions et Agrgations ( Suite )
4.2 - La Phase dlaboration
B Le Diagramme de Classe : Compositions et Agrgations ( Suite )
4.2 - La Phase dlaboration
Autres Notations
B Le Diagramme de Classe : Compositions et Agrgations ( Suite )
4.2 - La Phase dlaboration
Autres Exemples
B Le Diagramme de Classe : La gnralisation / spcialisation des concepts
4.2 - La Phase dlaboration
Il arrive quune classe ( concept ) soit essentiellement identique une autre , les seules
diffrences rsidant dans un certain nombre de caractristiques supplmentaires ( des attributs ,
des mthodes ou des associations avec dautres concepts ) . On dit alors que le 1er concept est
une spcialisation du second et que le second est une gnralisation du 1er .
Gnralisation = relation ente un lment plus gnral et un lment plus
spcifique qui est entirement conforme avec le premier lment, et qui ajoute de
l information supplmentaire
Spcialisation = mcanisme par lequel des lments plus spcifiques incorporent
la structure et le comportement dlments plus gnraux (notion dhritage).
B Le Diagramme de Classe : lhritage
4.2 - La Phase dlaboration
Les spcialisations dun concept hritent de toutes les caractristiques de ce concept .
Cet hritage concerne les attributs , les mthodes ( oprations ) et les associations ventuelles
avec dautres concepts .
Exemple :
Selon ce modle , les concepts
Paiement cash , Paiement par carte
et Paiement par chque possdent
Lattribut Montant , et chacun deux
Est associ au concept Vente par
la relation Rgle .
Principe de substitution ( Liskov - 1987 ) :
Si 2 concepts sont lis par une relation de spcialisation , alors ils doivent satisfaire la rgle suivante :
Toute instance du concept spcialis doit pouvoir jouer le rle dune instance du concept gnral
Cette rgle peut tre vrifie en formant la phrase : < concept spcialis > est un < concept gnral > ?

Cas de notre exemple : Un paiement cash , par carte ou par chque est toujours un paiement .
B Le Diagramme de Classe : la Classification multiple
4.2 - La Phase dlaboration
Un concept gnral peut souvent tre spcialis de plusieurs faons diffrentes .
Exemple :
Dans un hpital , chaque mdecin
ou infirmier est aussi un homme
ou bien une femme .
Il est donc possible quune instance
dun concept appartienne
simultanment plusieurs
spcialisations de ce concept .

Sur le diagramme de classe ,
on associe aux relations de
gnralisation des discriminants
qui prcisent quelles combinaisons
de spcialisation sont autorises .

Rgles :
Une instance dun concept gnral ne peut tre simultanment une instance de 2 concepts spcialiss
associs au mme discriminant ( une personne peut tre un infirmier ou un mdecin ou ni lun ni lautre )
Si la contrainte Mandatory accompagne un discriminant , alors toute instance du concept gnral doit
obligatoirement tre une instance dun et dun seul concept spcialis associ ce discriminant .
( une personne est obligatoirement soit un homme , soit une femme ) .
B Le Diagramme de Classe : lhritage multiple
4.2 - La Phase dlaboration
Un mme concept spcialis peut tre associ plusieurs concepts gnraux et hriter du
comportement de chacun deux .
Avi on
Pl aneur Avi onAMoteur MoyenCourri er
LongCourri er
A320
motori sati on
motori sati on
rayon d'acti on rayon d'acti on
Discriminant
Gnralisation
Spcialisation
Hritage multiple
Agrgation ou association ?
Agrgation ou gnralisation ?
Agrgation ou
association :
si 2 objets sont troitement associs
par une relation de type compos-
composant, cest une agrgation

si 2 objets sont habituellement
indpendants, bien que parfois
associs, cest une association.

Agrgation ou
gnralisation :

Dites vous ou
ou dites-vous et ?
Exemples :
Un moteur est diesel ou essence
(gnralisation)
Un moteur est compos de
cylindres et de pistons
(agrgation)
B Le Diagramme de Classe : les Contraintes ( Suite )
4.2 - La Phase dlaboration
Contrainte = Relation smantique entre lments de modle qui spcifie des
conditions ou propositions devant tre respectes pour que le modle soit valide
Notation : { contrainte }
Contraintes Pr-Dfinies
B Le Diagramme de Classe : les Contraintes ( Suite )
4.2 - La Phase dlaboration
B Le Diagramme de Classe : les Contraintes ( Suite )
4.2 - La Phase dlaboration
B Le Diagramme de Classe : les Associations drives ( Suite )
4.2 - La Phase dlaboration
B Le Diagramme de Classe : les Interfaces
4.2 - La Phase dlaboration
Une interface dcrit de manire abstraite le comportement dune classe , dun composant , dun
sous-systme , dun paquetage ou de toute autre classificateur .
Exemple :
Classe avec implmentation
des mthodes
Classe gnrique sans implmentation
des mthodes
1re Notation
2me Notation
B Le Diagramme de Classe : les Interfaces ( suite )
4.2 - La Phase dlaboration
La classe VILLE implmente linterface REPRESENTABLE ( elle comporte le code associ aux
mthodes qui sont dcrites dans linterface ) .

La classe AFFICHE utilise linterface REPRESENTABLE ( dclenche lexcution de ses mthodes )
pour une instance de la classe VILLE ou de toute autre classe implmentant linterface .
B Le Diagramme de Classe : les Interfaces ( suite )
4.2 - La Phase dlaboration
C Le Diagramme dobjets
4.2 - La Phase dlaboration
Les diagrammes dobjets, ou diagrammes dinstances, montrent des objets et des
liens. Comme les diagrammes de classes, les diagrammes dobjets reprsentent la
structure statique.

Les diagrammes dobjets sutilisent principalement pour montrer un contexte, par
exemple avant ou aprs une interaction, mais galement pour faciliter la
comprhension des structures complexes, comme les structures rcursives.
Lobjet ObjetA nest pas classifi
Lobjet : ObjetB est instance de la classe ClasseB
Lobjet : ClasseC est une instance anonyme de la classe
ClasseC
C Le Diagramme dobjets ( Suite 1 ) : Exemple dobjet composite
4.2 - La Phase dlaboration
Classes
Objets
C Le Diagramme dobjets ( Suite 2 ) : Exemple dassociations multiples
4.2 - La Phase dlaboration
Classes
Objets
C Le Diagramme dobjets ( Suite 3 ) : Exemple dassociation rflexive
4.2 - La Phase dlaboration
Classe
Objets
D Laxe dynamique
4.2 - La Phase dlaboration
Le modle dynamique reprsente les squences dvnements, dtats et de
ractions qui peuvent survenir dans un systme.
Il est intimement li au modle statique ( diagrammes de classe et dobjet )
et au modle fonctionnel ( diagramme des cas dutilisation ) et dcrit
les aspects de contrle dun systme en prenant compte le temps,
le squencement des oprations et les interactions entre objets

3 diagrammes fondamentaux sont utiliss dans le modle dynamique :
Diagrammes de Squence et de collaboration
Diagramme Etats-Transitions
Diagramme dactivit
E Le Diagramme de Squence
4.2 - La Phase dlaboration
Dfinition :
Le diagramme de squence dcrit le droulement dune interaction entre les objets
dans le cadre de la ralisation dun scnario de cas dutilisation en mettant en
vidence la dimension temporelle de cette interaction .

Il y a autant de diagrammes de squence quil y a de scnarios
Un Scnario montre une squence particulire dinteractions entre objets, dans un
seul contexte dexcution du systme
Un scnario peut tre vu comme une des instances possibles dun Use Case.
On y fait intervenir des objets, des messages et des vnements

objet1 : Classe objet2 : Classe
Objets de type Classe
Messages
E Le Diagramme de Squence ( suite 1 )
4.2 - La Phase dlaboration
Lenvoi dun message dun objet un autre
se dnote par une flche pleine reliant les
lignes de vie de ces deux objets .

La forme lmentaire de ltiquette dun
message est la suivante :

[ garde ] message ( paramtres )

o

Garde est une condition devant tre satisfaite
afin de pouvoir envoyer le message ( si cette
condition est toujours vraie , elle peut tre omise)

Message est lidentificateur du message envoy

Paramtres est une liste ( vntuellement vide ) de
paramtres , spars par de virgules )


E Le Diagramme de Squence ( suite 2 ) : Interation avec le diagramme de classe
4.2 - La Phase dlaboration
Personne
bouton d'appel s'al l ume( )
ouverture des portes tage( )
bouton d'tage s'al l ume( )
Ascenseur
appel de l 'ascenceur tage( )
choi x de l 'tage( )
0..*
0..*
transporte
0..*
0..*
Myri am :
Personne
: Ascenseur Ol i vi er :
Personne
1: appel de l 'ascenceur tage (RdC)
2: buton d'appel s'al l ume ( )
3: ouverture des portes tage (RdC)
4: choi x de l 'tage (3)
5: bouton d'tage s'al l ume (3)
6: appel de l 'ascenceur tage (2)
7: buton d'appel s'al l ume ( )
8: ouverture des portes tage (2)
10: ouverture des portes tage (3) 9: ouverture des portes tage (3)
< 2 secondes
Exemple de
Lascenceur
E Le Diagramme de Squence ( suite 3 )
4.2 - La Phase dlaboration
Les diagrammes de squence distinguent deux grandes catgories denvoi de message :
- Les envois synchrones pour lesquels lmetteur est bloqu et attend que lappel ait fini de traiter le message
- Les envois asynchrones pour lesquels lmetteur nest pas bloqu et peut continuer son excution.

Les diagrammes de squence permettent de reprsenter les priodes dactivit des objets.
Une priode dactivit correspond au temps pendant lequel un objet effectue une action,
soit directement, soit par lintermdiaire dun autre objet qui lui sert de sous-traitant.

Les priodes dactivit se reprsentent par des bandes rectangulaires places sur les
lignes de vie. Le dbut et la fin dune bande correspondent respectivement au dbut et
la fin dune priode dactivit.
Message synchrone

Retour implicite
Message asynchrone

Retour explicite
E Le Diagramme de Squence ( suite 4 ) : Rgles de reprsentations
4.2 - La Phase dlaboration
E Le Diagramme de Squence ( suite 5 ) : Rgles de reprsentations
4.2 - La Phase dlaboration
Diagramme de
squence avec
un objet
contrleur chef
dorchestre
Diagramme de
squence avec
dlgation
E Le Diagramme de Squence ( suite 6 ) : Diagramme de squence viter
4.2 - La Phase dlaboration
Diagramme
de squence
viter
Intrt de diagramme de squence

Les diagrammes de squences prsentent les intrts suivants :
permettre de mieux comprendre le fonctionnement du systme; modliser la vie
des objets dans le temps et leur chronologie ;
reprsenter les interactions, les communications (par messages) entre objets :
messages asynchrones (traits horizontaux avec une demi-flche, messages
synchrones (traits horizontaux avec une flche entire) ;
dtre trs utiles dans la description des cas derreur et des cas limites dutilisation
du systme;
dtre une aide prcieuse pour documenter les mthodes des classes
F Le Diagramme de Collaboration
4.2 - La Phase dlaboration
Dfinition : Les diagrammes de collaboration montrent des interactions entre objets, en insistant plus
particulirement sur la structure spatiale statique qui permet la mise en collaboration dun groupe dobjets.

Les diagrammes de collaboration expriment la fois le contexte dun groupe dobjets (au travers des objets et
des liens) et linteraction entre ces objets (par la reprsentation de lenvoi de messages).

Les diagrammes de collaboration sont une extension des diagrammes dobjet.
On reprsente principalement dans les diagrammes de collaboration :
les structures statiques : les objets;
les liens entre objets (comme dans les diagrammes de classes);
les interactions qui sont une suite de messages (structure dynamique) changs (petites
flches) que lon va numroter permettant ainsi de les lire dune manire chronologique ;
F Le Diagramme de Collaboration ( Suite 1 ) : Rgles de construction
4.2 - La Phase dlaboration
Strotype
Acteur
Itrtion sur
un message
F Le Diagramme de Collaboration ( Suite 3 ) : Scnario de Use Case
4.2 - La Phase dlaboration
USE CASE : Retrait en espces

Le guichetier saisit le numro de compte du client.
Lapplication valide le compte auprs du systme central.
Lapplication demande le type dopration au guichetier.
Le guichetier slectionne un retrait de 200 DH.
Le systme guichet interroge le systme central pour
sassurer que le compte est suffisamment approvisionn.
Le systme central effectue le dbit du compte.
Le systme notifie au guichetier quil peut dlivrer le
montant demand.
F Le Diagramme de Collaboration ( Suite 4 ) : Scnario de Use Case
4.2 - La Phase dlaboration
F Le Diagramme de Collaboration ( Suite 5 ) : Scnario de Use Case
4.2 - La Phase dlaboration
F Le Diagramme de Collaboration
4.2 - La Phase dlaboration
Dfinition : Les diagrammes de collaboration montrent des interactions entre objets, en insistant plus
particulirement sur la structure spatiale statique qui permet la mise en collaboration dun groupe dobjets.

Les diagrammes de collaboration expriment la fois le contexte dun groupe dobjets (au travers des objets et
des liens) et linteraction entre ces objets (par la reprsentation de lenvoi de messages).

Les diagrammes de collaboration sont une extension des diagrammes dobjet.
intrt de diagramme de collaboration
Les intrts des diagrammes de collaborations sont :
de faire coexister les descriptions dynamiques et statiques. Ce qui donne une vision
globale du systme ;
de pouvoir dcrire des mthodes ou la ralisation de cas dutilisation (par exemple une
suite de messages va permettre de visualiser la ralisation dune opration) et dobserver
leurs effets externes ;
de reprsenter un moyen indispensable de vrifier la cohrence globale dune analyse
objet ;
de visualiser le comportement particulier dun systme travers un acteur.
Permettent de comprendre et de dcrire le comportement des objets et leurs
interactions.
F Le Diagramme de Collaboration
4.2 - La Phase dlaboration

Origine

Deux types de reprsentations :
Dynamique entre objets avec les deux diagrammes dinteraction :
diagramme de squence
diagramme de collaboration
Dynamique interne un objet avec le diagramme dtats-transitions.


Dfinition

un diagramme dtat dcrit lvolution au cours du temps dun objet (instance dune classe) en
rponse aux interactions avec dautres objets ou acteurs.

Il dcrit le cycle de vie des objets d'une seule classe. On tablit un diagramme d'tat pour chaque
classe qui a un comportement dynamique significatif, ce qui signifie que toutes les classes nen ont pas
besoin
Un diagramme d'tat est un graphe orient comportant des tats (nuds) connects par des
des transitions (arc orients).

.



E Le Diagramme dtat Transition
4.2 - La Phase dlaboration
Exemple
tat :
un tat spcifie la rponse de l'objet aux vnements d'entre. Il est stable. Il peut tre caractris par un
ensemble de valeurs d'attributs et de liens d'un objet. Chaque objet est un moment donn dans un tat
particulier :

-Etat Initial : tat d'une instance juste aprs sa cration (un seul tat initial)
- Etat Intermdiaire : un objet est toujours dans un tat donn pour un certain temps
-Etat Final : tat d'une instance juste avant sa destruction (un automate infini peut ne pas avoir d'tat
final).
E Le Diagramme dtat Transition
Formalisme :
Etat
Intermdiaire
Etat Initial
Etat Final
Transition :

Relation entre deux tats indiquant quun objet dans le premier tat va passer dans le
deuxime quand un vnement particulier apparatra, et que certaines conditions
seront satisfaites.

vnement:

un vnement est un stimulus pouvant transporter des informations (sous forme de
paramtres). Un vnement peut tre mis par un objet du systme ou par un objet
externe au systme. Il peut galement provenir de linterface du systme, par exemple
un clic de souris.

Condition :

une condition est une expression boolenne, attache un vnement, qui doit tre
vraie pour le dclenchement de la transition. Elle est indique entre crochets la suite
du nom de l'vnement
E Le Diagramme dtat Transition
Transition - Condition
Anniversaire (ge) [ge=18]
Mineur
Majeur
Naissance
Dcs
tat initial tat final
vnement
condition
Etat transition
Action :

une action est une opration instantane (atomique) dclenche par une transition Elle est associe
un vnement. La notation d'une action sur une transition est prcde dune barre oblique ("/").


En attente

Menu
visible
Bouton droit activ / afficher menu droulant
Bouton droit non activ / effacer menu
Curseur boug / item de menu en surbrillance
E Le Diagramme dtat Transition

Chauffage
l'arrt

Chauffage
en marche

Refroidissement [temp < temp rfrence]
Rchauffement [temp > temp rfrence]

/DmarrerChauffage()
/ArrterChauffage()
E Le Diagramme dtat Transition
Activit :
une activit est une opration qui dure un certain temps. Elle est associe un tat. Elle peut tre continue ou finie
(se termine delle mme). Notation : "Do : activit".
Compte
crditeur
Compte dbiteur
Do: CalculAgio
Retrait [solde - retrait < 0]
Dpt [solde + dpt > 0]
En entre :
Laction est excute chaque fois que lon entre dans ltat.
Notation : entry : action
En sortie :
Laction est excute chaque fois que lon quitte ltat.
Notation : exit : action

Action interne :
Laction ou opration excute dans un tat seulement si un vnement survient.
Notation : On Event : action
Notation complte et ordonnancement :






Ordre temporel dexcution :
En entre :
Action sur la transition dentre (action 1)
Action dentre dans ltat (action 2)
Dmarrage de lactivit

Dans ltat :
Interruption de lactivit
Excution de laction interne (action 3)
Reprise de lactivit

En sortie :
Arrt de lactivit
Action de sortie de ltat (action 4)
Action sur la transition de sortie (action 5)
E Le Diagramme dtat Transition
Etat x

Entry / action 2
Do : activit
On Event: even/ action 3
Exit / action 4

Evt [condition]

/ action 1

Evt [condition]

/ action 5


Arret
Marche
Entry: TournerMoteur()
Appui bouton tage [N!=tage courant]

/DmarrerMoteur()
Exemple : Fonctionnement d'un rveil affichage digital
22 :15 :35
En fonctionnement normal, la montre affiche les heures, les minutes et les secondes qui
dfilent.
Une pression sur le bouton mode slectionne le chiffre des heures qui se met clignoter. A
ce moment une pression sur le bouton avance incrmente le compteur dune heure.
Une nouvelle pression sur le bouton mode slectionne le chiffre des minutes qui se met
clignoter. A ce moment une pression sur le bouton avance incrmente le compteur dune
minute.
Une nouvelle pression sur le bouton mode revient laffichage normal.
Dessiner le diagramme tat-transition de cette montre.
Bouton mode
Bouton avance
Affichage Heure
Modification Heure
Entry:ClognoterHeure()
Modification Minute
Entry:ClognoterMinute()
Appui Bouton Mode/ChangerHeure()
Appui Bouton Mode/ChangerMinute()
Appui Bouton Mode/AfficherHeure()
Appui Bouton Avance/AvancerHeure()
Appui Bouton Avance/AvancerMinute()
E Le Diagramme dtat Transition
Gnralisation d'tats:

Dans le cas d'un comportement dynamique complexe, les diagrammes d'tats sur un niveau
deviennent rapidement illisibles
Pour viter ce problme, il est ncessaire de structurer les diagrammes d'tats en :
- Super-tats : tats gnraux
- Sous-tats : hritent des caractristiques des tats gnraux

A B
C
B A
C
E2
E2
E1
E2
E1
Rapport inf.
Rapport sup.
Premire

Deuxime

Troisime
Rapport inf.

Point mort
Marche
arrire
Passer P.M.
Passer M.Avant
Rapport sup.
Passer P.M.
Passer M.Arrire
Passer P.M. Passer P.M.
Objectif : rduire la complexit
Rapport inf.
Rapport sup.

Premire

Deuxime

Troisime
Rapport
inf.

Point mort
Marche
arrire
Passer P.M.
Passer M.Arrire
Passer M.Avant
Marche avant
Rapport sup.
Passer P.M.
E Le Diagramme dtat Transition
Notion d'historique :

- Par dfaut, un automate na pas de mmoire
- la notation H offre un mcanisme pour mmoriser le dernier sous tat dans lequel
l'automate se trouve avant une transition afin de pouvoir retrouver cet tat si ncessaire.
- Exemple : Cycle de lavage d'un lave-vaisselle


Rinage

lavage

Schage

Attente
H
Porte Ferme
Porte Ouverte
E Le Diagramme dtat Transition
Cration et Destruction
La cration d'un objet se reprsente par l'envoi d'un vnement de cration la classe de l'objet
Au Sol
Au Vol
Atterir
Dcoler
Crer (immatriculation)
Supprimer
La destruction est effective lorsque le flot de contrle de l'automate atteint un tat final
non embot
Intrts des diagrammes dtats-transitions

Les intrts de la modlisation par les diagrammes dtats-transitions sont de :

Donner vie aux objets (sils sy prtent) reprsents jusqu prsent de manire
statique comme des occurrences de classes quon peut gnraliser par les classes ;

Mieux visualiser le systme en diminuant sa complexit (parce que lon va dtailler);

Tenir compte des tats lors de limplmentation (en effet la traduction des tats peut
tre faite simplement, la plupart des langages le permettent);

Reprsenter un aspect du modle dynamique, lautre tant illustr les diagrammes de
collaborations et les diagrammes de squences ;

Pouvoir dcrire les changements dtats des automates
E Le Diagramme dtat Transition
Cas
dutilisation
Scnarios
Diagrammes
dinteraction
Diagrammes
dtats-transition
Diagramme
de classes
Exemple
Convocation(Date)
Evaluation
Entrevue
Prparation
Entrevue
Bilan
Convocation(Date)
AttributionPoste
RefusAffectation
Chauffage
l'arrt

Chauffage
en marche

Refroidissement [temp < temp rfrence]

Rchauffement [temp > temp rfrence]

C Transposition dun modle UML dans un contexte relationnel
4.3 - La Phase dimplmentation ( codage )
Classe avec attributs et mthodes
La gnration de code SQL tient compte du comportement statique ( attributs ) mais
pas du comportement dynamique ( mthodes )
Create Table RECTANGLE (
Id_Rectangle Integer Primary Key ,
Largeur Number ,
Hauteur Number )
Comment identifier les instances ?
Ajouter une cl primaire artificielle si
une cl naturelle nexiste pas
Que faire avec les mthodes ?
Plusieurs solutions suivants les besoins

Solution 1: Crer de nouveaux attributs calculs et les mmoriser ( surface , primtre,)
Solution 2 : Utiliser des Vues ( SELECT ) sans mmorisation pour dterminer la surface , le primtre , etc
Solution 3 : Utiliser des mises jour ( UPDATE ) pour les autres mthodes ( exemple : modifier la valeur
de la largeur et de la longueur avec la mthode Agrandir )
C Transposition dun modle UML dans un contexte relationnel ( Suite )
Classe avec attributs et mthodes
Create Table RECTANGLE (
Id_Rectangle Integer Primary Key , Largeur Number , Hauteur Number ,
Surface Number , Perimetre Number )
Solution 1: Crer de nouveaux attributs calculs et les mmoriser ( surface , primtre,)
Create vue V_Rectangle As
Select Id_Rectangle , Largeur , Hauteur ,
Largeur * Hauteur Surface ,
2 * ( Largeur + Hauteur ) Perimetre )
From Rectangle
Solution 2: Utiliser des Vues sans mmorisation pour dterminer la surface , le primtre , etc
Update Rectangle
Set Largeur = 2 * Largeur , Hauteur = 2 * Hauteur
Where Id_Rectangle =
Solution 3 : Utiliser des mises jour pour les autres mthodes
C Transposition dun modle UML dans un contexte relationnel ( Suite )
Association binaire gnrale
Objectif : Mmoriser lassociation dans une base de donnes

La solution dpend de lassociation r ( des multiplicits maxA et maxB )
C Transposition dun modle UML dans un contexte relationnel ( Suite )
Associations binaires hirarchiques
Rgion
Code_Rgion
Rgion
Ville
Nom_Ville
Population
1
1..*
Create Table Region (CodeRegion varchar(4) not null primary key,
Region varchar(30),.)

Create Table Ville (NomVille varchar(20) not null primary key,
CodeRegion varchar(4) References Region (CodeRegion),
Population int,)
Personne
conjoint
conjointe
mari a
0..4
0..1
Create table personne(Id-personne int not null primary key,
nom varchar(20),datenaissance date,
id_personne_conjoint references personne (id_personne,)
C Transposition dun modle UML dans un contexte relationnel ( Suite )
Associations binaires multivalues
Create Table Ville (NomVille varchar(20) not null primary key, ,Population int,)
Create table personne(Id-personne int not null primary key, nom varchar(20), Prenom
varchar(20), datenaissance date, )
Personne
Id_Personne
Nom
Ville
Nom_Ville
Population
0..*
0..*
Depuis
jusqua
Travailler
Create table travailler (id_personne int not null reffences personne (id_personne),
nomville varchar(20) refferences ville(nomville),
depuis date, jesqua date, primary key (id_personne,nomville))
C Transposition dun modle UML dans un contexte relationnel ( Suite )
Associations multivalues
Personne
Ami_de
0..*
0..*
Create table personne(Id-personne int not null primary key,
nom varchar(20), Prenom varchar(20),
datenaissance date, )
P1
P2
Create table ami_de ( id_personne_P1 int not null refferences personne (id_personne) ,
id_personne_P2 int not null refferences personne (id_personne),
primary key (id_personne_P1, id_personne_P2))
C Transposition dun modle UML dans un contexte relationnel ( Suite )
Associations d'hritage
A
A1
B
B1
B2
C
C1
C2
Cas1 : les attributs de spcialisation sont en nombre limit dans B et C
Create tableA ( id_A int not null primary key,
A1 varchar(30),
B1 varchar(30), B2 varchar(30),
C1 varchar(30), C2 varchar(30))
Cas2 : l'hritage est associ une contrainte de couverture


Create tableB ( id_A int not null primary key,
A1 varchar(30),
B1 varchar(30),
B2 varchar(30))



Create tableC ( id_A int not null primary key,
A1 varchar(30),
C1 varchar(30),
C2 varchar(30))

Cas3 : l'hritage n'est pas associ une contrainte de couverture (totalit)
et les attributs de spcialisation sont nombreux dans B et C


Create TableA (id_A int not null primary key,
A1 varchar(30))


Create tableB ( id_A int not null primary key references tableA(id_A),
B1 varchar(30),
B2 varchar(30))


Create tableC (id_A int not null primary key references tableA(id_A),
C1 varchar(30),
C2 varchar(30))