LMNtal 開発環境の設計と実装スケーラブルな可視化機能を備えた

(1)

2007 年度修士論文

スケーラブルな可視化機能を備えた LMNtal 開発環境の設計と実装

提出日 : 2008 年 1 月 31 日指導 : 上田和紀教授

早稲田大学大学院理工学研究科情報・ネットワーク専攻

学籍番号 : 3606U070-4

中野敦

(2)

概要

LMNtal は階層グラフの書き換えに基づく並列言語モデルである．基本要素は

アトム，リンク，膜，ルールである．膜はアトム，膜，ルールの多重集合を持ち，

階層構造をなしている．また，アトムは互いにリンクで接続され，グラフ構造をなすことができる．階層グラフ構造がルール（書き換え規則）によって書き換えられることで処理が進行する．そのため，簡潔な構文を持つ言語であるものの，規模が大きくなるにつれ処理の進行の把握が困難となる．一方で，少ない基本要素から階層グラフ構造をなしているプログラムであるため，可視化が容易に行える．

これらの理由から， LMNtalプログラムの理解にはテキスト表現によるグラフ構造の提示よりも，可視化による視覚的な情報提示が有効であると考える．

現在Javaによる実装が進んでいるLMNtal処理系には，以前から可視化機能が組み込まれており，ある程度の可視化が可能となっている．しかしながら，この可視化機能は，大規模なグラフを扱うことを前提としておらず，膜やアトムの数が多いグラフや，リンクが複雑なグラフなどではグラフが振動や発散により安定しないという問題があった．

そこで，本研究では，階層グラフの可視化と同時に開発環境を備えたツールUNYO UNYO の設計と開発を行う．UNYO UNYO はLMNtalで記述される階層グラフを力学などをとりいれた再配置アルゴリズムにより再配置される過程をリアルタイムに可視化する．またユーザからの入力により任意の構図にグラフを配置するインタラクティブな制御機能を持つ．さらに，大規模なグラフを扱うことも想定し，スケーラビリティを意識した設計を行っている．スケーラビリティの向上により，より大規模なグラフを処理可能となった．本論文では，これらの機能の設計方針や，その実装方法について述べる．

(3)

第 1 _{章はじめに}

1.1 _{研究の目的と背景}

LMNtal は階層グラフの書き換えに基づく並列言語モデルである．基本要素は

アトム，リンク，膜，ルールである．膜はアトム，膜，ルールの多重集合を持ち，

階層構造をなしている．また，アトムは互いにリンクで接続され，グラフ構造をなすことができる．階層グラフ構造がルール（書き換え規則）によって書き換えられることで処理が進行する．そのため，簡潔な構文を持つ言語であるものの，規模が大きくなるにつれ処理の進行の把握が困難となる．一方で，少ない基本要素から階層グラフ構造をなしているプログラムであるため，可視化が容易に行える．

これらの理由から， LMNtalプログラムの理解にはテキスト表現によるグラフ構造の提示よりも，可視化による視覚的な情報提示が有効であると考える．

現在Javaによる実装が進んでいるLMNtal処理系には，以前から可視化機能が組み込まれており，ある程度の可視化が可能となっている．しかしながら，この可視化機能は，大規模なグラフを扱うことを前提としておらず，膜やアトムの数が多いグラフや，リンクが複雑なグラフなどではグラフが振動や発散により安定しないという問題があった．

そこで，本研究では，階層グラフの可視化と同時に開発環境を備えたツールUNYO UNYO の設計と開発を行う．

1.2 論文構成

本論文の構成は下記の通りである．

• 第2章

LMNtalの言語の概要について解説する．

• 第3章

UNYO UNYO の設計について述べる．

• 第4章

システムの Mediator 部の設計と実装について述べる．

(6)

1.2 論文構成 2

• 第5章

システムの Graph Container 部の設計と実装について述べる．

• 第6章

システムの Calculator 部の設計と実装について述べる．

• 第7章

システムの Interface 部の設計と実装について述べる．

• 第8章

実装したUNYO UNYOと関連研究との比較検討と，今後の課題について述

べる．

(7)

3

第 2 _章 LMNtal _言語解説

2.1 LMNtal _言語解説

本章では，LMNtal（Linked Multisets of Nodes transformation language）言語仕様について説明する．

2.1.1 _概要

LMNtalは主に以下の４要素から成る．

• 基本の要素であるアトム

• 要素を繋げるリンク

• 要素の多重集合である膜

• 書き換え規則であるルール

本節ではこれらを中心に説明していく．

2.1.2 アトムとリンク

アトムは，LMNtalの基本要素であり，名前と0本以上のリンクを保持する．名前とリンク数の組をファンクタと呼び，n本数のリンクを持つアトムをn価のアトムと呼ぶ．2本のリンクを持つaという名のアトムをa(X, Y)と表記し，リンクの順番が異なるa(X, Y)とa(Y, X)のようなものは別物として扱われる．また，リンクは要素を１対１で接続するものである．多重集合の書換えに基づく言語と比較すると，リンクの存在は特徴的であり，これを利用することで接続先の取得を定数時間で行え，処理の高速化が図れる．

図2.1は，LMNtalのグラフ構造の構文に即したテキスト表現と，図示したものの対応を表している．図の円はアトムを表し，その中の文字はアトム名を表す．アトム同士をつないでいるのはリンクであり，その横の文字がリンク変数名である．

また，円に付いている矢印はリンクの順序を表している．（たとえば，図中のアトムaはリンクの順番がW,X,Yであることを示している．）

(8)

2.1 LMNtal言語解説 4

図 2.1: 図とテキストによるグラフ構造の表現

2.1.3 膜

膜は，アトムや膜など要素の多重集合を保持する仕組みである．膜を要素として保持できるため，階層的なグラフ構造を実現する．これにより，データの階層構造などを表現できる．なお，膜およびその中身をあわせてセルと呼び，膜，アトム，ルールをあわせてプロセスと呼ぶ．書き換え規則ルール2.1.4は膜に所属し，膜内のグラフ構造に対して書き換えを行う．

図 2.2: 膜によるグラフ構造の階層化

図2.2ように，膜は任意の数のアトム，膜，ルールを保持できる．この図をテキスト表現すると次のようになる．

¶ ³

{

{a(X)} , b(X,Y), {c(Y)}.

{a(A)}:-{d(A)}.

µ} ´

アトムaとアトムcはそれぞれ膜の中に囲われていて，アトムa，アトムcの膜とアトムbは更に上位の膜に囲われている．（ルールについては2.1.4で詳しく述べる．）アトムaの膜とアトムcの膜のように，兄弟関係にあるものを兄弟膜と呼ぶ．

(9)

2.2 言語仕様 5 同様にして，親，子，先祖，子孫の関係にあるものをそれぞれ親膜，子膜，先祖膜，子孫膜と呼ぶ．また，あるプロセスを囲う最も内側の膜を所属膜と呼ぶ．

2.1.4 _ルール

ルールはグラフ構造のある特定部分を書き換える規則を表す．2.1.3で述べたように，ルールは膜に所属するため，自身が所属する膜内のプロセスのみを書き換えることが出来る．したがって，所属膜，およびその子膜は書き換えることが出来るが，所属膜の先祖膜や，兄弟膜は書き換えることはできない．図2.2に書いたルールは，アトムaを含む子膜をアトムdを含む膜に書き換えることを意味する．

2.2 _言語仕様

2.2.1 LMNtal の構文

LMNtalの構文は??のように示される．Xはリンク（リンク変数）を表す．pは

アトム名，ルール変数名，プロセス変数名として使われる．また，数もアトムとして扱われ，アトムの名となる．pは大文字以外から始まる文字列で表される．

構文上の曖昧さをなくす目的として()を用いる．また，moleculeを構成する , はルールを構成する :- より強く結合する．

プロセス変数は「膜内にある膜，アトムで，ルール中で特定されていないもの全ての膜およびアトム」を表し，ルール変数は膜内の全てのルールにマッチする変数である．ただし，プロセス変数は，マッチする膜，アトムがない状態，つまりルール中で全ての膜，アトムが指定されているものにもマッチする．

{inu. neko. {hone. {sakana} } } {inu $p}:-pets.

この場合$pは以下を表す．

neko. {hone. {sakana} }

inuはルール中で特定されているので，プロセス変数には含まれない．また，左辺に現れるプロセス変数は，膜ごとに高々1回出現することができる．また，左辺で重複するプロセス変数は使用することができない．

ルール変数は膜内の全てのルールにマッチする変数である．ただし，ルール変数は，ルールの持たない膜にもマッチする．

{inu. neko. hone:-sakana. } {inu @p}:-pets.

(10)

2.2 言語仕様 6

P ::= 0 (空)

| p(X₁, . . . , X_m) (m≥0) (アトム)

| P, P (分子)

| {P} (膜)

| T:- T (ルール)

T ::= 0 (空)

| p(X₁, . . . , X_m) (m≥0) (アトム)

| T, T (分子)

| {T} (膜)

| T:- T (ルール)

| @p (ルール変数)

| $p[X₁, . . . , X_m|A] (プロセス変数)

| p(*X₁, . . . ,*X_m) (m >0) (アトム集団)

A ::= [] (空)

| *X (リンク束)

表 2.1: LMNtalの構文この場合pは以下を表す．

hone:-sakana.

また，左辺に現れるルール変数はプロセス変数同様，膜ごとに高々1回出現することが出来る．また，左辺で重複するルール変数を使用することは出来ない．

2.2.2 _ガード

T:- G|Tの形のルールを書く事ができる。このGの部分をガードと呼ぶ．ガードは，ガード内に記述された条件を満たすものにだけマッチするように，左辺のプロセスに制約を加える．複数の条件を指定する場合は， , で区切る．

2.2.3 型付きプロセス文脈

ガードに型制約を記述することで，1本のルールで可算個のルールを記述することが出来る．

inu(N):-N >= 0, N < 5 | neko.

このようなルールを書くと，以下のようなルールに同義となる．

(11)

2.2 言語仕様 7 inu(0):- neko.

inu(1):- neko.

inu(2):- neko.

inu(3):- neko.

inu(4):- neko.

したがって，

inu(0). inu(3). inu(5). inu(10).

は，

neko. neko. inu(5). inu(10).

に書き換えられる．

(12)

8

第 3 _章 UNYO UNYO _の設計

この章では UNYO UNYO の設計について解説する．

3.1 システム概要

本システムは階層グラフ書き換え言語である LMNtalのスケーラブルな開発環境として設計されている．

本研究のスケーラビリティとは，より大規模なグラフの描画や再配置などがスムーズに行えることをさし，また大規模なグラフにおいての可読性をさす．

また，以前の可視化機能では振動や発散により再配置が不安定な状態に陥ってしまうような複雑な構造をなしたグラフ構造も安定した状態で再配置が行えるよう設計している．

UNYO UNYO は，再配置の過程もリアルタイムに描画するため，グラフ構造の

変化も視覚的にとらえやすく，ユーザによる直観的な操作で再配置を制御するインタラクティブなインタフェースを有する．

図 3.1: UNYO UNYO

(13)

3.2 処理系との結合度 9

3.2 _{処理系との結合度}

LMNtal処理系は現在も活発に開発が進められており，処理系の仕様変更や，新

しい処理系の開発などが行われている．そのため UNYO UNYOは LMNtal 処理系との結合度を最小限に抑え，これらの変化に対し柔軟に対応できるよ設計している．この効果は Mediator モジュールにより実現されるが，詳細は章??にて述べる．

3.3 _{各システムの分離}

UNYO UNYO では，担当する機能ごとにシステムを分離しモジュールとして

独立させている．各機能ごとの責任を明確にすることで，拡張性や運用性などを高めている．

システムは表3.1に示すモジュールに分けることができる．（各モジュールの詳細については後述する．）

各モジュールの関連は図3.2に示す．

モジュール名主な役割

Mediator 処理系と UNYO UNYO の仲介を担い結合度を低く保つ

Graph Container 処理系と UNYO UNYO の持つグラフ構造を矛盾なく管理する

Calculator 目的地算出と移動処理を担う

Interface ユーザに対するすべての入出力を担う

表 3.1: モジュール一覧

3.4 関連研究 GMine との比較

インタラクティブに階層グラフを扱うことを前提にした研究は少ないが，近い設計概念をもつソフトウェアとしてはGMine[2] が挙げられる．GMine は大規模な階層グラフをインタラクティブに扱うことを目標としている．

ただし，UNYO UNYO とは異なり，対象となる階層グラフは静的なものであり，

ユーザによる書き換えは可能であるものの，構造がユーザの入力以外の要因で変化することはない．構造が変化しない特徴を生かし，表示対象となっている階層以外はメモリに乗せないなどの方法により，より大規模なグラフの実行を可能としている．この点では，UNYO UNYO はグラフが LMNtal 処理系により，書き換えられる過程を表示するという性質上，同手法を取り入れることはできない．

(14)

3.4 関連研究 GMine との比較 10

図 3.2: システム構造

図 3.3: GMine の実行例

(15)

11

第 4 _章 LMNtal _{処理系との仲介モ} ジュール Mediator _の設計と実装

この章では LMNtal処理系との仲介を担う Mediator部を解説する．

4.1 主な役割

Mediator部は LMNtal処理系との仲介を担当し，処理系の変更に伴う影響を吸

収する．

Mediator 部が担当する処理を以下に示す．

• 処理系の初期化

• 処理系への実行コードの指定

• 処理系の実行制御

• 処理系からグラフ構造の取得

• 処理系へのグラフ構造書換え命令

4.2 処理系の初期化・実行コードの指定

Java で実装された現在の LMNtal 処理系には「最適化」，「シャッフル」などとといったオプションが用意されている． UNYO UNYO では，実行する LMNtal プログラムを指定する際に同時にオプションを指定することができる．

実行するプログラムを指定すると，図4.1で選択したオプションが有効になるよう処理系を初期化し，実行するプログラムを引き渡す．同時に．UNYO UNYOからの実行であることを通知し，処理系の出力（通常は標準出力）やグラフ構造を

UNYO UNYO が受け取れるよう設定する．

(16)

4.3 処理系の実行制御 12

図 4.1: オプションの選択

4.3 処理系の実行制御

LMNtalはルールをグラフに適用することでプログラムが進行していく．UNYO

UNYO ではこのルールの適用回数を制御することでプログラムの進行を制御することが可能である．

UNYO UNYO から起動されたLMNtal処理系はルールの適用毎にUNYO UNYO へ次のルール適用へ進んでよいか問い合わせを行うようになっている． UNYO UNYO はユーザから指定された実行回数に達するまで許可を出す．処理系は実行許可が得られない場合は，一定時間スリープし再び実行許可を求める処理を繰り返す．

ユーザは実行回数を ’Go ahead’ ボタンの左の数値により入力することができる．

ただし，ユーザによる実行回数の入力は Interface 部の役割であり，Mediator 部は Interface部から実行回数の値を受け取る．

図 4.2: 実行回数の指定

(17)

4.4 処理系からグラフ構造の取得 13

4.4 処理系からグラフ構造の取得

UNYO UNYO は自身では LMNtal プログラムをグラフ構造に変換することが

できないため， LMNtal 処理系に実行するプログラムを渡しグラフ構造に変換する．処理系が変換したグラフは Mediator が受け取り Graph Container へ格納する．

また，Mediatorは処理系によるグラフ書換えの通知も受け取る．グラフが書き換

えられた場合は，Graph Containerへ通知し，Active Nodeの情報を更新させる．

ただし，Active Node と Nodeの同期をとるのは Graph Container の役割であるため，Graph Container への通知までが Mediator の役割となる．

4.4.1 _{差分の利用}

LMNtal処理系により書き換えらたグラフは Graph Container で解析され変更を Acitve Node に反映させることになるが， Graph Container でグラフ全体をチェックし，変更箇所を見つけ出すには高いコストがかかる．そこで，Meidator は処理系からグラフの差分情報をのみを受け取る．

差分情報は以下の六種類である．

• 生成されたアトム

• 削除されたアトム

• 変更されたアトム（リンクの張り替えを含む）

• 生成された膜

• 削除された膜

• 変更された膜

(18)

14

第 5 章グラフ構造管理モジュール Graph Container _の設計と実装

この章ではNode およびActive Nodeの管理を担う Graph Container部を解説する．

Graph Container の役割はNode と Active Node の対応をとり， LMNtal処理系に依存ずにグラフを扱うためのインタフェースをシステムに提供することである．

5.1 Node

Node とはLMNtal処理系が保持するグラフ構造のアトムや膜を指す．

Graph Container 部の役割の一つに LMNtal処理系を意識しないグラフへのインタフェースを提供することがる．UNYO UNYO は将来 LMNtal 処理系が変更された場合でも柔軟に対応させるため， LMNtal処理系とシステムの結合度を低く抑える必要がある．一方でメモリ消費量の抑制などの問題から LMNtal 処理系の扱うグラフのスナップショットのようなものを保存する方法は避ける必要がある．

そこで， LMNtal 処理系のグラフへリアルタイムにアクセスするメソッド群を用

意した．これによりシステムはグラフのアトムや膜といったオブジェクトにたいして， Node として容易にアクセスすることが可能となる．

5.2 Active Node

Active Node は UNYO UNYO が LMNtal 処理系のNode を元に生成する．

UNYO UNYO は必ずしも LMNtal 処理系の保持するグラフをすべて可視化する

わけではなく，必要に応じて必要な Node のみActive Node として生成し，可視化する．不要な Node の Active Node 化を行わないことで，メモリや処理コストを軽減する．

Active Node は対象となる Node を元に以下の情報を生成する．

• ID

(19)

5.2 Active Node 15

• 名前

• 描画用のリンク

• 再配置計算用のリンク

• 活性状態

• 目的地座標

• 現在座標

• 色・形・サイズ

ID

IDは LMNtal処理系が生成する各 Node固有の識別子を元に生成するすべての

Active Nodeで固有の識別子である．システムはこのIDをもとに Active Nodeを一意に識別できる．

名前

名前は Node の名前情報を元に取得する．メモリなどの観点からは Node からの取得が好ましいが，名前情報の使用頻度が描画毎と高いため Active Node に持たせる．

描画用のリンク・再配置計算用のリンク

Active NodeはCalculator 部（6）で使用するリンク対象と，描画上のリンク対象がことなることがある．そのため，冗長になる可能性があるが，描画上のリンクと再配置計算用のリンクを別に保持する．

活性状態

活性状態は，Active Node の移動の必要性を示す．現在座標と最適な座標が同じ場合，（移動しない）移動処理を繰り返し行うことになる．そこで，移動が行われなかった Active Node は非活性状態とされ，移動処理をスキップする．詳細は 6.3にて述べる．

(20)

5.2 Active Node 16

目的地座標・現在座標

Active Node は，非活性状態になるまで，移動を続ける．ただし，最適な位置

（座標）の算出はコストが高く，計算に時間がかかる事がある．そこで，目的地座標と現在座標とを保持し，次の最適な位置を算出するまでの間この座標への移動

（現在座標の書換え）を続ける．これにより，大規模なグラフなどで，最適な位置の再計算を待つタイムラグをなくし，見た目上スムーズな移動を提供する．

色・形・サイズ

Active Node化されたNode は視覚化されるため，色，形，サイズ（大きさ）と

いった情報を保持する．色は名前を元に算出される．また，形やサイズはNodeの種類（アトム・膜）によって異なる．アトムである場合には，システムで指定されている固定値によって決められる．膜である場合は，形はシステムによって指定された形となるが，サイズは子 Node の座標によりサイズが変動する．

(21)

17

第 6 _章 Active Node _{の再配置モ} ジュール Calculator _の設計と実装

この章では目的地座標算出処理と移動処理を担うCalculator 部を解説する．

Calculator 部では，Graph Container に格納されている Active Node に対し，目的地の座標の算出と，実際の移動処理を行う．また，目的地の算出と実際の移動処理とは別スレッドで非同期的に行われている．詳細は節6.2にて解説する．

6.1 目的地算出処理

6.2 移動処理と目的地算出処理の分離

目的地座標の計算には，ばねモデル，リンクの角度調節，斥力，引力など複数のアルゴリズムを使用している．各アルゴリズムの利点を生かし，複合的な視点から最適な配置座標を計算するためである．また，それぞれの計算から算出された座標を平均化することで決定する．

ただし，最適な配置を計算するためには高いコストがかかるため，処理時間が延びてしまうという問題があり，大規模なグラフをリアルタイムに再描画するための課題の一つとなっていた．

そこで， Calculator 部では，各 Active Node に最適と思われる座標を記憶させ，

移動の際はこの最適座標へ向かって一定距離ずつ移動させるといった方法をとった．この処理の利点は，コストの高い座標計算演算処理と比較的コストの低い移動処理とを切り分けれるところにある．これにより，目的地の算出処理と，移動処理とを別スレッドとして非同期的に実行するよう実装出来た．

移動処理が，設定された目的地まで１ステップで移動しないため，一度目的地を算出すると一度以上の移動処理が行える可能性があり，目的地算出処理と移動処理を同期させて実行す必要がなくなる．

移動処理が実行されると Active Node 同士の位置関係が変化するため目的地を変更する必要性がある．ただし，一度の移動処理で移動する距離は一定に制限され

(22)

6.3 活性度による負荷軽減 18 ているので，位置関係が大きくは変化しないと期待できる．そのため，目的地の算出は移動処理よりも低い優先度で実行することがで出来る．

6.3 _{活性度による負荷軽減}

Active Nodeには活性状態に関するフラグを保持している．活性状態にあるAc-

tive Nodeは，目的地座標の計算を行い，移動処理を行うが，活性状態にないActive Node はいずれも行わない．これにより，現在地と目的地が等しいActive Nodeに対して，不要なコストをかけなくて済むようになる．

活性状態にある Active Node が，移動処理を行う際，現在地と目的地が等しかった場合，移動が完了したものとみなされ，非活性状態に置かれる．

Interface 部はこの活性度を監視しており，すべてのActive Node が非活性状態になった場合，再描画を停止する．（ウィンドウの移動などによる再描画は行われる．）これにより，すべての Active Node の移動処理が終わった場合，再描画にかかるコストがほぼなくなる．

6.3.1 活性状態の伝播

非活性状態にある Active Node も，周囲の状況が変化することにより，活性状態へともどる必要が出てくることがある．

以下に Active Node が活性化される条件の以下に示す．

• リンクで接続される Active Node が移動した時

• 子 Active Node が移動した時

• ユーザによって強制的に移動させられた時

6.4 リンク構造のフラット化

UNYO UNYOでは，階層の違う Active Node を繋ぐリンクがあった場合，階

層が同じ Active Node 同士になるよう，親のActive Node へリンク関係を移譲する．つまり，図6.1の関係は，図6.2 と見なされる．ただし，LMNtalでは膜はリンクを持たないので，図6.2のプログラムはLMNtalとしては正しくなく，あくまで目的地計算上での考え方である．

リンク構造のフラット化はグラフが位置的に発散しないようにするためのものである．フラット化しないグラフの場合，階層構造などが影響し近づけないActive Node などが引き合い，無限に膨張することがある．この問題を抑制するため，リンク構造をフラット化し簡潔にする必要がある．

(23)

6.5 ばねモデル 19

¶ ³

{a(X)}, {{ b(X) }}

µ ´

図 6.1: リンク構造のフラット化前

¶ ³

{a}(X), {{b}}(X)

µ ´

図 6.2: リンク構造のフラット化後

6.5 ばねモデル

LMNtal でアトム同士がリンクで接続される状態を UNYO UNYO ではアトム

に対応する Active Node 同士を線で結ぶことで表現する．そのため，接続されて

いる Active Node が遠距離にある場合，リンクを表す線が長くなってしまう．

この問題を解消するため，リンクで結ばれた Active Node は互いを一定距離に置こうとする力を互いに働かせる．互いに働かせるのは，相手に与えた力と逆向きの等しい力を自分に与えないとグラフ全体が移動してしまうためである．

また，同じ Active Node 間で多重リンクがある場合は，力のバランスおよび，計算量の軽減のため一本のリンクとして計算する．

リンクの長さは以下のアルゴリズムで求める．

図 6.3: リンク構造のフラット化

(24)

6.5 ばねモデル 20

図 6.4: 近すぎるものを引き離す

図 6.5: 遠すぎるものを近づける

¶ ³

// node1 と node2 の最適長を求める dx = node1.x - node2.x;

dy = node1.y - node2.y;

l = sqrt(dx * dx + dy * dy);

dw = node1.width + node2.width;

dh = node1.height + node2.height;

if(node2 が node1 の左または右側に位置する){

h = (node1.height + node2.height) / 2;

y = abs(dy);

value = (l * h) / y;

} else {

// node2 が node1 の上または下に位置する w = (node.width + node2.width) / 2;

x = abs(dx);

value = (l * w) / x;

}

// MARGIN は node1 と node2 が密着しないための余白 return (value + MARGIN)

µ ´

(25)

6.6 角度調節 21

6.6 _角度調節

6.5で解説したように，Active Node同士はリンクで結ばれることがある．一つの Active Node が複数のActive Node にリンクを接続している場合，たがいの位置関係を見やすくする必要がある．そこで，リンクの線が等間隔に表示されるようにリンクで接続されているActive Nodeの座標を移動させる．この場合も，6.4 で解説したのと同様にリンク構造をフラット化する必要がある．

リンクの角度は，リンクが２本以上の場合に調節される．また，角度はあるリンクから見てひとつ前のリンクと次のリンク（つまり前後のリンク）の真ん中を最適位置とする．これにより，計算されるごとにすべてのリンク間の角度が次第に等しくなっていく．

図 6.6: 目的地座標の算出

上図では，a というアトムを中心に，b ，c ，d という三つのアトムがリンクで繋がっている．この中で，アトム d に注目し，目的地座標を考えると，左側の配置ではc - d 間の角度がd - b 間に比べて狭くなっている．そこで，アトム dが

c - b 間を二等分するよう座標を， dの目的地座標とする．

詳細なアルゴリズムは以下に示す．

(26)

6.6 角度調節 22

¶ ³

// node に接続されているリンクの最適な角度を求め，node とリンク先の

// Active Node を移動させる．

// nthAngleArray はリンクのそれぞれの角度の配列

// nthNodeArray はリンクによって接続されている Active Node の配列 // nthAngleArray と nthNodeArray の配列は対応しているものとする for(i = 0; i < nthAngleArray.length; i++ ){

ActiveNode nthNode = nthNodeArray[i];

anglePre = (i != 0) ?

nthAngleArray[i] - nthAngleArray[i - 1]

: (PI * 2) - nthAngleArray[nthAngleArray.length - 1]

+ nthAngleArray[0];

angleCur = (i != nthAngleArray.length - 1) ? nthAngleArray[i + 1] - nthAngleArray[i]

: (PI * 2) - nthAngleArray[nthAngleArray.length - 1]

+ nthAngleArray[0];

angleR = angleCur - anglePre;

dx = nthNode.x - node.x;

dy = nthNode.y - node.y;

edgeLength = sqrt((dx * dx) + (dy * dy));

if(edgeLength == 0.0){ edgeLength = 0.00001; } tx = -dy / edgeLength;

ty = dx / edgeLength;

ddx = tx * angleR;

ddy = ty * angleR;

nthNode.move(ddx, ddy);

node.move(-ddx, -ddy);

}

µ ´

(27)

6.7 斥力 23

6.7 _斥力

Active Node を配置する際，Active Node 同士が重なる可能性がある．そこで，

重なってしまった Active Node 同士に互いに反発する力を与えることで，重なりを排除する．

図 6.7: 斥力

斥力のアルゴリズムを以下に示す．

(28)

6.7 斥力 24

¶ ³

// node1 と node2 の斥力を計算する if(node1 と node2 が重なっていない){

break;

}

dx = node1.maxX - node2.minX;

// node1 が node2 の右にあった場合 if(dx < 0){

dx = node1.minX - node2.maxX;

}

dy = node1.maxY - node2.minY;

// node1 が node2 の下にあった場合 if(dy < 0){

dy = node1.minY - node2.maxY;

}

// 半分ずつ双方を移動する dx /= 2;

dy /= 2;

node1.move(dx, dy);

node2.move(-dx, -dy);

µ ´

上記のプログラムをすべてのActive Nodeの組み合わせに対し行うことで，すべてのActive Nodeの重なりを解消することが期待できる．ただし，すべてのActive Nodeの組み合わせになると，グラフのサイズに伴い計算量が膨大になってしまう．

そこで，重なっている可能性のある Active Nodeをある程度選別する必要がある．

そこで，以下の二つの方法を導入する．

• 階層が違うものは処理しない

• 空間分割を行い対象を限定する

まず，階層構造を意識して，階層が違うものを判別対象としないことで，階層が多いグラフでは計算量を抑えることが期待できる．ただし，この方法だと，一つ

(29)

6.8 引力 25 の階層に多くの Active Node が存在する場合には有効ではない．そこで，二点目の，空間分割を取り入れる．空間分割は，一定のサイズで空間を分割することと，

一定の数で空間を分割することができるが，グラフの最大サイズが予測できないため一定数の分割を採用した．本来はグラフのサイズに応じて分割数を調節すべきだが，今は実装されていない．

また， Active Node は大きさがあるので，複数の空間に所属する可能性がある．

所属する空間は図6.8に示す例の場合，AからDの各１から３の計12箇所にとなる．Active Node は選択されたすべての空間と関連付けられる．すべての Acitve

図 6.8: 所属する空間の選択

Node の関連付けが終わった後，空間ごとに関連付けられているActive Node について重なりを判定する．これにより，処理数の軽減が期待できるが，一か所に固まっている場合や，グラフが極端に大きくなってしまった時には効率は悪くなる．

6.8 引力

斥力や，角度調節などによりグラフの再配置を行うと，Active Nodeが広範囲に分散し，隙間が多くなる傾向がある．そこで，必要以上に分散してしまったActive Node を引き寄せまとめる処理が必要となる．

引力は Active Node が所属する親のActive Node の中心へと向かって加えられる．

力は，中心点に一定以上遠い場合は一定とし，十分に近づいた場合は，中心までの距離を力とする．これは，遠方にあるほど強い力がかかってしまうことを防ぐためである．遠方のものほど強い力が加わる方法の場合，ある程度規模の大きい集合の場合，遠方の Active Node が内側のActive Node に必要以上に近付いてし

(30)

6.8 引力 26 まい，安定しなくなる．また，接続対象は親 Acitve Node の中心となり，かつ親 Active Node に対しては力を与えない．

¶ ³

// parentNode 内の node の引力を求める dx = parentNode.centerX - node.x;

dy = parentNode.centerY - node.y;

distance = sqrt(dx * dx + dy * dy);

if(dx == 0.0){ dx=0.000000001; } angle = atan(dy / dx);

if(dx < 0.0) angle += PI;

l = (distance < STEP) ? distance : STEP;

ddx = l * cos(angle);

ddy = l * sin(angle);

node.move(ddx, ddy);

µ ´

ただし，一つ一つの Active Node に対し個別に引力を加えると，分子構造をなしているグラフなどの形が崩れてしまう．そこで，分子構造をなしているAcitve Node は分子単位で同じ引力を加える．これにより，分子単位での形を崩すことなく，移動させることが可能となる.

図 6.9: 引力の計算

(31)

27

第 7 _章 Interface _{の設計と実装}

この章では I/O部の特にインタフェースについて解説する．

グラフの理解についてのスケーラビリティを向上させるためには，理解を助けるための豊富なインタフェース機能が不可欠である．そこで，可視性を補助する縮小地図機能や，膜の開閉機能といったものや，ユーザによる再配置の制御を補助

する Active Node の固定機能や，グラフの回転機能などを実装した．

7.1 _縮小地図

縮小地図とは，現在表示しているグラフの全体を縮小表示する機能である．

図 7.1: 縮小地図（左上ウィンドウ）の表示

ある程度の規模のグラフを表示すると，通常のサイズで表示するとウィンドウのサイズに収まりきらなくなってしまう．しかし，Active Nodeを小さく表示して

(32)

7.2 膜の開閉 28

しまうと Active Node 一つ一つを認識するのが困難になる．そこで，通常のウィ

ンドウと同期してグラフを縮小表示する機能を提供する．

この縮小地図上では常にグラフ全体が収まるように縮小して表示し，通常のウィンドウがどの範囲を表示しているかを赤い枠にて表示する．また，縮小地図上の赤い枠をドラッグして移動させることで，通常のウィンドウの表示位置を移動させることが可能である．

これにより，大規模なグラフにおいても任意の箇所を容易に発見・表示する事ができるようになる．

7.2 _膜の開閉

膜の開閉機能とは，膜のAcitve Node の中身を表示しない状態と，表示する状態とを切り替える機能である．表示してる状態を開いている状態とし，非表示の状態を閉じている状態とする．

図 7.2: 膜の開閉

閉じている状態の膜は，内部のActive Nodeの座標を相対座標として保存し，開状態に移行するときに，現在座標から内部の Acitve Node の座標を決定する．また，閉じた膜の中にある Active Node は移動処理，目的地計算処理，描画処理をスキップし，システムへの負荷を軽減させる．

(33)

7.3 Active Node の固定 29

7.3 Active Node _の固定

Active Nodeの固定とは，ユーザからの操作により， Active Nodeの再配置を強制的に行わなくする機能である．

固定機能は，非活性状態になった Active Node の状態にほぼ等しい．しかし，通常のようにActive Nodeは再配置が完了し，非活性状態になった Active Nodeとは異なり，周辺のActive Nodeの移動などにも影響されず，ユーザが固定を解除しないかぎり非活性状態のままとなる．ただし，固定された Active Node は周辺への影響は与える．つまり，リンクでつながった（固定されていない）Active Node はばねの力により，この固定された Active Node との距離を調節する．

7.4 _{グラフの回転}

グラフの回転とは，現在表示している箇所の（画面上の）中心を中心点として，

グラフ全体を回転させる機能である．グラフの回転を行うと，7.3の機能で固定さ

れた Active Node も含めて回転させる．これにより，ユーザはグラフを任意の点

で任意の角度に傾けることが可能になる．

回転角度は，画面右上の回転操作パネルを回転させると，回転させた角度に応じて決められる．

図 7.3: 回転操作パネル

7.5 _{グラフの編集}

現在，UNYO UNYO にはアトム・膜の名前変更，アトム・膜の追加機能が実

装されている．

名前変更は任意の Active Node を選択後，上部に表示されるパネルの名前部分を

書換え Update ボタンを押すことで可能である．変更された情報は LMNtal 処理

(34)

7.6 その他の機能 30 系へと通知され， Node 情報が書き換わる．

アトム・膜の追加には任意の膜の Active Node を選択し，上部に表示されるパネルから Add Node を押すことで， Node 追加パネルが表示される．Node 追加パネルからは Node の名前と追加するNode の種類（アトム・膜）の選択が可能である．

図 7.4: Node の追加パネル

7.6 _{その他の機能}

再実行前回実行されたファイルを前回と同じオプションで再実行する

イメージ保存表示中のグラフを PNG イメージとして保存する変更箇所強調反応により書き換えが起きた個所を，

背景色を変更することで強調する拡大機能グラフを拡大表示する

Node一覧 Active Node 化可能な Node の一覧を表示する

再配置のOn・Oﬀ 各再配置アルゴリズムの切り替え

表 7.1: 細かい機能

(35)

31

第 8 _{章考察}

8.1 _{差分の利用による効果}

¶ ³

a.

a:-a, a.

µ ´

上記のプログラムを5000回実行するのにかかった時間を計測する．時間は100回毎に計測し，三回の平均をとった．時間は処理系で実行された結果を UNYO UNYO が受け取ってから， UNYO UNYO の保持するグラフ構造の更新にかかる時間とする．つまり， LMNtal 処理系が要する時間は含まない．

結果を図8.1に示す．

図 8.1: アトム一つ生成の所要時間

初回のは，UNYO UNYOの Graph Container等の初期化に時間がかかるため，

二回目以降の実行にくらべ所要時間が大幅に長くなる．二回目以降の実行では，処理系から増加したアトムの情報のみを受け取るので， UNYO UNYO の所持するグラフ構造の更新はグラフのサイズに依存しない結果となった．

図8.1では計算時間の上昇がみられる箇所があるが，これらに再現性はなくランダ

(36)

8.2 可読性 32 プロセッサ Intel(R) Core(TM)2 CPU 6600 2.40GHz 2.40GHz

メモリ(RAM) 2047MB

OS Windows Vista Business

表 8.1: 評価に使用したマシンのスペック

