Тестирование лучше проводить не автору, а другому человеку.

Объектно-ориентированная технология привносит свои особенности в процесс тестирования систем. Формулируется несколько вопросов, которые необходимо разрешить для успешного проведения тестирования:

• Какая часть унаследованных свойств должна заново тестироваться.

• Когда и как можно проверять информацию о состоянии класса.

• Как можно проверить поведение системы, зависящее от состояния, когда отсутствует единый механизм управление состояниями в программе.

• Как следует тестировать интеграцию классов и какие стратегии тестирования применять.

Решение подобных вопросов выполняется путем разработки новых подходов и модернизации старых, специально для тестирования объектно-ориентированных систем.

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

Основные свойства объектов добавляют новые аспекты тестирования:

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

Наследование ставит вопросы о повторении тестирования наследуемых операций. Допустим операция А принадлежит базовому классу, и она протестирована. Операция В принадлежит производному классу и вызывает операцию А. Должна ли операция А тестироваться повторно?

Полиморфизм приводит к неоднозначности с вызовом операций, которая может быть разрешена только на этапе выполнения. Следовательно, заранее построить и спланировать набор тестов становится просто невозможным.

44. Основные понятия и определения теории тестирования. Подходы к тестированию. Стратегии тестирования. Критерии тестирования.

Тестирование программного обеспечения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.

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

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

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

Критерии «чёрного ящика»:

1. Критерий тестирования функций.

2. Критерий тестирования входных данных.

3. Критерий тестирования выходных данных.

4. Тестирование области допустимых значений.

5. Тестирование длины набора данных (пустой, единичный, минимально возможной длины, выход за пределы длины).

6. Тестирование упорядоченности входных данных.

Стратегия тестирования по принципу Белого ящика - также называемая стратегией тестирования управляемая логикой программы позволяет проверить внутреннюю структуру программы. Исходя из этой стратегии тестировщик получает тестовые данные путем анализа логики работы программы.

Критерии «белого ящика»:

1. Критерий покрытия операторов.

2. Критерий покрытия решений (ветвей).

3. Критерий покрытия путей.

4. Критерий комбинаторного покрытия условий.

5. Критерий минимально грубого тестирования.

45. Способы тестирования программ, состоящих из модулей (блоков).

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

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

Для получения выгоды от модульного тестирования требуется строго следовать технологии тестирования во всём процессе разработки программного обеспечения. Нужно хранить не только записи обо всех проведённых тестах, но и обо всех изменениях исходного кода во всех модулях. С этой целью следует использовать систему контроля версий ПО. Таким образом, если более поздняя версия ПО не проходит тест, который был успешно пройден ранее, будет несложным сверить исходный код вариантов и устранить ошибку. Также необходимо убедиться в неизменном отслеживании и анализе неудачных тестов. Игнорирование этого требования приведёт к лавинообразному увеличению неудачных тестовых результатов.

46. Два критерия полноты тестирования. Причины появления второго критерия.

Существует два подхода к формулированию критериев полноты тестирования: критерии «черного ящика» и критерии «белого ящика». 

• Критерии черного ящика описывают тестирование с точки зрения поставленной задачи внутреннего устройства программы.

• Критерии белого ящика учитывают структуры программы.

Черный ящик

Долгое время основным способом тестирования было тестирование методом "черного ящика" - программе подавались некоторые данные на вход и проверялись результаты, в надежде найти несоответствия. При этом как именно работает программа, считается несущественным. 

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

Белый ящик

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

При тестировании программы критериями белого ящика происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей. Даже для средних по сложности программ число таких путей может достигать десятков тысяч.

Критерии тестирования

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

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

47. Отладка программы. Программные ошибки. Категории программных ошибок.

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

Программные ошибки – ошибку в программе или системе, которая выдает неожиданный или неправильный результат. 

Категории программных ошибок:

1. Ошибки анализа (неполное обследование, неверное решение задачи). Связаны с неполным учётом ситуаций.

2. Ошибки общего характера из-за недостаточного понимания программистом особенностей языка.

3. Ошибки физического характера (пропуск оператора неверный ввод данных).

4. Синтаксические ошибки (неопределённые переменные) – всякое нарушение требований языка программирования.

48. Методы отладки программного обеспечения

Все методы можно разделить на две группы:

1. Методы грубой силы – полного перебора.

• Метод ветвей и границ

• Распараллеливание вычислений

• Радужные таблицы

Недостатки: длительное время исполнения, изменение программы при отладке, метод проб и ошибок.

2. отладка с использованием автоматических средств. Достоинство: в программу не нужно вносить никаких изменений.

• метод индукции;

• метод дедукции;

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

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

49. Критерии черного ящика.

"Чёрный ящик" - тестирование функционального поведения программы с точки зрения внешнего мира (текст программы не используется).

Методы стратегии чёрного ящика:

1. Эквивалентное разбиение.

2. Анализ граничных значений.

3. Анализ причинно-следственных связей.

4. Предположение об ошибке.

Существуют следующие критерии черного ящика:

1. Тестирование функций.

2. Тестирование классов входных данных.

3. Тестирование классов выходных данных.

4. Тестирование области допустимых значений. Если ОДЗ – простое перечисление, необходимо проверить, как программа воспринимает верные и неверные значения.

5. Тестирование длины набора данных (пустой, единичный, минимально возможной длины, выход за пределы длины).

6. Тестирование упорядоченности входных данных (сортировка, экстремум).

50. Критерии белого ящика

"Белый ящик" - тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка, на котором она писалась.

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

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

2. Критерий покрытия решений (ветвей). Необходимо подобрать такой набор тестов, чтобы каждая ветвь была выполнена хотя бы один раз.

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

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

5. Критерий минимально грубого тестирования. Критерий, усиленный дополнительными условиями при проверке циклов.

51. Минимально грубое тестирование

52. Модели надежности программных систем

Основным средством определения показателей надёжности являются модели надёжности, под которыми понимается математическая модель, построенная для оценки зависимости надёжности от заранее известных или оцененных в ходе создания параметров программной системы.

Все модели надёжности можно классифицировать по тому, какой из следующих процессов следует использовать:

1. Предсказание – определение количественных показателей надёжности, исходя из будущей программной системы.

2. Измерение, основанное на анализе данных на каком-то интервале между отказами.

3. Оценивание.

На основе этих процессов выделяют эмпирические и аналитические модели надёжности.

Эмпирические базируются на анализе структурных особенностей программы (число модулей, количество циклов и т.д.).

Аналитические модели дают возможность рассчитывать показатели надёжности. Они делятся на две группы:

1. Статистические – учитывают только зависимость количества ошибок от числа тестовых прогонов или от характеристик входных данных.

2. Динамические – появление отказов рассматривается во времени.

Аналитическое моделирование включает четыре шага:

1. Определение предположений, связанных с процедурой тестирования программной системы.

2. Разработка или выбор аналитической модели, основанной на предположениях, выдвинутых в первом шаге.

3. Выбор параметров моделей с использование полученных данных.

4. Расчёт количественных показателей надёжности.

53. Измерения и оценка качества программного обеспечения

54. Динамическая модель Шумана

Исходные данные для этой модели собираются в процессе тестирования программной системы в течение фиксированного времени или в течение случайных временных интервалов.

Интервал – стадия, на которой выполняется последовательность тестов и фиксируется некоторое количество ошибок. Основные условия:

• общее число команд в программе на машинном языке постоянно;

• в начале компоновочных испытаний число ошибок равно некоторой постоянной величине, и по мере исправления ошибок их становится меньше. В ходе испытаний программы новые ошибки не вносятся;

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

• интенсивность отказов программы пропорциональна числу остаточных ошибок.

Использова­ние модели Шумана предполагает, что тестирование проводится в несколько этапов, каждый из которых представляет собой выполнение программы на полном комплекте разработанных тестов. Ошибки выявляются, регистрируются, но не исправляются.

По завер­шении этапа на основе собранных данных о поведении ПС на очередном этапе тестирования может быть использована модель Шумана для расчета количественных показателей надежности. После этого исправляются ошибки, обнаруженные на предыдущем этапе, при необходимости корректируются тестовые наборы, затем происходит повторное тестирование.

56. Статические модели надежности

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

Модель Миллса.

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

Тестируя программу в течение некоторого времени, собирают статистику об ошибках. В момент оценки надежности по протоколу искусственных ошибок все ошибки делятся на собственные и искусственные. Соотношение

Дает возможность оценить N – первоначальное число ошибок в программе. В данном соотношении, которое называется формулой Миллса, S – количество искусственно внесенных ошибок, n – число найденных собственных ошибок, V – число обнаруженных к моменту оценки искусственных ошибок.

Вторая часть модели связана с проверкой гипотезы выражения и тестирования N.

Рассмотрим случай, когда программа содержит К собственных ошибок и внесем S рассеянных ошибок. Будем тестировать программу до тех пор, пока не обнаружим все рассеянные ошибки. В то же время количество обнаруженных исходных ошибок накапливается и запоминается n. Предполагаем, что изначально было N=n ошибок. Далее вычисляется оценка надежности модели: 

(11)

как вероятность того, что в программе содержится K ошибок.

Величина С является мерой доверия к модели и показывает вероятность того, насколько правильно найдено значение N. Эти два связанных между собой по смыслу соотношения образуют полезную модель ошибок: первое предсказывает возможное число первоначально имевшихся в программе ошибок, а второе используется для установления доверительного уровня прогноза.

Формула для расчета С в случае, когда обнаружены не все искусственно рассеянные ошибки, модифицирована таким образом, что оценка может быть выполнена после обнаружения v (vS) рассеянных ошибок:

      (12)

где числитель и знаменатель формулы при n  К являются биноминальными коэффициентами.

Простая интуитивная модель.

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

Пусть первая группа обнаружила n₁ ошибок, вторая n₂ , n₁₂ - это число ошибок, обнаруженных как первой, так и второй группой.

Обозначим через N неизвестное количество ошибок, присутствующих в программе до начала тестирования. Тогда можно эффективность тестирования каждой из групп определить как

.

Эффективность тестирования можно интерпретировать как вероятность того, что ошибка будет обнаружена. Таким образом, можно считать, что первая группа обнаруживает ошибку в программе с вероятностью , вторая - с вероятностью . Тогда вероятность p₁₂ того, что ошибка будет обнаружена обеими группами, можно принять равной . С другой стороны, так как группы действуют независимо друг от друга, то р₁₂ = р₁р₂. Получаем:

Отсюда получаем оценку первоначального числа ошибок программы:

.

57. Модель Миллса

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

Тестируя программу в течение некоторого времени, собирают статистику об ошибках. В момент оценки надежности по протоколу искусственных ошибок все ошибки делятся на собственные и искусственные. Соотношение

Дает возможность оценить N – первоначальное число ошибок в программе. В данном соотношении, которое называется формулой Миллса, S – количество искусственно внесенных ошибок, n – число найденных собственных ошибок, V – число обнаруженных к моменту оценки искусственных ошибок.

Вторая часть модели связана с проверкой гипотезы выражения и тестирования N.

Рассмотрим случай, когда программа содержит К собственных ошибок и внесем S рассеянных ошибок. Будем тестировать программу до тех пор, пока не обнаружим все рассеянные ошибки. В то же время количество обнаруженных исходных ошибок накапливается и запоминается n. Предполагаем, что изначально было N=n ошибок. Далее вычисляется оценка надежности модели: 

как вероятность того, что в программе содержится K ошибок.

Величина С является мерой доверия к модели и показывает вероятность того, насколько правильно найдено значение N. Эти два связанных между собой по смыслу соотношения образуют полезную модель ошибок: первое предсказывает возможное число первоначально имевшихся в программе ошибок, а второе используется для установления доверительного уровня прогноза.

Формула для расчета С в случае, когда обнаружены не все искусственно рассеянные ошибки, модифицирована таким образом, что оценка может быть выполнена после обнаружения v (vS) рассеянных ошибок:

      где числитель и знаменатель формулы при n  К являются биноминальными коэффициентами.

58. Простая интуитивная модель

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

Пусть первая группа обнаружила n₁ ошибок, вторая n₂ , n₁₂ - это число ошибок, обнаруженных как первой, так и второй группой.

Обозначим через N неизвестное количество ошибок, присутствующих в программе до начала тестирования. Тогда можно эффективность тестирования каждой из групп определить как

.

Эффективность тестирования можно интерпретировать как вероятность того, что ошибка будет обнаружена. Таким образом, можно считать, что первая группа обнаруживает ошибку в программе с вероятностью , вторая - с вероятностью . Тогда вероятность p₁₂ того, что ошибка будет обнаружена обеими группами, можно принять равной . С другой стороны, так как группы действуют независимо друг от друга, то р₁₂ = р₁р₂. Получаем:

Отсюда получаем оценку первоначального числа ошибок программы:

.

59. Модель Коркорэна

Модель Коркорэна относится к статическим моделям надежности ПС, так как в ней не используются параметры времени тестирования и учитывается только результат N испытаний, в которых выявлено N₁ ошибок i-го типа. Модель использует изменяющиеся вероятности отказов для различных типов ошибок.

Применение модели предполагает знание следующих ее показателей:

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

• в модели используются такие параметры, как результат только N испытаний, в которых наблюдается N_i ошибок i-го типа;

• выявление в ходе N испытаний ошибки i-го типа появляется с вероятностью а_i.

Показатель уровня надежности R вычисляют по следующей формуле:

где N₀ - число безотказных (или безуспешных) испытаний, выполненных в серии из N испытаний, k - известное число типов ошибок, a_i — вероятность выявления при тестировании ошибки i-го типа,

Y_i - вероятность появления ошибок, при N_i > 0, Y_i = a_i, при N_i = 0, Y_i = 0.

60. Типы пользовательских интерфейсов и этапы их разработки

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

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

   • Примитивные – интерфейсы, которые организуют взаимодействие пользователя в консольном варианте.

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

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

2. Объектно-ориентированные интерфейсы предоставляют пользователю возможность напрямую взаимодействовать с каждым объектом и инициировать выполнение операций, в процессе которых взаимодействуют несколько объектов.

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

Этапы разработки пользовательского интерфейса:

1. Постановка задачи – определение типа интерфейса и общих требований к нему.

2. Анализ требований и определение спецификаций – определение сценариев использования и пользовательской модели интерфейса.

3. Проектирование – проектирование диалогов и их реализация в виде процессов ввода-вывода.

4. Реализация – программирование и тестирование интерфейсных процессов.

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

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

Критерии оценки интерфейсов пользователя:

1. Простота освоения.

2. Запоминание операций системы.

3. Высокая скорость достижения результатов при использовании системы.

4. Субъективная удовлетворённость при работе с системой.

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

62. Пользовательские интерфейсы прямого манипулирования и их проектирование

Интерфейсы данного типа на внешнем уровне используют директивную форму диалога: ввод команды осуществляется при выполнении определенных действий с пиктограммой объекта мышью. Основными элементами этих интерфейсов являются: метафоры, объекты, представления объектов и технология Drag and Drop («перетащил и бросил»).

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

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

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

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

Объекты. Существует три основных типа объектов интерфейсов прямого манипулирования: объекты-данные, объекты-контейнеры и объекты-устройства.

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

Объекты-контейнеры могут манипулировать своими внутренними объектами, в том числе и другими контейнерами, например, копировать их или сортировать в любом порядке.

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

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

Таким образом, каждому объекту соответствует, по крайней мере, одно окно. В исходном состоянии это окно представлено пиктограммой, но при необходимости его можно раскрыть и выполнить требуемые операции, например настройки объекта. Окно объекта в раскрытом состоянии может содержать меню и панели инструментов. Пиктограмме же должно соответствовать контекстное меню, содержащее перечень операций над объектом.

Технология Drag and Drop. Технология Drag and Drop («перетащил и бросил») определяет основные принципы прямого манипулирования, описанные в руководстве по разработке пользовательских интерфейсов фирмы IBM (CUA - Common User Access):

• результат перемещения объекта должен соответствовать ожиданиям пользователя;

• пользователи не должны неожиданно терять информацию;

• пользователь должен иметь возможность отменить неправильное действие.

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

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

• анализ объектов, определение их типов я представлений, а также перечня операций с этими объектами;

• уточнение взаимодействия объектов и построение матрицы прямого манипулирования;

• определение визуальных представлений объектов;

• разработка меню окон объектов и контекстных меню;

• создание прототипа интерфейса;

• тестирование на удобство использования.

63. Классификации диалогов и общие принципы их разработки

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

Типы диалогов. Тип диалога определяет, кто из обеседников управляет процессом обмена информации.

Различают два типа диалогов:

• управляемый программой;

• управляемый пользователем.

Диалог, управляемый программой, предусматривает наличие формализованного жёсткого сценария, заложенного в ПО, и должен сопровождаться большим количеством подсказок.

Диалог, управляемый пользователем, подразумевает, что сценарий диалога зависит от самого пользователя.

Формы диалога. Разделяют три формы диалога:

1. Фразовая – задаются в определённой форме вопросы.

Достоинства: свободное общение с системой.

Недостатки:

• большие затраты ресурсов;

• нет гарантии однозначной интерпретации ответа;

• необходимость ввода длинных фраз.