日本財団 図書館


5.2.7 configuration_management UoF [NK]
 
 configuration_management UoFは、承認・変更及び各版履歴の中で異なる版との関係といったものに関する定義の特性をカバーしている。Approvalの情報は、いつ・誰が・何を承認し、それがどのレベルの承認であるのか、また承認が互いにどの様に関係しているのかを定義する。管理されたChangeの情報は、いつ・誰が・何を変更し、その変更によって他の定義が作成・変更・消去されたか否かを記述するものである。Versionは、版の対象となるもの、各版履歴の中でどのように異なっているかを記述する。本UoFは、以下に示すアプリケーションオブジェクトを用いて構成されている。
 
5.2.7.1 アプリケーションオブジェクト
 configuration_management UoFに現れる全てのアプリケーションオブジェクトを下記に示す。
 
・Alternative_version_relationship (4.2.3)
・Approval_event (4.2.4)
・Approval_history (4.2.5)
・Change (4.2.20)
・Change_definition (4.2.21)
・Change_impact (4.2.22)
・Change_plan (4.2.23)
・Change_realization (4.2.24)
・Change_request (4.2.25)
・Check (4.2.26)
・Definable_object (4.2.79)
・Definition (4.2.80)
・Envisaged_version_creation (4.2.90)
・Event (4.2.91)
・Item (4.2.109)
・Item_relationship (4.2.110)
・Item_structure (4.2.111)
・Revision (4.2.139)
・Revision_with_context (4.2.140)
・Ship (4.2.141)
・Version_creation (4.2.174)
・Version_deletion (4.2.175)
・Version_history (4.2.176)
・Version_modification (4.2.177)
・Version_relationship (4.2.178)
・Versionable_object (4.2.179)
・Versionable_object_change_event (4.2.180)
 
 ここで太字で示したアプリケーションオブジェクトは、configuration_management UoF (4.1.7) の解説部分で示されているものである。その他のオブジェクトは、本UoFを利用する上で、必要となる抽象オブジェクトである。以下では抽象オブジェクトも含め解説を行う。
 
5.2.7.2 configuration_management UoFの解説
(1)Alternative_version_relationship (4.2.3)
 本アプリケーションオブジェクトは、同じタイプの2つのVersionable_object (4.2.179) 間の関係を示す。各Versionable_objectは、もう一方のVersionable_objectの代わりになるものである。以下の属性を持つ。
- alternative_1
- alternative_2
- reason
 alternative_1は、alternative_2により定義されるVersionable_objectの代案である。
 alternative_2は、alternative_1により定義されるVersionable_objectの代案である。
 reasonは、2つの選択肢の関係を記述するものである。
 
(2)Approval_event (4.2.4)
 本アプリケーションオブジェクトはEvent (4.2.91) のタイプであり、製品データの組織的な検査や承認のステータスの変更の記録を示す。以下の属性を持つ。
- approval_reference
- result
- user_defined_result
 approval_referenceは、ある出来事によって影響された承認履歴Approval_historyを特定する。全てのApproval_eventは承認履歴を参照していなくてはならない。
 resultは、製品データ設計のある版が、権限者によってレビュー後もしくはレビュー中に、承認・否認・その他の固有の与えられたステータスを示す。
・approved: 製品データが適切な組織によりレビューされ、使用を承認されたこと。
・rejected: 製品データが適切な組織によりレビューされ、使用を承認されなかったこと。普通は、否認された製品データを置き換えるために他の製品データが作成される。
・unapproved: 製品データがまだ組織によりレビューされておらず、若しくは承認のためのレビューのプロセスにあること。
・user_defined: プロジェクトでの承認のステータスが、2つ若しくはそれ以上の組織により決定される場合に用いられる。
 user_defined_resultはオプション記述で、user_defined承認ステータスを定め、結果としてuser_definedの値を持てばuser_defined_resultと定められる。
 
(3)Approval_history (4.2.5)
 本アプリケーションオブジェクトは、ある製品データに与えられたApproval_eventの集合である。以下の属性を持つ。
- approvals
- status
- subject
 approvalは、ある時点までに発生した一連のApproval_eventsを記述する。履歴は一つ以上のApproval_eventsで構成される。一連のApproval_eventsは、日付順に構成するよう仮定している。
 statusは、現在の承認のステータスを示す。Statusは次の何れかである。
・approved: 製品データが適切な組織によりレビューされ、使用を承認されたこと。
・rejected: 製品データが適切な組織によりレビューされ、使用を承認されなかったこと。普通は、否認された製品データを置き換えるために他の製品データが作成される。
・unapproved: 製品データがまだ組織によりレビューされておらず、若しくは承認のためのレビューのプロセスにあること。
・user_defined: プロジェクトでの承認のステータスが、2つ若しくはそれ以上の組織により決定される場合に用いられる。
 subjectは、ある承認に関連する製品データを特定する。
注)Definitionは、0、1つ、若しくは多くの関連したapprovalsを持つ可能性がある。1つ以上の関連したapprovalがある場合には、全て異なるものでなくてはならない。
 
(4)Change (4.2.20)
 本アプリケーションオブジェクトは、Item (4.2.109) のタイプであり、顧客や設計部門の変更要請をうけ製品データが変更予定されまたは変更される全ての段階を通して表現するものである。その変更は製品モデルデータを修正することになるか、若しくは修正しないことになるかもしれない。予定または実際の製品モデルの変更は、関連したChange_definitionに記述される。以下の属性を持つ。
- the_class
 the_classは、変更の組織的役割の質を定める。
例)本部の修正要求や技術的変更提案など。
 
