An Introduction to Component Software Robert Gallup MSCS

An Introduction to Component Software Robert Gallup MSCS Candidate Union College 16 May 2003

Agenda • • • Introduction Software Components Component-Based Development Conclusion Questions / Discussion

Introduction

Traditional Software Custom-Made • Developed entirely from scratch – Uses only programming tools and libraries • Advantages Standard • Outsourced – Standard software is purchased, then modified to provide a solution that is ‘close enough’ to what is needed – May provide a competitive edge, as it is optimized for a user’s business model – Takes advantage of In-House proprietary knowledge or practices • Produced for a mass market • Strong trend toward Standard SW • Advantages – – • Disadvantages Very expensive Often provides sub-optimal solutions High risk of failure No guarantee of interoperability with customers or business partners – Can be parameterized to closely match customer’s needs – Retires Time-to-Market Risk – Does not offer a competitive edge, it’s available to competitors as well – Cannot be quickly adapted to changing needs

Traditional Software Problems with Large Software Projects • 1 in 3 Projects Cancelled Prior to Completion • Average Project Suffers Schedule Overrun of 50% • 1 in 8 Completed Projects Considered to be Successful • 75% of Projects Fail to Perform According to Customer’s Requirements

Component Software • Represents a Middle-Path between Custom and Standard Software Development • Makes it Easier to Customize Standard Software • Component Assembly Allows Individual Price/Performance Tradeoff Choices • May be Combined with Custom-Made Components • Eliminates the Need for Massive Upgrade Cycles

Software Components Software Component: Executable unit of independent production, acquisition, and deployment that can be composed into a functioning system Component Software: Composite systems composed of software components Current Technologies: – – OMG CORBA Microsoft COM, OLE, and Active. X, Visual Basic SUN Java. Beans, EJBs Modern Operating Systems • Sharing of File Systems, Common File Formats, use of Pipe and Filter Composition – Netscape and Plug-Ins (ie: Apple Quicktime) – Applets

Spectrum Between Make-All and Buy-All Flexibility, nimbleness, competitive edge Cost Efficiency 0 Custom % Bought 100 Standard Component Software Allows Customers to Set Priorities Based on Budget Restraints, Performance Requirements, etc.

Analogies Component Software Comparisons to Other Engineering Disciplines • Computer Hardware – Integrated Circuits (Software IC) – Plug and Play Technology • Audio Equipment • Mechanical Engineering – Gears, nuts, and bolts Why is Software Different? • Software delivers a ‘blueprint’ for products, not the product itself • Computers instantiate software blueprint

Component-Based Development

Component Characteristics • Unit of Deployment – Isolatable part of a system – Well separated from it’s environment and from other components – Never partially deployed • Unit of Third-Party Composition – Components must interact through a well-defined interface • Has No Persistent State – Ex: Database server = component, database = object • Typically Consists of a Collection of Related Classes – May consist of a single class, but rare – May contain traditional procedures and global variables – May be implemented using functional languages, assembly language, or any other approach – A component’s objects may be visible to clients (usually other components)

Client Access to Components Component A Client of A • Component A consists solely of objects, of which A’s client has access to 2 Client of B • Component B consists solely of traditional procedures (& possibly global static variables) Client of C • Component C combines objects & traditional procedures. Client has access only to objects & cannot recognize that C is “all O-O inside” Object a Object b Object c Component B Procedure a Procedure b Procedure c Component C Object a Object b Procedure a

Components vs. Objects • What is a Component? – Characteristic properties • • • a component is a unit of independent deployment a component is a unit of third-party composition a component has no persistent state • What is an Object? – Characteristic properties • • • an object is a unit of instantiation; it has a unique identity an object has a state; this state can be a persistent state an object encapsulates its state and behavior

