ICONIX プロセスによる Java 製 REST API の設計
先日 Java と Spring Boot を使って REST API のプロトタイプを作った。さらに、書籍「ユースケース駆動開発実践ガイド」で登場する ICONIX プロセスを参考にユースケース記述の工程までを試してみた。
ICONIX プロセスを用いた設計も Java も Spring Boot も学習中なので、いろいろ雑だと思うが学びの記録として続きの工程を簡単にまとめてみる。ICONIX プロセスは工程を進めながらイテレーティブに各図を洗練されていく様なので、上記記事でのアウトプットも一部変更して再度この記事に貼り付ける。
紙芝居
作ろうとしているアプリケーションの画面構成を簡単に表現している。
機能要求
アプリケーションができることは何かを定義する。
- ユーザーは node を登録できなければならない
- node には名前を登録できなければならない
- root 以外の node は 1 つの parent node を登録しなければならない
- node は child node を任意個数登録できなければならない
- node と node は edge で結ばれていなければならない
- ユーザーは node の内容を編集できなければならない
- ユーザーは node を削除できなければならない
- ユーザーは tree を閲覧できなければならない
用語集
機能要求やユースケースで登場する用語の説明をする。
| 用語 | 説明 |
|---|---|
| node | ・システムに登録することができる最小単位の要素 |
| edge | ・node と node を結び付ける要素 |
| tree | ・node と edge で構成される node の集合体 |
| root | ・最上流に位置する node |
| parent node | ・ある node と edge で結ばれ上流側の node ・各 node にとって parent node は単一となる |
| child node | ・ある node とedge で結ばれた下流側の node ・各 node には任意個数の child node を持つことができる |
ドメインモデル
用語集に登場する概念らの関係を整理・視覚化する。
ユースケース図
このアプリケーションのユーザーが、このアプリケーションを使用して何ができるのかを表現している。
ユースケース記述
ユースケース図をより具体化するためにユーザーとアプリケーションの対話を記述する。本来ならユースケースの代替コース（例外）も記述するべきだが面倒なので省略する。
- node を登録する
- ユーザーはページへアクセスする
- システムは tree を表示する
- ユーザーは node の右上の「・・・」ボタンを押下する
- システムはドロップダウンメニューを表示する
- ユーザーは「Add child node」ボタンを押下する
- システムは child node を作成し、作成された child node の名前を入力するための input 要素にフォーカスする
- ユーザーは node の名前を入力しフォーカスアウトする
- node の名前を編集する
- ユーザーはページへアクセスする
- システムは tree を表示する
- ユーザーは node の右上の「・・・」ボタンを押下する
- システムはドロップダウンメニューを表示する
- ユーザーは「Edit」ボタンを押下する
- システムは node の名前を入力するための input 要素にフォーカスする
- ユーザーは node の名前を変更しフォーカスアウトする
- parent node を編集する
- ユーザーはページへアクセスする
- システムは tree を表示する
- ユーザーは node の右上の「・・・」ボタンを押下する
- システムはドロップダウンメニューを表示する
- ユーザーは「Change parent node」ボタンを押下する
- システム parent node にしたい node の選択（クリック）を促すメッセージを表示する
- ユーザーは任意の node をクリックする
- システムは選択された parent node と当該 node を結びつける
- node を削除する
- ユーザーはページへアクセスする
- システムは tree を表示する
- ユーザーは node の右上の「・・・」ボタンを押下する
- システムはドロップダウンメニューを表示する
- ユーザーは「Delete」ボタンを押下する
- システム node を削除し、child node がある場合は削除した node の parent node と child node 結びつける
- tree の参照
- ユーザーはページへアクセスする
- システムは tree を表示する
アーキテクチャ
オニオンアーキテクチャの思想をベースにしている。
| レイヤ | 役割 |
|---|---|
| Domain | ・Entity ビジネスの概念やルールを表現したドメインオブジェクト・ Repository ドメインオブジェクトの取得や更新を表現したインターフェース |
| Service | ・Service ユースケースを実現するアプリケーション固有のロジック |
| UI | ・Controller リクエストを解釈しレスポンスを生成するオブジェクト |
| Infrastructure | ・Repository いわゆる Data Access Object |
ロバストネス図
ユースケースとオブジェクトを関連付ける。この記事の最後にも感想を書いたが、この工程が難しいと感じた。次の工程であるシーケンス図の作成にあまり役にたたなかった。
1.node を登録する
2.node の名前を編集する
3.parent node を編集する
4.node を削除する
5.tree の参照
クラス図
アーキテクチャをベースにクラスに対する責務を割り当てる。
シーケンス図
ユースケースの振る舞いを、オブジェクトがどの様に達成するのかを示す。すなわち、ユースケース毎にシーケンス図を書くのが望ましいが、面倒になってきた参照と登録さえ設計できていれば、他のユースケースも同じ様に実装できそうなので一部省略している。
5.tree の参照
1.node を登録する
データベース設計
約 2 年ほど前に購入して読んでいた書籍「達人に学ぶDB設計 徹底指南書 ～初級者で終わりたくないあなたへ」を読んでテーブルに格納する値の例と ER 図を考えてみた。
このアプリケーションは木構造でデータを管理するのだが、この書籍を読んでリレーショナデータベースが木構造でデータを格納するのが苦手なことを知った。
tree
| tree_id（主キー） | tree_name |
|---|---|
| TREE1 | 動物 |
| TREE2 | Foo |
node
| node_id（主キー） | node_name | parent_node_id | tree_id | user_id |
|---|---|---|---|---|
| NODE-A1 | 動物 | TREE1 | USER1 | |
| NODE-A2 | 脊椎動物 | NODE-A1 | TREE1 | USER1 |
| NODE-A3 | 無脊椎動物 | NODE-A1 | TREE1 | USER1 |
| NODE-A4 | 哺乳類 | NODE-A2 | TREE1 | USER1 |
| NODE-B1 | Bar | TREE2 | USER2 |
user
すぐに利用する予定はないが、システムとして当然必要なので作成しておく。
| user_id（主キー） | user_name |
|---|---|
| USER1 | tarou |
| USER2 | jirou |
ER 図
感想
書籍「ユースケース駆動開発実践ガイド」には、先にシーケンス図から作成し、その後（その都度？）クラス図を整理する様に書かれていたが、私は先にクラス図を作成する方が好みだった。これは今までの経験に依存するのかもしれない。
ロバストネス分析が難しい。私が書いたロバストネス図は、アプリケーションのユースケースの細かい振る舞いは表現している。しかし、ここで作りたいのはバックエンドアプリケーションなので、「ボタンを押下する」などのコントローラーはシーケンス図を作成するためには不要だった。ロバストネス図からシーケンス図がかなり飛躍しているので、うまく活用できていないのだろう。正直ロバストネス分析は不要だと感じている。ICONIX プロセスに関する記事などを読むと、ロバストネス分析が ICONIX の肝である様に書かれてあったが、個人的には、以下のアウトプットでも（もちろん開発対象によるとは思うが）充分だと感じた。
どんなに小規模なアプリケーションであっても、ドメインモデルからアーキテクチャの検討までは実施したい。考慮できていない仕様に気付くことができるので有用だと思う。
これから
本当は書籍「Web APIの設計」を読んで API の設計をしたいのだが、お仕事が忙しかったのと体調不良で、プロトタイプ作成から時間があき過ぎている。そろそろ Java と Spring Boot の知識が脳内から消えていきそうなので実装に入ろうと思っている。
途中で変更するかもしれない。ChatGPT 先生に頼ることになりそうだ。
