Toward A FundamentalsBased Perspective for ComponentBased Software Development

1
Toward A Fundamentals-Based Perspective for
Component-Based Software Development

• Allen Parrish
• Department of Computer Science
• The University of Alabama
• Tuscaloosa, AL 35487
• parrish_at_cs.ua.edu

2
Historical Perspective

• 1980s Several academic treatments
• Booch components, Bertrand Meyer
• RESOLVE (Ohio State)
• Reuse community contributions
• Recent impetus
• Commercial technology (OLE, COM, Active-X, etc.)
• Distributed object systems
• Client-server systems
• Recent commercial advances hold great promise,
  but
• Not much underlying intellectual content

3
Why No Intellectual Content?

• Reliance on wizards to automate the programming
  process (cookbook approach)
• Commercial world not that interested in providing
  intellectual content
• No basic textbooks really provide an intellectual
  perspective
• Teach Yourself X in 14 Days is the standard
  source of information

4
Some Proposed Conceptual Foundations

• Binary component Separate piece of executable
  code.
• Binary component as an underlying intellectual
  concept
• Consistent with Szyperskis view in recent
  popular CBSD text
• Binary component provides foundations to (at
  least) two areas
• Component-based software deployment
• A technology-independent pedagogy

5
Component-Based Software Deployment

• Deployable application Set of binary components
• Not all component sets belonging to different
  applications are necessarily disjoint

6
Typical Scenario
B

A
J
K
H
D
C
E
L
I
F
G
Application 2
Application 1
7
DLL Hell

• DLL Dynamic Link Library
• Windows canonical binary components
• Problem Installing Application 2 includes a new
  version of H or I
• Application 1 no longer works
• This problem comes in several forms
• Recent white paper by Microsoft entitled The End
  of DLL Hell with Windows 2000

8
Our Deployment Work

• Recognizes that the deployment of binary
  components is not just a commercial problem with
  a proprietary solution.
• Characterizes formal conditions under which a
  deployment is
• Safe No existing applications are damaged.
• Successful The application being installed
  actually works.

9
Some Basic Terms

• Application Set of components
• Desktop system Set of applications
• Component family Made up of components that
  implement the same concept
• Each component in family is just a version of the
  same concept

10
Installation

• Can think of two levels of installation
• Component installation
• Application installation
• Component installation issue
• What if a component of the same family is already
  installed?
• Some component installation strategies
• Replace Always (RA)
• Replace Only If Newer (ROIN)
• Never Replace (NR)
• Install Separately (IS)

11
Forward and Backward Compatibility

• Backward Compatibility (BC) New component works
  with older applications
• Forward Compatibility (FC) Old component works
  with newer applications.

12
Some Selected Results

• IS always guarantees safety and success.
• With this strategy there is no sharing of
  components
• All components will always be installed and used
  as part of the application.
• No components in the installation affect other
  applications.

13
Example
Existing Application A
New Application B (components installed under IS)
14
One More Result

• ROIN for all components guarantees safety,
  whenever all components replacing existing
  components are BC.
• For components not replaced Those components
  work with existing applications as always
• For components that replace existing components
  The replacements are newer and must work with
  existing (older) applications.

15
Example
Existing Shared Components
A
B

J
G
C
H
E
D
E
D
New Application After Installation
G
New Application
J
H
Assume X newer than X
E
D
16
Summary
17
Contribution of this Work

• Safety conditions and associated formalism
  contribute to a formal conceptual framework
• Software installation is elevated from an ad hoc
  process to a process with some theoretical
  foundations
• Most results confirm the obvious
• Absence of results totally intuitive discourse
  lack of clarity

18
A Slightly Higher Level A Three Dimensional Model

• Based on the number of components to be
  installed
• Full installation All components
• Service pack installation Only those components
  to be upgraded
• Based on whether concurrent multiple versions are
  supported
• In-place installation New version goes on top of
  old version
• Version-separate installation New version goes
  in different location from old
• Based on whether application shares components
  with other applications
• Independent installation No shared components
• Dependent installation Contains shared
  components with other applications

19
A Technology-Independent Pedagogy

• Idea Would like to present abstract
  underpinnings of commercial CBSD technologies
• Use one or two technologies as specific models
• Avoid wizards as much as possible
• Avoid discussion of arcane witchcraft
  procedures that dont have intellectual
  justification

20
Our Approach

• Introduce concepts, models, etc. where possible
• Taxonomies of types of components and approaches
• Binary vs. source components/architectures
• Our deployment theory
• Use lightweight approaches to component
  construction before heavyweight ones
• Plain DLLs Simplest possible binary components
• Incremental introduction of more advanced CBSD
  approaches.

21
Conceptual Framework
ODBC, CORBA, COM, Active X
Component deployment
Standards and middleware
Run-time binary components
DLLs
Software modularity
Classes, interfaces, specification
22
Outline of Topics

• Fundamental component concepts
• Component, interface, implementation
• Components as source code
• Binary components
• Dynamic link libraries
• Component-based software deployment
• Standards/packaging mechanisms
• ODBC
• COM
• CORBA
• Active X

23
Case Study Project

• Simple point-of-sale transaction system
• Three-tier architecture
• User interface component (UIA, UIB, UIC, )
• Business logic component (MTA, MTB, MTC, )
• Database component (DSA, DSB, DSC, )
• Several versions
• Version 1 Only purchase one of an item
• Version 2 Multiple quantity purchases
• Version 3 GUI introduced
• Version 4 Data source ODBC compliant
• Version 5 CORBA-based, client-server system

24
Incremental Development

• (Assignment 1) Build components in source code
  (C) using good encapsulation practices. Deploy
  Versions 1 and 2.
• (Assignment 2) Repackage components in DLLs to
  obtain binary component reuse. Deploy Versions 1
  and 2 built in this fashion.
• (Assignment 3) Develop distribution Web site to
  support component-based deployment
• Download a version get needed components
• (Assignment 4) Build components needed to upgrade
  to Version 3 (GUI).
• (Assignment 5) Build components needed to upgrade
  to Version 4 (ODBC).
• (Assignment 6) Build components needed to upgrade
  to Version 5 (Client-server)

25
Component-Based Design

• File format issues localized to database
  component
• Qty vs. one-instance localized to user interface
  and business logic components
• Interface presentation localized to user
  interface component

26
Component Architecture
Version 1 (basic)
Data file
UIA
MTA
DSA
EXE/C
DLL/C
DLL/C
Version 2 (choose quantity)
Data file
UIB
MTB
DSA
EXE/C
DLL/C
DLL/C
27
Component Architecture (cont.)
Version 3 (GUI)
Data file
UIC
MTB
DSA
WRA
EXE/VB
State-based DLL/C
DLL/C
DLL/C
Version 4 (ODBC)
Data base
UIC
MTB
DSB
WRA
EXE/VB
State-based DLL/C
DLL/C
DLL/C
28
Component Architecture (cont.)
Version 5 (Client/Server)
Data base
UIC
MTB
DSB
WRA
CORBA
EXE/VB
State-based DLL/C
DLL/C
DLL/C
Server
Client
29
Application Deployment

• Component-based deployment models
• Full installation
• Service pack (upgrade) installation
• Used InstallShield to build installations
• Students had to build a Web site to host
  installations

30
Additional Enhancement (planning stages)
Version 3
UIC
MTB
DSA
WRA
State-based C DLL
DLL/C
DLL/C
VB GUI
COM version no need for wrapper
UID
MTB
DSA
COM DLL
COM DLL
VB GUI
COM provides better component-level
interoperability COM tends to hide details, so
students may understand less!
31
Summary and Future Work

• Some proposed intellectual foundations
• Binary components
• Deployment theory and framework
• Incremental approach allows us to
• Explain underlying concepts in the context of a
  minimum of technology.
• Future work
• Extend the case study to include COM/DCOM
• Continue upgrading conceptual course materials
• Web site http//cs.ua.edu/components/grant.
• CD with course materials also available by
  request.