|
Реферат: Программа сложной структуры с использованием меню (Программирование)
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ГОРНЫЙ УНИВЕРСИТЕТ
кафедра вм
Курсовик
“Программа сложной структуры с использованием меню”
ВЫПОЛНИЛ: Пикулин Е. Г.
принял:
Солодовников А. Д.
( мОСКВА 1996 год
ОГЛАВЛЕНИЕ.
1. ВИДЫ КОНТРОЛЯ ПРОГРАММ
3
2. ЦЕЛИ, ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ
3. СТРУКТУРНОЕ ТЕСТИРОВАНИЕ
4. СОВМЕСТНОЕ ТЕСТИРОВАНИЕ МОДУЛЕЙ
5. ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ
6. ТЕСТИРОВАНИЕ ПРОГРАММНОГО КОМПЛЕКСА В ЦЕЛОМ
7. ОТЛАДКА ПРОГРАММ
ВИДЫ КОНТРОЛЯ ПРОГРАММ
Программный комплекс - это совокупность программных модулей,
предназначенных для решения одной задачи и составляющих одно целое.
Основными разновидностями контроля программного обеспечения
являются визуальный, статический и динамический.
Визуальный контроль - это проверка программ “ за столом “ , без
использования компьютера. На первом этапе визуального контроля
осуществляется чтение программы, причем особое внимание уделяется
следующим ее элементам:
комментариям и их соответствию тексту программы ;
условиям в операторах условного выбора ( IF, CASE ) и
цикла;
сложным логическим выражениям;
возможности незавершения итерационных циклов ( WHILE,
REPEAT, LOOP ).
Второй этап визуального контроля - сквозной контроль программы
( ее ручная прокрутка на нескольких заранее подобранных простых
тестах). Распространенное мнение , что более выгодным является
перекладывание большей части работы по контролю программных средств на
компьютере, ошибочно. Основной довод в пользу этого таков : при работе на
компьютере главным образом совершенствуются навыки в использовании
клавиатуры, в то время как программистская квалификация преобретается
прежде всего за столом.
Статический контроль- это проверка программы по ее тексту
(без выполнения) с помощью инструментальных средств. Наиболее известной
формой статического контроля является синтаксический контроль программы с
помощью компилятора , при котором проверяется соответствие текста
программы синтаксическим правилам языка программирования.
Сообщения компилятора обычно делятся на несколько групп в
зависимости от уровня тяжести нарушения синтаксиса языка программирования
:
- информационные сообщения и предупреждения , при
обнаружении которых компилятор, как правило, строит корректный объектный
код и дальнейшая работа с программой (компоновка, выполнение) возможна
(тем не менее сообщения этой группы также должны тщательно
анализироваться, так как их появление также может свидетельствовать об
ошибке в программе - например, из-за неверного понимания синтаксиса
языка);
- сообщения об ошибках, при обнаружении которых
компилятор пытается их исправить и строит объектный код, но его
корректность маловероятна и дальнейшая работа с ним скорее всего не
возможна;
3
- сообщения о серьезных ошибках , при наличии
которых построенный компилятором объектный код заведомо некорректен и его
дальнейшее использование невозможно;
- сообщения об ошибках , обнаружение которых привело
к прекращению синтаксического контроля и построения объектного кода .
Однако, практически любой компилятор пропускает некоторые виды
синтаксических ошибок. Место обнаружения ошибки может находиться далеко по
тексту программы от места истинной ошибки, а текст сообщения компилятора
может не указывать на истинную причину ошибки. Одна синтаксическая ошибка
может повлечь за собой генерацию компилятором нескольких сообщений об
ошибках (например, ошибка в описании переменной приводит к появлению
сообщения об ошибке в каждом операторе программы, использующем эту
переменную).
Второй формой синтаксического контроля может быть контроль
структурированности программ, то есть проверка выполнения соглашений и
ограничений структурного программирования. Примером подобной проверки
может быть выявление в тексте программы ситуаций, когда цикл образуется с
помощью оператора безусловного перехода (использования оператора GOTO для
перехода вверх по тексту программы ). Для проведения контроля
структурированности могут быть созданы специальные инструментальные
средства, а при их отсутствии эта форма статического контроля может
совмещаться с визуальным контролем .
Третья форма статического контроля - контроль правдоподобия
программы, то есть выявление в ее тексте конструкций, которые хотя и
синтаксически корректны, но скорее всего содержат ошибку или
свидетельствуют о ней. Основные неправдоподобные ситуации :
- использование в программе неинициализированных
переменных (то есть переменных, не получивших начального значения) ;
- наличие в программе описаний элементов,
переменных, процедур, меток, файлов, в дальнейшем не используемых в ее
тексте;
- наличие в тексте программы фрагментов, никогда не
выполняющихся;
- наличие в тексте программы переменных, ни разу не
используемых для чтения после присваивая им значений;
- наличие в тексте программы заведомо бесконечных
циклов ;
Даже если присутствие в тексте программы неправдоподобных
конструкций не приводит к ее неправильной работе, исправление этого
фрагмента повысит ясность и эффективность программы, т. е. благотворно
скажется на ее качестве.
Для возможности проведения контроля правдоподобия в полном объеме
также должны быть созданы специальные инструментальные средства, хотя ряд
возможностей по контролю правдоподобия имеется в существующих отладочных
и обычных компиляторах.
4
Следует отметить, что создание инструментальных средств контроля
структурированности и правдоподобия программ может быть существенно
упрощено при применении следующих принципов:
1) проведение этих дополнительных форм
статического контроля после завершения компиляции и только для
синтаксически корректных программ ;
2) максимальное использование результатов
компиляции программы и, в частности, информации, включаемой в листинг
компилятора;
3) вместо полного синтаксического разбора текста
проверяемой программы построение для нее списка идентификаторов и списка
операторов с указанием всех их необходимых признаков.
При отсутствии инструментальных средств контроля правдоподобия эта
фаза статического контроля также может объединяться с визуальным
контролем.
Четвертой формой статического контроля программ является их
верификация, то есть аналитическое доказательство их корректности.
В интуитивном смысле под корректностью понимают свойства программы,
свидетельствующие об отсутствии в ней ошибок, допущенных разработчиком на
различных этапах проектирования ( спецификации, проектирование алгоритма и
структур данных, кодирование ). Корректность самой программы по отношению
к целям, поставленным перед ее разработкой ( то есть это относительное
свойство ). Отличие понятия корректности и надежности программ в следующем
:
надежность характеризует как программу, так и ее
“окружение” ( качество аппаратуры, квалификацию пользователя и т.п. );
говоря о надежности программы, обычно допускают
определенную, хотя и малую, долю ошибок в ней и оценивают вероятность их
появления.
Надежность можно представить совокупностью следующих характеристик
:
1) целостность программного средства (способность
его к защите от отказов);
2) живучесть (способность к входному контролю
данных и их проверки в ходе работы) ;
3) завершенность (бездеффектность готового
программного средства, характеристика качества его тестирования);
4) работоспособность (способность программного
средства к восстановлению своих возможностей поле сбоев).
Очевидно, что не всякая синтаксически правильная программа является
корректной в указанном выше смысле, т. е. корректность характеризует
семантические свойства программ.
5
С учетом специфики появления ошибок в программах можно выделить
две стороны понятия корректности :
1) корректность как точное соответствие целям
разработки программы (которые отражены в спецификации) при условии ее
завершения или частичная корректность ;
2) завершение программы , то есть достижение
программой в процессе ее выполнения своей конечной точки.
В зависимости от выполнения или невыполнения каждого из двух
названных свойств программы различают шесть задач анализа корректности :
1) доказательство частичной корректности ;
2) доказательство частичной некорректности ;
3) доказательство завершения программы ;
4) доказательство незавершения программы ;
5) доказательство тотальной (полной ) корректности
(то есть одновременное решение первой и третьей задач);
6) доказательство некорректности (решение второй или
четвертой задачи).
Методы доказательства частичной корректности программ как правило
опираются на аксиоматический подход к формализации семантики языков
программирования. В настоящее время известны аксиоматические семантики
Паскаля, подмножества ПЛ/1 и некоторых других языков.
Аксиоматическая семантика языка программирования представляет собой
совокупность аксиом и правил вывода. С помощью аксиом задается семантика
простых операторов языка (присваивания, ввода - вывода, вызова процедур).
С помощью правил вывода описывается семантика составных операторов или
управляющих структур (последовательности, условного выбора, циклов). Среди
этих правил вывода надо отметить правило вывода для операторов цикла так
как оно требует знания инварианта цикла (формулы, истинности которой не
изменяется при любом прохождении цикла).
Построение инварианта для оператора цикла по его тексту является
алгоритмически не разрешимой задачи, поэтому для описания семантики циклов
требуется своего рода ”подсказка” от разработчика программы.
Наиболее известным из методов доказательства частичной корректности
программ является метод индуктивных утверждений предложенный Флойдом и
усовершенствованный Хоаром. Метод состоит из трех этапов.
Первый этап - получение аннотированной программы. На этом этапе для
синтаксически правильной программы должны быть заданы утверждения на языке
логики предикатов первого порядка :
6
входной предикат ;
выходной предикат ;
по одному утверждению для каждого цикла (эти
утверждения задаются для входной точки цикла и должны характеризовать
семантику вычислений в цикле).
Доказательство неистинности условий корректности свидетельствует о
неправильности программы, или ее спецификации, или программы и
спецификации.
Несмотря на достаточную сложность процесса верификации программы и
на то, что даже успешно завершенная верификация не дает гарантий качества
программы ( т.к. ошибка может содержаться и в верификации ), применение
методов аналитического доказательства правильности очень полезно для
уточнения смысла разрабатываемой программы, а знание этих методов
благотворно сказывается на квалификации программиста.
Наконец, динамический контроль программы - это проверка
правильности программы при ее выполнении на компьютере, т.е. тестирование.
ЦЕЛИ , ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ .
Каждому программисту известно, сколько времени и сил уходит на
отладку и тестирование программ. На этот этап приходится около 50% общей
стоимости разработки программного обеспечения.
Но не каждый из разработчиков программных средств может верно
определить цель тестирования. Нередко можно услышать, что тестирование -
это процесс выполнения программы с целью обнаружения в ней ошибок. Но эта
цель недостижима : ни какое самое тщательное тестирование не дает
гарантии, что программа не содержит ошибок.
Другое определение тестирования ( у Г. Майерса ) тестирование -
это процесс выполнения программы с целью обнаружения в ней ошибок. Такое
определение цели стимулирует поиск ошибок в программах. Отсюда также ясно,
что “удачным” тестом является такой, на котором выполнение программы
завершилось с ошибкой. Напротив, “неудачным можно назвать тест, не
позволивший выявить ошибку в программе.
Определение Г. Майерса указывает на объективную трудность
тестирования : это деструктивный ( т.е. обратный созидательному ) процесс.
Поскольку программирование - процесс конструктивный, ясно, что большинству
разработчиков программных средств сложно “переключиться” при тестировании
созданной ими продукции.
7
У Майерса сформулированы также основные принципы организации
тестирования :
1) необходимой частью каждого теста должно являться
описание ожидаемых результатов работы программы, чтобы можно было быстро
выяснить наличие или отсутствие ошибки в ней ;
2) следует по возможности избегать тестирования
программы ее автором, т.к. кроме уже указанной объективной сложности
тестирования для программистов здесь присутствует и тот фактор, что
обнаружение недостатков в своей деятельности противоречит человеческой
психологии ( однако отладка программы эффективнее всего выполняется именно
автором программы ) ;
3) по тем же соображениям организация -
разработчик программного обеспечения не должна “единолично ” его
тестировать ( должны существовать организации, специализирующиеся на
тестировании программных средств ) ;
4) должны являться правилом доскональное изучение
результатов каждого теста, чтобы не пропустить малозаметную на
поверхностный взгляд ошибку в программе ;
5) необходимо тщательно подбирать тест не
только для правильных ( предусмотренных ) входных данных, но и для
неправильных (непредусмотренных) ;
6) при анализе результатов кождого теста
необходимо проверять, не делает ли программа того, что она не должна
делать ;
7) следует сохранять использованные тесты
(для повышения эффективности повторного тестирования программы после ее
модификации или установки у заказчика) ;
8) тестирования не должно планироваться
исходя из предположения, что в программе не будут обнаружены ошибки (в
частности, следует выделять для тестирования достаточные временные и
материальные ресурсы) ;
9) следует учитывать так называемый “принцип
скопления ошибок” : вероятность наличия не обнаруженных ошибок в некоторой
части программы прямо пропорциональна числу ошибок, уже обнаруженных в
этой части ;
10) следует всегда помнить , что
тестирование - творческий процесс, а не относиться к нему как к рутинному
занятию.
Существует два основных вида тестирования : функциональное и
структурное. При функциональном тестировании программа рассматривается как
“черный ящик” (то есть ее текст не используется). Происходит проверка
соответствия поведения программы ее внешней спецификации. Возможно ли при
этом полное тестирование программы ? Очевидно , что критерием полноты
тестирования в этом случае являлся бы перебор всех возможных значений
входных данных, что невыполнимо .
8
Поскольку исчерпывающее функциональное тестирование невозможно, речь может
идти о разработки методов, позволяющих подбирать тесты не “вслепую”, а с
большой вероятностью обнаружения ошибок в программе.
При структурном тестировании программа рассматривается как “белый
ящик” (т.е. ее текст открыт для пользования ). Происходит проверка логики
программы. Полным тестированием в этом случае будет такое, которое
приведет к перебору всех возможных путей на графе передач управления
программы (ее управляющем графе). Даже для средних по сложности программ
числом таких путей может достигать десятков тысяч. Если ограничиться
перебором только линейных не зависимых путей, то и в этом случае
исчерпывающее структурное тестирование практически невозможно, т. к.
неясно, как подбирать тесты , чтобы обеспечить “покрытие” всех таких
путей. Поэтому при структурном тестировании необходимо использовать другие
критерии его полноты, позволяющие достаточно просто контролировать их
выполнение, но не дающие гарантии полной проверки логики программы.
Но даже если предположить, что удалось достичь полного структурного
тестирования некоторой программы, в ней тем не менее могут содержаться
ошибки, т.к.
1) программа может не соответствовать своей внешней
спецификации, что в частности, может привести к тому, что в ее управляющем
графе окажутся пропущенными некоторые необходимые пути ;
2) не будут обнаружены ошибки, появление которых
зависит от обрабатываемых данных (т.е. на одних исходных данных программа
работает правильно, а на других - с ошибкой).
Таким образом, ни структурное, ни функциональное тестирование не
может быть исчерпывающим. Рассмотрим подробнее основные этапы тестирования
программных комплексов.
В тестирование многомодульных программных комплексов можно выделить
четыре этапа :
1) тестирование отдельных модулей ;
2) совместное тестирование модулей ;
3) тестирование функций программного комплекса (т.е.
поиск различий между разработанной программой и ее внешней спецификацией )
;
4) тестирование всего комплекса в целом (т.е. поиск
несоответствия созданного программного продукта сформулированным ранее
целям проектирования, отраженным обычно в техническом задании).
На первых двух этапах используются прежде всего методы структурного
тестирования, т.к.
на последующих этапах тестирования эти методы
использовать сложнее из-за больших размеров проверяемого программного
обеспечения ;
последующие этапы тестирования ориентированы на
обнаружение ошибок различного типа, которые не обязательно связаны с
логикой программы.
При тестировании как отдельных модулей, так и их комплексов должны
быть решены две задачи :
1) построение эффективного множества тестов ;
2) выбор способа комбинирования (сборки) модулей
при создании трестируемого варианта программы .
СТРУКТУРНОЕ ТЕСТИРОВАНИЕ .
Поскольку исчерпывающее структурное тестирование невозможно,
необходимо выбрать такие критерии его полноты, которые допускали бы их
простую проверку и облегчали бы целенаправленный подбор тестов.
Наиболее слабым из критериев полноты структурного тестирования
является требование хотя бы однократного выполнения (покрытия) каждого
оператора программы.
Более сильным критерием является так называемый критерий С1 : каждая
ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы
один раз. Для большинства языков программирования покрытие переходов
обеспечивает и покрытие операторов, но , например, для программ на языке
ПЛ/1 дополнительно к покрытию всех ветвей требуется всех дополнительных
точек входа в процедуру (задаваемых операторами ENTRY) и всех ON - единиц.
Использование критерия покрытия условий может вызвать подбор тестов,
обеспечивающих переход в программе, который пропускается при использовании
критерия С1 (например, в программе на языке Паскаль, использующей
конструкцию цикла WHILE х AND y DO... , применение критерия покрытия
условий требует проверки обоих вариантов выхода из цикла : NOT x и NOT
y ).
С другой стороны покрытие условий может не обеспечивать покрытия
всех переходов. Например, конструкция IF A AND B THEN... требует по
критерию покрытия условий двух тестов (например, A=true, B=false и
A=false, B=true ), при которых может не выполняться оператор,
расположенный в then - ветви оператора if.
Практически единственным средством, предоставляемым современными
системами программирования, является возможность определения частоты
выполнения различных операторов программы (ее профилизации). Но с помощью
этого инструмента поддержки тестирования можно проверить выполнение только
слабейшего из критериев полноты - покрытие всех операторов.
Правда, с помощью этого же инструмента можно проверить и выполнение
критерия С1. Но для этого предварительно текст программы должен быть
преобразован таким образом, чтобы все конструкции условного выбора (IF и
CASE
10
или SWITCH ) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом
случае все ветви алгоритма , не выполнявшиеся на данном тесте будут
“видимы” из таблицы частоты выполнения операторов преобразованной
программы.
Актуальной остается задача создания инструментальных средств,
позволяющих :
1) накапливать информации о покрытых и непокрытых
ветвях для всех использованных тестов ;
2) выделять разработчику еще не покрытые при
тестировании участки программы, облегчая выбор следующих тестов ;
3) поддерживать более мощные критерии полноты
структурного тестирования.
Совместное тестирование модулей.
Известны два подхода к совместному тестированию модулей : пошаговое
и монолитное тестирование.
При монолитном тестировании сначала по отдельности тестируются все
модули программного комплекса, а затем все они объединяются в рабочую
программу для комплексного тестирования.
При пошаговом тестировании каждый модуль для своего тестирования
подключается к набору уже проверенных модулей.
В первом случае для автономного тестирования каждого модуля
требуется модуль - драйвер ( то есть вспомогательный модуль, имитирующий
вызов тестируемого модуля) и один или несколько модулей - заглушек ( то
есть вспомогательных модулей, имитирующих работу модулей, вызываемых из
тестируемого). При пошаговом тестировании модули проверяются не
изолированно друг от друга, поэтому требуются либо только драйверы, либо
только заглушки.
А
B C D
E F
рис. 1
12
При сравнении пошагового и монолитного тестирования можно отметить
следующие преимущества первого подхода :
1) меньшая трудоемкость (для примера на рис.1 при
монолитном тестировании требуются 5 драйверов и 5 заглушек ; при пошаговом
тестировании требуются или только 5 драйверов - если модули подключаются
“снизу вверх ”, - или только 5 заглушек - если модули подключаются “сверху
вниз”) ;
2) более раннее обнаружение ошибок в
интерфейсах между модулями (их сборка начинается раньше, чем при
монолитном тестировании ) ;
3) легче отладка, то есть локализация ошибок
(они в основном связаны с последним из подключенных модулей ) ;
4) более совершенны результаты тестирования
(более тщательная проверка совместного использования модулей).
Есть приемущества и у монолитного тестирования :
1) меньше расход машинного времени (хотя из-за
большей сложности отладки может потребоваться дополнительная проверка
программы и это приемущество будет сведено на нет) ;
2) предоставляется больше возможностей для
организации параллельной работы на начальном этапе тестирования.
В целом более целесообразным является выбор пошагового
тестирования. При его использовании возможны две стратегии подключения
модулей : нисходящая и восходящая.
Нисходящее тестирование начинается с главного (или верхнего) модуля
программы, а выбор следующего подключаемого модуля происходит из числа
модулей, вызываемых из уже протестированных. Одна из основных проблем ,
возникающих при нисходящем тестировании, - создание заглушек. Это
тривиальная задача, т. к. как правило недостаточно, чтобы в заглушке
выполнялся вывод соответствующего информационного сообщенияи и возврат
всегда одних и тех же значений выходных данных.
Другая прблема , которую необходимо решать при нисходящем
тестировании, - форма представления тестов в программе, так как, как
правило, главный модуль получает входные данные не непосредственно, а
через специальные модули ввода, которые при тестировании в начале
заменяются заглушками. Для передачи в главный модуль разных тестов нужно
или иметь несколько разных заглушек, или записать эти тесты в файл во
внешней памяти и с помощью заглушки считывать их.
Поскольку после тестирования главного модуля процесс проверки может
продолжаться по-разному, следует придерживаться следующих правил :
а) модули, содержащие операции ввода-вывода, должны
подключаться к тестированию как можно раньше ;
б) критические (т.е. наиболее важные ) для
программы в целом модули также должны тестироваться в первую очередь.
12
Основные достоинства нисходящего тестирования :
уже на ранней стадии тестирования есть
возможность получить работающий вариант разрабатываемой программы ;
быстро могут быть выявлены ошибки, связанные с
организацией взаимодействие с пользователем.
Недостатки нисходящей стратегии продемонстрируются с помощью рис.2.
Допустим , что на следующем шаге тестирования заглушка модуля H
заменяется его реальным текстом. Тогда
1) может оказаться трудным или даже
невозможным построить такой тест на входе модуля J, который соотвеьствовал
бы любой заданной наперед последовательности значений данных на входе
модуля Н ;
2) не всегда окажется возможным легко
оценить соответствие значений данных на входе модуля J требуемым тестам
для проверки модуля Н;
3) т. к. результаты выполнения прграммы на
построенном для проверки модуля Н тесте выводятся не им, а модулем I ,
может оказаться трудным восстановлении дейсвительных результатов работы
модуля Н.
Другие проблемы, которые могут возникать при нисходящем
тестировании :
появляется соблазн совмещения нисходящего
проектирования с тестированием, что, как правило, неразумно, т.к.
проектирование - процесс итеративный и в нем неизбежен возврат на верхние
уровни и исправление принятых ранее решений, что обесценивает результаты
уже проведенного тестирования ;
может возникнуть желание перейти к
тестированию модуля следующего уровня до завершения тестирования
предыдущего по объективным причинам (необходимости создания нескольких
версий заглушек, использования модулями верхнего уровня ресурсов модулей
нижних уровней).
При восходящем тестировании прверка программы начмнается с
терминальных модулей (т.е. тех, которые не вызывают не каких других
модулей программы). Эта стратегия во многом противоположна нисходящему
тестированию (в частности, преимущества становятся недостатками и
наоборот).
Нет проблемы выбора следующего подключаемого модуля - учитывается
лишь то , чтобы он вызывал только уже протестированые модули. В отличие от
заглушек драйверы не должны иметь несколько версий, поэтому их разработка
в большенстве случаев проще (кроме того, использование средств
автоматизации и отладки облегчает создание как раз драйверов, а не
заглушек).
Другие достоинства восходящего тестирования :
поскольку нет промежуточных модулей
(тестируемый модуль является для рабочего варианта программы модулем
самого верхнего уровня), нет проблем, связанных с возможностью или
тружностью задания тестов ;
нет возможности совмещения проектирования с
тестированием ;
нет трудностей, вызывающих желание перейти
к тестированию следующего модуля , не завершив проверки предыдущего.
Основными недостатком восходящего тестирования является то , что
проверка всей структуры разрабатываемого программного комплекса возможна
только на завершающей стадии тестирования.
Хотя однозначного вывода о преимущества той или иной стратегии
пошаговаого тестирования сделать нельзя (нужно учитывать конкретные
характеристики тестируемой программы), в большинстве случаев более
предпочтительным является восходящее тестирование.
На третьем этапе тестирования программных комплексов (тестировании
функций) ипользуются прежде всего методы функционального тестирования.
Функциональное тестирование.
Обзор методов проектирования тестов при функциональеом
тестировании начнем с метода зквивалентного разбиения.
Т.к. нашей целью является построения множества тестов,
характеризующегося наивысшей вероятностью обнаружения большинстыва ошибок
в тестируемой программе, то тест из этого множества должен :
1) уменьшать (более чем на единицу) число других тестов, которые
должны быть разработанны для достижения заранее поставленной цели
“удовлетворительного” тестирования ;
2) покрывать собой значительную часть других
возможных тестов .
Другими словами :
1) каждый тест должен заключать в себе
проверку наибольшего числа задаваемых внешней спецификацией входных
условии (ограничений на входные данные) для того, чтобы минимизировать
общее число необходимых тестов ;
2) необходимо разбить область значений
входных данных на конечное число подобластей (которые будут называться
классами эквивалентности), чтобы можно было полагать каждый тест,
являющийся представителем некоторого класса, эквивалентным любому другрому
тесту этого класса (т.е. обнаруживающим одни и те же ошибки).
В общем случае использование термина “класс эквивалентности”
является здесь не вполне точным, т.к. выделенные подобласти могут
пересекаться.
Проектирование тестов по методу эквивалентного разбиения
проводится в два этапа :
выделение по внещней спецификации классов
эквивалентности;
построение множества тестов.
На первом этапе происходит выбор из спецификации каждого входного
условия и разбиение его на две или более группы, соответствующие так
называемым “правильным” (ПКЭ) и “неправильным” классом эквивалентности
(НКЭ), т.е. облатям допустых для программы и недопустимых значений входных
данных. Этот процесс зависит от вида входного условия. Если входное
условие описывает область (например, х 0), то определяются один ПКЭ (N>0) и один НКЭ (N= вместо >.
При проектировании тестов по методу эквивалентного разбиения будут
построены тесты для случаев возможности построения треугольника (например,
3, 4, 5) и невозможности его построения (например, 1, 2, 4), т.е. ошибка в
программе не будет обнаружена (на входные данные 1, 2, 3 будет выведено
сообщение “разносторонний треугольник”). Но подобный тест будет получен
при использовании метода анализа граничных условий.
Анализ граничных уловий - один из наиболее полезных методов
проектирования тестов. Но он часто оказывается неэффективным из-за того ,
что граничные условия иногда едва уловимы, а их выявление весьма трудно.
Общим недостатком двух рассмотренных выше методов функционального
тестирования является то, что при их примененине исследуются исследуются
возможные комбинации входных условий. Следует, правда, заметить, что из-за
весьма большого числа таких комбинаций, их анализ вызывает существенные
затруднения. Но существует метод (метод функциональных диаграмм),
позволяющий в этом случае систематическим образом выбрать высоко
эффективные тесты. Полезным побочным эффектом этого метода является
обнаружение неполноты и противоречивости во внешних спецификациях.
Функциональная диаграмма - это текст на некотором формальном языке,
на который транслируется спецификация, составленная на естественном или
полуформальном языках. Далее будет называться причиной отдельное входное
условие и следствием - выходное условие или преобразование системы (т.е.
остаточное действие программы, вызванное определенным входным условием или
их комбинацией). Например, для программы обновления файла изменение в нем
является преобразованием системы, а подтверждающее это изменение сообщение
- выходным условием.
Метод функциональных диаграмм состоит из шести основных этапов. На
первом из них (необязательном) внешняя спецификация большого размера
разбивается на отдельные участки (например, спецификация компилятора языка
программирования разбивается на участки, определяющие синтаксический
контроль отдельных операторов языка).
На втором этапе в спецификации выделяются причины и следствия, а на
третьем - анализируется семантическое содержание спецификации и она
преобразуется в булевский граф, связывающий причины и следствия и
называющийся функциональной диаграммой. На рис.3 приведены базовые символы
для записи функциональных диаграмм (каждый узел функциональной диаграммы
может находиться в состоянии 1 - “существует” - или 0 - “не существует”).
а) Тождество : (а(1(>b(1) & (а(0(>b(0)
а b
б) Отрицание : (а(1(>b(0) & (a(0(>b(1)
~
a b
в) Дизъюнкция : (a(1(b(1(>c(1) & (a(0&b(>0 >c(0)
a
( c
b
г) Конъюнкция : (a(1&b(1(>c(1) & (a(0(b(0(>c(0)
a
& c
b
рис.3
На четвертом этапе функциональная диаграмма снабжается комментариями,
которые задают ограничения на комбинации причин и следствий. На рис.4
приведены знаки комментариев, задающих эти ограничения.
а) Исключение одной из причин :
a
E ((a(1(b(1)^~(a(1&b(1)) ( (a(0&b(0)
b
б) Включение хотя бы одной причины :
a
I (a(1(b(1)&~(a(0&b(0)
b
в) Существуетодна и только одна причина :
a
O (a(1(b(1)&~(a(1&b(1)&~(a(0&b(0)
b
г) Одна причина влечет за собой лругую :
a
R ~(a(1&b(0)
b
д) Одно следствие скрывает в себе другое :
a
M (a(1&b(0)&(a(1&b(1)
b
рис.4
Пятый этап - функциональная диаграмма преобразуется в таблицу решений
:
выбирается следствие, которое устанавливается в 1 ;
находятся все комбинации причин (с учетом ограничений),
которые устанавливают выбранное следствие в 1
Реферат на тему: Программа эмуляции развития популяций животных
Институт Переподготовки Кадров
Уральского Государственного Технического Университета
Кафедра микропроцессорной техники
Оценка работы
Члены комиссии
Курсовая работа
ПРОГРАММА ЭМУЛЯЦИИ РАЗВИТИЯ
ПОПУЛЯЦИЙ ЖИВОТНЫХ
Пояснительная записка
Руководитель
Доцент
Слушатель
Группа СП-923 С.А.
Нягань
2001г.
СОДЕРЖАНИЕ
Содержание ....................................2
ВВЕДЕНИЕ.......................................3
1. ОСНОВНАЯ ЧАСТЬ..............................4
1. Методика взаимодействия популяций.........4
2. Описание программы........................4
3. Описание библиотеки Fauna1 ...............5
4. Описание библиотеки Mycrt ................6
5. Описание основного тела программы.........7
2. ЗАКЛЮЧЕНИЕ.................................8
Приложение 1. Основная программа..............9
Приложение 2. Библиотека Fauna1...............23
Приложение 3. Библиотека Mycrt................24
Приложение 4. Инструкция пользователя.........26
ВВЕДЕНИЕ.
Ради интереса было решено написать программу типа "Жизнь", с
некоторыми начальными условиями.
Условия были таковы, что в эмуляции должны участвовать
две популяции: хищники и травоядные, которые взаимодействовали
бы друг с другом путем поедания травоядных хищниками.
В процессе разработки программы были введены дополнительные
параметры:
- Возраст животных
- Минимальный и максимальный репродуктивный возраст
животных
- Количество пищи нужной животным для поддержания жизни
- Количество травы
- Процент восстановления травы
- Вероятность природных катаклизмов влияющих на популяции животных
1. ОСНОВНАЯ ЧАСТЬ.
2.1 Методика взаимодействия популяций.
Методика взаимодействий хищника и травоядного заключается в том, что и
хищники, и травоядные представлены в виде точек, которые передвигаются по
экрану с шагом в один пиксель. При этом заданно условие, если в радиусе
один пиксель от точки принадлежащей хищнику появляется точка принадлежащая
травоядному, то считается, что хищник съел травоядного.
Способ передвижения точек на экране был организован по алгоритму
случайного блуждания, т.е. передвижение по осям Х и Y с шагом в один
пиксель выбирается случайным образом.
Умершие своей жизнью травоядные считаются, как съевшиеся хищниками.
При недоедании обеими популяциями, особи умирают в процессе уменьшения
возраста, т.е. чем больше возраст животного, тем больше вероятность
погибнуть от голода. Из-за больших промежуточных расчетов учет по
недоеданию был выбран
так, что хищники учитываются один раз в год, а травоядные двенадцать раз в
год.
1.2 Описание программы.
Данная программа написана с использованием объектно-ориентированного
языка Borland Pascal 7.1 и построена на обработке массивов типа tosob
описанного в объектном модуле fauna1. Этот тип имеет следующие параметры:
x - расположение по координате Х экрана
y - расположение по координате Y экрана
age - возраст точки
col - цвет вывода на экран
Программа обеспечивает следующие операции:
- Задание параметров популяции травоядных
- Задание параметров популяции хищников
- Задание параметров окружающей среды
- Просмотр взаимодействия животных в графическом режиме
- Индикация результатов по выходу из режима просмотра
взаимодействия животных
- Выход из программы
При помощи зарезервированного слова "uses" к программе
подключается стандартные библиотечные модули TPCRT, GRAPH, DOS и
библиотечные модули написанные программистом-разработчиком MYCRT и FAUNA1.
В разделе описания констант и переменных были объявленны следующие
переменные:
- gd,gm типа integer для инициализации графики
- q,x,y,x1,y1,t,i,j,k,at,at1,ct1,ctp типа integer для
использования их в теле циклов
- g,m типа integer для задания начального количества животных
- v,w типа integer для задания максимального возраста животных
- ct,ch типа shortint для задания цвета отображаемых точек
- tmin,tmax,hmin,hmax,tp,hp типа integer для задания факторов
влияющих на репродуктивность животных
- tt типа integer для учета умерших и съеденных травоядных
- kata типа integer для задания вероятности природных катаклизмов
- ht типа integer для задания количества травоядных нужных хищнику для пищи
- ttt типа real для задания количества травы нужных травоядному для пищи
- tr типа real для задания процента восстановления количества
травы
- tree,tree1 типа longint для задания и модификации количества травы
- z типа longint для счетчика времени
- key типа boolean для отслеживания нажатия клавиш
- s,ss типа string размером в семнадцать символов для вывода
на экран в графическом режиме
- pal типа FillPatternType стандартная переменная библиотеки
GRAPH для хранения типа и цвета заливки графических фигур объектов
- tg массив объемом 4400 точек типа tosob для хранения травоядных
- hr массив объемом 1350 точек типа tosob для хранения хищников
1.3 ОПИСАНИЕ БИБЛИОТЕКИ FAUNA1
В данной библиотеке описано два типа данных Tposition и Tosob. Тип
Tposition имеет два параметра:
x - расположение по координате Х экрана
y - расположение по координате Y экрана
Задействованы функции:
getx - получение координаты Х
gety - получение координаты Y
А также процедура инициализации объекта init
Тип Tosob имеет четыре параметра:
x - расположение по координате Х экрана
y - расположение по координате Y экрана
age - возраст точки
col - цвет вывода на экран
Задействованы функции:
daizwet - получение цвета точки
daiage - получение параметра age
vidnoli - получение факта отображения на экране
процедуры:
blind - гашение точки
show - отображение точки
init - создание объекта Tosob
done - уничтожение объекта Tosob
1.4 ОПИСАНИЕ БИБЛИОТЕКИ MYCRT
В данную библиотеку включены функции и процедуры предназначенные для
работы в текстовом режиме.
Процедуры:
fon - задание цвета фона экрана
txt - задание цвета выводимых символов
ramka - вывод прямоугольника символами
186,187,188,200,201,205
colorwind - вывод окна с рамкой
Функции:
colword - преобразование чисел от одного до пятнадцати в строку с
наименованием цвета
mes - преобразование чисел от нуля до триста шестидесяти
пяти в строку с названием месяца
1.4 ОПИСАНИЕ ОСНОВНОГО ТЕЛА ПРОГРАММЫ
В основном модуле программы включены процедуры:
ini - вывод на экран массивов hr и tr со стартовыми
параметрами
tnew - движение точки принадлежащей массиву tr с
проверкой возраста
hnew - движение точки принадлежащей массиву hr с
проверкой возраста
trod - создание новых точек массива tr
hrod - создание новых точек массива hr
dead - процесс поглощения точки массива tr точкой
| массива hr
havka - процесс уничтожения точек массива tr в
зависимости от значения переменной tt
tmor - процесс уничтожения случайного количества
точек массива tr
hmor - процесс уничтожения случайного количества
точек массива hr
zasux - подсчет переменной tree
quit - выход из программы
herb - организация ввода стартовых значений переменных
для массива tr
beast - организация ввода стартовых значений переменных
для массива hr
env - организация ввода значений переменных для
задания переменных tree, tr, kata, q
info - организация информационного окна
gmenu - прорисовка основного меню
omenu - прорисовка меню Option
start - запуск графического режима и запуск основного
цикла
komenu - организация меню Option
gkmenu - организация основного меню
2. ЗАКЛЮЧЕНИЕ
3.
Данная программа представляет достаточно грубую модель
жизнедеятельности и взаимодействия живых организмов. Однако, даже такое
моделирование позволяет проследить основные моменты цикла жизни популяции.
При возможном добавлении некоторых дополнительных факторов, моделирование
может более приблизиться к реальной ситуации. Такими факторами могут
являться:
- Сезонные изменения климата
- «Технология» охоты
- Окружающая флора и фауна
- Влияние жизнедеятельности человека
- Взаимодействие особей внутри популяции
Данная программа может служить в качестве учебного пособия по
программированию на языке Pascal.
Приложение 1.
Основная программА
program fauna;
uses mycrt,dos,graph,fauna1,tpcrt;
var
q,x,y,x1,y1,gd,gm,t,i,j,k,AT,at1,ct1,ctp:integer;{общие}
g,v,m,w:integer;{}
ct,ch:shortint;{цвет}
tmin,tmax,hmin,hmax,tp,hp:integer;{детородность}
tt:integer;{трупы и съеденые травоядные за 1 год}
kata,ht:integer;
ttt,tr:real;
z,tree,TREE1:longint;
key:boolean;
s,ss:string[17];
tg:array[1..4400] of tosob; {green-травоядных}
hr:array[1..1350] of tosob; {red-хищников}
pal:FillPatternType;
{***********************************************************}
procedure ini;
begin
for i:=1 to g do
begin
at:=RANDOM(v)+1;
tg[i].init((random(630)+5),(random(462)+18),at,ct);
tg[i].show;
end;
for i:=1 to m do
begin
at:=random(w)+1;
HR[i].init((random(630)+5),(random(462)+18),at,ch);
hr[i].show;
end;
end;
{***********************************************************}
procedure tnew;
begin
I:=0;
REPEAT
I:=I+1;
begin
x:=tg[i].getx;
y:=tg[i].gety;
AT:=TG[I].DAIAGE;
CTP:=TG[I].DAIZWET;
if (z mod 365)=0 then
BEGIN
at:=at+1; {Happy New Year!}
TG[I].INIT(X,Y,AT,CTP);
END;
if at>v then {Old ?}
begin
tg[i].done;
tg[i].init(0,0,0,0);
tt:=tt+1;{умершее животное}
for j:=i+1 to g do
begin
x1:=tg[j].getx;
y1:=tg[j].gety;
at1:=tg[j].daiage;
ct1:=tg[j].daizwet;
tg[j].done;
tg[j-1].init(x1,y1,at1,ct1);
tg[j-1].show;
end;
TG[G].INIT(0,0,0,0);
G:=G-1;
I:=I-1;
CONTINUE;
end;
x:=tg[i].getx;
y:=tg[i].gety;
x:=x+(random(3)-1);
y:=y+(random(3)-1);
if x635 then x:=634;if y480 then y:=479;
AT:=TG[I].DAIAGE;
CTP:=TG[I].DAIZWET;
tg[i].done;
IF CT0 THEN
BEGIN
tg[i].init(x,y,at,CTP);
tg[i].show;
END;
END;
UNTIL I>=G;
end;
{***********************************************************}
procedure trod;
begin
if (z mod 365)=0 then {Happy New Year!}
begin
t:=0;
for i:=1 to g do
begin
at:=tg[i].daiage;
if (tmin4100 then break;
end;
g:=g+1+x;
if g>4000 then
begin
key:=true;
end;
end
else
begin
end;
end;
end;
{***********************************************************}
procedure hnew;
begin
I:=0;
REPEAT
I:=I+1;
begin
x:=hr[i].getx;
y:=hr[i].gety;
At:=hr[I].DAIAGE;
CTp:=hr[I].DAIZWET;
if (z mod 365)=0 then
BEGIN
at:=at+1; {Happy New Year!}
hr[I].INIT(X,Y,At,CTp);
END;
if at>w then {Old ?}
begin
hr[i].done;
hr[i].init(0,0,0,0);
for j:=i+1 to m do
begin
x1:=hr[j].getx;
y1:=hr[j].gety;
at1:=hr[j].daiage;
ct1:=hr[j].daizwet;
hr[j].done;
hr[j-1].init(x1,y1,at1,ct1);
hr[j-1].show;
end;
hr[m].INIT(0,0,0,0);
m:=m-1;
I:=I-1;
CONTINUE;
end;
x:=hr[i].getx;
y:=hr[i].gety;
x:=x+(random(3)-1);
y:=y+(random(3)-1);
if x635 then x:=634;if y480 then y:=479;
AT:=hr[I].DAIAGE;
CTp:=hr[I].DAIZWET;
hr[i].done;
IF CTp0 THEN
BEGIN
hr[i].init(x,y,at,CTp);
hr[i].show;
END;
END;
UNTIL I>=m;
end;
{**********************************************************}
procedure hrod;
begin
if (z mod 365)=0 then {Happy New Year!}
begin
t:=0;
for i:=1 to m do
begin
at:=hr[i].daiage;
if (hmin1000) or (m=g;
TG[G].INIT(0,0,0,0);
G:=G-1;
j:=j-1;
end
else
begin
end;
until j>=g;
end;
end;
{**********************************************************}
procedure havka;
begin
if ((z mod 365)=0) and (tt>0) then
begin
x1:=(tt div ht);{сколько прокормилось в этом году}
j:=0;
y1:=w;{max vozrast}
if x1=0 then
begin
for i:=1 to m do
begin
hr[i].init(0,0,0,0);
hr[i].done;
end;
end;
if (x10 then
begin
repeat
j:=random(m)+1;
hr[j].done;
hr[j].init(0,0,0,0);
for i:=j+1 to m do
begin
x1:=hr[i].getx;
y1:=hr[i].gety;
at1:=hr[i].daiage;
ct1:=hr[i].daizwet;
hr[i].done;
hr[i-1].init(x1,y1,at1,ct1);
hr[i-1].show;
end;
hr[m].done;
hr[m].init(0,0,0,0);
m:=m-1;
until m=y;
end;
end;
{***********************************************************}
procedure zasux;{засуха}
begin
tree:=tree - random(round(tree/10));
end;
{***********************************************************}
procedure quit;
begin
window(1,1,80,25);
fon(black);
clrscr;
GOTOXY(1,24);
txt(White);
WRITELN(' --------------------------------------------------
----------------------------');
txt(yellow);
WRITELN(' Antony Sokolov | FidoNet 2:5078/20.4 AKA
2:5078/20.666 AKA 2:5078/22.666');
txt(White);
WRITELN(' --------------------------------------------------
----------------------------');
end;
{***********************************************************}
procedure herb;{травоядные}
begin
colorwind(3,20,77,25,black,yellow);
gotoxy(32,1);
writeln('Правила ввода для травоядных');
gotoxy(2,2);write('Кол-во травоядных не более 3000.');
write(' Корм на месяц в килограммах. ');gotoxy(2,3);
write('Помет - кол-во детенышей. ');write('Цвет вывода от 1
до 15');
colorwind(40,10,65,19,black,green);
gotoxy(6,1);
txt(Yellow);
write('Травоядные');
gotoxy(2,2);
write('Кол-во: '); {начальное кол-во травоядных}
readln(g);
txt(yellow);
gotoxy(2,3);
write('Корм : ');{кол-во корма в год на одного
травоядного}
readln(ttt);
ttt:=ttt/1000;
gotoxy(2,4);
write('Помет: '); {рождаемость}
readln(tp);
gotoxy(2,5);
write('Min детородный: ');
read(tmin);
gotoxy(2,6);
write('Max детородный: ');
read(tmax);
gotoxy(2,7);
write('Max возрaст: ');
read(v);
gotoxy(2,8);
write('Цвет вывода: ');
read(ct);
colorwind(3,20,77,25,black,black);
end;
{***********************************************************}
procedure beast; {хищники}
begin
colorwind(3,20,77,25,black,yellow);
gotoxy(32,1);
writeln('Правила ввода для хищников');
gotoxy(2,2);write('Кол-во хищников не более 1000.');
write(' Корм - кол-во травоядных в год. ');gotoxy(2,3);
write('Помет - кол-во детенышей. ');write('Цвет вывода от 1
до 15');
colorwind(40,10,65,19,black,red);
gotoxy(8,1);
txt(Yellow);
write('Хищники');
gotoxy(2,2);
txt(yellow);
write('Кол-во: ');
readln(m);
gotoxy(2,3);
write('Корм: ');{начальное кол-во хищников}
readln(ht);
gotoxy(2,4);
write('Помет: ');{рождаемость}
readln(hp);
gotoxy(2,5);
write('Min детородный: '); {естественная смертность}
read(hmin);
gotoxy(2,6);
write('Max детородный: '); {естественная смертность}
read(hmax);
gotoxy(2,7);
write('Max возраст: '); {естественная смертность}
read(w);
gotoxy(2,8);
write('Цвет вывода: ');
read(ch);
colorwind(3,20,77,25,black,black);
end;
{***********************************************************}
procedure env ; {среда обитания}
begin
colorwind(3,20,77,25,black,yellow);
gotoxy(32,1);
writeln('Правила ввода для среды');
gotoxy(2,2);write('Кол-во травы не менее 1000.');
write('Процент восстановления любой.');gotoxy(2,3);
write('Катастрофы: 0 или 1 - нет, 2 и более-есть.');
gotoxy(2,4);
write('Задержка сообщений в мс. Рекомендуется не менее
1000');
colorwind(40,10,75,17,black,Magenta);
gotoxy(13,1);
txt(Yellow);
write('Среда обитания');
gotoxy(2,2);
txt(yellow);
write('Кол-во травы: ');{Кол-во востанавливаемой
пищи для травоядных в год}
readln(tree);
gotoxy(2,3);
write('Процент восстановления: ');
readln(tr);
gotoxy(2,4);
write('Наличие катастроф: ');
readln(kata);
gotoxy(2,5);
write('Задержка сообщений: ');
readln(q);
colorwind(3,20,77,25,black,black);
end;
{***********************************************************}
procedure info;
begin
fon(15);
colorwind(1,4,70,16,black,Lightblue);
txt(Green);
gotoxy(2,2);write('Травоядных-',g,' Хищников-',m);
str(ttt:1:2,s);
gotoxy(2,3);
write(s,' т. травы и ',ht,' туш нужно на прокорм животных');
gotoxy(2,4);
write('Max возраст травоядных ',v,', хищников ',w);
gotoxy(2,5);
write('Детородный возраст травоядных от ',tmin,' до ',tmax);
gotoxy(2,6);
write('Детородный возраст хищников от ',hmin,' до ',hmax);
gotoxy(2,7);
write('Помет травоядных до ',tp,', хищников до ',hp);
gotoxy(2,8);write('Травы ',tree,' тонн ');
str(tr:1:2,s);
gotoxy(2,9);write('Прирост травы на каждый месяц ',s,'%');
if (kata=0) or (kata=1) then s:='отсутствует' else
s:='присутствует';
gotoxy(2,10);write('Вероятность катаклизмов ',s);
s:=colword(ct);
gotoxy(2,11);write('Цвет травоядных ',s);
s:=colword(ch);
write(' Цвет хищников ',s);
end;
{***********************************************************}
procedure Gmenu;
begin
fon(black);
clrscr;
colorwind(1,1,80,4,black,darkgray);
txt(14);
gotoxy(5,2);
write(' S');
txt(white);
write('tart ');
txt(yellow);
write('O');
txt(white);
write('ption ');
txt(yellow);
write('Q');
txt(white);
write('uit');
END;
{***********************************************************}
PROCEDURE Omenu;
begin
colorwind(45,3,62,8,black,darkgray);
hiddencursor;
txt(14);
gotoxy(2,2);
write('H');
txt(white);
writeln('erbivorous');
txt(yellow);
gotoxy(2,3);
write('B');
txt(white);
writeln('east of prey');
txt(yellow);
gotoxy(2,4);
write('E');
txt(white);
write('nvironment');
end;
{***********************************************************}
procedure start;
begin
randomize;
gD := Detect;
InitGraph(gD,gM,'');
setfillpattern(pal,black);
z:=0;{начало эры}
tt:=0; {трупы и съеденные}
ini;
repeat
key:=false;
z:=z+1;
if ((z mod 365)=0) or ((z mod 365)=31) or ((z mod 365)=59)
or ((z mod 365)=90) or ((z mod 365)=120) or ((z mod
365)=151) or ((z mod 365)=181) or ((z mod 365)=212) or
((z mod 365)=242) or ((z mod 365)=273) or ((z mod
365)=303) or ((z mod 365)=334) then
begin
tree:=round(tree-g*ttt);{съели за месяц}
tree:=tree+round(tree*(tr/100));{прирост травы в месяц}
x:=round(tree*ttt);{травоядные умирают от недоедания}
if tree0 then
begin
dead;{хищники едят травоядных}
hnew;{естественная смертность хищников}
havka;{хищники умирают от недоедания}
hrod;{рождение хищников}
end;
if ((z mod 365)=180)and(g>0)and(m>0) then
begin
if random(kata)0 then
begin
x:=random(4);
if x=0 then
begin
x:=random(round(g/50))+5;
moveto(320,240);setcolor(Lightred);str(x,s);
Outtext('Болезнь травоядных унесла ');
Outtext(s);Outtext(' жизней ');
tmor;
end;
if x=1 then
begin
x:=random(round(m/40))+1;
moveto(320,240);setcolor(Lightred);str(x,s);
Outtext('Болезнь хищников унесла ');
Outtext(s);Outtext(' жизней');
hmor;
end;
if x=2 then
begin
zasux;
moveto(320,240);setcolor(Lightred);
str(tree1,s);Outtext('Засуха! Потеряно ');
Outtext(s);Outtext(' тонн травы');
delay(q);
end;
if x=3 then
begin
x:=random(round(g/50))+5;
moveto(0,240);setcolor(Lightred);str(x,s);
Outtext('Наводнение погубило ');Outtext(s);Outtext('
травоядных, ');
tmor;
x:=random(round(m/40))+1;
str(x,s);Outtext(s);Outtext(' хищников, ');
hmor;
zasux;
str(tree1,s);Outtext(s);Outtext(' тонн травы');
delay(q);
end;
delay(q);
bar(0,240,640,260);
end;
end;
if g>0 then trod;{рождение травоядных}
if g>4000 then break;
if keypressed then key:=true ;
if (g>4000) or (g0)and(m>0)and(ttt>0)and(tp>0)and(tmin>0)and(tmax>0)
and(ct>0)and(ht>0)and(hp>0)and(hmin>0)and(hmax>0)and
(Ch>0)and(tree>0)and (tr>0)and(kata>0)then
begin
start; gmenu; info;
key1:=false;
end;
end;
if (key2='o')or(key2='O') then
begin
Omenu; komenu;
GMENU;
info; key1:=false;
end;
if (key2='q') or (key2='Q')or(key2=#27) then
begin
key1:=true; quit;
end;
until key1=true;
end;
{***********************************************************}
{Body program}
begin
g:=1200;{травоядные кол-во}
v:=30;{возраст травоядного}
m:=200;{хищники кол-во}
w:=25;{возраст хищника}
ct:=yellow;ch:=red;
tmin:=2;tmax:=28;
hmin:=3;hmax:=24;
tp:=3;hp:=7;{детородность}
kata:=9; ht:=3; ttt:=1; tree:=1300; tr:=15.1;
hiddencursor;
GKMENU;
end.
Приложение 2.
Библиотека Fauna 1
{Init object}
unit fauna1;
interface
uses graph;
Type TPosition=object
x,y : integer;
procedure Init(x0,y0 : integer);
function getx : integer;
function gety : integer;
end;
type Tosob=object(TPosition)
color : word;
vidno : boolean;
AGE : INTEGER;
constructor Init(x0,y0,age0:integer;col:word);
destructor Done ; virtual ;
procedure Show ; virtual ;
procedure Blind ; virtual ;
function Daizwet : word;
function VidnoLi : boolean;
FUNCTION DAIAGE : INTEGER;
end;
Posob=^Tosob;
{metod Tposition}
Implementation
Procedure Tposition.Init(x0,y0:integer);
Begin
x:=x0;
y:=y0;
End;
Function Tposition.Getx:integer;
Begin GetX:=x End;
Function Tposition.Gety:integer;
Begin Gety:=y End;
Constructor Tosob.Init(x0,y0,age0:integer;col:word);
Begin
Tposition.Init(x0,y0);
AGE:=AGE0;
color:=col;
vidno:=false;
End;
Destructor Tosob.Done;
Begin
Tosob.blind;
End;
procedure Tosob.Show;
Begin
putpixel(TPosition.GetX, TPosition.GetY,color);
vidno:=True;
End;
procedure Tosob.Blind;
Begin
putpixel(TPosition.GetX, TPosition.GetY,GetBKColor);
vidno:=False;
End;
Function Tosob.Daizwet : word;
Begin Daizwet:=color End; | |
