モデルの画像によるデコレーション

Tipsです。

Papyrus/UMLで特定ドメインのモデル化を行っている際に、そのモデル化対象を端的に示す「シンボルマーク」をUMLのモデル要素にデコレーションして、ダイアログ上で表示したい場合があります。

通常のPapyrus（実際にはEclipseのEMF/UML2だと思いますが）の「モデルアイコン」は表示／非表示の指定は可能ですが、そのような一般的なアイコンではなく、ユーザ独自のマークです。

例えば、このような表示です（クラス図上でのクラス表記）。

　

Papyrusでは、そのデコレーション手段がサポートされています。

まず最初に PapyrusInternal というプロファイルをモデルに適用します。通常のプロファイル適用操作（Apply registered profile）により表示されるダイアログ上で「Papyrus Internal」と表示されているプロファイルとなります。

このプロファイルですね。

説明にも

Profile that provides annotations for the tool itself (Decorations, etc.)

と記載されています。

このプロファイルを適用すると、例えばクラス図上で作成したクラスに対して、以下の様な

「TypeSymbolDefinition」

というステレオタイプが適用可能となります。

このステレオタイプを適用した直後は以下のような表示となります。

基本的には、この「symbolPath」にシンボルマークの画像ファイルを指定することで、デコレーション表示が可能となります。

どのようにファイルを指定するか、またどのようなパス名で指定するかですが、一番楽なのが、一旦同ダイアログを非表示として、再度表示すれば、プロパティの所に

Symbol

という選択肢が現れますので、そこから指定するのが楽です。
以下がダイアグラムの再表示を行った後のプロパティのメニューですが、左側の「Comments」と「Profile」の間に「Symbol」が現れてるのが分かります。

この「Symbol」を選択すると、

[Browse] または [Browse workspace]

としてファイルが選択可能であることが分かります。

前者がファイルシステムから、後者が Papyrus (Eclipse) で開いているワークスペースから、となります。

とりあえず同じプロジェクト下のフォルダに画像ファイルが置いてあるとして、それを指定してみます。

[Browse workspace] からワークスペース内のファイルを指定すると

platform:/resource/...

というファイル指定方法となります。

で、はい、これだけでは何も表示は変わりません笑。

その後、表示の細かな指定を行います。

「Properties」の「Appearance」を開き、「Shape Decoration」と書かれた所までスクロールします。

ここ（Shape Decoration）の

• Visible を true に
• Position で表示位置を選択

すると、モデル上の指定位置にアイコン表示がなされます。

このような感じになります。

 ≪TypeSymbolDefinition≫ というステレオタイプ名表示が重なって見づらい場合には、同じくAppearance の少し下にある「Stereotype display」の「 Visible 」のチェックをはずします。

これで見やすくなりました。

これが一つの例ですが、このような奥ゆかしい表示ではなく、例えばコンテキスト図を作成し、そこに大きくシンボルマークとして表示したいケースもあるかと思います。

その場合は「Appearance」ではなく、対象のモデルをマウスで選択しマウス右クリックで表示される

「Filters」メニュー

から操作する表示方法があります（以下の説明では一旦「Shape Decoration」の「Visible」を「false」に戻しています）。

「Show/Hide Compartments」で「Symbol」を選択します。

すると、以下の表示に変わります。

うまく使い分けると各ダイアグラムでより分かりやすいモデル図が作成できると思います。

なお画像のファイル形式として svg と png は表示できることを確認しています。他はまだ試していません。

モデルファイルの分割作成と使用

UMLでモデル化を行う場合の最上位の要素は「Model」なのですが、どの粒度で1つのモデルパッケージとなる最上位モデルを規定するかの問題があります。

対象とする開発プロジェクト全体を扱うモデルを１ファイルで作成するか、より細かな粒度でモデルファイルを扱うかの話しとなります。

上記の「Model」のリンクから辿れる記事で説明した通り PapyrusでのModelのファイル構成は非常にシンプルでファイルの独立性が高いです。また作成しているUMLモデルから別ファイルのモデルのImportも簡単に行えます。

そのため自分としては「１つの関心事で１つのモデルファイルを作成する」というやり方を行っています。

実はそうしている理由がもう一つあって、昔、ツール上での自分の操作ミスとツール不具合により、作成中のモデルが完全に消えたことがあります。それなりにボリュームのあるモデルを作成していたため、かなりショックで、またそのリカバリ（といっても再度のモデル化ですが）に多くの時間を有しました。その時の経験も踏まえ、出来るだけファイル分割したモデルを作成しています。

