Uml Introduction

UML : Unified Modeling Language
À destination des étudiants du

Master 2 - Sciences Humaines et Sociales –
mention Psychologie - Ergonomie Cognitive des Nouvelles
Technologies de l’Information et de la communication
Mireille Blay-Fornarino
ESSI
Sophia Antipolis
Email: blay@essi.fr
http://www.essi.fr/~blay
Contexte
Le Master de Psychologie avec spécialité professionnelle Ergonomie

Cognitive des NTIC vise à former des experts dans la conception et
l’évaluation des Interfaces informatiques (Web, CD-ROM,
télécommunications…) qui soient capables de mettre en place des
techniques d’évaluation et des outils d’analyse comportementale, procéder à
l’analyse statistique des mesures et les interpréter à la lumière des théories
cognitives actuelles.
Ces spécialistes doivent proposer des solutions informatiques
ergonomiques, évaluer les logiciels interactifs existants et opérer les
remédiations nécessaires.
L’objectif premier de ce diplôme est avant tout la pratique professionnelle
sans négliger une sensibilisation à la recherche.
Un support de discussion pour la partie fonctionnelle
Mireille Blay-Fornarino, 2
20/01/2005 blay@essi.fr
Bibliographie
UML Distilled Fowler&Scott
Cours de Jacques Lonchamp (rubrique enseignement): http://www.loria.fr/~jloncham
Cours ppt sur le WEB de Xavier Burdet
Modélisation Objet avec UML, Pierre-Alain Muller, Nathalie Gaertner, Ed. Eyrolles
Cours sur le Web de Pascal Molli, Université Nancy1,Loria molli@loria.fr,

www.loria.fr/~molli
Cours de Anne-Marie Hugues, http://www.essi.fr/~hugues
Cours UPV1, Processus Unifié, Ecole des mines de Nancy
Supélec – FP (d’après Terri QUATRANI – Rational Software)
ENSTA : cours IN204 Introduction à JAVA et UML, Olivier Sigaud, LIP6/AnimatLab
UML, Jacques JARAY
Détails du «module »
Ressources : http://www.essi.fr/~blay/ENSEIGNEMENTS/UML/
21 janvier 05 :
– Cours introduction à UML
– Analyse des besoins (use cases)
Présentation de l’étude de cas, détermination des binômes.
☺ Cahier des charges, cas d’utilisation à rédiger.
28 janvier 05 :
– Modèles statiques et dynamiques
– Présentation d’un outil de manipulation de diagrammes UML
Questions/réponses sur l’étude de cas, cas d’utilisation
☺ Cas d’utilisation à corriger ou compléter, premiers scénarii pour le cas d’utilisation choisi + diagramme de classes
4 février 05:
– Fin de présentation d’UML
Etude critique de votre modélisation
Compléments sur les scénarii et Diagramme de classes
☺ Rapport final + présentation
Vacances
18 février 05:
Exposé (cas d’utilisation, diagramme de classes général, des scénarii, +… )
☺ Rapport complet.
Plan du Cours
(1) Introduction
a. Ingénierie du logiciel : D’abord des échanges
b. Modélisation : du fonctionnel à l’objet
c. UML, histoire, généralité
(2) Analyse et Conception avec UML

a. Cas d’utilisation
b. Diagrammes d’interactions
c. Diagramme de classes
d. Diagramme d’objets
e. Diagramme d’états
Introduction
a. Ingénierie du logiciel : D’abord des échanges
Ingénierie du logiciel : D’abord des échanges
Symptômes Courants d'Echec des Projets
Mauvaise compréhension des besoins des utilisateurs

