Modélisation par Objets - Introduction - De Merise à UML

ACSIModélisation par Objets

À destination des étudiants du 2e année IUT Nice-Sophia Antipolis

1

Mireille Blay-FornarinoIUT Nice-Sophia Antipolis

[email protected]://www.polytech.unice.fr/~blay

Site web du module : http://anubis.polytech.unice.fr/iut/2010_2011/s3/omgl/mod-si/start

mercredi 8 septembre 2010

mailto:[email protected]

mailto:[email protected]

http://www.polytech.unice.fr/~blay

http://www.polytech.unice.fr/~blay

http://anubis.polytech.unice.fr/iut/2010_2011/s3/omgl/mod-si/start

http://anubis.polytech.unice.fr/iut/2010_2011/s3/omgl/mod-si/start

Modélisation par

Objets2


Modélisation & 0bjetsQuizSur la base du

Essentials of Visual Modeling with UML 2.0Module 3a: VM Quiz Show

IBM

Parlons-nous le même langage ?


4

Question

Un modèle. . .?

A. doit être structurel et comportemental. B. est inutile si les membres d’une équipe savent

programmerC.est une simplification de la réalité.D.est une excuse pour retarder le développement

Réponse :


5

QuestionPourquoi modéliser? Pour ...

A.Aider à visualiser un systèmeB.Documenter nos décisionsC.Comprendre et cerner les besoins fonctionnels et

techniquesD.Faciliter la planificationE.Toutes ces réponses

Réponse :

Question


6

A votre connaissance, à partir d’un modèle, avec des outils, on peut. . .?

A. obtenir une bonne noteB.produire de la documentationC.produire des squelettes de codeD.produire du codeE. valider une spécificationF. simuler un systèmeG.autre

Réponse :

Question


7

Question

La modélisation s’arrête quand ?A. on commence à développerB. le prof n’est plus là pour l’exigerC.tout le système a été modéliséD.on a fini de représenter la réalitéE. on n’a plus d’argentF. le système s’arrête

Réponse :

Question


8

QuestionLa technologie objet est . . . ?

A.Une nouvelle théorie cherchant à se faire accepter.B.Un nouveau langage dynamique inventé par Grady

Booch.C.basée sur des principes de décomposition

fonctionnelleD. Un ensemble de principes guidant le développement du logicielE. faire compliqué quand on peut faire simple

Réponse :


9

QuestionUn objet . . . ?

A.a un état défini par la valeur de ses attributsB.a une identité qui doit correspondre à une clef dans

une BDC.est identifié par une référenceD.peut recevoir des messages

Réponse :


10

Pour communiquer avec un objet, je ....?

A. lui envoie des messagesB. le stocke dans une base de donnéesC.modifie la valeur de ses attributs

Réponse :

Question


11

Une classe . . . ?A. est une encapsulation d’un objet;B. représente la hiérarchie d’un objet;C.représente un ensemble d’objets;D.est une instance d’un objet;E. est une définition abstraite d’un object.

Réponse :

Question


12

Une classe définit . . . ?

A. les données portées par les objetsB. les comportements des objetsC. la manière de créer un objet

Réponse :

Question


13

Pour créer un objet, je dois ....?A. demander à un autre objet de le créerB. demander à sa classeC.demander à une base de donnéesD. lui parlerE. lui envoyer un message

Réponse :

Question


14

QuestionL’encapsulation . . . ?

Réponse :

A. est souvent vue comme un moyen de cacher les données dans des entités logicielles

B. empêche les codes de s’abîmerC.facilite les modifications d’implémentationsD.engendre une gestion difficile de l’évolution


15

QuestionQuelle phrase traduit le mieux la

Généralisation . . . ?

Réponse :

A. “Est une partie de”B. “Est une sorte de”C.“Est un réplica de”D.“Est un héritage de”


16

QuestionL’héritage . . . ?

Réponse :

A. permet de déclarer des propriétés une fois et que les sous-classes les connaissent.

B. offre la possibilité de toucher dans l'âge adulte les sommes qu'on vous a refusées dans votre jeunesse.

C.améliore la productivité D.améliore la maintenanceE.accroît la complexité


http://www.evene.fr/citations/mot.php?mot=possibilite

http://www.evene.fr/citations/mot.php?mot=possibilite

http://www.evene.fr/citations/mot.php?mot=toucher

http://www.evene.fr/citations/mot.php?mot=toucher

http://www.evene.fr/citations/mot.php?mot=age

http://www.evene.fr/citations/mot.php?mot=age

http://www.evene.fr/citations/mot.php?mot=adulte

http://www.evene.fr/citations/mot.php?mot=adulte

http://www.evene.fr/citations/mot.php?mot=sommes

http://www.evene.fr/citations/mot.php?mot=sommes

http://www.evene.fr/citations/mot.php?mot=jeunesse

http://www.evene.fr/citations/mot.php?mot=jeunesse

Intro. Intro. UML De Merise à UML

09/10 /99

Plan

Problèmes du développement logicielHistoire brève jusqu’aux limites de la programmation structurée

Du bidouillage au Génie logiciel

Introduction à UMLUn peu d’histoire

Survol

De Merise à UMLPrésentation du Module

17mercredi 8 septembre 2010

I. Quels sont les problèmes du développement logiciel?

18



Un peu d’histoire

19



09/10 /99

La gestion progressive de la complexitéPremiers programmes en langage machine

Les premiers programmes, écrits en langage machine, dépendaient fortement de l'architecture des ordinateurs utilisés.

20

sub $sp, $sp, 4sw r,0($sp)

✓histoire



09/10 /99

Lorsque le nombre d'architectures différentes a augmenté, un premier effort a été produit pour séparer les concepts manipulés dans les langages de leur représentation dans la machine et a abouti à la création de langages comme FORTRAN.

21

La gestion progressive de la complexitéProgrammation en langages évolués

PROGRAM DEGRAD ! ! Imprime une table de conversion degrés -> radians ! ================================================= ! ! Déclaration des variables INTEGER DEG REAL RAD, COEFF ! ! En-tête de programme WRITE ( *, 10) 10 FORMAT (' ',20('*') / & & ' * Degres * Radians *' / & & ' ', 20('*') ) ! ! Corps de programme COEFF = (2.0 * 3.1416) / 360.0 DO DEG = 0, 90 RAD = DEG * COEFF WRITE ( *, 20) DEG, RAD 20 FORMAT (' * ',I4,' * ',F7.5,' *') END DO ! ! Fin du tableau WRITE ( *, 30) 30 FORMAT (' ',20('*') ) ! ! Fin de programme STOP END PROGRAM DEGRAD

✓histoire


http://upload.wikimedia.org/wikipedia/en/0/07/Fortran_acs_cover.jpeg

http://upload.wikimedia.org/wikipedia/en/0/07/Fortran_acs_cover.jpeg


09/10 /99

La complexité croissante des programmes a de nouveau suscité un effort pour mieux structurer les programmes (abandon du goto et de la programmation spaghetti)

Les méthodes d'analyse consistait alors à «diviser pour mieux régner», i.e. à découper les tâches en modules indépendants.

Niklaus Wirth va plus loin : les programmes sont la «somme» d'une structure de données et d'un ensemble distinct d'algorithmes chargés de les manipuler.

➡La programmation structurée étaient a lors synonyme de programmation dirigée par les traitements.

22

La gestion progressive de la complexitéMéthode d’analyse par décomposition

function ConstruitPhrase(phrase:string):string;var s : string;begin readln(s); ConstruitPhrase:=phrase+', '+s;end;

var Phrase : string;begin Phrase:=''; {initialiser à chaîne vide} {premier mot} writeln('Entrez un mot :'); Phrase:=ConstruitPhrase(Phrase);

✓histoire



09/10 /99

Le coût du matériel informatique a fortement décru et ce matériel est devenu un bien de consommation courant (tant dans des entreprises et des universités que chez les particuliers).

La clientèle s'est diversifiée, les besoins ont explosé.

23

La gestion progressive de la complexitéL’explosion des besoins

✓histoire



09/10 /99

La programmation structurée nécessite de faire des hypothèses sur les données à traiter. La structure physique des données à traiter est diffusée dans une part importante du code.

Une simple modification des exigences des utilisateurs ou une modification des données peut entraîner d'importantes modifications au niveau des codes chargés de les traiter.

Par exemple, en 1982, les postes américaines sont passés du code postal à 5 chiffres à celui à 9 chiffres. Beaucoup de programmes gérant des fichiers d'adresses ont dû être récrits à grands frais.

24

Limites de la programmation structuréeLa diffusion de la structure des données

dans le code

✓histoire



09/10 /99

Pour répondre à ces besoins croissants, la programmation a connu une évolution et une montée en abstraction encore plus importante :

25

Et aprèsEncapsuler, assembler, réutiliser

Objets, Composants, Services, Composants as Services, Génération des codes à partir de modèles,

Frameworks, Usines logicielles, ....

Mais le plus important des changements de «méthodes» de développement...

✓histoire



Du bidouillage au génie logiel

26



09/10 /9927

Problématique du génie logiciel

➡ Programming-in-the-SmallProblème de la qualité interne d'un composant

➡ Programming-in-the-LargeFaire face à la construction de systèmes de plus en plus gros : non spécifique au logiciel, mais aggravé par sa “mollesse”.

Problème de gestion de la complexité, de communication, etc.

Maîtrise du processus de développement: délais, coûts, qualité.

Programming-in-the-DurationProblème de la maintenance corrective et évolutive.

Notion de ligne de produits.

Pr. Jean-Marc Jézéquel



09/10 /9928

Programming-in-the-Small


Acquérir une valeur positive nTant que n > 1 faire

si n est pair alors n := n / 2 sinon n := 3n+1Sonner alarme;

Prouver que le prog. termine pour tout n?-> Indécidabilité de certaines propriétés

Recours au test– ici, si machine 32 bits, 2^31 = 10^10 cas de tests

– 5 lignes de code => 10 milliards de tests !

Problème de la validité du logiciel

✓Validation✓Prog. Small



09/10 /9929

Produire des programmes prouvésC’est possible…

On peut construire des programmes de tel manière qu’ils soient prouvablesEn partie automatisable (Atelier B, etc.)

Outils spécifiques

…mais coûteuxPreuve au moins aussi complexe que le codeAutant de chances de se tromper dans la preuve…

En pratique :Réservé à des (petits) sous-systèmes (très) critiquesRecours aux tests pour le reste

Programming-in-the-Small✓Validation✓Prog. Small



09/10 /9930

Assertions

Syntaxe JML/**

* @param double x réel positif* @result double racine carrée de x

*//*@

@ requires x >= 0.0 ;@ ensures x == \result * \result ;

@*/public static double sqrt(double x) {

Postconditions : Ce qui est satisfait en cas de retour

normal

Invariant = propriété toujours vraie quelque soit l’état du système

Préconditions : Ce qui doit être satisfait pour appeler la méthode

Programming-in-the-Small✓Validation✓Prog. Small



09/10 /9931

Gérer la complexité due à la taille


a)

b)

c)

d)

Si l'automobile avait suivi le même développement que l'ordinateur, une Rolls-Royce coûterait aujourd'hui 100$, pourrait rouler un million de kilomètres avec un litre d'essence, et exploserait une fois par an en tuant tout le monde à bord. Robert Cringely.

Programming-in-the-Large✓Complexité✓Prog. Large



09/10 /9932

Augmentation exponentielle de la taille du logicielProgramming-in-the-Large

✓Complexité✓Prog. Large



09/10 /9933

ATT (1990): interruption du service téléphonie pendant 5 heures à l'Est des Etats-Unis.

Aéroport de Denver, 1993-1995:logiciel de suivi des bagages, coût 3 milliards de $, retard de 18 mois.

National Cancer Institute, Panama City,2000 : Logiciel non adapté aux médecins => 8 morts, 20 personnes “surexposées”.etc., etc.

Out of range

Premier vol d’Ariane 5 (1996)

Echecs logicielsProgramming-in-the-Large

✓Complexité✓Prog. Large



09/10 /9934

Gestion de la complexité due à la taille : diviser pour résoudre

Aspects techniquesen s'appuyant techniquement sur la modularité

« Encapsulation et masquage d'information, faible couplage »Importance de la notion d’Objets

Aspects organisationnelsS’organiser au delà de la réalisation : méthodes

« Analyse, conception »« Validation et vérification »

Ingénierie de la conduite de projet = compromis entrerespect des délaisrespect des coûtsréponse aux besoins/assurance qualité

Problèmes de gestion de ressources (humaines, etc.) etde synchronisation entre tâches

✓Diviser✓Prog. Large



09/10 /9935

