Modélisation orientée objet UML

1. Modélisation orientée objet UML Le langage de modélisation objet unifié

2. Plan du cours • Historique • Rappels • UML • Présentation • Les vues statiques d’un système (cas d’utilisation, diagramme de classes…) • Les vues dynamiques d’un système (séquence, etats-transition…) • Exercices

3. Objectifs du cours • Architecture logicielle : • Approcher les problèmes d’analyse et de conception des systèmes informatiques (les programmes). • Au travers du filtre des méthodes orientées objet : • UML (Unified Modeling language).

4. Ce que nous ne ferons pas ! • Traitement des problèmes d’organisation d’un développement informatique (gestion du temps, des ressources…). • Les différentes méthodes de conduite de projets (RUP, XP…). • Toutes les méthodes de conduite de projet utilise UML!

5. Les erreurs classiques • Analyse et conception d’un logiciel ne correspond pas à l’analyse des besoins d’une entreprise! • Ne pas tenter de solutionner tous les problèmes d’une entreprises avec un seul logiciel : apprendre à cerner le problème à traiter. • Les méthodes orientées objet ne traitent pas des problèmes organisationnels d’une entreprise

6. Schéma classique - caricatural

7. Problème de cette vision des choses • Ignore les relations avec les autres applications de l’entreprise (la gestion des stocks peut communiquer avec la fabrication des marchandises, les commandes clients…). • Cloisonne les activités : organisation hiérarchique de l’analyste au programmeur, pas de contact entre le client et le réalisateur final! • Un système doit être facile à modifier pour de la maintenance corrective et évolutive. • L’architecture doit être modulaire.

8. Développement orienté objet

9. Développement orienté objet…suite • Conséquences de l’application des méthodes orientés objet : • les phases d’analyse, conception et de programmation sont très liées. • Historiques de méthodes orientées objet : • Langage de programmation. • Méthodes de conception. • Méthodes d’analyse.

10. Un peu d’histoire sur les langages de programmation… • 1967 : le langage SIMULA (origine de la couche objet de C++) : • Notions de classes, d’objets et des procédures locales à une classe! • 1972 : le langage SmallTalk • interaction Homme-Machine, souris et fenêtres (origine de l’ergonomie de Macintosh). • Les Années 80 : • foisonnement des langages Cobol, C++, java…

11. Un peu d’histoire sur les méthodes de conception… • Les premières méthodes d'analyse (années 70) • Découpe cartésienne (fonctionnelle et hiérarchique) d'un système. • L'approche systémique (années 80) • Modélisation des données + modélisation des traitements (Merise). • L'émergence des méthodes objet (1990-1995) • Analyse sur les données et les traitements • Plus de 50 méthodes objets (dont OMT, OOSE) 

12. Un peu d’histoire sur les méthodes de conception… • 1995 : Premier consensus • OMT : Notation graphique riche (General Electric) • OOD : concept de package ( élèment d’organisation des modèles) • OOSE : La méthodologie repose sur l'analyse des besoins des utilisateurs (Ericsson). • Unification et la normalisation des méthodes (1995-1997) • OMG : Object Management Group. Association de professionnels de l'informatique orientée objet. • Apparition d’UML

13. Petite piqûre de rappel • Objets : • Unités de base organisées en classes et partageant des traits communs (attribut ou procédures). • Entités du monde réel, des concepts de l’application ou du domaine traité. • Encapsulation : • Les structures de données et les détails de l’implémentation sont cachés aux autres objets du système. • La seule façon d’accéder à l’état d’un objet est de lui envoyer un message qui va déclencher l’exécution de l’une de ses méthodes.

14. Encore une… • Abstraction • Il s'agit d'un processus qui consiste à identifier les caractéristiques intéressantes d'une entité, en vue d'une utilisation précise. • L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des caractéristiques essentielles d'une entité, retenues par un observateur. • Héritage: • Chaque instance d’une classe possède ses caractéristiques (attributs+méthodes), mais aussi celles d’une éventuelle super classe (classe mère). • Permet de décrire un type de lien qui unit les différents objets.

15. La dernière! • Modularité : • Partition du programme qui crée des frontières bien définies (et documentées) à l’intérieur du programme dans l’objectif d’en réduire la complexité. • Polymorphisme : • Possibilité de recourir à la même expression pour dénoter différentes opérations. • L’héritage est une forme particulière de polymorphisme caractéristique des systèmes orientés objet.

16. Un petit exercice… …pour la forme ! • Quelles sont les caractéristiques d’une personne? • Quelles sont les comportements génériques d’une personne? • Pouvez vous donnez des exemples d’instances d’une personne? • Donnez des exemples de sous classes.

17. Un petit exercice… …pour la forme ! • Le type de la classe personne.

18. Ajout d’une classe vieil homme

19. Trouver les bons objets • Méthode de désagrégation / agrégation : • Désagréger un module : {modules} • Agréger un {modules} : un module • Désagrégation d’un module : • On part d’un tout que l’on éclate en plusieurs parties. Chaque partie formant à son tour un tout, est susceptible d’être à nouveau éclatée en parties plus petites. • Il est difficile d’exprimer en décomposition logicielle ce qu’est une partie. • En conception on fait l’hypothèse que le système est un tout et qu’il est composé de parties cohérentes séparables.

20. Trouver les bons objets • La décomposition est basée sur les entités du domaine du problème. • La désagrégation est très différente de la décomposition fonctionnelle car une fonctionnalité n’est pas une entité du domaine du problème. • La granularité de la taille des entités dépend du niveau d’abstraction.

21. Trouver les bons objets • La décomposition est basée sur les entités du domaine du problème. • La désagrégation est très différente de la décomposition fonctionnelle puisqu’une fonctionnalité n’est pas une entité du monde concret. • La granularité de la taille des entités à utiliser est un facteur important de l’effort d’abstraction à réaliser.

22. Quelques règles d’écriture d’un module • Un module représente un concept et tout le concept. • Ne pas regrouper dans un module des opérations qui n’ont pas de raison d’être ensemble (module fourre-tout). • Pour concrétiser une idée le choix du nom du module est un élèment puissant d’expression (Design Patterns). • Phase simpliste : Le choix des méthodes correspond aux verbes.

23. Les qualificatifs de classe • Publique : • Les fonctions de toutes les classes peuvent accéder aux données ou aux méthodes d'une classe définie avec le niveau de visibilité public. Il s'agit du plus bas niveau de protection des données. • Protégée : • L’accès aux données est réservé aux fonctions des classes héritières, c'est-à-dire par les fonctions membres de la classe ainsi que des classes dérivées. • Privée : • L'accès aux données est limité aux méthodes de la classe elle-même. Il s'agit du niveau de protection des données le plus élevé.

24. Les qualificatifs d’attribut • Publique : Un attribut publique pourra être accéder (lu et modifié) par tout le monde. • Protégée : Un attribut protégé pourra être accéder (lu et modifié) par les classes héritières. • Privée : Un attribut privée pourra être accéder (lu et modifié) par les méthodes et seulement les méthodes de sa classe.

25. Les qualificatifs de méthode • Publique : Une méthode publique pourra être utiliséepar tout le monde. • Protégée : Une méthode protégée pourra être utilisée ou redéfinie par les classes héritières. • Privée : Une méthode privée pourra être utilisée par les méthodes et seulement les méthodes de sa classe.