CONCEPTION DE SYSTME

D’INFORMATION L2
INFO/CONCEPTION
AM I
N Y
ph i n
.R u
CT. MSC Ruphin NYAMI

M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 HISTORIQUE
1945 à 1969 : Crise de du logiciel
1970 (OTAN) : Génie Logiciel + 1ère méthodes
1980 : Approche Systémique (MERISE, AXIAL,

I
NIAM,…..)
1990 : Développement Orienté Objet (OOSE,

Y AM
N
OMT, BUCH 98 : UP + UML)

ph i n
2001 : Agilité (Approche Agile)

u
2004 : Gestion de Processus Métier (BPM)

s c .R
T. M
C
1970 à 1979 : Méthodes fonctionnelles : Structured Analysis -
Structured Design (SA - SD)
• SA - Analyse Structurée (Structured Analysis)
- Notations des outils de SA : DFD, dictionnaires, ...
- Mise en oeuvre des outils graphiques

AM I
Y
• SD - Conception Structurée (Structured Design)

i n
- Découpage des programmes en modules
N
u ph
- Différents types de couplage entre modules

.R
- Différents types de cohésions d'un module

M s c
C T.
1970 à 1979 : Méthodes fonctionnelles : Structured Analysis -
Structured Design (SA - SD)
• SD - Conception Structurée (Structured Design)
 ont leur origine dans le développement des langages procéduraux
plus orientées vers les traitements que vers les données

I
mettent en évidence la ou les fonctions à assurer

AM
proposent une approche hiérarchique, descendante et modulaire en

Y
précisant les liens entre les différents modules

N
 utilisent souvent des modèles/outils de type DFD

i n
avec l'évolution des langages de programmation et des systèmes,

ph
prennent en compte la modélisation des données et les problèmes

u
posés par le temps réel (SA-RT)

.R
 méthodes fonctionnelle les plus connues :

s c
SA-SD (Strutured Analysis -Structured Design - Yourdon, DeMarco,
W.P.Stevens, G.J.Myers, Constantine, Gane & Sarson,...)

. M
SADT (Structured Analysis and Design Technique - Softech)

C T
 SA-RT (Strutured Analysis / Real Temps- Hatley & Pirbhai 1991)
spécialisé temps réel
 1980 : Approche Systémique
• Découpage de l'organisation en domaine
• Analyse indépendante Données / Traitements
• méthodes s'appuyant sur une approche systémique

AM I
Y
• définissent différents niveaux de préoccupation ou d'abstraction

n N
• proposent de nombreux modèles complémentaires sont souvent

i
ph
spécialisées pour la conception d'un certain type de systèmes

.R u
M s c
C T.
 1980 : Approche Systémique
• Méthodes systémiques les plus connues :
oMERISE (méthode la plus utilisée en informatique
de gestion en France et grande partie de l'Europe)

I
oAXIAL (IBM - systèmes d'information),
oMEGA (Mega - systèmes d'information),...

Y AM
n N
oOSSAD (systèmes bureautiques)

ph i
oSAGACE (CEA - systèmes complexes (centrales

.R u
atomiques))

c
oGRAI (Productique)

. M s
oNIAM

C T
1990-1997 : Analyse Orientée Objet

AM I
N Y
ph i n
.R u
s c
 La méthode OMT de Rumbaugh

. M
 La méthode BOOCH'93 de Booch

T
La méthode OOSE de Jacobson (Object Oriented Software

C


Engineering)
1990 : Analyse Orientée Objet

AM I
N Y
ph i n
.R u
M s c
C T.
2001 : Manifeste Agile

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Exemple
Introduction CONCEPTION Outils avec Conclusion
Anaconda

Origine de la conception

AM I
N Y
Aristote

ph i n
Voici quelques exemples des grandes questions ontologiques :

u
– Qu'est-ce que est l'existence?

.R
– Qu'est-ce qu'un objet ?

c
– Quelles sont les propriétés d'un objet et comment sont-elles liées à

M s
l'objet lui-même?

.
– Un objet disparaît-il ou change-t-il ?

C T 16
 Exemple
La
Introduction Outils avec Conclusion
Sémiotique
Anaconda
être et Être dans l’ontologie
Grand Être ( essence) : ce qu’on a à l’esprit quand on

I
pense à quelque chose selon le Grec
Exemple. Smartphone

Y AM
i n N
être (observable) : ou objet c’est l’apparence du Grand

ph
Être objet

.R u
M s c
C T. 17
 Exemple
La
Introduction Outils avec Conclusion
Sémiotique
Anaconda

AM I
N Y
ph i n
.R u
M s c
C T. 18
RN1
Exemple
La
Introduction Outils avec Conclusion
Sémiotique
Anaconda

Définition de l’ontologie :

I
C’est la spécification formelle d’une
conceptualisation

Y AM
i n N
u ph
s c .R
T. M
C 19
Diapositive 19

RN1 Ruphin2 Nyami; 22/08/2021

AM I
N Y
ph i n
.R u
M s c
C T.
 Méthode de Conception

• Une méthode de conception est constituée :

I
- d’un processus de développement,
- de notations permettant la modélisation
Y AM
N
- et d’outils d’aide à la conception,

ph i n
- à la vérification et/ou au suivi du processus.

.R u
M s c
C T.
Eléments d’UML

• UML se décompose en plusieurs parties :

I
• Les vues : ce sont les observables du système. Elles

AM
décrivent le système d'un point de vue donné, qui

Y
N
peut être organisationnel, dynamique, temporel,

i n
architectural, géographique, logique, etc. En

ph
combinant toutes ces vues, il est possible de définir

.R u
(ou retrouver) le système complet.

M s c
C T.
 Eléments d’UML

• Les diagrammes : ce sont des ensembles d'éléments

I
graphiques. Ils décrivent le contenu des vues, qui

AM
sont des notions abstraites. Ils peuvent faire partie de

Y
plusieurs vues.

i n N
• Les modèles d'élément : ce sont les éléments

ph
graphiques des diagrammes.

.R u
M s c
C T.
 4 VUES + 1

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Démarche de Conception

AM I
N Y
ph i n
.R u
M s c
C T.
 I: LA MODELISATION METIER
L’analyste s’intéresse aux grands processus
métier de l’entreprise:

AM I
N Y
ph i n
.R u
M s c
C T.
 II. La capture Initiale de besoins
L’analyste s’intéresse aux services et
processus à automatiser :

AM I
N Y
ph i n
.R u
M s c
C T.
 III: L’ANALYSE
L’Analyse s’intéresse à la solution et sa
mise en œuvre :

AM I
N Y
ph i n
.R u
M s c
C T.
 III: L’ANALYSE
L’Analyse s’intéresse à la solution et sa
mise en œuvre :

AM I
N Y
ph i n
.R u
M s c
C T.
 IV: La Conception
L’analyste adapte la solution dans la
technologie choisie :

AM I
N Y
ph i n
.R u
M s c
C T.
 Notions des acteurs avec UML
• Acteur:
- entité externe qui interagit avec le système

I
- Tout ce qui peut interagir avec le système. (Personne physique

M
ou non, Chose, Logiciel, extérieur du système décrit)

A
- Représente un rôle joué (plusieurs rôles possibles pour une

Y
même entité)

i n N
- Identifié par le nom du rôle joué par cette entité.

ph
- Acteur principal : celui qui déclenche un cas d’utilisation

.R u
- Acteur secondaire : celui qui subit ou reçoit l’information
pendant, à la fin de l’exécution d’un cas d’utilisation (flèche

s c
orienté vers l’acteur)

M
Bonne manière : mettre les acteurs secondaires à droite du

T.
système; sinon cette règle n’est pas obligatoire

C
 Exemple
Gestion de stock

Acteur secondaire

I
S'authentifier

M
Effectuer

A
transfert «include»

Y
d'argent

N
Emetteur

ph i n
Beneficiare

.R u
c
Acteur principal

. M s
C T
 Diagramme de contexte ( A qui le système sera important ? )
• Diagramme non UML
• Hérité de la méthode SADT (actigramme)
• Contient le nom du système (vente, prise en charge médicale). Erreur a éviter : mettre le nom de l’entreprise
• Objectif:

I
- Modéliser le contexte du système avec les acteurs

M
- Définir l’environnement du système : Qui va l’utiliser ou interagir avec lui ? (des humains? Pas forcément. Peut

A
être que d’autres systèmes informatiques comme de capteur,…)

N Y
- Définir les limites du système : où s’arrête sa responsabilité ? (Qu’est ce qui sort de son cadre ?, vat-il délégué
certaines opérations dans un autre système ?

ph i n
- Délimiter les périmètres du système
- Montrer les acteurs qui interagis avec le système

.R u
• Phases

c
- Analyse du domaine (Diagramme de contexte statique) montrant les acteurs et système reliés par des assotions

s
(avec ou sans multiplicités)

M
- Analyse applicative (diagramme de contexte dynamique) : contenant les acteurs et le système dont les associations

T.
sont pondérées par de messages émis et reçus)

C
- Formalisme : rectangle ou ellipse
 Diagramme de contexte statique
Légende :
* : plusieurs instances d’acteurs en
un instant donné

I
1 : un et un seul acteur en un

M
instant donné

N Y A
i n
«actor»

ph
Mo bil Bank
*
: : acteur non humain

u
Client

.R
1
Systeme de vente
en ligne (SVE)

c
«actor»

s
Mobil Bank

M
1 : acteur humain

C T.
Service Client
C lie nt
 Diagramme de contexte dynamique

AM I
N Y
ph i n
.R u
M s c
C T.
 Diagramme de contexte statique
Acteur du métier : un acteur existant à priori au système
informatique (caboche coupée)
«business actor»

I
C lient

AM
Acteur système : un rôle existant grâce au système

Y
informatique

i n N
Administrateur

ph
Travailleur d’interface : un acteur du métier touchant le

u
système en lieu et place d’un autre acteur (ex. Garde,

.R
Guichetier de la banque)

c
Acteur d'interface

. M s Travailleur interne : un acteur du métier participant à un

C T
Travailleur
interne
processus sans contact avec le monde extérieur
 Diagramme de cas d’utilisation UML
Pour réfléchir aux besoins du client;
La réflexion autour des Cu, c’est le point de départ de tout
processus de développement, que ca soit un processus

I
classique en V ou le processus Agile.

AM
La question principale qu’on cherche à répondre est:

N Y
A quoi et à qui va servir le système qu’on cherche à

i n
développer ?

u ph
Comment ce système vat-il être utilisé et pourquoi faire ?

.R
Bref c’est la phase d’analyse de besoins du client

M s c
C T.
 Cas d’utilisation : Objectif UML 2/3
• Comprendre les besoins du client pour rédiger un cahier
de charge fonctionnel c’est-à-dire la liste de
fonctionnalités du système.

AM I
• Il faut analyser son interface et la manière dont les

N Y
utilisateurs vont interagir avec lu.

ph i n
.R u
M s c
C T.
 Trois questions à répondre sur les cas d’utilisation UML

1) Définir les utilisations principales du système : à

quoi sert-il (quelles sont ces taches principales )?
C’est ça qu’on va appelé CU.
2) Définir l’environnement du système : Qui va
l’utiliser ou interagir avec lui ? (des humains? Pas
AM I
forcément. Peut être que d’autres systèmes
N Y
i n
informatiques comme de capteur,…)

u ph
3) Définir les limites du système : où s’arrête sa

.R
responsabilité ? (Qu’est ce qui sort de son cadre ?,

s c
vat-il délégué certaines opérations dans un autre

M
.
système ?

C T
 Outils sur le cas d’utilisation
• Diagramme de CU;
• Description textuelle des CU;

I
• Diagramme de séquences de scénario d’utilisation

Y AM
i n N
u ph
s c .R
T. M
C
 Diagramme de CU 3/4

AM I
N Y
ph i n
.R u
s c
L’association entre CU et acteur signifie que cet acteur a la

M
.
possibilité de déclencher le cas d’utilisation.

C T
 Modélisation du métier : Exemple 1
• Guichet automatique de la banque. Où n’importe qui peut retirer de
l‘argent et où certaines opérations sont réservées au client de la
banque, propriétaire de l’automate.

I
• Ce client est reconnu comme client de la banque, dès qu’il insère sa

AM
carte dans l’automate (GAB).

N Y
ph i n
.R u
M s c
C T.
 Exemple

AM I
N Y
ph i n
.R u
M s c
C T.
Exemple empiré en chevauchement

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Exemple de Généralisation
Systeme enseignement

Suivre co urs
Etudiant Un cas d’utilisation a un et un seul acteur
Principal qui peut le déclencher sans

I
confusions.
Payer frais

M
Que faire dans ce genre des situations ?

A
La réponse à ce conflit de responsabilité

Y
Est « la généralisation ».

N
Finaliste Passer

i n
exam en

u ph
Rediger

.R
memo ire

s c
Stagiaire
Effectuer

M
stage

C T.
 Exemple de Généralisation
Systeme enseignement Systeme enseignement

Rediger
Suivre co urs memoire
Etudiant
Finaliste

I
Payer frais
Payer frais

Y AM
N
Passer
Finaliste Passer Etudiant examen

i n
exam en

u ph
Suivre co urs
Rediger

.R
memo ire

s c
Stagiaire Effectuer
Effectuer Stagiaire stage

M
stage

C T.
 Rôle artificiel
Systeme Prise en charge medicale

Gérer Que faire dans ce genre de cas ?

consultation
- Impossible de généraliser les rôles ?
Medecin
- Solution

I
Gerer
hospitalisation
• Créer de rôles artificiels

AM
Car il y en a de structures sanitaires
Gérer

Y
dossier

N
Receptionniste médicale Facturer
soins
Sans médecin ? Où l’infirmier peut jouer

i n
Ce rôle

ph
Etablir plan de

u
Infirmier traitement Solliciter prise en

.R
Traitant charge medicale
Patient
Administrer

c
soins medicaux

s
Gerer

M
examen

.
Laborantin laboratoire

C T
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Extension

AM I
N Y
ph i n
.R u
M s c
C T.
 Relation entre cas d’utilisation
Systeme Prise en charge medicale

Recommander
examen
Recommander clinique
examen Dans ce diagramme :

I
- Cas optionnel de Gérer consultation
«extend»

M
• Recommander examen

A
Recommander - Cas particulier de Gérer consultation

Y
Gérer Etablir examen
• Etablir diagnostic

N
consultation diagnostic clinique
Medecin • Prescrire parient

i n
- Cas particulier de recommander examen

ph
• Recommander examen clinique

u
Prescrire • Recommander examen clinique

.R
patient

M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Exemple 2

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Contre-exemple
- Un cas d’utilisation doit contenir
plusieurs scénarios et non un seul

M I
- Chaque cas d’utilisation ne peut se

A
déclencher sans s’authentifier

Y
« include »

i n N
- Le cas d’utilisation en formuler en

ph
tenant compte de l’intention de

u
l’acteur et non du système :

.R
« Consulter état du stock"

M s c - On ne peut commander que

.
qu’après consultation des articles

C T
 Modélisation du Métier : Complément de
Notation sur les cas d’utilisation
Le diagramme de cas d’utilisation est la
description générale fonctionnelle du projet

I
en étude.

Y AM
Exemple 2 : le système de vente de livre en
ligne:
i n N
u ph
s c .R
T. M
C
Etude de cas : Vente de livres en ligne

AM I
N Y
ph i n
.R u
M s c
C T.
 Etude de cas : Vente de livres en ligne
Dans le diagramme de Cu ci-haut, il y a des choses un peu plus
compliqué :
Le deux acteurs se disputent deux cas d’utilisation « Parcourir
catalogue et modifier son panier ».

M I
L’ordre d’apparition des CU n’a pas d’importance et ni un Work flow de
de haut en bas ou de bas en haut;
A
N Y
La position des acteurs également influe peu sur la compréhension du

i n
diagramme, on peut le mettre à gauche ou à droite sans signification

ph
particulière.

.R u
Le trait là qui traverse les deux CU ennuient sérieusement le

c
diagramme. Pour ce faire il faut isoler le rôle commun à ces deux

M s
acteurs : L’internaute qui n’est pas connu et le Client qui est connu dans

.
le système.

C T
 Etude de cas : Vente de livres en ligne
On généraliser les deux acteurs par visiteur : le Visiteur devient ainsi un concept
plus large que l’Internaute et Client

AM I
N Y
ph i n
.R u
M s c
C T.
 Etude de cas : Généralisation sur les USES CASES
Exemple : lorsque le client passe la commande, il faut qu’il paie en ligne
(par CB, PayPal, MobilBanking) et là, les acteurs externes qui vont
intervenir ne sont pas le même : (CB : partenaire banque) et Mobile
Bank,…)

I
Or payer par banque est en lien direct avec le Cu payer qui semble être

A
abstrait. C’est en quelque sorte une spécialisation du CU payer.

Y M
N
La généralisation en CU est à utiliser avec Parcimonie et avec

ph i n
précaution car en UML il n’existe pas de sous processus. Et surtout pas

u
au niveau du métier mais au niveau du développement.

.R
L’extension risque également de noyer le CU si on prenait le cas où

s c
dans chaque page Web on à la possibilité d’aller partout donc plusieurs

M
.
extensions.

C T
 Etude de cas : Généralisation sur les USES CASES

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Scénario détaillé et Diagramme de séquence
Le diagramme de CU est :
• Utiles pour les discussions avec le client car intuitif et
concis

I
• Mais pas suffisant pour l’équipe de développement

AM
• Voila la nécessité d’une description textuelle détaillée des

Y
N
scénarios représenter par chacun des CU :

i n
• Description textuelle en langue naturelle et structurée

u ph
• Explication du vocabulaire utilisé dans le diagramme

s c .R
T. M
C
 Description textuelle

AM I
N Y
ph i n
.R u
M s c
C T.
 Description textuelle : Exemple

AM I
N Y
ph i n
.R u
M s c
C T.
 Description textuelle : Exemple

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Diagramme de séquences
• Il fait partie de diagramme dynamique d’UML
• Il est l’un de diagramme d’interaction ( à coter du

I
digramme de communication)

Y AM
i n N
u ph
s c .R
T. M
C
 Diagramme de séquences
• Le diagramme de séquence est une représentation graphique
de chronologie des échanges de messages entre les acteurs et
le système.

I
• Le temps « ligne de vie » est représenté verticalement et les

M
échanges de messages horizontalement.

Y
• Les diagrammes de séquences permettent de décrire

N A
COMMENT les éléments du système interagissent entre eux
et avec les acteurs :

ph i n
u
- Les objets au cœur d’un système interagissent en s’échangent

.R
des messages.

s c
Les acteurs interagissent avec le système au moyen d’IHM

M
(Interfaces Homme-Machine).

C T.
Diagramme de séquences : Type de pictogramme

I
Ligne de Vie

Y AM
i n N
ph
Suppression Activation

u
de l’Objet

s c .R
T. M
C
Diagramme de séquences : Type de pictogramme
Acteur participant à Objet anonyme (Système,
un processus Table, Code source,
Ecran,….) participant à un

I
processus

Y AM
N
Objet de

i n
persistance (Table,

ph
BD, fichier)

u
Objet d’interface

.R
Homme Machine

c
Objet de contrôle

s
(Code source,

M
équipement de

T.
contrôle,…)

C
Diagramme de séquences : Type de Messages
Bloque l'expéditeur jusqu'à prise en compte du message par le destinataire. Le
flot de contrôle passe de l'émetteur au récepteur (l'émetteur devient passif et
le récepteur actif) à la prise en compte du message.

M I
N'interrompt pas l'exécution de l'expéditeur. Le message envoyé peut être pris

A
en compte par le récepteur à tout moment ou ignoré (jamais traité).

N Y
n
Réponse à un événement

ph i
u
Un message réflexif : ne représente pas l'envoi d'un message, il représente une

.R


activité interne à l'objet ou une abstraction d'une autre interaction (qu'on peut

s c
détailler dans un autre diagramme de séquence).

T. M Suppression d’un objet dans la mémoire

C
Diagramme de séquences : Fragments

Alternatif : vérification d’une condition et le choix

d’une possibilité

AM I
N Y
Optionnel : Action à choisir au besoin, non

i n
obligatoire

u ph
s c .R Traitement répétitif, boucle

T. M
C
Diagramme de séquences : Fragments

Parallèle: Traitement en parallèle entre objets

AM I
N Y
Référence : faire référence ou déléguer certains

i n
fragments à un autre processus

u ph
s c .R
T. M
C
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Ca CU du Gestionnaire
u c Use C ase Mo de l

A jo u te r
pr o du it

I
su ppr im e r

M
pr o du it

Gerer

N Y A
i n
c atalo gu e

ph
de pr o du it G e stio nnair e

.R u
c
m o difie r

s
c ate go r ie A jo u te r

. M
c ate go r ie

C T
 Description textuelle de cas d’utilisation
: Gérer Catalogue produit : Créer catégorie
Préconditions : néant.
Scénario nominal :
1. Le Gestionnaire renseigne les informations

AM I
Y
de la catégorie (ID, nom, photo)
2.
i n N
Le système vérifie l’existence de la

ph
catégorie saisie. Si oui, chaque catégorie

.R u
préalablement enregistrée est présentée avec

s c
son nom et sa photo. Sinon le système

M
.
demande à l’utilisateur s’il veut ajouter cette

C Tcatégorie dan la base.

 Description textuelle de cas d’utilisation
: Gérer Catalogue produit : Créer catégorie

Préconditions : néant.

I
Scénario nominal :
3. Le Gestionnaire valide l’ajout de la
Y AM
N
catégorie.
Exceptions
ph i n
.R u
2-3a : [Doublon]

c
1. dans ce cas le système affiche un

M s
avertissement de doublon, demande à l’utilisateur

.
T
‘il veut mettre à jour la catégorie actuelle.

C
 Diagramme de séquence système :
Créer catégorie

AM I
N Y
ph i n
.R u
M s c
C T.
 Diagramme de séquence système :
éditer catégorie
<<System>>
GESCAT
Gestionnaire
ref

I
s' authentifier()

M
1: ID
2: verifictaion

Y A
alt TRUE

N
categorie affichee

i n
3: editer

u ph
confirmation

.R
ELSE

s c
nouvelle categorie

M
ref

.
DS Creer categorie()

C T
 Diagramme de séquence système :
delete catégorie

AM I
N Y
ph i n
.R u
M s c
C T.
Diagramme de séquence système :
créer produit

AM I
N Y
ph i n
.R u
M s c
C T.
Diagramme de séquence système :
éditer produit <<System>>
GESCAT
Gestionnaire
ref
s' authenti fi er()

I
1: IDproduit
2: verifier(idp)

AM
alt IF

Y
libelle, prix, photo affichee

3: editer(n_lib, n_prix, new_ph)

i n N
u ph
produit affichee

c .R
ELSE

s
nouveau produit Exception

T. M
ref
DS aj out produi t()

C
 Réalisation des cas d’utilisation : analyse
Nous distinguerons trois types de classes d’analyse
(comme proposé par I. Jacobson) :

• les « dialogues » qui représentent les moyens

AM I
N Y
d’interaction avec le système,

i n
• les « contrôles » qui contiennent la logique

ph
applicative

.R u
• et les « entités » qui sont les objets métier

s c
manipulés.

T. M
C
 Le diagramme de séquence système :
S’authentifier
<<System>>
GESCAT
Gestionnaire
1: seConnecter

2: cadre d'authentification

AM I
N Y
loop [<= 5]
4: verification

n
3: loginMotDePasse

ph i
u
alt ALORS
break

.R
5:[Condi ti on]
connexion reussie

s c
SINON
6: connexion échouée

T. M
C
 Création Catégorie
sd C o nceptio n

Gestionnaire
EcranGestio nC atalo gue Gestio nCatalogue cat:
HashMap<C atego rie>
saisieCategorie(id, nom, photo)

alt Etat saisie verifierChamps(): boolean

I
[FALSE]

M
erreur saisie ()

Y A
[TRUE]
valider()

N
addCategorie(id, nom, photo): Categorie

i n
alt

ph
create()
[IF]
put(nouvelle.id, nouvelle)
nouv elle:

u
create() C atego rie

.R
V ueC o nfirmatio n

c
opt editer()

M s
[ELSE] create()

T.
V ueExceptio n

C
 Edition Catégorie
sd C onception

Gestionnaire
EcranGestionC atalogue GestionC atalogue cat:
HashMap<Categorie>
editerCategorie(id, nom, photo)

I
alt Etat saisie verifierChamps(): boolean

M
[FALSE]
erreur saisie ()

[TRUE] editer()

N Y A
n
updateCategorie(id, nom, photo): Categorie

ph i
alt create()
[IF]

u
put(nouvelle.id, nouvelle)nouvelle:

.R
create() C ategorie

c
V ueC onfirmation

M s
[ELSE]

.
create()

T
V ueException

C
 Création Produit
sd Conception

Gestionnaire
EcranGestionCatalogue GestionC atalogue produits:
HashMap<Produit>
creerProduit(id, libelle, prix, photo)

I
alt Etat saisie verifierChamps(): boolean

M
[FALSE]

A
erreur saisie ()

N Y
[TRUE] editer()

i n
addProduit(id, nom, photo): Categorie

ph
alt create()

u
[IF]
put(nouveau.id, nouveau) nouveau:

.R
create() Produit

s c
V ueConfirmation

. M
[ELSE]

T
create()

C
VueException
 Edition Produit
Gestionnaire
EcranGestionCatalogue GestionCatalogue produits:
HashMap<Produit>
editerProduit(id, libelle, prix, photo)

I
alt Etat saisie verifierChamps(): boolean

M
[FALSE]

A
erreur saisie ()

N Y
[TRUE] editer()

i n
updateProduit(id, nom, photo): Categorie

ph
alt create()

u
[IF]

.R
put(nouveau.id, nouveau) nouveau:
create() Produit

s c
V ueConfirmation

. M
[ELSE]

T
create()

C
VueException
 Sous forme de cas d’utilisation
uc Use Case Model

rechercher
par mot-cle
recherche

I
par ID

YAM
n N
Rechercher

i
rechercher

ph
produit par

u
Client
categorie

s c .R
T. M
C
Conception préliminaire
• Intéressons-nous au moment où le Client consulte le Catalogue
de produit. Que se passe-t’il derrière le dialogue concerné ?

M I
• Celui-ci passe la main à un contrôle spécialisé dans la gestion du

A
Y
Catalogue. Ce contrôle a la responsabilité de rechercher les

N
produits dans le catalogue. Il est également responsable

ph i n
d’afficher un dialogue particulier récapitulant le résultat de la

u
recherche.

s c .R
T. M
C
 «System»
GESCAT
Client
lo o p

alt
[rapide] rechercheRapide(motCles)

[avancee]

AM I
Y
rechercheAvancee(parametres)

i n N
ph
alt

.R u
[echec] aucun produit trouvé()

M s c[succé]

T.
resultat trouvé()

C
 Client
EcranRecherche CtrlCatalogue categorie: produits:
HashMap<Long, HashMap<Long,
Categorie> Produit>
loop produit in HashMap
rechercheParID(id): Produit

produitParId(id): Produit

I
find(id): Produit

AM
init(myCate): Categorie

N Y
alt neant()

i n
[echec] create()

ph
ErreurResultat

.R u
details()
[succé]

c
create()

M s
DetailRecherche

.
opt mettreDansPanier()

C T
 Client
EcranRecherche CtrlCatalogue categorie: produits:
HashMap<Long, HashMap<Long,
Categorie> Produit>
loop produit in HashMap
rechercheParMotCles(mc): List<Produit>

produitParMotCles(mc): List<Produit>

I
contains(mc): List<Produit>

AM
init(myCate): Categorie

N Y
alt neant()

i n
[echec] create()

ph
ErreurResultat

.R u
[succé] details()

c
create()

s
DetailRecherche

. M
opt mettreDansPanier()

C T
 sd DS Conception

Client
EcranRecherche CtrlCatalogue categorie: produits:
HashMap<Long, HashMap<Long,
Categorie> Produit>
loop cat in HashMap
rechercheParCategorie(cat): List<Produit>

produitParCategorie(cat): List<Produit>

I
myCategorie.nom.equals(cat): List<Produit>

AM
init(myCate): Categorie

N Y
alt neant()

i n
[echec] create()

ph
ErreurResultat

.R u
[succé] details()
create()

s c
DetailRecherche

M
opt

.
mettreDansPanier()

C T
 Etude de Cas : Gestion Catalogue Produit
• Créer une application, qui permet de gérer un
catalogue de produits appartenant à des catégories.
• Une catégorie est définie son identifiant, son nom et

I
sa photo

Y
• Un produit, appartenant à une catégorie, est définie
AM
N
par son identifiant, sa désignation, son prix et sa

i n
photo

u ph
• L’application devra permettre les opérations suivantes

.R
:

s c
- Ajouter une nouvelle catégorie

. M
- Ajouter un nouveau produit

C T- Consulter toutes les catégories

 Diagramme de Classe

AM I
N Y
ph i n
.R u
M s c
C T.
 Le Système d’information
• L’ champs d’action de l’informaticien, quel que soit
le niveau d’intervention.
• Un SI est un « Tout constitué d’éléments unis par de
relations.

AM I
Y
• Ces éléments et relations sont munies de propriétés
• Le décrire revient à déterminer :

i n N
ph
- ses éléments (classes) et relations (Associations).

.R u
- Leurs propriétés (attributs et méthodes) et les valeurs

c
qu’elles peuvent prendre

M s
- L’activité

.
T
- Et l’organisation qui en découle

C
 SI: Eléments et Relations
• Les éléments d’un SI : Objet, Entité ou Individu
(classes) ou Concept

I
• Le propriétés sont appelées « attributs »

Y
• Les relations entre ses éléments « Associations »
AM
i n N
u ph
Association Navigable Agrégation faible Composition

s c .R
M
Association de

.
Réalisation Héritage direction

C T
 Entreprise comme SYSTEME
• On peut dire qu’il est constitué des « employés », de « Services », des
« articles », des « emplacements de stockage »

M
• Les propriétés décrivant ces éléments : matricule, nom employé,

A I
Y
code article, libelle, prix, le stockage

i n N
• Les relations entre ces éléments sont : « est attaché » entre un

ph
employé et un service, la relation « est stocké » entre un article et

u
emplacement de stockage

c .R
• Les propriétés de ces relations seront de type : date d’entrée dans le

s
M
service, la quantité stockée dans l’emplacement de stockage

C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Formalisme général et exemple

AM I
N Y
ph i n
.R u
M s c
C T.
 Modificateurs de classe

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Objet : Techniquement
• Objet = Etat + Comportement + Identité
• Etat : l’ensemble de valeurs prises par les attributs en un

I
moment donné.

AM
• Exemple:

