ECGE1215 Informatique en économie et gestion

2009 IAG 1

ECGE1215Informatique en économie et gestion

Jean VanderdoncktUniversité catholique de Louvain (UCL)

Institut d’Administration et de Gestion (IAG)Unité de Systèmes d’Information (ISYS)

Laboratoire Belge d’Interaction Homme-Machine (BCHI)Place des Doyens, 1

B-1348 Louvain-la-NeuveBelgium

[email protected]

2009 IAG 2

Table des matières• Chapitre 2. Le modèle objet

2.1 Introduction au modèle du domaine 2.2 Identification des classes

2.2.1 Définition 2.2.2 Règles d’identification des classes et exemples 2.2.3 Recommandations pour l’identification des classes

2.3 Identification des attributs 2.3.1 Définition 2.3.2 Règles d’identification des attributs et exemples 2.3.3 Recommandations pour l’identification des classes

2.4 Identification des services 2.4.1 Définition 2.4.2 Règles d’identification des méthodes et exemples

2.5 Identification des associations 2.5.1 Définition 2.5.2 Règles d’identification des associations et exemples 2.5.3 Catalogue des associations typiques

2.6 Identification des contraintes d’intégrité 2.7 Résumé synoptique du modèle objet

2009 IAG 3

2.1 Introduction au modèle objet• Le modèle objet est un modèle du domaine• Modèle du domaine= diagramme de classe

UML• Histoire

Fin des années 80 : compétition des méthodes d’analyse et de conception OO

Booch : particulièrement adaptée au design et à l’implémentation

OOSE (Jacobson) : expression des besoins OMT-2 (Rumbaugh) : analyse et applications

orientées-données 1994 : Rumbaugh rejoint Booch chez Rational 1995 : Jacobson rejoint Rational 14 novembre 1997 : UML adopté par l’OMG

2009 IAG 4

2.1 Introduction au modèle objet• Qu’est-ce que UML?

« UML est un langage pour visualiser, spécifier, concevoir et documenter les artefacts d’un système à base logicielle »

Langage : lexique (graphique), syntaxe (diagrammes), sémantique

Visualiser : représentation graphique Spécification : précis, complet, non-

ambigu Construction : translation vers des

langages de programmation Documentation : des besoins aux tests

2009 IAG 5

2.1 Introduction au modèle objet• Langage = syntaxe + sémantique• Syntaxe = Règles par lesquelles les

éléments du lexique (e.g., mots) sont assemblées en expressions (e.g., phrases, clauses)

• Sémantique = Règles par lesquelles on donne un sens aux expressions syntaxiques

• UML Notation Guide – définit la syntaxe graphique d'UML

• UML Semantics – définit la sémantique d'UML

2009 IAG 6

2.1 Introduction au modèle objet

• Dans UML, il y a des diagrammes prescriptifs : décrivent

le système tel qu’il doit être ou se comporter à tout moment Classe, StateCharts, Use Cases, Activités,

Composants, Déploiement

des diagrammes descriptifs : illustrent un état ou un comportement possible et typique du système Objet, Séquence, Collaboration

2009 IAG 7

2.1 Introduction au modèle objet• Exemple de

modèle des données

unit Enregistrement; interface uses MickeyServe, MKW; type Client = record of Num_Cli : integer; (* Label=‘Numéro de client’ *) Lastname : string [30]; (* Label=‘Nom du client’ *) Firstname : string [20]; (* Label=‘Prénom du client’ *) Adresse = record of

Street : string [20]; (* Label=‘Rue du client’ *)ZipCode: integer; (* Label=‘Code postal’ *)City : string [20]; (* Label=‘Localité’ *)

end; end; ... procedure Search_cust_id(cust,id,result); (* Menu=‘Customer’ Item=‘Search by ID’*) procedure Seach_cust_by_name(cust,last first,result); (* Menu=‘Customer’ Item=‘Search by lastname, firstname’*)

Pas de lien entre les différentesdonnées autres que la structuration

2009 IAG 8

2.1 Introduction au modèle objet• Le modèle objet est

Un modèle du domaine Un modèle qui définit les objets que

