1. Towards a Practical Composition Language Oscar Nierstrasz Software Composition Group University of Bern

2. Slide 2 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Roadmap The problem: Software Evolution –What about OOP? Components? … Approach: understanding composition –Piccola — a small composition language Where are we? Where do we go? –Evaluation; research agenda

3. Slide 3 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) 1. Thesis — Focus on Software Evolution Software evolution is the key problem in software development Not purely a technical issue 1.Lehman’s Laws 2.What’s wrong with OOP? 3.What’s wrong with Components?

4. Slide 4 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Lehman’s Laws Continuing change A program that is used in a real-world environment must change, or become progressively less useful in that environment. Increasing complexity As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure. —Lehman and Belady, 1985

5. Slide 5 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) The Myth of Software Maintenance Between 50% and 75% of global effort is spent on “maintenance”! (= “continuous development 17.4% Corrective (fixing reported errors) 18.2% Adaptive (new platforms or OS) 60.3% Perfective (new functionality) —Lientz, 78 4.1% Other

6. Slide 6 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) What’s wrong with OOP? (I) OOA and OOD are domain driven –Designs are based on domain objects, not available components –Objects end up with rich interfaces, not plugs + Hard to reconfigure and adapt objects

7. Slide 7 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) What’s wrong with OOP? (II) Implicit Architecture –Source code exposes class hierarchy, not run-time architecture! –Objects are wired, not plugged together –How the objects are wired is distributed amongst the objects + Hard to understand and hard to evolve

8. Slide 8 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) What’s wrong with OOP? (III) Implicit Reuse Contracts –Idioms and patterns are hidden in the code + Hard to learn frameworks and conventions

9. Slide 9 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) What about Components? stable ^ A software component is a unit of independent deployment without state We know how to build components! We don’t understand how to compose flexible applications from components. +We should be thinking more about composition than about components.

10. Slide 10 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) 2. Composition A composition language would support flexible, high-level composition of applications from components according to various styles. Applications = Components + Scripts Piccola: A Small Composition Language Forms + Agents + Channels Styles as Component Algebras

11. Slide 11 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Applications = Components + Scripts Components both export and import services Scripts plug components together

12. Slide 12 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Towards a Composition Language Scripting languages Configure applications from components ADLs Specify compositional styles Coordination languages Configure applications from distributed services Glue languages Adapt components to new contexts

13. Slide 13 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Piccola — A Small Composition Language Piccola agents compose and coordinate external components

14. Slide 14 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Piccola Layers Applications components + scripts Compositional styles streams, events, GUI composition,... Standard libraries basic coordination abstractions, basic object model... Piccola syntax layer services, operator syntax, namespaces, built-in types Composition primitives agents, channels, forms

15. Slide 15 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Forms + Agents + Channels Forms embody structure immutable, extensible records they unify components, services and namespaces Agents embody behaviour concurrently executing scripts they unify concurrency and composition Channels embody state mailboxes for communicating agents unify synchronization and communication.

16. Slide 16 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Piccola in a Nutshell A form consists of a sequence of bindings: helloForm =# a form Label = "hello world"# a binding do: println Label# a service A script composes components by invoking services makeFrame Title = "Demo” makeButton(helloForm) ? Action(helloForm) High-level connectors hide details of object wiring.

17. Slide 17 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Hello World

18. Slide 18 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Component Algebras A style can be viewed as a many-sorted algebra: connectors as operators over components: source | filter is also a source contrast the procedural view: a.in() -- b.out() doesn’t yield a new component...

19. Slide 19 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Some Piccola Styles Many frameworks can be expressed as component algebras –Pipes and filters (both push & pull flow) –GUI composition –Event listeners –Actor groups –Regulated coordination (law-governed interaction) –Mixin layer composition

20. Slide 20 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) 3. Where are we? Where do we go? What would be a practical composition language? How explicit namespaces support composition Results and shortcomings The future

21. Slide 21 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) How forms support composition

22. Slide 22 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) Results so far Piccola implementations for Java and Squeak –Sophisticated language bridging –Partial evaluation –Various experimental composition styles Formal semantics –π calculus with first-class namespaces –Limited reasoning about styles and composition Publications and software: www.iam.unibe.ch/~scg

23. Slide 23 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) What’s missing? Explicit components, connectors & styles Type-checking provided and required services Reasoning about styles and compositions Adapting/reengineering existing services

24. Slide 24 of 24FMCO, Leiden, 2002-11-072002 © Oscar Nierstrasz University of Berne (Switzerland) The future of composition? Dynamic composition of ubiquitous services Service discovery and negotiation Reconfiguration validation and run-time monitoring