分析から設計へのモデル変換などについてオブジェクト指向の世界(8)

» 2005年02月16日 12時00分 公開
[河合昭男,(有)オブジェクトデザイン研究所]

 建築家アレグザンダー(Christopher Alexander)は名前のない品質(QWAN)を建築で実践するための技法として「パターン言語」を提唱しました。第6回「名前のない品質とパターン言語」ではこのQWANについて、第7回は「パターンとパターン言語入門」と題して、パターン言語の紹介とそれがソフトウェアの世界に2大潮流を引き起こしたことをお話ししました。デザインパターンなどの「ソフトウェアパターン」とケント・ベックたちが提唱するXP(eXtreme Programming)をはじめとする「アジャイル開発」のルーツは、実はこのアレグザンダーのパターン言語だったのです。

 今回は話題を変えて「分析と設計」について考えてみたいと思います。オブジェクト指向分析・設計と呼ばれるようにシステム開発では分析と設計は隣り合わせですが、「分析(analysis)」と「設計(design)」は本来まったく別の概念であり、この間に無限のギャップを感じています……。

ソリューションとは問題の解決策

 システム開発の世界ではソリューションという言葉をよく使います。SIerの仕事は顧客にソリューションを提供することです。ところでこの“solution”という言葉の本来の意味は「問題に対する解決策、解答」です。顧客のビジネス実践上の問題を解決するものがソリューションです。顧客のビジネス上の問題認識もなくソリューションパッケージを提案することは顧客にとって無意味です。

 「ビジネスとは顧客の創造である」とはピーター・ドラッカーの有名な言葉です。ビジネスの目的は利潤極大化ではなく、利潤は顧客満足の結果として後から付いてくるものです。従ってビジネスの本来の目的が顧客満足にあるなら、情報システムは導入先のビジネス対象となる顧客(間接顧客)満足向上をサポートするものでなければなりません。この間接顧客はSIerからは顧客(直接顧客)のさらなる顧客であって直接見えませんが、ソリューションを考えるうえで最も重要な要素です。つまり間接顧客の満足が直接顧客の満足につながるわけです。

ALT 図1 顧客の顧客満足を目指す

 顧客満足を実現するためにビジネスの効率・品質向上のための解決策はいろいろ考えられます。情報システムによる解決策も一手段として強力でありいまや不可欠です。従って情報システム構築の前にまずビジネス成功のために解決すべき問題は何であるか(what)からスタートする必要があります。問題を分析すればその解決策はいくつか考えることができます。問題を解決するためのソリューションとなる情報システムを設計する(how)のも主要な選択肢の1つです。

ALT 図2 ソリューションは問題の解決策

オブジェクト指向分析・設計

 オブジェクト指向による開発プロセスを総称してOOAD(Object Oriented Analysis & Design)と呼びます。これはそのままオブジェクト指向分析・設計と訳されています。OOADの具体的なプロセスは標準化されてはいませんが、成果物はUMLで表記するのが一般的です。オブジェクト指向による一般的な開発プロセスを次に示します。

要件定義

 問題領域・業務を分析し、システム化すべき範囲を抽出して要件定義または要求仕様としてまとめる。要求には機能要求とパフォーマンスや信頼性などの非機能要求があり、機能要求はユースケースモデルで表す。非機能要求は一般的にはUMLで表すことができず、通常の文章で表す。

分析

 ユースケースごとに、それをオブジェクトの世界で実現するためのオブジェクトを抽出し、UMLのクラス図、相互作用図などで分析モデルを作成します。分析モデルは要求の理解が目的で、実装のことはまだ考えません。

設計

 分析モデルをインプットとし、開発環境と実行環境の制約の下にどのようにシステムとして実現するかを設計モデルとして表現します。設計モデルも分析モデルと同じくUMLのクラス図、相互作用図等で表現します。分析モデルとUMLのダイヤグラムは同じですが、設計では実装方法を表現します。

実装

 設計モデルを開発環境の制約の下にプログラミングし、実行環境で稼働可能なプログラムを作成します。

作業工程 要件定義 分析 設計 実装
作業目的
(作成モデル)
要求モデル 分析モデル 設計モデル 実装モデル
主要成果物
(具体例)
ユースケース図 クラス図
相互作用図
クラス図
相互作用図
ソースコード
プログラム 
オブジェクト指向による開発工程概要

モデル変換はwhat-how連鎖

 開発プロセスはモデル変換作業の連鎖です。開発の各工程でインプットとなるモデルを変換して成果物となるモデルを作成します。その成果物は次の開発工程のインプットとなるわけです。モデルとは与えられた問題を単純化して表現するものです。工程に渡されるモデルは何をしたいのかをその時点の認識レベルで表現するものです。従って、各工程の作業は前工程での認識を次工程で理解できるモデルに変換することです。与えられたwhatをhowに変換することです。成果物であるhowは次工程のwhatとなり、開発工程はwhat−howモデル変換の連鎖であるということができます。

ALT 図3 モデル変換はwhat−how連鎖

「分析」と「設計」の言葉の意味

 ここで一度「分析」と「設計」という言葉の本来の意味を考えてみましょう。分析という言葉の意味は、広辞苑(第4版)によると

 分析(analysis)→(1)ある物事を分解して、それを成立させている成分・要素・側面を明らかにすること。

とあります。もともと英語の“analysis”の訳語ですが英和辞典(プログレッシブ英和中辞典(第3版)から主要な意味を拾い出すと「分析、分解、解析」とあります

 次に、設計という言葉の意味は、広辞苑によると

 設計(plan;design)→(1)ある目的を具体化する作業。製作・工事などに当り、工費・敷地・材料および構造上の諸点などの計画を立て図面その他の方式で明示すること

とあります。もともと英語の“design”の訳語です。analysisは名詞ですがdesignは名詞と動詞が同じ単語です。英和辞典から主要な名詞の意味を拾い出すと「(1)設計図、(2)図案、(3)計画」とあります。

科学と工学

 分析は対象を分解して単純化し本質を見極めることであり、設計は人工物を合成するためにモデルを作ることです。「分析と設計」を「科学と工学」という視点で考えてみましょう。

 科学(science)は大きくは自然科学系と人文・社会科学系に分けることができます。科学の基本的方法は複雑で理解が困難な対象を単純な構成要素に分解し、分解された一部分を取り出して性質を調べて全体をその集積として理解することです。部分の切り分け方法により理解は異なります。

 プラトンの「パイドロス」(藤沢令夫訳、岩波文庫)の中で、主人公であるソクラテスはものの本質を人に話したり考えたりするのに「分割と綜合」という2つの方法の有効性を説いています。「綜合」とは「多様にちらばっているものを綜観して、これをただ1つの本質的な相へまとめること」で、それとは逆に「分割」とは「自然本来の分節に従って切り分ける能力をもち、いかなる部分をも、下手な肉屋のようなやり方でこわしてしまおうと試みることなく」うまく理解しやすい部分に切り分けることです。



 この方法は分析の基本的な方法、あるいは科学の基本的な方法と相通ずるものです。つまり分析とはものの本質を捉えることが目的であり、そのためには対象を、自然に逆らわずいかにうまく単純な構成要素に切り分けるかが重要です。

 一方、工学 (engineering) は物作りです。人工物を作ることです。ある程度複雑な物を作るためには設計が必要です。つまり、分析は対象を分解することにより単純化してその本質を理解することが目的であり、設計は人工物を合成するのが目的です。分析の対象は自然現象でも社会現象でもあるいは人工物でも構いません。分析対象が自然現象なら分析は自然科学の範疇(はんちゅう)で、社会現象なら社会科学の範疇です。分析が科学(science)の範疇であるのに対して、設計は工学(engineering)の範疇と考えることができます。

ALT 図4 科学と工学

 ソフトウェア開発に話を戻すなら、大きくは分析の対象がビジネスであり、設計の対象は合成すべき人工物である情報システムです。ビジネスの分析は自然科学ではなく社会科学の範疇に入るものであり、システム開発において要件定義を行うための分析作業は文科系の人、要件定義をもとに行う設計作業は工学系の人が得意とする分野かもしれませんね。


 今回はシステム開発プロセスで「分析・設計」と隣り合わせで使われるが、本来まったく異なる概念である「分析(analysis)」と「設計(design)」について考えてみました。分析は複雑で理解困難な対象を単純な構成要素に分解して本質を見極める科学(science)の範疇で、設計は人工物を合成する工学(engineering)の範疇です。システム開発で分析と設計の間には大きなギャップがあり、実際このモデル変換は大変な作業で、単純に機械的にできるものではありません。大学の学部でいえば分析は対象が自然現象なら理学部、対象が社会現象なら社会科学系の学部、設計は工学部くらいの差があるでしょうか。理工学部という科学と工学の橋渡し的な学部もありますが、分析から設計への変換作業はその範疇に入るものです。

 次回は「分類と分解」というテーマで考えてみたいと考えています。日常生活でも、あるいはシステム開発で行うモデリング作業にもこの類似した2つの概念が表れ混乱することがありますね。どのように違うのでしょうか?

 なお、現在、筆者主催のオブジェクト指向教育オープンコースを開催しています。詳細は有限会社オブジェクトデザイン研究所のホームページをご参照ください。皆さまとお会いできることを楽しみにしています。

プロフィール

河合昭男(かわいあきお)

 大阪大学理学部数学科卒業、日本ユニシス株式会社にてメインフレームのOS保守、性能評価の後、PCのGUI系基本ソフト開発、クライアント/サーバシステム開発を通してオブジェクト指向分析・設計に携わる。

 オブジェクト指向の本質を追究すべく1998年に独立後、有限会社オブジェクトデザイン研究所設立、理論と実践を目指し現在に至る。ビジネスモデリング、パターン言語の学習と普及を行うコミュニティ活動に参画。ホームページ「オブジェクト指向と哲学」 。

 『JavaデベロッパーのためのUML入門』(監修)。著書は『まるごと図解 最新オブジェクト指向がわかる』『まるごと図解 最新UMLがわかる』(共に技術評論社)、『明解UML−オブジェクト指向&モデリング入門』(秀和システム)。



「オブジェクト指向の世界」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