継承先クラスでの継承元クラス要素の表示

Tipsです。

「区間の名前表示と区間で表示するモデル要素」という記事で、クラス図において、クラスの区画上で表示する要素の選択や、表示する区画自体やそのタイトルの選択方法について説明しました。

関連して、「継承先クラスで継承元クラスの要素の選択表示は行えるか？」の話しです。

答えは「行えます」

上記の元記事にあるBaseクラスを継承してDerivedクラスを規定したとします。

DerivedクラスにBaseクラスの要素を表示するかどうかの操作は元記事と同様に Derived クラスをマウスで選択した後、

Filters → Show/Hide Contents

から行います。

上記操作により以下のダイアログが表示されます。

見ての通り、「(from <Class> Base)」として Base クラスの要素の表示が可能です。

全てをチェックしてOKとすると、クラス表記は、

となります。

なお「Show/Hide Contents」として表示されるダイアログ上で y や b が選択肢として出てきませんが、これはそれらが「private」として定義されているためであり、正しい動作となります。

区間の名前表示と区間で表示するモデル要素

Tipsです。

Model Explorer 上で以下の様に示されている 3つのProperty 「x, y, z」と 3つのOperation 「a, b, c」を持つクラス Base を考えます。

クラス図上で Base クラスは以下の様に表示されると思います。

クラス名「Base」の下にある attributes を表示する「区画」(Compartment）に「x, y, z」が表示され、operations を表示する区画に「a, b, c」が表示されています。

この表示に対し

• 各区画が何を表示する所かを明示したい
• 各区画で表示する内容を選択したい

という様な時のツール操作方法です。

まずクラス図上で対象のクラス（ここではBaseクラス）をマウス左クリックで選択し、その後、マウス右クリックで表示されるドロップダウンリスト上で「Filters」を選択します。

すると幾つかのメニューが表示されます。

ここで

• Show/Hide Contents を選択すると表示する要素の選択
• Show/Hide Compartments を選択すると表示する区画や区画の名前の選択

が行えます。

まず「Show/Hide Contents」ですが、以下のダイアログが表示されます。

このチェックボックスを選択もしくは選択解除することで表示する要素を選べます。

例えば、attributes としては「xのみ」、operations としては「a, bのみ」を表示したい場合は、そのようにチェックボックの選択を行い、

[OK]ボタンを押すとクラス図での表記が以下の様に変更されます。

また「Show/Hide Compartments」ですが、以下のダイアログが表示されます。

ここで

• 左側の「Compartments To Display」が区画自体を表示するかどうか
• 右側の「Display Compartment Title」が区画の名前を表示するかどうか

の選択となります。

まず右側の「Display Compartment Title」を試してみます。現在表示されている3つの区画全てにタイトル表示のチェックを行うと、

クラス表記は以下の様に変わります。

無事に区画のタイトルが表示されています。

次に「Compartments To Display」を試してみます。

まず attributes 区画だけの表示を試してみます。

この時、チェックを外した区画の「Display Compartment Title」のチェックはあってもなくても構いません。これでOKを押すと、

とBaseクラス上で attributes 区画のみが表示されます。

今度は operations 区画だけを表示させてみます。ダイアログ上の選択で、

としてみます。こうするとクラス表記は、

と変わります。

これらをうまく組み合わせて、同じクラスモデルでも表示する内容を選択して、各図で何を示そうとしているのかを明確にすることが可能です。

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

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 キーで確定した場合、セルの色とダイアグラム上のモデル名が変わるので、変更されたことの確認を明確に行うことが可能です。

関連における表示要素の選択

Tipsです。

２つのクラス間で関連 (Association。Composite や Shared など）をモデル化した後、関連端などの表示内容を表示する・しないを変更したい時があります。

例えば

というモデルにおいて、「A_engine_car」と名付けている関連が持つ関連端の多重度「１」や名前「car」や「engine」を非表示にしたい等です。

上記モデルでは

• Carクラス側の「+car」を非表示にしたい
• Carクラス側の「1」を非表示にしたい

というケースが多いのではないでしょうか。

また上の図の例では関連に陽に名前をつけて「A_engine_car」としてますが、作成したモデルにより、関連の名前を表示したり非表示にしたりを調整したい時です。

その場合は、関連のエッジをマウス左クリックで選択した後、マウス右クリックで表示されるドロップダウンリストから

Filters → Show/Hide Labels

を選択します。

すると、表示する内容を選択するダイアログが表示されます。

このチェックボックスのチェックを切り替えることで、表示内容を選択可能です。

例えば Engine クラス側の関連端内容の表示のみを行いたい場合には、

を選びます。

すると以下のように所望のモデル表示となります。

例えば関連の名前をモデルにはちゃんと規定したいが表示はさせたくないから付けないという人もおられるかもしれませんが、上記の設定を使用すると、モデル化とその表示とを分離して作業を進めることが出来ます。

なお上記の Filters からのドロップダウンリストに

• Show All Labels
• Hide All Labels

というメニューも見えますが、まさに名前の通りの挙動となります。

関連端の可視性の変更

Tipsです。

Papyrusのクラス図を用いたモデル化の際、Association（CompositeやShared）で2つのクラス間を関連付けた後に「可視性」（Visibility）を変更したい時に、どうすれば良いか悩む時があります。

例えば

とモデル化した後で、Engineクラス側の関連端「engine」の可視性を、今の ＋ (+engine。ようは public）から ー (-engine。ようは private） に変更したい時などです。

Association のエッジを選択して Properties タブを見てみると、関連端に対する「名前」や「多重度」など幾つかの属性は変更出来ますが、可視性（Visibility）を変更できる所はメニューにはありません。

以下の図のような感じです。

このような時に可視性を変更するには、上記図のような Association に対する Properties タブから行うのではなく、Model Explorer 上に見える Car クラスのプロパティとしての「engine」を選択することで行います。

Model Explorer の Car クラスを見ると、

のように Carクラス に engine が見えると思います。

これをマウスで選択し、Properties タブを開くと、

のように Carクラスの Property としての engine の編集が行えるので、ここで「Visibility」を public から private に変更します。

これにより、クラス図上で 「- engine」と変更されます。

このような Tips が Papyrus には色々と存在しているので、また紹介してゆけたらと思います。

ちなみに上記の Propertiesタブ で、可視性を public から private に変更した際、図の左上にあるアイコンが変わっていることにも気づけるかと思います。Model Explorer 上でも

のように変動して private メンバを示すアイコンに変更されています。

Papyrus のロードマップ

今後の Papyrus について

最近はツールとしての開発もある程度は落ち着き、またUML自体の大きなバージョン変化が無い中で、今後 Papyrus がどの方向に向かっているのかが気になります。

開発側のweb情報を探しても纏まったものが見当たらない感じですが、先だっての2019年10月に開催された EclipseCon Europe 2019 において 「The evolution of Papyrus, an open SysML and UML tool」 という発表が、 Camille Letavernier (EclipseSource) さんと Philip Langer (EclipseSource) さんからなされています。

なお上記の各リンクをクリックすると同発表や発表者のページに飛びます。また直リンクもはりましたが、 発表資料（pdf） もそこに置かれています。

今回はその内容について見ていきたいと思います。

なお同発表内容は YouTube でも公開されていますので、発表資料と共に視聴されると、より詳しく確認出来るかと思います。

The evolution of Papyrus, an open SysML and UML tool

発表資料は全部で21ページです。なお原著は上のリンクの通りです。

ページ 1/21

表紙です。UMLツールとしてだけではなく SysMLツールとしてもアピールしていますね。

ページ 2/21

UMLベースのモデリング環境としてのアピールが通常の通りなされていますが、一番最後に、本発表全体での大きなテーマである「Domain-Specific (Modeling) Tool の構築が可能」であることがアピールされています。

ページ 3/21

ドメイン特化のモデルベースエンジニアリングがとても有効であることは I agree です。

コード生成やシミュレーションの機能が有効に働くかどうかは、どういうドメインか、やどういうエンジニアリングかに大きく依存しそうには思います。

ページ 4/21

様々な見え方は（もちろん相応する適切な内容と共に）必要だと思います。また良くも悪くも表形式というものは重要との認識です。

また確かにアイコンも重要ですね。一瞬にして、齟齬が少なく理解出来るので。大物の開発では、理解するための時間の短縮もとても重要ですし、受け取る人の適性もありつつ直感的に受け止められることが重要だと思います。

象形文字に起源を持つ表語文字である漢字を多用する我々は、特にそうなのかもしれません。

ページ 5/21

汎用モデリング言語である UML や SysML (1.X系かな？）と Domain-Specific Modeling は両立しないか？の問には確かに「NO!」(両立可能) だと思います。

後でも出てきますが Papyrus は UML Profile をサポートしています。UML Profile を使って DSML を実現する場合、Papyrus はプラットフォームとして使用可能だと思いますし、自分もそういう使い方をすることが多いです。

ページ 6/21

Eclipse のモデリングフレームワーク (EMF) を用いプラグインとして開発されている UMLベースの Papyrus であれば、EclipseおよびEMFをベースとした良いモデリングプラットフォームとなると思います。

ページ 7/21

Papyrus as a Platform の核は UML Profile となるみたいですね。合意します。

僕も UML Profile は多用してますが、あんまりこのブログでの記事としては記載していないですね。標準やAdd-onのProfileや自身で定義したProfileを含め、ほとんどの開発では、何かしらの UML Profile は作成して差し込んで使っています。

ページ 8/21

ここまでの話しと同じ内容ですが、ここでいう codegen や validation に対する「Powerful API」とは、どの機能が提供している API を指しているのですかね・・・

ページ 9/21

ここでの「Example and Demo」では UML Profile を定義・適用してモデル要素にドメイン特化の意味付け（ステレオタイプにて）を与えることが出来ることと、CSSライクなスタイルファイルにより表示内容が変わることが説明されたみたいですね。

先の YouTube ビデオの 11:06 ぐらいの所から説明されています。

UML Profile の適用や、標準スタイルの変更で CSS を使ったことはありますが、ステレオタイプで見え方が変わるというのは試したことがないですね。また、試してみたいと思います。

ページ 10/21

Papyrusに対してDSL向けの（フルな）カスタマイズさえもしたことがないですね。基本的に Profile 作成・適用で、見た目等は全て通常のUML UIで行っています。 まだまだ試してない機能も多いですね。

ページ 11/21

Papyrus UMLLight ですが、前に学習用として調べたことはあります。サイトは ここ になると思います。

OMG CERTIFIED UML PROFESSIONAL 2 (OCUP 2)の FOUNDATION LEVEL として示されている UMLのサブセット:

• UML Use Case
• Activity Diagram
• Class Diagram
• State Machine
• Package Diagram
• Sequence Diagram

に特化して、設定出来るプロパティ等も基本的なものになっていた気がします。

ただ、今見てもバージョンが UMLLight 0.0.1 RC2 のままで、またファイル置き場も Google Drive のままな気がします。 UMLLightに関する今後の開発スケジュールも知りたい所です。

なおアイコンが少し変わっていて以下のようになっています。日本で言えば「若葉マーク」なのかな、と思えますが各国共通なのでしょうかね？？

SysML 1.6 は既に公開されていて Market Place から導入可能ですね。僕も使っています。

ページ 12/21

Papyrusで作成したモデルの diff および Merge ですね。僕自身はまだ使ってないですが、欲しいものであることは確かです。

今後は積極的に使ってみようと思います。

ページ 13/21

残りとしては、ベースとなる Eclipse のUI基盤に基づき今後 UI technology と Rendering Technology が変わるとのこと。

ページ 14/21

PapyrusのUIは GEF (Graphical Editing Framework) で作られています。 GEFのバージョン毎の進化は Wikipedia にまとめられています。

ページ 15/21

なるほど、GEF 3ベースから GEF 5ベースにマイグレーションするわけですね。より modern になるわけですか。 永続的な進化のためには必要になるとは思います。大変だとは思いますが。。。

ちなみに「Papyrus GEFx」という名称を固有名詞として使っているように思えますね。

ページ 16/21

ここは飛ばします。

ページ 17/21

ここも飛ばします。

ページ 18/21

頑張って欲しいです、Papyrus GEFx。

ページ 19/21

Web-based Papyrusも悪くないですね。僕自身への直近のメリットとしては、Eclipseベースといえ、時たまPC環境の違いで問題となることもあるので、 それが解消するといいですね。結構、そういう時は原因がよくわからないので。Eclipseのエラーログも難解ですし。。。

ただ使用する browser によって問題が発生するかもしれませんね。常に使用するbrowserを固定化出来ればいいですが、逆にそちらの方が難しいこともあるかな。

ページ 20/21

見た目の差異はこんな感じみたいです。

ページ 21/21

まだまだ進化し続けるみたいですね。これからも頑張って頂きたいです。