2 Conception objet et UML 3 Sources ● Cours de Martine Gauthier ● Cours de François Charoy ● Slides de Lou Franco ●

Présentation au sujet: "2 Conception objet et UML 3 Sources ● Cours de Martine Gauthier ● Cours de François Charoy ● Slides de Lou Franco ●"— Transcription de la présentation:

1

2 2 Conception objet et UML

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

4 4

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

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

12 Problems have many solutions

13 Design is about choosing one http://flickr.com/photos/chidorian/4795357/in/set-384742/ http://morguefile.com/archive/?display=66493

14 Why model?

15 To visualize http://www.rohdesign.com/weblog/archives/000896.html

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

17 To emphasize DaVinci’s Flush Toilet

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

19 Use UML to visualize, communicate, and emphasize your choices

20 Goal: Understand this

21 And this

22 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 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 24

25 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 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 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 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 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 30 Planification Besoins Analyse et conception Implémentation Déploiement Tests Evaluation Planification initiale

31 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 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 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 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 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 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 37 UML et MDA ● Model Driven Architecture...

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