Тео Мандел в своей работе [1, с. 244] выделяет четыре этапа разработки пользовательского интерфейса, а именно:
• Сбор и анализ информации от пользователей;
• Разработка пользовательского интерфейса;
• Построение пользовательского интерфейса;
• Подтверждение качества пользовательского интерфейса.
Первый шаг – определение профиля пользователя. Профиль пользователя отвечает на вопрос: «Что представляет наш пользователь?». Он позволяет нам составить представление о возрасте, образовании, предпочтениях пользователей.
Второй шаг – анализ стоящих перед пользователями задач.
Анализ стоящих перед пользователями задач – это определение того, чего хотят пользователи и каким образом они собираются решать свои задачи.
Концептуальное проектирование есть определение общей структуры и взаимодействия продукта. По определению Алана Купера [2, с. 190], концептуальные принципы проектирования «помогают определить сущность продукта и его место в более широком контексте использования, который требуется пользователям».
Концептуальное проектирование включает:
• Определение типа интерфейса будущего приложения (монопольный, временный, фоновый);
• Организацию инфраструктуры взаимодействия;
Согласно определению Алана Купера [2, с. 200], тип интерфейса определяет поведенческую сущность продукта, то есть то, как он предъявляет себя пользователю. Тип интерфейса – это способ описать то, как много внимания пользователь будет уделять взаимодействию c продуктом, и каким образом продукт будет реагировать на это внимание.
Следует отметить зависимость типа интерфейса от используемой технической платформы: персонального компьютера, Интернет, информационный киоск, мобильное устройство, бытовая техника.
Применительно к программам, которые разрабатываются для современных персональных компьютеров, в литературе также используется термин «настольное приложение».
Интерфейс настольных приложений можно отнести к одному из трёх типов: монопольный, временный и фоновый.
К приложениям монопольного типа относятся программы, которые полностью завладевают вниманием пользователя на длительные периоды времени. Для продуктов с монопольным интерфейсом характерна длительная работа в течение длительных отрезков времени. В процессе работа пользователя монопольный продукт является его основным инструментом и преобладает над остальными.
Приложение временного типа приходит и уходит, предлагая одну функцию и ограниченный набор связанных с этой функцией элементов управления. Приложение этого типа вызывается при необходимости, делает свою работу и быстро исчезает, позволяя пользователю продолжить прерванную (как правило, в окне монопольного приложения) деятельность. Типичный пример сценария работы с временным приложением – вызов Проводника Windows для поиска и открытия другого файла в то время, когда пользователь уже редактирует один файл в MS Word.
Фоновыми называют приложения, которые в нормальном «рабочем» состоянии не взаимодействуют с пользователем. Такие программы выполняют задачи, которые в целом важны, но не требуют вмешательства пользователя. Примеры: драйвер принтера, подключение к сети.
Инфраструктура взаимодействия [2, с. 163] включает варианты поведения приложения. Создание инфраструктуры взаимодействия предполагает выполнение шести шагов [2, с. 164]:
Шаг 1. Определение форм-фактора, типа приложения и способов управления.
Шаг 2. Определение функциональных и информационных элементов.
Шаг 3. Определение функциональных групп и иерархических связей между ними.
Шаг 4. Макетирование общей инфраструктуры взаимодействия.
Шаг 5. Создание ключевых сценариев.
Шаг 6. Выполнение проверочных сценариев для верификации решений.
Форм-фактор – это зависимость вида пользовательского интерфейса от используемой технической платформы.
Функциональные и информационные элементы – это зримые представления функций и данных, доступные пользователю посредством интерфейса. Это конкретные проявления функциональных и информационных потребностей, выявленных на стадии выработки требований.
Информационные элементы – это, как правило, фундаментальные объекты интерактивных продуктов.
Функциональные элементы – это операции, которые могут выполняться над информационными объектами и представляющими эти объекты элементами интерфейса. В большинстве случаев функциональные элементы представляют собой инструменты, работающие с информационными элементами, а также контейнеры, содержащие информационные элементы.
Макетирование общей инфраструктуры взаимодействия Аланом Купером [2, с. 169] охарактеризовано как «фаза прямоугольников», поскольку эскизы будущего интерфейса начинаются с разделения каждого представления на прямоугольные области, соответствующие панелям, элементам управления и другим высокоуровневым контейнерам. При этом каждому прямоугольнику даётся своё название и показывается, каким образом одна группа элементов может влиять на другие. Содержательно этот шаг предназначен для исследования различных вариантов представления информации и функциональности в интерфейсе, при этом затраты на внесение изменений должны быть минимальны.
Известны два вида макетов: с жёсткой компоновкой и без компоновки.
При этом макет с жёсткой компоновкой:
• содержит взаимное расположение элементов и визуальную информацию о приоритетах;
• ограничивает работу графического дизайнера.
Для макета без компоновки характерно то, что он:
• не содержит графического представления элементов;
• содержит текстовое описание элементов и их приоритетов;
• не ограничивает работу графического дизайнера.
Сценарий определяется Аланом Купером как средство описания идеального для пользователя взаимодействия [2, с. 146]. Истоки этого понятия восходят к публикациям сообщества HCI (Human-Computer Interaction – взаимодействие человека и компьютера), где оно увязывалось с указанием на метод решения задач проектирования через конкретизацию, которая понималась как использование специально составленного рассказа, чтобы одновременно конструировать и иллюстрировать проектные решения [2, с. 148]. Применение сценарного подхода к проектированию, как показано в книге Кэрролла «Making Use» (Carroll, 2000), сосредоточено на описании того, как пользователи решают задачи. Такое описание включает характеристику обстановки рабочей среды, а также агентов, или действующих лиц, которые являются абстрактными представителями пользователей.
Сценарии, основанные на персонажах, есть краткие описания одного или более персонажей, применяющих программный продукт для достижения конкретных целей. Сценарии позволяют начинать проектирование с рассказа, описывающего идеальный с точки зрения персонажа опыт, при этом фокусируя внимание на людях, их образе мысли и поведении.
Процесс выработки требований с использованием персонажей и сценариев состоит из следующих пяти шагов:
Шаг 1. Постановка задач и определение образа продукта.
Шаг 2. Мозговой штурм.
Шаг 3. Выявление ожиданий персонажей.
Шаг 4. Разработка контекстных сценариев.
Шаг 5. Выявление требований.
Ключевой сценарий описывает взаимодействие персонажа с системой в терминах лексикона инфраструктуры взаимодействия. Он отражает магистральные пути внутри интерфейса, используемые персонажем чаще всего (например, ежедневно). Ключевые сценарии сосредоточены на задачах. Например, в случае приложения для работы с электронной почтой ключевые действия – это просмотр и создание новых сообщений, а не настройка нового почтового сервера.
Ключевые сценарии, как правило, являются результатом развития контекстных сценариев, но целенаправленно описывают взаимодействие персонажа с различными функциональными и информационными элементами, составляющими общую инфраструктуру взаимодействия.
Контекстные сценарии сосредоточены на целях, же ключевые сценарии больше сосредоточены на задачах, намеки на которые или описания которых содержатся в контекстных сценариях [2, с. 171].
Задание на лабораторную работу
Лабораторная работа №2 предполагает разработку концепции пользовательского интерфейса программного продукта. В работе требуется выполнить этап концептуального проектирования применительно к созданию пользовательского интерфейса приложения для предметной области по варианту задания на лабораторную работу №1.
Перед выполнением второй лабораторной работы следует ознакомиться с материалами лекций №5 и 6.
Результаты исследования потенциальных пользователей и предметной области проектируемого программного продукта, а также моделирования персонажей и контекстов использования, полученные в ходе выполнения лабораторной работы №1, следует использовать как основу принятия решений при разработке концепции будущего программного обеспечения. При этом основополагающими являются ответы на следующие вопросы:
• Кто, зачем и как будет использовать данный продукт?
• Как построить взаимодействие с продуктом, чтобы помочь пользователю достичь своей цели?
• Какой уместен тип пользовательского интерфейса?
• Какие информационные и функциональные элементы пользовательского интерфейса должны присутствовать?
• В какой последовательности, с какими приоритетами, с какой группировкой их следует располагать?
• Какую навигационную схему выбрать?
• Как организовать и именовать интерактивные объекты?
• Какие ключевые пути общения пользователя с продуктом существуют?
Данный перечень содержит типовые вопросы, которые возникают при проектировании взаимодействия пользователя с программным продуктом.
Подобного рода вопросы следует рассматривать с точки зрения знаний, полученных в ходе выполнения лабораторной работы №1.
В результате выполнения лабораторной работы №4 студент должен приобрести следующие навыки и умение:
• умение переводить требования к программному продукту, выработанные на исследовательском этапе, в концепцию пользовательского интерфейса продукта, позволяющего его персонажам эффективно достигать своих целей;
• навыки применения принципов и шаблоны проектирования взаимодействия.
Рекомендуемая последовательность этапов выполнения лабораторной работы №2:
1) на основе исследования, проведённого в лабораторной работе №1, разработать требования к проектированию концепции пользовательского интерфейса (объекты, действия, контексты);
2) разработать концепцию общей инфраструктуры взаимодействия:
• определить тип приложения и способы управления;
• разработать информационную архитектуру продукта (системы организации, наименования, навигации и поиска);
• разработать навигационную модель для каждого персонажа;
• определить информационные и функциональные элементы интерфейса, связи между ними, основания для группировки, приоритеты для персонажей и последовательности элементов;
• разработать ключевые сценарии использования продукта для каждого персонажа (интерактивные раскадровки);
• составить список проверочных сценариев;
• выполнить объединение ключевых и проверочных сценариев всех персонажей, результат отразить на совокупной диаграмме взаимодействия;
• разработать макеты экранов для выбранной концепции пользовательского интерфейса.
Рекомендуемые инструменты:
• MS Visio – для разработки различных схем и диаграмм, в том числе – макетов пользовательского интерфейса. Адрес в Internet (бесплатно по подписке MSDN Academic Alliance): https://msdnaa.lib.bmstu.ru/.
• карточная сортировка Websort.net – инструмент для проведения удалённой карточной сортировки. Адрес в Internet (до 10 респондентов – бесплатно): https://websort.net/;
• Microsoft Expression Blend – для разработки интерфейса взаимодействия с пользователем для платформ MS.NET и MS Silverlight. Адрес в Internet (бесплатно по подписке MSDN Academic Alliance): https://msdnaa.lib.bmstu.ru/.
2 Результатом выполнения лабораторной работы являются следующие документы:
• требования для разработки концепции общей инфраструктуры взаимодействия: объектная модель (см. лекцию №4), функциональные требования, контексты; связи объектов, действий и контекстов с персонажами программного продукта;
• краткое описание информационной архитектуры продукта: выбранные виды систем организации, наименования, навигации и поиска (опционально);
• навигационная модель системы для каждого персонажа и общая диаграмма путей;
• интерактивные раскадровки для каждого персонажа и совокупная диаграмма взаимодействия;
• концептуальные макеты с жёсткой компоновкой.
3 В отчёте о выполнении работы должно быть отражено планирование этапа концептуального проектирования и краткое описание выполненных шагов.
ЛАБОРАТОРНАЯ РАБОТА №5
Отладка программных продуктов
Одним из важнейших этапов разработки программ является процесс поиска и устранения ошибок, неизбежно возникающих при написании сложных программных систем. Для того, чтобы упростить и во многом автоматизировать этот процесс, необходимо использовать специальные программы, называемые отладчиками. Несмотря на то, что сложность написания параллельных программ часто существенно превосходит сложность написания последовательных аналогов, длительное время наблюдалась нехватка качественных отладчиков для параллельных программ, разрабатываемых с использованием технологии MPI.
Новейшая интегрированная среда разработки Microsoft Visual Studio 2013 имеет в своем составе отладчик, предоставляющий широкие возможности для поиска и устранения ошибок, в том числе и для отладки MPI приложений.
Цель работы: получение практических навыков отладки параллельных MPI программ в среде Microsoft Visual Studio 2013. При этом будет предполагаться, что на рабочей станции установлен Compute Cluster Server SDK, и, следовательно, используется реализация MPI от компании Microsoft (библиотека MS MPI):
• Упражнение1 – Тестовый локальный запуск параллельных программ,
• Упражнение2 – Отладка параллельной программы в Microsoft Visual Studio 2013.
Теоретические сведения
Отладка (поиск и устранение ошибок) – один из важнейших этапов в написании программных систем, часто занимающий у разработчика больше времени, чем написание отлаживаемого кода. Для того, чтобы максимально снизить время, затрачиваемое на отладку, необходимо придерживаться рекомендаций крупнейших производителей программного обеспечения и ведущих исследователей в области компьютерных наук еще на этапах проектирования и программирования. Например, подобные рекомендации обычно требуют подготавливать автоматические тесты для всех участков разрабатываемой системы и контролировать корректность значений внутренних переменных с использованием макроса ASSERT. Но и сама процедура отладки должна проводиться эффективно, в соответствии с рекомендациями ведущих экспертов в этой области. Огромное значение здесь имеет правильный выбор отладчика– специальной программы, существенно упрощающий процесс поиска ошибок, позволяющий выполнять программу в пошаговом режиме, отслеживать значения переменных, устанавливать точки остановки и т.д.
Важнейшими критериями выбора отладчика являются богатство предоставляемого программисту инструментария и удобство использования. В ходе выполнения данной лабораторной работы мы будем использовать стандартный отладчик среды Microsoft Visual Studio 2013, удачно сочетающий в себе интуитивно понятный пользовательский интерфейс и широкий спектр предоставляемых возможностей.
Наиболее частым приемом отладки является приостановка работы программы в заданный момент времени и анализ значений ее переменных. Момент, в который программа будет приостановлена, определяется выбором, так называемых, точек остановки, то есть указанием строк кода исходной программы, по достижении которых выполнение останавливается до получения соответствующей команды пользователя. Помимо простого указания строк кода, где произойдет приостановка, возможно также указание условий, которые должны при этом выполняться. Например, можно дать указание приостановить выполнение программы на заданной строке только в том случае, если значение некоторой переменной программы превысило заданную константу. Правильный выбор момента остановки имеет решающее значение для успеха отладки. Так, зачастую анализ значений переменных непосредственно перед моментом падения программы дает достаточно информации для определения причин некорректной работы.
Другим исключительно полезным инструментом является возможность выполнять программу в пошаговом режиме– по одной строке исходного кода отлаживаемой программы при каждом нажатии пользователем кнопки F10. При этом пользователь также имеет возможность заходить внутрь функции, вызов которой происходит на данной строке, или просто переходить к следующей строке. Таким образом, пользователь всегда находится на том уровне детализации, который ему необходим.
Для того, чтобы в полной мере оценить преимущества отладчика, необходимо предварительно скомпилировать программу в специальной отладочной конфигурации (чаще всего такая конфигурация называется “Debug”), особенностью которой является добавление в генерируемые бинарные файлы специальной отладочной информации, которая позволяет видеть при отладке исходный код выполняемый программы на языке высокого уровня.
К числу других часто используемых инструментов отладки Microsoft Visual Studio 2013 относятся:
• Окно “Call Stack” - окно показывает текущий стек вызова функций и позволяет переключать контекст на каждую из функций стека(при переключении контекста программист получает доступ к значениям локальных переменных функции),
• Окно “Autos” - окно показывает значения переменных, используемых на текущей и на предыдущих строках кода. Кроме того, это окно может показывать значения, возвращаемые вызываемыми функциями. Список отображаемых значений определяется средой автоматически,
• Окно “Watch” - окно позволяет отслеживать значения тех переменных, которых нет в окне “Autos”. Список отслеживаемых переменных определяется пользователем,
• Окно “Threads” - окно позволяет переключаться между различными потоками команд процесса,
• Окно “Processes” - окно позволяет переключаться между различными отлаживаемыми процессами (например, в случае отладки MPI – программы).
Отладка параллельных MPI программ имеет ряд особенностей, обусловленных природой программирования для кластерных систем. Напомним, что в параллельной программе над решением задачи работают одновременно несколько процессов, каждый из которых, в свою очередь, может иметь несколько потоков команд. Это обстоятельство существенно усложняет отладку, так как помимо ошибок, типичных для последовательного программирования, появляются ошибки, совершаемые только при разработке
параллельных программ. К числу таких ошибок можно отнести, например, сложно контролируемую ситуацию гонки процессов, когда процессы параллельной программы взаимодействуют между собой без выполнения каких-либо синхронизирующих действий. В этом случае, в зависимости от состояния вычислительной системы, последовательность выполняемых действий может различаться от запуска к запуску параллельной программы. Как результат, при наличии гонки процессов сложным становится применение одного из основных принципов отладки– проверка работоспособности при помощи тестов (однократное выполнение теста для параллельной программы может не выявить ситуации гонки процессов).