Modélisation Des Systèmes D'information: Description
Modélisation Des Systèmes D'information: Description
Modélisation Des Systèmes D'information: Description
Description
• Objectif: Note
▫ Modéliser les
Systèmes Assiduité
d’Information en 20%
utilisant UML
Modélisation des Systèmes d’Information • Déroulement du cours :
Examen Final
40%
Sommaire
• Définir :
▫ La modélisation
▫ Un Système d’information
• Quel intérêt pour la modélisation des Systèmes d’information ?
Modélisation des Systèmes d’Information • Quels sont les méthodes de modélisation des SI ?
Pr. TIKITO • Quels sont les langages de modélisation des SI ?
• Quels sont les diagrammes d’UML (2.5) ?
• Quels sont les outils pour la modélisation avec UML?
• Proposer un exemple de SI : le Projet
Définitions
9 10
11 12
•UML est un langage (de modélisation objet) •Les auteurs d'UML préconisent d'utiliser une
•Représenter graphiquement les besoins des démarche se basant sur 3 principes
utilisateurs : les diagrammes fondamentaux :
•UML ne propose pas de processus (i.e. de ▫Démarche itérative et incrémentale
démarche proposant un enchaînement
d’étapes et d’activités qui mènent à la ▫Guidée par les besoins du client et des
résolution d’un problème posé) utilisateurs
•UML est un langage qui permet de représenter ▫Centrée sur l’architecture du logiciel
des modèles, mais il ne définit pas le processus
d'élaboration des modèles
•UML n’est pas une méthode
15 16
2ème MSIP
19 20
21 22
23
•Acteur
• Relation entre cas d’utilisation
•Les acteurs doivent être en mesure de prendre
• Généralisation
des décisions, mais pas besoin d'être humain
• Inclusion
•«Un acteur peut être une personne, une
( « uses » dans la version UML 1.X)
• Extension
entreprise ou une organisation, un programme
informatique ou un ordinateur système
matériel, des logiciels, ou les deux. »
•Attention: une personne utilisant un système
peut être représentée comme différents
acteurs parce qu’elle joue des rôles différents
(ex: banquier)
Use Case Diagram
2ème MSIP
Diagramme de Classe
• Notion de Classe
• Classe abstraite
• Encapsulation
• Interface
• Relations:
Modélisation des Systèmes d’Information • Association
Pr. TIKITO • Agrégation
• Composition
• Héritage (cf. Polymorphisme)
– Généralisation
Diagramme de Classe – Spécification
• Dépendance
Spécification Concepts de
• les interfaces des
l’orienté objet:
classes plutôt que Conceptuel • Encapsulation:
leurs contenus regrouper les données et les
• manière éventuelle traitements associés.
d'implémenter les
concepts du domaine • Héritage: créer de
et à leurs relations nouvelles classes à partir de
classes déjà existantes afin de
réutiliser leurs attributs et leurs
comportements
Implémentation
• Polymorphisme: le
• contenu et même service, aussi appelé
implémentation de
opération ou méthode, peut
chaque classe
avoir un comportement
différent selon les situations.
Source: UML & Together 2006 tutorial. Hong Qing Yu. 2006
Pr.TIKITO 35 Pr.TIKITO 36
Diagramme de Classe / La Classe Diagramme de Classe / Les attributs
• La notation UML dessine le concept de classe [Visibilité] Nom [Mult] [":" TypeAtt] ["=" Val] [Prop]
sous forme d’un rectangle, le nom de la classe
• La visibilité des attributs est représenté par un des symboles
apparaît dans la partie supérieure. Les suivants:
compartiments suivants sont pour la liste des Private Package Protected Public
attributs et la liste des méthodes. (-) (~) (#) (+)
• Le nom de la classe est généralement écrit au • Mult: : [ nbElt ] ou [ Min .. Max ]
centre et en gras. S’il est en italique c’est qu’il • TypeAtt : type primitif (Entier, Chaîne, ...) ou classe
s’agit d’une classe abstraite , ou bien on ajoute le • Val : valeur initiale à la création de l’objet
• Prop : {gelé}, {variable}, {ajoutUniquement}, ...
mot clé « abstract » • Si l’attribut est souligné : attribut de classe (statique)
• Si l’attribut est précédés de « / » : Attribut dérivé
Pr.TIKITO 37 Pr.TIKITO 38
• Exemple:
La fameuse classe « Voiture »
• La classe Voiture :
o Passager
o Roue
o Puissance
o Couleur
o Stickers
Source: UML 2.0 in a Nutshell By Dan Pilone, Neil Pitman. 2005
Pr.TIKITO 39 Pr.TIKITO 40
Association
Association
• Une association décrit une relation stable entre les
classes.
• Il peut exister plusieurs associations possibles entre deux
classes : rôles multiples
• Les liens entre les objets doivent exister en dehors de
l’exécution d’une méthode.
Source: Conception et
réalisation de bases de
données : De UML à
SQL. Jacques Guyot.
Editions Systèmes et
Information. 2008
Pr.TIKITO 41 Pr.TIKITO 42
Diagramme de Classe / Les relations Diagramme de Classe / Les relations
Association
Association
• La multiplicité:
• La navigabilité: Pour contraindre l’association à n’être
parcourue que dans un sens.
Multiplicité de A Multiplicité de B
Classe A Classe B
Rôle de A Rôle de B
Source: Conception et réalisation de bases de données : De UML à SQL. Jacques Guyot. Editions Systèmes et Information. 2008
Pr.TIKITO 43 Pr.TIKITO 44
Association Association
0..* 1
1..* 0..1
Est employé par Est employé par
Personne Entreprise Personne Entreprise
Employé Employeur Employé Employeur
1..* *
Pr.TIKITO 45 Pr.TIKITO 46
0..1
conjointe Personne conjointe Personne
0..1
conjoint conjoint
Marié à Marié à
Personne
Ami de
Pr.TIKITO 47 Pr.TIKITO 48
Diagramme de Classe / Les relations Diagramme de Classe / Les relations
Classe-Association Classe-Association
• L’association a ses propres attributs et méthodes.
Source: Conception et réalisation de bases de données : De UML à SQL. Jacques Guyot. Editions Systèmes et Information. 2008
Pr.TIKITO 49 Pr.TIKITO 50
Pr.TIKITO 51 Pr.TIKITO 52
Composition
Spécialisation / Généralisation
• « Agrégation Forte » • Notion d’héritage.
• La destruction d’un composite implique la destruction de
ses composants.
• Un composant appartient à au plus une composite
Pr.TIKITO 53 Pr.TIKITO 54
Diagramme de Classe / Les relations Diagramme de Classe / Les relations
Dépendance Dépendance
• Une ou plusieurs méthodes reçoivent un objet d'un type
d'une autre classe.
• Lorsqu’un changement intervient dans la classe cible, la
classe source est affectée.
Source: http://www.uml-diagrams.org/dependency.html
Pr.TIKITO 55 Pr.TIKITO 56
Interface Relations
• Classe sans attribut, dont toutes ses opérations sont
abstraites
Association Aggregation Dependency
• On utilise une relation de type réalisation entre une
interface et une classe qui l'implémente.
Inheritance Composition
Realize
Modélisation du comportement
• Diagramme de cas d’utilisation
• Diagrammes d’interaction
Etude de cas
Conclusion
Pr.TIKITO 59 Pr.TIKITO 60
Diagramme de Classe / Objet Diagramme de Classe
Pr.TIKITO 61 Pr.TIKITO 62
Pr.TIKITO 63 Pr.TIKITO 64
Diagramme de Classe
Pr.TIKITO 71 Pr.TIKITO 72
Diagrammes de Séquence
Pr.TIKITO 75 Pr.TIKITO 76
Pr.TIKITO 77 Pr.TIKITO 78
Diagrammes de Séquence Diagrammes de Séquence
Pr.TIKITO 79 Pr.TIKITO 80
Condition (If)
Message synchrone
Pr.TIKITO 81 Pr.TIKITO 82
Pr.TIKITO 83 Pr.TIKITO 84
Diagrammes de Séquence Diagrammes de Séquence
Boucle Break
Pr.TIKITO 85 Pr.TIKITO 86
Parallélisme Référence
Pr.TIKITO 87 Pr.TIKITO 88
Exercice
• Le déroulement normal d’utilisation d’un distributeur automatique de billets
est le suivant :
• 1. le client introduit sa carte bancaire
• 2. la machine vérifie alors la validité de la carte et demande le code au client
• 3. si le code est correct, elle envoie une demande d’autorisation de
prélèvement au groupement de banques. Ce dernier renvoie le solde autorisé à
prélever.
• 4. le distributeur propose alors plusieurs montants à prélever
• 5. le client saisit le montant à retirer
• 6. après contrôle du montant par rapport au solde autorisé, le distributeur
demande au client s’il désire un ticket
• 7. Après la réponse du client, la carte est éjectée et récupérée par le client
• 8. les billets sont alors délivrés (ainsi que le ticket)
• 9. le client récupère enfin les billets et son ticket
Pr.TIKITO 89 Pr.TIKITO 90
Modélisation des Systèmes d’Information Modélisation des Systèmes d’Information
Pr. TIKITO Pr. TIKITO