実践 ICONIXプロセス : クラスをすべて発見する

シーケンス図を完成させるには、すべてのオブジェクト(クラス)を発見、確定する必要があります。

ドメインクラス

初期ドメインモデル(概念クラス)から出発して、ロバストネス分析で、すべて洗い出し、属性まで定義済み。
シーケンス図では、クラス図から、ドラッグしてくるだけ。

画面表示用のクラス

ロバストネス分析では、バウンダリオブジェクトとして発見し、属性まで定義済み。
これをどのように実装するかは、採用している Web アプリケーションのフレームワークに依存する。

私たちの方式では、Velocity のテンプレートファイルとして実装する。

サービス層のクラス

UI 層に提供するサービスを定義したアプリケーションクラス。
実体は、ドメインクラスとリポジトリクラスに委譲する、コーディネーター役。(自分では何もしない)

これは、シーケンス図作成の過程で、クラス図に追加する。
ロバストネス図の複数のコントロールが、ひとつのサービスクラスになることがある。

リポジトリクラス

永続化を抽象化したデータアクセスクラス。
これも、シーケンス図作成の過程で、クラス図に追加している。

基盤オブジェクト

データアクセスの実装オブジェクト、MVCメカニズムの実装オブジェクトなどが必要であれば、追加する。

---

実装パターンが決まってくると、たいていのユースケースでは、あまりクラスの発見と定義に悩むことはなくなります。

実践 ICONIXプロセス : ユースケースを絵にする

ICONIXプロセスの詳細設計、つまりシーケンス図作成で重要なことは、「ユースケースを絵にする」という意識です。

ロバストネス分析では、ユースケース記述をもとにして、画面遷移から一歩踏み込んで、エンティエィやコントロールを絵にしました。

シーケンス図では、さらに踏み込んで、ユースケース記述を、実装オブジェクトとその相互作用で絵にします。
ロバストネス図を参考にシーケンス図を描くのではなく、ユースケース記述を読みながらシーケンス図を描くことが重要です。

実践テクニック

・ユースケース記述を白紙のシーケンス図に貼り付けてから作業を開始する。
・ユースケース記述を適切に改行して、ユースケースの行と、メッセージの矢印の高さを揃える。

ユースケース記述を追いかけながら、ここで、このオブジェクトからこのオブジェクトにメッセージを送る、ということを絵にしていく。

そのためには、ひとつのメッセージに対応する単位に、ユースケース記述を改行する。
ユースケース記述は「基本コース」「代替コース」の順番ですから、シーケンス図も上部が基本コース、下部が代替コースになります。

ユースケースの分割

この描き方だと図がかなりごちゃごちゃすることがあります。
その時は、ユースケースの分割を、もう一度検討します。
precedes や invokes で連動させるサブのユースケースを括りだすことを検討します。

ユースケースの加筆・修正 (アンチパターン)

シーケンス図を描き始めると、ユースケースのあいまいな点や、矛盾を発見することがあります。
ユースケース記述とシーケンス図は一致させるべきです。

ただし、シーケンス図を描き始めてからユースケースを修正するのは、問題です。
要求レビューをして、ロバストネス分析をして、予備設計レビューをして、ユースケース記述を検証・改良してきました。
この時点では、ユースケース記述は安定していなければいけません。

もし、シーケンス図を描き始めてからユースケース記述の修正が起きるようなら、要求レビュー、ロバストネス分析、予備設計レビューのどこかに改良すべき点があります。

なぜ、記述が不十分だったかを、関係者で検討し、改良ポイントを考えましょう。プロセスの改善活動ですね。


実践 ICONIXプロセス : シーケンス図の目的

ICONIXプロセスで、シーケンス図の作成前、つまりロバストネス図の作成とレビューが終わった段階では、次の状況です。

・バウンダリ(画面)と エンティティ(ドメインオブジェクト)の発見が終わっている。
・画面の詳細な模型を作成済み
・エンティティクラスの属性の大半も定義済み
・ユースケースごとに、処理の順番、情報の流れも定義済み
・必要な機能(表示、入力チェック、情報の取り出しや保存)も定義済み

不足しているもの、未発見・未定義)なのは、

・それぞれのクラスの操作(メソッド)
・永続化のメカニズムに関連したオブジェクト
・MVCフレームワークに関連したオブジェクト
・コントローラークラス

など。

シーケンス図の作成は、この不足部分を発見し、定義し、決定する作業です。

ICONIXプロセスでシーケンス図を描くときのポイントは、三つの視点で説明できます。

