La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Méthodologie objet UML et RUP : un survol IUP GMI 2ième année 2005/2006 M HuchardT. Libourel

Présentations similaires


Présentation au sujet: "Méthodologie objet UML et RUP : un survol IUP GMI 2ième année 2005/2006 M HuchardT. Libourel"— Transcription de la présentation:

1 Méthodologie objet UML et RUP : un survol IUP GMI 2ième année 2005/2006 M HuchardT. Libourel

2 Plan Cours 3 Modèle dynamique Modèle dimplémentation Cours 1 Introduction Présentation dUML Modèle fonctionnel (utilisation) Cours 2 Modèle structurel ANNEXES Projection vers les Bases de Données Projection vers la programmation Méthodologie (RUP)

3 Plan Cours 1 Introduction Présentation dUML Modèle fonctionnel (utilisation)

4 Introduction Modélisation Produire une représentation simplifiée du monde réel pour : accumuler et organiser des connaissances, décrire un problème, trouver et exprimer une solution, raisonner, calculer.

5 Introduction En informatique, Résoudre le hiatus entre : le réel le monde informatique Évolutif Ambiguïté Langages codifiés Sémantique unique

6 Introduction Difficultés de la modélisation Problèmes des spécifications parfois imprécises, incomplètes, ou incohérentes Taille et complexité des systèmes importantes et croissantes les besoins et les fonctionnalités augmentent la technologie évolue rapidement les architectures se diversifient assurer linterface avec le métier (domaine dapplication)

7 Évolution des applications évolution des besoins des utilisateurs réorientation de l'application évolution de l'environnement technique (matériel et logiciel) Problèmes liés à la gestion des équipes taille croissante des équipes spécialisation technique spécialisation métier Introduction Difficultés de la modélisation

8 Introduction Les méthodes = des guides structurants Décomposition du travail Organisation des phases Concepts fondateurs Représentations semi-formelles Assurent une démarche reproductible pour obtenir des résultats fiables

9 Introduction Décomposition du travail Phases analyse, conception, codage, validation, etc. Niveaux dabstraction conceptuel (besoins) logique (solution informatique abstraite) physique (solution informatique concrète)

10 Introduction Organisation du travail Processus de développement Phases séquentielles Itération sur les phases

11 Introduction Concepts fondateurs Fondent lapproche du problème et lexpression de la solution Classe, signal, état, fonction, etc.

12 Introduction Représentations semi-formelles Représentations partiellement codifiées basées sur les concepts fondateurs diagrammes, formulaires, etc. Support de différentes activités réflexion, spécification, communication, documentation, mémorisation (trace)

13 Une méthode danalyse et de conception propose une démarche qui distingue les étapes du développement dans le cycle de vie du logiciel (modularité, réduction de la complexité, réutilisabilité éventuelle, abstraction) sappuie sur un formalisme de représentation qui facilite la communication, lorganisation et la vérification Le langage de modélisation produit des documents (modèles) qui facilitent les retours sur conception et lévolution des applications Introduction Pour résumer …

14 Plan Cours 1 Introduction Présentation dUML Modèle fonctionnel (utilisation)

15 Langage de modélisation véhiculant en particulier les concepts des approches par objets classe, instance, classification, etc. mais intégrant dautres aspects associations, fonctionnalités, événements, états, séquences, etc. UML - Unified Modeling Language

16 Simplicité Facilité pour coder et réutiliser Modèle plus proche de la réalité –description plus précise des combinaisons (données, opérations) –décomposition basée sur classification naturelle –facile à comprendre et à maintenir Stabilité –de petites évolutions peuvent être prises en compte sans changements massifs UML = Bénéficier des qualités des approches par objets

17 Omniprésence technique de lObjet dans les langages de programmation, les bases de données, les interfaces graphiques,... et les méthodes danalyse et de conception. Universalité de lObjet la notion dobjet, plus proche du monde réel, est compréhensible par tous et facilite la communication entre tous les intervenants dun projet. La portée dUML sexplique par limportance de lapproche par objets

18 Au début des années 90, une cinquantaine de méthodes objet, liées uniquement par un consensus autour didées communes (objets, classes, sous-systèmes,...) Recherche dun langage commun unique utilisable par toute méthode objet dans toutes les phases du cycle de vie, compatible avec les techniques de réalisation actuelles. Genèse dUML

19 UML (Unified Modeling Language) OOD (Booch) OMT (Rumbaugh) OOSE (Jacobson) OOPSLA OMG UML Autres

20 Autres méthodesBooch91OMT-1OOSEPartenaires Booch93OMT-2 OOPSLA95 Unified Method 0.8 Commentaires du public UML 0.9 & 0.91 Juin 96 puis OOPSLA96 UML 1.0 Soumission à lOMG - Janvier 97 UML 1.1 UML 1.2 UML 1.3 Standardisation à lOMG - Novembre 97 Version intermédiaire non publiée Version béta - fin 99 UML

21 Vue Cas dutilisation Vue structurelle Vue architecture (déploiement) Vue dynamique Points de vue sur le système Concepts généraux Vue implémentation

22 Modèle Implémentation Modèle Dynamique Modèle structurel Quatre modèles pour concrétiser ces points de vue Types d'objets et leurs relations Stimuli des objets et leurs réponses Modèle dutilisation Concepts généraux Composants Fichiers BD Projection sur le matériel Fonctionnalités

23 Chaque modèle est une représentation abstraite d une réalité, il fournit une image simplifiée du monde réel selon un point de vue. Il permet : - de comprendre et visualiser (en réduisant la complexité) - de communiquer (à partir dun « langage » commun à travers un nombre restreint de concepts) - de valider (contrôle de la cohérence, simuler, tester …) Concepts généraux

24 Diagrammes (représentations graphiques de modèles) de classes dinstances Diagrammes de déploiement de composants Diagrammes de collaboration de séquences d'états, dactivités Diagrammes de cas dutilisation Concepts généraux

25 AnalyseConceptionImplémentation Démarche uniforme sur le cycle de vie Même notation Concepts généraux

26 Les diagrammes sont majoritairement des graphes Aspects du langage Noeuds Chaînes de caractères Arcs Notes noms, étiquettes, mots clefs > Contraintes Texte libre, lge prog. OCL, etc.

27 Plan Cours 1 Introduction Présentation dUML Modèle fonctionnel (utilisation)

28 Modèle dutilisation Les cas dutilisation, ou « USE CASE » Fonctionnalités externes Modèles descriptifs du point de vue des utilisateurs Interactions avec les acteurs extérieurs la manière dutiliser le système

29 Modèle dutilisation On part de lanalyse des besoins …. Deux concepts Acteur toute entité extérieure au système et interagissant avec celui-ci. acteurs humains, acteurs « machine » (système extérieur communiquant avec le système étudié) Cas dutilisation toute manière dutiliser le système suite dévénements notable du point de vue de l utilisateur

30 Modèle dutilisation Trois concepts Acteur (rôle 1) Acteur (rôle 2) « communicate » Acteur Cas dutilisation > role Frontière du système

31 Modèle dutilisation Les cas d utilisation peuvent être liés par des relations : - dutilisation « include » (le cas origine contient obligatoirement lautre) - de raffinement « extend » (le cas origine peut être ajouté optionnellement ) Acteur (rôle 1) Acteur (rôle 2) « include » « extend » - de généralisation/spécialisation « generalizes »

32 Diagramme du « contexte statique » système Acteur (rôle 2) Acteur (rôle 1) > role association * Modèle dutilisation

33 Client Gestionnaire Du stock « include » « extend » Commander Décrire produits Procéder au paiement « include » Livraison Demande catalogue extension

34 Modèle dutilisation Client « include » Commander Décrire produits Procéder au paiement « include » Paiement CBPaiement cash « specializes »

35 Modèle dutilisation Délimiter le système - ce qui est extérieur et qui communique avec le système - ce qui est interne au système Définir les fonctionnalités du système du point de vue des utilisateurs Donner une description cohérente de toutes les vues que lon peut avoir du système

36 Modèle dutilisation Descriptions complémentaires Textes, diagramme de séquences ou dactivités Une proposition courante Sommaire didentification Titre, résumé, acteurs, dates création maj, version, auteurs Description des enchaînements Pré-conditions, scénario nominal, alternatives, exceptions, post-conditions Besoins IHM Contraintes non fonctionnelles Temps de réponse, concurrence, ressources machine, etc.

37 Plan Cours 2 Modèle structurel

38 En UML, le modèle structurel ou statique est décrit à l'aide de deux sortes de diagrammes Diagrammes de classes (description de tout ou d'une partie du système d'une manière abstraite, en termes de classes, de structure et d'associations). Diagrammes d'objets (description d'exemples de configuration de tout ou partie du système, en termes d'objets, de valeurs et de liens).

39 Modèle structurel Objets du monde réel Objets informatiques État Interne caché Comportement visible Les objets

40 Modèle structurel Comportement influe sur l'état Etat reflète les comportements passés Objet Etat---> évolue au cours du temps Comportement---> actions et réactions Identité----> essence

41 Sophie Alain Système BD Luc : Professeur : Discipline Deux objets ou instances Modèle structurel

