JP5147952B2 - システムのモデルを変換する方法、コンピュータ・プログラム及びシステムモデル変換装置 - Google Patents

Description

本発明は、システムのモデルを変換する方法、コンピュータ・プログラム及びシステムモデル変換装置に関する。

ソフトウェアや製造業におけるシステムのモデルを、複数の視点から横断的に記述する場合に、かかわるモデルの要素の規模が大きくなると、横断的な記述のための抽出作業が非効率になることが知られている。例えば、制約を形式的に記述する手法が、従来いくつか提案されている。しかし、制約の数が大きくなると、効率的に制約を分析・編集することが困難になる。汎用グラフィカル・モデリング言語であるＳｙｓＭＬ（Ｓｙｓｔｅｍｓ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）のＰＤ（Ｐａｒａｍｅｔｒｉｃ Ｄｉａｇｒａｍｓ）やＶｉｓｕａｌ ＯＣＬ、Ｃｏｎｓｔｒａｉｎｔ Ｄｉａｇｒａｍｓは、制約と、制約を満たすべきシステム構成要素との関係を、ブロックとリンクとを用いて視覚的に記述することができる。しかし、多数のシステム構成要素がかかわる制約を記述しようとすると、ダイアグラム中に多数のブロックとリンクとがひしめきあい、複雑化するので、効率的な制約の分析と編集とが難しくなる。今日、ますます大規模で複雑なシステムが作られるようになっており、多数のモデル要素を階層的かつ複数の視点に基づいて分析・編集することが重要になる。

一方、大量のデータを対象として分析を行う手法の１つとして、ＯＬＡＰ（Ｏｎｌｉｎｅ Ａｎａｌｙｔｉｃａｌ Ｐｒｏｃｅｓｓｉｎｇ）が知られている。ＯＬＡＰでは、リレーショナルデータの構造を、スナップショットとして多次元データモデルに展開することで、データの分析を行う手法であり、最終分析結果は、Ｔａｂｌｅ／Ｍａｔｒｉｘ形式に展開されることが自然な定義となる。ＯＬＡＰは、すでに業務における様々な分析に広く用いられており、手法も確立したものになっている。逆の見方をすると、表形式による大量データの効率的な分析手法は、システム記述においても有望であることが考えられる。

しかし、システムを記述するためのＳｙｓＭＬ、車載組み込みソフトウェア記述の標準であるＡｕｔｏｓａｒ（登録商標）（Ａｕｔｏｍｏｔｉｖｅ Ｏｐｅｎ Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ）、制御システムの記述で一般的なＳｉｍｕｌｉｎｋ（登録商標）等、ほとんどの言語では、一般的なグラフ構造を基本データモデルとして持っており、リレーショナル形式のデータ構造とはなっていない。したがって、Ｔａｂｌｅ／Ｍａｔｒｉｘとして分析を行うためには、両者のデータモデルを適切に対応付けすることが必要になる。

グラフ構造を有するグラフモデルとリレーショナルモデルとの対応付けとしては、種々の方法が開示されている（例えば、特許文献１〜３）。特許文献１に記載のネットワーク型データベース問い合わせ制御システムは、ネットワーク型データベースにおけるレコード間の関係をセットを用いて定義する外部スキーマ情報と、ネットワーク型データベースを記憶装置上に格納する形態を定義する内部スキーマ情報とにしたがって、リレーショナル型データベースにおいてカラム情報及びセット情報からなるネットワークモデル情報を生成する。そして、ネットワーク型データベース問い合わせ制御システムは、このネットワークモデル情報とリレーショナル型データベースに対する問い合わせ文とからネットワーク型データベースに対する問い合わせを実行するものである。

特許文献２に記載の関連情報変換装置は、データベース用の関連情報のデータ構造を入力する入力手段と、入力手段からの情報をｎ次元ユークリッド空間等の距離空間内での関連情報表現にて格納する属性表現格納手段と、入力手段からの情報をノード及びアークで構成されるグラフ構造の関連情報表現にて格納するグラフ表現格納手段と、属性表現格納手段により格納された情報及びグラフ表現格納手段に格納された情報を相互変換する属性表現・グラフ表現変換手段と、属性表現格納手段に格納された情報もしくはグラフ表現格納手段に格納された情報を関連情報のデータ構造として出力する出力手段とを備えるものである。

特許文献３に記載のデータベースモデル変換方法は、ネットワークモデルによるデータベースにおけるグループそれぞれに対応させてテーブルを生成し、子グループに含まれていた子レコードに親子関連情報及び順序情報を付加してから子テーブルに格納するものである。

特開平５−２７４３４８号公報 特開平６−２５０８９６号公報 特開２０００−２６７９０６号公報

しかしながら、特許文献１〜３に開示されているシステム等は、いずれもモデル変換において得られる関係データベースのテーブル同士の関係に関する情報が与えられていない。よって、特許文献１〜３に記載のシステム等は、階層的かつ複数の視点に基づくリレーショナルモデルの生成等を行うことができないものであったので、システムのモデルの分析及び編集を容易にするものではなかった。

本発明は、階層関係を表す情報を用いることでシステムのモデルの分析及び編集を容易にする、システムのモデルを変換する方法、コンピュータ・プログラム及びシステムモデル変換装置を提供することを目的とする。

本発明の１つの態様として、本発明の第１の形態によると、グラフ形式のデータ構造を有し、複数のモデル要素から構成されるシステムのモデルであるグラフモデルを記憶するグラフモデル記憶部を備えたコンピュータが、多次元データモデルの構造とモデル要素を抽出する抽出クエリとに関する記述を含んだ変換処理記述の入力を受け付ける。ここで、グラフモデルは、ＳｙｓＭＬ等の言語で記述できるものであり、システムの構造、振る舞い（動作）及び制約のうち少なくともいずれかがモデル化されたものである。そして、コンピュータが、入力された変換処理記述に基づき、グラフモデル記憶部に記憶されたグラフモデルから、次元が階層関係を有する多次元データモデルを生成する。多次元データモデルの構造は、スノーフレーク・スキーマを適用したものである。

本発明の第２の形態によると、第１の形態に加えて、コンピュータが、多次元データモデルの中心のテーブルであるルートブロックテーブルに対応するモデル要素を、複数のモデル要素の中から予め指定する。そして、コンピュータが、指定されたルートブロックテーブルに関連付けられたブロックテーブル、及びブロックテーブルに更に関連付けられたブロックテーブルに対して抽出クエリを順番に適用し、関連付けられたブロックテーブルが存在する間はブロックテーブルに抽出クエリを適用して、抽出したモデル要素を用いて多次元データモデルを生成する。

本発明の第３の形態によると、第１の形態に加えて、コンピュータが、生成された前記多次元データモデルから表形式のビューを生成して、生成された表形式のビューを出力する。ここで、コンピュータが、出力する特定の情報を指定するフィルタリング情報を受け付けることで、フィルタリング情報に対応した表形式のビューを出力することができる。また、ユーザにより、出力された表形式のビューに対する変更が行われた場合には、コンピュータは、変更情報を受け付け、更に多次元データモデルの更新に関するルールを示すビュー更新ルールに関する記述を含んだ前記変換処理記述の入力を受け付けることで、変換処理記述にしたがって受け付けた変更情報を、多次元データモデル反映する。更に、コンピュータは、変換処理記述にしたがって受け付けた変更情報を、グラフモデルに反映する。

本発明の第４の形態によると、第３の形態に加えて、コンピュータが、表形式のビューに基づいた制約式の記述を受け付けることで、予め定義された多次元データモデルとグラフモデルとの対応付け規則を用いて、制約式の記述からグラフモデルを更新する。

また、本発明は別の態様として、上記の方法の各ステップをコンピュータに実行させるコンピュータ・プログラムとしても提供可能である。さらに別の形態として、上記の方法を実行する装置としても提供可能である。

本発明によれば、コンピュータが、グラフ形式のデータ構造を有し、複数のモデル要素から構成されるシステムのモデルであるグラフモデルを記憶するグラフモデル記憶部を備えており、多次元データモデルの構造とモデル要素を抽出する抽出クエリとに関する記述を含んだ変換処理記述の入力を受け付けるステップと、入力された変換処理記述に基づき、グラフモデル記憶部に記憶されたグラフモデルから、次元が階層関係を有する多次元データモデルを生成するステップと、を含むシステムのモデルを変換する方法、コンピュータ・プログラム及びシステムモデル変換装置を提供することができる。よって、多数のモデル要素からなるグラフモデルから次元が階層関係を有する多次元データモデルを生成することで、システムのモデルの分析及び編集を容易にし、多数のモデル要素を階層的かつ複数の視点に基づいて分析・編集することができる。

本実施形態に係るモデル変換装置の全体構成を示す図である。 本実施形態に係るシステムのモデルの例を示す図である。 本実施形態に係る多次元データモデルの構造及び構造に従うテーブルの例を示す図である。 本実施形態に係るブロック抽出クエリの例を示す図である。 本実施形態に係る多次元データモデル生成のフローチャートである。 本実施形態に係るユーザに提示される表形式のビューの例を示す図である。 本実施形態に係るビュー更新ルールの例を示す図である。 本実施形態に係るビューの変更によるモデル更新のフローチャートである。 本実施形態に係るビューの変更によるモデル更新のフローチャートである。 本実施形態に係るビューの変更によるモデル更新のフローチャートである。 本実施形態に係るグラフ構造のシステムのモデルと、多次元データモデルと、表形式のビューとの間の変換の概略を示す図である。 本実施形態に係るＳｙｓＭＬ ＰＤの作成のフローチャートである。 本実施形態に係るシステムのモデルの例を示す図である。 本実施形態に係る多次元データモデルの構造とその付加情報の例を示す図である。 本実施形態に係る多次元データモデルに従うテーブルの内容の例を示す図である。 本実施形態に係るユーザに提示されるテーブルの例を示す図である。 本実施形態に係るモデル変換装置のハードウェア構成を示す図である。

以下、本発明の実施形態について図を参照しながら説明する。なお、これらはあくまでも一例であって、本発明の技術的範囲はこれらに限られるものではない。

［全体構成］
図１は、本実施形態に係るモデル変換装置１の全体構成を示す図である。モデル変換装置１は、グラフモデル記憶部２、多次元データモデル記憶部３、データ変換部４、表提示部５及び処理記述入力部６を備える。

グラフモデル記憶部２は、ＳｙｓＭＬやＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）等の、グラフ形式のデータ構造（グラフ構造ともいう）を有する対象システムの構造、振る舞い、及び制約のモデルからなるシステムのモデル（グラフモデル）を記憶する。ここで、システムの振る舞いとは、動作や状態遷移を表すものをいう。

多次元データモデル記憶部３は、グラフモデル記憶部２のシステムのモデルと、処理記述入力部６から入力を受け付けた情報である変換処理記述とから生成される多次元データモデルを記憶する。

データ変換部４は、グラフモデル記憶部２に記憶したシステムのモデルから、多次元データモデル記憶部３に記憶可能な多次元データモデルを生成する制御部である。また、データ変換部４は、多次元データモデルをもとに、ユーザが欲する情報を表の形式で表現した表形式のビューを作成する。更に、データ変換部４は、表形式のビューが変更された際には、多次元データモデル記憶部３に記憶された多次元データモデルと、グラフモデル記憶部２に記憶されたシステムのモデルとにその変更を反映する。また、データ変換部４は、表形式のビューを参照して記述された制約式等の情報から、対応するグラフモデル記憶部２に記憶されたシステムのモデルを更新する。

表提示部５は、データ変換部４により作成された表形式のビューを出力する出力制御部である。また、表提示部５は、出力した表形式のビューがユーザによって操作して変更されたことに応じて、変更情報を受け付ける。更に、表提示部５は、表形式のビューを参照してユーザにより記述された制約式の情報を受け付ける。

処理記述入力部６は、設計者が入力した、システムに関する変換処理記述の情報として、多次元データモデルの構造と、その付加情報とを受け付ける。付加情報とは、多次元データモデルの構造の付加情報であり、グラフ構造のシステムのモデルから抽出するモデル要素を指定するモデル要素抽出クエリと、多次元データモデルの更新に関するルールであるビュー更新ルールとをいう。なお、各機能の詳細は、後述で説明する。

図２は、本実施形態に係るシステムのモデルの例を示す図である。図３は、多次元データモデルの構造及び構造に従うテーブルの例を示す図である。

［システムのモデル例］
図２には、ＦＦ車・Ｘ配管方式２系統油圧ブレーキの車輪に関するグラフ形式のデータ構造を有するシステムのモデルであるグラフモデル２０が示されている。グラフモデル２０は、左前輪ｗ１と右前輪ｗ２との２つのブロック（モデル要素）が、前車軸ｐ１のブロックとステアリングｓ１のブロックとにつながっており、右後輪ｗ３と左後輪ｗ４との２つのブロックが、後車軸ｐ２のブロックにつながっていることを示す。また、グラフモデル２０は、故障に備えた二重化を考慮して、油圧配管Ａ（ｔ１）及び油圧配管Ｂ（ｔ２）の２つのブレーキ油圧配管のブロックを有することを示す。油圧配管Ａ（ｔ１）及び油圧配管Ｂ（ｔ２）の２つのブレーキ油圧配管のブロックは、油圧配管Ａ（ｔ１）のブロックが、左前輪ｗ１のブロック及び右後輪ｗ３のブロックにつながり、油圧配管Ｂ（ｔ２）のブロックが、右前輪ｗ２のブロック及び左後輪ｗ４のブロックにつながっており、それぞれ前輪と後輪とを１つずつ互い違いに結んでいる。グラフモデル２０は、前車軸ｐ１と後車軸ｐ２とのブロックが、車体Ａｕ１のブロックに、油圧配管Ａ（ｔ１）と油圧配管Ｂ（ｔ２）とのブロックが、ブレーキマスターシリンダｍ１のブロックに、それぞれ上位のブロックに対してつながっていることを示す。なお、図２では、記載を省略しているが、図中の左前輪ｗ１、右前輪ｗ２、右後輪ｗ３及び左後輪ｗ４、等の各ブロックは、重さや名称等のプロパティを有する。

図２のグラフモデル２０は、グラフモデル記憶部２に予め記憶されている。以降、グラフモデル２０から多次元データモデルを生成する例を説明する。

［多次元データモデルの構造例］
図３（１）は、多次元データモデルの構造３０である。構造３０は、多次元データモデルを生成するのに必要な情報であり、設計者が、図２に例示したグラフモデル２０を参照した上で、処理記述入力部６から与える。図３（１）に示す構造３０は、図２のグラフモデル２０を、車輪ｗの観点を中心に、車軸ｐ、ステアリングｓ、油圧配管ｔの異なる３つの視点で分析するためのスキーマである。車軸ｐは、車体ｕを下位に有しており、車輪ｗ−車軸ｐ−車体ｕといった階層的な分析が可能になる。構造３０は、車輪ｗを中心にして、車輪ｗにつながる次元が階層化されて放射状に広がる構造をしている。そして、構造３０のような、次元が階層化されて放射状に広がる構造をしたスキーマを、スノーフレーク・スキーマという。

［多次元データモデルの構造に従うテーブルの例］
図３（２）は、多次元データモデルの構造３０に従うテーブル３２の例を示す。テーブル３２は、ルートブロックテーブル３３と、ブロックテーブル３４〜３７とから構成される。このテーブル３２を生成することが、多次元データモデルの生成であり、テーブル３２は、多次元データモデルを表す。ルートブロックテーブル３３は、スノーフレーク・スキーマにおけるＦａｃｔテーブルであり、分析・編集の中心となるブロックの集合である。本実施形態の場合には、車輪ｗが分析・編集の中心となるブロックの集合である。ブロックテーブル３４〜３７は、スノーフレーク・スキーマにおける次元テーブルであり、中心になるルートブロックテーブル３３が、システムのモデルにおいて関連しているブロックの集合を保持する。

［付加情報例１］
次に、テーブル３２を生成するために必要な情報であり、設計者が、処理記述入力部６に入力する付加情報である抽出クエリについて説明する。図４は、本実施形態に係るブロック抽出クエリＱの例を示す図である。ブロック抽出クエリＱは、多次元データモデルのブロックテーブルごとに設計者が付与する。ブロック抽出クエリＱは、対象のブロックテーブルのレコードとして、例えば、グラフモデル２０等のグラフ構造のシステムのモデルから、どのブロックを抽出するかを指定するクエリである。ブロック抽出クエリＱは、Ｑ＝（Ｑｂ，Ｑｐ）によって構成される。クエリＱｂは、ブロックを抽出するために用いられる。これは、ローカルクエリを仮定する。すなわち、クエリＱｂにマッチするかどうかは、局所的にブロックをひとつ与えれば、判定できるようなクエリであるとする。そのような言語として、例えば、抽出対象のブロック名にマッチする正規表現やパターンが考えられる。そして、ルートブロックテーブルに対応するブロックを抽出する際には、モデル全域に対してｇｌｏｂａｌなクエリを適用する。

一方で、ルートブロックテーブル以外のブロックテーブルについては、親レベル（ここではスノーフレーク・スキーマを木構造に見立てたときの親−子関係の言葉を用いている）で抽出されたブロックから辿れるブロックだけを対象に、クエリを適用する。これによって、ルートブロックテーブル以外のクエリについては、文脈に依存した問い合わせを実現することができる。文脈に依存した問い合わせとは、リンクが繋がっていることで、子レベルに向かって辿ることができる問い合わせを順に辿っていくことをいう。このように文脈に依存した問い合わせをすることで辿る範囲が決定されるため、モデル変換装置１による文脈の問い合わせは、実用に適うものになる。

クエリＱｐは、クエリＱｂによって抽出されたブロックから、どのようなプロパティを取り出すかを決める。プロパティは、例えば、プロパティ名の集合を考えることができる。

［多次元データモデル生成のフローチャート］
次に、グラフ構造のシステムのモデルから、スノーフレーク・スキーマの次元テーブルの内容を抽出する処理について説明する。図５は、本実施形態に係る多次元データモデル生成のフローチャートである。なお、以下に示す処理において、データ変換部４が制御する。

ステップＳ１では、整数ｊに０を代入し、ステップＳ２では、ブロックテーブルＬｊをブロックテーブルＬとする。なお、ブロックテーブルＬ０は、ルートブロックテーブルを示す。

ステップＳ３では、ブロックテーブルＬに対応するクエリＱｂを用いて、クエリＱｂにマッチする全てのブロックであるブロックｂｉ（ｉ＝１〜ｎ（ｎ：整数））を取得する。なお、クエリＱｂは、ブロック抽出クエリＱの１つであり、ブロックｂｉを抽出するものである。ステップＳ４では、１を整数ｉに代入し、ブロックｂｉをブロックｂとする。

ステップＳ５では、ブロックテーブルＬに対応するクエリＱｐにマッチする、ブロックｂのプロパティの値ｖ（ｖ１，…，ｖｋ）を取得する。プロパティの値ｖの数にあたる整数ｋは、クエリＱｐに依存する。

ステップＳ６では、ブロックｂのブロックテーブルＬにおけるＩＤ（ｉｄｅｎｔｉｆｉｅｒ）として、ｂ．ｉｄを生成する。

ステップＳ７では、ブロックテーブルＬの下位にブロックテーブルが存在するか否かを判断する。ブロックテーブルＬの下位にブロックテーブルが存在する場合（ステップＳ７：ＹＥＳ）には、ステップＳ８に処理を移す。他方、ブロックテーブルＬの下位にブロックテーブルが存在しない場合（ステップＳ７：ＮＯ）には、ステップＳ１０に処理を移す。

ステップＳ８では、ブロックｂをコンテキストにして、ブロックテーブルＬの下位（子レベル）のブロックテーブルの集合Ｌ１，…，Ｌｘに対するクエリＱｂ１，…，クエリＱｂｘを用いて、クエリＱｂ１，…，クエリＱｂｘにマッチするブロックｂ１，…，ブロックｂｘを取得する。なお、整数ｘは１以上の数値である。

ステップＳ９では、ブロックｂ１，…，ブロックｂｘのブロックテーブルＬ１，…，ブロックテーブルＬｘに対応するＩＤとして、ｂ１．ｉｄ，…，ｂｘ．ｉｄを生成する。

ステップＳ１０では、レコード（ｂ．ｉｄ，ｂ１．ｉｄ，…，ｂｘ．ｉｄ，ｖ１，…，ｖｋ）を、ブロックテーブルＬに追加する。なお、ｂ１．ｉｄ，…，ｂｘ．ｉｄは、ブロックテーブルＬの下位にブロックテーブルＬ１，…，ブロックテーブルＬｘを有する場合にのみ存在する。

ステップＳ１１では、ｉに１を加えた値を整数ｉに代入し、ブロックｂｉをブロックｂとする。そして、ステップＳ１２では、整数ｉが整数ｎより大きいか否かを判断する。ここで、整数ｎは、ステップＳ３で取得したクエリＱｂにマッチするブロックの数である。整数ｉが整数ｎよりも大きい場合（ステップＳ１２：ＹＥＳ）には、処理をステップＳ１３に移す。他方、整数ｉが整数ｎよりも大きくない場合（ステップＳ１２：ＮＯ）には、処理をステップＳ５に移す。

ステップＳ１３では、ｊに１を加えた値を整数ｊに代入し、ステップＳ１４では、ブロックテーブルＬｊが存在するか否かを判断する。ブロックテーブルＬｊが存在する場合（ステップＳ１４：ＹＥＳ）には、処理をステップＳ２に移す。他方、ブロックテーブルＬｊが存在しない場合（ステップＳ１４：ＮＯ）には、本処理を終了する。

この一連の処理により、ユーザが、多次元データモデルの構造と、モデル要素を抽出するクエリとを入力して与えることで、データ変換部４は、グラフ形式のデータ構造を有するシステムのモデルから、次元が階層関係を有する多次元データモデルを自動的に生成することができる。

［多次元データモデル生成のフローチャートの使用例］
次に、図５で説明したフローチャートを使用して、多次元データモデルを生成する例を説明する。ここでは、図２のグラフモデル２０から、処理記述入力部６が受け付けた図３（１）の構造３０と、図４のブロック抽出クエリＱとを用いて、多次元データモデル記憶部３に記憶可能な図３（２）のテーブル３２を作成する。

まず、図３（１）の構造３０を参照して、データ変換部４は、ルートブロックテーブルである車輪ｗについて処理をする（図５のステップＳ１、Ｓ２）。車輪ｗに対応するクエリＱｂは、図４よりＱｂ＝“ｗ＊”であり、これは“ｗ”で始まるブロックを抽出することを意味する。よって、データ変換部４は、図２から左前輪ｗ１、右前輪ｗ２、右後輪ｗ３及び左後輪ｗ４の計４つのブロックを取得する（図５のステップＳ３）。

次に、左前輪ｗ１のブロックについて処理を行う（図５のステップＳ４）。車輪ｗに対応するクエリＱｐにマッチする、左前輪ｗ１のブロックのプロパティとして、左前輪ｗ１の重さ（ｗｅｉｇｈｔ）を取得する（図５のステップＳ５）。なお、ここでは、グラフモデル２０に示されるべき左前輪ｗ１、右前輪ｗ２、右後輪ｗ３及び左後輪ｗ４の重さが、いずれも５ｋｇであるとする。そして、左前輪ｗ１のｉｄとして「ｗ１」を生成する（図５のステップＳ６）。

