| ドキュメント名 | 解説 | 様式番号 |
|---|---|---|
| システム開発環境標準 | システム全体の開発環境を統一的に管理するためのルール | 2-01 |
| システムアーキテクチャ仕様書 | システムの基本構造、アプリケーション構成、アプリケーション間のコミュニケーション方式などについて仕様化したもの | 2-02 |
| システム機能仕様書 | システムの提供する機能を解説する仕様書 | 2-03 |
| システム操作説明書 | ユーザの立場からシステムの操作方法を解説したもの | 2-04 |
外部ビュー設計
ユーザインタフェース共通設計は、開発するシステムの操作性を共通化する作業である。システム全体の操作性を向上させることが目的となる。
ユーザインタフェース共通設計
「システム共通ワークショップ」により、システム全体としての統一的な操作基準を定める。操作基準は、システムを実装するOSまたはGUIにおける一般的な操作規約（または慣習となっている操作基準）をベースに、システムの仕様として新たに必要となる以下のような操作を共通化する。
また、この操作規約の決定過程では「ユーザインタフェースプロトタイプ」によって操作性と実現可能性を検証することが重要となる。
- 特殊なカーソル操作
- 特殊なマウス操作
- 連続的な流れが必要となる画面操作
要求仕様を基に、システムをアプリケーションの単位に分割する。このアプリケーションの単位とは、開発システムを利用者の使いやすい単位に分割したものでりある。たとえば、利用者が「運用者」と「管理者」に分かれる場合は、「運用アプリケーション」「管理者用ツール」といった形に分類できるだろう。
分割されたアプリケーションは、システムを利用者にとって分かりやすい単位となる。しかし、これらのアプリケーションを統合したものとして見せることも重要となる場合もある。たとえば、利用者が使う複数のアプリケーションの間でデータを共有させたり、前工程のアプリケーションのアウトプットが次工程のアプリケーションのインプットとして必要になる場合などである。
このようなシステムでは、システムの統合環境を実現するために、アプリケーションが相互にデータ交換を行うための流れや、他のアプリケーションとデータや機能を連携させるための基盤となるアーキテクチャを決定する。
問題領域分析フェーズで定義された、要求仕様書とシネマスコープモデルにて作成されたシナリオを基に、システムの機能とシステムの操作方法を、分割されたアプリケーションごとに詳細化する。この作業の成果ドキュメントとして、「システム機能仕様書」と「システム操作説明書」がある。両ドキュメントは、要求仕様に記述された機能について、完全に実装されるOS、GUIに合わせて作成されるドキュメントである。
内部ビュー設計
ADGのシステム分析者が中心となり、要求モデルのオブジェクトの中でデータに永続性があるもの、そして、システム共通となるものを中心に具体的なデータストア方式について設計を行う。 データストア設計の対象となるものは、要求モデルの中で分類されたDataManageに属するクラスである。データストア方式は開発言語やクラスライブラリによって異なるものであるが、一般的には表23-1のようなものが考えられる。表の(1)や(4)を選択する場合、オブジェクト設計とは別にファイルフォーマットやデータベーステーブル設計が必要となり、DataManageオブジェクトからファイル(or データベース)に相互変換するためのProcessを設計しなければならない。
NO 必要条件 ストレージ方式 主な特徴 効果 (1) 非リアルタイム処理 ファイル入出力クラスの利用 テキストベースの入出力 テキストファイルなので参照・変更が容易 (2) 非リアルタイム処理 オブジェクトシリアライズ機能 オブジェクト自身により入出力 入出力処理コード作成の省力化が可能 (3) リアルタイム処理・並行操作 オブジェクト指向データベース オブジェクトイメージによる入出力 入出力処理コード作成の省力化が可能 (4) リアルタイム処理・並行操作対応 リレーショナルデータベース テーブルイメージによる入出力 インタラクテイブな問い合わせに向いている
表23-1 データストア方式例とその特徴
プロセス・スレッド設計とは、単１マシンの中でシステムを動作させるための資源管理の単位と動作単位を決めることである。この決定は、アーキテクチヤモデルにおけるオブジェクトの存在空間とその空間同士の関係構造を決定するものであり、システム構造図を使って図式化される。
それぞれの空間に存在する、オブジェクト同士の関係は並行性を持ち、共通的なオブジェクトはオブジェクト属性の共有性を持つ可能性がある。ここでは、この基本的な構造設計を行い、クラスレイアカテゴリのProcessに属するものである。
ネットワーク設計はシステム開発の対象がネットワークシステムの場合に必要となる。 問題領域分析フェーズで作成された実装基盤検討書を元にして、具体的なネットワークモデルを形成する。その際には、プロセス・スレッド設計は、ネットワークモデルの１ノードとして設計され、データストア設計は、データベースの存在するマシンノードの設計となる。
ネットワークモデルは、単純な２層型や３層型、さらにはファンクション層とデータ層を業務毎に分割し、それぞれを結びつけた３層構成の統合システム型など、規模と目的に応じて選択される。
Dropにおけるクラスレイアカテゴリは、このネットワーク３層モデルとの相性がよい。クラスレイアカテゴリ設計によって分割されたカテゴリ中のオブジェクトは、それぞれデータ管理(DataManage)、機能(Process)、見せ方(View)となり、ネットワークモデルのデータ、ファンクション、プレゼーンテーションに関連性が強く、ネットワーク２層型や３層型の構成が取りやすい。
信頼性設計とは、システム全体としてエラー処理のレベルを統一化した上で、システムの保証すべき信頼性のレベルを決定することである。これは、問題領域分析におけるシステム実装基盤の調査によって決定された基本コンポーネントの信頼レベルに大きく依存しており、利用するコンポーネントの信頼レベルはすでにシステムに要求される信頼性のレベルをクリアしていることが前提となる。これは、問題領域分析フェーズの「実装基盤ワークショップ」により十分検討されていなければならない。
信頼レベルとは、システムのどこかに異常が発生した際、完全に回復すべき範囲と、完全に回復ができない（または回復しようとしない）時に保証すべき範囲を決定することである。つまりフェールセーフな設計（機能やデータが一部失われても最低限の安全性が保持される設計）をシステム全体として統一しなければならない。
この信頼レベルを基に、クラスパッケージ（Dropにおけるソフトウェア配布単位）毎にエラーの構造化を図る。エラーの構造化とは、「エラーチェックすべき範囲」と「エラーを返却する範囲」を決めることである。この決定は、クラス設計の指針となり、最終的には、クラスパッケージ仕様書やコンポーネント仕様書の事前条件、使用条件、戻り値などにより明確化される。
要求理解と要求実現の違い
アーキテクチャモデルへ移行するためのオブジェクト設計
サブシステム分割は大規模開発には欠かせない。分析・設計する対象があまりにも広範囲になりすぎた場合、その問題をいくつかのサブシステムに分類することで、見通しの良い設計ができるようになる。
このサブシステムは、たとえば「経理システム」における「販売統計」や「財務管理」とうような外部ビューのアプリケーション分割にマッチすることもあれば、経理システムにおける「DBアクセス」「ネットワーク管理」といったような外部ビューにマッチしない処理単位であることも多い。
このようにして分割されたサブシステムは、システムとしては一つの固まりとして動作しつつも、サブシステム間の独立性は高くなければならない。そのためには、以下の点に注意してサブシステム間の設計を進める必要がある。
- サブシステムの実装に依存する詳細を不必要に見せてはならない。
- サブシステムはサブシステムを利用しやすいインタフェースだけを見せる。
- サブシステム間の結合はできるだけ弱める。
これらのことは、如何にしてサブシステムを構成するクラスやメソッドを隠蔽し、必要なサービスだけを見せられるかというオブジェクトの設計方法にかかっている。このようなサブシステム分割設計においては、デザインパターンのFacadeパターンの考えが必要となる。Facadeパターンとは、図23-2のようにサブシステムの基本サービスだけを見せる(facadeは「外見」という意味)という役割を持つオブジェクトを設けるわけである。つまりFacadeの役割を持つクラスはサブシステムのサービスをインタフェースとして持つクラスである。このFacadeクラスは、上記(2)を実現するために、サブシステムを使うクライアント(これもサブシステム)に適したFacadeをクライアントごとに提供することもある。
また、サブシステムのインタフェースを抽象化することで、サブシステム内部実装を切り替えする際、他のサブシステムに影響を及ばさない方法も考慮すべきだろう。このようにサブシステムのインタフェースを抽象化するには、Abstract FactoryパターンやFactory Methodパターンが参考になる。Abstract Factoryパターンはサブシステムという大きな枠組みを抽象化するためのデザインパターンとして知られている。また、Factory Methodパターンは、Abstract Factoryの実現方法の一種として用いられるデザインパターンである。筆者らのIJAHOプロジェクトでは、FacadeパターンとFactory Methodパターンを使ってサブシステムを抽象化する方法を簡単なソフトウェア例として示したものだ。
図23-2 Facadeパターン
図23-3 Factory Methodパターン
開発するシステムがネットワークシステムの場合は、２層型や３層型に論理的に分割されたシステムモデルを実際のマシン単位（ノード）に割り付けることになる。この際、それぞれのノードはサブシステムと考えるべきである。つまり、サブシステム分割で述べたようにサブシステム間の結合を弱めるようにしなければならない。このことは、クライアント／サーバ間やネットワーク３層モデルにおけるクライアントと中間層（ビジネスプロセス層）間の設計において重要となる。
このことはCORBAなどの分散オブジェクトを使う際にも同様に重要である。しかしながら、分散オブジェクトを使った設計では、ネットワーク透過性が強調されるばかりに、ノード間の結合度を弱める設計に労力をはらわないことがある。たとえば、サーバ側のリファレンスするオブジェクトを多用してしまう設計である。そのような設計をしてしまうと、異なるノード間に存在するオブジェクト同士の結合度が高くなってしまう。よってネットワークのノードをサブシステムと考え、ノードにFacadeパターンを応用するのである。
図23-4は、このことを解説するために作成したシンプルなモデルである。この図は、スーパマーケットの支店ごとの仕入れ先業者と仕入れ品を管理モデルである。もし、図のB1のアーキテクチャモデルを採用するならば、要求モデルをそのまま反映させたネットワーク透過なモデルとなる。しかし、その反面、クライアントは複数の支店オブジェクトの複数の仕入れ品オブジェクトのリファレンスオブジェクトをクライアントに持つこととなる。たとえば、千個の仕入れ品オブジェクトがあれば千個のリファレンスオブジェクトがクライアントに作成され、それぞれがサーバ側のオブジェクトをリファレンスする。 この結果、ネットワーク上にトラブルが発生した時に対処しにくいシステムとなったり、システム全体としてのスループットに悪影響を及ぼしたりしてしまうことになる。
そこで、B2のようにノードが行うサービスをインタフェースとするような支店管理コンポーネントを新たに設けることを設計として考えなければならない。しかしB2の問題は、サーバ側にある実オブジェクトと切り離されたオブジェクトがクライアントに存在してしまうという問題がある。つまり、クライアント側ではサーバ側の仕入れ品オブジェクトの複製を持つことになり、その属性値が不一致になってしまう瞬間が存在することを考慮しなければならない。よって、B2がよい設計とはいちがいには言えない。実際は、下記の設計要件を参考にそれぞれのトレードオフを考慮し、B1とB2の折衷案を見つける事が必要とされる。
- クライアントで処理される最小単位のオブジェクトは、オブジェクト転送の方が望ましい。
- ネットワーク転送するオブジェクトは少量になるよう考慮する(たとえば支店を転送する際は仕入れ先のリンクを切って転送するなど)。
- 状態管理が複雑なものや、サーバ側で頻繁に属性値が変化するものは、リモートオブジェクトをリファレンスする方が望ましい。
- 大きなデータを管理し、その中の局所的なデータがクライアントからの要求で更新されるようなオブジェクトはリモートオブジェクトをリファレンスする方が望ましい。
- Aは要求モデルである。
- アーキテクチャモデル(B1、B2)の図では、分散オブジェクトの仕組み上必要となるstubオブジェクトやskeletonオブジェクトを省略している。
- B1は要求モデルをそのままアーキテクチャモデルにしたもの。
実際には、クライアントは、サーバ側のリモートオブジェクトをリファレンスオブジェクト(代理オブジェクト)により参照しているため、ネットワーク透過なモデルが実現されている。- B2は要求モデルをノード間の独立性を高めるように変化させたもの。
支店管理クラスは、リファレンスオブジェクト(代理オブジェクト)によってクライアントから参照され、要求される支店オブジェクト、仕入先オブジェクト、仕入れ品オブジェクトをクライアント側に転送する。この形式では、クライアント側の空間にサーバ側の部分オブジェクトが転送されることになり、ネットワーク透過性という意味では、B1より劣っている。図23-4 ２つのアーキテクチャモデルの設計例
Viewに属するクラスの分析は要求モデルでは対象外となっていた。従って、アーキテクチャモデルによって具体的化される。Viewの具体的なアーキテクチャモデルの構造は、Viewを構築する基盤となる言語、クラスライブラリよって決定されるものである。しかし、その論理的な基本構造は図23-5のように「表示制御部」と「イベント制御部」に分類できる。「表示制御部」とは、ウインドウなどの表示に関するロジックを持っているクラスグループである。また、「イベント制御部」は、ユーザがボタンなどのGUIコントロールによって発生させるイベント処理を行うクラスグループである。
イベント制御部の役割は、イベント要求を機能グループ毎に集結させ、Processへ橋渡し（委譲）することである。 また、関係するGUIコンポーネントを参照し、制御する役割も持つことになる。イベント制御部は、それぞれのGUIコンポーネントを独立させながら管理し、GUIイベントを集中的に受け付ける必要があり、その設計にはMediatorデザインパターンが参考となるだろう。Viewにイベント制御部を作るか否かは設計者の判断に委ねられるが、イベント制御部を作ることでViewとProcess間の結合度が弱くなり、見通しのよい設計ができるようになる。
Processの構造は、図のようにView側にとって使いやすいインタフェースを提供することが望ましい。(Facadeパターン)このようにViewとProcessの独立性を高めれば、ViewとPrcoessの仕様変更がしやすい構造をもたらすことになるだろう。また、Viewが得意な開発者とProcessが得意な開発者にそれぞれ作業を分担しやすくなる。Prcoessは、ネットワークシステムの場合はクライアントとサーバを接合するフレームワークとしても機能する。アーキテクチャモデルで新たに追加されるProcessクラスは、要求機能を効率的に実現するために、アーキテクチャに最適な構造によって実装されることになる。
DataManageに属するクラスは、永続エンジンを実現するProcessクラス（図中のAクラス。ODG作成または市販製品）によってデータベースやファイルに読み書きされる。実際のストレージ方式により、要求モデルに対して永続化のためのスーパクラスが付加されたり、クラスライブラリに属するためのプロトコルを実装するメソッドが付加されることになる。
図23-5 アーキテクチャモデルにおけるView、Process、DataManageの実現
安易にシステム固有の操作を共通仕様化してはいないか？共通仕様決めだけを先行させてはいないか？
共通操作に関する方式仕様だけが決定され、部品化について検討が疎かになっていないか。