Diagramme de cas d’utilisation( use case)
o Avant de se lancer dans la réalisation d’un logiciel, Il faut comprendre, clarifier et
structurer les attentes et les besoins du client.
o Un diagramme de cas d’utilisation permet de :
➢ Modéliser les besoins des utilisateurs.
➢ Identifier les grandes fonctionnalités et les limites du système.
➢ Représenter les interactions entre le système et ses utilisateurs.
o Il ne nécessite aucune connaissance informatique
Les éléments d’un diagramme de cas d’utilisation:
Acteurs
o Un acteur est un utilisateur externe au système. Cela peut être :
➢ Une personne.
➢ Du matériel (capteurs, moteurs, relais...).
➢ Un autre système.
o Les acteurs se représentent sous la forme d’un petit personnage
ou sous la forme d’une case rectangulaire (appelé classeur) avec le mot clé « actor ».
<<actor>>
Actor2
Les éléments d’un diagramme de cas d’utilisation:
Cas d’utilisation
o Le cas d’utilisation représente une fonctionnalité du système (visible de l’extérieur du
système).
o Un cas d’utilisation se représente par une ellipse contenant le nom du cas d’utilisation
(phrase commençant par un verbe à l’infinitif).
Nom du cas
Relations entre acteurs et cas d’utilisation:
Relation d’association
o A chaque acteur est associé un ou plusieurs cas d’utilisations, la relation d’association
peut aussi être appelée relation de communication.
o Elle exprime le fait que l’acteur participe à la réalisation d’un cas d’utilisation . C’est la
seule relation qui peut exister entre un acteur et un cas d ’utilisation.
Payer
Consommateur
Relations entre les cas d’utilisation:
Relation d’inclusion
o Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement
du cas B : le cas A dépend de B. Lorsque A est sollicité, B l'est obligatoirement, comme
une partie de A. Cette dépendance est symbolisée par le stéréotype << include >>
o L’inclusion permet de :
Partager une fonctionnalité commune entre plusieurs cas d’utilisation.
Décomposer un cas d’utilisation complexe en décrivant ses sous fonctions
<<include>>
Régler par CB Composer Code
Les Relation entre les cas d’utilisation:
Relation d’extension
o On dit qu'un cas d'utilisation A étend un cas d'utilisation B lorsque le cas d'utilisation A
peut être appelé au cours de l'exécution du cas d'utilisation B. Exécuter B peut
éventuellement entraîner l'exécution de A : contrairement à l'inclusion, l'extension est
optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >>
<<extend>>
Remplir ordre et montant Régler par chèque
o
automatiquement
Relations entre les cas d’utilisation:
Relation de généralisation ou de spécialisation:
o un cas d’utilisation « enfant » hérite du comportement du cas d ’utilisation parent
o La relation de généralisation est représenté par une flèche avec une extrémité
triangulaire.
Payer
Régler par chèque Régler par CB
Relation entre les acteurs
o La seule relation possible entre deux acteurs est la généralisation : un acteur A est une
généralisation d'un acteur B si l'acteur A peut être substitué par l'acteur B. Dans ce cas,
tous les cas d'utilisation accessibles à A le sont aussi à B, mais l'inverse n'est pas vrai.
Exemple d’un diagramme de use case
Modèle Conceptuel des Données (MCD)
o Ensemble de concepts pour modéliser les données d'une application (d'une entreprise).
o Ensemble de symboles graphiques associés.
o Description des données et des relations en termes de:
➢ Entité ou Individu
➢ Relation ou Association
➢ Propriétés ou d’Attributs
Modèle Conceptuel des Données (MCD)
o Objectif : le MCD a pour but de modéliser les données (aspect statique) mémorisées
dans le système d’information ;
o Caractéristiques : Représentation graphique des données à un niveau conceptuel, c’est-
à-dire, sans se préoccuper ni des contraintes d’organisation, ni du gestionnaire de bases
de données utilisées, ni des traitements ;
o MCD Merise : Correspond au modèle Entité-Association.
Modèle conceptuel des données:
Concepts de base
Entité
o Une entité permet de modéliser un ensemble d'objets concrets ou abstraits de même
nature.
Entité
o Une occurrence d’une entité est une instance (un représentant) de l’entité dans le monde
réel ;
Modèle conceptuel des données:
Concepts de base
Modèle conceptuel des données:
Concepts de base
Propriété (ou attribut)
o Une propriété (ou attribut) est une donnée élémentaire qu’on perçoit sur l’entité ;
Modèle conceptuel des données:
Concepts de base
Identifiants (ou Clé)
o Un identifiant aussi appelé clé est un attribut qui permet de retrouver une occurrence
d'entité unique à tout instant parmi celles de l’entité.
Exemple: Numéro dans client
o Un identifiant peut être constitué de plusieurs attributs (clé composée)
Exemple:
• [N°,Rue,Ville] pour Maisons
• [Nom,Prénom] pour Personnes
Modèle conceptuel des données:
Concepts de base
Association ( ou Relation)
o Une relation décrit un lien entre deux ou plusieurs entités.
o Chaque relation possède un nom, généralement un verbe à l'infinitif.
o En général une association relie deux entités ; elle peut toutefois relier une entité avec elle
même (relation réflexive) ou relier trois voire n entités (relation ternaire / n-aire)
o Une relation peut avoir des attributs : on parle d’association porteuse de données
Modèle conceptuel des données:
Concepts de base
Association: Exemple
« Ecrire » est une association entre l’entité « auteur » et l’entité « livre »
Modèle conceptuel des données:
Concepts de base
Cardinalités :
o Les cardinalités précisent la participation de l'entité concernée à la relation.
o Le premier nombre indique la cardinalité minimale, le deuxième la cardinalité maximale.
Cardinalité maximale : le nombre maximum de fois qu’une occurrence d'une entité participe
à une relation. Cette cardinalité vaut souvent 1 ou n, avec n indiquant une valeur >1
Cardinalité minimale : le nombre maximum de fois qu’une occurrence d'une entité participe à
une relation. Cette cardinalité vaut souvent 0 ou 1.
Modèle conceptuel des données:
Concepts de base
Cardinalités : Exemple
Un client peut passer Une commande ne
une ou plusieurs concerne qu’un et un
commandes seul client
