СПОСОБ И УСТРОЙСТВО СОЗДАНИЯ ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСОВ НА ОСНОВЕ АВТОМАТИЗАЦИИ С ВОЗМОЖНОСТЬЮ ПОЛНОЙ НАСТРОЙКИ Российский патент 2010 года по МПК G06F9/44 G06F7/00 

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

Настоящим осуществлена ссылка на нижеследующие одновременно рассматриваемые и совместно переданные заявки на патент, поданные, таким образом, с той же датой: заявка на патент в США с порядковым номером №_, озаглавленная "METHOD AND APPARATUS FOR GENERATING FORMS USING FORM TYPES" (Способ и устройство создания форм с использованием типов форм) и заявка на патент в США с порядковым номером №_, озаглавленная "METHOD AND APPARATUS FOR MAPPING A DATA MODEL TO A USER INTERFACE MODEL" (Способ и устройство отображения модели данных на модель пользовательского интерфейса), обе из которых являются полностью включенными путем ссылки.

УРОВЕНЬ ТЕХНИКИ

Настоящее изобретение относится к созданию (генерированию) форм. Более конкретно настоящее изобретение относится к способам и устройству, предназначенным для создания пользовательских интерфейсов (ПИ, UI) в виде экранных форм или формообразных (документальных) интерфейсов.

В обычных программных продуктах и приложениях, предназначенных для предприятий (деловых операций), таких как системы планирования ресурсов предприятия (ПРП, ERP) и системы управления взаимосвязями с клиентами (УВК, CRM), используют большое количество экранных форм или формообразных пользовательских интерфейсов. Формой является окно на экране дисплея, диалоговое окно, страница или другой элемент пользовательского интерфейса, предназначенный для просмотра и/или ввода данных. Является нередким, что количество экранных форм, которые используют вместе с программной прикладной системой для предприятия или бизнес-приложением, превышает несколько тысяч.

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

Более того, возрастает сложность в бизнес-приложении, таком как система ПРП, система УВК, и в других приложениях, основанных на формах. Это вызвано множеством факторов, включая: (1) возрастающее количество форм в каждой системе, которое является следствием возросших функциональных возможностей; (2) возрастающее концентрирование внимания на удобстве и простоте использования, исходящее от конечных пользователей, которые привыкли к удобству и простоте использования web-страницы; (3) возрастающее количество различных инструментальных сред или платформ, устройств, и технологий (технических решений); (4) возрастающее концентрирование внимания на обеспечении безопасности, которое может приводить к использованию различных форм в зависимости от прав пользователя; и (5) возрастающее требование гибкости (приспособляемости), эффективности и настройки на требования конкретного пользователя (персонализации). В то же время имеется стимул разрабатывать систему быстрее и с более высоким качеством.

В качестве примера практического бизнес-приложения можно рассмотреть Microsoft Business Solutions-Axapta® компании Майкрософт, которое имеет приблизительно 3000 таблиц, приводя к использованию приблизительно 2000 форм. Каждая форма должна быть настроена или согласована по элементам с компоновкой каждой таблицы, на основании/из которой осуществляют привязку данных, относящихся ко времени исполнения. Формы и связанная с формами логика (обработки) должны быть настраиваемыми всякий раз в случае, когда компоновка таблицы изменяется и когда изменяется бизнес-логика. Увеличивает сложность возрастающее количество различных технологий клиентских платформ. Классический пользовательский интерфейс системы Windows теперь сопровождают Web-браузером. В ближайшем будущем, персональный цифровой ассистент (ПЦА, PDA), телефон сотовой связи и другие технологии ПИ будут вносить свой вклад в эту тенденцию.

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

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

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

Настоящее изобретение обеспечивает решения для одной или нескольких вышеописанных задач и/или обеспечивает другие преимущества над предшествующим уровнем техники.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 - блок-схема одной примерной среды, в которой может быть использовано настоящее изобретение.

Фиг.2 - блок-схема обычной мобильной вычислительной среды (среды мобильных вычислений), в которой может быть осуществлено настоящее изобретение.

Фиг.3-1 - схематическая иллюстрация использования типов форм согласно настоящему изобретению для создания логических форм и физических форм.

Фиг.3-2 - схематическая иллюстрация использования типов форм, показанных на Фиг.3-1, дополнительно иллюстрирующая связь между типами форм и созданием логических форм и физических форм.

Фиг.4-1 - блок-схема, иллюстрирующая примерную бизнес-модель.

Фиг.4-2 - блок-схема, иллюстрирующая логический объект бизнес-модели, отображенный на форму.

Фиг.5-1 - блок-схема, иллюстрирующая последовательность операций создания моделей с использованием отображений и других моделей.

Фиг.5-2 - блок-схема, иллюстрирующая последовательность операций создания конкретной или зависимой от целевого объекта экрана модели на основании исходной модели приложения или бизнес-модели посредством последовательности отображений.

Фиг.5-3 - блок-схема, иллюстрирующая обработку типа, показанного на Фиг.4-1 и 4-2, для примерного варианта осуществления.

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

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

Фиг.7 - блок-схема, иллюстрирующая логические формы, отображенные на конкретные для целевого объекта экрана технологии визуализации.

Фиг.8 - схематическое иллюстрирование идей настоящего изобретения.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

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

Используя системы и способы настоящего изобретения, разработчики приложений могут сосредотачиваться на разработке бизнес-модели. Бизнес-модель (унифицированный язык моделирования (УЯМ, UML), схемы бизнес-ресурсов (БР), класс и т.д.) затем отображают на технологически независимый промежуточный формат, который вновь посредством одного или нескольких этапов отображают на конкретные для целевого объекта экрана технологии и компоновку (Windows, Web-браузер, PDA, телефон и т.д). Разработчики структуры приложения затем могут независимо от разработчиков приложений расширять конкретную для целевого объекта экрана технологию и применять ее к взятому в целом разработанному приложению. Промежуточный формат создают один раз для одной формы и используют для нескольких целевых объектов экрана. Осуществление отображения по своей сути является гибким вследствие открытых и изменяемых (представлений) отображений, используемых процессорами отображений. Промежуточные модели ПИ и конечные форматы целевого объекта экрана также являются открытыми и изменяемыми, предоставляя возможность особенного уровня гибкости. Нижеследующие обсуждения дополнительно иллюстрируют идеи изобретения.

На Фиг.1 проиллюстрирован пример подходящей среды 100 вычислительной системы, в которой может быть осуществлено изобретение. Среда 100 вычислительной системы является лишь одним примером подходящей вычислительной среды и не подразумевает подсказку каких-либо ограничений относительно области использования или функциональных возможностей изобретения. Не следует интерпретировать вычислительную среду 100 в качестве имеющей какую-либо зависимость или требование, относящиеся к любому компоненту или комбинации компонентов, проиллюстрированных в примерной операционной среде 100.

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

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

Со ссылкой на Фиг.1 примерная система для осуществления настоящего изобретения включает в себя вычислительное устройство общего назначения в виде компьютера 110. Компоненты компьютера 110 могут включать в себя, но не являются ограниченными таковыми, блок 120 обработки (процессор), системное запоминающее устройство 130 и системную шину 121, которая связывает различные системные компоненты, включая системное запоминающее устройство, с блоком 120 обработки. Системная шина 121 может быть произвольным типом из нескольких типов шинных архитектур, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любую шинную архитектуру из множества шинных архитектур. В качестве примера, а не ограничения, такие архитектуры включают в себя шину стандартной промышленной архитектуры (ISA), шину микроканальной архитектуры (МСА), шину расширенной ISA (EISA) локальную шину стандарта Ассоциации по стандартам в области видеоэлектроники (VESA) и шину межсоединения (PCI) периферийных компонентов, известную также как шина расширения (шина второго уровня).

Компьютер 110 обычно включает в себя набор машиночитаемых носителей. Машиночитаемые носители могут быть любыми имеющимися носителями, к которым может осуществлять доступ компьютер 110, и включают в себя и энергозависимые, и энергонезависимые носители, сменные и несменные носители. В качестве примера, а не ограничения, машиночитаемые носители могут содержать носители (для) запоминающих устройств компьютера и носители (для) передачи данных. Носители запоминающих устройств включают в себя энергозависимые и энергонезависимые, сменные и несменные носители, осуществленные любым способом или технологией, которые предназначены для хранения информации, такой как машиночитаемые команды, структуры данных, программные модули или другие данные. Носители запоминающих устройств компьютера включают в себя, но не ограничены таковыми: оперативное запоминающее устройство (ОЗУ, RAM), постоянное запоминающее устройство (ПЗУ, ROM), электрически стираемое программируемое ПЗУ (ЭСППЗУ, EEPROM), флэш-память или другую технологию запоминающего устройства, постоянное запоминающее устройство на компакт-диске (КД-ПЗУ, CD-ROM), цифровые универсальные диски (ЦУД, DVD) или другое хранилище на оптическом диске, магнитные кассеты, магнитную ленту, хранилище на магнитном диске или другие запоминающие устройства на магнитных носителях или любой другой носитель, который может быть использован для хранения требуемой информации и к которому может осуществлять доступ компьютер 110. Носитель передачи данных обычно воплощает машиночитаемые команды, структуры данных, программные модули или другие данные в модулированном сигнале данных, таком как несущая или другое транспортное средство, и включает в себя любой носитель для доставки информации. Термин «модулированный сигнал данных» означает сигнал, у которого есть одна или несколько характеристик, устанавливаемых или изменяемых таким образом, чтобы в сигнале закодировать информацию. В качестве примера, а не ограничения, среда для передачи данных включает в себя проводной носитель, такой как проводная сеть или соединение непосредственно проводами, и беспроводной носитель, такой как акустический, радиочастотный (ВЧ, RF), инфракрасного света и другие беспроводные носители. Комбинации из любых из вышеуказанных следует также включать в рамки машиночитаемых носителей.

Системное запоминающее устройство 130 включает в себя носители для запоминающего устройства в виде энергозависимого и/или энергонезависимого запоминающего устройства, такого как постоянное запоминающее устройство (ПЗУ, ROM) 131 и оперативное запоминающее устройство (ОЗУ, RAM) 132. Базовую систему 133 ввода-вывода (БСВВ, BIOS), содержащую базовые процедуры, которые помогают передавать информацию между элементами внутри компьютера 110, как, например, при запуске, обычно хранят в ПЗУ 131. ОЗУ 132 обычно содержит данные и/или программные модули, которые являются непосредственно доступными для блока 120 обработки и/или обрабатываемыми им в настоящий момент. В качестве примера, а не ограничения, на Фиг.1 проиллюстрирована операционная система 134, прикладные программы 135, другие программные модули 136 и программные данные 137. Отдельную группу прикладных программ называют бизнес-приложениями. Они адресованы руководству предприятия, включая, но не являются ограниченными таковыми, обработку общей бухгалтерской книги, реестра запасов предприятия, заработной платы, заказчиков, продаж, закупок, финансовых отчетов и любых других данных, относящихся к деловым.

Компьютер 110 может также включать в себя другие сменяемые/несменяемые энергозависимые/энергонезависимые носители для запоминающего устройства компьютера. В качестве примера только на Фиг.1 проиллюстрирован накопитель 141 на жестком диске, который осуществляет считывание с несменяемых энергонезависимых магнитных носителей или запись на них, накопитель 151 на магнитном диске, который осуществляет считывание со сменяемого энергонезависимого магнитного диска 152 или запись на него, и накопитель 155 на оптическом диске, который осуществляет считывание со сменяемого энергонезависимого оптического диска 156 или запись на такой диск, как, например, ПЗУ на компакт-диске или другие оптические носители. Другие сменяемые/несменяемые энергозависимые/энергонезависимые носители для запоминающего устройства компьютера, которые могут быть использованы в примерной операционной среде, включают в себя, не являясь ограниченными таковыми: кассеты магнитной ленты, карты флэш-памяти, цифровые универсальные диски, цифровую видеоленту, твердотельное ОЗУ, твердотельное ПЗУ и подобное. Накопитель 141 на жестком диске обычно соединен с системной шиной 121 через интерфейс несменяемого запоминающего устройства, такой как интерфейс 140, и накопитель 151 на магнитном диске и накопитель 155 на оптическом диске обычно соединены с системной шиной 121 посредством интерфейса сменяемого запоминающего устройства, такого как интерфейс 150.

Накопители и ассоциированные с ними носители запоминающего устройства компьютера, обсуждаемые выше и проиллюстрированные на Фиг.1, обеспечивают хранилище для машиночитаемых команд, структур данных, программных модулей и других данных для компьютера 110. На Фиг.1, например, накопитель 141 на жестком диске проиллюстрирован в качестве хранящего операционную систему 144, прикладные программы 145, другие программные модули 146 и программные данные 147. Обратите внимание, что эти компоненты могут быть либо теми же, либо отличными от операционной системы 134, прикладных программ 135, других программных модулей 136 и программных данных 137. Операционной системе 144, прикладным программам 145, другим программным модулям 146 и программным данным 147 заданы при этом отличающиеся номера, чтобы проиллюстрировать, что, по меньшей мере, они являются различными копиями.

Пользователь может вводить команды и информацию в компьютер 110 через устройства ввода, такие как клавиатура 162, микрофон 163 и указательное устройство 161, например манипулятор для управления курсором или мышь, шаровой манипулятор или сенсорная клавиатура. Другие устройства ввода (не показаны) могут включать в состав координатную ручку или джойстик, игровую панель, спутниковую антенну, сканирующее устройство или подобное. Эти и другие устройства ввода обычно соединены с блоком 120 обработки через пользовательский входной интерфейс 160, который соединен с системной шиной, но может быть соединен посредством другого интерфейса и шинных структур, таких как параллельный порт, игровой порт или универсальная последовательная шина (УПШ, USB). Устройства ввода данных используют для создания, изменения и удаления данных. Устройства ввода данных также могут быть использованы для управления (запуска и останова) прикладными программами и конкретными функциями при этом. Функции включают открытие (показ) форм и закрытие форм. Монитор 191 или другой тип устройства вывода на экран также соединен с системной шиной 121 через интерфейс, например видео интерфейс 190. В дополнение к монитору компьютеры также могут включать в себя другие периферийные выходные устройства, такие как динамик 197 и принтер 196, которые могут быть соединены через интерфейс 195 периферийных выходных устройств. Монитор или другое устройство вывода на экран используют, чтобы показывать (визуализировать) формы.

Компьютер 110 может действовать в сетевой среде, используя логические соединения с одним или несколькими удаленными компьютерами, например удаленным компьютером 180. Удаленный компьютер 180 может быть персональным компьютером, портативным устройством, сервером, маршрутизатором, сетевым ПК, одноранговым устройством или другим обычным сетевым узлом и обычно включает в себя многие или все элементы, описанные выше относительно компьютера 110. Логические соединения, изображенные на Фиг.1, включают в себя локальную вычислительную сеть (ЛВС, LAN) 171 и глобальную вычислительную сеть (ГВС, WAN) 173, но могут также включать в себя другие сети. Такие сетевые среды являются обычными для учреждений, вычислительных сетей масштаба предприятия, внутрикорпоративных локальных сетей и Интернета.

При использовании в сетевой среде ЛВС компьютер 110 соединен с локальной сетью 171 через сетевой интерфейс или адаптер 170. При использовании в сетевой среде ГВС компьютер 110 обычно включает в себя модем 172 или другое средство для установления связи в ГВС 173, такой как Интернет. Модем 172, который может быть внутренним или внешним, может быть соединен с системной шиной 121 через пользовательский входной интерфейс 160 или другие подходящие средства. В сетевой среде программные модули, изображенные относящимися к персональному компьютеру 110, или их части могут храниться на удаленном запоминающем устройстве. В качестве примера, а не ограничения, на Фиг.1 проиллюстрированы удаленные прикладные программы 185 в качестве постоянно хранимых на запоминающем устройстве 181. Будет оценено, что показанные сетевые соединения являются иллюстративными, и можно использовать другое средство установления линии связи между компьютерами.

На Фиг.2 показана блок-схема мобильного устройства 200, которое является альтернативной примерной вычислительной средой. Мобильное устройство 200 включает в себя микропроцессор 202, запоминающее устройство 204, компоненты 206 ввода/вывода (I/O) и интерфейс 208 связи для обмена информацией с удаленными компьютерами или другими мобильными устройствами. В одном варианте осуществления вышеупомянутые компоненты соединены для связи между собой по соответствующей шине 210.

Запоминающее устройство 204 осуществлено в виде энергонезависимого электронного запоминающего устройства, такого как запоминающее устройство с произвольным доступом (ОЗУ, RAM), имеющее блок резервного аккумуляторного питания (не показан), с тем чтобы информация, хранимая в запоминающем устройстве 204, не была потеряна в случае, когда общее питание мобильного устройства 200 отключено. Часть запоминающего устройства 204 предпочтительно распределена в качестве адресуемой памяти для исполнения программы, тогда как другую часть запоминающего устройства 204 предпочтительно используют для хранения, например, чтобы моделировать хранилище на накопителе на дисках.

Запоминающее устройство 204 включает в себя операционную систему 212, прикладные программы 214, а также хранилище 216 объектов. В течение функционирования операционную систему 212 из запоминающего устройства 204 предпочтительно исполняет процессор 202. Операционная система 212 в одном предпочтительном варианте осуществления является операционной системой торговой марки WINDOWS® CE, доступной для приобретения от корпорации Microsoft. Операционная система 212 предпочтительно разработана для мобильных устройств и осуществляет функциональные возможности (системы) базы данных, которые могут быть использованы приложениями 214 через набор открытых интерфейсов прикладного программирования и методов (функций). Объекты в хранилище 216 объектов являются поддерживаемыми приложениями 214 и операционной системой 212, по меньшей мере, частично в ответ на вызовы или обращения к открытым интерфейсам и методам прикладного программирования.

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

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

АРХИТЕКТУРА И СПОСОБ МНОГОУРОВНЕВОГО И ОТОБРАЖАЕМОГО ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

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

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

Это достигают посредством определения многоуровневого ПИ, которое дает возможность разработчику сосредоточить интеллектуальное усилие на уровне, который имеет "правильный" уровень абстракции. Образы моделей вводят с сохранением и повторно используют на каждом уровне абстракции. Отображения от более высоких уровней абстракции на более конкретные уровни вводят/копируют образы моделей в ходе осуществления отображения, но также дают возможность разработчику приложений тонко настраивать результаты. Настоящее изобретение использует эти отображения наряду с управляющими элементами, типами логических форм и поведениями, чтобы отобразить бизнес-модель на физические модели, предназначенные для конкретного целевого объекта экрана (зависимые от целевого объекта).

В способах настоящего изобретения бизнес-модель является главной (эталонной). Интеллектуальную работу, воплощенную в бизнес-модели, сохраняют и используют в качестве основы для создания пользовательского интерфейса. Модель может быть описана на унифицированном языке моделирования (УЯМ), схемой бизнес-ресурсов (БР) или на любом другом графическом или неграфическом языке моделирования. Бизнес-модели также могут быть обеспечены (представлены) в виде классических объектно-ориентированных программ, реляционных баз данных или в других форматах. Как описано ниже, в некоторых примерных вариантах осуществления настоящего изобретения бизнес-модели являются иерархией классов сущностей, имеющих свойства.

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

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

В некоторых вариантах осуществления настоящего изобретения модель ПИ отображают на конкретный для целевого объекта экрана язык разметки, такой как язык активных серверных страниц (ASP.NET), язык разметки для беспроводной связи (ЯРБС, WML), язык разметки гипертекста (ЯРГТ, HTML) и т.д. Модель ПИ также может быть отображена на другие технологии отображения информации (например, Win32, WinForms, PocketPC). В одном частном примерном воплощении изобретения логические формы отображают на целевой объект экрана для Web-клиента, целевой объект экрана для клиентской части WinForms и т.д., и могут быть динамически добавлены новые целевые объекты экрана.

