Глава 20. Экранные формы, отчеты и пакетные программы

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

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

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

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

В наши дни практически каждый пользователь БД знаком и с другими продуктами. У большинства людей на столах стоят ПК, и они наверняка пользуются текстовыми процессорами или электронными таблицами. Если их спросить, каким должен быть интерфейсе, то вполне естественно, что они сошлются на знакомые приложения. Вам следует сделать точно так же. Проектируя, старайтесь обеспечить максимальное соответствие стандартам, принятым в рабочей среде пользователя (например, в приложениях Microsoft Windows для вызова справочной системы служит клавиша F1). Следует также добиваться согласованности с другими приложениями, привычными для пользователей.

Однако при этом легко попасть в зависимость от этого требования и в результате получить программу, напоминающую нечто такое, чем она на самом деле не является. Электронные таблицы и текстовые процессоры хороши для выполнения многих задач, однако в качестве внешних систем баз данных они непригодны, особенно если базу данных нужно обновлять. Не пытайтесь сделать так, чтобы экранная форма ввода данных выглядела и работала, как окно Lotus 1-2-3 или Microsoft Excel. На ознакомление пользователей с новым форматом или стилем требуется совсем немного времени. Можно потратить несколько недель на создание перемещаемой панели кнопок, когда достаточно просто приучить пользователя к тому, что эта панель будет постоянно находиться в верхней части экрана. Кроме того, хотя графические пользовательские интерфейсы (ГПИ), скорее всего, будут присутствовать в приложении, полная реализация их возможностей может и не быть лучшим вариантом для всех пользователей.

Полезно разбить всех пользователей на группы. Вот один из вариантов такого разбиения:

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

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

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

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

Вот общие принципы проектирования экранных форм:

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

Для отчетов существует широкий набор требований. Среди них часто встречаются не только новые, но и "старомодные" требования. Вот основные типы отчетов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В PL/SQL диагностику можно включить с помощью переменной пакета:

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

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

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

В следующих разделах приводится довольно краткое описание приемов пакетной обработки. Такая краткость в основном обусловлена нашим убеждением, что многие вопросы, связанные с успешным управлением пакетной обработкой, не имеют ничего общего с используемым ПО управления данными. Мы отвергаем идею о том, что такие проблемы, как управление заданиями, лучше всего решаются из СУБД, несмотря на все возможные преимущества переносимости. К сожалению, платформы открытых систем не поставляются с системами управления заданиями по типу мэйнфреймовских, и поддержка в этой области на промышленном уровне будет критическим фактором успеха для многих приложений. Но эта тема выходит за рамки книги по проектированию баз данных Oracle.

Несмотря на большое число усовершенствований, сделанных в версиях 7.2 и 7.3, мы не рекомендуем использовать PL/SQL как средство реализации высокопроизводительной пакетной обработки. Как вы видите из приведенных в книге примеров, мы — сторонники использования PL/SQL в качестве языка для хранимых процедур и триггеров, но у него есть ряд ограничений, делающих этот язык слишком дорогим для использования при обработки больших объемов данных. Эти недостатки таковы:

Рекомендуем писать выполняющиеся на сервере программы пакетной обработки на 3GL и осуществлять обмен данными с СУБД при помощи массивного интерфейса Oracle. Кроме того, рекомендуем ограничить операции с базой данных только теми, которые либо должны выполняться внутри нее, либо не должны экспортироваться. Так, если требуется прибавить единицу к какому-то значению в базе данных, но нет необходимости видеть это значение в управляющем коде, следует использовать простое относительное обновление, например:

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

Для не критичных по времени заданий PL/SQL все же дает определенные преимущества, а именно:

Еще одна важная рекомендация, которую мы обязаны дать относительно проектирования пакетных заданий, — максимально использовать обработку при смене объекта операции (control break processing), сочетая ее с "мягким" отключением триггеров в ходе выполнения процесса.

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

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

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

Если задание выполняет фиксацию один раз, например, через четыре часа обработки, то можно потерять 3 часа 59 минут сделанной работы в случае отказа носителя или аварии экземпляра. Кроме того, в процессе проектирования часто не учитывают и другие факторы — размер сегмента отката, который потребуется для поддержки модели с единичной фиксацией, и время, необходимое для запуска с восстановлением после аварии экземпляра. Если к моменту аварии задания программа использует 10 Гбайт сегмента отката, то при перезапуске Oracle придется обработать 10 Гбайт элементов сегмента отката. Это может существенно увеличить время простоя.

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

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

