astahによるUMLモデリング

2021/09/26

astahのセミナーレポート「サンプルモデル図で解説、MBSEの流れとモデルの役割」の感想

astahのセミナーレポート「サンプルモデル図で解説、MBSEの流れとモデルの役割」の記事と動画が公開されていたのでメモ。
参考になった。

【参考】
セミナーレポート「サンプルモデル図で解説、MBSEの流れとモデルの役割」 | astah in 5 min

電気ケトルを題材にして、SysMLと安全性の観点からモデルを描いて詳細化していく流れ。

重要な考えは、モデル種類x検討した観点のマトリクスでSysMLのモデルを使い分けること。
モデル種類には、用語、構造、接続性、状態、プロセス、シナリオの6種類がある。
前半がブロック図、後半は状態遷移図、アクティビティ図、シーケンス図に対応する。

検討した観点には、Usage、Function、Implementationなどがある。
順に詳細化していく感じ。

気づきは、SysMLのそれぞれの図は関連していること。
動画を見ると、ブロック図やユースケース図の要素にハイパーリンクがあって、リンク先にブレイクダウンしたシーケンス図やステートマシン図がある流れだった。
こういう風にモデルがトレースされて作られていくならば、説明しやすいし理解しやすいと思う。

ブロック図の使い方は分かっていなかったが、利害関係者を含むコンテキスト図やハードウェア部品構造、機能とハードウェア部品の関係に使うらしい。
SysMLではブロック図が一番重要なモデルに思える。
ちょうど、UMLではクラス図が一番重要であるように、SysMLではハードとソフトが関係するモデルとしてブロック図が設計図に相当するように思えた。

個人的には、モデリングのプラクティスみたいなものも資料に添えられたら役立つだろうと思った。
たとえば、オブジェクト指向設計でも、SOLID原則、GRASPパターンのような基本プラクティスがあり、そのプラクティスを使うことで、クラス図の責務割当がスムーズに行くからだ。
SysMLでも、オブジェクト指向設計のプラクティスは使えるだろうが、SysML特有のプラクティスや組み込みソフトウェアならではのプラクティスが知りたいところだった。

この辺りは色々調査してみたい。

| | コメント (0)

2021/07/23

値オブジェクトの設計がオブジェクト指向モデリングの最初の登山口

先日7/14に開催された「アジャイル開発におけるモデリング活用実践セミナー」のオンライン動画を見ていて、興味深かった。
羽生田さん、増田さん、原田さん達の会話が面白かった。
気になった発言をラフなメモ。
自分の感想も混じっていて、全くロジカルでない。

【参考】
「アジャイル開発におけるモデリング活用実践セミナー」(2021.07.14開催) - UMTP 特定非営利活動法人UMLモデリング推進協議会

ドメイン駆動設計が好きで、ベンチャー企業のWebサービスの開発で使っている

最近は、基幹系システムのリプレースでドメイン駆動設計を使いたい、という話も多く来ている
すごく難しいけど、やりがいもあるし面白い

オブジェクト指向モデリングのワークショップでモデルを書こうとすると、みんな、フレームワークが前提でモデルを書いてしまう
ドメインの外側ばかり話している
肝心のドメインをプログラミングしようとすると、意外に誰も書けない
まずは値オブジェクトから始めよう
みんな、値オブジェクトでプログラミングできない
増田さんのオブジェクト指向モデリング本「現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法」は、値オブジェクトから書こうとしているのでお勧め

intやStringのデータ型だけではトランザクションスクリプトみたいに書いてしまう
値オブジェクトが大事
オブジェクト指向では、Immutableな値オブジェクトから始まる
関数的プログラミングとも相性がいい
ドメインに特化してプログラムを書こうとすると、必ず値オブジェクトから始まる
値オブジェクトの設計がオブジェクト指向モデリングの最初の登山口

エンティティを重視するとデータモデリングになってしまう
手続き型プログラミングで、でかいエンティティを書いて、長いトランザクションスクリプトを書くと失敗する
書いていて怖い
データモデリングとオブジェクト指向モデリングは違うと考えた方がいい

エリック・エヴァンスのDDD本「エリック・エヴァンスのドメイン駆動設計」に出てくる例では、OODBを使っていた
昔はデータのストアはOODBでいい、という感じだった
OODBでは性能が出ないので廃れた

業務の複雑さに関するデータのモデリングは、データモデリングの方が一日の長がある

1990年代にモデリングが盛んだったのに、現代ではモデリングが廃れたのは、モデリングが伝承されなかったからではない
むしろ、現代的な課題に対して、長年知られていたモデリング手法のこの部分は今も使えるが、この部分は今は使えない、という交通整理された本がほしいね

2010年代にピアソン本が絶版されたので古いオブジェクト指向モデリング本が手に入らなくなり、エリック・エヴァンスのDDD本「エリック・エヴァンスのドメイン駆動設計」だけが唯一残った
そのために、オブジェクト指向モデリングの歴史に断絶がある

メソッドは3個まで
それができない人は、クラス化、カプセル化が分かってない
入出力処理は手続き型になりやすい

顧客との対話では、UMLを普通に使う
ただし、アクティビティ図、コンテキスト図、データフロー図を使う場合が多い
システム要件に落とす時は、UMLをガンガン使う

要件定義でモックを作るときはHTMLを使う
最近はいい感じですぐにモックデザインが作れる
実データを画面で見せた方が早い

プロダクトオーナーとの対話では、RDRA2.0を使って話する時が多い
システム設計では、UMLを使っている
図を書くのが目的ではなく、会話や意思決定のために使っている

DDDのエンティティはミュータブル?イミュータブル?
Webならイミュータブルが普通でしょ
setter, getterと無関係なモデルにしている
イミュータブルが普通
エンティティに状態は持たせない
void実行でなく、新しい状態のオブジェクト、エンティティを別で返す
Webならイミュータブルが普通
エンティティの状態をSetして変更すると、バグが出そう
イミュータブルだからFreezeしているのでCloneする必要もない

アジャイル開発プロセスとモデリング作業の事例は?

モデリングでも、概念モデルのレベルでプログラミングを書く
合わせてDFDやER図を書く
事業分野の可視化はシステムで書きにくいので、シナリオ、バリューチェーンを書く
バリューチェーンで、どこのプロセスに差別化要素があるか、強みがあるか、を分析する
ビジネスを理解するモデリングとシステムとして動かすプロトタイプの2つを行き来している

増田さんのドメインモデルのサンプルが分かりやすい
パッケージ図でクラス図を分割して、HTMLで一覧にしている
さらに、ユースケースのシナリオからパッケージ図、クラス図まで一気通貫でHTMLにしている
軽量で明快なモデリング
ビジネスモデルとDFD・ER図をつなぎつつ、パッケージ図・クラス図で方にしてHTMLで見せている
増田さんのクラス図は値オブジェクトが中心
取引日、貸し出しも全てクラスになっている
増田さんにとって、モデル駆動とはドキュメント駆動のイメージ
ソースコードとモデルを行き来していて、モデルが自然にドキュメントになっている

Scrumで開発する時に、ユーザーストーリーマッピングを使う場合が多い
このメソッドを実装する時、このメソッドはこの要件から来ていて、この要件はユーザーストーリーマッピングのこの部分に対応する、と辿れる

【感想】
エリック・エヴァンスのドメイン駆動設計現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法を読むと、ドメインのソースコードが値オブジェクトになっている場合が多い。
その理由は、ドメインをプログラミングに注力しているから、と見ると分かりやすい気はする。
オブジェクト指向でプログラムを書くと、状態を持たせるエンティティが頻出して、バグが出やすい箇所はたいていその部分であり、デバッグしないと追跡できない場合が多いのを思い出した。

| | コメント (0)

2021/07/11

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて楽しい

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて、面白いのでメモ。
10年以上も前にかおるんさんは既に読破されているので参考にしている。

