page 1 component based software engg. karthick chinnaswami, qualcomm inc

Component Based Software Engg.Karthick Chinnaswami, Qualcomm Inc.

Contents

• Mobile phone evolution

• Challenges

• Components

• Interfaces

• Virtual Function Tables

• Reference Counting

• QueryInterface

• Class Factory

• Dynamic Linking & Component Reuse

• Benefits of Componentization

• References

Mobile Phone Evolution

• Mid 90s - late 90s Voice was the key feature Digital (GSM/CDMA-IS95) vs AMPS Total memory size (RAM & ROM) less than 500K Real-time OS

– Basic priority based task scheduler

– Shared address space

– No file system

– No paging/virtual memory

Processor speeds around @10-15 Mhz Data storage on EEPROM Character-based monochrome displays Very limited data functionality SMS 3G Standards war (1x vs UMTS)


• Late 90s – early 2000s More data-oriented features (web browser etc.) Emergence of multimedia features (MIDI player, ringtone composer) Emergence of multimedia gaming (Java, BREW) Increased memory footprint (2-5 MB) Processor speeds around @40 Mhz File system support More sophisticated RTOS Bitmap displays with color Ehhanced Messaging Services (small pictures/icons & sounds) Interesting form factors – flips, sliders etc. Introduction of smartphone


• Early 2000s to Present Rollout of 3G networks

– Better data rates Mobile-PC convergence

– Smartphone revolution (Blackberry, Winmobile)

– IP based services (IMS) for better PC interoperability Enhanced multimedia features (Music player, video player/recorder, camera, video

telephony) GPS, Bluetooth, USB support Better/faster web browsers RTOS replaced by conventional OS tailored for mobile phones (Winmobile, Linux

etc.) Multimedia messaging services (MMS) Memory footprints around 64-256MB Much bigger display sizes (QVGA, VGA) and touchscreen capability.


• Looking ahead More convergence towards PC platforms

– Today’s mobile phone have processing power of yesterdays PCs.

Winmobile, Embedded Linux – more traditional OS entering mobile space 4G Standards war

– WiMAX vs Flash-OFDM

Growth of smartphones– No longer for the business user

– Most of the phones sold 5 years from now will be smartphones

iPOD/Mobile convergence– If you have a phone that can play music, why not have an iPOD that can make calls ?

Creation of a new market between mobiles and PCs– Origami or similar devices

Emergence of markup languages (like XML) for mobile software (especially UI applications) to facilitate better customization by end-user/operators

– Qualcomm’s UIOne framework

– Macromedia Flash

Challenges

• Mobile software has traditionally been written in C and most of the time critical portions, optimizations or hardware accelerated code handwritten in assembly• The size of the code in mobile devices has also increased tremendously over

the years (500K – 20 MB) which results in longer bootup times.• Modules take valuable memory space even though they may not be used at

all• Lot of inconsistencies between various modules (e.g. interfaces) • Redundancy (code duplication)• Not very scalable• Module upgrade (e.g. FOTA) is very challenging• Very difficult for customers & carriers to customize look and feel or behavior• Building the software takes hours – productivity drain !

Components

• Monolithic applications are very difficult to change, maintain and fix

• Applications need to be broken down into separate pieces or components

• As technology advances, new components can replace existing components

Component A Component B

Component DComponent C

Component E

Monolithic Application Component Application

Components

• Dynamic Linking Loaded on demand Ability to be replaced by newer versions

• Encapsulation Client interacts with components through an interface. Language independence

– Components can be implemented in any language. Interfaces are the contract between a component and its clients

– Interfaces can be specified in a language independent fashion (e.g. IDL – Interface Description Language) and run through an IDL compiler to generate appropriate language specific headers

– Shipped in binary

Components

Upgradeable and backwards compatible– Will not break existing users

– Protecting components from interface changes will not force client changes on component upgrades

Should be transparently relocatable– Can run in same process, different process or different machines

Definition of a Component

“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 composition by third parties”

- ECOOP, 1996

Interfaces

• The client communicates with the component only through its interfaces• Client has very little knowledge of the component as a whole• Interfaces protect system from change• Interfaces allow clients to treat different components in the same manner

(Polymorphism) A client can send data to a USB headset component the same way as it does with a Bluetooth

headset component if they support the same interface. Interfaces need to be small (less methods). More methods in an interface makes it more specific

and hence not reusable. e.g. a single helicopter interface vs multiple interfaces like flying, hovering, lifting etc.

• Interfaces encapsulate component specific behavior • Interfaces are immutable (COM, BREW)

During component upgrades, new interfaces are added and existing interfaces remain unchanged.

• A system of components is a set of components, each supporting a set of interfaces, each of which contains a set of functions.

Virtual Function Tables

• Defining a pure abstract base class defines a memory layout as shown. When a derived class inherits from an abstract base class, it inherits this memory structure.

interface IFoo { virtual void Fx1()=0; virtual void Fx2()=0; virtual void Fx3()=0; virtual void Fx4()=0;};

• This is automatically done for you in C++. COM & BREW take advantage of this layout for their implementation.

pIX vtbl ptr &Fx1

&Fx2

&Fx3

&Fx4

Interface IFoo

Virtual Function Table


• Vtbl pointer adds an extra level of indirection to the process of getting from an abstract base class pointer to a function. This enables us to separate an interface from its implementation.

class CBar: public IFoo{public:// IFoo

virtual void Fx1(); virtual void Fx2(); virtual void Fx3(); virtual void Fx4(); // ConstructorCBar ();

private:int m_cbar;

};


pBar vtbl ptr &Fx1

&Fx2

&Fx3

&Fx4

&m_cbar

Fx1

Fx2

Fx3

Fx4

Client

Interface IFooCBar

VTBL and class data for CBar


• Multiple instances of a class share the same vtbl.

pBar1 vtbl ptr &Fx1

&Fx2

&Fx3

&Fx4

&m_cbar

Fx1

Fx2

Fx3

Fx4

ClientInterface IFoo

CBar

vtbl ptr

&m_cbarpBar2

Virtual Function Table

• Multiple classes derived from the same interface use the same vtbl format. For e.g.class CStick : public IFoo {...};

pBar vtbl ptr &Fx1

&Fx2

&Fx3

&Fx4

…

Fx1

Fx2

Fx3

Fx4

Client

CBar

vtbl ptr

…

pStick

&Fx1

&Fx2

&Fx3

&Fx4

Fx1

Fx2

Fx3

Fx4

CStick

Reference Counting

• Enables the component to manage its lifetime rather than the client Components can support multiple interfaces and interface handles can be passed around

• Clients inform components when they want to use an interface and when they are finished using that interface

• All interfaces derive from IUnknown (COM) or IQI (BREW)interface IQI {

virtual int AddRef() = 0;

virtual int Release() = 0;

virtual int QueryInterface(const AEEIID iid, void **ppIFace) = 0;

};

• When a client gets an interface from a component (or creates another reference on an existing interface), the reference count is incremented

• When the client is finished using an interface, the reference count is decremented

• AddRef() increments reference count and Release() decrements reference count

QueryInterface

• Clients need an interface to ask a component for another interface

• In COM, all interfaces inherit from IUnknown This allows all interfaces to be treated as IUnknown interfaces All interfaces support QueryInterface which can be used to get other interfaces

supported by the component

• All interfaces have a Globally Unique ID (GUID) called Interface ID (IID) which is passed as a parameter into the QueryInterface method

Class Factory

• Components have a globally unique ID (CLSID) that uniquely identifies a component. Two components (with different CLSIDs) can support the same IID. For example,

Component A – CLSID_FORD and Component B – CLSID_TOYOTA can both support interface ICar – AEEIID_CAR

• COM GUIDs are 128 bit while BREW GUIDs are 32 bit

• COM provides CoCreateInstance function to create a componentHRESULT __stdcall CoCreateInstance (

const CLSID& clsid,

IUnknown* pIOuter,

DWORD dwClsContext,

const IID& iid,

void **ppIFace);

Dynamic Linking & Component Reuse

• Dynamic Linking Dynamic linking in COM is achieved by putting the component into a DLL For BREW, we use the BREW module loader

• Component reuse Containment

– Outer component is a client of inner component

– Outer component can also reimplement an interface supported by inner component by forwarding calls to the inner component

Aggregation– Outer component passes inner component’s interface pointer directly to client

– No specialization of aggregated component possible

Containment vs Aggregation

IY

IY

IX

IY

IX

Outer Component Outer Component

Inner Component Inner Component

Containment Aggregation

Benefits of componentization

• Dynamic Linking Not loaded until needed and unloaded after use

• Object-oriented Benefits of OO design

• Language independence Different Components can be written in different languages

• Interface is a contract Backwards compatibility Consistent interfaces

• Application customization Components can be replaced to meet user needs

Benefits of Componentization

• Component Libraries Why reinvent the wheel ? Reuse

• Distributed Components Components can be located across process, processor and network boundaries

References

• Inside COM – Dale Rogerson

• Component Software – Clemens Szyperski

• http://en.wikipedia.org/

page 1 component based software engg. karthick chinnaswami, qualcomm inc

Documents

mobile space

mobile devices

challenges mobile software

mobile phones winmobile

vs umts slide

s early

s late

valuable memory space