Systèmes d’information

Partie 1

Pr. Lamyae Maatougui

Lamy.maatougui@gmail.com 2019/2020
 Introduction
Notion de système pour l’entreprise
 Un système est un ensemble d’éléments matériels ou immatériels (hommes,
machines, méthodes, recettes, règles, etc.)

 Ces éléments sont unis par des relations qui transforme, par un processus, des
éléments (les entrées) en d’autres éléments (les sorties).

 Exemple
 Introduction
Notion de système pour l’entreprise
 Le système qui correspond à l’activité de l’entreprise (transformation de flux) est
appelé : système opérant (SO).
 L’entreprise a aussi besoin d’un système de prise de décision qui lui permet de
réaliser les objectifs fixés. Ce système est appelé système de pilotage (SP).
 Le SP procède à la régulation et au contrôle du système opérant en décidant du
comportement de celui-ci.
 Introduction
Notion de système pour l’entreprise
 Avec l’augmentation en quantité et
en complexité des informations
échangées entre ces deux systèmes,
on a besoin d’avoir un autre système
qui stocke et traite de façon plus
efficace ces informations.

 Ce système est appelé système

d’information (SI).
 Introduction
Notion de système pour l’entreprise
 Le SI est composé d’éléments divers :
 Employés;
 Ordinateurs;
 Procédures;
 Règles et méthodes;
 etc.

 Le SI collecte et traite les informations relatives au système opérant (SO) afin de les mettre à la
disposition du système de pilotage (SP).

 Le SI possède deux aspects :

 Aspect statique (ou aspect données) :
 base d’information,
 modèle (ou structure) de données.
 Aspect dynamique (ou aspect traitement) :
 circulation de l’information entre les différents acteurs,
 évolution chronologique des opérations provoquées par des évènements.
 Introduction
Système Automatisé d’Information (SAI)
 Dans un SI, on retrouve
 des décisions (homme)
 des actions programmées (machine)

 Un SAI est un sous-système d’un SI dans lequel toutes les transformations

significatives d’information sont effectuées par des ordinateurs.

 Un SAI permet une conservation et un traitement automatique des informations.

 Introduction
Système Automatisé d’Information (SAI)
 Un SAI doit être

 intégré : une même information n’est saisie qu’une fois en un point du

système et est récupérée dans tous les fichiers concernés.

 durable et adaptable : les logiciels de traitement des données

(programmes) sont indépendant des données
 Introduction
Composition
 Le SI se divise en deux parties :

 Le SI automatisé
 Procédures répétitives
 Gestion des documents de l’entreprise
 Tâches coordonnées
 Le SI non automatisé
 Discussions informelles
 Informations non écrites
 Introduction
Fonction du SI

Un SI a deux fonctions principales

 La production d’information
• Collecter des informations
• Traiter et transmettre des informations
• Mémoriser des informations

 La mise en œuvre d’outils de gestion

• Fonction technologiques (matériels, logiciels,
méthodes, savoir-faire, …)
• Fonction économique
• Fonction sociale
 Introduction
Analyse et conception de SI
On doit :
o Bien comprendre les demandes et exigences des utilisateurs finaux
o Bien communiquer avec le client
o Tenir compte des changements du cahier de charges
o Empêcher la découverte tardive de défauts sérieux dans le projet
o Traiter au plus tôt tous les points critiques du projet
o Bien maîtriser la complexité
o Favoriser la réutilisation
o Définir une architecture robuste
o Faciliter le travail en équipe

Nous avons, donc, besoin de:

Modèles,
Méthodologie.
 Introduction
Analyse et conception de SI
A quoi sert une méthode
 Une méthode définit une démarche qui produit des résultats fiables.
 Une méthode d’élaboration de logiciels décrit comment modéliser et construire des systèmes logiciels de manière fiable et
reproductible.

De manière générale, une méthode définit:

 Des éléments de modélisation,
 Une représentation graphique,
 Du savoir-faire et des règles

Avec, en autre, les objectifs suivants:

 Se donner toutes les chances de mener à bien un projet informatique,
 Établir un plan projet réaliste en définissant, estimant et planifiant les moyens à mettre en œuvre,
 Maîtriser le projet en mesurant son avancement et les écarts éventuels avec les engagements pris,
 S'assurer que la qualité définie est respectée.

Et une évidence:
Le système d'information des entreprises actuelles est devenu l'un des principaux piliers sur lesquels repose l'ensemble de
l'activité.
Impossible donc de traiter ce domaine de manière approximative.
 Introduction
Analyse et conception de SI
Des méthodes fonctionnelles aux méthodes objet
Une évolution des méthodes qui s’est toujours faite de la programmation vers l’analyse :

Programmation Conception Analyse

 Les premières méthodes d'analyse (années 70)
Découpe fonctionnelle (fonctionnelle et hiérarchique) d'un système.

 L'approche systémique (années 80)

Modélisation des données + modélisation des traitements (Merise, Axial, ..).

 L'émergence des méthodes objet (1990-1995)

 Prise de conscience de l'importance d'une méthode spécifiquement objet :
comment structurer un système sans centrer l'analyse uniquement sur les données
ou uniquement sur les traitements (mais sur les deux) ?
 Plus de 50 méthodes objet sont apparues durant cette période (Booch, Classe-
Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) !
 Aucune méthode ne s'est réellement imposée.
 Introduction
Analyse et conception de SI
Des méthodes fonctionnelles aux méthodes objet (suite) :

 Les premiers consensus (1995)

 OMT (Object Modeling Technique - James Rumbaugh) - Méthode d'analyse et de conception orientée objet. Vues
statiques, dynamiques et fonctionnelles d'un système.

 OOD (Object Oriented Design - Grady Booch). Vues logiques et physiques du système.

 OOSE (Object Oriented Software Engineering - Ivar Jacobson). Couvre tout le cycle de développement. Une des
plus anciennes méthodes objet focalisée sur le modèle statistique.

 L'unification et la normalisation des méthodes (1995-1997)

 UML (Unified Modeling Language) est né de la fusion de ces 3 méthodes qui ont le plus influencé la modélisation
objet au milieu des années 90

Fin 1997, UML devient une norme OMG (Object Management Group).
L'OMG est un organisme à but non lucratif, créé en 1989 à l'initiative de grandes sociétés (HP, Sun, Unisys, American
Airlines, Philips...). Son rôle est de promouvoir des standards qui garantissent l'interopérabilité entre applications
orientées objet, développées sur des réseaux hétérogènes.
 Introduction
Méthodes de conception des SI

Dans le cadre de ce cours nous allons se concentré sur les modèles pour les donnée en utilisant:

 Méthode objet (type UML - Unified Modelling Language)

Pour les données et les traitements

 Méthode systémique (type MERISE)

Pour les données
Modélisation UML
 Modélisation UML
Qu'est-ce qu'un modèle ?
La modélisation consiste à créer une représentation simplifiée d'un problème: le
modèle.
Grâce au modèle il est possible de représenter simplement un problème et le simuler.

La modélisation comporte deux composantes:

 L'analyse, c'est-à-dire l'étude du problème

 La conception, soit la mise au point d'une solution au problème

Le modèle constitue ainsi une représentation possible du système pour un point de vue
donné.
 Modélisation UML
La modélisation UML

L’UML fournit des outils permettant de représenter l'ensemble des éléments du

monde objet (classes, objets, ...) ainsi que les liens qui les relie. Toutefois, étant
donné qu'une seule représentation est trop subjective, UML fournit un moyen
astucieux permettant de représenter diverses projections d'une même représentation
grâce aux vues.
Une vue est constitué d'un ou plusieurs diagrammes.
 Modélisation UML
UML a été pensé pour permettre de modéliser les activités de l'entreprise.

Les points forts:

 UML est un langage formel et normalisé qui permet un ƒgain de précision et de
stabilité en encourageant l'utilisation d'outils
 UML est un support de communication performant.
ƒ-Il cadre l'analyse.
-Il facilite la compréhension des problèmes compliqués.
-ƒSon caractère polyvalent et sa souplesse en font un langage universel.
 Les points faibles d'UML
Les points faibles:

 La mise en pratique d'UML nécessite un apprentissage.

 Les auteurs d'UML sont tout à fait conscients de l'importance du processus, mais
l'acceptabilité industrielle de la modélisation objet passe d'abord par la
disponibilité d'un langage d'analyse objet performant et standard.
 Les éléments de modélisation
Les objets etudiant : Personne

la description d’une entité du monde réel ou virtuel

Les classes
Personne
la description d’un ensemble d’objets

