Méthodologies de

conception des SI

Objectif du cours

 Beaucoup de raisons pour étudier et

s’intéresser aux Systèmes d’Information (SI)

 Utiliser intensivement les SI existants

 Analyser des SI existants et identifier leurs forces
et faiblesses
 Emettre des recommandations d’amélioration
et/ou de modifications
 Proposer, participer à la conception et réalisation
de nouveaux SI

1
Plan du cours
 Introduction aux SI
 Méthodologies de conception :
 Importance dans le cycle de développement d’un
logiciel
 Historique et caractéristiques des différentes
approches:
 Approche objet
 Le langage UML
 Principaux diagrammes
 Processus unifiés

Information
 Le bon fonctionnement d'une organisation, voire sa
survie, est conditionné par la mise en place d'une
communication cohérente et fluide :
 entre ses différentes composantes

 avec son environnement externe

 L'essence de cette communication est l'information

 Cette information n'est utile que si elle est exploitée et
mise à disposition de façon optimale
 Or,
 augmentation du volume d'informations à traiter

 complexité croissante de la communication dans les

organisations

2
Système d’Information

 Nécessaire pour gérer cette ressource

stratégique qu'est devenue l'information
 Composante indissociable des organisations

« le système d'information suppose

l'organisation et celle-ci ne fonctionne pas
sans lui » ( J.L. Peaucelle )
 Le SI d’une entreprise est l’ensemble des
données et des traitements qui sont
nécessaires et suffisants à son
fonctionnement

Information et donnée

 Donnée: Signe+ code

Elle peut être numérique, alphanumérique, ….
Exemple : 71540325
 Information: donnée +interprétation

Exemple : C’est un numéro de téléphone

 L’information peut-être interprétée par un être
humain et elle apporte alors de la connaissance
Exemple : ce numéro correspond à un abonné de
Tunis

3
Évolution des applications de gestion
 60-80
 stockage et restitution d'informations
 structures plates (fichier, ligne de table)
 traitement simple (mise à jour et édition de données)
 80- ..
 objets complexes (texte, graphiques, images)
 traitements plus élaborés (tableau de bord, système expert,
statistiques)
 intégration (bureautique, multimédia, web)
 Les méthodes de conception doivent évoluer

Cycle de vie du logiciel

4
Cycle de développement du logiciel

 Plusieurs catégories de modèles ou de méthodes ont

été proposés pour décrire le cycle de développement
du logiciel
 Les modèles définissent des étapes clairement
identifiables et censées correspondre à l’achèvement
d’une partie du travail
 Catégories de modèles
 Code and fix
 Linéaire
 Itératif

Code and Fix

 Approche chaotique (coder,
tester et réparer)
 Code devient rapidement
déstructuré, très difficile à
comprendre, modifier, gérer, etc
 Correspond en réalité à
l’absence de modèle
 Ne peut plus s’appliquer aux
projets post années 70
 Taille, complexité, spécifications
changeantes
 Crise du logiciel

5
Catégorie linéaire

 Processus logiciel bien défini et inclut

souvent des procédures détaillées suivies
plus ou moins de façon périodique
 L’analyse des besoins et la conception sont
identifiées, passées en revue, et acceptées
 Modèle en cascade, V

Modèle en cascade (Années 65-75)

Waterfall Model…
 Modèle qui permet de
définir les principales étapes
du processus logiciel
 Les activités sont
représentées dans des
processus séparés
 Après chaque étape un
délivrable est produit et on
passe à la prochaine étape
 Originalement ce modèle fut
proposé de façon linéaire
sans «backtracking»
 Ceci est un objectif difficile à
atteindre

6
 Modèle en cascade (Années 65-75)
Waterfall Model…
 Étude de faisabilité
 Définir le problème, définir et étudier les alternatives, définir les
coûts et les délais
 Analyse des besoins et spécifications
 Définir les attendus du système, aboutir à un document de
spécification lisible, précis, complet, consistant et non ambigu
 Aboutir aux besoins fonctionnels et non fonctionnels
 Conception architecturale
 Définir les modules qui constituent le système et leurs relations
 Selon le contexte, la conception détaillée correspond à:
 Définir les interfaces utilisateurs
 Définir les types, les algorithmes

Modèle en cascade (Années 65-75)

Waterfall Model…
 Codage et test unitaire
 Écriture du code source, test des modules séparément par rapport à la
conception architecturale
 Intégration et Test système
 Assembler les modules (gérer les versions)
 Tester le système
 Test de régression
 Alpha testing: Mettre l’application entre les mains d’utilisateurs
compréhensifs
 Beta testing: Élargir la base des utilisateurs
 Mise en exploitation et maintenance
 Le système est installé sur site à large diffusion. On distingue 3 sortes de
maintenance
 Maintenance corrective
 Maintenance adaptative
 Maintenance perfective

7
Modèle en cascade
avantages et inconvénients
 Bien adapté pour des petits systèmes
 Mal adapté à des systèmes complexes
(processus de développement rarement
séquentiel)
 Les tests s'appliquent à l'application globale
(pas de validation des besoins)
 Difficulté de définir tous les besoins dés le
début du projet
 Délai assez long pour voir quelque chose

Modèle en V
V Model
 Variante du modèle en cascade

8
Modèle en V
avantages et inconvénients
 Tests bien structurés
 Hiérarchisation du système à développer
permettant une conception et un
développement modulaire
 Validation par rapport aux besoins
 Validation ou le test de réception trop tardifs
– très coûteux si des erreurs sont constatées

Catégorie Itérative

 Processus logiciel bien défini et inclut souvent les

procédures détaillées qu'on s'attend à ce que des
réalisateurs appliquent d'une façon itérative
 Les exigences peuvent être définies avec un niveau

d’abstraction élevé et affiné tout au long du processus

 Les modèles de cette catégorie sont:
 Prototypage
 Spirale
 Entreprise Unified Process (EUP)
 Rational Unified Process (RUP)
 2 TUP

9
Modèle prototypage
Je saurai ce que je veux lorsque je le verrai!
 Un prototype initiale peut évoluer jusqu’à avoir le système
définitif
 Utilisé pour comprendre les besoins de l’utilisateur
 Son but est de s’assurer de la faisabilité et vérifier les exigences
 Le produit est reconstruit en tenant compte du feed-back de
l’utilisateur
 Une nouvelle version est développée en utilisant le modèle en
cascade
 Évolutif
 Plusieurs prototypes sont développés (avec minimum de
fonctionnalités)
 Seul le prototype retenu par l’usager est évolué en un produit final

Modèle prototypage
avantages et inconvénients
 Validation des besoins très tôt dans le processus
 Validation concrète et sûre par les utilisateurs
 Forte implication des utilisateurs
 Bonne compréhension du système par les
développeurs
 Ne convient que pour
 les projets qui peuvent être découpés en sous systèmes
 les applications dans lesquelles l’interface utilisateur est
prépondérante
 Coût pourrait être élevé

10
RUP
 S’applique sur des moyens et grands projets (>10 employés)
 Basé sur le langage UML
 RUP est piloté par les cas d’utilisation
 RUP saisit les besoins fonctionnels à travers les cas d’utilisations
qui ne sont pas un simple outil de spécification des besoins mais
guident tout le processus de développement et en garantissent la
cohérence
 RUP est centré sur l’architecture
 L’architecture permet de réaliser les besoins exprimés par les
utilisateurs à travers les cas d’utilisation qui guident tout le
processus de développement
 RUP est itératif et incrémental
 Les itérations se succèdent dans un ordre logique pour prendre
en compte les cas d’utilisation et traiter en priorité les risques
majeurs et les problèmes imprévus

Classes de méthodes de
conception

11
Les différentes classes de méthodes de
conception
 Approches cartésiennes (première
génération)
 Approches systémiques (deuxième
génération)
 Approches objet (troisième génération)

Les approches cartésiennes

 Approche cartésienne classique:

décomposition d'un problème en sous-
problèmes
 Méthodes d'analyse fonctionnelles
 décomposition d'une fonction en sous-fonctions
jusqu'à atteindre un niveau facile à coder
 Méthodes: méthodes de programmation
structurée, SADT, Jackson, Yourdon

12
Les approches cartésiennes
suite
 Points forts:
 simplicité et bon sens
 adéquation à capturer les besoins des utilisateurs
 capacité à produire des solutions à plusieurs
niveaux d'abstraction
 Points faibles:
 effort sur les fonctions au détriment des données
 règles de décomposition non explicites
 difficile de faire de la réutilisation

Les approches systémiques

 Approche inspirée d'une vision systémique

 SI = structure + comportement
 Modélisation des données et des traitements
 Méthodes: Merise, Information Engineering

13
Les approches systémiques
suite
 Points forts:
 grande cohérence des données
 niveaux d'abstraction bien définis
 niveau conceptuel, niveau logique ,niveau physique
 Points faibles:
 manque de cohérence entre données et
traitements
 faiblesse de la modélisation des traitements,
mélange des contraintes et des contrôles

Les approches objet

 Évolution de l'approche systémique vers une

plus grande cohérence entre les objets et
leurs comportements
 Vision du SI comme un ensemble d'objets
avec leurs opérations
 Méthodes: OMT, OOD, OOSE, Unified
Software
 Development Process (UML)

14
Les approches objet
suite
 Points forts:
 capacité à modéliser des objets complexes
 réduire les distorsions entre système informatique
et monde réel
 intégration des traitements aux données
 encapsulation
 Points faibles
 "tout objet" difficile à appréhender
 aspect fonctionnel mal représenté
 aspect procédural des opérations

Approche cartésienne
vs approche objet
 Approche cartésienne: approche
descendante par décomposition de fonctions
 Approche objet: approche ascendante par
composition d'objets

15
Approche systémique
vs approche objet
 Basées sur les mêmes concepts
 Approche systémique
 Les langages de modélisation pour les données
et les traitements sont incompatibles
 Faut-il commencer par les données ou les
traitements?
 Approche objet
 nouveau paradigme
 Réunir les traitements et les données dans la
même unité, objet

Introduction au langage
UML

16
UML un langage
 C’est un formalisme (notation) pas une méthode
 Il est entièrement tourné vers le support de l’analyse et la
conception orientée objet.
 Il est un langage qui fournit des mots, une syntaxe et une
sémantique à des fins de communication
 UML fournit le vocabulaire et les règles pour représenter
les différents modèles permettant de comprendre un
système.
 Il est la synthèse de plusieurs autres méthodes objet ou
non.
 Il est supporté par des d’acteurs importants du monde
informatique.
 Il est normalisé par l’Object Management Group (OMG)

Chapitre 2 paradigme objet 33

UML
un langage pour visualiser

 UML fournit un ensemble de symboles et des

règles d'assemblage pour représenter
graphiquement les modèles du système.
 La représentation graphique est indépendante
de la langue et permet souvent une meilleure

Chapitre 2 paradigme objet 34

17
UML
un langage pour spécifier

 Un spécification est une description précise,

non ambiguë et complète.
 UML fournit les outils pour construire des
spécifications aux niveaux analyse,
conception et implémentation.

Chapitre 2 paradigme objet 35

UML
un langage pour construire

 UML n'est pas un langage de programmation

visuel, mais les modèles d'implémentation sont
assez riches pour être directement traduits dans
un langage de programmation.

Chapitre 2 paradigme objet 36

18
Genèse d’UML

Chapitre 2 paradigme objet 37

UML et le processus unifié

Chapitre 2 paradigme objet 38

19
Architecture et vues du processus de
développement

Chapitre 2 paradigme objet 39

Modèles et diagrammes du processus de

développement

Chapitre 2 paradigme objet 40

20
Vues architecturales et modèles UML

Chapitre 2 paradigme objet 41

Diagrammes UML 2

 Diagrammes statiques :
 Mettent en évidence des liens structurels entre les
entités qui constituent l’application
 Diagrammes dynamiques :
 Mettent en évidence le comportement des entités
qui constituent cette application

Chapitre 2 paradigme objet 42

21
 Chapitre 2 paradigme objet 43

UML 2.x
 Quelques points majeurs
 Restructuration du méta-modèle

Infrastructure (sémantique) et superstructure

(notation)
 Diagrammes nouveaux ou modifiés

 Profiles plus puissants et simples

 Format pour échanger les diagrammes (entre

outils UML)
 Site principal pour les normes reliées à UML:

http://www.omg.org/uml/
Chapitre 2 paradigme objet 44

22