tehnologia (Г.С. Иванова - Учебник - Технология программирования), страница 11
Описание файла
Файл "tehnologia" внутри архива находится в папке "Учебник - Технология программирования". PDF-файл из архива "Г.С. Иванова - Учебник - Технология программирования", который расположен в категории "". Всё это находится в предмете "информационные технологии" из 2 семестр, которые можно найти в файловом архиве РТУ МИРЭА. Не смотря на прямую связь этого архива с РТУ МИРЭА, его также можно найти и в других разделах. Архив можно найти в разделе "книги и методические указания", в предмете "информационные технологии" в общих файлах.
Просмотр PDF-файла онлайн
Текст 11 страницы из PDF
Длямодулей обслуживания данных характерна информационная связность функций. Данныетаких модулей могут быть связаны по-разному. Так, модули, содержащие описание классовпри объектно-ориентированном подходе, характеризуются информационной связностьюметодов и функциональной связностью данных. Получение в процессе декомпозициимодулей с другими видами связности, скорее всего, означает недостаточно продуманноепроектирование.
Исключением являются лишь библиотеки ресурсов.Библиотеки ресурсов. Различают библиотеки ресурсов двух типов: библиотекиподпрограмм и библиотеки классов.Библиотеки подпрограмм реализуют функции, близкие по назначению, например,библиотека графического вывода информации. Связность подпрограмм между собой втакой библиотеке – логическая, а связность самих подпрограмм – функциональная, так каккаждая из них обычно реализует одну функцию.Библиотеки классов реализуют близкие по назначению классы. Связность элементовкласса – информационная, связность классов между собой может быть функциональной для родственных или ассоциированных классов и логической – для остальных.В качестве средства улучшения технологических характеристик библиотек ресурсов внастоящее время широко используют разделение тела модуля на интерфейсную часть иобласть реализации (секции Interface и Implementation – в Pascal, h и срр-файлы в C++ и вJava).Интерфейсная часть в данном случае содержит совокупность объявлений ресурсов(заголовков подпрограмм, имен переменных, типов, классов и54т.п.), которые данная библиотека предоставляет другим модулям.
Ресурсы, объявлениекоторых в интерфейсной части отсутствует, извне не доступны. Область реализациисодержит тела подпрограмм и, возможно, внутренние ресурсы (подпрограммы, переменные,типы), используемые этими подпрограммами. При такой организации любые измененияреализации библиотеки, не затрагивающие ее интерфейс, не требуют пересмотра модулей,связанных с библиотекой, что улучшает технологические характеристики модулейбиблиотек. Кроме того, подобные библиотеки, как правило, хорошо отлажены и продуманы,так как часто используются разными программами.2.3. Нисходящая и восходящая разработкапрограммного обеспеченияПри проектировании, реализации и тестировании компонентов структурной иерархии,полученной при декомпозиции, применяют два подхода:• восходящий;• нисходящий.В литературе встречается еще один подход, получивший название «расширение ядра».Он предполагает, что в первую очередь проектируют и разрабатывают некоторую основу –ядро программного обеспечения, например, структуры данных и процедуры, связанные сними.
В дальнейшем ядро наращивают, комбинируя восходящий и нисходящий методы. Напрактике данный подход в зависимости от уровня ядра практически сводится либо книсходящему, либо к восходящему подходам.Восходящий подход. При использовании восходящего подхода сначала проектируют иреализуют компоненты нижнего уровня, затем предыдущего и т.д. По мере завершениятестирования и отладки компонентов осуществляют их сборку, причем компоненты нижнегоуровня при таком подходе часто помещают в библиотеки компонентов.Для тестирования и отладки компонентов проектируют и реализуют специальныетестирующие программы.Подход имеет следующие недостатки:• увеличение вероятности несогласованности компонентов вследствие неполнотыспецификаций;• наличие издержек на проектирование и реализацию тестирующих программ, которыенельзя преобразовать в компоненты;• позднеепроектированиеинтерфейса,асоответственноневозможностьпродемонстрировать его заказчику для уточнения спецификаций и т.д.Исторически восходящий подход появился раньше, что связано с особенностьюмышления программистов, которые в процессе обучения привыкают при написаниинебольших программ сначала детализировать компоненты нижних уровней (подпрограммы,классы).
Это позволяет им лучше55осознавать процессы верхних уровней. При промышленном изготовлении программногообеспечения восходящий подход в настоящее время практически не используют.Нисходящий подход. Нисходящий подход предполагает, что проектирование ипоследующая реализация компонентов выполняется «сверху-вниз», т.е. вначалепроектируют компоненты верхних уровней иерархии, затем следующих и так далее до самыхнижних уровней. В той же последовательности выполняют и реализацию компонентов. Приэтом в процессе программирования компоненты нижних, еще не реализованных уровнейзаменяют специально разработанными отладочными модулями – «заглушками», чтопозволяет тестировать и отлаживать уже реализованную часть.При использовании нисходящего подхода применяют иерархический, операционный икомбинированный методы определения последовательности проектирования и реализациикомпонентов.Иерархический метод предполагает выполнение разработки строго по уровням.Исключения допускаются при наличии зависимости по данным, т.е.
если обнаруживается,что некоторый модуль использует результаты другого, то его рекомендуетсяпрограммировать после этого модуля. Основной проблемой данного метода являетсябольшое количество достаточно сложных заглушек. Кроме того, при использовании данногометода основная масса модулей разрабатывается и реализуется в конце работы надпроектом, что затрудняет распределение человеческих ресурсов.Операционный метод связывает последовательность разработки модулей с порядком ихвыполнения при запуске программы. Применение метода усложняется тем, что порядоквыполнения модулей может зависеть от данных. Кроме того, модули вывода результатов,несмотря на то, что они вызываются последними, должны разрабатываться одними изпервых, чтобы не проектировать сложную заглушку, обеспечивающую вывод результатовпри тестировании.
С точки зрения распределения человеческих ресурсов сложным являетсяначало работ, пока не закончены все модули, находящиеся на так называемом критическомпути.Комбинированныйметод учитываетследующие факторы,влияющиенапоследовательность разработки:• достижимость модуля – наличие всех модулей в цепочке вызова данного модуля;• зависимость по данным – модули, формирующие некоторые данные, должнысоздаваться раньше обрабатывающих;• обеспечение возможности выдачи результатов – модули вывода результатов должнысоздаваться раньше обрабатывающих;• готовность вспомогательных модулей – вспомогательные модули, например, модулизакрытия файлов, завершения программы, должны создаваться раньше обрабатывающих;• наличие необходимых ресурсов.56Кроме того, при прочих равных условиях сложные модули должны разрабатыватьсяпрежде простых, так как при их проектировании могут выявиться неточности вспецификациях, а чем раньше это произойдет, тем лучше.Нисходящий подход допускает нарушение нисходящей последовательности разработкикомпонентов в специально оговоренных случаях.
Так, если некоторый компонент нижнегоуровня используется многими компонентами более высоких уровней, то его рекомендуютпроектировать и разрабатывать раньше, чем вызывающие его компоненты. И, наконец, впервую очередь проектируют и реализуют компоненты, обеспечивающие обработкуправильных данных, оставляя компоненты обработки неправильных данных напоследок.Пример определения последовательности реализации модулей будет рассмотрен в § 5.2.Нисходящий подход обычно используют и при объектно-ориентированномпрограммировании. В соответствии с рекомендациями подхода вначале проектируют иреализуют пользовательский интерфейс программного обеспечения, затем разрабатываютклассы некоторых базовых объектов предметной области, а уже потом, используя этиобъекты, проектируют и реализуют остальные компоненты.Нисходящий подход обеспечивает:• максимально полное определение спецификаций проектируемого компонента исогласованность компонентов между собой;• раннее определение интерфейса пользователя, демонстрация которого заказчикупозволяет уточнить требования к создаваемому программному обеспечению;• возможность нисходящего тестирования и комплексной отладки (см.
гл. 9).2.4. Структурное и «неструктурное» программирование. Средства описанияструктурных алгоритмовОдним из способов обеспечения высокого уровня технологичности разрабатываемогопрограммного обеспечения является структурное программирование.Различают три вида вычислительного процесса, реализуемого программами: линейный,разветвленный и циклический.Линейная структура процесса вычислений предполагает, что для получения результатанеобходимо выполнить некоторые операции в определенной последовательности.57Разветвленная структура процесса вычислений предполагает, что конкретнаяпоследовательность операций зависит от значений одной или нескольких переменных.Циклическая структура процесса вычислений предполагает, что для получениярезультата некоторые действия необходимо выполнить несколько раз.Для реализации указанных вычислительных процессов в программах используютсоответствующие управляющие операторы.