Grammatical approach to problem solving

(1)

Grammatical Approach t o Problem Solving

Pedro

Rarigcl Hcnriqucs' .Toinai Kosar2

~

Marjan Mcrnik"

Maria Jo50 Varaiida

Pcrcira3. Viljcm

Zumcr2

Uiiiversitp of hliiilio, Departliieiit of Coiriputer Scieiice, Portugal

Uiiiversity of nikribor, Faculty of Electrical Eiigiiieeriiig aiitl Coiiiput,er Scieiice, Sloveiiia Polytecliiiic Iiistitute of Bragaiqa, Portiigal

7tLjOUO @Lp 6. jJ t

plll@di. r L r r l i 7 L t l o . p t

{ t 07tli1.2. kos Urj 711 a 7'jan. 71 k f Y 1 1 . lk , z1L,lri er'} @IL t l i - 711 6. sr

1 Introduction

Oiic of tJic well k~iowii properties of soft,-

i v a r c syst,eiiis i s tlint. t,liey are subject to frcqueiit cliaiigcbs. A sof'tware developer iieetls to build a

soft.\\~ilr(~ systeiii i i i sucli a iiiaiiiier tliat lie cirii eas- ily ; i t l a ] ) ( , it t , ~ tlic iiscr's cliaiigcal>le reqiiirciiieiits.

Ciiri.t!iit ol)ject.-oi.ieiit,etl desigii tecliiiiqiies [ 5 ] [GI

i l l < ' well siiitcd fur a sucli tlesigii for a cliaiige. How-

PVCY.. a ~ i y cliaiiges tluriiig t.lie software life cycle are costly. Tlieit~fore, it is very iiriportaiit t h a t t,lic iiser is iiivolvrd i i i tlie software tlevelopiiieiit pro-

froiii tlic very begiiiiiiiig itiitl that, the software

c i i i is tlelivercd t.o tlic user before liis require-

iiic3iit.s liave t.lw opportiiiiity t.o cliaiige.

Ilapicl prot,ot,ypiiig eiitibles t,lie software tlevel- ol)er 1.0 I)iiiltl cscnital)le prototypes aiitl t,o iiivolve

tlie user iii ai1 itera.tive biiild-execiite-rriodify loop uiit,il his requireiiieiits a.re validated. The prototype is then used to build t h e filial versioii of the software systeiri tlirougli the use of the arcliitecture iiicludetl iii the prototype or it is siiriply tlirowii

away [ l G ] . I i i tlie latter case the prototype is used

to c1ai.if-y the user's iieetls. I n both cases, tlie rapid prototypiiig approacli is used wlieii t,he user's requireiiieiits are iiot well defiiied. The proposed appixiach, i.e. the ~ ~ 1 % ~ r 1 1 7 r i . u t i i : i ~ l uppr'oui:h to p m b -

l e r r i . s ( J ~ U L , I L ~ . rests o i i t h e success rer-Lchetl 11.y at-

tril,ut,e graiiiiiiars iii t h e specihxtioii of laiiguage

seiiiaiitics [Y] [ 3 ] aiid iii t.lie syst,eniat,ic iiiipleirieii- tatioii of laiigiiage processiiig tools [7] [ 8 ] . I i i t h e

paper tlie graiiiiiiatical appr'oacli to probleiii solviiig support,d by aii attribute graiiiiiiar developed

a i d wiit,teii i i i aii object-orieiited style (OOAG)

is proposctl. Oiie of the h i e f i t s of the proposed approtrcli is t.liat, it eiial)les rapid prototypiiig aiid t,lie validat.ioii of tlie user's reqiiireiiieiit,~ iii a prag-

iiiat.ic way. The idea is to traiislate the OOAG ob- taiiietl i i i tlie spet:ifici1t,ioii 111ii)~e iiit,o the coiicrete syiit,ax of a coiiipiler generator iii order to c1ea.t.e

a siriiulator for i,liat probleiii. We caii tlieii write sceiiarios (iii t,lie tloiiiaiii-specific 1a.iigiiage [17] de-

fiiied b y tliat OOAG) tlescr'ibiiig tliffereiit uses of tlie systeiii, aiid use t,he generated siriiiilat,or to process those stwiarios coiiipiitiiig t,lie desired results. Tlie org;iiiizat,ioii of the paper is as follows. I11

Sect.ioii 2 related works are descril)ed. Tlie graiiiiiiatical a1)proacli to pi.obleiii solviiig is presented

iii tlet,ail in Sectioii 3 followed by aii exairiple i i i the

Sectioii 3 . A syiit,hesis aiid coiichitlirig reiiiarks are preseiited iii Section 5.

2 Related Work

The graiiiiiiatical c~pproacli to software develop- irieiit caii bc seeii a b d i i exteiisioii of object-orieiitetl de5igii iiietliotls [15] [ 5 ] [(i] wliere a probleiii tlo- 25th Int. Conf. Information Technology Interfaces IT1 2003, June 16-19, 2003, Cavtat, Croatia

(2)

i i i a i i i iiioclel is developed froiri use-cases a d chss tliagraiii. However! their iiiaiii goal is to develop good soft,ware iiiodels (e.g. as i i i [ I l l ) . Our goal

is t,o develop rapid prototypes aiid early valitlatioii of userk requireiiieiits.

Our work is closely related to the Grairiiiiar- Orieiited Object Design (GOOD) [l] [ l o ] , where

iill valid object iiitera.ctioii sequeiices of tlie clus- ter of ol)jects are ideiitified. Tlieii a nieta-iriodel is coiist,ructed iilitl represeiited as a coiitext-free graiiiiiiar. However, our approacli differs froiii [l]

[LO] siiice they are usiiig a coiitext-free grarriinar to

tlescri1)e hliiivior of the ol,jects (iiietliods), wliile

iii our Cilse the structure of a cla.ss (a.tt,riliutes) is

descrilml. Our api)roacli lias also different goals a i d adva.iitages. However, it caii lie seen as coiiipleiiieiitary t,o the GOOD approach. Coiiiliiiiiiig Imth tipproilclies t o describe tlic beliavior aiid the structure with a doiiiaiii-specific laiiguage, is uiitler iiivestigatioii.

T h e graiiiiiiat ical apl)roidi t o software tlevelopiiieiit is also related to the rapid prototypiiig research (e.g. [3]). hi [3] Two-Level Graiiiiiiars

( T I E ) were proposed as an object-orieiited re- qriireiiieiit specificatioii laiiguage. Successive re- - fiiieiiieiit, steps startiiig with iia.tura1 laiiguage lead to iiiore detailed specificatioiis t h a t caii tie traiis- Int,ed to VDR,I++, wliicli iii turii is t,ransliited t,o .Java. yieltliiig a rapid prototype of a systeiri. With (,his approacli it. is possible t o obtaiii the rapid pro- t,ot.ype of a systeiii froiii iiatural laiiguage specificatioiis. Iii iiiore coiiiplex cases rapid prototype is

iiot coiiipletely autoiiiatically derived siiice a suffi- cieiit tlegrce of iiitera.ctioii with a user is required t.o eiisure a correct iiiterpreta.tioii.

R.esolviiig the seiiiaiitic,al gap hetweeii use-case

diagraiii aiitl class diagraiii is also presented i i i [14].

Froiii t.lie use-case tliagraiii ageiits state niacliiiies

i i i i ( l \/idlies atltled iiiviiriaiits are derived. Tlie term

iigeiitr is used t o rcpreseiit ail actor collahorat,iiig wit.11 t.lie systeiii tlirougli specific use-case. Botli tecliiiiques are collectivcly used in iterative coii- vertiiig algoritliiii, wliicli Iniiltls the OCL specifi- cahoii i1.iitl class diiigrairi. The OCL specifica.t.ioii (tlefiiie ii. set of precoiidit.ioiis, postcoiiditioiis aiitl

act,or iiiviiriaiits) are fiirt,lier iisctl to clieck tlie cor-

rcctiiess of t,lie iiiodel.

3 The Grammatical Approach

To acliieve a good uiiderstaiidiiig of tlie user’s world? we ~iccd to uiiderstaiid the applicatioii do-

i i i i i i i i . I i i otlier words, we iieed t o ideiitify concepts iiiitl tlieir relatioiisliips iii the protileiii doiiiaiii. For tliis purpose object-orieiited design (OOD) uses use-case tliilgraliis aiid coiiceptual class diagraiiis [ 5 ] . Tlie iise-case diagram describes tlie fuiictioiiality of the systeiii. Use-cases are iiarra-

tive descriptioiis of specific tasks, wliile the conceptual class diagram captures coiicepts arid relatioiisliips betweeii tlierri. Guideliiies for develop- ing the coiiceptual class diagram caii be found in [15]. Froiii the use-case diagram aiid froin the coiiceptual class diagrairi a skeleton design model is obtained wliicli should be robust with respect to clia.iiges of the user’s requireiiieiits. For itleiitify- iiig concepts arid their relatioiisliips iii tlie problem doiiiaiii our grariirriatical approacli is not limited t o object-orieiited design. Also otlier approaches, siicli as tla.ta-flow diagrairis aiid entity-relatioil di- agra.~iis wliicli show tlie flow of work and the re- latioiisliip between x t i v i t i e s and deliverahles, can be applied. However, object-oriented design

[a]

[6] is iiow alitiost the-fa.cto standard for software systerii design aiid it is also used iii our approach.

Therefore, the starting point of our grarniiiatical approach is a coriceptual class diagram. To enable rapid prototypiiig the following steps are used iii our approacli (Fig. 1):

0 tleriviiig the coiitext-free graiiiiiiar from the 0 describing the seiiiilritics of every coiicept, 0 geiieratiiig the rapid prototype of a system

Doiiiaiii concepts aiid relatiorisliips ainoiig tlieiii tire identified iii the coiiceptual class diagraiii aiid are further represented as a coiitext-free grairi-

iiiar. Tlie obtairied coiltext,-free grairiiiiar describes the syiitax of a doiriaiii-specific language whose seinaiitics is the same as the fuiictioiiality of the system uiider irripleiiieiitatioii. The seiriaritics of the doiriaiii specific laiiguage is described with attribute graiiiinars (derived froin doiriaiii concepts) froiii which a coiripiler is autoiriatically generated. The executioii of a particular prograin written in a tloiiiaiii-specific 1aiigua.ge correspoiids t o the executioii of a prototype of a system on a particular use-case. Tlie brief description of the above steps is described in tlie followiiig subsectioiis.

coiiceptual class diagram,

3.1 Deriving

a

context-free gram-

mar from

a

conceptual class di-

agram

The role of iioii-terniirials in a coiitext-free graiiiniar is two fold. First, a t higher al,stract,ioii level Iioii-teririiiials are used to describe tliffereiit coiicepts i i i the prograiriiriirig laiiguage (e.g. ex-

pressioii or declaration iii t,lie general-purpose pro-

graiiiiiiiiig language). 0 1 1 tlie other haiid, at more coricrete level iioii-terniiiials arid teriiiirials are used to tlescrilie the structure of a concept (e.g. variable declarations coiisist of var-iable type and variable iiaiiie followed by seiiiicoloii). Therefore, both the coiicepts arid relatioiiships betweeii them are cap- tured iii a context-free grairirnar. B u t , this is also

(3)

1

Conceptualclass

’

i

Diagram

L

,i

I

1

DSL Program =

Use Case

--I

Compiler = Rapid Prototype

i

Result = Behaviour of the System

Figure 1: High-level view of the gramriatical ap- prtlilcli

t,me for tlie colicoptual class diagram wliicli tle- scrilm concepts in a probleni doiiiaiii and their relat.ioiisliips. I t is clear that both foriiialisiris ciili lie used for t h e saiiie purpose a i d that soiiie rough triilisforliiat8iori fro111 a coiiceptual class diagraiii to a coiit,ext,-free graiiiiiiar aid vice versa sliorild exist.

111 geiieral, classes are niappetl to iioii-teriiiiiial

syiil)ols a.iitl attribut,es are niapped to terrriiiial sgiiil)ols. Tlie result of this s k p is a context-free ~ 1 ~ i i ~ i ~ ~ ~ ~ ~ i i r . A class diagrairi coiisists also of oper- iit.ioils, wliicli will be identified when the seiiiaiitics of coiitext-free grairirnar is going to be de- fiiietl. Associatioils rqreseiit tlre iiiteractioii I)e-

