Conception des systèmes d’information
Cours 2ème année CS
ISI-Tunis
Elaboré par: Dr Hela LIMAM
Chapitre introductif
Année universitaire 2021/2022– Semestre 1
1
Dans quel cas modéliser et analyser?
Construire
une niche: c’est facile
une maison: c’est un peu plus compliqué
un immeuble: bon là, comment s’y prendre?
Nombreux fabricants de logiciels veulent construire « des
immeubles » mais abordent le problème comme d’ils devaient
bricoler une niche
Nous construisons des modèles pour les systèmes complexes
parce que nous ne sommes pas en mesure d’appréhender de
tels systèmes dans leur intégralité.
Le guide de l’utilisateur UML, Grady Booch, James Rumbaugh et
Ivar Jacobson?Eyrolles, Octobre 20002.
2
Mais pourquoi analyser et modéliser?
Pour éviter les résultats négatifs suivant:
Les modules ne fonctionnent pas ensemble
Le produit est non conforme avec les besoins
Le produit est difficile à maintenir et à faire évoluer
Le produit présente beaucoup d’anomalies et de bugs
Mais aussi pour:
Simplifier la problématique posée par le client
« Visualiser » le système
Spécifier sa structure et son comportement
Aider à sa construction
Travailler en équipe
3
Et c’est quoi un modèle?
Un modèle est une abstraction de la réalité. Il s'agit d'un
processus qui consiste à identifier les caractéristiques
intéressantes d'une entité, en vue d'une utilisation précise.
L'abstraction désigne aussi le résultat de ce processus,
c'est-à-dire l'ensemble des caractéristiques essentielles
d'une entité, retenues par un observateur.
Un modèle est une vue subjective mais pertinente de la
réalité
Un modèle définit une frontière entre la réalité et la
perspective de l'observateur. Ce n'est pas "la réalité", mais
une vue très subjective de la réalité.
Bien qu'un modèle ne représente pas une réalité absolue,
un modèle reflète des aspects importants de la réalité, il
en donne donc une vue juste et pertinente.
Et UML dans tout ça?
UML: langage standard de modélisation des systèmes
d’information
UML: langage visuel pour
comprendre le système
communiquer et travailler à plusieurs
aider à spécifier, concevoir et développer un système
d’information différents modèles et différentes vues
5
Et dans quel cas l’utiliser?
Systèmes à forte composante logicielle
systèmes d’information pour les entreprises
les services bancaires et financiers
les télécommunications
les transports
la défense / l’aérospatiale
le commerce de détail
l’électronique médicale
les services distribués et les applications WEB
Pas limité à un domaine précis
6
UML: un peu d’histoire
Années 80:
Méthodes pour organiser la programmation fonctionnelle
(Merise)
Séparation des données et des traitements
Début des années 90:
Apparition de la programmation objet: nécessite d’une
méthodologie adaptée
Apparition de plus de 50 méthodes entre 1990 et 1995
1994
Consensus sur 3 méthodes
OMT de James Rumbaugh : représentation graphique des
aspects statiques, dynamiques et fonctionnels d’un système
OOD de Grady Booch: concept de package
OOSE de Ivar Jacobson: description des besoins de l’utilisateur
7
Caractéristiques d’UML
UML cadre l'analyse objet, en offrant différentes vues
(perspectives) complémentaires d'un système, qui
guident l'utilisation des concept objets, plusieurs niveaux
d'abstraction, qui permettent de mieux contrôler la
complexité dans l'expression des solutions objets.
UML est un support de communication: Sa notation
graphique permet d'exprimer visuellement une solution
objet.
L'aspect formel de sa notation limite les ambiguïtés et les
incompréhensions.
Son aspect visuel facilite la comparaison et l'évaluation
de solutions.
Son indépendance (par rapport aux langages
d'implémentation, domaine d'application, processus...) en
8
font un langage universel.
Alors UML, c’est la solution à tout?
UML n’est qu’un ensemble de formalismes permettant
d’appréhender un problème et de le modéliser
Un formalisme n’est qu’un outil
Le succès = savoir utiliser les outils
Ce n’est pas un algorithme ou une méthode automatique à
appliquer
UML laisse la liberté de « penser » ☺
IMAGINATION IS MORE IMPORTANT THAN KNOWLEGDE
9
([Link])
Et comment l’utiliser alors?
Avant tout, une bonne démarche qui permet de :
Bien comprendre les demandes et exigences des utilisateurs
finaux
Bien communiquer avec le client
Tenir compte des changements du cahier des charges
Empêcher la découverte tardive de défauts sérieux dans le
projet
Traiter au plus tôt tous les points critiques du projet
Bien maîtriser la complexité
Favoriser la réutilisation
Définir une architecture robuste
Faciliter le travail en équipe
La démarche
UML est un langage qui permet de représenter des
modèles, mais il ne définit pas le processus
d'élaboration des modèles.
Cependant, dans le cadre de la modélisation d'une
application informatique, les auteurs d'UML préconisent
d'utiliser une démarche :
• itérative et incrémentale,
• guidée par les besoins des utilisateurs du
système,
• centrée sur l'architecture logicielle.
11
Briques de base d’UML
Les éléments
Ce sont les abstractions essentielles au modèle.
Les relations
Les relations expriment les liens existants entre les différents
éléments.
Les diagrammes
Un diagramme est une représentation visuelle de l’ensemble des
éléments qui constituent le système
Ils servent à visualiser un système sous différents angles
(utilisateur, administrateur par ex.)
Dans les systèmes complexes, un diagramme ne fournit qu’une
vue partielle du système
L’ensemble des diagrammes réunis permet d’obtenir une vue globale
du système à concevoir
Chaque diagramme va permettre de modéliser ou spécifier une vue
12
(spécificité) du système à concevoir
Diagrammes d’UML 2
Diagrammes structurels / statiques (UML Structure)
diagramme de classes (Class diagram)
diagramme d’objets (Object diagram)
diagramme de composants (Component diagram)
diagramme de déploiement (Deployment diagram)
diagramme de paquetages (Package diagram)
diagramme de structures composites (Composite structure diagram)
13
Diagrammes d’UML 2
Diagrammes comportementaux / dynamiques (UML
Behavior)
diagramme de cas d’utilisation (Use case diagram)
diagramme d’activités (Activity diagram)
diagramme d’états-transitions (State machine diagram)
diagrammes d’interaction (Interaction diagram)
diagramme de séquence (Sequence diagram)
diagramme de communication (Communication diagram)
diagramme global d’interaction (Interaction overview diagram)
diagramme de temps (Timing diagram)
14
Les éléments de modélisation
Les objets: La description
d’une entité du monde
réel ou virtuel
Les classes/ la description
d’un ensemble d’objets
jean : Personne
Les états: une étape de la
vie d’un objet
Les acteurs: utilisateurs
finaux du système 15
Les éléments de modélisation
Les cas d’utilisation: Une
manière dont un acteur
utilise le système
Les nœuds: Un dispositif
matériel
Les paquetages: Une
partition du modèle
Les notes: Un
commentaire, une
explication ou une
annotation 16
FIN
17
