7.8 Globally unambiguous identifier (GUID) usage
Globally unambiguous identifier (GUID)(グローバル識別子)が、Ship Common Modelに組みこまれ、すべての船舶アプリケーションプロトコルにて使用されている。それは、以下のようなインクリメンタルな交換シナリオのサポートの為に利用される。
― 一つのAPの中でのアプリケーションオブジェクト間のrelationを保持しながらの、items、definitionsそしてrepresentationsの複数回に分けた交換
例えば、最初の交換でMoulded_formsのエンティティだけを送ったのに対して、二回目の交換ではMoulded_formとともにMoulded_form_design_definitionエンティティを送るように、ある特別なプロパティや表現を含む場合。
― 一つの船のモデルに対してある選ばれたAP216のアプリケーションオブジェクト間のrelationを保持しながらの複数回に分けた交換
例えば、最初の交換で船体のMoulded_formエンティティを含み、二回目の交換でその境界が船体のグローバル識別子を有するExternal_instance_referenceエンティティであるメインデッキのMoulded_formのエンティティを含む場合。
― 一つのモデルに対して複数の船舶APを使用し、異なるAPのアプリケーションオブジェクト間のrelationshipを保持しながらの複数回に分けた交換
例えば、最初の交換でAP216のデッキのMoulded_formエンティティを含み、二回目でAP216のデッキのmoulded_formのグローバル識別子を含んだExternal_instance_referenceエンティティによって定義されるサーフェス上にのっているAP218のメインデッキのPlatesを交換する場合。
グローバル識別子とインクリメンタルな交換は、下記の理由から造船にとって重要なものである。
―船舶設計におけるデータのボリューム
一回の交換で全ての船舶の設計データを交換するのは現実的でない。一般的なデータ交換は、船舶あるいはある特定のシステムのある領域にフォーカスして行われる。このような複数回の交換の後でも基本的な船舶要素間の関連が保持されることが重要である。
―ロングレンジの設計と製造期間
艦艇の設計が数年を要するように、船舶の設計は長期間で進められる。同様に生産のための情報も同じような期間で生成される。よって、設計と製造サイクルのあらゆる時点で基本的な船舶要素間の関連が保持されることが重要である。
―インスタンスベースの設計
船舶の設計はその船のある特定の範囲の部品群一つ一つによって構成される。よって、船舶の設計、建造、さらには運航のステージをも通じてその船の個々のインスタンスを識別し、追跡できることが重要である。
―船体の応用性
船舶のクラスは、ある一つの船の設計と同じように、船体特有の例外を集めながら設計される。それは、船のある特定の範囲の部品群一つ一つによって構成される。船舶の設計、建造、さらには運航のステージをも通じてshipクラスの個々のインスタンスを識別し、追跡できることが重要である。
―コンカレント設計、製造
一般的には、全ての設計が完了する前に、製造が開始される。設計と製造両方の情報がインクリメンタルに組み立てられる。さらに、変更を管理するために、個々のインスタンスを設計と製造を等して識別することが重要である。
―共同設計
複数の設計エージェントが一つの船舶あるいは船舶クラスの設計に対して協働することがある。これは、他のパートナーによるインクリメンタルな変更がそれぞれの会社で識別できる時に限って可能となる。
―共同製作
複数の造船会社が一つの船舶あるいは船舶クラスの製造に対して協働することがある。これは、他のパートナーによるインクリメンタルな変更がそれぞれの会社で識別できる時に限って可能となる。
―コラボレーション
何社もの会社が一つの船舶や船舶クラスの設計や製造に対して協働することがある。これは、それぞれの会社でなされるインクリメンタルな変更が、各会社で識別できる時に限って可能となる。
7.8.1 Functional requirements
GUIDはインクリメンタルな交換をサポートするために利用されるものであるため、船舶アプリケーションプロトコルにおけるGUIDに対する機能要求を全てにわたって規定することは不可能である。GUIDに対する機能要求は以下のとおりとなる。
―GUIDは、一つの船舶の設計に対して、複数船の設計を通じて、会社を超えてグローバルかつユニークであり永続性がなければならない。GUIDはそれが示すインスタンスを指す、あるいは、(インスタンスが消去された時のように)何も指さないかどちらかでなければならない。
―それぞれのソフトウェアシステムは、生成あるいはアップデートされた個々のアプリケーションオブジェクトに対して永続的なGUIDを割り当てなければならない。
―それぞれのソフトウェアシステムは、GUIDによるアプリケーションオブジェクトへのアクセスをサポートしなければならない。
―それぞれのソフトウェアシステムは、全てのアプリケーションオブジェクトのGUIDを格納しなければならない。
―それぞれのソフトウェアシステムは、アプリケーションオブジェクトが変更されない場合は、受け取ったと同じGUIDを返さなければならない。
7.8.2 Implementation constraints
このGUIDの概念をサポートするためにいくつもの異なった実装スキームやテクノロジが用いられる。しかし、いくつかの実装上の制約があり、それは考慮されなければならない。
―会社やアプリケーションのシステムやテクノロジの違いに関わらず共通に利用出来るようサポートされなければならない。(識別子は不透明であってはならず、永続的な識別に必要となる基本的なデータ要素を公開しなければならない。CORBA v1で規定された不透明な識別子などは、システム間の共通利用を阻害することを証明した。)
―システム生成のオブジェクト識別子を使用するシステムと同様に、数値ベースのキーを使用するシステムをサポートしなければならない。(システム生成の識別子に対する付加的な属性を格納するように数値ベースのシステムに要求を押し付けてはならない。)
―インスタンスの識別子はグローバルにユニークなタイプの識別子を含み、なおかつ付加的な要求を持たなければならない。必然的にインスタンス識別子はタイプ識別子以上の情報を持たなければならない。(PLIBのBSUのごとく)
―識別子は文字列ベースでありシンタックスは産業標準のツールやアルゴリズムが利用できるように規定されなければならない。
―識別子はPart28 XMLの用法と同様にPart21とSDAIの用法をサポートしなければならない。
―識別子はソフトウェアアプリケーションのなかでの一つのデータオブジェクトへのユニークな識別となるようにするべきである。Ship Common Modelでは一般的に一つのデータオブジェクトを記述するために4つあるいはそれ以上のオブジェクトを使用する。それらは、item、design_definition、functional_definition、manufacturing_definitionである。各STEPアプリケーションオブジェクトをユニークに識別することが重要であるので、これらのSTEPアプリケーションオブジェクトを生成するソフトウェアアプリケーションでもデータオブジェクトをユニークに識別することが重要となる。
7.8.3 ISE recommended GUID format
Integrated Shipbuilding Environment (ISE) プロジェクトでは、以下に示すようなGUIDフォーマットを採用し、それに基づいたトランスレータを実装中である。
ARM属性であるGlobal_id.id(AIM attribute applied_classification_assignment.id)は、ストリングにより以下のようなフォーマットで記述される。
‘<XX_Key x_href=YY Id=WW x-owner=ZZ x-rev=AA />’
Argument definition:
XX_Key: XXはARMエンティティに関係した名前。
例えば Moulded_form_function_definition。この引数は必須。アプリケーションオブジェクトの頭文字は大文字、残りは小文字。接尾辞は"_Key"
X-href=YY: YYはSOAPサーバのURLあるいはデータベース。この引数は必須。
Id=WW: WWはオブジェクトを識別するストリング。Idはdefinable_objectsについてのみ必須。Idは以下の2タイプのいずれかをとる。
Value(transparent usage このインスタンスを識別するユニークな数値)
GUID(opaquie usage システムが生成する識別子。"guid:"と接尾辞を付ける。)
x-owner=ZZ: ZZはオブジェクトを識別するストリング。この引数はDefinitionオブジェクトについてのみ必須。Definable_objectと関連するIdと同じストリング。
x-rev=AA: AAは改正番号。この引数はDefinition objectsについてのみ必須。Definition.version_id属性と同じストリング。
(XX_key, x-href, Id)の組合わせは、definable_objectsに対してユニーク。
(XX-key, x-href, x-owner, x-rev)はDefinitionsに対してユニーク。
例1)以下の例はAP216のmoulded_formエンティティに関係する用法を説明する。
'<Moulded_form_Key
x-href="//joshua.ingr.com"
Id="guid:123-123-123"/>'
'<Moulded_form_functional_definition_Key
x-href="//joshua.ingr.com"
x-owner="guid:123-123-123"
x-rev="A"/>'
'<Moulded_form_design_definition_Key
x-href="//joshua.ingr.com"
x-owner="guid:123-123-123"
x-rev="A"/>'
SCHEMA part_schema;
ENTITY Part
Name : STRING;
Description: STRING;
END_ENTITY;
END_SCHEMA;
このタイプのインスタンスに対するグローバルかつユニークで永続的な識別子は次のようにエンコードされる。
この例では、グローバルにユニークな永続的なインスタンスの識別として三つの基本的なデータコンポーネントを説明している。すなわち、グローバルにユニークなタイプ名、グローバルにユニークなインスタンスローケータ(リポジトリ)、ローケータ(リポジトリ)のなかでローカルでユニークな識別子(キー)。
グローバルにユニークなタイプ名は、EXPRESSスキーマとISO10303-28にしたがってマップされるタイプ名とのコンビネーションとなる。EXPRESSスキーマ名はタイプの名前のスペース("urn:iso10303:osb/part_schema");と関連づけられ、EXPRESS ENTITYのNameは、限定された要素名に'_Key'の接尾辞を付けたストリング(p:Part_Key)によって永続性のある形で表現される。Xlink:href属性はインスタンスを管理するリポジトリのローケータを検索する。これは、グローバルな識別子のユニークさを確立する。残りの要素は、ローカルな識別属性名とリポジトリの中でユニークであることが保証される数値(Id="P1")によって永続性ある形に表現される。一つのローカルな識別子だけがある場合に推奨される名前はIdである。
特別な属性であるx-revが、参照されるインスタンスのバージョン情報を表すために含まれることがある。その規則は、もしx-revが存在するならば、x-revを除く全ての分野に対して同一の数値をキーとして有する他のインスタンスと、このインスタンスとの間にある特別の関係を表すことであり、そのようなインスタンスは同じオブジェクトの異なったバージョンを表現する。バージョンの順番はアプリケーション依存とする。
システムが生成するオブジェクトの識別子(guidのような)を使用するシステムは、guidストリングを第一のキー属性として使用する。
<p:Part_Key xmlns:p = "urn:iso10303:osb/part_schema" x-id = "_10"
xlink:href = "http://www.acme.com/stepdataserver"
Id = "guid: BDA4A1BA-110C-11d0-8CC3-0080F394BA32" x-rev = "A"/>
グローバルにユニークな永続的な識別子はSTEPファイルにて以下のように現れる。
#10 = Part('P1','Description for this part');
#20 = applied_identification_assignment(
'<p:Part_Key xmlns:p = "urn:iso10303:osb/part_schema"
xlink:href = "http://www.acme.com/stepdataserver" Id = "P1" x-re v= "A"/>',
#21,#10);
#21 = identification_role('xml_guid',' ');
|