<< XP, ICONIX, ウォータフォール系 : 要件定義 一度にひとつ | main | XP, ICONIX, ウォーターフォール系 : 要件定義 詳細化 >>

XP, ICONIX, ウォーターフォール系 : 要件定義 用語集(概念モデル)

XP, ICONIX プロセス、ウォータフォール系の要件定義で、画面の模型を作るのは、三つとも共通。

機能については、表現の方法が、
XP : ユーザーストリー ( のセット )
ICONIX : ユースケースパッケージ図
ウォーターフォール系 : 業務機能一覧、アプリケーション機能一覧など
など異なる。

まあ、どれも結局は、画面にすると、メニューになることが多いので、本質的には同じことをしているんだと思う。

概念クラスモデルと概念データモデル

アジャイルというか、オブジェクト指向系のやり方だと、要件定義では、概念クラスのモデル(模型)を作る。
ウォーターフォール系の要件定義では、「概念データモデル」とか データ指向のアプローチ (DOA) が多いと思う。

データモデルは、Entity ( 実体 ) と Relationship (関係) に注目する。クラスモデルは、Entity も対象にするが、それ以外の概念、例えば「口座振替」のように手続きのかたまりもクラスとしてモデル化することがある。

もっとも業務的には「口座振替」という手続きを実行した記録を残すので、これも Entity としてモデル化できる。

ようするに問題領域の用語集

私は、概念クラスモデルと概念データモデルが本質的に違うものだとは思っていません。問題領域の知識として用語(概念)を洗い出して、その関係を描けば、似たような図になるのが自然だと思っている。 あまり違ってしまっては困りますよね。同じ問題領域なのに。

ICONIX のようにドメインモデルとは問題領域の「用語集」である、というのが実践的な発想だと思う。

要件定義で重要なことは、役に立つソフトウェアの具体的なイメージを関係者で共有すること。
役に立つソフトウェアは、問題領域の正しく深い理解から生まれる。そのためには、問題領域を説明する「用語(概念)」を正しく捕まえること。

そのやり方は、クラス図でもER図でも用語集でも、どれでも良いと思う。
前に書きましたが、50音順の用語集よりは、クラス図なりER図のほうが、より豊かな情報を提供できるとは思います。(理解の不一致を見つけやすい)

ICONIXプロセスの本「ユースケース駆動開発実践ガイド」では、ドメインモデリングとデータモデリングは違うということは、結構こだわっているようですが。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< December 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM