The Maersk Mc-Kinney Moller Institute for Production Technology,. University of Southern Denmark, Odense Campus,. DK-5230 Odense M, Denmark.
Classifying Component Interaction in Product-line Architectures Bo Nørregaard Jørgensen, Wouter Joosen The Maersk Mc-Kinney Moller Institute for Production Technology, University of Southern Denmark, Odense Campus, DK-5230 Odense M, Denmark. {bnj, wouter}@mip.sdu.dk Abstract. This paper describes a set of interaction patterns that were used to facilitate the composition of components in the product-line architecture of a robot control system. The primary purpose of supporting a common set of component interaction patterns in a productline architecture is to reduce the learning curve of the inner working of the architecture. Interaction patterns provide the means for informal reasoning about the functionality and temporal behavior of components and their interconnections. In addition, it supports increased readability of the architecture diagrams.
1. Introduction In software engineering a product-line architecture [1] refers to a collection of software products sharing a common set of features that address the specific needs of a given business area. By using product-line architecture as a basis for development of new products in the business area, a common architecture is used to derive the architecture of its member products. Variations between products belonging to the same product-line architecture are captured by so called variation points. Variation points specify where we can expect structural, dynamic, as well as, temporal differences for how the components within the architecture interact. Hence, the core asset of a product-line architecture is a reusable architecture that explicitly handles variation in common features. To facilitate the development of product-line architectures by component composition the applied component framework must provide guidelines for component interactions. The components are the primary computational and storage entities of the system. In general, guidelines are necessary for preventing interface and contract mismatch between components developed by different component developers. This is important since total anarchy will require very skilled application developers that are able to write suitable adapters for gluing the components together. If too much time is spent on gluing components together instead of composing functionality, then the promised benefits of component-oriented software development is lost. Basically, a good component framework should ease the development process for both the component and the application developer. Hence, the guidelines for component interactions must capture all recurring patterns in order to ensure sound component interaction. Guidelines for component interaction can be enforced by requiring components to use a set of predefined interaction patterns. A set of interaction patterns can be defined as a number of syntax conventions for interface and method names. One well-known component framework that applies this approach is the Java Beans framework [2]. However, the interaction patterns in the Java Beans framework are aimed at reactive applications and are therefore not sufficient for
industrial control applications where periodic activities are common. Thus, interaction patterns for periodic activities must be defined in order to complete the picture. This paper is organized as follows: section 2 discusses five interaction patterns and how they relate to the temporal behavior of the components' information processing. Section 3 describes the application of interaction patterns in the product-line architecture of a robot control system. Related work is discussed in section 4. Section 5 concludes our work.
2. Interaction Patterns Components will in most cases depend on other components to fulfill their purpose. Typically these dependencies relate to information that is not available within the components themselves and must therefore be retrieved from other components. This is analogous to normal programming where abstractions depend on each other to achieve a common goal. Dependencies between components are expressed by the components calling each other's operations. This results in the exchange of information from one component to another. Basically three models for communicating information (i.e. in the form of data) between components can be identified by investigating different approaches to component communication [3],[4]. These models will be referred to as the push, pull, and mixed models. When communicating information, one component will supply the information and another will consume it. This relationship is expressed by the roles: supplier and consumer. The supplier is the source of data and the consumer is the sink. In the push model, suppliers "push" data to consumers; that is, suppliers communicate data by invoking "push" operations at the consumers' interfaces. The suppliers play the active role in maintaining data consistency. It is the responsibility of the suppliers to communicate data updates. In the pull model, consumers "pull" data from a supplier; that is, consumers request data by invoking "pull" operations at the supplier's interface. With the pull model, the supplier plays a passive role: it does not act whatsoever when data is updated. Therefore, the consumer is responsible for implementing the update policy by issuing data requests whenever necessary. The mixed model divides the responsibility of updating data between the supplier and the consumer. Here the supplier depends on the consumer to provide the data it needs to process the data requested by the consumer. The three basic models say nothing about when and why data should be updated; this decision is left to the application developer. Providing mechanisms for specifying "when" can eliminate the looseness in interaction specifications. The "why" will always be application specific! The rest of this section discusses five interaction patterns for communicating information between components. The patterns have their origin in the temporal behavior of component interaction, or how components interact through time (i.e. the "when"). This includes both composition-time and run-time. During composition-time, component interaction is comprised of the modification of component properties and the creation of connections between components. This activity involves components from the development environment and the application. During runtime, component interaction is only concerned with the components within the application. Run-time interaction can be sporadic or periodic and utilize either push, pull, or mixed communication styles. For instance, event notification in reactive systems is a typical example of sporadic push style communication. Figure 1 shows the classification of interaction patterns along the dimensions of communication style and temporal behavior.
Pattern Name Property Event Publisher Service Sampler
Communication Style Push Pull Mixed √ √ √
√
√
Temporal behavior Sporadic Periodic √ √
√
√
√ √
Figure 1. Classification of interaction patterns The first interaction pattern is identical to the Property design pattern in the Java Beans specification (The Java Beans specification refers to the use of syntax conventions as design patterns) and is included here for completeness of discussion. The second pattern is a modification of Java Bean’s Event design pattern. The Publisher pattern handles periodic activities with isochronous nature. The Service pattern facilitates the request of well-defined services offered by other components. Finally, the Sampler pattern supports periodic polling of a value from another component. The interaction patterns are presented as a number of syntax conventions for defining interface and method names. The syntax conventions for each interaction pattern are illustrated using the syntax of the Java programming language. The Unified Modeling Language (UML) could also have been used to document the syntax conventions, since they depend on the concepts of interfaces and methods and not on the features of a particular programming language. 2.1. Property The appearance and behavior of a component can be customized through its properties. For instance, a component that offers multiple algorithms for the same computation can dedicate a property to select the algorithm to use. An algorithm can then be selected through the property's setter method by an application developer at composition-time or by another component at run-time. In general, properties can be modified and accessed by other components by calling their corresponding setter and getter methods. This allows modification of properties at both composition-time and run-time. Thus, the use of getter and setter methods gives full control of component properties. If both the getter and setter methods are available, the property will be read-write. If only the getter method is available, then the property will be read-only. And if only the setter method is available, the property will be write-only. Participants Owner: The component to which the property belongs. A component must use the syntax conventions shown in Figure 2 for its getter and setter methods. public void set( property); public get();
Figure 2. Methods for modifying and accessing properties The method set changes the value of the property. The method get returns the value of the property. Modifier: The component that accesses or modifies the property. No additional syntax conventions are needed for the modifier. The modifier uses the target component's getter and setter methods to modify the property.
Applicability The Property pattern can be used to configure the properties of components at compositiontime or to change the properties of components during run-time. Temporal behavior Properties can be more than simple data fields or object references. They can be computed values based on other properties. Updating a property may have various programmatic effects; depending on whether the property's updating mechanism uses eager or lazy evaluation, either the property's setter or getter method can result in the firing of property change events, or recomputation of the property value. Consequences The properties which control the customization of a component are made explicit to the application developer. 2.2. Event The Event pattern fits applications with a reactive nature well. Such applications often consist of a collection of loosely coupled components in which each component carries out some operation that may, in the process, trigger operations in other components by firing events. By convention an operation that is triggered by an event does not return a result. A component may fire events spontaneously as a result of a change in its state or as a change in an environment parameter that it is responsible for monitoring. Participants Event Listener: A component that needs to be notified when some event occurs. An event listener must implement the interface that specifies the method to invoke when the event occurs. Figure 3 shows the syntax convention for defining an event listener interface. public interface Listener { public void on(Event event); }
Figure 3. Interface of an event listener The event source uses the method on to notify an event listener about the occurrence of an event. Event Source: The component that fires the event. An event source provides methods for registering and de-registering event listeners: public interface Source { public void add ( listener); public void remove ( listener); }
Figure 4. Registration methods of the event source Invoking the method add adds the given listener to the set of event listeners registered for events associated with the . Similarly invoking the method remove removes the given listener from the set of event listeners registered for events associated with the .
Applicability Use the Event pattern when a component has to inform other components about changes that will affect them. Temporal behavior Events are generated sporadically at a source and propagated to a sink (a listener). The generation of events may be instantaneous or it may require a substantial time period. A simple transformation of an I/O interrupt from an external device is an example of an instantaneously generated event. Events that are fired as a result of re-computing a component's properties are examples of time consuming event generation. The source does not impose any temporal constraints on the listener's processing of an event. Such constraints must be associated with the event at the listener side, meaning the acceptable response time for a particular event should be specified at the listener side. Consequences The Event pattern has at least one key benefit and one liability: 1. It provides loose coupling of listeners to the event source. 2. It does not support any ordering of events occurring at different components. If such an ordering is critical to the application, the developer must supply a solution. One common solution to the problem is to introduce a logical clock to timestamp all events within the system. 2.3. Publisher The Publisher pattern is suitable for systems with an isochronous nature. Isochronous pertains to the property of being equal or uniform in time. In information technology, this may refer to both processes and data sequences. Processes are said to have isochronous nature if they generate or process regular amounts of data at fixed time intervals. Similarly, data sequences are said to be isochronous if their elements are equidistant in time and require processing at equal time intervals. Audio and video applications are typical examples on applications that require isochronous processing of data. Examples of isochronous data sequences are computer generated data sequences, such as, computer animations and digital music. Participants Subscriber: A component that consumes data. public interface Subscriber { public void onReady( data); }
Figure 5. Interface of the subscriber The publisher uses the method onReady to deliver data to the subscriber. Publisher: A component that generates data that other components use to perform their functional responsibilities. public interface Publisher { public void setPeriod(long period); public void add ( subscriber); public void remove ( subscriber);
}
Figure 6. Registration methods of the publisher A
component
can
consume data registers itself by invoking the method add. This method adds the component to the publisher's set of subscribers. Similarly, invoking the method remove removes a subscriber from the set of registered subscribers. The registering method can be designed to take additional arguments, which can be used to describe the level of quality service that a subscriber requires. The time period between publication of data is set by the method setPeriod. Applicability Use the Publisher pattern when a component produces data that must be delivered to other components at fixed time intervals (i.e. time periods). Temporal behavior In the Publisher pattern, the data processing at the subscriber and the publisher sides is mutually dependent. The subscriber must be able to process the data published by the publisher at the same rate as the publisher produces it. This implies that the time required to process the published data, must be less than the publication period. The subscriber is responsible for verifying this relationship. In case of a timing mismatch, the subscriber should refrain from subscription. Similarly, the time required to produce the data must be less than the publication period, and the publisher should verify this constraint. The publication period can either be a property of the published data, or have its origin in the requirements of the subscriber. Consequences If more components subscribe to the same publisher component, they have to share the same update period. This is not always practical or possible; thus, it may introduce the need for more publishers of the same kind within a system (i.e. more publishers which publish the same data but with different time periods). Surveillance systems may be an example of this type of application. 2.4. Service The Service pattern captures the typical Client - Server relationship where one component needs another component to perform a service on its behalf. For instance, the computation of some value. A service represents a third functionality that other components can use to fulfill their own responsibilities. The component that offers the service depends on the client to provide information that it can not know; such information being typically client specific. The Service pattern assumes in two different forms: the synchronous form where the requestor blocks until the requested result is ready, and the asynchronous where the requestor receives the result by callback. Thus, the asynchronous form allows the requestor to perform other tasks while waiting. 2.4.1. Synchronous Service.
Participants Requestor: The component requesting a service from another component. Since the result of the service is returned as part of the invocation, no syntax conventions are necessary for returning the result. The requestor is implicitly given by the invocation mechanism. However, a method is needed for setting the service provider, see Figure 7.
public interface Requestor { public void setProvider ( provider); }
Figure 7. Interface of the service requestor The method setProvider sets the reference to the component that provides the service. Provider: The component providing the service. The provider must follow the interface specification convention shown in Figure 8. public interface Provider { public perform ( data); }
Figure 8. Interface of the service provider Invoking the method perform with an argument of the type implies that the service will be performed on the data contained in the object. The result will be returned in the object. Applicability Use the Service pattern when a component depends on the result of a service provided by another component in order to perform one of its own services. Temporal behavior The service offered by a component must be performed within the temporal constraints of the requestor. If this is not possible, the service should not be requested. This is important since the requestor waits until the provider has finished its execution. A late reply can cause a violation of the temporal constraints imposed on the requestor by the application environment. This implies that the temporal properties of a service should become part of the component's specification. Consequences The method setProvider makes the coupling between a component and its requested services explicit. This emphases the component's dependencies to other components. 2.4.2. Asynchronous Service: The asynchronous version of the Service pattern extends the synchronous version by defining a callback interface for returning the result to the requestor. This allows the requestor to perform other tasks while waiting for the result.
Participants Requestor: The component requesting a service from another component. public interface Requestor { public void setProvider ( provider); public void onResponse ( result); }
Figure 9. Interface of the service requestor The additional method onResponse provides the callback method for returning the result produced by the service.
Provider: The component that provides the service. public interface Provider { public void perform ( requestor, data); }
Figure 10. Interface of the service provider The signature of the method perform is extended so that it includes an argument of the type which refers to the component requesting the service. This is the reference on which the method onResponse will be invoked. Applicability Use the Asynchronous Service pattern when a component can perform other actions while waiting for the result of a service, provided by another component, that it needs to perform its own service. Temporal behavior As in the synchronous case, the service provider must deliver the result of the service request within the temporal constraints of the requester. Consequences In addition to the consequences of the synchronous case, the level of concurrency within an application is increased. 2.5. Sampler Continuous polling of a component at fixed intervals may be required to sample the value of a particular parameter. For instance, the value of some physical parameter in the system's environment. Participants Sample: The component that resembles the value of interest. public interface Sample { public sample(); }
Figure 11. Interface of the sample The method sample returns the sampled value of the parameter. Sampler: The component that polls the value from the sample. public interface Sampler { public void setPeriod(long period); public void setSample ( sample); }
Figure 12. Interface of the sampler The method setPeriod sets the sampling period. The method setSample sets the reference to the component that has to be sampled. Applicability Use the Sampler pattern when a component has to periodically poll a value from another component.
Temporal behavior Depending on how the value is obtained, the return of the sampled value may be delayed. If the delay exceeds the sampling period, it will result in a timing error in the application. Since timing errors can have fatal consequences for the correctness of a system operating in the real world, the developer must take precautions to ensure that the delay is smaller than the sampling period. Consequences The Sampler pattern offers the following benefits and drawbacks: 1. The method setSample makes the coupling between the sampling component and its target explicit. This emphases the dependency between the two components. 2. A well-known disadvantage of polling is that it uses a noticeable amount of system resources if it is used without forethought. Polling should only be used at the spots in the architecture where active retrieval of data is needed (e.g. from some sensor device).
3. Product-line Architecture for Robot Control Systems This section, describes the application of the discussed interaction patterns in a recent developed component-oriented product-line architecture for robot control systems. The robot control system was developed as a research project to address control of high-speed robots [7]. The robot control system aims at the application area of spray painting. However, a requirement for the developed architecture is that it must be applicable to previously explored application areas, such as robot welding and cutting. This implies that the architecture must be adaptable to different robot types and control strategies. However, a full description of the product-line architecture for the robot control system is beyond the scope of this paper. 3.1. Component Architecture Inspection of previous applications for robot welding and cutting led to the identification of the components shown in Figure 13. The functionality of the components relate to the two logical tasks of robot motion: 1) deciding how to move the robot to the target position, and 2) moving the robot to the target position. Briefly, the individual components responsible for performing the following tasks are: Task Scheduler: handles the execution planning of robot tasks. For example, welding a line segment between two iron plates. Trajectory Planner: responsible for planning a collision free trajectory for the robot while performing a task. Parameter Optimizator: evaluates and updates the robot model according to the observed physical behavior of the robot. Force Generator: computes the forces that must be applied to the robot's joints to obtain the desired motion. Joint Controller: responsible for applying the generated forces to the robot's joint actuators. Physical Model: contains the mathematical description of the robot's physical properties (e.g. friction, momentum, weight, etc.).
Trajectory Planner
Task Scheduler TargetChange Source
TargetChange Listener
Position Publisher
Position Subscriber Physical Model ModelUpdate Source
Force Generator
StatisticalData Publisher
ModelUpdate Listener Force Publisher
Parameter ChangeListener Statistical DataSubscriber Parameter Optimizer Parameter ChangeSource
SensorData Subscriber Force Subscriber Joint Controller
SensorData Publisher
Figure 13. Components in the robot control system 3.2. Component Interaction Figure 13 shows the interaction patterns used to direct the interaction between the components in the robot control system. The different interaction patterns can be identified by the concrete interfaces derived from the syntax conventions that define each pattern. Syntax conventions allow straightforward deduction of the behavior of the individual components from the interfaces that they implement. For example, from the TargetChangeListener interface of the TrajectoryPlanner component, it is observed that it listens for occasional changes in the target position, and similarly from its PositionPublisher interface it is observed that it periodically publishes new positions. Consequently, it can be deduced that the TrajectoryPlanner component must generate intermediate positions between target positions, since the target only changes occasionally and the TrajectoryPlanner component publishes new positions periodically. Currently, four of the five interaction patterns have been applied. Figure 13 shows the use of two: the Event and Publisher patterns. The other two are the Property and Service patterns. The Event pattern handles the exchange of sporadic changing information, an example being the change of parameter values in the physical model component. The Publisher pattern connects components that produce and consume isochronous information. For each informationproducing component, the production period depends on application specific characteristics (e.g. the type of robot, task, and control strategy). The Property pattern is utilized to facilitate the configuration of components. For instance, the applied force control strategy is selected through the ForceGenerator component's control strategy property either at composition-time or run-time. Finally, the composition of application specific components from other more general-purpose components is done by the Service pattern. The Sampler pattern was not applied in the current version of the product-line architecture, but this may easily change as the architecture evolves to include different kinds of sensor devices for monitoring the environment in which the robot operates. Monitoring includes obstacle detection, which is necessary for avoiding collisions with equipment and other robots present inside the working field of the robot.
4. Related Work Other development and research efforts have addressed aspects of interaction between independently developed components [2],[8],[9]. However, these efforts are only concerned with the description of the dynamic behavior of component interaction (i.e. specification of message sequence). Work in our group also focuses on the temporal behavior of component interaction. In [8] the concept of a Connector is proposed for describing the interconnection between components. A Connector is defined as a set of roles and a glue specification. The roles describe the expected local behavior of each of the interacting parties while the glue specification describes how the activities of the roles are coordinated. This approach allows one to define reusable connector classes that can be instantiated as needed to interconnect the high-level computational components of the system. The interaction patterns proposed herein can be described as Connector classes, if the dynamic behavior is the only factor taken into consideration. However, the temporal constraints between components can not be described. The Java Beans [2] component framework uses simple design patterns consisting of conventional names and type signatures for methods and interfaces to specify what properties and events that a Java Beans component supports. The use of design patterns allows the application developer to quickly identify the particular properties and events of a component. However, the Java Beans' component model only addresses event driven component interaction, which is not enough for industrial control applications which depend on correct exchange of isochronous data. The idea of contracts for specifying the contractual obligations that a set of communicating objects must obey to collaborate was proposed in [9]. Briefly, a contract specification includes the specification of the participating objects, the contractual obligations of all participants, the invariants to be maintained by the participants, and the method which instantiates a contract. In order to put a contract to use, a conformance declaration must be made which initializes the contract with actual participants. Obviously, these participants must satisfy the contractual obligations of the contract. Contracts seem quite useful for the implementation of coordinated behavior and the abstraction of object interactions, but they are unable to express temporal behavior. The interaction patterns applied here have been described using a similar approach to that of the Design Pattern book [5] but with the additional “temporal behavior” section. This similarity rises the question whether the discussed interaction patterns are patterns in the traditional sense or not. The classification scheme in [5] classifies Design Patterns along the dimensions: Creational, Structural, and Behavioral. Our classification differs by classifying along the dimensions of communication style and temporal behavior. However, this does not exclude the discussed interaction patterns form being design patterns; instead it suggests that the classification space of Design Patterns most likely is larger than first assumed.
5. Conclusion The documented set of interaction patterns comprises a framework for 'wiring' components together. Every component within the architecture must implement all interfaces that are required for interconnecting it with other components. The framework de-couples a component from the implementation of connected components by defining interfaces for information exchange. This approach supports the composition of software products from individually developed components since no prior knowledge about the components' implementation class is required. This is possible because interfaces allow late binding by introducing an indirection in message dispatching. However, the intended semantics of the interfaces that define the
interaction patterns can not be enforced. It is still the responsibility of the component developer to ensure that his component act in accordance with the semantics of the interfaces which it implements. Furthermore, the interaction patterns provide the component developer with valuable information about what is expected from his component, and the application developer with information about how components should be composed. From the software engineering perspective, a key goal in the robot controller project was to reduce the time required for new component developers to learn the component architecture of the robot control system. This goal has been achieved by requiring the component developers to follow the syntax conventions of a set of common interaction patterns. Standardizing on a set of common interaction patterns for interconnecting components will enable developers to easily recognize the interactions and temporal constraints between a system's components; thus, minimizing the risk of interconnection mismatches.
References [1] F. van der Linden (Ed.), “Development and Evolution of Software Architectures for Product Families”, Proceedings of the Second International ESPRIT ARES Workshop, Las Palmas de Gran Canaria, Spain, February 26-27, 1998, LNCS Springer, Vol. 1429. [2] Sun Microsystems, Java Beans specification 1997. http://java.sun.com/beans. [3] CORBAservices: Common Object Services Specification, Volume I, July 1997, Object management Group formal/97-07-04. [4] Oscar Nierstrasz, Dennis Tsichritzis. Object-Oriented Software Composition. Prentice Hall 1995. ISBN 0-13220674-9. [5] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable ObjectOriented Software. Addison-Wesley 1995. ISBN 0-201-63361-2. [6] Mary Shaw, David Garlan, "Software Architecture: Perspectives on an emerging discipline", Prentice Hall, 1996. ISBN 0-13-182957-2. [7] J.W. Perram, H.G. Petersen, P.T. Ruhoff and A. Sørensen, "A New Model for Advanced Control of Robotic Manipulators", Proceedings of the 6th IASTED Int. Conf. on Robotics and Manuf. p. 120-124. [8] Robert Allen and David Garlan. Beyond definition/use: Architectural interconnection. In Proceedings of the ACM Interface Definition Language Workshop, 29 (8). SIGPLAN Notics, August 1994. [9] R. Helm, I. Holland, D. Ganghopadhyay, Contracts: Specifying Behavioral Compositions in Object-Oriented Systems, OPPSLA'90, pp.169-180, 1990. [10] Bo N. Jørgensen, Wouter Joosen, "Dynamic Scheduling of Object Invocations in Distributed Object Oriented Real-Time Systems", In ECOOP'98 Workshop Reader on Object-Oriented Technology, LNCS Springer 1998.
