Transcript オブジェクト指向
知識工学とCAD研究会
アスペクト指向
ソフトウェア開発
九州工業大学
情報工学部 知能情報工学科
鵜林尚靖
2005年7月16日
1
内容
アスペクト指向が生まれた背景
アスペクト指向の考え方
様々なアスペクト指向メカニズム
アスペクト指向の適用事例
アスペクト指向とMDA
アスペクト指向の今後
2
1.アスペクト指向が
生まれた背景
3
ソフトウェア開発手法の変遷
60 年代
70 年代
80 年代
90 年代
2000 年代
構造化手法
構造化プログラミング
構造化分析
構造化設計
オブジェクト指向手法
OOP
OOA
OOD
パターン
フレームワーク
コンポーネント
EA
プロダクトライン
アジャイル, XP
MDA
アスペクト指向
4
アスペクト指向とは何?
一言でいうと
「モジュール化メカニズム」の一つ
5
モジュール化メカニズムの歴史
構造化
機能中心のため、データの変更に対して脆い
データ抽象
データとそれに関連する操作をまとめてしまおう
抽象データ型
データとそれに関連する操作をまとめて型にしよう
オブジェクト指向
継承機構も入れて、再利用性を高めよう
6
モジュール化メカニズムの発展
~ 構造化 から オブジェクト指向 へ ~
操 作
操 作
操 作
オブジェクト
操 作
データ
データ
操 作
データ
操 作
操 作
データ
操 作
データ
オブジェクト
オブジェクト
操 作
操 作
データ
操 作
データ
データ
構造化
データを変更すると周りの
操作に影響が波及する
オブジェクト指向
変更の影響範囲が
オブジェクト内に
カプセル化される
7
モジュール化の理想像
ソフトウェア構造
要求分析
設計
実装
問題
領域
分析時の
関心事
設計時の
関心事
モジュールの
構成
問題領域の構造がソフトウェア構造に対応する
ソフトウェア構造を構成する関心事を自然にモジュール化できる
(関心事の分離 “Separation of Concerns” Edsger Wybe Dijkstra )
8
良いモジュール化
org.apache.tomcat におけるXML parsing
– 赤い線はXML parsingを行うコード行を示す
機能要件を
きれいにモジュール化
– 1箇所にモジュール化されている
AspectJ. http://eclipse.org/aspectj/より抜粋
9
しかし、ログ処理の場合は...
複数のオブジェクトにまたがる
(Crosscutting Concerns)
org.apache.tomcat におけるログ処理
– 赤い線はログ処理を行うコード行を示す
– 1箇所ではない
– しかも、数多くの場所に分散している(tangling and scattering)
AspectJ. http://eclipse.org/aspectj/より抜粋
10
現実のモジュール化は...
ソフトウェア構造
要求分析
設計
実装
問題
領域
分析時の
関心事
設計時の
関心事
モジュールの
構成
(問題意識)
上流の関心事が、下流に行くにしたがって構造的に分散してしまう
(オブジェクト指向でも解決できない問題がある)
11
オブジェクト指向の限界
オブジェクト指向プログラミングは、機能要件のカプセル化には優れているが、
横断的関心事( Crosscutting Concerns )の表現には必ずしも向いていない。
<横断的関心事の例>
・エラーチェック戦略
・セキュリティ
・デザインパターン
・同期制御
・資源共有
・分散にかかわる関心事
・性能最適化
性能最適化のためのコードを追加しようとする
と、コードが複数のオブジェクトに分散してしま
い、見通しの悪いプログラムになってしまう。
「分かりやすく性能も良い」プログラムを作る
のが難しい。
AOP
12
組込みソフトウェア設計の難しさ
現在のソフトウェア技術では、機能的合成可
能性が物理的合成可能性を意味するものでは
ない。
実際、物理特性は合成可能ではない。むしろ、
開発プロセスにおいて、横断的制約(crosscutting constraints)として現れる。
このような横断的制約は設計をやり難くして
しまう可能性がある。
Janos Sztipanovits and Gabor Karsai:
Generative Programming for Embedded Systems,
GPCE2002, LNCS2487, pp.32--49, 2002
13
組込みソフトウェアの構造
最適化
メモリ容量
HW特性
応答性
きれいなプログラムを作成したい!
でも、HW特性、性能向上、例外のためのコードを追加すると
どんどんプログラムが汚くなってしまう。。。
アスペクト指向
14
アスペクト指向を実現する
言語処理系、システム
AspectJ (Gregor Kiczales, et.al.)
Hyper/J (Harold Ossher, et.al.)
DemeterJ (Karl J. Lieberherr, et.al.)
Composition filters (Mehmet Aksit, et.al.)
JBoss-AOP
AspectWerkz など多数
15
2.アスペクト指向の
考え方
~ AspectJ を中心に ~
16
AspectJ
最も代表的なAOP言語
AOPの基本的な考え方をJava上に実
現した言語
元々はPARCで開発。現在はEclip
seプロジェクトに移管。
AspectJ: http://eclipse.org/aspectj/
17
開発環境: AJDT
Eclipse Tools Projectの1つ。
AJDT(AspectJ Development Tools)は、AspectJを用いた
アスペクト指向開発を支援するためのツールをEclipse上に
提供する。
AJDTを用いることにより、JDT(Java Development Tools)
上でAspectJの機能が使用できるようになる。
AJDT:
http://eclipse.org/ajdt/
18
AspectJによるプログラミング方式
同期制御、資源共有、性能最適化など複数のオブジェクトにま
たがる関心事をアスペクトというモジュール概念を用いて記述
オブジェクト
(通常の機能)
weaver
プログラム
アスペクト
(オブジェクトに
またがる関心事)
・複数のオブジェクトにまたがる関心事を見通しよく記述できる!
・「分かりやすく性能も良い」プログラムが作れる!
19
AspectJの主要概念
振る舞いへの作用
ジョインポイント(join point)
ポイントカット(pointcut)
アドバイス(advice)
構造への作用
インタータイプ定義
declare句による宣言
20
簡単なAspectJプログラム
アスペクト
HelloWorld.java
public class HelloWorld {
public static void main ( String [], args) {
HelloWorld app = new HelloWorld ();
app.hello();
}
Trace.java
インタータイプ
定義
public aspect Trace {
private String HelloWorld.mes = “トレース”;
ポイントカット
public pointcut atHello() :
call (void HelloWorld.hello());
void hello() {
System.out.println(“こんにちは!”);
}
before(HelloWorld h) : atHello() && target(h) {
System.out.println(h.mes + “呼び出し前”);
}
}
after(HelloWorld h) : atHello() && target(h) {
System.out.println(h.mes + “呼び出し後”);
}
}
アドバイス
「AspectJによるアスペクト指向プログラミング入門」
長瀬、天野、鷲崎、立堀(著) より
21
JPM(Join Point Model)
public aspect Trace {
private String HelloWorld.mes = “トレース”;
public pointcut atHello() :
call (void HelloWorld.hello());
before(HelloWorld h) : atHello() && target(h) {
System.out.println(h.mes + “呼び出し前”);
}
after(HelloWorld h) : atHello() && target(h) {
System.out.println(h.mes + “呼び出し後”);
}
メソッド呼び出し、
変数参照/更新など
の実行点を捕まえる
}
weaving
トレースコードの
埋め込み
(advice)
プログラム上の
様々な実行点
(join point)
実行点の取り出し
(pointcut)
実行点の中から
トレース処理に関
わる部分を抽出
22
実用的な例:
簡易図形エディタ
Display
* FigureElement
Figure
makePoint(..)
makeLine(..)
Point
getX()
getY()
setX(int)
setY(int)
moveBy(int, int)
moveBy(int, int)
2
Line
getP1()
getP2()
setP1(Point)
setP2(Point)
moveBy(int, int)
operations that
move elements
AspectJ. http://eclipse.org/aspectj/より抜粋
23
通常の保守、改良
class Line {
class Line {
private Point p1, p2;
private Point p1, p2;
Point getP1() { return p1; }
Point getP2() { return p2; }
Point getP1() { return p1; }
Point getP2() { return p2; }
void setP1(Point p1) {
this.p1 = p1;
void setP1(Point p1) {
this.p1 = p1;
Display.update(this);
}
void setP2(Point p2) {
this.p2 = p2;
Display.update(this);
}
}
void setP2(Point p2) {
this.p2 = p2;
}
}
}
class Point
{
class Point
private int x = 0, y = 0;
private int x = 0, y = 0;
int getX() { return x; }
int getY() { return y; }
int getX() { return x; }
int getY() { return y; }
void setX(int x) {
this.x = x;
void setX(int x) {
this.x = x;
Display.update(this);
}
void setY(int y) {
this.y = y;
Display.update(this);
}
}
void setY(int y) {
this.y = y;
}
}
{
変更が複数の
クラスに散らば
ってしまう!
}
AspectJ. http://eclipse.org/aspectj/より抜粋
24
AspectJによる保守、改良
class Line {
aspect DisplayUpdating {
private Point p1, p2;
pointcut move(FigureElement figElt):
target(figElt) &&
(call(void FigureElement.moveBy(int, int) ||
call(void Line.setP1(Point))
||
call(void Line.setP2(Point))
||
call(void Point.setX(int))
||
call(void Point.setY(int)));
Point getP1() { return p1; }
Point getP2() { return p2; }
void setP1(Point p1) {
this.p1 = p1;
}
void setP2(Point p2) {
this.p2 = p2;
}
after(FigureElement fe) returning: move(fe) {
Display.update(fe);
}
}
class Point
{
private int x = 0, y = 0;
int getX() { return x; }
int getY() { return y; }
void setX(int x) {
this.x = x;
}
void setY(int y) {
this.y = y;
}
}
}
(set* のような記述も可能)
変更が1つのアスペクトに局所化される!
予期しないソフトウェア発展に有効!
(unanticipated software evolution)
AspectJ. http://eclipse.org/aspectj/より抜粋
25
クラスを横断するアスペクト
Display
* FigureElement
Figure
makePoint(..)
makeLine(..)
Point
getX()
getY()
setX(int)
setY(int)
moveBy(int, int)
moveBy(int, int)
2
Line
getP1()
getP2()
setP1(Point)
setP2(Point)
moveBy(int, int)
DisplayUpdating
AspectJ. http://eclipse.org/aspectj/より抜粋
26
3.様々なアスペクト
指向
メカニズム
27
様々なアスペクト指向メカニズム
アスペクト指向 = AspectJ ではない!
たとえば、
PA (AspectJ流 pointcut & advice)
TRAV (DemeterJ流 traversal specifications)
COMPOSITOR (Hyper/J流 class hierarchy composition)
OC (AspectJ 流 open classes )
※用語は以下のものに準拠
Hidehiko Masuhara and Gregor Kiczales:
Modeling Crosscutting in Aspect-Oriented Mechanisms, ECOOP 2003
28
http://www.cs.ubc.ca/labs/spl/projects/asb.html
ASB
ASB(Aspect Sand Box)
4つのアスペクト指向メカニズムをモデル化
4つのインタプリタを提供
ここでは、ASBのサンプルプログラム(※)を提示しながら
4つのアスペクト指向メカニズムを紹介する
※ 元々のプログラムはSchemeライクな言語であるが、ここでは、
分かりやすさを考慮してJavaライクな 言語で説明する
※ 以下の論文からの引用
Hidehiko Masuhara and Gregor Kiczales:
Modeling Crosscutting in Aspect-Oriented Mechanisms, ECOOP 2003
29
基盤となる例題プログラム
簡易図形エディタ
30
PA (AspectJ流 Point
cut & Advice)
ASBサンプルプログラム
after (FigureElement fe):
( call(void Point.setX(int))
|| call(void Point.setY(int))
|| call(void Line.setP1(Point))
|| call(void Line.setP2(Point)))
&& target(fe){
fe.display.update(fe);
31
TRAV
(DemeterJ流)
Northeastern大学で開発されたツール/ライブラリで、Javaに
よるAdaptive Programmingを支援する
ASBサンプルプログラム
Visitor counter = new CountElementsVisitor();
traverse("from Figure to FigureElement",
fig,
counter);
fig
[Visitor]
Counter
traverse 仕様に則り、
オブジェクト木を訪問し、
Visitor メソッドを実行
Point
32
COMPOSITOR
J流)
(Hyper
Hyper/Jとは
IBM T.J Watson Research Centerで開発された
Javaベースの言語。
SOP(Subject-oriented programming)およびその
後継の MDSOC(Multi-Dimensional Separation
Of Concerns)という考え方に基づいている。
すべてを関心事(クラスで表現)としてプログラミ
ングする方式。AspectJのようにアスペクトとクラ
スといった区分がない。
ソフトウェアのevolutionへの柔軟な対応を重視。
33
つづき
ASBサンプルプログラム
class Observable {
Display display;
void moved() {
display.update(this);
}
}
; relationship between Point/Line and Observable
match Point.setX with Observable.moved
match Point.setY with Observable.moved
match Line.setP1 with Observable.moved
match Line.setP2 with Observable.moved
34
OC (AspectJ流 Open
Class)
AspectJ の インタータイプ定義
ASBサンプルプログラム
class DisplayMethods {
void Point.draw() { Graphics.drawOval(...); }
void Line.draw() { Graphics.drawLine(...); }
}
35
疑問...
PA
TRAV
COMPOSITOR
OC
同じアスペクト指向と言っても
全然違うではないか?
これらに共通するものは
あるのか?
36
Three-Part Model
Aprogram
META weaving
parameter
Bprogram
XJPjoin point
X - computation
or program
Hidehiko Masuhara and Gregor Kiczales:
Modeling Crosscutting in Aspect-Oriented Mechanisms, ECOOP 2003
37
Three-Part Model (つ
づき)
c, m, f: class, method, field の略
38
4.アスペクト指向の
適用事例
39
アスペクト指向の適用事例
デバッグやロギングについてはメリットは分かるが、
それ以外の応用はどうなのか?
デザインパターンへの応用
[Hannemann他02]
データベースへの応用
[Rashid他03]
FreeBSDカーネルの最適化コードをAOPで分離
[Coady他02,03]
WebSphereのコードをAOPで分離
[Coyler04]
40
事例1:
デザインパターンへの応用
Jan Hannemann and Gregor Kiczales:
Design Pattern Implementation in Java and AspectJ,
OOPSLA2002 (2002)
AspectJを持いて、GoFデザインパターンの記述を改良
41
Observer パターン
Subject
Attach(Observer)
Detach(Observer)
Notify()
*
1
o
Observer
Update()
for(;全てのObserver;)
{o->Update();}
1
1
ConcreteSubject
subject
ConcreteObserver
subjectState:State*
observerState:State*
GetState()
Update()
return subjectState;
observerState
= Subject->GetState();
42
Observer パターンの適用例
Jan Hannemann and Gregor Kiczales:
Design Pattern Implementation in Java and AspectJ,
OOPSLA2002 (2002) より引用
43
Observerパターンの汎用アス
ペクト
抽象ポイントカット
抽象アスペクト
インタフェース
アドバイス
Jan Hannemann and Gregor Kiczales:
Design Pattern Implementation in Java and AspectJ,
OOPSLA2002 (2002) より引用
44
実際のプログラムへの適用
具象ポイントカット
Jan Hannemann and Gregor Kiczales:
Design Pattern Implementation in Java and AspectJ,
OOPSLA2002 (2002) より引用
45
事例2:
データベースへの応用
永続性(Persistence)は横断的関心事の1つ
アスペクト指向により、永続性をモジュール化したい
永続アスペクトを再利用したい
永続性のことを気にせずにアプリケーションを開発したい
Aspect-Oriented Database
Awais Rashid and Ruzanna Chitchyan:
"Persistence as an aspect", AOSD2003
46
アスペクト化された永続性(1)
例: 文献管理アプリケーション
データアクセスに関わる
join pointを抽出し、そこに
DB処理のためのコードを
weavingする
47
アスペクト化された永続性(2)
AspectJ による記述
public class PersistentRoot {
protected boolean isDeleted = false;
public void delete() {
this.isDeleted = true;
}
public boolean isDeleted() {
return this.isDeleted;
}
}
public abstract aspect DatabaseAccess {
private static Connection dbConnection;
private static String dbURL;
abstract pointcut establishConnection();
abstract pointcut closeConnection();
public abstract String getDatabaseURL();
public abstract String getDriverName();
Connection
Storage &
Update
pointcut trapInstantiation() : call(PersistentRoot+.new(..));
pointcut trapUpdates(PersistentRoot obj) :
!cflow(call(public static Vector
SQLTranslation.getObjects(ResultSet, String))) &&
(this(obj) &&
execution(public void PersistentRoot+.set*(..)));
public aspect ApplicationDatabaseAccess {
declare patents: (BibliographyItem ||
AuthorEditor ||
Publisher ||
PublisherLocation)
extends PersistentRoot;
pointcut trapRetrievals() : call(Vector PersistentData.get*(..));
public static PersistentData getPersistentData() { … }
:
:
// other code
}
Retrieval
// advice code
}
48
アスペクトベースの永続化フレーム
ワーク
<<aspect>>
SQLTrajnslation
<<use>>
<<aspect>>
MetaData Access
永続化フレームワーク
アプリケーション
<<use>>
Lookup Table
<<aspect>>
Data Access
<<use>>
Persistent Data
<<use>>
<<aspect>>
Establish Mapping
Application
specific
customisation
<<aspect>>
Application
Database Access
Persistent Data
Implimentation
Weaving
永続性の部分をアスペクト化することにより、アプリケーションは永続性のことを気にせず
に開発できる(一部例外あり)。
49
5.アスペクト指向と
MDA
50
MDA(Model-Driven Architecture)とは
実装技術(J2EEや.NETなど)から分析/設計を
独立させ、設計情報が実装技術に左右されないよ
うにする技術
分析/設計部分はプラットフォームに
依存しない為、再利用可能
UML2の目玉
51
MDAと従来プロセスの違い
従来の開発
MDAによる開発
分析
CIM
PIM
設計
PSM
コーディング
設計フェーズが
大きく変化!
モデルコンパイラ
による自動変換
ソース・コード
CIM: Computation Independent Model
PIM: Platform Independent Model
PSM: Platform Specific Model
52
モデル変換の例(Strutsの場
合)
ステップ1: 複数PIMの合成
①PIMクラスのマージ
ステップ2: アクションフォーム
Beanへの変換
②Bean規約名に変更
③ActionFormを継承
④setter/getterを追加
ステップ3: アクションクラス
の新規作成
⑤アクションクラスを生成
⑥Actionを継承
⑦executeメソッドを追加
⑧メソッド本体を追加
PIM
PSM
53
MDAのメリット
コード中心開発からモデル中心開発へパラダイムシ
フト: 開発者は特定のプラットフォームやプログ
ラミング技術にとらわれることなく、PIMの開発に
全力を注ぐことができる。
新しいタイプのコンポーネント化: PIMモデル部
品とモデル変換規則をライブラリ化することにより、
様々な機能やプラットフォームに対応したプロダク
ト群を生成することが可能になり、プロダクトライ
ン型開発の実現につながる。
54
MDA実現のための鍵
厳密なモデル表記 (MOF、OCL)
厳密なモデル変換定義 (QVT)
QVTの例
mapping Simple_Class_To_Java_Class
refine Simple_Class_And_Java_Class {
domain {(SM.Class)[name = n, attributes = A] }
body {
(JM.Class)[
name = n,
attributes = A->iterate(a as ={} |
as + Simple_Attribute_To_Java_Attribute(a))
]
}
}
MOF: Meta Object Facility
OCL: Object Constraint Language
QVT: Queries, Views, and Transformations
55
MDAとアスペクト指向
PIMモデル(UML)
アプリケーション
weaving
実装環境対応コード
アプリケーション
実装環境対応コード
マッピングルール(MOF QVT)
アスペクト記述言語
「AspectJによるアスペクト指向プログラミング入門」
長瀬、天野、鷲崎、立堀(著) より
56
当研究室の研究紹介:
AspectMモデルコンパイラ
アスペクト
アスペクト
アスペクト図
(モデル変換モジュール
(モデル変換モジュール
(モデル変換モジュール
としてのアスペクト)
としてのアスペクト)
としてのアスペクト)
XML
アスペクトを追加する
ことにより様々な変換
を可能にする
UMLモデル
(クラス図)
XML
weave
UMLモデル
(クラス図)
モデルコンパイラ
XML
アスペクト図
(システム構成モジュール
としてのアスペクト)
XML
アスペクト指向メカニズムにより
モデルコンパイラを実現!
57
AspectMにおけるJPM
JPMでモデル変換を記述
Join Point
クラス名
Advice
クラス名
属性
・・・
属性①
属性②
操作
・・・
操作
・・・
クラス図
Point Cut
58
モデル変換のためのJPM
モデル変換機能
操作本体の変更
クラスのマージ
クラスの追加/削除
PA
CM
NE
OC
RN
RL
○
①PIMクラスのマージ
CM
②Bean規約名に変更
○
RN
○
③ActionFormを継承
操作の追加/削除
○
属性の追加/削除
○
RL
④setter/getterを追加
クラス名の変更
○
操作名の変更
○
属性名の変更
○
OC
⑤アクションクラスを生成
NE
⑥Actionを継承
継承の追加/削除
○
集約の追加/削除
○
関連の追加/削除
○
PA(pointcut & advice),CM(composition),NE(new element),
OC(open class),RN(rename),RL(relation)
RL
⑦executeメソッドを追加
OC
⑧メソッド本体を追加
PA
59
MessageクラスとMessageProfileクラスを
AspectMの記述例
マージしてPostMessageクラスに変換
aspect
<< CM >>
merge-message-classes
message-classes : class
{ Message || MessageProfile }
merge-message-classes [message-classes]
: merge-by-name
{ PostMessage }
<aspect name="merge-message-classes" type="CM" >
<pointcut name="message-classes" type="class"> Message || MessageProfile </pointcut>
<advice name="merge-message-classes" type="merge-by-name">
<ref-pointcut> message-classes </ref-pointcut>
<advice-body>
<element> PostMessage</element>
</advice-body>
</advice>
</aspect>
60
6.アスペクト指向の
今後
61
アスペクト指向の今後
現在、プログラミング周りで研究が活発(8
0年代のOOP研究を彷彿させる)
今後は、適用事例の拡大、開発方法論の整備、
アスペクトコンポーネント・フレームワーク
の整備に向かって行くと思われる(90年代
のOOソフトウェアエンジアリングの発展に
類似)
歴史は繰り返す...
62
AOSD ソフト開発工程全体への波及
AOP(Aspect-Oriented Programming)
から
AOSD(Aspect-Oriented Software Development)
へ
AO: Aspect-Oriented
要求分析
Early Aspect
設計
AO
Design Pattern
AO
Modeling
Aspect
Mining
AO
Framework
実装
AO
Language
AO
Component
AO
Database
63
上流段階のアスペクト研究例
Stein他[AOSD2002]
アスペクトをUML図として表現する方法を提案
モデリング段階のアスペクトはAspectJなどのAOP言語に変換
するもので、この方法ではMDAは実現できない
AspectMのアスペクトはUML図自身を操作するもの
Gray他[GPCE2003]
AODM(Aspect-Oriented Domain Modeling)を提案
属性や関連などのモデル要素を追加する機能をもつ
MDAなどの一般的なモデル変換を対象にしたものではない
Sillito他[ECOOP2004]
ユースケースレベルのポイントカットを提案
上流のモデリング段階においてもJPMの考え方が有効であるこ
とを示した
64
アスペクト指向言語の変遷
ドメイン専用AOP言語を個々に開発するアプローチ
(1997年頃まで)
Weaverを開発するのが大変
汎用AOP言語(AspectJ等: 「Pointcut+Advice」メカニズ
ム)のアプローチ
(現在)
適用範囲が限定される
拡張可能ドメイン専用AOP言語の(Xaspect等)アプローチ
(これから)
65
アスペクト指向に関する情報源
ポータルサイト
http://aosd.net
国際会議
Aspect-Oriented Software Development (AOSD)
OOPSLA, ECOOP, GPCE, ICSE, FSE, ICFP など
66
研究室の紹介
67
最近の主な研究
Naoyasu Ubayashi and Tetsuo Tamai: Aspect-Oriented Programming
with Model Checking, AOSD 2002
Kouhei Sakurai, Hidehiko Masuhara, Naoyasu Ubayashi, Saeko
Matsuura, and Seiichi Komiya: Association aspects, AOSD 2004
Tetsuo Tamai, Naoyasu Ubayashi, and Ryoichi Ichiyama: An Adaptive
Object Model with Dynamic Role Binding, ICSE 2005
Naoyasu Ubayashi, Tetsuo Tamai, Shinji Sano, Yusaku Maeno, and
Satoshi Murakami: Model Compiler Construction Based on Aspectoriented Mechanisms, GPCE 2005 (to appear)
68
現在進行形の研究
Weaving by Contract
Contract Generator for AO Refactorings
Class-based AOP Language
Reflective AOP Language
69
最後に
奥の深そうな着想を見つけて、長期間研究する。
研究の成果に対して明確な目的意識をもって研究する。
理論的研究は、現実問題に有用であることを、その価値基準とす
る。
力のありそうな人となるべく多くの議論をする。
学生は、できるだけ早くかつ多く欧米に行かせ、発表・議論させ
てくる。
理論を研究する学生にも、必ず実装をきちんとさせる。
システム実装が得意な学生には、自分の実装の特徴を概念化・明
示化する訓練をさせ、かつ実装の重要性を自覚させる。
各学生には、その人生に1つでよいから、他人が考えたことのな
い、概念・アイデア・プロダクトを、確立あるいは作成するとい
う使命感をもたせる。米澤 明憲 「私のソフトウェア研究」より
コンピュータソフトウェア, Vol.21,No.5(2004)
70
おわり
71