会話の背景：
ユーザーの要求を明確に記述するために、ユースケースを書く。
ユースケースはシステムと外部との相互作用を表現するもので、システムの機能仕様であり、あるいは、ユーザーと開発者間の契約とも言える。
なぜなら、これらは、われわれが開発しようとするシステムが、どのようになるかをユーザーに説明するもので、ユーザーとのコミュニケーションの大事な手段ともなる。
また、ユースケースはシステム開発プロセスを駆動する中心的なドキュメントでもある。
登場人物
鈴木ー ＰＬ
佐藤、田中－ ＰＧ
会話：
鈴木：おはようございます。
これまでに、われわれはユーザーの要求をよく聞き、現場の資料も集めました。これからは、もっと厳密にユーザーの要求を記述しなければなりません。そのために、これからユースケースを書いて、要求を整理しましょう。
佐藤：ユースケースについて聞いたことがありますが、実際に書いたことがまだありませんので、簡単に、紹介してもらえますか？
鈴木：そうですね。ユースケースはわれわれが開発しようとするシステムの機能をユーザーに説明する手段です。ユースケースでは、さらにシステムの境界を定義します。つまり、だれがこのシステムを使い、このシステムがどこまでの機能を持つのかということを定義します。
佐藤：わかりました。でも、どんなドキュメントを書くでしょうか？
鈴木：ユースケースのドキュメントは二つの種類があります。まずはユースケース図です。二番目はユースケース記述です。
佐藤：ユースケース図の記号と要点は、何でしょうか？
鈴木：各々（おのおの）ユースケースは一つの機能または操作を記述するので、基本的には誰が何をするかを記述します。そのため、ユースケース図では基本的にユースケース名（楕円）、アクター（人型）、関係（接続線）を含んでいます。
佐藤：例で説明してもらえるでしょうか？
鈴木：はい。たとえば、車両見積もり作成という機能では、ユースケース名は「車両見積を作成する」で、アクターは営業マンと外部のデータベースで、アクターとユースケース名の間は、連続線で結びます。
田中：すみませんが、営業マンがアクターになることはわかりますが、なぜデータベースもアクターになるでしょうか？
鈴木：そうですね。ユースケースは実現しようとするシステムの立場から記述するので、このシステム以外で、システムと相互作用をする特定の機能を持つもの、または特定の操作を行う別のもの、たとえば外部のシステムやデータベースなどを操作するものならば、すべてはアクターと呼ばれます。
田中：そうですか、わかりました。
それと、もしシステムの機能が複雑で、一つのユースケースでうまく表現できない場合はどうすればいいでしょうか？
鈴木：そんなことはよくあります。そこで、ユースケースの間には包含、拡張の関係があるので、これらの関係を使えば、一つの大きなユースケースをいくつかに分離し、いろいろなユースケース間の関係を表現できると思います。
田中：なるほど。それでは、ユースケース記述の方法を教えていただけますか？
鈴木：はい。ユースケース記述を照会しましょう。
ユースケース記述はユースケース図より正確に定義する手段として、ある機能のイベントフローを記述します。もちろん、このイベントフローはシナリオ図で書くこともできますが、シナリオ図はイベントフローの一つインスタンスだと思えばいいと思います。ユースケース記述はユースケース図より詳しく機能の流れを記述できます。実際には、ユースケース図よりユースケース記述のほうがもっと重要だと思います。ユースケース図は、他人に説明をするなら、また、システム全体を理解するには有効ですが、ユースケース図だけでは、機能の仕様を表すには、十分ではありません。
田中：それは助かります。ユースケース図記述を行うときの要点はなんでしょうか？
鈴木：ユースケース記述に関しては、ＵＭＬ標準の中では統一されていませんが、大抵以下の部分を含んでいると思います。ユースケース名、概要、基本フロー、代替（だいたい）フロー、例外フロー、事前条件、事後条件、などです。
佐藤：概念は大体わかりましたが、ユースケース図でもユースケース記述でも、サンプルをいただけるでしょうか？
鈴木：それは後で、例を挙げましょう。
佐藤：最後ですが、ユースケースに関してどんな参考文献がありますか？
鈴木：そうですね。たとえば、アリスターコーパンさんが書いた「ユースケース実践ガイド―効果的なユースケースの書き方」という本は参考にできると思います。訳本（やくほん）は翔泳社が出版しました。それ以外にもいろいろありますが、サンプルと一緒にリストしておきましょう。
佐藤：どうもありがとうございました。
鈴木：それでは、皆さんには今回車両販売管理システムのユースケースを書いてもらいます。がんばってください。きょうのミーティングはここまでです。
６．コンテキスト図とコンセプト図
会話の背景：
システム分析段階ではユースケースを作成することが中心的な作業であるが、しかしながら、ユースケースだけではうまく表現できない部分も相当ある。たとえば、システムの全体に関する概念や機能、また外部との情報交換など。それに対していろいろな手段がある。ここではコンテキスト図やコンセプト図を紹介する。
登場人物：
近藤―システムアーキテクト
鈴木― ＰＬ
山田、田中：ＰＧ
会話：
鈴木：こんにちは。
これまでに、皆さんにユースケースを書いてもらいました。大変お疲れ様です。なにか問題があるでしょうか？われわれはどう対処（たいしょ）すればいいか、などを議論してもらいましょう。
山田：そうですね。ユースケースの書き方はなんとかわかってきましたが、具体的なユースケースを書くと、システムの全体に関する概念や機能などが見えなくなる恐れがありますが、それにたいして何かいい方法あるでしょうか？
近藤：はい。まず、よくやっている方法はユースケースリストです。すなわち、一つの画面（図形の方法）また一枚のページ（テキストの方法）で、全てのユースケースのタイトルを番号で関係をつけながら、集めてリストしておきます。
山田：ＯＫ、わかりました。
もう一つは、実際的な現場のユーザーには、データの流れを表現していないユースケース図は、直観的に理解しにくく、データの流れを表すＤＦＤのような設計図のほうがわかりやすいではないでしょうか？
田中：すみませんが、ＤＦＤとは？
鈴木：ＤＦＤはData Flow Diagramの略です。すなわち、データの流れを表すためのダイアグラムです。
近藤：そうですね。一部のオブジェクト指向の本によると、ＤＦＤなどはオブジェクトの概念とは反対のものなので、あまり使わないように薦めています。しかし、私の経験では、それは参考にはなりますが、まったくその通りにやる必要はないかもしれません。
ユースケース図は、やはり開発するシステム機能に早く集中する傾向があり、開発対象とするシステム外のほかのシステムや要素とのつながりが漏らしてしまうことがあるようです。また、ユースケース図はシステムの範囲を決めるべきだが、システム開発の初期では、範囲をはっきり決めるのはなかなか難しいこともよくあります。
山田：そうですか。
近藤：そのため、全ての人が理解できる、システムを一枚の図で表すようなものが必要です。これにはコンテキスト図が向いています。ここで言うコンテキスト図は一種のＤＦＤですが、システム外（そと）とのデータのやり取りのみを記述し、システム内部のデータについては何も記述しないものです。また、コンテキスト図は、ユーザー側の企画書などにすでにある場合は、それをチェックして、開発側で流用できるケースもあると思います。
そうすると、この前言ったように、ユースケースが顧客とのコミュニケーションに使われるというのとちょっと矛盾するようにおもわれますが、やはり現実には、同じようなものの違った表現が必要です。
山田：どうもありがとうございます。コンテキスト図に関してはわかりました。ところで、各ユースケースで出てきた概念や名前など名詞は、これからはクラスになると聞きましたが、そうでしょうか？
近藤：それの答えはＹｅｓでもありＮｏでもありますね。各ユースケースで現れた名詞はクラスになる可能性が十分ですが、必ずクラスになるかどうか、いまの時点ではまだわかりません。そのため、コンセプト図を導入することが必要だと思います。
田中：コンセプト図とは？
近藤：コンセプト図は一種のクラス図ともいえますが、分析レベルのものです。普通のクラス図ではクラスの属性と操作などの記述が必要ですが、ここではおもに名前だけを整理した図になります。とういうのは、基本的にはユースケースから出てきた名詞を整理したうえで、重要な意味をもつ名詞、あるいはオブジェクトらしい名詞をリストし、それらの名詞の間の関係をつけてみます。その目的は、重要な概念をみつけ、重要ではない概念を捨てることです。コンテキスト図と同じように、できるだけ、一枚の図でこのシステムの重要な概念をお客様にみせたほうがいいと思います。
田中：わかりました。われわれもコンセプト図を書きましょう。
それと、ユースケース記述を表すためにシーケンス図を使うこともできるでしょうか？
近藤：そうですね。クラス図と同じように、シーケンス図でも分析レベルと実装レベルの区別があると思います。一般的にいうと、実装レベルのシーケンス図はオブジェクト間のメッセージ通信です。しかし、分析段階ではオブジェクトそのものがまだはっきりしていないので、オブジェクト間のメッセージ通信より、システムの流れを表します。言い換えると、ユースケース記述の替わりに、図で表現するものです。われわれは、このようなシーケンス図をシナリオ図とよんでいます。シナリオ図の主な特徴は明確的なオブジェクトはもっていません。
田中：大体、かんじはつかめましたが、まだ十分に理解できていないようです。例で説明してもらえますか？
近藤：わかりました。
たとえば、「車両の注文書」を作成するというユースケースでは、その流れは、以下のようになっている。
・お客様の注文情報を入れて、
・システムがデータベースから対応する見積情報を引き出し、
・その見積情報に基づいて注文書のデータを纏め、また今回注文の情報を付け加え、
・最後にそのお客さんの注文書を作成し、
・確認したうえで、印刷する。
このような流れをシナリオ図で表すことができます。
田中：わかりました。これからは、われわれもユースケースリスト、コンテキスト図、コンセプト図、および一部のシナリオ図を書いてみましょう。
鈴木：それがいいでしょう。がんばりましょう。
没有评论:
发表评论