CONCEPTION DES LOGICIELS : Chapitre 5

1. CONCEPTION DES LOGICIELS : Chapitre 5 Introduction à l’analyse et à la conception objet Le langage UML

2. Plan du chapitre • Nouveaux besoins - Nouvelles architecture - Nouvelles applications • Genèse des objets - Construction des abstractions architecturales dans un style objet • Pilotage et Contrôle des enchaînements - Notions d’états-transitions

3. 1ère partie Nouveaux besoins - Nouvelles architecture - Nouvelles applications

4. Architecture Client-Serveur Application Client C Serveur S Disque C Disque S Réseau local haut débit (> 1 méga octets) Communication entre le client et le serveur paréchange de messages  L’application est physiquement répartie, mais dans la programmation structurée classique, C et S sont 2 entités distinctes qui s’ignorent totalement, d’où : problème de cohérence

5. Avantages/Inconvénients des Architectures C-S • Avantages • Évolutions indépendantes des C et S sous réserve du respect absolu de l’interface message • Obligation d’expliciter rigoureusement les interfaces entre C et S • Souplesse, Coûts des configurations + faible • Inconvénients • Contrôle obligatoire des comportements induits par le réseau • Non déterminisme, gestion des ressources, propagation des défaillances  Programmation plus complexe • Disponibilité, sûreté de fonctionnement,… • à la charge du programmeur

6. Exemple de serveur de données • Traitement de la requête sur S : • 1ère étape : Traduction de la requête(par exemple en SQL) • 2ème étape : Exécution par le « moteur » de requête Client C Serveur S Disque S Disque C Émission d’un message de requête « Machine » de traduction Ordre N°1 • • • Retour des résultats de la requête Ordre N°n Aiguillage « Machine » d’exécution  Besoin de « machines » spécialisées dynamiquement programmables Stockage des résultats avant émission Mot d’état définissant les modalités d’exécution

7. 2ème partie Genèse des objets - Construction des abstractions architecturales dans un style objet

8. Un exemple d’abstraction : les nombres (1/2) • Le concept de nombre et ses représentations • Niveau 0 : chaque nombre à un nom propre • Aucune opération n’est possible, le « 0 » n’existe pas • Niveau 1 : émergence d’un alphabet pour écrire les nombres  chiffres romains • Toujours pas de 0, mais les opérations + et  sont possibles • Niveau 2 : émergence de la notion de système de numération • Le 0 est introduit par les mathématiciens/logiciens hindous ; toutes les opérations {+,  ,,} sont possibles sauf • la correspondance entre le groupe + et le groupe  est établie avec la fonction logarithme.

9. Un exemple d’abstraction : les nombres (2/2) • Niveau 3 : nombres abstraits complexes (Euler, de Moivre, Argand, etc.), quaternions (Hamilton) • La recherche du sens du « nombre imaginaire » crée une nouvelle classe de nombres dont R.Argand (1806) découvre une interprétation géométrique qui sera appelée vecteur par H.G.Grassmann (1844) • W.R.Hamilton généralise la notion de nombre complexe à de nouveaux nombres « quaternions » • Niveau 4 : D.Hilbert, E.Artin créent la théorie des corps de nombres algébriques qui n’a plus qu’un très lointain rapport avec la notion intuitive de nombre • On peut « algébriser » la géométrie (ou l’inverse ! ) • Concept de matrice de nombres

10. Opérations génériques et polymorphisme Sélection de la bonne opération à partir du type des données en entrée Édition de lien dynamique indispensable Opérations génériques : +, - ,  ,  Type entier Type décimal +, - ,  ,  sur le type entier Données d’entrée Type flottant +, - ,  ,  sur le type décimal Type complexe Résultats • • • Type vecteur Type matrice +, - ,  ,  sur le type matrice • • •

11. Introduction au langage UML Cf. site OMG : www.omg.org État actuel de la norme : version 1.3

