ASTERIAはグラフィカルにビジネスアプリケーションを作成するためのビジュアルプログラミング開発・実行環境である。このビジュアルプログラミングというのはよくあるリソースエディタ+コードスケルトンの作成というレベルではなく、以下の図のように実際にアイコンを平面に並べることでプログラミングを行う。
このアイコンは一つのフィーチャを持ったオブジェクトで、オブジェクトごとにあるプロパティを適切に設定することでオブジェクトの詳細な動作を規定する。
また図上でアイコン間を結んでいる矢印線はデータの流れを示している。
このようにASTERIAは適切なアイコンを選択し、それらを設定し、線で結んでいくことで業務アプリケーションの設計と製作を一緒にやってしまう。
また標準で用意されたアイコンを使用する限りにおいてはまったくコーディングは不要だ。
このASTERIAがもつビジュアルプログラミングの最大の特徴は、アイコンというプログラム言語より遙かに抽象度の高いレベルでロジックを規定していくことによる、非プログラマに対する解りやすさだ。
ただし、まつもとひろゆき氏がBlogで指摘しているようにヴィジュアルプログプログラミングというのは死屍累々であることもたしかだ。しかしながら、20年以上も前からビジュアルプログラミングを行い成功している業界がある。PLC(Programable Logic Controller)/DCS(Distributed Control System)の業界である。
以下はいささか手前みそであるけれども、僕が勤めている会社のSymphonyと言うDCSのプログラムの一部だ。
大抵のDCSも当社のシステムと同様に、と言うよりもASTERIAと同じようにアイコンを線で結んでいくやり方でプログラミングを行う。また、このような制御装置に対するプログラミング方法はIECによりIEC(6)1131-4と言う形で標準化されており、PLC/DCSの世界では成功しているプログラミング方法である。
したがって、ビジュアルプログラミングがいつも失敗かというと、決してそうではない。
ではなぜ、ビジュアルプログラミングは広まってもいないし、失敗続きなのだろうか。
ビジュアルプログラミング環境の最大の特徴と利点はフィーチャをアイコンとして表現し、それらアイコン間を線などで結びつけていく事による解りやすさであるが、このわかりやすさを維持するためには二つのことを守っていく必要があると思う。
一つはアイコンの抽象度レベルが同じであることで、アイコン間の抽象度、あるいは粒度が一定でないと2次元上に表しているアイコン間に実は深度の違いが出来てしまい、プログラミングする側で立体的な思考が必要になってしまうため、これはわかりにくさに繋がって行く。
二つめはアイコンの数を増やしすぎないことで、アイコンの数が増えすぎてしまうと似たようなフェイスを持つアイコンだらけになってしまい、見た目上の区別がつかなくなり、アイコンその物の意義が無くなってしまう。
大抵だめだったビジュアルプログラミング言語は、汎用的であることを目指して、この二つの利点を維持できずに失敗してしまっていると思う。
ASTERIAに関しては、一つめの問題点に関しては、通常のフローと、データマッピング内でのフローという形で実際には二つに深度を分けることで、深度の違うアイコンが一つの図上に混在してしまうことを防いでいる。二つめに関しては、現状アイコンで表現されたフィーチャは限定されており、アイコンの絵も適切であると思うので、問題がないと思う。ここではフィーチャが限定されているとは機能が少ないわけではなく、上手く抽象化された単位でアイコン化されている事を示している。
以上で考察してきたように、ビジュアルプログラミング環境が成功するこつは、それが対象とする業務ドメインや、アプリケーションを限定して特化し、汎用を目指さないことだ。それこそ、そういった柔軟性とそれに付随したわかりにくさは、テキストで書くプログラミング言語に任せておけばいい。それよりもビジュアルプログラミングに求められているの解りやすさ・使いやすさのはずである。
従って、ASTERIAも汎用を目指さず、現在の業務アプリケーション向けビジュアルプログラミング環境という位置付けを維持していけば成功できると思う。下手にユーザー(つーかプログラマ)の意見を聞いて汎用に走っては失敗してしまうだろう。
もっとも、ASTERIA実践ガイドの「刊行に寄せて」の一文
ASTERIAには、かつてアップルがユーザーインターフェースの世界にもたらしたことと同じ事を、プログラミング言語の世界においても実現したい、と言う思いが込められています。グラフィカルで直感的なプログラミング環境を普及させ、プログラムを書くという営みをもっと身近にしたいという願いです。
を見る限りは、そんな心配も必要無さそうではある。
その他雑感:
ASTERIAから見ると、MSのDSLやOMGのMDAによるGPはいかにも中途半端な気さえする。DSLが本当に特定ドメインの記述言語であり、それで完結できるならC#やJavaのコードなんて吐き出す必要がないはず。
IEC(6)1131-4ではFCとSFCと呼ばれるビジュアルなプログラミングだけでなく、STという従来のテキスト型のプログラミング言語も規格化されていて、これらはASTERIAとJavaの関係と同じだと捉えてもらえばいいと思う。
僕がASTERIAに感じたシンパシーや解りやすさはDCSでのプログラミング経験による所が大きいと思う。高級言語による経験しか持たない者にとっては逆に敷居が高いのかもしれない。
プログラマの分業化は進んでいくなぁ。OSやVMといったファンダメンタルな部分を作る人、アプリケーションフレームワークを作る人、ASTERIAのオブジェクトのようなプログラム部品を作る人、ASTERIAやDSLツールを使って、ユーザーにとって意味のあるアプリケーションを作る人。どれも大事だけど、一人の人間がこの全ての領域にわたって意味のある仕事を行うのはもはや不可能だと思ってしまう。
コメント
素晴らしい評価をありがとうございました!
Symphonyのように閉じたドメインの中でビルディングブロック型の要件を扱うものと、ASTERIAのような演繹的とはいえない業務系データを扱うものとの違いについて、もやもやとしていたものが晴れてきた気がします。
本当にまだまだ第一歩だな、という実感です。楽観も悲観もせず、慎重かつ大胆に取り組んでいきたいと思います。
「ASTERIA実践ガイド」TOP10入り!
Yahoo!JAPANの書籍ランキング(書泉グランデ調べ)で「ASTERIA実践…
笑門来福@インフォテリアの平野です。トラックバックがエラーで重複してしまいました。申し訳ありません。このコメントを含め、余計なものを削除願います。
「ASTERIA実践ガイド」TOP10入り!
Yahoo!JAPANの書籍ランキング(書泉グランデ調べ)のコンピュータ部門で「…
「ASTERIA実践ガイド」TOP10入り!
Yahoo!JAPANの書籍ランキング(書泉グランデ調べ)のコンピュータ部門で「…