生成の過程で必要なデータ構造とは何か
構造情報と疑似コード
GUI の提供
デザインパターンと生成されるクラス(群)との間には 次にあげるような関係が存在する．
このような関係を図で表すと， 以下のようになる．
このような多対多の関係の存在は， デザインパターンとクラス(群)との間に 中間媒介者が必要であることを意味する． この中間媒介者として， Instantiated Pattern Structure (具体化されたデザインパターンの構造) を導入した． この具体化されたデザインパターンの構造を 以下では単に IPS と呼称する． IPS はデザインパターンを具体化したもの であると同時に， パターン内でのある役割を果たすクラス内での1部分 を表す．
クラス名，抽象・具象，いくつかのクラスを代表しているか
関係の種類，向き
共に複製されなければならない要素の列挙
関数名，抽象・具象，返り値，引数， いくつかのメソッドを代表しているか
関数の振舞いを表す． 現在は特に定まった書き方は無く，省略されることも多い
構造記述は SGML によって行った． 疑似コードについては生成される コードに組み込むようにしたいため， 簡易言語を設計し， 設計支援時に解析して用いることにした． SGML を用いなかったのは， 記述が非常に繁雑になることと， 設計支援時以外には解析の必要は無く， 表示にはそのまま使用すれば良いと考えたためである．
詳細については，
で詳しく述べる．
言語の選択, アプリケーションの作成
↓
デザインパターンの選択
α．デザインパターン (
PIML+疑似コード)
↓
↓
ユーザとの対話
言語非依存な情報の入力
(name etc.)
↓
γ．＜ IPS (具体化されたパターン構造) ＞
↓
特化
言語依存な情報の入力
(specifier etc.)
↓
↓
ソースコード生成
δ．クラス (CIML)
ユーザが必ず指定しなくてはならない識別子には以下の種類がある． 上から順に決定していくことになる． パターン内の全役割に対して最低でも１つのクラスが 割り当てられる必要がある． が，実際の支援では暫定的な名前をつけて それを変更するという形態を取っている．
例は主に PIML についてでも示した Iterator パターンです．
Aggregate に対して List, Iterator に対して Iterator など
reference と aggregate 関係についてのみ
inheritance, creation にラベルはない
Aggregate の CreateIterator に対して createIterator など
ConcreteIterator の ConcreteIterator(ConcreteAggregate aggr) の aggr （あまり重要ではない）
Composite パターンでの forall "g" in "children" の "g" など （あまり重要ではない）