システムとモデリング

SysML, Matlab/Simulink,他モデリング全般について。たまにプロジェクトマネジメント。

『Dropbox Paper』が計画書の作成に便利かもしれない

前回の更新から大分間が空いてしまいました。仕事が忙しくなりブログ更新のための時間が取り辛くなっています。

さて、今回は各所で既に話題にはなっていますが昨年から始まったDropboxの新サービス『Dropbox Paper』を紹介したいと思います。

www.dropbox.com

個人的にはこのサービスはプロジェクト計画の大変向いていると感じました。

 

Dropbox paperの優れている要素

1.Markdownで記述できる

 今までありそうでなかったものですが、この手のノートアプリには珍しくMarkdown方式のキーボードショートカットに対応しており、すばやく文字の装飾や表の作成を行うことができます。

2.docxでエクスポートできる

 MSのwordで読み込める形式でエクスポートすることができますのでこのサービスを利用していない人との共有も簡単にできます。ただしエクスポートは完璧ではなく反映されない部分も散見されます。

3.タスクの設定が可能

 文書内でタスクの設定が可能で、内容・期日・担当者をチェックボックス形式で表現することができます。

 

これらの特徴はプロジェクト計画書で欲しい要素『頻繁に更新するので記述に手軽さが必要』『広範囲の相手と共有する必要がある』『文書数は増やしたくなく、一つの文書にWBS他多くの要素を含みたい』を叶えることができますのでプロジェクト管理に大変有用と感じました。

 

しばらくこのサービスを利用してみて、また感想を公開したいと思います。

短いですが本日はここまでです。

 

 

ModelioでSysMLパッケージ図を書く

今回は前記事との比較のためModelioでSysMLのパッケージ図を書いてみます。

otepipi.hatenablog.com

Modelioとは

Modelioはオープンソースモデリングソフトウェアで、UMLやBPMN、SysMLに対応しています。

www.modelio.org

過去に一度試してみたことがあったのですがその際は重い動作が気になって断念してしまいました。

otepipi.hatenablog.com

今回は再チャレンジとなります。

 

例題

例題は前回同様下記パッケージ図です。

f:id:Otepipi:20180514195854p:plain

実践

f:id:Otepipi:20180515194708p:plain

Modelioをインストールすると上の画面が立ち上がります。

f:id:Otepipi:20180515194754p:plain

Creat a projectでプロジェクトを作成します。名前は任意に決定できます。

 

f:id:Otepipi:20180515194851p:plain

上が作業画面になります。前回の記事で紹介したEnterprise Architectは最近のMicrosoft officeのようなリボンを使用したインターフェースでしたが、Modelioは昔風のインターフェースです。

f:id:Otepipi:20180515194953p:plain

SysMLのモデリングをするにはSysMLモジュールをデプロイする必要があります。ConfigurationメニューのWork ModelsからModuleタブを開き、[Add]をクリックしてモジュールの選択画面を開き、「SysMLArchitect」を選択し[Deploy in the project]をクリックします。

f:id:Otepipi:20180515195108p:plain

Deployに成功した場合、上のようにModuleタブにSysML Architectが追加されます。

f:id:Otepipi:20180515205550p:plain

 作業画面に戻ります。

f:id:Otepipi:20180515210044p:plain

ここから例題の通りパッケージダイアグラムを作成していきます。まず第一階層のパッケージを作成していきます。操作感はEnterprise Architectとほぼ同じでしたが、動きはModelioのほうがモッサリしていました。

f:id:Otepipi:20180515210714p:plain

次に[Behavior]パッケージの中に含まれる[Manufacturing Use Cases], [Launch Use Cases], [Operations Use Cases]の3つのパッケージを作成します。ウィンドウ左側のツリーから[Behavior]を選択し、右クリックして新たにパッケージダイアグラムを作成し、3つのパッケージを作りました。

f:id:Otepipi:20180515210628p:plain

ただ、一番上の階層に戻ったところ[Behavior]パッケージの中に3つのパッケージが含まれていることが図に反映されていませんでした。Enterprise Architectでは反映されていました。

f:id:Otepipi:20180515211109p:plain

次に[Domain]パッケージが[Actors]と[Structure]を含んでいることをラインで示します。これは問題なくできました。ただし、「Domain::Actors]といった表現方法のやり方はわからなかったので、[Domain]と[Actors]の関係もラインで示すことにしました。

f:id:Otepipi:20180515211539p:plain

 結局第一階層のパッケージ図ではわかりませんが、[Structure]パッケージの中に6つのパッケージを作成し、作図は終了しました。

Enterprise Architectと比べて……

・動きがかなりモッサリしてストレスが貯まります。

・一部のSysMLダイアグラムに対応していません。(これは致命的

・機能がかなり少ない(エクスポート拡張子や図の表現方法など)

 

まぁフリーだから仕方がないとは思います。選択肢の一つであることは確かだと思います。

 

 

 

 

Enterprise ArchitectでSysMLパッケージ図を書く

今回はEnterprise Architectの体験版でSysMLのパッケージ図を書いてみます。

題材は下記SysMLの教科書からです。

 

SysML Distilled: A Brief Guide to the Systems Modeling Language

SysML Distilled: A Brief Guide to the Systems Modeling Language

 

 

f:id:Otepipi:20180514195854p:plain

 全部で17のパッケージが存在しています。パッケージはフォルダの形で表現されているのはそれっぽいですね。図を見てわかるようにパッケージはパッケージを含むことができます。まさにフォルダの階層構造ですね。○の中に+が描かれた線はパッケージとパッケージの包含関係を示します。この場合、StructureパッケージはDomainパッケージに含まれています。またDomain::Actorsも、ActorsがDomainに含まれることを表しています。これもフォルダのディレクトリの表現方法に似ていますね。

 他、矢印のついた点線は依存関係を示します。例えばTest CaseとRequirementsの関係ですが、Requirementsが変化した場合Test Caseも変化する可能性があることを示しています。その逆はありません。

 この図をEnterprise Architectで書いてみます。どうもSysMLとかシステムズエンジニアリング関係の題材は航空宇宙系が多いですねぇ……

f:id:Otepipi:20180514200218p:plain

とりあえずEAを起動します。

こんな感じのウィンドウです。日本語版をインストールしたつもりが英語verでした。設定で変更できそうですが面倒なのでこのまま作成していきます。

f:id:Otepipi:20180514200339p:plain

操作方法など日本語のドキュメントは下記サイトにあります。

Enterprise Architect ドキュメント ライブラリ

 

途中スクリーンショットを忘れてしまったので中途半端なところからスタートです。もう半分ぐらいできていますね。

f:id:Otepipi:20180514200800p:plain

この状態から新たにパッケージValue Typesを追加してみます。
New Packageからダイアログを起動してパッケージ名を入力します。

f:id:Otepipi:20180514200934p:plain

パッケージが追加され、さらに詳細入力画面が自動で立ち上がるのでキーワード model Libraryを入力します。

 

f:id:Otepipi:20180514201041p:plain

次にDomainとActorの包含関係を表します。例題ではActorはドメインに含まれています。Domainパッケージを右クリックして、Domainに新たにパッケージ図を追加します。

f:id:Otepipi:20180514201253p:plain

新たにDomainタブが立ち上がりました。まだ何も中に入れていないので白紙の状態です。

f:id:Otepipi:20180514201448p:plain

ここにActorsパッケージを作成してみます。

f:id:Otepipi:20180514201415p:plain

もともとのタブに戻ります。ActorsがDomainパッケージの中に作成されているのが確認できました。ただ、「Domain::Actors」という表現にはなっていません。どこか設定変更で変えられる可能性はありますが、今回は見つけられませんでした。

f:id:Otepipi:20180514201533p:plain

Domainの時と同様にStructureパッケージの中に6つのパッケージを作成します。

f:id:Otepipi:20180514202011p:plain

最後にコネクタをつけて仕上げになります。図のタイトルフレームを付けたかったのですがドキュメントをざっと見た限り項目が見当たらず、今回は諦めました。しかし機能としては存在していることは確かなので、おいおい探していきたいと思います。

f:id:Otepipi:20180514204245p:plain

総評として、やはりやや重いかなと感じる場面がありました。具体的にはパッケージを作ってから詳細入力ウィンドウが立ち上がるまでに1秒程度ラグを感じますので、そこが若干の不満点です。詳細ウィンドウが自動で立ち上がらないように設定すれば問題ないと思います。また今回はultimate版を使ったのですが大変機能が多くリボンの項目が多くて何をどうしたら良いのか迷ってしまう部分が多くありました。

ただDraw.ioと比べるとやはり専用ソフトだけあってかなり作成時間が短くなったように思います。またDraw.ioで書いた場合はただの絵ですがEnterprise Architectで書いたものはちゃんと動作するモデルになるので、その点も大きな違いですね。またエクスポートもPDFで問題なくできたのは嬉しいです。

 

今日はここまでにしておきます。これからもちょくちょくモデリングを進めていきたいですね!

 

『システムエンジニアリング』を取り巻く問題

注)この記事は下記『System Engineering Analysis, Design, and Development: Concepts, Principles, and Practices』の第2章[The Evolving State of SE Practice- Challenges and Opportunities]の要約になります。

 

前提

・企業のエンジニアの業務の50~75%は多分野に渡る意思決定や問題解決を行うシステムエンジニアリング的業務である。
・にもかかわらず、エンジニアの殆どは『システムエンジニアリング』について正式な教育を受けたことがない。経験から学ぶのみで大変非効率的である。

f:id:Otepipi:20180512231611p:plain

 

どうしてこのような状況になったのか?

・大学・大学院では個別分野の知識を深める一方、複数の領域に跨った問題を解決する技法を学ばない。

f:id:Otepipi:20180512230513p:plain

・これは博士号取得者が大学院を卒業してそのまま大学で教鞭を取るケースが多いため、企業で上記のような経験をする機会に恵まれなかったからである。

