Этапы проектирования и жизненный цикл программ. Тестирование и отладка. Документирование программ

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ НЕФТЕГАЗОВЫЙ УНИВЕРСИТЕТ»

КАФЕДРА ИНФОРМАТИКИ И ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ

КУРСОВАЯ РАБОТА

по дисциплине «Программирование и основы алгоритмизации»

Тема 1: «Этапы проектирования и жизненный цикл программ. Тестирование и отладка. Документирование программ».

Тема 2: «Разработка приложения для Windows, представляющего собой модель базы данных по успеваемости студентов».

Выполнил

студент группы

УТСб-11-1

Лыткина Елена

Проверила

Мосягина Н.А.

Тюмень 2012

Содержание

Тема 1. «Этапы проектирования и жизненный цикл программ. Тестирование и отладка. Документирование программ»

1. Этапы проектирования

2. Жизненный цикл программ

2.1Модели жизненного цикла

3.Синтаксическая отладка программы

3.1 Тестирование и семантическая отладка

3.2.Структурное тестирование

3.3Совместимое тестирование модулей

3.4Семантическая отладка

4. Документирование программы

4.1Пользовательская документация программы

4.2Документация по сопровождению программы

Тема 2. «Разработка приложения для Windows, представляющего собой модель базы данных по успеваемости студентов»

2.1 Введение

2.2 Назначение и область применения

3. Разработка рабочего проекта

3.1Разработка программы

3.2 Спецификация программы

3.3 Текст программы

3.4 Описание программы

3.4.1 Общие сведения

3.4.2.Функциональное назначение

3.4.3 Описание логической структуры

3.4.4 Используемые технические средства

3.4.5 Вызов и загрузка

3.4.6 Входные данные

3.4.7 Выходные данные

3.5 Тестирование программы

Литература

Тема 1. «Этапы проектирования и жизненный цикл программ. Тестирование и отладка. Документирование программ»

1.Основные этапы проектирования программ

данных база разработка windows

Проектирование и последующая поддержка программного обеспечения включает несколько этапов:

разработка спецификации (specification);

проектирование или конструирование программы (design);

доказательство правильности проекта (verification);

кодирование, описание программ на языке программирования (coding);

отладка и проверка правильности программ (debugging and testing);

доработка и улучшение программ (refining);

производство окончательного программного продукта (production);

поддержка программного продукта в процессе его использования (maintenance).

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

какими должны быть входные данные;

какие данные являются корректными и какие ошибочными;

кто будет использовать разработанное программное обеспечение и каким должен быть интерфейс (средство общения с пользователем);

какие ошибки необходимо выявлять и какие сообщения желательно выдавать пользователю при наличии ошибок;

какие упрощения, предположения и допущения можно сделать по отношению к программам;

перечислить все особые ситуации, которые требуют дополнительного учета и специального рассмотрения;

какими должны быть выходные данные;

какая документация по программам должна быть подготовлена;

как развивать и улучшать программы в будущем.

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

В частности, общую схему любой программы можно (и даже полезно) представить в виде трех последовательных блоков, причем правильность этой схемы сомнений не вызывает:

Блок 1. Задание исходных данных.

Блок 2. Решение поставленной задачи.

Блок 3. Вывод полученных результатов.

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

Многое из того, что говорилось об исходных данных, относится и к окончательным результатам.

После разработки общей структуры программы необходимо выполнить следующие этапы:

установить, какие библиотечные (ранее разработанные) средства можно использовать и какие новые процедуры необходимо разработать;

разработать новые структуры данных и алгоритмы выполнения новых процедур;

обосновать (доказать) правильность проекта. При доказательстве правильности проекта в первую очередь необходимо проверить критические части алгоритмов, какими являются циклы и условные переходы. Выявление ошибок на этом этапе позволяет существенно упростить последующие этапы кодирования и отладки программ;

произвести кодирование, т. Е. описание алгоритмов и данных с помощью инструкций выбранного языка программирования. Многие рассматривают этот этап как главный в программировании, хотя в действительности он является относительно второстепенным;

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

В процессе выполнения этапов 1-5 накапливается определенный опыт, который дает основание для усовершенствования программы (этап 6). В этом случае дорабатываются или изменяются некоторые алгоритмы и модули. Усовершенствование не должно приводить к повторению цикла разработки с самого начала.

После завершения программного продукта он передается пользователям (этап 7).

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

2.Жизненный цикл программы

Жизненный цикл программы - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

Этапы Жизненного Цикла:

Анализ

Проектирование

Реализация

Сборка, тестирование, испытание

Внедрение (выпуск)

Сопровождение

Анализ

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

2) ПП разрабатывается для рынка. Нужно проводить маркетинговые исследования и найти какого продукта на рынке нет. Это связано с большим риском. Цель - разработка спецификации требований.

Проектирование

Цель - определение общей структуры (архитектуры) ПП. Результат - спецификация ПП. Эту работу выполняет системный программист.

Реализация

Написание программного кода. Реализация включает и разработку, и тестирование, и документацию.

Сборка, тестирование, испытание

Сборка всего, что сделано разными программистами. Тестирование всего программного комплекса. Отладка - поиск и устранение причин ошибок. Испытание - уточнение технических характеристик. В результате - гарантия работоспособности программы.

Внедрение (выпуск)

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

Выпуск - когда ПП разрабатывается на рынок. Начинается с этапа бета-тестирования. Соотв. Версия - бета-версия. Альфа-тестирование - тестирование людьми из той же организации, не участвовавших в разработке программ. Бета-тестирование - изготовление нескольких экземпляров ПП и отправка потенциальным заказчикам. Цель - еще раз проверить разработку ПП.

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

Сопровождение

Устранение замеченных в ходе эксплуатации ошибок. Внесение непринципиальных усовершенствований. Накопление предложений для разработки следующей версии.

Модели жизненного цикла

1.Waterfall («водопад», каскадная модель)

	Модель не предусматривает обратные связи (каждый элемент д.б. полностью закончен до перехода к следующему). При решении сложных задач это невозможно. Модель применима когда: 1) решается очень простая задача, 2) разрабатывается очередная версия ПП

Прототипирование

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

Итерационная модель

Задача разделяется на подзадачи и определяется очередность их реализации т.о., чтобы каждая следующая подзадачи расширяла возможности ПП. Успех существенно зависит от того сколь удачно разделены задачи на подзадачи и как выбрана очередность. Преимущества: 1) возможность активного участия заказчика в разработке, он имеет возможность уточнить свои требования в ходе разработки; 2) возможность тестирования вновь разрабатываемых частей совместно с ранее разработанными, это уменьшит затраты на комплексную отладку; 3) во время разработки можно начинать внедрение по частям.

3.Синтаксическая отладка программы

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

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

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

3.1Тестирование и семантическая отладка

Тестирование - это динамический контроль программы, т.е. проверка правильности программы при ее выполнении на компьютере.

Каждому программисту известно, сколько времени и сил уходит на отладку и тестирование программ. На этот этап приходится около 50% общей стоимости разработки программного обеспечения. Но не каждый из разработчиков программных средств может верно, определить цель тестирования. Нередко можно услышать, что тестирование - это процесс выполнения программы с целью обнаружения в ней ошибок. Но эта цель недостижима: ни какое самое тщательное тестирование не дает гарантии, что программа не содержит ошибок. Другое определение: это процесс выполнения программы с целью обнаружения в ней ошибок. Отсюда ясно, что “удачным” тестом является такой, на котором выполнение программы завершилось с ошибкой. Напротив, “неудачным” можно назвать тест, не позволивший выявить ошибку в программе. Определение также указывает на объективную трудность тестирования: это деструктивный (т.е. обратный созидательному) процесс. Поскольку программирование - процесс конструктивный, ясно, что большинству разработчиков программных средств сложно “переключиться” при тестировании созданной ими продукции.

Основные принципы организации тестирования:

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

следует по возможности избегать тестирования программы ее автором, т.к. кроме уже указанной объективной сложности тестирования для программистов здесь присутствует и тот фактор, что обнаружение недостатков в своей деятельности противоречит человеческой психологии (однако отладка программы эффективнее всего выполняется именно автором программы);

