Технология модульного программирования

Модульное программирование

МЕТОДЫ ПРОЕКТИРОВАНИЯ ПРОГРАММ

2. Объектно-ориентированное проектирование

2.1. Основные понятия объектно-ориентированного проектирования

2.2. Пример объектно-ориентированного проектирования

1. Марченко А.И., Марченко Л.А. Программирование в среде Turbo Pascal 7.0. – 8-е изд. – К.: ВЕК+, СПб.: КОРОНА принт, 2004. с. 232-238.

2. Ставровский А.Б. Первые шаги в программировании. Самоучитель. – М.: «Вильямс», 2003. с. 113-133.

3. Вирт Н. Алгоритмы и структуры данных. – М.: Мир, 1989.

4. Иванова Г.С. Технология программирования: Учебник для вузов. – М.: Изд-во МГТУ им. Н.Э.Баумана, 2002. -320 с.

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

структурное проектирование программных продуктов;
информационное моделирование предметной области

и связанных с ней приложений;

объектно-ориентированное проектирование программных продуктов и др.

Целью данного занятия является изучение основных принципов структурного и объектно-ориентированного проектирования программ

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

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

Типичными методами структурного проектирования являются:

нисходящее проектирование, кодирование и тестирование программ;
модульное программирование;
структурное программирование и др.

В зависимости от объекта структурирования различают:

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

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

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

Структурный подход использует:

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

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

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

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

В качестве примера рассмотрим проект одевания ребенка.

Конкретизация цели на первом шаге:

Одеть нижнюю половину.

Одеть верхнюю половину.

Нижнюю половину можно одеть в два этапа:

Надеть носки и ботинки.

Верхнюю половину можно также одеть в два этапа:

Окончательный проект выглядит так:

Метод нисходящего проектирования предполагает последовательное разложение общей функции обработки данных на простые функциональные элементы («сверху-вниз»). В результате строится иерархическая схема, отражающая состав и взаимоподчиненность отдельных функций, которая носит название функциональная структура алгоритма (ФСА) (рис. 1.1).

Последовательность действий по разработке ФСА приложения следующая:

1) определяются цели автоматизации предметной области и их иерархия (цель-подцель);

2) устанавливается состав приложений (задач обработки), обеспечивающих реализацию поставленных целей;

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

4) определяются необходимые для решения задач функции обработки данных;

5)
выполняется декомпозиция функций обработки до необходимой структурной сложности, реализуемой предполагаемым инструментарием.

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

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

Функции ввода-вывода информации рекомендуется отделять от функций вычислительной или логической обработки данных.

По частоте использования функции обработки делятся на:

однократно выполняемые;
повторяющиеся.

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

Уточнение действий при нисходящем проектировании — это, по сути, переход от описания того, что нужно сделать, к тому, как это сделать.

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

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

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

Модуль должен обладать следующими свойствами:

один вход и один выход – на входе программный модуль получает определенный набор исходных данных, выполняет содержательную обработку и возвращает один набор результатных данных, т.е. реализуется стандартный принцип IPO (Input — Process — Output — вход-процесс-выход);
функциональная завершенность – модуль выполняет перечень регламентированных операций для реализации каждой отдельной функции в полном составе, достаточных для завершения начатой обработки;
логическая независимость – результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей;
слабые информационные связи с другими программными модулями – обмен информацией между модулями должен быть по возможности минимизирован;
обозримый по размеру и сложности программный код.

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

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

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

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

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

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

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

В результате дальнейшей детализации алгоритма создается функционально-модульная схема (ФМС) алгоритма приложения, являющася основой для программирования (рис. 1.2).

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

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

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

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

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

Читать еще: Геометрическое решение задач линейного программирования

Статьи к прочтению:

Информатика. Язык Си: Модульное программирование на Си.Центр онлайн-обучения «Фоксфорд»

Что такое модульное программирование и кому оно нужно

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

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

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

Классическая проблема программирования

В западной литературе существует термин «big ball of mud» для описания архитектуры программы. Давайте переведём его дословно. Графически «большой шар грязи» можно представить в виде точек на окружности, символизирующих функциональные элементы, и прямых – связей между ними:

Похоже на ваши глаза перед сдачей проекта, не так ли?

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

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

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

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

Ускорение разработки.
Повышение надёжности.
Упрощение тестирования.
Взаимозаменяемость.

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

Но не всё так просто.

Проблемы модульного программирования

Сама по себе идея использования модулей не сильно упрощает код, важно минимизировать количество прямых связей между ними. Здесь мы подходим к понятию «инверсия управления» (IoC). Упрощённо – это принцип программирования, при котором отдельные компоненты кода максимально изолированы друг от друга. То есть детали одного модуля не должны влиять на реализацию другого. Достигается это при помощи интерфейсов или других видов представления, не обеспечивающих прямого доступа к модульному коду.

В повседневной жизни таких примеров множество. Чтобы купить билет на самолёт или узнать время вылета, вам не надо звонить пилоту. Чтобы выпить молока, не надо ехать в деревню или на завод и стоять над душой у коровы. Для этого всегда есть посредники.

В модульном программировании существует три основные реализации:

Внедрение зависимостей. Способ, при котором каждый элемент имеет свой интерфейс, взаимодействие модулей происходит через интерфейсы.
Фабричный метод. Основывается на существовании некого объекта, предназначенного для создания других объектов. Иначе говоря, введение в программу прототипа, объединяющего общие черты для большинства объектов. Прямого взаимодействия между модулями нет, все параметры наследуются от «завода».
Сервисный метод. Создаётся один общий интерфейс, являющийся буфером для взаимодействия объектов. Похожую функцию в реальной жизни выполняют колл-центры, магазины, площадки для объявлений и т.д.

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

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

Таким образом, поддержка принципов модульного программирования, инверсии управления и четкой архитектуры приложения поможет убить сразу трёх зайцев:

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

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

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

Классическая проблема программирования

Похоже на ваши глаза перед сдачей проекта, не так ли?

Ускорение разработки.
Повышение надёжности.
Упрощение тестирования.
Взаимозаменяемость.

Но не всё так просто.

Проблемы модульного программирования

Читать еще: Как вызвать безопасный режим на ноутбуке

В модульном программировании существует три основные реализации:

Внедрение зависимостей. Способ, при котором каждый элемент имеет свой интерфейс, взаимодействие модулей происходит через интерфейсы.
Фабричный метод. Основывается на существовании некого объекта, предназначенного для создания других объектов. Иначе говоря, введение в программу прототипа, объединяющего общие черты для большинства объектов. Прямого взаимодействия между модулями нет, все параметры наследуются от «завода».
Сервисный метод. Создаётся один общий интерфейс, являющийся буфером для взаимодействия объектов. Похожую функцию в реальной жизни выполняют колл-центры, магазины, площадки для объявлений и т.д.

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

Технологии программирования

Для начала разберёмся с тем, что такое технология. Постараюсь изъясняться простым языком, пусть даже это будет не очень точно. Зато понятно.

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

Технологии программирования — это способы создания программ. Эти способы включают в себя как определённые знания (например, знание языка программирования), так и определённые инструменты (например, средства разработки программ).

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

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

Развитие технологий программирования

Развитие технологий программирования — это эволюция способов разработки программ. Эту эволюцию можно разбить на следующие этапы (на текущий момент — в будущем может быть придумают что-то ещё):

Стихийное программирование. То есть “как Бог даст”, как получится. Можно сказать, что на этом этапе какие-либо технологии отсутствовали. На этом этапе случился переход от машинных кодов к ассемблерам. А затем к алгоритмическим языкам программирования. На этом этапе обычно сначала создавали кучу подпрограмм, а потом пытались объединить их в одну программу. Первое время это удавалось. Но по мере усложнения задач, решать их в разумные сроки становилось всё труднее. Поэтому возникла необходимость перехода на второй этап.
Структурное программирование. Появились структурированные языки программирования. Изначально Паскаль был именно таким языком. А язык С, можно сказать, таким языком и остался. Структурный подход представлял собой технологию, когда большая задача разбивалась на несколько относительно небольших, и представлялась в виде некой иерархической (древовидной) структуры.
Модульное программирование. Эта технология рождалась почти одновременно со структурным программированием. Идея заключалась в том, чтобы разбивать программы на модули. В модули включали подпрограммы, близкие по своему назначению.
Объектно-ориентированное программирование (ООП). Технология объектно-ориентированного программирования — это уже современный подход, хотя начиналось это ещё с середины 80-х годов 20-го века. Суть ООП заключается в представлении программы в виде совокупности объектов. Каждый из объектов имеет свои свойства (характеристики) и методы (функции). При этом программисту часто не обязательно знать, как устроен объект. Достаточно только общего описания свойств и методов. Объектно-ориентированные языки программирования — это С++, Object Pascal, Delphi и т.п.
Компонентый подход и CASE-технологии. Развиваются с середины 90-х прошлого столетия. Программы создаются из отдельных компонентов. Большинство из этих компонентов уже имеются в средствах разработки. CASE-технологии позволяют не только создавать, но и сопровождать программное обеспечение от “рождения до смерти”, то есть на всём жизненном цикле ПО. Компонентный подход в совокупности с ООП на сегодняшний день и является наиболее используемой технологией программирования.

Ну и, как вы понимаете, на всех этих этапах было много чего придумано и создано. То есть эти эти группы можно разбить на подгруппы, а подгруппы — снова разбить и т.д.

Например, к компонентным технологиям можно отнести технологию OLE, разработанную всем известной компанией Microsoft. И к ним же можно отнести технологию CORBA.

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

И в каждом из этих видов есть немало конкретных технологий, таких как OLE, API или .NET. Так что тема эта очень обширная и очень интересная. Как говорится — не переключайтесь ))))

Введение в технологию программирования

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

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

5.2. Модульное программирование

Технология модульного программирования — оформившаяся в начале 70-х годов XX века идея разработки больших программных систем [1.4]. Это фундаментальная концепция, являющаяся основой всех современных подходов к проектированию и реализации. В то же время суть ее проста и отражает широко известные научные и технические методы, заключающиеся в поиске и реализации некоторого базового набора элементов, комбинации которых дают решение всех задач из определенного круга.

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

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

5.3. Объектно-ориентированное программирование

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

Объектно-ориентированная технология в некоторой степени решила большинство описанных проблем. В отличие от рассмотренных ранее технологий, объектно-ориентированная технология работает на стадиях анализа, проектирования и программирования. В основе технологии лежат объектная модель и объектная декомпозиция [1.3].

К основным принципам объектной модели часто относят следующие:

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

Суть объектной декомпозиции состоит в выделении в предметной области классов и объектов, а также связей между ними, и лишь потом данных и алгоритмов, которыми характеризуется каждый класс. Таким образом, именно классы становятся основным «строительным блоком» в ООП, тогда как ранее таковыми блоками являлись алгоритмы.

Читать еще: Алфавит языка программирования это

5.4. Компонентное программирование

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

программный код в виде самостоятельного модуля;
может быть использован в неизменном виде;
может допускать настройку;
обладает поведением (функциональностью).

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

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

Модульное программирование

Цели урока:

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

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

1.1. Устный опрос:

Какой вид имеет структура описания процедуры и функции в Turbo Pascal?
В чем состоит отличие описания процедуры и функции?
Что такое область действия идентификаторов?
Какие параметры называются формальными и какие фактическими?
Какие способы передачи параметров реализованы в Turbo Pascal?
Почему при работе с графикой в Turbo Pascal необходимо предложение uses Graph?
Какие процедуры и функции модуля Graph вам известны?

2. Изложение нового материала.

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

2.1.1. Технология модульного программирования.

Языки высокого уровня появились в 60-е годы. Ресурсы ЭВМ (объем ОЗУ 8 Кбайт, быстродействие 20 тыс. операций в сек.) были недостаточны, поэтому программисты вынуждены были писать программы весьма “хитроумно” с использованием оператора безусловного перехода. Программа получалась запутанной, имела структуру “блюдо спагетти”. Так как область применения ЭВМ расширялась, программное обеспечение усложнялось. Программисты, решающие сложные задачи, столкнулись с проблемой разрастания количества и размера программ до такой степени, что дальнейший процесс разработки становился практически неуправляемым, и никто из разработчиков не мог с уверенностью сказать, что созданный программный продукт всегда выполняет то, что требуется, и что он не выполняет ничего такого, что не требуется. Поэтому возникла необходимость в новой методологии разработки программных проектов. В 1968–1969 гг. состоялись конференции по программированию. На второй из них Эдсгер Дийкстра предложил принципиально новый способ создания прграмм – структурное программирование. Главное – разбиение программного комплекса (при его создании) на программные модули, которые соединяются иерархически.

Цели модульного программирования:

1. Улучшать читабельность программ.
2. Повышать эффективность и надежность программ (легко находить и корректировать ошибки).
3. Уменьшать время и стоимость программной разработки (уменьшается время отладки).

Разбиение программного комплекса на модули выполняется в соответствии со следующими принципами:

Модуль – это независимый блок, код которого физически и логически отделен от кода других модулей.
Размер модуля не больше 100 операторов.
Имеет одну входную и одну выходную точку.
Модули связаны иерархически.
Разбиение должно обеспечивать надежное скрытие информации в модуле.
Парнас: “Для написания одного модуля должно быть достаточно минимальных знаний о тексте другого”.
Каждый модуль должен начинаться с комментария (его назначение – входные и выходные переменные).
Не использовать метки и оператор GOTO.
Использовать только стандартные управляющие конструкции (условие, выбор, цикл, блок).

2.1.2. Нисходящее и восходящее программирование.

При разработке модульных программ применяются два метода проектирования – нисходящее и восходящее. При нисходящем проектировании разработка программного комплекса идет сверху вниз.

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

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

Недостатки нисходящего проектирования:

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

Преимущество нисходящего проектирования – на самом начальном этапе проектирования отлаживается головной модуль (логика программы).

Преимущество восходящего программирования – не нужно писать заглушки.

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

На практике применяются оба метода. Метод нисходящего проектирования чаще всего применяется при разработке нового программного комплекса, а метод восходящего проектирования – при модификации уже существующего комплекса.

2.1.3. Оформление программы в виде модуля.

При подключении стандартных модулей достаточно корректно записать их идентификаторы в предложении uses. При разработке собственных модулей необходимо помнить некоторые особенности:

Не допускается одновременное использование модулей с одинаковыми именами.
Идентификатор модуля, указанный в заголовке (unit), должен совпадать с именами файлов, содержащих исходный (.pas) (.tpu, . tpp, .tpw) код.
Если идентификатор модуля длиннее восьми символов, то он должен совпадать с именами файлов по первым восьми символам.

Общая структура модуля

unit идентификатор модуля;

<Интерфейсный раздел>

в этом разделе описывается взаимодействие данного модуля с другими пользовательскими и стандартными модулями, а также с главной программой. Другими словами – взаимодействие модуля с “внешним миром”.

Список импорта интерфейсного раздела

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

Список экспорта интерфейсного раздела

const
type
var
procedure
function

Раздел реализации

в этом разделе указывается реализационная (личная) часть описаний данного модуля, которая недоступна для других модулей и программ. Другими словами – “внутренняя кухня модуля”.

Список импорта раздела реализации

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

Подразделы внутренних для модуля описаний

В этих подразделах описываются метки, константы, типы, переменные, процедуры и функции, которые описывают алгоритмические действия, выполняемые данным модулем, и которые являются “личной собственностью” только данного модуля. Эти описания недоступны ни одному другому модулю. Заголовки процедур и функций в этом подразделе допускается указывать без списка формальных параметров. Если заголовки указаны все же с параметрами, то список формальных параметров должен быть идентичен такому же списку для соответствующей процедуры (функции) в разделе interface.

label
const
type
var
procedure
function

Раздел инициализации

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

Пример модуля a1

unit a1;
interface
uses graph;
procedure init;
procedure pr1;
implementation
procedure init;

procedure pr1;
begin

end;
begin
init;
pr1;
readln;
end.

Головной модуль

program a;
uses a1, a2, a3, a4;
begin
pr1;
pr2;
pr3;
pr4;
readln;
end.

3. Проверка качества усвоения нового материала.

3.1. Устный опрос.

Назовите принципы модульного программирования.
Когда применяется технология нисходящего программирования? А восходящего?
В чем различие между технологией восходящего и технологией нисходящего программирования?
Какие существуют особенности при разработке собственных модулей?
Из каких разделов состоит модуль?
Что описывается в разделе interface?
Что описывается в разделе implementation?
Что описывается в разделе инициализации?

3.2. Самостоятельная работа учащихся на уроке.

Учащиеся разбиты на две группы. Работой каждой группы руководит “начальник”. Получив задание, учащиеся начинают коллективную работу. Каждый ученик разрабатывает свою программу, оформляет ее в виде модуля UNIT и отдает “начальнику”, который пишет головную программу, объединяя модули своих “подчиненных”.

Литература:

Марченко А. И., Марченко Л. М. “Программирование в среде Turbo Pascal 7.0”, М.: “Бином Универсал”, 1998.
Информатика. № 2. /Приложение к газете “Первое сентября”, 1996.

Технология модульного программирования

Модульное программирование

Статьи к прочтению:

Информатика. Язык Си: Модульное программирование на Си.Центр онлайн-обучения «Фоксфорд»

Похожие статьи:

Что такое модульное программирование и кому оно нужно

Классическая проблема программирования

Проблемы модульного программирования

Классическая проблема программирования

Проблемы модульного программирования

Технологии программирования

Развитие технологий программирования

Введение в технологию программирования

5.2. Модульное программирование

5.3. Объектно-ориентированное программирование

5.4. Компонентное программирование

Модульное программирование