ムに発生する．たとえば，3100 回目では特に顕著な上昇がみられるが，三度の計測のうち，一度だけ上昇したもので，他の二度の計測では特に上昇はみられなかった．これは実装が Java で行われているため，メモリ管理などによる影響も考えられるが，原因は不明である．

8.2 可読性

8.2.1 C70 の可視化

LMNtalで高次フラーレンC70 の分子構造を表現したコードを8.2.1に示す．また，そのコードを可視化したものを図8.3に示す．

高次フラーレンの構造は複雑であるため，テキスト表現でグラフ構造を示されてもフラーレンの構造をなしているこを確認するのは困難であるが，図8.3からその構造を容易に確認することができる．

8.2.2 深さ 3 の四分木の可視化

¶ ³

a.

a :- a(b, b, b, b).

b(X) :- b(c, c, c, c, X).

µ ´

上記のプログラムを LMNtalで実行した例を8.4に示す．

また， LMNtal ではリンクを明記することも可能であるため，以下のコード

（8.5）も8.4と同義である．

同じプログラムを UNYO UNYO で実行した結果を図8.6に示す．

可視化による結果表示はテキスト表現とはことなり，配置が異なることはあっても，表記方法がことなることはない．また，図8.6は再配置機能を使い，配置したものなので，常に同じ配置を再現することも可能である．

(37)

8.2 可読性 33

¶ ³

cc(L1,L10,cc(L2,L19)), cc(L3,L18,cc(L4,L17)), cc(L5,L16,cc(L6,L15)),cc(L7,L14,cc(L8,L13)), cc(L9,L12,cc(L0,L11)),

c(L11,c(L140,c(L130,c(L142,c(L10,L168)))),L168), c(L148,c(L18,c(L19,c(L142,c(L138,L202)))),L202), c(L64,c(L52,c(L60,c(L2,c(L3,L96)))),L96),

c(L68,c(L8,c(L9,c(L62,c(L58,L122)))),L122), c(L54,c(L64,c(L4,c(L5,c(L66,L104)))),L104), c(L14,c(L15,c(L146,c(L134,c(L144,L180)))),L180), c(L7,c(L68,c(L56,c(L66,c(L6,L118)))),L118), c(L12,c(L13,c(L144,c(L132,c(L140,L170)))),L170), c(L136,c(L146,c(L16,c(L17,c(L148,L194)))),L194), c(L130,c(L132,c(L134,c(L136,c(L138,L150)))),L150), c(L58,c(L50,c(L52,c(L54,c(L56,L72)))),L72),

c(L0,c(L1,c(L60,c(L50,c(L62,L80)))),L80)

µ ´

図 8.2: C70 のソースコード

図 8.3: C70 の可視化

(38)

8.2 可読性 34

¶ ³

b(c,c,c,c,a(b(c,c,c,c),b(c,c,c,c),b(c,c,c,c))).

µ ´

図 8.4: 深さ３の四分木結果1

¶ ³

b(_8,_10,_12,_14,_1), b(_17,_19,_21,_23,_3), b(_26,_28,_30,_32,_5), b(_35,_37,_39,_41,_7),

c(_8), c(_10), c(_12), c(_14), c(_17), c(_19), c(_21), c(_23), c(_26), c(_28), c(_30), c(_32), c(_35),

c(_37), c(_39), c(_41),a(_1,_3,_5,_7).

µ ´

図 8.5: 深さ３の四分木結果2

図 8.6: 深さ3の四分木

(39)

8.3 未実装機能 35

¶ ³

b(c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), a(b(c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e))), b(c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e))), b(c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)), c(d(e,e,e,e),d(e,e,e,e),d(e,e,e,e),d(e,e,e,e)))))

µ ´

8.2.3 深さ 5 の四分木の可視化

節??と同様の四分木を深さ5に変更し実行した結果を図8.7と，図8.8に示す．

この例では葉にあたるアトム数が多すぎて末端部分の可読性が著しく低下している．この場合，不要な Acitve Node をインアクティブ化（Active Node を削除する）するなどで対処する必要がある．

8.3 _{未実装機能}

8.3.1 リンクの編集

現在のUNYO UNYO にはアトム・膜の生成が可能であるが，リンクの編集が

行えない．リンクの編集を行う場合，以下の点を考慮する必要がある．

• リンクの始点アトム

• リンクの終点アトム

• 始点アトムでのリンク番号

• 終点アトムでのリンク番号

(40)

LMNtalのリンクは双方向なので，始点・終点は正しくはないが，ここでは便宜上

最初に選択したアトムを始点，次に選択したアトムを終点とする．また，数値型のアトムは1引数であるため，アトム生成時にリンクが必要となる．よって，これらを考慮したインタフェースを考案しなければならない．

8.3.2 グラフの保存

UNYO UNYO 上で作成または編集されたグラフは当然保存する必要性が生じ

る．そのため，表示中のグラフを保存する機能を実装しなければならないが，現在はその機能を有しない．また，グラフ構造のみの保存か座標データ等を含む情報の保存なども考えられる．

8.3.3 _{注目箇所の抽出}

現在はルール適用を行った場合などに生じる新たなNodeはすべて Active Node として可視化される．しかし，生成されがNode が不要な場合逐次非Acitve Node 化するのは現実的ではない．よって，ユーザの要求に応じて，Active Node化するか否かの選択を行う機能が必要である．

選択の条件は以下のものなどが考えれらる．

• 特定の膜の内部に生成されるアトムや膜

(41)

• 特定の情報を持つアトム（名前や，リンク数など）

• 特定のアトムにリンクを持つアトム

• 特定の情報を持つ膜（特定のアトムや膜を含むものなど）

• 特定のルールにより生成されるアトムや膜

また，上記の条件のうち，膜に関するものは閉じた状態での Acitve Node 化などの要求も考えられる．

8.3.4 グラフの参考配置記録

特定の構造をもつグラフにおいて，類似する前例が記録されている場合，その記録を利用して再配置を行う機能が考えれる．この場合，現在実装が進められているカスタマイズ可能な可視化手法[7]とはことなり，グラフ構造とその配置の記録を保持するDBを持つ必要があり，さらにグラフの同型性判別などを行わなくてはならないことになる．

(42)

38

謝辞

本研究を進めるにあたり様々な方の指導・助言をいただきました. まず,ご指導を賜わった上田和紀教授に深く感謝致します.

