Presentation Uml Cours

Ce document a été fabriqué par PDFmail (Copyright RTE Multimedia)
http://www.pdfmail.com
– Introduction :
• Constatations et état du marché
• Approche objet
• Inconvénients et remèdes
• La genèse
• Le cycle itératif et incrémental
– Les diagrammes UML
• Diagramme des cas d'utilisation
• Diagramme de classes, objets
• Diagramme de séquence
• Diagramme de collaboration
• Diagramme d'états – transition
• Diagramme de composants
• Diagramme de déploiement
Ca va mal dans le logiciel

: Seulement 15 % (chiffres 99) des
applications écrites sont mises en place
et fonctionnent ! (selon des enquêtes réalisées aux USA)
Pourquoi ?
Evolution des spécifications en cours de développement
Complexité des applications
Technologies en perpétuelle mutation
Retards de livraisons
Dépassements de budgets
Manque de réactivité
L’état du Marché
• Quelle est la réalité du développement aujourd’hui ?
Est-ce que je peux partager mes systèmes existants ?
Puis-je intégrer de nouvelles applications ?
Quelle est l’adaptabilité de mon application (souplesse) ?
• Le rythme effréné des changements technologiques:

Internet/Intranet, ERP
CORBA , COM/DCOM, ActiveX, Java, ...
Système Distribués à N-niveau
• Etat actuel : des dépendances ingérables entre des

applications peu ou pas documentées
L’approche objet : une solution ?

• Maîtrise de la complexité
Une décomposition objet décrit et décompose le

problème étudié comme un ensemble d’objets
autonomes qui collaborent pour réaliser certaines
opérations.
Chaque objet décrit un certain objet du monde réel et
incorpore son propre comportement.
Les objets inter-agissent en s’envoyant des messages
demandant l’exécution de telle ou telle opération
• Réutilisation
Les inconvénients de l’approche

objet
• Moins intuitive que l’approche fonctionnelle ou
chaque fonction du système est identifiée puis
décomposée en sous-fonctions
• Dérive inévitable car rien dans les concepts de base de

l’approche objet ne dicte comment modéliser la
structure objet d’un système de manière pertinente
• Nécessité d’une grande rigueur dans l’application

des concepts
UML : le remède
Pour penser et concevoir objet, il faut savoir prendre
de la hauteur, jongler avec des concepts abstraits,
indépendants des langages d’implémentation et des
contraintes purement techniques.
Il nous faut donc :

• Un langage qui permette de
ü représenter des concepts abstraits (graphiquement par
exemple)
UML :Le remède
ü De limiter les ambiguïtés en permettant un discours commun

avec un vocabulaire précis indépendant des langages orientés
objet.
ü De faciliter l’analyse
ü De définir des vues décrivant tous les aspects du système

avec des concepts objets
Historique d’UML
UML 1.3 Version finalisée en
décembre 1999
Standardisation OMG
Novembre 1997
UML 1.1
Janvier 1997 UML 1.0
Juillet 1996 UML 0.9
UML 0.8
Octobre 1995
Booch 93 OMT - 2
Booch 91 OMT - 1 OOSE

Grady Booch Jim Rumbaugh Ivar Jacobson
Qu’est ce que UML?

• UML = Unified Modeling Language
• UML est le langage standard incontournable

aujourd’hui ,pour visualiser, spécifier, construire, et
documenter des produits d’un système dont le logiciel
est prépondérant.
• Il peut être utilisé avec tous les processus, à travers le

cycle de vie de développement, et avec différentes
technologies d’implémentation.
Qu’est ce que UML?

UML possède plusieurs facettes:
• C’est une norme (OMG)
• C’est un langage de modélisation objet
• C’est un support de communication
• C’est un cadre méthodologique
• Mais ce n’est pas une méthode car il ne définit pas le

processus d’élaboration des modèles
UML
Bien qu’ UML n’impose pas de processus , ses
auteurs préconisent néanmoins l’utilisation
d’une démarche
üGuidée par les besoins des utilisateurs du système

üCentrée sur l’architecture logicielle
üItérative et incrémentale
(en opposition au cycle fonctionnel « en cascade »)
Cycle en cascade
Schéma directeur Plan de développement à moyen terme des systèmes d’informations
Etude préalable Dossier de choix avec proposition et évaluation de n solutions
Etude détaillée Spécifications fonctionnelles complètes futur S.I.O. (vue utilisateur)
Spécifications techniques complètes du futur S.I.I. (vue

Etude technique info.) pour la réalisation
Réalisation logicielle Bases de données générées Programmes réalisés et testés
Application informatique installée

Mise en service
dans la nouvelle organisation
Rectification des anomalies

Améliorations Maintenance
Evolutions
Cycle itératif
Le développement itératif et incrémental permet de construire un

logiciel par pas successifs, chaque pas étant appelé cycle.
A la fin d’un cycle, on obtient une nouvelle version du logiciel.
Chaque cycle est une succession de phases:

Etude d’opportunité (Inception in english)
Elaboration
Construction
Transition
La phase d’étude d’opportunité
But : Etablir les besoins et décider de leur prise en compte ou pas

En sortie: refus du projet ou prise en compte avec :
o Formalisation des exigences, des besoins
o Critères permettant d’évaluer le succès de cette itération
üLes critères doivent être mesurables (outils et conditions de mesure)
o Un plan de risque initial

ü pour guider les choix de développement
Eventuellement:
o Un prototype de conception
o Un modèle de domaine (10 à 20% du modèle final)
La phase d’élaboration
Buts :
o Finaliser l’analyse du problème
o Construire l’architecture du système
o Traiter les risques majeurs du projet
o Finaliser le plan de développement
En sortie :
o Analyse presque complète : modèle de comportement du système avec le contexte,
les scénarios et un modèle de domaine
o Un plan de risque révisé
o Implémentation des éléments de l’architecture pour tests de performance et fiabilité
o Prototypes
o Nombres d’itérations pour les phases de construction et de transition
o Plan de tests et la stratégie de tests mise en place
La phase de construction
Buts :
o Finaliser le développement du logiciel
o Fournir à l’utilisateur une version opérationnelle du logiciel
En sortie :
o un logiciel livrable à l’utilisateur
o des prototypes de comportement
o des documents d’assurance qualité
o des manuels utilisateurs
o des documents de déploiement
o les critères d’évaluations pour la prochaine itération
La phase de transition
Buts :
o mise en œuvre d’une version « bêta » chez
les utilisateurs pour tests grandeur nature
En sortie :
o Transition entre anciens systèmes et nouveaux systèmes
o Résultats concernant l’assurance qualité
o Formation des utilisateurs
o Analyse « post-mortem pour ne pas refaire les mêmes erreurs sur les projets à venir
o des documents sur l’étude, le développement et la maintenance
Mais qu’est-ce qu’une itération ?
Une itération fournit une version intermédiaire exécutable du logiciel
Etude Itération préliminaire

d’opportunité
Itération d’architecture
Elaboration
Itération d’architecture
Perspective Perspective
de gestion Itération fonctionnelle technique
Pilotage de projet Construction Itération fonctionnelle
Itération fonctionnelle
Itération de transition
Transition
Le nombre d’itérations varient Itération de transition
en fonction de la complexité
Modéliser avec UML
• UML est utilisé pour modéliser visuellement :
Ø Les interactions entre le système

et le monde extérieur
Ø Le comportement du système
Ø La structure du système
Ø Les composants du système
Les diagrammes
• Modélisation des vues statiques d’un système
– Le diagramme des cas d’utilisation

– Le diagramme de classes
– Le diagramme de composants
– Le diagramme de déploiement
Les diagrammes UML

• Modéliser les vues dynamiques d’un système
– Le diagramme de séquence
– Le diagramme de collaboration
– Le diagramme d’états/transition
D iag r
am m e
Cas
d'utili
sa tion
Diagramme de cas d'utilisation
vLes diagrammes de cas d'utilisation (use case models)

sont créés pour :
visualiser l’interaction du système avec le monde extérieur,
modéliser très tôt les processus métiers et l’organisation de
l’entreprise.
vIls se basent sur des diagrammes où des acteurs

interagissent avec le système de l'extérieur ou de
l'intérieur

Use case
v Les cas d’utilisations (use-case) sont des séquences d’actions

