UML ロバストネス分析 設計

ロバストネス分析をやってみるとモードレスっていうのはAPIも単純になっていいなと思った

そもそも

私、設計スキルを学ぼうと思っていて、本とか読んで、インプットだけはやっていたんですが、設計スキルを発揮するにふさわしい複雑な問題には出会ったことがなかったです。 もともと設計というプロセスを挟むことによって、時間はかかるようになるし、いつでもどこでも必要とは思っていないです。 いろいろ本を読んだ今でも、設計プロセスをむやみやたらに挟むのは良くない派です。

とはいえ、設計プロセスの一つである、ロバストネス分析をやってみると問題が単純化するよという例が得られたので、今回記事を書いてみることにしました。

今回考えた問題

こんなUIが与えられているとします。(Google Keepに保存ボタンがついているものです。) このUIでは、何かしらリストを追加したり、リストの内容を変更したりすることができます。

保存ボタン付きのリスト。リストの一行に保存ボタンがついているのではなく、リストを含むセクション全体に対して、保存ボタンがついている。

何やら、複雑そうな気がします。

ロバストネス分析をやってみるとどうなる？

これを一度ロバストネス分析をやってみることにします。 以下の図において、赤い丸が、ユーザが行う操作で、緑の丸がブラウザ上におけるエンティティです。 また、グレーの丸がサーバ上のエンティティになります。

複雑度がお分かりいただけたでしょうか？

注目は赤枠で囲われている箇所です。

このUIだと、フロントでサーバ上のリストにある要素か、ない要素かを保存しておく必要があって、実装が複雑になりそうです。 また、APIとしてもRESTだけで表すことはできず、どうしてもリストに削除フラグなどを仕込んで、削除フラグが立っているリストの要素に対してだけ、削除を実施するなどの工夫が必要です。 私はこのロバストネス分析をやってみた結果、この実装はやりたくないなと思いました。

で、どうしたらもっと単純な実装になるUIになるのかなと考えた結果、世の中のリストUIを見ているとリスト全体を含む塊には保存ボタンがついていないことに気づきました。 つまり、モードレスなUIです。

で、モードレスなUIにするとどうなる？

リスト全体を含む塊には保存ボタンがついていない、モードレスなUIというのはつまり、こういうUIです。

リスト全体を含む塊には保存ボタンがついていないリストのUI

こういうUIにするとロバストネス図はこのようになります。

差がお分かりいただけたでしょうか？

フロントで持っていた状態がなくなり、複雑度が一気に減っています。すごい。世の中の人はすごいですね。やはり、周りを見て、どんな実装にしているのかを確認してみるのは大事です。

いろいろやってみてロバストネス分析がどう効いたのか？

今回、ロバストネス分析をやってみましたが、主に2点有効だったかなと思います。

• 複雑な実装になりそうなことを図で表すことができて、チームでイメージが共有できる。
• 実装を簡略化したことを図で表すことができて、実装が簡単になったことを評価できる。

一度、やってみるということは、その威力が知れてよかったなと思いました。

ロバストネス分析の参考図書

ロバストネス分析をはじめとするICONIXプロセスについては、下記の書籍が詳しいです。 私もロバストネス分析をはじめとするICONIXプロセスを知ったときは非常に感銘を受けました。エンティティと振る舞いを見出していくパターンのようなものがあるということに対して、非常に意義深い本だと思います。 興味があれば、是非一読ください。