特集
» 2006年03月25日 00時00分 公開

“ハッスルCATS”のETロボコン2005参戦記(前編):ゼロから始めた組み込みUMLモデリング (1/3)

新人社員が挑戦したUMLモデリングによる組み込み開発。3カ月に及ぶ奮闘の末に完成したモデルの出来映えは?

[赤穂/ラン/唐/渡辺 キャッツ,@IT MONOist]

はじめに

 キャッツ株式会社の新卒社員4人組が“ハッスルCATS”というチームを結成し、2005年のETロボコン(注1)に参戦しました。これは新人研修の一環として実施されたもので、UMLを学び、組み込みソフトウェア開発の知識を吸収するだけではなく、仕事のやり方、チームによるプロジェクトの進め方といった、さまざまな能力を身に付けることを期待されていました。今回は前編として、参戦が決定した時点から初期モデルの作成、そして最終的なモデル完成までを紹介し、2005年7月に行われた競技会・審査ワークショップ当日のドキュメントを紹介します。ET2005でのチャンピオンシップ大会については、後編で紹介します。

※注1:ETロボコン
自律型ライントレース・ロボット「LEGO Mindstorm」を使って、組み込みソフトウェア開発の「分析、ソフトウェア設計モデリング」と「走行性能(タイムトライアル)」を競うコンテスト。


新人4人組がETロボコンに参戦

 キャッツに入社した私たち4名の新人は、ほんの少し前までは学生であり、しかもプログラミングの知識はほとんどなく、学校の授業でC言語を学んだことがあるという程度でした。当然「組み込み」「UML」という言葉は初めて聞く単語。こんなメンバーでETロボコンに挑戦したのです。

 ETロボコンとは、2004年まではUMLロボコンとして開催されていましたが、2005年の「Embedded Technology展」の特別イベントとして開催されることになり、「ETロボコン」と名称が変わりました。そもそもETロボコンとはUMLで設計されたモデリングを競い、その後、LEGO Mindstorm(PathFinder)を使用してコースを走行し、タイムを競うといった競技です。

 プロジェクトメンバーは、通常のソフトウェア開発に関する新人研修を受け、その後通常業務を行うといった日常の中、ETロボコン参戦のために、通常業務(定時)後に会社に残って、UMLモデリングを行い、自分たちでコースを作成し、何度も走行体を走らせては設計を繰り返しました。参戦中は毎日深夜に及ぶ作業になり、つらい日々でした。

 また、参戦前は「LEGOのおもちゃを走らせて競争するだけなので楽勝!」と思っていて、やる気満々でしたが、いざモデリングを始めると、メンバーそれぞれが違った考えを持ち、なかなか全員の意見はまとまりません。最初に突き当たったのはチーム開発の難しさでした。そんなときは、上司や先輩に報告・連絡・相談をすることが大切だと分かりました。ここでせっかくUMLを勉強したので、「新人、先輩、上司」の関係をシーケンス図でモデリングしてみましょう(笑)。

ソフトウェア開発における「新人、先輩、上司」の関係を分析したシーケンス図 図1 ソフトウェア開発における「新人、先輩、上司」の関係を分析したシーケンス図

初めて作ったUMLモデル

 モデリングに取り組んだ当初は、分からないことばかりでした。整理してみると、

  • モデル図を何のために描くのか分からなかった
  • 開発におけるフェイズ(要求分析や分析など)の意味が分からなかった
  • どんなモデル図があるのか分からなかった
  • モデル図の見方が分からなかった

などです。そこでまず、UMLの調査から始めることにしました。参考書籍として「組み込みUML―eUMLによるオブジェクト指向組み込みシステム開発」(以下、eUML本)を読むことで、モデル図の種類や見方などを把握していきました。

 それでは、ハッスルCATSが初めて作ったUMLモデルを紹介しましょう。今回のモデリングは、「ユースケース分析」→「ドメイン図」→「状態図」→「クラス図」の順番で作成していきました。初期バージョンから完成バージョンへ至る過程で、どのように進化していったかを確認していただけます。

ユースケース分析

 UMLモデリングの第一歩として、まず要求分析を行うために、ユースケース図を描きました。eUML本を参考にしながら、ユースケース図には何を描けばいいのかを模索したのですが、ここで苦労したのは「ユースケースとは何か?」でした。資料などによれば「システムにさせたいサービス・機能を記述する」とあるものの、走行体を走らすという具体的な開発に即した形で、納得のできるユースケースを見つけ出すのは容易ではありません。

 ユースケースの意味もしっかり理解しないままに描いていたため、当初出来上がったユースケースでは、システムに何を要求しているのかが不明確でした。ユースケース図を描くに当たって、視点や粒度をどこに定めたらいいか、チーム内で議論をしても個々に意見が違い、なかなか決めることができません。走行体となるPathFinderをシステムとして見る考えもあれば、走行体の制御を行うRCXという機器をシステムとしてとらえる考え方もありました。

 そこで、先輩に相談したところ、次のような指摘を受けました。

  • ユースケースは、サービスや機能である
  • 2つのユースケース(サービス・機能)を持つものを、1つのユースケースとして表現してはいけない

 また、ユースケース記述の項目のフォーマットなどを教えてもらい、ユースケースごとの役割や前提条件などが明確になっていきました。そこで、

  • アクターが何であるか
  • そのアクターが何に対して要求をしているか

を決めました。今回、アクターとなるのは開発を行う自分たちであるため、アクターを自分たち(ハッスルCATS)としました。また今回のETロボコンに参加するに当たり、タイムトライアル部門優勝という目標を掲げていたので、「優勝してほしい」「優勝したい」という気持ちを込めて、システムに相当する走行体のPathFinderは「優勝システム」としました。こうして出来上がった初期のユースケースを図2に示します。

初期のユースケース分析 図2 初期のユースケース分析

 ユースケースが明確にならず悩んでいたところ、先輩から「ドメイン図や状態図を描いてみれば」とアドバイスを受けました。試しにドメイン図や状態図を描いたところ、初期のユースケースで不明確であった詳細部分を明確にできました。最終的にモデル審査部門に提出したユースケース分析を図3に示します。

完成したユースケース分析 図3 完成したユースケース分析

 最終モデルでは「コース選択」が追加され、初期モデルでは2つだったシナリオが3つに増えています。これはユースケース以外のモデルを描いていくうちに、初期の要求分析に漏れがあったことに気付いたからです。ちなみに、コース選択とは「INコース」「OUTコース」を走行前に選択する機能です。タイムトライアルでは異なる2つのコースを1回ずつ走行して、合計タイムで順位が決まります。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.