Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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
• 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
Choose your trail
• A managers view onto the subject
• An in depth treatise for the technically interested
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
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
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
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
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
Robust Component Object Model
hidden
hiddenreqItf2conReqreqItf1
hidden
hidden
hidden
hidden
hidden
hidden
hidden
hiddenQueryAccessPoint
ResetInstance
FuncB3FuncB4FuncB5
QueryAccessPointResetInstanceFuncA3
FuncA6
FuncA4FuncA5
Instancedata
Vtbl AVtbl A
VtblVtbl B BClass dataClass data
AA
BB
hidden
IAccessor
BB
FuncB4
Under the control of the infrastructure
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)
Relational Complexity in Monolithic System or Part
n(n-1)/2 potential relations n = Nr of related items
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!!!
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
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
Environment
Complexity in Component Based Systems
Configuration: Easily three orders of magnitude better than monolithic case
Gain: easily two orders of
magnitude
Gain: easily three orders of magnitude
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
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
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
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
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
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
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:Category
Name="BKE" OwnerFileName="BKEGameControlPackage1.pkg" OwnerType="Package" />
</pkg:Categories> </pkg:Package>
Package contents
Load modulesPackage
Instancemanager Instance
manager
Instancemanager
Instancemanager
Package Manager clscls
cls
clsinst
inst
instinst
Infrastructure servicesApplication Implementation
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
Application Programmers Interface Modularisation
AudioVolume (int nValue)
AudioBalance (int nValue)
AudioMute (bool bOn)
AudioTone (int nValue)
VideoLuminance (int nValue)
VideoContrast (int nValue)
VideoColor (int nValue)
TuneFrequency (int nValue)
TuneBand (int nValue)
TuneStore(int nBand)
TuneSearch (bool bUp)
TapePlay (int nMode)
TapeRecord (bool bOn)
TapeEject()
TapeWind (bool bUp)
MenuSelect (int nSel)
MenuMove (bool bUp)
MenuOn(bool bOn)
MenuGroup (bool bUp)
Application Programmers Interfaces
AudioV
olume (int nV
alue)
AudioB
alance (int nValue)
AudioM
ute (bool bOn)
AudioT
one (int nValue)
VideoL
uminance (int nV
alue)
VideoC
ontrast (int nValue)
VideoC
olor (int nValue)
TuneF
requency (int nValue)
TuneB
and (int nValue)
TuneS
tore(int nBand)
TuneS
earch (bool bUp)
TapeP
lay (int nMode)
TapeR
ecord (bool bOn)
TapeE
ject()
TapeW
ind (bool bUp)
MenuS
elect (int nSel)
MenuM
ove (bool bUp)
MenuO
n(bool bOn)
MenuG
roup (bool bUp)
TaskManager
API
API
Base & extended elements
Int_3Method31Method32
Attribute1Attribute2Attribute3
Method11Method12
Method21Method22Method23Method24
Extended class1a
Int_1
ExtInt_2
•Additional attributes
•Additional interfaces
•Additional methods per interface
•Additional class CLSID
•Additional IID for extended interfaces
Attribute1Attribute2
Method11Method12
Base class1
Int_1
Method21Method22Method23
Int_2
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
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
Robust Component Object Model
hidden
hiddenreqItf2conReqreqItf1
hidden
hidden
hidden
hidden
hidden
hidden
hidden
hiddenQueryAccessPoint
ResetInstance
FuncB3FuncB4FuncB5
QueryAccessPointResetInstanceFuncA3
FuncA6
FuncA4FuncA5
Instancedata
Vtbl AVtbl A
VtblVtbl B BClass dataClass data
AA
BB
hidden
IAccessor
BB
FuncB4
Under the control of the infrastructure
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)
Relational Complexity in Monolithic System or Part
n(n-1)/2 potential relations n = Nr of related items
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!!!
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
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
Environment
Complexity in Component Based Systems
Configuration: Easily three orders of magnitude better than monolithic case
Gain: easily two orders of
magnitude
Gain: easily three orders of magnitude
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
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
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
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