В соответствии с вариантами осуществления настоящего изобретения выполнение отображения основано на декларативных отображениях, которые являются открытыми и изменяемыми. Образы моделей ПИ сохраняют/отражают в отображениях. Отображения могут быть созданы на основании нескольких условий, что приводит к высокой степени гибкости. Различные модели могут быть изменены вручную (включая посредством программы) после того, как они были отображены. Это дает разработчику конечный уровень гибкости. Динамическая суть отображений обеспечивает разработку и использование новых элементов ПИ, например управляющих элементов. Новые управляющие элементы просто задействуют на форме посредством отображения свойств на новые управляющие элементы. Новые управляющие элементы должны подчиняться некоторому соглашению в этом воплощении, что новые управляющие элементы должны быть наследованы (произведены) от указанного базового класса. Во время исполнения логическую форму связывают с сущностями, и целевой объект экрана связывают с логическим уровнем. Это позволяет, чтобы все функциональные возможности, которые являются общими для целевых объектов экрана (защита, персонализация, логика внутри формы), были осуществлены один раз на логическом уровне и использованы во многих экземплярах (формы).

ТИПЫ ФОРМ

Настоящее изобретение использует понятия логических форм и типов логических форм, чтобы обеспечить новый способ создания пользовательских формообразных интерфейсов (форм) для бизнес-приложений и других приложений. Тогда как в примерных вариантах осуществления или реализациях настоящего изобретения используют логические формы и типы логических форм, использование логического уровня не является необходимым во всех вариантах осуществления. Таким образом, настоящее изобретение применяет использование типов форм, чтобы создавать формы в целом. Бизнес-приложения на сегодняшний день обычно состоят из большого количества форм, которые часто делятся на несколько категорий или следуют сходной модели. Количество категорий обычно находится между двумя и двадцатью, но может быть задано большее количество. Типы форм согласно настоящему изобретению содействуют управляемым моделью пользовательским интерфейсам посредством сохранения и действия согласно бизнес-модели или модели приложения и во время проектирования, и во время исполнения. Это обеспечивает разработчику программного обеспечения высокий уровень абстракции. Дополнительно использование типов форм в соответствии с настоящим изобретением обеспечивает повторное использование (одну компоновку используют многократно), значительно более однородный набор пользовательских формообразных интерфейсов, поскольку все формы делятся на несколько различных типов, и формы, которые более удобно поддерживать (компоновка для типа может быть изменена без изменения формы, и другой тип может быть применен без изменения формы). Изобретение обеспечивает, что разработчики приложений имеют полный («сплошной») контроль по многим целевым объектам экранов над «впечатлением и ощущением от использования приложения» и над тем, как происходит навигация (передвижение) в пределах приложения. Примеры целевых объектов экранов включают в себя каждый из многих типов существующих и будущих операционных систем, а также каждый из многих доступных или будущих мобильных устройств. В качестве другого примера каждая технология визуализации в конкретной операционной системе также может быть целевым объектом вывода на экран.

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

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

РАЗЛИЧНЫЕ ТИПЫ ФОРМ

Как упомянуто, в типичном использовании настоящего изобретения предусмотрены многие различные типы форм для использования разработчиком приложений при создании форм. Например, в одном примерном варианте осуществления типы форм могут включать в себя тип формы Dialog (Диалог), тип формы Card (Карта) или CardView (Представление в виде карты), тип формы ListView (Представление в виде списка), тип формы EntityOverview (Обзор сущностей) и тип формы ActivityCenter (Центр деятельности). Эти типы форм соответствуют типичным различным категориям форм, используемым в бизнес-приложении в одном примере. Таким образом, обеспечение многих типов форм дает возможность разработчикам приложений создавать все формы, которые составляют современное бизнес-приложение. Как будет понятно специалисту в данной области техники, эти конкретные типы форм являются просто примером, и настоящее изобретение не ограничено какими-либо конкретными типами форм или каким-либо конкретным количеством типов форм.

КОМПОНОВКА ТИПА ФОРМЫ

Содержимое и структура информации о компоновке могут быть различными для каждого типа формы. Дополнительно информация о компоновке может быть зависимой от целевого объекта экрана. Например, информация о компоновке для типа формы ActivityCenter может иметь поддержку для Themes/Skins/Styles (Темы/Поверхностные слои/Стили) и Master Pages (шаблоны страниц), которые будут использованы целевым объектом HTML (то есть глобальной гипертекстовой системой или сетью Интернет), для показа на экране формы на платформе конкретной операционной системы. Это дает бизнес-разработчику свободу ввести новшества на различных целевых объектах экранов и подстраивать формообразный пользовательский интерфейс так, как необходимо.

СМЕННЫЙ И РАСШИРЯЕМЫЙ

Типы форм предлагают полную гибкость и расширяемость, поскольку независимый поставщик (разработчик) программного обеспечения (ИПП, ISV) может их изменять или расширять и создавать новые типы форм, таким образом изменяя «впечатление и ощущение» для всего приложения.

Обратимся теперь к Фиг.3-1 и 3-2, на них показаны схематические иллюстрации логической формы Sales Order (Заказ на закупку), созданной с использованием типа формы Card в соответствии с примерным вариантом осуществления настоящего изобретения. В этом примере логическая форма Sales Order содержит набор логических управляющих элементов, сгруппированных в три различные группы логических управляющих элементов. Как будет описано дополнительно ниже, тип формы Card задает, каким образом и где управляющие элементы появятся на физических формах на различных целевых объектах экрана. На Фиг.3-1 и 3-2 проиллюстрирована аналогичная с Фиг.3-2 информация, включая стрелки, иллюстрирующие связи и источники информации между типом логической формы и логической формой, и создание физической формы на основании логической формы.

На Фиг.3-1 и 3-2 схематически проиллюстрирован экземпляр 305 формы, созданный с использованием типа 300 формы. На базовом клиенте 310 экземпляр 305 формы является логической формой 306 (показанной в качестве концептуальной модели формы), и тип 300 формы является типом 301 логической формы. На целевом объекте 320 экрана форма 305 является визуализируемой формой 370, созданной с использованием логической формы 306, и в конечном счете на основании типа 301 логической формы. Визуализируемая форма 370 является одной конкретной реализацией, но могут быть выполнены многие другие реализации или визуализации. Визуализируемую форму 370 можно также называть физической формой.

Тип 300 формы включает в себя две части, схему 330, которая задает то, что должно быть включено в конкретные формы, использующие тип формы, и компоновку 331, которая включает в себя управляющие элементы, которые описывают, как форма должна быть визуализирована или изображена (вычерчена) на конкретном целевом объекте экрана. Тип формы также может включать в себя программный код, скрытый за классом. При наличии различных компоновок, которые могут быть использованы типом формы, те формы, которые созданы с использованием типа формы, могут быть приспособлены к различным целевым объектам экранов (например, экранам дисплеев телефонов сотовой связи, экранам дисплеев персональных цифровых ассистентов, экранам мониторов персональных компьютеров и т.д.). С помощью типа 300 формы, представляющего сохраненную модель, которая подлежит использованию во многих формах, могут быть созданы многие экземпляры 305 формы.

Можно рассмотреть для данного примера операции, через которые может пройти разработчик, чтобы создать форму для сущности или объектной модели Sales Order (то есть бизнес-модели или модели приложения). Сначала разработчик может просмотреть, чтобы представить себе, из которых видов форм он или она должны выбирать. Выбор типа формы "Card", как показано в (позиции) 325 на Фиг.3-1 и 3-2, вызывает или обозначает схему 330 Card, как представлено стрелкой 326 на Фиг.3-2.

Когда разработчик задает конкретный тип формы и связанную схему, он или она находятся в некоторых вариантах осуществления, выбирая для включения в форму информацию или поля, предписанные схемой, вместе с метаданными на основании бизнес-модели или другой модели пользователя, заполняя значения полей. Например, в соответствии с выбором типа 301 формы Card (и связанной схемы 330 Card) логическая форма 306 будет включать в себя Content Area (Область содержимого) 336, соответствующую области Content Area 335, заданной в схеме 330. Источник Content Area 336, соответствующий Content Area 335, представлен стрелкой 337 на Фиг.3-2. Подобным образом, поскольку схема 330 для типа формы Card включает в себя область 340 раздела (описания) ПИ, область 345 раздела ПИ для связанной сущности и область 350 действия, то логическая форма 306 включает эти области или поля, а также показанные в (позициях) 341, 346 и 351. Вновь источники этих полей представлены схематически стрелками 342, 347 и 352.

Как упомянуто выше, каждый тип формы также включает в себя по меньшей мере одну компоновку 331 (обычно одну на один целевой объект экрана), которая включает в себя управляющие элементы, описывающие, как форма должна быть визуализирована или вычерчена на конкретном целевом объекте экрана. Как показано схематически на Фиг.3-1 и 3-2, компоновка для типа формы Card включает в себя управляющие элементы, которые вызывают, что целевой объект 320 экрана включает в состав область 339 содержимого, область 344 раздела ПИ, область 349 раздела ПИ для связанной сущности и область 354 действия. Стрелками 338, 343, 348 и 353 проиллюстрировано соотнесение этих областей в компоновке «карты» с их соответствующими областями в схеме для Card. Логическую форму 306, которая создана с использованием выбранного типа логической формы и метаданных на основании модели приложения (в данном примере сущности Sales Order), визуализируют в качестве физической формы 370 на целевом объекте 320 экрана. Эта последовательность операций проиллюстрирована на Фиг.3-2 с помощью стрелок 361 и 362.

МОДЕЛИ И ОТОБРАЖЕНИЯ

Многие информационные системы используют модели. Примерами моделей являются: схемы объектов, схемы расширяемого языка разметки (РЯР, XML), определения баз данных и определения форм. Модель часто определяют как набор объектов, каждый из которых имеет свойства, структуры и связи (ассоциации). В пользовательских интерфейсах для бизнес-приложений (бизнес-ПИ) иерархии управляющих элементов, которые используют для визуализации форм, могут рассматриваться в качестве моделей, таких как древовидные структуры управляющих элементов системы Windows и объектные модели языка разметки гипертекста (HTML). К тому же можно использовать синтаксис, например, унифицированного языка моделирования (языка UML), чтобы задать модель (например, определения классов). В примерной структуре приложения, используемой для иллюстрирования способов настоящего изобретения, приложения моделируют с использованием бизнес сущностей. Таким образом, бизнес-модель состоит из этих бизнес объектов, называемых сущностями, связей между сущностями и свойств сущностей. См. для примера простой модели 380 сущности 381, 382, 383 и 384, показанные на Фиг.4-1. Сущности имеют свойства (см., например, свойства 385 сущности 381) и связи с другими сущностями (см., например, связи 386 между сущностями 381 и 384).

В случае когда модель преобразуют в другую модель, отображения являются используемыми явно или иногда неявно. Отображения описывают связи между моделями. Некоторые примеры включают в себя: преобразование расширяемого языка (таблиц) стилей (ПРЯС, XSLT), которое предназначено, чтобы отображать (документ) XML на XML; управляющие элементы, используемые для визуализации объектной модели на поверхности конкретного устройства; отображения команд (упорядоченности) одного приложения на другое (поскольку команды в различных приложениях могут иметь различные форматы) и инструментальные средства автоматизированного проектирования и создания программ (CASE-средства), которые отображают ЯУМ на определения классов.

В современных бизнес-приложениях отображения по большей части запрограммированы с использованием по-объектного отображения («один объект единовременно»), означая, что осуществления отображений программируют в виде предложений "switch" ("переключение") в программе, которая принимает конкретный объект в качестве входных данных и возвращает другой объект. Таким образом, традиционные бизнес-приложения обычно используют императивные отображения, отображения, записанные в программе на обычном языке программирования. Посредством использования «по-модельного» отображения в соответствии с настоящим изобретением утверждают, что производительность может быть повышена на порядок величины. Помимо роста производительности, имеется умственный рост в восприятии задачи создания ПИ в виде осуществления отображения моделей на другие модели с использованием отображений. Дополнительно другим преимуществом является более высокий уровень абстракции, обеспеченный в декларативно задаваемых отображениях согласно настоящему изобретению. Настоящее изобретение позволяет отображениям быть явными и декларативными. В настоящем изобретении отображения могут быть либо декларативными, либо императивными (вследствие факта, что осуществление отображения можно переопределять в программе).

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

Декларативный характер отображений означает, что отображения не являются императивными (запрограммированными на обычном языке программирования). Как используют в настоящем документе, фраза "заданный декларативно" означает, что отображения не только не задают в программе, как происходило традиционно, но их задают в формате, который дает возможность легко изменять отображения. Примеры декларативно задаваемого формата включают в себя, но не являются ограниченными таковыми, документы XML, файлы с разделяющими запятыми, схемы отображения системы BizTalk (отображающие одну схему данных на другую) и отображения объектов Microsoft Business Framework (отображение объектной модели на схему базы данных). Можно использовать широкое разнообразие форматов декларативного отображения в соответствии с настоящим изобретением, и какой формат является выбранным, не имеет особого значения. Является важным, что декларативное отображение имеет ограниченный набор возможностей, следовательно, проще обеспечить инструментальное средство интуитивного проектирования для того, чтобы задавать отображение. Напротив, императивное отображение (использующее программу) имеет почти неограниченные возможности посредством языка программирования, и следовательно, чрезвычайно трудно создать инструментальное средство интуитивного проектирования. Скорее, для его создания необходимы навыки программирования.

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

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

УПРАВЛЯЕМЫЙ МОДЕЛЬЮ ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС НА ОСНОВЕ ОТОБРАЖЕНИЙ

Наличие модели приложения является важным признаком при создании ПИ для бизнес-приложения, встроенным в варианты осуществления настоящего изобретения. Значительное большинство ПИ может быть создано исключительно на основе модели бизнес-логики и отображений. В случае когда разработчик приложений создал модель новой сущности, ПИ выводят из нее. Это схематически проиллюстрировано на Фиг.4-2, на которой проиллюстрирована бизнес-модель 380, отображаемая (как показано в 388) на модель 390 ПИ. Стрелка 388 представляет последовательность операций отображения, а также соответственно настроенный процессор отображений, который использует представление отображения, чтобы управлять операциями осуществления отображения.

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

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

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

Например, можно рассмотреть блок-схему 400, показанную на Фиг.5-1, на которой проиллюстрированы последовательность операций отображения главной модели 405 на конкретизированную модель 425 с использованием двух явных и декларативных этапов осуществления отображения. Главная модель 405 (то есть "модель А") может быть, например, базой данных, таблицей, сущностью, объектом или другими типами моделей в предметной области, конкретной для пользователя. Главную модель 405 отображают на промежуточную модель 415 (то есть "модель B") с помощью этапа отображения, проиллюстрированного позицией 411, с использованием отображения 410 (то есть "отображения A-B"). Промежуточная модель 415 может быть независимой от целевого объекта экрана моделью, имеющей логические управляющие элементы, как будет описано более подробно ниже. Промежуточную модель 415 затем отображают на конкретизированную модель 425 (то есть "модель C") с помощью этапа отображения, проиллюстрированного позицией 421, с использованием второго отображения 420 (то есть "отображения B-C"). Конкретизированная модель 425 может быть зависимой от объекта экрана моделью, содержащей физические управляющие элементы, как также будет описано ниже более подробно. Стрелки, используемые для представления этапов отображения 411 и 421, также представляют процессоры отображений, которые настроены с возможностью использования отображений 410 и 420, чтобы осуществлять этапы отображения.

В соответствии с некоторыми вариантами осуществления настоящего изобретения схема осуществления отображения, включенная в определение того, каким образом дать возможность пользователю взаимодействовать с бизнес-информацией на клиентской платформе, включает в себя по меньшей мере три этапа, как описано ниже и как показано схематически на блок-схеме 450 по Фиг.5-2. Исходная модель 455 (см. также главную модель 405, показанную на Фиг.5-1) содержит информацию о бизнес-сущностях, с которыми пользователь должен взаимодействовать. Каждый элемент данных этой модели приложения имеет конкретный тип. Первый этап включает в себя определение логического управляющего элемента, который надлежит использовать для заданного типа (строка, целое число, десятичный тип, представляющий денежные значения, адреса, содержащие другие значения и т.д.) представляемого элемента данных.

Логический управляющий элемент, подлежащий использованию для заданного типа, определяют, используя отображение типа данных в модели 455 на логический управляющий элемент в модели 465. Последовательность операций отображения проиллюстрирована в 461 и использует отображение 460 (то есть "отображение типа элемента данных на логический управляющий элемент"). Логические управляющие элементы имеют несколько полезных свойств. Они полностью свободны от зависимостей от какого-либо конкретного целевого объекта экрана, но содержат свойства, которые управляют поведением зависимых от устройства физических управляющих элементов. Поиск логических управляющих элементов выполняют, принимая во внимание иерархию типов. Если нет логического управляющего элемента, точно подходящего для инкапсулирования (заключения в себе) свойств конкретного типа, поиск продолжают с базового типа, пока не будет найден логический управляющий элемент для обработки типа.

Как только логический управляющий элемент был идентифицирован на основании представляемого типа данных, должен быть найден физический управляющий элемент, используемый для фактического выполнения визуализации на данной платформе. Эти физические управляющие элементы иногда называют "адаптерами". Это осуществляют, используя другое отображение, выдающее физический управляющий элемент на основании логического управляющего элемента и целевого объекта экрана. Последовательность операций отображения проиллюстрирована в 471 и использует отображение 470 (то есть "отображение логического управляющего элемента на физический управляющий элемент"), чтобы создать модель 475 физических управляющих элементов на основании модели 465 логических управляющих элементов.

В случае когда клиент исполняется на пользовательском целевом объекте, физический управляющий элемент будет использован для создания экземпляров внутренних управляющих элементов, используемых для взаимодействия с пользователем. Это осуществляют посредством третьего отображения, выдающего набор внутренних управляющих элементов на основании физического управляющего элемента. Например, если физический управляющий элемент является управляющим элементом для адреса, то физический управляющий элемент отобразят на внутренние управляющие элементы, предназначенные для «улицы», «города», «страны». Последовательность операций отображения проиллюстрирована в 481 и использует отображение 480 (то есть "отображение физического управляющего элемента на внутренний управляющий элемент"), чтобы создать модель 485 внутреннего управляющего элемента на основании модели 475 физического управляющего элемента. В некоторых вариантах осуществления это является императивным отображением, но это не должно быть обязательным. Вновь стрелками 461, 471 и 481 также представлен процессор(ы) отображений, используемый для осуществления функций отображения, как указано отображениями 460, 470 и 480. Осуществление отображения, описанное выше, может быть расширено с помощью других отображений, чтобы достичь требуемого результата. Другие факторы включают в себя тип визуализируемой формы (представление в виде карты или перечня), пользовательскую роль (которая возможно ограничивает информацию, предлагаемую пользователю). Последовательность операций достижения конкретной модели на основании абстрактной модели является полностью в виде предписаний (посредством описания включаемых отображений), и гибкость предоставлена способностью изменять эти отображения.

В качестве другого примера на Фиг.5-3 проиллюстрирована блок-схема 500, показывающая последовательность операций отображения для перехода от имени заказчика и идентификационного номера, или идентификатора (ID), к HTML, используемому для визуализации этой информации в браузере. Главная или исходная бизнес-модель 505 является сущностью (или объектом) или классом сущностей (или классом объектов), имеющих имя заказчика и идентификатор в качестве свойств. Свойства "Name" (имя) и "ID" (идентификатор) модели 505 являются типами "String" (строковый) и "Number" (числовой) соответственно. Модель 505 отображают на уровень логических управляющих элементов, соответствующий модели 515, с использованием отображения 510, имеющего вид предписаний. Последовательность операций отображения представлена в 511. В этом примере тип данных "String" отображают на логический управляющий элемент "TextBox" (текстовое окно), тогда как тип данных "Number" отображают на логический управляющий элемент "NumberBox" (числовое окно).

