Cтраница 2
Добавление в экспертную систему новых знаний также не является тривиальной проблемой. Во-первых, новые знания добавляются в систему уже на стадии отладки тех знаний, которые были введены в первоначальный вариант системы. Во-вторых, существуют и другие причины, требующие включения новых знаний на протяжении всего жизненного цикла системы. [16]
Резюмируя изложенное выше, можно сделать следующие выводы. Кроме того, применение тех же процедур позволяет еще на стадии отладки той или иной задачи локализовать неисправности в схеме АВМ, удалить неработоспособные блоки из схемы, что значительно сокращает время отладки задачи. Описанная выше методика может быть рекомендована также и как средство аттестации отдельных блоков или узлов АВМ и всей машины в целом. [17]
Программы пользователя, рассчитанные на пакетную обработку, пишутся пользователями и выполняются в режиме разделения времени под управлением супервизора пакетной обработки. К ним могут относиться новые программы управления процессом, находящиеся в стадии отладки и испытания, или программы решения задач, не ориентированных на технологический процесс. [18]
Петрова внедряется шефвая очередь поточной линии изготовления обечаек, которая предусматривает установку всего стандартного оборудования и внедрение следующих средств механизации: тележки механизированной к гильотинным ножницам, стенда / оборки и сварки листов на размер ПД с механизированным кантователем и портальной установкой, комплекса оборудования к листогибочным вальцам, стенда сварки продольного стыка обечайки, рентгенокамеры и установки для тазовой подрезки торцов обечаек. Оборудование последних трех видав находится в действии, механизированная тележка к гильотинным ножницам - в стадии отладки. [19]
Моделирующая программа - программа, моделирующая выполнение программы в машинных кодах на другой ЭВМ. Такие программы целесообразно применять при отладке программного обеспечения, так как моделирующая ЭВМ обычно имеет периферийные устройства, тогда как микропроцессорное устройство в стадии отладки их не имеет. [20]
Во всех работах, рассматривающих сложные явления взаимодействия излучения с поверхностями и со средой, указывается на возрастание преимуществ метода Монте-Карло перед другими методами при исследовании геометрически сложных систем. Отмечаемые преимущества сводятся к двум основным: менее сложен математический аппарат геометрических преобразований; ясная физическая интерпретация рассматриваемых задач делает процесс программирования более наглядным и легко контролируемым в стадии отладки вычислительной программы. Здесь интересно отметить, что распространение метода Монте-Карло на задачи со сложной объемной геометрией обеспечивается на основе зонального метода, что позволяет вести исследования радиационного и сложного теплообмена применительно к реальным энергетическим объектам. [21]
Иногда основному проектированию сверху вниз сопутствует разработка компонент снизу вверх. Достоинством этого принципа является то, что при переходе к разработке модулей более высокого уровня иерархии модули нижних уровней можно считать готовыми и подключать их к модулям верхнего уровня на стадии отладки. [22]
Быстрые трансляторы обеспечивают минимальное время обработки программы, однако, в ущерб качеству ее. Эти трансляторы обычно компактные и быстродействующие. Их целесообразно применять на стадии отладки программы, когда приходится часто вносить исправления и добавления в нее. [23]
Появление одного-едпнственного пробела внутри инструкции Снобола 4 может превратить простой вызов подпрограммы в инструкцию сопоставления с образцом, что приведет при выполнении программы к целому каскаду ошибок в других ее частях; потребуется немало труда, чтобы выявить породившую их синтаксическую ошибку. Несоответствие между числом открывающих и числом закрывающих скобок в Лиспе приводит к аналогичным проблемам. Мы вправе требовать, чтобы удобство чтения программы учитывало и то обстоятельство, что на стадии отладки программа, содержащая серьезные ошибки, не должна выглядеть правильной. [24]
Чем на более ранней стадии разработки программист начинает заниматься вопросами отладки программы, тем меньше неприятных неожиданностей ожидает его в будущем. Надежды на то, что устранение ошибок из программы и получение правильных результатов произойдет как-то само собой, без затраты особых усилий, никогда не оправдываются. Вообще, оптимизм и самоуверенность для программиста на стадии разработки противопоказаны; они могут являться полезными только на стадии отладки при затяжной борьбе с очень глубоко скрытыми ошибками. [25]
Если программа неверно работает, то она должна отлаживаться. Следовательно, отладка всегда должна начинаться с некоторых доказательств неудачности программы. Если кажется, что программа работает верно, то она должна быть подвергнута контролю тестами. Часто после тестирования программа модуля возвращается на стадию отладки для устранения ошибок. [26]
Хотя ограничений на формат записи программы практически не существует, все же следует принять во внимание следующее. Программа читается легче, если каждый оператор занимает одну карту. В случае его продолжения на другую желательно другую строку продолжать, отступив несколько позиций вправо. Операторы и другие элементы языка, используемые на стадии отладки программы, желательно записывать на отдельных картах с тем, чтобы их можно было легко удалить после отладки. Если между ключевыми словами и другими элементами языка имеются разделители, то не нужно дополнительно ставить пробелы в качестве разделителей, так как меньшее число позиций останется для записи других элементов операторов. [27]
Несмотря на ее кажущуюся большую трудоемкость, ручная отладка рентабельна, так как позволяет выявить в алгоритме и программе наиболее массовые и грубые логические ошибки, которые трудно и долго выявлять формализованными методами на ЦВМ, и тем самым существенно сэкономить затраты, необходимые для трансляции после выявления очередной группы ошибок. Кроме того, наличие контроля со стороны руководителя проекта алгоритмов и программиста-дублера позволяет проверить соответствие разработанной подпрограммы поставленной задаче и алгоритму и уточнить множество деталей ее решения, которые могут отсутствовать в техническом задании. Техническое задание на алгоритм в информационно-логических задачах управления редко содержит полную формализованную схему постановки задачи. Эту постановку приходится в значительной части уточнять на всех стадиях отладки. [28]
Несмотря на успешное развитие методов верификации программ, до сих пор в их основе лежит множество эвристических способов проверки правильности программ. Достаточно привести пример наиболее простого, до сих пор применяемого способа отладки программ, - организации выдачи ( печати) промежуточных результатов. В этом случае пользователю приходится анализировать и, часто вручную, огромные наборы промежуточной информации. Опытные программисты используют, конечно, приемы автоматического анализа промежуточных данных на основе анализа и проверки ряда известных заранее условий [ ( логических выражений) и правильного выполнения программы, что позволяет существенно уменьшить объем информации, выдаваемой пользователю при отладке программы. Имеются компиляторы, которые позволяют операторы проверки условий выделять в тексте программы и при завершении в стадии отладки автоматически их выбрасывать. Системные программисты рекомендуют встраивать подобные проверки в программу для улучшения их документирования. [29]
По результатам полной трассировки или ручным способом может быть выбран некоторый маршрут обработки информации данным алгоритмом. Этот маршрут определяется перечислением соответствующих ему меток. При частной трассировке система отладки контролирует и индицирует ( выводит на печать состояние основных устройств ЦВМ и значения необходимых величин) информацию при условных переходах и по возможности формирует входной тест логической информации, соответствующий данному маршруту. Если задана необходимая информация, преобразуемая линейными участками данного маршрута, то при частной трассировке контролируются и отображаются выходные данные, соответствующие заданным на входе. При частной трассировке выявляются несоответствия входного теста и заданного маршрута, причем приоритет при реализации задания может отдаваться маршруту или тесту в зависимости от стадии отладки. [30]