【参考】
読了・組み込みソフトウェア開発のためのオブジェクト指向モデリング - ブログ@kaorun55

読了・組込みソフトウェア開発のための 構造化モデリング - ブログ@kaorun55

【1】上記のブログでは、「組み込みとしては、やはりこちら(構造化)の方がしっくりくる。なんとなくオブジェクト指向の方は無理をしている気がしてならない。」という感想がある。
オブジェクト指向モデリング」よりも「構造化モデリング」の方がしっくり来るらしい。

一方、僕は、構造化設計の技法は、データフローダイアグラムとかSTS分割のような古い技法に違和感があって、むしろ、オブジェクト指向設計の方針でクラス図、シーケンス図、状態遷移図からモデルを作り出す方がしっくり来る。
だから、「構造化モデリング」よりも、「オブジェクト指向モデリング」の方が、読みやすく感じた。
なぜなら、オブジェクトで考える方がレイヤ化設計、状態遷移図などのモデルを自然に組み立てられる気がするから。

【2】たとえば、組込みSW開発の経験はゼロだが、組込みSWのモデルをユーザ視点の業務ロジック層と、物理法則やセンサーから検知した情報の制御を含む制御層の2つに大きく分けてモデルを組み立てる方針の場合、オブジェクト指向設計の方がパッケージでソフトェアを分割してレイヤ化しやすい利点があると思う。

以前、astah関西で、高井さんがSysMLを使う利点として、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家、ハードウェアの専門家、そして組込みSWを開発するプログラマの4種類の人達が、SysMLを通じてコミュニケーションできるようになった、という話もあった。

第2回astah関西の感想 #astahkansai: プログラマの思索

また、状態遷移図とは、一つのオブジェクトに着目してその状態が遷移した過程を表すので、クラス図で洗い出したオブジェクトから自然に状態遷移図で考えるように仕向けられる。

組み込みソフトウェアの根本問題~対象物の状態遷移を記述できれば、制御が可能だ: プログラマの思索

【3】興味深いのは、組込みSW開発の要件定義で重要な成果物として、ユーザ視点のユースケース分析だけでなく、イベントリストも挙げられている点だ。
たとえば、「構造化モデリング」「オブジェクト指向モデリング」の例では、電気ポットのソフトウェア要件定義で、ユーザがお湯を沸かすときのイベントだけでなく、ポットの水位やポットのお湯の温度の変化がトリガーとなるイベントも洗い出されている。
考えてみれば当たり前だが、アクターとして、ポットの購入者という利用者だけでなく、ポットという機械を構成するセンサー部品(水位の検知、温度の検知)もアクターになるわけだ。
つまり、組込みSW開発では、アクターの種類が多いので、コンテキスト図を最初に描くのが割と重要と気づいた。

【4】もう一つの「リバースモデリング」は読みかけだが、よくある事例な気がして、興味深く読んでる。
レガシーな業務システムと同じく、組み込みソフトウェアもレガシーになると、設計書はなくなっていて、動くソースコードが仕様そのものになっている。
しかし、数千行、数万行、数十万行のソースコードから本来の設計思想を汲み取って開発するのは至難の業だ。
たとえば、工場の生産ラインとか、長年使われている機械部品とか、そういう例があるのだろう。

リバースモデリング」では、レガシーと化したソースコードからリバースして、モデルを抽出し、本来のあるべきモデルを描き出し、そこから仕様変更や改修を手がけていく、というストーリー。
なかなかうまく行かないだろうが、色んな技法を駆使して、リバースしたモデルを洗練させていくのは面白い。
今なら、XDDPと組合せてやるだろうか?

【5】残念なことに、組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」は、「構造化モデリング」以外は絶版になっている。
3部作全てが復刊されるといいなと思う。


| | コメント (0)

2021/06/20

なぜか2000年代にIT系の良い本が多いと感じる今日この頃

最近、Ciscoベースのネットワーク、組み込みソフトウェア開発・設計のためのモデリング、業務システムやERPを設計・分析するためのデータモデリングや業務フローの本を読み漁っている。
他にも、Matlab・Scilibのようなシミュレーション関係の本も探している。

たとえば、下記の本になる。

【1】「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門 第2版」「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」は、オンプレのネットワーク設計の解説でピカイチだった。
インフラ担当者なら当たり前の知識なのだろうが、アプリ開発の経験しかない僕にとってはとても新鮮だった。
クラウドやInfrastructure as Codeが何を解決しようとしているのか、について、考えさせてくれた。

なお、この本は2010年代の本だが、ほとんどのCiscoルータ・スイッチの解説・コマンドリファレンス本は2000年代が多い。

【2】「組込みソフトウェア開発のための オブジェクト指向モデリング (組込みエンジニア教科書)」も良かった。
話題沸騰のポットを題材に、ハードウェアのポットを要件定義から、オブジェクト指向設計、C++のソースコードまで落としてくれる。
業務システム設計とは違う観点で、状態遷移図やパッケージ間の依存関係が非常に重要になってくる。
2006年頃の出版で絶版。

【3】「7つの要素で整理する業務プロセス (for Mutual Interest SERIES)」は、業務フロー図の演習本だ。ひたすら、7種類の業務フローのサンプルと解説をしてくれている。
内部統制が導入された頃に、ITに関係ない人が業務フローを使うことになった時に使われたのだろう。
2007年頃の出版で絶版。

【4】しかし、それらの本は2000年代に良い本が多く、2010年代はほとんど出版されていない。
オブジェクト指向モデリング、データモデリング、オンプレのネットワーク、シミュレーションなどの基本的な技術の解説本がほとんど出版されていない。
なぜなのだろうか?

おそらく、IT技術のトレンドが激しく変化してしまい、従来の設計や技術は基盤として埋め込まれて、見えなくなってしまうくらい、当たり前になってしまったからではないか。
実際、データモデリングやオブジェクト指向モデリングも、その概念や考え方は、20年前も10年前も変わらない。

しかし、SOEのWebシステムでも、枯れた業務システムであっても、データモデリングは必須だし、オブジェクト指向モデリングも知っていて当然だろうが、そういう技術を知らずにどっぷり最先端の技術にハマってしまう。
今となっては、最先端の技術から古い技術に遡るしか無いのだろうが、基本的な技術無しで取り組んでいる感じで、何か腑に落ちない時が多いと思う。

2000年代に良い本が多いのに、割と絶版になっていたりする。
すると、それらの本に含まれているノウハウや優れた説明は継承されることなく消えてしまう。

たぶん、ベースとなる技術はもはや当たり前であって、ベースの技術や基盤の上で、次々に新しいサービスをどんどん生み出していくのが普通になっている。
だから、逐一古い基礎的な技術を掘り返すのは手間がかかり過ぎるのかもしれない。

この辺りの理由は色々探りたい。
そして、その悪影響についても考えてみたい。


| | コメント (0)

2021/06/05

組み込みソフトウェアの根本問題~対象物の状態遷移を記述できれば、制御が可能だ

「組み込みソフトウェアでは対象物の状態遷移を記述できれば、制御が可能だ」という文言をネットで2箇所見つけた。
ラフなメモ。

組み込みソフトウェアのモデリングにおける根本問題とは何だろうか?
業務システムのモデリング、ネットワーク設計の根本問題とは異なる。

業務システムのモデリングでは、業務ロジックをいかにER図に落とし込めるか、という点に集約できると思う。
以前書いた。

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

その考えから、ビジネスの一連の業務フローが表現されて、データのライフサイクルと使われる帳票が導出されて、最終的にERPになるイメージ。

一方、ネットワーク設計の根本問題は、ネットワークの品質をどのように保つか、という点に尽きると思う。

SDNアーキテクチャの本質は巨大な仮想L3スイッチを実現したことではないか: プログラマの思索

なぜInfrastructure as Codeが必要なのか?: プログラマの思索

ネットワークの根本問題は何か~昨今のIT技術と時代の変化についての考察: プログラマの思索

ネットワークの品質は、耐障害性の観点でのL2・L3の冗長化、セキュリティの観点でL2のスプーフィング対策・L3のパケットフィルタリング・認証、L4層以上のファイアーウォールやVPN、音声や動画やデータの通信品質を保つ観点のQoSなどの技術が使われている。
さらに、巨大で複雑なネットワーク構造を構成管理の配下に置くために、SDNやぜInfrastructure as Codeの技術が生まれた、というイメージ。
特に、昨今は、データモデリングやオブジェクト指向設計よりも、ネットワークの仮想化技術が熱いと思う。
その中にクラウドも含まれるわけだが。

では、組み込みソフトウェアのモデリングにおける根本問題とは何だろうか?


組み込みモデリング - MONOist

(引用開始)
組み込みシステム開発の世界には、大きく2つのモデル<ソフトウェアのモデル>と<制御のモデル>が存在する。
(引用終了)

組込みソフトウェア開発のための オブジェクト指向モデリング (組込みエンジニア教科書)にこんな感想があった。

(引用開始)
殿堂入りNO1レビュアー
kaizen
状態遷移が肝でしょうか。

2008年3月21日に日本でレビュー済み
対象物の状態遷移を記述できれば、制御が可能だという意味で、オブジェクト(対象)指向は有効なのだと思われます。
モデルを作る場合に、対象(オブジェクト)を記述していくのが王道なのだと思われます。
本当に必要な技術と、内容を確かめるために使う技術と、試験のための技術との詳細な説明があるとよいかもしれません。
(引用終了)

勝手な想像では、組み込みソフトウェア設計では、単純に部品をクラス図やブロック図に表現するよりも、そこから、抽象度を上げた対象物の状態遷移を見抜くことが重要ではないだろうか。
対象物の状態遷移を記述できれば、プログラムで実装可能であり、その制御プログラムで機械に作業を指示できる。

しかし、状態遷移は爆発しやすい、という根本問題は以前からある。
だから、状態が爆発的に増えてコントロールできなくなるために、レイヤーごとに分けたり、抽象度を上げ下げしたりして、ソフトウェアの複雑さを制御しようとしているのではないか。

この発想を元に、色々考えてみる。

| | コメント (0)

2021/06/03

RPAはデータモデリングを復活させるのか

RPAがノーコード開発とみなされることで、野良データを増やして、データを分散させてしまって破綻しそうな話がツイートで流れてた。
また、アクターが3人出てくる企業システム開発は、BtoCのWebシステム開発とは異なるよ、というデータモデリングの記事もあった。
ラフなメモ。

Web世代の皆さん、企業情報システムを見たことがありますか? | 日経クロステック(xTECH)

Windows10でRPAが手軽に使えるようになって、ちょっとしたRPAブームかもしれない。
しかし、RPAをノーコード開発と捉えて、Excelを単に置き換えたようなシステムで作ると、破綻する。
データが正規化されていない、データが一元化されていない、などの問題が噴出するのは誰でも知っているが、データモデリングを知らなくても作れることで、よりその問題が大きくなったのかもしれない。

また、SoEのWebシステム開発だけで経験を積むと、バックエンドの業務も含めたより業務が複雑になる基幹システムまで目が向かなくなる。
昨今のコロナワクチン接種予約システムの件も連想させる。

データモデリング、あるいはオブジェクト指向モデリングも、最近はアジャイル界隈でも聞かなくなった。
10年以上前に終わった感じもある。
しかし、その有効性は今も変わらないのだろうと思う。

| | コメント (0)

ビジネスモデルキャンバスで思考を発散させて、ピクト図で思考を収束させる

ビジネスモデルキャンバスで思考を発散させて、ピクト図で思考を収束させるという記事を読んで、なるほどと思った。
ラフなメモ書き。

