「インタラクション，97」 平成9年2月

SpatialParserGeneratorのTcl／Tkを用いた軍襲
馬場昭宏

田中二郎

筑波大学工学研究科

筑波大学電子情報工学系

JlrOQsoftlab・is・tSukuba・aC・JP

baba◎softlab．is・tSukuba．ac・Jp

概要

ビジュアルプログラミングシステムには図形の形状、配置の解析を行う部分（SpatialParseL）があるが作成は困難で時間がかかるので、SpatialParserGeneratorが必要になる。

本論文では現在我々が作成している仕様を与えてSpatialParSerを作るシステムについて述べる。生成されたSpatialParserは必要があれば対話的に再定義することが出来る。

ImplementingASpatialParserG占neratorinTcl／Tk・
abstract

Avisualprogrammingsystemrequiresaspatialparser，Whichanalyzesshapesahdconfigurationsof
figures・Creatingspatialparsersisadi且cultandtimeconsumingjob，SOWeneedaspatialpar！er9enerYltOf・Inthispaper，Wedescribeasystemthatgeneratesspatialparserfromspecifications・Theresulted
spatialparsercanbetestedandthespecificationscanberedefined，ifneeded，inaninteractiveway・
1 はじめにビジュア？レプログラミングシステムとは、「2次元もしくはそれ以上の次元でプログラムを定義することが出来る環境」である【1】。我々は並列論理型言語GHC【2】に基づき、ビジュアルプログラミングシ￣ゎムPP【3】【4】の捷案を行ってきた。ビジュアルプログラミングシステムPPセはこすでにいくつかの試験的な実装が成されているが、図形の形状や配置に関して、最終的な仕様が確定しておらず、仕様の変更が常に行われそいる段階である。

一般に、ビジュアルプログラミングシステムには図形の形状、配置の解析を行う部分（SpatialParser）がある。これはテキスト言語の処理系における字句解析、構文解析にあたる。通常、SpatialParserは特定の図形の形状や配置の仕様に特化した形で実現されるが、このような形でSpatialParserを作成するの，は試験的な実装には不向きである。そこで、図形の形状や配置に関しても、仕様を入力すればその仕様に対す為parserが自動的に合成される（テキスト言語における）lexやyaccのようなもめ、す′なわちSpati91ParserGeneratorがあればよい、という考えが生まれる。

土れまでに提案されてきたSpa七ialParserGenerator【11】は図形の形状や配置に関する仕様を与えた後にコンパイルし、生成されたSpatialParserをビジュアルプログラミングシステムに組み込み、動作のテストを行ってきた。

本論文ではTcl／Tk七Prologを用いて定義とテストを繰り返しながら対話的にSpatialParserを作成するシステムを提案する。本システムにおいては、仕様を対話的に与え、仕様をPrologプログラムにコンパイルする。Tbstwindowからparseされるべき図形を与え、それをPrologのqperyの形式に変換し、動作テストを行うことができるので、SpatialParserをビジュアルプログラミングシステム本体に組み込む必要はない0一71−

2 テキスト言語とビジュ

アル言語の構成要素の対比

ビジュアルプログラミングシステムで用いられる言語をビジュアル言語と呼ぶ。単語を構成するためにテキスト言語では文字を1次元的に配置していくが、ビジュアル言語では円や直線などの図形を2次元、もしくはそれ以上の次元に配置する。これらの図形のことを図形文字と呼ぶことにする。図形文字としては、例えば楕円、円弧、長方形、直線、文字などが考えられる。各図形文字は、形状に関わる情報として種類、色、大きさ、線の太さなどの属性を持つ。また、形状以外の情報として、ある座標空間における位置を属性として持つ。
テキスト言語ではある概念を単語として表すが、同様にビジュアル言語にも単語に相当するものがあると考えられる。ビジュアル言語ではある概念を図形文字を組み合わせて作った、意味のある一つの「もの」として表すのが一般的である（図1）。したがって本論文ではビジュアル言語におけるこのような「もの」を図形単語と呼ぶことにする。最も基本的な図形単語は1個以上の図形文字の集合として表される。テキスト言語では例えば「顔」という概念の視覚的な側面を説明する時に「顔は、輪郭があって、目が二つとまゆげが二つとロがある」という文ができるが、ビジュアル言語においては下位の概念を表す文字や単語を空間的に組み合わせることによって上位の概念を表す単語を作ることができる（図2（a））。このことから一般に図形単語は1個以上の図形文字または図形単語の集合として定義することができる。

図形単語自身の属性と図形単語を構成している下位の構成要素の属性とは異なっている。すなわち、一般には下位の構成要素が持っていなかった属性を図形単語が持つことになる。例として図2（b）をあげる。図2（b）では楕円や直線などから、「顔」という名前の図形単語を作っている。このとき、「顔」はその形状から「肥満度」という属性を持つ。これはどの構成要素にもなかった属性である。このように図形単語の属性はテキスト言語における形容詞の役割を果たしているものと考えることができる。
テキスト言語もビジュアル言語もある事柄を記述するための方法であるという点においては共通である。本論文ではテキスト言語で「文」と呼んでいる概念のことをビジュアル言語では図形文と呼ぶことにする。図形文

は1個以上の図形単語の集合である。図形文と図形単語は見かけ上の違いはない。、しかし、テキスト言語に変換したときに図形文は文になり、図形単語は単語になる。以下、本論文では単に文字、単語と言ったときは通常のテキスト言語における文字、単語を指すものとする。

単語単語文字顔 …・− 顔相愛しい文字．．‖− 愛，し，い

1トー＿．享図1：テキスト言語とビジュアル言語の村比

また、テキスト言語の字句解析、構文解析をビジュアル言語ではそれぞれSpatia［LexicaIAnalyzing、Spa−
tialParsingと呼ぶことにする。これまでビジュアル言語の構成要素は基本部品とそれを組み合わせることで作られるものとの2つに分類するのが一般的であったが．（【9】【10】）、本論文ではテキスト言語の構成要素（文、単語、文字）と対応付けて3つに分類した。この分類によりビジュアル言語の言語としての側面がよりはっきりした0虔 仕様の記述の方式

テキスト言語に率いて構文解析する際に文法を形式的に記述する必要があるのと同様に、SpatialParsingを行なうためにはビジュアル言語の仕様を形式的に記述する必要がある。

3．1 他の研究の動向
これまでSpatialPerserに仕様を与える方法としては文法的な記法【5】【6］［7］［8】【9トや重言的な記法［10］などが用いられてきた。しかし、これらの記法はいずれもtextualなものである。図形文字や図形単語の属性は、図ー72−

上位の単語㊦…・…・−・
アご熱下位の単語／￣＼ 0 0 「 ￣ T○罠−・−・−・…・ナ・1て鵬・−・L・−・−・L

＼＿ノ ‖

▼

l

文字 00
（a）単語の階層構造（b）図形単語の属性

図2：図形単語形として表現すれば自ずと備わるが、文字にしてしまうとそれらを明示的に記述する必要が出てくる。そのため、teXtualな記法は煩雑であり、しかも直観的に理解しにくいb3．2 図形を用いる方式
そこで、図形を用いて仕様を記述したいという欲求が出てくる。しかし図形を用いると逆に必要のない属性までが記述されてしまう。例えば、図3のような例を考える。図3では「楕円の中に文字が書かれている」図形
単語を定義したいとする。しかしそれを図を用いて記適しようとすると、「線の太さが1で長軸の長さが30で…の楕円の中心からx軸方向に−10、y軸方向に−5だけ移動した点にフォントはHelveticaで色は黒で…appendと書かれた文字列がある」となってしまう。右側の6個の例はいずれも「楕円の中に文字が善かれている」図形単語であるが、左側の定義と完全に一敦するのはいちばん右側のものだけである。あとのものは大きさや線の太さなどが異なるために一致しない。本当は右側の6個の図形単語すべてが一敦して欲しいのこのような定義は表現したいものとは明らかに異なっている。

例

×⑳×㊤ ×㊥ ×㊤．0く蒜妄参
図3：図形のみを用いて仕様を与える例

3．3 図形と文字を併用する方式
3．2節で述べた問題の解決法として本論文で提案する仕様の記述め方式は、まず図形を用いて大まかな仕様を与えた後にそれを文字に変換し、必要のない属性を削除したり、複数の属性間の関係を記述することで仕様を決めるというスタイルである。この方式ではまず図形を用いているために定義したいものの概要を直観的に理解、記述することができ、その後文字に変換して必要のない属性をなくし、さらには図形の状態では必ずしも明らかではなかった図形間の関係を記述する。

4 実装するシステム
これらの考察をふまえて現在Tcl／Tkを用いて実装を行っているシステムについて述べる。

−73−

4．1 機能
本システムが目指すものは
1．3，3節で述べた方式によってビジュアル言語の仕様を記述し、2．その仕様からSpatialParserを自動生成し、3．生成されたSpatialParserのテストを行なうことをサイクルとして村話的にSpatialParserを完成させるためのエディタである。システムの概要を図4に示す。図4の各行が上述の1、2、3に対応する。

−Slla血1Pa一光r（P柑logの節）◎

ヽ＿．＿．＿＿．＿＿＿＿＿■−◎

図4：システムの概要

システムの画面例を図5（a）、（b）に示す。図5（a）の画面の上半分をDefinewindow下半分をT申twindowと呼ぶ。、Definewindowのメニューバーには、入力した図形の保存、呼び出し、システムの終了などを行なう
File、図形の消去、コピーなどを行なうEdit、入力する図形の種類を変えるMode、入力する図形の色、線の太さなどの変更の他、水平、垂直方向の整列を行なうGraphics、図形情報から文字情報、さらにSpatialParserまで変換するLex、各メニューの説明を表示するHelpがある。TestwindowのメニューバーにはDefinewin−
dowのメニューバーと同様のFile、Edit、Mode、Graphicsの他、Testwindowに措かれた図形を現在作られているSpatialParserによりSpatialParsingするParseがある。
ユ「ザはまずDefinewindowに図形を入力する。入力した図形のうち一つの図形単語としたいものをまとめて選択し、メニュ⊥バーのLexからMakeNon−Tbrminalを遽ぶと文重任棟を入力するためゐウィンドウ（図5（b））が開く（図4の○）。ここでユーザは必要のない属性を削除したり属性間の関係を記述する。ウインドウを閉じると定義した図形単語が内部表現として登録される（図4の①）。

同様にしていくつかの図形単語を作成していく。メニューバーのLexからGenarateClauseを選ぶとSpa−tialParserとしてPrologの節が作られる（図4の◎）。生成されたSpatialparserはファイルに書き出される。
Testwindowに実際にSpatialParsingしたい図形を入力し、メニューバーのParseからParseを選ぶとTest
Windowの図形はPrologの問い合わせに変換され（図4の①）、生成されたSpatidP鱒SerによってSpatialPars−ingが行なわれる0このと割こ期待通りの出力が得られなかったらSpatialParser
トを行なう。

SpatigP鱒rSingが成功すると仕様として与えられたアクショシが実行され声。アクションについては4．2．4節で述べる。

4．2 文字による仕様
SpatialParsingする際、上位の図形単語を構成するために下位の構成要素を組み合わせていくが、当然、下位の構成要素の属性値と上位＿の図形単語の属性億とは異なっている。図5（b）にお1、て、いちばん上のブロックが現在定義中の歯形単語自体の属性で卒る。2番目以降の各ブロックはその図形単語の構成要素の属性である。属性の各行は属性名、その属性の型、そして値を表している。現在のところ型としては、文字列型、数値型

ー74−

（a）図形仕様入力部およびテスト部（b）文字仕様入力部

図5：作成中のエディタを用意している。また、定義している図形単語とその構成要素間で互いに属性の型や値を参照するため、参照塑を用意している。

4．2．1 数値型
座標、長さなどを記述するために数値型を用いる。数値型の値は数値の取り得る値の範囲を指定できるようにするために次のように記述することとした。
（I任意の値n借用（托1れ2） 几1以上れ2以下の値（乃1−） 几1以上の値（一犯2） 陀2以下の値

4．2．2 文字列型
図3の例にあったように、図形の一つとしての文字の記述や、図形の種類、色などの記述には文字列を使う。
これらには「任意の文字列」といったことが記述できると便利である。文字列型の値の記述にはTclで用いることのできる正規表現を用いることができる予定である。

4．2．3 参照型
参照型を使うことによって、属性の値を記述する際に同一の単語内の他の構成要素の属性の値を参照する。

例えば、ある構成要素（idl）のtypeを別の構成要素（id2）のtypeと同じものであるようにする・ときは翠のように記述する。
id numl

type at2・type−75−

name cbar noⅣamelnⅦmber−Of−COmpOn￠ntS nⅦn3
ancbor」【atl．c8nter」【ancbor＿y at O・Center＿y
Vidtb nⅥm120．O

heigbt nu皿121・O
id nu皿 O

type char oval
center」【num60．O

Center＿y num60・5
maJOr＿aXis nl皿＄0．】O

minor＿aXis at O・皿aJOr＿aXis
id num itypo cbar oval
COnter⊥Ⅹ num35．5

CenterJ at O・COntOr−ymaJOr＿aXi5nlm12・5

定義する図形の例

minor＿aXis atl・maJOr＿aXis
id mⅦm 2

type cbar oval
Center＿Ⅹ】mⅦ181．5

Center−y at O・C8nt￠ー＿ymaコOr＿aXis atl・maJOr＿aXis
minoエーaXis atl・maJOr−aXis〜

4．2．4 アクション

アクションはその図形単語が見つかったときに実行されるTclのスクリプトである。アクションは属性の一つとして記述される。
4．2．5 図形間の関係の記述の例
以下に参照型を用いて図形間の関係を記述する例をあげる。
この例では、右側に示すような3つの円を表している。id Oのものが外側の大きな円、idlのものが内側左の円、id2のものが内側右の円に対応する。まず、それぞれの円は参照型を用いて一つの楕円の長軸と短軸の長さを同じにすることで作られている。内側左の円は内側右の円の半径を参照することで内′側右の円と同じ大きさになっている。内側の二つの円の中心のy座標は、外側の円のy座標を参照することでy座標を揃えている。さらに、定義された図形単語自体の属性弧Chor＿Ⅹ、弧Cbor＿yも参照型を用いて内側左の円の中心に設定している。

4．3 生成されたSpatialParser
ビジュアル言語の定義はエディタによって図形的に、対話的に行なう。定義された文法から最終的に生成されるSpa＆ialParserはPrologの節の集合である。定義されたビジュアル言語の文法はテキスト言語の文法とは異なり、左から右へたどっていく、というような規則はない。そのためマッチングを行っていく過程において頻繁にやり直し（バックトラック）が必要となる。このような処理系を手続き型の言語として生成するのは非常に面倒である。そこで本システムではSpa鳥ialParserとしてPrologの節の集合を生成することとした。このため、生成されるSpatialParserは処理の流れではなく、ルール自体を記述したものとなった。文字情報化された図形単語はいったん内部表現に変換された後、さらに次のようなPrologの表現に変換される。ただしここに−76−示すのは字句解析部の概要のみである。
1ex（Item，［ResIResult】，Interp）：−
VOrdl（Item，Res，Rest，Interp），
1ex（Rest，RosⅦ1t，Int8rp）・
1ex（Item，【Res】Resnlt］，Interp）：−
ⅤOrd2（Iten，Reさ，Rest，Interp），
1￠Ⅹ（Rest，ResⅦ1t，Int￠rp）・

1ex（［］，【］，＿）．

甘Ordl（RestO，Reさult，Rest3，Interp）：−
COmpOnentl＿1（RoさtO，RosⅥ1tl，Re5tl，【】，Interp），
COmpOhentl＿2（Ro＄tl，Result2，Re5t2，［】，Intorp）．
COmpOnOntl■3（Rest2，Result3，Reさt3，【】，In七Orp），
R05ult＝〔〔namelvordl］，【＄izモ＿Ⅹほ0】，［size＿y140］，【ancbor＿Ⅹ10］，［ancbor＿yIO］．
【compllRe＄ultl】，【comp引Reさnlt2】．【comp封Rosult3コ】・
COmpOn￠ntl＿1（［Ⅹけtom］，Re＄ult，Re＄t．Rostt．Intorp）：−
Ⅹ＝【IdlRestO］，

COmp＿Cbar（RostO，［typ0lrectangle】．Resl，Re5tl，［］，Intorp），
COmp＿mm（R08tl，【c00rd＿X】10コ，R082，Rest2，〔】，Interp），
COmp＿nl皿（Rest2．【c00rd＿y120】，Res2，R8St3，［】，エntorp），
COmp＿Cbar（Rest3．トfillIvbite】，R悶4，＿，【】，Intorp），
R05ult三［〔idlId】，〔typelResl】，［c00rd＿ⅩlRes2】，【c00rd＿ylR即3】，トfilllRos4］】
appond（Item，Restt，R88t）．
COmpOnentl＿1（［XlItem］，見ゃsult，Rest，Re＄tt，Interp）：−

CO皿pOnentl＿1（Itom，Result，鮎st，［XIR￠Stt】，Intorp）．
COnPOnentl＿2（【XJItem］．Result，Rest，Restt，Interp）：−

VOrd2（R05tO，Reさじlt，Rest3，Intorp）；−

1e又は与えられた図形に定義済みの図形単語を探し、再帰的に1exを呼び出すことによりすべての図形のマッチングを行なう。1exはさらに上位の述語parseから呼び出されることになる。

wordgは図形単語gの定義である。図形単語Jを構成する図形文字Jl…Jmがあるかどうかを探し、結果として図形単語J自体の属性のリストを作る。

co叩OnentJ＿mは図形文字Jmの定義である。与えられた図形の集合の中から図形文字Jmにマッチするものを探し、結果として図形文字Jmの属性のリストをつくる。
comp＿Char、COmPrnunはそれぞれ文字型、数値型がPrologの節に変換されたものである。

4．4 図形文
このようにして生成されたSpatialParserに与えるデータ（図形の集合）はやはりPrologの問い合わせの形をしていなければならない。本システムではTkのCanvasWidgetに描かれた図形を生成されたSpatialParserへの問い合わせに変換するためのTclのライブラリ（図4の①）も提供する。
実際に変換されたものは次のような形式である。

1ex（［［図形文字1コ，［図形文字2］，図形文字3】，…，［図形文字几】］，Res111t，Interp）
ここで、図形文字或は次の形式をしている。

けd，［属性名11値1］，［属性名21値2］，【属性名31値3〕，…，［属性名ml値m］］

一77−

5 ぁわりに
本論文では仕様を図形で与えてから詳細化していくことによりSpatialParserを自動生成し、生成したSpa−
tialParserを用いてテストを行なうことができるようなシステムについて述べた。生成されたSpatialParserはPrologの節の形をしており、これと、このシステムが同時に提供している図形の集合をPrologの問い合わせに変換するTclのライブラリを組み込むことにより、ビジュアルプログラミングシステムの実装はこれまでよりも容易になるはずである。

関連研究としてはGolinによるSPARGEN【11］があるが、本論文で述べた方法は仕様を与えるのにまず最初に図形を直接用いることができるという点と、生成されたSpatialParserを用いてテストしながらさらに仕様を変えていくという対話的な方法でSpatialParserを作成できるという点において異なる。
現在SpatialLexicalAnalyzerのみではあるが図4の○、◎を実装し、①、①を実装中である。実装中のシステムでは距離の範囲を指定して図形間の位置関係を記述している。しかしこの方法では「接している」、「包含している」、「交わっている」などの抽象的な位置関係を記述するのは難しい。そのため、より抽象的な方法で図形間の関係を記述できるようにする必要がある。また、図形単語の正規表現のようなものを用いて図形のみで仕様を記述する方法についても考察する予定である。

参考文献【1］B．A・Myers．Taxonomiesofvisualprogrammingandprogramvisualization・JournalpfVisualLan−
夕鶴叩eβ肌dComp祝血タ，1（1）：9つL123，1990．

［2】K．Ueda：GuardedHornClauses，ICOTTechnicalReportTR−103，ICOT，1985．
［3］J・Tanaka：VisualProgrammingSystemforParallelLogicI！anguageS，TheNSF／ICOTWorkshopon
Paral1elLogicProgrammlnganditsProgramEnvironments，theUniversityofOregon，pp・175−186，

1994．
【4】中野勝次郎，田中二郎‥ビジュアルプログラミングシステムにおけるモデルの視覚化アルゴリズム，インタラ
クティブシステムとソフトウェアII，日本ソフトウェア科学会WISS，94，竹内彰一編，近代科学社，pp205−
214，1994．
【5】J・RekersandA・Schurr・Agraphgrammarapproachtographicalparsing・Technicalreport，LeidenUniversity，1995．avai1ableviaftpfromftp−SerVerftp．wi．leidenuniv．nl，fi1e／pub／CS／TechnicalReports／1995／tr95−15．ps．g2：〔6】C・Crimi，A・Guercio，G・Nota，G・Pacini，G・Tortora，and九年・Tucci・RelationgrammarSandtheirq）pli−
C？tiontomulti−dimensional1anguageS．hurnalqfⅥsualLan9ua9eSandCo叩utin9，pageS333−346，1991．
［7］K・Wittenburg，L・Weitzman，andJ・Talley・Unification−ba5edgrammarsandtal）ularparsingforgraph−
icallanguages．JournalqfmsualLan9ua9eSandCoITtPutin9，pageS347−370，1991・［8］S−K．Chang，M．J．Tauber，由，Ⅵユ，andJ−S．Yu．Avisual1anguageCOmPiler・IEEEIhnsactions oβ埴びαrej才乃夕虞犯eer亘れg，15（5）：506−525，1989・【9］EJ・Golin・Parsingvisuallanguageswithpicturel町OutgrammarS・JournalpfVisualLan9ua9eSandCo叩p≠加タ，pageS37ト393，1991．

［10］軋HelmandK・Marriott・Declarativespecificationofvisuallanguages・InPrbceedin9S1990ml仇rkshoponl′1suaLLan9ua9eS，pageS98−103，1990・【11］E．J．GolinandT．Magliery．Acompilergeneratorforvisua11anguages．Ⅰムproceedin9S1993I
助汀岬0β有礼mOれⅥβ祝αJエαれタ伽叩eβ，pageS314−321，1993・

ー78−