・ユースケースの視点
・クラスの視点
・メソッドの視点

それぞれの視点について、ポイントをまとめてみようと思います。

実践 ICONIXプロセス : コントロール、操作、メッセージ、メソッド

シーケンス図の話をする時に、振る舞いを表すための概念(用語)がいろいろある。

・操作
・メソッド
・メッセージ

UML の視点から説明すると、

操作

クラスの振る舞いの名前。動詞を使う。
そのクラスがどんなことをする(できる)かの宣言ですね。

メソッド

操作の実装(実体)。
UML のクラスモデルにはメソッドは登場しない。操作だけ。
Java とかで、クラスモデルの操作を実装すると、メソッドになる。

UMLクラスモデルを Javaコードに自動生成する時、操作名をそのままメソッド名にする。

メッセージ

(静的な)クラス図ではなく、動的モデルのシーケンス図の概念。
オブジェクトとオブジェクトの間のコミュニケーションを表現する。

実装では、オブジェクトのメソッドを呼び出す行為で実現する。

もう少し関連する用語をあげると、

関数

C 言語などで操作を実装する手段。

動詞

オブジェクト指向分析で、振る舞いを見つける手がかり

コントロール

ロバストネス図でロジックの置き場所

その他

責務、振る舞いの特性、機能なども使われる。

---

混乱します。私は正確に使い分けることはできない。
正直いって、実装の手段であるメソッドが一番しっくりくるし、良く使う。

一応

・クラス図では操作
・シーケンス図ではメッセージ
・実装ではメソッド

という使い分けを心がけています。

ICONIXプロセス的には、

ロバストネス図で発見したコントロールを、シーケンス図のメッセージに変換する。
(ツールでは自動的に)メッセージをクラスの操作に割り当てる。

クラスモデルの操作を(コードを自動生成して)Java のメソッドとして実装する。

ということになりますね。

実践 ICONIXプロセス : 詳細設計とフレームワーク

ICONIXプロセスでは、シーケンス図で徹底的に詳細設計をします。
コードを書くときには、メソッドの中身以外に未確定のことをなくすのが目標です。

6年ほど前に、ICONIXプロセスのガイド本「ワークブック形式で学ぶ UMLオブジェクトモデリング」を読んだ時には、ロバストネス図とシーケンス図には大きなギャップがありました。シーケンス図でコントローラークラスなどを追加したりする必要があった。

状況はずいぶん変わりました。現在では、Web アプリケーションの MVCの実装パターンは、フレームワークが提供され、個別にコードを書く必要が激減しました。

私たちは、

・Web Flow 2.0 ( Spring MVC をさらに抽象化したフレームワーク )
・サービス層のサービスクラス(アプリケーション機能を抽象化したクラス)
・ドメイン層の下の、リポジトリクラス(データアクセスを抽象化したクラス)

というフレームワーク/アーキテクチャを採用しています。

このため、ロバストネス図とシーケンス図のギャップはかなり小さくなりました。

あたりまえですが「コードを書く量が減った」ということは「設計すべきことが減った」わけです。

ただ、私たちが採用したフレームワーク/アーキテクチャで描かれたシーケンス図のサンプルはどこにもなかったので、いろいろ試行錯誤をしている最中です。

シーケンス図は、実装の設計なので、採用しているフレームワーク/アーキテクチャによって、描き方のポイントは、かなり異なります。

ICONIXプロセスでは、シーケンス図より前の作業は、どのような実装方式、プロジェクトスタイルでも容易に適用できると思います。
しかし、シーケンス図は、実装方式に依存する部分がかなりある。

もちろん、本質はいっしょなので、このブログでは、そういう点を少しまとめたいと思います。

まず基本目的。

ユースケース記述を実現する方法を絵で描くこと。

実践 ICONIXプロセス : シーケンス図の効果

シーケンス図の効果は明確でした。

コードを書く時間が3分の1になった。
Ecliplse を使っている時間が激減し、Enterprise Architect でシーケンス図を書いている時間が長くなった。

ユースケースを実現するために、シーケンス図で、使用するクラス、使用するメソッド、パラメータなどをきちんと設計する。時間がかかる作業ではある。

でも、その結果、シーケンス図のレビュー完了後、実際にコードを書く時間は激減した。

シーケンス図が完成していれば、クラス名もメソッド名も呼出の順番も全部決まっている。だから、コードを書く作業は、メソッドの中身だけになる。

