astahによるUMLモデリング

2020/02/22

PlantUMLでAWSのインフラ構成図を描くやり方

PlantUMLでAWSサービスを含む図が作れるらしい。
以下の内容を試してみる。

【参考】
PlantUMLでAWSサービスを含む図を作る | 秋元@サイボウズラボ・プログラマー・ブログ

AWS Labs製のPlantUMLライブラリ『AWS Icons for PlantUML』の使い方 - Qiita

AWS 構成図を PlantUML で描画できる『AWS-PlantUML』の紹介 ? サーバーワークスエンジニアブログ

従来、インフラ構成図はシステム開発で重要な成果物なのに、非常に作りにくかった。

最悪なチームは、Excelでインフラ構成図を何とか書き切ろうとして、だいたい上手く描けていない。
Excelでああいう複雑なダイアグラムを描くには、Excelは機能が貧弱すぎる。
Excelで描いた図はどこかで何かが漏れているし、頻繁な変更に耐えきれず、すぐに古くなってしまう。

僕の経験では、Visioでインフラ構成図を書いているチームが一番まともだった。
Visioなら、複雑なダイアグラムもまだ描きやすい。
しかし、Visioはライセンスが高価なので、余裕のある会社や開発チームでしか使えなかった。

そういう問題点をずっと抱えている現場では、PlantUMLとAWSアイコンを使ってインフラ構成図を描く手法は試して見る価値がある。
PlantUMLはテキストベースなので、慣れればDSLっぽく書けるし、Gitでも構成管理がやりやすいので変更にも強い。
AWSアイコンが使えるならば、PlantUMLのインフラ構成図は一目で理解できるようになるだろう。
昨今ではAWSでシステム開発をするのが普通なので、こういうインフラ構成図を即座に書いて情報共有できるツールがあると非常に心強い。

PlantUMLについては過去にも色々考えていたが、インフラ構成図も描けるならば、非常に強力なツールだ。
この辺りもいろいろ考えてみる。

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索

| | コメント (0)

2020/02/21

astah* System Safetyのリンク

安全分析設計論証に特化したモデリングツールastah* System Safetyをリンクしておく。

astah* System Safety | 安全分析設計論証に対応したMBSEツール

以前から、SysML、GSN、STAMPなどの図を1個のモデリングツールで描けるといいな、と思っていたので、興味はある。
1つの事象、考えたいアイデアは、複数のモデルを描きながら、関連性や整合性を検証していくことで、本質を深堀りできるから。
この辺りのアイデアも蓄積していく。

| | コメント (0)

2019/10/24

第3回astah関西勉強会の感想 #astahkansai

昨夜行われた第3回astah関西勉強会の感想をメモ。講演者、スタッフ、参加者の皆さん、ありがとうございました。

【参考】第3回astah関西勉強会「もやもやを分解しよう」 - connpass

「モデリング事例紹介」10月23日に大阪で開催 ? 参加申し込み受付中! | astah in 5 min

PlantUML Example for モデルベース要件定義テクニック - Qiita

【1】ツイッターやastah blogぐらいしか流していないのに、狭い部屋に参加者が30人以上も来てくれました。懇親会でも、以前から勉強会の存在は検知していて、今回初めて参加できた、という人もいた。勉強会のターゲット層、議論するドメインは非常に狭いと思うのに、興味を持つ人が多くて正直嬉しかった。

僕は、astah関西コミュニティでは、プログラミングとモデリングの間をモデリングツールや事例紹介の観点で行ったり来たりする議論ができるといいな、と考えている。そういう思いに共感してくれる人たちが少なくとも存在する、と気づけたのはとても嬉しかった。

【2】以下、講演の内容で感じたことをメモしておく。

【2-1】@ogomorさんの講演PlantUML+RDRAの話は、以前から聞きたいと思っていた。過去に色々書いてきた。

PlantUML Example for モデルベース要件定義テクニックの記事のリンク: プログラマの思索

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー: プログラマの思索

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

RDRAについては、システム地図という考え方が重要と考えている。要件定義から論理モデルや実装モデルまで、要件をトレースする仕組みがシステム地図として実現されている。つまり、RDRAでは、トレーサビリティを重視した手法であると思っている。僕は、モデリングではトレーサビリティが重要と思っているので、RDRAの考え方は好きだ。

