Simulation, modélisation, traitement des données

1. Simulation, modélisation, traitement des données Une approche pragmatique D. Buskulic, Maubuisson 2001

2. I. Généralités I.1 Contraintes sur les outils de Physique Corpusculaire D. Buskulic, Maubuisson 2001

3. Quantité de données à traiter • 1 Teraoctet à quelques Petaoctets/an ! • 1015 octets • 1000 Teraoctets • 20 000 bandes d'aujourd'hui • 100 000 DVD RAM double face • 1 500 000 exemplaires de l'Encyclopaedia Universalis ! • Seulement 1 evt sur 106 est intéressant ! • 1 sur 109 REELLEMENT intéressant ! • -> Data Mining (recherche d'une aiguille dans une botte de foin) D. Buskulic, Maubuisson 2001

4. Ca va plus vite que la loi de Moore • Données Babar D. Buskulic, Maubuisson 2001

5. Conséquences • Importance des outils de gestion des données (bases de données) • Importance des outils d'analyse statistique • L'analyse requiert un accès efficace aux données et aux fonctions D. Buskulic, Maubuisson 2001

6. Quantité de calculs nécessaires • Grande puissance de calcul nécessaire pour simuler/reconstruire/analyser les données • 1000 à 10000 PC d'aujourd'hui (fermes) • Importance du calcul parallèle • Futur : calcul distribué D. Buskulic, Maubuisson 2001

7. I. Généralités I.2 Critères et fonctionnalités à respecter D. Buskulic, Maubuisson 2001

8. Comment faisait-on une analyse ? Modèle "Batch" Détecteur Données Traitement batch histos… D. Buskulic, Maubuisson 2001

9. Un meilleur modèle Raw Data coups ADC… Détecteur ou simulation une fois DST traces, etc… Reconstruction Ntuple valeurs calculées Analyse histos… un grand nombrede fois Mais ca ne suffit pas pour traiter les données LHC ! D. Buskulic, Maubuisson 2001

10. Tâches à effectuer : exemple Recette : • Calibrer les signaux • Extraire les composants élémentaires (traces) • Reconnaître les particules individuelles • Reconnaître les caractéristiques physiques de l'événement • Extraire les quantités physiques Et ceci 10 millions de fois ! D. Buskulic, Maubuisson 2001

11. Tout ceci dans une grande variété de situations : • Près du détecteur : algorithmes de reconstruction, études sur l'évolution des performances… • Etude d'une grande quantité d'événements • Etude d'un seul événement marquant • Analyse de signal • Comparer théorie et résultats expérimentaux Reste à étudier la physique, mesurer, publier… D. Buskulic, Maubuisson 2001

12. Problèmes cruciaux • Où se trouvent les données ? • Plusieurs Petaoctets doivent être distribués • Plusieurs centres de stockage interconnectés • Où sont-elles traitées ? • Traitement également distribué, au plus près des données • Un problème d'une telle dimension ne peut être résolu qu'internationalement • Exemple : Babar a deux sites de stockage/calcul, Stanford et Lyon (CCIN2P3) D. Buskulic, Maubuisson 2001

13. Influence sur les modèles d'environnement de travail • Concilier : • Point de vue de l'utilisateur • Besoin de "toucher et voir", manipuler les données pour acquérir une compréhension des problèmes • La boucle expérimentale est dans l'analyse • Doit pouvoir traiter aussi bien de petites quantités de données "à fond" que de grosses quantités • Point de vue du concepteur du système • Fermes de production centralisées • Calcul local/distribué • Modèles informatiques ? (Software Engineering) • Frameworks vs Composants, méthodes de conception D. Buskulic, Maubuisson 2001

14. Influence sur les modèles d'environnement de travail • Modèles d'environnements de travail : Composants Boite à outils Services D. Buskulic, Maubuisson 2001

15. Comparaison des approches • Physiciens habitués à la boîte à outils • Outils puissants • Contrôle tout depuis le début • Mais pas adapté aux flux de données actuels • Approche "composants" (Plug-ins) permet de se concentrer plus sur le problème • peut oublier certains "détails" -> lesquels ? • Peut-on faire tout ce que l'on veut ? • Approche "services" comme compromis • En s'assurant que l'on peut tout contrôler • Exemple des approches actuelles : dans la suite du cours D. Buskulic, Maubuisson 2001

16. II. Programmation et langagesOrientés Objet II.1 Motivations D. Buskulic, Maubuisson 2001

17. Evolution • La quantité et la complexité des données rendent nécessaire une certaine forme d'abstraction des détails de base • Exemple : fabrication des ordinateurs • 1950 : tubes • 1960 : transistors • 1970 : circuits intégrés • 1980 : microprocesseur • 1990 : microcontrôleurs • 2000 : ordinateur sur une puce • Quel concepteur de PC s'occupe de savoir ce que fait chacun de 20 Millions de transistors dans un microprocesseur ? Complexité des briquesélémentaires Complexité des tâches D. Buskulic, Maubuisson 2001

18. On peut essayer d'adapter les vieux outils • Mais il faut parfois faire des sauts conceptuels D. Buskulic, Maubuisson 2001

19. Couplage • Des parties de code d'analyse (reconstruction) vont remonter le diagramme • Réutilisation du code, simplicité • Peut-on transférer un objet complexe dans un nœud de trigger ? • Ex : une trace qui sait comment calculer sa quantité de mouvement • Ex : un histo qui sait comment se tracer lui-même Raw DST Ntuples Histos D. Buskulic, Maubuisson 2001

20. Un bon logiciel c'est… • Vous écrivez vos logiciels pour les autres ! • Un bon logiciel doit : • Avoir une structure aisément compréhensible • Pouvoir être facilement débogué • Autoriser facilement le changement d'une partie sans affecter les autres parties • Avoir un code modulaire et réutilisable • Etre simple à maintenir et mettre à jour • Etc… • La programmation orientée objet (POO) vous aide à écrire de bons logiciels… mais… D. Buskulic, Maubuisson 2001

21. Ce n'est pas la panacée ! • L'utilisation d'un langage dit "orienté objet" ne garantit pas une "programmation orientée objet" • Un code mal écrit en C++ est pire qu'un code mal écrit en Fortran • Les langages OO ne sont destinés qu'a simplifier une bonne programmation OO • Le langage est un outil pour arriver à l'orientation objet D. Buskulic, Maubuisson 2001

22. Programmation orientée objet : histoire • Plus de 30 ans de développements, d'expérience et de pratique de programmation • 1967 : Simula67 • 1980 : Smalltalk80 • Lisp, Clu, Actor, Eiffel, Objective C • C++ et Java • Motivation • La crise du logiciel (1980-1990): • Matériel de plus en plus puissant et peu cher • Logiciel de plus en plus complexe et cher • Besoin de rendre le code réutilisable • Cache les détails de l'implémentation d'un algorithme, programme ou structure au monde extérieur, montre juste une interface. D. Buskulic, Maubuisson 2001

23. II. Programmation et langagesOrientés Objet II.2 Principe et concepts de base D. Buskulic, Maubuisson 2001

24. Principe de base • L'idée est de représenter le comportement du monde réel sous une forme qui cache les détails de l'implémentation • Lorsque ca fonctionne, la POO permet de penser en termes de domaine élargi du problème D. Buskulic, Maubuisson 2001

25. Trois idées de base • Trois idées fondamentales caractérisent la Programmation Orientée Objet : • Classe/Objet Encapsulation • Hiérarchies de classes Héritage • Abstraction / Polymorphisme D. Buskulic, Maubuisson 2001

26. II. Programmation et langagesOrientés Objet II.3 Classes, Objets et Encapsulation D. Buskulic, Maubuisson 2001

27. Classes et Objets • La POO est une manière de programmer centrée sur les objets (Quoi ?) plutôt que sur les procédures (Comment ?) • Les objets et leur comportement sont très fortement liés • Données et comportements sont regroupés dans des classes dont les instances sont des objets • Une classe représente un type de "chose" dans le système, un objet représente une chose particulière. • Ex. : classe "trace" est un type, la trace particulière "p+no 23" est un objet D. Buskulic, Maubuisson 2001

28. Classes et Objets • Finalement, la POO voit la programmation comme une activité de simulation de comportement. • Ce qui est simulé, ce sont des objets représentés par une abstraction dans le programme D. Buskulic, Maubuisson 2001

29. Classes et objets • Les classes sont responsables de leur comportement class Impulsion { public : Impulsion(double x0, double y0, double z0, double e); ~Impulsion(); Impulsion& operator= (const Impulsion & droite); Impulsion& operator+ (const Impulsion & droite); double Module(); … D. Buskulic, Maubuisson 2001

30. Classes et objets • En C++, on peut définir les opérateurs standard (=, +, -, *, / ) pour une classe • Une classe est un type comme un autre (float, double,…) • Améliore la lisibilité du code Impulsion a,b,c; c=a+b; D. Buskulic, Maubuisson 2001

31. Classes et objets • Les données membres d'une classe ont une relation d'appartenance (possède un) D. Buskulic, Maubuisson 2001

32. Encapsulation • Une classe possède une implémentation des détails de son comportement et une interface vers l'extérieur • Les détails d'implémentation doivent être inaccessibles de l'extérieur, c'est à dire des codes et objets qui utilisent la classe. • Les données membres de la classe doivent être privées, accessibles seulement à travers des fonctions membres (méthodes) du type Set/Get D. Buskulic, Maubuisson 2001

33. Encapsulation • Les changements de l'implémentation interne ne doivent pas modifier la façon dont on accède et utilise la classe extérieurement class Impulsion { … private: double m_Px; double m_Py; double m_Pz; double m_E; public: double GetP() const; void SetP(double p); class Impulsion { … private: double m_P; double m_Theta; double m_Phi; double m_E; public: double GetP() const; void SetP(double p); Données internes (privéees) Méthodespubliques D. Buskulic, Maubuisson 2001

34. II. Programmation et langagesOrientés Objet II.4 Hiérarchies de classes et héritage D. Buskulic, Maubuisson 2001

35. Héritage et hiérarchies de classes • L'héritage est un moyen de dériver une nouvelle classe de classes préexistantes, appelées classes de base • La nouvelle classe dérivée peut utiliser le code de sa ou ses classes de base • A travers l'héritage, on peut créer une hiérarchie de classes qui partagent du code et des interfaces • L'héritage est une méthode pour gérer la complexité D. Buskulic, Maubuisson 2001

36. Hiérarchie de classes L'héritage correspond à une notiond'identité ("est un") D. Buskulic, Maubuisson 2001

37. TObject Segment Momentum • possèdeun est un possèdeun Event Track MassSquared • possèdeun • possèdeun • possèdeun • possèdeun Vertex InterceptAtVertex D. Buskulic, Maubuisson 2001

38. II. Programmation et langagesOrientés Objet II.5 Abstraction et polymorphisme D. Buskulic, Maubuisson 2001

39. Abstraction • On peut définir des classes destinées uniquement à donner naissance à d'autres classes par héritage • Ce sont des classes "abstraites" • Permet • De définir une interface générale ("abstraite") • De simplifier la modularité et la portabilité du code • Par exemple GEANT4 est libre de tout choix de techniques d'entrées/sorties ou d'histogrammation. De même, le GUI (Graphical User Interface) et la visualisation sont complètement isolées du noyau de GEANT4 par l'intermédiaire d'interfaces abstraites D. Buskulic, Maubuisson 2001

40. Polymorphisme • Le polymorphisme prend de nombreuses formes : • Surcharge de fonctions et d'opérateurs • Redéfinition de fonctions membres d'une classe de base par une classe dérivée • Patrons (templates) de classes D. Buskulic, Maubuisson 2001

41. Polymorphisme : surcharge • En POO, une fonction peut avoir le même nom, mais des arguments différents. • Exemple Draw(TLine* ligne) Draw(TBox* carre) • On ne trace pas de la même manière une ligne et un carré • La distinction est faite par le compilateur sur le type des arguments ("signature" de la fonction) D. Buskulic, Maubuisson 2001

42. Polymorphisme : surcharge • On peut également en C++ surcharger des opérateurs • Ex: La somme de deux histogrammes peut avoir un sens. On peut surcharger les opérateurs "+" et "=" pour permettre • h3 = h1 + h2; • Ne le faites que si vous savez où vous mettez les pieds ! D. Buskulic, Maubuisson 2001

43. Polymorphisme : redéfinition • Lorsqu'une classe dérivée a besoin de réaliser une opération définie dans la classe de base mais un peu différemment, elle peut redéfinir la fonction membre de la classe de base • Ex. : fonction "Draw". Si la classe "TArrow" dérive de la classe "TLine", il faudra ajouter le code de tracé de la pointe de la flèche. Ceci peut se faire dans la classe dérivée en redéfinissant la fonction membre "Draw". D. Buskulic, Maubuisson 2001

44. Polymorphisme : redéfinition et … pièges ! class Base { public: Base() {;} virtual void Affiche(int i) {cout<<"Int"<<endl;} virtual void Affiche(double i) {cout<<"Double"<<endl;} } class Derive : public Base { public: Derive() {;} virtual void Affiche(int i) {cout<<"Int"<<endl;} } main() { Base* a = new Derive(); a->Affiche(1.0); } -> affiche "Int" ! D. Buskulic, Maubuisson 2001

45. Polymorphisme : Patrons de classes • C++ a la notion de polymorphisme paramétrique. Kézaco ? • Un patron de classe (template) permet de définir une classe indépendamment d'un type • Ex : un tableau de nombres, qu'ils soient entiers, longs, float ou doubles • Principalement utilisé dans la librairie STL (Standard Template Library). Facilite le développement. • Conseil personnel : n'allez pas au delà de l'utilisation de STL… D. Buskulic, Maubuisson 2001

46. II. Programmation et langagesOrientés Objet II.6 C++ et Java D. Buskulic, Maubuisson 2001

47. C++ • Origine : les labos AT&T (Bjarne Stroustrup) • Le C++ a été conçu comme une extension du C qui prend certaines libertés avec les concepts POO "purs" • L'encapsulation n'est pas obligatoire • On mélange les fonctions (procédures) du C et les classes et leurs fonctions membres • Conséquence : on peut très bien écrire un programme procédural en C++ • Principal mérite : a permis une transition "acceptable" de la programmation procédurale vers la POO • Principal défaut : trop de liberté d'action. Il est facile de mettre le fouillis dans du code • Quelqu'un a déjà eu des démêlés avec des pointeurs ? D. Buskulic, Maubuisson 2001

48. Java • Origine : Sun Microsystems (1991) • Objectifs : • Simple : syntaxe "C" • Sûr : pas de manipulation de pointeurs, vérification du code à l'exécution • Orienté Objet : Ni variables, ni fonctions globales • Robuste : Ramasse-miettes, fortement typé, gestion des exceptions • Indépendant de l'architecture sous sa forme "interprétée" • -> mais lent dans ce cas • C'est de la POO "pure" D. Buskulic, Maubuisson 2001

49. Java : langage orienté objet • Langage orienté objet : • TOUT est classe (pas de fonctions) sauf les types primitifs (int, float,…) et les tableaux • Toutes les classes héritent d'une classe de base java.lang.Object • Héritage simple D. Buskulic, Maubuisson 2001

50. Java : avantages • Portabilité • Le compilateur java génère du "byte-code" • Les "Java Virtual Machine" présentes sur de nombreuses plateformes : Unix, Win32, Mac, Netscape, IE,… • La taille des types primitifs est indépendante de la plateforme • Java est toujours accompagné d'une librairie standard • Robustesse • Compilateur contraignant D. Buskulic, Maubuisson 2001