オブジェクト指向で実現できる保守性・拡張性：保守性・拡張性に優れたシステムを作る（2）（2/3 ページ）

[野村佳弘，日立ソフトウェアエンジニアリング]

［2］ 上流工程における機能仕様の整理整頓の考え方

　ここでは上流工程において、似たような機能をまとめる考え方を見ていきます。まず最初にクラスがどのように導き出されるかを見てみましょう。

（1）概念からクラスへ

　 オブジェクト指向言語で必ず出てくるクラスとは、どのように導き出されるのでしょうか。設計、実装で出てくるクラスは、上流工程のシステム分析の工程で洗い出す必要があります。オブジェクト指向分析設計では、この上流工程に概念モデリングやユースケース分析があります。これらについては、本連載で説明していきます。

　それでは、どのようにクラスの基を探し出すのでしょうか。それは要件定義書や業務シナリオを基にして、実現したいシステムに存在する「概念」と「サービス」を分析することにより洗い出していきます。

　「サービス」については後ほどお話しするとして、ここでは概念についてお話しします。概念とは本質的な特徴を持たせるように抽象化を行った「もの」です。例えばレンタル商品管理システムでは、「田中さん」「伊藤さん」などを「会員」として抽象化し、「ビデオ」や「CD」などを「商品」として抽象化して、本質的な概念として定義します。概念は人間が定義するものなので、目的が違えば概念も違ってきます。

　概念には属性と操作があります。「会員」は「名前」「生年月日」などの属性を持っており、「年齢を取得する」などの操作があります。この属性と操作を検討していき、クラスとして定義していきます。

（2）上流工程の問題の解決：機能仕様に似たような機能が散在

　それでは、機能仕様に「似たような機能」が散在することを解決するためには、どのような考え方が必要なのでしょうか。オブジェクト指向分析では、まず概念というものを考えるとお話ししました。似たような機能を分析するためには、概念の汎化構造を分析します。

　概念の汎化構造とはどのような考え方でしょうか。ここでは概念を集合として考えて理解していきます。汎化構造は部分集合として考えられます。

　例えば、「田中さん」と「佐藤さん」という従業員がいるとします。「田中さん」は営業職で「佐藤さん」は技術職です。

図4 概念の汎化構造

　このとき、「田中さん」は従業員であり、営業職の従業員でもあるので、従業員の集合と営業職の集合に属します。「佐藤さん」は従業員であり、技術職の従業員でもあるので、従業員の集合と技術職の集合に属します。この様子を図で表すと、営業職と技術職は従業員の部分集合であることが分かります（図4）。

　この部分集合は汎化構造としてとらえることができるので、これをクラス図で表します。

　このように汎化構造を見つけ出すと、そこに似たような機能が存在します。「田中さん」「佐藤さん」は従業員なので「給料を計算する」や「勤続年数を計算する」などの共通的な機能があります。

　「勤続年数を計算する」は「田中さん」「佐藤さん」に共通する機能です。それに対し、「給料を計算する」は技術職と営業職では算出方法が違いますが、利用する側から見ると、技術職と営業職を両方とも従業員として扱い、「給料を計算する」という操作名で同じように扱えると便利です。

　似たような機能には次のようなものがあります。

（A）操作名は同じだが、機能は異なる

（B）操作名は同じで、機能も同じ

　そして、この汎化構造を明らかにし、技術職と営業職を従業員として扱い、「勤続年数を計算する」や「給料を計算する」などの操作名で同じように扱うことができることにより、利用する側のプログラムは技術職や営業職の区別を知ることなく、操作を利用することができます。この両方とも従業員として扱うというのがポイントになります。

　このような考え方を基にしてクラス図を利用して、機能や属性を整理整頓することにより、できるだけ単純な重複のない機能と属性の構造を明らかにできるように分析を進めていきます。