42 Première abstraction Une classe peut être vue comme - la description en intension d'un groupe d'objets ayant même structure (même ensemble d'attributs), même comportement (mêmes opérations), une sémantique commune. - la « génitrice » des objets ou instances - le « conteneur » (extension) de toutes ses instances

43 Classe Attributs (propriétés) Voiture type : string marque : string couleur : string titine :Voiture type =205 Peugeot rouge Modèle structurel Instance Valeurs d'attributs (État) « Est-instance-de »

44 Classe et Attributs (propriétés) Voiture type : String {changeable} marque : String couleur[1..*]: Couleur = blanc Modèle structurel [Visibilité] nom [[multiplicité]][:type][=valeur initiale][{propriétés}] constant addOnly Nom de classe, expression [0..1] [n] [2..*] + - ~ # Couleur blanc:Couleur

45 Classe Attributs de classe Voiture type : string marque : string couleur : string nbrVoitures : int nbrRoues : int =4 {cst} titine :Voiture type =205 Peugeot rouge Modèle structurel Instance Valeurs d'attributs (État) Sauf des attributs de classe « Est-instance-de » Attribut de classe ~ caractéristique partagée Révèle souvent une modélisation à approfondir

46 Classe Attributs dérivés Personne dateNaissance : String / age : int julie:Personne 08/05/88 15 Modèle structurel Instance Valeurs d'attributs (État) « Est-instance-de » {age = date du jour – date de naissance} Peut-être une opération déguisée ? (stockage optionnel)

47 Opérations et méthodes Voiture type : string marque : string couleur : string repeindre(c: Couleur) déplacer(d : longueur) Méthodes Implémentations Modèle structurel nom de la classe attributs opérations Des attributs complémentaires peuvent être nécessaires

48 Classe, opérations, méthodes Modèle structurel [Visibilité] nom [(paramètres)][:type retour][{propriétés}] query abstract [mode] param : type [=valeur défaut] + - ~ # Couleur blanc:Couleur mode = in (par défaut), out, in/out Voiture repeindre(in c: Couleur=blanc) déplacer(in d : longueur) getCouleur():Couleur{query}

49 Opérations et méthodes de classe Modèle structurel Date jour:int mois:int annee:int nomDesMois[12]:String={« janvier », « fevrier »..} getJour():int ……… getFormatEtendu():String …….. getNomMois(in i:int) Opération/méthode de classe Elle ne sapplique pas à une instance

50 Opérations et méthodes de classe Modèle structurel Produit Référence : String PrixHT : float TauxTVA : float setPrixHT(f:float) affichePrix() …….. fixeTauxTVA(f:float) Opération/méthode de classe Elle ne sapplique pas à une instance

51 Modèle structurel Un objet est instance (propre) d'une classe : il se conforme à la description que celle-ci fournit, il admet une valeur pour chaque attribut déclaré à son attention dans la classe, il est possible de lui appliquer toute opération définie à son attention dans la classe. Tout objet admet une identité qui le distingue pleinement des autres objets : il peut être nommé et être référencé par un nom (mais son identité ne se limite pas à ça).

52 Association / Lien (analogie Classe / Instance) Pays Ville nom a-pour-capitale Association : Pays nom=France :Ville nom = Paris a-pour-capitale Lien Modèle structurel

53 Association / Lien (analogie Classe / Instance) Modèle structurel Une association est labstraction dun groupe de liens dont les caractéristiques sont communes même type dorigine même type de destination même attributs

54 Modèle structurel Association en général binaire (degré = 2) mais.. AdhérentExemplaire emprunte DispositifDeLecture lire nom d'association association binaire association ternaire

55 Multiplicités et rôles dans une association B assoc Modèle structurel n A - n instances de B peuvent être en relation avec une instance fixée de A - une instance de B joue le rôle rb pour une instance de A dans le contexte de assoc rb

56 Multiplicité et rôles d'une association Société Personne nom adresse nom date de nais. n°SS adresse emploie travaille-pour employeuremployé chef travailleur encadre Modèle structurel * 1..* 0..1

57 Modèle structurel exactement 1 Classe Classe 0..* Classe 1..* Classe 2..4 Classe 2,4 au plus 1 aucun, 1 ou plusieurs (défaut) au moins 1 de 2 à 4 2 ou 4 Multiplicité Classe

58 Conseils pour la modélisation d'association - verbes candidats possibles - ne pas "dériver vers la conception" (pointeurs ou attributs référentiels) Modèle structurel

59 Voiture type : String {changeable} marque : String Modèle structurel Couleur 1..* Un attribut à valeur multiple est souvent référentiel

60 Entreprise Personne nom adresse nom date de nais. adresse quantité Possède-des- actions capital actionnaire Modèle structurel Classe association Ligne de portefeuille *1..*

61 Classe association Utilisateur Station de travail nom Autorisation Autorisé sur priorité droits Répertoire répertoire de rattachement Modèle structurel 1..*

62 Classe dassociation Modèle structurel Une classe d'association permet de modéliser une association par une classe, donc de disposer dattributs et dopérations spécifiques. Les liens d'une telle association sont alors des objets instances de cette classe. À ce titre, ils admettent une valeur pour tout attribut déclaré dans la classe d'association ; et on peut leur appliquer toute opération définie dans celle-ci. En tant que classe, une classe d'association peut à son tour être associée à d'autres classes (voire à elle-même par une association réflexive).

63 Association qualifiée Banque Personne num_client est_client Modèle structurel Dossier_C 1..* Banque Personne num_client est_client 1..* 0..1

64 Navigabilité (pour la conception) Polygone Point contient Modèle structurel 3..* {ordered} Exprime un chemin daccès dun objet à un autre Un polygone « connaît ses points » Par défaut = bidirectionnel

65 Association dérivée Société Département Modèle structurel 1..*1 Personne / travaillePourLaSociété 1..* 0..1 dept structure employeur travaillePourLeDept {Personne.employeur=Personne.dept.structure} *

66 Dautres « abstractions » Modèle structurel associations particulières (composition / agrégation) spécialisation / généralisation

67 Agrégation Sémantique Collection/Élément Arbre Site Forêt 1 1..n Région Pays 1 1..n 1 Modèle structurel

68 Association particulière tout /partie Lexistence du composant est assujettie à celle de lobjet composite DeptEnseignement Université Composition Modèle structurel * 1

69 Composition / Agrégation Contraintes - Exclusivité / Partage - Dépendance / Indépendance Propagation / Diffusion Modèle structurel

70 Généralisation / Spécialisation Mécanismes dinférences intellectuelles de caractéristiques Soit on affine (spécialisation) Soit on abstrait (généralisation) Sémantique Point de vue ensembliste Point de vue logique Modèle structurel

71 Généralisation / Spécialisation Elle relie deux éléments de modèle (classes, cas dutilisation, méthodes) Modèle structurel A B B spécialise A ; A généralise B Définition : Lextension de A (ses instances) contient lextension de B A B Conséquence : une instance de B possède les propriétés de A éventuellement sous une forme affinée

72 Personne nom adresse Chercheur grade adresse Exposer() {disjoint} Gestionnaire num adresse Modèle structurel Généralisation / Spécialisation

73 Une sous-classe hérite des descriptions de sa super-classe : les déclarations d'attributs, les définitions d'opérations, les associations définies sur la super-classe, les contraintes (on en parle plus tard). Une sous-classe peut redéfinir de façon plus spécialisée une partie ou la totalité de la description « héritée ». Modèle structurel Généralisation / Spécialisation

74 Modèle structurel Généralisation / Spécialisation Le discriminant : exprime un critère de classification Salarié Vacataire Cotisant NonCotisant Employé RetraiteComplémentaire TypeContrat RetraiteComplémentaire Salarié Vacataire Cotisant NonCotisant Employé TypeContrat RetraiteComplémentaire

75 Modèle structurel Généralisation / Spécialisation multiple Véhicule terrestre Véhicule aquatique Auto Véhicule amphibie Bateau Véhicule milieu

76 Composition/Agrégation ou généralisation ? Modèle structurel Agrégation lien entre instances un arbre d'agrégation est composé d'objets qui sont parties d'un objet composite Généralisation lien entre classes

77 Les contraintes Les contraintes sont des prédicats, pouvant porter sur plusieurs éléments du modèle statique, qui doivent être vérifiés à tout instant. Les contraintes permettent de rendre compte de détails à un niveau de granularité très fin dans un diagramme de classe. Elles peuvent exprimer des conditions ou des restrictions. En UML, les contraintes sont exprimées sous forme textuelle, entre accolades et de préférence en OCL (Object Constraint Language). Les contraintes sont héritées. Modèle structurel

78 Contraintes de généralisation / Spécialisation SalariéCdi Vacataire Cotisant NonCotisant Employé {complet,disjoint} {incomplet}

79 Modèle structurel Contraintes de généralisation / Spécialisation Véhicule terrestre Véhicule aquatique Auto Véhicule amphibie Bateau Véhicule milieu {incomplet,chevauchement}

80 Les contraintes Exemples de contraintes sur associations SOL Strates 1..* Personne Comité préside * 1 membreDe ** {subset} {ordered} contrainte sur extrémité d'association contrainte entre 2 associations Modèle structurel

81 actif : Real {value 0} passif : Real Les contraintes Exemple de contraintes à différents niveaux contrainte sur classe Personne chef subordonné

82 Quelques compléments de notation relation de dépendance Sémantique de la relation de dépendance « un changement dans la spécification de B peut affecter A » (appelle, crée, utilise, instance de, etc.) Modèle structurel A B FenêtreGraphique Evénement Consommer ChoixBoisson

83 Quelques compléments de notation Un stéréotype est un label qui permet d'apporter une précision supplémentaire à un élément de notation (classe, relation, …) Modèle structurel Consommer ChoixBoisson « include » « enumeration » NomMois Janvier Février …. Personne « crée » + Personne() + getNom():String

84 Classes abstraites (notation italiques ou avec mot-clef {abstract}) Modèle structurel Une classe abstraite est une classe non instanciable, c'est à dire qu'elle n'admet pas d'instances directes. Une classe abstraite est une description d'objets destinée à être « héritée » par des classes plus spécialisées. Pour être utile, une classe abstraite doit admettre des classes descendantes concrètes. La factorisation optimale des propriétés communes à plusieurs classes par généralisation nécessite le plus souvent l'utilisation de classes abstraites.

85 Opérations abstraites Modèle structurel Une opération abstraite est une opération n'admettant pas d'implémentation : au niveau de la classe dans laquelle est déclarée, on ne peut pas dire comment la réaliser. Les opérations abstraites sont particulièrement utiles pour mettre en œuvre le polymorphisme. Toute classe concrète sous-classe d'une classe abstraite doit concrétiser toutes les opérations abstraites de cette dernière.

86 Classes abstraites Modèle structurel FormeGéométrique dessiner() déplacer(delta : Vecteur) centre : Point régulier : Boolean Polygone grandDiam : Vecteur petitDiam : Vecteur dessiner() opération abstraite classe abstraite classe abstraite (dessiner() est héritée et non concrétisée) opération concrétisée classe concrète Polygone utile si spécialisée Ellipse

87 Interfaces Modèle structurel Une interface est une collection d'opérations utilisée pour spécifier un service offert par une classe. Une interface être vue comme une classe sans attributs et dont toutes les opérations sont abstraites. Une interface est destinée à être réalisée par une classe (celle-ci en hérite toutes les descriptions et concrétise les opérations abstraites). Une interface peut en spécialiser une autre, et intervenir dans des associations avec d'autres interfaces et d'autres classes.

88 Interfaces Modèle structurel MenuPopUp BlocDeChoix setDefault(o : Option) getChoice() : Option Option choix 1..* setDefault(o : String) getChoice() : String setDefault(o : Bouton) getChoice() : Bouton Bouton choix 1..* String choix 1..* opérations concrétisées «interface» interface opérations abstraites réalisation MenuBouton

89 Interfaces Modèle structurel Deux notations pour l'utilisation d'une interface MenuPopUp setDefault(o : Option) getChoice() : Option «interface» BlocDeChoix MenuPopUp ApplicationFenêtrée «uses» ApplicationFenêtrée «uses» BlocDeChoix interface utilisation réalise classe utilisatrice

90 Heuristiques délaboration du modèle structurel Bien comprendre le problème Faire simple Bien choisir les noms Bien expliciter les associations Ne pas trop généraliser Relire Documenter De nombreuses révisions sont nécessaires ! Modèle structurel

91 Cours 3 Modèle dynamique Modèle dimplémentation Plan

92 Décrit les interactions entre objets et les changements au cours du temps Modèle dynamique -Le déroulement des actions, le contrôle -Les états des objets et leurs interactions - La survenue des événements

93 Modèle dynamique diagrammes de collaboration (ou de communication) diagrammes de séquences diagrammes états-transitions diagrammes d'activités

94 La communication Systèmes informatiques : Société d'objets travaillant en synergie pour réaliser les fonctions de l'application Communication Client Serveur message Acteur Modèle dynamique

95 constructeurs destructeurs appel de méthodes Types Synchronisation asynchrone synchrone retour Les messages Modèle dynamique Expressions [condition] *[condition ditération] itération

96 Diagramme de collaboration Interaction entre objets pour la réalisation dune fonctionnalité du système :B :C message :A 1: m1 2: m2 3: m3 4: m4 6: m6 5: m5 Modèle dynamique Laccent est mis sur la collaboration entre objets

97 Diagramme dinstance dune roue de brouette pneu:Piece d:Piece rdb:Piece 4: m4 Modèle dynamique Chambre:Piece Jante:Piece r3:Piece r2:Piece r1:Piece Piece

98 Diagramme de collaboration – calcul du prix pneu:Piece d:Piece rdb:Piece 4: m4 Modèle dynamique Chambre:Piece Jante:Piece r3:Piece r2:Piece r1:Piece 1:getPrix() 2:getPrix() 3:getPrix() 3.4:getPrix() 3.3:getPrix() 3.2:getPrix() 3.1:getPrix()

99 Diagramme de séquences Interaction entre objets pour la réalisation dune fonctionnalité du système :B :C :A m1 m2 m3 m4 m6 m5 Modèle dynamique Laccent est mis sur la chronologie des événements

100 La ligne de vie « create » Création par le message «create» Activation de lobjet qui exécute une opération op Destruction par un autre objet :C1 « destroy » op Modèle dynamique

101 rdb pneu chambre jante temps Modèle dynamique d r1r2 r3 getPrix()

102 rdb pneu chambre jante temps Modèle dynamique d r1r2 r3 getPrix()

103 :Palmier :Feuille :Inflorescence :Régime temps Modèle dynamique

104 Diagrammes détats Événement et État État d'un objet moment de la vie dun objet où Il accomplit une action Il satisfait une condition Il attend un événement létat est défini par la valeur instantanée des attributs et liens de lobjet Modèle dynamique

105 Événement et État Événement Stimulus (sans durée) envoyé à un objet une condition devient vraie appel dune opération réception dun signal fin dune période de temps Modèle dynamique

106 Graphe Nœud État Arc Transition nommées par événement Une séquence d'événements = chemin dans le graphe Modèle dynamique Diagrammes d'États Ils servent à représenter les états par lesquels passe un objet dune classe donnée

107 état et événement sont duaux un événement sépare deux états un état sépare deux événements Modèle dynamique Diagrammes d'États

108 Modèle dynamique Notation des états Initial Final Simple Complexe Créditeur Typing password entry/ set echo off exit/ set echo on on type char/ handle char on help/ display help do/ curseur clignote au début à la fin lors devt tout le temps Activités internes Diagrammes d'États

109 Modèle dynamique Notation des transitions étiquette événement(paramètres) [condition] /action ^envoiMessage Diagrammes d'États

110 État 1 do/ activité 1 Événement 1 [Cond1] / Action1 État 2... Opération Activité / Action Modèle dynamique

111 Avec inflorescence création e1 Avec régime e2 [C] Créé Avec feuille Modèle dynamique

112 Diagrammes d'États Etats dun compte bancaire transitions gardées sous-état Ouvert Fermé demandeCréat() Débiteur on retrait/ agios on dépôt/ augmenter solde fermer() Créditeur on retrait/ debiter solde on dépôt/ augmenter solde [Solde >0] [Solde 0] Modèle dynamique ouvert

113 Action opération instantanée, non interruptible, souvent utilisée pour faire des mises à jour de valeurs, attachée à une transition. Envoyer un événement est une action Activité opération qui prend du temps, interruptible par un événement, perpétuelle ou finie, nécessairement attachée à un état. Opération elle peut être attachée à une transition ou à un état. elle est exécutée en réponse à l'événement ou à l'état. Modèle dynamique

114 Généralisation - permet une meilleure structuration des diagrammes d'états Un objet dans un état du diagramme général doit être dans un des états du diagramme imbriqué (relation ou entre les états) E1 E2 E5 E4E3 E6 Modèle dynamique

115 Agrégation une classe "agrégat" aura un état défini par l'agrégation des états de ses composants. Agrégation concurrente (relation et) Modèle dynamique marié Age célibataire Statut familial Enfant Ado Adulte

116 Diagrammes dactivités Représentation du flot de contrôle Actions Données, objets nœuds de contrôle Etat initial Etat final Modèle dynamique signal forkdécision

117 Diagramme dactivités Modèle dynamique Réception Expédier produits Exécuter Envoi facture Facture Paiement Accepter paiement [acceptée] [rejetée] Clôturer Bon de commande Traiter Commande

118 Heuristiques délaboration du modèle dynamique Chemins suivis lors des envois de messages : diag. de séquences ou de collaboration Point de vue dun objet diag détats : pour les objets pour lesquels il est significatif de montrer les changements détats diag. dactivités : pour décrire un algorithme du point de vue dun objet Contrôler la cohérence, structurer les diagrammes Accompagnement des diagrammes de cas dutilisation diag. de séquences diag. dactivités (proches des workflows) Modèle dynamique

119 Les packages Modèle dimplémentation Un package ou sous-système est un regroupement logique de classes, associations, contraintes.. Un sous-système est généralement défini par les services quil rend Les liens entre sous-systèmes sont des liens de dépendance Les « packages » servent à structurer une application Ils sont utilisés dans certains LPO (Java) ce qui assure une bonne « traçabilité » de l analyse à l implémentation

120 Les packages Classes avec fort couplage « sémantique » Liens de dépendance Modèle dimplémentation

121 VenteAutomobile Voiture Garage Vendeur

122 Modèle dimplémentation (UML 2.0) Diagramme de composants dépendances entre composants logiciels (sources, binaires, exécutables, etc.) Système de planification Agenda réservation

123 :PC Modèle dimplémentation (UML 2.0) Diagramme de déploiement organisation matérielle des éléments de calcul et des composants logiciels Système de planification Agenda :server

124 ANNEXES Projection vers les Bases de Données Projection vers la programmation Méthodologie (RUP) Patrons de conception Plan

125 Persistance Classes vs Types persistants vs éphémères Points dentrée (racine de persistance) Regroupements Du modèle objet... aux BD Adéquation aux BD « objet »

126 LDD, LMD, L Hôte LDD, LMD, L Hôte équivalents LPO Langage de requête « like » SQL Transactions Du modèle objet... aux BD Adéquation aux BD « objet »

127 Adéquation aux BD « classiques » Traduction comme précédemment d. structurels --> schémas d. dynamiques --> requêtes et traitements applicatifs divers Mais règles de « passage » Du modèle objet... aux BD

128 Classes Attributs Ajout de lidentifiant Schéma relationnel ADRESSE N° Rue CP Ville Attribut Domaine Non Null Id_adresse Identifiant Oui N° Entier Non Rue String(30) Non ….. Schéma Adresse Clé primaire Id_adresse Du modèle objet... aux BD

129 Classes Attributs Ajout de lidentifiant Schéma relationnel PERSONNE NSS {unique} Nom Prénom Date-naissance Attribut Domaine Non Null Id_Pers Identifiant Oui NSS String(13) Oui Prénom String(30) Non Date-nais Date Non Schéma Personne Clés primaires candidates Id_adresse NSS On préfère NSS Du modèle objet... aux BD

130 Associations PERSONNE ADRESSE NSS.... N° Rue CP Ville 1 1 a Attribut Domaine Non Null NSS String(13) ID Oui Nom String(35) Oui Id_adresse Identifiant Oui Schéma Personne Clé primaire NSS Clé étrangère Id_adresse Du modèle objet... aux BD

131 Associations PERSONNE COMPTE NSS.... N° Type 1 0..* possède Attribut Domaine Non Null Id_compte Identifiant Oui N° String(35) Id Oui NSS Identifiant Oui Schéma Compte Clé primaire Id-compte N° On choisit N° Clé étrangère NSS Du modèle objet... aux BD

132 Associations PERSONNE BIBLIOTHEQUE NSS.... nom 0..* adhère-> 0..* date adhésion type adhésion (mensuelle, annuelle) Schéma Adhère Clé primaire NSS Id_bibliothèque Rque : Date Type Attribut Domaine Non Null NSS Id String(13) Oui Id_bibliothèque Identifiant Oui Date_adhésion Date Oui Type_adhésion String(10) Oui Du modèle objet... aux BD

133 Spécialisation PERSONNE NSS.... ETUDIANT num.... ENSEIGNANT grade.... Plusieurs choix - « aplatir vers le haut » Schéma Personne Clé primaire NSS - « aplatir vers le bas » Schémas Etudiant, Enseignant Clé primaire NSS - conserver les niveaux Du modèle objet... aux BD

134 ANNEXES Projection vers les Bases de Données Projection vers la programmation Méthodologie (RUP) Patrons de conception Plan

135 Du modèle objet... à la programmation Classes - adresse : String = 'adresse inconnue' - numeroINSEE[6] : Integer # changeAdresse(nouvelleAdresse : String) + cotisationAJour() : Boolean Adhérent note ( peut contenir un complément de description, un commentaire, …) type d'attribut valeur initiale type de paramètre type du résultat de l'opération privé protégé public adhérent de la bibliothèque valeurs multiples

136 Du modèle objet... à la programmation Classes Attributs, Opérations > Champs, Méthodes Et des méthodes particulières spécifiques à certains langages … Accesseurs L/E (convention get/set en Java) Constructeurs (Java, C++), Destructeurs (C++) Proposer un service et réagir aux messages

137 Classe Adhérent en Java (extrait) public class Adherent { private String adr = ``adresse inconnue``; private int[] numeroInsee; public Adherent(){numeroInsee=new int[6];} public Adherent(String na, int[] ni){adr=na; numeroInsee=ni;} public String getAdr(){return adr;} protected void setAdr(String nouvelleAdresse) {adr=nouvelleAdresse;} public int[] getNumeroInsee(){return numeroInsee;} protected void setNumeroInsee(int[] ni){numeroInsee=ni;} public boolean cotisationAjour(){…….} } Constructeurs Accesseurs Méthodes Champs

138 Classe Adhérent en C++ (extrait) //………. Adherent.h …………………………………………………… class Adherent { private: string adr; int* numeroInsee; public: Adherent(); Adherent(string na, int* ni); virtual ~Adherent(); virtual string getAdr() const; virtual void setAdr(string nouvelleAdresse); virtual int* getNumeroInsee()const; virtual void setNumeroInsee(int* ni); virtual boolean cotisationAjour()const; }; Constructeurs Accesseurs Méthodes Champs Destructeurs

139 Classe Adhérent en C++ (extrait) //……………. Adherent.cc ………………………………………………… Adherent::Adherent() {adr = ``adresse inconnue``; numeroInsee=new int[6];} Adherent::Adherent(string na, int* ni) {adr=na; numeroInsee=ni;} Adherent::~Adherent(){delete[] numeroInsee;} string Adherent:: getAdr()const{return adr;} void Adherent::setAdr(string nouvelleAdresse) {adr=nouvelleAdresse;} int* Adherent::getNumeroInsee()const{return numeroInsee;} void Adherent::setNumeroInsee(int* ni){numeroInsee=ni;} boolean Adherent:: cotisationAjour()const{…….}

140 Du modèle objet... à la programmation Opérations Données Messages Encapsulation Objet Retour sur la notion dencapsulation

141 Du modèle objet... à la programmation Liste GestionPersonnel ajoute retire applique(fct) Confiner les modifs de Liste dans la classe Liste … Utilité de lencapsulation

142 Du modèle objet... à la programmation Encapsulation Consensuel privé... implémentation public... spécification En pratique à chaque langage ses particularismes Smalltalk. attributs privés, méthodes publiques,... Java. package, protected,... C++. friends, protected, protection sur le lien dhéritage,... Quelle philosophie adopter ?

143 Protection en Java public class Adherent { private String adr = ``adresse inconnue``; private int[] numeroInsee; public Adherent(){numeroInsee=new int[6];} public Adherent(String na, int[] ni) {adr=a; numeroInsee=ni;} public String getAdr(){return adr;} protected void setAdr(String nouvelleAdresse) {adr=nouvelleAdresse;} public int[] getNumeroInsee(){return numeroInsee;} protected void setNumeroInsee(int[] ni){numeroInsee=ni;} public boolean cotisationAjour(){…….} } Accessible aussi dans toute méthode du package et dans toute méthode dune sous-classe C sur une variable dont le type statique est C ou une sous- classe de C Accessible partout Accessible seulement dans les autres méthodes de la classe Du modèle objet... à la programmation

144 Variables et méthodes de classe (en Java) public class Produit { private static float tauxTVA; ……….. public static void fixeTauxTVA(float f){…..} } Produit référence : String prixHT : float tauxTVA : float setPrixHT(f:float) affichePrix() …….. fixeTauxTVA(f:float) Du modèle objet... à la programmation

145 Classes abstraites, méthodes abstraites abstract public class Figure { abstract public void dessine(); …….. } Java class Figure { public: virtual void dessine()const=0; …….. } C++

146 Du modèle objet... à la programmation Traduction des interfaces en Java Héritage par réalisation Spécification de services (sans implémentation)

147 interface Ipolygon {float perimeter(); …} interface Iquadrilateral …. {static const int sideNb = 4; ….} interface Isquare …. {float getCote(); …..} public class Square implements Isquare {public float getCote(){….} ….} public class x {…. public void meth(Isquare i) {…} …..} Du modèle objet... à la programmation Interfaces en Java Ipolygon Iquadrilateral Isquare Square

148 interface Ipolygon {float perimeter(); …} interface Iquadrilateral …. {static const int sideNb = 4; ….} interface Isquare …. {float getCote(); …..} public class Square implements Isquare {public float getCote(){….} ….} public class x {…. public void meth(Isquare i) {…} …..} Du modèle objet... à la programmation Interfaces en Java méthodes abstraites et publiques (par défaut) variables de classe publiques et constantes (par défaut) type à implémenter type de Java (écriture de code générique)

149 Du modèle objet... à la programmation Associations PERSONNE ADRESSE nom.... N° Rue CP Ville 1 1 a class PERSONNE { private : string nom; ADRESSE adr;.... } rien de spécial dans ADRESSE Attribut complexe Navigabilité dans un seul sens adr Utilisation du nom de rôle

150 Du modèle objet... à la programmation Associations PERSONNE COMPTE nom.... N° Type 1 0..n possède class PERSONNE {private : string nom; list comptes;....} class COMPTE {private : PERSONNE possesseur;....} Conteneur Référence Navigabilité dans les deux sens comptes possesseur

151 Du modèle objet... à la programmation Associations PERSONNE BIBLIOTHEQUE nom.... nom 0..n adhère class PERSONNE {private : string nom;....} class BIBLIOTHEQUE {private :....} class ADHESION {private : PERSONNE adhérent; BIBLIOTHEQUE biblio; DATE dateadhésion; String typeAdhesion;....} Réification 0..n date adhésion type adhésion (mensuelle, annuelle) Classe dassociation

152 Personne nom adresse Gestionnaire num adresse Du modèle objet... à la programmation Lhéritage traduit la généralisation/spécialisation C++ class Personne{}; class Gestionnaire : virtual public Personne Java public class Personne{} public class Gestionnaire extends Personne {}

153 Du modèle objet... à la programmation Héritage adéquation des deux relations représentation et traitement des conflits spécialisation des attributs représentation de la surcharge et du masquage utilisation de lhéritage à des fins dimplémentation ? Implémentation de la relation de spécialisation par lhéritage, quelques problèmes....

154 Du modèle objet... à la programmation Héritage : adéquation des deux relations Spécialisation multiple (possible en C++, impossible entre classes Java) Flot good() eof()... FlotEcriture écrire(blocOctets)... FlotLecture lire(nbOctets)... FlotLectureEcriture

155 interface Ipolygon {float perimeter(); …} interface Iquadrilateral extends Ipolygon {static const int sideNb = 4; ….} interface Isquare extends Irectangle,Irhombus {float getCote(); …..} public class Square implements Isquare {public float getCote(){….} ….} public class x {…. public void meth(Isquare i) {…} …..} Du modèle objet... à la programmation Adéquation des deux relations (cas de Java) héritage multiple entre interfaces spécialisation implémentation

156 Cas de Java : héritage simple pour limplémentation, multiple pour les interfaces... côté classes,... les méthodes de FlotLecture et FlotEcriture doivent être réécrites dans FlotLectureEcriture Du modèle objet... à la programmation Héritage : adéquation des deux relations (Java) interface Flot interface FlotEcriture interface FlotLecture interface FlotLectureEcriture classe Flot classe FlotLecture classe FlotLectureEcriture classe FlotEcriture extends implements

157 Du modèle objet... à la programmation Spécialisation/Généralisation.... Conflit portant sur le nom des propriétés Il y a clairement deux propriétés Objet couleur (rouge, vert...) Elément de jeu Pion Dé Carte à jouer couleur (coeur, trèfle,...)

158 Du modèle objet... à la programmation Spécialisation/Généralisation.... multiples Conflit portant sur les valeurs ou le domaine dune propriété Le pédalo na quune propriété zoneNav, mais quel sera son domaine ? ObjetNautique Bateau EnginPlage Pedalo zoneNav {zoneNav sup. à 100} {zoneNav inf. à 10} {zoneNav ?}

159 Du modèle objet... à la programmation Héritage : représentation et traitement dun conflit de nom Smalltalk Java C++ Désignation explicite Objet::Couleur CarteAJouer::Couleur Donner deux noms différents pas daccès possible à couleur dobjet autre quavec super (dans les méthodes) mieux vaut donner deux noms différents

160 Du modèle objet... à la programmation Héritage : spécialisation des attributs Animal nourriture (végétale, animale, minérale) Herbivore nourriture (végétale) Relation ensemblesImpliqués > 1 RelationBinaire ensemblesImpliqués = 2 Aucune représentation, ni en C++, ni en Smalltalk, ni en Java Seule issue : vérification des contraintes dans les méthodes (surtout accesseurs)...

161 Du modèle objet... à la programmation Héritage : surcharge statique et redéfinition Redéfinition coexistence de méthodes de même nom dans des classes comparables appel déterminé par le type de lobjet (dynamique) Surcharge statique coexistence de méthodes de même nom dans des classes différentes appel déterminé par le type de la variable (statique)

162 Du modèle objet... à la programmation Héritage : redéfinition Java redéfinition seulement si les signatures sont strictement identiques, C++ redéfinition si les types des paramètres sont identiques, le type de retour peut être spécialisé Magnitude <(Magnitude) Time <(Time) heure minute secondes Date <(Date) jour mois année Java, C++ : on ne peut pas représenter directement une spécialisation des paramètres cas de surcharge statique Magnitude <(Magnitude) Time <(Magnitude) heure minute secondes Date <(Magnitude) jour mois année cas de redéfinition

163 Du modèle objet... à la programmation Héritage : à chacun sa surcharge Personne Princesse habiller(Vêtement) habiller(Vêtement, Chaussure) habiller(Vêtement, Bijou) Vêtement Chaussure Bijou QuiSePorte En Java : correctement interprété comme de la surcharge statique En C++ : habiller(Vêtement, Bijou) cache les deux autres

164 Du modèle objet... à la programmation Héritage : lutiliser pour des raisons dimplémentation ? Liste ajoutFin Pile push pop top A éviter dans tous les cas... même si les livres en sont pleins...

165 Du modèle objet... à la programmation Généricité paramétrique Pile push(t:T) pop():T top():T En C++ : template template class Pile {… push(T element) …} Pile p; En Java : simulé class Pile {…. push(Object element) ….} Pile p = new Pile(); problèmes : - contrôle des éléments insérés - cast des éléments retirés T T

166 Du modèle objet... à la programmation A partir du modèle dynamique - diagrammes de séquence jim:Etudiant afficheResultats() afficheMoyenneEtMention() [moyenne<10] afficheModulesObtenus() public class Etudiant { public void afficheResultats() { afficheMoyenneEtMention(); if (getMoyenne()<10) afficheModulesObtenus(); }

167 cnam03:Promotion Du modèle objet... à la programmation A partir du modèle dynamique - diagrammes de collaboration :Etudiant *[i:=0..nbEtudiants-1]:moyenne() public class Promotion { private Vector listeEtudiants; ………. public float moyenneGenerale() { double mg=0; for (int i=0; i

168 ANNEXES Projection vers les Bases de Données Projection vers la programmation Méthodologie (RUP) Patrons de conception Plan

169 Méthodologie Méthode ou Processus de développement acteurs nécessaires (qui) grands types dactivités (comment) artefacts (quoi) organisation du travail (quand)

170 Historique Méthodes cartésiennes Jackson, SADT, Yourdon Méthodes systémiques Merise, Axial, Information Engineering Méthodes objet OOD, HOOD, OMT, OOSE, OOA/OOD, unifiées dans le RUP (Rational Unified Process)

171 Concepts généraux Conceptualiser obtenir un énoncé du problème (utilisateurs) Analyser spécifier le problème Implémenter réaliser la solution informatique Concevoir une solution informatique

172 Concepts généraux Étapes Résultats PlanificationSchéma directeur Analyse des besoinsModèle des besoins Spécification formelle ou analyseModèle conceptuel Spécification technique ou conceptionModèle logique ImplémentationModèle physique Intégration et TestsRapport de cohérence logique Validation du systèmeRapport de conformité Maintenance et évolution Documentation et trace

173 Concepts généraux Cycles de développement - en cascade - en V - en spirale - tridimensionnel

174 Analyse Conception Implémentation Tests Maintenance Modèle de cycle en cascade

175 Organisation séquentielle des phases du cycle de vie Une phase est structurée en un ensemble d'activités pouvant s'exécuter en parallèle par plusieurs personnes Le passage d'une phase à la suivante ne se fait que lorsque les sorties de la première ont été fournies Modèle de cycle en cascade

176 Contre : Retours sur les phases précédentes difficiles (rupture entre les phases) Visualisation et validation tardive Pour : Organisation simple et directe

177 Implémentation Expression des besoins Validation des besoins Validation fonctionnelle Spécification fonctionnelle Conception du système Tests du système Tests des composants Conception des composants Modèle de cycle en V

178 Approche descendante dans les phases précédant limplémentation : on décompose le système au fur et à mesure quon le construit Approche ascendante dans les phases suivantes : on recompose le système en testant les parties Hiérarchie de tests : les différents tests provoquent un retour dinformation directement sur la phase permettant de corriger les erreurs.

179 Modèle de cycle en V Pour : Décomposition du système en sous-systèmes Hiérarchie de tests et retours facilités Vérification ascendante Contre : Validation en fin de cycle (erreurs danalyse coûteuses)

180 Conception Analyse Spécifications Besoins Validation Tests Implémentation Modèle de cycle en spirale

181 Modèle itératif On passe par toutes les phases du cycle de vie plusieurs fois Modèle incrémental On améliore à chaque passage Un passage peut aussi bien permettre dévaluer un nombre réduit de fonctionnalités ou lorganisation générale du système de façon non détaillée

182 Modèle de cycle en spirale Pour : Réalisation de plusieurs prototypes (versions) avant la réalisation du système réel (définitif) Validation progressive et précoce Souplesse dans le choix des prototypes Contre : Mise en œuvre parfois coûteuse Possibilité de divergence, nombre de prototypes difficile à déterminer Le RUP est une réponse à ces critiques

183 RUP (Rational Unified Process) RUP Objectory OMT BOOCH

184 RUP (Rational Unified Process) Mots-clefs : développement itératif développement incrémental pilotage par les cas dutilisation centré sur larchitecture configurable

185 RUP (Rational Unified Process) 1- Les grandes activités 2- La notion darchitecture logicielle 3- Lorganisation itérative des activités Bibliographie « The RUP, an Introduction » P. Kruchten, Addison-Wesley 2000 « The unified Software Developement Process » I. Jacobson, G. Booch, J. Rumbaugh, Addison-Wesley 1999 « Modélisation Objet avec UML » P.-A. Muller, N. Gaertner, Eyrolles, 2002

186 RUP (Rational Unified Process) 1- Les grandes activités Le RUP distingue 9 activités, à chacune correspond : des artefacts des métiers des outils (cf. site de Rational)

187 RUP (Rational Unified Process) 1- Les grandes activités activité 1. GESTION DE PROJET Plannification Allocation des tâches et des responsabilités Allocation des ressources Etude de faisabilité et des risques calendrier des tâches chef de projet

188 RUP (Rational Unified Process) 1- Les grandes activités activité 2. MODELISATION DE LORGANISATION modélisation - de la structure - du fonctionnement de lorganisation où le système sera déployé cas dutilisation de lorganisation (avec scenarii) concepteur dorganisation

189 RUP (Rational Unified Process) 1- Les grandes activités activité 3. ANALYSE DES BESOINS détermination des besoins : - fonctionnels (ce que lon attend du système) - non fonctionnels (fiabilité, temps de réponse, environnement distribué, etc.) cas dutilisation du système à construire (avec scenarii) documents descriptifs conception de linterface utilisateur analyste

190 RUP (Rational Unified Process) 1- Les grandes activités activité 4. ANALYSE ET CONCEPTION évoluer depuis la spécification des besoins jusquà une solution informatique analyse~besoins fonctionnels conception~intègre aussi les besoins non fonctionnels diagrammes de classes, paquetages, sous-systèmes diagrammes de collaboration, détats diagrammes de composants architecte, concepteur

191 RUP (Rational Unified Process) 1- Les grandes activités activité 5. IMPLEMENTATION Transcription dans un langage de programmation ou de base de données Utilisation de composants existants code implémenteur, développeur

192 RUP (Rational Unified Process) 1- Les grandes activités activité 6. TEST Estimer si les besoins sont satisfaits sil y a des erreurs/défauts à corriger Renforcer et stabiliser larchitecture modèles de test, scripts concepteur de test, testeur

193 RUP (Rational Unified Process) 1- Les grandes activités activité 6. TEST Différents niveaux de tests unitaires (test dune classe, dun module isolément) intégration (plusieurs modules ensembles) validation (les fonctionnalités du système sont assurées) recette (souvent contractualisés, avec le client)

194 RUP (Rational Unified Process) 1- Les grandes activités activité 6. TEST Différents types de tests Benchmark (sur un ensemble de données type) Configuration/installation Charge Fiabilité, stress Performance

195 RUP (Rational Unified Process) 1- Les grandes activités activité 7. DEPLOIEMENT Distribuer le logiciel dans son environnement opérationnel Installation, test Formation des utilisateurs Migration des données diagrammes de déploiement formateur, graphiste, rédacteur de documentation, testeur, implémenteur (scripts dinstallation)

196 RUP (Rational Unified Process) 1- Les grandes activités activité 8. MAINTENANCE ET EVOLUTION Gérer pendant lavancement du projet lévolution : des besoins des utilisateurs, du niveau des développeurs, de la technologie, etc. plan de modification tous les métiers !

197 RUP (Rational Unified Process) 1- Les grandes activités activité 9. ENVIRONNEMENT Activité de support du développement sélection des outils de travail, administration système et réseau, administration BD, formation de léquipe de travail, etc. doc outils, doc installation admin. S&R, formateur, admin. BD

198 RUP (Rational Unified Process) 2- Larchitecture logicielle Analogie avec larchitecture dans le domaine du bâtiment Désigne un ensemble de descriptions de haut niveau (les « plans de construction »)

199 RUP (Rational Unified Process) 2- Larchitecture logicielle La vue de larchitecte est générale et sert à : contrôler lintégrité du système identifier les éléments réutilisables baser le partage du travail

200 RUP (Rational Unified Process) 2- Larchitecture logicielle Plans de construction Orientation des modèles par les cas dutilisation Cas dutilisation Logique Réalisation Processus Déploiement classes/dynamiquecomposants use case + scenarii scenarii sur composants concurrence distribution tolérance aux pannes composants projetés sur le matériel

201 RUP (Rational Unified Process) 2- Larchitecture logicielle Une définition de la notion darchitecture « vue limitée du système permettant de comprendre : ce quil fait comment il fonctionne comment travailler sur une seule partie comment létendre comment réutiliser certaines parties » Seules les grandes lignes de chaque diagramme font partie de larchitecture

202 RUP (Rational Unified Process) 3- Lorganisation itérative des activités Pour répondre aux problèmes connus du développement en cascade : découverte tardive des défauts intégration difficile des modifications contrôle temps et coûts délicat

203 RUP (Rational Unified Process) 3- Lorganisation itérative des activités Cycle de base plannification besoins analyse conception implémentation déploiement test évaluation

204 RUP (Rational Unified Process) 3- Lorganisation itérative des activités Contrôle de la convergence : instauration de 4 PHASES Etude dopportunité Elaboration Construction Transition Chaque phase développe tout ou partie dun ou plusieurs cycles Des points de contrôle entre les phases permettent de vérifier lavancement Def. Projet objectifs risques, bénéfices Plannification architecture version béta version courante

205 RUP (Rational Unified Process) 3- Lorganisation itérative des activités A chaque itération la plannification est remise à jour et étendue les modèles sont approfondis un prototype est développé ou augmenté on teste (on re-teste parfois …) lexistant

206 RUP (Rational Unified Process) 3- Lorganisation itérative des activités Bénéfices résultats concrets précoces et réguliers problèmes et évolutions sont intégrés au fur et à mesure meilleure compréhension par les utilisateurs de ce quils peuvent comprendre -> ils précisent mieux leur besoin la faisabilité est objectivement mesurée, on a des points de mesure tous les métiers sont en permanence sollicités, les problèmes remontent plus vite

207 ANNEXES Projection vers les Bases de Données Projection vers la programmation Méthodologie (RUP) Patrons de conception Plan

208 Patrons de conception Recueillir lexpertise en conception Définition Un patron de conception est une solution de conception générique pour résoudre un problème de conception récurrent Micro-architecture dune application Analogie avec les plans de construction détaillés dun élément de bâtiment

209 Patrons de conception Un exemple : Résumé du patron « objets composite » Problème Nous désirons représenter des objets qui se décrivent par une hiérarchie dobjets, avec les deux particularités : la hiérarchie est une hiérarchie dagrégation tous les objets jusquau plus haut niveau présentent un même comportement (on peut leur appliquer un même ensemble de méthodes)

210 Patrons de conception Résumé du patron « objets composite » Exemple 1 Dans un éditeur de dessin, une figure géométrique est simple ou se compose dautres figures. Toutes les figures peuvent être dessinées, déplacées, effacées, agrandies, etc. Exemple 2 Dans un système dexploitation, les fichiers peuvent être ordinaires, ou bien des liens, ou encore des répertoires qui contiennent eux-mêmes dautres fichiers. Tout fichier peut être déplacé, détruit, renommé, etc.

211 Patrons de conception Résumé du patron « objets composite » Solution générique [E. Gamma et al. « design patterns », 94] version dite « sécurité » Composant + operation abstraite si pas de partie commune Feuille + operation Composite + operation + ajout(c:Composant) appliquer operation à tous les fils fils

212 Patrons de conception Résumé du patron « objets composite » Spécialisation du patron Figure + dessine + deplace FigureSimple FigureGroupee element + dessine + deplace + ajoute(f:Figure) + dessine + deplace Cercle CarréTrait


Télécharger ppt "Méthodologie objet UML et RUP : un survol IUP GMI 2ième année 2005/2006 M HuchardT. Libourel"

Présentations similaires


Annonces Google