最後に，入学から現在に至るまで，叱咤激励を私にかけてくれた家族に深く感謝いたします．

眠い中猫の手を貸してくれた猫

2008年2月中野敦

(43)

39

参考文献

[1] 土井淳，伊藤貴之,梶永泰正 , 池端裕子. 階層型グラフデータのための可視化手法. 情報処理学会グラフィクスとCAD合同シンポジウム, pp. 47–50, 2001.

[2] Jose’ F. Rodrigues Jr, Hanghang Tong, Agma J. M. Traina, Christos Faloutsos, Jure Leskovec. Gmine: A system for scalable, interactive graph visualization and mining. VLDB Endowment, pp. 1195–1198, 2006.

[3] Takayoshi Noguchi, Jiro Tanaka. New automatic layout method based on magnetic spring model for object diagrams of omt.Proceedings of International Symposium on Future Software Technology 1998, pp. 89–94, 1998.

[4] 田中二郎. 3次元ビジュアルプログラミングシステム3dppの構築に向けて. 人工知能基礎論研究会(第34回), SIG-FAI-9802, pp. 9–14, 1998.

[5] 豊田正史, 喜連川優. Webrelievo: ウェブにおけるリンク構造の発展過程解析システム. 第12回インタラクティブシステムとソフトウェアに関するワークショップ, pp. 89–94, 2004.

[6] 上田和紀 and 加藤紀夫. 言語モデルLMNtal. コンピュータソフトウェア, Vol. 21, No. 2, pp. 44–60, 2004.

[7] 齊藤和佳子. Lmntal プログラムのカスタマイズ可能な可視化機能の設計と実装. 早稲田大学卒業論文, 2007.

(44)

40

図目次

2.1 図とテキストによるグラフ構造の表現 . . . . 4

2.2 膜によるグラフ構造の階層化 . . . . 4

3.1 UNYO UNYO . . . . 8

3.2 システム構造 . . . . 10

3.3 GMine の実行例 . . . . 10

4.1 オプションの選択 . . . . 12

4.2 実行回数の指定 . . . . 12

6.1 リンク構造のフラット化前 . . . . 19

6.2 リンク構造のフラット化後 . . . . 19

6.3 リンク構造のフラット化 . . . . 19

6.4 近すぎるものを引き離す . . . . 20

6.5 遠すぎるものを近づける . . . . 20

6.6 目的地座標の算出 . . . . 21

6.7 斥力 . . . . 23

6.8 所属する空間の選択 . . . . 25

6.9 引力の計算 . . . . 26

7.1 縮小地図（左上ウィンドウ）の表示 . . . . 27

7.2 膜の開閉 . . . . 28

7.3 回転操作パネル . . . . 29

7.4 Node の追加パネル . . . . 30

8.1 アトム一つ生成の所要時間 . . . . 31

8.2 C70 のソースコード . . . . 33

8.3 C70 の可視化 . . . . 33

8.4 深さ３の四分木結果1 . . . . 34

8.5 深さ３の四分木結果2 . . . . 34

8.6 深さ3の四分木 . . . . 34

8.7 深さ5の四分木 . . . . 35

8.8 深さ5の四分木 . . . . 36

(45)

41

表目次

2.1 LMNtalの構文 . . . . 6

3.1 モジュール一覧 . . . . 9

7.1 細かい機能 . . . . 30

8.1 評価に使用したマシンのスペック . . . . 32

(46)

42

付録

(47)

43

Appendix.A _{ソースコード}

以下にソースコードを記載する。

• FrontEnd.java : 48行

• container/ConﬁgContainer.java : 105行

• container/NodeAttributeContainer.java: 44行

• container/UserConfContainer.java : 96行

• container/OptionContainer.java : 75行

• container/ActiveNodeContainer.java : 245行

• container/NodeContainer.java : 21行

• generator/GraphController Java.java : 180行

• generator/GCFactory C.java : 16行

• generator/GCFactory.java : 11行

• generator/GCBuilder.java : 18行

• generator/GraphController.java : 18行

• generator/GCFactory Java.java : 15行

• manager/NodeActivator.java : 350行

• manager/NodeCalculator.java : 688行

• manager/NodeGroupManager.java : 98行

• manager/InitManager.java : 21行

• manager/NodePainter.java : 284行

• manager/NodeMover.java : 247行

(48)

• manager/NodeSelector.java : 48行

• mediator/LMNtalRuntime.java : 215行

• mediator/Synchronizer.java : 124行

• node/Node Membrane.java : 150行

• node/ActiveNode.java : 396行

• node/Node Atom.java : 236行

• node/ActiveNode Membrane.java : 308行

• node/ActiveNode Atom.java : 114行

• panel/FilterFrame.java : 373行

• panel/ForcePanel.java : 106行

• panel/LogPanel.java : 99行

• panel/MapFrame.java : 29行

• panel/MultiInfoPanel.java : 31行

• panel/OptionChooser.java : 115行

• panel/RulePanel.java : 47行

• panel/CompassPanel.java : 148行

• panel/InfoPanel.java : 82行

• panel/AtomInfoPanel.java : 131行

• panel/CommonKeyListener.java : 61行

• panel/ConfFrame.java : 90行

• panel/MembraneInfoPanel.java : 123行

• panel/ControlPanel.java : 255行

• panel/GraphInfoPanel.java : 9行

• panel/MyPopupMenu.java : 82行

• panel/MainFrame.java : 377行

(49)

• panel/MapPanel.java : 143行

• panel/AddNodeFrame.java : 109行

• panel/GraphPanel.java : 764行

• util/Logger.java : 52行

で合計7400行程度のプログラムを記述した。

LMNtal 開発環境の設計と実装 スケーラブルな可視化機能を備えた

2007 年度 修士論文

スケーラブルな可視化機能を備えた LMNtal 開発環境の設計と実装

提出日 : 2008 年 1 月 31 日 指導 : 上田 和紀 教授

早稲田大学大学院理工学研究科 情報・ネットワーク専攻

学籍番号 : 3606U070-4

中野 敦

目 次

第 1 章 はじめに

1.1 研究の目的と背景

1.2 論文構成

第 2 章 LMNtal 言語解説

2.1 LMNtal 言語解説

2.1.1 概要