e-mail: {johan.lilius, dragos.truscan}@abo.fi. Abstract ..... [KCH+90] Kyo C. Kang, Sholom G. Cohen, James A. Hess, William E. Novak, and A. Spencer Peterson.
Using feature models to automate model transformations Johan Lilius, Dragos Truscan∗ Turku Centre for Computer Science and Åbo Akademi Lemminkäisenkatu 14, FIN-20520 Turku, Finland e-mail: {johan.lilius, dragos.truscan}@abo.fi
Abstract This paper presents work in progress to explore the possibility of combining model-driven and domain modeling techniques to facilitate support for reuse and automation. The approach is based on the fact that the models specifying the system at different levels of realization can belong to different application domains. Therefore, to facilitated the implementation of transformations between models, mappings are created between the domain concepts present in each model. We exemplify with the implementation of an IPv6 router on a protocol processing platform.
1
Introduction
Model Driven Engineering (MDE) has lately become the de facto standard in providing tool support and automation for complex specifications. The main idea behind MDE is the use of well-defined models to describe the systems at different levels of detail and model transformations to go from one model to another in an automated manner. Starting from business specification down to specific implementations, the MDE process usually spans over several application domains each of them requiring the expertise of specific domain experts. During the MDE process the models of the system are populated with concepts of different application domains. In the subsequent steps, the concepts of one domain are refined into concepts of a different domain to provide a more detailed and implementation specific view of the system. Therefore, we consider that instead of mappings being created between models of the system, they can be created between the concepts of the corresponding domain concepts and reused for different models of the same domain. To be able to identify domain concepts, specific domain analysis techniques are required. One such technique is represented by feature modeling, where features of the system (family of systems) are identified. Feature models (FM) are an important and, in our opinion, an efficient tool, for describing reusable assets of a given domain, mainly because they are simple and easy to use by domain experts. This paper presents ongoing research aiming at combining the model-driven and domain engineering techniques for the development of protocol processing applications. We show how, by using feature models and mappings between domain concepts they model, transformations between MDE models described in terms of domain concepts can be automated. We also present a short example of the approach.
2
Domain Modeling in protocol processing
A domain model is a representation of what ”happens“ in a domain: functions being performed, data, information and entities flowing among the functions. Usually the domain model is composed of several models that provide different perspectives (e.g., structural, functional, relational) of the domain in question. An overview of some of existing domain methodologies can be found in [CE00] and [KCH+ 90]. ∗
Financial support for this work from the HPY Research Foundation is acknowledged by the second author.
1
One of the most popular tools for domain analysis is the feature diagram [KCH+ 90]. It provides a view of the domain in a tree like structure containing ”and“, ”or“ and ”xor“ branches, modeling mandatory, optional and alternative features of a family of systems, respectively. Their corresponding notations are illustrated in Figure 1. In addition, composition rules (i.e., requires and exclusion) can be specified to describe structural relationships among different features. Feature diagrams are usually complemented with other modeling formalisms, like object diagrams, interaction diagrams, or entity-relationship diagrams, to provide enhanced semantics of the domain model. To be able to easily combine feature diagrams with our model-driven methodology we propose feature feature feature to use class diagrams to represent them. In the class diagram each feature is modeled as a class, feature2 feature2 feature1 feature1 feature2 feature1 and additional properties of a given feature can (a) (b) (c) be added as properties of the class. To model commonality and variability of features we use Figure 1: Mandatory (a), optional (b) and alternative constrained UML association relationships as pre- (c) feature notations. sented in Figure 2. Alternatively, stereotyped classes could be used. One much debated problem in the related literature was how to define cardinaliNewActor_18 ties of the feature relationships, and solutions using UML based notations were proposed in [RBSP02]. Since this is an already elucidated aspect we will not get into details. We can also specify ordered sets of sub-features, meaning that the sub-features of a given feature compose that feature in a specified order (e.g., using the {ordered} constraint). In our research we address the development of protocol processing applications that can be imfeature feature feature plemented on various platforms, software or hardware, fixed or reconfigurable. Telecommunication {and} {xor} {and} {or} {or} {xor} protocols are complex field and their features can feature1 feature2 feature1 feature2 feature1 feature2 be classified and analyzed in several ways. For instance, in [Par04] the identification of domain (a) (b) (c) concepts is based on the architecture of the system, like routers, hosts, sockets, etc. Although Figure 2: Mandatory (a), optional (b) and alternative HopLimit this is a perfectly good approach, we would like (c) features using class diagram notations. + to adopt a different perspective, in which we fo+ test ( self : , val : , res : ) : + set ( ) : cus on the data that a protocol processing system has to process. We focus on this approach because one + decrement ( ) : + the implementation platform of the main goals of our model driven design methodology is to configure (i.e., a protocol processor) based on the processing support it has to provide to a given application. In our opinion, processing is strongly influenced by the "conceptual" protocol data used by the application. We consider that there are two possible perspectives from which the features of a given family of protocol processing applications can be modeled: a data and an operational perspective, respectively. The two perspectives cannot be completely separated, since they depend on each other. For instance, if we focus on the operational features of the system, data needed by different operations is implicitly embedded in the model. Similarly, if we focus on a data perspective of the system, then the operational features will be implicitly present in the model. Consequently, during protocols analysis we classify domain assets into protocol data (i.e., conceptual data types used by a given protocol) and protocol operations (operations needed to process data of a specific type). We chose to focus our analysis on how protocol features are specified in terms of data (e.g., datagrams, packets, fields, etc). A partial example of a class diagram modeling the features of IPv6 routing applications is presented in Figure 3. The elements in the diagram are used during the application specification, to populate platform-independent models describing the functionality of the system. It is important to note here, that we are not only interested in identifying the features, but also their properties. Moreover, a feature can be decomposed hierarchically into other features, which in our case is similar to defining the substructure of a given data entity. For instance, one protocol packet can be composed in a number of data fields (some mandatory, some optional), each such field having certain properties in terms of data type (see the type feature
feature1
feature
feature2
feature1
feature2
attribute), and operations that it triggers in the protocol processing application. Other properties of the features can be added, for instance a requiredValue expressing the required value of given feature in order to be valid. Protocol operations associated to features are added as properties (i.e., class operations) of each class separately. The parameter of the class operations have a number of input, output or input/output parameters with well-defined types. It is important to note, that different classes can have the ”same“ protocol operations, but each having its own parameters of specific types. The reason to chose this approach was: (a) it obliges the domain analyst to pay attention and analyze each feature of the protocol data in part and to identify its corresponding protocol operation; (b) it allows for a protocol operation on a higher level in the feature diagram to be decomposed into similar operations applied to sub-features of the higher feature; (c) it makes easier the mapping of protocol concepts to various implementation platforms that can provide different levels of granularity to implement a particular operation. Although MDE advocates storing of model mappings outside system models, for the moment we store them inside feature models, by providing implementations of protocol operations as methods of feature classes. The idea is based on the way UML metamodel defines methods as implementations of class operations. Several methods (i.e., implementations) can be associated with a given operation. To distinguish between implementations of different implementation platforms, the method’s name contains the name of the platform. For instance, the __C_checksum() represents the C implementation of the checksum protocol operation. In future work, we will evaluate storing of mappings outside models in the form of other models. Once the mappings between domain Figure 3: IPv6 routing features class diagram concepts are defined, applying the transformation between models belonging to separate application domains can be fully automated and reused for several models using the same domain concepts. routing
{and}
Protocol Data
{and}
entities
{and}
1..* +
+ IPv6Datagram
{and}
interface +
+ Discard ( ) :
{and}
IPv6Header
Version
{and}
+ 1
1 +
type : 4b +
{and}
FlowLabel
type : 12b +
{and}
{and}
{and} + NextHeader
PayloadLength
type : 8b +
Router
IPv6Payload
{and}
+ TrafficClass {and} type : 20b +
{and}
{xor}
{and}
{or}
+ ExtensionHeaders
1 +
{xor}
Host +
+
{or}
{xor}
{xor}
{xor}
+ ...headers...
+ICMPv6
+ TCP
UDP
+ HopLimit
type : 8b +
{and}
+ Dec ( ) :
type : 16b +
+SourceAddress
+ largerThen ( ) :
type : 128b +
+
type : 128b +
+ test ( self : 128b , val : 128b , res : Bool ) : + __C_test ( self : 128b , val : 128b , res : Bool ) : + __TACO_test ( self : 128b , val : 128b , res : Bool ) :
UDPPayload
+
{and}
+ DestinationAddress
{and}
UDPHeader
SourcePort
type : 16b +
Checksum+
type : 16b +
{xor}
{and}
{and} {and}
+DestinationPort
+RIPng
type : 16b +
+UDPPayloadLength type : 16b +
Command
type : 8b +
{and}
RIPngHeader
{and} Version
type : 8b +
{and} + RIPngPayload
{and} {and} + +Padding
{and} 1..* RTE
type : 16b +
Bool
3
Example
As a case study we used an IPv6 router specification to be implemented on a TACO protocol processor [Vir04]. TACO processors consist of a set of functional units (FUs), implementing its function independently, connected through one or many busses. An operation of the processor occurs as a side-effect of the bus transports between FUs. The functionality of the processor resides in its functional units, each FU implementing one or many processor operations. Due to space reasons only a very simple example is presented here. Figure 4-left presents a part of the specification modeled as an Activity Diagram. The states contain protocol operations applied to specific protocol data. Once a implementation platform is selected, the model transformation is applied in two steps: firstly, the control structure of the Activity Diagram is transformed into control structures of the implementation platform (Figure 4-middle); secondly, each state’s operation is replaced with a corresponding implementation method (Figure 4-right) already present in the domain model. We avoid giving the transformation code here, but similar examples were presented in [TFL04] [ALPT04]. We mention that due to the way the domain concepts mappings were specified, the transformation was automated.
PayloadLenght.largerThan(self:16b, 42:16b; res:Bool) [!b]
IPv6.Discard()
[b]
HopLimit.Dec(self:8b)
LABEL State1; PayloadLength.__TACO_largerThen(); b.JUMP State3; !b.JUMP State2; ENDLABEL State1;
LABEL State1; //comparator self > OPCM; +42 > TGTCM; //result bit b b.JUMP State3; !b.JUMP State2; ENDLABEL State1;
LABEL State2; IPv6.__TACO_Discard(); ENDLABEL State2;
LABEL State2; //outputFU self > OPOUT; +05 > TROUT; ENDLABEL State2;
LABEL State3; HopLimit.__TACO_Dec(); ENDLABEL State3;
LABEL State3; //counterFU self > TSC; +01 > TDC; RC > res; ENDLABEL State3;
Figure 4: Initial specification (left), results of the first (middle) and second (right) transformation steps It is important to mention that, as side-effect of the transformation, the implementation platform (i.e., the TACO processor) is configured. In the case of TACO, protocol operations can be supported by one or many processor operations and, consequently, by a number of FUs that provide the operations. As the result, the deliverables of the transformation (i.e., processor configuration modeled using the TACO UML profile [Tru04] and the program code to exploit that configuration) were obtained automatically.
4
Conclusions and future work
We presented work in progress in which we attempt to combine domain modeling and model-driven techniques to provide automation and reuse. The use of feature models was proposed to provide not only reusable domain concepts to be used during modeling, but also predefined mappings between domain concepts. To be able to integrate feature model with model-driven environments, a class-diagram-like notation was proposed; it allowed us to interrogate and manipulate elements of the feature models in an automated manner using model scripts and to implement fully automated model transformations. Future work is focused on defining an improved method for mapping (in terms of data types, functionality, etc.) the concepts of different domains. We also consider important to complement feature models with other domain models to give a better description of the domain information.
References [ALPT04] Marcus Alanen, Johan Lilius, Ivan Porres, and Dragos Truscan. MDE support in a protocol processR ing design method. In proceedings of Model Driven Architecture : Foundations and Applications Workshop (MDAFA 2004), Linköping , Sweden, June 2004. [CE00] Krzysztof Czarnechi and Ulrich W. Eisenecker. Generative Programming – Methods, Tools and Applications. Addison-Wesley, 2000. + [KCH 90] Kyo C. Kang, Sholom G. Cohen, James A. Hess, William E. Novak, and A. Spencer Peterson. Feature Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21/ ESD90-TR-222, Carnegie Mellon University, 1990. [Par04] Juha Parsinen. Domain concepts for communication protocols. In Proceedings of 4th OOPSLA Workshop on Domain-Specific Modeling, Vancouver BC, Canada, October 2004. [RBSP02] Matthias Riebisch, Kai Böllert, Detlef Streitferdt, and Ilka Philippow. Extending feature diagrams with uml multiplicities. In proceedings of Integrated Design and Process Technology (IDTP-2002), 2002. [TFL04] Dragos Truscan, João Miguel Fernandes, and J. Lilius. Tool Support for DFD-UML Model-based Transformations. In Proceedings of the Intl. Conf. on the Engineering of Computer Based Systems (ECBS’04), Brno, Czech Rep., May 2004. [Tru04] Dragos Truscan. A UML profile for the TACO protocol processing platform. In proceedings of IEEE Norchip Conference (Norchip’04), Oslo, Norway, November 2004. [Vir04] Seppo Virtanen. A Framework for Rapid Design and Evaluation of Protocol Processors. PhD thesis, University of Turku, Sep 2004.
