開発フェーズ編 -
第２６章　コンポーネント分析

２６．１ 目的

コンポーネント分析フェーズでは、ソフトウェア資産としてのクラスライブラリ（再利用コンポーネント）を計画的に構築するための分析を行う。

２６．２ 作業ドキュメント

コンポーネント分析で作成するドキュメントの一覧を示す。

ドキュメント名	解説	様式番号
コンポーネント開発計画書	新たに再利用コンポーネントの構築が検討される時に作成する計画書	5-01
パッケージ開発環境標準	コンポーネント開発に必要となる標準的なルールを定めたもの。	5-02
パッケージ利用解説書	コンポーネントを配布提供する単位（パッケージと呼ぶ）毎にクラスライブラリの使い方を解説したもの。この単位をフレームワークとする場合は、フレームワーク仕様書という名前になる。	5-03
パッケージ仕様書	コンポーネントを配布提供する単位（パッケージと呼ぶ）毎にクラスライブラリの設計方針やオブジェクト設計について記述されたもの。	5-04

２６．３ 作業項目の解説

コンポーネント分析フェーズは、ODGを主体とする開発サイクルの分析フェーズである。コンポーネント分析は、オブジェクト指向技術を使ってソフトウェア資産を構築するための基盤となる再利用モデルを形成し、発展させることにある。それは以下の２つの活動からなる。

1. システム開発の要求に応じて、開発を行うための分析
   開発システムの問題領域分析やシステム共通設計フェーズにODGのメンバが参加することにより、システムの中から再利用コンポーネントを見つけだし、その構築方法について、既存のコンポーネントを加味しながら分析を行う。
2. 再利用コンポーネント構築のための基盤形成
   強力なコンポーネントを構築するための抽象的な再利用モデルの構築。および、コンポーネント構築のためのルールやポリシーをその時代のニーズにあわせて拡張・改訂する。

コンポーネント分析フェーズでは、「再利用コンポーネントワークショップ」によってコンポーネント構築計画が具体化され、ODGにより分析作業が実施される。

• 再利用コンポーネントワークショップ」

再利用コンポーネントの開発計画

従来では、ソフトウェア開発の中で作成されたコンポーネントは、他のプロジェクトで再利用するための工夫があまりなされず、オブジェクト指向による開発であっても再利用資産を構築することは困難であった。 Dropは、このような問題を解決して企業レベルで再利用資産を効率的、計画的に構築するための方法論である。

再利用コンポーネントの開発計画とは、企業レベルの再利用資産を構築するための戦略をトップダウンで計画することである。この作業は、「再利用コンポーネントワークショップ」の参加者により提案がなされ、ワークショップの中で新規のコンポーネント構築について審議されることで具体的な計画として承認される。

ODGは、この計画を基に再利用コンポーネントを構築し続ける専門集団である。ODGの具体的な活動計画は再利用コンポーネントワークショップで審議され、決定される。また、個々のシステム開発で要求されるコンポーネントについてもこのワークショップによって審議がなされる。

「再利用コンポーネントワークショップ」では、以下のような内容について議論される。

• 今後のソフトウェア開発で必要とされるクラスは何か？
• 必要とされているクラスが、すでに市販製品としてあるか？
• 必要とされるクラスを自社で開発すべきか、市販製品を使うべきか？
• 市販製品を使う場合は、その製品を自社の再利用コンポーネントとして取り込めるか？
• 調査期間はとるべきか？
• プロトタイプの必要性はあるか？
• プロトタイプの開発期間は？
• 全体の開発期間はどのくらいか？
• どのプラットフォーム（OS、GUI等）に構築すべきか？
• 特定のプラットフォーム（OS、GUI等）に依存すべきか？
• どの言語で構築すべきか？
• どの言語製品で構築するか？
• 言語製品に依存すべきか？
• 基本となるクラスライブラリは必要か？
• 基本となるクラスライブラリは何にするか？
• 再利用ターゲットをどこにするか？
• 将来的な拡張方針は？
• 既存コンポーネントとの整合性に問題がないか？
• 既存コンポーネントとの整合性に問題がある場合、それをどのように解決するか？
• どのような時にバージョンアップが必要となるか？
• どこで保守管理すべきか？（ODGの資産とするか、ADGの資産とするか）

コンポーネント要求分析

コンポーネント要求分析は、コンポーネントに対する要求を明確にし、その要求からオブジェクトを見つけだす作業である。

コンポーネント要求条件の作成

コンポーネントに対する要求は、ADGのシステム開発から出される要求と、ODGの再利用コンポーネント構築活動の中で生まれたアイデアを元にする場合がある。コンポーネントの要求条件の定義は、それらの要求やアイデアの中から、コンポーネントとして提供すべき本質的と思えるサービスを箇条書きにしたものである。

この文章は、コンポーネント開発計画書ドキュメントの「目的」、「機能概要」、「コンポーネント概要」などに元になる。

コンポーネント要求モデルの作成

コンポーネント要求モデルの作成では、シネマスコープモデルとDRO手法が使われ、具体的な実現手段の決定にはプロトタイプが使われる。

コンポーネント要求分析においてシネマスコープモデルを作成する際に重要になることは、コンポーネント化についてのアイデアや、ADGからの要求として整理されたコンポーネント要求条件を、具体的にシナリオとして定義できるか？また、それが実際のソフトウェアとして有効なものなのか？ということである。

よって、コンポーネント要求モデルは、下記のような手順で進められる。

自分のコンポーネントについてのアイデアやADG要求実現のコンポーネント化のアイデアが、実現のイメージまで具体化されており、それをシナリオとして人に話せるレベルまで達しているかどうかをシナリオ記述によって確認する。このシナリオがしっかりしてくれば、シナリオ毎にシーンを作成し、オブジェクトの候補を探し出す。そして、DRO手法を用いてオブジェクトの候補を具体的な構造を持つクラスとして洗練させる。また、これらの作業と並行させて、そのアイデア実現が正しい方向へ進むように小さなプロトタイプによりモデルを評価し、よりより構造に改善していくようにする。

1. シネマスコープモデルにより要求オブジェクトの候補を見つける
   • コンポーネント要求からシナリオ表を作成する
   • シナリオからシーン図を作成する
   • シーン図からシーン統合図を作成して、オブジェクトの候補を得る
2. DRO手法を使って、要求オブジェクトの詳細化を図る
   • オブジェクトの候補をPD( Process、DataManage)レイアに分類する
   • DRO手法に従って、Processの振る舞いと、データ管理（DataManage）オブジェクトを洗練化を行う。
3. 小さなプロトタイプを数多く作成し、コンポーネント要求モデルを、実装レベルで評価する。
   コンポーネント構造やソフトウェアアーキテクチャを検証したり、コンポーネントに対するアイデアそのものを検証するために、数多くの小さなプロトタイプを作成してテストする。

再利用基盤モデル分析

「再利用基盤モデル」の中で解説したクラスレイアカテゴリ図を使って、新たに作成するクラスがどのカテゴリに属し、どこのレイアスペースに入れるべきかの検討を行う。これは、再利用基盤モデルに一定の秩序を与えるための分析である。この分析により、コンポーネント間の依存関係を低くし、独立性を高めるための指針を立てることができる。

図26-1 クラスレイアカテゴリ図

クラスライブラリ分析

既存のクラスライブラリの中に新規作成クラスをどのように位置付けするかを具体化するために以下の検討をおこなう。

• 新規開発するクラスをクラスライブラリのどこに位置づけるか？
  クラス階層のどの位置にクラスを構築すべきか、そのクラスの特性や役割から判断する。
• クラス名は適切か？
  クラスライブラリの中でクラス名の付与が理解し安く一貫性があるかを検討する。
• クラスライブラリの拡張性は保てるか？
  新規作成したクラスによってクラスライブラリの拡張が損なわれないか検討する。
• メソッド・インタフェースが統一されているか？
  クラスライブラリの中で統一的操作またはプロトコルとして提供されているようなメソッド名を新規作成クラスの中のメソッドとして定義する場合は、メソッドのもたらす機能がクラスライブラリの中のメソッドインタフェースと矛盾していないかを十分に調査する。
• 新たなメソッド・インタフェースは必要であるか、適切であるか？
  新規作成クラスの中に新たなメソッド・インタフェースを定義する場合、その必要性と有効範囲について検討する。
• クラスの独立性は保てるか？
  クラスレイアカテゴリ分析で計画された独立性が保てるように関連するクラスとスーパークラスについての基本方針を立てることができる。
• 他のクラスと比較してメソッド名に一貫性があるか？
  メソッド名の付与について他のクラスとの統一性と一貫性があるかを検討する。（たとえば、既存のクラスはprintメソッドに標準ストリームに出力するということで統一されているにもかかわらず新規作成クラスでは、printメソッドにＧＵＩ画面に描画するという機能を割り付けてしまうというようなことがないようにする。）
• 可視性は十分に検討されているか？
  単独のコンポーネントとしては成立しないクラスに対して可視性をもたらす設計がなされていないか調査する。

パッケージ計画

パッケージ計画とは、開発するクラスの提供単位を決めることである。パッケージは、１個以上のクラスカテゴリから構成される。具体的には、開発言語の１個以上のライブラリファイル(Javaの場合はclass、zip、jar、C++の場合はリンクライブラリファイル)によって提供される。

パッケージには以下のような特徴がある。

• パッケージはメンテナンスするための論理的な単位である。
  パッケージにはメンテナンスのためのバージョンが付加され、このバージョンによって内部のクラスが管理される。
• パッケージはクラス利用者がクラスライブラリを理解する単位となる。
  利用者のために、パッケージ毎に「パッケージ利用解説書」を作成する。このドキュメントでは、パッケージに含まれるコンポーネントの提供目的や利用方法について細かな解説がなされる。具体的には、パッケージの内容によって「ＸＸＸフレームワーク利用解説書」「ＸＸＸコンポーネント利用解説書」などといったドキュメント名が付けられる。

パッケージの単位が決まると、そのパッケージに対する開発期間が定められ、コンポーネント設計・実装フェーズによって開発が進められる。

パッケージ開発環境標準の作成

パッケージの単位が定まる段階では、開発プラットフォーム（OS、GUI）や開発言語はコンポーネント開発計画にて決定されているはずである。ここでは、決定された開発プラットフォームや開発言語に合わせて「パッケージ開発環境標準」を作成する。これは、コンポーネント実装時に管理面で必要となる下記のようなルールである。このルールは、開発言語等に依存するが、Dropにおける標準的なルールを示すので、それを実装言語にカスタマイズして利用するとよいだろう。

一度決定したルールは、その開発環境で新たに作成するパッケージにも採用することが重要であり、他の開発環境ともできるだけ統一を図るよう調整しなければならない。

ファイル名付与規約

ソースファイル名（ヘッダファイル名）

ファイル名は、カテゴリ分類が可能で、かつ、分かりやすい名前にしなければならない。
例）
カテゴリ名を１文字または２文字使用した名前とする。一つのソースファイル（またはヘッダファイル）には、公開されたクラス１つといくつかの非公開のクラスがセットで格納される。

その他リソースファイル

プログラム構築時や実行時に必要となるリソースファイルについて、そのファイル名付与規約を作成する。

システムリソース管理規約

統合化のために事前に環境を整備

開発当初は個人でソースを管理することになるが、最終的にパッケージというリリース単位を作成する際に、支障のないように事前にパッケージ結合後の開発環境構造を設計しておく。 最近では、ビジュアルな開発環境ツールが発達してきたが、このようなツールを利用する際には、そのツールを個人で利用する場合と、チーム全体で統合して利用する場合の２つのパターンを前もってルール化する。

コーディングルール

クラス名（公開）

カテゴリ単位に２文字程度（大文字＋小文字）のプレフィックス に続き大文字で役割の名前を用いる。 クラス名は、理解しやすく、役割が明確にわかる名前とする。
よい例） AbLine,AbText,OwLine,OwText
悪い例） abline（小文字で始まっている）、getBuffer（機能名になっている）

クラス名（非公開）

プレフィックスにアンダーバー（_）を用いる。
よい例） _LineBuffer
悪い例） LineBuffer（公開クラスとの区別がつかない）

属性名

小文字で始まるわかりやすい名前とする。
例） firstName

公開メソッド名

小文字で始まる動詞、または動詞＋名詞の組み合わせ。ただし、名詞にクラス名を含める必要はない。
例） draw,drawLine

非公開メソッド名

プレフィックスにアンダーバー（_）を用いる。
例） _setline
※ベースとするクラスライブラリが大文字から始まるメソッド名を持つ場合もある。このような時は、ベースとなるクラスライブラリに準拠する。

２６．４ チェックリスト

コンポーネント分析フェーズの作業過程や完了時に、作業内容の評価を行う材料として以下のチェックリストを示す。

• 再利用範囲を予測しているか？
  継承を初めとするオブジェクト指向メカニズムは、予測された再利用性・拡張性の範囲の中で再利用性と拡張性を高めることに適している。これを「再利用の傘」とここで呼ぶことにする。再利用の傘の広がりの中にある問題については非常によい効果を発揮する。しかし、再利用の傘の外にある問題に対しては、オブジェクト指向によって従来の方式よりも堅い構造を定義することが逆に弱みとなってしまう。
  この問題を緩和するには、コンポーネント分析フェーズで再利用範囲やその方向性を明確にすることが重要になる。また、コンポーネント設計では、コンポーネント間の独立性を高める設計をできるだけ高めるようにしなければならない。この面で継承は万能ではない。継承はクラス間の依存性を高め、再利用の傘の広がりを狭めることもある。よって、関連を使った設計をうまくミックスさせなければならない。
• コンポーネントの使われ方に集中しているか？
  コンポーネント分析が対象とする問題領域は、システム分析のそれよりもソフトウェアの世界に近い（ソフトウェアにしか存在し得ない問題）ことが多いため、コンポーネント分析は、コンポーネント設計との作業と、ごちゃ混ぜになってしまうこともある。このような時は、コンポーネント分析は、「なにを作るか」と「再利用資産としてのコンポーネントの位置づけ、あり方」に集中して分析を行うようにするとよい。

この記事のトップへ