Les états
Attente
une étape de la vie d’un objet

Les acteurs
utilisateurs finaux du système administrateur
 Les éléments de modélisation
Les cas d’utilisation

Une manière dont un acteur utilise le système

Les collaborations

La réalisation d’un cas d’utilisation par une société d’objets

collaborants

Les micro-architectures (patterns)

Un générateur pour la structure et l’interaction d’une société

d’objets
 Les éléments de modélisation
Les composants

Un module contenant des entités d’implémentation

Les noeuds

Un dispositif matériel capable d’exécuter du logiciel

Les paquetages

Une partition du modèle

Les notes

Un commentaire, une explication ou une annotation

 Les éléments de modélisation
L’association

Une connexion sémantique entre instances

La généralisation

Une relation de classification

La dépendance

L’utilisation d’un élément par un autre

 Les qualificatifs d’attribut
Publique :
Un attribut publique pourra être accéder (lu et modifié) par tout le monde.

Protégée :
Un attribut protégé pourra être accéder (lu et modifié) par les classes
héritières.

Privée :
Un attribut privée pourra être accéder (lu et modifié) par les méthodes et
seulement les méthodes de sa classe.
 Modélisation Objet
Modélisation par un ensemble d’entité Objet

Un Objet peut être:

1) Physique: (Enseignant, Livre, Voiture…)

2) Abstrait: (opération de vente, ligne commande, Adresse_Machine…)

 UML utilise 9 Diagrammes
1. Diagramme de cas d’utilisation
2. Diagramme de classes
3. Diagramme d’objets
4. Diagramme de composants
5. Diagramme de déploiement
6. Diagramme d’états
7. Diagramme d’activités
8. Diagramme de séquence
9. Diagramme de collaboration
UML utilise 9 Diagramme
 1. Le diagramme de cas d’utilisation (DCU)

Les cas d’utilisation sont une technique utilisée pour représenter un ensemble de
séquences d’actions que devrait réaliser le système privilégiant le point de vue de
l’utilisateur.

Exemple
Pour le cas d’utilisation d’un guichet automatique de banque, on ne dira pas «
Distribuer de l’argent » favorisant ainsi le coté système,
On dirait plutôt « Retirer de l’argent » pour favoriser le coté utilisateur.

Un DCU montre QUI fait QUOI ?

1. Le diagramme de cas d’utilisation (DCU)
Notation
1. Le diagramme de cas d’utilisation (DCU)
Exemple de CU avec Notation UML
1. Le diagramme de cas d’utilisation (DCU)
Inclusion / extension
 1. Le diagramme de cas d’utilisation (DCU)
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.
« include »
B A

Cette dépendance est symbolisée par le stéréotype «include»

On utilise cette relation pour:

*éviter de décrire plusieurs fois un même enchaînement d'actions. On factorise un

comportement commun à plusieurs cas d'utilisation dans un cas d'utilisation à part.

*décomposer un cas complexe en sous-cas plus simples.

 1. Le diagramme de cas d’utilisation (DCU)
Inclusion

Par exemple:

L’accès aux informations d’un compte

bancaire inclut nécessairement une phase
d’authentification avec un mot de passe.
 1. Le diagramme de cas d’utilisation (DCU)
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

« extend » A
B
point d’extension

Cette dépendance est symbolisée par le stéréotype « extend »

Le comportement ajouté s’insère au niveau d’un point d’extension définit dans A.
 1. Le diagramme de cas d’utilisation (DCU)
Extension

Par exemple:

La vérification du solde du compte

n’intervient que si la demande de retrait
d’argent dépasse 500 DHs.
1. Le diagramme de cas d’utilisation (DCU)
Généralisation / Spécialisation
1. Le diagramme de cas d’utilisation (DCU)
Hiérarchisation des acteurs

Ce que Fait A = Action (B) + Action (C) + Action (D)

1. Le diagramme de cas d’utilisation (DCU)
Exemple pratique
 1. Le diagramme de cas d’utilisation (DCU)
Conclusion
Pour modéliser le diagramme des cas d'utilisation, il faut:

Identifier les acteurs qui entourent le système. Certains acteurs utilisent le système pour accomplir des tâches
(acteurs principaux), d'autres effectuent des tâches de maintenance ou d'administration (acteurs secondaires).

Organiser les acteurs selon une hiérarchisation de généralisation/spécialisation

Intégrer les acteurs au diagramme en spécifiant les cas d'utilisation auxquels ils se rapportent

Structurer les cas d'utilisation pour faire apparaître les comportement partagés (relation d'inclusion), les cas
particuliers (généralisation/spécialisation) ou options (relation d'extension)
 Exemples pratiques
a. Éléments constitutifs des cas d’utilisation
Acteur : entité externe qui agit sur le système; Le terme acteur ne désigne pas seulement les utilisateurs humains
mais également les autres systèmes.
Les acteurs sont des classificateurs qui représentent des rôles au travers d'une certaine utilisation (cas) et non pas
des personnes physiques. Ce sont des acteurs types.

Cas d’utilisation : ensemble d’actions réalisées par le système en réponse à une action d’un acteur.
-les cas d’utilisation peuvent être structurés,
-les cas d’utilisation peuvent être organisés en paquetages,
-l’ensemble des cas d’utilisation décrit les objectifs du système.
 Exemples pratiques
a. Éléments constitutifs des cas d’utilisation
Exemple: Diagramme de cas d’utilisation d’un guichet automatique bancaire
 Exemples pratiques
b. Description des cas d’utilisation
Pour décrire un cas d’utilisation, il nous faut décrire un maximum de chemins d’exécution possibles pour la séquence
d’actions correspondant à ce cas. On étudiera donc un certain nombre de scénarios d’un cas d’utilisation.

Un scénario est donc un ensemble d'évènement.

 Ce scénario suivra un chemin particulier dans la description d’un cas d’utilisation.

 Un scénario ne contient pas de branche du type « si la condition X est vraie alors faire Y », car pendant l’exécution
la condition est soit vraie, soit fausse mais elle aura toujours une valeur. Bien sûr il est impossible de décrire un cas
d’utilisation en écrivant tous les scénarios, mais il faut répertorier les scénarios les plus représentatifs afin de gérer
les risques.
 On recherchera donc le ou les scénarios nominaux et les principaux cas d’exceptions.

Nous aurons donc deux niveaux de description :

- Description générale d’un cas d’utilisation reprenant les divers chemins pouvant être réunis en un même cas.
- Description des scénarios les plus pertinents.
 Exemples pratiques
b. Description des cas d’utilisation
a) Exemple : Cas d’utilisation Retirer de l’argent

1- Le client de la banque s’identifie

2- Le système lui propose les différents comptes sur lesquels il peut effectuer un retrait
3- Le client choisit le compte à débiter et spécifie le montant du retrait
4- Le système vérifie si le retrait est autorisé, si oui il déduit le montant du compte et délivre l’argent, sinon il
renvoie un message de rejet de l’opération

b) Exemple : scénario du cas d’utilisation :Retirer de l’argent ; retrait autorisé. Acteur déclencheur : M. X

Ce scénario commence par:

1- M. X s’identifie
2- Le système lui propose les différents comptes sur lesquels il peut effectuer un retrait
3- M. X choisit son compte chèque et demande 200dh /*Le système vérifie que le retrait est autorisé*/
4- Le système délivre deux billets de 100dh et demande à ce que M. X les saisisse.
Ce scénario se termine par
5- M. X prend l’argent.
 Exemples pratiques
c. Structuration des cas d’utilisation
Après avoir identifié les acteurs et les cas d’utilisation, il est utile de restructurer l’ensemble des cas d’utilisation que
l’on a fait apparaître afin de rechercher les comportements partagés, les cas particuliers et les généralisations.

Les relations possibles entre cas d’utilisation : UML définit trois types de relations standardisées entre cas
d’utilisation, détaillées ci-après :
 Une relation d’inclusion : formalisée par la dépendance « include »
 Une relation d’extension : formalisée par la dépendance « extend »
 Une relation de généralisation / spécialisation

Etapes de construction:
1. Les acteurs
2. Pour chaque acteur, recherche des cas d'utilisation,
3. Structuration des cas d'utilisation pour faire apparaître les comportements partagés (relation d'inclusion), les cas
particuliers ou options (relation d'extension), les généralisations / spécialisations
 Exemples pratiques
c. Structuration des cas d’utilisation
a) La relation d’inclusion : Lors de la description des cas d’utilisation, il apparaît qu’il existe des sous-ensembles
communs à plusieurs cas d’utilisation, il convient donc de factoriser ces fonctionnalités en créant de nouveaux
cas d’utilisation qui seront utilisés par les cas d’utilisation qui les avaient en commun.
Un cas d’utilisation A utilise un cas d’utilisation B signifie que :
- une instance de A va engendrer une instance de B et l’exécuter,
- A dépend de B,
- B n’existe pas tout seul et A n’existe pas sans B

