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

Méthodologie objet

UML et RUP : un survolIUP GMI 2ième année

2005/2006

M Huchard T. Libourelhuchard@lirmm.fr libourel@lirmm.fr

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

• Cours 1IntroductionPrésentation d’UMLModèle fonctionnel (utilisation)

• Cours 2Modèle structurel

• ANNEXESProjection vers les Bases de Données Projection vers la programmationMéthodologie (RUP)

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.

Introduction

En informatique, Résoudre le hiatus entre :

le réel

le monde informatique

• Évolutif

• Ambiguïté

• Langages codifiés

• Sémantique unique

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)

É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

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)

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

Introduction

Pour résumer …

• 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 - Unified Modeling LanguageUML - Unified Modeling Language

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

Omniprésence technique de l’Objetdans les langages de programmation, les bases de données, les interfaces graphiques, ... et les méthodes d’analyse et de conception.

Universalité de l’Objetla 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.

La portée d’UML s’explique par La portée d’UML s’explique par l’importance de l’approche par objetsl’importance de l’approche par objets

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.

Genèse d’UMLGenèse d’UML

UML (Unified Modeling Language)

OOD (Booch) OMT (Rumbaugh)OOSE (Jacobson)

OOPSLA

Autres

Autres méthodesBooch’91 OMT-1 OOSE Partenaires

Booch’93 OMT-2

OOPSLA’95Unified Method 0.8Commentaires du

public

UML 0.9 & 0.91Juin 96 puis OOPSLA’96

UML 1.0Soumission à l’OMG - Janvier 97

UML 1.1

UML 1.2

UML 1.3

Standardisation à l’OMG - Novembre 97

Version intermédiaire non publiée

Version béta - fin 99

UML 2.02003

VueCas d’utilisation

Vue structurelle

Vue architecture(déploiement)

Vue dynamique

Points de vue sur le système

Concepts généraux

Vue implémentation

<------- Logique Physique ------>

Modèle Implémentation

Modèle DynamiqueModè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 d’utilisation

Concepts généraux

ComposantsFichiers BD

Projection sur lematériel

Fonctionnalités

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 classesd’instan

Diagrammes

de déploiementde composants

Diagrammes

de collaborationde séquences

d'états, d’activités

Diagrammes

de cas d’utilisation

Concepts généraux

Analyse Conception Implémentation

Démarche uniforme sur le cycle de vie

Même notation

Concepts généraux

Les diagrammes sont majoritairement des graphes

Aspects du langage

Noeuds

Chaînes de caractères

noms, étiquettes,

mots clefs << interface >>

Contraintes

Texte libre, lge prog. OCL, etc.

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

On part de l’analyse des besoins ….

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

Trois concepts

Acteur (rôle 1)

Acteur (rôle 2)

« communicate »

Acteur

Cas d’utilisation

<< actor >>

Frontière du système

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 )

Acteur (rôle 1)

Acteur (rôle 2)

« include »« extend »

- de généralisation/spécialisation « generalizes »

Diagramme du « contexte statique »

système

Acteur (rôle 2)Acteur (rôle 1)

<< actor >>

association

Client

GestionnaireDu stock

« include » « extend »

Commander

Décrireproduits

Procéder aupaiement

« include »

Livraison

Demandecatalogue

extension

Client

« include »

Commander

Décrireproduits

Procéder aupaiement

« include »

Paiement CB Paiement cash

« specializes »

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

Descriptions complémentaires Textes, diagramme de séquences ou d’activités

Une proposition couranteSommaire 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 IHMContraintes non fonctionnelles

Temps de réponse, concurrence, ressources machine, etc.

• Cours 2

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

Objets du monde réel Objets informatiques

État Internecaché

Comportementvisible

Les objets

Modèle structurel

Comportement influe sur l'étatEtat reflète les comportements passés

Etat ---> évolue au cours du temps

Comportement ---> actions et réactions

Identité ----> essence

Sophie

Système

: Professeur

