Cours UML

Chapitre 1 - Introduction
au langage UML
La justification historique de la modélisation objet
La complexité du logiciel
Ses origines
Selon Grady Booch, la complexité est une caractéristique

inhérente au logiciel et elle provient de quatre éléments :
la complexité des problèmes ;
la difficulté à contrôler le processus de développement ;
la flexibilité dans la programmation ;
le passage du monde continu au monde discret .
La complexité des problèmes
Les logiciels doivent parfois traiter des éléments
complexes (par exemple, le pilote automatique d'un avion
de ligne) auxquels viennent s'ajouter des exigences comme
la facilité d'emploi, les performances ...
Ces contraintes forment un

ensemble de besoins que
l'utilisateur a du mal à exprimer
à un concepteur de logiciels qui
ne connaît pas nécessairement
le domaine d'activité de
l'utilisateur.
Ce dialogue s'effectue aux
travers de documents parfois
volumineux et sujets à
interprétations.
Cette complexité est encore accrue par l'évolution du
dialogue entre le concepteur qui appréhende de mieux
en mieux le domaine et l'utilisateur qui saisit mieux les
possibilités de l'informatique et exprime mieux ses
besoins.
La difficulté à contrôler les processus de développement
Les logiciels doivent parfois traiter (en interne) des

éléments complexes tout en conservant (en externe)
une relative simplicité d'utilisation. Cet objectif peut être
atteint en utilisant, par exemple, des interface
utilisateurs graphiques et intuitives.
Ce traitement interne, toujours plus complexe, auquel vient

s'ajouter un souci de simplification dans sa présentation,
entraîne une augmentation du volume de codage des outils
logiciels.
Le processus de développement de tels outils logiciels ne peut
plus être appréhendé (en un temps raisonnable) par une seule
personne et doit faire l'objet d'un travail d'équipe.
La complexité organisationnelle vient s'ajouter à la
complexité du logiciel à développer.
La flexibilité dans la programmation
Des industries comme le bâtiment peuvent utiliser les

services d'autres industries comme la métallurgie pour
construire des édifices car toutes sont tenues de respecter
des normes.
Un industriel comme Eiffage peut construire un pont mixte

en utilisant des poutres d'acier produites par un autre
industriel comme sa filiale Effel simplement en spécifiant
le type normalisé de poutre dont il a besoin (une poutre
d'un type donnée est construite d'une certaine manière et
possède des caractéristiques mécaniques particulières).
L'industrie du logiciel possède moins de normes, les

concepteurs sont alors tentés de créer leurs propres
briques de base pour s'assurer qu'elles répondent
parfaitement à leur besoins : le développement logiciel en
devient donc d'autant plus laborieux.
Le passage du monde continu au monde discret
La modélisation du réel, qui est

régie par des lois physiques
continues, s'appuie sur des
éléments discrets possédant un
nombre fini d'états.
En météorologie, l’atmosphère
est modélisée par un ensemble
de cubes où la température et la
pression sont considérées
comme homogènes.
Cette discrétisation introduit une erreur artificielle qui doit

être gérée par le logiciel (par exemple un dépassement de
capacité ne doit pas introduire un comportement anormal du
modèle).
L'état du modèle discret est la combinaison des états des

éléments qui composent ce modèle, le programmeur doit donc
gérer une combinatoire importante qui amène un modèle avec
un grand nombre d'états.
La gestion progressive de la complexité

Premiers programmes en langage machine
Les premiers programmes, écrits en langage machine,

dépendaient fortement de l'architecture des ordinateurs
utilisés.

Programmation en langages évolués
Lorsque le nombre d'architectures différentes a augmenté, un

premier effort a été produit pour séparer les concepts
manipulés dans les langages de leur représentation dans
la machine et a aboutit à la création de langages comme
FORTRAN.

Méthode d’analyse par décomposition
La complexité croissante des

programmes a de nouveau suscité
un effort pour mieux structurer les
programmes (en abandonner le
goto et la programmation spaghetti).
Les méthodes d'analyse consistait
alors à « diviser pour mieux
régner », autrement dit à découper
les tâches en modules
indépendants considérés comme
des boites noires [Edsger Dijkstra].

Structuration des programmes
Niklaus Wirth alla plus loin en considérant les programmes

comme la « somme » d'une structure de données et d'un
ensemble distinct d'algorithmes chargés de les manipuler.
La programmation structurée étaient alors synonyme de
programmation dirigée par les traitements.
Limites de la programmation structurée

L’explosion des besoins
Le coût du matériel informatique a fortement décrût et ce

matériel est devenu un bien de consommation courant (tant
dans des entreprises et des universités que chez les
particuliers).
La clientèle s'est diversifiée, les besoins ont explosé.

Des besoins très variés
Certains besoins concernent la création de logiciels mais

d'autres besoins concernent la « maintenance » de logiciels (70
% du coût du logiciel).
40 % de cette maintenance sont des extensions ou des
modifications demandées par les utilisateurs.

La diffusion de la structure des données dans le code
La programmation structurée nécessite de faire des hypothèses

sur les données à traiter .
La structure physique des données à traiter est diffusée dans
une part importante du code.
Une simple modification des exigences des utilisateurs ou une

modification des données peut entraîner d'importantes
modifications au niveau des codes chargés de les traiter.

L’exemple de des postes Américaines
Par exemple, en 1982, les postes américaines sont passés du

code postal à 5 chiffres à celui à 9 chiffres. Beaucoup de
programmes gérant des fichiers d'adresses ont dû être récrits
à grands frais.

Synthèse de la situation avant la POO
D'un côté des utilisateurs formulaient des exigences qui leur

semblaient simples
De l'autre des concepteurs de logiciels ne maîtrisaient pas la
complexité logicielle notamment à cause de la
programmation structurée.
Nous avons alors abouti à une explosion des délais et des

budgets informatiques ce qui s'est traduit à grande échelle
par une crise du logiciel.
Introduction au langage UML
Les apports de la
modélisation objet
Les apports de la modélisation objet
Plan de la partie
Voici les chapitres que nous allons aborder :
Méthode et modèle
Le principe d’encapsulation.
Le principe d’abstraction.
Le principe de modularité.
Synthèse.
Méthode, modèle
processus
Une méthode comprend deux parties :

une première, technique, qui correspond à l’ensemble des activités
induites (ce que l’on doit faire et dans quel ordre) ;
une seconde, organisationnelle, relative à la gestion du processus
(qui fait quoi, avec quelles ressources).
Il faut ajouter à cela un aspect outillage qui complète
avantageusement cet « arsenal ».
techniques
Méthode = { notations, processus, outil, management}
UML
UP StarUML
Méthode, modèle
Un modèle est une représentation (le plus souvent abstraite) de
quelque chose que l’on perçoit :
Modèle 1 Modèle 2
ﾪ
ﾎ
réalité déformée
filtre réalité
filtre réalité déformée
perception perception
Modèle
ÉPISTÉMOL., SC. Système physique, mathématique ou

logique représentant les structures essentielles d'une réalité
et capable à son niveau d'en expliquer ou d'en reproduire
dynamiquement le fonctionnement`` (Birou 1966). Modèle
explicatif; modèle logico-mathématique:
On parle de modèle, en science, chaque fois qu'il y a renvoi
d'une réalité concrète à une réalité idéale avec exploitation de
leurs analogies descriptives. Analogie ne signifie nullement
identité; il existe même une différence de nature entre le
modèle et le réel qu'il représente, le modèle ayant une valeur
symbolique. Sill. Psychol. 1980, p.753.
Réf: http://www.cnrtl.fr/lexicographie/modele
Objets de la vie courante
Rêve
123CDE91 titi
garfield mange
0605040302
0102030405 grosminet
parle
odie
001-DF-YTR
poursuit
007BEJ06
Dupond Dupont
poursuit
java 2
0203040506 felix
45BEJ91
Les objets coopèrent
Objet boîte noire
Services rendus par l’objet

:
Démarrer ;
Arrêter ;
Accélérer ;
Freiner ;
Climatiser …
Fonctionnement
interne ???
Objet logiciel
Abstraction
Représentation abstraite des entités du monde réel ou virtuel
dans le but de les piloter ou de les simuler
Programme, logiciel
Objet = Message =
demande de
Service
État + service
État
Comportement +
Identité
unObjet
Téléphone portable
voir R ép er toir e
() appeler (Bob)
ch er ch er
appeler
N um er o
(personne)
État
(p er sonne)
monTéléphone recevoir
msg appeler (Bob et Paulette)
(msg)
Le principe d’encapsulation
Le principe
Le principe de l'encapsulation est « d'enfermer »
(de cacher) les données dans des entités logicielles
appelées objets qui fournissent des méthodes pour accéder
« proprement » en lecture et en écriture à ces données que nous
appelons attributs (ou champs).
INTERFACE
METHODES ATTRIBUTS
Selon Grady BOOCH
L’objectif et les conséquences
Cette encapsulation avait pour principal objectif de confiner la

structure physique des données à l'intérieur de l'objet afin
de limiter l'impact d'une éventuelle modification dans la
structure des données.
L’adaptabilité du code est améliorée donc l’écriture du code et

sa maintenance sont facilitées
Le principe de modularité
L’héritage et le polymorphisme
D'autres concepts comme l'héritage et le polymorphisme ont

été mis en place plus tard dans les langages de POO afin de
faciliter la ré-utilisabilité du code :
productivité accrue des équipes de programmeurs ;
extensibilité du code améliorée.
L’héritage
Ces objets graphiques ont des points Point

Couleur
communs comme la couleur ou le
Point d’ancrage
point d'ancrage : ces attributs peuvent
être déclarés une seule fois au
niveau de l'objet Point, ils seront
connus de la descendance. Segment
De même les méthodes permettant de

lire ou de modifier ces attributs seront Rectangle
codées une seule fois au niveau de
Point pour être connues de la
descendance.
Le polymorphisme
Soit des objets graphiques (le point, le cercle, le carré ...)

munis d’une même méthode « dessiner » qui se comporte
différemment selon le type d'objet.
Nous créons un objet « abstrait » appelé objetGraphique

muni d'une méthode virtuelle « dessiner ».
On créé un tableau d’objetGraphique et lorsqu’on implante

une boucle où est appelée la méthode dessiner de chaque
élément, le système détermine automatiquement la bonne
méthode dessiner à utiliser.
Le polymorphisme
« abstract »
ObjetGraphique
virtual dessiner
Point Cercle Carré
dessiner dessiner dessiner

Le principe d’abstraction
Le principe
Chaque acteur de la conception possède son propre point

de vue sur l'objet qui est conditionné par son domaine
d'activité professionnelle, par sa culture et sa sensibilité.
Les niveaux d'abstraction perçus par chacun sont alors

différents
L'objet à concevoir doit pouvoir être décrit en respectant

différents niveaux d'abstraction (du général au précis).
Les différents points de vue (selon G. BOOCH)
Les différents niveaux d’abstraction (selon G. BOOCH)
La pratique
D’un point de vue pratique, ce principe d’abstraction est atteint

en utilisant une hiérarchie d’objets :
des objets (par exemple des souris) qui englobent
d’autres objets (différents types de rouages) qui englobent
d’autres objets plus petits (les composants) qui contiennent
des objets atomiques.
Les concepteurs peuvent donc manipuler un objet dans sa

globalité ou dans un niveau de détail plus fin.
Synthèse
Les 3 principes de la modélisation objet
Introduction au langage UML
L’aspect historique de la
modélisation objet
L’aspect historique de la modélisation objet
Plan de la partie
Voici les chapitres que nous allons aborder :
Introduction.
Grady Booch et OOD.
Ivar Jacobson et OOSE.
John Rumbaugh et OMT.
L'arrivée d'UML.
Introduction
Une petite chronologie
Les premières méthodes d'analyse apparaissent au cours

des années 70.
Les méthodes d’analyse sont améliorées dans les années

80. On adopte une approche systémique (modélisation des
données et modélisation des traitements) et on utilise des
méthodes comme Merise, Axial, IE...
Dans les années 90-98, le langage C++ connaît de plus en

plus d’adeptes. On assiste à ce moment à une l’émergence
d’une multitude de méthodes objet (Booch, Classe-
Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE) :
3 méthodes se démarquent (OMT, OOD et OOSE).
Grady Booch et OOD

Description
OOD signifie « Object Oriented Design ».

Cette méthode a été créée en 1993 par Grady Booch, alors
qu’il travaillait chez General Electric pour faciliter la phase de
conception orientée objet des gros projet.
Cette méthode propose des vues logiques et physiques du
système.
Ivar Jacobson et OOSE

Description
OOSE signifie « Object Oriented Software Engineering ».

Cette méthode, créée en 1995 par Ivar Jacobson dans le
cadre de ses activités chez Ericsson, introduit la notion de
use-cases (cas d’utilisation).
John Rumbaugh et OMT

Description
OMT est l’acronyme de « Object Modeling Technique ».

John Rumbaugh a créé cette méthode en 1996 et a
commercialisé un logiciel appelé Rational Rose (de la
société Rational Rose Software) qui est une référence
dans le domaine de la modélisation.
Cette méthode propose des vues statiques, dynamiques et
fonctionnelles d’un système.
L’arrivée d’UML
L’unification
Entre 1995 et 1997, nous assistons à une fusion progressive

de ces 3 méthodes (OOD, OOSE et OMT) :
représentation graphique commune des notions qui apparaissaient

comme semblables ;
apport des éléments spécifiques à chacune des méthodes.
Ces 3 méthodes ont donc été unifiée sous la bannière UML

qui signifie Unified Modeling Language.
La normalisation
UML devient une norme de l’OMG en 1997.
L’OMG (Object Management Group) est un organisme à but

non lucratif créé en 1989 afin de promouvoir des standards
(comme CORBA par exemple) qui garantissent
l’interopérabilité entre des applications orientées objet
développées sur des réseaux hétérogènes.
Cet organisme a été créé et est soutenu par des industriels

comme HP, Sun, Unisys, American Airlines, Philips …
L’évolution
La norme a évolué afin d’intégrer
de nouveaux diagrammes ;
une manière de formaliser les contraintes grâce à OCL
(Object Constraint Language) proposé par IBM.
On a donc eu :
la version 1.1 en 1997 ;
la version 2.0 en 2004 ;
la dernière est la 2.1.1 du 3 février 2007.
L’évolution
Au final, qu’est-ce qu’UML ?
UML est un langage visuel, basé sur l’utilisation de

diagrammes normalisés.
Il permet d'exprimer visuellement une solution objet, ce qui

facilite la comparaison et l'évaluation de solutions.
UML n’est pas une méthodologie de développement,

contrairement à RUP (Rational Unified Process).
Les différentes vues
UML propose 5 vues qui se superposent en partie afin de

présenter les systèmes sous différents aspects.
Vue d’implémentation Vue logique
Vue des cas d’utilisation
Vue du déploiement Vue des processus

Les différentes vues
La vue des cas d'utilisation décrit le système tel que le

perçoivent les acteurs (leurs besoins).
La vue logique décrit l’intérieur du système pour expliquer
comment peuvent être satisfaits les besoins.
La vue d'implémentation définit les dépendances entre les
modules.
La vue des processus est la vue temporelle et technique,
qui met en œuvre les notions de tâches concurrentes, stimuli,
contrôle, synchronisation, etc.
La vue de déploiement décrit la position géographique et
l'architecture physique de chaque élément du système.
Les différents diagrammes
UML (qui est avant tout un langage graphique) propose 13

types de diagrammes.
Ces diagrammes sont présentés dans la norme sous forme

d’un diagramme de classes afin de mettre en évidence les
deux types de diagrammes :
les diagrammes de structure pour modéliser l’aspect statique
d’un système ;
les diagrammes de comportement pour modéliser l’aspect
plutôt dynamique d’un système.
Les différents diagrammes
Diagramme
Diagramme de structure Diagramme de comportement
Diagramme de classes Diagramme d’activité
Diagramme d’objets Diagramme de cas d’utilisation
Diagramme de paquets Diagramme d’états-transitions
Diagramme de déploiement Diagramme d’interaction
Diagramme de composants Diagramme de séquence
Diagramme de structure composite Diagramme de communication
Diagramme global d’interaction
Diagramme de temps
Les points forts
UML est un langage formel et normalisé :
un gain de précision (pas d’ambigüité) ;
un gage de stabilité qui encourage à la création et
l’utilisation d’outils.
UML est un support de communication performant :

il cadre l’analyse ;
il facilite la compréhension de représentations abstraites
complexes ;
son caractère polyvalent et sa souplesse en font un
langage universel.
Les points faibles
L’utilisation pratique d’UML passe par un apprentissage.

UML ne propose pas de méthodologie, c’est seulement
un langage graphique.
Représentation du contexte du système
Définir les Limites du système à développer
Relations entre le système et son environnement.
Diagrammes:
Cas d’utilisation
Gestion commerciale représente le périmètre de l’étude

Les acteurs sont des personnes ou des systèmes en
relation avec le domaine de l’étude.
Les acteurs sont extérieurs au domaine de l’étude.
Diagrammes:Cas d’utilisation
Pour:
Structurer fonctionnellement le domaine pour décrire les
exigences
Répartir le travail et les responsabilités pour la spécification
et la validation des besoins.
Les cas d’utilisation
Opportunité
Analyse
du besoin
Analyse
du problème
de la solution
Conception
de la solution
Implémentation
Mise en oeuvre
Cas d’utilisation
Chaque cas d’utilisation est accompagné d’un

texte et éventuellement de diagrammes
Ceux-ci expriment les exigences du client
Les exigences constituent une partie du contrat
entre le client (maîtrise d’ouvrage) et les
développeurs (maîtrise d’œuvre)
Cas d’utilisation
Exemple de rédaction
Titre: Préparation de la commande fournisseur
But: Déterminer la date de passation de commande
Version, date de rédaction
Auteur de la rédaction
Acteurs du cas d’utilisation: acheteur
Préconditions:
Les demandes d’achat sont valides, elles ont été affectées à
l’acheteur qui initialise le processus.
Postcondition:
La date de passation de commande de la DA est prévue
Événement initial:
Affectation des DA nouvellement arrivées à un acheteur
Description du scénario de base
Description des flots alternatifs
Diagrammes:
Cas d’utilisation. Acteurs
Le domaine du projet est découpé en cas d’utilisation
Chaque cas d’utilisation représente une fonction du

système informatique dont un acteur métier a besoin
Un acteur métier est un rôle.
Dans la démarche: on recherche d’abord les acteurs

métier puis les fonctions dont ils ont besoin.
Diagrammes:
Cas d’utilisation.
Le cas d’utilisation spécifie la façon dont le

système est utilisé pour aider un client ou un
utilisateur à atteindre ses objectifs. Il décrit un
processus.
Cas d’utilisation
Spécifications de besoins,
exigences
Le texte doit être bien structuré

Il est sous la responsabilité de l’utilisateur
Il peut être accompagné de diagrammes UML
Il décrit ce que doit faire le système et non
comment
Cas d’utilisation
Spécifications de besoins,
exigences
Le cas d’utilisation décrit un processus métier
Le processus est déclenché par un événement métier
Il se termine par un résultat intéressant pour l’utilisateur ou par
un échec
Il comporte souvent plusieurs scénarios
Diagrammes:Cas d’utilisation
Chaque cas d’utilisation est accompagné d’un

texte et éventuellement de diagrammes
Ceux-ci expriment les exigences du client
Les exigences constituent une partie du contrat
entre le client (maîtrise d’ouvrage) et les
développeurs (maîtrise d’œuvre)
Cas d’utilisation
Exemple de rédaction
Titre: Passation de la commande au fournisseur

But: Transmettre une commande valide au fournisseur
Version, date de rédaction
Auteur de la rédaction
Acteurs du cas d’utilisation: acheteur
Préconditions:
Les demandes d’achat sont valides, elles ont été affectées à
l’acheteur qui initialise le processus.
Postcondition:
La commande est transmise, sa transmission est enregistrée
Événement initial:
Affectation des DA nouvellement arrivées à un acheteur
Description du scénario de base
Description des flots alternatifs
Diagramme de cas d’utilisation
Relations
Les cas d’utilisation peuvent être fractionnés.

Puis reliés.
relation « include »
relation « extend »
relation « generalise »
Cas d’utilisation
Relation « include »
Permet d ’identifier des sous-ensembles

communs à plusieurs cas d ’utilisation
comptable
« include » « include » Accueil
Contrôle adhérent
Règlement cotisations
Inscription activité
Contrôle adhérent est extrait de « Règlement cotisation »
et de « Inscription activité » afin de ne le décrire qu’une fois
Cas d’utilisation
Relation « include »
« include »
Cas d’utilisation
Relation « extend »
Accueil
« include »
contrôle adhérent
Permet de décrire séparément
certaines partis alternatives, « extend » extension
optionnelles ou exceptionnelles
Inscription activité inexistante

Cas d’utilisation
Relation « extend »
L‘extension ne peut être

Accueil
activée directement « include »
contrôle adhérent
Texte: La relation est indiquée dans le
« extend »
cas extension, ici inscription activité inexistante
L‘extension peut être planifiée dans un autre Inscription

activité inexistante
incrément que le cas d’utilisation de base
Cas d’utilisation
Relation généralisation
Plusieurs cas d’utilisation ont le même but
Ils ont des fonctionnements différents, Ce sont les variantes

d’une même fonction.
Cas d’utilisation
Relation Généralisation
« inc
lude
» »
contrôle comptable
Règlement cotisations
« Généralisation »
Règlement par courrier Règlement par Internet
adhérent
Exercice
Faire le modèle de cas d’utilisation
correspondant aux fonctions suivantes:
Contrôle des commandes client (la saisie des
commandes est faite chez le client par le commercial ou
au siège à partir d’un formulaire)
Réception des règlements
Dans ces 2 cas l’identité du client est contrôlée
Traitement des anomalies commandes
Le contrôle des commandes est sous la responsabilité

du commercial ou de l’administration des ventes. Le
comptable est responsable de la réception des
règlements
Exercice
Modèle de cas d’utilisation
Prise de commande Contrôle identité client

Commercial chez client
<<include>>
<<généralisation>> <<include>>
Contrôle commande Réception règlement Comptable
<<extend>>
Administration ventes Saisie commande
au siège
Traitement anomalies
commandes
Traiter le passage en
caisse
Titre : Traiter le passage en caisse

Résumé : un client arrive à une caisse avec des articles qu’il souhaite
acheter. Le caissier enregistre les achats et récupère le paiement.
A la fin de l’opération, le client part avec les articles.
Acteurs : principal caissier, secondaire client.
Pré conditions : la caisse est ouverte (donc en service) ;
un caissier y est connecté
Post conditions: Le client a payé, la vente est enregistrée,
le ticket de caisse a été donné au client.
Description du flot de base :
Ce cas d’utilisation commence quand un client arrive à la caisse avec des
articles qu’il souhaite acheter.
Le caissier enregistre chaque article. S’il y a plus d’un exemplaire par
article, le caissier indique également la quantité.
La caisse détermine le prix de l’article et ajoute les informations sur
l’article, à la vente en cours. La caisse affiche la description et le prix de
l’article en question.
Après avoir enregistré tous les articles, le caissier indique que la vente est
terminée. La caisse calcule et affiche le montant total de la vente.
Le caissier annonce le montant total au client.
Le client choisit le type de paiement :
E ncas depai
em ent cash, calculerla m onnai
eà rendre
La caisse enregistre la vente effectuée et imprime un ticket.
Le caissier donne le ticket de caisse au client.
Le client s’en va avec les articles qu’il a achetés.
Pour éviter les Si dans le flot de base
Les flots alternatifs sont décrits à part
Flot alternatif 1: numéro d’identification inconnu

Cette alternative démarre au point 4 du flot de base.
La caisse indique au caissier que le numéro d’identification de
l’article est inconnu. L’article ne peut alors être pris en compte dans
la vente en cours.
Le flot de base reprend au point 4.
Flot alternatif 2 : client ne pouvant pas payer

Cette alternative démarre au point 6 du flot de base.
Le client ne peut payer le total avec aucun moyen de paiement
autorisé.
Le caissier annule l’ensemble de la vente et le cas d’utilisation se
termine en échec (post condition non réalisée)
Flot alternatif 3: client payant par chèque
Cette alternative remplace le point 6 de la version de base.

Le chèque est mis par le caissier dans le lecteur de chèque
qui imprime le montant et la date
Le caissier fait signer le chèque.
Le flot de base reprend au point 7
Exercice
Cas d’utilisation paiement par carte
Ce cas d’utilisation remplace le point 6 du cas d’utilisation:
« Traiter le passage en caisse ». En cas de succès, le flot reprend
au point 7; en cas d’échec il reprend au point 6 de « Traiter le
passage en caisse »
Flot de base
1. Le client insère la carte dans le lecteur de carte et saisit son
code
Flot alternatif échec: Le code saisit est faux 3 fois de suite
à la suite du point 1
« extend » Payer par carte
Traiter le passage en
caisse
Diagramme cas d’utilisation
Le diagramme de cas d’utilisation montre le comportement d’un
système, les services visibles de l’extérieur, fournis par le système
dans le contexte de son environnement
Exemple: Téléphone mobile
Modélisation logique structurelle
Diagramme de classe
Architecture
du système d’information
du système informatique
Objets
Classes
Paquetages
Modélisation structurelle
Les objets
Un objet est « une chose »

qui peut être parfaitement
identifiée; une personne
précise, une organisation,
une machine ou un
événement peuvent être
considérés comme des
objets.
Les objets
Un objet peut sauvegarder des valeurs, ces valeurs ont un

nom (nom d’attribut)
.Ces valeurs constituent l’état de l’objet. l’état de l’objet peut

changer
Les objets
Un objet offre des

opérations (son
comportement) qui
permettent
d’examiner ou de
modifier son état.
L’état d’un objet garde le souvenir

de l’exécution des opérations
Les objets
Un objet est une instance de classe

3 représentations possibles d’un objet:
Valérie Valérie: Personne

: Personne
Date embauche =12-07-76
nom de l’objet nom de l’objet , Objet anonyme

nom de la classe
Les Classes
Les objets sont groupés en ensembles appelés classes.
Les objets sont des instances de classe.
Salarié Lili:Salarié
nom Instance de nom:Lili
Poste poste:DRH
salaire
3000 euros
payer()
Les classes
Une classe est une abstraction qui représente l’idée
ou la notion générale que l’on peut avoir d’un ensemble
d’objets similaire
Par exemple tous les salariés d’une entreprise
appartiennent à la classe « Salarié »
Tous les objets d’une classe partagent les mêmes attributs,