但し、RDRAでは、UMLを拡張した図を多用するので、astahなどのUMLモデリングツールでは、UMLの制約に引っかかって全ての絵を書くことができない弱点があった。そこで、PlantUMLを使うと、自由に描けるので、RDRAの技法を全て実現できる。しかも、テキストベースなので、設計書をMarkdownで書けば、プログラムから設計書まで全てGitで構成管理の配下に置ける。

akipiiさんはTwitterを使っています: 「#astahkansai RDRA はUMLを拡張してるので、astah などの普通のモデリングツールでは制約に引っかかって書きにくい時がある。plantuml なら自由に描けるので、RDRA の記法も問題ない。」 / Twitter

興味深い点は、PlantUMLのソースを見るだけで脳内にUMLモデルの絵がイメージできるし、逆に、UMLモデルの絵からPlantUMLソースをイメージできるようになる、ということ。
右脳と左脳で行ったり来たりしている点はすごいな、と思う。

akipiiさんはTwitterを使っています: 「Astahkansai 慣れてくると、plantuml のソースから、頭の中で絵をイメージできる一方で、UMLの絵からplantuml のソースが頭の中にイメージできる、と。なるほど、まさに右脳と左脳で行ったり来たりしてるわけだ」 / Twitter

講演では図書館モデルの事例紹介で、ユーザの要望をコンテキスト図で表す時に、アクターアイコンの吹き出しに要望を書くことで、あたかもユーザが声に出して要望を話しているように見える、という箇所は非常に興味深かった。また、VSCodeでPlantUMLをライブコーディングしながらUMLを書いていく説明も分かりやすかった。PlantUMLは奥が深そうなので、色々試してみたい、と思う。

【2-2】とくぢろうさんの講演ユースケースリファクタリングでは、ファウラーのリファクタリング本を元に、ユースケースのリファクタリングのカタログを作ってみよう、という話で、面白かった。

ユースケースの削除、抽象化、分割、共通化、などは、ソースのリファクタリングの手法と全く同じように考えられるので、理解しやすい。実際の場面でユースケースを使う利用シーンは少ないけれど、その考え方は要件定義に活かせると思う。

但し、リファクタリングはTDDと表裏一体なのに、ユースケースのリファクタリングはTDDがないので、その部分の弱みはある。他にも課題はあったが、思考は深められそう。

akipiiさんはTwitterを使っています: 「#astahkansai Cソースの依存関係をastah のユースケースで描くと、ユースケースの依存関係の機能を使えるので便利」 / Twitter

【2-3】高井さんの講演では、GSNを使って、組込みシステムのタスク実装の意図を残す事例。僕は、GSNはロジカルな手法なので、厳密に説明するもの、と思っていたが、事例紹介の話を聞くと、説明する人の立場で論理を組み立てるので、意外に緩やかに使える印象を持った。

僕は、GSNやフォルトツリー解析、STAMPなどの手法はどのような違いがあり、どのように使い分けられるのか、が分かっていないので、この辺りも考えてみたいと思う。

【2-4】細合さんの講演では、テストケースの組合せ爆発を、フィーチャーモデルを使って制約条件を表現し、astahを基盤とした開発ツールでテストケース生成を行った話。フィーチャーモデルはソフトウェアプロダクトラインにも出てくるが、実際の記法を見ていたら、原因結果グラフに似ているような印象を受けた。だとすれば、組合せたテストケースの精度は非常に高いだろうと推測する。

【3】2時間の勉強会にたくさんの講演を押し込んでしまったので、質疑応答の時間が取れなかったのは反省点だけど、熱心に聞き取る参加者を見て、開催できてよかった、と思った。とても小さなコミュニティだけど、今後も緩く長く続けられればいいな、と思っている。

| | コメント (0)

2019/09/21

第3回astah関西勉強会の見所「もやもやを分解しよう」 #astahkansai

第3回astah関西を1年ぶりに開催します。
興味のある方は、ふるってご参加ください。

【参考】
第3回astah関西勉強会「もやもやを分解しよう」 - connpass

(引用開始)
要件定義やシステム開発で袋小路に陥った時、何か「もやもや」していることはありませんか?
そこで、そんな「もやもや」をモデルに書き出して、どんどん分解して、もやもやの真因を突き止めていきましょう。

そんな時に役立つモデリング手法の実践事例を講演者から紹介して頂きます。 具体的には、下記になります。

・モデルベースの要件定義手法(RDRA)とPlantUMLを使った実践モデリング
・ユースケースのリファクタリング・テクニック
・設計やプロジェクトのゴールに関するモデリング技術:ゴール指向表現(GSN)
・フィーチャー図によるテストスィートのモデリング技術
(引用終了)

一番の見所は、@ogomrさんの「PlantUML Example for RDRA 2.0」 。
PlantUMLで要件定義や設計の作業をどれだけ書ききれるのか、に興味がある。

@ogomrさんの下記の記事はとても参考になる。
PlantUML Example for モデルベース要件定義テクニック - Qiita

UMLで全ての設計ができるわけではないだろうが、UMLを一部カスタマイズして、業務システムの要件定義やシステム設計に合わせるようなモデリング技法(RDRA)を組み合わせると、ほとんどの内容をモデルとして描くことができる。
さらに、PlantUMLでテキストベースにUMLモデルを書けば、設計モデルもソースも全てGitの構成管理の配下で管理させることができる。
そうすれば、自動デプロイすることで、最新の設計書とビルドモジュールがいつでもリリースできる流れになる。

このあたりのアイデアは以前色々考えていた。

PlantUML Example for モデルベース要件定義テクニックの記事のリンク: プログラマの思索

仕様書にもExcel脱却が求められている: プログラマの思索

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

PlantUMLが優秀な点は、UMLだけでなくER図も書けるし、画面インターフェイスの部品を使って画面設計書も書けたり、マインドマップやガントチャートまで対応している点だ。
つまり、設計資料以外にも、PJ管理資料まで全てテキストで管理できる可能性がある。

また、VSCodeを使えばPlantUMLを簡単にプレビューできるので、開発環境も揃っているのも良い。
もしかしたら、astahでモデルを描くよりも、VSCodeの方が馴染む人もいるかもしれない。

設計者が自分の意図を開発者に伝えたい時、シーケンス図を書くときが多いだろうが、その時に、PlantUMLで書いたシーケンス図を渡す利用シーンも考えられる。

特に、シーケンス図の修正はPlantUMLでテキストベースで書いている方が、仕様変更の対応にも強い。

そんなことを考えると、設計というモデリング技法は、モデリングツールの開発という観点も含めて、まだまだ発展途上の技術のような気がしている。
そういう内容も合わせて、色々議論できると楽しいと思っている。

| | コメント (0)

2019/05/16

GSNの利用事例のリンク

 

astahブログにGSNの利用事例が紹介されていたのでリンクしておく。

GSN広めよう活動奮闘記?三菱電機エンジニアリング株式会社様? | astah in 5 min

GSNは組込みシステムの機能安全の設計で使うツールと思っていたので、タスク管理に使う発想がなかった。
なるほど、変更要求からタスクまでのトレーサビリティを明示できる特徴を生かして、こういう使い方もできるのは面白いと思った。

 

 

 

 

| | コメント (0)

2019/03/31

システムエンジニアリングとしての SysMLの記事のリンク

青木淳さんが書かれたSysMLの記事が分かりやすかったのでリンクしておく。
ラフなメモ。

【参考】
「システムエンジニアリングで SysML を使いこなす」第1章 概要編-システムエンジニアリングとしての SysML | オブジェクトの広場

「システムエンジニアリングで SysML を使いこなす」第2章 実践編-電光掲示板を設計する(1) | オブジェクトの広場

「システムエンジニアリングで SysML を使いこなす」第2章 実践編-電光掲示板を設計する(2) | オブジェクトの広場

上記の記事を読んで面白いと思った点は2つある。
一つは、SysMLという共通言語が複数の専門家集団の意思疎通に重要な役割を果たすこと。

ソフトウェア組込製品でも、システムの大規模化・複雑化によって、開発作業はハードウェア技術者やソフトウェア技術者に細分化され専門化した。
結局、開発プロセスや開発組織そのものも局所最適化されてしまっている。

