Software Components
Home | Components Links | Component-based Software Development (CBSD) | Desktop Computing |
The days of large, monolithic software systems are fast moving into oblivion. The pace of software development becomes aggressive with development cycles reduced drastically. The current trend favors a short-term development process where large and complex applications are being built using a series of smaller parts, referred to as components. Component technology is the next step in the evolution of software design and development. It is strongly associated with Object technology, though this association is not necessarily an accurate one. Here is an explanation of what is all about components and their usefulness. The area of component technology has spawned a slew of new buzz-words, some of them are confusing. Future systems shall be developed by assembling co-operative software units. These units need not necessarily originate from the same vendor, but will conform to a standard interface for units offering their respective functionality. Assembly of such units will be aided by use of tools which will extract self descriptive information from these units. Delivery of such an assembled system will involve the deployment of these units configured appropriately. These units may be delivered on any platform. Such software units are known as components. Components are typically business objects that have predefined and reusable behaviors. Implementation detail is hidden in the interfaces, which isolate and encapsulate a set of functionality. Interfaces are the means by which components connect. An interface is a set of named operations that can be invoked by clients. More importantly, well-defined interfaces define the component's entry points, and a component's accessibility is done only via its interface. In a component-based approach, providers and clients communicate via the specification of the interface, which becomes the mediating middle that lets the two parties collaborate and work together. In summarizing, we have the following:
It is worth considering the relationship existing between components and objects. A component approach to software development builds upon fundamental constructs of object-oriented paradigms. Although the terms "component" and "object" are often used interchangeably, a component is not an object. An object is an instance of a class that gets created at runtime. A component can be a class, but is usually a collection of classes and interfaces. At runtime, a component becomes alive when its classes get instantiated. Therefore, at runtime, a component becomes a web of objects. Their usage seems synonymous. While objects are well-suited for component construction, a non-OO approach to component construction is perfectly valid. The following explains how objects differ from components.
There are a whole lot of exciting and robust components in the existing systems. Extraction of them and reusing for the purpose of building software applications is one interesting task. The other one is to build components from the scratch using component-based programming languages. Component-oriented programming addresses the aspects of programming components. Component construction itself can be performed using arbitrary programming languages, as long as the language supports the particular component standard's interface conventions. Many programming languages such as COBOL, C, C++, Pascal, Smalltalk lack support for encapsulation, polymorphism, type safety or a combination of these. So nowadays Java is becoming the most favored programming language for building software components. In the absence of existing legacy code, a component must be built from scratch. In this case, it makes sense to implement a component using an OO approach. However, it is often the case that legacy code providing similar functionality will be available somewhere. The aim of components is to deliver better applications to the market in a shorter time. This is easily achieved through leveraging existing components. Thus the philosophy of component assembly is re-use. The philosophy for component construction remains the same. When assembling a component based system, it is assumed that the selected components are fit for the purpose. That is, the components have been rigorously tested and their performance metrics well understood. Reuse is encouraged through faith in the components. When constructing components, existing code will be often be reused. We below give a brief explanation for some of the approaches in this regard. Object wrapping: In a system which is object-based, all entities within the system must behave as objects. Thus, when non-OO code is being reused, it can not be used directly- it must be wrapped. A class is created which delegate functionality to the non-OO code. The objects created from this class will behave as object oriented proxies for the legacy code. Refactoring: System development is an incremental process. The more a system is used, the more it must evolve to meet new requirements. It is often the case that code which was cut in the original release, while functionally sound, may prove to be inflexible for current requirements. Refactoring is changing code's internal structure to make it easier to understand and use while leaving its functionality unchanged. Refactoring can breath new life into powerful but inflexible systems. Mining: It is performed by analyzing elements of the existing system. These elements are only considered within the scope of the existing (legacy) system. This provides the miner with a comprehensive picture of the system. While designing/implementing a new system, the mistakes of the previous system can be avoided, as they were identified in the mining process. In addition, useful elements of the legacy system will have been identified and these can be reused. Mining is a powerful concept and may be applied at the code level as well. Code identified in the mining process as suitable for reuse will typically undergo wrapping and possibly refactoring.
Caveat: With a vast collection of systems already
tied and tested, it would seem tempting to go for a reuse approach outright. However,it
is worth distinguishing between Legacy Assets and Legacy Liabilities. Most systems
will be littered with both, with dependencies between the two. It is the skill
of the system miner to distinguish between the assets and the liabilities and
to identify the assets with little or no liability dependencies. The benefits of software components are manifold:
|