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

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

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

Олькина Е.В.

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

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

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

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

Создание вычислительных систем при использовании концепции разработки программ. По мнению исследователей этой проблемы Хартсона Х.Р., Роуча Р.В. и Галлана Дж.Е. подобный подход давал некоторые преимущества, которые заключаются в том, что разработчику становилось легче управлять сложным процессом разработки проекта при наличии необходимой документации, например, модели информационных (функциональных) потоков. [6] Эксперименты показали, что данный подход привел к существенному повышению производительности труда разработчиком систем по сравнению с предыдущим этапом.

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

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

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

Создание систем, в которых разработчики системы и разработчики пользовательских интерфейсов работают на основе единой методологии, отличительной особенностью которой является наличие третьего компонента в проектируемой системе - блока управления системой. Для данной методологии характерно отделение функциональных аспектов эксплуатации пользовательских интерфейсов от технологических аспектов их проектирования и создания, что дает возможность разработчику пользовательского интерфейса заниматься созданием и испытанием интерфейсов, при этом интерфейс полностью отделяется от основного кода информационной системы. Это положение методологии получило название «независимость диалога».[5]

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

В современной книге по управлению проектами («UML Toolkit» (Eriksson and Magnus, 1998)) и нотации UML (методология разработки программного обеспечение RUP), не рассматривается необходимость рассматривать интерфейс проектируемой системы уже на стадии анализа требований к проекту, которая в нотации UML обозначается как первая фаза его разработки. Однако в действительности разработку интерфейса не следует откладывать до стадии технической реализации проекта, которую Эриксон и Магнус в своей работе определяют, как третью фазу.

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

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

Рисунок 1 - Модель функционирования группы специалистов по разработке интерфейса

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

Определив цели и задачи, для которых предназначена проектируемая система, необходимо сначала спроектировать интерфейс (следствие из модели), после чего следует приступать к его реализации. Это повторяющийся процесс. Как правило, определение задач и их количество меняется во время разработки интерфейса. Поэтому весь процесс разработки системы будет проходить в соответствии с изменениями в требованиях системы и его интерфейсе. Здесь разработчики всегда стремятся к максимальной гибкости, то есть при любом изменении требований проект должен позволить внести изменения без существенной переделки уже проделанной работы и тем более без отказа от всех предыдущих разработок. На первом этапе разработки следует определить и четко представлять, что именно должен сделать пользователь для получения того или иного результата и как система должна отвечать на каждое его действие. [3,7]

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

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

Рисунок 2 - Схема диалога пользователя с информационной системой

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

Для проектирования пользовательского интерфейса, представленным внешним диалогом любой разрабатываемой системы, используются модели, представленные на рисунке 3.

Рисунок 3 - Модели, используемые при проектировании пользовательского интерфейса

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

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

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

интерфейс информационный визуальный архитектура

Литература

1. Бережной, В.А. Системы управления пользовательским интерфейсом (UIMS) [Текст] / В.А. Бережной, С.В. Клименко, В.Д. Юрпалов. - Пользовательский интерфейс: исследование, проектирование, реализация. - 1998. - с.31-43.

2. Курьян, А.Г. Реализация процессного подхода в рамках систем менеджмента качества на основе методологии функционального моделирования IDEF0 [Текст] / А.Г. Курьян, П.С. Серенков / Качество. Инновации. Технологии. - 2004, №4. - с. 45-48.

3. David A. Carr A. Compact Graphical Representation of User Interface Interaction Objects, Dissertation Submitted to the Faculty of the Graduate School of The University of MaryLand for the degree of Doctor of Philosophy. - 1995. - p.107.

Аннотация

An article considers formation of process of realization of the user interfaces for last decades and problems which developers of similar systems faced. One of variants of the decision of the revealed problems which now can is offered is wide be used in complex systems, especially an industrial function. Reorganization of groups of projects is offered: allocation of the expert or group of the experts who are engaged in designing and realization of the graphic user interface. The model of developed information streams displaying process of functioning of group of working out of the user interface and its interaction with the basic group of the project is presented. The model of embedding of the user interface is presented to the existing software

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