コンセプト編

第１章　Drop構成用語集(オブジェクト指向用語編)

１．１　オブジェクト指向用語編

Dropの基本コンセプトを学ぶうえで、Dropの解説で使われるオブジェクト指向用語の定義と用語同士の関係を知ることは重要である。Dropでは、ここで解説される用語を基に開発プロセスが構成されている。さらに、Dropで使用する用語を学ぶことは、オブジェクト指向開発における用語の意味をソフトウェア製品に特化せずに学ぶことができるだろう。 　オブジェクト指向用語編の全体像は図1-1のようになる。

図1-1　オブジェクト指向用語

１．２　コンポーネントとカテゴリ

　コンポーネントは「クラス利用の視点」によりオブジェクトを再利用する抽象的な単位をいう。一方、カテゴリは「クラス構築の視点」によってクラスを役割別、再利用範囲別にグループ化する単位である。

図1-2　コンポーネントとカテゴリ

コンポーネント

カテゴリ

　問題領域からクラスを抽出する際に、クラスの再利用度と役割という観点で１つ以上のクラスをグループ化したものを言う。クラス構築の際にはどのようにクラス同士が関連を持ち、どのレイアに位置するべきなのかを分析・設計する必要がある。Dropでは、このようなカテゴライズを再利用基盤モデルのクラスレイアカテゴリ図を使って行う。
　ここで、辞書アプリケーションを例に、カテゴリと再利用基盤モデルによるカテゴライズのについて解説する。(図1-3参照)このアプリケーションに「同義語検索」コンポーネント必要とされたとしよう。コンポーネントユーザ（アプリケーション開発者）からコンポーネントを見ると、検索ボタンと入力フィールド、表示リストボックスなどのクラスと、その使い方が見えるだろう。

図1-3　コンポーネント提供者は、再利用基盤モデルを使ってクラスをカテゴライズする

　カテゴリとは、コンポーネントを提供の視点でによって見えてくるものだ。コンポーネント提供者は、図1-3で示すように、同義語検索コンポーネントを構成するクラスのデザインを考え、クラス群毎にカテゴライズする。このカテゴライズは、開発したクラスを再利用基盤モデルのクラスレイアカテゴリを使って、下記のように役割別に分類するものである。これによって、クラスが再利用しやすい単位に分類され、まとめられる。このように再利用基盤モデルを使うことによる効果は、コンポーネント間の独立性が保たれ、保守性が向上することである。

		意味
再利用レイア	Generic	アプリケーションに特化しないレイアである。このレイアのサブレイアとして、マシンに依存・ 処理依存という分類をする場合もある。このレイアに存在するクラスは最も再利用性が高い
	AppParts	アプリケーションに特化しているが、類似アプリケーションに再利用することができるクラスや、 システム共通の枠組みとして作成されたレイアである。
	App	基本的に再利用を考慮せずに設計するレイアである。
役割レイア	View	View（見え方）に関係する。表示関連の処理を行うクラスである。
	Process	処理や状態を主体とするクラスである。
	Data	データ処理を主体とするクラスである。

表1-1 クラスレイアカテゴリの解説

[表1-1の解説]

• クラスレイアカテゴリの再利用レイアは、企業またはグループで個々のレイアの範囲を決める必要がある。
• クラスレイアカテゴリの役割レイアを別名VPDレイア（またはVPD構造）と呼ぶ。
• カテゴリは二重線の長方形で表される
• クラス１個でカテゴリをなすものは、クラス名を図中に直接書いてよい。
• カテゴリ間の点線矢印はカテゴリの依存関係を示す

１．３　パッケージ

　アプリケーションをユーザにリリースする際や、コンポーネントをコンポーネントユーザにリリースする際にまとめるための論理的な単位をいう。パッケージは、それぞれの開発言語が提供する物理的な提供形態にあわせて提供するソフトウェアの保守性や拡張性を考慮しながら単位が決められる。Dropのコンポーネント開発チームODGでは、このパッケージを単位として開発サイクルが定められる。
　たとえば、開発言語がC++の場合は、１つ以上のライブラリファイルがパッケージとなる。Javaでは１つ以上のpackageまたは１つ以上のzipファイルやjarファイルが対応する。

図1-4　パッケージ

１．４　フレームワーク

　コンポーネントは、「クラス利用の視点」による再利用可能なクラス群のことであることを先に述べた。一方、フレームワークとは、アプリケーションを構築するための骨格を提供するコンポーネント群のことをいう。また、フレームワーク自身も低レベルなコンポーネントを再利用して開発されることも重要なことである。

図1-5　フレームワークとコンポーネント

フレームワークとコンポーネントの違い

フレームワークの種類

１．５　アプリケーションとシステム

　開発するアプリケーションが巨大な場合や、問題領域のアプリケーションをユーザが利用するフェーズが時間的に分割されたりする場合などは、アプリケーションを統合するための機構（システム）が必要となる。この場合、アプリケーションはシステムが提供する何らかの仕組みにより、統合的な環境を提供することになる。Dropでは、この「アプリケーション」を統合する仕組みを「システム」と呼ぶ。
　Dropの利用者は、開発ターゲットに併せて「アプリケーション」を「ツール」と呼び変えてもよいし、必要ならば、システムにもう一つ階層を持ちサブシステムを設けてもよい。

図1-6　アプリケーションとシステム

１．６　アプリケーションユーザとコンポーネントユーザ

　Dropによるソフトウェア開発を考えるとき、２つのユーザが重要となる。１つはアプリケーションユーザであり、もう一つはコンポーネントユーザである。このユーザという言葉は、ソフトウェアを開発する際の視点を意味するものと考えてよい。

• アプリケーションユーザ.......アプリケーションの使い方が知りたい
• コンポーネントユーザ　.......コンポーネントの使い方が知りたい

　上記のような視点を持つユーザの要求を達成するためには、「アプリケーション提供の観点」と「コンポーネント提供の観点」という２つの観点を併せ持つことが、開発者にとって重要な考え方となる。
　Dropでは、この２つの観点をまずは１人の技術者に持たせることを、開発プロセスにおける戦術の基本コンセプトとしており、 徐々にそれぞれの観点を持つ２つのグループを育てていくことが、Dropの提唱する企業（組織）戦略である。

• ADG(Application Development Group)
  • 要求される責務.... アプリケーションの仕様に責任を持つ
  • 要求される視点.... システムの境界を定める。
  • 要求される知識と技術.... 対象システムの専門知識を持ち、システムを構築する技術を持つ。
• ODG(Objects Development Group)
  • 要求される責務.... コンポーネントの仕様に責任を持つ
  • 要求される視点.... コンポーネントの境界を定める
  • 要求される知識と技術.... ソフトウェアプラットフォームに対する専門知識やコンポーネント構築技術を持つ。

図1-7　２つのユーザ

　先に述べたように、ADGとODGは１人の技術者の観点でもある。 図1-8のようにソフトウェア開発者は、ADGとODGの観点をバランスよく備え持ち、両観点を必要に応じて切り替えながら思考することが必要なのだ。

図1-8　ADGとODGとは一人のオブジェクト技術者の観点でもある

１．７　コンポーネントユーザを考える

　ここで図1-7をもう少し解説しよう。アプリケーションを提供するADGは、アプリケーションを開発する際にいくつかのコンポーネントを利用することになる。
コンポーネントを提供するODGは、コンポーネントを開発するにあたり、その下位層にあたるコンポーネントを再利用するだろう。このように、ほとんどの「コンポーネント提供者」は「コンポーネントユーザ」となる。

図1-9　コンポーネント提供者(ODG)はコンポーネントユーザでもある

１．８　アプリケーション開発とコンポーネント開発

　オブジェクト指向開発における理想はコンポーネントを組み合わせてアプリケーションを作ることである。この理想は、いわゆるコンポーネントパラダイムの実現である。(図1-10参照)
　しかしながら、現状では理想と現実のギャップは大きい。実際には、コンポーネントを組み合わせただけでは、簡単なプロトタイプアプリケーションは作ることができても、本格的にユーザが満足できるレベルのアプリケーションを開発するのは困難なのである。なぜなら、アプリケーションに特化した要求項目を実現するコンポーネントを既存コンポーネントを張り合わせることが困難であることが多いからだ。
　このアプリケーション開発におけるコンポーネントの融合ができにくいという問題の本質は、以下の２点からくる。

• オブジェクト指向を含めた現状のテクノロジーでは、柔らかなコンポーネントを開発することが難しく、コンポーネントにアプリケーション要求を組み込むインターフェースをもたせることができにくい。
• ユーザ要求の中には、それを実現するための中枢部にアーキテクチャが存在する。そのようなアーキテクチャを実現するクラスは一般に、クラス間の結合度は高くなってしまう。よって独立性の高いコンポーネントを作ることができにくい。

図1-10　理想のオブジェクト指向開発

　Dropは、ADGとODGという観点をベースとする開発プロセスによって、現実的なコンポーネント利用モデルを有している。それは、図11-1に示すように、システム要求からシステムアーキテクチャを設計し、その設計のなかでコンポーネントとして抽出可能な部分を取り出すということから始まる。その後、システムからうまく取り出せたコンポーネント部分は、コンポーネント開発サイクル(ADGの視点)によって設計・実装し、コンポーネント化できずに残ったアプリケーションの中枢部分をシステム開発サイクル(ADGの視点)によって設計・実装することになる。
　このDropにおける開発モデルの思想を簡単に説明すると。

「システム開発対象範囲からコンポーネントとして実現可能な部分を抽出することで、システムの骨格部分をできるだけ小さくする。」


　ということである。上記の思想を持つことによって、システムの理解性を高めることができ、さらには、再利用コンポーネントを増やすこともできるようになるだろう。このような現実なオブジェクト指向開発をサポートする手法の基本となる考えが、ADGとODGという開発者の持つべき観点である。

図1-11　Dropのオブジェクト指向開発の考え方

１．９　アプリケーション開発とフレームワーク開発

図1-12　フレームワークの再利用