Graphical Composition of Components with Feature Interactions Christian Prehofer∗ In this paper, we present a graphic description method for modeling software components with state diagrams (or automata). We build components by composing features, which define particular services or aspects of the component. The behavior of features is specified individually with partial (or incomplete) automata. Using refinement concepts for automata complete component descriptions are created by combining the partial automata of the desired features. In addition to this cross-cutting of components, we also consider feature interactions, which is a well known problem from the telecommunications area. We use adaptors as a glue for combining highly-entangled features which do interact. In this way we show that graphical software modeling with state diagrams can be extended to modular composition of features.
1. Introduction In this paper, we present a graphic description method for developing software components with state diagrams (or automata). We build components by modular composition of features, which define particular services or aspects of a component. As in aspect-oriented programming, we aim at cross-cutting of components, but with the focus on graphic component descriptions. A key issue in our approach are interactions between features, which means that a feature must behave differently in the presence of another feature. This is a well known problem from the telecommunications area, from where we also take the terminology of features and interactions. To model the behavior of features, we use partial or incomplete automata which reflect a service or aspect of a complete automaton. With refinement concepts for automata, such as parallel composition and hierarchical automata, component descriptions are created by combining the partial automata of the desired features. In addition to this cross cutting of components, we also consider adaptors between features to handle feature interactions. We use these adaptors as a glue for combining highly-entangled features which do interact. In this way we show that graphical software modeling with state diagrams can be extended to modular composition of features. A key problem we address here is that features often have to cooperate or interact in unforeseen ways. In the example of an email server, [Hall00] has analyzed 10 common features of an email system and discovered about 25 feature interactions. This is a well known problem in telecommunications, which lead to a research branch focusing on tools and methods to handles interactions (see e.g. [FIW]). For instance, encryption and auto-responder interact as follows. The auto-responder answers emails automatically by quoting the subject field of the incoming email. If an encrypted email is decrypted first and then processed by the autoresponder, an email with the subject will be returned. This however leaks the originally encrypted subject if the outgoing email is sent in plain. Hence combining these seemingly independent features is not fully modular, as such special cases have to be considered. We show in the sequel our concepts by the above email example. Its main features (see also [Hall00]) are: - Encryption and decryption for encrypted mails. - Filtering particular emails, e.g. for spam or virus protection. - An auto-reply feature for automatic answers to all incoming emails.
2. Features and Feature-Interactions A feature is an entity which offers an interface with functions and encapsulates internal state, like a class in object-oriented development. Instead of aggregation or inheritance relations, we use feature combination as shown below [Prehofer01]. Compared to aspect-oriented programming we concentrate on dependencies or interactions between features. For these interactions, we consider particular interaction handling schemas. There are basically three ways in which features can interact – if they are not fully independent. The following illustrates these three cases: ∗
[email protected], DoCoMo Euro Labs, Landsbergerstr. 308-312, 80687 Munich, Germany, Tel. +49 89 56824223, Fax 49 89 56824-300
1
- Two features are simply contradictory or incompatible and cannot be used together. - Features have to be adapted in the presence of others to account for special cases. - In many cases features complement each other and additional functionality is required. Our approach solves these problems by adopting a clear and simple scheme for interaction. In case two features interact, one feature is adapted in this case. This covers the majority of all interactions and leads to a clearly structured composition architecture. Note that we consider feature interactions only pair-wise for two features at a time. We refer to [Prehofer01, Hall00] for a discussion on these common assumptions. For adapting a feature A to account for a feature B, we speak of a lifter or an adaptor of A to B, which adapts the a feature A in the presence of feature B. This lifter is also written as A à B and may adapt transitions on the automaton level, similar to method adaptation in object-oriented languages. We use layered composition of features in a fixed order. Figure 1 shows how to obtain a combination of features F1-Fn by adding feature Fn to a combination of the features F1, ..., Fn-1. Since feature Fn may add new functionality and state variables, the features F1 – Fn-1 adapted by the appropriate lifters. In the general case, we need n-1 lifters, one for each of the inner features. Note that this adaptation has to be done repeatedly each time a feature is added. For instance, the feature F1 in Figure 1 may have been adapted n-1 times. Feature Combination or Features F1, ..., Fn-1 F1 à Fn
F2 à Fn
Fn-1à Fn
Lifters adapt features F1 ... Fn-1 to Fn Feature Fn adds methods and state
Feature Fn
Figure 1: Incremental Composition of n Features
3. Modeling Features and Interactions by Automata In this section, we describe graphic tools to model the internal behavior of features. We describe features and interactions by automata where transitions are labeled with function calls. The finite number of states of an automaton usually represents an abstraction of the internal states a feature can have. As we aim at specifying the functions of a feature, transitions are labeled by function calls which trigger this transition. The novel point here is that we describe the features and interactions modularly as fragments of automata. For a concrete feature combination, we show how to combine these (automatically) to an automaton for the combined functionality. For the combination, we will make extensive usage of hierarchical automata and parallel composition of automata. When modeling features with automata, we can distinguish the following three kinds: - Features with a complete automaton, including an initial state. - Features which represent a partial automaton with some states and transitions. For instance, consider a feature with a new state called MaintenanceMode. This automaton may not have an initial state and its state may be reachable by new transitions from the states of other features. - Features with utility functions, e.g. encryption functions, which are modeled only by transitions. None of these functions has persistent state between function calls. An example of the first kind is the automaton in Figure 2 describing the basic functionality of an email system in a feature called BasicEmail. We have two states, one waiting for email and the other called Email arrived which means that an email has arrived. The transition labeled incoming() occurs if an email has arrived. The transition labeled deliver is the actual processing of the new email. This simple model of an email system only handles one email at a time. Note that we indicate functions by parentheses as in f(), which does not mean that these are parameter-less functions.
2
deliver() Waiting
Email arrived incoming()
Figure 2: The BasicEmail Feature Utility features in the email example are the encryption and decryption features, which consist of a single transition each. An actual implementation of these features may have persistent state, but his is not modeled here. encrypt() decrypt()
Figure 3: Encryption and Dencryption Features (Abstract View) We use the following notation for la beling transitions: {condition} called_function() / action A transition can be initiated by an external event, here called_function(). It may have a condition and it may have an action it initiates. This action may affect another automaton. Note that all three labels may be empty. In case the called function is omitted, we have an internal or spontaneous transition without an external event. For the following forwarding and reply features, we take a more detailed view and show the internal states of the forward and reply functions. The feature Forwarding includes also a function call do_forward which is not detailed here. The reply feature is similar. On a more abstract view, we could also model these by simple transitions as above. Note that we use two small circles to denote the start and end states of this transitions, which are determined upon composition. Feature Forwarding: forward() {forward_active} /do_forward() Forward {forward_inactive} Feature Reply: reply() {reply_active} Reply
/do_reply()
{reply_inactive}
Figure 4: Internal View of Forwarding and Reply Features 3.1. Feature Interactions Interaction handling adapts a feature into the context of another one. With automata, we have two ways to refine a feature A to the new feature B: - The transitions of feature A may be refined. We model this by hierarchical automata. - New transitions from the states of A to states of B triggered by function calls of B. For instance, the above feature MaintenanceMode may have a function enter_maintenance_mode, which can be triggered by a transition in another feature. (See also [PrehoferFIW97] for this kind of feature interactions.)
3
We describe the first case in terms of automata by expanding the transitions labeled by function calls. More formally, this can be seen as an hierarchical automaton. For instance, Figure 5 shows how the deliver function is adapted to the decryption feature. The transition is expanded by an automaton with two transitions and a newly added state, where the decrypt function is of the added feature and BasicEmail.deliver() the function of the extended feature combination. Note that this function is now viewed as an operation of an internal transition, and not as an externally triggered function. BasicEmail à Decryption: deliver() /decrypt() Plain Mail
/BasicEmail. deliver()
Figure 5: Lifting BasicEmail to Decryption BasicEmail à Forwarding: deliver() /forward()
/deliver() Fwd Mail
Figure 6: Lifting BasicEmail to Forwarding Interaction between automatic reply and encryption is a typical special case, which can often be modeled by adding and/or restricting transitions. The interaction here can be handled similar to the above and is shown in the figure below. Note that the function replyCrypto is not detailed here. Reply à Decryption: do_reply() {mail_wasEncrypted()} /replyCrypto() {else} do_reply()
Figure 7: Lifting the Method do_reply of the Feature Reply to the Decryption Feature In the general case, a lifting can refine a transition of the lifted feature by extending the transition to a local automaton with internal transition. We do not permit externally triggered functions in this refinement, since this may change the external semantic interface. (See also [Klein97] for refinement.) The function which is refined can however be used in the operation associated with an internal transition. 3.2. Combining Features and Interactions We show in the following how to combine features and their interaction handlers in a sequential, ordered way. The idea is that a tool generates the automaton for a concrete feature combination. We use several forms of automata refinement, including transition refinement and parallel automata. For a more detailed semantic treatment of refinement we refer to [Klein97,Rumpe96]. We first cover the simpler case of adding utility features, without an automaton with persistent state. In this case, the combined automaton can be obtained by unfolding the interaction handlers in the automaton one after the other. Adding features with internal control state is considered in the following section. We consider a typical case which a base feature, which is externally visible, and auxiliary features, which do not change the external interface. We show the combination method by the above example. We first consider adding features to the base feature, then we look at other kinds of interactions. The combination proceeds sequentially and produces a typical pipeline-architecture, where the input is passed from one feature to another. For instance, the message
4
is first decrypted, then the signature is verified and then it is delivered to the client. Hence, the interaction consists of extending the message delivery function of the basic email feature. For the reverse direction, not shown here, one has to extend the message incoming function in a similar way. If no lifter between two features exists, we assume that the features can be combined in any arbitrary order. If feature A must be adapted in case of B, A must clearly be added before B. In this way, the interaction handling defines the order of the feature combination. The hierarchical automaton in Figure 8 shows the combination of three features, extending the basic email feature. The delivery function has been refined to an inner automaton. Note that the transitions in this automaton are internal transitions, which are not visible externally. deliver() /do_forward() Forward
Fwd Mail {forward_inactive}
{forward_active}
/decrypt() Plain Mail /BasicEmail.deliver()
Email arrived
Waiting incoming()
Figure 8: Combination of Basic Email, Decryption and Forwarding In similar fashion, we can combine three other features, including the reply and decrypt features. While the above combination shows mainly how to combine cooperating features, this combination also illustrates the interaction between the reply and decrypt features. deliver() {reply_active} Plain Mail
Reply
{mail_wasEncrypted()} / replyCrypto()
{else} /reply()
/decrypt() {reply_inactive}
Reply Done
/ BasicEmail.deliver() Waiting
Email arrived incoming()
Figure 9: Combination of Basic Email, Auto Reply and Decryption 3.3. Adding Features with Control State So far, we have expanded automata of auxiliary features during combination. For more complex features this method is however insufficient. In the general case, we combine features with individual automata. We obtain two parallel automata with disjoint signatures. This is typically needed if features add external methods and may affect the control state.
5
For instance, consider a generic locking feature, which disables all function calls to an object which change the state. In the case of the mailer, this may be used to stop receiving/sending, e.g. to configure or inspect the mailer. The lock feature has two externally visible functions, lock and unlock, and two states. When combining the BasicEmail and the lock features, the interaction handling must block the message delivery and message incoming. We only show the combined automaton below. Note that we model the blocking of transitions by adding conditions to the transitions, which is a particular form of transition refinement. Note that lifters can extend the functions in the parallel automata and can add function calls to other automata. For instance, a lifter to lock may invoke the lock() operation of the Lock feature. For illustrating this, we show here a new function of the basic email feature, called reset. When adapting this to function to Lock, this transition has to unlock the Lock. When adding another feature we may have to lift all the previously lifted functions. With parallel automata, only the transition of one automaton has to be lifted. With unfolding, a transition may occur several times in other lifters and hence has to be unfolded several times. {is_unlocked()} deliver()
Email arrived
waiting {is_unlocked()} incoming()
reset() / unlock()
unlock() unlocked
locked lock()
Figure 10: Parallel Automaton with the adapted BasicEmail and Lock Features
4. Conclusions We have presented a novel approach for cross-cutting state description diagrams which supports flexible composition of features. The main contribution is the automatic combination of features, which is advantageous in cases where different variations or extensions of a software component are needed. In general, an exponential number of feature combinations can be created from a set of features with a quadratic number of interactions [Prehofer01]. With our graphic design techniques, we have shown plug-and-play concepts for the construction of complex automata, which describe a component with several features. We view this paper as a first contribution towards separation (and flexible composition) of concerns for graphic description languages like UML. While state diagrams are a very important part of UML, UML includes a number of diagrams which we have not yet covered and remain for future work. Furthermore, scalability and development methodology have to be examined. There is little related work on this subject. Regarding automata composition, semantic refinement relations for automata based descriptions are pursued in [Klein97] which can serve as a semantic foundation for the approach shown here. There are several other works which consider flexible composition schemes, but only in the context of object-oriented programming languages [Prehofer01, Elrad01], but do not consider graphic modeling of components. Our composition methods whit layers resembles other layered architectures for feature composition [Batory97, Demeter96], which lack explicit support for interactions.
5. References [Batory97] [Demeter96]
D. Batory and B. J. Gerac. Composition validation and subjectivity in Genvoca generators. IEEE Transactions on Software Engineering, February 1997. K. Lieberherr, Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns, PWS Publishing Company, Boston, 1996 6
[Elrad01] [FIW] [Hall00] [Klein97] [Prehofer97] [Prehofer99] [Prehofer01] [Rumpe96]
Tzilla Elrad, R. E. Filman, A. Bader, Aspect-oriented programming: Introduction, Communications of the ACM, Volume 44 , Issue 10 (October 2001) Workshops in Feature Interaction, see www.cs.stir.ac.uk/~mko/fiw00/ R. J. Hall, Feature Interactions in Electronic Mail, IEEE Workshop on Feature Interaction, IOS-Press, 2000 C. Klein, C. Prehofer und B. Rumpe, Feature Specification and Refinement with State Transition Diagrams, In.: P. Dini (Ed..), Fourth IEEE Workshop on Feature Interactions in Telecommunications Networks and Distributed Systems, IOS-Press, 1997. C. Prehofer, Feature-Oriented Programming: A Fresh Look at Objects, ECOOP '97 -Object-Oriented Programming, Springer LNCS 1241, 1997. C. Prehofer, Flexible Construction of Software Components: A Feature-Oriented Approach, Habilitation Thesis, Technical University of Munich, 1999 C. Prehofer, Feature-Oriented Programming: A New Way of Object Composition, Concurrency and Computation. 2001 B. Rumpe and C. Klein, Automata Describing Object Behavior, In: Specification of Behavioral Semantics in Object-Oriented Information Modeling, Kilov, H. and Harvey, W.(Eds.), Kluwer, 1996
7
