我水也

われみずなり

最近やっている設計手法(ユースケース駆動開発)

毎度毎度、久しぶりの更新となりました。
先日プレスリリースを出し、最近会社でやっていることを公開できました。

prtimes.jp

まだまだ忙しくしていますが、ひと区切りついたこともあり、現在の会社での開発フローについて紹介したいと思っています。
長くなりそうなので、数回に分けて投稿したいと思います!

Growi

現在、設計ドキュメントの管理としてGrowiを活用しています。
MarkdownとPlantUMLがスムーズに使えるので、結構おすすめです。

growi.org

Growiは日本の WESEEK, Inc. さんという会社がOSSで開発しているWiKiソフトウェアで、ベースはCrowiらしいです。
Node.jsベースで開発されており、構築も簡単なのでサクッと導入できます。
弊社では、現在AWS上で運用しています。

先日、Atlassianが小規模チーム向けの無料サービスプランを展開していることを知って、すぐに使い始めたのですが、Confluenceについては、MarkdownとPlantUMLが標準で使えず(厳密にはMarkdown自体で書くことはできる)、プラグインでもなかなかスムーズな使い心地が出来なかったので、設計ドキュメントについてはGrowiを継続利用する予定です。

ユースケース駆動開発

ユースケース駆動開発」をベースに設計を進めています。

www.amazon.co.jp

ざっくりと解説すると、以下のような進み方です。

みたいな感じです。

ユースケース書いてみる

実際に書いてみるのが早いと思うので、今回はよくあるTODOアプリをケースとしてシリーズ化して書いていこうと思います。

今回のTODOアプリは簡単なものを想定しています。大体こんな感じのイメージです。

  • 一覧を表示する
  • TODOを登録する
  • TODOを削除する
  • TODOを完了する

これをユースケース図で表現するとこんな感じです。

f:id:matcu:20200524150541p:plain
usecase

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登録画面を表示していること

メインフロー

  1. システムは、TODO登録画面を表示する
  2. ユーザーは、やること、期限を入力する
  3. ユーザーは、登録ボタンを押す
  4. システムは、TODOを登録する
  5. システムは、登録完了画面を表示する

代替フロー

  • 入力内容に不備がある場合
    • システムは、フローを中断しエラーを通知する

ユースケースを書く利点

大事なことは、誰が何をすることで、どういったことが起きるのか?を明確に言語化して表現していきます。
この時点でプロダクトオーナーとシステムの動きをすり合わせることで、足りない機能や考慮していない部分がないか?の確認ができます。

ドメインモデル書いてみる

こんな感じのユースケースを書いていくと、こんなドメインモデルが出来上がります。

f:id:matcu:20200527141537p:plain
domainmodel

@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

次回は、このユースケースに沿って、ロバストネス図を書いてみたいと思います!