Components

1. Components Alexey Golubev, 20.06.2004

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

3. What is a component ? 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

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

5. The father of components ? • 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 CBD has the same goal for the software that Eli Whitley wanted for muskets Eli Whitney (1765 - 1825) Alexey Golubev, 20.06.2004

6. Components and their promise (1) • expected advantages: • 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 • 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. Alexey Golubev, 20.06.2004

7. 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 productivitywill be realised. However, in the shortrun the • fruits of reuse will be smaller than the costof 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). Alexey Golubev, 20.06.2004

8. Requirements of component based development environments • Accepted rules of modular designshould 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 ofthe component. • Components should be defined and accessed within a globalnamespace of interfaces, • whichprovides a method to nameinterfaces 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. Alexey Golubev, 20.06.2004

9. 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. Alexey Golubev, 20.06.2004

10. Disadvantages and risks in using CBD • 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 fifthreuse. 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. • 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. • 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. Alexey Golubev, 20.06.2004

11. Component-Based System Development Lifecycle • Find components which may be used in the system. • Select the components which meet the requirements of 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 • requirement specification. • Compose and deploy the components using a framework for components. • Replace earlier with later versions of components. The development cycle compared with the waterfallmodel. Alexey Golubev, 20.06.2004

12. 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 Alexey Golubev, 20.06.2004

13. 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. Alexey Golubev, 20.06.2004

14. 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 Alexey Golubev, 20.06.2004