 |
|
Б-42 Классификации диалогов и общие принципы их разработки. Типы диалогов, их достоинства и недостатки.
Диалог - это процесс обмена информацией между пользователем и программной системой, осуществляемый через интерактивный терминал и по определенным правилам.
Различают тип диалога и его форму.
Типы диалога. Тип диалога определяет, кто из «собеседников» управляет процессом обмена информацией. Соответственно различают два типа диалога: управляемые программой и управляемые пользователем.
Диалог, управляемый программой, предусматривает наличие жесткого, линейного или древовидного, т. е. включающего возможные альтернативные варианты, сценария диалога, заложенного в программное обеспечение. Такой диалог обычно сопровождают большим количеством подсказок, которые уточняют, какую информацию необходимо вводить на каждом шаге.
Диалог, управляемый пользователем, подразумевает, что сценарий диалога зависит от пользователя, который применяет систему для выполнения
необходимых ему операций. При этом система обеспечивает возможность реализации различных пользовательских сценариев.
Формы диалога. Никакой диалог невозможен, если не существует языка, понятного «собеседникам». Описание языка, на котором ведется диалог, включает определение его синтаксиса - правил, определяющих допустимые конструкции (слова, предложения) языка или его форму, и семантики - правил, определяющих смысл синтаксически корректных конструкций языка или его содержание. В зависимости от вида используемых в конкретном случае синтаксиса и семантики различают три формы диалога:
• фразовую,
• директивную,
• табличную.
Фразовая форма предполагает «общение» с пользователем на естественном языке или его подмножестве. Содержание диалога в данной форме составляют повелительные, повествовательные и вопросительные предложения и ответы на вопросы. Общение может осуществляться в свободном формате, но возможна и фиксация отдельных фраз.
Организация диалога на естественном языке на современном уровне -задача не решенная, так как естественный язык крайне сложен и пока не удается в достаточной степени формализовать его синтаксис и семантику.
Чаще всего используют диалоги, предполагающие односложные ответы, например:
Программа: Введите свой возраст (полных лет): Пользователь: 48.
В этом случае программа содержит ограниченное описание как синтаксиса, так и семантики используемого ограниченно-естественного языка. Для данного примера достаточно определить синтаксис понятия «целое положительное число» и наложить ограничение на значение числа.
Однако существует некоторый опыт создания интерфейсов на базе ограниченного подмножества предложений естественного языка в основном для интеллектуальных систем. Синтаксис и семантика языков диалога, реализуемых в таких интерфейсах, достаточно сложны.
При обработке фраз в этих случаях оперируют понятием словоформа. Словоформа - отрезок текста между двумя соседними пробелами или знаками препинания. Обработка словоформ вне связи с контекстом называется морфологическим анализом.
Выделяют два метода морфологического анализа:
•декларативный - предполагает, что в словаре находятся все возможные
словоформы каждого слова, тогда анализ сводится к поиску словоформы в
словаре. Данный метод обеспечивает возможность обработки сообщений,
состоящих из строчных и прописных букв в произвольной комбинации, при
чем как латинского, так и русского или других алфавитов;
•процедурный - предполагает выделение в текущей словоформе основы, которую затем идентифицируют.
После распознавания словоформ осуществляют синтаксический анализ сообщения, по результатам которого определяют его синтаксическую структуру, т. е. выполняют разбор предложения.
Далее выполняют семантический анализ, т. е. определяют смысловые отношения между словоформами. При этом выявляют главные предикаты, определяющие смысл предложения.
Таким образом, интерфейс, реализующий фразовую форму диалога, должен: преобразовывать сообщения из естественно-языковой формы в форму внутреннего представления и обратно, выполнять анализ и синтез сообщений пользователя и системы, отслеживать и запоминать пройденную часть диалога.
Основными недостатками фразовой формы при использовании подмножества естественного языка являются:
•большие затраты ресурсов;
•отсутствие гарантии однозначной интерпретации формулировок;
•необходимость ввода длинных грамматически правильных фраз.
Основное достоинство фразовой формы состоит в относительно свободном общении с системой.
Директивная форма предполагает использование команд (директив) специально разработанного формального языка. Командой в этом случае называют предложение этого языка, описывающее комбинированные данные, которые включают идентификатор инициируемого процесса и, при необходимости, данные для него.
Команду можно вводить:
•в виде строки текста, специально разработанного формата, например,
команды MS DOS, которые вводятся в командной строке;
•нажатием некоторой комбинации клавиш клавиатуры, например, комбинации «быстрого доступа» современных Windows-приложений;
•посредством манипулирования мышью, например, «перетаскиванием»
пиктограмм;
•комбинацией второго и третьего способов.
Основными достоинствами директивной формы являются:
•сравнительно небольшой объем вводимой информации;
•гибкость - возможности выбора операции в данном случае ограничены только набором допустимых команд;
•ориентация на диалог, управляемый пользователем;
•использование минимальной области экрана или не использование ее
вообще;
•возможность совмещения с другими формами.
Недостатки директивной формы:
•практическое отсутствие подсказок на экране, что требует запоминания вводимых команд и их синтаксиса;
•почти полное отсутствие обратной связи о состоянии инициированных процессов;
•необходимость навыков ввода текстовой информации или манипуляций мышью;
•отсутствие возможности настройки пользователем.
Исследования показали, что директивная форма удобна для пользователя-профессионала, который обычно быстро запоминает синтаксис часто используемых команды или комбинации клавиш. Основные достоинства формы (гибкость и хорошие временные характеристики) проявляются в этом случае особенно ярко.
Табличная форма предполагает, что пользователь выбирает ответ из предложенных программой. Язык диалога для табличной формы имеет простейший синтаксис и однозначную семантику, что достаточно легко реализовать. Удобна эта форма и для пользователя, так как выбрать всегда проще, чем вспомнить, что особенно существенно для пользователя-непрофессионала или пользователя, редко использующего конкретное программное обеспечение. Однако применение табличной формы возможно не всегда: ее можно использовать только, если множество возможных ответов на конкретный вопрос конечно. Причем, если количество возможных ответов велико (более 20), то применение табличной формы может оказаться нецелесообразным.
Достоинствами табличной формы являются:
•наличие подсказки, что уменьшает нагрузку на память пользователя,
так как данная форма ориентирована не на запоминание, а на узнавание;
•сокращение количества ошибок ввода: пользователь не вводит информацию, а указывает на нее;
•сокращение времени обучения пользователя;
•возможность совмещения с другими формами;
•в некоторых случаях возможность настройки пользователем.
К недостаткам данной формы относят:
•необходимость наличия навыков навигации по экрану;
•использование сравнительно большой площади экрана для изображения визуальных компонентов;
•интенсивное использование ресурсов компьютера, связанное с необходимостью постоянного обновления информации на экране.
Следует иметь в виду, что типы и формы диалога выбирают независимо друг от друга: любая форма применима для обоих типов диалогов (рис. 8.10). Однако фразовая форма, которая используется в диалоге, управляемом пользователем, как правило, предполагает более сложные синтаксис и семантику языка диалога, так как программа должна «понимать» пользователя.
Рис. 8.10. Соответствие типов диалогов и его форм
Сложное программное обеспечение обычно взаимодействует с пользователем посредством диалогов различных типов и форм в зависимости от решаемых задач. Причем, помимо диалогов, происходящих в процессе нормальной работы программного обеспечения и называемых синхронными, предусматривают диалоги, возникающие по инициативе системы или пользователя при нарушении сценария нормального процесса. Такие диалоги называют асинхронными. Обычно их используют для выдачи экстренных сообщений от системы или пользователя.
Разработка диалогов. Процесс проектирования и реализации диалогов можно разделить на следующие стадии:
•определение множества необходимых диалогов, их основных сообщений и возможных сценариев - проектирование абстрактных диалогов;
•определение типа и формы каждого диалога, а также синтаксиса и семантики используемых языков - проектирование конкретных диалогов;
•выбор основных и дополнительных устройств и проектирование процессов ввода-вывода для каждого диалога, а также уточнение передаваемых
сообщений - проектирование технических диалогов.
В основу абстрактных диалогов должна закладываться идеология технологического процесса, для автоматизации которого предназначается программный продукт. Именно анализируя составляющие автоматизируемого технологического процесса, разработчик определяет сценарии диалогов (см. § 6.2), которые должны быть предусмотрены в программном обеспечении.
Кроме сценариев, при проектировании абстрактных диалогов используют диаграммы состояний интерфейса или графы диалога.
Граф диалога - ориентированный взвешенный граф, каждой вершине которого сопоставлена конкретная картинка на экране (кадр) или определенное состояние диалога, характеризующееся набором доступных пользователю действий. Дуги, исходящие из вершин, показывают возможные изменения состояний при выполнении пользователем указанных действий. В качестве весов дуг указывают условия переходов из состояния в состояние и операции, выполняемые во время перехода.
Таким образом, каждый маршрут на графе соответствует возможному варианту диалога. Причем представление диалога в виде графа в зависимости от стадии разработки может выполняться с разной степенью детализации. По сути граф диалога - это граф состояний конечного автомата, моделирующего поведение программного обеспечения при воздействиях пользователя. Для представления таких графов уже были введены две нотации: нотация диаграмм состояний структурного подхода к разработке (см. рис. 4.3) и нотация диаграмм состояний UML (см. рис. 7.17). Причем нотация UML является более мощной, так как позволяет использовать обобщенные состояния. Поэтому, чтобы не вводить новую нотацию для представления графа диалога, будем использовать обозначения UML.
------------------------------------------------------------------------------------------------------Б-43 Тестирование программного обеспечения. Структурное тестирование. Понятие тестирование ПО, суть структурного тестирования, критерии формирования тестовых наборов.
Тестирование - очень важный и трудоемкий этап процесса разработки ПО, т.к. правильное тестир-е позволяет выявить подавляющее большинство ошибок, допущенных при составлении программ. Тестирование - это процесс вып-ия программы, целью кот. явл. выявление ошибок. Никакое тестир-е не может доказать отсутствие ошибок в хоть сколько-нибудь сложном ПО.
Процесс разработки ПО, в том виде, как он опр-ся в современной модели ЖЦ ПО, предполагает 3 стадии тестирования:
• автономное тестирование компонентов ПО;
• комплексное тестирование разрабатываемого ПО;
• системное или оценочное тестирование на соответствие основным критериям качества.
Сущ. 2 различных подхода к формированию тестовых наборов: структурный и функциональный.
Структурный подход базируется на том, что известна структура тестируемого ПО, в том числе его алгоритмы («стеклянный ящик»). В этом случае тесты строят так, чтобы проверить правильность реализации заданной логики в коде программы. Структурное тестирование наз. также тестир-ем по «маршрутам», т.к. в этом случае тестовые наборы формируют путем анализа маршрутов, предусмотренных алгоритмом. Под маршрутами при этом понимают послед-ти операторов программы, кот. вып-ся при конкретном варианте исходных данных.В основе стр-ного тестир-я лежит концепция максимально полного тестир-я всех маршрутов программы. Так, если алгоритм программы включает ветвление, то при одном наборе исходных данных м.б. вып-на послед-ть операторов, реализующая действия, кот. предусматривает одна ветвь, а при втором - другая. Прог-ма проверена полностью, если с пом. тестов удается осущ-ть вып-ие прог-мы по всем возможным маршрутам передач упр-ния. Стр-рный подход к тестир-ию имеет ряд недостатков. Так тестовые наборы, построенные по данной стратегии:не обнаруживают пропущенных маршрутов;не обнаруживают ошибок, зависящих от обрабатываемых данных, не дают гарантии, что программа правильна.
Функциональный подход основывается на том, что стр-ра ПО не известна («черный ящик»). В этом случае тесты строят, опираясь на функц-ные спецификации. Этот подход наз. также подходом, управляемым данными, так как при его исп-нии тесты строят на базе различных способов декомпозиции множества данных. Одним из способов проверки программ является тестирование с управлением по данным или по принципу «черного ящика». В этом случае программа рассматривается как «черный ящик», и целью тестирования явл. выяснение обстоятельств, в кот. поведение программы не соответствует спецификации. Для обнаружения всех ошибок в прог-ме, исп-я упр-ние по данным, необх-мо вып-ть исчерпывающее тестир-е, т. е. тестир-е на всех возможных наборах данных. Для тех же программ, где исполнение команды зависит от предшествующих ей событий, необх-мо проверить и все возможные послед-ти. Очевидно, что проведение исчерпывающего тестир-я для подавляющего большинства случаев невозможно. Поэтому вып-ют «разумное» или «приемлемое» тестир-ние, кот. ограничивается прогонами прог-мы на небольшом подмножестве всех возможных входных данных. Этот вариант не дает гарантии отсутствия отклонений от спецификаций.
Инспекции исходного текста.Инспекции исходного текста представляют собой набор процедур и приемов обнаружения ошибок при изучении текста группой специалистов. В эту группу входят: автор программы, проектировщик, специалист по тестированию и координатор - компетентный программист, но не автор программы. Общая процедура инспекции предполагает след. операции:
• участникам группы заранее выдается листинг программы и спецификация на нее;
• программист рассказывает о логике работы программы и отвечает на вопросы инспекторов;
• программа анализируется по списку вопросов для выявления исторически сложившихся общих ошибок программирования.
• Список вопросов для инспекций исходного текста зависит, как от исп-мого языка программирования, так и от специфики разрабатываемого ПО.
Кроме непосредственного обнаружения ошибок, рез-ты инспекции позволяют программисту увидеть др. сделанные им ошибки, получить возможность оценить свой стиль программирования, выбор алгоритмов и методов тестирования. Инспекция явл. способом раннего выявления частей программы, с большей вероятностью содержащих ошибки, что позволяет при тестировании уделить внимание именно этим частям.
Сквозной контроль.Сквозной просмотр, как и инспекция, представляет собой набор способов обнаружения ошибок, осущ-мых группой лиц, просматривающих текст программы, но отличается процедурой и методами обнаружения ошибок. Группа по вып-ию сквозного контроля состоит из трех-пяти человек: председатель или координатор, секретарь, фиксирующий все ошибки, специалист по тестированию, программист и независимый эксперт. Сквозной просмотр предполагает вып-ние след. процедур:
• участникам группы заранее выдают листинг программы и спецификацию на нее;
• участникам заседания предлагают несколько тестов;
• участники заседания мысленно вып-ют каждый тест в соответствии с логикой прог-мы, при этом состояние программы (значения переменных) отслеживается на бумаге или доске;
• при необх-ти программисту задают вопросы о логике проектирования и принятых допущениях.
В большинстве сквозных просмотров при вып-ии самих тестов находят меньше ошибок, чем при опросе программиста.
Эффективный прием оценки детальных внешних спецификаций – подготовить тесты и затем воспользоваться детальными внешними спецификациями для имитации поведения системы. Для проверки отдельных внешних ф-ций д.б. вып-ны след. действия. Кто-то (не автор спецификаций) должен сначала построить “тесты на бумаге” для этой функции, т.е. список конкретных входных данных (допустимых и недопустимых). Вместе с автором спецификаций затем имитируют ввод этих данных в cистему, исп-я спецификации как описание поведения системы. Если оказывается, что спецификации описывают вых. данные или преобразование для какого-то набора вх. данных недостаточно полно и правильно, это означает, что обнаружена ошибка. Цель всякого такого сеанса сквозного контроля – обнаружить ошибки, но не исправлять их сразу.
Исп-я данный прием тестир-я, были протестированы запросы осущ-мые к БД созданной системы. Для этого на вход подавались различные запросы к БД. В рез-те проведения теста было зафиксировано, что корректные запросы обрабатываются БД согласно предполагаемому рез-ту. При попытке осущ-ть некорректный запрос к БД не всегда выдаются сообщения об ошибках, либо не указано какие действия необх-мо предпринять для правильной работы системы.
Тестирование ПО- процесс, помогающий опр-ть корректность, полноту и кач-тво разработанного ПО. Вместе с тем, тестир-е никогда не может полностью установить корректность прог-мы. Только процесс формальной проверки может док-ть, что дефекты отсутствуют. Формальная верификация — док-во с пом. формальных методов правильности или неправильности системы в соответствии с формальным описанием св-в системы.Верификация - проверка; способ обоснования (подтверждения) каких-либо теоретических положений путем их сопоставления с опытными данными.