開発モデル編 -
第１４章 オブジェクトモデルのライフサイクル

Dropは、UMLで提唱される表記法をベースとした手法を提供し、さらに新たに独自モデルを拡張することで、ソフトウェア開発全般で使える実践的な方法論を目指している。しかしながら、Dropの着目点はこのようなUMLベースのモデルの提唱ということだけではない。オブジェクトを中心とするモデルの発展過程を開発プロセスの中で組み込んで解説することを重要視している。なぜなら、オブジェクト指向表記法を覚えたとしても、このようなモデルの発展過程に着目しない限り、実際の複数人でおこなうソフトウェア開発においては使えるものではないからである。

このようにソフトウェア開発過程で変化するモデルのことをオブジェクトモデルのライフサイクルと呼び、本章にてその意味と意義について解説する。

１４．１ 目的に応じて変化するオブジェクトモデル

ソフトウェア開発が進むにつれ、オブジェクトモデルは序々に発展を遂げる。ここでは、ソフトウェア開発の過程においてオブジェクトモデルの発展をモデル分割という概念から解説することにしよう。

ソフトウェアの開発過程を、Dropの提唱するモデル分割に当てはめると、下記のように４つのモデルに分割される。

現状認識モデル

対象問題を理解するためのモデルをいう。

戦略モデル

現状認識モデルによって得た知識を基に、理想のソフトウェアの要求をモデル化したものをいう。

要求モデル

戦略モデルに対して開発コストや期間を加味したソフトウェア開発の要求を基して作成したモデルをいう。

アーキテクチャモデル

ソフトウェア実装のためのモデル化をいう。

これらのモデルの必要性は「第２章 Drop構成用語集(開発プロセス用語編)」で解説しているが、これらのモデルを分ける意義について短くまとめると以下のようになる。

モデル化の基本はモデル化対象の目的にあった観点を定めることであり、観点が異なればモデルを構成するオブジェクトが異なるのは当然のことである

つまり、先に示した４つのモデルはソフトウェア開発過程でモデリングする目的と観点の変化に対応した名前を付与している。モデル化におけるもっとも重要なことは「モデル化する目的を常に頭に入れておく」ことである。これを実践するためにも、目的別にモデルを分類することは重要不可欠なことなのだ。(図14-1参照)

このように開発フェーズが進むにつれ目的と観点が変化する以上、モデル化の対象となるオブジェクトも徐々に変化することになる。ここでいう変化とは、オブジェクトの仕様が段階的に詳細化されるということだけでは済まない。４つのモデルの対象となるオブジェクトは基本的に異なるのである。しかしながら、完全に異なっているわけでもなく、前フェーズのモデリング結果は、後フェーズのオブジェクトの基礎となるものもある。

図14-1 目的によって観点が定まる

１４．２ モデルの変化をとらえる意義

従来のオブジェクト指向方法論では、このようなモデルの発展という概念はあるが、そのほとんどが詳細に欠けている。しかも、そのほとんどがシームレス(*注)なモデル変換を理想としているために、現状認識段階のモデルの無駄な贅肉が取れないまま実装段階まで発展してしまい、オブジェクトの数が不必要にふくらみ、オブジェクトの存在目的も定まらなくなってくる。このことが原因となって分析フェーズでの分析作業の停滞、設計フェーズでのモデルの大幅な見直しといった、深刻な状況を引き起こすことになりかねない。

そもそもオブジェクトを抽出するためには、オブジェクトが存在する場(フィールド)に明確な目的がなければならにのである。その場をDropでは４つに分類している。

オブジェクト指向分析・設計における失敗要因は、オブジェクトの存在する場を明確に定義せず、様々な目的を混同させた場の中からオブジェクトを探し出そうとすることから起こるものである。

Dropにおけるオブジェクトのシームレス性とは、分析から実装まで首尾一貫した表記法が提供するということであり、現状分析から実装まで、同じオブジェクトを段階的に詳細化するという考えは持っていないのである。

(*注) OMGによるオブジェクト指向方法の比較では、モデルの発展方法を大別すると、追加工程と変換工程があり、追加工程はシームレスであり追跡性を維持できると報告されている。

１４．３ オブジェクトモデルのライフサイクルとDrop開発チームとの関係

図14-2は４つのモデルとそのライフサイクルを示し、それがどのようにDrop開発チームと関わっているのかを示す図である。Dropは図のように、現状認識モデルと戦略モデルを方法論の対象としていない。よって、実世界のオブジェクトモデル化については何の方法も示していない。Dropの範囲は、ソフトウェア要求から要求モデルを作り出すことから始まる。これは、図に書いてあるように、開発するソフトウェアの範囲を定めた上で、理想のソフトウェア要求を定めることである。この作業の中心となるのがADGであり、対応するフェーズが問題領域分析から開始されるADG開発サイクルとなる。

一方、ODG開発サイクルは、ソフトウェアアーキテクチャのモデルがベースとなる。よってそのアプローチは、既存資産のソフトウェアコンポーネントやフレームワークなどをベースとして、どのようにADG要求を実現するかというボトムアップ的なアプローチがなされる。

ADG開発サイクルをODG開発サイクルと対比させて述べるならば、そのアプローチはトップダウンである。なぜなら、アプリケーションの要求がベースとなり、それをどのようにアーキテクチャモデルへ落とすかということが最大の関心事なのである。

このADGによる要求ありきのトップダウンアプローチとODGによるソフトウェアアーキテクチャありきのボトムアップアプローチがお互いに牽制しあいながら、両者の接合点を探ることで、要求を満たしながら最良の方法で実装されることになり、良質なソフトウェアを生み出すことになる源泉となる。

図14-2

１４．４ オブジェクトモデルの区別

ここで、第２章で取り上げた解説により、ソフトウェア開発過程で観点に併せて変化するオブジェクトモデルの区別について明確に示そう。

現状認識モデル

システムを開発する際には、まず問題領域の現状を理解することから始まるだろう。このように問題領域の理解のためにオブジェクトを使ってモデル化したものを現状認識モデルという。

現状認識モデルにおいて重要となる点は、問題を深く理解したかどうかということである。

戦略モデル

現状認識モデルに企業戦略を加えた理想的なモデルを戦略モデルと呼ぶ。

戦略モデルとは、問題領域に対する理想的なモデルを作り上げることであり、長期的視野で企業戦略をモデルに含まなければならない。よって戦略モデルは、予算や期間を考慮しない理想のモデルのことをいう。

要求モデル

戦略モデルを現実的な側面である開発コストと開発期間により吟味したシステム用件定義がなされ、その用件定義に基づいたモデルを要求モデルと呼ぶ。

要求モデルは、ソフトウェア領域に依存しない問題領域に対する要求の本質部分をモデル化した概念的なオブジェクトモデルであり、データ管理とシステムの本質的な振る舞いに視点をおいているものである。

アーキテクチャモデル

アーキテクチャモデルは、要求モデルを受け入れるために既に準備されたソフトウェア領域のモデルだと考えてよい。つまり、要求モデルという概念的なモデルをソフトウェアモデルに落とし変えるための作業が必要となるわけである。

オブジェクトモデルのライフサイクル図は図14-3に示す。この図のように、戦略モデルから要求モデルに落とす際にシネマスコープモデルが使われる。シネマスコープモデルは要求のモデル化が主な目的である。また、要求モデルからアーキテクチャモデルに落とし込む際に、再利用基盤モデルのクラスレイアカテゴリ図を使うことになる。再利用基盤モデルとは、企業における再利用部品を構築する基盤を形成するためのモデルのことである。

またこの図には書かれていないが、システム構造モデルについても要求モデルからアーキテクチャモデルに落とし込む際に使われる。では、静的構造モデルと動的構造モデルはどのようなタイミングで使われるのだろうか？実は両モデルともあらゆる段階で多用されるのである。

図14-3 オブジェクトモデルのライフサイクル

表14-1は、Dropの対象となる要求モデルの特徴を理解するために、現状認識モデルと戦略モデルを要求モデルの比較対照としている。

表14-1 現状認識モデル、戦略モデル、要求モデルの比較

	現状認識モデル （Reverse engineering）	戦略モデル （Forward engineering）	要求モデル （Requirement Model）
主な目的	対象問題の理解のためのモデル化	戦略を含む理想のモデル化	システム要求に基づたコストと期間を加味してモデル化
使い方	現状理解	戦略の理解	要求の理解
特徴	対象問題を理解するために、客観的な視点で今ある姿を描く	ソフトウェア開発における企業戦略を含みこむ理想像を描いたもの	本質的な要求を反映したオブジェクトだけが存在する。 システム境界が明確
発見フェーズ	Drop範囲外	Drop範囲外	問題領域分析
オブジェクトの例	仕訳、勘定科目、顧客 端末、入力担当者、月次更新	仕訳、勘定科目、顧客 端末、入力担当者、日時更新、日時集計表、予算対比	仕訳 勘定科目 顧客 日時集計
モデル変換	対象問題の理想像を含むことで戦略モデルとなる	具体的な開発期限と開発コストを加味することで要求モデルとなる	クラスライブラリなどによる実装方式を具体化することで、アーキテクチャモデルとなる
対象者	システム分析者 ユーザ	ユーザ システム分析者	ユーザ システム分析者 コンポーネント分析者

表14-2にDropの対象となる要求モデルとアーキテクチャモデルの比較を示す

表14-2 要求モデルとアーキテクチャモデル

	要求モデル （Requirement Model）	アーキテクチャモデル （Data,View,Process）
主な目的	システム要求に基づく本質部分のモデル化	ソフトウエア実装のモデル化
使い方	要求の理解とモデル化	ソフトウエア構造理解とモデル化
特徴	本質的な要求を反映したオブジェクトだけが存在する。 システム境界が明確	ソフトウエア領域で表現されるオブジェクトが対象となる
発見フェーズ	問題領域分析	クラス分析 クラス設計 システム共通設計 アプリケーション設計
オブジェクトの例	仕訳 勘定科目 顧客	ウィンドウ 配列、リスト、仕訳 タスク、共有メモリ
モデル変換	クラスライブラリなどによる実装方式を具体化することで、アーキテクチャモデルとなる
対象者	ユーザ システム分析者 コンポーネント分析者	システム設計者 システム分析者 コンポーネント分析者 システム設計者、コンポーネント設計者

この記事のトップへ