【連載】概念モデリングを習得しよう：概念モデルから考える、より良い「ユースケースモデル」（第25回）

筆者が概念モデリングのベースになっている Shlaer-Mellor 法の習得にいそしんでいた、1990年代後半は、開発方法論戦争の時代でした。当時、コードヨードン法、Booch法、OMT法、そして、Shlaer-Mellor法が四大手法とされ、それぞれ異なる主張を繰り広げて開発者を惑わせていました。今ならば、

• コードヨードン法 ＝ 良きオブジェクト指向プログラミングを目指した手法
• Booch法 ＝ システムアーキテクチャ論
• OMT法 ＝ 単なる表記法
• Shlaer-Mellor法 ＝ 概念モデリング×変換による設計・実装論

であると明確に筆者は認識できるのですが、当時はインターネットが発達した今とは異なり情報も少なく惑うばかり。いやぁ…大変でした。なにしろ、当時はC++や Java といったオブジェクト指向プログラミング言語がようやく普及しだした時代で、要求分析、アーキテクチャ設計、プログラミングに関するプラクティスがごっちゃ混ぜになって語られていましたから。

そんなあまたの手法が提唱されていた1990年代後半、比較的後発組でしたが、ユースケース駆動型開発なるものが、普及しだしました。

その後、.NET Framework という本格的なコンポーネントベースの実行環境やオブジェクト指向をはじめとするプログラミング言語や、Visual Studio など開発環境の進化が進み、コードヨードン法は忘れ去られたものの、OMT法は UML に昇華（？）し、Booch法やその他の技法が混ざり合って RUP（Rational Unified Process）が出来上がりました。Shlaer-Mellor 法は UML の表記を取り入れて xtUML（eXecutable and Translatable UML）と名称を変えました。この辺りの名称、今となっては、昔から開発方法論に携わってきた年齢層高めの技術者か、よほどのマニアにしか知られていないと思いますが。

一方で、ユースケースという言葉は、システム開発に携わっている技術者ならだれでも知っているように感じます。ざっくりいうと、システムが提供する機能の単位を利用者目線で捉えたのがユースケース、明確に記述したユースケース集を基にシステムを開発するのがユースケース駆動型開発です。

モデリング言語の国際標準である、UML（Unified Modeling Language）の仕様書には、ユースケースの定義が以下のように書かれています。

UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase’s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors.

A UseCase is a specification of behavior. An instance of a UseCase refers to an occurrence of the emergent behavior that conforms to the corresponding UseCase. Such instances are often described by Interactions.

UML Specification 2.5.1 18章から抜粋

ユースケース（UseCase）は、利用者から見たシステムの振舞いの仕様であり、利用者をアクターと呼ぶことになっています。ユースケース群（UseCases）を記述することは、システムに対する要求仕様を捕捉することだそうです。

アクターをスティックフィギュアで、ユースケースは楕円形で、システム境界を四角形で、それぞれ名前をつけた図で表記します（図表1）。

アクターとユースケースを結ぶ線は、多重度が付与された関連（Association）であり、アクターとユースケースの相互作用を表します。このような形式でユースケース群を記述した図のことをユースケース図といいます。

“An instance of a UseCase referes …”の文面から、ユースケース図で描かれたモデルは、概念情報モデルと同様、スキーマである圏Cのモデルであり、ユースケース図をひな型にした、個別の、アクターによるユースケースの駆動の様相が圏Iのモデルといえるでしょう。

強制ではないようですが、ユースケースが駆動されたときの振舞いは、ステートモデルで記述できるようです。

他に、UML の仕様では、ユースケースの内部構造を明記する、他のユースケースの Include 関連や、あるユースケースの機能を別のユースケースで拡張する Extend という関連も仕様として用意されています。

一通りユースケース概要の紹介が終わったところで、概念モデリングからのユースケースに対する考察と、概念モデリングの考え方を活用した、より良いユースケースの書き方について、私見を述べておこうと思います。図中の楕円をユースケース、アクターとの関連やシステム境界も含めた描かれた図をユースケース図と、“ユースケース”という単語がやたらと使われていて煩雑なので、ここでは、図の記述が意味している内容のことをユースケースモデルと呼ぶことにします。

