A Look at Current Component Models from the Black-box Perspective

A Look at Current Component Models from the Black-box

Perspective

On the need for well-specified black-box components

Premek BradaUniversity of West Bohemia, Pilsen, Czech Republic

Euromicro SCBSE, August 2009. Patras, Greece

Agenda

• Defining component

• Defining and defending black box

• Case studies

• Lessons learned

2P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras

What is component, anyway

• Levels of understanding

• Szyperski’s tiers: “business” and source level (buy instead of make) design fragment reuse (~ADLs) user-driven composition (deployment) dynamic integration (~SOA)

• Bachmann et al: “architectural component” is architectural abstraction with standardized properties and composition possibilities – not an functionality implementing blob

with ad-hoc integration means



4

Szyperski’s book 2nd edition, preface

P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras

The inflation of definitions

• Szyperski 1997 (2002): three own defs

• About 17 other defs around (1987-2007)


Sometimes omitted


• We talk about deployable architecturalcomponents here

• 7+ defs, shared view:

– black-box (opaque) software element

– with well-specified surface (aka interface)

• completeness, includes dependencies; client readable

– 3rd party composable and deployable

– model conformant

• type, interaction and composition rules


Together prevent property leaksand implementation dependencies

What is black box, then?

7

David Parnas: On the Criteria

… (1972)

“Blackbox reuse refers to the concept of reusing implementations without relying on anything but their interfaces and specifications. (…)”In contrast, whitebox reuse refers to using a software fragment, through its interfaces, while relying on the understanding gained from studying the implementation.

Szyperski (2000)

P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras

Why black-box matters

• Software Engineering core concept: modules -> interfaces -> components: information hiding enforced

on both sides of the surface (provide, require)

• Goals and consequences

– prevent property leaks

– manage dependencies, composition

– localize change effects

– make software comprehensible, analyzable8P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras

Why good specification [of the black box]

matters

When it does not…

… other essential properties not achievable

• Compositionality

– cannot be deployed really anywhere, due to the internal (non-specified) dependencies

– compound properties not deducable from composition of internal (non-specified) properties

• Model conformance

– implementation can bypass interaction standards


Aren’t we talking about the obvious?

• Counterexamples

– JavaBeans – allow source-level composition

• white-box reuse

– OSGi, EJB – not well specified black boxes

• discussion follows


How do we assess opacity

1. Completeness of specification

– Explicit required role

2. Specification-implementation consistency

3. Enforcement of black box

– or “of information hiding”

4. Ease of feature reconstruction

5. Richness of contract types


Does this component model support black-box

reuse well?

Case study 1: OSGi

• Explicit required role

• In-completeness of specification

– core: don’t declare services

– std services: almost complete, not universal

• Weak specification-implementation consistency

– core: package resolving only

• Moderate enforcement of black box

– bind to declared packages and registered services only

– class leaks from packages deprecated but easy


Case study 2: EJB

• Explicit required role

• Moderate completeness of specification

– events for MDB, attributes for BMP

– issue with annotation style declarations in EJB 3

• Mixed specification-implementation consistency

– extremely poor for EJB 2.1

– good for annotation style EJB 3

• Enforcement of black box by framework13P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras

Why the transgressions?

• Component model design: abstraction level, specification means

– Bachmann: “API can only be silent about properties about which it can speak, and programming languages are only equipped to speak about a narrow range of properties.”

• Implementation compromises / constraints

– OSGi expert: Export-Service header deprecated because the framework does not act on it


Conclusions

• Components are not as black box as we think

• How far on the scale can we go (before falling off)?

call for sufficient abstraction level, completeness

call for adequate [run-time] enforcement

Detailed analysis of state of art/practice needed.


A Look at Current Component Models from the Black-box Perspective

Technology

Transcript of A Look at Current Component Models from the Black-box Perspective