l’utilisateur final peut voir, accéder et manipuler à travers le système avec les relations entre ces objets

Un modèle structurel Une vue d'un système qui met l'accent sur la

structure des objets, avec leurs classificateurs, leurs relations, leurs attributs et leursopérations

Un modèle du domaine est plusqu’un modèle des données

Modèle dudomaine

Modèledonnées

2009 IAG 9

2.1 Introduction au modèle objet

• Pour obtenir un modèle objet, il faudra successivement Identifier les classes avec leurs attributs

et leurs services Relier les classes entre elles au moyen

de relations Identifier les contraintes d’intégrité Spécifier quels sont les agents autorisés

à déclencher les services des classes

2009 IAG 10

2.2 Identification des classes• Comment classer ces objets?

2009 IAG 11


2009 IAG 12


2009 IAG 13

2.2 Identification des classes• Classe

Description d’un ensemble d’objets qui ont même Sémantique Structure

• Nom: p. ex. Voiture• Attribut: p. ex. Plaque d’immatriculation• Service: p. ex. Age de la voiture• Relation: p. ex. Propriétaire• Responsabilités: p. ex. Gestion des immatriculations

Une classe constitue un canevas de sémantique et de structure à partir duquel des objets individuels peuvent être instantiés Classe: Voiture Objets: Ma propre voiture, la voiture du voisin

2009 IAG 14

2.2 Identification des classes• Objet = une abstraction de quelque chose présent dans le

domaine d’intérêt qui doit refléter une capacité du système d’information à maintenir cette information et à interagir avec elle

• Classe = description d’un ou de plusieurs objets de manière uniformisée, avec moyens de gérer les objets de cette classe

• Modèle objet=moyen de décrire les classes en vue de leur implémentation

Objets du domaine d’intérêt

Implémentation 1

Implémentation 2

Implémentation 3

Modèle objet

2009 IAG 15

2.2 Identification des classes• Classe: notation et exemples

• Règles pour identifier des objets et classes Rôles joués dans l’organisation: p. ex. Client de la

banque Choses ou événements à conserver: p. ex. connexion à

un site Web Appareils physiques: p. ex. ordinateur personnel Règles de gestion: p. ex. calcul du taux d’intérêt Sites physiques: p. ex. chantiers versus siège

Personne

-Naissance : Date

-Nom : String

-Prenom : String

+age() : int

Nom de la classe

Attributs de la classe

Services de la classe

Responsabilités de la classe

Relations de laclasse avecd’autres classes

Les personnes enregistrées danscette classe sont les membres dupersonnel de l’organisation

Exprimés defaçonstructurée

Exprimés defaçonlibre

Les compartiments pour les attributs et les méthodes peuvent rester vides en fonction de la perspective de modélisation

Responsabilités de la classe

2009 IAG 16

2.2 Identification des classes• Le modèle objet

Est le modèle le plus fréquent Fournit les fondements nécessaires pour les

liens avec les autres modèles Ne décrit que la partie structurelle, statique 3 perspectives de Fowler

Conceptuelle: le diagramme représente le domaine étudié indépendamment de tout système

Spécification: quelles sont les conditions, l’interface offerte avec l’extérieur

Implémentation: chaque classe est implémentée directement

2009 IAG 17

2.2 Identification des classes• Objet et classe: diagramme d’objet vs de

classe Notation et exemples

triangle: Polygon

center = (0,0)vertices = ((0,0),(4,0),(4,3))borderColor = blackfillColor = white

triangle: Polygon

triangle :Polygon

2009 IAG 18

2.2 Identification des classes• Classe: exemples

Window

display ()

size: Areavisibility: Boolean

hide ()

Window

Window

+default-size: Rectangle#maximum-size: Rectangle

+create ()

+display ()

+size: Area = (100,100)#visibility: Boolean = invisible

+hide ()

-xptr: XWindow*

-attachXWindow(xwin:Xwindow*)

{abstract,author=Joe,status=tested}

2009 IAG 19

2.2 Identification des classes• Rôle de l’utilisateur final

Utilisateur qui interagit avec le SI: p. ex. employé Personne qui n’interagit pas directement avec le SI,

