FormatPowerPoint97

(1)

4 Analyse

 Quoi développer ?

– Spécification indépendante de la technologie

 Cas d'utilisation détaillés

 Modèle conceptuel

– concepts du domaine

d ’application

(2)

4.1 Cas d'utilisation détaillés

AutoriserUtilisateur

Commis au prêt

GérerMembres

ProduireRapportRetards EnregistrerRetours EnregistrerPrêts AutoriserCommis

GérerPrêts

<<inclut>>

Membre

AutoriserMembre

ConsulterCollections

ConsulterPrêts

<<inclut>>

Consulter

<<inclut>>

ProduireStatistiquesPrêts

ProduireStatistiquesCollections ProduireRapportActivités

<<inclut>>

SystèmeAcquisition Bibliothécaire

AutoriserBibliothécaire

<<inclut>>

AjouterCatégorieDocumentaire InclureAcquisitions

<<inclut>>

<<étend>>

(3)

Séquence d ’interaction GérerPrêts

Commis au prêt Système

1. Le commis invoque l'application de gestion des prêts.

2. Le système déclenche le cas AutoriserCommis

3. Si le commis est autorisé à poursuivre, un menu incluant les choix suivants est affiché : EnregistrerPrêt, EnregistrerRetour, ConsulterPrêt, GérerMembres, ProduireRapportRetards ou Quitter

4. Le commis effectue une sélection dans le menu.

5. Le cas choisi est déclenché. Ensuite, retour en 3.

Si le commis choisit de quitter, l'application est interrompue.

Exceptions :

(4)

4.1.1 Paquetages (« Packages »)

PackageCasServicePrêt

PackageCasAdministration

PackageCasAutorisation

(5)

PackageCasServicePrêt

Membre

Commis au prêt

Consulter

ConsulterCollections

<<inclut>>

AutoriserMembre (from PackageCasAutorisation)

<<inclut>>

ConsulterPrêts

<<inclut>>

AutoriserCommis (from PackageCasAutorisation)

EnregistrerPrêts

EnregistrerRetours GérerPrêts

<<inclut>>

(6)

PackageCasAdministration

ProduireStatistiquesCollections

ProduireStatistiquesPrêts ProduireRapportActivités

<<inclut>>

Système Acquisition

AutoriserBibliothécaire (from PackageCasAutorisation)

<<inclut>>

Bibliothécaire

InclureNouvellesAcquisitions

<<inclut>>

GérerSystème

(7)

PackageCasAutorisation

AutoriserBibliothécaire AutoriserCommis AutoriserMembre

AutoriserUtilisateur

(8)

4.2 Modèle conceptuel

 Concepts fondamentaux du domaine d'application visé par le système

 Approche traditionnelle

–

modèle de données

–

modèle de traitement

 Approche objet

–

regroupement données/traitements

–

commencer par données

 Point de départ de la conception BD

–

concepts => données persistantes

(9)

Représentation du modèle conceptuel

 Formalisme entité/association (Chen, 76)

– diverses extensions

 Modèles sémantiques

– graphes conceptuels (Sowa), SDM, ...

 UML

– ~ entité/association++

– diagramme de structure statique

(diagrammes de classes)

(10)

4.3 Modèle conceptuel objet avec les diagrammes de classes UML

Personne nom prénom

Membre téléphoneRésidence

$ nbMaxPrêts = 5

$ duréeMaxPrêts = 7

PrêtEnCours PrêtArchivé

dateRetour

{dateRetour >= datePrêt}

{statut = "prêté" ssi PrêtEn Cours de l'Exemplaire est non vide}

{Le nombre de PrêtEnCours d'un Membre <= nbMaxPrêts}

Employé

{UNIQUE : codeMatricule}

codeMatricule catégorieEmployé

catégorieUtilisateur

Catégorie {UNIQUE: code}

code

descripteur *

enfant

* Auteur

Editeur {UNIQUE: nomEditeur}

nomEditeur ville

Livre {UNIQUE: ISBN}

ISBN titre

annéeParution {annéeParution > 0}

* 1* 1 1..*

1..* 1..*

1..*

1

1..*

1

1..*

Exemplaire {UNIQUE: idExemplaire}

idExemplaire dateAchat statut

1 1..*1..*

1 Prêt datePrêt

1

*

1

* Utilisateur

{UNIQUE :idUtilisateur}

idUtilisateur

motPasse 11 **

{ordonné}

{Il ne peut y avoir plus d'un PrêtEnCours pour un même Exemplaire}

{disjointe, complète}

{chevauchante, complète}

(11)

4.3.1 Notion d'objet et de classe

 Objet (instance d'une classe)

–

significatif pour le domaine d'application

–

caractérisé par



identité



état



comportement

 Attribut (variable membre, variable d'instance)

–

contenant pour une valeur

–

état

(12)

Représentation d ’un objet en UML

u n L i v r e I S B N : S t r i n g = 0 - 2 0 1 - 5 7 1 6 8 - 4

t it r e : S t r in g = T h e U n if ie d M o d e li n g L a n g u a g e U s e r G u i d e a n n é e P a r u t i o n : I n t e g e r = 1 9 9 9

u n A u t r e L i v r e I S B N : S t r in g = 0 - 2 0 1 - 3 0 9 9 8 - X

t i t r e : S t r in g = T h e U n i f i e d M o d e lin g L a n g u a g e R e f e r e n c e M a n u a l a n n é e P a r u t io n : I n t e g e r = 1 9 9 9

u n E d i t e u r

n o m E d i t e u r : S t r i n g = A d d is o n W e s le y v ill e : S t r in g = R e a d in g , M A

u n A u t e u r n o m : S t r i n g = B o o c h p r é n o m : S t r i n g = G r a d y

u n A u t r e A u t e u r n o m : S t r in g = R u m b a u g h p r é n o m : S t r in g = J a m e s

(13)

Classe

 Abstraction

 Caractéristiques communes à un ensemble d'objets

– attributs

– associations

– opérations

(14)

Représentation d ’une classe en UML

L i v r e

I S B N : S t r in g t i t r e : S t r i n g

a n n é e P a r u t io n : I n t e g e r

E d i t e u r

n o m E d i t e u r : S t r in g v il le : S t r in g

A u t e u r

n o m : S t r in g

p r é n o m : S t r i n g

(15)

 Intention (intent) d'une classe

– propriétés communes (attributs, associations et opérations)

 Extension (extent) d'une classe

– ensemble des objets correspondant à la classe

 extension représentée par un objet ?

(16)

Terminologie

 Objet

– instance, occurrence, entité

 Classe à l ’analyse

– abstraction

– pas toujours une classe d ’implémentation

– concept, entité, type (stéréotype UML)

– stéréotype « entité » pour données

persistantes du domaine d ’application

(17)

Identifiant d'objet (OID, object identifier)

 Mécanisme d ’identification

– pas deux objets avec le même OID

 Implicite

– non visible

– réalisation traitée à la conception

 Mécanisme de référence

(18)

Pas besoin d ’identificateur explicite !

 Par opposition au relationnel

: P r ê t

d a t e P r ê t : d a t e = 1 0 / 1 0 / 2 0 0 0

: P r ê t

d a t e P r ê t : d a t e = 1 0 / 1 0 / 2 0 0 0 O I D = 1 5 4 3 9 6 O I D = 2 0 4 3 9 5

(19)

Identifiant naturel (ou clé

«key») pour une classe

 Ensemble d'attributs minimal qui identifie chacun des objets de manière unique

– ~clé candidate du relationnel

 Représentation par une contrainte UML

{ U N I Q U E : i d M e m b r e ,

U N I Q U E : n o m , p r é n o m } id M e m b r e

n o m p r é n o m

M e m b r e

(20)

Syntaxe générale pour la spécification des attributs en UML



[visibilité] nom [multiplicité] [: type] [= valeurInitiale]

[{propriétés}

–

visibilité peut être :



+ publique



# protégé



- privé

–

nom de l'attribut

–

multiplicité ( [1..1] par défaut)



téléphone[1..2]: String



adresse [0..1]: String



auteurs [1..]: String*

(21)

Syntaxe pour attributs (suite)



[visibilité] nom [multiplicité] [: type] [=

valeurInitiale] [{propriétés}]

– type

 OCL

–

Boolean, Integer, Real, String, enum{valeur1,…, valeurn}

 types de la plate-forme visée

 type non pré-défini

–

classe stéréotypée «datatype»

 ~domaine en modélisation conceptuelle

(22)

Syntaxe pour attributs (suite)



[visibilité] nom [multiplicité] [: type] [= valeurInitiale]

[{propriétés}]

– valeurInitiale



à la création de l ’objet

– propriétés



prédéfinies :

–

changeable (par défaut)

–

addOnly

–

frozen – portée



souligner attribut de classe (Rational Rose 98 :$)

(23)

4.3.2 Notion de lien et d'association binaire

u n L i v r e : L i v r e I S B N : S t r in g = 0 - 2 0 1 - 5 7 1 6 8 - 4

t i t r e : S t r in g = T h e U n if ie d M o d e li n g L a n g u a g e U s e r G u i d e a n n é e P a r u t i o n : I n t e g e r = 1 9 9 9

u n A u t r e L i v r e : L i v r e I S B N : S t r in g = 0 - 2 0 1 - 3 0 9 9 8 - X

t i t r e : S t r in g = T h e U n if ie d M o d e li n g L a n g u a g e R e f e r e n c e M a n u a l a n n é e P a r u t i o n : I n t e g e r = 1 9 9 9

u n E d i t e u r : E d i t e u r

n o m E d it e u r : S t r in g = A d d is o n W e s le y v il le : S t r in g = R e a d in g , M A

u n A u t e u r : A u t e u r n o m : S t r in g = B o o c h p r é n o m : S t r in g = G r a d y

u n A u t r e A u t e u r : A u t e u r n o m : S t r in g = R u m b a u g h p r é n o m : S t r in g = J a m e s E d i t e

E d i t e

R é d i g e

R é d ig e

R é d i g e

R é d ig e

L i v r e I S B N : S t r in g t i t r e : S t r i n g

a n n é e P a r u t io n : I n t e g e r E d i t e u r

n o m E d i t e u r : S t r in g v ill e : S t r in g

A u t e u r n o m : S t r i n g p r é n o m : S t r in g 1 . . *

1 E d i t e >

1 . . *

< R é d i g e

Lien

Association

(24)

Rôles et multiplicités

 Nom de rôle

 Exemple avec nom de rôle et d ’association

n u m é r o d a t e h e u r e

P a r t i e

n o m v ill e

E q u ip e r e c e v e u r

v is it e u r

0 . . * 0 . . *

1 1

p a r t i e l o c a le

p a r t i e à l'é t r a n g e r

numéro date heure

Partie

nom ville

Equipe receveur

visiteur

0..*

1 1

< Est receveur pour

< Est visiteur pour partie locale

partie à l'étranger

(25)

Association réflexive

Personne nom

prénom

dateNaissance sexe

* 2

enfant

*

parent

2

(26)

Contraintes pré-définies pour les associations

 Ordonné (ordered)

 Modifiable (changeable)

 InsertionSeulement (addOnly)

 Fixe (frozen)

 Exclusives

– entre deux associations

L i v r e I S B N : S t r i n g t i t r e : S t r in g

a n n é e P a r u t io n : I n t e g e r

A u t e u r n o m : S t r i n g p r é n o m : S t r in g 1 . . *

1 . . *

< R é d i g e

{ o r d o n n é }

(27)

4.3.3 Agrégation

 Cas particulier d ’association

Moteur Châssis Porte Pneu

Auto

0..1 1

0..1

2,4 0..1

4 0..1

1 2,4 0..1 1

0..1

(28)

Composition

TableDesMatières

Chapitre

Bibliographie

Index Livre

1 1

1

1 1

1..*

1

1..*

1

1 1

1

Glossaire 1

0..1 1

0..1 tableDesMatières

chapitres

bibliographie index

glossaire

Livre

tableDesMatières : TableDesMatières chapitres[1..*] : Chapitre

bibliographie : Bibliographie index : Index

glossaire[0..1] : Glossaire

(29)

4.3.4 Associations qualifiées

 Partition des objets associés

Groupe

nb_maximum_inscrits Cours

sigle titre

nb_crédits 0..1

numéro session

1 0..1

1 numéro session

Groupe numéro

session

nb_maximum_inscrits Cours

sigle titre

nb_crédits 1 1 0..* 0..*

Contrainte d ’identification locale

{UNIQUE : Cours, numéro, session}

(30)

4.3.5 Classes associatives

 Données spécifiques à

l ’association _Cours

sigle titre Etudiant

nom

prénom * * * *

NoteObtenue note

session

Incorrect si plusieurs notes

pour un Etudiant et un Cours

(31)

Réification de l ’association

 Plusieurs notes pour un Etudiant et un Cours

Etudiant nom

prénom

NoteObtenue note

session

* 1

Cours sigle titre

*

1 *

1

(32)

Autre solution : classe

associative + agrégation

Cours sigle titre Etudiant

nom

prénom * * * *

NotesObtenues

Note note session

1 * 1

*

(33)

Solution avec classe Groupe

NoteObtenue note

Etudiant nom

prénom

Cours sigle titre Groupe

nb_maximum_inscrits

*

* *

*

numéro session 1

0..1 1

numéro session 0..1

Créer un objet session ?

(34)

4.3.6 Associations n-aires

Athlète nom : String

Epreuve nom : String

JeuxOlympiques année : Integer ville : String

*

* *

unAthlète:Athlète nom : String = Myriam Bédard

uneEpreuve:Epreuve nom : String = Biathlon 7,5 km

unJO:JeuxOlpympiques année : Integer = 1994 ville : String = Lillehamer

Lien ternaire

Association

ternaire

(35)

Exemple de données

a1:Athlète nom : String = Myriam Bédard

e2:Epreuve nom : String = Biathlon 7,5 km

j1:JeuxOlpympiques année : Integer = 1998 ville : String = Nagano

e1:Epreuve nom : String = Patin 5000m

j2:JeuxOlpympiques année : Integer = 2002 ville : String = Salt Lake City

a2:Athlète nom : String = Annie Perreault

(36)

Attention !

 Modèle non équivalent :

JeuxOlpympiques année : Integer ville : String

*

Compétitionne *

* Participe

*

* Est admise

(37)

Explication de la non équivalence

 Myriam Bédard figure au “ Patin 5000m

” à Nagano ?

a 1 : A t h l è t e

n o m : S t r in g = M y r ia m B é d a r d

e 2 : E p r e u v e

n o m : S t r in g = B ia t h l o n 7 , 5 k m

j 1 : J e u x O l p y m p i q u e s a n n é e : I n t e g e r = 1 9 9 8 v ill e : S t r in g = N a g a n o

e 1 : E p r e u v e

n o m : S t r in g = P a t in 5 0 0 0 m

j 2 : J e u x O l p y m p i q u e s a 2 : A t h l è t e

n o m : S t r in g = A n n i e P e r r e a u lt

F ig u r e

F i g u r e

P a r t ic ip e P a r t ic ip e

E s t a d m is e P a r t ic ip e

E s t a d m is e

(38)

Utilisation incorrecte d ’une association ternaire

Livre

ISBN : String titre : String

annéeParution : Integer

Editeur

nomEditeur : String ville : String

Auteur

nom : String prénom : String

*

1 *

(39)

Exemple de multiplicité maximale 1

Politicien nom : String

Parti nom : String

Election année : Integer

*

* 0..1

Politicien nom : String

Parti nom : String

Election 1..*

* CandidatDéputé CandidatDéputé

1

Représente 1..*

(40)

4.3.6.1 Réification d ’une association n-aire

JeuxOlpympiques année : Integer ville : String Figuration

* 1

1

* *

1

Nécessaire si les

associations n-aires ne

sont pas supportées !

(41)

4.3.7 La généralisation/

spécialisation

Personne nom

prénom adresse

téléphoneRésidence

Etudiant codePermanent Employé

codeMatricule téléphoneBureau

Etudiant nom

prénom adresse

téléphoneRésidence codePermanent Employé

nom prénom adresse

téléphoneRésidence codeMatricule

téléphoneBureau

Propriétés communes : classe plus générale

Héritage

(42)

Notation multi-segments

Personne nom

prénom adresse

téléphoneRésidence

Etudiant

codePermanent Employé

codeMatricule

téléphoneBureau

(43)

Utilisation de la délégation

?

Employé codeMatricule téléphoneBureau

Etudiant codePermanent Personne

nom prénom adresse

téléphoneRésidence 1

0..1

1 0..1 0..1 0..1

1 1

(44)

Cas de SyLeRat

Personne nom prénom

$ nbMaxPrêts = 5

dateRetour

Employé

catégorieUtilisateur

code

descripteur *

enfant

* Auteur

nomEditeur ville

ISBN titre

annéeParution {annéeParution > 0}

* 1* 1 1..*

1..* 1..*

1..*

1

1..*

1

1..*

idExemplaire dateAchat statut

1 1..*1..*

1 Prêt datePrêt

1

*

1

* Utilisateur

idUtilisateur

motPasse 11 **

{ordonné}

Discriminant

(45)

4.3.7.1 Redéfinition

Etudiant

{UNIQUE: codePermanent}

codePermanent

Programme {UNIQUE: codeProgramme}

codeProgramme nomProgramme

typeProgramme : enum(Certificat,Baccalauréat,Maîtrise,Doctorat) nbCrédits

* *

Admission dateAdmission

ProgrammeGradué

typeProgramme : enum(Maîtrise,Doctorat) EtudiantGradué

sujetRecherche

*

* *

*

AdmissionGraduée propédeutique

Eviter de changer la sémantique !

(contravariance des opérations, invariance des attributs ?)

(46)

4.3.7.2 Héritage multiple

Personne nom

prénom adresse

Etudiant

codePermanent Employé

{UNIQUE: codeMatricule}

EmployéEtudiant dégrèvement

(47)

4.3.7.3 Contraintes pré-définies pour la généralisation

Personne nom

prénom adresse

téléphoneRésidence

Etudiant

{UNIQUE: codePermanent}

codePermanent Employé

{UNIQUE: codeMatricule}

codeMatricule téléphoneBureau

{complète, chevauchante}

Italique pour nom de classe abstraite

Complète /incomplète

Disjointe/chevauchante

(48)

Notation alternative par une note UML

Personne nom

prénom adresse

téléphoneRésidence

Etudiant

{UNIQUE: codePermanent}

codePermanent Employé

{UNIQUE: codeMatricule}

codeMatricule téléphoneBureau

{chevauchante, complète}

(49)

4.3.7.4 Multi-classification et héritage multiple

Personne nom

prénom adresse

Etudiant

codePermanent Employé

Enseignant Cadre Soutien

catégorieEmployé

EtudiantPremierCycle EtudiantGradué {disjointe, complète}

{disjointe, complète} catégorieEtudiant

(50)

Sous-classes de jointure?

Personne nom

prénom adresse

Etudiant {UNIQUE: codePermanent}

codePermanent Employé

Enseignant département Cadre

mur

Soutien fonction catégorieEmployé

EtudiantPremierCycle EtudiantGradué sujetRecherche {disjointe, complète}

{disjointe, complète} catégorieEtudiant

CadreEtudiantPremierCycle SoutienEtudiantPremierCycle EnseignantEtudiantPremierCycle CadreEtudiantGradué SoutienEtudiantGradué EnseignantEtudiantGradué

(51)

4.3.7.5 Attribut de classe

Membre

téléphoneRésidence

$ nbMaxPrêts = 5

Souligner l ’attribut (UML 1.1)

(52)

4.3.8 Opérations

 Signature d'une opération

–

nom et type des paramètres

Employé codeMatricule : String nom : String prénom : String getCodeMatricule() : String salaire () : Real

Cadre prime : Real setPrime(p : Real) salaire() : Real

Surnuméraire tauxHoraire : Real nbHeures : Real setNbHeures(h : Real) setTauxHoraire(t : Real) salaire() : Real Permanent

salaireAnnuel : Real setSalaireAnnuel(s : Real) salaire() : Real

(53)

Syntaxe générale pour la spécification des opérations en UML



[«stéréotype»][visibilité] nom [(listeParamètres)] [: typeRetour]

[{propriétés}]

–

visibilité peut être :

 + publique

 # protégé

 - privé

–

nom de l ’opération

–

listeParamètres



syntaxe d ’un paramètre



[direction] nomParamètre : typeParamètre [ = valeurDeDéfaut]

–

direction (in, out ou inout)

(54)

Syntaxe pour opérations (suite)



[«stéréotype»][visibilité] nom [(listeParamètres)] [:

typeRetour] [{propriétés}]

– typeRetour

 optionnel

– portée

 souligner opération de classe (Rational Rose 98 : $)

– abstraite

 en italique

(55)

Interface

 Opérations publiques visibles

 Définition d ’une interface de classe

– classe stéréotypée

(56)

Définitions

 Méthode

– une implémentation d'une opération

 Polymorphisme

– même signature d'opération

– méthodes distinctes pour des classes distinctes

 Surcharge (« overloading »)

– même nom avec signatures différentes

(57)

Catégories d ’opérations

 Constructeur

 Modifieur

 Lecteur

 ...

(58)

4.3.9 Spécification de contraintes

 Entre { }

 A proximité de l ’élément concerné

– après spécification d ’un attribut

– avant un ensemble d ’attributs

 Note reliée aux éléments

 Près d ’un trait pointillé

 Près d ’une flèche pointillée

 Syntaxe

– langue naturelle

– OCL (version 1.1 d ’UML)

(59)

4.3.9.1 OCL (Object constraint language)

 Invariants de classe

 Pré et post-conditions sur les opérations

 Conditions de déclenchement (Guards)

 Langage de navigation

 Contraintes sur les opérations

(60)

4.3.9.1.1 Contexte d'une contrainte

 L'année de parution d'un livre est supérieure à 0

Livre

self. annéeParution > 0 l : Livre

l. annéeParution > 0

(61)

4.3.9.1.2 Spécification d'une propriété d'un objet

Livre

self. annéeParution > 0

Cadre

self.salaire() > 50000

opération

(62)

Spécification d ’une propriété (suite)

Utilisateur

self.prêt -> size <= 1000 Catégorie

self.enfant->size < 1000

retourne une collection !

nom de classe (première lettre en

minuscule) pour naviguer association

(63)

4.3.9.1.3 Expression de chemin

Prêt datePrêt : Date

1

**

1

idExemplaire : String dateAchat : Date

statut : enum(prêté, disponible, retiré) 1 1..*

ISBN : String titre : String

annéeParution : TypeDonnéesAge 1 1..*

1 * Catégorie

1 *

Prêt

self.exemplaire.livre.catégorie.descripteur <> 'Référence'

(64)

4.3.9.1.4 Types et expressions OCL

 Opérations pour types de base

– ex: +, -, *, /,… pour Integer

 Opérations pour Collections

– Collection, Set, Bag et Sequence

– -> pour opération de collection

(65)

Exemples d ’opérations de collection

Utilisateur

self.prêt->select(p|p.datePrêt>'1/1/2000')

Membre

self.prêt->forAll(p1, p2 |p1 <> p2 implies p1.exemplaire <> p2.exemplaire)

Employé.allInstances->exists(e|e.catégorieEmployé = bibliothécaire) Livre

(self.ISBN = '0-13-123829-9') implies (self.Auteur->at(2).nom = 'Premerlani')

(66)

4.3.10 Eléments dérivés

Prêt datePrêt Utilisateur

{UNIQUE :idUtilisateur}

idUtilisateur motPasse

/ nbPrêtsEnCours

1 *

PrêtEnCours {nbPrêtsEnCours = nombre de

PrêtEnCours pour un Utilisateur}

Utilisateur

self.nbPrêtsEnCours = self.prêtEnCours -> size

(67)

4.4 Processus d'élaboration du modèle conceptuel

 Modèle conceptuel du domaine

 Modèle conceptuel des données

persistantes (ou modèle conceptuel des données)

– stéréotype « entité »

– valeur étiquetée {persistent}

 Modèle conceptuel de la base de données

– données persistantes dans la BD

(68)

Processus d ’élaboration du modèle conceptuel

 Clé : comprendre le domaine d ’application

 Intrants

– cas d ’utilisation détaillés

– ...

 Un processus simple

– 1. Déterminer les classes et leurs attributs

– 2. Déterminer les associations

– 3. Chercher les généralisations

– 4. Ajouter les types et les contraintes

manquantes

(69)

4.4.1 Identifier les classes et leurs attributs

 Candidats

– groupes nominaux

 Exemple : GérérPrêts

Description: Ce cas d'utilisation est déclenché par le commis au prêt suite

à une requête d'un membre ou d'un employé . Il lui permet d'enregistrer un

prêt ou un retour , de consulter les prêts , de gérer les données d'identification

des membres, i.e. l' identificateur d'utilisateur de sa carte de membre , le mot de

passe du membre , son nom , prénom et le numéro de téléphone de sa résidence . Il

permet aussi de produire un rapport des retards . Lors d'un prêt ou d'un

retour , l' identificateur d'utilisateur et l' identificateur de l'exemplaire peuvent être

saisis en utilisant un lecteur optique ou manuellement.

(70)

4.4.1.1 Identification des concepts

significatifs du domaine d ’application du système

 Non pertinent au domaine

–

cas d ’utilisation

 Pertinent

–

prêt, retour, retard, membre, exemplaire, ...

Description: Ce cas d'utilisation est déclenché par le commis au prêt suite

à une requête d'un membre ou d'un employé . Il lui permet d'enregistrer un

prêt ou un retour , de consulter les prêts , de gérer les données d'identification

des membres, i.e. l' identificateur d'utilisateur de sa carte de membre , le mot de

passe du membre , son nom , prénom et le numéro de téléphone de sa résidence . Il

permet aussi de produire un rapport des retards . Lors d'un prêt ou d'un

retour , l' identificateur d'utilisateur et l' identificateur de l'exemplaire peuvent être

saisis en utilisant un lecteur optique ou manuellement.

(71)

4.4.1.2 Persistance du concept

 Modèle conceptuel des données persistantes

– nécessaires aux traitements

– persistantes

 Acteurs ?

 Documents externes ?

 Unités périphériques ?

(72)

4.4.1.3 Classe ou attribut ?

 Attribut : décision de conception ?

– pas d ’attributs dans les graphes conceptuels !

 Critères pour attributs

– caractéristique propre aux objets de la classe

– pas d ’identité propre

– valeur (immuable)



pas une référence

– type complexe ?

Membre idUtilisateur

motPasse nom

prénom

téléphoneRésidence

(73)

4.4.1.3.1 Application de la théorie de la normalisation

 Classe d ’appartenance d ’un attribut ?

 Table = attributs de classe + OID



(OIDPrêt, idUtilisateur, motPasse, nom, prénom, téléphoneRésidence)

–

idUtilisateur  motPasse, nom, prénom, téléphoneRésidence

–

OIDPrêt  idUtilisateur

–

pas en 3FN

 (OIDPrêt, nom, prénom, téléphoneRésidence)

–

est en 3FN mais...

(74)

4.4.1.3.2 Conversion entre attribut et classe

Membre TéléphoneRésidence

numéro 1

1 1

1

Membre idUtilisateur motPasse nom

prénom

m 1 : M e m b r e

t é lé p h o n e R é s id e n c e : S t r i n g = ( 5 5 5 ) 5 5 5 - 5 5 5 5

m 2 : M e m b r e

t é lé p h o n e R é s id e n c e : S t r i n g = ( 5 5 5 ) 5 5 5 - 5 5 5 5

m 1 : M e m b r e

m 2 : M e m b r e t 2 : T é l é p h o n e R é s i d e n c e

n u m é r o : S t r in g = ( 5 5 5 ) 5 5 5 - 5 5 5 5 t 1 : T é l é p h o n e R é s i d e n c e n u m é r o : S t r in g = ( 5 5 5 ) 5 5 5 - 5 5 5 5

~ composition

(75)

Partage du même téléphone ?

Membre TéléphoneRésidence

numéro

1..* 1 1

1..*

m 1 : M e m b r e

m 2 : M e m b r e

t 1 : T é l é p h o n e R é s i d e n c e n u m é r o : S t r in g = ( 5 5 5 ) 5 5 5 - 5 5 5 5

(76)

4.4.1.3.3 Types de données complexes

Membre adresse : String

Membre

adresse : typeDonnéesAdresse

typeDonnéesAdresse numéroCivique

numéroAppartement nomRue

nomVille nomProvince nomPays codePostal

<<datatype>>

Expliciter la structure ?

~ composition

(77)

Variante

Membre numéroCivique

numéroAppartement nomRue

nomVille nomProvince nomPays Membre

adresse : typeDonnéesAdresse

typeDonnéesAdresse numéroCivique

numéroAppartement nomRue

nomVille nomProvince nomPays codePostal

<<datatype>>

(78)

Partage de la même Adresse

Membre

Adresse numéroCivique

numéroAppartement nomRue

nomVille

nomProvince nomPays codePostal 1

1..*

1..* 1

(79)

Modélisation fine des adresses pour éviter toute redondance ?

Membre

Adresse numéroCivique numéroAppartement

1 1..*

Rue nomRue codePostal 1

1..* 1 1..*

Ville nomVille 1

1..*

Pays nomPays Province

nomProvince

1..* 1 1..* 1

1..* 1 1..* 1 1..* 1

(80)

4.4.1.3.4 Représentation des types de données énumérés

 Type du statut de l ’Exemplaire

– enum(prêté, disponible, retiré)

– classe stéréotypée « datatype »

– classe stéréotypée « extensible

datatype »

(81)

4.4.1.3.5 Attribut de classe

 Partagé par tous les objets

– ~variable globale à la classe

Membre

téléphoneRésidence

$ nbMaxPrêts = 5

$ duréeMaxPrêts = 7

(82)

4.4.1.3.6 Classe pour un seul objet ?

Bibliothèque nom : String = LeRat

téléphone : String = (999)999-9999

...

(83)

4.4.1.4 Première ébauche de modèle pour SyLeRat

$ nbMaxPrêts = 5

Retour Employé

nom prénom codeMatricule catégorieEmployé

Catégorie Auteur

nom prénom

Editeur

Livre ISBN titre

annéeParution

Exemplaire idExemplaire dateAchat statut Prêt

datePrêt Utilisateur

idUtilisateur motPasse nom prénom

Retard

(84)

4.4.1.5 Eviter les concepts dérivables

$ nbMaxPrêts = 5

Retour dateRetour Employé

nom prénom codeMatricule catégorieEmployé

Auteur nom prénom

Livre ISBN titre

annéeParution

Exemplaire idExemplaire dateAchat statut Retard

Utilisateur idUtilisateur motPasse nom prénom

Prêt datePrêt

Pour dériver

durée moyenne

(85)

Clarté conceptuelle et linguistique

 4.4.1.6 SYNONYMIE ET POLYSÉMIE

 4.4.1.7 NOMS REPRÉSENTATIFS

– répertoire des concepts (dictionnaire

de données, glossaire)

(86)

4.4.2 Identification des associations

 Lors d'un prêt ou d'un retour, l'identificateur d'utilisateur et l'identificateur de l'exemplaire peuvent être saisis ...

Utilisateur idUtilisateur motPasse nom

prénom 1

emprunteur Prêt

datePrêt

*

1 *

(87)

Éviter les associations dérivables

Exemplaire idExemplaire dateAchat statut Utilisateur

idUtilisateur motPasse nom

prénom

Prêt datePrêt

1 *

emprunteur

1 * ** 11

Retour dateRetour

1

*

1

* * 1

* 1

0..1 11

0..1

Associations dérivables à éviter

(88)

Employé nom

prénom

Membre

$ nbMaxPrêts = 5

Catégorie code

descripteur 0..1

* parent0..1

enfant

* Auteur

nom prénom

Livre ISBN titre

annéeParution

1

* 1

*

1..* 1..*

Editeur nomEditeur ville

1..*

1

1..*

1

Exemplaire idExemplaire dateAchat statut Utilisateur

Retour dateRetour

Prêt datePrêt

1 *

emprunteur

1 *

*

1

*

1 0..1

1

(89)

4.4.2.1 Classe, association ou classe associative

Prêt datePrêt Utilisateur

Exemplaire idExemplaire dateAchat statut

*

0..1 *

0..1

PrêtEnCours datePrêt

PrêtArchivé datePrêt Utilisateur

prénom

* 1

Exemplaire idExemplaire dateAchat

* 0..1

0..1

*

Utilisateur idUtilisateur motPasse nom prénom

Retour dateRetour

Prêt datePrêt

1 *

emprunteur

1 *

* 0..1

1 0..1

1 *

11

(90)

4.4.2.2 Spécification des qualificateurs

Membre

Adresse numéroCivique numéroAppartement

1 1..*

Rue nomRue codePostal 1

1..* 1 1..*

Ville nomVille 1

1..*

Pays nomPays Province

nomProvince

1..* 1 1..* 1

1..* 1 1..* 1 1..* 1

Membre

Adresse 1 1..*

1 1..*

Rue codePostal numéroCivique

numéroAppartement 1 0..1

1 numéroCivique numéroAppartement 0..1

Ville nomRue

0..1 11

nomRue 0..1

Province 0..1

nomVille

0..1 11

nomVille Pays

nomPays 0..1

nomProvince

0..1 11

nomProvince

(91)

 4.4.2.3 Degré approprié d ’association

 4.4.2.4 Éviter les clés étrangères

Utilisateur idUtilisateur motPasse nom

prénom

Prêt

idUtilisateur

datePrêt

(92)

4.4.3 Identification des généralisations

 Principe de génie logiciel

– isoler chaque chose à sa place

 Mettre en facteur propriétés communes

– attention synonymie/polysémie

– généralisation ou délégation ?

 « est un » ou « fait partie de »

 Méthode systématique: treillis de Galois

(concepts)

(93)

Ajout d ’un lien de généralisation entre classes

Employé codeMatricule catégorieEmployé

Membre

$ nbMaxPrêts = 5

$ duréeMaxPrêts = 7 Utilisateur

prénom catégorieUtilisateur

Utilisateur idUtilisateur motPasse nom

prénom

Employé nom

prénom

Membre

$ nbMaxPrêts = 5

(94)

Découverte d ’une nouvelle classe de généralisation

Auteur

Personne nom

prénom

Utilisateur idUtilisateur motPasse

{non disjointe, complète}

Auteur nom prénom

Utilisateur idUtilisateur motPasse nom

prénom

(95)

Autre exemple

PrêtEnCours datePrêt

PrêtArchivé datePrêt dateRetour Utilisateur

* 1

* 11

*

* 0..1

0..1

*

Utilisateur {UNIQUE :idUtilisateur}

idUtilisateur

motPasse 11 **

Prêt datePrêt

PrêtArchivé dateRetour

PrêtEnCours

*

11

*

idExemplaire

(96)

4.4.4 Types de données des attributs et autres contraintes d'intégrité

Personne nom : String prénom : String

Membre

téléphoneRésidence : String

$ nbMaxPrêts : Integer = 5

$ duréeMaxPrêts : Integer = 7

dateRetour : Date

Employé {UNIQUE : codeMatricule}

codeMatricule : String

catégorieEmployé : enum(bibliothécaire, commis) catégorieUtilisateur

code : String descripteur : String

0..1

* parent 0..1

enfant

* Auteur

nomEditeur : String ville : String

annéeParution : TypeDonnéesAnnée 1 **

1 1..*

1..* 1..*

1..*

1

1..*

1

1..*

statut : enum(prêté, disponible, retiré)

1 1..*1..*

1 Prêt datePrêt : Date

1

*

1

* Utilisateur

idUtilisateur : String

motPasse : String 11 **

{ordonné}

TypeDonnéesAnnée

<<datatype>>

(97)

4.4.5 Conservation de

l'historique des données

 Pour prise de décision (OLAP)

– entrepôt de données

– traitements difficiles à prévoir

 Historique complet ou sommaire ?

 Historique des mises à jour ?

 Plus facile de supprimer des

données que de les retrouver ...

(98)

4.4.6 Modularisation du modèle conceptuel

PackageCLassesPrêts

PackageClassesDescriptionBibliographique PackageHiérarchiePersonne

(99)

PackageHiérarchiePersonne

Personne nom : String prénom : String

Membre

téléphoneRésidence : String

$ nbMaxPrêts : Integer = 5

$ duréeMaxPrêts : Integer = 7 Employé

codeMatricule : String

catégorieEmployé : enum(bibliothécaire, commis) catégorieUtilisateur

Auteur Utilisateur

idUtilisateur : String motPasse : String

(100)

PackageClassesPrêts

dateRetour : Date

statut : enum(prêté, disponible, retiré) Utilisateur

(from PackageHiérarchiePersonne)

Prêt datePrêt : Date

1

*

1

1 * *

1 *

Membre

(101)

PackageClassesDescriptionBibliographique

{ordonné}

TypeDonnéesAnnée

<<datatype>>

code : String

descripteur : String 0..1

* parent

0..1

enfant

* Auteur

Editeur

{UNIQUE: nomEditeur}

nomEditeur : String ville : String

annéeParution : TypeDonnéesAnnée 1 **

1 1..*

1..* 1..*

1..*

1

1..*

1

1..*

Exemplaire

(from PackageCLassesPrêts)

1 1..*

(102)

4.4.7 Métamodélisation

 Méta-donnée (metadata)

– décrit un aspect de la structure d'autres données

 Méta-modèle (metamodel)

– modèle de données des méta-

données

(103)

Exemple : méta-modèle de UML

Element

GeneralizableElement isRoot : Boolean isLeaf : Boolean isAbstract : Boolean

Attribute

initialValue : Expression Method

body : ProcedureExpression Operation

concurrency : CallConcurrencyKind isRoot : Boolean

1 **

+specification 1 ElementOwnership

visibility : VisibilityKind

Namespace

ModelElement name : Name

0..1

*

+namespac 0..1

+ownedElement

*

BehavioralFeature isQuery : Boolean Feature

ownerScope : ScopeKind visibility : VisibilityKind

StructuralFeature multiplicity : Multiplicity

changeability : ChangeableKind targetScope : ScopeKind Classifier

*

1

+feature {ordered} *

+owner 1

1 +typ **

1

Class isActive : Boolean

DataType Interface