Gestion de l’évolution d'un système

D’après Swanson & Beath (Maintaining Information Systems in Organizations, 1989)

Durée de vie moyenne d’un système : 6.6 ans 26% des systèmes sont âgés de plus de 10 ans

Problème de la maintenance corrective et évolutiveAdaptation aux changements des besoinsAdaptation aux changements de l’environnement

Support nouvelles plateformes, bug « an 2000 »

Programming-in-the-Duration✓Prog. Durée



09/10 /9936

Problème de la maintenabilitéExemple critique dû à M. Jackson

Barques à louer sur un lacEnregistrement des départs (S) et retours (E) sur un terminal, avec horodatage automatique

On veut chaque jour un rapport avec :le nombre de sessionsla durée moyenne d'une session

Programming-in-the-Duration✓Maintenance✓Prog. Durée



09/10 /9937

Décomposition fonctionnelle en 1980Structured Analysis and Design technique : SADT

Le système a une fonction…Décomposée récursivement en sous-fonctions…

Jusqu’à tomber sur des fonctions élémentaires

Reliées par flots de données

∑(

Approche « droit au but »Programming-in-the-Duration

✓Maintenance✓Prog. Durée



09/10 /9938

RéalisationProgramming-in-the-Duration

✓Maintenance✓Prog. Durée



09/10 /9939

Demandes de modifications :durée de la session la plus longueun état pour le matin, un autre pour le soircorriger la perte de S ou de E

MaintenanceProgramming-in-the-Duration✓Prog. Durée✓Maintenance

Dans la réalité, c’est pire!Nokia rapporte à propos de son infrastructure GSM

50% des exigences (besoins numérotés) ont changé après le gel du cahier des charges60% de ceux-ci ont changé au moins 2 fois!

C’est le cas général plutôt que l’exception

Cahier des charges figé = rêve des années 70



09/10 /9940

Coût de la MaintenanceProgramming-in-the-Duration

✓Prog. Durée✓Maintenance



09/10 /9941

La découpe fonctionnelle d'un problème informatique : une approche intuitive

Factorisation

✓Prog. Durée ✓Vers l’objet



09/10 /9942

Le revers de la médaille : maintenance complexe en cas d'évolution

La séparation des données et des traitements : le piège !

✓Vers l’objet✓Prog. Durée

->mercredi 8 septembre 2010


09/10 /9943

Réunir données et traitements : Programmation par objets




09/10 /9944

Vision objet du système informatique (1)

➡ Le système d ’informatique est modélisé comme un ensemble d ’objets, avec leurs propriétés et leurs comportements, qui collaborent entre eux

• Un objet est une entité aux frontières précises• Un ensemble d'attributs caractérise l'état de l'objet. • Un ensemble d'opérations (méthodes ou comportements) en définit le comportement.




09/10 /9945


➡ Un objet est une instance de classe (une occurrence d'un type abstrait).

➡ Une classe est un type de données abstrait (modèle) , caractérisé par des propriétés (attributs et méthodes) communes à des objets et permettant de créer des objets possédant ces propriétés.




09/10 /9946


➡ Héritage (et polymorphisme)L'héritage est un mécanisme de transmission des propriétés

d'une classe (ses attributs et méthodes) vers une sous-classe.




09/10 /9947


➡ Héritage (et polymorphisme)Le polymorphisme représente la faculté d'une méthode à pouvoir s'appliquer à des objets de classes différentes.




09/10 /99

Approche orientée-objet

48Illustration de Jean-Marc Estay (IMA)



09/10 /9949

L'approche objet : une solution parfaite ?

L'approche objet est moins intuitive que l'approche fonctionnelle !

➡ Quels moyens utiliser pour faciliter l'analyse objet ? ➡ Quels critères identifient une conception objet

pertinente ?

L'application des concepts objets nécessite une grande rigueur !

➡ Le vocabulaire est précis (risques d'ambiguïtés, d'incompréhensions).

➡ Comment décrire la structure objet d'un système de manière pertinente ?




09/10 /9950

Quels sont les remèdes aux inconvénients de l'approche objet ?Modéliser avec un langage pour exprimer les concepts objet afin de

pouvoir :➡ Représenter des concepts abstraits (graphiquement par exemple…). ➡ Limiter les ambiguïtés (parler un langage commun). ➡ Faciliter l'analyse (simplifier la comparaison et l'évaluation de

solutions).

Une démarche d'analyse et de conception objet, pour :➡ Ne pas effectuer une analyse fonctionnelle et se contenter d'une

implémentation objet, mais penser objet dès le départ. ➡ Définir les vues qui permettent de couvrir tous les aspects d'un

système, avec des concepts objets.




09/10 /9951

Aspects techniquesAssurer une meilleure continuité entre

Domaine du problème

Domaine des solutions

Définir les fonctionnalitésPrévoir les scénarios de tests

Maintenance traitée comme le développement initial

Aspects organisationnelsTraçabilitéGestion contrôlée des changements Utilisation de

Méthodes «Agiles»

Solution : approche par modélisationProgramming-in-the-Duration✓Prog. Durée



09/10 /9952

Problématique du génie logiciel

WHAT IS SOFTWARE ENGINEERING?The IEEE Computer Society defines software engineering as“(1) The application of a systematic, disciplined, quantifiable

approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

(2) The study of approaches as in (1).”

http://www.swebok.org/


III. Introduction à UML

53


III. Introduction à UML UML, histoire, généralité

54



09/10 /9955

Pourquoi UML ?➡ Objectifs : spécifier, construire, visualiser et documenter les

systèmes à base de logiciel Pour communiquer, travailler à plusieurs

Pour comprendre la « big picture »

Par approche orientée objets

Avec différents modèles pour différentes vues

➡ UML : Langage et non simple notation graphique (ni méthode)➡ UML est Indépendant des méthodologies

✓Histoire



09/10 /9956

Un peu d’histoire :La guerre des Méthodes

Booch, OMT, Coad/Yourdon, Fusion,SADT, OOSE, Schlaer/Mellor, HOOD…

UML: un méta-langage de modélisation pour unifier les modèles utilisés dans les méthodes

✓Histoire✓Histoire



09/10 /9957

Et un langage unique, un !

(...mais pas toutes, p. ex. RdP, SADT/IDEF0, DFD, etc.)

Un cocktail de notations éprouvées.

Auteurs : Grady Booch, Ivar Jacobson, James Rumbaugh.

Standardisation OMG (Object Management Group) en 1997

Promoteurs : Rational Software, Oracle

Hp, Microsoft, IBM

✓Histoire



09/10 /9958

➡ Modèle : simplification de la réalité dont les buts sont

Visualiser le système

Documenter les décisions

Aider à la constructiondu système

Spécifier lastructure et le comportement

du système

Qu’est-ce qu’UML ? un support à la modélisation



09/10 /9959

Qu’est-ce qu’UML ?➡ UML est un langage «visuel»➡ Il supporte

La visualisationLa spécificationLa constructionLa documentation

Syntaxe et sémantiqueDescriptions graphiques et textuellesArchitecture et comportementGénération de code

Jean-Paul Rigault 2005

UML n’est pas une méthodologie de développement, contrairement à RUP (Rational Unified Process).

✓Histoire

On ne décrit pas l’univers tout entier…Le logiciel joue un rôle majeur



09/10 /99

• diagramme de classes

• diagramme d’objets

• diagramme de composants

• diagramme de déploiement

Statique (ce que le système EST)

• diagramme de séquences

• diagramme de collaboration

• diagramme d’états-transitions

• diagramme d’activités

Fonctionnel (ce que le système

FAIT)

Dynamique(comment le système

EVOLUE)

• diagramme de cas d’utilisation

• diagramme de collaboration

60

Qu’est-ce qu’UML ? Axes de modélisation d ’un système

✓Histoire



09/10 /9961

Les points forts d'UML

UML est un langage normaliségain de précision gage de stabilité encourage l'utilisation d'outils

UML est un support de communication performantIl cadre l'analyse. Il facilite la compréhension de représentations abstraites complexes. Son caractère polyvalent et sa souplesse en font un langage universel.

✓Histoire



09/10 /9962

Les points faibles d'UML

La mise en pratique d'UML nécessite un apprentissage et passe par une période d'adaptation.

Le processus (non couvert par UML) est une autre clé de la réussite d'un projet.

✓Histoire


III. Introduction à UML survol

63



09/10 /9964

SystèmeDeContrôleDAcces

CapteurAIncendie

PorteurDeCarte

EntrerDébloquerLesPortes

GérerLesCartesAdministrateur

ListerLesTentativesDeFraudes

Gardien

Sortir

Qu’est-ce qu’UML ? Diagrammes des cas d’utilisation

✓Survol

Ce diagramme montre ce que que fait le système et qui l’utilise



09/10 /9965

Qu’est-ce qu’UML ? Diagrammes de séquence

le compte de P.le distrib. la banquepaul

retirer(500)

débiter(500)

la carte de P.

lireN°Compte()

la reserve

retirerDeLArgent(500,88219)

sortirDesBillets(5)

sortirBillets ()

✓Survol

Ce diagramme montre les flots de communications



09/10 /9966

Qu’est-ce qu’UML ? Diagrammes de collaboration

le compte de paul

le distributeur la banque

la carte de P.

la reserve de billets

paul

4 : débiter(500)1 : retirer(500)

2 : lireN°Compte()

3 : retirerDeLArgent (500,88219)

6 : prendreBillet()

5 : sortirDesBillets(5)

88219

✓Survol



09/10 /9967

Qu’est-ce qu’UML ? Diagrammes de classes

Client1..4 1..*titulaires

Consortium

Comptenumérosolde...

1..*

0..*

1

Banquenuméronom

Distributeur 0..*

1

0..*

1..*

signataire1

0..* CarteBleue

CoderetraitMax

1..*AcceptéPar>

✓Survol

Ce diagramme montre les classes et les relations entre elles



09/10 /9968

Qu’est-ce qu’UML ? Diagrammes d’objets

c1 : Compte

c2 : Compte

paul : Client

pierre : Client

marie : Client c3 : Compte

titulaires

titulaires

: CarteBleue

titulaires

titulaires

signataire

: CarteBleue

sophie : Client

: Banque

: Banque

fred : Client c4 : Comptetitulaires

: Banque

signataire

: Consortium

: Consortium

: Distributeur

: CarteBleuesignataire

: Distributeur

EstAcceptéPar>

EstAcceptéPar>

EstAcceptéPar>

✓Survol

Ce diagramme montre les instances et les liens entre elles à l’exécution.



09/10 /9969

Qu’est-ce qu’UML ? Diagrammes d’états

En attente En attente du code

En vérification

En attente du montant

carte insérée

code frappémauvais code

En distribution

code bon

En attente retrait carte

carte retirée

montant correct

montant incorrect

billets retirés

✓Survol

Pour expliciter les attentes

d’évènements & les différents

états d’un objet.



09/10 /9970

➡ Mode esquisse (sketch)Informelle, incomplète

Souvent manuelle (tableau)

➡ Mode plan (blue print)Diagrammes détaillés

Production de documents

Pro- et rétro-ingénierie

➡ Mode langage de programmationSpécification complète et exécutablePas vraiment disponible actuellement !

Jean-Paul Rigault 2005

Qu’est-ce qu’UML ? Divers modes d’utilisation

✓Survol✓Survol



09/10 /9971

Unified Process (UP)

➡ UML se veut indépendant de toute méthodologie➡ Cependant, il est mieux adapté à un processus (tel le RUP)

dirigé par les cas d’utilisation (use-case driven)centré sur l’architecture (architecture centric)itératif et incrémental

➡ Le UP propose en outredes techniques de modélisation pour les différentes phases et activitésune organisation des rôles et des flots lors du processus de développement

A venir dans le cours

✓Survol


IV. De Merise à UMLen bref

72

Attention UML n’est pas une méthode :Nous étudions uniquement ici le support de Merise par UML



09/10 /99

Les principes de Merise Approche systémique

Un système = Un ensemble d’éléments en interaction organisés en fonction d’un but. Un système transforme des éléments reçus en entrée (inputs) en éléments de sortie (outputs) par des actions (processus). Il peut être contrôlé et régulé par un système de pilotage.

Intègre les notions de limites du système à étudier, découpage en sous-ensembles, finalité, buts, objectifs et interactions.

Prise en charge par les cas d’utilisation en UML: - Le système est considéré comme une boîte noire qui réagit à des sollicitations extérieurs par des «acteurs».- Chaque cas d’utilisation est modélisé par des collaborations représentant ainsi la dynamique du système.



09/10 /99

Les principes de Merise

Cycle de vie : il mène du point de départ à l’exploitation du système, en passant par sa création, sa maturité et sa maintenance.

Cycle de décision : Il représente l’ensemble des choix qui doivent être fait durant le déroulement du cycle de vie.

Cycle d’abstraction : niveaux conceptuel, organisationnel, physique.

Cycles de construction du SI



09/10 /99


Non défini par UML, mais une approche itérative et incrémentale guidée par les use-cases & l’architecture sous-tend.

UML supporte la modélisation des différents niveaux par différents types de

diagrammes : use-case, classes, composants, noeuds, ...

A l’utilisateur de décider du bon modèle au bon niveau...l’architecture.

UML cible une intervention des utilisateurs aux tâches d’analyse et

conception.

Cycles de construction du SI

75

Cycle de vie : il mène du point de départ à l’exploitation du système, en passant par sa création, sa maturité et sa maintenance.

Cycle de décision : Il représente l’ensemble des choix qui doivent être fait durant le déroulement du cycle de vie.

Cycle d’abstraction : niveaux conceptuel, organisationnel, physique.



09/10 /99


Le problème est décomposé en activités, décomposées en fonctions, décomposées en règles de gestion.

Les règles se décomposent en modules.

Des diagrammes de fonctions

UML n’utilise pas une approche fonctionnelle.

Les diagrammes d’utilisations font place aux fonctions en plaçant les besoins dans

un contexte réel.Des diagrammes d’interactions explicitent

les scenarios des cas d’utilisation.Des diagrammes d’activités décrivent les

activités dans les processus métier.Les besoins sont portés par des classes

donnant naissance à des composant réutilisables.

Approche fonctionnelle



09/10 /99


Merise considère le système réel selon un point de vue statique (les données) et un point de vue dynamique (les traitements).

Validation des données par liaison aux traitements

Merise est une méthode de type "descendante"

( TOP -DOWN )

- L’approche objet associe les informations et les traitements assurant

ainsi une certaine cohérence.- Les scénarios permettent de valider les

classes. - Il est possible d’ajouter des contrôles

pour s’assurer que les besoins utilisateurs sont respectés.

- La place des use-cases est prépondérante pour assurer la cohérence

d’un ensemble.

- UML supporte une approche aussi bien descendante qu’ascendante.

Approche données-traitements



09/10 /99

Modélisation du métierUn acteur représente une entité active intervenant dans le fonctionnement de l’entreprise :

Client, Fournisseurs, (acteur externe)

Un domaine de l’entreprise (Gestion Personnel, Comptabilité)

Le système de pilotage.

Distinction entre acteur externe et interne

Pour UML au niveau métier l’acteur est de fait externe.De manière plus précise, les acteurs sont analysés en fonction de

leur rôle par rapport au périmètre d’étude.

Acteurs



09/10 /99

Modélisation du métier

L’analyse des flux permet de représenter le fonctionnement global de l’entreprise

Un flux de données est la représentation d’un échange d’informations entre deux acteurs. Il est un support de communication avec les utilisateurs.

Le diagramme des flux est une représentation graphique des acteurs et des flux . Il est construit par itération.

En UML les use-cases ne capturent que les liens de haut niveau pas les échanges, par contre il précise le rôle des acteurs.

Au niveau interne les diagrammes de séquences et d’activités permettent de représenter les flux en s’orientant davantage vers

une décomposition pour ce dernier en terme de fonctions.

Flux



09/10 /99

Modélisation du métier Flux



09/10 /99

Modélisation du métier Diagramme de Cas d’utilisation



09/10 /99

Modélisation du métier Diagramme de Séquence



09/10 /99


Le Modèle conceptuel des données (MCD) et le diagramme de classes possèdent beaucoup de points communs et une approche de structuration similaire.

En UML le diagramme de classes est utilisé au cours del’ensemble du processus:

• Les classes contiennent les opérations (services),• Les contraintes sont exprimées dans un langage de contrainte (OCL),

• UML propose des stéréotypes,• UML n’implique pas l’utilisation d’un formalisme de normalisation sur les classes, mais des règles sont à respecter pour éviter les erreurs.

Niveau conceptuel

83

Nous les comparerons en détail dans un prochain cours



09/10 /99


Le Modèle conceptuel des données (MCD)

Niveau conceptuel



09/10 /99


Le Diagramme de classes

Niveau conceptuel

85

Pas forcément celui-ci



09/10 /99


Etats-transitions - cycle de vie (comportement)*

Dans Merise le cycle de vie des objets (CVO) traduit les différents états que peut prendre l'entité, leur succession, les événements déclencheurs

UML fournit un diagramme états-transitions qui corresponddirectement au CVO:

• Il s'agit des modèles les plus proches,• UML propose des concepts de sous-états, de macro-états, d'états

parallèles et détaille d'avantage les actions et les opérations,• Ce diagramme est lié au diagramme de classe.

Niveau conceptuel

86Nous les comparerons en détail dans un prochain cours



09/10 /99


Cycle de vie des objets (CVO)

Niveau conceptuel



09/10 /99


Diagramme d’états-transitions

Niveau conceptuel



09/10 /99


Dans le Modèle conceptuel des traitements (MCT), on trouve les concepts d'événements, de règles de gestion, de synchronisation et d'opérations qui réutilisent la notion de flux.

En UML, événements internes et externes apparaissent auniveau des diagrammes séquences/activités.

• Les règles de gestion apparaissent dans les contraintes OCL et dans les méthodes des classes,

• Les synchronisations apparaissent dans les diagrammes d'activités et d'états-transitions,

• Les opérations sont représentées dans les diagrammes d'activités.

En résumé: pour retrouver les informations d'un MCT, il faut jongler avec différents diagrammes en UML !!!

Niveau conceptuel



09/10 /99

Modélisation du métierModèle conceptuel des traitements (MCT)



09/10 /99

Modélisation du métierDiagramme d’activités et de séquence



09/10 /99

Modélisation du métierDiagramme d’activités et de séquence



09/10 /99


La formalisation organisationelle vise à Spécifier l’organisation qui régira les données et traitements

Modèle Organisationnel des Traitements (MOT) : complète le MCT avec les acteurs, temps, types d’opérations

Modèle Logique des Données (MLD) fait suite au MCD

En UML, les aspects dynamiques apparaissent là encore dans les diagrammes d'activités/séquences:

• Ils servent directement pour le passage du métier au système informatique,

• Les échanges et les attentes apparaissent clairement dans les activités,➡ Merise offre une vision plus globale de l'organisation.

Niveau organisationnel



09/10 /99

La démarche & les modèlesMerise adopte un nombre important de formalismes pour modéliser le métier, mais il y a des ruptures pour le passage au modèle logique,

UML propose un nombre important de concepts et de diagrammes qui suivent le processus de développement du métier au système informatique.

94

– Cas d'utilisation et modèle de contexte ne sont pas équivalents,

– Diagramme de classes et MCD sont voisins, mais les classes ne sont pas que conceptuels (métier et logique).

– Diagramme de séquence/activité et modèle de contexte et de flux partagent des points communs,

– Le diagramme d'états-transition se retrouve en Merise,– Diagramme de composants ne se retrouve pas directement dans un modèle en

Merise,– Diagramme de déploiement est proche du modèle d'architecture



09/10 /99

De l’analyse à la conception...en UML

95

1. Capture des besoins : diagrammes de cas d’utilisation2. Focus sur les flots de communication : Diagrammes de

séquences3. Construction du système : Diagrammes de Classes4. De l’analyse à la conception 5. Point de vue général sur le procédé : Introduction à la méthode

orientée objet



09/10 /99

Bibliographie

Merise: 5ème Partie Dossier "SAM l'Informaticien" du 5 Mars au 18 Mars 2001 par Stéphane Lambert http://www.vediovis.fr/index.php?page=merise5

Introduction au langage UML, SUPINFO

De Merise à UML, Nasser Kettani, Dominique Mignet, Eyrolles

http://www.compucycles.com/nouveausite/articles/Merise/Article_07.htm

UML-MERISE Etude Comparative, OSITEC-Consultants, 2004-2005

96

Ce cours a été monté en utilisant de nombreux supports dont je remercie chaleureusement ici les auteurs

D’autres références se trouvent sur le site du module.


mailto:slambert_arobas_vediovis.fr

mailto:slambert_arobas_vediovis.fr

http://www.vediovis.fr/index.php?page=merise5

http://www.vediovis.fr/index.php?page=merise5



Education

Modélisation par Objets - Introduction - De Merise à UML