le même comportement et les mêmes associations.
Tous les salariés ont un salaire, chaque mois ils touchent
leur salaire, ils travaillent pour une entreprise.
Les Classes
Pendant la phase d’analyse une classe est un concept du

monde réel (ex : salarié, adhérent, prime)
Pendant la phase de conception elle peut être un concept

technique (ex : pilote d’imprimante, fenêtre…) elle est
affinée par des notions techniques (ex: visibilité)
Pendant la phase d’implémentation une classe est un

élément du logiciel
Les Classes
Chaque classe est représentée sous la forme d’un
rectangle divisé en 3 compartiments. Le 1er
compartiment contient le nom de la classe, le second
les attributs et le 3ème les opérations
Personne
adressePrincipale
nom
facturer ()
Les Attributs
Chaque nom d’attribut peut être accompagné de détails

facultatifs tels que le type ou la valeur par défaut.
Le type et la valeur par défaut seront généralement
mentionnés à partir de la phase de conception.
Personne
N om :chai ne
A ge:enti er
S olv ab i
li
té:Booléen=1
Les attributs dérivés
Un attribut dérivé peut être calculé à partir d’autres

attributs
On le trouve:
soit dans le compartiment attribut précédé d’une barre
oblique
soit dans le compartiment opération
C’est un choix de conception
Rectangle
Longueur
Largeur
/S urface
Les opérations
Une opération spécifie une action qu’un objet doit exécuter

Une méthode est une procédure qui implémente une opération
Généralement
En phase d’analyse, on écrit seulement le nom de l’opération
En phase de conception on écrit
La visibilité
Les paramètres
Le type de retour
La portée
Les opérations
« entité »
Portée de classe
Personne {auteur=Rémi}
adresse
nom
solde
Portée d’instance créer

Facturer ( remise : Int = 0, montant : Int ) : montantDu
La visibilité
UML définit 3 niveaux de visibilité pour les attributs et les

opérations
+ Public qui rend l’élément visible à tous les clients de la

classe ·
# Protégé qui rend l’élément visible aux sous-classes de
la classe
— Privé qui rend l’élément visible aux opérations de la
classe seule
La visibilité
Client
—
nom
— adressePrincipale
— enregistrer()
# facturer()
+ consulter nom()
Les relations
L’association
La généralisation
La dépendance
La réalisation
L’association
Il existe des liens entre les objets
Exemple:
Les commandes sont liées aux clients
Client Passe > Commande

raisonSociale 1 *
dateCommande
Multiplicité
Un objet peut être relié à plusieurs objets:
Un client peut être relié à plusieurs commandes.
Mais une commande ne peut être reliée qu’a un seul
client
et elle est nécessairement reliée à un client.
La multiplicité s’écrit :
1 toujours 1
0..1 0 ou 1
* ou 0..* 0 à plusieurs
1..* 1 à plusieurs
m..n de m à n (entiers naturels)
Classes d’association
Chaque lien de l’association est relié à un objet de la classe association.

Chaque objet de la classe association est identifié par les références aux
classes reliées ; Il ne peut y avoir plusieurs liens entre les mêmes objets
On indique cette classe si le lien est porteur d’attributs ou d’opérations .
Une classe d’association peut être associée à d’autres classes
Personne * ** Diplôme
nom niveau
DiplômeObtenu
date obtention
Rôle
Un rôle décrit la part prise par une classe dans une

association, il est écrit sur l’association du coté de la
classe correspondante
Le rôle permet de distinguer plusieurs associations
entre les 2 même classes
résident 1
Personne *
travailleur Ville
nom * *
Associations qualifiées
Le qualificatif permet de retrouver 1 ou n objets à l’autre
bout de l’association il sélectionne certains objets)
Nom de fichier est un identifiant relatif pour Fichier
1
Répertoire 1 Fichier
Nom de fichier
* 1
Banque compte Personne
Associations qualifiées
Exercice
Comment modéliser les chambres d’une chaîne

d’hôtels en indiquant que les hôtels ont la liberté de
leur numérotation
Contraintes d’intégrité sur
association
Statue
{ ou exclusif } Commune Personne

Musée Site
Sous-ensemble
Association réflexives
Un objet d’une classe peut être associé à un autre
objet de la même classe
Personnel chef
1
collaborateur 1..*
Associations n-aires
Des associations peuvent relier plus de 2 classes

Joueur
Équipe Année
Record
Gain
Exercice
Représentation principal
Spectacle
Date représentation Acteur
metteur en scène
Heure représentation * 1 0..* 1..*
Tarif
Prix place
* *
*
réserver
Billet Réservation
num billet vendre Agence
Date réservation
1..* * 0..* 1
*
Catégorie Place
1 *
L’agrégation
L’agrégation est une forme particulière d’association qui

exprime un couplage plus fort entre classes.
L’agrégation permet de représenter les relations de type

maître esclave, tout et partie, ou composé et
composant.
Mission *
Développeur
Agrégation simple
Agrégation de composition
L’agrégat « possède » ses parties,
Les partie sont « à l’intérieur » de l’agrégat ; Un objet ne
peut être l’élément de plusieurs agrégats.
La destruction de l’agrégat entraîne la destruction des
parties
Commande 1
LigneDeCommande Article
1..*
quantitéCommandée * 1 référenceArticle
préparer
Exercice
Un médecin veut modéliser des informations concernant

ses patients, leurs consultations, leurs maladies.
Exercice
Patient Consultation
1 0..*
Date
Maladie
Généralisation et spécialisation
La généralisation consiste à factoriser les éléments

communs (attributs, opérations, relations) d’un
ensemble de classes dans une classe plus générale
appelée super-classe.
Les sous-classes héritent des caractéristiques de
leur super-classe
Tiers Banque
raisonSociale Code
Client Fournisseur
facturer() régler()
Tiers Banque
raisonSociale Code
Client Fournisseur
facturer() régler()
ClientNat ClientExport Devise

Site Objet Nation
Code
Bâtiment ObjetMobile Musée
Statue Bijou Particulier

Contrainte d’intégrité sur
généralisation
Objet Objet
Statue Bijou Statue Bijou

Classe abstraite
Une classe abstraite ne peut être instanciée, ses sous-classes sont
concrètes
Classe abstraite
Activité
nom activité
montant
planifier()
Classe concrète
Tennis Foot
planifier() planifier()
Représentation de l’architecture
Une bonne architecture doit permettre:

La réutilisation
La répartition du travail entre équipes
L’étude d’impact lors des changements fonctionnels,
techniques et d’explitation
UML offre des notations destinées

à découper
Le système d’information
Le logiciel
À isoler les éléments du logiciel
Les Paquetages
Les Paquetages
Représentation de
l’architecture
Architecture technique
1 paquetage= n éléments
1 composant=1 ou n classes
Les Paquetages
livraison article
Classe livraison (from vente) (from stock)
appartient à vente
Le paquetage vente Commercial::Vente

