[advanced information and knowledge processing] meta-programming and model-driven meta-program...

Chapter 3A Background of Meta-ProgrammingTechniques

3.1 Introduction

In Chap. 2, we discussed the fundamental concepts of programming and meta-programming. Knowing the meaning of the concepts through their definitions isimportant but not enough. It is just the first step to acquire knowledge in thefield. The aim of this chapter is to extend that knowledge and to reconsider somesoftware design principles as a background of meta-programming techniques. Here,by principles, we mean the known software construction principles as they are to beapplied to meta-programming domain. We refer to them as preliminary principles,when we discuss the way on how to start acquiring knowledge in the field. Werefer to them as fundamental principles, when we consider the background ofmeta-programming based on information hiding. We refer to the implementationtechniques or mechanism, when we consider the conceptual description of how someprinciples are realized in order to implement the meta-programming paradigm.

In our view, fundamental principles are based on some forms of informationhiding that allow describing the meta-programming paradigm without consideringof implementation mechanisms in detail. Those principles (aka forms of informationhiding) are separation of concepts and identification of their values (meanings),introduction of abstraction levels and identification of roles for each concept orits values at each level and integration of concepts through the use of somemechanisms and identification relationships among concepts and their values. Weuse the expression ‘fundamental principles’ here in the following sense: they areessential not only to the field of meta-programming but they are valid in many otherdisciplines, where they are used, perhaps, under different names.

However, there might be a variety of views, representations and mechanismsapplied to the use of principles. For example, in this chapter, we introduce ataxonomy axis for a visual representation of concepts and their values in orderwe could be able to identify some primary relationships. Another example is theintegration of meta-programming concepts. The integration relates to the meta-program development phase. Usually, this principle is realized through some

V. Stuikys and R. Damasevicius, Meta-Programming and Model-Driven Meta-ProgramDevelopment, Advanced Information and Knowledge Processing,DOI 10.1007/978-1-4471-4126-6 3, © Springer-Verlag London 2013

31

32 3 A Background of Meta-Programming Techniques

parameterization. However, there might be quite different schemes to realize theparameterization mechanism. As a consequence, there are multiple views, ideas andsuggestions that are exploited within the field called meta-programming. Our aim isto outline this field in some well-structured way.

In this context, we can summarize the importance of fundamental concepts ofmeta-programming by introducing preliminary principles that are described in thefollowing.

3.2 Preliminary Principles

These principles are about the understanding on how to start the learning route fromthe programming domain to its sub-domain called meta-programming. They canalso be seen as educational principles because they emphasize the role of termsand their relationships in knowledge acquisition. Actually, these principles are theconsequence of the discussion given in Chap. 2.

The first principle of acquiring knowledge in meta-programming is the knowing of basicconcepts of meta-programming and their definitions as a separate entity. If there are severalconcepts with the same or close meaning, it is selecting the only one which is best suited ina given context.

Though it is important (educologists say that terms may contribute 10–15 %of knowledge) but by no means is enough. Let us recall one definition of meta-programming provided earlier: ‘meta-programming is a manipulation on programas data’. Though it provides with the primary understanding of the topic, aknowledgeable reader may ask a lot of questions:

What is the manipulation?How it can be implemented?To which part of the program manipulations are to be applied: to data structures

only, or to the entire program?

The second principle follows from the investigation performed in Chap. 2. Asit was shown, the concepts are not independent entities. On the contrary, there aresome relationships among concepts. Relationships are expressed through taxonomy.As taxonomy extends our knowledge, we can formulate the following:

The second principle of acquiring knowledge in meta-programming is the knowing ofessential relationships among basic concepts of meta-programming.

However, it is an extremely difficult task to reveal the most essential relationshipsand to build as an exhaustive taxonomy as possible, if not to say more – in general, itis impossible to do that. In order to continue the discussion towards the formulationof other principles, we extend evaluation of the introduced taxonomy (see Table 2.2).This taxonomy was built on some initial assumptions and experiments, it was basedon our aim, the subjective view to the topic and on the extent of knowledge that wecan encompass, reveal and represent. Now one can ask the following questions:

3.3 Fundamental Principles of Meta-Programming 33

1. What are the basic concepts?2. Was there missed some important concepts in the taxonomy?3. What are the essential relationships in the field?

A simple answer to the first question might be as the one. Concepts have adifferent role or rank, and the latter depends on the context. For example, conceptssuch as ‘meta-program’ and ‘meta-language’ have a different rank because a meta-program is a very small subset of the given meta-language. What is common for bothconcepts is that they are ‘pure internal’ concepts of the field. The other term, suchas ‘separation of concept’, is not a pure internal concept of the meta-programmingfield. As it will be disclosed later, this concept has a much wider context of use. Theimportant observation as a primary assumption to support our analysis is that thereis some hierarchy in concept rank. The task of the analysis is to reveal and representthis hierarchy explicitly.

The other statement is an answer to the second question: some concepts eitherwere omitted in our taxonomy consciously, or they were interpreted in another way.The omitted concepts are not the internal terms of meta-programming, though theyallow a deeper understanding of the field. Examples are the concepts of ‘context’ and‘time’ (those terms were missed in analysis of concepts). For example, introducingsuch time dimensions as ‘meta-program construction time’ and ‘meta-programexecution time’ explicitly enables us to express some essential relationships betweenthe concepts. The time dimension should be understand here as a more precise andexplicit interpretation of the concept of ‘process’ discussed in Chap. 2 (see Table2.2). As ‘what are essential relationships?’ is not a simple question, a reader shouldseek for an answer reading the whole material of this chapter. We start the discussionwith fundamental principles below.

3.3 Fundamental Principles of Meta-Programming

Perhaps one might to say that there is the only one fundamental principle known inprogramming and in meta-programming as well. This principle is about ‘separationof concepts’. But we want to see some hierarchy of fundamental principles, in whichthe ‘separation of concepts’ is at the top and the others (such as the introduction of‘levels of abstraction’, ‘information hiding’ and ‘integration of concepts’ to describemeta-programming) are seen as derivatives from the top concept in the hierarchy.Thus, Sect. 3.3 describes the fundamental principles of meta-programming usingthis view.

3.3.1 Separation of Concepts

Indeed separation of concepts is a fundamental term. In computer science, forinstance, separation of concepts refers to the process of breaking a program into


distinct parts that overlap in functionality as little as possible (note that two termsconcepts and concerns are interchangeably used as synonymous in the literature).A concept is any piece or focus (sometimes also called aspect) in a program that isessential to a developer.

The term ‘separation of concepts’ has its roots in early works of Parnasand Dijkstra and relates to information hiding. However, the developers usedinformation hiding long before Parnas published his seminal work in 1972 [Par72],where he explicitly identified information hiding as a common aspect of goodsoftware development practice. Parnas provided the basis for information hiding,for reviewing software design and for applying the techniques to the variety ofmodules. Dijkstra applied the information hiding and separation techniques todescribe structural programming [Dij72].

Over the decades of software evolution, the separation of concepts has playeda significant role in devising new ideas, methods, approaches and methodolo-gies (e.g. FAST (Family-oriented Abstraction, Specification and Translation) andSCV (Scope-Commonality-Variability) methods [CHW98], generative program-ming [CE00], aspect-oriented programming [KLMC97], multidimensional separa-tion of concepts (MDSoC) [OT01], variability management [HHU08]), though indifferent fields it may be called differently. For example, in hardware design, theterms ‘orthogonalization of concepts’, ‘divide-and-conquer’, etc., are used.

In software engineering, the use of separation of concepts can be summarized asfollows: The concept refers to the establishment of logical boundaries to define anddelineate purpose typically expressed through concepts (also often called features).The concept is fundamental and we fully agree with the statement of Greer thatseparation of concepts is both ‘a principle and a process’ [Gre08]. According toGreer, the principle of separation of concepts might be stated as the premise thatthings (e.g. the meta-programming concepts in our case) should contain the essentialattributes and behaviours inherent to their nature, but should be void of attributes andbehaviours not inherent to their nature.

The previous discussion gives us a motivated background to formulate thefollowing statement.

Separation of concepts is a fundamental principle of programming and meta-programming enabling to understand those interrelated fields, as well as to drawa distinguishing line among those fields.

Separation of concepts is also a process used to describe mechanisms for imple-menting designs of programs and meta-programs.

In order to preserve the introduced style in enumerating principles of meta-programming, we summarize the statement as follows:

The third principle of acquiring knowledge in meta-programming is separation of concepts.In this context, separation of concepts has two meanings: (1) it is treated as a fundamentalprinciple per se, and (2) it is treated as a process of identifying the value (meaning) for aconcept of interest, as well as relationships among values of different concepts.


The intention of the foregoing discussion is to reveal the interpretation of‘separation of concepts’ in meta-programming in detail. But before doing so, firstwe introduce two important terms. As a principle and as a process, separation ofconcepts has two forms or kinds: implicit separation and explicit separation.

Implicit separation of concepts refers to the knowing of some concept of interest inan indirect way. This kind of separation is less powerful because the understandingof a given concept comes either from the context or through the introduction ofsome specific view to the concept under consideration (e.g. user’s view, designer’sview). The best example of implicit separation of concepts, perhaps, is the definitionof some programming concepts by default. In many programming languages, forinstance, the hiding of some declarations from the user (e.g. declarations of types,functions) can be seen as a default declaration or implicit separation of concepts.When there is a need for more expressiveness, one uses explicit separation ofconcepts.

Explicit separation of concepts refers to the explicit representation, statementand visualization of some concept of interest. What is done explicitly is morepowerful in the sense of expressivity and ability to understanding. If we look at aprogram or component from a structural point of view, one can see, for instance,an explicit separation of interface and functionality, explicit separation of datatypes in declarations (e.g. integer from float, Boolean from enumerated). In systemanalysis, it is a common practice to separate levels of abstractions. In programminglanguages, it is an appropriate action to separate computational constructs (e.g.assignments) from control constructs (e.g. loops, if-statements).

Explicit separation of concepts is especially useful in the case when an analyserhas to consider a variety of concepts at a time. Meta-programming is just the case.The question is as follows: in which way one can introduce and deal with meta-programming concepts explicitly? In our view, the taxonomy axes are helpful meansin considering the problem.

3.3.2 Taxonomy Axes to Describe Relationships BetweenConcepts

Taxonomy axis is a graphical representation of concepts in the one-dimensionalspace. For simplicity reasons, we assume that a concept under consideration has twovalues (meanings) in the space (see Fig. 3.1) only. For example, the concept ‘contextof use’ has the following meanings: ‘meta-programming field’ and ‘programmingfield’. The concept ‘time’ has the values ‘construction time’ and ‘execution time’(aka run time of a program or meta-program), and so on. What are benefits of usingthe taxonomy axis? Combining them, one can express relationships graphically, forexample, in the two-dimensional space as it is shown in Fig. 3.2.


Programming Meta-programming

Time

Execution time Construction time

Implicit separation Explicit separation

Separation ofconcepts (asprocess)

Lower-level(LL)

Language

Domain language Meta-language

Generalization

LL operations HL parameterization

Architecture

Body (Instance) Interface

Type of meta-programming

Homogeneous Heterogeneous

Meta-architecture

Meta-body Meta-interface

Transformation

Program Model

Context of use

Higher-level (HL)

Fig. 3.1 Taxonomy axes for specifying concepts and their values: an ideal case

What is a difficulty with this representation is that we cannot draw a discrim-inating line precisely. For example, there is no thin line to separate the ‘use ofprogramming’ and the ‘use of meta-programming’, or to separate ‘meta-language’from ‘domain language’ (note that instead of the term ‘domain language’, ‘targetlanguage’ and ‘object language’ are also used) because the same language can beconsidered in two roles simultaneously, for example, in case of homogeneous meta-programming (it will be discussed later in detail).

Figure 3.2 demonstrates more complex relationships among concepts in the two-dimensional space. Here, we focus on some structural relationships having in mindthat separation of concepts is used as a principle to define the intersection betweenconcepts ‘domain language’ (DL) and ‘meta-language’ (ML).

Considering Fig. 3.2, one can conclude that concepts ‘programming’ (PG)and ‘homogeneous meta-programming’ (Ho MPG) are deeply overlapping con-cepts because a single language, that is, a domain language, is used to supportthose paradigms. Homogeneous meta-programming can be viewed as a mode ofusing of a domain language, in which the focus is given at a larger extent toprogram manipulations rather than to data manipulations. From this perspective,


DL ML

Language

x

Separation ofconcepts

He

Ho

MPG

PG

B1 B0 B2

A2

A0

A1

Heterogeneous (He)Meta-programming(MPG) domain(rectangle betweenbidirectional lines)

Programming (PG) & Homog. (Ho)meta-programmingdomains (squareyA0B0x)

y

Contextof use axis

MPGaxis

Implicit Explicit

Fig. 3.2 Structural relationships between some concepts in two-dimensional space

heterogeneous meta-programming (He MPG) is seen as a paradigm, in which atleast two languages, that is, meta-language (ML) and domain language (DL), areused simultaneously. The model also outlines the boundaries (see a rectangularbetween lines B1, B2 and A1, A2 in Fig. 3.2), which indicate aspects that arethe source of various scientific discussions in the field (e.g. extensions of meta-programming paradigm).

3.3.3 Levels of Abstractions and Meta-Programming

We also can consider the principle of ‘separation of concepts’ from the otherperspective giving the insight into such an aspect as ‘boundary’ of using theprinciple. Dealing with the Greer’s definition of ‘separation of concepts’ stating thatit ‘refers to the establishment of logical boundaries to define and delineate purpose’,one can ask: in which way those boundaries might be established? The answer tothe question is that boundaries can be identified by introducing levels of abstractionin dealing with the problem as it was already done implicitly (see Fig. 3.2).

For simplicity reasons and aims of this chapter, it is enough to have two levels ofabstractions: higher or (meta-) level and lower level. But in another context, say forgeneralization purposes, by no means, two levels of abstraction are not sufficient asit will be discussed in Chaps. 11 and 14.

On the other hand, the ‘levels of abstraction’ relate to some specific roles ofa given concept. Take, for example, the concepts of ‘meta-language’ and ‘domainlanguage’ in the context of meta-programming or in the context of multi-linguisticspecifications. One can ask: what is the role of those languages in the boundaries


of meta- and domain languages? A simplified answer is as follows: the role of anML is to express manipulations applied to a domain program or its fragments. Andthe role of a DL is to express the functionality of a domain program written in thedomain language.

The provided examples and statements should convince the reader that thelevels of abstractions and roles of concepts are associated with each other. Thisrelationship is formulated as the next principle:

The fourth principle of acquiring knowledge in meta-programming is the introduction ofthe levels of abstraction as boundaries to deal with separation of concepts along with theidentification of roles for concepts of interest (e.g. a role of a language, a role of a meta-interface in a meta-program).

3.3.4 Integration of Concepts

In the development process of a system or program (meta-program), it is not enoughto use the ‘pure’ principle of ‘separation of concepts’, since this principle describesthe aspects of analysis and decomposition only. In each stage of the process,some ‘intermediate form’ of the design should be created until the entire designis completed. What a designer is doing in creating this ‘intermediate form’ ofthe design? He or she first uses ‘separation of concepts’, and then he (she) uses‘integration of concepts’ in order to synthesize the intermediate or the final result.Thus, ‘separation of concepts’ and ‘integration of concepts’ are different sides of thesame coin. More generally, analysis and synthesis appears together in any systemdesigns.

In any case, either system or meta-program designs, a mechanism should beidentified which indicates the way to achieve the integration. In computer science ata very abstract level, such an integration of concepts can be seen as a generalization.How to achieve generalization through integration of concepts when constructingmeta-programs? The answer is the higher-level parameterization as a tool toimplement generalization or integration in meta-program design (see generalizationaxis in Fig. 3.1).

Now, we can formulate the next principle of meta-programming.

The fifth principle of acquiring knowledge in meta-programming is the integration of theprior separated concepts through the introduction of high-level parameterization enablingto connect concepts of higher and lower levels in some well-established process within themeta-program specification.

Below, we provide an example explaining in detail how does the higher-levelparameterization work.

Let us consider the following task. A user needs to develop a meta-programthat generates a set of domain programs, each describing similar models, such ashomogeneous logical equations. Equations differ in a logic operation used (e.g.‘and’, ‘or’) and in the length of expression (i.e. in number of arguments in anequation).

3.4 Process-Based Relationships of Meta-Programming Concepts 39

A concrete homogeneous logic equation, that is, an instance of the equationgenerated by a meta-program, which we need to develop, may look like thefollowing:

Y D X1 and X2 and X3 (3.1)

Equation (3.1) is also a domain program or a component because it describesinterface (e.g. its input arguments are X1, X2 and X3 and output is Y) andfunctionality explicitly in the form of the functional relationship.

Equation (3.1) represents the domain level, that is, the lower level. In order tosatisfy requirements of the task, two high-level parameters are needed (one forselecting a logic operation and another for selecting the length of an equation).It is clear that the specification of change should be done at the higher level.The specification through the introduction of parameterization, for example, usingparameters p1 and p2, can be written like the following:

p1 WD< a value from the set S1 >; where S1 D fand; org (3.2)

p2 WD< a value from the set S2 >; where S2 D f2; 3; 4; 5; 6g (3.3)

As there are no constraints in using values of the identified sets S1 and S2, allpossible combination of parameter values can appear, which, when implemented,may yield ten different equations.

To be useful, the parameterization mechanism, of course, needs an extra support.At this level, a reader should be aware that a meta-language has to ensure this sup-port. As linguistic aspects are central in both programming and meta-programming,in order to acquire insight knowledge in homogeneous and heterogeneous meta-programming, a reader needs to study materials in Chaps. 4, 5 and 6.

What should be yet learned in this chapter for the conceptual understanding of thefield are two topics: (1) further extension of relationships between concepts in two-dimensional space using taxonomy axes and (2) introduction of the basic knowledgerequired for the understanding of multidimensional separation of concepts (MD-SoC) in the context of meta-programming.

The next section considers the first topic.

3.4 Process-Based Relationships of Meta-ProgrammingConcepts

The aim is to summarize a conceptual understanding of meta-programming conceptsproviding analysis of other relationships among concepts. The basis for analysisis the taxonomy axes (see Fig. 3.1) and the framework introduced in Table 2.2.First, we need to reorder taxonomy axes according to structural (e.g. language, types


DL ML

Implicit/ execution Explicit/ construction

x, Generalization/transformation

Separation ofconcepts/ time

MPG, y

(Meta-)Architecture

He

Ho

B1 B0 B2

A2

A0

A1

Heterogeneous (He)Meta-specifications(meta-programs) (rectangle betweenbidirectional lines)

Homogeneous (Ho) meta-specifications (meta-programs) domains (square yA0B0x)

Space of instances

MI+ MB

I + B

Fig. 3.3 Process-based relationships between some concepts in two-dimensional space

Fig. 3.4 An example of meta-specification to explain process-based model

of meta-programming, architecture and meta-architecture) and process-based views(time, separation of concepts, generalization and transformation).

The process-based view to the meta-programming concepts is about the devel-opment of meta-specifications or meta-programs without dealing with the detailsof the development. Again, we express the view using the model, which is similarto that presented in Sect. 3.3. Figure 3.3 presents the model which describes theprocess-based view. The model should be considered with the meta-specificationexample (Fig. 3.4).

In what aspects the previous analysis described in Sects. 3.3 and 3.4 have hadto convince reader, there might be at least two things. The first is that the meta-programming field encompasses concepts of programming and introduces the newones that are relevant to meta-programming only. The second is that, in the contextof applying the principle of ‘separation of concepts’, concepts interact or overlap

3.5 Multidimensional Separation of Concepts and Meta-Programming 41

(intersect) between themselves and this interaction was expressed through variousrelationships. In what a more knowledgeable reader might be less convinced is thefollowing: is it enough to analyse the relationships in two-dimensional space?

In the next section, we try to fulfil the gap introducing the concept ‘multidimen-sional separation of concepts’ and applying it for further analysis and conceptualunderstanding of meta-programming.

3.5 Multidimensional Separation of Conceptsand Meta-Programming

Ossher and Tarr and their colleagues from IBM Inc. have introduced the newapproach to separation of concepts, which is known in the literature on softwareengineering as ‘multidimensional separation of concepts’ (MDSoC) [OT01]. (Notethat authors use the term ‘concern’ in the original paper). The approach supportsconstruction, evolution and integration of software. Its goals are to enable thefollowing activities:

• Encapsulation of all kinds of concepts in a software system simultaneously• Considering of overlapping and interacting concepts• Considering on-demand re-modularization

Concepts are the primary motivation for organizing and decomposing softwareinto manageable and comprehensible parts. Many kinds of concepts may be relevantto different developers in different roles, or at different stages of the software lifecy-cle. For example, the prevalent concept in object-oriented programming is the class,which encapsulates data concepts. Feature concepts, like printing, persistence anddisplay capabilities, are also common, as are concepts like aspects, roles, variantsand configurations. Appropriate separation of concepts has been hypothesized toreduce software complexity and improve comprehensibility; promote traceability;facilitate reuse, noninvasive adaptation, customization and evolution; and simplifycomponent integration [OT01].

MDSoC is based on the idea that design concepts should be first representedindependently. A designer develops domain programs by composing the separatedconcepts according to systematic rules. A simultaneous encapsulation of conceptscan be understood in terms of an n-dimensional design space, called a hyperspace.Each dimension is associated with a set of similar concepts, such as a set ofcomponent instances; different values along a dimension are different instances.A hyperslice is a set of instances that pertain to a specific concept. A hypermoduleis a set of hyperslices and integration relationships that dictate how the units ofhyperslices are integrated into a program. MDSoC is especially useful where a greatvariety of requirements exist at different levels of abstraction such as in embeddedsystem (ES) design.


According to the authors of the approach, these goals, while laudable, have notyet been achieved in practice. But authors believe that this is because the set ofrelevant concepts varies over time and is context-sensitive: different developmentactivities, stages of the software lifecycle, developers and roles often involveconcepts of dramatically different kinds. Thus, any criterion for decomposition willbe appropriate for some contexts, but not for all. Further, multiple kinds of conceptsmay be relevant simultaneously, and they may overlap and interact, as features andclasses do.

Summarizing the benefits of the approach, we can conclude that the term MDSoCrefers to flexible and incremental separation, modularization and integration of soft-ware artefacts based on any number of concepts. It overcomes limitations of existingmechanisms by permitting clean separation of multiple, potentially overlapping andinteracting concepts simultaneously, with support for on-demand re-modularizationto encapsulate new concepts at any time. Realizations of MDSoC can permitincremental identification and encapsulation of concepts, without requiring the useof new languages or formalisms.

How is the above described motivation similar to the one, which was given inthe Introduction (see Sect. 1.4) to motivate the need of meta-programming? It is themain reason why we consider MDSoC as a general analysis method and apply it inthe context of insights to understanding of meta-programming here.

Now, we try to outline some correspondence between concepts used for describ-ing meta-programming and those concepts used within the MDSoC approach. Fromthe first glance, such terms as ‘overlapping concepts’, ‘interacting concepts’ mightbe seen to much abstract to understand their actual meaning if there are no examples.First, let us return to the process-based relationship model (see Fig. 3.3). Here theoverlapping and interacting concepts are represented abstractly by the square whichis formed between vertical lines B1, B2 and horizontal lines A1, A2. The followingconcepts are represented explicitly: DL and ML, Ho MPG (Homogeneous meta-programming) and He MPG (heterogeneous meta-programming), architecture ofmeta-specification and architecture of program (component) specification. Note thatarchitecture of meta-specification in Fig. 3.3 is denoted by MI C MB, where MImeans a meta-interface and MB means a meta-body. Architecture of a program(component) specification is denoted by I C B (where I – interface, B – body).

Next, let us look at the concrete (though very simplified) example of the meta-specification presented in Fig. 3.4. In terms of MDSoC, the specification is thesimultaneous encapsulation of all (or nearly all) concepts of meta-programming thatwere considered in Chaps. 2 and 3. In terms of our analysis, the specification is thesimultaneous integration of prior separated meta-programming concepts accordingto the ones formulated in previous sections. How the interaction or overlapping ofconcepts is seen in this specification? In order to comprehend these terms, perhaps,the best way is to perform (e.g. in ad hoc manner) a structural and semantic analysisof the description. For example, the interaction between terms ‘meta-architecture’and ‘meta-language’ is expressed through parameters p1 and p2 explicitly andthrough transferring parameter values from the meta-interface to the meta-bodyimplicitly, that is, through the environment (meta-language processor). Using theintroduced guideline, one can easily identify other types of interaction.

3.6 Representation of Meta-Programming Concepts Using Feature Diagrams. . . 43

The concepts ‘hyperslicing’ and ‘re-modularization on demand’, which wasdescribed above as a part of MDSoC goals, in our analysis should be understoodas follows. In our context, for instance, in the development process, the concept of‘hyperslicing’ means the identification/specification of structural units (e.g. meta-interface, meta-body) within either the monolithic meta-specification (see Fig. 3.3)or the hierarchical meta-specification which consists of meta-modules (see, e.g.[SD00]).

In our case, the concepts of ‘re-modularization on demand’ mean a separation ofa concrete instance from the whole specification. Such an interpretation is appropri-ate because a meta-specification is a set of domain program instances (e.g. specificequations in Fig. 3.4) that are weaved in a specific way (e.g. using informationhiding and meta-programming principles). The separation of an instance from itsmeta-specification is performed, first, through parameterization and, then, throughtransformation/generation process within the given environment.

We summarize the discussion on meta-programming principles with the de-scription of yet another way to represent relationships and interactions betweenthe concepts of interest. We found Feature Diagrams [KCHC90] to be a usefulinstrument for this purpose because the meaning of the terms ‘feature’ and ‘concept’overlaps.

3.6 Representation of Meta-Programming ConceptsUsing Feature Diagrams: MDSoC View

Kang et al. define feature as an ‘end-user visible characteristic of a system or a keycharacteristic of a concept that is relevant to some stakeholder’ [KCHC90] (seealso [SDBC08]). The intention of the concept is to represent a family of similardomain entities in some well-established way in order to be able to model a domainthrough the relationships of feature variants.

Feature modelling is the activity of modelling common and variable properties ofconcepts and their dependencies and organizing them into a coherent model referredto as a feature model. The model delivers the intention of a concept, whereas the setof instances it describes is referred to as an extension, which narrows the meaningand scope of the concept.

In software engineering, the terms of ‘feature’ and ‘feature-based modelling’are widely exploited in the context of the product line approach. It is not ourintention to discuss the details of the approach here. We refer a reader to the Part II,where our main aim is to consider the issues of meta-program specification throughmeta-modelling. In this section, we extend the understanding of meta-programmingthrough the abstract and semi-formal representing principles and concepts of thefield of interest. First we introduce some definitions.

There are three main types of features: mandatory, optional and alternative.Mandatory features allow expressing commonality of the concept, whereas optional


ML1

DL

MLn

MPG Concepts &principles

MD Separation ofConcerns

Applications

Architecture (A)

Generation

PG

Process-basedview

Structural view

Paradigm aspects

Ho MPG

He MPG

Meta-A

Explicit

Linguistic aspects

TransformationML

Architectural aspects

Concerns Integration

Implicit

DLm

I

BMB

MI

DL1

Information hiding

Abstraction levels

Construction time

Execution time

Model/Family

Parameterization

MPGInstance

MPG Taxonomies

Generalization

Multi-dimensional concerns relationships

Fig. 3.5 Feature-based model to represent meta-programming domain abstractly

and alternative features allow expressing variability. Features may appear either asa solitary feature or in groups. If all mandatory features in the group are derivatesfrom the same father in the parent-child relationship, there is the and relationshipamong those features. An optional feature is the one which may be included ornot if its father is included in the model. Alternative features, when they appear ingroups as derivates from the same father, may have the following relationships: or,xor (filled arc in Fig. 3.5), case (arc in Fig. 3.5), etc. The xor relationship also canbe treated as a constraint. Usually, a constraint appears when features are derivedfrom different parents. For more advanced subtypes of alternative features as ‘viewson ontologies’, see [CKK06].

A Feature Diagram (FD) is a graphical notation for feature models representedas a treelike or directed acyclic graph. The root represents the top-level feature (i.e.concept, system or domain per se). The intermediate nodes represent compoundfeatures and leaves represent atomic features that are non-decomposable to smallerones in a given context. Mandatory features are denoted as boxes with black circles,and alternative (optional) features are represented as boxes with white circles (seeFig. 3.5). The edges are used to progressively decompose a compound feature intomore detailed features. Edges of the graph also denote relationships between feature

3.7 Summary and Evaluation 45

nodes as it is depicted in Fig. 3.5. There are two types of relationships: ‘parent-child’relationships and relationships between terminal nodes. The latter are representedas bidirectional dotted lines. Those relationships are treated as multidimensionalinteraction of concepts.

3.7 Summary and Evaluation

This chapter provides a more deep study of the meta-programming field incomparison to that what was initiated in Chap. 2 by extending the taxonomy-basedunderstanding of meta-programming concepts towards a more precise interpretationand representation of relationships among the concepts.

The basic result of the study is the formulation of some principles for acquiringa systematic knowledge in the field. The preliminary principles are a summary ofthe taxonomy-based analysis. The core for formulating of fundamental principles ofmeta-programming is information hiding, which is known in computer science dueto early works of Dijkstra and Parnas.

In our context, we consider information hiding as a general framework fromwhich we derive five principles for acquiring the knowledge in meta-programmingas follows:

1. Introduction of abstraction levels and identification of roles and values forconcepts of interest at each abstraction level

2. Separation of concepts as a principle of high-level analysis3. Integration of the prior separated concepts to support development processes at

the conceptual level4. Introduction of the levels of abstraction as boundaries to deal with separation of

concepts5. Integration of the prior separated concepts through the introduction of high-level

parameterization

Our contribution is:

1. Systematization of the known principles to better understand the field underconsideration

2. Application of formulated principles through the introduction of two levels ofabstractions and only two values for concepts and graphical representation ofconcepts using taxonomy axes

3. Use of multidimensional separation of concepts as an instrument for disclosingmore subtle relationships among meta-programming concepts

4. Graphical representation of the basic meta-programming concepts and theirinteraction using Feature Diagrams

The presented analysis is by no means exhaustive and complete because (1) it isimpossible to explain subtleties of meta-programming without introducing linguisticaspects explicitly and (2) our intention was to convey only a more general and


fundamental knowledge in some simplified manner. Thus, the presented analysisis rather the indication of the direction one may follow when performing furtherstudies in the field.

3.8 Exercise Questions

3.1. Repeat the basic definitions of meta-programming as the first principle ofacquiring knowledge in the field to solve the problem of synonymy in usingclosely related terms.

3.2. How to draw essential relationships among basic concepts of meta-programming (the second principle of acquiring knowledge in the field)?

3.3. What is separation of concepts in programming and meta-programming?Interpret two meanings of separation of concepts in meta-programming: (a) asa fundamental principle per se and (b) as a process of identifying the value(meaning) for a concept of interest, as well as relationships among values ofconcepts.

3.4. In which way taxonomy axes extend the taxonomy per se?3.5. What is the role of abstraction levels in the meta-programming paradigm? Why

levels of abstraction are treated as boundaries to deal with separation of meta-programming concepts (the 4th principle of acquiring knowledge in the field)?

3.6. What is the integration of previously separated concepts? What mechanism isused to implement the integration (the fifth principle of acquiring knowledgein the field)?

3.7. Define and learn the difference between the pairs of terms: homogeneous meta-programming and heterogeneous meta-programming; separation of conceptsand multidimensional separation of concepts.

3.8. Compare and evaluate three means of representing knowledge in meta-programming: (a) taxonomy (given in Table 2.2), (b) taxonomy axis (Figs. 3.1,3.2 and 3.3) and (c) feature-based representation (Fig. 3.5).

References

[CE00] Czarnecki K, Eisenecker UW (2000) Separating the configuration aspect to supportarchitecture evolution. In: Proceedings of 14th European conference on object-oriented programming (ECOOP’2000), international workshop on aspects anddimensions of concerns, Cannes, France, 11–12 June 2000

[CHW98] Coplien J, Hoffman D, Weiss D (1998) Commonality and variability in softwareengineering. IEEE Softw 15:37–45

[CKK06] Czarnecki K, Kim CHP, Kalleberg KT (2006) Feature models are views on ontolo-gies. In: Proceedings of the 10th international software product line conference,Baltimore, 2006, pp 41–51

[Dij72] Dijkstra EW (1972) Notes on structured programming. In: Dahl OJ, Dijkstra EW,Hoare CAR (eds) Structured programming. Academic, London

References 47

[Gre08] Greer D (2008) The art of separation of concerns. http://ctrl-shift-b.blogspot.com/2008/01/art-of-separation-of-concerns.html

[HHU08] Hubaux A, Heymans P, Unphon H (2008) Separating variability concerns in aproduct line re-engineering project. In: EA-AOSD’08, Brussels, Belgium, 31 Mar2008

[KCH+90] Kang K, Cohen S, Hess J, Novak W, Peterson S (1990) Feature-oriented domainanalysis (FODA) fessibility study. In: TR CMU/SEI-90-TR-21, Software Engineer-ing Institute, Carnegie Mellon University, Nov 1990

[KLM+97] Kiczales G, Lamping J, Mendhekar A, Maeda C, Videira Lopes C, Loingtier J-M, Irwin J (1997) Aspect-oriented programming. In: Proceedings of the Europeanconference on object-oriented programming (ECOOP’1997). LNCS, vol 1241.Springer, Berlin, pp 220–242

[OT01] Ossher H, Tarr P (2001) Multi-dimensional separation of concerns and the hyper-space approach. In: Aksit M (ed) Software architectures and component technology:the state of the art in software development. Kluwer Academic Publishers, Boston

[Par72] Parnas DL (1972) On the criteria to be used in decomposing a system into modules.Commun ACM 15(12):1053–1058

[SD00]ˇ Stuikys V, Damasevicius R (2000) Scripting language open PROMOL and itsprocessor. Informatica 11(1):71–86

[SDB+08]ˇ Stuikys V, Damasevicius R, Brauklyte I, Limanauskiene V (2008) Explorationof learning object ontologies using feature diagrams.In: Proceedings of worldconference on educational multimedia, hypermedia & telecommunications (ED-MEDIA 08), June 30–July 4 2008, Vienna, Austria, pp 2144–2154

http://ctrl-shift-b.blogspot.com/2008/01/art-of-separation-of-concerns.html

http://ctrl-shift-b.blogspot.com/2008/01/art-of-separation-of-concerns.html

[advanced information and knowledge processing] meta-programming and model-driven meta-program...

Documents