2.6. ПСИХОФИЗИОЛОГИЧЕСКИЕ ОСОБЕННОСТИ ВЗАИМОДЕЙСТВИЯ ЧЕЛОВЕКА И ЭВМ
ЭВМ дополняет человека, но не заменяет его, поэтому рассмотрение основных особенностей их сотрудничества необходимо.
Логический метод рассуждения. У человека он основан на интуиции, использовании накопленного опыта и воображении. Метод ЭВМ — строгий и систематический. Наиболее удачным является сочетание реализованных на ЭВМ отдельных расчетных процедур с определением человеком их логической последовательности.
Способность к обучению. Человек обучается постепенно, степень же «образованности» ЭВМ определяется ее программным обеспечением. Желательно, чтобы количество информации, получаемой на запрос пользователя, было переменным и могло изменяться по требованию пользователя.
Обращение с информацией. Емкость мозга человека для сохранения детализированной информации невелика, но мозг обладает интуитивной, неформальной возможностью организации информации. Эффективность вторичного обращения к памяти зависит от времени.
В ЭВМ емкость памяти большая, организация формальная и детализированная, вторичное обращение не зависит от времени. Поэтому целесообразно накапливать и организовывать информацию автоматическим путем и осуществлять ее быстрый вызов по удобным для человека признакам.
Оценка информации. Человек умеет хорошо разделять значимую и несущественную информацию. ЭВМ таким свойством не обладает. Поэтому должна существовать возможность просмотра макро информации большого объема, что позволяет человеку выбрать интересующую его часть, не изучая всю накопленную информацию.
Отношение к ошибкам. Человек часто допускает существенные ошибки, исправляя их интуитивно, при этом метод обнаружения ошибок чаще всего также интуитивный. ЭВМ, наоборот, не проявляет никакой терпимости к ошибкам и метод обнаружения ошибок строго систематичен. Однако в области формальных ошибок возможности ЭВМ значительно больше, чем при обнаружении неформальных. Поэтому нужно обеспечить возможность пользователю вводить в ЭВМ исходную информацию в свободной форме, написанную по правилам, близким к обычным математическим выражениям и к разговорной речи. ЭВМ выполняет контроль и приводит информацию к стандартному виду, удобному в процедурах обработки и формального устранения ошибок. Затем желательно обратное преобразование этой информации для показа пользователю в наглядной, например графической, форме, для обнаружения смысловых ошибок.
Обращение со сложными описаниями. Человеку трудно воспринять большое количество информации. Поэтому следует поручать ЭВМ автоматическое разбиение сложных конфигураций на относительно независимые части, охватываемые одним взглядом. Естественно, что изменения, сделанные в одной из этих частей, должны автоматически производиться во всех остальных.
Распределение внимания на несколько задач. Выполнить это условие человеку в основном не удается. При решении подзадачи приходится отвлекаться от основной задачи. Поэтому в ЭВМ должна быть организована система прерываний, восстанавливающая состояние основной задачи к моменту, нужному для пользователя. Аналогичным образом ЭВМ обслуживает процедуру анализа нескольких вариантов решения.
Память по отношению к проведенной работе. Человек может забыть как и то, что уже сделано, так и то, что ему запланировано сделать еще. Этот недостаток компенсируется ЭВМ, которая четко фиксирует и информирует пользователя о выполненных процедурах и предстоящей работе.
Способность сосредоточиваться. Эта способность у человека зависит от многих факторов, например от продолжительности и напряжения внимания, влияния среды, общего состояния. Усталостью обусловливаются рассеянность, удлинение реакций, нецелесообразные действия. В связи с этим интерактивная система с разделением времени должна адаптироваться к времени реакции отдельного пользователя.
Терпение. При многократном повторении одних и тех же действий человек может испытывать чувство досады. Поэтому предусматривается, например, ввод исходных данных одним массивом при многократном анализе этих данных. К этому же относится включение в систему макрокоманд или гибких сценариев.
Самочувствие. ЭВМ должна беречь самочувствие пользователя, его чувство собственного достоинства и показывать ему, что именно машина его обслуживает, а не наоборот. Вопросы, ответы и замечания должны соответствовать разговору между подчиненным и его руководителем, определяющим ход и направление работы.
Эмоциональность. Это чувство свойственно человеку и чуждо ЭВМ. Программы должны возбуждать у пользователя положительные эмоции и не допускать отрицательных эмоций.
2.7. КЛАССИФИКАЦИЯ ТИПОВ ДИАЛОГА ПРОГРАММ
В настоящее время распространены следующие диалоги типа: вопрос-ответ; выбор из меню; заполнения бланков; на основе команд; работы в окнах; по принципу электронной таблицы; гипертекста; приближения к естественному языку; виртуальной реальности.
Диалог типа вопрос-ответ, представленный на рис. 2.3, является одним из универсальных. По запросу возможен ввод значений разных типов. В простейшем случае диалог может быть реализован с использованием трех кнопок: да, нет, начать диалог сначала. Проблема при реализации диалога состоит в затруднении обеспечения просмотра пользователем всей предыстории вопросов программы и ответов на них.
Диалог типа меню не является универсальным. Довольно сложно реализовать с использованием диалога данного типа ввод значений в широком диапазоне. Вертикальные меню предпочтительнее горизонтальных. Нежелательно в отдельных меню предлагать более семи тем. Меню с большим количеством тем желательно представить системой иерархической системы подменю. Часто используется
в программах меню в стиле фирмы «Lotus» из одного главного горизонтального подменю и иерархически построенных остальных вертикальных меню. Строка единственного главного горизонтального подменю придает уверенность начинающему пользователю путем сообщения ему фута о том, что имеется меню в программе. Диалог типа меню представлен на рис. 2.4.
Диалог типа заполнения бланков отображает на отдельном экране какой-то бланк. Посредством клика мыши или нажатия клавиш <Tab>, а также клавиш-стрелок перемещения курсора обеспечивается подвод курсора на любое из выделенных полей ввода информации. Обычно при заполнении какого-либо поля бланка осуществляется контроль кодов нажатых клавиш (ввод по маске). Трудность реализации диалога состоит в принятии решения по факту ввода недопустимой по значению информации в поле или ввода недопустимой совокупности значений в ряд полей. Диалог типа заполнения бланков представлен на рис. 2.5.
Диалог на основе команд, представленный на рис. 2.6, используется в системах с априорно незаданной последовательностью работы. Сложность использования диалога данного типа заключается в необходимости предварительного изучения пользователем языка команд и возможных последовательностей команд. Если команд мало в списке возможных команд, то пользователю по запросу «?» может быть выдан список возможных команд. После набора имени команды возможна выдача списка полей команды и их назначение.
Диалог типа работы в окнах (рис. 2.7) позволяет на экране монитора организовать совокупность окон как отдельных программ, так и отдельных документов и осуществлять работу в
каждом из отдельных окон. Данный диалог необходим специалистам, «у которых стол завален бумагами», т. е. специалистам, которым для получения нового документа необходима информация сразу из нескольких документов.
Диалог типа по принципу электронной таблицы отображает информацию в двухмерной системе координат по принципу игры «в морской бой» и в режиме «что вижу, то и получу в распечатке» позволяет придать табличной информации форму, необходимую пользователю (рис. 2.8).
Диалог типа гипертекста (рис. 2.9) обеспечивает пользователю просмотр на экране монитора текстовой (графической, видео, аудио и др.) информации с возможностью получения дополнительной информации при выборе пользователем выделенных на экране ключевых слов (ссылок).
Диалог приближения к естественному языку обычно обеспечивает выдачу пользователем запросов на ограниченном естественном языке. Наибольшую сложность при реализации диалога данного типа представляет составление ограниченного тезауруса слов запроса и изучение данного тезауруса пользователем.
Диалог типа виртуальная реальность используется в различных тренажерах и может основываться на использовании особого оборудования типа кибершлем, тактильные перчатки, система запахов и т.д.
Фонд различных диалогов облегчает выбор рационального варианта построения внешних спецификаций программ. Список более мелких «строительных элементов» диалога можно получить в панели компонентов систем визуального программирования, например Delphi.
ВЫВОДЫ
• На разных этапах проектирования (особенно часто на начальных этапах) перед разработчиком встает задача выбора наилучшего варианта из множества допустимых проектных решений, которые удовлетворяют предъявленным требованиям. Принятие «правильного» решения означает выбор такой альтернативы из числа возможных, в которой с учетом всех разнообразных факторов будет оптимизирована общая ценность.
• Задача оптимизации разработки программ состоит в достижении целей при минимально возможной затрате ресурсов. Системный анализ в отличие от предварительного системного исследования — это углубленное изучение информационных потребностей пользователей, которое будет положено в основу детального проектирования новой информационно-программной системы (АС). Формулировка целей при разработке программного продукта — первый и важнейший этап процесса проектирования. Ошибки в выборе и формулировке цели не могут быть скомпенсированы на последующих этапах. Анализ требований способствует лучшему пониманию системы, а также достижению наилучшего удовлетворения потребности.
• Совокупность функций системы, условий и ограничений их существования называется множеством потребительских свойств системы. Функции системы — это все свойства, обусловливающие полезность (целесообразность системы для потребителя).
• Любые классификации программ повышают вероятность синтеза вариантов. Классификации можно использовать как при работе методом морфологического синтеза, так и методом аналогии.
• Прежде чем искать пути оптимизации разработки программ, необходимо выделить некоторые ключевые положения.
Положение 1. Проблема, которая должна быть решена разрабатываемой программой, ранее каким-то образом решалась. Следовательно, необходимо изучить методы, применявшиеся ранее, по возможности, их формализовать и применить.
Положение 2. Для подавляющего числа задач в настоящее время существуют программы, выполняющие похожие либо аналогичные функции. Поэтому необходимое условие качественной разработки — ознакомление с существующими аналогами.
Глава 3. ПРОЕКТНАЯ ПРОЦЕДУРА РАЗРАБОТКИ ФУНКЦИОНАЛЬНЫХ ОПИСАНИЙ
3.1. ОБЩИЕ СВЕДЕНИЯ О ПРОЕКТНОЙ ПРОЦЕДУРЕ
Развитие отдельных направлений программирования, филологии, психологии, теории проектирования и искусственного интеллекта подошло к точке, когда ощущается настоятельная необходимость интеграции накопленных результатов. Попытка такой интеграции воплотилась в излагаемой далее проектной процедуре (методике), которая может быть применена для составления функциональных описаний (описаний процессов). Инструкция пользования каким-либо устройством, инструкция вообще или алгоритм программы являются функциональными описаниями.
Хорошим функциональным описанием является описание безошибочное, однозначное для читателя, краткое, суть которого понимается быстро. Согласно проектной процедуре, хорошее функциональное описание составляется от общего к частному с использованием особых конструкций предложений — типовых элементов (типовых структур или просто структур).
Обычно человек мыслит предложениями естественного языка. Если научиться упорядочивать мысли в процессе мышления, то можно научиться получать алгоритмы и иные функциональные описания со скоростью не только не меньшей, чем до обучения, но даже большей. Опытный программист пишет текст на языке программирования со скоростью, с которой он думает, а в случае простых алгоритмов — со скоростью набора текста на клавиатуре. Одно из преимуществ применения проектной процедуры заключается в снижении умственной усталости программиста за счет исключения необходимости неоднократного повторения мыслительного процесса для получения одной и той же забываемой идеи. Главное преимущество заключается в однозначности соответствия функционального описания замыслу, что достигается исчерпывающим тестированием. При операционном подходе к составлению функциональных описаний исчерпывающее тестирование принципиально невозможно в силу сложности решаемой задачи (требуется сразу оттестировать большую и сложную структуру — всю программу).
Программисты могут применять проектную процедуру при написании инструкций работы пользователя в системе организации (учреждения) с использованием ЭВМ и разрабатываемой программы; внешних функциональных описаний программы в форме сценария работы программы (такие описания предшествуют внутреннему проектированию программы); внутренних функциональных спецификаций программы (метода решения задачи, алгоритма программы в целом); исходных текстов модулей программы при использовании технологии структурного программирования; кода методов объектов при использовании технологии объектно-ориентированного программирования; текстов помощи по использованию программы.
Умение применять проектную процедуру полезно и непрограммистам. При помощи данной проектной процедуры можно составлять короткие и понятные описания любых процессов; инструкции пользования изделиями; описания принципов функционирования изделий; тексты должностных инструкций организационного обеспечения, описания бизнес-процессов.
Данный список не является исчерпывающим и возможны все новые применения.
Написание технической документации — особый жанр писательского искусства. В настоящее время в развитых странах появляется новая специальность — Technical Writer — технический писатель. Вероятно, одна из сфер применения проектной процедуры заключается в ее использовании такими специалистами.
3.2. ИСТОРИЯ ВОЗНИКНОВЕНИЯ ПРОЕКТНОЙ ПРОЦЕДУРЫ
С появлением ЭВМ актуальным стал поиск способов описания вычислительных алгоритмов. В 60-х годах уже применялись два способа описания алгоритмов: словесный пошаговый и графический в виде схем алгоритмов программ (жаргонно: блок-схем алгоритмов).
При словесно пошаговом способе алгоритмы описывались по изложенному ниже принципу.
Шаг 1. Выполняется такое-то действие для того-то. Если получается, что А < В, то переходим к шагу 4.
Шаг 2. Выполняется такое-то действие для того-то.
Шаг 3. Если А > В, то переходим к выполнению шага 1.
Шаг 4. Выполняется такое-то действие для того-то.
Шаг 5. Если А > В, то переходим к выполнению шага 2.
Изображение того же алгоритма в форме схемы алгоритма приведено на рис. 3.1.
Недостатки каждого из способов приведены в табл. 3.1, из которой видно, что графический способ в виде схем алгоритмов программ облегчил лишь отслеживание передач управления и одновременно затруднил описание сути процессов (их комментирование).
До конца 70-х годов проектная процедура получения алгоритмов базировалась на операционном (маршрутном) мышлении, которое закладывается еще в школе математическими и физическими учебными дисциплинами. При операционном мышлении сначала записываются последовательные действия по главному основному маршруту. Затем эти действия дополняются операциями ветвления (if), операциями безусловного перехода (go to) и дополнительными действиями других маршрутов.
В результате использования операционного подхода получались программы (подпрограммы) со структурными элементами в виде операторов языка программирования и единственной сверхсложной структурой «вся программа» типа «спагетти» — множеством неупорядоченных передач управлений вперед и назад (см. рис. 3.1).
Программы, алгоритмы которых получаются операционным подходом, являлись практически несопровождаемыми. Даже при использовании графических схем алгоритмов их необходимо было дополнять достаточно длинными текстовыми описаниями. Эти текстовые описания должны были содержать огромное количество отдельных тестовых данных для отслеживания всех маршрутов вычислений с целью понимания алгоритма каждого отдельного маршрута. Сложность таких описаний приводила к несоответствию комментариев вычислительным процессам, а также к неоправданно длительному изучению алгоритма с просчетом трассы счета по всем маршрутам в процессе отладки.
При использовании схем алгоритмов программ вне документации остается ход мыслей проектировщика по получению алгоритмов. Само вычерчивание схем алгоритмов программ занимает достаточно большое время. Огромное, поистине астрономическое число вычислительных маршрутов требовало подготовки астрономического количества тестов. Программы были ненадежными по сравнению с нынешними программами. Отладка программы в виде одной неразделимой структуры «спагетти» и длиной всего в 600 строк занимала время до полугода. Написание и отладка такой программы при современных технологиях производится программистом за два-три рабочих дня.
Согласно современным технологиям программирования, описания алгоритмов в словесно-пошаговой и графической формах в виде схем алгоритмов программ практически не используются. Их заменили самодокументированные тексты, состоящие из стандартных структур кодирования.
Составлению описания проектной процедуры предшествовали труды Дейкстры (с концепцией программирования без go to), одна из первых работ по структурному кодированию программ [16] и длительный опыт программирования и преподавания авторов.
3.3. ОБЩЕЕ ОПИСАНИЕ ПРОЕКТНОЙ ПРОЦЕДУРЫ
Выполнение проектной процедуры начинается с полного уяснения задачи. Этому помогает применение модели «черного ящика», разработка форм вводимой и выводимой информации программы (например, в виде макетов экрана), подготовка первичных тестовых примеров. Не существует для всего многообразия задач точного порядка выполнения этих действий. Данные действия часто приходится выполнять параллельно, переключаясь с действия на действие по мере исчерпания возможностей развития текущего действия и открытия возможностей развития очередного действия.
Первоначально алгоритм или эвроритм должен представлять одну типовую структуру СЛЕДОВАНИЕ (одно действие со смыслом выполнить все действия программы, например программа начисления заработанной платы). Порядок детализации одиночного СЛЕДОВАНИЯ с использованием модели «черного ящика» будет показан далее. Данная модель позволяет выявить входную, выходную информацию программы и уточнить суть программы.
При разработке алгоритмов программ входная, промежуточная и выходная информация характеризуется именами и набором значений как простых, так и структурированных переменных (записей, массивов). Важным является порядок размещения значений в массивах, имена и значения констант описания размерностей массива, имена и значения переменных, характеризующие текущие значения используемого размера массива, имя и порядок изменения переменной индекса текущего элемента массива. Форма вводимой и выводимой на экран или печать информации может быть показана макетами экранов или документов.
При разработке эвроритмов инструкций входная, промежуточная и выходная информация характеризуется набором предметов (физических и документов) и их состоянием, например: пустой чайник; чайник, заполненный наполовину объема холодной водой; включен выключатель «сеть» в правом верхнем углу панели; документ по форме № 5 с заполненной первой графой. Здесь уместно дополнять описания предметов их рисунками. Учитывайте, что предметы изменяются во времени и пространстве.
Первичные тестовые примеры должны включать как обычные, так и стрессовые наборы тестовых входных данных. Каждый стрессовый набор тестовых данных предназначен для выявления реакции в особых случаях, например неверных действий пользователя, деления на ноль, выхода значения за допустимые границы и т. д. Любой набор тестовых данных должен содержать описание результата.
На основе первичных тестовых примеров и организации входной и выходной информации готовится обобщающий тест или несколько обобщающих тестов. Каждый обобщающий тест должен включать как можно больше ситуаций первичных тестов. Обобщающий тест должен отражать цепочку преобразования информации от исходной информации через промежуточную информацию до результирующей информации. Главнейшее требование к обобщающему тесту — его наглядность в представлении порядка изменения информации. Известно, что при изучении геометрии успех решения задачи определяется наглядностью рисунков. Наглядные геометрические, рисунки обычно получаются многовариантным их построением, и требуется приобретение некоторых навыков для развития искусства их выполнения. Все это относится и к составлению наглядных обобщающих тестов. Наглядность обобщающих тестов достигается правильным выбором способа отображения информации, который обеспечивает восприятие порядка преобразования информации.
Таким образом, составление эвроритма или алгоритма начинается с разработки обобщающих тестов, являющихся моделью типа абстракции данных, изложенной в гл. 1. Одной из ее форм может быть функциональная модель в виде набора диаграмм потоков данных (ДПД). Другая форма может соответствовать рисунку с рациональным способом размещения по его площади массивов с их именами, значениями элементов, значениями индексов элементов, значениями и именами простых переменных, соединенными стрелками по направлению передачи информации. Еще одной формой является форма, близкая к трассе счета, показывающая изменения значений переменных на итерациях процесса. Возможны и иные формы, например таблицы правил.
Подчеркнем важность работы с данными. Данные во многом определяют алгоритмы. При решении одной и той же задачи, выбор разных структур данных приводит к совершенно различающимся алгоритмам.
Дальнейшая работа заключается в получении модели процедурной абстракции на основании модели абстракции данных.
Любые алгоритмы или эвроритмы должны состоять только из стандартных структур, каждая из которых строго имеет один информационный вход и один информационный выход. Использование иных (нестандартных) структур приводит либо к удлинению описания, либо к невозможности тестирования (из-за нереально огромного объема необходимых тестов), либо к потере понятности.
Структуре СЛЕДОВАНИЕ в программах могут соответствовать выполнение всей программы, вызов процедуры, отдельный смысловой блок вычислений, который не оформлен в форму процедуры (программный блок), одиночный оператор присваивания, а также оператор ввода-вывода информации.
В инструкциях структуре СЛЕДОВАНИЕ соответствуют как элементарные операции, так и более частные инструкции. Далее до достижения элементарных действий (элементарных операторов языка программирования или элементарных операций) отдельные структуры СЛЕДОВАНИЕ, из которых состоит описание любого алгоритма или процесса, декомпозируются с соблюдением принципа от общего к частному одной из трех стандартных структур (рис. 3.2): ЦЕПОЧКА СЛЕДОВАНИЙ; ЦЕПОЧКА АЛЬТЕРНАТИВ; ПОВТОРЕНИЕ.
В случае длинного алгоритма по исчерпанию информации обобщающего теста готовятся новые обобщающие тесты под все новые задачи.
Любая из трех выявленных структур содержит в себе одну или несколько новых структур вида СЛЕДОВАНИЕ с более частными действиями. Так, ЦЕПОЧКА СЛЕДОВАНИЙ содержит последовательно выполняемые СЛЕДОВАНИЯ. ЦЕПОЧКА АЛЬТЕРНАТИВ . включает одну или несколько подчиненных структур вида СЛЕДОВАНИЕ. Структура ПОВТОРЕНИЕ включает одну подчиненную структуру вида СЛЕДОВАНИЕ.
На каждой итерации проектной процедуры приходится решать задачу: «А какая именно из трех структур будет выявлена?» При решении данной задачи необходимую информацию можно получить лишь из анализа обобщающих тестов. Анализ тестов на предмет поиска самой главной на данный момент структуры является для начинающих весьма непростым делом. «Раскрепостить мышление» помогает набор признаков структур, изложенный в табл. 3.2 и далее по тексту, а также набор эвристических приемов, позволяющий преодолеть инерцию мышления.
Набор эвристических приемов:
• «Хорошие наглядные иллюстрации — залог успеха!».
• «Думай от общего к частному!».
• «Общий процесс определяет работу частных!».
• «Это не главный процесс, вы увязли в частностях!».
• «Не забывай вводить новые термины (имена переменных)!».
• «Выделив главное действие, вы уже решаете более простую
задачу!».
• «Если закончилась информация в обобщающих тестах, то готовьте новые обобщающие тесты для решения все новых частных задач!».
• «Если в процессе декомпозиции потребуется описать процесс выхода из какой-то точки описания в какую-то иную, то это значит, что были неправильно выполнены предшествующие детализации из-за неправильного выявления наиболее общего действия и требуется корректно переделать предшествующую работу!».
• «Иногда очередная детализация не получается из-за неосознанной потребности по вводу вспомогательной переменной (флага события), характеризующей, произошло ли ранее какое-то событие!».
Структуре СЛЕДОВАНИЕ в программах могут соответствовать выполнение всей программы; вызов процедуры; отдельный смысловой блок вычислений, который не оформлен в форму процедуры (программный блок); одиночный оператор присваивания, а также оператор ввода-вывода информации.
Каждое СЛЕДОВАНИЕ соответствует строго одному действию. Главное в действиях — глагол. Основное, что необходимо выполнить при описании отдельной структуры СЛЕДОВАНИЕ: в описании должна содержаться лишь одна мысль. Любая структура вида СЛЕДОВАНИЕ может быть описана простым распространенным предложением естественного (русского) языка. Например, «Следующее действие заключается в погрузке мебели в автомобиль». Однако учитывая то, что в случае составления алгоритмов программ суть типовых структур поясняется самими операторами языка программирования, применяется более краткое описание в виде неполного предложения без сказуемого. В последнем случае подлежащее образуют от глаголов. Например, «Погрузка мебели», «Решение квадратного уравнения», «Ввод данных».
Порядок детализации одиночного СЛЕДОВАНИЯ с использованием модели «черного ящика» показан на рис. 3.2:
1) предварительное выявление сути действия;
2) выявление выходной информации, ибо выход определяет вход, а не наоборот;
3) выявление входной информации;
4) запись уточненного комментария сути действия или одного заключительного элементарного оператора.
ЦЕПОЧКА СЛЕДОВАНИИ соответствует однозначному описанию последовательности действий.
Признаком ЦЕПОЧКИ СЛЕДОВАНИЙ являются последовательно выполняемые разнородные действия. СЛЕДОВАНИЯМ соответствует последовательность простых предложений и сложносочиненных предложений, которые лучше преобразовать в простые предложения.
Порядок детализации ЦЕПОЧКИ СЛЕДОВАНИИ показан на рис. 3.3:
1) предварительное выявление сути действий каждого из СЛЕДОВАНИЙ, определение количества СЛЕДОВАНИЙ;
2) детализация каждого из СЛЕДОВАНИИ как одиночного СЛЕДОВАНИЯ;
3) проверка информационной согласованности всех СЛЕДОВАНИЙ, а также входной и выходной информации всей ЦЕПОЧКИ СЛЕДОВАНИЙ;
4) рационализация порядка СЛЕДОВАНИЙ (сосредоточение СЛЕДОВАНИЙ, сотрудничающих в информационном обмене);
5) сверка с обобщающими тестами. Отдельные СЛЕДОВАНИЯ структуры ЦЕПОЧКА СЛЕДОВАНИЙ в дальнейшем могут быть декомпозированы ЦЕПОЧКОЙ СЛЕДОВАНИЙ (более частных). Однако встречаются отдельные структуры СЛЕДОВАНИЯ, которые не могут быть декомпозированы ЦЕПОЧКОЙ СЛЕДОВАНИЙ. Такие СЛЕДОВАНИЯ могут лишь быть описаны или структурой вида ЦЕПОЧКА АЛЬТЕРНАТИВ (ВЕТВЛЕНИЕ) или структурой вида ПОВТОРЕНИЕ (ЦИКЛ).
Признаком ЦЕПОЧКИ АЛЬТЕРНАТИВ или ВЫБОРА является одно или несколько действий, каждое из которых выполняется при определенном условии или не выполняется вообще (обязательно конечное число разных действий при разных условиях). ЦЕПОЧКА АЛЬТЕРНАТИВ, в частном случае, может состоять из одной или нескольких простейших альтернатив с одним действием. Предложение простейшая АЛЬТЕРНАТИВА с одним действием имеет следующую конструкцию: «Если выполняется какое-то условие, то выполняется такой-то процесс (СЛЕДОВАНИЕ)». (В противном случае СЛЕДОВАНИЕ пропускается.) Предложение АЛЬТЕРНАТИВА из двух действий имеет следующую конструкцию: «Если выполняется какое-то условие, то выполняется СЛЕДОВАНИЕ 1, в противном случае выполняется СЛЕДОВАНИЕ 2». В принципе структура АЛЬТЕРНАТИВА из двух действий эквивалентна цепочке из двух простейших альтернатив с одним действием. При детализации процессов, включающих более двух альтернатив, может быть получена единая структура — ВЫБОР в виде цепочки последовательно записанных структур АЛЬТЕРНАТИВА с одним действием. Здесь следует отметить, что от внешне похожей ЦЕПОЧКИ СЛЕДОВАНИЙ, каждое СЛЕДОВАНИЕ которой является простейшей АЛЬТЕРНАТИВОЙ с одним действием, структура ВЫБОР отличается использованием одних и тех же предметов или переменных во всех условиях альтернатив.
Пример условий альтернатив в случае структуры ВЫБОР:
если А< В, то выполнить СЛЕДОВАНИЕ 1;
если А= В, то выполнить СЛЕДОВАНИЕ 2;
если А> В, то выполнить СЛЕДОВАНИЕ 3.
АЛЬТЕРНАТИВОЙ с одним действием можно осуществить досрочное прекращение процесса выполнения алгоритма в том случае, который соответствует обнаружению условий невозможности правильного дальнейшего выполнения алгоритма.
Детализациям всех последующих структур предшествует нулевое действие — запись в начале и в конце входных и выходных данных, выявленных в процессе детализации предшествующих им СЛЕДОВАНИЙ.
Порядок детализации ЦЕПОЧКУ АЛЬТЕРНАТИВ показан на рис. 3.4:
1) предварительное выявление сути действий каждого из СЛЕДОВАНИЙ альтернативных действий, определение количества таких СЛЕДОВАНИЙ;
2) детализация каждого из СЛЕДОВАНИЙ как одиночного СЛЕДОВАНИЯ;
3) выявление и запись логического условия выполнения каждого из альтернативных СЛЕДОВАНИИ;
4) проверка информационной согласованности всех СЛЕДОВАНИИ и логических условий в цепочке, а также входной и выходной информации всей ЦЕПОЧКИ АЛЬТЕРНАТИВ;
5) рационализация порядка альтернатив;
6) проверка выполнения всех маршрутов на тестах, полученных из обобщающего теста.
Признаком ПОВТОРЕНИЯ является многократно выполняемое действие (но обязательно конечное число раз). ПОВТОРЕНИЯМ соответствуют мысли: «Это действие должно быть выполнено пять раз»; «Это действие выполняется многократно до наступления такого-то события». Признаки ПОВТОРЕНИЙ — переменное количество АЛЬТЕРНАТИВ, любая мысль о возврате «назад», чтобы повторить какие-то действия. Часто главный более общий процесс вида ПОВТОРЕНИЕ прячется в контексте «и т. д.» или «и т. п.», «это совсем просто», или даже в многоточиях «...».
Предложение вида ПОВТОРЕНИЕ может быть записано или в форме ПОВТОРЕНИЕ «ДО» (ЦИКЛ «ДО») или в форме ПОВТОРЕНИЕ «ПОКА» (ЦИКЛ «ПОКА»).
Предложение ПОВТОРЕНИЕ «ДО» имеет следующую конструкцию: «До выполнения какого-то условия многократно выполнять СЛЕДОВАНИЕ».
Предложение ПОВТОРЕНИЕ «ПОКА» имеет следующую конструкцию: «Пока выполняется какое-то условие, многократно выполнять СЛЕДОВАНИЕ».
Разница между предложениями ПОВТОРЕНИЕ «ДО» и ПОВТОРЕНИЕ «ПОКА» заключается в том, что, согласно первому предложению, действие СЛЕДОВАНИЕ должно быть выполнено хотя бы один раз, а согласно второму, — СЛЕДОВАНИЕ может не выполняться ни разу.
Структура НЕУНИВЕРСАЛЬНОЕ ПОВТОРЕНИЕ или просто обеспечивает заданное количество повторений какого-либо процесса или выполнение какого-то процесса при значении переменной цикла, значение которой изменяется по правилам арифметической прогрессии.
Порядок детализации ПОВТОРЕНИЙ показан на рис. 3.5:
1) выявление и запись логического условия завершения ПОВТОРЕНИЯ «ДО» или условия продолжения выполнения ПОВТОРЕНИЯ «ПОКА»;
2) выявление действий прекращения выполнения повторения;
3) выявление действий СЛЕДОВАНИЯ подготовки выполнения ПОВТОРЕНИЯ;
4) детализация СЛЕДОВАНИЯ оставшегося действия как одиночного СЛЕДОВАНИЯ;
5) проверка информационной согласованности всех СЛЕДОВАНИЙ, логических условий, а также входной и выходной информации всего ПОВТОРЕНИЯ;
6) проверка на 2 — 3 тестах, полученных из обобщающего теста;
7) окончательный выбор варианта реализации ПОВТОРЕНИЯ; в виде структуры ПОВТОРЕНИЕ «ПОКА», в виде структуры ПОВТОРЕНИЕ «ДО».
Выполнение проектной процедуры начинается с подготовки и рассмотрения тестовых примеров для детализации всего описываемого процесса в виде одного СЛЕДОВАНИЯ. Для активизации мышления используется модель «черный ящик».
Берется чистый лист бумаги, внизу листа записываются термины выходных объектов и их состояния. Применительно к программам определяются имена и типы переменных, файлы, макеты экранных форм. Применительно к физическим системам определяются месторасположения и состояния объектов. Например, чайник без воды находится на полке. Результат действий — чайник, заполненный кипятком до половины объема, находится на плите. Выход определяет вход, а не наоборот! Поэтому сначала записываются результаты действий и лишь затем состояния объектов до действий.
Далее в верхней части листа записываются термины входных объектов и состояния входных объектов. В середине листа записывается одно простое распространенное предложение, характеризующее процесс преобразования входной информации в выходную информацию. Многократным анализом входа, выхода и сути предложения уточняется вся информация листа. Параллельно с этими действиями, еще на одном листе составляется множество тестовых примеров, охватывающих все случаи вычислений. В случае необходимости готовятся макеты экранов.
На основе совокупности тестов необходимо на отдельном листе составить один или несколько обобщающих тестов. При этом нужно спроектировать рациональную форму иллюстрирования: например, рисунки промежуточных состояний данных процесса или таблицы состояний данных. Обобщающий тест необходим для понимания сути функционирования процесса. На обобщающем тесте приводятся обозначения всех входных, выходных и внутренних переменных. Из теста должны быть видны все процессы преобразования входных данных в результат.
Обучаемым, которые находятся на начальной стадии изучения, рекомендуется предварительно описать протекание процесса по принципу: «Как можешь!» Качество описания должно соответствовать попытке объяснения процесса какому-то заурядному человеку или даже ребенку. Данный текст поможет (с использованием признаков) отличить общие действия от частных.
При обучении детализацию очередной структуры следует осуществлять на отдельном листе. При детализации ЦЕПОЧЕК СЛЕДОВАНИЙ рекомендуется ориентировать лист узкой стороной вверх, а при детализации ЦЕПОЧЕК АЛЬТЕРНАТИВ и ПОВТОРЕНИЙ лист лучше ориентировать широкой стороной вверх (это позволит размещать на листе трассы просчета тестов). Предварительно в верхней части листа записывается предложение, которое было получено ранее из детализации каждого из этих процессов в виде одного СЛЕДОВАНИЯ. Под ним записывается входная информация СЛЕДОВАНИЯ, а внизу листа — выходная информация. Далее осуществляется сама детализация, результаты которой после проверки на тестовых примерах и литературной обработки переносятся в чистовик описания алгоритма в целом.
При детализации ЦЕПОЧКИ СЛЕДОВАНИЙ равномерно по свободной части листа записываются предложения сути последовательно выполняемых действий (конкретный смысловой комментарий к процессу). Далее осуществляется работа над каждым из них как над отдельным СЛЕДОВАНИЕМ. Далее осуществляется проверка информационной согласованности следований и рационализируется их порядок, уточняется суть СЛЕДОВАНИЙ. При проверке необходимо убедиться, что для последующих СЛЕДОВАНИИ данные уже были определены предшествующими СЛЕДОВАНИЯМИ.
При детализации ЦЕПОЧКИ АЛЬТЕРНАТИВ равномерно по свободной части листа записываются (в количестве альтернативных действий) конструкции в виде нужного количества следующих последовательных предложений: слово «Если», несколько чистых строк для поля условия, слова «то выполняется действие», далее оставляется несколько чистых строк для предложения СЛЕДОВАНИЕ (конкретный смысловой комментарий процесса).
После детализация всех записанных СЛЕДОВАНИЙ как одного СЛЕДОВАНИЯ осуществляется запись условий выполнения альтернативных процессов. Далее осуществляется проверка информационной согласованности входа и выхода каждого из СЛЕДОВАНИЙ, их условий выполнения, а также входной и выходной информации всей ЦЕПОЧКИ АЛЬТЕРНАТИВ. Цепочка только из двух альтернатив может быть описана предложением вида: «Если выполняется условие (конкретное условие выполнения действия по ТО), то выполняется процесс (конкретный смысловой комментарий процесса), в противном случае выполняется иной процесс (конкретный смысловой комментарий процесса).
При детализации ПОВТОРЕНИЙ на свободной части листа записываются слова обоих заготовок для ПОВТОРЕНИЯ «ДО» и ПОВТОРЕНИЯ «ПОКА». Каждая заготовка начинается с чистых строк для будущего СЛЕДОВАНИЯ определения подготовки повторяющихся действий. Далее для ПОВТОРЕНИЯ «ДО»: записывается строка «До выполнения условия окончания повторяющегося процесса»; оставляется несколько чистых строк для записи условия окончания повторяющегося действия; записывается строка «многократно выполняется следующее действие:...». Для ПОВТОРЕНИЯ «ПОКА» записывается строка «Пока выполняется условие», оставляется несколько чистых строк для записи условия продолжения выполнения повторяющегося действия; записывается строка «многократно выполняется следующее действие:...». Под этими строками на обеих заготовках оставляются чистые строки для СЛЕДОВАНИЯ, определяющего окончание повторения процесса и СЛЕДОВАНИЯ многократно выполняемого действия, Заполнение заготовок осуществляется в следующем порядке: сначала условие окончания (продолжения для ПОВТОРЕНИЯ «ПОКА») выполнения повторяющегося действия; затем записывается СЛЕДОВАНИЕ, определяющее окончание повторения процесса; потом — СЛЕДОВАНИЕ определения подготовки повторяющихся действий и в последнюю очередь — СЛЕДОВАНИЕ многократно выполняемого действия. Далее осуществляется проверка информационной согласованности входа и выхода каждого из СЛЩОВАНИЙ, условия выполнения действия, а также входной и выходной информации всей структуры. Если до начала детализации не было ясно, какой из вариантов повторений рациональнее детализировать в первую очередь, то последовательно детализируются обе заготовки. Окончательный вариант отбирается путем их сравнения по критериям краткости и понятности.
По окончании детализации структурных отдельных частей документа необходимо произвести его сборку. При сборке обычно требуется литературное редактирование документа как единого целого. После смысловой и литературной обработки результат исследований процесса переносится в чистовик. Главный принцип — передай другим ход своих мыслей так, чтобы они смогли понять, но при этом не следует переусердствовать в деталях. Излишние комментарии могут вызвать раздражение читателя и усилить непонимание.
По достижении некоторого опыта можно большую часть работы делать без ее записи на отдельных листах. Однако первая работа выполняется строго на отдельных листах. Это важно для опытного специалиста, который по листам документа сможет выявить дефекты навыков у обучаемого, а также выдать обучаемому серию индивидуальных подсказок.
3.5. ПРИМЕР РАЗРАБОТКИ ОПИСАНИЯ ПРОЦЕССАХ «КИПЯЧЕНИЕ ВОДЫ В ЧАЙНИКЕ»
Ниже показано пошаговое выполнение проектной процедуры на примере разработки описания процесса «Кипячение воды в чайнике». Дополните данное описание наглядными рисунками самостоятельно.
Лист 1. Анализ процесса как одного СЛЕДОВАНИЯ. Первичное описание сути действия: «Кипячение воды в чайнике».
Выход: Чайник, заполненный кипятком до половины объема, находится на газовой плите. Конфорка выключена.
Вход: Чайник без воды находится на полке. Конфорка выключена. Требуемый объем кипятка — половина чайника.
Окончательное описание сути действия: «Получение чайника заполненного кипятком до заданного объема».
Нами получено СЛЕДОВАНИЕ (рис. 3.6).
Лист 2. Второй лист может содержать описание процесса «Получение чайника, заполненного кипятком до заданного объема», выполненное любым доступным способом.
Лист 3. Декомпозиция процесса «Получение чайника, заполненного кипятком до заданного объема».
Первоначально на лист переносим информацию предшествующей структуры СЛЕДОВАНИЕ, получаем макет листа, представленный на рис. 3.7.
Далее, исходя из соображений, что для этого процесса необходимо выполнить ряд последовательных действий, получаем макет листа с ЦЕПОЧКОЙ СЛЕДОВАНИЙ, представленный на рис. 3.8.
После детализации каждого из следований, проверки информационной согласованности и уточнения сути следований в цепочке получаем макет листа, изображенный на рис. 3.9.
Проверка информационного согласования выявила, что действие 2 не может быть ранее действия 1 из соображений экономии газа. Чайник нельзя ставить на конфорку до зажигания газа из-за опасности закончения донышка копотью спички. Аналогично проверялась последовательность остальных действий.
Действие 1 может быть декомпозировано еще одной ЦЕПОЧКОЙ СЛЕДОВАНИЙ.
Действие 2 «зажигание газовой горелки» декомпозируется циклом: пока не зажглась конфорка или не выявлены форс-мажорные обстоятельства, многократно выполнять действие «Зажигание конфорки». Дальнейшее развитие алгоритма позволило выявить структуры, изложенные далее.
Действие (СЛЕДОВАНИЕ) «Зажигание конфорки» представляет собой ЦЕПОЧКУ СЛЕДОВАНИИ: «Зажигание спички», «Включение газа», «Поджигание газа», «Отключение газа при неудаче», «тушение спички», «выбрасывание спички». Форс-мажорными обстоятельствами является отсутствие газа или окончание спичек. Им соответствует логическая переменная.
Действие (СЛЕДОВАНИЕ) «Отключение газа при неудаче» представляет собой альтернативу: если газ не зажегся, а спичка прогорела, то необходимо закрыть газ.
Здесь выявлена предшествующая недоработка с выходными данными действия 2. Ведь по окончании действия 2 конфорка может быть как включена, так и не включена. Исправить ситуацию можно двумя способами. По первому способу за действием 2 можно вставить простейшую альтернативу с одним действием: если
выявлены форс-мажорные обстоятельства, то аварийно завершить инструкцию. Согласно второму способу, действия 3, 4, 5 могут быть представлены одним СЛЕДОВАНИЕМ, внутри которого должна находиться ЦЕПОЧКА АЛЬТЕРНАТИВ последовательного выполнения каждого из прежних действий 3, 4, 5 при условии отсутствия выявления форс-мажорных обстоятельств.
3.6. ПРИМЕР ОПИСАНИЯ ПРОГРАММЫ «РЕДАКТОР ТЕКСТОВ»
Ниже приведен пример описания программы «Редактор текстов», составленный одним из обучаемых. В примере приводится сначала внешняя функциональная спецификация, а затем внутренняя спецификация.
Программа «Редактор текстов» предназначена для создания новых и корректировки существующих текстовых файлов MS DOS в диалоговом (пользователь-ЭВМ) режиме работы. ЭВМ формирует экран с окном, в котором отображен участок текста из текстового файла (макет экрана соответствует внутреннему редактору программы Norton Commander). Пользователю обеспечивается возможность вставки в текст в окне экрана любого символа клавиатуры за символом, отмеченным на экране курсором. Исключение составляет ряд символов, которые являются признаками команд управления или незадействованными символами (приводится список символов). После подачи пользователем команды записи все изменения текста, осуществленные пользователем, записываются в файл.
Основной принцип работы редактора текстов состоит в переносе строк текста из необходимых участков файла сначала в буферный массив памяти длиной в 65535 байт (символов) с дальнейшим копированием необходимых строк из буферного массива в окно экрана.
Запуск программы осуществляется командой с указанием имени редактируемого файла. Далее, пока не будет указано корректное имя файла, может начать многократно выполняться алгоритм «Запрос пользователя на ввод или корректировку имени файла».
Затем задаются начальные значения структурированной переменной «Система координат», в которой имеются поля: «Положение курсора относительно файла»; «Положение курсора относительно буферного окна редактора»; «Положение буферного окна редактора относительно файла».
После осуществляется очистка буферного массива редактора строковых переменных из 5·23 = 115 строк длиной по 255 символов.
Далее при параметре «Первая строка файла» выполняется алгоритм «Загрузка строк файла, начиная с указанной строки в буферный массив редактора». Потом до подачи пользователем одной из команд завершения редактирования с сохранением информации (или без сохранения) выполняется главный цикл программы. Наконец, если была дана команда завершения с сохранением информации, то информация из буферного массива переписывается в файл. Выполнение программы завершается очисткой экрана.
Контроль имени редактируемого файла состоит в следующем. Если файл с указанным именем отсутствует на диске, то выводится предупреждающее сообщение«о создании нового «пустого» файла. Если пользователь не указал имя редактируемого файла или отказался работать с созданным «пустым» файлом, то происходит аварийное завершение программы с пояснением причины завершения.
Внутри главного цикла программы выполняется ряд из трех последовательных действий. «Алгоритм отображение» отображает на экране 23 строки текста из буферного массива, начиная с заданной строки. Далее устанавливается курсор дисплея на заданную позицию экрана. Осуществляется ввод кода нажатой клавиши. Если код нажатой клавиши соответствует управляющей клавише, то выполняется одно из альтернативных действий по выполнению команды, которая соответствует данной клавише. В противном случае осуществляется вставка символа в текст.
3.7. ТЕОРИЯ КОДИРОВАНИЯ ТЕКСТОВ МОДУЛЕЙ (МЕТОДОВ)
3.7.1. Последовательность выполнения проектной процедуры при кодировании текстов модулей (методов)
Проектная процедура предусматривает подготовительные шаги:
1) составление тестовых примеров входных и выходных данных;
2) составление макетов экрана (теста ввода/вывода);
3) определение информации входа, выхода и текста комментария заголовка модуля;
4) выбор наиболее характерного теста, уяснение алгоритма пошаговым его выполнением на внутренних данных;
5) разработка максимально наглядного обобщающего теста процесса преобразования входной информации в выходную информацию с отображением состояний всех внутренних переменных.
Для некоторых конкретных случаев составления алгоритмов перечисления 1), 2) и 3) лучше поменять местами.
Тестовые примеры составляются как для правильных, так и для неправильных данных. Обобщающий тест или тесты — минимальный набор тестовых данных, охватывающих все возможные случаи вычислений.
Далее осуществляется преобразование первичного описания алгоритма в описание «от общего к частному» с параллельным кодированием текста. Все описание проектной процедуры такого преобразования излагается одним предложением: до достижения детального описания в виде элементарных операторов языка выделять, кодировать и тестировать очередную структуру.
Кодирование программы должно осуществляться только с использованием стандартных структур! Запрещено использование меток, операторов безусловного перехода на метку (go to), операторов досрочного выхода из структур break! При кодировании на языке С оператор break может использоваться только при кодировании структуры switch.
Вообще при использовании иного другого процедурно-ориентированного языка программирования (не Pascal) необходимо предварительно закодировать на используемом языке программирования все описанные в этом подразделе стандартные структуры без изменения их логики!
Так, при программировании на языке С структура УНИВЕРСАЛЬНЫЙ ЦИКЛ-ДО будет включать операцию «!» (НЕ):
В приведенной выше структуре ненулевое значение переменной L соответствует окончанию выполнения цикла, а не его продолжению выполнения как в операторе языка программирования! Использование «лишней» операции (!) НЕ никак не удлинит программу. Современные компиляторы автоматически инвертируют логическое условие завершения цикла.
3.7.2. Описание внешних и внутренних данных при кодировании текстов модулей (методов)
Кодирование текстов подпрограмм начинается с кодирования операторов описания вида подпрограммы (процедура или функция) и описания переменных. Имена переменных и их организация уже должны быть определены в обобщающих тестах. Особое внимание при выполнении проектной процедуры уделяется составлению описаний внешних и внутренних данных.
Внешние данные описываются макетами (рисунками) экранов ввода и вывода информации, формами документов, выводимых на печать, спецификациями файлов. Спецификации файлов могут быть составлены в виде рисунков, таблиц последовательной расшифровки назначения байтов и битов файла, в виде описаний переменных на языке программирования, в которые считывается информация из файла (или из которых записывается информация в файл).
Внутренние данные программы составляют глобальные константы (переменные с неизменяемыми значениями) и переменные как простые, так и структурированные. Переменные описываются детально сразу после их выявления. Например, массивы определяются именем (желательно с мнемоникой, раскрывающей их назначение), типом элементов, возможными границами изменения индексов, внешне смысловым порядком следования элементов массива, а также простой переменной, которая содержит количество элементов, реально находящихся в массиве. Иногда определяется переменная-носитель индекса. Переменные лучше всего документировать операторами описания их типов и самих переменных с указанием в комментариях назначения переменных, порядка информации в массивах и характерных значений конкретных переменных. Следует помнить, что данные могут иметь иерархическую структуру. Нежелательно рассредоточение данных. Так, вместо трех массивов — фамилия, имя, отчество — лучше использовать один массив-контингент в виде массива записей с полями — фамилия, имя, отчество.
Спецификации файлов могут быть составлены в виде рисунков, таблиц последовательной расшифровки назначения байтов и битов файла, описаний переменных на языке программирования, в которые считывается информация из файла (или из которых записывается информация в файл).
3.7.3. Кодирование типовых структур на языках программирования
СЛЕДОВАНИЯМИ могут быть: оператор вызова подпрограммы, комментарий оставшихся действий, элементарный оператор языка программирования.
Согласно стандарту проекта, АЛЬТЕРНАТИВА имеет четыре конструкции. Рассмотрим их запись на языке программирования Pascal.
Правая конструкция соответствует очень сложной логике условий. В простейших случаях допускается упрощенная кодировка (первый пример на Pascal, второй на С):
ВЫБОР из двух и более АЛЬТЕРНАТИВ нельзя кодировать при помощи вложения других структур простейших АЛЬТЕРНАТИВ из-за большой вероятности ошибок.
Порядок детализации структур АЛЬТЕРНАТИВА:
1) в зависимости от количества альтернативных действий, записываются все операторы структуры;
2) определяются сами альтернативные действия как СЛЕДОВАНИЯ;
3) записываются логические условия альтернативных действий;
4) проверяется информационная согласованность логических условий и действий;
5) на нескольких тестовых примерах осуществляется проверка. ПОВТОРЕНИЯ в программировании называются циклами.
Обычно стандартом проекта предусмотрен ряд конструкций циклов.
Не универсальный ЦИКЛ-ДО имеет две конструкции и используется для задания заданного числа повторений. Рассмотрим их запись на языке программирования Pascal.
Здесь i — переменная цикла. Обычно эти циклы не требуют после кодирования дополнительного тестирования.
Универсальные циклы имеют конструкции ЦИКЛ-ДО и ЦИКЛ-ПОКА. Их запись на языке Pascal приведена ниже:
Здесь L логическое выражение при значении True является условием продолжения выполнения ЦИКЛ-ПОКА или условием окончания выполнения ЦИКЛ-ДО. Подготовка и тело цикла являются СЛЕДОВАНИЯМИ. Тело цикла выполняется столько раз, сколько и весь цикл. Признаком ЦИКЛ-ПОКА является возможность не выполнения тела цикла ни разу. При равноценности из двух конструкций ЦИКЛ-ДО и ЦИКЛ-ПОКА выбирают ту, запись которой короче.
Вообще ЦИКЛ-ДО можно закодировать структурой ЦИКЛ-ПОКА, если в подготовке записать некоторые действия из тела цикла. Из ЦИКЛА-ДО получается ЦИКЛ-ПОКА при его охвате структурой АЛЬТЕРНАТИВА.
Порядок декомпозиции циклов:
1) набирается «пустой» текст оператора цикла;
2) записывается логическое условие продолжения ЦИКЛ-ПОКА или завершения ЦИКЛ-ДО (при этом выявляется переменная цикла);
3) декомпозируется то действие тела цикла, которое изменяет логическое условие до невыполнения условия ЦИКЛ-ПОКА или до выполнения условия ЦИКЛ-ДО;
4) детализируется СЛЕДОВАНИЕ «Подготовка цикла»;
5) детализируется оставшееся действие тела цикла как СЛЕДОВАНИЕ;
6) проводится проверка информационной согласованности всех элементов цикла;
7) проводится проверка правильности работы цикла с помощью без машинного расчета трассы выполнения тестов с трехкратным (или более), однократным выполнением цикла и вообще без выполнения.
В текстах программ может использоваться еще одна вычислительная структура — РЕКУРСИЯ. Признаком этой структуры является наличие рекурсивных формул и вычислений. Все, что делает рекурсия, можно реализовать при помощи циклов и массивов. Однако если язык программирования допускает рекурсию, то ее использование может сократить код программы. Peкурсия всегда очень тщательно комментируется.
3.8. ПРИМЕР ПРИМЕНЕНИЯ ПРОЕКТНОЙ ПРОЦЕДУРЫ ДЛЯ КОДИРОВАНИЯ ТЕКСТА МОДУЛЯ ПРОГРАММЫ КАЛЕНДАРЯ
Рассмотрим выполнение проектной процедуры на примере разработки на языке Pascal модуля расчета всех дат между двумя датами будущего. Оформление исходных текстов модуля подчиняется одному из возможных стандартов проекта.
Глядя на тесты и изображение модели «черного ящика» рис. 3.10, детализируем весь алгоритм как одно СЛЕДОВАНИЕ в порядке: а) выходная и/или выводимая информация; б) входная и/или вводимая информация; в) определяется действие в «черном ящике» (одно предложение).
Специфицирование входа и выхода программ заключается в кодировании операторов описания типов переменных и разработке макетов экранных и выводимых на печать форм. В результате выполнения этих действий при решении рассматриваемой задачи были получены приведенные ниже спецификации, тесты и тексты программ.
Выходная информация — отсутствует.
Выводимая информация — поясняется тестом с формами вывода.
Входная информация:
1) начальная дата вывода (например, 23.08.96);
2) конечная дата вывода (например, 05.11.96);
Комментарий алгоритма:
{Расчет всех дат между двумя датами будущего}
Тест с формами вывода:
ПН01.04.96 (високосный год) — базовая дата.
Макет печати:
ПТ23.08.96 — начало печати
СБ24.08.96
ВС25.08.96
. . . — очередная дата
ВТ05.11.96 — конец печати
Правила перехода на очередную дату:
1) 31.12 — на 01.01 следующего года;
2) 31.01; 29.02; 31.03; 30.04; 31.05; 30.06;
31.07; 31.08; 30.09; 31.10; 30.11, а также 28.02 не високосного года, года века, но не года тысячелетия — на первое число следующего месяца;
3) по остальным датам — перейти к следующему дню текущего месяца.
Правила перехода на очередной день недели:
1 2 3 4 5 6 7 1 2 3
ПН; ВТ; СР; ЧТ; ПТ; СБ; ВС; ПН; ВТ; СР ...
Первичный алгоритм: рассчитывать последовательно даты от базовой до конечной заданной даты с выводом информации, начинающейся с начальной заданной даты.
Текст программы, написанный сразу после выполнения подготовительных шагов:
При первоначальной детализации алгоритма «Расчет всех дат между двумя датами будущего» по слову «всех» пытаемся выделить ПОВТОРЕНИЕ в виде главного цикла программы. Здесь дополнительными признаками цикла является повторяющийся вывод строк дат.
Применительно к рассматриваемому примеру, был декомпозирован УНИВЕРСАЛЬНЫЙ ЦИКЛ-ДО и тело модуля приняло вид:
Цикл был проверен на тестах:
1) базовая дата = StartDate = EndDate (алгоритм корректен);
2) базовая дата < StartDate < EndDate (алгоритм корректен);
3) базовая дата > StartDate (алгоритм не корректен);
4) StartDate > EndDate (алгоритм не корректен).
Вывод: алгоритм работает корректно только при корректных данных, но это приемлемо по условию задачи.
Выполняемые операторы до слова repeat соответствуют СЛЕДОВАНИЮ «Подготовка цикла».
Тело цикла «работа с очередной датой» декомпозировано цепочкой трех СЛЕДОВАНИЙ, которые поименованы комментариями. При детализации цепочки СЛЕДОВАНИЙ проводились следующие проверки. Для правильной работы «Вывод требуемых дат» необходимо значение CurrentDate и StartDate. Это СЛЕДОВАНИЕ нельзя записать ниже двух других СЛЕДОВАНИЙ. Входной и выходной информацией СЛЕДОВАНИЯ «Переход на следующий день неделим является IndexWeek Day. Входной и выходной информацией СЛЕДОВАНИЯ «Переход на следующую дату» является CurrentDate. Это СЛЕДОВАНИЕ соответствует действию тела цикла, которое изменяет логическое условие завершения ЦИКЛ-ДО. Два последних СЛЕДОВАНИЯ могут быть взаимно переставлены. Однако избранный порядок соответствует важному положению хорошего стиля программирования «не разрывай по тексту работу с одними и теми же переменными». Проверка информационной согласованности этих СЛЕДОВАНИЙ между собой и всем циклом не выявила неопределенных или неправильно определенных значений переменных.
Дальнейшую детализацию алгоритма можно было бы проводить по пути детализации любого из СЛЕДОВАНИЙ тела цикла. Оставшиеся СЛЕДОВАНИЯ главного цикла программы рассматриваемого примера были закодированы следующим образом:
После сборки всей программы необходимо еще раз проверить понятность комментариев. «Лишние» комментарии надо изъять, а недостающие добавить.
3.9. ПРИМЕР ВЫПОЛНЕНИЯ УЧЕБНОЙ РАБОТЫ «РАЗРАБОТКА АЛГОРИТМА УМНОЖЕНИЯ»
В качестве примера приводится учебная работа, выполненная одним из обучаемых. Работа была оформлена на отдельных листах формата А4. Курсивом выделены пояснения авторов учебного пособия, которые были дополнительно ими внесены в текст работы.
Страница 1 (без нумерации) представляет собой титульный лист с наименованием: ЗАДАНИЕ НА СОСТАВЛЕНИЕ СТРУКТУРИРОВАННОГО АЛГОРИТМА».
Страница 2 содержит постановку задачи и набор тестов, составленных до разработки алгоритма процесса.
1. ПОСТАНОВКА ЗАДАЧИ
Составить алгоритм умножения двух положительных чисел с произвольным (до ста) количеством цифр. Цифры сомножителей и результата должны находиться в одномерных массивах. Разрядность результата не должна превышать 100 цифр.
2. НАБОР ТЕСТОВ, СОСТАВЛЕННЫХ ДО РАЗРАБОТКИ АЛГОРИТМА ПРОЦЕССА
Пусть предельная разрядность сомножителей равна трем цифрам, а результата — четырем. Аналогично приведенному образцу умножения чисел 391· 56 = 21896 (переполнение) были составлены тесты: 23·132 = 3036; 111·11 = 1221; 999·99=98901(переполнение); 00· 000=0; 1·0=0.
Алгоритм умножения обычно изучался в младших классах школы по маршрутному описанию процесса счета. Из-за теоретической огромности числа маршрутов большинство со школьной скамьи не знает процесса умножения при нулевых сомножителях!
Страница 3 содержит результаты анализа выходной и входной информации вычислительного процесса со структурами данных. Рациональность избранной структуры данных в значительной мере определяет рациональность алгоритма.
3. АНАЛИЗ ВЫХОДНОЙ И ВХОДНОЙ ИНФОРМАЦИИ ВЫЧИСЛИТЕЛЬНОГО ПРОЦЕССА
Анализ выходной и входной информации начинается с рассмотрения модели «черного» ящика, показанной на рис. 3.11.
Макет экрана со строками диалога программы приведен на рис. 3.12. Вместо трех последних строк возможен вывод: «Ошибка переполнения».
Страница 4 содержит наглядное изображение процесса преобразования входных данных обобщающего теста или тестов в выходные данные со всеми внутренними данными и/или трассу выполнения обобщающего теста или тестов. Обобщающий тест или тесты составляются на основе тестов страницы 2 и при минимальном количестве тестов охватывает все маршруты процесса вычислений. Наглядность изображения изменений всех данных способствует упрощению процесса разработки алгоритма. Рациональность избранной структуры данных в значительной мере определяет рациональность алгоритма.
4. НАГЛЯДНОЕ ИЗОБРАЖЕНИЕ ПРОЦЕССА ПРЕОБРАЗОВАНИЯ ВХОДНЫХ ДАННЫХ ОБОБЩАЮЩЕГО ТЕСТА В ВЫХОДНЫЕ
На первый взгляд кажется, что необходимо ввести переменное количество промежуточных массивов (в зависимости от количества цифр второго сомножителя) для запоминания продукта умножения первого сомножителя на очередную цифру второго сомножителя. Однако. внимательный анализ структур данных позволяет найти иной способ выполнения расчетов. При этом способе сначала обнуляется результат. Далее результат последовательно увеличивается на сдвинутый на разряд влево продукт умножения первого сомножителя на очередную цифру второго сомножителя. Переоформляем наглядное изображение процесса преобразования входных данных обобщающего теста.
На странице 4 или следующей иногда полезно поместить описание алгоритма в обыденном неструктурированном понимании.
Каждая последующая страница содержит результаты процесса детализации очередной выделенной от общего к частному структуры.
5. ПОСЛЕДОВАТЕЛЬНОСТЬ ДЕТАЛИЗАЦИИ АЛГОРИТМА
5.1. Результаты детализации СЛЕДОВАНИЯ «Вся программа» Следование «Вся программа» детализируется ЦЕПОЧКОЙ
СЛЕДОВАНИЙ:
Без отступов показана входная и выходная информация структур, которая использовалась при проверке информационной согласованности СЛЕДОВАНИЙ в ЦЕПОЧКЕ СЛЕДОВАНИЙ.
СЛЕДОВАНИЕ «Устранение лидирующих нулей» необходимо при использовании сомножителя, состоящего из нескольких нулей.
5.2. Детализация СЛЕДОВАНИЯ «Ввод корректного значения числа цифр первого сомножителя»
СЛЕДОВАНИЕ «Ввод корректного значения числа цифр первого сомножителя» декомпозируется циклом:
Аналогично декомпозируется процесс «Ввод корректного значения числа цифр второго сомножителя».
5.3. Детализация СЛЕДОВАНИЯ «Ввод цифр первого сомножителя в порядке от С1.D[C1.N] до C1.D[1]
СЛЕДОВАНИЕ «Ввод цифр первого сомножителя в порядке от C1.D[CI.N] до C1.D[1] декомпозируется циклом:
Описания новых переменных:
var {Рабочие переменные}
InCode : word;
ch : Char;
Несмотря на то, что здесь в нарушение правил детализировано сразу два цикла, в тестировании нет необходимости.
Аналогично декомпозируется процесс «Ввод цифр второго сомножителя в порядке от С2.D[C2.N] до С2.D[1].
5.4. Детализация СЛЕДОВАНИЯ «Вывод результата произведения»
СЛЕДОВАНИЕ «Вывод результата произведения» декомпозируется АЛЬТЕРНАТИВОЙ — РАЗВИЛКА С ДВУМЯ ДЕЙСТВИЯМИ:
{Вывод результата произведения}
if ERROR
then
WriteLn(Ошибка переполнения)
else
begin
{Вывод продукта умножения}
end;
Тесты: ERROR = True; ERROR = False.
5.5. Детализация СЛЕДОВАНИЯ «Вывод продукта умножения»
СЛЕДОВАНИЕ «Вывод продукта умножения» декомпозируется циклом:
{Вывод продукта умножения}
for i := R.N downto 1 do
Write(R.D[i]);
В тестировании нет необходимости.
5.6. Детализация СЛЕДОВАНИЯ «Устранение лидирующих нулей»
СЛЕДОВАНИЕ «Устранение лидирующих нулей» декомпозируется циклом:
В тестировании нет необходимости.
5.7. Детализация СЛЕДОВАНИЯ «Расчет произведения сомножителей»
СЛЕДОВАНИЕ «Расчет произведения сомножителей» декомпозируется циклом:
Структура тестировалась на тестах: 390*56; 390*56, но при Digits = 5; 0*0 при C1.N = 0; 1*0 при C1.N = 1 и других тестах.
5.8. Детализация СЛЕДОВАНИЯ «Увеличение результата на сдвинутый продукт умножения первого сомножителя на j-ю цифру второго сомножителя
СЛЕДОВАНИЕ детализируется циклом:
5.9. Детализация СЛЕДОВАНИЯ «Расчет очередной цифры результата и цифры переноса»
СЛЕДОВАНИЕ детализируется циклом:
Выход: R.D, R.N, ERROR, p.
Описания новых переменных:
6. РЕЗУЛЬТАТЫ СБОРКИ ПРОГРАММЫ
По окончании сборки программы имеет смысл еще раз отредактировать комментарии с изъятием «лишних» комментариев.
ВЫВОДЫ
• С появлением ЭВМ актуальным стал поиск способов описания вычислительных алгоритмов. В 60-х годах уже применялись два способа описания алгоритмов: словесный пошаговый и графический в виде схем алгоритмов (жаргонно: блок-схем алгоритмов).
• Согласно современным технологиям программирования, описания алгоритмов в словесно пошаговой и графической формах, в виде схем алгоритмов практически не используются. Их заменили самодокументированные тексты, состоящие из стандартных структур кодирования.
• Хорошим функциональным описанием является описание безошибочное, однозначное для читателя, краткое, суть которого понимается быстро. Согласно проектной процедуре, хорошее функциональное описание составляется от общего к частному с использованием особых конструкций предложений — типовых элементов (типовых структур или просто структур).
• Любые алгоритмы или эвроритмы должны состоять только из стандартных структур. Каждая стандартная структура строго имеет один информационный вход и один информационный выход. Использование иных (нестандартных) структур приводит либо к удлинению описания, либо к невозможности тестирования (из-за нереально огромного объема необходимых тестов), либо к потере понятности.
• При разработке алгоритмов программ входная, промежуточная и выходная информации характеризуются именами и набором значений как простых, так и структурированных переменных (записей, массивов).
• Первоначально алгоритм или эвроритм должен представлять одну типовую структуру СЛЕДОВАНИЕ (одно действие со смыслом «выполнить все действия программы»). Далее до достижения элементарных действий (элементарных операторов языка программирования или элементарных операций) отдельные структуры СЛЕДОВАНИЕ декомпозируются с соблюдением принципа от общего к частному одной из трех стандартных структур: ЦЕПОЧКА СЛЕДОВАНИЙ; ЦЕПОЧКА АЛЬТЕРНАТИВ; ПОВТОРЕНИЕ.
• Переход на новый язык программирования рекомендуется, начинать с разработки стандарта кодирования типовых вычислительных структур.
• Алгоритм во многом определяется структурой данных.
• Тесты — необходимый атрибут разработки алгоритма.
• Обобщающий тест или тесты — минимальный набор тестовых данных, охватывающих все возможные случаи вычислений.