An Attribute Grammar Specification ofIIS*Case PIM Concepts

Ivan Luković1, Maria João Varanda Pereira2, Nuno Oliveira3,Daniela da Cruz3, Pedro Rangel Henriques3

1 University of Novi Sad, Faculty of Technical Sciences,Trg D. Obradovića 6, 21000 Novi Sad, Serbia,

ivan@uns.ac.rs2 Politechnique Institute of Bragança, Escola Superior de Tecnologia e

Gestão, Campus de Santa Apolónia - Apartado 11345301-857 Bragança, Portugal

mjoao@ipb.pt3 Universisty of Minho, Department of Computer Science,

Campus de Gualtar - 4710-057 Braga, Portugal{nunooliveira,danieladacruz,prh}@di.uminho.pt

Abstract. IIS*Case is a model driven software tool that provides informationsystem modeling and prototype generation. It comprises visual and repositorybased tools for creating various platform independent model (PIM)specifications that are latter transformed into the other, platform specificspecifications, and finally to executable programs. Apart from having PIMsstored as repository definitions, we need to have their equivalent representationin the form of a domain specific language. One of the main reasons for this is toallow for checking the formal correctness of PIMs being created. In the paper,we present such a meta-language, named IIS*CDesLang. IIS*CDesLang isspecified by an attribute grammar (AG), created under a visual programmingenvironment for AG specifications, named VisualLISA.

Keywords: Information System Modeling; Model-Driven Approaches; DomainSpecific Languages; Domain Specific Modeling; Attribute Grammars

1 Introduction

In this paper we present a textual language aimed at modeling platform independentmodel (PIM) specifications of an information system (IS). Our research goals are tocreate such a language and couple it with Integrated Information Systems CASE Tool(IIS*Case). IIS*Case is a model driven software tool that provides IS modeling andprototype generation. At the level of PIM specifications, IIS*Case providesconceptual modeling of database schemas and business applications. Starting fromsuch PIM models as a source, a chain of model-to-model and model-to-codetransformations is performed in IIS*Case so as to obtain executable program code ofsoftware applications and database scripts for a selected target platform. One of themain motives for developing IIS*Case is in the following. For many years, the most

An Attribute Grammar Specification of IIS*Case PIM Concepts 111

favorable conceptual data model is Entity-Relationship (ER) data model. A typicalscenario of a database schema design process provided by majority of existing CASEtools is to create an ER database schema first and then transform it into the relationaldatabase schema. Such a scenario has many advantages, but also there are seriousdisadvantages [5]. We overcome them by creating an alternative approach and relatedtechniques that are mainly based on the usage of model driven software development(MDSD) and Domain Specific Language (DSL) paradigms. The main idea was toprovide the necessary PIM meta-level concepts to IS designers, so that they can easilymodel semantics in an application domain. After that, they may utilize a number offormal methods and complex algorithms to produce database schema specificationsand IS executable code, without any expert knowledge.

In order to provide design of various PIM models by IIS*Case, we created anumber of modeling, meta-level concepts and formal rules that are used in the designprocess. Besides, we also developed and embedded into IIS*Case visual andrepository based tools that apply such concepts and rules. They assist designers increating formally valid models and their storing as repository definitions in a guidedway.

Apart from having created PIM models stored as repository definitions, there is astrong need to have their equivalent representation given in a form of a textuallanguage, for the following reasons. (i) Firstly, despite that we may expect thataverage users prefer to use visually oriented tools for creating PIM specifications, weshould provide more experienced users with a textual language and a tool for creatingPIM specifications more efficiently. (ii) Secondly, we need to have PIM meta-levelconcepts specified formally in a platform independent way, i.e. to be fullyindependent of repository based specifications that typically may include someimplementation details. (iii) The third, but not less important, by this we create a basisfor the development of various algorithms for checking the formal correctness of themodels being created, as well as for the implementation of some semantic analysis.Therefore, we need a grammar specification of our meta-level concepts and rules. Bysuch a grammar, we specify a DSL [3, 9] that recognizes problem domain conceptsand rules that are applied in the conceptual IS design provided by IIS*Case. In thepaper, we present a specification of such meta-language, named IIS*CDesLang.IIS*CDesLang is used to create PIM project specifications that may be lattertransformed into the other specifications, and finally to programs.

There are a number of meta-modeling approaches and tools suitable for thepurpose of creating IIS*CDesLang, as well as many other applications in variousproblem domains like it is, for example, [16]. One of them is the Meta-Object Facility[18] proposed by the OMG, where the meta-model is created by means of UML classdiagrams and Object Constraint Language (OCL). The Generic ModelingEnvironment (GME) [19] is a configurable toolkit for domain-specific modeling andprogram synthesis. In MetaEdit+ [20] models are created through a graphical editorand a proprietary Report Definition Language is used to create code from models. TheEclipse Modeling framework (EMF) [21] is also a commonly used meta-modelingframework, where meta-meta-model named Ecore is used to create meta-models, or toimport them from UML tools or textual notations like one presented in [17].

To create IIS*CDesLang, a visual programming environment (VPE) for attributegrammar specifications, named VisualLISA [11, 13] is selected. In the paper, we

112 I. Luković, M. J. V. Pereira, N. Oliveira, D. da Cruz, and P. R. Henriques

focus on the following application PIM concepts: project, application system, formtype, component type, application, call type, and basilar concepts as attribute anddomain. We applied VisualLISA Syntactic and Semantic Validators to check thecorrectness of the specified grammar.

A benefit of introducing IIS*CDesLang is to use VisualLISA attribute grammar(AG) specifications and generate a parser aimed at checking the formal correctness ofcreated project models. In this way, we may help designers in raising the quality ofcreated IS specifications. Currently, we developed an AG specification ofIIS*CDesLang. The main goal of this paper is to present a part of such specificationand address main future research directions. Apart from having the AG specificationof IIS*CDesLang, we also need the appropriate design and syntax checker tools. Theyare still under development. Therefore, we were not able so far to test the efficiencyof the concept as a whole. It remains to be one of our next research tasks.

Apart from Introduction and Conclusion, the paper is organized in four sections. InSection 2, we give a short presentation of IIS*Case. Preliminaries about VisualLISAprogramming environment are given in Section 3. Selected IIS*CDesLang PIMconcepts are briefly described in Section 4. In Section 5 we present an attributegrammar specification of IIS*CDesLang, created by VisualLISA.

2 IIS*Case and Conceptual Modeling

IIS*Case, as a software tool assisting in IS design and generating executableapplication prototypes, currently provides: Conceptual modeling of database schemas, transaction programs, and business

applications of an IS; Automated design of relational database subschemas in the 3rd normal form

(3NF); Automated integration of subschemas into a unified database schema in the 3NF; Automated generation of SQL/DDL code for various database management

systems (DBMSs); Conceptual design of common user-interface (UI) models; and Automated generation of executable prototypes of business applications.

Apart from the tool, we also define a methodological approach to the application ofIIS*Case in the software development process [6, 8]. By this approach, the softwaredevelopment process provided by IIS*Case is, in general, evolutive and incremental.It enables an efficient and continuous development of a software system, as well as anearly delivery of software prototypes that can be easily upgraded or amendedaccording to the new or changed users' requirements. In our approach we strictlydifferentiate between the specification of a system and its implementation on aparticular platform. Therefore, modeling is performed at the high abstraction level,because a designer creates an IS model without specifying any implementationdetails. Besides, IIS*Case provides some model-to-model transformations from PIMto Platform-Specific Models (PSM) and model-to-code transformations from PSMs tothe executable program code.

An Attribute Grammar Specification of IIS*Case PIM Concepts 113

Detailed information about IIS*Case may be found in several authors' referencesand we do not intend to repeat them here. A case study illustrating main features ofIIS*Case and the methodological aspects of its usage is given in [6]. Themethodological approach to the application of IIS*Case is presented in more details in[8]. At the abstraction level of PIMs, IIS*Case provides conceptual modeling ofdatabase schemas that include specifications of various database constraints, such asdomain, not null, key and unique constraints, as well as various kinds of inclusiondependencies. Such a model is automatically transformed into a model of relationaldatabase schema, which is still technology independent specification. It is an exampleof model-to-model transformations provided by IIS*Case. [7]

In [1] we present basic features of SQL Generator that are already implemented intoIIS*Case, and aspects of its application. We also present methods for implementation ofa selected database constraint, using mechanisms provided by a relational DBMS. It isan example of model-to-code transformations provided by IIS*Case.

At the abstraction level of PIMs, IIS*Case also provides conceptual modeling ofbusiness applications that include specifications of: (i) UI, (ii) structures oftransaction programs aimed to execute over a database, and (iii) basic applicationfunctionality that includes the following "standard" operations: data retrieval, inserts,updates, and deletes. Also, a PIM model of business applications is automaticallytransformed into the program code. In this way, fully executable applicationprototypes are generated. Such a generator is also an example of model-to-codetransformations provided by IIS*Case and its development is almost finished. [2]

3 Designing DSLs using VisualLISA

As it follows from the definition of AGs [15] they are not as easy to specify as peoplewould desire because there is a gap between the language description and thegrammar meta-language that must be interpreted. The user must take care aboutchoosing the appropriate attributes and their evaluation rules. Since the beginning, theliterature concerned with the formal approach to compiler development presents AGsdrawing syntax trees decorated with attributes. So it is usual to sketch up on paperattributed trees with semantic rules to describe an AG, avoiding spending time withsyntactic details. However, such informal drawings must be translated manually (bylanguage experts) into the specific input notation of a compiler generator. Thisinconvenience discourages language designers to use AGs. Such an attitude preventsthem of resorting to systematic ways to implement the languages and their supportingtools [10].

For modeling the new DSL we use here a Visual Language (VL) and its respectiveprogramming environment (VPE) called VisualLISA, as it is proposed in [11], andconceived in [13]. The idea of introducing VL is not only about having a nice visualdepiction that will be translated into a target notation latter on, but also having apossibility of checking syntactic and semantic consistency.

VisualLISA environment offers a visually oriented and non-errorprone way for AGmodeling and an easy translation of AG models into a target language. Three mainfeatures of VisualLISA are: (i) syntax validation, (ii) semantics verification and (iii)

114 I. Luković, M. J. V. Pereira, N. Oliveira, D. da Cruz, and P. R. Henriques

code generation. The syntax validation restricts some spatial combinations among theicons of the language. In order to avoid syntactic mistakes, the model edition issyntax-directed. The semantics verification copes with the static and dynamicsemantics of the attribute grammar meta-language. Finally, the code generationproduces code from the drawings sketched up. The target code would be LISAspecification language (LISAsl) - the meta-language for AG description under LISAgenerator - or XAGra specification [13]. LISAsl specification is passed to the LISAsystem [4, 14] in a straightforward step. XAGra [12] textual language was conceivedwith the aim of giving to VisualLISA development environment more versatility andfurther usage perspectives.

In our case, we are specifying IIS*CDesLang, a new DSL for IIS*Case tool, usingVisualLISA; the target code will be LISAsl in order to implement IIS*CDesLanginterpreter in LISA system. This specification is further detailed in Section 5.

4 PIM Concepts and IIS*CDesLang

IIS*CDesLang is a meta-language aimed at formal specification of all the conceptsembedded into IIS*Case repository definitions. In this paper, we focus on the PIMconcepts only. Hereby, we give a brief overview of the following concepts covered byIIS*CDesLang: project, application system, form type, component type, application,call type, as well as fundamental concepts: attribute and domain. In this section wepresent the PIM concepts only from the technical point of view. Additional anddetailed information may be found in several authors' references, as well as in [6, 8].

A work in IIS*Case is organized through projects. Everything that exists in theIIS*Case repository is always stored in the context of a project. A designer may createas many projects as he or she likes. One project is one IS specification and has astructure represented by the project tree. Each project has its (i) name, (ii)fundamental concepts or fundamentals for short, and (iii) application systems. Adesigner may also define various types of application systems – application types forshort, and introduce a classification of application systems by associating eachapplication system to a selected application type. At the level of a project there is apossibility to generate various reports that present the current state of the IIS*Caserepository. IIS*Case provides various types of repository reports.

Application systems are organizational parts, i.e. segments of a project. Wesuppose that each application system is designed by one, or possibly more than onedesigner. Fundamental concepts are formally independent of any application system.They are created at the level of a project and may be used in various applicationsystems latter on. Fundamental concepts are: domains, attributes, inclusiondependencies and program units. In the paper, we focus on domains, attributes, andfunctions as a category of program units.

In the following text, we use a notion of domain with a meaning that is common inthe area of databases. It denotes a specification of allowed values of some databaseattributes. We classify domains as (i) primitive and (ii) user defined. Primitivedomains exist "per se", like primitive data types in various formal languages. We havea small set of primitive domains already defined, but we allow a designer to create his

An Attribute Grammar Specification of IIS*Case PIM Concepts 115

or her own primitive domains, according to the project needs. User defined domainsare created by referencing primitive or previously created user defined domains.Domains are referenced latter from attribute specifications. A list of all projectattributes created in IIS*Case belongs to fundamentals. Attributes are used in variousform type specifications of an application system.

A concept of a function is used to specify any complex functionality that may beused in other project specifications. Each function has its name as a unique identifier,a description, a list of formal parameters and a return value type. Besides, itencompasses a formal specification of function body that is created by the FunctionEditor tool of IIS*Case.