finaux.
Incapacité de gérer les modifications des exigences.
Les modules qui ne fonctionnent pas ensemble.
Du logiciel difficile à maintenir ou à faire évoluer.
Du logiciel de mauvaise qualité (beaucoup d'anomalies).
Le processus « idéal » pour

le développement de logiciel
Il doit permettre de :
Bien comprendre les demandes et exigences des utilisateurs finaux
Bien communiquer avec le client
Tenir compte des changements du cahier des charges
Empêcher la découverte tardive de défauts sérieux dans le projet
Traiter au plus tôt tous les points critiques du projet
Bien maîtriser la complexité
Favoriser la réutilisation
Définir une architecture robuste
Faciliter le travail en équipe
...20/01/2005 Mireille Blay-Fornarino, 8
blay@essi.fr
7 bonnes pratiques
Développement de manière itérative

Développement à base de composants centré
sur l’architecture
Pilotage par les risques
Ce sont
Gestion des exigences celles du
UP…
Maîtrise des modifications
Evaluation continue de la qualité
Modélisation visuelle
(1) Qu'est-ce que le Développement Itératif ?
• Basé sur de petites étapes, le feedback et l’adaptation.

• Aussi appelé évolutif, en spirale, . . .
Itération Itération
...
1 2
Ana- Con- Code+Conception+Test+Intégration Ana- Con- Code+Conception+Test+Intégration

lyse ception lyse ception
2 ou 4 semaines 2 ou 4 semaines
(2) Développement à base de composants

centré sur l’architecture
Au cours des premières itérations, on construit et on

valide une architecture logicielle
– A partir de composants existants, standards du marché
– Éviter les développements spécifiques
Construire l’architecture et la tester tôt même si la

solution n’est pas parfaite et incomplète
(3) Pilotage par les risques
L’hiver,
Un risque est un il faut se faire vacciner
événement redouté dont contre la grippe
l’occurrence est plus ou
moins prévisible et
provoquant, lorsqu’il se
produit, des dommages
sur le projet.
Vous avez la grippe, je vais vous
prescrire des antibiotiques
Il ne faut pas confondre risque et problème.

Un problème est un risque qui s’est révélé.
Le pilotage par les risques, c’est :
Analyser les risques potentiels le plus tôt possible – dès

les premières itérations
– Les hiérarchiser
– Commencer par travailler sur
les éléments les plus exposés
Penser aux risques techniques, mais aussi :

– aux risques liés au client
– aux risques liés au domaine applicatif
– aux risques liés à l’organisation du projet
Identification des exigences
Qu’est ce qu’une exigence ?

– Condition à laquelle le système doit satisfaire ou une capacité
dont il doit faire preuve. [RUP]
On distingue :
– Les exigences fonctionnelles
• Qui formulent ce que le système est chargé de faire
– Les exigences non fonctionnelles
• Décrivent la qualité des services attendus du système (performance,
sécurité de fonctionnement, IHM)…
(4) La gestion des exigences
1) Lack of User Input

1) Lack ofparticipation
User Input
Facteurs de 1)
1)Manque
Manquedede participationdes
desutilisateurs
utilisateurs
dépassement
et d’abandon 2)
2) Incomplete Requirements
2) Incomplete Requirements Gérer les
2)Identification
Identificationincomplète des Besoins
and Specifications des Besoins
incomplète
3)
and Specifications
exigences
3) 3)Changing
Changing
3)Besoins
Besoinsqui Requirements
Requirements
quichangent
changentau
aucours
coursdu
duprojet
projet
and
andSpecifications
Specifications
Standish Group, ‘97 Mireille Blay-Fornarino, 15

La Gestion des Exigences
Cela ne signifie pas:

– Avoir des exigences correctes dés le démarrage du projet.
C'est irréaliste…
Cela signifie:
– Ne pas être négligent.
– Les recueillir efficacement.
– Enregistrer, tracer, organiser
– Et cela se rapporte au fait de considérer les changements de
manière formelle (maîtriser les changements).
(5) Qu’est-ce qu’une demande de

changement ?
Demande de changement (Change Request ou CR)
– Requête pour modifier un artefact ou un processus. Dans la
documentation d’une demande de changement figurent des
informations sur l’origine et l’impact du problème considéré, sur la
solution proposée et sur son coût.
Deux types
– Demande d’Evolution
• Spécifie une nouvelle caractéristique du système ou un changement
par rapport au comportement établi.
– Rapport d’Anomalie
• Erreur ou défaut
(6) Faire les Tests à la fin ?

Il est démontré que :
– Corriger une anomalie plus tard coûte 10-100 fois plus que de la
corriger à son origine.
Software Engineering Economics, Boehm, 1981.
– Les produits avec le moins d'anomalies ont les délais les plus courts.
• Applied Software Measurement, 1st edition, Jones 1991.
– La mauvaise qualité est la raison la plus courante de dépassement
des délais.
• Assessment and Control of Software Risks, Jones 1994, 4000 project
study.
– La correction des anomalies consomme 40-50% du coût total.
• IEEE Computer, Boehm, Sept 1987.
– 60% des anomalies existent au moment de la conception.
• Principles of Software Engineering Management, Gilb, 1988.
Evaluation continue de la Qualité

Solution construite – contrôle produit
– Vérification de l’adéquation de la solution aux besoins
– Tests systématiques et périodiques
– Actions qualité
Avantages :
– Identification précoce des dysfonctionnements
– Réactivité aux déviations constatées
– Maîtrise des risques de dérapage
Une Histoire Vraie
1. Passez 6 mois à construire un système de e-

commerce. Maintenant que vous êtes prêt à sortir le
produit…
2. Alors, vous demandez à vos amis et collègues:

“A 11 heures demain matin, tout le monde se
connecte et essaye de passer une commande, ainsi
on pourra vérifier si le système résiste à la charge
prévue.”
Est-ce le moment de vérifier cette propriété

significative de l'architecture?
Introduction
b. Modélisation : du fonctionnel à l’objet
Modélisation : du fonctionnel à l’objet
La découpe fonctionnelle
d'un problème informatique : une approche intuitive
Factorisation
Le revers de la médaille :
maintenance complexe en cas d'évolution
La séparation des données et des traitements :

le piège !
Réunir données et traitements :

Programmation par objets
Vision objet du système informatique (1)

Le système d ’informatique est modélisé comme un ensemble
d ’objets, avec leurs propriétés et leurs comportements, qui
collaborent entre eux
• Un objet est une entité aux frontières précises qui possède

une identité (un nom).
• Un ensemble d'attributs caractérise l'état de l'objet.
• Un ensemble d'opérations (méthodes ou comportements) en
définissent le comportement.

Un objet est une instance de classe (une occurrence d'un
type abstrait).
Une classe est un type de données abstrait (modèle) ,
caractérisé par des propriétés (attributs et méthodes)
communes à des objets et permettant de créer des objets
possédant ces propriétés.

Héritage (et polymorphisme)
L'héritage est un mécanisme de transmission des propriétés d'une
classe (ses attributs et méthodes) vers une sous-classe.

Le polymorphisme représente la faculté d'une méthode à
pouvoir s'appliquer à des objets de classes différentes.

L'héritage est un mécanisme de transmission des propriétés d'une classe

(ses attributs et méthodes) vers une sous-classe.
Une classe peut être spécialisée en d'autres classes, afin d'y ajouter des
caractéristiques spécifiques ou d'en adapter certaines.
Plusieurs classes peuvent être généralisées en une classe qui les factorise,
afin de regrouper les caractéristiques communes d'un ensemble de classes.
La spécialisation et la généralisation permettent de construire des
hiérarchies de classes. L'héritage peut être simple ou multiple.
L'héritage évite la duplication et encourage la réutilisation.
Le polymorphisme représente la faculté d'une méthode à pouvoir s'appliquer
à des objets de classes différentes.
Le polymorphisme augmente la généricité du code.
L'approche objet : une solution parfaite ?