Несомненно, это самый быстрый способ перемещения строк из одной таблицы в другую. В самой последней версии предложение CREATE TABLE...AS SELECT... можно снабдить атрибутом UNRECOVERABLE, предполагая, что проблемы с использованием сегмента отката и временем восстановления экземпляра преодолены. Однако все равно существует риск того, что авария экземпляра, операционной системы или аппаратных средств может привести к потере большого объема работы и, конечно, эта операция невосстановима, если требуется восстановление с повтором транзакций. Поэтому вы, возможно, решите не использовать опцию UNRECOVERABLE в заданиях промышленного уровня, а примените ее для основных служебных операций, за которыми сразу же следует резервное копирование. В приведенном ниже предложении продемонстрирован второй самый быстрый способ перемещения строк:

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

Это один из тех немногих случаев, когда мы можем рекомендовать реализацию основного пакетного процесса на PL/SQL, поскольку почти все время выполнения будет затрачено на работу интерпретатора SQL и требования к процедурному языку минимальны (и потому, что PL/SQL очень облегчает реализацию курсорных циклов FOR).

Продемонстрированный нами подход связан с некоторым увеличением затрат на создание задания, и для его реализации необходимо использовать PL/SQL или 3GL, а не просто создать скрипт на SQL*Plus. Однако он позволит сэкономить большой объем пространства сегмента отката и обеспечит быстрое восстановление.

Вообще говоря, нас не впечатляют организации, где пакетная обработка реализована средствами SQL*Plus.

Если этот пример преобразовать в хранимую процедуру (что мы рекомендуем делать), то в этом сеансе должен быть включен режим COMMIT IN PROCEDURE. Собственные средства Oracle, главным образом Oracle Forms, тяготеют к выдаче команды ALTER SESSION, отключающей этот режим. Они делают это для того, чтобы можно было рассчитывать на то, что установленные ими блокировки все еще действуют. Если режим COMMIT IN PROCEDURE включен, то любая хранимая процедура или функция, вызываемая процессом, может выдать команду COMMIT или ROLLBACK, что приведет к снятию всех транзакционных блокировок, установленных сеансом.

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

В данном случае гораздо проще и эффективнее поместить условие (подразделение активно) в предложение WHERE.

Большинство из нас, конечно, сталкивались с "радостными" сообщениями вроде Unexpected condition has occurred ("Возникла непредвиденная ситуация") или даже 04FD63-unknown reference ("Неизвестная ссылка"). Мы ломали голову над тем, что они означают, и расстраивались, так как не знали, что именно сделали не так — если мы вообще делали что-нибудь не так. Тем не менее, мы считали ошибки такого типа неизбежным злом и обычно повторяли свои попытки. Однако сегодня пользователи требуют сообщений, по которым можно идентифицировать ошибки и на которые можно реагировать. К тому же, если два программиста будут обрабатывать одну и ту же исключительную ситуацию, не имея схемы, указывающей, как обрабатывать эту ситуацию, то вряд ли они сделают это одинаково и наверняка предложат разные тексты сообщения об ошибке. Отсюда и необходимость в общем и согласованном подходе.

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

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

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

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

или, что еще хуже:

Если вы потратили десять минут на ввод данных и получили второе сообщение, то что вы сделаете? Вы станете нажимать кнопку Retry снова и снова в надежде, что программа все-таки заработает и вам удастся избежать потери сделанной работы. К сожалению, если программа перед выдачей этих сообщений пользователю сняла ряд важных блокировок, результатом может быть полное блокирование приложения.

Второй, еще более забавный, просчет заключается в регистрации действий приложения в базе данных для содействия устранению фатальной ошибки. Очевидно, что когда программа производит откат транзакции, то она выполняет откат и для всех элементов журнала регистрации. Решения просты: выполнить фиксацию вместо отката транзакции (разве можно без шуток?) или выполнять регистрацию в файлах, а не в базе данных. В версии 7.3 реализовать файловое решение несколько проще, чем в предыдущих, так как из PL/SQL теперь можно выполнять запись в файлы на сервере. Хотя безопасность при этом оставляет желать лучшего, поскольку эти файлы могут содержать в диагностической информации важные данные, на которые может случайно натолкнуться пользователь. В более ранних версиях регистрацию в файлы можно выполнять, посылая сообщения посредством DBMS_PIPE в выделенный серверный процесс, если обработка ошибок производится в основном через хранимые процедуры. Не поддавайтесь искушению использовать DBMS_ALERT, поскольку соответствующие механизмы имеют транзакционный характер, т.е. подвержены фиксации и откату.

Некоторые думают, что решение с фиксацией приемлемо в тестовых системах, но мы считаем его неоправданным в любых обстоятельствах. Если вы не завершили транзакцию (например, выполнили только три из пяти операций вставки, а потом получили сообщение Duplicate value in index), то фиксация незавершенной транзакции и нарушение целостности базы данных — непрофессиональное решение.

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

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

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

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

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

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

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

При проектировании оперативной справочной системы приложения необходимо учитывать следующее:

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

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

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

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

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

• Справочная система должна быть знакома пользователям. Если бы мы писали эту главу два-три года назад, то почти наверняка включили бы в нее советы по проектированию таблиц справочного текста, но мир изменился и мы уже не считаем, что справочные системы нужно реализовывать на уровне проекта. Они должны быть похожи на справочные системы, с которыми пользователь работает в других приложениях. Самый лучший путь — использовать "родное" для клиентской платформы справочное средство, даже несмотря на то, что при этом приходится распространять справочные файлы минимум до уровня файлового сервера в пределах предприятия. Например, на клиентах с Microsoft Windows следует использовать Microsoft Help. Если вы используете стандартную справочную систему, то сможете работать с мощными и простыми в эксплуатации средствами создания справок, которые помогут вам разработать справочные файлы профессионального уровня.

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

• В Oracle Designer/2000 версии 1.2А и выше есть генератор, который создает справки в формате Microsoft Help на базе описаний таблиц и модулей. Но если эти описания не составлены так, чтобы они были понятны для пользователей, то такая система, конечно, будет классическим образцом системы КЗТО ("каков запрос, таков ответ"). В большинстве проектов много сил тратится на то, чтобы описания были понятыми для программистов!

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

НОВОСТИ ФОРУМА Рыцари теории эфира

10.11.2021 - 12:37: ПЕРСОНАЛИИ - Personalias -> WHO IS WHO - КТО ЕСТЬ КТО - Карим_Хайдаров. 10.11.2021 - 12:36: СОВЕСТЬ - Conscience -> РАСЧЕЛОВЕЧИВАНИЕ ЧЕЛОВЕКА. КОМУ ЭТО НАДО? - Карим_Хайдаров. 10.11.2021 - 12:36: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от д.м.н. Александра Алексеевича Редько - Карим_Хайдаров. 10.11.2021 - 12:35: ЭКОЛОГИЯ - Ecology -> Биологическая безопасность населения - Карим_Хайдаров. 10.11.2021 - 12:34: ВОЙНА, ПОЛИТИКА И НАУКА - War, Politics and Science -> Проблема государственного терроризма - Карим_Хайдаров. 10.11.2021 - 12:34: ВОЙНА, ПОЛИТИКА И НАУКА - War, Politics and Science -> ПРАВОСУДИЯ.НЕТ - Карим_Хайдаров. 10.11.2021 - 12:34: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Вадима Глогера, США - Карим_Хайдаров. 10.11.2021 - 09:18: НОВЫЕ ТЕХНОЛОГИИ - New Technologies -> Волновая генетика Петра Гаряева, 5G-контроль и управление - Карим_Хайдаров. 10.11.2021 - 09:18: ЭКОЛОГИЯ - Ecology -> ЭКОЛОГИЯ ДЛЯ ВСЕХ - Карим_Хайдаров. 10.11.2021 - 09:16: ЭКОЛОГИЯ - Ecology -> ПРОБЛЕМЫ МЕДИЦИНЫ - Карим_Хайдаров. 10.11.2021 - 09:15: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Екатерины Коваленко - Карим_Хайдаров. 10.11.2021 - 09:13: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Вильгельма Варкентина - Карим_Хайдаров.