【参考】
ビジネスモデルをデザインするスキル 「ビジネスモデル・キャンバス」と「ピクト図解」を身につけろ | 「ピクト図解」考案者が語る ビジネスモデルのつくり方|DIAMOND ハーバード・ビジネス・レビュー

ビジネスモデルを「見える化」するピクト図解 「ビジネス3W1H」を意識してビジネスモデルを読み解け | 「ピクト図解」考案者が語る ビジネスモデルのつくり方|DIAMOND ハーバード・ビジネス・レビュー

ビジネスモデルは「基本パターン」の組み合わせで考えよ ジレットとネスレの事例から学ぶ「消耗品モデル」 | 「ピクト図解」考案者が語る ビジネスモデルのつくり方|DIAMOND ハーバード・ビジネス・レビュー

ビジネスモデルの「プロトタイプ」を量産せよ 実践!ビジネスモデルをデザインする(前半) | 「ピクト図解」考案者が語る ビジネスモデルのつくり方|DIAMOND ハーバード・ビジネス・レビュー

「新結合」でビジネスモデル・イノベーションを起こせ 実践!ビジネスモデルをデザインする(後半) | 「ピクト図解」考案者が語る ビジネスモデルのつくり方|DIAMOND ハーバード・ビジネス・レビュー

ビジネスモデルキャンパスの感想: プログラマの思索

ピクト図解を用いたビジネスモデルの書き方と事例 | Finch [フィンチ]

【1】企画フェーズの資料や提案資料を作成していると、ビジネスモデルをポンチ絵で描いたり、経営戦略に基づいたあるべき業務プロセスを描く必要が出てくる。
そんなときに、考えているアイデアを整理したり、アイデアを膨らませるためのテコ、基点となるような、何らかのフレームワークが欲しくなる。

【2】ビジネスモデルキャンバスやリーンキャンパスは、リーンスタートアップやプロダクト開発でよく例として出てくる。
しかし、実際に書いてみようとすると、そもそも枠内にアイデアが出てこなかったり、それぞれの要素の因果関係やロジックが作れなくて、手間取る時が多い。
また、キャンパスにたくさんの付箋やPostItを貼っても、何か分かった気がしない。
ビジネスというプロセスをモデル化できた気持ちにどうしてもなれなかった。

一方、ピクト図は、UMLで言うオブジェクト図、コラボレーション図に非常に良く似ている。
アクター同士の相互作用があって、その相互メッセージは、必ず情報のやり取り、お金のやり取りが発生する。
システムユースケース図に近いイメージ。

ビジネスモデルを「見える化」するピクト図解 「ビジネス3W1H」を意識してビジネスモデルを読み解け | 「ピクト図解」考案者が語る ビジネスモデルのつくり方|DIAMOND ハーバード・ビジネス・レビューでは、ビジネスモデルキャンバスでは、思いついたアイデアを枠内にPostItをどんどん貼っていって思考を発散させる。
一方、ビジネスモデルキャンバスで抽出した要素は、ピクト図の相互メッセージに対応させたり、相互メッセージを発生させる要因として対応付けて、思考を収束させる。
つまり、ピクト図で、ビジネスモデルキャンバスの要素に因果関係やロジックを表現しているわけだ。

こういう考え方ができるならば、ビジネスモデルをビジネスモデルキャンバスとピクト図という2つのモデルで分析できて、それぞれの因果関係や意図をより明確に理解できるようになる。

ビジネスモデルキャンバスとピクト図を組み合わせることで、UMLのように、1つの分析対象を、複数のモデル技法で多面的に分析できるのはとても良い。
複数のモデルを描くだけで、整合性を取る作業を通じて、自然に多面的に考えるようになるからだ。

【3】最近、システム開発する前の企画フェーズやシステム提案の作業が多くなって、その資料に必要なモデル技法を探している。
ビジネスモデルキャンバスとピクト図はその一つの手段。

他にも興味を持っているのは、匠メソッド。
一部のアジャイル界隈では、SIがシステムを受注する前にシステム提案に使ったり、新たな事業を企画する時に使っているのは知っている。
なかなか触手に至らなかったけれど、価値から要求を導き、業務をAsIsとToBeを導こうとする点、デザイン思考のようなラフなモデルとBABOKライクに戦略要求から移行要求までロジカルに組み立てるモデルを組み合わせている点は、よく考えているように思える。

気づいたことがあればまた書く。

| | コメント (0)

2021/06/01

顧客が本当に欲しいものは何か?

顧客が本当に欲しいものは何か?というイメージが面白かったのでメモ。

[姿勢編]理由無き要求は機能化してはいけない | 日経クロステック(xTECH)

現場は軽トラックで十分なのに、管理職や経営陣は重装備のトラックを要求してる。
しかし、予算は自転車並みなので、出来上がってくるのは人力車とか。
足りない機能は人力の運用でカバーするのが前提。
いかにも、現場が強い日本向けのシステムみたい。

| | コメント (0)

2021/05/30

PlantUMLの手書き風ダイアグラムスタイル

PlantUMLの手書き風ダイアグラムスタイルという機能があったのでメモ。

Draft with handwritten diagram

(引用開始)
手書き風ダイアグラムスタイル
ダイアグラムが作成途中であることを強調するために、手書き風のダイアグラムを出力することができます。
skinparamでhandwrittenをtrueに設定します。

@startuml
skinparam handwritten true
Alice -> Bob : hello
note right: Not validated yet
@enduml
(引用終了)

平鍋さんから、モデルは手書きのようなイメージにしたい、と聞いた。
モデルの内容はロジカルであっても、伝えるときには、手書きの筆跡で感情に訴えるようにしたい、と。
なるほど、そんな考え方もあるのか、と思った。

PlantUMLには、そういう手書き風スタイルがあると聞いた。
そういう機能がastahにも入れたい、と。

確かに、人に伝えるときには、因果関係のロジックだけでなく、熱気や気持ちも伝えたい。
そういうパッションも伝えたい時に、使うといいかもしれない。

| | コメント (0)

2021/05/25

astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い

astahとPlantUMLを行き来できるastah* PlantUML Pluginが公開された。
この機能は、色んなアイデアを生み出すと思う。

【参考】
astah* PlantUML Plugin | モデルを相互変換できるプラグイン

astah* PlantUML Plugin | astah in 5 min

シンプルなテキストファイルで UML が書ける、オープンソースのツール

Visual Studio Code で UML を描こう! - Qiita

PlantUML使い方メモ - Qiita

PlantUML Pluginでは、astahのクラス図、シーケンス図をPlantUMLのソースコードにリバースしてくれて表示してくれる。
また、PlantUMLのソースコードを元に、PlantUMLのビューを見せてくれるだけでなく、astahのクラス図やシーケンス図も作成してくれる。
つまり、PlantUMLのソースコードとastahのモデルを行ったり来たりすることができる。

このPlantUML Pluginの利用シーンは、色んな使い方が考えられるだろう。

astahで描いたクラス図やシーケンス図などのモデルは構成管理が難しかった。
バイナリファルでGitで管理しても、差分情報が分からないからバックアップ代わりくらいの機能しかない。

しかし、いったんPlantUMLのソースコードでテキスト化してしまえば、Gitの履歴管理で、モデルがどのように変遷していったのか、モデルの差分情報を詳しく見ることができる。
これが最大の利点だろう。

他にも、PlantUMLのプレビューでは割とアイコンがしょぼいので、astahで綺麗に表示してくれるのはありがたい。

PlantUMLは、UML以外にもガントチャート、アーキテクチャ図、マインドマップ、WBS図(作業分解図)、ER図、ネットワーク図なども描けるので、それらもastahで実現できたとしたら、すごいだろうなと思う。
実際は無理だろうが。

正直な所、あっと思うような利用シーンがまだ思いつかないが、色んな可能性を秘めていると思う。

| | コメント (0)

より以前の記事一覧