Проектирование информационных систем

Методические указания

к лабораторному практикуму

Специальность 080801.65 – Прикладная информатика

Содержание

Лабораторная работа «Проектирование пользовательского

интерфейса» 4

1. Цель работы 4

2. Программно-техническая платформа 4

3. Теоретическая часть 4

4. Перечень заданий к лабораторной работе 16

5. Порядок выполнения лабораторной работы 20

6. Содержание отчета по лабораторной работе 23

Лабораторная работа «Разработка диаграмм потоков данных

с использованием CASE-технологии» 24

1. Цель работы 24

2. Программно-техническая платформа 24

3. Теоретическая часть 24

4. Перечень заданий к лабораторной работе 27

5. Порядок выполнения лабораторной работы 29

6. Содержание отчета по лабораторной работе 39

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

Приложения 41

Лабораторная работа

«Проектирование

пользовательского интерфейса»

1. Цель работы

Целью работы «Проектирование пользовательского интерфейса» является закрепление навыков в области разработки иерархического меню, проектирования экранных форм и отчетов при создании АРМ управленческого персонала. В ходе работы студенты приобретают практические навыки проектирования стандартного интерфейса Windows (многоуровневое меню, формы, отчеты) с помощью средств MS Access 2003.

2. Программно-техническая платформа

В качестве программного обеспечения используются приложения Microsoft Office 2003 Microsoft Access 2003 и Microsoft Word 2003.

Минимальные требования к технической платформе: персональный компьютер Pentium III и выше, 128 Мб оперативной памяти.

3. Теоретическая часть

Проектирование пользовательского интерфейса

Пользовательский интерфейс (User Interface – UI) включает в себя: меню, экранные формы и отчеты.

При проектировании пользовательского интерфейса любой программы должны выполняться следующие эвристические правила [3]¹:

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

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

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

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

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

• Свобода действий пользователя. Пользователь должен иметь контроль над системой и возможность изменить текущее состояние программы. Чаще всего это реализуется в виде кнопки Cancel (Отмена), расположенной в диалоговом окне и позволяющей прекратить выполнение текущей операции или закрыть это диалоговое окно. Аналогичный результат дает нажатие на клавиатуре клавиши <Escape>. Еще одним средством выхода из ошибочной ситуации являются функции Undo (Отменить) и Redo (Повторить). Если же по каким-либо причинам действие, на выполнение которого дал команду пользователь, нельзя будет отменить, то на экран должно быть выведено соответствующее предупреждение, а также просьба подтвердить выполнение команды.

• Последовательность и стандарты. Принцип последовательности означает использование одних и тех же средств для выражения схожих образов и выполнения действий, имеющих одинаковую природу. Примером применения принципа последовательности и стандартизации является интерфейс «в стиле Windows».

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

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

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

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

• Распознавание и исправление ошибок. Это правило определяет проектирование сообщений об ошибках. Сообщение об ошибке должно состоять из двух частей:

• описание ошибки. Оно должно быть четким, ясным и понятным, давать пользователю всю необходимую информацию о причинах и месте возникновения ошибки;

• описание решения проблемы. Большинство разработчиков программ размещают описание решения проблемы в разделе справочной системы, посвященном соответствующей ошибке. Однако лучше всего включить эту информацию прямо в диалоговое окно сообщения об ошибке, так, как это сделано, например, в системе управления базами данных Microsoft Access. При описании пути решения проблемы нужно избегать составления слишком объемных текстов, т.к. пользователи будут просто пробегать их глазами, не вникая в смысл написанного, подобно тому, как человек, просматривающий газету, сначала останавливает взгляд на коротких заметках, пропуская большие материалы. Поэтому рекомендуется составлять описание действий по исправлению ошибки наподобие пошаговой инструкции, каждый шаг которой составляет 1–2 предложения.

• Справка и документация. Меню программы (системы) должно содержать пункт, с командами Справка (Help), О программе вызывающие соответственно справочную систему и информацию о программе.