по тем же соображениям организация - разработчик программного обеспечения не должна “единолично ” его тестировать (должны существовать организации, специализирующиеся на тестировании программных средств);

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

необходимо тщательно подбирать тест не только для правильных (предусмотренных) входных данных, но и для неправильных (непредусмотренных);

при анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать;

следует сохранять использованные тесты (для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика);

тестирования не должно планироваться исходя из предположения, что в программе не будут обнаружены ошибки (в частности, следует выделять для тестирования достаточные временные и материальные ресурсы);

следует учитывать так называемый “принцип скопления ошибок”: вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части;

следует всегда помнить, что тестирование - творческий процесс, а не относиться к нему как к рутинному занятию.

Существует два основных вида тестирования: функциональное и структурное. При функциональном тестировании программа рассматривается как “черный ящик” (то есть ее текст не используется). Происходит проверка соответствия поведения программы ее внешней спецификации. Возможно ли при этом полное тестирование программы? Очевидно, что критерием полноты тестирования в этом случае являлся бы перебор всех возможных значений входных данных, что невыполнимо.

Поскольку исчерпывающее функциональное тестирование невозможно, речь может идти о разработки методов, позволяющих подбирать тесты не “вслепую”, а с большой вероятностью обнаружения ошибок в программе. При структурном тестировании программа рассматривается как “белый ящик” (т.е. ее текст открыт для пользования). Происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей на графе передач управления программы (ее управляющем графе). Даже для средних по сложности программ числом таких путей может достигать десятков тысяч.

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

В тестирование многомодульных программных комплексов можно выделить четыре этапа:

тестирование отдельных модулей;

совместное тестирование модулей;

тестирование функций программного комплекса (т.е. поиск различий между разработанной программой и ее внешней спецификацией );

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

На первых двух этапах используются, прежде всего, методы структурного тестирования, т.к. на последующих этапах тестирования эти методы использовать сложнее из-за больших размеров проверяемого программного обеспечения; последующие этапы тестирования ориентированы на обнаружение ошибок различного типа, которые не обязательно связаны с логикой программы.

3.2Структурное тестирование

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

Наиболее слабым из критериев полноты структурного тестирования является требование хотя бы однократного выполнения (покрытия) каждого оператора программы. Более сильным критерием является так называемый критерий С1: каждая ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз.

Использование критерия покрытия условий может вызвать подбор тестов, обеспечивающих переход в программе, который пропускается при использовании критерия С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 или SWITCH) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом случае все ветви алгоритма, не выполнявшиеся на данном тесте, будут “видимы” из таблицы частоты выполнения операторов преобразованной программы.

Актуальной остается задача создания инструментальных средств, позволяющих:

накапливать информации о покрытых и непокрытых ветвях для всех использованных тестов;

выделять разработчику еще не покрытые при тестировании участки программы, облегчая выбор следующих тестов;

поддерживать более мощные критерии полноты структурного тестирования.

3.3Совместимое тестирование модулей

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

В первом случае для автономного тестирования каждого модуля требуется модуль - драйвер (то есть вспомогательный модуль, имитирующий вызов тестируемого модуля и один или несколько модулей - заглушек то есть вспомогательных модулей, имитирующих работу модулей, вызываемых из тестируемого). При пошаговом тестировании модули проверяются не изолированно друг от друга, поэтому требуются либо только драйверы, либо только заглушки. При сравнении пошагового и монолитного тестирования можно отметить следующие преимущества первого подхода:

меньшая трудоемкость (при монолитном тестировании требуются 5 драйверов и 5 заглушек; при пошаговом тестировании требуются или только 5 драйверов - если модули подключаются “снизу вверх ”, - или только 5 заглушек - если модули подключаются “сверху вниз”);

более раннее обнаружение ошибок в интерфейсах между модулями (их сборка начинается раньше, чем при монолитном тестировании);

легче отладка, то есть локализация ошибок (они в основном связаны с последним из подключенных модулей);

более совершенные результаты тестирования (более тщательная проверка совместного использования модулей).

При использовании пошагового тестирования возможны две стратегии подключения модулей: нисходящая и восходящая.

Нисходящее тестирование начинается с главного (или верхнего) модуля программы, а выбор следующего подключаемого модуля происходит из числа модулей, вызываемых из уже протестированных.

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

модули, содержащие операции ввода-вывода, должны подключаться к тестированию как можно раньше;

критические (т.е. наиболее важные) для программы в целом модули также должны тестироваться в первую очередь.

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

Проблемы, которые могут возникать при нисходящем тестировании: появляется соблазн совмещения нисходящего проектирования с тестированием, что, как правило, неразумно, т.к. проектирование - процесс итеративный и в нем неизбежен возврат на верхние уровни и исправление принятых ранее решений, что обесценивает результаты уже проведенного тестирования; может возникнуть желание перейти к тестированию модуля следующего уровня до завершения тестирования предыдущего по объективным причинам (необходимости создания нескольких версий заглушек, использования модулями верхнего уровня ресурсов модулей нижних уровней).

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

Другие достоинства восходящего тестирования: поскольку нет промежуточных модулей (тестируемый модуль является для рабочего варианта программы модулем самого верхнего уровня), нет проблем, связанных с возможностью или трудностью задания тестов; нет возможности совмещения проектирования с тестированием; нет трудностей, вызывающих желание перейти к тестированию следующего модуля, не завершив проверки предыдущего. Основными недостатком восходящего тестирования является то, что проверка всей структуры разрабатываемого программного комплекса возможна только на завершающей стадии тестирования. Хотя однозначного вывода о преимущества той или иной стратегии пошагового тестирования сделать нельзя (нужно учитывать конкретные характеристики тестируемой программы), в большинстве случаев более предпочтительным является восходящее тестирование.

3.4Семантическая отладка

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

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

Существует 3 способа отладки программы:

Пошаговая отладка программ с заходом в подпрограммы;

Пошаговая отладка программ с выполнением подпрограммы как одного оператора;

Выполнение программы до точки остановки.

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

Если в программе имеются уже отлаженные подпрограммы, то подпрограмму можно рассматривать, как один оператор программы и воспользоваться вторым способом отладки программ.

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

4.Документирование программы

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

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

4.1Пользовательская документация программы

Пользовательская документация программы объясняет пользователям, как они должны действовать, чтобы использовать данную программу. Она необходима, если программа предполагает какое-либо взаимодействие с пользователями. К такой документации относятся документы, которыми руководствуется пользователь при установке программы.

Состав пользовательской документации зависит от аудиторий, на которую ориентировано данное ПО, и от режима использования документов. Аудитория - это пользователи, у которых есть необходимость в определенной пользовательской документации. Хороший пользовательский документ зависит от правильного выбора аудитории, для которой он предназначен.

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

4.2Документация по сопровождению программы

Документация по сопровождению программы описывает программу с точки зрения её разработки. Эта документация необходима, если программа предполагает изучение того, как она сконструирована.

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

Документация по сопровождению программы можно разбить на две группы:

1. документация, определяющая строение программ и структур данных программы и технологию их разработки;

2. документацию, помогающую вносить изменения в программу.

Документация первой группы содержит итоговые документы каждого технологического этапа разработки. Она включает следующие документы:

Внешнее описание;

Описание архитектуры программы, включая внешнюю спецификацию;

Описание модульной системы, включая внешнюю спецификацию каждого включенного модуля;

Для каждого модуля - его спецификация и описание его строения;

Тексты модулей на выбранном языке программирования;

Документы второй группы содержат:

Руководство по сопровождению программы, которое описывает известные проблемы вместе с программой, описывает, какие части программы являются аппаратно и программно зависимыми.

Тема 2. «Разработка приложения для Windows, представляющего собой модель базы данных по успеваемости студентов»

2.1 Введение

Задание на курсовую работу по дисциплине «Программирование и основы алгоритмизации».

Студент группы УТСб-11-1 Лыткина Елена Николаевна.

