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

Génie Logiciel Orienté Objet. Plan 1.Introduction et concepts de base 2.Modélisation par objets zModèle objet zModèle dynamique zModèle fonctionnel zProcessus.

Présentations similaires


Présentation au sujet: "Génie Logiciel Orienté Objet. Plan 1.Introduction et concepts de base 2.Modélisation par objets zModèle objet zModèle dynamique zModèle fonctionnel zProcessus."— Transcription de la présentation:

1 Génie Logiciel Orienté Objet

2 Plan 1.Introduction et concepts de base 2.Modélisation par objets zModèle objet zModèle dynamique zModèle fonctionnel zProcessus de modélisation 3.Implantation des modèles objets 4.Discussion

3 Introduction et concepts de base zL’approche objet présente: yUne vue conceptuelle du « monde » composé d’objets yObjets = interconnexion entre données et traitements sur ces données yUne approche unificatrice du cycle de vie zNe résout pas tout les problèmes du génie logiciel mais: yOffre de bonnes et élégantes solutions dans certains domaines d’application, par exemple, ingénierie des interfaces usagers et systèmes hautement extensibles yEst une approche clé pour supporter la réutilisation du logiciel.

4 Introduction (suite) zOrigines de l’approche OO: smalltalk (70), prédécesseur: Simula67 zL’approche objet est principalement bâtie sur les deux principes du génie logiciel: yAbstraction des données yDissimulation de l’information zConcepts de base yObjets yClasses yHéritage yMessages yPolymorphisme et liaison dynamique

5 Objets zDéfinition conceptuelle: Un objet incorpore une abstraction et fournit des services aux usagers (clients) zExemple 1: Pile yAbstraction incorporée: la pile yServices fournis: empiler, dépiler, tester si pile est vide. zExemple 2: compte bancaire yAbstraction incorporée: le compte (client, succursale,…) yServices fournis: ouvrir, fermer, débiter, créditer, connaître le solde.

6 Objets zConcepts sous-jacents: yÉtat de l’objet yComportement de l’objet (services rendus) yAspects caché: encapsulation des données, réalisation du comportement.

7 Objets (suite) zDéfinition informatique: un objet incorpore une structure de données représentant un concept du monde réel et les opérations possibles (appelées aussi méthodes) sur cette structure de données. zUn objet se compose de deux parties: yPartie visible: interface avec le reste du monde (autres objets, programmes, …) yPartie cachée: réalisation technique de la structure de données et des opérations. zConséquences: yChaque objet est un module, yLes langages de programmation classiques (Fortran, Pascal, C,…) ne permettent pas l’implantation du concept d’objet.

8 Classes zPoint du vue conceptuel (vision du monde réel): yUne classe représente un ensemble d’objets ayant les mêmes caractéristiques (structure et comportement) yExemple: compte bancaire, tous les comptes bancaires ont les mêmes attributs (mêmes structures de données) et les mêmes méthodes (services rendus)

9 Classes zPoint de vue informatique: yUne classe définit un ensemble d’objets possibles yUne classe est définie par une déclaration yAnalogie: déclaration de types, définition de variables yAu plan concret (exécution du programme), une classe n’existe pas. yUn objet est une réalisation concrète d’une classe. Un objet est créé (à l’exécution) conformément au patron de la classe; il existe.

10 Classes et Objets zExemple: compte bancaire //description de la classe (interface, cachée) Etc.

11 Classes et Objets zImplantation des classes et des objets yLa création d’un objet d’une classe crée physiquement un exemplaire de la structure de données définie dans la déclaration de la classe. Toute opération sur l’objet affecte cet exemplaire. yPar contre, les méthodes (opérations) définies dans la déclaration de la classe ne sont pas recopiées. Il en existe un seul exemplaire qui est invoqué chaque fois qu’une opération est exécutée sur un objet de la classe.

12 Héritage zDéfinition générale: yRelation entre deux classes yY hérite de X: Y possède (reçoit) toutes les caractéristiques de X. On dit Y est descendant de X. zPropriétés de l’héritage: Transitivité ySi Y descendant de X et Z descendant de Y alors Z descendant de X. Z reçoit toutes les caractéristiques de X (et de Y).

13 Héritage zDeux formes d’héritage: enrichissement, substitution. yEnrichissement: Y descendant de X. Y reçoit toutes les caractéristiques de X; en plus on peut définir des caractéristiques additionnelles (données et opérations) spécifiques à la classe Y. ySubstitution: Y descendant de X. Certaines caractéristiques reçues de X sont redéfinies pour la classe particulière Y. zLa plus part des héritages sont une combinaison d’enrichissement et de substitution.

14 Héritage multiple zUne classe peut être héritière de plusieurs autres classes. zPropriétés de l’héritage multiple: Si Z hérite de X et Y, les caractéristiques de Z sont l’union des caractéristiques de X et Y. zProblèmes de l’héritage multiple: conflits possibles entre caractéristiques de même nom venant d’ancêtres différents.

15 Messages zLes objets communiquent entre eux par messages; c’est l’unique moyen de communication entre objets. zDéfinition: un message est une communication entre deux objets: requêtes envoyée par un objet « client » à un objet « serveur ». zForme de l’envoi d’un message. À spécifier: yL’objet serveur yLa méthode yLes arguments correspondants à la méthode ySi la méthode produit un résultat, place (variable) pour ce résultat.

16 Polymorphisme et liaison dynamique zUne entité de programme doit pouvoir faire référence à des objets de plusieurs classes, et une opération doit pouvoir avoir des versions différentes dans des classes différentes. zRelation étroite avec les langages de programmation.

17 Modélisation par objets zObjectifs: yAnalyser et spécifier le problème yConcevoir une solution au problème yPréparer l’implantation de la solution avec un langage de programmation et/ou à l’aide d’une base de données  « méthodologies d’analyse et de conception OO » zMéthodologies connues: yBooch, Jacobson, Rumbaugh.. yConvergence vers une méthodologie intégrant les approches de Booch, Rumbaugh et Jacobson (1995)

18 Object Modeling Technique (OMT) zMéthodologie développée par James Rumbaugh et d’autres en zPermet l’utilisation des mêmes concepts et des mêmes notations tout au long du processus de modélisation zModélisation par trois modèles complémentaires, chacun offrant un point de vue particulier: yLe modèle objet représente les aspects statiques et structurels et l ’aspect des données d’un système. yLe modèle dynamique représente les aspects temporels et comportementaux et l’aspect de contrôle d’un système yLe modèle fonctionnel représente les aspects de fonction et de transformation.

19 Modèle objet zIl saisit la structure statique d’un système, en montrant ses objets, les relations entre eux, ainsi que les attributs et les opérations qui caractérisent chaque classe d’objets. zIl constitue le cadre dans lequel les modèles dynamiques et fonctionnels s’insèrent. zDescription par deux types de diagramme: yDiagramme de classes: schéma permettant de décrire un grand nombre d’instances possibles de données. Il décrit les classes d’objets. yDiagramme d’instances: décrit comment un ensemble particulier d’objets est lié à d’autres objets.

20 Diagrammes de classes et d’instances Projet Personne Langage Diagramme de classes (projet) Syst. De comp. (projet) Logiciel CAO (Langage) Cobol (Langage) C (Personne) Mary Diagramme d’instances

21 Liens et associations zLes liens et les associations permettent d’établir des relations entre objets et classes. zUn lien est une connexion physique ou conceptuelle entre des instances d’objets zUne association décrit un groupe de liens ayant une structure et une sémantique commune. zMultiplicité des associations: spécifie le nombre d’instances d’une classe qui peuvent être liées à une instance d’une classe associée.

22 Liens et associations Classe ,4 Exactement un Plusieurs (0 ou plus) Optionnel(0 ou1) Un ou plus Spécifié numériquement

23 Liens et associations zUn attribut de lien est une propriété des liens d’une association zIl est parfois utile de modéliser une association en classe: FichierUtilisateur Permission d’accès Accessible par Station de travail Utilisateur Propriété Autorisation Répertoire Début de session

24 Relation d’agrégation zL’agrégation est la relation « composé-composant » ou « partie de », dans laquelle les objets représentant les composants d’une chose sont associés à un objet représentant l’assemblage entier DocumentParagraphe Phrase

25 Généralisation et héritage zAbstractions puissantes qui permettent de partager les points communs entre les classes tout en préservant leurs différences: Équipement Nom Fabriquant … Pompe Pression d’aspiration Pression de débit Taux d’écoulement Réservoir volume … Échangeur de chaleur Superficie Diamètre Pression Type d ’équipement

26 Modèle dynamique zLe modèle dynamique décrit les aspects du système par rapport au temps et à l’ordonnancement des opérations. Il ne capture ni le contenu des opérations, ni les objets des opérations, ni leur implantation. zLe modèle dynamique est représenté graphiquement par un ensemble de diagrammes d’états dont chaque diagramme représente une classe qui expose un comportement important. zUn diagramme d’états met en évidence les séquences d’états et d’évènements permis dans un système pour une classe d’objets..

27 Les diagrammes d’états zUn événement est quelque chose qui se produit à un moment donné dans le temps, par exemple l’usager appuie sur le bouton gauche ou bien le vol 217 part de Mirabel. zUn état est une abstraction des valeurs des attributs et des liens d’un objet. zUn état spécifie la réponse d’un objet à un événement d’entrée. zUn diagramme d’états lie les évènements aux états. Il est un graphe dont: yLes nœuds sont des états yLes arcs orientés sont des transitions désignées par des noms d’évènements.

28 Diagrammes d’états zDes conditions peuvent être utilisées comme garde (guard) sur les transitions: yUne transition gardée est franchie quand survient un événement, mais seulement si la condition de garde est satisfaite. yExemple: Quand tu sors le matin (événement), si la température est glaciale (condition), alors mets tes gants (état suivant, action). zLa description comportementale d’un objet doit spécifier ce que fait l’objet en réponse aux évènements.

29 Exemple de diagramme d’états Composant Tonalité décrocher En attente Composer chiffre (n) Délai Fin de délai Faux numéro Message en. Connectant Bon numéro Sonnant acheminé connecté Déconnecté Tél. appelé répond Tél. appelé décroché raccroché Message fini raccroché

30 Modèle fonctionnel zIl décrit les aspects relatifs aux transformations des valeurs: les fonctions, les correspondances, les contraintes et les dépendances fonctionnelles. zIl modélise ce que fait un système, sans s’occuper de la façon ou du moment où il les fait. zIl est représenté graphiquement par des diagrammes de flots de données.

31 Diagrammes de flots de données zIl contient des traitements qui transforment les données, des flots de données qui transportent les données, des acteurs qui produisent et consomment les données, et des dépôts de données qui stockent passivement les données.

32 Les flots de contrôle zUn diagramme de flots de données ne montre pas quels chemins sont exécutés ni dans quel ordre. zDécisions et séquences sont des problèmes de contrôle et, en tant que tels, font partie du modèle dynamique. zCependant, il est parfois utile de les englober dans le modèle fonctionnel (but: ne pas les oublier) zCeci se fait en englobant les flots de contrôle dans les diagrammes de flots de données. zUn flot de contrôle est une valeur booléenne qui permet de savoir si un traitement est évalué. Il est représenté par une ligne pointillée.

33 Processus de modélisation zLa méthodologie OMT prévoit trois étapes: yAnalyse yConception du système yConception des objets

34 Analyse zLe but est de développer un modèle de ce que le système doit faire. Ce modèle est exprimé en termes d’objets et de relations, de flux dynamiques et de transformations fonctionnelles. 1.Écrire ou obtenir une description initiale du problème. 2.Construire un modèle objet. zIdentifier les classes d’objets zCommencer à remplir un dictionnaire de données contenant les descriptions des classes, des attributs et des associations. zAjouter les associations entre les classes. zAjouter les attributs des objets et des liens zOrganiser et simplifier les classes en utilisant l’héritage zTester les chemins d’accès en utilisant des scénarios et itérer les étapes précédentes. zRegrouper les classe en modules, selon le critère du couplage fort et des fonctions apparentées.  Modèle objet = diagramme du modèle objet + dictionnaire de données.

35 Analyse (suite) 3. Développer un modèle dynamique. yPréparer des scénarios des séquences d’interactions typiques. yIdentifier les évènements entre les objets et préparer un diagramme de suivi des évènements pour chaque scénario. yPréparer un diagramme de flots d’évènements pour le système. yDévelopper un diagramme d’états pour chaque classe ayant un comportement dynamique important. yVérifier la cohérence et la complétude des évènements partagés par touts les diagrammes d’états.  Modèle dynamique = diagramme d’états + diagramme global des flots d’évènements.

