- •Внешнее описание программного средства
- •Определение требований к программному средству
- •Спецификация качества программного средства
- •Функциональная спецификация программного средства
- •Методы контроля внешнего описания пс
- •Архитектура программного средства
- •Разработка структуры программы и модульное программирование
- •Методы разработки структуры программы
- •Контроль структуры программы
- •Разработка программного модуля
- •Структурное программирование
- •Пошаговая детализация
- •Контроль программного модуля
- •Тестирование и отладка программного средства
- •Автономная отладка модуля
- •Расчет метрик Холстеда
Методы разработки структуры программы
Спецификация программного модуля содержит синтаксическую спецификацию его входов, позволяющую построить на используемом языке программирование правильное обращение к нему. Это описание семантики функции. Функциональная спецификация модуля строится также как и функциональная спецификация ПС. В процессе разработки программы модульная структура может формироваться по разному, обычно используется 2 метода:
-
Метод восходящей разработки
Сначала строится модульная структура программы в виде дерева, затем поочередно программируются модули программы, начиная с самого нижнего уровня (листья дерева, самых маленьких модулей). Модули программируются в таком порядке, чтобы для каждого нового модуля были созданы уже все модули, к которым он обращается. Затем происходит поочередное тестирование и отладка в таком же порядке. Такой расклад не рекомендуется. Это связано со следующим:
-
Для программирования какого-либо модуля совсем не требуется текста описывающий модуль, для этого достаточно чтобы каждый модуль был лишь специфицирован.
-
Каждая программа подчиняется некоторым внутренним для нее соображениям, например, структура данных, набор исходных переменных и т.д. на который накладывай свой отпечаток предметная область в которой функционирует приложение. Поэтому модули часто требуют перепрограммирования, когда происходит уточнение этой глобальной информации. Таким образом, наблюдается большой объем отладочного программирования и при этом не гарантируется, что тестирование модуля будет происходить в тех же условиях, что и в рабочей программе.
-
Метод снисходящей разработки
Заключается в следующем: сначала также строится модульная структура в виде дерева, но программирование происходит в другом направлении, начиная с самого верхнего (головного) уровня и только затем переходит к программированию других модулей. Когда все модули запрограммированы происходит программирование и отладка. В этом случае вся глобальная информация формируется своевременно, т.е. просчеты в программировании модулей сводятся к минимуму, облегчается тестирование, поскольку головной модуль уже создан и можно лишь его запустить. Также все модули тестируются в естественном состоянии информационной среды. Если головной модуль обращается к еще незапрограммированному модулю, то он заменяется на имитатор (т.е. простой программный фрагмент, сигнализирующий о том, что произошел факт обращения к модулю с необходимыми входными параметрами). Таким образом объем отладочного программирования сводится к созданию простых имитаторов. Также имитаторы удобно использовать для того чтобы они возвращали строго определенные значения.
Эти два способа являются классическими, поскольку инструкция должна быть разработана до начала программирования модулей. В ряде случаев разработать такую структуру достаточно точно и содержательно трудно, поэтому применяются другие подходы, в которых модульная структура формируется в процессе программирования модулей. Эти модули являются развитием классическими, поэтому обладают соответствующими особенностями классических методов.
-
Конструктивный подход
Представляет собой модификацию снисходящей разработки. Программирование начинается с головного модуля исходя из спецификации программы в целом, при этом спецификация программы головного модуля является спецификацией программы, так как именно он ответственен за выполнение функций. В процессе программирования головного модуля, в случае если программа достаточно большая, выделяются подзадачи (т.е внутренние функции). В терминах в которых программируется головной модуль, таким образом, что для каждой выделяемой подзадачей создается спецификация реализующего ее фрагменты программы, который в дальнейшем может быть представлен под деревом модулей. В головном модуле для обращения к выделенной функцией строят соответствующие обращения, в соответствии с созданной спецификацией. Таким образом на первом шаге разработке создается верхняя (начальная) часть дерева. В результате создается дооформление дерева программы.
-
Архитектурный подход
Модификация восходящей разработки. Модульная структура также создается в процессе работы. Цель разработки – повышение уровня языка программирования, а вовсе не разработка программы. Это означает что для заданной предметной области выделяются типичные задачи, которые специфицируются, а затем программируются как отдельные программные модули. Т.е. процесс выделения функции связан с накоплением и обобщением опыта решения задач в заданной предметной области. Сначала выделяются и реализуются более простые функции, а затем постепенно появляются модули, которые используют созданные ранее модули. Такой набор модулей создаётся в расчете на то, что при разработке программы заданной предметной области в рамках конструктивного подхода могут быть приемлемы некоторые из этих модулей. Таким образом применение готовых модулей может сократить затраты на разработку конкретных программ. Также архитектурный подход является методом борьбы с повторением. Программные модули в архитектурном подходе всегда параметризируются, т.е. выделяются конкретные программы, для того чтобы конкретизировать модули путем настройки их программы (создаются универсальные модули). Пример, кнопочка в форме.
Главное отличие классических методов от неклассических заключается в том, что структура кода в неклассических методах заранее неопределенна или определяется лишь частично. Это откладывает свой отпечаток на способ тестирования модулей. Например, тестирование модулей отдельно друг от друга. Конструктивный подход имеет ряд положительных особенностей в отношении архитектурного, а именно поскольку в конструктивном подходе головной модуль уже создан, следовательно, программа уже готова к работе, поэтому появляется возможность выпуска на рынок не полностью доделанной программы, которая решает только основные функции. В дальнейшем функционал приложения может быть доведен до требуемого, однако приложение уже может использоваться в конкретных целях, например, для определения особенностей функционирования программы.