21/03/2023

UML

Youssef khanchoufi
SUPMTI RABAT - LICENCE FONDAMENTALE -
1. La programmation procédurale vs la programmation orientée objet

1. Programmation procédurale
La différence entre la programmation procédurale et la programmation orientée objet (POO) réside
dans le fait que dans la programmation procédurale, les programmes sont basés sur des fonctions, et
les données peuvent être facilement accessibles et modifiables, alors qu’en programmation orientée
objet, chaque programme est constitué d’entités appelées objets, qui ne sont pas facilement
accessibles et modifiables.

Dans la programmation procédurale le programme est divisé en petites parties appelées procédures
ou fonctions.

• Approche : Structure le programme comme une séquence de procédures ou routines (fonctions).

• Organisation : Code organisé autour de fonctions et de blocs de code.

• État et Données : Les données sont généralement séparées des fonctions qui les manipulent,
souvent passées comme arguments.

• Concepts Clés : Procédures (fonctions), variables globales et locales, séquence, itération, et

sélection.

1
 2. Programmation orientée objet (POO)

• Approche : Structure le programme en entités appelées objets, qui sont des instances de classes.

• Organisation : Code organisé autour d'objets qui combinent état (données) et comportement
(méthodes).

• Encapsulation : Les données (attributs) et le code (méthodes) sont regroupés dans des classes.

• Concepts Clés : Classes, objets, héritage, encapsulation, polymorphisme.

Voici un tableau résumé des langages de programmation courants avec leurs dates d'apparition et
une classification selon s'ils sont procéduraux, orientés objet, ou les deux (multi-paradigme) :

2
 3. Maitriser l’analyse/conception orienté objet et le langage UML

Pour maîtriser l'analyse et la conception orientées objet ainsi que le langage UML, voici un résumé
des principales étapes :

Un Projet informatique nécessite une phrase d'analyse, suivi d'une phase de conception.

Phase d'analyse :

Objectif : Comprendre les besoins des utilisateurs ou des clients et déterminer les exigences du
système logiciel à développer.
❖ Comprendre et décrire précisément les besoins des utilisateurs ou des clients.
❖ Identifier les fonctionnalités souhaitées et les usages prévus du logiciel.
❖ Analyser comment les actions devraient fonctionner pour répondre aux besoins.
❖ Cette phase inclut l'analyse des besoins et l'analyse de la solution, après validation de la
compréhension du besoin.

Résultat : Document d'analyse des besoins qui décrit les spécifications du système à développer.

Phase de conception :

Objectif : Concevoir une solution logicielle répondant aux exigences identifiées lors de la phase
d'analyse.

❖ Apporter des détails supplémentaires à la solution envisagée lors de l'analyse.

❖ Clarifier les aspects techniques tels que l'installation des différentes parties logicielles sur le
matériel.
❖ Développer une vue plus détaillée de la solution et des interactions entre ses composants.
❖ Cette phase vise à préciser la solution envisagée lors de l'analyse et à planifier sa mise en œuvre.

Résultat : Document de conception détaillé décrivant l'architecture logicielle, les interactions entre les
composants et les spécifications techniques.

Pour réaliser ces deux phases, différentes méthodes, conventions et notations sont utilisées. Ces
méthodes fournissent des cadres et des approches pour structurer le processus d'analyse et de
conception, tandis que les conventions et les notations fournissent un langage commun pour
documenter et communiquer les spécifications du système.

3
Méthodes :
Agile : Approche itérative qui favorise la livraison continue et la collaboration étroite avec le client.
Elle comprend des cadres tels que Scrum et Kanban.
Développement Piloté par les Tests (TDD) : Méthode où les tests sont écrits avant le code lui-même,
garantissant que le développement se concentre sur les exigences.
Développement Piloté par le Comportement (BDD) : Approche similaire au TDD mais centrée sur les
interactions utilisateur et les comportements du système.
Modèle en Cascade : Approche séquentielle où chaque phase (conception, implémentation, test) doit
être complétée avant de passer à la suivante.

Conventions :
PEP 8 pour Python : Guide de style pour la programmation en Python qui couvre des aspects tels que
la mise en page, la nomination des variables et le style de codage.
Google Java Style Guide : Ensemble de conventions de codage pour les programmes Java, adopté par
de nombreux développeurs Java pour assurer la cohérence et la lisibilité du code.

Notations :

UML (Unified Modeling Language) : Langage de modélisation standardisé utilisé pour spécifier,
visualiser, construire et documenter les artefacts d'un système logiciel.
BPMN (Business Process Model and Notation) : Notation graphique pour décrire les étapes d'un
processus d'affaires, souvent utilisée pour l'analyse et la conception de flux de travail et de processus
d'affaires.
ER (Entity-Relationship Diagram) : Diagrammes utilisés pour modéliser les données et leurs relations
dans des systèmes de bases de données.

4
 4. UML : Analyse et conception POO

UML, ou Langage de Modélisation Unifié, est un langage graphique essentiel dans le développement
logiciel et les systèmes d'information. Son objectif principal est de représenter visuellement les
différents aspects d'un système logiciel, incluant sa structure, son comportement et ses interactions
avec d'autres systèmes.
Utilisations principales de l'UML :
Documentation et Communication :

❖ Permet de documenter les conceptions logicielles de manière graphique.

❖ Facilite la communication entre les membres de l'équipe de développement, les parties
prenantes et les clients.
❖ Les diagrammes UML offrent une représentation visuelle claire des concepts et des relations
entre les différents éléments du système.

Conception :

❖ Utilisé durant la phase de conception des logiciels.

❖ Permet de modéliser la structure statique du système à travers des diagrammes de classes.
❖ Modélise également le comportement dynamique à travers des diagrammes d'activités, de
séquence, d'états, etc.
❖ Aide les concepteurs à visualiser et organiser leurs idées avant de passer à la phase de
développement.

Analyse :

❖ Utilisé pour l'analyse des systèmes.

❖ Aide les analystes à comprendre les exigences du système, à identifier les acteurs et les cas
d'utilisation.
❖ Modélise les flux d'activités et les interactions système pour une meilleure compréhension.

Le terme "unifié" dans "Unified Modeling Language" souligne l'aspect standardisé d'UML, qui intègre
plusieurs techniques et approches de modélisation. Avant l'adoption d'UML, la diversité des langages
de modélisation compliquait la communication entre les équipes et les phases du développement
logiciel. UML a permis d'unifier ces différents langages en fournissant un ensemble standard de
diagrammes et de concepts, favorisant ainsi une meilleure interopérabilité et une compréhension
commune des modèles entre les acteurs du processus de développement logiciel.

5
Pas de méthode spécifique : UML propose une notation et une sémantique associée, mais n'impose
pas de processus spécifique. Il n'est pas considéré comme une méthode en soi. UML n’est pas une
méthode
Approche orientée objet : UML adopte une approche entièrement objet, couvrant l'ensemble du
cycle de développement logiciel, de l'analyse à la réalisation. Il modélise le système en objets
collaborant plutôt qu'en tâches décomposées en fonctions.

Utilisé dans le développement objet : UML est principalement utilisé lors du développement
d'applications avec une approche objet, comme le développement en Java ou en C++.
Applicable à divers domaines : UML est conçu pour modéliser différents types de systèmes, de toutes
tailles et dans tous les domaines d'application, y compris les systèmes temps réel et embarqués.
❖ Systèmes d'information commerciale : Système de gestion des commandes en ligne.
❖ Systèmes embarqués : Logiciel embarqué dans système de navigation GPS.
❖ Systèmes temps réel : Systèmes de contrôle industriels et de trafic aérien.
❖ Systèmes d'information géographique : Systèmes d'information géographique (SIG).

Divisions du système d'information : UML permet de diviser le système d'information d'une

organisation en système métier et système informatique, modélisant les aspects statiques et
dynamiques de l'activité.
Éléments de modélisation et diagrammes : UML se compose d'éléments de modélisation qui
représentent les propriétés du langage, ainsi que de différents types de diagrammes pour exprimer
visuellement et graphiquement les modèles, tels que les diagrammes de cas d'utilisation, de classes,
d'objets, d'états, d'activités, de séquence, de collaboration, de composants et de déploiement.
Processus de développement logiciel : Bien qu'UML n'impose pas de processus spécifique, il est
souvent utilisé dans des processus itératifs (Itération), incrémentaux, centrés sur l'architecture,
pilotés par les cas d'utilisation et pilotés par les risques.
Ingénierie des besoins : UML intègre l'ingénierie des besoins, en particulier les cas d'utilisation, pour
modéliser l'application à partir des besoins des utilisateurs.
Automatisation et génération de code : UML peut être automatisé pour générer du code à partir des
modèles vers différents langages et environnements de programmation.
Genericité, extensibilité et configurabilité : UML est générique, extensible pour couvrir différentes
technologies objet existantes, et configurable selon les besoins du projet.
Intuitif, simple et cohérent : UML vise à être intuitif, simple et cohérent pour faciliter l'utilisation et la
compréhension des modèles.

6
 5. Schéma de la Chronologie et des Contributions à UML
Genèse d'UML
1994 : Naissance d'UML chez Rational Software Corporation.
Initiateurs : Grady Booch et James Rumbaugh.

Influences Méthodologiques
OMT (Object Modeling Technique) => James Rumbaugh => 1991
Booch (Méthode de modélisation de Booch) => Grady Booch => 1992
OOSE (Object Oriented Software Engineering) => Ivar Jacobson => 1992

Fusion : UML est le résultat de la fusion de ces trois méthodes. 1997

Standardisation et Évolution
17 novembre 1997 : UML 1.1 standardisé par l'OMG (Object Management Group).
Contributeurs à la standardisation : Plusieurs entreprises majeures, dont Hewlett Packard, IBM,
Microsoft, Oracle, et bien d'autres.
Dernière version validée : UML 2.5.1 en 2017.

Les Trois Amigos

Equipe d'experts : Grady Booch, James Rumbaugh, et Ivar Jacobson.
Contribution : Compromis trouvé pour intégrer les meilleures pratiques des méthodes OMT, Booch, et
OOSE.

Adoption et Développement
UML comme standard de l'Object Management Group.
Adoption : Large adoption par de nombreuses entreprises renommées.
Développement continu : Participation active à son évolution.

7
6. Modélisation et modèle

Clarifier et Communiquer les Besoins : Transforme les exigences complexes en représentations

visuelles simples, améliorant la communication entre toutes les parties prenantes.
Analyser et Concevoir le Système : Aide à définir l'architecture, les composants et leurs interactions,
identifiant les problèmes de conception en amont.
Documenter le Système : Offre une documentation technique détaillée utile pendant et après le
développement pour la maintenance et les évolutions futures.
Faciliter la Réutilisation : Permet d'identifier et de réutiliser des composants existants, économisant
temps et ressources.
Soutenir le Processus de Développement : Sert de référence à travers toutes les étapes du cycle de vie
du développement logiciel, de l'analyse à la maintenance.
Faciliter la Simulation et le Test : Permet de simuler le comportement du système avant
l'implémentation pour détecter et corriger les erreurs précocement.

8
 7. Comment modéliser avec UML
Un document de texte décrivant de façon précise ce qui doit être réalisé contiendrait plusieurs
dizaines de pages.

UML nous aide à faire cette description de façon graphique et devient alors un excellent moyen pour
"visualiser" le(s) futur(s) logiciel(s).

Transformation d'un document de texte complexe en une représentation visuelle à l'aide d'UML.

Description de façon graphique visualiser = Diagrammes = Plans.

Dans le développement de logiciels, le processus de modélisation, qui utilise des diagrammes, sert un
rôle similaire à celui des plans dans la construction d'une maison. Ces diagrammes sont des outils
essentiels pour visualiser graphiquement la structure et le comportement d'un logiciel, offrant ainsi
une description claire et détaillée des différents composants et de leur interaction.

L'omission de l'analyse des besoins et de la conception adéquate dans le développement logiciel est
similaire à la construction d'une maison sans plans architecturaux : cela mène inévitablement à un
produit final qui risque de ne pas répondre aux attentes, d'être truffé d'erreurs et de devenir un
cauchemar à maintenir.

La modélisation à travers différents types de diagrammes n'est pas une perte de temps, mais une
étape essentielle qui assure que le logiciel répond précisément aux besoins, est structuré
correctement et reste adaptable et maintenable à long terme, malgré l'urgence perçue de sa
réalisation.

9
 8. Les différents types de diagrammes
UML, c’est l’acronyme anglais de « Unified Modeling Language » On le traduit par " Langage de
modélisation unifié ".
La notation UML est un langage visuel constitué d’un ensemble de schémas, appelés des diagrammes
qui donnent chacun une vision différente du projet à traiter.
UML nous fournit donc des diagrammes pour représenter le logiciel à développer son
fonctionnement, sa mise en route, les actions susceptibles d’être effectuées par le logiciel, etc.

Note : Le diagramme de classes est généralement considéré comme l'élément central d'UML.

13 Diagrammes UML : UML dispose de 13 types de diagrammes qui servent à modéliser différents
aspects d'un système informatique, tous basés sur les besoins des utilisateurs.

Aspects Fonctionnels :
Utilisateurs et Utilisation : Identifie qui utilisera le logiciel et dans quel but.
Déroulement des Actions : Modélise le processus et le flux des actions au sein du logiciel.
Gestion des Informations : Détermine quelles informations seront traitées et utilisées par le logiciel.

Aspects Architecturaux :
Composants Logiciels : Définit les différents éléments logiciels du système, tels que les bases de
données, librairies et interfaces.
Infrastructure Matérielle : Précise le matériel sur lequel chaque composant logiciel sera exécuté et
interagira.

UML modélise donc le système logiciel suivant ces deux modes de représentation.

10
 9. Les 4+1 vues d’un système

La conception d’un logiciel est organisée autour des aspects fonctionnels et d’architecture. Ces deux
aspects sont représentés par le schéma de 4 vues, axées sur les besoins des utilisateurs (parfois
intitulé des cas d’utilisation), appelé 4+1 vues.

Une première décomposition d’une problématique ou système peut donc être faite à l’aide de 4+1
vues. Le schéma ci-dessous montre les différentes vues permettant de répondre au mieux aux
besoins des utilisateurs, organisées selon les deux aspects (fonctionnels et architecture). Chacune des
vues est constituée de diagrammes

Dans le modèle des 4+1 vues architecturales, chaque vue est associée à un ensemble de diagrammes
UML qui fournissent une représentation visuelle des différents aspects du système. Les relations entre
les vues et les schémas (diagrammes UML) sont les suivantes :

Vue de Cas d'Utilisation (Scénarios) :

Diagrammes UML associés : Diagrammes de cas d'utilisation.
Relation : Capture les exigences fonctionnelles à travers les interactions entre les acteurs (utilisateurs
ou autres systèmes) et le système.

Vue Logique :
Diagrammes UML associés : Diagrammes de classes, diagrammes d'objets.
Relation : Montre la structure interne du système en termes de classes et d'objets, en lien avec les
fonctionnalités définies dans la vue de cas d'utilisation.

Vue de Développement (Implémentation) :

Diagrammes UML associés : Diagrammes de composants, diagrammes de packages.
Relation : Illustration de l'organisation physique du code et des éléments logiciels, reflétant la
modularité du système.

11
Vue de Processus :
Diagrammes UML associés : Diagrammes d'activités, diagrammes de séquence, diagrammes de
communication.
Relation : Représente les processus (ou threads) du système, leur interaction et le comportement
dynamique du système.

Vue Physique (Déploiement) :

Diagrammes UML associés : Diagrammes de déploiement.
Relation : Décrit la distribution du système sur l'infrastructure matérielle, montrant les relations entre
le logiciel et le matériel.

10.Comment réaliser les diagrammes ?

Pour la création de diagrammes UML, il y a une flexibilité quant à la méthode et aux outils utilisés.
Vous pouvez choisir de dessiner les diagrammes à la main ou d'utiliser des logiciels spécialisés, qu'ils
soient gratuits comme StarUML, ArgoUML, et BOUML, ou payants comme PowerDesigner.
L'important est que les diagrammes soient cohérents les uns avec les autres et reflètent fidèlement
les aspects du système que vous souhaitez modéliser.
UML, en tant que langage de modélisation, ne prescrit aucune démarche spécifique pour son
utilisation ; l'ordre et le type de diagrammes employés sont laissés à la discrétion du développeur ou
de l'équipe de projet.
Ce qui compte avant tout, c'est que les diagrammes soient utilisés efficacement pour planifier et
communiquer la structure et le comportement du logiciel avant de passer à sa construction.

12
 11.Analyse des Besoins ou spécifications des besoins d’un Projet
• L’analyse des besoins, appelée aussi spécifications des besoins
Les premiers besoins seront identifiés grâce aux différents échanger avec le client, afin de découvrir
au fur à mesure ses différents besoins et actions à intégrer dans son projet de logiciel.
• Notre première mission sera donc de décrypter son discours au fur et à mesure afin de préciser ses
besoins. C’est ce qu’on appelle la modélisation des besoins fonctionnels. Nous essaierons donc de
répondre aux questions suivantes :
❖ Qui sont les utilisateurs ?
Les utilisateurs sont ceux qui interagiront directement avec le logiciel, chaque type ayant des besoins
distincts.
❖ Que veulent-ils faire avec le logiciel ?
Les utilisateurs ont des attentes spécifiques en fonction de leur rôle, comme rédiger des textes,
vérifier le contenu, ou simplement lire des documents.

1) Les Étapes d'Analyse de Besoins

1) Étape 1 : Description du Contexte

Décrire le contexte du logiciel à créer : Cela implique de comprendre l'environnement dans lequel le
logiciel sera utilisé et de déterminer les besoins des utilisateurs.
Question clé : À qui le logiciel devra-t-il servir ?
Exemple avec Microsoft Word : Les utilisateurs envisagés incluent les rédacteurs, les vérificateurs, et
les lecteurs.

2) Etape 2 : Décomposition en parties (Packages)

Décomposition fonctionnelle : Le logiciel est divisé en plusieurs packages (Famille) pour simplifier
l'analyse, chacun correspondant à un ensemble ou "Familles" de fonctionnalités liées.
* Question : Pour une partie précise, qui, parmi les acteurs identifiés (ou utilisateurs) l’utilisera ?
Microsoft Word : On peut le décomposer en plusieurs parties ou packages :
* Package "Accueil" : Utilisé par rédacteurs, vérificateurs, et lecteurs pour les fonctionnalités de base
comme la création de nouveaux documents, l'Ouverture de fichiers, Enregistrement.
* Package "Insertion" : Utilisé principalement par les rédacteurs pour ajouter des images, tableaux,
des graphiques, des liens au Document.
* Package "Mise en Page" : Principalement pour les rédacteurs, centré sur la mise en forme avancée
des documents, comme les marges, l'Orientation, la taille de la page.
* Regrouper différentes fonctionnalités d'un logiciel en "familles", que l'on désigne sous le terme de
"packages".

13
 3) Étape 3 : Définition des Cas d'Utilisation
L'étape d'analyse des cas d'utilisation dans le développement de logiciels est essentielle pour
déterminer précisément comment chaque type d'utilisateur interagira avec le logiciel.
Cette analyse permet de spécifier les interactions détaillées entre les utilisateurs et le système, pour
chaque partie du logiciel.
Spécification des interactions : Pour chaque package, précisez les actions que les utilisateurs pourront
exécuter.

Examiner chaque partie (Package) du logiciel séparément pour définir précisément qui pourra
faire quoi avec cette section du Logiciel, en identifiant les différents cas d'utilisation.
Spécifier les actions que chaque type d'utilisateur pourra exécuter dans chaque package ou
partie du Logiciel.
➢ Dans le package "Accueil", le rédacteur peut écrire du texte, modifier la police, la couleur
du texte, et aligner le texte. Ces actions constituent les utilisations de base accessibles à
tous les utilisateurs de ce package.
➢ Dans le package "Révision", le vérificateur a la possibilité d'insérer des commentaires et de
proposer des modifications, tandis que le rédacteur peut accepter ou refuser ces
modifications.

Outils de modélisation :
Diagrammes utilisés :

❖ Diagramme de contexte : pour visualiser les utilisateurs du logiciel.

❖ Diagramme de packages : pour représenter la décomposition en parties distinctes.

❖ Diagramme des cas d'utilisation : pour illustrer les interactions spécifiques des utilisateurs avec le
logiciel.

14
En fait, chaque diagramme est une précision du précédent. C’est comme si enouvrant une grande
boîte en carton, on découvrait d’autres boîtes.

2) Tableau résumant les étapes d'analyse des besoins d'un projet logiciel :

15
 3) TP :
Premier étape Discussion avec le Client et collecte les données :

• Créer la boutique en ligne d’une entreprise de papeterie

Qui est note Client ?

Notre client, Monsieur Morin, est le directeur d’une petite entreprise commerciale, MORIN OFFICE,
spécialisé dans les produits de bureau. Son entreprise est localisée à Blois.

Que vend-il ?
Voici la liste de produit qu’il vend sur place :
• Matériel de base : crayons, stylos, gommes, papier, cahiers, etc.
• Matériel électronique : ordinateurs, imprimantes, téléphones, etc.
• Mobilier : tables, bureaux, chaises, armoires, etc.

Que souhaite-t-il faire sur le site de vente en ligne ?

Lors d’une première discussion avec notre client Monsieur Morin, nous avons pu obtenir les
précisions suivantes :

1) Le client (ou client potentiel) doit pouvoir consulter les produits et éventuellement Procéder à un
achat en ligne.

2) Les commerciaux de la société doivent pouvoir consulter le catalogue des produits en ligne et
enregistrer les achats des clients.
3) Le service des livraisons doit pouvoir consulter les commandes pour préparer les colis et les
livrer au client.
4) Le technicien doit pouvoir vérifier d’éventuelles remarques ou messages signalant un
dysfonctionnement lors de l’achat en ligne.
5) Le service administratif de la société doit pouvoir :
➢ Ajouter de nouveaux produits au catalogue en ligne ;
➢ Modifier les descriptions ou les prix des produits ;
➢ Retirer si besoin des produits que l’on ne souhaite plus proposer.
6) Le directeur, quant à lui, souhaite avoir une vision globale des ventes. À travers le site, il souhaite
pouvoir :
➢ Faire un suivi du chiffre d’affaires par mois, sur une certaine durée ;
➢ Voir quels produits est les plus vendus sur une durée donnée.

16
 1) Etape 1 : Définir le Contexte du futur Logiciel

➢ Identification du Projet :
Le futur logiciel est destiné à créer une boutique en ligne.

➢ La boite noire.
Le futur logiciel correspond à une boite noire qui doit fournir des services à son environnement.
Par environnement, on entend les utilisateurs qui ont besoin de ce logiciel.

➢ Définition du Système :
Dans UML, le logiciel à développer est appelé "système", ici représenté par le site de vente en ligne.

➢ Acteurs du Système :
Les utilisateurs du système sont désignés comme des "acteurs", qui sont les personnes ou entités qui
interagiront avec les diverses fonctionnalités offertes par la boutique en ligne.

Site de Vente en Ligne = Système = Boite noire.

Les Acteurs :
Un acteur correspond à une entité (humain ou non) qui aura une interaction avec le système. Parmi
les acteurs, nous distinguons :
➢ Les acteurs principaux agissent directement sur le système. Il s’agit d’entités qui ont des besoins
d’utilisation du système. On peut donc considérer que les futurs utilisateurs du logiciel sont les
acteurs principaux.
➢ Les acteurs secondaires n’ont pas de besoin direct d’utilisation. Ils peuvent être soit consultés
par le système à développer, soit récepteur d’informations de la part du système. Cela est
généralement un autre système (logiciel) avec lequel le nôtre doit échanger des informations.
➢ Certains acteurs sont de type humain. Ils sont alors représentés par un bonhomme en fil de fer
(parfois appelé « stick man » en anglais) et on indique leur rôle en dessous.

17
Pour représenter un acteur de type non-humain, on peut utiliser une représentation graphique
différente et/ou ajouter une indication supplémentaire (appelé le stéréotype). Vous pouvez voir les
différentes représentations du même acteur dans le schéma suivant :

Le contexte de Notre Projet

Que Souhaite-t-il faire sur le site de Vente en Ligne ?

Les Acteurs principaux : Client, Commercial, Livraison, technicien, administration, Directeur.

Fonctionnalités Souhaitées sur le Site de Vente en Ligne

18
Acteur secondaire - non humain :
Proposition de Paiement en Ligne : Étant donné que le site est de nature commerciale, il est proposé
d'offrir aux clients la possibilité de réaliser des paiements en ligne. Cette fonctionnalité nécessite
une interaction avec des systèmes externes de traitement des paiements, tels que des banques ou
des services de paiement en ligne (exemple : PayPal). Cela implique l'intégration sécurisée de ces
services sur le site pour permettre des transactions fluides et sécurisées.
Identification d'un Acteur Secondaire : Dans le contexte des paiements en ligne, un acteur
secondaire, tel que le système bancaire ou PayPal, est identifié.
Cet acteur est crucial pour le processus de paiement et est représenté symboliquement (par exemple,
avec un "bonhomme de fil de fer" et un stéréotype "système") pour souligner son rôle dans
l'architecture globale du site. Ce rôle externe est essentiel pour le fonctionnement des paiements et
doit être intégré et géré de manière à assurer l'intégrité et la sécurité des transactions.