mais à propos de laquelle on tient de l’information à jour: p. ex. fidélité d’un client dans une banque

• Autres rôles Rôles joués par les différents intervenants du SI: DHL

Express: client, centre de routage, points de triage, achemineurs, DHL lui-même

• Comment nommer une classe? Utiliser un nom, un substantif singulier: p. ex. Client Eventuellement qualifié par un adjectif: p. ex. Client

Entreprise, Client particulier Le nom doit décrire une seule catégorie d’objets à la

fois Adhérer au standard terminologique du domaine Eviter le jargon informatique

2009 IAG 20

2.2 Identification des classes• Comment trouver les classes?

Observer les pratiques et comportements Interviewer les intervenants Consigner dans un scénario textuel Vérifier avec les classes préalablement

identifiées En vue de préserver la cohérence En vue de maximiser la réutilisabilité En vue d’optimiser la structuration

Considérer d’autres SI Lire les manuels et règles de gestion Prototyper le système

2009 IAG 21

2.3 Identification des attributs• Attribut

= propriété commune des objets d’une classe = toute donnée d’un objet possédant sa propre valeur

• Tout attribut possède Un nom unique Un type

Constant : ssi la valeur de l’attribut ne change pas depuis sa création

Variable : ssi la valeur de l’attribut peut changer au cours de sa vie Dérivé : ssi la valeur de l’attribut est calculée à partir de valeurs

d’autres attributs de la classe• Dans ce cas, on spécifie une paire <condition, effet> où• La condition consiste en une formule bien formée• L’effet consiste en une formule bien formée exprimant la valeur de l’attribut• Exemples

Condition EffetEXISTE(Location) = FAUX 0

COUNT(Rentals) WHERE (Rentals.Status = “E”)

Condition Effet- 0

Produit.prix x Produit.qté

2009 IAG 22

2.3 Identification des attributs• Tout attribut possède

Un booléen spécifiant si l’attribut est identifiant ou non Identifiant : ssi la valeur de l’attribut est unique pour toute la

classe Non identifiant : ssi la valeur de l’attribut peut exister plusieurs

fois dans la classe Un type de données

Boolean : représente une valeur de vérité (oui/non, vrai/faux, 0/1) Hour : représente une heure Date : représente une date Natural : représente un nombre naturel (N) Integer : représente un entier (Z) Autonumeric : représente un entier attribué par

incrémentation/compostage Real : représente un nombre réel String : représente une chaîne de caractères

2009 IAG 23

2.3 Identification des attributs• Tout attribut possède

Une taille, surtout pour les attributs de type « String » Un booléen indiquant si l’attribut est obligatoire ou facultatif

Obligatoire : ssi l’attribut doit avoir obligatoirement une valeur lors de sa création

Facultatif : ssi l’attribut ne doit pas nécessairement prendre une valeur lors de sa création. Autrement, la valeur peut rester vide

Un booléen indiquant si l’attribut peut accepter une valeur nulle ou non

Valeur nulle permise : ssi l’attribut peut recevoir une valeur vide (<>0) Valeur nulle non permise : ssi l’attribut ne peut pas recevoir une valeur

vide Une valeur par défaut : éventuellement une valeur à

assigner lors de la création de l’objet Peut arriver pour tout type de donnée P. ex. « Célibataire » pour l’état civil au début

• Tout attribut peut également posséder Un alias : nom alternatif utilisé comme référence supplémentaire Un commentaire : petit texte définissant l’attribut Un message d’aide : petit message permettant la saisie de l’attribut

2009 IAG 24

2.3 Identification des attributs• Visibilité des attributs

Public (+): visible et utilisable par toute autre classe (utilisation très limitée)

Protégé (#): visible et utilisable par toute spécialisation de la classe

Privé (-): visible uniquement par la classe elle-même

Dérivé (/): calculé à partir d’autres attributs

Autre (?): inconnu On utilisera la sémantique de java (package)

Non spécifié (): indéterminée

2009 IAG 25

2.3 Identification des attributs• Exemples

Voiture: marque, modèle, cylindrée, année constr. Département: code, adresse, président, secrétaire

académique, secrétaire administratif, …. Cours: code, titre, semestre, jour, heure, nombre

d'heures, auditoire, date début, date fin, …. Professeur: Nom, prénom, titre, téléphone, adresse,

… Etudiant: nom, prénom, téléphone, adresse, date

de naissance, …. Bureau: numéro, bâtiment, téléphone, …

2009 IAG 26

2.3 Identification des attributs• Recommandations d’identification

Questions anthromoporphiques Comment suis-je décrit en général? Comment suis-je décrit dans le domaine

d’intérêt? Comment suis-je décrit vis-à-vis des

responsabilités assignées au SI? Questions de responsabilités

Que dois-je savoir? Quel état dois-je sauvegarder dans le temps?

• Exemple: système de tolérance aux pannes Quels sont les états significatifs?

• Exemple: états d’une fenêtre Windows

2009 IAG 27

2.3 Identification des attributs• Attribut

doit représenter un concept tangible, concret, atomique avec une valeur, un ensemble de valeurs Bons exemples: nom, prénom, adresse Mauvais exemples: esthétique, ce qu’on fait dans la

journée Doit être placé dans la classe qui lui correspond,

qui la décrit au mieux Température associée à un corps humain, pas à un

thermomètre Dans une structure d’héritage, les attributs

partagés par un certain nombre de sous-classes doivent être logés au niveau d’une super-classe Les attributs génériques dans la super-classe Les attributs spécifiques dans la sous-classe

2009 IAG 28

2.3 Identification des attributs• Déclaration d’un attribut

[visibilité] nom [card] [ : type ] [ = valeur-initiale ] [ { props... } ]

• Exemples: age + age : Integer - age : Integer = 0 # age [0..1] : Integer (att. facultatif) # numSecurité : Integer {frozen} # motsClés [*] : String {addOnly}

2009 IAG 29

2.3 Identification des attributs• Identification d’une classe

Identifiant: moyen de désigner de manière univoque n’importe quel objet d’une classe

Aucune paire d’objets d’une même classe ne partage le même identifiant

Attribut simple Noma, NoChassis, Code, Référence

Attributs multiples NoChassis, PlaqueImmatriculation

Attributs groupés Nom+Prénoms+Localité

EtudiantNoma

VoitureNoChassisPlaqueIm

Personne

NomPrénomsLocalité

2009 IAG 30

2.3 Identification des attributs• Identification d’une classe

Notation de l’identifiant Soit souligné dans le dessin Soit précédé de « Id »

EtudiantNoma

VoitureNoChassisPlaqueIm

Personne

NomPrénomsLocalité

Etudiant«Id» Noma: Integer [8]

Voiture«Id» NoChassis: String [14]«Id» PlaqueIm: String [6]

Personne

«Id» Nom: String [30]«Id» Prénoms: String [20]«Id» Localité

2009 IAG 31

2.4 Identification des services• Un service

Exprime un comportement particulier dont une classe peut faire preuve Un serveur web autorise un accès à un site La voiture de X se déplace en avant ou en arrière

Exprime ce qu’une classe peut faire en offrant une série de services à l’extérieur, pour les autres classes

Synonymes: fonction, opération, méthode,… Autorise un changement d’état de tout objet par

appel de méthode• Un état

Est représenté par les valeurs collectives d’un ensemble d’attributs d’une classe d’objets

Tout changement résulte d’une invocation de méthode

2009 IAG 32

2.4 Identification des services• Services simples

Services CRUD C)reate: crée et initialise un nouvel objet R)ead: accède, obtient la valeur d’un

attribut quelconque d’un objet U)pdate: assigne une valeur à un attribut

quelconque d’un objet D)elete: déconnecte, rend à nouveau

disponible un objet Le pattern CRUD

• devrait être toujours présent pour chaque classe,• doit être décliné suivant le nom de la classe:

– KO: Create(), Read()– OK: CreateClient(), ReadClient(), etc.

2009 IAG 33


Services CRUD: notation basée sur les événements New: événement généré lors de la création

• «new» NewClient() ou bien «new» CreateClient()• «new» NouveauClient() ou «new» CréerClient()

