Chapitre1 

: Introduction au langage de modélisation UML

UML : Unified Modeling Language

 Qu’apporte la modélisation objet ? plus grande indépendance du modèle

par rapport aux fonctionnalités demandé
 Des fonctionnalités peuvent être rajouté au modifié, le modèle objet ne
change pas.
 Plus proche du monde réel.

LES OBJECTIFS D’UML

 Représenter des systèmes entiers
 Etablir un couplage explicite entre les concepts et les artefacts exécutables
 Prendre en compte les facteurs de chaine
 Créer un langage de modélisation utilisable à la fois par les humains et les
machines
Recherche d’un langage commun
 Utilisable par toutes les méthodes
 Adapté à toutes les phases de développements
 Compatibles avec toutes les techniques de réalisation

UML UN LANGAGE
 UML n’est pas une méthode
 UML est un langage de modélisations d’objet
 UML a été adopte par tous les méthodes objets
 UML est dans le domaine publique, c’est une norme

UML UN LANGAGE POUR

- VISUALISER
 CHAQUE symbole graphique a sémantique
 Spécifier de manière précis et complète
 Construire
 Les classe
  Les relations SQL peuvent être généré automatique
 Documenter : les différents diagrammes, notées, contraintes,
exigence seront présenter dans un document

UML ET LES DOMAINES UTILISATIONS

- Système informations des entreprises
- Les banques et les services
- Transport
- Défense et aérospatial
- Application distribue par le web

Les trois éléments de bases en UML

1) Les blocks de bases pour construire
a) Les entités utilisées :
- Entité structurelle
- Entité de comportement
- Entité de regroupement
- Entité annotation
- La notion de relation
- Les diagrammes
2) Les règles à observer pour utiliser les blocks de bases

- Règles sémantique
- Règles de présentation
3) Les mécanismes communs

- Spécification
- Présentation
- Extension des modelés
4) Les entites structurelles
 chien
Race

Age

Couleur
Aboyer () Comparable
Mordre () INTERFACE
Obéir ()

CLASSE

Emprunte
Observateur
Cas d’utilisateur
Collaboration

producteur Noyau

Suspend () Serveur
Run()

Classe active composant nœud

Les entités de comportement

0
appel
emprunté Accès BD

message paquetage
Etat
 Dépendance

Association

Héritage
Réalisation
 Les neufs diagrammes en UML
- Cas utilisation :
 Diagramme objet

diagramme

Etats activité
Classe déploie
Cas d’
s Transitions ment
Utilisati
on
Séquence Collabora
s tion
Objets Com
posa
nt

Point de vue des cas utilisation :

- Vue du système par utilisateur finaux

- Regroupe le comporte système selon :
 Priorité (critique
 Option disponible
 Couverture de l’architecture
 Autre ouverture tactique et contrainte

Point de vue logique

- Décomposition oriente objet

- Décomposition et classes
- Connexion par héritage et association,
- Accent sur l’attraction
- L’encapsulation, l’uniformité
- Réalisations des scenarios de cas utilisations

Décomposition en tache et processus

Information sur les caractéristiques suivants :
- Intégrité et performance
- Contrôle
Point de vue implantation :
- Décomposition en module et niveau
- Regroupement de niveau en paquetage
- Organise des sous-systèmes en niveau :
 Réduis le couplage et la visibilité
 Augmenter la robustes
Information sur les caractéristiques suivant :
 Facilite de développement
 Potentiel de réutilisations
 Gestion de configuration
Point de vue déploiements :
- Décomposition en nœud exécution
- Rôle de nœud
- Inter connectivité, topologie
- Infor0mation sur les caractéristiques suivantes :
 Performance, disponibilité
 Installation, maintenance

TROIS COMPOSANTS PRINCIPALE D’UNE MODELISATION :

 Aspect dynamique :
Modèle Fonctionnel
Diagrammes d’interaction
Que fait le système
(séquence ,collaboration ,d’état-
Transitions et d’activités Aspect fonctionnel :
Diagrammes des cas d’utilisation
Séquencement des actions dans
Dans le système

Modèle structure (objet)

Modèle temporel Sur quoi le système agit

Aspect statique :
Diagramme de classes et d’objets

PHASE DE MODELISATION
TOUT commence par le cahier de charge
1) Expression des besoins
S’accorder ce qui doit être fait dans le système
2) ANALYSE
COMPRENDRE les besoins et les décrire dans le système
3) LA CONCEPTION

S’accorder de la manière donc le système doit être construire

4) IMPLEMENTATION
 Codage du résultat de la conception
7) le test
Le système est du conforme au cahier de charge

Rôle des expressions des besoins

- Permet une meilleure compréhension du système
- Comprendre est structure les besoins du client (clarifier, filtrer et
organise les besoins, ne pas chercher les hostilités)
- Une fois identifier et structuré ses besoins :
 Définir le contour du système a modéliser
 Permettre identifier les fonctionnalités principal(critique) du
système
Expressions des besoins
- Comprendre le contexte du système en définissant un modèle du
modèle et du métier
- Recenser les besoins fonctionnels et les définir par de cas d’utilisation
- Note les contraintes, besoins non fonctionnelle

Exigence non fonctionnelle

- Contrainte de concurrence
- Contrainte de temps de réponses
- Contrainte de distributions
- Contrainte de performances
- Contrainte de répartitions
ANALYSE
- Le but de l’analyse est de traduit dans un langage proche de
celui de l’informaticiens les modèles exprimaient dans
l’expression des besoins
 - Cependant pour rester compréhensible par les clients ou
utilisateur, ils interviennent que les entités du domaines
(métiers) considères.
- Elle sert interface avec l’expression des besoins, au dialogue
au contrat des utilisateurs
- L’analyse doit servir de support de la conception,
l’implémentation et la maintenance
NOTATION GRAPHIQUE
Le but :
- modéliser les objets, les relations entre objets, les interactions avec
le système
- servir de support de communication entre analyse, le client et les
utilisateurs
CHAPITRE 2 : : le diagramme des cas d’utilisation

Ce que doit faire le système sans spécifié comment il le fait.

BUT
Les cas d’utilisation représentent les fonctionnalités que le système
doit savoir faire. Chaque cas d’utilisation peut être complète par un
ensemble itération.
successives d’une entité en dehors du système (utilisateurs)

SYSTEME

Les cas d’utilisation permettent :

- De connaitre le comportement du système sans spécifier
comment se comporte le système
- Définir les limites précises du système
- AU DEVELOPPEURS DE BIEN COMMPRENDRE L’ATTENTE DES
UTILISATEURS
- Les instruments de texte et validation du système encours et
en fin de construction
MODELE DES CAS D’UTILISATION

- Un diagramme de cas d’utilisation définir :

 Le système
 Les acteurs
  Les cas d’utilisation
 Les liens entre acteurs et cas d’utilisation
- Un modelé de cas d’utilisation se définir par :
 Des diagrammes de cas d’utilisation
 Une description textuelle des scenarios d’utilisation
 Une description de ces scénarios :
 Les diagrammes de séquences
 Les diagrammes de collaborations

LES ACTEURS

UN ACTEUR représente une personne ou un périphérique qui joue un

rôle(interagir) avec le système.
- Relation entre acteur
CAHIER DE CHARGE : GESTION DE BIBLIOTHEQUE
- Un gérant de bibliothèque désire automatiser la gestion des
prêts
- Il commande un logiciel permettant au utilisateur de
connaitre les livres pressants dans réserve jusqu’à deux,
adhérent peut connaitre la liste de livres qu’il a emprunté

- L’adhèrent possède un mot de passe qui lui est données à

son inscription
- L’emprunt est toujours réalisé par les employeurs qui
travaille à la bibliothèque après avoir identifier l’emprunter
ils savent si le prêt est possible (nombre max de prêt = 5), et
si la priorité (il est celui qui à réserve le libre)
- Ce sont des employées qui mettent en bibliothèque les livres
rendues et les nouveaux livres.il est possible de connaitre
l’ensemble de prêt réaliser dans la bibliothèque
 Abonne

Bibliothèque

Administrateur
 LES CAS D’UTILISATION

- Un cas d’utilisation est un moyen de représenter les

différentes possibilités d’étudier un système
- Il exprime toujours une suite interaction entre un acteur et
une application
- Il définir une fonctionnalité utilisable par un acteur

ORGANISATION DES USES CASE : INCLUDE

La relation include précis un cas utilisation contient le comportement
définir dans un nœud de cas d’utilisation
- Cette relation permet de mettre en commun des
comportement humain a plusieurs cas utilisation

<<include>>
Emprunter

Identification
abonnee

<<include>>

Réserver
ORGANISATION DES USE CASE : EXTERNE
- UNE relation externe précis un cas d’utilisations peut dans
certain augmenter le comportement d’un autre cas
d’utilisation
- Une condition devra augmenter cette augmentation

Administrateur
<<extend>>

Regarder la
Réservation
liste des livres

ORGANISATION DES USE CASES : GENERALISATION

- CETTE relation [est un ]

Correction TD1
Modélisation d’un système : obtenir les cas d’utilisation

- Identifier les acteurs qui utilisent, gèrent, exécutent des fonctions

spécifiques
- Organiser des acteurs par relation des héritages
- Pour chaque acteur recherche les cas utilisateurs et de systèmes. En
particulière ceux qui modifie l’état du système ou qui entendre une
réponse du système
- Ne pas oublier les variétés interaction (cas erreur),(cas interdit)
- Organiser interaction par héritage, par extension, par utilisation

Exercice :
ABC
ACD
ABCDE

LE SYSTEME

GESTION
 Bibliothèque

Connaitre les livres

emprunts

Reserver un livre

Extension point avant

la reservation
identificateur

Connaitre les livres

presents

Ajouter de
nouveaux livres
Identiication par
carte

Identification
Remetrre un livre par mot de
passe

Réaliser un emprunt

La description d’un cas utilisation se fait par des scénarios qui définit
la suite logique des interactions qui définit ce cas
- On peut définir des scénarios simples ou des scénarios plus
détailler faisant intervenir les variantes, les cas erreur etc.
- Ces descriptions se fait ne manière simple par un texte
compréhensible par les personnes de domaine de
l’application
- Elle précis ce que fait l’acteur ce que fait le système
- La description détailler pourra préciser
 Le client se présente devant un terminal :
 (1) le système affiche un message accueil
 (2) le client choisit l’opération réservation parmi les
différentes opérations proposées
 (3) le système lui demande de s’authentifier
 (4) le client donne son identification (nom, mot de passe)
 (5) le système lui demande de choisir un livre
 (6) le client précise le livre qu’il désire.
 (7) le système lui précise si un exemplaire du livre lui réserve

Réservation d’un livre Description detaillee

Pré –condition : le client doit être inscrit à la bibliothèque

Le client ne doit pas avoir atteint le nombre maximum de
réservation
Un exemplaire du livre doit être enregistre

Post-condition ( si l’operation s’est bien deroulee)

Le client a une

Réservation d’un livre Description detaillee

CAS
NORMAL
1.(1) le système affiche un message d’accuiel sur le terminal avec un choix
d’operation
2. (2) le client choisit l’operation reservation parmi les differents operations
proposees
3. (3) le système lui demande de s’authentifier
4. (4) le client donne son identification(nom,mot de passe)
5.(5) le système demande le titre du livre en donnant la possibilite de choix
dans une liste
6.(6) le client precise le livre qu’il desire
7.(7) le système lui precisqu’un exemplaire du livre est reserve
Variante 1

En (6) le client demande à connaitre les livres presents

