План

Роль интерфейса пользователя при построении прикладного ПО.

Краткая характеристика программы.

Результаты и их анализ.

Структура системы меню.

Текст программы

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

<задание на курсовой проект>

Роль интерфейса пользователя при построении прикладного ПО.

Сегодня трудно не заметить, какими темпами компьютерная техника входит в нашу жизнь. Входит она и в лице персональных компьютеров, которых с каждым днем становится все больше и больше, и в лице бытовой техники, которая уже сплошь «набита» электроникой, взять хотя бы микроволновые печи, мобильные телефоны, электронные записные книжки и т.д. Обычному человеку очень трудно приспособиться к массе новой техники, и очень часто ему приходится выбирать между соблазном использовать достижения научно-технического прогресса и необходимостью «перелопачивать» тонны сопроводительной литературы и руководств пользователя. Фирмы, занимающиеся производством бытовой компьютерной техники, должны показать пользователю, что ему стоит покупать данный продукт, и немаловажную роль играет в этом построение удобного и интуитивно-понятного интерфейса. Естественно, пользователю не нужна микроволновая печь с цифровой клавиатурой, на которой необходимо набрать массу команд, прежде чем печь начнет работать. Но его вполне устроит дисплей с таймером и кнопкой пуска. Трудно не догадаться, что нужно установить время и нажать на кнопку. Опять же, еще одна крайность – что если бы перед ним была бы панелька и ему пришлось бы отсоединить проводок от одного места и присоединить к другому… Какой выбор сделал бы пользователь? (Кстати, почему многие предпочитают импортную технику? В том числе и потому, что она удобна и проста).

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

Но мы остановимся пока на чисто-графическом интерфейсе. Для сложного программного обеспечения часто оказывается невозможным представить все ее возможности на экране с помощью кнопок, списков, флажков и т.д. Тут на помощь приходит меню – структура, использующая пространство экрана динамически. Основной идеей меню является последовательная конкретизация желания пользователя. Пусть, например, пользователь хочет вставить в свой документ иллюстрацию и не знает, как это сделать. Однако он знает, что меню предоставит ему доступ к любой функции программы. Если он начнет проглядывать все опции подряд (а их может оказаться несколько сотен), он может потратить довольно много времени. Но он пойдет по другому пути. Строчка меню довольно небольшая, всего 6-10 пунктов. Просматривая их названия по очереди, он вряд ли остановится на пункте «Вид» или «Файл», зато его точно заинтересует меню «Вставка». Открыв его, он аналогичным образом проглядывает новый список. И так же не обратит внимания на «Примечание» или, например, «Закладка», но выберет «Рисунок». Нетрудно видеть, что, в конце концов, он своей цели добьется довольно быстро.

Задача проектировщика ПО состоит в том, чтобы создать это меню наиболее очевидным образом, удачно построить иерархию в соответствии с принципом пошаговой конкретизации. Задача дизайнера – оформить меню так, чтобы нужный пункт сразу бросался в глаза (например, иконками, выделением и т.д.). Задача программиста – запрограммировать все это так, чтобы можно было бы создавать меню любой сложности (дальновидный программист знает, что ему вряд ли придется писать меню один раз и только простенькое), чтобы меню работало корректно (вряд ли кому понравятся постоянные «глюки»), чтобы пользователь мог достичь одной и той же цели разными путями (например, введение «горячих клавиш»), чтобы управление было интуитивно-понятным (курсор, Enter, с учетом, что до Enter’а пользователю лишний раз тянуться лень и что пользователь может захотеть изменить свой выбор), и чтобы программа была как можно менее требовательна к аппаратуре («Ну, на Pentium III может еще и пойдет…»).

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

Краткая характеристика программы.

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

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

Внутренняя реализация такова: компьютер переводится в графический режим и запускается так называемый «ждущий цикл», который ждет нажатия клавиши и, дождавшись, передает значение нажатой клавиши специальному обработчику класса, который уже решает, что с ним делать. Конечно, в сложных системах лучше было бы организовать принцип событий. «Ждущий цикл» ждет событие (нажатие клавиши, движение мышки, сигнал системы – что угодно), формирует объект типа Event, а затем рассылает его всем имеющимся в его распоряжении объектам, а их обработчики уже сами решают, нужно реагировать на это событие, или не нужно. Кроме того, полезно было бы определить классы Application, метод которого инициировал бы граф-режим, определял бы «ждущий цикл», класс Window, DialogWindow, добавить свойства, которые однозначно определяли бы каждый экземпляр каждого объекта, добавить канцепцию событий и т.д. Но это сильно усложнило бы программу и увело бы от цели работы. Поэтому здесь и наблюдается некоторое несоответствие принципам ООП.

Реакции класса на нажатия клавиш следующие:

♦ ВЛЕВО – находимся в подменю – выходим из него, если же выходить можно только в главное меню, то смещаем выделение в главном меню влево (если мы находимся в начале, то переходим в конец), при этом пункт остается открытым.