A Look at Current Component Models from the Black-box Perspective
-
Upload
premek-brada -
Category
Technology
-
view
560 -
download
3
Transcript of 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
3P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras
What is component, anyway
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)
5P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras
Sometimes omitted
What is component, anyway
• 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
6P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras
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
9P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras
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
10P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras
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
11P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras
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
12P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras
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
14P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras
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.
15P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras