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

Модель онтологии связи интерфейса с прикладной программой (ОСПП) описывает структуру программных интерфейсов Interfaces, используемых при взаимодействии интерфейса и прикладной программы.

Множество программных интерфейсов, предоставляемых прикладной программой Interfaces={Interface_i} . Каждый программный интерфейс Interface_i = < Interfacename_i, InteractionModel_i, Functions_i>, где Interfacename_i – уникальное имя программного интерфейса, InteractionModel_i - модель взаимодействия, описывающая способ взаимодействия интерфейса и прикладной программы через данный программный интерфейс, InteractionModel_i Î IModels (IModels – множество моделей взаимодействия), Functions_i – множество функций, предоставляемых данным программным интерфейсом, Functions_i={Function_ij} .

Множество моделей взаимодействия IModels={IModel_i} , IModel_i=<IModelname_i, IModelparameters_i>где IModelname_i – уникальное имя модели взаимодействия, IModelparameters_i={IModelparameter_ij} – множество параметров. Описание каждого параметра IModelparameter_ij состоит из описания его значения и типа, т.е. IModelparameter_ij = < IParametervalue_ij, IParametertype_ij>, где IParametervalue_ij – значение параметра, IParametertype_ij – тип параметра. IParametertype_ij = { String, Integer }. Значением параметра IParametervalue_ij типа «String» является последовательность символов, допустимых реализацией, значением параметра IParametervalue_ij типа «Integer» является некоторое целое число из множества целых чисел, допустимых реализацией.

Функции программного интерфейса Functions_i описывают множество возможных действий, которые могут производиться в прикладной программе с его помощью, Functions_i={Function_ij} . Каждая функция Function_ij описывается следующим образом: Function_ij = < Function_Name_ij, Function_Parameters_ij, Function_Return_Type_ij >. Function_Name_ij – имя функции, Function_Parameters_ij – параметры функции, Function_Return_Type_ij – тип значения, возвращаемого функцией, Function_Return_Type_ijÎ Func_Type.

Параметры функции Function_Parameters_ij могут состоять из множества параметров функции, Function_Parameters_ij = {Function_Parameter_ijk } . Каждый параметр функции Function_Parameter_ijk описывается своим типом и значением, т.е. Function_Parameter_ijk=< FuncParam_Value_ijk, FuncParam_Type_ijk >, где FuncParam_Value_ijk – значение параметра, FuncParam_Type_ijk - тип параметра, FuncParam_Type_ijkÎ Func_Type.

Тип параметра функции Func_Type = String È Integer È Float È Boolean. Значением параметра FuncParam_Value типа «String» является последо­вательность символов, допустимых реализацией, значением параметра FuncParam_Value типа «Integer» является некоторое целое число из множества целых чисел, допустимых реализацией, значением параметра FuncParam_Value типа «Float» является некоторое вещественное число из множества вещественных чисел, допустимых реализацией, значением параметра FuncParam_Value типа «Boolean» является элемент множества {Истина, Ложь}.

Множество IModels состоит из следующих элементов – IModels = { Локальная, Распределённая }.

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

Локальная = < Локальная модель, IModelparameters_{локальная} >.

IModelparameters_{локальная} = { Файл, Класс }.

Файл = < Имя файла, String >. Описывает имя файла, в котором хранится исходный код реализации данного программной интерфейса.

Класс = < Имя класса, String >. Описывает имя класса в файле с исходным кодом, который реализует данный программный интерфейс.

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

Распределённая = <Распределённая модель, IModelparameters_{распределённая}>.

IModelparameters_{распределённая} = { Адрес, Порт, Объект }.

Адрес = < Сетевой адрес, String >. Описывает сетевой адрес компьютера, на котором находится реализация прикладной программы.

Порт = < Номер порта, Integer >. Описывает номер порта, через который будет производиться взаимодействие.

Объект = < Имя объекта, String >. Описывает имя программного объекта на удалённом компьютере, который предоставляет реализацию данного программного интерфейса.

Обсуждение

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

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

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

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

Модели онтологий, для которых возможно их развитие в процессе жизненного цикла инструментария, имеют двухуровневую структуру. Верхний уровень онтологии (метаонтология) описывает структуру онтологии, в терминах которой может осуществляться ее расширение (развитие). Так, в модели онтологии WIMP-интерфейсов возможно расширение множества интерфейсных элементов; в модели онтологии статических и динамических сцен на плоскости – множества геометрических фигур, цветов, типов линий и их толщины, форматов времени и др.; в модели онтологии для формирования текстов – расширение конструкций форматирования текста; в модели онтологии сценария диалога – расширение множества стандартных функций диалога; в модели онтологии связи интерфейса с прикладной программой - множество моделей взаимодействия. МОС не являются расширяемыми и к тому времени, как такое средство выходит на рынок, оно требует модификации [195].

[1] Выделяется два основных подхода к анализу профессиональной деятельности:

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

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

[2] В литературе также используется следующая терминология: графический образ, графическая схема.

Поиск по сайту: