ObjectSquare [2002 年 5 月号]

[UML Forum 2002 レポート]


 UML Forum 2002レポート


株式会社オージス総研
坂坂屋.com


2002/04/25 10:02

■ はじめに ―― UML Forum / Tokyo 2002 (UML Forum 2002)

UML Forum / Tokyo 2002

3/26(火)〜3/27(水)の2日間、東京ファッションタウンTFTホールにて「UML Forum / Tokyo 2002」が開催されました。日本で開催されるUML Forumは、今年で2回目のまだ初々しい、Object Management Group(OMG)が主催するUMLの祭典です。

くみこまーである坂坂屋.comの2名は、翌日のXPセッションを見たいという誘惑にもメゲず、初日(3/26)の組込みセッションにのみ参加してきました。

今回組み込みはモデル駆動型アーキテクチャ(MDA)

今年のUML Forumの目玉として、少なくとも組込み/リアルタイムシステム開発については、モデル駆動型アーキテクチャ(Model-Driven Architecture 以下、MDA)を前面に押し出した講演が目白押しでした。今後のUMLのプロパガンダ的な要素があるのか、はたまた今回のメインスポンサーの力関係も働いているのか、といった疑問にはとりあえず目をつぶっておきましょう(笑)。

MDAの定義

OMGでは「OMG技術基礎 - MDA」で、MDAを以下のように定義しています。

MDA(モデル駆動型アーキテクチャ)とは、モデリング主導のシステム開発、およびライフサイクル管理を実現するための参照アーキテクチャです。「駆動」という言葉には、「まずモデルありき。モデルが定義されることで特定言語や製品へのマッピングは自動的に決定し、さらにシステム管理、インテグレーションもモデルを中心として行うことを可能とする」という意味が込められています。

かなりの曲解かもしれませんが、MDAはざっとこんな感じの理解です。

MDAをサポートするCASEツールを利用して、モデルをCASEツールのシミュレータで動作させ(モデルレベルで)検証するとともに、この検証したモデルからソースコードに変換するものです。ここで生成されるコードはスケルトンコードではありませんよ。コンパイルして実行することが可能なソースコードなのです。このコード生成のことを変換(Translation)といいます。対して生成されたスケルトンにコードを埋め込むものは作り込み(Elaboration)というそうです。

※ 作り込み(Elaboration)は、RUPでいうところの推敲フェーズ(Elaboration Phase)のことではありませんのでご注意くださいませ。

しかも、MDAで開発するモデルは PIM (Platform-Independent Models) といって、プラットフォームに依存しない分析モデルなのだそうです。実装コードを書いてみないと検証出来なかったことを考えると、実装コードより抽象度の高いUMLモデルで動作検証ができるし、これは類似したドメイン、あるいはシリーズ製品の開発において、これら分析モデルを再利用できるといったメリットがあります。ただし分析モデルとはいっても詳細度でいえばかなり設計よりになってしまうものと想像します。

従来の抽象度の高い分析モデルとプラットフォームに依存し非機能的要求(アーキテクチャ要求)を満たすために最適化された設計モデルの2つのモデルをメンテナンスすることによる作業負荷が軽減されます。

むしろ、より抽象度の高い分析モデルから実装コードが生成されることにより、より問題の本質に注力したモデルの作成が可能になり、短いサイクルでバージョンアップされる対象ハードウェア(プラットフォーム)の変更に影響を受けずに再利用できるというメリットがあります。

実際のところ、プラットフォームに非依存とはいいますが、抽象度がそれほど高いかどうかについてはかなり疑問に感じます。残念ながら、我々坂坂屋.comにはMDAをサポートするCASEツールの利用経験がありませんので、確かなことはわかりません。

ところで坂坂屋.comとは?

今回、オブジェクトの広場に初見参の坂坂屋.comですが、いったい誰なんでしょう?

それは、オージス総研 オブジェクトテクノロジー・ソリューション部のくみこまー、赤坂英彦と小坂優。二人合わせて坂坂屋.comです。単なるペンネームですので、Googleとかで検索するのは止めてくださいね(笑)。今後、何かの間違いで坂坂屋.comとして広場あるいは広大なインターネットの片隅でお会いする機会があるかもしれませんが、その時はお手柔らかによろしくお願いいたします。多分、もうないと思いますが(坂坂屋.com両名の談)。

■ 参加の目的と聴講したセッション

参加の目的

今回はスケジュールの都合で諦めかけていたUML Forumなのですが、直前になって参加できることになりました。今回は特に目的など考えていませんでしたが、レポート記事を書くにあたり、とりあえず何か目的を埋めておくことにします。

我々の生業である(!?)組込み関係では、以下のようなことが考えられます。

また、せっかくプロジェクトから1日解放されるので、実はこんな目的もあったりしました。

聴講したセッション

我々が聴講したセッションは以下のものです。

[K1]基調講演「リアルタイムシステムのためのUML」  Speaker:ブルース・パウエル・ダグラス氏

Speakerのダグラス氏は"Real-Time UML"(邦訳『リアルタイムUML(第2版)』)の著者です。

講演の内容は、リアルタイムシステム開発において、UMLを現在の複雑なシステムの開発に効果的に適用するには、というテーマでした。MDAを採用して、モデルから実行コードに変換するという開発スタイルを用います。

特徴的なものは以下のものでした。

※ すみません、これらの詳細についてはよく理解できませんでした m(_._)m

推奨する開発サイクル - セミスパイラル

セミスパイラルについては、『サバイバルプロジェクトガイド』(SteveMcConnell著)にある段階的分納と似ているものだと感じました。

セミスパイラルを推奨するのは、モデルでの検証を行いたいため、先行してアーキテクチャの骨格部分をまず確立しておきたいという発想から来ているものだと思います。このため、最初に分析、設計を十分に取っておくのだでしょう。イテレーションとしては区切られていませんが、実質的にはRUPの方向づけ、推敲各フェーズを分析、設計に置き換えたものと言えます。要するに、最初のスパイラルで検証できるレベルのモデル(=アーキテクチャの骨格)をまず作りたいのでしょう。以降はこれをベースモデルとしてスパイラルに開発できるって訳ですね。

なお、このライフサイクルを実践するためには、ある程度、システム要求の大枠が決まっている(要求リスクが少ないといった)必要があります。最初に作ったモデルが使い物にならないとセミスパイラルは一から出直しを余儀なくされるからです。
まあ、RUPのような繰り返し開発を採用したとしても、推敲フェーズが終了するまでの何回かのイテレーションの間には、要求、アーキテクチャともに安定したものにならないと、結局は一から出直しせざるを得ませんよね。そのリスクの度合いに僅かな差があるかもしれないといったところでしょう。RUPの方がアーキテクチャ構築に、数回のイテレーションをかけますので、その間(例えば、イテレーションごと)に見直しをかける機会があるのでリスクが少し低いかもしれません。

どちらにしても、要求の根本が変化してしまうならアーキテクチャは使い捨てに成らざるを得ないとは思います。

質疑応答

申し訳ありませんが、ここでは挙がった質問のみを列挙するに留めておきます。

 

[M1]特別講演「Executable UMLとレゴを使った組込みシステム開発の学習法」 Speaker:レオン・スター氏

Speakerのレオンスター氏はシュレイアーメラー法の『オブジェクト・モデリング』の著者です。現在はシュレイアーメラー法に関する権威といっても過言ではないでしょう。

講演の内容はレゴで作ったエレベータを題材に、Exectable UMLを適用して、組込みシステム開発を学ぼうというものです。(レゴで作ったエレベータでの開発についての詳細は書籍『Executable UML』を参照してくださいとのこと)

 今回のUMLロボットコンテストも、弊社で開催している組込みトレーニングも、レゴのライントレーサーですし、近々出版予定の日本人による組込み/リアルタイム開発向けのガイドライン『e-UML』もレゴのキャンディーソーターを題材にしたものになるそうです。最近手ごろな(入手しやすい)例で手軽に楽しく作ってみるという学習法が流行のようですね。

□ 関心の分離を行うことで、各ドメインを並行に分析、設計することが可能

ドメイン分析はシュレイアーメラー法に基づくもので、RUPなど我々が行っているレイヤー・サブシステム分割に相当します。ここで云うドメインはシステム全体ではなく、サブシステム(あるいはレイヤ程度)の単位になっていますのでご注意ください。

□ まずコラボレーションでクラスの責務を検証し(Design Collaboration First!!)、状態図を作成する

□ 状態遷移をアクション言語でモデル化(=記述)する

アクション言語はスクリプト言語のようなものであり一種の実装だと思います。

質疑応答

[Q1] MDA、実行可能モデルにより、開発者が実装コードを書かなくなるが、不具合発生時のデバッグにおいて問題の切り分け{CASEツールの問題なのか|モデル、アルゴリズムの問題なのか}ができるのか?また、CASEツールの信頼性はどのように保証してくれるのか?

⇒ ドメイン開発チーム(アプリケーション開発)と実行環境チーム(Model Translator周りの開発、保守、ドメインチームの開発支援)の2チーム体制を敷くこと(前者はシステムごとのチーム。後者は1チームで全てのドメインチームをサポートする)が重要[成功の秘訣?]。

[Q2] Design Collaboration First!!(状態図を作成する前に、コラボレーションを作成すること)について、コラボレーション図作成のポイントを示さないと、きちんと責務分担ができず、その後の(状態を持つクラスの)状態図の作成が意味のないものになってしまうのではないか?

⇒ 省略(当然クラスの責務がきちんと出来てなければ状態を記述しても上手く行かないはず)

[Q3] レースコンディション等はプラットフォーム非依存(つまり、PIMモデルに反映する!!)ということだが、本当にハードリアルタイムを意識しているのか?
# (意図は)レースコンディションはプラットフォームに依存するのではないか?

⇒ 省略(質疑噛み合わず)

[C1]「OOADによる組込リアルタイム系ソフトウェアの開発」 Speaker:堀松和人氏(ソニー)


有料セッション。聴講者はかなり少なく40名弱程度。講師はe-UML創設メンバーの一人(OGIS渡辺、Sony堀松両氏が実質的な技術的リーダーといっても過言ではない)。個人的に、期待に胸を膨らませて臨みました。

内容は、Elaboration(作り込み)vs. Translation(変換)の比較検討したプロジェクトの結果報告でした。
同一システムを以下の3パターンで作成し、比較、検証を行ったものです。
  1. 設計Rose98+(堀松氏による)ハンドコーディング
  2. 設計BridgePoint+Cトランスレータによるコード自動生成
  3. 設計BridgePoint+C++トランスレータによるコード自動生成


結果は、頑張って作ったという1)が最良、2)もかなり健闘[1)に肉薄]、3)は全然ダメ(使えそうにない)となりました。
最終的に、Cトランスレータに限っては、実用レベルにあるとの見解です。

私の感想は、Cトランスレータはかなり優秀だと思いました。後はデバックの問題さえクリアできれば、問題は案外少ないかも知れません。Cトランスレータのパフォーマンスだけを考えれば十分に実用レベルなのではないでしょうか。

質疑応答

[Q1]動的生成のインスタンス数はどれだけあるのか?

⇒ 動的生成は行っているが、正確な数は把握していない、とのこと。

[Q2]評価結果について、実装コードの理解性、メンテナンス性については?

 ⇒ やはり(堀松氏)本人が書いたコードが一番分かる。
   Translationの実装コードについては、専属チームが必要なのでは・・。

[Q3]Rose作り込み設計は状態遷移図から関数テーブルで実装とあるが、オブジェクト指向的にStateパターンなど使った場合には、少し冗長になるため、速度性能、コードサイズ共にかなり数値が悪くなるのではないか?
  # (意図は)出来る堀松氏が頑張ったから、こんなにいい数値なのではないでしょうか?

⇒ 設定した性能目標を達成することと、比較対象(Translationの実装コード)に負けないように、堀松氏が頑張って書いたコードであるため、通常のOOADで作成したElaborationコードより良い数値になっていることは確か。一般的なOOADについては、サンプルがないため、はっきりは分からない。

[Q4]講師(堀松氏)の本音はどっち?(Translation vs. Elaboration)

⇒ (もういい歳だからといったノリで) Translation の方が好き、との回答。
   # 上手くかわされてしまったという感じでしょうか。

講演の後、タバコ吸っていると偶然にも堀松氏がいらしたので、ご迷惑かとは思いながらも捕まえて雑談させていただきました。やはり「方向性として、開発対象をソースコードではなくモデルに出来るのは理想的(より抽象度を上げたレベルで議論できるため)」とおっしゃっていました。「言語もアセンブラからCへ一気にシフトしたように、C/C++ソースコードからモデルへシフトしていくはず」なんだとも。

 ただ、現状でもアセンブラで開発する部分が残っているように、当然、開発者が実装する部分がなくなる訳ではないという認識もあるようです。「現在はその過渡期」というのが堀松氏の見解でした。

以前、Interface記事の執筆時に参照した堀松氏のモデルはとても綺麗だったが、彼はもちろん実装も出来るとのこと(弊社W辺さん談)。きっと本音は、自分で実装するElaboration型のほうが好きなはず(だと私は睨んでいたのですが・・・)。

■ [C3] 組込みソフトウェアの部品化と再利用 Speaker 山田 大介氏(リコー)

山田氏の勤める(株)リコーでは、デジタル複写機のソフトウェアを部品化・再利用することにより、生産性と品質を向上させる活動を実施しておられます。ソフトウェアの部品化と再利用を実現するためにオブジェクト指向開発を取り入れておられるそうで、その実践的な取り組み事例をお話していただきました。

現在、山田氏は社内の技術者育成、チーム間の情報共有など、社内の啓蒙活動に取り組んでおられるそうです。このセッションでは、人材育成や失敗談のお話もあり、とても興味深く聞かせていただきました。

私が一番興味を持ったのは、「プロジェクトが成功するチームは?」というお話です。

成長するチーム

さて、いきなりですが、以下のチームでプロジェクトがうまくいくチームはどのチームでしょうか。

成功するチームは?

成功するチームは?

*(株)リコーでは、技術者のスキルに応じたカテゴリを設けているそうです。その内容を以下の表にまとめておきます。

メンバのカテゴリ

リボン

実践スキル

業務遂行レベル

ブルーリボン

OO思考+論理思考

人に教えることが出来る

グリーンリボン

「抽象化」が分かる

再利用モデルができる

イエローリボン

「責務分担」が分かる

ひとりでモデリングができる

無印

UMLやC++,Cが使える

それなりにできる

それでは、各チームを分析してみましょう。

Aチーム
このチームは、無印メンバー(つまり初心者)だけで構成されたチームです。このチームは、ブルーリボンであるメンターに頼りきりになります。チームのメンバーには、メンターのアドバイス(知識、スキルの伝搬)を理解するだけの経験と知識が期待できません。そのため、メンターによるアドバイスだけではチームとして伸び悩むことになります。

また、リーダーとなるメンバーがいないのもマイナスポイントですね。
Bチーム
このチームにはイエローリボンメンバーが一人いますが、あまりスキルの高いチームには見えません。このようなチームでは、メンターがイエローリボンメンバーを育成してからプロジェクトを開始するのがポイントです。グリーンリボンレベルまでスキルを上げるのですね。そうすることで、メンターからのアドバイスをある程度理解するメンバーができることになります。このチームでは、メンターのアドバイスも比較的スムーズにチームメンバーに浸透します。

このように、メンターのプロキシ的存在のメンバーがチーム内に生まれることで、このようなチームは意外とうまくいくそうです。
Cチーム
このチームは全体的にレベルの高い、バランスの良いチームに見えます。経験者が揃っているので、他のチームからうらやましがられそうですね。しかし、このチームで心配なのはブルーリボンメンバ同士の衝突です。個人的には高いスキルを持っているのですが、お互いのポリシーが衝突してまとまるものもまとまらない状況になる可能性があります。ということでチームの成長という観点で見ると、ちょっと疑問といったところでしょうか。 
Dチーム
このチームには、メンターに加え、チーム内にブルーリボンメンバがいます。また、その他のメンバーもそれなりの経験を積んでいるようです。このチームは、様々な経験レベルのメンバによって形成されているため、知識の伝搬もスムーズにいきます。また、外部からベテランの目が入るため、より機能することが期待できます。 
Eチーム
このチームはBチームとチーム構成は同じですね。ただし、メンターはDチームと掛け持ちです。Bチームと同じようにイエローリボンメンバを育成すると、良いチームになりそうですが、ブルーリボンメンバがうまくDチームと掛け持ち出来ないとたちまち破綻するでしょう。

山田氏の経験では、成長するチームはBチームとDチームだそうです。

 

成長するチームのプロジェクトは成功へとつながります。ということはつまり、

プロジェクトの成功にはチームを成長させる「仕組み」が重要!

なのです。

 

一見頼りないチームに見えるBチームですが、意外と機能するのはイエローメンバーにチームをまとめるリーダーとしての意識が育つからでしょうね。もちろん、プロジェクト開始前にメンターから"みっちり"教育を受けることが前提となっているのですが。

また、他のメンバーも若いメンバーで構成されたチームであることを自覚しているため、人任せではなく若きリーダーを助けるという意識が生まれそうですね。

その反面、Cチームの無印メンバーはどうでしょうか。ブルーリボンメンバーの相性によりそうですね。ブルーリボンメンバー同士の衝突が起きようものなら、「勝手にして!」という感じになりかねません。そうすると一番神経をすり減らすのは(経験の)若いメンバになりそうですね。

プロジェクトの成功に向けて

スポーツの世界では、優秀な選手が揃っているチームが必ずしも成功するとは限りません。チームを成長させることの出来たチームが成功するのです。それは、現在、首位を独走中の阪神タイガース(1)を見れば説明は要らないでしょう。

ところで、山田氏はモデリングについて「直観やひらめきは、良いモデルになる可能性が高い」とおっしゃっていました。この"直観やひらめき"は蓄積された知識や経験から生まれるものです。しかし、知識や経験を積み重ねれば"直観やひらめき"が生まれてくるかというと、必ずしもそうではありません。潜在的にもっている「直観やひらめき」を意識レベルに持ってくるには訓練が必要で、しかしそれは自己学習だけで習得できるかというと、難しいでしょうね。それについては、「職人のように、以心伝心で伝わるものではないか?」とのことです。

プロジェクトを成功させるには、チームを成長させることが大事。そして、個人の成長もチームの成長が大きく影響してくる。ということですね。これは、私も最近強く感じていることです。

"ダメ虎"と"猛虎"の違いは大きいですよね。企業における組織的な人材育成への取り組みというのは、あまり聞く機会がありませんでしたので、とても参考になりました。

    (1) 2002年4月21日現在。今後の行方は当然ながら未定。

■ [S3]UMLを活用した人材派遣基幹システム構築事例」 Speaker:竹内政博氏(パソナテック)+平沢章氏(ウルシステムズ)

ウルシステムズ平沢氏によるシステム開発側の立場での事例紹介でした。
前半はユーザーである人材派遣会社の竹内氏(プロマネ)からシステムの概要が説明され、後半は平沢氏によりシステムのビジネスモデリングの経過や成果物のオーバービュー(静的構造を示す概念モデルの一部のみ)からUMLaut(ウルシステムズ作成の開発プロセス)、全体スケジュール、主要メトリクス、事例からの成功条件について説明がありました。

パソナテック/基幹システムの特徴


人材派遣会社の基幹システムを構築する上で弊害となる複雑さ

通常のBPRパッケージではシステム化は不可能で、従来は人手(職人技)で切り盛りをしなければどうにもならなかった、とのことです。

システムのメタファー(ビジネスの特徴)

顧客(派遣先)の要望に応え、適切な人材を選定する

ビジネスの特徴として「お見合い支援」と同様だと聞いて、アナパタのように複数ドメインで通用するメタファの切り出し方にはとてもセンスを感じました。きっと、僕には出来ないだろうなぁ。

パソナテックの要求を実にキレイにモデルにまとめてある。これなら、メタファーの似たドメインで再利用が効くだろう。個人的には、複雑怪奇な給与計算のところや、人材選定(マッチング)のアルゴリズムなどの詳細の例が見たかったが、それは無理というものか(笑)。

個人的には一番良かったです。なにより、ドメインが違うとはいえ、概念モデルの質の高さには惚れ惚れしてしまいました。現在のプロジェクトで作成した概念モデルはかなりベタベタな感じなので、改めて少し嫌悪感を持ちました。折を見て見直してみたいと思います。ドメイン理解のためと割り切ったものだとはいえ、できれば後で使えるものにしていきたいです。

質疑応答

[Q]概念モデルの例について、ビジネスモデリングの際に、boundary、control、entityに基づいたクラス分割を行ったか?
# 質問者は「オブジェクト指向分析」を行ったかと聞いていた。

⇒ 基本的にはそのカテゴリに拘らなかった(一部、そのような分析を行ったところもあるが)。

■ まとめと感想

今回は久しぶりのお出掛け(ではなくセミナー参加)だったので、とても楽しみにしていました。

UMLロボコンのビーチくらぶの集合時間に間に合わず、遅れて簡単に挨拶を済ませ、そこで逢ったお客様を一番前の席に送り込むとすぐ後ろ(2列目)にはすでに別のお客様が。とりあえず、午前中の基調講演2セッションは最前列で聴講しました。なんと2コマめには、眠気に負けてしまい、隣のお客様に起して頂くという失態も演じてしまいました(^^;;

セッションでは今年はやたらMDA(今後リリースされるUML1.5以降のプロパガンダ)ばかりでちょっとウンザリ。ただし、将来的には(主にドメインを対象とする)開発者が実装コードを気にせず、抽象度の高いモデルによって動作の検証も行える方が理想的だと思う。いずれはそういう時代になって行くのだろうと思います。
生成されるコードのメモリ効率、実行効率がまだまだ実用的でない面や(ただしC言語生成に限ってはかなり良さそうですか)、コードを書かないためデバックが難しくなる問題などもあり、現状ではまだまだコードは自分で実装するしかないようです。もちろん、すでにMDAをサポートするケースツールは存在するので、今すぐ変換を試してみることはできます。
現状の備えとしては、実装コードをきちんと書くのはもちろんですが、より抽象度の高いレベルで動作をイメージし(机上で)検証する能力を身に付けておくことだと思います。特に抽象度の高い分析モデルの作成能力を向上させておきたいところですね。
また、MDAやExecutableUMLは基本的に状態モデルからの実装コード生成であるため、システムを状態を用いて表現する必要がありそうです。現状で、あまり状態を使わずにシステムを開発しているプロジェクトなどでは、状態図、状態遷移表といった形でシステムを記述していくことも検討していく必要があります。

セッション終了後、お客様を含むプロジェクトメンバーでコーヒーを啜りながら、講演について思ったことや、自分達の問題点などについて雑談してみました。いろいろと、自分達の問題点などが出てきましたが、直ぐには解決できるかどうか・・・。

あいにくの雨にも関わらず、UMLロボコンの会場は大勢の観衆で賑わっていました。
残念ながら弊社のビーチくらぶは完走できませんでした。完走は逃しましたが、速さで引けを取っていたわけではなかったと思います。とても残念でした。モデル部門では2位でしたので、面目は保ったというところでしょうか(ただし、同順位が3チームありました)。
来年は是非、現在のプロジェクトチーム(お客様とオージスのコラボレーション)で参加したいと思います。

当初(!?)の目的に関しては、

といった感じです。とりあえず自分としては楽しかったから良しとして、レポート記事を終わりにしたいと思います(笑)。


■ 関連ページへのリンク

UMLForum2002/Tokyoのページ

Object Management Group(オブジェクトマネージメントグループ・ジャパン)のページからUML Forum / Tokyo 2002のページにアクセスできます。

また、ZDNetエンタープライズでも「UML Forum/Tokyo 2002レポート」として紹介されました。

MDA関係のページ

こちらも同様に、「OMG技術」のページから「MDA (Model-Driven Architecture)」のページにアクセスできます。

また、MDAをサポートするCASEツールも「MDA関連製品」のページから見ることができます(4/20現在28製品)。

Real-TimeUML関係のページ

ダグラス氏

著書Real-Time UML, Second Edition: Developing Efficient Objects for Embedded Systems

邦訳『リアルタイムUML(第2版)』オージス総研訳、翔泳社

ダグラス氏の i-Logix社ホームページはここです。CASEツールは「Rhapsody」。同氏のセッションの模様についてはZDNetエンタープライズでも「UML Forum/Tokyo 2002 Keynote:プラットフォーム非依存のモデル開発がリアルタイムシステム成功のカギ」として紹介されました。

レオンスター氏

著書『How to Build Shlaer-Mellor Object Models

邦訳は『オブジェクト・モデリング』Sharlare-Mellor研究会訳、プレンティスホール

Executeble UML: How to Build Class Models

レオンスター氏の Project Technology社ホームページはここです。CASEツールは「Bridge Point」。同氏のセッションの模様についてはZDNetエンタープライズでも「レゴ・ブロックで学ぶExecutable UMLの有効性」として紹介されました。

 

その他、組込み関係のページ

eUML

『eUML』は、堀松氏も参画している、日本発の組み込み向けの開発プロセスのガイドラインです。以前、組み込みネットで紹介されました。書籍の方は近日翔泳社より発売されるそうです。

現在読めるのは、eUMLのエッセンスを濃縮した『組み込みシステムのモデリングテクニック』です。これは、昨年JavaWorld誌に連載された記事ですが、書籍同様、レゴで作ったキャンディーソーターを使ってモデリングのエッセンスを紹介してくれます。


記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。
  

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