N Y
ph i n
.R u
M s c
C T.
 Objet : Comportement
• Ensemble d’opérations que l’objet peut effectuer.
Chaque opération est déclenchée par l’envoi d’un
message

AM I
N Y
ph i n
. R u
s c
Comportement
M
CT.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Objet : Identité
• Permet de distinguer les objets
indépendamment de leur état

I
• Exemple:

Y AM
i n N
u ph
s c .R
. M
Chacun a sa référence

T
mémoire différente de

C
l’autre
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Association réflexive

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Classifications
• Classes du domaine (métier) : ne contenant que les
entités ou éléments (documents, concepts, éléments) du
domaine d’étude. Ces classes peuvent contenir quelques
attributs et optionnellement les opérations.

AM I
Y
• Classes participantes (classes d’analyse) : contenant en

i n N
plus des entités, les formulaires et les contrôleurs.

u ph
• Classes de conception : contiennent les contraintes

.R
techniques et prêtes à être traduites en codes sources

s c
• Classes de persistance : contiennent les tables et champs
M
T.
de la base de données.

C
 Classes d’analyse
• Il y a trois types de classes à modéliser dans la phase d’analyse :
1. les « dialogues » qui représentent la quasi-totalité des échanges d’information
entre l’utilisateur et le système logiciel (l’entrée de données par l’utilisateur,
affichage de questions posées à l’utilisateur par le système, affichage de résultats
obtenus,…) ;

M I
2. les « contrôles » qui constituent le canal de validation et communication entre le

A
dialogue et la partie données, jouant ainsi le rôle l’intelligence de l’application

Y
cachée ;

N
3. et les « entités » qui sont les concepts issus du métier contenant des données à

i n
persister.

ph
Par respect de protocole de communication, toute modélisation de ces trois classes

u
peut se faire en obéissant aux règles suivantes : les classes « dialogues » dépendant de

.R
« contrôle » et les classes de contrôle dépendant des entités.

c
Par ailleurs, les dialogues peuvent contenir les attributs (représentant les champs de

s
saisies, liste de choix) et les opérations (actions de l’utilisateur sur les différents

M
contrôles graphiques) ; les classes de contrôle contiennent uniquement l’interface

.
de classes entités ; et les entités contiennent les attributs seulement et, les entités

T
peuvent être en relation entre elles.

C
 Classes participantes

AM I
N Y
ph i n
.R u
M s c
C T.
Objets métier
<<entity>>
• Catégorie (id, nom, photo) Categorie
- idcat : long

I
- nom : String
• Produit (id, libelle, prix, photo)

M
- photo : String

N Y
1..1

A
ph i n
1..*

u
<<entity>>

.R
Produit
- idp : long

c
- libelle : String

s
- prix : double

M
- photo : String

C T.
 Classe participante
<<dialog>>
EcranCatalogue <<entity>>
- idcat : long <<control>> Categorie
- nomCat : String GestionCatalogue - idcat : long

I
- photo : String 1..1 - nom : String

M
- idProduit : long 1..* - photo : String

A
+ creerCategorie ()
- libelle : String

Y
1..1 + editerCategorie () 1..*
- prix : double

N
+ supprimerCategorie ()
- photoProduit : String

n
+ creerProduit () 1..1

ph i
+ ajouterProduit () + editerProduit () 1..*
+ editerProduit () + supprimerProduit ()

u
+ supprimerProduit () ... <<entity>>

.R
1..* Produit
+ creerCategorie ()
1..1

c
+ editerCategorie () - idp : long

s
+ supprimerCategorie () - libelle : String

M
... - prix : double

.
- photo : String

C T
 Diagramme de classes de conception
class Use Case Model

EcranCategorie
- idCategorie: Long
- nomcate: String
Categorie
- idcat: Long
- nom: String
GestionCatalogue - photo: String
+ addCategorie(Long, String, String): Categorie + afficher(): List<Categorie>
+ addProduit(Long, String, double, String): Produit + creer(Categorie): Categorie
+ editerCategorie(Long, String, String): Categorie + editer(Categorie): Categorie

I
- photp: String + editerProduit(Long, String, double, String): Produit + supprimer(Long): boolean
+ findAllCategorie(): List<Categorie>

M
+ afficherCategorie(): void
+ rechercherCategorieParId(Long): Catgorie 1
+ creerCategorie(): void

A
+ editerCategorie(): void + rechercherProduitParMotCles(String): List<Produit>

Y
+ rechercherCategorie(): void + supprimerCategorie(Long): boolean
1..*

N
+ supprimerCategorie(): void + supprimerProduit(Long): boolean
+ trouverProduitParId(Long): Produit Produit

i n
- idp: Long

ph
- libelle: String
- photo: String

u
EcranProduit - prix: double

.R
- idp: Long + afficher(): List<Produit>
ResultatRecherche Exception + creer(Produit): Produit

c
- libelle: String

s
- photo: String - resultat: String + editer(Produit): Produit
- prix: double + supprimer(Long): boolean

. M
+ afficherTout(): void
+ creerProduit(): t

T
+ editerProduit(): void

C
+ rechercherParId(): void
+ rechercherParMotCle(): void
+ supprimerProduit(): void
 D ia lo gu e

Ec r a nP r o du it Ec r a nC a tego r ie
- idp: Long - idCategorie: Long
- libelle: String - nomcate: String
- photo: String - photp: String
- prix: double
+ afficherCategorie(): void
+ afficherTout(): void + creerCategorie(): void
+ creerProduit(): t + editerCategorie(): void
+ editerProduit(): void + rechercherCategorie(): void
+ rechercherParId(): void + supprimerCategorie(): void
+ rechercherParMotCle(): void
+ supprimerProduit(): void

«import»

I
Lo giqu e applic ati v e

M
G estio nC ata lo gu e

A
+ addCategorie(Long, String, String): Categorie

Y
+ addProduit(Long, String, double, String): Produit
+ editerCategorie(Long, String, String): Categorie

N
+ editerProduit(Long, String, double, String): Produit
+ findAllCategorie(): List<Categorie>

n
+ rechercherCategorieParId(Long): Catgorie

i
+ rechercherProduitParMotCles(String): List<Produit>
+ supprimerCategorie(Long): boolean

ph
+ supprimerProduit(Long): boolean
+ trouverProduitParId(Long): Produit

.R u
«import»

c
Mo dels

M s
P r o du it
C a tego r ie

.
- idp: Long
- libelle: String - idcat: Long

T
- photo: String - nom: String
- prix: double - photo: String

C
1..* 1
+ afficher(): List<Produit> + afficher(): List<Categorie>
+ creer(Produit): Produit + creer(Categorie): Categorie
+ editer(Produit): Produit + editer(Categorie): Categorie
+ supprimer(Long): boolean + supprimer(Long): boolean
 Classes participantes : exemple

AM I
N Y
ph i n
.R u
M s c
C T.
 DIAGRAMME D’ACTIVITE

AM I
N Y
ph i n
.R u
M s c
C T.
 DIAGRAMME D’ACTIVITE UML
La logique procédurale par le DAC d’un Workflow
• Permet de décrire la logique procédurale

I
d’une activité
• Modélisation de processus métier
Y AM
i n N
• Prend en charge le comportement parallèle

u ph
• Il est très proche de l’algo, ordinogramme

s c .R
T. M
C
 INTRODUCTION

AM I
N Y
ph i n
.R u
M s c
C T.
 CONCEPTS DE BASE

AM I
N Y
ph i n
.R u
M s c
C T.
 NOTIONS D’ETATS

AM I
N Y
ph i n
.R u
M s c
C T.
 NOTION DE TRANSITION

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 FLOW D’OBJET

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 TRANSITION CONDITIONNELLE

AM I
N Y
ph i n
.R u
M s c
C T.
 NŒUD DE FUSION TEST

AM I
N Y
ph i n
.R u
M s c
C T.
 NOTION DE SYNCHRONISATION

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Diagramme de communication UML

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Diagramme de compo UML

AM I
N Y
ph i n
.R u
M s c
C T.
 VUE D’IMPLÉMENTATION
DIAGRAMME COMPOSANTS

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 DIAGRAMME DE COMPOSANT

AM I
N Y
ph i n
.R u
M s c
C T.
 VUE DE DÉPLOIEMENT :
DIAGRAMME DE DÉPLOIEMENT

AM I
N Y
ph i n
.R u
M s c
C T.
 VUE DE DÉPLOIEMENT :
DIAGRAMME DE DÉPLOIEMENT

AM I
N Y
ph i n
.R u
M s c
C T.
 Nœud

AM I
N Y
ph i n
.R u
M s c
C T.
 Supports de communication
• Les supports de communication sont symbolises par des
relations entre les nœuds.

I
• La nature du support peut être précisée par un

M
stéréotype : <<mémoire>>, ...

N Y A
• Le support de communication est a priori bidirectionnel

ph i n
.R u
M s c
C T.
 Exemple : Vue de déploiement

AM I
N Y
ph i n
.R u
M s c
C T.
Exemple d’un diagramme de Déploiement
PC SERNIE https
Serveur applicatif

I
Navi gateur

M
Apache.2.5.exe

Serveur base de données

A
tcp : 3306

Y
web_app MySQL.6.exe db_cursus.sql

N
https

i n
PC Chef

ph
etablissement
Navigateur
https
https

.R u
PC Eleve

c
Navi gateur

s
PC Service

M
Scolarite

.
Navigateur

C T
 Diagramme de package

AM I
N Y
ph i n
.R u
M s c
C T.
 Diagramme de package

AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 AM I
N Y
ph i n
.R u
M s c
C T.
 Modèle en couche
<<Layer>>
IHM

AM I
<<Layer>>

N Y
i n
Logique du metier

u ph
s c .R <<Data Layer>>

M
Base de données

C T.
 Représentation détaillée
Entity

Gestion Catalogue

Dialogue Controleur

AM I
Y
«import» «import» «import» «import»

i n N
Gestion Commande

ph
Gestion Client

u
«import»

s c .R
T. M
C
 Travail pratique de Conception Système d’Information
• Groupe 1 : Administration de dossiers médicaux
de manière centralisée dans l’Inspection
Provinciale de la Santé.

AM I
N Y
ph i n
.R u
M s c
C T.
ATELIER DE GENIE LOGICIEL
- Outils de conception (upper-case)

M
- et les environnements de développement
A I
Y
(lower-case)

i n N
u ph
s c .R
T. M
C