PrÃ©sentation UML - UniversitÃ© Nice Sophia Antipolis

Génie Logiciel 

& UML : Unified Modeling Language 

À destination des étudiants du 

5 ième année Ingénieur EPU Nice-Sophia Antipolis 

- option Bioinformatique et Modélisation pour la Biologie (BIMB) – 

Objectif : 

Savoir gérer la production d’un logiciel depuis les besoins des utilisateurs 

jusqu’à sa mise à disposition. 

Mireille Blay-Fornarino 

EPU 

Sophia Antipolis 

blay@polytech.unice.fr 

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

Site web du module : http://anubis.polytech.unice.fr/cours/2009_2010:gb5:uml:start 

03/10/2009 

Mireille Blay-Fornarino, 

blay@polytech.unice.fr

➡ 

Contexte 

(extraits choisis du site de présentation de l’option) 

L'option BIMB (Bio-Informatique et Modélisation pour la 

Biologie) propose une formation en bio-informatique à 

destination des biologistes…BIMB apporte par ailleurs 5 

domaines de compétence : algorithmique et programmation, 

systèmes informatiques, systèmes d'information, biologie à 

grande échelle et extraction de connaissances, et systèmes 

biologiques complexes. 

Cette option forme des biologistes qui dominent les deux 

langages, celui de la biologie et celui de l'informatique. Cette 

double compétence est non seulement un atout pour les 

interactions avec les métiers de l'informatique mais permettra 

aussi aux futurs ingénieurs d'animer une équipe sur un projet 

pluridisciplinaire. En outre, de nombreuses entreprises 

d'informatique embauchent des diplômés en bio-informatique. 

L'informatique trouve ses applications dans tous les domaines 

d'activités de la société et la biologie de fait pas exception : … 

3/10/2009 


blay@polytech.unice.fr 2

Planning 

Bibliographie & références : voir sur le site web. 

3/10/2009 



Plan 

I. Problématique du Génie Logiciel 

II. Processus de Développement 

III. Qualité du logiciel 

IV. Méthodologies de développement 

V. D’UML au RUP 

VI. Modélisation : du fonctionnel à l’objet 

3/10/2009 



I. Quels sont les problèmes du 

développement logiciel? 

30/09/2009 



Le premier « bug » 

➡ En 1947, un « calculateur programmable » Mark II de 

l’université de Harvard s’arrête brutalement. 

– Un papillon mort avait provoqué un court-circuit 

➡ Ce « bug » n’était pas de nature logicielle 

– Il relève en partie de la légende… 

3/10/2009 



Problématique du génie logiciel 

➡ 

➡ 

➡ 

Programming-in-the-Small 

– Problème de la qualité interne d'un composant 

Programming-in-the-Large 

– Faire 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-Duration 

– Problème de la maintenance corrective et évolutive. 

– Notion de ligne de produits. 

3/10/2009 

Mireille Pr. Jean-Marc Blay-Fornarino, 

Jézéquel 




Problème de la validité du logiciel 

Acquérir une valeur positive n 

Tant que n > 1 faire 

si n est pair 

alors n := n / 2 

sinon n := 3n+1 

Sonner 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 ! 

3/10/2009 

Mireille Pr. Jean-Marc Blay-Fornarino, Jézéquel 




Préconditions : 

Syntaxe JML 

Ce qui doit être satisfait 

/** 

pour appeler la méthode 

* @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 

Assertions 

3/10/2009 




Produire des programmes prouvés 

➡ C’est possible… 

– On peut construire des programmes de tel manière qu’ils soient 

prouvables 

– En partie automatisable (Atelier B, etc.) 

• Outils spécifiques 

➡ …mais coûteux 

– Preuve au moins aussi complexe que le code 

– Autant de chances de se tromper dans la preuve… 

➡ En pratique : 

– Réservé à des (petits) sous-systèmes (très) critiques 

– Recours aux tests pour le reste 

• On reviendra dessus… 

3/10/2009 



Programming-in-the-Large : 

Gérer la complexité due à la taille 

a) 

c) 

b) 

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. 

3/10/2009 




Augmentation exponentielle de la taille du logiciel 

3/10/2009 




Echecs logiciels 

➡ 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 millard de $, retard de 18 mois. 

➡ 

National Cancer Institute, Panama City, 

2000 : Logiciel non adapté aux médecins 

=> 8 morts, 20 personnes “surexposées”. 

Premier vol d’Ariane 5 (1996) 

➡ etc, etc. Out of range 

3/10/2009 



Gestion de la complexité due à la taille : 

diviser pour résoudre 

➡ 

➡ 

3/10/2009 

Aspects techniques 

– en s'appuyant techniquement sur la modularité 

• « Encapsulation et masquage d'information, faible couplage » 

• Importance de la notion d’Objets 

Aspects organisationnels 

– S’organiser au delà de la réalisation : méthodes 

• « Analyse, conception » 

• « Validation et vérification » 

– Ingénierie de la conduite de projet = compromis entre 

• respect des délais 

• respect des coûts 

• réponse aux besoins/assurance qualité 

– Problèmes de gestion de ressources (humaines, etc.) et 

de synchronisation entre tâches 

Pr. Mireille Jean-Marc Blay-Fornarino, 

Jézéquel 



Sort des projets informatiques 

Standish Group in 2005 

3/10/2009 



X


Amélioration de la production de logiciels 

http://www.richmondgov.com/departments/dit/docs/PolCo200203.pdf 

3/10/2009 



X

Coûts du développement 

3/10/2009 




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 évolutive 

– Adaptation aux changements des besoins 

– Adaptation aux changements de l’environnement 

• Support nouvelles plateformes, bug « an 2000 » 

➡ Notion de ligne de produits 

– Anticiper des familles de besoins 

3/10/2009 




Problème de la maintenabilité 

➡ 

➡ 

Exemple critique dû à M. Jackson 

Barques à louer sur un lac 

– Enregistrement des départs (S) et retours (E) sur un terminal, avec 

horodatage automatique 

➡ On veut chaque jour un rapport avec : 

– le nombre de sessions 

– la durée moyenne d'une session 

3/10/2009 




Approche « droit au but » 

➡ Décomposition fonctionnelle en 1980 

➡ 

➡ 

Structured 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 modulaire et hiérarchique 

– Permet de gérer toute taille de problème 

3/10/2009 



X


Réalisation 

3/10/2009 




Maintenance 

➡ Demandes de modifications : 

– Nombre de sessions depuis le début de la journée 

– durée de la session la plus longue 

– un état pour le matin, un autre pour le soir 

– corriger la perte de S ou de E 

➡ Dans la réalité, c’est pire! 

– Nokia rapporte à propos de son infrastructure GSM 

• 50% des requirements (besoins numérotés) ont changé après le gel du cahier 

des charges 

• 60% 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 

3/10/2009 




Coût de la maintenance 

3/10/2009 




Solution : approche par modélisation 

➡ Aspects techniques 

– D’abord modéliser ce qui est stable dans un système 

• Entités et événements selon Jackson (JSD) 

– Ensuite ajouter les fonctionnalités 

• C’est la partie visible, donc ce qui bouge le plus 

• Maintenance traitée idem développement initial 

– Assurer une meilleure continuité entre 

• Domaine du problème 

• Domaine des solutions 

➡ Aspects organisationnels 

– Traçabilité 

– Gestion contrôlée des changements 

3/10/2009 




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/ 

3/10/2009 



II. Processus de Développement … 

Ingénierie du logiciel : D’abord des 

échanges 

30/09/2009 



Processus de Développement 

Symptômes Courants d'Echec des Projets 

Mauvaise compréhension des besoins des utilisateurs 

finaux. 

Incapacité de gérer les modifications des exigences. 

Les modules qui ne fonctionnent pas ensemble. 

Du logiciel difficile à maintenir ou à faire évoluer. 

Du logiciel de mauvaise qualité (beaucoup d'anomalies). 

3/10/2009 




7 bonnes pratiques 

Unified Process 

Développement de manière itérative 

Développement à base de composants centré 

sur l’architecture 

Pilotage par les risques 

Gestion des exigences 

Maîtrise des modifications 

Evaluation continue de la qualité 

Modélisation visuelle 

Ce sont 

celles du 

UP… 

3/10/2009 




7 bonnes pratiques 

Unified Process 

Développement de manière itérative 

Développement à base de composants centré 

sur l’architecture 

Pilotage par les risques 

Gestion des exigences 

Maîtrise des modifications 

Evaluation continue de la qualité 

Modélisation visuelle 

Ce sont 

celles du 

UP… 

3/10/2009 



(1) Qu'est-ce que le Développement Itératif ? 

• Basé sur de petites étapes, le feedback et l’adaptation. 

• Aussi appelé évolutif, en spirale, . . . 

2 ou 4 semaines 2 ou 4 semaines 

3/10/2009 



(1) Qu'est-ce que le Développement Itératif ? 

• Basé sur de petites étapes, le feedback et l’adaptation. 

• Aussi appelé évolutif, en spirale, . . . 

2 ou 4 semaines 2 ou 4 semaines 

3/10/2009 



(2) Développement à base de composants 

centré sur l’architecture 

➡ 

Au cours des premières itérations, on construit et on 

valide une architecture logicielle 

– A partir de composants existants, standards du marché 

– Éviter les développements spécifiques 

➡ 

Construire l’architecture et la tester tôt même si la 

solution n’est pas parfaite et incomplète 

3/10/2009 



(3) Pilotage par les risques 

➡ Un risque est un 

événement redouté dont 

l’occurrence est plus ou 

moins prévisible et 

provoquant, lorsqu’il se 

produit, des dommages 

sur le projet. 

➡ Il ne faut pas confondre risque et problème. 

l Un problème est un risque qui s’est révélé. 

Vous avez la grippe, je vais vous 

prescrire des antibiotiques 

3/10/2009 



(3) Pilotage par les risques 

➡ Un risque est un 

événement redouté dont 

l’occurrence est plus ou 

moins prévisible et 

provoquant, lorsqu’il se 

produit, des dommages 

sur le projet. 

➡ Il ne faut pas confondre risque et problème. 

l Un problème est un risque qui s’est révélé. 

L’hiver, 

il faut se faire vacciner 

contre la grippe 

Vous avez la grippe, je vais vous 

prescrire des antibiotiques 

3/10/2009 



Le pilotage par les risques, c’est : 

➡ Analyser les risques potentiels le plus tôt possible – 

dès les premières itérations 

– Les hiérarchiser 

– Commencer par travailler sur les éléments les plus exposés 

➡ Penser aux risques techniques, mais aussi : 

– aux risques liés au client 

– aux risques liés au domaine applicatif 

– aux risques liés à l’organisation du projet 

3/10/2009 



(4) Identification des exigences 

➡ Qu’est ce qu’une exigence ? 

– Condition à laquelle le système doit satisfaire ou une capacité 

dont il doit faire preuve. [RUP] 

➡ On distingue : 

– Les exigences fonctionnelles 

• Qui formulent ce que le système est chargé de faire 

– Les exigences non fonctionnelles 

• Décrivent la qualité des services attendus du système (performance, 

sécurité de fonctionnement, IHM)… 

3/10/2009 



(4) La gestion des exigences 

Facteurs de 

dépassement 

et d’abandon 

1) Manque de participation des utilisateurs 

2) Identification incomplète des Besoins 

3) Besoins qui changent au cours du projet 

3/10/2009 

Standish Group, ‘97 

➡Gérer les exigences 



La Gestion des Exigences 

➡ 

Cela ne signifie pas: 

– Avoir des exigences correctes dés le démarrage du projet. 

➡ 

C'est irréaliste… 

➡ 

Cela signifie: 

– Ne pas être négligent. 

– Les recueillir efficacement. 

– Enregistrer, tracer, organiser 

– Et cela se rapporte au fait de considérer les changements de 

manière formelle (maîtriser les changements). 

3/10/2009 



(5) Qu’est-ce qu’une demande de 

changement ? 

➡ 

➡ 

Demande de changement (Change Request ou CR) 

– Requête pour modifier un artefact ou un processus. Dans la 

documentation d’une demande de changement figurent des 

informations sur l’origine et l’impact du problème considéré, sur la 

solution proposée et sur son coût. 

Deux types 

– Demande d’Evolution 

• Spécifie une nouvelle caractéristique du système ou un changement 

par rapport au comportement établi. 

– Rapport d’Anomalie 

• Erreur ou défaut 

3/10/2009 



(6) Faire les Tests à la fin ? 

Il est démontré que : 

- Corriger une anomalie plus tard coûte 10-100 fois plus que de la corriger à 

son origine. 

Software Engineering Economics, Boehm, 1981. 

- Les produits avec le moins d'anomalies ont les délais les plus courts. 

Applied Software Measurement, 1 st edition, Jones 1991. 

- La mauvaise qualité est la raison la plus courante de dépassement des 

délais. 

Assessment and Control of Software Risks, Jones 1994, 4000 project study. 

- La correction des anomalies consomme 40-50% du coût total. 

IEEE Computer, Boehm, Sept 1987. 

- 60% des anomalies existent au moment de la conception. 

Principles of Software Engineering Management, Gilb, 1988. 

3/10/2009 



Evaluation continue de la Qualité 

➡ Solution construite – contrôle produit 

– Vérification de l’adéquation de la solution aux besoins 

– Tests systématiques et périodiques 

– Actions qualité 

➡ Avantages : 

– Identification précoce des dysfonctionnements 

– Réactivité aux déviations constatées 

– Maîtrise des risques de dérapage 

3/10/2009 



III. Qualité du logiciel ? 

30/09/2009 



Evaluation de la Qualité du logiciel 

➡ 

Il est difficile d’évaluer directement la qualité du logiciel lui-même 

– Utilisation de métriques ? 

‣ Au niveau analyse, conception, architecture, code ? 

‣ Nombreuses métriques différentes, nombreux débats… 

➡ 

➡ 

Il semble plus atteignable d’évaluer la qualité du processus de 

développement de logiciel 

– Normes ISO 9000 

– Capability Maturity Model Integration (CMMI) 

La qualité (administrative, bureaucratique…) du processus n'est 

pas une garantie absolue de la qualité du produit 

Jean-Paul Rigault 2005 

3/10/2009 



Évaluation de la qualité du logiciel 

Normes ISO 9000 

➡ 

Normes générales et internationales de qualité 

– Familles de normes (9000 à 9004) selon l’activité de l’entreprise 

(ou d’un de ses départements) 

– Procédure de certification et d’accréditation 

– Applicable aussi bien à la fabrication des boulons, des 

automobiles, grossiste de poissons ou même à la formation des 

ingénieurs ! 

– De nature très bureaucratique ! 


3/10/2009 



X


Capability Maturity Model Integration 

CMMI 

SM 

➡ 

➡ 

Analyse de la maturité des entreprises (ou d’un de 

leurs départements) par rapport à l’organisation de 

leur processus de développement de logiciel 

Modèle établi par le Software Engineering Institute, 

université de Carnegie Mellon, Pittsburg (SEI-CMI) 

– Première publication en 1986 

– Spécifique au logiciel (CMM) 

– Révisé en 2002 

– Étendu à l’ingénierie des systèmes (CMMI) 

The CMMI model is not a process. 

This model shows what to do, 

Not how to do it or who does it. 


3/10/2009 





CMMI 

SM 

On ne peut pas sauter une marche, ni prendre l’escalier au milieu ! 


3/10/2009 





CMMI 

SM 

Level 

5 Optimizing 

4 Quantitatively 

Managed 

Focus 

Continuous 

Process 

Improvement 

Quantitative 

Management 

Process Areas 

Organizational Innovation and Deployment 

Causal Analysis and Resolution 

Organizational Process Performance 

Quantitative Project Management 

Quality 

Productivity 

3 Defined 

Process 

Standardization 

Requirements Development 

Technical Solution 

Product Integration 

Verification 

Validation 

Organizational Process Focus 

Organizational Process Definition 

Organizational Training 

Integrated Project Management for IPPD 

Risk Management 

Integrated Teaming 

Integrated Supplier Management 

Decision Analysis and Resolution 

Organizational Environment for Integration 

2 Managed 

1 Initial 

Basic 

Project 

Management 

Requirements Management 

Project Planning 

Project Monitoring and Control 

Supplier Agreement Management 

Measurement and Analysis 

Process and Product Quality Assurance 

Configuration Management 

Risk, 

Rework 

3/10/2009 



X



CMMI 

SM 

➡ 

Évaluation du CMMI 

– Enquête d’avril 2002 à août 2004, publiée en septembre 2004 

• 424 évaluations 

• 385 organisations 

• 206 entreprises 

• 1704 projets 

• 50,6 % des entreprises non US 

– Résultats 

• 2/3 des entreprises au niveau 2 ou 3 

• mais quand même 1/4 au niveau 5 

Ce peut être un facteur de sélection d’une entreprise par un client ou un 

collaborateur. 


3/10/2009 




➡ 

➡ 

Le CMMI et l'ISO 9001 sont compatibles et 

complémentaires. Ils se basent tous les deux sur une 

approche processus et sur une notion d'amélioration 

continue. 

Beaucoup d'entreprises utilisent l'ISO 9001 au niveau 

global et le CMMI au niveau des départements de 

développement. 

3/10/2009 



X

IV. Méthodologies de développement 

30/09/2009 



Méthode, méthodologie et cycle de vie 

➡ 

➡ 

➡ 

Cycle de vie 

– Période entre l’idée du logiciel et sa mise en service 

Méthodologie 

– Identification et enchaînement des activités et phases du 

processus de développement 

– Identification des pré- et post-conditions de chaque phase 

– Définition des procédures de gestion et de mesure 

– Gestion des équipes, des moyens, du budget… 

Méthode 

– Approche technique pour aborder une ou plusieurs phases ou 

activités 

3/10/2009 




➡ 

➡ 

Exemples de méthodes 

– UML : un langage de modélisation 

• Activités de spécification et conception 

– Z : une méthode 

• Activité de spécification 

Exemples de méthodologies 

– Cascade (waterfall) 

– Développement en spirale, … 

– Unified Process (UP), 

– eXtreme Programming (XP) 

Jean-Paul 3/10/2009Rigault 2005 




Activités lors du processus (1) 

➡ 

➡ 

1) Définition des besoins (Requirements) 

– Expression des besoins dans le langage du client 

2) Spécifications 

– Traduction des besoins dans un langage plus informatique 

– Description du système d’un point de vue extérieur 

• Ce qu’il doit faire 

• Pas comment il le fait 

– Spécifications fonctionnelles et non-fonctionnelles 

– Doit rester accessible au client (contrat) 


3/10/2009 





➡ 

Spécifications (suite) 

– Spécifications fonctionnelles 

• Les fonctions/services rendus par le système 

– Spécifications non-fonctionnelles 

• Utilisabilité 

• Fiabilité (reliability) 

• Performance 

• Supportabilité (maintenabilité) 

• Conditions d’implémentation, de déploiement… 

• Interface 

• Conditions d’exploitation 

• Conditionnement 

• Aspects juridiques 

• Aspects financiers… 






➡ 

➡ 

➡ 

➡ 

3) Conception 

– Traduction des spécifications en termes d’artefacts logiciels 

– Peut être plus ou moins détaillée 

4) Codage 

– Traduction de la conception en code 

5) Test unitaires 

– Test de chaque module individuellement 

– Généralement de la responsabilité du développeur du module 

6) Tests d’intégration 

– Test de la composition de plusieurs modules (sous-systèmes) 






➡ 

➡ 

➡ 

7) Validation 

– Test du système final par rapport aux spécifications 

8) Recette 

– Acceptation du système final 

– Peut être l’objet d’une procédure formelle et parfois officielle 

9) Gestion des changements, gestion de configuration 

➡ 

Gestion de projet 

– Orthogonale à toutes ces activités 

– Gestion du temps, des coûts, des équipes 

– Gestion des relations avec les clients… 


3/10/2009 



Exemples de méthodologie 

Cycle exploratoire 

➡ 

➡ 

Essais-erreurs 

Admissible tel quel pour 

– du prototypage 

– de très petits projets développés 

– par de très petites équipes 

– avec de très petits enjeux 

➡ Cependant, retour en force dans les processus « agiles » 

– mais sous une forme beaucoup plus élaborée 


3/10/2009 



Processus «classique» 

➡ 

Cycle de vie normalisé AFNOR 

Analyse 

• Expression du besoin 

• Analyse détaillée 

Conception 

• Etude technique préalable 

• Conception préliminaire 

• Conception détaillée 

Validation 

• Validation 

• Mise en œuvre 

Intégration 

• Intégration 

• Tests d'Intégration 

Variante US : 

Cycle en « cascade » 

3/10/2009 

Réalisation 

• Codage 

• Mise au point 

• Tests unitaires 



Cycle en V 

Expression des besoins 

Maintenance 

Spécifications 

Validation (recette) 

Conception générale 

Tests d’intégration 

Conception 

Tests unitaires 

Réalisation (codage) 

3/10/2009 



X

Problèmes avec le processus classique... 

3/10/2009 




Cycle en V, caricature ;-) 

Cahier des charges 

Maintenance 

Euphorie 

Promotion des autres 

Inquiétude 

Panique 

Études 

Développement 

Mise en œuvre 

Punition des innocents 

Production 

Recherche des coupables 

Tests 

3/10/2009 



X

➡ 

➡ 

➡ 


Développement en V 

3/10/2009 

Tentative « tayloriste » du développement de logiciel 

– Une idée « linéaire » du développement, non conforme à la pratique réelle 

Processus fondé sur des documents 

– Risque de documents artificiels 

– Délai d’approbation des documents 

Erreurs détectées tardivement 

– On ne voit quelque chose « tourner » qu’à la fin 

– Les spécifications doivent être stables et correctes 

➡ Ne facilite pas 

– l’intégration du client 

– le prototypage 

– la réutilisation 

– la traçabilité… 

➡ Cependant, le processus en cascade est souvent apprécié des 

managers 

– Générateur de pouvoir 

– Facile à planifier, Mais il est moins facile de respecter le plan ! 

L’utilisation du processus en cascade est (maintenant) reconnu 


blay@polytech.unice.fr 50 

comme une des sources majeures des échecs de projets logiciels


Cycle de vie en « spirale » 

Analyse détaillée 

Conception 

Analyse 

préliminaire « (de risque) » 

V1 V2 

Réalisation 

Validation 

Intégration 

Synergie avec approche par objets 

3/10/2009 





➡ 

Bien adapté aux développements innovants 

– les progrès sont tangibles : c ’est du logiciel qui « tourne » et pas 

seulement des kilos de documents 

– possibilité de s ’arrêter « à temps », i.e. avant que l ’irréalisabilité du 

projet ait créé un gouffre financier 

➡ 

Moins simple à manager 

– difficile à gérer en situation contractuelle 

– mal contrôlé => on retombe dans le hacking 

3/10/2009 





➡ 

Bien adapté aux développements innovants 

– les progrès sont tangibles : c ’est du logiciel qui « tourne » et pas 

seulement des kilos de documents 

– possibilité de s ’arrêter « à temps », i.e. avant que l ’irréalisabilité du 

projet ait créé un gouffre financier 

➡ 

Moins simple à manager 

– difficile à gérer en situation contractuelle 

– mal contrôlé => on retombe dans le hacking 

À la base de tous les processus « agiles » 

3/10/2009 




Processus modernes « orientés objets » (1) 

➡ 

Le paradigme objet favorise 

– la réutilisation 

– le développement incrémental (et donc itératif) 

– et donc l’intégration du client 

– et aussi la gestion des changements de spécification 

➡ 

la modélisation (avec UML) 

– par réduction de la distance entre le domaine de l’application et sa 

représentation informatique 

3/10/2009 





Processus modernes « orientés objets » (1) 

➡ 

Méthodologies lourdes 

– Reposent sur une modélisation importante (utilisation d’UML) 

– Exemples : Rational Unified Process (RUP), Model-Driven 

Architecture (MDA) de l’OMG 

➡ Méthodologies agiles 

– Modélisation et documentation limitées et légères 

– Itérations courtes et « productives » 

– Importance des tests 

– Importance du rôle des individus 

– Exemples : Unified Process (UP), eXtreme Programming, … 

3/10/2009 




V. D’UML au RUP 

30/09/2009 



D’UML au RUP 

Qu’est-ce qu’UML ? 

➡ 

UML is a language for 

– Visualizing 

– Specifying 

– Constructing 

– Documenting 

Syntaxe et sémantique 

Graphique 

Architecture et comportement 

Génération de code 

Descriptions graphiques et textuelles 

The artifacts of 

a software-intensive system 

On ne décrit pas l’univers tout entier… 

Le logiciel joue un rôle majeur 





Pourquoi utiliser la Modélisation Visuelle? 

➡ 

On doit enregistrer nos pensées et communiquer en 

utilisant des langages visuels et schématiques (par 

ex., UML). 

➡ Parce que : 

– On estime qu'au moins 50% de notre cerveau est impliqué dans le 

processus visuel. 

– Les langages visuels sont naturels et faciles pour notre cerveau. 

3/10/2009 




Modélisation 

3/10/2009 




Modélisation 

➡ 

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

3/10/2009 




Modélisation 

➡ 


Visualiser 

le système 

3/10/2009 




Modélisation 

➡ 


Visualiser 

le système 

Spécifier la 

structure et le 

comportement 

du système 

3/10/2009 




Modélisation 

➡ 


Visualiser 

le système 

Spécifier la 


comportement 

du système 

Aider à la construction 

du système 

3/10/2009 




Modélisation 

➡ 


Visualiser 

le système 

Spécifier la 


comportement 

du système 

Aider à la construction 

du système 

3/10/2009 

Documenter 

les décisions 





Use Case 

Diagrams Use Case 

Diagrams Sequence 

Diagrams 

Use Case 



Diagrams 

State 

Diagrams State 

Diagrams Class 

Diagrams 

State 


Diagrams Object 

Diagrams 

Scenario 

Diagrams Scenario 

Collaboration 

Diagrams 

Diagrams 

Models 

State 


Diagrams Component 

Diagrams 

Scenario 

Diagrams Scenario 

Diagrams Statechart 

Diagrams 

dynamiques 

Activity 

Diagrams 

Component 

Diagrams Component 

Diagrams Deployment 

Diagrams 

statiques 

3/10/2009 




Diagrammes des cas d’utilisation 

Entrer 

DébloquerLesPortes 

PorteurDeCarte 

Capteur 

AIncendie 

Sortir 

Gardien 

ListerLes 

TentativesDeFraudes 

GérerLesCartes 

Administrateur 

SystèmeDeContrôleDAcces 

3/10/2009 




Diagrammes de classes 

1 

Client 

signataire 

1..4 0..* 

titulaires 

Compte 

numéro 

solde 

... 

1..* 

Banque 

numéro 

nom 

1..* 

0..* 

0..* 

CarteBleue 

Code 

retraitMax 

0..1 

1 

AcceptéPar> 

1..* 

Distributeur 

Consortium 

1 

0..* 

3/10/2009 




Diagrammes d’objets 

: CarteBleue 

EstAcceptéPar> 

: Distributeur 

signataire 

fred : Client 

titulaires 

c4 : Compte 

: Banque 

: Consortium 

: CarteBleue 

signataire 

paul : Client 

titulaires 

c1 : Compte 

: Banque 

pierre : Client 

titulaires 

titulaires 

c2 : Compte 

: Consortium 

marie : Client 

titulaires 

c3 : Compte 

: Banque 

signataire 

: CarteBleue 

sophie : Client 


: Distributeur 


3/10/2009 




Diagrammes de séquence 

paul 

le distrib. la carte de P. la reserve la banque 

le compte de P. 

retirer(500) 

lireN°Compte() 

retirerDeLArgent(500,88219) 

débiter(500) 

sortirDesBillets(5) 

sortirBillets () 

3/10/2009 




Diagrammes de collaboration 

6 : prendreBillet() 

la reserve de billets 

5 : sortirDesBillets(5) 

paul 

1 : retirer(500) 

le distributeur la banque 

88219 2 : lireN°Compte() 

3 : retirerDeLArgent 

(500,88219) 

4 : débiter(500) 

la carte de P. 

le compte de paul 

3/10/2009 




Diagrammes d’états 

En attente 

carte insérée 

En attente du code 

carte retirée 

mauvais code 

code frappé 

En attente retrait carte 

En vérification 

code bon 

montant incorrect 

En attente du montant 

montant correct 

billets retirés 

En distribution 

3/10/2009 



Modélisation UML 

➡ Modélisation selon 4 points de vue principaux : 

– Vision utilisateur du système 

• Cas d’utilisation 

– Aspects statiques du système 

• Description des données et de leurs relations 

• Structuration en paquetages 

– Aspects dynamiques du système (comportemental) 

• Diagramme de séquences (scénarios) 

• Diagramme de collaborations (entre objets) 

• Diagramme d’états-transitions (Harel) 

• Diagramme d’activités 

– Vision implantation 

• Diagramme de composants et de déploiement 

3/10/2009 




Divers modes d’utilisation d’UML 

➡ 

➡ 

➡ 

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 programmation 

– Spécification complète et exécutable 

– Pas vraiment disponible actuellement ! 


3/10/2009 




Diverses cibles d’utilisation d’UML 

➡ 

➡ 

➡ 

Point de vue conceptuel 

– Modélisation d’entités du monde applicatif 

– Analyse de domaine 

Point de vue de spécification logicielle 

– Abstraction d’entités du monde réel 

– Composants logiciels 

– Analyse OO 

Point de vue d’implémentation logicielle 

– Artefacts et composants pour une technologie particulière (Java, 

C++, BD…) 

– Conception OO 


3/10/2009 



X

Rational Unified Process (RUP) 

➡ 

➡ 

➡ 

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 RUP propose en outre 

– des techniques de modélisation pour les différentes phases et 

activités 

– une organisation des rôles et des flots lors du processus de 

développement 





Itératif et incrémental 

Pré-étude/INCEPTION 

• Cas d'utilisation 

• Modèle des objets du 

domaine 

• Interfaces 

• Maquettes 

Quoi ? 

Pour qui ? 

Combien ? 

Étude de marché 

Opportunité 

économique 

UML 

Modèle utilisateur 

Modèle statique 

Modèle dynamique 

Modèle d’implantation 

VALIDATION/Transition 

• Validation technique 

• Validation par les 

utilisateurs 

Transfert vers 

les utilisateurs 

3/10/2009 

ELABORATION 

• Architecture 

• Modèles des objets et 

scénarios 

• Règles de transformation 

(Design patterns) 

Analyse des 

besoins 

Modélisation 

du domaine 

CONSTRUCTION 

• Modèle détaillé des 

objets 

• Scénarios détaillés 

• Algorithmes 

• Codage - Mise au point 

• Intégration 

Développement 

du produit 

Gestion des 

changements 




Itératif et incrémental 

Chaque phase est composée d’itérations, chaque itération 

se concluant par un produit ou un prototype 

3/10/2009 



X


Un processus à deux dimensions 

Une itération 

dans la phase 

d'élaboration 

Chaque phase est composée d’itérations, chaque itération 

se concluant par un produit ou un prototype 

3/10/2009 




Dirigé par les cas d’utilisation 

3/10/2009 



VI. Modélisation : du fonctionnel à l’objet 

30/09/2009 



La découpe fonctionnelle 

d'un problème informatique : une approche intuitive 

Factorisation 

3/10/2009 



Le revers de la médaille : 

maintenance complexe en cas d'évolution 

3/10/2009 



Le revers de la médaille : 

maintenance complexe en cas d'évolution 

La séparation des données et des 

traitements : le piège ! 

3/10/2009 



Réunir données et traitements : 

Programmation par objets 

3/10/2009 



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 qui possède 

une identité (un nom). 

• Un ensemble d'attributs caractérise l'état de l'objet. 

• Un ensemble d'opérations (méthodes ou comportements) en 

définissent le comportement. 

3/10/2009 




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

3/10/2009 




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

3/10/2009 




➡ 

Héritage (et polymorphisme) 

Le polymorphisme représente la faculté d'une 

méthode à pouvoir s'appliquer à des objets de classes 

différentes. 

3/10/2009 




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. 

Une classe peut être spécialisée en d'autres classes, afin d'y ajouter 

des caractéristiques spécifiques ou d'en adapter certaines. 

Plusieurs classes peuvent être généralisées en une classe qui les 

factorise, afin de regrouper les caractéristiques communes d'un 

ensemble de classes. 

La spécialisation et la généralisation permettent de construire des 

hiérarchies de classes. L'héritage peut être simple ou multiple. 

L'héritage évite la duplication et encourage la réutilisation. 

Le polymorphisme représente la faculté d'une méthode à pouvoir 

s'appliquer à des objets de classes différentes. 

Le polymorphisme augmente la généricité du code. 

3/10/2009 



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 ? 

3/10/2009 



Quels sont les remèdes 

aux inconvénients de l'approche objet ? 

Un langage pour exprimer les concepts objet qu'on utilise, 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. 

3/10/2009 



Introduction 

c. UML, histoire, généralité 

3/10/2009 



UML: histoire, généralité 

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 

UML : Support des systèmes concurrents et répartis, à base de 

composants 

3/10/2009 




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 

3/10/2009 




Et un langage unique, un ! 

Un cocktail de notations éprouvées. 

(...mais pas toutes, p. ex. RdP, 

SADT/IDEF0, DFD, etc.) 

Auteurs : Grady Booch, Ivar 

Jacobson, James Rumbaugh. 

Standardisation OMG 

Promoteurs : 

Rational Software, Oracle 

Hp, Microsoft, IBM 

3/10/2009 




Unified Modeling Language 

➡ 

UML est un langage graphique qui permet de modéliser 

tous les types de systèmes d ’informatiques. 

➡ 

Ce n ’est pas une méthode mais une notation qui laisse 

la liberté de conception. 

3/10/2009 




Les points forts d'UML 

– UML est un langage formel et normalisé 

• gain de précision 

• gage de stabilité 

• encourage l'utilisation d'outils 

– UML est un support de communication performant 

• Il 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. 

3/10/2009 



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. 

Or, l'intégration d'UML dans un processus n'est pas triviale et 

améliorer un processus est une tâche complexe et longue. 

3/10/2009 



Organisation générale 

3/10/2009 



X

➡ 

UML au travail…. 

➡ 

Présentation du projet 

– http://anubis.polytech.unice.fr/cours/2009_2010:gb5:projet-bduml:start 

➡ 

Chargement du logiciel 

– http://anubis.polytech.unice.fr/cours/ 

2009_2010:si5:idm:download:download_directives#magic_draw 

3/10/2009

PrÃ©sentation UML - UniversitÃ© Nice Sophia Antipolis

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?