日々常々

ふつうのプログラマがあたりまえにしたいこと。

RDRAのダイアグラムの位置付け

RDRA をやってて思うところ。

RDRAでは多くのダイアグラムが定義されていますが、これらのダイアグラムはきっと成果物(最終的に作るものの中核にあるものをこう呼んでみる)では無いです。多分ハマりどころ。 システムコンテキスト図も業務フロー図もユースケース複合図も、どれもRDRAのエディタとビューアでしかありません。中間成果物、もしくは補足資料的な位置付け。

じゃあ成果物が何かって言うと、各アイコンと関連線。詰まるところ全てのアイコンと関連線を持ったリポジトリそのものが成果物なんだと思います。

ダイアグラムを通してリポジトリを読み書きしている感覚。アイコンを見つけやすい、関連線を引きやすいダイアグラムを使ってアイコンを配置し、アイコン間に関連線を引く。その整合性を確認しやすいダイアグラムを使って、アイコンと関連線を検証する。各ダイアグラムはそのためのものでしか無い。 決して「ダイアグラムを作ればヨシ!」と言うものでは無い。

……とか思い至ってからRDRA2.0ハンドブックを読み直したら「はじめに」に書いてた件。

RDRAではダイアグラムよりもモデル要素間のつながりを重視します。

紙版で持っています。なんだかんだで物理媒体便利。画面もCPUも占有しないし電気も使わない。やはり石板が最強か。

やはり重要なことは最初に書いてますね。そして理解していないと読んだつもりでも重要さを読み落としてしまう……。

どうしてもRDRAはダイアグラムが目立つようで、「どのダイアグラムを作ればよいか」「どのダイアグラムに何を書けばいいか」と言った疑問をよく聞きます。私も使いこなせていない感はあるのでなんともなのですが、少なくとも早めにダイアグラムを主人公じゃなくす方にシフトした方がいいんじゃないかなーと思ったりしています。

ダイアグラムの見方が変われば、ビジネスユースケース図を作るか否かとか、ビジネスユースケースから業務フローを作るべきか、利用シーンが必要か、いきなりユースケース複合図に行っていいのかダメなのか、なんてことはどれでも良くなってきます。アイコンと関連を書きやすいかどうか、書き始めてからでも。なんか足りないなって思ったら他のダイアグラムを使ってみたらいい。「ユースケース複合図 業務フロー付き」とかがあるのも、それの方が書きやすいからだと思う。一つ一つのダイアグラムにそんな価値はない。と言うか、一つのダイアグラムだけ取り出すと、ほとんど価値がない……。

ダイアグラムに目が向いてしまうと、RDRAが避けようとしている「ドキュメントを作ることが目的になっている」に結局ハマりそうだなぁと。 でもダイアグラムをある程度書き慣れないと厳しい気もする。

RDRAのダイアグラムはシンプルでぱっと見わかりやすいのですが、書かないと読めるようにならないんじゃないかと。少なくとも書いている場に同席している必要があると言うか、同席できる程度の記述量だからRDRAなんだろうなって思ったり。

こんなことをふわっと考えている今日この頃。

モデルベース要件定義テクニック

モデルベース要件定義テクニック

RDRA1.0ですが、2.0ハンドブックと比べると変わった点、強調したい点、変わらない点が見えるので面白いです。ページ数が多い分、RDRA自体のコンテキストはこちらからのほうが読み取れる気もする。