Systèmes d’Information I

Plan du cours

1) L’Approche Objet

2) Le Langage UML

3) Mise en œuvre d’UML dans une démarche UP

L’approche orientée objet

Principe

– Un logiciel est une collection d’objet dissociés, et identifiés,

définis par des propriétés.

– La fonctionnalité du logiciel émerge de l’interaction entre les

différents objets qui le constituent.

– Dans un logiciel, on rapproche les données et leurs

traitements associés au sein d’un unique objet.
L’approche orientée objet
Caractéristiques d’un objet

1) Type de l’objet

– Un objet est une occurrence d’un type abstrait

– Un objet est une instance de classe
– La classe est un type de données abstrait, caractérisé par
des propriétés (attributs et méthodes) communes à des
objets et permettent de créer des objets de même type.
– On peut assimiler une classe à un type, et un objet à
une variable.
L’approche orientée objet
Caractéristiques d’un objet

2) L’identité

– Tout objet possède une identité unique qui permet de le

distinguer des autres objets.
– On construit cette identité grâce à un identifiant.

Exemple:
Un produit est repéré par un code
Une voiture est repérée par un numéro de série
L’approche orientée objet
Caractéristiques d’un objet

3) Les attributs

– Il s’agit des données caractérisant l’objet.

– Ce sont des variables stockant des informations sur l’état
de l’objet.

Exemple:
Un produit a un prix unitaire
Une voiture a une marque
L’approche orientée objet
Caractéristiques d’un objet

4) Les méthodes

– Les méthodes d’un objet caractérisent son comportement.

– C’est l’ensemble des actions (opérations) qui permettent
de faire réagir l’objet aux sollicitation extérieures ou d’agir
sur les autres objets.
– Les opérations sont étroitement liés aux attributs: leurs
actions peuvent dépendre des valeurs des attributs, ou
bien les modifier.
L’approche orientée objet
Caractéristiques d’un objet

3) Les méthodes

Exemple:
Acquisition d’un nouveau produit
Établissement d’une facture
Consulter la fiche descriptive d’un livre
L’approche orientée objet
Concepts importants
• Encapsulation: Masquer l’implémentation d’un objet en
définissant une interface.

• Héritage: Mécanisme de transmission des propriétés d’une classe

(ses attributs et méthodes) vers une sous-classe.

• Polymorphisme: La faculté d’une même opération de s’exécuter

différemment suivant le contexte de la classe où elle se trouve.

• Agrégation: Une relation entre deux classes, spécifiant que les

objets d’une classe sont des composants de l’autres classe.
L’approche orientée objet
Inconvénients

• Approche non intuitive:

Fait appel au raisonnement plutôt qu’au sens
(connaissances spontanées de la vérité).

• Rigueur dans l’application des concepts objets:

Vocabulaire précis (risques d’ambiguïtés,
d’incompréhensions).
L’approche orientée objet
Solutions

• Emploi d’un langage de modélisation objet:

Pour exprimer les concepts objets, parler un langage
commun et faciliter l’analyse.

• Adoption d’une démarche d’analyse et de conception

objet:
Définir des vues qui couvrent tous les aspects d’un système
avec des concepts objet et penser objet dés le début.
Le langage UML
Emergence: Historique des méthodes d’analyse

• Les premières méthodes d’analyse (années 70)

Découpe cartésienne (fonctionnelle et hiérarchique) d’un système
• L’approche systémique (années 80)
Modélisation des données+ Modélisation des traitements (Merise)
• Emergence des méthodes objet (1990-1995)
Rapprocher les données et les traitements (Plus de 50 méthodes durant cette
période)
• Les premiers consensus (1995)
OMT (James Rumbaugh): Vues statiques, dynamiques et fonctionnelles
OOD (Grady Booch): Vues logiques et physiques
OOSE (Ivar Jacobson): Couvre tout le cycle de développement (analyse des besoins)
• L’unification et la normalisation des méthodes (1995-1997)
Unified Modeling Language
Le langage UML
Emergence: Historique des méthodes d’analyse
Le langage UML: Unified Modeling Language

Caractéristiques

• UML n’est pas une méthode ou un processus

• Un langage de modélisation objet.
• Un langage graphique permettant de représenter et de
communiquer les différents aspects d’un SI.
• Un métalangage car il permet de construire le modèle
qui sera le langage du projet.
• C’est une norme qui s’impose aux technologie à objets.
• UML est un support de communication
Le langage UML
Points forts

UML est un langage formel et normalisé

• Gain de précision
• Gain de stabilité
• Utilisation d’outils

UML est un support de communication performant

• Il cadre l’analyse
• Il facilite la compréhension de représentations abstraites
complexes
• Langage universel
Le langage UML
Points faibles

• La mise en pratique d’UML nécessite un apprentissage

et passe par une période d’adaptation

• Le processus (non couvert par UML) est une autre clé

de la réussite d’un projet
Le langage UML
Diagrammes UML 2.0
Diagrammes structurels ou diagrammes statiques
(UML Structure)
• Diagramme de classes (Class diagram)
• Diagramme d’objets (Object diagram)
• Diagramme de composants (Component diagram)
• Diagramme de déploiement (Deployment diagram)
• Diagramme de paquetages (Package diagram)
• Diagramme de structures composites (Composite structure diagram)
Le langage UML
Diagrammes UML 2.0

Diagrammes comportementaux ou diagrammes

dynamiques (UML Behavior)
• Diagramme de cas d’utilisation (Use case diagram)
• Diagramme d’activités (Activity diagram)
• Diagramme d’états-transitions (State machine diagram)
• Diagrammes d’interaction (Interaction diagram)
o Diagramme de séquence (Sequence diagram)
o Diagramme de communication (Communication diagram)
o Diagramme global d’interaction (Interaction overview diagram)
o Diagramme de temps (Timing diagram)
Processus Unifié
Besoins de démarche

 Comment passer de l’expression des besoins au code de

l’application?
 Quelle est la séquence d’étapes à suivre?
 Quelle est la démarche de modélisation qui explicite et encadre
toutes les étapes du projet de développement?
Processus Unifié
Définition :
Le processus unifié est un processus de développement
logiciel; il regroupe les activités à mener pour transformer les
besoins d’un utilisateurs en système logiciel.

Le premier livre décrivant le processus unifié : Publié en 1999 par les auteurs
d’UML Ivar Jacobson, Grady Booch and James Rumbaugh: “The Unified
Software Development Process ”

Caractéristiques essentielles :

o Basé sur l’utilisation d’UML

o Piloté par les cas d’utilisation
o Centré sur l’architecture
o Itératif et incrémental
Processus Unifié
Etapes de la démarche

1) Identification des besoins :

Diagrammes de cas d’utilisation, de séquence système et de
communication système.

1) Analyse:
Diagrammes de classes, d’activités, et d’états-transitions.

1) Conception:
Diagrammes d’interaction, de déploiement, et de composants.

1) Implémentation:
Passage du modèle objet au modèle relationnel.
Phase 01:
Identification des besoins
Phase 01: Identification des besoins

Diagramme des cas d’utilisation

Un diagramme de cas d’utilisation définit les fonctionnalités du

système et les interactions entre le système et les acteurs du
monde extérieur qui utilisent ces fonctionnalités

Un diagramme de cas d’utilisation contient :

 Des acteurs

 Un ensemble de cas d’utilisation et

 Des associations entre les acteurs et les cas d’utilisation
Phase 01: Identification des besoins

Identification des acteurs

Un acteur est une entité externe au système qui interagit avec

une partie de celui-ci à travers des cas d’utilisation. Elle peut être
une personne physique ou morale, au autre système.

Notation :

Acteur

On distingue :
• Acteurs primaires : ceux sont les utilisateurs du système
• Acteurs secondaires : ceux qui contribuent au
fonctionnement du système
Phase 01: Identification des besoins

Identification des cas d’utilisation

Un cas d’utilisation permet de modéliser le comportement d’un

système du point de vue d’un acteur externe.
Il traduit comment un acteur externe souhaite utiliser le système

Notation : une ellipse

Exemple :
Établir une facture
Phase 01: Identification des besoins

Relation entre acteur et un cas d’utilisation

Dénote la participation d’un acteur à un cas d’utilisation.

Une seule relation est possible entre un acteur et un cas d ’utilisation

Notation : utilisation du stéréotype <<communicate>>

<<communicate>> Créer une commande

Commercial
Phase 01: Identification des besoins

Relation entre cas d’utilisation: Extension

• B est une partie alternative, optionnelle ou exceptionnelle de A

• Une instance de A engendre une instance de B et l’exécute sous
certaines conditions.
• B dépend de A.
• B n’existe pas sans A.

Notation :
Utilisation du stéréotype <<extend>>
<<extend>>
A B
Rechercher un produit Ajouter au panier
Phase 01: Identification des besoins

Relation entre cas d’utilisation: Inclusion

• B est sous-ensemble commun à plusieurs cas d’utilisation.

• Une instance de A va engendrer une instance de B et l’exécuter.
• A dépend de B.
• A n’existe pas sans B.

Notation :
Utilisation du stéréotype <<include>>

<<include>>
A B
Ajouter un S’authentifier
employé
Phase 01: Identification des besoins

Relation entre cas d’utilisation: Généralisation

• Le cas d’utilisation enfant est une spécialisation du cas

d’utilisation parent

Formalisme et exemple:

Informer le client
Cas d’utilisation parent

Informer le client par Email

Cas d’utilisation enfant

Informer le client par SMS
Phase 01: Identification des besoins

Relation entre acteurs: Généralisation

• Un acteur peut participer à des relations de généralisation avec

d’autres acteurs.
• L’acteur enfant sera capable de communiquer avec les mêmes
cas d’utilisation que l’acteur parent.

S’authentifier
Formalisme et exemple:

Utilisateur

Virement bancaire

Guichetier
Phase 01: Identification des besoins

Exemple de diagramme de CU:

Gestion des transactions bancaires
Retirer de
l’argent
<<include>>

Effectuer un <<include>>
Guichetier virement S’authentifier

<<extend>>

<<include>>

Vérifier solde <<include>>

Consulter
Consulter compte comptes
depuis Internet
Phase 01: Identification des besoins

Description d’un cas d’utilisation

Description textuelle (scénario):

Exemple : Cas d’utilisation : “ Retrait en espèce ” :

• Le guichetier saisit le n° de compte du client.

• L’application valide le compte auprès du système central.
• L’application demande le type d’opération au guichetier.
• Le guichetier sélectionne un retrait d’espèces de 5000 dzd.
• Le système “ guichetier ” interroge le système central pour s’assurer
que le compte est suffisamment approvisionné.
• Le système central effectue le débit du compte.
• Le système notifie au guichetier qu’il peut délivrer le montant demandé
Phase 01: Identification des besoins

Description d’un cas d’utilisation

Description par diagramme de séquence système

Exemple : Cas d’utilisation : “ Retrait en espèce ”

Saisie
compte Validation compte
Demande type
d’opération
Retrait liquide
(5000dzd) Vérification solde
compte
Autorisation Débit compte
délivrance
t Guichetier Système Système
guichet central
Phase 01: Identification des besoins

Description d’un cas d’utilisation

Description par diagramme de communication système

Exemple : Cas d’utilisation : “ Retrait en espèce ”

(6) Débit compte

(4) Retrait espèces Système

Guichetier (5000dzd) Central

(3) Demande (7) (5) vérification

type d’opération Autorisation solde compte
délivrance

(2) Validation compte

(1) Saisie compte Système
guichetier