CH1 CH2 CH3 Coo Uml

Conception Orientée Objet (UML)
Chapitre 1 : Introduction
IGE/S5 & SMI/S5

COO-UML
Prof. : M. BENADDY
Contenu

Introduction

UML

Déroulement

25 heures de cours.

10 heures de TD.

12 heures de TP.

Evaluation

Note des Tps / Mini projet

Note de l'examen final

Logiciels et société

Aujourd’hui la société dépend à tous les niveaux
de systèmes informatiques

Banque: comptes, guichets auto., bourse, …

Bureau: courriel, Traitement de texte, Tableur,
…

Transport: véhicules, routes, horaires, ...

Communication: téléphone, vidéo, web, ...

Recherche: bioinformatique,
nanotechnologie, ...

Divertissement: films, jeux, musique, ...
Les logiciels ?

Un logiciel est:

Du code exécutable

Les données associées au programme

Des documents: besoins des usagers, design,
guide d’utilisateur, guide de programmation, etc.

Les logiciels jouent un rôle clé:

Produisent, gèrent et présentent de l’information

Définition : Un logiciel est un ensemble d’entités
nécessaires au fonctionnement d’un processus de
traitement automatique de l’information.
Les logiciels ?

Spécificités du logiciel

Un produit immatériel, dont l’existence est indépendante du
support physique

Semblable à une œuvre d’art (roman, partition…)

Un objet technique fortement contraint

Fonctionne ou ne fonctionne pas

Structure complexe

Relève des modes de travail du domaine technique

Un cycle de production différent

La reproduction pose peu de problèmes, seule la première
copie d’un logiciel a un coût

Production à l’unité

Semblable au Génie Civil (ponts, routes…).
Problématique

Comment faire des logiciels de qualité ? Génie
Logiciel (Software Engineering)

Le génie logiciels ?

Le génie logiciel est un domaine des sciences de
l’ingénieur dont l’objet d’étude est la conception,
la fabrication, et la maintenance des systèmes
informatiques complexes.

Une discipline qui comprend:

Le processus de développement de logiciels

La méthodologie pour l’analyse, la conception,
le développement, la vérification et la
maintenance de logiciels

Des outils qui supportent le processus et la
méthodologie Conception Orientée Objet (UML)

Motivations

La « Crise du logiciel »

Mise en évidence au début des années 70, la crise se
caractérise par

l'absence de maîtrise des projets, au niveau des coûts et
des délais,

la mauvaise qualité des produits: les produits ne répondent
pas aux besoins définis et des erreurs résiduelles
persistent dans le produit final

un stock important de projets en attente faute d'une
gestion rigoureuse

Quelques exemples de logiciels défaillants :

La facture de 0DH...(pas juste)

Motivations 
Mars Pathfinder (1997)

La « Crise du logiciel » 
Concurrence

Mars Spirit Rover (2003)

La fausse attaque de 
Manque de mémoire
missiles (Novembre 1979) 
Inversion dans le système de bord
du F16

La panne AT&T (1990) 
L’avion se serait retourné à

L’échec d’Ariane 5 (1996) chaque fois qu’il traversait

La poste (1998) l’équateur

Panne de courant en Amérique du

Les anti-missiles Patriotes nord (2003)
(Guerre du Golfe 1991) 
Problème de concurrence

Samy / MySpace XSS (2005)

Les sondes perdues 
Debian / OpenSSL (2008)

vers Vénus( années 60)

vers Mars (99)
Plus d'info : http://www5.in.tum.de/~huckle/bugse.html

Motivations

La « Crise du logiciel »

Et les erreurs que l'on ignore : logiciels de surveillance médicale
défaillants

....et l ’an 2000 (qui a fait dépenser des millions de $ pour des
logiciels développés pour la plupart en pleine crise du logiciel) qui
a finalement été bien absorbée sans provoquer trop de
défaillances.

Etude sur 8 380 projets (Standish Group, 1995)

Succès : 16 %

Problématique : 53 % (budget ou délais non respectés, défaut
de fonctionnalités)

Echec : 31 % (abandonné)

Le taux de succès décroît avec la taille des projets et la taille
des entreprises.

Motivations

Matériel et logiciel

Systèmes informatiques

80 % de logiciel

20 % de matériel

Depuis plusieurs années, la fabrication du matériel
est assurée par quelques fabricants seulement

Le matériel est relativement fiable

Le marche est standardise

Les problèmes liés à l’informatique sont
essentiellement des problèmes de Logiciel.

Le Génie Logiciel

Conférence de l’OTAN à Garmish, Allemagne (1968)

L’informatique ne répond pas aux attentes qu’elle
suscite

L’informatique coûte très cher et désorganise les
entreprises ou organisations

Introduction de l’expression « Génie Logiciel »
(Software Engineering)

Comment faire des logiciels de qualité ?

Qu’attend-on d’un logiciel ? Quels sont les critères
de qualité pour un logiciel ?

Un processus de fabrication original

Le logiciel partage des propriétés
contradictoires avec l’art, les technologies et
le Génie Civil

Les possibilités de réutiliser les savoir-faire
des autres technologies sont (très) limitées

Compte tenu du cycle de production, il faut
bien faire tout de suite « La qualité du
processus de fabrication est garante de la
qualité du produit »
Qualités d’un logiciel

Utilité

Adéquation entre :

Le besoin effectif de l’utilisateur

Les fonctions offertes par le logiciel

Solutions :

Emphase sur l’analyse des besoins

Améliorer la communication (langage commun,
démarche participative)

Travailler avec rigueur.

Utilisabilité

« Effectivité, efficacité et satisfaction avec laquelle des
utilisateurs spécifiés accomplissent des objectifs
spécifiés dans un environnement particulier »

Facilité d’apprentissage : comprendre ce que l’on
peut faire avec le logiciel, et savoir comment le faire

Facilité d’utilisation : importance de l’effort nécessaire
pour utiliser le logiciel à des fins données

Solutions :

Analyse du mode opératoire des utilisateurs

Adapter l’ergonomie des logiciels aux utilisateurs.

Fiabilité

Correction, justesse, conformité : le logiciel est conforme à ses spécifications,
les résultats sont ceux attendus

Robustesse, sûreté : le logiciel fonctionne raisonnablement en toutes
circonstances, rien de catastrophique ne peut survenir, même en dehors des
conditions d’utilisation prévues

Mesures :

MTBF : Mean Time Between Failures

Disponibilité (pourcentage du temps pendant lequel le système est utilisable)
et Taux d’erreur (nombre d’erreurs par KLOC)

Solutions :

Utiliser des méthodes formelles, des langages et des méthodes de
programmation de haut niveau

Vérifications, tests

Progiciels.

Interopérabilité, couplabilité

Un logiciel doit pouvoir interagir en synergie avec
d’autres logiciels

Solutions :

Bases de données (découplage données/traitements)

« Externaliser » certaines fonctions en utilisant des «
Middleware » avec une API (Application Program
Interface) bien définie.

Standardisation des formats de fichiers (XML...) et
des protocoles de communication (CORBA…)

Les ERP (Entreprise Resources Planning).

Performance

Les logiciels doivent satisfaire aux contraintes
de temps d’exécution

Solutions :

Logiciels plus simples

Veiller à la complexité des algorithmes

Machines plus performantes


Portabilité

Un même logiciel doit pouvoir fonctionner sur
plusieurs machines et plusieurs plateformes
(systèmes d'exploitation)

Solutions :

Rendre le logiciel indépendant de son
environnement d’exécution

Machines virtuelles


Réutilisation (ré-utilisabilité)

On peut espérer des gains considérables car dans la
plupart des logiciels :

80 % du code est du « tout venant » qu’on retrouve à
peu près partout

20 % du code est spécifique

Solutions :

Abstraction, généricité

Construire un logiciel à partir de composants prêts à
l’emploi (Développement par composants)

« Design Patterns » (les patrons de conception).

Facilité de maintenance

Objectifs

Réduire la quantité de maintenance corrective (zéro défaut)

Rendre moins coûteuses les autres maintenances

Enjeux

Les coûts de maintenance se jouent très tôt dans le processus
d’élaboration du logiciel

Au fur et à mesure de la dégradation de la structure, la maintenance devient
de plus en plus difficile

Solutions :

Ré-utilisabilité, modularité

Vérifier, tester

Structures de données complexes et algorithmes simples

Anticiper les changements à venir

Facilité de maintenance

Un logiciel ne s’use pas

Pourtant, la maintenance absorbe une très
grosse partie des efforts de développement.

Maintenance d’un logiciel

Maintenance corrective

Corriger les erreurs : défauts d’utilité, d’utilisabilité, de
fiabilité…

Identifier la défaillance, le fonctionnement

Localiser la partie du code responsable

Corriger et estimer l’impact d’une modification

Attention

La plupart des corrections introduisent de nouvelles erreurs

Les coûts de correction augmentent exponentiellement
avec le délai de détection

La maintenance corrective donne lieu à de nouvelles
livraisons (release)

Maintenance adaptative

Ajuster le logiciel pour qu’il continue à remplir
son rôle compte tenu du l’évolution des

Environnements d’exécution

Fonctions à satisfaire

Conditions d’utilisation

Ex : changement de SGBD, de machine, de
systèmes d'exploitation, de taux de TVA, an
2000, euro…


Maintenance perfective, d’extension

Accroître/améliorer les possibilités du logiciel

Ex : les services offerts, l’interface utilisateur,
les performances…

Donne lieu à de nouvelles versions.

Principes utilisés dans le Génie Logiciel

Généralisation : regroupement d’un ensemble de fonctionnalités
semblables en une fonctionnalité paramétrable (généricité, héritage)

Structuration : façon de décomposer un logiciel (utilisation d’une
méthode bottom-up ou top-down)

Abstraction : mécanisme qui permet de présenter un contexte en
exprimant les éléments pertinents et en omettant ceux qui ne le
sont pas

Modularité : décomposition d’un logiciel en composants (modules)
discrets

Documentation : gestion des documents incluant leur identification,
acquisition, production, stockage et distribution

Vérification : détermination du respect des spécifications établies
sur la base des besoins identifiés dans la phase précédente du
cycle de vie.
Cycle de vie
« La qualité du processus de fabrication est garante

de la qualité du produit »

Pour obtenir un logiciel de qualité, il faut en
maîtriser le processus de son élaboration

La vie d’un logiciel est composée de différentes
étapes

La succession de ces étapes forme le cycle de
vie du logiciel

Il faut contrôler la succession de ces différentes
étapes
Composantes du cycle de vie

Étude de faisabilité

Organisation du projet

Spécification

Conception

Implémentation

Tests

Livraison

Maintenance

Étude de faisabilité

Déterminer si le développement proposé vaut
la peine d'être mis en œuvre, compte tenu des
attentes et de la difficulté de développement

Étude de marché : déterminer s’il existe un
marché potentiel pour le produit.


Organisation du projet

Déterminer comment on va développer le logiciel

Analyse des coûts : établir une estimation du prix du
projet

Planification : établir un calendrier de développement

Assurance qualité du logiciel : déterminer les actions
qui permettront de s’assurer de la qualité du produit
fini

Répartition des tâches : hiérarchiser les tâches et
sous-tâches nécessaires au développement du
logiciel


Spécification

Déterminer les fonctionnalités que doit
posséder le logiciel

Collecte des exigences : obtenir de l’utilisateur
ses exigences pour le logiciel

Analyse du domaine : déterminer les tâches et
les structures qui se répètent dans le problème


Conception

Déterminer la façon dont le logiciel fournit les
différentes fonctionnalités recherchées

Conception générale

Conception architecturale : déterminer la
structure du système

Conception des interfaces : déterminer la façon
dont les différentes parties du système agissent
entre elles

Conception détaillée : déterminer les algorithmes
pour les différentes parties du système

Implémentation

Écrire le logiciel (coder les différents
algorithmes déterminés dans la phase de
conception).


Tests : Essayer le logiciel sur des données d’exemple pour s’assurer
qu’il fonctionne correctement

Tests unitaires : faire tester les parties du logiciel par leurs
développeurs

Tests d’intégration : tester pendant l’intégration

Tests de validation : pour acceptation par l’acheteur (le client)

Tests système : tester dans un environnement proche de
l’environnement de production

Tests Alpha : faire tester par le client sur le site de développement

Tests Bêta : faire tester par le client sur le site de production

Tests de régression : enregistrer les résultats des tests et les
comparer à ceux des anciennes versions pour vérifier si la
nouvelle n’en a pas dégradé d’autres

Livraison

Fournir au client une solution logicielle qui
fonctionne correctement

Installation : rendre le logiciel opérationnel
sur le site du client

Formation : enseigner aux utilisateurs à se
servir du logiciel

Assistance : répondre aux questions des
utilisateurs


Maintenance

Mettre à jour et améliorer le logiciel pour
assurer sa pérennité

Pour limiter le temps et les coûts de
maintenance, il faut porter ses efforts sur les
étapes antérieures.

Modèles de cycle de vie d’un logiciel

Modèles linéaires et incrémentaux

Modèles linéaires

Cascade

modèle en V

...

Modèles non linéaires

Prototypage

modèles incrémentaux

modèle en spirale

…
Le cycle de vie en « Cascade »

Ce modèle est
qualifié de modèle
séquentiel linéaire.
Décrit par Royce
en 1970, était alors
la première
modélisation d'une
suite de tâches
standard. Ce
modèle est adapté
pour des projets de
petite taille, et dont
le domaine est bien
maîtrisé.
Le cycle de vie en « V »

Le modèle de cycle
de vie en V part du
principe que les
procédures de
vérification de la
conformité du logiciel
aux spécifications
doivent être
élaborées dès les
phases de
conception. Le
modèle en V est
adapté pour des
projets dont le
domaine est bien
maîtrisé.
Le prototypage

Prototype : version d’essai du logiciel

Pour tester les différents concepts et exigences

Pour montrer aux clients les fonctions que l’on
veut mettre en œuvre

Lorsque le client a donné son accord, le
développement suit souvent un cycle de vie
linéaire

Avantages : Les efforts consacrés au
développement d’un prototype sont le plus souvent
compensés par ceux gagnés à ne pas développer
de fonctions inutiles
Le modèle incrémental de Parnas

Concevoir et livrer au client un sous-ensemble
minimal et fonctionnel du système

Procéder par ajouts d’incréments minimaux
jusqu’à la fin du processus de développement

Avantages : meilleure intégration du client dans
la boucle, produit conforme à ses attentes

Le modèle en Spirale de Boehm

Un modèle mixte

A chaque cycle, recommencer :

Consultation du client

Analyse des risques

Conception

Implémentation

Tests

Planification du prochain cycle

Avantages : meilleure maîtrise des risques, mais
nécessite une (très) grande expérience
Le modèle en Spirale de Boehm

Chapitre 2 : UML (Unified Modeling Language)
IGE/S5 & SMI/S5

COO-UML
Prof. : M. BENADDY
Introduction à UML

Le Langage de Modélisation Unifié, de l'anglais Unified Modeling
Language (UML), est un langage de modélisation graphique à base
de pictogrammes conçu pour fournir une méthode normalisée pour
visualiser la conception d'un système.

Il est couramment utilisé en développement logiciel et en conception
orientée objet.

L'UML est le résultat de la fusion de précédents langages de
modélisation objet : Booch, OMT, OOSE. Principalement issu des
travaux de Grady Booch, James Rumbaugh et Ivar Jacobson.

UML est à présent un standard adopté par l'Object Management
Group (OMG).

UML 1.0 a été normalisé en janvier 1997; UML 2.0 a été adopté par
l'OMG en juillet 2005. La dernière version de la spécification validée
par l'OMG est UML 2.5.1 (2017)
Introduction à UML
UML permet de :


Formaliser la conception d’application

Faciliter la communication entre les différents
intervenants au sein d’un projet informatique

Coordonner les activités entre les différents
intervenants

Gérer l’évolution d’un projet informatique

Proposer des outils standardisés prenant en
compte de nombreux aspects de la conception

Introduction à UML

UML est utilisé pour spécifier, visualiser, modifier et construire les
documents nécessaires au bon développement d'un logiciel orienté
objet. UML offre un standard de modélisation, pour représenter
l'architecture logicielle. Les différents éléments représentables sont
:

Activité d'un objet/logiciel, Acteurs, Processus, Schéma de base
de données, Composants logiciels, Réutilisation de composants.

Remarques :

Grâce aux outils de modélisation UML, il est également possible
de générer automatiquement tout ou partie du code d'une
application logicielle, par exemple en langage Java, à partir des
divers documents réalisés.
 UML n'est pas une méthode, il n'est pas destiné à la mise en œuvre d'un projet,
c'est avant tout un outil d'analyse et de conception en orienté objet, qui
s'appuie sur des notations et des règles syntaxiques spécifiées par l'OMG.
Prof. M. BENADDY Conception Orientée Objet (UML) 49
Diagrammes d’UML

La version actuelle, UML 2.5, propose 14 diagrammes
dont 7 structurels (UML Structure) et 7 comportementaux
(UML Behavior).

A titre de comparaison, UML 1.3 comportait 25 types de
diagrammes.

Diagrammes d’UML

Diagrammes d’UML

Les diagrammes de structure (structure
diagrams) ou diagrammes statiques (static
diagrams) :

définissent la structure statique d'un modèle. Ils sont
utilisés pour modéliser les constituants d'un modèle :
Les classes, les objets, les interfaces et les
composants physiques.

Ils sont utilisés pour modéliser les relations et les
dépendances entre éléments.

Diagrammes d’UML

diagrams) rassemblent :

Diagrammes de classes (Class diagram) : Ils représentent les
classes intervenant dans le système.

Diagrammes d'objets (Object diagram) : Ils montrent comment
les
instances d'éléments structurels sont reliées et utilisées pendant
l'exécution.

Diagrammes de composants (Component diagram) : Ils sont
utilisés pour décrire l'architecture logicielle et les composants
choisis pour mettre en place la solution finale (API, Framework,
typede stockage...).
Diagrammes d’UML


Diagrammes de déploiement (Deployment diagram) : Ils montrent la
disposition physique et matérielle conçue pour héberger et déployer
la système.

Diagrammes de paquetages (Package diagram) : Ils sont utilisés
pour diviser un modèle en terme de conteneurs logiques ou packages.
Ils permettent aussi de décrire les interactions entre packages.

Diagrammes de structures composites (Composite structure
diagram):
Ils fournissent un moyen pour mettre en couches la structure d'un
élément et se focaliser sur un détail interne, sa construction ou ses
relations.
Diagrammes d’UML

Les diagrammes de comportement (behavior
diagrams) :

modélisent le comportement en capturant les variétés
d'interaction et les états instantanés d'un modèle pendant
son «exécution» dans le temps

Diagrammes d’UML


Diagramme des cas d'utilisation (use-case diagram) :
représentation des possibilités d'interaction entre le
système et les acteurs (intervenants extérieurs au
système), c'est-à-dire de toutes les fonctionnalités que
doit fournir le système.

