интересно
Предыдущая | Содержание | Следующая

Развитие проблемно-ориентированного пользовательского интерфейса с моделями

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

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

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

Конечные пользователи стремятся применить новые технологии, возникающие вследствие развития аппаратного обеспечения вычислительных машин. Использование новых технологий - это следствие эволюции программных средств.

Расширяется круг разработчиков. В настоящее время (в отличие от 1970-х - 1980-х гг., когда большинство разработчиков ПО являлись профессиональными программистами) все больший круг программных продуктов разрабатывается людьми, имеющими опыт в той сфере, к которой относится разрабатываемый продукт, но не имеющими фундаментальных знаний в области программирования.

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

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

Рассмотрим систему имитационного моделирования - пакет Pilgrim. Направленный на создание имитационных моделей, Pilgrim имеет круг потенциальных пользователей в лице системных аналитиков, экономистов-математиков, а также других специалистов, знакомых с программированием, но не являющихся программистами-профессионалами.

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

С появлением Windows 95/98/NT для Pilgrim были разработаны многочисленные модули, обеспечивающие графическое отображение результатов в окне Windows. Имеются возможности настройки окна отображения результатов в удобной для пользователя форме. Однако разработка самой модели оставалась задачей программиста. Новой задачей модификации Pilgrim стала разработка графического конструктора, позволяющего задавать модели в виде графа, отвлечься от кодирования и использовать иерархию процессов.

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

Следует также отметить, что первые версии пакета Pilgrim отличались способностью переноса на различные платформы, единственным требованием к которым было наличие компилятора C++. Библиотеку пакета можно было одинаково эффективно использовать и в среде Unix, и в среде MS DOS. Созданная для Unix модель могла успешно компилироваться и в MS DOS, а ориентированный на конкретную платформу интерфейс только интерпретировал результаты выполнения.

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

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

отображение процесса имитации на графе модели в реальном времени;

расширение графических средств отображения процесса имитации;

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

предоставление интерфейса ввода начальных параметров;

хранение моделей в виде проектов, содержащих в качестве компонентов граф модели, описание интерфейса и дополнительных функций.

Многие сервисные функции уже есть в различных версиях системы. Рассмотрим их подробнее.

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

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

Помимо имитации на графе модели Pilgrim должен также предоставлять средства отображения выходных данных в виде графиков, таблиц, диаграмм, а также анимации. На данный момент в библиотеке Pilgrim такие средства заложены, однако набор их ограничен, и в случае желания заказчика получить дополнительные способы отображения результатов разработчику необходимо писать C++ код, использующий стандартные средства Visual C++.

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

Реализация дополнительных функций неизбежно приведет к изменению в составе и структуре конструктора (рис. 5.25). Основой для новых функций является механизм обмена данными между выполняющейся моделью и конструктором.

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

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

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

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

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

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

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

Все эти факторы в конечном итоге должны отразиться на увеличении привлекательности моделирующей системы Pilgrim как для разработчика моделей, так и для конечного пользователя.

Выводы

1. CASE-конструктор имитационных моделей позволяет проводить разработку многоуровневой Pilgrim-модели практически без применения языка Pilgrim.

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

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