UML T. Libourel Autour des objets et du formalisme UML T. Libourel [email protected]

UML T. Libourel

Autour des objetsAutour des objetset et

du formalisme UMLdu formalisme UML

T. Libourel

[email protected]

UML T. Libourel

PLANPLAN

Introduction– Pourquoi des méthodes ?

– Atouts

– Historique

Concepts objet et formalisme UML– Concepts généraux

– Modèle fonctionnel

– Modèle structurel

– Modèle dynamique

Discussion

UML T. Libourel

PLANPLAN


– Atouts

– Historique





Discussion

UML T. Libourel

• Besoin de méthodologie

Entreprise

Outils Informatiques

Pourquoi des méthodes ?Pourquoi des méthodes ?

Rien ne dicte a priori comment modéliserun système de manière pertinente

UML T. Libourel


Démarche reproductible pour obtenir des

résultats fiables– Construire des modèles à partir d'éléments (concepts)

– Possibilité de représenter à partir de formalismes

– Mise en œuvre

UML T. Libourel


Démarche qui distingue les étapes du

développement dans le cycle de vie du

logiciel – Modularité, réduction de la complexité, réutilisabilité,

abstraction

– Un formalisme de représentation qui facilite la

communication, l’organisation et la vérification

– Production de documents (modèles) qui facilitent les retours

sur conception et l’évolution des applications

UML T. Libourel

AtoutsAtouts

Universalité de l’Objetla notion d’objet, plus proche du monde réel, est compréhensible

par tous et facilite la communication entre tous les intervenants

d’un projet.

Omniprésence technique de l’Objetdans les langages de programmation, les bases de données, les

interfaces graphiques, ... et les méthodes d’analyse et de

conception.

UML T. Libourel

HistoriqueHistorique

Plus de 50 méthodes objet sont apparues durant la période 90-95: Booch, Classe-Relation, OMT, OOA, OOD, OOM, OOSE...

– Grady Booch : OOD, BOOCH'93 (Société RATIONAL) • 1987 pour ADA,

• 1990 générale

– James Rumbaugh : OMT 1990-1991 • "Object Modeling Techniques"

• General Electric

– Ivar Jacobson : Objectory 1992, • Ericsson,

• suite de OOSE "Object Oriented Software Engineering"

Regroupement de BOOCH-OMT puis Objectory

UML T. Libourel

http://www.omg.org

HistoriqueHistorique

Recherche d’un langage commun unique utilisable

par toute méthode objet– dans toutes les phases du cycle de vie,

– compatible avec les techniques de réalisation actuelles.

UML (Unified Modeling Language)

UML T. Libourel

PLANPLAN


– Atouts

– Historique





Discussion

UML T. Libourel

Concepts générauxConcepts généraux

Un modèle est une représentation abstraite d’une réalité,

Il fournit une image simplifiée du monde réel.

Il permet – de comprendre et visualiser (en réduisant la complexité)

– de communiquer (à partir d ’un « langage » commun à travers un nombre restreint de concepts)

– de valider (contrôle de la cohérence, simuler, tester …)

UML T. Libourel

Les modèles d'UML

modèle des classes statique

modèle des états dynamique des objets

modèle des cas d'utilisation besoins utilisateur

modèle d'interaction scénarios et flots de messages

modèle de réalisation unités de travail

modèle de déploiement répartition des processus


UML T. Libourel

La perception des modèles Les vues graphiques (diagrammes )

diagrammes de classesdiagrammes d'objets

diagrammes de séquencesdiagrammes de collaboration

diagrammes états-transitionsdiagrammes d'activités

diagrammes de cas d'utilisationdiagrammes de composantsdiagrammes de déploiement


UML T. Libourel

VueCas d ’utilisation

Vue structurelle

Vue Architecture

(déploiement)

Vue dynamique

Définir une architecture ……. divers points de vue sur le système

Vue Implémentation

<------- Logique Physique ------>


UML T. Libourel

Analyse

Tests - Maintenance Réalisation

Même formalisme lors de toutes les phases du cycle de vie

Conception

Processus incrémental


UML T. Libourel

Modèle fonctionnelModèle fonctionnel

Modèles descriptifs du point de vue des utilisateurs

Scénarios fonctionnels

Focus

La manière d’utiliser le système

Les « USE CASE »

UML T. Libourel

Deux concepts

Acteur

Use case

Acteur (rôle 1)

Acteur (rôle 2)


UML T. Libourel

Acteur (rôle 1)

Acteur (rôle 2)

« use »« extend »


Les cas d’utilisation peuvent être liés par

des relations– d’utilisation « use » (décomposition)

– de raffinement « extend » (traitement d’exceptions)

UML T. Libourel


Délimiter le système

- ce qui est extérieur et qui communique avec le système

- ce qui est interne au système

Définir les fonctionnalités du système du point de

vue des utilisateurs

Donner une description cohérente de toutes les

vues que l ’on peut avoir du système

UML T. Libourel

En UML, le modèle structurel ou statique est décrit à

l'aide de deux sortes de diagrammes

– Diagrammes de classes

• description de tout ou d'une partie du système d'une

manière abstraite, en termes de classes, de structure et

d'associations.

– Diagrammes d'objets

• description d'exemples de configuration de tout ou partie

du système, en termes d'objets, de valeurs et de liens.

Modèle structurelModèle structurel

UML T. Libourel

Objets du monde réel Objets informatiques

État Internecaché

Comportementvisible

Les objets


UML T. Libourel

Comportement influe sur l'étatEtat reflète les comportements passés

Objet

Etat évolue au cours du temps

Comportement actions et réactions

Identité essence


UML T. Libourel

Palmier3

Palmier2

Site1

Site2

Palmier1

: Palmier

: Site

Deux objetsou instances


UML T. Libourel

Première abstraction

Une classe peut être vue

– la description en intension d'un groupe d'objets

• ayant même structure (même ensemble d'attributs),

• ayant même comportement (mêmes opérations),

• ayant une sémantique commune.

– la « génitrice » des objets ou instances

– le « conteneur » (extension) de toutes ses instances


UML T. Libourel

Classe

Attributs (propriétés)

Palmier

type : stringtaille : float

palmier1 :Palmier

type =« dattier »taille= 2

Instance

Valeurs d'attributs (État)

« Est-instance-de »


UML T. Libourel

Palmier

type : stringtaille : float

croitre()arroser (qtte : float)

Opérations et méthodes

Méthodes

Implémentations

nom de la classe

attributs

opérations


UML T. Libourel

Représentation graphique : « les boites » (à

différents niveaux de détail)

Les types sont optionnels et ne figent pas les

choix d'implémentation

La description des opérations sera complétée

dans les phases de conception

NomClasse2nomAttribut1 : type1nomAttribut2 : type2

nomOpération1()nomOpération2()

NomClasse1


UML T. Libourel

Un objet est instance d'une (seule) classe :– il se conforme à la description que celle-ci fournit,

– il admet une valeur pour chaque attribut déclaré à son attention dans la classe,

– il est possible de lui appliquer toute opération définie à son attention dans la classe.

Tout objet admet une identité qui le distingue pleinement des autres objets :

– Identité fixée par le système (oid) mais il peut être nommé et être référencé par un nom


UML T. Libourel

Association / Lien (analogie Classe / Instance)

Palmier Site

type nom

a-pour-localisation

Association

: Palmiertype=dattier

:Sitenom = Djerba

a-pour-localisation

Lien


UML T. Libourel

Association en général binaire (degré = 2) mais ..

Palmier Sitea-pour-localisation

Dispositif-Arrosage

soumit

nom d'association

association binaire association ternaire


UML T. Libourel

Multiplicité et rôles d'une association

Palmier Site

typetaille

nomLatLong

A-pour-localisation

comporte

plantation lieu

englobant

englobé

eng

lobe

* 1..*

1..*

0..1


UML T. Libourel

exactement 1

Classe1

0..1

Classe0..*

Classe1..*

Classe2..4

Classe2,4

au plus 1

aucun, 1 ou plusieurs (défaut)

au moins 1

de 2 à 4

2 ou 4

Multiplicité

Classe


UML T. Libourel

Palmier Site

type nom

Gestion

A pour localisation

type

Personne

1..*1..*

1..*


Classe association

gestionnaire

UML T. Libourel

D ’autres « abstractions »


associations particulières – (composition / agrégation)

spécialisation / généralisation

UML T. Libourel

Association particulière Tout /partie

Couronne Stipe Racine

Feuille

Palmier

0..2

Composition


0..*

Régime

Inflorescence0..1

0..1

UML T. Libourel

Agrégation

Sémantique Collection/Élément

Arbre

Site

Forêt1

1..n

Région

Pays

1

1..n

1

1..n


UML T. Libourel

Composition / Agrégation

Contraintes

- Exclusivité / Partage

- Dépendance / Indépendance

Propagation / Diffusion


UML T. Libourel

Généralisation / Spécialisation

Mécanismes d’inférences intellectuelles de

caractéristiques– Soit on affine (spécialisation)

– Soit on abstrait (généralisation)

Sémantique– Point de vue ensembliste

– Point de vue logique


UML T. Libourel

Personne

nom adresse

Chercheur

grade adresse Exposer()

{disjoint}

Gestionnaire

numadresse



UML T. Libourel

Pompe Échangeur Réservoir

Pompe Cent. Pompe Imm. Réservoir Press.

Équipement

...

Type d'équipement

...

Type de pompe

...

Type de réservoir



UML T. Libourel

Véhicule terrestre Véhicule aquatique

Auto Véhicule amphibie Bateau

Véhicule


Généralisation / Spécialisation multiple

UML T. Libourel

Composition/Agrégation ou généralisation ?


Agrégation – lien entre instances

– un arbre d'agrégation est composé d'objets qui sont parties d'un objet composite

Généralisation – lien entre classes

UML T. Libourel

Une sous-classe “hérite” des descriptions de sa super-classe :

– les déclarations d'attributs,

– les définitions d'opérations,

– les associations définies sur la super-classe,

– les contraintes (on en parle plus tard).

Une sous-classe peut redéfinir de façon plus spécialisée une partie ou la totalité de la description « héritée ».



UML T. Libourel

Les contraintes

Les contraintes sont des prédicats, pouvant porter sur plusieurs éléments du modèle statique, qui doivent être vérifiés à tout instant.

Les contraintes permettent de rendre compte de détails à un niveau de granularité très fin dans un diagramme de classe. Elles peuvent exprimer des conditions ou des restrictions.

En UML, les contraintes sont exprimées sous forme textuelle, entre accolades et de préférence en OCL (Object Constraint Language).

Les contraintes sont héritées.


UML T. Libourel

Les contraintes : Exemples de contraintes sur associations

SOL

Strates

1..*

Personne Comitépréside *1

membreDe**

{subset}

{ordered} contrainte sur extrémité

d'association

contrainte entre 2 associations


UML T. Libourel

actif : Real {value 0}passif : Real

Les contraintes : Exemple de contraintes à différents niveaux

contrainte sur classe

Personne

chef

subordonné

<dirige

Société

{ actif = passif }

{ Personne.employeur = Personne.chef.employeur }

employeur

* 1..* 0..10..1

contrainte sur attribut

contrainte sur 2 associations


UML T. Libourel


Classes abstraites

Une classe abstraite est une classe non instanciable, c'est à dire qu'elle

n'admet pas d'instances directes.

La factorisation optimale des propriétés communes à plusieurs classes par

généralisation nécessite le plus souvent l'utilisation de classes abstraites.

Une opération abstraite est une opération n'admettant pas d'implémentation

Les opérations abstraites pour mettre en œuvre le polymorphisme.

Opérations abstraites

Patrons

UML T. Libourel

Décrit les interactions entre objets et les changements au cours du temps

- Aspects temporels, comportementaux : Contrôle

- Stimuli des objets et leurs réponses

Modèle Modèle dynamiquedynamique

UML T. Libourel

Modèle dynamiqueModèle dynamique

diagrammes de collaboration

diagrammes de séquences

diagrammes états-transitions

diagrammes d'activités (non traités)

UML T. Libourel

La communication

Systèmes informatiques : Société d'objets travaillant en synergie pour réaliser les fonctions de l'application

Communication

Client

Serveur

message

Acteur


UML T. Libourel

constructeursdestructeurs

sélecteursmodificateursitérateurs

Types Synchronisation

simple

synchrone

dérobant

minuté

asynchrone

Les messages


UML T. Libourel

Diagramme de collaboration

B

C

message

A

1: M12: M2

3: M3

4: M4

6: M6

5: M5


UML T. Libourel

Diagramme de séquence

B CA

M1

M2

M3

M4

M6M5


UML T. Libourel

La ligne de vie

« create »

Création par le message «create»

Activation de l’objet qui exécute une opération op

Destruction par un autre objet

:C1

« destroy »

op


UML T. Libourel

Événement et État


État d'un objet– valeurs de ses attributs et de ses liens

– au cours du temps un objet peut changer d'état

Événement– stimuli d'un objet vers un autre objet

UML T. Libourel


:Palmier :Feuille :Inflorescence :Régime

tem

ps

UML T. Libourel

État 1faire : Activité 1

Événement 1 [Cond1] / Action1 (attrib) État 2

...

Diagramme d ’état

État d'un objet

valeurs de ses attributs et de ses liens au cours du temps un objet peut changer d'état

Événement

stimuli d'un objet vers un autre objet


UML T. Libourel


Avec inflorescence

création

e1

Avec régime

e2

[C]

Créé Avec feuille

UML T. Libourel

Les packages

Modèle d’implémentationModèle d’implémentation

Un package ou sous-système est un regroupement logique de classes, associations, contraintes ..

Un sous-système est généralement défini par les services qu’il rend

Les liens entre sous-systèmes sont des liens de dépendance

Les « packages » servent à structurer une application Ils sont utilisés dans certains LPO (Java) ce qui assure une

bonne « traçabilité » de l ’analyse à l ’implémentation

UML T. Libourel

Les packages

Classes avec fort couplage « sémantique »

Liens de dépendance

Modèle Modèle d’implémentationd’implémentation

UML T. Libourel

PLANPLAN


– Atouts

– Historique





Discussion

UML T. Libourel

DiscussionDiscussion

L'approche mathématique vs approche objet

– Représentation de types, de variables et de fonctions.

– Culture scientifique

Traitement du « continu »

– Simulations.

– Vers les agents ?

Les points « épineux »

UML T. Libourel

Des bienfaits de l ’encapsulation ….

Proposer un service et réagir aux messages

Opérations

Données

MessagesEncapsulation


UML T. Libourel

La méta-modélisation

Meta-Meta Modèle

Meta-Modèle

Modèle

Objets utilisateur

Meta-Class, Meta-Attribut, etc

Class, Attribut, etc

Palmier, Site, etc

A120, 50, etc

Langage pour spécifiertout métamodèle

Langage pour spécifierun modèle

Langage pour spécifierun domaine d’information

Définition spécifiqued’un domaine


UML T. Libourel

UML et Merise UML et Merise

UML n ’est pas une méthode comme Merise

– Ne dit rien sur le processus de mise en œuvre ; chaque

société peut proposer son processus:

• RUP « Rational Unified Process » (Rational)

• EAI (Valtech)

• MEGA Process (MEGA)

UML cible toute application informatique, alors que Merise cible les SI


UML T. Libourel

Les outilsLes outils

Langages JAVA, C++, ..

Modèles UML, ...AGL

Environnement de développement:

Visual Age (IBM), Delphi, Visual J++, J Builder, VisualWorks,

Objets

SGBD-Rou

SGBD-OO

re-engineering

Squelette de code

Schéma de la base relationnelle ou objet


UML T. Libourel

Outil de dialogue :– langage de représentation des modèles

– graphique et simple

– formel et normalisé (OMG)

Outil ouvert– Indépendant des langages de programmation

– Pas un processus d'élaboration des modèles

– Adaptable (stéréotype)


UML T. Libourel

Livres UML (1)Livres UML (1)

Booch Grady, Rumbaugh James, and Jacobson Ivar, The

Unified Modeling Language User Guide, 0-201-57168-4,

Addison Wesley, Fall 1998, traduit : Le guide de l'utilisateur

UML, Eyrolles 2000.

Jacobson Ivar, Booch Grady and Rumbaugh James, The

Unified Software Development Process, 0-201-57169-2, Addison

Wesley, Fall 1998, traduit : Le processus unifié de

développement logiciel, Eyrolles 2000.

Rumbaugh James, Jacobson Ivar, and Booch Grady, The

Unified Modeling Language Reference Manual, 0-201-30998-X,

Addison Wesley, Fall 1998

UML T. Libourel

Livres UML (2)Livres UML (2)

– Conallen Jim, Concevoir des applications Web avec UML, Eyrolles , 2000.

– Douglass Bruce Powell, Doing Hard Time : Developping Real-Time Systems with UML, Addison Wesley, 1999.

– Eriksson , UML Toolkit, Wiley, 1997

– Fowler Martin, UML Distilled, Applying the Standard Object Modeling Language Addison Wesley, 1997

– Kettany N et al, De Merise à UML,Eyrolles , 1998

– Larman Craig, Applying UML and Patterns,Prentice Hall, 1998

– Lee R, Tepfenhart W, UML et C++, Simon et Schuste , 1998

– Lopez N, Intégrer UML dans vos projets, Eyrolles, 1997

– Muller Pierre-Alain, Modélisation objet avec UML, Eyrolles, 1997

– Roques Pascal, Vallée Franck, UML en action, Eyrolles, 2000.

– Roques Pascal, UML par la pratique, Eyrolles, 2001.

– Schmuller Joseph, Teach Yourself UML in 24 Hours, Sams Publishing, 1999

– Texel Williams, Uses cases combined with Booch/OMT/UML, Prentice Hall, 1998

Documents

UML T. Libourel Autour des objets et du formalisme UML T. Libourel [email protected]