Diagramme états-transitions (state machine diagram) :
représentation sous forme de machine à états finis le
comportement du système ou de ses composants.

Diagramme d'activité (activity diagram) : représentation
sous forme de flux ou d'enchaînement d'activités le
comportement du système ou de ses composants.
Diagrammes d’UML


Diagramme de séquence (sequence diagram) : représentation de
façon séquentielle du déroulement des traitements et des
interactions entre les éléments du système et/ou de ses acteurs.

Diagramme de communication (communication diagram) :
représentation de façon simplifiée d'un diagramme de séquence se
concentrant sur les échanges de messages entre les objets (depuis
UML 2.x).

Diagramme global d'interaction (interaction overview diagram) :
représentation des enchaînements possibles entre les scénarios
préalablement identifiés sous forme de diagrammes de séquences
(variante du diagramme d'activité) (depuis UML 2.x).

Diagramme de temps (timing diagram) : représentation des
variations d'une donnée au cours du temps (depuis UML 2.3).
Diagrammes d’UML

Remarque : Les diagrammes les plus utilisés
sont :

Diagramme de cas d'utilisation,

diagramme de séquence,

diagramme de classes,

diagramme d'états-transitions

et diagramme d'activités.

Chapitre 3 : Diagramme de cas d’utilisation
IGE/S5 & SMI/S5

COO-UML
Prof. : M. BENADDY
Diagrammes de cas d’utilisation

Questions :

Que doit faire le système ?

Il s’agit de définir le quoi ?

Quelles sont les fonctionnalité du système ?

Quels sont les acteurs ?

Quelle relation y’a t-elle entre acteur et système ?


Un cas d’utilisation (use case) représente un
ensemble de séquences d’actions qui sont
réalisées par le système et qui produisent un
résultat observable pour un acteur particulier.

Chaque cas d’utilisation spécifie un
comportement attendu du système considéré
comme un tout, sans imposer le mode de
réalisation de ce comportement.

Un cas d’utilisation permet de décrire ce que le
futur système devra faire, sans spécifier comment
il le fera.

Comment les identifier ? L’ensemble des cas
d’utilisation doit décrire exhaustivement les exigences
fonctionnelles du système. Chaque cas d’utilisation
correspond donc à une fonction métier du système,
selon le point de vue d’un de ses acteurs.

Pour chaque acteur, il convient de :

rechercher les différentes intentions métier avec
lesquelles il utilise le système,

déterminer dans le cahier des charges les services
fonctionnels attendus du système.


Comment les analyser ?

Pour détailler la dynamique du cas d’utilisation, la
procédure la plus évidente consiste à recenser de
façon textuelle toutes les interactions entre les
acteurs et le système. Le cas d’utilisation doit avoir
un début et une fin clairement identifiés. Il faut
également préciser les variantes possibles, telles que
le cas nominal, les différents cas alternatifs et
d’erreur, tout en essayant d’ordonner
séquentiellement les descriptions, afin d’améliorer
leur lisibilité.

Régle : Nommez les cas d’utilisation par un verbe à l’infinitif suivi
d’un complément, du point de vue de l’acteur (et non pas du point
deM. vue
Prof. du système). Conception Orientée Objet (UML)
BENADDY 63

Acteur :

Un acteur représente un rôle joué par une entité externe (utilisateur
humain, dispositif matériel ou autre système) qui interagit
directement avec le système étudié.

Un acteur peut consulter et/ou modifier directement l’état du
système, en émettant et/ou en recevant des messages susceptibles
d’être porteurs de données.

Comment les identifier ? Les acteurs candidats sont
systématiquement :

les utilisateurs humains directs : faites donc en sorte d’identifier tous
les profils possibles, sans oublier l’administrateur, l’opérateur de
maintenance, etc. ;

les autres systèmes connexes qui interagissent aussi directement
avec le système étudié, souvent par le biais de protocoles
bidirectionnels.

Comment représenter un acteur ? La représentation graphique
standard de l’acteur en UML est l’icône appelée stick man, avec le
nom de l’acteur sous le dessin. On peut également figurer un acteur
sous la forme rectangulaire d’une classe, avec le mot-clé <<actor>>.
Une troisième représentation (intermédiaire entre les deux premières)
est également possible avec certains outils, comme cela est indiqué ci-
dessous.

Une bonne recommandation consiste à faire prévaloir l’utilisation de la
forme graphique du stick man pour les acteurs humains et une
représentation rectangulaire pour les systèmes connectés.

Types d’acteurs :

Les acteurs principaux : les personnes qui utilisent
les fonctions principales du système.

Les acteurs secondaires : les personnes qui
effectuent des tâches administratives ou de
maintenance.

Le matériel externe : les dispositifs matériels
incontournables qui font partie du domaine de
l’application et qui doivent être utilisés.

Les autres systèmes : les systèmes avec lesquels le
système doit interagir.


Comment les représenter ? Le diagramme de cas d’utilisation est un
schéma qui montre les cas d’utilisation (ovales) reliés par des
associations (lignes) à leurs acteurs (icône du « stick man », ou
représentation graphique équivalente). Chaque association signifie
simplement « participe à ». Un cas d’utilisation doit être relié à au moins
un acteur.


Relations entre acteurs et cas d'utilisation :

Les acteurs impliqués dans un cas d'utilisation lui sont
liés par une association.

Un acteur peut utiliser plusieurs fois le même cas
d'utilisation et peut participer à plusieurs cas
d’utilisation.


Relations entre les cas d'utilisation :

Inclusion « include »: le cas A inclut le cas B (B est
une partie obligatoire de A).

Extension « exrend »: le cas B étend le cas A (B est
une partie optionnelle de A).

Généralisation : le cas A est une généralisation du
cas du cas B (B est une sorte de A).


Etdue de cas : Guichet Automatique de la Banque

Cette étude de cas concerne un système simplifié de Guichet
Automatique de Banque.

(GAB). Le GAB offre les services suivants :

Distribution d’argent à tout Porteur de carte de crédit, via un
lecteur de carte et un distributeur de billets.

Consultation de solde de compte, dépôt en numéraire et dépôt de
chèques pour les clients porteurs d’une carte de crédit de la
banque adossée au GAB.

A ne pas oublier que :

Toutes les transactions sont sécurisées.

Il est parfois nécessaire de recharger le distributeur, etc.

À partir de ces quatre phrases, nous allons progressivement :

1- identifier les acteurs ; 2- identifier les cas d’utilisation ;

Etdue de cas : Guichet Automatique de la Banque

À partir de ces quatre phrases, nous allons progressivement :

….

3- construire un diagramme de cas d’utilisation ;

4- décrire textuellement les cas d’utilisation ;

5- compléter les descriptions par des diagrammes dynamiques ;

6- organiser et structurer les cas d’utilisation.


Étape 1 – Identification des acteurs du GAB : Quelles sont les entités
externes qui interagissent directement avec le GAB ?

La phrase 1 permet d’identifier immédiatement un premier acteur
évident : tout « Porteur de carte ». Il pourra uniquement utiliser le
GAB pour retirer de l’argent avec sa carte.

Le porteur de carte

La phrase 2 permet d’identifier des services supplémentaires qui ne
sont proposés qu’aux clients de la banque porteurs d’une carte de
crédit de cette dernière. Il s’agit donc d’un profil différent du
précédent, que nous matérialisons par un deuxième acteur, appelé

Client banque



…

La phrase 3 nous incite à prendre en compte le fait que toutes les
transactions sont sécurisées. Mais sécurisées par qui ? Pas par le
GAB. Il existe donc d’autres entités externes qui jouent le rôle de
Système d’autorisation et avec lesquelles le GAB communique
directement.

le Système d’autorisation global Carte Bancaire, pour les
transactions de retrait ;

le Système d’information de la banque, pour autoriser toutes les
transactions effectuées par un client avec sa carte de la banque,
mais également pour accéder au solde des comptes.



…

Enfin, la phrase 4 nous rappelle qu’un GAB nécessite également des
actions de maintenance, telles que le rechargement en billets du
distributeur, la récupération des cartes avalées, etc. Ces actions
de maintenance sont effectuées par un nouvel acteur, que nous
appellerons :

Opérateur de maintenance



Le système étudié peut être illustré par un diagramme de contexte
statique suivant :
Remarque : Bien
que ce diagramme
ne fasse pas partie
des diagrammes
UML « officiels », il
est très souvent
trouvé utile dans
des projets réels.


Étape 2 – Identification des cas d’utilisation : Préparez une liste
préliminaire des cas d’utilisation du GAB, par acteur

Porteur de carte :

Retirer de l’argent.

Client banque :

Retirer de l’argent (à ne pas oublier !).

Consulter le solde de son compte courant.

Déposer du numéraire.

Déposer de l’argent (du numéraire ou des chèques)

Opérateur de maintenance :

Recharger le distributeur.

Maintenir l’état opérationnel (récupérer les cartes avalées, récupérer
les chèques déposés, remplacer le ruban de papier, etc.).

Système d’autorisation (Sys. Auto.) : Néant.

Système d’information (SI) banque : Néant.


Étape 3 – Réalisation de diagrammes de cas d’utilisation : Utiliser un
outils ou manuellement.

Outils gratuits :

Astah Community (free for Students) : nécessite un email
académique

UML Designer

Umbrello

Outils payants :

Rational Software Architect RealTime Edition (IBM)

WinDesign

Eddraw

StarUML


outils.


outils.

Représentation des acteurs secondaires


Description textuelle des cas d’utilisation :

Sommaire d’identification (obligatoire) :

Titre, Résumé, Acteurs, Date de création, Date de mise à jour,
Version, Responsable, …

Description des scénarios (enchaînement) :

Décrit les préconditions, le scénario nominal, les enchaînements
alternatifs, les enchaînements d’erreur et les postconditions

Besoins d’IHM (optionnel) :

Ajouter éventuellement les contraintes d’interface homme-machine :
ce qu’il est nécessaire de montrer, en conjonction avec les
opérations l’utilisateur peut déclencher...

Exigences non fonctionnelles (optionnel) :

Ajouter éventuellement les informations suivantes : fréquence,
volumétrie, disponibilité, fiabilité, intégrité, confidentialité,
performances, concurrence, etc. Ces informations peuvent servir à
mieux évaluer les contraintes techniques, et pourront améliorer, la
capture des besoins opérée en parallèle par l’architecte technique.

Description textuelle des cas d’utilisation : cas GAB

Sommaire d’identification

Titre : Retirer de l’argent

Résumé : ce cas d’utilisation permet à un Porteur de
carte, qui n’est pas client de la banque, de retirer de
l’argent, si son crédit hebdomadaire le permet.

Acteurs : Porteur de carte (principal), Système
d’autorisation (secondaire).

Date de création : 19/09/19 Date de mise à jour :
19/09/19

Version : 1 Responsable : Analyste 1



Description des scénarios

Préconditions :

La caisse du GAB est alimentée (il reste
au moins un billet !).

Aucune carte ne se trouve déjà coincée
dans le lecteur.

La connexion avec le Système
d’autorisation est opérationnelle.




Scénario nominal
1)Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB.
2)Le GAB vérifie que la carte introduite est bien une carte bancaire.
3)Le GAB demande au Porteur de carte de saisir son code d’identification.
4)Le Porteur de carte saisit son code d’identification.
5)Le GAB compare le code d’identification avec celui qui est codé sur la puce
de la carte.
6)Le Système d’autorisation donne son accord et indique le crédit
hebdomadaire.
7)Le GAB demande au Porteur de carte de saisir le montant désiré du retrait.
8)Le Porteur de carte saisit le montant désiré du retrait.
9)Le GAB contrôle le montant demandé par rapport au crédit hebdomadaire.
10)Le GAB demande au Porteur de carte s’il veut un ticket.
11)Le Porteur de carte demande un ticket.
12)Le GAB rend sa carte au Porteur de carte.
13)Le Porteur de carte reprend sa carte.
14)Le GAB délivre les billets et un ticket.
15)Le Porteur de carte prend les billets et le ticket.



Enchaînements alternatifs

A1 : code d’identification provisoirement erroné
L’enchaînement A1 démarre au point 5 du scénario nominal.
6. Le GAB indique au Porteur de carte que le code est erroné, pour la première
ou deuxième fois.
7. Le GAB enregistre l’échec sur la carte.
Le scénario nominal reprend au point 3.

A2 : montant demandé supérieur au crédit hebdomadaire
11. Le GAB indique au Porteur de carte que le montant demandé est supérieur
au crédit hebdomadaire.
Le scénario nominal reprend au point 8

A3 : ticket refusé
12. Le Porteur de carte refuse le ticket.
13. Le GAB rend sa carte au Porteur de carte.
14. Le Porteur de carte reprend sa carte.
15. Le GAB délivre les billets.
84
16. Le Porteur de carte prend les billets.


Enchaînements d’erreur

E1 : carte non-valide

L’enchaînement E1 démarre au point 2 du scénario nominal.

3. Le GAB indique au Porteur que la carte n’est pas valide (illisible,
périmée, etc.), la confisque ; le cas d’utilisation se termine en échec.

E2 : code d’identification définitivement erroné

L’enchaînement E2 démarre au point 5 du scénario nominal.

6. Le GAB indique au Porteur de carte que le code est erroné, pour
la troisième fois.