図３（１）を参照すると、車輪ｗの下位には、車軸ｐ、ステアリングｓ、油圧配管ｔの３つのブロックテーブルが存在するので（図５のステップＳ７がＹＥＳ）、左前輪ｗ１のブロックをコンテキストにして、車軸ｐ、ステアリングｓ、油圧配管ｔに対するクエリＱｂ（図４参照）にマッチする前車軸ｐ１、ステアリングｓ１、油圧配管Ａ（ｔ１）の各ブロックを取得する（図５のステップＳ８）。そして、前車軸ｐ１、ステアリングｓ１、油圧配管ｔ１の各ブロックのｉｄとして「ｐ１，ｓ１，ｔ１」を生成する（図５のステップＳ９）。そして、レコード（ｗ１，ｐ１，ｓ１，ｔ１，５ｋｇ）を車輪ｗに追加する（図５のステップＳ１０）。

次に、右前輪ｗ２のブロックについて、左前輪ｗ１のブロックと同様に処理を行う（図５のステップＳ１２がＮＯ）。まず、車輪ｗに対応するクエリＱｐにマッチする右前輪ｗ２のブロックのプロパティである重さを取得する。そして、右前輪ｗ２のブロックをコンテキストにして、車軸ｐ、ステアリングｓ、油圧配管ｔに対するクエリＱｂにマッチする前車軸ｐ１、ステアリングｓ１、油圧配管Ｂ（ｔ２）の各ブロックを取得する（図５のステップＳ８）。よって、レコード（ｗ２，ｐ１，ｓ１，ｔ２，５ｋｇ）を得る。

同様に、右後輪ｗ３のブロックは、レコード（ｗ３，ｐ２，，ｔ１，５ｋｇ）を、左後輪ｗ４のブロックは、レコード（ｗ４，ｐ２，，ｔ２，５ｋｇ）を、それぞれ得る。よって、図３（２）のテーブル３２のルートブロックテーブル３３に示すように、ルートブロックテーブル３３にレコードが挿入される。

次に、ルートブロックテーブルの車輪ｗに対して下位のブロックテーブルである車軸ｐについて処理を行う（図５のステップＳ１４がＹＥＳ）。車軸ｐに対応するクエリＱｂは、図４よりＱｂ＝“ｐ＊”であり、これは“ｐ”で始まるブロックを抽出することを意味する。よって、データ変換部４は、図２から前車軸ｐ１，後車軸ｐ２の計２つのブロックを取得する（図５のステップＳ３）。

次に、前車軸ｐ１のブロックについて処理を行う（図５のステップＳ４）。車軸ｐに対応するクエリＱｐにマッチする、前車軸ｐ１のブロックのプロパティとして、前車軸ｐ１の名前（ｎａｍｅ）と重さとを取得する（図５のステップＳ５）。なお、ここでは、グラフモデル２０に示されるべき前車軸ｐ１と後車軸ｐ２の重さが、いずれも５０ｋｇであるとする。そして、前車軸ｐ１のｉｄとして「ｐ１」を生成する（図５のステップＳ６）。

車軸ｐの下位には、車体ｕのブロックテーブルが存在するので（図５のステップＳ７がＹＥＳ）、前車軸ｐ１のブロックをコンテキストにして、車体ｕに対するクエリＱｂにマッチする車体Ａｕ１のブロックを取得する（図５のステップＳ８）。そして、車体Ａｕ１のブロックのｉｄとして「ｕ１」を生成する（図５のステップＳ９）。レコード（ｐ１，ｕ１，前車軸，５０ｋｇ）を車軸ｐに追加する。同様に、後車軸ｐ２のブロックは、レコード（ｐ２，ｕ１，後車軸，５０ｋｇ）を得るので、図３（２）のブロックテーブル３４に示すように、ブロックテーブル３４にレコードが挿入される。

同様に、ステアリングｓ、油圧配管ｔ、車体ｕについても処理を行うことで、図３（２）に示すテーブル３２が生成できる。このように、図５のフローチャートに示したアルゴリズムを用いることで、図３（２）に示すルートブロックテーブル３３及び各ブロックテーブル３４〜３７にレコードが挿入されたテーブル３２を生成することができる。

［ビューの例］
図６は、本実施形態に係るユーザに提示される表形式のビュー６０の例を示す図である。上記の処理により、多次元データモデルのテーブル３２が生成できると、データ変換部４は、そのテーブル３２に含むルートブロックテーブル３３及び各ブロックテーブル３４〜３７を結合（Ｊｏｉｎ）することで、図６に示す表形式のデータ構造を作成できる。これが、表形式のビュー６０である。

表形式のビュー６０は、表提示部５によりユーザに提示される。ユーザは、提示された表形式のビュー６０を参照したり、表形式のビュー６０の値を更新したりすることができる。表形式のビュー６０は、ユーザによるデータの扱いが容易な形式で提示されるので、ユーザによる分析及び編集を容易なものにすることができる。例えば、ユーザが興味のある項目やその内容をフィルタリング情報として指定することで、ユーザが必要な情報を取り出すことができる。

［付加情報例２］
次に、表形式のビュー６０をユーザが更新した場合に、グラフモデル２０やテーブル３２にユーザの更新を反映させるために必要な付加情報であるビューの更新ルールについて説明する。図７は、本実施形態に係るビュー更新ルールＵＲの例を示す図である。ビュー更新ルールＵＲは、設計者が処理記述入力部６から入力する。ビュー更新ルールＵＲは、ブロックテーブルごとに付与される。ビュー更新ルールＵＲは、表形式のビュー６０に対して、ユーザが行の追加や削除に関する操作を行った場合に、対象になるブロックを複製したり削除したりするか否かを決めるためのフラグであり、真偽値で表現される。ビュー更新ルールＵＲが「Ｔｒｕｅ」である場合には、行の挿入時に、対応するブロックを複製し、行の削除時に、対応するブロックを消去することを表す。また、ビュー更新ルールＵＲが「Ｆａｌｓｅ」である場合には、行の挿入時や削除時に、対応するブロックを複製したり消去したりしない。ビュー更新ルールＵＲにしたがった処理により、表形式のビュー６０のセルには、同じ複数の項目が表示される場合があるが、実際には、同一のブロックを指していることになる。

［ビュー変更による多次元データモデル更新のフローチャート］
次に、表形式のビューにおける変更を、多次元データモデル及びグラフ構造のシステムのモデルに反映させる処理について説明する。図８から図１０は、本実施形態に係るビューの変更によるモデル更新のフローチャートである。なお、以下に示す処理は、記載がある場合を除き、データ変換部４が制御する。

（セルの変更）
図８のステップＳ２１では、表提示部５は、表形式のビューのセルに対する変更を受け付けたか否かを判断する。表形式のビューのセルに対する変更を受け付けた場合（ステップＳ２１：ＹＥＳ）には、表提示部５は、処理をステップＳ２２に移す。他方、表形式のビューのセルに対する変更を受け付けていない場合（ステップＳ２１：ＮＯ）には、表提示部５は、処理を図９のステップＳ３１に移す。

ステップＳ２２では、セルが位置するビュー上の列をｃとし、列ｃを定義しているブロックテーブルをＬとし、セルが位置するビュー上の行に該当するブロックテーブルＬの行をｒとする。そして、行ｒに対応するモデル要素をｅとする。

ステップＳ２３では、ブロックテーブルＬの付加情報Ｍのブロック抽出クエリＱ＝（Ｑｂ，Ｑｐ）に関して、列ｃに対応付けられたクエリＱｐの要素をｐとする。ステップＳ２４では、モデル要素ｅのプロパティｐに、更新されたセルの値を代入する。その後、本処理を終了する。

この一連の処理により、ユーザが入力して与えたブロック抽出クエリＱを用いて、データ変換部４は、表提示部５が受け付けたセルの変更に関する情報を、次元が階層関係を有する多次元データモデルと、グラフ形式のデータ構造を有するシステムのモデルとに反映できる。

（行の追加）
図９のステップＳ３１では、表提示部５は、表形式のビューの行の追加を受け付けたか否かを判断する。表形式のビューの行の追加を受け付けた場合（ステップＳ３１：ＹＥＳ）には、表提示部５は、処理をステップＳ３２に移す。他方、表形式のビューの行の追加を受け付けていない場合（ステップＳ３１：ＮＯ）には、表提示部５は、処理を図１０のステップＳ５１に移す。

