Trend towards ‘open systems’

1. Component-OrientedSoftware Technology- Oscar Nierstrasz and Laurent DamiPresented by – Harshal Savalia Akeel Udar

2. Trend towards ‘open systems’ ‘A system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered application software to be ported across a wide range of systems with minimal changes, to interoperate with other applications on local and remote systems, and to interact with users in a style that facilitates user portability.’ - IEEE POSIX 1003.0 Committee

3. Open Systems We can see, then, that open systems must be‘open’ in at least three important ways : • 1.Topology Open applications run on configurable networks. • 2.Platform The hardware and software platforms are heterogeneous. • 3.Evolution Requirements are unstable and constantly change.

4. Object oriented software development partially satisfies these needs Evolution? Open Systems

5. Introducing Components • By viewing open applications as compositions of reusable and configurable components, we expect to be able to cope with evolving requirements by unplugging and reconfiguring only the affected parts

6. What are Components? • Component-based development represents the 'industrialization' of software development. When any manufacturing process evolves to the point where it can be based on pre-built components and subassemblies, product quality, quantity, and speed of delivery soar. This principle applies equally to software systems development, allowing unprecedented quality, speed of development, and highly effective change management.

7. What are Components? - “static abstraction with plugs” • A software component is a long-lived entity that can be stored in a software base, independently of the applications in which it has been used. • A component puts a more or less opaque boundary around the software it encapsulates. • There are well-defined ways to interact and communicate with the component (parameters, ports, messages, etc.).

8. Seen from the outside, a component may appear as in figure 1.2, a single entity, which may be moved around and copied, and in particular may be instantiated in a particular context, where the plugs (the small black rectangles) will be bound to values or to other components.

9. Where do components come from? • Components only emerge through an iterative and evolutionary software lifecycle. • Components are only useful as components if they can be easily used in many contexts. • We must incorporate the activity of “component engineering” into the software lifecycle. • Basically, both software methods and development technology need to undergo some significant changes in order to take advantage of component-oriented development.

10. Objects vs. Components • Issues - • Present-day object-oriented languages emphasize programming over composition • A programming language for open systems development should also support strong typing and concurrency • Components need to be recognized as entities in their own right, independently of objects

11. Technical Support for Components • Structure of components What is the structure of a software component? • Components typically are static entities; moreover, they always consist of some kind of abstraction • A component is a self contained entity, with some kind of boundary around it, which can later be composed with other entities

12. Composition decisions At what stage do composition decisions occur? Necessity for open systems to be able to dynamically link new agents into a running systems Static compilation is not as efficient as compilation at run-time E.g. Perl The author does not clearly specify the actual composition process

13. Verification of composition How do we formally model components and composition, and how can we verify that fragments are correctly composed? • Additional constraints in the interfaces of components • Improve expressiveness of type systems • Put the contract outside the components • (useful for inter-language composition)

14. Features in a language supporting component oriented development • Active objects • Components • Composition • Types • Subtypes

15. Benefits and Risks of following a component oriented approach • Benefits • makes it easier • (i) to fill (at least partially) the needs of many different applications, and • (ii) to adapt a given application to changing needs. • Risks • Developers invest time and effort • Developing new frameworks is a costly and long-term activity • No support from management if excess overhead • Frameworks tend to stabilize only over several complete re-designs

16. Summary • The notion of a software component is not explicitly and generally supported by object-oriented languages • A component, as opposed to an object, is a static software abstraction • An object is a run-time entity • In a component-oriented approach, the activity of component engineering must be explicitly incorporated into the lifecycle, and supported by the software process, the methods and the tools • Component engineering is the activity of distilling and packaging domain expertise in such a way as to make component-oriented application development possible

17. Conclusion • This paper introduces the concept of component oriented technology. • Clearly illustrates the difference between objects and components • However, • It does not get into the details of actual implementation • The paper is very abstract about some important details