Blackbox vs Whitebox Abstraction Visibility of an Implementation Behind it’s Interface • Blackbox Abstraction – Clients know only the interface and it’s specification • Whitebox Abstraction – The interface may still enforce encapsulation and limit what clients can do – Implementation is fully available • Glassbox Abstraction – Implementation details may be viewed only, not modified • Graybox Abstraction – A controlled part of their implementation is available

Blackbox vs Whitebox Reuse • Blackbox Reuse – Reuses implementations relying on nothing but their interfaces and specifications • Example: Application Programming Interfaces (APIs) • Whitebox Reuse – Uses a software fragment through it’s interfaces – Relies on information gained from studying the actual implementation • Example: Class libraries and Frameworks

Component Interfaces • A Component Interface Provides the Means for Components to Connect – Technically, it is a group of related functions that can be invoked by clients – Every operation must be specified • The specification serves both providers implementing the interface and clients using the interface – A component may contain multiple interfaces – An interface should be viewed independently of any component that may implement or use it • Terminology – Provider – The component that implements the operations of an interface – Client – The user of the services provided by an interface

Interface Specification • The Semantics (Behavior) of Each Operation in an Interface is Given by a Specification • This Specification Serves Both the Provider and the Client – ie. : • Provider – Specification defines the requirements for the behavior to be implemented within the provider component • Client – Specification defines the behavior that can be expected from interactions with the Provider’s interface • Interfaces are Specified Using an IDL (Interface Definition Language) – Current competitors: • OMG IDL • COM IDL

Direct and Indirect Interfaces • Direct Interface – Provided directly by a component – Corresponds to procedural interfaces of traditional libraries • Indirect Interface – Provided by objects made available to clients by a component – Corresponds to object interfaces

Direct and Indirect Interfaces Direct Interface Client of A Component A Procedure B Procedure C Indirect Interface Client of B Component B Object B Method B. a Method B. b

Interfaces as Contracts Interface Specifications Between Provider and Client • Contracts State What a Client Needs to do to Use an Interface • Also State What Providers Must Implement to Meet Services Promised by the Interface • A Popular Method: Specifying Pre-Condition and Post-Condition Specifications for an Operation – Hoare triple convention: • {precondition} operation {postcondition} – Dijkstra’s weakest preconditions convention: • wp(S, Q) – wp = weakest precondition for which execution of S is guaranteed to terminate while meeting postcondition Q

Pre and Post Conditions • Specification of the Form: pre U, post V – Means: Condition U must be satisfied by client upon method entry, and condition V will be satisfied by provider upon method exit: • Usually Specified Using Predicates • Example: Queue interface Queue { boolean empty(); } Queue enq(Object X); @post { !this. empty() } Post condition: Queue must not be empty after executing enq() Queue deq(); @pre { !this. empty() } Pre condition: Queue must not be empty before executing deq()

Substitutability Ability of a Component B to Replace Component A Without Breaking A’s Client(s) • An Interface Must be Specified Carefully – Should not require too much or too little from clients/providers • ie: An interface should require no more than is essential for the service to be provided • Allows headroom for both client and provider to overfulfill their contract – Client may establish more than required by the pre-condition, and expect less than is guaranteed by the post-condition • In General: – What is established by a certain client: Demanded by interface (precondition) Required by certain provider – What is established by a certain provider: Guaranteed by interface (postcondition) Expected by certain client

Substitutability Example interface Simple. Counter { int get. Value(); void dec(); void inc(); } interface Positive. Counter { int get. Value(); void dec(); @pre { this. get. Value() > 0 } void inc(); } class Counter implements Simple. Counter, Positive. Counter Simple. Counter / Positive. Counter : Identical interface methods, different functionality

Contract Verification • Contract-Checking is Highly Desirable – – • Ideally, contracts checked against interface specification • Compiler or other automatic tool Contract violators would be rejected In Practice: – Fully formalized interface contracts are hard to achieve • • • Difficult and expensive Efficient, general-purpose verifiers are not feasible Current research focuses on theorem-provers using heuristics – – • Expensive Requires expert manual assistance Ultimate Goal: Develop automatic error-checking as early as possible to prevent catastrophic faults • Preferred order of error checking: 1) 2) 3) 4) Compile-Time Load-Time Run-Time No Checking at All !

