初歩のUML　第6回 「関連」の理解をさらに深める,,,,,,,,,, ,http://www.itmedia.co.jp/im/articles/0305/02/news001.html,,,,,,,,, ,,,,,,,,,, ,■クラス間の関連の数は１つ？,,,,,,,,, ,,,,,,,,,, ,,　今まで使ってきた例では、２つのクラス間の関連の線は１つでしたね。しかし、２つのクラス間の関連が１つにな,,,,,,,, ,,るとは限りません。例えば、店舗の売上を集計するシステムのモデルを考えてみましょう。店舗はその日の売上,,,,,,,, ,,を持つようにします。売り上げの細かな構造については、とりあえず保留にしておきましょう（図１）。,,,,,,,, ,,,,,,,,,, ,,　しかし、その日の売上を持つということを満たしただけで、果たしてこのシステムの要求を満たせるのでしょうか,,,,,,,, ,,？例えば、月次売上はどうなるのでしょう。また、「月次ABC分析」（ABC分析：商品の管理手法の一つ。ABCの３,,,,,,,, ,,ランクに分けてAランクを最重点商品として管理する）などを行うためには、月次、年次レベルで売り上げを持つ必,,,,,,,, ,,要があります。では、売上を日次だけではなく月次、年次レベルも含めて保持するようにすればいいと考えますよ,,,,,,,, ,,ね。ところが、店長から次のような要求が出てきたらどうしますか？（図２）,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,図２　店長は語る,,,,,,,, ,,,,,,,,,, ,,　なるほど店長の言い分もごもっともです。さて、皆さんならこのモデルをどうしますか。私ならば、まずお客さん（,,,,,,,, ,,店長）からこのような要求が出た時点で、モデルをとりあえず図３のように変更します（注１）。,,,,,,,, ,,,,,,,,,, ,,　図３には、２つのクラス間に２つの関連が引かれています。そして、それぞれの関連は、「売り上げを管理する」「,,,,,,,, ,,履歴を管理する」という異なる意味が付与されています。このように、２つのクラス間には異なる意味を持ついくつ,,,,,,,, ,,かの関連を引くこともあります。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,（注１）,,,このようにお客さんから要求を聞きながら大まかなシステムの概念構造をモデルとして整理していく,,,, ,,,,,,作業を分析モデルといいます。しかし、実際のプログラムコードに落とすには、もっと詳細なクラス図,,,, ,,,,,,を書く必要があります。このようなモデルを設計モデルといいます。分析モデルと設計モデルの詳細,,,, ,,,,,,な説明についてもこの連載で取り上げる予定ですのでお楽しみに。,,,, ,,,,,,,,,, ,■自己再帰的な関連,,,,,,,,, ,,,,,,,,,, ,,　次は、図３のモデルを大規模な商店のモデルとして考えてみましょう。それぞれの売り上げは、「食品部」「衣服,,,,,,,, ,,部」などといった部門によって管理されるとしましょう。その場合、図４のように店舗と売り上げの間に部門を入れ,,,,,,,, ,,たモデルで表現できます。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,　さて、ここからが少し複雑な問題となります。店長が次のようなことを言い始めました。,,,,,,,, ,,,,,,,,,, ,,　「この部門には、衣服部門の中に子供服、紳士服、婦人服といったサブ部門が必要なんだ。また、サブ部門を持,,,,,,,, ,,たない部門もあるぞ。さらには、サブ部門のそのまたサブ部門が必要かもしれない」,,,,,,,, ,,,,,,,,,, ,,　うーむ。難しい注文ですね。部門とサブ部門があり、サブ部門がいくつ存在するか分からないとは、・・・どうしま,,,,,,,, ,,しょう。,,,,,,,, ,,,,,,,,,, ,,　これを端的にモデル化することはできないものでしょうか。そこで、まずはこの問題をオブジェクト図を使って表,,,,,,,, ,,現してみましょう（図５）。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,　いかがでしょう？図５のモデルからクラス図がイメージできますか？「部門が部門を持つようにすればよいので,,,,,,,, ,,は？」という意見もありますね。そういう場合は、部門が部門を持つ構造を作成すればよいのです（図６）。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,　しかし図６は何か変だと思いませんか？,,,,,,,, ,,,,,,,,,, ,,　そうですね、１つのクラス図の中に、部門クラスが２つ存在するのはクラス図ではルール違反です。また、このモ,,,,,,,, ,,デルのままでは部門は１階層までで、それ以上の階層が存在することはできませんので、店長の考えを反映した,,,,,,,, ,,とは言えません。,,,,,,,, ,,,,,,,,,, ,,　正解は、「部門が部門を構成する」ということを、部門クラスが同じ部門クラスを集約するように表せばよいので,,,,,,,, ,,す。図７にクラス図を示します。これで、部門の階層かについても、ちゃんと表現できるようになりました。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,■対象問題をしっかりと分析する,,,,,,,,, ,,,,,,,,,, ,,　「売り上げ」については、売り上げクラスということで、かなり大雑把にモデル化していました。次は、この部分に,,,,,,,, ,,ついてもう少しまじめに分析してみましょう。,,,,,,,, ,,,,,,,,,, ,,　物事を深く分析するためには売り上げというものがどのような構造になっているかを考察する必要があります。,,,,,,,, ,,しかし、売り上げを考察するといっても漠然としてイメージがわかないでしょう。そこで、筆者がお勧めするのが、,,,,,,,, ,,リアルな「もの」をイメージしながらモデリングする方法です。つまり、実世界にあるリアルな「もの」をまずイメー,,,,,,,, ,,ジすることから始めるのです。リアルな「もの」とは、具体的に印刷されたものとか、表示されているものとか、,,,,,,,, ,,実際に目で見える「もの」を想像することです。,,,,,,,, ,,,,,,,,,, ,,　この例では、お店に行って売上を端的に表しているリアルなものは何かを考えましょう。売り上げには取引とい,,,,,,,, ,,う行為が伴います。この取引という単位で売り上げをとらえるというのはビジネスの鉄則です。そこで、店と客の間,,,,,,,, ,,の取引を行った結果として残るレシートを、リアルな「もの」としてイメージしてみるのです（図８）。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,図８　レシートのイメージ,,,,,,,, ,,,,,,,,,, ,,　レシートのイメージ（図８）をよく見ると、品目と個数と金額が繰り返し表示されている部分があります。まずはこ,,,,,,,, ,,こに着目します。,,,,,,,, ,,,,,,,,,, ,,□繰り返されている部分をほかのクラスに分解する,,,,,,,, ,,,,,,,,,, ,,,　もしこのように繰り返されている部分が存在する場合は、ほかのクラスに分解し、コンポジション（または集約,,,,,,, ,,,関係）として表現します。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,図９　繰り返し部分をほかのクラスにし、コンポジションとして表現,,,,,,, ,,,,,,,,,, ,,□ライフサイクルが異なる部分をほかのクラスに分割する,,,,,,,, ,,,,,,,,,, ,,,　次は、ライフサイクルに着目します。明細の属性をよく見てください。この中で「チョコを２つ買った」という結果,,,,,,, ,,,は、取引が行われたときに発生しています。しかしチョコとその単価という属性はどうでしょうか。これは取引が,,,,,,, ,,,発生したときに発生したと考えるべきでしょうか？,,,,,,, ,,,,,,,,,, ,,,　いいえ、そうではないですね。チョコと単価は、取引をする前からすでに存在していたものです。そこで、これ,,,,,,, ,,,らの属性をまとめて別のクラスとして分割します。これら属性をまとめるクラスとしては何が適切でしょうか？,,,,,,, ,,,,,,,,,, ,,,　それは商品です。ということで、商品クラスを作成し、明細クラスから分割します。商品クラスには、商品名と,,,,,,, ,,,単価を属性として持ちましょう。ついでに商品を管理するための商品コードもつけてみましょう（図１０）。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,図１０　ライフサイクルが異なるものを分割する,,,,,,, ,,,,,,,,,, ,,,　このようにして作成された商品は、明細の構成物と考えてコンポジションとしました。しかし本当にこれでよい,,,,,,, ,,,のでしょうか？例えば、他の人がコーラを買った場合、商品との関係はどうなるのでしょうか？,,,,,,, ,,,,,,,,,, ,,,　ちょっとそのときのイメージを示してみましょう（図１１）。この図のように、２枚のレシートに現れる商品のオブ,,,,,,, ,,,ジェクトは、管理上1個のオブジェクトで表すのが適切です。なぜなら別々に２つある必要がないからです。従,,,,,,, ,,,って、明細と商品の関連は「N対１」となります。また、明細オブジェクトは、商品オブジェクトを参照しているに,,,,,,, ,,,すぎないことになり、コンポジションではなく関連が適切だということになります。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,図１１　２枚のレシートに現れる商品（コーラ）,,,,,,, ,,,,,,,,,, ,,,　このような理由により、クラス図は、図１２のようになります。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,■操作を割り付けてみよう,,,,,,,,, ,,,,,,,,,, ,,　さて、ここでしっかりと分析された売り上げを店舗と部門に関係づけて、部門ごとの売り上げ合計、サブ部門ごと,,,,,,,, ,,の売り上げ合計という操作を割り付けてみましょう。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,　この図では、２つの新たな記法を使用しています。それぞれの記法について下記に説明します。,,,,,,,, ,,,,,,,,,, ,,,派生属性：,,,,,,, ,,,,,,,,,, ,,,,　明細クラスの属性「小計」を見てください。この小計には”/”（スラッシュ）が付いています。このようにスラ,,,,,, ,,,,ッシュが付けられた属性のことを派生属性といいます。派生属性は、自分の関係しているオブジェクトの情,,,,,, ,,,,報から加工・算出できる値を保有する概念的な属性です。操作によってオブジェクトが一時的に保有するの,,,,,, ,,,,か、それとも属性として本当に持つかどうか、まだ明らかにしたくない場合に使用します。派生属性は、分,,,,,, ,,,,析段階にて使用され、操作の結果だけにすべきか、実際の属性を持つべきかどうかを設計に委ねる際に,,,,,, ,,,,使用するものです。,,,,,, ,,,,,,,,,, ,,,関連の方向性（誘導可能性）：,,,,,,, ,,,,,,,,,, ,,,,　関連はデフォルトでは双方向性を持ちます。これは、関連から生成される２つのオブジェクトは両方相手,,,,,, ,,,,を知っており、お互いにメッセージを交換し合うことを意味します。しかし、明らかに片方のオブジェクトから,,,,,, ,,,,しかメッセージを送る必要がない場合に双方向性を持つとするならば、実装局面においてはプログラムコー,,,,,, ,,,,ドに冗長性をもたらすことになります。また、モデルの意味上においても分かりづらさをもたらしてしまいま,,,,,, ,,,,す。このようなときには、関連の端に矢印を書くことで、関連の方向性を明確にします。図１３では、明細か,,,,,, ,,,,ら商品に向けて矢印を書くことで、明細は商品を知っているが、商品は明細を知らないという意味をモデル,,,,,, ,,,,に付加しています。こうすることで、商品クラスが明細クラスから独立していることを強調することができます,,,,,, ,,,,。このように関連の方向性をつけることを誘導可能性と呼びます。,,,,,, ,,,,,,,,,, ,,　今回は、店舗の売り上げを例に、関係の理解をさらに深めてきましたが、いかがでしたか。関連の理解は深まり,,,,,,,, ,,ましたでしょうか？今回取り上げたように、問題領域を分析する際には、まずリアルな「もの」を想像するためのコ,,,,,,,, ,,ツとして現実世界に存在する印刷物をイメージするというのは非常に有効な手段です。たとえ実際にそのような印,,,,,,,, ,,刷物がなかったとしても、その印刷物を自作してみることをお勧めします。そして、自作した印刷物の内容を分析,,,,,,,, ,,してみるのです。その際に、下記の方法を使って印刷物の構成要素を分解していきます。そうすることで、問題領,,,,,,,, ,,域を深く理解するためのモデルが作成できるようになります。,,,,,,,, ,,,,,,,,,, ,,,・,繰り返されている部分をほかのクラスに分解し、コンポジションとする,,,,,, ,,,・,ライフサイクルが異なる部分をほかのクラスに分割し、関連で結ぶ,,,,,, ,,,,,,,,,, ,,（コラム）リアルモデリングのすすめ,,,,,,,, ,,,,,,,,,, ,,,　今回紹介したように、印刷物などリアルなものをイメージして、それを基に、モデリングを進めるというのは私,,,,,,, ,,,が業務分析を行う際によく使うテクニックです。なぜ、このような方法を考え出したかというと、オブジェクト指向,,,,,,, ,,,によるモデリングの特徴に起因します。,,,,,,, ,,,,,,,,,, ,,,　オブジェクト指向によるモデリングは、どうしても思考の世界に入り込むため、良くも悪くも「あいまいさ」を残し,,,,,,, ,,,てしまうことがあるのです。リアルモデリングは、実際の印刷物を作成することでこの「あいまいさ」を排除でき,,,,,,, ,,,ます。また、問題領域を分析する際の目的（関心事）を明確にすることができます。,,,,,,, ,,,,,,,,,, ,,,　今回の例の場合は、「取引の内容」と「取引の単位」こそが、問題領域（ビジネス）の最も重要視すべき関心,,,,,,, ,,,事なのです。このビジネスの関心事を理解するためにも、そこでやり取りされる重要な情報を印刷物として作,,,,,,, ,,,成してみたらどうなるかということを考えると、ビジネスの関心事がはっきりと見えてくるのです。,,,,,,, ,,,,,,,,,, ,,,　このような印刷物を作成してみて、その印刷物がどのようにやりとりされ、ライフサイクル（いつ発生し、いつ,,,,,,, ,,,まで保持されるべきか）はどうなのか、などと考えることで、ビジネスにとって、最も重要な事項をモデリングの,,,,,,, ,,,対象とできるようになります。みなさんもぜひ、一度リアルモデリングにチャレンジしてみてください。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, 初歩のUML　第7回 オブジェクトの動的側面を見極める,,,,,,,,,, ,http://www.itmedia.co.jp/im/articles/0306/05/news001.html,,,,,,,,, ,,,,,,,,,, ,■オブジェクト図,,,,,,,,, ,,,,,,,,,, ,,　第6回「関連の理解をさらに深める」で説明した店舗と売り上げのクラス図（図１）の実際のインスタンス構造を理,,,,,,,, ,,解するためには、オブジェクト図が有効です。オブジェクト図は、複雑なクラス図を説明するために、インスタンス,,,,,,,, ,,が動作する際のイメージ例を図として表現したようなものです。つまり、インスタンス同士が動作する時の重要な,,,,,,,, ,,シーンを写真に撮ったようなものです。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,図１　第6回で説明した店舗と売り上げのクラス図,,,,,,,, ,,,,,,,,,, ,,　では、図１のクラスから作られる実際のインスタンスの例を、オブジェクト図として表してみましょう。図２はオブジ,,,,,,,, ,,ェクト図をフォーマルに書いたものです。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,　前回もオブジェクト図を使いましたが、ここではオブジェクト図のモデル要素についても、きちんと説明していきま,,,,,,,, ,,す。モデル要素とは、図の中で使用される図中のそれぞれのモデルの意味を表す図要素のことです。オブジェク,,,,,,,, ,,ト図では、「オブジェクト」「リンク」のほか、「コンポジション」「集約」「誘導可能性」など、クラス図で使用できるモデ,,,,,,,, ,,ル要素を必要に応じて使うことができます。また、属性に属性値を入れたものも使います。ただし、多重度は使え,,,,,,,, ,,ません。「リンク」とは、オブジェクト図で使える線のことで、「リンクは関連のインスタンスである」といえます。オブ,,,,,,,, ,,ジェクト図の利用ポイントとしては、クラス図によって生成される重要なオブジェクトのリンクの例を示すように使い,,,,,,,, ,,ます。例えば、この図２は、当日の売り上げを示しています。また、売上にはいくつかの明細があり、各明細を、商,,,,,,,, ,,品とリンクしています。明細は商品を共有することもあるという重要なポイントを、この図では示しています。,,,,,,,, ,,,,,,,,,, ,■シーケンス図,,,,,,,,, ,,,,,,,,,, ,,　次は、部門クラスの操作（売上合計）を呼び出してみることで、クラス図の検証をしてみましょう。果たして、この,,,,,,,, ,,モデルは、正しく動作できるのでしょうか。これを確認するにはシーケンス図を使います。UMLの表記法の中で、,,,,,,,, ,,シーケンス図は、オブジェクト同士の動的側面をとらえるための相互作用図の１つとして知られています。相互作,,,,,,,, ,,用図には、シーケンス図とコラボレーション図があります。コラボレーション図についても今回説明します。,,,,,,,, ,,,,,,,,,, ,,　ではさっそく、シーケンス図の作成方法について説明します。,,,,,,,, ,,,,,,,,,, ,,　シーケンス図は、まずオブジェクト図の中で操作シーケンスを説明する上で、最も適切なオブジェクトをいくつか,,,,,,,, ,,代表として列挙します（図３）。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,　次に、店舗から部門の売上合計操作メッセージを呼び出したときの流れを矢印で書いていけばシーケンス図の,,,,,,,, ,,出来上がりです（図４）。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,■シーケンス図のモデル要素,,,,,,,,, ,,,,,,,,,, ,,　さて、ここからは、シーケンス図で使用できるモデル要素について詳しく説明していきます。まずは、図５をご覧く,,,,,,,, ,,ださい。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,　１から５まで、シーケンスのモデル要素を示す番号が振ってあります。以下、順番にモデル要素の説明をしてい,,,,,,,, ,,きます。図５を参照しながら、以下の説明をお読みください。,,,,,,,, ,,,,,,,,,, ,,（１）ライフサイクル,,,,,,,, ,,,,,,,,,, ,,,　ライフサイクルは、オブジェクトが生成されてから消滅するまでの区間を点線を使って書きます。もし、オブジ,,,,,,, ,,,ェクトを途中で生成（オブジェクトにメッセージの線を直接書く）し、途中で消滅（×マーク）させる場合は図６の,,,,,,, ,,,ように、明示的に表現することができます。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,（２）活性期間,,,,,,,, ,,,,,,,,,, ,,,　活性期間は、操作が実行中または操作の中からほかのオブジェクトの操作の呼び出し中の期間を示します,,,,,,, ,,,。シーケンス図の中でやや分かりづらい概念です。オブジェクトのライフサイクルと混同しないよう注意してくだ,,,,,,, ,,,さい。,,,,,,, ,,,,,,,,,, ,,（３）メッセージ,,,,,,,, ,,,,,,,,,, ,,,　オブジェクトのメッセージは矢印で記入します。例えば「売上合計（）」というメッセージを「衣服：部門」オブジェ,,,,,,, ,,,クトに送るということは、部門クラスに「売上合計（）」という操作があることが前提となります。また、このように,,,,,,, ,,,メッセージを送るには、送信元と送信先のオブジェクトのクラス同士に何らかの関係（関連、集約、コンポジショ,,,,,,, ,,,ン、依存）がある必要があります。,,,,,,, ,,,,,,,,,, ,,,　メッセージを呼び出した後、活性期間が切れているところでメッセージがリターンしていると考えましょう。この,,,,,,, ,,,ことを明示するために、点線矢印でメッセージの戻りを書くことがありますが、一般的にメッセージの戻りは省,,,,,,, ,,,略されます。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,　メッセージには、下記のように非同期メッセージ、同期メッセージがあります。非同期メッセージとは、並行処,,,,,,, ,,,理を進めるためのものです。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,（４）メッセージの自己呼び出し,,,,,,,, ,,,,,,,,,, ,,,　自分自身のオブジェクトのメッセージを呼び出す際は、図５のように、メッセージを自分自身に呼び戻すよう,,,,,,, ,,,な矢印を用いて記述します。,,,,,,, ,,,,,,,,,, ,,（５）オブジェクト,,,,,,,, ,,,,,,,,,, ,,,　オブジェクト図で何度も使ってきたオブジェクトの表記です。オブジェクトのタイプとして、複数存在することを,,,,,,, ,,,示すためのマルチオブジェクトや自分自身が並行動作できる能力を持つことを示すアクティブオブジェクトとい,,,,,,, ,,,ったものがあります。,,,,,,, ,,,,,,,,,, ,,,　図４のシーケンス中の衣服部門の配下には、複数のサブ部門がありますが、マルチオブジェクトを使えば図,,,,,,, ,,,９のように表現することができます。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,　アクティブオブジェクトは、他の制御メッセージと並行的に制御できるメッセージを発するオブジェクトのことで,,,,,,, ,,,す。アクティブオブジェクトは、並行処理を行う際に非同期メッセージと一緒に使用するとよいでしょう。アクティ,,,,,,, ,,,ブオブジェクトは、オブジェクトの枠を太線で囲みます。アクティブオブジェクトの例とその説明については、図１,,,,,,, ,,,０で行います。筆者はHORB ver2.xのアーキテクチャを設計した際、アーキテクチャドキュメントの様々な並行,,,,,,, ,,,処理の部分の説明にシーケンス図を使いました。実際、UMLのシーケンス図で並行処理を表現しようとすると,,,,,,, ,,,、かゆいところに手が届かないといった感じがします。このドキュメントは、http://horb.a02.aist.go.jp/horb-j/で,,,,,,, ,,,「HORB 2.1　コア・アーキテクチャドキュメント」として公開されていますので、興味がある方は、ダウンロードし,,,,,,, ,,,て参考にしてください。UMLクラス図、シーケンス図、オブジェクト図などの利用例が盛りだくさんです。,,,,,,, ,,,,,,,,,, ,■並行処理におけるシンプルなシーケンス図の例,,,,,,,,, ,,,,,,,,,, ,,　以上のモデル要素を活用して、並行処理におけるシンプルなシーケンス図の例を示してみましょう。Javaではお,,,,,,,, ,,なじみのjava.lang.Runnableを実装したオブジェクトによる並行処理について書いたものを図１０に示します,,,,,,,, ,,（Runnableは、第5回「クラスの依存関係と実現関係」で取り上げました）。図１０は、下記のようなストーリーをシー,,,,,,,, ,,ケンス図で表したものです。,,,,,,,, ,,,,,,,,,, ,,,ストーリー,,,,,,, ,,,java.lang.Threadのコンストラクタの引数に、Runnableを実装したオブジェクトを渡して、Threadインスタンスを生,,,,,,, ,,,成し、そのインスタンスのstartメッセージをよびだすと、JVMによって新たなスレッドコンテキストが生成され、そ,,,,,,, ,,,のコンテキスト上からRunnableを実装したオブジェクトのrunメソッドが呼ばれます。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,　いかがでしょうか。この図から２つのスレッドが同時に走っているのが分かりますか？この図は、アクティブオブ,,,,,,,, ,,ジェクトを２つ（MyClassとJVM)登場させています。最初のスレッド（MyClass）が動作している最中に、もう１つのス,,,,,,,, ,,レッド（JVM）が動き始めることをアクティブオブジェクトを使って表現しているものです。また、２つめのスレッドは、,,,,,,,, ,,並行処理を行うことになりますので、JVMからJava.lang.Threadに伸びるメッセージの線は非同期メッセージにして,,,,,,,, ,,います（注）。,,,,,,,, ,,,,,,,,,, ,,,（注）,,UMLはJava.lang.Threadのようにパッケージを含めたクラス名の場合、パス名と呼ばれる表記を使いま,,,,, ,,,,,す。パス名は、図１０の「java：：lang：：Thread」のように「：：」をパス間、またはパスとクラスのセパレータ,,,,, ,,,,,文字として使用します。これはオブジェクト表記、クラス表記共通の記述です。,,,,, ,,,,,,,,,, ,,　少々分かりづらいですね。でも、この図は私なりに、上記UMLの標準的な表記に２つの工夫を追加しています。,,,,,,,, ,,,,,,,,,, ,,　まず１つ目は、苦し紛れですがJVMを登場させることで、OSのスレッドが振り出され、そのコンテキスト上から,,,,,,,, ,,Threadインスタンスのrunが呼び出されていることを説明しています。どの時点でOSからスレッド（実行単位）が切,,,,,,,, ,,り出され、並行制御が行われているのかをJVMをアクティブオブジェクトとして登場させることで説明しています。,,,,,,,, ,,,,,,,,,, ,,　皆さんもご存知のように、そもそもオブジェクトとOSの資源であるスレッドは直行した概念ですので、アクティブオ,,,,,,,, ,,ブジェクトのように、オブジェクトという単位にスレッドが割り付けられるというのも不自然な話なのです。そこで、こ,,,,,,,, ,,の図の２つ目の工夫として、メッセージの線をスレッド別に分けています。こうすることで、どちらのスレッドがどの,,,,,,,, ,,メッセージを読んでいるのかが分かります。また、もしスレッド同士がwait、notifyなどで同期をとる場合、ノートを,,,,,,,, ,,使ってコメントを書き加えるようにします。,,,,,,,, ,,,,,,,,,, ,■コラボレーション図,,,,,,,,※UML2.0ではコミュニケーション図, ,,,,,,,,,, ,,　コラボレーション図は、シーケンス図と同様、相互作用図の１つです。シーケンス図と同じようにオブジェクトの相,,,,,,,, ,,互作用を表していることに違いはありません。しかしコラボレーション図は、オブジェクトとオブジェクトのリンクイメ,,,,,,,, ,,ージを残します。図４のシーケンス図をコラボレーション図で表現したものを図１１に示します。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,■クラス図の詳細化,,,,,,,,, ,,,,,,,,,, ,,　シーケンス図によって、それぞれのクラスの操作の割り付けが詳細化できました。例えば、明細の小計は派生,,,,,,,, ,,属性にしていましたが、操作として定義することにしました。売り上げには税額計算操作が追加されました。商品,,,,,,,, ,,の金額取得操作は省略されています。このように、属性のset（）、get（）についてはクラス図が煩雑になるために,,,,,,,, ,,省略します。,,,,,,,, ,,,,,,,,,, ,,　このようにシーケンス図やコラボレーション図は、クラスから生成されるオブジェクトの相互作用を考察すること,,,,,,,, ,,で、最終的にクラス図の詳細化、洗練化につなげていくために使われます。ただし、シーケンス図やコラボレーシ,,,,,,,, ,,ョン図は、この連載で紹介した図のようにきれいに清書することだけが正しい利用方法ではありません。ホワイト,,,,,,,, ,,ボードでのディスカッションにて、これらの図を描くだけで特に清書しないこともあります。特にシステム分析段階,,,,,,,, ,,などではそのような使われ方をすることが多いでしょう。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,（コラム）オブジェクトの世界はソフトウェアの都合で作られた恣意的な世界,,,,,,,, ,,,,,,,,,, ,,,　今回ご紹介した店舗と売り上げのモデルでは、明細は商品を共有するという構造を持っています。これは、,,,,,,, ,,,現実の世界の明細と商品の構造とは異なります。なぜなら、現実の世界の商品、例えばコーラを２つ買うと、２,,,,,,, ,,,つの商品（コーラ）オブジェクトが使われます。よって、明細と商品の関係は1対1なのです。なぜ、明細は商品,,,,,,, ,,,を共有するようにしたのでしょうか。われわれは、それを当然と思っているのでしょうか。それは結局、皆さんが,,,,,,, ,,,、ソフトウェア開発の常識であるデータの重複排除、つまりデータは一元管理すべきという原則を知っているか,,,,,,, ,,,らだと私は思います。明細に現れる商品（コーラ）の情報は、１つのオブジェクトで管理させるべきというソフトウ,,,,,,, ,,,ェアエンジニアリングの常識を皆さんが知っているからこそ、自然に思えているだけなのです。,,,,,,, ,,,,,,,,,, ,,,　オブジェクト指向は、現実の世界をそのまま描写しているように誤解する方が多いのですが、実はそうでは,,,,,,, ,,,ありません。ソフトウェアという仮想世界を現実世界に似せて表現することで、仮想世界のもやもやした構造を,,,,,,, ,,,、人が理解しやすくしているだけなのです。ですから、実際のオブジェクトは、ソフトウェア開発にとって都合が,,,,,,, ,,,良い構造に変化させる必要があり、非常に恣意的なものと考えるべきなのです。そうしないと無意味な分析、,,,,,,, ,,,設計に時間をかけてしまうといったオブジェクト指向の落とし穴にはまりこんでしまいます。,,,,,,, ,,,,,,,,,, ,,,　現実世界の「もの」の名前を借用して、オブジェクトに名付けてあげることで、みんながそのオブジェクトの存,,,,,,, ,,,在を理解するということがオブジェクト指向のメリットなのです。そしてそのようなテクニックが、オブジェクト指,,,,,,, ,,,向分析、設計、実装のそれぞれの局面において重要なものとなるのです。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,図１３　オブジェクト指向は、仮想世界のもやもやした構造を人が理解しやすくしているだけ,,,,,,, ,,,,,,,,,, ,,,　また、第４回「関連クラスと集約、コンポジション」でも述べましたが、ソフトウェアで、「何をやりたいのか」がク,,,,,,, ,,,ラスの構造やクラスの関係構造を決定します。何をやりたいのかが決まらなければ、そもそもクラスの仕様が,,,,,,, ,,,正しいかどうかさえ分からないのです。先に挙げた、明細と商品の関係についても、すべての取引で同じ構造,,,,,,, ,,,を持つかというと、そうではありません。例えば、レンタルビデオショップの場合、明細と商品は１対１になるか,,,,,,, ,,,もしれません。なぜなら、売り上げの明細につながる商品はビデオ本体となり、ビデオが１つ貸し出されると在,,,,,,, ,,,庫が１つ少なくなることを管理しなければならないからです。つまり在庫管理までも対象としている場合、構造,,,,,,, ,,,が変わってきます。これも、やりたいことが変わるとクラスの関係構造が変わるという例ですね。,,,,,,, ,,,,,,,,,, ,,　今回はここまでです。次回は、「やりたいことは何か」「やるべきことは何か」に焦点を絞ったモデリングを紹介し,,,,,,,, ,,ます。そうです。ようやくユースケースモデルの登場です。,,,,,,,, ,,,,,,,,,, 初歩のUML　第8回 顧客の要求をユースケースに反映させる,,,,,,,,,, ,http://www.itmedia.co.jp/im/articles/0307/05/news002.html,,,,,,,,, ,,,,,,,,,, ,　ユースケースとは何か？なぜ必要か？今回は、だれも書いたことがない視点から、オブジェクト技術者が理解して,,,,,,,,, ,おくべきユースケースモデルについてのノウハウを解説します。,,,,,,,,, ,　そもそも、ソフトウェア開発には、必ず開発を行う目的があります。どんなソフトウェアであってもこの目的がはっきり,,,,,,,,, ,しないと、よいソフトウェアなど作れるはずがありません。筆者が初心者の頃、よく「構造化されたソフトウェアを考え,,,,,,,,, ,てみよう」とか「継承を生かした何らかのソフトウェアを作ってみよう」といったことを計画し、自作ソフトウェアを作ろう,,,,,,,,, ,と試みたことがありました。しかし、あえなくすべて失敗に終わってしまいました。「構造化」や「オブジェクトテクニック」,,,,,,,,, ,が目的であっては何も作れないのです。では、ソフトウェア開発にとって最も重要なことは何でしょうか。そうです、「ソ,,,,,,,,, ,フトウェアがどのような人に、どう使われるか」ということなのです。今回は、UMLユースケースモデルを紹介します。,,,,,,,,, ,ユースケースモデルは要求を表現するモデルです。「ソフトウェアがどのような人に、どう使われるか」を表すのが、,,,,,,,,, ,ユースケースモデルなのです。,,,,,,,,, ,,,,,,,,,, ,■ユースケースモデルとは,,,,,,,,, ,,,,,,,,,, ,,　ユースケースモデルは、「ユースケース図」と「ユースケース記述」によって構成されます。,,,,,,,, ,,,,,,,,,, ,,□ユースケース図,,,,,,,, ,,,,,,,,,, ,,,　まずは、図１を見てください。これがユースケース図です。ユースケース図は、利用者から見たシステムの「,,,,,,, ,,,使い方の例（ユースケース）」を示したものです。この図は、店頭で商品を販売するサービスと、Web上で商品,,,,,,, ,,,を販売するサービスを持つ、商品販売システムを表しています。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,　ユースケース図はとても簡単な図なので、あまり身構えずに読んでください。では、図の説明をしていきましょ,,,,,,, ,,,う。,,,,,,, ,,,,,,,,,, ,,,　人形マークはアクターといいます。だ円をユースケースといいます。アクターは、システムを利用する何らか,,,,,,, ,,,の役割を持つオブジェクトです。アクターは人であっても、サブシステムであってもかまいません。システムにア,,,,,,, ,,,クセスする何らかの役割を持ったものであればOKです。要するにアクターは、システムにアクセスする何らか,,,,,,, ,,,の役割に名前を付けたものと考えれば分かりやすいでしょう。,,,,,,, ,,,,,,,,,, ,,,　ユースケースとは、名前の通り「システムの利用例」です。例えば、Webユーザは、「商品を購入する」「購入,,,,,,, ,,,商品を確認する」というユースケースを使うことができるのがこの図からわかります。商品販売システムと描か,,,,,,, ,,,れた長方形は、システム境界と呼ばれ、システムの内外を区切ります。,,,,,,, ,,,,,,,,,, ,,,　アクターは、システム境界の外部に書かれ、ユースケースはシステム境界の内部に書かれます。またアクタ,,,,,,, ,,,ーとユースケースを繋ぐ線は関連といいます。,,,,,,, ,,,,,,,,,, ,,□ユースケース記述,,,,,,,, ,,,,,,,,,, ,,,　ユースケース記述とは、ユースケース図の中の1つのユースケースについて、アクターとシステムのやりとり,,,,,,, ,,,をストーリーとして書いたものです。例えば、「商品を購入する」というユースケースのユースケース記述を下記,,,,,,, ,,,に書いてみましょう。,,,,,,, ,,,,,,,,,, ,,,,ユースケース名,,,,,,商品を購入する ,,,,概要,,,,,,本ユースケースは、Web上及び店頭で商品を購入する際に呼び出される。 ,,,,,,,,,,店頭では、店員を通じて本ユースケースが利用される。 ,,,,アクター,,,,,,Webユーザー、店員（オペレータ） ,,,,メインフロー,,,,,,１．アクターは、購入したい商品のジャンルを選ぶ ,,,,,,,,,,２．システムは、選択されたジャンルの商品一覧を返す ,,,,,,,,,,３．アクターは、商品を選ぶ ,,,,,,,,,,４．システムは、商品の詳細情報（説明、金額、写真）を返す ,,,,,,,,,,５．アクターは、この商品でよければ商品購入手続きに入る ,,,,ユースケース記述,,,,,, ,,,,,,,,,, ,,,　いかがですか、簡単でしょう。上記のように、ストーリ部分はメインフローというところに書きます。ユースケー,,,,,,, ,,,ス記述で書かれるフローのことを、イベントフローと呼びます。この例では、処理の中断や、前の処理に戻るな,,,,,,, ,,,どの制御の流れについて省略しています。もう少し長々しく書いた本格方法を下記のコラムにまとめています,,,,,,, ,,,。ここまで詳細に書いてしまうと、分析初期段階からドキュメント過多に陥りやすいので私としては、あまりお勧,,,,,,, ,,,めしたくありません。,,,,,,, ,,,,,,,,,, ,,,コラム：ユースケース記述補足,,,,,,, ,,,,,,,,,, ,,,,　ユースケース記述には、必要に応じて、代替フロー（メインフローの条件分岐）、例外フロー（ユースケース,,,,,, ,,,,中の例外的な挙動やシステムのユーザーから見えるエラー）を書きます。,,,,,, ,,,,,,,,,, ,,,,　また、事前条件（ユースケースを呼び出すために満たすべき条件）や事後条件（ユースケースが終了され,,,,,, ,,,,る際にシステムが満たしておくべき条件）を書くこともできます。さらに、具体的な「もの」や「アクター」を説明,,,,,, ,,,,するために、「シナリオ」を書くこともできます。イベントフローの一例をシナリオとして書いてみましょう。,,,,,, ,,,,,,,,,, ,,,,,１．ユーザーは、紳士服のジャンルを選ぶ,,,,, ,,,,,２．システムは、紳士服の一覧を表示する,,,,, ,,,,,３．ユーザーは、気に入った礼服を選ぶ,,,,, ,,,,,４．システムは、選択された礼服の説明、サイズ、金額、写真を表示する,,,,, ,,,,,５．ユーザーは、この礼服の購入手続きに入る,,,,, ,,,,,,,,,, ,■ユースケースモデル、誰のため、何のため？,,,,,,,,, ,,,,,,,,,, ,,　ユースケースモデルがどんなものか分かりましたか？,,,,,,,, ,,,,,,,,,, ,,　ユースケースモデルを一言で言うと、「システムを利用者の視点で端的に捉えたモデル」です。では、ユースケ,,,,,,,, ,,ースとは誰のために、何のために、必要なのかという点について考えてみましょう。まず、いままでのソフトウェア,,,,,,,, ,,開発における要件定義フェイズはどうやっていたのでしょうか。開発者の立場で要求をまとめていたのでは？,,,,,,,, ,,,,,,,,,, ,,　そのような要件定義では、ユーザーは理解できるはずもなく、つい「これでいいですよ！」と開発者にいってしま,,,,,,,, ,,います。ここから悲劇の始まりです。システムに要求されているものと異なるシステムを作ってしまう原因となるわ,,,,,,,, ,,けです。,,,,,,,, ,,,,,,,,,, ,,　開発者は、もう少しユーザーの視点で、つまりユーザーがどのようにシステムを利用するかといった視点で要求,,,,,,,, ,,をまとめる必要があります。ユーザーの視点でまとめられた世界には、データベースやネットワークがどうのこう,,,,,,,, ,,のという話はなく、あるのは「誰が、どうやれば、何ができるのか」ということに尽きます。このようにシステム利用,,,,,,,, ,,者の視点で作るモデルがユースケースモデルです。そうすることで、ユーザーの業務ナレッジを最大限にシステ,,,,,,,, ,,ムに生かすことができるのです。,,,,,,,, ,,,,,,,,,, ,,　ユースケースモデルは、システムの利用者の視点で、システムの利用者と開発者の間でシステム要求の姿を,,,,,,,, ,,明らかにするために作成されるモデルなのです。ユースケースモデルを開発でうまく活用するには、利用者主導,,,,,,,, ,,でこのモデルを完成させることです（図２）。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,図２　利用者主導で作成されたユースケースを開発者と共用するという考えが重要,,,,,,,, ,,,,,,,,,, ,■開発者から見たユースケース,,,,,,,,, ,,,,,,,,,, ,,　次は、開発者の視点でユースケースをとらえてみましょう。つまり、開発するソフトウェアの構造とユースケース,,,,,,,, ,,との関係を調べてみることにします。図３は、「商品を購入する」ユースケースを開発者の視点で拡大したもので,,,,,,,, ,,す。ユースケースの中に開発者から見た、各種機能があります。ユースケースは、ユーザーから見た機能ですが,,,,,,,, ,,、図３は、開発者から見たソフトウェア機能や画面も複数含まれ束ねられているものです。ユースケースは、あくま,,,,,,,, ,,で、ユーザーから見た機能ということを忘れないでください。開発者から見える機能は、ユースケースとしては適,,,,,,,, ,,切ではないことが多いのです。また、複数の機能や画面を束ねているという点も重要なポイントです。これは、ユ,,,,,,,, ,,ースケース名は、ユーザーの利用事例に名前を付けたと考えるとよいでしょう。「商品を購入する」というユースケ,,,,,,,, ,,ース名も、システムの利用例をひとくくり（利用の単位）にして名前を付けたものです。,,,,,,,, ,,,,,,,,,, ,,　なぜこのことが重要かというと、ある程度の規模になるビジネスアプリケーションにおいては、ユースケースの個,,,,,,,, ,,数やユースケース図の枚数が膨大になる可能性があるからです。システムの利用単位でユースケースを書くこと,,,,,,,, ,,で、この問題を解決することができます。,,,,,,,, ,,,,,,,,,, ,,　ユースケース図は何枚程度が適切ですかって？,,,,,,,, ,,,,,,,,,, ,,　そうですね、どんなに多くなっても、ユースケース図２０枚以内、図中のユースケース７個以内程度に抑えるよう,,,,,,,, ,,にした方がいいでしょうね。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,図３　ユースケースを開発者の視点で拡大すると！,,,,,,,, ,,,,,,,,,, ,■オブジェクト技術から見たユースケース,,,,,,,,, ,,,,,,,,,, ,,　次は、オブジェクト技術からユースケースモデルを見てみましょう。ええっ、UMLの中に入っているからユースケ,,,,,,,, ,,ースモデルはオブジェクトモデリング技術の一種なんでしょって？,,,,,,,, ,,,,,,,,,, ,,　実は、そうではありません。ユースケースモデルは、オブジェクトモデリングとは異なる機能中心のモデリング技,,,,,,,, ,,術なのです。しかし、オブジェクト指向開発には必須ともいえるものです。さて、ここからオブジェクト技術を追求し,,,,,,,, ,,ようと思っている読者の方々も必読です。オブジェクト技術を追求するビギナーの陥りやすい落とし穴について説,,,,,,,, ,,明します。,,,,,,,, ,,,,,,,,,, ,,　皆さん、オブジェクト技術の効果は何だと思いますか？おそらく「再利用性」「拡張性」という話が必ず出てくるで,,,,,,,, ,,しょう。たいていの自称オブジェクト技術者は、ソフトウェアの本質の尺度として再利用性と拡張性に重きを置いて,,,,,,,, ,,います。,,,,,,,, ,,,,,,,,,, ,,　ここで、ユースケース図の中に現れるシステム境界とオブジェクトの再利用性と拡張性について簡単に説明して,,,,,,,, ,,いる図４を示します。,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,図４　バランス感覚のないオブジェクト技術者は致命的？,,,,,,,, ,,,,,,,,,, ,,　この図のように、オブジェクトの再利用性や拡張性を考慮するということは、システム境界からはみ出たオブジェ,,,,,,,, ,,クトを対象にするということになります。なぜなら、再利用可能なオブジェクトには、システムで必要とされる要求,,,,,,,, ,,を満たす機能のほか、ほかのシステムでも必要とされるであろう機能を盛り込むからです。また、オブジェクトに拡,,,,,,,, ,,張メカニズムを組み込むことは、いま必要な機能だけではなく、将来必要とされる機能を組み込むメカニズムを導,,,,,,,, ,,入することなのです。,,,,,,,, ,,,,,,,,,, ,,　このような思考をシステムに対する要求と同じ視点で考えてしまう人は、システム境界が図４の右側のように見,,,,,,,, ,,えています。つまり、いま必要とされる要求に疎くなるのです。このような問題を解決するためにもユースケースモ,,,,,,,, ,,デルは非常に有効です。なぜなら、まずユースケースによってユーザーからシステムに要求されている機能は何,,,,,,,, ,,なのかをしっかりととらえることができるからです。,,,,,,,, ,,,,,,,,,, ,,　ただ、ユースケースモデルがあるから安心と考えるべきではありません。オブジェクト技術を実践する技術者の,,,,,,,, ,,心得としては、ユースケースモデルに頼ることなく、「アプリケーションの視点」と「オブジェクトの視点」という２つの,,,,,,,, ,,視点をバランスよく併せ持ち、それぞれの視点でシステム開発を見るべきです。「アプリケーションの視点」とは、,,,,,,,, ,,システムとして必要とされているものが何で、それをいつまでに作るべきかというユースケースの視点です。「オブ,,,,,,,, ,,ジェクトの視点」とは、いま何が必要かということだけではなく、将来必要となる機能は何か、また、そのソフトウェ,,,,,,,, ,,アの構造はどうなっているのか、さらに、その中で再利用できる箇所はどこなのかといった視点です。,,,,,,,, ,,,,,,,,,, ,■ユースケースモデルの描き方,,,,,,,,, ,,,,,,,,,, ,,　ユースケースモデルを開発者が書くとき陥りやすい落とし穴について説明します。,,,,,,,, ,,,,,,,,,, ,,□機能単位をユースケースにするな,,,,,,,, ,,,,,,,,,, ,,,　ユースケースの単位を、機能分割の感覚で作ってしまいます。そのようなユースケースは、ユーザーの視点,,,,,,, ,,,から見ると時系列を伴うものが多く、時系列を表すすべがないユースケース図には不適切であり、また、ユー,,,,,,, ,,,スケースの個数が膨大になってしまいます。,,,,,,, ,,,,,,,,,, ,,□データベースがどこにあるかなどは問題ではない,,,,,,,, ,,,,,,,,,, ,,,　よくある誤解が、例えば「商品を登録する」というユースケースの中にデータベースが存在すると勘違いして,,,,,,, ,,,しまうことです。この勘違いから、「商品を参照する」というユースケースに関連を持つアクターからも「商品を登,,,,,,, ,,,録する」に関連を引いてしまいます（図５）。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,図５　正しくないユースケース図,,,,,,, ,,,,,,,,,, ,,□アクターの正しい理解,,,,,,,, ,,,,,,,,,, ,,,　最初に紹介した図１のユースケース図で、あなたが管理者だったとしましょう。あなたがもし商品購入ができ,,,,,,, ,,,るとしたら、それは、管理者という立場で、商品購入ユースケースと関連を持つのか、それとも、店員という立,,,,,,, ,,,場で、商品購入ユースケースと関連を持つのかを考えなければなりません。前者の場合は、管理者から商品,,,,,,, ,,,購入ユースケースに関連を引く必要性が生じますが、後者の場合、その必要はありません。このように、,,,,,,, ,,,アクターは、システムにアクセスする外部のアクターの責務を明確にすることで、システム運用における仕様,,,,,,, ,,,を明らかにさせることが目的なのですが、この点があいまいな記述がよく見られます。,,,,,,, ,,,,,,,,,, ,,□システムの根拠がないまま挙動を書いてしまう,,,,,,,, ,,,,,,,,,, ,,,　ユースケース記述は、あまり細かく書いてしまうと問題が起こることがあります。なぜかというと、ユースケー,,,,,,, ,,,ス記述は、要求定義というシステム開発のかなり早いフェイズで用いられるモデルだからです。よってシステム,,,,,,, ,,,の詳細な動きについてシステマチックに書きすぎると、根拠なき挙動を書いてしまうということにつながります。,,,,,,, ,,,システム屋さんが陥りやすい落とし穴です。ちょっとしたストーリ（構想）を書いているという軽い気持ちの方が,,,,,,, ,,,うまくいくようです。,,,,,,, ,,,,,,,,,, ,,□要求はユースケースかユースケース記述に書く,,,,,,,, ,,,,,,,,,, ,,,　ユースケース図は、システムの要求をビジュアルにとらえるものです。しかし、一般にユースケースの粒度は,,,,,,, ,,,かなり大きくなります。そうすると、ユースケースだけを見ても要求がどのようなものであるか一目で分かりま,,,,,,, ,,,せん。そこで、ユースケース記述でそれを補うわけです。従って、システムに対する主要な要求は、ユースケー,,,,,,, ,,,スかユースケース記述によって表現されていなければなりません。そのような定義からすると図１で紹介した,,,,,,, ,,,ユースケース図中の「商品を購入する」というユースケースを説明するユースケース記述（表）のメインフロー,,,,,,, ,,,部は何か問題があると思いませんか？,,,,,,, ,,,,,,,,,, ,,,,1,アクターは、購入したい商品のジャンルを選ぶ,,,,, ,,,,2,システムは、選択されたジャンルの商品一覧を返す,,,,, ,,,,3,アクターは、商品を選ぶ,,,,, ,,,,4,システムは、商品の詳細情報（説明、金額、写真）を返す,,,,, ,,,,5,アクターは、この商品で良ければ商品購入手続きに入る,,,,, ,,,,表　ユースケース記述メインフロー,,,,,, ,,,,,,,,,, ,,,　このメインフローには、「商品購入手続き」というストーリがまだ明らかにされていません。これに対応するに,,,,,,, ,,,は２つの方法があります。まず、一つ目は、ユースケース記述に商品購入手続きの内容についてアクターとシ,,,,,,, ,,,ステムのやり取りを書いていくことです。もう1つのやり方としては、「商品購入手続き」ユースケースを追加する,,,,,,, ,,,方法です。ただし、「商品購入手続き」ユースケースは、アクターが単独で利用するものではないので、「商品,,,,,,, ,,,を購入する」ユースケースから呼び出される部品的なユースケースとして表します。,,,,,,, ,,,,,,,,,, ,,,　ユースケース図では、このようなユースケースは、包含（include）ステレオタイプを利用した依存関係を使って,,,,,,, ,,,表すことができます。図６を見てください。,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,,,,,,,, ,,,　「商品を購入する」は「商品購入手続き」を包含（include）しています。ただし、この方法は「開発者から見た機,,,,,,, ,,,能を分割してユースケースにしてはならない」という点に十分注意してください。これでユースケースとしては完,,,,,,, ,,,成です。このように、原則としてユースケース図かユースケース記述にシステムの全ての要求を書きます。な,,,,,,, ,,,ぜ、「原則として」と書いたかというと、開発対象のシステムが大きくなればなるほど、ユースケースは本質的な,,,,,,, ,,,要求だけにとどめておいたほうが良いからです。例えば、システムのマスタメンテナンスなどの細かな機能ま,,,,,,, ,,,で網羅しても仕方ありませんからね。,,,,,,, ,,,,,,,,,, ,■ユースケースモデルは機能要求をとらえる,,,,,,,,, ,,,,,,,,,, ,,　図４で、拡張性、再利用性といった視点とは異なる視点で、ユースケースモデルをとらえると説明しました。では,,,,,,,, ,,、拡張性、再利用性については、どのように開発の中に組み込んでいくのでしょうか。また、パフォーマンスや信,,,,,,,, ,,頼性といったユーザーから見た機能というものとは異なる要求はどうすればよいのでしょうか？,,,,,,,, ,,,,,,,,,, ,,　実は、ユースケースモデルで整理できる要求は、「機能要求」のみです。機能要求とは、システムを利用する,,,,,,,, ,,利用者から見てシステムの機能と考えられるもののことをいいます。また、それ以外の要求のことを「非機能要,,,,,,,, ,,求」といいます。拡張性、再利用性、パフォーマンス、信頼性といったものは非機能要求に該当します。非機能,,,,,,,, ,,要求は、ユースケースモデルでは表せないため、非機能要求一覧としてまとめられます。,,,,,,,, ,,,,,,,,,, ,,　非機能要求についてもしっかりとアーキテクチャ設計に加味されます。この辺の話についてもこの連載の中で取,,,,,,,, ,,り上げていきます。,,,,,,,, ,,,,,,,,,, ,,　今回はこれでおしまいです。次回は、オブジェクト技術を使ってどのように開発を進めていくのか、どのようにモ,,,,,,,, ,,デリングを利用するのかという点について、オブジェクトベースの開発プロセスの考え方について説明します。,,,,,,,,