SESSAMEで一緒のにしさんがブログでソフトウェアの自動生成を話題にしているので、今回は自動コード生成、モデル駆動開発について考えてみたい。
ソフトウェアの自動生成といっても設計行為がいらないわけではない。実際にはUMLなどでモデルを作ってそのモデルからコードを自動に生成するという話だ。ようするにソフトウェアシステムの抽象度を一段上げようという世の中の傾向のことである。
ソフトウェアをアセンブラで書いていた時代からC言語などの高級言語で書くように時代はシフトしたので、次は言語で記述せずにモデルを記述して、モデルからC言語、C言語からアセンブラといった変換の部分をツールにやらせようという考え方だ。
その背景には、10万行を超える高級言語で書いた組込みソフトウェアは絡まり合い、収拾が付かなくなり、不具合が起こっても問題の原因を追及しきれないことが多いことにある。
手続き型の言語に慣れてしまった組込みソフトエンジニアはC++などのオブジェクト指向言語を使うことに尻込みし、また、オブジェクト指向言語を使っても従来の手続き型の言語でも試行錯誤的プログラミングをやってしまう。
そういう状況を見ていると、いっそモデルしか書けないようにして、モデルからコードへの変換のアーキテクチャの中にアーキテクトのノウハウを隠蔽してしまった方が品質が上がるんじゃないかと思うこともある。
でも、何年かまたは何十年かして、もしそういう時代がきたとしても必ずモデルからコードへの変換がどうなっているのか、今使っているモデル変換のアーキテクチャを変化させる必要がないのかを常に考る技術者が必要になる。今でもC言語とCPU、アセンブラに精通し、Cからアセンブラへ変換するコンパイラを開発しなければいけない人たちが必要なのと同じだ。
ちなみに、組込みソフトエンジニアでハードウェア寄りのソフトを書いている人たちは今でもCPUやグラフィックコントローラなどのデータブックをぼろぼろになるまで読み込む。多くのソフトエンジニアのソフトウェア記述の抽象度を上げても、誰かが抽象度の上がったモデルと下層レイヤのソフトウェアやハードウェアとの橋渡しをしなければいけない。
ソフトウェアプラットフォームがPCの場合は、モデルからコードへの変換のアーキテクチャは一般化しやすいだろうが、組込みの場合、変換アーキテクチャを一般化し、変換アーキテクチャの寿命を長持ちさせようとすると犠牲にしなければいけないことが生じる。
組込みシステムの場合、市場要求が千差万別で機能だけでなく性能要件やコストの要件などもあり、制約も多いからトレードオフが頻繁に発生する。コスト要求からくるメモリやCPUパフォーマンスの制限をクリアするためのトレードオフは手続き言語のレベルなら何とかなることが多い。でも、モデル変換のアーキテクチャの中にトレードオフのパターンが隠蔽されていると最適なすり合わせができない。
モデル変換のルール・アーキテクチャにその製品や製品群特有のすり合わせ要素を注入することは可能だが、トレードオフのポイントが頻繁に変わるような商品だった場合、モデルベースの開発はうまみがなくなってしまう。
モデル変換のルール・アーキテクチャを変えない、プラットフォームを変えないことに固執すると、ソフトウェアの開発効率は上がるが、トレードオフバランスの調整やすり合わせによるまねされにくい強みを作り上げるというアドバンテージは減る。プラットフォームが共通になり、数少ないモデル変換アーキテクチャが組込みソフト開発の世界にも普及するようになると、組込みもアプリケーションソフトだけで勝負することになる。これでは他社がまねしにくいソフトウェアのコアコンピタンスを作り上げることが難しい。
プラットフォームの共通化、フレームワークの共通化は、PC+Windows の現状を見れば分かるように、エンドユーザとアプリケーションソフトウェア開発者にはメリットが大きい。でも、そのメリットとは裏腹にPCのハードウェアメーカは辛いだろう。ユーザはPCを買うときにSONYでも東芝でもNECでもDELLでもどのメーカのパソコンを選んでも使い勝手にさほど変わりがない。変わりがないというよりは変えられないのだ。ここまでプラットフォームや共通クラスライブラリが普及してしまうとハードメーカは独自の特徴を出すことができない。
組込みシステムに対するモデル駆動開発のポイントはトレードオフやすり合わせの必要がないGUIなどのアプリケーションソフトに絞って実施することではないだろうか。組込みソフトウェア開発では開発環境の選択であっても常にトレードオフのことを考え、顧客満足を最大にするポイントを探り続ける必要がある。
P.S.
にしさんのブログのコメントに自動車エンジニアさんが、【MATLAB/Simulink/Stateflow】を使った自動コード生成の実態を書いている。MATLAB/Simlink についてはこのブログでも『MATLABのビジネスから見る知的生産性とは』に記事を書いているが、自動車エンジニアさんの記述によると自動車の世界ではMATLAB/Simlinkを使ったモデルベース開発/自動コード生成は実用段階まで進んでおり、実際の車のソフトにも自動コード生成で作られたソフトウェアが実装されているそうだ。日経エレなどの雑誌の記事では読んだことがあるが、現場の生の声でその実態を聞くとリアリティがある。
モデルベース開発によってコードを自動生成する行為が商品の価値を押し下げる可能性がなく※1、実際の商品の動きからモデルやチューニングパラメータを類推されないのなら、モデルベース開発に移行した方がいいというのは理解できる。
※1 パフォーマンスを低下させたり余計にメモリを食ったり、自動コード生成を実現させるためにCPUのランクを上げてコストアップになったりすることが顧客満足を低くする可能性のこと）
また、高級言語でプログラミングするエンジニアの割合が減って、モデル駆動開発するのが常識になったなら、高級言語ですり合わせ開発してまねされにくいソフトウェア資産を作ることより、開発の効率化や品質向上のメリットの方が大きくなる時代もくるだろう。やっぱりトレードオフのバランスポイントが大事になる。
ただ、一つ気になるのはMATLAB/Simlinkのように、モデルベース開発のツールが一社独占になってしまうことのリスクだ。万が一何かの理由でつぶれてしまったり、IBMやMicrosoftなどの巨人に飲み込まれていきなりツールや保守の価格を10倍ぐらいにされても、その条件を飲まざるを得なくなる。
ソフトウェアは複製コストがほとんどかからないので何万台も何十万台も製品を作って売るメーカーなら開発ツールが少々高くてもエンドユーザーへの負担は少ない。逆にメーカーは高価なCPUを使ったり、メモリ部品を余計に追加したりして材料費が10円でも20円でも高くなることを嫌う。原材料費のアップはエンドユーザーまで行くと数倍の負担になってしまうからだ。
一般的な会社においては開発ツールの価格の高さに加えて、開発ツールのセカンドソースも考えておかないといけないところが辛い。競争相手が次々現れたとしてもコンパイラやRTOSもバグがないかとか信頼性は高いかとか考えないといけないのと同じように、アーキテクチャ変換ツールの信頼性について心配しなければいけない。
やっぱり自動車業界のように業界内での示し合わせができないと普及するのに時間がかかると思うなあ。
2007-03-19
組込みでUMLは何のために使う？
あるソフトウェア技術者の方から、UMLについて問い合わせを受けた。その後、UMLツールやこの本を紹介したら次のような追加質問をもらった。【追加質問】
詳しいご回答をありがとうございました。
書籍は早速購入しました。
ＵＭＬツールを使う上で、オブジェクト指向から学ばなければいけないと思っているのですが、どのようにオブジェクト指向とＵＭＬを勉強していけば良いでしょうか？
【追加質問終わり】
この追加質問の内容で、「ＵＭＬツールを使う上で、オブジェクト指向から学ばなければいけないと思っている」というところにちょっと引っかかりがあった。実質的にはそうなのかもしればいが、安直に UML = オブジェクト指向 関連付けると、組込みの場合特に足を踏み外しそうな気がする。
そこで、以下のような返信を書いた。
【追加質問に対する回答（抜粋）】
UMLは表記法です。極端な言い方をすればフローチャートと同じ表記法です。ただ、フローチャートよりは書き方を修得するのに時間がかかります。
では、なぜ修得に時間のかかるUMLを覚えるのか？
UMLが国際標準の表記法となりつつあり、UMLで書いたモデルはたぶん10年近くは（UMLの表記法を認知している人の中で）通じます。
通じるというのは、UMLのダイアグラムを見ながらディスカッションすれば、ソフトウェアの静的な構造や振る舞いについて、素早く認識できるということです。ソースコードを見ながら議論するよりは、絶対効率的です。
プロジェクト内部だけで通じるブロック図でもいいかもしれませんが、プロジェクトの規模が大きくなって独特なブロック図の表記法について質問してくる人が増えたり、新しい人が入ってきたりすると毎度毎度説明しなければいけません。説明しないでもいいくらい単純な図だと、複雑なソフトウェア構造を示すことができないでしょう。
また、ソフトウェアの開発を海外を含む外部に委託するような場合も同じです。ソフトウェアの構造や振る舞いを共通の記述方法で示すことができれば、表記法の説明を省いて本題に早く入れるようになります。
でも、そんなに大きなプロジェクトではないチームだってあります。では、非常に狭い範囲だけでUMLを使うメリットはなんでしょうか？
同じ市場に対して、同じような製品を、同じメンバーで作り続けている少人数のチームがあった場合、UMLでソフトウェアの構造や振る舞いを表記する必要があるでしょうか？
答えは YES です。
理由は、自分たちのために必要だからです。同じ市場に対して、同じような製品を、同じメンバーで作り続けている少人数のチームであっても、ソフトウェアの規模は年々大きくなっているはずです。この規模が大きくなってしまったソフトウェアシステムの構造や振る舞いをUMLで表現することには意味があります。
例えば次のような目的のためです。
－UMLを使う目的－
- 全体を俯瞰して、どのような責任分担でソフトウェアが分割されているのかが分かる。（上記のようなチームであれば、このモジュール分割が技術者の責任分担にもなる）
- 分割されたサブシステム同士の関係（依存関係、呼び出し関係）が分かる。（サブシステムの独立性を高めるのに役立ちます）
- システム全体もしくは一部の状態遷移が分かるようになる。（状態遷移図・・・古典的ですがやっぱり分かりやすいです）
- そのシステムで何かをしたいときのシーケンスを表現できる。（役割分担と手順が分かると、具体的に何をすればいいか見えてきます）
いままでの小規模なソフトウェアプロジェクトでは1～4までの内容は、そのシステムの構造や振る舞いを最初に設計した技術者（アーキテクト）の頭の中だけに暗黙知として存在していました。考え方によっては、その技術者（アーキテクト）をチーム内にずっとキープしておければ、次々に新しい製品を開発できるとも言えます。
しかし、ソフトウェアシステムの規模は一人のアーキテクトでは把握しきれないくらいの大きさにまで拡大しており、また、ソフトウェアシステムに対する要求が複雑化すると、システム全体の構造を熟知しているアーキテクトしか分からない仕事が増えてしまい、そのアーキテクトの仕事が集中し、ついには破綻させてしまったり、その組織から逃げ出されてしまったりします。
悪循環から脱しきれないソフトウェアプロジェクトは、代わりとなる優秀なアーキテクトを探そうとし、人材不足の世の中、結局代わりのアーキテクトは見つからない場合もあるでしょう。その場合は、残されたメンバーで全体構造がよく分からないままソフトウェアを付け足し続け、最初のアーキテクチャを崩ししてしまい、悪循環のスピードを速めてしまいます。
また、運良く変わりのアーキテクトを見つけることができた場合、見つけられてしまったアーキテクトは前任のアーキテクトと同じように過負荷にさらされることになります。このとき、ソフトウェアシステムの構造や振る舞いを示すドキュメントが存在しないと、ソースコードからそれらを分析することになり、立ち上がりには相当な時間を要するでしょう。
もしも、ソフトウェアシステムの構造や振る舞いをUMLで表現できれば、次のような可能性がでてきます。
－UMLでソフトウェアシステムの構造や振る舞いを可視化できると・・・－
- サブシステム単位で力のいれ具合に強弱を付けることができる。（まずは、このサブシステム、このモジュールの信頼性を高めようというアプローチが可能）
- 再利用資産を抽出することが可能となり、開発の効率を高めることができる。
- 不具合が起こったときに、原因となるサブシステムやモジュールを特定しやすくなる。（責務で分割されているため、発生した現象から原因を作った犯人を見つけやすい）
- 新たな要求が降りかかってきたとき、どのサブシステムやモジュールに影響を及ぼすか事前に分析できる。
- 新たな要求が降りかかってきたときに最小限の変更ですむような、システム構造を変更できる。（アーキテクチャの見直し）
新しい技術を習得するためには、時間や費用が必要です。こられのリソースを確保するためには、組織に対しては修得した技術で開発効率やソフトウェア品質を高め、顧客満足を高めることに貢献できることを説明し、プロジェクトメンバーにはその技術の習得が余裕を生み、クリエイティブな仕事ができるきっかけになることを示さなければいけません。
UMLをなぜ使うのかをしっかりと考えて、先に進んでください。
：
【追加質問に対する回答の抜粋終わり】
P.S.
上記の回答文章は質問に返信するつもりで書いたが、結局はブログネタとして使い本当の回答文章はもっともっと簡略化した。だって、こんな長い文章をメールで返信したらどう見てもへんでしょ。
登録:
投稿 (Atom)