Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Unresolved
    • Labels:
      None
    • Proposal:
      Hide

      Add "belongsTo" property to each resource of ManagedItem.

      Show
      Add "belongsTo" property to each resource of ManagedItem.

      Description

      While ManagedItemCollection has "belongsTo" link to a project it belongs to, ManagedItem does not have such a link. This causes a problem especially for ScopeItem since it is not easy to get Metric an UnitOfMeasure for its size property.

        Attachments

          Activity

          tomkamimura Tsutomu Kamimura [X] (Inactive) created issue -
          Hide
          tomkamimura Tsutomu Kamimura [X] (Inactive) added a comment -

          Exchanged mails with Yoshida-san to discuss its implications.

          Mail of September 14, 2017

          吉田さん、

          この件昨日のTCで議論しました。と言っても私と薮田さんでの議論でしたが。

          結論から言うと、どの変更案でも現状の課題が解決され他の問題もなくなるかと言うとそうとも思えないと言うことでは一致したので、とりあえずは現状のままで変更しないのが良いと言う方向になりました。

          いくつかコメントをします。

          モデルとスキーマの一致については現在でも既に不一致の部分が出ていて、完全に一致させると言うことではないと思います。ただ不一致の部分はUMLのクラス定義とRDFでのリソース定義の違いと、実装によって使い勝手がよくなるため等が主な部分で、主要コンセプトの違いまで許容すると言うことにはなってないと思います。

          吉田さんの人と国籍の議論はわかりますが、PlanやReportなどのManagedItemCollectionとManagedItemの関係については、作られた全てのManagedItemがどれかのManagedItemCollectionに入るとの保証はないので、リンクをたどることではどのProjectに入るかはわからないものが出てくる可能性があると思います。それでManaagedItemにProjectへのリンクをもたせるのが良さそうにも見えますが、そうすると冗長性が多くなり、例えばExcel adaptor等でManagedItemの中身をExcelに読み込む時に全てのManagedItemの部分にProjectが入るのは流石に違和感を覚えます。ほとんどのツールではManagedItemに相当する情報を作った時は、Projectがわかっていてそれに相当するエリアやdirectoryに作るでしょうから、Projectをアクセスするためには他のやり方の方がいいように思えてきました。ただRDFではリソースとそれらをつなぐグラフのみなので、直接リンクを作るかqueryによるかしかないのでしょう。それでManagedItemCollectionに入っていないManagedItemのProjectがどうしても必要になる場合は例えばProjectがわかっているManagedItemと何らかのリンクでつながっているなどのqueryを使うということでしょうか。

          ScopeItemのactualSizeとplannedSizeをMeasureにするのは私もいいように思いましたが、薮田さんは現実のプロジェクトでバラバラにSizeを決めてトラブルを起こすことがよくあるので、Sizeはプロジェクトレベレで決めるのがGovernanceを効かせるのは重要とのことで、やはり反対の立場です。

          と言うわけでおさわがせしましたが、とりあえず、この件に関しては今は修正なしということでお願いします。若尾さん、青山先生の意見でまた変わる場合は再度連絡します。

          上村

          Show
          tomkamimura Tsutomu Kamimura [X] (Inactive) added a comment - Exchanged mails with Yoshida-san to discuss its implications. Mail of September 14, 2017 吉田さん、 この件昨日のTCで議論しました。と言っても私と薮田さんでの議論でしたが。 結論から言うと、どの変更案でも現状の課題が解決され他の問題もなくなるかと言うとそうとも思えないと言うことでは一致したので、とりあえずは現状のままで変更しないのが良いと言う方向になりました。 いくつかコメントをします。 モデルとスキーマの一致については現在でも既に不一致の部分が出ていて、完全に一致させると言うことではないと思います。ただ不一致の部分はUMLのクラス定義とRDFでのリソース定義の違いと、実装によって使い勝手がよくなるため等が主な部分で、主要コンセプトの違いまで許容すると言うことにはなってないと思います。 吉田さんの人と国籍の議論はわかりますが、PlanやReportなどのManagedItemCollectionとManagedItemの関係については、作られた全てのManagedItemがどれかのManagedItemCollectionに入るとの保証はないので、リンクをたどることではどのProjectに入るかはわからないものが出てくる可能性があると思います。それでManaagedItemにProjectへのリンクをもたせるのが良さそうにも見えますが、そうすると冗長性が多くなり、例えばExcel adaptor等でManagedItemの中身をExcelに読み込む時に全てのManagedItemの部分にProjectが入るのは流石に違和感を覚えます。ほとんどのツールではManagedItemに相当する情報を作った時は、Projectがわかっていてそれに相当するエリアやdirectoryに作るでしょうから、Projectをアクセスするためには他のやり方の方がいいように思えてきました。ただRDFではリソースとそれらをつなぐグラフのみなので、直接リンクを作るかqueryによるかしかないのでしょう。それでManagedItemCollectionに入っていないManagedItemのProjectがどうしても必要になる場合は例えばProjectがわかっているManagedItemと何らかのリンクでつながっているなどのqueryを使うということでしょうか。 ScopeItemのactualSizeとplannedSizeをMeasureにするのは私もいいように思いましたが、薮田さんは現実のプロジェクトでバラバラにSizeを決めてトラブルを起こすことがよくあるので、Sizeはプロジェクトレベレで決めるのがGovernanceを効かせるのは重要とのことで、やはり反対の立場です。 と言うわけでおさわがせしましたが、とりあえず、この件に関しては今は修正なしということでお願いします。若尾さん、青山先生の意見でまた変わる場合は再度連絡します。 上村
          Hide
          tomkamimura Tsutomu Kamimura [X] (Inactive) added a comment -

          Based on discussions at TC and interactions with Yoshida-san, this change is not a clear improvement. Therefore, we decided not to implement the proposal.

          Show
          tomkamimura Tsutomu Kamimura [X] (Inactive) added a comment - Based on discussions at TC and interactions with Yoshida-san, this change is not a clear improvement. Therefore, we decided not to implement the proposal.
          tomkamimura Tsutomu Kamimura [X] (Inactive) made changes -
          Field Original Value New Value
          Status New [ 10000 ] Closed [ 6 ]

            People

            • Assignee:
              tomkamimura Tsutomu Kamimura [X] (Inactive)
              Reporter:
              tomkamimura Tsutomu Kamimura [X] (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Due:
                Created:
                Updated: