1: \documentclass{llncs}

2: %

3: \usepackage{epsfig}

4: \usepackage{times}

5: \usepackage{theorem} 

6: \usepackage{graphs}

7: %

8: \usepackage{latexsym}

9: \usepackage{amstext}

10: 

11: %

12: %

13: %

14: %

15: %

16: %

17: %

18: %

19: %

20: %

21: %

22: %

23: 

24: \renewcommand{\topfraction}{0.95}

25: \renewcommand{\dbltopfraction}{0.95}

26: \renewcommand{\bottomfraction}{0.95}

27: \renewcommand{\textfraction}{0.05}

28: 

29: \newlength{\picwidth}

30: \setlength{\picwidth}{8.3cm}

31: 

32: \emergencystretch10pt

33: 

34: %

35: %

36: %

37: %

38: %

39: %

40: %

41: %

42: %

43: 

44: %

45: %

46: \newenvironment{itemizeri}%

47: {\begin{list}{$\bullet$}{

48:    \labelwidth1ex 

49:    \labelsep1ex

50:    \rightmargin0ex

51:    \leftmargin2ex

52:    \listparindent0pt

53:    \itemsep0.2ex

54:    \topsep0.2ex

55:    \parsep0.1ex}}%

56: {\end{list}}

57: 

58: 

59: \unitlength=0.9mm %

60: 

61: \theoremstyle{plain}    %

62: {\theorembodyfont{\rmfamily}

63:         \newtheorem{exxx}{Example}

64: }

65: 

66: \hyphenation{DiaPlan DiaGen Ha-bi-li-ta-tions-schrift}

67: 

68: \begin{document}

69: \bibliographystyle{abbrv}

70: \pagestyle{plain}

71: 

72: %

73: %

74: \title{Towards Rule-Based Visual Programming\\of Generic Visual Systems

75:         \thanks{This work has been partially 

76:                 supported by  the ESPRIT Working Group

77:                 \emph{Applications of Graph Transformation} (\textsc{Appligraph}).

78:                }

79:       }

80: 

81: \author{Berthold Hoffmann\inst{1} \and Mark Minas\inst{2}}

82: \institute{Fachbereich Mathematik/Informatik\\  

83:         Universit\"at Bremen\\  

84:         Postfach 33 04 40,   

85:         28334 Bremen, Germany\\

86:         hof@informatik.uni-bremen.de\\

87:         \and

88:         Lehrstuhl f\"ur Programmiersprachen\\ 

89:            Universit\"at Erlangen-N\"urnberg \\

90:            Martensstr. 3, 

91:            91058 Erlangen, Germany \\

92:         minas@informatik.uni-erlangen.de

93: }

94: 

95: %

96: \maketitle

97: %

98: 

99: %

100: 

101: 

102: %

103: %

104: %

105: 

106: \newcommand{\com}[1]{}

107: \newcommand{\change}[2]{\marginpar{#1} #2}

108: \newcommand{\ALT}[2]{#1}

109: \newcommand{\wzbw}{\hfill $\Box$}

110: 

111: \newcommand{\kw}[1]{\mathbf{#1}}

112: \newcommand{\fg}[1]{\textsf{#1}}

113: 

114: \newcommand{\tup}[1]{\langle #1 \rangle}

115: \renewcommand{\top}[1]{\widehat{#1}}

116: \newcommand{\cut}[1]{\underline{#1}}

117: 

118: \newcommand{\To}{\Rightarrow}

119: \newcommand{\notTo}{\not\Rightarrow}

120: \newcommand{\iso}{\cong}

121: \newcommand{\tuple}[1]{\langle #1 \rangle}

122: \newcommand{\G}{{\cal G}}

123: \newcommand{\E}{{\cal E}}

124: \renewcommand{\H}{{\cal H}}

125: \renewcommand{\L}{{\cal L}}

126: \newcommand{\N}{{\cal N}}

127: \renewcommand{\S}{{\cal S}}

128: \newcommand{\T}{{\cal T}}

129: \newcommand{\allows}{\vdash_{\S}}

130: \newcommand{\att}{\text{att}}

131: \newcommand{\lab}{\text{lab}}

132: \newcommand{\occ}{\text{occ}}

133: \newcommand{\glue}{\mathop{\!\not\!\circ\:}}

134: \newcommand{\guard}{\mathop{[\!]}}

135: \newcommand{\others}{\mathop{/\!\!/}}

136: 

137: 

138: %

139: %

140: %

141:   \graphnodesize{2} \graphnodecolour{1}         %

142:   \graphlinewidth{0.2} \grapharrowlength{1.5}   %

143:   \grapharrowwidth{0.8}  \grapharrowtype{1}     %

144:   \enlargeboxes{2} \autodistance{0.6}           %

145: 

146: %

147: %

148: %

149: \newcommand{\node}[3]%

150:   {\roundnode{#1}(#2,#3)}

151: 

152: \newcommand{\Node}[3]%

153:   {\roundnode{#1}(#2,#3)[\graphlinewidth{0.5}]}

154: 

155: \newcommand{\nnode}[5]%

156:   {\roundnode{#1}(#2,#3)\autonodetext{#1}[#4]{\small #5}}

157: 

158: \newcommand{\nnnode}[5]%

159: %

160:   {\roundnode{#1}(#2,#3)\autonodetext{#1}[n]{\small #4}

161:    \autonodetext{#1}[s]{\small #5}}

162: 

163: \newcommand{\point}[3]%

164:   {\roundnode{#1}(#2,#3)[\graphnodecolour{0}]}

165: 

166: \newcommand{\npoint}[5]%

167:   {\roundnode{#1}(#2,#3)[\graphnodecolour{0}]\autonodetext{#1}[#4]{\small #5}}

168: 

169: \newcommand{\nnpoint}[5]%

170:   {\roundnode{#1}(#2,#3)[\graphnodecolour{0}]\autonodetext{#1}[n]{\small #4}

171:    \autonodetext{#1}[s]{\small #5}}

172: 

173: \newcommand{\hiddennode}[3]%

174:   {\roundnode{#1}(#2,#3)[\graphnodesize{0}\opaquetextfalse]}

175: 

176: %

177: %

178: %

179: \newcommand{\smalledge}[4]%

180:   {\rectnode{#1}[4,4](#2,#3) \autonodetext{#1}{\footnotesize \fg{#4}}}

181: 

182: \newcommand{\Smalledge}[4]%

183:   {\rectnode{#1}[4,4](#2,#3)[\graphlinewidth{0.5}]

184:    \autonodetext{#1}{\footnotesize \fg{#4}}}

185: 

186: \newcommand{\var}[4]%

187:   {\rectnode{#1}[6,6](#2,#3) \autonodetext{#1}{\small $#4$}}

188: 

189: \newcommand{\typ}[4]%

190:   {\rectnode{#1}[6,6](#2,#3) \autonodetext{#1}{\footnotesize \fg{#4}}}

191: 

192: \newcommand{\framevar}[4]%

193:   {\rectnode{#1}[6,6](#2,#3) \autonodetext{#1}{$#4$}}

194: %

195: %

196: %

197: %

198: %

199: 

200: \newcommand{\Iframe}[6]%

201:   {\rectnode{#1}[#2,#3](#4,#5)[\graphnodecolour{0.7}] \autonodetext{#1}{#6}}

202: 

203: \newcommand{\Qframe}[6]%

204:   {\rectnode{#1}[#2,#3](#4,#5)[\graphnodecolour{0.85}]

205:         \autonodetext{#1}{\begin{graph}#6 \end{graph}}}

206: 

207: \newcommand{\button}[4]

208:   {\rectnode{#1}[14,5](#2,#3)[\graphnodecolour{1}\graphlinecolour{1}]

209:    \freetext(#2,#3){\begin{picture}(0,0)

210:                     \put(0,0){\oval(14,5)}\end{picture}}[\opaquetextfalse]

211:    \autonodetext{#1}{\makebox(0,0){\scriptsize \sf #4}}}

212: 

213: \newcommand{\buttonvar}[4]

214:   {\rectnode{#1}[7,5](#2,#3)[\graphnodecolour{1}\graphlinecolour{1}]

215:    \freetext(#2,#3){\begin{picture}(0,0)

216:                     \put(0,0){\oval(7,5)}\end{picture}}[\opaquetextfalse]

217:    \autonodetext{#1}{\makebox(0,0){\footnotesize $#4$}}}

218: 

219: \newcommand{\parbuttonvar}[4]

220:   {\rectnode{#1}[7,5](#2,#3)[\graphnodecolour{1}\graphlinecolour{0}]

221:    \freetext(#2,#3){\begin{picture}(0,0)

222:                     \put(0,0){\oval(6.8,4.8)}

223:                     \put(0,0){\makebox(0,0){\footnotesize $#4$}}

224:                     \end{picture}}[\opaquetextfalse]

225: %

226:    }

227: 

228: \newcommand{\parbutton}[4]

229:   {\rectnode{#1}[14,5](#2,#3)[\graphnodecolour{1}\graphlinecolour{0}]

230:    \freetext(#2,#3){\begin{picture}(0,0)

231:                     \put(0,0){\oval(13.9,4.8)}

232:                     \put(0,0){\makebox(0,0){\scriptsize \sf #4}}

233:                     \end{picture}}[\opaquetextfalse]

234: %

235:    }

236: 

237: %

238: %

239: %

240: \newcommand{\Edge}[2]%

241:   {\edge{#1}{#2}[\graphlinewidth{0.5}]}

242: 

243: \newcommand{\Bow}[3]%

244:   {\bow{#1}{#2}{#3}[\graphlinewidth{0.5}]}

245: 

246: %

247: %

248: 

249: \newcommand{\metaedge}[2]

250:   {\edge{#1}{#2}[\graphlinewidth{0.6}]\edge{#1}{#2}[\graphlinecolour{1}]}

251: 

252: \newcommand{\metabow}[3]

253:   {\bow{#1}{#2}{#3}[\graphlinewidth{0.6}]\bow{#1}{#2}{#3}[\graphlinecolour{1}]}

254: 

255: %

256: %

257: %

258: \newcommand{\ItemI}{%

259: \begin{graph}(7,7)(-3.5,-3.5)

260:   \node{0}{2.5}{0} \edge{0}{1} \edge{0}{2} \edge{0}{3}

261:   \node{1}{0}{-2} \edge{1}{3}

262:   \node{2}{0}{+2} \edge{2}{3}

263:   \point{3}{-2.5}{0}

264: \end{graph}%

265: }

266: 

267: \newcommand{\ItemII}{%

268: \begin{graph}(7,7)(-3.5,-3.5)

269:   \point{0}{2.5}{0} \edge{0}{1} \bow{0}{1}{-0.3} \bow{0}{1}{+0.3}

270:   \point{1}{-2.5}{0}

271: \end{graph}%

272: }

273: 

274: \newcommand{\ItemIII}{%

275: \begin{graph}(7,7)(-3.5,-3.5)

276:   \node{0}{2}{0} \edge{0}{1} \edge{0}{2} 

277:   \node{1}{-1.5}{-2} \edge{1}{2}

278:   \node{2}{-1.5}{+2} 

279: \end{graph}%

280: }

281: 

282: %

283: %

284: %

285: 

286: \newcommand{\Garrow}[3]%

287: %

288: {\begin{picture}(#1,#2) \put(0,0){\makebox(#1,#2){$#3$}}\end{picture}}

289: 

290: \newcommand{\Graephchen}[3]%

291: %

292: {\begin{picture}(#1,#2) \put(0,0){\makebox(#1,#2){#3}}\end{picture}}

293: 

294: \newcommand{\BILD}[3] 

295: %

296: {\begin{picture}(#1,#2) \put(0,0){\makebox(#1,#2){#3}}\end{picture}}

297: 

298: \newcommand{\DEF}[1] %

299: {\BILD{7}{#1}{::=}}

300: 

301: \newcommand{\OR}[1] %

302: {\BILD{3}{#1}{$\mid$}}

303: 

304: \newcommand{\IF}[1] %

305: {\BILD{3}{#1}{$[\!]$}}

306: 

307: \newcommand{\TO}[1] %

308: {\BILD{5}{#1}{$\to$}}

309: 

310: \newcommand{\TRANS}[1] %

311: {\BILD{7}{#1}{$\To$}}

312: 

313: \newcommand{\OUT}[2] %

314: {\BILD{10}{#2}{$\others \; #1$}}

315: 

316: \newcommand{\RULE}[3] %

317:   {\centering\begin{tabular}{ccc}

318:   #1 & \TO{#3} & #2 

319:   \end{tabular}}

320: 

321: \newcommand{\CONDITIONAL}[4] %

322:   {\centering\begin{tabular}{ccccc}

323:   #1 & \IF{#4} & #2 & \TO{#4} & #3 

324:   \end{tabular}}

325: 

326: \newcommand{\STEP}[3] %

327:   {\centering\begin{tabular}{ccc}

328:   #1 & \TRANS{#3} & #2 

329:   \end{tabular}}

330: 

331: \newcommand{\STEPS}[4] %

332:   {\centering\begin{tabular}{ccccc}

333:   #1 & \TRANS{#4} & #2 & \TRANS{#4} & #3 

334:   \end{tabular}}

335: 

336: \newcommand{\THREESTEPS}[5] %

337:   {\centering\begin{tabular}{ccccccc}

338:   #1 & \TRANS{#5} & #2 & \TRANS{#5} & #3 & \TRANS{#5} & #4

339:   \end{tabular}}

340: 

341: \newcommand{\PROC}[5]%

342:   {\begin{tabular}{@{}cccc@{}}

343: %

344: %

345: %

346:   #2 & \TO{#5} & #3 & \OUT{#4}{#5}

347:   \end{tabular}}

348: 

349: \newcommand{\CONPROC}[6]%

350:   %

351:   {\begin{tabular}{@{}cccccc}

352: %

353: %

354: %

355:    #2 & \IF{#6} & #3 & \TO{#6} & #4 & \OUT{#5}{#6}

356:   \end{tabular}}

357: 

358: \newcommand{\TYPE}[4] %

359:   {\centering\begin{tabular}{@{}c@{}c@{}c@{}c@{}c@{}}

360:   #1 & \DEF{#4} & #2 & \OR{#4} & #3 

361:   \end{tabular}}

362: 

363: \newcommand{\SIGN}[3] %

364:   {\centering\begin{tabular}{ccc}

365:   #1 & \DEF{#3} & #2  

366:   \end{tabular}}

367: 

368: \newcommand{\TYPES}[6] %

369:   {\centering\begin{tabular}{@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}}

370:   #1 & \DEF{#6} 

371:      & #2 & \OR{#6} 

372:      & #3 & \OR{#6} 

373:      & #4 & \OR{#6} 

374:      & \BILD{17}{#6}{{\Large #5}}

375:   \end{tabular}}

376: 

377: \newcommand{\Gtrans}[6]%

378:   %

379:   {\centering\begin{tabular}{ccc}

380:   #1 & \Garrow{5}{#3}{\to} & #2  \\[2mm]

381:   $\downarrow$ & & $\downarrow$ \\[2mm]

382:   #4 & \Garrow{5}{#6}{\To} & #5 

383:   \end{tabular}}

384: 

385: %

386: %

387: %

388: 

389: \begin{abstract}

390: %

391: %

392: %

393: %

394: %

395: %

396: %

397: %

398: %

399: %

400: 

401:   This paper illustrates how the \emph{diagram programming language}

402:   \textsc{DiaPlan} can be used to program visual systems.

403:   \textsc{DiaPlan} is a visual rule-based language that is founded

404:   on the computational model of graph transformation.  

405:   The language supports \emph{object-oriented programming}

406:   since its graphs are hierarchically structured.

407:   \emph{Typing} allows the shape of these graphs to be specified recursively

408:   in order to increase program security. 

409:   Thanks to its \emph{genericity}, \textsc{DiaPlan}

410:   allows to implement systems that represent and manipulate data

411:   in arbitrary diagram notations. 

412:   The environment for the language exploits the diagram editor generator

413:   \textsc{DiaGen} for providing genericity, 

414:   and for implementing its user interface and type checker.

415: \end{abstract}

416: %

417: 

418: 

419: %

420: \section{Introduction}\label{sec:intro}

421: %

422: 

423: Many data structures can be represented by graphs, 

424: and the theory of graph transformation~\cite{Rozenberg:97}

425: provides a profound computational model for rule-based programming with graphs.

426: As graphs are inherently visual, and have been used as an abstract model for

427: visual representations~\cite{Bardohl:98,Erwig-Meyer:95,Minas:00},

428: graph transformation could become widely accepted as a paradigm of 

429: \emph{rule-based visual programming}. 

430: 

431: %

432: %

433: %

434: %

435: 

436: However, existing programming languages based on graph transformation, such

437: as {\sc Progres}~\cite{Schuerr-Winter-Zuendorf:99} or

438: $\textsc{Ludwig}_2$~\cite{Pfeiffer:95}, have not been as successful as one

439: could expect. We believe that this has two major reasons:

440: \begin{itemizeri}

441: \item The \emph{structuring} of graphs as nested graph objects, and thus

442:   \emph{object-oriented programming} are not supported.

443: \item It is not possible to \emph{customize} the ``standard'' graph

444:   notation to the visual notation of particular application domains.

445: \end{itemizeri}

446: 

447: However, some approaches to these problems exist for visual environments

448: which are not based on graphs: Object-oriented programming languages have

449: been developed in the visual programming community~\cite{VOOP:94}, notably

450: \emph{Prograph}~\cite{Prograph}. Furthermore, there are visual language

451: tools which allow to use domain-specific visual representations, e.g.,

452: \textsc{Calypso}, a tool for visually defining data structures

453: of programs~\cite{Wodtli-Cull:97}. However, we are not aware of any language

454: or tool that allows to \emph{visually specify} and \emph{generate} 

455: %

456: visual language environments which then use domain-specific visual

457: representations.

458: 

459: This paper is about \textsc{DiaPlan},  

460: %

461: a visual, rule-based programming language and environment for implementing visual languages, which offers just these features. 

462: %

463: The \textsc{DiaPlan} programming environment consists of

464: \begin{itemizeri}

465: \item a visual programming language which supports graph typing and

466:   structuring as well as object-oriented programming for specifying graph

467:   transformations. These rules specify the behavior of the generated

468:   visual language.

469: \item a tool for specifying how graphs are represented by domain-specific

470:   diagrams in the generated visual language and how the user can interact

471:   with these diagrams. This makes \textsc{DiaPlan} a \emph{generic}

472:   environment.

473: \end{itemizeri}

474: 

475: The paper is organized as follows: Section~\ref{s:hgratra} describes graph

476: transformation, the computational model of the language. Concepts for

477: programming are illustrated in Section~\ref{s:control}, and typing is

478: discussed in Section~\ref{s:typing}. A complete example of a

479: \textsc{DiaPlan} program for solving graph coloring problems is discussed

480: in Section~\ref{s:example}. Section~\ref{s:diagrams} recalls how graphs can

481: be visualized in arbitrary diagram notations. Genericity of the language is

482: based on this feature.

483: %

484: In Section~\ref{s:implementation} we describe how the language can be

485: implemented. We conclude in Section~\ref{s:conclusion} with some remarks on

486: related and future work.

487: 

488: Due to space limitations, our presentation can only be informal.

489: We explain the concepts by a running example

490: concerned with the visual representation of lists and 

491: the implementation of list operations.

492: 

493: 

494: %

495: \section{The Computational Model}\label{s:hgratra}

496: %

497: 

498: We introduce a rather general notion of graphs, and a rather simple way of applying rules to them.

499: 

500: 

501: %

502: \subsection{Graphs}\label{ss:hgraphs} 

503: \begin{figure*}[b] %

504: \newcommand{\GE}

505: {\begin{framegraph}(38,25)(-2,-17.5)

506:   \node{h}{0}{0} \edge{h}{B} 

507:   \Qframe{B}{18}{12}{16}{0}{(17,11)(3.5,-5.5)

508:           \point{v0}{5}{0} \edge{v0}{Q} 

509:           \Iframe{Q}{8.5}{8.5}{12}{0}{\ItemII}

510:           \point{v1}{19}{0} \edge{v1}{Q}

511:           }  \edge{B}{t}

512:   \node{t}{32}{0}  

513:   \node{v4}{0}{-12} \edge{v4}{X} \edge{v4}{h}

514:   \Iframe{X}{8.5}{8.5}{8}{-12}{\ItemIII}

515:   \node{v5}{16}{-12} \edge{v5}{X} \edge{v5}{Y}

516:   \Iframe{Y}{8.5}{8.5}{24}{-12}{\ItemI}

517:   \node{v7}{32}{-12} \edge{v7}{Y} \edge{v7}{t}

518: \end{framegraph}

519: }

520: \newcommand{\HE}

521: {\begin{framegraph}(44,25)(-2,-17.5)

522:   \node{h}{0}{0} \edge{h}{B}

523:   \Qframe{B}{34}{12}{20}{0}{(33,11)(3.5,-5.5) 

524:           \point{v0}{5}{0} \edge{v0}{G1} 

525:           \Iframe{G1}{8.5}{8.5}{12}{0}{\ItemII}

526:           \node{v1}{20}{0} \edge{v1}{G2} \edge{v1}{G1} 

527:           \Iframe{G2}{8.5}{8.5}{28}{0}{\ItemIII} 

528:           \point{v2}{35}{0} \edge{v2}{G2}

529:           } \edge{B}{t} 

530:   \node{t}{40}{0}

531:   \node{v4}{0}{-12} \edge{v4}{X} \edge{v4}{h}

532:   \Iframe{X}{8.5}{8.5}{10}{-12}{\ItemIII}

533:   \node{v5}{20}{-12} \edge{v5}{X} \edge{v5}{Y}

534:   \Iframe{Y}{8.5}{8.5}{30}{-12}{\ItemI}

535:   \node{v7}{40}{-12} \edge{v7}{Y} \edge{v7}{t}

536: \end{framegraph}

537: }

538: \newcommand{\GD}

539: {\begin{graph}(48,23) \end{graph}

540: }

541: \newcommand{\HD}

542: {\begin{framegraph}(38,25)(-2,-17.5)

543:   \node{h}{0}{0} \edge{h}{B}

544:   \Qframe{B}{19}{12}{16}{0}{(18,11)(11,-5.5)

545:           \point{v0}{13}{0} \edge{v0}{G2} 

546:           \Iframe{G2}{8.5}{8.5}{20}{0}{\ItemIII} 

547:           \point{v2}{27}{0} \edge{v2}{G2}

548:           } \edge{B}{t} 

549:   \node{t}{32}{0}  

550:   \node{v4}{0}{-12} \edge{v4}{X} \edge{v4}{h}

551:   \Iframe{X}{8.5}{8.5}{8}{-12}{\ItemIII}

552:   \node{v5}{16}{-12} \edge{v5}{X} \edge{v5}{Y}

553:   \Iframe{Y}{8.5}{8.5}{24}{-12}{\ItemI}

554:   \node{v7}{32}{-12} \edge{v7}{Y} \edge{v7}{t}

555: \end{framegraph}

556: }

557: \STEPS{\GE}{\HE}{\HD}{25} %

558: %

559: \caption{Two transformation steps on list graphs}%

560: \label{f:enq-deq-steps}

561: \end{figure*}%

562: 

563: \emph{Graphs} represent relations between entities as \emph{edges} between

564: \emph{nodes}. Usually, the edges link two nodes of a graph, and represent

565: binary relations. We, however, allow edges that link \emph{any number} of

566: nodes, and distinguish different \emph{types} of edges by labeling them so

567: that different relations, of any arity, can be represented in a single

568: graph.  We also distinguish a sequence of nodes as the \emph{points} at which a graph may be connected to other graphs. 

569: Such graphs are known as \emph{pointed hypergraphs}~\cite{Drewes-Habel-Kreowski:97}.

570: 

571: Usually, graphs are \emph{flat}: Their nodes and edges are primitive; none

572: of them may contain a nested graph.  

573: We, however, distinguish a subset of the edges in a graph $H$ as \emph{frames}: Every frame $f$ \emph{contains} a nested subgraph $H_f$ that may contain frames again. 

574: These graphs are called \emph{hierarchical} in~\cite{Drewes-Hoffmann-Plump:00}.

575: 

576: %

577: \begin{exxx}[List Graphs]

578: \label{x:hlist}%

579: The three graphs in Figure~\ref{f:enq-deq-steps} show how we represent

580: lists as graphs: A \emph{list} frame (light gray boxes) is linked to the

581: start and end node of a chain of item frames (dark gray boxes); every

582: \emph{item} frame contains an \emph{item graph}.

583:  

584: Nodes are drawn as circles, and filled if they are points.  Edges are drawn

585: as boxes around their label, and are connected to their attachments by

586: lines that are ordered counter-clockwise, starting at noon.  The boxes for

587: binary edges with empty labels ``disappear'' so that they are drawn as

588: lines from their first to their second linked node.  Frames are boxes (like

589: ordinary edges), with their contents drawn inside; we distinguish list and

590: item frames by different shades of grey, and omit their labels. The graphs

591: in Figure~\ref{f:enq-deq-steps} contain two item frames, and a list frame

592: that contains one or two item frames.

593: %

594: %

595: %

596: \wzbw\end{exxx}

597: %

598: 

599: This representation \emph{forbids} edges across frame boundaries (which other notions of hierarchical graphs~\cite{Pratt:71,Engels-Schuerr:95} allow). 

600: Only then graphs can be transformed in a modular way. 

601: However, the correspondence between the links of a frame and the points of its contents may induce an \emph{indirect relation} between the contents and the context of that frame. 

602: The links of the list frames in Figure~\ref{f:enq-deq-steps} are related to the points of their contents in that way.

603: 

604: 

605: %

606: \subsection{Computation}\label{ss:rules}

607: In the graphs occurring in computation rules, a distinguished set $X$ of

608: \emph{variable names} is used to label \emph{variable edges}

609: (\emph{variables} for short). 

610: A \emph{substitution} $\sigma $ maps variables names $X_1, \ldots, X_n$ onto graphs $G_1, \ldots, G_n$.

611: 

612: The \emph{instantiation} $G\sigma$ of a graph $G$ by some substitution

613: $\sigma$ is obtained by identifiying the points of a fresh copy of $\sigma(X_i)$

614: with the corresponding attachments of every $X_i$-edge in $G$, and removing

615: the edge afterwards. 

616: 

617: A graph $C[\,]$ is called a \emph{context} if it contains a single variable (a \emph{hole}). 

618: We write $C[G]$ for the instantiation of the hole in $C[\,]$ by some graph $G$.

619: 

620: A \emph{graph transformation rule} (\emph{rule}, for short) $t: P \to R$

621: consists of a \emph{pattern} $P$ and a \emph{replacement} $R$, where $P$

622: and $R$ are graphs such that the following holds:

623: \begin{itemize}

624: \item Every variable name occurring in $R$ occurs in $P$ as well.

625: \item Every variable name occurs at most once in $P$.

626: \end{itemize}

627: 

628: A rule $t: P \to R$ \emph{transforms} some host graph $G$ into a modified

629: graph $H$, written $G \To_t H$, if there is a context $C[\,]$ and a

630: substitution $\sigma$ such that $G \iso C[P\sigma]$ and $H \iso

631: C[R\sigma]$. 

632: \footnote{We write $G \iso H$ if two graphs $G$ and $H$ are isomorphic, i.e.~equal up to the identity of their nodes and edges.}

633: 

634: A transformation step can be constructed by \emph{graph

635:   matching} (defined in~\cite{Plump-Habel:96} for flat graphs). 

636: The matching algorithm can be lifted to the hierarchical case along the lines of~\cite{Drewes-Hoffmann-Plump:00}.

637:  

638: 

639: %

640: \begin{exxx}[List Graph Transformation]%

641: \label{x:enremove} 

642: The rules in Figure~\ref{f:enq-deq-hrules} specify two operations on list graphs, which are used in the transformation steps shown in Figure~\ref{f:enq-deq-steps}.

643: (Variable names appear in italics.)

644: \begin{figure*}[bt] %

645: \newcommand{\PE}

646: {\begin{framegraph}(26,20)(-2,-14)

647:   \point{h}{0}{0} \edge{h}{B} 

648:   \Qframe{B}{16}{10}{11}{0}{(16,10)(4,-5)

649:           \point{v0}{6}{0} \edge{v0}{Q} 

650:           \var{Q}{12}{0}{L}

651:           \point{v1}{18}{0} \edge{v1}{Q}

652:           }  \edge{B}{t}

653:   \point{t}{22}{0}  

654:   \point{v4}{5}{-10} \edge{v4}{X} 

655:   \framevar{X}{11}{-10}{X}

656:   \point{v5}{17}{-10} \edge{v5}{X} 

657: \end{framegraph}

658: }

659: \newcommand{\RE}

660: {\begin{framegraph}(38,20)(-2,-14)

661:   \point{h}{0}{0} \edge{h}{B}

662:   \Qframe{B}{28}{10}{17}{0}{(28,10)(4,-5) 

663:           \point{v0}{6}{0} \edge{v0}{G1} 

664:           \var{G1}{12}{0}{L}

665:           \node{v1}{18}{0} \edge{v1}{G2} \edge{v1}{G1} 

666:           \framevar{G2}{24}{0}{X} 

667:           \point{v2}{30}{0} \edge{v2}{G2}

668:           } 

669:   \edge{B}{t} 

670:   \point{t}{34}{0}

671: 

672:   \point{v4}{11}{-10} \edge{v4}{X} 

673:   \framevar{X}{17}{-10}{X}

674:   \point{v5}{23}{-10} \edge{v5}{X} 

675: \end{framegraph}

676: }

677: \newcommand{\PD}

678: {\begin{framegraph}(38,12)(-2,-6)

679:   \point{h}{0}{0} \edge{h}{B}

680:   \Qframe{B}{28}{10}{17}{0}{(28,10)(4,-5) 

681:           \point{v0}{6}{0} \edge{v0}{G1} 

682:           \framevar{G1}{12}{0}{X}

683:           \node{v1}{18}{0} \edge{v1}{G2} \edge{v1}{G1} 

684:           \var{G2}{24}{0}{L} 

685:           \point{v2}{30}{0} \edge{v2}{G2}

686:           } 

687:   \edge{B}{t} 

688:   \point{t}{34}{0}

689: \end{framegraph}

690: }

691: \newcommand{\RD}

692: {\begin{framegraph}(26,12)(-2,-6)

693:   \point{h}{0}{0} \edge{h}{B}

694:   \Qframe{B}{16}{10}{11}{0}{(16,10)(4,-5) 

695:           \point{v0}{6}{0} \edge{v0}{G1} 

696:           \var{G1}{12}{0}{L}

697:           \point{v1}{18}{0} \edge{v1}{G1} 

698:           } 

699:   \edge{B}{t} 

700:   \point{t}{22}{0}

701: \end{framegraph}

702: }

703: \RULE{\PE}{\RE}{20}

704: \hspace{1cm} %

705: \RULE{\PD}{\RD}{12}

706: \caption{Two rules specifying operations on list graphs}%

707: \label{f:enq-deq-hrules}

708: \end{figure*}%

709: 

710: The first step (using the rule on the left) \emph{enters} a copy of an item frame $X$ at the end of a list graph $L$, and the second step (using the rule on the right) \emph{removes} the first item frame from a list graph.

711: \wzbw\end{exxx} %

712: 

713: \emph{Graph transformation} with a set $\T$ of graph transformation rules

714: considers sequences of sequential transformation steps in arbitrary order,

715: and of arbitrary length.

716: 

717: By taking arbitrary graphs as input, and transforming them as long as

718: possible, graph transformation computes a \emph{function} on graphs. 

719: This function is \emph{partial} if certain graphs can be transformed infinitely, and \emph{nondeterministic} if a graph may be transformed in different ways.

720: 

721: 

722: %

723: \section{Programming}\label{s:control}

724: %

725: 

726: The computational model presented in Section~\ref{s:hgratra}

727: is extended by concepts for abstraction, control, and encapsulation.

728: This section gives only a brief account of these programming concepts. 

729: See~\cite{Hoffmann:00} for more motivation and details.

730: 

731: 

732: %

733: \subsection{Abstraction}

734: 

735: We consider certain labels as \emph{predicate names}.

736: An edge labeled by a predicate name is depicted as an oval. 

737: A \emph{predicate} named $p$ is defined by a set of rules wherein every pattern contains exactly one $p$-edge, and every replacement may contain other predicate edges. 

738: A predicate $p$ is \emph{applied} by applying one of its rules to a $p$-edge in the host graph.  

739: A predicate is \emph{evaluated} by first applying one of its rules, and evaluating all predicates that are called in its replacement, recursively.

740: 

741: The links of a predicate edge indicate the \emph{parameters} of a predicate. 

742: A parameter can be just a \emph{node}, but also an \emph{edge}. 

743: In particular, this edge can be a frame that contains a \emph{graph parameter}

744: (as in Example~\ref{x:removeproc} below), or a predicate edge that denotes a

745: \emph{predicate parameter} (as in Example~\ref{x:combinators} below). 

746: 

747: The rule set of a predicate may contain an \emph{otherwise} definition (starting with a ``$\others$'' symbol) that applies when no rule of the predicate is applicable.

748: In  Example~\ref{x:removeproc}, a ``--'' in the otherwise definition signals \emph{failure} of the predicate, and triggers backtracking, and in Example~\ref{x:combinators}, a ``+'' signals \emph{success} of the predicate, so that evaluation continues.

749: (A ``$\bot$'' can be used to raise an \emph{exception} that is either caught elsewhere, or leads to program abortion).

750: 

751: In any case, predicate edges are always removed during the transformation because

752: they are meta edges that are just introduced to control the program's

753: evaluation, and are not meant to occur in its result.

754:  

755: %

756: \begin{exxx}[A Predicate]\label{x:removeproc}

757: Figure~\ref{f:removeproc} shows the definition of a predicate \fg{remove}.

758: %

759: \begin{figure}[ht] %

760: \newcommand{\PD}

761: {\begin{framegraph}(38,21.5)(-2,-6.5)

762:   \button{D}{17}{11}{remove} \metaedge{D}{B}

763:   \point{h}{0}{0} \edge{h}{B}

764:   \Qframe{B}{28}{10}{17}{0}{(28,10)(4,-5) 

765:           \point{v0}{6}{0} \edge{v0}{G1} 

766:           \framevar{G1}{12}{0}{X}

767:           \node{v1}{18}{0} \edge{v1}{G2} \edge{v1}{G1} 

768:           \var{G2}{24}{0}{L} 

769:           \point{v2}{30}{0} \edge{v2}{G2}

770:           } 

771:   \edge{B}{t} 

772:   \point{t}{34}{0}

773: \end{framegraph}

774: }

775: \newcommand{\RD}

776: {\begin{framegraph}(26,21.5)(-2,-6.5)

777:   \point{h}{0}{0} \edge{h}{B}

778:   \Qframe{B}{16}{10}{11}{0}{(16,10)(4,-5) 

779:           \point{v0}{6}{0} \edge{v0}{G1} 

780:           \var{G1}{12}{0}{L}

781:           \point{v1}{18}{0} \edge{v1}{G1} 

782:           } 

783:   \edge{B}{t} 

784:   \point{t}{22}{0}

785: \end{framegraph}

786: }

787: \centering

788: \PROC{\fg{remove}}{\PD}{\RD}{-}{13}

789: \caption{The predicate \fg{remove}}%

790: \label{f:removeproc}

791: \end{figure}%

792: The predicate is parameterized by a frame (which should contain a list graph).

793: It is defined by a single rule (which appeared on the right in Figure~\ref{x:enremove}).

794: Its otherwise definition ``$\others -$'' leads to failure if it is applied to an empty list graph.

795: 

796: %

797: Note that the predicate \emph{updates} a list graph, as in imperative or object-oriented programming.

798: However, it would be possible to define a ``functional'' version of \fg{remove} that constructs a new list frame as a result, and leaves the input frame unchanged.

799: Such a predicate would need more space as subgraphs have to be copied (as in functional languages).

800: \wzbw\end{exxx} %

801: 

802: 

803: %

804: \subsection{Control}

805: 

806: Program evaluation is nondeterministic since predicates can be applied in arbitrary order, also concurrently.

807: We introduce \emph{conditional rules} by which an evaluation order for predicates can be specified. 

808: Such a rule has the form $t: P \guard A \to R$ where the graph $A$ is an \emph{application condition}  (or \emph{premise}).

809: It is applied to a graph $G$ as follows: 

810: If $G \iso C[P\sigma]$, the graph $C=G[(A \oplus R)\sigma]$ is constructed,

811: where $A \oplus R$ is the union of $A$ and $R$ that identifies only their

812: corresponding points. 

813: If all predicate edges of $A\sigma$ in $C$ can be evaluated, yielding a graph $H$, $t$ is applicable, and its application yields $H$; otherwise, the rule is not applicable, and $G$ is left unchanged.

814: (Note that the evaluation of $A\sigma$ may thus modify the host graph. 

815:           This effect is used in Example~\ref{x:combinators}.)

816: 

817: Predicates provide some simple control mechanisms:

818: Pattern matching and otherwise definitions allow for case distinction; applicability conditions specify an application order for predicates.

819: 

820: We also allow that predicates are parameterized by predicates.

821: This allows control to be specified by \emph{combinators} like in functional languages.

822: %

823: 

824: %

825: \begin{exxx}[Control Combinators]\label{x:combinators} 

826:   Figure~\ref{f:combinators} shows a predicate \fg{normalize} that

827:   applies to a predicate denoted by the variable $T$,

828:   evaluates $T$ as an application condition, and, if that succeeds, calls

829:   itself recursively.

830: 

831:   As $T$ shall bind to predicate calls with any number of parameters, we

832:   use the dot notation to indicate that $T$ links to a varying number of

833:   nodes.

834: %

835:   Where the $T$-edge is used as a predicate parameter, it is

836:   \emph{disguised} as an ordinary edge by drawing a box around the oval.

837:   This prevents it from evaluation as long as it is ``carried around'' (in the

838:   pattern and replacement graph of the rule).

839: 

840: \begin{figure}[th] %

841: \newcommand{\PN}

842: {\begin{framegraph}(16,22)(-2,0)

843:   \button{N}{6}{18}{normalize} \metaedge{N}{Q}

844:   \parbuttonvar{Q}{6}{9}{T}

845:   \edge{Q}{1} \edge{Q}{k}

846:   \hiddennode{d}{6}{4} \autonodetext{d}{\ldots}

847:   \point{1}{2}{2}

848:   \hiddennode{d2}{6}{2} \autonodetext{d2}{\ldots}

849:   \point{k}{10}{2}

850: \end{framegraph}

851: }

852: \newcommand{\AN}

853: {\begin{framegraph}(12,22)

854:   \buttonvar{Q}{6}{9}{T} \edge{Q}{1} \edge{Q}{k}

855:   \hiddennode{d}{6}{4} \autonodetext{d}{\ldots}[\opaquetextfalse]

856:   \point{1}{2}{2}

857:   \hiddennode{d2}{6}{2} \autonodetext{d2}{\ldots}[\opaquetextfalse]

858:   \point{k}{10}{2}

859: \end{framegraph}

860: }

861: \centering

862: \CONPROC{\fg{normalize}}{\PN}{\AN}{\PN}{+}{22}

863: \caption{The control combinator \fg{normalize}}%

864: \label{f:combinators}

865: \end{figure}%

866: 

867: \begin{figure*}[bt] %

868: \newcommand{\Neins}

869: {\begin{framegraph}(44,31)(-2,-7.5)

870:   \button{N}{20}{20}{normalize} \metaedge{D}{N}

871:   \parbutton{D}{20}{12}{remove} \metaedge{D}{B}

872:   \node{h}{0}{0} \edge{h}{B}

873:   \Qframe{B}{34}{12}{20}{0}{(33,11)(3.5,-5.5) 

874:           \point{v0}{5}{0} \edge{v0}{G1} 

875:           \Iframe{G1}{8.5}{8.5}{12}{0}{\ItemII}

876:           \node{v1}{20}{0} \edge{v1}{G2} \edge{v1}{G1} 

877:           \Iframe{G2}{8.5}{8.5}{28}{0}{\ItemIII} 

878:           \point{v2}{35}{0} \edge{v2}{G2}

879:           } 

880:   \edge{B}{t} 

881:   \node{t}{40}{0}

882: %

883: %

884: %

885: %

886: \end{framegraph}

887: }

888: \newcommand{\Nzwei}

889: {\begin{framegraph}(28,31)(-2,-7.5)

890:   \button{N}{12}{20}{normalize} \metaedge{D}{N}

891:   \parbutton{D}{12}{12}{remove} \metaedge{D}{B}

892:   \node{h}{0}{0} \edge{h}{B}

893:   \Qframe{B}{18}{12}{12}{0}{(17,11)(11.5,-5.5) 

894:           \point{v0}{13}{0} \edge{v0}{G2} 

895:           \Iframe{G2}{8.5}{8.5}{20}{0}{\ItemIII} 

896:           \point{v2}{27}{0} \edge{v2}{G2}

897:           } 

898:   \edge{B}{t} 

899:   \node{t}{24}{0}

900: \end{framegraph}

901: }

902: \newcommand{\Ndrei}

903: {\begin{framegraph}(20,31)(2,-7.5)

904:   \button{N}{12}{20}{normalize} \metaedge{D}{N}

905:   \parbutton{D}{12}{12}{remove} \metaedge{D}{B}

906:   \node{h}{4}{0} \edge{h}{B}

907:   \Qframe{B}{8}{6}{12}{0}{(8,6)(-4,-3) 

908:           \point{v0}{0}{0} \autonodetext{v0}[w]{$1$}\autonodetext{v0}[e]{$2$}  

909:           } 

910:   \edge{B}{t} 

911:   \node{t}{20}{0}

912: \end{framegraph}

913: }

914: \newcommand{\Nvier}

915: {\begin{framegraph}(20,15)(2,-7.5)

916:   \node{h}{4}{0} \edge{h}{B}

917:   \Qframe{B}{8}{6}{12}{0}{(8,6)(-4,-3) 

918:           \point{v0}{0}{0} \autonodetext{v0}[w]{$1$}\autonodetext{v0}[e]{$2$}  

919:           } 

920:   \edge{B}{t} 

921:   \node{t}{20}{0}

922: \end{framegraph}

923: }

924: \THREESTEPS{\Neins}{\Nzwei}{\Ndrei}{\Nvier}{15}

925: %

926: \caption{An evaluation of \fg{normalize}}%

927: \label{f:norm-eval}

928: \end{figure*}%

929: In Figure~\ref{f:norm-eval}, \fg{normalize} is applied to 

930: a disguised call of \fg{remove}.

931: Every application of \fg{normalize} removes one item frame 

932: by evaluating \fg{remove} as an application condition,

933: until the list frame contains no item frame, and \fg{remove} fails.

934: %

935: (The empty list graph is represented by a single node;

936: the numbers 1 and 2 attached to it shall indicate that this node is the first,

937: as well as the second point of the graph.)

938: This control combinator uses the side effect of evaluating the premise

939: reminding of the way how the \emph{cut} operator is used in \textsc{Prolog}. 

940: 

941: Figure~\ref{fig:not-seq} shows two other control combinators: \textsf{Seq}

942: specifies two predicates which have to be evaluated sequentially whereas

943: \textsf{not} actually does not modify anything; \textsf{not} fails if and

944: only if its argument can be evaluated, i.e., \textsf{not} specifies an

945: application condition which must not be satisfied. Please note that the

946: right-hand side of its rule is ``--''. i.e., failure, whereas its otherwise

947: definition specifies ``++'', i.e., success.  For an application of these

948: control combinators see Section~\ref{s:example}.

949: \begin{figure}[htb]

950:   \begin{center}

951:     \psfig{figure=control.ps,scale=0.6}

952:     \caption{The control combinators \textsf{not} and \textsf{seq}}

953:     \label{fig:not-seq}

954:   \end{center}

955: \end{figure}

956: 

957: Finally, Figure~\ref{fig:while} shows the two rules that define the control

958: combinator \textsf{while}: It has two parameters; the second one is

959: evaluated as long as the first one can be evaluated. The \textsf{while}

960: succeeds as soon as $T_1$ cannot be applied (any longer). The

961: \emph{otherwise} definition triggers backtracking if both rules fail, i.e.,

962: $T_1$ can be evaluated, but the evaluation of the replacement graph of the

963: lower rule fails. For an application of \textsf{not}, \textsf{seq}, and

964: \textsf{while} see Section~\ref{s:example}.

965: \begin{figure}[tb]

966:   \begin{center}

967:     \psfig{figure=while.ps,scale=0.6}

968:     \caption{The control combinator \textsf{while}}

969:     \label{fig:while}

970:   \end{center}

971: \end{figure}

972: \wzbw\end{exxx} %

973: 

974: %

975: %

976: 

977: 

978: %

979: \subsection{Encapsulation}

980: 

981: Programming--in--the--large relies on the encapsulation of features in modules 

982: so that only some of them are visible to the public, 

983: and the others are protected from illegal manipulation.

984: 

985: We consider frames as \emph{objects} that respond to certain \emph{messages} (which are predicate calls).

986: The types of frames are \emph{class names},

987: and a \emph{class definition} declares predicates as its \emph{methods}. 

988: Only the class name, and some designated methods are \emph{public}.

989: The graphs contained in frames, and their other methods, are \emph{private}.

990: This adheres to the principle of \emph{data abstraction}.

991: 

992: \begin{exxx}[The List Class] %

993: In Figure~\ref{f:class}

994: we encapsulate primitive operations on list graphs within a class.

995: \begin{figure}[ht] %

996: \begin{center}

997: \begin{graph}(74,32)(-37,-16)

998:   \graphlinewidth*{2}

999:   \node{h}{-35}{0} \edge{h}{L}

1000:   \Qframe{L}{60}{32}{0}{0}{(58,32)(-27,-16)

1001:         \graphlinewidth*{0.5}

1002:         \freetext(31,13){\makebox(0,6)[r]{\small \fg{L}$_\tau$}}

1003:         \put(-23,2){\dashbox{0.2}(18,10){}} \freetext(0,7){$\to$}

1004:         \put(5,2){\dashbox{0.2}(18,10){}} \freetext(28,7){\ldots}

1005:         \button{E}{-14}{7}{enter}

1006:         \put(-23,-12){\dashbox{0.2}(18,10){}} \freetext(0,-7){$\to$}

1007:         \put(5,-12){\dashbox{0.2}(18,10){}} \freetext(28,-7){\ldots}

1008:         \button{R}{-14}{-7}{remove}

1009:           } 

1010:   \node{t}{35}{0} \edge{t}{L}

1011: \end{graph}

1012: \end{center}

1013: \caption{The list class}

1014: \label{f:class}

1015: \end{figure}%

1016: 

1017: In this small example, all methods are public.

1018: However, the structure of list graphs is visible only inside for the methods \fg{remove} and \fg{enter} that belong to the class.

1019: Other objects that contain some list frame $l$ can access its contents only by sending a message \fg{enter} or \fg{remove} to $l$.

1020: \wzbw\end{exxx} %

1021: 

1022: 

1023:   

1024: %

1025: \section{Typing}\label{s:typing}

1026: %

1027: 

1028: Types classify the objects of a program, and establish rules for using

1029: them. 

1030: If these rules are checked, preferably \emph{statically}, before executing the program, this ensures that a program is consistent, and may also speed up

1031: its execution.

1032: 

1033: 

1034: %

1035: %

1036: %

1037: %

1038: %

1039: %

1040: %

1041: %

1042: %

1043: %

1044: %

1045: \subsection{Graph Shapes}\label{ss:shapes}

1046: 

1047: %

1048: %

1049: We allow the \emph{shape} of graphs to be specified, similar as in \emph{Structured Gamma}~\cite{Fradet-LeMetayer:98}, by \emph{shape definitions} of the form

1050: $$      G_T \mathrel{::=} G_1 \mid G_2 \mid \ldots \mid G_n     $$

1051: where the graph $G_T$ consists of an edge labeled with a \emph{type name} $T$ and its linked nodes, 

1052: and the $G_i$ are graphs that may contain type edges again.

1053: Every variable name, frame type, and rule has a specified type,

1054: and it is checked whether the substitutions of variables, the contents of frames, and the patterns and replacements of rules \emph{conform} to these types. 

1055: Then all graphs in a program and the diagrams which are used as visual

1056: representations are of a well-defined shape.

1057: 

1058: %

1059: \begin{exxx}[Typing Shape of List and Item Graphs]%

1060: \label{x:listtypes}

1061: The shape definition in Figure~\ref{f:listtypes} specifies list and item graphs.

1062: \begin{figure}[ht] %

1063: \newcommand{\LQ}

1064:  {\begin{framegraph}(16,10)(-2,13)

1065:   \typ{Q}{6}{18}{L$_\tau$} \edge{Q}{b}  \edge{Q}{e} 

1066:   \point{b}{0}{18} \point{e}{12}{18}

1067:   \end{framegraph}

1068: }

1069: \TYPE{\LQ}

1070:  {\begin{framegraph}(12,10)(-6,-5)

1071:   \point{v}{0}{0} 

1072:   \autonodetext{v}[w]{\small 1}\autonodetext{v}[e]{\small 2}

1073:   \end{framegraph}

1074: }{\begin{framegraph}(52,10)(-2,-5)

1075:   \point{v0}{0}{0} \edge{v0}{Q1} 

1076:   \typ{Q1}{6}{0}{L$_\tau$} 

1077:   \node{v1}{12}{0} \edge{v1}{G2} \edge{v1}{Q1} 

1078:   \Qframe{G2}{16}{8}{24}{0}{(16,8)(-2,-4)

1079:         \point{b}{0}{0}

1080:         \var{X}{6}{0}{\tau} \edge{X}{b} \edge{X}{e}

1081:         \point{e}{12}{0}

1082:         }

1083:   \node{v2}{36}{0} \edge{v2}{Q3} \edge{v2}{G2}

1084:   \typ{Q3}{42}{0}{L$_\tau$} 

1085:   \point{v3}{48}{0} \edge{v3}{Q3}

1086:   \end{framegraph}

1087: }{10}

1088: \\[3mm]

1089: \TYPES{\begin{framegraph}(16,10)(-2,-5)

1090:   \typ{I}{6}{0}{I} \edge{I}{1} \edge{I}{k}

1091:   \point{1}{0}{0}

1092:   \point{k}{12}{0}

1093:   \end{framegraph}

1094: }{\begin{framegraph}(12,10)(-6,-5)

1095:   \point{0}{4}{0} \edge{0}{1} \bow{0}{1}{-0.3} \bow{0}{1}{+0.3}

1096:   \point{1}{-4}{0}

1097:   \end{framegraph}

1098: }{\begin{framegraph}(12,10)(-6,-5)

1099:   \point{0}{4}{0} \edge{0}{1} \edge{0}{2} \edge{0}{3}

1100:   \node{1}{0}{-3} \edge{1}{3}

1101:   \node{2}{0}{+3} \edge{2}{3}

1102:   \node{3}{-4}{0}

1103: \end{framegraph}

1104: }{\begin{framegraph}(12,10)(-6,-5)

1105:   \node{0}{3}{0} \edge{0}{1} \edge{0}{2} 

1106:   \node{1}{-2}{-3} \edge{1}{2}

1107:   \node{2}{-2}{+3} 

1108:   \end{framegraph}

1109: }{$\ldots$}{10}

1110: %

1111: \caption{The shape of list and item graphs}

1112: \label{f:listtypes}

1113: \end{figure}%

1114: These graphs may be contained in list and item frames, respectively. The

1115: type \fg{L}$_{\tau}$ of list graphs is \emph{polymorphic}.  The type

1116: parameter $\tau$ can be instantiated with any shape. In our examples, the

1117: variable $L$ binds list graphs of type \fg{L}$_{\tau}$, and the variable

1118: $X$ binds graphs of the any type $\tau$, and is instantiated by the type

1119: \fg{I} of item graphs in the transformations of Example~\ref{x:enremove}

1120: and~\ref{x:combinators}.

1121: \wzbw\end{exxx} %

1122: 

1123: The rules used for shape definitions are a well-studied special case of

1124: \emph{context-free} graph transformation~\cite{Drewes-Habel-Kreowski:97}.

1125: Type checking thus amounts to \emph{context-free graph parsing}, as

1126: it is implemented in \textsc{DiaGen} (see Section~\ref{s:diagrams}).

1127: 

1128: Note that even if graph parsing may be expensive, it is done \emph{statically},  before executing the program, and will also reduce the search space for graph matching at runtime.

1129: 

1130: 

1131: %

1132: \subsection{Predicate Signatures}

1133: 

1134: The \emph{signature} of a predicate shall specify to which

1135: kind of parameters it applies. As predicates are represented as graphs,

1136: their signature can be specified by shape definitions for a designated type $\pi$ of predicates.

1137: 

1138: 

1139: %

1140: \begin{exxx}[Signature of List Predicates]%

1141: \label{x:listsig}

1142: In Figure~\ref{f:listsig}, we speci\-fy signatures for the predicates used

1143: in our examples.

1144: The predicate type $\pi$ has a varying number of parameter nodes

1145: so that the rules of the shape definition 

1146: have different left hand sides.

1147: \begin{figure*}[tb] %

1148: \centering

1149: \newcommand{\Nvariadic}

1150: {\begin{framegraph}(16,21.5)(-2,0)

1151:   \button{N}{6}{18}{normalize} \metaedge{N}{P}

1152:   \parbuttonvar{P}{6}{9}{\pi}

1153:   \edge{P}{1} \edge{P}{k}

1154:   \hiddennode{d}{6}{4} \autonodetext{d}{\ldots}

1155:   \point{1}{2}{2}

1156:   \hiddennode{d2}{6}{2} \autonodetext{d2}{\ldots}

1157:   \point{k}{10}{2}

1158: \end{framegraph}

1159: }

1160: \newcommand{\Pvariadic}

1161: {\begin{framegraph}(12,13)

1162:   \buttonvar{P}{6}{9}{\pi} \edge{P}{1} \edge{P}{k}

1163:   \hiddennode{d}{6}{4} \autonodetext{d}{\ldots}[\opaquetextfalse]

1164:   \point{1}{2}{2}

1165:   \hiddennode{d2}{6}{2} \autonodetext{d2}{\ldots}[\opaquetextfalse]

1166:   \point{k}{10}{2}

1167: \end{framegraph}

1168: }

1169: \newcommand{\Ntwosig}

1170: {\begin{framegraph}(16,21.5)(-2,0)

1171:   \button{N}{6}{18}{normalize} \metaedge{N}{P}

1172:   \parbuttonvar{P}{6}{9}{\pi}

1173:   \edge{P}{1} \edge{P}{k}

1174:   \point{1}{2}{2}

1175:   \point{k}{10}{2}

1176: \end{framegraph}

1177: }

1178: \newcommand{\Ptwo}

1179: {\begin{framegraph}(12,13)

1180:   \buttonvar{P}{6}{9}{\pi} \edge{P}{1} \edge{P}{k}

1181:   \point{1}{2}{2}

1182:   \point{k}{10}{2}

1183: \end{framegraph}

1184: }

1185: \newcommand{\Nfoursig}

1186: {\begin{framegraph}(16,21.5)(-2,0)

1187:   \button{N}{6}{18}{normalize} \metaedge{N}{P}

1188:   \parbuttonvar{P}{6}{9}{\pi}

1189:   \edge{P}{1} \edge{P}{2} \edge{P}{3} \edge{P}{k}

1190:   \point{1}{2}{2}

1191:   \point{2}{4.66}{2}

1192:   \point{3}{7.36}{2}

1193:   \point{k}{10}{2}

1194: \end{framegraph}

1195: }

1196: \newcommand{\Pfour}

1197: {\begin{framegraph}(12,13)

1198:   \buttonvar{P}{6}{9}{\pi} \edge{P}{1} \edge{P}{2} \edge{P}{3} \edge{P}{k}

1199:   \point{1}{2}{2}

1200:   \point{2}{4.66}{2}

1201:   \point{3}{7.36}{2}

1202:   \point{k}{10}{2}

1203: \end{framegraph}

1204: }

1205: \newcommand{\Dsig}

1206: {\begin{framegraph}(16,16.5)(-2,5)

1207:   \button{D}{6}{18}{remove} \metaedge{D}{Q}

1208:   \typ{Q}{6}{9}{L$_\tau$} \edge{Q}{q1} \edge{Q}{q2}

1209:   \point{q1}{0}{9}

1210:   \point{q2}{12}{9}

1211: \end{framegraph}

1212: }

1213: \newcommand{\Esig}

1214: {\begin{framegraph}(17,25.5)(-2,-4)

1215:   \button{D}{6}{18}{enter} \metaedge{D}{Q} \metabow{D}{X}{+0.45}

1216:   \typ{Q}{6}{9}{L$_\tau$} \edge{Q}{q1} \edge{Q}{q2}

1217:   \point{q1}{0}{9}

1218:   \point{q2}{12}{9}

1219:   \var{X}{6}{0}{\pi} \edge{X}{x1} \edge{X}{x2}

1220:   \point{x1}{0}{0}

1221:   \point{x2}{12}{0}

1222: \end{framegraph}

1223: }

1224: \begin{tabular}{c} \Ptwo \end{tabular} {\large ::=}

1225: \begin{tabular}{c} \Dsig \end{tabular}

1226: \hfill

1227: \begin{tabular}{c} \Pfour \end{tabular} {\large ::=}

1228: \begin{tabular}{c} \Esig \end{tabular}

1229: \hfill

1230: \begin{tabular}{c} \Pvariadic \end{tabular} {\large ::=}

1231: \begin{tabular}{c} \Nvariadic \end{tabular}

1232: 

1233: \caption{The signature of list predicates}

1234: \label{f:listsig}

1235: \end{figure*}%

1236: 

1237: All predicate calls occurring in the examples of this paper

1238: can be derived with these rules 

1239: (together with those of Figure~\ref{f:listtypes}).

1240: The predicate variable $T$ used in example~\ref{x:combinators} is of type $\pi$.

1241: \wzbw\end{exxx} %

1242: 

1243: Note how typing increases the security of programs:

1244: Since the shape of all graphs in a program can be checked, every call of a predicate (like \fg{remove} or \fg{normalize}) can be type-checked at compile time.  

1245: Since the input to the program, e.g.~the graphs in Figure~\ref{f:norm-eval}, can also be type-checked, a predicate will always be applied to graphs of its parameter type, and evaluation of the program may not go wrong with this respect.  

1246: 

1247: %

1248: \section{Example: Graph Coloring}\label{s:example}

1249: %

1250: 

1251: This section shows that \textsc{DiaPlan} is a well-suited rule-based

1252: language for inherently graphical problems. The following \textsc{DiaPlan}

1253: program searches for a solution of the graph coloring problem for an

1254: arbitrary graph which is passed as an argument to the predicate

1255: \textsf{coloring} (cf.~Fig.~\ref{fig:coloring-pred}).

1256: \begin{figure}[htb]

1257:   \begin{center}

1258:     \psfig{figure=color.ps,scale=0.6}

1259:     \caption{The predicate \textsf{coloring}}

1260:     \label{fig:coloring-pred}

1261:   \end{center}

1262: \end{figure}

1263: As specified by the \textsf{while}-combinator, the program alternately

1264: evaluates predicate \textsf{addColor} and \textsf{not invalid}. The program

1265: terminates as soon as \textsf{addColor} cannot be applied any longer

1266: (success) or when no coloring exists (failure).

1267: 

1268: \begin{figure}[htb]

1269:   \begin{center}

1270:     \psfig{figure=addColor.ps,width=\textwidth}

1271:     \caption{The predicate \textsf{addColor}}

1272:     \label{fig:addColor-pred}

1273:   \end{center}

1274: \end{figure}

1275: Predicate \textsf{addColor} (Fig.~\ref{fig:addColor-pred}) simply adds a

1276: color edge, i.e., \emph{red}, \emph{blue}, or \emph{green} to some

1277: previously non-colored node of the graph. Non-colored nodes are indicated by

1278: $\varepsilon$-edges.

1279: \begin{figure}[bh]

1280:   \begin{center}

1281:     \psfig{figure=invalid.ps,scale=0.6}

1282:     \caption{The predicate \textsf{invalid}}

1283:     \label{fig:invalid-pred}

1284:   \end{center}

1285: \end{figure}

1286: After assigning a color to a node, predicate \textsf{invalid}

1287: (Fig.~\ref{fig:invalid-pred}) checks whether this action was valid: The

1288: \textsf{not invalid} predicate fails and triggers backtracking if previous

1289: \textsf{addColor} evaluation cannot yield a consistent graph coloring.

1290: 

1291: Fig.~\ref{fig:color-ex} shows a sample transformation sequence

1292: which terminates with a consistent coloring of a simple graph that

1293: consists of four edges and four nodes which are initially non-colored.

1294: \begin{figure}[htb]

1295:   \begin{center}

1296:     \psfig{figure=color-ex.ps,width=\textwidth}

1297:     \caption{An evaluation of \textsf{coloring} which yields a graph coloring}

1298:     \label{fig:color-ex}

1299:   \end{center}

1300: \end{figure}

1301: 

1302: %

1303: \section{Diagrams}\label{s:diagrams}

1304: %

1305: 

1306: Genericity, the other key feature of the language, is based on diagrams as

1307: an external notation for graphs. This section briefly recalls how diagrams

1308: can be represented by graphs (e.g., in diagram editors), and, vice versa,

1309: how graphs can be visualized by diagrams.

1310: 

1311: %

1312: \subsection{Representation and recognition of diagrams}\label{s:graph-rep}

1313: %

1314: 

1315: Andries \emph{et al.}~\cite{Andries-Engels-Rekers:98} have proposed a model

1316: for representing diagrams as graphs that has been modified in

1317: \textsc{DiaGen}, a tool for generating diagram editors which support

1318: free-hand as well as syntax-directed

1319: editing~\cite{Koeth-Minas:00,Minas:98,Minas:00}.  This model shall be

1320: described here. Figure~\ref{f:diagen} shows the levels of diagram

1321: representation and the recognition steps when analyzing a given diagram.

1322: \begin{figure}[b] %

1323: \begin{center}

1324: \unitlength=0.7mm\graphlinewidth*{3}\grapharrowwidth*{2}\grapharrowlength*{2}

1325: \begin{graph}(50,60)(-20,-4)

1326:   \rectnode{c}[50,12](0,52) 

1327:         \autonodetext{c}{\small\begin{tabular}{@{}c@{}} diagram components\\ with attachment areas \end{tabular}}

1328:   \diredge{c}{s} \bowtext{c}{s}{+0.7 }{\emph{scanning}}

1329:   \rectnode{s}[50,8](0,32) 

1330:         \autonodetext{s}{\small\begin{tabular}{@{}c@{}} spatial relation ship graph \end{tabular}}

1331:   \diredge{s}{r} \bowtext{s}{r}{+0.7 }{\emph{reducing}}

1332:   \rectnode{r}[50,8](0,16) 

1333:         \autonodetext{r}{\small\begin{tabular}{@{}c@{}} reduced graph \end{tabular}}

1334:   \diredge{r}{a} \bowtext{r}{a}{+0.7 }{\emph{parsing}}

1335:   \rectnode{a}[50,8](0,0) 

1336:         \autonodetext{a}{\small\begin{tabular}{@{}c@{}} abstract syntax graph \end{tabular}}

1337: \end{graph}

1338: \end{center}

1339: \caption{Diagram representation and recognition in \textsc{DiaGen}}

1340: \label{f:diagen}

1341: \end{figure} %

1342: 

1343: 

1344: \emph{Scanning} creates a \emph{spatial relationship graph} (\emph{SRG} for

1345: short) for capturing the lexical structure of a diagram. This step uses

1346: edges for representing the \emph{elements} of a diagram language (like

1347: circles, boxes, arrows, text); these \emph{component edges} are linked to

1348: nodes representing the \emph{attachment areas} at which these elements can

1349: be connected with the attachment areas of other elements, (like~the

1350: \emph{border} and \emph{area} of circles and boxes, the \emph{source} and

1351: \emph{target} ends of arrows). The connection of attachment areas is

1352: explicitly represented by binary relationship edges. The type of a

1353: relationship edge reflects the types of connected attachment areas and

1354: their kind of connection (e.g., intersection). For instance, the

1355: \emph{sources} and \emph{targets} of arrows may have intersections with the

1356: \emph{borders} of circles or boxes leading to specific relationship edges

1357: between the nodes of the corresponding element edges.

1358: 

1359: %

1360: %

1361: %

1362: %

1363: %

1364: %

1365: 

1366: Syntactic analysis is performed in two steps: The SRG is first

1367: \emph{reduced} to a more condensed graph (\emph{reduced graph}, RG for

1368: short) which is then \emph{parsed} according to the syntax of the diagram

1369: language. This two-step analysis transforms the spatial relationships into

1370: logical relations of the \emph{abstract syntax graphs} of the diagrams.

1371: (The specification of diagram syntax is discussed in

1372: Section~\ref{s:typing}.) The separation into two independent steps allows

1373: for a tractable process of specifying the syntax of the diagram language

1374: and for efficient syntax analysis.

1375: 

1376: Syntax-directed editing is supported by such editors, too. \textsc{DiaGen}

1377: comes with an abstract machine for the operational specification and

1378: execution of graph transformation rules (cf.~Section~\ref{ss:rules}) which

1379: are used to modify the SRG . This abstract machine already offers the full

1380: functionality which is necessary for the implementation of an interpreter

1381: for \textsc{DiaPlan} which is outlined in Section~\ref{s:implementation}.

1382: 

1383: This model is generic; a wide variety of diagram notations can be modeled,

1384: e.g., finite automata and control flow diagrams~\cite{Minas-Viehstaedt:95},

1385: Nassi-Shneiderman diagrams~\cite{Minas:97}, message sequence charts and

1386: visual expression diagrams~\cite{Minas:98}, sequential function

1387: charts~\cite{Koeth-Minas:00}, and ladder diagrams~\cite{Minas:00}. Actually

1388: we are not aware of a diagram language that cannot be modeled that way. 

1389: 

1390: %

1391: \subsection{Genericity}\label{s:genericity}

1392: %

1393: As this generic model uses graphs for modeling very different diagram

1394: notations, we can also use diagrams for visualizing graphs. This capability

1395: allows to tackle the problem that graphs are basically a visual data

1396: structure, but using graphs for programming directly might be too abstract.

1397: Instead, we can choose an arbitrary visual syntax for \emph{external}

1398: representations even if the programming language represents visual data as

1399: graphs internally.

1400: The user interface of a program can so be customized for the visual

1401: representations which are best suited in its application domain. This makes

1402: it possible to use the programming language of this paper which is based on

1403: graph transformations as a \emph{generic visual programming language}.  By

1404: representing very different diagram notations by graphs and operating on

1405: these graphs, many different flavors of visual (programming) languages can

1406: be described and implemented.  Obvious examples are \emph{Pictorial

1407:   Janus}~\cite{Kahn-Saraswat:90} (whose agents with ports directly

1408: correspond to our notion of typed edges) or

1409: \emph{KidSim}~\cite{Smith-Cypher-Spohrer:94}.

1410: 

1411: %

1412: %

1413: %

1414: %

1415: %

1416: %

1417: %

1418: %

1419: %

1420: %

1421: %

1422: %

1423: %

1424: %

1425: %

1426: %

1427: %

1428: %

1429: %

1430: %

1431: %

1432: %

1433: %

1434: %

1435: %

1436: %

1437: %

1438: %

1439: 

1440: 

1441:   

1442: %

1443: \section{Implementation}\label{s:implementation}

1444: %

1445: 

1446: The programming language outlined in this paper is in a rather concrete phase of its design.

1447: Its implementation is only at a very early stage.

1448: Here we just outline the architecture of the implementation. 

1449: (See Figure~\ref{f:architecture} for a diagram of the system structure.)

1450: 

1451: \begin{figure}[bt] %

1452: %

1453: %

1454: %

1455: %

1456: %

1457: %

1458: %

1459: %

1460: %

1461: %

1462: %

1463: %

1464: %

1465: %

1466: %

1467: %

1468: %

1469: %

1470: %

1471: %

1472: %

1473: %

1474: %

1475: %

1476:                                 %

1477:   \centerline{\psfig{figure=arch.ps,width=0.9\textwidth}}

1478: \caption{System architecture}

1479: \label{f:architecture}

1480: \end{figure} %

1481: 

1482: \begin{itemize}

1483: \item The \emph{interpreter} executes programs of the language by reading

1484:   the input graph, transforming the graph according to the program, and

1485:   re-displaying the modified graph, in a loop, steered by user interaction.

1486:   As an implementation of this interpreter, \textsc{DiaPlan} will use the

1487:   abstract machine for graph transformations which is part of

1488:   \textsc{DiaGen}.

1489: \item The \emph{compiler} reads programs and transforms them into an

1490:   internal form that can be easily and efficiently executed by the

1491:   interpreter.  And, very important, the compiler checks whether the

1492:   program violates any lexical, syntactical or contextual rule of the

1493:   language.  Among the contextual rules, typing (as discussed in

1494:   Section~\ref{s:typing}) plays a prominent role: The type checker shall be

1495:   implemented with the graph parser built into \textsc{DiaGen}~\cite{Minas:97}. 

1496: %

1497: \item The interpreter shall have an interactive visual editor by which the

1498:   input data is created. This editor shall be generated from a

1499:   specification in \textsc{DiaGen} in order to support customizable diagram

1500:   notation for the (abstract syntax) graphs that are produced by the editor

1501:   in order to be transformed internally.

1502: %

1503: %

1504: %

1505: %

1506: \item The programs will also be constructed with an interactive editor for

1507:   the visual syntax of the programming language. Again, this editor shall

1508:   be generated from a \textsc{DiaGen} specification of graphs, rules,

1509:   predicates, types, and classes.

1510: \end{itemize}

1511: 

1512: Altogether, only the compiler has to be implemented anew, while we rely

1513: entirely on the operational graph transformation machine of {\sc DiaGen}

1514: and the capability of \textsc{DiaGen} for generating the user interfaces of

1515: \textsc{DiaPlan}. \textsc{DiaGen} needs some extensions to meet the needs

1516: of this application:

1517: \begin{itemize}

1518: %

1519: %

1520: \item Other ways of specifying diagram languages, like normalizing

1521:   constructor rules, have to be investigated.

1522: \item A visual user interface has to be provided for \textsc{DiaGen} itself.

1523:   It comes to no surprise that \textsc{DiaGen} shall be used for this purpose.

1524: \end{itemize}

1525: 

1526: The implementation of the compiler is a challenging task. Even

1527: if we have convinced the reader that all concepts promised for the language

1528: are implementable, neither does this mean that it can be done

1529: \emph{efficiently}, nor that this will result in \emph{efficient systems}.

1530: For instance, the matching of a rule explained in section~\ref{ss:rules}

1531: requires to check \emph{subgraph isomorphism}, which is NP-hard in general.

1532: We hope that we will come close the performance of logical and

1533: functional languages' implementations, at least after restricting the shapes of graphs in a suitable way. 

1534: However, we cannot draw very much from the experience with implementing textual (functional or logical) languages for this aspect of the implementation.

1535: %

1536: %

1537: %

1538: 

1539: 

1540: %

1541: \section{Conclusion}\label{s:conclusion}

1542: %

1543: 

1544: In this paper we have presented a new programming language based on graph

1545: transformation that is rule-oriented, object-oriented, and supports

1546: structured graphs.  In particular, we have discussed typing of the

1547: language, and its genericity with respect to diagram notations. Genericity

1548: allows to represent graphs by specific notations of the application domain in the user interface. This feature makes the language and its specified environment well-suited for simulations and animations.

1549: 

1550: \emph{Structured graphs} have already been proposed in the context of graph

1551: transformation~\cite{Pratt:71,Engels-Schuerr:95}, in graphical data base

1552: languages~\cite{Poulovassilis-Levene:94}, and in system modelling

1553: languages~\cite{Tapken:99}. 

1554: Graph \emph{shapes} exist in \emph{Structured Gamma}~\cite{Fradet-LeMetayer:98} (for unstructured graphs).

1555: 

1556: However, we are not aware of any other language or language proposal that

1557: features structured graphs, transformations, and classes together with genericity and typing.

1558: 

1559: %

1560: %

1561: 

1562: The precise definitions of the concepts presented in this paper has been

1563: started in~\cite{Drewes-Hoffmann-Plump:00}, and needs to be continued. Some

1564: more concepts, like \emph{concurrency} and \emph{distribution}, have still

1565: to be considered.  As these concepts have been studied

1566: by~\cite{Taentzer:96} and~\cite{Taentzer-Schuerr:95} in a similar setting,

1567: there is some hope that these results can be extended to our language.

1568: 

1569: %

1570: %

1571: %

1572: %

1573: %

1574: %

1575: %

1576: 

1577: Last but not least, a compiler (with type checker) has still to be implemented.

1578: 

1579: 

1580: 

1581: %

1582: %

1583: %

1584: %

1585: %

1586: %

1587: 

1588: 

1589: %

1590: %

1591: %

1592: \begin{thebibliography}{10}

1593: 

1594: \bibitem{Andries-Engels-Rekers:98}

1595: M.~Andries, G.~Engels, and J.~Rekers.

1596: \newblock How to represent a visual specification.

1597: \newblock In K.~Marriott and B.~Meyer, editors, {\em Visual Language Theory},

1598:   chapter~8, pages 245--260. Springer, New York, 1998.

1599: 

1600: \bibitem{Bardohl:98}

1601: R.~Bardohl.

1602: \newblock \textsc{GenGEd}: A generic graphical editor for visual languages

1603:   based on algebraic graph grammars.

1604: \newblock In {\em Proc. 1998 IEEE Symp.{} on Visual Languages (VL'98), Halifax,

1605:   Canada}, pages 48--55, 1998.

1606: 

1607: \bibitem{VOOP:94}

1608: M.~M. Burnett, A.~Goldberg, and T.~G. Lewis, editors.

1609: \newblock {\em Visual Object-Oriented Programming}.

1610: \newblock Manning, 1994.

1611: 

1612: \bibitem{Corradini-Montanari:95}

1613: A.~Corradini and U.~Montanari, editors.

1614: \newblock {\em Proc.\ Joint {\sc CompuGraph}/{\sc Semagraph} Workshop on Graph

1615:   Rewriting and Computation}, number~2 in Electronic Notes in Theoretical

1616:   Computer Science, {\tt http://www.elsevier.nl/locate/entcs}, 1995. Elsevier.

1617: 

1618: \bibitem{Prograph}

1619: P.~T. Cox, F.~R. Giles, and T.~Pietrzykowski.

1620: \newblock Prograph.

1621: \newblock In Burnett et~al. \cite{VOOP:94}, chapter~3, pages 45--66.

1622: 

1623: \bibitem{Drewes-Habel-Kreowski:97}

1624: F.~Drewes, A.~Habel, and H.-J. Kreowski.

1625: \newblock Hyperedge replacement graph grammars.

1626: \newblock In Rozenberg \cite{Rozenberg:97}, chapter~2, pages 95--162.

1627: 

1628: \bibitem{Drewes-Hoffmann-Plump:00}

1629: F.~Drewes, B.~Hoffmann, and D.~Plump.

1630: \newblock Hierarchical graph transformation.

1631: \newblock In {\em Foundations of Software Science and Computation Structures

1632:   (FOSSACS 2000)}, LNCS, 2000.

1633: \newblock To appear.

1634: 

1635: \bibitem{Engels-Schuerr:95}

1636: G.~Engels and A.~Sch\"urr.

1637: \newblock Encapsulated hierachical graphs, graph types, and meta types.

1638: \newblock In Corradini and Montanari \cite{Corradini-Montanari:95}.

1639: 

1640: \bibitem{Erwig-Meyer:95}

1641: M.~Erwig and B.~Meyer.

1642: \newblock Heterogeneous visual languages -- {I}ntegrating visual and textual

1643:   programming.

1644: \newblock In {\em Proc.\ 11th IEEE Symp. on Visual Languages (VL'95),

1645:   Darmstadt, Germany}, pages 318--325, 1995.

1646: 

1647: \bibitem{Fradet-LeMetayer:98}

1648: P.~Fradet and D.~L. M{\'e}tayer.

1649: \newblock Structured {G}gamma.

1650: \newblock {\em Science of Computer Programming}, 31(2/3):263--289, 1998.

1651: 

1652: \bibitem{Hoffmann:00}

1653: B.~Hoffmann.

1654: \newblock From graph transformation to rule-based programming with diagrams.

1655: \newblock In {\em Proc. Int. Workshop on Applications of Graph Transformations

1656:   with Industrial Relevance ({\sc Agtive}'99)}, volume 1779 of {\em LNCS},

1657:   pages 165--180.

1658: 

1659: \bibitem{Kahn-Saraswat:90}

1660: K.~M. Kahn and V.~Saraswat.

1661: \newblock Complete visualizations of concurrent programs and their executions.

1662: \newblock In {\em Proc. IEEE Workshop on Visual Languages (VL'90)}, pages

1663:   7--15, 1990.

1664: 

1665: \bibitem{Koeth-Minas:00}

1666: O.~K\"{o}th and M.~Minas.

1667: \newblock Generating diagram editors providing free-hand editing as well as

1668:   syntax-directed editing.

1669: \newblock In {\em Proc. International Workshop on Graph Transformation ({\sc

1670:   GraTra} 2000), Berlin}, March 2000.

1671: 

1672: \bibitem{Minas:00}

1673: M.~Minas.

1674: \newblock Creating semantic representations of diagrams.

1675: \newblock In {\em Proc. Int. Workshop on Applications of Graph Transformations

1676:   with Industrial Relevance ({\sc Agtive}'99)}, volume 1779 of {\em LNCS},

1677:   pages 209--224.

1678: 

1679: \bibitem{Minas:98}

1680: M.~Minas.

1681: \newblock Hypergraphs as a uniform diagram representation model.

1682: \newblock In {\em Proc. 6th Int. Workshop on Theory and Application of Graph

1683:   Transformation (TAGT'98)}, volume 1764 of {\em LNCS}, pages 281--295.

1684: 

1685: \bibitem{Minas:97}

1686: M.~Minas.

1687: \newblock Diagram editing with hypergraph parser support.

1688: \newblock In {\em Proc.\ 13th IEEE Symp. on Visual Languages (VL'97), Capri,

1689:   Italy}, pages 230--237, 1997.

1690: 

1691: \bibitem{Minas-Viehstaedt:95}

1692: M.~Minas and G.~Viehstaedt.

1693: \newblock {DiaGen}: A generator for diagram editors providing direct

1694:   manipulation and execution of diagrams.

1695: \newblock In {\em Proc.\ 11th IEEE Symp. on Visual Languages (VL'95),

1696:   Darmstadt, Germany}, pages 203--210, 1995.

1697: 

1698: \bibitem{Pfeiffer:95}

1699: J.~J. {Pfeiffer, Jr.}

1700: \newblock $\textsc{Ludwig}_2$: Decoupling program representations from

1701:   processing models.

1702: \newblock In {\em Proc.\ 11th IEEE Symp. on Visual Languages (VL'95),

1703:   Darmstadt, Germany}, pages 133--139, 1995.

1704: 

1705: \bibitem{Plump-Habel:96}

1706: D.~Plump and A.~Habel.

1707: \newblock Graph unification and matching.

1708: \newblock In J.~E. Cuny, H.~Ehrig, G.~Engels, and G.~Rozenberg, editors, {\em

1709:   Proc.\ Graph Grammars and Their Application to Computer Science}, number 1073

1710:   in Lecture Notes in Computer Science, pages 75--89. Springer, 1996.

1711: 

1712: \bibitem{Poulovassilis-Levene:94}

1713: A.~Poulovassilis and M.~Levene.

1714: \newblock A nested-graph model for the representation and manipulation of

1715:   complex objects.

1716: \newblock {\em ACM Transactions on Information Systems}, 12(1):35--68, 1994.

1717: 

1718: \bibitem{Pratt:71}

1719: T.~W. Pratt.

1720: \newblock Pair grammars, graph languages and string-to-graph translations.

1721: \newblock {\em Journal of Computer and System Sciences}, 5:560--595, 1971.

1722: 

1723: \bibitem{Rozenberg:97}

1724: G.~Rozenberg, editor.

1725: \newblock {\em Handbook of Graph Grammars and Computing by Graph

1726:   Transformation, Vol.~{I}: Foundations}.

1727: \newblock World Scientific, Singapore, 1997.

1728: 

1729: \bibitem{Schuerr-Winter-Zuendorf:99}

1730: A.~Sch\"urr, A.~Winter, and A.~Z{\"u}ndorf.

1731: \newblock The {\sc progres} approach: Language and environment.

1732: \newblock In Rozenberg \cite{Rozenberg:97}, chapter~13, pages 487--550.

1733: 

1734: \bibitem{Smith-Cypher-Spohrer:94}

1735: D.~C. Smith, A.~Cypher, and J.~Spohrer.

1736: \newblock Kid{S}im: Programming agents without a programming language.

1737: \newblock {\em Communications of the ACM}, 37(7):54--67, 1994.

1738: 

1739: \bibitem{Taentzer:96}

1740: G.~Taentzer.

1741: \newblock {\em Parallel and Distributed Graph Transformation: Formal

1742:   Description and Application to Communication-Based Systems}.

1743: \newblock Dissertation, TU Berlin, 1996.

1744: \newblock Shaker Verlag.

1745: 

1746: \bibitem{Taentzer-Schuerr:95}

1747: G.~Taentzer and A.~Sch{\"u}rr.

1748: \newblock {DIEGO}, another step towards a module concept for graph

1749:   transformation systems.

1750: \newblock In Corradini and Montanari \cite{Corradini-Montanari:95}.

1751: 

1752: \bibitem{Tapken:99}

1753: J.~Tapken.

1754: \newblock Implementing hierarchical graph structures.

1755: \newblock In J.-P. Finance, editor, {\em Proc. Formal Aspects of Software

1756:   Engineering (FASE'99)}, number 1577 in Lecture Notes in Computer Science.

1757:   Springer, 1999.

1758: 

1759: \bibitem{Wodtli-Cull:97}

1760: R.~Wodtli and P.~Cull.

1761: \newblock \textsc{Calypso}: A visual language for data structures programming.

1762: \newblock In {\em Proc. 1997 IEEE Symp.{} on Visual Languages (VL'97), Capri,

1763:   Italy}, pages 166--167, 1997.

1764: 

1765: \end{thebibliography}

1766: 

1767: %

1768: 

1769: \end{document}

1770: 

1771: 

1772: