ComponentBased Software Engineering

1
Component-Based Software Engineering

• Alexander L. Wolf
• University of Colorado
• alw_at_cs.colorado.edu

2
Software Engineering

• Software
• Computer programs and their related artifacts
• Engineering
• The application of scientific principles in the
  context of practical constraints

3
A Definition (Daniel M. Berry)

• Software engineering is that form of engineering
  that applies
• a systematic, disciplined, quantifiable approach,
• the principles of computer science, design,
  engineering, management, mathematics, psychology,
  sociology, and other disciplines,
• to creating, developing, operating, and
  maintaining cost-effective, reliably correct,
  high-quality solutions to software problems

4
Component-Based Software Engineering

• Development as component assembly, rather than as
  system construction
• Market structure (a Capitalist view)
• Component suppliers
• System integrators
• Analogies
• Civil engineering industry
• Airplane manufacturing

5
Components
Binary units of independent production,
acquisition, and deployment that interact to form
a functioning system. - Clemens Szyperski
6
Components through History

• Procedure or function
• Class or type
• Module or package
• DBMS, GUI, application
• Plug-in, applet, aglet, servlet

7
Component Packaging

• Source code
• Byte code
• Object code
• Library
• Executable (loadable image)
• Service (running image)

8
Generalized Development Characteristics
9
Two Extremes of Software Development

• Custom-made software
• Optimally adaptable
• Directly controllable
• Expensive
• Requires broad expertise
• Limited interoperability
• Large inertia
• Example ATC System

• Standardized software
• Amortized costs
• Higher quality
• Interoperable
• No market advantage
• Large inertia
• Example Windows 95

10
Component Software as a Compromise

• Advantages
• Standard components
• Custom components
• Customizable systems
• Incremental upgrade
• Decentralized expertise
• Market competition

• Disadvantages
• Lack of control
• Decentralized expertise
• Market competition

11
Component Marketplace

• Software ICs (Mcllroy, 1968)
• Technically superior components can fail
• Example PCTE
• Market requires critical mass
• Components of sufficient variety and quality
• Obvious benefit (e.g., build/buy cost ratio)
• implication for granularity of components
• Backed by strong resources

12
Components as Reusable Assets
Imperfect technology in a working market is
sustainable perfect technology without any
market will vanish. - Clemens Szyperski

• Designing general solution more difficult than
  specialized solution
• Work in multiple contexts and usable by unknowns
• Components viable only if investment returned by
  deployment
• Market pull versus market push

13
Forms of Design-Level Reuse

• Consistency ? languages and environments
• Solution fragments ? libraries
• Protocols ? interfaces
• Interaction structures ? patterns
• Subsystem structures ? frameworks
• System structures ? architectures
• Methods ? software process

14
Standards

• Architectural models
• Enable assignment of component functionality
• Communication models
• Enable interoperability
• Concrete interface specifications
• Enable composition

15
Venders ? Environments ? Clients

• 1 ? 1 ? 1 (the trivial case)
• Vender can exactly understand needs of client
• Example Sole-source for data management
• As numbers increase, chances of single component
  working in all environments and satisfying needs
  of all clients decreases
• Standards serve to constrain the numbers
• Independent of source of standard
• Committee or market leader

16
Wiring Standards not Sufficient

• Syntactic, so easiest part of component assembly
  problem
• Domain- and application-specific aspects (i.e.,
  semantics) also critical for success
• Example OMG industry committee
• First introduced CORBA, a wiring standard
• Then introduced services as application standards
• Counter example Microsoft market leader
• Grew standards (e.g., OLE, COM) by generalizing
  from successful products (i.e., applications)

17
Simplistic Analogies

• Toys (Lego blocks)
• Simple components can combine to form complex
  systems
• Entertainment (plug and play)
• Well-defined interfaces allow components from
  different vendors to be easily connected
• Other engineering disciplines
• Handbook of building blocks and analyses
• Training centers on experiencing techniques for
  finding and applying building blocks

18
Example Chemical Engineering
Chemical engineering evolved from a mixture of
craft, mysticism, wrong theories, and empirical
guessesImprovements were very slow until the
Scientific RevolutionOnly then were mystical
interpretations replaced by scientific theories
though the early theories were often wrong,
theyplayed a leading role in stimulating
thought. - J.T. Davies
19
Example Chemical Engineering

• Interesting historical points
• Theory ignored by engineers
• Hacking worked until problems of scale
• Scale problems solved by development of
  relatively small number of unit operations
• distillation, evaporation, filtration,
  absorbtion,
• Handbook of chemical engineering developed
• Fundamental difference from Soft. Engineering
• Software not naturally constrained
• Richness comes from unbounded variety

20
Scale and Granularity of Components

• Driven by two forces
• Application requirements
• Catalog of available components
• Principal criteria

• Abstraction
• Accounting
• Analysis
• Compilation
• Delivery
• Dispute

