Software & Systems

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

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

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

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

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

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

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

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

При решении задачи предлагается использовать метод анализа пользовательского интерфейса [2] на основе статистических данных о последовательности вызовов программных модулей при работе с информационной системой.

Рассмотрим пример использования данного метода в реальных приложениях, а именно структуру программного компонента сбора статистических данных (КССД). Как средство описания структуры КССД используем нотацию UML.

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

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

Функционирование КССД иллюстрируют диаграммы состояний и последовательности (рис. 2 и рис. 3).

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

Пример реализации приведем с использованием языка Object Pascal (Borland Delphi).

Дадим описание класса TАctivater.

type

TActivater = class

 private

  Fmodule : Integer;

  Fdependence : Boolen;

  FWorkType : Integer;

 public

  procedure DoRegistrationEnter (ModuleID, WorktypeID :Integer);

 procedure DoRegistrationExit (ModuleID, WorktypeID :Integer);

 property Module : Integer

  read Fmodule

  write Fmodule;

 property Dependence : Boolen

  read Fdependence

  write Fdependence;

 property WorkType : Integer

  read FWorkType

  write FWorkType;

 end;

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

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

Свойство WorkType определяет характер выполняемой работы модулем (пользователем в модуле), например, расчетные действия, редактирование данных, ввод данных и т.д. Свойство Module определяет уникальный номер модуля.

Процедуры DoRegistrationEnter и DoRegistrationExit выполняют регистрацию события входа или выхода из модуля.

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

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

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

В процессе работы системы при каждом входе и выходе из модуля (подпрограммы) производится регистрация данного события в БД. Таким образом, на этапе опытной эксплуатации системы накапливается информация, по которой можно судить о характере работы операторов на рабочих местах. На основе полученных данных можно построить модели работы оператора для каждого АРМ.

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

Список литературы

1. Шибанов Г.П. Количественная оценка деятельнос- ти человека в системах человек-техника. - М.: Машиностроение, 1983.

2. Музяков И.Р., Мустафин Н.Г., Савосин С.В. Статистический анализ пользовательского интерфейса. // Программные продукты и системы. - 1999. - № 4