Vous êtes sur la page 1sur 42

Conception des Systèmes

d’Informations

Niveau: 2ème année Licence

Mme Maha BELLAAJ


2

28/01/2020

Plan
• Introduction
• Chapitre1: Les diagrammes de cas d’utilisation
• Chapitre2: Les diagrammes de classe
• Chapitre3: Les diagrammes de séquence
• Chapitre4: Traduction des diagrammes UML en
code JAVA
3

28/01/2020

Introduction : Système d’Information


• Définition:
▫ Un système d’information (SI) est un
élément central d’une entreprise ou d’une
organisation (groupement humain structuré et
orienté vers la réalisation des objectifs) .
▫ Un SI est un ensemble de ressources, à la
fois humaines, matérielles, logiciels,
données,.. dont le rôle est de collecter, stocker,
traiter et distribuer de l’information grâce à un
ordinateur.
4

28/01/2020

Introduction : Système d’Information


• Exemple: le service de cartographie de Google: Google Maps.
▫ Un site de cartographie en ligne qui vous permet de rechercher
un lieu, n’importe où dans le monde, depuis la barre de recherche
sur le site.
▫ En plus d’être un service de Google, Google Maps est un système
d’information (SI). Pourquoi?
 Collecter et stocker les données cartographiques prises par les
satellites ;
 Les traiter en les combinant à vos recherches sur le site ;
 Les distribuer, c’est-à-dire vous les afficher sur le site lors de
vos recherches ;
 Un ensemble de ressources humaines (équipe de développeurs,
de cartographes, de géomètres, …), matérielles (ordinateurs,
serveurs, caméras, satellites sont utilisés pour acquérir et
stocker les données cartographiques) et immatérielles (brevets
mettre en œuvre ce service).
5

28/01/2020

Introduction : Système d’Information


• Rôle d’un SI:
▫ Le SI est le véhicule des différents services d’une entreprise.
▫ Il coordonne les activités de l’organisation.
▫ Il permet à l’entreprise d'atteindre ses objectifs.
• Objectif:
▫ L’objectif d’un SI est de restituer une information à la bonne
personne et au bon moment sous le format approprié.
• Fonctions:
▫ Collecter: acquérir les informations provenant de l’environnement
interne ou externe à l’entreprise.
▫ Stocker: conserver l’information
▫ Traiter, Transformer: : construire de nouvelles informations en
modifiant le fond ou la forme.
▫ Diffuser: transmettre l’information dans son environnement interne ou
externe.
6

28/01/2020

Introduction : Système d’Information


• logiciels composant le Système d‘Information:
▫ Un SI est composé de différents logiciels en fonction des domaines
d’activités de l’entreprise (commercial, ressources humaines,
juridiques…).

Logiciels Rôle / Fonctionalité


CRM(Customer Relationship gérer la relation client: envoi
Management) automatique, par exemple de e-mail
de bienvenue aux nouveaux clients
ERP (Entreprise Ressources gestion des ressources humaines, de
Planning) la paie, des ventes et de la
maintenance, la gestion de la
production,…
7

Introduction : Conception de Système


28/01/2020

d’Information
• 1ère étape: Bien se comprendre
• Difficultés:
▫ Multiplicité des acteurs, des rôles
 Client, utilisateur (ce n’est pas forcément le même)
 Informaticiens
 Chef de projet
 Architecte
 Développeur
 Testeur,…
▫ Maintenance, documentation, ...
▫ Langages, vocabulaires différents
8

Introduction : Conception de Système


28/01/2020

d’Information
• Cycle de vie du logiciel:
• Étapes:
▫ Définition des besoins  Dans le langage du client.
▫ Spécifications
 Traduction des besoins dans un langage plus informatique
 Ce que doit faire le logiciel (et non comment il le fait)
fonctionnalités du logiciel.
▫ Conception
 Traduction des spécifications en termes de concepts logiciels