・また多くの企業では誤った『システムエンジニアリング』の認識を持っているため改善が進まない。

 

誤った『システムエンジニアリング』とは?

・問題に対して要件分析や解空間の検討をほとんど行わないままたったひとつの設計案を設計し、テストし、修正することを繰り返すパラダイム。本書ではSDBTF-DPM Engineeringと称されている。

・この方法ではプロジェクトのスケジュールが限界に達するか、予算が足りなくなるまでテスト→修正→テスト……のループを繰り返すことになる。

f:id:Otepipi:20180512231403p:plain

・この方法は手戻りが多く非常に非効率的である。設計案を固める前に要件分析や解空間を実施することで手戻りの少なくなるようにプロジェクトを進めていくのが真の『システムエンジニアリング』である。

 

 

感想

 本書に書かれているのはアメリカの話ですが日本はもっと酷い状況だと思われます。まず現代的な『システムエンジニアリング』について書かれた和書がほぼ存在しません。たまに「システム工学」という名前がついた本が散見されますが基本的にどれも『システムエンジニアリング』とは全く違う内容です。むしろ「プロジェクト・マネジメント」関連の本が『システムエンジニアリング』に近い内容と言っても良いと思います。

 日本の製造業が最近イマイチ活躍できていないのはこの『システムエンジニアリング』に対する理解の不足が原因の一つと感じています。知識の習得には洋書の読解が必須になりますが喰らいついていきたいところですね!

 

モデリングツール"Enterprise Architect"の購入検討

モデリングツールのEnterprise Architectの購入を検討しています。

www.sparxsystems.jp

過去の経緯

過去にも有料のモデリングツールを各種検討したことがありました。結局有料のものは高価だったのでフリーのもの(Modelio、Papyrus)を試しましたが、全体的に重くて使用を断念してしまった経緯があります。

otepipi.hatenablog.com

 

なぜ今回有料のEnterprise Architectを検討するのか

5月16日にEnterprise Architectの最新バージョン14.0がリリースされます。

Enterprise Architect 14.0の新機能のご紹介

これまでEnterprise ArchitectのSysML対応エディションはシステムエンジニアリング版で、これが1ライセンス7万9千円もしました。なので全く手が出なかったのですが、今回のバージョン14.0からはコーポレート版もSysML対応となり、このコーポレート版は1ライセンスあたり4万円となり、高価なことは高価ですが手が出ないことは無いというレベルにまで値下がりしました。

体験版を軽く触ってみましたが思ったよりサクサク動作してなかなか快適でした。

しかしコーポレート版は個人で使うにはハイスペックすぎるのが難点。やはりフリーで十分となってしまうかもしれません。

今後どうしていくか

 とりあえず体験版を使って何かモデリングしてみたいと思います。

【雑記】Googleトレンドで遊ぶ SysMLなど、多く検索している地域はどこか

昨日の記事で使用したGoogleトレンドで遊んでみます。Googleトレンドには『小区域別のインタレスト』という、検索語がどの地域でよく検索されているか調べる機能がありますので、それを使ってみたいと思います。

 

"SysML"は愛知県で最もよく検索されているようです。愛知県といえば自動車のトヨタデンソーが思い浮かびます。おそらく車体の制御システムの設計に使用されていると思われます。

 

"Modelica"は東京で最も検索されています。Modelicaといえばそれこそ自動車業界で使われているものですので愛知県が多くなると思いきや、東京都言うのが意外ですね。ソフトウェアベンダーが東京にあるからなのでしょうか?

 

"Simulink"は1位が栃木、2位が愛知、3位は静岡となっております。Simulinkも自動車のモデルベースデザインに使用されているソフトウェアであることを考えると、栃木はホンダでしょうか?愛知はトヨタとして、静岡はヤマハかもしれませんね。

 

最後に"トヨタ"、"ホンダ"が最も検索されているのはそれぞれ愛知県と栃木県でした。やはりお膝元なんですね。

 

 

【雑記】SysMLとSysML

久々の更新でしかも短いですがご容赦ください。

当ブログ "システムとモデリング" ではシステムのモデリングにシステムモデリング言語SysMLをよく利用しています。ただこのモデリング言語自体は認知度はとても低い状態にあります。Googleトレンドで見てみると派生元のUMLに人気度で圧倒的に負けています。

 

 

ちなみに同じくモデリング言語のBPMNとは比較的良い勝負をしています。

 

 

こんな不人気なSysMLですが、最近Twitter界隈で"SysML"という単語をちらほら見かけるようになりました。

f:id:Otepipi:20180501222150p:plain

なぜSysMLツイートが増えたかといいますと、どうやらここで呟かれている一部の"SysML"はシステムモデリング言語ではなく"Systems and Machine Learning"の略のようです。最近SysML Conferenceという機械学習関係のカンファレンスが開催されたこともありSysMLが頻繁に使用されているようです。

SysML Conference

 

とりあえずシステムモデリング言語のSysMLはまだマイナーなようですね!

今日はここまでです。