Translate

2020/06/11

UML+SysML としての使い方(1)

前回の記事「SysML 1.6 でのモデリング」ではSysMLプロジェクトを作成する方法を簡単に説明しましたが、SysMLプロジェクト単独では「UML + SysMLとなるモデル化を行いたい」という場合には(多分)うまく扱えないと思います。

「UML + SysMLとなるモデル化」とは、UMLとSysMLの関係を示す下記のFigure 4-1 (SysML仕様書から抜粋)において、両集合の和となるようなUMLとSysMLの要素をシームレスに扱いたいという場合です。


Figure 4-1: Overview of SysML/UML Interrelationship
前のやり方ではSysMLプロジェクトとして作成されるためUMLのダイアグラムを扱うことが出来ず、関連するUMLモデルを別モデルファイルとして作成し、そのモデルをImportすることで関連付けを行い、UMLモデル側でダイアグラムを扱うならばUMLとして扱えます。
また逆に、システムエンジニアリング→ソフトウェアエンジニアリングとして進める場合で考えるとUMLモデル側にSysMLモデルをImportして使うとして同様に進めれば「UML+SysML」は扱えます。
ただ、別モデルファイルであるため扱いづらいですし、Papyrus上でモデル切り替えを行う際に操作系としてのタイムラグが発生するので切り替え頻度が高い場合はフラストレーションもたまります。

なお、自分が「UML+SysML」として扱いたいケースは、

  • SysMLでシステム設計を行った後の設計対象がソフトウェアであるため、その先の関係者が扱う「通常のUML」にシームレスに繋げて、UMLとして機能内容等をブレークダウンしていきたい。
  • (同じく主体がソフトウェアであるため)UMLを主として、そこにSysMLの「Stakeholder、View、Viewpoint」や「Requirement」のみを上位側の概念として使いたい。

です。特に後者の方が多いです。

昔のPapyrusでは、「UML+SysML」としての混在が楽だったのですが、現在の「Architecture Context」を明示的に指定する方法(最初にモデルを作る時に Software Engineering か System Engineering かを選択)になってからは対応しづらくなりました。

もちろん、現在の方が利点も多いですし、そもそも別れている世界だと考えると問題はありませんし、SysML側で再定義されたモデル要素をUML/SysMLのどちらの意味で扱うのか等の問題も存在していますが、それでも「UML+SysML」として使いたいケースも多いです。

今回はそのやり方について紹介したいと思います。

なお今回のやり方は「UMLをベースとしてモデルやダイアグラムを扱い、そこに一部のSysML要素を使いたい」の例となります。


まず、UMLのプロジェクト/モデルを作成します。

作成したモデルの最上位を Model Explorer 上で選択し、PropertiesタブのProfileを開きます。


このProfileパネルの右上にある「Apply registered profile」と表示されるボタンである

をクリックします。

すると「Apply profiles from Papyrus repository」となるダイアログが上がってくるので、そこで
SysML 1.6
を選択して[OK]を押します。


すると
Choose profile(s) to apply
というダイアログが上がってきます。ここで任意のプロファイルを選択します。自分は全てを選択して使っています。


これでUMLモデル上で SysML プロファイルを扱うことが出来るようになりました。


それではUMLモデル上でSysMLの「Stakeholder」を使用してみたいと思います。

まず「Actor」を作成します。

Actorを直接的に扱えるダイアグラムは「UseCase」のためユースケース図で作成してみます。

自分は ModelExplorer 上で直接モデルを作成することが多いですが、Actorの線画アイコンがそのまま表示されるユースケース図を使って進めようと思います。


通常のモデル作成操作(NodesからActorを選択して作成)を行います。

これで名前が「StakeholderA」となるUMLのActorが作成されました。

ここでActorのProfileパネルを開きます(Propertiesタブ→Profile)。


Applied stereotypesで前と同じく [+] ボタンをクリックします。


左側の「Applicable Stereotypes」上に
Stakeholder
が現れるので、ダイアログ中央の[⇒]ボタンを使って、右側に移動します。


これで[OK]を押すと、Actorに「SysMLのStakeholderステレオタイプ」が適用され、ユースケース図上ではステレオタイプ名となる <<Stakeholder>> が適用されます。

また Profileパネルの Applied stereotypes の所で、Stakeholder ステレオタイプが持つプロパティである
concern
のプロパティが扱えるようになったことが分かります。


「Stakeholder」を作成したので「関心事」(concern)を規定して行きたいと思います。

上記図から見て取れる様に「concernList」としてCommentを複数登録可能です。

concernListをマウスで選択し、ここでも同じく右上の[+]ボタンをクリックします。

するとconcernListに関するダイアログが表示されます。


既にCommentとして作成されている concern があれば、それを左側で選択し右側に[⇒]で移動すれば選択出来ますが、まだ存在(作成)していない場合には、ダイアログ右端中央にある[+]ボタンをクリックします。

すると「Create a new Comment」というダイアログが上がってきます。


まず、Comment要素を保持する Container を指定する所から始めます。

Container: の所にある […] ボタンをクリックします。

すると作成するCommentを持つモデル要素を選択出来るので、適切なコンテナを指定します。

ここでは作成した「StakeholderA」をコンテナとして指定して進めます。


[OK]ボタンを押すと以下のダイアログの様に選択されるので [OK] ボタンを押します。


この後、通常の Comment 作成用のダイアログが上がってくるのですが、そこでの入力操作については割愛します(キャプチャし忘れました…)。

今回は、そのコメント内容(body)を
「継続してサービスが提供出来る仕組みか」
として作成しました(内容は雰囲気で適当に書きました)。


これでOKを押します。

これにより基本的には

  • Stakeholderステレオタイプが作成され、
  • そのStakeholderの関心事がモデルとして規定された

となるのですが、残念ながらダイアグラム上での見た目は変わりません。



ダイアグラム上で表示として見せるためには、もう少しだけ手間が必要です。

StakeholderAのPropertiesタブのAppearanceパネルを開きます。


その中央ぐらいにある
Stereotype display
の表で諸々の指定を行うことで表示をコントロールできます。

この表のStakeholder行とIn Comment列が交差するセルのチェックボックをチェックすると、


と無事に関心事がStakeholderにリンクされたコメントとして表示されました。

このモデルはUMLベースであるため、画面のダイアグラム操作系からも見て取れるように、他の関係するモデルとして通常のUMLが扱えます。

このようにしてUML上でSysML要素を扱うことが可能です。

なお、幾つか追加で説明しておきたい話や注意点がありますので、それについては次の記事に書こうかと思います。

2020/06/10

SysML 1.6 でのモデリング

最近、ブログを訪れる方で SysML に関するページを見られている方が増えています。

検索サイトから来訪される方でも SysML をキーワードとして検索され、このブログにたどり着かれている方も多い様に思えます。

前に書いた記事「SysML 1.6 プロファイルのリリース」ではSysML 1.6 Profile の簡単な紹介をしていますが、SysMLで実際にモデルを書いてみたいという方に対して少し丁寧にご紹介したいと思います。特に Papyrus RCP 版を使用されておられる方だと
「どうやって SysML Profile を導入するの?」
という所から困る方もおられるかもしれません。過去の記事には色々と書いていますが、SysML 1.6 でのモデリングという観点でこの記事でまとめてみます。

SysML Profile の導入がわからない方

Papyrus RCP 版を使っておられる方からすると、そもそも SysML のプロファイルを導入する所から不明なことがあるかもしれません。

導入の仕方は幾つかあるのですが、今後も含め様々なプラグイン導入による利便性を向上させる手段として、
Marketplace
から導入する方法をご紹介したいと思います。

Marketplace とは、有償・無償を含めて Eclipse Project 下で直接開発しているプラグイン以外のプラグインをEclipseに導入可能とするプラグインです。Marketplace プラグインを導入すると「Help」からのドロップダウン上に
Eclipse Marketplace...
というメニューアイテムが現れます。


Papyrus RCP 版の初期状態では Eclipse Marketplace はメニュー上に存在しません。この Marketplace を導入するためには、まず、上記ドロップダウン上にある
Install New Software...
から始めます。

Install New Software を選択すると、
Install
という名前のダイアログが上がってくるので、そこで

  • Work with: で 2020-03 - http://download.eclipse.org/staging/2020-03/ を選択
  • type filter text と書かれている所に Market とでも入力

すると、以下の様に
Marketplace Client
が選択されるので、それをチェックし、Next> で進みインストールを行います。


その後、再起動が促され、再起動後にHelp メニューから Marketplace が選択可能となります。

Eclipse Marketplace からの SysML プロファイルの導入

Marketplace を開くと各種プラグインを検索出来るダイアログが上がってくるので、ここで
Find
の所に
papyrus

と入力し、[Go]ボタンを押すと、Papyrus に関連する様々な導入可能プラグインが表示されます。


これで SysML プロファイル(SysML の Papyrus 向けプラグイン)である
Papyrus SysML 1.6 1.0.0
を見つけることが出来ます。

そして「Papyrus SysML 1.6 1.0.0」にある [Install] ボタンを押すとプロファイルがインストールされます。

なお上記のダイアログ表示では、現在使用中の環境では既にインストール済であるため [Installed] と表示されています。

これで SysML モデルの作成が可能となります。

SysML モデルの作成

SysML プロファイル(Papyrus 向けプラグイン)を導入すると、これまでの Papyrus プロジェクト/ Papyrus モデルの作成ダイアログにおいて

  • Systems Engineering
    • SysML 1.6

が選択可能となります。


SysML 1.6 をチェックしてモデルプロジェクト/モデルファイルを作成すると、Papyrus 上で SysMLのダイアグラムやモデル化要素を用いたモデル化が可能となります。

SysML 1.6 モデルでのツール操作系(俯瞰)

Papyrus のメニュー等における操作系がざっとどのようになっているかを紹介しておこうと思います。

自分は Model Explorer の所からダイアグラム作成やモデル作成を行うことが多いので、Model Explorer 上のマウス右クリックで表示されるメニューを紹介します。

まずモデル化要素の選択としては、

  • SysML 1.6 Child
  • UML for SysML 1.6

の2つに別れて表示されます。前者は SysML で新たに導入された要素(ステレオタイプ)、後者は SysML仕様書上で「UML4SysML」と称されている UML から SysML に直接導入された要素となります。

まず SysML 1.6 Child はいわゆる「Node」ですが、以下の要素が選択可能です。SysMLとして良く目にする要素が並んでいます。


SysML 1.6 Relationship はいわゆる「Edge」ですが、以下の要素が選択可能です。



UML for SysML 1.6 では以下の要素が表示されます。どのような要素が「UML4SysML」として使用可能であるかは SysML仕様書で説明されています。

UML for SysML 1.6 (Node です)


UML for SysML 1.6 Edges (Edgeです)


また、SysML に特化したダイアグラムは、
New Diagram
のメニューから表示されます。これも SysML でよく見るダイアグラムが並んでいます。


また
New Table
のメニューから SysML でモデル化を行う際に有用な「表」が作成可能です。SysMLの仕様書を見ると表形式も積極的に推奨されているような印象を受けます。


ざっと、そのような感じです。

UML自体をその記述のベース言語とする一般的なUMLプロファイルよりは、専用モデリング言語として特化した操作系として各種モデル作成が行えるようになっています。

SysML 向け Papyrus となる細かな使い方やTips、また和集合として 「SysML OR UML」 となる使い方については、またご紹介出来ればと思っています。


2020/06/05

モデルファイル中にある全てのダイアグラムのファイル出力

モデルファイル中にある全ての図をファイル出力したい場合があります。

自分は RCP版Papyrus に TeXLipse プラグインを導入していまして、Papyrusで作成したモデル図を LaTeX のソースから includegraphics して使うことが多いです。

その際、モデルファイル中の図の一括出力機能を使っています。モデル側で修正があった場合に修正したモデルが関係するダイアグラム全ての表示がすべて変更されるため、ドキュメント側でも図全体の整合を取ることが出来ます。

図の一括出力の具体的なやり方ですが、まず、あるプロジェクト中にAという名称のモデルファイルがあるとし、その中のモデル階層がダイアグラムも含めて以下の図の様になっているとします。


ここで図(Diagram)の置かれている階層ですが、
  • ルートの Model "A" の直下に ClassDiagram1 と ComponentDiagram1 があり、
  • ルートA下のパッケージ "X" に ClassDiagram2 と useCaseDiagram1 があり、
  • パッケージ X 下のパッケージ "Y" に CompositeStructureDiagram1 がある

となっています。

プロジェクトエクスプローラ上のモデルファイルAを選択しマウス右クリックで表示されるメニュー最下部の「Export All Diagrams..」を選択します。


選択すると以下の「Export All Diagrams」というダイアログが上がってくるので、ここで、
  • Select the output format: で所望する形式に変更(自分はPDFが多いです)
  • Prefix with qualified name をチェック

します。


これで[OK]を押すとダイアグラムファイルの生成・出力処理が実行され、終了すると以下のダイアログが表示されます。


これでプロジェクトエクスプローラ上でPDFファイルが生成されていることが分かります。

ファイル名は Papyrus が自動的につけますが、

上位のパッケージ種別_パッケージ名_ダイアグラム名

となっているみたいです。

実際、各ダイアグラムのPropertiesを見てみると、



となっており、この「Root element」もしくは「Owner」の「モデル種別名」と「モデル名」を用いた名前となっている模様です。

注意しないといけないのは

「複数のモデルファイルが存在し、そこから図をExportする場合に名前の競合が起こらないように」

することです。

今は生成されるファイル名が重ならないことを確認してからExportしているので問題に遭遇していませんが、競合が起こりうる話しなので注意が必要かと思います。

なお「パッケージAの下にパッケージBがあり、その下にまたパッケージAがあって」の場合で「階層は違うパッケージAの下に同じダイアグラム名があった場合」とかですかね。
試してはいませんが、気になる所です。。。

なお「ダイアグラム名を日本語にしていた場合」は「図出力がなされません」。無視されます。

こちらの方が要注意点ですね笑

そのため、自分は「ダイアグラム名に日本語は使わない」という運用をしています。

2020/06/04

クラスのプロパティ表示から関連表示への変換

Tipsです。

クラスをモデル化する際、ユーザ定義クラスを型とするプロパティを属性区画に追加した後で、関連(Association)として表示したい事があります。

例えば
というクラスがあった場合に、この parts メンバ要素をXクラスとの関連として表示させたい場合です。クラス図上で、ClassXクラスの各種要素と共にXクラスの詳細も表示することで、両者が関係するある特徴を明示したクラス図として表記したい時などです。

この時のModel Explorerの表示は


となっています。
通常、各種関連も Model Explorer 上で表記されているのですが、ClassAクラスに直接 parts プロパティを追加したため、関連を示すモデルが存在しません。

では関連としてのモデル要素をEdgeパネルから作らないといけないかというと、そういう訳ではありません。その関連を自動生成するやり方があります。

まず、クラス図上で対象のプロパティ(parts)を選択し、マウス右クリックから

Utils > Create Association From Property

を選択します。


これを実行すると、何の変化も起こらない様に見えますが、Model Explorer を見ると、ClassAクラスとXクラスの間のpartsに関する関連が生成されています。


一番下の「A_parts_classA」です。

これをクラス図上で Drag&Drop することで、関連が表示されます。


後はXクラスの表示内容を変更したり、関連(A_parts_classA)の見せ方を変更することで、所望の意図を持つクラス図に修正することが可能です。

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

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

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

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

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

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

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

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

プロジェクトの作成

上で説明した様な運用をする場合、分割する粒度を「プロジェクト」とするか「モデルファイル」とするかが、まずはの分岐点となります。
どちらでも大きな問題は発生しませんが、それよりも自身が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 なのでしょうかね??)