Затем модель 515 логического управляющего элемента отображают на модель 525 HTML с использованием отображения 520. Последовательность операций отображения представлена в 521. В этом примере модель 525 является моделью физических управляющих элементов в формате модели HTML. Таким образом, отображение 520 отображает логические управляющие элементы модели 515 на символы разметки (теги) HTML или элементы в модели 525. Модель HTML 525 затем используют, чтобы визуализировать в браузере информацию на основании модели 505. Вновь стрелки, используемые для представления этапов 511 и 521 отображения, также представляют соответственно настроенные процессоры отображений, которые используют отображения 510 и 520, чтобы осуществить последовательность операций отображения.

На Фиг.5-4 проиллюстрирован дополнительный аспект вариантов осуществления настоящего изобретения, в котором несколько различных типов свойств могут быть отображены на одни и те же конечные управляющие элементы, так что количество требуемых управляющих элементов не обязательно увеличивается в случае, когда увеличивается количество типов свойств. Как показано в блок-схеме 550 по Фиг.5, бизнес-модель 560, имеющая свойства 561, относящиеся к различным типам, отображают на модель 580 целевого объекта экрана, используя отображения 555. Подобно предварительно обсужденным примерам, модель 560 отображают на модель 570 логического уровня, которая содержит логические управляющие элементы 571. Процессор отображений и последовательность операций отображения, которые используют отображение 565, проиллюстрированы в 566. Отображение 565 отображает типы элементов данных ("IDType" (тип-идентификатор), "String" и "Float" (число с плавающей точкой)) свойств 561 модели 560 на логические управляющие элементы ("Number" и "String"). В этом случае и "IDType", и типы элементов данных "Float" отображают на тип "Number" логического управляющего элемента, тогда как тип элемента данных "String" отображают на тип "String" логического управляющего элемента.

Затем модель 570 логического уровня отображают на модель 580 целевого объекта экрана, которая содержит физические управляющие элементы 581, определенные для конкретного целевого объекта экрана. Модель 570 отображают на модель 580, используя отображение 575, с помощью последовательности операций и процессора отображения, представленных в 576. Отображение 575 отображает типы "Number" и "String" логических управляющих элементов модели 570 на тип физического управляющего элемента "TextBox" модели 580, иллюстрируя вновь, что несколько различных типов из конкретной модели могут быть отображены на один тип в другой модели. Посредством расширения несколько различных типов свойства из бизнес-модели могут быть отображены на один и тот же конечный (например "физический") управляющий элемент.

Опыт разработчика

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

- изменить бизнес-модель, чтобы отразить требования. Например, в некоторых вариантах осуществления, если сортировка последовательности свойств является неправильной, допустим, что ID должен быть выведен на экран перед Name, тогда сущность может быть отредактирована. В других вариантах осуществления упорядочение свойств хранится во внешнем "поведении". Однако упорядоченное группирование свойств может быть "добавлено" к сущности, и его можно использовать, чтобы осуществить это (упорядочение). Таким образом, в таких вариантах осуществления лучшим подходом может быть изменение порядка в группировании.

- Изменить созданную логическую модель формы. Переключение Name и ID также может быть выполнено в форме. Это потенциально представляет некоторый трудный вопрос для сопровождения впоследствии, если изменяют бизнес-логику, например, так, что изменение в бизнес-логике повторно записывает (переопределяет) изменения в форме. Также может быть необходимо изменить бизнес-логику на каждой форме.

- Изменить отображение. Если ID отображают на управляющий элемент Number, но управляющий элемент String является более подходящим, отображение является надлежащим местом, чтобы осуществить изменение.

Имеется ряд преимуществ в изменении отображения вместо более традиционной модификации моделей. Прежде всего, изменения могут иметь более широкую область действия. Если элемент отображения, используемый в предыдущем примере, был изменен, все сущности, использующие "IDType", автоматически получат обновление. Это приведет к весьма согласованному (единообразному) ПИ, из которого конечный пользователь извлечет преимущество.

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

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

Язык отображения

Формирование отображения использует простой декларативный язык отображения, который является расширяемым. Формирование отображения принимает один или несколько символов (лексических единиц) в качестве входных данных и возвращает один или несколько символов в качестве выходных данных. Для заданного типа свойства в качестве входных данных один или несколько логических управляющих элементов могут быть заданы в качестве выходных данных. Также должно быть возможным задавать выходные данные нулевыми. Например, "IDType" может быть машинно-генерируемым полем, которое пользователь не может редактировать или видеть, в каком случае тип ничему не соответствует. Также формирование отображения может управлять параметрами выходных данных. Например, свойство "String" может приводить к TextBox с более широкими возможностями по сравнению с другими TextBox на форме.

Чтобы обрабатывать вопрос области действия, на который обращалось внимание ранее, условие области действия является необходимым на предварительно обсужденной примерной форме для отображения типов "IDType" на управляющие элементы "IDControl" (идентификатор управляющего элемента), но на всех других формах используют управляющий элемент «Number». Другие параметры также могут использоваться в качестве области действия, включая бизнес-сущность, стереотип сущности, тип формы и т.д. Имеются другие условия, которые было бы полезно принимать во внимание, когда должно быть выполнено отображение. Одним примером является родительский управляющий элемент. Если родительский управляющий элемент является перечнем (list), то свойство нумератора (enumerator) можно выбрать для отображения на (управляющий элемент) "выпадающий список", а не на управляющий элемент «селективная кнопка». Другим условием может быть количество возможных вариантов выбора в нумераторе; селективные кнопки можно использовать, если их две или три, но несколько вариантов выбора могут иметь результатом перечень. Двигаясь по этому пути, язык формирования отображения приводит к тому, что является весьма сложным по сравнению с исходным требованием, и для разработчиков необходим другой уровень абстракции на верхнем уровне отображения, чтобы понимать отображения. Такая структура была представлена с помощью преобразований расширяемого языка таблиц стилей (ПРЯС), в которых были осуществлены несколько инструментальных средств, чтобы скрыть сложность.

ЛОГИЧЕСКИЕ ФОРМЫ - МОДЕЛЬ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

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

На Фиг.6 схематически проиллюстрированы действия периода времени проектирования и действия времени исполнения, которые применяют при создании формы. Во время проектирования используют инструментальные средства 605 моделирования, чтобы создать модели или определения форм, и представления отображений такие, как обсужденные выше. Эти определения форм и представления отображений могут быть сохранены в базе 610 метаданных.

Во время исполнения модели или формы отображают на модель 625 логического уровня. Модель 625 логического уровня создают также, используя данные, относящиеся ко времени исполнения, хранимые в базе 615 данных, применяемой к бизнес-логике 620. Также во время исполнения модель 625 логического уровня отображают на модель 630 целевого объекта экрана, как описано выше.

