LOG4430 : Architecture logicielle et conception avancée Yann-Gaël Guéhéneuc Cours 4 Informaticiens célèbres Département de génie informatique et de génie logiciel École Polytechnique de Montréal Guéhéneuc, 2011
Informaticiens célèbres Grady Booch Frederick Brooks Ole-Johan Dahl et Kristen Nygaard Manny Lehman Barbara Liskov Dave Parnas 2/17
Grady Booch Frederick Brooks Né le 27 février 1955 Grady Booch *1955 Père de UML avec I. Jacobson et J. Rumbaugh Stevens Award en 2003 Cf. http://en.wikipedia.org/wiki/grady_booch 3/17
Grady Booch Principe de la loi de Brooks Contexte 4/17
Grady Booch Three Amigos and their methods Grady Booch, Booch Method (design) Ivar Jacobson Objecto Oriented Softwre Engineering, OOSE (use cases) James Rumbaugh Object Modeling Technique, OMT (analysis) Rational Software Corporation UML 5/17
Frederick Brooks Frederick Brooks Né le 19 avril 1931 Père de la loi de Brooks Frederick Brooks *1931 IEEE J. von Neumann Medal en 1993 ACM Turing Award en 1999 Cf. http://en.wikipedia.org/wiki/fred_brooks 6/17
Frederick Brooks Principe de la loi de Brooks Contexte 1956 1964 Livre Gestionnaire du projet de développement du IBM OS/360 Retards dans la livraison The Mythical Man-Month: Essays on Software Engineering Principe Adding manpower to a late software project makes it later 7/17
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 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 8/17
Frederick Brooks Commentaires, solutions Brooks' Law often applies to projects that are already late 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 9/17
Frederick Brooks Critiques How to quadruple your productivity with an army of student interns 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 10/17
Dahl Nygaard Ole-Johan Dahl Né le 12 octobre 1931, 29 juin 2002 Co-créateur du paradigme des objets Ole-Johan Dahl *1931 2002 ACM Turing Award en 2001 IEEE J. von Neumann en 2002 Cf. http://www.olejohandahl.info/ Cf. http://en.wikipedia.org/wiki/ole-johan_dahl 11/17
Dahl Nygaard Kristen Nygaard Né le 27 août 1926, 10 août 2002 Co-créateur du paradigme des objets Kristen Nygaard *1926 2002 ACM Turing Award en 2001 IEEE J. von Neumann en 2002 Cf. http://www.ifi.uio.no/in_memoriam_kristen/ Cf. http://en.wikipedia.org/wiki/kristen_nygaard 12/17
Dahl Nygaard Paradigme des objets Contexte 1961 Le langage de programmation impérative Algol Classes, objets, encapsulation, héritage, polymorphisme Simula I Simula 67 13/17
Dahl Nygaard Programmation par objets Smalltalk Xerox Parc, 1970 19983 GUI Icônes WYSIWYG Souris (cf. Stanford Research Institute) Typage dynamique Réflexion Ramasse-miettes 14/17
Dahl Nygaard Programmation par objets C++ AT&T Bell Labs Bjarne Stroustrup 1980 Typage statique Héritage multiple Cf. http://www.approximity.com/ruby/ Comparison_rb_st_m_java.html 15/17
Dahl Nygaard Programmation par objets Oberon ETH Zurich Niklaus Wirth 1986 Typage statique Ramasse-miettes Vérification des bornes des tableaux 16/17
Manny Lehman Meir M. «Manny» Lehman Décédé le 29 décembre 2010 Père des lois de l évolution Manny Lehman *1925 2010 Stevens Award en 2003 Cf. http://www.doc.ic.ac.uk/news/archive/story/ manny-lehman Cf. http://www.ieeeghn.org/wiki/index.php/oral- History:Meir_Lehman 17/17
Manny Lehman Lois de l évolution logicielle Contexte 1974 IMB OS/360 et OS/370 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 18/17
Manny Lehman Huit lois 1. Continuing change: E-type systems must be continually adapted or they become progressively less satisfactory 2. Increasing complexity: As an E-type system evolves its 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 19/17
Manny Lehman Huit lois 5. 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 6. 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 20/17
Barbara Liskov Barbara Liskov Née le 7 novembre 1939 Mère du principe de substitution de Liskov Barbara Liskov *1939 IEEE J. von Neumann Medal en 2004 ACM Turing Award en 2008 Cf. http://en.wikipedia.org/wiki/ Liskov_substitution_principle 21/17
Barbara Liskov Principe de substitution de Liskov Contexte 1987 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 22/17
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 acceptant des objets de type T peut recevoir des objets de type S, où S est un sous-type de T Covariance du type de retour : le type de retour peut être «agrandit» de T à S 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 23/17
Barbara Liskov Mise en pratique dans Java Java < 1.5 Redéfinition /* Classe mère */ public T foo(string a, String b) {...} /* Classe fille */ public T foo(string a, String b) {...} Surcharge Java > 1.5 /* Classe mère */ public T foo(string a, String b) {...} /* Classe fille */ public T foo(string a, Integer c) {...} Redéfinition /* Classe mère */ public T foo(string a, String b) {...} /* Classe fille */ public S foo(string a, String b) {...} 24/17
Dave Parnas Dave Parnas Né le 10 février 1941 Père des critère de décomposition en conception modulaire Dave Parnas *1941 IEEE Computer Society 60th Anniversary Award en 2007 Cf. http://en.wikipedia.org/wiki/david_parnas 25/17
Dave Parnas Conception modulaire Contexte 1972 Langages de programmation impératifs et par objets Diagrammes de flots Décomposition des programmes en modules, classes 26/17
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 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 27/17
Dave Parnas Révision du critère en termes de Cohésion Couplage Concepts «inventés» par Larry Constantine en 1968 et publié en 1972, 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 28/17
À suivre ACM A. M. Turing Award Cf. http://awards.acm.org/homepage.cfm? awd=140 AITO Dahl-Nygaard Prize http://www.aito.org/dahl-nygaard/ IEEE J. von Neumann Medal Cf. http://www.ieee.org/about/awards/bios/ vonneumann_recipients.html 29/17