menées par le système qui doit donné un résultat observable
pour un acteur.
Ils sont représentés par le symbole :


Acteurs
Un acteur représente une entité qui interagit avec le système étudié.
Il est représenté par le symbole
Types d’acteur :
qLes acteurs principaux : personnes qui utilisent les fonctions du système.
qLes acteurs secondaires : personnes qui effectuent des tâches administratives ou de
maintenance.
qLes matériels extérieurs sauf la machine où se trouve l’application
(tels que distributeur de billets).
qLes autres systèmes tels que par exemple le réseau des cartes bancaires

Comment trouver les acteurs ?
Qui est intéressé par le besoin ?

Dans l’entreprise, où le système se trouve-t-il utilisé ?
Qui entre l’information, qui l’utilise, qui la détruit ?
Qui utilise cette fonction ?
Qui fait le support et la maintenance du système étudié ?
Le système utilise-t-il une ressource extérieure ?
Quels acteurs ont besoin de la fonction ?
Un acteur joue-t-il plusieurs rôles ?
Le même rôle est-il joué par plusieurs acteurs ?
…?

Acteurs
Un utilisateur peut jouer plusieurs rôles donc peut être plusieurs acteurs.
On a des instances d’acteurs : M.Dupont et Mme Martin sont des instances de

l’acteur « client ».
Il est impératif de bien définir les frontières du système pour définir

correctement les acteurs.

Comment trouver les use case ?
?
Quelles sont les tâches de l’acteur ?
Quel acteur crée, sauvegarde, modifie, efface ou
simplement consulte cette information ?
Quel use case crée, modifie, efface cette information ?
L’acteur devra-t-il informer le système des changements
venant de l’extérieur ?
L’acteur doit-il être informé sur certain état du système ?
Tous les besoins fonctionnels sont-ils pris en compte ?
…?

les relations entre cas d’utilisation ?
La relation de communication :
Elle est représentée par une flèche entre l’initiateur de
Communique
l’interaction et celui qui la reçoit changement
adresse
Client Gérer Client

La relation d’utilisation :
Une instance du cas source comprend le comportement décrit
dans le cas destination <<utilise>>
Editer facture Calcul remise
La relation d’extension :
Le cas source étend le comportement
<<étend>> décrit dans le cas destination
Gérer Client Gérer personne

Exemple
Adhère
Association
Adhérent Envoie info concours
Inscrit au concours
Organisation
concours
Délivre résultats
Juge
Juge épreuves

documentation
Pour chaque acteur :

Øune description rapide de quelques lignes
Pour chaque cas d’utilisation :
ØUne description rapide
ØLe détail des évènements (avec les informations) :
üComment et quand commence et se termine le cas d’utilisation
üQuand il y a interaction entre cas d’utilisation et acteur
üQuelles informations constituent un échange entre l’acteur et le cas
d’utilisation
üLe flux nominal
üLes n flots alternatifs

documentation
Pour chaque acteur :

Øune description rapide de quelques lignes
Pour chaque cas d’utilisation :
ØUne description rapide
ØLe détail des évènements (avec les informations) :
üComment et quand commence et se termine le cas d’utilisation
üQuand il y a interaction entre cas d’utilisation et acteur
üQuelles informations constituent un échange entre l’acteur et le cas
d’utilisation
üLe flux nominal
üLes n flots alternatifs

Scénario
C’est une instance de cas d’utilisation.

C’est un chemin que peut suivre le système.
Quand tout ce passe bien, c’est un scénario (happy day scénario).
Puis on a un scénario à chaque point de décision et chaque exception.
On écrira les différents scénarii possibles : ils constitueront la bases des jeux de
tests.

Intérêts
Il permet de communiquer avec les clients/utilisateurs et l’expert du domaine.

ü Assurance de compréhension mutuelle
Il permet d’identifier qui intervient sur le système

ü Que doit faire le système?
ü Qui interagit avec le système ?
ü Quelle interfaces doit posséder le système ?
Il permet de vérifier que les développeurs ont bien compris le besoin.

C l a s se
s
et
Ob je t
s
Classes et objets
Un objet est un membre d’un système orienté objet.
C’est une entité atomique qui possède :

ü une identité qui le caractérise de façon non ambiguë,
ü un état représenté par le contenu de ses attributs et les liens qu’il a avec les
autres objets,
ü un comportement qui regroupe les compétences d’un objet et décrit ses actions
et ses réactions (messages reçus , messages envoyés).
Les objets communiquent entre eux par des messages.
La persistance des objets est la capacité pour un objet de sauvegarder son état
dans un système de stockage de l’information.
Classes et objets
Une classe est un regroupement d’objets ayant les mêmes propriétés ou attributs,
les mêmes comportements, les mêmes relations avec les autres objets.
Un objet est une instance d’une classe.
Une classe nous permet de mieux gérer la complexité car c’est une définition
abstraite mettant en lumière les points communs entre les objets qu’elle
regroupe.
Le nom d’une classe provient directement du domaine. Il commence par une

lettre majuscule :
Commandes, Clients, LigneCommandes

Classes et objets
Combien de classes voyez-vous ?

Classes et objets
Une classe est représentée par :
Stagiaires Nom de la classe
idStagiaire
strNomStagiaire
nStage Attributs
strAdresse
….
creation()
modification() Comportements
suppression()
….
Classes et objets
Une classe a au moins un stéréotype :

vClasse "Boundary" ou classe à la frontière du domaine
vClasse entité
vClasse de contrôle
vClasse utilitaire
vMeta classe
vClasse d'exception
Classes et objets
Classe "frontière"
Une classe "boundary" modélise :

Ø la communication entre les intervenants autour du système et ses propres
tâches.
Classes "boundary" typiques :
vInterface utilisateur
vProtocole de communication (interface système)
vInterface d'impression
vCapteurs
Ø l'interface avec un autre système (facturation client).
Les caractéristiques d'une telle classe sont :
üLes informations passées à l'autre système,
üLe protocole utilisé pour "parler" à l'autre système.
Classes et objets
Classe "frontière"
Comment les découvrir ?

Ø En examinant chaque couple "acteur physique et scénario". On découvre
une classe interface.
Ø Durant le maquettage, ces classes peuvent être redéfinies en fonction des

mécanismes de l'interface utilisateur.
ØDes prototypes et des maquettes de fenêtres peuvent être créés pour

communiquer le "look and feel" de la classe boundary à l'utilisateur.
Classes et objets
Classe "entité""
Une classe "entity" modélise les informations et les comportement associés

(généralement persistante).
Les caractéristiques d'une telle classe sont :

üElle reflète une réalité,
üElle a besoin des tâches internes du système,
üLa valeur de ses attributs est souvent fournie par un acteur,
üSon comportement est indépendant des intervenants.
Classes et objets
Une classe "contrôle" supervise d'autres classes, assure la coordination entre

classes
üElle crée, initialise et détruit les objets contrôlés,

üElle contrôle le séquencement, ou coordonne l'exécution des objets
contrôlés. Elle n'a pas de "responsabilités" ceci est l'apanage des classes
entity et boundary
üElle contrôle la concurrence entre classes contrôlées,
üElle est l'implantation d'un objet intangible,
üAu départ , on crée une classe "contrôle" pour chaque use-case; cette
classe gère le flot d'évènements dans le use-case,
üAu fur et à mesure de l'avancement de l'analyse, les classes "contrôles"
peuvent être supprimées, découpées ou regroupées.
Classes et objets
Diagrammes de classes
Ø Diagramme principal qui est la vue de plus haut niveau avec

l'ensemble des classes de l'application
Ø Mais on peut avoir des vues logiques plus spécialisées si
nécessaire :
vVue des classes participant à un scénario
vVue des classes "privées" dans un package
vVue d'une classe avec ses attributs et ses opérations
vVue d'une hiérarchie d'héritage
Classes et objets
Les relations
Pourquoi ?
Tout système comporte de nombreuses classes et objets,
Les objets contribuent au comportement du système en
collaborant avec d'autres objets; cette collaboration est
représentée par des relations.
Il existe deux grands types de relations

ØL'association
ØL'agrégation
Classes et objets
Les relations : l'association
travaille pour
Sociétés Personnes
Association binaire non porteuse d'attributs
Classe association : Association porteuse d'attributs
s'inscrire
Concours Adhérents
Inscriptions
dateInscription
Classes et objets
Arité des associations
Agences Voyages
<<association ternaire>>
Sites touritiques Touristes
Visites
<<Association ternaire>> est

un stéréotype
Classes et objets
Les relations : l'agrégation
L'agrégation est une relation de type composé – composant,

maître – esclave.
FrameSaisie
Une forme d'agrégation est la composition.
ComboPays PanelRégion PanelPays
Ne pas utiliser l'agrégat pour une association : se poser la question quand je

détruis le "composé" est ce que je détruis le "composant" .
Si oui, c'est un agrégat, sinon c'est une association
Exemple : quand je détruis la voiture, est ce que je détruis la carrosserie ?
Ne mettre en agrégation que si c'est vraiment utile.
Classes et objets
Les relations : la généralisation
La généralisation est une relation entre un élément général (la super

classe) et un élément plus spécifique.
Personnes
strNom
strPrenom Dans cet exemple de généralisation, les attributs de Client
datNaissance sont ceux de Personnes plus ceux de Client.
strAdresse
Dans Personnes, on retrouve les attributs qui sont communs
aux classes Clients, Fournisseurs, Salariés.
Clients Fournisseurs Salariés

nCaAnnuel strSecteur nQualif
strFamille dSalaire
Classes et objets
Les relations : les rôles
L'extrémité d'une association est appelée rôle.
Le rôle décrit comment une classe voit l'autre classe au

travers d'une association.
< Travailler pour
Société Employeur Personnes
Employé
Classes et objets
Les relations : les cardinalités
Chaque rôle d'une association porte une indication de multiplicité indiquant combien
d'objets de la classe considérée peuvent être liés à un objet de l'autre classe (c'est la même
notion que les cardinalités merise sauf que l'indication se fait à l'inverse).
1 Un et un seul
0..1 0 ou un
* De 0 à plusieurs
0..*
1..* De un à plusieurs
Collaborateur
M..N De m à n occurences
0..*
Société Personnes
< Travailler pour
Employeur 0..* Encadrer
1 Employé 0..1
Supérieur
Classes et objets
Contraintes sur les relations
Les contraintes sont représentées par des expressions placées entre accolades.
Association Personnes
< appartenir
0..*
Membre
(Sous-ensemble)
0..*
Bureau
Les contraintes sont :

•Contrainte de partition (ou exclusif),
•Contrainte d'exclusion (toute objet de la classe participe à une et une seule des relations 0 ou n
fois),
•Contrainte de totalité (toute objet de la classe participe à une des relations)
Classes et objets
Exemple
Stagiaires
datEntree participer
datSortie +participant
Personnes cNiveauEntree
0..*
strNom
affectation()
strPrenom
iincriptionCours()
datNaissance
strAdresse
0..*
creation() +enseigne
modification() Professeurs Cours
suppression() 1..* 1..* 0..*
0..*
pré requis
Centres
Classes et objets
Paquetage
• Un paquetage ou package est un mécanisme servant à organiser des éléments

en groupes .
Package
IHM
• Les packages peuvent être mis en relation
Package Package
Interface Règles métiers
Classes et objets
Paquetage
Eviter le cycle
de dépendance
Package Package
A Règles métiers
Package
X
Classes et objets
Paquetage
Un package regroupant les objets techniques assurant la persistance

stéréotype <<infrastructure>>
pour un domaine donné (paie, comptabilité, …)

stéréotype <<entité externe>>
un package pour les interfaces par domaine également

stéréotype <<application>>
Un package pour les services d'impression

stéréotype <<infrastructure>>
D iag
ram m
es
d'
i nte r
ac t i o
n
Diagrammes d'interaction
C'est un diagramme qui donne une représentation graphique des interactions

entre objets.
Il existe deux types de diagrammes d'interaction :

@ Le diagramme de séquence (fonction du temps),
@ Le diagramme de collaboration( représente les flots de données).
Chacun de ces deux diagrammes représente la même chose vue

différemment.
Diagramme de séquence
Un diagramme de séquence montre les interactions entre objet dans le temps

avec :
Nom: Classe : Classe
v les objets participant à l'interaction,
Ligne de vie de l'objet
v la séquence des messages échangés qui peuvent être :

o synchrone : ils sont alors symbolisés par
o ou asynchrone : ils sont alors symbolisés par
Il montre étape par étape ce qui se passe pour accomplir une fonctionnalité
fournie par le système
Un message synchrone bloque son émetteur tant qu'il n'a pas fini de traiter.
Nommer un objet dans un diagramme de séquence :
Nom Nom: Classe : Classe
L'objet, l'individu est un objet non précisé de

connu la classe indiquée
Gwendal : Stagiaires
Diagramme de séquence : messages
Objet A Objet B
Message1() Le retour est implicite
Message2(p1,p2)
Le message a des paramètres
Le retour est implicite
Message3()
Le retour est explicite
Message récursif (objet composite)
Message avec délai de transmission non

négligeable
Diagramme de séquence : période d'activité
Objet A Objet B
Période d'activité
Message1()
l'objet A active l'objet B et reprendra la main

quant B lui redonne la main
Message2()
Le retour est explicite avant suicide :

la ligne de vie est terminée
Objet A Objet B Objet C
Représentation possible *[condition]Message1()

de la boucle While
Tant que condition

Envoie de Message1
[condition]Message2()
Représentation
d'une alternative
[non condition]Message3()
Il est possible d'écrire un script à la gauche du diagramme

en langage naturel ou en pseudo code
:Stagiaires Accueil : SaisieHeure : : Pointages : Stagiaires

Jframe Jpanel
1: SaisieAction ( )
2: new
3: afficheMsg()
4: afficheMsg(nStage)
5: SaisieCode
6: CtlStagiaireExist(nStagiaire)
7: retour(bExiste)
8: afficheMsg(nStagiaire)
9: createMvtPointage(nStagiaire, bType, Date,Heure)
Diagramme de séquence : exemple

Diagramme de collaboration
3: afficheMsg()
:Stagiaires 4: afficheMsg(nStage)
8: afficheMsg(nStagiaire)
5: SaisieCode
1: SaisieAction( )
2: new 6: CtlStagiaireExist(nStagiaire)
Accueil : SaisieHeure
Jframe : Jpanel : Stagiaires
7: retour(bExiste)
9: createMvtPointage
C'est un diagramme qui donne une
représentation graphique des
interactions entre objets.
:Pointages
D iag
ram m
e
d'
ét a t s
- tr a n
s it i o n
Diagramme d'états - transition
• Ce diagramme est utilisé pour montrer l'historique de la vie

d'une classe donnée : des évènements font passer d'un état à un
autre état qui doit déclencher des actions.
• C'est une abstraction des comportements possibles.
• Début : on ne peut en avoir qu'un
• Etat
• Distingué par un changement de valeurs des attributs ou par l'existence
de certains liens
• Transition
• C'est le changement d'un état vers un autre état suite à un stimuli
• On peut lui associer une action (celle ci doit être non interruptible)
• Fin : optionnel, mais on peut en avoir plusieurs
Ne pas confondre activité et action :

Une activité dure et peut être interrompue
Une action est immédiate et ne doit pas être interrompue

Exemple
Controle conformité
Préparation teminée Site préparé

Date ouverture
Site à amenager Site ouvert
Arrivé visteur
Décision d'exploitation Date ouvertue - 1 mois[ si pas de remise en état ]
Date ouverture[ avec remise en état ] Site visité

Site découvert
Décision de non exploitation date fermeture

Date fermeture
Site fermé
A u tr
es
d ia g r
am m
es
Diagramme d’activités
• Les diagrammes d'activités sont créés pour illustrer le flot

d'évènements à l'intérieur d'un cas d'utilisation.
• C'est une variante du diagramme d'états – transitions.
• Une activité est représentée par

Diagramme d’activités : exemple

Société Cotisations
Intermédiaire
assurée siège
Emettre
appel de
cotisations
Compléter Appel
informations émis Emettre
salariés 1ère relance
Enregistrer
paiement Appel 1
relance
Payer
cotisations Emettre
2ème
Enregistrer relance
informations Appel 2
salariés relance
Appel
payé
Mettre
Appel en Contrat
contentieux contentieux suspendu
Résiliation
du
contrat Contrat
résilié
Diagrammes de composants
– Les diagrammes de composants illustrent l’organisation et les dépendances parmi
les composants logiciels.
Accueil
Les symboles utilisés sont :
Programme principal entrée de l'application

