калашник Борис Борисович разработка среды поддержки сценариев для генерации графических текстов, дипломная работа (стр. 3 из 7)

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

Интерфейс нашей системы строится как многоуровневый. Он будет иметь два уровня: описание текстом, описание картинками и видео. Текст будет описывать нужные нам действия. Определения, которые могут быть незнакомыми пользователю, нужно объяснить. Самым удобным способом будет показ внешнего вида этой детали и текстовое описание его предназначения. Для реализации сказанного поставим рядом с незнакомым словом свернутый текст в виде «+», при нажатии на него будет развернута область около этого слова, где и будет присутствовать описательная информация, не перекрывая основной текст. Таким образом, пользователь будет знать, как выглядит и зачем нужна любая деталь. Ниже основного теста будут располагаться картинки. В одну отдельную картинку можно заложить основную мысль какого-либо конкретного действия, изобразив лишь его основную идею. Последовательность картинок позволяет показать пользователю последовательность действий, которые ему нужно совершить, чтобы прийти к какому-то определенному результату. Таким образом, в последовательности картинок будут отображены основные идеи действий, и, как следствие, будет показана наглядность происходящего. Присоединение к картинкам видео улучшает понимание информации пользователем. Таким образом, прослеживается определенная связь между манга и аниме.

Несмотря на всё интерфейс будет очень прост и соответственно интуитивно понятен.

Для реализации всего проекта мы предлагаем следующий подход. Работа будет осуществляться в два этапа. Первый – разработка сценария для генерации нужных нам файлов - текстов, картинок, видео. Второй – разработка методов их реализации. Первую часть буду выполнять я. Вторую часть будет выполнять мой коллега, Кожевин Александр. Моя задача заключается в следующем: представить и написать сценарий как программу, генерирующую наборы файлов системы по сценарию, и выдать нужные нам файлы, которые в свою очередь будут использоваться в работе Александра. В результате будет web-страница, описывающая нужную информацию.

4.СЦЕНАРИЙ

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

Что такое сценарий? Само понятие сценария возникло вместе с появлением кино и телефильма. Сценарий - литературное произведение, написанное как основа для постановки кино или телефильма. Сценарий в кинематографе, как правило, напоминает пьесу и подробно описывает каждую сцену и диалоги персонажей. Отталкиваясь от этого понятия, проведём аналогию с нашим проектом. Наш результат – информационная система. Также и в киноиндустрии, конечным результатом является “фильм”. Разумеется, сценарий описывает каждую сцену и порядок сцен. Соответственно для нас - это порядок вывода информации (что за чем идёт) и её описание. Можно сделать вывод, что сценарий – текст, описывающий идею генерации данных (файлов) информационной системы, с правильной организацией вывода нужной информации.

4.1.СЦЕНАРИЙ-ПРОГРАММА

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

Программа должна автоматически сгенерировать из имеющегося множества файлов нужный нам набор, то есть сделать правильный выбор нужной информации и вывести её. Нельзя не упомянуть об уже существующих языках сценариев. Язык сценариев(англ. scripting language, в русскоязычной литературе принято название язык сценариев) — язык программирования, разработанный для записи сценариев, последовательностей операций, которые пользователь может выполнять на компьютере. Примером таких языков служит Perl. Языки сценариев удобны в следующих случаях:

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

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

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

Мы же в свою очередь будем использовать язык программирования C#, так как в нашем случае плюсы языков сценария не важны и будут почти не заметны.

Перейдём к этапу проектирования нашего сценария. Наша система подразумевает, как это уже говорилось, какое-то количество действий. Итак, каждое действие имеет описательную (текстовый файл) и показательную (картинки и видео файлы) части. Также, каждое действие имеет зависимость от ряда других действий. Нужно найти и вывести все части нужного нам действия и все части действий, которые для него нужны. Например, для выполнения действия «2» нужно выполнить действия «1» и «3», при этом действие «2» имеет описательную часть в виде текстового файла и показательную часть в виде четырёх картинок и одного видео, в свою очередь действие «1» имеет также текстовый файл, три картинки и одно видео, а действие «3» имеет текстовый файл, шесть картинок и два видео. Наша программа-сценарий должна сгенерировать набор файлов, состоящий из трёх текстовых файлов, тринадцати картинок и четырёх видео файлов.

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

4.1.СЦЕНАРИЙ КАК ГРАФ

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

Рассмотрим пример.

Действие (вершина) «1» не зависит ни от одного действия; действие «2» зависит от действия «1»; действие «3» не зависит ни от одного действия; действие «4» зависит от действия «1»; действие «5» зависит от действий «1», «3» и «4»; действие «6» зависит от действий «1», «2» и «3».

Конечно же, надо определить, как будет осуществляться поиск всех зависимых действий по заданному действию. В этом нам поможет поиск в глубину. Поиск в глубину - один из методов обхода графа. Алгоритм поиска описывается следующим образом: для каждой не пройденной вершины необходимо найти все не пройденные смежные вершины и повторить поиск для них. Таким образом, с помощью поиска в глубину, мы, начиная алгоритм от заданной вершины, обойдём все вершины (действия), от которых будет зависеть наше действие. Стоит отметить, что при задании зависимостей некоторые из них можно не задавать, примером тому будут зависимости между действиями «5» и «1», «6» и «1» (возвращаясь к нашему примеру). Это происходит из-за того, что действие «5» зависит от действия «4», которое в свою очередь зависит от действия «1». То есть поиск в глубину в любом случае дойдёт до действия «1». Соответственно возникает вопрос – удобно ли это будет при задании зависимостей? Переформулируем вопрос - хочется ли нам продумывать с самого начала все зависимости? Нет, так как вся наша система может содержать очень много действий, а это приведёт к большой затрате сил, да и просто проще.

Раз уж мы коснулись вопроса задания зависимостей между действиями, надо чётко определиться, как, и в какой форме, они будет задаваться для программы. Зависимости будем задавать, аналогично с графом, следующим образом: в текстовом файле, с именем actions.txt, самая верхняя строка будет содержать количество действий; первая строка после верхней будет содержать номера действий, от которых будет зависеть первое действие; вторая строка после верхней будет содержать номера действий, от которых будет зависеть второе действие; и т.д. Ясно, что если количество всех действий системы будет N, то количество строк в файле actions.txt будет N+1. Рассмотрим пример, описывающий ранее приведённый пример.