*begin*back*foward*end*contents

コンセプト編 -
第1章 Drop構成用語集
(オブジェクト指向用語編)

1.1 オブジェクト指向用語編

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

sorry this is image
図1-1 オブジェクト指向用語

1.2 コンポーネントとカテゴリ

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

sorry this is image
図1-2 コンポーネントとカテゴリ

コンポーネント

コンポーネントの構造は、1個以上のクラスで構成される再利用可能な集合を意味しており、下記のような再利用範囲に着目したレベル分けが可能である。

  1. 汎用 (Generic) ....汎用性の高い再利用部品
  2. システム共通(App Parts)....同一システムや類似システムで再利用可能な部品
  3. アプリケーション内再利用(App )....アプリケーション内や個人の中で再利用される部品

このレベル分けで注意すべき点は「アプリケーション内再利用」である。これは、コンポーネントという論理的な単位にソフトウェアをまとめたもので、1個以上のクラスで構成される。「アプリケーション内再利用」に属するコンポーネント化の目的には、コンポーネント化された論理的な単位が、再利用されることだけを期待するのではなく、コンポーネント化することによって細かな情報が隠蔽されることにより、システム全体の見通しが良くなることに期待することにある。つまり、再利用ではなくオブジェクトを利用する単位として考えることができる。

この考えは、コンポーネントを切り張りしながら開発するようなビジュアル開発環境に欠かせない考え方である。

コンポーネントを利用する開発者をDropでは、コンポーネントユーザと呼ぶ。 コンポーネントを提供する上で重要となる点は以下の2つであり、Dropはこれを重視した開発プロセスを提供するものである。

  • コンポーネントユーザにとってコンポーネント仕様を明らかにしているか。
  • コンポーネントの再利用情報に、不必要なクラスや実装に関わるメソッド等が隠されているか。

つまり、コンポーネントという用語は、再利用ソフトウェア部品を使う際に、その部品の提供するサービスを実現するインタフェース(メソッド)の概念的な集まりをいう。コンポーネントの物理構造は、ひとつ以上のクラスで構成されるかもしれない。しかし、コンポーネントユーザにとってみるとクラスの物理構造など関係はなく、必要なサービスを利用するためのオブジェクトとインタフェースの利用法だけがわかればよいのである。このような観点からクラスを見ることが「クラス利用の視点」であり、この視点によってコンポーネントという概念的な単位が明確化されるのである。Dropでは、この視点にフォーカスしたドキュメントをコンポーネント仕様書と呼ぶ。

カテゴリ

問題領域からクラスを抽出する際に、クラスの再利用度と役割という観点で1つ以上のクラスをグループ化したものを言う。クラス構築の際にはどのようにクラス同士が関連を持ち、どのレイアに位置するべきなのかを分析・設計する必要がある。Dropでは、このようなカテゴライズを再利用基盤モデルのクラスレイアカテゴリ図を使って行う。

ここで、辞書アプリケーションを例に、カテゴリと再利用基盤モデルによるカテゴライズのについて解説する。(図1-3参照)このアプリケーションに「同義語検索」コンポーネント必要とされたとしよう。コンポーネントユーザ(アプリケーション開発者)からコンポーネントを見ると、検索ボタンと入力フィールド、表示リストボックスなどのクラスと、その使い方が見えるだろう。

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

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

表1-1 クラスレイアカテゴリの解説
意味
再利用レイア Generic アプリケーションに特化しないレイアである。このレイアのサブレイアとして、マシンに依存・ 処理依存という分類をする場合もある。このレイアに存在するクラスは最も再利用性が高い
AppParts アプリケーションに特化しているが、類似アプリケーションに再利用することができるクラスや、 システム共通の枠組みとして作成されたレイアである。
App 基本的に再利用を考慮せずに設計するレイアである。
役割レイア View View(見え方)に関係する。表示関連の処理を行うクラスである。
Process 処理や状態を主体とするクラスである。
Data データ処理を主体とするクラスである。
[表1-1の解説]
  • クラスレイアカテゴリの再利用レイアは、企業またはグループで個々のレイアの範囲を決める必要がある。
  • クラスレイアカテゴリの役割レイアを別名VPDレイア(またはVPD構造)と呼ぶ。
  • カテゴリは二重線の長方形で表される
  • クラス1個でカテゴリをなすものは、クラス名を図中に直接書いてよい。
  • カテゴリ間の点線矢印はカテゴリの依存関係を示す

1.3 パッケージ

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

たとえば、開発言語がC++の場合は、1つ以上のライブラリファイルがパッケージとなる。Javaでは1つ以上のpackageまたは1つ以上のzipファイルやjarファイルが対応する。

sorry this is image
図1-4 パッケージ

1.4 フレームワーク

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

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

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

現在のソフトウェア環境において、フレームワークとコンポーネントの違いを厳密な技術体系として述べてもあまり意味をなさない。そのような定義は時代の流行と共に変化する可能性があるからである。なぜなら、フレームワークもコンポーネントも厳密なソフトウェアのメカニズムを土台としているものではなく、むしろソフトウェア部品に対する概念的な役割体系を定めているだけからである。

このような役割体系として両者を区別すると、 個々のコンポーネント達が円滑にコミニュケーションする仕組み(ルール)を提供していれば、 それがどんなに小さいコンポーネントの集合であってもフレームワークと言うこともあるだろう。 このように、フレームワークの役割を人体にたとえると、肉体を円滑に操作するための神経のようなものである。

逆に、いくつかのコンポーネントの集合を提供したとしても、それぞれのコンポーネントの利用目的が独立しており、それぞれのコンポーネントの関係が薄い場合は、フレームワークとは呼ばない。

つまりコンポーネント集合の特殊な形態をフレームワークと考えることができるだろう。