概念モデリングでは、ただ一つの“意味の場”に対して、それぞれの概念モデルを作成します。モデル化の対象となった“意味の場”は、出来上がった概念モデルによって厳密に記述されることになります。概念モデルにより厳密に定義されるのは“意味の場”のスキーマであり、それが“概念ドメイン”です。

また、システム構築には、常に複数の意味の場が必要になるので、その数だけ概念モデリングを行います。結果として、システム構築は、複数の概念モデルを掛け合わせになります。複数の意味の場の掛け合わせの結果がシステムとなるため、 “システム境界”というものが、概念モデリングにおいては、明確にはモデルとして重視されません。“システム境界”というからには、何らかの二つの領域があることが前提になっているはずです。システム側を“領域S”、ユーザー側を“領域U”としましょう。 “アクター”は領域Uに属するものと考えて間違いありません。しかし、アクターが持つ役割は、領域Sが想定している役割のはずです。意味の場を通じて観る世界という観点からすると、その役割は領域Sの意味の場に属していると考えられるので、この分割は不自然にも思えます。

とはいえ、概念モデルで記述された意味の構造と振舞いが、機能的な観点で外からどう見えるかを明示したい場合には、ユースケースモデルは役立ちそうです。もしかすると、プロジェクトの開発プロセスとして、ユースケース図を描くことを必須として要請されるケースもあるかもしれません。

概念モデリングにおいて、

• 概念ドメインの境界＝システム境界（システム化の対象を一つの意味の場と考える）
• ドメインファンクション＝ユースケース
  　▶情報に関する問い

  　▶圏I に対する同期的操作

  　▶圏Iへのイベント生起

と考えれば、概念モデルからユースケースモデルの導出が可能です。アクターは、それぞれのドメインファンクションの利用者を想像して適当に決めれば十分でしょう。

このようなやり方でユースケース図を描くと、

• 図で使われている単語の意味
• 状態に依存したユースケースの挙動
• 複数のユースケースが同時並行的に起動されたときの競合発生

に関する曖昧さを排除できるというメリットが生まれます。

例えば、図表1（UMLの銀行のATM）の“Withdraw”は、“お金を口座から引き出す”ことですが、口座の残金によって振舞いは変わるでしょうし、残金にしても給与の振込やクレジット払いの自動引き落としが同時並行的に発生するでしょう。これらは限られた資源に対する競合が生じるシナリオなので、ただ単に項目を羅列することに意味はないでしょう。そもそも私がここで書いている内容が図表1上の“Withdraw”と意味が同じである保証もありません。

システム開発は問題解決の手段にすぎません。基本に立ち返ると、問題を把握し記述するためには、問題の対象となっている世界への理解が必要です。

もしかすると、ユースケース駆動型開発の提唱者のイヴァー・ヤコブソンやアリスターコバーンにとって、システム構築において、システム化対象の世界の理解ができていることは、あまりにも当たり前すぎて、トピックとして取り上げなかったのかもしれません。

もしくは、UML にはクラス図があり、それを使って意味論的なモデルを作るのは当たり前だということかもしれません。

現実世界（圏I）の意味のスキーマである概念情報モデルを基盤とし、その意味の構造を眺めて、どのようなシナリオが生まれるのかを考えること、それが、概念モデリング流のユースケース活用術です。それぞれのシナリオはユースケースとして、概念情報モデル上の意味の定義をもとにしてドメインファンクションとして厳密に記述されることになります。

ここまで説明してきたことは、システム化対象の世界をユースケース的な観点で眺める時のプラクティスに関するものであり、システム境界を明確化するというユースケース図の役割を否定するものではないことにご留意ください。

もっとも、意味が曖昧なままの単語がちりばめられた図に対した意味があるとは思えませんが。

以上、実際のシステム開発の場でよく出会う、リファクタリングやユースケースモデルも含めて、概念モデリングを解説してきました。

次回は、これまで解説してきた概念モデリングの道具立てをあらためて整理し、概念モデルを問題解決に役立てるうえで重要な「検証可能性」についても考察します。