連絡網システムHunterの設計について

本ドキュメントでは、連絡網システムHunterのデータ構造と、 アプリケーションの一部の機能について処理の流れを説明します。

1. Hunterのデータ構造

連絡網システムHunterはデータ管理にRinza RDF Repositoryを用いています。 Rinza RDF Repositoryは、RDFの形式でアプリケーションとデータを受け渡しします。 連絡網システムHunterのデータ構造図を以下に示します。

なお、以下のデータ構造図では、リソースを○で、リテラルを長方形で記述します。 またトリプルは、主語とオブジェクトを矢印で結ぶことで表されます。

1.1. ユーザ情報・連絡先リスト

ユーザへの召集通知時に連絡する場所の順序を保持するために、 ユーザリソースから会社／携帯電話／自宅の各リソースへと 連絡順序n1,連絡順序n2,連絡順序n3の述語が張られています。 <br> n1,n2,n3には1～3の数字が入り、数字の昇順で対応する連絡場所に 召集通知が発信されます。

1.2. 召集通知と回答

召集が実行されるごとに「召集内容」のデータ構造が作成されます。 そして、連絡対象のユーザ数だけ「通知案件」のデータ構造が作成され、 「召集内容」リソースから「通知案件」リソースへと参照されます。 <br> 一方、召集日時／場所などの、ユーザへと通知される召集に関する具体的な 内容は、「通知内容」のデータ構造が作成され、「召集内容」リソースから 参照されます。

各ユーザへの通知が始まり、それぞれの連絡先(会社／携帯電話／自宅)と 連絡手段(電子メール／電話)で連絡したときに「回答結果」のデータ構造が 作成されます(これは、代理人がいる場合は代理人についても同様に作成されます)。 <br> 作成された「回答結果」リソースは「通知案件」リソースから参照されます。

1.3. 召集通知文

召集通知文はカテゴリで分類されて管理されます。 召集通知文自体は名称／日本語メッセージ／英語メッセージのリテラルから 構成されます。

1.4. セッション情報

セッション情報は、電子メールによってユーザに連絡したときに作成されます。 ユーザがメールに記述されたURLにアクセスして回答したとき、URLに含まれる セッションIDからこのセッション情報が検索されます。 <br> セッション情報からは「回答結果」リソースへの参照があるため、どのユーザ・代理人の、 どの連絡場所に対する回答かを判別できます。

1.5. システムパラメータ

システムパラメータは、カテゴリで分類されて管理されます。 システムパラメータ自体は、パラメータ名とその値のリテラルから構成されます。

2. 召集通知実行時の処理の流れ

連絡網システムHunterにおいて、管理者が召集通知を実行すると、以下の手順で 対象ユーザとその代理人に連絡を行います。

まず、召集通知が実行されると、連絡の対象であるユーザごとにスレッドを作成します。 それぞれのスレッドでは、ユーザの代理人がいるか調べ、代理人がいればユーザ・代理人ごとの、 代理人がいなければユーザのスレッドを作成します。 そして、ユーザとその代理人への連絡処理がそれぞれのスレッドで並列で実行されます。

また、ユーザおよび代理人への連絡処理は、以下の流れで行われます。

(1) 連絡処理が起動されると、該当のユーザもしくは代理人の連絡先を検索します。 ユーザの指定した連絡場所と連絡手段の優先順位を考慮して、連絡先のリストを 構成します。

(2) 連絡手段が電話のときは、システムで設定された最大試行回数まで電話の発呼を 行います。回答が得られた場合は確認メールを送信します。 電話がつながらない場合は次の手段へと移ります。

(3) 連絡手段が電子メールのときは、メールを送信してからシステムで設定された 時間待ったのち、WWW経由で回答が登録されたかを確認します。 回答があった場合は確認メールを送信します。 回答がなかった場合は次の手段へと移ります。

(4) (2)と(3)の処理を繰り返した後、全ての連絡手段で回答を得られなかった場合は、 連絡不可として連絡処理を終了します。

(5) 電話もしくは電子メールによる連絡で回答を得られた場合は、その回答で 状況を更新して連絡処理を終了します。