يقدم موقعنا تمارين مصححة في لغات البرمجة مثل C / C ++ و PHP
abdelouafi
Administrator
إذا كنت ترغب في مشاهدة الصور ، يرجى النقر عليها
Blog
SUIVEZ NOTRE CHAINE YOUTUBE: قم بالتسجيل في قناتنا عبر هذا الرابط https://www.youtube.com/channel/UCCITRMWPcElh-96wCS3EyUg
devoir 1 math tronc commun
مجموعة من دروس و فروض جميع المستويات
دروس الإعدادي - دروس الثانوي الثأهيلي - دروس التعليم الابتدائي - فروض مختلف المستويات الدراسيةفضلا و ليس أمرا شارك هذه الصفحة مع أصدقائك:
Dans ce chapitre, nous allons étudier
un des modèles , en l’occurrence le premier à construire : le diagramme de cas d’utilisation.
Il permet de recueillir, d’analyser et d’organiser les besoins. Avec lui débute l’étape d’analyse
d’un système.
1- L’importance de bien recu eillir les besoins
Le développement d’un nouveau système, ou l’amélioration d’un système existant, doit répondre à un ou à plusieurs besoins. Par exemple, une banque a besoin d’un guichet automatique pour que ses clients puissent retirer de l’argent même en dehors des heures d’ouverture de la banque. Celui qui commande le logiciel est le maître d’ouvrage. Celui qui réalise le logiciel est le maître d’oeuvre.
Le maître d’ouvrage intervient constamment au cours du projet, notamment pour :
définir e • t exprimer les besoins ;
• valider les solutions proposées par le maître d’oeuvre ;
• valider le produit livré.
2- Le diagramme d e cas d’utilisation
Parlons à présent d’UML et voyons quelle aide il peut apporter lors du recueil des
besoins. UML n’est qu’un langage et il ne sert ici qu’à formaliser les besoins, c’est-à-dire
à les représenter sous une forme graphique suffisamment simple pour être compréhensible
par toutes les personnes impliquées dans le projet. N’oublions pas que bien souvent,
le maître d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un
moyen simple d’exprimer leurs besoins. C’est précisément le rôle des diagrammes de cas
d’utilisation. Ils permettent de recenser les grandes fonctionnalités d’un système.
Exemple
La fi gure 1.1 modélise une borne interactive qui permet d’accéder à une banque. Le système
à modéliser apparaît dans un cadre (cela permet de séparer le système à modéliser du monde
extérieur). Les utilisateurs sont représentés par des petits bonshommes, et les grandes fonctionnalités
(les cas d’utilisation) par des ellipses.
L’ensemble des cas d’utilisation contenus dans le cadre constitue « un sujet ». Les petits
bonshommes sont appelés « acteurs ». Ils sont connectés par de simples traits (appelés
« associations ») aux cas d’utilisation et mettent en évidence les interactions possibles
entre le système et le monde extérieur. Chaque cas modélise une façon particulière et
cohérente d’utiliser un système pour un acteur donné.
Défi nition
Un cas d’utilisation est une manière spécifi que d’utiliser un système. Les acteurs sont à l’extérieur
du système ; ils modélisent tout ce qui interagit avec lui. Un cas d’utilisation réalise un service de
bout en bout, avec un déclenchement, un déroulement et une fi n, pour l’acteur qui l’initie.
Notation et spécifi cation
Un cas d’utilisation se représente par une ellipse (fi gure 1.2). Le nom du cas est inclus dans l’ellipse
ou bien il fi gure dessous. Un stéréotype (voir la défi nition ci-après), peut être ajouté optionnellement
au-dessus du nom, et une liste de propriétés placée au-dessous.
Un cas d’utilisation se représente aussi sous la forme d’un rectangle à deux compartiments : celui
du haut contient le nom du cas ainsi qu’une ellipse (symbole d’un cas d’utilisation) ; celui du bas
est optionnel et peut contenir une liste de propriétés (fi gure 1.3).
Un acteur se représente par un petit bonhomme ayant son nom inscrit dessous (fi gure 1.1) ou
par un rectangle contenant le stéréotype acteur avec son nom juste en dessous (fi gure 1.4). Il est
recommandé d’ajouter un commentaire sur l’acteur pour préciser son rôle.
Défi nition
Un stéréotype représente une variation d’un élément de modèle existant.
À un niveau d’abstraction plus élevé, UML permet de représenter tous les cas d’utilisation
d’un système par un simple rectangle. La figure 1.5 montre comment un tel rectangle
peut remplacer tous les cas d’utilisation de la figure 1.1.
Le rectangle de la figure 1.5 est appelé « classeur ».
Défi nition
Un classeur est un élément de modélisation qui décrit une unité comportementale ou structurelle.
Les acteurs et les cas d’utilisation sont des classeurs. Tout au long de ce livre, on retrouvera
le terme « classeur » car cette notion englobe aussi les classes, des parties d’un système, etc.
Notation
Un classeur se représente par un rectangle contenant éventuellement des compartiments (la
fi gure 1.6 montre comment il est possible de faire fi gurer explicitement des cas d’utilisation dans
un classeur).
2.2 Relations entre acteurs et cas d’utilisation
Un acteur peut utiliser plusieurs fois le même cas d’utilisation.
Exemple
La fi gure 1.7 montre un internaute qui télécharge plusieurs morceaux de musique sur Internet.
Le symbole * qui signifie « plusieurs » est ajouté à l’extrémité du cas et s’appelle une
multiplicité. Plusieurs valeurs sont possibles pour la multiplicité : exactement n s’écrit
tout simplement n, m..n signifie entre m et n, etc. Préciser une multiplicité sur une relation
n’implique pas nécessairement que les cas sont utilisés en même temps.
2.3 Relations entre cas d’utilisation
Pour clarifier un diagramme, UML permet d’établir des relations entre les cas d’utilisation.
Il existe principalement deux types de relations : les dépendances stéréotypées et la
généralisation/spécialisation. Les dépendances stéréotypées sont des dépendances dont
la portée est explicitée par le nom du stéréotype. Les stéréotypes les plus utilisés sont
l’inclusion et l’extension.
• La relation d’inclusion . Un cas A est inclus dans un cas B si le comportement décrit
par le cas A est inclus dans le comportement du cas B : on dit alors que le cas B
dépend de A. Cette dépendance est symbolisée par le stéréotype inclut. Par exemple,
l’accès aux informations d’un compte bancaire inclut nécessairement une phase
d’authentification avec un mot de passe (figure 1.8).
• La relation d’extension . Si le comportement de B peut être étendu par le comportement
de A, on dit alors que A étend B. Une extension est souvent soumise à condition.
Graphiquement, la condition est exprimée sous la forme d’une note. La figure
1.8 présente l’exemple d’une banque où la vérification du solde du compte n’intervient
que si la demande de retrait d’argent dépasse 20 euros.
• La relation de généralisation. Un cas A est une généralisation d’un cas B si B est un
cas particulier de A. À la figure 1.8, la consultation d’un compte bancaire via Internet
est un cas particulier de la consultation. Cette relation de généralisation/spécialisation
est présente dans la plupart des diagrammes UML et se traduit par le concept
d’héritage dans les langages orientés objet.
Les inclusions permettent aussi de décomposer un cas complexe en sous-cas plus simples.
Exemple
À la fi gure 1.9, le modélisateur a jugé que la vente d’un article par correspondance est un problème
complexe et qu’il est important de faire apparaître dans le modèle une décomposition en sous-cas.
Notation et spécifi cation
Une dépendance se représente par une fl èche pointillée. Un stéréotype est souvent ajouté audessus
du trait.
Le stéréotype inclut indique que la relation de dépendance est une inclusion (fi gures 1.8 et 1.9).
Le stéréotype étend indique une extension (fi gure 1.8). L’extension peut intervenir à un point
précis du cas étendu ; ce point s’appelle le point d’extension ; il porte un nom, qui fi gure dans un
compartiment du cas étendu sous la rubrique « point d’extension », et est éventuellement associé
à une contrainte indiquant le moment où l’extension intervient. Une extension est souvent
soumise à une condition (indiquée dans une note attachée à la fl èche pointillée).
Le symbole utilisé pour la généralisation est une fl èche en traits pleins dont la pointe est un
triangle fermé. La fl èche pointe vers le cas le plus général (fi gure 1.8).
Un cas relié à un autre cas peut ne pas être directement accessible à un acteur (figure 1.9).
Un tel cas est appelé « cas interne ».
Défi nition
Un cas d’utilisation est dit « interne » s’il n’est pas relié directement à un acteur.
Les relations entre cas ne sont pas obligatoires. Elles permettent de clarifier et d’enrichir
les cas d’utilisation. Par exemple, à la figure 1.8, rien n’empêche de regrouper les cas
« Consulter comptes » et « Consulter sur Internet » en un seul cas. Cependant, indiquer
dès la phase de recueil des besoins qu’il y a des cas particuliers apporte une information
supplémentaire pertinente. La question à se poser est : faut-il la faire figurer dans le
diagramme de cas d’utilisation ou la prendre en compte plus tard ? La réponse à cette
question ne sera pas toujours la même selon le contexte du projet.
Remarque
Attention à l’orientation des fl èches : si le cas A inclut B on trace la fl èche de A vers B, mais si B
étend A, la fl èche est dirigée de B vers A.
2.4 - Relations entre acteurs:
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 (tous les cas
d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai).
Exemple
La fi gure 1.10 montre que le directeur des ventes est un préposé aux commandes avec un pouvoir
supplémentaire (en plus de pouvoir passer et suivre une commande, il peut gérer le stock).
Le préposé aux commandes ne peut pas gérer le stock.
Notation
Le symbole utilisé pour la généralisation entre acteurs est une fl èche en traits pleins dont la
pointe est un triangle fermé. La fl èche pointe vers l’acteur le plus général.
un des modèles , en l’occurrence le premier à construire : le diagramme de cas d’utilisation.
Il permet de recueillir, d’analyser et d’organiser les besoins. Avec lui débute l’étape d’analyse
d’un système.
1- L’importance de bien recu eillir les besoins
Le développement d’un nouveau système, ou l’amélioration d’un système existant, doit répondre à un ou à plusieurs besoins. Par exemple, une banque a besoin d’un guichet automatique pour que ses clients puissent retirer de l’argent même en dehors des heures d’ouverture de la banque. Celui qui commande le logiciel est le maître d’ouvrage. Celui qui réalise le logiciel est le maître d’oeuvre.
Le maître d’ouvrage intervient constamment au cours du projet, notamment pour :
définir e • t exprimer les besoins ;
• valider les solutions proposées par le maître d’oeuvre ;
• valider le produit livré.
2- Le diagramme d e cas d’utilisation
Parlons à présent d’UML et voyons quelle aide il peut apporter lors du recueil des
besoins. UML n’est qu’un langage et il ne sert ici qu’à formaliser les besoins, c’est-à-dire
à les représenter sous une forme graphique suffisamment simple pour être compréhensible
par toutes les personnes impliquées dans le projet. N’oublions pas que bien souvent,
le maître d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un
moyen simple d’exprimer leurs besoins. C’est précisément le rôle des diagrammes de cas
d’utilisation. Ils permettent de recenser les grandes fonctionnalités d’un système.
Exemple
La fi gure 1.1 modélise une borne interactive qui permet d’accéder à une banque. Le système
à modéliser apparaît dans un cadre (cela permet de séparer le système à modéliser du monde
extérieur). Les utilisateurs sont représentés par des petits bonshommes, et les grandes fonctionnalités
(les cas d’utilisation) par des ellipses.
L’ensemble des cas d’utilisation contenus dans le cadre constitue « un sujet ». Les petits
bonshommes sont appelés « acteurs ». Ils sont connectés par de simples traits (appelés
« associations ») aux cas d’utilisation et mettent en évidence les interactions possibles
entre le système et le monde extérieur. Chaque cas modélise une façon particulière et
cohérente d’utiliser un système pour un acteur donné.
Défi nition
Un cas d’utilisation est une manière spécifi que d’utiliser un système. Les acteurs sont à l’extérieur
du système ; ils modélisent tout ce qui interagit avec lui. Un cas d’utilisation réalise un service de
bout en bout, avec un déclenchement, un déroulement et une fi n, pour l’acteur qui l’initie.
Notation et spécifi cation
Un cas d’utilisation se représente par une ellipse (fi gure 1.2). Le nom du cas est inclus dans l’ellipse
ou bien il fi gure dessous. Un stéréotype (voir la défi nition ci-après), peut être ajouté optionnellement
au-dessus du nom, et une liste de propriétés placée au-dessous.
Un cas d’utilisation se représente aussi sous la forme d’un rectangle à deux compartiments : celui
du haut contient le nom du cas ainsi qu’une ellipse (symbole d’un cas d’utilisation) ; celui du bas
est optionnel et peut contenir une liste de propriétés (fi gure 1.3).
Un acteur se représente par un petit bonhomme ayant son nom inscrit dessous (fi gure 1.1) ou
par un rectangle contenant le stéréotype acteur avec son nom juste en dessous (fi gure 1.4). Il est
recommandé d’ajouter un commentaire sur l’acteur pour préciser son rôle.
Défi nition
Un stéréotype représente une variation d’un élément de modèle existant.
À un niveau d’abstraction plus élevé, UML permet de représenter tous les cas d’utilisation
d’un système par un simple rectangle. La figure 1.5 montre comment un tel rectangle
peut remplacer tous les cas d’utilisation de la figure 1.1.
Le rectangle de la figure 1.5 est appelé « classeur ».
Défi nition
Un classeur est un élément de modélisation qui décrit une unité comportementale ou structurelle.
Les acteurs et les cas d’utilisation sont des classeurs. Tout au long de ce livre, on retrouvera
le terme « classeur » car cette notion englobe aussi les classes, des parties d’un système, etc.
Notation
Un classeur se représente par un rectangle contenant éventuellement des compartiments (la
fi gure 1.6 montre comment il est possible de faire fi gurer explicitement des cas d’utilisation dans
un classeur).
2.2 Relations entre acteurs et cas d’utilisation
Un acteur peut utiliser plusieurs fois le même cas d’utilisation.
Exemple
La fi gure 1.7 montre un internaute qui télécharge plusieurs morceaux de musique sur Internet.
Le symbole * qui signifie « plusieurs » est ajouté à l’extrémité du cas et s’appelle une
multiplicité. Plusieurs valeurs sont possibles pour la multiplicité : exactement n s’écrit
tout simplement n, m..n signifie entre m et n, etc. Préciser une multiplicité sur une relation
n’implique pas nécessairement que les cas sont utilisés en même temps.
2.3 Relations entre cas d’utilisation
Pour clarifier un diagramme, UML permet d’établir des relations entre les cas d’utilisation.
Il existe principalement deux types de relations : les dépendances stéréotypées et la
généralisation/spécialisation. Les dépendances stéréotypées sont des dépendances dont
la portée est explicitée par le nom du stéréotype. Les stéréotypes les plus utilisés sont
l’inclusion et l’extension.
• La relation d’inclusion . Un cas A est inclus dans un cas B si le comportement décrit
par le cas A est inclus dans le comportement du cas B : on dit alors que le cas B
dépend de A. Cette dépendance est symbolisée par le stéréotype inclut. Par exemple,
l’accès aux informations d’un compte bancaire inclut nécessairement une phase
d’authentification avec un mot de passe (figure 1.8).
• La relation d’extension . Si le comportement de B peut être étendu par le comportement
de A, on dit alors que A étend B. Une extension est souvent soumise à condition.
Graphiquement, la condition est exprimée sous la forme d’une note. La figure
1.8 présente l’exemple d’une banque où la vérification du solde du compte n’intervient
que si la demande de retrait d’argent dépasse 20 euros.
• La relation de généralisation. Un cas A est une généralisation d’un cas B si B est un
cas particulier de A. À la figure 1.8, la consultation d’un compte bancaire via Internet
est un cas particulier de la consultation. Cette relation de généralisation/spécialisation
est présente dans la plupart des diagrammes UML et se traduit par le concept
d’héritage dans les langages orientés objet.
Les inclusions permettent aussi de décomposer un cas complexe en sous-cas plus simples.
Exemple
À la fi gure 1.9, le modélisateur a jugé que la vente d’un article par correspondance est un problème
complexe et qu’il est important de faire apparaître dans le modèle une décomposition en sous-cas.
Notation et spécifi cation
Une dépendance se représente par une fl èche pointillée. Un stéréotype est souvent ajouté audessus
du trait.
Le stéréotype inclut indique que la relation de dépendance est une inclusion (fi gures 1.8 et 1.9).
Le stéréotype étend indique une extension (fi gure 1.8). L’extension peut intervenir à un point
précis du cas étendu ; ce point s’appelle le point d’extension ; il porte un nom, qui fi gure dans un
compartiment du cas étendu sous la rubrique « point d’extension », et est éventuellement associé
à une contrainte indiquant le moment où l’extension intervient. Une extension est souvent
soumise à une condition (indiquée dans une note attachée à la fl èche pointillée).
Le symbole utilisé pour la généralisation est une fl èche en traits pleins dont la pointe est un
triangle fermé. La fl èche pointe vers le cas le plus général (fi gure 1.8).
Un cas relié à un autre cas peut ne pas être directement accessible à un acteur (figure 1.9).
Un tel cas est appelé « cas interne ».
Défi nition
Un cas d’utilisation est dit « interne » s’il n’est pas relié directement à un acteur.
Les relations entre cas ne sont pas obligatoires. Elles permettent de clarifier et d’enrichir
les cas d’utilisation. Par exemple, à la figure 1.8, rien n’empêche de regrouper les cas
« Consulter comptes » et « Consulter sur Internet » en un seul cas. Cependant, indiquer
dès la phase de recueil des besoins qu’il y a des cas particuliers apporte une information
supplémentaire pertinente. La question à se poser est : faut-il la faire figurer dans le
diagramme de cas d’utilisation ou la prendre en compte plus tard ? La réponse à cette
question ne sera pas toujours la même selon le contexte du projet.
Remarque
Attention à l’orientation des fl èches : si le cas A inclut B on trace la fl èche de A vers B, mais si B
étend A, la fl èche est dirigée de B vers A.
2.4 - Relations entre acteurs:
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 (tous les cas
d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai).
Exemple
La fi gure 1.10 montre que le directeur des ventes est un préposé aux commandes avec un pouvoir
supplémentaire (en plus de pouvoir passer et suivre une commande, il peut gérer le stock).
Le préposé aux commandes ne peut pas gérer le stock.
Notation
Le symbole utilisé pour la généralisation entre acteurs est une fl èche en traits pleins dont la
pointe est un triangle fermé. La fl èche pointe vers l’acteur le plus général.
