Towards a PracticalComposition Language

Oscar NierstraszSoftware Composition Group

University of Bern

Slide 2 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 3 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity of Berne (Switzerland)

1. Thesis — Focus on Software EvolutionSoftware evolution is the key problem in

software development

Not purely a technical issue1. Lehman’s Laws2. What’s wrong with OOP?3. What’s wrong with Components?

Slide 4 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 5 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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, 784.1% Other

Slide 6 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 7 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 8 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 9 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity of Berne (Switzerland)

What about Components?

stable

^A software component is a unit of independent deployment without

stateWe 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.

Slide 10 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 11 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity of Berne (Switzerland)

Applications = Components + Scripts

Components both export and import services

Scripts plug components together

Slide 12 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity of Berne (Switzerland)

Towards a Composition Language

Scripting languagesConfigure applications from components

ADLsSpecify compositional styles

Coordination languagesConfigure applications from distributed services

Glue languagesAdapt components to new contexts

Slide 13 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity of Berne (Switzerland)

Piccola — A Small Composition Language

Piccola agents compose and coordinate external components

Define styles

Script connections

Adapt protocols

Coordinate activities

Components

Agents

Channels

Scripts

Forms

Slide 14 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 15 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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.

Slide 16 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity of Berne (Switzerland)

Piccola in a Nutshell

A form consists of a sequence of bindings:

helloForm = # a formLabel = "hello world" # a bindingdo: println Label # a service

A script composes components by invoking services

makeFrameTitle = "Demo”makeButton(helloForm) ? Action(helloForm)

High-level connectors hide details of object wiring.

Slide 17 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity of Berne (Switzerland)

Hello World

Slide 18 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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 ...

Slide 19 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 20 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 21 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity of Berne (Switzerland)

How forms support composition

Formsextensible, immutable recordsfirst-class, monadic serviceslanguage bridgingintrospectionexplicit namespacesdynamic scoping on demandservices as operatorsagents & channels

Stylescomponent algebrasprimitive neutral object modelmetaobjectsHO plugs & connectorsdefault argumentsencapsulation

Scriptscomposition expressionssandboxescontext-dependent policies

Gluegeneric wrapperscomponent packaginggeneric adaptors

Coordinationcoordination abstractions

Slide 22 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 23 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity 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

Slide 24 of 24FMCO, Leiden, 2002-11-072002 © Oscar NierstraszUniversity of Berne (Switzerland)

The future of composition?

•Dynamic composition of ubiquitous services

•Service discovery and negotiation•Reconfiguration validation and run-time monitoring