最近やっている設計手法(ユースケース駆動開発)
毎度毎度、久しぶりの更新となりました。
先日プレスリリースを出し、最近会社でやっていることを公開できました。
まだまだ忙しくしていますが、ひと区切りついたこともあり、現在の会社での開発フローについて紹介したいと思っています。
長くなりそうなので、数回に分けて投稿したいと思います!
Growi
現在、設計ドキュメントの管理としてGrowiを活用しています。
MarkdownとPlantUMLがスムーズに使えるので、結構おすすめです。
Growiは日本の WESEEK, Inc. さんという会社がOSSで開発しているWiKiソフトウェアで、ベースはCrowiらしいです。
Node.jsベースで開発されており、構築も簡単なのでサクッと導入できます。
弊社では、現在AWS上で運用しています。
先日、Atlassianが小規模チーム向けの無料サービスプランを展開していることを知って、すぐに使い始めたのですが、Confluenceについては、MarkdownとPlantUMLが標準で使えず(厳密にはMarkdown自体で書くことはできる)、プラグインでもなかなかスムーズな使い心地が出来なかったので、設計ドキュメントについてはGrowiを継続利用する予定です。
ユースケース駆動開発
「ユースケース駆動開発」をベースに設計を進めています。
ざっくりと解説すると、以下のような進み方です。
みたいな感じです。
ユースケース書いてみる
実際に書いてみるのが早いと思うので、今回はよくあるTODOアプリをケースとしてシリーズ化して書いていこうと思います。
今回のTODOアプリは簡単なものを想定しています。大体こんな感じのイメージです。
- 一覧を表示する
- TODOを登録する
- TODOを削除する
- TODOを完了する
これをユースケース図で表現するとこんな感じです。
PlantUMLで書くとこんな感じです。
@startuml usecase actor ユーザー as User usecase "一覧を表示する" as ShowTodoList usecase "TODOを登録する" as RegisterTodo usecase "TODOを削除する" as RemoveTodo usecase "TODOを完了する" as CompleteTodo User -down- ShowTodoList ShowTodoList ..> RegisterTodo : <<Invokes>> ShowTodoList ..> RemoveTodo : <<Invokes>> ShowTodoList ..> CompleteTodo : <<Invokes>> @enduml
ユースケースとしては、こんな感じで書いていきます。
TODOを登録する
概要
- ユーザーがTODOを作成する際に、利用される
アクター
- ユーザー
事前条件
- ユーザーは、TODO登録画面を表示していること
メインフロー
- システムは、TODO登録画面を表示する
- ユーザーは、やること、期限を入力する
- ユーザーは、登録ボタンを押す
- システムは、TODOを登録する
- システムは、登録完了画面を表示する
代替フロー
- 入力内容に不備がある場合
- システムは、フローを中断しエラーを通知する
ユースケースを書く利点
大事なことは、誰が何をすることで、どういったことが起きるのか?を明確に言語化して表現していきます。
この時点でプロダクトオーナーとシステムの動きをすり合わせることで、足りない機能や考慮していない部分がないか?の確認ができます。
ドメインモデル書いてみる
こんな感じのユースケースを書いていくと、こんなドメインモデルが出来上がります。
@startuml domainmodel hide circle hide method mix_actor "ユーザー" as User class "TODO" as Todo { やること 期限 完了 } class "TODO一覧" as TodoList User o- Todo TodoList o- Todo @enduml