|
[2005 年 5 月号] |
［レポート］
皆さんは UMTP の L2 試験を知っていますか？UMTP は UML モデリングスキルの認定資格の一つですが、その L2 （レベル 2）は、参考書がまだ 1 冊も出版されておらず（2005 年 5 月現在）、その試験内容が謎につつまれた資格です。
この記事は、オブジェクトの広場の "新人" 編集員が手探りで UMTP L2 突破をめざした受験記です。新人によるモデリング勉強会、そして UMTP L2 受験までの過程をまとめました。はたして受験の結末はいかに！？※この記事に UMTP L2 試験問題についての詳細はありません。受験者が試験内容について公開することは禁じられているためです。ご了承ください。
※また、この記事に掲載されている多数の UML モデルは、入社一年目の新人編集員が作成したものです。妥当性に欠ける点やツッコミどころも満載ですので、その点も併せてお楽しみください。
ことの始まり
ある日の「オブジェクトの広場」編集会議・・・
先輩： 「毎年新人君には UML ロボコン*1の参加記事を書いてもらってるんだけど、今年はロボコンが春にないみたいだから企画から考えて。ヨロシク。」 新人： 「えっ。厳しいですよ！読者の方に見てもらえるだけの記事書けるほど、技術的なスキルないですよ！」 先輩： 「スキルがないから記事になることもあるよ。例えばオブジェクト指向でも今から勉強する人にとっては新人君たちが一番近い視点を持っているわけだし。なにかテーマを決めて勉強することで、その過程を記事にしてみれば？」 新人： 「なるほど・・・。」 というわけで、UML の基礎知識はあるけれど実際のモデリングはあまりしたことがないオブジェクトの広場、 新人編集員（2004年度入社）の 6 人（乙村、佐々木、高橋、龍野、田邉、米田）が集まり、UML モデリングについての勉強会を開くことになりました。
その勉強会の最終目標として UMTP L2 取得を掲げたのが、この「UMTP L2 受験記」です。
*1今年からは ET ロボコンに名称を変え、7 月に実施されます。
UMTP L2 資格とは
UMTP は UML のモデリングスキルを認定する資格
今日、ソフトウェア開発者にとって重要なスキルの一つとされているモデリングスキル。あなたは自分のモデリングスキルがどのくらいか、気になったことはありませんか？
UMTP/Japan（UML モデリング推進協議会：https://www.umtp-japan.org/）は UML モデリング技術者の育成と、各分野における業務モデル共有の促進を目的とした特定非営利活動法人です。私たちが受験しようとしている「UMTP」は、UMTP/Japan が実施する「UML モデリング技能認定試験」のことを指しています。この試験により、受験者は自分のモデリングスキルを客観的に評価してもらうことができます。
試験はピアソン VUE 社（https://www.pearsonvue.com/japan/）を通して実施されています。申し込みを行った後、指定された試験場（公開テストセンター）に設置されているコンピュータ上で試験を行います。試験終了と同時に点数が計算され、受験者にはその場でスコアシートが渡されます。レベルごとに設定された合格点が取れていれば晴れて資格取得、となります。
UTMP L2 の難易度は？・・・結構難しいらしい
UMTP/Japan は UML モデリングスキルのレベルを以下のように 4 段階（ L1 〜 L4 ）に分類しています。現在実施されている試験は L1 と L2 の二つです。
（ UMTP/スキル体系表 ： https://www.umtp-japan.org/examination/index.html より抜粋）
レベル モデリングスキル 説明 L4 実践に基づいてモデリングを指導できる
・ L3 のスキルを有し、開発プロジェクトでモデリングを一定数あるいは期間実践した経験を持つ L3 実務でモデリングが実践できる
・ 拡張性や変更容易性の点で高品質なモデルを定義できる ・ ビジネスモデリング、分析、アーキテクチャ設計、組み込み開発を行うための専門的な知識を備えている（分野は選択） L2 UML モデルの読み書きが普通にできる（モデリングリテラシーがある）
・ 開発範囲の一部を担当し、モデリングができる ・ 他者のモデルの意味を理解できる L1 簡単な UML モデルの意味が分かる
・ UML などを使ってモデリングを行う最低限の知識を持っている L2 は第 2 段階目のスキルレベルです。
L2 の認定試験は 2004 年の 10 月から受験可能になったので、比較的新しい資格といえます。L1 はモデリング技能認定試験の開始から実施されている試験ですが、最も易しいスキルレベルで、試験の出題内容も UML の記法やオブジェクト指向の基礎知識が主なものでした。新人メンバーの中にも L1 資格を取得している人は多く、それほど難しい資格ではないように思います。
しかし、L2 では、スキルレベルの説明に、
- 開発範囲の一部を担当し、モデリングができる
- 他者のモデルの意味を理解できる
とあるように、単純なUMLの記法を知っているだけではなく、モデルが何を表しているかを正確に理解する能力、また表現したいモデルを正確にUMLで表現する能力が問われるようです。つまり、L2 のレベルは、実践で使えるモデリングスキルの基礎レベルといえます。実務での UML モデリングの経験があまりない新人にとっては、かなり手ごわい印象です。
モデリング勉強会
UMTP L2 取得に向けてどう勉強するか？
UMTP L2 の受験対策本はまだ出版されていません。また、まだ受験者数も少なく、試験に関する情報が極端に少ない状況です。
そんな中で、「UMTP L2 に合格」という目標を達成するために、必要な勉強は何かを考えてみました。UMTP L2 で問われる内容は、
- 開発範囲の一部を担当し、モデリングができる
- 他者のモデルの意味を理解できる
です。
そこで、私たちは題材を決め、モデリングの勉強会を開く！
という方法で、UMTP L2 の受験対策を行ないました。
勉強会で議論しながら１つのモデルを作成する過程を通じて、モデルを作成する能力と、他者が作成したモデルを理解する能力を身に付けることが目的です。モデリングの題材
モデリングの題材は、児玉 公信さんの著書「UML モデリングの本質」（参考文献 [1] ）から選び、「旅行代理店における航空券の予約システム」としました。
演習問題 〜 航空券予約の問題 〜 （ 「UML モデリングの本質」第 7 章 演習問題 より ）
旅行業の NIP 社は、国内線・航空券の予約システムを構築することにした。
東京（羽田または成田）-大阪（伊丹または関空）のように顧客が指定した地区間において、
各航空会社における便と料金、空席を一覧表示するオーソドックスなシステムだ。
ただし往復や乗り継ぎなどに対応できるように、一度に複数の航空券を予約できるようにする。
航空経路および便の検索・予約は、各航空会社が定めた手順（プロトコル）に従う。
その際には座席のグレードとして「スーパーシート」と「普通席」を設定する。
以下の機能を持つ航空便予約業務の支援システムのモデル（概念レベル）を作成してほしい。
1. 航空便の検索
窓口係は顧客の旅行計画に基づいて、候補となる航空経路と便を検索する
2. 航空便の予約
候補の便から空席を探して料金を計算し、予約するこのシステムの「概念レベルのクラス図の作成」と、「機能（航空便の検索と予約）の流れを表すシーケンス図の作成」を、勉強会の課題としました。
「UML モデリングの本質」第 7 章には、モデリングのテクニックやノウハウ、実際の概念モデルなどが多数掲載されていますが、このモデリング勉強会を行う際にはこれらを参照せず、題材だけを頼りにモデリングを行いました。
参加メンバー
勉強会の参加メンバーを簡単に紹介しておきます。モデリング勉強会は土曜日を使って 3 回ほど開催し、毎回 4 〜 5 人が参加しました。
- 乙村：
- 普段の業務 ・・・ 大型機械制御のためのプログラム作成。
- モデリングの経験 ・・・ 社内のモデリング勉強会*2（2.0h × 10 回ほど）。仕事では無し。
- 特徴 ・・・ モデリングの勉強よりプログラミングの勉強がしたい
- 佐々木：
- 普段の業務 ・・・ SE
- モデリングの経験 ・・・ 2 年ぐらい
- 特徴 ・・・ 格闘技マニア
- 高橋：
- 普段の業務 ・・・ プログラマー
- モデリングの経験 ・・・ 社内のトレーニングと勉強会*2に参加。現在、実務でオブジェクト指向設計に携わる。
- 特徴 ・・・ 航空業界マニア
- 龍野：
- 普段の業務 ・・・ システム開発
- モデリングの経験 ・・・ 新人研修時と 3 ヶ月間の要件定義業務にて経験
- 特徴 ・・・ 天然（←とよく周りから言われる）
- 田邉：
- 普段の業務 ・・・ 組み込みシステムの設計・実装
- モデリングの経験 ・・・ 社内のモデリング勉強会*2にちょこちょこ参加
- 特徴 ・・・ 「渡鬼」大好き
- 米田：
- 普段の業務 ・・・ トレーニング講師
- モデリングの経験 ・・・ 社内のモデリング勉強会*2に半年間参加
- 特徴 ・・・ 演劇マニア
ではでは、勉強会で行なったモデル作成の過程をご覧下さい。
*2モデリング能力の向上を目的としたオージス総研の社内勉強会で、与えられたお題を参加者がモデリングし、それぞれ作成したモデルについて議論します。今までのお題は「じゃんけん」、「待ち合わせ」など。勉強会の成果は、「思考系 UML モデリング 即効エクササイズ」にまとめられました。
初回の勉強会では、問題文を手がかりにドメインを分析し、クラスの抽出と、初期のクラス図の作成を行います。
弊社のトレーニング「UML オブジェクト指向分析・設計」の内容の一部や、前掲の「UMLモデリングの本質」（参考文献 [1] ）などを参考に、以下の手順で行いました。
- 問題文から名詞を取り出す
- 取り出した名詞の中から関連のありそうなもの同士をグルーピングする
- グループの中でクラスになりそうなもの、属性になりそうなものを探す
- クラス間の関係を検討する
1. 問題文から名詞を取り出す
方法
- 一人ひとり自分が取り出した名詞をポストイットに書き、テーブルの中央に貼り付けていく。
- 思いつかなかったら、パスする。
- 全員がパスするまで続ける。
問題文が限られているためか、ブレインストーミングのように際限なくアイディアが出てくることはありませんでした。次のような語句が抽出できました。
2. 取り出した名詞の中から関連のありそうなもの同士をグルーピングする
オブジェクトの構造はあまり意識せずに、関連のありそうなものをまとめます。グルーピング結果は次のようになりました。
3. グループの中でクラスになりそうなもの、属性になりそうなものを探す
各グループについて語句を検討し、概念を整理します。概念をはっきりさせるために、「4. クラス間の関係を検討する」作業も一部先取りして行いました。
「1（場所）」グループ
単純に、「地区」クラスのインスタンスが東京、大阪で、「空港」クラスのインスタンスが羽田、関空であると考えます。しかし、問題文からは、「地区」クラス、「空港」クラスの属性となるべき要素を導き出すことができないので、「地区」も「空港」もクラスにする必要はないかもしれません。
「2（座席）」グループ
「座席」をクラスと考えます。インスタンスは、「12 列の B 番席」、「43 列の H 番席」などになるでしょう。
「グレード」は「座席」クラスの 1 属性でしょうか？それとも「座席」クラスのカテゴリとして別クラスにすべきでしょうか？
ここで意見が 3 つに分かれます。
- （1）属性で良い
- （2）クラスにしておくと、グレードごとの振る舞いを独立させることができるから、クラスのほうが良い
- （3）どちらも分類の実装方法なのではないか
この時点で結論を出す必要もないので、保留することにします。
次に、「空席」の取り扱いを考えます。一つ一つの座席が空席かどうか、という観点で捉えると、空席は「座席」クラスの属性と考えることができます。しかし、航空券を予約する際には、空席があるかどうかを便ごとに知る必要があるので、「便」とも関連がありそうです。
結論として、「便」クラスには「空席数」という属性を持たせ、「座席」クラスには「空席かどうか」という属性を持たせることにします。これで、便ごとに予約できる座席の数（空席数）を知ることができ、予約する座席を具体的に指定することができます。
「3（経路）」グループ
「経路」と「航空経路」は同じ概念なので、問題文に従って、「航空経路」クラスに統一します。また、対象システムは国内線専用の予約システムなので、「国内線」という概念は不要と考えます。
「4（要望）」グループ
問題を整理すると、「旅行計画」には往復かつ乗り継ぎという場合があり、乗り継ぎは、地区間に複数の航空経路があるものを指します。
ここでは、「旅行計画」クラスと、「地区間」クラスを作ることにします。
以下の図のように、「旅行計画」から「地区」に対して 2 本関連を引き、ロールを「目的地」、「出発地」にすれば良いのではないか、という意見もありましたが、「旅行計画」に複数の地区間のフライトがあった場合、「目的地」と「出発地」の組み合わせがわからなくなってしまいます。
「5（人）」グループ
「窓口係」はアクターであり、システムの範囲外と考えられます。責任の所在を明らかにするために、予約を担当した人間の情報が必要である可能性もありますが、今回は対象外とします。また、「一覧」はドメインの本質とは無関係なので、概念レベルではクラスにしないことにします。
「顧客」については、システムに含めるかどうか、他クラスとの関連を考えて、後ほど検討することにします。
「6（料金）」グループ
「料金」は、何れかのクラスの属性になりそうです。また、「計算」は、何れかのクラスの操作（メソッド）になるかもしれません。
「7（予約）」グループ
「予約システム」は対象システムそのものなので、ここでは「予約」クラスを作成します。
「8（便）」グループ
座席グループの検討ですでに言及しましたが、「便」クラスを作成します。「候補の便」は、「便」クラスのインスタンスを指していると考えます。
4. クラス間の関係を検討する
これまでに挙がったクラスとクラスの関係を検討し、初期のクラス図を作成していきます。その過程で、さまざまな議論が起こりました。
「航空券」はクラスか？
クラスではない。ドメインの本質を捉えたモデル要素（クラス）ではなく、モデルから取り出した特定の情報を一時的に表現するビューと考える。
「予約」と「便」の関係は 1 対 1 か？
1 つの便には複数の予約が存在し得るので、1 対多になる。
「旅行計画」、「地区間」「航空経路」の関係は？
旅行計画の中に 1 つ以上の地区間があり、地区間の中に 1 つ以上の航空経路がある。
「航空機」クラスは必要ないのか？
座席数は航空機（機種）によって異なるものなので、あっても良い。
「予約」と「座席」の関係は 1 対 1 か？
座席が予約されるときに、「予約」インスタンスが 1 つ生成され、1 つの「座席」インスタンスと関連付けられると考える。
「予約」は「地区間」と「旅行計画」の関連クラスになるのでは？
「旅行計画」に基づいて、「地区間」を「予約」する、という関係になるのではないか。
「料金」の位置づけは？
旅行計画の合計料金ではなく、1 フライトあたりの料金を指すものと考えると、航空経路に対して料金が決まっているので、「航空経路」クラスの属性になる。その際、グレードも考慮しなければならない。
検索はどのクラスの責務か？
概念モデルではエンティティに着目するため、検索という機能の責務は今は考えない。
「顧客」クラスは必要ないのか？
旅行計画が地区間を予約する、と考えるより自然なので、「顧客」クラスを追加する。
「顧客」と「旅行計画」は 1 対 1 か？
顧客を永続化しなくて良いなら、1 対 1 で OK。問題文をそのまま読んだだけでは永続化が必要であるとは考えられないし、無闇に個人情報を収集するのは良くない。
しかし、顧客情報を登録しておけば、2 回目以降に利用する際に個人情報を再記入する手間が省けたり、ポイント（マイレージ）プログラムが利用できたり、というメリットもあるので、ここでは顧客を永続化すると考え、顧客と旅行計画は 1 対多とする。
「顧客」―「予約」、「顧客」―「旅行計画」、の関連はどちらか 1 つで良いのではないか？
次のようなシナリオで、オブジェクト図を描いて考えてみる。
- シナリオ
- 沖縄に住む「A」さんは、「雪祭り見学」のため、「2 月 5 日の那覇 → 札幌 間の便」と、「2 月 6 日の札幌 → 那覇 間の便」を予約する
- 「顧客」が「予約」する場合（パターン 1）
「顧客」が「予約」する場合のクラス図 「顧客」が「予約」する場合のオブジェクト図
- 「旅行計画」が「予約」する場合（パターン 2）
「旅行計画」が「予約」する場合のクラス図 「旅行計画」が「予約」する場合のオブジェクト図 「顧客」が「予約」すると考えたほうが自然なので、パターン 1 を採用する。
「旅行計画」クラスが持っている属性は？
日付と複数の地区。
「予約」クラスの責務があいまいではないか？
もともとは「旅行計画」と「地区間」の関連クラスだったはずだが、属性が明らかにできていない。次回の勉強会で再検討する。
全体的に関連が多い
クラスの責務が明確でなく、要素の粒度にバラつきがあることが原因と考えられる。次回以降で再検討する。
便とフライトを混同していないか？
確かに、両者の概念の違いが表現できていない。「便を予約する」と言ったとき、「便」とは特定の日付の便、つまり一回の「フライト」を指していると考えられる。問題文がドメインの重要な概念に言及していないことに気づかなかった点は、反省として次回に生かしたい。
初期のクラス図
参加者のスキル不足が如実に現れ、最後はかなり混乱しました。次回は視点を変えて、クラス図の再検討を行います。
前回の勉強会まで、自分たちが作成したクラス図とにらめっこをしながら、このクラス図が正しいのか否かを検証してきました。しかし、検証すればするほど、新たな疑問が続出し、議論は迷宮入りに・・・。結局、各クラスがもつ情報や役割がわからず、検証方法も八方ふさがりの状態に陥ってしまいました。
そこで、本日の勉強会では、新たな視点やアドバイスをもらいながら分析を進めるために、先輩をゲストとして招きました。やはり先輩が加わると違いますね。相変わらず、クラス図を見てあれこれ議論しそうになっている私たちに、別の視点から解決の糸口を提供してくれました。それは、「問題文だけを見て考えてもこれ以上議論が発展しないので、システムの具体的な画面イメージを考えて機能が満たせるかを検討し、不足している情報や関連を見直してみては？」というアドバイスでした。そこで私たちは、クラス図をみて議論するのをやめ、このアドバイスに従ってシステム要件から想定できる画面イメージを作り、その後で、作成した画面イメージと前回までのクラス図とを比較し、その整合性をみることにしました。
どのような画面が考えられるか？
まず、どのような画面が考えられるかについて意見を出しあってみた後、各画面に必要な要素は何かを考えていきました。その結果出てきたものは下記の通りです。
タイトル 要素 検索条件入力ビュー 日付 出発地 目的地 検索結果ビュー 出発時刻 到着時刻 出発空港 到着空港 便名 料金 空席情報 以上の情報をもとにしてできた画面イメージが下記のものです。
しかし、出来上がったイメージに対して、以下の二点についてつっこみが入りました。
- 料金を決めるためには、座席のグレードが必要ではないか？
- 往復が考慮されていない！
以上の指摘を受けて画面イメージを再検討した結果、次のようになりました。
しかし、またまた画面に対するつっこみが・・・。
- 乗り継ぎが考慮されていない！
そこで、乗り継ぎを考慮にいれて、再度イメージの修正を行いました。その結果できた画面イメージが以下のものです。
乗り継ぎをする場合を考えると、出発地から目的地までの行き方として、直行でいく場合と、途中に別の空港で乗り継ぎをしてから目的地まで行く場合とがあることに気が付きました。つまり、乗り継ぎをする場合を考えると、同じ目的地にいく場合でも、その行き方は複数あるとわかったのです。このことから、出発地と目的地をつなぐひとつの地区間に対して、複数の航空経路が存在すると考えるべきであることがわかってきました。
画面イメージの作成を終えて 〜 クラス図との整合性を考える
一通りイメージが作成できたところで、クラス図との整合性を考えてみることにしました。
乗り継ぎを考慮したことで、地区間と航空経路との間に新たな関連のあることがわかりました。
（赤線でひかれている部分）第 2 回 勉強会の終わりに：宿題！
新たなクラスの存在が明らかになったところで、気がつけばお昼をとうに過ぎて午後に。。。 朝から始めてお昼抜きで検討していたこともあり、本日の勉強会はこれできりあげることにしました。 次回の勉強会までに、下記の宿題をやってくることを決めて、本日の勉強会は終了しました。
＜宿題＞
- 第 2 回の勉強会で考えた検索画面と予約画面が実現できるか、という視点でクラス図を考える。
- （※注）コントロールクラスや、作業中に必要を感じたクラスは自由にクラス図に追加する。
- 作成したクラス図をもとに、「検索」「予約」のシーケンス図を描いてくる。
次回に向けて
今回の記事では、第 1 回、第 2 回の勉強会でモデリングを行う様子を見ていただきました。
複数人の議論でモデルを作成するのがこんなに難しいとは思いませんでした・・・。
概念モデルとして、まだまだ及第点にはほど遠い状況です。「旧新人編集員が挑む！ 〜UMTP L2 受験記〜 後編」では、
- 第 3 回モデリング勉強会
- 先輩からのコメント、フィードバック
- UMTP L2 受験結果
についてお伝えします。
[1] 『 UML モデリングの本質』 児玉 公信／著, 日経 BP 社
[2] 『 はじめて学ぶ UML 』 竹政 昭利／著, ナツメ社
| © 2005 OGIS-RI Co., Ltd. |
|
