Технологии программирования. 
Информационные технологии

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

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

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

Рассмотрим краткую ретроспективу развития методов и средств разработки ПО [21, 22].

Установка ключевых переключателей на передней панели вычислительных устройств — предпосылка первых программ.

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

Специализированные или проблемно- (предметно-)ориентированные языки — построены для решения конкретных задач, упрощают процесс разработки программных продуктов в выбранной предметной области, но в то же время для новых языков характерна проблема преемственности, а для специализированных — ограниченности области применения. На этом этапе следует выделить развитие таких языков программирования, как КОБОЛ, СИМУЛА, СИМСКРИПТ, АСПИД, АНАЛИТИК и т. д.

Постепенное усложнение решаемых задач, а вместе с ними кодов и объемов разрабатываемых программных средств, заставило критически переосмыслить сложившийся к концу 1960;х гг. стиль и технику программирования. В связи с чем начиная с 1970;х гг. усилиями рабочей группы Технического комитета по программированию Международной федерации по обработке информации (International Federation for Information Processing — IFIP — ИФИП) формируются основы методологии и теории программирования и утверждается принцип структурного программирования как наиболее производительного и привлекательного стиля программирования Развитие концепции структуризации привело к осознанию необходимости структуризации данных и определило появление в языках программирования механизмов абстрагирования типов данных (Клу, Модула и др.). Последнее легло в основу техники модульного программирования, содержательной основой которой является интерпретация типа как алгебры над множеством объектов и множеством операций, а модуля — как программного эквивалента абстрактного типа. В модульном программировании акцент делается на разбиение программы на модули таким образом, чтобы данные (обрабатываемые модулем) были спрятаны в нем. Эта доктрина, известная как «принцип ограничения доступа к данным», в значительной степени повысила модифицируемость и эффективность порождаемого кода.

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

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

Параллельно с развитием процедурного стиля программирования в начале 1970;х гг. появляются непроцедурные языки логического программирования и программирования искусственного интеллекта (LISP, Пролог, РЕФАЛ, ПРИЗ). Программа в таких языках представляет собой совокупность правил (определяющих отношения между объектами) и цели (запроса). Процесс выполнения программы трактуется как процесс установления общезначимости логической формулы по правилам, установленным семантикой того или иного языка. Результат вычислений является побочным продуктом процедуры вывода. Такой метод являет собой полную противоположность программирования на каком-либо из процедурных языков. Сегодня Пролог — язык, предназначенный для программирования приложений, использующих средства и методы искусственного интеллекта, создания экспертных систем и представления знаний.

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

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

Спецификация. Формирование спецификации предназначено для определения сервисов, которыми будет обладать проектируемое ПО, а также ограничений, накладываемых на функциональные возможности и разработку программной системы. Этот процесс в настоящее время обычно называют «разработка требований» (requirements engineering). Разработка требований часто является критическим этапом в создании ПО, поскольку ошибки, допущенные на этом этапе, ведут к возникновению проблем на этапах проектирования и разработки.

Процесс разработки требований включает четыре основных этапа.

• 1. Предварительные исследования. Оценивается степень удовлетворенности пользователей существующими программными продуктами и аппаратными средствами, а также экономическая эффективность будущей системы и возможность уложиться в существующие бюджетные ограничения при ее разработке. Этот этап должен быть по возможности коротким и дешевым.
• 2. Формирование и анализ требований. Формируются системные требования путем изучения существующих аналогичных сметем, обсуждения будущей системы с потенциальными пользователями и заказчиками, анализа задач, которые должна решать система, и т. п. Этот этап может включать разработку нескольких моделей системы и ее прототипов, что помогает сформировать функциональные требования к системе.
• 3. Специфицирование требований. Осуществляется перевод всей совокупности информации, собранной на предыдущем этапе, в документ, определяющий множество требований. Этот документ обычно содержит два типа требований: пользовательские — обобщенные представления заказчиков и конечных пользователей о системе; системные — детальное описание функциональных показателей системы.
• 4. Утверждение требований. Проверяется выполнимость, согласованность и полнота множества требований. В процессе формирования ограничений неизбежно возникновение каких-либо ошибок. На этом этапе они должны быть по возможности выявлены и устранены.

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

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

• • архитектура ПО;
• • устройство компонентов (модулей) ПО;
• • пользовательские интерфейсы.

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

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

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

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

Проектирование играет важную роль в процессах жизненного цикла создания программного обеспечения (Software Development Life Cycle), например, IEEE и ISO/IEC (ГОСТ P ИСО. МЭК) 12 207. Проектирование программных систем можно рассматривать как деятельность, результат которой состоит из двух составных частей:

• • архитектурный или высокоуровневый дизайн (Software Architectural Design, Top-Level Design) — описание высокоуровневой структуры и организации компонентов системы;
• • детализированная архитектура (Software Detailed Design) — описывающая каждый компонент в том объеме, который необходим для конструирования.

Кодирование — процесс написания программного кода, скриптов с целью реализации определенного алгоритма на определенном языке программирования.

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

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

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

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

