ユースケースリファクタリング/usecase-refactoring

Transcript

1. ユースケース リファクタリング 第３回astah勉強会関西 2019年10月23日(水) @tokudiro ユースケース リファクタリング
2. 自己紹介 兒玉 督司（こだま とくじ） 1996年より民生機器、携帯電話、生産機 器など、色々なソフトウェア開発に従事。 2002年頃よりアジャイル開発に興味を持 ち、「バグがないプログラムの作り方」 を共著。 現在は、組込＆オブジェクト指向のソフ トウェア開発のコンサルタントとして、 レガシーコード改善に奮闘中。
3. みなさん、 ユースケース、 覚えてますか？
4. みなさん、 ユースケース、 使ってますか？
5. ユースケースとは？ ユースケース（Use Case）は、ソフトウェア工学やシステム工学でシステム（あるいはシステムのシステム） の機能的要求を含む振舞を把握するための技法である。各ユースケースは、何らかの目的・目標/機能 に関する台本（シナリオ）での主体（アクター(actor)）と呼ぶ利用者（ユーザ）とシステムのやりとりを描い ている。ユースケースのアクターはエンドユーザーの場合もあるし、別のシステムの場合もある。ユース ケースでは技術専門用語をなるべく使わず、エンドユーザーやそのビジネスの専門家に分かり易い用語 を用いる。ユースケースの作成は、ビジネスアナリストとエンドユーザーが共同で行う。ユースケースを図 にしたものがユースケース図であり、両者を厳密に区別すべき根拠はない。 1986年、後に統一モデリング言語(UML)やラショナル統一プロセス (RUP) で重要な役割を演じたイ ヴァー・ヤコブソンは、初めてユースケースの視覚化モデリング技法を成文化した。当初彼は usage scenarios とか usage case という用語を使用していたが、それらが英語として不自然であると気づき use case という用語を使うようになった。ヤコブソンが創始したユースケースのモデリングに対して、Kurt Bittner、アリスター・コーバーン、Gunnar Overgaard といった人々が改良を加えていった。 1990年代、ユースケースは機能要求を含む振舞を把握する手法として使われるようになってきた。発祥 の分野であるオブジェクト指向関連で顕著である。ユースケースの有効性はオブジェクト指向に限らない。 ユースケースの仕様は、オブジェクト指向とは直接的な関係がない。 システム工学において、ユースケースはソフトウェア工学よりも抽象度の高いレベルで利用され、システ ムの任務やシステム保有者の目標を描くのに使われる。より詳細な要求は SysML のリクワイアメント図 などで把握される。 「ウィキペディア」より ( https://ja.wikipedia.org/wiki/ユースケース )
6. ユースケースとは？ ユースケース アクター ユースケース図 ユースケース記述 要求仕様を次の2つで明確にする。
7. (参考)他の要求仕様の書く方法  ユーザーストーリー  XDDPのUSDM  SysMLの要求図  SPLEのフィーチャーモデル  Excel  などなど いっぱいあるなぁ..
8. ユースケース実践ガイド 本書は、実際の開発プロジェクトにおいて、 ユースケースを書くための実践的な知恵、 ノウハウをまとめたものである。ユース ケースの表記法の解説書ではなく、表記 法をマスターした開発者が、実際のプロ ジェクトでユースケースを書く際に役に立 つ実践的なガイドである。UMLをひととおり マスターしている管理者、技術者に向けて 書かれているが、UMLを知らない方でも、 システムの要件分析の実践的ガイドとして も活用できる。コーバーン氏の今までの活 動を1冊の本にまとめたものであり、地に 足のついたプラクティスを体系的に説明。 ユースケースの入門を終えた技術者が、 プロジェクトで本当に使えるための知恵、ノ ウハウを学ぶための格好の一冊。 Amazon.co.jpより
9. ユースケースを作成 チェックリストで✔ ユースケースを修正 [✔が付かない] [全て✔済] どう修正するか もやもや・・・。
10. モデルを リファクタリングしてみては？
11. 仮説：少しでもやりやすくなるかも？ とりあえずのユースケースを作成 不吉な匂いを感知 ユースケースリファクタリング [まだ不吉な匂いがある] [よくなった！] チェックリストで✔ 小さくちょっとずつ改善
12. リファクタリングとは？ リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラ ムの外部から見た動作を変えずにソースコードの内部構造を整理することである。 また、いくつかのリファクタリング手法の総称としても使われる。ただし、十分に確 立された技術とはいえず、また「リファクタリング」という言葉に厳密な定義がある わけではない。 「ウィキペディア」より
13. リファクタリング この本はリファクタリングのガイドブックで す。系統だった効果的なリファクタリング 手法を説明しています。コード中にバグ を加えずに、ソフトウェアの構造を体系 的に改善できます。 Amazon.co.jpより
14. ユースケースへのリファクタリング適応 ユースケースへの リファクタリング適応 ソースコードのリファクタリングは、外部の振る舞いを変えず 内部の構造を変更すること。 ユースケースのリファクタリングは、外部・内部問わず、構造 を変更して要求仕様を理解しやすくするのが目的。
15. ユースケースリファクタリングカタログ
16. 1. ユースケースの削除 アクタに価値のないユースケースは、削除する。 当たり前のことなんですが、不要なユースケースは削除しましょうということ。 見るポイントは、ユースケース名や事後条件。 ユースケース アクター
17. 2.ユースケースの抽出 事後条件の異なるフローが1つのユースケースに書かれている。 代替フローを別のユースケースとして抽出する。 アクション アクション アクション アクション アクション アクション アクション ユースケース ユースケース1 ユースケース2
18. 3.ユースケースの結合 事後条件の同じフローが2つのユースケースに書かれている。 同じのユースケースとして結合する。 アクション アクション アクション アクション ユースケース ユースケース1 ユースケース2 アクション アクション アクション
19. (参考)個々のリファクタリングの相反関係 「Refactoring Second Edition」より
20. 4.ユースケースの抽象化 似たようなユースケースを、ひとつに纏められないか検討する。 似たような手順のフローで基本フローしかないようなユースケースがたくさん出た 時、それらはシステムが同じサービスを提供しているのかもしれません。 「ユースケース実践ガイド」にあるように、「なぜ？」を問うと良いかもしれません。
21. 5.ユースケースの具象化 事前条件が複雑なユースケースは、複数に分けられないか検討する。 事後条件が抽象的でシステムの提供サービスが理解しづらいかもしれません。 ユースケースを元にテストを実施するとした場合、事後条件の確認が簡単である かが判断基準となります。 「ユースケース実践ガイド」にあるように、「どのように？」を問うと良いかもしれま せん。
22. (参考)ユースケースの目的レベル 「ユースケース実践ガイド」より
23. 6.共有利用されたユースケースを フロー内のステップへ移動 ユースケース記述に1行程度しか書かれていない基本フローがあり、このユース ケースが複数の箇所から利用(include)されている場合、利用している側のユー スケースでフロー中の1ステップに記述できないか検討する。 アクター ユースケース2 ユースケース3 ユースケース4 ユースケース5 ユースケース1 ユースケース7 <<include>> <<include>> <<include>> <<include>> <<include>> これ要らない のでは？
24. 7.基本フローと代替フローの入替 代替フローの方が、事後条件を達成するのにシンプルな場合、基本フローと入れ 替える。
25. 8.データ更新による include関連の削除 あるユースケースが内部データを更新し、その更新をもって起動されるユース ケースは、include関連をつけてしまう。しかし、前者のユースケースと後者のユー スケースの役割(サービス)が異なるならば、include関連を結ぶ必要はない。 ユースケース記述に内部データのことは、書かれているはずである。ユースケー スは役割(サービス)を見出すために書かれているはずが、データを抽出し機能を 抽出するDFDを書くことになってしまっている。 アクター アラームが鳴る 目覚ましをセット する タイマー 目覚ましをセット する アクター アラームが鳴る <<include>>
26. 9.ユースケースを非機能要求へ移動 ログ出力のユースケースなどの製品特有の機能でないユースケースは、非機能 要求とする。 こうすることで、ユースケース図の可読性を高め、システムの全体像を捉えやすく する。無駄なincludeの線も消すことができ、ユースケース図がすっきりとする。 無理に非機能要求をユースケースで書かない。
27. (参考)FURPS 機能性 (Functionality) 機能（機能セットのサイズと一般性）、再利用性（互換性、相互運用性、 移植性）、セキュリティ（安全性と悪用性） ユーザビリティ （Usability） 人的要因、美学、一貫性、ドキュメンテーション、応答性 信頼性 (Reliability) 可用性（障害頻度（堅牢性/耐久性/復元力）、障害の範囲と期間（回 復可能性/生存可能性））、予測可能性（安定性）、精度（頻度/エラー の重大度） パフォーマンス (Performance) 速度、効率、リソース消費（電力、RAM、キャッシュなど）、スループット、 容量、スケーラビリティ サポート性 (Supportability) テスト容易性、柔軟性（可換性、構成可能性、適応性、拡張性、モ ジュール性）、インストール可能性、ローカライズ可能性 「wikipedia」より 非機能要求
28. 10.数値名称によるマジックナンバー の置き換え 数値がそのまま記述されている箇所は、本来なにかの変数である可能性があり ます。 システムが変更された場合、分析や設計でも定数や変数として定義されることに なります。数値のままにせず、数値名称を記載しましょう。どうしても数値も記載し たい場合は、備考欄に記載します。
29. 11.重複するフロー内のステップを共 有利用するユースケースへ移動 複数のユースケースのユースケース記述に重複するステップがある場合、まと めて共有利用するユースケースにできないか検討する。
30. ユースケースリファクタリングカタログ (拡張編)
31. (参考)ユースケース拡張 拡張点 extension points ユースケース サブユースケース <<include>> 拡張ユースケース <<extend>>
32. 12.拡張ユースケースの削除 不要な拡張ユースケースは削除する。 あまり拡張ユースケースを使わない方がよい。
33. 13.拡張ユースケースの代替フロー化 拡張予定のないユースケースは、代替フローとしてベース側のユースケースへ 組み込む。
34. 14.拡張ユースケースの抽出 拡張予定のある機能は、拡張ユースケースを追加する。
35. 15.代替フローのユースケース化 拡張予定のあるフローは、拡張ユースケースに変更する。
36. (参考)フィーチャーモデルを ユースケースで表現する https://www.atmarkit.co.jp/fdotnet/softfactory/softfactory03/softfactory03_02.html フィーチャモデルのサンプル 購入者 分析 extension points 書籍を購入する 分類 extension points カタログを管理する <<include>> 注文を処理する <<include>> カタログを検索する <<include>> カタログを分類する <<extend>> 決済 extension points 課金を処理する <<include>> データ分析をする <<extend>> クレジット決済を する <<extend>> 現金決済をする <<extend>> ユースケースでの表現
37. 課題 • せっかくリファクタリングなのに、自動テストできない、目視するしかない • 細かく修正するので時間がかかる？ • そもそも最近ユースケース使わないないぁ。
38. 参考文献 「リファクタリング～プログラミングの体質改善テクニック」 マーチン・ファウラー著 (翻訳)児玉公信, 友野晶夫, 平澤章, 梅澤真史 「ユースケース駆動開発実践ガイド～効果的なユースケースの書き方」 ダグ・ローゼンバーグ, マット・ステファン著 (翻訳)三河淳一, 佐藤竜一, 船木健児
39. ユースケース図の別の使い方 レガシーコード改善の一環で、C言語の関数コールに使ってます。 sample1.c function2 function1 function3 sample2.c function4 function5 function6 この関数は共通 関数として別 ファイルにした 方がよさそう