Содержание к диссертации
Введение
Глава 1. Инструментальные средства и подходы к разработке WIMP-интерфейсов (Обзор литературы) 9
1.1 Основные понятия WIMP-интерфейсов 9
1.2 Построители интерфейса ,у 11
1.3 Моделеориентированиые средства 15
1.4 Онтологический подход к автоматизации разработки пользовательских интерфейсов .. 26
1.5 Выводы из обзора 28
Глава 2. Онтология WIMP-иитерфейсов 32
2.1 Модель метаонтологии 32
2.2 Модель онтологии 35
2.3 Выводы 69
Глава 3. Методы формирования модели WIMP-интерфейса и генерации исходного кода 70
3.1 Метод формирования модели WIMP-интерфейса 70
3.1.1 Метод формирования модели системы понятий диалога 71
3.1.2 Метод формирования модели WIMP-представления 73
3.1.3 Метод формирования модели связи интерфейса с прикладной программой 76
3.1.4 Метод формирования модели сценария диалога 78
3.2 Метод генерации исходного кода WIMP-интерфейса по его модели 85
3.2.1 Абстрактный язык для описания структуры исходного кода WIMP-интерфейсов 88
3.2.2 Процесс генерации кода 93
3.3 Выводы 105
Глава 4. Методы реализации инструментального средства для проектирования, автоматической генерации и сопровождения WIMP-интерфейсов 106
4.1 Требования к инструментальному средству для проектирования, автоматической генерации и сопровождения WIMP-интерфейсов 106
4.2 Архитектура Onto Dev 107
4.3 Методы реализации инструментария 109
4.4 Методы реализации генератора кода WIMP-интерфейсов 117
4.5 Технические характеристики 119
4.6 Сравнительный анализ инструментальных средств для разработки WIMP-интерфейсов 119
4.7 Выводы 121
Глава 5. Технология проектирования и сопровождения WIMP-интерфейсов с помощью инструментального средства Onto Dev 123
5.1 Технология проектирования и сопровождения WIMP-интерфейсов 123
5.2 Технология сопровождения инструментария разработчика 130
5.3 Разработанные с помощью Onto Dev интерфейсы
5.3.1 Система интеллектуальной поддержки обследования больных для врача уролога... 133
5.3.2 Система анализа газетных объявлений 134
5.3.3 Сравнительная оценка трудоёмкости разработки WIMP-интерфейсов 135
5.4 Выводы 137
Основные результаты работы
- Онтологический подход к автоматизации разработки пользовательских интерфейсов
- Модель онтологии
- Метод формирования модели связи интерфейса с прикладной программой
- Методы реализации генератора кода WIMP-интерфейсов
Введение к работе
Актуальность темы. Разработка интерфейсов программных средств, удовлетворяющих требованиям пользователей, является одной из важнейших задач при создании программного обеспечения. Общей тенденцией является усложнение пользовательских интерфейсов, связанное как с увеличением функциональности программ, так и с различными и часто изменяющимися условиями их эксплуатации. В результате на пользовательский интерфейс уходит существенная часть общих затрат на разработку программного средства. Поэтому исследования в области человеко-машинных интерфейсов, направленные на уменьшение трудоемкости разработки и сопровождения являются актуальными. Значительный вклад в решение этой проблемы внесли российские и зарубежные ученые: Гаврилова Т.А., Соснин П.И., Хорошевский В.Ф., Myers В.A., Puerta A.R., Szekely Р.А. и другие.
В настоящее время наибольшее распространение получили WIMP -интерфейсы, в которых взаимодействие с пользователем производится с помощью различных элементов интерфейса (кнопок, меню, списков, полей ввода и т.д.), предназначенных для ввода, вывода и управления информацией. Число таких элементов постоянно увеличивается, а их структура и поведение усложняются. При разработке пользовательских WIMP-интерфейсов в настоящее время используется два подхода, поддерживаемых специализированным инструментарием. Для каждого подхода существует свой класс таких инструментов - построители интерфейса (Interface Builders) или моделеориентированные средства (MB IDE - Model Based Interface Development Environments). Построители интерфейса предназначены для автоматизации процесса разработки их визуального представления с помощью структурных и визуальных редакторов. С использованием построителей интерфейса разрабатывается большинство современных WIMP-интерфейсов. Моделеориентированные средства (МОС) основаны на принципе раздельного проектирования и реализации интерфейса с прикладной программой с последующим их связыванием и предназначены для автоматической генерации кода пользовательского интерфейса по его модели. При этом модель интерфейса разбивается на несколько компонентов и предназначена для описания всех аспектов взаимодействия с пользователем.
Однако в каждом классе инструментов остался нерешенным ряд проблем, в результате которых трудоёмкость разработки и сопровождения интерфейсов остаётся высокой. Так в построителях интерфейса лишь визуальное представление и некоторые компоненты сценария диалога могут описываться с использованием структурных и визуальных редакторов, все остальные компоненты должны
Windows, Icons, Menus, Pointing devices
описываться на языке программирования. В МОС для описания некоторых компонентов модели интерфейса требуется изучение специализированных языков, что увеличивает трудоемкость разработки. Построители интерфейса и МОС ограничены одной платформой и языком программирования, на которые генерируется код интерфейса. Поддержка организации взаимодействия (локального или сетевого) с прикладной программой либо ограничена каким-либо одним фиксированным способом взаимодействия (в МОС), либо полностью отсутствует (в построителях интерфейса разработчик вручную программирует этот компонент программного средства). Разработка и особенно сопровождение интерфейсов с большой системой понятий диалога с помощью указанного инструментария имеют высокую трудоемкость, поскольку в построителях интерфейса отсутствует механизм поддержки отдельного (от компонента представления) описания терминов предметной области; а в МОС, несмотря на наличие специальных возможностей для описания терминов предметной области и генерации пользовательских интерфейсов на их основе, возникает необходимость заново генерировать интерфейс и формировать новую версию программного средства при любом изменении структуры терминов или связей между ними. В построителях интерфейса и МОС возможность повторного использования компонентов пользовательского интерфейса ограничена копированием элементов интерфейса из уже разработанных интерфейсов.
Все вышесказанное определяет актуальность исследований, направленных на решение проблемы автоматизации разработки и сопровождения WIMP-интерфейсов.
Диссертационная работа является частью исследований, выполняемых в рамках предложенного в Институте автоматики и процессов управления (ПАПУ) ДВО РАН онтологического подхода к автоматизации разработки и сопровождения пользовательских интерфейсов. Основная идея подхода заключается в (1) разбиении интерфейса на компоненты в соответствии с системами понятий различных групп специалистов, осуществляющих его разработку и сопровождение; (2) построении для каждой системы понятий модели онтологии, в терминах которой разработчики интерфейса формируют соответствующий компонент его модели; (3) автоматической генерации кода пользовательского интерфейса по его модели. В работах Клещева А.С. и Грибовой В.В. разработана концепция автоматизации проектирования, реализации и сопровождения пользовательского интерфейса на основе онтологического подхода; определены компоненты модели интерфейса и их структура; а также модели онтологии системы понятий диалога, связи интерфейса с прикладной программой и сценария диалога. Но не были разработаны онтология WIMP-интерфейсов, методы формирования модели и методы генерации по ней исходного кода WIMP-интерфейсов.
Целью диссертационной работы является разработка и исследование моделей, методов и инструментального средства для генерации и сопровождения WIMP-интерфейсов на основе онтологического подхода.
Для достижения поставленной цели необходимо решить следующие задачи:
Разработать модель онтологии WIMP-интерфейсов.
Разработать метод формирования модели WIMP-интерфейса.
Разработать метод генерации исходного кода WIMP-интерфейса по его модели.
Разработать методы реализации инструментального средства для проектирования, автоматической генерации и сопровождения WIMP-интерфейсов.
Разработать технологию проектирования и сопровождения WIMP-интерфейсов с помощью разработанного инструментального средства и выполнить ее практическую проверку при разработке WIMP-интерфейсов программных систем.
Методы исследования. Для решения указанных задач использовались методы искусственного интеллекта, теория множеств, теория формальных языков, методы объектно-ориентированного проектирования, методы системного программирования.
Научная новизна работы состоит в следующем:
- впервые разработана модель онтологии WIMP-интерфейсов;
- предложен метод формирования модели WIMP-интерфейса в терминах
онтологии (а не языков спецификаций);
- разработан абстрактный язык для описания структуры исходного кода WIMP-
интерфейсов, не зависящий от конкретной платформы и языка его реализации;
- метод генерации исходного кода WIMP-интерфейса ориентирован на
абстрактный (а не конкретный) язык.
Практическая ценность работы заключается:
- в создании инструментального средства (Onto Dev) для разработки, авто
матической генерации и сопровождения WIMP-интерфейсов на основе онтологии;
в разработке с помощью Onto Dev WIMP-интерфейса Системы интеллектуальной поддержки обследования больных для врача-уролога;
в разработке с помощью Onto Dev WIMP-интерфейса Системы анализа газетных объявлений о купле-продаже недвижимости;
в использовании Onto Dev при выполнении практических занятий по дисциплине «человеко-машинный интерфейс», курсовых и дипломных работ студентами Института математики и компьютерных наук Дальневосточного государственного университета.
Апробация работы. Основные положения диссертации докладывались и обсуждались на Дальневосточных математических школах-семинарах имени академика Е.В. Золотова (Владивосток, 2002-2004; 2007), Первой международной
конференции «Системный анализ и информационные технологии» (Переславль-Залесский, 2005), Международной научной конференции «Интеллектуальные и многопроцессорные системы» (Таганрог, 2005), Открытом дальневосточном конкурсе студентов, аспирантов и молодых специалистов «Программист-2006» (Владивосток, 2006), Научной сессии МИФИ (Москва, 2006), Международной конференции «Параллельные вычисления и задачи управления» (Москва, 2006), на семинарах отдела интеллектуальных систем ИАПУ ДВО РАН и базовой кафедры программного обеспечения ЭВМ ДВГУ (Владивосток, 2002-2007).
Публикация результатов работы. По материалам диссертации опубликовано 17 печатных работ и тезисов докладов конференций, в том числе в двух журналах, рекомендуемых ВАК РФ для опубликования научных результатов диссертаций.
Структура и объем работы. Диссертационная работа состоит из введения, пяти глав и заключения, изложенных на 138 страницах, списка литературы, включающего 141 наименование, и двух приложений. Диссертация содержит 44 рисунка.
Онтологический подход к автоматизации разработки пользовательских интерфейсов
Для решения проблем автоматизации разработки и сопровождения пользовательских интерфейсов в работах Грибовой В.В. и Клещева А.С. [13, 15, 16, 18, 98-99] был предложен онтологический подход. Основные этапы онтологического подхода к автоматизации разработки пользовательских интерфейсов заключаются в следующем:
1) Выделение групп специалистов, осуществляющих разработку и сопровождение пользовательского интерфейса, а также систем понятий, которые они используют при его проектировании и сопровождении. 2) Построение моделей онтологии пользовательского интерфейса, в терминах которых разработчики интерфейса смогут определять и модифицировать структуру конкретной модели пользовательского интерфейса.
3) Разработка метода построения модели пользовательского интерфейса в терминах моделей онтологии.
4) Построение алгоритма автоматического преобразования модели интерфейса в исходный код. Алгоритм автоматического преобразования модели интерфейса в его исходный код должен управляться моделями онтологии, при этом характеристики конкретной модели являются входными данными для этого алгоритма.
Автоматическое построение исходного кода по его модели необходимо для уменьшения трудоемкости разработки (быстрого создания прототипов) и особенно его сопровождения, поскольку в процессе жизненного цикла пользовательский интерфейс подвержен частым изменениям: изменяются требования пользователей, условия эксплуатации, развиваются функциональные возможности программного средства.
В соответствии с первым этапом онтологического подхода, в работах [19, 97] выделены следующие системы понятий пользовательского интерфейса в соответствии с группами специалистов, которые осуществляют его разработку: система понятий диалога, через которую выражаются входные и выходные данные, осуществляется интеллектуальная поддержка пользователя в процессе его взаимодействия с программным средством; разработку системы понятий диалога осуществляют эксперты предметной области; система понятий о средствах представления информации в пользовательском интерфейсе в общем случае определяет интерактивные объекты, используемые на экране в различных состояниях диалога; в терминах данной системы понятий проектировщики интерфейса определяют его дизайн - элементы интерфейса, которые используются в конкретном
2 Исходный код- код на языке реализации, который затем обрабатывается компилятором этого языка. интерфейсе и значения их параметров (расположение на экране, размер, имена и др.); система понятий для описания связи интерфейса с прикладной программой определяет множество программных интерфейсов, которые предоставляют интерфейсу и прикладной программе доступ к функциям друг друга (онтологический подход, также, как и моделеориентированный, основан на раздельном проектировании и реализации интерфейса и прикладной программы с последующим их связыванием); описание связи интерфейса с прикладной программой осуществляют программисты - разработчики прикладной программы; система понятий, связанная со сценарием диалога, определяет множество возможных его состояний и действий, которые выполняются в каждом состоянии; разработку сценария диалога осуществляют, как правило, когнитивные психологи и эргономисты с участием программистов. Для системы понятий диалога, связи интерфейса с прикладной программой, сценария диалога, в работах [14,17, 78] построены модели онтологии. L 5 Выводы из обзора В данной главе рассмотрены современные средства автоматизации разработки интерфейсов. Самыми распространенными из них являются построители интерфейса, этот вид средств предоставляет инструментарий для описания визуального представления, разработка остальных компонентов пользовательского интерфейса этим видом средств не поддерживается. МОС предоставляют инструментарий для описания всех компонентов пользовательского интерфейса и генерируют интерфейс автоматически.
В современных условиях большое значение приобрели следующие возможности средств разработки пользовательских интерфейсов:
1) Возможность разработки интерфейса на различные платформы с использованием различных языков программирования. Построители интерфейса и МОС ограничены всего одной платформой, а часто ещё и одним языком программирования для этой платформы. При этом некоторые построители интерфейса используют многоплатформенные языки программирования, такие как Java, пользовательские интерфейсы, разработанные с их помощью, могут использоваться в различных операционных системах. Однако это привязывает разработчиков интерфейса (и, как правило, разработчиков прикладной программы) к одному языку программирования.
2) Возможность организации как локального, так и сетевого взаимодействия с прикладной программой. В построителях интерфейса средства поддержки организации взаимодействия с прикладной программой отсутствуют -разработчику приходится вручную программировать этот компонент программного средства. В МОС разработчик интерфейса ограничен каким-либо одним фиксированным способом взаимодействия с прикладной программой: либо локальное, либо сетевое, при том, что в случае сетевого взаимодействия поддерживается лишь один из протоколов.
3) Возможность разработки пользовательского интерфейса средствами структурного и визуального редактирования. В построителях интерфейса лишь визуальное представление и некоторые компоненты сценария диалога могут описываться с использованием средств структурного и визуального редактирования, все остальные компоненты должны описываться в текстовом редакторе на языке программирования. В МОС для описания компонентов модели интерфейса используются специализированные (в некоторых случаях текстовые) редакторы, при этом во многих МОС требуется изучение специализированных языков для описания компонентов модели.
4) Возможность описания терминов предметной области. В построителях интерфейса специальные средства описания терминов предметной области отсутствуют. В МОС, несмотря на наличие специальных средств описания терминов предметной области и генерации пользовательских интерфейсов на их основе, при любом изменении структуры терминов или их связей зо возникает необходимость заново генерировать интерфейс и формировать новую версию программного средства.
5) Возможность повторного использования компонентов пользовательского интерфейса. В построителях интерфейса и МОС возможность повторного использования компонентов пользовательского интерфейса ограничена копированием элементов интерфейса из уже разработанных интерфейсов.
6) Возможность расширения инструментария. Инструментарий построителей интерфейса и МОС может расширяться добавлением новых видов элементов интерфейса.
Модель онтологии
В данной главе получены следующие основные результаты. Разработана модель онтологии WIMP-интерфейсов, состоящая из двух уровней: метаонтологии, предназначенной для описания структуры элементов интерфейса и непосредственно онтологии, содержащей описание множества элементов интерфейса. Модель онтологии является расширяемой (т.к. разработана структура модели онтологии - метаонтология, в соответствии с которой описаны элементы интерфейса); модель онтологии не зависит от платформы и языка реализации интерфейса. і
В данной главе представлены методы формирования модели WIMP-интерфейса и генерации исходного кода по его модели.
В данном разделе описывается метод формирования модели WIMP-интерфейса. Согласно онтологическому подходу к разработке пользовательского интерфейса (см. гл. 1.4), его модель является конкретизацией моделей онтологии пользовательского интерфейса и состоит из следующих компонентов [14, 16,18]: модели системы понятий диалога; модели WIMP-представления; модели связи интерфейса с прикладной программой; модели сценария диалога. Компоненты модели WIMP-интерфейса связаны между собой. Эти взаимосвязи, а также контекстные условия, которые должны выполняться при формировании каждого компонента модели, определены в методе. Метод формирования каждого компонента модели WIMP-интерфейса в терминах онтологии осуществляется в соответствии со структурой модели WIMP-интерфейса, описанной в работах Грибовой В.В. и Клещева А.С. [14, 18, 19]. Задание конкретных значений в модели WIMP-интерфейса определяет разработчик интерфейса в соответствии с семантикой программного средства, средой и требованиями пользователей, руководствуясь собственным опытом и принципами. 3.1.1 Метод формирования модели системы понятий диалога
Модель Системы Понятий Диалога (МСПД) описывает множество терминов системы понятий диалога. Эти термины необходимы для представления входных и выходных данных прикладной программы, обеспечения интеллектуальной поддержки действий пользователя в процессе его работы. Модель системы понятий диалога является конкретизацией модели онтологии системы понятий диалога (ОСПД, см. Приложение 1.1). Метод формирования МСПД состоит в указании параметра ИмяСистемыПонятий - имени системы понятий диалога, и построении множества групп терминов ГруппыТерминов. ... Прежде, чем перейти к описанию процесса формирования МСПД, опишем процедуры, которые при этом используются. Процедура Задание значения (ТипЗначения) 1. Если тип значения ТипЗначения является составным, т.е. ТипЗначения = Составное, то задать множество атрибутов (для формирования каждого атрибута Атрибут; є Составное выполнить Задание атрибута (Атрибуті) - см. ниже). 2. Если тип значения ТипЗначения является количественным, т.е. ТипЗначения = Количественное, то конкретное значение задается пользователем в процессе его работы; в модели системы понятий диалога определяются границы интервалов допустимых значений. 2.1. Если Количественное = ЦелоеЗначение, то параметрам ЦелоеМин и ЦелоеМакс присвоить целочисленные значения, обозначающие границы интервала допустимых значений, при этом ЦелоеМин ЦелоеМакс, а параметру ЦелоеМера присвоить строку, обозначающую единицу измерения. 2.2. Если Количественное = ВещественноеЗначение, то параметрам ВещественноеМин и ВещественноеМакс присвоить вещественные значения, обозначающие границы интервала допустимых значений, при этом ВещественноеМин ВещественноеМакс, а параметру ВещественноеМера присвоить строку, обозначающую единицу измерения. 3. Если ТипЗначения = Качественное, то параметр СпособВыбора установить равным Совместный, если способ выбора значений задается как совместный, либо СпособВыбора установить равным Несовместный, если способ выбора значений задается как несовместный; параметру КачественныеЗначения присвоить множество строковых значений атрибута, при этом число элементов множества должно быть не меньше двух. 4. Если ТипЗначения = Строковое, то параметру МаксимальнаяДлина присваивается целое число, параметру СтроковоеЗначение присваивается строка, длина которой меньше, либо равна параметру МаксимальнаяДлина.
Метод формирования модели связи интерфейса с прикладной программой
Модель Связи интерфейса с Прикладной Программой (МСПП) является конкретизацией модели онтологии связи интерфейса с прикладной программой (см. Приложение 1.2) и описывает множество программных интерфейсов, предоставляемых прикладной программой, Interfaces={Interfacei}jn=t1e CCC0 "". Процесс формирования МСПП состоит в определении множества Interfaces, структура которого описана в модели онтологии связи интерфейса с прикладной программой (ОСПП).
Процесс определения программного интерфейса Interface] состоит из следующих шагов: 1. Параметру Interfacenamej присваивается строковое значение - уникальное имя программного интерфейса. 2. Параметр InteractionModel; принимает значение из множества IModels={Локальная, Распределённая}, при этом: a. Если IModels=Лoкaльнaя, то множество параметров IModelparameters={Oauri, Класс}, где Файл= Путь к файлу, String ; параметру «Путь к файлу» присваивается строковое значение, описывающее расположение исходного кода реализации данного программного интерфейса; Класс= Имя класса, String , параметру «Имя класса» присваивается строковое значение, описывающее имя класса, реализующего данный программный интерфейс. b. Если ІМогіе1з=Распределенная, то множество параметров IModelparameters= Aflpec, Порт, Объект , где Адрес = Сетевой адрес, String ; параметру «Сетевой адрес» присваивается строковое значение, описывающее сетевой адрес компьютера, предоставляющего реализацию данного программного интерфейса; Порт = Номер порта, Integer , Параметру «Номер порта» присваивается целое значение, указывающее номер порта, через который производится взаимодействие; Объект = Имя объекта, String , параметру «Имя объекта» присваивается строковое значение, описывающее имя программного объекта на удалённом компьютере, предоставляющего реализацию данного программного интерфейса. 3. Формируется множество функций Functions;, при этом процесс определения каждой функции Function є Functions; состоит из следующих шагов: a. Параметру Function_Namejj присваивается строковое значение уникальное имя функции. b. Формируется множество параметров функции Function_ParameterSjj, при этом для каждого параметра функции Function_Parameterijk є Function_ParameterSy определяется его тип: параметру FuncParamJTypejjk присваивается одно из значений, определенных в модели онтологии: FuncParamJTypejji String и Integer и Float и Boolean. c. Параметру Function_Return_Typejjic присваивается одно из следующих значений, Function_Return_Typejjk = String и Integer и Float и Boolean и 0. Контекстные условия 1. Множество Interfaces должно содержать хотя бы один элемент (не должно быть пустым). 2. Имена всех программных интерфейсов Interfacename,- должны быть различны. 3. Каждый программный интерфейс Interface; должен содержать как минимум одну функцию Function . 4. Имена всех функций Function_Name;j в пределах каждого интерфейса Interface) должны быть различны. 3.1.4 Метод формирования модели сценария диалога
Модель Сценария Диалога (МСД) является конкретизацией модели онтологии сценария диалога (ОСД, см. Приложение 1.3), она описывает начальное окно, множество состояний диалога States, а также действий, которые выполняются в каждом состоянии.
Прежде чем перейти к описанию процесса формирования МСД, опишем процедуры, которые при этом используются. В качестве значений могут использоваться элементы МПР и МСПП. Процедура Задание значения (Value) 1. Присвоить Value параметр элемента интерфейса, Value = Parameter где Parameter (J Parameters (параметр Parameter Window J є WindowDescriptions принадлежит элементу интерфейса, определенному в МПР), при этом Parameter є UIElementm, EventjeUIElementm, UIElementme JJUIElementm (параметр принадлежит UIElement/и є WindowDescriptions элементу интерфейса, событие которого определяется). При этом типом параметра Value является тип параметра элемента интерфейса -Рагат_ТурЄк. 2. Либо присвоить Value переменную из множества переменных описываемого состояния, Value = Variable где Variablek є Variables;. При этом типом параметра Value является тип переменной - Variable_Typek. 3. Либо присвоить Value параметр описываемого события, Value = Event_Paranij, где Event_Paranij - параметр описываемого события Event;, Event_Parairij є Event_ParameterSj, Event_Parameters; є Eventj. При этом типом параметра Value является тип параметра события Event_Param_Typej. 4. Либо присвоить Value функцию элемента интерфейса: 4.1.Value=Functionk, где Functions (jFunctions (функция Windowj є WindowDescriptions Function принадлежит элементу интерфейса, определенному в МПР), при этом FunctionkGUIElementm; EventjGUIElementm, UIElementmG (JUIElementm (функция принадлежит UIElement/и є WindowDescriptions элементу интерфейса, событие которого определяется). При этом типом Value является тип возвращаемого значения функции -Function_Return_Typek. 4.2.3адать множество параметров функции Functionk (для каждого параметра Function_Parameterj є Function_Parametersk, где Function_Parametersk -множество параметров функции Functionk, выполнить Задание значения (FuncParam_Valuei), где FuncParam_Valuei - значение параметра Function_Parameterj). 5. Либо присвоить Value функцию переменной из множества переменных описываемого состояния: 5.1.Value=Functionk, где Functions [JFunctions Variable є Variables Variable_TypejjGWindowm, Windowm є WindowDescriptions (функция Functionk, принадлежит переменной Variabley из множества переменных описываемого состояния, типом которой Variable_Typejj является окно Windowm, которое определено в МПР). При этом типом Value является тип возвращаемого значения функции - Function_Return_Typek. 5.2.Задать множество параметров функции Functionk (для каждого параметра Function_Parameterj є Function_Parametersk, где Function_Parametersk -множество параметров функции Function выполнить Задание значения
Методы реализации генератора кода WIMP-интерфейсов
В качестве средства реализации всех компонентов Onto Dev использовалась среда разработки MS Visual Studio 2005 [124]. В качестве языка программирования использовался язык C++ [29, 51]. Общий объём исходного кода Onto Dev - около 30000 строк на языке C++.
В ходе разработки Onto Dev были реализованы средства генерации кода интерфейса на язык С# для платформы .NET 2 (включая версию .NET для карманных компьютеров - .NET 2 Compact Framework [56, 121]), а также на язык Java [40] для платформы Java 2. Взаимодействие интерфейса с прикладной программой может быть организовано с помощью локальных вызовов, а также через сеть, посредством .NET Remoting с использованием протоколов SOAP и/или TCP/IP.
В данном разделе приводится сравнительный анализ инструментальных средств для разработки WIMP- интерфейсов.
Автоматическая генерация кода интерфейса. Onto Dev и МОС автоматически генерируют исходный код пользовательского интерфейса по его модели. Построители интерфейса автоматически генерируют только код визуального представления, остальные компоненты интерфейса разрабатываются на языке программирования.
Генерация интерфейсов на различные платформы и языки программирования. Onto Dev генерирует интерфейсы на различные языки и платформы: язык С# для платформы .NET 2 (включая .NET 2 Compact Framework - версию .NET для карманных компьютеров) и язык Java для платформы Java 2. Построители интерфейса и МОС генерируют интерфейсы только на один язык и платформу. Локальное и сетевое взаимодействие с прикладной программой.
Onto Dev поддерживает как локальное, так и сетевое взаимодействие интерфейса с прикладной программой. В построителях интерфейса средства поддержки организации взаимодействия с прикладной программой отсутствуют - разработчик должен описывать этот компонент на языке программирования в текстовом редакторе. В МОС разработчик ограничен каким-либо одним фиксированным способом взаимодействия с прикладной программой.
Формирование модели WIMP-интерфейса с помощью специализированных редакторов. В Onto Dev все компоненты модели WIMP-интерфейса формируются с помощью структурных и визуальных редакторов, управляемых моделями онтологии пользовательского интерфейса. В построителях интерфейса специализированные редакторы применяются только для описания визуального представления и некоторых компонентов диалога. В МОС для описания компонентов интерфейса используются специализированные (в некоторых случаях текстовые) редакторы, но при этом, во многих МОС требуется изучение специализированных языков для описания компонентов модели интерфейса (например, СТТ, ACG, ERA, Mimic), что повышает трудоемкость её разработки и сопровождения. Средства автоматизации сопровождения модели WIMP-представления. Onto Dev предоставляет возможность автоматического сопровождения модели WIMP-представления: при изменении терминов МСПД или их структуры автоматически изменяется модель WIMP-представления, при этом не требуется повторная генерация кода. Это достигается за счет того, что при проектировании модели WIMP-представления значениями параметров элементов интерфейса являются ссылки на элементы МСПД, а не конкретные ее элементы. Для реализации этой возможности ОСД снабжена дополнительным набором функций, предназначенных для работы с МСПД по время выполнения программного средства. С помощью этих функций (реализующих загрузку, сохранение, редактирование элементов МСПД и т.д.) пользовательский интерфейс может производить загрузку, изменение и сохранение МСПД во время выполнения, что избавляет от необходимости генерировать его код заново после каждого изменения МСПД. В построителях интерфейса средства описания терминов предметной области отсутствуют. В МОС несмотря на возможность описания терминов предметной области и генерации пользовательских интерфейсов на их основе вместо ссылок используются явные присваивания, что не позволяет автоматически сопровождать модель представления при изменении структуры и связей терминов предметной области.
Повторное использование компонентов модели WIMP-интерфейса. Onto Dev предоставляет средства повторного использования фрагментов МПР, состоящих как из отдельных элементов интерфейса, так и их групп, причём фрагменты МПР могут быть связаны с терминами МСПД, что упрощает поиск нужных фрагментов МПР при дальнейшей разработке. В построителях интерфейса и МОС возможности повторного использования ограничены копированием элементов интерфейса между компонентами визуального представления.
Расширяемость инструментария. Инструментарий Onto Dev может расширяться добавлением новых элементов интерфейса, новых стандартных функций диалога ОСД, новых платформ и языков программирования. Инструментарий построителей интерфейса и МОС в некоторых случаях может расширяться только добавлением новых элементов интерфейса.