(5)Change_definition (4.2.21)
 本アプリケーションオブジェクトは、Definition (4.2.80) のタイプであり、個々のChangeの段階を統合して扱うものである。各Change_definitionは、Change_plan (4.2.23)、Change_realization (4.2.24)、Change_request (4.2.25) のどれか一つになる。以下の属性を持つ。
- author
- date_time
- defined_for
- local_unit
 authorは、前回終了時からこのChange_definitionまでの期間のChange活動の責任者または組織を記述する。
 date_timeは、Change_definitionの状態になった日付と時間を記述する。
 defined_forは、Change_definitionが適用されるChangeを指す。Change_definitionに対して1つ以上のdefined_forがあり得る。
 local_unitは、世界的に造船業界で用いられている単位とは違ったものを用いる場合に、Definitionが使用する単位を示す。
注)Change_definitionについては、Definitionから関連づけられたlocal_units属性はAIMでは一般的でない属性と解釈されるので、ARMではゼロとセットするように再定義される。
 
(6)Change_impact (4.2.22)
 本アプリケーションオブジェクトは、起こるであろうもしくは起こっているChangeの影響を記述する。以下の属性を持つ。
- Impact
 impactは、変更の影響をDefinition、Item_structures、Item_relationshipsの生成・修正・削除の点から記述する。Change_impactについて1つ以上のimpactがあり得る。
 
(7)Change_plan (4.2.23)
 本アプリケーションオブジェクトは、Change_definition (4.2.21) のタイプであり、提案された変更の方法を定義する。これは、製品モデルにおける変更を完成するためのアクティビティ、Versionable_object_change_events、必要性を基としている。以下の属性を持つ。
- checks
- chosen_solution_for
- planned_impact
 checksはオプション記述で、Change変更に対して予定された検証作業を記述する。Change_planについて1つ以上のchecksがあり得る。
 chosen_solution_forは、Change_planが、どのChange_requestに対応するものかを示す。
 planned_impactは、推定または計算されたChange変更の影響を記述する。これは、通常、Change_requestの中から選ばれる。
 
(8)Change_realization (4.2.24)
 本アプリケーションオブジェクトは、Change_definition (4.2.21) のタイプであり、Changeによって実際に認められた影響を定義する。以下の属性を持つ。
- checks
- impact
- realization_of
 checksはオプション記述で、変更が行われた製品モデルの改訂の組織的な承認を記述する。Change_realizationについて1つ以上のchecksがあり得る。
 impactは、製品モデルにおこなわれた改訂を記述する。
 realization_ofは、行われようとしている製品モデルの変更のChange_planを特定する。
 
(9)Change_request (4.2.25)
 本アプリケーションオブジェクトは、Change_definition (4.2.21) のタイプであり、どこに変更が必要か可能な変更方法を規定されたChangeの一番始めの段階を定義する。以下の属性を持つ。
- addressee
- initiator
- problem
- solution_alternatives
- solution_description
 addresseeは、要求が提出された人物または組織を記述する。addresseeは特別なChange_requestに対しては示される必要は無い。
 initiatorは、要求を発案した人物または組織を記述する。
 Problemは、要求の原因となった問題を記述する。
 solution_alternativesはオプション記述で、その問題を解決するために提案された他の解決法を記述する。解法は改訂対象への影響の観点から記述する。Change_requestについて1つ以上のsolution_alternativesがあり得る。
 solution_descriptionは、問題解決のための1つ以上の解法を記述する。もしsolution_alternativesが設定されていない場合や、solution_alternativesによって情報が増えてきたときに、この記述をすればよい。solution_descriptionは、特別なChange_requestに対しては示される必要は無い。
 
(10)Check (4.2.26)
 本アプリケーションオブジェクトは、Event (4.2.91) のタイプであり、Change_planやChange_realizationの組織内での予定または終了した承認の詳細を記述する。
 
(11)Definable_object (4.2.79)
 Definable_objectは、基本属性が記述できる製品のタイプである。各Definable_objectは、Item (4.2.109)、Item_relationship (4.2.110)、Item_structure (4.2.111) の何れかである。以下の属性を持つ。
- id
 Idには、Definable_objectのグローバルユニークな識別名称を記入する。
 
(12)Definition (4.2.80)
 Definitionは、Versionable_object (4.2.179) の下位型であり、それは、Definable_object定義の全ての下位型の基本となるものである。各々のDefinitionは次の何れかとなる。
:Cargo_bay_definition (4.2.14), Change_definition (4.2.21), Design_definition (4.2.82),
Design_requirement (4.2.103), Functional_definition (4.2.99),
General_characteristics_definition (4.2.103), Lightship_definition (4.2.113),
Loading_condition_definition (4.2.117), Local_co_ordinate_system (4.2.121),
Spacing_table (4.2.155), Tonnage_definition (4.2.164)
注)Definitionsは次の建造概念を支える。
:design, function, manufacturing, general Ship characteristics, design requirements, and parametric and library descriptions of objects.
 Definitionに関連するデータには以下のものがある。
- defined_for;
- id;
- local_units.
 defined_forはDefinitionで定義されているDefinable_objectsを指す。Definitionについて1つ以上のdefined_forがあり得る。
 IdはDefinitionのグローバルな明白な識別を定める。
 local_unitsにはShipのグローバル単位として定義されたものと異なるものを使用する場合に明記する。各々のLocal_unitsは、Derived_unit (4.2.81) 若しくはNamed_unit (4.2.127) のどちらかとなり得る。Local_unitsは、特定のDefinitionにて定めなくても良く、また一つ若しくはそれ以上の重複しない値を持っても良い。







日本財団図書館は、日本財団が運営しています。

  • 日本財団 THE NIPPON FOUNDATION