一つの画は千の言葉を語るだろうか？

作者 Niclas Nilsson, 翻訳者 編集部 投稿日 2007年11月13日 午前4時54分

コミュニティ

Architecture

トピック

モデリング,

Artifacts & Tools,

プログラミング,

Domain Specific Languages

タグ

Diagramming,

Visualization,

Microsoft,

IDEs

一つの画は千の言葉を語るだろうか？

最近の記事”私たちはなぜダイアグラムを描かずコードを記述するのだろうか？(source)”の中で、Dean Wampler氏(source)はソフトウェア開発においてはその反対が事実であることが多いことを議論している。

グラフィック的な表記法の提唱者達は、私たちがテキストのコードを記述する必要がなくダイアグラムのみを描くという点に到達することを切望していました。過去数年間に渡っていくつかビジュアルプログラミング環境が存在していたが早くも去っていってしまったのです。

もし一つの画が千の言葉をも語っているのなら、なぜそれは今までに起こらなかったのでしょうか？

いくつかはグラフィカルなプログラミング環境があり、使われている。しかしながら例外もある。Labview(source)はたぶんその中で一番知られたものだが、実際それは従来のデベロッパではなく主にテスター（とLegoが好きな子供達）(source)によって使用されているのである。

それはなぜだろうか？ソフトウェア開発においては手のかかる細かいことがたくさんあるのである。これがリーダーを圧倒させない、複雑なものを表示するビジュアル言語を作るのを困難にさせるのである。もし私たちが画としてプログラミング構成を表示するときは、それが何を意味しているか理解可能にするために、 それらの画を抽象概念にマップする必要があるのである。大変な部分は典型的な罠(source)にはまって終わらないようにすることなのである。また私たちは他のデベロッパと会話をするので、どのみち私たちには言葉が必要となるのである。

Dean氏は下記のように記載している。

さて、私たちはそれを十分に表現力のあるグラフィック表記法ですることはできなかったのでしょうか？もちろんそうですが、そうするとテキストの詳細をタイプするのがそれを描くよりも速くなってしまうという現実的な問題に直面します。

私は2,3年前、JavaデベロッパのためのUMLベースのツールを開発している良く知られた会社で働いている時にこれに気付いたのです。そのツールのUIはもっと効率的になったはずですが、テキストをタイプする速さにはかなうはずがなかったのです。

しかしながら、これは全てどれだけ強力なアブストラクションをコードの中に作ったかという事にかかっているのである。もしそれがおろそかであれば、一つの画で表せるところを千をもの言葉で表示しなければいけないかもしれない。そしてあなたとあなたの同僚はそのコードを読む度に毎回解読する必要に迫られるのである。

現在のDomain-Specific言語のムーブメントは明らかにこの点に集中している。

またいくつかの言語はむしろ詳細であるということも事実であります。これがDomain-Specific言語(DSL)が非常に重要となる方法の一つです。上手くデザインされたDSLは、それらの高レベルなコンセプトを簡潔に表現するのを可能にします。 　

Dean氏はこのケースにおいてDSLを言及しているが、Metacaseのような会社はビジュアルモデル言語をデザインするためのツール(サイト・英語)を作り、マイクロソフトはSoftware Factoryビジョンに伴うグラフィックDSLを作るためのツールを開発した(source)際に、似たような道をたどった。

Arnon Rotem-Gal-Oz氏(source)はこのようなグラフィックDSLの制限に関して解説した。

小さなコードベースのDSLとは違い、ソフトウェアファクトリーのモデルベースアプローチ、MDA等は目標を高く持ちすぎていて、それゆえにより少ない値を提供し、もしくは世代間のギャップに苦しむのです（生成されたコードは一般化されすぎて、もしくは実際のソリューションの必要性からかけ離れているのです）。

Arnon氏はまた画が実際に千の言葉に値しているかどうかということに関して、あからさまなコメントを述べた。

これはもしあなたがモデルをスケッチとして扱うことができるのなら、あなたが上げたいだけ抽象性のレベルを上げ、混乱をより少なくしてアイディアを運ぶことができるというのは事実です。しかしながら、コードの生成を許容させるためモデルをとても詳細にする必要がある時は、コード内でそれをしたほうがより便利な状況になり、生成された、または事前に構築されたDSLかフレームワークに頼れるのです。

あいにく、画は複雑なコードベースを把握するのに実用的な方法に成り得る。InfoQは最近Software VisualizationにおいてErik Deornenburg氏とのインタビューを行い、それにおいてErik氏は例えばシステム、もしくはコードベースの異なるアスペクトを可視化する方法を説明している。可視化を使用して見つけるのが困難な例外を迅速に捉えるのが可能になるが、しかしそれはソフトウェアをグラフィック的に作るのとは異なっているのである。

Dean氏は、グラフィック表示が収まる場所が無いことを暗に意味しているのではない事を説明することによって、結論を下している。

それでもまだ一般的なケースにおいては、上手く設計されたAPIとDSLを使用して簡潔な言語で書かれたコードはダイアグラム駆動のアプローチを切り札として使用するのです。

一方、International Software(サイト・英語)は、コードかもしくは画が単に同じモデルから反映された異なる射影であると述べるだろう。

原文はこちらです：http://www.infoq.com/news/2007/11/pictures-or-words

• 次へ >