Translate

2018/11/07

Model パッケージ

Papyrus でモデルファイルを作成し,そのモデルファイルをソフトウェアリポジトリ上で管理する場合,そのモデル記述は Papyrus プロジェクトフォルダ (Eclipse プロジェクトフォルダ)下の独立した3つのファイル:

  • .di
  • .notation
  • .uml

として保存されます.

これらは UML の仕様と同じく OMG で規定されたモデル記述やダイアグラム記述のファイルフォーマットであり,内部的には XML 形式のファイルです.

これらのファイル形式(仕様としては XMI 等)については,また記事をかければと思っていますが,全てテキストとして解釈可能なテキストファイル形式でありソフトウェアリポジトリ管理ツールと相性がいいです.

そのため,モデルの流用や再利用等を考え出すと,開発対象のモデルをどのようにモデルファイル管理に分割し,また,どのようにリポジトリ管理ツール上で連携させるかが重要になってくると思います.
理由は,そのファイル単位が独立して作成・修正またメンテナンスをする単位となるからです.

その整理(何かしらのカテゴライズかと思いますが)の仕方として何がよいかはまだ調べ切れていませんが,個人的には図書分類法が何かしらのヒントになるのでは,と思っています.

話しを戻すと,そのようにモデルファイル管理を考えた場合に,Papyrus で作成するモデルのトップが何になるか,というのが気になってきます.ようはその単位でモデルを作成していくことになるのですから.

Model Explorer で見た場合にルートになるノードで,アイコン表示としては通常のパッケージ要素の中に三角形が記載されたような図です(下図で Test と記載されている所).

これは UML のモデル要素における Model という名前のモデル要素になります.分かりづらいですが.
UMLにおける Model はパッケージであり,UML2.5.1 の仕様書では下記の抽象文法で定義されています:

そのため通常のパッケージと同じような扱いは出来ますが,そのプロパティとして文字列型の viewpoint なるものがあったりします.

UML仕様書上で Model に関する説明を見つけるのは,pdfをModelで検索してもひっかかるものが多いため難しいですが,UML 2.5.1 では
12.2.3.11 Model
に記載があります.

その内容は以下です.ほぼ直訳ですが,その説明にも色々な示唆が含まれています.UMLの仕様書はそれ自身,とても良い読み物だと個人的には思います.

  • モデルとはシステムの記述です.ここで「システム」とは最も広い意味をさしており,ソフトウェアやハードウェアだけでなく組織やプロセスも含まれます.
  • あるカテゴリのステークホルダー(例えばシステムの設計者,ユーザー,または顧客)による特定の視点(または観点)から,ある抽象レベルでシステムを記述します.
  • モデルは,その目的に関連する(すなわち,与えられた抽象化レベルおよび視点レベル内の)様相のみがモデルに表されますが,システム全体をカバーするという意味で完全です.
  • パッケージとして,モデルには,モデル化されるシステムを一緒に記述するメンバーのセットがあります.
  • これらの要素の構成は,使用されるモデリング方法によって異なります.
  • 1つのアプローチは,最上位のパッケージ/コンポーネントがシステムの境界を表すような,1つ以上のコンポジション階層であるものです.
  • モデルには,システムの環境の関連部分を記述する要素も含まれます.
  • 通常,環境はアクタとそのインタフェースによってモデル化されます.
  • これらはシステムの外部にあるため,パッケージ/コンポーネント階層の外側に存在します. 
  • それらは別のパッケージで収集されるか,またはpackagedElementsとしてモデルによって直接所有されることがあります. 
  • 同じシステムに対して異なるモデルを定義することができます. 異なるモデルは,通常,異なるシステム関係者の見通し(視点)から補完され定義されます. 
  • モデルの構成において,コンテナモデルは,含まれるモデルによって定義される異なるビューによって与えられるシステムの包括的なビューを表します. 
  • モデルは抽象化の依存関係を持つことができます:洗練(標準プロファイルの«Refine»によりステレオタイプ化)またはマッピング(例えば標準プロファイルの«Trace»でステレオタイプ化). 
  • これらは,通常,モデルに含まれる要素間の依存関係によってより詳細に表現されます. 
  • 異なるモデルの要素間の関係は,一般に,各モデルが完全であるため,モデルの内容に直接影響を与えません. 
  • ただしこれらは,詳細をトレースしたり,モデル間の相互参照を追跡したりするのに便利です. 


なお前の記事でも紹介したかと思いますが,Papyrus は UML の言語仕様にとても忠実で,仕様として規定されているものはだいたい記述可能です.今回の Model における viewpoint のように使用頻度が少ないものは通常のPropertiesメニューには現れませんが,その Advanced の所で入力できることが多いです.今回の Model においても,viewpoint は Advanced の所で入力可能です.



2018/11/04

Papyrus/Eclipse の Simultaneous Release

以下の投稿から:
[mdt-papyrus.dev] Oomph Setup for New Release Cadence

Papyrus は Eclipse の 同時配信(Simultaneous Release)のスキームに従っており,次のリリースはこの12月です.

Eclipse の Simultaneous Release がどういうものかについては以下のページにて説明されています:
Simultaneous Release

簡単にいうと四半期(13週)ごとにローリングリリースされるモデルです.
これまでは年に一回6月のリリースでプラットフォームのマイナーバージョンアップがなされ:
Neonは4.6,Oxygenは4.7,Photonは4.8
それ以降のリリースである Oxygen.1 の様なサブマイナーの改善的なバージョンアップであったものと異なり,四半期毎の各リリースでプラットフォームのマイナーバージョンがアップされていきます.
それもあって,リリース名がこれまでのアルファベット順のコードネームから年月で規定される名前に変更されているみたいです.

なおこの先の予定は以下となります:

  • 2018-09 (現)/プラットフォームバージョン 4.9/ 2018年9月19日リリース
  • 2018-12 (次) / プラットフォームバージョン 4.10/ 2018年12月19日リリース予定
  • 2019-03 / プラットフォームバージョン 4.11/ 2019年3月リリース予定