Download - Bern.jb
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 1
Should we Resurrect Software Engineering?
Jean Bézivin [email protected]
CHOOSE Forum 2012, Bern
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 2
Requiem for Software Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 3
You escaped these titles
Software Engineering is Dead; Long Live Software Engineering
The basis of Software Engineering 2.0 From Software Engineering to Engineering
Software Towards a Unified Theory of Engineering Is Generic Engineering Feasible? How to Bridge Problem Spaces and Solution
Spaces? Some remarks about eEngineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 4
Agenda
1. Introduction 2. Software Engineering is Dead 3. Model Driven Engineering Missed the Boat 4. Problem and Solution Spaces 5. Domain Engineering 6. Support Engineering 7. Conclusion
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 5
SOFTWARE ENGINEERING IS DEAD
Sorry for the bad news
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 6
… or at least critically ill
Last time we heard good news was in the 80’s with the invention of the Smalltalk Browser
Every year since then, we have been eagerly waiting for better health news at OOPSLA, ECOOP, ICSE, etc.
But unfortunately we had only patterns, aspects, Java, and false hopes that did not last very long
Adding superficial deltas to the J-language is boring
And now many people have given up, to concentrate only on the problem of organization of agile teams
The NATO Conferences of 1968 and 1969 were motivated by the belief that software development should be "based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering.“ Surprisingly the conferences did not discuss what these foundations and disciplines were, or how they could be emulated. There has been little discussion of this topic in the intervening forty years and more. Some important lessons have been neglected.
From Michael Jackson’s Web site
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 7
Hype after Hype
Are we condemned to jump from hype to hype like a fashion industry?(1)
What is the hidden meaning in the long term evolution of our discipline?
(Raw Ngram buzzword observations)
Google Ngram Viewer
(1) Ivar Jacobson
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 8
Software Engineering as a Succession of Hypes
Many developers’ career paths follow a continuous zigzag from hype to hype, from objects to models, from models to services, ...
We need to focus more on long term continuity and progresses than on small ruptures and failures.
Progress in SE? What is the deep meaning, if any, behind this succession of hypes?
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 9
OOPSLA: An Object Odyssey
Design Patterns: Kent Beck and Ward Cunningham
[OOPSLA] became the forum for some of the most important software developments over the last couple of decades. OOPSLA was the incubator for CRC cards, CLOS, Design Patterns, Self, Agile Methodologies, Service-Oriented Architectures, Wikis, Unified Modeling Language (UML), Test Driven Design (TDD), Refactoring, Java, Dynamic Compilation, and Aspect-Oriented Programming, to name just some of them.
Probably the Palo Alto Research Center produced more results in ten years between 1970 and 1980 that the OOPSLA community in 25 years between 1986 and 2012.
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 10
Not a competition
We are suffering from the « My solution is better than yours » syndrome. Where is the big picture in this hype-after-hype sequence? Will some
technology finally prevail? Let us focus more on technology cooperation than on technology
competition.
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 11
What has changed in the past 50 years ?
Expressions like “CAD” or “Computer Assisted” or “Computer Aided” have lost all their discriminant meaning in engineering
Most engineering fields are now using computers and software
Time to adapt our vision
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 12
MDE MISSED THE BOAT Model Driven Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 13
Models Have Failed
“Models” have failed, at least temporarily. Deployment of MDE seems today to have reached a standstill. Immense hopes greeted the MDA™ initial proposal as a possible
way to regenerate the entire software engineering practices Recognition today that its impact is rather limited and its perspectives
quite confined. Observation that the process is not at the same level that in case of
technology take-off like OT in the 80’s Unfortunately this last silver bullet fired blank What went wrong?
No sustainability lack of model portability in time and space
No killer app Decreasing confidence in UML Many other factors
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 14
Separating the platform independent and dependent parts of a system (PIM/PSM)
We don't want anymore to pay such a high price for simply moving our information system to a new middleware platform (COM, CORBA, Java, HTML, XML, DotNet, etc.) when our business system stays stable. We are prepared to pay a last price for building the abstract models of our business and services that will guarantee us against technological obsolescence. From there, any platform provider will also have to provide the mapping solutions from standard business models before we buy.
November 2000
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 15 - 15 -
Write Once, Run Anywhere Model Once, Generate Anywhere
CORBA
Java/EJB C#/DotNet
Web/XML/SOAP
PIM
etc.
From Platform Independent Models to Platform Specific Models PIM to PSM
Multi-target code generation
+ SVG, GML, Delphi, ASP, MySQL, PHP, etc.
Service architecture, Cloud computing, …
SMIL/Flash
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 16
Sustainable Software?
Sustainability is the new hype, but is this hype sustainable?
The first promise/commitment of MDA™ was on sustainability: “Developers gain the ultimate in
flexibility, the ability to regenerate code from a stable, platform independent model (PIM) as the underlying infrastructure shifts over time”.
This was based on the “hidden condition” that the PIM was written in UML, a language supposed itself to be stable over long periods of time.
PERMANENT LINK TO THIS COMIC: HTTP://XKCD.COM/1007/ IMAGE URL (FOR HOTLINKING/EMBEDDING):
HTTP://IMGS.XKCD.COM/COMICS/SUSTAINABLE.PNG
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 17
Nice Gems … but is this core MDE?
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 18
Some MDA success stories but no killer app. yet
http://www.omg.org/mda/products_success.htm
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 19
What is a Killer App?
Tom Love experiment at Schlumberger (see also the Analyst At Xerox) 220 lines of Smalltalk vs. 10,000 lines of Fortran
A killer app. should provide measurable and reproducible evidence that the new proposal offers an order of magnitude improvement over previous solutions.
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 20
UML and MDE: friend or foe, devil or angel?
UML was the conclusion of the OOADTF and the beginning of MDA Everything started with UML and this is
probably the main problem of MDE
UML is a loosely defined language UML is a language with one syntax and an
infinity of semantics (Very popular BYOS)
UML is not a badly designed language Because it was never designed at all It is the result of industrial consensus,
obtained through a precise process (committee invention)
Bad modularity principles (profiles) UML as a visual syntax for C++
UML as a better « programming » language?
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 21
UML as the modeling language archetype?
UML considered as the archetype of modeling languages, often illustrates properties that are at the extreme opposite of the main MDE basic principles.
UML as the typical visual language. Many still wrongly associate MDE with visual modeling. MDE has later shown that textual modeling (like in Xtext) is often better than visual
modeling. UML as a general purpose language (GPL).
MDE has demonstrated the interest of precise and focused Domain Specific Languages (DSLs).
UML as an OO modeling language MDE has demonstrated the benefits of multiparadigm modeling, considering not
only objects, but rules, events, functions, tables, processes, etc. UML has wrongly conveyed the idea that modeling was only OO modeling
UML is known for its complexity, by the size of its metamodel and its rapid evolution MDE promotes the idea of simple languages that could be combined, with controlled
execution
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 22
Confusing Executability and Precision
One important ambiguity has been to let the idea propagate that all MDE-models, (including UML), could be made executable.
MDE promotes the idea that some models may be executable but not all A perverse corollary of this is that non executable models are not
precise Many models may be executable and however very precise
Precision is not always obtained through computer executability
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 23
XMI Failure
From SMIF to XMI, a good start. XMI as the final interoperability solution, the first mistake The proportion of native data expressed in XMI is
completely marginal and will not increase. Through its various versions, XMI added mess to mess. XMI with UML is part of MDE legacy. XMI will eventually disappear, creating an additional
problem of maintenance for UML models.
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 24
Lack of Theory
a model M a system S
The «real» World The World of «Models»
Squares and Circles
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 25
Representation and Conformance
Model System representationOf
Metamodel
conformsTo
The two orthogonal dimensions of MDE
wrt
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 26
Taking the representation relation seriously
"What about the [relationship between model and real-world]? The answer, and one of the main points I hope you will take away from this discussion, is that, at this point in intellectual history, we have no theory of this [...] relationship". [Brian Cantwell Smith]
Where are models coming from?
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 27
Action on a model is not action on the system (real world)
a model M a system S repOf
A situation or a phenomenon of the real or imagined world.
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 28
But we Learned a Lot with MDE
1. Representation principle Any model M represents a system S
2. Multiple view principle A system S may be represented by
several models 3. Conformance principle
Any model M conforms to the language of its metamodel MM
4. 3-level principle Any metamodel MM conforms to a
common metametamodel MMM 5. Transformation principle
The most important operation applicable to models is a transformation
6. HOT principle A transformation is a model
7. Weaving principle Abstract correspondences between
models are represented as models 8. Megamodel principle
Model elements may be considered as models
9. Unification principle All models specialize a common
abstract model 10. Technical Space Framework
Any model has a given representation defined by its technical space
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 29
What is a modeling language?
The expression “modeling language” is recent
Examples: • Requirements • Abstract Specifications • Formal Methods • Semi-Formal Notations • Early aspects (?) • etc.
The expression “modeling language” is recent
Tentative definition: A modeling language is a language contributing to software production, maintenance or operation that is not directly executable.
Examples Flowcharts (~1950) Petri Nets (~1960-1970) PSL/PSA (~1967) State Diagrams (~1967) SADT (~1969) DFD (~1975) Entity-Association
(Chen, ~1976) JSD (~1982) AD/Cycle (~1982) UML (~1996) MDA (~2000)
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 30
What are the relations between Programming & Modeling Languages?
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 31
The two parallel tracks
Programming Languages
Assembler Fortran COBOL
Algol60 PL/1 ADA Java
C#
Smalltalk
C++ Ruby Scala
Python F# Go
Dart
Modeling Languages Sara
SREM SADT Petri JSD
DFD B
OMT
Z
VDM UML
SART
ExecutableUML?
Flowcharts
Lisp
Prolog
SysML
Pascal
PSL/PSA
SBVR
Javascript
No global consolidated history of Modeling Languages
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 32
Evolving scope Not only for code generation
[If MDE is the Solution, then what was the Problem?]
MDE
MDD
MDE
MDD
MDD = Model Driven (Software) Development MDE = Model Driven Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 33
MDE is not only for code generation
Restricted focus MDE concentrated too much
on models of code and not enough on models of data
MDE concentrated too much on models of solutions and not enough on models of problems
MDE concentrated too much on Information Systems models and not enough on Business models
MDE concentrated too much on modeling in the small and not enough on modeling in the large
etc.
Software Engineering
System Engineering
Data Engineering
Business Engineering
appliesTo
Model Driven
Engineering
Initially MDA was for just software engineering, and the scope was progressively extended
UML/SPEM CWM SysML BPMN
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 34
PROBLEM AND SOLUTION SPACES The engineer view of « how to solve it? »
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 35
Technical Spaces
aTechnicalSpace
aSystem aModel repOf
System: A group of interacting, interrelated, or interdependent elements forming a complex whole.
Model: An abstract representation of a system created for a specific purpose.
Technical Space: A representation system for models and a set of technical solutions to handle them. A framework usually based on some algebraic structures (relational tuples, trees, graphs, hypergraphs, etc.)
MetaMetaModel
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 36
Structuring the solution space
Problem How to Solve it?
Java XML MDA™ Ontologies etc.
Problem Space
Solution Space
Grammars
Programs
DBMS
XML Schema
XML Documents
Metamodel
Model
All models are not MOF or ECORE Models.
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 37
Three representations for the same program
JavaML schema
JavaML Document
Java Metamodel
Java Model
Java Grammar
Java Program
Program TS MDA TS XML TS
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 38
Projections between EBNF, MDE and XML
MDE TS EBNF TS
MOF
Java
Test.xmi
EBNF.g
Java.g
Test.java
XSD.xsd
JavaML.xsd
Test.xml
M3
M2
M1
XML TS
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 39
Ubiquitous Software: From Problems to Solutions
Solution Spaces
Problem Spaces
Mappings
Domain Engineering
Support Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 40
Focus on Engineering
Scientists study the world as it is; engineers create the world that has never been.
Theodore von Kármán
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 41
The two spaces
Domain Engineering
Support Engineering
Problems lie here
Tools to solve problems may be found here
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 42
Problems and Solutions
Support Engineering (vertical?) Process engineering Product (line) engineering Software language engineering Model engineering Service engineering Data engineering Program engineering Event engineering Constraint engineering System engineering Requirement engineering Ontology engineering Legal engineering
Domain Engineering (horizontal?) Civil engineering Building engineering Electrical engineering Mechanical engineering Business engineering Biological engineering Automotive engineering Health engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 43
DOMAIN ENGINEERING Problem Spaces
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 44
Domain Engineering
Similar processes across all engineering fields 1. Build abstract models
Using some given ontologies For example mechanics, electronics, etc.
2. Verify/Validate Abstract Models
Using some validation technique
3. Put into production Create Products from Models Automatic, Semi-automatic or Manual
4. Put into operation
Deployment Augment or change the real world Adding a new bridge, a new phone device, a
new building, a new operational program, etc.
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 45
Electrical Engineering
Building abstract models
Validation Verification
Putting in Production
Augmenting, Changing the
world
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 46
Construction Engineering
Building abstract models
Validation Verification
Putting in Production
Augmenting, Changing the
world
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 47
Old and new engineering fields
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 48
Many Communities, Many Journals
http://www.govengr.com/
Journal of Neural Engineering to help scientists, clinicians and engineers to understand, replace, repair and enhance the nervous system.
Neural engineering (also known as Neuroengineering) is a discipline within biomedical engineering that uses engineering techniques to understand, repair, replace, enhance, or otherwise exploit the properties of neural systems
Healthcare Engineering Biomedical engineering Computer-aided medical engineering Medical/disease modeling Rehabilitation engineering Healthcare energy systems engineering Healthcare support service engineering Emergency response engineering Engineering issues in public health and epidemiology Aging Engineering and aging (elderly patient service) Healthcare engineering education …
Concurrent engineering is a work methodology based on the parallelization of tasks (i.e. performing tasks concurrently). It refers to an approach used in product development in which functions of design engineering, manufacturing engineering and other functions are integrated to reduce the elapsed time required to bring a new product to the market.
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 49
And many more
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 50
Synergies Between Engineering Fields
Program Engineering Building Engineering
“The Origins of Pattern Theory, the Future of the Theory, And The
Generation of a Living World” Christopher Alexander
Once in a great while, a great idea makes it across the boundary of one discipline to take root in another. The adoption of Christopher Alexander’s patterns by the software community is one such event. .
Jim Coplien
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 51
Domain Engineering
Domain Engineering
Product Engineering
Process Engineering
Problem spaces
Solution spaces (Support Engineering)
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 52
Many features common to all domain engineering fields
Based on support engineering Product & Process focus Including HR and team management
Chain Building Abstract Models Verification/Validation Putting in Production Putting in operation
Need for a strong model repository Scaling up to millions of parts Cooperative concurrent access Point of view mechanisms Strong zooming mechanisms
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 53
SUPPORT ENGINEERING Solution Spaces
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 54
Variety Complexity of the Support Engineering Landscape
Language Engineering
Program Engineering
Ontology Engineering
Model Engineering
Web Engineering
Service Engineering
Transformation Engineering
Rule Engineering
Complex Event Engineering
Data Engineering
Process Engineering
Product Engineering
HR Engineering
Team Engineering
Software Engineering
Other Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 55
Specialized engineering fields
Language Engineering
Software Language
Engineering
Model Engineering
Ontology Engineering
Grammar Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 56
Composite engineering fields
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 57
Model Engineering
The legend
Same visual notation, different context, different meaning (Thick red dotted lines for bicycle lanes)
is the metamodel
µ
Model
c2
Metamodel
Model element
Metamodel element
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 58
Process engineering
Process engineering encompasses a vast range of industries, such as chemical, petrochemical, mineral processing, advanced material, food, pharmaceutical, biotechnological, and software industries.
See also Concurrent Engineering
Process Engineering
Software Process Engineering
SPEM
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 59
PSL (Process Specification Language) Process Specification Language NIST
+nameProcess
-name-duration
Activity
1
0..*
+following0..*
+preceding
0..*
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 60
Early SPEM (UPM)
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 61
Team and Product management
Team Management Engineering
Software Team Management Engineering
Agile Methods
Product Lifecyle Management (PLM)
Product Line Engineering
Software Product Line Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 62
Data Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 63
Program Engineering
Short name: “Programming” Long tradition of excellence Noble and visible part of SE Very difficult Many iterations and branches Structured Programming OO Programming Functional Programming Etc.
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 64
What is a program?
The World (domain)
The Machine (platform)
A Program The Application Requirements
(use cases)
class BankCustomer{ } class Printer{ } class Application{ }
A Programming
Language
c2
class Application{ public static void main (String[] args) { System.out.writeln("Hello, world") } }
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 65
Making implicit relations explicit
Language engineering is related to the definition and handling of languages
Program engineering deals with the use of executable software languages to produce operational programs that will participate in human activities (includes deployment).
Language Engineering
Program Engineering
?
?
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 66
Models for producing programs
Domain (World)
Problem (Application)
Platform (Machine)
Program
Models
Code generation with models
Today Knowledge in the head of programmer
Tomorrow From implicit to explicit Transformation based Other aspects
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 67
But also models for understanding programs
View1
View2
View3
Program
Models
Code understanding with models
Today
Tomorrow
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 68
Sound terminologies are always useful
Good definitions allow avoiding sterile, futile, and non productive discussions
«Mal nommer les choses, c'est ajouter au malheur du monde» Albert Camus [To misname things is to add misery to the world]
Programming is Modeling
Modeling is Programming
Model Engineering
Program Engineering
?
?
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 69
Many Possible Useful Collaborations Between Support Eng.
Transformation Engineering
Model Engineering
Data Engineering
Program Engineering
Model Engineering
Language Engineering
Service Engineering
Model Engineering
Data Engineering
Process Engineering
Model Engineering
Product Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 70
Combining Support Engineering
1,400,000 results N defs of MDA M defs of SOA P ways to combine them
Model Engineering
Service Engineering
?
?
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 71
Understanding complex relations
Business Engineering
Software Engineering
?
?
Model Engineering
Language Engineering
BPMN
UML
Data Engineering
Service Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 72
CONCLUSIONS Software Engineering is Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 73
Let’s forget about “Computer Science”
Computer Engineering
Program Engineering
Software Engineering
Data Engineering
? Language
Engineering
Informatics
Platform Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 74
Conclusions
After nearly 50 years Software engineering is dead MDE missed the boat No other major silver bullet on the horizon
Good time to invent a new future SE as a branch of generic eEngineering (eE) eE using most of the ideas of MDE eE taking inspiration of the brightest ideas in
other domain or support engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 75
Software Engineering and Engineering Software
Engineering
eEngineering
Software Engineering Civil Engineering Electrical Engineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 76
Unified Theories of Engineering
Yes we need to resurrect Software Engineering. The expression “Software Engineering” was coined in 1968. In 2018, for the 50th anniversary, a new “NATO-like” event to
refund SE2.0 on solid grounds, taking into account what has been learnt in half-a-century?
We need to invent SE2.0, in a radical departure from what has been done in the past 50 years. The problem is not to invent a marginally better
programming or modeling language. SE2.0 could/should be just be a specialization of
eEngineering, a generic view of modern engineering practices.
Short term proposal: a generic platform for eEngineering
07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 77
Thanks
• Questions? • Comments?