EALOOP

77 Н

ES4

ES3

ES2

ES1

L1 15

78 Н

DFMO

AIS

LOS

79 Н

FL

TQRSS

ESOVR

ESUNF

TDFMO

TAIS

TLOS

7A Н

ЕРАТ1

EPAT0

ETAOS

EQZMON

ERLOOP

ELLOOP

EALOOP

7B Н

ES4

ES3

ES2

ES1

L1 16

7C Н

DFMO

AIS

LOS

7D Н

FL

TQRSS

ESOVR

ESUNF

TDFMO

TAIS

TLOS

7E Н

ЕРАТ1

EPAT0

ETAOS

EQZMON

ERLOOP

ELLOOP

EALOOP

7F Н

ES4

ES3

ES2

ES1

Рис. 1.11. Распределение памяти ОЗУ данных процессора.

Потом инициализируется последовательный порт Р3 на прием. Инициализируется таймер, выбор 1_го таймера, перевод его в третий режим работы, загрузка константы скорости в таймер для 9600 Бод, разрешение работы таймера. Инициализация последовательного порта проходит следующим образом: порт устанавливается в режим 9_бит с программируемой скоростью, устанавливается адрес для записи принятых значений, выбирается номера канала, идет разрешение приёма сообщений с взведённым 9_м битом, разрешение работы приёмопередатчика, разрешение прерываний от приёмопередатчика, общее разрешение прерываний, сброс бита разрешения приёма. После этого выполняется основной цикл программы: ожидание прерывания либо от любого из линейных интерфейсов с переходом на подпрограмму перезаписи карты памяти части битов внутренних регистров линейных интерфейсов, либо от последовательного порта с переходом на подпрограмму связи с внешней ПЭВМ через последовательный порт.

Подпрограмма перезаписи карты памяти части битов внутренних регистров линейных интерфейсов состоит из четырех последовательных вызовов подпрограмм RDPSR, RDTSR, DRCR2 и RDCR1 с предварительным занесением в регистр R1 соответствующих адресов регистров, используя таблицу, приведенную на рисунке 1.10. Выполнение подпрограммы происходит в режиме маскирования прерываний. После перезаписи карты памяти снимаются все флаги прерываний линейных интерфейсов и происходит выход из подпрограммы.

Подпрограмма связи с внешней ПЭВМ через последовательный порт вызывается при появлении прерывания от последовательного порта. Она также с запрещения всех прерываний. Инициализируется прием и прослушивается порт на приход старт байта. В случае его получения происходит инициализация чтения данных из памяти. Считается контрольная сумма для передачи бита четности и происходит поблочная передача данных. Для передачи всех 64 байт требуется 64 сеанса связи. Такая организация работы выбрана не случайно. В разделе, где упоминалось об основах асинхронной последовательной связи, приводились причины, по которым данный способ взаимодействия внешней ПЭВМ с последовательным портом является оптимальным. При втором сеансе связи приема старт байта не происходит. Это говорит о продолжении уже начатой передачи данных. Смотрится, является ли этот байт признаком передачи последнего кусочка данных. В этом случае считается контрольная сумма и выполнение подпрограммы прекращается. Иначе мы продолжаем поблочно читать данные из памяти и передавать их внешней ПЭВМ через последовательный порт.

1.7.3 Тестирование и отладка программы

После окончания этапа программирования, т.е. собственно процесса написания программы, проводится ее проверка для обнаружения и исправления возможных ошибок. На эмуляторе микропроцессора АТ89С51 проверяется корректность кода программы по содержимому различных регистров процессора. В контрольных точках программы, выбранных для удобства после каждого логически законченного куска кода, мы смотрим содержимое регистра R7. Внесенные в программу отладочные строки для контроля ее пошагового выполнения позволяют своевременно выявлять неточности реализации общего алгоритма изделия ТС16Е1. Применение модульного принципа тестирования программы существенно облегчает этот процесс.

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

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

1.7.4 Оформление программы и ее возможная модернизация

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

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

1.7.5 Надежность программного продукта

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

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

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

проверку исправности системы;

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

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

поиск и локализацию неисправностей в системе.

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

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

В ходе выполнения данного дипломного проекта была разработана программа управления автоматизированным комплексом многоканальной связи. Предъявленные в техническом задании к проекту требования выполнены полностью: программное обеспечение для процессора АТ89С51 разработано в соответствии с общим алгоритмом ПО изделия ТС16Е1, ОЗУ данных процессора АТ89С51 использовано для хранения карты памяти состояний части битов регистров CR1, CR2, TSR и PSR 16_ти линейных интерфейсов по заданным адресам в заданном порядке, обеспечено своевременное обновление карты памяти состояний части битов регистров CR1, CR2, TSR и PSR всех интерфейсов через подпрограмму обработки прерываний линейных интерфейсов, обеспечена возможность передачи карты памяти состояний оговоренных регистров, взаимодействуя с внешней ПЭВМ, используя интерфейс RS_232, через последовательный порт Р3. Подробно описана структура программы, алгоритмы построения и работы всех трех ее частей для дальнейшего использования, модернизации и возможного применения отдельно взятых частей кода при разработке подобных программных продуктов для устройств связи.

2. Технологическая часть

2.1 Требования к программным системам

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

правильность

точность

совместимость

надежность

универсальность

защищенность

полезность

эффективность

проверяемость

адаптируемость

Будем говорить, что программа является:

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

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

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

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

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

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

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

эффективной, если объем требуемых для ее работы ресурсов ЭВМ не превышает допустимых пределов.

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

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

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

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

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

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

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

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

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

2.2 Этапы решения задачи на ЭВМ

1. Постановка задачи.

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

Задание на разработку программы по форме и характеру должно быть аналогично техническому заданию на разработку какого-либо технического продукта.

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

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

2. Составление проекта.

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

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

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

3. Алгоритмизация.

На этот этап иногда смотрят как на вспомогательный, подготовительный к выполнению следующего этапа считающегося основным, на котором производится написание программы на выбранном языке программирования. Введение такого «промежуточного» этапа преследует цель облегчить выполнение этапа 4 и тем самым предотвратить возникновение многих ошибок при его осуществлении для сложных задач. Формулировка алгоритма закрепляет последовательность основных шагов выполнения программы, четко фиксирует функциональное содержание ее частей, позволяет уделить необходимое внимание простоте логической структуры разрабатываемой программы. Этап алгоритмизации является совершенно необходимым также, в случае, если язык, на котором предстоит программировать, не вполне освоен программистом-разработчиком и предвидятся. Трудности при его использовании на следующем этапе.

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

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

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

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

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

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

4. Программирование.

В случае, когда на предыдущем этапе был получен детально разработанный алгоритм, составление программы на выбранном для программирования языке сводится к переводу этого алгоритма на язык программирования. Основные трудности и, следовательно, причины ошибок на этом этапе заключаются, во-первых, в необходимости знания всех требований и ограничений выбранного языка программирования и, во-вторых, в необходимости постоянного внимания ко многим деталям языка, которые приходится учитывать в ходе написания программы. Если этап 3 был выполнен некачественно и алгоритм представлен недостаточно детально, то его доводку придется выполнять «на ходу», во время программирования. Это затруднит процесс программирования-перевода и поведет к возникновению дополнительных ошибок в программе. Чем более процесс программирования будет походить на перевод, чем более механическим будет такой перевод, тем более легким будет составление программы и тем меньше возникнет ошибок на этом этапе, самом щедром на ошибки.

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

Компиляция.

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

6. Отладка.

На этапе отладки производится обнаружение с помощью ЭВМ ошибок в программе и их исправление. Этап отладки можно разделить на три подэтапа:

6.1. Контроль правильности программы.

6.2. Локализация ошибок.

6.3. Исправление ошибок.

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

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

На этапе 6.3 производится исправление ошибок, выявленных на этапе 6.2. Исправления вносятся как в программу, так и в алгоритм, если он затрагивается этими исправлениями.

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

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

7. Тестирование.

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

8. Оформление программы.

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

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

9. Отчет о работе.

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

10. Модернизация.

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

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

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

