Formalismes et méthodes Objet 1 Méthodologie objet Survol du formalisme UML T. Libourel...

Formalismes et méthodes Objet

Méthodologie objet

Survol du formalisme UML

T. Libourel

libourel@lirmm.fr

Avec la complicité de M Huchard

• De l ’analyse à la réalisationaspects LPOaspects SI / BD

• Introduction - Généralités sur les méthodes objet

• Concepts objet et formalisme UML

• Introduction - Généralités sur les méthodes objet

Introduction

• Évolution des paradigmes de programmation

• Évolution des besoins

• Évolution des technologies

Introduction

• Taille et complexité des systèmes importantes et croissantes

– les besoins et les fonctionnalités augmentent

– la technologie évolue rapidement

– les architectures se diversifient

• Problèmes des spécifications– parfois imprécises, incomplètes, ou incohérentes

– assurer l’interface avec le métier (domaine d’application)

• Évolution des applications– évolution des besoins des utilisateurs

– réorientation de l'application

– évolution de l'environnement technique (matériel et logiciel)

• Problèmes liés à la gestion des équipes– taille croissante des équipes

– spécialisation technique

– spécialisation métier

Introduction

Pourquoi des méthodes ?

• Une nécessité

Entreprise

Outils Informatiques

Introduction

• Démarche reproductible pour obtenir des résultats fiables

• Construire des modèles à partir d'éléments (concepts)

• Possibilité de représenter à partir de formalismes

• Mise en œuvre

Une méthode d’analyse et de conception

– propose une démarche qui distingue les étapes du développement dans le cycle de vie du logiciel (modularité, réduction de la complexité, réutilisabilité éventuelle, abstraction)

– s’appuie sur un formalisme de représentation qui facilite la communication, l’organisation et la vérification

– produit des documents (modèles) qui facilitent les retours sur conception et l’évolution des applications

Introduction

Historique

• Méthodes cartésiennes

Jackson, SADT, Yourdon

• Méthodes systémiques

Merise, Axial, Information Engineering

• Méthodes objet

OOD, HOOD, OMT, OOSE, OOA/OOD, etc.

Concepts généraux

• Conceptualiser

obtenir un énoncé du problème (utilisateurs)

• Analyser

spécifier le problème

• Implémenter

réaliser la solution informatique

• Concevoir

une solution informatique

Concepts généraux

Étapes Résultats

Planification Schéma directeur

Analyse des besoins Modèle des besoins

Spécification formelle ou analyse Modèle conceptuel

Spécification technique ou conception Modèle logique

Implémentation Modèle physique

Intégration et Tests Rapport de cohérence logique

Validation du système Rapport de conformité

Maintenance et évolution Documentation et trace

Concepts généraux

• Cycles de développement

- en cascade

- en V

- en spirale

- tridimensionnel

Analyse

Conception

Implémentation

Maintenance

Modèle de cycle en cascade

• Organisation séquentielle des phases du cycle de vie

• Une phase est structurée en un ensemble d'activités pouvant s'exécuter en parallèle par plusieurs personnes

• Le passage d'une phase à la suivante ne se fait que lorsque les sorties de la première ont été fournies

• Pour :– Organisation simple et directe

• Contre :– Retours sur les phases précédentes difficiles (rupture entre

les phases)– Visualisation et validation tardive

Implémentation

Expressiondes besoins

Validationdes besoins

Validationfonctionnelle

Spécificationfonctionnelle

Conceptiondu système

Tests dusystème

Tests descomposants

Conceptiondes composants

Modèle de cycle en V

• Approche descendante dans les phases précédents l’implémentation : on décompose le système au fur et à mesure qu’on le construit

• Approche ascendante dans les phases suivantes : on recompose le système en testant les parties

• Hiérarchie de tests : les différents tests provoquent un retour d’information directement sur la phase permettant de corriger les erreurs.

• Pour :– Décomposition du système en sous-système

– Hiérarchie de tests et retours facilités

– Vérification ascendante

• Contre :– Validation en fin de cycle (erreurs d’analyse coûteuses)

Conception

Analyse

Spécifications Besoins

Validation

Implémentation

Modèle de cycle en spirale

• Modèle itératif– On passe par toutes les phases du cycle de vie plusieurs fois

• Modèle incrémental– On améliore à chaque passage

• Un passage peut aussi bien permettre d’évaluer un nombre réduit de fonctionnalités ou l’organisation générale du système de façon non détaillée

• Pour :– Réalisation de plusieurs prototypes (versions) avant la

réalisation du système réel (définitif)

– Validation progressive et précoce

– Souplesse dans le choix des prototypes

• Contre :– Mise en œuvre parfois coûteuse

– Possibilité de divergence, nombre de prototypes difficile à déterminer

• Simplicité

• Facilité pour coder et réutiliser

• Modèle plus proche de la réalité

– description plus précise des combinaisons

(données, opérations)

– décomposition basée sur “classification naturelle”

– facile à comprendre et à maintenir

• Stabilité

– de petites évolutions peuvent être prises en compte sans changements massifs

Pourquoi l’approche objet ?Pourquoi l’approche objet ?

• Omniprésence technique de l’Objetdans les langages de programmation, les bases de données, les interfaces graphiques, ... et les méthodes d’analyse et de conception.

• Universalité de l’Objetla notion d’objet, plus proche du monde réel,

est compréhensible par tous et facilite la communication entre tous les intervenants d’un projet.

Pourquoi l’approche objet ?Pourquoi l’approche objet ?

Au début des années 90, une cinquantaine de méthodes objet, liées uniquement par un consensus autour d’idées communes (objets, classes, sous-systèmes, ...)

Recherche d’un langage commun unique utilisable par toute méthode objet

– dans toutes les phases du cycle de vie,

– compatible avec les techniques de réalisation actuelles.

UML (Unified Modeling Language)

OOD (Booch) OMT (Rumbaugh)OOSE (Jacobson)

OOPSLA

Autres

Autres méthodes Booch’91 OMT-1 OOSE Partenaires

Booch’93 OMT-2

OOPSLA’95 Unified Method 0.8Com

UML 0.9 & 0.91Juin 96 puis OOPSLA’96

UML 1.0Soumission à l’OMG - Janvier 97

UML 1.1

UML 1.2

UML 1.3

Standardisation à l’OMG - Novembre 97

Version intermédiaire non publiée

Version béta - fin 99

• Concepts objet et formalisme UML

VueCas d’utilisation

Vue structurelle

Vue Architecture

(déploiement)

Vue dynamique

Points de vue sur le système

Concepts généraux

Vue Implémentation

<------- Logique Physique ------>

Modèle déploiement

Modèle Dynamique

Modèle structurel

Quatre points de vueTypes d'objets et leurs relations

Stimuli des objets et leurs réponses

Modèle implémentation

Concepts généraux

Un modèle est une représentation abstraite d ’une réalité, il fournit une image simplifiée du monde réel.

Il permet :

- de comprendre et visualiser (en réduisant la complexité)

- de communiquer (à partir d ’un « langage » commun à travers un nombre restreint de concepts)

- de valider (contrôle de la cohérence, simuler, tester …)

Concepts généraux

Diagrammes (représentations graphiques de modèle)

de classesd ’instances

d'états

Diagrammes de déploiement

de composants

Diagrammes Diagrammes de collaboration

de séquences

Diagrammes Cas d ’utilisation

Concepts généraux

Analyse Conception Implémentation

Démarche uniforme sur le cycle de vie

Même notation

Concepts généraux

Formalisme UML - Concepts objet

• Modèle d’utilisation

• Modèle structurel

• Modèle dynamique

• Modèle d’implémentation

Modèle d’utilisation

Les « USE CASE »

• Modèles descriptifs du point de vue des utilisateurs

• Scénarios fonctionnels

• Focus la manière d’utiliser le système

On part de l ’analyse des besoins ….

Deux concepts

Acteur

toute entité extérieure au système et interagissant avec celui-ci.

acteurs humains, acteurs « machine » (système extérieur communiquant avec le système étudié)

Use case

toute manière d’utiliser le système

suite d ’événements vue du point de vue de l ’utilisateur

Deux concepts

Acteur

Use case

Acteur (rôle 1)

Acteur (rôle 2)

« communicate »

Acteur (rôle 1)

Acteur (rôle 2)

Les cas d ’utilisation peuvent être liés par des relations

- d’utilisation « include » (on utilise une partie commune)

- de raffinement « extends » (on traite des exceptions)

« include »« extends »

- de généralisation/spécialisation« generalizes »

Délimiter le système

- ce qui est extérieur et qui communique avec le système

- ce qui est interne au système

Définir les fonctionnalités du système du point de vue des utilisateurs

Donner une description cohérente de toutes les vues que l ’on peut avoir du système

Modèle structurel

En UML, le modèle structurel ou statique est décrit à l'aide de deux sortes de diagrammes

– Diagrammes de classes

(description de tout ou d'une partie du système d'une manière abstraite, en termes de classes, de structure et d'associations).

– Diagrammes d'objets

(description d'exemples de configuration de tout ou partie du système, en termes d'objets, de valeurs et de liens).

Modèle structurel

Objets du monde réel

Objets informatiques

État Internecaché

Comportementvisible

Les objets

Modèle structurel

Comportement influe sur l'étatEtat réflète les comportements passés

Etat ---> évolue au cours du temps

Comportement ---> actions et réactions

Identité ----> essence

Sophie

Système

: Professeur

: Discipline

Deux objetsou instances

Modèle structurel

Première abstraction

Une classe peut être vue

- la description en intention d'un groupe d'objets

ayant même structure (même ensemble d'attributs),

ayant même comportement (mêmes opérations),

ayant une sémantique commune.

- la « génitrice » des objets ou instances

- le « conteneur » (extension) de toutes ses instances

Classe

Attributs (propriétés)

Voiture

type : stringmarque : stringcouleur : string

Titine :Voiture

type =205Peugeotrouge

Modèle structurel

Instance

Valeurs d'attributs (État)

« Est-instance-de »

Opérations et méthodes

Voiture

type : stringmarque : stringcouleur : string

repeindre(c: Couleur)déplacer (d : longueur)

Méthodes

Implémentations

Modèle structurel

nom de la classe

attributs

opérations

Modèle structurel

• Un objet est instance d'une (seule) classe :– il se conforme à la description que celle-ci fournit,– il admet une valeur pour chaque attribut déclaré à son attention dans

la classe,– il est possible de lui appliquer toute opération définie à son attention

dans la classe.

• Tout objet admet une identité qui le distingue

pleinement des autres objets :– il peut être nommé et être référencé par un nom (mais son identité ne

se limite pas à ça).

Association / Lien (analogie Classe / Instance)

Pays Ville

nom nom

a-pour-capitale

Association

: Paysnom=France

:Villenom = Paris

a-pour-capitale

Modèle structurel

Association en général binaire (degré = 2) mais ..

Adhérent Exemplaireemprunte

DispositifDeLecture

nom d'association

association binaire association ternaire

Multiplicité et rôles d'une association

Société Personne

nomadresse

nomdate de nais.n°SSadresse

emploie

travaille-pour

employeur employé

travailleur

encadreModèle structurel

* 1..*

Modèle structurel

exactement 1Classe

Classe0..*

Classe1..*

Classe2..4

Classe2,4

au plus 1

aucun, 1 ou plusieurs (défaut)

au moins 1

de 2 à 4

2 ou 4

Multiplicité

Classe

Conseils pour la modélisation d'association

- verbes candidats possibles

- ne pas "dériver vers la conception" (pointeurs ou attributs référentiels)

Modèle structurel

Entreprise Personne

nomadresse

nomdate de nais.adresse

quantité

Possède-des-actions

capital actionnaire

Modèle structurel

Classe association

Ligne de portefeuille

* 1..*

Classe association

Utilisateur Station de travail

nom nom

Autorisation

Autorisé sur

prioritédroits

Répertoire

répertoire de rattachement

Modèle structurel

1..*1..*

Classe association

Modèle structurel

• Une classe d'association permet de modéliser une association par une classe.

• Les liens d'une telle association sont alors des objets instances de cette classe.

• À ce titre, ils admettent une valeur pour tout attribut déclaré dans la classe d'association ; et on peut leur appliquer toute opération définie dans celle-ci.

• En tant que classe, une classe d'association peut à son tour être associée à d'autres classes (voire à elle-même par une association réflexive).

Association qualifiée

Banque Personne

num_client

est_client

Modèle structurel

Dossier_C

1..*1..*

Banque Personnenum_client

est_client

1..* 0..1

Modèle structurel

D ’autres « abstractions »

- associations particulières (composition / agrégation)

- spécialisation / généralisation

Association particulière Tout /partie

Barre titre Fond Barre AscenseurFrontière

IndicateurTitre Bouton Ferm Flèche

Fenêtre

Modèle structurel

Composition

Agrégation

Sémantique Collection/Élément

Département

Forêt

Région

Modèle structurel

Composition / Agrégation

Modèle structurel

Contraintes

- Exclusivité/Partage

- Dépendance/Indépendance

Propagation/Diffusion

Modèle structurel

Généralisation / Spécialisation

Mécanismes d’inférences intellectuelles de caractéristiques

Soit on affine (spécialisation)

Soit on abstrait (généralisation)

Sémantique

Point de vue ensembliste

Point de vue logique

Personne

nom adresse

Étudiant

num_carte adresse

Enseignant

grade adresse enseigner

{disjoint}

Modèle structurel

Pompe Échangeur Réservoir

Pompe Cent. Pompe Imm. Réservoir Press.

Équipement

Type d'équipement

Type de pompe

Type de réservoir

Modèle structurel

Généralisation / Spécialisation multiple

Modèle structurel

Véhicule terrestre Véhicule aquatique

Auto Véhicule amphibie Bateau

Véhicule

Composition/Agrégation ou généralisation ?

Agrégation

- lien entre instances

- un arbre d'agrégation est composé d'objets qui sont parties d'un objet composite

Généralisation

- lien entre classes

Modèle structurel

• Une sous-classe “hérite” de sa super-classe la description des instances :

– les déclarations d'attributs,

– les définitions d'opérations,

– les associations définies sur la super-classe,

– les contraintes (on en parle plus tard).

• Une sous-classe peut redéfinir de façon plus spécialisée une partie ou la totalité de la description « héritée », mais il n'y a pas d'exception à l'héritage.

Classes abstraites

Modèle structurel

• Une classe abstraite est une classe non instanciable, c'est à dire qu'elle n'admet pas d'instances directes.

• Une classe abstraite est une description d'objets destinée à être « héritée » par des classes plus spécialisées.

• Pour être utile, une classe abstraite doit admettre des classes descendantes concrètes.

• La factorisation optimale des propriétés communes à plusieurs classes par généralisation nécessite le plus souvent l'utilisation de classes abstraites.

Opérations abstraites

Modèle structurel

• Une opération abstraite est une opération n'admettant pas d'implémentation : au niveau de la classe dans laquelle est déclarée, on ne peut pas dire comment la réaliser.

• Les opérations abstraites sont particulièrement utiles pour mettre en œuvre le polymorphisme.

• Toute classe concrète sous-classe d'une classe abstraite doit “concrétiser” toutes les opérations abstraites de cette dernière.

Classes abstraites

Modèle structurel

FormeGéométrique

dessiner()déplacer(delta : Vecteur)

centre : Point

régulier : Boolean

PolygonegrandDiam : VecteurpetitDiam : Vecteur

dessiner()

opération abstraite

classe abstraite

classe abstraite (dessiner() est héritée et non concrétisée)

opération concrétisée

classe concrète

Polygone utile que si spécialisée

Ellipse

Interfaces

Modèle structurel

• Une interface est une collection d'opérations utilisée pour spécifier un service offert par une classe.

• Une interface être vue comme une classe sans attributs et dont toutes les opérations sont abstraites.

• Une interface est destinée à être “réalisée” par une classe (celle-ci en hérite toutes les descriptions et concrétise les opérations abstraites).

• Une interface peut en spécialiser une autre, et intervenir dans des associations avec d'autres interfaces et d'autres classes.

Interfaces

Modèle structurel

MenuPopUp

BlocDeChoixsetDefault(o : Option)getChoice() : Option Option

setDefault(o : String)getChoice() : String

setDefault(o : Bouton)getChoice() : Bouton Bouton

String

choix1..*opérations

concrétisées

«interface» interface

opérations abstraites

réalisation

MenuBouton

Interfaces

Modèle structurel

Deux notations pour l'utilisation d'une interface

MenuPopUpsetDefault(o : Option)getChoice() : Option

«interface»

BlocDeChoix

MenuPopUp

ApplicationFenêtrée

«uses»

ApplicationFenêtrée«uses»

BlocDeChoix

interfaceinterfaceclasse utilisatriceclasse utilisatrice

utilisationutilisation

réalise

Les contraintes

Modèle structurel

• Les contraintes sont des prédicats, pouvant porter sur plusieurs éléments du modèle statique, qui doivent être vérifiés à tout instant.

• Les contraintes permettent de rendre compte de détails à un niveau de granularité très fin dans un diagramme de classe. Elles peuvent exprimer des conditions ou des restrictions.

• En UML, les contraintes sont exprimées sous forme textuelle, entre accolades et de préférence en OCL (Object Constraint Language).

• Les contraintes sont héritées.

Les contraintes

Modèle structurel

Exemples de contraintes sur associations

Chemin

Arête

Personne Comité

préside *1

membreDe

**{subset}

{ordered} contrainte sur extrémité

d'association

contrainte entre 2 associations

Les contraintes

Modèle structurel

Exemple de contraintes à différents niveaux

contrainte sur classe

Personnechef

subordonné

diriger

actif : Real {value 0}passif : Real

Société

{ actif = passif }

{ Personne.employeur = Personne.chef.employeur }

employeur

* 1..* 0..10..1

contrainte sur attributcontrainte sur

2 associations

Quelques compléments de notation

Modèle structurel

• Une relation de dépendance peut être exprimée entre deux éléments de notation. Elle est le plus souvent stéréotypée. Il y a plusieurs stéréotypes de dépendance : «uses», «instance of», …

«instance of»

relation de dépendance

stéréotype

• Un stéréotype est un label qui permet d'apporter une précision supplémentaire à un élément de notation (classe, relation, …)

Heuristiques d’élaboration du modèle structurel

• Bien comprendre le problème • Faire simple • Bien choisir les noms • Bien expliciter les associations • Ne pas trop “généraliser” • Relire • Documenter

De nombreuses révisions sont nécessaires !

Modèle structurel

Modèle dynamique

Décrit les interactions entre objets et les changements au cours du temps

- Aspects temporels, comportementaux : Contrôle

- Stimuli des objets et leurs réponses

Événement et État

État d'un objet

valeurs de ses attributs et de ses liens au cours du temps un objet peut changer d'état

Événement

stimuli d'un objet vers un autre objet

Modèle dynamique

• diagrammes de séquences

• diagrammes états-transitions

• diagrammes de collaboration

• diagrammes d'activités (non traités)

l’appelant soulève le combinéla tonalité est déclenchéel’appelant compose le numéro 6la tonalité s’arrêtel’appelant tape le chiffre 7l’appelant tape le chiffre 1l’appelant tape le chiffre 4l’appelant tape le chiffre 8l’appelant tape le chiffre 6l’appelant tape le chiffre 6l’appelant tape le chiffre 2le téléphone appelé commence à sonnerla tonalité de sonnerie commence dans le téléphone appelantl’appelé décrochele téléphone de l’appelé cesse de sonnerla tonalité de sonnerie cesse dans le téléphone appelantles téléphones sont connectésl’appelé raccrocheles téléphones sont déconnectésl’appelant raccroche

Scénarios

Exemple

Modèle dynamique

Diagrammes de séquences

Appelant : Personne :Ligne Téléphonique Appelé : Personne

l’appelant soulève le combiné

la tonalité est déclenchée

la tonalité s’arrête

l’appelant compose le numéro 6

l’appelant compose les numérosle téléphone appelé commence à sonnerl’appelant entend la sonnerie

l’appelé décroche

le téléphone de l’appelé cesse de sonnerla sonnerie cesse

connexion établieconnexion établie

connexion interrompue connexion interrompuel’appelé raccroche

l’appelant raccroche

Modèle dynamique

constructeursdestructeurs

sélecteursmodificateursitérateurs

Types Synchronisation

simple

synchrone

dérobant

minuté

asynchrone

Les messages

Modèle dynamique

La ligne de vie :C1

« create »

Création par le message « create »

Activation de l ’objet qui exécute une opération op

Destruction par un autre objet

« destroy »

Diagrammes de collaboration

Vue globale des événements entre classes

Appelant: Personne

:Lignetéléphonique

Appelé:Personne

Modèle dynamique

1, 3, ..

5, ...

Diagrammes d'États

Représentation graphique état et événement

• Graphe

Nœud ÉtatArc Transition nommées par événement

• Une séquence d'événements = chemin dans le graphe

Modèle dynamique

Événement

• pas de durée

• concurrence d'événements

• classes d'événements - sans attributs

- avec attributs départ vol (compagnie, num_vol, ville) a pour instances AirFrance vol 124 de Paris Alitalia vol 352 de Rome

Modèle dynamique

• abstraction des valeurs d'attributs et de liens d'un objet

• un état a une durée (intervalle de temps entre deux événements)

• spécifie la réponse à un événement

• état et événement sont duaux

un événement sépare deux états un état sépare deux événements

Modèle dynamique

Diagrammes d'États

Tonalité

En numérotation

En connexion

décroche

numérote

recherche réussie

Sonnerie

Connectée

Déconnectée

numéro existant

réponse appelé

raccrocheraccroché

Exempleincomplet

Modèle dynamiqueEtat initial

Diagrammes d'États

Transitions gardées

en création Ouvert Fermé

demande créationfermeture accomplie

En retrait En dépôt

Débiteur

fermeture

retrait (s) dépôt(s)

Créditeur[Solde >0] [Solde >0]

[Solde ≤0] [Solde ≤0]

Modèle dynamique

État 1faire : Activité 1

Événement 1 [Cond1] / Action1 (attrib) État 2

Opération Activité / Action

Modèle dynamique

Action opération instantanée, non interruptible,souvent utilisée pour faire des mises à jour de valeurs,attachée à une transition.

Envoyer un événement est une action

Activitéopération qui prend du temps, interruptible par un événement,perpétuelle ou finie,nécessairement attachée à un état.

Opération elle peut être attachée à une transition ou à un état. elle est exécutée en réponse à l'événement ou à l'état.

Modèle dynamique

Généralisation permet une meilleure structuration des diagrammes

d'étatsUn objet dans un état du diagramme général doitêtre dans un des états du diagramme imbriqué (relation ou entre les états)

Modèle dynamique

Agrégation une classe "agrégat" aura un état défini par l'agrégation des états de ses composants.

Agrégation concurrente (relation et)

Modèle dynamique

Ecomp1 Ecomp2

Heuristiques d’élaboration du modèle dynamique • Utiliser les scénarios pour commencer à construire les diagrammes d'état

• Ne construire un diagramme d'état que pour les classes au comportement temporel significatif

• Contrôler la cohérence

• Utiliser des diagrammes structurés

Modèle dynamique

Modèle d ’implémentation

Les packages

Un package ou sous-système est un regroupement logique de classes, associations, contraintes ..

Un sous-système est généralement défini par les services qu ’il rend

Les liens entre sous-systèmes sont des liens de dépendance

Les « packages » servent à structurer une application Ils sont utilisés dans certains LPO (Java) ce qui assure une bonne « traçabilité » de l ’analyse à l ’implémentation

Modèle d ’implémentation

Les packages

Classes avec fort couplage « sémantique »

Liens de dépendance

• De l ’analyse à la réalisationdu modèle objet ….. à la programmation objet du modèle objet …… aux BD

Du modèle objet ... à la programmationDu modèle objet ... à la programmation

Classes

Attributs, Opérations ------> Champs, Méthodes

Accesseurs L/E

Constructeurs, Destructeurs

Du modèle objet ... à la programmationDu modèle objet ... à la programmationClasses

- adresse : String = 'adresse inconnue'- numeroINSEE[6] : Integer

# changeAdresse(nouvelleAdresse : String)+ cotisationAJour() : Boolean

Adhérent

note (peut contenir un complément de description,

un commentaire, …)

type d'attribut

valeur initiale

type de paramètretype du résultat

de l'opération

privé

protégé

public

adhérent de labibliothèquevaleurs multiples

Du modèle objet ... à la programmationDu modèle objet ... à la programmationClasses

Classes ------> classes abstraites vs classes concrètes

C++ méthodes virtuelles pures

Java Interfaces

Héritage par réalisation

Proposer un service et réagir aux messages

Opérations

Données

MessagesEncapsulation

Encapsulation

Consensuel

privé ... implémentationpublic ... spécification

En pratique

à chaque langage ses particularismes

Smalltalk. attributs privés, méthodes publiques, ...Java. package, protected ...C++. friends, protected, protection sur le lien d’héritage, ...

Quelle philosophie adopter ?

Associations

PERSONNE ADRESSE

nom....

N°RueCPVille

Class PERSONNE{Private : string nom;ADRESSE adr;....}

rien de spécial dans ADRESSE

Attrribut complexe

Associations

PERSONNE COMPTE

nom....

N°Type

1 0..npossède

Class PERSONNE{Private :

string nom;list <COMPTE> comptes;....}

Class COMPTE{Private :

PERSONNE possesseur;....}

Conteneur

Référence

Associations

PERSONNE BIBLIOTHEQUE

nom....

nom0..nadhère->

Class PERSONNE {Private : string nom;....}Class BIBLIOTHEQUE {Private : ....}

Class ADHESION{Private :

PERSONNE adhérent;BIBLIOTHEQUE biblio;DATE dateadhésion;....}

Réification

date adhésiontype adhésion (mensuelle, annuelle)

Héritage

• adéquation des deux relations

• représentation et traitement des conflits

• spécialisation des attributs

• représentation de la surcharge et du masquage

• utilisation de l’héritage à des fins d’implémentation ?

Implémentation de la relation de spécialisation par l’héritage,quelques problèmes ....

Héritage : adéquation des deux relations

Spécialisation multiple

good()eof() ...

FlotEcriture

écrire(blocOctets)...

Flot-Lecture

lire(nbOctets)...

FlotLectureEcriture

Cas de Java : héritage simple pour l’implémentation, multiple pour les interfaces ... côté classes, ...les méthodes de FlotLecture et FlotEcriture doivent être réécrites dans FlotLectureEcriture

Héritage : adéquation des deux relationsinterface Flot

interface FlotEcritureinterface FlotLecture

interface FlotLectureEcritureclasse Flot

classe FlotLecture

classe FlotLectureEcriture

classe FlotEcriture

extendsimplements

Spécialisation/Généralisation .... multiples

Conflit portant sur le nom des propriétés

Il y a clairement deux propriétés

couleur (rouge, vert ...)

Elément de jeu

Pion DéCarte à jouer

couleur (coeur, trèfle, ...)

Spécialisation/Généralisation .... multiples

Conflit portant sur les valeurs d’une propriété

Le mulet n’a qu’une propriété couleur, mais quelle sera sa valeur ?

couleur (rouge, vert ...)

Jument Ane

Héritage : représentation et traitement d’un conflit de nom

Smalltalk JavaC++

Désignation expliciteObjet::CouleurCarteAJouer::Couleur

Donner deux nomsdifférents

pas d’accès possibleà couleur d’objetautre qu’avec “super”(dans les méthodes)

mieux vaut donnerdeux noms différents

Héritage : spécialisation des attributs

Animal

nourriture (végétale, animale, minérale)

Herbivore

nourriture (végétale)

Relation

ensemblesImpliqués > 1

RelationBinaire

ensemblesImpliqués = 2

Aucune représentation, ni en C++, ni en Smalltalk, ni en Java

Seule issue : vérification des contraintes dans les méthodes ...

Héritage : surcharge et masquage

Masquage, (redéfinition)coexistence de méthodes de même nom dans des classes comparables

Fenêtre

FenêtreAvecBord FenêtreAvecTitre

affiche

affiche affiche

Figure

affiche

Surchargecoexistence de méthodes de même nom dans des classes différentes

Héritage : masquage

C++ et Java masquage seulement si les signatures sont strictement identiques,on ne peut pas représenter directement :

Magnitude

<(Magnitude)

<(Time)

heureminiutesecondes

<(Date)

jourmoisannée

Héritage : à chacun sa surcharge

Personne

Princesse

habiller(Vêtement)habiller(Vêtement, Chaussure)

habiller(Vêtement, Bijou)

VêtementChaussureBijou

QuiSePorte

En Java : correctement interprété comme de la surchargeEn C++ : habiller(Vêtement, Bijou) cache les deux autres

Héritage : ... l’utiliser pour des raisons d’implémentation ?

ajoutFin

pushpoptop

A éviter dans tous les cas ...même si les livres en sont pleins ...

Vers la programmation : ... à partir du modèle dynamique (diagrammes de séquence, de collaboration, etc.)

:C2« create »

:C1:C3

Persistance• Classes vs Types

persistants vs éphémères

• Points d’entrée (racine de persistance)

• Regroupements

Du modèle objet ... aux BDDu modèle objet ... aux BD

Adéquation aux BD « objet »

LDD, LMD, L Hôte• LDD, LMD, L Hôte équivalents LPO

• Langage de requête “like” SQL

• Transactions

Adéquation aux BD « objet »

Adéquation aux BD « classiques »

Traduction

comme précédemment

d. structurels --> schémas

d. dynamiques --> requêtes et traitements applicatifs divers

Mais règles de « passage »

Classes

AttributsAjout de l ’identifiant

Schéma relationnel

ADRESSE

N°RueCPVille

Attribut Domaine Non Null

Id_adresse Identifiant OuiN° Entier NonRue String(30) Non…..

Schéma AdresseClé primaireId_adresse

Associations

PERSONNE ADRESSE

nom....

N°RueCPVille

Id_personne Identifiant OuiNom String(35) OuiId_adresse Identifiant Oui

Schéma PersonneClé primaireId_personne

Clé étrangèreId_adresse

Associations

PERSONNE COMPTE

nom....

N°Type

1 0..npossède

Id_personne Identifiant OuiNom String(35) OuiNO Identifiant Oui

Clé étrangèreNO

Associations

PERSONNE BIBLIOTHEQUE

nom....

nom0..nadhère->0..n

date adhésiontype adhésion (mensuelle, annuelle)

Id_personne Identifiant OuiId_bibliothèque Identifiant OuiDate_adhésion Date OuiType_adhésion String(10) Oui

Schéma AdhèreClé primaireId_personneId_bibliothèqueDateType

Spécialisation

PERSONNE

nom....

ETUDIANT

num....

ENSEIGNANT

grade....

Plusieurs choix

- « aplatir vers le haut »

- « aplatir vers le bas »Schémas Etudiant, EnseignantClé primaireId_personne

- conserver les niveaux

Processus de développement

Quatre phases

• Analyse

• Conception système

• Conception objet

• Implémentation

Démarche

Centrer l'effort sur l'analyse Processus itératif plutôt que séquentiel

Objectifs de l'analyse

• Obtenir une description initiale du problème et du système à réaliser (à partir des USE CASE)

• Construire les modèles objet (structurel) et dynamique

• Vérifier et itérer sur les modèles

Conception système

Décrire l'architecture générale du système

• Organiser en sous systèmes

• Grouper les objets en tâches concurrentes

• Décider des communications inter-processus, du stockage des données, de l'implémentation du modèle dynamique

Construire l'architecture générale du système

Un sous-système est un ensemble de composants qui englobe des aspects similaires :- fonctionnalités semblables- même caractéristiques techniques- même emplacement physique

Un sous-système fournit des services aux autres sous-systèmes.

Chaque sous-système doit être le plus autonome possible.

Un sous-système doit pouvoir être conçu indépendamment.

Composants ?

Le système peut être décomposé en couches et/ou en partitions

Gestionnaire base de données

Objets métier

BatchIHMRobustesseSécuritéRapiditéRépartitionMulti-tâches

Conception objet

Transposer les modèles d ’analyseEcriture des algorithmes

Il s ’agit de combiner modèles objet et dynamique…. En tenant compte des choix de la conception système

Formalismes et méthodes Objet 1 Méthodologie objet Survol du formalisme UML T. Libourel...

Documents

Programmation orientée objet - jb.vioix.fr · Présentation de la programmation orientée objet 1. ... C++, ... sans grosses ... Destruction d’objet • Un objet est détruit par

Objet Publicitaire

Objet étudié :

Colloque 3-4-5 novembre 2008 Atelier libourel/ Systèmes d'Informations Environnementales et leur application au bassin méditerranéen

Approche Objet Approche Objet - Cours informatiquepolymorphe.free.fr/cours/programmation/objet/objet.pdf · Approche Objet Programmation par objets Un programme = une société d'entités

1 Le mécanisme des exceptions GLIN505 – L3 – 2011 M. Huchard Qu'est-ce qu'une exception? Comment définir et signaler des exceptions? Comment récupérer

eshcamillevernet.files.wordpress.com · Web viewChapitre 14. Objet et méthodes de la sociologie . La construction de l’objet sociologique . D. istinguer objet social et objet

Objet : Projetdemodificationdeladivision213

Initiationàlaprogrammationorientée-objet aveclelangageJavapicard/cours/1A/java/livretJava.pdf · 1.2. Programmationorientée-objet êtrevucommeuneentitéregroupantunensemblededonnéesetdeméthodes(l’équivalentd’une

OBJET : fresque

Programmation orientée objet dans Java - …€¦ · Programmation orientée objet dans Java 1. Introduction ... en plus de leurs extensions objet. Par exemple, C++ et Pascal Objet

Objet direct / Objet indirect

Analyseformellededonnéesrelationnellespour la …huchard/Documents/Papiers/LMO07-rouane-etal-final.pdf · 150 LMO 2007. 1. Introduction En modélisation conceptuelle, en particulier

objet empreinte

Cours 3- Objet et objet-relationnel Anne Doucet

Programmation Orientée Objet – Java · 2015. 8. 27. · Autres langages orienté objet C++ : très utilis ... Bertrand Estellon (DII – AMU) Programmation Orientée Objet –

Programmation par Objets 1 Module IN504 Animé par : Marianne Huchard Marie-Laure Mugnier Khalil Ben Mohamed huchard/Enseignement/FLIN504

Partie 7: Evolution du Modèle Objet — Programmation orientée objet en C++

Séminaire IG 1 Méthodologie objet et IG ? T. Libourel libourel@lirmm.fr

DESCRIPTIF DES FONCTIONS OBJET POLYGONALpragblog.free.fr/3D/mod/Polygone_Editable.pdfPoly éditable est un objet éditable ayant cinq niveaux sous-objet : , , , et . Son utilisation