By Ivica Crnkovic, Brahim Hnich, Torsten Jonsson, and Zeynep Kiziltan

Specification, Implementation, and Deployment of COMPONENTS
Clarifying common terminology and exploring component-based relationships. omponent-based software engineering is a new, promising, and rapidly growing discipline in academia and industry. The basic concepts in CBSE originate from different areas of software engineering and computer science, such as OO programming, reuse, software architecture, modeling languages, and formal specifications. Industry and the open market have had a significant impact on the development of component technology—CBSE synthesizes knowledge and experience from these areas. A consequence of this situation is that CBSE uses concepts that are still not fully formalized, terms that are not clearly distinguished, with relations among them that are not well explained. For example, the terms “component” and “interface” are still widely discussed, and still not yet formally specified. Here, we clarify the commonly used terms within the area of CBSE and discuss relations between them.
The main concerns of CBSE related to components are a component specification, its implementation, and its deployment. A component is specified by functions by which it communicates with its environment, and by other attributes, called “extrafunctional attributes,” which are not expressed by functions but define the total behavior of the component. A widely used method for specifying the syntactic aspects of functional properties is the definition of interfaces. The semantic aspects of functional properties related to context-dependencies (specification of the deployment and runtime environments) and interaction can be expressed using contracts. Interfaces and contracts, however, are not so well equipped to express extrafunctional properties. Manners and the analytical model are two examples of techniques that address the specification of extrafunctional properties. Component implementation and deployment are closely related to patterns and frameworks. A component is a unit of composition, and it must be specified in such a way that it is possible to compose it with other components and integrate it into systems in a predictable way. Szyperski [11] defines a component as a unit of composition that can be deployed independently and is subject to composition by a third party. For a component to be deployed independently, a clear distinction from its environment and other components is required. A component communicates with its environment through interfaces. Hence, a component must have clearly specified interfaces, while the implementation must be encapsulated in the component, and is not directly reachable from the environment. This is what makes a component a unit of third-party composition. The most important feature of a component is the separation of its interfaces from its implementation. This separation is different from those we find in OO programming languages, where class definitions are sepaCOMMUNICATIONS OF THE ACM October 2002/Vol. 45, No. 10

35

rated from class implementations. such as functional programming or an assembly lanComponent integration and deployment should guage approach. In particular, patterns and framebe independent of the component development life works are two commonly used methods that cycle, and there should be no need to recompile or re- contribute to the realization and deployment of comlink the application when updating with a new com- ponents. We can conclude that the OO approach and ponent. Another important characteristic of a CBSE have many similarities, but there is a clear discomponent is its visibility exclusively through its tinction between the two. CBSE is more focused on interfaces. An important implication of this is a need interface, reuse of black-box-type components, runfor a complete specification of a component includ- time behavior, and less on programming and proing its functional properties, extrafunctional proper- gramming languages, which is characteristic for OO. ties [2] (quality attributes such as accuracy, CBSE and OO are, however, not conflicting: on the availability, latency, security, performance, resources contrary, OO analysis, design, and development conrequired), use cases, tests, and so forth. This calls for stitute a set of technology and methods naturally used different types of interfaces. Unfortunately, the in CBSE. current component-based Specifying technologies successfully Constraint Component * * Interface Functional manage only the specifica1 * * Properties tion of functional proper* * in-interfaces * A component is specified ties, though functional * in terms of its functional specifications are limited State Interface * out-interfaces 1 and extrafunctional propto syntactic lists of opera- 2 * 1 1 1 erties. While the use of tions and attributes. Curinterfaces captures the synrent technologies fall short * tax of the functional propof addressing the semanInvariant * * * erties, contracts play an tics of functional properimportant role in underties. Further, there is no PreCondition Operation PostCondition * * * 1 1 standing the semantics of satisfactory support for * * * 1 the functional properties specification of extrafunc* * * of a component. Contional properties. versely, manners and the Many CBSE concepts InParameter Parameter OutParameter analytical model generalize originate from reusability * the concept of interface to and OO approaches. A express extrafunctional reusability approach in CBSE manifests on different levels. First, a component Figure 1. UML metamodel for properties of a component. Interfaces. An interface can be composed at runtime without any need for semantic specification of of a component can be compilation. Second, a component detaches its inter- software components. face from its implementation, and conceals its imple- defined as a specification of its access point [11]. The mentation details, permitting a composition without a clients access the services provided by the component need to know its implementation details. Moreover, a using these points. It is important to note that an component interoperates with other components or interface offers no implementation of any of its operframeworks in a predefined architecture. Furthermore, ations. Instead, it only names a collection of operaa component interface is required to be standardized, tions, and provides only the descriptions and the protocols of these operations. This separation makes so that components can be widely reused. The terms object and component are often it possible to: replace the implementation part withthought to be synonymous or very similar. In an OO out changing the interface, and in this way improve approach, a component can be seen as a collection of the system performance without rebuilding the sysobjects, in which the objects cooperate with each tem; and, add new interfaces (and implementations) other and are tightly intertwined. The boundary without changing the existing implementation, and between a component and other components is spec- in this way improve the component adaptability. Interfaces defined in standard component techified, and the interaction of the component (and thus its objects) across the boundary is implemented nologies (for example, Interface Definition Language through the component interface, while the inner 1 For the details Comgranularity of a component is hidden.1 However, a ponent pattern,of implementingaenterprise components through the Enterpriseobjects which includes composite set of medium-and finer-grained component can be realized by using other approaches of which it is comprised, see the article by Levi and Arsanjani in this section.
36
October 2002/Vol. 45, No. 10 COMMUNICATIONS OF THE ACM

Many different concepts, definitions, and specifications lie behind attempts to successfully manage component-based development. in CORBA or COM) can only express functional properties, and this only partially, focusing on the syntax part. In general, functional properties include a signature part in which the operations provided by a component are described, and a behavior part, in which the behavior of the component is specified. In this type of notation, we can distinguish export/import interfaces to/from environments that may include other components. An exported interface describes the services provided by a component to the environment, while an imported interface specifies the services required by a component from the environment. Contracts. The interface semantics can be achieved through contracts. A contract lists the global constraints that the component will maintain (the invariant). For each operation within the component, a contract also lists the constraints that must be met by the client (the pre-condition), and that the component promises to establish in return (the post-condition). The pre-condition, the invariant, and the post-condition constitute the specification of a component’s behavior. Figure 1 illustrates a UML metamodel for semantic specification of a component [4]. In this metamodel, a component is determined by its interface (which provides or requires services) and by constraints. Each interface consists of a set of operations. In addition, a set of pre-conditions and post-conditions is associated with each operation. Pre- and postconditions often depend on the state maintained by the component. Finally, a set of invariants is associated with an interface. Beyond the specification of the behavior of a single component, contracts can also be used to specify interactions among groups of components [7]. However, they are then employed in a slightly different manner. A contract specifies the interactions among components in terms of: • the set of participating components; • the role of each component through its contractual obligations, such as type obligations, which require the component to support certain variables and an interface, and causal obligations, which require the component to perform an ordered sequence of actions, including sending messages to the other components; • the invariant to be maintained by the components; and • the specification of the methods that instantiate the contract. Specifying Extrafunctional Properties. Extrafunctional properties determine the overall behavior of a component, but cannot be expressed through standard interfaces. Examples of extrafunctional properties are time properties (latency, worst-case execution time), reliability, robustness, and availability. Some research efforts have addressed the specification of extrafunctional properties by generalizing the term interface (and accordingly the component specification). Arsanjani et al. [1] define manners, the governing behavior of a reuse element such as classes, subsystems, and components within a given context. Thus, when a component receives a message or has registered interest in an event, the component’s manners ensures that the component responds within the semantics appropriate for its current context by checking its state, constraining the rules or flow that apply within the given context and activating extrafunctional aspects (that have often been represented as metadata). Manners cover a wide spectrum, ranging from business analysis expression of business rules assigned to a reuse element to a grammar-oriented object design specification based on a domain-specific language for a business. Manners of components provide the services for self-description, dynamic configuration, and dynamic collaboration. A component can be queried for its manners within a given processing context. A similar approach to generalizing the interface specification is the Analytical Model [6] that comprises standard component technologies with the constructive (functional) interface, and Analysis Technology that specifies the analytic interface. The analytic interface specifies extrafunctional properties of components, and provides techniques for deriving, thus predicting extrafunctional properties of the component assemblies.

Implementation and Deployment of Components Patterns and frameworks play a central role toward the implementation and deployment of components. We describe these two concepts here.
COMMUNICATIONS OF THE ACM October 2002/Vol. 45, No. 10

37

Patterns. A pattern defines a recurring solution to a recurring problem. Gamma et al. [5] further refined this definition by specifying the characteristics of a pattern and its objectives. Patterns capture not only abstract principles or strategies, but also non-obvious solutions in an indirect manner. Patterns can be classified in three major categories depending on the level of abstraction on which they are used when documenting a software solution or design. At the highest level of abstraction architectural patterns deal with the global properties and architecture of a system Component-type composed of large-scale compoSpecific Interface nents. Architectural patterns capture the overall structure and Component Deployment organization of a software system, and encode high-level tactics, which describe the set of participating subsystems, specify their roles, and express the relationships between them. At a lower level of abstraction, design patterns refine the structure and the behavior of the subsystems and the components of a software system, and the relationships that exist between them. They encode microarchitectures of subsystems and components for a general design problem within a particular context, which describe the structure and behavior of the subsystems and components, and the communication between them. At the lowest level of abstraction, idioms are lowlevel patterns, which are dependent on the chosen paradigm and the programming language used. Patterns have been applied to the design of many OO systems, and are considered as reusable microarchitectures that contribute to an overall system architecture. However, the knowledge encoded in the design patterns is an unstructured knowledge that may contain many ambiguities because of the informal description of the solutions. Frameworks. In CBSE, software is built by putting pieces together. It is therefore very important that there exist a context in which such pieces can be used. This is the task of frameworks. Frameworks are often discussed from different points of view and at different levels of detail. In some cases frameworks are seen as a reusable design and in other cases they are simply “a skeleton of an application which can be customized by an application developer” [10]. Others consider them “a microarchitecture which provides an incomplete template for systems within a specific domain…” [8]. Mostly, the term framework is used to describe the design results that are reusable in any isomorphic situation. Often they are defined for a class of problems or
38
October 2002/Vol. 45, No. 10 COMMUNICATIONS OF THE ACM

problems within a specific domain. Frameworks in general describe a typical reusable situation at a model level, whereas component frameworks constitute “circuit boards” with empty slots waiting to be filled with components. When this is done the framework is said to be instantiated. Tkach and Puttick [12] distinguish three types or levels of frameworks: (1) technical frameworks that are similar to what is formerly termed application frameworks;
Interface that Satisfies Contracts

Component

Component Model

Coordination Services

Component Framework

(2) industrial frameworks; Figure 2. Relations and (3) application frame- between basic concepts of works. As can be seen, this component technology. definition to some extent conflicts with the former. Levels 2 and 3 in this definition correspond to what is also called “modelframeworks.” Level 2 is biased toward certain business areas, whereas Level 3 focuses more on applications (certain business problems within specific domains).

The Relations Between Concepts In the CBSE community, there is often confusion about the basic terms. For example, component models are intermixed with the concept of component frameworks. Bachman et al. [2] depict the relations among some of the terms in a very illustrative way as shown in Figure 2. The figure defines a component model as the set of component types, their interfaces, and, additionally, a specification of the allowable patterns of interaction among component types. A component framework provides a variety of deployment and runtime services to support the component model. Starting from this generalized view of a component technology, we discuss the relations between different concepts in more detail. Frameworks and Components. As stated earlier, frameworks could be seen as “circuit boards” with empty slots where components are inserted, creating working instances of the framework. A component is an atomic part that can only be used (and not changed) within the framework. Similar to operating systems, frameworks include common services such

as deployment or communication services or specific services obtained by particular components (for example, a scheduler). We can distinguish frameworks at component assembly time and at runtime. When a framework is instantiated, it becomes a component’s container, and at the same time it becomes a new component of the application. Thus finer grained components are inserted into a framework and largergrained enterprise components can be seen as encapsulating frameworks, once instantiated. Thus is the composite nature of components. A framework specifies the requirements a component must conform to in order to participate in the framework. The outer characteristics of the components are specified in an interface description. A remaining problem is how to formalize in more detail what interface the component should have to its surrounding framework. This notion of context is further explored in terms of a component’s manners. Frameworks and Contracts. Whereas frameworks concentrate on the overall properties of components participating in the framework, contracts give specifications for relationships between concrete components. These specifications may be different for components within one composition. As a contractually specified interface increases the component reliability and robustness, though when not carefully designed and implemented can significantly decrease the quality of other (extrafunctional) services such as performance or availability, it is important to integrate concepts of contract awareness into component frameworks [3]. Contracts express a more general principle, while frameworks identify particular components and rules. Some of these rules can be expressed using the contracts. Frameworks and Patterns. Johnson employed design patterns both in the design and the documentation of frameworks [9]. Design patterns are of a logical nature, representing the knowledge of and experience gained with software, whereas frameworks are of a physical nature, and are executable software used in either the design or the runtime phase. The relationship between frameworks and design patterns is a mutual relation: frameworks are the physical realization of one or more design patterns; patterns are the instructions for how to implement those solutions. Gamma et al. summarize in [5] the major differences between design patterns and frameworks. The first difference is the level of abstraction of frameworks and design patterns. Design patterns are more abstract than frameworks. The implication of this difference is that frameworks are implemented in a programming language, and represent reusable pieces of code that cannot only be studied but also be executed.

On the other hand, design patterns need to be implemented each time they are used, but they encode more knowledge about the trade-offs and consequences of the design. The second difference is that design patterns are smaller architectural elements than frameworks. A typical framework contains several design patterns, but the reverse is never true. The last difference is the level of specialization of frameworks and design patterns. Frameworks are more specialized and are employed in a particular application domain, whereas design patterns can be used in any kind of application. Components and Patterns. The relationship between components and patterns can be viewed as follows. Architectural or compound patterns can be used to describe the internal constitution and aid the contruction of components. An example of this is the Enterprise Component pattern [1]. Compound patterns contain design patterns. Design patterns are widely used in the process of designing componentbased systems in which the reusable units must be identified. By using design patterns, it is easier to recognize those reusable parts. Then, we can either find them in the form of preexisting components, or develop them as reusable units. Design patterns may be used to describe the behavior of the inner parts of a component, and thus can be used to develop components. Furthermore, design patterns may also be used to describe a component composition when designing an assembly or a framework that associates several components. Contracts and Interfaces. Contracts and interfaces are strongly related but quite different concepts. While an interface is a collection of operations that specify a service provided by a component, a contract specifies the behavioral aspects of a component or the interaction between components. While interfaces deal with syntactic aspects of functional properties of a component, contracts focus on the semantic aspects of such properties.

Conclusion CBSE is strongly related to new and innovative technologies, but it is also based on a long history of work in modular systems, structured design, and the OO approach. CBSE extends these well-established concepts by emphasizing outsourcing of pieces of a systems and the controlled assembly of those pieces through well-defined interfaces. We are witnessing an enormous expansion in using CBSE and have seen that many different concepts, definitions, and specifications lie behind attempts to successfully manage component-based development. Most of these concepts are in the research stage and first attempts are
COMMUNICATIONS OF THE ACM October 2002/Vol. 45, No. 10

39

being made at their successful utilization. As researchers and practitioners in CBSE community come from different areas, they bring with them different approaches and experiences. In general, this offers many advantages, but also creates some confusion in the understanding of basic concepts. In that sense, one of the currently most important objectives of CBSE is to clarify and formally specify the basic terms in order to provide a strong basis on the conceptual level. This will make it possible to further develop the concepts and improve some of the weaker parts of CBSE such as interoperability between different component technologies, maintenance aspects, and predictability of behavior of component compositions. c References
1. Arsanjani A. and Alpigini J. Using grammar-oriented object design to seamlessly map business models to component-based software architectures. In Proceedings of the International Association of Science and Technology for Development, 2001. 2. Bachman, F., Bass, L., Buhman, S., Comella-Dorda, S., Long, F., Seacord, R.C., and Wallnau, K.C. Technical Concepts of Component-Based Software Engineering. Tech. Rep. CMU/SEI-2000-TR-008, Software Engineering Institute, Carnegie Mellon University, 2000. 3. Beugnard, A. Making components contract aware. IEEE Computer, 1999. 4. Crnkovic, I. and Larsson, M. Building Reliable Component-based Systems. Artech Publishing House, Boston, 2002. 5. Gamma E., Helm R., Johnson R., and Vlissidies J. Design Patterns, Ele-

ments of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995. 6. Hissam S., Moreno G., Stafford J., and Wallnau K. Prediction-Enabled Component Technology: An Existence Proof. Tech. Rep. CMU/SEI-2001TN-007, ESC-TN-2001-007, Carnegie Mellon, Software Engineering Institute, 2001. 7. Holland, I. Specifying reusable components using contracts. In Proceedings of ECOOP, 1992. 8. Jacobson, I., Griss, M.L., and Jonsson, P. Software Reuse, Architecture, Process and Organization for Business Success. Addison Wesley and ACM Press, 1997. 9. Johnson R.E. Documenting frameworks using patterns. In Proceedings of OOPSLA, 2001. 10. Johnson, R.E. Frameworks = (Components + patterns). Commun. ACM 40, 10 (Oct. 1997). 11. Szyperski, C. Component Software: Beyond Object-Oriented Programming. Addison-Wesley, Reading, Mass., 1998. 12. Tkach, D. and Putticj, R. Object Technology in Application Development, Addison Wesley, Reading, Mass., 1996.

Ivica Crnkovic (ivica.crnkovic@mdh.se) is a professor of software engineering at Mälardalen University, Department of Computer Engineering, Västerås, Sweden. Brahim Hnich (Brahim.Hnich@dis.uu.se) is a Ph.D. student and lecturer at Uppsala University, Department of Information Science, Uppsala, Sweden. Torsten Jonsson (tjo@hig.se) is a Ph.D. student at the University of Gävle, Department of Mathematics, Natural, and Computer Sciences, Gävle, Sweden. Zeynep Kiziltan (Zeynep.Kiziltan@dis.uu.se) is a Ph.D. student at Uppsala University, Department of Information Science, Uppsala, Sweden.
© 2002 ACM 0002-0782/02/1000 $5.00

40

October 2002/Vol. 45, No. 10 COMMUNICATIONS OF THE ACM