Méthodologie objet UML et RUP : un survol IUP GMI 2ième année

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

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

Plan • Cours 1 Introduction Présentation d’UML
Modèle fonctionnel (utilisation)

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.

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

Difficultés de la modélisation
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 l’interface avec le métier (domaine d’application)

Difficultés de la modélisation
Introduction Difficultés de la modélisation É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 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

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

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

Introduction Concepts fondateurs
Fondent l’approche du problème et l’expression de la solution Classe, signal, état, fonction, etc.

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)

Introduction Pour résumer … Une méthode d’analyse 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) s’appuie sur un formalisme de représentation qui facilite la communication, l’organisation 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

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

UML = Bénéficier des qualités des approches par objets
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

La portée d’UML s’explique par l’importance de l’approche par objets
Omniprésence technique de l’Objet dans les langages de programmation, les bases de données, les interfaces graphiques, ... et les méthodes d’analyse et de conception. Universalité de l’Objet la notion d’objet, plus proche du monde réel, est compréhensible par tous et facilite la communication entre tous les intervenants d’un projet.

Genèse d’UML Au début des années 90, une cinquantaine de méthodes objet, liées uniquement par un consensus autour d’idées communes (objets, classes, sous-systèmes, ...) Recherche d’un 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.

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

Version intermédiaire non publiée UML 1.2
2003 UML 2.0 Version béta - fin 99 UML 1.3 Version intermédiaire non publiée UML 1.2 Standardisation à l’OMG - Novembre 97 UML 1.1 Soumission à l’OMG - Janvier 97 UML 1.0 Commentaires du public Juin 96 puis OOPSLA’96 UML 0.9 & 0.91 OOPSLA’95 Unified Method 0.8 Booch’93 OMT-2 Autres méthodes Booch’91 OMT-1 OOSE Partenaires

Concepts généraux Points de vue sur le système Vue structurelle Vue
implémentation Vue Cas d’utilisation Vue architecture (déploiement) Vue dynamique < Logique Physique >

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

Concepts généraux 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 d’un « langage » commun à travers un nombre restreint de concepts) - de valider (contrôle de la cohérence, simuler, tester …)

Concepts généraux Diagrammes (représentations graphiques de modèles)
de collaboration de séquences d'états, d’activités Diagrammes de classes d’instances Diagrammes de cas d’utilisation Diagrammes de déploiement de composants

Concepts généraux Démarche uniforme sur le cycle de vie Même notation
Analyse Conception Implémentation

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

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

Modèle d’utilisation On part de l’analyse 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 d’utilisation toute manière d’utiliser le système suite d’événements notable du point de vue de l ’utilisateur

Modèle d’utilisation Trois concepts Acteur (rôle 2) « communicate »
<< actor >> role Cas d’utilisation Frontière du système

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

Modèle d’utilisation Diagramme du « contexte statique »
0..1 Acteur (rôle 2) 0..* Acteur (rôle 1) système association 0..1 << actor >> role

Modèle d’utilisation Client Gestionnaire Du stock Commander Décrire
extension Client « include » « include » « extend » Décrire produits Procéder au paiement Demande catalogue Livraison Gestionnaire Du stock

Modèle d’utilisation Client Commander Décrire produits Procéder au
« include » « include » Décrire produits Procéder au paiement « specializes » Paiement cash Paiement CB

Modèle d’utilisation 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 l’on peut avoir du système

Modèle d’utilisation Descriptions complémentaires
Textes, diagramme de séquences ou d’activités Une proposition courante Sommaire d’identification 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.

Plan • Cours 2 Modèle structurel

Modèle structurel 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).

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

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

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

Modèle structurel 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

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

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

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

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

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

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

Modèle structurel Opérations et méthodes de classe 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 s’applique pas à une instance

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

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

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

Modèle structurel Association / Lien (analogie Classe / Instance)
Une association est l’abstraction d’un groupe de liens dont les caractéristiques sont communes même type d’origine même type de destination même attributs

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

Modèle structurel Multiplicités et rôles dans une association A B
rb - 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

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

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

Modèle structurel 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 Couleur Voiture type : String {changeable}
1..* Couleur Voiture type : String {changeable} marque : String Un attribut à valeur multiple est souvent référentiel

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

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

Modèle structurel Classe d’association
Une classe d'association permet de modéliser une association par une classe, donc de disposer d’attributs et d’opé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).

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

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

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

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

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

Modèle structurel Composition Association particulière tout /partie
L’existence du composant est assujettie à celle de l’objet composite 1 * DeptEnseignement Université

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

Modèle structurel Généralisation / Spécialisation
Mécanismes d’infé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

Elle relie deux éléments de modèle (classes, cas d’utilisation, méthodes) A B spécialise A ; A généralise B Définition : L’extension de A (ses instances) contient l’extension de B B A Conséquence : une instance de B possède les propriétés de A éventuellement sous une forme affinée B

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

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

Le discriminant : exprime un critère de classification Employé RetraiteComplémentaire TypeContrat TypeContrat RetraiteComplémentaire Salarié Vacataire Cotisant NonCotisant Employé TypeContrat RetraiteComplémentaire Salarié Vacataire Cotisant NonCotisant

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

Modèle structurel Agrégation Généralisation
Composition/Agrégation ou généralisation ? 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

Modèle structurel 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 Contraintes de généralisation / Spécialisation
Employé {incomplet} {complet,disjoint} SalariéCdi Vacataire Cotisant NonCotisant

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

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

Exemple de contraintes à différents niveaux { actif = passif } contrainte sur classe subordonné employeur Personne Société * 1..* 0..1 0..1 { Personne.employeur = Personne.chef.employeur } actif : Real {value  0} passif : Real <dirige chef contrainte sur attribut contrainte sur 2 associations

relation de dépendance
Modèle structurel Quelques compléments de notation A B 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.) FenêtreGraphique Evénement Consommer ChoixBoisson

Modèle structurel 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, …) « enumeration » NomMois Personne Janvier Février …. « crée » + Personne() + getNom():String « include » Consommer ChoixBoisson

Modèle structurel Classes abstraites
(notation italiques ou avec mot-clef {abstract}) 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.

Modèle structurel Opérations abstraites
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.

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

Modèle structurel Interfaces
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.

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

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

Modèle structurel 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 !

Plan • Cours 3 Modèle dynamique Modèle d’implémentation

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

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

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

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

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

Modèle dynamique Diagramme d’instance d’une roue de brouette Piece
pneu:Piece rdb:Piece Chambre:Piece d:Piece Jante:Piece 4: m4 r3:Piece r1:Piece r2:Piece

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

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

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

Modèle dynamique rdb pneu chambre jante d r1 r2 r3 getPrix() getPrix()
temps getPrix() getPrix() getPrix() getPrix()

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

moment de la vie d’un objet où
Modèle dynamique Diagrammes d’états Événement et État État d'un objet moment de la vie d’un 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 l’objet

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

Modèle dynamique Diagrammes d'États • Graphe Nœud État
Ils servent à représenter les états par lesquels passe un objet d’une classe donnée • 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 • état et événement sont duaux
un événement sépare deux états un état sépare deux événements

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

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

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

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

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

Modèle dynamique 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. 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.

Modèle dynamique 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 E3 E4 E2 E6 E5

Modèle dynamique 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) Statut familial Age marié Enfant Ado célibataire Adulte

Modèle dynamique Diagrammes d’activités
Représentation du flot de contrôle Actions Données, objets nœuds de contrôle Etat initial Etat final signal fork décision

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

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

Modèle d’implémentation
Les packages 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 qu’il 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

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

VenteAutomobile Vendeur Voiture Garage

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

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

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

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

Du modèle objet ... aux BD Adéquation aux BD « objet »
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 « 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 Classes Schéma relationnel Attributs
ADRESSE N° Rue CP Ville Schéma relationnel Attributs Ajout de l’identifiant Attribut Domaine Non Null Schéma Adresse Clé primaire Id_adresse Id_adresse Identifiant Oui N° Entier Non Rue String(30) Non …..

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

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

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

