Модульный подход к программированию. Модульное программирование. Заголовок модуля и связь модулей друг с другом

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

МИНОБРНАУКИ РОССИИ

Реферат

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

Введение

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

Машинно-ориентированное программирование появилось одновременно с созданием электронных вычислительных машин. Сначала это были программы в машинных кодах, затем появился язык программирования Assembler (Автокод), который немного «очеловечил» написание программы в машинном коде.

Процедурное программирование. Основная идея этого стиля - алгоритмизация процесса решения задачи и выбор наилучшего алгоритма (по расходу памяти или по быстродействию.

Структурное программирование. Здесь основная идея прекрасно выражена Н. Виртом в его книге "Алгоритмы + структуры данных = программы". Это был ответ на кризис в области программирования, начавшийся в середине 60-х годив, когда объем исходного программного кода перешел рубеж в 1000 строк. В 1971 году появился алгоритмический язык Pascal и немного позже, в 1972 году, язык С..

Модульное программирование. Здесь основная идея заключалась в том, чтобы "спрятать" данные и процедуры внутри независимых программных единиц - модулей. Эту идею впервые реализовал Н. Вирт в алгоритмическом языке Modula (1975-1979 годы), а затем "подхватили" и остальные, распространенные в то время языки программирования. Например, известные системы программирования Turbo Pascal и Turbo С.

Объектно-ориентированное программирование. С середины 80-х годов объем исходного программного кода перешел рубеж в 100 000 строк. Нужно было сделать не случайное объединение данных и алгоритмов их обработки в единое целое, а - смысловое. То есть необходимо было создать модульное программирование нового уровня, когда основной акцент делается на смысловую связь структур данных и алгоритмов их обработки

модуль программирование проектирование декомпозиция

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

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

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

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

2. Основные характеристики программного модуля

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

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

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

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

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

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

o всегда следует использовать рутинный модуль, если это не приводит к плохим (не рекомендуемым) сцеплениям модулей;

o зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения параметрического сцепления;

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

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

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

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

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

3. 1 Функциональная декомпозиция

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

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

3.2 Минимизации количества передаваемых параметров

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

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

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

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

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

3.3 Минимизации количества необходимых вызовов

Одним из существенных преимуществ модульного программирования является то, что программа основного уровня очень часто может быть сконструирована для чтения как последовательность вызываемых процедур. Этот факт существенно повышает «понимаемость» программы, поскольку читатель может познакомиться с ее основным потоком и функционированием после прочтения только одной - двух страниц программного кода. Однако эта особенность может также иметь и недостатки. Одна из многих верхних статистических оценок программирования говорит о том, что 90% времени выполнения типовых программ расходуется в 10 % кода программы. При этом подразумевается, что если эти 10 % содержат большое количество цепочечных вызовов процедур, то суммарное время, затрачиваемое на управление выполнением программы, может стать непреодолимым препятствием на пути использования этого подхода.

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

Заключение

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

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

Все ресурсы модуля делятся на две группы: внешние - предназначенные для использования другими программными единицами, и внутренние - рабочие ресурсы данного модуля.

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

Размещено на Allbest.ru

Подобные документы

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

реферат , добавлен 29.01.2016

Характеристика модульного программирования: процедуры и функции, модули и их структура, открытые массивы и строки, нетипизированные параметры. Способы передачи параметров в подпрограммы в Borland Pascal. Объектно-ориентированное программирование.

контрольная работа , добавлен 28.04.2009

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

курсовая работа , добавлен 16.12.2011

Появление первых вычислительных машин и возникновение "стихийного" программирования. Структурный подход к декомпозиции сложных систем. Развитие модульного и объектно-ориентированного программирования. Особенности компонентного подхода и CASE-технологий.

презентация , добавлен 14.10.2013

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

презентация , добавлен 05.11.2016

Предмет исследования – современные методы разработки программ таких, как объектно-ориентированное программирование и визуальное проектирование, а также структурное и модульное программирование. C++ - универсальный язык программирования. Ключевые понятия.

курсовая работа , добавлен 10.01.2009

Почему C++. Возникновение и эволюция языка C++. Сравнение языков С++ и С. Эффективность и структура. Процедурное программирование. Модульное программирование. Абстракция данных. Объектно-ориентированное программирование. Улучшенный С.

реферат , добавлен 03.06.2004

Обзор технологий и систем геоинформационных систем. Системное и функциональное проектирование программного модуля, его разработка с использованием сред программирования Visual C++ 6.0, Qt 3.3.3. Технико-экономическое обоснование данного процесса.

дипломная работа , добавлен 13.03.2011

Проектирование программного модуля в среде программирования Borland Delphi 7.0. Схемы алгоритмов решения задач по темам "Символьные переменные и строки", "Массивы", "Работа с файлами", "Создание анимации". Реализация программного модуля, код программы.

отчет по практике , добавлен 21.04.2012

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заметим, что нужно различать использование слова "модуль", когда имеется в виду синтаксическая конструкция языков программирования (unit в Object Pascal), и когда имеется в виду единица дробления большой программы на отдельные блоки (которые могут быть реализованы и в виде процедур, и в виде функций).

Использование модульного программирования позволяет упростить тестирование программы и обнаружение ошибок. Аппаратно-зависимые подзадачи могут быть строго отделены от других подзадач, что улучшает мобильность создаваемых программ.

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

Термин "модуль" в программировании начал использоваться в связи с внедрением модульных принципов при создании программ. В 70-х годах под модулем понимали какую-либо процедуру или функцию, написанную в соответствии с определенными правилами. Например "Модуль должен быть простым, замкнутым (независимым), обозримым (от 50 до 100 строк), реализующим только одну функцию задачи, имеющим только одну входную и только одну выходную точку". Однако общепризнанных требований не было и модулем очень часто называли любую процедуру размером до 50 строк.

Первым основные свойства программного модуля более-менее четко сформулировал Парнас (Parnas): "Для написания одного модуля должно быть достаточно минимальных знаний о тексте другого". Таким образом! Парнас первым выдвинул концепцию скрытия информации (information! hiding) в программировании.

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

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

Впервые специализированная синтаксическая конструкция модуля была предложена Н.Виртом в 1975 г. и включена в его новый язык Modula. В этом же году была сделана опытная реализация языка Modula. После некоторой переработки этот новый язык был окончательно реализован в 1977 г. и получил название Modula-2. Впоследствии, аналогичные конструкции, с некоторыми отличиями, были включены и в другие языки программирования: Pascal Plus (Уэлш и Бастард, 1979 г.), Ada (1980), Turbo Pascal версии 4.0 и другие.

Изначально предполагалось, что при реализации сложных программных комплексов модуль должен использоваться наравне с процедурами и функциями как конструкция, объединяющая и надежно скрывающая детали реализации определенной подзадачи. Однако в языке Borland (Turbo) Pascal были реализованы не все теоретические возможности модуля. В частности, в этом языке отсутствует поддержка внутренних модулей (аналогичных внутренним процедурам и функциям), недостаточно гибко реализован импорт (предложение uses), который не позволяет импортировать объекты из других модулей выборочно. Это обстоятельство, а также то, что с появлением персональных компьютеров круг программирующих людей резко расширился (а это существенно снизило средний уровень теоретической подготовки программистов), привело к тому, что при разработке приложений на этой, предшествующей Object Pascal, версии языка модули использовались в основном как средство создания проблемных библиотек процедур и функций. И только наиболее квалифицированные программисты использовали всю мощь этой языковой конструкции для структурирования своих проектов. В языке Object Pascal отмеченные ограничения реализации модулей остались, однако благодаря тому, что в среде Delphi каждой форме обязательно соответствует свой модуль и не визуальные алгоритмические действия также, как правило, оформляются в виде отдельных модулей, конструкцию "модуль" стали использовать по ее первоначальному предназначению все программисты, независимо от их квалификации.

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

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

Рассмотрим еще один теоретический вопрос, связанный с использованием модульного программирования. Этот вопрос касается формы модульного проекта.

Придание иерархической структуре модульного проекта хорошей формы позволяет улучшить процесс ее разработки. Число модулей, которые подключаются каким-либо модулем, и число модулей, которые его подключают, оказывают влияние на сложность проекта. Йордан (Yourdon) назвал число модулей, подключаемых из данного модуля, размахом или шириной управления модулями. Наряду с большим размером модуля очень маленькая или очень большая ширина управления является признаком плохой схемы разбивки на модули. В общем случае, ширина управления модуля не должна превышать 10-ти. Это число связано с "магическим" числом 7, которое базируется на положениях психологии, в особенности, на теории "кусков" ("chunking") информации. Кратковременная память человека имеет ограниченные способности сохранения "кусков" информации. Психологические эксперименты показали, способность нашей кратковременной памяти находится в пределах 5-11 "кусков" (в среднем - 7). Она может одновременно оперировать около 7 "кусками" информации. Когда человек превышает этот предел, он более склонен к ошибкам. Реорганизация информации с разбивкой на подходящие части является важным действием для эффективного использования кратковременной памяти человека и для улучшения понимаемого материала. Люди во многих жизненных ситуациях делают такую реорганизацию бессознательно. Однако программист может сам себе помочь, сознательно не допуская ширины управления модулями, которая существенно превышает число 7.

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

Кроме того, эти же принципы следует применять и при проектировании иерархии классов. Например, в иерархии предопределенных классов Object Pascal, только два класса, TObject и Exception, имеют число непосредственных классов-потомков, значительно большее, чем 7. Это можно объяснить глобальной базовой ролью TObject и "перечисляемым" характером класса Exception. Еще у троих классов это число находится в пределах 8-9, а остальные классы имеют менее 7 непосредственных потомков.

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

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

Наряду с этими преимуществами имеются и некоторые недостатки, которые могут привести к возрастанию стоимости программной системы:

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

Перечислим основные свойства и требования к модулям .

1. Модуль возникает в результате сепаратной компиляции или является частью результата совместной компиляции. Он может активизироваться операционной системой или быть подпрограммой, вызываемой другим модулем.
2. На содержимое модуля можно ссылаться с помощью его имени.
3. Модуль должен возвращать управление тому, кто его вызвал.
4. Модуль может обращаться к другим модулям.
5. Модуль должен иметь один вход и один выход. Иногда программа с несколькими входами может оказаться короче и занимать меньше места в памяти. Однако опыт модульного программирования показал, что разработчики предпочитают иметь несколько похожих модулей, но не использовать несколько входов и выходов в одном модуле. Это объясняется тем, что единственность входа и выхода гарантирует замкнутость модуля и упрощает сопровождение программной системы.
6. Модуль сравнительно невелик. Размеры модуля влияют на степень независимости элементов программы, легкость ее чтения и тестирования. Обнаружено, что небольшие модули позволяют строить такие программы, которые легче изменять. Такие модули чаще используются, они облегчают оценку и управление разработкой, их можно рекомендовать и достаточно опытным, и неопытным программистам. Можно было бы удовлетворить критериям высокой прочности и минимального сцепления, спроектировав программу как несколько больших модулей, но вряд ли таким образом была бы достигнута высокая степень независимости. Как правило, модуль должен содержать от 10 до 100 операторов языка высокого уровня (в некоторых публикациях - до 200).

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

7. Модуль не должен сохранять историю своих вызовов для управления своим функционированием. Такой модуль называют предсказуемым. Модуль, хранящий следы своих состояний при последовательных вызовах, не является предсказуемым. Все модули ПС должны быть предсказуемыми, т.е. не должны сохранять никакой информации о предыдущем вызове. Хитрые, неуловимые, зависящие от времени ошибки возникают в тех программах, которые пытаются многократно вызвать непредсказуемый модуль.
8. Структура принятия решения в модуле должна быть организована таким образом, чтобы те модули, на которые прямо влияет принятое решение, были подчиненными (вызываемыми) по отношению к принимающему решение модулю. Таким образом, обычно удается исключить передачу специальных параметров-индикаторов, представляющих решения, которые должны быть приняты, а также принимать влияющие на управление программой решения на высоком уровне в иерархии программы.
9. Минимизация доступа к данным. Объем данных, на которые модуль может ссылаться, должен быть сведен к минимуму. Исключение сцепления по общей области, внешним данным и по формату - хороший шаг в этом направлении. Проектировщик должен попытаться изолировать сведения о любой конкретной структуре данных или записи в базе данных в отдельном модуле (или небольшом подмножестве модулей) -возможно, за счет использования информационно прочных модулей.
10. Внутренние процедуры. Внутренняя процедура, или подпрограмма, - это замкнутая подпрограмма, физически расположенная в вызывающем ее модуле. Таких процедур следует избегать по нескольким причинам. Внутренние процедуры трудно изолировать для тестирования, и они не могут быть вызваны из модулей, отличных от тех, которые их содержат. Это не соответствует идее повторного использования. Конечно, имеется альтернативный вариант - включить копии внутренней процедуры во все модули, которым она нужна. Однако это часто приводит к ошибкам (копии часто становятся «не совсем точными») и усложняет сопровождение программы, поскольку, когда процедура изменяется, все модули нужно перекомпилировать.

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

Предположим у нас есть программа, которая выводит температуру на lcd дисплей и что для lcd дисплея, что для датчика температуры(ds18b20 ), нужна инициализация, а также функции для работы с ними. Поэтому логично будет создать два отдельных файла lcd.c и ds18b20.с , которые будут содержать в себе функции необходимые для работы. Такие файлы называют модулями , хотелось бы отметить, что каждый модуль представляет собой независимую, логически-завершенную единицу, которую можно компилировать отдельно от остальной программы . При компиляции модуля компилятор сделает из него объектный файл.

Следующий вопрос, который возникает, раз модуль это независимая структура, можно сказать «вещь в себе », то она не имеет связи с внешним миром, а нас это не устраивает. Для связи модулей с внешним миром используется заголовочные файлы, их также называют хэдерами/хидерами и они имеют расширение .h . Назвать хэдер можно как угодно, но удобнее, чтобы его название совпадало с названием модуля, lcd.h и ds18b20.h , также надо сказать, что все подключаемые файлы(#include ) удобно вынести в хэдер и подключать только его вначале модуля.
Когда хэдера не было, начало lcd.с выглядело так
#define F_CPU 8000000UL #include #include
а после создание хэдера стало выглядеть так
#include

Но тут же возникает еще один вопрос, что выносить в хэдер?
В хэдер необходимо вынести прототипы функций, которые могут понадобиться в других модулях программы . Прототип функции лишь объявляет функцию и не содержит тела функции, но посмотрев на него можно узнать имя функции, количество, тип аргументов и возвращаемый тип данных .
В файле lcd.h
void lcd_init(void); void lcd_write_symbol(char symbol); void lcd_write_string(char *str); void lcd_clear(void);
В файле ds18b20.h будут объявлены следующие прототипы:
void ds18b20_init(void); uint8_t ds18b20_get_temperature(void);

Что касается макросов, можно вынести макросы, отвечающие за выполнение условной компиляции
#define MAKE_CALIBRATION //раскомментировать для калибровки
А где-то в коде есть конструкция, которая выполняется если предыдущая строчка раскомментирована
#ifdef MAKE_CALIBRATION touch_x -= 300; touch_x = 240 - touch_x/((Xmax-Xmin)/240); touch_y -= 350; touch_y = 320 - touch_y/((Ymax-Ymin)/320); #endif
Также можно вынести макросы, отвечающие за выбор выводов, к которым будет подключаться периферия
#define D0 PORTA //так данные передаются по 16 битной шине, #define D7 PORTD //под это дело мы используем два порта

Но в то же время в хэдере не надо размещать то, что не понадобится в других модулях:

макросы типа
#define (LCD_PIN & 0X80) check_busy_flag
переменные, которые будут использоваться только внутри модуля с ключевым словом static
переменные с квалификатором extern
прототипы функций, которые нужны для каких-то промежуточных действий, например, функцию, которая переводит число в BCD формат

Теперь пару слов про подключение хэдеров, при программировании микроконтроллеров AVR почти во всех модулях подключается хэдер для работы с портами ввода-вывода.
#include avr/io.h
То есть он подключается в lcd.h и в ds18b20.h , теперь если мы подключим эти два заголовка в основном файле программы, то avr/io.h подключится дважды, хотя достаточно было и одного . Для того чтобы избежать возникновения такой ситуации и хэдер не подключился дважды используют #include guards , который выглядит следующим образом.
#ifndef _ENCODER_H_ #define _ENCODER_H_ // оформляем как обычный хэдер #endif
Это конструкция позволяет препроцессору определить, что данный хэдер уже включался в программу и не включать его повторно. Подробнее про это можно почитать .
Также ограничить количество подключений файла до одного, можно с помощью конструкции
#pragma once // оформляем как обычный хэдер
Преимущество использование #pragma once вместо #include guards можно почитать .
Кстати подключать можно не только хэдеры, а также файлы с расширением .с , если это надо
#include “font.c”
В данном случае для вывода букв на TFT дисплей подключается файл с шрифтами.
На этом всё, мне кажется это минимум, который необходимо знать каждому начинающему программисту микроконтроллеров.