手順の6番目はUMLで規定されていませんが、業務フローと概念クラス図の整合性を取るために行っています。業務フローを記述するということは、概念クラス図を検証するということでもあります。業務フローを記述した結果、必要な情報が概念クラス図になければ追加します。業務フローに一度も現れない概念がある場合は、その概念の必要性を検討します。業務フローと概念クラス図の整合性を意識してモデリングすることにより、モデル間にフィードバックが行われ、より正確なモデル構築が可能になります。業務分析の段階で正確なモデルを構築することは、要件定義や設計を正しく行う上で極めて重要です。
業務フローを記述する際に、アクティビティーをどの単位でまとめればいいか分からないということがよく問題になります。同様に、システムユースケースの粒度についても、どの単位にすればいいか分からないという話をよく聞きます。
システムユースケースの粒度に関する指針と、業務フローのアクティビティーの粒度は、以下のようにある程度対応しています。
システムユースケースの粒度に関する指針 | 業務フローのアクティビティー粒度に対応させると…… | |
---|---|---|
アクターにとっての価値(意味ある結果)を提供する | ×作業者に必ずしも価値を提供しない | |
アクターをまたがらない | ○作業者をまたがらない | |
ユースケースとユースケースの合間に休憩できる(数分空いても問題ない) ※このような検証をコーヒーブレークテストといいます。 |
○同じ役割の別の人に引き継げる(自分は休憩できる) | |
ユースケースのステップを意識して、共通化・抽象化する | ×作業で抽象化はしない(共通項をまとめるなどを行わない) | |
条件や振る舞いが共通なものは1つにくくり、異なるものは分ける | ○条件や振る舞いが共通なものは同じ名前にし、異なるものは別の名前にする | |
表中の「休憩(coffee break)」というのは、ユースケースの粒度に関する1つの基準で、そこまでは一息で行わなければならない作業(中断すると半端な作業になる)ですが、それが終われば休憩してコーヒーを飲みに行っても構わないという作業の切れ目を意味します。システム的な表現を使えば、ユースケースは、アクターにとっての1トランザクションの作業(コミットまでで意味を持つ、ひとまとまりの作業)ということになります。
ある業務フローを表現する際に、何通りかの描き方がある場合、その中の一番シンプルなもので表現するべきです。これについては、業務フローに現れる特徴的な振る舞いをパターンとしてまとめたワークフローパターンが参考になります。
ワークフローパターン2003年に第1版が定義され、その後、さまざまなワークフローエンジンがこのパターンを実行できるように実装されています。つまり、ワークフローパターンで描かれた業務フローは、システム化しやすい業務フローということになります。
余談ですが、業務フローを改善する「業務フローリファクタリング」という考え方について、以前記事を書きましたので、紹介させてください。
この手順でスイムレーンをきちんと書くことを重要視しているのは、後続のユースケースモデルの作成作業において、アクターを抽出する作業に使用するからです。では次に、ユースケースモデルの作成について見ていきましょう。
Copyright © ITmedia, Inc. All Rights Reserved.