Composant
Composant 1
dll
Sous programme : spécification corps
Package : spécification corps

–
Les symboles (suite) :
Tâches : spécification corps (exe)
Dépendances :
pointe de l'utilisateur des service vers le fournisseur de service
Interfaces :
Créer groupe
Groupe
Mise à jour groupe
Consulter groupe
Consultation
groupe
Le déploiement du système
§ Le diagramme de déploiement visualise la distribution des

composants dans l’entreprise.
§ Les symboles utilisés sont :
Serveur2
ØPour les processeurs
modem
ØPour les autres ressources matérielles
ØPour les connexions

Le déploiement exemple
LaserJet Site
du système régional
<<TCP/IP>>
<<TCP/IP>>
Seveur d' Site
mpressio central <<TCP/IP>>
Site
régional
<<TCP/IP>>
<<TCP/IP>>
Serveur Mac
Web
Site
régional Infographie
<<internet>>
PC PC
Application1
Application 2
FIN
Merci pour votre attention
A vos diagrammes

Presentation Uml Cours

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Presentation Uml Cours

Încărcat de

Drepturi de autor:

Formate disponibile

Ce document a été fabriqué par PDFmail (Copyright RTE Multimedia)

Ca va mal dans le logiciel

• Le rythme effréné des changements technologiques:

• Etat actuel : des dépendances ingérables entre des

L’approche objet : une solution ?

Une décomposition objet décrit et décompose le

Les inconvénients de l’approche

• Dérive inévitable car rien dans les concepts de base de

• Nécessité d’une grande rigueur dans l’application

Il nous faut donc :

UML :Le remède

ü De limiter les ambiguïtés en permettant un discours commun

ü De définir des vues décrivant tous les aspects du système

Janvier 1997 UML 1.0

Juillet 1996 UML 0.9

Booch 91 OMT - 1 OOSE

Qu’est ce que UML?

• UML est le langage standard incontournable

• Il peut être utilisé avec tous les processus, à travers le

Qu’est ce que UML?

• Mais ce n’est pas une méthode car il ne définit pas le

üGuidée par les besoins des utilisateurs du système

Etude préalable Dossier de choix avec proposition et évaluation de n solutions

Etude détaillée Spécifications fonctionnelles complètes futur S.I.O. (vue utilisateur)

Spécifications techniques complètes du futur S.I.I. (vue

Réalisation logicielle Bases de données générées Programmes réalisés et testés

Application informatique installée

Rectification des anomalies

Le développement itératif et incrémental permet de construire un

Chaque cycle est une succession de phases:

La phase d’étude d’opportunité

But : Etablir les besoins et décider de leur prise en compte ou pas

o Un plan de risque initial

Mais qu’est-ce qu’une itération ?

Une itération fournit une version intermédiaire exécutable du logiciel

Etude Itération préliminaire

Pilotage de projet Construction Itération fonctionnelle

Modéliser avec UML

• UML est utilisé pour modéliser visuellement :

Ø Les interactions entre le système

– Le diagramme des cas d’utilisation

Les diagrammes UML

Diagramme de cas d'utilisation

vLes diagrammes de cas d'utilisation (use case models)

vIls se basent sur des diagrammes où des acteurs

Diagramme de cas d'utilisation

v Les cas d’utilisations (use-case) sont des séquences d’actions

Ils sont représentés par le symbole :

Diagramme de cas d'utilisation

Un acteur représente une entité qui interagit avec le système étudié.

Il est représenté par le symbole

Diagramme de cas d'utilisation

Qui est intéressé par le besoin ?

Diagramme de cas d'utilisation

On a des instances d’acteurs : M.Dupont et Mme Martin sont des instances de

Il est impératif de bien définir les frontières du système pour définir

Diagramme de cas d'utilisation

Diagramme de cas d'utilisation

Client Gérer Client

Editer facture Calcul remise

Diagramme de cas d'utilisation

Adhérent Envoie info concours

Diagramme de cas d'utilisation

Pour chaque acteur :