36 Analyse (suite) 4. Construire un modèle fonctionnel. yIdentifier les valeurs d’entrée et de sortie yUtiliser des diagrammes de flots de données là où c’est nécessaire pour mettre en évidence les dépendances fonctionnelles. yDécrire ce que fait chaque fonction. yIdentifier les contraintes ySpécifier les critères d’optimisation.  Modèle fonctionnel = diagramme de flots de données + contraintes.

37 Analyse (suite) 5. Vérifier, itérer et raffiner les trois modèles. yAjouter au modèle objet les opérations clés découvertes lors de la préparation du modèle fonctionnel. yVérifier que les classes, associations, attributs et opérations soient cohérents et complets à chaque niveau d’abstraction. yComparer les trois modèle à la définition du problème et aux connaissances pertinentes du domaine et tester les modèles à l’aide des scénarios. yDévelopper des scénarios plus élaborés (comprenant des conditions d’erreurs) comme variations des scénarios de base. Utiliser des scénarios de type « que se passera-t-il, si … ». yRecommencer les étapes ci-dessus autant de fois que nécessaire pour compléter l’analyse.  Documentation d’analyse = définition du problème + modèle d’objets + modèle dynamique + modèle fonctionnel.

38 Conception du système zDurant la conception du système, le choix de la structure de haut niveau du système (architecture du système) est arrêtée. 1.Organiser le système en sous systèmes 2.Allouer les sous-systèmes à des processus et à des tâches 3.Choisir la stratégie de base pour implanter les stockages des données en termes de structures de données, de fichiers et de base de données. 4.Identifier les ressources globales et déterminer les mécanismes de contrôle d’accès. 5.Choisir une approche pour l’implantation du contrôle du logiciel. 6.Examiner les conditions de limites 7.Établir des compromis de priorités.  Documentation de conception du système = structure de l’architecture de base du système et décisions stratégiques de haut niveau.

39 Conception des objets zÉlaborer le modèle d’analyse et fournir un support détaillé pour l’implantation. zOn arrête les décisions nécessaires à la réalisation du système sans entrer dans les détails propres à un langage de programmation ou un système de base de données. zDans le modèle d’analyse c’est le monde réel. zDans le modèle de conception c’est les points de vue informatique pour l’implantation concrète.

40 Conception des objets 1.Obtenir les opérations pour le modèle objet à partir des autres modèles: -Trouver une opération pour chaque traitement du modèle fonctionnel. -Définir un opération pour chaque événement du modèle dynamique, en fonction de l’implantation du contrôle. 2.Concevoir les algorithmes pour implanter les opérations. -Choisir les algorithmes qui minimisent les coûts d’implantation des opérations. -Sélectionner les structures de données appropriées à ces algorithmes. -Définir de nouvelles classes internes et de nouvelles opérations si nécessaire. -Affecter des responsabilités aux opérations qui ne sont pas clairement associées à une classe.

41 Conception des objets 3. Optimiser les chemins d’accès aux données: -Ajouter des associations redondantes pour minimiser les coûts d’accès et augmenter la commodité. -Enregistrer les valeurs calculées pour éviter de recalculer des expressions complexes. 4. Implanter le contrôle du logiciel en complétant l’approche choisie en phase de conception du système.

42 Conception des objets 5. Ajuster la structure de classes pour augmenter l’héritage -Réorganiser et ajuster les classes et les opérations pour accroître l’héritage. -Abstraire le comportement commun à un groupe de classes. -Utiliser la délégation pour partager les comportements là où l’héritage est invalide sur la plan sémantique. 6. Concevoir l’implantation des associations -Analyser le parcours des associations. -Implanter chaque association comme un objet distinct, en ajoutant des attributs à une des classes associées ou aux deux classes.

43 Conception des objets 7. Déterminer la représentation exacte des attributs de l’objet. 8. Empaqueter les classes et les associations au sein de modules physiques.  Documentation de conception = modèle objet détaillé + modèle dynamique détaillé + modèle fonctionnel détaillé.


Télécharger ppt "Génie Logiciel Orienté Objet. Plan 1.Introduction et concepts de base 2.Modélisation par objets zModèle objet zModèle dynamique zModèle fonctionnel zProcessus."

Présentations similaires


Annonces Google