PERSONNE BIBLIOTHEQUE 0..* adhère-> 0..* NSS .... nom date adhésion type adhésion (mensuelle, annuelle) 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 Schéma Adhère Clé primaire NSS Id_bibliothèque Rque : Date Type

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

Du modèle objet ... à la programmation
Classes note (peut contenir un complément de description, un commentaire, …) adhérent de la bibliothèque valeurs multiples Dans le cadre de la projection vers la programmation, on complète le modèle d’analyse avec toutes sortes d’informations (protection, valeurs initiales, commentaires, etc.) Adhérent valeur initiale privé - adresse : String = 'adresse inconnue' - numeroINSEE[6] : Integer type d'attribut protégé # changeAdresse(nouvelleAdresse : String) + cotisationAJour() : Boolean type de paramètre public type du résultat de l'opération

Classes Proposer un service et réagir aux messages 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++) Les attributs et opérations sont traduits en champs et en méthodes ; usuellement on ajoutera des méthodes spéciales (accesseur) pour accéder à la valeur en lecture ou en modification Des attributs ; les langages de programmation demandent également l’écriture de méthodes spéciales appelées lors de la construction d’un objet (constructeur) ou lors de sa destruction (destructeur)

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(){…….} } Champs Constructeurs Accesseurs Méthodes

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; }; Champs Constructeurs Destructeurs Accesseurs Méthodes

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{…….}

Retour sur la notion d’encapsulation Objet Données Nous revenons plus en détails sur la notion d’encapsulation qui est propre à la programmation. Pour développer et maintenir facilement les logiciels, on essaie de découper le logiciel en modules relativement indépendants, bien spécifiés, et qui présentent seulement des services externes aux autres modules : l’implémentation est masquée, on dit encore « encapsulée ». Encapsulation Messages Opérations

Utilité de l’encapsulation GestionPersonnel Liste Par exemple, nous introduisons une classe GestionPersonnel qui utilise une classe Liste. Si la classe GestionPersonnel est développée en prenant bien garde à n’utiliser que les méthodes externes de Liste (et donc en s’interdisant de manipuler les champs internes), une modification effectuée sur la classe Liste restera confinée à la classe Liste et ne remettra pas en cause le code écrit pour GestionPersonnel. ajoute retire applique(fct) Confiner les modifs de Liste dans la classe Liste …

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 d’héritage, ... Quelle philosophie adopter ?

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 seulement dans les autres méthodes de la classe Accessible aussi dans toute méthode du package et dans toute méthode d’une sous-classe C sur une variable dont le type statique est C ou une sous- classe de C Accessible partout

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

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

Traduction des interfaces en Java Spécification de services (sans implémentation) Héritage par réalisation

Interfaces en Java Ipolygon 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) {…} …..} Iquadrilateral Isquare Square

Interfaces en Java 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) {…} …..} 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)

Associations Navigabilité dans un seul sens PERSONNE ADRESSE N° Rue CP Ville nom .... 1 a 1 Nous étudions à présent la traduction des associations. Dans ce premier cas, on considère qu’il est important pour une personne d’accéder à son adresse, mais l’inverse n’est pas utile dans le système. On traduit cette contrainte par le fait que a est navigable de Personne vers adresse (flèche à l’extrémité du trait de l’association). On utilise les noms de rôle comme nom d’attribut. adr class PERSONNE { private : string nom; ADRESSE adr; .... } rien de spécial dans ADRESSE Attribut complexe Utilisation du nom de rôle

Associations Navigabilité dans les deux sens PERSONNE COMPTE 1 possède 0..n nom .... N° Type Quand rien n’est indiqué sur l’association, elle est navigable dans les deux sens (par défaut) possesseur comptes class PERSONNE {private : string nom; list <COMPTE> comptes;....} class COMPTE PERSONNE possesseur;....} Conteneur Référence

Associations Classe d’association PERSONNE BIBLIOTHEQUE 0..n adhère 0..n nom .... nom date adhésion type adhésion (mensuelle, annuelle) class PERSONNE {private : string nom;....} class BIBLIOTHEQUE {private : ....} class ADHESION {private : PERSONNE adhérent; BIBLIOTHEQUE biblio; DATE dateadhésion; String typeAdhesion; ....} Réification

L’héritage traduit la généralisation/spécialisation Personne C++ class Personne{}; class Gestionnaire : virtual public Personne nom adresse Java public class Personne{} public class Gestionnaire extends Personne {} Gestionnaire num adresse

Héritage Implémentation de la relation de spécialisation par l’héritage, quelques problèmes .... • 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 l’héritage à des fins d’implémentation ?

Héritage : adéquation des deux relations Flot good() eof() ... FlotLecture lire(nbOctets) ... FlotEcriture écrire(blocOctets) ... FlotLectureEcriture Spécialisation multiple (possible en C++, impossible entre classes Java)

Adéquation des deux relations (cas de Java) 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) {…} …..} héritage multiple entre interfaces spécialisation implémentation

Héritage : adéquation des deux relations (Java) interface Flot interface FlotLecture interface FlotEcriture classe Flot interface FlotLectureEcriture classe FlotLecture classe FlotEcriture extends implements classe FlotLectureEcriture Cas de Java : héritage simple pour l’implémentation, multiple pour les interfaces ... côté classes, ... les méthodes de FlotLecture et FlotEcriture doivent être réécrites dans FlotLectureEcriture

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

Spécialisation/Généralisation .... multiples Conflit portant sur les valeurs ou le domaine d’une propriété ObjetNautique zoneNav {zoneNav sup. à 100} Bateau {zoneNav inf. à 10} EnginPlage Pedalo {zoneNav ?} Le pédalo n’a qu’une propriété zoneNav, mais quel sera son domaine ?

Héritage : représentation et traitement d’un conflit de nom C++ Désignation explicite Objet::Couleur CarteAJouer::Couleur Smalltalk Java Donner deux noms différents pas d’accès possible à couleur d’objet autre qu’avec “super” (dans les méthodes) mieux vaut donner deux noms différents

Héritage : spécialisation des attributs Animal nourriture (végétale, animale, minérale) Relation ensemblesImpliqués > 1 Herbivore nourriture (végétale) 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) ...

Héritage : surcharge statique et redéfinition 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) Redéfinition coexistence de méthodes de même nom dans des classes comparables appel déterminé par le type de l’objet (dynamique)

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) Date Magnitude <(Magnitude) Time jour mois année heure minute secondes Date Time <(Date) <(Time) jour mois année heure minute secondes Java, C++ : on ne peut pas représenter directement une spécialisation des paramètres cas de surcharge statique <(Magnitude) <(Magnitude) cas de redéfinition

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

Héritage : l’utiliser pour des raisons d’implémentation ? Liste ajoutFin A éviter dans tous les cas ... même si les livres en sont pleins ... Pile push pop top

Généricité paramétrique En C++ : template template<typename T> class Pile {… push(T element) …} Pile<int> p; En Java : simulé {…. push(Object element) ….} Pile p = new Pile(); problèmes : contrôle des éléments insérés cast des éléments retirés T Pile T push(t:T) pop():T top():T

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(); }

A partir du modèle dynamique - diagrammes de collaboration *[i:=0..nbEtudiants-1]:moyenne() cnam03:Promotion :Etudiant public class Promotion { private Vector listeEtudiants; ………. public float moyenneGenerale() double mg=0; for (int i=0; i<listeEtudiants.size(); i++ mg+=((Etudiant)(listeEtudiants.get(i))).moyenne(); return mg/listeEtudiants.size(); }

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

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)

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

Concepts généraux Étapes Résultats Planification Schéma directeur
Analyse des besoins Modèle des besoins Spécification formelle ou analyse Modèle conceptuel Spécification technique ou conception Modèle logique Implémentation Modèle physique Intégration et Tests Rapport de cohérence logique Validation du système Rapport de conformité Maintenance et évolution Documentation et trace

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

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

Modèle de cycle en cascade
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

Contre : Pour : Modèle de cycle en cascade
Retours sur les phases précédentes difficiles (rupture entre les phases) Visualisation et validation tardive Pour : Organisation simple et directe

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

Modèle de cycle en V Approche descendante dans les phases précédant l’implémentation : on décompose le système au fur et à mesure qu’on 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 d’information directement sur la phase permettant de corriger les erreurs.

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 d’analyse coûteuses)

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

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 l’organisation générale du système de façon non détaillée

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

RUP (Rational Unified Process)
Objectory OMT BOOCH

Mots-clefs : développement itératif développement incrémental pilotage par les cas d’utilisation centré sur l’architecture configurable

1- Les grandes activités 2- La notion d’architecture logicielle 3- L’organisation 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

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

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

1- Les grandes activités activité 2. MODELISATION DE L’ORGANISATION modélisation - de la structure - du fonctionnement de l’organisation où le système sera déployé cas d’utilisation de l’organisation (avec scenarii) concepteur d’organisation

1- Les grandes activités activité 3. ANALYSE DES BESOINS détermination des besoins : - fonctionnels (ce que l’on attend du système) - non fonctionnels (fiabilité, temps de réponse, environnement distribué, etc.) cas d’utilisation du système à construire (avec scenarii) documents descriptifs conception de l’interface utilisateur analyste

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

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

1- Les grandes activités activité 6. TEST Estimer si les besoins sont satisfaits s’il y a des erreurs/défauts à corriger Renforcer et stabiliser l’architecture modèles de test, scripts concepteur de test, testeur

1- Les grandes activités activité 6. TEST Différents niveaux de tests unitaires (test d’une classe, d’un 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)

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

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 d’installation)

1- Les grandes activités activité 8. MAINTENANCE ET EVOLUTION Gérer pendant l’avancement du projet l’évolution : des besoins des utilisateurs, du niveau des développeurs, de la technologie, etc. plan de modification tous les métiers !

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

2- L’architecture logicielle Analogie avec l’architecture dans le domaine du bâtiment Désigne un ensemble de descriptions de haut niveau (les « plans de construction »)

2- L’architecture logicielle La vue de l’architecte est générale et sert à : contrôler l’intégrité du système identifier les éléments réutilisables baser le partage du travail

2- L’architecture logicielle Plans de construction Logique Réalisation classes/dynamique composants Cas d’utilisation use case + scenarii Processus Déploiement scenarii sur composants concurrence distribution tolérance aux pannes composants projetés sur le matériel Orientation des modèles par les cas d’utilisation

2- L’architecture logicielle Une définition de la notion d’architecture « vue limitée du système permettant de comprendre : ce qu’il 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 l’architecture

3- L’organisation 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

3- L’organisation itérative des activités Cycle de base besoins analyse conception plannification implémentation évaluation test déploiement

3- L’organisation itérative des activités Contrôle de la convergence : instauration de 4 PHASES Chaque phase développe tout ou partie d’un ou plusieurs cycles Des points de contrôle entre les phases permettent de vérifier l’avancement Etude d’opportunité Elaboration Construction Transition Def. Projet objectifs risques, bénéfices Plannification architecture version béta version courante

3- L’organisation 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 …) l’existant

3- L’organisation 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 qu’ils 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

Patrons de conception Recueillir l’expertise 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 d’une application Analogie avec les plans de construction détaillés d’un élément de bâtiment

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 d’objets, avec les deux particularités : la hiérarchie est une hiérarchie d’agrégation tous les objets jusqu’au plus haut niveau présentent un même comportement (on peut leur appliquer un même ensemble de méthodes)

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 d’autres figures. Toutes les figures peuvent être dessinées, déplacées, effacées, agrandies, etc. Exemple 2 Dans un système d’exploitation, les fichiers peuvent être ordinaires, ou bien des liens, ou encore des répertoires qui contiennent eux-mêmes d’autres fichiers. Tout fichier peut être déplacé, détruit, renommé, etc.

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

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

Méthodologie objet UML et RUP : un survol IUP GMI 2ième année

Présentations similaires

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

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Méthodologie objet UML et RUP : un survol IUP GMI 2ième année

Présentations similaires

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

Présentations similaires

Notre projet

Feed-back