asatoの技術的な日常日記

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

スポンサーサイト

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

コンサーン

ソフトウェアの構造が適切でなくなっていく理由は色々ある。適切でないとは、うまくモジュール化できていないとかそういうこと。

理由の一つは、技術的な要因に関するもの。たとえば、プログラミング言語の能力不足。

もう一つは、管理的な要因に関するもの。たとえば、開発者の能力不足やリリースのプレッシャーなど。


この記事では、リリースのプレッシャー、つまり、締切りの理由からとにかく動くコードを書く必要があるために、設計について考慮する時間がとれなかったとか、リファクタリングする余裕がなかった時のコードの構造について一つの例を挙げて考えたい。


以下では、適切にモジュール化されていない、という代わりに、コンサーンを適切に分離できていない、ということにする。コンサーンとは

The term concern is loosely defined to represent anything that stakeholders of a software project may want to consider as a conceptual unit. Typical concerns in a software project include features, nonfunctional requirements, design idioms, and implementation mechanisms (e.g., caching).

-----
Martin P. Robillard and Gail C. Murphy.
Representing Concerns in Source Code.
ACM Transactions on Software Engineering and Methodology, 16(1):1-38, February 2007.
http://www.cs.mcgill.ca/~martin/papers.html

つまり、コンサーンは、概念的な単位であり、ステークホルダが気にするなんでも。


さて、では、僕がこの前、適切にコンサーンを分離できていなかった例を挙げて、(すでに誰かが言及していることも含めて)何か考察してみよう。

作っているソフトウェアは、ゲーム。どんなゲームかというと、「ローグ」とか「不思議のダンジョン風」のゲーム。

以下は、プレイヤーが「足踏み」行動の入力を行ったときの処理内容を表すクラス。このクラスは、Command パターンでいうところの ConcreteCommand に対応する。


// 「足踏み」行動の時の処理内容
public class PlayerHPHealingTaskCommand implements TaskCommand {

private GameManager gameManager;

public PlayerHPHealingTaskCommand(GameManager gameManager) {
this.gameManager = gameManager;
}

public void execute() {

// プレイヤーの「満腹度」が0なら、一定の値で HP を減少
// そうでなければ、HP を増加
//
// ... コード

// 「満腹度」を減少
status.setHungry( status.getHungry() - 20 );
}
}



「足踏み」行動の基本的な仕様は、「プレイヤーの「満腹度」が0なら、一定の値で HP を減少そうでなければ、HP を増加。その後、「満腹度」を一定値で減少させる、というのもの」

コード的に色々まずいところもあるけど、一つまずいのは、「HP値を減少/増加される」というコンサーンと「満腹度を減少させる」というコンサーンがうまく分離されていない部分。
concern.png



あるいみでは、仕様書通りの振る舞いなのだけど、「満腹度を減少させる」という処理は「移動」行動の処理を行うときの、サブ処理の一つなので、「満腹度を減少させる」という処理を一つの ConcreteCommand として分離して、「足踏み」と「移動」の二つの処理で使えるように出来るのが望ましい。
concern2.png

concern3.png





考察


まず、コンサーンがうまく分離できてないと、プログラムの理解や修正が難しくなる。

次に、Command パターンを適用している構造の時、ConcreteCommand として分離されるべきコンサーンは、からまってしまう状況がある。
concern4.png


スポンサーサイト

コメント

結果的なアーキテクチャの問題よりなぜそのようなアーキテクチャになってしまったのかというのを人とか組織とかの観点で時系列で見てみると面白いのでは。

  • 2007/08/15(水) 21:30:43 |
  • URL |
  • ysakata #-
  • [ 編集]

コメントの投稿


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

トラックバック

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

FC2Ad

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