ObjectSquare

[レポート]


モデリングライブ 〜隣の開発を覗こう〜

[組み込みソフトウェアシンポジウム 2003 参加レポート]

UML ソリューション部
永田 博靖
Nagata_Hiroyasu@ogis-ri.co.jp

0. 10 月 X *1

同僚から今度の組み込みソフトウェアシンポジウムには、2 日間連続でモデリングを実演するモデリングライブがあるというのを聞きました。組み込みを学びはじめてまだ 3 ヶ月と少しといったひよっこエンジニアの私でも、非常に興味深い内容です。どのような形態で実施するのか、モデリングをどのように実演するのか、モデリングの題材は何を使うのかと「モデリングライブ」という響きからさまざまな疑問、想像が膨らみました。

本レポート記事は、「モデリングライブ」という言葉を聞いて、私と同じようにその全貌について興味を持ったエンジニア向けへの記事です。モデリングライブで実演された各種モデリング技法のエッセンスについて紹介するレポート記事ではありません。本来であれば、上級モデラーのモデリングの過程から知り得た情報をお伝えすべきなのですが、組み込み初心者の私にとってはそれを読み取るだけの力量がありませんでした。しかし、私の理解できる範囲で、モデリング技法に関する知り得た情報を本記事で紹介したつもりですので、その情報が少しでも読者のスキルアップのお役に立てればうれしいです。

*1細かいですが、X は 0 < X < 16 の整数です。

1. セッションの概要

コーディネータ

