1. PAGE 1 Component Based Software Engg. Karthick Chinnaswami, Qualcomm Inc.

2. PAGE 2 Contents Mobile phone evolution Challenges Components Interfaces Virtual Function Tables Reference Counting QueryInterface Class Factory Dynamic Linking & Component Reuse Benefits of Componentization References

3. PAGE 3 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)

4. PAGE 4 Mobile Phone Evolution 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

5. PAGE 5 Mobile Phone Evolution 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.

6. PAGE 6 Mobile Phone Evolution 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

7. PAGE 7 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 !

8. PAGE 8 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 AComponent B Component DComponent C Component E Monolithic Application Component Application

9. PAGE 9 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

10. PAGE 10 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

11. PAGE 11 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

12. PAGE 12 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.

13. PAGE 13 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. pIXvtbl ptr &Fx1 &Fx2 &Fx3 &Fx4 Interface IFoo Virtual Function Table

14. PAGE 14 Virtual Function Tables 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(); // Constructor CBar (); private: int m_cbar; };

15. PAGE 15 Virtual Function Tables pBarvtbl ptr &Fx1 &Fx2 &Fx3 &Fx4 &m_cbar Fx1 Fx2 Fx3 Fx4 Client Interface IFoo CBar VTBL and class data for CBar

16. PAGE 16 Virtual Function Tables Multiple instances of a class share the same vtbl. pBar1vtbl ptr &Fx1 &Fx2 &Fx3 &Fx4 &m_cbar Fx1 Fx2 Fx3 Fx4 Client Interface IFoo CBar vtbl ptr &m_cbar pBar2

17. PAGE 17 Virtual Function Table Multiple classes derived from the same interface use the same vtbl format. For e.g. class CStick : public IFoo {... }; pBarvtbl ptr &Fx1 &Fx2 &Fx3 &Fx4 … Fx1 Fx2 Fx3 Fx4 Client CBar vtbl ptr … pStick &Fx1 &Fx2 &Fx3 &Fx4 Fx1 Fx2 Fx3 Fx4 CStick

18. PAGE 18 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

19. PAGE 19 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

20. PAGE 20 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 component HRESULT __stdcall CoCreateInstance ( const CLSID& clsid, IUnknown* pIOuter, DWORD dwClsContext, const IID& iid, void **ppIFace);

21. PAGE 21 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

22. PAGE 22 Containment vs Aggregation

23. PAGE 23 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

24. PAGE 24 Benefits of Componentization Component Libraries  Why reinvent the wheel ?  Reuse Distributed Components  Components can be located across process, processor and network boundaries

25. PAGE 25 References Inside COM – Dale Rogerson Component Software – Clemens Szyperski http://en.wikipedia.org/