4
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

ユースケース駆動開発について

Posted at

これは何

ドメイン知識が複雑で特定の人しか把握していない仕様があり、他のメンバーが仕様が把握しやすいようにする必要がありました。

勉強会で見かけたユースケース駆動開発に興味があり、本を読んでみてユースケースモデリングとドメインモデリングについて書いてみました。

ユースケース駆動開発について

ユースケース駆動開発とは、システムの機能を利用者から見たシステムの振る舞いを記述したもの(ユースケース)に分割し、それを基に要求分析から実装までの工程を進めていく開発手法です。

本はこちら
ユースケース駆動開発実践ガイド

この本の第2章の「ドメインモデリング」と第3章「ユースケースモデリング」を参照しました。

ユースケース駆動開発自体は古くからあり書籍も古いが、現在でも十分通用する内容だと思います。

ユースケース駆動開発の拡張(と本の中では定義されている)として、TDD駆動開発も可能になるそう。
これは、ユーザー視点で設計していく開発手法なので納得できますね。

ドメインモデリング

ドメインモデリングの目的は、問題領域に対する共通の用語集を作成することによって、プロダクトのコミュニケーションミスによる問題を解決する。

DDDのドメインモデリングとの違い
DDDにもドメインモデリングがあり、ユースケース駆動開発と似たような概念になっているので、DDDの導入を検討する際にも役に立ちそうです。

厳密には、DDDのドメインモデリングとユースケースモデリングは違い、DDDのドメインモデリングはクラス図に近い形で書きます。

ドメイン駆動設計の2つのモデリング手法 ユースケース図とドメインモデル図をどう作る? - ログミーTech

ドメインモデル図について

作成するにあたっては、以下のルールで作成するのを心がける。

  • 作業は2時間に限定する。
    • ICONIXプロセスではドメインモデルを完璧に作成するのではなく、以降のプロセスで成り立たせていく。
  • あくまで、現実世界のオブジェクトに焦点を合わる。
    • データベースモデルやクラス設計ではない。
  • 属性や振る舞いは記述せず、シンプルにドメイン名のみ。
  • 汎化(is-a)・集約(has-a)関係を用いる。

ユースケースモデリング

ユースケースモデリングの目的は、ユーザーの操作 に対する システムの応答を明らかにし、正常系(基本コース)と異常系(代替コース)を洗い出すこと。

ユースケース図とユースケース記述を作成する。

ユースケース図よりも、ユースケース記述がより重要。

ユースケース記述時のポイント

  • ドメインモデルの用語を用いる。
  • バウンダリクラス(主に画面名)の名前を使う。
  • ユーザーとシステムの対話の両側を記述する。
  • 指示的ではなく叙述的に書く。

    • ×ユーザーは著者名で検索できる。
      ○ユーザーが著者名を入力して「検索」ボタンを押す。システムは著者名に一致する書籍一覧を検索結果画面に表示する。
  • 基本コース(いわゆる正常系)と代替コース(いわゆる異常系)を記述する。
  • ユースケース図上の「関係」を正確に記述することを頑張らない。
    ほとんどの場合、ユースケース図の関係は invokes、precedes で十分で、extends や includes が必要になる機会は少ない。

ユースケース記述がなぜ重要か

ユースケース記述はユーザーガイドを書くのに似ているとのこと。

「ユースケース駆動」は、「まずユーザーガイドを書き、それからコードを書く」というように要約できるらしい。

「ユースケース駆動」の目的は、ユーザーの操作に対する振る舞い要求を実現するためなので、ユーザーの視点でシステムの振る舞いを記述すれば、設計や単体テストもユーザーの視点になる

レガシーシステムにも適用できる。
その際は、ユーザーガイドから開始するのがよいとのこと。
既存の機能を分析し、ユーザーガイドからユースケースを導き出すと、自然と基礎的なコンポーネントにブレイクダウンする(と言う理論らしい)。

ドメインモデリングとユースケースモデリングについて

いきなりユースケース図から作成する (ユースケースモデリングする)のではなく、ドメインモデリングから開始する。

理由は、ユースケースは抽象的に書くのではなく、設計するシステムに近いものであるべき(と著者が言っている)。

※ユースケースを抽象的に書くことが、一般では多いが、ユースケース駆動開発(ICONIXプロセス)では、それとは正反対。

ユースケースは動的な部分の基礎を形作り、ドメインモデルは静的な部分の基礎を形作る。
静的な部分は構造を定義し、動的な部分は振る舞いを定義する。

ICONIXプロセス

ICONIXプロセスでは、ロバストネス分析が肝になるそうなので、厳密にユースケース駆動開発を実践するには、ロバストネス分析以降のステップも含め、実践する事が重要です。

ICONIXプロセス(ロバストネス分析)については、ここでは書きませんので、ご了承ください。

iconixprocess-feature-image.png

ユースケース駆動開発およびICONIXプロセスの読解は、以下のサイトが割とわかりやすかったです。
読んだ : ユースケース駆動開発実践ガイド - ひだまりソケットは壊れない
明日から使えるDDDのためのユースケース駆動開発(ICONIXプロセス) - Qiita

4
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?