Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2

Avancée

Université Abdelhamid Mehri – Constantine 2

2020-2021. Semestre 1

MODELISATION ORIENTEE OBJET AVANCEE (MOOA)

– Cours 3 –
Chapitre 03 : Diagramme de cas d’utilisation

Staff pédagogique
Nom Grade Faculté/Institut Adresse e-mail
Gueraich Sonia MCB Nouvelles Technologies Sonia.gueraich@univ-constantine2.dz

Etudiants concernés
Faculté/Institut Département Année Spécialité
Nouvelles Technologies TLSI Master1 Système d’Information et Technologie
Web (SITW)

Objectifs du cours 3

L’étudiant est censé comprendre et maitriser les différents concepts liés aux cas d’utilisations.

© Gueraich Sonia Page 1 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

1. Introduction

Ce chapitre suit les premières étapes du processus de développement 2TUP qui sont l’étude préliminaire et
l’expression des besoins afin d’arriver à manipuler les diagrammes de cas utilisations en UML2.

2. L’étude préliminaire

L’étude préliminaire est la toute première étape du processus de développement. Elle permet de faire un
premier repérage des besoins fonctionnels et opérationnels en utilisant principalement du texte ou des
diagrammes très simples. Elle prépare les activités suivantes : capture des besoins fonctionnels et des besoins
techniques.

Objectifs

L’étude préliminaire a pour objectifs principaux :

Etablir un recueil initial des besoins fonctionnels et opérationnels par un cahier des charges
préliminaire.
Modéliser le contexte du système, considéré comme une boite noire en identifiant :
o Les entités externes qui interagissent directement avec lui (acteurs)
o Répertoriant les interactions (émission/réception de message) entre ces acteurs et le système
o Représentant l’ensemble des interactions sur un modèle de contexte dynamique.

2. 1 Cahier des charges

Le cahier des charges (CC) est un préalable à tout projet informatique : étude de l’existant, analyse des
besoins, spécification des caractéristiques fonctionnelles, cadre juridique ; et autant d’aspects qu’il faut pour
un projet réussi.

Remarque :
L’élaboration d’un CC (fonctionnel) débute lorsque la phase de lancement du projet est terminée (charte
de projet validée).

L’élaboration d’un CC (fonctionnel) débute lorsque la phase de lancement du projet est terminé
Un CC doit donc pouvoir :
Définir les objectifs que doit atteindre la solution.
Définir les contraintes à respecter impérativement.
Etre un outil de dialogue entre les différents acteurs.
Diminuer les risques d’erreur lors de la réalisation ou l’installation.

2. 2 Objectifs d’un CC
Préciser les orientations et le champ du domaine étudié.
Analyser l’existant au niveau organisation, documents utilisés, traitements effectués et données
manipulées.
Proposer des solutions d’organisation, fonctionnelles et techniques répondant aux exigences et
besoins exprimés.

© Gueraich Sonia Page 2 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Obtenir une description globale du système (organisationnelle, fonctionnelle, technique, contraintes

majeures de sécurité, de performance, interfaces avec d’autres systèmes, …).
Vérifier la faisabilité organisationnelle et technique.
Aboutir à un choix argumenté d’une solution type de développement.

Remarque :

L’expression des besoins initiée en phase de lancement du projet puis complété en phase d’étude
préliminaire, est contenue dans le CC.

En résumé le CC est un document qui doit être rédigé, sa rédaction doit avoir une structure de base facilitant
la compréhension, i.e. :
Structure claire et simple
Paragraphes courts
Schémas et illustrations
Inspiration d’un modèle ou exemple

Elle repose sur la règle du PPCR (Précis, Prospectif, Concis et Réaliste).

Le CC n’est pas destiné à imposer au prestataire comment il doit réaliser le projet mais à lui expliquer les
besoins et décrire les fonctionnalités cibles.
Un bon document doit uniquement servir d’outil de communication entre professionnel de l’information et
informaticien et déterminer les engagements mutuels. Sa qualité réside dans la clarté, la pertinence et la
lisibilité du contenu.

2.3. Forme d’un CC

La forme du contenu d’un CC diffère mais en général il comporte les parties suivantes:

2.3.1 Présentation du projet

Elle est déduite des différents entretiens avec le client et les futurs utilisateurs du système. L’élaboration de
cette présentation doit être itérative et incrémentale, dans le sens où : l’entretien doit être résumé, les points
flous identifiés et des questions ressorties pour guider le prochain entretien.
Les interviews qui doivent avoir lieu doivent avoir comme objectifs de:
Etudier les informations fournies par le client.
Savoir identifier les points obscurs et les incohérences.
Etablir une liste des questions précises.
Clarifier le sujet et éventuellement reformuler certaines parties.
Travailler sur le vocabulaire et sur l'analyse d'un texte en langue naturel.
Finalement, Tout ce qui n’est pas écrit noir sur blanc n’existe pas.

2.3.2 Grands choix techniques

Cette partie doit définir les choix d’utilisation quant aux :
Processus de développement
Langages de modélisation et de programmation (UML, JAVA)
Architecture (2-tiers ou 3-tiers)
Systèmes et logiciels (Plateforme, SE, Internet) :
Matériel

© Gueraich Sonia Page 3 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

2.3.3 Grands choix fonctionnels

Recenser les traitements informatiques du futur système par analyse première des besoins exprimés par les
employés de l’entreprise
2.3.4. Grands choix opérationnels
Permet d’expliciter les volumes nécessaires et la définition de la sécurité.
D’un point de vue sécuritaire chaque utilisateur du système est identifié et se voit attribué un mot de
passe qui lui permettra d’accéder certaines fonctionnalités du système et pas d’autres. Le profil des
utilisateurs est aussi défini.
D’un point de vue volume de données, des prévisions sont faites quand aux quantités d’informations
qui seront traitées avec leurs fréquences de traitement.
On peut aussi identifier à ce niveau les modes d’opération et quels traitements seront réalisés en
temps réel et lesquels le seront en batch. De la même manière les modes d’opération synchrone et
asynchrone.

3. Description du contexte
Après le premier recueil des besoins, la description du contexte du système commence, elle consiste en trois
activités successives :

3.1. Identification des acteurs

Etudier les entités externes qui interagissent avec le système afin de reconnaître les futurs acteurs.

Acteur : C’est l’abstraction d’un rôle joué par des entités externes du système (utilisateur, dispositif matériel
ou autre système) qui interagissent directement avec le système.
Un acteur peut consulter ou modifier directement l’état du système, en émettant ou en recevant des messages
éventuellement porteurs de données.
Les acteurs candidats sont :
Les utilisateurs humains, dans ce cas il faut identifier les profils possibles sans oublier
l’administrateur, l’opérateur de maintenance ….
Les autres systèmes connexes qui interagissent avec le système

Remarque :
vérifier que les acteurs interagissent directement avec le système, et qu’ils se trouvent bien à
l’extérieur du système.
Un acteur joue un rôle face au système.
Eliminer les acteurs physiques au profit des acteurs logiques : L’acteur bénéficie de l’utilisation
du système et il a une autonomie de décision. Les terminaisons informatiques (imprimante, clavier
de l’agent …). Il faut se concentrer sur les acteurs métiers.

© Gueraich Sonia Page 4 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Représentation de l’acteur :

Figure 3.1 Représentation de l’acteur

Une recommandation répandue consiste à utiliser le stick man pour les acteurs humains et la boite pour les
acteurs non humains.
En UML 2.0, un acteur est considéré comme une méta-classe indépendante il peut avoir :
- un ensemble d’attributs permettant de caractériser son état
- un ensemble de messages
- un diagramme d’état.

3.2. Identification des messages

Message : c’est la spécification d’une communication unidirectionnelle entre objets qui peut transporter de
l’information avec l’intention de déclencher une activité chez le récepteur.
A un haut niveau le message est utilisé pour décrire les interactions entre les acteurs et le système.
Pour chaque acteur, il faut identifier les messages qui déclenchent un comportement attendu du système
par l’acteur.
Pour le système, il faut identifier les messages porteurs d’information émis à l’intention d’un acteur.
Remarques : Les messages entre acteurs ne sont d’aucune utilité.

3.3. Modélisation du contexte

Le diagramme de contexte dynamique : La représentation de tous les messages acteur <-->système

identifiés.
Le formalisme du diagramme de communication (collaboration UML 1.x) est ici utilisé pour représenter le
diagramme de contexte dynamique (objet, lien, sens du message) avec un objet central : le système.

© Gueraich Sonia Page 5 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Figure 3 .2 Diagramme de contexte dynamique Figure 3 .3 Diagramme de contexte statique

Remarque :
il est conseillé de :

décrire textuellement les messages, en leur donnant un titre (créer , modifier client) et même une
description textuelle complète.
Omettre les messages de consultation pure et de connexion/déconnexion du système pour ne pas
surcharger le diagramme.

Le diagramme de contexte statique : La représentation du nombre d’instances d’acteurs reliés au système à

un moment donné. Ce complément (pas nécessaire) est utile dans le cas de système avec un certain nombre
d’acteurs et que l’on désire représenter la multiplicité des instances d’acteurs.
Ce diagramme est représenté au moyen d’un diagramme de classe
Le diagramme de contexte hiérarchique : Ce diagramme est utile dans les cas de grands systèmes dont les
sous-systèmes fonctionnels sont identifiés déjà à ce niveau. Le système est alors représenté comme un objet
composite contenant les différents sous systèmes par une inclusion graphique. Aussi les différents messages
sont répartis aux sous-systèmes concernés. Les principaux messages entre les sous-systèmes deux à deux
sont ajoutés.

Figure 3.4 Diagramme de contexte hiérarchique

© Gueraich Sonia Page 6 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

4. Capture des besoins fonctionnels

Durant cette phase les diagrammes UML sont utilisés pour compléter la capture des besoins fonctionnels
ébauchée dans la phase d’étude préliminaire. Les cas d’utilisation sont la pierre angulaire qui va permettre
d’étudier avec précision le contexte fonctionnel du système.

4.1 Identification des cas d’utilisation

4.1.1 Définition
Un cas d’utilisation est une manière spécifique 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 fin, pour l’acteur qui l’initie. Donc, il exprime une interaction
acteur système et apporte une valeur ajoutée notable pour l’acteur concerné.
Un C.U. décrit ce que le futur système devra faire sans dire comment ce sera fait. Chaque C.U. doit
correspondre à une fonction métier du système selon le point de vue d’un de ses acteurs.
L’ensemble des C.U. doit décrire exhaustivement les exigences fonctionnelles du système.
Pour chaque C.U. identifié, il faut vérifier :

Qu’il fournit une valeur ajoutée notable à l’acteur dans le cadre de son métier
Qu’un événement externe au système en déclenche l’exécution.
Qu’il n’est pas réduit à une action, mais qu’il représente une séquence d’actions réalisées par le
système.
4.1.2 Notations et spécifications

La pratique des CUs via leurs notations est présentée dans la partie TD, néanmoins la description des
différentes notations est donnée dans ce qui suit.

Un cas d’utilisation se représente par une ellipse ( Le nom du cas est inclus dans
l’ellipse ou bien il figure dessous). Un stéréotype 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 (figure ).

Figure 3 .5 Représentations d’un cas d’utilisation

© Gueraich Sonia Page 7 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Remarque :
il est conseillé de :

Un stéréotype représente une variation d’un élément de modèle existant.

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 figure montre comment il est possible de faire figurer explicitement des cas d’utilisation dans
un classeur).

Figure 3 .6 Un classeur de cas d’utilisations

4.2 Acteur principal/acteur secondaire

4.2.1 Définition
L’acteur principal est l’acteur pour lequel le système fournit une plus-value métier. C’est généralement lui
qui déclenche le C.U.
Par opposition, l’acteur secondaire représente tous les autres participants du C.U. qui sont sollicités par le
système pour obtenir des informations complémentaires pour sa réalisation.

4.2.2 Notations
Un acteur se représente par un petit bonhomme ayant son nom inscrit (voir paragraphe 3.3.1) ou par un
rectangle contenant le stéréotype acteur avec son nom juste en dessous. Il est recommandé d’ajouter un
commentaire sur l’acteur pour préciser son rôle.

Figure 3 .7 Autre représentation d’un acteur

© Gueraich Sonia Page 8 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Un acteur peut utiliser plusieurs fois le même cas d’utilisation La figure suivante 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.

Figure 3 .8 Association avec multiplicité

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 suivante)

Figure 3 .9 Relations entre cas

© Gueraich Sonia Page 9 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Les inclusions permettent aussi de décomposer un cas complexe en sous-cas plus simples.
-

Figure 3 .10 Décomposition de cas

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 3.9 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épassant une certaine somme.

En UML, une dépendance se représente par une flèche pointillée. Un stéréotype est souvent ajouté
au-dessus du trait. Le stéréotype inclut indique que la relation de dépendance est une inclusion. Le
stéréotype étend indique une extension
En UML2 l’extension peut intervenir à un point précis du cas é tendu, ce point s’appelle le point
d’extension ; il porte un nom, qui figure 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) (figure 3.9).

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. Par exemple, 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. 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.

Un cas d’utilisation est dit « interne » s’il n’est pas relié directement à un acteur.

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). Par exemple la figure suivante 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

© Gueraich Sonia Page 10 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Figure 3 .11 Relations entre acteurs

4.3 Organisation des cas d’utilisation

Les cas d’utilisation peuvent être regroupés selon différents critères afin de répartir la charge de travail ou de
distribuer les tâches. Les critères de regroupement peuvent être :
Par domaine d’expertise : identifier des sous-domaines dans l’étude générale
Par acteur : si les acteurs des C.Us identifiés sont distincts
Par lot de livraison : dans le cadre d’un développement itératif et incrémental, on peut être appelé à
réunir en package les CU livrables ensembles.
Un paquetage permet d’organiser des éléments de modélisation en groupe. Un paquetage peut contenir des
classes, des cas d’utilisations, des interfaces, etc.
A la figure 3.12, trois paquetages ont été créés : Client, Stock et Support. Ces paquetages contiennent des cas
d’utilisation: Client contient les cas « Passer une commande » et « Suivre une commande », Stock contient le
cas « Gérer le
stock », tandis que le cas « Rechercher article » est inclus dans le paquetage Support.

Figure 3 .12 Relations entre acteurs

4.4 Objectifs des C.U

© Gueraich Sonia Page 11 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

L’identification des C.U. doit être faite d’une manière précise car ce sont eux qui vont guider toute la phase
d’analyse. L’identification des C.U. doit avoir comme objectifs de:

Dialoguer avec le client

Analyser les besoins métier
Aider à démarrer l’analyse O.O et identifier les classes candidates

4.5 Description des C.U

Il existe différentes façons pour décrire les cas ; telles que la description textuelle ou par diagrammes.

Figure 3 .13 Descriptions des CUs

4.5.1 Description textuelle

Bien que de nombreux diagrammes d’UML permettent de décrire un cas, il est recommandé de rédiger une
description textuelle car c’est une forme souple qui convient dans bien des situations. Une description
textuelle couramment utilisée se compose de trois parties.
La première partie permet d’identifier le cas. Elle doit contenir :

le nom du cas ;
un résumé de son objectif ;
les acteurs impliqués (principaux et secondaires) ;
les dates de création et de mise à jour de la description courante ;
le nom des responsables ;
un numéro de version.

La deuxième partie contient la description du fonctionnement du cas sous la forme d’une séquence de
messages échangés entre les acteurs et le système. Elle contient toujours une séquence nominale qui
correspond au fonctionnement nominal du cas (par exemple, un retrait d’argent qui se termine par
l’obtention des billets demandés par l’utilisateur). Cette séquence nominale commence par préciser
l’événement qui déclenche le cas (l’utilisateur introduit sa carte bancaire par exemple) et se développe
en trois points :

© Gueraich Sonia Page 12 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Les pré-conditions. Elles indiquent dans quel état est le système avant que se déroule la séquence (le
distributeur est alimenté en billets par exemple).
L’enchaînement des messages.
Les post-conditions. Elles indiquent dans quel état se trouve le système après le déroulement de la
séquence nominale (une transaction a été enregistrée par la banque par exemple).

Parfois la séquence correspondant à un cas a besoin d’être appelée dans une autre séquence (par exemple
quand une relation d’inclusion existe entre deux cas d’utilisation). Signifier l’appel d’une autre séquence se
fait de la façon suivante : « appel du cas X », où X est le nom du cas.
Les acteurs n’étant pas sous le contrôle du système, ils peuvent avoir des comportements imprévisibles. La
séquence nominale ne suffit donc pas pour décrire tous les comportements possibles.
A la séquence nominale s’ajoutent fréquemment des séquences alternatives et des séquences d’exceptions.
Ces deux types de séquences se décrivent de la même façon que la séquence nominale mais il ne faut pas les
confondre.
Une séquence alternative diverge de la séquence nominale (c’est un embranchement dans une séquence
nominale) mais y revient toujours, alors qu’une séquence d’exception intervient quand une erreur se produit
(le séquencement nominal s’interrompt, sans retour à la séquence nominale) (un exemple de la description
textuelle est explicitée dans le TD).
La description de C.U doit être complétée par des diagrammes dynamiques simples.
4.5.2 Description par les diagrammes

Diagramme de séquence : représentant uniquement l’interaction acteur-système.

Diagramme d’activité : représentant l’activité globale du C.U et le traitement en cas d’exception.
Diagramme de communication : représentant l’interaction nécessaire pour réaliser le C.U., elle fait aussi
ressortir les objets candidats.

4.6 Les exigences non fonctionnelles

Les exigences non fonctionnelles représentent des nécessités identifiées du système qui ne sont pas d’ordre
fonctionnelles. Elles viennent décrire la manière d’opérer des fonctionnalités d’un point de vue fréquence,
concurrence, confidentialités, sécurités,….etc.

Exigence Signification
Temps de réponse Indiquer le temps de réponse maximum toléré ou attendu pour un C.U.
Concurrence Indiquer si un avertissement doit être émis suite à la réalisation ou pas du
C.U.
Fréquence Prévenir la fréquence de réalisation du C.U
Volumétrie Volume estimé de l’information manipulée par le C.U.
Disponibilité Jours et heures de disponibilité du C.U.
Intégrité Recenser les cas ou le C.U ne peut pas se réaliser pour un fonctionnement
correct et intègre du système
Confidentialité Degrés de confidentialité du C.U et de l’information manipulée.

Tableau 3.1 Exigences non fonctionnelles

© Gueraich Sonia Page 13 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

4.7 Identification des classes candidates

La phase de recueil des besoins fonctionnels doit préparer la modélisation objet en aidant à identifier les
principales classes du futur modèle statique du système.
Les premières classes candidates identifiées dans cette phase doivent être des concepts connus des
utilisateurs du système appelée : objet métier et par abstraction classes métier (commande, client,
produit,….). Ces classes seront juste recensées dans une première étape.
Dans une prochaine étape seront rajoutées des concepts applicatifs liés à l’informatisation tels que : code-
barres, profil,…
Pour chaque C.U., il y aura un Diagramme de classes participantes représentant les classes candidates avec
les associations identifiées. Ces diagrammes préliminaires, n’ont pas comme objectif l’exhaustivité, ils
servent juste à démarrer la découverte des classes pour la partie d’application délimitée par le C.U.
La réunion de tous les diagrammes, après élimination des classes et associations redondantes représentera le
squelette du modèle statique d’analyse.

4.8 Validation et consolidation

La révision des cas d’utilisation doit aboutir à une présentation des résultats obtenus aux futurs clients en
posant les questions :
Les frontières du système sont-elles bien définies ?
Les acteurs sont-ils tous pris en compte ?
Toutes les fonctionnalités sont-elles traitées ?
Le niveau d’abstraction des C.U est-il homogène ?

5 Capture des besoins techniques

La capture des besoins technique couvre toutes les contraintes qui ne traitent ni de la description du métier de
l’utilisateur, ni de la description applicative. Elle concerne donc la capture des contraintes techniques. Ceci
est primordial pour la conception de l’architecture.
Cette étape ne peut débuter que lorsque les architectes ont eu suffisamment d’information sur les pré-requis
techniques (les machines, les réseaux, les progiciels à intégrer, et les outils retenus pour le développement).
Les différents éléments mis en jeu dans cette étape sont :
Diagramme de déploiement : nœuds et connexions du réseau, architecture à 3 niveaux
Diagrammes de composants, composants d’exploitation, architecture 3-tiers
Diagrammes de cas d’utilisation techniques,
Objectifs

La capture des besoins techniques est une étape de prise en compte des contraintes techniques et logicielles.
Elle doit être suffisamment détaillée pour permettre d’aborder la conception générique du système. Ses
objectifs sont :

1. Capture des spécifications techniques liées à la configuration matérielle :

Identifie les contraintes techniques liées aux machines, aux connexions et aux déploiements existants
Produire le diagramme de configuration matérielle
Identifier les contraintes d’organisation spécifiées par les choix d’architecture. Par exemple, pour le
style d’architecture en niveaux, nous trouvons :

© Gueraich Sonia Page 14 sur 15

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

- L’architecture à deux niveaux met en œuvre un environnement de travail de niveau départemental et

local. Elle répond généralement à la demande d’un métier particulier dans l’entreprise (un service ou
filiale qui dispose d’un système informatique indépendant et localisé au sein de la société).

- L’architecture à trois niveaux met en œuvre le système informatique de toute l’entreprise avec les
trois niveaux : central, départemental, local. Une telle architecture couvre les différents métiers de
l’entreprise

- L’architecture multi niveaux est conditionnée par la contrainte géographique

2. Capture initiale des spécifications logicielles

Identifier les besoins logiciels du point de vue des exploitants

Elaborer les cas d’utilisation techniques.

6 Conclusion

Dans ce chapitre, nous avons présenté les étapes conduisant vers la modélisation des cas d’utilisation, ainsi
que des aspects sur les besoins techniques du développement. Le chapitre suivant, portera sur la modélisation
statique par les diagrammes de classes.

© Gueraich Sonia Page 15 sur 15