© Petko ValtchevUniversité de Montréal Février 2002 1 IFT 2251 Génie Logiciel Génie Logiciel Orienté-Objet Hiver 2002 Petko Valtchev.

Présentation au sujet: "© Petko ValtchevUniversité de Montréal Février 2002 1 IFT 2251 Génie Logiciel Génie Logiciel Orienté-Objet Hiver 2002 Petko Valtchev."— Transcription de la présentation:

1 © Petko ValtchevUniversité de Montréal Février 2002 1 IFT 2251 Génie Logiciel Génie Logiciel Orienté-Objet Hiver 2002 Petko Valtchev

2 © Petko ValtchevUniversité de Montréal Février 2002 2 Conception Sommaire l Introduction et concepts de base l Modélisation par objets et UML l Diagramme de classes l Diagramme de cas d’utilisation l Diagrammes de collaboration l Diagramme d’états l Diagramme d’activités l Processus de modélisation

3 © Petko ValtchevUniversité de Montréal Février 2002 3 Conception L’Essence de l’Orienté-Objet l Le paradigme orienté-objet (OO) = modéliser les traitements sous forme d’un ensemble de composants qui communiquent entre eux afin de faire émerger la solution du problème global. l Le paradigme structuré = modélise les traitements effectués par un logiciel en termes de fonctions (mathématiques) de transformation des données. système « SafeHome » système composant Capteurs Alarme

4 © Petko ValtchevUniversité de Montréal Février 2002 4 Conception L’approche structurée: division des fonctionnalités en processus de plus en plus simples (diviser-pour-régner), transformation en modules puis factorisation. L’approche OO : réunir les données et leur traitement dans la même unité, l’objet. Quelques retombées de la décomposition en objets: l Conduit à des modèles plus naturels du domaine d’application l La distance cognitive entre les artefacts informatiques (les objets et les classes) et les entités du domaine est faible l Facilite la maintenance l Augmente l’extensibilité du logiciel produit l Rend possible la réutilisation de composants existant l S’accorde bien de la complexité des problèmes à résoudre l Permet de tracer les besoins plus facilement La Raison d’Être de l’OO

5 © Petko ValtchevUniversité de Montréal Février 2002 5 Conception Les Objets « A concept, abstraction or thing with crisp boundaries and meaning for the problem at hand. » Rumbaugh et al., 1991 « [reflects] the capabilities of a system to keep information [or] to interact. » Coad and Yourdon, 1991 « [has] state, behaviour and identity. » Booch, 1993 « represents a particular instance of a class. It has identity and attribute values. » UML Spec V1.1 Quelques tentatives de définition de la notion d’objet:

6 © Petko ValtchevUniversité de Montréal Février 2002 6 Conception l Les objets possèdent un ensemble (peut être vide) d’attributs. l Attribut = propriété de l’entité exprimée par l’objet l Les attributs ont un type et peuvent prendre des valeurs. l Les attributs sont de nature: l statique, l Dynamique. l L’état d’un objet est composé par l’ensemble des valeurs de ses attributs. L’État d’un Objet Ex. Un objet voiture Attributs possibles : l producteur l modèle l km parcourus l date-taxation l date-contrôle l date-enregistrement États possibles: l enregistrée / non enregistrée l taxée / non taxée l contrôlée / non contrôlée

7 © Petko ValtchevUniversité de Montréal Février 2002 7 Conception l Un ensemble d’opération est associé à chaque objet. l Une opération est toujours activée par un autre objet par l’envoi d’un message. En réponse du message (requête) l’opération peut: l consulter les données stockées dans les attributs de l’objet l modifier ces données. l Le comportement de l’objet est constitué par les opérations valides. Comportement et Identité Ex. Un objet voiture changer de couleur taxer faire contrôler l Chaque objet possède une identité, un identifiant unique dans le système appelé obj-id. l L’identifiant est indépendant des valeurs des attributs de l’objet.

8 © Petko ValtchevUniversité de Montréal Février 2002 8 Conception l Les objets de l’application collaborent afin de réaliser les besoins fonctionnels. l Les objets communiquent en s’envoyant de messages. l Un message est une requête adressée par un objet à un autre objet qui lui demande de faire quelque chose (rendre un service): l Un message appelle une opération de l’objet destinataire, l Il peut inclure des paramèters = données nécessaires pour exécuter l’opération, l Il peut transmettre une valeur de retour = le résultat de l’opération. Envoi de Messages emprunter abonné nom adresse état livre titre état l L’objet abonné envoie un message emprunter à livre l L’objet livre appelle l’opération emprunter l Résultat: son état change en prêté

9 © Petko ValtchevUniversité de Montréal Février 2002 9 Conception L’Encapsulation données comportement OBJETOBJET Signature = Nom opération + Nombre et types des paramètres

10 © Petko ValtchevUniversité de Montréal Février 2002 10 Conception l L’implémentation d’un objet reste cachée pour les autres objets, cependant cela ne les empêche pas d’utiliser les services que l’objet offre. l « Know what not how! » l Les autres objets ne voient que les protocoles des opérations admissibles d’un objet. l Ce principe permet de faire évoluer de manière significative la partie interne cachée de l’objet sans effet néfaste sur le reste du système. l Du moment que l’objectif et le protocole d’une opération restent les mêmes, les éventuels changement ne se propagent pas dans le code. Atouts de l’Encapsulation

11 © Petko ValtchevUniversité de Montréal Février 2002 11 Conception Les Classes « a group of objects with: similar properties, common behaviour, common associations to other objects and common semantics. » Rumbaugh et al., 1991 « a descriptor for a set of objects with similar structure and behaviour. » UML Spec V1.1 Quelques tentatives de définition de la notion de claasse:

12 © Petko ValtchevUniversité de Montréal Février 2002 12 Conception l Principe de regroupement des objets en classes : en fonction du comportement et de la structure que les objets ont en commun. l Les objets d’une classe = ses instances. l Plus les objets partagent des propriétés et des opérations, plus ils ont la chance de se retrouver ensemble dans une classe bien définie. l Le principe de classification supporte bien l’évolution dans les classes: l ajout de nouveaux attributs ou opérations, l modification du comportement existant. l Ex. Un compte épargne est un type particulier de compte qui rapporte des intérêts sur son solde et qui n’autorise pas les découvertes. Classification

13 © Petko ValtchevUniversité de Montréal Février 2002 13 Conception Ex. Syst. d’Information Universitaire : une classe générale Employé (StaffMember). l Pour des raisons de modélisation, il faut distinguer les Employés académiques des Employés administratifs. l Une raison: les administratifs ne peuvent pas enseigner La classe StaffMember sera specialisée l La spécialisation permet de diférencier les objets d’une classe existante en les divisant en un ensemble de classes plus restreintes (plus spécifiques) appelées les sous-classes. l Les sous-classes étendent la sur-classe en ajoutant des nouvelles informations. Leurs instances sont également des instances de la sur- classe. Spécialisation

14 © Petko ValtchevUniversité de Montréal Février 2002 14 Conception Spécialisation AcademicStaff possède des associations spécialisantes avec la classe Module Les instances de AdminStaff et AcademicStaff partagent les attributs name, address, phone, nextOfKin qui leur viennent de la classe StaffMember

15 © Petko ValtchevUniversité de Montréal Février 2002 15 Conception l Le mécanisme d’héritage permet une modélisation différentielle : l Afin de définir une nouvelle classe qui est la spécialisation d’une classe existante, on ne doit spécifier que les propriétés et le comportement spécifiques pour la nouvelle classe. l L’héritage permet donc la réutilisation des définitions des classes existantes, tout en minimisant l’effort de description (en évitant les duplications). l Le principe réalise une factorisation du modèle : les descriptions d’un attribut et/ou d’une opération ne se trouvent qu’à un seul endroit dans le modèle. l Favorise les changements : ceux-ci qui se répercutent automatiquement sur toutes les sous-classes. l L’héritage n’a pas un effet contraignant, les sous-classes peuvent remodeler les éléments hérités l Ex. Les deux sous-classes de StaffMember redéfinissent l’opération pay (sans changer la signature) Héritage

16 © Petko ValtchevUniversité de Montréal Février 2002 16 Conception l Le polymorphisme est un principe qui se base sur la spécialisation et l’héritage. l Permet de s’adresser aux instances d’une classe pour leur demander un service sans pour autant se soucier de la sous-classe exacte de ces instances (et donc de la sémantique particulière de l’opération sous-jacente) Ex. La redéfinition de pay en est une manifestation : les deux sous-classes AdminStaff et AcademicStaff définissent leur propre implémentation de cette opération, néanmoins, le même message pay peut être envoyé à un ensemble d’instances de StaffMember sans savoir à quelle des deux sous-classe elles appartiennent, l la méthode appropriée sera toujours exécutée. Polymorphisme « Capacité d’un phénomène de se manifester sous plusieurs (poly) formes (morph) différentes. »

17 © Petko ValtchevUniversité de Montréal Février 2002 17 Conception References l Bennett, S., McRobb, S. & Farmer, R. Object-Oriented Systems Analysis and Design using UML McGraw-Hill 1999 l Jacobson, I., Booch, G. and Rumbaugh, J. (1999), The Unified Software Development Process, Addison-Wesley, Reading Mass. l Rational Unified Process 2000