a look at current component models from the black-box perspective
TRANSCRIPT
![Page 1: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/1.jpg)
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
![Page 2: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/2.jpg)
Agenda
• Defining component
• Defining and defending black box
• Case studies
• Lessons learned
2P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras
![Page 3: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/3.jpg)
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
![Page 4: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/4.jpg)
What is component, anyway
4
Szyperski’s book 2nd edition, preface
P.Brada: Black-box perspectiveEuromicro 28.8.2009 Patras
![Page 5: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/5.jpg)
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
![Page 6: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/6.jpg)
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
![Page 7: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/7.jpg)
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
![Page 8: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/8.jpg)
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
![Page 9: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/9.jpg)
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
![Page 10: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/10.jpg)
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
![Page 11: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/11.jpg)
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?
![Page 12: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/12.jpg)
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
![Page 13: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/13.jpg)
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
![Page 14: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/14.jpg)
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
![Page 15: A Look at Current Component Models from the Black-box Perspective](https://reader034.vdocuments.site/reader034/viewer/2022052700/55a071c91a28ab44498b45b6/html5/thumbnails/15.jpg)
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