astahによるUMLモデリング

2020/05/29

オンラインサービスmiroとastahを連携するastah-miro plugin

オンラインサービスmiroとastahを連携するastah-miro pluginのリンクをメモ。

【参考】
astah-miro pluginを作ってみました | astah in 5 min

Miro | Free Online Collaborative Whiteboard Platform

便利なオンラインホワイトボードサービスmiro(ミロ)の使い方の基本

便利過ぎる!オンラインホワイトボード miroを使ってmiro!|あしたのチーム デザイン事業部|note

デジタルホワイトボード「Miro」が目指すコロナ時代の「ニュー・ノーマル」な会議 ? BRIDGE(ブリッジ)

【miro】コロナ時代の神ツール!リモートチームを一つにするオンラインホワイトボード「miro(ミロ)」 | MAPLOG|ビジネス思考を整理するためのマインドマップ活用ブログ

以前、坂根さんから、miroがお勧めですよ、と教わったが、その意味が正直分かっていなかった。
おそるおそる触ってみたら、無限大のホワイトボードみたいなイメージで使いやすそうな感触がした。

astah-miro pluginでは、astahのクラス図とマインドマップをmiroと相互連携してくれるみたい。
このツールがあれば、ホワイトボードでラフな設計を書いた後、astahに取り込んで、モデリングを深化させていくことができる。
一方、自分で考えたastahのモデルをmiroに連携することで、ホワイトボードに書き出せるので、皆で議論するのが便利。

試してみたいと思う。

| | コメント (0)

2020/04/12

astahによる状態遷移テストの事例

astahによる状態遷移テストの事例が紹介されていたのでメモ。

【参考】
状態遷移テストと1スイッチカバレッジ|Tsuyoshi Yumoto|note

UMLステートマシンと状態遷移図 - astah-info

teyamaguさんはTwitterを使っています 「湯本さんによる,状態遷移テストの話 昨日の社内勉強会で,同じAstahを使っても,湯本さんが書いた状態遷移図と他の人が書いた図の見た目が異なっていて,湯本さんが書いた図がきれいなのは驚いた. 湯本さんとか社外で講師できる人に気軽に色々聞けるのは贅沢だわ. https://t.co/HA9cHxuFWb」 / Twitter

astahソフトウェアの品質向上支援プラグイン

astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索

上記の記事を読んで、自分の気付きがいくつかあった。

テスト技法には、デシジョンテーブルやオールペア法のような組合せテストが多い気がする。
それらは「テストパラメータの事前入力のバリエーション」に注力する。
一方、状態遷移テストでは、「テストケース構造の事前状態(事前条件)に着目」する。
つまり、単なる事前入力値の組合せだけでなく、事前入力の状態までの履歴も考慮する点が異なる。
この指摘は、改めて気付かされた。

状態遷移テストには、テストカバレッジの考え方にN-switch coverageがある。
詳細は下記を参照。

状態遷移表を使用したテスト手法【後編】 (1/3) - MONOist(モノイスト)

スイッチカバレッジのまとめ: ソフトウェアテストの勉強室

状態遷移テスト - Qiita

おそらく、単体テストレベルでは0-switch coverage、結合テストでは1-switch coverage、総合テストでは、N-switch coverageのようなイメージもあるだろう。
つまり、条件分岐処理に関するC0・C1・C2網羅のような考え方と同じく、状態遷移テストでもN-switch coverageを考えることでテスト網羅性を高めるわけだ。

では、どうやって、0-switch coverageやもN-switch coverageのテストケースを作るか?
おそらくテストケース生成ツールなしでは、状態遷移テストの網羅性を高めることは難しいだろう。

幸いなことに、astahでは品質管理プラグインがあるおかげで、状態遷移図を描けば、状態遷移表を生成し、それに基づくテストケースをExcel出力することができる。
開発者もテスト担当者も、精度の高い状態遷移図を描くことに注力するだけでいいのはすごく良いメリットだ。

改めて思うのは、テスト技法はモデリング技法に密接に関係している。
その意味は、単にモデルの正当性にテストが必要、というだけではない。
開発したソフトウェアをテストするには、何らかの観点が必要であり、それはモデルが提供すべきもの。
モデルがテスト技法を支援しているわけだ。

そういう考え方も色々考えてみる。

| | コメント (0)

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)

より以前の記事一覧