coo - introduction

Thèmes Motivation Objet

COO - Introduction

Guillaume Huard

Université Grenoble Alpes

M1 INFO COO 1 / 42


COO

Nom : Conception Orientée ObjetIntervenants :

[email protected] (responsable)[email protected]

Déroulement : 1 cours et 1 TD/TP par semaineEvaluation :

Examen terminal, 70%, règle de maxNotes de TP -> note de CC, 30%

1 TP joint GL / COO (en groupes de 5)1 interro écrite après la moitié du semestre

M1 INFO COO 2 / 42


Plan

Thèmes

Motivation

Objet

M1 INFO COO 3 / 42


Thèmes

Programmation orientée objetmotivation de l’approcheobjets et classeshéritage, polymorphisme et liaisondynamiqueprincipes de modélisation

Bertrand Meyer :Object-Oriented Software Construction, Prentice Hall.

Dispo aussi en français :Conception et programmation orientées objet, Eyrolles.

M1 INFO COO 4 / 42


Thèmes

Modélisation avec l’UMLmodélisation statiquemodélisation dynamiquestructure du logiciel

Martin Fowler :UML Distilled, 3rd ed.

Dispo aussi en français : UML 2.0.

M1 INFO COO 5 / 42


Thèmes

Patrons de conceptioncréationstructurecomportement

Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides :Design Patterns : Elements of Reusable Object-Oriented Software.

Dispo aussi en français : Design patterns. Catalogue des modèles deconception réutilisables.

M1 INFO COO 6 / 42


Autre références

Robert C. Martin :Clean Architecture : A Craftsman’s Guide toSoftware Structure and Design

James Rumbaugh, Ivar Jacobson & GradyBooch :The Unified Modeling Language ReferenceManual, 2nd ed.

Dispo aussi en français :UML 2.0.

M1 INFO COO 7 / 42


Positionnement de l’UE

Complémentaire avec le cours de génie logicielPoints d’accroche : qualité du logiciel, démarche de conceptionAspects concrets vus en COO : modélisation, programmationmini projet commun (en TD/TP)

Mise en œuvre en javaUn des langage les plus demandésEn accord avec les compétences de l’équipe GL/COOSuffisant pour couvrir les besoins importants en COO

M1 INFO COO 8 / 42


Plan

Thèmes

Motivation

Objet

M1 INFO COO 9 / 42


Les qualités d’un logicielFiabilité :

Correction : respect de la spécificationRobustesse : comportement en cas d’utilisation anormale

Modularité :Extensibilité : adaptation aux changements de spécificationRéutilisabilité : partie utilisables dans d’autres contextes

Autre :Compatibilité : facilité à le combiner à d’autres logicielsEfficacité : ne charge pas trop les ressources matériellesPortabilité : transfert aisé vers d’autres systèmes/matérielsFacilité d’utilisation : installation, exploitation, retoursFonctionnalités : possibilités offertesProduit dans les temps : ou avant

M1 INFO COO 10 / 42


Pourquoi est-ce si important ?Le coût d’un logiciel est dominé par les coûts de maintenance

67% entre 1976 et 198175% entre 1992 et 1998

[ S.R. Sachs, Object-Oriented Software Engineering ]

§1.3 ABOUT SOFTWARE MAINTENANCE 17

1.3 ABOUT SOFTWARE MAINTENANCE

The list of factors did not include a frequently quoted quality: maintainability. Tounderstand why, we must take a closer look at the underlying notion, maintenance.

Maintenance is what happens after a software product has been delivered.Discussions of software methodology tend to focus on the development phase; so dointroductory programming courses. But it is widely estimated that 70% of the cost ofsoftware is devoted to maintenance. No study of software quality can be satisfactory if itneglects this aspect.

What does “maintenance” mean for software? A minute’s reflection shows this termto be a misnomer: a software product does not wear out from repeated usage, and thus neednot be “maintained” the way a car or a TV set does. In fact, the word is used by softwarepeople to describe some noble and some not so noble activities. The noble part ismodification: as the specifications of computer systems change, reflecting changes in theexternal world, so must the systems themselves. The less noble part is late debugging:removing errors that should never have been there in the first place.

The above chart, drawn from a milestone study by Lientz and Swanson, sheds somelight on what the catch-all term of maintenance really covers. The study surveyed 487installations developing software of all kinds; although it is a bit old, more recentpublications confirm the same general results. It shows the percentage of maintenancecosts going into each of a number of maintenance activities identified by the authors.

More than two-fifths of the cost is devoted to user-requested extensions andmodifications. This is what was called above the noble part of maintenance, which is alsothe inevitable part. The unanswered question is how much of the overall effort the industrycould spare if it built its software from the start with more concern for extendibility. We maylegitimately expect object technology to help.

Breakdown of maintenance costs. Source: [Lientz 1980]

12.4%9%6.2%5.5%

4%3.4%

EmergencyFixesRoutine

Fixes

Hardwarechanges

Documen-tation

Efficiency

improvements

Other

41.8%

Changes in User Requirements

17.6% Changesin DataFormats

Essentiellement des changementsde spécification

M1 INFO COO 11 / 42


Fiabilité

LimitesCorrection indécidable dans le cas généralDefinition de la robustesse subjective et contextuelle

ObjectifsSpecification d’un comportement correct

découpage en parties plus simples à spécifier (modules)conception par contrats

Tests de correctiondeveloppement dirigé par les tests (couverture)tests unitaires (à l’échelle du module)

Gestion des situations anormalesmécanisme d’exceptionsrécupération au niveau du module concerné

M1 INFO COO 12 / 42


ModularitéModulaire = fait de composants logiciels autonomes

impact direct sur l’extensibilité et la réutilisabilitéaméliore indirectement la fiabilité et les autres qualités

Critères d’une architecture modulaire1 Décomposabilité : logiciel découpé en sous problèmes peu

dépendants les uns des autres2 Composabilité : modules facilement combinables entre eux

pour produire une architecture différente3 Compréhension : modules facile à comprendre

indépendemment les uns des autres4 Continuité : un petit changement dans le problème implique

un changement de peu de modules5 Protection : les anomalies à l’exécution sont confinées dans

un module (ou peu de modules)

M1 INFO COO 13 / 42


Règles

Découlent des critères précédents6 Correspondance directe : décomposition en modules du

logiciel compatible avec celle du domaine du problème (1, 4)7 Peu d’interfaces : communication avec aussi peu de modules

que possible (4, 5)8 Petites interfaces : échange d’aussi peu d’information que

possible entre modules (4, 5)9 Interfaces explicites : communication entre modules explicite

dans leur code source (1, 2, 3, 4)10 Dissimulation d’information : partie visible du module aussi

petite que possible (4)

M1 INFO COO 14 / 42


Principes

Conséquences des règles et critères de bonne modularité11 Unités modulaire linguistiques : les modules doivent

correspondre à une construction du langage (1, 2, 4, 5, 6)12 Auto-Documentation : la documentation concernant un

module doit faire partie du module lui-même (3, 4)13 Accès uniforme : l’utilisation d’un module doit utiliser une

notation uniforme indépendante de l’implémentation (5, 10)14 Principe d’ouverture/fermeture : les modules doivent être

ouverts aux extensions et fermés aux modifications (2, 4, 10)15 Choix unique : le cas échéant, un seul module doit avoir

connaissance d’un ensemble d’alternatives (10, 14)

M1 INFO COO 15 / 42


Premiers apports de l’orienté objet

Notion de classe qui combineun type de donnéesune implémentation

La classe est l’élément fondamental qui permet de construiredes modules logicielsun ensemble suffisant de types utilisable dans le langage

Et nous donne les moyens de respecter les critères de modularité

M1 INFO COO 16 / 42


Concevoir un logiciel : décomposition fonctionnelleApproche dite top-down, classique en ingénierie

Procède par décomposition de la fonction principale du logicielen sous problèmes

A

B C D

E F G H I

séquence

boucle alternative

Répète la décomposition jusqu’à obtenir des sous problèmesélémentaires, faciles à attaquer

M1 INFO COO 17 / 42


Problèmes de la décomposition fonctionnelle

Difficile d’en tirer une architecture modulairele logiciel peut avoir de multiples fonctions principales,comment en choisir une ?évolutions difficiles à intégrer de manière continue, ex :comment intégrer une interaction utilisateur à un système detraitement par lots ?dans une vue fonctionnelle, avec un découpage temporel,certaines parties distinctes sont difficiles à séparer lesunes des autres, ex : interface utilisateur / cœur fonctionnelimpose un ordre arbitraire sur la décompositionconduit souvent à une décomposition spécifique, dont leséléments sont peu réutilisables

M1 INFO COO 18 / 42


Conception orientée objet

Approche bottom-up qui construit l’architecture classe par classese concentrer sur les types de données manipulésmot d’ordre : ne pas se demander ce que le système fait,mais à qui il le fait

ApportsExtensibilité : les types de donnés sont moins sujets auxchangements que les fonctions qui les manipulentRéutilisabilité : un ensemble de fonctions (associées à untype) est plus réutilisable qu’une fonction isoléeCompatibilité : plus simple à l’échelle d’une structure dedonnées qu’à l’échelle d’une fonction

M1 INFO COO 19 / 42


Difficultés de l’approche orientée objet

Questions inévitables pour mener à bien la conceptioncomment trouver les classes ?

inspirées de l’analyse du problème à résoudreréutilisation de classes existantes (bibliothèques)expérience, imitation de schémas classique (patterns)

comment écrire les classes ?rester indépendant de la représentation (abstraire)y concevoir la partie fonctionnelle

comment mettre en relation les classes ?par utilisation d’autres classes (délégation)par spécialisation d’autres classes (héritage)

M1 INFO COO 20 / 42


Plan

Thèmes

Motivation

Objet

M1 INFO COO 21 / 42


Retour sur la notion de classe

Patron permettant de créer des objets, une classe combineun type de données structuré

constitué de champs nommés attributsdont les attributs ont chacun un type existant

un ensemble d’opérations applicables à ce typeces opérations sont nommées méthodesdiverses méthodes pour construire, consulter et commander

Constitue le code source écrit par le programmeur

Une classe n’a pas d’existence en mémoire à l’exécutionelle sert de type pour créer des objets (instances de la classe)ces instances existent en mémoire

M1 INFO COO 22 / 42


Exemple de classe

En java

class Point {double x, y;

double rho() {return Math.sqrt(x*x+y*y);

}

double theta() {return Math.atan2(y, x);

}}

En UML

M1 INFO COO 23 / 42


Notion d’objet

Un objet est une instance d’une classecréé par un opérateur ou une fonction spéciale du langageoccupe un espace en mémoire

méta informations (type de l’objet)valeurs des attributstable(s) de liaison (méthodes)

Déclaré et manipulédirectement, par valeur (impossible en java)par référence (typiquement pour le partage)

M1 INFO COO 24 / 42


Exemple d’objet

En java// La classe Point est associée// à un type de référencesPoint p;

// Opérateur new : création// renvoie une référencep = new Point();

// Accès aux attributs avec .p.x = 3.14;p.y = 42.0;

En UML

M1 INFO COO 25 / 42


Méthodes

Une méthode est associée à un objetne peut être appellée qu’à partir de celui-cicet objet est un paramètre implicite de l’appel

existe toujours (sinon, par définition, l’appel est impossible)est désigné par la référence this en java

Exemple d’appel de méthodePoint p;

p = new Point();p.x = 3.14;p.y = 42.0;

System.out.println("Rho : " + p.rho());System.out.println("Théta : " + p.theta());

M1 INFO COO 26 / 42


Surcharge

Plusieurs méthodes peuvent avoir le même nom du moment queleur nombre d’arguments diffère oule type de leurs arguments diffère (au moins à un endroit)


void reset() {reset(0,0);

}

void reset(double x,double y) {

this.x = x;this.y = y;

}}

Point p = new Point();

p.reset(3.14, 42.0);System.out.println(

"Rho : " + p.rho() + "\n"+ "Théta : " + p.theta());

p.reset();System.out.println(


M1 INFO COO 27 / 42


Constructeur

La construction, pour créer un objet cohérent, peut avoir besoind’exécuter une méthoded’être paramétrée

En java, cette tâche est remplie par un constructeurméthode sans type de retour, de même nom que la classepeut être surchargéappelé implicitement par le new ou explicitement par thiscontructeur vide implicite si la classe n’en n’a aucun

M1 INFO COO 28 / 42


Exemple de constucteurs


Point() {// Appel de l'autre// constructeurthis(0,0);

}

Point(double x,double y) {


}}

Point p;

p = new Point(3.14, 42.0);System.out.println(


p = new Point();System.out.println(


M1 INFO COO 29 / 42


Limite des constructeurs de java

On aimerait parfois plusieurs constructeurs de même signature


// Coordonnées cartésiennesPoint(double x, double y) {


}

// Coordonnées polairesPoint(double rho,

double theta) {x = rho*Math.cos(theta);y = rho*Math.sin(theta);

}}

Impossible en javala surcharge estdéfinie par lasignatureun constructeur aforcément le nom desa classe

M1 INFO COO 30 / 42


Critique de l’exemple choisi

Notre exemple de classe Point va à l’encontre des règles etprincipes d’une architecture modulaire

Pas d’accès uniformeaccès aux attributs via p.x et p.yaccès aux méthodes via p.rho() et p.theta()

Pas de dissimulation d’informationattributs et méthodes accessibles par le programme principal

Pas d’auto-documentationpas de documentation du tout. . .

M1 INFO COO 31 / 42


Accès uniforme, pourquoi est-ce important

Stocker les coordonnée cartésiennes n’est qu’un choixd’implémentation


double rho() {return

Math.sqrt(x*x+y*y);}

double theta() {return

Math.atan2(y, x);}

}

class Point {double rho, theta;

double x() {return

rho*Math.cos(theta);}

double y() {return

rho*Math.sin(theta);}

}

M1 INFO COO 32 / 42


Pas d’accès direct aux attributsOn masque ainsi les choix d’implémentationclass Point {

double rho, theta;

double x() {return rho*Math.cos(theta);}double y() {return rho*Math.sin(theta);}void setX(double x) {double y = y();

rho = Math.sqrt(x*x+y*y); theta = Math.atan2(y, x);}void setY(double y) {double x = x();

rho = Math.sqrt(x*x+y*y); theta = Math.atan2(y, x);}

double rho() {return rho;}double theta() {return theta;}void setRho(double r) {rho = r;}void setTheta(double t) {theta = t;}

}

M1 INFO COO 33 / 42


Implémentation masquée

Du coté du programme principal on ne passe que par des méthodesle choix des attributs est masquéle développeur est libre de changer l’implémentation

Point p;

p = new Point();p.setX(3.14);p.setY(42.0);

System.out.println("Rho : " + p.rho());System.out.println("Théta : " + p.theta());

M1 INFO COO 34 / 42


Dissimulation d’information

Java permet de déclarer comme private (visible seulement par lesobjets de la classe englobante) un attribut ou une méthode

la dissimulation d’information est expliciteles attributs devraient toujours être privés

Par défaut en java, tout est visible dans le paquetage englobant

visibilité signification UMLpublic partout +nompackage dans le paquetage englobant ~nomprotected dans la classe et ses descendantes #nomprivate dans la classe -nom

Nous reviendrons sur les paquetages et les classes descendantes

M1 INFO COO 35 / 42


Exemple d’une liste chaînéeEn suivant les règles à la lettre

class Liste {private Maillon tete

void ajouteTete(int e) {Maillon nouveau =

new Maillon();nouveau.setElement(e);nouveau.setProchain(tete);tete = nouveau;

}

int supprimeTete() {int resultat =

tete.element();tete = tete.prochain();return resultat;

}}

class Maillon {private int element;private Maillon prochain;

setElement(int e) {element = e;

}setProchain(Maillon p) {

prochain = p;}int element() {

return element;}Maillon prochain() {

return prochain;}

}

M1 INFO COO 36 / 42


La classe frontière du module ?Est-ce pertinent lorsque l’implémentation couvre plusieurs classes ?

class Liste {private Maillon tete;

void ajouteTete(int e) {Maillon nouveau =

new Maillon();nouveau.element = e;nouveau.prochain = tete;tete = nouveau;

}

int supprimeTete() {int resultat =

tete.element;tete = tete.prochain;return resultat;

}}

class Maillon {int element;Maillon prochain;

}

M1 INFO COO 37 / 42


Auto-documentation en javajavadoc générée automatiquement sous forme de page web/*** Début de commentaire spécifique à la javadoc. On* commence par une description générale de la classe.* Le texte peut être enrichi de balises html :* <ul>* <li>pour créer des listes ;</li>* <li>pour <tt>mettre en valeur</tt> du texte.</li>* </ul>** @author meta-information* @version spécifique au module*/

class Point {/** Abscisse */private double x;/** Ordonnée */private double y;

M1 INFO COO 38 / 42


Auto-documentation en java

/*** Description de la méthode, ici un recupérateur.* @return valeur de l'abscisse.*/

double x() {return x;

}

/*** Et ici un modificateur.* @param x nouvelle abscisse* @param y nouvelle ordonnée*/

void setXY(double x, double y) {this.x = x;this.y = y;

}}

M1 INFO COO 39 / 42


Resultat

M1 INFO COO 40 / 42


Conclusion

Objectif de qualité logiciellefiabilitémodularité

Conception orientée objetfavorise l’extensibilité, la réutilisabilité et la compatibiliténecessite aussi une auto-discipline

accès uniformedissimulation d’informationauto-documentation

Développement des ces idées dans les cours suivants

M1 INFO COO 41 / 42


Questions ?

M1 INFO COO 42 / 42

coo - introduction

Documents