4. Заключение

Предлагаемый подход основан на использовании модели данных в качестве исходной информации для моделирования интерфейса. Однако, в отличие ог аналогичных подходов [33,69,85] интерфейс рассматривается не просто как непосредственное следствие модели данных, но как проекция этой модели на точку зрения пользователя системы, которая может варьироваться в зависимости от выполняемых им задач. Новизна предлагаемого решения заключается еще и в определении элементов интерфейса, подлежащих моделированию (типов и элементов экранных форм), и построению на их основе метамодели интерфейса. Новым является также преимущественное использование мастеров для разработки модели интерфейса, несмотря на возможность просмотра и редактирования /той модели в виде диаграмм. Опыт показывает, что непосредственное создание диаграмм для моделирования интерфейса зачастую оказывается недостаточно наглядным и провоцирует разработчиков отказываться от моделирования в пользу создания экранных форм в визуальном конструкторе среды разработки. Наличие мастеров, позволяющих сразу после моделирования получить готовый код формы, позволяет решить эту проблему.

В табл.4.3 приведена статистика использования генераторов при создании ИС «СТУДЕНТ», предназначенной для автоматизации управления учебным процессом ВУЗа. Видно, что генераторы в той или иной мере использовались при создании более чем 96% экранных форм, при этом более 60% экранных форм не требовали «ручной» доработки после генерации.

Тип формы	Полностью сгенерировано	С «ручными» изменениями	Сопровождается «вручную»’	Всего
Список	69	16	6	91
Карточка	37	21	16	74
Отношение	17	1	4	22
Другое	0	0	6	6
Всего	123	38	32	193

Таблица 4 J Статистика использования генераторов форм

Глава 5. Поддержка итеративной разработки

Поддержка итеративного процесса разработки, на наш взгляд, является одной из самых фундаментальных проблем использования модельно-ориентированного подхода в промышленном программировании. Именно отсутствие такой поддержки в большинстве CASE-пакстов или ее недостаточный уровень является главным аргументом сторонников гибких методологий в их критике подхода «Чертеж» [56]. Действительно, долгое время большинство работ в рамках этого подхода ориентировались, в первую очередь, на поддержку водопадного процесса разработки, считавшегося «классическим». Однако, в последнее время произошла существенная переоценка ценностей в области процессов разработки ПО - а именно, отказ от водопадного процесса разработки в пользу итеративных подходов - RIJP, MSF. ХР и т.д. В связи с этим поддержка итеративного процесса оказывается в фокусе внимания исследователей [27,39,55,63,79,93].

Обобщая, можно говорить о классе проблем, во «пикающих при переходе между различными фазами жизненного цикла программных продуктов при итеративной разработке. Эти проблемы заключаются в том, что если на очередной итерации были внесены изменения на фазе N-1, то на фазе N необходимо совместить последствия этих изменений с артефактами фазы N, созданными в рамках предыдущей итерации.

В случае водопадною процесса разработки модель каждой следующей фазы строится на основе модели предыдущей. В том случае, если процесс разработки носит итсратинный характер, на всех итерациях, кроме первой, при переходе к следующей фазе возникает задача построения ее модели на основе как модели предыдущей фазы, гак и модели предыдущей итерации данной фазы. В том случае, когда переход между фазами осуществляется разработчиком «вручную», задача интеграции моделей целиком ложится на его плечи. Если же переход осуществляется с использованием автоматических или автоматизированных средств (например, генераторов кода), то именно они и должны поддерживать эту интеграцию.

Мы будем называть модели анализа и проектирования высокоуровневыми, отличая их от моделей фазы реализации (реализационных), к которым относятся, в первую очередь, исходные тексты программ.

Для создания высокоуровневых моделей широко применяются языки визуального моделирования [13], позволяющие оформлять эти модели в виде диаграмм. Следует отметить, однако, что не все диаграммные модели являются высокоуровневыми в нашем смысле - они могут носить и реализационный характер, т.е. служить для визуализации исходного кода разрабатываемой системы. При этом они являются ссма1гтнчсски полносгью эквивалентными представляемому коду. Например, язык диаграмм описания схемы реляционной базы данных IDEFlx[28] позволяет специфицировать все особенности схемы данных, описываемые средствами языка SQL.

Высокоуровневые модели, в отличие от реализационных, используются для рассмотрения тех или иных свойств системы, абстрагируясь от деталей их реализации. Одни и те же виды диаграмм иногда можно рассматривать как высокоуровневые и как реализационные, в зависимости от степени детальности представленной на них информации. Например, SDL-диаграмма 11,97], в символах которой указан код на языке программирования, является реализационной, а та же диаграмма без кода - высокоуровневой.

При использовании REAL-IT можно выделить два наиболее значимых аспекта в проблеме поддержки итеративной разработки: учет «ручных» изменений кода, сгенерированного по моделям фазы проектирования (переход с фазы проектирования на фазу реализации), и сохранение информации в базе данных при се обновлении (переход с фазы реализации на фазу эксплуатации). Выбор именно этих аспектов обусловлен следующими факторами:

• основным аргефактом фазы реализации является исходный код разрабатываемой системы, который, частично или полностью, может Сыть сгенерирован по модели проектирования;

• при создании информационных систем именно содержание базы данных является основным артефактом фазы эксплуатации.

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

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