Cours UML 1

ENSA de Fès 2015/2016
ENSAF Sommaire
2ème année Filière : Génie Informatique
Année Universitaire 2015/2016 • Introduction au génie logiciel
L L • Présentation d’UML
A A • Diagramme de cas d’utilisation
N N
G
A
G
Langage de Modélisation G
A
G
•
•
Diagramme de classes
Diagramme d’objets
E
U
UML E
U
•
•
Diagramme d’états-transitions
Diagramme d’activité
M M • Diagrammes d’interaction (séquence et collaboration)
L L
• Diagrammes de composants et de déploiement
Mohammed Berrada
mohammed.berrada@gmail.com
ENSAF 1 M.BERRADA ENSAF 2 M.BERRADA
Plan 1
• Introduction
L L • Définitions
A A • Le Génie Logiciel : Genèse et Objectifs
N N
G G • Les Cycles de vie de développement industriel de
A
G Introduction au Génie A
G
Logiciels
E E • Les facteurs de qualité logiciel
U
Logiciel U
• Des méthodes fonctionnelles aux méthodes “Objet”
M M
L L
Introduction Introduction (2)

• Programmer n'est pas Concevoir un système informatique • Comment acquérir/développer un système sur mesure ?
– Que le logiciel soit
L L
A A • développé en interne
• La technique ? nécessaire, mais pas si importante que ça !
N N • acheté, sous-traité
G G
A A
G
• Le VRAI problème difficile : l'organisation, la gestion G • Comment avoir/donner confiance
E – difficulté de formalisation E
– respect des coûts, du calendrier
– multitude de paramètres, facteurs
U U – respect des besoins fonctionnels
M – gestions des ressources (financiers, humaines, matériel, temps) M
L L
M.BERRADA 1
Définitions Genèse et Objectifs (1)

• Le génie logiciel (software engineering) est une science de génie • Difficulté de maîtrise des coûts
industriel qui étudie les méthodes de travail et les bonnes pratiques des
L ingénieurs qui développent des logiciels. L
A A • Difficulté de réalisation de plannings
N N
G • Le génie logiciel s'intéresse en particulier aux procédures G
A systématiques qui permettent d'obtenir des logiciels de grande taille, A
G qui correspondent aux attentes du client, sont fiables, ont un coût G
• Difficulté de maîtrise des délais de réalisation
E d'entretien réduit et de bonnes performances tout en respectant les E
délais et les coûts de construction.[ Wikpédia] • Difficulté d’amélioration de la productivité et de la qualité
U U
M M des logiciels
L • Ensemble de moyens (techniques, méthodes) mis en œuvre pour la L
construction
– de systèmes informatiques
– de logiciels
Genèse et Objectifs (2) Difficultés liées à la nature du logiciel

• Difficulté de gestion de projets logiciels de grande ampleur • un logiciel ne s'use pas, sa fiabilité ne dépend que de sa
L
(Programming in the Large) L conception
A A
N N • mais, pour rester utilisé un logiciel doit évoluer
G • Nombreux échecs : résultats fournis par les logiciels G
A insatisfaisants pour les clients finaux. A
• pas de direction clairement exprimée,
G G
E E
• changements fréquents,
Tout ceci dans un contexte de compétition
U U
M
internationale sévère M • Contradictions des besoins
L L
Difficultés liées aux personnes Difficultés technologiques
• ne savent pas toujours ce qu'elles veulent, ou ne savent pas • courte durée de vie du matériel,
L bien l'exprimer L
A A • beaucoup de méthodes, langages, …
N N
G G
A • communication difficile entre personnes de métiers A
G différents (jargons) G
• Évolution des outils de développement
E E – adaptation
– formation
U • l'informaticien est souvent perçu comme introverti, peu U
M M – Investissement lourds
L
solidaire du groupe (...ça change...) L
• beaucoup d ’autodidactes qui croient savoir...
M.BERRADA 2
Le coût de développement... Quelques thèmes tirés par le Génie Logiciel

• Répartition : (Ref. Boehm) • Qualification du personnel par la formation
– Analyse/Conception
L L • Procédures de gestion de la qualité logiciel
• 33-34 % : Système d’exploitation, Aérospatiale
A • 44-46 % : Contrôle et Régul. indus., Calcul scientifique, Gestion
A • Outils dédiés au GL
N N
– Codage
G G • Langages et environnements de programmation
• 17-20 % : Système d’expl., Contrôle et Régul. indus., Aérospatiale
A A
G • 26-28 % : Calcul scientifique, Gestion
G
• Prototypage
– Test/Intégration
E E Il n’y a pas de remède miracle,
• 28-34 % : Contrôle et Régul. indus., Calcul scientifique, Gestion
U • 46-50 % : Système d’exploitation, Aérospatiale U
mais quelques voies à creuser...
M – Maintenance M
L • coûts très importants... L
• Méthodes formelles et semi-formelles
• Peu de capitaux d’investissement nécessaires
• Réutilisabilité
• Frais de personnel élevés
• L’approche Objet
Les cycles de vie Les cycles de vie (2)

• qu’est-ce qu’un cycle de vie logiciel? Etapes d’un cycle de vie
L – Enchaînement des activités de développement logiciel L • Analyse : opportunité fonctionnelle et faisabilité technique
A – Définition des Pré et Post conditions pour chaque phase A • Conception : choix tactiques de réalisation et d’architecture
N N
G – Procédures de gestion et d’encadrement G • Codage : réalisation informatique du détail des opérations
A A
G
– Procédures de mesures G
• Test : tests unitaires et d’intégration
E – Cycle de vie logiciel : synonyme de méthodologie E • Exploitation / Maintenance
U
logiciel U
M M Les deux grandes catégorie de cycles de vie :
L L
• Les cycles linéaires : succession d’étapes ordonnées
• Les cycles itératifs : réalisation incrémentale par évolutions
Les cycles de vie linéaires Limites du modèle linéaire

• Cycle en cascade : ouvre des points de visibilités • Les projets présentent bien souvent une part d’inconnu et
L L
donc de risques.
A A – Méconnaissance des besoins par le client
N N – Incompréhension des besoins par le fournisseur
G G
A A – Instabilité des besoins
G G – Choix technologiques
E E
– Mouvements de personnels
U U
M M
L L
=> Le processus de développement d’un logiciel n’est
pas naturellement linéaire...
M.BERRADA 3
Les cycles de vie itératifs Le cycle en spirale (Boehm)

• Evaluation d’éléments concrets au cours du • A chaque spire, il y a itération complète sur les phases :
développement : élimination de l’effet tunnel – Analyse
L L
A A – Conception
– basé sur l’évolution de prototypes exécutables, mesurables
N N – Codage
G – diminution de l’importance des documents de spéc. Détaillée G
– Test
A – livraisons intermédiaires => résultats concrets réguliers de A
G G
E
l’équipe de développement E
– meilleurs anticipation et prise en compte des problèmes
U U
M
– meilleurs gestion de la prise en compte de modifications de M
L spécification qui peuvent être intégrées dans une itération L
future
– intégration progressive de composants
– ...
Le cycle en spirale (2) Facteurs de qualité logiciel (1)

• A chaque itération, le logiciel doit être dans un état quasi Facteurs externes (visibles par le client)
L
commercialisable L • Validité : aptitude d’un produit logiciel à remplir
A A exactement ses fonctions, définies par le cahier des charges
N N et les spécifications.
G • Grand intérêt en prototypage incrémental G
A A • Exactitude : le logiciel fournit les bons résultats
G G
E • Très utilisé sur les projets reposant sur l’objet. E • Robustesse : le logiciel réagit correctement à des données
fausses
U U
M • La première spire doit comprendre les éléments les plus M
• Fiabilité : exactitude + robustesse
L abstraits et Le coeur fonctionnel minimum du système L • Stabilité : possibilité d’intégrer des modif. de spécification
légères
«Design a little, code a little»
Facteurs de qualité logiciel (2) Facteurs de qualité logiciel (3)

Facteurs externes (visibles par le client) Facteurs internes
L • Efficacité : Utilisation optimales des ressources L • Vérifiabilité : facilité de préparation des procédures de
A matérielles (performances d’exécution, encombrement A test.
N mémoire,...) N
G G • Maintenabilité (support du temps..., testabilité, traçabilité)
A A • Portabilité : facilité avec laquelle un logiciel peut être
G G
E • Facilité d’emploi : facilité d’apprentissage, d’utilisation, E transféré sous différents environnements matériels et
de préparation des données, d’interprétation des erreurs et logiciels.
U de rattrapage en cas d’erreur d’utilisation. U
M M
• Intégrité : aptitude d’un logiciel à protéger son code et ses
L L données contre des accès non autorisés.
• Compatibilité : facilité avec laquelle un logiciel peut être • Cohésion : forte cohésion dans les modules
combiné avec d’autres logiciels. • Faible couplage entre les modules
M.BERRADA 4
Des méthodes fonctionnelles aux méth.

L’approche fonctionnelle
objet
• L’approche fonctionnelle • Représentation graphique d’une approche fonctionnelle
L – Raisonnement en terme de fonctions du système L
A • l’accent est mis sur les fonctions et non sur les données A
N N
G G
A – Séparation des données et du code de traitement A
G • transposition dans les méthodes des contraintes du matériel G
E E
U – Diffusion des responsabilités U

M • intégrité des données non garanties M
L • ajout possible de nouvelles opérations à tout moment L
– Décomposition fonctionnelle descendante
L’approche fonctionnelle (Exemple) L’approche Objet
• Regroupement données-traitements
L L
A A
• Diminution de l’écart entre le monde réel et sa représentation
N N informatique (approche naturelle)
G G
A A – Les informaticiens sont pervertis : le monde est avant tout
G G
E E objet
U U • Localisation des responsabilités : encapsulation
M M
L L • Décomposition par identification des relations entre objets :
– association, composition , généralisation/spécialisation
L’approche Objet (Exemple) Evolution des méthodes
L L
A A
N N
G G
A A
G G
E E
U U
M M
L L
M.BERRADA 5
Panorama des méthodes La spécification UML

• Méthodes structurées
– Programmation structurée (Dijkstra)
L L
– Décomposition fonctionnelle descendante (SA/SD)
A A
N – SADT/SART N
G • Modélisation de Systèmes d’Information G
A A
G – Diagrammes entités-relations G
E – Merise E
U • Méthodes Objet U
M – OOD : Booch (91,93) M
L – OOA : Coad-Yourdon (90) L
– HOOD : pour Ada (88)
– OOM : Bouzeghoub (93) merise
– OOSE : Jacobson
– OMT : Rumbaugh (91,93)
Plan 2
• Introduction
L L • La modélisation
A A
N N • Concepts de l’approche Objet
G G • Historique d’UML
A A
G G • Diagrammes d’UML
E E
U
Présentation d’UML U
• Classification des digrammes
M M
L L
La modélisation Concepts de l’approche Objet

• Elle est essentielle pour : • Classe : type de donnée abstrait
– Caractéristiques : attribues et méthodes
L – Comprendre le fonctionnement d’un système L
A A • Encapsulation : masquer les détails d’implémentation d’un l’objet
– Maîtriser la complexité
N N – Facilite l’évolution d’une application
G – Faciliter la communication au sein de l’équipe G – Garantit l’intégrité des données
A A
G G • Héritage : transmission les caractéristiques d’une classe vers
E • Et particulièrement en génie logiciel : E une/plusieurs sous classe(s)
– Spécialisation et généralisation
U – Être un facteur de réduction des coûts et des délais U
M M • Polymorphisme: faculté d’appliquer une méthode à des objets de classes
– Être un facteur d’accroissement de la qualité du produit
L L différentes
Validité, fiabilité, extensibilité,
réutilisabilité, compatibilité, intégrité, • Agrégation : composition des objets, plus complexes, d’une classe à
portabilité, vérifiabilité, efficacité...
partir des objets d’autres classes de base
– Permettre d’assurer une maintenance facile et efficace
– Permettre de contrôler l’avancement d’un projet
M.BERRADA 6
Méthodologie OO Méthodes OO de base

• Les méthodes de modélisation ‘classiques’ sont basées sur : Méthode OOD Méthode OMT Méthode OOSE
BOOCH RUMBAUGH JACOBSON
– Un modèle de données et un modèle des traitements séparés Modélisation Modélisation statique Cas d’utilisation
L L
A – Une modélisation de flots de données A dynamique
N Insatisfaisantes pour modéliser des systèmes objet N
G G
A A
G • L'émergence des méthodologies objets (c.1990) G
E E
– Plus de 50 méthodes objet sont apparues
U – Exemples : Booch, Classe–Relation, Fusion, HOOD, OMT,OOA, U UML
M OOD, OOM, OOSE M
L L Unified Modeling Language
– Toutes les méthodes avaient pourtant d’énormes points communs
(objets, méthode, paramètres,…)
Aucune ne s’est réellement imposée • UML: un méta-langage de modélisation pour unifier les
modèles utilisés dans les méthodes
Historique : évolution d’UML

UML 2.3 Mai 20102010
Présentation
Dernière spécification
révisée par l’OMG
• UML est un langage graphique qui permet de modéliser tous
UML 1.X 1999-2002
L L les types de systèmes d’informatiques.
A UML 1.2 A – Comprendre et de décrire les besoins
juin 1998
N N
– Concevoir et construire des solutions
G Standardisation par l’OMG G
UML 1.1 Novembre 1997 – Documenter un système tout au long du cycle de développement
A Soumission à l’OMG A
G Septembre 1997 G – Communiquer entre les membres de l’équipe de projet
E Soumission à l’OMG UML 1.0 Janvier 1997 E
U Version bêta OOPSLA’96 UML 0.9 Juin 1996 U • C’est une notation qui laisse la liberté de conception
M M
L OOPSLA’95 Méthode unifiée 08 Octobre 1995 L
Booch’93 OMT-2
Autres méthodes Booch’91 OMT-1 OOSE Partenaires
Les diagrammes d ’UML Classification des diagrammes

9 types de diagrammes • L’ensemble des 9 diagrammes peut être réparti sur les trois
– Classes : les classes et les relations statiques Structurel axes de modélisation
L L
A – Objets : les objets et les liens A
N – Cas d’utilisation : les acteurs et l’utilisation du système N
G – Séquence : vision temporelle des interactions Interaction G Fonctionnel
A – Collaboration : vision spatiale des interactions A
Comportement
G – Etats-Transitions : le comportement des objets G Diagramme de cas d’utilisation
E E
– Activité : le flot de contrôle interne aux opérations
Statique dynamique
U – Composants : les composants d’implémentation et leurs U
M relations M
Implémentation Diagramme de classes Diagramme de séquence
L – Déploiement : la structure matérielle et la distribution des L Diagramme d’objets Diagramme de collaboration
objets et des composants Diagramme de composants Diagramme d’états
Diagramme de déploiement Diagramme d’activités
4 nouveaux diagrammes sont ajoutés depuis la version 2.0

– Diagrammes de paquetages, de structures composites, global de collaboration, et de temps
M.BERRADA 7
Les diagrammes d ’UML Les diagrammes d ’UML

• Diagrammes structurels ou diagrammes statiques (UML Structure) • Diagramme Use Case (ou de Cas d'utilisation) : Il répond à la question "qu'est-
– diagramme de classes (Class diagram) ce que les utilisateurs attendent ?", c'est-à-dire les relations entre les acteurs et
L – diagramme d’objets (Object diagram) L les fonctionnalités du système d'information. Niveau fonctionnel, point de vue
A – diagramme de composants (Component diagram)
A
externe.
N N
– diagramme de déploiement (Deployment diagram)
G G
A – diagramme de paquetages (Package diagram) A • Diagramme de Classe est l'ensemble des éléments qui constituent le monde
G – diagramme de structures composites (Composite structure diagram) G réel et les relations qui existent entre ces éléments.
E • Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) E
– diagramme de cas d’utilisation (Use case diagram)
U U • Diagramme d'objets : Il représente les objets et les liens qui les relient, permet
– diagramme d’activités (Activity diagram)
M M de préciser un aspect particulier du diagramme de classe.
– diagramme d’états-transitions (State machine diagram)
L L
– Diagrammes d’interaction (Interaction diagram)
• diagramme de séquence (Sequence diagram) • Diagramme de séquence : Il représente les messages échangés entre les objets
• diagramme de communication (Communication diagram)
qui s'enchaînent de façon séquentielle.
• diagramme global d’interaction (Interaction overview diagram)
• diagramme de temps (Timing diagram)
Les diagrammes d ’UML (2) Les diagrammes d ’UML (3)

• Diagramme State Chart (ou d’états/transitions) : Il définit les règles • UML2 diagramme "interaction overview" ou synthèse des
d'évolution, soit le cycle de vie des objets d'une classe interactions : c'est un mélange des diagrammes de séquence et
L L
A A d'activité.
N • Diagramme d'activité : Il décrit les phases d'évolution du système et N
G modélise les actions effectuées sur le système. Niveau abstrait G • UML2 diagramme de timing : Il décrit les contraintes temporelles sur
A A l'évolution du système.
G G
• Diagramme de communication : montre les relations sémantiquement • UML2 diagramme des packages : Il montre les dépendances des
E E
faibles entre les objets éléments au niveau de la compilation.
U U
M M • UML2 diagramme des structures composites : Comme le diagramme
• Diagramme de composants : Montre le découpage du systèmes en
L unités pouvant être distribuées (logiciels). L des packages, il montre les dépendances des éléments, mais au niveau
de l'exécution.
• Diagramme de déploiement : répartition des matériels : machines,
systèmes d'exploitation et les liens réseaux entre ces machines
Plan 3
• Introduction
L L • Cas d’utilisation : Notation
A A
N N • Relation entre acteurs et cas d’utilisations
G G • Elaboration d’un cas d’utilisation
A
G Diagramme de Cas A
G • Exemple d’application
E E
U
d’Utilisation U
• Conclusion
M M
L L
M.BERRADA 8
Cas d’utilisation : Introduction Cas d’utilisation (Notation)

• Le concept de cas d’utilisation introduit par Ivar Jacobson • Entité qui agit sur le système; représente un
L
dans la méthode Object-Oriented Software Engineering L ensemble cohérent de rôles qu’un utilisateur
A (OOSE). A peut effectuer.
N N Acteur
G G
A • Les fonctionnalités du système sont décrites comme un A
G ensemble de cas d’utilisation. G
E E • Ensemble cohérent de fonctionnalités fournies
par le système ou un sous-système en réponse
U U Cas d’utilisation
M
• Chaque cas représente un flot spécifique d’événements M
à une action de l’utilisateur.
L vers le système. L
• Représentent des relations (liens) entre :

• La description du cas d'utilisation définit ce qui arrive dans Relation – Des CU, des acteurs, les CU et les acteurs
le système lors de sa réalisation.
Représentation d’un Cas d’utilisation Relations entre acteurs et CU

• Association
L L – Représente un chemin de communication entre un acteur et un CU
A A • Multiplicité
N N
– En cas de plusieurs interactions entre un acteur et un cas d’utilisation,
G G
A A – Elle est représenté par un symbole du coté cas d’utilisation
G G • Exemple : * (plusieurs) , n (exactement n), et n..m ( entre n et m)
E E • Cas d’utilisation interne
U U – Quand un cas n’est pas relié directement à un acteur
M M
L L
Relations entre cas d’utilisation (1) Relations entre cas d’utilisation(2)
• On peut distinguer entre 2 types de relations:

L L – Les dépendances stéréotypées
A A • Une dépendance se représente par une flèche avec un trait pointillé
N N
G G <<stéréotype>>
A A
G G • les plus utilisées :
E E – l’inclusion <<include>> : Représente l'insertion d'un « use case » dans
un autre use case
U U – l’extension <<extend>>: Capture comment une ou plusieurs
M M descriptions d’un « use case » intègrent la description d'un autre use
L L case
– La généralisation/spécialisation
• Le symbole utilisé pour la généralisation est un flèche avec un trait pleins
dont la pointe est un triangle fermé désignant le cas le plus général.
M.BERRADA 9
Relation d’inclusion Relation d’extension

• Un cas A inclut un cas B si le comportement décrit par le cas
• Un cas A étend un cas B lorsque le cas A peut être appelé au cours de
A inclut le comportement du cas B : le cas A dépend de B. l’exécution du cas B.
L L
A • Les inclusions permettent : A • Exécuter B peut éventuellement entraîner l’exécution de A :
N N
– factoriser une partie de la description d’un cas d’utilisation qui serait
contrairement à l’inclusion, l’extension est optionnelle.
G G
A commune à d’autres cas d’utilisation A • Une extension est souvent soumise à une condition. Graphiquement, elle
G – décomposer un cas complexe en sous-cas plus simples G est exprimée sous la forme d’une note
E E
U U
M M
L L
Condition : Si le client
n’est pas enregistré
Relation de généralisation/Spécialisation Relations entre acteurs

• La généralisation est la seule relation possible entre deux
• Cette relation de généralisation/spécialisation est présente acteurs
L dans la plupart des diagrammes UML L
• un acteur A est une généralisation d’un acteur B
A • Elle se traduit par le concept d’héritage dans les langages A
N N – si l’acteur A peut être substitué par l’acteur B.
G orientés objet. G – Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais
A • Un cas A est une généralisation d’un cas B si B est un cas A l’inverse n’est pas vrai.
G G
E particulier de A E
U U
M M
L L
Consulter depuis Internet Consulter comptes
Elaboration de CU Cas d'utilisation : Démarche

• quelles sont les tâches de l’acteur ? • Recherche des acteurs externes
L • quelles informations l’acteur doit-il créer, sauvegarder, modifier, L • Pour chaque acteur les cas d'utilisation
A détruire, ou simplement lire ? A
N N • Pour chaque cas d'utilisation :
G • l’acteur doit-il informer le système de changements externes ? G – rechercher les interactions
A • On s’intéresse au domaine du ‘quoi faire’, pas du ‘comment’ (sinon on A – rechercher les objets manipulés
G G
rentre dans la phase de conception) • Faire la maquette de chaque cas d'utilisation
E E
• on doit rester au niveau de l’interaction acteur/système
U U
M M Remarque :Les diagrammes des cas d'utilisation se retrouveront
L L à tous les stades du projet.
M.BERRADA 10
Acteur Catégories et types d’acteurs
• UML n’emploie pas le terme Utilisateur Catégories

L • Rôle joué par une personne ou une chose qui interagit avec L • Acteurs principaux: personnes utilisant le système (à qui va servir le système)
A un système d’une manière directe A • Acteurs secondaires: qui administrent le système (paramètrent le système en lui
N N fournissant les informations nécessaires ou effectuent des m.a.j).
G – La même personne physique peut jouer différents rôles G
A • Correspondre à plusieurs acteurs A Exemple : bibliothèque => l’administrateur est un A.S, le membre est un A.P.
G – Plusieurs personnes peuvent jouer le même rôle G Types
E E
• Correspondre à un seul acteur • Matériel externe: dispositifs matériels faisant partie du domaine de
U U l’application.
M M • Humains : utilisateurs du système.
L • Nom de l’acteur = Rôle joué par l’acteur L
• Logiciels, robots : qui exploitent les données du système.
• Détermination des acteurs par l’identification des différents
rôles
– ==> précision des limites du système de manière progressive
C.U : Caractéristiques (1) CU : Caractéristiques (2)

• Le cas d'utilisation utilise une description textuelle • Identification d'une finalité de l'utilisateur
L • Le cas d'utilisation est un cadre pour l'élaboration des différentes fins L • Un stimulus de départ
A possibles pour le cas d'utilisation A • Une pré-condition du système au déclenchement
N N
G • L'analyse est complète lorsque tous les cas d'utilisation sont étudiés G • Un enchaînement d'interactions
A • Un cas d'utilisation décrit l'échange standard entre un acteur externe et un A
G G
• Une post-condition du système à la fin du cas d’utilisation
système; décrit une famille de scénarios incluant les cas d ’erreur.
E E • Enchaînement d’actions à effectuer
• L'acteur est l'initiateur de l'échange, il peut être:
U U • Une fin normale (conditions d’exécution éventuelles)
– Personne
M M
L – équipement L
– système externe
Description textuelle d’un CU Exemple d’application (1)

• Diagramme de CU pour un système téléphonique
• Une description se compose de trois parties
L 1. Première partie: permet d’identifier le cas, elle doit contenir L
A • Nom: utiliser une tournure à l’infinitif (ex: Retirer de l’argent) A
Téléphone
N • Objectif: Une description résumée N
G G Appeler Téléphone
• Acteurs principaux/secondaires
A A
G • Dates, Responsable et version G Client
E 2. Deuxième partie : contient la description du fonctionnement du cas E Recevoir Appel
• Les préconditions : décrit l’état du système avant le déclenchement de ces cas Opérateur
U d’utilisation U
Interrompre appel
M M
• Des scénarii : ils sont décrits sous la forme d’échanges d’évènements entre
L L
l’acteur et le système (nominal, alternatif et d’exception)
• Des postconditions: décrivent l’état du système à l’issue des différents scénarii • Cas d’utilisation : description générique d’une transaction complète entre
3. Troisième partie: contient des spécifications non fonctionnelles (techniques ) l’acteur et le système (claire et précise).
• une description des besoins en d’interfaces graphiques Remarque : pas d ’interactions entre acteurs
M.BERRADA 11
Exemple d’application (2)

• Description textuelle d’un CU
L – Nom : appeler téléphone
A – Description:
N
G – Acteur principal : client
A
G
– Acteur secondaire : opérateur
E – Pré condition :avoir un crédit suffisant pour l’appel
U – Scénarii :
M • composer le numéro de l’appelant, parler, et finir l’appel
L
• Composer le numéro, fin du crédit et arrêt de l’appel par l’opérateur
• Composer le numéro, l’appelant ne répond plus
– Post condition : communication finie entre l’appellant et
l’appellé
ENSAF 67 M.BERRADA
M.BERRADA 12

Cours UML 1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours UML 1

Transféré par

Droits d'auteur :

Formats disponibles

ENSA de Fès 2015/2016

ENSAF 1 M.BERRADA ENSAF 2 M.BERRADA

ENSAF 3 M.BERRADA ENSAF 4 M.BERRADA

Introduction Introduction (2)

ENSAF 5 M.BERRADA ENSAF 6 M.BERRADA

Définitions Genèse et Objectifs (1)

ENSAF 7 M.BERRADA ENSAF 8 M.BERRADA

Genèse et Objectifs (2) Difficultés liées à la nature du logiciel

ENSAF 9 M.BERRADA ENSAF 10 M.BERRADA

Difficultés liées aux personnes Difficultés technologiques

• beaucoup d ’autodidactes qui croient savoir...

ENSAF 11 M.BERRADA ENSAF 12 M.BERRADA

Le coût de développement... Quelques thèmes tirés par le Génie Logiciel

ENSAF 13 M.BERRADA ENSAF 14 M.BERRADA

Les cycles de vie Les cycles de vie (2)

ENSAF 15 M.BERRADA ENSAF 16 M.BERRADA

Les cycles de vie linéaires Limites du modèle linéaire

ENSAF 17 M.BERRADA ENSAF 18 M.BERRADA

Les cycles de vie itératifs Le cycle en spirale (Boehm)

ENSAF 19 M.BERRADA ENSAF 20 M.BERRADA

Le cycle en spirale (2) Facteurs de qualité logiciel (1)

ENSAF 21 M.BERRADA ENSAF 22 M.BERRADA

Facteurs de qualité logiciel (2) Facteurs de qualité logiciel (3)

ENSAF 23 M.BERRADA ENSAF 24 M.BERRADA

Des méthodes fonctionnelles aux méth.

U – Diffusion des responsabilités U

– Décomposition fonctionnelle descendante

ENSAF 25 M.BERRADA ENSAF 26 M.BERRADA

L’approche fonctionnelle (Exemple) L’approche Objet

ENSAF 27 M.BERRADA ENSAF 28 M.BERRADA

L’approche Objet (Exemple) Evolution des méthodes

ENSAF 29 M.BERRADA ENSAF 30 M.BERRADA

Panorama des méthodes La spécification UML

ENSAF 33 M.BERRADA ENSAF 34 M.BERRADA

La modélisation Concepts de l’approche Objet

Méthodologie OO Méthodes OO de base

ENSAF 37 M.BERRADA ENSAF 38 M.BERRADA

Historique : évolution d’UML

Autres méthodes Booch’91 OMT-1 OOSE Partenaires

ENSAF 39 M.BERRADA ENSAF 40 M.BERRADA

Les diagrammes d ’UML Classification des diagrammes

4 nouveaux diagrammes sont ajoutés depuis la version 2.0

Les diagrammes d ’UML Les diagrammes d ’UML

ENSAF 43 M.BERRADA ENSAF 44 M.BERRADA

Les diagrammes d ’UML (2) Les diagrammes d ’UML (3)

ENSAF 45 M.BERRADA ENSAF 46 M.BERRADA

ENSAF 47 M.BERRADA ENSAF 48 M.BERRADA

Cas d’utilisation : Introduction Cas d’utilisation (Notation)

• Représentent des relations (liens) entre :

ENSAF 49 M.BERRADA ENSAF 50 M.BERRADA

Représentation d’un Cas d’utilisation Relations entre acteurs et CU

ENSAF 51 M.BERRADA ENSAF 52 M.BERRADA

Relations entre cas d’utilisation (1) Relations entre cas d’utilisation(2)

• On peut distinguer entre 2 types de relations:

Relation d’inclusion Relation d’extension

ENSAF 55 M.BERRADA ENSAF 56 M.BERRADA

Relation de généralisation/Spécialisation Relations entre acteurs

Consulter depuis Internet Consulter comptes

ENSAF 57 M.BERRADA ENSAF 58 M.BERRADA

Elaboration de CU Cas d'utilisation : Démarche

ENSAF 59 M.BERRADA ENSAF 60 M.BERRADA

Acteur Catégories et types d’acteurs

• UML n’emploie pas le terme Utilisateur Catégories

ENSAF 61 M.BERRADA ENSAF 62 M.BERRADA