Logo GenDocs.ru


Поиск по сайту:  


Ответы к госэкзамену по технологии разработки программных продуктов для ССУЗов - файл 1.doc


Ответы к госэкзамену по технологии разработки программных продуктов для ССУЗов
скачать (143.5 kb.)

Доступные файлы (1):

1.doc144kb.16.11.2011 03:15скачать

содержание

1.doc

Реклама MarketGid:



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


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

Процессы жизненного цикла ПО

  1. Основные:

    1. Приобретение (действия и задачи заказчика, приобретающего ПО)

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

    3. Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)

    4. Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)

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

  2. Вспомогательные

    1. Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)

    2. Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).

    3. Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)

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

    5. Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)

    6. Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

    7. Аудит (определение соответствия требованиям, планам и условиям договора)

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

  3. Организационные

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

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

    3. Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)

    4. Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:

  • Инициирование приобретения

  • Подготовка заявочных предложений

  • Подготовка и корректировка договора

  • Надзор за деятельностью поставщика

  • Приемка и завершение работ

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

Формирование требований к системе

Формирование списка программных продуктов

Установление условий и соглашений

Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

  1. Стадии;

  2. Результаты выполнения работ на каждой стадии;

  3. Ключевые события — точки завершения работ и принятия решений.

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

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

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

Каскадная модель

Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

  • Формирование требований;

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

  • Реализация;

  • Тестирование;

  • Внедрение;

  • Эксплуатация и сопровождение.


Спиральная модель

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

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

необходимость выполнения еще одной итерации;

степень полноты и точности понимания требований к системе;

целесообразность прекращения проекта.

Один из примеров реализации спиральной модели — RAD (англ. Rapid Application Development, метод быстрой разработки приложений).


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

Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который представляет рациональное сочетание этих моделей. Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов (RUP, MSF, XP).


  1. ^

    Характеристики качества программных продуктов.


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

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

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

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

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

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

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

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

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


  1. ^

    Общие понятия отладки. Виды ошибок.


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

Из всех этапов проектирования логики программных модулей этап отладки является наименее формализованным. В нем выделяют две задачи:

  • определение природы ошибки;

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

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

Наиболее распространенными и наименее эффективными для отладки являются так называемые методы ‘грубой силы’. К ним относят:

  • отладку с использованием дампа памяти;

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

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

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

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

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

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

  • метод индукции;

  • метод дедукции.

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

Метод индукции включает:

  • определение данных тестирования, имеющих отношение к ошибке;

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

  • в результате анализа (п.2) выдвигается гипотеза о причине ошибки;

  • для подтверждения гипотезы 3 разрабатывается один или больше тестов, которые должны либо подтвердить, либо опровергнуть гипотезу;

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

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

  • перечисление возможных причин или гипотез:

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

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

  • доказательство выбранной гипотезы совпадает с п.4 и п.5 метода индукции.



  1. ^

    общие понятия тестирования. виды тестирования


Тестирование (testing), как мы уже выяснили,—процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки.

Доказательство (proof) попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Многие исследователи считают доказательство альтернативой тестированию — взгляд во многом ошибочный; более подробно это обсуждается в гл. 17.

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

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

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

Отладка (debugging) не является разновидностью тестирования. Хотя слова “отладка” и “тестирование” часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки.

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

Тестирование сопряжении (integration testing) контроль сопряжении между частями системы (модулями, компонентами, подсистемами).

Тестирование внешних функций (external function testing)контроль внешнего поведения системы, определенного внешними спецификациями.

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

Тестирование приемлемости (acceptance testing) проверка соответствия программы требованиям пользователя.

Тестирование настройки (installation testing) — проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.

^ ВОСХОДЯЩЕЕ ТЕСТИРОВАНИЕ.


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

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


^ НИСХОДЯЩЕЕ ТЕСТИРОВАНИЕ.


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

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

Интересен и второй вопрос: в какой форме готовятся тестовые данные и как они передаются программе? Если бы головной модуль содержал все нужные операции ввода и вывода, ответ был бы прост:

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

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

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

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

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

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


  1. ^

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


Работая над программой, программист, особенно начинающий, должен хорошо представлять, что программа, которую он разрабатывает, предназначена, с одной стороны, для пользователя, с другой — для самого программиста. Текст программы нужен прежде всего самому программисту, а также другим людям, с которыми он совместно работает над проектом. Поэтому для того, чтобы работа была эффективной, программа должна быть легко читаемой, ее структура должна соответствовать структуре и алгоритму решаемой задачи. Как этого добиться? Надо следовать правилам хорошего стиля программирования. Стиль программирования — это набор правил, которым следует программист (осознано или потому, что "так делают другие") в процессе своей работы. Очевидно, что хороший программист должен следовать правилам хорошего стиля.

Хороший стиль программирования предполагает:

  • использование комментариев;

  • использование несущих смысловую нагрузку имен переменных, процедур и функций;

  • использование отступов;

  • использование пустых строк.

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

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

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

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

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

Комментарии


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


Комментарии можно разделить на два вида:

1) Многострочные комментарии

2) Однострочные комментарии


Однострочные это комментарии, которые действуют только в одной строке (от символа комментария до конца строки).

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


  1. ^

    основные понятия струтурного программирования


История, 70-е годы. Языки программирования Assembler, Fortran, Cobol.

Используется оператор GoTo – переход по метке.

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

Последовательность

Условие

Цикл с предусловием

Цикл с постусловием

Вариант

Категорически предлагалось отказаться от оператора GoTo

“Свобода” программистов подверглась ограничению, но программы стали нагляднее и понятнее.

Структурное программирование придало ПО совершенно новый вид – это было революцией.


Современные языки программирования изначально включают конструкции СП и помогают программисту разрабатывать структурированные программы. Термин «структурное программирование» почти не применяется, потому что все программы структурированы, цель достигнута.

Следующее технологическое достижение в области разаботки ПП – объектно-ориентированное программирование.


^ Метод реализации ПП «сверху-вниз»

На стадии проектирования задача разбивается на модули, строится схема иерархии модулей.

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

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

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

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

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


Современные средства разработки Delphi, C++Builder, MS Visual Studio имеют встроенные средства ведения проекта. Visual-конструкторы создают заготовки стандартных модулей (например, Form), встраивают вызовы некоторых функций и создают код-заготовку функции (рамочный код – заголовок+завершение), т.е. в значительной мере помогают разработчикам создавать «скелет» программы.


  1. ^

    автоматичемкие средства отладки Turbo Pascal 7.0. Понятие трассировки и пошагового выполнения программы


Интегрированный отладчик Turbo Pascal.


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

Интегрированный отладчик Turbo Pascal имеет все описанные выше возможности и даже более того. Он представляет собой встроенную часть интегрированной усовершенствованной среды Turbo Pascal (IDE): для использования предлагаются две основные функции меню (Run, Debug), а также некоторые клавиши для команд отладчика. Для дополнительной информации об IDE горячих клавишах см. главу 7 "Справочник по IDE" или справочную информацию о Turbo Pascal.


^ Что может делать отладчик.

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

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

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


^ Обзор возможностей отладчика:

Трассировка. F7

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

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

^ Переход на курсор. F4

Run/Go to Сursor Вы можете передвинуть курсор на определенную строку в Вашей программе, а затем указать отладчику выполнить программу до достижения этой строки. Это позволяет обходить циклы или другие утомительные участки программы, это также позволяет перебираться в то место программы, откуда Вы хотите начать отладку.

Прерывание.

С помощью команды Debug/Breakpoints Вы можете пометить строки в Вашей программе как точки прерывания. Когда в процессе выполнения Вашей программы достигается точка прерывания, выполнение программы приостанавливается и отображается исходный текст и курсор останавливается на строке с точкой прерывания. Затем Вы можете проверить значения переменных, начать трассировку или выполнить программу до другой точки прерывания. Вы можете подключить условие к точке прерывания. Вы можете также прерваться в любой точке Вашей программы, нажав клавишу Ctrl-Break. Произойдет остановка на следующей строке исходной программы, как если бы в этой строке была установлена точка прерывания.

Наблюдение.

Debug/Watches Пользователь имеет возможность задавать для просмотра в окне Watch некоторые объекты (переменные, структуры данных, выражения). Просматриваемые данные меняются, отражая текущие изменения в программе при пошаговом выполнении.

^ Вычисление/модификация Ctrl-F4.

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

^ Начало сеанса отладки.

Наиболее быстрый способ начать отладку состоит в загрузке программы и выборе команды Run/Trace Into (F7). Программа будет компилироваться. Когда компиляция завершится, редактор отобразит на дисплей тело основной программы с индикацией строки выполнения на первом операторе begin. Пользователь может начать трассировку программы с этого места (нажать клавиши F7 или F8) или использовать другие методы которые приведены ниже.

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

- Выбрать команду Run/Goto Cursor (или нажать клавишу F4), которая будет выполнять программу пользователя до достижения строки, помеченной курсором, а затем останавить работу программы.

- Задать на указанной строке точку прерывания (выбрать команду Debug/Toggle Breakpoint или нажать на Ctrl-F8), затем выполнить программу (выполнить команду Run/Run или нажать Ctrl-F9); остановка будет происходить каждый раз при достижении заданной строки. Вы можете задать несколько точек прерывания, в этом случае программа будет делать остановку всякий раз при достижении какой-либо из этих точек.

^ Рестарт сеанса отладки.

Если в процессе отладки программы возникает необходимость начать все сначала, то нужно выполнить команду Program Reset из меню Run. Система отладки повторно инициализируется, и команда следующего шага вернет вас к первой строке главной программы. При этом производится закрытие всех файлов, которые были открыты программой, очистка стека всех вложенных программ, которые вызывались программой, и освобождение всего использованного пространства кучи. Переменные программы, однако, не будут повторно инициализированы или подвержены модификации какого-нибудь другого вида. (Turbo Pascal никогда не инициализирует переменные автоматически). Однако, начальные значения типированных констант программы будут восстановлены.

Turbo Pascal также предлагает рестарт, если Вы производите какие-либо изменения в программе во время отладки. Например, если Вы изменяете часть программы, а затем выбираете любую команду выполнения (нажимаете клавиши F7, F8, F4, Ctrl-F9 и т.д.), Вы получите сообщение : Source modified, rebuild? (Y/N) (исходный модуль модифицирован, нужно повторить сборку? да/нет ). Если Вы отвечаете Y, Turbo Pascal будет перекомпилировать программу и возобновит отладку программы с начала. Если Вы ответите N, Turbo Pascal предполагает, что Вы уверены в своих действиях, и продолжает сеанс отладки дальше. (Любые изменения в программе, которые Вы произвели, не будут влиять на ее выполнение до тех пор, пока Вы не перекомпилируете программу). Если Вы добавили или удалили строки программы, курсор выполнения не реагирует на эти изменения, и может оказаться, что будет выделяться ошибочная строка.

^ Окончание сеанса отладки.

В процессе отладки программы Turbo Pascal хранит трассу того, что Вы делаете и где находитесь в данный момент. Так как пользователь может в процессе отладки загружать и даже редактировать различные файлы, Turbo Pascal не интерпретирует загрузку другого файла в редактор, как конец сеанса отладки. Поэтому, если вы желаете выполнить или отладить другую программу, нужно выполнить команду Run/Program Reset (клавиша Ctrl -F2).


  1. ^

    понятия ЕСПД. программные и Эксплуатационные документы


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


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


К числу упомянутых стандартов необходимо, в первую очередь, отнести ГОСТ 26.203-81 КОМПЛЕКСЫ ИЗМЕРИТЕЛЬНО-ВЫЧИСЛИТЕЛЬНЫЕ. ПРИЗНАКИ КЛАССИФИКАЦИИ. ОБЩИЕ ТРЕБОВАНИЯ, ГОСТ 19781-90 ОБЕСПЕЧЕНИЕ СИСТЕМ ОБРАБОТКИ ИНФОРМАЦИИ ПРОГРАММНОЕ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ, ГОСТ 28806-90 КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ, ГОСТ Р ИСО МЭК 9126-93 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. ОЦЕНКА ПРОГРАММНОЙ ПРОДУКЦИИ. ХАРАКТЕРИСТИКИ КАЧЕСТВА И РУКОВОДСТВА ПО ИХ ПРИМЕНЕНИЮ и некоторые другие.


^ Вид программного документа

Содержание программного документа

Спецификация

Состав программы и документации на нее

Ведомость держателей подлинников

Перечень предприятий, на которых хранят подлинники программных документов

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

Запись программы с необходимыми комментариями

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

Сведения о логической структуре и функционировании программы

Программа и методика испытаний

Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля

Техническое задание

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

Пояснительная записка

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

Эксплуатационные документы

Сведения для обеспечения функционирования и эксплуатации программы

^ Вид эксплуатационного документа

Содержание эксплуатационного документа

Ведомость эксплуатационных документов

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

Формуляр

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

Описание применения

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

Руководство системного программиста

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

Руководство программиста

Сведения для эксплуатации программы

Руководство оператора

Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы

Описание языка

Описание синтаксиса и семантики языка

Руководство по техническому обслуживанию

Сведения для применения тестовых и диагностических программ при обслуживании технических средств

 
Реклама:





Скачать файл (143.5 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru