UML/Standard Profile

UMLでは幾つかの「標準プロファイル」が規定されています．

UML仕様書(2.5.1)では22章(Standard Profile) にあたります．

Papyrus でも Standard Profile はサポートされており，Software Designer でコード生成する際に Standard Profile にて規定のステレオタイプが必要になることもあります．

UML 2.5.1 仕様書に規定されている Standard Profile モデルとしては以下の図で示される33個ほどあります．

また Table 22.1 Description of the Stereotypes in the UML StandardProfile に，その詳細な説明が記載されています．以下参考として同内容を転記しておきます． なお34個記載されていますが，これは«Create»の適用先が2つあるためで，ステレオタイプの個数としては33個となります．

若干機械的に翻訳したため説明が分かりにくいものも多々ありますが，詳細な情報を確認し，適宜updateしていければと考えています．

Description of the Stereotypes in the UML StandardProfile

名前	適用先	説明
«Auxiliary»	Class	通常，二次的なロジックまたはコントロールフローを実装することで，より中心的な別のクラスまたは基本クラスをサポートするクラス． 補助クラスは通常，フォーカスするクラスと一緒に使用され，設計中に二次的なビジネスロジックやコンポーネントの制御フローを指定する場合に特に便利． «Focus»も参照のこと．
«BuildComponent»	Component	コンパイルやバージョン管理など，システムレベル開発活動の目的のために定義された要素の集合．
«Call»	Usage	そのソースが操作であり，そのターゲットが操作である使用法の依存関係． この関係は，依存関係が適用されるクラス内に操作が存在するという意味で，操作を含むクラスに包含されることもある． コール依存関係は，ソース操作またはソースクラス内の操作が，ターゲット操作またはターゲットクラス内の操作を呼び出すことを指し示す． コール依存関係は，ソース操作を，範囲内にある任意のターゲット操作（これに限定されるものではないが，囲み分類器の操作および他の可視分類器の操作）に接続することができる．
«Create»	Usage	クライアント分類子がサプライヤ分類子のインスタンスを作成することを示す使用依存関係．
«Create»	BehavioralFeature	指定されたフィーチャが，フィーチャが関連付けられている分類子のインスタンスを作成することを指し示す．
«Derive»	Abstraction	通常同じタイプのモデル要素間の派生関係を指定するが，必ずしもそうである必要はない． 派生した依存関係は，クライアントがサプライヤから計算されることを指し示す． マッピングは計算を指定する． クライアントは，たとえ論理的に冗長であっても，効率性などの設計上の理由で実装することができる．
«Destroy»	BehavioralFeature	指定された機能が，その機能が接続されている分類子のインスタンスを破棄することを示す．
«Document»	Artifact	人間が読める形式のファイル． «ファイル» のサブクラス．
«Entity»	Component	ビジネスコンセプトを表す永続的な情報コンポーネント．
«Executable»	Artifact	コンピュータシステム上で実行可能なプログラムファイル． «ファイル»のサブクラス．
«File»	Artifact	開発システムのコンテキストにおける物理ファイル．
«Focus»	Class	サポートする1​​つ以上の補助クラスのコアロジックまたはコントロールフローを定義するクラス． フォーカスクラスは，通常，1つ以上のAuxiliaryクラスとともに使用され， 設計中にコアとなるビジネスロジックやコンポーネントの制御フローを指定する場合に特に便利． «Auxiliary»を参照．
«Framework»	Package	システムの全部または一部に対して再利用可能なアーキテクチャを指定するモデル要素を含むパッケージ． フレームワークには通常，クラス，パターン，またはテンプレートが含まれる． フレームワークがアプリケーションドメインに特化している場合， フレームワークはアプリケーションフレームワークと呼ばれることもある．
«Implement»	Component	仕様自体を持たないことを意図したコンポーネント定義． むしろ依存性を持つ別個の「仕様」の実装．
«ImplementationClass»	Class	インスタンスが複数のクラスを持たないプログラミング言語（C++，Smalltalk，Javaなど）のクラス実装． これは，Classとは対照的である． インスタンスは，一度に複数のクラスを持ち，時間の経過とともにクラスを獲得したり 失ったりする可能性があり，オブジェクトは複数のクラスを動的に持つことがある． Implementationクラスは，Classifierのオペレーションに指定されたのと同じ振る舞いで， Classifierに対して定義されたすべてのオペレーションを提供する場合，Classifierを実現すると言われている． インプリメンテーション・クラスは，いくつかの異なるタイプを実現することができる． Implementationクラスの物理的属性および関連は，それが実現する任意のClassifierのものと同じである必要はなく， Implementation Classは，その物理的属性および関連性に関して操作のためのメソッドを提供することができる． «Type»も参照のこと．
«Instantiate»	Usage	クライアント上の操作がサプライヤのインスタンスを作成することを示す分類子間の使用依存関係．
«Library»	Artifact	静的または動的なライブラリーファイル． «File»のサブクラス．
«Metaclass»	Class	インスタンスもクラスであるクラス．
«Metamodel»	Model	いくつかのモデリング言語（たとえば，MOFモデル）のモデリング概念を指定するモデル． «Metaclass»を参照．
«ModelLibrary»	Package	他のパッケージによって再利用されることを意図したモデル要素を含むパッケージ． いくつかのプログラミング言語では，クラスライブラリに類似している． モデルライブラリには，プロファイルおよびステレオタイプなど， 12.3節で指定されたメタモデル拡張メタクラスのインスタンスは含まれない場合がある． ただし，ProfileApplicationsおよびStereotypeアプリケーションが含まれている場合があり， モデルライブラリはしばしば適用されたプロファイルと共に使用される．
«Process»	Component	トランザクションベースのコンポーネント．
«Realization»	Classifier	オブジェクトのドメインを指定し，それらのオブジェクトの物理的な実装も定義する分類子． 例えば«Realization»によってステレオタイプ化されたコンポーネントは， 別個の«Specification»コンポーネントで指定された動作を実装する分類子を実現するのみ． «仕様»を参照． «ImplementationClass»は，システム設計者にとって有益な属性やメソッドなどの機能を持つことができるクラスの実現であるため， «ImplementationClass»とは異なります．
«Refine»	Abstraction	異なる意味レベルでのモデル要素間の洗練された関係（分析や設計など）を指定． マッピングは，2つの要素または要素のセットの間の関係を指定する． マッピングは計算可能であってもなくてもよく，単方向または双方向であってもよい． リファインメントを使用し，分析から設計およびその他の変更に至るまでの変換をモデル化することができる．
«Responsibility»	Usage	要素の他の要素との関係における契約または義務．
«Script»	Artifact	コンピュータシステムによって解釈可能なスクリプトファイル． «File»のサブクラス．
«Send»	Usage	オペレーションがシグナルを送信することを指定， クライアントがオペレーションでありサプライヤがシグナルである使用法．
«Service»	Component	ステートレスで機能的なコンポーネント．
«Source»	Artifact	実行可能ファイルにコンパイルできるソースファイル． «File»のサブクラス．
«Specification»	Classifier	これらのオブジェクトの物理的な実装を定義せずにオブジェクトのドメインを指定する分類子． 例えば，«Specification»によってステレオタイプ化されたコンポーネントは，インタフェースを提供し， 必要とするだけであり，その定義の一部として実現クラスを持たないことを意図している． «Type»は，アナリストのモデリングシステムにとって有用な属性やメソッドなどの機能を持つことができるため， «Type»とは異なります． «Realization»を参照．
«Subsystem»	Component	大規模システムにおける階層分解の単位． サブシステムは一般的に間接的にインスタンス化される． サブシステムの定義はドメインやメソッドによって大きく異なり， ドメインとメソッドのプロファイルがこの構造を特化することが期待される． サブシステムは，仕様と実現要素を持つように定義することができる． «Specification»と«Realization»を参照．
«SystemModel»	Model	SystemModelは，同じシステムのモデルのコレクションを含むステレオタイプのモデル． SystemModelには異なるモデルに含まれるモデル要素間のすべての関係と制約も含まれる．
«Trace»	Abstraction	異なるモデルで同じ概念を表すモデル要素またはモデル要素のセット間のトレース関係を指定する． トレースは，主にモデル間の要件と変更を追跡するために使用される． モデルの変更は両方向で発生する可能性があるため，依存関係の方向性はしばしば無視できる． マッピングは2つの間の関係を指定するが，ほとんど計算可能ではなく通常は形式でない．
«Type»	Class	それらのオブジェクトの物理的な実装を定義することなく， オブジェクトに適用可能な操作と共にオブジェクトのドメインを指定するクラス． ただし属性と関連性を持つことがある． タイプ操作の動作仕様は，例えばアクティビティ図を用いて表現することができる． オブジェクトは実装クラスを最大で1つ持つことができるが，複数の異なる型に準拠することができる． «ImplementationClass»も参照．
«Utility»	Class	インスタンスを持たないクラスで，属性と操作の名前付きコレクションを表す． これらはすべて静的である．

Qiita からのリンク

最近 Qiita の記事からリンクを張っていただいたおかげで，そこからの来訪者の方が増えてきております．

OSSのUMLモデリングツールpapyrusを使ってみよう ~インストール編~

感謝です．

記事を起こされた背景をたどっていくと，なるほど  astah community版がなくなったことで，この先の技術教育で使用するツールをどうするか，というお話しなのですね．

あとは ETロボコンも絡むのですかね？？

もしそうなら Papyrus SW Designer の記事もそろそろアップした方がよいのかしらんと思ったりしたりしています．

僕が Papyrus RCP を最新版に更新した際に Eclipse Market Place から入れるのが 「SysML Profile」と「Papyrus SW Designer」の2つですしね．

特に Papyrus SW Designer を入れると「C/C++」や「Java」や「MARTE」のプロファイルが入るので，それだけでも重宝するのではと思います．

SysML v2 について

最近，何故か知りませんが SysML v2 の blog ページへのアクセスが急増しています．

このページです

SYSML V2

どこで何があったのでしょうか？

逆にキーワードは聞こえてくるけども，なんら新しい情報が入ってこないので，このページにたどり着いておられるのかもしれませんね．

僕もあまり最近の情報は知らないのですが，直近で知って「へー」と思ったのが，このプレゼンです．2019-2-18との日付が打たれています：

SysML v2 and the Next Generation of Modeling Languages

Model Driven Solutions社の CTO である Ed. Seidewitz さんの資料で，概要も上記ページに記載されています．

へーと思うのが資料上にある以下の内容です：

• SysML v2 will be based on a kernel metamodel, rather than UML.
• The kernel semantics will be grounded in a declarative formalism.
• Full language semantics will be specified using a semantic model library.
• The SysML v2 specification will include a separate volume with a self-contained definition of the Kernel.

そして

• It will be natural to build a other modeling languages on this rigorous foundation.
• Will UML v3 be a profile of SysML v2?

とのことです．


なんということでしょう（笑）

なかなかの大作になりそうですね，SysML v2 は．

読まないといけないものが，また増えそうです ><

Vienna University of Technology でお話しされた内容の様でして，その概要が以下のページに記載されています：

SysML v2 and the Next Generation of Modeling Languages – Ed Seidewitz, February 18th, 4 p.m. Vienna

関連する部分を抜粋しますと，RFP(Request for Proposals) の発行後，

A year into this work, it is clear that SysML v2 needs to be more than just an expansion of the functional capabilities of SysML. Rather, it must address fundamental architectural issues that have made it difficult to further evolve SysML v1 to address the needs of its user community.

Therefore, the language is being re-designed using a new kernel metamodel with formally grounded semantics. This kernel can then be extended using semantic model libraries, rather than by expanding the language metamodel itself.

This approach will allow SysML v2 to be not only the modeling language for traditional systems engineering, but also the foundation for a whole new generation of modeling languages.

とのことです．

ちなみに  Ed. Seidewitz さんは以下の YouTube で解説されておられる方ですね：

Overview: UML® (Unified Modeling Language™) and SysML® (Systems Modeling Language™)

MARTE 2.0 RFI

MARTE (UML Profile for Modeling and Analysis of RealTime and Embedded Systems version) の version 2.0 に向けた RFI (Request For Information) が発行されているのに気が付きました．

MARTE 2.0 RFI (OMGページ)

に RFI のドキュメントと Response list があります．

RFI ドキュメントに記載の Summary of this RFI では

Our goal is to modernize, enhance and integrate the embedded hardware and software model-based design and analysis frameworks that are enabled by MARTE with the opportunities that heavily distributed and intensive communication run time environments as well as other modern technologies offer nowadays. Since the inception of MARTE, 12 years ago, a number of OMG standards have emerged to improve the UML base semantics, and additional new analysis and design techniques as well as application domains (e.g., IoT and AI) for MARTE have appeared. Then, to drive the update of the language over the basis of the updated UML and its related standards, it is time to seek inputs from the community for potential enhancements and additions in the various domains in which MARTE could be used, and to account new design and analysis techniques that emerged in the meantime. 

The purpose of this RFI is to identify the community of interest and to identify potential stakeholders, along with their specific interests and needs. These will be used to prepare a roadmap for MARTE evolution and more specifically concrete requirements for MARTE 2.0.

とのことです．
詳細は上記のOMGホームページにて．

SysML2.0 のこともありますし，色々と動いていますね．

Papyrus 2019-03 release (4.3.0)

ここ数ヶ月，本業がかなり忙しく，なかなかブログを更新できないままなのですが，
今日，ふと，

Papyrus 2019-03 (4.3.0)

がリリースされていることに気づきました．

Eclipse の 2019-03 がリリースされたことに対応する版みたいです．

あまり最近，プロジェクト側で大きなアクティビティを感じてなく，

「2019-03 はスキップかな」

と思ってましたので，少し驚きでした．

ちなみにupdate内容は以下とのことです：

• Diagram:clean some code that was not used anymore
• Sequence diagram fix problem about fragment ordering
• CDO:
• add benchmark code for 
• add aa way to add and edit easily CDO User

さほど目立った改善はなさそうですがシーケンス図は色々と問題を感じるので，改善され続けていくのは良いことですね．
色々とアグレッシブな改変を発生させるよりも，こういう着実な改善を進めることも，もちろんですが大事だと思います．

ダウンロードはこちらから．

なお前の 2018-12 リリースからそうですが 64bit 版のみです．

Papyrus 2018-12 が12/19にリリースされたというニュースが公開されました :-)

少し妙なタイトルで始めてみました :-)

Papyrus 4.2.0 2018-12 がリリースされたというニュースが公開されました：

Papyrus 4.2.0 2018-12 Released 

Posted Dec 19, 2018 とのことです．

リリースに気づいていなかったわけではなく，POST自体はその日にされたのかもしれませんが今までずっと公開されていなかったわけで，ようやく公開された形です．

12月からリリースに向けた状況を Papyrus の Jenkins から確認していたのですが， 僕の認識だと実際のリリース予定日の12/19の直前にコミットされたコードからビルドに失敗するという状況が発生し，リリース予定日を超えそのまま2019に突入．最近，なんとか安定してきたので，ようやくニュースリリースを公開した，という様に思えます．

変更内容は Eclipse Papyrus 4.2.0 の詳細ページ に記載されています．

またダウンロードページに RCP 版も準備されています．前にアナウンスがあった通り64bit版のみ提供となっています．

いつもはすぐにでも試してみるのですが， Jenkins を見るとまだ All Clear という感じでもなさそうなので，ぼちぼちと試してみようと思います．

Papyrus 2018-12 まであと２週間

最近，記事の投稿がおろそかになっています．
書きかけの記事は結構たまっているのですが，なかなか推敲が進みません．

少し気分をかえて，今月に予定されている次のリリースについてです．
次のリリース Papyrus 2018-12 は 12月19日に予定されています．
より詳しく言うとアメリカ東部時間での 12/19 10:00 でして，日本時間に換算すると確か14時間差なので 12/19 24:00，ようは 12/20 0:00 でしょうか．

なお上記日時は正確には Eclipse-2018-12 のリリース日なので，もしかしたら Papyrus 単体，特に RCP としての正式リリースは少し遅れるかもしれませんね．
Eclipse-2018-12のリリーススケジュールはここから確認できます．

最新の Weekly Problem Digest for Papyrus を見ると，大幅に Problem が減ってきているので，Papyrus-2018-12 リリースに向けて大きく対応がなされていると思います．

リリースが楽しみです．

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/Eclipse の Simultaneous Release

以下の投稿から:

[mdt-papyrus.dev] Oomph Setup for New Release Cadence

Papyrus は Eclipse の 同時配信（Simultaneous Release）のスキームに従っており，次のリリースはこの12月です．

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

Simultaneous Release

簡単にいうと四半期（13週）ごとにローリングリリースされるモデルです．
これまでは年に一回６月のリリースでプラットフォームのマイナーバージョンアップがなされ：

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月リリース予定

Papyrus における登録済パッケージのインポート

Papyrus 上でモデル作成を行っている際，作成した他パッケージのモデルを使用したり，すでに Papyrus に登録済のプロファイル内で定義されている他パッケージを使用したいことがあります．
これをうまく使うと，様々なモデル定義（モデルファイル）を効率的に分割して作成・管理でき，また再利用も容易となるため，モデルベースの開発を効率的に行うことが可能となります．

今回はその様なケースにおいて

「すでにPapyrusに登録済のプロファイル内で定義されている他パッケージを使用」

するやり方について考えたく思います．

またその具体的な例として，Papyrus Software Designer を導入することで Papyrus で使用可能となる

「MARTE」… Modeling and Analysis of Real-time and Embedded systems

に登録されている各種パッケージを閲覧・使用することを試してみようと思います．

まず画面上の「Model Explorer」上で対象モデルを選択し，マウス右クリックで現れるドロップダウンリストの Import を選択，そこから

Import Registered Package

を選択します．

Import Registered Package

これにより以下のダイアログ「Libraries to import」が表示されます．

ここに様々な登録済のモデル要素が表示されます．上記の図にも

• JavaLibrary
• JavaPrimitiveTypes
• Pthread (subset)
• Socket (subset)
• SysML-Standard-Library

等が見えるかと思いますが，わざわざ自身でモデル定義しなくとも，既にあるものを活用する方が便が良いと思います．ただ，各モデルがいつまでサポートされるかは不明ではありますが．

今回は「MARTE」のパッケージを使用するため，リスト中段くらいにある

MARTE_Library

を選択します．ダイアログの下段あたりに本パッケージが「CEA LIST」により開発・提供されていることが見て取れます．

パッケージを選択し，その後 [OK] を押すと，下記のようなダイアログが表示されます．

ここで一つのポイントがあるのですが，含まれているモデルを Import する際の挙動（Action）として，ダイアログ下側のボタンにも表示されている通り，

• Load
• Import
• Copy

の3種類があることが分かります．

これらの意味（挙動）の違いは以下となります．

• Load
• 指定したパッケージを単にモデルにロードする．作成中のモデルには何も変更は発生しない．
• Import
• 指定したパッケージをモデルにロードすると共に，モデルから同パッケージに対し PackageImport の関係が設定される（そのため作成中のモデルに変更が発生する）
• UMLのモデル要素の一つである「PackageImport」は，ある名前空間内にImport先のモデル要素を非修飾名で使用可能とします
• Copy
• 指定したパッケージのローカルコピーをモデル内に作成する．Importに似ているが PackageImport の関係を設定せず，対象パッケージに含まれる要素のクローンをモデル内に作成する

またその使い分けは，

• インポート先のモデル修正も随時行っており，その修正内容を適宜反映したい場合は「Import」
• インポート先のモデルの現バージョンをコピーし，それを元に今回のモデルを構築する場合は「Copy」
• その後のインポート先モデルの変更には影響されない
• とりあえずインポート先のモデルを使ってみたい場合は「Load」

となるかなと思います．

先のダイアログに戻ります．

表示されているすべてのモデル（パッケージ）に対して「全て同じ」操作をしたい場合には，ダイアログ上の [… All] のボタンを使用します．
また表示されているモデル中の特定パッケージを使用したい場合には，チェックボックスにチェックをします．その際，Load なのか Import なのか Copy なのかは選択したすべてのパッケージに対して共通であることに注意が必要です．

今回は [Import All] で進めることにします．
[Import All] のボタンをクリックし，その後，[OK] ボタンをクリックします．

これにより Model Explorer 上に対象のモデルパッケージが表示されます．
下記の図では上から３つ目のパッケージ「≪ModelLibrary》 MARTE_Library」です．

≪ModelLibrary》 MARTE_Library

MARTEの仕様では，その Profile 内で様々なパッケージが定義されており，それらが作成中のモデル内で使用可能であることが見て取れると思います．

Import対象がプロファイルの場合には，一般的には作成中のモデルに Profile を適用し，そこに含まれるステレオタイプを自身のモデルに指定することが多いかと思いますが，そもそもProfile 定義の中身がどうなっているかを確認したいケースではこのモデルのインポートは大変役に立ちます．

Papyrus が起動しない / Java VM

Papyrus-2018.9 を起動しようとしたら起動しなくなりました...

エラーを告げるダイアログがいっぱい出てきます．

Error: opening registry key 'Software\JavaSoft\JRE

Error: could not find java.dll

Error: Could not find Java SE Runtime Environment

これらは Java Virtual Machine Launcher が出しているものですね．
この後に Eclipse 自体のエラー出力が表示されます．
タイトルには Papyrus と表示されていますがベースとなる Eclipse そのもののエラーです．

Java was started but returned exit code=2

Papyrus(Eclipse)が使用している JavaVM に問題があるとのことですが，さて何かしたかしらん，と考えてみると，そいえば少し前に Java の update が表示され対応したことを思い出しました．
確かにいつもとは違うアップデート画面で，インストールされているものを削除するという手順があったため，色々と削除したことを思い出しました．
Javaはほっておくと色々なバージョンがインストールされてしまうため，古い奴を消してくれる便利機能でも追加されたのかなと深く考えなかったのですが，どうやら違ったみたいです :-)

コマンドプロンプトをあげて javaw.exe や javac.exe をたたいてみても，同じようなメッセージがテキストで表示されました：

c:\Eclipse\papyrus-2018-09-4.1.0-win64\Papyrus>java
Error: opening registry key 'Software\JavaSoft\JRE'
Error: could not find java.dll
Error: Could not find Java SE Runtime Environment.

さてはてと考えていると，ふと先日， Oracle がJavaのライセンスやリリースモデルを変更するってニュースリリースしてたなぁ，と思い出しました．詳細はここに書いてあるものです：

JDKの新しいリリース・モデルおよび提供ライセンスについて

まぁ今もちゃんと読んではいませんが，ようは無償で使う場合には今後は OpenJDK を使ってね，ということでしょうかね(笑)．
Linux環境では OpenJDK を普通に使っているのですが，Windowsでは Oracle JDK をこれまでずっと使っていました．
今回は Oracle JDK から OpenJDK に移行しないといけない状況での不連続点なのかもしれません．

確かに Eclipse/Papyrus を動作させる際，Windows下で使用される JavaVM の問題が発生したこともあり，どうしてもJavaVMを固定化したい場合には Eclipse/Papyrus のインストールフォルダの下に `jreフォルダ' を作成し，そこに JavaVM をコピーして使ったりしていました．もしくは Eclipse の ini ファイルを編集して，使用する JavaVM を固定化したりと．前者は複数人で同じ環境を使う場合（Eclipse/Papyrus環境を配布したりする場合），後者は自分単独で使う場合の対応として使い分けています．

感覚的にはそのような状況と同じような対応をすれば良いかなと．

では，と，OpenJDKをインストールします．
OpenJDK は jdk.java.net からダウンロードできます．現時点での最新版は以下のページから入手可能です：

Java Platform, Standard Edition 11 Reference Implementations

これまでの .exe 形式のインストーラではなく .zip での配布ですね．個人的にはどっちでも，です．

ファイル

openjdk-11+28_windows-x64_bin.zip

をダウンロードし，以下のように C:\OpenJDK フォルダの下で展開しました：

その後，Papyrus のインストールフォルダに行き，ファイル papyrus.ini に以下のように使用する JavaVM を陽に指定しました（赤色の太字の所）．

-vm

C:\OpenJDK\jdk-11\bin\javaw.exe

-startup

plugins/org.eclipse.equinox.launcher_1.5.100.v20180827-1352.jar

--launcher.library

plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.800.v20180827-1352

-showsplash

org.eclipse.papyrus.rcp

--launcher.XXMaxPermSize

512m

--launcher.defaultAction

openFile

-vmargs

-Xms256m

-Xmx900m

-Dosgi.bundlefile.limit=200

赤色の太字以外は元々の設定です．
もしかしたらメモリ関係の設定値を増やしているやもしれませんが忘れました(笑)

これで再度 Papyrus を実行すると，無事に起動しました．

UML Profile

UMLを用いてモデリングする際，ドメインに応じた UML Profile を活用することがモデル化における設計コストの低減や確からしさの確保のためにも重要だと考えています．

OMGで正式に採択された UML Profile にどういうものがあるかは下記webページで確認できます：
UML PROFILE CATEGORY - SPECIFICATIONS ASSOCIATED

同ページには以下にしめす16個の UML Profile がリストアップされています：

• UML Profile for BPMN Processes
• UML Profile for CORBA and CORBA Components
• UML Profile for CORBA Components
• UML Profile for CORBA
• UML Profile for Enterprise Application Integration
• UML Profile for Enterprise Distributed Object Computing
• UML Profile for MARTE
• UML Profile for NIEM
• UML Profile for Modeling QoS and FT
• Software Radio Components
• UML Profile for System on a Chip
• UML Profile for Schedulability, Performance, & Time
• UML Profile for Telecommunication Services
• SES Management TelcoML Extension
• UML Profile for ROSETTA
• UML Profile for Voice-based Applications

メンテナンスされていない Profile も多いのですが「UML Profile for ROSETTA」と「UML Profile for NIEM」はアクティブな活動の様です．とはいえ ROSETTA はまだベータのため，リリース後，すぐに凍結されてしまうやもしれませんが笑

ちなみに両Profile は下記のドメイン言語の模様です：

• UML Profile for ROSETTA
• The ROSETTA Profile will ‘provide precise syntax and semantics that will facilitate the export of UML and SysML system models to a matrix representation that can be used tostructure mathematical knowledge for concordant use in simulation at the conceptual and detailed design levels’.

• UML Profile for NIEM
• NIEM is a national program that empowers organizations to create and maintain meaningful data connections across their stove-piped IT systems, as well as their stakeholder base. NIEM provides data components and processes needed to create exchange specifications which support mission data sharing and exchange requirements. By providing a common vocabulary and mature framework to facilitate information exchange, NIEM enables communities to “speak the same language” as they share, exchange, accept, and translate information efficiently

どちらも興味がありますが，まずは ROSETTA を見てみようかと思います．

Eclipse Papyrus 4.1.0 リリース

無事に Papyrus 4.1.0 がリリースされました．

Eclipse Papyrus 4.1.0 Release Review

9月17日づけの「Weekly Problem Digest for Papyrus」を見ると，まだまだ色々とバグは抱えてそうですが．

4.1.0は以下が変更されているみたいです:

• Diagram: improve sequence diagram combined fragment
• Diagram Layers: add it into the model explorer, refactoring layer model + generation, property view
• diagram generation: improvement.
• fix problems about Xtext support and UML Constraint Language
• continue Architecture Framework support integration.
• releng: change EP1 to EPL2.

最大のポイントはシーケンス図の改善でしょうか．

ダウンロードページから 4.1.0 の RCP が入手可能です．

ダウンロードしてみたのですが，ファイル名が少し変わってますね．

旧）papyrus-photon-4.0.0-win64.zip
新）papyrus-2018-09-4.1.0-win64.zip

photon → 2018-09 となっています．どういうポリシーの変更でしょうか？

バナーでのバージョン表記も 2018-09 に変わっています：

なお次の正式なリリース 4.2.0 は 12月になる模様です．

Papyrus SW designer のニューリリース

Papyrus SW designer の新バージョン (1.1.0)が 8月28日（日本時間では8月29日未明）にリリースされたみたいです．

OxygenとPhotonに対応し，変更内容は

• Bug fixes
• Documentation is now integrated into the Papyrus documentation (Papyrus SW designer section in user and developer doc).
• Unchanged files are not overwritten during (re-)generation. This speeds up compilation time after generation considerably.
• Component ports may have more than 1 provided or required interface

とのことです．

Eclipse Marketplace から，もしくはアップデートサイトから入手可能のようです．

• 1. the Eclipse marketplace: 
• https://marketplace.eclipse.org/content/papyrus-software-designer
• 2. its update site: 
• http://download.eclipse.org/modeling/mdt/papyrus/components/designer/

情報入手元）
http://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/msg04387.html

Papyrus 4.1.0 のリリース予定日

2018年9月19日（水）の様ですね．
日本時間では 9月20日 でしょうか？

内容としてはシーケンス図の改良，Time Observation や Duration の改良，各種Exceptionへの対応等で90個程度の改善を進めている模様です．

リリースが待ち遠しいです．

https://projects.eclipse.org/projects/modeling.mdt.papyrus/releases/4.1.0

Eclipse Modeling Tools のダウンロード割合

Papyrus は Eclipse のプラグインであり，Eclipse がパッケージとしてまとめている

"Eclipse Modeling Tools"

の主要なプラグインの１つになっています．

最近ふと，コンピュータ関連ツールにおいて，どの程度「モデリングツール」を使用している人がいるのかが気になり，その判断指標の１つとして Eclipse のダウンロードパッケージのダウンロード数比率を比べてみました．

ダウンロード数は以下のサイトから確認できます：
https://www.eclipse.org/downloads/packages/

2018-8-10時点での，Eclipse Photonベースのダウンロード数を比率をまとめたものが以下の表になります．

順位	パッケージ	DL数	割合	累積
1	Eclipse IDE for Java EE Developers	396851	47.8%	47.8%
2	Eclipse IDE for Java Developers	216948	26.1%	73.9%
3	Eclipse IDE for C/C++ Developers	72894	8.8%	82.7%
4	Eclipse IDE for Eclipse Committers	59813	7.2%	89.9%
5	Eclipse IDE for PHP Developers	27667	3.3%	93.2%
6	Eclipse IDE for Java and DSL Developers	24023	2.9%	96.1%
7	Eclipse IDE for JavaScript and Web Developers	12227	1.5%	97.6%
8	Eclipse IDE for RCP and RAP Developers	4625	0.6%	98.1%
9	Eclipse Modeling Tools	4060	0.5%	98.6%
10	Eclipse IDE for Java and Report Developers	3488	0.4%	99.0%
11	Eclipse IDE for Scientific Computing	2673	0.3%	99.3%
12	Eclipse IDE for Testers	2057	0.2%	99.6%
13	Eclipse IDE for Rust Developers (includes Incubating components)	1861	0.2%	99.8%
14	Eclipse IDE for Scout Developers	1486	0.2%	100.0%

Eclipse というツールの成り立ちやよく使われるドメインに依存した特性はあると思うので，この結果のみで何かしら結論を出すというのは乱暴すぎますが，やはり Java や C/C++ の様なプログラミング言語の環境としての利用者が多く，上位の3パッケージだけで8割以上を占めています．その他のPHPやJavaScriptまでも含めると9割程度がプログラミング言語の環境利用者で，モデリングツール自体は全体の 0.5% でダウンロード数順位も 14パッケージ中 9位 と思ったよりも少ない印象です．

モデリングに取り組んでいる人も同じくらいの割合なのでしょうか．

少し残念な気がします・・・

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

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

ダイアグラムのファイル出力

Papyrus で作成したUML/SysML等のモデル図からドキュメントを生成したいことが多々あります．

ダイアグラムそのものを画像として抽出するには，個々のダイアグラム上でマウス右クリックを行い，

File → Save As Image File ...

の操作をすることで図を画像保存することが可能です．

その際に選択可能な画像形式には，

GIF，BMP，JPG，SVG，PNG，PDF

があります．表示されるダイアグラム上の Image Format リストから選択することが可能です．

どれが良いかは難しいですが，自分としては「PNG」を使うことが多いです．次点としては「PDF」と「SVG」になるのですが，

• PDFはクラスにグラデーションのかかった色を付けている場合に，そのグラデーションが正しく出力されない場合がある
• SVGは少し前までのMS-Wordでは画像として直接取り込めない（Word側の問題）

という問題があるため無難な「PNG」を使うことが多いです．

png で保存

pdf で保存（pdfで保存したファイルをacrobat reader で表示しスナップショットを取得）

svg で保存（svgで保存したファイルを google chrome で表示し画面ダンプをpngで保存）

ただ，上記問題が影響がない場合にはPDFとSVGを使用しますし，特にベクタグラフィックスとして図をハンドリングしたい時はそちらを使います．

その他のダイアグラム出力のやり方としては，Project Explorer 上のモデルファイルを選択し，マウス右クリックで

Export All Diagrams ...

を選択するやり方もあります．

Export All Diagrams メニュー

Export All Diagrams ダイアログ

これによりモデル中に含まれるすべてのダイアグラムがファイル出力されます．
選択可能な画像フォーマットは上記のものです．

ただ少なくとも Papyrus 3.x の時には，ダイアグラム名を日本語にしていた場合にファイル名が文字化けしていました．Papyrus 4.0 ではどうなっているかについては確認していません．

Eclipse Papyrus 4.0.0 (Photon) Released

Eclipse Photon ベースの Papyrus 4.0.0 がリリースされました．
通常の Plugin 版と共に RCP 版も同時リリースされています．

スプラッシュ画面 には Photon と表示されています．

まだちゃんと確認していませんがPapyrus 4.0.0 の変更点は以下とのことです（参照元）：

• A new preference has been introduced to keep stereotype application with their base element see StereotypeApplication Preference
• The hyperlink navigation has changed see Hyperlink Navigation
• Add a preference page to configure the visualisation of  external decorator  see External Decorator
• Add auto-completion to select the type in the property view see  Auto complete type
• Add an export to HTML to see model without papyrus see HTML Export
• Development and adaptation of the Layer tool for the diagrams Layers .
• Synchronisation with ELK see ELK adaptation
• Tables improvements:
  • display of a string instead of N/A
  • Matrix improvements
  • save by UUID not the positon
• Diagrams improvements:
  • some problems about the name label of ports have been fixed
  • some resize action in the class diagram have been fixed.
  • sequence diagram - Better movement  managment of Elements, introduction of combined fragment, RCPTT tests.
•  Integrate a  tool to adapt your model based on the modification of the profile
• Architecture framework : stabilization (easier customizations/modifications by the users) and bug corrections

なおこの4.0.0から正式に Papyrus Component が Marketplace 対応したのですが，残念ながら Help メニュー上には Marketplace はありませんでした．

Papyrus4.0.0のダウンロードページには以下の記載があります：

From Papyrus 3.3.0 onwards, the Papyrus Relatives will be released in the Eclipse Marketplace as soon as they are available.

SysMLや Software Designer のようなコンポーネントのインストール手段としては，Marketplace メニューからではなく，別の手段を想定しているのやもしれませんね．
また探してみてみます．

なお適用された細かなパッチリストは以下で確認できます．
https://projects.eclipse.org/projects/modeling.mdt.papyrus/releases/4.0.0/bugs

もし現バージョンで気になる点があれば，4.0.0で改修済かどうか確認されるとよいかもしれません．

EclipseCon France 2018

Eclipse の年次コンファレンスである EclipseCon France 2018 が今日 6月13日 から開催されます。

Papyrus に関係するセッションとしては二日目の6月14日に以下の２つがあります：

• Papyrus as a Platform
• Meet Polarsys Time4Sys : timing verification now available to everyone!

Papyrus そのもののセッションでは Domain-Specific となる Modeling tool であることをクローズアップし、紹介されるみたいです（Experience level が Beginner となってますので紹介なのかなと思っています）。

Time4Sys は MARTE が目的とする Real-Time Embedded System のタイミング解析等を行うためのフレームワークです。

Time4Sys のサイトにある図がその位置づけを端的に示していると思います：

PolarSys Time4Sys is a timing performance framework that fills the semantic gaps between the design models of real-time systems and the models of timing verification tools.

Time4Sys proposes four capabilities: modeling and viewing the Time4sys model, A dedicated meta-model based on the MARTE standard, model transformations able to transform and adapt Time4sys model for verifications tool and connectors to import/export models from design tools and verifications tools.

Time4Sysのプラグインは GItHub 上で公開されています：

Time4Sys (GitHub)

最新のバージョンは、この 6月8日 に公開された 0.8.0 のようです。