DIAGRAMME DE SEQUENCE
- Suite aux diagrammes textuels le scenario peut etre representer en
utilisant un diegramme
- Connaitre le son (acteur vers systemes ,ou le contraire
CHAPITRE 3 : CONCEPT OBJET DE DIAGRAMME DE CLASSE

LA CLASSE :
CLASSE

Personne
Nom
Age
Mot de passe
CLASSE
Nbre livres empruntes
ChangerAdresse ()
DonnerAge ()
DonnerAdresse ()
Verifiermotdepasse () PERSONNE

Personne
Nom :string
Age :integer
Adresse :string
Mot de passe :string
Nbre livres empruntes :integer
« constructeur »
Personne(nom :string,age :integer
Adresse:string,mot de passe:string)
« caracteristique »
Changeradresse(string)
« authentification »
Verifiermotdepasse(string) :boolean
Changermotdepasse(old.string,new :strin
g
DonnerAdresse ()
Verifiermotdepasse ()
 INSTANCE DE
LA CLASSE ET L’OBJET
Un objet
CLASSE
Personne

Personne
Nom Nom=Alain Dupont
Prénom Age=45
Adresse Adresse=France
Attribut
Mot de passe Mot de passe=4RSA67
Nbre livre emprunte Nbre livres
Change Adresse () empruntes=4
Obtenir Age ()
Comportement
Verifiermotdepasse()
Personne
André roue
25
France
6FT34
0

Personne

PROTECTION DES ATTRIBUT ET DES OPERATIONS : PRINCIPE DE

L’ENCAPSULATION
Peut-on accéder à toute les attributs ou à toute les méthodes d’un objet ? non
La classe définir ce qui est accessible c’est le principe de l’encapsulation.
Exemple : on peut utiliser une voiture à travers son volant ,son frein, son
accélérateur
- L’accès au carburateur est impossible sauf par les méthodes qui le
font de manière cohérent (méthode acceler de l’accélérateur)
-
PROTECTION DES ATTRIBUT ET DES OPERATIONS : usage et notation
 Les attributs sont généralement inaccessible(secret) ils sont alors
qualifier de :
-protected (notation UML : #)
-
Leur lecture ou modification n’est possible à travers certains opérations (les
accesseurs)
Les opérations sont en général publiques elles sont alors qualifier de public
(notation UML : +)

PROTECTION DES ATTRIBUT ET DES OPERATIONS : notation UML

CLASSE

+ : attribut
# : attribut protected
- :attribut Privat

personne
- Nom
- Age
- adresse
# changerAdresse ()
# obternirue ()
+ obtenirage()
+ :operation public
# :operation protected
- :operation private

La reification
 marriage
* Epoux
Epouse
date
Chien
Semarier ()
Race
Entité physique
Évènement Divorcer()
Age
couleur

Aboyer ()
Mordre ()
Obeir()

Relation
appartenir Cours
Propriétaire Professeur
Date Salle
Voiture Situation Élèves
Vendre () Assister ()
Acheter () Quitter()
Prêter ()

Le modèle du type abstraire pile

Pile Entier
- Contenu
- -hauteur
- Taille
+empiler (valeur : integer)
+depile ()
+elementsommet () : integer
+estvide : boolean

La surcharge et le polymorphisme
Personne
nom :string
age: integer
adresse :string

ChangerAdresses(sonadresse
: string)
Obternirage (): entire
Obteniradresse():string
fichier
Nom :string
Taille :integer
Proprietaire :string
Imprimer
(nombreligne :entier)

Classe paramétrage

Pile

+pile
+empiler(valeur :element)
+depiler() :element
+nombreelements() :integer
+estpleine() :boolean
+estvide() :boolean

Element
Taille :integer

Return
Nombreelements()==taille
Livre
titre

Nom d’associatio
Sens de lecture du
nom d’association
auteur
Multiplicité nom

Personne
Société
Nom
Nom Adresse
adresse garde
Lien entre objet

Emploie
Constructeur :sociét Contremaitre :personne
é Nom=Dupont
Nom : Peugeot Employeur employé
Adresse :Sochaux
CLASSE DES ASSOCIATIONS

Personne
Société Emploie Nom
Nom Adresse
Adresse Garde
0.1 * Salaire

Emploi
Grade
salaire

CLASSE D’ASSOCIATION
 Cours

cours

salle
enseignat

eleve

AGREGATION
C’est une association qui exprime un couplage fort lie à une relation de
subordination , elle est asymétrique du type ensemble\élément

polygone
{ordonnee} point
Composition : AGREGATION FORTE
La composition est une agrégation forte qui les cycles de vie entre compose
(ensemble) et les composants (éléments)
subordination , elle est asymétrique du type ensemble\élément

BUT
- Créer des sous titres (sous classes). Une sous classe sera de même de
la classe qu’elles héritent (super classes)
Ceci permet de mettre en œuvre la liaison dynamique et le polymorphisme
PRINCIPE
un objet d’une classe donnée pourtant toujours faire référence à des objets de
ses sous classe (polymorphisme)
Devoir :
Recherche de thème de diagramme :
- Etat
- Collaboration
- Etat transition
- Activité