UseCaseMaps

UseCaseMaps(以後UCMs)は、オブジェクト指向技術の弱い点でかつリアルタイムシステムの設計を進める上で効果的なノーテーションを提案していますが、これはまた、ソフトウェアプロダクトライン開発において、複数の製品／サービスを横断するシナリオを明確に定義する際に用いることができます。これまで、複数の製品群を対象に要求を分析し、機能に落とし込んでいく部分について、効果的な開発技法が整備されておりませんでした。極論すれば、Validationに関する理解／スキル不足により、一つのシステムを無事に開発することがフォーカスされているのです。ここでは、複数の製品／サービス、派生を伴う開発の超上流における、UseCaseMapsの利用方法について示していきます。

サービスとは？

「サービス」という言葉は使われる場合により意味が異なる。曖昧さを排除するため、ここではユーザが直接享受するメリットを持つユースケースである、と定義する。例えば、製品(プロダクト)が単体で機能を提供する場合、製品に対してユーザをアクタしてみたときのユースケースがそのままサービスとなる。

一方、製品についてサービス提供の変遷をみてみると、製品は単独の製品で機能提供するところから始まっている。洗濯機、炊飯器、給湯器などは作業代行を、冷蔵庫、電子レンジなどはNeedsへの対応がサービスにあたる。

また、サービスの内容が共通認識となると、サービス自体に変化が起こる。製品を開発する側はそれぞれのドメイン知識を蓄積し独自の深化を遂げ、製品としてのサービスを提供する。

昨今の製品は単独での機能提供だけでなく、外部機器、カスタマサポートなどと接続し、(そのドメインにとっては)新たなサービス提供も行われている。デジタルテレビでは、番組表を提供したり、製品の自動補修(ソフトウェアの自動更新)も行われていたりしている。

デジタルテレビのユースケースを例にしてサービスと機能を確認する。

「番組表」や「製品の自動補修」はデジタルテレビのユースケースである。ユースケースはアクタにとってのサービスそのものである。これよると、「番組表」に関してデジタルテレビ単体のユースケースは「番組表を取得する」、「番組表を保存する」、「番組表を表示する」があげられるが、アクタがユーザであるものは「番組表を表示する」ユースケースだけとなる。

※本節では「サービス」を次のように定義した。

サービスはエンドユーザが直接享受するメリットを持つユースケースである。

サービス開発プロセス

サービスは粒度の大きいユースケースの１つである、との定義から、サービス開発プロセスはユースケースを実現するシステムの開発を考えればよい。開発プロセスを以下の図に表す。

以下(TBD)