Quelques informaticien(ne)s célèbres Yann-Gaël Guéhéneuc Département de génie informatique et de génie logiciel This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported License [email protected]Version 1.0 2013/04/22
De brèves présentations de quelques femmes et hommes qui ont marqué l'histoire de l'informatique
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Quelquesinformaticien(ne)s
célèbres
Yann-Gaël Guéhéneuc
Département de génie informatique et de génie logiciel
This work is licensed under a Creative Commons Attribution-NonCommercial-
� Dave Parnas– Né le 10 février 1941– Père des critères de décomposition en
conception modulaire
Dave Parnas*1941
47/76
conception modulaire
IEEE Computer Society 60th Anniversary Award en 2007
– Cf. http://en.wikipedia.org/wiki/David_Parnas
Dave Parnas
� Conception modulaire– Contexte
• 1972– Langages de
48/76
– Langages de programmation impératifs et par objets
– Diagrammes de flots – Décomposition des
programmes en modules, classes…
Dave Parnas
– Critères• “[I]t is almost always incorrect to begin the
decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins
49/76
of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others”
• Information hiding = Encapsulation
Dave Parnas
– Révision du critère en termes de• Cohésion• Couplage
50/76
• Concepts « inventés » par Larry Constantine en 1968 et publié en 1974, dans W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.
• Un module doit avoir une forte cohésion et un fable couplage avec les autres modules
Manny Lehman
� Meir M. « Manny » Lehman– Décédé le 29 décembre 2010– Père des lois de l’évolution
• Types de programmes– S : peuvent être spécifiés formellement– P : sont soumis à un processus itératif– E : sont partis intégrante de notre environnement
Manny Lehman
– Huit lois1. Continuing change: E-type systems must be continually
adapted or they become progressively less satisfactory2. Increasing complexity: As an E-type system evolves its
complexity increases unless work is done to maintain or
53/76
complexity increases unless work is done to maintain or reduce it
3. Self regulation: E-type system evolution process is self regulating with distribution of product and process measures close to normal
4. Conservation of organisational stability: The average effective global activity rate in an evolving E-type system is invariant over product lifetime
Manny Lehman
– Huit lois5. Conservation of familiarity: As an E-type system evolves all
associated with it must maintain mastery of its content and behaviour to achieve satisfactory evolution. The average incremental growth remains invariant as the system evolves
54/76
incremental growth remains invariant as the system evolves6. Continuing growth: The functional content of E-type systems
must be continually increased to maintain user satisfaction over their lifetime
7. Declining quality: The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes
8. Feedback system: E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base
Frederick Brooks
� Frederick Brooks– Né le 19 avril 1931– Père de la loi de Brooks
Frederick Brooks*1931
55/76
– IEEE J. von Neumann Medal en 1993– ACM Turing Award en 1999
– Cf. http://en.wikipedia.org/wiki/Fred_Brooks
Frederick Brooks
� Principe de la loi de Brooks– Contexte
• 1956–1964– Gestionnaire du projet de développement du IBM OS/360
56/76
– Gestionnaire du projet de développement du IBM OS/360– Retards dans la livraison
– Livre• The Mythical Man-Month: Essays on Software
Engineering
– Principe• Adding manpower to a late software project
makes it later
Frederick Brooks
– Raisons• It takes some time for the people added to a
project to become productive. Brooks calls this the "ramp up" time. New workers must first become
57/76
"ramp up" time. New workers must first become educated about the work that has preceded them; also integrate with a team composed of multiple engineers who must educate the new worker in their area of expertise in the code base, day by day
• Communication overheads increase as the number of people increases. The number of different communication channels increases along with the square of the number of people
Frederick Brooks
– Commentaires, solutions• Brooks' Law often applies to projects that are already
late• The quantity, quality and role of the people added to
58/76
• The quantity, quality and role of the people added to the project also must be taken into consideration
• Good management and development practices also help to minimize the impact of Brooks' Law
• Rather than depending on heroes to carry the day with extraordinary efforts, Wiegers argues that a team of ordinarily-skilled individuals can repeatedly deliver timely results in the right work environment
Frederick Brooks
– Critiques“How to quadruple your productivity with an army of student interns”
59/76
• Tolerate a little crowding• Locate next to a deep pool of hackers• Know who the best people are and only hire them• Pay well• Divide tasks to be as loosely-coupled as possible• Design your intern projects in advance
Edward Yourdon
� Edward Yourdon– Né le 30 avril 1944– Promoteur des sept types de cohésion
Edward Yourdon*1944
60/76
– Cf. http://en.wikipedia.org/wiki/Edward_Yourdon
Edward Yourdon
� Conception modulaire– Contexte
• 1972– Langages de
61/76
– Langages de programmation impératifs et par objets
– Diagrammes de flots – Décomposition des
programmes en modules, classes…
• 1987– Boom du paradigme de
la programmation par objets
Edward Yourdon
– Critère de cohésion1. Accidentel : décrivant le niveau le plus faible où le
lien entre les différentes méthodes est inexistant ou bien créé sur la base d'un critère futile
62/76
bien créé sur la base d'un critère futile– Classes utilitaires
2. Logique : lorsque les méthodes sont reliées logiquement par un ou plusieurs critères communs– Toutes les classes qui traitent des matériels d’entrée,
souris, clavier, etc.
3. Temporel : lorsque les méthodes doivent être appelées au cours de la même période de temps– Une méthode appelée dans un « catch », etc.
Edward Yourdon
– Critère de cohésion4. Procédural : lorsque les méthodes doivent être
appelées dans un ordre spécifique– Une méthode qui vérifie les permissions et une méthode
63/76
– Une méthode qui vérifie les permissions et une méthode qui ouvre un fichier
5. Communicationnel : lorsque les méthodes manipulent le même ensemble spécifique de données– Toutes les classes qui portent sur des dates, etc.
Edward Yourdon
– Critère de cohésion6. Séquentiel : lorsque les méthodes qui manipulent
le même ensemble de données doivent être appelées dans un ordre spécifique
64/76
appelées dans un ordre spécifique– Un analyseur syntaxique : les entrées d’une classe
provient des sorties d’une autre
7. Fonctionnel : réalise le niveau le plus élevé lorsque la classe ou le module est dédié à une seule et unique tâche bien spécifique– Classes qui contribuent à remplir un même besoin
Barbara Liskov
� Barbara Liskov– Née le 7 novembre 1939– Mère du principe de substitution de Liskov
Barbara Liskov*1939
65/76
– IEEE J. von Neumann Medal en 2004– ACM Turing Award en 2008
• 1987– Boom du paradigme de la programmation par objets
66/76
– Boom du paradigme de la programmation par objets
– Principe• Let q(x) be a property provable about objects x
of type T. Then q(y) should be true for objects y of type S where S is a subtype of T
Barbara Liskov
– Principe• Sous-typage comportemental différent et plus fort que la notion
de sous-typage en théorie des types• En théorie des types
– Contravariance des paramètres : un paramètre peut être « réduit »
67/76
– Contravariance des paramètres : un paramètre peut être « réduit » de S à T, pour éviter une confusion de la méthode a appeler
– Covariance du type de retour : le type de retour peut être « agrandit » de T à S, pour permettre aux méthodes gabarits de fonctionner avec les méthodes surchargées
• En plus– Les pré-conditions ne peuvent plus fortes dans un sous-type– Les post-conditions ne peuvent être moins forte dans S– Le sous-type S doit conserver les invariants du type T
Barbara Liskov
– Mise en pratique dans Java• Java < 1.5
– Redéfinition /* Classe mère */ public T foo(String a, String b) {...}
68/76
/* Classe fille */ public T foo(String a, String b) {...}
– Surcharge/* Classe mère */ public T foo(String a, String b) {...} /* Classe fille */ public T foo(String a, Integer c) {...}
• Java > 1.5– Redéfinition
/* Classe mère */ public T foo(String a, String b) {...} /* Classe fille */ public S foo(String a, String b) {...}
Erich Gamma
� Erich Gamma– Né en 1961– Père des patrons de conception logiciel
– Christopher Alexander– A Pattern Language: Towns, Buildings, Construction et
l’idée de « generative patterns »– The Timeless Way of Building et l’idée de perfection en
architecture
• 1990– Les programmes par objets sont parmi nous…
Erich Gamma
� A Pattern Language: Towns, Buildings, Construction
– 253 patrons– Grammaire générative– « At the core... is the idea that people should design for
themselves their own houses, streets and communities.
71/76
themselves their own houses, streets and communities. This idea... comes simply from the observation that most of the wonderful places of the world were not made by architects but by the people »
� Design Patterns: Elements of Reusable Object-Oriented Software
– 23 patrons– Pas un langage ?– « Dynamic, highly parameterized software is harder to
understand and build than more static software »
Erich Gamma
� Design Patterns: Elements of Reusable Object-Oriented Software
72/76
Software
– Dahl-Nygaard Prizes à • Ralph Johnson• Richard Helm• Erich Gamma• † John Vlissides
Grady Booch
� Grady Booch– Né le 27 février 1955– Père de UML avec I. Jacobson et J. Rumbaugh
Grady Booch*1955
73/76
Stevens Award en 2003
– Cf. http://en.wikipedia.org/wiki/Grady_Booch
Grady Booch
� UML– Contexte
74/76
Grady Booch
– Three Amigos and their methods• Grady Booch,
– Booch Method (design)
• Ivar Jacobson
75/76
• Ivar Jacobson– Objecto Oriented Softwre Engineering, OOSE (use cases)
• James Rumbaugh– Object Modeling Technique, OMT (analysis)
• Rational Software Corporation
– UML
À suivre…
� ACM A. M. Turing Award– Cf. http://awards.acm.org/homepage.cfm?