7. Le GAB confisque la carte.

8. Le Système d’autorisation est informé ; le cas d’utilisation se
termine en échec.



Enchaînements d’erreur

…

E3 : retrait non autorisé

E4 : carte non reprise

E5 : billets non pris

E6 : annulation de la transaction



Postconditions :

La caisse du GAB contient moins de billets qu’au
début du cas d’utilisation (le nombre de billets
manquants est fonction du montant du retrait).

Une transaction de retrait a été enregistrée par le
GAB avec toutes les informations pertinentes
(montant, numéro de carte, date, etc.). Les détails de
la transaction doivent être enregistrés aussi bien en
cas de succès que d’échec.



Exigences non fonctionnelles :

La caisse du GAB contient moins de billets qu’au
début du cas d’utilisation (le nombre de billets
manquants est fonction du montant du retrait).

Une transaction de retrait a été enregistrée par le
GAB avec toutes les informations pertinentes
(montant, numéro de carte, date, etc.). Les détails de
la transaction doivent être enregistrés aussi bien en
cas de succès que d’échec.



Besoins d’IHM :

Les dispositifs d’entrée/sortie à la disposition du Porteur de
carte doivent être :

Un lecteur de carte bancaire.

Un clavier numérique (pour saisir son code), avec des
touches « validation », « correction » et « annulation ».

