2004-07-31

S2Unitの強化

S2.0.15でS2Unitはかなり強化されます。
Map, MapのList, Bean, BeanのListを
DataSet(Excelから読み込んだデータ)とassertEquals()で比較できます。
かなり楽。いわゆるKモードに入ってます。

検索系のテスト



readXlsWriteDb("xxxPrepare.xls");

List actual = dao.getXxx(...);

DataSet expected = readXls("xxxResult.xls");

assertEquals(expected, actual);

更新系のテスト



readXlsWriteDb("xxxPrepare.xls");

dao.updateXxx(...);

DataSet expected = readXls("xxxResult.xls");

assertEquals(expected, reload(expected));

S2.0.15, S2Dao1.0.2は今日出ます。

2004-07-31

ユーザ機能分析

くーす

これまで、ユーザ機能はVOで表すことを推奨してました。
一方オリジナルのFDDでは、<オブジェクト><結果><アクション>で
表現します。「〜の〜を〜する」ってことです。
結局言ってることはほとんど同じなんですよね。
だったら、オリジナルにあわせて、ユーザ機能は、<オブジェクト>(<結果>)<アクション>で表すことにしたいと思います。
ただし、結果は省略可能ですね。「〜を〜する」もあるということです。

ユーザ機能をアトミックになるまで分解していくときに、
どこまで分解すれば、アトミックといえるかですが、
論理的に言うと単一の目的だけに徹していてこれ以上分解すると
ユーザにとって意味があるというより、単にAPIの分解になってしまう
粒度です。とはいっても、もっと具体的であった方がいいでしょう。
今考えているのは、2時間以内で実装できる粒度のものです。
オリジナルが2週間だといっていたのを考えるとめちゃ小さいですが、
S1時代のRuletが1日に3,4個実装できていたような気がするので、
こんなもんじゃないかなと思ってます。

ユーザ機能分析と一緒に行うシナリオ分析ですが、
これまで特にフォーマットは決めてなかったのですが、
シーケンス図でいいかなぁと思ってます。
UMLでいうとシーケンス図を使うことが素直なのと、
UMLベースの開発なんて言うと客の受けが良いためです。
全部ほんとのことですから！！！！
登場人物は3人(バウンダリ、業務ロジック、Dao)ではじめて
補助ロジックが登場したら追加していく形になると思います。

くーすのワークショップをやるってのも面白いかもしれないですね。