ステップＳ３２では、ユーザが行を追加する際にベースとして選んだビュー上の行をＲとする。行を追加する際にベースとして選ぶとは、ユーザが既存の行をコピー＆ペーストして行を追加することを示す。新規に作成する場合には、行Ｒには、何も指定されていない。

ステップＳ３３では、行Ｒに既存の行が指定されているか否かを判断する。行Ｒに既存の行が指定されている場合（ステップＳ３３：ＹＥＳ）には、処理をステップＳ３４に移す。他方、行Ｒに既存の行が指定されていない場合、つまり、何も指定されていない場合（ステップＳ３３：ＮＯ）には、処理をステップＳ４０に移す。

ステップＳ３４では、各ブロックテーブルＬｉの行Ｒに対応する行をＲｉとする。ステップＳ３５では、ブロックテーブルＬｉの付加情報Ｍｉのビュー更新ルールＵＲｉを参照して、ビュー更新ルールＵＲｉがＴｒｕｅであるか否かを判断する。ビュー更新ルールＵＲｉがＴｒｕｅである場合（ステップＳ３５：ＹＥＳ）には、処理をステップＳ３６に移し、ビュー更新ルールＵＲｉがＦａｌｓｅである場合（ステップＳ３５：ＮＯ）には、処理をステップＳ３８に移す。

ステップＳ３６では、ブロックテーブルＬｉのプライマリキーを新たに生成して、そのプライマリキーをＫｉとする。ステップＳ３７では、ブロックテーブルＬｉに行を挿入して、行Ｎｉとする。そして、行ＮｉのプライマリキーをＫｉにして、それ以外の部分には、行Ｒｉの値を複製する。その後、処理をステップＳ３９に移す。ステップＳ３８では、行ＲｉのプライマリキーをＫｉにして、行ＮｉをＮｕｌｌにする。

ステップＳ３９では、各ブロックテーブルＬｉに対して処理を行ったか否かを判断する。各ブロックテーブルＬｉに対して処理を行った場合（ステップＳ３９：ＹＥＳ）には、処理をステップＳ４３に移す。他方、各ブロックテーブルＬｉに対して処理を行っていない場合（ステップＳ３９：ＮＯ）には、処理をステップＳ３５に移して、処理をしていないブロックテーブルＬｉについて処理を行う。

ステップＳ４０では、ブロックテーブルＬｉのプライマリキーを新たに生成して、そのプライマリキーをＫｉとする。ステップＳ４１では、ブロックテーブルＬｉに行を挿入して、行Ｎｉとする。そして、行ＮｉのプライマリキーをＫｉにして、それ以外の部分をＮｕｌｌにする。

ステップＳ４２では、各ブロックテーブルＬｉに対して処理を行ったか否かを判断する。各ブロックテーブルＬｉに対して処理を行っていた場合（ステップＳ４２：ＹＥＳ）には、処理をステップＳ４３に移す。他方、各ブロックテーブルＬｉに対して処理を行っていない場合（ステップＳ４２：ＮＯ）には、処理をステップＳ４０に移して、処理をしていないブロックテーブルＬｉについて処理を行う。

ステップＳ４３では、多次元データモデルの構造Ｓにおいて、各ブロックテーブルＬｉの下位にある各ブロックテーブルＬｊに対して、行Ｎｉ≠Ｎｕｌｌの場合に、ブロックテーブルＬｊへの外部キーになっている行Ｎｉのフィールドに、ブロックテーブルＬｊのプライマリキーＫｊを格納する。

ステップＳ４４では、各ブロックテーブルＬｊに対して処理を行ったか否かを判断する。各ブロックテーブルＬｊに対して処理を行った場合（ステップＳ４４：ＹＥＳ）には、処理をステップＳ４５に移す。他方、各ブロックテーブルＬｊに対して処理を行っていない場合（ステップＳ４４：ＮＯ）には、処理をステップＳ４３に移して、処理をしていないブロックテーブルＬｊについて処理を行う。

ステップＳ４５では、各行Ｎｉに対して、システムのモデルの中に、行Ｎｉに該当するノードＣｉを作成する。

ステップＳ４６では、行Ｎｉを含むブロックテーブルＬｉの下位にある各ブロックテーブルＬｊに対して、行Ｎｉにより参照されているブロックテーブルＬｊ中の行を行Ｍｊとし、行Ｍｊに該当するシステムのモデルの中のノードをノードＣｊとする。そして、システムのモデルの中のノードＣｉとノードＣｊとの間に、関連を追加する。

ステップＳ４７では、各行Ｎｉに対して処理を行ったか否かを判断する。各行Ｎｉに対して処理を行った場合（ステップＳ４７：ＹＥＳ）には、本処理を終了する。他方、各行Ｎｉに対して処理を行っていない場合（ステップＳ４７：ＮＯ）には、処理をステップＳ４５に移して、処理をしていない各行Ｎｉについて処理を行う。

（行の削除）
図１０のステップＳ５１では、表提示部５は、表形式のビューの行の削除を受け付けたか否かを判断する。表形式のビューの行の削除を受け付けた場合（ステップＳ５１：ＹＥＳ）には、表提示部５は、処理をステップＳ５２に移す。他方、表形式のビューの行の削除を受け付けていない場合（ステップＳ５１：ＮＯ）には、表提示部５は、本処理を終了する。

ステップＳ５２では、ユーザが削除対象として選んだビュー上の行を行Ｒとする。ステップＳ５３では、ブロックテーブル上で削除した行を記憶する集合である集合Ｄを、空集合で初期化する。

ステップＳ５４では、整数ｋに０を代入し、ブロックテーブルＬｋをブロックテーブルＬｉとする。なお、ブロックテーブルＬ０は、ルートブロックテーブルを示す。ステップＳ５５では、ブロックテーブルＬｉの行Ｒに対する行をＲｉとする。

ステップＳ５６では、ブロックテーブルＬｉがルートブロックテーブルであるか否かを判断する。ブロックテーブルＬｉがルートブロックテーブルである場合（ステップＳ５６：ＹＥＳ）には、処理をステップＳ５８に移す。他方、ブロックテーブルＬｉがルートブロックテーブルではない場合（ステップＳ５６：ＮＯ）には、処理をステップＳ５７に移す。

ステップＳ５７では、「ブロックテーブルＬｉの付加情報Ｍｉのビュー更新ルールＵＲｉを参照して、その値がＴｒｕｅ」であり、かつ「ブロックテーブルＬｉの親ブロックテーブルＬｊ中に行Ｒｉを参照している行が存在しない」か否かを判断する。ビュー更新ルールＵＲｉがＴｒｕｅかつブロックテーブルＬｉの親ブロックテーブルＬｊ中に行Ｒｉを参照している行が存在しない場合（ステップＳ５７：ＹＥＳ）には、処理をステップＳ５８に移す。他方、ビュー更新ルールＵＲｉがＦａｌｓｅであるか、又はブロックテーブルＬｉの親ブロックテーブルＬｊ中に行Ｒｉを参照している行が存在する場合（ステップＳ５７：ＮＯ）には、処理をステップＳ５９に移す。

ステップＳ５８では、行Ｒｉを削除して、集合Ｄに行Ｒｉを追加する。

ステップＳ５９では、ブロックテーブルの親子関係のツリー上の深さ優先順位で処理を行うように、ｋに１を加えた値を整数ｋに代入して、ブロックテーブルＬｋをブロックテーブルＬｉとする。そして、処理をステップＳ６０に移す。

ステップＳ６０では、各ブロックテーブルＬｉに対して処理を行ったか否かを判断する。各ブロックテーブルＬｉに対して処理を行っていた場合（ステップＳ６０：ＹＥＳ）には、処理をステップＳ６１に移す。他方、各ブロックテーブルＬｉに対して処理を行っていない場合（ステップＳ６０：ＮＯ）には、処理をステップＳ５５に移す。

ステップＳ６１では、集合Ｄの各要素Ｄｉに対して、システムのモデルから、要素Ｄｉに該当するノードＣｉ及びノードＣｉにつながっている関連を削除する。要素Ｄｉは、集合Ｄに記憶されたブロックテーブルで削除した行の１つである。その後、本処理を終了する。

この一連の処理により、ユーザが入力して与えたビュー更新ルールＵＲを用いて、データ変換部４は、表提示部５が受け付けた行の追加や削除に関する情報を、次元が階層関係を有する多次元データモデルと、グラフ形式のデータ構造を有するシステムのモデルとに反映できる。

［ビュー変更によるモデル更新のフローチャートの使用例］
次に、図８から図１０で説明したフローチャートを使用して、モデルを更新する例を説明する。最初に、表提示部５が提示した図６の表形式のビュー６０のセル６１を、「前車軸」から「前車軸２」に更新した場合を例に説明する。

まず、セル６１の列を定義しているブロックテーブルＬを、車軸ｐのブロックテーブルして、車軸ｐの該当の行をｒとする。すなわち、前車軸ｐ１の行をｒとする。そして、行ｒに対応するモデル要素である、ｐ１を取得する（図８のステップＳ２２）。

次に、図４を参照して、車軸ｐのブロック抽出クエリの、セル６１の列に対応付けられたクエリＱｐの要素である｛ｎａｍｅ｝を取得して、取得したｐ１のプロパティである車軸名称に、更新されたセルの値を代入する（図８のステップＳ２３、Ｓ２４）。

本処理によって、図３（２）に示すブロックテーブル３４のｐ１のレコードの「前車軸」は、「前車軸２」に更新される。同時に、ｐ１がマップされているビュー６０のセル６３も、「前車軸」から「前車軸２」に更新される。

次に、表提示部５が提示した図６の表形式のビュー６０の行６２を削除した場合を例に説明する。これは、４輪自動車から、前車輪が１つの３輪自動車にした場合の例である。

まず、行６２である右前輪ｗ２の行をＲにして、集合Ｄを空集合で初期化する（図１０のステップＳ５２、Ｓ５３）。

次に、車輪ｗのブロックテーブルから右前輪ｗ２を削除して、集合Ｄに右前輪ｗ２を追加する（図１０のステップＳ５６がＹＥＳ、ステップＳ５８）。

次に、車軸ｐのブロックテーブルに関して処理を行う。車軸ｐのブロックテーブルは、ビュー更新ルールはＴｒｕｅである（図７）。また、車軸ｐのブロックテーブルの親である車輪ｗのブロックテーブルの中には、前車軸ｐ１を参照する左前輪ｗ１があるので、削除行を参照している行がある（図１０ステップＳ５７がＮＯ）。よって、車軸ｐのブロックテーブルからは何も削除しない。

同様に、ステアリングｓ、油圧配管ｔ、車体ｕの各ブロックテーブルは、ビュー更新ルールがいずれもＦａｌｓｅである（図７）ので（図１０ステップＳ５７がＮＯ）、ステアリングｓ、油圧配管ｔ、車体ｕの各ブロックテーブルからは何も削除しない。

ここまでの処理によって、多次元データモデルに対する削除処理が終了した。また、集合Ｄの右前輪ｗ２のノードと、その関連とを削除する（図１０のステップＳ６１）。この処理で、システムのモデルに対する削除処理が終了する。

［多次元データモデルの更新をシステムのモデルに書き戻す処理］
次に、多次元データモデルの更新をグラフ構造のシステムのモデルに書き戻す処理について説明する。多次元データモデルから表形式のビューを生成することで、表形式のビューを参照して、例えば、図２の車輪のモデルに関する例において、車軸視点と油圧配管視点による制約の記述が可能である。制約の具体例として、
（制約１）ＳＵＭ（「油圧配管Ａ＝ｔ１」である車輪の制動力）＞車輪にかかる最大トルク
（制約２）ＳＵＭ（「油圧配管Ｂ＝ｔ２」である車輪の制動力）＞車輪にかかる最大トルク
（制約３）ＳＵＭ（「前車軸＝ｐ１」である車輪の最大荷重）＞定数Ｋ
が挙げられる。制約１は、油圧配管Ａ（ｔ１）のみでも制動可能でなければならないことを表し、制約２は、油圧配管Ｂ（ｔ２）のみでも制動可能でなければならないことを表す。また、制約３は、前輪２つの最大荷重が一定値より大きくなければならないことを表す。この制約３は、フロントにあるエンジンの重量を考慮した制約である。このように、多次元データモデルは、複数の視点に基づいた分析・記述において有用である。この制約は、例えば、ＳＱＬクエリを用いて記述できる。

次に、このような制約を図１１に示すＳｙｓＭＬのＰａｒａｍｅｔｒｉｃ Ｄｉａｇｒａｍ（ＰＤ）に変換する方法を示す。図１１は、本実施形態に係るグラフ構造のシステムのモデルと、多次元データモデルと、表形式のビューとの間の変換の概略を示す図である。なお、制約をＳｙｓＭＬ ＰＤに変換する処理では、制約式自身の変換を対象にしていない。例えば、スプレッドシートの式によって制約が記述されている場合には、本来ならば、ＳｙｓＭＬにおいては、制約記述言語であるＯＣＬやＪａｖａ（登録商標）等の制約式で記述することが好ましいこともあるが、そのような変換は対象にしない。後述する処理は、事前に定義されたＯＣＬやＪａｖａ等の個々の制約表現とスプレッドシート内の式との対応付け規則を利用して、ＳｙｓＭＬ ＰＤのセルとセルの範囲とのそれぞれに対応するＣｏｎｓｔｒａｉｎｔ ＰｒｏｐｅｒｔｙとＣｏｎｓｔｒａｉｎｔ Ｂｌｏｃｋと、それに割り当てられるＣｏｎｓｔｒａｉｎｔ要素を生成することである。

［グラフ構造のシステムのモデルへの変換例］
図１１に示す対象になるグラフモデル２０は、ＩＢＤ（Ｉｎｔｅｒｎａｌ Ｂｌｏｃｋ Ｄｉａｇｒａｍ）であるとする。そして、図５の処理によって、ＩＢＤをもとに表形式のビュー６０が作成される（図中（１））。この表形式のビュー６０に対して、例えば、全ての車輪の重さの合計がある値（例えば、○○ｋｇ）以下である、等の制約式が記述されている場合に、その制約式を選択することで、ＳｙｓＭＬ ＰＤへの変換を行う（図中（２））。

図１２は、本実施形態に係るＳｙｓＭＬ ＰＤの作成のフローチャートである。なお、以下に示す処理において、データ変換部４が制御する。

ステップＳ７１では、ユーザによって選択された制約式を取り出す。制約式は、表形式のビューに対して予め記述されている。ステップＳ７２では、制約式が参照されている表のセルの集合を取り出す。ステップＳ７３では、各々の表のセルに対応するプロパティ７０に対するＣｏｎｓｔｒａｉｎｔ Ｐｒｏｐｅｒｔｙ７１が未作成であれば、それを作成する。そして、Ｃｏｎｓｔｒａｉｎｔ Ｐｒｏｐｅｒｔｙ７１の集合をノードＣ１とする。

ステップＳ７４では、Ｃｏｎｓｔｒａｉｎｔ Ｂｌｏｃｋ７２を生成する。そして、生成したＣｏｎｓｔｒａｉｎｔ Ｂｌｏｃｋ７２にはノードＣ１を割りつけ、更に選択された制約式をＣｏｎｓｔｒａｉｎｔ７３として設定する。その後、本処理を終了する。

本発明によって、モデル変換装置１は、複雑なグラフ構造のシステムのモデルに対して多次元データモデルを生成し、表形式のビューを提示するので、表を用いて階層的かつ複数の視点に基づく分析・編集を行うことができるようになる。ＳｙｓＭＬ等の汎用的なグラフィカル・モデリング言語では、制約を記述する際に、制約に関係する全てのプロパティに対して、関連を記述する必要がある。例えば、多数のコンポーネントに対して働く制約を記述することは、非常に労力がかかる仕事となる。本発明では、モデル変換装置１は、複雑なグラフ構造のシステムのモデルに対して、スノーフレーク・スキーマを適用することで、ＯＬＡＰの技法を元に、適切に表形式を作成することができる。そして、モデル変換装置１は、表形式上では、多数のプロパティが関与する制約式を記述することが容易になる。なぜなら、表の列や行の単位でプロパティを集計することが出来るためである。更に、この表形式では、編集も可能である。すなわち、多数のプロパティを表形式で一覧してモデルを編集することが可能である。

