Last updated:
Aug 26 20:37:49 2003
[MJ Top page]
[Site map]
このページは、プログラミング言語 MixJuice や差分ベースモジュールの 関連研究メモです。 アスペクト指向言語や separation of concerns 、モジュール機構に関連した 研究のうち重要そうなものをとりあえずリストアップしています。
なお、すべての研究について、詳細に調査したわけではありません。 間違いがあった場合は御容赦を。
プログラムの保守性・再利用性を高めるためには、 できるだけ関連の深いコードを近い場所に集めて、他とは分離して記述すべきです。 これを separation of concerns （関心事の分離）と言います。
オブジェクト指向言語はデータ構造とそれに深く関連する手続きを１箇所で記述する 構文を提供するため、手続き型言語よりも separation of concerns が「うまくできる場合が多く」、そのために広く普及してます。
しかし、一般には複数のクラスを横断する形で関連するコードを記述せざるを得ない 場合もあります。つまり、現在のオブジェクト指向言語では、 separation of concerns が「できない場合もある」のです。
この問題の解決のために最近注目されているのがアスペクト指向言語です。 （アスペクト指向に関して詳しくは、次の URL を参照下さい。 http://aosd.net）
ある「側面(aspect)」に関連するコードは、一般に複数のクラスを横断して存在する。 それをひとまとめにして再利用の単位とすべし、という話。 aspect は concern とだいたい同じ意味と思ってよさそう。
日本人による解説（最近は検索するともっとたくさん見つかります。）
最近期待の国内ページ
OOPSLA'92 の論文のころから、 "Subject-oriented programming" として separation of concerns 的な機能の 必要性をうったえている。 最近は Multi-dimentional separation of concerns (MDSOC)に進化した。 Hyper/J という Java 用ツールが alphaworks から公開された。
Hyper/J は言語ではなく、バイトコード編集を用いたツールである。 普通の Javac でコンパイルしたバイトコードから、 「ある観点」で hyper slice を抜きだし、 それを他のアプリケーションに追加することができる。 この hyper slice が concern に相当。 他のシステムと大きく違うのは、プログラマーがあらかじめ concern を分離して記述するのではなく、 普通に記述されたアプリケーションのバイトコードから、 concern を抜き出して再利用できる点。
解決方法はともかくとして、 Harold Osshe の問題意識にはすごく共感できます。
[ Karl J. Lieberherr ]
Karl J. Lieberherr は Law of Demeter で有名なソフトウエア工学の人。
DemeterJ というツールがある。それをさらに簡略化した DJ というツールもある。
XML 処理プログラムなどの、グラフ構造を traverse するプログラムは、 オブジェクト指向的にはきれいに書けない。 これらのツールはこの問題を解決するもので、 traverse するコードを再利用可能にする。
Mira Mezini and Karl J. Lieberherr:
"Adaptive Plug-and-Play Components for Evolutionary Software Development"
In Proc. of OOPSLA'98.
adaptive programming の一種。
特定のクラス階層の構造に依存しない形で、そのクラス階層に機能を追加できる。
メカニズムとしては、リニアライズをやらない mixin 。
機能の追加先を指定するのがめんどうそう。
Mira Mezini and Linda Seiter and Karl Lieberherr:
"Component Integration with Pluggable Composite Adapters",
In Mehmet Aksit ed.,
Software Architectures and Component Technology: The State of
the Art in Research and Practice, 2000.
AP&PC の改良版。
接続は容易、「差分」の動的ロードが可能。
type lifting というテクニックにより、動的ロード時の型システムの問題を解決。
Mira Mezini and Klaus Ostermann: "Integrating Independent Components with On-Demand Remodularization" To appear in OOPSLA 2002.
Klaus Ostermann:
"Dynamically Composable Collaborations with Delegation Layers",
In Proc. of ECOOP 2002.
Mixin layers と
delegation (prototype-based OOP) との融合。
delegation layer は動的にロードして、既存のクラス階層に
あとづけすることができる。
型システムの問題は PCA の type lifting と同じようなもので解決。
Mehmet Aksit, Univ. of Twente
まだ詳細には調査してない。 クラス定義にあとから filter を付けることで、処理を拡張できる。 複数の filter を compose することができる。 個々の filter が aspect であり、 concern である。 Java ベースの言語が説明に出て来るが、実装はされているのだろうか？
Mixin Layers の Java 版。 プログラムに対して新たな機能を実現する「レイヤー」を 追加していくことにより、段階的にアプリケーションを発展させて行く。 （このプログラミングスタイルは、 MJ と全く同じ。）
JL (Java Layers) は、 Mixin Layers と同様に、 parameterized class と nested class の 機構を使って「差分の追加」を実現する言語。 しかし純粋にそれだけでは問題があるため、 型システムにいくつか拡張がなされている。 （言語としては、かなりださい。）
http://www.cs.utexas.edu/users/richcar/JavaLayers.html
Michael VanHilst:
"Using Role Components to Implement Collaboration-Based Designs",
OOPSLA'96.
UML で言う role を再利用の単位とすべし、という話。 この role は、実質 mixin 。 role を横につなげたものが UML で言う collaboration で、これは Mixin Layers （MJ のモジュール）に相当する。 mixin を使うことにより、ヤコブソンの OOSE の本にある リサイクルマシンの例が、きれいにモジュール分けできる。 再利用の単位としては粒度が細かすぎて、部品をつなげるのが大変。 この問題は Mixin Layers では解決されている。
未読。１つのオブジェクトは、他の複数のオブジェクトと相互作用するが、 相手によって異なる側面を見せる。この「側面」が role 。 role を使った modeling のための記法を定義している。
role の特徴として、 visibility, dependency, identity, dynamicity, multiplicity, abstractivity の６つを定義している。 （MJ の module は role の集合と解釈できる。 MJ の role は、 dynamicity 以外の全ての要件を満たしている。）
AspectJ を使って、 role model による設計・実装をする、という論文もある。
by Krzysztof Czarnecki and Ulrich W. Eisenecker
http://www.generative-programming.org/
本が出ている。未読。
プログラムを自動生成するツールを使えば、再利用性が上がる、という話？
international programming, template meta-programming などの話も
含まれている。
これらの言語は category という、クラスとは別の「分類手段」を
持っている。（これも crosscutting concerns か？）
Objective-C は、あとから category を追加できる。
最新の
VisualWorks では、さらに、クラスおよび category と直交した（？）
名前空間機能と構成管理機能を持っているらしい。
[ Microsoft, Charles Simonyi ]
separation of concerns をマクロで実現、というかんじか？
構造エディタによるプログラミングを前提とする。
抽象構文木に対する変換を行う。
domain-specific な機能を追加することができる。
（Charles Simonyi はハンガリアン記法の提唱者。）
[ John Plaice ]
MS の intentional programming とは全く無関係。
バージョンごとの挙動の違いを１つのプログラムの中で表現する。
（#ifdef みたいなものだが、実行時にバージョンが切替えられるみたい。）
Keller, R. and U.Holzle,
"Binary Component Adaptation",
in Proc. of ECOOP'98, LNCS 1445, pp.307--329, 1998.
BCAは、
ソースのない既存の Java クラスライブラリに、
差分を追加できるようにするシステム。
実装されているが、独自の JavaVM が必要。
（システムクラスに差分を追加できるようにするためだろうか？）
SPARC/Solaris 用の JavaVM が配布されている。
「差分」の型チェックは、 future work になっている。
Moby
ECOOP2000
PLDI'99
（未調査）
普通のオブジェクト指向言語は、 class に module の役割を負わせているため、
class の機能が複雑化している。
そこで、 class とは別に module を導入。
ML style の module メカニズムを OOP に入れたもの。
JML
Clyde Ruby and Gary T.Leavens:
"Safely Creating Correct Subclasses without Seeing Superclass Code",
OOPSLA2000 .
mixin, separation of concerns とは関係ない。
「superclass のソースコードを見なくても安全に subclass を定義する方法」に
ついての論文。
いわゆるクラスの事前条件・事後条件の他に、
subclassing contract という情報を加えることで、
はじめて subclass を安全に定義することが可能になる。
subclassing contract は、 superclass のコードがアクセスする、
自分自身の field/method 名の情報。
soundness についても証明の概略が載っている。
superclass の field/method は動作を拡張するための hook であると考えれば、 それが subclass に対する外部仕様に含まれているのは当然である。 しかしこの論文では hook という観点では subclassing contract を見ていない。
また、 mixin についての考察はまったくない。 subclass から見て superclass は固定であるため、 mixin があるシステムと比べて、この論文の方法では、 subclass ができることの自由度が高い。
In proc. of ECOOP'97
mixin に近いが、少し違うらしい。関連研究が少ない。
Software Composition Group at University of Berne
動的な名前空間を持つものらしい。
Application = Components + Scripts
NTT 原田さんの
作った言語の１つ。
挿入構文というものを用いて、差分プログラミングができる。
情報処理学会論文誌プログラミング Vol.42 No.SIG 2(PRO 9)
Yasunori Harada, Kenichi Yamazaki, Richard Potter:
"CCC: User Defined Object Structures in C"
in Proc. of ECOOP2001.
[ Gilad Bracha ]
Gilad Bracha は JLS2
の著者の一人。
GJ
の設計にも関わっている。
Gilad Bracha and William Cook: "Mixin-based Inheritance", In Proc. of OOPSLA90.
mixin は再利用性を高める、という話。 mixin があれば BETA, C++, CLOS の
継承機構をすべてエミュレートできる。
Gilad Bracha and Gary Lindstrom:
"Modularity Meets Inheritance", In Proceedings of
the IEEE International Conference on Computer Languages, April 1992.
Gilad Bracha: "The Programming Language Jigsaw: Mixins, Modularity and Multiple Inheritance" .PhD thesis, University of Utah, 1992.
Jigsaw は
クラス継承の機能から subtyping と実装継承を分離した言語らしい。
プリミティブすぎて実用的なものではないらしい。
[ Matthew Flatt ]
Matthew Flatt は DrSchemeのスタッフの１人。
Matthew Flatt : "Class and Mixins", In POPL'98.
Java に mixin の機能を入れた言語 MixedJava の型システムの話。
言語としては普通。
Flatt and Felleisen:
"Units: Cool Modules for HOT Languages", In Proc. of PLDI 98.
Units は分割コンパイル、再利用、循環依存、階層構造、動的ロードをサポートする
モジュール機構。
再利用性が高いのはいいが、モジュールを１つ１つつなぐのが面倒そう。
McDirmid, Flatt, and Hsieh:
"Jiazzi: New-Age Components for Old-Fashioned Java",
In Proc. of OOPSLA 2001.
Units の機能を入れた Java 上のモジュール機構。
[ Davide Ancona ]
[ Elena Zucca ]
"A Theory of Mixin Modules: Basic and Derived Operators",
Mathematical Structures in Computer Science, Vol.8, number 4, pages 401-446, August 1998.
未読。 OOPSLA 2001 の mixin module とは別物か。
"Jam - A Smooth Extension of Java with Mixins", In proc. of ECOOP'00.
型チェックできる Java 上の mixin 。 static field, static method の機能を
生かそうとしているが、そのかわり mixin 型の扱いにちょっと制限が入る。
Java のプリプロセッサとして実装。
"True Modules for Java-Like Languages "
ECOOP'01 - European Conference on Object-Oriented Programming, Lecture Notes in Computer Science 2072.
JavaMod という言語とその型システム。
BETA 言語の fragment system と virtual class という機能は、 それぞれ MixJuice の差分ベースモジュールと深く関係する。 詳しくは ECOOP'02 の差分ベースモジュールの論文参照。
gbeta は北欧の由緒正しいオブジェクト指向言語 BETA の機能を一般化し、 実装しなおされた言語。
Erik Ernst. "Propagating class and method combination". In Proceedings ECOOP'99.
BETA では class と method が unify されている。
たとえば class のメンバーとして class を定義できる。
Java の nested class と違って、サブクラスのメンバークラスは、
スーパークラスの同名のメンバークラスを override することができる。
この機能を virtual class と呼ぶ。
（外側のクラスと内側のクラスの関係は、 MixJuice における module と class の
関係に対応する。）
gbeta では、 BETA の機能をさらに拡張して、 mixin を使えるようにしている。
いくつかの mixin を明示的に結合すると、
それらの mixin のメンバーの class/method や、
それらの mixin のスーパークラスのメンバーの class/method なども mixin として
自動的に結合され、この暗黙の結合は次々と波及してく。
これが propagation らしい。
この機能により、例えば
separation of crosscutting concerns も実現できる。
Erik Ernst. "Family Polymorphism", In Proceedings ECOOP 2001.
gbeta の継承機構によって実現可能になる family polymorphism という機能に
焦点を当てた論文。
Node と Edge という相互参照する２つのクラスがあるとする
それぞれを継承し、サブクラス ColoredNode と ColoredEdge を定義できる。
同様に、サブクラス WeightedNode と WeightedEdge を定義できる。
Node と Edge を引数として受け取るユーティリティ関数は、
これらのサブクラスからも当然、再利用したい。
一方で、 WeightedEdge と ColoredEdge が相互参照するようなことは
無意味なので、型チェックで検査したい。
実はこの場合における再利用性と安全性の両立は、 C++ の template など既存の機構を
駆使しても達成できず、 gbeta ならば達成できるというのがこの論文の主張である。
gbeta は dependent type というものを使ったあやうい型システムによって
family polymorphism を実現しているらしい。
Dominic Duggan, Ching Ching Techaubol:
"Modular Mixin-Based Inheritance for Application Frameworks",
in Proc of OOPSLA 2001.
OOPSLA2001 の論文はまだ見ていない。 同タイトルの MASPLAS'01 の論文が手に入る。 http://www.research.ibm.com/masplas/schedule.html
一見、 MJ と非常によく似ているが、中身はだいぶ違う。 Java のような言語に mixin を入れたときの型システムの話。 名前の衝突は rename によって解決する。
P. Kellomaki and T. Mikkonen. Design templates for collective behavior. In Proc. of ECOOP 2000.
未読。分散リアクティブシステムにおける協調的振る舞いのための仕様記述言語？
|
|
Last updated:
Aug 26 20:37:49 2003
[MJ Top page]
[Site map]
|