Направление «Управление в технических системах»

Тема: Разработка приложения для Windows, представляющего собой модель базы данных по успеваемости студентов.

Условие задачи: Описать структуру с именем MARSH с полями: BEGST-название начального пункта маршрута; TERM-название конечного пункта маршрута; NUMER-номер маршрута. Написать программу, выполняющую следующие действия:

ввод (с клавиатуры и из файла) данных в массив TRAFFIC с элементами типа MARSH (записи упорядочены по номерам маршрутов);

вывод информации о маршруте, номер которого введен с клавиатуры;

если таких маршрутов нет, выдать сообщение.

Задание выдано: Мосягина Н.А. « » _______2012 года. Подпись ______.

2.2 Назначение и область применения.

Данная программа может быть использована для создания базы данных в типизированном файле, а также является примером использования записей и типизированных файлов.

2.3 Технические характеристики.

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

Программа в основном состоит из процедур: процедура добавления данных, процедура вывода, процедура сортировки, процедура вывода определенного маршрута.

Входные данные находятся в файле, также их можно добавить в файл из клавиатуры, выход идет на окно модуля CRT.

Программа работает на любой ОС, на которой работает pascal abc, например windows 7 x64, среда разработки - pascal abc.

Разработка программы

1. Заголовок окна модуля crt

2. Рабочая область, на которой выводится и вводится вся необходимая информация.

3.2 Спецификация программы

Обозначение	Наименование	Примечание
lena.pas	Файл проекта	Основная программа, написанная с помощью процедур
modul.pas	Модуль с процедурами	Находится в той же папке, что и программа
CRT	Библиотечный файл	Обеспечивает работу с экраном

Текст программы

Файл lena.pas.pas

uses crt,modul;

var routes:file of marsh; name:string[30]; a:string;

begin

name:='c:\routes.txt';

assign(routes,name);

writeln('Дописать в файл данные с клавиатуры? Если да введите "да" либо "yes"');

read(a);

if (a='yes') or (a='да') then inputmarsh(routes);

sortirovka(routes);

outputmarsh(routes);

outputnum(routes);

end.

Модуль modul.pas

unit modul;

interface

uses crt;

type marsh=record

BEGST:string[20];// поле начального маршрута

TERM:string[20];// поле конечного маршрута

NUMER:integer;//поле номера маршрута

end;

procedure inputmarsh(var x:file of marsh);//процедура ввода в файл

procedure outputmarsh(x:file of marsh);//процедура вывода на экран

procedure sortirovka(var x:file of marsh);//сортировка

procedure outputnum(x:file of marsh);//процедура вывода маршрута

implementation

procedure inputmarsh(var x:file of marsh);

var a:marsh; i,b:integer;//объявляем буфер и 2 целые переменные

begin

reset(x);

seek(x,filesize(x));//ставится курсор в конец файла

writeln('Сколько данных о маршрутах вводить:');

read(b);//считывание количества маршрутов

for i:=1 to b do

begin

writeln('Введите название начального пункта:');

read(a.begst);//считывание поля начального маршрута

writeln('Введите название конечного пункта:');

read(a.term);//считывание поля конечного маршрута

writeln('Введите номер маршрута:');

read(a.numer);//поле с номером маршрута

if a.numer=0 then break;//в случае нулевого номера прерывается ввод

write(x,a);//запись введенного элемента в файл

end;

close(x);

end;

{Описание}

procedure outputmarsh(x:file of marsh);

var a:marsh;//объявляем буфер

begin

writeln('Все маршруты');

reset(x);

while not eof(x) do//запускается цикл вывода элементов до конца файла

begin

read(x,a);//чтение элемента в буфер

write('Номер: ',a.numer);//вывод на экран номера маршрута

write(' Нач. пункт: ',a.begst);//вывод на экран начального номера маршрута

write(' Конеч. пункт: ',a.term);//вывод на экран конечного номера маршрута

writeln();

end;

close(x);

end;

{Описание}

procedure sortirovka(var x:file of marsh);

var a: array[1..100] of marsh; i,j,n:integer; buffer:marsh;//объявляем массив для сортировки,целую-счетчик, две целые-циклы

begin

reset(x);

i:=1;

while not eof(x) do//запускается цикл заполнения массива до конца файла

begin

read(x,buffer);//чтение элемента в буффер

a[i]:=buffer;//заполнение буффером элемента массива

inc(i);//увеличение счетчика

end;

close(x);

n:=i-1;//реальное число элементов на 1 меньше-исправляем

{сортировка пузырьком по номерам маршрутов}

for i:=1 to n do

for j:=i+1 to n do

if a[i].numer>a[j].numer then

begin

buffer:=a[i];

a[i]:=a[j];

a[j]:=buffer;

end;

rewrite(x);//перезапись файла

for i:=1 to n do//цикл записи массива в файл

write(x,a[i]);

close(x);

end;

procedure outputnum(x:file of marsh);

var flag:boolean; buf:marsh; n:integer;//объявляем флажок,буфер и переменную с номером

begin

flag:=true;//флаг-истина, что значит маршутов нет

writeln('Введите номер маршрута:');

read(n);//чтение с клавиауры номера маршрута

reset(x);

while not eof(x) do//цикл поиска введенного номера

begin

read(x,buf);//чтение элемента в буфер

if buf.numer=n then//проверка на подходящий номер

begin

write('#',buf.numer);

write(' Начальный маршрут: ',buf.begst);

write(' Конечный маршрут: ',buf.term);

writeln();

flag:=false;//при нахождении маршрута флаг меняется

break;

end;

end;

if flag then writeln('Таких маршрутов нет!');//если флаг не менялся,зачит маршрутов не было найдено

close(x);

end;

end.

3.4 Описание программы.

3.4.1Общие сведения.

Название программы - «lena». Для нормального функционирования программы требуется Pascal abc. Программа написана на языке программирования pascal.

3.4.2 Функциональное назначение.

Данная программа может быть использована для создания базы данных в файл, также является примером создания типизированного файла.

3.4.3. Описание логической структуры.

В программе используется один тип - marsh, состоящий из полей: begst -название начального пункта маршрута. term - название конечного пункта маршрута,numer-номер маршрута. В программе есть также процедуры: inputmarsh (пополняет базу данных), outputmarsh (выводит на экран список с записями), sortirovka (сортирует записи в файле по номерам маршрута), outputnum (выводит на экран записи маршрут с введенным номером, либо сообщение что его нет).

3.4.4 Используемые технические средства.

Для создания программы был использован компьютер на базе процессора Intel i5-2520M, RAM DDR-3 4096Mb, HDD 500Gb (SATA-2), NVIDIA GeForce GT 555M 1024 Mb с ОС Windows 7 x64 Ultimate.

Минимальные системные требования: процессор не ниже Pentium MMX(266MHz), 64Mb RAM, 1 Mb Видеопамяти, около 10 Mb свободного места на диске с установленным pascal abc.

3.4.5 Вызов и загрузка.

Для запуска программы необходимо запустить файл lena.pas с помощью pascal abc.

3.4.6 Входные данные.

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

3.4.7 Выходные данные.

Список с записями, а также маршруты выводятся на окно CRT. Также информация сохраняется в файл routes.txt.

3.5 Тестирование программы

При запуске программы будет предложено добавить данные в файл:

Если ответить да, то программа спросит количество записей:

После ввода, начнется ввод данных:

После ввода будет выведен весь список маршрутов и предложено найти информацию об определенном маршруте:

Если маршрут существует, то выведется информация о нем

Программа завершается

Если при вводе ввести номер маршрута "0", то ввод данных прервется

Затем снова будет предложено найти маршрут.

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

Если ввести несуществующий маршрут, то выведется соответствующее сообщение:

Программа завершается.

Литература

1. Лекции по программированию и основам алгоритмизации, Мосягина Н. А. 2012 г.

2. Встроенный справочник в pascal abc.

3. Раздел помощи «примеры» в pascal abc.

4. «Объектно-ориентированное программирование в C++», М. - «ПИТЕР», 2004 г.

Размещено на Allbest.ru

...