Introduction to ComponentBased Software Development

1
Introduction to Component-Based Software
Development

• CS 391 Edited/Abridged Notes
• Spring Semester, 1999
• Updated 9/16/99

2
What Is A Component?

• Definition
• A component is a software artifact that can be
  developed independently and inserted (in
  completed form) into a software system.
• Our (artificial) perspective Software components
  are programs or pieces of programs.
• Two views in this regard
• Source code
• Binary code
• We will ignore the perspective that components
  are sometimes viewed as other life-cycle
  artifacts.

3
Some Possible Types of Components

• Subprograms
• Classes
• DLLs
• COM objects
• GUIs (e.g., written in VB)
• Database access functions (e.g., ODBC-compliant)
• CORBA-based clients and servers

4
Some Basic Terminology

• Interface The part of a component that plugs
  in to the rest of the world.
• Implementation The internals of a component.
• General principle A component may depend on the
  interface of another component, but not its
  implementation.

5
Subprograms as Components

• Procedure sort (l list)
• sort can be implemented as bubblesort,
  quicksort, mergesort, heapsort, etc.
• Client code
• x list
• read(x)
• sort(x)
• Can have a component consisting of multiple
  subprograms (e.g., a library of subprograms)

6
SP Component Examples
interface
void foo(int x) cout ltlt x int blah(int
y) return y1
void sort(list l) actual sort code
interface
implementation
implementation
interface
void swap(int a, int b) int temp temp
a a b b temp
This is one component... Interface and
implementation are aggregates
implementation
7
Classes As Components

• Class definition (type definition function
  prototypes) Interface
• Method (function) definitions Implementation
• Can have a component consisting of multiple
  classes.
• Examples showing precise characterization of
  interface and implementation

8
Class Components
Class foo1 ... class foo2 ... foo1foo1
() foo1 foo1 foo2foo2() foo2 foo
2
class foo private int x int y public
foo() void a(int j) void b(int
k) foofoo() void fooa(int j) void
foob(int k)
interface
interface
implementation
implementation
9
Roles in a Component-Component Relationship

• Client component user
• Server component provider
• Invocation Client side of connection
• Some people refer to invocation side of
  connection as a uses interface
• Interface Server side of connection.

10
Source vs. Binary Components

• Source code components
• Functions, procedures
• Libraries
• Classes
• Binary components
• DLLs
• Active-X controls
• COM objects
• CORBA clients and servers
• Java beans
• Binary component Run-time binary component

11
Source vs. Binary Components

• Types of architectures
• Monolithic (no components)
• Component-based
• Possible source vs. binary architectures
• Monolithic source, monolithic binary
• Component source, monolithic binary
• Component source, component binary
• If source monolithic, binary cannot be
  component-based

12
Common Scenarios

• Component-based source, monolithic binary
  (classical approach with static builds)
• Component-based source and binary

13
CB Source, Monolithic Binary

• C Client and server components
• client.h client.cpp client component
• server.h server.cpp server component
• Each component is compiled
• Server.obj, client.obj
• Individual .obj files may be converted to .lib
  files
• .lib files may be stored in a library in binary
  form, and then linked into different applications
  at build time.
• Build step Individual .lib files are combined
  into a single .exe for the application.
• Example 60K client.lib 40K server.lib 100K
  client.exe.

14
Source and Binary Components

• Classical approach
• Build source code in individual source code
  components.
• Link components together statically.
• This means that you have to rebuild the entire
  system every time a component is modified or
  replaced.
• Binary components Treated as separate units at
  the executable system level.
• Example Dynamic Link Libraries (DLLs).
• .EXE file links to appropriate DLL at run-time.

15
Building a DLL in Visual Studio

• Start a new project. Choose Win32 DLL.
• Create an empty project (no files).
• Write the actual code for the project.
• Include the stanza
• __declspec(dllexport)
• Goes right after the word class for each class
  declaration that you wish to export.
• Compile and build the DLL.

16
Building a DLL-Compatible Client

• Start a new project. Choose Win32 Console
  Application.
• Create an empty project (no files) and write the
  code for the project.
• Include the header file for the DLL on the
  include line.
• Change the project settings to link to the static
  library for the DLL (go to the project settings
  menu, click the link tab and add an additional
  library file to the list of library files to link
  with).
• Build the .exe file from the appropriate build
  menu.

17
Binary Component Model

• Assume a two-component application as before.
• Each component is compiled as before.
• The server component is built separately. The
  output of this process is two-fold
• .dll file Dynamic link library, contains the
  actual executable code for the component
• .lib file Static link library, as above. The
  static link library contains only the code needed
  to locate a .dll file.

18
Binary Component Model

• The client component is built into an
  executable, by linking its .lib file with the
  .lib file for the server component.
• .lib file for the server component only contains
  code to direct server calls to the .dll.
• .exe and .dll files exist as separate executable
  components.

19
Model Comparison
CB source and binary
CB source, mono binary
Client.h
Server.h
Client.h
Server.h
Client.cpp
Server.cpp
Client.cpp
Server.cpp
Compile-time
Compile-time
Client.obj
Server.obj
Client.obj
Server.obj
Client.lib
Server.lib
Client.lib
Server.lib
60k
40k
Link-time
60k
4k
Link-time
Client.exe
Client.exe
Server.dll
Run-time
100k
64k
36k
Run-time
20
Advantages of CB Binary Architecture

• Applications can be upgraded via releasing a
  limited number of binary components
• Lower bandwidth upgrades
• Applications can share components
• Less disk space required to store applications
• Component reused in many applications
• Upgrading the component does not require
  rebuilding the (many) applications.

21
Interface Upgrades

• Upgrading implementation of a DLL doesnt impact
  the rest of the system.
• Upgrading interface of a DLL may impact clients.
• Multiple Interface Principle Dont every change
  the interface of binary component -- just export
  an additional interface.
• Simplest way to export multiple interfaces Just
  add a new class that exports the new interface
  (leaving the old code intact).
• Build new clients against the new interface.

22
When do you need to make a new interface?

• Changing the implementation - no.
• Adding one or more operations - probably not.
• Deleting an operation - yes.
• Changing the data representation for a class in
  the interface - yes.
• Stack case study example.

23
Deploying Your CB Binary Application

• Lots of different final product components in a
  typical software distribution
• Final product components include data files,
  documentation files, DLLs, EXEs, etc.
• Need to be able to control where things go in the
  file system (directory hierarchy)
• Need to be able to do flexible installations
  based on disk space availability
• As-needed replacements for upgrades

24
Types of Installations

• 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

25
InstallShield

• Application to build self-extracting archives
• Self-extracting archives are executables that
• Contain components in an installation
• Move installation components to appropriate
  locations in file system

26
Problems with Installations

• Installation can be a dangerous process.
• Ugly scenario
• New installation of application A contains
  version 2 of component C.
• Application A shares component C with
  applications B and C (already deployed).
• Applications B and C currently use version 1 of
  component C.
• B and C dont work with Version 2.
• This installation of application A is unsafe.

27
Some 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

28
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?
• Two component installation strategies
• Add Always (AA)
• Add Only If Newer (AOIN)

29
Safe Installation

• Fundamental idea
• Defining sufficient conditions under which an
  installation is safe (doesnt break anything)
• Needed
• Component installation strategies AA and AOIN
• A couple of other properties
• Application Disjointness (AD) Application being
  installed shares no component with any existing
  application
• Upgrade Compatibility (UC) Substituting a new
  component for a previous version in the same
  family doesnt damage the correctness of any
  application using previous version.

30
Sufficient Conditions for Safe Installation

• AD holds
• Either AA or AOIN will guarantee a safe
  installation.
• AD does not hold
• AA will not guarantee a safe installation
• AOIN and UC together will guarantee a safe
  installation

31
Other Issues Related to Installation Safety

• Uninstalls
• Distinguish between different installation
  models
• Shared vs. non-shared components
• Full installation vs. service pack installation
• Provide more complete treatment of various
  tradeoffs of different installation models
• Disk space consumption
• Network bandwidth
• Reuse
• Correctness

32
Multiple Language Issues

• Our objective Use Visual Basic to construct a
  GUI component that is a client of existing DLLs
  (constructed using C).
• Issues
• Data type mapping
• Minor (and sometimes major) inconsistencies in
  storage formats
• Inconsistent language features

33
Some things to know about Visual Basic

• Very suitable for GUI programming in that it lets
  you build the interface visually
• Event-driven programming Standard approach to
  GUI development
• Supports COTS component-based development with
  ODBC and Microsoft products

34
Some things to know about Visual Basic (cont.)

• Does not scale up well to applications that
  require new programming/component development
  (within VB itself)
• To compensate, does support multiple language
  interoperability

35
Options to Interface Multiple Languages

• Two basic options
• Complex interface Use industry standard
  middleware like COM, CORBA, etc.
• With a complex interface, you can pass complex
  objects across the interface.
• Simple interface Pass scalars and strings across
  the interface keep complex objects on the other
  side of the interface.
• Problems with complex interface
• No flexibility in VB to create objects with the
  complexity of C.
• Interface is necessarily more complicated as well
• We are going to adopt the simple interface
  strategy

36
Simple Interface Strategy

• Read scalar data in VB (strings, integers,
  floats, etc.)
• Pass the scalar data across the interface to C.
• Top-level interface component in C has the
  following properties
• Strictly functional interface (no classes
  interface is an aggregation of functions)
• State-based component (i.e., it owns a piece of
  the global state)

37
Interface Between VB GUI and VC DLLs

• Passing parameters across this interface - safe
  choices
• Scalars (integers, reals, characters and strings)
• Value parameters (declare ByVal in VB)
• Passing integers
• Long (VB) corresponds to int (VC)
• Integer (VB) corresponds to short (VC)
• Passing strings
• String (VB) corresponds to char (VC)
• Passing floats
• Single (VB) corresponds to float (VC)
• Double (VB) corresponds to double (VC)
• Currency (VB) can be passed to float or double
  (VC)