asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

コード進化パターン:抽象クラスの継承によるコードの重複の削除 (2)

前回の記事 だけど、分析が足りなかったので補足。

まず、一応 DSM (Design Structure Matrix) で構造変化を表してみる。DSM は要素間の依存関係を表現するための方法。ここでは、要素はクラス単位。

before:
dsm_extends_abstract_class_in_refactoring_before.jpg


after:
dsm_extends_abstract_class_in_refactoring_after.jpg


DSM から分かるように、ConcreteComponentA と AbstractComponent の間に継承の依存関係ができている。


具体的な例のやつも DSM で表してみる。
before:
dsm_extends_abstract_class_in_refactoring_example_before.jpg

after:
dsm_extends_abstract_class_in_refactoring_example_after.jpg


こっちの DSM では、デザインの構造を表す要素 or デザインパラメータであるクラスだけでなく、それらデザインパラメータが依存している「仕様」もデザイン構造の要素して加えている。デザインパラメータとかについては「Design Rules」本(翻訳)」を参照。ソフトウェアデザインでの話は Lopes らの 論文 を参照。

この DSM の例からは、先ほどの例と同じように、ItemUseMenu (ConcreteComponentA) と AbstractMenu (AbstractComponent) の間に継承の依存関係ができている。

依存の要素に「仕様」を含めたので、仕様が変わればそれに伴ってクラスも変更する必要がある(かもしれない)ことが分かる。

たとえば、オープニング(or タイトル画面)で選択するメニューアイテムの数が変化すれば、「オープニングメニュー仕様」が変わる。それに伴って、OpeningMenu も変化する必要がある。同様に、「アイテム使用メニュー仕様」が変われば、ItemUseMenu も変化する必要がある。

一方で「AbstractMenu」は、何の仕様にも依存していないように見える。では、疑問は「AbstractMenu」は、いつ変化するのか、誰(変化のドライバ)によって変化が引き起こされるのか、ということ。

一つは、品質に関する観点。リファクタリングなど。リファクタリングをするか決めるのは誰か。少なくとも、ソフトウェアを使うユーザではない。ユーザは、構造に関係する品質(保守性、モジュラリティ、などなど)を気にしない。ほとんどの場合は、開発者が決める。

図で表すとこんな感じ。
menuitem.png



眠くなってきたのでここで終了。


まとめ:
-DSM (Design Structure Matrix) を使って、コードの変化を確認した。

-デザインの要素だけでなく、仕様などの要求も含めて、DSM で変化の様子を分析した。

課題
-コンサーンとの関係について。

-アーキテクチャのルールについて。

-OpeningMenu/ItemUseMenu の変化が AbstractMenu を変化させるきっかけとなる場合について。

-関連研究の話。Lopes のデザインパラメータの種類。
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/39-ad328958
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。