1) Diagramme de Contexte
Acteurs et Contexte = Système

Contexte = Système :
• Boutique en ligne MORIN OFFICE
• Plateforme e-commerce pour vendre des produits de bureau, des équipements
électroniques et du mobilier.

Acteurs :
Client, Commerciaux de la société, Service des livraison, Technicien, Service administratif,
Directeur.
Systèmes externes (Bancaire, PayPal, etc).

19
 2) Étape 2 : Décomposer le système en parties, dit « package »
Pour clarifier la situation et le processus de développement. Voir clair et pour faciliter la tâche, on
peut découper le futur logiciel en parties distinctes, en fonction des "Familles De Fonctionnalités" et
de façon à pouvoir les analyser séparément.
• Chacune de ces parties ou package correspond à un domaine fonctionnel qui regroupe des
fonctionnalités similaires.
 On ne souhaite pas réaliser des diagrammes énormes qui deviendraient très vite illisibles. On
décompose le logiciel à développer en plusieurs packages, dès que possible.

Essayez d’identifier les parties bien distinctes parmi les fonctionnalités de notre site.
Pour cela, pesez-vous cette question : « Est-ce que le logiciel comporte des parties différentes qui
pourraient être analysées séparément ?
• Deux parties distinctes :
• La partie « Gestion de l’achat » qui contiendrait l’achat à proprement parler, la préparation de la
commande et la vérification des remarques et problèmes liés à l’achat en ligne.
• La partie « Gestion administrative », incluant :
▪ Les tâches liées au catalogue : ajouter ou retirer un produit, modifier le produit, etc.
▪ Les vérifications des ventes : chiffre d’affaires et produits les plus vendus par exemple.

Nous aurons donc deux packages. Un package est représenté sous forme de dossier :

20
N.B: Ne faites pas l’erreur de décomposer le système en fonction des acteurs. Un package (ou une
partie) peut être utilisé par plusieurs acteurs !
Il n’est donc pas utile de faire des packages « client », « livraison », « technicien », « administration »
et « directeur ».

Réaliser le diagramme
Il ne nous reste plus qu’à réaliser le diagramme de packages, en mettant en évidence les acteurs qui
interviennent dans chacun de ces packages.
Pour cela, on représente au centre le Système, qui comprend les deux packages que nous avons
trouvés : la gestion des achats et la Gestion administrative.
Autour de cela, nous devons donc relier les acteurs principaux et secondaires au package
correspondant !

21
Le Client, le Commercial, la Livraison et le Technicien sont les acteurs principaux.
Le système bancaire est l’acteur secondaire du package Gestion des achats.
L’administration et le directeur sont les acteurs principaux du package Gestion administrative.

3) Étape 3 : Les cas d’utilisation

➢ Identification des Acteurs et Packages : Déterminer quels acteurs interagiront avec quelles
grandes familles de fonctionnalités (packages) du logiciel.
➢ Détail des Besoins : Pour chaque acteur, préciser les actions ou séries d'actions (lots d’actions)
qu'ils doivent pouvoir réaliser grâce au logiciel.
Question : Qui devra pouvoir faire Quoi grâce au logiciel ?
Example : Que souhaite faire le technicien sur le site ? Que souhaite faire le client ?
Cas d'Utilisation : Chaque package contient différents cas d'utilisation qui décrivent les
fonctionnalités spécifiques ou les lots d’actions nécessaires pour répondre aux besoins des acteurs.
Structure des Packages : Imaginer le logiciel comme une grande boîte contenant d'autres boîtes
(packages), où chaque package doit être "ouvert" pour explorer son contenu via des diagrammes de
cas d'utilisation.

Les acteurs principaux qui sont liés à un package auront besoin de cette partie du logiciel pour
réaliser une ou plusieurs lots d’actions. Ces lots d’actions sont le contenu de la boite « Package »
Actions vs. Lots d'Actions : Comprendre la différence entre des actions individuelles et des lots
d'actions qui composent une fonctionnalité complète nécessaire à un acteur.
➢ Définition d'une Action : Une action représente une tâche élémentaire ou une opération simple
que l'utilisateur peut réaliser avec le logiciel.
Par exemple, dans un traitement de texte, des actions élémentaires incluent "sélectionner une partie
de texte" ou "choisir une police différente".
➢ Définition d'un Lot d'Actions : Un lot d'actions regroupe plusieurs actions élémentaires qui,
combinées, permettent de réaliser une tâche plus complexe. Cela correspond à une fonctionnalité
complète qui aide l'utilisateur à atteindre un objectif spécifique.
Par exemple, « la mise en forme d’une partie de texte » est un lot d’actions qui peut inclure la
sélection du texte, le choix de la police, l'application d'un style et l'alignement du texte.

➢ Relation entre Actions et Lots d'Actions : Les lots d’actions sont constitués de multiples actions
élémentaires. L'accomplissement d'un lot d'actions implique généralement la réalisation successive
de plusieurs actions simples.

22
Cas d'Utilisation : Un lot d'actions est souvent associé à un cas d’utilisation dans le développement
logiciel. Un cas d’utilisation décrit une séquence d'actions ou un scénario dans lequel des acteurs
(utilisateurs ou autres systèmes) interagissent avec le système pour atteindre un objectif spécifique.
Dans notre exemple, le cas d'utilisation pourrait être « Mettre en forme du texte », qui détaille toutes
les étapes nécessaires pour formater le texte selon les besoins de l'utilisateur.

Un Lot d’actions => Une fonctionnalité dont Acteur ont besoin => Cas d’utilisation

Les diagrammes des Cas d’utilisation => Quelle façon les acteurs utiliseront le logiciel : Qui doit
pouvoir faire QUOI ?

12.Réalisation du diagramme de cas d’utilisation

Cas d’utilisation = Fonctionnalité ou lot d’actions

Pour rappel, les cas d’utilisation principaux sont liés aux acteurs qui en ont besoin. Ils détaillent les
Diagrammes de packages.
Un diagramme des cas d’utilisation est une représentation graphique des interactions entre les
acteurs (utilisateurs ou systèmes externes) et les cas d'utilisation dans un système.
Illustrer visuellement les fonctionnalités du système et la manière dont les acteurs interagissent avec
ces fonctionnalités.
Concentrons-nous sur le package « Gestion des achats » pour en réaliser le diagramme des cas
D’utilisation.
Il faut donc identifier toutes les fonctionnalités dont les différents acteurs concernés par le Package
auront besoin.

