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