ハマチを活用したソフトウェア開発

＃思いつき
ハマチの持っている能力を最大限に引き出すソフトウェア開発方法を考えてみたりするコーナー
ハマチはコンポーネントを繋ぐ糊の役割を持っているソフトウェアです。この特徴から仕様変更に強いのでそっち方面ばかり目を奪われるともう一つの特性に気が付かずにハマチの持つ能力の半分しか料理出来ません。
もう一つとはフローの呼び出しポイントが自由であるというちょっと変わった特性です。このの特性を持つ事で一連の流れを分断して呼び出したとしても全体としてはフローの通りに辿る事が可能になっています。
この二つの特徴を最大限に生かす為には要件定義から設計に至る各工程で重要なポイントがたくさん発生します。
まず、要件定義の工程では画面の流れをきちんと把握し、それをドキュメントに残すことが大事です。（画面遷移図とは別）この画面の流れをきちんと把握するというのは、業務フロー上重要なアクションをしている画面を把握する意味でも非常に重要です。
とりあえず、JaWEで画面のフローを記述するのもありだと思います。
それと、データに状態がある場合や業務フローをきちんと定義する必要がある場合もかなりまじめに定義します。ただし、ここで１００％を目指すと次に進めなくなる事があるので必要なアクションを抽出する事に注意します。
必要なアクションとそれぞれの関連が抽出出来た段階であとはkusuを使って設計します。ここではほとんどそのままやればOKです。
設計の後半あたりからJaWEでフローを描いていきます。フローを描く上での重要なポイントは画面単位で分断したフローにしない事。フローは必ず最初の要件定義で決めたフローに出来る限りあわせて描いてください。
実装の段階では、それぞれのサービスでは指定されたActivity名で呼び出します。
サービスがフローのみで良い場合はAOPハマチを使って呼び出します。
単なる共通のデータ取得系みたいに非常に単純でハマチを使う必要のないサービスに無理にハマチを使う必要はありません。あくまで業務フロー上で重要なサービスに割り当てる事を忘れずに
これがハマチを使って実装するときの方法です。要件定義〜設計工程さえハマチに適合させれば実装上のArchitectureはほとんど従来と変更する必要がない事に気が付くと思います。逆にハマチがあることでコンポーネントの単純化、フローの可視化の利点とフローの変更のしやすさの利点を最大限に生かす方法論の方が重要です。