: Discipline

Deux objetsou instances

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

Classe

Attributs (propriétés)

Voiture

type : stringmarque : stringcouleur : string

titine :Voiture

type =205Peugeotrouge

Modèle structurel

Instance

Valeurs d'attributs (État)

« Est-instance-de »

Classe et Attributs (propriétés)

Voiture

type : String {changeable}marque : Stringcouleur[1..*]: Couleur = blanc

Modèle structurel

[Visibilité] nom [[multiplicité]][:type][=valeur initiale][{propriétés}]

constant

addOnly

Nom de classe, expression

[0..1]

[2..*]

+ - ~ #

Couleur

blanc:Couleur

ClasseAttributs de classe

Voiture

type : stringmarque : stringcouleur : stringnbrVoitures : intnbrRoues : int =4 {cst}

titine :Voiture

type =205Peugeotrouge

Modèle structurel

Instance Valeurs d'attributs (État) Sauf des attributs de classe

Attribut de classe ~ caractéristique partagéeRévèle souvent une modélisation à approfondir

Classe

Attributs dérivés

Personne

dateNaissance : String/age : int

julie:Personne

08/05/8815

Modèle structurel

Instance

Valeurs d'attributs (État)

{age = date du jour – date de naissance} Peut-être une opération déguisée ? (stockage optionnel)

Opérations et méthodes

Voiture

type : stringmarque : stringcouleur : 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

Classe, opérations, méthodes

Modèle structurel

[Visibilité] nom [(paramètres)][:type retour][{propriétés}]

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}

Opérations et méthodes de classe

Modèle structurel

Datejour:intmois:intannee:intnomDesMois[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

Opérations et méthodes de classe

Modèle structurel

Produit

Référence : StringPrixHT : floatTauxTVA : 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).

Association / Lien (analogie Classe / Instance)

Pays Ville

nom nom

a-pour-capitale

Association

: Paysnom=France

:Villenom = Paris

a-pour-capitale

Modèle structurel

Association / Lien (analogie Classe / Instance)

Modèle structurel

Une association est l’abstraction d’un groupe de liensdont 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 ..

Adhérent Exemplaireemprunte

DispositifDeLecture

nom d'associatio

association binaire

association ternaire

Multiplicités et rôles dans une association

Bassoc

Modèle structurel

- 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 lecontexte de assoc

Multiplicité et rôles d'une association

Société Personne

nomadresse

nomdate de nais.n°SSadresse

emploie

travaille-pour

employeur employé

travailleur

encadre

Modèle structurel

* 1..*

Modèle structurel

exactement 1Classe

Classe0..*

Classe1..*

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

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

Voiture

type : String {changeable}marque : String

Modèle structurel

Couleur1..*

Un attribut à valeur multiple est souvent référentiel

Entreprise Personne

nomadresse

nomdate de nais.adresse

quantité

Possède-des-actions

capital actionnaire

Modèle structurelClasse association

Ligne de portefeuille

* 1..*

Classe association

Utilisateur Station de travail

nom nom

Autorisation

Autorisé sur

prioritédroits

Répertoire

répertoire de rattachement

Modèle structurel

Classe d’association

Modèle structurel

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

Association qualifiée

Banque Personne

num_client

est_client

Modèle structurel

Dossier_C

Banque Personnenum_client

est_client

Navigabilité (pour la conception)

Polygone Pointcontient

Modèle structurel

{ordered}

Exprime un chemin d’accès d’un objet à un autre

Un polygone « connaît ses points »

Par défaut = bidirectionnel

Association dérivée

Société Département

Modèle structurel

Personne/travaillePourLaSociété1..*

structure

employeur

travaillePourLeDept

{Personne.employeur=Personne.dept.structure}

D’autres « abstractions »

Modèle structurel

associations particulières (composition / agrégation)

spécialisation / généralisation

Agrégation

Sémantique Collection/Élément

Forêt1

Région

Modèle structurel

Association particulière tout /partie

L’existence du composant est assujettie à celle de l’objet composite

DeptEnseignementUniversité

Composition

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

Modèle structurel

Elle relie deux éléments de modèle (classes, cas d’utilisation, méthodes)

Modèle structurel

B spécialise A ; A généralise B

Définition : L’extension de A (ses instances)contient l’extension de B

Conséquence : une instance de Bpossède les propriétés de Aéventuellement sous une forme affinée

Personne

nom adresse

Chercheur

grade adresse Exposer()

{disjoint}

Gestionnaire

numadresse

Modèle structurel

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

Modèle structurelGé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

Modèle structurel

Généralisation / Spécialisation multiple

Véhicule terrestre Véhicule aquatique

Auto Véhicule amphibie Bateau

Véhicule

milieumilieu

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

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

Modèle structurelContraintes de généralisation / Spécialisation

SalariéCdiVacataire Cotisant NonCotisant

Employé

{complet,disjoint}{incomplet}

Modèle structurelContraintes de généralisation / Spécialisation

Véhicule terrestre Véhicule aquatique

Auto Véhicule amphibie Bateau

Véhicule

milieumilieu

{incomplet,chevauchement}

Les contraintes

Exemples de contraintes sur associations

Strates

Personne Comité

préside *1

membreDe**

{subset}

{ordered}contrainte sur

extrémité d'association

contrainte entre 2 associations

Modèle structurel

actif : Real {value 0}passif : Real

Les contraintesExemple de contraintes à différents niveaux

contrainte sur classe

Personne

subordonné

<dirige

Société

{ actif = passif }

{ Personne.employeur = Personne.chef.employeur }

employeur

* 1..* 0..10..1

contrainte sur attribut

contrainte sur 2

associations

Modèle structurel

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

FenêtreGraphique Evénement

Consommer ChoixBoisson

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

JanvierFévrier ….

Personne

« crée » + Personne()+ getNom():String

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.

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.

Classes abstraites

Modèle structurel

FormeGéométrique

dessiner()déplacer(delta : Vecteur)

centre : Point

régulier : Boolean

PolygonegrandDiam : VecteurpetitDiam : Vecteur

dessiner()

opération 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

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.

Interfaces

Modèle structurel

MenuPopUp

BlocDeChoixsetDefault(o : Option)getChoice() : Option Option

setDefault(o : String)getChoice() : String

setDefault(o : Bouton)getChoice() : Bouton Bouton

String

choix1..* opérations concrétisées

«interface» interfaceopérations abstraites

réalisation

MenuBouton

Interfaces

Modèle structurel

Deux notations pour l'utilisation d'une interface

MenuPopUpsetDefault(o : Option)getChoice() : Option

«interface»

BlocDeChoix

MenuPopUp

ApplicationFenêtrée

«uses»

ApplicationFenêtrée«uses»

BlocDeChoix

interfaceinterfaceutilisationutilisation

réalise

classe utilisatriceclasse utilisatrice

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

• Cours 3

Modèle dynamiqueModèle d’implémentation

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

Modèle dynamique

diagrammes de collaboration (ou de communication)

diagrammes de séquences

diagrammes états-transitions

diagrammes d'activités

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

constructeursdestructeursappel de méthodes

Types Synchronisation

asynchrone

synchrone

retour

Les messages

Modèle dynamique

Expressions

[condition]*[condition d’itération] itération

Diagramme de collaboration

Interaction entre objets pour la réalisation d’une fonctionnalité du système

message

1: m12: m2

Modèle dynamique

L’accent est mis sur la collaboration entre objets

Diagramme d’instance d’une roue de brouette

pneu:Piece

d:Piece

rdb:Piece

Modèle dynamique

Chambre:Piece

Jante:Piece

r3:Piece

r2:Piecer1:Piece

Diagramme de collaboration – calcul du prix

pneu:Piece

d:Piece

rdb:Piece

Modèle dynamique

Chambre:Piece

Jante:Piece

r3:Piece

r2:Piecer1:Piece

1:getPrix()

2:getPrix()

3:getPrix()

3.4:getPrix() 3.3:getPrix()

3.2:getPrix()

3.1:getPrix()

Diagramme de séquencesInteraction entre objets pour la réalisation d’une fonctionnalité du système

:B :C:A

Modèle dynamique

L’accent est mis sur la chronologie des événements

La ligne de vie

« create »

Création par le message «create»

Activation de l’objet qui exécute une opération op

Destruction par un autre objet

« destroy »

Modèle dynamique

rdb pneu chambre jante

psModèle dynamique

d r1 r2 r3

getPrix()

getPrix()getPrix()

getPrix()

rdb pneu chambre jante

psModèle dynamique

d r1 r2 r3

getPrix()

getPrix()getPrix()

getPrix()

:Palmier :Feuille :Inflorescence :Régime

psModèle dynamique

Diagrammes d’états Événement et État

État d'un objetmoment 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 et État

ÉvénementStimulus (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

• Graphe

Nœud ÉtatArc 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 passeun objet d’une classe donnée

• état et événement sont duaux

un événement sépare deux états un état sépare deux événements

Modèle dynamiqueDiagrammes d'États

Modèle dynamiqueNotation des états

Initial

Simple

Complexe

Créditeur

Typing password

entry/ set echo offexit/ set echo on

on type char/ handle charon help/ display helpdo/ curseur clignote

au débutà la finlors d’evt

tout le temps

Activités internes

Diagrammes d'États

Modèle dynamique

Notation des transitions

étiquette

étiquette• événement(paramètres)• [condition]• /action• ^envoiMessage

Diagrammes d'États

État 1do/ activité 1

Événement 1 [Cond1] / Action1État 2...

Opération Activité / Action

Modèle dynamique

Avec inflorescence

création

Avec régime

Créé Avec feuille

Modèle dynamique

Diagrammes d'ÉtatsEtats d’un compte bancaire transitions gardées

sous-état

Ouvert FermédemandeCréat()

Débiteuron retrait/ agioson dépôt/ augmenter solde

fermer()

Créditeuron retrait/ debiter soldeon dépôt/ augmenter solde

[Solde >0]

[Solde ≤0]

Modèle dynamique

ouvert

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

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)

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)

Modèle dynamique

marié

célibataire

Statut familial

Enfant

Adulte

Diagrammes d’activité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

fork décision

Diagramme d’activitésModèle dynamique

Réception

Expédier produits

Exécuter

Envoi facture

FacturePaiement

Accepter paiement

[acceptée]

[rejetée]

Clôturer

Bon de commande

Traiter Commande

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

Les packages

Modèle d’implé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 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

Les packages

Classes avec fort couplage « sémantique »

de dép

endanc

Modèle d’implémentation

VenteAutomobile

Voiture

Garage

Vendeur

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

Agenda

réservation

Modèle d’implémentation (UML 2.0)Diagramme de déploiement

organisation matérielle des éléments de calcul et descomposants logiciels

Système de planification

Agenda

:server

• ANNEXES

Projection vers les Bases de DonnéesProjection vers la programmationMéthodologie (RUP)Patrons de conception

Persistance

• Classes vs Types persistants vs éphémères

• Points d’entrée (racine de persistance)

• Regroupements

Du modèle objet ... aux BDDu 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

Adéquation aux BD « objet »

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 »

Classes

AttributsAjout de l’identifiant

Schéma relationnel

ADRESSE

N°RueCPVille

Attribut Domaine Non Null

Id_adresse Identifiant OuiN° Entier NonRue String(30) Non…..

Schéma AdresseClé primaireId_adresse

Classes

AttributsAjout de l’identifiant

Schéma relationnel

PERSONNE

NSS {unique}NomPrénomDate-naissance

Id_Pers Identifiant OuiNSS String(13) OuiPrénom String(30) NonDate-nais Date Non

Schéma PersonneClés primairescandidates

Id_adresseNSS

On préfère NSS

Associations

PERSONNE ADRESSE

NSS....

N°RueCPVille

NSS String(13) ID OuiNom String(35) OuiId_adresse Identifiant Oui

Schéma PersonneClé primaireNSS

Clé étrangèreId_adresse

Associations

PERSONNE COMPTE

NSS....

N°Type

1 0..*possède

Id_compte Identifiant OuiN° String(35) Id OuiNSS Identifiant Oui

Schéma CompteClé primaire

Id-compteN°

On choisit N°

Clé étrangèreNSS

Associations

PERSONNE BIBLIOTHEQUE

NSS....

nom0..*adhère->0..*

date adhésiontype adhésion (mensuelle, annuelle)

Schéma AdhèreClé primaireNSSId_bibliothèque

Rque :DateType

NSS Id String(13) OuiId_bibliothèque Identifiant OuiDate_adhésion Date OuiType_adhésion String(10) Oui

Spécialisation

PERSONNE

NSS....

ETUDIANT

num....

ENSEIGNANT

grade....

Plusieurs choix

- « aplatir vers le haut »

Schéma PersonneClé primaireNSS

- « aplatir vers le bas »Schémas Etudiant, EnseignantClé primaireNSS

- conserver les niveaux

• ANNEXES

Du modèle objet ... à la programmationDu modèle objet ... à la programmationClasses

- 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ètretype du résultat

de l'opération

privé

protégé

public

adhérent de labibliothèquevaleurs

multiples

Du modèle objet ... à la programmationDu 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

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

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

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

Opérations

Données

MessagesEncapsulation

Retour sur la notion d’encapsulation

Liste GestionPersonnel

ajoute

retire

applique(fct)

Confiner les modifs de Liste dans la classe Liste …

Utilité de l’encapsulation

Du modèle objet ... à la programmationDu modèle objet ... à la programmationEncapsulationConsensuel

privé ... implémentationpublic ... 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 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

Accessible seulement dans les autres méthodes de la classe

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 : StringprixHT : floattauxTVA : float

setPrixHT(f:float)affichePrix()……..fixeTauxTVA(f:float)

Du modèle objet ... à la programmationDu modèle objet ... à la programmationClasses abstraites, méthodes abstraites

abstract public class Figure{

abstract public void dessine();……..

class Figure{ public:

virtual void dessine()const=0;……..

Traduction des interfaces en Java

Héritage par réalisation

Spécification de services (sans implémentation)

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 programmationDu modèle objet ... à la programmationInterfaces en Java

Ipolygon

Iquadrilateral

Isquare

Square

interface Iquadrilateral ….{static const int sideNb = 4; ….}

interface Isquare ….{float getCote(); …..}

Du modèle objet ... à la programmationDu modèle objet ... à la programmationInterfaces en Java

méthodes abstraites etpubliques (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

PERSONNE ADRESSE

nom....

N°RueCPVille

class PERSONNE{ private :

string nom; ADRESSE adr;

rien de spécial dans ADRESSE

Attribut complexe

Navigabilité dans un seul sens

Utilisationdu nom de rôle

Associations

PERSONNE COMPTE

nom....

N°Type

1 0..npossède

class PERSONNE{private :

string nom;list <COMPTE> comptes;....}

class COMPTE{private :

PERSONNE possesseur;....}

Conteneur

Référence

Navigabilité dans les deux sens

comptespossesseur

Du modèle objet ... à la programmationDu modèle objet ... à la programmationAssociations

PERSONNE BIBLIOTHEQUE

nom....

nom0..nadhère

class PERSONNE {private : string nom;....}class BIBLIOTHEQUE {private : ....}

class ADHESION{private :

PERSONNE adhérent;BIBLIOTHEQUE biblio;DATE dateadhésion; String typeAdhesion; ....}

Réification

date adhésiontype adhésion (mensuelle, annuelle)

Classe d’association

Personne

nom adresse

Gestionnaire

numadresse

Du modèle objet ... à la programmationDu modèle objet ... à la programmationL’héritage traduit la généralisation/spécialisation

C++class Personne{};class Gestionnaire

: virtual public Personne

Javapublic class Personne{}public class Gestionnaire

extends Personne {}

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 l’héritage à des fins d’implémentation ?

Implémentation de la relation de spécialisation par l’héritage, quelques problèmes ....

Héritage : adéquation des deux relations

Spécialisation multiple (possible en C++, impossible entre classes Java)

good()eof() ...

FlotEcriture

écrire(blocOctets)...

FlotLecture

lire(nbOctets)...

FlotLectureEcriture

interface Iquadrilateral extends Ipolygon{static const int sideNb = 4; ….}

interface Isquare extends Irectangle,Irhombus{float getCote(); …..}

Du modèle objet ... à la programmationDu modèle objet ... à la programmationAdéquation des deux relations (cas de Java)

héritage multipleentre interfaces

spécialisation

implémentation

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

Du modèle objet ... à la programmationDu modèle objet ... à la programmationHéritage : adéquation des deux relations (Java)

interface Flot

interface FlotEcritureinterface FlotLecture

interface FlotLectureEcritureclasse Flot

classe FlotLecture

classe FlotLectureEcriture

classe FlotEcriture

extendsimplements

Du modèle objet ... à la programmationDu modèle objet ... à la programmationSpécialisation/Généralisation ....

Conflit portant sur le nom des propriétés

Il y a clairement deux propriétés

couleur (rouge, vert ...)

Elément de jeu

Pion DéCarte à jouer

couleur (coeur, trèfle, ...)

Du modèle objet ... à la programmationDu modèle objet ... à la programmationSpécialisation/Généralisation .... multiplesConflit portant sur les valeurs

ou le domaine d’une propriété

Le pédalo n’a qu’une propriété zoneNav, mais quel sera son domaine ?

ObjetNautique

Bateau EnginPlage

Pedalo

zoneNav

{zoneNav sup. à 100}

{zoneNav inf. à 10}

{zoneNav ?}

Héritage : représentation et traitement d’un conflit de nom

Smalltalk

JavaC++

Désignation expliciteObjet::CouleurCarteAJouer::Couleur

Donner deux nomsdifférents

pas d’accès possibleà couleur d’objetautre qu’avec “super”(dans les méthodes)

mieux vaut donnerdeux noms différents

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

Héritage : surcharge statique et redéfinition

Redéfinitioncoexistence de méthodes de même nom dans des classes comparablesappel déterminé par le type de l’objet (dynamique)

Surcharge statiquecoexistence de méthodes de même nom dans des classes différentesappel déterminé par le type de la variable (statique)

Du modèle objet ... à la programmationDu modèle objet ... à la programmationHéritage : redéfinitionJava

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)

heureminutesecondes

<(Date)

jourmoisannée

Java, C++ : on ne peut pas représenter directement une spécialisation des paramètres

cas de surcharge statique

Magnitude

<(Magnitude)

heureminutesecondes

<(Magnitude)

jourmoisannée

cas de redéfinition

Héritage : à chacun sa surcharge

Personne

Princesse

habiller(Vêtement)habiller(Vêtement, Chaussure)

habiller(Vêtement, Bijou)

VêtementChaussureBijou

QuiSePorte

En Java : correctement interprété comme de la surcharge statiqueEn C++ : habiller(Vêtement, Bijou) cache les deux autres

Héritage : l’utiliser pour des raisons d’implémentation ?

ajoutFin

pushpoptop

A éviter dans tous les cas ...même si les livres en sont pleins ...

Généricité paramétrique

push(t:T)pop():Ttop():T

En C++ : template

template<typename T>class Pile{… push(T element) …}

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

Du modèle objet ... à la programmationDu modèle objet ... à la programmationA partir du modèle dynamique - diagrammes de séquencejim:Etudiant

afficheResultats()

afficheMoyenneEtMention()

[moyenne<10]afficheModulesObtenus()

public class Etudiant{ public void afficheResultats()

{afficheMoyenneEtMention();if (getMoyenne()<10)

afficheModulesObtenus();}

cnam03:Promotion

Du modèle objet ... à la programmationDu modèle objet ... à la programmationA 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<listeEtudiants.size(); i++

mg+=((Etudiant)(listeEtudiants.get(i))).moyenne();return mg/listeEtudiants.size();

• ANNEXES

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

• Implémenter

réaliser la solution informatique

• Concevoir

une 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

Analyse

Conception

Implémentation

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

Modèle de cycle en cascade

Contre : Retours sur les phases précédentes difficiles (rupture entre les phases)

Visualisation et validation tardive

Pour : Organisation simple et directe

Implémentation

Expressiondes besoins

Validationdes besoins

Validationfonctionnelle

Spécificationfonctionnelle

Conceptiondu système

Tests dusystème

Tests descomposants

Conceptiondes composants

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)

Conception

Analyse

Spécifications Besoins

Validation

Implémentation

Modèle de cycle en spirale

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

Modèle de cycle en spiralePour :

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ératifdéveloppement incrémentalpilotage par les cas d’utilisation

centré sur l’architectureconfigurable

1- Les grandes activités2- La notion d’architecture logicielle3- L’organisation itérative des activitésBibliographie

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

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)

activité 1. GESTION DE PROJET

PlannificationAllocation des tâches et des responsabilitésAllocation des ressourcesEtude de faisabilité et des risques

calendrier des tâcheschef de projet

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

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 descriptifsconception de l’interface utilisateuranalyste

activité 4. ANALYSE ET CONCEPTION

évoluer depuis la spécification des besoins

jusqu’à une solution informatique

analyse~besoins fonctionnelsconception~intègre aussi les besoins non

fonctionnels

diagrammes de classes, paquetages, sous-systèmesdiagrammes de collaboration, d’étatsdiagrammes de composantsarchitecte, concepteur

activité 5. IMPLEMENTATION

Transcription dans un langage de programmation

ou de base de donnéesUtilisation de composants existants

codeimplémenteur, développeur

activité 6. TEST

Estimer si les besoins sont satisfaitss’il y a des erreurs/défauts à

corriger

Renforcer et stabiliser l’architecture

modèles de test, scriptsconcepteur de test, testeur

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)

activité 6. TEST

Différents types de tests

• Benchmark (sur un ensemble de données type)

• Configuration/installation • Charge • Fiabilité, stress• Performance

activité 7. DEPLOIEMENT

Distribuer le logiciel dans son environnement

opérationnelInstallation, testFormation des utilisateursMigration des données

diagrammes de déploiementformateur, graphiste, rédacteur de documentation, testeur, implémenteur (scripts d’installation)

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 modificationtous les métiers !

activité 9. ENVIRONNEMENT

Activité de support du développementsélection des outils de travail,administration système et réseau,administration BD,formation de l’équipe de travail,

doc outils, doc installationadmin. S&R, formateur, admin. BD

RUP (Rational Unified Process)2- L’architecture logicielle

• Analogie avec l’architecture dans le domaine dubâtiment

• Désigne un ensemble de descriptions de haut niveau (les « plans de construction »)

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

Plans de construction

Orientation des modèles par les cas d’utilisation

Cas d’utilisation

Logique Réalisation

ProcessusDéploiement

classes/dynamique composants

use case + scenarii

scenarii sur composantsconcurrencedistributiontolérance aux pannes

composantsprojetés sur le matériel

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

RUP (Rational Unified Process)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

Cycle de base

plannification

besoins analyseconceptionimplémentation

déploiementtestévaluation

Contrôle de la convergence : instauration de 4 PHASES

Etude d’opportunité

ElaborationConstructionTransition

• 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

Def. Projetobjectifsrisques, bénéfices

Plannificationarchitecture

versionbéta

versioncourante

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

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

• ANNEXES

Patrons de conception

Recueillir l’expertise en conception

Définition

Un patron de conception est une solution de conceptiongé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

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)

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 conceptionRésumé du patron « objets composite »Solution générique [E. Gamma et al. « design patterns », 94]

version dite « sécurité »

Composant

+ operation

abstraitesi pas de partie commune

Feuille

+ operation

Composite

+ operation+ ajout(c:Composant)

appliquer operationà tous les fils

Patrons de conceptionRé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

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

Documents

1 Conduite de projets (informatiques) Eric Bourreau Thérèse Libourel FMIN114 W312TSS1

Mémoire de Stage de Master - Page d'accueil / Lirmm.fr

Coordination et interaction dans une société d' agents autonomes GOUAICH Abdelkader gouaich(at)lirmm.fr LIRMM, Montpellier

Le raisonnement mécanisé Joël Quinqueton, jq@lirmm.fr

Abdelhak-Djamel Seriai seriai@lirmm.fr …seriai/uploads/Enseignement/coursEvolution1.pdf · Lois de l'evolution logicielle ... realisee a partir de l’analyse directe d’un code

Modelica - lirmm.fr

©2008 Landrault Christian LANDRAULT landraul@lirmm.fr Laboratoire dInformatique, de Robotique et de Microélectronique de Montpellier (LIRMM) TEST ET TESTABILITE

Bilan - lirmm.fr · Optimisations pour la vitesse : recherche de sous-expressions communes, élimination de code mort ou inaccessible, déplacement des invariants de boucle

Analyseformellededonnéesrelationnellespour la …huchard/Documents/Papiers/LMO07-rouane-etal-final.pdf · 150 LMO 2007. 1. Introduction En modélisation conceptuelle, en particulier

1 Le mécanisme des exceptions GLIN505 – L3 – 2011 M. Huchard Qu'est-ce qu'une exception? Comment définir et signaler des exceptions? Comment récupérer

Introduction aux Websockets - Page d'accueil / Lirmm.fr / - lirmmtibermacin/ens/ws/expose.pdf · 2017-03-02 · Clients de Websockets Théoriquement, un client peut être écrit dans

BASES de DONNEES - Page d'accueil / Lirmm.fr / - …retore/DOCSBD/novelli_intro_bd.pdfRemarque : une valeur inexistante dans la base de données est appelée valeur nulle (NULL) (valeur

Introduction à C# - lirmm.fr · • Les tableaux héritent de System.Array ... une valeur à l'objet énumérateur ou signaler la fin de l'itération. –yield return ;

Moussab BENNEHAR - Page d'accueil / Lirmm.fr / - lirmmchemori/Temp/Francois/CST_1_Bennehar… · · 2016-05-24IV.Résultats: application au robot Dual- V ... • Dual-V (modèles

ProgrammationWeb - lirmm.frcroitoru/WebCourse-A2-week1.pdf · Transparents du cours et feuilles de TP disponibles chaque semaine sur croitoru Questions: croitoru@lirmm.fr. Quelques

Spécification et qualité du logiciel Resp.E. Bourreau Interv.M. Leclère leclere@lirmm.frleclere@lirmm.fr T. Libourel C. Nebut

Genie Logiciel - Page d'accueil / Lirmm.fr / - lirmmcroitoru/teaching/GL-Week1-C.pdf · • des arcs de transition permettant de relier les nœuds. Diagrammes d'état/transition •Les

Paludisme grave de l’adulte en réanimation · Faculté Xavier-Bichat, 46, rue Henri-Huchard, 75877 Paris, France ... transmission par greffe d’organe, paludisme congénital)

Test de Systèmes Intégrés Digitaux et Mixtes Arnaud Virazel virazel@lirmm.fr

UML T. Libourel Autour des objets et du formalisme UML T. Libourel libourel@lirmm.fr