またファイル分割したモデルとすることで、複数人での並列作業も可能となります。

そのような運用を行う場合のやり方について以下で紹介したいと思います。

プロジェクトの作成

上で説明した様な運用をする場合、分割する粒度を「プロジェクト」とするか「モデルファイル」とするかが、まずはの分岐点となります。
どちらでも大きな問題は発生しませんが、それよりも自身がPapyrus/Eclipseの「プロジェクト」という単位で何を扱っているかに大きく依存しそうな気がします。
自分は RCP版の Papyrus でも通常の Eclipse と同様に扱っており、より大きな括りで扱っている「Workspace」下に関係する C/C++ プロジェクトや Java プロジェクト、XMLプロジェクトやLaTeXプロジェクト等が混在しています。その一つとして「（ある特定の対象向けの）モデルプロジェクト」として「プロジェクト」を位置づけています。
そのため、作成するモデルが最初から小さいことが明確になっている場合を除き、

「Papyrus プロジェクトではなく 素のプロジェクトを作成し、その下に複数のモデルファイルを作成する」

というやり方をとっています。

素のプロジェクトの作り方ですが、Papyrusのメニュー上の File > New から、「Papyrus Project ではなく」、「Other」を選択します。

これにより使用中の Papyrus (Eclipse) で作成可能なプロジェクトやファイルの一覧が表示されるので、その中の

General > Project

を選択します。

これにより素のプロジェクトファイルが作成可能です。

モデルファイルの作成

その後は、作成したプロジェクトを Project Explorer 上で選択して、同じく File > New から、「Papyrus Project ではなく、Papyrus Modelを選択」します。

その先は通常の Papyrus Project での作成作業と同じダイアグラムが表示されます。

これを繰り返すことにより、一つのプロジェクト下に複数の Papyrus Model （ファイル）を作成することが可能です。

以下は SimpleProject という素のプロジェクト下に Papyrus Model として A、B、C という3つのモデルファイルを作成したプロジェクトの例です（Project Explorer 表示）。

各々のモデルファイルをダブルクリックすると、そのモデルが Papyrus 上で開かれます。

モデルパッケージのImport

今、Papyrus Model の A には ClassA クラスが、Papyrus Model の B には ClassB クラスが定義されているとします。

そしてPapyrus Model の C において、A の ClassA クラス、および B の ClassB を用いて新たなClassC を定義したいとします。

そのためには Model C において Model A パッケージと Model B パッケージを Import するとが必要となります。

まずは  C を開いて、その Model Explorer 上でトップの Model （ここでは C ）を選択します。

その後、マウス右クリックで

Import > Import Package from User Model

を選択します。

するとワークスペース内のプロジェクトからUMLモデルとしてImport可能なモデルファイルが選択可能となります。

ここで、「A.uml」および「B.uml」をマウスで選択し、ダイアログ中央にある [⇒] ボタンで、右側に表示させ [OK] ボタンを押します。

その後、どのパッケージ要素を Import するかの選択用ダイアログが表示されます。

ここで A と B を選択することになるのですが、注意点が「Action」です。
ダイアログ中央ぐらいにある 4 つのボタンのうちの3つが対応しているのですが、Actionとしては昔の記事「Papyrus における登録済パッケージのインポート」に示した通り、以下の3種類:

• Load
• Import
• Copy

があり、どれを選択するかで対応する [Load All] [Import All] [Copy All] ボタンをクリックします。

今回は Import で進めるとして、[Import All] ボタンをクリックするとダイアログの表示が以下となります。

これで [OK] を押すと、Model Explorer 上で Model A と Model B が現れます。

あとは Model C 上で ClassA や ClassB をダイアグラム上に Drag & Drop しながら、モデル作成を進めていけます。

モデル作成

試しに Model C 上でClassAとClassBをCompositeする「Cクラス」を定義してみると、このようになります。ClassA と ClassB は Model Explorer 上から Drag & Drop しました。

なお、ClassA や ClassB が別パッケージ由来というのが少し分かりにくいので、明示したい場合には、ClassA （やClassB）をダイアグラム上で選択し、Properties の Appearance の一番下にある

「Qualified name de」

