ИНСТРУМЕНТ РАЗРАБОТКИ ПРОГРАММНЫХ ПРИЛОЖЕНИЙ Российский патент 2018 года по МПК G06F9/44 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

Сущность изобретения

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

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

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

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

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

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

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

Эти страницы предпочтительно задаются декларативно и более предпочтительно с использованием языка XML, такого как XAML.

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

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

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

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

Этот результат достигается, в том числе, за счет того, что в составе инструмента разработки содержится GUI для моделирования рабочего процесса приложения, причем рабочий процесс включает в себя экраны (которые отображаются для пользователя) и сервисы, описанные декларативно посредством декларативного языка описания данных. Организация, координация и управление (т.е. оркестрация) сервисов в рабочем процессе обычно осуществляется с промежуточного (mid-level) логического уровня и используется для предоставления бизнес-функциональности. Оркестрация экранов соответствует пользовательскому восприятию экранов/страниц и, в соответствии с предшествующим уровнем техники, оркестрация экранов обрабатывается отдельно от оркестрации сервисов. Настоящим изобретением обеспечивается функциональная возможность оркестрации как экранов, так и сервисов, что вносит свой вклад в вышеупомянутое снижение временных и операционных затрат. Данный вклад делается, в частности, за счет того, что разработчик получает возможность единообразно работать с экранами и сервисами при сборке приложения, путем перетаскивания их в его рабочий процесс с использованием упомянутого GUI; помимо этого, устраняются накладные расходы, связанные с раздельной работой с оркестрацией сервисов и оркестрацией экранов (по меньшей мере, по причине того, что как оркестрация сервисов, так и оркестрация экранов происходят на промежуточном логическом уровне, что упрощает требующееся программирование). Кроме того, когда поведение системы меняется, один и тот же конфигурационный инструмент может быть использован для изменения поведения сервисов и экранов из единого центрального пункта.

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

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

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

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

Фиг. 2 показывает пример графического пользовательского интерфейса для проектировщика рабочего процесса;

Фиг. 3 показывает различные виды действий, связанных со страницами и ссылками на другие виды действий и страницы; и

Фиг. 4 показывает, как к значениям данных можно осуществить доступ посредством страницы бизнес сервиса.

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

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

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

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

Ссылаясь на Фиг. 1, показано схематическое представление клиента киоска. Функциональные возможности показаны как некоторое количество слоев, некоторые из которых находятся в самообслуживании или в канале киоска, и некоторые из которых находятся на среднем (промежуточном) уровне (mid-level). Следует понимать, что это только примеры и что некоторое программное обеспечение, которое находится на среднем уровне, например, описываемый XOML-уровень может находиться в канале самообслуживания и, наоборот. Клиент киоска - это тот, который обрабатывает регистрацию с самообслуживанием в аэропорту. Следует понимать, что это описание является только иллюстративным и что другие клиенты, обеспечивающие регистрацию, такие как онлайн Web-клиенты или клиенты мобильной связи, будут иметь другие сервисы платформы, другой или отсутствующий уровень доступа к устройствам и другой уровень XAML Silverlight.

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

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

На Фиг. 1 киоск включает в себя стандартную Windows (RTM) или другую операционную систему 100 и стандартный уровень 110 доступа к устройствам. Абстракция уровня платформы обрабатывается на уровне 120, обозначенном «сервисы платформы SITA». Абстракция включает в себя абстракцию монитора и диспетчер приложений соответствующего стандарта. Уровень сервисов платформы обеспечивает доступ к устройствам в простой и интуитивной форме через элементы управления Silverlight (RTM), которые могут быть перетащены на страницу Silverlight. Уровень Silverlight представлен на Фиг. 1 посредством уровня 130. Silverlight является подключаемым модулем (плагином) браузера, предоставляемым Microsoft Corporation, который обеспечивает проектирование и разработку Web-приложений и является кросс-платформным и переносимым между устройствами. Silverlight использует XAML (расширяемый язык разметки приложений). Это обеспечивает очень простой и интуитивный инструмент для разработчика приложения.

Страницы Silverlight активируются в результате сообщения из рабочего процесса. Страницы Silverlight содержат две части: код, посредством которого будет сообщение с рабочим процессом и который может включать в себя рабочий поток, который может сообщаться с устройством с ресурсами данных, Web-сервисами и который может выполнять некоторую обработку; и экран. Экран предпочтительно написан на XAML, но могут поддерживаться и другие декларативные языки, такие как HTML. Подходящим инструментом для экрана является Expression Blend, предоставляемый Microsoft Corporation и предназначенный для использования с платформой Silverlight.

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

