1. Components Alexey Golubev, 20.06.2004

2. What is a component? What is a component? The father of components? The father of components? Components and their promise Components and their promise Requirements of component based development environments Requirements of component based development environments Difference between a component and an object Difference between a component and an object Disadvantages and risks in using CBD Disadvantages and risks in using CBD Component-Based System Development Lifecycle Component-Based System Development Lifecycle UML and Component-Based Systems Modelling UML and Component-Based Systems Modelling Future of Component-Based Software Engineering Future of Component-Based Software Engineering Alexey Golubev, 20.06.2004 Contents:

3. Definitions: - - software components are (binary) units of independent production, acquisition, and deployment that interact to form a functioning system. - - a software component is a unit of composition with contractually specified interface and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parts. - - components are black boxes. Application developer that make use of components need not understand the implementation of those components. They are reusable code in its simplest form. Alexey Golubev, 20.06.2004 What is a component ?

4. Structure of a component: - Publoc parts are light - Privat parts are dark Alexey Golubev, 20.06.2004 What is a component ? provided required Reseources Classes and Private interfaces Self-Description Instantiation Public Interfaces

5. The father of components ? Alexey Golubev, 20.06.2004 1798 federal procurement for muskets component-based mass production higher output (10.000 in 28 months) Improved quality Lowered skill requirements Improved maintainability based on the concept of the interchangeable parts Eli Whitney (1765 - 1825) CBD has the same goal for the software that Eli Whitley wanted for muskets

6. Alexey Golubev, 20.06.2004 Components and their promise (1) expected advantages : flexibility flexibility Run-time components can work independently, and, if designed properly, are much less dependent on their environment (hardware, system software, other applications or components). Therefore, component-based systems are much more adaptable and extendable than systems traditionally designed and built. - hardware and system software. Component-based systems are less sensitive to changes in the foundation (for example: the operating system) than traditional systems. - functionality - functionality Component-based systems are at a functional level much more adaptable and extendable than traditional systems, because most of the new functionality can be reused some way or another or derived from already existing components. reuse Such components can be used everywhere. Functionality, be it technical or business oriented, has to be developed and implemented just once, instead of several times, as is now typically the case.

7. Alexey Golubev, 20.06.2004 Components and their promise (2) expected advantages : maintainability In a component-based system a piece of functionality ideally is implemented just once. It is self-evident this results in easier maintenance, which leads to lower cost, and a longer life for these systems. more rapid development/higher productivity of the developers In the long run, this higher productivity will be realised. However, in the short run the fruits of reuse will be smaller than the cost of the introduction of a new way of system development. distribution CBD makes it possible to design systems for distribution (on a LAN, or the Internet, or whatever).

8. Alexey Golubev, 20.06.2004 Requirements of component based development environments Accepted rules of modular design should be supported explicitly. The environment should support a separation between the private and public parts of a component. The environment should support and exploit component selfdescription, meta-information that is stored directly inside of the component. Components should be defined and accessed within a global namespace of interfaces, which provides a method to name interfaces in a globally (worldwide) unique way. The environment should support two methods of configuration: connection and adaptation. A CBDE should support multiple views. The maintenance problems associated with component technology should be addressed by the environment through reuse by reference, which is supported via access to remote, searchable component repositories.

9. Alexey Golubev, 20.06.2004 Difference between a component and an object Difference between a component and an object a component is meant to be a runtime entity, whereas an object is an instance of a class. objects are usually not thread-secure, because the designer knows (or thinks he knows) how the objects are going to be used. So in a component,interface design is more important than it usually is in object-oriented design, and encapsulation of the state is enforced. Objects exist at runtime, but classes are really design entities. Components are deployed independently, and it is impossible to predict how the component is going to be used.

10. Alexey Golubev, 20.06.2004 Disadvantages and risks in using CBD Time and effort required for development of components. Time and effort required for development of components. Efficient reuse of real-time components, made by engineers at Siemens that, as a rule of thumb, the overhead cost of developing a reusable component, including design plus documentation, is recovered after the fifth reuse. Similar experience at ABB shows that reusable components are exposed to changes more often than non-reusable parts of software at the beginning of their lives, until they reach a stable state. Unclear and ambiguous requirements. Reusable components are, by definition, to be used in different applications, some of which may yet be unknown and the requirements of which cannot be predicted. Conflict between usability and reusability. Conflict between usability and reusability. To be widely reusable, a component must be sufficiently general, scalable and adaptable and therefore more complex (and thus more complicated to use). Component maintenance costs. Component maintenance costs. While application maintenance costs can decrease, component maintenance costs can be very high since the component must respond to the different requirements of different applications running in different environments, with different reliability requirements and perhaps requiring a different level of maintenance support.

11. Alexey Golubev, 20.06.2004 Component-Based System Development Lifecycle Find components which may be used in the system. Find components which may be used in the system. Select the components which meet the requirements of the system. Select the components which meet the requirements of the system. Alternatively, create a proprietary component to be used in the system. Alternatively, create a proprietary component to be used in the system. Adapt the selected components so that they suit the existing component model or Adapt the selected components so that they suit the existing component model or requirement specification requirement specification. Compose and deploy the components using a framework for components. Compose and deploy the components using a framework for components. Replace earlier with later versions of components. Replace earlier with later versions of components. The development cycle compared with the waterfall model.

12. Alexey Golubev, 20.06.2004 UML and Component-Based Systems Modelling UML can be used for both component and system modeling. Component-driven design concentrates on interface definitions and collaboration between the components through the interfaces. The design process continues with the modeling of the system with physical components, which do not necessarily match the logical structure.. One logical component, identified in the first phase of design, may consist of several physical components. Finally, there is a deployment aspect, the components being executed on different computers in a distributed application. In a non-component-base approach the first, the design phase is important, while mapping between the conceptual and implementation level is a direct mapping, and the deployment phase is the same for the whole application. In principle, UML can be utilized to provide support for designing component-based systems covering all these aspects. Interfaces are presented as multiple subsystems (also multiple interfaces may be realized by a subsystem), which indicate the possibility of changing the implementation without replacing the interface. An interface can be presented in two ways, the second alternative being the more common presentation. Uml Component - Interface representation

13. Alexey Golubev, 20.06.2004 Future of Component-Based Software Engineering It is obvious that CBD and CBSE are in the very first phase of their lives. CBD is recognized as a new, powerful approach that will, if not revolutionize, at least significantly change the development of software and software use in general. We can expect that components and component-based services will be widely used by non- programmers for building their applications. Tools for building such applications by component assembly will be developed. Automatic component update over the Internet, already present today in many applications, will be a standard means of application improvement.

14. Alexey Golubev, 20.06.2004 Sources: “ “Component Based Development “ -- M. Huizing “WREN— An Environment for Component-Based Development” -- Chris Lüer, David S. Rosenblum “Component-based Software Engineering – New Challenges in Software Development” -- Ivica Crnkovic