ゼロからの Aras Innovator 第15回 〜 リレーションシップの振る舞い 〜

新年、明けましておめでとうございます。本年も何卒宜しくお願い申し上げます。
さて、またまた前回から間が空いてしまいましたが、「ゼロからの Aras Innovator」の第15回をお届け致します。

ゼロからの Aras Innovator 掲載予定

前回はリレーションシップの設定方法について見てきました。
今回は、そのリレーションシップを設定する際に考慮に入れておくべき事項 ―― 参照先アイテムの世代が上がった際の参照の振る舞い ―― について見ていきたいと思います。

なお この「参照の振る舞い」は、リレーションシップだけでなく、Item型プロパティ(データタイプが「Item」のプロパティ)に対しても考慮が必要ですが、今回はリレーションシップに限定してご説明していきます。

 


「参照の振る舞い」とは

ご存知の通り、Aras Innovatorでは アイテムの世代管理ができます。つまり、同じドキュメント「D-001」に対して、「世代1」のときのデータ、「世代2」のときのデータ、・・・、というように世代ごとに独立したデータ管理をすることが可能です。

このように世代管理されているアイテムが他から参照されるような場合には、被参照アイテム(参照先アイテム)の世代が上がった際の挙動について、考慮しておく必要があります。すなわち、

  • 参照先の更新に追随して、最新世代を参照するようにリレーションシップを付け替えるのか(= Float
  • あるいは、付け替えずに古い世代を参照し続けるのか(= Fixed

です。

参照の振る舞い

以下のように、Float(前者)が適しているのか Fixed(後者)が適しているのかは、対象に応じてまちまちです。

  • Float(最新世代を追随する参照)が適している例:
    • 設計中のパーツ から 関連ドキュメント への参照 ・・・ 対象パーツから最新ドキュメントを参照できるべき
    • 設計中のパーツ から 子パーツ への参照 ・・・ 子パーツの設計が親パーツの方からも参照できるべき
  • Fixed(最新世代を追随せず、固定化された参照)が適している例:
    • 不具合レポート から 不具合対象パーツ への参照 ・・・ 不具合が報告された世代のパーツがリンクされるべき
    • リリース済みパーツ から 子パーツ への参照 ・・・ リリースされた時点の構成をそのまま残しておくべき

 


「参照の振る舞い」の基本原則

「参照の振る舞い」は、リレーションシップタイプ、及び親アイテムのライフサイクルステートの両方に設定できます。両方に設定されている場合は、ライフサイクルステートの設定が優先的に適用されます。

また、以下の 4種類の設定が可能です。

  • Float系: Float , Hard Float
  • Fixed系: Fixed , Hard Fixed

設定された「参照の振る舞い」は、以下のような挙動を示します。

子アイテムの世代アップ:

子アイテムの世代アップ

親アイテムの世代アップ:

親アイテムの世代アップ

以上は、次の基本原則に従った挙動と言うことができます。

  • 参照先アイテム(子)の世代が上がった場合:
    • Float系: 旧世代への参照は無くなり、最新世代への参照に置き換わる
    • Fixed系: 旧世代への参照のまま
  • 参照元アイテム(親)の世代が上がった場合:
    • Float か Fixed かに関係なく、旧世代の親からの参照は “Hard Fixed” に置き換わる。言い換えると、その時点でリレーションシップが凍結される。

なお、「Hard Float」「Hard Fixed」のように「Hard」が付いた設定をリレーションシップタイプ側で行うと、親アイテムのライフサイクルステートでの振る舞い設定よりも優先的に作用させることができるようになります。

 


「参照の振る舞い」の設定方法

リレーションシップタイプ側での設定は、対象のリレーションシップタイプを編集モードで開き、「振る舞い」欄を編集することで行います。

リレーションシップタイプでの振る舞い設定

ライフサイクルステート側での設定は、親アイテムタイプのライフサイクルマップを編集モードで開き、それぞれのライフサイクルステートで「アイテムの振る舞い」欄を編集することで行います。こちら側の設定が、リレーションシップタイプ側の設定よりも優先的に適用されます。

ライフサイクルステートでの振る舞い設定

 


今回の説明は以上です。
内容自体にそれほど難しいところは無かったかと思いますが、実際のユースケースを想定しながら設定内容を考え出すと(= いわゆる設計をし出すと)、結構 頭を悩ませるところでもあったりします。

また、 「設定上はFixedにしておいて、プログラム的にリレーションシップを付け替える」 というような荒業も、実はかなり簡単に実現できたりします。
ですので、この荒業を最終手段として意識しつつ、想定されるユースケースを必要十分に満たすような最適解を導いて頂けたらと思います。

次回は、アクセス権の設定方法についてご説明する予定です。是非ご期待ください。
それでは、また次回。
 
(アラスジャパン 宮内一也)