Component-Based Software

1. Component-Based Software Kurt C. Wallnau Software Engineering Institute Carnegie Mellon University, USA kcw@sei.cmu.edu

2. Overview • Why component-based software? • What are components? component frameworks? • WaterBeans: “rolling your own” framework • Practical considerations • Component resources è

3. Why Component-Based Software? SW Products & Technology IT = competitive edge Marketplace Imperatives Business Imperatives Component-Based Software adaptability through component substitution and composition platform/language interoperability competitive marketplace for component vendors Elements of component technology Enterprise Java Beans Java Beans CORBA COM OO Web Technology Enablers

4. Interlude: Components v. Objects • Object Characteristics • abstraction (interfaces and encapsulation) • inheritance (hierarchically structured abstractions) • polymorphism (flexible but type-safe run-time binding) • Component Characteristics • abstraction (interfaces and encapsulation) • conformance to framework • independently deployable • composable • etc. Object-orientation is neither necessary nor sufficient for component-based software--but it is a convenient place to start

5. Components and Objects • Components and Objects are different kinds of abstractions • they are each good at different kinds of things • confusion sometimes arises because they share some characteristics (e.g. encapsulation)

6. The Object-Oriented Paradigm Object-oriented systems are based upon domain models the types of entities (or concepts) a type/subtype class hierarchy the structure and operation of OO software depends on this hierarchy This works when the domain is well understood and stable otherwise significant delays in implementation are to be expected and the resulting system will be brittle and difficult to adapt (real world class hierarchies are notoriously complex and difficult to change)

7. The Component Paradigm Coordination models allow integration of components without caring about what the components actually do individually or integrated. Components permit different approaches to structuring software systems for example, in ways that are not dependent upon the application domain (as with OO) i.e., frameworks based on “coordination model” rather than “domain model” are possible--as in WaterBeans This is one way to get a broader market for commercial components than possible with objects

8. Overview • Why component-based software? • What are components? component frameworks? • WaterBeans: “rolling your own” framework • Practical considerations • Component resources è

9. This is what the experts say... A component is a non-trivial, nearly-independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces. --Philippe Krutchen, Rational Software A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition --Clemens Szyperski A run-time software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at run time. --Gartner Group A business component represents the software implementation of an autonomous business concept or business process. It consists of the software artifacts necessary to express, implement, and deploy the concept as a reusable element of a larger business system. --Wojtek Kozaczynski, SSA These definitions show common ground & different perspectives

10. What I think they really said... There are some areas of agreement and some differences in perspectives among the experts

11. What they should have said Framework One key to understanding component software is the relation between component and framework components are conformant with a framework a framework provides compose-time and run-time services Not all frameworks are alike they differ in scope and in the kinds of interfaces they impose on components Components Component and Framework are inseparable concepts

12. Types of Component Framework Scope of Framework vertical horizontal Narrow, focused features. See object-oriented frameworks. E.g. SEMATECH CIM Framework. For large-scale systems integration. E.g. Enterprise Java Beans. function Framework Constraints Framework scope vertical: application specific horizontal: application neutral Framework constraints function: several types of component type-specific interfaces interfaces express functionality coordination: one type of component a standard component interface interface expresses coordination Not well explored. For application-level software with domain specific coordination. E.g., WaterBeans. For application-level software. E.g., Java Beans, and Microsoft COM. Great competition here. coordination A Notional Matrix for Component Frameworks

13. Coordination Interfaces Stack component • These are run-time coordination interfaces • how component functions are executed • Build-time & install-time interfaces are possible • registration & property editing, for example “push” instruction Stack logic “100” in data out data 100 3 signal 21 update 175 “ok” 223 Coordination interfaces are an option to functional interfaces there are fewer models for coordinating the activities of components than there are functions that we want our components to execute harden coordination into programmable interfaces specify functionality via protocols to be interpreted by components leads to a more uniform concept for integration through composition status

14. Overview • Why component-based software? • What are components? component frameworks? • WaterBeans: “rolling your own” framework • Practical considerations • Component resources è

15. The WaterBeans Framework Agriculture Estuary Construction B Lake QUAL2E Mining River QUAL2E WASP C Silviculture QUAL2E WASP WASP Urban A SWMM Mouse D The Environmental Protection Agency (EPA) develops software to model water quality lots and lots of models poor integration few standards The SEI is demonstrating component software for EPA initial scope is Urban Runoff to be extended to Loading Models We illustrate WaterBeans to show practical feasibility of vertical coordination frameworks • Framework Scopes: • A: Urban Runoff Models • B: Loading Models • C: Receiving Models • D: Water Quality Models

16. WaterBeans and Components simulates Water Beans composes imports Based on scientific theories and mathematics Model implemented by Computer tools for simulation and evaluation of models Application built from Custom and “off-the-shelf” software elements Components

17. The WaterBeans Specification Component interfaces to initialize, execute, and obtain input and output data Component interfaces to register the component and its properties to the WaterBeans framework Components implement ~20 (some trivial) interface calls Coordinational interface: how to register and execute components WaterBeans does not know or care about what the components compute Coordination scheme: a cyclic executive with scheduling determined by data dependencies among components

18. The WaterBeans Composer Composer tools Registered Sewer Components Component inspector Component instances and typed data connectors A standard coordination model supports compositional development and very high levels of program abstraction Data-driven component semantics

19. WaterBeans in Another Domain... Wave form components Wave combinations terminating in oscilloscope component WaterBeans framework was applied to another domain although a trivial domain, it is a proof of generality

20. Overview • Why component-based software? • What are components? component frameworks? • WaterBeans: “rolling your own” framework • Practical considerations • Component resources è

21. Components: Not a Silver Bullet • Components (as in WaterBeans) do not solve integration and interoperability problems • these problems are “merely” moved from hardened interfaces to data semantics • what properties does a component possess, and what do the properties mean? • for this industry consensus is required • However, coordination-style frameworks offer intriguing benefits (abstraction, composition,…)

22. Components: An Expandable Idea • Component-based software is an emerging technology and discipline • This talk has focused on one set of theoretical issues--the marketplace is more expansive • there are many emerging component technologies (COM/DCOM/ActiveX, Bean varieties , etc.) • there are a variety of emerging “methodologies,” some as extensions of pure OO and UML

23. Components: A Competitive Field • There is tremendous industry demand for improvements in software technology • recall the introductory motivation to this talk • There are many component technology providers looking to exploit this demand • competition over infrastructure standards is “hot” • Bottom Line: Expect instability and innovation in commercially-available component technology

24. Component Resources NIST Advanced Technology Program in Component-Based Software http://www.atp.nist.gov/atp/focusprg.htm Proceedings ICSE’98 Workshop on Component-Based Software Engineering http://www.atp.nist.gov/atp/focusprg.htm (cf Sept/Oct issue of IEEE Software for a summary of this workshop) Articles on Component-Based Software from OdaTeam http://www.odateam.com/cop/articles.html • An industry perspective on commercial tools for component-based development http://www.cool.sterling.com/cbd/