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
[Link]@[Link]

ENSAF 1 [Link] ENSAF 2 [Link]

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

ENSAF 3 [Link] ENSAF 4 [Link]

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

ENSAF 5 [Link] ENSAF 6 [Link]

[Link] 1
ENSA de Fès 2015/2016

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

ENSAF 7 [Link] ENSAF 8 [Link]

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

ENSAF 9 [Link] ENSAF 10 [Link]

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...

ENSAF 11 [Link] ENSAF 12 [Link]

[Link] 2
ENSA de Fès 2015/2016

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

ENSAF 13 [Link] ENSAF 14 [Link]

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

ENSAF 15 [Link] ENSAF 16 [Link]

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...

ENSAF 17 [Link] ENSAF 18 [Link]

[Link] 3
ENSA de Fès 2015/2016

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
– ...

ENSAF 19 [Link] ENSAF 20 [Link]

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»

ENSAF 21 [Link] ENSAF 22 [Link]

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

ENSAF 23 [Link] ENSAF 24 [Link]

[Link] 4
ENSA de Fès 2015/2016

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

ENSAF 25 [Link] ENSAF 26 [Link]

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

ENSAF 27 [Link] ENSAF 28 [Link]

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

ENSAF 29 [Link] ENSAF 30 [Link]

[Link] 5
ENSA de Fès 2015/2016

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)
ENSAF 31 [Link] ENSAF 32 [Link]

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

ENSAF 33 [Link] ENSAF 34 [Link]

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
ENSAF 35 [Link] ENSAF 36 [Link]

[Link] 6
ENSA de Fès 2015/2016

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

ENSAF 37 [Link] ENSAF 38 [Link]

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

ENSAF 39 [Link] ENSAF 40 [Link]

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
ENSAF 41 [Link] ENSAF 42 [Link]

[Link] 7
ENSA de Fès 2015/2016

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)

ENSAF 43 [Link] ENSAF 44 [Link]

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

ENSAF 45 [Link] ENSAF 46 [Link]

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

ENSAF 47 [Link] ENSAF 48 [Link]

[Link] 8
ENSA de Fès 2015/2016

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.

ENSAF 49 [Link] ENSAF 50 [Link]

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

ENSAF 51 [Link] ENSAF 52 [Link]

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.
ENSAF 53 [Link] ENSAF 54 [Link]

[Link] 9
ENSA de Fès 2015/2016

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é

ENSAF 55 [Link] ENSAF 56 [Link]

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

ENSAF 57 [Link] ENSAF 58 [Link]

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.

ENSAF 59 [Link] ENSAF 60 [Link]

[Link] 10
ENSA de Fès 2015/2016

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

ENSAF 61 [Link] ENSAF 62 [Link]

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

ENSAF 63 [Link] ENSAF 64 [Link]

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

ENSAF 65 [Link] ENSAF 66 [Link]

[Link] 11
ENSA de Fès 2015/2016

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 [Link]

[Link] 12