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