Инструмент создает файлы XOML (показанные на уровне 150), которые подаются в подсистему рабочего процесса или компилируются в d11-библиотеки (динамически подключаемые библиотеки). Подсистема рабочего процесса и рабочие процессы размещаются на хосте рабочих процессов, который находится на среднем уровне. Это не является существенным, и хост рабочих процессов может находится на клиенте. Действия в рабочем процессе сообщаются с бизнес сервисами 160, которые находятся на среднем уровне, через SOAP (Простой протокол доступа к объектам), который является базовым протоколом XML, разработанным, чтобы обеспечить возможность Web приложениям обмениваться информацией.

Сервисы 170 данных также образуют часть среднего уровня и находятся на нем. В случае киоска самообслуживания есть только обмен данными от пользователя к клиенту, и клиент может только прочитать данные; он не может их обновить. Клиент может сообщаться с сервисами данных через сообщения REST (Состояния Представления Передачи), хотя могут использоваться другие протоколы связи, такие как Xpath или подобные технологии. Это упрощает программирование, поскольку приложение просто запрашивает часть нужных данных. Сообщения являются легковесными, и средний уровень является очень слабосвязанными с клиентом. Сервис данных, а также обеспечение обычных данных авиакомпании могут соединяться с внешними Web-сервисами для представления других данных, таких как данные, связанные с путешествиями, включая отчеты о погоде.

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

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

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

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

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

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

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

Доступа к системам управления вылетом;

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

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

Конфигурации рабочего процесса - данные конфигурации рабочего процесса, которые задают свойства рабочего процесса и передаются в рабочий процесс в качестве аргументов, когда рабочий процесс запускается;

Данных приложения SL (Silverlight) - эти данные передаются в приложение SL, когда запускается рабочий процесс транзакции.

Один пример этих схем:

Пример данных рабочего процесса:

Спецификация экрана

Пример данных сеанса рабочего процесса:

Текущий полет

Пример данных конфигурации: Предлагаемые сервисы

Пример данных приложения SL: Тема

Таким образом, все данные в системе задаются посредством схемы, и когда к данным осуществляется доступ со стороны объектов, эти объекты должны генерироваться с использованием автоматизированного инструмента (xsd.exe). Модель данных не создается для системы, а скорее составляется из входных данных в систему или от конечного пользователя, или от Web-сервисов. Таким образом, модель данных приложения является суммой всех входных данных в приложение. Поэтому, модель данных автоматически расширяется, когда есть новые входные данные в систему.

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

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

Экраны могут предпочтительно быть разработаны в XAML или HTML, хотя может использоваться любой другой язык представления. Код, обеспечивающий экран, является универсальным кодом, который реагирует на события пользовательского интерфейса (UI) от экранов и выполняет отправку в рабочий процесс. События UI могут быть от устройства, причем все экраны могут просматриваться и редактироваться в Expression Blend.

Каждый экран имеет спецификацию XML. Эта спецификация используется проектировщиком для представления и проверки достоверности.

Элементами схемы являются:

Имя экрана (1)

Обязательные свойства - "key=value" (0-*)(«ключ=значение»)

Необязательные свойства - "key=value" (0-*)

Диапазон возвращаемых значений (1-*)

Возвращаемые данные - "key=value" (0-*)

Предусловия (0-*)

Постусловия () - *)

Описание поведения.

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

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

Схема XML используется для всех данных и сообщений, обеспечивая возможность расширения модели данных и/или сообщений пользователем посредством обновления схемы обратно совместимым образом.

Интерфейсы высокого уровня предусмотрены для устройств, к которым осуществляется доступ через элементы пользовательского интерфейса. Устройства могут быть перетащены на страницы, и свойства заданы на них. Страницы являются представлениями экрана GUI и разрабатываются с использованием инструмента экрана GUI. Они могут быть заданы декларативно на языке XML, таком как XAML.

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

Бизнес-правила являются также декларативными и включаются в рабочий процесс через инструмент GUI.

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

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

Изобретение также более широко применимо, например, в финансовой индустрии в ситуациях, когда большое количество устаревших систем развивалось за последние годы. Один пример - «Автоматические кассиры» (ATM), которыми теперь обеспечены многие различные банки, у каждого из которых есть их собственная база кодов.

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

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

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

Фиг. 2 показывает пользовательский интерфейс проектировщика рабочего процесса, используемого для разработки приложения для конкретной инстилляции. Проектировщик включает в себя представление в виде объектов GUI, рабочих процессов и действий, но не фактические объекты действий. Проектировщик программно создает рабочий процесс и преобразовывает его в файл XOML, который является декларативным файлом рабочего процесса XML. Таким образом, на Фиг. 2, объект 200 Идентификация (Identify) связан с объектом Выбор Полета 210 (Select Flight). Этот объект, в свою очередь, связан объектами Выбор места 220 (Select seat), Выбор багажа 230 (Select bags) и Регистрация 240 (Check in). На правой стороне экрана показаны Экраны (Screens), Бизнес Сервисы (Business Services), Действия (Activities) и Сценарии (Scenarios), которые доступны. Когда пользователь нажимает (кликает) на одно из них, для пользователя отображается спецификация, как описано их схемой, и помощь. Пользователь может перетаскивать Экраны или Бизнес Сервисы на страницу и действия и Сценарии в рабочий процесс. Пользователю не требуется создавать какой-либо код на этих этапах.

Рабочий процесс содержит Сценарии, Страницы и Действия. Как видно на Фиг. 3, страница является составным действием. Фиг. 3 - объектная модель UML, показывающая отношение между действиями. Страницы соединяются коннекторами 310, которые состоят из ссылки и страницы назначения. Таким образом, на данной фигуре три панели 300 страницы связаны с действиями от А до G. Страница содержит навигационную панель 320 (действие G), которая содержит ссылки. Ссылки (действие Е) имеют свойство состояния, которое оценивается, и, если оно является истинным, ход выполнения продолжается к странице назначения коннектора. Ссылки оцениваются слева направо через Навигационную панель. Страницы, которые сообщаются с клиентом, реализуются с использованием Действия 330 Вызова Внешнего Метода (Действие С). Действие 340 Обработчика События (действие D) принимает событие от клиентского приложения. Когда событие принято, оцениваются состояния ссылки. Эти страницы являются клиентскими страницами.

Страницы, которые сообщаются с сервисами, реализованы с использованием Действия Вызов Web-Сервиса. Когда Web-Сервис возвращает результат, состояние ссылки будет оценено. Эти страницы являются Страницами Сервисов. Специализированное Действие Итератора выполняет итерацию по списку, и Действие Задания Значения задает значение данных Сеанса.

На странице клиента проектировщик имеет опцию меню «Добавить Экран» («Add Screen»), которая проводит пользователя к файлу XAML для экрана. Проектировщик ведет пользователя через необходимые этапы для добавления требуемой дополнительной информации, такой как Предусловия (Pre Conditions), Постусловия (Post Conditions) и Путь к Возвращаемым Данным (Return Data Path). Затем проектировщик формирует соответствующий документ XML, используя Схему Экрана (Screen Schema). Страница Клиента отсылает сообщение в клиентское приложение, как определено Схемой Сообщения (Message Schema). Сообщение содержит название экрана для отображения и любые свойства для задания на этом экране. Страница клиента принимает событие от клиента, содержащее результат и любые возвращенные данные.

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

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

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

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

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

К элементам данных сеанса можно осуществлять доступ посредством использования Xpath выражений. Xpath используется для направления (навигации) через элементы и атрибуты в документе XML. Специализированное Значение Набора Действий может использоваться для установления значений в пределах данных Сеанса.

Свойство Страницы (Page Property) устанавливается в xpath для отправки значений данных сеанса клиенту или бизнес сервису. Примером является отправка выбранного посадочного места в бизнес сервис Изменения Посадочного Места (Change Seat). Интерфейс Изменения Посадочного Места является результатом Изменения Посадочного Места (строка пассажир, строка номер рейса, строка номер посадочного места) (Change Seat (string passenger, string flight Number, string seat Number)). Свойства могут быть установлены следующим образом:

"пассажир"="Данные сеанса/Текущий Выбор/Текущий Пассажир" («passanger»=«Session Data/Current Selection/Current Passenger»);

"номер рейса"="Данные сеанса/Текущий Выбор/Выбранное Посадочное Место" («flight Number»=«Session Data/Current Selection/Selected Seat»);

"номер посадочного места"="Данные сеанса/Текущий Выбор/Выбранное Посадочное Место" («Seat Number»=«Session Data/Current Selection/Selected Seat»).

Данные сеанса могут быть обновлены, если рабочий процесс принимает данные от клиента или бизнеса. Например, страница представления под названием Выбор Посадочного Места (Select Selection) связана по ссылке с экраном Выбор Посадочного Места (Select Seat) на клиенте, и экран Выбор Посадочного Места возвращает "Посадочное Место = 4G". Проектировщик обеспечил свойство "Посадочное Место" исходя из считывания xml для экрана Выбор Посадочного Места и обновляет это свойство значением "4G". Для всех возвращаемых значений имеется опция использования специального редактора, который позволяет разработчику управлять схемой сеанса и соединять элемент схемы Выбора Посадочного Места со свойством Посадочное Место Действия Выбора Посадочного Места. Таким образом, данные сеанса обновляются, когда свойство Посадочное Место устанавливается в "4G".

Ссылаясь теперь на Фиг. 4, будет объяснена организация доступа к значениям данных. Страница 400 Сервисов имеет Свойство (Property). Это Свойство 410 автоматически добавляется к Странице Проектировщиком (Designer), когда Бизнес Сервис перетаскивается на страницу. Свойство соответствует параметру в вызове сервиса. Чтобы содействовать быстрой разработке, имя Свойства соответствует элементу Данных Сеанса, и Проектировщик автоматически устанавливает значение Свойства равным пути в схеме данных. Это поведение по умолчанию может быть переопределено Проектировщиком посредством ввода строкового значения для Свойства и использования GUI 420 Редактора Свойств для навигации к соответствующему месту в Данных 450 Сеанса. Редактор 430 Свойств использует навигатор 440 схемы для навигации по Данным 450 Сеанса. Также возможно осуществить выбор из списка, используя GUI 460 Критериев Выбора. Этот GUI позволяет Разработчику осуществлять навигацию по другим свойствам в рабочем процессе.

Когда Экран или Бизнес Сервис перетащен на страницу, проектировщик автоматически вставит свойства Возвращаемые Данные согласно схеме. Для сервисов возвращаемые данные представляют собой строку, но схема, которую использует проектировщик, расширяет WSDL для задания соответствия возвращаемых данных пути в Данных Сеанса.

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

Проектировщик выполняет проверку на предмет ошибок из Web-сервиса и устанавливает Статус (Status) соответственно. В случае ошибки данные сеанса не обновляются. Значения в пределах Данных Сеанса могут также обновляться разработчиком с использованием Действия Задания значения. Это Действие позволяет разработчику переопределять какое-либо значение в пределах Данных Сеанса альтернативным значением.

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

Значения свойств зависимостей рабочего процесса могут быть отредактированы инструментом конфигурации. Инструмент создает объект словаря (путь = значение), который будет передан в качестве аргумента во время выполнения рабочего процесса, когда рабочий процесс выполняется. Это динамически установит свойства рабочего процесса. Рабочие процессы разрабатываются со свойствами по умолчанию, которые могут быть обновлены во время выполнения объектом конфигурации словаря.

Чтобы создать эти файлы Конфигурации, разработчик редактирует свойства рабочего процесса. Это делается посредством выбора пункта меню, «Новая … Конфигурация» («New … Configuration»); и ассоциирования Конфигурации с рабочим процессом. Инструмент Конфигурации открывает окно проектировщика, содержащее рабочий процесс, и проектировщик ограничивает обновления только обновлениями свойств зависимостей. Затем разработчик редактирует свойства рабочего процесса для создания новой Конфигурации. Разработчик может использовать инструмент навигатора схемы, чтобы устанавливать значения в свойства Данных Сеанса и может редактировать свойство условия (правила). Инструмент конфигурации создает пары путь=значение для объекта конфигурации словаря Рабочий процесс. Сценарий. Свойство. Атрибут=строка (Wolkslow. Scenario. Property. Attribute=string).

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

Этими способами инструмент может объединять Web-сервисы, экраны и расширять модель данных, изменять или добавлять бизнес правила, без написания кода.

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

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

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

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

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

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

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

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

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

4. Инструментальное средство разработки программных приложений по п. 3, в котором страницы задаются на языке XML.

5. Инструментальное средство разработки программного приложения по п. 1, в котором графический инструмент обеспечивает доступ к системам и сервисам авиакомпаний.

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

7. Инструментальное средство разработки программных приложений по п. 1, в котором библиотека системных компонентов содержит комплексные, универсальные и индивидуализируемые компоненты.

8. Инструментальное средство разработки программных приложений по п. 1, в котором по меньшей мере одно из данных и сообщений, и экранов, и сервисов, используемых приложением, описаны с использованием схем XML.

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

10. Инструментальное средство разработки программных приложений по п. 7, в котором универсальные компоненты содержат повторно используемые компоненты для домена, при этом по меньшей мере один универсальный компонент параметризован, чтобы увеличить возможность многократного использования.

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

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

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

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

15. Инструментальное средство разработки программных приложений по п. 1, при этом приложение является клиентом регистрации.

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

17. Инструментальное средство разработки программных приложений по п. 16, при этом клиент регистрации с самообслуживанием является основывающимся на Web-приложении.

18. Инструментальное средство разработки программных приложений по п. 17, при этом терминал регистрации является киоском регистрации с самообслуживанием.

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

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

21. Инструментальное средство разработки программных приложений по п. 1, при этом приложение является клиентом покупки билетов.