このブログは、旧・はてなダイアリー「檜山正幸のキマイラ飼育記 メモ編」(http://d.hatena.ne.jp/m-hiyama-memo/)のデータを移行・保存したものであり、今後(2019年1月以降)更新の予定はありません。

今後の更新は、新しいブログ http://m-hiyama-memo.hatenablog.com/ で行います。

ハイパートランジション? トータルマトリックス、行列計算

クライアント側の状態遷移も「リンク」と呼ぶと誤解が生じる。まー、そりゃそうだ。普通、状態遷移はリンクとは言わないからね。

ハイパーリンクのトラバース(たどり)によって、その結果としてトランジションが生じるのだから、ハイパートランジション。と、そう言えば誤解はないだろう。が、またしても用語が増える。ムーー。

ハイパーリンク」と「ハイパーメディア」って言葉はそのまま残したい。「リソース」の意義はどんどん下がってきているのだが、現状では、リソースクラスが、リソースインスタンスとアクションの編成(グルーピング)の道具。リソースインスタンス(ソースIDで識別される)は、アクションエントリーポイントをまとめる役割り。あと、いくつかのエントリーポイントに共通のデータを供給する役割りかな。

最近、リソースマトリックスという概念を考えて、これさえあれば何でも説明できると思っている。縦と横はどうでもいいのだが、今は横方向にリソースIDを並べて、縦方向にアクションを並べた方陣にしている。セルの値(行列成分)はエントリーポイント。エントリーポイントは一種の参照用ID値となる。

1つのリソースクラスから1枚(「枚」なのか?)のマトリックスができるので、アプリケーション全体としては複数のマトリックスを持つ。マトリックスの横軸のリソースインスタンスが重複することはない(互いに排他的)。よって、すべてのマトリックスの横軸=リソースインスタンスセットを直和で並べることができる。直和で寄せ集めた全体のリソースセット(トータルセット)が、そのアプリケーションが持つリソースの全体。

マトリックスの縦軸がアクションだが、アクションも修飾名(QName、モジュール修飾+クラス修飾)を使えば、マトリックス間の重複はない(だって、クラスが違うんだから)。よって、縦軸も直和で並べることができる。

すべてのマトリックスを、縦も横も直和で集めてデカイマトリックスを作れる。このデカイマトリックスの成分には未定義(⊥)も入れる。なんつーか、対角ブロックがあって、その対角ブロック以外は未定義。対角ブロック以外に有効値が出現するのは「なにかおかしい」。

アプリケーション全体のリソースセットとアクションセットを横軸/縦軸に配置して、成分を未定義も含めて埋めたマトリックスを、アプリケーションのトータルマトリックスと呼ぶことにする。トータルマトリックスを見れば(解析すれば)、アプリケーションの挙動はほぼ完全にわかるはず。

アプリケーションのトータルマトリックスを単にアプリケーションマトリックスと呼んでもいいかも。

アプリケーションマトリックスは、リソースマトリックス達を対角ブロックに並べたもの。そうなってないなら「なんかおかしい」と。行×列 と表記するなら、「アクション×インスタンス」の行列だ。アクション行の行数は有限。インスタンス列の列数も有限が望ましい。

マトリックスに対応するグラフは二部グラフなので、もとの行列と転置行列の積をとれる。これを往復行列(round-trip matrix)と呼ぶことにする。二種の往復行列が作れるが、どちらも正方行列になる。正方行列なのでクリーネ閉包が作れる。

あー、半環のε指標が使えそうだ。

  1. ε(0) = 0
  2. ε(x) = 1 if x≠0

なんかやっと、Webシステムの解析にグラフ理論と行列計算を適用する準備ができたような。ヨーシ、…。