Introduction to Component Software: Exploring Reusability and Composition

1. Module 4. Component Software4.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 • 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 0 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

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

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

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

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

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

37. Software Component (2) • Technical 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 0 % 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