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

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

Для удовлетворения этим требованиям диалоговая программа по обслуживанию туристического агентства должна иметь графический пользовательский интерфейс (Graphical User Interface, GUI) и содержать правила проверки корректности вводимых данных, а также контроля их непротиворечивости. Кроме того, данные о заказах билетов должны сохраняться в базе и быть доступными в будущем. Наконец, любой служащий агентства должен иметь возможность легко исправить неправильно введенные данные.

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

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

Размещение экранов моделируется по принципу WYSIWYG (сокращение от английского предложения "What You See Is What You Get" — "Что видишь, то и получаешь"). Размещаемыми элементами могут быть поля ввода, метки поля (надписи), экранные кнопки, фреймы, переключатели, управляющие элементы таблиц и т.д. Их можно выбирать из Dictionary или помечать на инструментальной линейке и размещать на экране с помощью мыши.

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

Сообщения рассматриваются в главе 20.

Под статусом GUI принято понимать те элементы, которые появляются в меню и на инструментальных линейках. Их можно строить динамически в управляющих программах АВАР/4 с помощью команды set pf-status. Заголовок GUI описывает заголовок экрана и может быть задан в программе с помощью команды set titlebar. Текст статуса GUI и заголовки могут выводиться на экран на естественном языке страны пользователя без изменения исходного текста программы. Если для статуса GUI используется статус, предлагаемый в Workbench по умолчанию, то программа будет иметь стандартно организованный пользовательский интерфейс.

В этой главе рассматривается, как строить статусы GUI для диалоговых программ изменения данных. Статусы GUI для отчетных списков описаны в главе 17.

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

Описание учебной задачи

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

•Запрос данных по авиарейсу

•Диалог для ввода необходимых данных клиента

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

Рис. 19.1

Интерфейс запроса данных об авиарейсе

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

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

Рис. 19.2

Диалоговое окно для ввода информации о конечном пункте авиарейса

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

Рис. 19.3

Экран ввода данных клиента для заказа билетов на авиарейс

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

Создание диалоговой программы

Теперь известно, как будет выглядеть программа, и можно приступить к се разработке. Для этого следует использовать Object Browser (см. главу 3). Сначала нужно задать имя программы (например, SAPMSABB) и выбрать для нее тип М (т.е. создается Module Pool — диалоговая программа, изменяющая данные в базе). В отличие от отчета, Module Pool нельзя инициировать командой submit или выбором экранной кнопки Test/Execute на экране Objecl Browser, так как в Object Browser не предусмотрен стартовый экран по умолчанию. Module Pool разрешается инициировать либо с помощью функции меню, связывающей его с транзакцией, либо используя специальную языковую конструкцию.

Транзакцией в R/3 называется диалоговая программа, изменяющая объекты базы данных непротиворечивым образом (см. главу 21).

В приведенном ранее примере транзакция создавалась с помощью начального (см. рис.19.1) и последующих экранов (см. рис. 19.2, 19.3). Кроме того, транзакцию разрешается определять на экране Object Browser. Для этого следует выбрать в переключателе опцию Other Objects (другие объекты) и щелкнуть мышью на кнопке Edit в нижней части экрана. На следующем экране нужно задать имя транзакции (например, SAAB) и щелкнуть на кнопке Create (создать). В открывшемся диалоговом окне необходимо определить тип транзакции как Dialog Transaction (диалоговая транзакция), а в следующем диалоговом окне ввести краткий поясняющий текст, задать имя программы и начальный экран диалога (в примере использованы имя программы SAPMSAAB и экран 100).

Выполнение транзакции начинается с отображения начального экрана, а при ее завершении управление передается в вызывающую программу. Протестировать выполнение транзакции можно с помощью кнопки Test/Execute (проверка/ выполнение) экрана Object Browser.