|
Полезная статья? Пожалуйста, поставьте "+"
Языки программирования и методы трансляции - Содержание
Почти каждому мудрому изречению соответствует противоположное по смыслу и не менее мудрое. Джордж Сантаяна В случае несложной программы, модуля или функции, документацию можно объединить, составив так называемую спецификацию программы, описывающую требования к программе (модулю или функции), ее интерфейс, тест требования и некоторые другие аспекты.
Стоит отметить, что спецификация или ее отдельные разделы могут проходить инспекции, дорабатываться, утверждаться, поэтому на работу с этим документом могут накладываться различные ограничения. Как минимум, необходимо чтобы в спецификации был указан ее автор и текущая версия. Для отслеживания всех действий рекомендуется вести таблицу изменений, в которой отмечать кто, когда, что и почему изменил и указывать номер новой версии. Пример таблицы изменений можно увидеть в Приложении Б.
Спецификация делится на разделы, соответствующие разным документам при разработке ПО. Схема написания полностью приведена в Приложении А.
Первый раздел – это краткое описание конечного продукта. Описание должно быть достаточно кратким, но давать четкое понимание назначения продукта. Здесь же следует указывать язык реализации и архитектуру целевой машины. Например, если рассмотреть программу, вычисляющую периметр треугольника по длинам его сторон, то краткое описание может иметь следующий вид.
Программа вычисления периметра треугольника по длинам его сторон. Язык реализации Си. Архитектура – х86.
Во втором разделе рассматривается интерфейс программы. Под интерфейсом понимается все данные, методы и средства предназначенные для взаимодействия с внешними программами, пользователями, периферией. Раздел, описывающий интерфейс всегда удобно рассматривать с трех точек зрения:
- входы;
- выходы;
- хранимые данные.
Каждую точку зрения можно разделить на подразделы, с учетом сложности и типа описываемого ПО. В случае программы расчета периметра треугольника удобно разделить входные/выходные данные на данные, подаваемые/возвращаемые в среду ОС и на вводимые данные с клавиатуры/выводимые сообщения на экран.
Входы
- Данные, вводимые с клавиатуры
Три целых положительных числа, меньшие 100 – длины сторон в
десятичной системе исчисления.
- Параметры – данные, передаваемые из среды ОС
Нет
В качестве хранимых данных рассматриваются все внутренние данные ПО, доступные извне во время выполнения. Например, модуль может иметь экспортируемую переменную, которая и должна быть описана в этом подразделе.
Если спецификация описывает отдельный модуль, то удобно делить раздел интерфейса на подразделы для каждой функции модуля, включающие входы/выходы, внутренние/внешние переменные функций. Когда язык программирования определен, удобно указывать заголовки функций на выбранном языке.
Третий раздел описывает функциональные требования к ПО. Здесь должна быть подробно в виде требований описана вся функциональность ПО, включая все особые случаи. Например, в нашем примере переданные числа могут оказаться не сторонами треугольника (не удовлетворять основному правилу треугольника), и необходимо четко указать, что программа должна делать в таком случае.
Требования могут дополнительно комментироваться, однако каждое требование выделяется в тексте отдельным предложением со словом должен (должна/должно). Это позволяет четко отделить требования и комментарии/описания, а так же однозначно пронумеровать все требования.
Требования к ПО должны отвечать на вопрос «что должна делать программа». Следует четко различать вопросы «ЧТО» должна делать программа и «КАК» она должна это делать. Вопрос «что» – это определение функциональности, а вопрос «как» – это определение алгоритма. Сам алгоритм относится уже к архитектуре системы, за исключением особых случаев, когда требуется реализация конкретных алгоритмов, например, шифрование, расчет контрольной суммы, но даже в этих случаях следует минимально ограничивать реализацию. Итак, требования к ПО содержат в себе определение функциональности, а алгоритмы и детали реализации – это архитектура ПО.
В случаях, когда спецификация пишется для целой программы, требования можно разбить на разделы, отражающие основные функциональные области системы. Например, для программы расчета периметра треугольника вся функциональность может быть разделена на следующие области:
- ввод данных;
- проверка корректности данных;
- расчет периметра;
- вывод результатов (или типа ошибки).
Для каждой функциональной области далее формируются требования. Например для «проверки корректности данных» можно сформировать следующие требования:
Программа должна проверить, являются ли введенные три числа длинами сторон треугольника согласно основному правилу треугольника (сумма двух любых сторон треугольника меньше длины третьей стороны). Если введенные числа не являются длинами сторон треугольника, то программа должна выполнить <ссылка на требование о выводе сообщения о соответствующей ошибке из раздела вывода результатов>.
Программа должна проверить, что каждое из введенных трех чисел меньше 100 и больше 0. Если введенные числа не принадлежат интервалу от 0 до 100, то программа должна выполнить <ссылка на требование о выводе сообщения о соответствующей ошибке из раздела вывода результатов>.
В дополнение к функциональным требованиям спецификация содержит и тест требования. В тест требованиях указывается, что необходимо проверить при тестировании. Сам раздел должен отражать основные области эквивалентности входов или области, в которых поведение программы будет схожим. Если выделить такие области и протестировать поведение программ для какого-либо одного значения из каждой области, то с большой вероятностью можно будет утверждать и о поведении программы на всей области определения ее входных значений. Обычно удобно начинать тест требование со слов «Проверить, что …». Например, для входов программы расчета периметра треугольника можно сформулировать следующее тест требование:
Проверить, что если значение одного из входов больше или равно 100, то программа выдаст сообщение об ошибке.
Составление тестов более подробно рассматривается в Главе 9 данного пособия.
После определения указанных разделов начинается процесс кодирования. Результат – код программы/функции/модуля – тоже может рассматриваться как часть спецификации.
После написания кода составляется тест-план, который содержит в себе реальные данные и ожидаемые результаты для проверки программы согласно тест требованиям. Тест-план можно рассматривать как часть спецификации, но зачастую он является отдельным документом.
По тест-плану пишется тест модуль, который автоматически выполняет («прогоняет») все тесты из тест-плана.
Результат выполнения тест модуля – отчет о прогоне теста тоже является частью спецификации программы. Те тесты, которые нельзя провести в автоматическом режиме проводятся вручную, и их результаты добавляются в отчет о прогоне теста.
|
