lab4_UseCase

Лабораторная работа № 4. Проектирование интерфейса
Файл 681469673
С. 1 из 6
Лабораторная работа № 4. Проектирование интерфейса
1. Постановка задачи
Разработать приложение, реализующее задачу из курса «Технология разработки ПО».
Ключевые персонажи, работающие с приложением:
 разработчик; интерфейс должен обеспечить удобное тестирование;
 приемщик работы (в данном случае преподаватель – Е.С.); интерфейс должен обеспечить прогон предложенных разработчиком тестов и возможность задания других тестов;
 собственно пользователь; интерфейс должен обеспечить удобное задание данных и просмотр результатов.
Уточнения
 Инструментарий разработки – среда Delphi.
 В нашем случае уже есть работающее приложение. Цель его создания была – отработка нисходящей технологии проектирования ПО. Теперь следует посмотреть на него с точки зрения поставленной задачи. В идеале приложение отлажено разработчиком, принято преподавателем; это
сделано через посредство каких-то интерфейсов; т.е. для двух персонажей требуется скорее
осмысление и анализ проделанной работы, нежели новая разработка.
 Конечного пользователя придется придумать. Условия учебного процесса иного не позволяют.
 Компоненты приложения можно разделить на интерфейсные и обрабатывающие («движок»). Интерфейсные – это компоненты, связанные с вводом-выводом данных и, возможно, диагностикой
ошибок поскольку анализ аномалий стандартными визуальными средствами можно реализовать
несколько иначе, чем непосредственным программированием, и, возможно, более эффективно).
Поскольку приложение разработано технологично, по нисходящей схеме, хорошо документировано, разделить эти компоненты несложно. Движок останется тем же, а имеющийся интерфейс может быть заменен на новый.
 Терминология
Поскольку деятельность по проектированию интерфейсов не является формализованной, смысл
основных понятий, используемых в разных источниках, определен не строго, а скорее описательно. Тем не менее чаще всего хорошо видно, что речь идет об одних и тех же вещах, т.е. легко просматривается сходство смыслов отдельных понятий.
Персонаж
– цель
– сценарий (Купер);
Актер
– вариант использования (Use Case) – сценарий (язык UML);
Модель пользовательской роли – сущностный элемент (Use Case) (Константайн, Локвуд).
Поэтому там, где это не вызывает недоразумений, не будем вдаваться в терминологические тонкости.
Рекомендация. Целесообразно объединиться в бригады для стимуляции мыслительной деятельности («мозгового штурма») .
2. Выбор актеров (персонажей) и определение вариантов использования
Актер (Actor), или действующее лицо – любой объект, субъект или система, взаимодействующая
с моделируемой системой извне так, как определит сам разработчик. В нашем случае это человек
– пользователь одного из трех указанных в постановке задачи классов.
Вариант использования (Use Case) – описание некоторого аспекта поведения проектируемой
системы без указания особенностей реализации данной функциональности. В этом смысле каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемая система по запросу актера, т.е. одному из способов применения системы.
Таким образом, актер и вариант использования – понятия взаимоопределяющие.
Для описания актера можно использовать следующие параметры 1.
 Обязанности:
1
Константайн, с. 112-116
Лабораторная работа № 4. Проектирование интерфейса
Файл 681469673
С. 2 из 6
- знание проблемной области;
- знание системы;
- прочие знания.
 Умения: уровень мастерства в работе с системой (от новичка до профессионала).
 Взаимодействия:
- частота нахождения в данной роли;
- регулярность;
- непрерывность;
- равномерность распределения работы во времени;
- интенсивность (скорость взаимодействия).
 Информация:
- каковы источники входящей информации, предоставляемой пользователем;
- объем информации;
- сложность информации.
 Критерии практичности интерфейса
 Функциональная поддержка: особые требования к функциональности
 Практический риск: оценка потенциальных убытков при работе с системой.
 Аппаратные ограничения
 Среда
Рекомендация. При выполнении работы конкретизируйте основные из этих характеристик для
персонажей разработчика и приемщика работы (обобщенных, но реальных) и сочините конечного
пользователя о своему вкусу. Например: Поль Элюар, поэт. В компьютерах не смыслит, но запускать программы умеет. Хочет попробовать, что выдаст данное приложение. И т.д.
Или: Поль М., сотрудник научного отдела. Проводит расчеты с помощью приложения регулярно (...
раз в ...). По истечении месяца результаты расчетов анализируются и обобщаются. И т.д.
Описания персонажей являются основой требований к соответствующим интерфейсам.
Для уточнения варианта использования решаются следующие вопросы 1.
 Каковы основные задачи, решаемые пользователями, выступающими в данной роли?
 Что должны уметь делать пользователи, чтобы играть данную роль?
 Какие возможности должна предоставлять система, чтобы пользователь мог решить любые задачи, присущие данной роли?
 Какую информацию пользователям в этой роли необходимо анализировать, создавать или изменять?
 Что потребуется пользователям в этой роли, чтобы они были в курсе происходящего в системе?
 О чем пользователи в этой роли должны информировать систему?
Рекомендация. При выполнении работы конкретизируйте основные из этих характеристик для
вариантов использования «тестирование», «прием работы», «решение задачи» (варианты, соответствующие персонажам).
Сценарии. Содержание варианта использования может быть представлено в форме дополнительного пояснительного текста – текста-сценария, или просто сценария. Для написания сценариев методологией RUP предлагаются определенные шаблоны (см. тему 6 курса «Технология
разработки ПО»). Сценарии – очень существенная часть модели Use Case; можно считать их текстовым аналогом модели. Кроме того, они удобны при определении элементов интерфейса для
реализации отдельных действий сценария.
1
Константайн, с. 139
Лабораторная работа № 4. Проектирование интерфейса
Файл 681469673
С. 3 из 6
3. Очерк основных моментов описания актеров и вариантов использования применительно к поставленной задаче
 Согласно Куперу, дадим персонажам имена. Пусть:
пользователь носит имя Поль;
разработчик-программист – Вася;
приемщик работы - преподаватель – Препод.
Описания персонажей – актеров и вариантов использования сделайте, пожалуйста, на основе материала п. 2 и нижеследующего материала.
 Кардинальные различия в работе с приложением Поля, Васи и Препода
Число запусков с одним набором данных
Общее количество
используемых наборов
данных
Количество запусков
приложения за сеанс
Переключение между
задачами за сеанс
Требования к скорости
рабоы
Требования к представлению информации
Поль
Один (решение задачи)
В зависимости от числа решаемых задач
Вася
Много (отладка)
В зависимости от целей (сеанс решения);
предположительно
мало
В зависимости от целей; предположительно мало
Завершение задачи за
приемлемое время
Пропорционально
числу тестов и числу
ошибок (сеанс отладки); много
Нет
Состоятельность, информативность, полнота.
Интерфейс должен
обеспечить минимизацию числа ошибок при
вводе данных и при их
чтении.
Число тестов задачи
(много)
Полный цикл запуска
(от ввода данных до
просмотра результата)
должен быть как можно меньше
Состоятельность, компактность, возможность сравнения результатов (интерфейс
должен позволять сохранять входные данные и результаты с
целью их сравнительного анализа или экспорта)
Препод
Один (проверка правильности работы)
Число тестов × число
проверяемых задач
(очень много)
Число тестов × число
проверяемых задач
(очень много)
По числу проверяемых
задач (много)
Полный цикл запуска
(от ввода данных до
просмотра результата)
должен быть как можно меньше
Состоятельность, компактность
 Требования к интерфейсу
•• Поль
Состоятельность (назначение всех элементов должно быть понятно).
Максимальная информативность (ввод только необходимых данных, отсутствие требований ненужных подтверждений, отсутствие вывода ненужных сообщений).
Немодальность.
Монотонность.
Все требования взаимосвязаны. Интерфейс должен содержать только элементы, необходимые
для решения задачи: элементы ввода, вывода результатов, диагностики хода решения.
•• Вася
1. Минимум действий на прогон теста и просмотр результатов.
2. Простота действий: минимум моментов, требующих ментальных операций для служебных действий (чтение сообщений, вызов меню, переходы по каталогам, выбор файлов). Оба пункта можно
оценить по модели GOMS.
3. Единообразие действий, автоматизм (все тесты должны пропускаться по одной схеме).
4. Видимость элементов интерфейса, используемых при тестировании.
Лабораторная работа № 4. Проектирование интерфейса
Файл 681469673
С. 4 из 6
В целом все требования направлены на снижение времени, объема внимания и числа ошибок при
тестировании. Эти три критерия примерно равноценны.
Для этого:
- тесты должны быть заранее подготовлены; удовлетворяются пп. 1 – 3 (альтернатива – при
выявлении каждой ошибки снова набирать данные);
- результаты должны сохраняться для многократного анализа; удовлетворяются пп. 1 – 3
(альтернатива – нельзя вернуться к просмотру ранее полученных результатов);
- должны использоваться средства навигации по файловой системе с максимально простым
способом указания файлов входных и выходных и позволяющие отслеживать формирование
файлов результатов (удовлетворяются пп. 2, 4); имена файлов должны отображать содержимое.
•• Препод
Здесь количество пропускаемых тестов при приеме одной задачи << чем у Васи, но количество
просматриваемых задач значительно.
В итоге тебования к интерфейсу в основном те же.
Выводы
Как видим, требования конечного пользователя и двух других персонажей значительно расходятся.
Поэтому приложение должно иметь два разных интерфейса.
Имеющееся приложение располагает интерфейсом, ориентированным на реализацию. Однако
логика реализации этого интерфейса инвариантна по отношению к форме интерфейса – она задает порядок ввода и анализа данных и получения результата согласно выбранным посылкам. Поэтому разработка имеющегося приложения будет выступать в качестве проекта.
Часть обработки данных останется неизменной; интерфейсная часть модифицируется с учетом
используемых инструментов.
4. Начало сценария для Поля и выбор элементов интерфейса
 Опишем начальную часть сценария согласно шаблонам RUP, приведенным в теме 6 прошлого
курса.
Таблица1.Решение задачи. Главный раздел
Вариант использования
Решение задачи
Актеры
Поль, приложение
Цель
Получение результатов
Краткое описание
Поль запускает приложение и набирает запрашиваемые входные данные. Приложение выдает результаты или диагностику
ошибок.
Тип
Базовый
Ссылки на другие варианты
использования
Нет
В следующей таблице отметим каждое действие его порядковым номером в общей последовательности.
Лабораторная работа № 4. Проектирование интерфейса
Файл 681469673
С. 5 из 6
Таблица 2 Решение задачи. Раздел «Типичный ход событий»
Типичный ход событий
Действия актера
Отклик системы
Элемент интерфейса
1. Поль запускает приложение
2. Приложение предлагает
ввести число элементов
массива
Поле ввода: элемент SpinEdit:
3. Поль вводит число элементов (задает n и переводит курсор в следующее поле ввода)
4. Приложение предлагает
ввести массив
Исключение № 1: n задано неверно
4.а. (см. исключения)
.........
............
- позволяет ограничить диапазон;
- имеет в качестве выхода число
Поле ввода массива: StringGrid.
Число элементов определяется
после ввода n и равно ему.
Таблица 3. Решение задачи. Раздел «Исключения (аномалии)»
Исключения (аномалии)
1. n задано
неверно
Действия актера
Отклик системы
Элемент интерфейса
4.а. Сообщение «n задано
неверно» рядом с полем
ввода n
Элемент label. Изначально невидим. Становится видимым только при ошибке в задании n
Поль вводит правильное число элементов
.........
............
 В самой общей форме этот сценарий содержится в алгоритме уровня 0, описанном на псевдокоде:
алг top_down(n,b,m,a,amax);
арг цел n,m; цел b(n),a(n,m);
рез цел maxmin; цел масс a(m,n);
нач лог nver,mver,bver,aver;{результаты анализа данных}
цел i,j; {текущие индексы}
вывод по обр1;
{ввод, анализ, вывод входных данных}
{проверка n}
ввод(n); вывод (n) по обр2.1;
nver:=истина;
если (n<=0 или n>=50) то {n неверно}
nver:=ложь; вывод по обр 4.1;
кесли;
Как и было сказано выше, этот алгоритм может служить проектом для разработки интерфейса
пользователя.
 Реализация интерфейса в силу особенностей решения (в диалоге) и инструментов отличается:
- возможен многократный ввод n (до ввода правильного значения);
- отпадает необходимость в фиксации правильности/ошибочности n.
5. Частичная реализация интерфейса
См. проект в каталоге InterfForTopDown.
6. Задание
2. Доопределить ключевых персонажей.
3. Описать Use Case диаграмму и сценарии деятельности ключевых персонажей.
4. Начать проектирование элементов интерфейса согласно сценариям. Выбор визуальных элементов, их размещение и функционирование обосновать.
Лабораторная работа № 4. Проектирование интерфейса
Файл 681469673
С. 6 из 6
Ориентироваться на готовое приложение как на проект для разработки недостающих интерфейсов.
7. Материал к работе
1. Представление о Use Case диаграммах. Тема 6 курса «Технология разработки программного
обеспечения», файл tema_6.doc на сайте http://cat.umorist.ru/PO/.
2. Алан Купер. «Психбольница в руках пациентов». Гл. 9 – 11. Электронную версию книги можно посмотреть по адресу http://eusi.narod.ru/lib/cooper/ .
3. Некоторые вопросы для описания пользовательских ролей из кн. Константайна и Локвуд.
Файлы lokvud1.jpg, lokvud2.jpg