これは全部のユースケースに対して必要なわけではなく、特に重要なものや、複雑なものをこのように拡張ユースケースまで分析するのが一般的です。
概念図
概念図というのは、概念モデルを図化したものです。概念モデルの目的は、取り扱う問題を個別のオブジェクトに、つまり私たちが知っているモノやコトに分類することです。
まずは概念を列挙しましょう。このでいう「概念」は本や分析法によっては「エンティティ」と呼ばれたりします。
いくつかガイドラインがあるのですが、そのうちの一つ、概念のカテゴリリストを紹介します。
- 物理的に存在しているモノ
- モノの仕様や説明
- 場所
- 処理、業務(トランザクション)
- トランザクションで扱うデータの明細
- 人の役割
- なにかを入れるもの
- なにかに入るもの
- 外部のシステム
- 抽象名詞(速度依存症など)
- 組織
- イベント
- 規則や方針
- カタログ(情報が集まったもの、という意味で)
- お金の動き、労働、契約、法的なモノゴトの記録
- 経理上の道具、サービス
- マニュアル・本
ええまあそうでしょう。ですからもっと簡単な方法を挙げましょう。
それは「ユースケース内の名詞を列挙する」ということです。
ただ、名詞＝概念、という機械的な変換はできません。
ですから、名詞を列挙した後、カテゴリリストと組み合わせて、注意深く、どれを「概念」と取り上げるべきか考えます。
もっとも、概念図の段階では、取り残しがあるよりは多すぎるほうがいいという傾向にありますので、それほど神経質になる必要はないかもしれません。
そうそう、忘れてはいけないのは「概念図」はプログラムの設計図ではないという面です。
もちろん上であげた関連が全て必要になるわけでもありません。(あ、ちょっと安心しました？(^^;)
たとえば上のリレーションの時に作った図で言えば、「売上取引」は「入力商品」を属性として持つこともできます。
属性の型として単純なのは、おおむね以下のとおりです。
これらは現実世界のモノやコトを整理し説明するためのものです。こういう工程を「分析フェーズ」と呼びます。
ですから、プログラムに関係ないと思うことも列挙します。
概念図１：概念だけ
で、上記にしたがってユースケースの中の概念っぽいものを列挙してみましょう。
さてこれを、「概念」としてふさわしいものはなにか、とか、あるいは「これとこれは同じものを含んでいる」とか「これにこれが含まれるな」とか分析します。
この分析は分析者によって多少違いますから、皆さんの考えと私の考えは違うかもしれません。
で、整理した後がこんな感じです。
統合したものもあれば、新しく入れたものもあります。最後の「レジに入力した商品」は新しく追加してみました。
ユースケースで「商品の識別情報を入力する」とありますが、入力された識別情報のリストがこの文章に隠れていますね。
ですのでこの分析で出しました。
商品に関する個々の概念は商品情報に属するとします。
さあこれを、いよいよ概念図（その１：まずは概念のみ)にしてみましょう！
あ、なんですかその沈黙は。
いま、ちょっとむっとしましたね？
でも、ほんとうにここから始めるんです、概念図。
これに、リレーションとか、属性とかをつけていきます。
ちなみにこれはUMLという表現形式で、最近のオブジェクト指向の表現ではかなりポピュラーなものです。
進んでいくにつれ、より「UML」らしい形式になっていきます。
もしかしたら、途中で、UML入門を割り込ませる(別コーナーだろうと思われるので)かもしれません。
概念図２：リレーション
さて、非常に単純な概念図でしたが、それぞれの四角形(オブジェクトといったり、エンティティといったりします。分析手法の違いによります。概念図の段階ではエンティティとしたほうが一般的かもしれません)同士の関係を考えてみましょう。
システムというのは、なんであれ、「何かが何かに働きかけて」動作するものです。これはコンピュータシステムに限らず、すべての「システム＝系」と呼ばれるものがそうなっていると思います。
つまり、このオブジェクト間の関係を明確にするということは、現実の世界を、この図にモデル化するということに他なりません。
で、この関係のことを「リレーション」と呼びます。(っていうか、まんま英語です)。
リレーションには、「典型的なもの」と「独自なもの」があります。
典型的なものは、おおむね以下のとおりです。
まあこんなものでしょう。
これらは（概念を拾い上げるときもそうですが）「正解」というものはありません。正しいかどうかというのは、それぞれの視点によって変わってしまうからです。
ですから、「同じ視点で考える」ということが大事です。
また、問題になるのは「正しいかどうか」ではなく「便利かどうか」です。
いくつでもリレーションはかけますし、またいくつでもエンティティを書くこともできます。
どのくらいまでが分析に便利なのかなと考えながら作っていきましょう。
概念図を書くに当たって、重要なのは「ＡはＢの一部」と「ＡはＢの中」、そして「ＡはＢに記録される」くらいです。
また、関係を探すより概念を探すほうが重要です。関連を探すのはなかなか面白い作業ですが、できるだけ概念を探すほうに力を傾けてください。
実用性の少ないリレーションで図を覆ってしまうと見難くなりますので、その点も注意してください。
関連には「役割(ロール)」というものが含まれていて、「関連の名前」「多重度」「誘導可能性」というのがあるのですが、とりあえず多重度は文脈によってどんどん変わりますし、誘導可能性とかいう良くわからないものもおいといて、さしあたっては「関連の名前」に気をつけていきましょう。
リレーションの名前
リレーションの名前は、名詞(エンティティ）─リレーション名─名詞（エンティティ）となったときに読みやすいものをつけるのが普通です。
この感じからおわかりになるように、リレーション名は一般的に動詞句になります。
もともとの考案者が英語圏の人たち(高名な人たちですのでＵＭＬを検索すればきっとすぐに出てきます)なので、これは英文の文法をちょっと取り入れています。
このためリレーション名は一般的に英語で(日本のシステムでも！)して、動詞で、頭文字を大文字、二語(toとかwithとかbyとかつくことが多い)以上の場合はハイフン(-)で繋ぎます。
一般的に、図において「上から下に」「左から右に」読まれます。だから、図の上でエンティティをどこに置くかによって、動詞が受身形になったりします。
図が見たいんだよ図が
まあごたくはこの辺にしておきまして、とりあえずいってみましょうか。
えい。
あ、なんだか高度なことしてるっぽい図になってきました。
何度も言うように、こういった図に「絶対の正解」はありません。
見方が違えば図も違います。
また、全ての関連を書く必要はありません。
たとえば「操作員」と「お客さん」は「商品をわたす」とか「挨拶する」とか「顔見知り」とか「初対面」とか「好意を抱いてる」…とか、いろいろな関係を書くこともできますが、あえて入れていません。それをこの図に入れても便利ではないからです。
あと、図の左下、「入力商品」と「商品」の関係が「売ったものを記録(Record-seles-of)↓」となっています。
この矢印はつけてもつけなくてもいいのですが、「商品」が左かつ下にあるような配置になっているので、「受身にすべきかどうか」で悩まないように、つけてもいいことになっています。
概念図３：属性
属性は、ユースケース上のエンティティの「個性」を決めるものだ、といっていいんではないでしょうか。
オブジェクト指向言語に慣れ親しんだ人なら「クラスのデータメンバだろ」と即座に切って棄てるかもしれませんが、それは正しい認識ではありません。(結果として同じことになってもです)。
繰り返しますが、概念図は現実世界のモノやコトを整理したものであり、ソフトウェア上の設計に直接関与するものではないんです。
だから、たとえば、操作員を管理するための操作員番号などはここでは出てきません。
どのくらい多くの属性を探せばいいんだ、という問いの答えには「ユースケースを詳しく説明するために必要なだけの属性」を探してください、という答えが適している…と思います。
単純なほうがいい
属性というのは、基本的に単純であるほうが望ましいといえます。
できるだけ簡単な「型」で構成されるように整理してください。
複雑な「型」や「モノゴト」を属性にするのは(正しくないとまではいいませんが)不便です。
そういう場合は、その属性もエンティティと捉え、属性にするのではなくリレーションで表現したほうがよくないか検討すべきです。
でも、そうしていないのは、「入力商品」のような複雑であることを暗示させるようなものは、属性として扱うと不便だからです。
で、これ以外のは全部エンティティ…にするとあまりにも概念が多くなり煩雑だったりしてやはり理解するのに不便になるので、一般的に属性としていいんじゃないかという型もあげます。
その他があるんなら何でもありじゃん、とか思う人たくさんいそうです(^^;
が、複雑な概念(＝エンティティとなるべきもの)を属性として扱うのは大変に不便です。
その「属性」の型を考えたときに、複雑なデータ構造になるものは「エンティティ」にするべきです。
それってＥＲ図と違うの？
エンティティがあり、属性がある。あ、データベース設計におけるER図(エンティティリレーションシップ図)に似ていますね。
でも、違います。
何度でも言いますが、概念図は現実世界のモノやコトを整理したものであり、ソフトウェア上の設計に直接関与するものではないです。
つまり、概念図におけるエンティティは、外部エンティティーへのキーを持っていません。ＥＲ図でいうフォーリンキーは含まれていないことに注意してください。
外部エンティティへのキーを属性として持っているのではなく、外部エンティティとリレーションしているのです。
で、具体的に今回の属性って何
はいはい。まず今回のシステムで、各々のエンティティとして何を把握しなければならないのかを整理してみましょう。
