La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Modélisation orientée objet UML Le langage de modélisation objet unifié"— Transcription de la présentation:

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 dun système (cas dutilisation, diagramme de classes…) Les vues dynamiques dun système (séquence, etats-transition…) Exercices

3 Objectifs du cours Architecture logicielle : Approcher les problèmes danalyse 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 dorganisation dun 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 dun logiciel ne correspond pas à lanalyse des besoins dune entreprise! Ne pas tenter de solutionner tous les problèmes dune entreprises avec un seul logiciel : apprendre à cerner le problème à traiter. Les méthodes orientées objet ne traitent pas des problèmes organisationnels dune entreprise

6 Schéma classique - caricatural

7 Problème de cette vision des choses Ignore les relations avec les autres applications de lentreprise (la gestion des stocks peut communiquer avec la fabrication des marchandises, les commandes clients…). Cloisonne les activités : organisation hiérarchique de lanalyste 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. Larchitecture doit être modulaire.

8 Développement orienté objet

9 Développement orienté objet…suite Conséquences de lapplication des méthodes orientés objet : les phases danalyse, 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 danalyse.

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

11 Un peu dhistoire 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 ( ) Analyse sur les données et les traitements Plus de 50 méthodes objets (dont OMT, OOSE)

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

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 lapplication ou du domaine traité. Encapsulation : Les structures de données et les détails de limplémentation sont cachés aux autres objets du système. La seule façon daccéder à létat dun objet est de lui envoyer un message qui va déclencher lexécution de lune 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 dune classe possède ses caractéristiques (attributs+méthodes), mais aussi celles dune é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) à lintérieur du programme dans lobjectif den réduire la complexité. Polymorphisme : Possibilité de recourir à la même expression pour dénoter différentes opérations. Lhé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 dune personne? Quelles sont les comportements génériques dune personne? Pouvez vous donnez des exemples dinstances dune personne? Donnez des exemples de sous classes.

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

18 Ajout dune 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 dun module : On part dun tout que lon é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 dexprimer en décomposition logicielle ce quest une partie. En conception on fait lhypothèse que le système est un tout et quil 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é nest pas une entité du domaine du problème. La granularité de la taille des entités dépend du niveau dabstraction.

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 puisquune fonctionnalité nest pas une entité du monde concret. La granularité de la taille des entités à utiliser est un facteur important de leffort dabstraction à réaliser.

22 Quelques règles décriture dun module Un module représente un concept et tout le concept. Ne pas regrouper dans un module des opérations qui nont 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 dexpression (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 : Laccè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 dattribut 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ée par 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.


Télécharger ppt "Modélisation orientée objet UML Le langage de modélisation objet unifié"

Présentations similaires


Annonces Google