Destroy: événement généré lors de la destruction d’un objet d’une classe

• «destroy» DeleteClient(), «destroy» RemoveClient()• «destroy» SupprimerClient()

Evénements propres, en fonction de l’état de l’objet

• «Marié» EnregistrerMariage()• «Divorcé» RetirerMariage()

2009 IAG 34


Services CRUD: notation basée sur les événements Evénements partagés: événement qui affecte

l’état de plusieurs objets en même temps• Client et Véhicule partagent Rent(), Return()

Connect: appelle un service d’un autre objet

Vehicle

«Id» PlateNumber: StringCreationDate: DateMake: StringModel: StringFuel: StringKilometres: RealStatus: StringNotes: String

Client

«Id» ClientId: AutonumericCreationDate: DateGivenName: StringFamilyName: StringAddress: StringRentalCount: NatRentalBalance: RealPendingBalance: Real

«new» NewClient()«destroy» DeleteClient()Edit()Rent()Return()

«new» New()«destroy» Delete()Rent()Return()

2009 IAG 35

2.4 Identification des services• Services complexes

Calculate: calcule un résultat à partir des valeurs des attributs d’un objet

Monitor: surveille l’état d’un système ou appareil extérieur Est approprié pour tous les appareils

d’acquisition et de restitution des données connectés au SI

Est approprié pour tous les systèmes de contrôle Est souvent complété par

• Initialise: initialise le système de surveillance• Terminate: clôture le système de surveillance• Listen: écoute les événements qui y surviennent• Re-initialise: réinitialise le système suite à un

problème

2009 IAG 36

2.4 Identification des services

• 2 stratégies d’identification Introspection: on observe comment les

objets changent au cours du temps Interconnexion: on regarde comment un

objet est connecté à d’autres objets durant sa durée de vie Exemples: messages, scénarios, fenêtre

d’un environnement graphique Windows

2009 IAG 37


• Arguments d’un service Argument en entrée ou en sortie Caractérisé par

un nom unique Un type de données Une taille (surtout pour « String ») Une valeur par défaut Un booléen indiquant l’admission de valeur nulle Un alias Un message d’aide Des commentaires Une précondition: p. ex. Kilometres > 50.000

2009 IAG 38


• Déclaration d’un service [ visibilité] nom [ ( params ) ] [ : type ] [

{ props... } ] params := [ in | out| inout ] nom [ :

type] [ =defaut ] [{ props... } ]

• Exemples: getAge() + getAge() : Integer - updateAge( in date : Date ) : Boolean + getAge() : Integer {isQuery}

2009 IAG 39

2.5 Identification des relations

• Comment relier les classes entre elles?Personnes Voitures

Personne Voiture * = plusieurs0..1 0..*

2009 IAG 40


• Différentes notations possibles Diagramme de classe UML

Schéma entité-association ERA

Schéma orienté-objet OO

Personne Voiture

Personne Voiture

0..1 0..*

Personne Voiture0..n 0..1 Possession

possède estpossédée par

2009 IAG 41


• Notation des relations En principe, une association est

implicitement bidirectionnelle, mais on peut la diriger

Notation sans direction (bidirectionnelle)

Notation avec direction (pour navigation)

Compagnie Personne0..1 0..*

est employée dans emploie

2009 IAG 42


• Multiplicité des relations = [min][..][max] Zéro ou plus (plusieurs)

Un à quarante

Un ou plus

Exactement 5

Personne0..*emploie

Personne1..40emploie

Personne1..*emploie

Personne5emploie

Personne*emploie

ou

2009 IAG 43

2.5 Identification des relations• Multiplicité des relations

0..0: n’a pas de sens 0..1: équivalente à un booléen

0..2: 0, 1 ou 2

0..* ou *: d’aucune à autant qu’on veut

1..1 ou 1: exactement 1, possible mais peu intéressant

Personne Etudiant1 0..1

est une est unNoPers Noma

Famille Enfant1 0..2

appar-tient à

est cons-tituée de

Personne Voiture1 0..*

est pos-sédée par

possèdeNoPers NoChassis

Etudiant Programme1..n 1..1

est suivipar

suitNoPers NoProg