12. Terminologie de l’analyse objet (1/2) • Modèle objet • Un ensemble de classes représentant le monde réel tel qu’il résulte des choix de modélisation • Classe • Une abstraction du « réel » permettant de représenter plusieurs objets présentant une structure commune • Pour une définition précise des classes, voir la théorie des ensembles • Objet • Un objet est l’« instanciation » d’une classe; un objet a une identité (OID), des méthodes définissant le comportement et un état définissant l’information qu’il détient • Méthode • Une opération permettant la description et l’implémentation d’un comportement ; fait partie de l’objet et de la classe qui le définit

13. Terminologie de l’analyse objet (2/2) • Instanciation • Mécanisme permettant la construction effective de l’objet (statiquement ou dynamiquement) à partir de la classe qui le définit et des paramètres spécifiques de l’instance • Exemples : macro-expansion, création d’une BD conformément à son schéma logique, etc. • état • État mémoire, état du flot d’exécution, état du flot d’événements ; l’état caractérise l’information transformée au moyen des méthodes(Cf. les opérations de base d’un modèle de données - cours conception Ch. 2) • Surcharge (Économise les noms et facilite l’abstraction) • Redéfinition du sens d’une entité ; exemple : surcharge d’un opérateur • Polymorphisme (Économise les noms et facilite l’abstraction) • Nom + ensemble de types caractérisant plusieurs opérations similaires ; exemple : TRI (types des entités à trier)

14. Les objets (1/3) • Qu’est-ce qu’un objet ? • une abstraction d’une entité du monde réel / observée • Étant donnée une abstraction, on cherche à regrouper • des données représentant la structure de cette abstraction • des fonctions décrivant son comportement • Un objet est donc un ensemble de données et de fonctions fortement liées • Chaque objet n’expose aux autres objets qu’un sous ensemble de ses opérations • interface de l’objet • Encapsulation • Les données / détails d’implémentation sont cachés

15. Les objets (2/3) • Objets faiblement liés entre eux • Pour que le contrôle d’accès et l’encapsulation soient efficaces (ou simplement réalisables…) • Forte cohérence interne des abstraction et faible couplage • doivent permettre de décomposer les problèmes abordés en sous problèmes moins complexes. • L’état d’un objet varie au cours du temps • vie de l’objet • Le principe d’encapsulation • assure que tous les changements d’état non initiés par l’objet lui-même sont dus à des stimuli reçus par l’objet (appels d’opérations) • n’est plus respecté si plusieurs objets partagent les mêmes données

16. Les objets (3/3) • Chaque objet est muni d’un identifiant unique : OID • La définition d’unicité de l’OID dépend du cadre de référence (cadre de déploiement du système) : • pour une application standalone : • unicité au niveau du process • dans un système distribué (CORBA, RMI, COM+, etc.) : • unicité au niveau du réseau de machines • dans une optique Internet : • unicité globale • Objet = OID + Comportement/Opérations + Etat • Exemple : objet dictionnaire • OIDISBN, date d’impression, etc. • ComportementChercher mot, ouvrir à la pager, fermer, etc. • ÉtatEst ouvert à la page xx

17. Classe • Une classe est une collection d’objets possédant tous : • les mêmes structures de données • les mêmes caractéristiques comportementales • le même ensemble d’états possibles • Un classe est le « plan » d’un objet • Doit spécifier les états valides et / ou les états invalides • invariants de l’objet • Au niveau logique une classe est définie par • des données • attributs / propriétés • des comportements • opérations / méthodes • des modes d’instanciation, de finalisation • constructeurs / destructeur

18. Classe, notation UML Le nom de la classe UneClasse attribut_privé : boolean = false Les attributs attribut_publique : int = 0 attribut_protégé : byte méthode_publique(entier : int = 0) : int méthode_protégée(réel : double) : double Les méthodes méthode_privée() : UneClasse UneClasse() UneClasse(x : UneClasse) Notations pour le contrôle d’accès : Privé : - (standard) ou (graphique divers outils) Protégé : # (standard) ou (graphique divers outils) Publique : + (standard) ou (graphique divers outils)

19. UML, un langage de modélisation à large spectre (1/2) • Filiation • Programmation objet (Smalltalk, Eiffel, etc.) et types abstraits de données (Pascal, Ada)  Conception orientée objet (OMT)  Notation unifiée de l’OMG : UML • Méthode et/ou outil ?! • UML n’est pas une méthode, c’est un ensemble de langages/notations dont la sémantique n’est pas - pour le moment - parfaitement cohérente • Il y a des présupposés pouvant être partiellement comblés par des langages comme IDL, XML • Sans méthode, l’emploi de UML est voué à l’échec

20. UML, un langage de modélisation à large spectre (2/2) • Concepts de programmation objet réutilisés pour la modélisation • Hiérarchies et mécanismes d’héritage (bibliothèques d’objets) • Problèmes d’édition de liens statiques et/ou dynamiques) • Polymorphisme • Permet de donner le même nom à des objets dont les types diffèrent (exemple : différentes catégories de nombres ayant des comportement identiques) , d ’où : économie de noms • Composants et réutilisation • Totalement tributaire de l’architecture logicielle de l’application

21. Concepts et notations UML (1/4)Les diagrammes • Nomenclature statique (3 diagrammes) • Diagrammes de classes (modèle ERA + opérations permettant la navigation) • Diagrammes objets (i.e. instance de classes) • Diagrammes de collaboration (échanges de   « messages » entre objets) • Mais pas de syntaxe comme ASN.1 (cf. Norme UIT X400) • Voir également les évolutions de XML du W3C • Interactions avec le monde extérieurscénarios (2 diagrammes) • Cas d’utilisation (use case) • Diagrammes de séquences (interactions temporelles entre objets) • S’appuient sur les diagrammes de collaboration

22. Concepts et notations UML (2/4)Les diagrammes • Machine à états finisEnchaînements et contrôle du flot d’exécution (2 diagrammes) • Diagrammes d’activités • Diagrammes états-transitions • CartographieLocalisation spatiale et réalisation (2 diagrammes) • Diagrammes de composants • Diagrammes de déploiement

23. Concepts et notations UML (3/4) • Qq. concepts UML centraux (éléments de la modélisation) • Concepts « objet » • Objet (opérations + types de données) ; Classes ; Polymorphisme • Mécanisme d’extensibilité via le mécanisme des stéréotypes • Qq. concepts réutilisés dans des notations antérieures • Modèle Entité-Relation-Attribut étendu (Agrégation + généralisation + spécialisation) • Modules et interface ; couches • Structuration • Hiérarchie ; Paquetage (i.e. service)

24. Qq. concepts pas vraiment pris en compte dans la notation actuelle : Sûreté de fonctionnement et plus généralement les caractéristiques non fonctionnelles Gestion des défaillances  identification des états incohérents (Structurant pour l’architecture) Contraintes, invariants, assertions Mais normalisation du langage OCL en cours(Cf. version 1.3 du standard) Synchronisation (sémaphores) ; Ressources ; Canal de communication Cf. le modèle de processus Transaction (propriétés ACID) AQ logiciel ; Intégration et VVT (Cf. TTCN de l’UIT) Concepts et notations UML (4/4)

25. Bibliographie UML et objet • Ouvrages élémentaires et/ou introduction à UML • P-A.Muller : Modélisation objet avec UML, Eyrolles • F. Vallée, P. Roque, UML en Action, Eyrolles • Ouvrages d’approfondissement • M. Fowler, K. Scott, UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, Reading MA, 1997 • I.Jacobson : Le Génie Logiciel orienté objet, Addison WesleyObject oriented software engineering (original en anglais) • I.Jacobson : The object advantage, Addison Wesley • B.Meyer : Conception orientée objet, Prentice HallObject oriented software construction (original en anglais) • M.Smith, Object oriented software in Ada 95, ITP • Gamma & al., Design patterns : Elements of Reusable Object Oriented Software, Addison Wesley • Ouvrages théoriques • M.Abadi, L.Cardelli : A theory of objects, Spinger (1ère tentative sérieuse de définition de la sémantique à l’aide du -calcul)