Presentation given at Euromicro Software Engineering and Advanced Applications conference in Patras, August 2009. For details, see paper Brada, P. A Look at Current Component Models from the Black-box Perspective. Proceedings of Euromicro SEAA, Patras, Greece. IEEE Computer Society 2009.

1. A Look at Current Component
Models from the Black-box
Perspective
On the need for well-specified black-box components
Premek Brada
University of West Bohemia, Pilsen, Czech Republic
Euromicro SCBSE, August 2009. Patras, Greece

2. Agenda
• Defining component
• Defining and defending black box
• Case studies
• Lessons learned
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 2

3. 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
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 3

4. What is component, anyway
Szyperski’s book 2nd edition,
preface
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 4

5. The inflation of definitions
• Szyperski 1997 (2002): three own defs
• About 17 other defs around (1987-2007)
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 5

6. What is component, anyway
• We talk about deployable architectural
components here Together prevent property leaks
• 7+ defs, shared view: and implementation dependencies
– black-box (opaque) software element
– with well-specified surface (aka interface)
• completeness, includes dependencies; client readable
– 3rd party composable and deployable
– model conformant Sometimes omitted
• type, interaction and composition rules
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 6

7. What is black box, then?
David Parnas:
On the Criteria
… (1972)
“Blackbox reuse refers to the concept of Szyperski
(2000)
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.
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 7

8. 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 Why good specification
[of the black box]
– manage dependencies, composition matters
– localize change effects
– make software comprehensible, analyzable
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 8

9. 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
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 9

10. 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
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 10

11. How do we assess opacity
Does this component
1. Completeness of specification model support black-box
reuse well?
– 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
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 11

12. 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
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 12

13. 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 framework
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 13

14. 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
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 14

15. 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.
Euromicro 28.8.2009 Patras P.Brada: Black-box perspective 15