10 personnages importants et pourtant peu connus de l'histoire de l'informatiqueAlain Lefebvre
L'histoire de l'informatique est pleine de héros et de personnages riches et célèbres... Mais toutes ses célébrités sont-elles les seules à vraiment avoir écrit cette histoire ?
Bien sûr que non !
Il a plein de héros méconnus qui ont contribué de manière importante, souvent décisive à cette histoire. En voici 10. Une sélection forcément trop restreinte mais que j'espère tout de même significative.
Retrouvez le livre sur l'histoire de l'informatique à http://www.histoireinformatique.com/
Alan Mathison Turing,est un mathématicien britannique, pionnier de l’informatique moderne et décrypteur génial des codes secrets nazis (Enigma).
Il a également été condamné pour homosexualité en 1952.
Ce cours introduit à l'intelligence artificielle. La première partie du cours présente et définit ce qu'est l'intelligence et décrit les notions d'agent rationnel et d'environnement et leurs propriétés. Ces deux concepts permettent d'offrir un cadre de réflexion sur l'intelligence. La fin de la première partie présente les neufs formes d'intelligence selon Howard Gardner. La seconde partie du cours présente et définit l'intelligence artificielle, initiée par Marvin Minsky et John McCarthy au MIT. Elle présente également le test de Turing, test permettant de déterminer si une machine peut penser. Cette partie se termine en présentant les six grands domaines de l'intelligence artificielle.
The document provides biographical information about several influential computer scientists:
- Alan Turing (1912-1954) introduced Turing machines and proved some important theorems about computability and algorithms.
- Claude Shannon (1916-2001) established information theory and laid the foundations for digital communication.
- Grace Hopper (1906-1992) developed one of the first compilers and popularized the idea of programming languages, coining the term "debugging."
- John McCarthy (1927-2011) pioneered artificial intelligence and time-sharing systems, inventing the Lisp programming language.
On Reflection in OO Programming Languages (v1.5.2, 14/04/14)Yann-Gaël Guéhéneuc
A tutorial on reflection, with a particular emphasis on Java, with comparisons with C++, Python, and Smalltalk working examples.
The tutorial focuses on four common problems:
- Avoid using instanceof when code must bypass the compiler and virtual machine’s choice of the method to call.
- Create external, user-defined pieces of code loaded, used, and unloaded at run-time.
- Translate data structures or object states into a format that can be stored (file, network...).
- Monitor the execution of a program to understand its behaviour, and measure its space and time complexity.
It shows working examples of Java, Smalltalk, and C++ code solving the four common problems through four scenarios:
- Scenario 1: invoke an arbitrary method on an object (see the problems with instanceof and plugins).
- Scenario 2: access the complete (including private) state of an object (see the problem with serialisation).
- Scenario 3: count the number of instances of a class created at runtime (see the problem with debugging/profiling).
- Scenario 4: patch the method of a class to change its behaviour (see the problem with patching).
It also discusses the different kinds of interconnections among objects that are available in common programming languages (linking, forking, subclassing, inter-process communication, and dynamic loading/invoking), some theories about reflection, and specifically the class-loading mechanism of Java and the inheritance mechanism of Python.
2016_Huguet_l1ICC11_séquence 4 vous avez dit télécommunications?François Huguet
L’objectif d’un tel cycle de cours magistraux est d’aborder plusieurs problématiques de l’Internet à l’heure actuelle et de vous aider à construire un regard critique sur ces technologies informationnelles.
10 personnages importants et pourtant peu connus de l'histoire de l'informatiqueAlain Lefebvre
L'histoire de l'informatique est pleine de héros et de personnages riches et célèbres... Mais toutes ses célébrités sont-elles les seules à vraiment avoir écrit cette histoire ?
Bien sûr que non !
Il a plein de héros méconnus qui ont contribué de manière importante, souvent décisive à cette histoire. En voici 10. Une sélection forcément trop restreinte mais que j'espère tout de même significative.
Retrouvez le livre sur l'histoire de l'informatique à http://www.histoireinformatique.com/
Alan Mathison Turing,est un mathématicien britannique, pionnier de l’informatique moderne et décrypteur génial des codes secrets nazis (Enigma).
Il a également été condamné pour homosexualité en 1952.
Ce cours introduit à l'intelligence artificielle. La première partie du cours présente et définit ce qu'est l'intelligence et décrit les notions d'agent rationnel et d'environnement et leurs propriétés. Ces deux concepts permettent d'offrir un cadre de réflexion sur l'intelligence. La fin de la première partie présente les neufs formes d'intelligence selon Howard Gardner. La seconde partie du cours présente et définit l'intelligence artificielle, initiée par Marvin Minsky et John McCarthy au MIT. Elle présente également le test de Turing, test permettant de déterminer si une machine peut penser. Cette partie se termine en présentant les six grands domaines de l'intelligence artificielle.
The document provides biographical information about several influential computer scientists:
- Alan Turing (1912-1954) introduced Turing machines and proved some important theorems about computability and algorithms.
- Claude Shannon (1916-2001) established information theory and laid the foundations for digital communication.
- Grace Hopper (1906-1992) developed one of the first compilers and popularized the idea of programming languages, coining the term "debugging."
- John McCarthy (1927-2011) pioneered artificial intelligence and time-sharing systems, inventing the Lisp programming language.
On Reflection in OO Programming Languages (v1.5.2, 14/04/14)Yann-Gaël Guéhéneuc
A tutorial on reflection, with a particular emphasis on Java, with comparisons with C++, Python, and Smalltalk working examples.
The tutorial focuses on four common problems:
- Avoid using instanceof when code must bypass the compiler and virtual machine’s choice of the method to call.
- Create external, user-defined pieces of code loaded, used, and unloaded at run-time.
- Translate data structures or object states into a format that can be stored (file, network...).
- Monitor the execution of a program to understand its behaviour, and measure its space and time complexity.
It shows working examples of Java, Smalltalk, and C++ code solving the four common problems through four scenarios:
- Scenario 1: invoke an arbitrary method on an object (see the problems with instanceof and plugins).
- Scenario 2: access the complete (including private) state of an object (see the problem with serialisation).
- Scenario 3: count the number of instances of a class created at runtime (see the problem with debugging/profiling).
- Scenario 4: patch the method of a class to change its behaviour (see the problem with patching).
It also discusses the different kinds of interconnections among objects that are available in common programming languages (linking, forking, subclassing, inter-process communication, and dynamic loading/invoking), some theories about reflection, and specifically the class-loading mechanism of Java and the inheritance mechanism of Python.
2016_Huguet_l1ICC11_séquence 4 vous avez dit télécommunications?François Huguet
L’objectif d’un tel cycle de cours magistraux est d’aborder plusieurs problématiques de l’Internet à l’heure actuelle et de vous aider à construire un regard critique sur ces technologies informationnelles.
This document discusses Alan Turing and his contributions to cryptography including developing the bombe machine which helped crack the German Enigma code during World War 2. It provides biographical details on Turing such as his birth year, work developing the first bombe in 1940, and later chemical castration due to his homosexuality. It also describes the Enigma machine used by Germans for encryption, how it worked, and some of the techniques used by Turing and others to crack the codes including finding common words or phrases in messages.
Alan Turing and the Programmable Universe (lite version)piero scaruffi
Alan Turing, the cultural context of his world, and what would Turing say of today's high-tech world. See also www.scaruffi.com/singular for presentations on AI and the Singularity.
The document discusses the marketing techniques used for the film "The Imitation Game". It lists the main cast which included Benedict Cumberbatch and Keira Knightly. Some of the techniques used to promote the film were posters, trailers, teasers, and capitalizing on big name actors. Using Benedict Cumberbatch helped attract a wider audience as he is a major star. Clever marketing also included quizzes and "easter eggs" that related to the film's subject of code breaking. The film was successful due to its national distribution across England and its use of ads, prominent actors, and promotional materials to reach a broad audience.
Towards a Principle-based Classification of Structural Design SmellsTushar Sharma
This is our paper published in JOT (Journal of Object Technology) based on our initial work. In this paper, we present our (early) catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
This document provides a non-exhaustive list of commonly available tools - along with their categories, supported languages, license, and web-site link - that can help in the process of refactoring to repay technical debt.
The document discusses technical debt in software development. Technical debt occurs when developers take shortcuts or make suboptimal design decisions to quickly deliver features. This debt accumulates interest over time as more changes are made, making the software harder to maintain. If left unchecked, technical debt can lead to "technical bankruptcy" where the cost of change becomes prohibitively high. Common causes of technical debt include schedule pressure, lack of skilled designers, and inadequate design principles and refactoring. Managing technical debt involves increasing awareness of it, detecting and repaying existing debt, and preventing further accumulation through monitoring and periodic repayment.
Technical debt in a software system not only impacts the productivity of the team but also compromises the external product quality. Technical debt needs to be managed pragmatically to ensure discipline, value, and quality.
This presentation provides a brief overview about technical debt including its definition, types, and dimensions. Further, the presentation discusses a couple of ways to prevent technical debt to accumulate. Finally, the presentation reveals a few pragmatic strategies to repay technical debt in real-world settings.
Tools for Identifying and Addressing Technical DebtTushar Sharma
This presentation catalogs a few tools that are useful for identifying and addressing technical debt. The debt identification tools include smell detection tools and metrics tools. The debt addressing category includes refactoring tools and comprehension tools.
Manual design reviews are effective in finding smells in design. Use this checklist when you are reviewing UML diagrams (mainly class diagrams) or code to find smells in your software.
Refactoring for Software Design Smells: Managing Technical DebtTushar Sharma
Technical Debt is a major concern today for huge and long-life maintenance projects. You can address technical debt in your project by identifying smells in your project and refactoring them. We have classified and cataloged 25 commonly-occurring design smells according to the design principles they violate.
AsianPLoP'14: How and Why Design Patterns Impact Quality and Future ChallengesPtidej Team
The document discusses schemas, design patterns, and how patterns relate to schemas and learning. It notes that schemas are mental representations that allow people to recognize patterns. Design patterns aim to capture best practices and reusable solutions to common problems. When patterns are reused, it activates existing schemas and can lead to better design through experiences being shared. The document explores how pattern reuse relates to theories of schema and learning, and how patterns can be codified and shared between designers based on these theories.
The tutorial titled "Applying design principles in practice" was presented in ISEC (India Software Engg Conference) on 18th Feb 2015 in Bengaluru by Tushar Sharma, Ganesh Samarthyam, and Girish Suryanarayana.
Une révolution socio-technico-culturelle, quelques dates et personnalités clefs.
Où l'on parle de bikinis et de bombe atomique, de LSD et de l'armée, de hippies allant à Davos, d'un Google en papier, de l'influence des ingénieurs français dans la création de l'Internet et du premier ordinateur personnel…
The document discusses software design principles and patterns, including the SOLID principles, design patterns like factory method and abstract factory, code smells like duplicated code and feature envy, and refactoring techniques to address smells like extracting classes and collapsing hierarchies. It provides examples of applying principles and patterns to real code and suggests design is key to creating high-quality, maintainable software.
Turing Machines are a simple mathematical model of a general purpose computer invented by Alan Turing in 1936. A Turing Machine consists of an infinite tape divided into cells, a head that reads and writes symbols on the tape, a finite set of states, and transition rules determining the behavior of the machine. The machine operates by reading a symbol on the tape, updating the symbol according to its transition rules, moving the head left or right, and transitioning to a new state. Turing Machines can simulate any algorithm and are capable of performing any calculation that can be performed by any computing machine.
Théorie des langages - 00 - IntroductionYann Caron
Cours de théorie des langages, théorie de la compilation, techniques de compilations et paradigmes de programmation que je dispense aux Ingé 2 et 3 à l’École National des Sciences Géographiques de Paris.
This document discusses Alan Turing and his contributions to cryptography including developing the bombe machine which helped crack the German Enigma code during World War 2. It provides biographical details on Turing such as his birth year, work developing the first bombe in 1940, and later chemical castration due to his homosexuality. It also describes the Enigma machine used by Germans for encryption, how it worked, and some of the techniques used by Turing and others to crack the codes including finding common words or phrases in messages.
Alan Turing and the Programmable Universe (lite version)piero scaruffi
Alan Turing, the cultural context of his world, and what would Turing say of today's high-tech world. See also www.scaruffi.com/singular for presentations on AI and the Singularity.
The document discusses the marketing techniques used for the film "The Imitation Game". It lists the main cast which included Benedict Cumberbatch and Keira Knightly. Some of the techniques used to promote the film were posters, trailers, teasers, and capitalizing on big name actors. Using Benedict Cumberbatch helped attract a wider audience as he is a major star. Clever marketing also included quizzes and "easter eggs" that related to the film's subject of code breaking. The film was successful due to its national distribution across England and its use of ads, prominent actors, and promotional materials to reach a broad audience.
Towards a Principle-based Classification of Structural Design SmellsTushar Sharma
This is our paper published in JOT (Journal of Object Technology) based on our initial work. In this paper, we present our (early) catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
This document provides a non-exhaustive list of commonly available tools - along with their categories, supported languages, license, and web-site link - that can help in the process of refactoring to repay technical debt.
The document discusses technical debt in software development. Technical debt occurs when developers take shortcuts or make suboptimal design decisions to quickly deliver features. This debt accumulates interest over time as more changes are made, making the software harder to maintain. If left unchecked, technical debt can lead to "technical bankruptcy" where the cost of change becomes prohibitively high. Common causes of technical debt include schedule pressure, lack of skilled designers, and inadequate design principles and refactoring. Managing technical debt involves increasing awareness of it, detecting and repaying existing debt, and preventing further accumulation through monitoring and periodic repayment.
Technical debt in a software system not only impacts the productivity of the team but also compromises the external product quality. Technical debt needs to be managed pragmatically to ensure discipline, value, and quality.
This presentation provides a brief overview about technical debt including its definition, types, and dimensions. Further, the presentation discusses a couple of ways to prevent technical debt to accumulate. Finally, the presentation reveals a few pragmatic strategies to repay technical debt in real-world settings.
Tools for Identifying and Addressing Technical DebtTushar Sharma
This presentation catalogs a few tools that are useful for identifying and addressing technical debt. The debt identification tools include smell detection tools and metrics tools. The debt addressing category includes refactoring tools and comprehension tools.
Manual design reviews are effective in finding smells in design. Use this checklist when you are reviewing UML diagrams (mainly class diagrams) or code to find smells in your software.
Refactoring for Software Design Smells: Managing Technical DebtTushar Sharma
Technical Debt is a major concern today for huge and long-life maintenance projects. You can address technical debt in your project by identifying smells in your project and refactoring them. We have classified and cataloged 25 commonly-occurring design smells according to the design principles they violate.
AsianPLoP'14: How and Why Design Patterns Impact Quality and Future ChallengesPtidej Team
The document discusses schemas, design patterns, and how patterns relate to schemas and learning. It notes that schemas are mental representations that allow people to recognize patterns. Design patterns aim to capture best practices and reusable solutions to common problems. When patterns are reused, it activates existing schemas and can lead to better design through experiences being shared. The document explores how pattern reuse relates to theories of schema and learning, and how patterns can be codified and shared between designers based on these theories.
The tutorial titled "Applying design principles in practice" was presented in ISEC (India Software Engg Conference) on 18th Feb 2015 in Bengaluru by Tushar Sharma, Ganesh Samarthyam, and Girish Suryanarayana.
Une révolution socio-technico-culturelle, quelques dates et personnalités clefs.
Où l'on parle de bikinis et de bombe atomique, de LSD et de l'armée, de hippies allant à Davos, d'un Google en papier, de l'influence des ingénieurs français dans la création de l'Internet et du premier ordinateur personnel…
The document discusses software design principles and patterns, including the SOLID principles, design patterns like factory method and abstract factory, code smells like duplicated code and feature envy, and refactoring techniques to address smells like extracting classes and collapsing hierarchies. It provides examples of applying principles and patterns to real code and suggests design is key to creating high-quality, maintainable software.
Turing Machines are a simple mathematical model of a general purpose computer invented by Alan Turing in 1936. A Turing Machine consists of an infinite tape divided into cells, a head that reads and writes symbols on the tape, a finite set of states, and transition rules determining the behavior of the machine. The machine operates by reading a symbol on the tape, updating the symbol according to its transition rules, moving the head left or right, and transitioning to a new state. Turing Machines can simulate any algorithm and are capable of performing any calculation that can be performed by any computing machine.
Théorie des langages - 00 - IntroductionYann Caron
Cours de théorie des langages, théorie de la compilation, techniques de compilations et paradigmes de programmation que je dispense aux Ingé 2 et 3 à l’École National des Sciences Géographiques de Paris.
Some Pitfalls with Python and Their Possible Solutions v1.0Yann-Gaël Guéhéneuc
Python is a very popular programming language that comes with many pitfalls. This presentation describes some of these pitfalls, especially when they could trick unsuspecting object-oriented developers. It proposes solutions to these pitfalls, in particular regarding inheritance, which is easily broken because of the implementation choice of Python for explicit delegation, its method resolution order, and its use of the C3 algorithm. It discusses some advantages of using Python, especially regarding meta-classes.
Advice for writing a NSERC Discovery grant application v0.5Yann-Gaël Guéhéneuc
NSERC Discovery grant applications are judged according to four criteria: (1) Excellence of the researcher, (2) Merit of the proposal, (3) Contribution to the training of HQP, and (4) Cost of research. Each criterion has six possible merit indicators: Exceptional, Outstanding, Very strong, Strong, Moderate, and Insufficient. This presentation describes the process from a candidate's point of view and a reviewer's point of view. It discusses funding decisions, including bins and ER vs. ECR. It gives some advice, including graduating PhD students, having a story, and limiting the number of main objectives.
Ptidej Architecture, Design, and Implementation in Action v2.1Yann-Gaël Guéhéneuc
A set of process, architecture, design, and implementation patterns from a real, large program, the Ptidej Tool Suite. This set shows concrete problems and their solutions in Java. It includes: Be A Profiler, Tests as Documentation, Multi-layered Architecture, Proxy Console, Proxy Disk, Hidden Language, Internal Observer, Run-time Deprecation, String Parsimony, Object Identity, Object Address, Final Construction, StringBuffer as Positioning Element.
Examples of (bad) consequences of a lack of software quality and some solutions. This presentation presents some examples of (bad) consequences of a lack of software quality, in particular how poor software quality led to the direct deaths of 89 people. It then provides some background on software quality, especially the concept of Quality Without a Name. It then discusses many principles, their usefulness, and their positive consequences on software quality. Some of these principles are well-known in object-oriented programming while many others are taken from the book 97 Programmers. They include: abstraction, encapsulation, inheritance, types, polymorphism, SOLID, GRASP, YAGNI, KISS, DRY, Do Not Reinvent the Wheel, Law of Demeter, Beware of Assumptions, Deletable Code, coding with reason, and functional programming. They pertain to dependencies, domains, and tools.
(In details: Beautify is Simplicity, The Boy Scout Rule, You Gotta Care About the Code, The Longevity of Interim Solutions, Beware the Share, Encapsulate Behaviour not Just State, Single Responsibility Principle, WET Dilutes Performance Bottlenecks, Convenience Is Not an -ility, Code in the Language of the Domain, Comment Only What the Code Cannot Say, Distinguish Business Exception from Technical, Prefer Domain-specific Types to Primitive Types, Automate Your Coding Standards, Code Layout Matters, Before You Refactor, Improve Code by Removing It, Put the Mouse Down and Step Away from the Keyboard)
Some Pitfalls with Python and Their Possible Solutions v0.9Yann-Gaël Guéhéneuc
Python is a very popular programming language that comes with many pitfalls. This presentation describes some of these pitfalls, especially when they could trick unsuspecting object-oriented developers. It proposes solutions to these pitfalls, in particular regarding inheritance, which is easily broken because of the implementation choice of Python for explicit delegation, its method resolution order, and its use of the C3 algorithm. It discusses some advantages of using Python, especially regarding meta-classes.
An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...Yann-Gaël Guéhéneuc
Unicode is currently the world standard for encoding text. It supports all of the world's major writing systems. With its version 15.1 of 2023/09/12, it defines 149,813 characters and 161 scripts. This presentation starts with the, seemingly, simple example of the polar bear emoji. It then defines the key terms of any such standard. It then asks how a software system can render orthographic characters into glyphs, i.e., to render characters into (combined) glyphs. It introduces the concept of abstract characters and describes a brief history of encoding standards, from ASCII to Unicode. It shows how, by adding one level of indirection, the Unicode standard answers this question. It then presents code examples to display text written in Unicode: HarfBuzz (for shaping) and FreeType (for rendering).
An Explanation of the Halting Problem and Its ConsequencesYann-Gaël Guéhéneuc
The halting problem is an important, famous, and consequential problem in computer science. It is about writing a program that decides if another problem will stop. There is no general solution to this problem, which shows that such a problem is undecidable, with important consequences: for example, it is not possible to write tests that would exhaustively test entirely an arbitrary program. This presentation was written in collaboration with <a href="https://www.iro.umontreal.ca/~hahn/">Gena Hahn</a>.
A presentation summarising FPGAs, their history, their benefits, and showing how to program them. It provides some historical background on the development of computers, from the Difference Engine to the Intel 4004 to the AMD Ryzen Threadripper PRO 3995WX. It shows how the number of transistors increased dramatically but also how this increase led to more complexity and more bugs. It then introduces Field-programmable gate arrays (FPGA) as an alternative. It then presents how to program such FPGA using data-flow graphs. It discusses some tools (Yosys, NextPnR, and IceStorm) and illustrates them with a typical "Hello World" (i.e., blinking an LED) using Cygwin on Windows 10.
A set of brief presentations of some of the women and men who made the history of computer science and software engineering.
- 1936: Alan Turing
- 1948: Claude Elwood Shannon
- 1950: Grace Murray Hopper
- 1960: John McCarthy
- 1966: Frances E. Allen
- 1967: Ole-Johan Dahl
- 1967: Kristen Nygaard
- 1969: Charles A. R. Hoare
- 1970: Edgar F. Codd
- 1972: Dave Parnas
- 1974: Manny Lehman
- 1975: Frederick Brooks
- 1986: Edward Yourdon
- 1987: Barbara Liskov
- 1994: Erich Gamma
- 1997: Grady Booch
- 2001: Butler Lampson
A tutorial on the history, use, and caveats of Java generics. Using the simple example of an interface for sort algorithms, the tutorial presents the history of generics and describes the problems being solved by generics. It also provides definitions, and examples in Java and C++, and discusses Duck Typing. It then describes two scenarios: (1) Scenario 1: you want to enforce type safety for containers and remove the need for typecasts when using these containers and (2) Scenario 2: you want to build generic algorithms that work on several types of (possibly unrelated) things. It also summarises caveats with generics, in particular type erasure.
A tutorial on reflection, with a particular emphasis on Java, with a comparison with C++, Python, and Smalltalk. It describes different scenarios in which reflection is useful, a brief history of reflection and MOPs, a comparison with C++, Python, and Smalltalk, and some particulars about Java. The source code of the examples in Java (Eclipse project), Smalltalk (Squeak image v3.10.6), Python (Eclipse project), and C++ (Eclipse projects and Visual Studio solution) are available. (C++ Eclipse projects require Mirror.) Big thanks to Matúš Chochlík and Marcus Denker for their kind and precious help with C++ and Smalltalk.
The tutorial focuses on four common problems:
- Avoid using instanceof when code must bypass the compiler and virtual machine’s choice of the method to call.
- Create external, user-defined pieces of code loaded, used, and unloaded at run-time.
- Translate data structures or object states into a format that can be stored (file, network...).
- Monitor the execution of a program to understand its behaviour, and measure its space and time complexity.
It shows working examples of Java, Smalltalk, Python, and C++ code solving the four common problems through four scenarios:
- Scenario 1: invoke an arbitrary method on an object (see the problems with instanceof and plugins).
- Scenario 2: access the complete (including private) state of an object (see the problem with serialisation).
- Scenario 3: count the number of instances of a class created at runtime (see the problem with debugging/profiling).
- Scenario 4: patch the method of a class to change its behaviour (see the problem with patching).
It also discusses the different kinds of interconnections among objects that are available in common programming languages (linking, forking, subclassing, inter-process communication, and dynamic loading/invoking), a bit of theory about reflection, and specifically the class-loading mechanism of Java.
REST APIs are nowadays the de-facto standard for Web applications. However, as more systems and services adopt the REST architectural style, many problems arise regularly. To avoid these repetitive problems, developers should follow good practices and avoid bad practices. Thus, research on good and bad practices and how to design a simple but effective REST API are essential. Yet, to the best of our knowledge, there are only a few concrete solutions to recurring REST API practices, like “API Versioning”. There are works on defining or detecting some practices, but not on solutions to the practices. We present the most up-to-date list of REST API practices and formalize them in the form of REST API (anti)patterns. We validate our design (anti)patterns with a survey and interviews of 55 developers.
Analyzing and Visualizing Projects and their Relations in Software Ecosystems presents an approach to help developers understand and navigate between projects in related software ecosystems. The approach generates word clouds from project documentation to summarize projects. It then maps relationships between word clouds to identify related projects. This allows developers to better understand the scope and connections between projects within software ecosystems.
This document presents an approach for automatically identifying antipatterns in microservice-based systems. It defines a meta-model with 13 components to capture necessary information about a system and its microservices. It also identifies 15 common microservice antipatterns. Detection rules are defined for each antipattern based on analyzing the system's source code, dependencies, configuration and other artifacts. The goal is to develop a tool based on this approach to help developers minimize antipatterns in microservice systems and improve their maintenance and evolution.
The document presents a preliminary study comparing several open-source IoT development frameworks: Eclipse Vorto, ThingML, Node-red, and OpenHab. The researchers designed the study to evaluate the frameworks' ability to support basic IoT application requirements. They implemented examples from three common IoT application categories using each framework and analyzed the results. Overall, Node-red required the least effort while the other frameworks had more limitations. Future work could study how the frameworks complement each other and implement more complex examples.
This document describes a dataset of software engineering problems in video game development extracted from over 200 postmortems published between 1997 and 2019. The dataset contains 1,035 problems across 20 problem types and is intended to summarize developers' experiences and difficulties during game development. It is available on GitHub at the listed URL.
This document summarizes research into software engineering patterns for designing machine learning systems. A survey found that ML developers have little knowledge of applicable architecture and design patterns. A literature review identified 19 scholarly papers and 19 gray documents discussing practices. The research aims to classify ML patterns according to the typical ML pipeline process and software development lifecycle. It identifies 12 architecture patterns, 13 design patterns, and 8 anti-patterns for ML systems. Future work includes documenting the patterns fully and analyzing their impact on ML system quality attributes.
This document describes a type-sensitive service identification approach called ServiceMiner to support the migration of legacy systems to service-oriented architectures. ServiceMiner uses static analysis and detection rules tailored to specific service types to identify services. It was validated on an open-source ERP system, Compiere, where it achieved higher identification accuracy than other approaches and reduced the effort required to identify architecturally significant services. The approach automates service identification, allows prioritizing types, and is extensible to new technologies.
Practitioners surveyed had experience migrating legacy systems, mainly written in COBOL and Java, to SOA architectures. The top motivations for legacy-to-SOA migration were reducing maintenance costs and improving flexibility. Most common migration strategies were rehosting, re-architecture, or a mix. Service identification was seen as important and drew from sources like source code, business processes, and human expertise. Top-down and mixed approaches were commonly used. Functionality clustering and wrapping were the dominant service identification techniques. The process aimed to identify coarse-grained, high-value domain services rather than technical services. Full automation was not a primary focus due to challenges in predicting results for enterprise systems. Recommendations included
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
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
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
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