Логический уровень, включающий в себя формы и управляющие элементы, является мостом между бизнес-логикой 620 и целевыми объектами 630 экрана. Он содержит ограниченное знание относительно компоновки и ограниченное знание относительно бизнес-логики. Логический уровень задает содержимое формы на основании бизнес-сущностей и обрабатывает общие вопросы «времени исполнения», такие как привязка данных форм к экземпляру бизнес-сущностей, относящемуся ко «времени исполнения». Кроме того, логический уровень обрабатывает защиту, общую для всех целевых объектов экранов; он поставляет метаданные на каждый целевой объект экрана, и логический уровень может обрабатывать проверку правильности входных данных.

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

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

ЦЕЛЕВЫЕ ОБЪЕКТЫ ЭКРАНА

Логические формы и управляющие элементы отображают на конкретные технологии визуализации, используемые целевыми объектами экрана. Как и на других чертежах, это проиллюстрировано на Фиг.7, на которой модель логического уровня или форма 705 отображена на несколько конкретных целевых объектов экрана. В этом частном примере целевой объект 710 экрана использует технологию визуализации системы Windows, тогда как объект экрана 715 использует технологию визуализации Web. Целевые объекты экрана отвечают за обработку всех пользовательских взаимодействий, включая визуализацию форм и управляющих элементов и обработку пользовательских входных данных. Каждый целевой объект экрана требует некоторого количества управляющих элементов с тем, чтобы управляющие элементы на логическом уровне были отображены на нечто значащее. То есть свойство должно быть совместимо с типами значений, которые управляющий элемент может обрабатывать, и управляющий элемент должен визуализировать это значение осмысленным (видимым) образом. Другими словами, не имеется конкретного количества управляющих элементов, которые должны быть доступными в каждом целевом объекте экрана, поскольку методика формирования отображения имеет существенное воздействие на это.

Целевые объекты экрана управляют пользовательским взаимодействием и по существу также парадигмой взаимодействия. Web-страница и окно Forms системы Windows могут быть созданы на основании одной и той же логической формы, но используют ли они стратегию разговорного взаимодействия или стратегию коротких обратных почтовых сообщений, естественно определяют (в соответствии с) целевым объектом экрана. Каждый целевой объект экрана выбирает, в какой степени форму отображают пользователю. Форма системы Windows может скрывать информацию на страницах вкладки, тогда как Web-страница может выбрать показ всей информации сразу. Эти решения принимают на основании логической формы и, таким образом, также на основании типа формы, который получают целевые объекты экрана. Различные целевые объекты экрана нуждаются в дополнительной информации, чтобы принимать такие решения по разбиению на страницы, и подобным образом логические формы и управляющие элементы могут быть аннотированы информацией о конкретном целевом объекте экрана.

ПОВЕДЕНИЯ - ДЕКЛАРАТИВНАЯ ЛОГИКА ФОРМЫ

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

В то же время имеются многие модели в виде программ, которые добавляют к формам. Например, программу для отключения поля, если другое поле заполнено, используют во многих формах. Если на форме выбрано "Cash" (Наличные деньги) в качестве вида оплаты, то поле "Credit Card Number" (Номер кредитной карточки) является затененным или даже скрытым.

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

ПРИМЕР МНОГОУРОВНЕВОЙ СИСТЕМЫ И СПОСОБА

Обратимся теперь к Фиг.8, на ней показана схематическая иллюстрация многоуровневой системы и способа, которые осуществляют различные понятия, описанные выше (то есть типы логических форм, отображения ПИ, управляющие элементы, поведения и т.д.) в объединении. Как показано на Фиг.8, система или способ 900 осуществлены с использованием структуры 905 бизнес-приложения, которая может включать в себя бизнес-приложения и вычислительные системы, базовый клиентский процессор отображений или компонент 910 и один или несколько целевых объектов 915 экрана.

С иллюстративными целями Фиг.8 разбита на сегменты, чтобы показать отображения 920 (включая отображения 921 и 922), модели 925 (включая модель приложения или бизнес-модель 926, модель 927 логической формы и физическую модель 928) и библиотеки 930.

Библиотеки 930 в структуре 905 бизнес-приложения включают в себя библиотеку 931 типов свойств, которая определяет различные типы 923 свойств для элементов данных в модели приложения 926. В базовом клиенте 910 библиотеки 930 включают в себя библиотеку 932 логических управляющих элементов, библиотеку поведений 933 и библиотеку 934 типов логических форм. Как описано выше, библиотека 932 логических управляющих элементов задает различные логические управляющие элементы 924, на которые могут быть отображены элементы данных или типы 923 свойств модели 926. Это отображение между моделью 926 приложения и моделью 927 логической формы выполняет базовый клиентский процессор отображений, используя отображение 921.

Библиотеку поведений 933 и библиотеку 934 типов логических форм использует базовый клиентский процессор 910 отображений в ходе операций проектирования и создания форм, как было описано предварительно. Библиотеки 930 также включают в себя библиотеку 935 стилей, библиотеку 936 физических или внутренних управляющих элементов и библиотеку 937 типов форм, которые использует целевой объект 900 экрана, чтобы создать модель 928 физической, формы и, таким образом, чтобы визуализировать физическую форму. Библиотека 936 управляющих элементов определяет различные физические управляющие элементы 925 для конкретного целевого объекта экрана, на который логические управляющие элементы 924 могут быть отображены, используя отображение 922.

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

Изобретение относится к созданию документальных интерфейсов. Способ включает в себя выбор, какой тип из многих различных логических типов форм надлежит использовать, чтобы создать формообразный пользовательский интерфейс для представления модели приложения. Способ также включает в себя обеспечение первого отображения. Независимую от целевого объекта экрана логическую форму создают с использованием модели приложения, выбранного типа формы и первого отображения. Раскрыт также считываемый носитель, на котором записана программа для осуществления способа. Технический результат - повышение качества и удобства проведения поисков и снижение временных трудозатрат. 2 н. и 20 з.п. ф-лы, 13 ил.

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

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

3. Способ по п.2, в котором при создании независимой от целевого объекта экрана логической формы создают независимую от целевого объекта экрана модель логической формы.

4. Способ по п.2, в котором при создании независимой от целевого объекта экрана логической формы с использованием модели приложения, заранее выбранного типа формы и первого декларативного отображения также присоединяют декларативно применяемые поведения к независимой от целевого объекта экрана логической форме.

5. Способ по п.4, в котором декларативно применяемые поведения активируют посредством событий в упомянутой форме.

6. Способ по п.5, в котором декларативно применяемые поведения являются моделями логики, которые в зависимости от значений и свойств логических управляющих элементов устанавливают свойства на других управляющих элементах.

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

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

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

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

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

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

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

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

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

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

17. Считываемый компьютером носитель по п.16, в котором при создании независимой от целевого объекта экрана логической формы с использованием модели приложения, заранее выбранного типа формы и первого декларативного отображения также присоединяют декларативно применяемые поведения к независимой от целевого объекта экрана логической форме.

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

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

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

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

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