仕様記述言語としてのjava

以前にAPIコンプライアンステストにて、脳内の概念モデルを言語に変換するという話を書きました。その際、仕様記述という目的に java 言語を用いています。

概念モデルの仕様化にあたり、主に java のインタフェースを用いる目的は、仕様として必要な多くの情報を盛り込み、仕様として不必要な多くの情報を盛り込みたくても盛り込めないようにすることです。そして、ある程度形式化されていることや、実装言語に変換する際のオーバーヘッドが小さいことは選択理由の一部です。（OOA/OODが前提で実装言語が未定であれば、おそらく UML を用いると思います。）

ユビキタスランゲージであることは前提事項

おいらは、java を仕様記述言語として扱う場合、それはユビキタスランゲージでなくてはならないと考えています。これは java の場合にというよりは、あらゆる仕様記述言語はユビキタスランゲージであるべきだと考えていることに由来します。

言語仕様だけでなく内容もユビキタス

ユビキタスランゲージと言う単語だけを捉えれば、関係者に対してユビキタスな言語仕様であればよさそうな気がします。しかし、DDDでの説明を見れば分かるとおり、ツールないし成果物としてのドメインモデル全体をユビキタスなものとして捉える必要があります。そのため、その言語によって書かれている内容についても、すべての関係者にとってユビキタスであると捉えられる必要があります。そうなると、モデルの管理体制の確立、言語教育、用語辞書の整備などを前提とする必要がありそうです。結構大変ですね。

言語教育

仕様記述言語として java の interface を用いるのであれば、関係者全員が、interface の概念やメソッドのシグニチャについて理解している必要があります。さらには、必要に応じてクラスや例外や Enum についても理解しておく必要があります。他にもさまざまなことを共有する必要があるため、そのための教育体制を確立するひつようがありそうです。

どの程度まで仕様記述に盛り込むべきか

これは、ケースバイケースかと思いますが、ぱっと思いつくだけでもいくつかの選択肢があります。

普通に java のインタフェースを使う。
- 普通に java のインタフェースを使います。
- 普通に java のインタフェースを使うことにより表現しきれない部分については、javadocに記述します。

APIコンプライアンステストを使用する。
- java の intarface として静的にチェックできないために javadoc にて記述した仕様を、APIコンプライアンステストにて厳密に検証可能にします。

アノテーションによるバリデーションを使用する。
- アノテーションを使用することにより、javadoc上に自然言語で記述するよりも厳密な使用記述が可能になります。
- javadoc による自然言語記述レベルの厳密さでは許容できない場合かつ、java 言語による記述が適切な場合は、補助クラスにて仕様を定義します。
- 以下、メソッド定義の例。

String setName(@NotNull @Length(max=30) String name);

ロジックの実装を作成する。
- ロジックは、自然言語で記述するだけでは厳密さにかけるので、javaで記述することにより形式化する。
- 以下例。

public interface User {
	
	/**
	 * 生年月日を返します。
	 * @return 生年月日
	 */
	Date getBirthDay();
	
	/**
	 * 生年月日から指定日までの秒数を返します。
	 * @param targetDate 指定日
	 * @return 生年月日から指定日までの秒数
	 */
	long getSecondsToTargetDate(Date targetDate);
	
}

/**
 * User interface の仕様定義のための補助クラス。 User interface の振る舞いのうち、javadoc
 * による自然言語記述レベルの厳密さでは許容できない場合かつ、java 言語による記述が適切な場合は、
 * この補助クラスにて仕様を定義します。
 */
public class UserSpecHelper {
	
	/**
	 * 生年月日から指定日までの秒数を返します。
	 * 
	 * @param user
	 *            User
	 * @param targetDate
	 *            指定日
	 * @return 生年月日から指定日までの秒数
	 */
	long getSecondsToTargetDate(User user, Date targetDate) {
		return (targetDate.getTime() - user.getBirthDay().getTime() / 1000L);
	}
	
}

ここまでやる必要があるのか？

ここまでやる必要あるのか？という疑問の湧いた人は、ここまでやる必要はないと思いますし、やってはいけないと思います。

おいらの場合は、具体的な不満があり、この方法によってその不満が解消するかどうかでこの方法を評価することができます。しかし、具体的な不満がない人は、新しい手法の利点を理解できず、過去の方法のメリットを失った部分だけを感じることになるとおもいます。

おいらの不満

おいらの不満は、ある程度の規模を超えるシステム開発を行う際に、ユーザーとのコンセンサスを得ることや、ユーザー自身にユーザー自身がなにを考えているかを理解させることが難しいことです。その原因は、上流工程では成果物の情報の粒度が大きく、下流工程では成果物の情報の粒度が小さいという一般的な考え方に起因しています。一般的に、粒度の大きい情報はユーザー要件寄りであり、粒度の小さな情報は実装寄りと考えられる傾向があるため、多くの場合、開発体制上、初期段階で粒度の小さな情報を得ることができませんでした。逆に、アジャイル開発方法論を間違って適用しているプロジェクトにおいては、粒度が小さい情報を得ることはできるのですが、それと同時に、初期段階では決定してはいけない実装レベルの決定を初期段階で下すという愚をPMが犯す結果に終わりました。というわけで、不満解消の策を模索しているわけです。

まとめ

上記は、おいらの不満解消のための道を模索しているうちに浮かんだアイデアの１つにすぎません。いまは正しいかどうかもわかりません。まぁ、気が変わるまではこの方向の模索を続けていくことになるとおもいます。

合掌。