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
Modélisation par
Objets2
mercredi 8 septembre 2010
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 ?
mercredi 8 septembre 2010
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 :
mercredi 8 septembre 2010
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
mercredi 8 septembre 2010
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
mercredi 8 septembre 2010
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
mercredi 8 septembre 2010
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 :
mercredi 8 septembre 2010
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 :
mercredi 8 septembre 2010
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
mercredi 8 septembre 2010
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
mercredi 8 septembre 2010
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
mercredi 8 septembre 2010
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
mercredi 8 septembre 2010
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
mercredi 8 septembre 2010
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”
mercredi 8 septembre 2010
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é
mercredi 8 septembre 2010
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
mercredi 8 septembre 2010
I. Quels sont les problèmes du développement logiciel?
Un peu d’histoire
19
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
I. Quels sont les problèmes du développement logiciel?
Du bidouillage au génie logiel
26
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /9928
Programming-in-the-Small
Pr. Jean-Marc Jézéquel
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /9931
Gérer la complexité due à la taille
Pr. Jean-Marc Jézéquel
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /9932
Augmentation exponentielle de la taille du logicielProgramming-in-the-Large
✓Complexité✓Prog. Large
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /9938
RéalisationProgramming-in-the-Duration
✓Maintenance✓Prog. Durée
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /9940
Coût de la MaintenanceProgramming-in-the-Duration
✓Prog. Durée✓Maintenance
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /9941
La découpe fonctionnelle d'un problème informatique : une approche intuitive
Factorisation
✓Prog. Durée ✓Vers l’objet
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
Intro. Intro. UML De Merise à UML
09/10 /9943
Réunir données et traitements : Programmation par objets
✓Prog. Durée ✓Vers l’objet
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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.
✓Prog. Durée ✓Vers l’objet
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /9945
Vision objet du système informatique (2)
➡ 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.
✓Prog. Durée ✓Vers l’objet
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /9946
Vision objet du système informatique (3)
➡ 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.
✓Prog. Durée ✓Vers l’objet
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /9947
Vision objet du système informatique (4)
➡ Héritage (et polymorphisme)Le polymorphisme représente la faculté d'une méthode à pouvoir s'appliquer à des objets de classes différentes.
✓Prog. Durée ✓Vers l’objet
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Approche orientée-objet
48Illustration de Jean-Marc Estay (IMA)
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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 ?
✓Prog. Durée ✓Vers l’objet
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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.
✓Prog. Durée ✓Vers l’objet
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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/
mercredi 8 septembre 2010
III. Introduction à UML
53
mercredi 8 septembre 2010
III. Introduction à UML UML, histoire, généralité
54
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
III. Introduction à UML survol
63
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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.
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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.
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
IV. De Merise à UMLen bref
72
Attention UML n’est pas une méthode :Nous étudions uniquement ici le support de Merise par UML
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à 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.
73mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
74mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Les principes de Merise
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.
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Les principes de Merise
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
76mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Les principes de Merise
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
77mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
78mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
79mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier Flux
80mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier Diagramme de Cas d’utilisation
81mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier Diagramme de Séquence
82mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier
Le Modèle conceptuel des données (MCD)
Niveau conceptuel
84mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier
Le Diagramme de classes
Niveau conceptuel
85
Pas forcément celui-ci
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier
Cycle de vie des objets (CVO)
Niveau conceptuel
87mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier
Diagramme d’états-transitions
Niveau conceptuel
88mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier
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
89mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métierModèle conceptuel des traitements (MCT)
90mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métierDiagramme d’activités et de séquence
91mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métierDiagramme d’activités et de séquence
92mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
09/10 /99
Modélisation du métier
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
93mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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
mercredi 8 septembre 2010
Intro. Intro. UML De Merise à UML
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.
mercredi 8 septembre 2010