2015-01-09-01-SVGのUMLツールを - 6
>> Site top >> weblog >> 月別アーカイブ >> 2015年01月のlog >> 2015-01-09-01-SVGのUMLツールを - 6
最終更新日付：2015/01/09 01:00:00
SVGのUMLツールを - 6
2015 年 01 月 09 日
さて、昨日は以下のようなイメージを提示した。
(define-structure uml-class (class-name x y)
(rectangle :x x :y y
:align :center :valign :center
:w (+ 20 (width-of :name))
:h (+ 20 (height-of :name)))
(text class-name :key :name :x x :y y
:align :center :valign :center))
これを、もう少し冷静にみつめてるのが今日の作業‥‥‥だと思う。
昨日書かなかった（気がする）前提として、rectangle や text などの描画指定は「記述されている順番に描画される」というのがある。上の例では、先に rectangle が描画され、その次に（つまりその上に）text が描画されるということだ。
しかし、よくよく考えてみると、単純に「順番に描画される」だけでは駄目だ。たとえば、上記のクラス図形の定義を育てていった場合のことを考えてみよう。データメンバやメンバ関数（UMLの正しい用語を既に忘れてしまっているな‥‥‥）の指定があった場合は必要な描画をするが、省略された場合は描画したくないだろう。つまり、条件分岐が必要になる。これまで、rectangle だの text だのは最終的にはクロージャにコンパイルされ、define-structure が作成するインスタンス（これもまたクロージャだろうが）が内部で管理するシーケンスに単純に格納されるイメージを持っていた。しかし、条件分岐が必要となれば、そんな単純なわけにはいかない。
考えれば考えるほど、少なくとも複合図形の定義は「最低限のルールと追加制約しかない Common Lisp プログラミング」で行きたいと思うようになってきた。単純に基本図形を並べるだけならばそこまで必要ないとしても、パラメータによってある程度以上に賢く振る舞う複合図形ではやはりプログラミングが必要なのだ。
とはいえ、これはまだいい。複合図形の定義は常にやる作業というわけでもないから。必要な図形の定義が完了してしまえば、（下手すれば）二度とやらないかもしれない。しかし、「図面の作成」は別だ。それは CL-SVG の主要な使い方であり、それをやらないというのは CL-SVG を使わないということになる。図面の作成がガチのプログラミングであってはならないだろう。たとえユーザが自分だけだったとしても。
そんなわけで、「複合図形の定義」と「図面の作成」は必ずしも同じコトではなくなるかもしれない。少なくとも、「複合図形の定義」はもうしっかりプログラミングだ。もちろん、それをマクロでどこまでサポートできるかが問題なのだが。次回以降、さらにユースケースの理解を進めてみよう。
コメント
このページのタグ
Page tag : CL-SVG
Copyright(C) 2005-2020 project-enigma.
Generated by CL-PREFAB.
