Атрибуты и генерация эталонного интерфейса.
Одним из инструментов VantageTeam Builder, поддерживающих генерацию по шаблону, являются
задаваемые пользователем атрибуты для любых элементов любых типов диаграмм. Детальный анализ
эталонного интерфейса показал, что его реализация требует задания для каждой таблицы и ее
полей некоторых дополнительных атрибутов, среди которых основными являются признак видимого
поля, признак вхождения поля в альтернативный ключ, признак вхождения поля в строковое
представление, тип вычисляемого поля для представления словарной таблицы. Перечисленные выше
атрибуты наиболее естественным образом могут быть введены на ER-диаграммах, поскольку при
принятой нами логике построения приложения, их значения единственны для всех форм, имеющих
отношение к данной таблице.
Отсутствие в CASE'е версии 3.1 инструментов генерации сложных экранных форм привело к
необходимости построения собственного генератора экранных форм, генерящего для каждой
таблицы формы для ввода/модификации информации и для формирования запросов, который также
вошел в состав GRINDERY One-Step 4GL.
С точки зрения скорости получения работающего приложения, чем крупнее шаблон, тем лучше.
Соответственно, мы ограничились одним шаблоном на весь набор функций, обеспечивающих работу
с таблицей (в отличие от VantageTeam Builder, мы генерим не одну функцию, а несколько,
основными из которых являются функция для ввода/модификации, функция для удаления
отмеченных в списке записей, функция просмотра записи, соответствующей "словарному" полю или
строке в списке, функция ввода запроса и формирования списка найденных записей и функция
формирования строкового представления). Однако, пойдя по такому пути мы не могли не столкнуться
с проблемой доработки прототипа. Вносить в него изменения вручную легче, чем в текст,
генерящийся по стандартным шаблонам, поскольку он разбит на отдельные функции и уже за счет
этого лучше структурирован. Сложность же здесь, как и при использовании стандартных шаблонов,
возникает прежде всего потому, что при внесении изменений непосредственно в текст модуля с одной
стороны ухудшается степень документированности проекта, а с другой теряется возможность
перегенерации кода программы при внесении каких-либо изменений в структуру таблиц или
переназначении дополнительных атрибутов. В настоящее время для решения этой проблемы
изменения, которые вносятся в текст программного модуля, записываются в специальные файлы (по
одному на каждый модуль) со специальными метками, указывающими куда именно внесено
изменение. Таким образом достигается и определенная документированность внесенных уникальных
изменений (хотя они и не отражаются на каких-либо диаграммах, их значительно легче найти в таком
файле, чем в полном тексте программы,) и их повторное использование при перегенерации
программы.
