The Different Aspects of Component Based Software Engineering 1
Ivica Crnkovic1, Magnus Larsson2, Frank Lüders2 Mälardalen University, Department of Computer Engineering, 721 23 Västerås, Sweden,
[email protected] 2 ABB Automation Products AB, LAB, 721 59 Västerås, Sweden, {Magnus.Larsson | Frank.Luders}@mdh.se
Abstract: More and more systems are developed from components instead of from scratch. Reusing components has many advantages: The development time dramatically decreases, the usability of the products increases, the production costs usually decrease, and so on. However, there is a big difference between a “classic” and component-based development, and there are many pitfalls which may lead to an unsuccessful result. A lot of difficult issues and aspects of Component Based Software Engineering (CBSE) have to be investigated to develop good component-based products. Still there is no established development process which will guarantee a proper treatment of components. This paper elaborates on some of those different aspects of CBSE and gives advise to developers working with component technologies. In particular the component identification problem is discussed, relation between the object-oriented and the component development, and the different phases in the component-based development process. Certain proposals for improvements of the process are given.
I. INTRODUCTION In recent years, we recognize a new paradigm in the development process: From a complete in-house development, to the development process which has focused on the use of standard and de-facto standard components. The final products are not closed monolith systems, but are instead component-based products that can be integrated with other products available on the market. The popularity of component-based development (CBD) has grown to a large extent with appearance of several component models, such as COM/DCOM [1], JavaBeans [2] and CORBA [3]. In recent years a lot of research related to the component-based development has been done [4], but still there are many open and unresolved problems in this area. Reusing components improves the efficiency in development and flexibility of delivered products, but at the same time increases the risk of loosing consistency of the product configuration. Component-based Software Engineering (CBSE) is a new growing discipline which aim is to bring a better understanding the nature of components, to improve the component-based development process and even to describe non-technical aspects of the development process, such as marketing and juridical question. This paper outlines some of the different aspects of CBSE. Chapter II discuses different definitions and a nature of components. Object-oriented design is tightly coupled with component-based development, and relations between objects, frameworks and components are discussed in chapter III. The CBD process life cycle is described in chapter IV and compared with the traditional waterfall process. Some of these faces are discussed in
more details in chapters V and VI where certain problems are outlined and solutions to these problems proposed. II. COMPONENTS “Components are for composition. Nomen est omen”[5]. This is a quote that most people agree upon when discussing about what components are. But to come up with a precise and well-understood definition of a component, which everybody agrees upon, is not an easy task. Wallnau [4] collects different definitions and compile them down to four definitions that are representative of those that are emerging in the software industry and that contain different concepts of components: 1) A component as a replaceable part of a system that fulfills a clear function; 2) A run-time component; 3) A component as a unit of composition with contractually specified interfaces; 4) A business component as a software implementation of an "autonomous" business concept. The question of component definition is essential since until there is no standardized definitions of components, and until there is no a common agreement what a component is, it is difficult to have a systematic and a consistent approach in researching and analyzing the problem. As, from a lexical point of view, a component is a part of a composition, completely different entities can be defined as components, such as: 1) Operating system - it is a part of the entire system. 2) Database - it is a component used by different applications. 3) Unix commands connected via pipes. 4) A library as a set of functions linked in the programs. 5) A shared library dynamically linked with programs. 6) A class, or an object as a reusable unit. 7) An aggregate of classes or objects putting together in a framework. 8) Packages providing functions with a specified interface (such as COM or JavaBeans component). In this paper we treat components as "a unit of composition with contractually specified interfaces and explicit dependencies only, which can be deployed independently" [5], which mostly corresponds to the last four examples. III. COMPONENTS AS OBJECTS AND FRAMEWORKS Typically, the development of component-based systems starts with a collection of existing components. The components are integrated into the system with some
proprietary code that glues the components together. This “code” is also known as “gluecode”[6]. Object-orientation (OT) had the same approach; objects are reusable entities that could be connected together into programs. However, OT is not sufficient for CBSE. OT does not express the “uses” relationship, which is needed for CBSE. OT express “has a” and “is a” relationships. Components express what context they will work within via a declaration of what system resources are required for the component to work properly. OT does not typically support this type of concept. A component does not have to be an object, it can be a function or an executable program that is not treated as an object. However, even if objects (or at design time, classes) cannot be treated as component, they are reusable entities and OT technology can successfully be used for development of components. Object-oriented Design (OOD) frameworks are increasingly recognized as better components in software development than objects (see e.g.[13]). Frameworks are software entities containing objects connected by a mutual relations and in a defined context. A Framework defines a functionality that is on a higher abstraction level. The reason why Frameworks are seen as better components than objects for is that objects tend to have more than one role in more than one context, and OOD frameworks can capture this, whereas existing OOD methods (e.g. Fusion [9]) cannot. The latter use classes or objects as the basic unit of design or reuse, and are based on the traditional view of an object, as shown in Fig. 1 which regards an object as a closed entity with one fixed role. Encapsulated internal structure
Visible functions
Fig. 1. Objects with one fixed role.
On the other hand, frameworks collect objects that play different roles in different Frameworks. In Catalysis [14], for instance, this is depicted in Fig. 2. Frame 1
Frame 1 + 2
Now consider another view of a person, e.g., a person plays the role of a consumer, as shown in the Person-AsConsumer framework in Fig. 3. In this role a person also has the attribute pocket, but he has the action buy (instead of the actions receive_pay and work). We may compose the frameworks for Person-As-Employee and Person-AsConsumer, to obtain a person with both roles together. A person now has all the actions of both roles, namely receive_pay, work and buy, and the attribute pocket in both roles. The composition is illustrated by Fig. 4 PersonAsEmployeeConsumer
Company
IUnknown
IUnknown
The following example illustrates the framework concept. Consider the framework for employees as depicted in Fig. 3, in which a person plays the role of an employee of a company. A person as an employee has an attribute pocket representing the amount of money he possesses, and two actions receive_pay and work PersonAsConsumer
pocket: Money
Person
IConsumer
IPerson Consumer
Fig. 2. Objects with multiple roles in different frameworks
Person
Shop
The basic characteristics of Frameworks are possibility to build Frameworks from partial objects, where object plays specific roles. Frameworks can also include Frameworks. This concept makes it easier to build larger components with more precise and understandable functions. This theoretical model can be used during the design phase. To implements components as Frameworks we can use component models, such as COM. The following example shows how "partial" objects can be collected in a Framework. COM suits multiple roles because it can use multiple interfaces for each role. We will use the aggregation mechanism in COM to compose frameworks. First, we implement the Person object, which corresponds to the encapsulated internal structure in Fig. 5. The Person object is constructed so it supports aggregation of role objects and it has one IPerson interface.
role B
role A +B
worksfor Person pocket: Money Company receive_pay( amt: Money) work(…)
pocket: Money
Fig. 4. PersonAsEmployeeConsumer framework.
IPerson
PersonAsEmployee
buysfrom
receive_pay(amt: Money) work(…) buy(price: Money)
Frame 2
role A
worksfor Person
buysfrom Shop
buy( price: Money)
Fig. 3. PersonAsEmployee and PersonAsConsumer framework.
Fig. 5. The Consumer and Employee roles are aggregated into the Person object.
Second, the consumer and employee roles are implemented so they support being aggregated into a person object. The consumer object needs also a reference to the person object to be able to work on the pocket variable. The Person reference is set up when the consumer is aggregated into the person object. In a similar way the Employee role is implemented. Using aggregation mechanism in COM we can reuse the different components that we have created. Fig. 6 shows how Person aggregates the two already defined COM objects, Consumer and Employee, which play different roles of the same person. Frameworks are created at run-time by adding roles to an object. The Person aggregate can now be treated as single component. Interfaces of every aggregated object become the common interface.
IUnknown IPerson
IUnknown
Person
IPerson Consumer IConsumer IUnknown IEmployee
Employee IPerson
Fig. 6. Aggregation of Consumer and Employee into Person.
The COM implementation of the framework concept has some limitations. The COM model defines frameworks as aggregates of the completed objects created at run-time, while a general framework model allows us to use incomplete objects (at run-time) or classes (at build-time). More details and problems related to managing Frameworks you can find in [7]. IV. THE DEVELOPMENT PROCESS Development with components differs from traditional development. There is a new development process for CBSE and it differs from the traditional waterfall model. Fig. 7 shows a comparison between the two different development processes. Gathering requirements and design in the waterfall process corresponds to finding and selecting components. Implementation, test and release correspond to create, adapt, deploy and replace. Requirements
Find Create
Design
Select
Implementation
Adapt
Test
Deploy
Maintenance
Replace
Waterfall model
CBD model
Fig. 7. A comparison of the waterfall (left) and the componentbased (right) development process
The different steps in the development process are: 1) Finding components that may be used in the product. Here all possible components are listed for further investigation. 2) Selecting the components that fit the requirements of the product. 3) Alternatively, creating a proprietary component that will be used in the product. 4) Adapting the selected components so that they suit the existing component model or requirement specification. Some component needs more wrapping than others.
5) Composing or deploy the product. This is done with a framework or infrastructure for components. 6) Replacing old versions of the product with new ones. This is also called maintaining the product. There might be bugs that have been fixed or new functionality added in a new component version. These steps have different technologies to support the developers. However, using the proper technology is not sufficient for a successful component-based development. Other factors, such as organizational issues, quality assurance, marketing factors, etc. play a crucial role for a successful result. Some of these issues are elaborated in more details in the following chapters. V. FINDING AND SELECTING COMPONENTS To find components there are tools like Agora[11] and JCentral[2] while Cool: Spex[10] from Sterling software can help with the selection process. There is also COMCAD[12] that supports the deployment for COM components. These tools help to find the appropriate components from component databases or over the Internet. However, to find a component that hopefully fulfills the requirements from the functional point of view is not enough (see e.g. [6]). Components are typically “black boxes” with their source code not available. The documentation usually includes only a brief description of its functionality, and there are many hidden characteristics which the developers are not aware of. The quality of a component is usually difficult to estimate. As a component is typically developed in a system environment which is different from the environment of the final system where the component is integrated, and it is difficult to predict the component behavior in the new system. For example, a component may function correctly alone, but in combination with other components it can fail because of different reasons: Resource problem, incompatibility of data formats, timing problems, etc. In order to minimize the uncertainties, a standardized development process for both developing components and using components must be established. As a result of studying different aspects of CBSE, we can provide a list of advises for this area. The list divided into two parts, one for the component developer and one for the application developer (the user of components). A. Advises For the Component Developer When developing components, we recommend to think of the following advises: - Always document all the features of the component. Do not restrict the documentation to functionality, document all other properties as well. E.g. Performance, resource consumption, limitations, robustness, etc. - Provide test-suites with the component so that the customer can test your component in their environment. It is extremely important to test an imported component in the environment it will operate. - Provide source code if possible, it might help the application developer to understand the semantics of your component.
- Make the components so they easily adopt and integrate into existing component frameworks. - Components need to be carefully generalized to enable reuse in a variety of contexts. However, solving a general problem rather than a specific one takes more work. B. Advises For the Component Integrator Before acting and taking decisions on how to build applications from components, we recommend that the following questions and thoughts be considered: - The time your product is off the market can be greater than the time saved getting your product to market if your component supplier drops the product. Can you accept this risk? - The functionality provided by the component may not remain precisely what you need over time, forcing you to create wrappers that get around this. Things are getting even worse if you are not getting support from the vendor. Similarly, the functionality of the component may be more than you actually need, requiring you to write restrictive wrappers for functionality that you do not want to be used. Use of unintended functionality may cause problems. - If you succeed to get the source code from the component vendor, can you really maintain it if something goes wrong? - A malfunction in the component may cause an error in your product. You have to provide the fix of the problem even though the error is in the third-party component. - If you ask the component vendor to customize the component for you, are you aware that you now are strongly dependent on the vendor? The vendor can charge you anything they please. In order to minimize the risk of selection of a wrong component, and to secure the component maintenance and improvements, relations with the component suppliers must be established, as well as procedures which will ensure the component correctness: - Make a thorough evaluation of the component suppliers. Are they suitable as a supplier? Do they have good quality products and support? Check their economy so they don’t easily bankrupt. - Put a lot of effort into the legal agreement with the supplier. This may save you if the supplier goes out of business or if they refuse to support you. - Create good and long term relations with the supplier for better cooperation. - Limit the number of partners and suppliers. To many will increase the costs and the dependencies. - Buy “big” components where the profit is greatest. The management of to many small components can consume the profit. - Have key persons that are assigned to supervise the component market. They shall keep track of new components and trends. - Try to get access to the source code. - Test properly the components in your environment.
VI. CONCLUSION This paper addresses some topics in Component-based Software Engineering which are still open and not completely explained. As a relative new discipline, CBSE uses both theoretical and practical approach to explain and improve the development process. In this paper we have discussed at Frameworks as a possible way to encapsulate the components. Further, a development process has been discussed, and some problems, related to insufficient information about the component properties, are stressed. Certain advises how to minimize the risks of using components not properly understood, were given. REFERENCES [1] Don Box, Essential COM, Addison-Wesley, ISBN 0201-63446-5 [2] JCentral, IBM, http://www.ibm.com/java/jcentral/basicsearch.html.
[3] CORBA, http://www.corba.org [4] Alan W. Brown, Kurt C. Wallnau: “An Examination of the Current State of CBSE”: ICSE Workshop on CBSE, 1998 http://www.sei.cmu.edu/cbs/icse98/summary.html [5] Szyperski C., “Component Software – Beyond Object-Oriented Programming”, Addison-Wesley, ISBN 0-201-17888-5, 1997 [6] Korel B., “Black-Box Understanding of COTS Components”, Proceedings from the 7th international workshop on program comprehension, ISSN: 10928138, 1999 [7] Crnkovic I., Larsson M., Lau K., Component Configuration Management for Frameworks, AsiaPacific Software Engineering Conference, Workshop on Components, 1999 [8] Cherinka R., Overstreet C.M., Ricci J., “Maintaining a COTS integrated solution, ISBN 0-8186-8779-7, IEEE 1998 [9] D. Coleman, P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes: Object-Oriented Development: The Fusion Method, Prentice-Hall, 1994 [10] Cool:Spex, Sterling, http://www.cool.sterling.com/products/Spex/ [11] Seacord R.C., Hissam S.A., Wallnau K.C., “AGORA: a search engine for software components”, IEEE Internet Computing Vol 2, Issue: 6, ISSN: 10897801, 1998 [12] Peltz C., “A Hierarchical Technique for Composing COM based Components”, Microsoft, Position paper from the 2nd international workshop on CBSE” [13] R. Mauth: A better foundation: development frameworks let you build an application with reusable objects. BYTE 21(9):40IS 10-13, September 1996. [14] D.F. D'Souza and A.C. Wills: Objects, Components, and Frameworks with UML: The Catalysis Approach, Addison-Wesley, 1998
