Génie Logiciel Processus de développement &...

1

Génie LogicielProcessus de développement &

Technologies

[email protected]

Module Electif E10SIGLE 2009-2010

dimanche 28 février 2010

mailto:[email protected]

mailto:[email protected]

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


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


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


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é


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


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)


9


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


10


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


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


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


13


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)


14


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)


15


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


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


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


Modélisation

18


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


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

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


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)


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



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



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



26


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


contrainte,évolution,dynamique,procédure,action


27

Liens entre les champs de modélisation


Champ Fonctionnel

Champ Structurel

Action

Quoi,Qui,Capacité

CommentQuand

Comment les choses interagissent pour accomplir une action ?


28

Champs de modélisation et conception


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


29

Un langage graphique : UML


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


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)


32

Principaux modèles d'élément

component

branch

association aggregation composition generalization dependance

fork

synchronization

object

object

persistant object


33

Carte des Diagrammes (UML 2)

Champ Structurel

Champ Fonctionnel


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


34

Catalogue des diagrammes : le diagramme des cas d'utilisation


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


36

Catalogue des diagrammes : le diagramme de déploiement


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


38

Catalogue des diagrammes : le diagramme des composants


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


40

Catalogue des diagrammes : le diagramme des paquetages


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


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


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


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


50

Catalogue des diagrammes : le diagramme de séquence


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


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


55

Catalogue des diagrammes : le diagramme global d'interaction


56

Catalogue des diagrammes : le diagramme d'activités


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


59

Etude préliminaire

Identifier les acteurs (humains ou non)

Identifier les messages (mais pas entre acteurs)

Diagramme de contexte dynamique[diagramme de communication]


60

Etude préliminaire

Identifier le contexte

Diagramme de contexte statique[diagramme des classes]


61

Réflexion

Vous devez concevoir le système d’information de votre école.

Identifiez les acteurs, les messages et le contexte


62

Spécifications



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


64


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)


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


66

Solution


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


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


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,…)


70


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


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


72Carte

Transaction VISA Ressources

Mais non orienté objet a priori


73

Conception et Développement



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


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


76


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é}]


77


Agrégation : association parties/ composites

Composition : agrégation dont le cycle de vie des parties et du composite est lié

Dépendance : lien temporaire


78


Classe d'association


79

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

Interfaces Java et classes abstraites


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


81


Structurer le diagramme suivant en 2 packages

Dessiner le diagrammedes packages correspondant


82


Vols

Réservations

Solution 1 : peu de dépendances


83


Solution 1 : peu de dépendances


84


Vols

Réservations

Solution 2 : mêmes durées de vie


85


Solution 2 : mêmes durées de vie


86


Complexité ⇒ décompositionen coucheslogicielles


87

Du conceptuel au logique : découpage en composants et Framework

Les frameworks peuvent donner naissance à des composants…


88


Composant :module de code

Dépendance


89


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


90

Construction



91

Génération de l’ossature du code


92

Génération de l’ossature du code


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..*


94

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


95

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

conceptuel


Pourquoi des modèles relationnels ?

96

Traduction en Python



97

Traduction en XML Schemadimanche 28 février 2010


98

instance XML : boucle infinie !il faut introduire des référencespour ne pas encapsuler les objets...


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)


100

Les relations binaires

Relation 1-1

Relation 1-n

Relation n-n sans attribut

Relation n-n avec attributs


101

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

Relation n-n réflexive

Relation n-aire réflexive


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


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


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


immatriculation=001

compagnieIDref=2


immatriculation=002

compagnieIDref=2



Association n-n et n-aire : migration des clefs primaires des classes connectées vers l’entité correspondant à la classe d’association

105


106


Propagation des migrations


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


108

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

Association réflexive de type N-N


109


Décomposition des associations de spécialisation (par distinction)


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)


112

Exemple


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



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



A faire :

• Analyse préliminaire• Spécifications• Conception en utilisant des notations OCL• Codage (ossature)

115


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


http://www.omg.org/

http://www.omg.org/

http://uml.free.fr/

http://uml.free.fr/

http://www.w3schools.com/sql/default.asp

http://www.w3schools.com/sql/default.asp

http://www.mysql.com/documentation/index.html

http://www.mysql.com/documentation/index.html

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


Génie Logiciel Processus de développement &...

Documents

Transcript of Génie Logiciel Processus de développement &...