１｣ 統幕指運第１２２号 ２ ３ ． ６ . ２ ２ 大 臣 官 房 長 防 衛 大 学 校 長 防衛医科大学校長 防 衛 研 究 所 長 陸 上 幕 僚 長 海 上 幕 僚 長 航 空 幕 僚 長 情 報 本 部 長 技術研究本部長 装備施設本部長 防 衛 監 察 監 殿 統合幕僚長 コンピュータ･システム共通運用基盤の技術標準について（通知） 標記について、別冊のとおり通知する。 なお、コンピュータ･システム共通運用基盤の技術標準について（通知）（統 幕指運第２号。１８．３．２７）は廃止する。 添付書類：別冊 分類番号：Ｌ３－Ｌ３２ 保存期間：１０年 保存期間満了日：３４．３．３１ 統幕指運第１２２号（２３．６．２２）別冊 ＣＯＥ技術標準 統合幕僚監部 平成２３年６月 分類番号：Ｌ３－Ｌ３２ 保存期間：１０年 保存期間満了日：３４.３．３１ 目 第１章 総則 次 ･･････････････････････････････････････････････････････ １ １ 目的 ････････････････････････････････････････････････････････ １ ２ 概要 ････････････････････････････････････････････････････････ １ ３ 用語の定義 ･･････････････････････････････････････････････････ １ ４ 本書の校正 ･･････････････････････････････････････････････････ ８ 第２章 ＣＯＥの概要 １ ＣＯＥ導入の背景 ２ ＣＯＥの目的 ３ ＣＯＥの位置付け ４ ＣＯＥが提供するフレームワーク ５ ＣＯＴＳの活用 第３章 第１節 ･･････････････････････････････････････････････ ９ ････････････････････････････････････････････ ９ ････････････････････････････････････････････････ ９ ････････････････････････････････････････････ ･･････････････････････････････ 10 ･･････････････････････････････････････････････ 11 ＣＯＥ＜ＯＯＡ＞及びＣＯＥ＜ＲＴ＞ ････････････････････････ 14 ････････････････････････････････････････････････ 14 ･･････････････････････････････････････････････････ 14 技術概要 １ 基本構成 ２ 構成要素の概要 ３ 技術ドキュメント体系（ＣＯＥ＜ＯＯＡ＞） ４ 技術ドキュメント体系（ＣＯＥ＜ＲＴ＞） ････････････････････････････････････････････ 16 ････････････････････ 18 ････････････････････････････････････････････････ 20 ･･････････････････････････････････････････････ 20 開発技法 １ 開発技法概要 ２ オブジェクト指向開発 ３ コンポーネント化 ４ フレームワーク開発 ５ 開発管理技法 ･･････････････････････････････････････ 20 ･･････････････････････････････････････････ 21 ････････････････････････････････････････ 22 ･･････････････････････････････････････････････ 23 システムモデル（ＣＯＥ＜ＯＯＡ＞） ･･････････････････････ 24 ･･････････････････････････････････････ 24 ････････････････････････････････････････ 25 ･･････････････････････････････････････････････ 27 ･･････････････････････････････････････････････････ 30 システムモデル（ＣＯＥ＜ＲＴ＞）･･････････････････････････ 31 １ システムモデルの概要 ２ 各機能モデルの概要 ３ ３階層モデル ４ 補足事項 第４節 15 ･･････････････････ 第２節 第３節 10 １ システムモデルの概要 ２ 各機能モデルの概要 ３ ３階層モデル ４ 補足事項（リアルタイム処理の実現要領） 第５節 ･･････････････････････････････････････ 31 ････････････････････････････････････････ 31 ･･････････････････････････････････････････････ 32 ････････････････････ 35 処理パターン･･････････････････････････････････････････････ 36 １ 処理パターンの概要 ２ ＣＯＥ＜ＯＯＡ＞の処理パターン ３ ＣＯＥ＜ＲＴ＞の処理パターン 第６節 表示型式 ････････････････････････････････････････ 36 ････････････････････････････ 36 ･･････････････････････････････ 40 ････････････････････････････････････････････････ 44 １ 表示型式の概要 ････････････････････････････････････････････ 44 ２ 各表示型式の概要 ･･････････････････････････････････････････ 44 ･･････････････････････････････････････････････ 50 第７節 標準クラス １ 標準業務クラス ････････････････････････････････････････････ 50 ２ 標準部品クラス ････････････････････････････････････････････ 51 ３ 標準インフラサービス ４ 保全クラス等 ５ 標準クラス一覧 第４章 第１節 ･･････････････････････････････････････ 51 ･･････････････････････････････････････････････ 51 ････････････････････････････････････････････ 51 ･･････････････････････････････････････････ 52 ････････････････････････････････････････････････ 52 ･･････････････････････････････････････････････････ 52 ＣＯＥ＜ＳＯＡ＞ 技術概要 １ 基本構成 ２ 各構成要素の概要 ３ 技術ドキュメント体系 ･･････････････････････････････････････････ ･･････････････････････････････････････ 53 ････････････････････････････････････････････････ 56 ･･････････････････････････････････････････････ 56 第２節 開発技法 １ 開発技法概要 ２ サービス指向開発 ３ フレームワーク利用 第３節 システムモデル ･･････････････････････････････････････････ 56 ････････････････････････････････････････ 59 ･･････････････････････････････････････････ 60 １ システムモデルの概要 ２ 情報共有論理ネットワークモデル ３ 防衛省セキュリティモデル 第４節 １ 適用モデル 52 ･･････････････････････････････････････ 60 ････････････････････････････ 61 ･･････････････････････････････････ 65 ･･････････････････････････････････････････････ 66 適用モデルの概要 ･･････････････････････････････････････････ 66 ２ 標準的なモデル ３ ＣＯＥ＜ＯＯＡ＞適用システムとの接続モデル ４ レガシーシステムとの接続モデル ５ ＤＩＩオープン系、ＤＩＩクローズ系間のサービス連携モデル ６ 省外システムとの接続モデル 第５節 ････････････････････････････････････････････ 68 ････････････････ 69 ････････････････････････････ 70 ･･ 71 ････････････････････････････････ 72 ＥＳＣ及び認証・認可サービス ････････････････････････････ 73 ･･････････････････････････････････････････････ 73 ････････････････････････････････････････････････ 73 １ ＥＳＣの概要 ２ ＥＳＣコア ３ ＥＳＣアダプタ ４ アダプタ（ＯＯＡ） ････････････････････････････････････････ 74 ５ アダプタ（レガシー）････････････････････････････････････････ 74 ６ 認証サービス ･･････････････････････････････････････････････ 74 ７ 認可サービス ･･････････････････････････････････････････････ 75 ･･････････････････････････････････････････････････ 75 第６節 標準化 １ 標準化の目的 ２ 標準化対象 第７節 ････････････････････････････････････････････ 74 ･･････････････････････････････････････････････ 75 ････････････････････････････････････････････････ 75 サービス利用形態 ････････････････････････････････････････ １ サービス利用形態の概要 ････････････････････････････････････ ２ 各メッセ－ジパターンの概要 ････････････････････････････････ 76 76 77 1 第１章 １ 総則 目的 本書は、ＣＯＥの整備、適用並びに維持管理における技術的事項及びソフト ウェア開発技法の骨子を規定する。また、ＣＯＥの技術的事項を記述する最上 位の技術ドキュメントであり、下位の技術ドキュメントの体系を規定する。 ２ 概要 本書は、「総則」、「ＣＯＥの概要」、「ＣＯＥ＜ＯＯＡ＞及びＣＯＥ＜Ｒ Ｔ＞」及び「ＣＯＥ＜ＳＯＡ＞」の各章により構成する。 ３ 用語の定義 本書で扱う用語の意義は、次の各号に定めるところによる。 (1) 技術ドキュメント ＣＯＥに関する技術的事項を記述したドキュメントをいう。 (2) ＣＯＥ＜ＯＯＡ＞ ＯＯＡ(Object Oriented Architecture)に基づいて整備されたＣＯＥ＜ＯＯ Ａ＞ソフトウェア、ＣＯＥ＜ＯＯＡ＞ラボ及びＣＯＥ＜ＯＯＡ＞ドキュメン トの総称をいう。 (3) ＣＯＥ＜ＲＴ＞ リアルタイム処理ために整備されたＣＯＥ＜ＲＴ＞ソフトウェア、ＣＯＥ ＜ＲＴ＞ラボ及びＣＯＥ＜ＲＴ＞ドキュメントの総称をいう。 (4) ＣＯＥ＜ＳＯＡ＞ ＳＯＡ(Service Oriented Architecture)に基づいて整備されたＣＯＥ＜Ｓ ＯＡ＞ソフトウェア、ＣＯＥ＜ＳＯＡ＞ラボ及びＣＯＥ＜ＳＯＡ＞ドキュメ ントの総称をいう。 (5) 適用システム ＣＯＥを適用した防衛省の情報システムをいう。 (6) アーキテクチャ システムを構成する要素（設計思想、技術及び個別のシステム等）とその関 係を図示したシステム全体の構造（骨格）を示したものをいう。 (7) ＣＯＴＳ（Commercial Off The Shelf） 民生品（商用製品、市販品）を指す呼称であり、通常ソフトウェアとハー 2 ドウェアが含まれるが、ＣＯＥでは特にことわりがない限りソフトウェアに 対し用いる。また、ＯＳＳ（オープンソースソフトウェア）のような準民生 品も、便宜上ＣＯＴＳに含め扱うものとする。 (8) インフラサービス 主としてカーネルに分類されるＣＯＴＳを使用して動作する通常ＣＯＴＳで 実現できるソフトウェアの枠組みをいう。 (9) フレームワーク ソフトウェア及びシステムを効率的に開発するために、基本的機能の骨格 部分を提供するソフトウェア群をいう。 (10) ＯＯＡフレームワーク ＣＯＥ＜ＯＯＡ＞によって提供されるフレームワークのことであり、処理形 態や表示形態を抽象化し、共通する基本的な処理や業務をライブラリ群として 提供する基盤をいう。 (11) ＲＴフレームワーク ＣＯＥ＜ＲＴ＞によって提供されるフレームワークのことであり、周期処理 を規定時間で終了させるとともに、イベント処理を並行して実行できる処理 基盤をいう。 (12) ＳＯＡフレームワーク ＣＯＥ＜ＳＯＡ＞によって提供されるフレームワークのことであり、標準化 されたメッセージフォーマットによるデータ交換手段を提供する情報共有基盤 をいう。 (13) リアルタイム処理 プログラムの処理時間に予測性を持たせて処理できることをいう（ここでい う予測性とは、システムの設計段階でシステムに要求される時間要件を満たす ことを保証することである。）。 (14) ＣＯＴＳカテゴリ 動作環境に含まれるＣＯＴＳを把握し評価するために機能等で分類区分し たものをいう。 (15) カーネル ＣＯＴＳカテゴリにおいて、他のＣＯＴＳ動作の基本となるソフトウェアを いう。一般にＯＳ、秘匿ソフトウェア等が該当する。 (16) ＯＳＳ（Open Source Software） ソースコードが無償で公開され、誰でもそのソフトウェアの改良、再配布 3 が行なえるようなソフトウェアをいう。 (17) ＧＰＬ(GNU General Public License) Free Software Foundation の理念に基づくソフトウェアライセンスをい う。原則として、ソフトウェアの複製、ソースコードの閲覧・変更・再配布 が自由に行えることが定められている。 (18) ＡＰ２０００ 陸上自衛隊において陸自指揮システムを再構築した際の「開発手法」及び それにしたがって作成された「ソフトウェア部品群」をいう。 (19) 部品クラス ＣＯＥ＜ＯＯＡ＞のフレームワークにおいて、基本的な処理を実現し、制御 及び部分機能を提供するクラスの総称をいう。 (20) 業務クラス 一連の業務の処理を司るクラス及び当該クラスを作動させる上で、付随して部品ク ラスから派生させたクラスの総称をいう。 (21) 標準インフラサービス ＣＯＥ＜ＯＯＡ＞の諸規定に基づき製造されたＧＯＴＳが提供するインフラ サービスに相当する機能及びサービスをいう。 (22) 標準部品クラス 部品クラスのうち、ＣＯＥ<ＯＯＡ>として開発及び提供するクラスの総称を いう。 (23) 標準業務クラス 業務クラスのうち、ＣＯＥ＜ＯＯＡ＞として開発及び提供するクラスの総称 をいう。 (24) 標準クラス 標準業務クラス、標準部品クラス及び標準インフラサービスをいう。 (25) 個別部品クラス 部品クラスのうち、ＣＯＥ＜ＯＯＡ＞の適用及びＣＯＥ＜ＯＯＡ＞フレーム ワークの拡張において適用システムにおいて開発したクラスの総称をいう。 (26) 個別業務クラス 業務クラスのうち、適用システムにおいて開発したクラスの総称をいう。 (27) 個別クラス 個別部品クラスと個別業務クラスをいう。 (28) 個別アプリケーション 4 適用システムにおいて開発した、標準クラスを使用せずに動作するソフト ウェアの総称をいう。 (29) ラッピング ＣＯＴＳのバージョンアップ等によるＡＰＩの変更等の影響を最小限にする ため、直接ＣＯＴＳのＡＰＩを利用するプログラムを作成し、そのプログラム のＡＰＩを利用できるようにすることをいう。 (30) ＧＯＴＳ（Government off The Shelf） ＣＯＴＳの考え方を取入れ、政府での利用を目的として製造されたソフト ウェアをライブラリ化したものをいう。 (31) ＣＯＲＢＡ(Common Object Request Broker Architecture) オブジェクト指向技術の標準化団体であるＯＭＧが策定した異機種アプリ ケーション連携のための標準仕様のことをいい、シームレスな分散環境が実現 できる。 (32) コンポーネント 標準部品クラスを構成するクラス間の依存関係の最小単位であり、個別クラスや 標準業務クラスが利用可能なインタフェースを装備した、再利用可能な独立したソフ トウェア部品をいう。 (33) コンストラクション計画 ＣＯＥ部品維持及び部品拡充並びに適用システム開発の各事業において、機 能一覧及びその開発スケジュールを定めた計画をいう。 (34) カプセル化 プログラムの部品化を進めるため、情報隠蔽の考え方のもとにオブジェクト の公開領域と非公開領域を明確に分離し、外部定義だけでプログラムを使うこ とができるようにする手法をいう。 (35) ＣＯＥ化 適用システムの部品を共通化することをいう。 (36) ポリモーフィズム 異なるクラスに定義されている別のメソッドに同一の操作名を付けることに よって、それらを同一のメッセージで使用することができる仕組みをいう。 (37) 継承 下位のクラスが上位のクラスの属性や操作を利用できる性質をいう。 (38) 公開クラス 適用システムの業務クラスに対してインタフェースを公開する標準クラス 5 をいう。 (39) 非公開クラス 適用システムの業務クラスに対してインタフェースを公開しない標準クラ スをいう。 (40) 他システム ＣＯＥを適用していないシステムの総称をいう。 (41) データコンテナ 可変長バイナリ形式のＣＯＥ固有のデータ転送方式をいう。内部のデータオ ブジェクトを隠蔽し、２つの論理装置間に分散したデータオブジェクトを連接 する。 (42) ＡＰＩ あるプラットフォーム(ＯＳやミドルウェア)向けのソフトウェアを開発す る際に使用できる命令や関数の集合をいう。 (43) オンライントランザクション処理 関連する複数の処理を一つの処理単位にまとめて管理する処理方式をいう。 複数の作業を連結した処理単位を「トランザクション」という。 (44) マルチキャスト クライアントから複数のクライアント（サーバ含む。）に対して同時にデー タを送ることのできる通信方式をいう。 (45) リアルタイムデータベース 全てのデータをメモリ上に展開することで、検索や並べ替えなどの処理速 度を高めたデータベースをいう。 (46) 表示データ形 表示型式に依存したデータ形式をいう。 (47) 基本データ形 表示型式に依存しないデータ形式をいう。 (48) ＥＳＣ（Enterprise Service Controller） サービスとリクエスタ間のインタフェース及び通信基盤を担うソフトウェ ア部品をいう。ＥＳＣコアとＥＳＣアダプタから成る。 (49) ＥＳＣコア ＳＯＡの概念を取り入れた、アプリケーション間のＸＭＬメッセージによ る情報交換を実現するためのソフトウェアをいう。 (50) アダプタ（ＯＯＡ） 6 ＣＯＥ＜ＯＯＡ＞適用システムとＥＳＣコアを接続するための専用ソフト ウェアをいう。 (51) アダプタ（レガシー） レガシーシステムとＥＳＣコアを接続するための専用ソフトウェアをい う。 (52) リクエスタ ＥＳＣを介しサービスへ要求を行い、情報や機能の提供を受ける業務アプ リケーションをいう。 (53) サービス 不特定多数の利用する側のアプリケーション（リクエスタ）からの利用を 前提として、ネットワーク上に公開されたアプリケーションが提供する機能 をいう。 (54) 認証サービス 当該適用システムのリクエスタからのメッセージについて、正規のユー ザ、リクエスタからのものであることを認証するためのサービスをいう。 (55) 認可サービス 当該適用システムのサービスに対するアクセス権の情報を管理し、その情 報の基づきリクエストメッセージのサービスへの送達可否を判断するための サービスをいう。 (56) ＪＢｏｓｓ プログラミング言語Ｊａｖａによるオープンソースソフトウェアの総称を いう。 (57) ＥＳＣ論理空間 ＥＳＣコアの連携により形成されるサービス連携のためのネットワークを いう。同一ＥＳＣ論理空間に属するリクエスタ、プロバイダ及びＥＳＣコア 間でメッセージの送受信が可能である。 (58) サービス化 アプリケーションが提供する機能を公開することをいう。 (59) ＥＳＣアダプタ リクエスタおよびプロバイダに提供されるＥＳＣコアと通信するためのソ フトウェアをいう。 (60) プロバイダ ＥＳＣを介したリクエスタからの要求を受け、情報や機能の提供を行う業 7 務アプリケーションをいう。 (61) サービスインタフェース リクエスタとサービス間でやり取りする情報の形式を定めたものをいい、 そのサービスの名称、複数の標準データセット及び標準タグから構成され る。 (62) ＸＭＬ（eXtensible Markup Language） 文書やデータの意味や構造を記述するためのマークアップ言語である。Ｈ ＴＭＬと異なり、自分の目的に応じて、タグを定義できる。 (63) ＪＮＩ（Java Native Interface） Ｊａｖａプラットフォームにおいて、Ｊａｖａで記述されたプログラム と、他の言語（たとえばＣやＣ＋＋など）で書かれた、実際のＣＰＵの上で 動作するコード（ネイティブコード）とを連携するためのインタフェース仕 様をいう。 (64) Ｊａｖａ オブジェクト指向プログラミング言語の１つである。Ｊａｖａにおける実 行環境の違いは仮想マシンが吸収するため、Ｊａｖａで開発されたソフト ウェアは特定のＯＳやマイクロプロセッサに依存することなく、複数のプ ラットフォームで動作する。 (65) ＤＩＩ連接装置 ＤＩＩオープン系・クローズ系間でセキュリティを確保しつつメッセージ 連携を実現する装置をいう。 (66) ガード装置 システムのセキュリティ境界面にてシステムからの情報漏洩を防止する装 置をいう。 (67) トポロジー コンピュータネットワークにおける各構成要素の接続形態をいう。 (68) サービスのアドレス サービスの位置情報をいう。 (69) ＳＯＡＰ（Simple Object Access Protocol) ＸＭＬとＨＴＴＰなどをベースとした、他のコンピュータにあるデータや サービスを呼び出すためのプロトコルをいう。 (70) 共通ＥＳＣコア ＣＯＥ＜ＳＯＡ＞の共通基盤として整備されるＥＳＣコアをいう。必要に 8 応じて適用システムが共通的に利用できる。 (71) 開発支援機構（自動生成ツール） ＸＭＬが持つ業務データとＯＯＡデータコンテナが持つ業務データの変換 に必要となる「変換定義ファイル」と、データコンテナ毎に異なる業務デー タの取得／設定方法に応じた「変換部品のソースファイル」及び「変換部品 のヘッダファイル」を自動生成するツールをいう。 (72) メッセージルーティング 情報（メッセージ）を送信するため、コンピュータネットワーク上での経 路を見つけだす手法をいう。 (73) ＢＰＭ(Business Process Management)エンジン ＢＰＥＬなどで記述されたワークフローを解釈し、実行・管理するソフト ウェアをいう。 (74) ＢＰＥＬ(Business Process Execute Language) ＸＭＬベースのワークフロー記述言語をいう。複雑なＷｅｂサービスを連 携させることで、複雑なワークフローを定義することができる。 ４ 本書の校正 (1) 本書の改正は、対象事項の実施又は成立以前を原則とする。 (2) 改正予定事項を先行し実施又は成立させる場合は、ＣＯＥ調整会議の承認 を必要とする。 9 第２章 １ ＣＯＥの概要 ＣＯＥ導入の背景 ＣＯＥ導入以前、防衛省・自衛隊は各自衛隊・機関毎に個別に最適化された システムを作成していたため、ソフトウェアの動作環境が不整合であり、シス テム間の情報共有が容易には実施できないという問題があった。加えて、共通 的機能の重複開発等のコスト上の問題並びにＣＯＴＳ等のバージョンアップに 伴う最新技術の迅速な取込み及び情報システムに対する安全性の確保が重要な 課題であった。 このような問題点を解決するため、平成１４～平成１５年にかけて、「ＣＯ Ｅ＜ＯＯＡ＞」と呼称しているオブジェクト指向によるソフトウェア部品群の 初期版を構築した。 ２ ＣＯＥの目的 ＣＯＥを情報システムに適用させる目的は、次の３項目である。 (1) 情報共有の促進 ＣＯＥは、セキュリティを確保した上で、システム構築アーキテクチャの 統一と情報共有インタフェースの統一によって、各情報システム間の情報伝 達を円滑に行えるようにしている。したがって、適用システムがＣＯＥを適 用することによって、安全な情報共有の範囲を容易に拡大することが可能に なる。 (2) 重複機能開発の防止 システムを構築する際に必要となる通信機能、保全機能及び地図表示機能 等の基本的な機能は、システムが異なっていても、要求される機能は概ね同 じである。したがって、これらの機能をＣＯＥとして提供することにより、 適用システムにおいて、重複機能の開発防止と開発期間の短縮化やコスト低 減を図ることができる。 (3) 最新技術の取込みの容易性向上 情報システムは、ＯＳを初めとして多様なＣＯＴＳ類の使用を前提に構築 しているが、これらＣＯＴＳは、ＩＴ技術の進展によって常に進化を続けて いる。このような中、情報システムにあっては、ハードウェア換装に伴う最 新ＣＯＴＳへの追随が必要であり、ＣＯＴＳの機能向上（バージョンアッ プ）に際して、既存機能に影響を受けないことが必要である。 10 このため、ＣＯＥおいては、ラッピング技術を活用し、ＣＯＴＳの影響を ＣＯＥ部品で吸収することによって、適用システムが、ＣＯＴＳ変更の影響 を受けない仕組みを提供している。つまり、ＣＯＥを適用することによっ て、適用システム側では、ＣＯＴＳが提供する最新技術を容易に取込むこと が可能になる。 ３ ＣＯＥの位置付け ＣＯＥは、「構造、設計及び構造手法を共通化したソフトウェアで、自衛隊 が情報システムに共通的に使用するもの」とコンピュータ・システム共通運用 基盤の業務実施に関する訓令（平成１６年防衛庁訓令第８号）に定義されてお り、さらに同訓令では、「運用企画局長等は、防衛大臣の指定する情報システ ムを構築（換装又は改修を含む。）する場合には、コンピュータ・システム共 通運用基盤を適用しなければならない。」とされている。また、コンピュー タ・システム共通運用基盤の適用範囲について（通達）（防官情第２７６９ 号。１６．３．２６）において、「自衛隊の指揮統制を総合的に実施するため の情報システム」は、ＣＯＥ適用が義務付けられているとともに、その他のシ ステムにおいても、可能な限り適用することを推奨している。 ４ ＣＯＥが提供するフレームワーク 現在、ＣＯＥでは、ＯＯＡ、ＲＴ及びＳＯＡの３つのフレームワークを提供 している。各フレームワークの適用範囲を図２－１に示す。 図２－１ 各フレームワークの適用範囲 11 (1) ＯＯＡフレームワーク ＣＯＥ＜ＯＯＡ＞によって提供されるＯＯＡフレームワークは、「プログ ラミングやシステム構築において、データとデータを扱う手続を一本化し、 オブジェクトとして扱う。」というＯＯＡの考え方に基づいて設計されたも ので、リアルタイム処理の必要がない情報を処理するためのフレームワーク である。システム構築のアーキテクチャを統一することによって、情報シス テム間の情報共有を可能とする部品群であり、端末装置に配置する共通の ビューアによって、各種データを多彩な表現で表示することが可能である。 主として、指揮統制系のシステムに適用される。 (2) ＲＴフレームワーク ＣＯＥ＜ＲＴ＞によって提供されるＲＴフレームワークは、情報システム のリアルタイム処理能力向上を目的として開発されたもので、定められた時 間周期で定められた処理を確実に行うことが可能なフレームワークである。 主として、指揮統制系及び兵器統制系のシステムに適用される。 (3) ＳＯＡフレームワーク ＣＯＥ＜ＳＯＡ＞によって提供されるＳＯＡフレームワークは、「ネット ワーク上に存在するサービスの組合せによってシステムを構築する。」とい うＳＯＡの考え方に基づいたフレームワークであり、情報共有のインタ フェースを統一することで、アーキテクチャの異なる情報システム間を柔軟 に連接して、情報共有を実現する。主として、後方系システムに適用される とともに、各種情報システムの連接のために適用される。 ５ (1) ＣＯＴＳの活用 ＣＯＴＳ活用の狙い ＣＯＥでは、最新技術への追随及びソフトウェアの再利用を目的として、ＣＯＴＳ を積極的に活用する。 (2) カーネル カーネルの多くは、一般的にＯＳの機能に含まれるが、セキュリティサービス等Ｏ Ｓの機能で不足する場合に、ＯＳ以外のＣＯＴＳを選定する。カーネルのＣＯＴＳカ テゴリを表２－１に示す。 12 １ ２ ３ (3) 表２－１ カーネルのＣＯＴＳカテゴリー ＣＯＴＳカテゴリ カテゴリ概要 オペレーティングシステムの機能 オペレーティングシステム (OSカーネル、ユーザ／システム管理) ユーザインタフェース ユーザーマシンインタフェースに関する機能 セキュリティサービス 情報セキュリティ及びネットワークセキュリティ に関する機能 ４ 国際化操作サービス 言語の国際化に関する機能 ５ ネットワークサービス ネットワークサービスに関する機能 インフラサービス インフラサービスのＣＯＴＳカテゴリを表２－２に示す。インフラサービスは、そ れぞれのカテゴリで必要なＣＯＴＳを選定することにより実現する。 表２－２ インフラサービスのＣＯＴＳカテゴリ １ ２ ３ ４ ＣＯＴＳカテゴリ ソフトウェア開発 サービス データベース及び データ処理サービス 分散コンピューティ 開発支援系 ングサービス マルチメディアサー ビス カテゴリ概要 システム及びソフトウェア開発のための機能 データベース及びデータ処理に関する機能 クライアント・サーバ分散処理に関する機能 グラフィクス、地図、音声及び動画を扱うた めの機能 ５ 暗号化サービス データを暗号及び復号する機能 ６ 日（略）連携サービス 日（略）の連携を実現する機能 ７ 可用性サービス ８ ９ ＯＡ、運用支 援系 ディレクトリサービス 構成管理サービス 安定稼動のためのシステムデータファイル の２重化及び切替操作等の制御する機能 システムリソース（マシン、人、アプリケーショ ン等）をディレクトリ形式で管理及び検索を行う 機能 ソフトウェアのライフサイクルを通した管理業 務のサポートのための機能（ソフトウェアの バージョン及び実装されている装置などの管 理を含む。） 13 ＣＯＴＳカテゴリ カテゴリ概要 ネットワーク及びシステ ネットワークを含むシステム全体を管理する ム管理サービス 機能 情報共有及びコラボレーションに関する機 ＯＡ、運用支 11 情報共有サービス 能 援系（続き） オフィスオートメーショ ワードプロセッシング、表計算、印刷等のオ 12 ンサービス フィスオートメーションに関する機能 10 (4) ＣＯＴＳ利用上の留意事項 ア ＣＯＴＳを選定する場合、機能を開発するための要件を満足すること、移植性、 市場動向、提供ベンダーの信頼性等を評価して選定する。 イ ＣＯＴＳの適用にあたっては、ＣＯＴＳによるシステムへの影響を最小限にする ためラッピングを行うとともに、選定したＣＯＴＳの機能・能力を最大限に活用す る。 ウ ＯＳＳを活用する場合は、ＧＰＬ適用有無等、ライセンスの内容を十分 確認し、防衛省のソフトウェアに対して外部から干渉を受けないようにす る。 14 第３章 ＣＯＥ＜ＯＯＡ＞及びＣＯＥ＜ＲＴ＞ ＣＯＥ＜ＯＯＡ＞は、陸上自衛隊が陸自指揮システム整備のために開発したＡ Ｐ２０００を基に開発されたものであるが、これは、さらにリアルタイム処理能 力を備えたＣＯＥ＜ＲＴ＞へと進化した。 本章における以下の記述においては、ＣＯＥ＜ＯＯＡ＞について記述し、ＣＯ Ｅ＜ＲＴ＞については、ＣＯＥ＜ＯＯＡ＞と差違がある項目についてのみ記述す る。 第１節 １ 技術概要 基本構成 ＣＯＥ＜ＯＯＡ＞はＣＯＴＳ及び標準クラスから構成される。ＣＯＥ＜ＯＯ Ａ＞の基本構成を図３－１に示す。 図３－１ ＣＯＥ＜ＯＯＡ＞の基本構成 ［個別部品クラス］ ［標準部品クラス］ （ラッピング部） 標準ｲﾝﾌﾗ ｻｰﾋﾞｽ インフラサービス （ＣＯＴＳ／ＧＯＴＳが提供する機能・サービスで構成） カーネル （OS及びOSに付随する機能・サービスで構成） 外部インタフェース（ハード、ﾈｯﾄﾜｰｸ） 外部環境 ＣＯＥ Ｏ <ＯＡ > の設計思想等 設計思想 設計思想 開発管理技法 開発管理技法 開発技法 開発技法 システムモデル システムモデル 個[別 アプリケー ション ] ＣＯＥ Ｏ <ＯＡ の >ソフトウェア等 ［個別業務クラス］ ［標準業務クラス］ 15 ２ (1) 構成要素の概要 設計思想 ア データ中心の分析及び設計による情報共有化の促進 イ ＧＵＩの統一による開発効率、多様性、通信効率及び保全性の向上 ウ ＣＯＲＢＡを用いた通信の統一によるシステム間連接性の向上 エ 層毎のラッピングによるＧＯＴＳ、ＣＯＴＳ及びハードウェアへの依存性の極小 化 オ プラグイン可能な業務の構造 (2) 開発管理技法 ユーザ満足度の高い開発及び品質の高いソフトウェアの開発を合わせて行うため、 スパイラルによる開発を実施する。設計工程においては機能の内容を確定し、製造工 程においては、早い段階からユーザ要求を取り入れつつ、スパイラルを行なった後、 試験工程を実施する。 (3) 開発技法 設計思想を具現化するため、本書に定める開発技法により開発することを基準とす る。 (4) システムモデル システム開発の効率化、外部要因による影響最小化や拡張性の考慮等の目的を具現 化するため、設計上の基本概念（アーキテクチャ）として、ＣＯＥ＜ＯＯＡ＞が前提 とするシステムの基本構造を定める。ＣＯＥ＜ＯＯＡ＞は、本システムモデルに基づ くフレームワークを適用システムに対して提供する。 (5) ＣＯＴＳ コスト低減及び最新技術への追随及びソフトウェア再利用のため、ＣＯＥ＜ＯＯ Ａ＞としてＣＯＴＳを推奨する。 なお、ＣＯＴＳ適用にあたっては、ＣＯＴＳのバージョンアップによる影響を最小 限にするとともに、選定したＣＯＴＳの機能・能力を最大限に活用する。 (6) 標準クラス 基本的な処理及び標準的な業務の処理を実現するソフトウェアを、標準クラスとし て開発する。また、適用システムが開発した個別クラスもＣＯＥ＜ＯＯＡ＞として認 定することにより、重複開発の防止を行いつつ、ＣＯＥ＜ＯＯＡ＞を拡張する。 (7) 個別クラス 適用システムが、ＣＯＥ＜ＯＯＡ＞の設計要領に準拠して開発したソフトウェアで ある。 16 ３ 技術ドキュメント体系（ＣＯＥ＜ＯＯＡ＞） ＣＯＥ＜ＯＯＡ＞の構成及び適用方法について、技術的観点から記述される技術ド キュメントの体系であり、ＣＯＥ技術標準を最上位のドキュメントとして、技術標準、 技術規約・基準、設計図書及びガイド図書から構成される。ＣＯＥ＜ＯＯＡ＞の技術ド キュメントの体系を図３－２に、各ドキュメントの目的、記述概要等を表３－１に示 す。 図３－２ ＣＯＥ＜ＯＯＡ＞の技術ドキュメントの体系 ＣＯＥ技術標準 技術規約・基準 ガイド図書 設計図書 設計工程図書 標準クラス 設計基準 基本設計書 標準業務 クラス設計書 標準部品 クラス設計書 標準ｲﾝﾌﾗｻｰﾋﾞｽ 設計書 データベース設計書 プログラム 開発規約 ＣＯＥ/適用 システム 開発ガイド 性能設計書 製造工程図書 動作環境 構築基準 標準業務クラス プログラム設計書 標準部品クラス プログラム設計書 試験工程図書 試験計画書 試験手順書 運用図書 操作手順書 注：太枠は適用側へ渡す図書を示す。 17 表３－１ ＣＯＥ＜ＯＯＡ＞の各技術ドキュメントの目的、記述概要等 区分 ドキュメント名 記 述 内 容 標準クラス設計基準 ＣＯＥ＜ＯＯＡ＞の標準業務クラス、標準部品クラ ス、データベース等を設計する際に遵守すべき基準及び 要領を規定する。 設計 規約 プログラム開発規約 ・ 基準 図書 設 計 工 程 図 書 ＣＯＥ＜ＯＯＡ＞の標準クラスのプログラム設計・開 発・維持を行う際に遵守すべきコーディング規約、ＨＭ Ｉ規約、ネーミング規約、ヘルプ規約及びメッセージ規 約について規定する。 動作環境構築基準 １ ＣＯＥ＜ＯＯＡ＞で定めたカーネル及びインフラ サービスの機能を実現するための推奨ＣＯＴＳを規定 する。 ２ 推奨ＣＯＴＳの諸元（ＣＯＥ＜ＯＯＡ＞として推奨 するパラメータ値、ディスク容量、メモリ容量等）に ついて規定する。 基本設計書 要求機能を分析し、実現するための外部仕様を規定す る。 標準業務クラス設計書 標準業務クラスの機能及び機能実現をするためのクラ ス構成等の内容を規定する。 標準部品クラス設計書 標準部品クラスの機能及び機能実現をするためのクラ ス構成等の内容を規定する。 標準インフラサービス 標準インフラサービスの機能及び機能実現をするため 設計書 のクラス構成等の内容を規定する。 データベース設計書 性能設計書 標準業務クラス等が使用するデータベース（外部ス キーマ）を規定する。 性能要件を受けた性能設計内容を記述する。 標準業務クラスプログ 標準業務クラスを構成するクラスの一覧、クラス図、 製造 ラム設計書 関数定義、内部スキーマ定義等を記述する。 工程 標準部品クラスを構成するクラスの一覧、クラス図関 図書 標準部品クラスプログ ラム設計書 数定義等を記述する。 試験計画書 試験 工程 総合試験手順書 図書 システム試験手順書 ＣＯＥ＜ＯＯＡ＞の試験の目的、範囲、体制、スケ ジュール等の計画を記述する。 ＣＯＥ＜ＯＯＡ＞の総合試験の手順を記述する。 ＣＯＥ＜ＯＯＡ＞のシステム試験の手順を記述する。 18 区分 ドキュメント名 運用 操作手順書 図書 記 述 内 容 標準業務クラスの操作手順について記述する。 ＣＯＥ＜ＯＯＡ＞を適用した適用システム開発のガイ ガイ ＣＯＥ／適用システム ドラインとして、設計要領、プログラム開発要領、動作 ド図 開発ガイド 環境構築要領及び開発・維持管理要領を規定する。 書 注： 太字 （斜体）は、適用システム側へ渡す図書を示す。 ４ 技術ドキュメント体系（ＣＯＥ＜ＲＴ＞） ＣＯＥ＜ＲＴ＞の技術ドキュメントの体系を図３－３に、各ドキュメントの目的、記 述概要等を表３－２に示す。 図３－３ ＣＯＥ＜ＲＴ＞の技術ドキュメントの体系 19 表３－２ ＣＯＥ＜ＲＴ＞の各技術ドキュメントの目的、記述概要等 区分 設計 規約 ・ 基準 図書 ドキュメント名 開発規約 ＣＯＥ＜ＲＴ＞で適用する規約類として、シス テムメッセージ規約、ネーミング規約、コーディ ング規約、ＨＭＩ規約、ヘルプ規約及び通信規約 等につて規定する。 設計図書記述要領 ＣＯＥ＜ＲＴ＞で作成する設計図書の記述要領 を規定する。 全体設計書 ＯＯＡフレームワークとＲＴフレームワークを 融合したフレームワークの全体像を規定する。 基本設計書 要求機能を分析し、実現するための外部仕様を規定す る。 設計 工程 図書 概要設 計書 製造 工程 図書 試験 工程 図書 運用 図書 記 述 内 容 詳細設 計書 標準業務 クラス設 計書 標準業務クラスの機能及び機能実現をするためのクラ ス構成等の内容を規定する。 標準部品 クラス設 計書 標準部品クラスの機能及び機能実現をするためのクラ ス構成等の内容を規定する。 標準業務 クラスプ ログラム 設計書 標準業務クラスを構成するクラスの一覧、クラス図、 関数定義、内部スキーマ定義等を記述する。 標準部品 クラスプ ログラム 設計書 標準部品クラスを構成するクラスの一覧、クラス図関 数定義等を記述する。 試験計画書 ＣＯＥ＜ＲＴ＞の試験の目的、範囲、体制、スケ ジュール等の計画を記述する。 総合試験手順書 ＣＯＥ＜ＲＴ＞の総合試験の手順を記述する。 操作手順書 標準業務クラスの操作手順について記述する。 ＣＯＥ＜ＲＴ＞を適用した適用システム開発のガイド ガイド ＣＯＥ／適用システ ラインとして、設計要領、プログラム開発要領、動作環 図書 ム開発ガイド(ＲＴ） 境構築要領及び開発・維持管理要領を規定する。 注： 太字 （斜体）は、適用システム側へ渡す図書を示す。 20 第２節 １ 開発技法 開発技法概要 ソフトウェアを部品化し、ソフトウェアの再利用性を高めるために、オブジェクト指 向による開発技法を標準とし、ソフトウェアをコンポーネント単位で、汎用的に使用で きるように設計する。この際、システムの処理形態や表示形態に着目してフレームワー クを設計し、各形態を抽象化して、システムで共通する基本的な処理や標準的な業務ク ラスとする。それらをライブラリ群として適用システムへ提供する。 なお、個別クラス等を開発する場合、ＯＯＡフレームワークを遵守することにより、 ソフトウェアの再利用性を向上させる。さらに、開発管理技法としてコンストラクショ ン計画に基づいたスパイラル開発を基本とする設計、製造、試験工程を推奨する。 ２ (1) オブジェクト指向開発 目的 ソフトウェアの再利用性、品質の向上及び開発の効率化を追及することを目的とす る。 (2) 手法 ア カプセル化 カプセル化手法を用いてソフトウェア部品(オブジェクト)を作成し、オブジェク ト同士がメッセージを交換することによりアプリケーションを実現する。 イ 継承 オブジェクトの再利用促進及び品質向上のため、継承を採用する。新たな業務処 理の開発にあたり、ソフトウェア部品として汎化した既存部品をベースとし、これ を継承することにより、当該業務固有の処理のみの開発を実現している｡ ウ ポリモーフィズム ポリモーフィズムを用いて同じインタフェースで新旧のメソッドが共存できる方 式を実現している。 エ 追跡可能性 設計方法からプログラミング言語仕様まで一貫して、この手法を実現するための 構造及び仕組みを備えている｡それにより、オブジェクトの派生関係を追跡でき る。 (3) 期待効果 ア ソフトウェアを部品化しやすい。 イ メンテナンス性に優れている。 21 ウ 開発規模を抑えることができる。 (4) 留意事項 ア クラスの設計については、既存資産を十分に理解し、新たに機能を追加する場合 には対象となるクラスの地位及び役割を明確にした上で設計を行う。 イ 業務や部品への影響を最小限に抑えるため、ソフトウェアの部品化にあたって は、ＣＯＴＳインタフェースを隠蔽する。 ウ 再利用性向上のための設計及び構築作業の標準化を図る。 エ 継承のメリットを生かすため、似たような機能を複写するようなイメージでクラ スを作成しない。 オ 継承関係の複雑化を回避するため、多重継承しない。 カ 派生をするときは、適切な親クラスを選定する。 ３ コンポーネント化 (1) 目的 標準クラスの品質向上及び適用性向上を図るととともに適用システムの維持管理 コスト削減等のＣＯＥ適用システムへのサービス向上を目的とする。 (2) 手法 標準クラスを、適用システムの業務クラスに対してインタフェースを公開 するクラス（以下「公開クラス」という。）と非公開とするクラス（以下 「非公開クラス」という。）に分けるとともに、適用システム側の要求に基 づいて、非公開クラスを入れ替え可能な構造とする。また、標準クラスの依 存関係を整理する。さらに、適用システム側へのソースプログラムを非提供 とし、プログラムの実行体のみを配布する。 (3) 期待効果 ア 標準クラスの品質向上 利用可能な公開機能の明確な定義及びプログラムの実行体配布により、 適用システム側でのソースプログラムの誤った修正及び使用禁止機能の不 正利用を防止し、想定していない箇所での不具合発生を減少させる。 イ 標準クラスの適用性向上 公開インタフェースが明確であること及びコンポーネント単位での実行 体配布により、改善部分機能の迅速な取り込みや適用システム側の状況に 応じて修正プログラムを任意に取り込むことが可能になる。 ウ 適用システム側の維持管理コスト低減 22 プログラムの実行体配布により、適用システム側のコンパイルが不要と なり、ＣＯＥ部品の入替え作業が軽減する。また、利用できる標準クラス とそのインタフェースが明確になるため、適用システム側の業務クラスの 設計及び開発が容易となり、維持管理コストを低減することができる。 (4) 留意事項 ア 新たに作成したクラスをコンポーネントに登録する場合は、既存資産の依 存関係を十分に理解し、コンポーネントの入れ替えを前提に設計を行う。 イ 新たに機能を追加する場合は、適用システム側のコンパイルが不要となる ように、極力、公開インタフェースを保持する。 ウ 適用システム側の要求等により、公開インタフェースの変更又は追加が必 要な機能拡張を行った場合は、適用システム側のコンパイルが必要になる。 ４ (1) フレームワーク開発 目的 ソフトウェアの再利用性を高めるとともに業務開発を安全に実施するため、基本的 な処理を実現することを目的とする。 (2) 手法 各業務の処理形態及び表示形態に着目して汎用的なフレームワークを提供する。Ｃ ＯＥ適用システムでは、必要な処理形態及び表示形態を検討し、提供されたフレーム ワークを元に具象化クラスを開発する。 ア 処理パターン 情報システムを構成する業務処理の共通性（データ検索、データ登録、データ送 信、自動更新、他システム連接等）に着目し、整理・抽象化することで得られる処 理フローの集まりで、次に示すような用途で適用システム側に提供される。細部は 第５節で解説する。 (ｱ) 業務処理を設計する上で必要となるパターン (ｲ) 適用システム側設計のサンプル イ 表示型式 情報システムで扱う表示データを分析し、画面の入出力イメージを整理・抽象化 （地図表示、表表示、グラフ表示、ツリー表示、テキスト表示、画像表示等）する ことで得られる表示の型の集まりで、次に示すような用途で適用システム側に提供 される。細部は、第６節で解説する。 (ｱ) 適用側の表示の型を導出するためのパターン 23 (ｲ) 適用側設計のサンプル (3) 期待効果 適用システム等を開発する場合には、これらパターンに則して業務処理を設計する ことにより､次の効果が期待できる。 ア セキュアな空間を安全に作成 イ 品質が確保されているフレームワークなどの開発済みの部品群を使用することに よる品質向上 ウ 設計から試験に至るまでの開発作業の効率化やソフトウェアの再利用性の向上 エ 適用システム毎に実施していた方式設計やコーディング規約の共通化 (4) 留意事項 適用システムは、ＯＯＡフレームワークとして提供する処理パターン及び表示型 式、あるいはそれを具現化した標準クラスの機能が不足する場合、次のとおり対応す る｡ ア 要求するユーザとの間での要件調整を行い、ＣＯＥ＜ＯＯＡ＞としての標準クラ ス開発を検討 イ 適用システム側での開発及びＯＯＡ＜ＯＯＡ＞への登録を検討 この際、ＣＯＥ管理室との密な調整が必要 ５ 開発管理技法 ＣＯＥではスパイラル開発による工程を基本とする。スパイラル開発の概要を図３－ ４に示す。 図３－４ スパイラル開発の概要 製造工程 設計工程 （ 機能の確定） 実装設計 コーディング 機能確認 確認 試験工程 （ 機能、性能の保証） スパイラル１ ユーザ要求反映 ユーザニーズ反映 リスク対策等 スパイラル２ 実装設計 コーディング 機能確認 確認 ユーザ要求反映 ユーザニーズ反映 リスク対策等 スパイラル３ 実装設計 コーディング 機能確認 確認 24 (1) 設計工程 ユーザ要求事項（機能及び性能）の全てを満足する内容を設計し、機能を確定する とともに、スパイラル毎に開発する機能を決定する。この場合、ＯＯＡフレームワー クを適用して設計を進める。ただし、既存のフレームワークでは実現できない場合 は、フレームワークの拡張を検討する。また、開発期間を考慮し、技術的なリスクが 高い機能の優先的な開発を計画する。 (2) 製造工程 設計工程で決定した機能を開発し、スパイラル毎にユーザによる確認を実施する。 確認時の指摘内容を反映した結果の確認については、ユーザとの協議の上、実施時期 を明確にする。 なお、指摘事項は製造工程内で完了させることを基本とする。 (3) 試験工程 製造工程で実施した機能確認の内容に加え、機能及び性能を保証するための網羅性 ある試験を実施する。 第３節 １ システムモデル（ＣＯＥ＜ＯＯＡ＞） システムモデルの概要 (1) 機能モデル ＣＯＥ＜ＯＯＡ＞は処理の骨格となるフレームワークとして、画面表示、通信及び ＤＢアクセス等の基本的機能を提供しており、個別の業務機能はフレームワークに追 加することで機能を拡張できる方式となっている。 このため、ＯＯＡフレームワークとしては、これら機能を「データモデル」、「Ｇ ＵＩモデル」、「通信モデル」及び「セキュリティモデル」に分割するとともに、個 別の業務要件を実現する機能については「業務モデル」としてフレームワーク設計を 行っている。 (2) ３階層モデル ＣＯＥ＜ＯＯＡ＞では、これらの機能モデルを実現するために、表示処理（ユーザ とのインタフェースを実現する。）、業務処理（業務固有のビジネスロジックを実現 する。）及びデータ抽出処理（データの格納及び業務要件に応じた検索等を実現す る。）の「３階層モデル」として各層に処理を分割するとともに、論理装置に機能を 配分することによって、将来の拡張性、効率的な開発とプログラムの安全性を実現す る方式としている。 25 (3) システムモデルのイメージ フレームワークに お け る シ ス テ ム モ デ ル の イ メ ー ジ を 図 ３ － ５ に 示 す。 図３－５ システムモデルのイ メ ー ジ ２ 各機能モデルの概要 (1) ＧＵＩモデル 高度なＧＵＩの実現、ＧＵＩの統一、開発効率の向上及び保全を意識することなく 安全なシステムの開発を可能とするモデルであり、データモデルに格納される地図、 表、グラフ及びツリー型式等の各種データを統一されたインタフェースに基づき表示 することが可能である。 (2) データモデル ア データモデルの概要 情報共有のために指揮システムに必要となるデータ種別（地図、表及びツリー 等）を取扱うための共通的な仕組みを提供しており、各業務がデータモデルを介し てデータの管理を行うことで、データ構造を隠蔽できるため、拡張性・保守性に優 れる。種別の区分については、次に示すとおり。 (ｱ) 表示用データ ＧＵＩモデルに表示するための表示型式毎の各種データ (ｲ) 格納用データ 26 ＤＢに登録又は検索結果を格納するためのデータ イ データコンテナ ＯＯＡフレームワークでは、各処理間でのデータ伝送を効率的に行うための仕組 みとして、データコンテナ方式を採用している。データコンテナは、通信を行う 際、適用業務のデータ構造に依存しない可変長バイナリ形式に変換し通信するた め、各適用業務固有のデータを統一的なインタフェースで扱うことができる。 ウ データベース構築の考え方 ＣＯＥ＜ＯＯＡ＞のデータベースはサーバの物理的な配置にかかわらず、全デー タを一元管理することを前提とした思想に基づき構築されている。これは、データ ベース定義体を内部スキーマとして、また、業務クラスからのインタフェースを外 部スキーマとすることで処理方式に差異を生じさせないこと及びデータベース管理 の簡素化を目的としている。 エ データベースモデル ＣＯＥ＜ＯＯＡ＞では、データベースを一元的に格納するための内部スキーマ及 び利用者が利用しやすい単位の外部スキーマに分けることで、効率的なデータ管理 が可能となる。図３－６にデータベースモデルのイメージ図を示す。 図３－６ ＣＯＥ＜ＯＯＡ＞のデータベースモデルのイメージ図 ＣＯＥ〈ＯＯＡ〉のデータ連携 ○○部 ○○部 データベース 編成 編成 個人情報 予算 人員 資金 個人情報 装備品 定員 敵情報 災害状況 編成装備 部隊配置 ○○部 編成 編成 ○○部 定数 編成 現数 現員 災害 ：外部スキーマ ○○部 ：内部スキーマ オ データベースモデルの特徴 (ｱ) データベースの統合化 データベース定義体及びアプリケーション処理方式の統一を図り、データベー スの管理要領を簡素化するために、データベースを統合する。これによりサーバ 27 （物理装置）の配置に依存しないデータベース構造が可能となる。 (ｲ) データ履歴の管理制御 各レコードに有効期間及び最新フラグを付与し管理する。これにより、ＤＢの 永続性と業務の変化に対応可能な拡張性の確保を可能とする。 (ｳ) ＤＢＭＳの最大限活用 ＤＢサーバの内部処理を効率的かつ効果的に実施することを目的に、ＤＢＭＳ が有する機能をＤＢアクセス部品が隠蔽している。これにより、ＤＢＭＳが有す る機能を最大限に活用する環境をＣＯＥ＜ＯＯＡ＞及び適用システム側に提供し ている。 (ｴ) コードの永続性 各業務データを履歴管理するためには、各種コードも同じく履歴管理する必要 がある。 したがって、ＣＯＥ＜ＯＯＡ＞においては、コードその物を示す「ユニークな 番号」と履歴の管理制御を行うための「有効期間」を定義し、コードの永続性を 保証している。 (3) 通信モデル ＣＯＥ＜ＯＯＡ＞における論理装置間の通信は、次の理由によりＣＯＲＢＡを採用 している。 ア 分散オブジェクト環境であるため、オブジェクト指向との親和性が高い。 イ 高水準ＡＰＩである。 ウ 分散オブジェクト環境の国際標準かつオープン環境を前提としているため、異機 種間連携が比較的容易である。 エ 各システム独自の論理空間の形成を容易にするため、接続マシンなどの定義を一 元管理できるネーミングサービスを有している。 (4) セキュリティモデル 情報システム保全技術基準ＭＯＤ－３保護プロファイルのうち、ソフトウェアで対 応可能な機能を実現したマルチレベルセキュリティに対応したモデルである。 (5) 業務モデル 個別の業務処理を実現するモデルであり、フレームワークへのプラグイン として開発及び追加を可能とする。 ３ (1) ３階層モデル 基本的な論理装置 28 ア ＣＯＥ＜ＯＯＡ＞は、「表示処理」、「業務処理」、「データ抽出処理」の３階 層を基本としてクラス群を構成し、これにより、各レイヤ（層）間で処理の分担及 び接続形態の共通化を図り、ソフトウェアの再利用性を向上させる。 イ 論理装置は、「表示処理」に相当する「①端末」、「業務処理」に相当する「② ＡＰサーバ」及び「データ抽出処理」に相当する「③ＤＢサーバ」により構成され る。 ウ ３階層モデルと論理装置の関係を図３－７に示す。 図３－７ ３階層モデルと論理装置の関係 (2) 論理装置の展開 ア ３階層モデル（「端末」、「ＡＰサーバ」及び「ＤＢサーバ」）を基本とし、シ ステムの分散配置、他システムとの連接等を実現するための論理装置を展開する。 イ その他の論理装置として、他システムとの連接を行う「他システム連接サーバ （ＯＣサーバ）」、「他システム連接用データベースサーバ（ＯＤサーバ）」、保 全機能を実現する「認証サーバ（ＣＣサーバ）」、動画の送受信・蓄積を行う「動 画サーバ（ＭＶサーバ）」及びデータベースアクセスを実現する「相関サーバ（Ｃ Ｒサーバ）」がある。 ウ ＣＯＥ＜ＯＯＡ＞は、これらの論理装置を持つサイト同士が結びついた分散シス テムを前提として、クラスの設計を行う。また、３階層モデルをベースとしたシス テム構造を前提とした標準クラスを構成することにより、適用システムにおいて次 のことを可能としている。 (ｱ) 複数の論理装置を１つの物理装置にまとめること。 (ｲ) ソフトウェア構造をパターン化し、開発効率を向上すること。 エ 各論理装置の概要を表３－３に、論理装置の構成イメージ図を図３－８に示す。 29 表３－３ 論理装置の概要 論理装置名称 概 要 １ 端末（クライアント） 表示操作に関連する処理全般を行う装置 ２ ＡＰサーバ （CRサーバ） 業務の処理を行う装置 （相関処理を高速に実施する装置） ３ DBサーバ データベース抽出処理を行う装置 ４ 他システム連接を行う場合に利用する装置 ５ 他 シ ス テ OＣサーバ ム連接サ ーバ OＤサーバ ６ CCサーバ 保全機能を実現する装置 ７ MVサーバ 動画の送受信と蓄積を行う装置 図３－８ 他システムで使用する固有のコードを保持する装置 論理装置の構成イメージ図 30 ４ 補足事項 (1) ＤＢベースサーバへのアクセス方法 ＣＯＥ＜ＯＯＡ＞は、保全性の確保のために、ＤＢサーバへのアクセスは、必ずＡ Ｐ（ＣＲ）サーバを経由して実施する。ＤＢサーバへのアクセス経路は、次に示すと おり。 ア クライアント～ＡＰサーバ（ＣＲサーバ）～ＤＢサーバ イ 適用システム間のＡＰサーバ～ＡＰサーバ～ＤＢサーバ ウ 他システム～ＯＣサーバ～ＡＰサーバ（ＣＲサーバ）～ＤＢサーバ (2) 各論理装置間の細部の通信方式 ア 同一システム内のクライアント～ＡＰ間のデータ送受信は分散オブジェクト処理 により、クライアントとＡＰサーバの処理を一体化している。また、ＡＰ～ＤＢ間 は、オンライントランザクション処理により、円滑なデータ送受を可能にしてい る。 イ 他システムのＡＰサーバ及び他システム連接サーバとのデータ送受信は、メッ セージキュー処理にて通信を行うことにより、データの確達性を保証しつつ運用及 びシステムの独立性を確保している。 ウ 図３－９にＣＯＥ＜ＯＯＡ＞における各論理装置間の通信方式を示す。 図３－９ 各論理装置間の通信方式 31 エ ＣＯＥ＜ＯＯＡ＞ではユニキャスト通信のほか、サーバの有無にかかわらずクラ イアント－クライアント間通信を狭帯域で実施できるマルチキャスト通信を提供し ている。図３－１０にマルチキャスト通信を示す。 図３－１０ 第４節 １ マルチキャスト通信 システムモデル（ＣＯＥ＜ＲＴ＞） システムモデルの概要 ＣＯＥ＜ＲＴ＞の機能モデルの構成は、ＣＯＥ＜ＯＯＡ＞を基本として作成したもの であり、ＣＯＥ＜ＯＯＡ＞と同様に、ＧＵＩモデル、業務モデル、データベースモデ ル、通信モデル及びセキュリティモデルから構成される。 ２ (1) 各機能モデルの概要 ＧＵＩモデル ＣＯＥ＜ＯＯＡ＞と同様に、高度なＧＵＩの実現、ＧＵＩの統一、開発効率の向上 及び保全を意識することなく安全なシステムの開発を可能とするモデルであり、デー タモデルに格納される地図、表、グラフ及びツリー型式等の各種データを統一された インタフェースに基づき表示することが可能である。 リアルタイム処理能力を付加するため、ＣＯＥ＜ＯＯＡ＞と異なりユーザ操作と画 面表示処理が並行して動作できるようになっている。 32 (2) データモデル ア データモデルの概要 ＣＯＥ＜ＲＴ＞においては、リアルタイム性を確保するため、ＣＯＥ＜ＯＯＡ＞ で使用している、表示用データと格納用データの他、基本データ型を用いている。 イ データコンテナ ＣＯＥ＜ＲＴ＞においては、基本データ型を使用できるデータコンテナを用いて 各処理間を連接している。 ウ データベース構築の考え方 ＣＯＥ＜ＲＴ＞においては、規定時間内で処理を終了させるため、目標情報等の 業務で使用するデータをメモリ上に展開し、業務から、高速にアクセスできる構成 としている。 (3) 通信モデル ＣＯＥ＜ＯＯＡ＞と同様に、ＣＯＲＢＡを採用している。 (4) セキュリティモデル ＣＯＥ＜ＲＴ＞においては、野外でのシステム運用を考慮し、装置認証を 行える仕組みを提供している。 (5) 業務モデル ＣＯＥ＜ＯＯＡ＞と同様に個別の業務処理を実現するモデルであり、フ レームワークへのプラグインとして開発及び追加を可能とする。 ３ (1) ３階層モデル 基本的な論理装置 ア ＣＯＥ＜ＲＴ＞は、ＣＯＥ＜ＯＯＡ＞と同様に、「表示処理」、「業務処理」、 「データ抽出処理」の３階層を基本としてクラス群を構成し、これにより、各レイ ヤ（層）間で処理の分担及び接続形態の共通化を図り、ソフトウェアの再利用性を 向上させる。 イ 論理装置は、「表示処理」に相当する「①ＣＳＬ端末」、「②ＣＳＬサーバ」、 「業務処理」に相当する「③ＲＡサーバ」及び「データ抽出処理」に相当する「③ ＤＢサーバ」により構成される。 ウ ３階層モデルと論理装置の関係を図３－１１に示す。 33 図３－１１ (2) ３階層モデルと論理装置の関係 論理装置の展開 ア ３階層モデル（「クライアント」、「ＡＰサーバ」及び「ＤＢサーバ」）を基本 とし、システムの分散配置、ＣＯＥ＜ＯＯＡ＞適用業務との連携及び他システムと の連接等を実現するための論理装置を展開する。 イ リアルタイム処理の中核をなすのが、「リアルタイムアプリケーションサーバ （ＲＡサーバ）」であり、他のＲＡサーバとの連接や、ＣＯＥ＜ＯＯＡ＞のＡＰ サーバ及びＤＢサーバとの連携を行う。 ウ センサー等の器機との連接については、リアルタイム性を確保するため、コード 変換処理をメモリ上で実施することのできる「連接装置」を介して行う。 エ 「コンソール端末（ＣＳＬ端末）」は、高速なシンボルの描画を行うとともに、 ユーザからの要求を受け付ける論理装置である。 オ 「コンソールサーバ（ＣＳＬサーバ）は、ＣＳＬ端末数の増加時にＲＡサーバの 処理負荷を軽減させるとともに、ＣＳＬ端末装置間の情報共有を実現するための論 理装置である。 カ 各論理装置の概要を表３－４に、論理装置の構成イメージ図を図３－１２に示 す。 34 表３－４ 論理装置名称 論理装置の概要 概 要 １ ＣＳＬ端末 表示操作に関連する処理全般を行う装置 ２ ＣＳＬサーバ ＲＡサーバの処理負荷を軽減するための装置 ＣＳＬ端末間の情報共有を行う装置 ３ ＲＡサーバ ＣＯＥ＜ＲＴ＞業務の業務処理を行う装置 ４ ＡＰサーバ ＣＯＥ＜ＯＯＡ＞業務の業務処理を行う装置 ５ ＤＢサーバ データベース抽出処理を行う装置 ６ CCサーバ 保全機能を実現する装置 ７ 連接装置 他システム連接を行う場合に利用する装置 図３－１２ 論理装 置 の 構 成 イ メ ー ジ 図 35 ４ 補足事項（リアルタイム処理の実現要領） (1) 基本データ型の採用 ＣＯＥ＜ＯＯＡ＞においては、ＡＰサーバが端末装置毎の表示型式に対応 したデータ加工するため、表示する画面数（端末数）の増加がサーバの処理 能力に影響を与える。 そこで、ＣＯＥ＜ＲＴ＞においては、ＣＳＬ端末が増加した場合において も、ＲＡサーバのリアルタイム処理への影響を最小限とするため、ＲＡサー バは、表示型式に依存しない基本データ型で送信することとし、ＣＳＬ端末 が、基本データ型から表示データ型に変換することで、ＲＡサーバの処理負 荷を軽減させる。 (2) 画面表示処理と業務処理の分離 ＣＳＬ端末においては、画面表示処理と業務処理を別な処理単位として実 行する形態とすることによって、業務処理中の画面イベントを受付可能にす るとともに、表示更新とメニュー操作等のイベントが同時に発生した場合に おいても、同時に処理を可能としている。 (3) ＣＳＬサーバによるＲＡサーバ及びＣＳＬ端末の負荷軽減と端末間の情報 共有 ＣＳＬサーバは、基本データ型から表示データ型に変換する処理を受け持 つことにより、個々のＣＳＬ端末の処理負荷を軽減させる役割を担うととも に、ＣＳＬ端末間での情報共有を実現する機能を有している。また、ＣＳＬ 端末の表示更新周期の変更がＲＡサーバへの処理負荷を生じさせない必要が あるため、ＣＳＬサーバにおいて情報の周期更新を補完する機能を有してい る。 (4) ＲＡサーバにおけるリアルタイム処理 ア リアルタイムデータベース 規定時間内で処理を終えるため、メモリ上に業務データを展開し、リア ルタイム処理を可能としている。 イ 並列処理及び優先度制御 複数の処理単位を複数のプロセッサに割り付ける並列処理管理機能によ り、リアルタイム性が要求される処理に対してＣＰＵリソースを独立的に 配分するとともに、高い優性度を付与することにより、イベント等に対す る処理が必要になった場合においても、規定時間内に処理を完了できるよ うにしている。 36 ウ ＣＯＥ＜ＯＯＡ＞の論理装置との情報共有 基本的に、ＣＯＥ＜ＯＯＡ＞の適用業務との連接は、ＤＢサーバを介し て行う。また、緊急メッセ－ジ等に関しては、ＡＰサーバと直接連携する ことが可能である。 第５節 １ 処理パターン 処理パターンの概要 ＣＯＥ＜ＯＯＡ＞においては、３階層構造における業務処理の多様な流れ を、数種類の処理パターンに整理・抽象化した上で、それら特定の処理パター ンを実現する標準クラスを提供している。 したがって、ＣＯＥ＜ＯＯＡ＞の適用においては、要求された業務アプリ ケーションを規定された処理パターンの組合せによって設計をする必要があ る。 ２ (1) ＣＯＥ＜ＯＯＡ＞の処理パターン データ検索パターン データ検索パターンは、クライアントから検索依頼を行い、ＡＰサーバを 経由してＤＢサーバから検索結果を取得する処理パターンである。取得した データは、ＡＰサーバにおいてクライアントの表示型式にあったデータ形式 に変換される。データ検索パターンの処理イメージを図３－１３に示す。 図３－１３ データ検索パターンの処理イメージ図 37 (2) データ登録パターン データ登録パターンは、クライアントから登録データを指定し、ＡＰサー バにおいて、ＤＢに登録するデータ形式に変換処理し、ＤＢサーバを経由し てＤＢにデータを登録する処理パターンである。データ登録パターンの処理 イメージを図３－１４に示す。 図３－１４ (3) データ登録パターンの処理イメージ図 データ送信パターン データ送信パターンは、クライアントから送信依頼を行い、他サイトのＡ Ｐサーバにデータを転送する処理パターンである。この際、自システムのＤ Ｂサーバにもデータの整合を図るため登録を行う。データ送信パターンの処 理イメージを図３－１５に示す。 図３－１５ データ送信パターンの処理イメージ図 38 (4) データ自動更新パターン データ自動更新パターンは、クライアント又は他のＡＰサーバ等から自動 更新の対象となるデータを受信した際に、ＡＰサーバが、クライアントに当 該データを転送するとともに、ＤＢサーバにデータを登録する処理パターン である。データ自動更新パターンの処理イメージを図３－１６に示す。 図３－１６ (5) データ自動更新パターンの処理イメージ図 他システム連接パターン 他システム連接パターンは、ＣＯＥ＜ＯＯＡ＞を適用していないシステム との間でデータの送受信を行う処理パターンである。ＯＣサーバにおいて、 プロトコル変換及びフロー制御を行うとともに、ＯＤサーバ上でコード変換 処理を行う。他システムへの送信処理イメージを図３－１７に、他システムか らの受信処理イメージを図３－１８に示す。 39 図３－１７ 図３－１８ (6) 他システム連接パターン（送信）の処理イメージ図 他システム連接パターン（受信）の処理イメージ図 動画パターン 動画パターンは、クライアントから動画表示依頼によって、ＭＶサーバか ら動画データを受取表示する処理パターンである。動画パターンの処理イ メージを図３－１９に示す。 図３－１９ 動画パターンの処理イメージ図 40 (7) クライアント内データ処理パターン クライアント内データ処理パターンは、画面等で指定したデータをクライ アント内部で処理し、処理後のデータを画面等に表示する処理パターンであ る。クライアント内データ処理パターンの処理イメージを図３－２０に示す。 図３－２０ ３ (1) クライアント内データ処理パターンの処理イメージ図 ＣＯＥ＜ＲＴ＞の処理パターン 周期情報受領パターン 周期情報受領パターンは、連接装置及び他のＲＡサーバから周期情報を受 信する処理パターンである。周期情報受領パターンの処理イメージを図３－２ １に示す。 図３－２１ 周期情報受領パターンの処理イメージ図 41 (2) イベント情報受領１パターン ＣＳＬ端末、ＣＳＬサーバ、連接装置及び他のＲＡサーバがイベント情報 を受信する処理パターンである。イベント情報受領１パターンの処理イメー ジを図３－２２に示す。 図３－２２ (3) イベント情報受領１パターンの処理イメージ図 イベント情報受領２パターン イベント情報受領２パターンは、ＣＳＬ端末からＣＳＬサーバがイベント 情報を受信するパターンである。イベント情報受領２パターンの処理イメー ジを図３－２３に示す。 図３－２３ (4) イベント情報受領２パターンの処理イメージ図 イベント情報受領３パターン イベント情報受領３パターンは、ＡＰサーバからＲＡサーバがイベント情 報を受信するパターンである。イベント情報受領３パターンの処理イメージ 42 を図３－２４に示す。 図３－２４ (5) イベント情報受領３パターンの処理イメージ図 周期処理パターン 周期処理パターンは、ＲＡサーバの内部で、周期処理を実行する処理パ ターンである。周期処理パターンの処理イメージを図３－２５に示す。 図３－２５ (6) 周期処理パターンの処理イメージ図 情報配信１パターン 情報配信１パターンは、ＲＡサーバがＣＳＬ端末（ＣＳＬサーバ経由）、 連接装置及び他のＲＡサーバに対してイベント情報を配信する処理パターン である。情報配信１パターンの処理イメージを図３－２６に示す。 43 図３－２６ (7) 情報配信１パターンの処理イメージ図 情報配信２パターン 情報配信２パターンは、ＣＳＬサーバがＣＳＬ端末に対してイベント情報 を 配 信 す る 処 理 パ タ ー ン で あ る 。 情 報 配 信 ２ パ タ ー ン の 処 理 イメージを図 ３－２７に示す。 図３－２７ (8) 情報配信２パターンの処理イメージ図 情報配信３パターン 情報配信３パターンは、ＣＳＬサーバがＣＳＬ端末に対してイベント情報 を 配 信 す る 処 理 パ タ ー ン で あ る 。 情 報 配 信 ３ パ タ ー ン の 処 理 イメージを図 ３－２８に示す。 44 図３－２８ (9) 情報配信３パターンの処理イメージ図 ＤＢ検索パターン ＤＢ検索パターンは、ＲＡサーバがＤＢサーバからデータを検索する処理 パターンである。ＤＢ検索パターンの処理イメージを図３－２９に示す。 図３－２９ 第６節 １ ＤＢ検索パターンの処理イメージ図 表示型式 表示型式の概要 ＣＯＥ＜ＯＯＡ＞では、ユーザインタフェースに対する多様なニーズを、特 定の表示型式に整理・抽象化した上で、それら特定の表示型式を実現する標準 クラスを提供している。 ２ (1) 各表示型式の概要 表型式 45 表型式は、画面上に表示する際に表型式で表現する型式である。表に関す るデータをセットし表の表示、各レコードとセル（列・行）の挿入、追加、 編集、削除、結合、行・列入れ替え、オートフィルタ、ソート及び表示制御 を行う。また、グラフ連携機能により入力したデータをグラフ化することが 可能である。表型式における画面構成例を図３－３０に示す。 図３－３０ (2) 表型式における画面構成例 グラフ（チャート）型式 グラフ（チャート）型式は、画面上に表示する際に折れ線グラフ、棒グラ フ、積重ね棒グラフ、円グラフ及びレーダチャートの型式で表現する表示型 式である。グラフ（チャート）型式における画面構成例を図３－３１に示す。 46 図３－３１ (3) グラフ（チャート）型式における画面構成例 ツリー型式 ツリー型式は、ツリー型データを階層型式で表現する表示型式である。部 隊編成等のツリーに関するデータの表示、追加、挿入、削除、ドラッグ＆ド ロップ、シンボル表示色変更、文字背景色変更及び表示制御を行う。ツリー 型式における画面構成例を図３－３２に示す。 図３－３２ ツリー型式における画面構成例 47 (4) ネットワーク図型式 ネットワーク図型式は、ネットワークに関する情報（アーク：通信網等、 ノード：通信所等）を表現する表示型式であり、地図上またはプレーンな ウィンドウ上にネットワーク図を表示させる。画面上からアーク及びノード を制御する機能を持つ。ネットワーク図型式における画面構成例を図３－３ ３に示す。 図３－３３ ネットワーク図型式における画面構成例 統合ビュ ーア ファイル(F) タイル設定(T) 編集(E) メモ(E) 地図・作画(M) 業務(G) 機能選択(K) ＸＸ業務 ヘルプ(H) ネットワーク図 (5) 階層マトリックス型式 階層マトリックス型式は、基本的な表示要領はツリー型式と同様である が、階層表示の制御をすることにより、表の表示を最適階層まで表示できる ように変更できる。ツリーに関するデータを表型式で表現し、データの表 示、追加、挿入、削除、ドラッグ＆ドロップ、シンボル表示色変更、文字背 景色変更及び、表示制御等を行う表示型式である。階層マトリックス型式に おける画面構成例を図３－３４に示す。 48 図３－３４ (6) 階層マトリックス型式における画面構成例 地図型式 地図型式は、画面上に地図を表示してその上に各種情報を表現する表示方 法であり、ＣＯＴＳを使用しシンボル等の地図に関するデータの表示等制御 を行う。地図型式の図法の種類には、メルカトル図法、ランベルト図法、正 距方位図法、ＵＴＭ図法、１９座標図法がある。地図型式における画面構成 例を図３－３５に示す。 図３－３５ 地図型式における画面構成例 49 (7) 静止画（イメージ）型式 静止画（イメージ）型式は画像（イメージ）を用いて表現する表示型式で ある。静止画（イメージ）型式における画面構成例を図３－３６に示す。 図３－３６ (8) 静止画（イメージ）型式における画面構成例 テキスト型式 テキスト型式は、テキストボックスを用いて表現する表示型式である。テ キストに関するデータの表示、編集及び表示制御（フォント、文字サイズ、 背景色の指定）等を行う。作成した図表等に対して、テキスト文書を付与す る場合に使用する。テキスト型式における画面構成例を図３－３７に示す。 図３－３７ テキスト型式における画面構成例 50 (9) 動画／音声型式 動画／音声型式とは、動画及び音声データを表現する表示型式である。表 示された動画データに対して、画面から一時停止、再生、早送り、巻き戻 し、音声調整等の制御を行う。動画／音声型式における画面構成例を図３－ ３８に示す。 図３－３８ 動画／音声型式における画面構成例 第７節 標準クラス １ 標準業務クラス (1) 標準業務クラスは、ＣＯＥ＜ＯＯＡ＞として共通的に開発した業務クラスで あり、適用システムの業務クラスの開発においてその骨格となる。適用システ ムにおいては、標準業務クラスを元に当該システムで固有の処理のみを実装す ることで個別の業務の処理を実現することが可能である。 (2) 重複開発を防止し、ＣＯＥ＜ＯＯＡ＞として共通化を図るため、適用システ ムで開発した個別業務クラスを標準クラスとして認定又は標準クラスとして改 修することにより、標準業務クラスの充実を図る。 51 ２ 標準部品クラス 標準部品クラスはＯＯＡフレームワークにおける基本的な処理を構成する部品群であ る。標準部品クラスは、適用システムに対する基本的な処理を提供するクラスであるた め、不変のものではなく、適用システムの要求を受け、ＯＯＡフレームワークを逐次拡 張し、充実を図る。 ３ 標準インフラサービス 標準インフラサービスは、インフラサービス（主にＣＯＴＳ）が提供してきたサービ スを標準クラスとして提供する部品群である。 ４ 保全クラス等 (1) 保全クラス ア ＣＯＥ＜ＯＯＡ＞は、ＭＯＤ-３の機能要件を満たす部品群を提供する。 イ 適用システムの構築においては、どのレベルまでの保全性を確保するかを検討し た上で、必要な保全機能を選択し、実装する。 (2) 運用モード ア 適用業務において、実業務と演習に応じてデータを変える等の運用に応じて表示 データが異なる場合においても、原則として業務処理は変更せず、データベースの 格納データを変更できるように演習識別子を用いて、各モードのデータを個別に管 理できる。 イ 運用モードの変更が予想される場合、あらかじめ運用モードに対応したコード等 をデータベースに格納する。 ５ 標準クラス一覧 付録に標準クラス一覧を示す。 52 第４章 第１節 １ ＣＯＥ＜ＳＯＡ＞ 技術概要 基本構成 ＣＯＥ＜ＳＯＡ＞の構成を図４－１に示す。 図 ４－１ ２ ＣＯＥ＜ＳＯＡ＞の構成 各構成要素の概要 (1) 設計思想 ア ＳＯＡ（サービス指向アーキテクチャ）による情報共有の促進 イ ＣＯＥ＜ＯＯＡ＞適用システムとの高い連接性を確保 ウ 標準技術による実装で、適用柔軟性向上、技術発展への追従性向上 エ ＯＳＳ（オープンソースソフトウェア）の活用による、ベンダー依存防 止、ライセンス費用の低減 オ マルチＯＳ（Solaris、Windows、HP-UX、Linux）への対応 カ データ標準化への対応 53 (2) 開発管理技法 ＥＳＣはシステム間連接として使用するミドルウェアであり、また、多様 なシステムにおいて活用されるため、決められた開発技法ではなく、適用シ ステムに最適な開発技法により開発を実施する。ただし、１つのＥＳＣ論理 空間上でＳＯＡの効果を発揮するため、その特性を生かしたＥＳＣ適用、他 システムへの影響を配慮したサービスの提供、利用といった留意事項を理解 した設計を行う必要がある。 (3) 開発技法 設計思想を具現化するために、本書に定める開発技法により開発すること を基準とする。 (4) システムモデル ＣＯＥ＜ＯＯＡ＞適用システムやレガシーシステム等、異なるアーキテク チャで構築されたシステム間の情報共有を目的に、ＣＯＥ＜ＳＯＡ＞は、防 衛省標準のシステム間情報共有フレームワークを適用システムに提供する。 (5) 適用モデル ＥＳＣ論理ネットワークへの接続を容易にするため、各適用システムのシ ステム構成に合わせて、ＣＯＥ＜ＳＯＡ＞が想定する基本構造を定める。 (6) ＯＳＳ／ＣＯＴＳ 最新技術への追随性を容易にするために、汎用技術を担う機能部分を市場 製品で構成する。また、ベンダー依存防止及びコスト低減を図るため、ＯＳ Ｓ（オープンソースソフトウェア）を最大限に活用する。 ＯＳＳ／ＣＯＴＳの選定にあたっては、将来の製品動向の中で、優秀な製 品への乗り換えを前提に、標準仕様への準拠を選定要件とし、極力容易な切 替えを可能にする構成にしている。 (7) ＥＳＣ サービスとリクエスタ間のインタフェース及び通信基盤担うソフトウェア 部品を提供する。ＣＯＥ＜ＳＯＡ＞としては、インタフェース標準化を規定 する部品を提供するのみで、適用システム内部の作りについての規定は行わ ない。 ３ 技術ドキュメント体系 ＣＯＥ＜ＳＯＡ＞の構成及び適用方法について、技術的観点から記述される 技術ドキュメントの体系であり、ＣＯＥ技術標準を最上位のドキュメントとし 54 て、ＥＳＣの適正、かつ、円滑な運用を図ることを目的とした指針類、技術規 約・基準、設計図書及びガイド図書から構成される。ＣＯＥ＜ＳＯＡ＞の技術 ドキュメントの体系を図４－２に、各ドキュメントの目的、記述概要等を表 ４－１に示す。 図 ４-２ ＣＯＥ＜ＳＯＡ＞の技術ドキュメントの体系 55 表４－１ 区分 ＣＯＥ＜ＳＯＡ＞の各技術ドキュメントの目的、記述概要等 ドキュメント名 ＥＳＣ運用ポリ シー 記 述 内 容 ＣＯＥ＜ＳＯＡ＞に関係する管理対象の規 定、各ＣＯＥ＜ＳＯＡ＞関係者の定義、各関係 者の業務と手続きの規定及び運用ポリシーの見 直しに関する考え方等について規定する。 ＥＳＣセキュリ ティポリシー システム環境の中で想定される脅威、ＥＳＣ が機能として対抗すべき脅威、適用システムが 対抗すべき脅威、ＥＳＣの機能実装のためのセ 指針類 キュリティポリシー、適用システムのためのセ キュリティポリシー及びセキュリティポリシー 見直しに関する考え方等について規定する。 標準化指針 標準化の目的、ＥＳＣメッセージ構造の標準 化、業務メッセージの標準化、標準データの管 理及び標準化規約等について規定する。 開発規約 ＥＳＣの開発で適用する規約類として、シス テムメッセージ規約、ネーミング規約、コー ディング規約、ＨＭＩ規約、ヘルプ規約及び 技術規約 通信規約等につて規定する。 ・基準 設計図書記述要 領 全体設計書 ＥＳＣの開発で作成する設計図書の記述要領 を規定する。 ＣＯＥ＜ＳＯＡ＞の全事業に関わる規定とし て、事業全体の設計方針、設計条件、ＣＯＥ＜ ＳＯＡ＞の定義、インタフェース、要求条件、 機能／性能及び構成等につて規定する。 基本設計書 全体設計で規定された機能として、システム 設計工程 構成（ハード、ソフト）、細部機能／処理及び 図書 入出力データ仕様について細分化し規定する。 概要設計書 基本設計で規定された細部機能として、クラ ス図、シーケンス図、データ仕様、画面仕様、 メッセージ仕様及びパッケージ構成について規 定する。 56 区分 ドキュメント名 詳細設計書 記 述 内 容 概要設計で規定されたクラスについて、プロ グラムの内容とインタフェース仕様について規 製造工程 定する。 図書 試験工程 図書 試験計画書 総合試験、システム試験の計画を示す。 総合試験手順書 総合試験を実施するための手順書及びその成 績を示す。 システム試験手 順書 システム試験を実施するための手順書及びそ の成績を示す。 操作手順書 ＥＳＣ及びＣＯＥラボ機能に関する操作手順 を示す。 運用図書 技術マニュアル ＥＳＣの外部インタフェース仕様及び利用に 関する情報を示す。 ラボ運用要領 ＣＯＥラボの運用、維持整備要領に関する情 報を示す。 適用システム開 ガイド 図書 ＣＯＥ＜ＳＯＡ＞を適用した適用システム開 発ガイド 発のガイドラインとして、ＥＳＣの役割、機 （ＳＯＡ） 能 、 適 用 例 、 設 計 /開 発 要 領 及 び 動 作 環 境 構 築 要領について規定する。 注：太字（斜体）は適用システム側に渡す図書を示す。 第２節 １ 開発技法 開発技法概要 適用システムが有する機能を、サービス化するための技法及びそれらを利用 する技法を概説する。サービス化による接続方式の共通化は、適用システム内 だけでなく、他システムからのサービスの利用も容易とし、業務単位での機能 の再利用性を高める効果を生む。結果として柔軟かつ容易なシステム間連携を 実現する。 ２ サービス指向開発 57 (1) 目的 機能の再利用性、変化への柔軟性をもったシステムの実現を目的とする。 (2) 手法 サービスは、複数のリクエスタの要求を一元的に受け付けて処理を行うも のである。サービスを開発するにあたり、その手法について、作業フェーズ 毎に示す。 ア サービス抽出（業務分析） システム開発に先立って実施される業務分析段階で、サービスの候補と すべき業務を抽出することで、業務効率化のための本質的な対応が可能と なるとともに、システム設計工程以降で、業務と矛盾しない成果を得るた めの下地を作ることができる。業務上の観点としては、次の項目が候補と なる。 (ｱ) データを一元的に管理すべきもの (ｲ) 要求の形式と処理の方式を一様にできるもの (ｳ) 複数の要求者（リクエスタ）が想定できるもの (ｴ) １度の要求でその業務目的が達成される単位に分割統合されているも の イ サービス設計 機能をサービスとして設計するということは、機能を、サービスを提供 するプロバイダと、プロバイダにサービス提供を要求するリクエスタの関 係に定義し、整理していくことである。 多くのリクエスタから利用（再利用性向上）されるサービスを実現する ため、サービスを定義する際は、次の事項を考慮する。 (ｱ) サービスの価値を確保 データ、機能を一元化したものとすることで、その存在意義を向上さ せることができる。 (ｲ) サービス個々の独立性の確保 サービスは、リクエスタからの１度の要求とそれに応える処理で、そ の業務目的を完結させる単位で設計する。理由は次のとおりである。 ａ サービスの組合せによる業務フローの構築とその組換えを容易にす るというＳＯＡの本質的な目的を達成するため。 ｂ 複数のサービスを跨いでデータの整合を図ることが、疎結合という 性質から技術的に困難であるため。 58 ウ サービスの開発 開発にあたっては、大きく新規開発と、既存資産の活用の２つの方式が ある。ＣＯＥ＜ＳＯＡ＞は、アプリケーションインタフェースとしてＥＳ Ｃアダプタを提供する。ＥＳＣアダプタはＪａｖａで実装しており、Ｊａ ｖａアプリケーションはそのままＡＰＩを利用することができる。他言語 アプリケーションからの利用も、ＪＮＩを使うことで可能である。また、 ＣＯＥ＜ＯＯＡ＞適用システムとの接続のために、専用アダプタであるア ダプタ（ＯＯＡ）を提供し、ツールを利用して変換定義等を設定すること で接続を実現することを可能としている。 既存資産の活用については、業務ロジック部分を生かしつつ、ＥＳＣの インタフェースに合わせるための改修を加えることで実現可能である。既 存資産については、システム毎に多様な実装となっているため、各適用シ ステムが独自に対応することになるが、極力適用システムの負担を低減す るため、アダプタ（レガシー）を提供し、なるべく開発負担を軽減する。 エ サービスの利用 システムを設計する際に、活用可能な既存サービスがある場合は、独自 に作込まず既存サービスを活用することを基本とする。また、複数のサー ビスを組み合せて一連の業務を実現する際、そのプロセスに変更が生じる 可能性の高い業務については、ビジネスプロセス管理を利用して業務環境 の変化に応じた柔軟な対応を可能にしておく。 オ データの標準化 データのＸＭＬ化、データ型及びコードの標準化を実施する。適用シス テムは、ＣＯＥ管理室より次の事項の提供を受け、サービスのデータを設 計する。 (ｱ) 標準データ設計の考え方、データ型とコード等を規定した標準化指針 (ｲ) ＣＯＥ管理室で管理する既に公開済みのサービスのインタフェース (ｳ) データの編集を補助する標準データ設計支援機構（ツール） なお、サービスの運用にあたり、サービスインタフェースは、ＣＯＥ 管理室において適合性確認を受けた後管理され、他適用システムへ公開 される。 (3) 期待効果 ア システム共通の情報共有基盤の提供 イ 運用の変化に対して迅速な対応を実現 59 ３ ウ 段階整備される事業の遂行が容易 エ 情報の重複管理及び機能の重複開発を防止 オ データの標準化による情報共有の効果を拡大 フレームワーク利用 (1) 目的 複数のシステム間での運用を想定した、リクエスタとサービスによる安全 で容易な情報共有基盤の実現により、システム間の情報共有促進を目的とす る。 (2) 手法 ＣＯＥ＜ＳＯＡ＞では、情報共有のための論理ネットワークを形成し、そ の利用を容易にするミドルウェアとしてＥＳＣを提供する。 ア システム間連携の手順の標準化 適用システムは、ＥＳＣが規定する手順で、全てのサービスを利用する ことができる。 イ サービスの利用形態のパターン 同期及び非同期、１：１及び１：Ｎ、加えて非同期については応答あり 及び応答なしの組合せとパブリッシュ＆サブスクライブ（配布＆購読）の ７通りの形態でメッセージを送信することができる。また、サービスの複 雑な連携をプロセスフローとして定義し、定型処理として実行するための ビジネスプロセスフロー機能も有する。適用システムは、業務上必要なパ ターンを用いて、サービスを活用する。細部は、第７節で説明する。 ウ 疎結合 適用システムが他サービスにアクセスする際、意識するのはＥＳＣアダ プタのンタフェースのみである。これにより、接続先のシステムはＥＳＣ により隠蔽された形となり、適用システムは、サービスやリクエスタがど のような実装であるかにとらわれずに利用することができる。 結果として、適用システム間の連接は疎結合となり、システム変更等の 相互の影響を受けにくくなる。 エ セキュリティ ＥＳＣのセキュリティを考えるにあたって、ＥＳＣ論理空間に対する脅 威を洗い出し、大きく次の２つに分類した。 (ｱ) ＥＳＣが機能として対抗すべき脅威 60 (ｲ) 適用システムが、ＥＳＣを利用する環境整備の中で対処すべき脅威 この成果は、ＥＳＣセキュリティポリシーとしてまとめている。 (3) 期待効果 適用システムは次の効果を期待できる。 ア 接続先のシステムとの技術的な調整、個別の実装から負担が軽減される。 イ セキュリティが確保されているので、安全に利用できる。 ウ ＥＳＣアダプタのインタフェース以外は、適用システムの実装を制約し ない。 エ （4) ＥＳＣは、システムの逐次拡張及び変更に対して容易に対応できる。 留意事項 ア ＥＳＣコアの設置については、ＥＳＣ全体の論理ネットワークとの連携 が必要となるため、トポロジーの構成等についてＣＯＥ管理室及びＤＩＩ と調整を実施すること。 イ サービスを構築する際は、インタフェースの仕様と公開、データの標準 化及び運用に関するルールについて、ＣＯＥ管理室と調整を実施すること。 ウ サービスの利用については、サービス提供部門に対してＣＯＥ管理室と ともにその利用について調整すること。 エ ＤＩＩオープン系、ＤＩＩクローズ系を跨ったサービスの利用を行う場 合、ＤＩＩ連接装置の利用が必要であるため、ＣＯＥ管理室及びＤＩＩと 調整を実施すること。 オ ＥＳＣを利用して省外の外部システムとの接続を実施する場合、ガード 装置の利用が必要であるため、ＣＯＥ管理室及びＤＩＩと調整を実施する こと。 カ ＥＳＣは機能としてのセキュリティを確保しているが、運用やＥＳＣの 設置等に関する部分でのセキュリティの確保は適用システムとなる。ＥＳ Ｃ論理空間のセキュリティを確保するために、各適用システムが適切なセ キュリティ対策を施すことが必要である。 第３節 １ システムモデル システムモデルの概要 ＳＯＡの技術構成について、主要な技術をモデルとして表４－２に示す。 なお、システムモデルはＥＳＣの内部機能の実装に関する技術モデルを示す 61 ものである。 表 ４－２ システムモデル概要 システムモデル名 情報共有論理ネッ トワークモデル モ デ ル 概 要 各適用システムで運用するＥＳＣは、他の適用システ ムのＥＳＣと連携することができる。これにより防衛省 内でＥＳＣによる論理ネットワークの構築を可能とし、 システムの枠を超えた情報共有空間を実現する。 ・ＸＭＬメッセージングによる疎結合 ・ＥＳＣコア間で制御情報を共有する機能を持ち連動す る。 ・ＥＳＣの論理ネットワークを要となる装置を、ＤＩＩ のサービスとして整備する。 ・複数ＯＳを動作環境とすることによる適用柔軟性確保 防衛省セキュリ ティモデル ＥＳＣ論理空間について防衛省として求められるセ キュリティを実装する。 ・サービス単位の情報フロー制御 ・ＤＩＩの統合認証基盤に対応した認証サービス、認可 サービスと連携することにより、システムの枠を超えた セキュリティ空間を実現 ・ＤＩＩオープン系、ＤＩＩクローズ系間の保全を確保 した情報共有の実現 ２ (1) 情報共有論理ネットワークモデル ＥＳＣによる情報共有 従来のシステムでは、各適用システムは、独立したネットワークの中に、 業務アプリケーションの実装環境、通信プロトコルを個別に実装する。 したがって、各システムは技術的に高い独立性を持つことになり、システ ム間で接続する場合は、そのための特別な考慮が必要なる。 一方、ＥＳＣはＥＳＣコア同士の連携を前提に設計されており、各システ ムを跨ったＥＳＣの論理ネットワークによるサービス層を形成する。各シス テムで構築したサービスは、このサービス層上で他のシステムへサービスを 提供することになる。 論理ネットワークを実現するＥＳＣの技術要素を次に述べる。また、サー 62 ビス層のイメージを図４－３に示す。 図４－３ サービス層のイメージ セキュリティ 脅威 セキュリティ 脅威 ＥＳＣ アクセス制御 アクセス制御 システム サービス システム システム サービス リクエスタ システム サービス アクセス制御 リクエスタ サービス アクセス制御 リクエスタ システム サービス アクセス制御 リクエスタ リクエスタ サービス アクセス制御 リクエスタ サービス層 情報共有 システム HP HP ＤＩＩオープン系 隠 ＤＩＩクローズ系 蔽 HP 他府省庁 防衛省 ア ＥＳＣ間連携 ＥＳＣ間でメッセージをルーティングするために必要な、サービスのア ドレス等、制御情報の同期機能を有する。また、効率的な同期を実現する ために、ＥＳＣコアは他のＥＳＣコアとトポロジーを構成し、１つの論理 ネットワーク空間を実現する。また、その論理空間には、省のインフラと して整備される各種装置も含まれる。ＥＳＣによる論理ネットワークのイ メージを図４－４及び図４－５に示す。 図４－４ ＥＳＣによる論理ネットワーク ESCコア ESCコア ESCコア Ｃシステム（陸自） Ａシステム（海自） ESCコア Ｅシステム（空自） ＥＳＣによる論理空間 ESCコア ESCコア Ｂシステム（海自） Ｆシステム（空自） Ｄシステム（陸自） 凡例 ＥＳＣコア リクエスタ アプリケーション サービス 63 図４－５ ＥＳＣコアのトポロジーのイメージ ＤＩＩオープン系 ＤＩＩクローズ系（防秘） ＤＩＩ 連接装置 ＤＩＩ 連接装置 ＤＩＩクローズ系（省秘） 共通 ＥＳＣコア ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） ガード装置 他府省ネットワーク ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） ＥＳＣコア （適用システム） 防衛省内の各適用システムが利用するネットワーク イ ＸＭＬ、ＳＯＡＰの活用 ＥＳＣを構成する各論理装置間の制御情報も含めた連携は、ＸＭＬとＳ ＯＡＰで実装する。これにより、各論理装置間の独立性を維持し、構成の 自由度を確保しつつ、柔軟性のある適用システム間の情報共有を実現する。 ＸＭＬは、扱えるデータの種類の多さ、データ構造の規定と変更の柔軟 さ等データフォーマットとしての性能、アプリケーションで扱うデータと しての高い汎用性及び人間にとっても高い可読性を有するといったメリッ トを有し、ＳＯＡによる情報共有に最も適合する。また、ＳＯＡＰは、Ｘ ＭＬメッセージに特化したプロトコルであり、相互のアプリケーションの 実装に影響を与えにくい特性を持ち、ＳＯＡの概念に最も適合する。ＥＳ Ｃ通信プロトコルについて図４－６に示す。 64 図４－６ ＥＳＣ通信プロトコル 認可 サービス XML 業務データ 取 り 出 し リクエスタ SO AP AP SO サービス アプリケーション 認証 サービス ＥＳＣ SOAP ＥＳＣコア アダプタ SOAP ＥＳＣコア SOAP ＥＳＣコア アダプタ 格 納 XML 業務データ SOAP エンベロープ SOAP エンベロープ リクエスタ アプリケーション SOAP ＥＳＣ XML 業務データ プログラム言語等、異なる技術で実装された アプリケーションも接続できる ウ マルチＯＳ対応 ＥＳＣはその動作環境として、適用システム側のシステム環境への制約 を低減し、設計自由度の確保とコスト低減効果を目的として、主要ＯＳで ある Windows、Solaris、HP-UX、Linux へ対応することが求められた。 この要件を満たすため、ＥＳＣはＪａｖａで実装されている。 これにより、ソース変更、リコンパイルなしに他のＯＳ環境への移行が 行える。Ｊａｖａの移行性について図４－７に示す。 図４－７ Ｊａｖａの移行性 移行 Ｊａｖａ アプリケーション ＶＭ Ｆｏｒ windows Windows (2) 移行 Ｊａｖａ アプリケーション ＶＭ Ｆｏｒ Solaris Solaris 移行 Ｊａｖａ アプリケーション ＶＭ Ｆｏｒ Ｌｉｎｕｘ Linux Ｊａｖａ アプリケーション ＶＭ Ｆｏｒ ＨＰ－ＵＸ HP-UX 論理ネットワーク形成のための要素 ア ＥＳＣ間でメッセージをルーティングするために必要な、サービスのア ドレス等、制御情報の同期機能を有する。 イ ＥＳＣ間でメッセージや制御情報を効率的にルーティングするため、Ｅ 65 ＳＣコアはトポロジーを形成する。 ウ 省レベルの論理ネットワークを形成するために、省のインフラとして整 備される共通サービスと連携する。 ３ (1) 防衛省セキュリティモデル 情報フロー制御 ＥＳＣの論理空間には、異なるセキュリティレベルのシステムが混在する ため、誤った情報の流れが生じないよう、秘密区分に基づいた情報フロー制 御を実装する。ＥＳＣによる情報フロー制御の概念を図４－８に示す。 図４－８ 情報フロー制御の概念図 保護プロファイルと取り扱う情報の秘区分 ＭＯＤ-１ 流れ る 情 報の秘 区 分 注意以下 ＭＯＤ-２ 省秘 防秘 ＭＯＤ-３ 省秘 防秘 防秘 防秘 防秘 省秘 省秘 省秘 注意 以下 注意 以下 省秘 注意 以下 凡例 注意 以下 同一の秘区分による情報空間 双方向に情報を流せる 片方向のみに情報を流せる（情報を取得した適用システム側で秘区分が変更になる） ＭＯＤ－１及びＭＯＤ－２対応システムは同一システム内で取り扱う情報 の秘区分を区別せず、ＭＯＤ－３対応システムでは同一システム内で取り扱 う情報に応じて複数の秘区分を区別する。そのため、システム間で片方向若 しくは双方向での送受信が可能なパターンが存在することとなり、このシス テム間で流れる情報を秘区分に応じて制御することを「情報フロー制御」と 呼ぶ。 66 なお、ＭＯＤ－２対応システムにおいては、自システムの秘区分と受取る 情報の秘区分が異なる場合、受取った情報の秘区分を自システムの秘区分と して取り扱うことになる。システム間連携における秘区分の遷移例を図４－ ９に示す。 図４－９ (2) システム間連携における秘区分の遷移例 適用システムＡ 適用システムＡ 適用システムＢ 適用システムＢ 適用システムＣ 適用システムＣ 保護プロファイル： ＭＯＤ－３（省秘） 保護プロファイル： ＭＯＤ－２（省秘） 保護プロファイル： ＭＯＤ－２（防秘） 情報 （秘区分：注意以下） 情報 （秘区分：省秘） 情報 （秘区分：防秘） 情報の流れ 情報の流れ 防衛省のセキュリティを実現するための考慮 ア サービス、リクエスタ、ユーザＩＤ及びメッセージの秘密区分の識別を 可能とし、秘密区分によるアクセス制御を行う機能を有する。 イ サービスへのアクセス制御として、ユーザＩＤ及びグループ単位でアク セス権を設定する機能を有する。 ウ メッセージの盗聴を防止するため、メッセージの秘匿を行える機能を有 する。 エ メッセージのなりすまし及び改ざん並びにＥＳＣコア及びＥＳＣアダプ タのなりすましを防ぐため、署名付与及び検証機能を有する。 オ システムの枠を超えたセキュリティ空間を形成するため、ＤＩＩの統合 認証基盤と連携し、ＤＩＩネットワークをセキュリティバウンダリとする ことを可能とする。 第４節 １ 適用モデル 適用モデルの概要 ＣＯＥ＜ＳＯＡ＞の基本的適用モデルの概要を表４－３に示す。 なお、適用システムモデルは、適用システム構築において、ＥＳＣの利用形 態モデルを示すものである。 67 表 ４－３ ＣＯＥ＜ＳＯＡ＞の基本的適用モデル 基本的適用モデル名 標準的なモデル モ デ ル 概 要 最も典型的な例として、次の構成で構築する。 ・ＥＳＣアダプタをインタフェースとしたサービ ス、リクエスタ ・適用システムで運用するＥＳＣコア ・認証サービス ・認可サービス ＣＯＥ＜ＯＯＡ＞適用 ＣＯＥ＜ＯＯＡ＞適用システムの場合の構成 システムとの接続モデ ・アダプタ（ＯＯＡ）をインタフェースとして、 ル ＯＯＡの業務をサービス、リクエスタとする。 ・適用システムで運用するＥＳＣコア ・認証サービス ・認可サービス レガシーシステムとの レガシーシステムの場合の構成 接続モデル ・アダプタ（レガシー）をインタフェースとした サービス、リクエスタ ・適用システムで運用するＥＳＣコア ・認証サービス ・認可サービス ＤＩＩオープン系、Ｄ ＤＩＩオープン系のシステムと、ＤＩＩクローズ ＩＩクローズ系間の 系のシステム間でのサービス利用の場合の構成と サービス連携モデル して、各システムが準備する①～③の構成と合わ せてＤＩＩ連接装置が必要 省外システムとの接続 省外システムとの接続の場合の構成として、各シ モデル ステムが準備する①～③の構成と合わせてガード 装置が必要 68 ２ 標準的なモデル 適用システム内において、ＥＳＣの基本構成は、ＥＳＣコア、ＥＳＣアダプ タ及び認証・認可サービスによって構成される。 (1) 概説 適用システムは、ＥＳＣによる論理ネットワークへの出入口としてのＥＳ Ｃコアを持ち、その下にリクエスタ及びサービスへインタフェースを提供す るＥＳＣアダプタを配する。ＥＳＣコアの数は、システムの設計に応じて複 数構成することができる。また、リクエスタの認証を行うための認証サービ ス及びサービスへのアクセス可否判断を行う認可サービスを配置し運用する。 リクエスタ及びサービスは、ＥＳＣアダプタ配下に配置する。標準的なモデ ルを図４－１０に示す。 図４－１０ 標準的なモデル 適用システム 省インフラ 統合認証基盤 認証 サービス 共通ＥＳＣコア ESC ｺｱ 他システム 認可 サービス 業務アプリケーション リクエスタ 他システム ESC ｱﾀﾞﾌﾟﾀ サービス 他システム 他システム ＤＩＩネットワーク 適用システムで準備するもの ＣＯＥが提供するもの (2) 留意事項等 ア 適用システムへ配置するＥＳＣコアやＥＳＣアダプタは、当該システム の規模や構成に合わせて何台でも配置することができる。また、１つのＥ ＳＣコアの配下には、複数のＥＳＣアダプタを配置することができ、１つ のＥＳＣアダプタの配下には、複数のリクエスタ及びサービスを配置する ことができる。 イ 省全体のＥＳＣ論理ネットワークへの接続を行う場合は、省インフラと 69 して提供されている共通ＥＳＣコアの配下に、適用システムのＥＳＣコア は配置されることになる。また、認証サービスは、統合認証基盤を認証基 盤として設定し、そのＥＳＣに関する電子証明書は、統合認証基盤配下の 認証局より発行したものを使用する。 ウ リクエスタ、サービスは、ＥＳＣへのインタフェースはＥＳＣアダプタ として提供されるが、サービスの業務内容に関する実装は、適用システム 側の構成に合わせて設計開発するものである。 エ 原則としては、適用システムはＥＳＣ論理空間への出入口として、ＥＳ Ｃコアを設置すると考えるが、システム規模等なんらかの理由によりＥＳ Ｃコアの設置が難しい場合、共通ＥＳＣコアを利用するこができる。その 場合は、適用システムのＥＳＣアダプタは、直接共通ＥＳＣコアに接続す ることになる。 なお、共通ＥＳＣコアの利用については、運営管理部門と調整する必要 がある。 ３ ＣＯＥ＜ＯＯＡ＞適用システムとの接続モデル ＣＯＥ＜ＯＯＡ＞適用システムにおいては、標準的なモデルで必要となるＥ ＳＣの構成に、アダプタ（ＯＯＡ）が加わる。 (1) 概説 アダプタ（ＯＯＡ）以外の各論理装置の役割は、標準的なモデルの場合と 同様である。 アダプタ（ＯＯＡ）は、ＥＳＣのデータ形式と、ＯＯＡのデータ形式の変 換を行う役割を担う。これにより、ＣＯＥ＜ＯＯＡ＞適用システムが持つ業 務を、サービスやリクエスタとして容易に活用することを可能とするもので ある。ＣＯＥ＜ＯＯＡ＞適用システムとの接続モデルを図４－１１に示す。 70 図４－１１ ＣＯＥ＜ＯＯＡ＞適用システムとの接続モデル 省インフラ 適用システム ＤＢサーバ 統合認証基盤 他システム ＡＰサーバ 他システム 共通ＥＳＣコア 他システム 他システム 認証 認可 サービス サービス ESC ｺｱ 業務 業務 業務 ｱﾀﾞﾌﾟﾀ （ＯＯＡ） ESC ｱﾀﾞﾌﾟﾀ 認証 サーバ 標準的なモデル構成 変換定義 ファイル 変換 プログラム ビューア （クライアント） ＤＩＩネットワーク データ コンテナ データ クラス 開発支援機構 （ツール） 適用システムで準備するもの ＣＯＥが提供するもの (2) 留意事項等 ア 標準的なモデルの留意事項はそのまま該当する。 イ ＣＯＥ＜ＯＯＡ＞の業務を、リクエスタ及びサービスとする場合、アダ プタ（ＯＯＡ）の機能として有する変換定義、変換プログラムを設定する 必要がある。変換定義、変換プログラムの作成は、ツールとして提供する 開発支援機構を利用することができる。 なお、業務要件で発生する業務処理部分の変更は、適用システム側での 開発作業となる。 ４ レガシーシステムとの接続モデル レガシーシステムにおいては、標準的なモデルで必要となるＥＳＣの構成に、 アダプタ（レガシー）が加わる。 (1) 概説 アダプタ（レガシー）以外の各論理装置の役割は、標準的なモデルの場合 と同様である。 アダプタ（レガシー）は、ＥＳＣのデータ形式と、レガシーシステムのプ ロトコル、データ形式の変換を行う役割を担う。これにより、レガシーシス テムの資産を、サービスやリクエスタとして容易に活用することを可能とす るものである。レガシーシステムとの接続モデルを図４－１２に示す。 71 図４－１２ レガシーシステムとの接続モデル 省インフラ 統合認証基盤 他システム 他システム 適用システム 認証 認可 サービス サービス レガシー資産 共通ＥＳＣコア 他システム 他システム ESC ｺｱ ESC ｱﾀﾞﾌﾟﾀ 標準的なモデル構成 ＤＩＩネットワーク ｱﾀﾞﾌﾟﾀ レガシー （レガシー） インタフェース （要開発） 共通機能 変換定義 ファイル 変換 プログラム クラス解析 結果ﾌｧｲﾙ 開発支援機構 （ツール） 適用システムで準備するもの ＣＯＥが提供するもの (2) 留意事項等 ア 標準的なモデルの留意事項はそのまま該当する。 イ レガシーシステム資産を、リクエスタ又はサービスとする場合、アダプ タ（レガシー）の共通機能として有する変換定義、変換プログラムを設定 する必要がある。変換定義の作成は、ツールとして提供する開発支援機構 を利用することができるが、変換プログラムは適用システム側で準備する。 ウ サービス化することにより発生する業務処理部分の変更は、適用システ ム側での開発作業となる。 エ アダプタ（レガシー）共通機能との連携するためのインタフェース部分 については、適用システム側の実装が各システムで異なるため、共通部品 化できない部分である。したがって、各適用システムにおいてプロトコル 変換等を開発する必要がある。 ５ ＤＩＩオープン系、ＤＩＩクローズ系間のサービス連携モデル ＤＩＩ連接装置により、ＤＩＩオープン系及びＤＩＩクローズ系それぞれの システム間で、サービスを利用する。 (1) 概説 異なるネットワークに存在するサービスについて、保全上の条件を満たす 場合、ＤＩＩ連接装置を経由して相互に利用することを可能とする。ＤＩＩ オープン系、ＤＩＩクローズ系間のサービス連携モデルを図４－１３に示す。 72 図４－１３ ＤＩＩオープン系、ＤＩＩクローズ系間のサービス連携モデル 省インフラ 省インフラ 統合認証基盤 統合認証基盤 他システム 適用システム リクエスタ サービス リクエスタ サービス 共通ＥＳＣコア ＤＩＩ連接装置 共通ＥＳＣコア 他システム 他システム リクエスタ リクエスタ サービス サービス ＤＩＩオープン系 ＤＩＩクローズ系 各システムのＥＳＣの構成は省略 適用システムで準備するもの ＣＯＥが提供するもの (2) 留意事項等 ア 適用システムは、ＤＩＩ連接装置をＥＳＣの適用モデル（標準、ＣＯＥ ＜ＯＯＡ＞、レガシー）に関わらず利用可能である。 イ 適用システムがＤＩＩ連接装置を利用する場合は、運営管理部門と調整 し、ネットワーク間連携の許可を得るとともにその設定を依頼する。 ウ 適用システム側による、ＤＩＩ連接装置の利用のための特別な開発は必 要ない。 ６ 省外システムとの接続モデル ガード装置により、保全を確保しつつ省外サービスの利用もしくは省外への サービスの提供を行う。 (1) 概説 異なるネットワークに存在するサービスについて、保全上の条件を満たす 場合、ガード装置を経由して相互に利用することを可能とする。省外システ ムとの接続モデルを図４－１４に示す。 73 図４－１４ 省外システムとの接続モデル 省インフラ 省外システム 適用システム 統合認証基盤 リクエスタ リクエスタ サービス サービス 共通ＥＳＣコア 他システム ガード装置 プロトコル データ変換 省外システム リクエスタ リクエスタ アダプタ（レガシー） で構築可能 サービス サービス ＤＩＩネットワーク 各システムのＥＳＣの構成は省略 (2) 留意事項等 ア 適用システムは、ガード装置をＥＳＣ適用モデル（標準、ＣＯＥ＜ＯＯ Ａ＞、レガシー）に関わらず利用可能である。 イ 適用システムがガード装置を利用する場合は、運営管理部門と調整し、 省外接続の許可を得るとともに設定を依頼する。 ウ 適用システム側による、ガード装置の利用のための特別な開発は必要な いが、ガード装置はＥＳＣのメッセージのみ通過させるため、他システム とのプロトコル変換等については、ガード装置の外側に配置する必要があ る。その変換処理の開発は適用システム側で実施する必要がある。変換処 理はアダプタ（レガシー）に実装することも可能である。 第５節 １ ＥＳＣ及び認証・認可サービス ＥＳＣの概要 ＥＳＣは、「ＥＳＣコア」と「ＥＳＣアダプタ」で構成され、「認証・認可 サービス」と連動する。各構成品については、以下のとおり説明する。 ２ (1) ＥＳＣコア ＥＳＣコアは、ＳＯＡ（サービス指向アーキテクチャ）の概念を取り入れ 74 た、アプリケーション間のＸＭＬメッセージによる情報交換を実現するため のミドルウェアである。 (2) 防衛省として必要なセキュリティへの考慮を行っている。 (3) ＥＳＣコアは、接続しているＥＳＣコア間で連携のために必要な情報につ いて自動的に整合することができる。これにより、各適用システムのＥＳＣ コア同士がひとつのＥＳＣによる論理ネットワークを形成し、情報共有空間 を構成する。 ３ ＥＳＣアダプタ ＥＳＣアダプタは、業務アプリケーションであるリクエスタ及びサービスが ＥＳＣコアと接続してメッセージを送受信するためのインタフェースを提供す る。リクエスタ及びサービスとＥＳＣの接点を、ＥＳＣアダプタの提供するイ ンタフェースのみに限定することで、実装の容易性及び保全性を向上させてい る。 ４ アダプタ（ＯＯＡ） アダプタ（ＯＯＡ）は、ＣＯＥ＜ＯＯＡ＞適用システムが持つ業務をサービ スやリクエスタとするために、ＥＳＣアダプタとＣＯＥ＜ＯＯＡ＞の間に配置 され、相互のプロトコル及びデータの変換を行う。 ５ アダプタ（レガシー） アダプタ（レガシー）は、レガシーシステムが持つ資産を、サービスやリク エスタとするために、ＥＳＣアダプタとレガシーシステムの間に配置され、相 互のプロトコル及びデータの変換を行う。ただし、レガシーシステムの作りは 一様でないため、レガシーシステム側のインタフェースについては、各適用シ ステムで実装する必要がある。 ６ (1) 認証サービス 認証サービスは、当該適用システムのリクエスタからのメッセージについ て、正規のユーザ、リクエスタからのものであることを認証するためのサー ビスであり、ソフトウェア部品として提供される。 (2) 認証サービスは、メッセージに添付されるアダプタの証明書についてＰＫ Ｉ認証を行うため、認証基盤と接続する。 75 (3) ７ 認証サービスは、適用システムで運用され、その管理について責任を負う。 認可サービス (1) 認可サービスは、当該適用システムのサービスに対するアクセス権の情報 を管理し、その情報に基づきリクエストメッセージのサービスへの送達可否 を判断するためのサービスであり、ソフトウェア部品として提供される。 (2) 認可サービスは、当該適用システムのサービスを不正アクセスから防御す るものであり、適用システムで運用され、その管理について責任を負う。 第６節 １ 標準化 標準化の目的 標準化の目的は、ＣＯＥ<ＯＯＡ>適用システムやレガシーシステム等の異 なった構築手法に基づく機能をサービス化し、統一された手順で利用できるよ うにすることによって、再利用性、連接性を高め、新たな業務への進展を容易 とすることで、システム構築の費用対効果や運用性を高めることである。 ２ 標準化対象 (1) 概要 ＣＯＥ＜ＳＯＡ＞においては、ＥＳＣが送達しているメッセージを標準化 の対象とし、ＳＯＡＰメッセージの構造を基盤に、ＥＳＣとしての規定を加 えたメッセージ構造を規定するとともに、標準文字コード、業務メッセ－ジ 構造（標準データを含む。）を規定している。 (2) ＥＳＣのメッセージ構造 ＥＳＣメッセ－ジは、ルーティング情報、セキュリティ情報及び業務情報 で構成される。 ア ルーティング情報 メッセージのルーティング情報を制御する情報を記述する。 イ セキュリティ情報 メッセージを安全に送達するための情報を記述する。 ウ 業務情報 リクエスタとプロバイダの間でやりとりされる業務メッセージとＥＳＣ が業務メッセージを処理する上で必要となる管理情報から構成される。 76 (3) 標準文字コード ＥＳＣメッセ－ジで使用する標準の文字コードは、ＸＭＬの標準とされて いるコード体系とエンコード型式を採用している。また、外字についても、 標準外字として統一しており、適用システムで使用する外字コードが標準と 異なるものを使用する場合は、ＥＳＣアダプタでコード変換を行う。 (4) 業務メッセージ 業務メッセージは、標準データとして管理される複数のサービスインタ フェースで構成され、その設計にあたっては、標準化指針で定める規定に基 づいた設計を行う。 (5) 標準データ 標準データとして管理される対象は、サービスインタフェース、データ セット、標準タグ及び標準コードである。サービスを設計する際は、既に登 録済みの標準データを再利用することを原則とする。 第７節 １ サービス利用形態 サービス利用形態の概要 ＣＯＥ<ＳＯＡ>におけるサービスの利用形態は８つのメッセージパターンに より分類される。各メッセージパターンはリクエスタが設定・送信するメッ セージの内容に従ってＥＳＣコアがサービスへメッセージを送信する。ＣＯＥ ＜ＳＯＡ＞のメッセージパターンを表４－４に示す。 表４－４ 番号 メッセージパターン １ １：１メッセージルー ティング（同期） メッセージパターン 説 明 １回の同期メッセージ送信により１つの サービスを利用するメッセージパターンであ る。 ２ １：Ｎメッセージルー ティング（同期） １回の同期メッセージ送信により複数の サービスを利用するメッセージパターンであ る。 77 番号 メッセージパターン ３ １：１メッセージルー 説 明 １回の非同期メッセージ送信により１つの テ ィ ン グ （ 非 同 期 応 サービスを利用するメッセージパターン。リ 答なし。） ４ １：Ｎメッセージルー クエスタへ結果の返却はされない。 １回の非同期メッセージ送信により複数の テ ィ ン グ （ 非 同 期 応 サービスを利用するメッセージパターンであ 答なし。） ５ １：１メッセージルー る。リクエスタへ結果の返却はされない。 １回の非同期メッセージ送信により１つの テ ィ ン グ （ 非 同 期 応 サービスを利用するメッセージパターンであ 答あり。） ６ １：Ｎメッセージルー る。 １回の非同期メッセージ送信により複数の テ ィ ン グ （ 非 同 期 応 サービスを利用するメッセージパターンであ 答あり。） ７ パブリッシュ＆サブス クライブ る。 リクエスタの依頼により、ＥＳＣコアが予 め設定された宛先へブロードキャストする メッセージパターンである。 ８ ビジネスプロセス リクエスタの依頼により、ＢＰＭエンジン がビジネスプロセスフローに基づいたサービ スの連携を行うメッセージパターンである。 ２ (1) 各メッセ－ジパターンの概要 １：１メッセージルーティング（同期） １：１メッセージルーティング（同期）は、１回のメッセージ送信をリク エスタが行うことにより、１つのサービスを利用するメッセージパターンで ある。このメッセージパターンは同期通信により行われるため、リクエスタ はメッセージ送信から応答結果の受信までの間処理を待機させておく必要が ある。１：１メッセージルーティング（同期）のイメージを図４－１５に示 す。 78 図４－１５ (2) １：１メッセージルーティング（同期） １：Ｎメッセージルーティング（同期） １：Ｎメッセージルーティング（同期）は、１回のメッセージ送信をリク エスタが行うことにより、複数のサービスを利用するメッセージパターンで ある。このメッセージパターンは同期通信により行われるため、リクエスタ はメッセージ送信から応答結果の受信までの間処理を待機させておく必要が ある。ただし、複数のサービスからの応答結果は順不同となるので、リクエ スタが任意の順序で応答結果を受け取りたい場合は、順序を制御する処理の 考慮が必要となる。１：Ｎメッセージルーティング（同期）のイメージを図 ４－１６に示す。 図４－１６ (3) １：Ｎメッセージルーティング（同期） １：１メッセージルーティング（非同期 応答なし。） １：１メッセージルーティング（非同期 応答なし。）は、１回のメッ セージ送信をリクエスタが行うことにより、１つのサービスを利用するメッ セージパターンである。このメッセージパターンは応答結果が返却されない 79 ため、リクエスタは応答結果を受信する必要がない半面、サービスにメッ セージが到達したかを判別することができない。また、メッセージの信頼性 を担保するため、何らかの事情によりサービスにメッセージを送信できない 場合は、ＥＳＣコアにより定期的に再送が行われる。１：１メッセージルー ティング（非同期 応答なし）のイメージを図４－１７に示す。 図４－１７ (4) １：１メッセージルーティング（非同期 応答なし。） １：Ｎメッセージルーティング（非同期 応答なし。） １：Ｎメッセージルーティング（非同期 応答なし。）は、１回のメッ セージ送信をリクエスタが行うことにより、複数のサービスを利用するメッ セージパターンである。このメッセージパターンは応答結果が返却されない ため、リクエスタは応答結果を受信する必要がない半面、サービスにメッ セージが到達したかを判別することができない。また、メッセージの信頼性 を担保するため、何らかの事情によりサービスにメッセージを送信できない 場合は、ＥＳＣコアにより定期的に再送が行われる。１：１メッセージルー ティング（非同期 応答なし。）のイメージを図４－１８に示す。 80 図４－１８ (5) １：Ｎメッセージルーティング（非同期 応答なし。） １：１メッセージルーティング（非同期 応答あり。） １：１メッセージルーティング（非同期 応答あり。）は、１回のメッ セージ送信をリクエスタが行うことにより、１つのサービスを利用するメッ セージパターンである。このメッセージパターンは非同期通信により行われ るため、リクエスタは応答結果を受信のために処理を待機させる必要がない。 また、メッセージの信頼性を担保するため、何らかの事情によりサービスに メッセージを送信できない場合は、ＥＳＣコアにより定期的に再送が行われ る。１：１メッセージルーティング（非同期 応答あり。）のイメージを図 ４－１９に示す。 図４－１９ １：１メッセージルーティング（非同期 応答あり。） 81 (6) １：Ｎメッセージルーティング（非同期 応答あり。） １：Ｎメッセージルーティング（非同期 応答あり。）は、１回のメッ セージ送信をリクエスタが行うことにより、複数のサービスを利用するメッ セージパターンである。このメッセージパターンは非同期通信により行われ るため、リクエスタは応答結果を受信のために処理を待機させる必要がない。 ただし、複数のサービスからの応答結果は順不同となるので、リクエスタが 任意の順序で応答結果を受け取りたい場合は、順序を制御する処理の考慮が 必要となる。また、メッセージの信頼性を担保するため、何らかの事情によ りサービスにメッセージを送信できない場合は、ＥＳＣコアにより定期的に 再送が行われる。１：Ｎメッセージルーティング（非同期 応答あり。）の イメージを図４－２０に示す。 図４－２０ (7) １：Ｎメッセージルーティング（非同期 応答あり。） パブリッシュ＆サブスクライブ パブリッシュ＆サブスクライブは、リクエスタがＥＳＣコアに対し、当 メッセージパターンの送信依頼を行うと、ＥＳＣコアは予め設定された１つ 以上の宛先に対し、メッセージを送信するメッセージパターンである。この メッセージパターンは非同期応答なしで行われるため、リクエスタに応答結 果の返却はされない。また、メッセージの信頼性を担保するため、何らかの 事情により送信先にメッセージを伝達できない場合は、ＥＳＣコアにより定 期的に再送が行われる。パブリッシュ＆サブスクライブのイメージを図４－ ２１に示す。 82 」 図４－２１ (8) パブリッシュ＆サブスクライブ ビジネスプロセス ビジネスプロセスは、予め設定されたビジネスプロセスフローに基づき、 ＥＳＣコアに接続されたＢＰＭエンジンが複数のサービスの連携を行うメッ セージパターンである。１：Ｎメッセージルーティングとは異なり、リクエ スタはあたかも複数のサービスを１つのサービスのように利用することがで きる。ビジネスプロセスは、事前にビジネスプロセスフローの設計及び設定 を行う必要がある。あるサービスの結果により、次のサービスを利用するか 否かという判断などをＢＰＭエンジンが設定されたビジネスプロセスフロー に基づいて自動的に実行する。ビジネスプロセスのイメージを図４－２２に 示す。 図４－２２ ビジネスプロセス 統幕指運第１２２号（２３．６．２２）別冊付録 標準クラス一覧 統合幕僚監部 平成２３年６月 分類番号：Ｌ３－Ｌ３２ 保存期間：１０年 保存期間満了日：３４．３．３１ 目 次 １ 標準業務クラス（ＣＯＥ＜ＯＯＡ＞） ･･････････････････････････ 1 ２ 標準部品クラス（ＣＯＥ＜ＯＯＡ＞） ･･････････････････････････ 5 ３ 標準部品クラス（ＣＯＥ＜ＲＴ＞） ････････････････････････････ 12 ４ 標準インフラサービス ････････････････････････････････････････ 16 1 標準クラス一覧 標準クラスは、次の表に示す種類で基本的な枠組みを構成している。 １ 標準業務クラス（ＣＯＥ＜ＯＯＡ＞） 標準クラスの種類 状況表示業 現況表示 機能の概要 １ 務 作戦の現況を把握するため、航跡情報を最 新情報に基づき状況図又は一覧表に表示す る。 ２ 本機能には、初期表示、自動更新、現況一 覧表示、要約情報表示及び詳細情報表示があ る。 航跡履歴／計画 １ 表示 作戦の経緯又は今後の行動予定の把握を行 うため、蓄積された計画及び航跡履歴情報を 検索し、状況図等に表示する。 ２ 航跡履歴の機能として、状況図表示、一覧 表示、詳細情報表示、シンボル表示、イメー ジ表示、イメージ登録、動画表示、航跡表示 設定、航跡点情報表示、履歴表表示及び履歴 状況図表示がある。 ３ 計画表示の機能として、状況図表示、一覧 表示、詳細情報表示、シンボル表示、イメー ジ表示、イメージ登録、動画表示、航跡表示 設定、航跡点情報表示、計画表表示、新規作 成、変更及び削除がある。 リプレイ／ １ プリプレイ 作戦の経緯又は今後の行動予定の把握を行 うため、計画及び航跡履歴から予定及び履歴 データを状況図上で連続表示する。 ２ 本機能には、リプレイ／プリプレイデータ 検索、再生、停止、一時停止、ファイル保存 及びファイル読み出しがある。 ランドマー １ ク管理 作戦に関する地理的な情報を把握するた め、ランドマーク情報を検索・表示する。 ２ 本機能には、状況図表示、一覧表示、詳細 情報表示、シンボル表示、新規作成、変更及 び削除がある。 2 標準クラスの概要 機能の概要 状況表示業 作 戦 区 域 管 １ 務（続き） 理 作戦に関する地理的な情報を把握するた め、作戦区域情報を検索・表示する。 ２ 本機能には、状況図表示、一覧表示、詳細 情報表示、図形表示、新規作成、変更及び削 除がある。 戦術通信 ＢＡＤＧＥ連接装置からバイナリデータとし て受信したＢＡＤＧＥ情報を標準データのコー ド体系や単位に変換しＣＲサーバへ転送する。 航跡管理業 相関管理 １ 務 他システムから受信又は手入力された航跡 情報と保有している航跡情報を条件に応じて 相関し、同一の航跡情報として表示する。 ２ 自動相関機能として、自動相関、相関条件 設定、出力条件設定（設定・表示）及び手動 送信がある。 ３ 手動相関の機能として、相関（手動）及び 相関履歴表示がある。 航跡管理 １ 作戦に関する地理的な情報を把握するた め、作戦区域情報を検索・表示する。 ２ 本機能には、状況図表示、一覧表示、詳細 情報表示、図形表示、新規作成、変更及び削 除がある。 緊 急 メ ッ 緊 急 メ ッ １ セージ業務 セージ管理 緊急情報の受信等、特に注意すべき情報に ついて注意喚起を行うため、メッセージを作 成、配布及び指定した宛先のクライアントに アラートを表示する。 ２ 本機能には、メッセージ一覧表示、テレタ イプ一覧表示、登録、削除及び送受信があ る。 戦術支援業 運動計算 １ 務 部隊の行動上の運動に関する判断を支援す るために簡易な予想計算を行う。 ２ 本機能には、会合計算、最近接点計算、占 位計算、時刻指定ＤＲ位置計算、航法程計算 及び侵入予想位置計算がある。 3 標準クラスの概要 戦術支援業 補助計算 機能の概要 １ 務 状況判断や簡易な数値的な決定を補助する 計算を行う。 ２ 本機能には、指定地点時刻計算、日出没・ 月出没時刻計算、座標系変換、方位距離計 算、面積計算及び誤差楕円計算がある。 戦術判断支 １ 援 戦術の決定上必要となる簡易な見積りを支 援する計算を行う。 ２ 本機能には、予測位置計算、攻撃配備計 算、潮汐計算及び衛星侵入・離脱時刻計算が ある。 後方計算 １ 後方支援に係わる見積りを支援する計算を 行う。 ２ 本機能には、輸送見積り計算及び消費見積 り計算がある。 自然環境予 気 象 状 況 把 １ 測業務 握業務 戦術上必要となる自然状況を把握するた め、データベース上に格納された自然環境情 報を、ベクトル図、シンボル及び一覧表で表 示する。 ２ 本機能には、気象ベクトル図表示、気象プ ロット図表示及び気象一覧表表示がある。 ファイル管 フ ォ ル ダ 管 １ 理業務 理 ファイル・フォルダを格納するフォルダを 管理する。 ２ 本機能には、登録、検索、削除及び更新が ある。 ファイル・ １ メッセージ 管理 作成したファイル・メッセージを管理す る。 ２ 本機能には、ファイル・メッセージ登録、 ファイル・メッセージ更新、ファイル・メッ セージ削除、ファイル・メッセージ検索、 ファイル・メッセージ送信、添付ファイル登 録、添付ファイル削除、添付ファイル更新及 び添付ファイル起動がある。 送受信簿管 １ 理 ファイル・メッセージを送信した際の履歴 を管理する。 ２ 本機能には、送信簿表示及び受信簿表示が ある。 4 標準クラスの概要 利用者管理 職務情報 業務 機能の概要 認証情報及びアクセス制御情報のシステムの 利用者に関する情報を管理する。 端末管理 端末ＩＤ、端末設置場所等の情報に基づき、 アクセス制御情報を管理する。 スクリーン スクリーンセーバの起動時間を設定する。 セーバ 監査証跡業 監 査 証 跡 検 務 蓄積された監査情報を検索し、表示する。 索 共通機能 標準業務クラスの要求機能を実現する設計過 程において、適用システムに対しても提供でき る汎用的な機能を業務クラスとして独立させた ものである。 アラート設定 アラートの表示機能を提供する。 テキスト作成 メモテキスト入力機能を提供する。 表作成 ユーザフリーなワークシート作成機能、ワー クシートからグラフを作成するグラフ連携機能 を提供する。 作図 メモ図形入力機能を提供する。 地形解析 統合ビューア上に表示された地図の地形を解 析する。本機能には標高値・水深値取得機能、 断面解析機能、鳥瞰図・鯨瞰図表示機能、解析 結果編集機能がある。 地図操作 統合ビューア上からＤＭＡＰを制御する。本 機能には地図表示制御機能、地図属性変更機 能、指定地図登録機能、作図処理機能、地図 データ登録・削除機能、指定位置図形取得機 能、エリア指定機能、ＳＫＴ読込・保存機能、 画像重畳機能、メッシュデータ表示機能、コン ター表示機能及びサムネイルビューア機能があ る。 送信 他サイト及び他システムへの送信を管理する 機能を提供する。 動画 動画の登録及び動画の表示機能を提供する。 5 標準クラスの概要 機能の概要 共通機能（続き） － イメージ 画像 デー タを ＤＢ 上で 管理 する 機能 を提 供す る。 ページ設定 アク ティ ブス ライ ド（ テキ スト スラ イド 、表 スライド）の印刷及びページ設定機能を提供す る。 マスタデータメンテ ナンス マスタデータ（マスタ コード、シンボルファ イル、環境ファイル等）を統合ビューアから検 索、表示及び登録する機能を提供する。 ランチャ機能 業務 及び 機能 を目 的別 にカ テゴ ライ ズし 、ツ リー上から起動するための処理を追加する。 ツリー表示 １ クライアントにツリーデータを表示する。 基底Ｄｏｃ ２ クライアントに部隊情報および送信先情報 などをツリー形式で表示する。 環境ファイル管理 ツール ２ 各論理装置の環境ファ イルをＸＭＬ形式で読 込み、環境変数の管理・編集を補助する。 標準部品クラス（ＣＯＥ＜ＯＯＡ＞） 標準クラスの種類 基本部品 機能の概要 基本部品は、業務クラスや部品クラスが共通 的に使用する機能を部品としてクラス化したも のの集合であり、ＯＳ（ＵＮＩＸ、Ｗｉｎｄｏ ｗｓ）のコンパイラ等で呼出し形式が異なる命 令を隠蔽するもの（ファイル操作及び環境変数 等及びに各業務クラス等で共通的に使用する基 本的な部品（日付、文字等））からなる。 リンクリスト リンクリストの操作を行う。 配列 配列の操作を行う。 日付 日付の操作を行う。 文字 文字の操作を行う。 座標 座標の操作を行う。 バイナリ バイナリデータの操作を行う。 ファイル ファイルの操作を行う。 ログ出力 ログを出力する。 例外 例外を受け取る場合に使用する。 エラー情報 エラー情報を保持・管理する。 6 標準クラスの種類 機能の概要 基本部品（続き） － 環境変数 環境変数を読み込む。 外部プログラム呼出 外部アプリケーションを起動する。 単位変換 単位変換を行う。 ビット操作 ビットデータの操作を行う。 サウンド 音楽ファイルの再生を行う。 圧縮 圧縮・解凍を行う。 プロセス管理 クライアントのプロセスの稼動状態を取得す る。 計算 地理的な各種計算を行う。 スクランブル 秘匿・復号化操作に関するＣＯＴＳインタ フェースを隠蔽し、ＯＯＡフレームワーク固有 の秘匿・復号化操作を行う。 ソート処理関数テン プレート ソート処理のアルゴリズムをテンプレートと して提供する。 他システム連接部品 他システム連接部品は、ＯＣサーバ及びＯＤ サーバを構築する上で基本となるクラス群であ り、他システムに連接するための枠組みを提供 する。 タグ タグを扱う上での共通的な処理（セット、取 得、解析）を行う。 ＣＯＥ基底部品 ＯＯＡフレームワークを構成するすべてのク ラスの基底となる抽象クラスである。 共通部品 ＯＯＡフレームワークを制御するための部品 群であり、業務クラスから隠蔽されている。 業務Ｄｏｃ管理 １ 業務クラスの生成及び管理をシステムとし て統一的に提供する。 ２ 業務クラスの追加・削除に対してソース修 正を行うことなく管理する(業務クラスのアド イン化)ためのクラスであり、業務クラスの生 成、削除等を制御する。 コンテナ管理 ＡＰサーバ、ＣＲサーバ、ＭＶサーバ及びＯ Ｃサーバにおいて、サーバデータコンテナの生 成及び管理をシステムとして統一的に提供す る。 7 標準クラスの種類 機能の概要 共通部品（続き） － 情報管理ファクトリ ＤＢサーバ及びＯＤサーバにおいて、データ 抽出処理からの依頼により、必要な情報管理ク ラス及びデータ処理クラスを生成する。 イベント管理 通信クラスあるいは業務クラスで派生したイ ベントデータをキューイングし、キューイング されたイベントデータを取得して、イベント データクラスに所定の処理を行わせる。 バージョン管理 データクラスの互換性を確保するための基本 的機能を提供する。 ＨＴＭＬ形式変換 ＯＯＡフレームワークの表示形式からＨＴＭ Ｌ形式への変換インタフェースを提供する。 タイマ 時刻によるタイマ起動イベントの通知・管理 を行う。 緊急パッチクラス １ ヘッダファイルの変更を必要とする不具合 の修正時に、追加する関数やメンバ変数を外 部定義することで当該クラスのヘッダファイ ルを変更することなく不具合の修正を可能と する仕組みを提供する。 ２ これにより、適用システムでコンパイルす ることなくパッチ適用が可能となる。 業務ＩＦ管理 業務向けにIFを公開している業務向けIFクラ スを管理する。 データ関連部品 データ関連部品は、業務クラスで扱うデータ を管理する。 データコンテナ 各種データオブジェクトを外部（業務クラ ス、通信部品等）から隠蔽し、インタフェース を制御することにより、拡張性及び保守性を向 上させる。 データクラス クライアント－ＡＰサーバ間及びＡＰサー バ－ＤＢサーバ間でやり取りするデータを管 理・格納するクラスの基底となるクラスであ り、また、共通的なデータを保持する。 8 標準クラスの種類 機能の概要 データ関連部品（続き） － 表示データ クライアントに表示するデータを管理・格納 する。 検索データ クライアントで指定された検索条件を格納 し、検索条件をＤＢ制御データに引き渡す。 ＤＢ制御データ ＤＢの検索条件及び登録時に必要な情報を保 持する。 格納データ ＤＢの検索結果及びＤＢに登録するデータを 保持する。 ＤＢアクセス部品 ＤＢアクセス部品は、ＲＤＢＭＳとのデータ のやり取りを実施する。本クラスは、実際にＲ ＤＢＭＳとやり取りする場合、ＲＤＢＭＳとの インタフェースを隠蔽する。 ＤＢアクセス 情報管理クラスからの依頼を受けて、ＲＤＢ ＭＳに対して登録、検索、更新及び削除を行 う。 ＤＢアクセス操作 １ ＲＤＢＭＳアクセス時にトランザクション 制御を行う。 ２ ＲＤＢＭＳアクセスはＤＢアクセスクラス を使用する。 通信部品 ＣＯＲＢＡを利用した通信で使用するＣＯＴ Ｓを隠蔽するために存在し、本クラスを使用す る側がＣＯＴＳのインタフェースを意識せずに 通信できることを目的としたクラス群である。 サイト内通信 サイト内クライアント及びサーバ（ＡＰサー バ／ＣＲサーバ／ＭＶサーバ／認証サーバ）と のデータ送受信を行う。 サイト内トランザク ション サイト内サーバ（ＡＰサーバ／ＣＲサーバ／ ＯＣサーバ）及びＤＢサーバ／ＯＤサーバとの データ送受信を行う。 サイト間非同期通信 ＡＰサーバ／ＣＲサーバ／ＯＣサーバ及び接 続するＡＰサーバ／ＣＲサーバ／ＯＣサーバと の非同期通信を行う。 9 標準クラスの種類 機能の概要 通信部品（続き） － サイト間同期通信 ＡＰサーバ／ＣＲサーバ／ＯＣサーバ及び接 続するＡＰサーバ／ＣＲサーバ／ＯＣサーバと の同期通信を行う。 マルチキャスト通信 クライアント間（ＡＰサーバを含む）との データ送受信を行う。 共通コード変換部品 ＯＯＡフレームワークで定義される共通コー ドにアクセスし、マスタデータを取得するため の部品である。 共通コード変換用通 信 共通コード変換用の通信を制御する機能であ り、次の機能を持つ。 ・ＡＰサーバ／ＣＲサーバ／ＯＣサーバの業務 クラスとのインタフェースを提供 ・ＡＰサーバ／ＣＲサーバ／ＯＣサーバからＤ Ｂサーバ／ＯＤサーバへのデータ検索を行う 際、ＩＤＬファイルから作成されたプログラム の呼び出し及びデータのやり取りを提供する。 ビュー部品 ビュー部品は、業務クラスがメニューやダイ アログを表示するとともに、ＤＢ検索等で得ら れた結果を地図、表、ツリー等の各種フォー マットで表示するために使用する部品である。 メニュー スライド固有バーメニュー及び画面ポップ アップメニューを生成する機能を業務クラスに 提供する。 ツールバー １ 使用頻度の高い操作をボタン化し、統合 ビューア上にツールバーとして表示／非表示 を行うクラスである。 ２ 業務クラス作成時にスライド形式ごとに個 別に派生させて使用する。 ダイアログ １ ダイアログボックスにより、入力及び入力 チェックを行う。 ２ 業務クラス作成時に画面仕様ごとに個別に 派生させて使用する。 ３ 操作パネルは同様なカテゴリに関する操作 をまとめて行う場合に使用する。 10 標準クラスの種類 機能の概要 ビュー部品（続き） データ表示 － １ 業務クラスが表示するフォーマット（地 図、表、ツリー（階層図）、グラフ（チャー ト）、階層マトリクスデータ、ネットワーク データ、イメージデータ、テキストデータ、 タグつきダイアログ、３Ｄ地図データ表示、 メッシュデータ表示、コンター表示及び印刷 エリア表示）に該当するクラスを生成及び使 用するクラスである。 ２ データ表示クラスが生成されると統合 ビューアクラスのスライドクラスが生成さ れ、スライド上に業務クラスが検索等で取得 したデータを画面に表示する。 印刷 １ 統合ビューアから印刷依頼を受け取り、選 択されているスライドをプリンタに印刷、あ るいはビットマップ出力する。 ２ 地図、表及びテキストデータのスライドは 改ページ印刷が可能である。 ガジェット 業務クラスがクライアントに対してデータ入 力を要求する場合及びデータを表示させる場合 等に、画面上にｉｌｖガジェットを表示させ、 共通的にコントロールする機能を持つ。 メッセージ メッセージを出力する。 統合ビューア管理 クライアントプロセスのメイン関数より呼び 出され、通信クラスや業務Ｄｏｃ管理、共通情 報、保全情報などを生成後、統合ビューアのメ インループを行うクラスである。 画面管理 統合ビューアで使用するＧＵＩ部品を管理、 制御し、統合ビューアとしてのＨＭＩ（ヒュー マン・マシン・インタフェース）機能を統括す る。 統合ビューア共通機 能 統合ビューアが共通的に呼び出すクラスであ り、ヘルプ表示管理、Ｂｏｏｋ・環境データ管 理、時刻帯設定、スライド管理、実演切替設定 の各種サービスを実施する。 11 標準クラスの種類 機能の概要 業務 各論理装置の業務を作成する上での基底クラ スとなるべきクラスである。また、ＤＢへの データ操作クラスも含む。 業務基底部品 クライアントにおける共通機能、地図業務や 状況図業務を作成する上での基底クラスとなる べきクラスである。 サーバ業務 ＡＰサーバ及びＡＰサーバベースで開発され たサーバ（ＯＣサーバ、ＣＲサーバ、ＭＶサー バ）上の全業務クラスの基底クラスである。 情報管理 情報管理は、ＤＢアクセス部品とともに、標 準業務クラスの必要とするＤＢに対するデータ 操作を実現する部品である。 メイン処理 各論理装置で最初に起動される処理を実行す る。 クライアントメイン クライアントにおいて最初に起動されるメイ ン処理であり、統合ビューアの起動を行う。 ＡＰサーバメイン １ ＡＰサーバ、ＣＲサーバ、ＭＶサーバ及び ＯＣサーバにおいてプロセスの制御を行う。 ２ クライアント又は他サーバからの通信を契 機とし、通信時に引き渡される共通情報を基 に、業務クラスの生成・起動を制御し、業務 クラスの処理結果を応答する。 ＤＢサーバメイン １ ＤＢサーバ及びＯＤサーバにおけるプロセ スの制御を行う。 ２ ＡＰサーバ、ＣＲサーバ及びＯＣサーバか らの通信を契機とし、通信時に引き渡される 共通情報を基に、情報管理クラスの生成・起 動を制御し、処理結果を応答する。 システム初期起動部 適用システム独自の初期処理を起動する。 品 ＡＰタイマ－ サーバにおいて指定時刻に指定のプログラム を起動する。 保全部品 ＭＯＤ－３に対応可能な部品群として、個人 認証、アクセス制御、秘匿及び監視の機能を提 供する。 12 ３ 標準部品クラス（ＣＯＥ＜ＲＴ＞） 標準クラスの種類 基本部品 機能概要 基本部品は、業務クラスや部品クラスが共通的 に使用する機能を部品としてクラス化したものの 集合であり、ＯＳ（ＵＮＩＸ、Ｗｉｎｄｏｗｓ） のコンパイラ等で呼出し形式が異なる命令を隠蔽 するもの（ファイル操作、環境変数等及び各業務 クラス等で共通的に使用する基本的な部品）から 成る。 リー ダ ／ ラ イ タ ロ ッ ク リーダ（読み込み）用とライタ（書み込み）用 のロック／アンロック機能を提供し、ライタロッ ク中ではリーダ／ライタ共に、リーダロック中で はライタロックの排他制御を行う。 日付 日付の操作を行う。 文字列 文字の操作を行う。 環境ファイル 環境ファイルを読み込む。 ログ出力 ログを出力する。 共有メモリ 共有メモリにアクセスする。 リンクリスト リンクリストの操作を行う。 配列 配列の操作を行う。 バイナリ バイナリデータの操作を行う。 ファイル ファイル操作を行う。 圧縮 圧縮・解凍を行う。 スクランブル 秘匿・復号化操作を行うＣＯＴＳインタフェー スを隠蔽する。 排他制御 排他制御を行う。 ＣＯＥ基底部品 フレームワークを構成する全てのクラスの基底 となる抽象クラスである。 ＣＯＥ＜ＲＴ＞基底 ＣＯＥ＜ＲＴ＞標準部品のクラスの基底となる 抽象クラスである。 共通部品 ＣＳ Ｌ サ ー バ デ ー タ コンテナ管理 フレームワークを制御する機能を実現する。 ＲＡサーバからの通信データを復元するために 必要なデータコンテナを登録しておき、ＲＡ－コ ンソール通信から要求があったときに適切なＣＳ Ｌサーバデータコンテナを返却する。 13 標準クラスの種類 共通部品（続き） ＲＡサーバデータコ ンテナ管理 表示制御 機能概要 － ＲＡサーバにおいて通信から受信するＲＡサー バデータコンテナを管理する。 ＲＡサーバとＣＳＬ端末（ＣＳＬサーバ）間の データをビジネスオブジェクトとして管理する。 通信管理 ＲＡサーバとＲＡサーバ／連接装置間／ＣＳＬ 端末（ＣＳＬサーバ）間の通信を管理する。 ＡＰ管理 ＣＯＥ＜ＲＴ＞からＣＯＥ＜ＯＯＡ＞のＡＰ サーバへのアクセスを隠蔽・管理する。 ＤＢ管理 ＣＯＥ＜ＲＴ＞からＣＯＥ＜ＯＯＡ＞のＤＢ サーバへのアクセスを隠蔽・管理する。 時刻管理 論理装置間の時刻の整合を制御する。 システム監視 システムの状況を監視する。 センサ管理 センサへのインタフェースを隠蔽する。 リソース管理部品 並列処理管理 各種リソースを管理する。 処理を実行させるためのスレッド及びＣＰＵに 関する管理を行う。 処理部品間通信 並行処理部品又は並列処理部品から他の処理部 品に対して、送信部品を使ってメッセージ通信を 行う。 処理部品 イベント等のメッセージを送信する送信部品か らメッセージを受け取ることによって処理を実行 する。 タイムホイール 時間の経過を監視し、予め指定された周期、指 定時刻となったタイミングでイベントを予め指定 された処理に通知する。 業務メモリ管理 業務等の扱う複数種のデータのメモリを管理す る。 共有情報管理 ＲＡサーバとＲＡサーバ／連接装置／ＣＳＬ端 末（ＣＳＬサーバ）とデータコンテナを介して情 報を共有する。 データ関連部品 ＲＴ共通情報 データを扱う機能とデータ型を定義する。 ＲＡサーバ、ＣＳＬ端末（ＣＳＬサーバ）及び 連接装置間の連携において必要な情報を保持・管 理する。 14 標準クラスの種類 データ関連部品（続き） ＣＳＬサーバデータ コンテナ ＲＴデータコンテナ Ｒ Ａ サ ー バ 機能の概要 － ＣＳＬサーバにおいて、ＲＡサーバとの間で扱 う通信のデータ型を隠蔽する。 ＲＴ独自のデータ型を定義する。 ＲＡサーバにおいて、ＲＡサーバ／連接装置／ デ ー タ コ ン テ ＣＳＬ端末（ＣＳＬサーバ）との間で扱う通信の ナ ビジネスオブジェク ト データ型を隠蔽する。 ＲＡサーバからの更新データをＣＳＬ端末（Ｃ ＳＬサーバ）に配信するためのデータを保持す る。 Ｖｉｅｗ 表示制御の間でデータの受け渡しを行う。 イベントタグ イベントの発生条件に適合した場合、イベント を発生させる。 表示データ クライアントに表示するデータを管理・格納す る。 業務データ 業務で扱うデータを保持する。 業務メモリ 業務の扱うデータをメモリ上で管理する。 共通情報 共通的なデータを管理する。 データコンテナ 各種データオブジェクトを隠蔽する。 通信部品 ＲＡ－ＣＳＬ通信・ 通信機能を実現する。 ＲＡ－ＣＳＬ端末（ＣＳＬサーバ）間の通信並 Ｒ Ａ － Ｒ Ａ / 連 接 装 びにＲＡ－ＲＡ間、ＲＡ－連接装置間及び連接装 置通信 置－連接装置間の通信を行う。 ＲＡ－ＡＰ通信 ＲＡ－ＡＰ間の通信を行う。 ＲＡ－ＤＢ通信 ＲＡ－ＤＢ間の通信を行う。 現有連接器材通信 非ＣＯＥ適用システムの現有器材と通信を行う ためのプロトコル変換を行う。 ビュー部品 ＲＴ統合ビューア ユーザインタフェース機能を実現する。 画面管理クラスに対して、イベントループ実行 を指示する。また、ＣＳＬ端末業務Ｄｏｃ起動を 指示する。 ＲＴ統合ビューアイ ベント管理 スライドに対する描画操作をイベントとして管 理する。また、イベントの処理優先度に応じて、 イベント優先度管理を行う。 15 標準クラスの種類 ビュー部品（続き） スライド 背景地図スライ 機能の概要 － 各種フォーマットで表示を行う。 タイル背景としての地図を配置する。 ド 高速シンボルス ライド ペアラインスラ イド ドットスライド シンボルを遅滞なくＲＴ統合ビューアのタイル 上に表示する。 ペアラインスライドの画面表示および操作を行 う。 ドットシンボルを遅滞なくＲＴ統合ビューアの タイル上に表示する。 環状メッシュス ライド ２Ｄ－自由図形 環状メッシュスライドの画面表示および操作を 行う。 ２Ｄの地図エレメントを表示する。 専用スライド ２Ｄ投影－３Ｄ ３Ｄの地図エレメントを２Ｄ投影表示する。 自由図形専用ス ライド 自由形式スライ ド システム制御ス ライド 業務が定義した形式で表示する。ボタン、ラベ ル等を配置することができる。 業務からのシステム終了や画面タイトルの変更 をＲＴ統合ビューア画面管理、ＲＴ統合ビューア 制御Ｄｏｃに通知する。 操作関連部品 パネルスライド 業務部品 操作を受け付ける。 パネルスライドの画面表示及び操作を行う。 業務を作成する上での基底クラスとなるべきク ラス群を提供する。 業務Ｄｏｃ管理 業務Ｄｏｃの生成と初期化を行う。 ＣＳＬ端末業務Ｄｏ 業務で扱う画面部品およびＶｉｅｗ部品の管理 ｃ と画面部品に対するスライド生成依頼を行う。ま た、地図エレメントに対する操作通知を取得す る。 ＣＳＬサーバ業務Ｄ ｏｃ ＲＡサーバ業務Ｄｏ ｃ ＣＳＬサーバ内の業務Ｄｏｃ内で扱う各部品の 生成及び初期化を行い、業務処理を行う。 ＲＡサーバの各部品の生成及び初期化を行う。 16 」 標準クラスの種類 業務部品（続き） ＲＡサーバサブ業務 Ｄｏｃ 機能の概要 － ＲＡサーバのサブ業務Ｄｏｃ内で扱う各部品の 生成及び初期化を行い、業務処理を行う。 連接業務Ｄｏｃ ＲＡサーバと処理パターンで連接する。 現有業務Ｄｏｃ 非ＣＯＥ適用システムの現有器材と連接する。 連接装置の現有業務Ｄｏｃ内で扱う各部品の生成 及び初期化を行い、業務処理を行う。 メイン処理 各論理装置で最初に起動される処理を実行す る。 ＣＳＬ端末メイン処 理 ＣＳＬサーバメイン 処理 ＲＡサーバメイン処 ＣＳＬ端末においてシステムを起動するための 制御を行う。 ＣＳＬサーバにおいてシステムを起動するため の制御を行う。 ＲＡサーバにおいて、システムを起動するため 理 （ 業 務 Ｄ ｏ ｃ 管 の制御を行う。 理） ＲＡサーバメイン処 理（業務ＤＯＣ） 連接装置メイン処理 ＲＡサーバにおいて、業務を起動するための部 品の生成等を行う。 連接装置においてシステムを起動するための制 御を行う。 保全部品 ＭＯＤ－３に対応可能な部品群として、個人認 証、装置認証、アクセス制御、秘匿及び監視の機 能を提供する。 ４ 標準インフラサービス 標準クラスの種類 Ｍ－ＣＯＲＢＡ 機能の概要 Ｃ Ｏ Ｒ Ｂ Ａ 2.6 規 格 の 機 能 及 び マ ル チ キ ャ ス ト・イベントサービスの機能を持ち、マルチ キャストによるクライアン ト及びクライアン ト （ＡＰサーバを含む。）間 の通信を行う機能 を 提供する。また、野外無線 用通信ネットワー ク インタフェース機材との連 携する機能を提供 し ている。 なお、提供する機能は、通信部品により隠蔽 される。
© Copyright 2024 Paperzz
