1 / 42

Re-usable Software Component Technology

Re-usable Software Component Technology. Author: Hans v Leunen Editors: Henk de Vries & William Ringer. Pillars. The technology comprises two pillars: Embeddable software component technology Open market mechanism

cala
Download Presentation

Re-usable Software Component Technology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Re-usable Software Component Technology Author: Hans v Leunen Editors: Henk de Vries & William Ringer

  2. Pillars • The technology comprises two pillars: • Embeddable software component technology • Open market mechanism • Together these pillars empower the embedded software community with a thousand times higher efficiency • It enables the software industry to keep pace with the hardware developments

  3. A managers view onto the subject An in depth treatise for the technically interested Choose your trail

  4. Definition: Re-usable Software Components • ‘Components’ are secure re-usable software modules with defined interfaces • Functionality can only be accessed through interfaces • Intellectual Property (IP) is hidden securely within the component • Components can be preplanned by means of development tools • The infrastructure controls the establishment and the release of connections • Connections can be fixed or dynamic

  5. Definition: Re-usable Software Components Packages • Components Binary Package • Load library • Collection of binary implementations of component classes • Components Package Specification • Formal specification document • Collection of references to Component Class Specification documents • NOT like layered software subsystems: • Defined by an Application Programming Interface (API) to a set of functions • With complex relations with other system parts • With no constructs for guarding integrity

  6. Interfaces • Re-usable Components have interfaces • Each interface is a set of coherent methods • An interface can be easily understood • NOT like layered software architecture subsystems that: • Have a single API that contains many functions • A complete API is difficult to comprehend

  7. Assets • Re-usable Components hide their assets • indirect access of asset values is such that the integrity of the component is secure • this is controlled by the component designer • NOT like layered subsystems assets • Are often globally accessible • Cannot defend against abuse of its assets

  8. Implementation • Re-usable Components • Use a well defined binary component model • Are reusable on hardware platforms that correspond with their binary component model • OS independent • NOT like layered software subsystems • Have no defined implementation • Are reusable in a limited context that depends on the OS and on the hardware platform

  9. B FuncB4 Under the control of the infrastructure Robust Component Object Model hidden QueryAccessPoint IAccessor hidden ResetInstance FuncA3 FuncA4 A hidden FuncA5 hidden hidden FuncA6 QueryAccessPoint B hidden ResetInstance FuncB3 FuncB4 reqItf1 FuncB5 conReq hidden reqItf2 Vtbl A hidden hidden hidden hidden Class data Instance data Vtbl B

  10. Relational complexity problem statement • Relational complexity makes software generation and system configuration increasingly hard to manage • Relational complexity is measured by the number of potential relations that exist between functional elements • Is determined by the square of the number of potentially related functional elements n*(n-1)

  11. Relational Complexity in Monolithic System or Part n = Nr of related items n(n-1)/2 potential relations

  12. In numbers • 100 items  99 • 100 potential relations • 1000 items  999 • 1000 potential relations • 10 modules containing 100 items  maximally 99 • 100 potential relations inside a module plus 9 • 10 relations between modules. • Nobody sees more than 9990 relations!!!

  13. Why measure with potential relations? • Every expert started as a novice • The number of available experts is limited • For a novice all potential relations are equally relevant • The manageability of the software generation process is directly affected • An automaton must traverse all potential relations • Tools are easier to develop when relational complexity is low

  14. Impact • The reduction of the potential relational complexity has the largest impact when systems are completely built as component based systems • Currently all systems that apply software components apply components embedded in a relatively small subsystem • This is why nobody has got a proper feel for the real power of software component technology

  15. Complexityin Component Based Systems Gain: easily three orders of magnitude Environment Gain: easily two orders of magnitude Configuration: Easily three orders of magnitude better than monolithic case

  16. Manageability of component generation • The manageability of generating Component based software is about two orders of magnitude (100 times) better than generating monolith system software • NOT like layered subsystem software where manageability is only slightly better than generating monolith software

  17. Manageability of system configuration • Managing the configuration of a system based on Re-usable Components is about three orders of magnitude (1000 times) better than that of layered subsystems • Task is accomplished by an easy to use tool • NOT like the configuration of a system based on layered subsystems • A big challenge for the architect of large and complex layered subsystem architectures

  18. Specification completeness • Re-usable Components are easy to specify completely • Modest size and low complexity • Static and dynamic characteristics • Only completely specified components can be reliably tested and can be guaranteed • NOT like layered subsystems • Due to growing size and complexity of subsystems it becomes increasingly difficult to give a complete specification of a subsystem

  19. Ability to trade Re-usable Components in an open market • Re-usable Components can be licensed to others • No access to encapsulated Intellectual Property • Easy marketing due to complete specification and standardized component model • NOT like layered subsystems • Due to complexity and low manageability layered subsystems can only be used in closed communities

  20. End

  21. Definition: Re-usable Software Components • ‘Components’ are secure re-usable software modules with defined interfaces • Functionality can only be accessed through interfaces • Intellectual Property (IP) is hidden securely within the component • Components can be preplanned by means of development tools • The infrastructure controls the establishment and the release of connections • Connections can be fixed or dynamic

  22. Definition: Re-usable Software Components Packages • Components Binary Package • Load library • Collection of binary implementations of component classes • Components Package Specification • Formal specification document • Collection of references to Component Class Specification documents • NOT like layered software subsystems: • Defined by an Application Programming Interface (API) to a set of functions • With complex relations with other system parts • With no constructs for guarding integrity

  23. A sample package specification • <?xml version="1.0" ?>-<pkg:Package Final="true" Name="BKEGameControlPackage2" Location="http://www.component-industry.org/repository/scitech_nl_repository/reusablesstore/scitech_nl_reusables/Package/BKEGameControlPackage2/BKEGameControlPackage2.pkg" Description="This is the control part of the tic-tac-toc game"MyLanguage="Cplusplus"MyPackageType="Skeleton"NamePrefix="gcp"Originator="http://www.component-industry.org/repository/scitech_nl_repository/reusablesstore/scitech_nl_reusables/Package/BKEGameControlPackage2/BKEGameControlPackage2.pkg"schemaLocation="Package_schema ../Package.xsd" ThePID="01f9929c-7263-4b30-a8d9-81a17e87ebe6" xmlns:pkg="package_schema"><pkg:ParentPackageReference Name="NoName" />-<pkg:Classes OneOrMore="true"><pkg:Class Name="BKEGameControlClass0"Location="http://www.the_origin_substitute.none/reusablesstore/scitech_nl_reusables/componentclass/bkegamecontrolclass0/bkegamecontrolclass0.cif" /> <pkg:Class Name="BKEGameControlClass"Location="http://www.the_origin_substitute.none/reusablesstore/scitech_nl_reusables/componentclass/bkegamecontrolclass/bkegamecontrolclass.cif" /></pkg:Classes>-<pkg:Categories OneOrMore="true"><pkg:CategoryName="BKE"OwnerFileName="BKEGameControlPackage1.pkg"OwnerType="Package" /></pkg:Categories></pkg:Package>

  24. Package Manager Instancemanager Instancemanager Instancemanager Instancemanager cls cls inst inst cls cls inst inst Load modules Package Package contents Infrastructure services Application Implementation

  25. Interfaces • Re-usable Components have interfaces • Each interface is a set of coherent methods • An interface can be easily understood • NOT like layered software architecture subsystems that: • Have a single API that contains many functions • A complete API is difficult to comprehend

  26. AudioVolume (intnValue) TuneFrequency (intnValue) AudioBalance (intnValue) TuneBand (intnValue) AudioTone (intnValue) TuneSearch (boolbUp) AudioMute (boolbOn) TuneStore(intnBand) MenuSelect (intnSel) VideoLuminance(intnValue) TapePlay (intnMode) VideoContrast(int nValue) MenuMove (boolbUp) TapeRecord (boolbOn) MenuGroup (boolbUp) VideoColor(intnValue) TapeWind (boolbUp) MenuOn(bool bOn) TapeEject() Application Programmers Interface Modularisation

  27. TaskManager API VideoLuminance(intnValue) TapePlay (intnMode) MenuSelect (intnSel) VideoContrast(intnValue) TapeRecord (boolbOn) MenuMove (boolbUp) VideoColor(intnValue) TapeWind (boolbUp) MenuGroup (boolbUp) AudioVolume (intnValue) AudioTone (intnValue) AudioMute (boolbOn) AudioBalance (intnValue) API TuneFrequency (intnValue) TuneStore(intnBand) TuneSearch (boolbUp) TuneBand (intnValue) TapeEject() MenuOn(boolbOn) Application Programmers Interfaces

  28. Base class1 Extended class1a Attribute1Attribute2 Attribute1Attribute2Attribute3 Int_1 Method11Method12 Int_1 Method11Method12 Int_2 Method21Method22Method23 ExtInt_2 Method21Method22Method23Method24 Int_3 Method31Method32 Base & extended elements • Additional attributes • Additional interfaces • Additional methods per interface • Additional class CLSID • Additional IID for extended interfaces

  29. Assets • Re-usable Components hide their assets • indirect access of asset values is such that the integrity of the component is secure • this is controlled by the component designer • NOT like layered subsystems assets • Are often globally accessible • Cannot defend against abuse of its assets

  30. Implementation • Re-usable Components • Use a well defined binary component model • Are reusable on hardware platforms that correspond with their binary component model • OS independent • NOT like layered software subsystems • Have no defined implementation • Are reusable in a limited context that depends on the OS and on the hardware platform

  31. B FuncB4 Under the control of the infrastructure Robust Component Object Model hidden QueryAccessPoint IAccessor hidden ResetInstance FuncA3 FuncA4 A hidden FuncA5 hidden hidden FuncA6 QueryAccessPoint B hidden ResetInstance FuncB3 FuncB4 reqItf1 FuncB5 conReq hidden reqItf2 Vtbl A hidden hidden hidden hidden Class data Instance data Vtbl B

  32. Relational complexity problem statement • Relational complexity makes software generation and system configuration increasingly hard to manage • Relational complexity is measured by the number of potential relations that exist between functional elements • Is determined by the square of the number of potentially related functional elements n*(n-1)

  33. Relational Complexity in Monolithic System or Part n = Nr of related items n(n-1)/2 potential relations

  34. In numbers • 100 items  99 • 100 potential relations • 1000 items  999 • 1000 potential relations • 10 modules containing 100 items  maximally 99 • 100 potential relations inside a module plus 9 • 10 relations between modules. • Nobody sees more than 9990 relations!!!

  35. Why measure with potential relations? • Every expert started as a novice • The number of available experts is limited • For a novice all potential relations are equally relevant • The manageability of the software generation process is directly affected • An automaton must traverse all potential relations • Tools are easier to develop when relational complexity is low

  36. Impact • The reduction of the potential relational complexity has the largest impact when systems are completely built as component based systems • Currently all systems that apply software components apply components embedded in a relatively small subsystem • This is why nobody has got a proper feel for the real power of software component technology

  37. Complexityin Component Based Systems Gain: easily three orders of magnitude Environment Gain: easily two orders of magnitude Configuration: Easily three orders of magnitude better than monolithic case

  38. Manageability of component generation • The manageability of generating Component based software is about two orders of magnitude (100 times) better than generating monolith system software • NOT like layered subsystem software where manageability is only slightly better than generating monolith software

  39. Manageability of system configuration • Managing the configuration of a system based on Re-usable Components is about three orders of magnitude (1000 times) better than that of layered subsystems • Task is accomplished by an easy to use tool • NOT like the configuration of a system based on layered subsystems • A big challenge for the architect of large and complex layered subsystem architectures

  40. Specification completeness • Re-usable Components are easy to specify completely • Modest size and low complexity • Static and dynamic characteristics • Only completely specified components can be reliably tested and can be guaranteed • NOT like layered subsystems • Due to growing size and complexity of subsystems it becomes increasingly difficult to give a complete specification of a subsystem

  41. Ability to trade Re-usable Components in an open market • Re-usable Components can be licensed to others • No access to encapsulated Intellectual Property • Easy marketing due to complete specification and standardized component model • NOT like layered subsystems • Due to complexity and low manageability layered subsystems can only be used in closed communities

  42. End

More Related