Upload
vuthuan
View
219
Download
0
Embed Size (px)
Citation preview
1
Génie LogicielProcessus de développement &
Technologies
Module Electif E10SIGLE 2009-2010
dimanche 28 février 2010
Programme
Conception et Modélisation (2h)processus de développement & UML
Communication et Web (2h)IP, WEB & services WEB
Modèles de données et XML (2h)XML & schéma
2
dimanche 28 février 2010
4
Conception
Spécification de fonctionnalités
du système
Spécification de acteurs (humains et non humains)
Définition d'un produit-service
Identification des interactions
acteurs / produit-service
Identification des cas d'utilisation
Modélisation du contexte (modèle
conceptuel)
Identification des applications / composants /
paquetages / ...
Modélisation pour l'implé-
mentation (modèle logique)
Implémentation
Validations (tests unitaires* et fonctionnels)
PackagingTechnique de créativitébrainstorming, TRIZ,...
Initialisationspécification
produit-service, esquisses de
business model
ElaborationConstruire quoi et comment ?
Chiffrage et affinage business modelEvaluation des risquesDiagramme de Gantt
* de non-regressionsConstruction
S'entendre et répartirConstruire
tester et démontrer
FinaliserPréparer la livraison
dimanche 28 février 2010
5
Processus de développement normaliser les processus de développement détermine qui fait quoi, quand et comment
atteindre un but (construire ou modifier un logiciel)
quelques idées fondatrices : il faut toujours s’assurer que l’on travaille sur ce qu’il y a de plus important
à faire il faut se coordonner avec les autres (collègues, clients,…) il faut pouvoir prévoir les conséquences d’un événement imprévu il faut minimiser les risques d’échec (itératif et incrémental) il faut que les modèles soient intuitifs (centrés utilisateurs) il faut que les résultats soient maintenable et ré-utilisable
dimanche 28 février 2010
6
Processus de développement Droits du client
droit d’avoir un planning du projet, de savoir ce qui peut être accompli et à quel coût droit d’avoir la plus grande valeur ajoutée chaque semaine de développement droit de voir le projet fonctionner réellement, réussissant différents tests spécifiés par
le client droit de changer d’avis, de modifier des fonctionnalités requises et de changer des
priorités sans payer de coûts exorbitants droit d’être informé des modifications de planning afin de pouvoir réajuster les objectifs
du projet
Droit du développeur droit de savoir ce qui est attendu par le client et des priorités droit de produire du travail de qualité tout le temps droit de recevoir de l’aide des collègues et du client droit d’estimer le travail à fournir et de mettre à jour ces estimations droit d’accepter ou de refuser une responsabilité
dimanche 28 février 2010
7
Comparatif
Formalisme lourdpas de documents types
itératiflarge place à la technologie et à la gestion des risquesdéfinit les profils d’intervenants, les livrables, les plannings, les prototypes
s’articule autour de l’architecturecycle de développement en Ytout projet
2TUP
pas de phase d’analyse (on peut faire pour défaire après)assez flou dans sa mise en œuvre: quels intervenants ? quels livrables ?
itératifsimple à mettre en œuvrelarge place aux aspects techniques : prototype, règle de développementinnovant: priorité à la dynamique de groupe
meilleurs pratiquesprojet – de 10 personnes
XP
coûteux à personnaliseraxé processus et peu développement
itératifspécifie les échanges: livrables, plannings, prototypesdocuments types
promu par Rationalméthodologie et outilsprojets + de 10 personnes
RUP
Points faiblesPoints fortsDescription
dimanche 28 février 2010
8
Rational Unified Process
Repose sur « 6 best practices » : Développement itératif et incrémental Gestion de besoins (client) Conduit à des architectures basées composant Modélisation graphique Vérification de qualité (organisation des plannings, conceptions,
implémentations, exécutions et tests) Gestion des changements dans le logiciel (gestion, contrôle et suivi)
dimanche 28 février 2010
9
Rational Unified Process
Structure du processus de développement :
Initialisation Élaboration Transition1 2 3 4 5…
Construction
BrainstormingRecensement d'idéesAnalyses sommaires
Construire quoi ?Construire comment ?Évaluer le développementIdentifier les risques
Risques liés aux spécificationsRisques technologiques
Risques liés aux compétencesRisques politiques
Construction itérative et incrémentale :- selon les cas d'utilisation- réorganisation du code (refactoring)- Pour chaque itération : analyse, conception, codage, test unitaire, intégration et documentation
OptimisationPackaging
UMLUMLUML
dimanche 28 février 2010
10
Rational Unified Process
Les jalons
Initialisation Élaboration Transition1 2 3 4 5…
Construction
•accord sur les objectifs, les coûts et les dates•besoins clairement compris•estimation clair des coûts/dates
•vision stable du produit•architecture stable•risques majeurs identifiés•planning de construction détaillé et précis•accord coûts/dates/objectifs avec le client
•projet stable et mûr pour un déploiement•client prêt pour le déploiement•accord coûts/dates/objectifs avec le client
•client satisfait•accord coûts/dates/objectifs avec le client
•La frontière entre les 4 phases est floue•Les dates ne sont pas rigides : ce sont des indicateurs
dimanche 28 février 2010
11
Extreme Programming (XP)
Fondements : On développe un projet en effectuant des
réajustements en permanence Séparation claire entre les rôles
les clients (ou ceux qui en jouent le rôle)* prennent les décisions d’affaire : dates, objectifs, priorités*Un bon client comprend le domaine d’application et l’intérêt économique du projet. Il peut prendre des décisions et accepte les conséquences d’un succès ou d’un échec. Il est disponible pour les rendez-vous réguliers
les programmeurs les décisions techniques : estimations
dimanche 28 février 2010
12
Extreme Programming (XP) L’histoire (story) pour synchroniser des cycles :
d’affaire : appel d’offre, réception des « releases », formation, règlement de développement : spécification, conception, implémentation, test,
intégration, déploiement, formation, documentation
Une histoire : représente une fonctionnalité que le client veut s’exprime en termes aussi simples que possible (compréhensible pour le client) doit apporter une valeur au client est issue d’une discussion entre clients et développeurs (itérations) doit être autant que possible indépendante des autres histoires doit être implémentable à cours terme (moins de 3 semaines), estimable et
testable(par exemple : « facile à utiliser » doit être reformulé plus concrètement car non estimable)
ItérationRelease
dimanche 28 février 2010
13
Extreme Programming (XP)
Organisation
1 sem.Classer les vols suivant leurs caractéristiques31 sem. Acheter un ticket42 sem.Faire un profil client51 sem.Montrer tous les itinéraires possibles6
…7
1 sem.Montrer les vols disponibles22 sem.Trouver les 10 vols les moins chers1
EffortStoryPr.
Clie
nts
Prog
ram
meu
rs
Prise en compte des risques techniques (négociation clients – développeurs)
dimanche 28 février 2010
14
Extreme Programming (XP)
Les dates sont non négociables : en cas de problème, on réajuste les objectifs.
coût
qual
ité
tem
ps
obje
ctifs
matériel (apprentissage)personnes (formation)
interne (effets de bord)externe (délicat)
à manipuleren priorité
(non extensible)
Pas assez de temps => diminuer les objectifs
(certaines histoires, celles qui ont le moins de valeur, doivent être supprimées)
dimanche 28 février 2010
15
Extreme Programming (XP)
Une histoire modélisable par un cas d’utilisation
A chaque histoire, des scénarios (diagramme de collaboration)
Mais la modélisation statique et dynamique du projet n’est pas vraiment structurée
dimanche 28 février 2010
16
2 Track Unified Process
Capture desbesoins techniques
Capture desbesoins fonctionnels
Analyse Conceptiongénérique
Conceptionpréliminaire
Conceptiondétaillée
Codage et tests
Recette
Modéliser leproblèmemétier
Définir les technologies nécessaires
Définir l'architecturematérielle et logicielle
Construire unmodèle d'analysedu système
Intégrer le modèled'analyse dans l'architecturetechnique
Conception dechaque composant
Codage et test dechaque composant
Validation de fonctions développées
Modèle de casd'utilisation
Modèle d'analyse
Modèlede conception
Architecturelogicielle
Modèle des besoins techniques
dimanche 28 février 2010
17
Points de vue
Capture desbesoins techniques
Capture desbesoins fonctionnels
Analyse Conceptiongénérique
Conceptionpréliminaire
Conceptiondétaillée
Codage et tests
Recette
Spécificationlogicielle
Matériel
Exploitation
Configurationlogicielle
Déploiement
Fonctionnel
Structurel
Logique
analyste + client
analyste + programmeur
architecte
dimanche 28 février 2010
A quoi sert un langage de modélisation ?
Décrire un contexte Analyser et résoudre un problème
Modéliser un contexte Spécifier des besoins
Echanger / partager
en génie logiciel : Concevoir un logiciel Documenter des solutions techniques Décrire une implantation physique 19
dimanche 28 février 2010
Quel intérêt pour la gestion d’énergie dans le bâtiment ?
Spécifier et Concevoir des systèmes de supervision de l’énergie : modéliser le contexte spécifier des fonctionnalités archiver des données concevoir des protocoles de communication concevoir des architectures logicielles spécifier des interfaces co-concevoir des solutions types 20
dimanche 28 février 2010
21
Différents champs de modélisation
Champ Comportemental
Champ Fonctionnel
Champ Structurel
composants,ressources,variables,objets,unités,paquets,paquetages
fonction,service,fonctionnalité,cas d'utilisation,histoires
contrainte,évolution,dynamique,procédure,action
dimanche 28 février 2010
22
Champ Fonctionnel
Fonction : ce pour quoi une chose est faite (téléologie) -> pas terrible service -> mieux mais reste vague (rendu à qui ?) petite histoire -> encore mieux car orienté utilisateur (vérifiable)
Pour chaque fonction : un intitulé avec un verbe (action) un acteur principal et des acteurs secondaires éventuellement des relations de précédence avec d'autres histoires une description des scénarios caractéristiques de la fonction
Champ Fonctionnel
fonction,service,fonctionnalité,cas d'utilisation,histoires
secondaire(pré-condition)
dimanche 28 février 2010
23
Champ Structurel
Objet : Tout ce qui se présente à la pensée comme ayant valeur de réalité
Pour chaque objet, un nom (sujet) des liens avec d'autres objets des caractéristiques des capacités (ce que l'on peut faire avec l'objet) un type (une classe) : une instance du type variable, une instance du type
composant, une instance du type machine, une instance du type acteur,...
Champ Structurel
composants,ressources,variables,objets,unités,paquets,paquetages
dimanche 28 février 2010
24
Champ Structurel
Existence de différents niveaux d'abstraction (structure type et structure effective)
Héritage = lien de spécialisation (ou généralisation) : différents niveaux d'abstraction
Permet de factoriser certains propriétés, certaines capacités :si un véhicule se déplace et si voiture est une spécialisation de véhicule, alors voiture se déplace
Champ Structurel
composants,ressources,variables,objets,unités,paquets,paquetages
dimanche 28 février 2010
25
Champ structurel
Certains types d'objets peuvent être réunis en une famille (catégories, paquetages ou packages) : même niveau d'abstraction (couche du modèle OSI, solver) même nature (classe d'objets liés à une technologie de communication) même sujet (composants d'une machine)
Cela structure les classes d'objet
Champ Structurel
composants,ressources,variables,objets,unités,paquets,paquetages
dimanche 28 février 2010
26
Champ Comportemental
Comportement : ensemble des observables caractérisant une action
Comportement Statique (caractérisé dans l'instant) et Dynamique (caractérisé sur plusieurs instants : évolution)
Pour chaque comportement, Une relation (ou contrainte) de comportement modélisant l'évolution des
observables
Champ Comportemental
contrainte,évolution,dynamique,procédure,action
dimanche 28 février 2010
27
Liens entre les champs de modélisation
Champ Comportemental
Champ Fonctionnel
Champ Structurel
Action
Quoi,Qui,Capacité
CommentQuand
Comment les choses interagissent pour accomplir une action ?
dimanche 28 février 2010
28
Champs de modélisation et conception
Champ Comportemental
Champ Fonctionnel
Champ Structurel
Pour quoi ?
Quoi,Qui,Capacité
CommentQuand
Lié au cahier des charges évolue avec le temps.
Description de ce qui est : stable dans la durée (complément mais peude remise en cause)!
Lié au cahier des charges évolue avec le temps.
POO
dimanche 28 février 2010
30
La petite histoire d'UML UML a été normalisé par l'Object Management Group
(1.0 en 1997, 1.3 en 2000, 2.0 en 2005) UML unifie les méthodes de De Booch, Rumbaugh
(OMT) et Jacobson Historique
Sally Shlaer et Steve Mellor (1989 et 1991) sur l'analyse et la conception suivi d'un étude sur la "conception récursive" (1997).
Peter Coad et Ed. Yourdon, les approches "allégées" et "orientées prototypes". Voir Coad et Yourdon (1991 a et 1991 b), Coad et Nicola (1993), et Coad et al.(1995).
La communauté Smalltalk développe la conception pilotée par les responsabilités (Wirfs-Brock et al. 1990) et les cartes CRC (Class-Responsibility-Collaboration) (Beck et Cunningham 1989).
Grady Booch chez Rational Software développe des systèmes en Ada. Voir Booch (1994 et 1996).
Jim Rumbauh chez General Electric publie un ouvrage très apprécié sur OMT. Voir Rumbaugh et al. (1991) et Rumbaugh (1996).
Jifn Odell, (1994) ouvrages très conceptuels. Voir Martin et Odell Ivar Jacobson, introduit le concept de cas d'utilisation (use-case). Voir Jacobson (1992 et 1995).
dimanche 28 février 2010
31
UML, c'est quoi ? UML ≠ processus de développement Un langage graphique pour la modélisation orientée objet
(13 diagrammes en UML 2/ 9 en UML 1) UML est composé de :
vues
modèles d'éléments diagrammes
point de vue des acteurs
modèle structurel et conceptuel
modules et dépendances
géographie et architecturephysique
vue temporelle et technique
fonctionnel
structurel
comportemental
structurel
structurel (scénarios)
(physique)
(developpement)
dimanche 28 février 2010
32
Principaux modèles d'élément
component
branch
association aggregation composition generalization dependance
fork
synchronization
object
object
persistant object
dimanche 28 février 2010
33
Carte des Diagrammes (UML 2)
Champ Structurel
Champ Fonctionnel
Champ Comportemental
Orienté Objet
diagramme des classes
Non Objet
Abstraction croissante
diagramme d'objets
diagramme de composants
diagrammes de séquencediagramme d'état-transition
diagramme des cas d'utilisation
diagramme d'activités
diagramme de déploiement
diagramme des paquetagesdiagramme des structures composites
diagrammes de communication
diagramme de temps
diagramme global d'interaction
dimanche 28 février 2010
35
Catalogue des diagrammes : le diagramme des cas d'utilisation
En utilisant StarUML, construire un diagramme des cas d’utilisation qui représente un système de monitoring de la consommation énergie d’étudiants pour la réalisation d’un travail.
Identifier les acteurs Identifier les principaux cas d’utilisation Synthétiser sur un diagramme
dimanche 28 février 2010
37
Catalogue des diagrammes : le diagramme de déploiement
En utilisant StarUML, décrire une salle informatique avec son système de supervision ainsi que les logiciels de monitoring s’exécutant sur les postes de travail étudiant.
utiliser les éléments Node, NodeInstance, part et Port
dimanche 28 février 2010
Catalogue des diagrammes : le diagramme des composants
En utilisant StarUML, modéliser un contrôleur d’éclairage qui peut :
recevoir des ordres d'arrêt, marche complète et marche mi-puissanceenvoyer des mesures d’intensités lumineuses
ainsi qu’un superviseur capable d’interagir avec des contrôleurs d’éclairage
Utiliser des composants, des ports, des interfaces connectés à des ports et des parties (ou composites)
39
dimanche 28 février 2010
Catalogue des diagrammes : le diagramme des paquetages
En utilisant StarUML, représenter les différentes couches du protocole Lonworks.Utiliser des paquetages, des importations et des notes (transport importe transaction,...)
41
dimanche 28 février 2010
Catalogue des diagrammes : le diagramme des structures composites
En utilisant StarUML, représenter une centrale météorologique dotée d’un émetteur, le réseau 433MHz et une station centrale dotée d’un récepteur. Utiliser des classes, des ports et des parties. Comment pourraient être utilisés les interfaces ?
43
dimanche 28 février 2010
Catalogue des diagrammes : le diagramme des classes
En utilisant StarUML, représenter les différentes appartenances d’un étudiant de l’école, le fait qu’il assiste à des séances liées à un cours. Faire apparaître des multiplicités et des attributs.
45
dimanche 28 février 2010
Catalogue des diagrammes : le diagramme d'objets
En utilisant StarUML, représenter une instance particulière du diagramme des classes construit précédemment.
47
dimanche 28 février 2010
48
Catalogue des diagrammes : le diagramme de communication*
* parfois appelé diagramme de collaborationdimanche 28 février 2010
Catalogue des diagrammes : le diagramme de communication*
En utilisant StarUML, représenter une connexion, une requête SQL et une déconnexion d’un superviseur vers une base de données. Utiliser un diagramme de collaboration (Role)
49
dimanche 28 février 2010
Catalogue des diagrammes : le diagramme de séquence
En utilisant StarUML, représenter une connexion, une requête SQL et une déconnexion d’un superviseur vers une base de données. Utiliser un diagramme de séquence (Role)
51
dimanche 28 février 2010
Catalogue des diagrammes : le diagramme d'état-transition
En utilisant StarUML, représenter les différents états d’un contrôleur d’une station météorologique avec un émetteur radio.
53
dimanche 28 février 2010
Catalogue des diagrammes : le diagramme d'activités
En utilisant StarUML, représenter les différents scénarios possibles associés au cas d’utilisation : «se connecteur sur un poste de travail» sachant qu’un superviseur doit être notifié.
57
dimanche 28 février 2010
59
Etude préliminaire
Identifier les acteurs (humains ou non)
Identifier les messages (mais pas entre acteurs)
Diagramme de contexte dynamique[diagramme de communication]
dimanche 28 février 2010
60
Etude préliminaire
Identifier le contexte
Diagramme de contexte statique[diagramme des classes]
dimanche 28 février 2010
61
Réflexion
Vous devez concevoir le système d’information de votre école.
Identifiez les acteurs, les messages et le contexte
dimanche 28 février 2010
63
Diagramme des cas d'utilisation
Cas d'utilisation : Séquence d'actions produisant une valeur ajoutée fonctionnelle pour un acteur ou manière spécifique d’utiliser un système ou image d’une fonctionnalité ou d’un service demandé
Chaque cas d'utilisation doit produire une valeur ajoutée significative (éviter les granularités trop fines : le service réunit généralement tout un ensemble d'actions élémentaires)
Les itérations doivent être définies / au cas d'utilisation
dimanche 28 février 2010
64
Diagramme des cas d'utilisation
Acteur
Include : permet d'éviter les répétitions entre plusieurs cas d'utilisationGénéralisation/Spécialisation : permet de « spécialiser »
Extend : permet de décrire simplement des variantes de comportement optionnelle (condition d’activation à préciser)
dimanche 28 février 2010
65
Exemple
Dessiner un diagramme des cas d'utilisation pour un logiciel destiné à un distributeur bancaire permettant : Retirer de l'argent Consulter le compte associé à la carte Déposer des chèques ou de l'argent
dimanche 28 février 2010
67
Capture des besoins fonctionnels
Construire un diagramme des cas d'utilisation en recherchant les intentions métiers des acteurs et les services attendus
Distinguer acteur principal (qui bénéficie de la plus-value métier) des acteurs secondaires (qui peuvent être sollicité)
Un cas d'utilisation comporte : Un acteur principal Éventuellement des
acteurs secondaires
dimanche 28 février 2010
68
Capture des cas d'utilisation techniques
Cas d'utilisation technique : conduit à une valeur ajoutée opérationnelle ou technique
Exploitant : acteur bénéficiant des fonctionnalités techniques
dimanche 28 février 2010
69
Capture des besoins fonctionnels Décrire les différents enchaînements du cas
d'utilisation :
Les scénarios peuvent être synthétisés par : Des diagrammes d'activités (plus naturels) Des diagrammes d'état-transitions (orientés évènements)
Pour documenter un scénario particulier Des diagrammes des séquences (plus intuitif et précis) Des diagrammes de collaborations
Nom du Cas d'UtilisationDescription - du but : …- des pré-conditions : …(conditions qui doivent vérifiées avant le début du CU)- des enchaînements nominaux : …(avec renvois vers exceptions)- des enchaînements alternatifs : …(avec renvoi vers exceptions)- des exceptions : …- des post-conditions : …(conditions qui doivent vérifiées à l'issu du CU)- des besoins d'IHM : …(ce qu'il doit être possible de faire via l'IHM)- des contraintes non-fonctionnelles : …(temps de réponse du logiciel, gestion des accès concurrents,…)
dimanche 28 février 2010
70
Diagramme des cas d'utilisation
Un cas d'utilisation recouvre plusieurs enchaînements (scénarios) possibles : Enchaînements normaux Enchaînements alternatifs Exceptions
dimanche 28 février 2010
71
Diagramme d'activité
Intérêts : représentationd'activitésséquentielsavecparallélisme(cf. organigramme)
Activité
Action
Fork (Débranchement)
Jonction
Branchement conditionnel
Activité : complexe, décomposable et pouvant être interrompueAction : simple, non décomposable et atomique
dimanche 28 février 2010
74
Modèle Conceptuel : diagramme des classes candidates
Recherche des classes candidates à partir des objets métiers
(ex: agenda, réservation, enseignant,…)Vérifier les propriétés objets de chaque concept (identité, comportement,
responsabilités (5 au plus))
On construit alors un diagramme des classes participantes pour chaque cas d'utilisation
dimanche 28 février 2010
75
Du conceptuel au logique : affinage du diagramme des classes
typage des propriétés
navigabilités & réduction des dépendances
optimisations spécifiques au langage
dimanche 28 février 2010
76
Du conceptuel au logique : affinage du diagramme des classes
Les autres informationsPropriété : {frozen}, {ordered},{addOnly}
Multiplicité
Type
Attribut de classe
Valeur initiale
[visibilité] nom [multiplicité] [:type] [=val_init] [{propriété}]
Visibilité
Contrainte
[visibilité] nom [(liste_param)] [:type_retour] [{propriété}]
dimanche 28 février 2010
77
Du conceptuel au logique : affinage du diagramme des classes
Agrégation : association parties/ composites
Composition : agrégation dont le cycle de vie des parties et du composite est lié
Dépendance : lien temporaire
dimanche 28 février 2010
78
Du conceptuel au logique : affinage du diagramme des classes
Classe d'association
dimanche 28 février 2010
79
Du conceptuel au logique : Spécification des interfaces et des classes de façade
Interfaces Java et classes abstraites
dimanche 28 février 2010
80
Du conceptuel au logique : découpage en catégories
Rôle du découpage en catégories : Organiser les équipes d'analystes Maîtriser la complexité Assurer l'évolutivité et la maintenance
Critères de regroupement Forte Cohérence interne
Finalité en terme de services Evolution (catégories stables
et catégories moins stables) Durée de vie des objets
Faible couplage externe Minimiser les dépendances
dimanche 28 février 2010
81
Du conceptuel au logique : découpage en catégories
Structurer le diagramme suivant en 2 packages
Dessiner le diagrammedes packages correspondant
dimanche 28 février 2010
82
Du conceptuel au logique : découpage en catégories
Vols
Réservations
Solution 1 : peu de dépendances
dimanche 28 février 2010
83
Du conceptuel au logique : découpage en catégories
Solution 1 : peu de dépendances
dimanche 28 février 2010
84
Du conceptuel au logique : découpage en catégories
Vols
Réservations
Solution 2 : mêmes durées de vie
dimanche 28 février 2010
85
Du conceptuel au logique : découpage en catégories
Solution 2 : mêmes durées de vie
dimanche 28 février 2010
86
Du conceptuel au logique : découpage en catégories
Complexité ⇒ décompositionen coucheslogicielles
dimanche 28 février 2010
87
Du conceptuel au logique : découpage en composants et Framework
Les frameworks peuvent donner naissance à des composants…
dimanche 28 février 2010
88
Du conceptuel au logique : découpage en composants et Framework
Composant :module de code
Dépendance
dimanche 28 février 2010
89
Du conceptuel au logique : découpage en composants et Framework
Spécifications d'architecture Composant d'exploitation :
assure un service logicielle repérable et interchangeableex: base de donnée centrale, serveur http, application centrale…
Composant métier :assure un service associé à un objet métier (composant d'exploitation spécialisé)ex: application comptable, application de gestion des stocks
Diagramme de composants
dimanche 28 février 2010
Exercice
Donner les codes Python du diagramme suivant :
93
-nom : String-prenom : String#envoyerCourriel(message : String)#__init__()
Ind iv idu
-service : String-fonction : String#estMute(nouveauService : String)#__init__()
Employe
-societe : String-adresse : String#passeCommande() : Commande#__init__()
Client
-date : String-livraison : String-certification : String#regle(montany : double, modePaiement : String)#__init__()#certifie(password : String)
Commande
theClient
theCommande
1
0..*
theClient
theCommande
1
0..*
dimanche 28 février 2010
95
Pourquoi des modèles relationnels ? Problème lors de la sérialisation d’un modèle
conceptuel
dimanche 28 février 2010
Pourquoi des modèles relationnels ?
98
instance XML : boucle infinie !il faut introduire des référencespour ne pas encapsuler les objets...
dimanche 28 février 2010
99
Notion d'identifiant
Une classe (modèleconceptuel) devient une entité (modèle relationnel)
Identifiant : un ou deplusieurs attributsidentifiant un objet demanière unique
Les identifiants (modèleconceptuel) deviennent des clefs candidates (modèle relationnel)
dimanche 28 février 2010
100
Les relations binaires
Relation 1-1
Relation 1-n
Relation n-n sans attribut
Relation n-n avec attributs
dimanche 28 février 2010
101
Les relations réflexives Relation 1-n réflexive
Relation n-n réflexive
Relation n-aire réflexive
dimanche 28 février 2010
102
Du conceptuel au relationnel
Transformation des classes Chaque classe devient une entité ou une relation. Si nécessaire, ajout d’identifiants
Transformation des associations Associations 1-n simples : migration de 1 vers n les identifiants deviennent des clefs equipement1:Equipement
nom=radiateur gauche
equipementID=1
serviceIDref=1
equipement2:Equipement
nom=radiateur droite
equipementID=2
serviceIDref=1
service1:Service
nom=chauffage
serviceID=1
clef étrangère clef primairedimanche 28 février 2010
Du conceptuel au relationnel
Transformation des associations Associations 1-n avec cycles de vie liés : migration de 1 vers n avec clef
étrangère intégrant la clef primaire les identifiants deviennent des clefs
103clef primaire
dimanche 28 février 2010
104
Du conceptuel au relationnel Association n-n et n-aire : migration des clefs primaires des classes
connectées vers une nouvelle entité
avion1:Avion
immatriculation=001
type=cargo
avion2:Avion
immatriculation=002
type=ligne
compagnie1:Compagnie
nom=comp1
compagnieID=1
compagnie1:Compagnie
nom=comp2
compagnieID=2
affretage1:Affretage
immatriculation=001
compagnieIDref=1
affretage1:Affretage
immatriculation=001
compagnieIDref=2
affretage1:Affretage
immatriculation=002
compagnieIDref=2
dimanche 28 février 2010
Du conceptuel au relationnel
Association n-n et n-aire : migration des clefs primaires des classes connectées vers l’entité correspondant à la classe d’association
105
dimanche 28 février 2010
107
Du conceptuel au relationnel Association 1-1
Multiplicité minimale = 1 : fusion des classes Multiplicité minimale = 0 : migration d'une clef primaire vers l'autre relation Une des multiplicité minimale est à 0 : migration de la clef primaire vers la
classe de multiplicité minimale nulle
dimanche 28 février 2010
108
Du conceptuel au relationnel Association réflexive de type 1-N
Association réflexive de type N-N
dimanche 28 février 2010
109
Du conceptuel au relationnel
Décomposition des associations de spécialisation (par distinction)
dimanche 28 février 2010
Application
Construire un modèle relationnel correspondant au diagramme suivant :
110
dimanche 28 février 2010
111
Conclusion UML de Martin Fowler (Campus Press, 2000) UML par la pratique de Pascal Roques (Eyrolles, 2002) UML en action de Pascal Roques (Eyrolles, 2003) Planning extreme programming de Kent Beck et Martin
Fowler (Addison Wesley, 2000) UML 2 et les design patterns de Craig Larman (Pearson
Education, 2005) De UML à SQL de Christian Soutou (Eyrolles, 2002) MDA en action de X. Blanc (Eyrolles, 2005)
dimanche 28 février 2010
113
Conception d’un système de supervision
Conception d'un système de monitoring et de délestage dynamique pour la salle PREDISDes équipements électriques :
éclairage de fond éclairage local PC stockage Chauffage Panneau PV EDF ...
Des services : utilisateurs intermédiaires supports
dimanche 28 février 2010
Conception d’un système de supervision
Des capteurs : température rayonnement solaire luminosité présence puissance électrique ...
Des actionneurs : commande des lampes de fond commande des lampes de bureau régulation de température / zone afficheur PC
114
dimanche 28 février 2010
Conception d’un système de supervision
A faire :
• Analyse préliminaire• Spécifications• Conception en utilisant des notations OCL• Codage (ossature)
115
dimanche 28 février 2010
116
Conclusion http://www.omg.org http://uml.free.fr Martin Fowler et al. (2004). UML 2.0, ISBN
2-7440-1713-2 UML 2 - Modéliser une application Web - Pascal Roques,
Eyrolles 2007, ISBN 2-212-12136-9 Des bases de données à l'Internet de Philippe Mathieu
chez Vuibert (2000) De UML à SQL de Christian Soutou chez Eyrolles (2002) http://www.w3schools.com/sql/default.asp http://www.mysql.com/documentation/index.html
dimanche 28 février 2010
117
Conclusion
MDA distilled de S. J. Mellor, K. Scott, A. Uhl, D. Weise (Addison-Wesley, 2004)
Eclipse Modeling Framework de F. Budinsky, D. Steinberg, E. Merks, R. Ellersick, T. J. Grose (Addison-Wesley, 2007)
Mastering XMI de T. J. Grose, G.C. Doney, S.A. Brodsky (John Wiley & sons, 2002)
starUML* Poséidon Rational Rose
Dia ...Visual Paradigm
dimanche 28 février 2010