Module 4. Component Software 4.2 Introduction Notas del Dr. Hector Durán

Component Software

Introduction The term “component” is overloaded The term’s been used in the literature to mean different things Run-time entities Design-time entities Source code Executable code

Introduction (2) But one thing is for sure Components are for composition [Szyperski] Composition enables prefabricated “things” to be reused

Introduction (3) To become a reusable asset It isn’t enough to start with a monolithic design and then partition it into fragments The fragments have to be generalised to allow for reuse in different contexts Overgeneralisation has to be avoided to keep fragments lightweight

Introduction (4) Software components are Executable units of independent production, acquisition, and deployment that can be composed into a functioning system [Szyperski]

Introduction (5) Component software is a Composite system composed of software components

Introduction (6) Components could be formed by abstractions such as: procedures, classes, modules, or even entire app As long as They are in executable form Remain composable Procedure libraries are the oldest example of software components

Introduction (7) Software development can be divided in Custom-made Developed from scratch Standard software Everything is outsourced Standard software is bought and parameterised

Introduction (8) Custom-made Advantage Disadvantages Optimally adapted to the user’s needs Disadvantages Production from scratch is very expensive Takes a lot of time to develop Maintenance is difficult

Introduction (9) Standard software Advantages Financial risk is reduced Time-to-market risk is reduced The burden of maintenance, product evolution, and interoperability is left to the vendor

Introduction (10) Standard software Disadvantages May require a reorganisation of the business process It isn’t easy to adapt quickly to changing needs Competitive edge is difficult to achieve as competitors are using the same software standard

Introduction (11) Component software represents the middle path Cost efficiency Flexibility Competitive edge % bought % Custom-made 100

Introduction (12) Component software Puts an end to the massive upgrade cycles Migrating old databases Retraining staff Buying more powerful software Evolution replaces revolution

Introduction (13) In custom-made approach, growth can at most be linear Whereas the growth of component market can be exponential

Introduction (14) Example of components for a certain market segment Solaris is factored into a set of modules that can be combined according to needs Windows CE can be custom-assembled

Introduction (15) SW component has lasted to take off Initially considered to be analogous to hardware components The term software IC became fashionable The Lego block model was conceived for object technology But this did not happen

Introduction (16) SW component has lasted to take off Software is different from products in all other engineering disciplines It’s important to distinguish between software and its instances Confusion between objects and classes

Introduction (17) SW component has lasted to take off The plan of a building and the building itself can be modelled as objects Plans VS instances Plans can be parameterised, applied recursively, scaled, and instantiated any number of times None of this is possible with instances Comparing component software with other disciplines is dangerous

Introduction (18) The object-oriented paradigm has failed!!!

Introduction (19) Object technology does not include the notion of Independence Late composition A market for object classes has failed

Introduction (20) Component success stories Microsoft’s Visual Basic EJB COM Older success stories are modern operating systems

Introduction (21) Components are a higher-level of abstraction Components directly mean something to the deploying client The client gains some explicable, high-level feature Components directly mean something to the deploying client.- for example, when a plugin is installed to a web browser the user is aware of the added functionality

Introduction (22) Components can be implemented in any language programming paradigm Object technology is probably one of the best ways to realise components

4.3 What is a component?

Terms and concepts Overloading of the term “object” and “component” Module, class, runtime instance, etc The terms “component” and “object” often used interchangeably

Components Main characteristics Is a unit of independent deployment Is a unit of third-party composition Has no (externally) observable state

Components (2) Independent deployment Needs to be well separated from its environment A component will never be deployed partially The component can be deployed into standard build-time and run-time environments

Components (3) third-party composition Needs to encapsulate its environment Interacts with well-defined interfaces Specification of what it provides and requires

Components (4) Stateless Cannot be distinguished from copies of its own Makes little sense to have multiple copies Essential to avoid massive maintenance problems Cannot be distinguished from copies of its own.- possible exceptions are serial numbers Essential to avoid massive maintenance problems.- if components were allowed to have observable state, then no two installations of the same component would have the same properties

Components (5) Instance VS concept A database server together with the database is an instance This instance is not a component The static database server program is a component A database server together with the database is an instance.- as it might be seen as a module with observable state

Objects Main characteristics Is a unit of instantiation, it has a unique identity May have state and this can be externally observable Encapsulates its state and behaviour

Components and Objects A component is likely to act through objects However, no need to be implemented with objects Different implementation paradigms Procedural Functional Assembly language

Components and Objects (2) A component may contain multiple classes Interface inheritance essential technique for establishing correctness Debate about the usefulness of implementation inheritance Interface inheritance essential technique for establishing correctness.- as by refering to the same specification, two components establish a common basis.

Whitebox VS Blackbox Blackbox does not provide implementation details May still enforce encapsulation Whitebox implementation details are fully available Whitebox allows for manipulation of the implementation Glassboxes allows for inspection of the implementation

Software 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.” Context dependencies.- refers to the context composition and deployment. Includes: Component model that defines the rules of composition Component platform that defines the rules of deployment The required and provided interfaces

Software Component (2) Technical aspects Market related aspects Independence Contractual interfaces Composition Market related aspects Third parties composition

Component Weight Two options for component weight Build self-sufficient components Reduces context dependencies But also reduces reuse Minimal functionality components Increases context dependencies Increases reuse Maximising reuse minimises use As high context dependencies shortens potential use

Component Weight (2) Maximising reuse -> explosion of context dependencies Maximising reuse minimises use fatter < context dependencies Less fat > Context dependencies % reuse 100

Horizontal VS vertical markets A horizontal market cuts through all or many different market domains E.g. WWW standards A vertical market sector is specific to a particular domain E.g standards for medical radiology

Horizontal VS vertical markets Standardisation in horizontal markets Is difficult List of wish list is too big Standardisation in vertical markets Is also difficult Domain has to be wide enough for a viable market With a smaller number of players, the mechanisms of market economies work less well