В общем, необходимость применения структурной эволюционной модели быстрого прототипирования в данном случае выражена достаточно явно. Признаками тому служат следующие факторы:
- полные требования не известны заранее и не постоянны;
- существует потребность в разработке достаточно сложных пользовательских интерфейсов;
- осуществляются временные демонстрации;
- требуется уменьшить неточности в определении требований; т.е. уменьшается риск создания системы, которая не имеет никакой ценности для заказчика;
- разработчики не уверены в том, какую оптимальную архитектуру или алгоритмы следует применять;
- системные интерфейсы усложнены;
Создание модели быстрого прототипирования было бы невозможным без работ выдающегося Фреда Брукса (“The Mythical Man-Month”, "No Silver Bullet, the Essence and Accidents of Programming"). Его идеи, изложенные в данных книгах, сегодня столь же актуальны, как и в 1975 году. Технологии радикально изменили мир, но многие недостатки менеджмента программных проектов по-прежнему те же. Десятки лет тому назад Брукс сказал:
"В большинстве проектов первая построенная система едва ли пригодна к употреблению. Она может быть слишком медленной, слишком объемной, неудобной в использовании или обладать всеми тремя перечисленными недостатками. Нет другого выбора, кроме как начать с самого начала, приложив все усилия, и построить модернизированную версию, в которой решались бы все три проблемы...
В случае, когда в проекте используется новая системная концепция или новая технология, разработчик вынужден построить систему, которой впоследствии не воспользуется, поскольку даже при наилучшем планировании невозможно предвидеть достижение нужного результата”.
Эти слова замечательно передают сущность рассматриваемой модели, её основную идею - построение экспериментальных моделей реального приложения, иными словами - прототипирование.
Согласно Джону Коннэллу и Линде Шафер, эволюционным ускоренным прототипом является "легко поддающаяся модификации и расширению рабочая модель предполагаемой системы, не обязательно представляющая собой все свойства системы, благодаря которой пользователи данного приложения получают физическое представление о ключевых частях системы до ее непосредственной реализации; это -- легко создаваемая, без труда поддающаяся модификации, максимально расширяемая, частично заданная рабочая модель основных аспектов предполагаемой системы".
Таким образом, прототип -- это эквивалент экспериментальной модели или "макета" в мире аппаратного обеспечения.
Выполнение эволюционных программ при разработке редактора, как и должно, происходило в рамках контекста плана, направленного на достижение предельно высокой производительности. При этом для заказчика был очевиден этот факт, что во многом облегчило работу. Заказчик принимал активное участие в течение всего процесса разработки, что в целом является одним из главных условий успешности реализации метода прототипирования.
Схему метода можно изобразить следующим образом:
Рисунок 2.1 - Метод быстрого прототипирования
Начало жизненного цикла разработки помещено в центре эллипса. В соответствии со схемой, базовый анализ (на основе предварительных требований) необходимых свойств и функций редактора был произведён на начальной стадии разработки (и жизненного цикла в целом). Заказчик и программист совместно определили требования и спецификации для важнейших частей системы. В результате был получен документ, описывающий в общих чертах примерные графики и результативные данные.
Далее было осуществлено создание базы данных, пользовательского интерфейса, разработаны соответствующие функции. Другими словами, была создана рабочая модель - первичный прототип.
Модель была продемонстрирована заказчику с целью получения предложений по ее усовершенствованию. Заказчик оценил первичный прототип и совместно с программистом определил проблемы, над устранением которых необходимо было работать в рамках разработки последующего прототипа системы. В основном, изменения коснулись пользовательского графического интерфейса редактора, функциональность ядра системы полностью удовлетворила пользователя на базе первичного прототипа (за исключением небольших ошибок, обнаруженных и исправленных впоследствии).
Все вышеописанные действия представляют собой одну итерацию цикла быстрого прототипирования. Этот цикл продолжается до тех пор, пока пользователь не будет удовлетворен тем, каким образом система отображает поставленные к ней требования. Команда разработчиков проекта продолжает выполнять этот процесс до тех пор, пока пользователь не согласится, что быстрый прототип в точности отображает системные требования.
При разработке текущего проекта было создано два быстрых прототипа. После модификации второго была получена окончательная версия системы, официально одобренная пользователем. Именно на этом этапе настройки ускоренный прототип редактора стал полностью действующей системой, которая заменила собой частичную систему, полученную в итерационном цикле прототипирования.
Использование данной модели не раз оправдало себя в течение разработки. В целом, оно позволило решить следующие проблемы:
- исходя из реакции заказчиков на демонстрации разрабатываемого продукта, разработчиком были получены сведения об аспектах необходимого поведения системы, благодаря чему количество неточностей в требованиях свелось минимуму;
- минимизирование вероятности искажения информации и возникновения недоразумений при определении системных требований, что несомненно привело к созданию более качественного конечного продукта;
- при разработке образовывались постоянные, видимые признаки прогресса в выполнении проекта, благодаря чему заказчики чувствовали себя уверенно;
- благодаря меньшему объему доработок были уменьшены затраты на разработку;
- благодаря тому, что проблемы, как правило, выявлялись до привлечения дополнительных ресурсов, сократились общие затраты;
- было обеспечено управление рисками;
2.2 Структурная модель приложения
Приложение состоит из двух основных сущностей:
а) очередь эмиттеров;
б) оконно-интерфейсная часть;
Сущности, в свою очередь состоят из множества функционально-логических блоков.
Очередь эмиттеров представляет собой программируемый контейнер, предназначенный для хранения параметров набора эмиттеров и их частиц, а также отображения в режиме реального времени. Очередь также определяет режимы смешивания и порядок рисования наборов частиц друг относительно друга. Это позволяет создавать различные эффекты наложения.
Отдельно взятый набор частиц представлен внутренними структурами данных эмиттера. Здесь хранятся все параметры эмиттера и каждой его частицы:
а) для эмиттера:
1) координаты в двумерной декартовой системе;
2) скорость;
3) размеры;
4) значения разброса частиц;
5) стартовая задержка и длительность генерации;
б) для частицы:
1) текстура;
2) время жизни;
3) скорость по осям;
4) гравитация по осям;
5) значения начальных и конечных растяжений;
6) значения начального и конечного цветов по каналам;
Для реализации интерфейсной части были использованы графические объекты вышеописанного межплатформенного движка wxWidgets.
Корневым элементом интерфейсной части является основной фрейм. Основной фрейм служит для расположения фрейма ввода данных, фрейма управления очередью эмиттеров, фрейма вывода. Также основному фрейму принадлежат системное меню, панели инструментов и статуса.
Фрейм ввода данных предназначен для ввода вышеозначенных параметров текущего эмиттера. В редакторе всегда имеется текущий эмиттер, если их число больше нуля. Если же оно равно нулю, инструменты фрейма ввода блокируются. При изменении текущего эмиттера происходит соответствующее обновление данных инструментов фрейма ввода.
Фрейм управления очередью эмиттеров представляет собой панель со схематическим отображением отдельных эмиттеров в виде пиктограмм. К функциям фрейма относятся добавление и удаление эмиттеров, копирование эмиттера со всеми его параметрами, изменение текущего эмиттера, а также порядка прорисовки эмиттеров. Для копирования и удаления эмиттеров при активном фрейме управления очередью можно использовать горячие клавиши (Ctrl+V, Ctrl+X, соответственно).
Фрейм вывода объединяет в себе всю функциональность вывода графических данных приложения. Для максимально быстрого вывода используется низкоуровневая работа с аппаратным обеспечением видеосистемы, осуществляемая посредством драйвера OpenGL. Доступ к платформенно-независимому конвейеру OpenGL осуществляется, в свою очередь, через интерфейс wxWidgets. Именно на уровне фрейма вывода осуществлено связывание оконной системы и функциональности рисования очереди эмиттеров, не зависящей от конкретного окна и работающая с буферами OpenGL. Средства wxWidgets используют для этого те или иные системные библиотеки, в зависимости от целевой платформы. Для Windows это WGL, для Mac OS X - AGL, а также стандартные Carbon (для С++) и Cocoa (Objective С).
Дополнительно фрейм вывода позволяет при помощи мыши перемещать эмиттеры, изменять их размеры. Также поддерживается перенос рабочей (текущей отображаемой) области рисования. Для этого необходимо, во-первых, активировать режим переноса, использовав клавишу Space. Затем, используя мышь, осуществить перенос области в нужном направлении и на необходимое расстояние. Для выхода из режима переноса рабочей области необходимо повторно нажать клавишу Space. Необходимо отметить, что в режиме переноса рабочей области возможности переноса эмиттеров и изменения их размеров отключаются.
Системное меню имеет следующую структуру:
- меню “Файл”, отвечающее за общий сброс, сохранение и загрузку, выход из приложения;
- меню “Очередь”, отвечающее за установку режима отображения эмиттеров (Playback, Loop playback, Static), добавление и удаление текущего эмиттера, копирование эмиттера и набора его параметров, сброс всех эмиттеров;
- меню “Информация”, позволяющее получить информацию о способах использования редактора, а также о разработчике;
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