L'approche objet est moins intuitive que l'approche
fonctionnelle !
Quels moyens utiliser pour faciliter l'analyse objet ?
Quels critères identifient une conception objet pertinente ?
L'application des concepts objets nécessite une grande

rigueur !
Le vocabulaire est précis (risques d'ambiguïtés,
d'incompréhensions).
Comment décrire la structure objet d'un système de
manière pertinente ?
Quels sont les remèdes

aux inconvénients de l'approche objet ?
Un langage pour exprimer les concepts objet qu'on utilise, afin de
pouvoir :
Représenter des concepts abstraits (graphiquement par exemple…).

Limiter les ambiguïtés (parler un langage commun).
Faciliter l'analyse (simplifier la comparaison et l'évaluation de
solutions).
Une démarche d'analyse et de conception objet, pour :
Ne pas effectuer une analyse fonctionnelle et se contenter d'une

implémentation objet, mais penser objet dès le départ.
Définir les vues qui permettent de couvrir tous les aspects d'un
système, avec des concepts objets.
Pourquoi Utiliser la Modélisation Visuelle?
On doit enregistrer nos pensées et communiquer en

utilisant des langages visuels et schématiques (par ex.,
UML).
Parce que :
– On estime qu'au moins 50% de notre cerveau est impliqué dans le
processus visuel.
– Les langages visuels sont naturels et faciles pour notre cerveau.
Modélisation
modèle : simplification de la réalité dont les buts sont
Visualiser Spécifier la
le système structure et le
comportement
du système
Aider à la construction
du système
Documenter
les décisions
Modélisation de la communication et des

processus
louer
rendre
tâches
Analyse Fonctionnelle gérer

Workflow / procedures Raffiner
Simuler
Connected
stop
Concevoir Dealing with customer choic e
Select mode
choice done
State 1 Event 1 State2

[ browse ]
[ place order ] [ consult ]
Event2 Browse Place order Consult order
disconnection
Disconnected
Modélisation objets métiers / données
Analyse des Vehicle

Domaines Boat Van Conception
Car
Aircraft
Real World Basic Concepts
Exec
support
Model Vehicle
Code
Realisation
Plane Boat Car

Deployment
Introduction
c. UML, histoire, généralité
UML: histoire, généralité
Pourquoi UML ?
Objectifs : spécifier, construire, visualiser et documenter les systèmes

à base de logiciel
– Pour communiquer, travailler à plusieurs
– Pour Comprendre la « big picture »
– Par approche orientée objets
– Avec différents modèles pour différentes vues
UML : Langage et non simple notation graphique (ni méthode)

UML est Indépendant des méthodologies
UML Support des systèmes concurrents et répartis, à base de
composants
Un peu d’histoire :
La guerre des Méthodes
Booch, OMT, Coad/Yourdon, Fusion,SADT, OOSE,

Schlaer/Mellor, HOOD…
UML: un méta-langage de modélisation pour unifier les

modèles utilisés dans les méthodes
Et un langage unique, un !
Un cocktail de notations éprouvées.

(...mais pas toutes, p. ex. RdP,
SADT/IDEF0, DFD, etc.)
Auteurs : Grady Booch, Ivar
Jacobson, James Rumbaugh.
Standardisation OMG
Promoteurs :
Rational Software, Oracle
Hp, Microsoft, IBM
Unified Modeling Language
UML est un langage graphique qui permet de modéliser

tous les types de systèmes d ’informatiques.
Ce n ’est pas une méthode mais une notation qui laisse la

liberté de conception.
Modèles et Diagrammes UML (d’après G Booch)
Les modèles UML

pour State
State
Diagrams
Class
Diagrams
– visualiser, Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Diagrams
– spécifier, Use Case Diagrams Object
Diagrams
Diagrams
Sequence Diagrams
Diagrams
– construire , Diagrams
– Documenter
Scenario State
Scenario
Diagrams State
Diagrams
Collaboration
Diagrams Component
Diagrams
Diagrams Diagrams
l ’architecture Models
en se plaçant à Scenario Component

Scenario Component
Diagrams
différents points de Diagrams
Statechart
Diagrams
Deployment
Diagrams
Diagrams Diagrams
Activity
vue Diagrams
statiques
dynamiques
Les points forts d'UML
– UML est un langage formel et normalisé
• gain de précision
• gage de stabilité
• encourage 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 d'UML
– 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.
Or, l'intégration d'UML dans un processus n'est pas triviale et

améliorer un processus est une tâche complexe et longue.
Organisation générale
UML au travail….

Uml Introduction

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uml Introduction

Enviado por

Direitos autorais:

Formatos disponíveis

UML : Unified Modeling Language

À destination des étudiants du

Le Master de Psychologie avec spécialité professionnelle Ergonomie

Un support de discussion pour la partie fonctionnelle

Cours de Jacques Lonchamp (rubrique enseignement): http://www.loria.fr/~jloncham

Cours ppt sur le WEB de Xavier Burdet

Cours sur le Web de Pascal Molli, Université Nancy1,Loria molli@loria.fr,

Cours de Anne-Marie Hugues, http://www.essi.fr/~hugues

Cours UPV1, Processus Unifié, Ecole des mines de Nancy

Supélec – FP (d’après Terri QUATRANI – Rational Software)

ENSTA : cours IN204 Introduction à JAVA et UML, Olivier Sigaud, LIP6/AnimatLab

UML, Jacques JARAY

(2) Analyse et Conception avec UML

a. Ingénierie du logiciel : D’abord des échanges

Symptômes Courants d'Echec des Projets

Mauvaise compréhension des besoins des utilisateurs

Incapacité de gérer les modifications des exigences.

Les modules qui ne fonctionnent pas ensemble.

Du logiciel difficile à maintenir ou à faire évoluer.

Du logiciel de mauvaise qualité (beaucoup d'anomalies).

Le processus « idéal » pour

Développement de manière itérative

(1) Qu'est-ce que le Développement Itératif ?

• Basé sur de petites étapes, le feedback et l’adaptation.

Ana- Con- Code+Conception+Test+Intégration Ana- Con- Code+Conception+Test+Intégration

(2) Développement à base de composants

Au cours des premières itérations, on construit et on

Construire l’architecture et la tester tôt même si la

(3) Pilotage par les risques

Il ne faut pas confondre risque et problème.

Le pilotage par les risques, c’est :

Analyser les risques potentiels le plus tôt possible – dès

Penser aux risques techniques, mais aussi :

Identification des exigences

Qu’est ce qu’une exigence ?

(4) La gestion des exigences

1) Lack of User Input

Standish Group, ‘97 Mireille Blay-Fornarino, 15

La Gestion des Exigences

Cela ne signifie pas:

(5) Qu’est-ce qu’une demande de

(6) Faire les Tests à la fin ?

Evaluation continue de la Qualité

Une Histoire Vraie

1. Passez 6 mois à construire un système de e-

2. Alors, vous demandez à vos amis et collègues:

Est-ce le moment de vérifier cette propriété

b. Modélisation : du fonctionnel à l’objet

La séparation des données et des traitements :

Réunir données et traitements :

Vision objet du système informatique (1)

• Un objet est une entité aux frontières précises qui possède

Vision objet du système informatique (2)

Vision objet du système informatique (3)

Vision objet du système informatique (4)

Vision objet du système informatique (5)

L'héritage est un mécanisme de transmission des propriétés d'une classe

L'approche objet : une solution parfaite ?

L'application des concepts objets nécessite une grande

Quels sont les remèdes

Représenter des concepts abstraits (graphiquement par exemple…).

Une démarche d'analyse et de conception objet, pour :

Ne pas effectuer une analyse fonctionnelle et se contenter d'une

Pourquoi Utiliser la Modélisation Visuelle?