2 Conception objet et UML

3 Sources ● Cours de Martine Gauthier ● Cours de François Charoy ● Slides de Lou Franco ● UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd Edition – Martin Fowler – Le site de reférence

4

5 Le développement des logiciels Etude des besoins Analyse Conception Implémentation Validation

6 Etude des besoins ● Quel est l’objectif ? – définir les besoins des utilisateurs, – définir les fonctionnalités attendues du système, – préciser les contraintes non fonctionnelles, concernant par exemple le matériel, le temps de réponse,... ● Qui est concerné ? – le client – les personnes chargées de la mise en place du cahier des charges ; il est souhaitable que ces personnes aient des connaissances dites « métier ». ● Synonymes : analyse des besoins, cahier des charges

7 Analyse ● Quel est l’objectif ? – modéliser le système de façon à mettre en évidence les aspects statiques et dynamiques, à partir de l’étude des besoins ● Aspects statiques – quelles sont les classes qui vont être utiles ? – quels sont les liens entre ces classes ? ● Aspects dynamiques – comment s’enchaînent les activités ? ● Qui est concerné ? – les analystes

8 Conception ● Quel est l’objectif ? – Affiner le modèle d’analyse de façon à prendre en compte les contraintes non fonctionnelles, la gestion de l’interface graphique, la communication avec des bases de données,... ● Qui est concerné ? – les concepteurs – les architectes logiciel

9 Implémentation ● Quel est l’objectif ? – Implanter les classes de conception dans un langage donné, sur une machine donnée, en s’aidant éventuellement d’outils ● Qui est concerné ? – les programmeurs ● Synonyme : programmation

10 Validation ● Quel est l’objectif ? – Vérifier que le système réalisé est conforme aux exigences définies par le cahier des charges ● Différentes sortes de tests – tests unitaires : tester chaque « morceau » – tests d’intégration : tester l ’intégration de « morceaux » – tests du système : tester le logiciel lui-même ● Qui est concerné ? – les testeurs ● Synonyme : test

11 Unified Modeling Language ● UML est né d'un besoin de standardisation de méthodes de développement. ● 1994 = Fin de la guerre des méthodes – Rumbaugh et Booch décident d’unifier leurs travaux relativement proches (Rational). – Ils seront rejoints par Jacobson. ● Résultats satisfaisants très rapidement – Les différentes versions sont relatives à des problèmes de notation et non pas à des problèmes de sémantique.

Problems have many solutions

Design is about choosing one

Why model?

To visualize

To communicate Electronic schematic of GEE radar (AMES type 7000) used in second world war by the allies

To emphasize DaVinci’s Flush Toilet

The UML is a standard graphical notation for describing object-oriented software systems

Use UML to visualize, communicate, and emphasize your choices

Goal: Understand this

And this

22 Définition ● UML se définit comme étant un langage de modélisation graphique et textuel, destiné à – comprendre et décrire des besoins, – communiquer – spécifier, – documenter des systèmes, – esquisser des architectures logicielles, – concevoir des solutions. ● Utilisé pour le développement de systèmes à forte composante logicielle – banques, télécommunications, transports, aérospatiale, commerce, sciences, …

23 13 diagrammes ● Diagrammes structurels – Classes : Classes et relations – Objets : configuration d'instances – Composants : Structure et connections entre composants – Déploiement – Package : structure hiérarchique de compilation – Composite Structure : composition d'une classe à l'exécution ● Diagrammes comportementaux – Cas d’utilisation : interaction des utilisateurs – Etats : impact des événements sur les objets – Activités : Comportement procédural et parallèle – Diagrammes d'interactions ● Séquence : interactions entre objets (séquentielles) ● Communication : Interaction entre objets (collaboration) ● Interaction : diagramme de séquence et d'activité ● Timing : interactions entre objets (temporelles)

24

25 Méta-modèle ● Les différents concepts UML ont été formalisés en UML. – définition récursive ● Construction d’un méta-modèle – décrit formellement les éléments de modélisation, ainsi que la syntaxe et la sémantique permettant de les manipuler ; – permet de faire la preuve de la puissance d’expression de la notation, capable (entre autres) de se représenter elle-même ; – sert de description de référence pour la construction d’outils.

26 Atouts ● Adapté à toutes les phases du développement ● Ouvert, grâce à un mécanisme d’extension ● Indépendant des langages de programmation ● Défini récursivement ● Supporte les concepts de développement de haut niveau – Patterns, composants, frameworks

27 Critiques ● Modèles potentiellement lourds, illisibles ● Profusion de diagrammes ● Vérification de cohérence complexe ● Retarde le moment de la programmation.  Par confusion, les critiques visent UML, alors qu’elles concernent plutôt le processus de développement.

28 Les processus de développement ● Développement en cascade – Analyse/conception/code/test ● Développement itératif – Release courte – Implantation d'un sous-ensemble des fonctionnalités – Test de regression automatique – Refactoring – Integration continue

29 Processus unifié ● Processus de développement défini par les concepteurs d’UML. – UML est donc le langage de modélisation préconisé ● Caractéristiques d'un processus unifié (UP) – incrémental, – construit autour de la création et la maintenance de modèles, – itératif, – orienté composant : vise la réutilisation, – orienté utilisateur : la spécification et la conception sont construites à partir des modes d'utilisation attendus.

30 Planification Besoins Analyse et conception Implémentation Déploiement Tests Evaluation Planification initiale

31 En pratique … ● Apprendre la notation UML au travers d’exemples. – Se référer régulièrement à la norme. ● Comment s’y retrouver dans les diagrammes ? – Tous ne sont pas systématiquement utiles, … et on peut même en imaginer d’autres. – Certains sont spécifiques à une étape du développement, d’autres non. – Quantité n’est pas synonyme de qualité.

32 En pratique (suite) ● Développer une application, en suivant un processus de développement bien défini, en décrivant les modèles en UML. – Les UP sont complexes et inadaptés à l’apprentissage. – Processus de développement simplifié ● Utiliser un outil qui permet de gérer des descriptions UML. – Ils gèrent tous les diagrammes. – Certains sont capables de produire de la documentation, de générer des squelettes de programme,... – D'autres font un peu de reverse engineering, … – Il n'en existe pas de miraculeux ! Juste des payants et des gratuits …

33 ● Analyse des besoins – Diagrammes de cas d’utilisation ● Décrire les fonctions du système selon le point de vue de ses futurs utilisateurs – Diagrammes d’activités ● Décrire l’activité du système – Diagrammes de séquences ● Décrire l’interaction entre Homme et Système –Descriptions textuelles des cas d'utilisation Processus de développement simplifié

34 Analyse ● Diagrammes de classes – Décrire les structures de données du système, définies comme un ensemble de relations entre classes. – Faire abstraction de de ce qui est extérieur au système (IHM, SGBD, …) ● Diagrammes de séquence – Décrire les interactions entre objets lors de la réalisation de chaque fonctionnalité ● Diagrammes d’états – Décrire le comportement d’une famille d’objets en termes d’états et de transitions entre états

35 Conception ● Diagrammes de classes – Décrire les structures de données du système, définies comme un ensemble de relations entre classes (plus de restriction) ● Diagrammes de séquence – Décrire les interactions entre objets dans la réalisation d’une fonctionnalité (en incluant les nouveaux objets) ● Diagrammes de composants – Décrire l’architecture des composants physiques ● Diagrammes de déploiement – Décrire le déploiement des composants sur les dispositifs matériels

36 ● Adieu UML ? – Si l’outil utilisé est sympathique, une partie du code est généré. ● Squelettes de classes – Ou full round-trip engineering – Le reste (tout … ) doit être écrit à la main, en accord avec les différents diagrammes. – Et les tests – Et l'intégration ● Validation Implémentation

37 UML et MDA ● Model Driven Architecture...

Conclusion ● UML is a standard graphical notation for describing object-oriented software ● Use UML to visualiza, communicate end emphasize your choices ● Use UML and MDA to generate your applications...