Создание автоматизированной системы создания и ведения адресных справочников и справочников объектов теплоснабжения

Важнейшим элементом экологии в программном обеспечении является эргономичность интерфейса.

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

К основным принципам проектирования качественных интерфейсов можно отнести:

Естественность - взаимодействие с интерфейсом не должно вызывать у пользователя осложнения

Непротиворечивость - взаимодействие должно соответствовать привычным для работы нормам

Неизбыточность - пользователь должен вводить минимальную необходимую информацию

Легкий доступ к системе помощи - справки и документация должна быть понятно интегрирована в интерфейс

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

7.2 Разработка эргономичного интерфейса

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

Зрительное напряжение можно снизить с помощью правильной работы со шрифтами, которые используются в графическом интерфейсе пользователя. Мелкие и нечитабельные шрифты вызовут трудности в восприятии информации пользователем. Изучение всех надписей в процессе поиска необходимой пользователю функции отнимает большое количество рабочего времени, а также вынуждает сильно напрягать зрение. Ввиду этого, очень важно подбирать удобно читаемые шрифты и выбирать максимально допустимый интерфейсом размер шрифта. Не рекомендуется набирать надписи исключительно заглавными буквами, так как восприятие информации, набранной таким способом, значительно затрудняется («СОХРАНИТЬ В БАЗУ ДАННЫХ»). Для выделения надписи и привлечения внимания пользователя лучше воспользоваться присвоением шрифту атрибута «жирный» или изменить стандартный цвет шрифта, но таким образом, чтобы текст легко читался на собственном фоне («Сохранить в базу данных», «Сохранить в базу данных»).

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

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

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

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

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

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

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

Добавление обработки таких клавиш как: «escape», «enter», «delete» значительно увеличит производительность работы пользователя в системе. Как правило, значения этих клавиш в программном обеспечении унифицировано и воспринимается пользователем на интуитивном уровне. «Escape» - отклонить, «enter» - принять, «delete» - удалить. Если в интерфейсе предусмотрены функции, к которым пользователь будет часто обращаться, рекомендуется добавить горячую клавишу для её обработки. Опытные пользователи смогут сократить время работы с программой, а старая система выполнения функций с помощью нажатия на кнопку будет поддерживаться.

Вывод

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

8. Решение задачи на ЭВМ

8.1 Структура классов модуля

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

Программный интерфейс настройки схемы маршрутизации

Маршрутизация запросов пользователям, обработка и отклонение запроса

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

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

Рассмотрим функции основных классов модуля подробнее.

TtrsAdmin - программный интерфейс настройки схемы маршрутизации. Одной из самых важных функций класса является загрузка всех сущностей схемы маршрутизации, а также вспомогательных сущностей в собственное хранилище данных. Вся информация загружается из базы данных и работа с ними происходит локально на компьютере пользователя. Такой подход был применён для оптимизации скорости работы с данными. Поиск конкретного объекта в локальном кэше занимает меньше времени, чем запрос к базе данных, так как с базой данных одновременно может работать большое количество пользователей. Загружать MySQL-сервер дополнительными запросами каждый раз при обновлении формы не имеет смысла. Функция загрузки сущностей выполняется всего единожды - при инициализации, в дальнейшем все операции по изменению сущностей дублируются: сначала происходит попытка записи в базу данных и, в случае успеха, в кэше также происходит обновление.

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

Физических таблиц

Справочников

Типов ролей

Схем маршрутизации

Бизнес-процессов

Наборов полей

Ролей

Связей роли-пользователи

Связей роли-наборы полей

Состояний

Переходов

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

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

TtrsTicket - класс, описывающий структуру запроса. Этот класс содержит все атрибуты запроса и предоставляет функции маршрутизации и изменения запроса. Под маршрутизацией запроса подразумеваются следующие функции:

Переход запроса из одного состояния в другое в соответствии с настроенной схемой маршрутизации запроса

Проверка выполнения правила остановки в состоянии

Откат последнего совершённого перехода

Назначение запроса пользователю

Обработка запроса и запись изменений в базу данных

Отклонение запроса

Изменение запроса включает в себя следующие функции:

Создание запроса

Удаление запроса

Сохранение изменений в данных

Отмена последних изменений в данных

Добавить/удалить объект в запрос

Добавить/удалить вложение в запрос

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

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

При совершении операции перехода запроса из одного состояния в другое ядро проверяет условие выполнения правила остановки запроса в этом состоянии. Для этого происходит создание объекта класса TtrsStateStopRule по экземпляру текста правила, который хранится в базе данных как атрибут состояния. Ядро заполняет структуру правила остановки значениями атрибутов объектов запроса. Затем интерпретатор, описанный в TtrsStateStopRule, выполняет логические операции правила и выдаёт однозначный результат необходимости остановки в данном состоянии - true или false. Далее речь пойдёт о структуре TtrsStateStopRule.

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

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

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

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

8.2 Графический интерфейс пользователя

Графический интерфейс пользователя состоит из трёх главных форм:

редактирование основных сущностей схем маршрутизации запросов

настройка схемы маршрутизации запросов

настройка бизнес-процесса

Также интерфейс содержит несколько вспомогательных форм:

регистрирование физических таблиц в системе

добавление/редактирование справочника

настройка параметров роли

настройка параметров состояния

настройка параметров переходов

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

8.2.1 Редактирование основных сущностей схем маршрутизации запросов

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

Рис. 8.1 Редактирование основных сущностей схем маршрутизации запросов

Рис. 8.2 Форма регистрации таблиц

Рис. 8.3 Редактирование справочников

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

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

8.2.2 Настройка схемы маршрутизации запросов

Рис. 8.4 Окно настройки схемы маршрутизации

Окно настройки схемы маршрутизации (рис. 8.4) состоит из двух частей: графической и текстовой. Графическая (верхняя) часть состоит из изображения схемы маршрутизации и легенды этой схемы. Как видно из рисунка (рис. 8.4), каждое состояние окрашено в определённый цвет, этот цвет определяет принадлежность состояния одной из ролей схемы. Легенда поясняет соответствие цветов ролям. Администратор системы имеет возможность произвольно настраивать изображение схемы, то есть перетаскивать состояния схемы в любое положение на полотне. Для сохранения результатов изменений необходимо нажать кнопку «сохранить схему». Переходы привязаны к состояниям, поэтому их редактирование недоступно. При создании новой схемы все автоматически созданные состояния будут расположены в одном и том же месте поверх друг друга. Администратору требуется расположить их на полотне по своему усмотрению и сохранить результат в базу данных.

Размещено на http://www.allbest.ru/

Рис. 8.5 Формы настройки атрибутов состояния(а), роли(б), перехода(в)

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

Заполнение правил остановки (рис. 8.5а), алиаса роли (рис. 8.5б), а также флагов «указание пользователя при переходе» и «комментарий обязателен» (рис. 8.5в) является необязательной процедурой.

8.2.3 Настройка бизнес-процессов

1. Atlassian JIRA Documentation https://confluence.atlassian.com/display/JIRA/ JIRA+Documentation

2. Wang R. & Strong D. Beyond Accuracy: What Data Quality Means to Data Consumers // Journal of Management Information Systems - №12 (4). - 1996. - 34 с.

3. Андреев А.М. Березкин Д.В. Кантонистов Ю.А. Объектные СУБД на российских просторах. - "Компьютерная хроника", 1997.

4. Браун Л. А. История географических карт. - 2007. - М.: Центрполиграф, 2006. - 479 с.

5. Бураков П.В., Петров В.Ю. Введение в системы баз данных: Учебное пособие - СПб.: СПбГУ ИТМО, 2010. - 129 с.

6. Гайдамакин Н. А. Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие. - М.: Гелиос АРВ, 2002. - 368 с.

7. Герасименко В.А. Основы теории управления качеством информации. Деп. в ВИНИТИ, № 5392-В 89, 1989. - 410 с.

8. Герасименко В.А. Принципы и методы индустриализации управления на базе комплексного применения вычислительной техники. Деп. в ВИНИТИ, № 5391-В 89, 1989. - 111 с.

9. Герасименко В.А., Малышев Н.И., Таирян В.И. Постановка задачи и методологические подходы к управлению качеством информации в автоматизированных системах. - В сб. Проблемы повышения качества информации. МИИТ, 1988, № 808, 62-63 с.

10. Герасименко В.А., Таирян В.И. Проблемы компелексного управления качеством информации в современных вычислительных системах и сетях. - В сб. Классификаторы и документы, 1986, вып. 1-6.

11. Гришков В.И. Исследование возможностей объектного представления данных в прикладных системах // Труды СПИИРАН. Вып.1, т.3. - СПб: СПИИРАН, 2003.

12. Документация программы LanDocs http://landocs.ru/system/

13. Долин П.А. Основы техники безопасности в электроустановках: Учебное пособие для вузов 2-ое изд., перераб. и доп. - М.: Энергоатомиздат, 1984. - 448 с.

14. Дружинин Г. В. Надежность автоматизированных производственных систем. - М.: Энергоатомиздат, 1986.

15. Журкин И. Г., Шайтура С. В. Геоинформационные системы. - М.: Кудиц-пресс, 2009. - 272 с.

16. Избачков Ю. С. Информационные технологии. Учебное пособие. - Спб: Питер, 2007. - 656 с.

17. Касьянов В. Н. Лекции по теории формальных языков, автоматов и сложности вычислений. - Новосибирск: НГУ, 1995. - 112 с.

18. Кон М. Scrum: гибкая разработка ПО. - М.: «Вильямс», 2011. - 576 с.

19. Коржов В. Многоуровневые системы клиент-сервер. - М.: Открытые системы, 1997.

20. Коровкин С. Д., Левенец И. А., Ратманова И. Д., Старых В. А., Щавелёв Л. В. Решение проблемы комплексного оперативного анализа информации хранилищ данных // СУБД. - № 5-6. - 2007. - 247 с.

21. Курлаев С. А., Цильковский И. А. Распределённые информационные системы и базы данных: учебно-методическое пособие - Новосибирск: НГТУ, 2012. - 92 с.

22. Мамиконов А.Г., Кульбы В.В., Шелков А.Б. Достоверность, защита и резервирование информации в АСУ. - М.: Энергоатомиздат, 1986. - 304 с.

23. Мельников Ю.Н. Достоверность информации в автоматизированных системах. - М.: Сов. радио, 1973. - 136 с.

24. Нефедов В.Н., Осипова В.А. Курс дискретной математики. М.: Издательство МАИ, 1992.

25. Першиков В. И., Савинков В. М. Толковый словарь по информатике / Рецензенты: канд. физ.-мат. наук А. С. Марков и д-р физ.-мат. наук И. В. Поттосин. - М.: Финансы и статистика, 1991. - 543 с.

26. Пивоваров А.Н. Методы обеспечения достоверности информации в АСУ. - М.: Радио и связь, 1982. - 144 с.

27. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. - 5-е изд., перераб. и доп. - СПб.: БХВ-Петербург, 2004. - 1040 с.

28. Романов Д. А., Ильина Т. Н., Логинова А. Ю. Правда об электронном документообороте. - М.: ДМК Пресс. - 224 с.

29. Рудько Г. И., Назаренко М. В., Хоменко С. А., Нецкий А. В., Федорова И. А. - Геоинформационные технологии в недропользовании (на примере ГИС K-MINE) - К.: «Академпрес», 2011. - 336 с.

30. Трудовой кодекс Российской Федерации. Под ред. Дегтяревой Т. - М.: Эксмо, 2013. - 208 с.

31. Хопкрофт Д., Мотвани Р., Ульман Д. Введение в теорию автоматов, языков и вычислений = Introduction to Automata Theory, Languages, and Computation. -М.: Вильямс, 2002. - 528 с.

32. Черняк Л. Задачи управления мастер-данными // Открытые системы. №5. - 2007.

Размещено на Allbest.ru