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

Структуры

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

1) Структура является значимым, а не ссылочным типом данных, то есть экземпляр структуры хранит значение своих элементов, а не ссылки на них, и располагается в стеке.

2) Структура не может участвовать в иерархии наследования она может только реализовывать интерфейсы.

3) В структуре запрещено определять конструктор по умолчанию.

4) В структуре запрещено определять деструкторы.

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

Синтаксис структуры.

[атрибуты] [спецификаторы] struct имя структуры [: интерфейсов]

{тело структуры}

Спецификаторы доступа для структуры:

Public, Internal, Private(только для вложенных структур)

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

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

Методы структур не могут быть абстрактными и виртуальными.

В основу структурного программировании положено 6 конструкций:

1) Следование

2) Ветвление

3) Цикл пока

4) Выбор

5) Цикл до

6) Цикл с заданным числом повторений

Существует различные методы разработки программ:

1) Восходящий подход

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

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

2) Нисходящий подход

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

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

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

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

2 - зависимость по данным (модули, формирующие некоторые данные должны создаваться раньше обрабатывающих)

3 – обеспечение возможности выдачи результатов (модули вывода результатов должны создаваться раньше обрабатывающих)

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

5 – наличие необходимых ресурсов

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

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

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

Конструктивный и архитектурный подход разработки.

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

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

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

Дата добавления: 2014-01-07