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●id1

Entité2●id2

1,1 0,nAsso1●Parametre1

Entité3●id3

Entité4●id4

0,n 0,nAsso2●Parametre2

Entité1(id1,@id2,parametre1)Entité2(id2)

Entité3(id3)Entité4(id4)Asso2(@id3,@id4,parametre2)

MCD => MLD

Usine●id_usine

Pays●id_pays

0,n

0,n Exporter

Implanter●date_implantation1,1

0,n

Pays(id_pays)Usine(id_usine,@id_pays,date_implantation)Exporter(@id_pays,@id_usine)

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é

PériodicitéDuréeResponsableRessources

MLT

Opération ●

sync

PériodeActeurexterne... Acteur interne ...

Type

Type

MLT

Avertir les étudiants

Toujours

Décision d'enregistrer les diplômes

Diplômes originaux

exigés Enregistrementdes diplômes

à effectuer

Période Étudiant Secrétariat Type

À la rentrée20 mintrait. de texte

interactif

MLT

Enregistrer les diplômes●Contrôle de validité●Saisie des diplômes

ET

NON valide Valide

Enregistrementdes diplômes

à effectuer

Diplômesoriginaux

reçus

Enregistrementdes diplômes

effectué

Diplômesoriginaux

rendus

Période Étudiant Secrétariat Type

semaine de la rentrée, de 9 à 1010 min

manuel/interactif

MPD

● Modèle Physique des Données– Décrit les tables de données

MCD => MPD

Entité1●id1

Entité2●id2

1,1 0,nAsso1●Parametre1

Entité3●id3

Entité4●id4

0,n 0,nAsso2●Parametre2

Entité1●id1 ●@id1●parametre1

Entité2●id2

Entité3●id3

Entité4●id4

Asso2●@id3 ●@id4

MCD => MPD

Usine●id_usine

Pays●id_pays

0,n

0,n Exporter

Implanter●date_implantation1,1

0,n

Usine●id_usine●@id_pays ●date_implantation

Pays●id_pays

Exporter●@id_usine●@id_pays

MPT

● Modèle Physique des Traitements– Spécifie les fonctions pour le programmeur

MPTFonction 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

Description physiquede l'existant

Organisationnel

Physique

Conceptuel

Système existant Nouveau système

MLD/MLT

MCD/MCT

MLD/MLT

MCD/MCT

MPD/MPT

Analyse fonctionnelle

1)Cahier des charges2)Conception

1)Mod. Communication2)Mod. Traitements3)Mod. Données

3)Validation4)Schéma conceptuel

=>Donner une représentation du système

=> Vérifier cohérence

Analyse organique

1)Schéma conceptuel

2)Développement

3)Solution informatique

● Objectif: adapter une solution fonctionnelle à un choix technique

Approche traditionnelle

● Représentation des traitements– Logique– Physique

● Représentation des données– Logique– Physique

● Description– Matériel, interface, ...

● Logique: prise en compte des besoins utilisateurs

● Physique: prise en compte des contraintes

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

● Contient les actions disponibles pour les acteurs

Nom du système

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 contient le comportement de Y

● Extension– X est un cas précisé de Y

« include »

« extend »X

X

Y

Y

ExempleDistributeur de billets