gists

Kolfschoten et al. (2006) 読解メモ

論文: A conceptual foundation of the thinkLet concept for Collaboration Engineering
出典: Int. J. Human-Computer Studies 64 (2006) 611–621


この論文が扱っていること

thinkLetの概念モデルの再定義。旧来の定義(Tool・Configuration・Script)を、オブジェクト指向モデリングの手法でより本質的な要素に分解し直した。thinkLetの「つくりかた」の手順そのものは扱っていない。ただし、新しいthinkLetを記述する際の「何を定義すべきか」という構造の枠組みは得られる。


thinkLetの構成要素

旧モデル(Briggs et al., 2001)

問題点:技術や文言に縛られ、少しでも変えると「別のthinkLet」になる。実務では同じthinkLetを異なる技術で実行したり、台本から逸脱してもパターンが変わらないケースが頻発していた。分類・比較も困難だった。

新モデル(本論文の提案)

旧モデルの3要素を解体し、5要素に再構成した。

プロセス全体の構造に関わる補助概念として以下がある。

新旧の本質的な違い

旧モデルが「何を使って何と言うか」という実装レベルの記述だったのに対し、新モデルは「何ができる状態で、どんな制約のもとで、何をするか」という本質レベルの記述になった。台本(Script)は新モデルでは構成要素ではなく、Rule・Action・Parameterを具体的な言葉に落とし込んだ「実装(インスタンス化)」として位置づけられる。


successor/predecessor の密結合問題

クラス図上、thinkLetクラスに successorpredecessor という属性があり、thinkLet同士が直接参照し合う構造になっている。

ただし論文のTable 4の記述では「ここでは独立したthinkLetとして記述しており、データセットや前後のthinkLetとは接続していない」と明記されている。設計意図としては、プロセスに組み込まれたときに初めて前後関係が設定されるものであり、thinkLet自体が特定の後続を「知っている」わけではない。

しかしモデリングとしてはthinkLetクラス自身の属性にしている以上、密結合に見えるのは妥当な指摘。CollaborationProcess側で順序を管理する設計にすれば、thinkLetは完全に独立した部品になる。論文ではこの点は議論されておらず、モデリングの精度より概念整理を優先した結果と思われる。


thinkLetの「つくりかた」について

本論文はthinkLetの構造を定義したが、新しいthinkLetをどう作り、検証し、ライブラリに登録するかという手順は扱っていない。参考文献の中で最も有望なのは以下。

ただし、論文自身がthinkLetの作成・検証・ライブラリ登録の手順は未整備であることを示唆しており、体系的な方法論は別の研究に委ねられている。