スライド 1

寺本裕基 武山文信 千葉滋
東京工業大学
情報理工学研究科 数理・計算科学専攻
1

同じようなコードを記述するとき使用
◦ 保守性の問題
 一箇所変更すると他のモジュールも変更しなければならない
class Rectangle extends Shape {
List<Display> displays = new
ArrayList<Display>();
int xpos, ypos;
int width, height;
void setX(int x) {
xpos = x;
for(Display d : displays)
d.update(this);
}}
class Circle extends Shape {
List<Display> displays = new
ArrayList<Display>();
int centerX, centerY;
int radius;
void setCenterX(int x) {
centerX = x;
for(Display d : displays)
d.update(this);
}}
2

メソッドの利用
◦ update() 処理を一つにまと
めることで、保守性を上げる
◦ 変更は一箇所で済む
class Rectangle extends Shape {
int xpos, ypos;
int width, height;
void setX(int x) {
xpos = x;
updateDisplays();
}}
class Shape {
List<Display> displays = new
ArrayList<Display>();
void updateDisplays() {
for(Display d : displays)
d.update(this);
}}
class Circle extends Shape {
int centerX, centerY;
int radius;
void setCenterX(int x) {
centerX = x;
updateDisplays();
}}
3

複雑な機構を導入すれば強力なモジュール化が可能
◦
◦
◦
◦
◦

パラメータ(関数引数)
テンプレート
クラス
アスペクト
・・・
隠れたコスト
◦ 新しい言語を導入しなければならない
◦ 複雑なので言語を理解するのが難しい
◦ 開発環境、ライブラリ、フレームワークなども用意しなければ
ならない
4

Eclipse 上でコピー&
ペーストによるモジュール
化
◦ Java言語は拡張しない
 他の言語は学習不要
◦ 保守性の問題を解決

機能強化
◦ 複製したコード領域の変更
に対した同期
 手続き抽象に相当
5

Eclipse 上でコピー&
updateをredraw
ペーストによるモジュール
に変更
化
◦ Java言語は拡張しない
 他の言語は導入不要
◦ 保守性の問題を解決

機能強化
◦ 複製したコード領域の変更
に対した同期
 手続き抽象に相当
6

Eclipse 上でコピー&
updateをredraw
ペーストによるモジュール
に変更
化
◦ Java言語は拡張しない
 他の言語は導入不要
◦ 保守性の問題を解決

機能強化
◦ 複製したコード領域の変更
に対した同期
変更が自動で伝わ
 手続き抽象に相当
る
7

引数は使用場所によっ
て別のものにしたい

同期領域のうち部分的
に同期しないことも可能
class Rectangle extends Shape {
int xpos, ypos;
int width, height;
void setX(int x) {
xpos = x;
display.update(xpos,ypos,
width,height);
width,
height);
}}
class Circle extends Shape {
int centerX, centerY;
int radius;
void setCenterX(int x) {
centerX = x;
display.update(centerX-r,
centerY-r, 2*r,
2*r,2*r);
centerY-r,
2*r);
}}
8

あちこちで同じコードが実行されるとき、どこで実行され
るかを抽象化(一箇所にまとめる)
◦ あちこちで個別にメソッド呼び出ししない
コードに名前をつ
けられる
aspect Update {
after(Shape s) : execution
(* Rectangle.set*(..)) ||
(* Circle.set*(..)) {
s.display.update(s.xpos,
s.ypos, s.width, s.height);
}}
コードが実行され
る場所が一目でわ
かる
class Rectangle extends Shape {
int xpos, ypos;
int width, height;
void setX(int x) {
xpos = x;
}}
9

同期領域には名前をつけられる
◦ コードに名前をつけられる

同期領域の場所の一覧を表示
◦ コードが実行される場所が一目
でわかる

Update
Rectangle
setX(int)
setY(int)
・・・
Circle
setCenterX(int)
setCenterY(int)
・・・
同期の問題点を解消
◦ どこが同期されているのかわかりにくい
◦ 意図せず別のコードが書き換わってしまう可能性
10
11

AspectJ
◦ 引数が異なる処理は二つ
のアスペクトを定義する必
要がある
◦ 提案方式は一つで良い

AJDT
◦ アスペクトが織り込まれる
場所をエディタ上に表示
◦ アスペクト指向プログラミン
グの知識が必要
aspect RectangleUpdate {
after(Rectangle r) : execution
(* *.set*(..)) && this(r) {
r.display.update(r.xpos,
r.ypos, r.width, r.height);
}}
aspect CircleUpdate {
after(Circle s) : execution
(* *.set*(..)) && this(c) {
c.display.update(c.centerXc.r,
c.centerY-c.r, 2*c.r, 2*c.r);
}}
12

Fluid AOP[Honら ‘06]
◦ 複数のモジュールにまたがるコードを一度に編集可能
◦ アスペクト指向プログラミングの知識が必要

Linked Editing[Toomimら ‘04]
◦ リファクタリング用のツール
◦ 既に存在するコードクローンを同時に編集可能
◦ 提案方式は開発初期から利用可能
13

IDEを活用したモジュール化の提案
◦ 再利用したいコードを複製し、同期
◦ 一部分のみの同期を可能にすることでパラメータ抽象に対応
◦ アウトライン表示によりアスペクト抽象

今後の課題
◦ 実装できていない部分の実装
◦ 本システムの評価
14