Memory Errors • Memory Error - A program reads a memory cell based on a wrong assumption of what the cell contains – – – • Can affect unrelated parts of a program Are notoriously hard to track down Can be arbitrarily destructive A Way Around Memory Errors: A Type System – Group values of related semantics into sets, or types • • • – – Integers, Reals, Object References, etc. Basic types (integers, reals) understood as sets of values Objects and interfaces understood as a set of objects implementing a certain interface Helps ensure memory accesses are type compatible Use with Automatic Memory Management and Runtime Checks to Eliminate all Memory Errors

Types and Subtypes • A Type Contains All of the Operations and Signatures of an Interface – Input parameters form a part of an operation’s preconditions – Output parameters form a part of an operation’s postconditions – NOTE: Other pre and post conditions may exist beyond an operation’s signature A Type is an Interface with a Simplified Contract A Subtype is a Type Derived From a Base Interface – Subtypes may be formed in 2 ways • Interface Inheritance – Similar to class inheritance • Structural Subtyping – Implementation of base interface is copied from derived interface

Types and Subtypes Example • View is a type: interface View { void close(); void restore(int left, int top, int right, int bottom); } • Text. View is a subtype of View (via interface inheritance): interface Text. View extends View { int caret. Pos(); void set. Caret. Pos(int pos); } • Text. View 1 is a subtype of View (via structural subtyping): interface Text. View 1 { void close(); void restore(int left, int top, int right, int bottom); int caret. Pos(); void set. Caret. Pos(int pos); } • Text. View and Text. View 1 can be used wherever View is expected

Inheritance • Three Facets of Inheritance – Substitutability • Can a subclass replace it’s superclass without breaking the system? – Subtyping (Interface Inheritance) • Can the subclass use or conform to the interface of the superclass? – Subclassing (Implementation Inheritance) • Can the subclass use the implementation of the superclass? • Interface Inheritance is Generally Preferred Over Implementation Inheritance

Multiple Inheritance • Two Principle Reasons for Supporting MI – To merge interfaces from different sources (Multiple Interface Inheritance) – To merge implementations from different sources (Multiple Implementation Inheritance) • Multiple Interface Inheritance – Does not generate major technical problems – Supported by OMG IDL and Java • Multiple Implementation Inheritance – May cause problems if superclasses come from disjoint inheritance graphs

Diamond Inheritance • The Diamond Inheritance Problem – Superclasses may inherit code from a shared superclass further up the inheritance graph • Issues with State – Do classes B 1 and B 2 share A’s state? • Yes – Breaks encapsulation • No – Which state does class C see? • Issues with Behavior (or Method Implementations) – If B 1 and B 2 both override A’s methods, which version does C see? • Java’s Solution: – Support multiple interface inheritance, but only single implementation inheritance

Fragile Base Class Problem • Can a Base Class Evolve? • Syntactic Fragile Base Class Problem – Compatibility of compiled classes with new binary releases of superclasses – Unrelated to the semantics of inherited code • Semantic Fragile Base Class Problem – Can a subclass remain valid when the implementation of it’s superclass is changed?

Avoiding FBC Issues • Disciplined Inheritance – Define Rules to Allow Subclass Construction Based on a Superclass Specification • Allows subclasses to remain valid if superclass implementation changes • Object Composition – – – Messages are forwarded to other related objects Outer objects (requestor) Inner objects (helper) • Supports late composition (can be recompiled without recompiling it’s outer object)

Conclusion • Component Software is an Evolution of Object. Oriented Software • Implements Code Reusability • Addresses Traditional Software Development Issues • Provides Customers with Price/Performance Tradeoff Choices

Questions / Discussion