MLD

● Modèle Logique des Données (= MOD Modèle

Organisationnel des Données)
– Transcription du MCD adaptée à l'implémentation
ultérieure (niveau physique)
● Règles de transcription:
– 1entité => 1table
– Identifiant => clé primaire
– Association => clé étrangère (1,1) ou nouvelle table
(0,n)
 MCD => MLD

Entité1 1,1 Asso1 0,n Entité2 Entité1(id1,@id2,parametre1)

Parametre1 Entité2(id2)
● id1 ●
● id2

Entité3 0,n Entité3(id3)

Asso2 0,n Entité4
Entité4(id4)
● id3 ● Parametre2 ● id4 Asso2(@id3,@id4,parametre2)
 MCD => MLD

Implanter
1,1 ● date_implantation 0,n

Usine Pays Pays(id_pays)

id_pays Usine(id_usine,@id_pays,date_impla
● id_usine ●
ntation)
Exporter(@id_pays,@id_usine)
0,n Exporter
0,n
 MLT
● Modèle Logique des Traitements (= MOT
Modèle Organisationnel des Traitements)
– Représente le MCT en ajoutant des informations qui
ne sont pas décrites par le MCD (durée, ressources,
lieu, ...)
– Qui? Où? Quand? Comment?
– Se limite à une ou plusieurs opérations suivant
nécessité
 MLT
Acteur
Période ... Acteur interne ... Type
externe

sync
Périodicité
Durée Opération
Type
Responsable ●

Ressources
 MLT
Période Étudiant Secrétariat Type
Décision
d'enregistrer
les diplômes

À la rentrée
20 min Avertir les étudiants
interactif
trait. de texte Toujours

Diplômes
originaux
exigés Enregistrement
des diplômes
à effectuer
 MLT
Période Étudiant Secrétariat Type

Diplômes Enregistrement
originaux des diplômes
reçus à effectuer

ET
semaine de la Enregistrer les diplômes
rentrée, de 9 à ●Contrôle de validité
manuel/interactif
10 ●Saisie des diplômes

10 min
NON valide Valide

Diplômes Enregistrement
originaux des diplômes
rendus effectué
 MPD
● Modèle Physique des Données
– Décrit les tables de données
 MCD => MPD

Entité1 1,1 Asso1 0,n Entité2 Entité1 Entité2

● id1 ● Parametre1 ● id2 ●id1 ● id2
●@id1

●parametre1

Entité3 Entité4
Entité3 0,n Asso2 0,n Entité4 ● id3 ● id4
● id3 ● Parametre2 ● id4
Asso2
●@id3
●@id4
 MCD => MPD

Pays Exporter
Implanter ● id_pays ●@id_usine
1,1 ● date_implantation 0,n ●@id_pays

Usine Pays
● id_usine ● id_pays Usine
●id_usine
●@id_pays
0,n Exporter
0,n
●date_implantation
 MPT
● Modèle Physique des Traitements
– Spécifie les fonctions pour le programmeur
 MPT
Fonction ControlerDiplome(Diplome,Etudiant)
si Diplome.Date – Etudiant.DateNaissance < 18
alors retourner Invalide
sinon si Diplome.Signature = Faux
alors retourner Invalide
sinon retouener Valide
 Démarche de conception
● Ex: Passer d'un ancien système à un nouveau
Système existant Nouveau système

Conceptuel MCD/MCT MCD/MCT

Organisationnel MLD/MLT MLD/MLT

Description physique MPD/MPT

Physique
de l'existant
 Analyse fonctionnelle
1)Cahier des charges
2)Conception =>Donner une
1)Mod. Communication représentation du
système
2)Mod. Traitements
3)Mod. Données
3)Validation => Vérifier cohérence
4)Schéma conceptuel
 Analyse organique
1)Schéma conceptuel ● Objectif: adapter une
solution fonctionnelle
2)Développement à un choix technique

3)Solution informatique
 Approche traditionnelle
● Représentation des ● Logique: prise en
traitements compte des besoins
– Logique utilisateurs
– Physique ● Physique: prise en
● Représentation des compte des
données contraintes
– Logique
– Physique
● Description
– Matériel, interface, ...
 Approche Orientée Objet
● Age de l'invention:
● 1967 Langage de programmation OO: Simula
● 1970 SMALLTALK basé sur Lisp et Simula
● Age de la confusion:
● 1980 langages ++
● Multiplication des méthodes de conception
● Age de la maturité:
● 1990 Object Management Group: standardisation.
● Unification des méthodes OMT (Booch) OOSE
(Jacobson) et Rumbaugh: Unified Modeling Language
(v1.0 en 1997)
 Approche orientée objet
● Définition:
– « Façon d'architecturer une application informatique
en regroupant les données et les traitements sur
ces dernières au sein d'une même entité, les
objets. »
● Objectif:
– Organiser, permettre modifications fondamentales
● Méthode:
– Regrouper données et traitements associés
 AOO: Concepts de base
● Classe/Objet: entité de base regroupant un
ensemble de caractéristiques (données ou
procédures).
● Encapsulation: les détails de l'implémentation
d'un objet sont cachés aux autres objets du
système. Cette action consiste alors à donner
des points d'entrée dans l'objet pour en
connaître son état.
● Modularité: permet de diviser le programme
afin d'en réduire la complexité.
 AOO: Concepts de base
● Héritage: permet de partager des
caractéristiques entre deux objets. Ainsi tous les
objets héritant d'une même super-classe
possèdent tous les mêmes caractéristiques
définies par cette dernière.
● Polymorphisme: permet de donner différentes
implémentations de la même caractéristique.
L'héritage permet justement de donner un
polymorphisme à un objet.
● Module: espace de nommage permettant de
regrouper des éléments de programmation.
 Notions fondamentales:
Classe et objet
● Classe:
– Modèle d'objet
● Objet:
– Instance de Classe
 Définir une Classe
● Attributs et méthodes qui sont communs à tous
les objets
– Même comportements
– Mêmes types d'informations
 Définir un objet
● Donner un nom à un exemplaire de la Classe
– Pour les différencier => Identité de l'instance
● Deux objets différents peuvent avoir le même état
● Retrouver l'objet malgré les modifications éventuellement
subies
 Classe - Attributs
● Les attributs:
– Ensembles des informations qui permettent de
définir l'état d 'un objet.
– Ce sont des variables qui peuvent ou non avoir une
relation avec les autres objets
 Classe - Méthodes
● Les méthodes:
– Permettent de définir le comportement de l'objet.
– Ce sont des actions (ou opérations) qui répondent
aux sollicitations extérieures pour modifier ou
consulter les attributs.
 Méthodes & Attributs: Visibilité
● La visibilité permet de limiter l'accès aux
méthodes et attributs des objets:
– Privée: seul les méthodes de l'objet lui-même
– Protégée: les autres objets de la même classe
– Publique: tous les objets quels que soient leurs
classes
 Méthodes & Attributs: Statique
● Attributs statiques:
– L'attribut est commun à toutes les instances
– Il peut être modifié/consulté par toutes les instances
● Méthodes statiques:
– Capable de gérer uniquement les attributs statiques
de la Classe
– Ne peut accéder à un objet qu'en connaissant son
identifiant
 Objet - Identité
● L'identité:
– Il s'agit d'un identifiant unique permettant de
différencier les objets entre eux
– Permet de retrouver les objets individuellement
sans faire de recherche et même dans le cas où
plusieurs objets ont le même état .
 Comment trouver une Classe?
● Choisir caractéristiques/attributs
● Choisir comportements génériques/fonctions
– Astuce: les méthodes correspondent à des verbes
(lors d'une première approche simple)
● Méthode désagrégation/agrégation
– Décomposer le tout en un ensemble de parties,
chaque partie devenant à son tour un tout
– ≠ décomposition fonctionnelle
AOO: Comment trouver un objet?
● Choisir caractéristiques/attributs
● Choisir comportements génériques/fonctions
● Méthode désagrégation/agrégation
– Décomposer le tout en un ensemble de parties,
chaque partie devenant à son tour un tout
– Décomposition modulaire ≠ décomposition
fonctionnelle
 Quelques règles d'écriture de
module
● Un module représente un concept et TOUT le
concept
● Ne représenter que ce qui existe
● Ne pas créer de module « bazar »
● Bien choisir le nom du module en fonction de ce
qu'il exprime
● Astuce: les méthodes correspondent à des
verbes (lors d'une première approche simple)
 UML - Introduction
● Les méthodes objets
– 1970 à 1990, mise au point des approches OO
– 1994 plus de 50 méthodes objet
● Emergence de 3 méthodes :
– OMT de Rumbaugh (Object Modeling Technique)
– BOOCH'93 de Booch
– OOSE de Jacobson (Object Oriented Software
Engineering)
 UML - Introduction
● Historique:
– 1994 v0.8: Rumbaugh et Booch (OMT et Booch'93)
« Unified method »
– 1995 v0.9: Jacobson (OOSE)
– 1997 v1.1: l'OMG standardise l'Unified Modeling
Language
– Aujourd'hui v2.0: norme ISO
● Consortium, adhésion de grands groupes:
– Rational (fondateurs), Microsoft, HP, Oracle,
Sterling, MCI Systemhouse, Unisys, ICON, i-Logix,
Intellicorp, IBM, ...
 UML
● Caractéristiques
– Langage, méthode de modélisation
– Uniformiser la conception d'une application
– Indépendant de la programmation
– Notation graphique simple et standardisée
● Ensemble de diagrammes décrivant un projet
– Format d'échange: XMI
 Diagrammes
● Statiques:
– Cas d'utilisation (Use Case en anglais)
– Objets
– Classes
– Composants
– Déploiement

– Paquetages
– Structures composites
 Diagrammes(2)
● Dynamiques:
– Collaboration
– Séquence
– Etats-transitions
– Activités

– Communication
– Interaction globale
– Temps
 Première étape
● Déterminer les actions (fonctionnalités) du
système
– Comment va-t-on se servir du système?
– Quelles sont les actions réalisées par le système?
● Diagramme des cas d'utilisation pour décrire
ces comportements et interactions
 Etapes suivantes
● A partir des cas d'utilisation → Autres
diagrammes statiques et dynamiques
– Autres statiques → Structurels
– Dynamiques → Comportementaux
 Cas d'utilisation
● Méthode:
– Définir des scénarii primaires
– Ne pas traiter les exceptions du système
● Exemple:
– Retirer de l'argent dans un distributeur:
● Insérer sa carte de retrait
● Taper son code
● Choisir le montant
● Reprendre sa carte
● Récupérer les billets
 Système
● Produit, projet, application que
l'on veut décrire Nom du système

● Contient les actions disponibles

pour les acteurs
 Acteur
● Toute entité extérieure au
système ayant une action
sur le système
● Un acteur peut être une
personne mais aussi un
autre système
● Une personne peut jouer le
rôle de différents acteurs

Rôle de l'acteur
 UseCase
● Action réalisée par l'acteur
sur le système

Intitulé de l'action
 Relations
● Acteur/UseCase

● Inclusion X
« include »
Y
– X contient le comportement de Y

● Extension « extend »
X Y
– X est un cas précisé de Y
Exemple
Distributeur de billets