Un écran pour l’affichage des messages du GAB.

Des touches autour de l’écran pour sélectionner un
montant de retrait parmi ceux qui sont proposés.

Un distributeur de billets.

Un distributeur de tickets.

CH1 CH2 CH3 Coo Uml

Transféré par

Informations du document

Titre original

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

CH1 CH2 CH3 Coo Uml

Transféré par

Droits d'auteur :

Formats disponibles

Conception Orientée Objet (UML)

IGE/S5 & SMI/S5

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

« La qualité du processus de fabrication est garante

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

Conception Orientée Objet (UML)

IGE/S5 & SMI/S5

UML permet de :

Conception Orientée Objet (UML)

Prof. M. BENADDY Conception Orientée Objet (UML) 50

Prof. M. BENADDY Conception Orientée Objet (UML) 51

Prof. M. BENADDY Conception Orientée Objet (UML) 52

Prof. M. BENADDY Conception Orientée Objet (UML) 55

Prof. M. BENADDY Conception Orientée Objet (UML) 58

IGE/S5 & SMI/S5

Prof. M. BENADDY Conception Orientée Objet (UML) 60

Prof. M. BENADDY Conception Orientée Objet (UML) 62

Prof. M. BENADDY Conception Orientée Objet (UML) 66

Prof. M. BENADDY Conception Orientée Objet (UML) 67

Prof. M. BENADDY Conception Orientée Objet (UML) 68

Prof. M. BENADDY Conception Orientée Objet (UML) 69

Prof. M. BENADDY Conception Orientée Objet (UML) 71

Prof. M. BENADDY Conception Orientée Objet (UML) 72

Prof. M. BENADDY Conception Orientée Objet (UML) 73

Prof. M. BENADDY Conception Orientée Objet (UML) 74

Prof. M. BENADDY Conception Orientée Objet (UML) 75

Prof. M. BENADDY Conception Orientée Objet (UML) 76

Prof. M. BENADDY Conception Orientée Objet (UML) 77

Prof. M. BENADDY Conception Orientée Objet (UML) 78

Prof. M. BENADDY Conception Orientée Objet (UML) 79

Prof. M. BENADDY Conception Orientée Objet (UML) 81

Prof. M. BENADDY Conception Orientée Objet (UML) 82

Prof. M. BENADDY Conception Orientée Objet (UML) 85

Prof. M. BENADDY Conception Orientée Objet (UML) 86

Prof. M. BENADDY Conception Orientée Objet (UML) 87

Prof. M. BENADDY Conception Orientée Objet (UML) 88

Vous aimerez peut-être aussi