 |
[2007 年 10 月号] |
|
[2007 年 10 月号] |
[レポート]
| (株)オージス総研 オブジェクトの広場 |
UMLモデリング推進協議会(UMTP/Japan)が主催する Modeling Forum 2007 が2007年9月13日・14日の2日間にわたって開催されました。Modeling Forum はその名前の通り「モデリング技術」をキーワードに、最新の技術動向や、製品、ビジネスプロセス、開発プロセスなど様々なテーマを扱うイベントです。今年で4回目になります。今回は「情報資産価値創造とモデリング」をテーマに講演とデモ展示が行われました。
この記事では参加したセクションとデモ展示会場の様子について報告いたします。
本セクションは、責務駆動設計で有名な Rebecca Wirfs-Brock（レベッカ・ワーフスブラック）氏による講演です。タイトルには、「ワールドクラスの設計者になるためのスキル」とありますが、主な内容は次の2つでした。
レベッカ氏曰く、優れた設計者の資質は、次に挙げる5つだそうです。
時間の関係で、個々の項目については、あまり詳しく説明されていませんでしたが、「良い設計者( designer )は良い伝達者( communicator )でなければならない」と言う持論を強調されていました。「 Telling Your Design Story 」という言葉を多用しており、自分の考えた設計をいかに分かり易く伝えるか、ということを重視されているように感じました。
レベッカ氏の考える設計者とは、単純にシステムを設計するのではなく、自分で問題を掘り下げることができ、考えた内容をシンプルに整理し、プロジェクトに関わる様々な人とうまく協調し、利害関係者が納得いく成果を得ることができる人物と捉えているようでした。
講演の中核になっていたのが、優れた設計者がいかに設計を行うかでした。ここでは、その設計者が仕事を効率的に進めるための道具をいくつか紹介していました。
レベッカ氏は設計者が行わなければならないこととは、2つあると説明しました。
(1)の問題を正しく理解する時に有効なのが、マイケル・ジャクソン氏の「 Problem Frames 」だそうです。この Problem Frames は、以下の 4 つの基本的な Problem Frame を使って、問題そのものをパターンに当てはめて理解しようとするものです。
この問題フレームの詳細に関しては参考文献「 Problem Frames 」を参照してください。
次に、オブジェクト指向設計において有用な「オブジェクトロールステレオタイプ」、「 CRCカード」について紹介がありました。このオブジェクトロールステレオタイプとは、オブジェクトが持ちうる役割のバリエーションを6つのカテゴリに分類したものです。レベッカ氏の提唱する責務駆動設計では、以下の6つのロールステレオタイプを切り口に、オブジェクトへの責務の割り当てを設計していきます。
上記のようなカテゴリを見ると、オブジェクトの責務の分析は難しそうな印象を受けますが、実際には CRCカードという分析ツールを使いながら、楽しくグループワークのような形で分析を進めることができるとのことでした。オブジェクトロールタイプステレオタイプや CRCカードの詳細については、参考文献「オブジェクトデザイン」を参照してください。
問題フレーム、オブジェクトロールステレオタイプ、CRCカードなど、初めて知るものも多く、大変ためになる講演でした。「良い設計者とは良い伝達者である」という言葉を胸に留め、この講演で知りえた各種手法を学び、自分自身も優れた設計者になれるようにがんばろうと思いました。
SOMA (ソーマ)とは SOA をモデリングしたり、構築するためのデザインや手法をまとめたものです。IBM が作成したものです。講演者は日本 IBM ラショナル・テクニカル・セールスの和田氏です。ラショナルは UML やオブジェクト指向ソフトウェア開発であるラショナル統一プロセス( RUP )を開発したところです。現在は IBM の一部門になっています。
SOA を構築するとき、どのような手法を行えばよいのか、そのためのツールとしての RUP SOMA に関しての説明でした。特にSOMAで扱われる主要な成果物であるサービス・モデルを中心に解説されていました。 SOA の最も大事な部分であるサービスをどのように決定していくのか、とても興味がありましたので参加しました。
まず、 SOMA について簡単に説明がありました。
システム開発のライフサイクルとして以下のものが挙げられます。
SOMA の目的は、これらのフェーズの中で「いつ」、「どのようなことして」、「どのような成果物」を残せばよいのかを開発メソッドとして定義することです。 SOMA は IBM が今まで行っていたシステム開発手法に SOA の概念を加えたものになっています。現在、3種類の SOMA が IBM から提供されています。このうち SOMA2.4, SOMA3.1 は IBM のサービスとしてのみ提供されています。外部の人間が SOMA を使うには RUP SOMA を使わなければなりません。
SOMA の主要なプロセスは、「サービスの識別」、「サービス仕様の定義」、「サービスの実現」の３つです。これらのプロセスは反復的に実施されます。これらのプロセスのなかで作成される主要な成果物はサービス・モデルと呼ばれるものです。サービス・モデルとはサービスに関係する情報をまとめたものです。
それでは、SOMAのプロセスからサービス・モデルを作成していく方法を紹介します。
まず「サービスの識別」を行います。ここでは対象となるシステムを分析し、「サービスの候補」、「コンポーネント候補」、「ビジネス・フロー候補」を洗い出していきます。対象となる分析と、候補の関係は次の図のようになっています。
次に「サービス仕様の定義」このプロセスでは次の図にあるようなアクティビティを行いサービス・モデルの情報を構築していきます。
「サービスの実現」では、サービスの実現方法を決定します。技術的な調査などを行い実際にサービスを構築する方法について決定していきます。
以上のプロセスによって作られるサービス・モデルは UML2.0 を拡張した Profile for Software Services によって記述されます。
※講演では UML2.0 Profile for Software Services で記述された図を見ることができましたが、この記事には載せることができません。ご了承ください。 UML の各オブジェクトがアイコン化された図でした。
全体を通して、サービス・モデルの構築について重点を置かれた講演でした。 SOMA のサービス・モデル作成のアクティビティはSOA開発を行うときに必要なものばかりで、それらがスッキリとまとめられていました。私のように「SOAという言葉はなんとなく知っているけど、具体的にどうやってシステム構築していくの？」という人にとっては「要求」・「分析」の段階で行うアクティビティについて簡単に解かるようになるセクションだと思いました。
サービス・モデルを作成するときはシステムを開発する側とシステムを利用する側が相互に議論を重ね構築していくものだと思います。そのため SOMA の各アクティビティを反復的に行いサービス・モデルを構築していくプロセスはとても有効だと感じました。具体的に SOMA を適応した例などの話を聞きたいと思いました。
本セクションは、オブジェクト指向による分析設計におけるユースケースの問題点とその解決方法に関するものでした。鷲崎氏によると、オブジェクト指向分析設計におけるユースケースの問題点として2つが挙げられるそうです。
1つ目の問題点は、ユースケース駆動での開発において、ユースケースの段階では機能は分離されているが、ユースケースの実現を考えた際に、ユースケースを横断的に登場するクラスが出てきてしまうことだそうです。アスペクト指向でいう、本質的な関心事と横断的な関心事が混ざって現れてきてしまっている状態です。
2つ目の問題点は、要求に変化があり、あらたな機能追加をユースケース拡張で実現する場合、拡張元を変更せずに新機能を追加したいのに、拡張元に新機能を利用するためのロジックを挿入する必要があり、結局は拡張元も変更する必要があるとのことです。
このようなユースケース駆動開発である2つの問題点を、アスペクト指向プログラミングでは既に実現されている、「本質的な関心事と横断的な感心ごとを分ける」、「拡張による差分を新たに付け加える」のような手法をユースケースにも適用するというのが、本セクションでの提案でした。
これにより、モデルは本質だけを表現した状態で維持することができ、必要に応じて実装上必要なものを新たに付け加えることも可能になります。
時間の関係上、ユースケースに対してアスペクト指向の手法を適用する際の具体的な手法については十分解説されていませんでしたが、アスペクト指向の手法により、本質的なことと本質的でないことをうまく分離することができる点は、設計の質を維持する上では有用なものだと感じました。
また、現状では、アスペクト指向のユースケースに対応したツールがないので、人間の力で対処すべきことが多く、現場で利用するには現実的ではないようです。今後、ツールが対応するとかなり便利な手法になるのではないかと感じました。
本セクションは、組み込みソフト開発の現場におけるモデルベース開発をマネジメントするか上で、どのような点に気をつければいいのかを、パネルディスカッション形式で話し合うというものでした。
最初に、現状の組み込みソフトウェア開発の問題点とモデルベース開発の利点・欠点を確認しました。次に、モデルベース開発を導入する際の時間的な流れに沿いながら、各段階でのマネジメントのポイントについてディスカッションを行いました。
以下、議論のトピックです。
現状の開発で、ソフトウェアの品質劣化が起きる原因は、個人に依存した開発をしていること、全体を把握できなくなっていることなどが挙げられました。
前者に関しては、片山氏(太陽精機)によると、ソフトウェアが小規模だった昔の開発手法を継続してしまい、個人に依存した開発を行ってしまっていることが多いとのことでした。ドキュメントなどが残されていない場合が多く、担当者以外の人がメンテナンスすることが難しくなっているそうです。後者に関しては、杉山氏(ヤマハ)によると、現在のソフトウェアは大規模になってきており、全体を見通すことができなくなっているそうです。さらに、濱崎氏(オムロン)によると、ソフトウェアの規模をコントロールする術を持っていない事が問題とのことでした。複雑な仕様を複雑なままに実装してしまい、派生開発により複雑さが他の製品に受け継がれしまうことが多いようです。
上記の問題に対し、モデルベース開発の利点は、ソフトウェアを見える化することで組織として成果物を管理できるようになる、派生開発の際に再利用のポイントが判断しやすくなる、などがあるとのことでした。
片山氏(太陽精機)によると、モデルによりソフトウェアを見える化することで、これまで個人に依存していた成果物を組織として管理できるようになるとのことでした。さらに、後藤氏(デンソー)によると、派生開発を行う上での再利用化のポイントが考えやすくなるようです。
一方で、モデルベース開発の難しいところとして、モデリングの難しさとモデルベース開発が向かない場合があることが指摘されました。
濱崎氏(オムロン)によると、モデリングは設計者のセンスに依存する部分が大きく、モデルを構築していく過程のノウハウを形式知化し、メンバーに伝えることは難しいとのことです。また、後藤氏(デンソー)によると、一製品向けのソフトやハードウェアで検証しながら開発するソフトウェアにはあまり向かないとの意見もありました。
杉山氏(ヤマハ)によると、エンジニア出身の経営層の方は、昔の組み込みソフト開発の意識が残っており、「ソフトは簡単で安くつくれる」と考えている方が多く、モデルベース開発を導入する必要性を感じていない人が多いとのことです。経営層を説得する上では、モデルベース開発の必要性を説明するだけでなく、裏で十分に準備をしてからうまくいく根拠を示すことも重要とのことでした。
一方で、後藤氏(デンソー)によると、他のプロジェクトメンバーからは，本当にモデルベース開発がうまくいくのか冷静に見られている場合が多いそうです。今後、他の開発にも展開していくことを考えると、周辺グループと常に良好な関係を維持し、飲み会などのフランクな場で徐々に説得していくなどの工夫をすると良いとのことでした。
後藤氏(デンソー)によると、現状の開発に疑問点を感じている人、新しいことを学びたいと考えている人は多く、モデルベース開発に興味を持っている人などに参加してもらっているようです。ただし、現行開発の方が向いている人など、本人の適正などを考慮するようです。また、現行の開発を改善していくためのモデルベース開発であっても、現行開発を尊重するバランス感覚が重要とのことでした。仕事の分担を考える上では、現行開発を担当しているメンバーよりも、モデルベース開発を行っているメンバーの方が若干負荷が高くなるようにしているそうです。このような分担になり、仕事が忙しくなっても、新しいことを学んでいる楽しさにより、生き生きとして働いているメンバーが多いとのことです。
現行開発とのバランスに関しては、パネリスト全員が現行開発を優先するべきとの意見を述べていました。現行開発を助けるためのモデルベース開発であり、現行開発を行っているプロジェクトのメンバーから理解を得るためにも、現行開発をおろそかにしてはいけないとのことでした。片山氏(太陽精機)は、予算やスケジュールに余裕を持たせておき、モデルベース開発に人員を割り当てることができるようにしておく工夫も必要とのことでした。
濱崎氏(オムロン)によると、開発中にあらゆるデータを取得しておき、以前の開発に対して、どう変わったにか客観的に分かるようにしておく事が重要とのことでした。経営者に説明する上では、コストの面だけではなく、開発期間をどのくらい短縮できるかなどを示せると良いそうです。
モデルベース開発を他のプロジェクトに展開していく上では、データによる客観性だけでなく、開発に参加したエンジニア自身の成功体験が重要とのことでした。
本セクションは、冒頭にも書いた通り、モデルベース開発を技術の面からではなく、マネジメントの面から議論するというものでした。現行の業務とバランスを保ち、経営層に対しては新しい取り組みの必要性と有効性を示し、現場のエンジニアには小さな成功体験を積ませるということがキーポイントではないかと感じました。
また、パネリストの方々が、マネジャー自身が確信を持ち、メンバーに成功を実感させることの重要性を繰り返し述べられており、新しい取り組みを進めていく上では、現場で実践する立場のエンジニアの心の問題が重要なのだと感じました。
このセクションは他のセクションとは違います。１人の講演者が壇上で話し、それについて参加者が聴いているタイプではなく、参加者が手を動かし「 UML のモデルを書いていこう」というセクションでした。初めのモデルは１人で描きましたが、途中からグループを組んで議論をしながらモデルを構築していくようになりました。グループの人数は3、4人でした。
参加者は「UMLを使ってモデルを描いたことはない。今回が初めて」という方と「描いたことはあるけどイマイチよくわからない」という方がほとんどだったと思います。私は後者でした。
オブジェクト倶楽部の2人の方の小芝居からスタートしました。内容は小学生の子供を持つ2人の親の会話でした。会場全体が他のセクションとはちょっと違う柔らかい雰囲気になりました。そこから「今の話をモデリングしてみましょう」という掴みで、モデリングワークショップは始まりました。とりあえず「小学校」のモデリングを1人で考えて書いてみようという内容でした。モデルはクラス図でもオブジェクト図でもなんでも構わない自由なものでした。
そのときに私が描いたモデルは次の通りです。
一応、クラス図のつもりで書きました。字が汚いですね。申し訳ありません。
登場人物は、「親」、「子」、「先生」。それらの要素に、「宿題」、「クラス」、「小学校」が関係しています。途中、「学年」という概念が出てきて、あわてて関連を引きなおしています。また、「子」、「親」というクラス名よりも「生徒」、「保護者」の方が小学校のモデリングとしては適切なのではないかと考え、書き直しています。
他の人のモデルを見てみると、オブジェクト図のようなモデルを書いている人が多くいました。
ここからは1人ではなくグループで１つのモデルを描くことになりました。モデルの発展ということで今度は「中学校」のモデルを描きました。下にある出されたお題はオブジェクト倶楽部から引用させて頂きました。
お題その１ 中学校
１．天野さんには中学生のお子さんもいます。名前は天野尼子さんです。
２．天野尼子さんは 1 年 Ａ 組です。
３． 1 年 Ａ 組の担任は山田山夫先生です。
４．山田山夫さんは、国語教諭です。
５． 1 年 Ａ 組の国語の授業は、担任の山田山夫先生が受け持っています。
６． 1 年 Ａ 組の数学の授業は、村田武蔵先生が受け持っています。
７．村田武蔵先生は数学教諭です。
８．村田武蔵先生は ２ 年 Ｂ 組の担当です。
９．学年は、 １ 年から ３ 年までの ３ 学年です。各学年には、 Ａ から Ｄ までのクラスがあります。
「小学校」と「中学校」の違いは、小学校では担任の先生がほとんどの授業を行いますが、中学校では教科ごとに担当の先生が違うというところです。議論になったのもその部分でした。「担任の先生」と「教科担当の先生」２つの役割があるので、それを表現するのにどのグループも苦労していました。
私たちのグループは「授業」という概念を作って「先生」の２つの役割を表現しました。私たちのグループが描いたモデルは次の通りです。
今、このモデルを見てみると直したいところがあります。「科目」の項目は「授業」の属性であってクラスの概念として抽出しなくても良かったのではないかと思います。
他のグループでは「担任」と「教科担当」２つのクラスを作ったり、「先生」クラスから２本の関連を引いたりして表現していました。
次に先ほど描いたモデルに追加要素を加えていきます。これが「ゆさぶり」です。新たな要素も、元のモデルを修正することなく加えることができれば元のモデルは優れたモデルであるといえるそうです。全体の追加要素と、チームごとにおまけの追加要素があり、考えなければならいことが多く出てきました。
お題その２ 中学校発展形
１．天野尼子さんが通っている学校は、立春中学です。
２．立春中学の校長は村上春来先生、副校長は金田春彦先生です。
３．海原さん家には、海原大洋さんという中学生がいます。
４．海原大洋さんは、秋分中学に通っています。
５．秋分中学の校長は和田秋子さんです。
お題その２ 追加要素①
１．和田秋子先生は、立春中学から転任して校長先生になりました。
２．天野尼子さんの友達だった土田強志さんは、転向してしまいました。
３．小学生だった天野次郎さんが、立春中学に入学しました。
４．天野尼子さんは、 1 年 A 組から学年が上がり、 2 年 A 組になりました。
お題その２ 追加要素②
１．山田山夫先生は国語教諭です。村田武蔵先生は、数学教諭です。
２．国語教諭、数学教諭はそれぞれの教科に対応した免許を持っています。免許がないと、対応した授業はできません。
３．山田先生は各クラスの国語を受け持っています。村田先生は、 １ 年 A 組と 3 年全クラスの数学を受け持っています。
４．坂田咲子先生は、美術の免許を持った美術教諭です。
５．立春中学では、美術の教諭は担任を持たないことになっています。
お題その２ 追加要素③
１．天野尼子さんはテニス部です。村田武蔵先生がテニス部の顧問です。
２．海原大洋さんは陸上部とマンガ部をやっています。
３．テニス部も陸上部も自分の学校のグラウンドで練習します。
４．テニス部や陸上部は、地域にある市立の施設で練習することもあります。
私たちのグループは追加要素②を担当しました。時間が少し余ったので追加要素③もモデルに組込ました。次のようなモデルになりました。
発展課題の「副校長先生」がいる学校といない学校があるのは、「副校長」と「中学校の」関連の多重度「0..1」で表現しています。担任するクラスを持たない先生がいるのは、「先生」と「クラス」の関連の多重度「0..1」で表現しています。また部活に関係するクラスが作られ、関連が引かれています。今、このモデルを見直してみると「部活」と「施設」の多重度が「*..*」になっているのはもう少し掘り下げる必要があると感じています。
中学校のモデリングをする際、一番苦労するのが「先生」の存在でした。今回のモデルでは「担任」「教科担当」「顧問」の３つの役割があり、これらを表現するのが難しかったです。模範解答では３つの役割を役割クラスとして抽出して表現していました。「なるほど、こうすればよいのか」と思いました。とても勉強になりました。
グループを組んで議論をしながらモデルを構築していく過程はエキサイティングで楽しい時間でした。議論が白熱し、時間があっという間に経ってしまい制限時間内にモデルを描けないなんてこともありました。モデルを描く難しさと楽しさがわかるセクションだったと思います。
私は、弊社オージス総研の「モデルベースSOA」の説明員としてデモ展示会場にいました。ここでは簡単に会場の雰囲気について所感を交え報告したいと思います。
デモ展示会場には出展社が各ブースを出し、製品のデモやソリューションの説明を行っていました。各セクションの合間に足を運ぶ人が多かったようです。特にブースに出展している会社のセクション後には、その会社のブースに多くの人が集まりました。一番人気はくじ引きのコーナーでした（笑）セクションが終わるごとに長蛇の列ができていました。
１日目には Rebecca Wirfs-Brock （レベッカ・ワーフスブラック）氏の著書「オブジェクトデザイン ～ロール、責務、コラボレーションによる設計技法」のサイン会が開かれ賑わっていました。
SOA に関わる製品やソリューションを展示していたコーナーがいくつかあり、それらを順々に見ていく方が見られました。パンフレットを片手に技術談義に花を咲かせたり、「 SOA って何なの」といった質問を投げかけていました。 SOA に関する関心が高まっていると実感しました。
また弊社のブースには「組み込みソリューション」のコーナーもあったため、メーカーに勤めている方も多くおられました。何人もの方が、「組み込みの世界もだんだんハードウェアの性能が上がり、それに伴って組み込みソフトウェアは巨大に複雑になっている」と話していました。システムを俯瞰するための「見える化」そのためのモデリングは非常に重要だそうです。組み込みの世界でモデリングが必要不可欠なものになりつつあることを肌で感じました。
エンタープライズの世界だけではなく組み込みの世界にもモデリング技術が深く浸透しつつあることを感じました。ビジネスの世界にもモデリング技術が浸透しはじめ、今回のテーマである「情報資産価値」を創造する手段としてモデリングが担う役割はますます大きくなっているのではないでしょうか。
2年前の Modeling Forum 2005 では「 SOA 時代のビジネスモデリング」がテーマになっていました。今回の Modeling Forum でも SOA 絡みのセクションは多く発表され、各ベンダも SOA 対応の製品を紹介していました。 2005 年には萌芽だった SOA は確実に広まり、１つの流行になっています。これから SOA 化はますます進むと思います。
| © 2007 OGIS-RI Co., Ltd. |
|
