Téléchargé parAbarkanAli1
PPTX, PDF28 vues

Cours_Magistral_Seance_1.pptx pour la conception orienté objet

Conception

Intégrer la présentation

Télécharger pour lire hors ligne
CONCEPTION ORIENTÉE OBJET Présentation Amosse Edouard Inspiré du cours de F .
ORGANISA TION D U C OU R S 1. Volume Horaire et ED T http://unice.fr/faculte-des- sciences/departements/informatique/contenus-riches/documents - telechargeables/documentsl3i/calendrier-des-cours-tp-et-td-de- projet- informatique-et-de-coo 2. Evaluation 1. Examen théorique : 1h30 : 50% 2. Travaux Pratiques (en TD) : 50%
PLAN D U C O U R S Introduction aux méthodologies de conception Introduction à UML Objets et Classes Les diagrammes  Les cas d’utilisation  Les classes et leurs instances  Les machines à états (et transitions)  Les activités  Les interactions  Le mécanisme de profilage
OBJECTIFS Montrer les forces de la COO Décrire l’histoire de la POO Commenter l’utilisation actuelle de la POO
CYCLE DE VIE D’UN LOGICIEL Expression des besoins Spécification Analyse des besoins Conception Implémentation T ests et vérification Validation
C Y C L E DE VIE D’UN LOGICIEL Expression des besoins Définition d’un cahier des charges Spécification Ce que le système doit être et comment il peut être utilisé Analyse Éléments intervenant dans le SI, leurs structures et relations A définir sur 3 axes  axe fonctionnel  axe statique  axe dynamique Savoir-faire de l’objet Structure de l’objet Cycle de vie de l’objet Conception Apport de solutions techniques: architecture, performance et optimisation Définition des structures et des algorithmes
C Y C L E DE VIE D’UN LOGICIEL Implémentation Réalisation et programmation T ests et Vérification Contrôles de qualité Vérification de la correspondance avec le cahier des charges Maintenance et Evolution Maintenance corrective : traiter les erreurs (bugs) Maintenance évolutive : intégration de nouveaux changements
CONCEPTION  Processus créatif qui consiste à représenter les diverses fonctions du système permettant d’obtenir rapidement un ou plusieurs programmes réalisant ses fonctions.  Une « bonne » conception se définit en termes de la satisfaction des besoins et des spécifications.  Une bonne Conception participe largement à la production d'un logiciel qui répond aux facteurs de qualité. Elle se base sur la Modularité.
CONCEPTION – CRITÈRES DE QUALITÉ  Cohésion : Se définit comme étant le caractère de ce qui forme un tout, dont les parties sont difficilement séparables.  Couplage : Relatif à la cohésion. Il exprime le degré d’interconnexion des differents composants d’un système. Compréhensibilité : La compréhensibilité d’un module dépend de : - Sa cohésion - L’appelation : Utilisation de noms significatifs - La documentation : Lien entre le monde réel et le composant - La complexité  Adaptabilité : Dépend du couplage et de la documentation. Un logiciel adaptable doit avoir un haut degré de lisibilité.
MÉ THODE S DE CONCEPTION On distingue principalement de trois de méthodes de conception: Méthodes fonctionnelles Méthodes systémiques Méthodes orientées objets
MÉ THODE S FONCTIONNELLES Les méthodes finctionnelles ou cartésiennes consistent à décomposer hiérarchiquement une application en un ensemble de sous applications. Ces méthodes utilisent les raffinements successifs pour produire des spécifications don’t l’essentiel est sous forme de notation graphique en diagramme de flots de données.
MÉ THODE S FONCTIONNELLES Points forts Simplicité du processus de conception Capacité à répondre rapidement aux besoins ponctuels des utilisateurs Points faibles: Fixer les limites pour les décompositions hiérarchiques Rédondance (éventuelle) des données
MÉ THODE S SYSTÉMIQUES Les méthodes systéliques sont influencés par les systèmes de Gestion de bases de données en proposant une double démarche de modélisation: La modélisation des données La modélisation des traitements Points forts : Approche globale prenant en compte la modélisation des données et des traitements Niveaux d’abstraction dans le processus de conception Bonne adaptation à la modélisation des données et à la conceptiond es BDs Points faibles Double démarche de conception : données et traitements Pas de fusion possible des deux aspects (données et traitements)
MÉ THODE S FONCTIONNELLES E T SYSTÉMIQUES Les méthodes foncionnelles et systémiques sont de type descendant (approache Top- Down). Inconvénients Réutilisabilité : Modules non généraux mais adaptés aux sous problèmes pour lesquels ils ont été concus Extensibilité: L’architecture du logiciel est fondée sur les traitements qui sont moins stables que les données; par conséquent cette approche est inadaptée à la conception de gros logiciel.
MÉ THODE S ORIENTÉES OBJETS  Dans une approche Orientée Objet (OO), le logiciel est considéré comme une collection d’objets dissociés définis par des propriétés. Une propriété est soit un attribut de l’objet ou une opération sur l’objet.  Un objet comprend donc à la fois une structure de données et une collection d’opérations (son comportement).  Contrairement aux méthodes fonctionnelles et systémiques, les méthodes orientées objets sont ascendantes.
MÉ THODE S ORIENTÉES OBJETS La technologie Orientée Objet Guide la conception par Un ensemble de concepts Abstraction, modularité, Encapsulation, Polymorphisme Des langages et outils qui supportent ces concepts Classification vs. prototype Héritage (Simple, Multiple) Typage (Fort, Faible) Avantages Reflète plus finement les objets du monde réel Du code : facile à maintenir Plus stable: Isolation des changements Réutilisation des composantes Faciliter le prototypage
MÉ THODE S ORIENTÉES OBJETS – EXEMPLES Objets  Personnes  Etudiant, enseignant, principal, secrétaire  Diplôme  Année, matière, parcours  Notes  Coefficients Système de gestion d’un lycée Fonctions  Calculer la moyenne  Calculer les taux d’encadrement  Calculer le nombrede redoublants  Calculer le taux de réussite au baccalauréat
OBJECTIFS DES TECHNOLOGIES À OBJETS Utiliser le langage du domaine  Modèle et vocabulaire métier Construire des modèles faciles à:  Etendre, modifier, valider, vérifier Faciliter l’implantation  Génération facilitée vers les langages à objets Nécessite une méthode et des outils  Rational Unified Process, Agile, … (cf. semestre 2)  UML est seulement un langage
LES OBJETS… Définitions : 🢝 Entité cohérente rassemblant des données et du code travaillant sur ces données 🢝 Structure de données valuées qui répond à un ensemble de messages Caractérisé par : 🢝 son comportement : que peut-on faire avec cet objet? 🢝 Méthodes 🢝 son état : comment réagit l’objet quand on applique ces méthodes? 🢝 Attributs (Champs) 🢝 son identité : comment distinguer les objets qui ont le même état et le m ê m e comportement? 🢝 Identifiant A les mêmes réactions et la même modularité que le monde réel 🢝 L’objet informatique est une projection de l’objet du monde réel
U N MODÈLE Une simplification de la réalité
POURQUOI U N MODÈLE? Quatre objectifs à la modélisation  Aider à visualiser le système  Spécifier la structure et le comportement  Servir de plan pour la construction effective  Permettre de documenter les choix Quatre avantages  Abstraction : diviser pour régner  Compréhension : mises au point avec le client  L’énergie déployée pour modéliser révèle les difficultés  Les erreurs sur les modèles coûtent bien moins cher
IMPOR T ANCE DES MODÈLES Avion papier Avion militaire moins important Plus important Le développement logiciel AUSSI nécessite des modèles bien pensés !
OBJETS – CLASSESS (EXEMPLES) Classe Figure longueu r largeur origine périmètre surface transpo ser Obje t rectangle: Figure longueur: 24 largeur: 20 Origine : (12, 20) Figure rectangle= new Figure( ); rectangle.surface();
MODEL DRIVEN ARC HI T EC T URE (MDA)  Développement orienté modèles  Spécifier un modèle indépendant de la plateforme sur laquelle il sera déployé  Spécifier la ou les plateformes  Choisir une plateforme adaptée  Transformer le modèle de spécification en un modèle spécifique pour la plateforme
LES 4 PRINCIPES P O U R C R É E R U N MODÈLE Un modèle influence énormément la façon d’aborder le problème et la solution  Vue du concepteur BD # vue du programmeur OO Chaque modèle peut être exprimer à différents niveaux de précision  Les meilleurs modèles permettent de choisir le niveau de détail en fonction de qui regarde et pourquoi il le regarde Les meilleurs modèles sont liés à la réalité Un seul modèle n’est jamais suffisant  Tous les systèmes gagnent à être décrits avec plusieurs petits modèles relativement indépendant => comment assurer la cohérence entre les modèles
U N SEUL MODÈLE N E SUFFIT PAS! Créer un ou plusieurs modèles différents mais avec un point commun Vue logique Analystes/Concepteurs Structure Use-Cas Vue d’implantation Programmeurs Software management e View Utilisate Fonctio Vue procédé Intégrateur système Performance, scalabilité, débit ur final nalité Vue Déploiement Ingénieur système Topologie du système, livraison, installation, communication
UNIFIED MODELING L A N G U A G E (UML) Langage visuel unifié  Tout le monde doit parler le même langage Langage pour spécifier  Executable-UML  Supposé précis et non ambigu Des liens vers +s langages de prog.  Java, C++, VB  RDMS ou OODMS  Génération de code et reverse engineering.
UML - HIST ORIQUE Années 80: 🢝 Méthodes pour organiser la programmation fonctionnelle (Merise) 🢝 Séparation des données et des traitements Début des années 90: 🢝 Apparition de la programmation objet: nécessite d’une méthodologie adaptée 🢝 Apparition de plus de 50 méthodes entre 1990 et 1995 1994 🢝 Consensus sur 3 méthodes 🢝 OMT de James Rumbaugh : représentation graphique des aspects statiques, dynamiques et fonctionnels d’un système 🢝 OOD de Grady Booch: concept de package 🢝 OOSE de Ivar Jacobson: description des besoins de l’utilisateur
U M L Consensus entre OMT, OOD, OOSE pour créer une méthode commune: 🢝 UML : Unified Modeling Language (Langage de Modélisation Unifié) 1997: Définition de la norme UML comme standard de modélisation des systèmes d’information objet par l’OMG (Object Management Group) UML est employé dans l’ensemble des secteurs du développement informatique 🢝 Systèmes d’information 🢝 Télécommunication, défense 🢝 Transport, aéronautique, aérospatial 🢝 Domaines scientifiques Mais pas seulement : on peut modéliser des comportement mécaniques, humain, etc.
UML E T R U P Un langage n’est pas suffisant, il faut aussi une méthode Les méthodes (process) qui fonctionnent le mieux avec UML sont :  Orienté par les Use-case ;  Centré sur l’architecture ;  Itératif et incrémental. • Les utilisateurs réagissent au fur et à mesure. Rational Unified Process
MODELE ORIENTÉ “USE CASE” Les use-case sont la base  Ils doivent être précis et concis  Ils sont compréhensibles par la majorité  Ils permettent de synchroniser les différents modèles  Ils décrivent l’ensemble des fonctions du système et les acteurs concernés Retirer de l’argent Client Vérifier le solde
LES BASES D’UML Les éléments 🢝 Ce sont les abstractions essentielles au modèle. Les relations 🢝 Les relations expriment les liens existants entre les différents éléments. Les diagrammes 🢝 Un diagramme est une représentation visuelle de l’ensemble des éléments qui constituent le système 🢝 Ils servent à visualiser un système sous différents angles (utilisateur , administrateur par ex.) 🢝 Dans les systèmes complexes, un diagramme ne fournit qu’une vue partielle du système 🢝 L’ensemble des diagrammes réunis permet d’obtenir une vue globale du système à concevoir 🢝 Chaque diagramme va permettre de modéliser ou spécifier une vue (spécificité) du système à concevoir
UML - LES VUES Vue des cas d’utilisation 🢝 Description du modèle vu par les acteurs du système 🢝 Besoins attendus pour chaque acteur 🢝 Le QUOI et le QUI Vue logique 🢝 Définition du système vu de l’intérieur 🢝 COMMENT satisfaire les besoins des acteurs Vue d’implémentation 🢝 Dépendances entre les modules Vue des processus 🢝 Vue temporelle et technique 🢝 Mise en œuvre des notions de tâches concurrentes, synchronisation… Vue de déploiement 🢝 Position géographique et architecture physique de chaque élément
UML – LES DIAGRAMMES
LES DIAGRAMMES Les diagrammes sont représentés dans des cadres(frames) • kind  { activity, class, component, deployment, interaction, package, state machine, use case } • Forme simplifiée {act, class, cmp, dep, sd, pkg, stm, uc }
UML - OBJETS Objectifs  Encapsulation, abstraction, modularité, hiérarchie  Structure d’une classe  Relations entre une classe et un objet  Polymorphisme et généralisation  Les interfaces
R E T O U R SUR LES OBJETS E T LES MODELES Qu’est-ce qu’un objet ? Quatre concepts au centre de la COO Qu’est-ce qu’une classe ? Généralisation et polymorphisme Organisation des éléments modèles
Q U ’ E S T -C E Q U ’ U N O B J E T ? Un objet représente une entité physique, conceptuelle ou logicielle du monde réel.  Entité physique  Entité conceptuelle  Entité logicielle Camion Procédé chimique Liste chainée
Q U ’ E S T -C E Q U ’ U N O B J E T ? Un objet a une frontière bien définie, une identité : état et comportement.  L’état est représenté par des slots et des références  Le comportement est représenté par les opérations et les machines à états
E T A T D’UN O B J E T L’état est une condition ou situation pendant la vie d’un objet qui satisfait une condition, effectue une activité ou attend pour un événement. L’état d’un objet peut changer dans le temps. Nom: C Martin ID: 567138 Embauche:25/ 07/91 Grade: MCF Discipline: Biologie Service: 192h Nom: C Martin ID: 567138 Embauche: 25/07/1991 Grade: Maitre de conférence Discipline: Biologie Service dû : 192h Professeur Martin
C O M P O R T E M E N T D’UN O B J E T Le comportement détermine comment l’objet agit ou réagit Le comportement visible d’un objet est son interface (ensemble d’opérations). Chercher() Comportement du professeur Martin Corriger les examens Préparer un nouveau cours Chercher Faire l’emploi du temps Nom: C Martin ID: 567138 Embauche:25/ 07/91 Grade: MCF Discipline: Biologie Service: 192h
IDENTITÉ DES OBJETS L’identité d’un objet est unique même si l’état est le même que celui d’un autre objet Professeur “C Martin” enseigne la biologie Professeur “C Martin” enseigne la biologie
C O N C E P T S F O N D AM E N T A U X DE LA C O O 🢝Abstraction 🢝Encapsulation 🢝Modularité 🢝Hiérarchie (Héritage) 🢝Polymorphisme
ABSTRACTION  Caractéristiques qui differencie une entité (objet) des autres Dépend de la perspective et di contexte N’est pas une manifestation concrète, dénote l’essentiel
ENCAPSULA TION Mécanisme consistant à rassembler , au sein d’une même structure, les données et les traitements 🢝 Définition des attributs et méthodes au niveau de la classe L’implémentation de la classe est cachée pour l’utilisateur 🢝 Définition d’une interface : vue externe de l’objet Possibilité de modifier l’implémentation sans modifier l’interface 🢝 Facilité de l’évolution de l’objet Préservation de l’intégrité des données 🢝 L’accès direct aux attributs est interdit 🢝 L’interaction entre les objets se fait uniquement grâce aux méthodes
ENCAPSULA TIO N Voiture marque couleur immatriculati on démarrer conduire arrêter Affiche : La voiture est démarrée J’aimerais créer unenouvelle twingo Voiture twingo = new Voiture( ); Que se passe-t-il si je démarre ma twingo? twingo.démarrer( ); Concepteu r Utilisateur
MODULARITÉ Casser un système en sous modules Inscription administrative Système de gestion de l’université Inscription pédagogique Gestion des parcours
HIÉRARCHIE (HÉRIT AGE) Un objet spécialisé bénéficie ou hérite des caractéristiques de l’objet le plus général, auquel il rajoute ses éléments propres 🢝 Création de nouvelles classes basées sur des classes existantes 🢝 Transmission des propriétés (attributs et méthodes) de la classe mère vers la classe fille Traduit la relation « est un … » Deux orientations possibles 🢝 Spécialisation : Ajout / adaptation des caractéristiques 🢝 Généralisation : Regroupement des caractéristiques communes Possibilité d’héritage multiple Avantages 🢝 Éviter la duplication du code 🢝 Encourager la réutilisation du
HÉRIT AGE SIMPLE Moins abstrait Plus abstrait Valeur monétaire BienImmobilier CompteBancaire Portefeuille Epargne Courant Action Obligation Les éléments au même niveau hiérarchique devraient être au même niveau d’abstraction
HÉRIT AGE SIMPLE Courant Epargne Sous-classes (filles) Relation généralisation Compte - solde - nom - nombre + retirer() + créer Relevé() Un CompteEpargne est-un Compte Ancêtre Superclasse (mère)
HERIT AGE MUL TIPLE Une classe peut hériter de plusieurs Utiliser l’héritage multiple avec prudence et seulement si indispensable! Non supporté par la plupart des langages de POO (ex: MachineVolante Animal Cheval Loup Oiseau Hélicoptère Avion Héritage multiple
PROBLÈME A V E C L ’HÉRIT AGE MUL TIPLE Combien de moteurs à l’hydravion ?
DE QUOI HÉRITE-T -ON? Une sous-classe hérite les attributs, les opérations et les références de ses parents. Une sous-classe peut:  Ajouter des attributs, des opérations, des références.  Redéfinir des opérationshéritées. Les catégories communes sont montrées dans la classe mère la plus haute possible
POL YMORPHISME Définition : 🢝 Poly : plusieurs 🢝 Morphisme : Forme Faculté d’une méthode à pouvoir s’appliquer à des objets de classes différentes Capacité d’une classe à redéfinir une méthode héritée à partir d’une classe mère 🢝 Surcharge Avantages 🢝 Lisibilité du code 🢝 Généricité du code
POL YMORPHISME Véhicule seDéplacer( ) Train seDéplacer( ) Bateau seDéplacer( ) Voiture seDéplacer( ) seDéplacer(){ Print (« Sur des rails »); } seDéplacer(){ Print (« Sur la route »); } seDéplacer(){ Print (« Sur l’eau»); }
REPRESENT A TION DES OBJETS E N U M L Un objet (InstanceSpecification) est représenté par un rectangle. Le nom est souligné C Martin : Professeur : Professeur Objet nommé Objet anonyme Professeur C Martin
MODÈLES O U CLASSES Contient la description d’un objet 🢝 Modèle de l’objet effectif Correspond à l’«idée» du monde réel de l’objet 🢝 Analogie avec la philosophie platonnienne idéaliste : 🢝 « Vous vous promenez dans la campagne, vous croyez avoir rencontré des troupeaux de chevaux. Quelle erreur! (…) Car le Cheval- Modèle, le Cheval-Idée, n’est ni noir ni blanc, il n’est d’aucune race chevaline. Il est cheval pur et vos sens ne vous le montreront jamais… » [Civilisation Grecque – A.Bonnard ] 🢝 La classe  l’« idée » du cheval 🢝 Un pur sang arabe de couleur noire, dont le nom est ASWAD et qui boîte légèrement, est un objet instancié à partir de cette classe!  ça c’est un cheval
C’EST QUOI U N E CLASSE? Une classe décrit un ensemble d’objets qui partagent les mêmes attributs, opérations, références, et sémantique.  Un objet est l’instance d’une classe. Une classe est une abstraction car elle  Met en évidence certaines caractéristiques  Supprime d’autres caractéristiques
LA CLASSE C OU R S Classe Cours Attributs Nom Salle Durée Crédits Semestre Comportement Ajouter un étudiant Enlever un étudiant
CLASSES VS. OBJETS La classe est une définition abstraite  Elle définit la structure et le comportement de chaque objet issue de cette classe  Sert de modèle pour la création d’instances Professeur Professeur M Professeur T Professeur A
LES CLASSES E N U M L Une classe est représentée par un rectangle avec 3 compartiments  Le nom de la classe  La structure (les attributs)  Le comportement (opérations) Professeur - nom - ID : UniqueId - embauche - grade - discipline - service + preparerCours() + corrigerExamen() + faireEDT() + chercher()
A TTRIBUTS DES CLASSES Un attribut est une propriété structurelle nommée dont le type décrit le domaine des valeurs que l’instance peut prendre.  Une classe peut avoir un nombre quelconque d’attributs y compris 0. Attributs - nom - adresse - ID - âge
A TTRIBUTS E T V ALEURS Objets (InstanceSpecification) :Etudiant - nom = “B. Simpson” - adresse = “123 rue Gde” - ID = 9 - âge = 23 :Etudiant - nom = “R. Bidochon” - adresse = “456 av Chêne” - ID = 2 - âge = 43 slots ValueSpecification Etudiant - nom - adresse - ID - âge attributs
CLASSES E T OPÉRA TIONS Opérations Un service qui peut être invoqué par un objet pour effectuer un comportement. Une opération a une signature, qui définit les paramètres formels possibles Une classe peut avoir un nombre quelconque d’opérations Etudiant + getParcours() + ajouteUE() + getEDT() + enleveUE() + getCredit()

Contenu connexe

PPTX
Chp1 - Introduction aux méthodologies de Conception
parLilia Sfaxi
 
PPTX
10-Cours de Géniel Logiciel
parlauraty3204
 
PPT
Programmation Orientée Objet comportement et attributs
parMonssifNajim1
 
PDF
CoursUML-2025-9-22. ibn tofail kenitra maroc
parkhaoulabr33
 
PDF
UML Part1-Introduction Mansouri
parMansouri Khalifa
 
PDF
COURS UML INFORMATQIUE TELECOM2 2007.pdf
parssuserbd075f
 
PDF
Support de cours Conception orientée objets - partie 1.pdf
parYasushiTsubakik
 
PDF
Uml 2
parAzaykou Karim
 
Chp1 - Introduction aux méthodologies de Conception
parLilia Sfaxi
 
10-Cours de Géniel Logiciel
parlauraty3204
 
Programmation Orientée Objet comportement et attributs
parMonssifNajim1
 
CoursUML-2025-9-22. ibn tofail kenitra maroc
parkhaoulabr33
 
UML Part1-Introduction Mansouri
parMansouri Khalifa
 
COURS UML INFORMATQIUE TELECOM2 2007.pdf
parssuserbd075f
 
Support de cours Conception orientée objets - partie 1.pdf
parYasushiTsubakik
 
Uml 2
parAzaykou Karim
 

Similaire à Cours_Magistral_Seance_1.pptx pour la conception orienté objet

PDF
Rattrapage uml
parvangogue
 
PDF
Modélisation Orienté objet & UML(unified Modeling langage)
parSkouDoucour
 
PDF
CoursUML-SlimMesfar-Total
parAhmed Mekkaoui
 
PDF
UML 2.2 : Introduction Complète à la Modélisation Orientée Objet et aux Diagr...
parYoussouf EL ALLIOUI
 
PDF
Uml upxp2
parJoubi Aaziz
 
PDF
modulisation UML Chapitre 1 ENSA khouribgua.pdf
parssuser3f9a41
 
PDF
Modélisation objet UML 2-LINCE-CDRI-BADJOUN.pdf
parValdezTakam
 
PPT
Poo
parDimitri LEMBOKOLO
 
PPSX
introduction à la modélisation objet
parAmir Souissi
 
PPTX
Object Oriented Programming course ,Python
parMeryemOnzy
 
PDF
uml
parZineb Bachiri
 
PDF
Lecon 1.1
parrebaoui ammar
 
PPTX
Présentation cours UML.pptx
parPrinceLankoand
 
PDF
Analyse et conception orienté objet (uml).pdf
parmesprofs221
 
PDF
Unified Modeling Language (Diagram Sequence/ Use Case / Class)
parMeryemOnzy
 
PPTX
Unified Modeling Langage Course : Different diagrams and Exemples
parMeryemOnzy
 
PPT
Cours_sur_les_concepts_de_base_de_la_programmation_orientée_objet.ppt
parRomaricMarc
 
PPT
Cour UML: Introduction historique et différentes vues
parmaria879693
 
PPT
Cour d'initiation au langage de modélisation UML
parmaria879693
 
PPT
Uml
parVINOT Bernard
 
Rattrapage uml
parvangogue
 
Modélisation Orienté objet & UML(unified Modeling langage)
parSkouDoucour
 
CoursUML-SlimMesfar-Total
parAhmed Mekkaoui
 
UML 2.2 : Introduction Complète à la Modélisation Orientée Objet et aux Diagr...
parYoussouf EL ALLIOUI
 
Uml upxp2
parJoubi Aaziz
 
modulisation UML Chapitre 1 ENSA khouribgua.pdf
parssuser3f9a41
 
Modélisation objet UML 2-LINCE-CDRI-BADJOUN.pdf
parValdezTakam
 
Poo
parDimitri LEMBOKOLO
 
introduction à la modélisation objet
parAmir Souissi
 
Object Oriented Programming course ,Python
parMeryemOnzy
 
uml
parZineb Bachiri
 
Lecon 1.1
parrebaoui ammar
 
Présentation cours UML.pptx
parPrinceLankoand
 
Analyse et conception orienté objet (uml).pdf
parmesprofs221
 
Unified Modeling Language (Diagram Sequence/ Use Case / Class)
parMeryemOnzy
 
Unified Modeling Langage Course : Different diagrams and Exemples
parMeryemOnzy
 
Cours_sur_les_concepts_de_base_de_la_programmation_orientée_objet.ppt
parRomaricMarc
 
Cour UML: Introduction historique et différentes vues
parmaria879693
 
Cour d'initiation au langage de modélisation UML
parmaria879693
 
Uml
parVINOT Bernard
 

Dernier

PDF
Transhumanisme (C1) : dossier complet pour débattre et argumenter
parCarolinagarciamora
 
PDF
B1 FLE – Exprimer ses sentiments : lexique + structures
parlebaobabbleu
 
PDF
POO exception java orientée objet throw throws try catch
paraloulounarjes
 
PDF
Présentation de lancement SAE203 - MMI1 S2
parJeanLucHusson
 
PPTX
présentation du module n°4 - niveau 4ème.pptx
parDorsafSaadi
 
PDF
Oral DNB. Stratégie de la problématique.pdf
pardocs ducdi
 
PPTX
Consolidation-1.2_SVT-2AC_P2-fiche_2 (1).pptx
parmustaphaouederrousvt
 
PPTX
MICROSOFT WORD 2016 MICROSOFT WORD 2016 MICROSOFT WORD 2016 MICROSOFT WORD 20...
parhamidabdellah
 
PPTX
présentation Module n°4 - 4ème année.pptx
parDorsafSaadi
 
PPTX
Présentation du module n°5 - 4ème année.pptx
parDorsafSaadi
 
PPTX
Principales ressources cartographiques et statistiques Centre GéoStat (GGR-46...
parCentre GéoStat, Bibliothèque, Université Laval
 
PDF
Pro Training support presentation webinaire version VP.pdf
parTHL1960
 
PDF
La roue des émotions (B1) : exprimer ses sentiments en français
parlebaobabbleu
 
PPTX
présentation du module 6.pptx - 4ème année primaire
parDorsafSaadi
 
PDF
La Chandeleur en secondaire fiche d'exercises.pdf
parelisa172030
 
PDF
B2/ C1- FLE - RACONTER UN CONTE AU PASSÉ.pdf
parlebaobabbleu
 
Transhumanisme (C1) : dossier complet pour débattre et argumenter
parCarolinagarciamora
 
B1 FLE – Exprimer ses sentiments : lexique + structures
parlebaobabbleu
 
POO exception java orientée objet throw throws try catch
paraloulounarjes
 
Présentation de lancement SAE203 - MMI1 S2
parJeanLucHusson
 
présentation du module n°4 - niveau 4ème.pptx
parDorsafSaadi
 
Oral DNB. Stratégie de la problématique.pdf
pardocs ducdi
 
Consolidation-1.2_SVT-2AC_P2-fiche_2 (1).pptx
parmustaphaouederrousvt
 
MICROSOFT WORD 2016 MICROSOFT WORD 2016 MICROSOFT WORD 2016 MICROSOFT WORD 20...
parhamidabdellah
 
présentation Module n°4 - 4ème année.pptx
parDorsafSaadi
 
Présentation du module n°5 - 4ème année.pptx
parDorsafSaadi
 
Principales ressources cartographiques et statistiques Centre GéoStat (GGR-46...
parCentre GéoStat, Bibliothèque, Université Laval
 
Pro Training support presentation webinaire version VP.pdf
parTHL1960
 
La roue des émotions (B1) : exprimer ses sentiments en français
parlebaobabbleu
 
présentation du module 6.pptx - 4ème année primaire
parDorsafSaadi
 
La Chandeleur en secondaire fiche d'exercises.pdf
parelisa172030
 
B2/ C1- FLE - RACONTER UN CONTE AU PASSÉ.pdf
parlebaobabbleu
 

Cours_Magistral_Seance_1.pptx pour la conception orienté objet

  • 1.
  • 2.
    ORGANISA TION D U C OU R S 1.Volume Horaire et ED T http://unice.fr/faculte-des- sciences/departements/informatique/contenus-riches/documents - telechargeables/documentsl3i/calendrier-des-cours-tp-et-td-de- projet- informatique-et-de-coo 2. Evaluation 1. Examen théorique : 1h30 : 50% 2. Travaux Pratiques (en TD) : 50%
  • 3.
    PLAN D U C O U R S Introductionaux méthodologies de conception Introduction à UML Objets et Classes Les diagrammes  Les cas d’utilisation  Les classes et leurs instances  Les machines à états (et transitions)  Les activités  Les interactions  Le mécanisme de profilage
  • 4.
    OBJECTIFS Montrer les forcesde la COO Décrire l’histoire de la POO Commenter l’utilisation actuelle de la POO
  • 5.
    CYCLE DE VIED’UN LOGICIEL Expression des besoins Spécification Analyse des besoins Conception Implémentation T ests et vérification Validation
  • 6.
    C Y C L E DE VIED’UN LOGICIEL Expression des besoins Définition d’un cahier des charges Spécification Ce que le système doit être et comment il peut être utilisé Analyse Éléments intervenant dans le SI, leurs structures et relations A définir sur 3 axes  axe fonctionnel  axe statique  axe dynamique Savoir-faire de l’objet Structure de l’objet Cycle de vie de l’objet Conception Apport de solutions techniques: architecture, performance et optimisation Définition des structures et des algorithmes
  • 7.
    C Y C L E DE VIED’UN LOGICIEL Implémentation Réalisation et programmation T ests et Vérification Contrôles de qualité Vérification de la correspondance avec le cahier des charges Maintenance et Evolution Maintenance corrective : traiter les erreurs (bugs) Maintenance évolutive : intégration de nouveaux changements
  • 8.
    CONCEPTION  Processus créatifqui consiste à représenter les diverses fonctions du système permettant d’obtenir rapidement un ou plusieurs programmes réalisant ses fonctions.  Une « bonne » conception se définit en termes de la satisfaction des besoins et des spécifications.  Une bonne Conception participe largement à la production d'un logiciel qui répond aux facteurs de qualité. Elle se base sur la Modularité.
  • 9.
    CONCEPTION – CRITÈRESDE QUALITÉ  Cohésion : Se définit comme étant le caractère de ce qui forme un tout, dont les parties sont difficilement séparables.  Couplage : Relatif à la cohésion. Il exprime le degré d’interconnexion des differents composants d’un système. Compréhensibilité : La compréhensibilité d’un module dépend de : - Sa cohésion - L’appelation : Utilisation de noms significatifs - La documentation : Lien entre le monde réel et le composant - La complexité  Adaptabilité : Dépend du couplage et de la documentation. Un logiciel adaptable doit avoir un haut degré de lisibilité.
  • 10.
    MÉ THODE S DE CONCEPTION Ondistingue principalement de trois de méthodes de conception: Méthodes fonctionnelles Méthodes systémiques Méthodes orientées objets
  • 11.
    MÉ THODE S FONCTIONNELLES Les méthodesfinctionnelles ou cartésiennes consistent à décomposer hiérarchiquement une application en un ensemble de sous applications. Ces méthodes utilisent les raffinements successifs pour produire des spécifications don’t l’essentiel est sous forme de notation graphique en diagramme de flots de données.
  • 12.
    MÉ THODE S FONCTIONNELLES Points forts Simplicitédu processus de conception Capacité à répondre rapidement aux besoins ponctuels des utilisateurs Points faibles: Fixer les limites pour les décompositions hiérarchiques Rédondance (éventuelle) des données
  • 13.
    MÉ THODE S SYSTÉMIQUES Les méthodessystéliques sont influencés par les systèmes de Gestion de bases de données en proposant une double démarche de modélisation: La modélisation des données La modélisation des traitements Points forts : Approche globale prenant en compte la modélisation des données et des traitements Niveaux d’abstraction dans le processus de conception Bonne adaptation à la modélisation des données et à la conceptiond es BDs Points faibles Double démarche de conception : données et traitements Pas de fusion possible des deux aspects (données et traitements)
  • 14.
    MÉ THODE S FONCTIONNELLES E T SYSTÉMIQUES Lesméthodes foncionnelles et systémiques sont de type descendant (approache Top- Down). Inconvénients Réutilisabilité : Modules non généraux mais adaptés aux sous problèmes pour lesquels ils ont été concus Extensibilité: L’architecture du logiciel est fondée sur les traitements qui sont moins stables que les données; par conséquent cette approche est inadaptée à la conception de gros logiciel.
  • 15.
    MÉ THODE S ORIENTÉES OBJETS Dans une approche Orientée Objet (OO), le logiciel est considéré comme une collection d’objets dissociés définis par des propriétés. Une propriété est soit un attribut de l’objet ou une opération sur l’objet.  Un objet comprend donc à la fois une structure de données et une collection d’opérations (son comportement).  Contrairement aux méthodes fonctionnelles et systémiques, les méthodes orientées objets sont ascendantes.
  • 16.
    MÉ THODE S ORIENTÉES OBJETS Latechnologie Orientée Objet Guide la conception par Un ensemble de concepts Abstraction, modularité, Encapsulation, Polymorphisme Des langages et outils qui supportent ces concepts Classification vs. prototype Héritage (Simple, Multiple) Typage (Fort, Faible) Avantages Reflète plus finement les objets du monde réel Du code : facile à maintenir Plus stable: Isolation des changements Réutilisation des composantes Faciliter le prototypage
  • 17.
    MÉ THODE S ORIENTÉES OBJETS– EXEMPLES Objets  Personnes  Etudiant, enseignant, principal, secrétaire  Diplôme  Année, matière, parcours  Notes  Coefficients Système de gestion d’un lycée Fonctions  Calculer la moyenne  Calculer les taux d’encadrement  Calculer le nombrede redoublants  Calculer le taux de réussite au baccalauréat
  • 18.
    OBJECTIFS DES TECHNOLOGIESÀ OBJETS Utiliser le langage du domaine  Modèle et vocabulaire métier Construire des modèles faciles à:  Etendre, modifier, valider, vérifier Faciliter l’implantation  Génération facilitée vers les langages à objets Nécessite une méthode et des outils  Rational Unified Process, Agile, … (cf. semestre 2)  UML est seulement un langage
  • 19.
    LES OBJETS… Définitions : 🢝Entité cohérente rassemblant des données et du code travaillant sur ces données 🢝 Structure de données valuées qui répond à un ensemble de messages Caractérisé par : 🢝 son comportement : que peut-on faire avec cet objet? 🢝 Méthodes 🢝 son état : comment réagit l’objet quand on applique ces méthodes? 🢝 Attributs (Champs) 🢝 son identité : comment distinguer les objets qui ont le même état et le m ê m e comportement? 🢝 Identifiant A les mêmes réactions et la même modularité que le monde réel 🢝 L’objet informatique est une projection de l’objet du monde réel
  • 20.
  • 21.
    POURQUOI U N MODÈLE? Quatreobjectifs à la modélisation  Aider à visualiser le système  Spécifier la structure et le comportement  Servir de plan pour la construction effective  Permettre de documenter les choix Quatre avantages  Abstraction : diviser pour régner  Compréhension : mises au point avec le client  L’énergie déployée pour modéliser révèle les difficultés  Les erreurs sur les modèles coûtent bien moins cher
  • 22.
    IMPOR T ANCE DES MODÈLES Avionpapier Avion militaire moins important Plus important Le développement logiciel AUSSI nécessite des modèles bien pensés !
  • 23.
    OBJETS – CLASSESS(EXEMPLES) Classe Figure longueu r largeur origine périmètre surface transpo ser Obje t rectangle: Figure longueur: 24 largeur: 20 Origine : (12, 20) Figure rectangle= new Figure( ); rectangle.surface();
  • 24.
    MODEL DRIVEN ARC HI T EC T URE(MDA)  Développement orienté modèles  Spécifier un modèle indépendant de la plateforme sur laquelle il sera déployé  Spécifier la ou les plateformes  Choisir une plateforme adaptée  Transformer le modèle de spécification en un modèle spécifique pour la plateforme
  • 25.
    LES 4 PRINCIPESP O U R C R É E R U N MODÈLE Un modèle influence énormément la façon d’aborder le problème et la solution  Vue du concepteur BD # vue du programmeur OO Chaque modèle peut être exprimer à différents niveaux de précision  Les meilleurs modèles permettent de choisir le niveau de détail en fonction de qui regarde et pourquoi il le regarde Les meilleurs modèles sont liés à la réalité Un seul modèle n’est jamais suffisant  Tous les systèmes gagnent à être décrits avec plusieurs petits modèles relativement indépendant => comment assurer la cohérence entre les modèles
  • 26.
    U N SEUL MODÈLEN E SUFFIT PAS! Créer un ou plusieurs modèles différents mais avec un point commun Vue logique Analystes/Concepteurs Structure Use-Cas Vue d’implantation Programmeurs Software management e View Utilisate Fonctio Vue procédé Intégrateur système Performance, scalabilité, débit ur final nalité Vue Déploiement Ingénieur système Topologie du système, livraison, installation, communication
  • 27.
    UNIFIED MODELING L A N G U A G E(UML) Langage visuel unifié  Tout le monde doit parler le même langage Langage pour spécifier  Executable-UML  Supposé précis et non ambigu Des liens vers +s langages de prog.  Java, C++, VB  RDMS ou OODMS  Génération de code et reverse engineering.
  • 28.
    UML - HIST ORIQUE Années80: 🢝 Méthodes pour organiser la programmation fonctionnelle (Merise) 🢝 Séparation des données et des traitements Début des années 90: 🢝 Apparition de la programmation objet: nécessite d’une méthodologie adaptée 🢝 Apparition de plus de 50 méthodes entre 1990 et 1995 1994 🢝 Consensus sur 3 méthodes 🢝 OMT de James Rumbaugh : représentation graphique des aspects statiques, dynamiques et fonctionnels d’un système 🢝 OOD de Grady Booch: concept de package 🢝 OOSE de Ivar Jacobson: description des besoins de l’utilisateur
  • 29.
    U M L Consensus entre OMT,OOD, OOSE pour créer une méthode commune: 🢝 UML : Unified Modeling Language (Langage de Modélisation Unifié) 1997: Définition de la norme UML comme standard de modélisation des systèmes d’information objet par l’OMG (Object Management Group) UML est employé dans l’ensemble des secteurs du développement informatique 🢝 Systèmes d’information 🢝 Télécommunication, défense 🢝 Transport, aéronautique, aérospatial 🢝 Domaines scientifiques Mais pas seulement : on peut modéliser des comportement mécaniques, humain, etc.
  • 30.
    UML E T R U P Unlangage n’est pas suffisant, il faut aussi une méthode Les méthodes (process) qui fonctionnent le mieux avec UML sont :  Orienté par les Use-case ;  Centré sur l’architecture ;  Itératif et incrémental. • Les utilisateurs réagissent au fur et à mesure. Rational Unified Process
  • 31.
    MODELE ORIENTÉ “USECASE” Les use-case sont la base  Ils doivent être précis et concis  Ils sont compréhensibles par la majorité  Ils permettent de synchroniser les différents modèles  Ils décrivent l’ensemble des fonctions du système et les acteurs concernés Retirer de l’argent Client Vérifier le solde
  • 32.
    LES BASES D’UML Leséléments 🢝 Ce sont les abstractions essentielles au modèle. Les relations 🢝 Les relations expriment les liens existants entre les différents éléments. Les diagrammes 🢝 Un diagramme est une représentation visuelle de l’ensemble des éléments qui constituent le système 🢝 Ils servent à visualiser un système sous différents angles (utilisateur , administrateur par ex.) 🢝 Dans les systèmes complexes, un diagramme ne fournit qu’une vue partielle du système 🢝 L’ensemble des diagrammes réunis permet d’obtenir une vue globale du système à concevoir 🢝 Chaque diagramme va permettre de modéliser ou spécifier une vue (spécificité) du système à concevoir
  • 33.
    UML - LESVUES Vue des cas d’utilisation 🢝 Description du modèle vu par les acteurs du système 🢝 Besoins attendus pour chaque acteur 🢝 Le QUOI et le QUI Vue logique 🢝 Définition du système vu de l’intérieur 🢝 COMMENT satisfaire les besoins des acteurs Vue d’implémentation 🢝 Dépendances entre les modules Vue des processus 🢝 Vue temporelle et technique 🢝 Mise en œuvre des notions de tâches concurrentes, synchronisation… Vue de déploiement 🢝 Position géographique et architecture physique de chaque élément
  • 34.
    UML – LESDIAGRAMMES
  • 35.
    LES DIAGRAMMES Les diagrammessont représentés dans des cadres(frames) • kind  { activity, class, component, deployment, interaction, package, state machine, use case } • Forme simplifiée {act, class, cmp, dep, sd, pkg, stm, uc }
  • 36.
    UML - OBJETS Objectifs Encapsulation, abstraction, modularité, hiérarchie  Structure d’une classe  Relations entre une classe et un objet  Polymorphisme et généralisation  Les interfaces
  • 37.
    R E T O U R SUR LESOBJETS E T LES MODELES Qu’est-ce qu’un objet ? Quatre concepts au centre de la COO Qu’est-ce qu’une classe ? Généralisation et polymorphisme Organisation des éléments modèles
  • 38.
    Q U ’ E S T -C E Q U ’ U N O B J E T? Un objet représente une entité physique, conceptuelle ou logicielle du monde réel.  Entité physique  Entité conceptuelle  Entité logicielle Camion Procédé chimique Liste chainée
  • 39.
    Q U ’ E S T -C E Q U ’ U N O B J E T? Un objet a une frontière bien définie, une identité : état et comportement.  L’état est représenté par des slots et des références  Le comportement est représenté par les opérations et les machines à états
  • 40.
    E T A T D’UN O B J E T L’étatest une condition ou situation pendant la vie d’un objet qui satisfait une condition, effectue une activité ou attend pour un événement. L’état d’un objet peut changer dans le temps. Nom: C Martin ID: 567138 Embauche:25/ 07/91 Grade: MCF Discipline: Biologie Service: 192h Nom: C Martin ID: 567138 Embauche: 25/07/1991 Grade: Maitre de conférence Discipline: Biologie Service dû : 192h Professeur Martin
  • 41.
    C O M P O R T E M E N T D’UN O B J E T Lecomportement détermine comment l’objet agit ou réagit Le comportement visible d’un objet est son interface (ensemble d’opérations). Chercher() Comportement du professeur Martin Corriger les examens Préparer un nouveau cours Chercher Faire l’emploi du temps Nom: C Martin ID: 567138 Embauche:25/ 07/91 Grade: MCF Discipline: Biologie Service: 192h
  • 42.
    IDENTITÉ DES OBJETS L’identitéd’un objet est unique même si l’état est le même que celui d’un autre objet Professeur “C Martin” enseigne la biologie Professeur “C Martin” enseigne la biologie
  • 43.
    C O N C E P T S F O N D AM E N T A U X DELA C O O 🢝Abstraction 🢝Encapsulation 🢝Modularité 🢝Hiérarchie (Héritage) 🢝Polymorphisme
  • 44.
    ABSTRACTION  Caractéristiques quidifferencie une entité (objet) des autres Dépend de la perspective et di contexte N’est pas une manifestation concrète, dénote l’essentiel
  • 45.
    ENCAPSULA TION Mécanisme consistant àrassembler , au sein d’une même structure, les données et les traitements 🢝 Définition des attributs et méthodes au niveau de la classe L’implémentation de la classe est cachée pour l’utilisateur 🢝 Définition d’une interface : vue externe de l’objet Possibilité de modifier l’implémentation sans modifier l’interface 🢝 Facilité de l’évolution de l’objet Préservation de l’intégrité des données 🢝 L’accès direct aux attributs est interdit 🢝 L’interaction entre les objets se fait uniquement grâce aux méthodes
  • 46.
    ENCAPSULA TIO N Voiture marque couleur immatriculati on démarrer conduire arrêter Affiche : La voiture est démarrée J’aimeraiscréer unenouvelle twingo Voiture twingo = new Voiture( ); Que se passe-t-il si je démarre ma twingo? twingo.démarrer( ); Concepteu r Utilisateur
  • 47.
    MODULARITÉ Casser un systèmeen sous modules Inscription administrative Système de gestion de l’université Inscription pédagogique Gestion des parcours
  • 48.
    HIÉRARCHIE (HÉRIT AGE) Un objetspécialisé bénéficie ou hérite des caractéristiques de l’objet le plus général, auquel il rajoute ses éléments propres 🢝 Création de nouvelles classes basées sur des classes existantes 🢝 Transmission des propriétés (attributs et méthodes) de la classe mère vers la classe fille Traduit la relation « est un … » Deux orientations possibles 🢝 Spécialisation : Ajout / adaptation des caractéristiques 🢝 Généralisation : Regroupement des caractéristiques communes Possibilité d’héritage multiple Avantages 🢝 Éviter la duplication du code 🢝 Encourager la réutilisation du
  • 49.
    HÉRIT AGE SIMPLE Moins abstrait Plus abstrait Valeur monétaire BienImmobilier CompteBancairePortefeuille Epargne Courant Action Obligation Les éléments au même niveau hiérarchique devraient être au même niveau d’abstraction
  • 50.
    HÉRIT AGE SIMPLE Courant Epargne Sous-classes (filles) Relation généralisation Compte - solde -nom - nombre + retirer() + créer Relevé() Un CompteEpargne est-un Compte Ancêtre Superclasse (mère)
  • 51.
    HERIT AGE MUL TIPLE Une classepeut hériter de plusieurs Utiliser l’héritage multiple avec prudence et seulement si indispensable! Non supporté par la plupart des langages de POO (ex: MachineVolante Animal Cheval Loup Oiseau Hélicoptère Avion Héritage multiple
  • 52.
  • 53.
    DE QUOI HÉRITE-T -ON? Unesous-classe hérite les attributs, les opérations et les références de ses parents. Une sous-classe peut:  Ajouter des attributs, des opérations, des références.  Redéfinir des opérationshéritées. Les catégories communes sont montrées dans la classe mère la plus haute possible
  • 54.
    POL YMORPHISME Définition : 🢝 Poly: plusieurs 🢝 Morphisme : Forme Faculté d’une méthode à pouvoir s’appliquer à des objets de classes différentes Capacité d’une classe à redéfinir une méthode héritée à partir d’une classe mère 🢝 Surcharge Avantages 🢝 Lisibilité du code 🢝 Généricité du code
  • 55.
    POL YMORPHISME Véhicule seDéplacer( ) Train seDéplacer( ) Bateau seDéplacer() Voiture seDéplacer( ) seDéplacer(){ Print (« Sur des rails »); } seDéplacer(){ Print (« Sur la route »); } seDéplacer(){ Print (« Sur l’eau»); }
  • 56.
    REPRESENT A TION DES OBJETSE N U M L Un objet (InstanceSpecification) est représenté par un rectangle. Le nom est souligné C Martin : Professeur : Professeur Objet nommé Objet anonyme Professeur C Martin
  • 57.
    MODÈLES O U CLASSES Contientla description d’un objet 🢝 Modèle de l’objet effectif Correspond à l’«idée» du monde réel de l’objet 🢝 Analogie avec la philosophie platonnienne idéaliste : 🢝 « Vous vous promenez dans la campagne, vous croyez avoir rencontré des troupeaux de chevaux. Quelle erreur! (…) Car le Cheval- Modèle, le Cheval-Idée, n’est ni noir ni blanc, il n’est d’aucune race chevaline. Il est cheval pur et vos sens ne vous le montreront jamais… » [Civilisation Grecque – A.Bonnard ] 🢝 La classe  l’« idée » du cheval 🢝 Un pur sang arabe de couleur noire, dont le nom est ASWAD et qui boîte légèrement, est un objet instancié à partir de cette classe!  ça c’est un cheval
  • 58.
    C’EST QUOI U N ECLASSE? Une classe décrit un ensemble d’objets qui partagent les mêmes attributs, opérations, références, et sémantique.  Un objet est l’instance d’une classe. Une classe est une abstraction car elle  Met en évidence certaines caractéristiques  Supprime d’autres caractéristiques
  • 59.
  • 60.
    CLASSES VS. OBJETS Laclasse est une définition abstraite  Elle définit la structure et le comportement de chaque objet issue de cette classe  Sert de modèle pour la création d’instances Professeur Professeur M Professeur T Professeur A
  • 61.
    LES CLASSES E NU M L Une classe est représentée par un rectangle avec 3 compartiments  Le nom de la classe  La structure (les attributs)  Le comportement (opérations) Professeur - nom - ID : UniqueId - embauche - grade - discipline - service + preparerCours() + corrigerExamen() + faireEDT() + chercher()
  • 62.
    A TTRIBUTS DES CLASSES Unattribut est une propriété structurelle nommée dont le type décrit le domaine des valeurs que l’instance peut prendre.  Une classe peut avoir un nombre quelconque d’attributs y compris 0. Attributs - nom - adresse - ID - âge
  • 63.
    A TTRIBUTS E T V ALEURS Objets (InstanceSpecification) :Etudiant -nom = “B. Simpson” - adresse = “123 rue Gde” - ID = 9 - âge = 23 :Etudiant - nom = “R. Bidochon” - adresse = “456 av Chêne” - ID = 2 - âge = 43 slots ValueSpecification Etudiant - nom - adresse - ID - âge attributs
  • 64.
    CLASSES E T OPÉRA TIONS Opérations Unservice qui peut être invoqué par un objet pour effectuer un comportement. Une opération a une signature, qui définit les paramètres formels possibles Une classe peut avoir un nombre quelconque d’opérations Etudiant + getParcours() + ajouteUE() + getEDT() + enleveUE() + getCredit()