［大規模なシステムのモデルへの適用例］
次に、本発明を、大規模なシステムのモデルの分析・編集に使用する例として、車載ソフトウェアコンポーネント（ＳＷＣ）の車載通信バス（ＢＵＳ）へのアサインについて検討する。図１３は、本実施形態に係るグラフモデル８０の例を示す図である。

図１３のグラフモデル８０は、自動車に搭載されている数万個のＳＷＣと、ＢＵＳと、ＥＣＵ（Ｅｎｇｉｎｅ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）とから構成されるグラフ構造のシステムのモデルである。グラフモデル８０は、ＥＣＵを表すブロックＥＣＵ０，ＥＣＵ１，ＥＣＵ２，…に、ＳＷＣを表すブロックＳＷＣ１，ＳＷＣ２，ＳＷＣ３，…が、ＥＣＵにはバスＢＵＳ１，ＢＵＳ２，…が各々接続されている。一方で、各ＳＷＣは、コンフィギュレーションＣｏｎｆ１，Ｃｏｎｆ２，…によって、どのＢＵＳを用いて通信を行うかが指定されている。

次に、グラフモデル８０を、ＳＷＣとＢＵＳとに関する必要帯域幅の必要／許容関係の観点で分析・編集する例を示す。図１４は、本実施形態に係る多次元データモデルの構造とその付加情報の例を示す図である。図１５は、本実施形態に係る多次元データモデルに従うテーブルの内容の例を示す図である。図１６は、本実施形態に係るユーザに提示されるテーブルの例を示す図である。

図１４には、多次元データモデルの構造を示すスノーフレーク・スキーマと、その付加情報として、ブロック抽出クエリと、ビュー更新ルールとが示されている。このスキーマは、ＳＷＣ，コンフィギュレーション，ＢＵＳを抽出するブロックテーブルとしてＳＷＣｓ，Ｃｏｎｆｓ，ＢＵＳｅｓが定義されており、分析の中心となるルートブロックテーブルはＳＷＣｓである。各テーブルには、ＳＷＣ，コンフィギュレーション，ＢＵＳを抽出するための情報が、ブロック抽出クエリＱ＝（Ｑｂ，Ｑｐ）として与えられている。また、各テーブルには、上位テーブルでレコードの追加・削除があったときにそのテーブルで追加・削除を実行すべきかの情報が、ビュー更新ルールＵＲとして与えられている。この例におけるビュー更新のルールは、ＳＷＣを追加／削除した場合には、対応するコンフィギュレーションのレコードも追加／削除を行うが（Ｃｏｎｆｓテーブルのビュー更新ルールＵＲ＝Ｔ）、ＢＵＳのレコードについては追加／削除を行わない（ＢＵＳｅｓテーブルのビュー更新ルールＵＲ＝Ｆ）というものである。

前述の図５のフローチャートを用いることで、図１５に示すように、ＳＷＣｓ，Ｃｏｎｆｓ，ＢＵＳｅｓテーブルにレコードが挿入される。このテーブルを結合することで、図１６のような表形式のビュー９０が得られる。

この表形式のビュー９０において、例えば、ＢＵＳ２に接続しているＳＷＣを全て表示して、必要バス帯域（ｂｗｉｄｔｈ）の合計を調べることができる。調査結果により、例えば、ＢＵＳ２の許容量を大きく下回っている場合は、ユーザは、ＢＵＳ２の帯域幅を下げてコスト削減を図ること等の対応を行うことができる。また、例えば、ＢＵＳ１とＢＵＳ２とにそれぞれ接続しているＳＷＣの必要バス帯域の合計を比較して、ＳＷＣ間でＢＵＳ帯域幅の融通をきかせたりするような分析・編集も可能である。

このように、表において特定の条件で絞り込んだ範囲を参照することで、異なる視点からシステムのモデルを分析し、それを参照した集約的制約等を効率的に記述することができる。

この例の場合は、同一テーブル（ＢＵＳｅｓ）内の検索条件でマッチする対象がＢＵＳ１かＢＵＳ２か、という意味で視点が異なるものであった。一般には、図６における車軸と油圧配管との関係のように、テーブルをまたがった条件を指定することで、様々な視点での分析・編集が可能である。

［モデル変換装置１のハードウェア構成］
図１７は、本実施形態に係るモデル変換装置１のハードウェア構成を示す図である。以下は、モデル変換装置１を、コンピュータを典型とする情報処理装置として全般的な構成を説明するが、専用機や組み込み型装置の場合、その環境に応じて必要最小限な構成を選択できることはいうまでもない。

モデル変換装置１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１０、バスライン１００５、通信Ｉ／Ｆ１０４０、メインメモリ１０５０、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）１０６０、パラレルポート１０８０、ＵＳＢポート１０９０、グラフィック・コントローラ１０２０、ＶＲＡＭ１０２４、音声プロセッサ１０３０、Ｉ／Ｏコントローラ１０７０、ならびにキーボード及びマウス・アダプタ１１００等の入力手段を備える。Ｉ／Ｏコントローラ１０７０には、フレキシブル・ディスク（ＦＤ）ドライブ１０７２、ハードディスク１０７４、光ディスク・ドライブ１０７６、半導体メモリ１０７８等の記憶手段を接続することができる。

グラフィック・コントローラ１０２０には、表示装置１０２２が接続されている。また、音声プロセッサ１０３０には、増幅回路１０３２、及びスピーカ１０３４が接続される。

ＢＩＯＳ１０６０は、モデル変換装置１の起動時にＣＰＵ１０１０が実行するブートプログラムや、モデル変換装置１のハードウェアに依存するプログラム等を格納する。ＦＤ（フレキシブル・ディスク）ドライブ１０７２は、フレキシブル・ディスク１０７１からプログラム又はデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０又はハードディスク１０７４に提供する。図１７には、モデル変換装置１の内部にハードディスク１０７４が含まれる例を示したが、バスライン１００５又はＩ／Ｏコントローラ１０７０に外部機器接続用インタフェース（図示せず）を接続し、モデル変換装置１の外部にハードディスクを接続又は増設してもよい。

光ディスク・ドライブ１０７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｋ）−ＲＯＭドライブ等を使用することができる。この際は各ドライブに対応した光ディスク１０７７を使用する必要がある。光ディスク・ドライブ１０７６は光ディスク１０７７からプログラム又はデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０又はハードディスク１０７４に提供することもできる。

モデル変換装置１に提供されるコンピュータ・プログラムは、フレキシブル・ディスク１０７１、光ディスク１０７７、又はメモリカード等の記録媒体に格納されて利用者によって提供される。このコンピュータ・プログラムは、Ｉ／Ｏコントローラ１０７０を介して、記録媒体から読み出され、又は通信Ｉ／Ｆ１０４０を介してダウンロードされることによって、モデル変換装置１にインストールされ実行される。コンピュータ・プログラムが情報処理装置に働きかけて行わせる動作は、既に説明した装置における動作と同一であるので省略する。

前述のコンピュータ・プログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としてはフレキシブル・ディスク１０７１、光ディスク１０７７、又はメモリカードの他に、ＭＤ等の光磁気記録媒体、テープ媒体を用いることができる。また、専用通信回線やインターネットに接続されたサーバシステムに設けたハードディスク又は光ディスク・ライブラリ等の記憶装置を記録媒体として使用し、通信回線を介してコンピュータ・プログラムをモデル変換装置１に提供してもよい。

以上の例は、モデル変換装置１について主に説明したが、コンピュータに、情報処理装置で説明した機能を有するプログラムをインストールして、そのコンピュータを情報処理装置として動作させることにより上記で説明した情報処理装置と同様な機能を実現することができる。したがって、本発明において１つの実施形態として説明した情報処理装置は、方法及びそのコンピュータ・プログラムによっても実現可能である。

本装置は、ハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアの組み合わせによる実施では、所定のプログラムを有するコンピュータ・システムでの実施が典型的な例として挙げられる。係る場合、該所定のプログラムが該コンピュータ・システムにロードされ実行されることにより、該プログラムは、コンピュータ・システムに本発明に係る処理を実行させる。このプログラムは、任意の言語、コード、又は表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接実行すること、又は（１）他の言語、コード、もしくは表記への変換、（２）他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行することを可能にするものである。もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記録した媒体を含むプログラム製品もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハードディスク装置、ＲＯＭ、ＲＡＭ、Ｍ−ＲＡＭ（Ｍａｇｎｅｔｏｒｅｓｉｓｔｉｖｅ ＲＡＭ）、フラッシュメモリ等の任意のコンピュータ可読媒体に格納することができる。係るプログラムは、コンピュータ可読媒体への格納のために、通信回線で接続する他のコンピュータ・システムからダウンロードしたり、他の媒体から複製したりすることができる。また、係るプログラムは、圧縮し、又は複数に分割して、単一又は複数の記録媒体に格納することもできる。

以上、本発明を実施形態に則して説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態又は実施例に記載されたものに限定されるものではない。

１ モデル変換装置
２ グラフモデル記憶部
３ 多次元データモデル記憶部
４ データ変換部
５ 表提示部
６ 処理記述入力部
２０，８０ グラフモデル
３０ 構造
３２ テーブル
３３ ルートブロックテーブル
３４，３５，３６，３７ ブロックテーブル
６０，９０ 表形式のビュー
Ｑ ブロック抽出クエリ
Ｑｂ，Ｑｐ クエリ
Ｌ ブロックテーブル

Claims (12)

1. コンピュータによって、システムのモデルの分析及び編集を容易にするためのシステムのモデルを変換する方法であって、
   前記コンピュータが、グラフ形式のデータ構造を有し、複数のモデル要素から構成される前記システムのモデルであるグラフモデルを記憶するグラフモデル記憶部を備えており、
   多次元データモデルの構造と前記モデル要素を抽出する抽出クエリとに関する記述を含んだ変換処理記述の入力を受け付けるステップと、
   入力された前記変換処理記述に基づき、前記グラフモデル記憶部に記憶された前記グラフモデルから、前記多次元データモデルを生成するステップとを含み、
   前記多次元データモデルが、ルートブロックテーブルと、前記ルートブロックテーブルから階層化されて広がる複数のブロックテーブルから構成されており、前記多次元データモデルの前記ルートブロックテーブル及び各前記ブロックテーブルにそれぞれ当該テーブルのレコードとして前記グラフモデルからどのブロックを抽出するかを指定するブロック抽出クエリが付与されており、
   前記ルートブロックテーブル及び各前記ブロックテーブルごとに、前記付与されたブロック抽出クエリに基づき抽出した前記グラフモデルのブロックをレコードに追加するステップをさらに含む、
   システムのモデルを変換する方法。
2. 前記多次元データモデルの中心のテーブルであるルートブロックテーブルに対応する前記モデル要素を、前記グラフモデルを構成する前記複数のモデル要素の中から予め指定するステップを含み、
   前記多次元データモデルを生成するステップが、指定された前記ルートブロックテーブルに関連付けられたブロックテーブル、及び前記ブロックテーブルに更に関連付けられたブロックテーブルに対して前記抽出クエリを順番に適用し、関連付けられたブロックテーブルが存在する間は前記ブロックテーブルに前記抽出クエリを適用して、抽出した前記モデル要素を用いて前記多次元データモデルを生成する、
   請求項１に記載のシステムのモデルを変換する方法。
3. 前記変換処理記述の入力を受け付けるステップが、スノーフレーク・スキーマを適用した前記多次元データモデルの構造に関する記述の入力を受け付ける、
   請求項１に記載のシステムのモデルを変換する方法。
4. 前記グラフモデルは、前記システムの構造、振る舞い及び制約のうち少なくともいずれかに関するものである、
   請求項１に記載のシステムのモデルを変換する方法。
5. 前記多次元データモデルを生成するステップにより生成された前記多次元データモデルから表形式のビューを生成するステップと、
   前記表形式のビューを生成するステップにより生成された前記表形式のビューを出力するステップと、
   を含む請求項１に記載のシステムのモデルを変換する方法。
6. 前記表形式のビューを出力するステップが、出力する特定の情報を指定するフィルタリング情報を受け付け、
   前記表形式のビューを出力するステップが、前記フィルタリング情報に基づいて前記表形式のビューを出力する、
   請求項５に記載のシステムのモデルを変換する方法。
7. 前記表形式のビューを出力するステップにより出力された前記表形式のビューに対する変更情報の入力を受け付けるステップと、
   前記多次元データモデルの更新に関するルールであるビュー更新ルールに関する記述を含んだ前記変換処理記述の入力を受け付けるステップと、
   前記多次元データモデルを生成するステップにより生成された前記多次元データモデルに、前記変換処理記述にしたがって前記変更情報の内容を反映するステップと、
   を含む請求項５に記載のシステムのモデルを変換する方法。
8. 前記表形式のビューを出力するステップにより出力された前記表形式のビューに対する変更情報の入力を受け付けるステップと、
   前記多次元データモデルの更新に関するルールであるビュー更新ルールに関する記述を含んだ前記変換処理記述の入力を受け付けるステップと、
   前記グラフモデル記憶部に記憶された前記グラフモデルに、前記変換処理記述にしたがって前記変更情報の内容を反映するステップと、
   を含む請求項５に記載のシステムのモデルを変換する方法。
9. 前記変更情報の入力を受け付けるステップにより受け付けた前記変更情報が、前記表形式のビューに対するセルの値の変更に関するものであることに応じて、前記多次元データモデルに反映するステップが、前記変換処理記述として前記抽出クエリを用い、
   前記変更情報の入力を受け付けるステップにより受け付けた前記変更情報が、前記表形式のビューに対する行の追加又は削除に関するものであることに応じて、前記多次元データモデルに反映するステップが、前記変換処理記述として前記ビュー更新ルールを用いる、
   請求項７に記載のシステムのモデルを変換する方法。
10. 前記表形式のビューを出力するステップにより出力された前記表形式のビューに基づいた制約式の記述を受け付けるステップと、
    予め定義された前記多次元データモデルと前記グラフモデルとの対応付け規則を取得するステップと、
    受け付けた前記制約式の記述から、前記対応付け規則を用いて前記グラフモデル記憶部に記憶された前記グラフモデルを更新するステップと、
    を含む請求項５に記載のシステムのモデルを変換する方法。
11. 請求項１から請求項１０までのいずれか１項に記載の方法のステップをコンピュータに実行させるためのコンピュータ・プログラム。
12. システムのモデルの分析及び編集を容易にするためのシステムモデル変換装置であって、
    グラフ形式のデータ構造を有し、複数のモデル要素から構成される前記システムのモデルであるグラフモデルを記憶するグラフモデル記憶部と、
    多次元データモデルの構造と前記モデル要素を抽出する抽出クエリとに関する記述を含んだ変換処理記述の入力を受け付ける処理記述入力部と、
    前記処理記述入力部から入力された前記変換処理記述に基づき、前記グラフモデル記憶部に記憶された前記グラフモデルから、前記多次元データモデルを生成するデータ変換部とを備え、
    前記多次元データモデルが、ルートブロックテーブルと、前記ルートブロックテーブルから階層化されて広がる複数のブロックテーブルから構成されており、前記多次元データモデルの前記ルートブロックテーブル及び各前記ブロックテーブルにそれぞれ当該テーブルのレコードとして前記グラフモデルからどのブロックを抽出するかを指定するブロック抽出クエリが付与されており、
    前記データ変換部は、前記ルートブロックテーブル及び各前記ブロックテーブルごとに、前記付与されたブロック抽出クエリに基づき抽出した前記グラフモデルのブロックをレコードに追加する、
    システムモデル変換装置。

Images