Copyright SOFTEAM 2000 Page 1 Philippe Desfray – Laurent Fourmy

Copyright SOFTEAM 2000 Page 1

Philippe Desfray – Laurent Fourmy


UML : Les origines

1. La diversité des modèles de données et de traitement : par exemple, Entité association (Chen 1974), Machines à états fini, Automates de Harel, etc.

2. Les modèles à Objet réunissent ces premiers modèles (+70 en 1994, 30 réellement industriels)

3. Les leaders du marché : OMT, Booch, Jacobson fusionnent

4. Effort de l’OMG pour standardiser les méthodes objet : accent sur l’interopérabilité (1996)

5. L’OMG standardise UML 1.1 (1997)

6. L’OMG maintient UML (UML 1.3, UML 1.4)

7. L’OMG prévoit une révision majeure de UML (UML2.0 - 2002?)


The UML is a graphical language for– specifying– visualizing– constructing– documenting

the artifacts of software systems

UML – Définition(fournie dans les tutoriaux OMG)


UML Les bénéfices

• Une notation unique et standard :– Connue de tous

– Pour tous les domaines informatiques

– Exploitable pour la plupart des niveaux de développement (Analyse préliminaire … code)

– Utilisée même en dehors du domaine de l’informatique (Organisation d’entreprise, Ingénierie des systèmes, etc.)

• Une sémantique définie par un métamodèle• Un format d’échange entre ateliers


UML : Le contenu

• 9 types de diagrammes (class, use case, deployment, composants, collaboration, state, sequence, activity, object)

• Un mécanisme d’extension : les profiles UML (tagged values, stereotypes, constraints)


Modèle des USE CASE

GARAGISTECONDUCTEUR

Se déplacer

Ecouter de la musique

Téléphoner

Faire la vidange

Changer les bougies

Acteur

Cas d’utilisation


USE CASES : Utilisation

• Très employé, bon outil pour formaliser les besoins

• Identification des acteurs «aisée»

• Découverte et décomposition des Use Case plus délicate:– Granularité des Use Case?– Exhaustivité des définitions de Use Cases?– Niveau de description d’un Use Case?


DIAGRAMME DE SÉQUENCE : PRINCIPE

Objet2:Classe2Objet1:Classe1

message2 (p1,p2)

message1 ()

Objet3:Classe3

message3 ()


Diagrammes de séquence : Utilisation

• Faciles à faire, faciles à comprendre

• Attention à définir la juste quantité : niveau de détail

potentiellement infini !

• Attention à travailler au bon niveau : il est aisé de fournir

des détails opérationnels intéressant la conception lors de

l’analyse

• UML 2.0 : Fournir des moyens de structuration des

diagrammes de séquence


DIAGRAMME DE COLLABORATION : PRINCIPE

Objet1:Classe1

att1 = 10att2 = «hello»

Objet2:Classe2

Objet3:Classe3

role

1: messageX ()

2: messageY (1,«x»)


DIAGRAMME DE COLLABORATION

• La notion de rôle, sous jacente est peu employée

• Expression de mécanismes, en montrant la coopération entre

objets,

• A un aspect redondant avec les diagrammes de séquence

• Difficultés pour limiter le niveau de détail nécessaire

• UML 2.0 : Améliorer la gestion de l’imbrication d’objets, pour

mieux gérer les architectures. Améliorer la modélisation de

patterns


DIAGRAMME DE CLASSES : EXEMPLEEtatAvancement

visualiser( )

imprimer( )

lot

Lot

nom : stringtempsPrevu : floattemsConsomme : float/ tempsRestant : float

1 chefDeProjet

Collaborateur

trigramme : stringmotDePasse : string

modifierMotDePasse (unMot : string) :

0..*membreEquipe

Activitenom : stringtempsPrevu : float

tempsConsomme : float/ tempsRestant : float

0..*

historique

Projet

nom : string

creerLot (unNom : string

historiserEtatCourant( )

visualiser( )

0..*

10..*

0..*11etatCourant

activite


Diagramme de classes : Le cœur du modèle

• Le plus utilisé, le plus indispensable• Partie la plus décisive, pour le succès et la qualité d’un

développement• Nécessité de précision et d’exhaustivité• Grande difficulté pour définir les diagrammes de classes :

trouver les classes, faire les bon choix de formes de modélisation...

• UML 2.0 : – Positionner les classes vs types vs rôles, vs interface et

restructurer le métamodèle.– Débat sur une sémantique plus fine des associations (types

d’agrégation, etc.)


DIAGRAMME DE PACKAGES : EXEMPLE

LIVRAISONS

VEHICULES

COLIS

LIVREURS


Diagrammes de Packages : Mode d’emploi

• Très utilisés, indispensables pour les grands modèles,• Indispensable pour définir l’architecture d’un modèle,

pour gérer un modèle, et son développement par une équipe

• Utile dès l’analyse et fondamental en conception• Il est très difficile de définir la bonne structure d’un

modèle (itération nécessaire sur la définition des packages)

• UML 2.0 : Nécessité de retravailler les sous-systèmes, de positionner les composants (CBD) et la notion de modèle


DIAGRAMME D’ETAT


DIAGRAMME D’ETAT

• Utilisé beaucoup dans les applications “temps réel”, très peu dans les systèmes de gestion

• Peut décrire :– 1 le comportement de classes réactives

– 2 le protocole d’utilisation de toute classe

• UML 2.0 : structurer les state diagrams, définir de manière plus claire les protocol state diagrams, définir la signification de l’héritage de state diagrams


Activity diagrams

Comité de pilotage

Décider d'étudier un module

Besoin

ValiderFiche

[Validée]Fiche de version

Décision de prévoir un module

ProductManager

<<ProcessActivity>>Préparer fiche de version

[Diffusée]Fiche de version

<<Document>>

[facultatif]CahierDesCharges

Rédiger Fiche de version

ProjectManager

Evaluer charges

Décider d'étudier un module

Besoin

<<ProcessActivity>>Préparer fiche de version

ValiderFiche

[Diffusée]Fiche de version

[Validée]Fiche de version

Décision de prévoir un module

<<Document>>

[facultatif]CahierDesCharges

Evaluer charges

Rédiger Fiche de version


DIAGRAMME D’ACTIVITÉ

• Utile pour représenter des aspects dynamiques d’un système à un niveau assez général

• Principalement utilisé dans les applications de gestion

• Uml 2.0 : supprimer la dépendance avec les state diagrams, et clarifier la sémantique; définir une notion plus générale de flot de données


DIAGRAMME DE DÉPLOIEMENT ET COMPOSANTS : EXEMPLE

ServeurBancaire

ServeurStockMarket

ServeurCalculOperationBourse

PersistenceManagement

PersistenceManagement

TransactionManagement

TransactionManagement

EJBGestionComptes

EJBGestionComptesSpecifique

EJBSTock

EJBStockSpecifique

1..1

0..*

0..*

0..*

PosteClient

IHMUtilitairesClient

Applicatif

GestionCompte

0..1 0..*

0..1 0..*


Diagrammes de déploiement

• Expriment la localisation des différents constituants d’un système

• Utiles pour les applications réparties/distribuées.

• (UML 2.0) Doivent être re-visités pour mieux modéliser le déploiement de composants


Utilisation des modèles UML

Modèle Exemple d’utilisation Nature

Use case Expression du besoin D

Classe et package Modèle conceptuel, modèle de données, S

organisation

Séquence Exemple de fonctionnement D

Collaboration Coopération entre objets D

Explication d’architecture

Etat/transition Dynamique de fonctionnement D

Activité Workflow, Dynamique de fonctionnement D

Composant Modèle physique, organisation des ressources S

Déploiement Distribution, diagramme d’architecture S


Well-Formedness Rules : Langage OCL

• Example of semantic rule: Class [1]• English: If a Class is concrete, all the Operations of the Class

should have a realizing Method in the full descriptor.

• OCL:

not self.isAbstract implies self.allOperations->forAll (op | self.allMethods->exists (m | m.specification-> includes(op)))


Profiles UML : UML adapté à chaque domaine

UML 1.4, sous la conduite de SOFTEAM à l’OMG, étend la définition des profiles

EDOC CORBAREAL TIME EJB

UML 1.3

LES PROFILES STRUCTURENT LES EXTENSIONS UML

COMPONENT

<<profile>>

<<profile>> <<profile>> <<profile>> <<profile>>

<<profile>>


Adaptation de UML à chaque domaine : Les standards prévus

Nom standard Etat RFP Réponse intermédiaire

Date standardisation

Description

UML Profile for CORBA

Standardisé en septembre

Correspondance UML/CORBA

Software Process Engineering Management

Voté Deux réponses en compétition

Q1 2001 SOFTEAM a chairé cet effort, et fait partie des répondant : technique de modélisation du process logiciel.

UML profile for Enterprise Distributed Object Computing (EDOC)

Voté Deux réponses en competition fusionnent

Q1 2001 Très orienté « Composants ». Les partenaires « COMBINE » de SOFTEAM participent.

UML Profile Scheduling for performances and Time

Voté Oui. Les acteurs majeurs du temps réel sont unis.

Juin 2001 Annotation permettant de raisonner sur les consommations de ressources et de temps.

UML profile for EAI

Voté Oui Q1 2001 EAI est un domaine important, connecté avec EDOC

QoS and fault tolerance

Décembre 15 Aout 2001

Class diagrams 9

Sequence diagrams 5

Use cases 5

State charts 2 6

Stereotypes and tagged values 2

Package 2

Implementation diagrams 2 4

Collaboration diagrams 2 4 2

Activity diagrams 6

Model management (except package) 1 2

Component 1 3

Pattern 1

Class, type, interface, classifier role, component 2

Whole-part relationships 2

UML Standard Profiles 2

Notes in semantics section 1

Standard elements without abstract semantics 1

4.1.5. What parts of the language should be removed?4.1.4. What parts of the language need clarification?

4.1.3. What constructs in the language are least used?4.1.2. What constructs in the language are most used?

> 8 7-8 5-6 1-23-4 Legend (responses)

Retours OMG sur l’utilisation de UML


Utilisation de UML dans l’industrie

Modèle Niveau d’utilisation

Classe et package 5 Le plus utilisé, le plus essentiel

Use case 3 Dépend des cultures. Il y a des domaines où cela a peu d’intérêt

Séquence 3 Assez employé, bien compris

Collaboration 2 Les diagrammes d’objet sont utilisés, mais la modélisation

des collaboration et des rôles est encore marginale

Etat/transition 2 Très utilisé dans le temps réel, peu utilisé dans le tertiaire.

Activité 1 Arrivée tardive dans les ateliers, habitude culturelle locale

à certaines parties du tertiaire

Composant/Déploiement 1 Peu de personnes l’utilisent, sur peu de parties de leurs

applications


UML : Un très grand nombre d’apports hétérogènes

Role modeling,

Notion de type vs classes

Notion d’interface (Java, CORBA)

Notion de design patterns

Temps réel

Modélisation des processus de gestion

Diagrammes d ’états avec plusieurs interprétations

Use cases


UML 2.0 : Le futur (2002…)

• Faire de UML une famille de langages en clarifiant le noyau

• Supporter la modélisation de composants

• Fournir plus d’outils pour le temps réel

• Clarifier les notions, éviter les redondances ou les notions vagues, Clarifier la généralisation


UML - Bilan

• Un standard universellement reconnu et appliqué• Une consolidation progressive (UML 1.4) et une

révision majeure en vue (UML 2.0)• Supporté par un très grand nombre d’outils : Case

Tools, mais aussi des environnements de développement et des « repositories » divers

• Un effort considérable sur la sémantique, qui nécessite encore des consolidations

Documents

Copyright SOFTEAM 2000 Page 1 Philippe Desfray – Laurent Fourmy