*begin*back*foward*end*contents

開発モデル編 -
第19章 システム構造モデル

問題領域分析フェーズで作成される要求モデルは、実装環境を意識しないオブジェクトモデルであり、それは仮想的な論理空間にオブジェクトをモデル化したものである。しかし、実際のシステム開発では、実装環境とシステムを実装するためのアーキテクチャ空間の中でオブジェクトモデルが存在する。そこで、システム共通設計フェーズによって、システムを実装するためのアーキテクチャを決定し、そのアーキテクチャに基づくオブジェクトの存在空間を作り上げることになる。

9.1 システム構造図

システム構造モデルは、アーキテクチャモデル上にオブジェクトが存在する空間を作り、その空間同士の関係と空間内のオブジェクトとの関係を示すものである。そのシステム構造モデルで表されるオブジェクトの空間のことを以降、「オブジェクト空間」と呼び、それを表すための表記法を「システム構造図」と呼ぶことにする。システム構造図の中でオブジェクト空間となる単位は、プロセス、スレッド、DLLなどである。

一般的なコンピュータ用語でこれらオブジェクト空間を解説すると、プロセスはプログラムの資源共有の単位、スレッドはプログラムの実行単位でプロセスに1個以上存在するものである。DLLはダイナミックリンクライブラリの略で、実行時にプログラムコードを異なるプロセスから共有可能とする単位である。

つまり、これらオブジェクト空間は、オブジェクト同時実行の単位やオブジェクト共有の単位を意味している。また、オブジェクト空間同士の関連を示すことは、異なる空間にあるオブジェクトの同時実行の必要性や共有の必要性を明らかにすることが目的となる。

これらのことを明確にすることにより、システム共通設計、アプリケーション設計・実装、コンポーネント分析、コンポーネント設計・実装などでは、その空間を前提として詳細化される。

システム構造図を記述する重要なポイントとして、オブジェクトをどの程度登場させるべきかということであろう。システム構造図の主役は、オブジェクトを存在させる空間であり、オブジェクトはその空間定義のための根拠として必要となる。従って、オブジェクトの記述は、その対象領域のオブジェクトの中で代表的なものだけを登場させなければならない。図19-1 は、サーバの請求書データベースをクライアントから読み込み参照するシステムを例にしたシステム構造図である。

実際には、クライアントにもサーバーにもオブジェクトが複数存在しているだろう。しかし、先に述べたように目的はシステム空間の明確化であり、不必要なオブジェクトの記述は避けるようにしなければならない。

sorry this is image
図19-1 請求書発行システム

システム構造図の表記方法を表19-1に示す。

表19-1 システム構造図の表記法
記号 意味
sorry this is image プロセスを表す図である。プロセスはオブジェクトの存在する空間となる。"<<Process>>"は"<<P>>"に省略することができる。もし、マシン(ノード)に対して1プロセス、1スレッドのモデルであるならば、スレッドは省略できる。また、マシンに対して1つのプロセスしか表す必要がないのならプロセスも省略できる。
プロセスはスレッドで分割されないかぎりひとつの実行単位となる空間である。
sorry this is image ひとつのプロセスがふたつのスレッドで構成されている。数字はオプションで、親子関係などを示す。 スレッドはオブジェクトの存在する空間となるが、ふたつのスレッド空間にオブジェクトを記述した場合、それらのオブジェクトは並行動作するということを示す。
sorry this is image DLL(実行時にダイナミックリンクされるライブラリ)を表す。DLLもオブジェクトが存在する空間である。ここに存在するオブジェクトは他のオブジェクト空間から共有することができる。これを利用して共有メモリ管理を行うオブジェクトを表現することができる。
sorry this is image クラスとインスタンスを表す。システム構造図では、オブジェクト空間に多くのオブジェクトを示さないようにしなければならない。あくまで、他の情報空間と関係を表す際に必要となるオブジェクトのみが記述対象となる。システム構造図にて動的な側面を表す際にはオブジェクトはインスタンスとなり、静的側面を表す際にはクラスとなる。
sorry this is image 複数のスレッドで共有される際にオブジェクトの持つデータの競合が発生する可能性のあるクラスまたはインスタンスを表す。このようなオブジェクトの利用は、データの競合を避けるための設計が必要とされ、それを明示するために、クラスやインスタンスの名前の上に"<<share>>"と記述する。もし、クラスそのものの仕様としてスレッド共有が必然的である場合はメソッド内部でオブジェクトの持つデータに対して排他制御を取ることとなる。
sorry this is image 共有メモリを管理するクラスを表す。複数のプロセスから共有される際にオブジェクトの持つデータの競合が発生する可能性があることを明示する時に、クラスやインスタンスの名前の上に"<<smem>>"と記述する。このように複数プロセスから同時利用される共有メモリを属性として持つクラスの設計は、クラス内部でセマフォなどを使ってデータの排他を図ることを強く勧める。
sorry this is image データベースまたは一般ファイルなどのデータストアを表す。
sorry this is image マシンの単位を明示する。マシンの単位は、いくつかのオブジェクト空間に限られる。
sorry this is image OSから標準APIとして提供されるパイプ通信を表す。
sorry this is image ウィンドウキューによる通信を表す。
sorry this is image OSから標準APIとして提供されるキュー通信を表す。
sorry this is image 太い線を使ってノード間のネットワーク通信を表す。ステレオタイプ"<<文字>>"により実際の通信手段やネットワークプロトコル名を表すことができる。

19.2 システム構造図の利用例

システム構造図の例を以下に示す。

sorry this is image 1プロセス、2スレッド構成でPersonオブジェクトのデータを共有する構成。この例の場合は、オブジェクトの所有権(生成と消滅)は第1スレッドにあることを意味する。スレッド同士の通信にはウィンドウキューを使用する。
この図で注意すべきことは、ReferThreadクラスがActiveクラスとして表されており、かつ、スレッド空間(T2)に配置されているという点である。これは、T2スレッド空間にてReferThreadがスレッド処理(T2)の主体となるクラスであることを明示しており、T2スレッド空間からReferThreadが新たにスレッドコンテクストを起こして非同期動作を行うという意味ではない。なお、この例の場合は、スレッド空間を省略することも可能であるが、この図式により、ReferThreadからPersonを参照する際には別スレッド(T2)のコンテクストを使っていることが明示されている。
sorry this is image 2プロセス構成でP2プロセスで作成した、共有オブジェクトをキューにて、P2プロセスに渡している。
sorry this is image 1サーバに複数のクライアント構成。
サーバ側は、クライアントからの送信を第2スレッドで受け取り、第1スレッドへウィンドウキューにより受け渡している。
クライアントは1プロセスでネットワークを通じてメッセージをサーバに渡す。図では、プロセスを1つしか表す必要がないためプロセスの記述を省略している。なお、ネットワーク通信にはSocketライブラリを使う。
この図の場合は、Serverの第2スレッドにPersonPrintをActiveクラス(太線の矩形)として表している。Activeクラスとはスレッドを内包している能動的なオブジェクトのことである。よってこの図は、スレッド空間T2を起こす主役がPersonPrintということを表している。なお、"<<T2>>"という記述によるスレッド空間の明示を省略することもできる。その場合、"<<P1>>"という1つのオブジェクト空間にPersonPrintというActiveクラスとPrintManクラスが存在する図となる。
sorry this is image ふたつのプロセス間通信をDLLで実現する。
DLLに共有オブジェクトを配置して、P1プロセスとP2プロセスがデータ交換を行う様子。
sorry this is image 2プロセス構成。
メッセージはウィンドウキューにより行う。
大量データの送信をファイルで行う様子。
sorry this is image 分散オブジェクトミドルウェアを使ってスレッド方式や通信方式をカプセル化した図。
クライアントからサーバ側の人事データベース検索サービスを利用している。

19.3 システム構造図の応用例

coming soon


*begin*back*foward*end*contents

この記事のトップへ