|
| |
 |
Главная » Мануалы 1 ... 10 11 12 13 14 15 16 ... 32  (а) Граф потока данных смешанного тип9 CONTROL  PUT A GET в GET C PUT C PUT 0 (6) Структурный граф в виде совокупности пакетов. Рис. 4.9. Смешанное управление последовательным потоком данных.
 (э) Поскольку задачи являются автономными, управление в параллельной системе может носить неявный характер независимо от того, в каком направлении взаимодействуют отдельные задачи.
 (S) в параллельных системах функции управления могут присутствовать также в явной форме . Рис. 4.10. Параллельные структурные графы для последовательного потока данных, схемы. Способ организации связи между парами задач может, следовательно, определяться требованиями конкретного прило-жения. Конечно, отдельный блок управления может быть сделан в параллельной системе точно таким же, как и в последовательной. Это показано на рис. 4.10,6, где функции модулей F1, F2 и F3 реализуются подчиненными задачами. В этом примере иллюстрируются два подхода к управлению подчиненными задачами: 1, Подчиненные задачи обращаются к управляющей с запросом на получение каких-либо данных для преобразования. 2. Управляющая задача обращается к подчиненным с требованием выполнения конкретного преобразования. Первый подход обычно используется тогда, когда желатель* но выполнять каждую функцию преобразования параллельно с другими аналогичными функциями. В этом случае преобразованные данные могут возвращаться от подчиненной задачи к управляющей с помощью операции вызова, содержащей запрос на выполнение очередной работы. Второй подход состоит в том, что управляющая задача обращается к подчиненным. Если управляющая задача ожидает заверщения преобразования, то   Рис. 4.11. Разработка структуры по принципу от границ - внутрь для многоканальных потоков данных. В логическом плане это ничем не отличается от вызова процедур в последовательной системе. Разумеется, возможно значительно большее разнообразие архитектур параллельных систем, чем было показано на рис. 4.10. Однако мы отложим дальнейшее обсуждение этих вариантов до последующих примеров. Функционирование вложенных систем вряд ли всегда характеризуется только одинаковым потоком данных. Более вероятен многоканальный поток типа показанного на рис. 4.11, где представлены два первых шага процедуры построения графа многоканального потока данных: первый шаг состоит в идентификации потоков данных через границы системы; второй шаг - это разработка графа внутренних потоков данных, основанная на стратегии от границ - внутрь . Подробнее мы бу* дем говорить об этом при рассмотрении примеров. 4.2.4. Связь между стратегиями проектирования и испытаний Как уже упоминалось ранее, в жизненном цикле системы фаза проектирования связана не только с построением архитектуры системы, но и с разработкой плана ее испытаний. Каждой стратегии проектирования соответствует своя стратегия тестирования и испытаний. Так, тестирование может осуществляться сверху - вниз, снизу - вверх, изнутри - к границам или от границ - внутрь. Оно может выполняться по отдельным цепям управления или ио отдельным каналам данных. Тестирование сверху - вниз требует наличия фиктивных, модулей нижних уровней. При использовании восходящего принципа тестирования необходимо использовать задающие модули (драйверы) более высоких уровней. Для тестирования ио принципу изнутри - к границам нужны и задающие, и фиктивные модули. Тестирование от границ - внутрь подобно тестированию снизу - вверх. Тестирование и испытания должны осуществляться поэтапно таким образом, чтобы полностью проверенные модули постепенно объединялись с непроверенными и другими, уже испытанными модулями для дальнейшей проверки. Проведение тестирования и испытаний - это отдельная проблема, и ее более глубокое рассмотрение здесь увело бы нас далеко за рамки темы данной главы. 4.3. Эскизное представление потока данных: принципы поэтапной разработки проекта системы В этом разделе описывается неформальная методология проектирования, в основе которой лежит стратегия структурного проектирования, ориентированная на потоки данных. При проектировании системы с использованием этой методологии разработчик реализует ряд основных этапов, которые в силу их достаточной общности для любых проектов положены в основу рекомендуемых ниже руководящих принципов. Неформальный характер методологии позволяет определить ее как метод эскизного представления потока данных, который предусматривает следующие шаги разработки: Шаг 1. Определите в системе наиболее очевидные граничные модули-подсистемы. Центральную часть системы рассматривайте как единый центральный модуль. На этом шаге следует приписывать модулям функции неформально, только в самом общем виде, не слишком беспокоясь об их завершенности илн о том, вполне ли они правильны. Целью первого шага является всего лишь обеспечение отправных позиций для организации процесса проектирования. Можно предполагать, что дальнейшие шаги этого процесса выявят необходимость изме- нения начальных условий; поскольку это вполне естественно и даже неизбежно, слишком большая оиределенность в исходной точке иросто нежелательна. Проектирование всегда отчасти ведется методом проб и ошибок, н поэтому с самого начала должно восприниматься как процесс, сопряженный с постоянным внесением изменений. Шаг 2. На чистом листе бумаги изобразите выделенные модули для целей их эскизного графического представления. Начните обдумывать характер потоков данных между модулями и оценивать необходимость введения дополнительных внутренних компонентов информационных истоков. Основываясь на этих размышлениях, попытайтесь выявить внутренние модули, которые, по вашему мнению, целесообразно иметь в системе по соображениям обеспечения требуемых функций и модульной конструкции. Шаг 3. Используйте эскизы информационных потоков и связанные с ними результаты размышлений для того, чтобы уточнить собственные представления о модулях и о потоках дан-пых. Потребность в дополнительных модулях и комионентах потоков данных может стать очевидной, например, вследствие необходимости реализации функций контроля и обработки ошибок. Шаг 4. С той степенью подробности, какая возможна на данной стадии, припишите модулям конкретные функции, используя перечень технических требований к системе. Снова уточните информационный потоковый граф с учетом произведенного расиределепия функций. Проведите критический анализ проектных решений по системе на данной стадии и ири необходимости внесите изменения. Шаг 5. Разработайте один или несколько структурных графов, определяя возможные варианты архитектуры системы в виде пакетов и задач для того представления о системе, которое выработалось к данному моменту; основываясь на произведенном распределении функций, определите интерфейсы пакетов и задач в функциональном плане, опуская детали, касающиеся структуры и типов данных. Для задач примите решения относительно направлений рандеву, условий защиты, вспомогательных задач, задач-курьеров, условных и временных вызовов и т. п., следуя руководящим принципам, изложенным в гл. 3. Вновь произведите критический анализ и ири необходимости внесите изменения. Шаг 6. Опишите в деталях интерфейсы системы, в том числе подробности, касающиеся типов и структур данных, п опять проведите критический анализ. Шаг 7. Если приходится иметь дело с большой и сложной системой, то может оказаться необходимым рекурсивное 5 Зак, 455 применение онисанного метода для разработки проектов по подсистемам. Шаг 8. Необходимо многократно проводить сессии всестороннего сквозного контроля проектных решений, чтобы ведущие специалисты коллектива разработчиков имели возможность убедиться в должном качестве и полноте проекта; эти сессии следует организовывать как рабочие совещания с участием всех основных участников разработки, где заслушиваются сообщения о проектных решениях и даются ответы на все возникающие вопросы. Критерии для оценки проектов рассматриваются ниже в этой главе и в гл. 6. Рассмотренные основные принципы проектирования систем иллюстрируются ниже на конкретном примере. 4.4. пример разработки проекта: система, реализующая экологическую игру LIFE Основная причина, ио которой в качестве первого примера выбрана игровая система, реализуемая на настольной микроЭВМ в интерактивном режиме, является ее простота; выбрав столь несложный пример, мы можем рассмотреть проблемы проектирования, не заменяя их проблемами конкретной прикладной области. Главная задача данного примера - показать, каким образом, основываясь на подходе, ориентированном на потоки данных, можно разработать проект системы, которая должна обладать способностью расшифровывать команды, вводимые в интерактивном режиме, и далее реализовать этот проект, используя концепции конечных автоматов, задач и пакетов, предусматриваемых в языке Ада. Экологическая игра не является игрой в обычном смысле этого слова. Скорее это просто набор правил отображения соответствующих последовательностей рисунков в игровом иоле, размеченном на квадраты подобно шахматной доске. В каждом таком квадрате помещаются фишки, которые живут или умирают в каждом поколении в соответствии с некоторыми правилами в зависимости от наличия или отсутствия других фишек. Последовательное порождение различных конфигураций игрового поля мол<ет приводить к возникновению интересных динамических изображений. В нашей системе поле будет высвечиваться на экране дисплея. Предполагается, что размеры поля предопределены программой. Играющий, сидя за клавиатурой, для создания исходной популяции фишек на экране может использовать ряд команд, а затем дать системе задание промоделировать заданное число поколений. В этой главе объектом нашего внимания является проектирование режима человеко-машинного взаимодействия, а не самого механизма игры. Конкретные правила рассматриваемой экологической игры несущественны для нашего проекта, однако ради забавы мы их все же приведем. Эти правила основаны на взаимной зависимости каждой фишки и ее соседей, количество которых может доходить до восьми - по числу клеток, окружающих данную. Игра начинается с произвольного числа расположенных в игровом поле в любом порядке фишек, совокупность которых называется исходной популяцией. Следующее поколение определяется путем одновременного применения ко всем клеткам игрового поля двух правил: 1. Если в некоторой клетке оказывается фишка, то она сохраняется в очередном поколении только тогда, когда имеет ровно двух или трех соседей. 2. Когда некоторая клетка пуста, в ней помещается фишка, если имеются ровно три соседние занятые клетки. Предположим теперь, что в руководстве пользователя определена система команд, набираемых из последовательно расположенных слов, которые образуют командные строки. Команды вводятся с клавиатуры посимвольно, и конец командной строки обозначается специальным символом, например сигналом возврата каретки. Слова, образующие команду, отделяются друг от друга пробелами. Команды обрабатываются только после окончания ввода всей строки. На экране резервируется специальная строка для отображения текущей команды по мере ее ввода. Пусть имеется семь возможных команд, которые образуются последовательностями слов, задаваемых конечным автоматом, как показано на рис. 4.12. Команды 1 и 2 предназначены для заполнения или очистки всех клеток при установке начального состояния. Команды 3 и 4 определяют способ интерпретации пар чисел в командах 5 и 6, указывающих номера строк и столбцов. Команды 5 и 6 добавляют или удаляют фишки в клетках с координатами, определяемыми парой.этих чисел. Команда 7 определяет задаваемое число поколений. Наша задача теперь состоит в том, чтобы спроектировать систему, которая будет распознавать эти команды при вводе, отвергать последовательности символов и слов, которые не образуют распознаваемых команд, а также определять порядок выполнения соответствующих операций по заполнению или очистке игрового поля, размещению фишек в игровом поле для создания исходной популяции, добавлению или удалению фишек на экране с целью порождения новой исходной популяции в игре и моделированию процесса рождения и гибели заданного числа поколений. 132 Глапп 4 ЗАПОМНИТЬ ПОЛЕ очистить ПОЛЕ - >{10) -{С?, вводить ФИШКИ по OltiL СТОЛБЦАМ  СТОЛБЦАМ И СТРОКАМ 5)-Kiib , 3 , УДАЛИТЬ <ЧИСЛ0> <ЧИСЛ0>, ---42) @- ИГРАТЬ <ЧИСЛ0>,=, <число> Рис. 4.12. Конечный автомат для последовательности слов командной строки в системе LIFE. (Примечание. Не производится никаких действий при любых транзакциях, кроме тех, которые содержат параметр <ЧИСЛО>. Для них следует сохранить указываемое число в одной из двух ячеек.) 4.4.1, Поток данных Последующая разработка информационного потокового графа системы LIFE проводится в соответствии с процедурой эскизного графического представления потока данных, рекомендованной в разд. 4.3. На границах системы необходимо иметь следующие модули: модуль приема данных, вводимых с клавиатуры, модуль фиксатора-дешифратора строки, предназначенный для запоминания частично заполненных командных строк с целью их высвечивания в специальной зоне экрана и для декодирования законченных командных строк, модуль хранения игрового поля, предназначенный для запоминания информации, которая необходима для отображения на экране текущего состояния игрового поля и для генерации новых игровых полей, подлежащих выводу на экран. Во внутреннбхМ потоке данных можно выделить следующие существенные элементы: вводимые символы, которые должны компоноваться в командные строки, декодированные команды,  Нажатие клавиш. Вывод на экран строки (отображение введенной команды, наводящих сообщений и ответов) Рис. 4.13. ИПГ для системы LIFE. Вывод игрового полн на экран Фиксатор-дешифратор строки Декодированные команды  Символы Вывод строки на экран Рис. 4.14. Пошаговое уточнение ИПГ системы LIFE, запросы вывода на экран наводящих сообщений, строк символов и ответов, запросы вывода на экран новых конфигураций и игрового поля. Для того чтобы соединить эти элементы потока данных вместе, требуется по крайней мере еще один дополнительный модуль, а именно процессор команд, предназначенный для преобразования декодированных команд в запросы вывода иа экран картины игрового поля. Определенный выше модуль фиксатора-дешифратора строки осуществляет преобразование символов в декодированные команды (рис. 4.13). Добившись четкого и полного представления об информационном потоковом графе, целесообразно уточнить структуру модуля фиксатора-дешифратора строки. Поскольку командные строки при декодировании рассматриваются как цепочки слов, представляется целесообразным разделение фиксатора-дешифратора строки на фиксатор строки и дешифратор цепочки слов; результат этой операции показан на рис. 4.14. Предполагается, что словарь командных слов является частью модуля фиксатора строки, который преобразует цепочку символов, ограниченную пробелами, в код слова. Элемент потока данных между фиксатором строки и дешифратором цепочки слов команды, являющейся цепочкой слов, может быть одной строковой переменной или некоторой последовательностью переменных, представляющих собой коды командных слов; однако все это - подробности, которые на данном этапе проектирования могут игнорироваться. 4.4.2. Структура системы Из построенного ИПГ довольно просто получить структурный граф, причем здесь первая задача заключается в том, чтобы решить, какова природа модулей, присутствующих в ИПГ. Модуль приема данных с клавиатуры должен представлять собой задачу, если символы вводятся по сигналам прерывания. Модули фиксации строки и хранения игрового поля могут быть пакетами, поскольку регенерация изображения на экране осуществляется непосредственно из памяти аппаратными средствами и для управления их работой не требуется порождать задачу. Отметим, однако, что в целях более широкого представления функций системы задача управления экраном должна быть определена как часть проекта системы, даже если она реализуется аппаратными средствами; тем не менее мы будем предполагать, что аппаратные средства заданы. Поскольку вообще задачи обслуживания прерываний следует делать максимально простыми, функции управления системой не следует возлагать на задачу приема данных с клавиатуры. 1 ... 10 11 12 13 14 15 16 ... 32 |
|||||||||||||||||