appartient à commercial + commande stock
+ client +stockFaçade
— livraison _article
Classe non visible
_ entrepôt
à l’extérieur du
paquetage
dépendance
commercial java.io
Paquetages leur contenu et leurs dépendances

Modélisation de la dynamique du
système
Diagrammes d’interaction
Diagramme de séquence
Diagramme de communication
Diagramme d’activité
Diagramme État-Transition
Modélisation de la dynamique du
système
Les diagrammes d’interaction et d’activité
précisent le texte du cas d’utilisation
Cas d’utilisation
flot de base
Flots alternatifs
n diagrammes de séquence Diagramme de classe

n diagrammes d’activité
Modélisation de la dynamique
Un diagramme de séquence représente un ou plusieurs
scénarios d’un cas d’utilisation (cas d’utilisation parent)
Pour un cas d’utilisation, il peut y avoir autant de

diagrammes de séquence qu’il y a de scénarios
Le diagramme de séquence transforme la structure
fonctionnelle, décrite par le cas d’utilisation en une
structure objet
Il représente les messages que les objets doivent

s’échanger pour réaliser la fonction.
Ces messages sont des appels d’opérations ou de

groupes d’opérations. Ils sont effectués par des objets
vers des objets.
Les objets sont des acteurs ou des objets logiciels.

Un objet de la classe
Acteur activité
: adhérent : activité
: Accueil
Message
Demande inscription activité La flèche est dans le
sens du flux de contrôle
inscription
Demande supplément cotisation

Période d’activité
de l’objet
Paiement
Ligne de vie de l’objet
Un objet ou un participant peut être anonyme,

identifié, qualifié
: adhérent Martin : adhérent adhérent actif
: adhérent
Adhérent est ici

un objet du logiciel
Diagramme de séquence, concepts
Diagramme de séquence, concepts
Événements (ou messages)

Un diagramme de séquence montre les
messages que les objets s’échangent.
Ces messages sont des événements :
Ils déclenchent des opérations sur les objets
destinataires
Ligne de vie
Exercice
Faire le diagramme de séquence correspondant à cet extrait du
cas d’utilisation Règlement cotisations
Suite à un appel de cotisation (qui a été fait longtemps avant et qui, par
conséquent est décrit dans un autre cas d’utlisation) les adhérents paient leur
cotisation, le paiement est enregistré, les appels de cotisation correspondants
sont mis à jour, un accusé de réception est retourné à l’adhérent
Paiement
Adhérent Règlement cotisations
AppelCotisation
unPaiement unAppel
: Adhérent
Cotisation
paiement
cotisation
accuséRéception
Client théatre : : Spectacle : : Place Paiement
: Client
Activité Représentation
Contrôle client
[client pas OK]

Contrôle activité
[activité pas OK]
[Réservation OK]
Représentation des paramètres
: Client Client
Demande réservation(code client,code activité)

Diagramme de séquence,
Représentation de plusieurs
scénarios
adhérent Un paiement Un appel cotisation
paiement
cotisation
Qualité du montant
Accusé réception [Si montant OK]
Avis solde [Else]

Représentation de plusieurs scénarios
Exercice
le service commercial doit la contrôler

Si elle n’est pas correcte, l’annuler Recevoir la commande
Si elle est correcte,

Faire le bon de livraison
Faire la facture
Dans tous les cas mémoriser son état
Recevoir la commande
[Commande pas OK]
[else]
D iagram m e de séquence: R eprésentation d’une
itération Par un cadre d’interaction
15 octobre
Représentation d’une itération
A la réception de la commande:
le service commercial doit la contrôler

Il saisit la commande
Il contrôle que chaque article est en stock
Sinon, il annule l’article
Si la commande est OK
Il fait la facture
Recevoir la commande
1. paiement :Paiement
2:cotisation
3.
: Adhérent
Ac
cu
sé
de
3.
Av
ré
ce olde
is
pt
de
io
s
n
[m art]
on
[é
ta
c
nt
O
K]
: Appel cotisation
2:cotisation
3.
: Adhérent
Ac
cu
sé
de
3.
Av
ré
ce olde
is
pt
de
io
s
n
[m art]
on
[é
ta
c
Flux de contrôle
nt
O
K]
Message
: Appel cotisation activité
adhérent
Classes correspondantes
nom activité
nom adhérent
montant
* *
2:cotisation
3.
: Adhérent
Ac
cu
sé
de
3.
Av
ré
ce olde
is
pt
de
io
s
n
[m art]
on
[é
ta
c
Flux de contrôle
nt
O
K]
Message
: Appel cotisation
2: Contrôle client
1: Demande réservation 4: Contrôle activité 6:

Client théatre : : Spectacle
Activité
3: [client pas OK] 5: [activité pas OK] 11:
: Client 15: [Réservation OK] 12:
14: 13: 10: 7:
: Représentation
Paiement
9: 8:
: Place
Diagrammes d’interaction
et démarche
Interactions entre les acteurs et le système (Analyse des besoins)
Interactions entre les objets logiciels (Analyse du problème et
conception)
Interaction entre les acteurs (Analyse des besoins)
Diagramme de flux (Analyse des besoins)
Interaction entre les objets logiciels
(Analyse du problème et conception)
(surtout s’il n’y a pas de chronologie ou si on veut montrer les liens entre
les objets)
Permet de représenter une logique procédurale, un processus

métier, un workflow
On peut représenter le déroulement des actions dans des
chemins alternatifs ou parallèles
Nœud initial
Enregistrer
la commande
Contrôler Commande
Action
Sortir article
Expédier Commande
Nœud final
Partitions
Client Ventes Entrepôt
Enregistrer Ressource
la commande
Contrôler Commande
Sortir article
Expédier Commande
Décisions
Client Ventes Entrepôt
Contrôler Commande
Sortir article
OU [OK] Sortir article
[Pas OK]
Annuler Expédier Commande
Commander
la commande
OU
Enregistrer état Commande

Exercice
Lorsque le réveil sonne, prendre le petit déjeuner puis
préparer le cartable (sauf le mercredi) puis, dans tous les
cas, se laver
Sonnerie réveil
Déjeuner
mercredi? non
oui Préparer
cartable
Se laver
Les diagrammes d’activité
Barre de synchronisation
administration Ventes Entrepôt
Contrôler Commande
Contrôler Commande
(fork)
[Pas OK]
[OK]
Préparer
Préparer bonbon
livraison ET Préparer Commande
livraison
(joint)
Commande expédiée
Explication du schéma précédent

Si le contrôle de la commande est satisfaisant (OK) on peut faire le bon de livraison
et préparer la commande, dans n’importe quel ordre successivement ou
parallèlement
Pour expédier la commande il faut que sa préparation soit terminée et que le bon de
livraison soit fait
Exercice lorsque le réveil sonne
Lorsque le réveil sonne, l’homme commence par prendre sa
douche.
Au sortir de la douche, il réveille sa femme et effectue sa
gymnastique
Ensuite, il prépare le petit déjeuner pour sa famille, et enfin prépare
la voiture pour le départ
La femme, à son réveil, fait sa toilette matinale, puis prépare les

cartables des enfants – sauf le mercredi – et enfin prend son petit
déjeuner avec les enfants.
Tout le monde se retrouve ensuite en voiture l’homme fait
l’inspection finale et la mise en route.
Homme Femme
Sonnerie réveil
Douche
Gym Toilette
Mercredi?
[ Non ] [ Oui ]
Préparation
petit déjeuner Préparation
cartable
Préparation
voiture
Petit
déjeuner
Famille en route Inspection et

mise en route
Décomposition d’une action
Les actions peuvent être décomposées en sous-activités.
On peut ainsi décrire un processus globalement puis
l’affiner progressivement
Réception
commande
Exécution
commande Envoi facture
Livrer
Traitement
paiement
Clore
l'ordre
Livrer
Livraison
normale
Exécution
Clore
commande l'ordre
Livraison
urgente
Exercice
Détailler l’exercice: « lorsque le réveil sonne »
Pour préparer le petit déjeuner l’homme sort les
ingrédients
Si le café manque, il prend du thé.
Il prépare soit le thé soit le café
Il dresse la table
Gym
Homme en forme
Préparation petit déjeuner

Sortir
ingrédients
Préparer Préparer thé

café
Dresser la
table
Préparation
voiture Petit
déjeuner
Invocation d’une méthode
Dans une action, on peut invoquer une méthode
Livrer
Livraison
normale Clore
Exécution l'ordre
commande Ordre::SuppressOrder
Livraison
urgente Nom de la classe Nom de la méthode
Signaux
Signal temporel
Une activité écoute ces signaux en permanence, ils
constituent un événement d’un processus extérieur, le
diagramme définit comment l’activité réagit à ces
événements
2 heures Faire les
bagages
avant le vol
Partir pour
l'aéroport
Taxi
arrive
Exercice
Une commande Fournisseur est rédigée puis envoyée
A la réception de l’accusé de réception, la commande est
validée.
Si 2 semaines après l’envoi de la commande, l’accusé de
réception du fournisseur n’est toujours pas parvenu, la
commande est annulée
Région d’expansion
Une région d’expansion délimite dans un diagramme

d’activité une zone ou les actions s’exécutent une fois
pour chaque élément d’une collection
Choisir un thème
Ecrire Relire Publier

l’article l’article la revue
« concurrent »
Contrôle client
Existence de Contrôle stock Etablir

l’article de l’article la facture
Modélisation de la dynamique Les
diagrammes d’activité
Activités et flot d’objets
Dans un diagramme d’activité, il est possible de faire
apparaître clairement les objets créés, détruits ou
modifiés, par une activité. .
Les objets modifiés sont indiqués par des flèches en
pointillé.
Etablir Devis Commande

r
Modélisation de la dynamique Les
diagrammes d’activité
Client et flots d’objetsVentes
Activités Entrepôt
Enregistrer
la commande
Contrôler Commande
Décision [OK] Préparer

commande
[Pas OK]
Expédier Commande
Commande annulée
Commande expédiée
Concepts
État
Un objet passe par différents états au cours de son
existence
Un état est une situation au cours de la vie d’un objet

pendant la quelle il satisfait certaines conditions,
exécute certaines activités ou répond à certains
événements
L’état d’un objet est matérialisé par la valeur de certains

de ses attributs et par ses liens
Concepts
Diagramme état-transition
Le diagramme d’états-transitions représente:

Les différents états possibles d’un objet
Les opérations qui peuvent être exécutées dans cet état
Les événements qui provoquent des transitions d’un
état à un autre.
commande Evénement déclencheur
Etat initial
prise en compte commande
Opération longue
Durée de l’état
commande en enregistrement Opération courte
entry: contrôle client pendant l’état
do: contrôle article
Urgence / priorité
Événement qui ne change pas l’état exit: décision
condition
[ non ] [oui ]
Activité
commande invalide
commande valide Envoi d’événement
entry: mise en attente
exit/^: bon de préparation
[ stock OK ] / ordre de servir Opération courte pendant

la transition
Commande refusée
commande servie
Etat final
Plusieurs types d’opérations:
Une opération longue ou activité
se prolonge autant que dure l’état
est précédée de la mention do:
Opérations courtes ou actions
pratiquement sans durée:
Opérations courtes ou actions, pratiquement sans
durée:
Précédées de entry lorsqu’elles s’exécutent au moment ou
l’objet entre dans le nouvel état
Précédées de exit lorsqu’elles s’exécutent au moment ou
l’objet sort d’un état
Précédées de:
/ lorsqu’elles sont déclenchées par un événement
Conditions
Les conditions sont encadrées par des crochets

Une condition peut avoir une certaine durée
alors qu’un événement est instantané
Monter le diagramme d’états-transitions représentant les

différents états que peut prendre, au sens de l’état civil, la
classe INDIVIDU
Jugement de divorce
MARIÉ DIVORCÉ
Contrat de
mariage signé Contrat de mariage signé
Décès
individu
Décès conjoint
VEUF
Contrat de mariage signé

Naissance
CÉLIBATAIRE DÉCÉDÉ
iDécès individu
Contrat PACSE signé
Contrat PACS
signé Contrat PACSE signé
PACSÉ
Rupture contrat
Diagramme état-transition Sous-
état
Un sous- état est un état emboîté dans un autre état.
Un état composé peut contenir soit des sous-états
concurrents, soit des sous-états séquentiels
état
Sous-état séquentiel
Plante en croissance
do: Arroser
Plante non mure
Plante à maturité
on
Disponibilité[
Disponibilité[
temps
temps
favorable
favorable
] / Récolter
]: Récolter
Plante récoltée
état
Plante semée
Plante en hibernation
Plante en croissance
Plante récoltée
Diagramme d’états concurrents et
Emission
synchronisation
do: Distribuer billets
exit: billets pris Prêt à initialiser
Préparation
do: éjecter carte

exit: carte prise
La modélisation de l’implémentation
Les Composants
Les composants sont des éléments physiques comme
les exécutables, les composants Com, les EJB, les
bibliothèques, les tables, les fichiers et les documents
Un composant peut réaliser une interface définie dans

le modèle logique
Généralement, les services d’un composant sont

disponibles uniquement à travers leur interface
a modélisation de l’implémentation
Les Composants, organisation
On peut regrouper les composants en
paquetages
Les composants sont des éléments de la
gestion de configuration.
On détermine les composants à partir des cas
d’utilisation et des postes de travail. Les
composants sont distribués sur les postes de
travail
Les Composants
La distribution des composants permet un
découplage entre les applications et le métier
et facilite
La réutilisation
La maintenance
La flexibilité
modélisation de l’implémentation
Développement par composants
On créé un système à partir de composants,

On le fait évoluer
En ajoutant de nouveaux composants
En remplaçant les anciens
Sans avoir à reconstruire le système
grâce aux interfaces
Diagramme de composants
Livraison Servir Le composant Servir
contient les classes
Article et Entrepôt
disponibilité
<<Interface>>
disponibilité Article
+contrôle stock() +contrôle stock()

+préparation()
livraison
Entrepôt
+préparation()
Modélisation du déploiement
Nœud
Un nœud représente une ressource de calcul
Un composant peut être déployé par un ou
plusieurs nœud
Diagramme de déploiement
Servir
Serveur
Client 1 Client 2
Livraison
Description des processus
De l’analyse des besoins à la conception
:
vé
gé
t
a
l :
so
l :
pl
an
te:
co
mm
a
nd
e:c
l
i
ent
: client système
systè
:
cl
i
ent
:
c
ot
i
se
r c
l
i
en
t
A
c
he
t
er
effectuez votre choix
type de végétal
pourquoi?(de l'ombre?des fruits?des fleurs?)

des arbres
nature du sol
idem
ensoleillement
idem
réponse
idem
Planche de fruits
des fruits
choix de fruit
idem
planche de fleurs
des fleurs
choix de fleurs
idem
planche de silhouettes
de l'ombre
choix de silhouette
idem
liste de choix possibles

Cas d’utilisation 1
1 1..*
Scénario
1..*
Opération système 0..* 0..1
DiagrammeSéquence
système
systè
Diagramme séquenceDiagr.
système
séquence objets logic
: client
effectuez votre choix
type de végétal
pourquoi?(de l'ombre?des fruits?des fleurs?)

des arbres
nature du sol
idem
ensoleillement
idem
Représentation du dialogue entre l’acteur et le sys

réponse
idem
Planche de fruits
des fruits
On représente les flux de données

choix de fruit
idem
Quelles données sont saisies

planche de fleurs
des fleurs
choix de fleurs
idem
Quelles données sont affichées.

Eventuellement les traitements importants effectués par
planche de silhouettes
de l'ombre
choix de silhouette
idem
liste de choix possibles

Les opérations système
Exemple : RespFormation
gestion Catalogue
:système
: RespFormation
creerFormation( )
initialiserFormation (titre, durée, prix)

Opérations système
creerContenu( )
creerContenu( audience, prerequis, objectifs, outils, plan )

Conseil
creerSession() Un diagramme de séquence par
fonction
creerSession(date debut, lieu) (Créer, Modifier, Supprimer,
Editer, ../)
Identifier les opérations système
:système
: Utilisateur :Système
creerFormation( )
creerFormation()
initialiserFormation (titre, durée, prix) creerContenu()
creerContenu( )
creerSession()
creerFiliere()
creerContenu( audience, prerequis, objectifs, outils, plan ) modifierFormation()
modifierContenu()
creerSession
modifierSession()
creerSession(date debut, lieu) modifierFiliere()
…..
Description des
données
Référence matière,
Adresse de l'élève,
Nombre d'heures,
Nom de la classe,
Nom de l'élève,
Nom du professeur,
Valeur de la note,
Numéro de salle,
Prénom de l'élève
Elève
Classe
nomElève appartient
nomClasse
prénom élève
numéroSalle
adresseElève * 1
0..*
*
Elève/Matière 1..* * Classe/Matière

ValeurNote NombreDheures
Matière
référenceMatière
nomProfesseur

Cours UML

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours UML

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre 1 - Introduction

Selon Grady Booch, la complexité est une caractéristique

Ces contraintes forment un

Les logiciels doivent parfois traiter (en interne) des

Ce traitement interne, toujours plus complexe, auquel vient

Des industries comme le bâtiment peuvent utiliser les

Un industriel comme Eiffage peut construire un pont mixte

L'industrie du logiciel possède moins de normes, les

La modélisation du réel, qui est

Cette discrétisation introduit une erreur artificielle qui doit

L'état du modèle discret est la combinaison des états des

La gestion progressive de la complexité

Les premiers programmes, écrits en langage machine,

La gestion progressive de la complexité

Lorsque le nombre d'architectures différentes a augmenté, un

La gestion progressive de la complexité

La complexité croissante des

La gestion progressive de la complexité

Niklaus Wirth alla plus loin en considérant les programmes

Limites de la programmation structurée

Le coût du matériel informatique a fortement décrût et ce

Limites de la programmation structurée

Certains besoins concernent la création de logiciels mais

Limites de la programmation structurée

La programmation structurée nécessite de faire des hypothèses

Une simple modification des exigences des utilisateurs ou une

Limites de la programmation structurée

Par exemple, en 1982, les postes américaines sont passés du

Limites de la programmation structurée

D'un côté des utilisateurs formulaient des exigences qui leur

Nous avons alors abouti à une explosion des délais et des

Une méthode comprend deux parties :

ÉPISTÉMOL., SC. Système physique, mathématique ou

Services rendus par l’objet

Cette encapsulation avait pour principal objectif de confiner la

L’adaptabilité du code est améliorée donc l’écriture du code et

D'autres concepts comme l'héritage et le polymorphisme ont

Ces objets graphiques ont des points Point

De même les méthodes permettant de

Soit des objets graphiques (le point, le cercle, le carré ...)

Nous créons un objet « abstrait » appelé objetGraphique

On créé un tableau d’objetGraphique et lorsqu’on implante

Point Cercle Carré

dessiner dessiner dessiner

Chaque acteur de la conception possède son propre point

Les niveaux d'abstraction perçus par chacun sont alors

L'objet à concevoir doit pouvoir être décrit en respectant

D’un point de vue pratique, ce principe d’abstraction est atteint

Les concepteurs peuvent donc manipuler un objet dans sa

Les premières méthodes d'analyse apparaissent au cours

Les méthodes d’analyse sont améliorées dans les années

Dans les années 90-98, le langage C++ connaît de plus en

Grady Booch et OOD

OOD signifie « Object Oriented Design ».

Ivar Jacobson et OOSE

OOSE signifie « Object Oriented Software Engineering ».

John Rumbaugh et OMT

OMT est l’acronyme de « Object Modeling Technique ».

Entre 1995 et 1997, nous assistons à une fusion progressive

représentation graphique commune des notions qui apparaissaient

Ces 3 méthodes ont donc été unifiée sous la bannière UML

UML devient une norme de l’OMG en 1997.

L’OMG (Object Management Group) est un organisme à but