Создание информационной системы любого уровня сложности проходит несколько основных этапов: постановка задачи, подготовка технического задания, разработка информационной структуры и базы данных, создание прототипа приложения, корректировка технического задания, создание готового приложения, подготовка и разработка новых версий. Для решения задач, возникающих на каждом из этих этапов, созданы специализированные инструменты, помогающие разработчикам минимизировать временные затраты и уменьшить количество ошибок. Однако при переходе от одного этапа к другому возникает проблема преемственности и интеграции специализированных средств, используемых при разработке приложения: требования аналитиков необходимо передать разработчикам базы данных, готовую базу передать для разработки пользовательского интерфейса, по получении замечаний заказчика к прототипу приложения сделать корректировку технического задания. При этом необходимо избежать тотальной переделки всей системы. В разработанных ранее системах автоматизации эти проблемы решались лишь частично.

Подходы к проектированию приложений в предлагаемых системах автоматизации проектирования и разработки приложений можно неформально разделить на два типа, условно называемых: "до и от" и "от и до".

Первый подход пропагандируется разработчиками билдеров и "легких" CASE средств и предполагает, что инструментарий CASE используется только для проектирования - ("до") создания базы данных, а разработка приложения осуществляется ("от" готовой базы) с помощью билдеров, которые обладают собственными средствами реверсинжениринга модели данных, библиотеками классов и многими другими инструментами. Основным недостатком этого подхода является разорванность технологического процесса, в результате чего модель данных, используемая билдером, значительно беднее модели, разработанной аналитиком с использованием инструментов CASE либо вручную. Дополнительную информацию аналитик вынужден передавать неформальными способами ("голосом"). Кроме того, в процессе разработки приложения зачастую оказывалось, что стандартные библиотеки классов, используемые билдером, недостаточны для разработки полнофункционального приложения и каждому программисту приходилось по-своему наращивать функциональность, что приводило к "лоскутному" интерфейсу. В результате, несмотря на наличие удобного инструментария у аналитиков и программистов, его использование не приводит ни к улучшению качества системы, ни к ускорению разработки.

Второй подход, реализованный в так называемых "тяжелых" CASE средствах, например, в Tau UML Suite, предполагает, что CASE поддерживает разработку "от" анализа "до" конструирования логической модели данных и логической модели приложения, на основе которых создается база данных и осуществляется автоматическая генерация программного кода. Tau UML Suite предоставляет пользователю прекрасный инструментарий для проектирования приложения:

диаграммы содержания экранных форм (FCD - Form Contence Diagram), которые позволяют описать структуру и (в значительной степени) функциональность сложных экранных форм (предназначенных для работы с несколькими таблицами);

диаграммы структурных схем (SCD - Structure Charts Diagram), которые позволяют описать алгоритмы программных модулей и методы работы с экранными формами (в рамках структурного подхода работа с экранными формами элегантно осуществляется с помощью так называемых "предопределенных модулей");

диаграммы последовательности экранных форм (FSD - Form Sequence Diagram), которые задают общую структуру приложения. а также связывают формы и алгоритмы (методы).

Главный недостаток этого подхода состоит в том, что идеология проектирования не учитывает реальные потребности проектировщика, который должен разработать информационную систему со стандартным интерфейсом, поскольку заказчику нужна система с легкими для освоения рабочими местами. Проектировщику нужны средства построения логической модели стандартного интерфейса, а не полной модели всех элементов интерфейса. Детальное проектирование каждой экранной формы (средствами FCD или в билдере) при создании стандартного интерфейса является не только нудной, но и зачастую вредной работой, а "уникальные" рабочие места, как правило, немногочисленны, их гораздо быстрее и проще создавать на основе типового рабочего места, а не "с чистого листа". Кроме того, затраты на приобретение и освоение "тяжелого" CASE окупаются только при создании достаточно крупных систем или при "поточном" производстве, многие возможности, предоставляемые продуктами этого класса, не столь уж необходимы для создания небольшой системы разработчиками, хорошо знающими предметную область или для воспроизведения существующей системы на другой платформе.

Компания DataX/FLORIN поставила перед собой задачу разработки технологии проектирования, которая бы обеспечивала автоматический перенос данных при переходе от одного этапа разработки информационной системы к другому, позволяла бы создавать современные информационный системы со стандартизированным пользовательским интерфейсом в сжатые сроки и поддерживала бы полный жизненный цикл приложения. Такая технология была разработана и получила название "технологии сквозного проектирования". Она позволяет связать воедино все этапы построения информационной системы, начиная от постановки задания и заканчивая созданием бумажной документации. Использование этой технологии позволяет отказаться от ручной работы по кодированию базы и программных интерфейсов, дает возможность вносить изменения на любом уровне реализации и в результате дает заказчику не только готовую систему, но и средства для ее дальнейшего развития и сопровождения. Для реализации технологии сквозного проектирования было создано семейство программных продуктов GRINDERY, с помощью которых преодолен технологический разрыв между CASE-средствами и средствами программирования интерфейсов. Использование программных продуктов семейства GRINDERY позволяет производить логическое проектирование приложения одновременно с разработкой логической структуры базы данных в среде Telelogic Tau UML Suite, затем осуществлять автоматическую генерацию программного кода на любом языке программирования, поддерживаемом семейством GRINDERYTM. Задание и изменение управляющих параметров кодогенерации (атрибутов), а также управление правами доступа и версиями проекта осуществляется с использованием механизмов соответствующего CASE-инструмента. Для кодогенератора GRINDERYTM разработаны шаблоны, предназначенные для создания типового интерфейса приложения. В приложении с типовым интерфейсом для каждой предметной таблицы базы данных создается рабочее место, позволяющее выполнять основные операции с данными (INSERT, UPDATE, DELETE, QBE), содержащимися в этой таблице. Рабочее место, созданное для предметной таблицы, позволяет работать не только с главной, но и с другими ("вспомогательными" для данного рабочего места) таблицами базы данных. Конкретный вид экранных форм и функциональные возможности приложения зависят от установленных значений атрибутов. С их помощью можно задать, например, способ представления конкретного поля, заголовки форм и полей, необходимость представления записей из таблиц-потомков и таблиц-партнеров, режим доступа к таблицам-словарям. Набор атрибутов для каждой таблицы и ее полей задается один раз и используется для всех форм, в которых доступны данная таблица или ее поля. Ввод и редактирование атрибутов производятся либо из графического интерфейса GRINDERY GrabberTM, либо через графический интерфейс Telelogic Tau UML Suite TM. Разработчик в любой момент может вручную внести изменения в сгенерированный кодогенератором программный код приложения.
Таким образом, разработанная фирмой DataX/FLORIN технология сквозного программирования и созданные для ее реализации программные продукты позволяют решить задачу автоматизации проектирования приложения от этапа анализа до полной генерации кода приложения со стандартизированным пользовательским интерфейсом.