4.1 Domains and Attributes

A specification of a primitive domain includes: name, description, default value, and a"length required" item specifying if a numeric length: a) not to be, b) may be or c)must be given. User defined domains are to be associated with attributes. A userdefined domain specification includes: a domain name, description (like all otherobjects in IIS*Case repository), default value, domain type, and check condition.

We distinguish the following domain types: (i) domains created by the inheritancerule and (ii) complex domains that may be created by the: a) tuple rule, b) choice ruleor c) set rule. Inheritance rule means that a domain is created by inheriting aspecification of a primitive domain or a previously defined user defined domain. Itinherits all the rules of a superordinated domain and may be "stronger" than theoriginal one.

A domain created by the tuple rule is called a tuple domain. It represents a tuple(record) of values. For such a complex domain, we need to select some attributes asitems of a tuple domain. Therefore, we may have a recursive usage of attributes anddomains, because we need some already created attributes to use in a tuple domainspecification. A domain created by the choice rule – choice domain is technicallyspecified in the same way as tuple domain. Choice domain is the same as choice typeof XML Schema Language. Each value of such a domain must correspond to exactlyone attribute which is an item in the choice domain. A set domain represents sets(collections) of values over a selected domain. To create it, we only need to referencean existing domain as a set member domain. Each value of this domain will be a setof values, each of them from a set member domain.

Check condition, or the domain check expression is a regular expression thatfurther constrains possible values of a domain. We have a formal syntax developedand the Expression Editor tool that assists in creating such expressions. We also havea parser for checking syntax correctness.

Currently we do not have a possibility to define allowed operators over a domain inIIS*Case repository. It is a matter of our future work.

Each attribute in an IIS*Case project is identified only by its name. Therefore, weobey to the Universal Relation Scheme Assumption (URSA) [5], well known in therelational data model. The same assumption is also applicable in many other datamodels. Apart from the name and description, we specify if an attribute is includedinto database schema, derived, or renamed.

116 I. Luković, M. J. V. Pereira, N. Oliveira, D. da Cruz, and P. R. Henriques

Most of the project attributes are to be included into the future database schema.However, we may have attributes that will present some calculated values in reportsor screen forms that are not included into database schema. They derive their valueson the basis of other attributes by some function, representing a calculation.Therefore, we classify attributes in IIS*Case as a) included or b) non-included indatabase schema. Also we introduce another classification of attributes, by which wemay have: a) elementary or non-derived and b) derived attributes. If an attribute isspecified as non-derived, it obtains its values directly by the end users. Otherwise,values are dervied by a function that may represent a calculation formula or anyalgorithm. Any attribute specified as non-included in database schema must bedeclared as derived one.

A derived attribute may reference an IIS*Case repository function as a queryfunction. Query function is used to calculate attribute values on queries. Only aderived attribute may additionally reference three IIS*Case repository functionsspecifying how to calculate the attribute values on the following database operations:insert, update and delete.

In IIS*Case we have a notion of renamed attribute. A renamed attribute referencesa previously defined attribute and has to be included in the database schema. It has itsorigin in the referenced attribute, but with a slightly different semantics. Renaming isa concept that is analogous to the renaming that is applied in mapping Entity-Relationship (ER) database schemas into relational data model. If a designer specifiesthat an attribute A1 is renamed from A, actually he or she introduces an inclusiondependency of the form [A1] [A] at the level of a universal relation scheme.

Each attribute specification also includes: a reference to a user defined domain,default value and check condition. Check condition, or the attribute check expressionis a regular expression that further constrains possible values of the attribute. It isdefined and used in a similar way as it is for domain check expressions. If theattribute check expression and domain check expression are both defined, they will beconnected by the logical AND.

Both user defined domain and attribute specifications also provide for specifying anumber of display properties of screen items that correspond to the attributes and theirdomains. Such display properties are used by the IIS*Case Application Generatoraimed at generating executable application prototypes. Display properties of anattribute may inherit display properties of the associated domain or may overridethem.

4.2 Application Systems, Form Types and Applications

Apart from name, type and description, each application system may have many childapplication systems. In this way, a designer may create application system hierarchiesin an IIS*Case project. An application system may comprise various kindsof IIS*Case repository objects. For PIM specifications, only two kinds of objects areimportant: a) form types and b) business applications, or applications, for short.

A form type is the main modeling concept in IIS*Case. It generalizes documenttypes, i.e. screen forms or reports by means of users communicate with an IS. It is astructure defined at the abstraction level of schema. Using the form type concept, a

An Attribute Grammar Specification of IIS*Case PIM Concepts 117

designer specifies a set of screen or report forms of transaction programs and,indirectly, specifies database schema attributes and constraints. Each particularbusiness document is an instance of a form type.

Form types may be (i) owned, if they are created just in the application systemobserved, or (ii) referenced, if they are "borrowed" from another application system,regardless if it is referenced as a child application system. If a form type is referencedit is a read-only object in the application system.

Business applications are structures of form types. Each application has its name,description, and a reference to exactly one form type that is the entry form type of theapplication. To exist, each application must contain at least the entry form type. Theexecution of a generated application always starts from the entry form type. Formtypes in an application are related by form type calls. A form type call always relatestwo form types: a calling form type and a called form type. By a form type call, adesigner may formally specify how values are passed between the forms during thecall execution. There are also other properties specifying details of a call execution.Business Application Designer is a visually oriented tool for modeling businessapplications in IIS*Case.

Each form type has the following properties: name, title, frequency of usage,response time and usage type or usage for short. By the usage property form types areclassified as menus or programs. Menu form types are used to generate just menuswithout any data items. Program form types specify transaction programs with the UI.They have a complex structure and may be designated as (i) considered or (ii) notconsidered in database schema design. The first option is used for all form typesaimed at updating database, as well as for some report form types. Only the formtypes that are "considered in database schema design" participate latter on ingenerating database schema. The former option is used for report form types only.

Each program form type is a tree structure of component types. It must have atleast one component type. A component type has a name, reference to the parentcomponent type (always empty for the root component type only), title, number ofoccurrences, and operations allowed. Number of occurrences may be specified as (i)0-N or (ii) 1-N. 0-N means that for each instance of the parent component type, zeroor more instances of the subordinated component type are allowed. 1-N means thatfor each instance of the parent component type, we require the existence of at leastone instance of the subordinated component type. By operations allowed a designermay specify the following "standard" database operations over the component types:query, insert, delete, and update instances of the component type.

Each component type has a set of attributes included from IIS*Case repository. Anattribute may be included in a form type at most once. Consequently, if a designerincludes an attribute into a component type, it cannot be included in any othercomponent type of the same form type. Each attribute included in a component typemay be declared as: (i) mandatory or optional, and (ii) modifiable, query only ordisplay only. Also, a set of allowed operations over an attribute in a component typeis specified. It is a subset of the set of operations {query, insert, nullify, update}. Adesigner may also specify "List of Values" (LOV) functionality of a component typeattribute by referencing a LOV form type and specifying various LOV properties.

Each component type must have at least one key. A component type key consistsof at least one component type attribute. Each component type key provides

118 I. Luković, M. J. V. Pereira, N. Oliveira, D. da Cruz, and P. R. Henriques

identification of each component instance, but only in the scope of its superordinatedcomponent instance. Also, a component type may have uniqueness constraints, eachof them consisting of at least one component type attribute. A uniqueness constraintprovides an identification of each component instance, but only if it has a non-nullvalue. On the contrary to keys, attributes in a uniqueness constraint may be optional.Finally, a component type may have a check constraint defined. It is a logicalexpression constraining values of each component type instance. Like domain checkexpressions, they are specified and parsed by Expression Editor.

Both component type and form type attribute specifications provide for specifyinga vast number of display properties of generated screen forms, windows, components,groups, tabs, context and overflow areas, and items that correspond to the form typeattributes. There is also the Layout Manager tool that assists designers in specifyingcomponent type display properties, and a tool UI*Modeler that is aimed at designingtemplates of various common UI models. All of these display properties combinedwith a selected common UI model are used by the IIS*Case Application Generator.

A presentation of the whole IIS*CDesLang syntax is out of scope of this paper.However, in the following example, we illustrate a form type created in an IIS*Caseproject named FacultyIS, and the corresponding IIS*CDesLang program. Figure 1presents a form type defined in the child application system Student Service of aparent application system Faculty Organization. It refers to information aboutstudent's grades (STG). It has two component types: STUDENT representinginstances of students, and GRADES, representing instances of grades for eachstudent. By the form type STG, we allow having students with zero or more grades.Component type attributes are presented in italic letters. StudentId is the key of thecomponent type STUDENT, while CourseShortName is the key of GRADES. Bythis, each grade is uniquely identified by CourseShortName within the scope of agiven student. Allowed database operation for STUDENT is only read (shown in asmall rectangle on the top of the rectangle representing the component type), whilethe allowed database operations for GRADES are read, insert, modify and delete.

Figure 2 presents a fragment of IIS*CDesLang program that corresponds to theform type specification from Figure 1.

APPLICATION SYSTEM PARENT APPLICATIONSYSTEM

Student Service Faculty Organization

Fig. 1. A form type in the application system Student Service

STUDENT

GRADES

StudentId, StudentName, Year

CourseShortName, Date, Grade

STG - STUDENT GRADES

r

r, i, m, d

An Attribute Grammar Specification of IIS*Case PIM Concepts 119

Project: Faculty ISApplication System: Faculty Organization...Application System: Student Service

is-child-of <<Faculty Organization>>FormType: “STG - Student Grades”

ComponentType: STUDENTAllowed Operations: readPosition: sameWindowDataLayout: TableLayoutWindow Position: CenterComponent Type Attributes:

Name: StudentIDCTAMandatory: Yes...

Name: StudentName...

Name: Year...

Component Type KEY: StudentIDComponentType: GRADES is-child-of <<Student>>

NoOfOccurrences:(0:N)Allowed Operations: read, insert, modify,delete...Component Type Attributes:

Name: CourseShortName...

Component Type KEY: CourseShortName...

Fig. 2. A fragment of IIS*CDesLang program that corresponds to the form type in Figure 1

5 The Attribute Grammar Specification of IIS*CDesLang

In this section, we discuss how VisualLISA (whose principles and functionalitieswere introduced in section 3) is used to create IIS*CDesLang. Due to spacelimitations, we only present a small set of productions and semantic calculations, justto show how we use the visual editor to model the language. Before that we present ashort description of VisualLISA look and feel, and main usage.

Figure 3 shows the editor look and feel; it exhibits its main screen with four sub-windows. To specify an attribute grammar a user starts by declaring the productions(in rootView – bottom-left sub-window) and rigging them up by dragging the symbolsfrom the dock to the editing area (in prodsView – upper-left sub-window), ascommonly done in VPEs. The composition of the symbols is almost automatic, sincethe editing is syntax-directed. When the production is specified, and the attributes areattached to the symbols, the next step is to define the attribute evaluation rules. Once

120 I. Luković, M. J. V. Pereira, N. Oliveira, D. da Cruz, and P. R. Henriques

again, the user drags the symbols from the dock, in rulesView (upper-right sub-window), to the editing area. To draw the computations links should connect some ofthe (input) attributes to an (output) attribute using functions. Functions can be pre-defined, but sometimes it is necessary to resort to user-defined functions that shouldbe described in defsView (bottom-right sub-window). In this sub-window it is alsopossible to import packages, define new data-types or define global lexemes.

Fig. 3. VisualLISA main windows

In this example of how we use VisualLISA to rapidly develop a formalspecification for IIS*CDesLang, we will show how the following condition isformalized and verified using the visual editor: “The application types associated toan application system should be previously defined”.

Figure 4 shows the first production of IIS*CDesLang (the one having the grammaraxiom as the tree root). As can be observed the root (Project) derives in three othernon-terminal symbols (ApplicationTypes, ApplicationSystems, and Fundamentals)and two terminals. Apart from that structural description, the production shown inFigure 4.a states that the attribute verify of the root symbol has the same value as thesynthesized attribute verify (green triangle) of the non-terminal ApplicationSystems.In Figure 4.b it is presented a detail of the same production, specifying that the inher-ited attribute setof_types (red inverted-triangle) of non-terminal ApplicationSystems,inherits the value of the attribute setof_types of the non-terminal ApplicationTypes.

In Figure 5, we present how the attribute setof_types of the non-terminal Aplica-tionTypes, is computed. First notice that the production for this non-terminal has twooptions: (i) a non-recursive one, where AplicationTypes derives only one Aplication-Type (Figure 5.a) and (ii) a recursive case, where the left-hand side (LHS) non-termi-nal derives into an AplicationType and recursively calls itself.

An Attribute Grammar Specification of IIS*Case PIM Concepts 121

(a) (b)

Fig. 4. Production structure and computation rules for non-terminal Project. (a) computationrule for attribute verify; (b) computation rule for inherited attribute setof_types

(a) (b)

Fig. 5. Production structure and computation of attribute setof_types of the elementApplicationTypes. (a) non-recursive case; (b) recursive case

In this production, we are interested in collecting the application type names thatcan be associated to the application systems, as explained before. To describe this inVisualLISA we created a function that adds a string to a list, and this function is usedto collect the types that are synthesized from each non-terminal ApplicationType. Theblue explosion symbol denotes the function, the dashed-arrows define the argumentsof these functions, and the straight blue arrows denote to which attribute the output ofthe function is assigned. The numbers in the dashed-arrows indicate the order of thearguments in the function, which are then used as ‘$i’ in the function body.

Recall Figure 4.b, where an inherited attribute is assigned the value of the attributewe just compute in Figure 5. The reason why we need to inherit this attribute is in thefact that we must check whether the type of each application system is in this list.Otherwise the language is not correct according to the contextual condition that we tryto verify in this example. Figure 6 presents the recursive option of the production withthe ApplicationSystems as LHS symbol.

122 I. Luković, M. J. V. Pereira, N. Oliveira, D. da Cruz, and P. R. Henriques

Fig. 6. Recursive case for production of the symbol ApplicationSystems and computation of theattribute verify

From each application system we synthesize its application type (attributeapp_type). Then, we use the inherited attribute setof_types and the value that resultsfrom applying this computation to the rest of the application systems in the language,to inject these three arguments in a function that tests if the setof_types ($1 in theoperation description of Figure 6) contains the value of the synthesized attributeapp_type ($2 in the operation description). As this operation returns a boolean value,we check using the logic and operation, if this value and the value of the attributeverify ($3 in the operation description) are both true. The output of the function is alsoa Boolean and is assigned to attribute verify of the LHS symbol.

The non-recursive option of this production is similar, but the computation of thefinal attribute is only based on the list of types and the type that comes from theApplicationType symbol.

Although the drawings presented in Figures 4 to 6 have been formally constructed,for those that read the visual grammar it is not necessary to know if attributes aresynthesized or inherited, neither the way evaluation rules are built – it is enough tounderstand the way they are connected to understand the new language semantics.The remaining parts of the formalization follows the same structure as the onepresented in this section.

With VisuaLISA we defined a model of IIS*CDesLang PIM concepts. This modelcan be turned into a valid attribute grammar, and in a straightforward step, we havenot only a new language, but also a compiler for the language.

6 Conclusion

Attribute Grammars (AG) are widely used to specify the syntax (by the underlyingContext Free Grammar) and the semantics (by the set of attributes and theirscomputation rules and contextual conditions) of computer languages. This formalismis well defined and so its usage is completely disciplined; but, more than that, it has

An Attribute Grammar Specification of IIS*Case PIM Concepts 123

the unique property of supporting the specification of syntax and semantics under thesame framework. Moreover, an AG can be automatically transformed into a programto process the sentences of the language it defines. AG can also be used to givesemantics to other systems, if we look them following that grammar approach.

The research presented in this paper resulted from the collaborative researchproject between Serbia and Portugal. To formally describe the Integrated InformationSystems CASE Tool (IIS*Case) – a model driven software tool that provides ISmodeling and prototype generation developed at University of Novi Sad – we define aDSL, named IIS*CDesLang, that encompasses problem domain concepts and rulesthat are applied in the conceptual IS design provided by IIS*Case. In the paper, wepresent such a meta-language resorting to a visual programming environment forattribute grammar specifications, named VisualLISA, developed at University ofMinho. VisualLISA makes the process of AG development easier and safer; it allowsthe drawing of the AG productions (grammar rules) in the form of attributed treesdecorated with attribute evaluation rules. These visual productions are syntacticallyand semantically checked for correctness.

As future work, we plan to complete the specification to cover all the IIS*Case andthen use the compiler generator system LISA to produce a compiler for IIS*DesLang.On the basis of the grammar specifications and the problem domain knowledge, it isalso possible to design tools providing some semantic analyses of the designedspecifications and further assist designers in raising the quality of their work. Twocharacteristic examples are domain compatibility analysis and check constraintequivalence analysis. Finally, we plan to embed a textual editor for IIS*DesLang intoIIS*Case and couple the language and generated compiler with IIS*Case repository.

Acknowledgments. A part of the research presented in this paper was supported byMinistry of Science and Technological Development of Republic of Serbia, GrantTR-13029, Title: A Development of an Intelligent Environment for the Design andImplementation of Information Systems.

References

1. Aleksić, S., Luković, I., Mogin, P., Govedarica, M.: A Generator of SQL Schema Specifi-cations. Computer Science and Information Systems (ComSIS), Consortium of Faculties ofSerbia and Montenegro, Novi Sad, Serbia, ISSN:1820-0214, Vol.4, No. 2, 79–98. (2007)

2. Banović J.: An Approach to Generating Executable Software Specifications of anInformation System. Ph.D. Thesis (currently in final stage). University of Novi Sad. (2010)

3. Deursen van, A., Klint, P. Visser, J.: Domain-Specific Languages: An AnnotatedBibliography. ACM SIGPLAN Notices, Association for Computing Machinery, USA, Vol.35, No. 6, 26–36. (2000)

4. Pereira, M. João, Mernik, M., Cruz, D., Rangel Henriques, P.: Program Comprehension forDomain-Specific Languages. Computer Science and Information Systems (ComSIS),ISSN:1820-0214, Vol. 5, No. 2, 1–17. (2008)

5. Luković I.: From the Synthesis Algorithm to the Model Driven Transformations inDatabase Design", In: Proceedings of 10th International Scientific Conference onInformatics (Informatics 2009), Herlany, Slovakia, ISBN 978-80-8086-126-1, 9–18 (2009).

124 I. Luković, M. J. V. Pereira, N. Oliveira, D. da Cruz, and P. R. Henriques

6. Luković, I., Mogin, P., Pavićević, J., Ristić, S.: An Approach to Developing ComplexDatabase Schemas Using Form Types. Software: Practice and Experience, John Wiley &Sons Inc, Hoboken, USA, DOI: 10.1002/spe.820, Vol. 37, No. 15, 1621–1656. (2007)

7. Luković, I., Ristić, S., Aleksic, S., Popović, A.: An Application of the MDSE Principles inIIS*Case. In: Proceedings of III Workshop on Model Driven Software Engineering (MDSE2008), Berlin, Germany, TFH, University of Applied Sciences Berlin, 53–62. (2008)

8. Luković, I., Ristić, S., Mogin, P., Pavicević, J.: Database Schema Integration Process – AMethodology and Aspects of Its Applying. Novi Sad Journal of Mathematics, Serbia, ISSN:1450-5444, Vol. 36, No. 1, 115–150. (2006)

9. Mernik, M., Heering, J., Sloane, M. A.: When and How to Develop Domain-SpecificLanguages. ACM Computing Surveys (CSUR), Association for Computing Machinery,USA, Vol. 37, No. 4, 316–344. (2005)

10. Rangel Henriques, P., Pereira, M. João, Mernik, M., Lenič, M.: Automatic Generation ofLanguage-based Tools. Workshop on Language, Descriptions, Tools and Applicationsunder ETAPS'02 (LDTA2002), Grenoble, France, April 2002.

11. Pereira, M. João, Mernik, M., Cruz, D., Rangel Henriques, P.: VisualLISA: a VisualInterface for an Attribute Grammar based Compiler-Compiler, In proceedings of 2ndConference on Compilers, Related Technologies and Applications (CoRTA08), IPB,Bragança, July 2008.

12. Oliveira, N. Rangel Henriques, P. Cruz, D. Pereira, M. João: XAGra - An XML Dialect forAttribute Grammars, In Proceedings of Conferene on XML and Associated Technologiesand Applications (XATA09) under INForum'09 - Simpósio de Informática, FCT-UL.(2009)

13. Oliveira, N. Pereira, M. João, Rangel Henriques, P. Cruz, D. Kramer, B.: VisualLISA: AVisual Environment to Develop Attribute Grammars. Computer Science an InformationSystems Journal, Special Issue on Compilers, Related Technologies and Applications(ComSIS), Lukovic, I. and Leitão A, Slivnik B. (Guest Eds.), ISSN:1820-0214, Vol. 7,No. 2, 265–289. (2010)

14. Mernik, M., Lenič, M., Avdičaušević, E., Žumer, V.: LISA: An Interactive Environmentfor Programming Language Development. Compiler Contruction, 1–4. (2002)

15. Knuth, D. E.: Semantics of Context-free Languages. Theory of Computing Systems, Vol 2,No. 2, 127–145. (1968)

16. Krahn H., Rumpe B., Völkel S.: Roles in Software Development using Domain SpecificModelling Languages, In Proceedings of 6th OOPSLA Workshop on Domain-SpecificModeling, Portland, USA, 150–158. (2006)

17. Jouault F., Bézivin J.: KM3: a DSL for Metamodel Specification, In Proceedings of 8thIFIP International Conference on Formal Methods for Open Object-Based DistributedSystems, Bologna, Italy, Springer LNCS 4037, 171–185. (2006)

18. Meta-Object Facilty: http://www.omg.org/mof/19. The Generic Modeling Environment: http://www.isis.vanderbilt.edu/Projects/gme/20. MetaCase Metaedit+: http://www.metacase.com/21. Eclipse Modeling Framework: http://www.eclipse.org/modeling/emf/