10/23「第3回astah関西勉強会」に行ってきました

先週の10月23日、astah*関西さん主催の勉強会に参加してきました。
astah*関西さんは、こちらの紹介ページにもある通り、astah*を使って、より良いモデリング技法や知識、実践事例を共有する事を目的とした勉強会を開催しています。私は、過去2回の開催には参加できず、今回ようやく3回目の勉強会に参加することができました。

開催は、週のど真ん中の水曜日19:00開始にも関わらず、受付開始時間前から参加者様が続々到着され、会場の部屋が蒸し暑くなるくらいの熱気でした。初回の勉強会から比べても、定員に対する応募数の割合が0.8 -> 1.07倍と伸びており、astah*関西勉強会の認知も徐々に高まっている事を感じました。会場に着くと、astah*関西のスタッフさんが温かくお出迎え。なんともアットホームな雰囲気で、初参加の私にとっても、居心地の良い空間でした。

今回の勉強会は【もやもやを分解しよう】
要件定義やシステム開発中に生まれる「もやもや」を、モデル化で分解していき、もやもやの原因を突き止めよう!というテーマで、4つの発表がありました。

  1. モデルベースの要件定義手法(RDRA *ラドラと読みます)とPlantUMLを使った実践モデリング
  2. ユースケースのリファクタリング・テクニック
  3. 設計やプロジェクトのゴールに関するモデリング技術:ゴール指向表現(GSN)
  4. フィーチャー図によるテストケースのモデリング技術
astah-kansai1

@akipii さんによるオープニング&astah関西勉強会のご案内

e382b9e382afe383aae383bce383b3e382b7e383a7e38383e38388-2019-05-22-14.08.40

1. モデルベースの要件定義手法(RDRA)とPlantUMLを使った実践モデリング

@ogomrさんの発表。ご自身のQiita記事を発表スライド代わりにお話しされました。
– Qiita: PlantUML Example for RDRA 2.0 ハンドブック

内容は、RDRA(Relationship Driven Requirement Analysis) -ラドラと読みます-というモデルベースの要件定義手法を使って、要件定義中に生まれるモヤモヤを落とし込む方法。astah*ではなくPlantUMLを使った方法を見せていただきました。

@ogomrさんのお話は、ユーモアを挟みながら、事実を分かりやすく、そしてご自身の感情がストレートに伝わる表現で、とても楽しかったです。(そして笑顔が素敵でした!)

発表内容は、こちらをお読みください
お話を聞いて印象的だったことは、4点あります。

1. RDRA 2.0変更点の一つ「アイコンの形を規定しない」がすごく良い
RDRAで表現するモデルのアイコンを指定しない、という変更が入ったそうです。つまり表記はツール毎に任せられるのです。好きなツールを使える事でモデルを描く人の負担が減り、更に、見る人が理解しやすいアイコンを使う事で、表現力が高まり、理解が深まりますね。下の左右の図は、同じモデルを異なるツールで描いた例です。
RDRA, ユースケース図

2. PlantUML、すごく使われている
@ogomrさんから「PlantUMLを使ったことがない人?」と会場に質問したところ、挙手は僅か4名程(会場は35名ほど)。PlantUMLはテキストベースで書きやすい、という話は聞いていましたが、これほど多くの人が利用経験を持っている事には驚きました。ちなみに、@ogomrさんがご自身用に作成したPlantUMLのCheatSheetは、20万アクセスもあるそうです。

3. 整列オプション機能がないから、迷わない
図を描いている時に「あぁ、このオブジェクトを1pxこっちに攻めたいな」といった時でも、PlantUMLにはオブジェクトの細かい位置は指定できず、整列機能のようなものはないので、微妙なレイアウト調整を考えなくて済むそうです。
確かに、新しいツールを使い始める時、様々なオプションを目にすると「便利そうな機能だ。使ってみたい」という欲が湧いて、本来の目的と外れた方向についつい進んでしまう事があります。着地が本来やりたかった事と直結すればラッキーですが、欲の発散に負けて、集中力が散漫になってしまう事もしばしば。「便利そうな機能なので使いたい」ではなく「これをしたいから、この機能を使う」が大事で、本来の目的を達成する事に集中すべきですね。オプションがない事で、逆に悩まなくて済む、というポジ視点が素敵でした。

4. 要求をアクターの吹き出しで見せる
同じ要求でも、文書で読むのと、棒人間の吹き出しで見るのとでは、何を欲しがっているかが後者の方が直感的に分かりやすい。これは、自分がアクターの立場になってセリフの様に読む事で、脳内で、コンテキスト付き擬似体感ができるからでしょうか。ちょっとした工夫ですが真似したくなりました。@ogomrさんの「棒人間って和むよね」というお言葉でも、場が和みました。

 

※astah* ご利用の方へ | astah*で描いた図をPlantUMLに変換することができますよ

e382b9e382afe383aae383bce383b3e382b7e383a7e38383e38388-2019-05-22-14.08.40

2. ユースケースのリファクタリング・テクニック

@tokudiroさんの発表。

astah-kansai3

マーチンファウラーのリファクタリング本を元に、ユースケースのリファクタリング方法のパターンをご紹介いただきました。「ユースケース図最近使っている人?」の質問に、挙手は4名程(会場は35人程度)、ご自身も最近は描かれていないとの事でしたが、ユースケース図に関する「モヤモヤあるある」を挙げられると、ウンウンと頷いて聞いている方が多かったです。

「このユースケースって何なんだ?」「アクターに対して価値のあるユースケースなの?」「この基本フローと代替フロー、基本フローの方が大事だと思ってたけど実は後者の方が大事なのでは?」などの各モヤモヤとそれに対する解決手段(ユースケースの削除や抽出、結合、抽象化、具象化など)のパターンを分かりやすくご紹介いただきました。(この時間から、勉強会への途中参加者への受付などで、会場を出たり入ったりしてしまったもので、じっくり聞けず残念。。)

最後に「レガシーコードの改善を目的に、ユースケース図を使って、Cソースの依存関係を調査してます」という独自のユースケース図活用法もご紹介されていて面白かったです。
usecase

当日のスライドは、こちらにあがっていますので是非ご覧ください。
https://astah-kansai.connpass.com/event/145697/presentation/

e382b9e382afe383aae383bce383b3e382b7e383a7e38383e38388-2019-05-22-14.08.40

3. 設計やプロジェクトのゴールに関するモデリング技術:ゴール指向表現(GSN)

astah-kansai-takai

チェンジビジョンの高井が「UMLだけじゃない、もやもやを解消するモデリング技術の紹介」として、システムの仕様設計の見える化ではなく、その設計や仕様の意図を見える化する方法をご紹介しました。

使う記法は、GSN(Goal Structuring Notation)=ゴール指向表現というものです。GSNでは、トップにゴール(主張)を置き、そのゴールの文脈・目的・意図と、ゴールを達成するための戦略、達成する見込みの根拠を図で表します。ゴール(主張)には、例えばこういったものが挙げられます。

GSN, goal structuring notation

(GSN例): G1の卵色の長方形がトップのゴール。水色のCが文脈、菱形のSが戦略を表す

GSNは、近年では、システムの安全性の論証で使われています。主観的なゴール(主張)に対して客観的な証拠に基づいた論証を記述する構造なので、第三者に対して論理的そして合理的に説明することができるのです。又GSNを導入する事で、下記の様な効果も期待できますよ。

  • 設計や仕様の意図をモデルとして共有できる
  • 状況が変わった時に、対応変更の必要性の有無を系統的に判断できる(俗人的にならない)
  • 現場の知見を系統的に蓄積できる

※GSNにご興味のある方、GSNに関する記事や導入事例は、こちらからお読みいただけます
※GSN試したいな、という方、astah*のGSNエディションを50日間無償でお使いいただけます。

e382b9e382afe383aae383bce383b3e382b7e383a7e38383e38388-2019-05-22-14.08.40

4.フィーチャー図によるテストケースのモデリング技術

hosoai
高井に続き弊社エンジニアの細合より、フィーチャモデルによる組合せ設計の取り組みと、astah*プラグインを用いた組合せ生成についてご紹介しました。
ソフトウェアプロダクトラインのバリエーション管理に用いられるフィーチャーモデルを活用していわゆる「組合せの爆発」を未然に防ぐ取り組みです。

IoTやAIを用いたシステムは、どのような環境に置かれるかによって挙動が異なるため、
検証のためには膨大なテストケースが必要となります。無作為にテストケースを作っても妥当性が担保できませんし、すべての因子の全網羅では組合せが爆発してしまいます。

このため、妥当なテストケースのみが生成されるように要素間に制約を加えた組合せの設計が必要となります。
今回の取り組みではastah*上でフィーチャモデルを用いて組合せ設計を行えるようにし、フィーチャモデルから導出されるシナリオもプレビューできるastahプラグインを試作しました。

主な機能は以下の通りです。
・クラス図を拡張したフィーチャモデルの記述
・生成されたテストケースの一覧ビュー及び、検索・フィルタ・クエリ機能
・テストケースのExcelへの出力機能

image.png
当初はお客様が人力で組合せケースを作成、管理をしていた領域が、本ツールを導入することで大幅な効率化することができました。
また、フィーチャモデルを用いることで組合せの因子となる要素が自明となるため、検証範囲や検証意図を明示化しやすくなる効果も認められました。
本ツールについては現在のところ一般公開の予定はありませんが、個別にお問い合わせ頂ければ試用して頂くことは可能です。

このケースではUML以外のモデルを対象とした取り組みですが、同様にastah*を拡張、改良することで従来のダイアグラム以外をastah*でモデリングするというお取り組みについて定期的にお客様より頂戴しております。
興味がお有りでしたら是非お問い合わせください。

e382b9e382afe383aae383bce383b3e382b7e383a7e38383e38388-2019-05-22-14.08.40

感想

初めての参加でしたが、モデリングの力を信じる方、モデリング情報を交換をしたい人など熱い思いを持つ方達が多く集まり、どのお話も面白く、非常に有意義な時間を過ごせました。astah*関西メンバーさんが作られるアットホームな空間はとても居心地が良いです。初めての人も気楽に参加できて、そして楽しい時間を過ごせます。また、astah*関西という名前ではあるものの、astah*のセールス色はありません。これもよかったです。

これは、astah*関西の@akipiiさんの言葉です。

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

回を重ねる毎に、この嬉しさや会の充実度が増している事と思います。素敵な会を作ってくださってありがとうございます。改めてお礼申し上げます。

モデリングが好きな方、モデリングについて情報交換したい方、上のakipiiさんの思いに共感される方、是非astah*関西勉強会にご参加ください。また「東京でも開催してほしい」「こんな話が聞きたい」「このトピックについて議論したい」などご意見ありましたら、是非コメントくださいね。よろしくお願いします。

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s