一方、市場要求や技術革新によって、どんどん製品や技術が陳腐化していくので、製品自体をその次代の技術に合わせて全体最適化する必要が出てくる。

しかし、今までの日本人が得意とする、すり合わせ技術だけでは、システムの複雑化や市場変化の速度に付いていけない。
そこで、モデルベースエンジニアリングのように、システムアーキテクチャを全体最適の観点で構築し直し、ハード・ソフトの専門家も一緒に開発していくスタイルへ変化せざるを得ない。
そういう場面で、ハード・ソフトの専門家同士で会話するための共通言語となるSysMLが必要となり、役立つのだ、というストーリーと理解した。

確かに、例えば、製品ドメインの専門家、熱力学や電気・ロボットなどの自然科学の専門家、そして、機械学習やクラウド等のソフトウェアの専門家のように、多数の専門家から成る集団で開発する場合、共通言語がなければ、価値ある製品を作ることは難しいだろう。
共通言語だけで解決できるわけではないが、必要条件の一つにはなりうる。

もう一つは、あらかじめ全ての顧客要求や製品の部品やアーキテクチャを決める必要はなく、未決定の要素をリスク管理の対象とみなして開発を進めて、必要な時に随時決定すれば良いこと。

製造業の製品開発ではどうしてもWF型開発になりやすいが、各工程の内部は実際はアジャイル開発っぽい雰囲気が出てくる。
原材料や部品の発注があるので納期厳守でWF型開発が王道だが、中身の開発は試行錯誤が普通。

昨今の開発では、要件を全て決めてから開発する、という流れの方が少ないだろう。
その時に、製品のアーキテクチャをSysMLで表現した時、どの部分の要件が未決定であるか、を明確に区別して管理することは重要になってくる。
その未決定の要件はリスク管理の対象として扱い、リスクが顕在化してきた時に、アーキテクチャを明確に固めていく。

そのプロセスでは、SysMLにあるユースケース図、ブロック図、シーケンス図、アクティビティ図などを使えば、複数の観点でアーキテクチャを分析することで整合性が取られることになる。
つまり、SysMLというモデリング言語によって、リスク管理を支援していることになるわけだ。

そんな事を考えると、設計と開発プロセス、モデリングは表裏一体のように思える。
それらを操れることで、開発をコントロールできるわけだ。

| | コメント (0)

2019/02/11

「サピエンス全史」「ホモ・デウス」の図解のリンク

一世を風靡した本「サピエンス全史」「ホモ・デウス」を図解した記事があったのでリンクしておく。
書籍を一度読んだ人であれば、この図解を見れば、そういうストーリーだったことを思い出せるはず。

【参考】
サピエンス全史図解(詳説版)|きょん|note

ホモ・デウス図解|きょん|note

akipiiさんのツイート: "この図解はすごく分かりやすい。plantUMLで書き換えてみたいな。サピエンス全史図解(詳説版)|きょん @kyon_hcj|note(ノート) https://t.co/kpZUiXCvgR"

akipiiさんのツイート: "利害関係者の図をPlantUMLで書く事例。分かりやすい。面白い。2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない https://t.co/8B15anmKAj"

【1】「サピエンス全史」「ホモ・デウス」は歴史好きの人にはたまらない本ではないか、と思う。
欧米人の学者は、歴史上の数多くの事実を一つの理論や体系、思想を元に整理して、一つの壮大な絵巻物で表現するのが上手だと思う。
でも、その膨大な量に圧倒されて、結局何が言いたいのか、を掴むのに結構時間がかかる。

そこで、上記の図解を読めば、まずは一つのストーリーを即座に理解できるので、その理解をもとに書籍を読み直すと理解しやすくなると思う。

【2】最近、歴史や法律など文系の知識をモデル化する事例に興味がある。
たくさんの文章に、言いたいことが埋もれてしまっていてすぐに理解できない時に、図解やモデリングの技術を使って、概念を鳥瞰して理解したいのだ。

例えば、利害関係者の図はパッケージ図やクラス図、歴史の流れはシーケンス図、といったモデルで表現すると、実は意外に分かりやすくなる。

2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索

akipiiさんのツイート: "この発想はいいな。歴史や政治、法務はモデル化したい。RT @naruyo_t: UMLで図を描くというのはおもしろい。ただ見栄え気にしたい派の私としてはpptがなじんでて下書きでの整理に良さそうと思った。 “2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない” https://t.co/8B15anmKAj"

色々試してみたいと思う。

【追記】
hekitterさんはTwitterを使っています: 「「サピエンス全史」「ホモ・デウス」の図解のリンク https://t.co/6KSKQH4Dph 今日UMLのことを調べてたら、思いがけず興味深いのがあるやんとみてたら、やはりakipiiさんの記事だった。(まだちゃんと読めてないので改めて読む)」 / Twitter

| | コメント (0)

astahのモデルをGitで差分比較する方法のリンク

astahのモデルをGitで差分比較する方法の記事があったのでリンクしておく
この方法は使えそう。

【参考】
astah*とGit | astah in 5 min

【1】UMLでモデルを書いていると、差分比較を取りたくなる時がある。
顧客の要求事項を一つずつモデルに反映して、課題を一つずつ潰していく作業は地道で労力がかかる。
だから、顧客のヒヤリングのたびに、想定したモデルをどんどん洗練させていく時、前回の状態とどれだけの変更箇所があったのか、後で振り返りたくなる。

また、マイルストーンごとに、モデルの差分比較もやりたい時がある。
仕様変更のスコープだけ、顧客に見積もりを請求したいからだ。

その為には、たとえモデルがバイナリファイルであっても、ソースと同じような差分比較機能が欲しくなる。

【2】(引用開始)
astah*には、プロジェクトの比較機能というものがあります。これをコマンドラインから利用できるようになっていることはあまり知られていないかもしれません。
このastah-commandコマンドは、インストールフォルダに配置されています。下記のように、-diffオプションに、比較対象の2つのファイルを指定して実行すると、モデルの差分や図の差分を確認する画面が開くというものです。

astah-commandw.exe -diff file0.asta file1.asta

このコマンドを利用することでGitリポジトリで管理するastah*のプロジェクトファイルのリビジョン間の比較をすることが可能です。
(引用終了)

なるほど、astahのコマンドにDiffオプションがあるので、それを使うという方法。
差分履歴を持つ2個のastahファイルがあれば、コマンドを使ってプロジェクト間の差分比較ができる。
このコマンドをスクリプト化しておけば、気軽に差分比較できるわけだ。

さらに、記事によれば、SourceTree上でもastahモデルを差分比較できるらしい。
これは便利だ。
Gitの履歴のリビジョンを取得して差分比較するスクリプトも用意しておけばいい。

色々試してみたいと思う。

| | コメント (0)

2019/01/04

PlantUML Example for モデルベース要件定義テクニックの記事のリンク

@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になるので、リンクしておく。
以下は、論理的でないラフなメモ書き。

【参考】
PlantUML Example for モデルベース要件定義テクニック - Qiita

akipiiさんのツイート: "この発想は面白いな。RT @ogomr: PlantUML はテキストだけど意外と表現力があって モデルベース要件定義テクニック のUMLを拡張した図も描ける。GitLab なら RDRA をブラウザで表示できて便利 https://t.co/IpCRFQ4XDu"

akipiiさんのツイート: "後で試す。RT @zenzengood: PlantUML Example for モデルベース要件定義テクニック https://t.co/IpCRFQ4XDu #Qiita テキストベースでRDRAモデルを書きたい方はとても参考になります。"

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索


【1】最近、PlantUMLに着目していて、色々試しているのだが、@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になった。

ストーリーは、モデルベース要件定義テクニック(RDRA)で使われるUML技法を、PlantUMLを使って書いてみよう、という流れ。
モデルベース要件定義テクニックは、UMLの技法をプロファイルで拡張していて、Enterprise Architectにはそのテンプレートがあるが、astahでは使えないので、いつも残念に思っていた。
だから、PlantUMLでモデルベース要件定義テクニックの技法を使えるのは非常に嬉しい。

記事では、コンテキスト図、概念モデル、ユースケース、データモデルなどがPlantUMLで紹介されている。

【2】RDRA(モデルベース要件定義テクニック)については過去に色々試していた。
僕は、UMLを要件定義に使う場合にRDRAの技法や考え方が非常に役立つ、と思っている。

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー: プログラマの思索

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

理由は、UMLを要件定義に使おうとすると、要件を複数の観点で分析したい時に、粒度やトレーサビリティがバラバラになりやすい弱点があるが、モデルベース要件定義テクニックを使えば、その弱点を克服できるから。

実際、UMLやオブジェクト指向分析の技法を使うと、中間成果物が多い割には、結局、どんな要件が決まったのか、という事が分かりにくい時がある。
一方、モデルベース要件定義テクニックでは、システム地図の一部にUMLの各種ダイアグラムが埋め込まれ、それらがどんな粒度でどのように関連しているか、システム地図を鳥瞰する観点で要件を整理できる。

僕は、下記の記事にあるシステム地図の中で、「システム外部環境」「システム境界」の部分が一番重要と思っている。

要件定義支援ツール「要件のツボ」によるRDRAの実践 (1/3):CodeZine(コードジン)

なぜなら、人とシステムが相互作用するI/Fは、それら2つの観点で整理でき、相互に関連させることで、トレーサビリティを確保できるからだ。

結局、モデリングで一番重要で、かつ、難しい部分は、各モデルの粒度を揃えてレイヤ化することと、各モデルのトレーサビリティを保証することだと思う。
だから、モデルベース要件定義テクニックのような考え方を、具体的な技法で表現できると非常に心強い。

【3】PlantUMLには非常に可能性があると思う。
システム開発がプログラミング主体であるのと同じく、設計書もテキスト化して、構成管理の配下に置きたい野望があるから。
そのイメージは1年前に書いていた。

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

仕様書にもExcel脱却が求められている: プログラマの思索

一般ユーザやプログラマへ業務イメージや技術イメージを説明する時に、何らかの図や絵を描いた資料を作るが、それらはExcelやパワポでは作りたくない。
そこで、PlantUMLを使えば、プログラミングと同じ感覚で書けるし、Webで情報共有もしやすい。

さらに、PlantUMLで描いたモデルも、モデルベース要件定義テクニックのように、各モデルの粒度やトレーサビリティを意識した規則に当てはめれば、その精度も上がるだろう。

PlantUMLが普及すれば、UMLは中間成果物が多すぎて使いものにならない、という声よりも、プログラミングの概念設計の一部として普通に使う、という考え方に変わるだろうと期待できる。
@u6k_yu1さんと同意見だ。

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

そして、最終的には、モデリングの根本問題の一つである「モデルの粒度を揃えてレイヤ化すること」「モデルのトレーサビリティを保証すること」も、PlantUMLとモデルベース要件定義テクニックを併用することで、具体的な解決方法を持って解決できそうな気もしている。
そのアイデアも試してみる。

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

【追記】
u6k_yu1さんのツイート: "PlantUMLのパーサーが欲しい。モデリングツールとして機能させたい。"

u6k_yu1さんのツイート: "はい、そうですね。と最初は思っていたのですけど、どうも私のイメージはPlantUMLのIDEっぽいです。VSCodeにPlantUMLのプロジェクト管理機能とモデル間のトレーサビリティ検証やバリデーションやチェック機能が欲しい、みたいな。… "

| | コメント (0)

2018/12/30

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク

歴史の流れをplantUMLのシーケンス図で書き起こした事例がツイートされていいたのでリンクしておく。
これは分かりやすい。

【参考】
読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "右手を痛めてから手書きを減らすべくAtom+PlantUMLで図を描くようにしてる。 画像は、大化の改新の前後をシーケンス図でまとめたもの。… "

akipiiさんのツイート: "歴史はシーケンス図で書くと面白いな。RT @kurubushi_rm: 右手を痛めてから手書きを減らすべくAtom+PlantUMLで図を描くようにしてる。 画像は、大化の改新の前後をシーケンス図でまとめたもの。 https://t.co/4FBraKNyco"

読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "実は「UMLで描く日本史」という企画もあってですね。… "

apple][ (28)さんのツイート: "あーこれはわかりやすいかも。 歴史の教科書って、時系列に文字で説明されているだけだから、相互関係や因果関係がすごく分かりにくいんだよね。図があってもすごく分かりにくかった。結局単なる暗記ものの域を脱しなくて、学問として全く興味が湧かなかったのもそれが大きな要因と思う。… https://t.co/kEoyxxbWNg"

akipiiさんのツイート: "「UMLで描く日本史」だけでなく「UMLで描く世界史」も期待しております! PlantUMLでソースをGitHubで公開してくれると、日本の高校生や受験生にも役立つと思いました。… "

てるりん🍙お結び隊 No.6🎸TEAM Mさんのツイート: "納品ドキュメントにWordやExcelが求められたりした場合は仕方ないけど、納品対象にならない内部設計のドキュメントやチームメンバー間での情報共有目的なんかは、SublimeTextやVSCodeとPlantUMLで書いてMarkdownで埋め込んでPDF化とか、最近よくやる。… https://t.co/ZxsDIBnsmJ"

【1】日本史や世界史のような歴史は大嫌い、という人も多いと思う。
理由は、暗記が大嫌いだからだ。
訳の分からない人名、関連して覚えにくい年号、など、丸暗記しなければ解答できないものばかりだから。

でも、僕自身は数学と歴史は好きだった。
理由は、数学はロジカルに組み立てられているので、基本的な公式さえ理解すれば、後は、そこから演繹的に導くだけで暗記が不要だから。

また、歴史も、その時代の政治的な背景や経済的な構造という仕組みを理解すれば、歴史上の大事件をマグマの噴火の現象として捉えることで、一連の流れで捉えることができるから。

たとえば、一昔前の歴史物であれば、マルクス主義史観や民主主義史観みたいに、歴史は経済中心で発展していくべきものであり、最終的には独裁政治から資本主義を経て民主主義へ落ち着く、という流れの中で、その国の歴史をプロットする、という考え方もある。
実際、民主主義に発展した国と歴史を考えれば、英国→フランス・米国→ドイツ・日本→ロシアの順で民主主義化されてきた。
あるいは、一人あたりGDPがある一定水準を超えると、中産階級の政治的発言力が高まり、独裁政治から民主主義に政治体制が変わる、とか。
とは言え、そういう進歩主義的歴史観が中国に当てはまるのかどうか、分からないが。

【2】では、そういう考え方で、歴史を捉えたい時、どんなモデリング手法を扱えばいいだろうか?

その答えの一つは、歴史をシーケンス図で書き起こしてみる事ではないだろうか。

たとえば、上記では、大化の改新前後の歴史的事件を、シーケンス図で書き起こしている。
さらに、吹き出しに、年号と事件名を書いている。
ゆえに、シーケンス図を見ると、誰が誰に何しているか、というのが一目で読み取れるので、理解しやすい。

シーケンス図のメリットは、アクターやオブジェクトの相互作用を表現できることだ。
そこから、UMLモデリング手法の考え方も適用できるだろう。

たとえば、Fatなオブジェクトがあって、メッセージの発信源が集中しているならば、他のオブジェクトが実は他に存在しているのではないか、と疑ってみると面白いかもしれない。
実は、XX事件の黒幕とか、他の重要人物が隠れているのかもしれない。

あるいは、「責任の委譲」を使って、メッセージが階段状になるように書き起こしてみて、歴史的事件のステーク・ホルダーが誰なのか、ステーク・ホルダー同士でどんなやり取りがあったのか、を書いてみると、より詳細に理解しやすくなるのではないか。
特に、XX戦争における敵と味方の区別、とか。
たとえば、新聞の国際欄では、シリア紛争の複雑な利害関係者の敵と味方の区別をクラス図に近いモデル図で表現している。

【3】そこで、歴史をシーケンス図で書き起こす時、VSCode+PlantUML+Gitを使うと非常に書きやすくなるだろう。

なぜならば、シーケンス図をプログラミングのように書けて、即座にプレビューできるので、試行錯誤しながら考えをまとめられるから。
また、Gitで構成管理の配下に置けば、理解した内容を継ぎ足していくことで、歴史のシーケンス図を一つの絵巻物として書き上げられるから。

上記の日本史のシーケンス図を見ていると、PlantUMLと歴史は相性が良い、という気がした。
日本史や世界史の年表を全てシーケンス図で書き起こしてみたら、世の中の高校生に貢献できるのではないだろうか??

たとえUMLを知らない高校生であっても、シーケンス図のように箱と矢印だけの絵を見れば、だいたいのイメージは分かるはずだろうから。

【4】PlantUMLの可能性については、以前から考えていた。

僕は、日本のSIで広く使われているExcel設計書は、全てテキスト化してGitで構成管理させたい。
そのためには、PlantUMLのような何らかのモデルの絵が必要だろうと思う。

一昔前の詳細設計書のような自然言語のドキュメントは現代では不要だが、システムの構想やアーキテクチャのイメージは、何らかのモデルという絵で表現したいからだ。
そうすれば、アーキテクトは、顧客やプログラマに説明しやすくなるから。

仕様書にもExcel脱却が求められている: プログラマの思索

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

ツイートを読み流していると、世界中の人達がPlantUMLを使って色んなアイデアを試そうとされているのがよく分かる。
業務フローやシステムのアーキテクチャだけでなく、ER図、ジョブフロー図、ガントチャートもPlantUMLで実現できる。
さらに、リスク関連図(?)みたいな、因果ループ図までPlantUMLで実現しようと試されている人もいるみたい。

akipiiさんのツイート: "後で読む。RT @pdl_runa: 現場で役立つシステム設計の原則にあるUMLをPlantUMLで書いてみる https://t.co/LIRmSOsBWW"

akipiiさんのツイート: "後で読む。RT @tech_advent: OPENLOGI Advent Calendar: plantUMLで業務フローを整理する https://t.co/2LWksWSyuI"

akipiiさんのツイート: "なかなか良いな。RT @abe4tawa8: PlantUMLでER図を描く! – VELTRA Engineering – Medium https://t.co/7eVRHuFjFC"

akipiiさんのツイート: "ジョブフロー図も書きたくなるな。RT @jiro_saburomaru: 定期実行のバッチとかのタイムチャートをテキストから生成できないのかな。plantuml みたいに"

akipiiさんのツイート: "I think it interesting. RT @DinisCruz: Here is the first draft and @PlantUML version of our revised @Jira schema for risk management What do you think? Does it make sense? Created by @madplatt #IN https://t.co/76Fy4FM1me"

立花優斗さんのツイート: "PlantUMLめっちゃいいな… "

【5】PlantUMLを用いて、Excel設計書をテキスト化するだけでなく、日本史や世界史もモデルで書き起こす事例のように、他の分野にも適用して試してみたくなってきた。

来年のastah関西でも、そういう話をしてみたいな。

【追記】
@kurubushi_rmさんが、「大化の改新前後.pu」「環大西洋革命.pu」をGitHubでソースを公開されている。
とても参考になる。

kurubushi--rm/history-in-UML: We will use UML to summarize Japanese history and world history

読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "@akipiiさんのご提案を受けて、このPlantUMLでソースをGitHubを公開しました。https://t.co/I8kF93dALf これだけだと日本史なので、世界史のサンプルとして「環大西洋革命」を追加しました。 何れにせようろ覚えなので、修正パッチなど遊んでいただけると幸いです。 https://t.co/aaYZyrlmSJ"

akipiiさんのツイート: "年末年始の忙しい時にありがとうございます! 歴史だけでなく、新聞の国際欄にある利害関係者の図、例えばシリア紛争、をクラス図やコラボレーション図で描く、とか、色々アイデアが膨らみます。… "

akipiiさんのツイート: "@kurubushi_rmさんが日本史と世界史のシーケンス図がPlantUMLでソースをGitHubを公開されてます。https://t.co/RzJsYwXpUj 中国の王朝変遷の歴史、歴史上の戦争とか、色々描けそう。 他に、民法や会社法、知財法などの理解の為に、UMLが使えないかな?と思ってる。"

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

【追記2】
y503Unavailable@非公式Redmine調理法unofficialcookingさんのツイート: "Redmine界隈をネタに作成してみました。(記載判断は自分の主観) 振り返り易くすることは必要ですね。… "

【追記3】
ステークホルダーの関係をPlantUMLで図式化した事例が面白い。
歴史の内容は、全てPlantUMLで置き換えた方が分かりやすいのではないだろうか。

2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない

| | コメント (0)

より以前の記事一覧