オブジェクトの広場はオージス総研グループのエンジニアによる技術発表サイトです
今月号からモデリング記事を連載することになりました。毎回、身近にあるモノや出来事など、簡単な【お題】を出題し、皆様にモデリングをして頂きます。次回の記事で、皆様の解答モデルの中から 3 つほど取り上げて、コメントを付けていくかたちで進めていきます。
今月号からモデリング記事を連載することになりました。毎回、身近にあるモノや出来事など、簡単な【お題】を出題し、皆様にモデリングをして頂きます。次回の記事で、皆様の解答モデルの中から 3 つほど取り上げて、コメントを付けていくかたちで進めていきます。
読者の皆様は必ずしもモデルを送付する必要はありません。ただ、お題に対する解答例の説明は次回になるので、お時間のあるときにでも考えてみるとより楽しめると思います。ちょっとした気分転換に、気軽にモデリングをしてみて下さい。テーマは以下の2点です。
この連載では、UMLでの表現の優劣やテクニックを競ったりというものではなく、 あまりUMLに馴染みのない人も気軽にモデリングを愉しんでもらえる連載にするつもりです。
解答していただきたい読者の方としては、普段からUMLを使ってバリバリ開発されているソフトウェアエンジニアの方よりもむしろ、最近UMLを覚えたばかりでモデル作成の経験の浅い方、モデルを作成するといつも複雑になってしまうと悩んでおられる方を対象に考えています。
モデリング大好きな達人モデラーの方々には少々物足りないネタになってしまうかもしれませんが、 まわりの仲間を誘って、一緒にモデリングしてみたり、個別にモデリングしてお互いのモデルで議論してみても楽しいと思います。 ぜひ、身近にいるモデリングの得意でない後輩や新人さんなどを誘ってモデリングして下さいね。
モデリングとは対象を模式化することです。
対象のすべてを細かく表現するのではなく、特徴的な部分を利用して、重要でないものは捨てます。
例えば、スマイルマークのように、まん丸の顔と目と口だけで笑顔を表現するようなものです(^_^)。
ここでは、プログラミング言語に実装するような詳細なレベルのモデリングではなく、身近なお題に対して、その特徴を表現するモデリングを行うものとします。
さて、ここでは本記事で実際にモデリングを実施していただくにあたり、例題を使って、モデリングの手順や注意点について説明します。
長谷川さんは，相田部長から「来週の12月13日(火)に14:00から第3会議室にて
新商品企画の打合せがあるよ」と聞きました。
また，先輩の田中さんから「12月15日(木)13:00から第1会議室にて
プロジェクトのキックオフミーティングがあるので参加してくれ」といわれています。
これらの状況を説明できるような「打合せ」をモデリングして下さい。
まず、はじめにモデリング対象となっている状況の全体像を把握します。 思いつくことを列挙したり、文献等を調べて、その状況の中で起こっていることや、 そこに含まれる「もの」を洗い出し、対象が持つ事実関係を具体的に理解していきます。
例題での登場人物は、長谷川さん、相田部長、先輩の田中さん、 安田くんです。何やら打合せの連絡について書かれているようですね。 会話の中からは、打合せの予定として、日付、時刻、会議室、打合せの内容といったことが読み取れます。 ここで、打合せ（あるいは会議）で思いつくことを挙げてみると、
などが思いつきます。
次のステップでは、モデルを作成するための「コンセプト」を決定します。 「コンセプト」は、モデリング対象をどのように捉えて、どのように表現するのかを決めるものです。 最初のステップで洗い出した様々な状況に対して、欠かすことのできない重要な部分に絞り込みます。
目標は、少ない情報でモデリング対象の重要な特徴を表現することです。
問題文を読み返してみると、ここでは長谷川さんの打合せの予定に関する会話であることが分かります。打合せの特徴はなんでしょうか？打合せの主催者や参加者など、立場を意識して打合せを考えて見えてくるものが違いますが、ここでは、第3者からみた予定としての打合せの特徴を考えてみることにします。
最後に、コンセプトに従ってモデルを作成します。ここでは、UMLを使ってモデリングを行います。
モデリングはあくまでコンセプトをUMLで表現したものに過ぎませんが、実際にはUMLの図を作成すること
によって気づくことがあります。
コンセプトを図(モデル)として表現してみると、少し意図と違っていたり、
不足しているものが見つかったりすることがあります。
おかしいと思ったら前のステップに戻って考え直してみましょう。
例題では、いつ、どこで、だれが、なにをといった出来事（あるいはイベント）を「打合せ」という概念（クラス）で表します。ただし、"どこで"と"だれが"については、それぞれ「会議室」、「参加者」という独立した概念になります。なぜなら、打合せとは別に存在するモノだからです。
このように「打合せ」、「参加者」、「会議室」といった要素に分解できましたので、「参加者」と「打合せ」および「打合せ」と「会議室」の関係でクラス図が書けます(図 1)。
図 1 打合せ（クラス図）
「参加者」は複数の「打合せ」に参加できるし、「打合せ」には少なくとも二人以上の「参加者」が必要になるので、多重度はそれぞれ、 0..* ， 2..* と表現します。
「打合せ」はひとつの「会議室」で行われ、「会議室」は複数の「打合せ」が行われることから、多重度はそれぞれ、 1 , 0..* と表現します。
具体的な例で考えてみると、問題文にある商品企画の打合せ、キックオフミーティングという打合せは以下のようなオブジェクト図で表現することができます(図 2)。問題文にはありませんでしたが、Aさん、Bさん、Xさんはそれぞれの打合せに参加するものとします。
図 2 打合せ（オブジェクト図 1）
「XX打合せ」を追加してみると、以下のように、会議室で複数の打合せが割り当てられる様子を表現できます(図 3)。
図 3 打合せ（オブジェクト図 2）
初めからクラス図で考えるのが難しいときには、オブジェクト図を先に書いてみると整理しやすいと思います。
いかがでしたか。実際にソフトウェアを開発している人は「こんなモデルで役に立つの？」と感じられた方もいらっしゃると思います。 しかし、実際の開発では、開発対象のソフトウェアが大規模化、複雑化してきており、そのままで扱うと理解しにくいものになってしまいます。
まずは、一番重要な部分に焦点を絞って、根本的な特徴を掴むことが大切です。
それでは、今月の問題です。
ゆうじ君たちは以下のように連絡をとることになっています。
この状況をモデリングしてください。
図 4 お題（連絡網）
解答はクラス図で表現して下さい。クラスには必要な属性を、関連には多重度を明記するのがポイントです (解答時間の目安は15分～30分です)。
締め切りは 2006年 1月 5 日 (木) です。解答モデル送付期間は終了しました。
以下の項目を記入し、解答のモデルファイルあるいは画像ファイルを電子メールに添付の上、下記アドレスまでご送付下さい。
|
解答で頂いた個人情報につきましては、本連載記事の編集にのみ使用いたします。
お客様の個人情報は、当社の個人情報保護方針に基づき、適切にお取り 扱いいたします。また、ご本人の承諾なしに、第三者機関へ提供することはありません。
送付いただいた解答モデルの著作権は解答者に帰属しますが、モデルの複製、配布、インターネット配信を行うことをオブジェクトの広場編集部ができるものとします。 特に取り決めのない事項については、オブジェクトの広場編集部の判断により決定します。解答者がその決定を了解できない場合は、解答を撤回できるものとします。
モデルは手書きでも、ExcelやWordの作図機能を使って描いても OK です。以下に挙げるようなUMLモデリングツールを使って作成するのもOKです。
一般的なUMLモデリングツールであれば問題ありませんが、こちらで確認できないツールをお使いの場合には、画像ファイルをご送付願う場合がありますのでご了承下さいませ。
UML モデリングツールをお持ちでない方に朗報です。
弊社の UML モデリングツールである Elapiz スタンダードエディション の Elapiz Basic の正規ライセンス(\9,975
相当)を、毎号抽選で 3 名の方にプレゼントいたします。
Elapiz Basic のライセンスをご希望の方は、メールの文面に「Elapiz
ほしい」 と一言添えて、Elapiz Basic または Elapiz Pro の評価版 でモデリングしたモデルファイル (拡張子ast) をご送付ください。
プレゼントはElapiz Basic または Elapiz Pro 評価版ご利用の方限定です。
UML モデリングツールに不慣れな方は、Elapiz スタンダードエディション のチュートリアルがありますので、そちらをご参照ください。
なお、当選者の発表は、来月号にペンネームで掲載する予定です。
本連載では、以下の文献[1]を参考にしています。気軽にモデリングを愉しむことを主眼におくため、細かな説明が不足するかもしれません。モデリングに関してきちんとした解説が欲しい場合には、以下の書籍を参考にしてみて下さい。