SlideShare une entreprise Scribd logo
1  sur  76
Télécharger pour lire hors ligne
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
yann-gael.gueheneuc@polytmtl.ca
Version 1.0
2013/04/22
Questions / commentaires ? Envoyez-les à
2/76
Questions / commentaires ? Envoyez-les à
yann-gael.gueheneuc@polymtl.ca
Pourquoi est-ce important ? (1/2)
« Ceux qui oublient leur histoire sont
condamnés à la revivre »
3/76
—George Santayana
dans Life of Reason, Reason
in Common Sense, Scribner’s,
1905, page 284
Pourquoi est-ce important ? (2/2)
Théorème de Pythagore
Loi d’Ohm
…
4/76
…
Vous connaissez le Prix Nobel…
… connaissez-vous le Prix Turing ?
Comment choisir ? (1/2)
Centaines de femmes et d’hommes ont fait
et font l’histoire de l’informatique
– Choix difficile, impossible
5/76
– Critères d’inclusion
• Importance historique
• Continuité historique
• Lien avec le génie logiciel
– Aucun critère d’exclusion !
Comment choisir ? (2/2)
Des suggestions d’autres informaticiens qui
devraient apparaître ici ?
– Envoyez un courriel à Yann-Gaël Guéhéneuc
6/76
yann-gael.gueheneuc@polymtl.ca
Quelques informaticien(ne)s célèbres
1936 Alan Turing
1948 Claude Elwood Shannon
1950 Grace Murray Hopper
1960 John McCarthy
1966 Frances E. Allen
1972 Dave Parnas
1974 Manny Lehman
1975 Frederick Brooks
1986 Edward Yourdon
1987 Barbara Liskov
7/76
1966 Frances E. Allen
1967 Dahl et Nygaard
1969 Charles A. R. Hoare
1970 Edgar F. Codd
1987 Barbara Liskov
1994 Erich Gamma
1997 Grady Booch
Alan Turing
Alan Mathison Turing
– Né le 23 juin 1912, décédé le 7 juin 1954
– Machines de Turing, indécidabilité, problème de
l’arrêt, théorie de la calculabilité
Alan Turing
*1912 †1954
8/76
l’arrêt, théorie de la calculabilité
Le Prix Turing est donné en son honneur
IEEE Milestone
…
– http://en.wikipedia.org/wiki/Alan_Turing
Alan Turing
1928
– Hilbert introduit le problème de l’arrêt
9/76
1931
– Gödel discute les limites des preuves et de la
calculabilité
Alan Turing
1936
– Turing introduit un concept de machines
connues désormais comme les « machines
de Turing »
10/76
de Turing »
– Turing démontre sur ses machines que le
problème de l’arrête est indécidable
Alan Turing
Problème de l’arrêt
– Premier problème démontré indécidable
– Utilisé pour démontré que d’autres problèmes
sont indécidables par réduction
11/76
sont indécidables par réduction
Alan Turing
Généralisation ≠ cas particuliers
– Preuves de correction sont possibles sur des
problèmes particuliers mais pas de façon
automatique, générale
12/76
automatique, générale
Méthodes formelles ≠ tests
– Démontrent la correction d’un algorithme
particulier
– Démontrent la présence d’erreurs
Alan Turing
1938−1945
– Travaille à Bletchley Park
• British Government Code and Cypher School
• Cinq contributions majeures
13/76
• Cinq contributions majeures
– Décoder le code Enigma de l’armée allemande
– Déduire la procédure d’initialisation des machines Enigma
par la marine allemande
– Développer une méthode statistique pour rendre la
« Bombe » plus efficace
– Développer une procédure pour décoder les
machines Lorenz SZ 40/42
– Développer un brouilleur de voix
Alan Turing
1952
– Test de Turing
1966
– ELIZA
Joseph Weizenbaum
*1923 †12008
14/76
Claude Elwood Shannon
Claude Elwood Shannon
– Né le 30 avril 1916 et décédé le
24 février 2001
– Père de la théorie de l’information
Claude Elwood Shannon
*1916 †12001
15/76
– Père de la théorie de l’information
National Medal of Science aux USA en 1966
IEEE Medal of Honor en 1966
…
– en.wikipedia.org/wiki/Claude_Shannon
Claude Elwood Shannon
1830s
– Télégraphe – Code Morse
16/76
Claude Elwood Shannon
1830s
– Une forme de compression sans pertes
17/76
Claude Elwood Shannon
1948
« The fundamental problem of communication is
that of reproducing at one point, either exactly or
18/76
that of reproducing at one point, either exactly or
approximately, a message selected at another
point. »
—Shannon, dans A Mathematical
Theory of Communication, 1948
Claude Elwood Shannon
1948
– Théorie probabiliste quantifiant le contenu
moyen d’un message en information
19/76
– Entropie
– Théorie des codes
• Compréssion
• Détection et correction des erreurs
– Toutes les « communications » électronique !
– Cryptographie
Grace Murray Hopper
Grace Murray Hopper (contre-amiral)
– Née le 9 décembre 1906, décédée le 1
janvier 1992
Grace Hopper
*1906 †1992
20/76
– Mère du premier compilateur, du terme
debugging, de COBOL et des standards
Defense Distinguished Service Medal aux USA
en 1986
– Cf. http://en.wikipedia.org/wiki/Grace_Hopper
Grace Murray Hopper
1944
– La seconde guerre mondiale est sur le point
de finir
– Les calculateurs ont fait leurs preuves…
21/76
– Les calculateurs ont fait leurs preuves…
• Dehomag D11 (Allemagne/USA, 1930s) : gestion
des fiches d’identité
• Zuse Z3 (Allemagne, 1941) : calcul du flottement
de décrochage
• Colossus Mark 1 (Grande Bretagne, 1943) :
déchiffrement de messages
• Harvard Mark I (USA, 1944) : production de tables
de calculs pour la marine de guerre
Grace Murray Hopper
Principe des
calculateurs
– Relais
électromécaniques ou
22/76
électromécaniques ou
électromagnétiques
– Deux relais actifs
rendent un troisième
relais actif
• Relais « 3 » et « 6 »
rendent relais « 9 » actifs
pour une addition 1947
Grace Murray Hopper
1950
– Les calculateurs deviennent des ordinateurs
programmables avec des langages de plus
haut-niveau que le microcode ou l’assembleur
23/76
haut-niveau que le microcode ou l’assembleur
• UNIVAC I : recensement
• A-0 (Arithmetic Language version 0)
• Chargeur ou lieur plus que compilateur
1954
– B-0 (Business Language version 0) aussi connu
comme FLOW-MATIC
Grace Murray Hopper
1959
– Conférence CODASYL (Conference on Data
Systems Languages)
– COBOL comme successeur de FLOW-MATIC
24/76
– COBOL comme successeur de FLOW-MATIC
– Proche de l’anglais
1970s
– Avocate de tests standards pour les langages et
FORTRAN en particulier
John McCarthy
John McCarthy
– Né le 4 septembre 1927
– Décédé le 24 octobre 2011
– Père de l’intelligence artificielle, de LISP, contributeur
John McCarthy
*1927 †2011
25/76
– Père de l’intelligence artificielle, de LISP, contributeur
aux systèmes à temps partagé, inventeur du « SaaS »
ACM Turing Award en 1971
National Medal of Science aux USA en 1991
– Cf. http://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)
John McCarthy
Intelligence artificielle, 1956
– Champion de la programmation logique
– Collaboration avec Marvin Minsky
26/76
Inventeur de LISP, 1960
– Recursive Functions of Symbolic
Expressions and Their Computation
by Machine, Part I, 1960
– Lambda calcul
– Ramasse-miettes
John McCarthy
Système à temps-partagé
– Multiprogrammation et multitâches
– Changement de paradigme le plus important en
informatique en 1970
DEC PDP-1, c. 1960
27/76
informatique en 1970
• Partage des ressources pour éviter la « perte de
temps de calculs »
– SaaS
• Software as a Service
• Architecture/ingénierie basée sur les services
Frances E. Allen
Frances E. Allen
– Né le 4 août 1932
– Pionnière de la compilation optimisée,
optimisation du code et parallélisation
Frances E. Allen
*1932
28/76
optimisation du code et parallélisation
AWC Augusta Ada Lovelace Award en 2002
ACM Turing Award en 2006
– Cf. http://en.wikipedia.org/wiki/Frances_E._Allen
Frances E. Allen
Avant 1966
– Depuis les années 30
• Ordinateurs programmables
– Depuis les années 50
29/76
– Depuis les années 50
• Premiers compilateurs par Grace Murray Hopper
• Langages de programmation
– FORTRAN : premier compilateur complet
– COBOL : premier langage compilé pour différentes
architectures machines (UNIVA II et RCA 501)
Frances E. Allen
Avant 1966
– En 1955
• Grammaires non-contextuelles inventées par
Noam Chomsky
30/76
Noam Chomsky
– En 1966
• LR Parsing inventé par Donald Knuth
Frances E. Allen
En 1966
– Program Optimization
• Introduction des graphes pour décrire les programmes et
permettre leurs optimisations
31/76
En 1970
– Control Flow Analysis et A Basis for Program
Optimization
• Intervalles pour les analyses du flot de contrôle
En 1974
– Interprocedural data flow analysis
• Analyses inter-procédurales de programmes complets
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
32/76
– 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
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
33/76
– 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
Dahl–Nygaard
Paradigme des objets
– Contexte
• 1961
– Le langage de programmation impérative Algol
34/76
– Le langage de programmation impérative Algol
– Classes, objets, encapsulation, héritage,
polymorphisme
• Simula I
• Simula 67
Dahl–Nygaard
Programmation par objets
– Smalltalk
• Xerox Parc, 1970–1983
– GUI
35/76
– GUI
– Icônes
– WYSIWYG
– Souris (cf. Stanford Research Institute)
• Alan Kay
• Typage dynamique
• Réflexion
• Ramasse-miettes
Dahl–Nygaard
Programmation par objets
– C++
• AT&T Bell Labs
• Bjarne Stroustrup
36/76
• Bjarne Stroustrup
• 1980
• Typage statique
• Héritage multiple
• Cf. http://www.approximity.com/ruby/
Comparison_rb_st_m_java.html
Dahl–Nygaard
Programmation par objets
– Oberon
• ETH Zurich
• Niklaus Wirth
37/76
• Niklaus Wirth
• 1986
• Typage statique
• Ramasse-miettes
• Vérification des bornes des tableaux
Charles A. R. Hoare
Sir Charles Antony Richard Hoare
– Né le 11 janvier 1934
– Inventeur de QuickSort
Sir Charles Antony Richard Hoare
*1934
38/76
– Inventeur de la logique de Hoare
–
– ACM Turing Award en 1980
– IEEE J. von Neumann en 2011
– Cf. http://en.wikipedia.org/wiki/C._A._R._Hoare
Charles A. R. Hoare
QuickSort
– Contexte
• 1960
– En Union Soviétique, Hoare travaille à l’Université d’état de
39/76
– En Union Soviétique, Hoare travaille à l’Université d’état de
Moscou en traduction automatique
– Il doit trier des mots à traduire pour les mettre en
correspondance avec des mots déjà triés et traduits
– QuickSort
• O(n × log(n)) en moyenne, O(n2) au pire
• Fonctionne bien avec un cache
Charles A. R. Hoare
Logique de Hoare
– Contexte
• 1969
– Étude de la correction d’un programme
40/76
– Étude de la correction d’un programme
– Idée originale semée par Robert Floyd en 1967
– Vérification de la correction d’un programme
• Triplet de Hoare : {P} C {Q}
• Pré-condition P, instruction C, post-condition Q
• Ensemble de règles pour des langages impératifs…
Edgar F. Codd
Edgar Frank « Ted » Codd
– Né le 23 août 1913 et décédé
le 18 avril 2003
– Père de l’algèbre relationnelle
Edgar F. Codd
*1923 †12003
41/76
– Père de l’algèbre relationnelle
ACM Turing Award en 1999
– http://en.wikipedia.org/wiki/Edgar_F._Codd
Edgar F. Codd
1960s
– Les bases de données deviennent possible
• Mémoire de stockage à accès direct
– Pas de modèles de données et de requêtes
42/76
– Pas de modèles de données et de requêtes
standards
– Deux modèles dominants
• CODASYL, modèle réseau
– Parcours « manuel »
• IBM/IMS, modèle hiérarchique
– Relations 1:n seulement
(Microsoft Windows Registry)
Edgar F. Codd
1970
– « A Relational Model of Data for Large Shared
Data Banks »
• Limites de l’approche CODASYL
Lawrence Joseph "Larry" Ellison
*1944
43/76
• Limites de l’approche CODASYL
• Introduction du concept de tables
• Introduction du concept de relation (clés)
– IBM Future Systems implante SEQUEL en 1975
– Relational Software Inc. livre Oracle en 1979
(SEQUEL devient SQL fin années 1970)
Edgar F. Codd
Aujourd’hui
– SQL est un standard
• ANSI depuis 1986
• ISO depuis 1987
44/76
• ISO depuis 1987
– Implanté par pratiquement toutes les bases de
données existantes
– Interopérabilité
• Attention aux extensions propriétaires
• Attention aux ambiguïtés
Edgar F. Codd
45/76
Edgar F. Codd
NoSQL
– http://nosql-database.org/
– http://www.10gen.com/nosql
46/76
Dave Parnas
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
Manny Lehman
*1925 †2010
51/76
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
Manny Lehman
Lois de l’évolution logicielle
– Contexte
• 1974
– IBM OS/360 et OS/370
52/76
– IBM 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
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
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 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
54/76
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
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ésion
1. 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ésion
4. 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ésion
6. 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
– Cf. http://en.wikipedia.org/wiki/
Liskov_substitution_principle
Barbara Liskov
Principe de substitution de Liskov
– Contexte
• 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
Erich Gamma
*1961
69/76
Dahl-Nygaard Prizes en 2006
– Cf. http://en.wikipedia.org/wiki/Erich_Gamma
– Cf. http://c2.com/cgi/wiki?ErichGamma
Erich Gamma
Patrons de conception logiciel
– Contexte
• 1977 et 1979
– Christopher Alexander
70/76
– 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?
awd=140
AITO Dahl-Nygaard Prize
76/76
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

Contenu connexe

En vedette

Histoire Informatique Et Hackers
Histoire Informatique Et HackersHistoire Informatique Et Hackers
Histoire Informatique Et HackersPatrick Plante
 
The imitation game and cryptography
The imitation game and cryptographyThe imitation game and cryptography
The imitation game and cryptographyAnry Lu
 
Alan Turing and the Programmable Universe (lite version)
Alan Turing and the Programmable Universe (lite version)Alan Turing and the Programmable Universe (lite version)
Alan Turing and the Programmable Universe (lite version)piero scaruffi
 
Marketing the imitation game
Marketing  the imitation gameMarketing  the imitation game
Marketing the imitation gameNaamah Hill
 
Towards a Principle-based Classification of Structural Design Smells
Towards a Principle-based Classification of Structural Design SmellsTowards a Principle-based Classification of Structural Design Smells
Towards a Principle-based Classification of Structural Design SmellsTushar Sharma
 
PHAME: Principles of Hierarchy Abstraction Modularization and Encapsulation
PHAME: Principles of Hierarchy Abstraction Modularization and EncapsulationPHAME: Principles of Hierarchy Abstraction Modularization and Encapsulation
PHAME: Principles of Hierarchy Abstraction Modularization and EncapsulationTushar Sharma
 
Tools for refactoring
Tools for refactoringTools for refactoring
Tools for refactoringTushar Sharma
 