を適切に切り替えることで表示が変更されます (de って何でしょうかね？ なにかしら単語が途中で切れているのでしょうか？ それともフランス語の前置詞 de なのでしょうかね？？）

モデル名の英語表示と日本語表示

Tipsです。

モデル化を行っている時に、モデル要素の Properties 表示で「Name」と「Label」があります。

普通にモデルの名前をつけた場合、この「Name」の所に名前がついていると思います。

それが正規の「モデル名」だとして、この「Label」は表示名を表します。

特に日本語圏でモデル化を行っている場合、

• モデル化を検討している時や人に見せる時には「日本語」で表示したいけど、モデル作成後にコード生成を行う場合には「英字名」を使いたい

というケースもあるかと思います。

その場合、この「Label」が役に立ちます。

上記の例で「NameをCar」とし「Labelを自動車」として与えると、モデル表記（例えばクラス図）上では「自動車」と表示されます。内部的な正規の名前は「Car」のままです。

「別に Name の所に日本語名を入れれば良いのでは」と思われるかもしれませんし、たしかにそれで問題なく名付けも表示も行われますが、例えばJava/C++のコード生成などをした際に日本語名がトラブルになることがあります。

そのため、日本語を使用したい場合には、

• 正規名（Name）は英字名で
• 表示名（Label）は日本語で

として運用されることをおすすめします。

なお、幾つか「バグ？」と思われる挙動があり、最初に Name に日本語名を付けてモデル化作業を進め、その後、「NameからLabelに日本語名をコピペして、その後、Nameに英字名をつける」とした場合、正しく名前が表示されないとか、Labelにコピペした日本語名が消失するという問題に出会うことがあります。
最初に Name に日本語名をつけることは自分もすることが多いですが、そのような名前変更の作業を行う場合には、

1. 最初に Name に書かれている名前を「切り取り（Cut）」
2. その後、Nameに英字名を入力し Enter キーを押して確定
3. その後、Label に切り取っておいた（日本語の）名前を「貼り付け（Paste）」
4. その後、Labelの所で Enter キーを押して確定

という手順を取る方がトラブルに合わなくて済むかと思います。

なお手順2および手順4で Enter キーで確定した場合、セルの色とダイアグラム上のモデル名が変わるので、変更されたことの確認を明確に行うことが可能です。

Model パッケージ

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

• .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 の所で入力可能です．

モデルのドキュメント出力

Papyrus で作成したモデルプロジェクト全体をドキュメント出力したい場合には

が最も有効な手段となります．
Gendocは ドキュメントテンプレートを用いて EMF モデルからドキュメントを生成する　`From models to documents' のためのプラグインであり，

• OpenOffice Writer (.odt)
• Microsoft Word (.docx)
• Microsoft Excel (.xlsx)
• Microsoft Powerpoint (.pptx)

のファイルを出力することが可能です．
プロジェクトのサイトは

https://www.eclipse.org/gendoc/index.php

になります．

このプロジェクトは進捗やリリーススケジュールが分かりづらく，一時期は全く機能していないのでは？と思えたりもしましたが，最近は主要な開発者の方から色々とコミット頂けた様で少し動きが出ています．
最新のバージョンは 0.7.1 です．ただリリース時期と対応する Papyrus のバージョンが微妙で，プロジェクトのホームページ上に記載された情報によると，その元となる 0.7.0 がリリースされたのが

26th Mars 2018 : Gendoc 0.7.0 is now 

とのことで，この 2018-3-26 という日付が示している Papyrus のバージョンが何かというのはよくわからないです．
ただこの先のロードマップの宣言は明確に示されており，

Future releases

Gendoc v0.8.0 (2018)

• Photon Release.
• Error reporting improvements.
• Improved XLSX file format support.
• Improved PPTX file format support.
• Improved Rich Text support.

Gendoc v1.0 (2018)

• API freeze

とのことです．
今年中には Photon 対応を行い，またバージョン1.0 品が正式に出る予定みたいです．

今年色々とアップデートがあるみたいなので，Nightly Build を使っておくのも良いかもしれません．Nightly Build のリポジトリは以下で確認できます．

https://www.eclipse.org/gendoc/downloads/download.php

ここに示されているLocationを Papyrus の Install New Software ... のダイアログ上に Add する形でインストールと適宜のupdateが可能です:

使い方は下記の pdf を参照してください：

Gendoc v0.7 tutorial