Use Case Refactoring

Use Cases Refactoring

以前に書いたメモを記録に残す。
最近は、ユースケースを書くことも少なくなったし、あまり役に立たないかも。

動機

ユースケースを作成したり、レビューしたりしていく中で、コードのリファクタリングのように行うことができないかというアイデアから、とりあえずリファクタリングカタログを作成してみた。

リファクタリングカタログ(基本編)

1-1.ユースケースの削除(Delete Use Case)

アクタに価値のないユースケースは、削除する。

1-2.ユースケースの抽出(Extract Use Case)

事後条件の異なるフローが1つのユースケースに書かれている。代替フローを別のユースケースとして抽出する。

1-3.ユースケースの抽象化(Abstract Use Case)

似たようなユースケースを、ひとつに纏められないか検討する。似たような手順のフローで基本フローしかないようなユースケースがたくさん出た時、それらはシステムが同じサービスを提供しているのかもしれません。

1-4.ユースケースの具象化

事前条件が複雑なユースケースは、複数に分けられないか検討する。事後条件が抽象的でシステムの提供サービスが理解しづらいかもしれません。ユースケースを元にテストを実施するとした場合、事後条件の確認が簡単であるかが判断基準となります。

1-5.共有利用されたユースケースをフロー内のステップへ移動

ユースケース記述に1行程度しか書かれていない基本フローがあり、このユースケースが複数の箇所から利用(include)されている場合、利用している側のユースケースでフロー中の1ステップに記述できないか検討する。

1-6.基本フローと代替フローの入替

代替フローの方が、事後条件を達成するのにシンプルな場合、基本フローと入れ替える。

1-7.データ更新によるinclude関連の削除

あるユースケースが内部データを更新し、その更新をもって起動されるユースケースは、include関連をつけてしまう。しかし、前者のユースケースと後者のユースケースの役割(サービス)が異なるならば、include関連を結ぶ必要はない。ユースケース記述に内部データのことは、書かれているはずである。ユースケースは役割(サービス)を見出すために書かれているはずが、データを抽出し機能を抽出するDFDを書くことになってしまっている。

1-8.ユースケースを非機能要求へ移動

ログ出力のユースケースなどの製品特有の機能でないユースケースは、非機能要求とする。こうすることで、ユースケース図の可読性を高め、システムの全体像を捉えやすくする。無駄なincludeの線も消すことができ、ユースケース図がすっきりとする。

リファクタリングカタログ(記述編)

2-1.数値名称によるマジックナンバーの置き換え

数値がそのまま記述されている箇所は、本来なにかの変数である可能性があります。システムが変更された場合、分析や設計でも定数や変数として定義されることになります。数値のままにせず、数値名称を記載しましょう。どうしても数値も記載したい場合は、備考欄に記載します。

2-2.重複するフロー内のステップを共有利用するユースケースへ移動

複数のユースケースのユースケース記述に重複するステップがある場合、まとめて共有利用するユースケースにできないか検討する。

リファクタリングカタログ(拡張編)

3-1.拡張ユースケースの削除(Delete External Use Case)

要求分析などの結果から、不要な拡張ユースケースは削除する。

3-2.拡張ユースケースの代替フロー化(Change External Use Case to Altanative Flow)

要求分析などの結果から、拡張予定のないユースケースは、代替フローとしてベース側のユースケースへ組み込む。

3-3.拡張ユースケースの抽出(Extract External Use Case)

要求分析などの結果から、拡張予定のある機能は、拡張ユースケースを追加する。

3-4.代替フローのユースケース化

要求分析などの結果から、拡張予定のあるフローは、拡張ユースケースに変更する。

参考文献

• ユースケース実践ガイド(Writing Effective Use Cases)
• リファクタリング ～プログラミングの体質改善テクニック (Refactoring:Imporving The Design of Existing Code)