ユースケース
システムの視覚化
システムを開発するデベロッパは、システムの詳細な仕様を知る必要があります
そうしなければ、デベロッパはまともなシステムを開発することはありません
技術者に対して、「…の様なものがあって、これをこんなふうにすると」という説明では
まず、間違いなく技術者に意思が伝わることはないと思ってかまいません
クライアントが予想していたシステムとは、かなり相違のあるものが組みあがります
システム開発を依頼する場合、依頼者は明確な知識が要求されます
内部的なプログラムの知識は必要ありませんが、専門用語を熟知している必要があり
意味論を付属した明確な要求をしなければ、技術者に伝わりません
これは、日本のソフトウェア産業が直面する大きな問題です
初心者が技術者やソフトハウスに仕事を依頼しても、それが伝わりません
会社が何をしたいのか、どのようなものを作ってほしいのか、わからないのです
そこで、UML はシステムを視覚化、図面化するユースケース図を定めています
ユースケース図の利用者は、プログラムやオブジェクト指向の知識はほとんど必要なく
直観的にシステムの仕様や、処理の流れを理解することができます
もちろん、それだけ抽象化されているので開発者にとっては意味のあるものではありませんが
システムの大まかな機能や分類子を定める、最初のステップとして重要です
漫画でたとえるとするならば、ネームのようなものと考えられます
分類子
ユースケース図において、分類子はユースケースで表します
ユースケースは処理と、外部の要素の関係を記述するためのもので
利用者や他のシステムとやり取りを行うメッセージを表しています
通常、システムやサブシステム、クラスが提供するサービスをここに記述します
ユースケースは、楕円の中にユースケース名を記載します
ステレオタイプは名前の上に、プロパティは名前の下に記述することができます
基本的な扱いは、静的構造図におけるクラスと同じだと考えてください
ユースケース名は、場合によっては楕円下部に配置してもかまいません

これがユースケースの基本図です
ユースケースが表すのは、必ずしもクラスである必要はありません
場合によっては処理の流れで発生するシステムの挙動かもしれませんし
他のシステムとの連帯を記述するためのメッセージかもしれません