Ces actions explicitent le cas

d’utilisation « S’authentifier »,
à un endroit spécifié dans leurs
enchaînements.
 Exemples pratiques
c. Structuration des cas d’utilisation
b) La relation d’extension

La relation <<extend>> permet d'étendre les interactions et donc les fonctions décrites par les interactions. Le cas de
base peut fonctionner tout seul, mais il peut également être complété par un autre, sous certaines conditions, et
uniquement à certains points particuliers de son flot d’évènements (point d’insertion). On utilise principalement cette
relation pour séparer le comportement optionnel (les variantes) du comportement obligatoire.

Considérons l’exemple : le cas d’utilisation B étend le cas d’utilisation A signifie que :

- Une instance de A va engendrer une instance de B et l’exécuter sous certaines conditions, B sait où s’insérer dans A.
- B connaît A et non l’inverse, c’est à dire que B dépend de A
- B n’existe pas tout seul et A existe sans B

La relation <<extend>> montre une possibilité d'exécution d'interactions qui augmenteront les fonctionnalités du cas
étendu, mais de façon optionnelle, non obligatoire, alors que la relation <<include>> suppose une obligation d’exécution
des interactions.
 Exemples pratiques
c. Structuration des cas d’utilisation
c) Relation de généralisation entre cas d’utilisation

Dans un système d'agence de voyage, un acteur touriste peut Exemple : Dans un système d’agence de voyage
participer à un cas de base qui est "Réserver voyage", qui
suppose par exemple des interactions basiques au comptoir de
l'agence. Une réservation peut aussi être réalisée par téléphone
ou internet. On voit qu'il ne s'agit pas de relation <<extend>>
car la réservation par Internet n'étend pas les interactions ni les
fonctionnalités du cas 'Réserver voyage". Elle les traduit
différemment. Les interactions Internet ne sont pas une option
des interactions comptoir. Par contre les deux cas "Réserver
voyage" et "Réserver voyage par Internet" sont liés : la
réservation par Internet est un cas particulier de réservation. De
façon générale en objet, une situation de cas particulier se
traduit par une relation de généralisation.
 Exercice1

Dans un établissement scolaire, on désire gérer la réservation des salles de cours ainsi que du matériel pédagogique
(ordinateur portable ou/et Vidéo projecteur). Seuls les enseignants sont habilités à effectuer des réservations (sous
réserve de disponibilité de la salle ou du matériel). Le planning des salles peut quant à lui être consulté par tout le
monde (enseignants et étudiants). Par contre, le récapitulatif horaire par enseignant (calculé à partir du planning des
salles) ne peut être consulté que par les enseignants. Enfin, il existe pour chaque formation un enseignant
responsable qui seul peut éditer le récapitulatif horaire pour l’ensemble de la formation.

Modéliser cette situation par un diagramme de cas d’utilisation

Solution
 Exercice2

Dans un magasin, le processus de vente est le suivant :

-le client entre, passe dans les rayons, demande éventuellement des renseignements ou procède à des
essais, prend des articles (si le stock est suffisant), passe à la caisse où il règle ses achats (avec tout moyen
de paiement accepté). Il peut éventuellement bénéficier d’une réduction.

Modéliser cette situation par un diagramme de cas d’utilisation

Solution
 Exercice 3

On considère le système suivant de gestion d’un DAB (Distributeur automatique de billets) :

- le distributeur délivre de l’argent à tout porteur de carte (carte Visa ou carte de la banque)
- pour les clients de la banque, il permet : o la consultation du solde du compte o le dépôt d’argent (chèque ou
numéraire)
- toute transaction est sécurisée et nécessite par conséquent une authentification
- dans le cas où une carte est avalée par le distributeur, un opérateur de maintenance se charge de la récupérer.
C’est la même personne qui collecte également les dépôts d’argent et qui recharge le distributeur.

Modéliser cette situation par un diagramme de cas d’utilisation

Solution