Dans le cadre du développement d'une boutique en ligne, le cas d'utilisation "Consulter le catalogue
des produits" décrit la fonctionnalité permettant au client, l'acteur principal, de visualiser les produits
offerts.
"Consulter le Catalogue des produits" => c'est la fonctionnalité que le client peut faire.
Consulter le Catalogue des produits => Cas d'utilisation
Ce cas d'utilisation est typiquement représenté par une ellipse dans les diagrammes de cas
d'utilisation pour modéliser visuellement l'interaction du client avec le système.

23
Un cas d'utilisation peut impliquer plusieurs acteurs ; par exemple, dans une boutique en ligne, à la
fois le client et le commercial peuvent utiliser le même cas d'utilisation "Consulter le catalogue des
produits" pour des besoins différents.

Identifier d'autres fonctionnalités liées aux différents acteurs mentionnés (client, commercial,
livraison, technicien) :

• Le Client souhaite : - Consulter le Catalogue de Produits. - Enregistrer un achat.

• Le Commercial doit pouvoir : - Consulter le Catalogue de Produits. - Enregistrer un achat.
• La livraison (ou les membres du service) souhaite : - Préparer une livraison.
• Le technicien souhaite : - Consulter une remarque ou problème.

Digramme de cas d’utilisation pour le Package « Gestion des achats ».

24
Dans le diagramme de packages, on avait illustré un lien entre le package « Gestion des achats » et un
système externe c’est-à-dire le système bancaire.
Il faut maintenant lier ce système externe au cas d’utilisation qui en a besoin. Il s’agit, bien entendu
du cas d’utilisation « Enregistrer un achat »

Diagramme de Contexte => Diagramme de Package => Diagramme de cas d’utilisation

25
 ✓ En résumé

➢ Un logiciel à développer est donc considéré comme un système, vu au Départ comme une
« boîte noire ».
➢ Le système est utilisé par des acteurs principaux, et parfois, des acteurs secondaires. Les
acteurs secondaires échangent des informations avec le système, mais ne déclenchent
aucune des fonctionnalités.
➢ Un système peut être composé de plusieurs packages. Chacun des packages contient une «
famille » de fonctionnalités nécessaires aux acteurs.
➢ Les fonctionnalités utiles aux acteurs sont appelées des cas d’utilisation.
➢ Un diagramme de cas d’utilisation permet d’illustrer QUI devrait pouvoir faire QUOI, grâce
au système. Il en existe un par package.

13.Résumer :

1- Phase Analyse

• L’analyse est la première phase du processus de développement d’une application.

• C’est le premier modèle construit à partir du cahier des charges.
• Les fonctionnalités sont rassemblées dans des diagrammes de cas d’utilisation.
• Les aspects dynamiques des cas d’utilisation sont les scénarios des processus métier
d’utilisation de l’application.
• Les scénarios sont classiquement représentés dans des diagrammes d’activité.

Acteur représente une personne, un périphérique ou un autre système qui joue un rôle
(interagit) avec le Système.

26
 2- Modèle de l’analyse

Comme suggéré par la figure, l’élément pivot du modèle du système informatique est la vue
cas d’utilisation. Cette vue est la plus proche du client et des utilisateurs finaux.
C’est elle que ces derniers comprennent le mieux.
Elle est complétée par la vue processus qui décrit comment le système répond aux stimulus
externes.
Cette vue processus présente les processus métier, par exemple les règles de gestion d’un
système d’information.
La première vue est composée des diagrammes de cas d’utilisation alors que la seconde
contient les diagrammes d’activité.

Diagramme de cas d’utilisations :

Les cas d’utilisation représentent les fonctionnalités que le système doit satisfaire.

• Les fonctionnalités sont modélisées par des cas d’utilisation

• Un diagramme de cas d’utilisation définit :
• Le système
• Les acteurs
• Les cas d’utilisation (fonctionnalités)
• Les liens entre acteurs et cas d’utilisation
• Quel acteur accède à quel cas d’utilisation ?
• Un modèle de cas d’utilisation se définit par :
• Des diagrammes de cas d’utilisation
• Une description textuelle des scénarios d’utilisation

27
Fonctionnalités et interactions :
Les cas d'utilisation représentent les fonctionnalités essentielles que le système doit offrir.
Ils décrivent les interactions successives entre les utilisateurs (ou autres entités externes) et le
système.

Connaissance et définition :
Permettent de comprendre le comportement attendu du système sans détailler comment ce
comportement est implémenté.
Aident à définir les limites précises du système, clarifiant ce qui est à l'intérieur et à l'extérieur du
périmètre du système.

Attentes et besoins :
Facilitent la compréhension des attentes des utilisateurs et des experts du domaine, en se focalisant
sur les besoins réels sans présupposer des solutions techniques.

Validation et évaluation :
Servent d'instruments pour valider et évaluer l'avancement du système, tant durant sa construction
qu'à sa finalisation.
Offrent des indicateurs simples de progrès (par exemple, le nombre de fonctionnalités implémentées
sur le total prévu) et de réussite (validation via des tests).

Illustration par des diagrammes :

Les scénarios de cas d'utilisation sont souvent illustrés par des diagrammes d'activité, qui montrent
comment les différentes étapes s’agencent pour réaliser les processus métiers.
Les diagrammes de séquence et de communication, bien qu'utiles, sont plus détaillés et mieux
adaptés pour décrire la dynamique interne des sous-systèmes.

Guidance pour le développement :

Les cas d’utilisation guident le processus de développement en fournissant une mesure claire de
l'avancement et de l'efficacité des solutions implémentées.

28
Acteurs : une entité extérieure au système modélisé, et qui interagit directement avec lui.
Les principaux acteurs sont les utilisateurs du système.
Un acteur correspond à un rôle, pas à une personne physique :

• Une même personne physique peut être représentée par plusieurs acteurs si elle a plusieurs rôles.
• Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles seront représentées par un
seul acteur.

14. Relation entre acteurs et cas d’utilisation

A chaque acteur est associé un ou plusieurs cas d’utilisations, la relation d’association peut aussi être
appelée relation de communication
Le lien de communication entre un acteur et un cas d’utilisation indique que l’acteur utilise le système
par cette fonctionnalité : il en a besoin, ou autrement dit, il modifie l’état du système en « exécutant »
cette fonctionnalité.
Le lien de communication montre l’acteur participant au cas d’utilisation.
L’élément de modélisation est appelé dans la terminologie UML une association.
NB : Les diagrammes de cas d’utilisation ajoutent des flèches, appelées navigabilités, aux liens de
communication pour spécifier comment l’acteur est impliqué dans le cas d’utilisation : l’acteur reçoit
des informations ou démarre le cas d’utilisation et fournit de l’information. Cependant, ce n’est pas le
rôle premier du lien de communication ; il est donc préférable de ne pas mettre de navigabilité.

29
 15.Cas d’utilisation interne :
➢ Les cas d'utilisation principaux sont directement associés à un acteur et décrivent ce que
l'utilisateur doit pouvoir faire avec le logiciel à développer. Ce sont les fonctionnalités principales
du logiciel.

• Cas d’utilisation principaux => (Associés) => Acteur

• Cas d’utilisation principaux => Fonctionnalités Principales
➢ Chaque cas d'utilisation principal peut nécessiter plusieurs actions. Parfois, certaines actions
doivent être regroupées dans un ou plusieurs cas d'utilisation complémentaires qui ne sont pas
directement liés à un acteur. On parle alors d’un cas d’utilisation interne

Les cas d’utilisation internes seront indiqués dans le diagramme de cas d’utilisation. Leur
particularité réside dans le fait qu’ils ne seront pas directement liés aux acteurs, mais aux cas
d’utilisation qui en ont besoin.
Les liens (ou relations) entre cas d’utilisation peuvent être divisés en deux groupes :
•La spécialisation.
•Les relations stéréotypées.

30
1) Relation de généralisation spécialisation entre acteurs
• Un premier complément à notre diagramme de cas d’utilisation pourra être mis en œuvre à l’aide
d’une notion appelée « la spécialisation ».
• La spécialisation peut être indiquée à deux niveaux :
• Au niveau des acteurs.
• Au niveau des cas d’utilisation principaux.

1) Au niveau des acteurs ou héritage [ is-a ]

La relation de généralisation spécialisation, aussi appelée relation d’héritage [ est-un ou is-a ], entre
deux acteurs exprime le fait que l’acteur du côté opposé à la pointe de la flèche « est une sorte de ».
Il est spécialisé au sens où il peut réaliser tout ce que l’acteur plus général peut réaliser, plus
d’autres fonctionnalités.
La spécialisation est justifiée si plusieurs acteurs ont besoin d’un ou de plusieurs cas d’utilisation
communs et qu’ils ont également besoin de cas d’utilisation spécifiques.
Utilisation de la spécialisation :
➢ Acteur générique : Est lié aux cas d’utilisations communs.
➢ Acteurs spécialisés : Qui sont liés à des cas d’utilisation spécifiques.
On indique qu’un acteur est la spécialisation d’un autre en dessinant une flèche à pointe fermée vers
l’acteur principal.
Il est spécialisé au sens où il peut réaliser tout ce que l’acteur plus général peut réaliser, plus d’autres
fonctionnalités.

31
Nouvel acteur générique appelé « Acheteur », dont « Client » et « Commercial » sont des
spécialisations.
Nous pouvons alors relier l’acteur générique aux cas d’utilisation « Consulter catalogue produits » et
« Enregistrer un achat ».
Même si les acteurs spécialisés ne sont pas liés à des cas d’utilisation spécifiques, nous pouvons les
laisser dans le diagramme.
• Cela explique quels types d’acteurs sont regroupés sous le nom « Acheteur ». De plus, il se pourrait
que nous découvrions, plus tard, de nouveaux cas d’utilisation qui seraient utiles à l’un ou à l’autre
des utilisateurs spécialisés.

Moto est une sorte de vechiule avec type de moto supplémentaire.

Voiture est une sorte de vechiule avec nombres de port supplémentaire.

32
2) Au niveau des cas d’utilisation principaux

2) Relation entre Cas d’utilisation

Le diagramme de package "Gestion des achats"

Intéressons-nous cette fois-ci au cas d’utilisation « Enregistrer un achat ».

L’objectif ici est de détailler les actions au sein de cette fonctionnalité.
On réalise qu’un acheteur qui enregistre un achat doit forcément constituer un panier (comme cela
est souvent le cas lors d’un achat en ligne).
La constitution du panier Nécessitera plusieurs séquences d’actions :
• Probablement une recherche de produits selon une catégorie ou un nom.
• La consultation de la fiche produit.
• La validation d’un produit à ajouter au panier.

Le cas d'utilisation "Enregistrer un achat", séparées entre les actions ou lot d’actions du client et celles
du commercial

Actions du client

• S'authentifier.
• Constituer un panier.
• Saisir les informations de livraison.
• Enregistrer le règlement de l'achat.

Actions du commercial :

• S'authentifier.
• Sélectionner le client. (Extend)
• Constituer un panier.
• Saisir les informations de livraison.
• Enregistrer le règlement de l'achat.

33
• L'enregistrement d'un achat est plus complexe qu'initialement prévu, nécessitant plusieurs
d'actions détaillées.

• Ces lots d’actions sont donc des précisions du cas d’utilisation « Enregistrer un achat » et peuvent
être considérées comme des cas d'utilisation internes.

• Pour représenter cela dans un diagramme de cas d'utilisation :

✓ Introduire un nouveau cas d'utilisation nommé « Constituer panier », Ce cas d’utilisation sera
toujours nécessaire pour la fonctionnalité « Enregistrer un achat ».
✓ Le nouveau cas d’utilisation interne sera donc lié au cas d’utilisation principal « Enregistrer un
achat » par une flèche représentant la relation dite « Include ».

1) Les relations stéréotypées

Les cas d’utilisation internes sont toujours reliés, par une flèche, au cas d’utilisation initial qui en a
besoin.
Le cas d’utilisation initial peut être un cas d’utilisation principal (donc directement relié à un acteur)
ou à un autre cas d’utilisation interne.
• Ces relations sont appelées des relations stéréotypées car ils définissent le type de lien entre les
cas d’utilisation, qui peuvent être de deux sortes :
• Les relations « include » ;
• Les relations « extend ».

1) La relation de type "Include"

• Est utilisée pour indiquer que le cas d’utilisation source (départ de la flèche) contient TOUJOURS le
cas d’utilisation inclus. Dans la figure précédente, le cas d’utilisation source « Enregistrer un achat »
contiendra TOUJOURS le cas d’utilisation « Constituer un panier ».

34
Représentation de la relation include entre cas d'utilisation dans un diagramme :

➢ Dessiner une flèche en pointillé partant du cas d'utilisation principal vers le cas d'utilisation
interne.
➢ Indiquer le stéréotype « include » sur la flèche pour préciser la nature de la relation.
➢ Dans une relation « include », le cas d’utilisation source est donc celui qui a besoin d’un autre cas
d’utilisation dit interne, indiqué par une flèche.

Dans la version précédente de notre diagramme, l’acteur secondaire « Système bancaire » était lié au
cas d’utilisation « Enregistrer un achat ».
Maintenant que ce cas d’utilisation a été complété par des cas d’utilisation internes, nous pouvons
être plus précis. Nous avons donc déplacé ce lien vers le cas d’utilisation direct : « Enregistrement
règlement ».

2) La relation de type "Extend"

Cette relation est utilisée pour indiquer que le cas d’utilisation source (à l’origine de la flèche) n’est
pas toujours nécessaire au cas d’utilisation principal, mais qu’il peut l’être dans certaines situations.
On doit alors préciser la condition qui fera que le cas d’utilisation en « extend » est nécessaire.

Dans notre cas, le cas d’utilisation interne « Sélectionner le client » n’étant pas une action
obligatoire au cas d’utilisation principal « Enregistrer un achat », on peut dès lors parler de relation «
extend ».

35
Ajout de cette relation se fait en dessinant une flèche en pointillé partant du cas d’utilisation interne
vers le cas d’utilisation principal. Puis, on indique le stéréotype « extend » sur la flèche.
Définir la condition, c’est-à-dire : à quelle condition cette relation peut avoir lieu ? Pour indiquer cela,
il faut ajouter une ligne « extension points » et définir la condition « EXT ».
Le cas d’utilisation « Sélectionner un client » est une relation « extend » du cas d’utilisation principal
« Enregistrer un achat ».
Cette action n’est possible qu’à condition que l’acteur soit le « Commercial », et non pas le « Client ».

Le cas d’utilisation « S’authentifier » peut devenir un package à lui seul. Pour il sera nécessaire pour
tous les cas d’utilisation principaux.
- Example : Seul un utilisateur de type « Livraison » devra avoir accès à la fonctionnalité « Préparer
livraison ». Et le package « Gestion administrative » aura également besoin de ce cas d’utilisation.
On peut donc dans ce cas créer un package spécifique à « Authentifier ».

36
Du coup, le diagramme de cas d’utilisation du package « Gestion des achats » s’en trouve allégé.

2) Relation de généralisation spécialisation

Actions ou lots d’actions pour le cas d’utilisation « Enregistrer un achat »:
Le client doit
S'authentifier
• Soit en se connectant
• Soit en s'inscrivant comme nouveau client
Constituer un panier
• Sélectionner le produit
• Valider le panier
Saisir les informations de livraison
Enregistrer le règlement de l'achat
• Par carte bancaire

Le commercial doit
S'authentifier
• En se connectant
• Sélectionner le client pour lequel on réalise l'achat
Constituer un panier
• Sélectionner le produit
• Valider le panier
Saisir les informations de livraison
Enregistrer le règlement de l'achat
• Soit par carte bancaire
• Soit par chèque

37
Cas d’utilisation « Enregistrement règlement » :

Donc il y a deux variantes du cas d’utilisation « Enregistrement règlement », on peut créer donc deux
nouveaux cas d’utilisation, qui sont spécialisations de « Enregistrement règlement ».
Dans une relation stéréotypée, un cas d’utilisation a besoin d’un autre cas d’utilisation, soit toujours
« include » ou sous certains conditions « extend ».

Dans une spécialisation, on indique que les cas d’utilisation spécialisés sont des versions différentes
du cas d’utilisation générique.

Dans Example : Les deux nouveaux cas d’utilisation « Enregistrement règlement CB » et

« Enregistrement règlement chéque » sont bien 2 versions du cas d’utilisation générique
« Enregistrement règlement ». Ils ont chacun un déroulement spécifique.

En effet, l’enregistrement d’un règlement par chèque n’est possible que lorsqu’un commercial
enregistre l’achat. Notre site web commercial ne serait pas très sûr si on acceptait qu’un client
enregistre un règlement par chèque lui-même. Il pourrait ne pas nous faire parvenir le chèque ! Nous
acceptons donc que seul un commercial puisse enregistrer ce type de règlement, après avoir reçu le
chèque.

Par contre, l’enregistrement d’un règlement par carte bancaire est possible autant pour un client
que pour un commercial. Le client pourra faire cela en ligne, mais le commercial peut également le
faire pour le client lors d’une vente sur site.

Enfin, l’acteur « Système bancaire » n’est utile que dans un des deux cas. Cet acteur n’interviendra
que pour l’action « Enregistrement règlement CB » car seul pour les CB, cet acteur secondaire
vérifiera l’exactitude des informations fournies.

Il y a donc grande différence entre lots d’actions du cas d’utilisation soit enregistrement par carte ou
par chèque.

38
Le diagramme de cas d’utilisation complété

16.Résumer :

39
1) Définir le contexte du futur logiciel – Diagramme de Contexte
Le futur logiciel correspond à une boîte noire qui doit fournir des services à son environnement.
Par environnement, on entend les utilisateurs qui ont besoin de ce logiciel. (Acteur)
Système est donc le site de vente en ligne

Contexte : boutique en ligne de la société.

Acteurs : Client, Commercial, livraison, technicien, administration, directeur.
Contexte + Acteurs = Système.

2) Décomposer le système en parties – Diagramme de Package

En étudiant les différents besoins de nos acteurs sur le logiciel, nous avons pu repérer 3 grandes
familles de fonction : Gestion des achats, Gestion administrative et Authentification. Elles sont
illustrées à l’aide d’un diagramme de package.

40
3) Les cas d’utilisation – Diagramme de cas d’utilisation
Puis, en étudiant dans le détail l’un des packages « Gestion des achats », nous avons défini les
grandes fonctionnalités et les acteurs principaux. Nous avons ainsi réalisé le diagramme de cas
d’utilisation (contenant uniquement des cas d’utilisation principaux).

4) Relation include, extend et spécialisation

Enfin, à travers l’un des cas d’utilisation principaux, nous avons tenté de définir les différents lots
d’actions nécessaires au déroulement de ce cas. Il s’agit des cas d’utilisation internes. Nous avons
d’ailleurs vu les différentes formes de relation qui existent entre les cas d’utilisation principales et les
cas d’utilisation internes, comme les relations « include », « extend » ou de spécialisation. Nous
avons donc réalisé un diagramme de cas d’utilisation détaillé.

41
42