Embed Size (px)
Citation preview
Constat• Lehman MM, Laws of Software Evolution Revisited, 1996
• Huit lois sur le développement et la vie d'un logiciel • loi du changement continuel: logiciel doit être constamment adapté,
sinon devient de moins en moins satisfaisant à l'usage • loi de la complexité croissante: un logiciel qui évolue devient de plus en
plus complexe à moins effort soit effectué pour maintenir un niveau de complexité acceptable ou le réduire
• loi de la croissance constante: un logiciel doit continuellement s'enrichir afin conserver satisfaction utilisateurs durant son exploitation
• loi de la qualité déclinante: un logiciel tend à baisser en qualité à moins soit rigoureusement maintenu pour s'adapter aux changements
Problème• Q: quels sont les changements que peut rencontrer un
logiciel dans sa vie ?
Problème• Comment un logiciel, basé sur une structure assez
statique va pouvoir affronter ces changements et adaptations constantes ? • Maintenance: correctifs techniques et fonctionnels• Évolutions fonctionnelles• Montée en charge• Changement de cible de déploiement (serveur, BDD…)• Obsolescence des technologies• …• Ré-écriture
Le paradigme Objet• Paradigme:
• « Modèle théorique de pensée qui oriente la recherche et la réflexion scientifique »
• Le trio du paradigme Objet• Encapsulation• Héritage• Polymorphisme
Le paradigme Objet• Paradigme:
• « Modèle théorique de pensée qui oriente la recherche et la réflexion scientifique »
• Objectif:• Elévation du niveau d'abstraction par rapport à la programmation
procédurale • Plus adapté à notre esprit
• Intérêt• Considérer un logiciel comme
• un ensemble d'objet (des instances de classes) • communiquant par l'envoi de messages (des appels de méthodes)
Le paradigme Objet• Le trio du paradigme Objet
• Encapsulation• Héritage• Polymorphisme
Encapsulation• L’Encapsulation masque les détails d'implémentation d'un
objet de notre modèle
• Principe “boîte noire” : • Pour l'utiliser : ne doit connaître que son interface ie les méthodes
qu'il expose • On ne s’intéresse pas au détails d’implémentation, ceux-ci ne
devraient aucunement nous impacter
Voiture
+ accelerer()+ freiner()- injecterDeLEssenceDansLeMoteur()
- Vitesse max- Couleur
Polymorphisme• Le polymorphisme est le principe primordial permettant à
une fonction de recouvrir plusieurs formes de manière dynamique • Détermination à l‘exécution, pas à la compilation
• Exemple couplé avec l’héritage:
Vehicule
- accelerer()
Velo
- accelerer()
Voiture
- accelerer()
Polymorphisme• En C++
• méthode « virtual » dans classe mère + utilisation pointeur • méthode abstraite virtuelle pure
• définit avec « virtual » + « = 0 »
• En Java• toutes les méthodes sont implicitement « virtuelles » et tout est
implicitement « pointeur ». • méthodes « abstract »
Polymorphisme• Rappels:
• Une méthode abstraite doit impérativement est définit dans une une classe concrete
• Une classe ayant au moins une méthode abstraite est elle-même abstraite
• Une classe abstraite ne peut être instanciée
Héritage• L’Héritage permet de créer une classification de certains
objets suivant le principe de généralisation/spécialisation• Principe de la généalogie • Factoriser des comportements (méthodes) et les données sur
lesquelles elles travaillent
Héritage• Règles:
• La règle « est un » : on doit pouvoir affirmer : sous-classe « est un » super-classe. • Vérifier que la sous-classe appartient à l'ensemble défini par la super-
classe. • Ex : un requin est un poisson, une voiture est un véhicule, un employé
est une personne.
• La règle des 100% : • sous-classe doit correspondre totalement à ce qu'elle hérite de sa
super-classe • les attributs et les méthodes hérités doivent avoir un sens dans la sous-
classe
Héritage vs. Composition• En OOP, lorsqu’on crée deux objets, ils pourront être liés
de deux manières fondamentalement différentes : • Héritage : A hérite de B et peut donc profiter donc « nativement »
des opérations que propose A • Composition : A utilise un objet B et en invoque des opérations
• Différence agrégation/composition (vie de l‟objet inclus)
UML - Rappels• Notation, indépendant technologie • Doit être adapté à nos besoins et non l‟inverse • Pas une méthode d'analyse ! • UML peut se décrire avec UML : méta modélisation ?
• Quelques clichés : • Que dans les bouquins ... • Real programmer don't draw diagrams !
UML - Rappels• Multi-usage suivant phase projet :
• Analyse besoin business : • Cas d‟utilisation : scénarios d‟utilisation du système • Modèle de domaine : représentation concepts business (basé sur
diagramme de classe)
• Architecture : • Diagramme de composants
• Conception/Réalisation fonctionnelle et/ou technique • Représentation statique : diagrammes de classes • Représentation dynamique : diagrammes de séquence, de
collaboration, d‟état
• Déploiements • Diagramme de déploiement • … Non exhaustif !
UML - Rappels• Typologie des besoins
UML - Rappels• Spécification « business » / fonctionnelles
• Use case : Cas d‟utilisation du système et acteurs associés
• Diagramme de domaine : Entités du domaine business
UML - Rappels• Spécification « business » par Use case
• Cas d‟utilisation du système et acteurs associés
UML - Rappels• Spécification « business » par diagramme de domaine
• Vue statique des objets business • “A domain model captures the most important types of objects in the
context of the business. The domain model represents the „things‟ that exist or events that transpire in the business environment.” I. Jacobsen
• Les objets du domaine• Une classe de domaine peut être:
• Un objet business (associé à un objet “réél” ou non) représente un élément manipulé par le business ex : une commande, une usine, une machine, un produit...
• Un événement ex : une vente, un paiement
• Les associations entre des objets du domaine. Elle peuvent définir les rôles des classes et les cardinalités pour plus de précision.
UML - Rappels• Spécification technique ou fonctionnelle par diagramme
de classes
UML - Rappels• Spécification technique ou fonctionnelle par diagramme
de séquence
UML - Rappels• Spécification technique ou fonctionnelle par diagramme
de collaboration
Conception• C’est le processus itératif par lequel on affecte des
responsabilités aux objets logiciel (classes)
Conception - Méthodologie• Pour Tout les use cases business (par ordre
d‟importance décroissante) • Enrichir mon modèle de classe en décrivant la réalisation (via des
diagrammes dynamiques) • Déterminer les objets logiciel utilisés, quand cela est possible issus du
modèle de domaine• Adopter au maximum une conception qui réduit le décalage des
représentations.
• Leur affecter des responsabilités
Conception - Méthodologie• Exemple:
Conception - Méthodologie
Conception : les lignes guide• 1/ Faible couplage
• Objectifs: réduire l’impact des modifications• Le couplage est une mesure d'évaluation de la dépendance d'un
élément à un autre• A est couplé à B si elle fait appel à l’un de ses services• L’esprit ne peut appréhender simultanément plus de 5 à 7 objets • En Java, il suffit souvent de regarder les « imports »
Conception : les lignes guide• 2/ Forte cohésion = bonne responsabilisation
• Objectifs: s'assurer que les objets restent compréhensibles, faciles à gérer, et, bénéfice second, qu'ils contribuent au faible couplage
• Une classe ne devrait avoir qu'une seule raison de changer, c'est-à-dire ne posséder qu'une seule responsabilité.
• Se rapprocher au maximum des Design Pattern existants.
Conception : les lignes guide
Conception : les lignes guide• 3/ Créer des objets pures non issus du modèle de
domaine• Toutes nos classes logicielles ne peuvent être tirées du modèle du
domaine • Pour ne pas violer principe forte cohésion et faible couplage , «
fabrication » d’une classe cohésive et de bonne conception (de conception « pure »)
• Exemple: Une vue BDD n’est pas une classe du modèle de domaine mais elle représente bien un objet permettant de réaliser un cas d’utilisation • Par exemple, la consommation moyenne de tous les véhicules d’une
marque donnée…
Conception : les lignes guide• 4/ L’instanciation des objets est une responsabilité
• Qui crée l’objet ? • Comment limiter le cout des refactoring ?
• Affecter à la classe B la responsabilité de créer une instance de la classe A si une ou plusieurs des conditions suivantes est vraie: • B contient ou agrège des objets A • B enregistre des objets A • B utilise étroitement des objets A • B possède les données d'initialisation des objets A
• Utiliser au maximum les Design Pattern de type *Factory pour résoudre les cas complexes
Conception : les lignes guide
• 5/ Préférer la composition à l’héritage• L’héritage induit un couplage fort • L'héritage ne permet d'encapsuler qu'un niveau de variation
• Vite limitant quand plusieurs axes de variation
Conception : les lignes guide
• 6/ Abstraire les implémentations• Programmez une interface, non une implémentation
Conception : les lignes guide
• 7/ Encapsuler ce qui varie• Pour éviter que cette variation n'ait un impact important, il
faut isoler l'aspect susceptible de varier en l'encapsulant. Ainsi nous n'aurons pas d'« effet de bord ». Il n'y aura alors qu'un endroit à modifier pour tenir compte de la variation, nous n'affecterons pas les parties de code non changeantes.
• S'applique à plusieurs niveaux de granularité
Conception : les lignes guide
• 1/ Faible couplage• 2/ Forte cohésion = bonne responsabilisation• 3/ Créer des objets pures non issus du modèle de
domaine• 4/ L’instanciation des objets est une responsabilité• 5/ Préférer la composition à l’héritage• 6/ Abstraire les implémentations• 7/ Encapsuler ce qui varie
Design Patterns
• Qu’est ce qu’un Design Pattern ?• Solutions élégantes et extensibles à de nombreux
problèmes de conception courant • Indépendants de la plate-forme utilisée pour
développer• Permettent aussi d'évoquer des micro-architectures
par leur seul nom et sont donc un puissant outil de communication lors de la conception
• Permettent réutilisation de connaissance d’experts
• Elles demandent un coût supplémentaire de travail et impliquent un niveau d'abstraction plus élevé• Utilisation doit être justifiée
Design Patterns
• Classification des Design Patterns:• Enterprise Architecture framework Patterns
• Il définissent l’architecture du système dans la globalité du système d’information• Exemple: Data Extraction Transformation and Loading (ETL), Data Warehouse…
• Les Patterns de domaine • Ils sont spécifiques à une architecture telle que J2EE ou .NET par exemple. Ils formalisent la
bonne manière de tirer profit de cette architecture. • Exemple : Core J2EE Patterns (Sous Java EE)
• Design patterns d’architecture • Ils définissent l'architecture de haut niveau d'une l'application • Exemple : Modèle-Vue-Contrôleur (MVC),
• Les Patterns d’implémentation• Ils suggèrent une manière d’arranger des classes pour répondre à un problème « simple ».• Exemple: Factory, Singleton…
• Les Anti-Patterns • Les Anti-Patterns nomment et formalisent de mauvaises solutions de conception. Ils
formalisent des pièges courant dans lequels peuvent tomber les développeurs• Exemple : Paralysie analytique , Usine à gaz, Réinventer la roue
Design Patterns• Les Design Patterns d’implementation les plus courants
par catégorie• http://fr.wikipedia.org/wiki/Patron_de_conception
• Création• Abstract Factory• Builder• Factory Method• Prototype• Singleton
• Structure• Adapter• Bridge• Composite• Decorator• Facade• Flyweight• Proxy
• Comportement• Chain of responsability• Command• Interpreter• Iterator• Mediator• Memento• Observer• State• Strategy• Template Method• Visitor• Callback
Keywords
UML
Java
Héritage
Aggregation
Composition
Objet
Diagramme de classes
Diagramme de séquence
Diagramme de domaine
Couplage fort
Couplage faible
Factory
Use case
Polymorphisme
Méthode abstraite
Méthode virtuelle
Encaspulation
Responsabilisation
Design pattern
Singleton
Factory Composite
Iterator
Observer
MVC
