Ruby on Rails によるシステム開発をモデリングで効率的に行う

• 概要編
• 分析・設計編（ユースケース図とユースケース記述）
• 分析・設計編（フィーチャモデリング）
• 分析・設計編（フィーチャと解決領域のマッチング）
• 分析・設計編（ER 図）
• 分析・設計編（ER 図の実践）
• 実装編（モデルを実装に落とし込む）
• まとめ

ユースケース図とユースケース記述

それでは、実際にユースケース図とユースケース記述を紹介します。

ユースケース：ブログ記事を閲覧する

アクター：ユーザー
概要：
このユースケースによって、ユーザーはブログに投稿された記事を
閲覧することができる。ユーザーはログインなどの動作を一切行う
必要はない。

事前条件：なし
事後条件：なし

シナリオ：
ユーザーはブログの「トップページ」にアクセスすると、システムは
ブログ記事の一覧を表示します。ユーザーが記事を選択すると、
システムは「記事詳細ページ」を表示します。

ユースケース：ブログ記事を投稿する

アクター：ライター
概要：
このユースケースによって、ライターは記事を投稿することが
できる。記事の投稿には、ログインが必要である。

事前条件：本システムにログインしている必要がある
事後条件：なし

イベントフロー：

1. メインフロー
1.1 ブログ記事を投稿する
1.1.1 ライターは本システムにログインする
1.1.2 システムは「ブログ記事管理画面」を表示する
1.1.3 ライターは「記事を投稿する」を選択する
1.1.4 システムは「ブログ記事投稿画面」を表示する
1.1.5 ライターは必要項目を入力する
1.1.6 システムはブログ記事を保存し、「ブログ記事管理画面」を表示する

ユースケース：ブログ記事を公開する

アクター：ブログ管理担当者
概要：
このユースケースによって、ブログ管理担当者は記事を公開することができる。

事前条件：本システムにログインしている必要がある
事後条件：なし

イベントフロー：

1. メインフロー
1.1 ブログ記事を公開する
＜＜本記事では省略＞＞

本連載では省略しますが、ユースケース記述中でカッコで囲った画面は、画面プロトタイプを作成します。また、ユースケースとして抜き出すべきものには、下線を引っ張りました。

シナリオは自由な書式ですが、イベントフローはシステムとアクターの掛け合いになっていることに注意してください。一般的なウェブアプリケーションはイベントフローが記述しやすいでしょう。

しかし、Ajax などを使用した場合、イベントフローではユーザーとシステムのコミュニケーションを表現しにくい場合があります。この場合は簡単なシナリオで済ませてしまうことも手です。Ruby on Rails では、画面の作り込みも試行錯誤する方が効率的な場合があります。形式に沿った完全なドキュメントも良いですが、早くレールに乗ることを検討してください。

そのほかの特性の検討

本連載では対象とはしませんが、ウェブアプリケーションでは「携帯」や「PC」というように機器によって開発項目が変わります。このような場合は、ユースケースにバリエーションを作成します。以下に例を示します。

その他、機能外要求もリストアップしておきましょう。アクセス集中に対する耐性、連続稼働時間に対する要求、システムの復旧に関する要求など様々な要求があります。案件によっては「とりあえず動けばよい」という場合もあります。案件に応じて、どれくらい要求を書きだすのか判断してください。

以上、ユースケースの作成は完了です。モデリングと言っても、絵を描くのは一瞬で、文字情報が多いことに気が付きましたでしょうか。モデリングと言っても、お絵描き「だけ」が重要なわけではないことに注意してください。また、「とりあえず書いた」ものは役に立ちません。ユースケースモデリングは「何を作るのか把握する」ために実施していることを忘れないようにしてください。

おそらく、ユースケース記述をどれくらい詳細に書けばよいのか、迷う人が多いかと思います。画面やユースケースの漏れがなくなった時点でユースケース記述を書く手を止めて、次の工程へ移るのも一つ手です。ユースケース記述の詳細度はそのシステムに期待される品質要求などによって変わってきます。重大なシステムなら詳細に、それほどでもないのなら相応な詳細度で書きだしてください。

今回は、「何を作るのか」に注目したモデリングを行いました。次回は「どうすれば少ないコストでシステムを作れるか」という点に注目したモデリングを紹介します。それでは！