Why care about technical debt?
Why care about technical debt?Why care about technical debt?
Why care about technical debt?Tushar Sharma
 
Infographic - Pragmatic Technical Debt Management
Infographic - Pragmatic Technical Debt ManagementInfographic - Pragmatic Technical Debt Management
Infographic - Pragmatic Technical Debt ManagementTushar Sharma
 
Pragmatic Technical Debt Management
Pragmatic Technical Debt ManagementPragmatic Technical Debt Management
Pragmatic Technical Debt ManagementTushar Sharma
 
Tools for Identifying and Addressing Technical Debt
Tools for Identifying and Addressing Technical DebtTools for Identifying and Addressing Technical Debt
Tools for Identifying and Addressing Technical DebtTushar Sharma
 
A Checklist for Design Reviews
A Checklist for Design ReviewsA Checklist for Design Reviews
A Checklist for Design ReviewsTushar Sharma
 
Refactoring for Software Design Smells: Managing Technical Debt
Refactoring for Software Design Smells: Managing Technical DebtRefactoring for Software Design Smells: Managing Technical Debt
Refactoring for Software Design Smells: Managing Technical DebtTushar Sharma
 
AsianPLoP'14: How and Why Design Patterns Impact Quality and Future Challenges
AsianPLoP'14: How and Why Design Patterns Impact Quality and Future ChallengesAsianPLoP'14: How and Why Design Patterns Impact Quality and Future Challenges
AsianPLoP'14: How and Why Design Patterns Impact Quality and Future ChallengesPtidej Team
 
Applying Design Principles in Practice
Applying Design Principles in PracticeApplying Design Principles in Practice
Applying Design Principles in PracticeTushar Sharma
 
Culture numérique, une histoire de hippies
Culture numérique, une histoire de hippiesCulture numérique, une histoire de hippies
Culture numérique, une histoire de hippieschristian poulot
 
IA, Ia grande question
IA, Ia grande questionIA, Ia grande question
IA, Ia grande questionAlain Lefebvre
 
SOLID Principles and Design Patterns
SOLID Principles and Design PatternsSOLID Principles and Design Patterns
SOLID Principles and Design PatternsGanesh Samarthyam
 

En vedette (20)

Histoire Informatique Et Hackers
Histoire Informatique Et HackersHistoire Informatique Et Hackers
Histoire Informatique Et Hackers
 
The imitation game and cryptography
The imitation game and cryptographyThe imitation game and cryptography
The imitation game and cryptography
 
Alan Turing and the Programmable Universe (lite version)
Alan Turing and the Programmable Universe (lite version)Alan Turing and the Programmable Universe (lite version)
Alan Turing and the Programmable Universe (lite version)
 
Marketing the imitation game
Marketing  the imitation gameMarketing  the imitation game
Marketing the imitation game
 
Towards a Principle-based Classification of Structural Design Smells
Towards a Principle-based Classification of Structural Design SmellsTowards a Principle-based Classification of Structural Design Smells
Towards a Principle-based Classification of Structural Design Smells
 
PHAME: Principles of Hierarchy Abstraction Modularization and Encapsulation
PHAME: Principles of Hierarchy Abstraction Modularization and EncapsulationPHAME: Principles of Hierarchy Abstraction Modularization and Encapsulation
PHAME: Principles of Hierarchy Abstraction Modularization and Encapsulation
 
Tools for refactoring
Tools for refactoringTools for refactoring
Tools for refactoring
 
Why care about technical debt?
Why care about technical debt?Why care about technical debt?
Why care about technical debt?
 
Infographic - Pragmatic Technical Debt Management
Infographic - Pragmatic Technical Debt ManagementInfographic - Pragmatic Technical Debt Management
Infographic - Pragmatic Technical Debt Management
 
Pragmatic Technical Debt Management
Pragmatic Technical Debt ManagementPragmatic Technical Debt Management
Pragmatic Technical Debt Management
 
Tools for Identifying and Addressing Technical Debt
Tools for Identifying and Addressing Technical DebtTools for Identifying and Addressing Technical Debt
Tools for Identifying and Addressing Technical Debt
 
A Checklist for Design Reviews
A Checklist for Design ReviewsA Checklist for Design Reviews
A Checklist for Design Reviews
 
Refactoring for Software Design Smells: Managing Technical Debt
Refactoring for Software Design Smells: Managing Technical DebtRefactoring for Software Design Smells: Managing Technical Debt
Refactoring for Software Design Smells: Managing Technical Debt
 
AsianPLoP'14: How and Why Design Patterns Impact Quality and Future Challenges
AsianPLoP'14: How and Why Design Patterns Impact Quality and Future ChallengesAsianPLoP'14: How and Why Design Patterns Impact Quality and Future Challenges
AsianPLoP'14: How and Why Design Patterns Impact Quality and Future Challenges
 
Applying Design Principles in Practice
Applying Design Principles in PracticeApplying Design Principles in Practice
Applying Design Principles in Practice
 
Culture numérique, une histoire de hippies
Culture numérique, une histoire de hippiesCulture numérique, une histoire de hippies
Culture numérique, une histoire de hippies
 
IA, Ia grande question
IA, Ia grande questionIA, Ia grande question
IA, Ia grande question
 
SOLID Principles and Design Patterns
SOLID Principles and Design PatternsSOLID Principles and Design Patterns
SOLID Principles and Design Patterns
 
Turing machines
Turing machinesTuring machines
Turing machines
 
Sc po2012 semaine01
Sc po2012   semaine01Sc po2012   semaine01
Sc po2012 semaine01
 

Similaire à Quelques informaticien(ne)s célèbres

Informaticien(ne)s célèbres (v1.0.2, 19/02/20)
Informaticien(ne)s célèbres (v1.0.2, 19/02/20)Informaticien(ne)s célèbres (v1.0.2, 19/02/20)
Informaticien(ne)s célèbres (v1.0.2, 19/02/20)Yann-Gaël Guéhéneuc
 
Théorie des langages - 00 - Introduction
Théorie des langages - 00 - IntroductionThéorie des langages - 00 - Introduction
Théorie des langages - 00 - IntroductionYann Caron
 
ia.ppt
ia.pptia.ppt
ia.pptNotan2
 
LLetDH_Marseille2022_V3.pdf
LLetDH_Marseille2022_V3.pdfLLetDH_Marseille2022_V3.pdf
LLetDH_Marseille2022_V3.pdfJ-Y Jeannas
 
Sciences, techniques, militaire et "information"
Sciences, techniques, militaire et "information"Sciences, techniques, militaire et "information"
Sciences, techniques, militaire et "information"Knowtex
 

Similaire à Quelques informaticien(ne)s célèbres (8)

Informaticien(ne)s célèbres (v1.0.2, 19/02/20)
Informaticien(ne)s célèbres (v1.0.2, 19/02/20)Informaticien(ne)s célèbres (v1.0.2, 19/02/20)
Informaticien(ne)s célèbres (v1.0.2, 19/02/20)
 
Théorie des langages - 00 - Introduction
Théorie des langages - 00 - IntroductionThéorie des langages - 00 - Introduction
Théorie des langages - 00 - Introduction
 
ia.ppt
ia.pptia.ppt
ia.ppt
 
ia.ppt
ia.pptia.ppt
ia.ppt
 
historique de l'informatique
historique de l'informatiquehistorique de l'informatique
historique de l'informatique
 
LLetDH_Marseille2022_V3.pdf
LLetDH_Marseille2022_V3.pdfLLetDH_Marseille2022_V3.pdf
LLetDH_Marseille2022_V3.pdf
 
Ackerman04
Ackerman04Ackerman04
Ackerman04
 
Sciences, techniques, militaire et "information"
Sciences, techniques, militaire et "information"Sciences, techniques, militaire et "information"
Sciences, techniques, militaire et "information"
 

Plus de Yann-Gaël Guéhéneuc

Advice for writing a NSERC Discovery grant application v0.5
Advice for writing a NSERC Discovery grant application v0.5Advice for writing a NSERC Discovery grant application v0.5
Advice for writing a NSERC Discovery grant application v0.5Yann-Gaël Guéhéneuc
 
Ptidej Architecture, Design, and Implementation in Action v2.1
Ptidej Architecture, Design, and Implementation in Action v2.1Ptidej Architecture, Design, and Implementation in Action v2.1
Ptidej Architecture, Design, and Implementation in Action v2.1Yann-Gaël Guéhéneuc
 
Evolution and Examples of Java Features, from Java 1.7 to Java 22
Evolution and Examples of Java Features, from Java 1.7 to Java 22Evolution and Examples of Java Features, from Java 1.7 to Java 22
Evolution and Examples of Java Features, from Java 1.7 to Java 22Yann-Gaël Guéhéneuc
 
Consequences and Principles of Software Quality v0.3
Consequences and Principles of Software Quality v0.3Consequences and Principles of Software Quality v0.3
Consequences and Principles of Software Quality v0.3Yann-Gaël Guéhéneuc
 
Some Pitfalls with Python and Their Possible Solutions v0.9
Some Pitfalls with Python and Their Possible Solutions v0.9Some Pitfalls with Python and Their Possible Solutions v0.9
Some Pitfalls with Python and Their Possible Solutions v0.9Yann-Gaël Guéhéneuc
 
An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...
An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...
An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...Yann-Gaël Guéhéneuc
 
An Explanation of the Halting Problem and Its Consequences
An Explanation of the Halting Problem and Its ConsequencesAn Explanation of the Halting Problem and Its Consequences
An Explanation of the Halting Problem and Its ConsequencesYann-Gaël Guéhéneuc
 
On Java Generics, History, Use, Caveats v1.1
On Java Generics, History, Use, Caveats v1.1On Java Generics, History, Use, Caveats v1.1
On Java Generics, History, Use, Caveats v1.1Yann-Gaël Guéhéneuc
 
On Reflection in OO Programming Languages v1.6
On Reflection in OO Programming Languages v1.6On Reflection in OO Programming Languages v1.6
On Reflection in OO Programming Languages v1.6Yann-Gaël Guéhéneuc
 

Plus de Yann-Gaël Guéhéneuc (20)

Advice for writing a NSERC Discovery grant application v0.5
Advice for writing a NSERC Discovery grant application v0.5Advice for writing a NSERC Discovery grant application v0.5
Advice for writing a NSERC Discovery grant application v0.5
 
Ptidej Architecture, Design, and Implementation in Action v2.1
Ptidej Architecture, Design, and Implementation in Action v2.1Ptidej Architecture, Design, and Implementation in Action v2.1
Ptidej Architecture, Design, and Implementation in Action v2.1
 
Evolution and Examples of Java Features, from Java 1.7 to Java 22
Evolution and Examples of Java Features, from Java 1.7 to Java 22Evolution and Examples of Java Features, from Java 1.7 to Java 22
Evolution and Examples of Java Features, from Java 1.7 to Java 22
 
Consequences and Principles of Software Quality v0.3
Consequences and Principles of Software Quality v0.3Consequences and Principles of Software Quality v0.3
Consequences and Principles of Software Quality v0.3
 
Some Pitfalls with Python and Their Possible Solutions v0.9
Some Pitfalls with Python and Their Possible Solutions v0.9Some Pitfalls with Python and Their Possible Solutions v0.9
Some Pitfalls with Python and Their Possible Solutions v0.9
 
An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...
An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...
An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...
 
An Explanation of the Halting Problem and Its Consequences
An Explanation of the Halting Problem and Its ConsequencesAn Explanation of the Halting Problem and Its Consequences
An Explanation of the Halting Problem and Its Consequences
 
Are CPUs VMs Like Any Others? v1.0
Are CPUs VMs Like Any Others? v1.0Are CPUs VMs Like Any Others? v1.0
Are CPUs VMs Like Any Others? v1.0
 
Well-known Computer Scientists v1.0.2
Well-known Computer Scientists v1.0.2Well-known Computer Scientists v1.0.2
Well-known Computer Scientists v1.0.2
 
On Java Generics, History, Use, Caveats v1.1
On Java Generics, History, Use, Caveats v1.1On Java Generics, History, Use, Caveats v1.1
On Java Generics, History, Use, Caveats v1.1
 
On Reflection in OO Programming Languages v1.6
On Reflection in OO Programming Languages v1.6On Reflection in OO Programming Languages v1.6
On Reflection in OO Programming Languages v1.6
 
ICSOC'21
ICSOC'21ICSOC'21
ICSOC'21
 
Vissoft21.ppt
Vissoft21.pptVissoft21.ppt
Vissoft21.ppt
 
Service computation20.ppt
Service computation20.pptService computation20.ppt
Service computation20.ppt
 
Serp4 iot20.ppt
Serp4 iot20.pptSerp4 iot20.ppt
Serp4 iot20.ppt
 
Msr20.ppt
Msr20.pptMsr20.ppt
Msr20.ppt
 
Iwesep19.ppt
Iwesep19.pptIwesep19.ppt
Iwesep19.ppt
 
Icsoc20.ppt
Icsoc20.pptIcsoc20.ppt
Icsoc20.ppt
 
Icsoc18.ppt
Icsoc18.pptIcsoc18.ppt
Icsoc18.ppt
 
Icsm20.ppt
Icsm20.pptIcsm20.ppt
Icsm20.ppt
 

Quelques informaticien(ne)s célèbres

  • 1. 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 yann-gael.gueheneuc@polytmtl.ca Version 1.0 2013/04/22
  • 2. Questions / commentaires ? Envoyez-les à 2/76 Questions / commentaires ? Envoyez-les à yann-gael.gueheneuc@polymtl.ca
  • 3. Pourquoi est-ce important ? (1/2) « Ceux qui oublient leur histoire sont condamnés à la revivre » 3/76 —George Santayana dans Life of Reason, Reason in Common Sense, Scribner’s, 1905, page 284
  • 4. Pourquoi est-ce important ? (2/2) Théorème de Pythagore Loi d’Ohm … 4/76 … Vous connaissez le Prix Nobel… … connaissez-vous le Prix Turing ?
  • 5. Comment choisir ? (1/2) Centaines de femmes et d’hommes ont fait et font l’histoire de l’informatique – Choix difficile, impossible 5/76 – Critères d’inclusion • Importance historique • Continuité historique • Lien avec le génie logiciel – Aucun critère d’exclusion !
  • 6. Comment choisir ? (2/2) Des suggestions d’autres informaticiens qui devraient apparaître ici ? – Envoyez un courriel à Yann-Gaël Guéhéneuc 6/76 yann-gael.gueheneuc@polymtl.ca
  • 7. Quelques informaticien(ne)s célèbres 1936 Alan Turing 1948 Claude Elwood Shannon 1950 Grace Murray Hopper 1960 John McCarthy 1966 Frances E. Allen 1972 Dave Parnas 1974 Manny Lehman 1975 Frederick Brooks 1986 Edward Yourdon 1987 Barbara Liskov 7/76 1966 Frances E. Allen 1967 Dahl et Nygaard 1969 Charles A. R. Hoare 1970 Edgar F. Codd 1987 Barbara Liskov 1994 Erich Gamma 1997 Grady Booch
  • 8. Alan Turing Alan Mathison Turing – Né le 23 juin 1912, décédé le 7 juin 1954 – Machines de Turing, indécidabilité, problème de l’arrêt, théorie de la calculabilité Alan Turing *1912 †1954 8/76 l’arrêt, théorie de la calculabilité Le Prix Turing est donné en son honneur IEEE Milestone … – http://en.wikipedia.org/wiki/Alan_Turing
  • 9. Alan Turing 1928 – Hilbert introduit le problème de l’arrêt 9/76 1931 – Gödel discute les limites des preuves et de la calculabilité
  • 10. Alan Turing 1936 – Turing introduit un concept de machines connues désormais comme les « machines de Turing » 10/76 de Turing » – Turing démontre sur ses machines que le problème de l’arrête est indécidable
  • 11. Alan Turing Problème de l’arrêt – Premier problème démontré indécidable – Utilisé pour démontré que d’autres problèmes sont indécidables par réduction 11/76 sont indécidables par réduction
  • 12. Alan Turing Généralisation ≠ cas particuliers – Preuves de correction sont possibles sur des problèmes particuliers mais pas de façon automatique, générale 12/76 automatique, générale Méthodes formelles ≠ tests – Démontrent la correction d’un algorithme particulier – Démontrent la présence d’erreurs
  • 13. Alan Turing 1938−1945 – Travaille à Bletchley Park • British Government Code and Cypher School • Cinq contributions majeures 13/76 • Cinq contributions majeures – Décoder le code Enigma de l’armée allemande – Déduire la procédure d’initialisation des machines Enigma par la marine allemande – Développer une méthode statistique pour rendre la « Bombe » plus efficace – Développer une procédure pour décoder les machines Lorenz SZ 40/42 – Développer un brouilleur de voix
  • 14. Alan Turing 1952 – Test de Turing 1966 – ELIZA Joseph Weizenbaum *1923 †12008 14/76
  • 15. Claude Elwood Shannon Claude Elwood Shannon – Né le 30 avril 1916 et décédé le 24 février 2001 – Père de la théorie de l’information Claude Elwood Shannon *1916 †12001 15/76 – Père de la théorie de l’information National Medal of Science aux USA en 1966 IEEE Medal of Honor en 1966 … – en.wikipedia.org/wiki/Claude_Shannon
  • 16. Claude Elwood Shannon 1830s – Télégraphe – Code Morse 16/76
  • 17. Claude Elwood Shannon 1830s – Une forme de compression sans pertes 17/76
  • 18. Claude Elwood Shannon 1948 « The fundamental problem of communication is that of reproducing at one point, either exactly or 18/76 that of reproducing at one point, either exactly or approximately, a message selected at another point. » —Shannon, dans A Mathematical Theory of Communication, 1948
  • 19. Claude Elwood Shannon 1948 – Théorie probabiliste quantifiant le contenu moyen d’un message en information 19/76 – Entropie – Théorie des codes • Compréssion • Détection et correction des erreurs – Toutes les « communications » électronique ! – Cryptographie
  • 20. Grace Murray Hopper Grace Murray Hopper (contre-amiral) – Née le 9 décembre 1906, décédée le 1 janvier 1992 Grace Hopper *1906 †1992 20/76 – Mère du premier compilateur, du terme debugging, de COBOL et des standards Defense Distinguished Service Medal aux USA en 1986 – Cf. http://en.wikipedia.org/wiki/Grace_Hopper
  • 21. Grace Murray Hopper 1944 – La seconde guerre mondiale est sur le point de finir – Les calculateurs ont fait leurs preuves… 21/76 – Les calculateurs ont fait leurs preuves… • Dehomag D11 (Allemagne/USA, 1930s) : gestion des fiches d’identité • Zuse Z3 (Allemagne, 1941) : calcul du flottement de décrochage • Colossus Mark 1 (Grande Bretagne, 1943) : déchiffrement de messages • Harvard Mark I (USA, 1944) : production de tables de calculs pour la marine de guerre
  • 22. Grace Murray Hopper Principe des calculateurs – Relais électromécaniques ou 22/76 électromécaniques ou électromagnétiques – Deux relais actifs rendent un troisième relais actif • Relais « 3 » et « 6 » rendent relais « 9 » actifs pour une addition 1947
  • 23. Grace Murray Hopper 1950 – Les calculateurs deviennent des ordinateurs programmables avec des langages de plus haut-niveau que le microcode ou l’assembleur 23/76 haut-niveau que le microcode ou l’assembleur • UNIVAC I : recensement • A-0 (Arithmetic Language version 0) • Chargeur ou lieur plus que compilateur 1954 – B-0 (Business Language version 0) aussi connu comme FLOW-MATIC
  • 24. Grace Murray Hopper 1959 – Conférence CODASYL (Conference on Data Systems Languages) – COBOL comme successeur de FLOW-MATIC 24/76 – COBOL comme successeur de FLOW-MATIC – Proche de l’anglais 1970s – Avocate de tests standards pour les langages et FORTRAN en particulier
  • 25. John McCarthy John McCarthy – Né le 4 septembre 1927 – Décédé le 24 octobre 2011 – Père de l’intelligence artificielle, de LISP, contributeur John McCarthy *1927 †2011 25/76 – Père de l’intelligence artificielle, de LISP, contributeur aux systèmes à temps partagé, inventeur du « SaaS » ACM Turing Award en 1971 National Medal of Science aux USA en 1991 – Cf. http://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)
  • 26. John McCarthy Intelligence artificielle, 1956 – Champion de la programmation logique – Collaboration avec Marvin Minsky 26/76 Inventeur de LISP, 1960 – Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I, 1960 – Lambda calcul – Ramasse-miettes
  • 27. John McCarthy Système à temps-partagé – Multiprogrammation et multitâches – Changement de paradigme le plus important en informatique en 1970 DEC PDP-1, c. 1960 27/76 informatique en 1970 • Partage des ressources pour éviter la « perte de temps de calculs » – SaaS • Software as a Service • Architecture/ingénierie basée sur les services
  • 28. Frances E. Allen Frances E. Allen – Né le 4 août 1932 – Pionnière de la compilation optimisée, optimisation du code et parallélisation Frances E. Allen *1932 28/76 optimisation du code et parallélisation AWC Augusta Ada Lovelace Award en 2002 ACM Turing Award en 2006 – Cf. http://en.wikipedia.org/wiki/Frances_E._Allen
  • 29. Frances E. Allen Avant 1966 – Depuis les années 30 • Ordinateurs programmables – Depuis les années 50 29/76 – Depuis les années 50 • Premiers compilateurs par Grace Murray Hopper • Langages de programmation – FORTRAN : premier compilateur complet – COBOL : premier langage compilé pour différentes architectures machines (UNIVA II et RCA 501)
  • 30. Frances E. Allen Avant 1966 – En 1955 • Grammaires non-contextuelles inventées par Noam Chomsky 30/76 Noam Chomsky – En 1966 • LR Parsing inventé par Donald Knuth
  • 31. Frances E. Allen En 1966 – Program Optimization • Introduction des graphes pour décrire les programmes et permettre leurs optimisations 31/76 En 1970 – Control Flow Analysis et A Basis for Program Optimization • Intervalles pour les analyses du flot de contrôle En 1974 – Interprocedural data flow analysis • Analyses inter-procédurales de programmes complets
  • 32. 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 32/76 – 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
  • 33. 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 33/76 – 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
  • 34. Dahl–Nygaard Paradigme des objets – Contexte • 1961 – Le langage de programmation impérative Algol 34/76 – Le langage de programmation impérative Algol – Classes, objets, encapsulation, héritage, polymorphisme • Simula I • Simula 67
  • 35. Dahl–Nygaard Programmation par objets – Smalltalk • Xerox Parc, 1970–1983 – GUI 35/76 – GUI – Icônes – WYSIWYG – Souris (cf. Stanford Research Institute) • Alan Kay • Typage dynamique • Réflexion • Ramasse-miettes
  • 36. Dahl–Nygaard Programmation par objets – C++ • AT&T Bell Labs • Bjarne Stroustrup 36/76 • Bjarne Stroustrup • 1980 • Typage statique • Héritage multiple • Cf. http://www.approximity.com/ruby/ Comparison_rb_st_m_java.html
  • 37. Dahl–Nygaard Programmation par objets – Oberon • ETH Zurich • Niklaus Wirth 37/76 • Niklaus Wirth • 1986 • Typage statique • Ramasse-miettes • Vérification des bornes des tableaux
  • 38. Charles A. R. Hoare Sir Charles Antony Richard Hoare – Né le 11 janvier 1934 – Inventeur de QuickSort Sir Charles Antony Richard Hoare *1934 38/76 – Inventeur de la logique de Hoare – – ACM Turing Award en 1980 – IEEE J. von Neumann en 2011 – Cf. http://en.wikipedia.org/wiki/C._A._R._Hoare
  • 39. Charles A. R. Hoare QuickSort – Contexte • 1960 – En Union Soviétique, Hoare travaille à l’Université d’état de 39/76 – En Union Soviétique, Hoare travaille à l’Université d’état de Moscou en traduction automatique – Il doit trier des mots à traduire pour les mettre en correspondance avec des mots déjà triés et traduits – QuickSort • O(n × log(n)) en moyenne, O(n2) au pire • Fonctionne bien avec un cache
  • 40. Charles A. R. Hoare Logique de Hoare – Contexte • 1969 – Étude de la correction d’un programme 40/76 – Étude de la correction d’un programme – Idée originale semée par Robert Floyd en 1967 – Vérification de la correction d’un programme • Triplet de Hoare : {P} C {Q} • Pré-condition P, instruction C, post-condition Q • Ensemble de règles pour des langages impératifs…
  • 41. Edgar F. Codd Edgar Frank « Ted » Codd – Né le 23 août 1913 et décédé le 18 avril 2003 – Père de l’algèbre relationnelle Edgar F. Codd *1923 †12003 41/76 – Père de l’algèbre relationnelle ACM Turing Award en 1999 – http://en.wikipedia.org/wiki/Edgar_F._Codd
  • 42. Edgar F. Codd 1960s – Les bases de données deviennent possible • Mémoire de stockage à accès direct – Pas de modèles de données et de requêtes 42/76 – Pas de modèles de données et de requêtes standards – Deux modèles dominants • CODASYL, modèle réseau – Parcours « manuel » • IBM/IMS, modèle hiérarchique – Relations 1:n seulement (Microsoft Windows Registry)
  • 43. Edgar F. Codd 1970 – « A Relational Model of Data for Large Shared Data Banks » • Limites de l’approche CODASYL Lawrence Joseph "Larry" Ellison *1944 43/76 • Limites de l’approche CODASYL • Introduction du concept de tables • Introduction du concept de relation (clés) – IBM Future Systems implante SEQUEL en 1975 – Relational Software Inc. livre Oracle en 1979 (SEQUEL devient SQL fin années 1970)
  • 44. Edgar F. Codd Aujourd’hui – SQL est un standard • ANSI depuis 1986 • ISO depuis 1987 44/76 • ISO depuis 1987 – Implanté par pratiquement toutes les bases de données existantes – Interopérabilité • Attention aux extensions propriétaires • Attention aux ambiguïtés
  • 46. Edgar F. Codd NoSQL – http://nosql-database.org/ – http://www.10gen.com/nosql 46/76
  • 47. Dave Parnas 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
  • 48. 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…
  • 49. 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
  • 50. 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
  • 51. 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 51/76 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
  • 52. Manny Lehman Lois de l’évolution logicielle – Contexte • 1974 – IBM OS/360 et OS/370 52/76 – IBM 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
  • 53. 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 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
  • 54. 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 54/76 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
  • 55. 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
  • 56. 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
  • 57. 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
  • 58. 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
  • 59. 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
  • 60. 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
  • 61. 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
  • 62. Edward Yourdon – Critère de cohésion 1. 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.
  • 63. Edward Yourdon – Critère de cohésion 4. 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.
  • 64. Edward Yourdon – Critère de cohésion 6. 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
  • 65. 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 – Cf. http://en.wikipedia.org/wiki/ Liskov_substitution_principle
  • 66. Barbara Liskov Principe de substitution de Liskov – Contexte • 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
  • 67. 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
  • 68. 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) {...}
  • 69. Erich Gamma Erich Gamma – Né en 1961 – Père des patrons de conception logiciel Erich Gamma *1961 69/76 Dahl-Nygaard Prizes en 2006 – Cf. http://en.wikipedia.org/wiki/Erich_Gamma – Cf. http://c2.com/cgi/wiki?ErichGamma
  • 70. Erich Gamma Patrons de conception logiciel – Contexte • 1977 et 1979 – Christopher Alexander 70/76 – 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…
  • 71. 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 »
  • 72. Erich Gamma Design Patterns: Elements of Reusable Object-Oriented Software 72/76 Software – Dahl-Nygaard Prizes à • Ralph Johnson • Richard Helm • Erich Gamma • † John Vlissides
  • 73. 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
  • 75. 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
  • 76. À suivre… ACM A. M. Turing Award – Cf. http://awards.acm.org/homepage.cfm? awd=140 AITO Dahl-Nygaard Prize 76/76 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