Extrait du cous unified Modeling Language

De OMT à UML
– 1990 : Object-oriented Modeling Technique (Rumbaugh et al., G.E.)
– Succès de la méthode du aux qualités de la notation :
– Concise, assez précise, simple à utiliser et à outiller
– Rien de fondamentalement nouveau
» Inspirée “ entité-relation ” pour la modélisation des objets
» Notation de Harel pour la dynamique des objets
» De Marco/Yourdon flots de données & transformations
– 1995 : Version préliminaire de UML
– extensions et améliorations, publications JOOP, …
– inspirées par les auteurs eux -mêmes et par Booch
– 1997 : UML version 1.0
– Intégration de la méthode OOSE de Jacobson (use-cases), et des remarques de grandes sociétés informatiques
– Standardisée à l’OMG. 2Q99 =>Version 1.4
La consécration des méthodes fondées sur la modélisation
– L’approche par modélisation facilite
– Communication (et sa précision)
» avec donneur d’ordre
» entre différentes phases de développement et de maintenance
– Capacité de vérification
» Cohérence
» Complétude
– Continuité entre les différentes phases du cycle de vie
» cf. Jackson et JSD
» N.B.: continuité <> isomorphique ou plongement/projection
Un peu de Méthodologie…
– Une méthode de développement de logiciels, c’est :
– Une notation
» La syntaxe — graphique dans le cas de UML
– Un méta-modèle
» La sémantique — paramétrable dans UML (stéréotypes)
– Un processus
» Détails dépendants du domaine d’activité :
– Informatique de gestion
– Systèmes réactifs temps-réels
– Shrink-wrap software (PC)
Problèmes du processus classique
– Organisation « industrielle » héritée du XIX ème  siècle
– rassurant pour les managers
– hiérarchie malsaine dans les rôles
– antinomie : Coplien ’s organizational pattern
» Architects Also Implement
– cycle management <> cycle développement
– linéarité implicite
– temps d ’approbation des documents => effet tampon
– coût de la (non-) modification d ’un document « final »
– irréaliste pour un projet innovant, donc à risques
Cycle de vie en « spirale »
– Bien adapté au 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ée un gouffre financier
– Moins simple à manager
– difficile à gérer en situation contractuelle
– mal contrôlé => on retombe dans le hacking
– Production des incréments asservie sur 2 parmi 3 :
– période (e.g. release toutes les 2 semaines)
– fonctionnalités (releases découpés suivant use-cases)
– niveau de qualité (problème de la mesure)

……..

Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Cours Unified Modeling Language (2080 KO) (Cours PPT)