t w w i i classes a i d have to lie iiicluded ill a coiit,ext-

free gri1lriliiar. The iiaviga1)ility associa.tion caii be tlcscribcxi with the productioii A + B. wlierc tlie iioii-kriiiirial A gets iiiforiiiatioii about attributes of t,lie iioii-teriiiiiial D. Association lias iiiultiplicity. Descri1)iiig niiiltiplicity with graiiiiiiar productioiis is st.l.aiglit.forwa.rtl as s l i o w i ~ oii aii exaiiiple for ~iiul- tiplicit,y O..iii:

A -> MoreB ,

MoreB -> MoreB B I epsilon

For griieralixatiori we propose the production A

+ D

1

G. Tlie iioii-teriiiiiial A can be inipleirieiitd

citlier with the non-teririiiial B or iioii-teriniilal C. Tlir coiilpositioii aiid aggregatioii a.re described as t l i r Iiavigaliility associatioii. 111 t h e coiiiposit,ioii t h e : iioii-i,eriiiiiid B can a.lq)eii.r i i i other protluc-

tioiis. 0 1 1 the o t h r liald, i i i tlie a.ggregat,ioii the

iion-t,erliiiilitl B is reacliable only froxii the iioii-

teriiiiiial .4.

r

3.2 Describing t h e semantics of each

concept

To describe tlie semantics or the meaning of a concept ail attribute grainmar is used. Attribute grammars [9] are natural extensions of context-free grainmars aiid as such very well support our approach wliicli is based 011 context-free grainmars.

The syntax mid seiiiaiitics of each symbol is specified iii a riiodule (modularity is the iinplicit fea- t,ure of a gramriiar axid is based on the locality associated with syiiibols arid productions). The first part of a iiiodiile is the declaratioii of its attributes, divided iii two subsets, tlie inlierited (context de- pendent) and tlie syiitliesixed (computed locally). The fiiiict,ioris t o be used to evaluate each attribute are tlieri defined in the context of each production. Also tlie contextual coiiditioris, if any, that express tlie data coiistraiiits are defined in the context of each production. The activities involved in the sec- ond step are intellectually demanding aiid may require sigiiificant, creativity of tlie designer. The result of this step is a complete attribute graniriiar specificatioii for a given problem.

3 . 3 Generating t h e rapid prototype

of

a system

To generate the rapid prototype of a system our corripiler-geiierator LISA [12] has been used. The LISA system autoiriatically generates a coin- piler or interpreter aiid other language-based tools, such as laiiguage-kiiowledgeable editor, inspectors, and aiiiiiiators [8] from attribute grainiriar specification. One of LISA’S most iiiiportaiit feature is that it supports increrrierital developrrieiit of speci- ficat,ioiis, which is especially important in particular tasks of the software development described in this paper.

4 An Example: Chocolate Vending

Machine

Our approach is illustrated on a simple example. hlore exairiples can be found iii tlie techiiical

report [13].

The problem: We w a i t a program for the daily iiiaiiageirieiit of a Chocolate Vending hla- cliine. Given the stock (name, price and quantity of each clioco available) and the d a t a for each sale (Iiaiiie of chosen clioco, aiid ariiount of money iri- trotliiced) the goal is to corripute the iricorrie and the final stock No clioco should be provided i f

tlie iiariie does not exist in the stock list, or the quantity is 0, or

(4)

“ 1 7 1 P String

Figure 2: T h e Coiiceptual Class Diagraiii for Vend- iiig hiIi~cliiiie

0 the aiiiouiit of iiioiiey is different froin tlie ])rice.

The Conceptual Class Diagram:

After tlie aiialysis of tlie prohlexii stated above, we itleii- tified tlie v e n d i n g mach,ine ( V M ) as tlie rriaiii coiicept,. Tlie two otlier iiriportaiit concepts iii t h e

iiiaiiageitieiit, of tlie ven.rlirig rriuchirie are: Stock,

aiitl Sale. Stock is a, set of iteiiis, aiid each Zte,rri

lias a “ m e . a prLce. aiid a p U 7 L l % t u . Tlie d a t a t o

I)e kept. for each Sule operatioii is tlie item “ m e

aiitl the aiiiouiit of rrwriey giveii. Tlie structure of tlie p r o l h i i doriiaiii caii lie defiiied iii teriiis of classes atid relat,ioiisliips as tlcpict,ed in tlie coiicep- t,ual class tliagraiii iii Fig. 2 .

The Structure:

Reiiieiiiber t,liat, iii our approacli, a prol)leiii coiicept is tleiioted by a graiii-

iiiar syiiil)ol. Tlie coiltest-free graiiiiria.r below for-

iiiiilizes tlie probleiri syiitax iii tlie sense tliat it

specifies tlie structure of the prol)leiii tloiiiaiii. re- liitiiig (,lie roiicepts aiiioiig tlieiii. Tlie followiiig coiitc,st-frce gri~iiniiar is o1)taiiied usiiig trimsfor- iiiat,ioiis tlescri1)etl i i i Sectioii 3:

V M -> Stock Sales

Stock -> Stock Item

Item -> name price quantity

I

&

Sales -> Sales Sale

Sale -> name money

I Sale

The Semantics:

Tlie iiext s t e p is to define the seiiiaiitics for ea.cli iioii-teriiiiiial syiiibol. Due to liiiiitcd page leiigtli oiily a part of the wliole at- t,ril)ut,e graiiiiiiar specificatioii is giveii below. Tlie coiiiplete exaiiiple is giveii in [13]. Accordiiig to tlie

prolileiii descriptioii, the aendirig rriuchi7~e sliould have two attributes: FStkTab (the final stock ta- ble) and Income (the filial iiicoiiie). Tliese at-

tributes denote t h e two required value coiriputa- tioris (the prohleiii goals). T h e iiihereiit modularity of attribute grainiriars enables us to write sepa- rate attribute grarriiiiar modules for each attribute associated t o a grarriiriar symbol. T h e complete specifica.tiori is t h e attribute graininar obtaiiied by coiiipositioii of all inodules. Oiily attribute graiii- mar for VM iriodule are sliown below.

We will start with stock table evaluatioii. No- tice t h a t its value is iiot computed locally to tlie VM syiiiliol defiiiitioii; it tlepeiids oii t h e sales processiiig. To perform such coinputatioii, it is necessary to kiiow tlie stock ta.ble before to start selling (iiii- tially tlie stock table is empty). F’roin tliese state- riieiits it is clear that syiiibols Stock and Sales will be cliaracterized by a stock ta.ble tliat liolds two distiiict values aloiig the processing tiiiie: the iiiitial one (depeiids oil tlie eiiviroiiirient); aid tlie final oiie (coiriputed during tlie sales yrocessiiig). So both will be associated with two attributes -

StkTab, FStkTab- t h e first oiie iiilierited from

tlie context, and tlie secoiid oiie syiitliesized froin the previous a i d tlie attributes associated t o each item. T h e type, TAB, of those two attributes is a finite fuiictioii (a iiiappiiig) tliat associates a naiiie witli a pair (price, quaiitity).,

TAB = FF( string, (rea1,int) )

NonTerm VM :

Inh:

13

Syn: { FStkTab: TAB

1

vm-manager(VM -> Stock Sales):

/ / associated semantics

VM.FStkTab = Sales.FStkTab

Stock.StkTab = {>

Sales.StkTab = Stock.FStkTab

Tlie next iiiodule is used t o describe t h e coiii- putatioii of tlie attribute Iucome. T h e filial result depeiids oii tlie aiiiouiit accuiriulated 011 each sale,

as stated much,ine.

NonTerm

iii the followiiig iiiodule for t h e ,uendiri.y

VM :

Inh:

{I

Syn:

C

Income: int

I

vm-manager(VM -> Stock Sales) :

VM.Income = Sales.Sum

Notice t h a t tlie stock declaration part plays 110

role i i i the 17ico~r~e evaluatioii. Tlie partially pre-

sented attribute graiiiiriar represeiits tlie foriiial specification for tlie given probleiri.

The rapid prototype:

Tlie attribute graiiiiiiar specified iii tlie previous step is tlieii writteii

(5)

usiiig our coiiipiler geiiera.tor systeiii LISA. The iii- Iierciit, iiiodularity of attriliute graiiiiriars eiiables iterat.ive tlesigii of prototype. Therefore, iiiore fuiictioiialitics of a systeiii caii be iiripleiiieiited. An

exaiiiple of the iiieiitioiied iiilierited iiiodularity is sliowii below: iii t.he first laiiguage (Vht-1) oiily

stock descriptioii is iiitroducetl aiid sales descrip- i,ioii is acltled to tlie next, laiiguage (VM-2).

A pa.rt of these sl)ecifica,t.ioiis are sliowii 1)elow. N0t.e tlic straiglitforwartl traiislatioii frorri above specificxt,ioiis to LISA.

language VM-1 {

. . .

attributes Hashtable *.StkTab, *.FStkTab;

rule VM {

. . .

VM : : = STOCK compute {

VM.FStkTab = STOCK.FStkTab; STOCK.StkTab = new Hashtableo;

1 ;

1

rule Stock {

STOCK : : = STOCK ITEM compute C

STOCK[O] .FStkTab = 1TEM.FStkTab; STOCK [ 11

.

StkTab

1TEM.StkTab = STOCK[lI .FStkTab;

= STOCK [OI

.

StkTab ;

1 I

epsilon compute STOCK. FStkTab = 1 ;

1 . . .

1 / / language VM-1 language VM-2 extends rule overrides VM { . . .

c

STOCK.StkTab; VM : : = stock-description STOCK sales-description SALES compute { VM.FStkTab = SALES.FStkTab; STOCK.StkTab = new HashtableO; SALES.StkTab = STOCK.FStkTab;

1 ;

>

. . .

1

/ / language VM-2 language VM-3 extends VM-2 {

attributes double *.income,

*,sum, *.amount; rule extends VM { compute {

1

VM.income = SALES.sum; 1

rule extends Sales {

SALES : : = SALE compute {

SALES.sum = SALE.amount;

1

1 SALES SALE compute {

SALES [OI .sum = SALES [ l l .sum

+ SALE.amount;

1 ;

>

1

/ / language VM-3

1

From above specifications the VM-3 compiler is autoiiiatically generated by LISA systeiii. Key- words ”stock-descriptioii” aiid ”sales-descriptioii” have been iiitroduced to explicitly show tlie differ- eiice between stock aiitl sales descriptioiis. Witli- out these keywords the grairirriar is iiot LR(1). Oiie of tlie possible sceiiarios is now described with tlie followiiig program written in our DSL.

stock-description mars 0.50 10 kitkat 0.60 15 twix 0.60 5 sales-description twix 0.60 twix 0.60 mars 0.50 twix 0.60

The iiieaniiig of tlie above prograiii is tlie followiiig stock aiitl irioiiey iiicoiiie:

FStkTab: {twix=(O.BO Euro, 2 ) ,

kitkat=(0.60 Euro, 151, mars=(0.50 Euro, 9))

Income: 2.3 Euro

5

Conclusion

111 the paper our approacli t o tlevelopiiig a fornial specificatioii for a given prok)leIii usiiig a coiiipleiiieiitary syiitax/seiriaiitics approach is described. Not least, our approach can be also seeii as a forriial approacli t o prograrn coiistructioii with a11 Ileiiefits of foriiial approaches. The proposed approach caii he also used if tlie user’s requireiiieiits are iiot well defiiied. Tlie essence of our approach is tlie tlevelopiiient of a doiriaiii-specific laiigiiage tliat describes the user iiiteraction with -a system or tlie fuiictioiiality of a systeiii. While execut,- iiig prograiiis writ,ten iii a specified doniaiii-specific

lilriguage the fuiictioriality of a system aiid user’s reqiiireiiieiits caii be validated. Tlie starting poiiit of our approacli is tlie identificatioii of coiicepts

iii tlie probleiri doiiiaiii. Here, well kriowii tecli-

iiiqiies froiii object-oriented desigii, siicli as use- c u e diagrams and coiiceptual class diagrairis, are used. However, our approach caii be used also with

(6)

data-flow dia.graiiis mid entity-relatioii diagraiiis.

Iii that ca.se just, new traiisforiiiatioii rules have to I)e tlefiiietl, siiiiilar to those explaiiied iii Sectioii 3. 111 our future work we would like to irivesti- gate the possiljility t o o l h i r i a doiriaiii-specific laiiguage oiily froiii a use-case diagraiii wliicli describes the fuiictioiiality of a system. It is well kiiowii that use-case diagrams and class diagrairis represeiit differeiit views oii a given problem aiid t h a t there is 110 direct traiisforiiia.tioii betweeii

tliosc two tecliiiiques. Has such coiikxt-free graiii-

i i i i l r soiiie viduiible iiiforiiiatioii for coiistructiiig il coiiceptual class diagram? Is it possilile t,liat,

a coiikxt-free graiiiiiiar of a domain-specific laii- gua.ge: derived froiii use-case tliagraiii, describes the class diagraiii for a. given probleiii? Such fiiid-

iiigs iiiiglit lime soiiie iiiipact oii curreiit object- orieiitetl tlesigii. Heiice, our fut.ure work is t o ex- plore this coiiiiectioii.

References

[ I ] Ali Arstiiijaiii. Graiiiiiiar-orieiited object de- s i p : Cleiit,iiig atla.pt,ive collal,orntioiis a i i t l

tlyiiaiiiic coiifiguratioiis witli self-descril)iiig coiiipoiie1it.s aiid services. 111 Proceedings o j

TOOLS 2001, voluiiie 65. IEEE Coniputer So- ciety Press, 2001.

[2] G. Boocli. Object-O~iented Aiialysis and De- sign ruith Appl&tion,s. 13eIijairiiIi/Cuiiiiiiiiigs, 19'34.

[SI B:~Irett, Bryiliit, ilii(l Bt~uiii-Stiuk Lee. TWO- Irvel g r a i i i i i i i i r as aii objcct-oriciitr:tl rcqiiire- 1iieiit.s specilicatioii laiiguage. I n IEEE CD ROA4 1'r.oceedLrigs vf 35th Huwaii Internci-

/ . l ( J 7 l U ! C~JlLJel'e'Il~:C! 011 S , y S / , C l l l sCiell,fX:S. 2002. [4] 1'. Derililsiilt, h1. J o ~ i I d ~ i , aiid B. LoIIIo. At-

t.ril)ute graiiiiiiars: Defiiiitioiis, systeiris aiid liililiograpliy. voliiiiie 323. Lecture Notes i l l

Coiiipukr Scieiice, Spriiiger-Verlag: 1988. [5] 11. Fowlcr. UhIL U i s t i l l e d . Applyirig the Stan-

diird Object hlodeliriy L ~ i ~ p u g e . Addisoii- Wcs ley Lo i ig i i I a i I ! 1 99 7 .

[Ci] E . Gaiiiiiiti. I t . Heliii. R. .Joliiisoii. i i i i d .I. Vlis- sides. Design P a t t e r r ~ . ~ : Elerireiits of RensoOle O~ject-O,r.iciited Softwure. Adtlisoii-Wesley, 1995.

[7] Jail Heeriiig aiid Paul Iiliiit. Seiiiaiitics of prograiiiriiiiig laiiguages: A tool-orieiited ap- Marcli 2000.

l~roacli. A C M Sipla71 N o t i ~ e s . 35( 3):39-48, [8] Pedro Heiiriques. hlaria Varalida Pereira.,

h4arja.ii h,leriiik, Mitja LeiiiC, Eiiis AvdiCau5eviC, aiid Viljeiii Zuiiier. Auto- iiiat,ic geiieratioii of laiiguage-liased tools.

In Mark vaii deli Brand aiid Ralf Laeiiiiiiel, editors, Electronic Notes i ~ i TILeoiet,ical Corn- p n t e r Scie7ice, voluiiie 65. Elsevier Scieiice Publishers! 2002.

[9] D. Kiiutli. Seriiaritics of coiitext-free law gua.ges. Math. Syst. T t i e o ~ y , 2(2):127-145, 1968.

lo] Keith Levi and Ali Arsaiijaiii. A goal-driven approach t o eiiterprise coiripoiieiit icleiitifica- tiori a i d specification. Corriiri,uii,ications of the ACM. 45( 10):45-52, Oct,ol)er 2002.

l l ] Karl J . Lielierlierr. Adapf;ive Object-Oyiented S V ~ ~ , U J U ~ ~ : The Derrieter Method ,with Propa- gatio,ri Patterns. PWS Publisliiiig Coiiipany, Bostoii, 1996.

[12] h,larjaii Meriiik, Mitja Leiiii., Eiiis AvdiCauSeviC, and Viljeiri Zuirier. LISA:

Aii Iiiteractive Eiivironineiit for Prograin- iiiiiig Language Developiiieiit.. 111 ,.Nigel Horspool, editor, 11 t h Iute~rnotiorLal Con- e o n CorrLpiler Co7i.stvuction. voluirie 2304, pages 1-4. Lecture Notes iii Coiiiputer Scieiice. Spriiiger-Verlag, 2002.

[ 131 h:laria Vararitla Pereira, Marjaii Meriiik, Pe- dro Heiiriques, Toiiiai Kosar, aiid Viljein Zuirier. OI,ject-orieiit,ed attriliute grariiiriar Imied graiiiiiiatical approach t o probleiii specificatioii. Techiiical report, Uiiiversity of h'liiilio. Departiiieiit, of Coiiiputer Science, Braga: 2002.

[ 141 Boris Roussev. Geiieratiiig ocl specificatioiis ai111 class diagraiiis froiii use cases: A iiewt,o-

iiiaii approacli. 111 IEEE C D R O M Proceed-

iriy.s of 30'11i H U w ~ i i Iiil e,inuf.io,riul Co,ri f ere rice

o'ri Systerii Sciences, 2003.

[15] J . Ruiiilmugli: h.1. Blaha, W . Preiiierlaiii, F. Eddy, aiid W . Lorelisen. Object-Oriented Modeling a r i d Design. Preiitice-Hall, 1991, [IS] I. Soiiiiiierville. Soffware E~iyirieerin,y.

Atltlisoii-Wesley, 5th editioii, 1996.

[17] A . vaii Deurseii, P. Kliiit, aiid J. Visscr. Doiiiaiii-Specific Laiiguages: A n Aiino-

tatetl Bil,liogra.pliy. A CM S i g p l w t , Notices, 3 5 ( 6 ) :26-36, 2000.