半形式化した仕様における「形式的な部分」は，一般に図式言語によって与えられる(p.144)
冒頭にあるように，次の役割分担を考えている．図式とそこに書かれるテキストを考えたときに，図式は形式性を受け持つ．図式中に書かれるテキストは非形式的である．従って，全体としては「半」形式的である．
図式を徹底することはもちろん出来るだろう．ただ，それは図式がテキスト化するだけで，可読性や編集容易性というメリットを失う．
ここでは，あくまで図とテキストに分かれると考える．この2分割によって，次節からはテキスト部分の形式化の話題に進む．
もちろん，Lamsweerdeさんがいうように，図式の形式化すらも矩形などの単純な図形と矢印だけなのだから表層的であるというのも，正しいだろう．
少しだけ違った視点から，「表層的には」使える図式表現といえども，更に難しさがあるということを考えてみたい．人の書く図式を見る機会は余りないのだが（最近は特に少なくなった気がする），先日，大学生にKAOSを説明する機会に恵まれた．採点しながら思ったのは，人間というのは，なんと発想力に優れた生き物かということである（イヤミではなく，素直に良いと思った）．
席が近い人以外は同じ図式にはならないのだが，そこからは，その人がどう考えたか，何を気にしたかが伝わってくる．これが一番の図式の魅力だろうと思う．同じコトを自然言語で実現しようとすると，よほど練った文章にする必要がある．
逆に言えば，図式の細部にこだわりながら正確に書かれたとしても，読者にがんばったね！以外に何も伝わらない図式は，意味をなしていないということである．図式は，数学に相当する正確さを持ち得ないと思っている（どんな図式でもノードとして使えるのはたかだか10個程度しかないのだから）．しかし，表層的とも思わない．多くの人（利害関係者の多くは，ソフトウェアが専門ではないだろう）が，重要な点を一瞥できるには，どうすべきかということに対して，魅力的な道具だと思う．
いつまでもKAOSのモデル図にたどり着けないが（原書ではあと100頁ほど先である），採点していて思った（ゴールモデルを）作成するときの注意点を残しておく．もちろん，学生のみなさんにはあらかじめ注意はしていないし，そもそも私の頭の中にはなかった．慣れてしまうと気がつかない点を教えてもらったと，みなさんには感謝している．
- （業務フロー的）フローは，意識しないこと
- 最も重要なゴールは何かを意識すること
- システムをイメージしないこと
- 関連と洗練を混同しないこと
(nil)