Отладка — это процесс локализации и исправления ошибок, обнаруженных при тестировании программного обеспечения [23].

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

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

Различают следующие виды ошибок:

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

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

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

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

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

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

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

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

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

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

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

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

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

Большинство современных сред программирования (Delphi, Builder C++, Visual Studio и т. д.) включают средства отладки, которые обеспечивают максимально эффективную отладку. Они позволяют:

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

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

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

• 1 этап — изучение проявления ошибки — если выдано какое-либо сообщение или выданы неправильные или неполные результаты, то необходимо их изучить и попытаться понять, какая ошибка могла так проявиться. При этом используют индуктивные и дедуктивные методы отладки. В результате выдвигают версии о характере ошибки, которые необходимо проверить. Для этого можно применить методы и средства получения дополнительной информации об ошибке. Если ошибка не найдена или система просто «зависла», переходят ко второму этапу.
• 2 этап — локализация ошибки — определение конкретного фрагмента, при выполнении которого произошло отклонение от предполагаемого вычислительного процесса. Локализация может выполняться:
  • • путем отсечения частей программы, причем, если при отсечении некоторой части программы ошибка пропадает, то это может означать как-то, что ошибка связана с этой частью, так и то, что внесенное изменение изменило проявление ошибки;
  • • с использованием отладочных средств, позволяющих выполнить интересующий нас фрагмент программы в пошаговом режиме и получить дополнительную информацию о месте проявления и характере ошибки, например, уточнить содержимое указанных переменных.

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

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

Документирование — это важная часть в разработке программного обеспечения, но часто ей уделяется недостаточно внимания. Существует четыре основных типа документации на ПО [24, 25]:

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

Архитектурная/проектная документация. Проектная документация обычно описывает продукт в общих чертах. Не описывая того, как что-либо будет использоваться, она, скорее, отвечает на вопрос:

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

Техническая документация. При создании программы одного лишь кода, как правило, недостаточно. Должен быть предоставлен некоторый дополнительный материал, описывающий различные аспекты реализации кода. Такая документация часто включается непосредственно в исходный код или предоставляется вместе с ним. Подобная документация имеет сильно выраженный технических характер и в основном используется для определения и описания API, структур данных и алгоритмов. Часто при составлении технической документации используются автоматизированные средства — генераторы документации, такие как Doxygen, javadoc, NDoc и др. Они получают информацию из специальным образом оформленных комментариев в исходном коде и создают справочные руководства в каком-либо формате, например, в виде текста или HTML. Использование генераторов документации и документирующих комментариев многими программистами признается удобным средством по различным причинам. В частности, при таком подходе документация является частью исходного кода, и одни и те же инструменты могут использоваться для сборки программы и одновременной сборки документации к ней. Это также упрощает поддержку документации в актуальном состоянии.

Пользовательская документация. В отличие от технической документации, сфокусированной на коде и том, как он работает, пользовательская документация описывает лишь то, как использовать программу. В случае если продуктом является программная библиотека, пользовательская документация и документация на код становятся очень близкими, почти эквивалентными понятиями. Но в общем случае, это не так. Обычно пользовательская документация представляет собой руководство пользователя, которое описывает каждую функцию программы, а также шаги, которые нужно выполнить для использования этой функции. Хорошая пользовательская документация идет еще дальше и предоставляет инструкции о том, что делать в случае возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение и была актуальной. Руководство должно иметь четкую структуру; очень полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют большое значение. Существует три подхода к организации пользовательской документации. Вводное руководство (англ, tutorial), наиболее полезное для новых пользователей, последовательно проводит по ряду шагов, служащих для выполнения каких-либо типичных задач. Тематический подход, при котором каждая глава руководства посвящена какой-то отдельной теме, больше подходит для совершенствующихся пользователей. В последнем, третьем, подходе команды или задачи организованы в виде алфавитного справочника — часто это положительно воспринимается продвинутыми пользователями, хорошо знающими, что они ищут. Жалобы пользователей обычно относятся к тому, что документация охватывает только один из этих подходов, и поэтому хорошо подходит лишь для одного класса пользователей. Во многих случаях разработчики программного продукта ограничивают набор пользовательской документации лишь встроенной системой помощи (англ, online help), содержащей справочную информацию о командах или пунктах меню. Работа по обучению новых пользователей и поддержке совершенствующихся пользователей перекладывается на частных издателей, часто оказывающих значительную помощь разработчикам.

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

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

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

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

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

Руководство программиста. Часто это самый объемный документ, описывающий внутреннюю организацию программы. Обычно этот документ идет в паре с документом «текст программы». Руководство программиста дает заказчику возможность дописать какие-то новые фрагменты программы или переделать старые. В современной литературе этот документ называется Software Development Kit (далее — SDK). Продукт, снабженный SDK, может стоить на порядок дороже, чем такой же продукт без оного, так что можно понять, насколько трудно создать действительно полезный SDK. Сейчас не очень принято продавать исходные тексты программ — проблемы с интеллектуальной собственностью, даже при наличии SDK трудно «влезть» в чужую программу. Поэтому большое распространение получили Application Program Interface (далее — API). Программа передается только в виде DLL (библиотека двоичных кодов), но известно, как обратиться к каждой функции из других программ, т. е. известно имя точки входа, количество, типы и значения параметров. Наличие множества API, конечно, хуже, чем наличие исходных текстов (например, нельзя переделать что-то в середине функции), зато много проще в использовании. С другой стороны, все большую популярность приобретает Free Software Foundation (далее — FSF). Основателем этого движения был Ричард Столман, который забил тревогу по поводу попыток крупных фирм запатентовать многие основные алгоритмы и программы: «Дойдет до того, что они запатентуют понятия „цикл“ и „подпрограмма“, что мы будем тогда делать?» FSF представляет собой собрание программ в исходных текстах. Любой программист может свободно использовать их в своих целях, но все добавления и улучшения, которые он сделал, тоже следует положить в FSF. Таким образом, FSF представляет собой одно из самых больших доступных хранилищ программ.

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

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

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

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

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

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

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

Рассмотрим классификацию различных форм тестирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

Различают тестирование по типам:

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

Сторонники первого подхода проектирует свои тесты, исследуя внешние спецификации или спецификации сопряжения программы или модуля, которые он тестирует. Позиция их такова: «Нас не интересует, как выглядит эта программа и выполнил ли я все команды или все пути. Мы будем удовлетворены, если программа будет вести себя так, как указано в спецификациях». Их идеал — проверить все возможные комбинации и значения на входе.

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

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

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

По объему можно выделить следующие тесты:

• • маленький тест, типа печати «hello, world», чтобы понять, есть ли вообще о чем говорить;
• • получасовое тестирование (американцы говорят «Тест на одну сигарету»), обычно проверяют по одному тесту на каждую функцию программы перед серьезным тестированием;
• • модульное тестирование;
• • комплексное тестирование.

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

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

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

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

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

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

Реинжиниринг. Особый интерес вызывает вопрос, когда же следует прекращать сопровождение [27]. На этот вопрос отвечает диаграмма оценки качества ПО (рис. 3.23).

Здесь по горизонтали растет важность программы для бизнеса компании, а по вертикали — сложность внесения исправлений. Так вот, если исправлять несложно и важность — небольшая, то надо просто сопровождать, исправляя ошибки (corrective fixing), если же программа важна для компании, то можно и улучшать ее (adaptive fixing). Если исправлять сложно, а важность — небольшая, то легче программу выкинуть, если же программа важна, содержит определенные знания бизнес-процессов, но сопровождать ее трудно, например, потому что авторы программы покинули компанию или компания вынуждена сменить платформу, то программу следует подвергнуть реинжинирингу.

Рис. 3.23. Диаграмма оценки качества ПО.

Попросту говоря, реинжиниринг — это перевод программы со старых языков (Кобол, ПЛ1, Адабас-Натурал и т. п.) на новые, такие как Java, Visual Basic, C+ +. На самом деле, все гораздо сложнее. Смена операционной системы, используемой базы данных, стиля организации диалога с пользователем — каждая из этих задач весьма нетривиальна. Если же добавить естественное желание реструктурировать программу, выкинуть отмершие части, перейти к объектно-ориентированной организации программы и т. д., да еще вспомнить, что все эти задачи требуют перебора и анализа путей в графе управления программы, число которых растет экспоненциально относительно числа вершин, то задача вообще выглядит нерешаемой.

Относительные затраты ресурсов на создание ПО по основным этапам: спецификацию (10%), проектирование (10%), кодирование (10%), отладку (20%) и сопровождение (50%).

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

Рассмотрим существующие технологии создания ПО.

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

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

Диаграмма функционального моделирования (Structured analysis and design technique — SADT) — инструмент разработки функциональных спецификаций в виде диаграмм, фрагментов текста и глоссария, связанных перекрестными ссылками. В состав диаграммы входят:

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

Место соединения дуги с блоком определяет тип интерфейса:

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

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

Компонентное сборочное программирование — объектно-ориентированное сборочное программирование, основанное на распространении классов в бинарном виде и предоставлении доступа к методам класса через строго определенные интерфейсы.

Компонентное сборочное программирование поддерживают технологические подходы COM, CORBA, .Net.

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

Логическое программирование — программирование в терминах фактов и правил вывода с использованием языка, основанного на формальных исчислениях.

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

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

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

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

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

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

Объектно-ориентированное сборочное программирование — разновидность сборочного программирования:

• • основанная на методологии объектно-ориентированного программирования;
• • предполагающая распространение библиотек классов в виде исходного кода или упаковку классов в динамически компонуемую библиотеку.

Синтезирующее программирование — программирование, предполагающее синтез программы по ее спецификации.

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

• • программирования «сверху-вниз»;
• • модульного программирования.

При этом логика алгоритма и программы должны использовать три основные структуры: последовательное выполнение, ветвление и повторение.

Инструментарий технологии программирования — программные продукты, предназначенные для поддержки технологии программирования. К ним относятся рассмотренные ранее (параграф 3.4) CASE- технологии.