Traduction du CdC
CPINFO’11 Nicolas Méger
Un petit conseil en passant…
Prenez des notes, tout n’est pas écrit contrairement à cette même remarque!
Remerciements
Jacques Kouloumdjian , professeur à l’INSA Lyon, André Flory, professeur à l’INSA Lyon, Pierre Delisle, Université du Québec à Chicoutimi, Claudine Toffolon, maître de conférences à l’Université du Littoral, Alain Vailly, maître de conférences à l’Université de Nantes, Bernard Morand, maître de conférences en Informatique à l’Institut Universitaire de Technologie de Caen, Lymberis Dimitrios, ETML (École Technique École des Métiers de Lausanne), Frédéric Paquet, Université du Quebec, Michel Lemoine, Office National d’études et de Recherches Aérospatiales (ONRA), Mathieu Seillier, Thales Security Systems, Roberta M. Roth, University of Northern Iowa, Giovanna Di Marzo Serugendo, Université de Genève, Laurent Audibert, maître de conférences à l’IUT de Villetaneuse.
0. Introduction
Traduire un CdC, c’est …
Définir les informations manipulées : MCD, MLD, MPD. Définir les traitements effectués sur ces informations : cas d’utilisation, diagrammes de séquences, diagrammes d’états-transitions. Et les écrans, à quoi servent-ils ?
Définition (rapide) des différents modèles utilisés.
MCD : carte des informations, MLD : tables relationnelles implémentées dans le SGBD, MPD : script de création de la base (indexs, uniques, gestion des contraintes d’intégrité). Use case : carte des fonctionnalités, Diagramme de séquence : détail d’une fonctionnalité à travers la modélisation du dialogue entre l’utilisateur et les différents « éléments » de l’application, Diagramme de classes : carte des différents « éléments » de l’application. Diagramme d’état-transitions : pour un type d’information jugé crucial, représentation de ses différents états possibles et des transitions entre ces états.
Attention, chaque projet est particulier …. CdC spécification logicielle
CdC & Cas d’utilisation
MCD D. séquence Ecrans D. classes MLD Cinématique des écrans D. états-transitions MPD
OBLIGATOIRE TRES RECOMMANDE RECOMMANDE Objectif du cours
Savoir modéliser les données à l’aide d’un MCD et d’un MLD. Savoir modéliser les traitements à l’aide de certains diagrammes UML.
Plan du cours
1 – Le MCD 2 – Normalisation du MCD 3 – Le MLD relationnel 4 – Passage du MCD au MLD 5 – Normalisation du MLD 6 – Le MPD 7 – Le modèle objet 8 – UML 9 – Les diagrammes de cas d’utilisation 10 – Les diagrammes de séquences 11 – Les diagrammes de classes 12 – Les diagrammes d’état-transition 13 – Le MVC
1. Le MCD
MCD: objectifs du modèle
Le MCD décrit les données gérées, sans tenir compte des choix d’organisation ou techniques, en précisant leurs structures et leurs liens. Le MCD fournit une image invariante du SI en termes de données => dimension statique du SI.
MCDMCD :: modèlemodèle entitéentité relationrelation
• Modèle très utilisé en France, depuis près de 30 années, sous des noms divers : • Entité association propriété • Entité association • Entité relation • Modèle qui permet une structuration des informations à conserver dans le SI et qui préfigure la structure de la base de données ou d’une partie de la base de données. • Reconnu internationalement : norme ISO TC97 SC5 WG3 1982
L’entité est un type
Une entité, c’est un modèle, un type (on parle, de temps en temps, de type d’entité ou d’entité-type).
TIMBRE
année-émission pays-émetteur état
L’entité TIMBRE correspond à un ensemble de timbres.
L’entité correspond à un ensemble
année-émission pays-émetteur état TIMBRE 1990 Finlande ** année-émission 1990 Finlande ** pays-émetteur 1992 Finlande * état 1993 Finlande o 1993 Finlande **
Ne pas confondre un timbre (ie. une ligne du tableau) et le type timbre (ie. l’entête du tableau).
EntitéEntité :: représentationreprésentation graphiquegraphique
Nom de l’entité Propriétés de l’entité
TIMBRE CLIENT CATALOGUE nom-client nom-catalogue année-émission prénom-client éditeur pays-émetteur état
Occurrence d’une entité
On appelle occurrence une ligne du tableau. Une occurrence de l’entité CATALOGUE correspond à un catalogue précis.
CATALOGUE nom-catalogue éditeur année-parution nom-catalogue Michel Schwaneberger Verlag GmbH 1995 éditeur Scott Scott Publishing Co. 1995 année-parution Stanley Stanley Gibbons Limited 1997 Yvert Editions Yvert et Tellier 2003
Occurrence = instance, exemplaire.
Occurrences d’un entité
TIMBRE CLIENT CATALOGUE nom-client nom-catalogue année-émission prénom-client éditeur pays-émetteur année-parution état
Il peut y avoir, cachés, empilés, cinq catalogues, mille clients et cent mille timbres dans ce schéma !
Une entité : ensemble d’occurrences
Une entité, c’est un ensemble d’occurrences.
Un ensemble (au sens Toutes les lignes sont mathématique du différentes... terme), donc pas de doublons ! année-émission pays-émetteur état
1990 Finlande ** 1990 Finlande ** …ce qui veut dire que, 1992 Finlande * dans ce magasin, il n’y a 1993 Finlande o 1993 Finlande ** qu’un seul exemplaire de chaque timbre à vendre !!
EtEt pourpour lesles doublons?doublons?
il faut trouver un moyen de rendre unique des doublons.
année-émission pays-émetteur état
1847 Trinitad ** 1847 Trinitad **
Ce timbre, appelé Lady Mc Leod, est un des fleurons de la philatélie mondiale. - Trinitad - 1847 Ajout d’une propriété discriminante : l’identifiant n° 1
numéro année-émission pays-émetteur état
1 1847 Trinitad ** 2 1847 Trinitad ** n° 2
Ce ne sont plus les mêmes ! Numéro est appelé identifiant.
Ce timbre, appelé Lady Mc Leod, est un des fleurons de la philatélie mondiale. - Trinitad - 1847 Numéro absolu ou relatif
1 A1 B1 C1 1 A1 B1 C1 2 A1 B1 C1 2 A1 B1 C1 3 A2 B2 C2 1 A2 B2 C2 4 A1 B1 C1 3 A1 B1 C1 5 A3 B1 C1 1 A3 B1 C1 6 A4 B2 C2 1 A4 B2 C2
L’élément n° 3 L’élément n° 3 (A2, (A2, B2, C2) est le B2, C2) est le premier troisième de la de la table dans cette table. série.
Identifiant relatif à Identifiant absolu (A2, B2, C2)
PlusieursPlusieurs identifiantsidentifiants possiblespossibles
Pour une même entité, il y a souvent une ou plusieurs propriétés qui peuvent jouer ce rôle.
CATALOGUE 2 identifiants possibles, nom-catalogue nom-catalogue tous deux mono- éditeur éditeur année-parution année-parution propriétés.
CLIENT nom-client 1 identifiant, composé prénom-client de 2 propriétés. adresse
Représentation graphique de l’identifiant
Une fois choisi, l’identifiant sera mis en évidence sur les schémas grâce au soulignement :
CATALOGUE CLIENT nom-catalogue nom-client éditeur prénom-client année-parution adresse
Les identifiants relatifs seront, quant à eux, soulignés par des pointillés.
Note : parmi les différents ensembles de propriétés pouvant servir d’identifiant pour une entité, on choisira l’ensemble qui contient le moins de propriétés Et les propriétés restantes ?
Un catalogue CATALOGUE comprend plusieurs x x x x numéros de x timbres. NUMERO-TIMBRE
x x Un même numéro de x x TIMBRE x timbre correspond à x x x x x x plusieurs catalogues
Un timbre a Un même numéro de timbre plusieurs peut correspondre à plusieurs numéros. timbres (un par catalogue)
Ce numéro de timbre a donc du sens pour le couple (TIMBRE, CATALOGUE). L’association
Une association A entre deux entités E1 et E2 est un ensemble de couples (x, y), x occurrence de E1, y occurrence de E2, décrits par des informations, des propriétés, qui n’ont de sens que pour ces couples.
E1 A E2
Association A = ensemble = sous-ensemble d’un produit cartésien E1 x E2
Exemple d’association
CATALOGUE TIMBRE nom-catalogue numéro-ordre éditeur EST-REFERENCE-DANS année-émission année-parution pays-émetteur numéro-timbre état catégorie
Numéro-ordre Nom-catalogue Numéro-timbre catégorie 4578 Michel 10 bâtiment 4578 Scott 1518 bâtiment 4579 Michel 120 Moyens de transports
Couples (TIMBRE, CATALOGUE) Informations sur les couples Exemples d’associations
CATALOGUE nom-catalogue TIMBRE sens (de lecture) éditeur numéro-ordre année-parution année-émission EST-REFERENCE-DANS pays-émetteur état numéro-timbre catégorie
EST-ACHETE-PAR CLIENT TIMBRE date-achat nom-client CATALOGUE prénom-client adresse CLIENT
TIMBRE x CATALOGUE NB : ce schéma est inachevé. TIMBRE x CLIENT Propriétés implicites et explicites
TIMBRE EST-ACHETE-PAR CLIENT numéro-ordre date-achat nom-client année-émission prénom-client pays-émetteur adresse état
EST-ACHETE-PAR peut, comme une entité, être décrite par un tableau. Celui-ci comprend quatre colonnes :
numéro-ordre nom-client prénom-client date-achat
implicites explicite
Propriétés implicites et explicites
Les propriétés implicites jouent le rôle d’identifiant. Elles permettent de garantir l’unicité des occurrences de l’association.
numéro-ordre nom-client prénom-client date-achat
identifiant
Il n’y a pas d’occurrence de EST-ACHETE-PAR ayant la même valeur de couple (numéro-ordre, (nom-client, prénom-client))
C’est un bien un couple !
Associations et identifiants
Une association, comme une entité, a un identifiant, constitué des identifiants des entités appartenant à sa collection (collection de EST-ACHETE-PAR est composée de TIMBRE et CLIENT).
TIMBRE EST-ACHETE-PAR CLIENT numéro-ordre date-achat nom-client année-émission prénom-client pays-émetteur adresse état Toutes les occurrences sont identifiées.
Exemple d’un identifiant d’association
ETUDIANT EST-INSCRIT-EN FORMATION numéro-étudiant date-inscription nom-formation
numéro-étudiant nom-formation date-inscription Pas possible ! 17 DEUG MIAGE 2002/2003 (l’identification joue sur 17 DEUG MIAGE 2003/2004 l’identifiant, pas sur les autres propriétés)
Avec ce schéma, un étudiant ne peut pas redoubler ou, plus exactement, il peut le faire sans que cela soit mémorisé !
Association sans propriété
Il n’y a aucune obligation de placer une propriété dans une association. La présence de cette information dépend uniquement de la situation à décrire.
TIMBRE EST-ACHETE-PAR CLIENT numéro-ordre date-achat nom-client année-émission prénom-client pays-émetteur adresse état
TIMBRE CLIENT EST-ACHETE-PAR numéro-ordre nom-client année-émission prénom-client pays-émetteur adresse état
Association en boucle
parrain CLIENT CLIENT numéro-client numéro-client EST-PARRAINE-PAR nom-client EST-PARRAINE-PAR nom-client prénom-client prénom-client adresse adresse filleul
Notion de rôle
Cette structuration est difficile à comprendre ; elle nécessite un numéro-client numéro-client soin particulier dans la rédaction de la documentation associée. filleul parrain
TIMBRE x CLIENT x DATE Association ternaire
TIMBRE CLIENT EST-ACHETE-PAR numéro-ordre nom-client année-émission prénom-client pays-émetteur adresse état
DATE Jour Mois Un timbre donné est Année acheté à une date donnée par un client donné.
. Les associations vues jusqu’à présent sont des associations binaires.
. Le nombre de « pattes » de l’association est sa dimension.
. Plus généralement, on parle d’association n-aire avec n la dimension. Les cardinalités
Le schéma doit être complété par des informations quantitatives. Ces quantités correspondent aux nombres d’occurrences d’entités impliquées dans une association.
ETUDIANT * EST-INSCRIT-EN * DIPLOME date
(mini, max, moy) (mini, max, moy)
Il y a trois quantités à indiquer, une minimale, une maximale et une moyenne, de chaque « coté » de l’association. La troisième (la moyenne) n’est pas toujours mentionnée. Occurrence « lambda », représentative de l’ensemble
* * Association entre E1 et E2 * * * * * * * * * * * * *
Ensemble des Combien ? occurrences de E1
Une cardinalité, c’est, par exemple, le nombre d’occurrences de E2 auxquelles est liée une occurrence « lambda » de E1.
LesLes cardinalitéscardinalités
Les cardinalités mini et maxi ne peuvent prendre que 3 valeurs :
Une occurrence de E1 peut ne pas être 00 reliée, dans A, à une occurrence de E2. mini Une occurrence de E1 doit être reliée, dans 11 A, à une occurrence de E2. maxi Une occurrence de E1 peut être reliée, dans nn A, à plusieurs occurrences de E2.
mini ≤ maxi
Les cardinalités
TIMBRE EST-ACHETE-PAR numéro-ordre date-achat Un timbre peut ne année-émission pays-émetteur (0, -, -) jamais être acheté. état
TIMBRE EST-ACHETE-PAR Un timbre est numéro-ordre date-achat obligatoirement acheté… année-émission dès sa création ! pays-émetteur (1, -, -) état (1, -, -)
Les cardinalités
CLIENT EST-ACHETE-PAR nom-client Un client pourra date-achat prénom-client acheter plusieurs adresse (-, n, -) timbres.
CLIENT EST-ACHETE-PAR nom-client Un client n’achètera jamais date-achat prénom-client adresse qu’un seul timbre ! (-, 1, -)
Et les cardinalités moyennes ?
TIMBRE EST-ACHETE-PAR numéro-ordre date-achat année-émission pays-émetteur (0, 1, 0.8) état
Un timbre peut ne jamais être acheté. S’il l’est, il ne le sera que par un seul client. En moyenne, sur les 5 dernières années, 80 % des sur la base des archives timbres sont achetés.
Et les cardinalités moyennes ?
CLIENT EST-ACHETE-PAR nom-client date-achat prénom-client adresse (1, n, 20)
Tout client a au moins un jour acheté un timbre. Il peut (c’est souhaitable) en acheter plusieurs. En moyenne, sur les 5 dernières années, un client achète 20 timbres.
sur la base des archives
LesLes cardinalitéscardinalités
TIMBRE CLIENT FAIT-UNE-OFFRE-POUR numéro-ordre nom-client année-émission prénom-client pays-émetteur adresse état (0, n, -)
Un client peut ne pas faire d’offre d’achat (à quelque date que ce soit) ; il peut en faire plusieurs : DATE Jour Mois - soit à la même date, pour des timbres différents, Année - soit pour le même timbre, à des dates différentes.
Les cardinalités
TIMBRE CLIENT FAIT-UNE-OFFRE-POUR numéro-ordre nom-client année-émission prénom-client pays-émetteur adresse état (0, n, -)
Un timbre peut n’être jamais l’objet d’offres ; il peut faire l’objet de plusieurs : DATE Jour - soit à la même date, par des clients différents ; Mois Année - soit par le même client, à des dates différentes.
Utilisation des cardinalités
Ces cardinalités correspondent à la loi que doivent respecter toutes les occurrences. Elles sont associées à un contrôle, mis en œuvre lors de toute mise à jour.
Personnalisation des associations
Il y a des associations qui impliquent non pas des entités, mais des associations d’entités.
E1
E2 E3
ACHETEUR nom-acheteur prénom-acheteur Exemple 1/2 0, n
On peut, par exemple, vouloir acheter un timbre seulement s’il est expertisé par un expert donné. La demande d’achat concerne donc un timbre précis et une expertise précise.
DEMANDE
0, n
EXPERTISE
TIMBRE EXPERT EXPERTISE année-émission nom-expert pays-émetteur prénom-expert 0, n 0, n état
ACHETEUR nom-acheteur prénom-acheteur Exemple 2/2 0, n
La personnalisation d’une association consiste à prendre du recul, à considérer l’association comme une entité, de clé la clé de l’association. DEMANDE
0, n
TIMBRE (1, 1) EXPERT EXPERT-TIMBRE (1, 1) 0, n 0, n EXPERTISE EXPERTISE année-émission nom-expert pays-émetteur prénom-expert état
2. Normalisation du MCD
Normalisation des modèles
But : atteindre une certaine qualité des schémas produits.
Il y a des normes pour quasiment chaque élément :
- normalisation des noms, - normalisation des propriétés, - normalisation des cardinalités, - normalisation des associations.
Normalisation des noms
- chaque entité a pour nom un nom commun singulier. (ex : CLIENT, COMMANDE, TIMBRE…) - chaque association a pour nom un groupe verbal. (ex : EST-PASSEE-PAR, GARANTIT…) - chaque propriété a un nom composé de deux mots, le second étant obligatoirement celui de l’entité ou de l’association « dans » lequel il est. - pas de nom qu’on ne peut trouver dans un dictionnaire (ex : XY, ASSO1, ASSO2…)
Normalisation des noms
Pas deux fois le même nom pour le même type d’éléments.
CLIENT COMMANDE numéro-client nom-client numéro-commande adresse-règlement date date
Normalisation des noms
Il peut aussi y avoir un travail de mise en évidence d’un lien, d’une association, à entreprendre : CLIENT numéro-client CLIENT nom-client COMMANDE date numéro-client numéro-commande nom-client adresse date date adresse adresse EST-PASSEE-PAR
1, 1 Cette association nouvellement créée permet à COMMANDE d’avoir accès à la propriété COMMANDE numéro-commande enlevée. date
Normalisation des noms
Si la suppression de (n - 1) exemplaires des propriétés ayant le même nom dérange, il est toujours possible de satisfaire la règle en rendant les noms uniques :
CLIENT COMMANDE numéro-client nom-client numéro-commande adresse-règlement date date
Une solution ?
Normalisation des propriétés
Il y a un travail de détection/correction de propriétés :
- ayant des noms non significatifs, - redondantes, - calculées, - mal localisées.
Normalisation des propriétés
La redondance des propriétés doit être éliminée des schémas. Sa persistance fait courir à la base de données un risque majeur, celui de l’incohérence lors de la mise à jour.
Occurrences de E1
propr1
E1 E2 XYZ prop1 prop1 Occurrences de E2
propr1
XYZ
Normalisation des propriétés
La raison qui justifie la non-mémorisation d’une information calculée réside dans le risque d’incohérence encouru lors d’une modification d’une valeur brute.
Supposons que l’on ait, malgré tout, enregistré info4 et que la valeur de info3 change.
info4 info1 info3
info2
info4 := f (info1, info2, info3)
Normalisation des propriétés
Le dernier contrôle porte sur la localisation des propriétés et plus précisément sur le cas d’une association porteuse d’information(s) de type fonction totale :
EST-INCLUSE-DANS EST-INCLUSE-DANS date -, 1 -, 1 RUBRIQUE1 RUBRIQUE1 nom-rubrique1 nom-rubrique1 date
Normalisation des entités
Toutes les entités doivent avoir un identifiant.
CLIENT CLIENT numéro-client numéro -client nom-client nom-client adresse-règlement adresse-règlement date Xdate
Normalisation des cardinalités
Les cardinalités mini et maxi appartiennent à l’ensemble {0, 1, n}. Toutes les valeurs en dehors de celui-ci sont à proscrire.
Mettre un maximum de 3 limitera E1 ASSO à 3 le nombre de liaisons et ce sur la totalité de la vie de l’occurrence 0, 3 de E1.
E1 ASSO
Pas plus de 3 => structure de taille 0, n fixée à 3 éléments. Si, un jour, cela (n ≤ 3) passe à 5 … il faut tout refaire !
Normalisation des associations
E1 E2 ASSO
1, 1 1, 1 E1 E2 ASSO1
fantômes 1, 1 -, - 1, 1 1, 1
ASSO2 ASSO3
E1 E2 - , - ASSO E3 -, 1 -, n - , n E3 décomposables redondantes
Normalisation des associations
E1 E2 Une association fantôme est 1, 1 1, 1 une association dans laquelle tous les couples de ASSO 1, 1 cardinalités (mini, maxi) sont E3 à (1, 1). 1, 1 E4
card (E1) = card (E2) = card (E3) = card (E4)
Normalisation des associations
Une telle structure se simplifie.
E1 E2 E1-2-3-4 1, 1 ident-E1 1, 1 ident-E2 ident-E3 ASSO ident-E4 1, 1 prop-E1 prop-E2 E3 prop-E3 1, 1 E4 prop-E4
Il y a 4 clés potentielles. Il faut en choisir une.
Normalisation des associations
départ Il y a redondance de chemins si pour chaque occurrence de E1 E2 l’entité de départ, que l’on ASSO1 parte sur la gauche ou sur la 1, 1 -, - droite, on arrive à la même 1, 1 1, 1 occurrence de l’entité d’arrivée. ASSO2 ASSO3 - , - X- , - E3 Si on est dans cette situation, on va supprimer le plus court chemin (le plus « pauvre »). arrivée
Normalisation des associations
FACTURE Si tous les clients règlent eux-même leurs factures, il y a redondance. On doit donc -, - 1, 1 enlever PAYE (le plus court chemin).
CORRESPOND-A
EST-RECUE-PAR
REGLEMENT 1, 1
1, 1 - , -
PAYE CLIENT
- , -
Normalisation des associations
E1 E2 ASSO
-, 1 -, n - , n
E3
Décomposition d’associations n-aires, avec n > 2, si il y a au moins un couple de cardinalités (1,1) ou (0, 1).
Normalisation des associations
La règle est simple :
E1 E2 ASSO
-, n -, n décomposable - , n
E3 E1 E2 ASSO
-, 1 -, n - , n
E3 NON décomposable
Normalisation des associations
… son application aussi simple :
E2 ASSOa -, n -, 1
E1 E2 ASSO E1
-, 1 -, n - , n
E3 -, 1 E3 ASSOb - , n
AVANT APRES
Normalisation des associations
Ca marche aussi avec plus de 3 pattes ...
E4 E2 ASSOa -, n 1, 1 1, 1
E1 E2 E1-4 ASSO
1, 1 -, n - , n 1, 1 E3 E3 ASSOb - , n
AVANT APRES
3. Le MLD relationnel
Modèle relationnel
Défini par E.F. Codd en 1970 à IBM San José. Les données sont enregistrées dans des tableaux à deux dimensions (lignes et colonnes). La manipulation de ces données se fait selon la théorie mathématique des relations.
Modèle relationnel
Les concepts du modèle relationnel découlent de la théorie des ensembles A ce type de modèle sont associées les notions suivantes: domaine table relationnelle attribut tuple (ou n-uplet)
Modèle relationnel : les domaines
Un domaine est un ensemble de valeurs ayant une signification pour l'utilisateur
Ex: le domaine des noms, le domaine des âges,…
Ex: le domaine des entiers E={...-2,-1,0,+1,+2,...}
Modèle relationnel : table relationnelle
Une table relationnelle = sous-ensemble du produit cartésien d'une liste de domaines (non nécessairement distincts).
Une table relationnelle est généralement caractérisée par un nom.
Exemple: D1= n°compte = {suite de symboles alphanumériques} D2= solde_compte = {réel}: on peut composer la relation « compte » :
Compte (n°compte, solde_compte)
notation en intention
attribut Modèle relationnel
date n°secu nom prénom naissance
124436 AGKHF ZDDZED 20/10/84
543674 MARTIN Thomas 10/01/01 tuple 89879 DURAND Cyrille 12/09/34
3213 DUPOND Marc 21/05/07
355A45 AZERTY Olivier 17/06/95
notation en extension Relation ou table relationnelle Modèle relationnel : attribut
Un attribut = colonne d'une table caractérisée par un nom L'ordre des colonnes est sans importance Plusieurs colonnes peuvent appartenir à un même domaine
Modèle relationnel : clé de table relationnelle
Une clé est un ensemble minimal d'attributs qui détermine tous les autres il peut y avoir plusieurs clés pour une même relation; on en choisit en général une comme clé primaire. La clé primaire est dite simple si elle est constituée d’un seul attribut et composée dans le cas contraire.
Modèle relationnel : exemples de clés
Compte (n°compte, solde_compte)
date n°secu nom prénom naissance
124436 AGKHF ZDDZED 20/10/84
543674 MARTIN Thomas 10/01/01
89879 DURAND Cyrille 12/09/34
3213 DUPOND Marc 21/05/07
355A45 AZERTY Olivier 17/06/95
4. Passage du MCD au MLD relationnel Règles de transformation MCD MLD : l’entité
Entité -> Table Toute entité est transformé en table. Ses propriétés deviennent les attributs de la table. L’identifiant devient clé primaire de la table
Propriété -> Attribut Une propriété est transformée en attribut
Identifiant -> Clé primaire Un identifiant est transformé en une clé primaire
Identifiant composé -> Clé composée Une concaténation d’identifiants est transformée en une clé composée Exemple de transformation d’une entité
CLIENT
N° Client Nom CLIENT (N° client, Nom, Prénom Prénom, Date_naissance) Date_naissance TABLE RELATIONNELLE formalisme de Codd Entité du MCD Exemple de transformation d’une entité
Entité "Entreprise" Table "Entreprise"
TABLE RELATIONNELLE formalisme graphique Règles de transformation MCD MLD : les associations Le lien entre 2 tables relationnelles est réalisé par la duplication de la clé primaire d’une table dans l’autre table, ou de la duplication des 2 clés primaires dans une nouvelle table. Cette clé dupliquée est appelée clé externe ou clé étrangère Exemple:
CLIENT COMMANDE Client_Num 1,n passe 1,1 Cmde_Num Client_Nom Cmde_Date Client_Prénom MCD MLD : table client
Client_Num Client_Nom Client_Prénom …
VH20021 Hugo Victor … EZ20006 Zola Emile … AZ19999 Zapata Achille … EZ19873 Zapata Emilie … … … … … MCD MLD : table commande
Clé primaire Attribut Clé étrangère
Cmde_Num Cmde_Date Client_Num 12345 02/09/03 VH20021 12346 02/09/03 VH20021 12347 03/09/03 EZ20006 12348 03/09/03 AZ19999 12349 03/09/03 AZ19999 12350 04/09/03 EZ19873 … … … Tuples Règles de transformation MCD MLD : les associations (1)
Table issue d’une association binaire: (0,n)-(1,1) (1,n)-(1,1)
La clé primaire de la table issue de l’entité côté cardinalités (0,n) ou (1,n) est dupliquée dans la table issue de l’entité côté cardinalités (1,1) où elle devient clé externe Les deux tables sont liées par une flèche nommée selon la relation, qui pointe de la table à clé étrangère vers la table qui contient la clé primaire correspondante. Exemple : transformation d’association (1)
L'attribut n°auteur qui est clé primaire de la table Auteur, devient clé étrangère dans la table Livre. Elle doit alors être précédée de #.
Notation « en ligne » Auteur(n°auteur,nom) Livre (n°livre,#n°auteur,titre) Méthode de modélisation des données Règles de transformation MCD MLD : les associations (2)
Table issue d’une association binaire (0,n)-(0,1) (1,n)-(0,1) La clé primaire de la table issue de l’entité côté cardinalités (0,n) ou (1,n) est dupliquée dans la table issue de l’entité côté cardinalités (0,1) où elle devient clé externe qui peut être une valeur nulle (sauf si …) Exemple : transformation d’association (2)
A vous de trouver un exemple !
Méthode de modélisation des données Règles de transformation MCD MLD : les associations (3)
Table issue d’une association binaire (0,1)-(1,1)
La clé primaire de la table issue de l’entité côté cardinalités (0,1) est dupliquée dans la table issue de l’entité côté cardinalités (1,1) où elle devient clé externe Exemple : transformation d’association (3)
Le n°client, qui est clé primaire de la table Client, devient clé étrangère dans la table Carte.
Méthode de modélisation des données Règles de transformation MCD MLD : les associations (4)
Table issue d’une association binaire (0,1)-(0,1)
La clé primaire de la table issue de l’une des entités est dupliquée dans la table issue de l’autre entité où elle devient clé externe qui peut être une valeur nulle (sauf si …) Exemple : transformation d’association (4)
ou
Soit on migre la clé primaire de la table Entreprise dans la table Salarié, soit on fait l'inverse
Méthode de modélisation des données Règles de transformation MCD MLD : les associations (5)
Table issue d’une association binaire (0,n)-(0,n) (1,n)-(1,n) (1,n)-(0,n) Une table ayant comme clé une clé composée des identifiants des 2 entités est créée. Les éventuelles propriétés de l’association deviennent les attributs de la table Exemple : transformation d’association (5)
On crée une table PORTE_SUR, qui contient comme clé primaire une clé composée de n°commande et de n°article. Elle contient également la propriété quantite issue de la relation PORTE_SUR
Méthode de modélisation des données Règles de transformation MCD MLD : les associations (6)
Table issue d’une relation ternaire ou supérieure
Une table ayant comme clé une clé composée des identifiants des entités est créée. Les éventuelles propriété de l’association deviennent les attributs de la table Exemple : transformation d’association (6)
La table ENSEIGNE contient une clé composée de n°enseignant, n°matiere et n°classe.
Méthode de modélisation des données Transformation de plusieurs relations entre 2 entités
Les règles générales s’appliquent
Méthode de modélisation des données Règles de transformation MCD MLD : les associations (7)
Table issue d’une association réflexive (0,n)-(x,1) ou (1,n)-(x,1) La clé primaire de la table issue de l’entité est dupliquée dans cette table où elle devient une clé externe qui peut être une valeur nulle si x=0. Exemple : transformation d’association (7)
#numeroParrain est mieux indiqué que PER_n°personne Règles de transformation MCD MLD : les associations (8)
Table issue d’une association réflexive (0,n)-(0,n) (1,n)-(1,n) (1,n)-(0,n) Une table ayant comme clé une clé composée de 2 fois l’identifiant de l’entité est créée. Les éventuelles propriétés de l’association deviennent des attributs de la table. Exemple : transformation d’association (8)
Nous appliquons les règles générales avec la seule différence que la relation est 2 fois reliée à la même entité
Méthode de modélisation des données Exemple : transformation d’association (9)
Table issue d’une association réflexive (0,1)-(x,1) La clé primaire de la table issue de l’entité est dupliquée dans cette table où elle devient une clé externe qui peut être une valeur nulle si x=0. Les éventuelles propriétés de l’association deviennent des attributs de la table. Exemple : transformation d’association (9)
Nous appliquons les règles générales avec la seule différence que la relation est 2 fois reliée à la même entité
Méthode de modélisation des données En résumé
Une entité devient une relation (c.a.d. une table). Les entités cherchent à récupérer les identifiants de leurs voisines ! Celles étant impliquées à 1,1 ou 0,1 gagnent toujours avec « 1,1 plus fort que 0,1 » ! (0,1- 0,1, attention optimisation …). Dans les configurations x,n – x,n, match nul, création d’une nouvelle table avec tous identifiants impliqués. Notation 1/2
Préciser quel attribut est clé étrangère : faire précéder les attributs concernés par # (représentation graphique ou non).
Notation graphique : indiquer quelle clé étrangère est impliquée dans une dépendance si ambiguïté. Indiquer également le champ dont dépend la clé externe si celui-ci n’est pas une clé primaire (seulement possible pour les champs avec contrainte UNIQUE).
B C A #n°truc n°B #n°machin -> n°alternatif n°C n°A #n°truc n°alternatif #n°machin Notation en ligne : indiquer la provenance de la clé étrangère. A(n°A), B(n°B,#n°truc(A.n°A),#n°machin(C.n°alternatif)), C(n°C, n°alternatif)
Notation 2/2
Cas d’ une clé étrangère composée
Notation graphique TRUC n°truc STUFF A n°A #n°truc MACHIN #(n°truc,n°machin) #n°machin n°machin
Notation en ligne
A(n°A,#(n°truc,n°machin)),STUFF(#n°truc,#n°machin),TRUC(n°truc),MACHIN(n°machin)
5. Normalisation du MLD
La normalisation
Théorie élaborée par E.F. Codd en 1970 But : éviter les anomalies dans les bases de données relationnelles Supprimer certains types de redondances Éviter certaines anomalies de mise à jour Simplifier la satisfaction de certaines contraintes d’intégrité Plus le niveau des formes normales est élevé pour une table, plus cette table sera exempte d’anomalies Un bon MCD implique souvent un modèle relationnel ayant déjà atteint un bon niveau de normalisation L’analyse des FN devient alors un bon outil de validation
108 Dépendance fonctionnelle (DF)
Association plusieurs-vers-un entre deux ensembles d’attributs XY Y est en dépendance fonctionnelle de X… X détermine fonctionnellement Y… … si et seulement si à chaque valeur de X correspond exactement une seule valeur de Y Autrement dit, lorsque 2 tuples s’accordent sur leur valeur de X, ils s’accordent également sur leur valeur de Y
109 Dépendance fonctionnelle (DF)
Les dépendances fonctionnelles peuvent être internes DF entre attributs d’une même entité Ex. : PERSONNE (NAS, Nom, Prénom) NAS Nom Avec le NAS, je trouve un et un seul nom Elles peuvent aussi être externes DF entre entités Facture Client
110 Première forme normale (1FN)
Une table est en 1FN si tous ses attributs sont simples et non décomposables (/besoin en traitement …) Ne sont pas en 1FN : PERSONNE (NAS, Nom, Prénom, PrénomEnfants) PERSONNE (NAS, Nom, Prénom, Adresse) Si la transposition d’un MCD en modèle relationnel n’est pas déjà en 1FN, c’est qu’il a été mal modélisé ! => 1FN = atomicité.
111 Deuxième forme normale (2FN) Une table est en 2FN si et seulement si elle est en 1FN et si chaque attribut non clé est en dépendance fonctionnelle irréductible avec la clé primaire Autrement dit, une table est en 2FN si Elle est en 1FN Une des 3 conditions suivantes est vérifiée La clé primaire n’est formée que d’un seul attribut La clé primaire contient tous les attributs de la table Si la clé primaire a plus d’un attribut, une dépendance fonctionnelle ne doit jamais exister entre une partie de la clé et un autre attribut de la table => Tout attribut qui ne fait pas partie de la clé dépend de toute la clé (dépendance fonctionnelle totale)
112 Deuxième forme normale (2FN)
Pour passer de la 1FN à la 2FN, il faut diviser chaque table ne satisfaisant pas les critères en deux tables distinctes Pour diviser une table en deux, il faut Créer une nouvelle table ayant pour clé la partie de la clé primaire dont dépend le ou les attributs, ainsi que ces attributs eux-mêmes. Éliminer ces attributs (ceux qui ne font pas partie de la clé) de la table originale
113 Deuxième forme normale (2FN) - Exemple
La table suivante représente des modèles génériques de télévisions construites par différents fabricants. La marque et le modèle permettent d’identifier de façon unique chaque sorte de télévision. Le mode sonore ainsi que la résolution sont spécifiques au modèle et non à la marque (ex: HDTV) TÉLÉVISION (Marque, Modèle, ModeSon, Résolution) Il y a donc une DF entre "Modèle" et "ModeSon", ainsi qu’entre "Modèle" et "Résolution" Il faudra donc diviser cette table en deux de la façon suivante : TÉLÉVISION (Marque, #Modèle) MODÈLETV (Modèle, ModeSon, Résolution)
114 Troisième forme normale (3FN)
Une table est en 3FN si et seulement si elle est en 2FN et si chaque attribut non clé est en dépendance non transitive avec la clé primaire Autrement dit, une table est en 3FN si Elle est en 2FN Aucun attribut ne faisant pas partie de la clé primaire ne dépend d’un autre attribut ne faisant pas partie lui non plus de la clé primaire => Les dépendances fonctionnelles entre deux attributs ordinaires (ne faisant pas partie de la clé) sont interdites.
115 Troisième forme normale (3FN)
Cette table n’est pas en 3FN AÉROPORT (CodeAéroport, Nom, Ville, Prov-État, Pays, Altitude, LongueurPiste)
Pourquoi ?
116 Troisième forme normale (3FN)
Pour passer de 2FN à 3FN, il faut Diviser chaque table ne satisfaisant pas ce critère en deux tables. La nouvelle table aura comme clé l’attribut dont provient la dépendance et comme attributs, ceux qui en dépendent. Éliminer les attributs dépendants de la table originale. La clé de la nouvelle table demeure dans l’ancienne en tant que clé étrangère Correction : AÉROPORT (CodeAéroport, Nom, #(Ville, Prov-État), Altitude, LongueurPiste) VILLE (Ville, Prov-État, Pays)
117 Troisième forme normale (3FN) - Exemple
Un vendeur de voitures usagées vend ses voitures à un prix unique selon l’année de construction VOITURE (NoStock, Marque, Modèle, Année, Couleur, Prix) Il y a donc une DF entre "Année" et "Prix", ce qui signifie que cette table n’est pas en 3FN. Il faut donc décomposer cette table en deux. VOITURE (NoStock, Marque, Modèle, #Année, Couleur) PRIXVENTE (Année, Prix)
118 Forme normale de Boyce-Codd (FNBC)
Définition plus rigide de la 3FN Une table est en FNBC si Elle est en 3FN Aucun attribut faisant partie de la clé primaire ne dépend d’un attribut ne faisant pas partie de la clé primaire Autrement dit, une table est en FNBC si une des conditions suivantes est remplie Sa clé n’est constituée que d’un seul attribut Tous les attributs sont dans la clé primaire IL n’y a pas de dépendance fonctionnelle entre un attribut ordinaire et un attribut faisant partie de la clé primaire
119 Forme normale de Boyce-Codd (FNBC)
Une base de donnée peut généralement être considérée comme implantable lorsqu’elle est en FNBC. Les cas de tables modélisées et transformées en 3FN qui ne sont pas déjà en FNBC sont très rares.
120 Forme normale de Boyce- Codd (FNBC) : exemple
Dans cet exemple, les attributs sont des clés étrangères, ce qui n’est pas un condition préalable pour vérifier si une FNBC est violée. #Id enseignant #Id matiere #Id salle 1 5 2 2 5 4 3 5 4 4 5 2 5 6 3 6 6 3 121 Forme normale de Boyce- Codd (FNBC) : exemple
#Id enseignant #Id salle 1 2 On retire l’attribut en dépendance 2 4 fonctionnelle. L'origine de la dépendance 3 4 fonctionnelle est conservée et compose 4 2 la nouvelle clé . 5 3 6 3
122 Forme normale de Boyce- Codd (FNBC) : exemple
#Id matiere #Id salle
5 2 On crée une nouvelle table ayant pour clé l’attribut 5 4 à l’origine de la dépendance fonctionnelle et ayant pour 5 4 attribut la partie de la clé impliquée dans la dépendance 5 2 fonctionnelle. 6 3 6 3 123 En résumé (1/2)
FNBC 3FN 2FN 1FN
En résumé (2/2)
FNBC
2FN 3FN A B C D E … … … … … … … … … …
1FN : atomicité
6. Le MPD
Le modèle physique des données
Le modèle physique des données (MPD) est la traduction du modèle logique des données (MLD) dans une structure de données spécifique au système de gestion de bases de données (SGBD) utilisé, e.g. le script de création de la base.
Ne pas oublier la spécification : - des uniques, - des indexs (où sont-ils ?), - du mode de gestion des contraintes d’intégrité référentielle (cascade, restrict, no action, no value, default value, etc …).
Méthode de modélisation des données 7. Le modèle objet
Un peu d’histoire
L’approche orientée objets à 50 ans Issue de la recherche en programmation 1961/64 : Simula I, Norvège 1967 : Simula 67, Norvège 1976 : Smalltalk , PARC Lab, Xerox, USA 1980 : Version industrielle de Smalltalk 1980 : C++ , Bell Labs 1986 : 1200 personnes pour OOPSLA’86 1995 : Java, Sun microsystems 1996 : Omniprésence des solutions objets
129 De la programmation fonctionnelle à la programmation objet (1/4)
Programmer Définir les structures de données à manipuler Définir les traitements à leur appliquer Définir la succession des appels de données et des traitements Programmation fonctionnelle Programmer d’une part les structures de données, d’autre part les traitements Avantage : traiter séparément des problèmes de nature différente (mais liés … cf. ci-dessous …) Inconvénient : difficulté des corrections et mises à jour
130 De la programmation fonctionnelle à la programmation objet (2/4)
La fonction donne la forme du programme/système.
131 De la programmation fonctionnelle à la programmation objet (3/4)
Programmation objet Idée de base : rapprocher données et traitements au sein d’un seul module, l’objet Définir des structures de données Associer et définir les traitements concernant ces structures Les objets sont des entités autonomes qui collaborent afin de réaliser un projet/but global. L’objet, c’est donc l’étape ultime de la modularité, un changement de l’art du programmeur.
132 De la programmation fonctionnelle à la programmation objet (4/4)
La fonction (but/projet) du système/du programme est réalisée par des objets collaborant.
3: Ouvrir Porte Cabine
1: Aller au RDC
Lumière Bouton
2: Clignoter
133 Notion d’objet
Un OBJET est une abstraction d’une personne, d’un lieu, d’une chose ou d’un concept relatif au domaine du problème pris en charge par le programme.
1
134 Objet
Un objet est une boîte noire L’utilisateur d’un objet ne voit pas l’intérieur de l’objet
Intérieur Etat (structures de données) Opérations/traitement (code) Encapsulation: l’objet cache son code et ses données
135 Les attributs (propriétés)
Un ATTRIBUT est une donnée qui décrit une des Prénom Nom propriétés de l’objet. Mary Smith Susan Jones Jeff Norman L’ensemble des valeurs prises par les attributs à un instant donné définit un ETAT de l’objet.
couleur = rouge
forme = disque 136 Exemple : objets de « type étudiant »
prénom nom adresse pointure yeux poids dateNaissance Susan McIntyre 123 Franklin St. 11 Blue 175 4-12-74 San Diego CA Greg Fisher 765 Park Ave. 10 Brown 170 12-2-73 San Diego CA Minder Chen 222 Dallas St. 9.5 Brown 140 10-5-76 La Mesa CA Sally Athey 862 Grand Ave. 6 Brown 125 6-28-75 Pacific Beach CA Laura Applegate 914 Garnett 5 Blue 110 3-15-74 La Jolla CA Margie Heltne 479 55th St. 5.5 Brown 105 5-22-75 El Cajon CA Bill Martz 876 Balboa 10.5 Blue 190 1-26-70 Mission Beach CA Anna Easton 309 Del Mar Hts. 6 Brown 120 8-14-74 Del Mar CA
137 Les méthodes (opérations)
Une METHODE est une procédure/fonction que l’objet Etudiant XCD1233 peut exécuter. • attributs • Nom : Drumond • Prénom : Joe • etc...
•méthodes •affectationAUnGroupe •changementDeGroupe •aujouterUneNote •calculDeLaMoyenne Le slogan des objets : • etc... “I do it myself” 138 Les messages
Les objets communiquent via des MESSAGES.
OBJET a OBJET c
OBJET b OBJET d 139 “The operation is the Les messages message.”
Un MESSAGE est un signal d’un objet vers un autre et qui demande à l’objet (récepteur) d’exécuter une de ses méthodes/opérations.
Les 3 parties d’un message : 1. Le nom du destinataire 2. La méthode à exécuter 3. Les éventuels paramètres nécessaires à l’opération invoquée. Message: achète des fraises Opération: acheterFraises($$) 140 Messages et Méthodes
Un objet ne peut être sollicité que par l’intermédiaire de ses opérations Il faut envoyer un message à l’objet Opérations (méthodes) répondent aux messages Méthodes définissent l’interface Il suffit de connaître l’interface pour utiliser l’objet
Pourquoi ne pas regarder ? Interface définit ce que l’objet peut faire Intérieur définit comment ça marche Même si l’intérieur d’un objet change, l’objet appelant, lui, ne doit pas changer => permettre la modularité et la réutilisation.
141 En résumé, l’objet est …
Un objet est une personne, un lieu, une chose, un concept dont on veut acquérir une représentation. Exemples : un nombre entier, un avion, un étudiant, un diplôme. Chaque objet à des propriétés (ou attributs). L’état d’un objet est défini par les valeurs de ses propriétés. Les objets ont des comportements – des “choses qu’ils font” – qui sont décrits par des méthodes (opérations, messages).
142 Exemple : objets de « type étudiant ». De « type »?
prénom nom adresse pointure yeux poids dateNaissance Susan McIntyre 123 Franklin St. 11 Blue 175 4-12-74 San Diego CA Greg Fisher 765 Park Ave. 10 Brown 170 12-2-73 San Diego CA Minder Chen 222 Dallas St. 9.5 Brown 140 10-5-76 La Mesa CA Sally Athey 862 Grand Ave. 6 Brown 125 6-28-75 Pacific Beach CA Laura Applegate 914 Garnett 5 Blue 110 3-15-74 La Jolla CA Margie Heltne 479 55th St. 5.5 Brown 105 5-22-75 El Cajon CA Bill Martz 876 Balboa 10.5 Blue 190 1-26-70 Mission Beach CA Anna Easton 309 Del Mar Hts. 6 Brown 120 8-14-74 Del Mar CA
143 Notion de classe
Une classe est un modèle qui représente une collection d’objets qui partage le même ensemble d’attributs et d’opérations. Etudiant Classe attributs operations
Objets
144 Classe et instances
145 Classes et instances Classe Chien Classe Définit les objets en définissant les données et les opérations Rex Objets Instances individuelles de la classe Toby Classe Chien Instances (exemplaires) : 2 objets Rex, Toby représentent 2 chiens différents
146 Classes et instances
A chaque instance créée est assigné un identificateur unique (UID)
Automobile VF8JE0KL523478498
Marque Marque : Renault Type Type : Espace Date achat Date achat : 30/10/2000 Immatriculation Immatriculation : 2210 XH 30 Kilométrage Kilométrage : 22635 âge Âge : 2 ans 3 mois
age() age() kilometrage() kilometrage()
Classe instance/objet 147 Classes et instances
A chaque instance créée est assigné un identificateur unique (UID)
148 8.
What is the UML?
Unified Modeling Language UML est une notation, pas une méthode. UML est un langage de modélisation objet. UML convient pour toutes les méthodes objet. UML est dans le domaine public.
UML est la notation pour
documenter les modèles objets Les sources d’inspiration
3 méthodes de conception objet mises au point à la fin des années 80 et publiées en 1991 :
OOD, Object Oriented Design, G. Booch, DoD. Particulièrement adaptée à la conception du logiciel et à l’implémentation en C++.
OMT, Object Modeling Technique J. Rumbaugh, General Electric. Permet la représentation de tous types de systèmes, qu’ils soient à base de logiciel ou non.
OOSE, Object Oriented Software Engineering, I. Jacobson, Ericsson. Place au premier plan l’expression des besoins de l’utilisateur.
Acte de naissance
Rumbaugh rejoint Booch chez Rational en 1994 et en 1995, Jacobson complète l’équipe. En 1996, le travail sur UML commence. La version 0.9 est produite. En 1996, l’OMG (Object Management Group) fait un appel d’offre pour une méthodologie. En Janvier 1997, Rational propose UML 1.0 à l’OMG. DEC, HP, IBM, TI, Microsoft, Oracle (entre autres) soutiennent la proposition. 14 novembre 1997 : UML adopté par l’OMG Depuis, l’OMG soutient UML. La dernière version est la version 2.0 (2005).
“Los 3 Amigos” Booch Jacobson Rumbaugh
Les diagrammes d'UML (1/3)
UML utilise des représentations diagrammatiques pour modéliser les aspects statiques (structurel) et dynamiques (comportemental) des systèmes.
Certains diagrammes sont utilisés dans les activités d’analyse et de conception avec un niveau de granularité différent.
Les diagrammes d'UML (2/3)
Avantages : représentation en 2D représentation sémantiquement riche chaque notation est simple => facilité d’apprentissage par les non informaticiens => validation possible par les utilisateurs finaux Inconvénients : sémantique pas totalement définie => risque d'interprétations variées beaucoup de diagrammes différents => difficulté à maîtriser toutes les notations besoin d’une méthode sous-jacente : Fusion, RUP, USDP ....
Les diagrammes d’UML(3/3)
Aspects statiques : diagramme de classes diagramme d'objets diagramme de déploiement diagramme de composants Aspects dynamiques et fonctionnels : diagramme d'activité diagramme de séquences diagramme d'états-transitions diagramme de collaboration diagramme de cas d'utilisation
Pourquoi utiliser UML ?
UML permet de modéliser tout type de système (avec ou sans logiciel) UML peut être utilisé à toute étape d'un cycle de vie UML est gratuit UML est normalisé Possibilité d’utiliser des AGL, de l’expression des besoins jusqu’à la génération de tout ou partie de l’application (Rational Rose, Objecteering, Power AMC) UML est très utilisé et de plus en plus utilisé par les informaticiens, à la fois pour concevoir mais également pour analyser les besoins des clients. UML fait le café et sort le chien.
9. Diagramme des cas d’utilisation
Diagramme des cas d’utilisation
Objectifs : décrire le système du point de vue de l’utilisateur mettre en évidence les services/fonctionnalités rendus par le système fixer le périmètre entre le système et son environnement Une fonctionnalité peut être décomposée en plusieurs sous-fonctionnalités => différents niveaux de granularité possibles Diagramme des cas d’utilisation : classes acteur + fonctionnalités (cas d’utilisation).
159 Diagramme des cas d’utilisation
Un diagramme des cas d’utilisation rassemble les différentes fonctionnalités pour lesquelles plusieurs scénarios sont possibles. Le diagramme est accompagné d’un texte organisé décrivant les cas d’utilisation et permettant de mettre en évidence les différents scénarios possibles. Un diagramme des cas d’utilisation peut être organisé autour d’un acteur, d’un groupe d’acteur, d’un cas d’utilisation, d’un groupe de cas d’utilisation. Un tel diagramme n’exprime PAS la séquence, l’ordre des traitements.
160 Diagramme des cas d’utilisation : notation graphique - lecture
Gestion des absences
générer avertissements absences Directeur des études
L'acteur directeur des études utilise la fonction « générer avertissements absences » du logiciel Gestion des absences
161 Diagramme des cas d’utilisation : notation graphique - concepts
Gestion des absences
générer avertissements absences Directeur des études
acteur association cas d'utilisation système
162 Diagramme des cas d’utilisation : exemple PowerPoint minimaliste
Créer un PowerPoint
Prof
163 Diagramme des cas d’utilisation : exemple PowerPoint – zoom in
nouveau
ouvrir
éditer
sauver Prof
imprimer
164 Diagramme des cas d’utilisation : relation include
ouvrir
Prof
Une instance du cas d’utilisation « ouvir » <
Sélectionner fichier
165 Diagramme des cas d’utilisation : relation include
Consulter ses comptes
Factorisation du cas « Authentifier »
166 Diagramme des cas d’utilisation : relation extend
Créer un PowerPoint
Prof << extend >>
Créer un PowerPoint à partir d’un modèle prédéfini
Une instance du cas d’utilisation « Créer un PowerPoint » voit son comportement repris et complété par une instance du cas d’utilisation « Créer un PowerPoint à partir d’un modèle prédéfini ». Objectif : mettre en avant une fonctionnalité optionnelle. 167 Diagramme des cas d’utilisation : relation extend
Si non parrainé
Créer compte utilisateur
168 Diagramme des cas d’utilisation : relation de généralisation entre UC
Créer un document Office
Créer un PowerPoint
Prof Créer un Word
Le cas d’utilisation « Créer un document office » est spécialisé par les cas « Créer un PowerPoint » et « Créer un Word ». 169 Diagramme des cas d’utilisation : relation de généralisation entre UC
<< include >> valide commande paiement
Internaute
PayPal
C.B.
170 Diagramme des cas d’utilisation : relation de généralisation entre acteurs
Consulter ses comptes
Est-ce que le client boursicoteur peut consulter ses comptes ? 171 Diagramme des cas d’utilisation : acteurs principaux
partage de fichiers torrent
Internaute
Les fonctionnalités principales du système sont définies pour les acteurs principaux/primaires
172 Diagramme des cas d’utilisation : acteurs secondaires
partage de fichier
Internaute Initial seeder
<
Il est en général nécessaire de réaliser des opérations en amont et en aval des fonctions principales. C'est le rôle des acteurs secondaires. En pratique, les acteurs primaires sont placés à gauche. Il est aussi possible de stéréotyper les associations (primary, secondary). 173 Diagramme de cas d’utilisation : exemple
Nouvelle <
<
Titulaire stagiaire Vérification identification mot de passe rétinienne
174 Documentation des cas d’utilisation
Cas d’utilisation : Consultation du planning des salles. Acteur primaire : L’agent de la mairie. Objectif : Consulter le planning de réservation des salles. Pré conditions : L’agent doit s’identifier par son login. Consulter planning Post conditions : L’agent visualise le planning. Scénario nominal : ... 1. L’agent sélectionne le calendrier de réservation de salles. Généralement la description est 2. … complétée, voire remplacée par un Scénario alternatif : diagramme de séquence … Scénario d’erreur : … 175 Diagramme des cas d’utilisation : en pratique
Il existe 2 types de cas d’utilisations : Un cas d’utilisation “client” : le plus simple possible (peu de relations “extend” ou “include”), proche du listing de fonctionnalités, relation “include” privilégiée par rapport à la relation “extend” (lorsque cela est possible), relation d'héritage souvent utilisée pour simplifier. Un cas d’utilisation “programmeur/développeur” : complète le cas d’utilisation client avec utilisation de tous les types de relation, en particulier les “extend” et “include”. Relation “extend” priviligiée par rapport à l'”include” pour, lorsque cela est possible, traduire la navigation au niveau de l'interface La documentation textuelle d’un cas d’utilisation n’est pas obligatoire : elle peut se faire à l’aide d’un diagramme de séquence (cf. cours suivant).
176 10. Diagramme de séquence
Diagramme de séquence
Objectifs : mettre en évidence les interactions entre les différents objets et visualiser de façon directe l’ordre dans lequel se déroulent les interactions. Détailler un use case. Peut remplacer un diagramme de collaboration. Diagramme de séquence : objets + lignes de vie + temps + messages + axe temporel vertical + activité + notes
178 Les objets
:Interface :Catalogue :Catégorie client
:Client
179 Les lignes de vie et le temps
:Interface :Catalogue :Catégorie client
:Client
temps
180 Les messages
Echangés entre objets, le long de leur ligne de vie, au fil du temps. Plusieurs types de messages : la création ou la destruction d’un objet/d'une instance, l’appel d'une méthode, l’envoi d’un signal.
181 Représentation des messages
message synchrone : on attend la réponse ! Ex. : appel de méthode
Réponse à un message synchrone
message asynchrone : on n'attend PAS la réponse ! Ex. : interruption
<
<
nom(paramètres)
pour tous les types de message, sauf pour les réponses
nom de l'attribut ou de la variable valorisée en retour
Une notation plus complète est disponible (en amphi) pour la réponse mais elle est très peu utilisée.
183 Les messages : exemple
:Interface :Catalogue :Catégorie client
:Client
demande devis(produit,catégorie)
demande prix(produit)
prix
calcul ristourne(catégorie)
taux ristourne montant devis
184 Et dans le code (Java) ?
public class Prix {...} public class Taux{...}
public class Catalogue { ... public Prix demandePrix(int produit) { Prix prixProduit; .... return prixProduit; } ... } public class CatégorieClient { ... public Taux calculRistourne(String catégorie) { Taux tauxRistourne; .... return tauxRistourne; } ... } Et dans le code (Java) ?
public class interfaceAppli() extends JDialog implements ActionListener { ... private Jbutton ok; private Catalogue objetCatalogue; private CategorieClient objetCategorie; ... void interfaceAppli() { ... this.objetCatalogue = new Catalogue(); this.objetCategorie = new CategorieClient();
this.ok = new JButton("ok"); this.ok.addActionListener(this); ...
} public Prix demandeDevis(int produit, String categorie) {Prix devis = this.objetCatalogue.demandePrix(produit)*this.objetCategorie.calculRistourne(categorie);} public void actionPerformed(ActionEvent e) {.. if (e.getSource() == this.ok) { ... Prix devis = demandeDevis(produit,categorie client);
... //affichage } .... } public static void main ( String [] a) { interfaceAppli i = new interfaceAppli();} } 186 Représentation de l'activité des objets
:Interface :Catalogue :Catégorie client
:Client
demande devis(produit,catégorie)
demande prix(produit)
Vérifier produit(produit)
prix
calcul ristourne(catégorie)
taux ristourne montant devis
Dans la pratique, pour le stéréotype acteur, on ne met que la ligne de vie.187 Ajout de condition d'émission des messages
:Interface :Catalogue :Catégorie client
:Client
demande devis(produit,catégorie)
demande prix(produit)
Vérifier produit(produit)
prix
[catégorie != particulier] calcul ristourne(catégorie) [catégorie != particulier] taux ristourne montant devis
188 Les fragments
Les fragments permettent : d'effectuer des choix (opt, alt), de répéter un traitement (loop), de nommer un traitement, d'inclure un traitement déjà défini (ref), d'effectuer des traitements en // (par), d'exécuter certaines instructions, puis de tout arrêter (break). D'autres fragments existent mais ne seront pas vus dans ce cours : ignore, consider, assertion, negative, weak sequencing , strict sequencing.
189 Les fragments : définition
opérateur
... opérande [ ...]
[ ...] opérande
conditions de garde (si vide, alors Vraie)
190 Opt = « if ... then ... >>
:Interface :Catalogue :Catégorie client
:Commercial
demande devis(produit,catégorie) recherche prix(produit)
Vérifier produit(produit)
prix
opt [catégorie != “particulier”] calcul ristourne()
taux ristourne montant devis
191 Alt = « if ... then ... else ...>> ou « switch ... case ... >>
:Interface :Catalogue :Catégorie client
:Commercial
demande devis(produit,catégorie) recherche prix(produit) Vérifier produit(produit) prix
alt calcul ristourne() taux ristourne [prix < 10 000] calcul ristourne exception ()
taux ristourne
montant devis condition vide => « [else] » est considéré 192 Alt = « if ... then ... else ...>> ou « switch ... case ... >>
:Interface :Catalogue :Catégorie client
:Commercial
demande devis(produit,catégorie) recherche prix(produit) Vérifier produit(produit) prix
alt calcul ristourne() taux ristourne [prix > 1000 euros && prix < 10 000] [prix > 10 000 euros] calcul ristourne exception()
taux ristourne
montant devis il est possible d'avoir plus de 2 conditions 193 Loop
:Interface :Catalogue :Catégorie client
:Commercial
demande devis(produits,catégorie)
recherche prix(produit) loop Vérifier produit(produit) [pour chaque produit] prix
calcul ristourne()
taux ristourne montant devis
194 Fragments : nommage
recherche prix
:Interface :Catalogue
recherche prix(produit) loop Vérifier produit(produit) [pour chaque produit] prix
tout diagramme de séquence peut être nommé/référencé à l'aide d'un fragement
195 Ref
:Interface :Catalogue :Catégorie client
:Commercial
demande devis(produits,catégorie)
ref recherche prix
calcul ristourne()
taux ristourne montant devis
196 Par et ref
Par : parallèlisme logique (non physique, peu utilisé), une opérande par traitement parallèlle.
Break : une seule opérande exécutée si la condition de garde est vérifiée. Une fois l'exécution terminée, l'ensemble du diagramme de séquence est stoppé.
197 11. Le diagramme de classes
Les relations entre objets ou classes
Elles représentent des liens statiques/structurels entre objets et à longue durée de vie. Précaution : les associations ne sont en général pas directement supportées par les langages de programmation orienté-objet. Note : les relations décrites ci-après n’adoptent aucun formalisme précis.
199 Relations entre classes ou entre objet
. Généralisation/Spécialisation . modes de transport - avion, train, auto, bateau...
.Associations . Etudiant – cours
.Agrégations & Composition .Groupe – Membres .Assemblage - Parties
200 Agrégation/composition
Relation non symétrique bicyclette Agrégat/agrégé : durée de vie des agrégés indépendante de l'agrégé Roue Guidon Cadre Composite/composant : durée de vie des composants dépendante Rayon Jante Pneu du composite/conteneur - on parle d'embarquement
201 Généralisation/spécialisation
Relation de classification entre un élément plus général et des éléments spécialisés L'élément spécialisé hérite des Trapèze attributs et des opérations et des relations et des contraintes de l'élément dont il est la spécialisation Losange Rectangle L'élément spécialisé peut avoir ses propres attributs, opérations, relations Carré Spécialisation simple ou multiple (C++ le supporte mais pas Java ni Smalltalk).
Un losange vaut 10 euros et un rectangle vaut 20 euros. Combien vaut un carré ? 202 L’héritage Généralisation a1 a2 Généralisation a3 a1 o1 a2 o2 Commun a3 o3 o1 o2 o3 Spécialisation a1 a2 a3 Spécialisation a4 a4 a5 a5 a6 Unique a6 o1 o4 o2 o5 o3 o6 o4 o5 (a = attribute; o = operation) o6 L’héritage multiple
Généralisation1 Généralisation2 a1 a2 a2 a4 a3 a5 o3 o1 o4 o2 o5 o3
Spécialisation a6 a7 a1 a8 a2 (lequel ?) Attributs hérités a3 o6 a4 o1 o7 a5 o2 o8 (laquelle ?) o3 Opérations héritées o4 o5 Les classes abstraites
Les classes que l’on peut instancier sont des classes concrètes.
Les classes abstraites ne peuvent pas être instanciées.
205 Les associations
Elève enseigne Professeur
Lie une ou plusieurs classe. Indique si une classe « connaît » une/d' autre/s classe/s. Elève Professeur
enseigne
206 Diagrammes de classe : les relations
Généralisation Association spécialisation * *
Composition
Agrégation 1
0..* 1..*
0..* toujours “1” 207 Diagrammes de classes : généralisation/spécialisation
Super-type
discriminant
Sous-type 1 Sous-type 2
Note: Super-type = Super-classe; Sous-type = Sous-classe 208 Exemple : généralisation
<
attributs opérations
Visiteur Etudiant Personnel
attributs attributs attributs opérations opérations opérations
Note: <
Personne
attributs opérations
Bras Jambe Tête
attributs attributs attributs opérations opérations opérations
210 Exemple : généralisation
Docteur
{Disjointe} Femme rôle <
A B
# aa : int # dd : int - bb : int + cc() : void + ee() : void
public class A public class B extends A { { protected int aa ; protected int dd ; private int bb ;
public void cc() {...} public void ee() {...} } }
Et dans le code (Java) ?
A {abstract} B
# aa : int # dd : int
+ cc() : void + ee() : void
public abstract class A public class B extends A { { protected int aa ; protected int dd ;
public void cc {...} public abstract void cc(){} public void ee() {...} } }
Interface et implementation d'interface
<
public interface A public class B implements A { { public void cc() {...} protected int dd public void zz() {...} protected int dd } public void cc() {...} public void zz() {...} } Diagramme de classes : les associations
Les associations peuvent avoir deux rôles (2 sens de lecture) : source --> destination destination --> source A chaque rôle correspond une multiplicité (cardinalités) Pour restreindre la navigation dans un sens précis (améliorer la lisibilité), une flèche est utilisée pour représenter la direction de navigation/lecture. Pas d’héritage ! 215 Diagramme de classes : les rôles
rôle B Classe A Classe B rôle A
Exemple:
Employé Entreprise Personne Employeur
216 Diagramme de classes : les multiplicités
1..1 Classe exactement un
0..* Classe zéro ou plus
0..1 Classe zéro ou 1
m..n Classe de m à n
217 Diagrammes de classes : la multiplicité
Class1 max.max. min.min. 1 2..5 1..n 0..* Class2 Class3
Attention au sens de lecture !!! C1 C3 2..5 1..n C2 1 C1 * C1 C3 C2 C3 C1 C2 C1 C3 C1 C2 C1 C3 C2 C1 C3 C2 C3 etc... etc...etc... etc... 218 Exemple : les associations
0..* Client Contrat 1
1..3 Produit Fournisseur 1
Attention au sens de lecture !!!
219 Diagramme de classes : associations réflexives
Cours
0..* est un pré-requis pour
0..*
a pour pré-requis
220 Et dans le code (Java) ?
ra rb A B 1 1
public class A { private B rb … } public class B { private A ra … }
Et dans le code (Java) ?
ra rb A B 1 1
public class A { private B rb …} public class B { ... // La classe B ne connaît pas l'existence de la classe A }
Et dans le code (Java) ?
ra rb A B 1 *
public class A { private ArrayList rb … } public class B { ... // La classe B ne connaît pas l'existence de la classe A }
Et dans le code (Java) ?
ra rb A B 1 *
public class A { private ArrayList rb … } public class B { private A ra …}
Diagrammes de classes : les classes associations
0..* Commande Client Produit n°client 0..* n°produit
Ligne facturée quantité
L’association « commande » est porteuse de la propriété quantité. Cela est traduit par la création d’une classe association « ligne facturée » dont l’attribut est « quantité ». 225 Et dans le code (Java) ?
0..* Commande Client Produit - n°client : int 0..* - n°produit : int
Ligne facturée - quantité : int public class Client { private n°client; private Produit [] a … } public class Produit { private n°produit; private Client [] b …} public class Ligne facturée {... private int quantité; private Client ref-client; private Produit ref-produit; ...} Et dans le code (Java) ?
0..* Commande Client Produit - n°client : int 0..* - n°produit : int
Ligne facturée - quantité : int public class Client { private n°client; private ligne facturée [] l … } public class Produit { private n°produit …} public class Ligne facturée {... private int quantité; private Produit ref-produit; ...}
Diagramme de classes : les associations ternaires
Date n°date
0..*
0..* 0..* Client Produit n°client Commande n°produit
Ligne facturée quantité 228 Diagramme de classes : contraintes sur les associations
développe
Programme {OuX} Individu
recette
Un développeur ne peut effectuer de recette de programme.
229 Diagramme de classes : contraintes sur les associations
assure
Contrat {Sous ensemble} Individu
est contracté
Le contractant est obligatoirement assuré.
230 Diagramme de classes : agrégation et composition
Université Commande
1..* 1
0..* 1..* Cours ligneCommande
231 Et dans le code (Java) ?
Commande public class Commande {...} public classe ligneCommande { ... 1 private Commande ref-co ...} 1..* ligneCommande Attention, à la destruction de Commande, il faudra prévoir de détruire ligneCommande ...
Et dans le code (Java) ?
Université public class Université { ... private ArrayList
Diagramme de classe : la référence
risquePret <
La classe « risque prêt » a besoin d'utiliser la classe client pour fonctionner. Cela correspond généralement au fait que la classe « client » est passée en paramètre d'une méthode de « risque prêt » ou qu'une méthode “risque prêt” l'utilise en variable locale. public class risquePrêt { ... public Boolean calculRisque(Client c) {...} … } ou public class risquePrêt { ... public Boolean calculRisque() {..new Client().} … } 234 12. Diagramme d’états transitions
Diagramme d’états-transitions
Objectifs: représenter les traitements en indiquant les états des instances des classes. Diagramme d’états-transitions : états + transitions + notes Un diagramme d’états-transitions : concerne une seule classe pour laquelle on représente tous les états possibles de ses occurrences ainsi que les transitions entre états.
236 Les états
Rappel : les objets, à un instant donné, sont dans un état. Un état regroupe les valeurs instantanées de tous les attributs d’un objet. Un état évolue au cours du temps. Exemple : une commande peut être « en préparation » (date d’expédition nulle), puis plus tard « en livraison » (date de livraison nulle). Un état peut aussi être défini par la participation de l’objet à une association. Exemple : Une salarié est dans l’état « affecté » s’il est associé à un poste de travail. Un état peut être décomposé en sous-états différents niveaux de granularité possibles
237 Les états : représentation graphique
Etat 1 Etat 2
238 Les transitions Passage d’un état à un autre : transition Une transition est déclenchée par un événement Cet événement doit : faire sens par rapport au domaine étudié et être de fréquence suffisante faire sens pour les instances de la classe étudiée Ex. : décision d'un acteur, résultat d'un processus, événement temporel, appel d'une méthode
239 Les états-transitions : représentation graphique
Evénement Etat 1 Etat 2
240 Exemple : classe police d’assurance
Abandonnée
Refus client Délai expiré Demande client
En souscription signature Ouverte X sinistres Résiliée
Délai expiré Date fin Demande client suspension suspension Demande client Suspendue
241 La condition de garde
X sinistres [nombre = 5] Ouverte Résiliée
La transition peut être soumise à la vérification d’une expression appelée condition de garde.
242 Diagrammes d’états- transitions : les opérations
Les opérations qui définissent les classes peuvent apparaître sur le diagramme d’états-transitions. Elles sont alors appelées actions. Les actions peuvent être associées aux événements et aux états.
243 Les actions et les événements
Si l’on veut que l’action soit déclenchée au moment où l’événement se produit, il suffit de l’indiquer directement sur la transition.
Refus client / Comptabiliser échec En souscription Abandonnée
244 Les actions et les états
Les actions associées aux états sont déclenchées par 3 types d’événements : l’entrée dans l’état la sortie de l’état un événement, appelé transition interne, qui laisse l’objet dans le même état : pour une police en souscription, on peut avoir une événement délai « 1 semaine écoulée » pour la relance du client. 245 Les actions et les états : exemple (1/2)
Lorsqu’une commande entre dans l’état « en préparation », il faut réaliser les actions suivantes : choix du fournisseur, détermination des quantités à commander, valoriser la commande. Durant l’état « en préparation », le fournisseur peut modifier ses tarifs et la commande peut être mise à jour. A la sortie de l’état « en préparation », la date d’expédition est enregistrée et un exemplaire de la commande est envoyé au fournisseur. Si on veut inclure une action qui « dure » pendant tout l’état, alors on parle d’activité. Par exemple, on peut publier le détail, de la commande sur l’intranet pendant l’état « en préparation ». 246 Les actions et les états : exemple (2/2)
L’exemple précédant se note comme suit :
En préparation
On entry/Choisir un fournisseur … … Nouveau tarif/Effectuer la valorisation … On exit/Enregistrer la date d’expédition … Do/Publier le détail de la commande dans l’intranet
247 Remarque sur les actions
Il est possible, à l'aide des actions dans les états, d'exprimer également les actions sur les transitions (à l'aide de « on entry » et « on exit » ).
248 Les états prédéfinis
État initial : obligatoire et unique. L’action déclenchée à la sortie de cet état correspond à la création de l’objet.
État final : non obligatoire et non unique. L’action déclenchée par l’événement aboutissant à cet événement correspond à la destruction ou à l’archivage de l’objet
249 Exemple : classe police d’assurance
Abandonnée
Refus client Délai expiré Archivage Demande client
En souscription signature Ouverte X sinistres Résiliée
Délai expiré Demande client Date fin suspension Création suspension Demande client Suspendue
250 Autre exemple …
Au chômage
Embauche Perte d’emploi
En activité Pas compétence UML Do:travailler() Compétence UML > 60 ans En formation En retraite
251 13. Le MVC (modèle – vue – contrôle)
Exemple application web
V = génère le code HTML.
M = service d’accès aux données (lecture, écriture).
C = met à disposition une fonctionnalité en utilisant M et V.
Le MVC n’interdit pas des connections entre V et M, mais c’est à éviter.
Le MVC 2
V C en chef C fonctionnalité M
… 2 C !
C en chef = front controller
Objectifs MVC/MVC2
Organiser le code pour : organiser la réalisation, faciliter la maintenance corrective et évolutive. Exemple MVC2 : cf. fichier mvc2.pdf.
Frameworks MVC pour le web …
ActionScript/Flex PureMVC, Cairngorm C++ Wt, CppCMS Java Aranea, Cocoon, CodeCharge Studio, JSF, Makumba, Oracle Application Development Framework, Play Framework, PureMVC, Sling, Spring, Struts, Struts2, Stripes, Tapestry, Wavemake, WebObjects, WebWork, Wicket, Web Dynpro Java .NET ASP.NET MVC Framework, Bistro Framework, CodeCharge Studio, Maverick.NET, MonoRail, Naked Objects MVC, PureMVC Framework for C, Spring Framework.NET Perl Catalyst, CodeCharge Studio, Maypole. PHP Agavi, Alloy, CakePHP, CodeCharge Studio, CodeIgniter, Exponent CMS, eZ Publish, Feng Office, Joomla! v1.5.x, Kohana v2.x, MODx, Odin, phpXCore, PureMVC, Qcodo, Recess, SilverStripe, Switch board, Symfony, Yii, Zend, Python Django, Enthought, Pylons, TurboGears, web2py, Zope, Plone, PureMVC Ruby Ruby on Rails, Merb, Ramaze, Camping, Nitro, Monkeybars, PureMVC Framework.