2009 IAG 44

2.5 Identification des relations• Multiplicité des relations

1..2: 1 ou 2

1..*: de 1 à plusieurs

2..4 : 2, 3 ou 4

m..n: cas le plus général où m≤n

Bureau Prise Rés.1 1..2

équipe est équi-pé de

NoBureau Adresse

Professeur Cours1..* 1..*

est donnépar

donneMatricule Code cours

Match Joueur1..* 2..4

jouedans

est jouépar

NoMatch NoJoueur

2009 IAG 45


• 5 types fondamentaux de relations Relation d’agent: pour exprimer les accès Dépendance: pour exprimer une

dépendance fonctionnelle entre deux classes

Généralisation: pour exprimer l’héritage d’une classe à l’autre

Association: pour exprimer les relations proprement dites, au sens large

Aggrégation: pour exprimer le lien tout-partie

2009 IAG 46


• Relation d’agent Une relation d’agent exprime les droits

d’accès aux autres classes d’un modèle

Client

«Id» ClientId: AutonumericCreationDate: DateGivenName: StringFamilyName: StringAddress: StringRentalCount: NatRentalBalance: RealPendingBalance: Real

«new» NewClient()«destroy» DeleteClient()Edit()Rent()Return()

Vehicle

«Id» PlateNumber: StringCreationDate: DateMake: StringModel: StringFuel: StringKilometres: RealStatus: StringNotes: String

«new» New()«destroy» Delete()Rent()Return()

«agent»

2009 IAG 47


• Relation de dépendance Une dépendance exprime qu’une classe

en utilise une autre Tout changement dans une classe

affecte l’autre

2009 IAG 48

2.5 Identification des relations• Relation de généralisation

Se traduit par une relation d’héritage Définit une relation « est-un » entre

classes Une classe peut hériter des attributs

et/ou des méthodes de l’autre classe L’oiseau chante Le pingouin chante et nage Le pingouin est un oiseau

La généralisation implique lapossibilité de substitution

2009 IAG 49

2.5 Identification des relations• Relation de généralisation/spécialisation

Personne = super-classe Client = sous-classe Client est une spécialisation de Personne Personne est une généralisation

de Client La pointe du triangle indique

La direction de la généralisation Personne est le parent de la relation Client est l’enfant de la relation

• Exemple: Tout oiseau possède un bec et chante Tout pingouin a une couleur de robe et nage Tout pingouin est un oiseau L’héritage est une relation de

généralisation/spécialisation

Personne

Client

Oiseau

Pingouin

Longueur de bec

Chante()

Couleur de robeNage()

2009 IAG 50


• Héritage Constitue une hiérarchie de classes

dont les nouvelles classes forment des spécialisations de classes déjà existantes

Permet une meilleure structuration et compréhension des classes

Améliore la réutilisabilité et l’extensibilité

2009 IAG 51


• Héritage simple: une sous-classe hérite d’une et d’une seule super-classe

• Héritage multiple: une sous-classe hérite simultanément de plusieurs super-classes

2009 IAG 52


• Hiérarchie de classes Les classes, organisées en hiérarchie

suivant la relation d’héritage entre elles, définissent un arbre d’héritage

2009 IAG 53


• Classes abstraites

2009 IAG 54


• Relation « Tout-partie » (whole-part) Une classe et les objets qui la

composent sont composés est constituée par d’autres classes avec leurs objets Permet la représentation d’hiérarchie de

composition Exemple: une voiture est composée d’un

moteur, d’un chassis, de sièges, de roues, …

2009 IAG 55


• Relation « Tout-partie » (whole-part)

2009 IAG 56


• Relation de composition « est partie de » (is part of) Les classes et les objets qui en sont

instantiés peuvent être imbriqués dans d’autres classes

Exemple: Le corps humain est constitué de deux

poumons La classe « Poumon » est partie de la classe

« Corps humain » avec 2 instances Toute instance de corps humain a donc 2

instances de poumons

2009 IAG 57


• Exemples de relation « Tout-partie »

Tout

Partie

Tout

Partie

1

* *

0

Composition Aggrégation

2009 IAG 58


• Exemples de relation « Tout-partie » Assemblage de pièces

Un avion est composé de pièces, dont les moteurs, les ailes, les ailerons, la dérive

Contenant et contenu Un pilote est assis à l’intérieur d’un avion en

vol

Collection de membres Une escadrille est composée

d’un certain nombre d’avions Une force aérienne est

composée d’escadrilles

2009 IAG 59


• Exemples de relation « Tout-partie »

2009 IAG 60

2.5 Identification des relations• Exemples de relation « Tout-partie »

Considérer chaque objet comme un tout Pour chaque composant potentiel, se poser

la question• Appartient-il au domaine d’intérêt?• Convient-il aux responsabilité du SI?• Capture-t-il juste une valeur ou bien est-il un

concept véritable?– Si valeur, insérer un attribut– Si concept, insérer une classe

• L’abstraction est-elle utile? Considérer aussi chaque objet comme une

partie Exemple: produits simples et composés

2009 IAG 61


• Rôle d’une association est de temporalité Statique : ssi l’objet reste constant une fois l’association

établie.Exemple : Personne <-> Compte, Véhiculle <-> TypeVéhicule

Dynamique : ssi l’objet à l’extrémité de l’association peut changer au cours du temps. Exemple: Professeur <-> Cours

• Classe d’association Pour qualifier la nature d’une

association

Employé Projet1..* 1..*

est réalisépar

réaliseNoEmployé NoProjet

Réalisation

ContratRéfContrat

2009 IAG 62

2.6 Contraintes d’intégrité• Une contrainte d’intégrité exprime une

condition logique qui doit être satisfaite pour état valide d’un objet d’une classe

• 2 types Statique : formule bien formée satisfaite relative

à un état pour toute la durée de vie Exemple : NbreKm > 0 AND NbreKm <= 300000

Dynamique : formule bien formée impliquant plusieurs états et incluant des opérateurs temporels Exemple : TOUJOURS (SoldeCompte < 1800) DEPUIS

(PARFOIS SoldeCompte > 1800)

2009 IAG 63

2.6 Contraintes d’intégrité

• Autres exemples SoldeCompte >= 0 SI CompteType =

‘Epargne’ SoldeCompte >= -1500 SI CompteType

= ‘Compte à vue’ TransactionEtat = ‘Ok’ SI

TransactionMontant >= SoldeCompte DESQUE SoldeCompte <= -1500, ALORS

TOUJOURS (SoldeCompte >= -1000)

2009 IAG 64

2.7 Résumé synoptique• Validité d’un diagramme de classe

Complétude: toute l’information relative au domaine d’intérêt est-elle présente?

Cohérence: toute l’information présente est-elle représentée de manière compatible avec la réalité et avec le reste du diagramme?

7 péchés de spécification de Meyer Bruit Silence Contradiction Surspecification Ambiguité Redondance Incohérence

2009 IAG 65

2.7 Résumé synoptiqueNomDeClasse

AttributIdentifiant+AttributPublic#AttributProtégé-AttributPrivé/AttributDérivéAttributAvecVisibilitéNonSpécifiée?AttributAvecVisibilitéInconnueAttribut1: typeAttribut2: type=valeur initialeAttribut3Constant: int = 5 {gelé}Attribut4: list of types

+ServicePublic()#ServiceProtégé()-ServicePrivée()~ServiceDansPackage()ServiceFonction: intService1AvecPar(in par1:string, inout par:int)Service2AvecPar(par1:string, par2:float)Service3AvecPar(par1, par2)Service4AvecPar(string, int)ServiceFonctionAvecPar (par1:string) : intServiceFonctionAvecParNonSpéc (…) : intServiceNonSpécifié ()

Description textuelledes responsabilitésde la classe adjointeà la définition de laclasse

Le cas échéant:Create()Read()Update()Delete()

2009 IAG 66

2.7 Résumé synoptique

Aggrégation (composition)

Type of (Généralisation/spécialisation)

Association avec cardinalité

2009 IAG 67

Modèle

objet

Modèledynamiqu

e

Modèlefonctionnel

Modèlede la

présentation

Documents

ECGE1215 Informatique en économie et gestion