Dropでは、フレームワークとコンポーネントの違いを上記役割体系のみで区別しており、コンポーネントの特化した形態がフレームワークと考えドキュメント体系を定める。また、Dropでは、それぞれに目的の異なるフレームワークを再利用基盤モデルを使って種別化するといった再利用範囲の体系化も試みている。以下にフレームワークの種類について述べている。

フレームワークの種類

フレームワークによって提供される骨組みは、以下のようにフレームワークのターゲットとする問題領域によってソフトウェアレイアが異なるものである。

  1. 一般的なウインドウアプリケーション体系に適合するための機構を提供する。
    (言語製品に付属するウインドウアプリケーション開発フレームワークなど)
  2. ネットワークにおけるビジネスシステムをターゲットにして、コンポーネント同士を協調動作させるための汎用的な骨組み部分を提供する。
    (OMGで定めるBOF[BisinssObjectFremework]など)
  3. 特定ビジネスに完全に特化したコンポーネントを協調動作させるための骨組みを提供する。
    (CADフレームワーク製品など)

1.5 アプリケーションとシステム

開発するアプリケーションが巨大な場合や、問題領域のアプリケーションをユーザが利用するフェーズが時間的に分割されたりする場合などは、アプリケーションを統合するための機構(システム)が必要となる。この場合、アプリケーションはシステムが提供する何らかの仕組みにより、統合的な環境を提供することになる。Dropでは、この「アプリケーション」を統合する仕組みを「システム」と呼ぶ。

Dropの利用者は、開発ターゲットに併せて「アプリケーション」を「ツール」と呼び変えてもよいし、必要ならば、システムにもう一つ階層を持ちサブシステムを設けてもよい。

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

1.6 アプリケーションユーザとコンポーネントユーザ

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

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

上記のような視点を持つユーザの要求を達成するためには、「アプリケーション提供の観点」と「コンポーネント提供の観点」という2つの観点を併せ持つことが、開発者にとって重要な考え方となる。

Dropでは、この2つの観点をまずは1人の技術者に持たせることを、開発プロセスにおける戦術の基本コンセプトとしており、 徐々にそれぞれの観点を持つ2つのグループを育てていくことが、Dropの提唱する企業(組織)戦略である。

ADG(Application Development Group)

  • 要求される責務 .... アプリケーションの仕様に責任を持つ
  • 要求される視点 .... システムの境界を定める。
  • 要求される知識と技術 .... 対象システムの専門知識を持ち、システムを構築する技術を持つ。

ODG(Objects Development Group)

  • 要求される責務 .... コンポーネントの仕様に責任を持つ
  • 要求される視点 .... コンポーネントの境界を定める
  • 要求される知識と技術 .... ソフトウェアプラットフォームに対する専門知識やコンポーネント構築技術を持つ。

sorry this is image
図1-7 2つのユーザ

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

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

1.7 コンポーネントユーザを考える

ここで図1-7をもう少し解説しよう。アプリケーションを提供するADGは、アプリケーションを開発する際にいくつかのコンポーネントを利用することになる。

コンポーネントを提供するODGは、コンポーネントを開発するにあたり、その下位層にあたるコンポーネントを再利用するだろう。このように、ほとんどの「コンポーネント提供者」は「コンポーネントユーザ」となる。

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

1.8 アプリケーション開発とコンポーネント開発

オブジェクト指向開発における理想はコンポーネントを組み合わせてアプリケーションを作ることである。この理想は、いわゆるコンポーネントパラダイムの実現である。(図1-10参照)

しかしながら、現状では理想と現実のギャップは大きい。実際には、コンポーネントを組み合わせただけでは、簡単なプロトタイプアプリケーションは作ることができても、本格的にユーザが満足できるレベルのアプリケーションを開発するのは困難なのである。なぜなら、アプリケーションに特化した要求項目を実現するコンポーネントを既存コンポーネントを張り合わせることが困難であることが多いからだ。

このアプリケーション開発におけるコンポーネントの融合ができにくいという問題の本質は、以下の2点からくる。

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

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

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

このDropにおける開発モデルの思想を簡単に説明すると。

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

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

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

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

「1.8 アプリケション開発とコンポーネント開発」で、アプリケーションの中枢部分はコンポーネント化できにくいと述べた。またその理由として「実現するための中枢部にアーキテクチャが存在し、そのアーキテクチャを実現するためのクラスは、一般的に、クラス間の結合度が高くなる」とも述べた。

このようにアプリケーションの中枢部分のアーキテクチャの実現は、クラス間の関係が非常に密になりやすい。その構造を人間にたとえると、神経の役割のようにコンポーネント間の情報を伝達させる機能も受け持つことになる。つまり、アプリケーションのアーキテクチャは、コンポーネント同士をつなげる神経となり、その神経につなげられた組織(コンポーネント)同士の情報伝達を制御しながらアプリケーションに特化された要求を実現しなければならない。

このようなアプリケーションのアーキテクチャには、類似のアプリケーションに共通する情報の流れや、共通的なクラス関係構造を、数多く見つけることができるだろう。この共通部分を抽出し、クラス間の情報伝達の流れも含めてパッケージ化し、それを再利用できればコンポーネントとしては困難だったアーキテクチャのの再利用が可能となる。これが本章のフレームワークの種類で述べた」特定ビジネスに特化するフレームワークの考え方である。

アプリケーションは、このようなビジネスフレームワークを使うことで図1-12のように、アプリケーションの中枢部分を再利用することが可能となる。このようなフレームワークは、ODGのコンポーネント開発サイクルにて開発されたり、市販フレームワークを購入したりして、ADGによって使われることになる。

sorry this is image
図1-12 フレームワークの再利用


*begin*back*foward*end*contents

この記事のトップへ