現実的ユースケース

たとえば、現実的ユースケースには、表示したり入力したりする項目を明らかにした画面イメージが添付されていたりします。
この詳細な画面イメージというのは必須ではありません。
大まかな画面(に限らずユーザーインターフェース一般)を説明したもの(ストーリーボードといいます)を作っておいて、もっと実装が進んだ段階でユーザーインターフェースの詳細を定義していく方法もあります。

実装前に画面の承認を得たいなどの理由で、詳細にインターフェースを記述しておきたい場合には、この現実的ユースケースは便利です。

「Buy Items (商品を購入する）」の現実的ユースケース

図１

まあこんな画面は実際にはないでしょうが、どんな画面でどんな動きをするのか、見えてくるのがこの「現実的」ユースケースです。

協調図も、シーケンス図も、オブジェクト同士がどんなふうに関連しあいながら相互的に作用するのかということを説明するためのものです。
動的な関連を「オブジェクトが通信する」とか「メッセージ」と呼びます。オブジェクト同士が何かメッセージをやり取りしているというイメージなんですね。

で、この相互作用図、協調図でもシーケンス図でも同じことを説明できます。
一つ一つの説明のわかりやすさでいえば、シーケンス図のほうが上でしょう。
＃分析フェーズでやった「システムシーケンス図」はシーケンス図の一種です。
では協調図のメリットは何でしょうか。
まず１つはスペース効率です。同じスペースなら、たいてい協調図のほうが多くのことが書けます。
もう１つは補助情報の豊富さです。条件付きや繰り返しメッセージなども協調図のほうが書きやすいです。
まあ、シーケンス図は、分析フェーズで使ってみましたから、こんどは協調図を書いてみましょう。

endSaleに付随する協調図

1. 計算するのに何が必要？
2. 計算するのはだれがやる？

1. 協調図やシーケンス図などの「相互作用図」を調べて、登場するクラスを洗い出す。
   ＃もちろんこれは、システムがわだけのクラスを洗い出す。
2. 概念図を参考に、とりあえずクラス図にしてみる。
   ＃慣れてくると、パッと見て閃きます。で、大体合ってます。
   ＃閃かない場合は、じっと見つめます。じわじわと浮かんできます。だいたい正解です。
   ＃それでもだめなら、図をいじりまわしてみましょう(笑)
3. 概念図の時にあった属性は、大体設計クラス図にもあってしかるべきなので記入する
4. 相互作用図を見る。クラスが矢印で結ばれている。矢印を受ける側に、メソッドを追加する。
5. 属性やメソッドのパラメータの型を正確に決める。
   
6. あるクラス(のインスタンス)があるクラス(のインスタンス)を属性として持っている、と判るように線を追加する
   ＃このとき、どちらがどちらを持っているのか判るように矢印を追加する
7. あるクラス(のインスタンス)があるクラス(のインスタンス)を属性としては持たないが、メソッドの中で作成して使っている、と判るように線を追加する

勢いのままコーディングになだれ込んでみる

class レジ {
    売上取引 torihiki;
    商品情報カタログ katarogu;

    enterItem(商品コード,数量) {
        if (FIRST) {
            torihiki = new 売上取引();
        }
        商品情報 shouin = katarogu.searchItem(商品コード);

        torihiki.createItem(shouin, 数量);
    }
    endSale() {
        torihiki.completeSale();
        合計金額 = torihiki.computeTotal();
    }
    enterPayment(金額) {
        torihiki.enterPayment(金額);
    }
}

class 商品情報カタログ {
    商品情報[] shouhin;

    searchItemInfo(商品コード) {
        for each (商品情報 s in shouhin) {
            if (s.商品コード = 商品コード) {
                return s;
            }
        }
    }
}

class 商品情報{
    String 商品名;
    Currency 価格;
    String 商品コード;
}

class 売上取引 {
    入力商品[] nyuryoku;
    現金支払 shiharai;

    Date 日付;
    Time 時間;
    Boolean SaleCompleted;

    completeSale() {
        SaleCompleted = true;
    }

    createItem(商品情報, 数量) {
        入力商品 nyuitem = new 入力商品(商品情報, 数量);
        nyuryoku.add(nyuitem);
    }

    computeTotal() {
        Currency Total = 0;
        for each (入力商品 nyu in nyuryoku) {
            Total = Total + nyu.comtputeSubtotal();
        }
        return Total;
    }

    enterPayment(金額) {
        shiharai.金額 = 金額;
    }
}

class 入力商品 {
    商品情報 shouhin;
    Integer 数量;

    computeSubtotal() {
        return shouhin.価格 * 数量;
    }
}

そうそう、クラス図の点線の説明をしましょう。
クラス図を見ると、「レジ」と「売上取引」から「商品情報」に点線が引いてありますよね。
これは、「属性として持ってるわけじゃないけど使う」って意味です。
コーディングを見てください。いや協調図でもいいですけれど。
「レジ」は属性としては商品情報をもっていません。
「レジ」は「商品情報カタログ」の「searchItemInfo」を使って「商品情報」を取得しています。属性として持っているわけじゃありません。
また、「売上取引」も「レジ」から「商品情報」を受け渡されるだけで、やはり属性として持っているわけじゃないですよね。
こういうとき、点線を使って表現します。

ここで上げたのは本当に駆け足ですし、いちおう「オブジェクト指向でやってみた」というところです。
そう、ようやく、入り口です。
拡張性は？再利用性は？生産性は？
まだ、この段階では考えられていません。
それは、オブジェクト指向入門３…いやもうこの辺まで来ると入門じゃなくなります。
「実戦に役立つオブジェクト指向」として次コンテンツにしましょうか。
「ちゃんといろいろ考えたモデリングをしよう」ということで。