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

2. Component Software

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

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

5. 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

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

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

8. 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

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

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

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

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

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

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

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

16. 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

17. 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

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

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

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

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

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

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

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

25. 4.3 What is a component?

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

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

28. 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

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

30. 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

31. 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

32. 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

33. 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

34. 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.

35. 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

36. 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

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

38. 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

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

40. 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

41. 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