Génie Logiciel Processus de développement & Technologies

Transcription

1 Module Electif E10 SIGLE Génie Logiciel Processus de développement & Technologies 1

2 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

3 Conception 3

4 Conception Technique de créativité brainstorming, TRIZ,... Définition d'un produit-service Finaliser Préparer la livraison Packaging Spécification de acteurs (humains et non humains) Validations (tests unitaires* et fonctionnels) Initialisation spécification produit-service, esquisses de business model Spécification de fonctionnalités du système Identification des interactions acteurs / produitservice Identification des cas d'utilisation Construction S'entendre et répartir Construire tester et démontrer Elaboration Construire quoi et comment? Chiffrage et affinage business model Evaluation des risques Diagramme de Gantt Modélisation du contexte (modèle conceptuel) * de non-regressions Modélisation pour l'implémentation (modèle logique) Identification des applications / composants / paquetages /... Implémentation 4

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 5

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é 6

7 Comparatif Description Points forts Points faibles RUP promu par Rational méthodologie et outils projets + de 10 personnes itératif spécifie les échanges: livrables, plannings, prototypes documents types coûteux à personnaliser axé processus et peu développement XP meilleurs pratiques projet de 10 personnes itératif simple à mettre en œuvre large place aux aspects techniques : prototype, règle de développement innovant: priorité à la dynamique de groupe pas de phase d analyse (on peut faire pour défaire après) assez flou dans sa mise en œuvre: quels intervenants? quels livrables? 2TUP s articule autour de l architecture cycle de développement en Y tout projet itératif large place à la technologie et à la gestion des risques définit les profils d intervenants, les livrables, les plannings, les prototypes Formalisme lourd pas de documents types 7

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) 8

9 Rational Unified Process Structure du processus de développement : Risques liés aux spécifications Risques technologiques Risques liés aux compétences Risques politiques Construire quoi? Construire comment? Évaluer le développement Identifier les risques Construction Optimisation Packaging Initialisation Élaboration Transition UML UML UML Brainstorming Construction itérative et incrémentale : Recensement d'idées - selon les cas d'utilisation Analyses sommaires - réorganisation du code (refactoring) - Pour chaque itération : analyse, conception, codage, test unitaire, intégration et documentation 9

10 Les jalons Rational Unified Process La frontière entre les 4 phases est floue Les dates ne sont pas rigides : ce sont des indicateurs Construction Initialisation Élaboration Transition accord sur les objectifs, les coûts et les dates besoins clairement compris estimation clair des coûts/dates projet stable et mûr pour un déploiement client prêt pour le déploiement accord coûts/dates/objectifs avec le client 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 client satisfait accord coûts/dates/objectifs avec le client 10

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 11

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 Release Itération 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) 12

13 Extreme Programming (XP) Organisation Prise en compte des risques techniques (négociation clients développeurs) Pr. Story Effort Clients Trouver les 10 vols les moins chers Montrer les vols disponibles Classer les vols suivant leurs caractéristiques Acheter un ticket Faire un profil client 2 sem. 1 sem. 1 sem. 1 sem. 2 sem. Programmeurs 6 Montrer tous les itinéraires possibles 1 sem. 7 13

14 Extreme Programming (XP) Les dates sont non négociables : en cas de problème, on réajuste les objectifs. interne (effets de bord) externe (délicat) matériel (apprentissage) personnes (formation) coût qualité temps (non extensible) objectifs à manipuler en priorité Pas assez de temps => diminuer les objectifs (certaines histoires, celles qui ont le moins de valeur, doivent être supprimées) 14

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 15

16 2 Track Unified Process Modéliser le problème métier Capture des besoins fonctionnels Modèle de cas d'utilisation Construire un modèle d'analyse du système Recette Analyse Modèle d'analyse Modèle de conception Conception détaillée Codage et tests Conception préliminaire Capture des besoins techniques Conception générique Architecture logicielle Définir les technologies nécessaires Définir l'architecture matérielle et logicielle Intégrer le modèle d'analyse dans l'architecture technique Conception de chaque composant Codage et test de chaque composant Modèle des besoins techniques Validation de fonctions développées 16

17 Points de vue analyste + client Fonctionnel Capture des besoins fonctionnels Structurel Analyse Capture des besoins techniques Conception générique Spécification logicielle architecte Matériel analyste + programmeur Logique Conception détaillée Codage et tests Conception préliminaire Exploitation Configuration logicielle Déploiement Recette 17

18 Modélisation 18

19 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

20 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

21 Différents champs de modélisation fonction, service, fonctionnalité, cas d'utilisation, histoires Champ Fonctionnel composants, ressources, variables, objets, unités, paquets, paquetages Champ Structurel contrainte, évolution, dynamique, procédure, action Champ Comportemental 21

22 Champ Fonctionnel fonction, service, fonctionnalité, cas d'utilisation, histoires Champ Fonctionnel Fonction : secondaire (pré-condition) 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 22

23 Champ Structurel composants, ressources, variables, objets, unités, paquets, paquetages 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 Champ Structurel 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,... 23

24 Champ Structurel composants, ressources, variables, objets, unités, paquets, paquetages 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 24

25 Champ structurel composants, ressources, variables, objets, unités, paquets, paquetages 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 25

26 Champ Comportemental contrainte, évolution, dynamique, procédure, action 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 26

27 Liens entre les champs de modélisation Action Champ Fonctionnel Quoi, Qui, Capacité Champ Structurel Comment Quand Champ Comportemental Comment les choses interagissent pour accomplir une action? 27

28 Champs de modélisation et conception Pour quoi? Champ Fonctionnel Lié au cahier des charges évolue avec le temps. Quoi, Qui, Capacité Champ Structurel POO Description de ce qui est : stable dans la durée (complément mais peu de remise en cause)! Comment Quand Champ Comportemental Lié au cahier des charges évolue avec le temps. 28

29 Un langage graphique : UML 29

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). 30

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 structurel (developpement) structurel (scénarios) (physique) modèles d'éléments diagrammes structurel fonctionnel comportemental modèle structurel et conceptuel modules et dépendances point de vue des acteurs vue temporelle et technique géographie et architecture physique 31

32 Principaux modèles d'élément component branch fork object object persistant object association aggregation composition generalization dependance synchronization 32

33 Carte des Diagrammes (UML 2) Abstraction croissante Champ Fonctionnel Champ Structurel diagramme des cas d'utilisation diagramme de déploiement diagramme de composants diagramme des paquetages diagramme des structures composites diagramme des classes diagramme d'objets Champ Comportemental diagrammes de communication diagrammes de séquence diagramme d'état-transition diagramme de temps diagramme global d'interaction diagramme d'activités Orienté Objet Non Objet 33

34 Catalogue des diagrammes : le diagramme des cas d'utilisation 34

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 35

36 Catalogue des diagrammes : le diagramme de déploiement 36

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 37

38 Catalogue des diagrammes : le diagramme des composants 38

39 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-puissance envoyer 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

40 Catalogue des diagrammes : le diagramme des paquetages 40

41 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

42 Catalogue des diagrammes : le diagramme des structures composites 42

43 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

44 Catalogue des diagrammes : le diagramme des classes 44

45 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

46 Catalogue des diagrammes : le diagramme d'objets 46

47 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

48 Catalogue des diagrammes : le diagramme de communication* * parfois appelé diagramme de collaboration 48

49 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

50 Catalogue des diagrammes : le diagramme de séquence 50

51 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

52 Catalogue des diagrammes : le diagramme d'état-transition 52

53 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

54 Catalogue des diagrammes : le diagramme de temps 54

55 Catalogue des diagrammes : le diagramme global d'interaction 55

56 Catalogue des diagrammes : le diagramme d'activités 56

57 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

58 Conception & Modélisation Analyse préliminaire 58

59 Etude préliminaire Identifier les acteurs (humains ou non) Identifier les messages (mais pas entre acteurs) Diagramme de contexte dynamique [diagramme de communication] 59

60 Etude préliminaire Identifier le contexte Diagramme de contexte statique [diagramme des classes] 60

61 Réflexion Vous devez concevoir le système d information de votre école. Identifiez les acteurs, les messages et le contexte 61

62 Conception & Modélisation Spécifications 62

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 63

64 Diagramme des cas d'utilisation Acteur Include : permet d'éviter les répétitions entre plusieurs cas d'utilisation Généralisation/Spécialisation : permet de «spécialiser» Extend : permet de décrire simplement des variantes de comportement optionnelle (condition d activation à préciser) 64

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 65

66 Solution 66

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 67

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 68

69 Capture des besoins fonctionnels Décrire les différents enchaînements du cas d'utilisation : Nom du Cas d'utilisation Description - 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, ) 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 69

70 Diagramme des cas d'utilisation Un cas d'utilisation recouvre plusieurs enchaînements (scénarios) possibles : Enchaînements normaux Enchaînements alternatifs Exceptions 70

71 Diagramme d'activité Intérêts : représentation d'activités séquentiels avec parallélisme (cf. organigramme) Activité Branchement conditionnel Fork (Débranchement) Action Activité : complexe, décomposable et pouvant être interrompue Action : simple, non décomposable et atomique Jonction 71

72 Mais non orienté objet a priori Carte Transaction VISA Ressources 72

73 Conception & Modélisation Conception et Développement 73

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 74

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 75

76 Du conceptuel au logique : affinage du diagramme des classes Les autres informations Visibilité Propriété : {frozen}, {ordered},{addonly} Valeur initiale Type Attribut de classe [visibilité] nom [multiplicité] [:type] [=val_init] [{propriété}] Multiplicité Contrainte [visibilité] nom [(liste_param)] [:type_retour] [{propriété}] 76

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 77

78 Du conceptuel au logique : affinage du diagramme des classes Classe d'association 78

79 Du conceptuel au logique : Spécification des interfaces et des classes de façade Interfaces Java et classes abstraites 79

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 80

81 Du conceptuel au logique : découpage en catégories Structurer le diagramme suivant en 2 packages Dessiner le diagramme des packages correspondant 81

82 Du conceptuel au logique : découpage en catégories Solution 1 : peu de dépendances Vols Réservations 82

83 Du conceptuel au logique : découpage en catégories Solution 1 : peu de dépendances 83

84 Du conceptuel au logique : découpage en catégories Solution 2 : mêmes durées de vie Vols Réservations 84

85 Du conceptuel au logique : découpage en catégories Solution 2 : mêmes durées de vie 85

86 Du conceptuel au logique : découpage en catégories Complexité décomposition en couches logicielles 86

87 Du conceptuel au logique : découpage en composants et Framework Les frameworks peuvent donner naissance à des composants 87

88 Du conceptuel au logique : découpage en composants et Framework Composant : module de code Dépendance 88

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 interchangeable ex: 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 89

90 Conception & Modélisation Construction 90

91 Génération de l ossature du code 91

92 Génération de l ossature du code 92

93 Exercice Donner les codes Python du diagramme suivant : Individu -nom : String -prenom : String #envoyercourriel(message : String) # init () Employe -service : String -fonction : String #estmute(nouveauservice : String) # init () Client -societe : String -adresse : String #passecommande() : Commande # init () theclient 1 0..* thecommande Commande -date : String -livraison : String -certification : String #regle(montany : double, modepaiement : String) # init () #certifie(password : String) 93

94 Transformation d un modèle conceptuel en un modèle relationnel 94

95 Pourquoi des modèles relationnels? Problème lors de la sérialisation d un modèle conceptuel 95

96 Pourquoi des modèles relationnels? Traduction en Python 96

97 Pourquoi des modèles relationnels? Traduction en XML Schema 97

98 Pourquoi des modèles relationnels? instance XML : boucle infinie! il faut introduire des références pour ne pas encapsuler les objets... 98

99 Notion d'identifiant Une classe (modèle conceptuel) devient une entité (modèle relationnel) Identifiant : un ou de plusieurs attributs identifiant un objet de manière unique Les identifiants (modèle conceptuel) deviennent des clefs candidates (modèle relationnel) 99

100 Les relations binaires Relation 1-1 Relation 1-n Relation n-n sans attribut Relation n-n avec attributs 100

101 Les relations réflexives Relation 1-n réflexive Relation n-n réflexive Relation n-aire réflexive 101

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 service1:service nom=chauffage serviceid=1 equipement2:equipement nom=radiateur droite equipementid=2 serviceidref=1 clef étrangère clef primaire 102

103 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 clef primaire 103

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 affretage1:affretage immatriculation=001 compagnieidref=1 compagnie1:compagnie nom=comp1 compagnieid=1 affretage1:affretage immatriculation=001 compagnieidref=2 avion2:avion immatriculation=002 type=ligne affretage1:affretage immatriculation=002 compagnieidref=2 compagnie1:compagnie nom=comp2 compagnieid=2 104

105 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

106 Du conceptuel au relationnel Propagation des migrations 106

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 107

108 Du conceptuel au relationnel Association réflexive de type 1-N Association réflexive de type N-N 108

109 Du conceptuel au relationnel Décomposition des associations de spécialisation (par distinction) 109

110 Application Construire un modèle relationnel correspondant au diagramme suivant : 110

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) 111

112 Exemple 112

113 Conception d un système de supervision Conception d'un système de monitoring et de délestage dynamique pour la salle PREDIS Des équipements électriques : éclairage de fond éclairage local PC stockage Chauffage Panneau PV EDF... Des services : utilisateurs intermédiaires supports 113

114 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

115 A faire : Conception d un système de supervision Analyse préliminaire Spécifications Conception en utilisant des notations OCL Codage (ossature) 115

116 Conclusion Martin Fowler et al. (2004). UML 2.0, ISBN UML 2 - Modéliser une application Web - Pascal Roques, Eyrolles 2007, ISBN Des bases de données à l'internet de Philippe Mathieu chez Vuibert (2000) De UML à SQL de Christian Soutou chez Eyrolles (2002)

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