▫ Codage
 Traduction de la conception en code
▫ Tests
▫ Maintenance
9

28/01/2020

Introduction : UML, C’est quoi?


• Un projet informatique nécessite une phase d’analyse
des besoins, suivi d’une étape de conception
(Modélisation des besoins).
• Dans l’analyse des besoins:
▫ Comprendre et décrire de façon précise les besoins des utilisateurs
ou des clients.
▫ Que souhaitent-ils faire avec le logiciel ? Quelles fonctionnalités
veulent-ils ? Pour quel usage ? Comment l’action devrait-elle
fonctionner ?
• Dans la phase de conception:
▫ Apporter plus de détails à la solution et chercher à clarifier des
aspects techniques.
•  Pour réaliser ces deux phases, nous allons utiliser
UML.
10

28/01/2020

Introduction : UML, C’est quoi?


• Définition:
• UML, c’est l’acronyme anglais pour « Unified Modeling
Language ». On le traduit par « Langage de modélisation
unifié ».
• UML est un langage visuel constitué d’un ensemble de
schémas, appelés des diagrammes.
•  il fournit 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.
•  Réaliser ces diagrammes revient donc à modéliser les
besoins du logiciel à développer.
•  UML est surtout utilisé lorsqu’on prévoit de
développer des applications avec une démarche objet
(développement en Java, en C++, etc.).
11

28/01/2020

Introduction : UML, C’est quoi?


• Pourquoi modéliser:
▫ Exemples: un meuble en kit, branchement d’un nouvel
équipement électrique,…. Plus facile à partir de schéma plutôt
qu’une page de texte.
▫ L’utilisation de schémas et d’illustrations rend quelque chose de
complexe plus compréhensible.
▫  C’est exactement à quoi sert UML dans des projets de
réalisation de logiciels.
12

28/01/2020

Introduction : Approche Objet


• Deux approches permettant de définir les besoins :
▫ La décomposition fonctionnelle (ou l’approche procédurale)
▫ L’approche objet (sur laquelle est basée UML)
• La décomposition fonctionnelle:
▫ L’approche par décomposition fonctionnelle considère que le
logiciel est composé d'une hiérarchie de fonctions et de
données.
▫ Les fonctions fournissent les services désirés et les données
représentent les informations manipulées.
▫ Exemple: fonctions Enregistrer et Enregistrer sous de Word.
▫ Problème: Les fonctions sont alors interdépendantes :
une simple mise à jour du logiciel à un point donné, peut
impacter en cascade d'autres fonctions.
▫ l’approche objet est née, dont UML s’inspire largement.
13

28/01/2020

Introduction : Approche Objet


• Approche Objet:
• L’approche objet est une démarche qui s’organise autour de 4
principes fondamentaux. C’est une démarche :
▫ Itérative et incrémentale: faire des allers-retours entre le plan
initial et les modifications apportées par les acteurs du projet.
▫ Guidée par les besoins du client et des utilisateurs: les
exigences exprimées par le client au niveau des fonctionnalités, du
rendu et des actions d’un logiciel.
▫ Centrée sur l’architecture du logiciel: l’architecture client
serveur, en couche ou en niveaux.
▫ Qui décrit les actions et les informations dans une seule:
entité (Diagramme de classe).
14

Introduction : les différents types


28/01/2020
de
diagrammes
• le langage UML est constitué de diagrammes. Il existe 13
diagrammes « officiels »:
▫ Diagramme cas d’utilisation (Aspect fonctionnel)
▫ Diagramme d’activité
▫ Diagramme de classe (Aspect statique)
▫ Diagramme d’objets
▫ Diagramme d’états
▫ Diagramme de séquence (Aspect dynamique)
▫ Diagramme de communications
▫ Diagramme de composants
▫ Diagramme de paquetages
▫ Diagramme de déploiement
▫ …..
15

Chapitre1: Les diagrammes de


28/01/2020
cas
d’utilisation
• Introduction:

• Le diagramme de cas d’utilisation (Uses Case Diagram):


▫ Moyen simple d’exprimer les besoins des utilisateurs.
▫ Il permet de recenser les fonctionnalités d’un système.
▫ Un diagramme de cas d'utilisation capture le comportement
d'un système, d'un sous-système, d'une classe ou d'un
composant tel qu'un utilisateur extérieur le voit.
▫  Il s'agit donc de la première étape UML d'analyse d'un
système.
▫  étape importante pour produire un logiciel conforme aux
attentes des utilisateurs. Pour élaborer les cas d'utilisation, il
faut se fonder sur des entretiens avec les utilisateurs.
16

Chapitre1: Les diagrammes de


28/01/2020
cas
d’utilisation
• Éléments des diagrammes de cas d'utilisation:
▫ Acteurs:
• Un acteur est l'idéalisation d'un rôle joué par une personne externe,
un processus ou une chose (entité extérieure) qui interagit avec
un système.
• Il se représente par un petit bonhomme avec son nom (i.e. son rôle)
inscrit dessous.

• Il est également possible de représenter un acteur sous la forme d'un


classeur stéréotypé << actor >>.
17

Chapitre1: Les diagrammes de


28/01/2020
cas
d’utilisation
▫ Cas d’utilisation:
• Un cas d'utilisation est une unité représentant une fonctionnalité
visible de l'extérieur.

• Il modélise un service rendu par le système, sans imposer le mode de


réalisation de ce service.

• Il réalise un service avec un déclenchement, un déroulement et une


fin, pour l'acteur qui l'initie.

• Un cas d'utilisation se représente par une ellipse contenant le nom du


cas (un verbe à l'infinitif).
18

Chapitre1: Les diagrammes de


28/01/2020
cas
d’utilisation
• Exemple d'un diagramme de cas d'utilisation:

• La frontière du système est représentée par un


cadre. Le nom du système figure à l'intérieur du
cadre, en haut. Les acteurs sont à l'extérieur et les
cas d'utilisation à l'intérieur.
19

Relations dans les diagrammes de cas 28/01/2020

d'utilisation
• Relations entre acteurs et cas d’utilisation:
▫ Relation d’association:

• Une relation d'association est un chemin de communication entre un


acteur et un cas d'utilisation et est représenté un trait continu.
20

Relations dans les diagrammes de cas 28/01/2020

d'utilisation
▫ Acteurs principaux et secondaires:
• Un acteur est qualifié de principal pour un cas d'utilisation lorsque
ce cas rend service à cet acteur.
• Les autres acteurs sont qualifiés de secondaires.
• Un acteur principal obtient un résultat observable du système tandis
qu'un acteur secondaire est sollicité pour des informations
complémentaires.
• L'acteur principal initie le cas d'utilisation
• Le plus souvent, les acteurs secondaires sont d'autres systèmes
informatiques avec lesquels le système développé est inter- connecté.

▫ Cas d’utilisation internes:


• Un cas d’utilisation interne n’est pas relié directement à un acteur.
21

Relations dans les diagrammes de cas 28/01/2020

d'utilisation
• Relations entre cas d'utilisation:
• Il existe principalement deux types de relations :
▫ Les dépendances stéréotypées, qui sont explicitées par un
stéréotype : l'inclusion et l'extension. représentées par une flèche
avec un trait pointillé.
▫ La généralisation/spécialisation. représentée par un flèche avec
un trait plein dont la pointe est un triangle fermé désignant le cas le
plus général

▫ Relation d'inclusion:

• Un cas A inclut un cas B si le comportement décrit par le cas A inclut


le comportement du cas B : B est une partie obligatoire de A.
• Cette dépendance est symbolisée par le stéréotype << include >>.
22

Relations dans les diagrammes de cas 28/01/2020

d'utilisation

• Les inclusions permettent:


▫ Factoriser une partie de la description d'un cas d'utilisation qui
serait commune à d'autres cas d'utilisation.
Exemple: l'accès aux informations d'un compte bancaire inclut
nécessairement une phase d'authentification avec un identifiant et
un mot de passe.
▫ Décomposer un cas complexe en sous-cas plus simples.
23

Relations dans les diagrammes de cas 28/01/2020

d'utilisation
▫ Relation d’extension:

• On dit qu'un cas d'utilisation B étend un cas d'utilisation A


lorsque le cas d'utilisation B peut être appelé au cours de
l'exécution du cas d'utilisation A.

• Exécuter A peut éventuellement entraîner l'exécution de B :


contrairement à l'inclusion, l'extension est optionnelle. Cette
dépendance est symbolisée par le stéréotype << extend >>
24

Relations dans les diagrammes de cas 28/01/2020

d'utilisation
▫ 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.  le flèche se ponte vers le cas général.

• Une généralisation se traduit par le concept d'héritage dans les


langages orientés objet.
25

Relations dans les diagrammes de cas 28/01/2020

d'utilisation
• 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. Dans ce cas, tous les cas d'utilisation
accessibles à A le sont aussi à B, mais l'inverse n'est pas vrai.
• Le symbole utilisé pour la généralisation entre acteurs est une flèche
avec un trait plein dont la pointe est un triangle fermé désignant l'acteur
le plus général
• Exemple: 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. Par contre,
le préposé aux commandes ne
peut pas gérer le stock.
26

Exemple1:ÉTUDE D’UN PUBLIPHONE À PIÈCES


28/01/2020

• Cette étude de cas concerne un système simplifié de


Publiphone à pièces.
▫ Le prix minimal d’une communication interurbaine est de 0,1
dinar.
▫ Après l’introduction de la monnaie, l’utilisateur a 2 minutes
pour composer son numéro(ce délai est décompté par le
standard).
▫ La ligne peut être libre ou occupée.
▫ Le correspondant peut raccrocher le premier.
▫ Le Publiphone consomme de l’argent dès que l’appelé décroche
et à chaque unité de temps générée par le standard.
▫ On peut ajouter des pièces à tout moment.
• Question: À partir de ces six phrases:
▫ 1. Identifier les acteurs et les cas d’utilisation.
▫ 2. élaborer le diagramme de cas d’utilisation.
27

28/01/2020

Exemple2:Système Pizzeria en ligne


• Étude de cas

Le patron d’une pizzeria minute (vente à emporter uniquement) a l’idée


de faire évoluer son activité en tirant profit d’Internet.
Il souhaite que ses clients puissent commander des pizzas en ligne au
lieu de se présenter dans la boutique ou de téléphoner. Ils pourront
choisir la pizza dans une liste préétablie dans le format qu’ils souhaitent
(petit, moyen, familial).

• Avant de passer une commande, le client doit s’inscrire en donnant son


nom, prénom, adresse, numéro de téléphone et adresse email. De plus,
les clients doivent pouvoir donner une note et un avis sur le service
(soin de l’exécution, rapidité de service, respect de la commande, etc.).
Ils doivent également avoir la possibilité de faire des suggestions (autres
ingrédients, nouveaux produits, etc.).

• Le patron et ses employés devront donc consulter la liste des


commandes arrivées pour pouvoir commencer la préparation. Dès
qu’une pizza sort du four, le préparateur (un des employés) devra alors
signaler sur le site que la pizza est prête.
28

Exemple3:Système de Gestion de stock 28/01/2020

d’articles
• Étude de cas

Dans un magasin, un commerçant dispose d’un système de


gestion de son stock d’articles, dont les fonctionnalités sont
les suivantes :
• - Edition de la fiche d’un fournisseur.
• - Possibilité d’ajouter un nouvel article (dans ce cas, la fiche
fournisseur est automatiquement éditée. Si le fournisseur
n’existe pas, on peut alors le créer).
• - Edition de l’inventaire. Depuis cet écran, on a le choix
d’imprimer l’inventaire, d’effacer un article ou d’éditer la
fiche d’un article).
• Question: Modéliser cette situation par un diagramme de
cas d’utilisation
29

Description textuelle des cas d'utilisation


28/01/2020

• Le diagramme de cas d'utilisation décrit les grandes


fonctions d'un système du point de vue des acteurs, mais
n'expose pas de façon détaillée le dialogue entre les acteurs
et les cas d'utilisation.
• 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.
• Un simple nom est tout à fait insuffisant pour décrire un cas
d'utilisation.
• Chaque cas d'utilisation doit être documenté pour qu'il
n'y ait aucune ambiguïté concernant son déroulement et ce
qu'il recouvre précisément.
30

Description textuelle des cas d'utilisation


28/01/2020

• Définition: Fiche descriptive pour chaque cas


d’utilisation
• Il s’agit des interactions entre les acteurs et le système en
décrivant la chronologie des actions qui devront être réalisées par eux
(acteurs et système).  On parle de scénarios.
• La description d’un cas d’utilisation permet de:
▫ Clarifier le déroulement de la fonctionnalité
▫ Décrire la chronologie des actions qui devront être réalisées ;
▫ Identifier les parties redondantes pour en déduire des cas
d’utilisation plus précises qui seront utilisées par inclusion, extension
ou généralisation/spécialisation.
•  Les descriptions peuvent aider à découvrir d’autres cas d’utilisation
que l’on pourrait ajouter. Il s’agit, dans ce cas, d’une nouvelle itération
sur les diagrammes de cas d’utilisation.
31

Description textuelle des cas d'utilisation


28/01/2020

• Une description textuelle se compose de trois parties.


• La première partie permet d'identifier le cas, elle doit contenir les
informations qui suivent.  Identification
• Nom :
▫ Utiliser une tournure à l'infinitif (ex. : Réceptionner un colis).
• Résumé (Objectifs):
▫ Une description résumée permettant de comprendre l'intention
principale du cas d'utilisation. Cette partie est souvent renseignée au
début du projet dans la phase de découverte des cas d'utilisation.
• Acteurs principaux :
▫ Ceux qui vont réaliser le cas d'utilisation (la relation avec le cas
d'utilisation est illustrée par le trait liant le cas d'utilisation et l'acteur
dans un diagramme de cas d'utilisation).
• Acteurs secondaires :
▫ Ceux qui ne font que recevoir des informations à l'issue de la
réalisation du cas d'utilisation.
• Date de création / Auteur
32

Description textuelle des cas d'utilisation


28/01/2020

• 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.  Séquencements (Dialogue)
• Elle contient toujours une séquence nominale qui décrit de
déroulement normal du cas.
• À la séquence nominale s'ajoutent fréquemment des séquences
alternatives (des embranchements dans la séquence nominale) et des
séquences d'exceptions (qui interviennent quand une erreur se
produit).
33

Description textuelle des cas d'utilisation


28/01/2020

• Les préconditions :
▫ Elles décrivent dans quel état doit être le système (l'application)
avant que ce cas d'utilisation puisse être déclenché.

• Des scénarii :
▫ Ces scénarii sont décrits sous la forme d'échanges d'événements entre
l'acteur et le système.
▫ On distingue:

 Le scénario nominal, qui se déroule quand il n'y a pas d'erreur


(le déroulement idéal des actions),
 Des scénarii alternatifs qui sont les variantes du scénario
nominal (C’est le cas des étapes liées à des conditions),
 Des scénarii d'exception qui décrivent les cas d'erreurs.
34

Description textuelle des cas d'utilisation


28/01/2020

  Les scénarios mettent en évidence les interactions entre les


actions de l’utilisateur et le système (le logiciel).
  Cela peut se faire par une liste numérotée d’actions (1,2,3, 1a,
1b, 2a, 2b…..) ou sous forme de tableau qui démontre clairement ce
qui est réalisé par l’utilisateur et ce qui est du ressort du système.

• Des postconditions :
▫ Elles décrivent l'état du système à l'issue des différents scénarii.
35

Description textuelle des cas d'utilisation


28/01/2020

• La troisième partie de la description d'un cas


d'utilisation est une rubrique optionnelle.
• Elle contient généralement des spécifications non
fonctionnelles (spécifications techniques,…).
• Elle peut éventuellement contenir une description
des besoins en termes d'interface graphique.
36

Description textuelle des cas d'utilisation


28/01/2020

• Le schéma suivant illustre la relation entre le diagramme des cas


d’utilisation et la description textuelle d’un cas d’utilisation.
37

Description textuelle des cas d'utilisation


28/01/2020

• Exemple:

• Proposer un description textuelle pour le cas d’utilisation:


« PayerCB » .
38

Description textuelle des cas d'utilisation


28/01/2020

• Identification:
▫ Nom du cas : Payer CB
▫ Résumé : Détailler les étapes permettant à un client de payer par
carte bancaire.
▫ Acteurs primaires : Client
▫ Acteurs secondaires: Banque
▫ Date de création: 27/01/2020
• Séquencements:
▫ Le cas d'utilisation commence lorsqu'un client demande le paiement
par carte bancaire.
▫ Pré-conditions
▫ Le client a validé sa commande.
▫ Enchaînement nominal
▫ 1. Le client saisit les informations de sa carte bancaire (type carte
bancaire, num carte, date d’expiration, ..)
▫ 2. Le système vérifie que le numéro de CB est correct
▫ 3. Le système vérifie la carte auprès du système bancaire
39

28/01/2020

▫ 4. Le système demande au système bancaire de débiter le client


▫ 5. Le système notifie le client du bon déroulement de la transaction
▫ Enchaînements alternatifs
▫ 2.a : si le numéro est incorrect, le client est averti de l'erreur, et invité
à recommencer
▫ 3.a: si les informations sont erronées, elles sont redemandées au
client.
▫ Post-conditions
▫ La commande est validée
▫ Le compte de l'entreprise est crédité
• Partie optionnelle:
▫ Contraintes non fonctionnelles :
▫ Fiabilité : les accès doivent être sécurisés
▫ Confidentialité : les informations concernant le client ne doivent pas
être divulgués
▫ Contraintes liées à l'interface homme-machine :
▫ Toujours demander la validation des opérations bancaires
40

Description textuelle des cas d'utilisation


28/01/2020

• Étude D’un Guichet Automatique De Banque (GAB):


• Proposer une description textuelle du cas d’utilisation:
« Retirer de l’argent ».
41

Résumé
28/01/2020

• Justification d’UML:

• 1. Sa nature graphique permet d’exprimer visuellement une


solution objet, ce qui facilite la compréhension et l’évaluation des
solutions.
• 2. l’aspect formel de sa notation limite les ambiguïtés et les
incompréhensions.
• 3. UML est un support de communication parfait.
• 4. Son caractère polyvalent et sa souplesse font un langage
universel.
42

Résumé
28/01/2020

• Le comportement du système est caractérisé par des cas


d'utilisation.
• Un cas d'utilisation est une fonctionnalité du système.
• Un acteur est quelque chose ou quelqu'un qui agit sur le système.
• Un diagramme de cas d'utilisation est une vue graphique du
système.
• Chaque cas d'utilisation est documenté par plusieurs scénarios.
• Étapes de construction:
• les acteurs
• Pour chaque acteur, chercher les cas d’utilisation
• Structuration des cas d’utilisation pour faire apparaître les
comportements partagés (relation d’inclusion), les cas
particuliers ou options (relation d’extension), et les
généralisations et spécialisations.