この効果は絶大です。コードを書く時間を短縮できただけでなく、あきらかに、バグ修正やリファクタリング作業が減りました。

シーケンス図は、ほんとうの設計作業です。コード書きがないから、設計だけを行っている。
設計が終わっていれば、コードを書く作業はほんと楽になることが実感できる。

もっとも、シーケンス図を使うことで、設計を分離すると、設計能力の不足が発覚する。でも、それは良いことですよね。設計が怪しいままコードを量産すれば、あとはバグとの戦いです。しかも、読み解くのがたいへん、ちょっといじれば、わけのわからないところに副作用、という保守地獄にまっさかさまです。

教訓:シーケンス図でちゃんと設計しましょう



実践 ICONIXプロセス : ユビキタス言語 英語?

ICONIXプロセスで、実装設計は、シーケンス図でやる。この段階以降はクラス名も、属性名も、メソッド名も、全部英語。

ICONIXプロセスは、画面の紙芝居からスタートして、業務の用語をドメインモデル図にして、ユースケース記述をして、ロバストネス分析をやる。 ここまでは、オブジェクト名、画面名、エンティティ、全部、日本語でやる。

英語圏だと、ドメインモデルから実装クラスまで「英語」で一貫している。ドメイン駆動設計で言う「ユビキタス言語」ですね。業務の話をしていて出てくる Book という概念が、そのまま Book クラスで実装。業務の世界でも、コードの世界でも、 Book が登場する文字通りの UBIQUITOUS(普遍的に存在する)言語。

日本語だと、問題領域、業務の世界は日本語。コードの世界は英語。そもそも、ユビキタスにできない。
業務の話は「書籍」でしていて、どこかで突然 class Book になってしまう。

ICONIXプロセスも、この問題にはさすがに言及していない。でもモデルをそのままコードに落とす、というICONIXプロセスの目標を日本でも達成するには、クリアしないければいけないハードル。

私たちはのアプローチ

・最初は日本語でスタート。
・英語がわかれば併記していく。(初期のドメインモデル段階からスタート)
・予備設計レビュー(ロバストネス図のレビュー)までには、すべて英語の別名で表示する。

業務用語の英語は、たとえば、英語の類似サイトとか、HR-XML という人材情報系のXML標準とか、データベースモデリングの洋書とかを参考にしている。

モデルの作成作業では、Enterprise Architectの「別名」を使って、ダイアグラムでの別名表示の制御や、アドインでの別名と名前の入れ替えなどをいろいろ試している段階。

いずれにしても、かなり設計作業の負担になっていることは事実。
定型作業はできるだけ自動化を目指したいと思います。

(EAのアドイン開発者を育成せんといかん)

実践 ICONIXプロセス : 分析から実装の架け橋

ICONIXプロセスではシーケンス図は、分析から実装への架け橋です。

ロバストネス図をコードにするために、中間の作業としてシーケンス図を描く。

描き方は、

1.ユースケース記述をノートとして(空の)シーケンス図に貼り付ける
2.ロバストネス図からエンティティをコピーする
3.ロバストネス図からバウンダリとアクターをコピーする
4.ロバストネス図のコントロールをメッセージとしてシーケンス図に配置する

これで、シーケンス図が一丁あがり。

簡単ですね。

もちろん、実際は、ややこしい問題も発生します。

・フレームワークのクラスなど、実装技術に依存したクラスの扱い。
・名前の変換(モデル上の名前と実装上のクラス名やメソッド名の変換)

ここらへんは、私たちも、まだ試行錯誤中です。

シーケンス図を使う価値は理解できましたが、作業が面倒で非効率な印象。
ここらへんの問題を整理する意味で、ICONIXプロセスのシーケンス図を検討してみたいと思います。

実践 ICONIXプロセス : いよいよ実装

ICONIXプロセスでは、実装は、シーケンス図の作成から始まります。詳細設計ですね。

前提となるのは、

・ユースケース記述が完全・正確・詳細・明確になっている
・必要なドメインクラスを全て発見済み

この状態にするためには、

・ロバストネス分析と予備設計レビューが完了している

そして、実装開始のもう一つの前提条件が、

・テクニカルアーキテクチャの確定

また、シーケンス図を描く時の注意事項として、

・最小限
・特定の形式

を強く推奨しています。

実際にやってみて、シーケンス図作成は、かなり時間がかかるし、また、問題が発生しがちな作業でもあることが実感できました。

シーケンス図で詳細設計する、という考え方、テクニックを実践できるようになるには、それなりの学習コストが必要です。

calendar
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM