B-3 ジェネリックタスクを包含したドメインモデルに基づく - lise

B-3 ジェネリックタスクを包含したドメインモデルに基づく
ユースケースダイアグラム再利用法
笠原 利春，川端 亮，伊藤 潔
(上智大学 理工学部 情報理工学科)
第１章 はじめに
1.1 研究背景
日々，様々な分野で業務のコンピュータシステム化が行われている．システム開発者が，”図書管
理システム” や”医療カルテシステム” などのような新たなシステムを開発する際には，その開発し
ようとするシステムに，どのような機能が必要であるかを分析しなければならない．対象業務には
暗黙であり明示されていない決まり事や情報があり，システム分析は一般に困難なものである.また，
ユーザの観点から求められるシステムの機能を増やすだけではなく，システムを使うユーザには，
どのような種類があるのか，それらユーザは，お互いにどのような情報をやりとりするのか，ユー
ザとシステムはどのような関係か，システムに備わる複数の機能がどのような関係を持つかにも，
着目する必要がある．このように，様々な観点から分析する必要がある複雑なシステムには，協調
業務の観点から分析を行う．そのシステムの中に存在する情報，もの，ユーザとそれらの関係に着
目したシステム分析である．
協調業務が観察されるシステム全体の機能を記述する際に，ダイアグラム(モデル図)が日常的に
使われている．大規模かつ複雑なシステムの場合には,ダイアグラムを複数記述する必要があり，労
力を要する．このような分析は，一人ではなく，チームで分析を進めるために，誰が見ても同様に
解釈できる統一的な記述法が必要となる．ダイアグラムには多くの種類があるが，特に UML
(Unified Modeling Language) で定められるダイアグラムの中で，ユースケースダイアグラムは，
システムの機能(振る舞い)をシンプルに記述することができる．ダイアグラムの記述を効率化する
ため，過去に書かれたダイアグラムのを再利用が行われるが，再利用可能な過去の事例の選択や，
それを対象のシステムに合わせて修正することは，記述者の経験に大きく依存している．この作業
をコンピュータ支援により容易にすることが求められる．
1.2 研究目的
本研究の目的は，システム分析を容易にすることである．その手段として，ダイアグラム再利用
環境を提案する．過去に書かれたダイアグラムをライブラリに蓄積しておき，本環境のユーザがラ
イブラリから検索することで，ダイアグラムの再利用が可能になる．検索結果を基にして，新しい
ダイアグラムを作成(記述)できる．
本環境には，協調業務ドメインのシステムを記述したユースケースダイアグラムを蓄積する．こ
のユースケースダイアグラムは，既に開発済みのツールを用いて，MCM や規律性のあるペトリネ
ットなどに容易に変換できる．また再利用が容易に出来るように，ユースケースダイアグラムに含
1
第1章
序論
まれる動作を全て，ジェネリックタスク格文法表現で表す．
ジェネリックタスク[川端 1998] とは，複数のドメインにまたがる共通の業務である．ジェネリ
ックタスクの観点でユースケースダイアグラムを記述することで，様々なドメインのシステム分析
に，ダイアグラムの再利用性が高まる．
さらにジェネリックタスク中に含まれる動作を，格文法[Fillmore 1988] を用いて記述する．これ
により，検索時に動作主格，動作目的語など，検索対象にしたい仕事の内容を検索のパラメータと
して詳細に指定できる．
参考にできるドメインモデルを効率的に検索するために，検索する人が検索に用いる言葉と，ラ
イブラリの中に蓄積されている言葉の差異を吸収するためシソーラスを導入する．これにより最も
参照するのに有効なドメインモデルと，そのドメインモデルが含むジェネリックタスクを意味論的
な視点から，検索できる．
その検索結果から，ジェネリックタスクを組み合わせることで，新しいドメインモデルを生成す
ることが出来る．生成したドメインモデル(ドメインインスタンス)は，ユースケースダイアグラム
で表現される．また，ライブラリへの新規ドメインモデルの追加，新規ジェネリックタスクの追加
も可能である．
1.3 本研究の再利用環境
本研究の再利用環境は，ライブラリと，複数のツールで構成される
ライブラリは，過去に書かれたダイアグラムを蓄積したデータベースである．ダイアグラムのデ
ータをそのまま蓄積してあるのではなく，再利用がしやすいように，いくつかの観点に沿ってライ
ブラリ化を行っている．詳細は項目 3.2～3.6 で後述する．
本再利用環境のユーザが，ダイアグラムを再利用する際に使われるツールには，検索ツール，合
成ツール，シソーラスツールなどがあり，ユーザがライブラリを直接編集する為のツールとして，
ジェネリックタスク追加ツールなどがある．
本再利用環境から出力されるダイアグラムの種類は，現在はユースケースダイアグラムのみであ
るが，ユースケースダイアグラムを他の種類のダイアグラム(規律性のあるペトリネット, MCM,
CLM など)に変換するツールがすでに多く実装されている．
これら変換ツールとの連携についても，
後述する．
本研究が目指すもう一つのポイントとして，システム分析に詳しくない初心者にもわかりやすい
再利用環境にすることが挙げられる．システム分析をする観点や，分析作業自体も難しいが，ライ
ブラリのコンテンツを潤沢にし，ツールの使いやすさを向上させることで，それを解消する．
例えば，ある会社が新しい事業を始めようとするとき，その事業が未知のドメインであれば，事
業を始めるかどうかさえも判断出来ないかもしれない．そのような時に，本再利用環境からそのド
メインを検索し，瞬時にダイアグラムで全体像を見ることが出来る．そのダイアグラムが示してい
る内容は，その会社が，最終的に実現する事業とは，部分的に異なっているものかもしれないが，
有効な答えの一つである．つまり，最適解ではないかもしれないが，ヒューリスティックの一つで
あると言える．
またシステム分析に詳しい人が利用する場合にも，満足のいく環境でなければならない．ライブ
ラリからの詳細検索を可能にし，ダイアグラムを再利用し，ユースケースダイアグラムが出力され
た後は，自由に細かに編集できるようになっている．
2
第1章
序論
第 2 章 基礎事項
本章では，システム分析の説明と，協調業務の説明を行う．システム分析とは，システム開発の
最初に行われ，その後の行程の道筋を示す非常に重要な行程である．協調業務とは，システム分析
における重要な観点である．本再利用環境は，協調業務に着目しながら，困難なシステム分析をサ
ポートするものである．その位置づけなどを述べる．
2.1 システム開発
システム開発の流れを図 2.1.1 に示す．これはソフトウェア開発で多く用いられる手順で，ウォ
ーターフォールモデルと呼ばれる．上流(要求分析) から下流 (保守, 運用) へ向かって開発を進め
て行くモデルであり，前のステップを確実に終了させてから次のステップに進む．基本的に前のス
テップに逆戻りする事はできない．また，そのシステムが完成したときに，システムのユーザ(エン
ドユーザやシステム管理者) から求められる機能がシステムに全て備わり，機能同士の矛盾が無い
ようにしなければならない．もし逆戻りした場合，多くの損失(コスト, 労力, 時間など)が発生する．
つまり，逆戻りする事がないように，先のステップを見据えて進めて行くモデルである．
図 2.1.1 ウォーターフォールモデル
ウォーターフォールモデル以外にもスパイラルモデル，プロトタイプモデルなどがあるが，ここ
では詳説しない．
図 2.1.1 の要求分析とは，これから開発するシステムのユーザ(エンドユーザ，システム管理者) が
新しいシステムに求めるニーズを調査・分析する行程である．要求分析を細かく分けると，ドメイ
ン分析, 要件定義, システム分析に分ける事が出来る．ドメイン分析とは，その開発しようとする
3
第2章
基礎事項
システムが置かれるドメイン(領域)で，どのような作業があるかを分析する行程である．コンピュ
ータシステムでは実現できない機能(例: 調理など)も，全て調査する．それから，分析したドメイン
に対して，要件定義を行う．要件定義とは，そのドメインの中で，どの部分をシステム化する必要
があるかを定義する事である．ユーザのニーズを把握し，システムの持つ機能や，その機能の追加
によるドメインへの効果を分析する．最後に，システム分析を行う．現実の世界で必要な機能を，
プログラムの世界とつなぎ合わせる重要な行程である．
図 2.1.1 に要求分析の位置づけを示したが，実は非常に曖昧な部分でもある．
まず，ドメイン分析, 要件定義, システム分析がきちんと分けて認識されていない事がある．モ
デリング(ダイアグラムを書くこと) をする人がプログラムに詳しい人である場合，ドメイン分析と
要件定義をしないで，システム分析から始める事があり，彼にとっては，要求分析=システム分析
という図式が成り立ってしまう．彼がシステム分析に詳しくない場合，システムのユーザのニーズ
と違ったシステムが出来る可能性がある．
また，要求分析, システム分析, 要件定義, ドメイン分析は，統一された言葉ではない．例えば要
件定義は，要求定義とも呼ばれる．実際，システムを構築しているような会社は，会社ごとに独自
の言葉遣いをしている．
2.2 システム分析
システム分析では，分析とモデリングが分けて考えられる．分析とは，目に見えないユーザのニ
ーズや，システムがそのドメインに置かれる事の効果の列挙である．モデリングは，そのシステム
が持つ機能をダイアグラムに記述することである．ダイアグラムの記述は，直接プログラム設計に
つながる，大切なものであるので，構造化され，かつ MECE (Mutually Exclusive, Collectively
Exhaustive) でなくてはならない．
このようにシステム分析は労力のかかる作業であるが，それに加えて，年々開発されるシステム
は複雑になる一方である．そこで本研究はこのシステム分析を容易にする事を目的とした．
本再利用環境のライブラリには，既に分析されたダイアグラムが多く蓄積されているが，それら
は構造化され，MECE なものである．また，それらダイアグラムはシステムだけではなく，ドメイ
ンの範囲までも記述してある．つまり，ドメインの全体像が見えると同時に，プログラム設計に有
用なものである．本再利用環境は，正確には，図 2.1.1 のドメイン分析を行うものであるが，シス
テム分析にシームレスに移行することができる．
2.3 協調業務
協調業務とは，複数の作業者と組織による協調的なプロセスの事である．システムの中に存在す
るユーザ，情報，もの，それらの関係が複雑に関わる業務の事である．近年，開発されるシステム
が複雑化している為に，多くのシステムにおいて協調業務が観察される．協調業務の観点からシス
テムを分析する事は，システム内部のリソースの共有などにも着目出来る．よって協調業務に着目
する事は，モデリングするダイアグラムが，実際のドメインと離れてしまわないようにする事が出
来る．
このように協調業務は大切な観点であるが，
モデリングに使われるような全てのダイアグラムが，
協調業務を表せるわけではない．
ここでは後述する項目 2.6～2.9 で，
ユースケースダイアグラム, 規
律性のあるペトリネット, MCM, CLM に限って説明する．特に規律性のあるペトリネット, MCM,
CLM は，システムの中の協調状態を表すのに有力なダイアグラムである．ユースケースダイアグ
ラムは，本再利用環境でベースとなっているダイアグラムである．
4
第2章
基礎事項
本研究では特に，システムの中に存在する M/I(マテリアル&インフォメーション) の協調状態を
重視する．M/I とは，システムの中で生成，状態変化するものや，システムのユーザ間のやりとり
の媒介となるもの，システムの状態推移を記録する為などに使われる情報やものの事である．ユー
ザの作業単位を基準にしてシステムの機能を記述せず，M/I の状態変化に着目してシステムの機能
を記述する．これにより，システム分析者ごとのシステム分析の結果(ダイアグラム) が大きく異な
ったりすることを防ぐ事が出来る．
項目 2.6 で詳述するが，本研究で扱うユースケースダイアグラムは，一般的なユースケースダイ
アグラムではなく，協調業務向きのユースケースダイアグラムを使う．これは M/I の観点がベース
となっている．そして，この協調業務向きのユースケースダイアグラムは，各種のダイアグラム変
換ツールを用いる事で，規律性のあるペトリネット，MCM, CLM など様々なダイアグラムに変換
する事が出来る．M/I については，項目 2.6 で説明する．
2.4 ダイアグラム
システム開発者は様々な観点からシステムを把握する必要がある．例えば人，もの，情報の流れ
や，システムの状態遷移である．また，マクロの視点とミクロの視点でシステムを分析する必要も
ある．そこで利用されるのがダイアグラムである．ダイアグラムはシステムの全体像とシステムの
詳細を表す事ができる．また，作業フロー, システムのユーザ, データフロー, データベース, ネッ
トワークなど, システムは多くの側面を持っている. 一種類のダイアグラムではその総ての側面を
表すことが出来ないので, システムアナリストは二つ以上のダイアグラムを用いることになる．複
数の種類のダイアグラムでシステムを表す事で，様々な観点からシステムを分析する事が出来, 膨
大な情報量を平面に表す事が出来る．ダイアグラムはシステムのユーザやその業種のエキスパート
からの情報を参考にして記述される.
ダイアグラムには多くの種類が存在する．例えば UML(Unified Modeling Language) は 1997
年に OMG(Object Management Group) の標準となった，ダイアグラムの統一規格である．オブ
ジェクト指向で，システム開発をする際に使われる．オブジェクト指向言語(プログラミング言語)
との連携を高めてあるので，UML2.0 ではダイアグラムからプログラムのソースコードを生成する
事が可能になっている．その手順は，まずユースケースダイアグラムを使って，システムに求めら
れる大まかな機能を書く．そして，ロバストネス図を使って，そのユースケースダイアグラムをさ
らに詳細に表す．最後にクラス図を使って，オブジェクト指向言語のクラス構造を書く．このよう
にして，現実にシステムに求められている機能を，プログラミングの領域に落とし込んで行くこと
が出来る．
システムの協調状態を表すのに有力なダイアグラムには，ユースケースダイアグラム，規律性の
あるペトリネット，MCM, CLM が挙げられる．これらのダイアグラムを用いる事で，複雑なシス
テムを詳細に記述する事が出来る．
システム開発において，一番重要な目的であるのは，”システムを確実に開発すること” であり，
ダイアグラム書くことは手段である． UML はその為に作られた”手段”の統一規格であるが，オブ
ジェクト指向言語以外には使いにくく，活発に用いられているのは，限られた分野のみである．し
かし，ダイアグラムはシステム分析には有用であることは間違いない．それ故に，本研究では詳細
なシステム記述が出来る協調業務向けのダイアグラムを使い，そのダイアグラムを即座に作成でき
る再利用環境を提案している．
以降，本研究に関係する協調業務向けのダイアグラムのそれぞれの基本的な構成や特徴を説明し
て行く．
5
第2章
基礎事項
2.5 ダイアグラムの再利用
多くの協調業務が既に上記に示したようなダイアグラムで表現されている．新たに協調業務を
分析する際に，その既に書かれたダイアグラムを参考にしながら分析を進めることは，大変有効な
手段である．なぜなら，既に完成しているダイアグラムを見ながらの分析では全体を見渡した分析
が可能であると同時に，協調業務分析の際に頻発する，システムの機能の見落としや，冗長な部分
の書き足しなどを防げるからである．しかし，そのような再利用の価値があるダイアグラムであっ
ても，総てのダイアグラムが一括管理されている訳ではないので，実際に再利用したい人がそのダ
イアグラムを手に入れる事は容易ではない．また，手に入ったとしても，その参考にするダイアグ
ラムが，参考にするのに最適なダイアグラムであるとは限らない．
ダイアグラムの再利用には図 2.5.1 に示すようなステップがあると考えられる．
図 2.5.1 ダイアグラム再利用の手順
本再利用環境は，この図 2.5.1 に示すステップを全てサポートする．これにより，システム分析
をより効率的に進めることが出来ると考える．
2.6 ユースケースダイアグラム(Use Case Diagram)
ユースケースダイアグラムとは，Ivar Jacobson によって提案された，ユースケースを視覚化
するためのモデル図である．一般的に，ユースケースダイアグラムは UML(Unified Modeling
Language)を使った分析で要求分析に利用される．対象システムの振る舞い，機能要求をユースケ
ースとして列挙することにより記述される．ユースケースはシステムのユーザの視点で，システム
のユーザが対象システムに対して求める機能の列挙が可能である．
ユースケースダイアグラムの構成要素を図 2.6.1 に示す．ユースケースダイアグラムは主に，シ
ステム境界枠(system boundary)，アクタ(actor)，ユースケース(use case)，アソシエーション
(association)から構成される．システム境界は，対象システムとそれ以外を区別するために用いる．
アクタは対象システムを利用するユーザ表し，必ずしも人である必要はない．例えば，他のシステ
ムがユーザとなる事が出来る．ユースケースは対象システムに対する”use case(使い方・利用法)”
を記述する．関連はユースケースとそれに関わるアクタを関連付ける．図 2.6.2 に例として病院ド
メインのユースケースダイアグラムを示す．
6
第2章
基礎事項
図 2.6.1 ユースケースダイアグラムの構成要素
図 2.6.2 病院ドメインのユースケースダイアグラム
ユースケースダイアグラムは，シンプルな構造で，記述も容易である．その柔軟さ故に，システ
7
第2章
基礎事項
ム分析者によって結果が違ったりする恐れや，曖昧な記述になってしまう恐れがある．そこで，ユ
ースケースダイアグラムで協調業務を正確に表すために，ルールを設ける．そのルールの中心とな
るのが，M/I(マテリアル&インフォメーション)である．
M/I(マテリアル&インフォメーション)とは，システムにおいて，システムのユーザによってやり
とりされる情報やもののことである．以下の 3 つが M/I として認識される



システム内で生成される情報やもの
アクタが他のアクタと交信する際に使われる情報やもの
タスクや状態を記録する為に使われる情報やもの
ここでの”情報”とは，システムのユーザが一塊として認識しているようなデータの集合のことを指
す．例えば，DVD レンタルシステムにおいて，”会員情報”が M/I の一つであると考えられる．”会
員情報”は，会員番号，会員氏名，年齢などのデータの集まりである．
協調業務向きのユースケースダイアグラムは，M/I のライフサイクルを表している．一般的にラ
イフサイクル(life cycle) とは，ある対象の誕生から消滅までを意味するが，情報システムの分野に
おいてのライフサイクルとは，システム化の要求が生じて(誕生)から，そのシステムの構築と運用
を続け，何らかの理由により不要になる(消滅) までの期間を示している．[河村 1999] よって，本
研究では M/I がシステムの中で発生，あるいはシステムの中に入ることを(誕生)，M/I がシステム
の中で消滅，あるいはシステムの外に出て行くことを(消滅)と定義する．[大曽根 2004]
M/I を中心に，システムの協調状態を捉えるためには，ユーザが M/I をやりとりする様子を正確
に記述しなければならない．そこで，M/I の送受を表す為のユースケース，ユースケース(from)と
ユースケース(to)を導入する．from と to の概念を図 2.6.3 に示す．
C
From
to
B
��
図 2.6.3 from と to の概念
図 2.6.3 では，アクタ C が，資料をアクタ B に渡す様子が描かれている．この様子をまず，”送
り”と”受け取り”の概念 2 つセットであると考える．つまり 2 つのユースケースでこのやりとりを表
す．さらに，送受を明確化する為に，誰に対して送るのか，誰から受け取るのかもユースケースに
記述する．その明記の様子を図 2.6.4 に示す．
8
第2章
基礎事項
A
�����
C
A
�����
�����
�����
�
�
�
C
to B
����� from C
�����
B
�����
D
B
�����
�
�
�
D
図 2.6.4 ユースケース(from)とユースケース(to)を用いた明確化
協調業務向きのユースケースダイアグラムの記述の手順は，以下の通りである
(Step 1) システムの内部に存在するユーザと M/I を総て列挙する
(Step 2) M/I 毎にユースケースダイアグラムを記述していく．この時のユースケースは，M/I に状
態変化を起こすようなユーザのタスクである．
(Step 3) それぞれの M/I のライフサイクルに矛盾がないかを調べる．
本再利用環境のライブラリには，様々なドメインを分析した，協調業務向きのユースケースダイ
アグラムが蓄積されている．
2.7 規律性のあるペトリネット(Petri net)
ペトリネット[J. Peterson 1984]は，互いに関連しあう同時進行的な要素からなるシステムをモデ
ル化することを目的として作られたダイアグラムである．ペトリネットでは，ものや情報が処理さ
れていく過程で，それらのものや情報を処理する主体との待ち合わせ，同期，競合を把握する観点
でシステムを記述する．[伊藤 2001] ペトリネットの構成要素は図 2.7.1 に示す．
9
第2章
基礎事項
図 2.7.1 ペトリネットの構成要素
プレースの中にトークンがある場合は，作業やものが移動し終わった状態，あるいは作業の始ま
り，もしくは次の仕事の待ち状態を表している．何らかの事象がおこる(発火する)とトランジショ
ンと通じて次のプレースへとトークンは移動する．
ペトリネットのトークンの移動の様子は図 2.7.2
に示す．
(a)
(b)
(c)
図 2.7.2 ペトリネットのトークンの挙動
トークンが左図の(a)の状態にあり，
何らかの事象が起こるとトークンは 2 つに複製され(b)の状態に
なる．トークンが 2 つに分かれたことは，作業を並行して行っていく事を示している．両方の仕事
が終わると次の自称が起こり 2 つのトークンが 1 つに合流して(c)のように下へと移動する．
ペトリネットは，その柔軟な記述方法のために，作成者によって異なる書き方のダイアグラムと
なり，共通の理解ができなくなるおそれがある．記述されたダイアグラムは，第三者に理解される
正確性・一貫性を兼ね備えたものでなければならない．そこで，ペトリネットを記述する際に，記
述手順に規律を持たせ，作成者の主観に左右され難い記述を支援する．ペトリネット記述法に 1 つ
の指針を与え，同時に，各主体の作業フロー，主体間の同期，待ち合わせ，競合を明確にできる．
本研究でも作業の主体を明確にするこの規律性のあるペトリネット記述法を導入することにする．
10
第2章
基礎事項
[瀬沼 2002]
規律性のあるペトリネットは，以下の特徴を持つ．
A) サービスを提供する主体と受ける主体を区別
B) 複数作業者が並行に作業する様子を記述
C) 複数作業者間でのものや情報のやりとりを記述
ディーラ・コンサルタント
購入者からのトークン
仮仕様書受諾
仮仕様書受諾
仕様書作成
仕様書作成
ディーラ・コンサルタント
図 2.7.3 規律性のあるペトリネット
図 2.7.3 は規律性のあるペトリネットの例である．図の左側のペトリネットは，タスクの流れの
みを表しているが，右側の規律性を持ったペトリネットでは，タスクの流れだけではなく，サービ
スを受ける側(購入者) がクライアントとして動き，サービスを与える側(ディーラ・コンサルタント)
がサーバ的な動きをしていることが明確である．
規律性のあるペトリネットの記述手順は以下の通りである．
(Step 1) 対象システムの目的を達成するためのサービスを受ける主体を認識
対象システムにおいて，ものや情報を処理する主体が複数個存在する(例えば，
「客」や「受付係」
，
「管理エージェント」などである)．対象システムの目的を明確化し，主体群の中から，目的を達成
しようとする主体を特定する．
(Step 2) 対象システムの目的を達成するためのサービスを受ける主体の，もの・情報を処理する過
程(作業フロー)を上から下に記述
Step 1 で特定した主体の，もの・情報を処理する過程を分析し，記述．作業フローは時系列と考
えてよい．
(Step 3) 主体の持つ作業フローの記述は，この主体の視点に立った記述に固定
ペトリネットの性質上，様々な箇所で主体やそのほかのもの，情報同士の同期，競合，待ち合わ
せが行われる為に行う．視点を固定しない場合，記述を行っている途中で処理を行うもの，処理さ
れるものの立場が逆転してしまう可能性があるからである．
11
第2章
基礎事項
(Step 4) 対象システムの目的を達成するためのサービスを受ける主体に対して，サービスを行う主
体，あるいは，協調して仕事を行う主体を認識
Step 1 で特定した主体の，もの・情報を処理する過程をサポートする主体を分析し，サービスを
行う主体，あるいは，協調業務を行う主体として認識する．
(Step 5) サービスを行う主体，あるいは協調して仕事を行う主体の，もの・情報を処理する過程(作
業フロー)を上から下に記述
Step 4 で認識した主体の，もの・情報を処理する過程を分析し，記述する．
(Step 6) 主体間における同期，競合，待ち合わせを分析し，記述
ここまでに認識した主体同士が，直接関わりをもつトランジションを分析し，その同期，競合，
待ち合わせを記述する．
(Step 7) サービスを行う主体に対して，さらにサービスを行う主体，あるいは協調して仕事を行う
主体を認識
Step 4 で認識した主体の，もの・情報を処理する過程をサポートする主体を分析し，さらにサー
ビスを行う主体，あるいは，協調して仕事を行う主体として認識する．
(Step 8) さらにサービスを行う主体，あるいは協調して仕事を行う主体の，もの・情報を処理する
過程を記述
Step 7 で認識した主体の，もの・情報を処理する過程を分析し，記述する．
(Step 9) 各主体間における同期，競合，待ち合わせを分析し，記述
これまでのステップで認識した各主体同士が，直接関わりを持つトランジションを分析し，その
同期，競合，待ち合わせを記述する．
(Step 10) 認識できる主体がなくなるまで Step3～Step 9 の手順を繰り返す．
図 2.7.4 は規律性のあるペトリネット記述法で記述した自動車販売ドメインである．
以降，
本研究ではペトリネットとはこの規律性のあるペトリネット記述法で記述したダイアグラム
の事を指すこととする．
12
第2章
基礎事項
購入者
設計・製造スタッフ
ディーラ・コンサルタント
車の仕様を
検討
会計
仮仕様書
受諾
在庫管理スタッフ
発注書
受取り
仕様書受取り・確認
仮仕様書
提出
仕様書・見積書
作成
設計書作成
在庫確認
仕様書・見積書
受取り
仕様書・見積書
送付
部品確認・
発注書作成
部品送付
仕様書・見積書
確認
仕様書・見積書
確認/決定
発注書送付
在庫
仕入れ
仕様書送付
部品受取り
在庫DB
更新
請求書作成
車の組立て
車受取り
請求書
送付
車
受取り・納車
納車
終了
（購入者）
図 2.7.4 自動車販売ドメイン
2.8 MCM (Multi Context Map)
MCM[長谷川 2002]とは，複数のコンテクストマップの関係を統合することで，ドメインやシ
ステムの構造を示すダイアグラムである．コンテクストマップとは，パースペクティブの接面
において，トークン(作業者間に存在する事実情報)，インフォメーション(作業者間で受け渡さ
れる情報)，マテリアル(質量を持ち現実のものとして存在するもの) の入出力状態をダイアグラ
ムに示したものである．パースペクティブとは，協調業務において，それに関わる主体(作業に
関わる人，組織，装置) の個々の領域である．2 つのパースペクティブがひとつのコンテクスト
となり，協調業務を行う．図 2.8.1 は MCM における一つのコンテクストマップの例を現す．
また，図 2.8.2 にコンテクストマップの構成要素を示す．
13
第2章
基礎事項
乗客
受付係
右側パースペクティブ（複数）
左側パースペクティブ（複数）
乗客が到着した
(トークン)
乗客(マテリアル)
チェックインが終了した
チェックインする
(コンテクスト)
乗客
搭乗券
航空券(インフォメーション)
(左側資源)
受付係(右側資源)
(入力資源)
(出力資源)
図 2.8.1 コンテクストマップ
図 2.8.2 コンテクストマップの構成要素
これらを用いて，協調作業をコンテクストマップとして記述する．これらコンテクストマップを統
合し，ドメインやシステムを表す MCM が完成する．この際，ドメイン全体を流れるトークン，イ
ンフォメーション，マテリアルの分岐や合流を表現するために 5 種類のジャンクションを用いる．
ジャンクションは組み合わせて使用する事もでき，トークン，インフォメーション，マテリアルご
とに別のジャンクションが用意されている．
以下にジャンクションの示す．図における T はトークン，M はマテリアル，I はインフォメーシ
ョンを示している．
14
第2章
基礎事項
[Branch Junction] (Br ジャンクション)
Br ジャンクションでは，それ以降にある複数のコンテクスト(あるいはジャンクション) の中か
ら，1 つを選択し，それに対してトークン，インフォメーション，マテリアルを入力する．Br ジャ
ンクションはトークン，インフォメーション，マテリアル全てに使用できる．
Context ２
I2
I1
Br
Context 1
I3
Context ３
図 2.8.3 Branch Junction
[Duplication Junction] (Du ジャンクション)
Du ジャンクションでは，それ以降にある複数のコンテクストに同一のものを入力する．Du ジャ
ンクションは，トークンとインフォメーションに使用できると考えられる．トークンやインフォメ
ーションが Du ジャンクションによって複製され，同一のものが以降に流れる．
Context ２
I1
I1
Context 1
Du
I1
Context ３
図 2.8.4 Duplication Junction
[Decomposition Junction] (De ジャンクション)
De ジャンクションでは，それ以降にある複数のコンテクストに対して，元のものを分割して，
それぞれ別のものを入力する．De ジャンクションは，マテリアルとインフォメーションの分割が
考えられる．
15
第2章
基礎事項
Context ２
I2
I1
De
Context 1
I3
Context ３
図 2.8.5 Decomposition Junction
[Synchronization Junction] (Sy ジャンクション)
Sy ジャンクションでは，その前に存在する全てのコンテクストからの出力を受け取って，それを
まとめてから，次のコンテクストに入力する．そうすることで，同期を取ることができる．Sy ジャ
ンクションはトークン，インフォメーション，マテリアル全てに使用できる．また，同期をとった
後にトークン，インフォメーション，マテリアルの名称が変わる場合も考えられる．
Context 1
I1
{I1,I2} or I3
Sy
Context 2
Context 3
I2
図 2.8.6 Synchronization Junction
[Serialization Junction] (Se ジャンクション)
Se ジャンクションでは，その前に存在する全てのコンテクストからの出力を受け取り，受け取っ
た順番に列をなして次のコンテクストに入力する．Se ジャンクションはトークン，インフォメーシ
ョン，マテリアル全てに使用できる．
16
第2章
基礎事項
Context 1
I1
I1 or I2
Se
Context 3
I2
Context 2
図 2.8.7 Serialization Junction
2.9 CLM (Collaborative Linkage Map)
CLM[長谷川 2002]とは，協調業務において作業者間で共有される，情報やものの状態変化を把握
するために，提案されたダイアグラムである．協調業務において，作業者が協力しながら作業を進
めていく際に，作業者間ではさまざまな情報やものを共有している．CLM はこのものや情報の状態
変化を明確に記述することが可能である．
CLM では状態遷移図を記述する際に，人に対する状態遷移図：Personal State Transition
Diagram(P-STD) と，情報ものに対する状態遷移図：Material State Transition Diagram (M-STD) を作成
する．作業者と情報・ものがなりうる状態の種類は 3 種類と定義される．作業者が主に行う動作に
は，本質を行う Enaction State，作業を依頼されたり引き継いだりする Commission State，待ち状態の
Dormant State と分析されている．
[Enaction State]
P-STD の Enaction State は，作業者が情報やものを使用して，作業者に課せられた本質的な作業を
行っている状態を示す．M-STD の Enaction State は，情報やものが作業者によって参照されたとき
や，変化を加えられたときの状態を示す．
[Commission State]
作業者が他の作業者と協調している状態である．他の作業者に情報やものを渡していたり，渡さ
れていたり，するときの状態は Commission State である．また，情報やものに対しても作業者間で
受け渡されている状態のときには，その状態を Commission State と定義する．
[Dormant State]
Enaction State,や Commission State 以外の状態である．作業者が作業せずにいる状態や，資源が保
管されている状態などをいう．この状態の例として作業の待ち状態が挙げられる．また，作業の本
質ではないが，その準備段階の状態など，その作業をするにあたって必要であると考えられる場合
も，その状態を Dormant State として定義する．
作業者と資源がなりうる状態は，両者同じである．そのため P-STD と M-STD はお互い関連する
状態を持っている．
P-STD とM-STD のEnaction State は，
PM Collaboration State を介して結合される．
同様に 2 つの P-STD の Commission State 同士も PP Collaboration State を介して結合される．また，2
つの M-STD の Commission State 同士は MM Collaboration State を介して結合される． Collaboration
17
第2章
基礎事項
State とは協調業務における協調状態を示す．
[PM Collaboration State] (PM-C-S)
分析対象業務の協業状態である．作業者は情報やものを参照もしくは使用しながら，作業を遂行
することがある．すなわち，作業者と資源との間には協業している状態がある．その状態を PM-C-S
と定義する．PM-C-S は，作業者が情報・ものを使用して作業しているという関係に着目して作成
する．
[PP Collaboration State] (PP-C-S)
作業が切り替わるときに，両作業者間で情報やものが受け渡される．その情報やものは，PP-C-S
で表す．作業の切り替えを，異なる P-STD 上にある 2 つの Commission State の結合で表す．
[MM Collaboration State] (MM-C-S)
2 つ以上のものが組み合わされ，1 つの製品になる状況や，1 つのものが 2 つ以上のものへと分解
や分離，分別されるときの状態を MM-C-S で表す．MM-C-S は 3 つ以上の M-STD の Enaction State
結合で表す．
図 2.9.1 に CLM を構成する要素の表記を示す．
図 2.9.1 CLM の要素の表記
18
第2章
基礎事項
第3章
ダイアグラム再利用環境
本章では，ダイアグラム再利用環境と，その環境に含まれるライブラリと再利用の手順について
述べる．本再利用環境で特に重要なのは，ライブラリ内部の構造である．その構造は，システム分
析において有用な考え方を組み合わせて，構築されたものである．ライブラリの構造と，その利用
方法について説明する．
3.1 ダイアグラム再利用環境
図 3.1.1 は，ダイアグラム再利用環境の概観である．
図 3.1.1 ダイアグラム再利用環境の概観
図の右側には，ライブラリがある．ライブラリの中身は，再利用がしやすいような構造になって
いる．図中のジェネリックタスク，格文法，ドメインモデル，シソーラスについては後述する．
このライブラリから，ダイアグラムの再利用を行う．図の左上にあるような検索窓を使い，本再
利用環境のユーザは，目的のドメインに近いドメインや，ジェネリックタスクを検索する．何度か
検索をした後に，それら検索結果を組み合わせることで，目的のドメインの，ユースケースダイア
グラムを出力することが出来る．
本再利用環境は Microsoft Visio 上で動き，出力されたユースケースダイアグラムは，Microsoft
Visio 上に描かれる．Microsoft Visio は実務フローや組織図，企画書，プレゼンテーション資料な
どの図入り文書を簡単に作成できるソフトウェアである．Visio が持つ様々なシェイプを配置する
ことにより作図を行うことができる作図機能や，建築/ネットワーク/電気などの図面の種類ごとの
製図ツールやテンプレートを用いて作図を行うことができる．また，それらの機能を Visual Basic
for Application(VBA)によって高度なカスタマイズやアプリケーション開発が可能である．
本再利用環境では，ライブラリを検索し，検索結果を合成するツールだけではなく，ライブラリ
内部を編集するツールも存在する．新しいジェネリックタスクを追加できるツールと，既に登録さ
れているジェネリックタスクを編集するツールである．ジェネリックタスクの考え方は非常に難し
19
第3章
ダイアグラム再利用環境
いので，実際にライブラリを編集できる人は，ジェネリックタスクについて熟知している人に限ら
れる．しかし，機能的には誰でも編集が可能なようになっている．これは，複数の編集人によって
ライブラリが構成される事で，ライブラリの内容の正確性を高めようという狙いである．例えば，
ウェブ上のオンライン百科事典である，wikipedia [wikipedia]は，有志のユーザによって内容が作
られている．Wikipedia 上に既に書かれている内容は，書いた人以外が追記，修正する事が可能で
ある．この働きにより，wikipedia の情報の信頼性が高まっている．
また，本再利用環境では，基本的にライブラリの中にある情報を参考にして，新しいドメインを
構築する．この方法で，ライブラリの内容に縛られた空間でしかドメインの構築を考えられない，
という考えが挙がるかもしれない．しかし，ライブラリの内容は，上記したように複数の編集人に
よって信頼性が高められたものである．また，ライブラリに最初から入っている情報の種類は，昔
から情報システムの分野で研究され，実際にシステムとして実現されてきたものである．このよう
なレガシなシステムを参考にすることは，非常に有用である．
ビジネスの観点からすると，本再利用環境に求められるのは，有用性だと考えられる．有用な再
利用環境であること，使いやすい再利用環境であること，再利用できる情報に信頼性があること，
などである．一方，アカデミックな観点からすると，本研究において大きなものは，情報システム
の為の新しいフレームワークを提案している点である．ダイアグラムの再利用は昔から取り組まれ
てきた事であるが，その再利用の新しい方法を提案し，それを有用なものとして形にしたのが本再
利用環境である．
3.2 ジェネリックタスク
ジェネリックタスク[川端 1998]とは，複数のドメインをまたいで存在する業務ことである．複
数のドメインに共通する業務であるので，共通業務とも言う．図 3.2.1 にジェネリックタスクの例
を示す．予約の業務は，図 3.2.1 に現れている全てのドメインで行われる業務である．
図 3.2.1 ジェネリックタスクの例
ジェネリックタスク(generic tasks)は，元々は AI(Artificial Intelligence)や KBS(knowledge
based system)などの分野で使われてきた言葉である．[CLAES 1997] 近年，コンピュータシステ
20
第3章
ダイアグラム再利用環境
ムを開発する際に，そのシステムに持たせる機能を一般化させて考える際にも用いられるようにな
っている．[J.Cornelis 2002]
ジェネリックタスクは，ライブラリ内では一般的に使われる名詞や動詞で保存されている．この
一般的な名詞や動詞を GT term と呼ぶ．
ジェネリックタスクはオブジェクト指向のクラスものであ
る．実際にあるドメインの中のタスクとして使う時は，ジェネリックタスクのインスタンスを生成
する．その時，ジェネリックタスクで使われている GT term は，その使われるドメインごとに固有
のものに置き換えられる．
そのドメイン固有の名詞や動詞は，ジェネリックタスクとは別に，ドメインごとのシソーラスと
してライブラリに保存されている．例えば，”宿泊客”という動作主格は図 1 ではホテルドメインで
しか使われない．一方”顧客”という動作主格は図 1 の全てのドメインで使うことができる．つまり，”
顧客”は GT term として採用できる．
本研究では，全てのドメインは，1 つ以上のジェネリックタスクの組み合わせによって表現する．
複数のジェネリックタスクのインスタンスの組み合わせによって生成されたドメインを，ドメイン
インスタンスと呼ぶ．
3.3 格文法
格文法[Fillmore 1988] とは，Fillmore が提唱した，言語処理論である．コンピュータによる自
然言語処理(natural language processing)において広く用いられている．言語に対する意味論的な
アプローチによって，言語を分析する．語と語の間の意味的関係を重視し，文の意味構造を動詞を
中心とした格文法構造によって表現する．
文を意味構造で捕らえるので，後述するシソーラスに，日本語以外の言語を追加すれば，言語の
違いを吸収できる．
格(case)とは，単語間の意味的関係(特に動詞と名詞間)を示すもので，正確には表層格(surface
case)と深層格(deep case)からなる．表層格とは，(構文木から)表層的に決まる格であり，一般的に”
文法”として認識されている，文の分割法とその構造である．深層格(deep case)とは，表層だけでは
決まらない, 真の格であり，文の文法に依らない意味的な分割と，その相互関係である．意味的な
アプローチであるので，全ての言語において共通に成り立つ．文の意味構造を動詞-深層格-名詞と
いう関係の集合として捉えたものを，格文法構造(格構造)と言う．本研究ではライブラリのドメイ
ンモデルが含むジェネリックタスク中の動作を，格文法構造にし，それを検索対象物としている．
図 3.3.1 に格の例を示す．
21
第3章
ダイアグラム再利用環境
動作主格
動作
対象格
場所格
時間格
源泉格
目標格
道具格
経験者格
条件節
動作を引き起こすもの
動作が作用する対象となるもの
動作が起こる場所や位置を表すもの
動作が起こる時間を表すもの
移動における起点を表すもの
移動における終点を表すもの
動作を起こさせるもの
心理状態を体験するもの
その動作が行われる条件
図 3.3.1 格の例
また，図 3.3.2 は，本研究で検索機構の中に蓄積されているジェネリックタスクのデータの一部
である．
協調業務においては，作業者，情報，物，これらの関係を分析することが重要である．本研究で
は目的ドメイン内に存在する情報や物に着目してドメインを記述する方法を採用する．図 3.3.2 に
おいて，図 3.3.1 の対象格(一般的な文法での目的語に該当する)は，”請求書”となっている．これは”
請求書”の状態変化に着目してドメインを格文法構造にしているからである．本研究では，対象格に
ドメインの中に存在する物が当てはまるように格文法構造を構築している．物や情報の状態変化に
着目してドメインを記述することで，詳細なドメイン分析を行うことができるからである．
図 3.3.2 の右側に示されている条件節は，格文法で記述されたジェネリックタスクの中の一つの
動作，つまり図 3.3.2 に表されているデータの一行と，その行の動作が起こりうる条件を示してい
る．これで，異なる行に書かれた動作間のつながりを示す事が出来る．例えば，”会計係”と”請求書”
が検索語として入力されたとする．図 3.3.2 の中では，その検索語と適合するのは，2 行目(会計係送る-請求書の行)であるが，条件節によるリンクによって，図 3.3.2 に表されている 4 行全てが検索
結果として出力される．
前述したジェネリックタスクを格文法で表現したものをジェネリックタスク格文法表現と呼ぶ．
本研究では，ライブラリ中の全てのジェネリックタスクをジェネリックタスク格文法表現によって
表す．
，
図 3.3.2 格文法構造の例
3.4 シソーラス
ジェネリックタスクを実際にドメインの中のタスクの一つとして利用する時，ジェネリックタス
クのインスタンスを生成することは前述した．その際に，ジェネリックタスクを構成している一般
的な名詞や動詞である GT term を，
その目的ドメインの中でローカルに使われている名詞や動詞に
置き換える．そのドメイン固有の単語は，シソーラスとしてライブラリに登録しておき利用する．
例えば，ジェネリックタスクの web 予約において，予約を行う人の GT term が”顧客”であると
する．この時，ホテルドメインに web 予約タスクを加える際には，その”顧客”という言葉を”ゲス
22
第3章
ダイアグラム再利用環境
ト”，”客人”，”招待客”，”訪客”，”来客”，”ビジタ”，”カスタマ”，”ユーザ”，”宿泊客”などの言葉に置
き換えることが予想される．この置き換えられる可能性のある言葉を，ドメインごとにシソーラス
としてドメインモデルに登録しておく．
また，逆の視点から考えると GT term とは，一つの事物を表すシソーラスの中の代表名である．
例えば，図 3.2.1 中の鉄道ドメインのシソーラスとホテルドメインのシソーラスはどちらも”会計を
担当する人”を表すシソーラスである．このどちらのシソーラスにとっても，”会計係”は代表名とし
て見ることが出来る．このような言葉を GT term として採用している．GT term で使われている
言葉も，シソーラスの一つとしてドメインの記述に用いることが出来る．
GT term (メタデータ)
会計係
計算係
会計係
出納係
窓口係
計算係
会計係
出納係
フロント係
鉄道ドメイン
ホテルドメイン
図 3.4.1 シソーラスの関係
3.5 ドメインモデル
ドメインモデルとは，あるドメインをそのドメインを構成するジェネリックタスクの集合として
表したものである．図 3.5.1 にドメインモデルの例を示す．
図 3.5.1 ドメインモデルの例
図 3.5.1 で，倉庫管理ドメインが持っているジェネリックタスクは，それぞれ 1 つ以上の動作を
含んでいる．その関係の様子を図 3.5.1 と入庫ジェネリックタスクのユースケースダイアグラムで
表すと，図 3.5.2 のようになる．
23
第3章
ダイアグラム再利用環境
図 3.5.2 ドメインモデルとジェネリックタスクの関係
ドメインモデルは，それぞれドメインごとに，そのドメインを構成しているジェネリックタスク
と，そのドメインの中でローカルに使われるシソーラスによって構成されている．
3.6 オントロジ
オントロジ[山宮 2004]とは，対象に存在する概念間の関係を表すもので，言葉とその意味や言葉
と言葉の関係で表すことができる．本研究のライブラリ上でも，一種のオントロジが形成されてい
る．格文法構造によって GT term 同士の動詞を中心とした語と語の関係が示され．シソーラスによ
って同義の言葉の関係が示され，GT term はシソーラスのメタデータとなる．ライブラリ上で構成
されている，ジェネリックタスクとシソーラスから成るオントロジを，図 3.6.1 に示す．
24
第3章
ダイアグラム再利用環境
図 3.6.1 オントロジ
項目 3.3 で述べたように，このオントロジは格文法で構成されているので，日本語という言語に
依存しない．例として，シソーラスを全て英語に入れ替えたオントロジを図 3.6.2 に示す．
図 3.6.2 シソーラス英語版
25
第3章
ダイアグラム再利用環境
現状では開発者は，システム全体の流れを把握しながら一貫性のあるダイアグラムを作成しよう
とする．様々な側面からシステムを分析するために，一つのダイアグラムで得られなかった面を別
のダイアグラムで把握しようとする．その際には，他のダイアグラムとの整合性を取るようにしな
ければならないため，一つのダイアグラムを変更するたびに既存のダイアグラムに手を加えなけれ
ばならない．
開発するシステムに似たシステムがすでに作られているかもしれない．この時には，以前に作成
したダイアグラムを見返し，そのシステムで使用できそうな部分を再利用する．
さらに，開発するシステムの規模により分析しなければならない量も比例して多くなる．そのた
めダイアグラム作成をする作業者も増やさなければならないし，多くのダイアグラムを作成するた
めには時間もかけなければならない．
3.7 ダイアグラムの再利用
ダイアグラムを再利用し，新たなドメインを生成する手順を示す．図 3.7.1 にその概観を示す．
図 3.7.1 ダイアグラム再利用の概観
以下，新規ドメイン作成の手順を示す．
(Step 1) ユーザがライブラリの中のドメインを検索
ユーザが得たいドメインモデルに近いドメインがライブラリにあるかを検索する．
検索ツールには，格文法での全ての格ごとに検索窓がある．主に動作に使われる単語を中心に
して，検索を行う．
26
第3章
ダイアグラム再利用環境
図 3.7.2 検索窓
(Step 2) ジェネリックタスクのリストの出力
(1)で検索した言葉に関連するドメインと，そのドメインに関連するジェネリックタスクのリス
トが出力される．
図 3.7.3 検索結果合成ツール
(Step 3) ユーザがリストから使いたいものを選択
ユーザが得たいドメインインスタンスに加えたいタスクを(2)で出力したリストから 1 つ以上
選択する．
(Step 4) シソーラスの出力
ユーザが選択したモデルに適用できるシソーラスが出力される．ユーザはその中から選択して
使うか，あるいは任意の名詞や動詞を用いることができる．
27
第3章
ダイアグラム再利用環境
図 3.7.4 シソーラスからの選択
(Step 5) シソーラスから使いたい言葉を選択
(Step 6) ドメインモデルのインスタンスを出力．
同時にライブラリにそのドメインモデルが新規ドメインモデルとして登録される．
ユーザが構築したドメインインスタンス(ユースケースダイアグラム)を出力する．このドメイン
インスタンスは，ユースケースダイアグラムに基づいたものであるが，実際は Prolog 形式のテキス
トファイルで出力される．Prolog 形式については，項目 4.2 にて後述する．
これが再利用の手順の概観であるが，再利用環境のライブラリを編集することも可能である．そ
の手順については第５章で説明する．
3.8 ライブラリの実際
ライブラリが実際にどのような構造になっているかを説明する．ライブラリには，各種ジェネリ
ックタスクの情報と，各種ドメインモデルの情報が個々に MS Excel ファイルとして保存されてい
る．普通のデータベースソフトを用いなかった理由は，Excel ファイルの方が，人間から見て直感
的に理解しやすいからである．
28
第3章
ダイアグラム再利用環境
図 3.8.1 ライブラリの内部
まず，ジェネリックタスクのデータから説明する．ジェネリックタスクのファイルは，図 3.8.2
のように，格文法に基づいて記述されている．
29
第3章
ダイアグラム再利用環境
図 3.8.2 ジェネリックタスクのファイル
また，一つのファイルに関連するジェネリックタスクが，複数保存されている．使われている言
葉は全て，GT term である．
次に，ドメインモデルのデータを説明する．ドメインモデルのデータは，図 3.8.3 や図 3.8.4 のよ
うに，そのドメインモデルで使われる GT term を基準に記述されている．ドメインモデルのデータ
は，大きく二つに分類され，一つはそのドメインが含んでいるジェネリックタスクのリスト(sheet
名 GT term-Domain=GTs)，もう一つはそのドメインでローカルに使われるシソーラス(sheet 名
GT term-Domain-Thesaurus)である．
30
第3章
ダイアグラム再利用環境
図 3.8.3 GT term-Domain-GTs
図 3.8.4 GT term-Domain-Thesaurus
31
第3章
ダイアグラム再利用環境
このように，複数の Excel ファイルから成り立つライブラリを再利用環境の検索ツールが検索す
るには，非常に時間がかかる．そこで，検索の前に，ライブラリのインデックスをとるファイルを
作成している．図 3.8.5 に示したのは，インデックスファイルの sheet1 で，行ごとに[ドメインモ
デル名]-[ジェネリックタスク名]-[GT term-シソーラス]となっている．これで，ドメインモデルと
ジェネリックタスクのファイルを連結して考えることが出来る．
図 3.8.5 インデックスファイルその１
さらに，ジェネリックタスクと，そのジェネリックタスクが含む動作を連結しているのが図 3.8.6
に示した sheet2 である．
32
第3章
ダイアグラム再利用環境
図 3.8.6 インデックスファイルその２
検索の前にこのインデックスファイルを作成することで，
最新の状態のライブラリのデータから，
迅速に検索をすることが出来る．
3.9 検索の手法
検索ツールにおける，AND 検索と OR 検索について説明する．検索は，図 3.9.1 に示した検索
窓に言葉を入力して行う．
図 3.9.1 検索窓
そのとき，AND 条件と OR 条件は，図 3.9.2 に示したようになる．検索窓右のラジオボタンで，
AND 検索をするか，OR 検索をするかを選択できる．これは，行ごとの AND/OR を示している．
例えば，ラジオボタン”And 検索”を選択している状態では，1 行目の動作を含み，且つ 2 行目の動
33
第3章
ダイアグラム再利用環境
作を含み，且つ 3 行目の動作を含んでいるジェネリックタスクを探し出し，そのジェネリックタス
クを含んでいるドメインモデルを検索結果として出力する．尚，元々の行の格同士は，全て AND
である．図 3.9.2 でいうと，”窓口”が”作成する””領収書”をで検索してくる．
また，図 3.9.2 の左下に示されている通り，格ごとの窓に(テキストボックス一つ一つに)スペース
や縦棒(“|”UNIX のコマンドなどで”パイプ”と呼ばれている記号)を使うことで，格ごとの AND 検
索や OR 検索が可能である．
図 3.9.2 AND 検索と OR 検索
以下で，AND 検索と OR 検索をどのように組み合わせているかを説明する．図 3.9.3 に示した，論
理回路の AND 記号と OR 記号を使って説明する．
なお，
簡単の為に格の数を 3 つに減らしてある．
図 3.9.3 AND 記号と OR 記号
[行ごとの AND 検索]
図 3.9.4 に示したように，ABC の行且つ，DEF の行を含むジェネリックタスクを検索する．
34
第3章
ダイアグラム再利用環境
図 3.9.4 行ごとの AND 検索
[行ごとの OR 検索]
図 3.9.5 にしめしたように，ABC の行または，DEF の行を含むジェネリックタスクを検索する．
図 3.9.5 行ごとの OR 検索
[テキストボックスごとの AND 検索]
図 3.9.6 に示したように，テキストボックスにスペースが入っている場合，その行を二つの行に
分けて考える．その分けた二つの行で，AND 検索を行う．
図 3.9.6 テキストボックスごとの AND 検索
[テキストボックスごとの OR 検索]
図 3.9.7 に示したように，テキストボックスに縦棒が入っている場合，その行を二つの行に分け
て考える．その分けた二つの行で，OR 検索を行う．
35
第3章
ダイアグラム再利用環境
図 3.9.7 テキストボックスごとの OR 検索
以上を踏まえて，
AND 検索と OR 検索が組み合わされた場合を考える．
図 3.9.8 は行ごとに AND
をとるが，2 行目には縦棒が入っている．
図 3.9.8 AND と OR の組み合わせ
これはまず，2 行目を 2 つに分解して，OR をとる．そして，その結果と 1 行目とで AND をと
る．このようにして，AND 検索と OR 検索を実行している．
36
第3章
ダイアグラム再利用環境
第 4 章 他ツールとの連携
本章では，本研究の再利用環境と，他ツールとの連携を述べる．また，他ツールの使い方も，い
くつか解説する．本再利用環境がサポートするのは，ユースケースダイアグラムのみである．しか
し，他のダイアグラム変換ツールなどと組み合わせて使う事で，他の種類のダイアグラムに変換す
る事が出来る．他の種類のダイアグラムに変換すると，ユースケースダイアグラムとは別の観点か
らシステムの構造を知る事ができる．
4.1 他のツールとの関係
他ツールとの関係を，図 4.1.1 に示す．
図 4.1.1 他ツールとの関係
図 4.1.1 中の用語の説明
UCD: ユースケースダイアグラムの略．協調業務向けのユースケースダイアグラムを指す．
PN: ペトリネットの略．規律性のあるペトリネットを指す．
MCM: 先述した，Multi-Context Map の事である．
CLM: 先述した，Collaborative Linkage Map の事である．
STD: State Transition Diagram の略．状態遷移図の事である．
DFD: Data Flow Diagram の略．データフロー図の事である．
IDEF0: Integration Definition Language の事である．
37
第4章
他ツールとの連携
UCT: Use Case Text の略．ユースケース記述の事である．
“～-Prolog”: ～が示すダイアグラムの，Prolog 形式のテキストファイルの事である．ダイア
グラムそのもの(Visio 上の記述) ではないが，ダイアグラムと同等の情報量を持つ．
図 4.1.2 は，図 4.1.1 中 Diagram Reuse Environment，つまり本再利用環境の出力の様子を示し
たものである．出力は，ユースケースダイアグラムを Prolog 形式のテキストファイルで出力する．
図 4.1.2 本再利用環境の出力
図 4.1.3 は，図 4.1.1 の，UCDE(Use Case Diagram Editor)の入出力の様子を表したものである．
Visio 上のユースケースダイアグラムと，Prolog 形式のユースケースダイアグラム，Prolog 形式の
規律性のあるペトリネットを入出力する事が出来る[笠原 2004] ．
UCD
UCD-Prolog
PN-Prolog
UCD Navigator
Convert UCD to PN
UCD
UCD-Prolog
PN-Prolog
図 4.1.3 ユースケースダイアグラムエディタ
図 4.1.4 は，ユースケースダイアグラムを MCM の Prolog 形式に，あるいは CLM の Prolog 形
式に変換するツールである．それぞれを MCM Extractor，CLM Extractor と呼ぶ [大曽根 2004] ．
38
第4章
他ツールとの連携
図 4.1.4 MCM/CLM Extractor
図 4.1.5 は分散型開発環境におけるシステム分析ツール，CiCCS である．規律性のあるペトリネ
ットを入力として，各種ダイアグラム変換ツールを用いて，STD (State Transition Diagram)，DFD
(Data Flow Diagram)，IDEF0 (Integrated DEFinition methods 0)，UCT (Use Case Text)などの
ダイアグラムを作成できる．その様々な変換を，operarion tool が管理している [石川 2005]．
PN-Prolog
Operation Tool
STD,
DFD,
IDEF0,
UCT
Chart Convert Tools
図 4.1.5 CiCCS
図 4.1.3 のユースケースダイアグラムエディタと，図 4.1.4 の MCM/CLM Extractor は，元々別
のツールである．しかし，どちらのツールも M/I(マテリアル&インフォメーション)に着目したユー
スケースダイアグラムをベースにした分析を行うので，本研究の為に一つのツールに統合した．ま
た，CiCCS に含まれるダイアグラム変換ツールの一部も，その統合ツールに追加した．その統合し
たツールの様子を図 4.1.6 に示す．
統合ツールは以下の機能を持つ (図 4.1.6 に表示されている順番に説明．”Prolog 形式の～”とは，
その～というダイアグラムが，Prolog 形式のテキストファイルである状態である．逆に”Prolog 形
式の～”と説明のないダイアグラムは，Visio 上に描画されている状態である．Prolog 形式について
は，次の項目で後述する．)
[CLM extractor] M&I 準拠のユースケースダイアグラムを，Prolog 形式の CLM に変換
[MCM extractor] M&I 準拠のユースケースダイアグラムを Prolog 形式の MCM に変換
[petrinet convert] M&I 準拠のユースケースダイアグラムを規律性のあるペトリネットに変換
[petrinet input] Prolog 形式の規律性のあるペトリネットを読み込んで，規律性のあるペトリネ
ットを描画
[petrinet output] 規律性のあるペトリネットを Prolog 形式の規律性のあるペトリネットに変換
39
第4章
他ツールとの連携
[PN extractor] ユースケースダイアグラムを規律性のあるペトリネットに変換
[UCT extractor] 規律性のあるペトリネットをユースケーステキストに変換
[use case input] Prolog 形式の M&I 準拠のユースケースダイアグラムを読み込んで，M&I 準拠
のユースケースダイアグラムを記述
[use case navigator] 新たに M&I 準拠のユースケースダイアグラムを作成する際のナビゲータ
ー
[use case output] M&I 準拠のユースケースダイアグラムを Prolog 形式の M&I 準拠のユースケ
ースダイアグラムに変換
図 4.1.6 統合ツール
また，図 4.1.7 は，Visio 上に描かれたダイアグラムを，他の形式のダイアグラムに変換できるツ
ールである．上記ツールと違い，あるダイアグラムから，別の種類のダイアグラムに変換する変換
ルールを作成すれば，いかなる種類のダイアグラムにも対応できるのが特徴である[益田 2005]．
Diagram A
Convert Tool
Diagram B
Convert rule Of A to B
図 4.1.7 ダイアグラム変換ツール
40
第4章
他ツールとの連携
4.2 Prolog 形式
Prolog 形式とは，論理型プログラミング言語である Prolog に基づいた，形式である． ダイアグ
ラムの情報を Prolog 形式でテキストファイルに書くようにして採用している．つまり，実際の
Prolog 形式の出力は，拡張子が”.txt”となる．Prolog 形式のテキストファイルが持っているダイア
グラムの情報は，Prolog 形式の出力元のダイアグラムと等価である．
Prolog 形式のテキストファイルを用いる理由を説明する．先述したダイアグラム作成ツールやダ
イアグラム変換ツールは，全て MS Visio の VBA か MS Excel の VBA で作成されている．VBA
(Visual Basic for Application)の特徴の一つとして，そのアプリケーション(Visio や Excel)のファイ
ルに付随して，保存されている．VBA 単体では保存はできず，かつ VBA 単体では，動作すること
が出来ない．以下に VBA において困ると思われる点を挙げる．
例 1 VBA が装備されたファイル X があったとする．そこにダイアグラム A を書き，ダイアグ
ラム A という名称で保存する．また，ファイル X のコピーや，ダイアグラム A のファイルにダイ
アグラム B を上書きし，ダイアグラム B という名称で保存する．この操作で，ダイアグラム A と
いうファイルと，ダイアグラム B というファイルが作成されたが，両ファイルとも全く同じ VBA
のデータを持っている．これでは，同じデータが重複し，コンピュータのデータ容量の無駄使いに
なる．
例 2 例 1 の状態で，VBA のバージョンアップがあったとする．すると，ダイアグラム A のフ
ァイルとダイアグラムBのファイルで，
両方ともVBAの書き換えや更新を行わなくてはならない．
例 3 チャートを作成する VBA を搭載したファイル Y と，チャートを変換する VBA を搭載し
たファイル Z があったとする．まずファイル Y でダイアグラムを作成する．そのダイアグラムをフ
ァイル Z に移行するには，ダイアグラムを全てコピーしてペーストする手間がかかる．さらに，も
しファイル Z に，ダイアグラムがドロップ(ペーストしたときもドロップされたと判断される)され
たときに動作するVBAが含まれていた場合，
まずそのドロップしたときに動作するVBAの動きを，
止める必要がある．
以上のような事が考えられるので，上記のツールのほとんどで，Prolog 形式のテキストファイル
でダイアグラムを管理する手段をとっている．
41
第4章
他ツールとの連携
第５章 再利用環境の使用法と例題
本章では１つのシステムに関して，本研究で実装したダイアグラム変換ツールを使用し，実際に
ダイアグラムを作成した結果を述べる．本再利用環境のツールの使い方，本再利用環境がどのよう
に再利用を実現しているか，についても述べる．
5.1 検索ツール
(Step i)では，本再利用環境のユーザが行う動作を列挙する．並列する(Act i.j)で，本再利用環境
が行う作業を示す．
例: 書籍予約販売ドメインの作成
(Step 1) 検索ツールによって検索を行う．再利用環境のツールを搭載した MS Visio ファイルを開
き，図 5.1.2 のように，メニューから”SearchTool”を選択し，検索ツールを起動する．
図 5.1.1 検索ツールの起動
すると，図 5.1.2 のような検索窓が現れる．
42
第5章
システムの例題
図 5.1.2 検索窓
まず書籍を予約するようなタスクを検索する．検索窓に図 5.1.3 のように入力して，検索を開始
する．
図 5.13 検索窓への入力
(Act 1.1) 再利用環境内部の動きを記す．検索が始まると，まず入力された単語と，それに合致する
シソーラスを検索する．
これで，
入力された言葉を総て，
ライブラリ内部の GT term と関連づける．
(Act 1.2) 入力された格の組み合わせを含んでいるようなジェネリックタスクを検索する．
(Act 1.3) 格の組み合わせに合致するようなジェネリックタスクが存在する場合，そのジェネリック
タスクを含むドメインモデルを検索する．
(Act 1.4) 該当するドメインモデルを出力する．出力画面は図 5.1.4 のようになる．
43
第5章
システムの例題
図 5.1.4 検索結果の出力
図5.1.4の左上のリストボックスには，
検索したタスクを含むようなドメインが列挙されている．
このリストボックスからドメインを一つ選択すると，その左のリストボックスに，そのドメインを
構成しているジェネリックタスクが列挙される．さらに，そのジェネリックタスクを表示している
リストボックスから，ジェネリックタスクを一つ選択すると，その右に選択されたジェネリックタ
スクのユースケースダイアグラムのプレビューを見ることができる．
(Step 2) 検索結果を利用して，目的のドメインに追加したいジェネリックタスクを選ぶ．図 5.1.4
のジェネリックタスクのリストボックスから．ジェネリックタスクを選択して，”新規 DM に追加”
ボタンを押すと，一番右のリストボックスに，そのジェネリックタスクが追加される．この下の，
色のついたリストボックスにあるジェネリックタスクが，目的のドメインを構成していく
(Step 1 ぞの 2) 図 5.1.4 の左側にある”さらにドメインを検索”ボタンを押すと，図 5.1.2 の検索窓が
現れ，さらに追加して検索することが出来る．検索窓に図 5.1.5 のように入力して，検索結果を追
加すると，図 5.1.6 のような検索結果を得られる．
44
第5章
システムの例題
図 5.1.4 追加の検索
図 5.1.6 追加の検索を行った検索結果
(Step 2 その 2) 図 5.1.6 の下のリストボックスのように，作成したいドメインが含むジェネリック
タスクを列挙する．列挙し終わったら，図 5.1.6 右の”ドメインモデル作成”ボタンを押すと，シソー
ラスの決定画面が現れる．シソーラス選択画面を図 5.1.7 に示す．
45
第5章
システムの例題
図 5.1.7 シソーラス選択画面
もし，使いたい言葉が一覧にない場合，図 5.1.7 右側の”add thesaurus”ボタンを押すと，図 5.1.8
のような入力画面が出て，任意の言葉を入力できる．
図 5.1.8 新規シソーラスの追加
図 5.1.7 のようなシソーラス選択画面は，図 5.1.6 で選んだジェネリックタスクが含んでいる GT
term すべてに対して質問する．全てのシソーラスを決めると，ユースケースダイアグラム(Prolog
形式)の出力場所を図 5.1.9 のように質問する．任意のディレクトリを選択して保存する．このとき
入力したファイル名が，新規ドメインの名称となる．
46
第5章
システムの例題
図 5.1.9 ファイルの保存先選択画面
これで，新規ドメインの作成が行われた．出力された Prolog 形式のユースケースダイアグラムを，
項目 4.1 で示した統合ツールを使って見ることが出来る．また，ドメイン名を正確に入力する為に，
再度図 5.1.10 のような入力フォームが現れる．
図 5.1.10 ドメイン名入力フォーム
フォームに図 5.1.11 のように入力し，OK を押す．
図 5.1.11 ドメイン名の入力
すると，図 5.1.12 のようなファイルがライブラリに追加される．これで，新規ドメインモデルの
ライブラリへの自動登録が完了した．
47
第5章
システムの例題
図 5.1.12 ライブラリへの新規ドメインモデルの追加
5.2 編集ツール
ライブラリを編集するツールについて説明する．5.1 で説明した検索ツールを用いて出力したユ
ースケースダイアグラムは，MS Visio 上で描かれるダイアグラムであるので，出力後にユーザの手
によって細かい編集が可能である．しかし，出力元のライブラリのデータが，過度に使用不可能な
ものであっては，この再利用環境が使われることはなくなってしまう．そこで，ライブラリを編集
する必要が出てくる．
ライブラリ内のドメインモデルを修正する場合は，上記の検索ツールを使い，修正後のドメイン
モデルを出力すればよい．ここでは，ジェネリックタスクの編集操作について述べる．
まず，ライブラリに保存されているジェネリックタスクのデータを呼び出す．図 5.2.1 のように，
再利用環境のメニューから”generic_task_load”を選択し，ジェネリックタスクの読み込みを行う．
図 5.2.1 ジェネリックタスクの読み込み開始
ずると，図 5.2.2 のような選択画面が現れる．
48
第5章
システムの例題
図 5.2.2 ジェネリックタスク選択画面
編集したいジェネリックタスクを選択すると，図 5.2.3 のように Visio 画面上に，選択したジェネリ
ックタスクのユースケースダイアグラムが現れる．
図 5.2.3 ジェネリックタスクの表示
表示されたジェネリックタスクを，必要に応じて編集する．編集後，図 5.2.4 のように，再利用
環境のメニューから，”generic_task_save”を選択すると，編集したジェネリックタスクは，ライブ
ラリの中に保存される．
49
第5章
システムの例題
図 5.2.4 ジェネリックタスクの保存
50
第5章
システムの例題
第６章 おわりに
6.1 結論
本研究では，システム分析を容易にする為に，ダイアグラムを再利用できる環境を構築した．本
再利用環境は，項目 2.5 で図示したダイアグラムの再利用の手順の全てのステップをサポートする．
図 6.1.1 再利用環境の効能
特に，最初のステップである”ダイアグラムを探す”ことは，普通は困難である．自分が欲しいダ
イアグラムの場所がわからなかったり，参考に出来るダイアグラムが存在するかがわからなかった
りするからである．そのような散在する有力な情報を，一元に管理することで，有力な再利用環境
が生まれた．本研究の最大の功績は，その一元に管理できる構造を提供した事にある．
また，他研究と比較をすると，ダイアグラムの再利用には，ダイアグラム中のパターンを見つけ，
それをライブラリ化し再利用するものがある．デザインパターン[E. Gamma 1995]は，頻出するクラ
スダイアグラムのパターンを再利用する．開発者は，パターンを熟知し，開発対象に適切なものを
探し，対象ドメインに適用する．
[O. López 2002]では，メタモデルとユースケースダイアグラム，データフローダイアグラム，ク
ラスダイアグラム，ER ダイアグラムなどのダイアグラムとの関係を整理し，ドメインの目的と関
連づけて蓄積する．開発者は，開発対象に適用可能なダイアグラムをドメインの目的から探し出し
利用する．本稿では，ドメインに関わらず共通に行われているジェネリックタスクを捉え，登場す
る人，もの，情報とその流れについての記述を再利用する．本稿の手法では，開発者は，対象につ
いて，名詞や動詞を用いて，ダイアグラムに必要な情報を検索，利用する．ジェネリックタスクの
概念とシソーラスにより，ドメインを意識せずに必要なジェネリックタスクに関するダイアグラム
の情報を利用できる
6.2 今後の課題
51
第6章
結論
本再利用環境では，ユースケースダイアグラムをベースとしたシステムである．項目 4.1 で述べ
たように，それ以外の種類のダイアグラムには，再利用環境から出力した後に変換が可能である．
しかし，将来的には他の種類のダイアグラムをベースとした再利用環境が望まれる．特に，MCM，
CLM ベースの再利用環境が有力であると考えられる．
また，別の課題として，本再利用環境のライブラリを充実させることが挙げられる．項目 3.1 で
述べたように，誰にでもライブラリの中身を編集・追加できるようにした．より多くのダイアグラ
ムの情報が集まれば，さらに利用価値のある再利用環境となる．
52
第6章
結論
参考文献
[河村 1999] 河村一樹：情報システムの設計・開発技術，近代科学社，1999．
[大曽根 2004] 大曽根淳雄, 伊藤潔, 川端亮：協調作業分析のための統合ツールの研究，上智大学
修士論文，2004．
[J. Peterson] James L. Peterson：ペトリネット入門，共立出版，1984．
[伊藤 2001] 伊藤潔 他著：ソフトウェア工学演習 IT Text，オーム社出版，2001．
[瀬沼 2002] 瀬沼裕志, 伊藤潔, 川端亮：システム分析の進展に伴うモデル図の利用法，上智大学
修士論文，2002．
[長谷川 2002] 長谷川明子, 伊藤潔, 川端亮：協調エンジニアリングのためのフレームワークに関
する研究，上智大学博士論文，2002．
[wikipedia] ウィキペディア，http://en.wikipedia.org/wiki/Main_Page．
[川端 1998] 川端亮，長谷川明子，熊谷敏，伊藤潔：共通業務のドメイン分析に基づくプロトタイ
ピングシステム，ソフトウェア工学基礎論文集，Vol.5, pp.126-133，1998．
[CLAES 1997] CLAES Generic tasks，http://www.claes.sci.eg/claes/gt_tool.htm．
[J. Cornelis 2002] J. Cornelis, R. Deklerck, B. Truyen, P. Schelkens：Human Body Imaging:
generic tasks in medical image processing illustrating the application of computer science
and digital signal processing techniques，2002．
[Fillmore 1988] Charles J. Fillmore：格文法の原理―言語の意味と構造, 三省堂，1988
[山宮 2004] 山宮健寛, 伊藤潔, 川端亮：オントロジを導入したウェブの構成法と検索法の研究,
上智大学修士論文, 2004．
[笠原 2004] 笠原利春, 伊藤潔, 川端亮：ユースケース図を利用した協調システム分析法，上智大
学学士論文，2004．
[石川 2005] 石川雄樹, 伊藤潔, 川端亮：分散型開発環境におけるシステム分析ツールの研究，上
智大学修士論文，2005．
[益田 2005] 益田健司, 伊藤潔, 川端亮：チャート間の関係に関する知識を導入したチャートエデ
ィタの設計，上智大学修士論文，2005．
[E. Gamma 1995] E. Gamma et al., ：Design Patterns - Elements of Reusable Object-Oriented
Software，Addison-Wesley Reading MA 1995, 1995．
[O. López 2002] Oscar López, Miguel A. Laguna, Francisco José García Peñalvo：Metamodeling
for Requirements Reuse, Anais do WER02 - Workshop em Engenharia de Requisitos, Valencia,
Espanha. ISBN 84-96023-01-X, pp.76-90，Nov 2002．
53
第6章
結論