Разработка и сопровождение программ

Автор: Пользователь скрыл имя, 05 Января 2012 в 15:21, отчет по практике

Описание работы

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

Работа содержит 1 файл

отчет по практике.doc

— 145.00 Кб (Скачать)

     Входные данные: команды 

     Выходные  данные: карта поля  

     Функции - ввод данных и предоставление пользователю возможности их редактирования. 

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

     Входные данные: команды, карта поля 

     Выходные  данные: карта поля , файл  

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

     Функции - считывание и сохранения структуры  лабиринта. 

     Модуль  визуализации 

     Входные данные: координаты комнат и дверей 

     Выходные  данные: отсутствуют 

     Внешние эффекты: на экране монитора появляется лабиринт и путь прохождения. 

     Функции – вывод на экран монитора информации. 

     Модуль  расчета кратчайшего пути лабиринта

     Входные данные: карта поля

     Выходные  данные: карта прохождения  

2.5 Разработка  тестов  для модулей

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

 
2.6 Разработка пояснительной записки

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

    1.        Титульный лист  

    2.        Задание на проектирование

    3.        Аннотация

    4.        Содержание

    5.        Список условных сокращений и обозначений

    6.        Техническое задание (если есть)

    7.        Введение

    8.        Разделы по основной части

    9.        Технико-экономическая оценка инженерных решений

    10.     Охрана труда

Пояснительная записка должна содержать следующие  разделы:

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

Назначение  и область применения - назначение программы, краткая характеристика области применения программы.

Технические характеристики - раздел должен содержать  следующие подразделы:

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

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

описание  и обоснование выбора метода организации  входных и выходных данных;

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

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

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

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

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

 

Раздел 3.Стадия РАБОЧИЙ ПРОЕКТ 

3.1 Программирование головной программы

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

3.2 Программирование модулей. Автономное тестирование

Модуль (программирование)

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

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

Основным  принципом модульного программирования является принцип «разделяй и  властвуй». Модульное программирование – это организация программы  как совокупности небольших независимых  блоков, называемых модулями, структура и поведение которых подчиняются определенным правилам.

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

Термин  «модуль» в программировании начал  использоваться в связи с внедрением модульных принципов при создании программ. В 70-х годах под модулем  понимали какую-либо процедуру или  функцию, написанную в соответствии с определенными правилами. Например: «Модуль должен быть простым, замкнутым (независимым), обозримым (от 50 до 100 строк), реализующим только одну функцию задачи, имеющим одну входную и одну выходную точку».

 Первым  основные свойства программного модуля более-менее четко сформулировал Парнас (Parnas): «Для написания одного модуля должно быть достаточно минимальных знаний о тексте другого». Таким образом, в соответствии с определением, модулем могла быть любая отдельная процедура (функция) как самого нижнего уровня иерархии (уровня реализации), так и самого верхнего уровня, на котором происходят только вызовы других процедур-модулей.

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

Автономное  тестирование 

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

Автономное  тестирование включает следующие работы:

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

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

3.3 Комплексное тестирование

Комплексное тестирование (system testing) контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

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

3.4 Корректировка программ

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

3.5Разработка  документов рабочего  проекта

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

Информация о работе Разработка и сопровождение программ