Conception - Objets & UML -

1. Conception- Objets & UML - Pierre-Johan CHARTRE pierre-johan.chartre@logica.com

2. 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

3. Problème • Q: quels sont les changements que peut rencontrer un logiciel dans sa vie ?

4. 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

5. 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

6. 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)

7. Le paradigme Objet • Le trio du paradigme Objet • Encapsulation • Héritage • Polymorphisme

8. Encapsulation • L’Encapsulationmasque 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 • Vitesse max • Couleur + accelerer() + freiner() - injecterDeLEssenceDansLeMoteur()

9. Polymorphisme • Le polymorphismeest 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() Voiture Velo • accelerer() • accelerer()

10. 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 »

11. 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

12. 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

13. 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

14. 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)

15. 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 !

16. 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 !

17. UML - Rappels • Typologie des besoins

18. 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

19. UML - Rappels • Spécification « business » par Use case • Cas d‟utilisation du système et acteurs associés

20. 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.

21. UML - Rappels • Spécification technique ou fonctionnelle par diagramme de classes

22. UML - Rappels • Spécification technique ou fonctionnelle par diagramme de séquence

23. UML - Rappels • Spécification technique ou fonctionnelle par diagramme de collaboration

24. Conception • C’est le processus itératif par lequel on affecte des responsabilités aux objets logiciel (classes)

25. 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

26. Conception - Méthodologie • Exemple:

27. Conception - Méthodologie

28. 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 »

29. 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.

30. Conception : les lignes guide

31. 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…

32. 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 *Factorypour résoudre les cas complexes

33. 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

34. Conception : les lignes guide • 6/ Abstraire les implémentations • Programmez une interface, non une implémentation

35. 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é

36. 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

37. 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-architecturespar 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

38. 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

39. Design Patterns • Les Design Patterns d’implementation les plus courants par catégorie • http://fr.wikipedia.org/wiki/Patron_de_conception • Comportement • Chain of responsability • Command • Interpreter • Iterator • Mediator • Memento • Observer • State • Strategy • Template Method • Visitor • Callback • Structure • Adapter • Bridge • Composite • Decorator • Facade • Flyweight • Proxy • Création • Abstract Factory • Builder • FactoryMethod • Prototype • Singleton

40. Keywords Factory Encaspulation Composite Méthode abstraite Objet Couplage faible Iterator Composition Diagramme de classes UML Diagramme de séquence Aggregation Singleton Responsabilisation Polymorphisme Factory Couplage fort Héritage Observer Java Méthode virtuelle Diagramme de domaine Use case MVC Design pattern