• Extension
• Fault containment
• Instantiation
• Loading
• Locality
• Maintenance

21
Example IT Infrastructure of Union Bank
Customer Information Services
Authorization Services
Trading Workstation
Product Database Services
Marketing Services
Host Services
22
Example Boeing 777 Configuration Man.

• Scale
• 3,000,000 parts per aircraft
• Configuration of every aircraft is different
• CAA regulations demand that records are kept for
  every single part of aircraft
• Aircraft evolve during maintenance
• Configuration database grows by 1.5 billion parts
  each year
• Projected life of each aircraft 30 years
• 45,000 engineers need on-line access to
  engineering data

23
Example Boeing 777 (cont.)

• COTS Integration
• Existing IT infrastructure inappropriate
• Boeing could not afford new IT infrastructure
• Components were purchased from several different
  specialized vendors
• Relational database technology
• Enterprise resource planning
• Computer-aided project planning
• But, components needed to be integrated

24
Example Boeing 777 (cont.)

• Heterogeneity
• 20 Sequent database machines as servers for the
  engineering data
• 200 UNIX application servers
• NT and UNIX workstations for engineers

25
Historical Influences

• Software Engineering
• Programming Languages
• Database Systems
• Operating Systems
• Network Systems

26
Historical Influences Soft. Engineering (1)

• ADTs, Modularity, and Encapsulation
• Restricted set of operations on user-defined data
• Logical grouping of related system elements
• Separation of interface from implementation
• Specification of imported and exported resources
• Reuse and Design Patterns
• Design for generality, cost models, and
  cataloging
• Configuration Management
• System models and version selection mechanisms

27
Historical Influences Soft. Engineering (2)

• Design Methods
• Guidelines for modularity
• Formal specifications
• Software Architecture
• Component, connection, and system specification
• Testing and Analysis
• Behavioral sampling and correctness
• Buses, Backplanes, and Frameworks
• Distillation of common services

28
Historical Influences Soft. Engineering (3)

• Buses (or correctly busses)
• Communication infrastructure
• Event-based component integration
• Examples Field MSG, Sun ToolTalk
• Backplanes
• Service infrastructure based on slots
• Common GUI, DB, and communication
• Example Atherton Software Backplane

29
Historical Influences Soft. Engineering (4)

• Frameworks
• Common set of classes for building applications
• Example Smalltalk model view controller
• Example Apple OpenDoc

30
Historical Influences Prog. Languages

• Linguistic constructs capturing best SE practice
• ADTs, modules, and module interconnection
• Type checking and separate compilation
• ADT and encapsulation enforcement
• Inheritance and templates/generics
• Reusable interfaces and implementations
• Scripting languages
• Interpreted, lightweight, application-specific
  specification of service requests

31
Historical Influences Database Systems

• Distributed services
• Client/server architecture
• Standard scripting language
• SQL
• Heterogeneous interoperability
• Multi-databases

32
Historical Influences Operating Systems

• Communication mechanisms
• Asynchronous messaging (IPC, mailboxes, )
• Remote procedure call
• Sockets
• Distribution mechanisms
• Networks of workstations
• Distributed shared memory
• Service abstractions
• Micro-kernel architectures

33
Historical Influences Network Systems

• Open communication standards
• ISO OSI reference model
• Transport protocols
• TCP reliable and connection oriented
• UDP unreliable and connectionless
• HTTP layered on top of TCP
• Naming services
• DNS hierarchical and Internet scale
• URL/URI layered on top of DNS

34
Key Technical Challenges

• Middleware for Component Assembly
• Predicting and Attaining Performance
• Avoiding and Handling System Failures
• Further Complications
• Both early and late assembly
• Assembly by novices

35
Key Technical Challenge Middleware

• Context
• Heterogeneous components
• Inter-component communication/synchronization
• Value-added functionality from integrator
• Middleware
• Architectural model
• Nature and boundary of common services
• Tailorability

36
Key Technical Challenge Performance

• Context
• Components implemented in isolated context
• System performance dependent on performance of
  components, middleware, and their interactions
• Performance
• Scaling
• Hot components
• Performance calculus

37
Key Technical Challenge Failures

• Context
• Components built by one party system used by
  second party system assembled by third party
• Component-based systems only as strong as their
  weakest component
• System Failures
• Responsibility
• Isolation
• Avoidance

38
General Issues Arising from Challenges

• Component independence is an illusion
• Component interfaces and behavior must be
  specified
• Modular, compositional approach to specification
  and analysis is required
• Functionality
• Performance
• Reliability

39
Sources

• Component Software Beyond Object-Oriented
  Programming, C. Szyperski, Addison Wesley,
  Harlow, England, 1998.
• Engineering Distributed Objects, W. Emmerich,
  Wiley, 1999.
• Proceedings 1998--2003 Workshop on
  Component-Based Software Engineering,
  http//www.sei.cmu.edu/cbs/