2.3 Проектирование системы

К основным стадиям развития программной системы относятся следующие:

постановка задачи;

разработка;

реализация;

испытания;

эксплуатация системы.

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

2.3.1 Определение основных элементов системы

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

2.3.2 Структурный анализ

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

2.3.3 Структурное проектирование

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

2.3.4 Реализация и испытания

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

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

В конечном итоге вся система в целом будет испытана и готова к внедрению в промышленную эксплуатацию.

2.4 Вспомогательные средства проектирования

2.4.1 Графическая схема задания

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

Рис. 2.2. Графическая схема задания.

2.4.2 Развернутый план проекта системы

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

A. Функции системы. Поясняется назначение прикладной системы, приводится перечень основных процедур и обрабатываемых данных.

B. Сфера применения. Характеризуется круг пользователей, на которых ориентирована разрабатываемая система.

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

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

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

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

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

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

III. Связь с внешней средой. Описывается взаимодействие пользователей с системой.

A. Вход системы. Определяются форматы данных всех типов, вводимых пользователями, а также внутренняя структура данных. Эта информация служит руководством при разработке бланков входных форм и подготовке данных.

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

C. Управляющие параметры. Перечисляются параметры, задаваемые при настройке системы на конкретную конфигурацию технических и программных средств.

D. Рабочие инструкции. Дается общий обзор содержания инструкций. Данная информация используется при составлении инструкций для обслуживающего персонала.

IV. Качество системы.

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

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

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

D. Защита информации. Описываются средства, обеспечивающие сохранность данных и авторизацию доступа, используемые способы кодирования.

V. Документация по системе.

A. Пособия и руководства. Приводится перечень документации, прилагаемой к системе, - пособий, форм отчетности, рабочих описаний, системной и программной документации.

B. Спецификации программ. Дается общее функциональное описание отдельных программ, входящих в состав системы. Эта информация служит руководством при разработке программ.

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

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

2.5 Организация процесса проектирования

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

составление рабочих спецификаций

составление перечня характеристик

внешнее описание данных

внешнее описание программ

разработка архивов данных

разработка программных модулей

разработка тестовых задач

кодирование программных модулей

проверка программных модулей

объединение программных модулей

испытание системы в целом

комплектация программной сопровождающей документации

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

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

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

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

2.6 Необходимость тестирования программных продуктов

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

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

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

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

2.7 Отладка и общие принципы тестирования программ

Начинающий программист, как правило, переоценивает свои возможности и, проводя разработку программы, исходит из того, что в его программе ошибок не будет. Исходя из такого представления о своих способностях, этот программист и строит свою работу над программой, и каждый неверный результат, каждая найденная ошибка вызывают у него изумление и считаются, конечно, последними. Вследствие такого подхода получение надежных результатов откладываются на неопределенный срок. Только приобретя достаточный опыт, программист понимает справедливость древнего высказывания: «Человеку свойственно ошибаться». Оказывается, что практически невозможно составить реальную программу без ошибок, и почти невозможно для достаточно сложной программы быстро найти и устранить все имеющиеся в ней ошибки. Трудности программирования и отладки программы подчеркивает следующий афоризм: «В любой программе есть по крайней мере одна ошибка». Таким образом, можно сказать, что наличие ошибок в только что разработанной программе это вполне нормальное явление.

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

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

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

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

Существует два основных подхода к тестированию:



Рис. 2.3. Технология отладки программ

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

2. Тестирование программы как «белого ящика». Стратегия белого ящика, или стратегия тестирования, управляемого логикой программы, позволяет использовать внутреннюю структуру программы. В этом случае программист получает тестовые данные путем анализа логики программы. Основной алгоритм тестирования программы представлен на рис. 2.3.

Также существует 3 основных способа тестирования: алгоритмическое, аналитическое и содержательное.

Алгоритмическое тестирование

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

Функциональное или аналитическое тестирование

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

Содержательное тестирование

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

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

2.8 Типы тестов

Рассмотрим несколько основных типов тестов программного обеспечения:

Вырожденный тест

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

Тест граничных значений

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