このページをはてなブックマークに追加このページを含むはてなブックマーク このページをlivedoor クリップに追加このページを含むlivedoor クリップ

目次

ユースケースモデル

  • ユースケースモデルとは、システムを利用者の視点で端的に捉えた機能モデルである。
    • システム利用者の視点により、ユーザーの業務ナレッジを最大限にシステムに活かすことができる。
    • ユースケースモデルは、システムの利用者の視点で、システムの利用者と開発者の間でシステム要求の姿を明らかにするために作成されたモデルである。
  • ユースケースモデルは、ユーザーの視点でシステムに対する要求を整理するための道具である。
    • つまり、システムの要求やシステム化のアイデアは、ユーザーから獲得するか、システム開発者自ら提案することが基本となる。
    • ユースケースモデルを作成しているうちにいつの間にか要求が獲得できるという手品ではない。
    • ユーザー手動で要件をモデルによって整理することで、より視覚的な分析ができ、新たなシステムのアイデアが具現化できるという効果はあるが、それは副次的なものである。
  • ユースケースモデルはオブジェクト中心のモデリングとは異なる機能中心のモデリング技術である。
    • しかしながら、オブジェクト指向開発には必須ともいえる。
  • ユースケースモデルで整理できる要求は、機能要求のみである。
    • 機能要求とはシステムを利用するユーザーから見て、システムの機能と考えられるもののことである。また、機能要求以外のものを、非機能要求という。
  • 非機能要求はユースケースモデルでは表せないため、非機能要求一覧としてまとめられる。
    • これにより、非機能要求についても、アーキテクチャ設計に加味される。
  • 機能単位をユースケースにしてはいけない。
    • ユースケースの単位を機能分割の感覚で作ってしまうと、そのようなユーズケースはユーザーの視点から見ると時系列を伴うものが多い。
      • 時系列を表す術がないユースケース図には不適切なユースケースであったり、ユースケースの個数が膨大になってしまう。
  • DBがどこにあるかなどは問題ではない。
  • アクターはシステムにアクセスする外部のアクターの責務を明確にすることで、システム運用における使用を明らかにさせることが目的であるが、この点があいまいな記述がよくある。
  • ユースケース図はシステムの要求をビジュアルにとらえるものである。
    • しかし、一般にユースケースの粒度はかなり大きくなる。そうすると、ユースケースだけを見ても要求がどのようなものであるか一目でわからない。
      • そこで、ユースケース記述でそれを補う。
  • 開発対象のシステムが大きくなればなるほど、ユースケースは本質的な要求だけにとどめておいたほうがよい。
  • ユースケースモデルはシステム利用するというユーザーの視点(what)から作成するが、設計モデルはどう作るべきかという(how)視点で作成される。

ユースケースモデルの構成要素

 ユースケースモデルはユースケース図とユースケース記述によって構成される。

  • ユースケース図
  • ユースケース記述

ユースケース図

  • アクターはシステム境界の外部に書かれ、ユースケースはシステム境界の内部に書かれる。
  • アクターとユースケースをつなぐ線は関連という。

ユースケース記述

  • ユースケース記述はあまり細かく書いてしまうと問題が起こることがある。
    • なぜならば、ユースケース記述はシステム開発のかなり早いフェーズから用いられるモデルだからである。よって、システムの詳細な動きについてシステマチックに書きすぎると、根拠なき挙動を書いてしまうことにつながってしまう。
    • ちょっとしたストーリー(構想)を書いているという軽い気持ちのほうがうまくいきやすいと言われる。

ユースケース

  • ユースケースはユーザーから見た機能である。
    • 開発者から見える機能は、ユースケースとしては適切ではないことが多い。
  • ユースケース名はユーザーの利用事例に名前を付けたものと考えるとよい。
    • ある程度の規模になるビジネスアプリケーションにおいては、ユースケースの個数やユースケース図の枚数が膨大になる可能性あるため、システム利用単位でユースケースを書くことで、この問題を解決することができる。
  • どんなに多くなっても、ユースケース図は20枚以内、図中のユースケースは7戸程度に抑えるとよい。
  • ユースケースの粒度は、あまり小さくならないようにする。
    • あくまでユーザーから見てシステムを何らかの目的で使う際の一連の利用について、1つのユースケース名で表す。
    • 粒度を細かくしすぎて開発者から見た機能単位・画面単位になってしまうと、ユースケースのメリットは薄れる。

オブジェクト技術から見たユースケース

  • オブジェクトの再利用性や拡張性を考慮するということは、システム境界からはみ出たオブジェクトを対象にするということになる。
    • なぜならば、再利用可能なオブジェクトには、システムで必要とされる要求を満たす機能のほかに、他のシステムでも必要とされるであろう機能を盛り込むからである。
    • また、オブジェクトに拡張メカニズムを組み込むことは、今必要な機能だけではなく、将来必要とされる機能を組み込むメカニズムを導入することであるからである。
  • 再利用性や拡張性をシステムに対する要求を同じ視点で考えてしまうと、今必要とされる要求に疎くなってしまう。
    • このような問題を解決するためにユースケースモデルは有効である。
      • なぜならば、まずユースケースによってユーザーからシステムに要求されている機能は何なのかをしっかりとらえることができるからである。
  • オブジェクト技術を実践するためには、ユースケースモデルだけに頼るのではなく、アプリケーションの視点とオブジェクトの視点とのバランスを併せ持ち、それぞれの視点でシステム開発を見るべきである。
    • アプリケーションの視点とは、システムとして必要とされているものが何で、それをいつまでに作るべきかというユースケースの視点である。
    • オブジェクトの視点とは、将来必要となる機能は何か、ソフトウェアの構造はどうするのか、再利用できる個所はどこかという視点である。

ソフトウェアテストから見たユースケース

  • ユースケースの視点は、テスト作成時にも有効である。
  • ユースケースはシステムの利用事例を整理することなので、開発早期の段階でシステムの要求を利用者の視点で整理することができる。
  • ユースケースをまとめる段階からユースケースの視点で、テスト項目を抽出するとよい。
    • そして、テスト主導で開発を行えば、開発目的に即した設計モデルが自然とできるものである。
  • ユースケース記述中のイベントフローを具体的な例(シナリオ)を書いて、そのシナリオをテストケースとして利用する。
    • つまり、シナリオテストができる。
    • しかし、それではあまりに細かすぎ、現実の画面設計などとのギャップがありすぎて問題にあるときは、もっと大まかなレベルで、ユースケースの視点(つまりはシステム利用者の視点)でテスト項目を抽出整理してみるとよい。

VOPC(View Of Participating Classes)

  • ユースケース単位に作成されるクラスのこと。
  • このようなクラス図は、ユースケースの説明を機械的に行うのではなく、概念構造に照らし合わせて行う場合には有効になる。しかし、さらにVOPCを有効に利用するには、1つのユースケースではなく、問題領域の概念を中心にいくつかのユースケースをまとめて説明するという工夫が必要になる。

参考文献

  • 『これだけでわかる!初歩のUMLモデリング』