佐藤 啓太(株式会社デンソー

概要

モデリングライブについて、組み込みソフトウェアシンポジウム 2003 で配布された論文集 [1] には以下のように記載されています。

組み込みソフト開発は発展途上にあり、より良い開発の追及と技術の向上が日々試みられている。しかし、一般に組み込みソフト開発は営利活動であり、開発に関する情報が公開されることは稀である。このことが国内の組み込みソフト開発技術の向上や教育、そして研究に対して大きな障害となっている。

本ワークショップは 2 日間という学会のワークショップとしては長い時間をかけて、技術書、技術雑誌などで情報を発信している技術者や開発に対して指導するコンサルタント自らが、提示された課題に対して開発を行い、その過程を通して組込み開発に関する様々な情報を公開する。ワークショップ参加者は分析、設計、実装など各工程への入力情報をモデラが紆余曲折しながらどのように次工程への出力情報に変換していくのかを知り、その意図をモデラと共に議論し、アドバイスするなど全員参加型のワークショップを目指す。

つまり、組み込みソフトウェア開発では、自社以外の開発方式がわからなかったり、良いモデリングの視点の情報が公開されていなかったりするので、それをモデリングライブの場を通して参加者がモデリングの技法を知り、今後の開発方式の選定やスキルアップ、教育、研究に役立ててもらおうというのが狙いのようです。また、取り上げる課題を組み込みソフトウェア開発向けの標準課題として位置付けたいという思いも含まれているようです。

私は、このような背景、目的を事前に知らないまま、モデリングライブに参加しました。他の組み込みソフトウェアシンポジウム参加者のモデリングライブへの注目度はというと、40 人ぐらいの人が収容できる部屋に 9 割ぐらいの人が集まったといった感じでしょうか。両日実施され、いつでも参加できるという状態でしたので、両日とも満席というような感じではありませんでした。しかし、多くの方が出入りしていましたので、シンポジウムの参加者の興味を惹いた企画だったと思います。

さて、気になるモデリングライブの内容ですが、以下のような形態で実施されました。自動販売機の模型

課題の自動販売機の仕様も、実際に自動販売機を作成している人が決めたようなので本格的です。ちなみに、実際の自動販売機の仕様がある程度確立されており、製作サイドが仕様を公開しても良いかなということで今回の題材として利用されることになったそうです。

モデリングライブのスケジュールは、以下のようになります。予定では、モデリングの時間は 4 時間半ということでしたが、初日( 16 日)の仕様確認が午後にずれ込んだので、さらに作業時間は短くなっています。

16日 11:00 〜 12:00

モデリングライブ説明
チーム紹介
機能仕様説明
ソフト仕様説明
ハード仕様および評価機説明
仕様確認

  13:30 〜 16:30 モデリング
  16:30 〜 17:00 中間成果発表
仕様変更提示
17日 11:00 〜 12:00 モデリング
  13:30 〜 14:00 モデリング
  14:00 〜 15:00 最終成果発表
質疑

それでは、モデリングライブの内容について以下でレポートします。

2.題材は自動販売機

自動販売機の模型

モデリングライブの題材は、自動販売機です。この題材はモデリングライブ用に用意されました。また、自動販売機のハードウェアも用意されていて、LEGO Mindstorms で製作した自動販売機の模型を使うということでした。自動販売機の各種仕様は EEBOFモデリングライブのページにありますので、そちらを参照してください。ちなみに、この自動販売機の模型は貸して頂けるそうで、モデリングした方は、是非、実際に動作するか検証してみてくださいとのことです。

さて、自動販売機の仕様ですが、機能仕様書に関しては事前に通知されていたようです。ソフトウェア仕様書、ハードウェア仕様書に関しては、このモデリングライブにおいて初披露ということです。ソフトウェア仕様書とハードウェア仕様書に関しては、それぞれ製作者の森さん(東海ソフト)、井上さん(武蔵工大)より説明がありました。

仕様はわざと曖昧に作ってあるということです。できるだけ、現実性をかもし出すため不完全に記述しているということでした。ということで、あいまいな仕様の確認が重要となってくるのですが、モデリングライブでは、以下の質問が行なわれました。ここでは、追試ができるようすべての質問について記載しています。

Question Answer

商品とは何?

缶ジュース。
入金は何? コイン、千円札。
出金は何? 未定義だったので、最小枚数で出金するということに。
ソフトウェア仕様書にある「0 円の設定は売り切れ表示とする」とあるがこれは、ハードウェア的な仕様か? 価格設定として 0 円を設定すると売り切れとなること。
釣り切れセンサーが ON という状態はどういうときか? 釣り切れセンサー ON はお釣りが払えない状態のこと。
ON になるまでは、金種によらず必ず 9 枚以上あるということ。
減算とは? 金額をとるという意味。
偽札の対応は? 考えない。
取扱い中の条件が満たされなかったときどうなるのか? 停止したまま。停止中のときに外部に通知するかどうかのその他の動作は今のところ考えていない。
入金の千円札の最大枚数は? ハードウェアの仕様により 10 枚まで。
釣り切れセンサーはハードウェアとして用意されているのか? ない。ソフトウェア内部でカウントする。
入金のコインの最大枚数は? 金種に付き 100 枚まで保有可能。
払い出すときに、購入時に使ったお金を利用できるのか? 利用可能。
実装言語は何か? C 言語で実装する予定。

上記以外の質問として、「出題者が仕様のあいまいな部分が何であるか理解しているのかどうか?」という質問もありましたが、これに関してははっきりとした回答がありませんでした。

さて、モデリングライブでは、モデリングライブの途中で仕様変更を行なうというイベントが盛り込まれています。モデリングの結果が、仕様変更によってどのように変化するのかを見ることで、モデルの頑健性をチェックしようというものです。しかし、実際は、各チームのモデリングの作業が思うように進んでいなかったので、仕様変更がモデルに影響を与えることはありませんでした。

モデリングライブで行なわれた仕様変更は、以下の 2 つです。

  1. POS 端末に故障情報、日報、月報を送信したい。
  2. 後払いができるようにしたい。

1 つ目は、販売履歴に関する変更で、故障情報や日報、月報を送信できるよう自動販売機内でそのデータを保存しておいてほしいということです。2 つ目は、販売方法に関する変更で、「入金してから商品選択をする」前払いだけでなく、「商品選択から入金をする」後払いもサポートしてほしいということです。

3.参加チーム

モデリングライブに参加したチームは、SESSAME WG2 と EEBOF の 2 チームです。両チームとも組込みソフトウェア管理者・技術者育成研究会 (SESSAME) に所属している方々です。各チームの詳細は、モデリングライブのページにチーム紹介がありますので、そちらを参照してください。ここでは、各チームの特徴をピックアップして紹介します。

SESSAME WG2 チーム

チームリーダの森原 剛さん(オージス総研)と斉藤 賢一さん(リコー)、福田 朋紀さん(リコー鳥取技術開発)の 3 名で構成されたチームです。オブジェクト指向歴 6,7 年の方々です。

SESSAME WG2 チームでは、再利用可能な分析モデルの作成を目指すということを目標に掲げておられました。実施する作業としては、ドメイン分析、要求分析、分析モデリングの 3 つの作業です。分析モデリングの作業は、さらに 3 つに分けていて、静的分析、動的分析、検証と洗練化の作業がありました。実機上での実現までは検討しないということでした。

チームリーダの森原さんは、これらの作業の中でも、ドメイン分析を重視し、また、分析モデリングの静的分析では、モデリング方針を決定することと、クラス候補を抽出することの 2 つの作業に特に時間をかけたいと言っておられました。EEBOF チームに比べて人数は 3 人と少ないですが、「トリオモデリングでがんばります!」、とモデリングライブに対する意気込みを語っておられました。しかし、実際は EEBOF チームより人数が少ないため、コーディネータの佐藤 啓太さんのご配慮により、モデリング開始時に EEBOF チームから、佐熊 伴晃さん(東海ソフト)、田邊 和士さん(冨士電機リテイルシステムズ)が参加することになりました。従って、計 5 人のチームです。

SESSAME WG2 チームの成果物としては、以下を挙げています。

コンテキストダイアグラムは、ユースケースモデルを補完するもので、対象システムと外界との境界を記述した DFD です。また、モデリング指針の図解は、目に見えない概念的なクラスを無理なく抽出できるよう作成するということです。

EEBOF チーム

安富 大輔さん(豆蔵)と佐藤 洋介さん(デンソー)をリーダとしたチームです。コーディネータの佐藤 啓太さん(デンソー)、ソフトウェア仕様を作成した森 康さん(東海ソフト)、評価機を作成した井上 大祐さん(武蔵工大)がメンバとして参加しています。メンバの入れ替わりが激しかったので、メンバーに漏れがあるかもしれませんが、他にも加藤 正紀さん(横河ディジタルコンピュータ)、伊藤 恭直さん(東海ソフト)、高島 美弥子さん(横河ディジタルコンピュータ)が参加されています。

EEBOF チームでは、ドメイン開発と関心の分離を目標として挙げています。ドメイン開発では、自動販売機とは何か、という本質を考えることで、仕様変更に柔軟に対応できるものを目指すということです。関心の分離では、システムをサブシステムに分割することで、並行作業による開発効率の向上を目指します。モデリングライブでは、ドメイン開発の方を特に重視するということでした。

4.モデリング結果

モデリングの作業は、チーム毎に並列に行なわれます。従って、両チームのモデリングの作業を見ることはできません。私は EEBOF チームのモデリング作業を主に見ていました。

両チームのモデリングライブの成果物については、EEBOFモデリングライブのページが用意されていますので、そちらをご参照ください。ここでは、モデリング時間、中間発表、最終結果発表を通して知り得た両チームの作業内容について簡単に記載しています。両チームの共通点としては、分析を行なうことによって自動販売機の本質を掴もうというところです。相違点は、それを作るための手段で、EEBOF チームは ROOM 法 [2] ベースで、SESSAME WG2 チームは、ExecutableUML 法 (Shalaer Mellor 法) [3] ベースであるということです。

SESSAME WG2 チーム

SESSAME WG2 の作業内容は、中間発表、最終結果発表の内容をもとにしているので、詳しい内容はわかりません。

まず、ドメイン分析ということで、自動販売機を複数の問題領域(ドメイン)に分割していました。「販売」、 「金銭授受」、「商品搬送」、「在庫管理」、「履歴管理」、「表示」、「メカ」のドメインに分割されています。「商品搬送」、「在庫管理」のドメインは分けるかどうかが微妙ということで、まずは一緒として進めていました。その作業に並行して、仕様書にある専門用語を整理するということで、用語辞書を作成されています。そして、用語辞書の各用語が、どのドメインが管理すべきかを検討し、各ドメインの役割を明確にされていました。

この後は、「販売」、「在庫管理」、「履歴管理」だけを取り上げてモデリングを行っています。商品購入フローのシナリオを作成し、ドメイン毎のユースケースを検討します。「販売」ドメインのユースケースを洗い出す際には、コンテキストダイアグラムを利用されていました。コンテキストダイアグラムによって、「販売」ドメインと関係する「金銭授受」、「在庫管理」、「履歴管理」、「表示」ドメインとのデータフローがわかるので、そこからユースケースが検討できるということでした。その他、「販売」ドメインにおける静的分析を行ない、販売に関するクラス図を作成しています。ちなみに、ユースケースモデルの粒度は、Cockburn [4] の要約レベル(凧)で統一したということでした。

ドメイン分析に時間をかけてしまったため、当初予定していた動的分析あたりまでは出来なかったという感じです。

EEBOF チーム

EEBOF チームの作業については、 EEBOF のモデリングドキュメントのページに詳しくまとめられているので、それを見ていただくことが一番わかりやすいかと思います。以下、簡単に作業内容をまとめています。

EEBOF チームの作業風景まず、自動販売機の本質は「販売」であるということに注目し、それを起点としてモデリングを開始していました。次に、販売は、一般的に「受注」、「納品」、「入金」の 3 つの業務を行なうことで成り立つということなので、その 3 つの業務から販売というユースケース記述を検討していました。商品によって、受注方法、納品方法、入金方法が変わるので、販売というユースケース記述を考える際には、できるだけ変更のないものだけを書き、販売の本質を捉えるようにしていました。

次に、販売を取り巻く概念を考えていました。販売を取り巻く概念を考えた場合も、「受注」、「納品」、「入金」の概念が関係します。各概念の責務を明確にするために、ユースケースを利用していました。ユースケースは 2 項関係であるので、2 つの関係する概念間で、一方の概念をアクターとして考えると、他方の概念のサービスが洗い出せるということです。

ユースケースによって各概念の責務を明確にした後は、仕様書から抜き出した各種ボタンがどの業務の概念で管理すべきなのかを検討していました。また、各概念の責務が明確になったので、各概念の名前を変更しています。「入金」を「金銭管理」、「受注」を「受注管理」、「納品」を「商品管理」と変えています。

EEBOF チームは、業務を示すコントロール、ユーザとインタラクションするバウンダリを最初に検討し、後からエンティティを検討するというような方針に感じました。ここまでが、初日( 16 日) の作業です。

2日目( 17 日)は、チーム内で作業を 2 つに分けて分業するような方針をとっています。販売に関するユースケース記述の詳細化を行なうユースケースモデルチームと、販売に関するモデルの検証作業を行なうモデル検証チームです。

ユースケースモデルチームでは、以下のユースケース記述の形式を利用して、販売ユースケースに関する詳細化を行なっています。

ユースケース記述の書き方のポイントとしては、基本系列の部分では各種ボタンなどの名前については明記しないということだそうです。基本系列の各ステップで利用するボタン名を特定したい場合は、備考欄に記入するということでした。また、代替系列と例外系列との使い分けのポイントとしては、事後条件を達成するかしないかというのが基準だそうです。従って、事後条件を達成しないのは、例外系列として書くようです。

モデル検証チームは、昨日作成した概念図から Rose-RT を使って設計に入りました。ハードウェアの CPU (RCX) が 3 つなので、「金銭管理」、「受注管理」、「商品管理」の 3 つをカプセル(アクティブオブジェクトを表す)として定義し、「商品管理」に関して掘り下げていました。そして、「商品管理」の状態図を作成し、その部分のコーディングまでを行なっていました。

EEBOF チームは、前半は予定より遅れていましたが、後半は並行作業によって挽回したという感じです。

さて、両チームともモデリングライブ中には最後まで完成しないのは当然なのですが、このモデリングの作業自体は自動販売機の模型の評価機で実動するまで行なうようです。完成したら、自動販売機プロジェクトのページで公開するということでした。また、モデリングライブ中で撮影したビデオも編集して公開するということです。ビデオを見れば、私が捉えきれなかったモデリングのポイントも掴めるんではないでしょうか。

おまけ

最終結果発表の後、張 漢明 先生(南山大学)から VDM でモデリングした結果の発表がありました。VDM は形式手法の一つで、文章だけで概念を整理していく方法です。張先生は、VDM を使って機能仕様書から名詞だけを抽出し、1つの用語が 2 つの概念を表すことがないように整理しておられました。

VDM のメリットは、1つの言葉を 2 つの意味で使わないことを可能にするので、仕様の曖昧さを取り除くことができるということです。しかし、概念を定義する際に、本質だけを定義しなければならないので、慣れないとうまく適用できないと感じました。概念を定義するポイントとしては、How を書かずに、What を書くということだそうです。また、What を書く上でのポイントは、事前条件と事後条件を考えるということだそうです。ちなみに、VDM にオブジェクト指向の機能を付け加えた VDM++ というのもあるらしいです。

5.まとめ

モデリングライブの様子をわかっていただけましたでしょうか。

モデリングライブでは、モデラーは説明しながらモデリングをし、参加者はモデラーに対して口を挟んでも良いということでしたが、実際のところ、その辺りはうまく機能していなかったように感じます。モデラーの方もその場でいきなりモデリングだったので、モデリングをやりながらしゃべるというのは難しく、たいへん苦労されていました。参加者の方としては、私の個人的な意見になりますが、モデリングで利用する方法論を知らなかったり(UML 以外の図が出てきたりすると目的がわからないので理解に苦しみました)、事前に自動販売機のモデリングについて一切考えていなかったりと、モデラーの方と考える土俵が違ったので、どのようにモデリングをされているのかを見ているだけに終ったところがありました。モデラーの方が採用する方法論のアクティビティや成果物の目的などについて、もう少し詳しい説明があった方が良かったかもしれません。しかし、企画としてはたいへん面白い内容でしたので、次回、実施されるときにも参加してみたいと思います。

繰り返しになりますが、モデリングライブに参加して、方法論の概要を知らないと何をやっているのかわからないということを強く感じました。次回、モデリングライブに参加される方は、組み込みソフトウェア開発で用いられる ROOM [2] や ExecutableUML [3],eUML [5] 等の方法論のいずれかを一通り見ておくことをお薦めします。個人的には、日本語で解説されている eUML がお薦めですね。もし、書籍を読んでも今一つわからないという方は、ちょっと宣伝になりますが、弊社の「組込みオブジェクト指向分析・設計トレーニング(開発プロセス編)」トレーニングを受講してみるのも良いと思います。弊社のトレーニングを弊社のエンジニアが受講して書いた潜入レポート記事もありますので、そちらを見ていただければトレーニングの雰囲気を掴んでいただけるでしょう。

6.参考文献

    1. 『組み込みソフトウェアシンポジウム 2003 (ESS 2003) 論文集』 (社) 情報処理学会 ソフトウェア工学研究会.
    2. 『 Real-Time Object-Oriented Modeling 』 Bran Selic, Garth Gullekson,Paul T. Ward 著,John Wiley & Sonc, Inc.
    3. 『 Executable Uml : A Foundation for Model-Driven Architecture 』 Stephen Mellor, Marc J. Balcer 著,Addison-Wesley.
    4. 『ユースケース実践ガイド』 アリスター・コーバーン 著,ウルシステムズ株式会社 監訳,山岸 耕ニ,矢崎 博英,水谷 雅宏,篠原 明子 /訳,翔泳社.
    5. 『組み込みUML : eUML によるオブジェクト指向組み込みシステム開発』 渡辺 博之,渡辺 政彦,掘松 和人,渡守 武和記 著,翔泳社.

© 2003 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP