Понятие модульного программирования. Предназначение и принцип применения математического модуля
Получилось так, что те парадигмы, которые раньше потом и кровью пробивались в свет через орды приверженцев традиционных методов постепенно забываются. Эти парадигмы возникли на заре программирования и то, почему они возникали, какие преимущества они давали и почему используются до сих пор полезно знать любому разработчику.
Ладно. Введение это очень весело, но вы его все равно не читаете, так что кому интересно - добро пожаловать под кат!
Императивное программирование
Исторически сложилось так, что подавляющее большинство вычислительной техники, которую мы программируем имеет состояние и программируется инструкциями, поэтому первые языки программирования в основном были чисто императивными, т.е. не поддерживали никаких парадигм кроме императивной.
Это были машинные коды, языки ассемблера и ранние высокоуровневые языки, вроде Fortran.
Ключевые моменты:
В этой парадигме вычисления описываются в виде инструкций, шаг за шагом изменяющих состояние программы.В низкоуровневых языках (таких как язык ассемблера) состоянием могут быть память, регистры и флаги, а инструкциями - те команды, что поддерживает целевой процессор.
В более высокоуровневых (таких как Си) состояние - это только память, инструкции могут быть сложнее и вызывать выделение и освобождение памяти в процессе своей работы.
В совсем высокоуровневых (таких как Python, если на нем программировать императивно) состояние ограничивается лишь переменными, а команды могут представлять собой комплексные операции, которые на ассемблере занимали бы сотни строк.
Основные понятия:
- Инструкция- Состояние
Порожденные понятия:
- Присваивание- Переход
- Память
- Указатель
Как основную:
- Языки ассемблера- Fortran
- Algol
- Cobol
- Pascal
- C
- C++
- Ada
Как вспомогательную:
- Python- Ruby
- Java
- C#
- PHP
- Haskell (через монады)
Стоит заметить, что большая часть современных языков в той или иной степени поддерживает императивное программирование. Даже на чистом функциональном языке Haskell можно писать императивно.
Структурное программирование
Структурное программирование - парадигма программирования (также часто встречающееся определение - методология разработки), которая была первым большим шагом в развитии программирования.
Основоположниками структурного программирования были такие знаменитые люди как Э. Дейкстра и Н. Вирт.
Языками-первопроходцами в этой парадигме были Fortran, Algol и B, позже их приемниками стали Pascal и C.
Ключевые моменты:
Эта парадигма вводит новые понятия, объединяющие часто используемые шаблоны написания императивного кода.В структурном программировании мы по прежнему оперируем состоянием и инструкциями, однако вводится понятие составной инструкции (блока), инструкций ветвления и цикла.
Благодаря этим простым изменениям возможно отказаться от оператора goto в большинстве случаев, что упрощает код.
Иногда goto все-же делает код читабельнее, благодаря чему он до сих пор широко используется, несмотря на все заявления его противников.
Основные понятия:
- Блок- Цикл
- Ветвление
Языки поддерживающие данную парадигму:
Как основную:
- C- Pascal
- Basic
Как вспомогательную:
- C#- Java
- Python
- Ruby
- JavaScript
Поддерживают частично:
- Некоторые макроассемблеры (через макросы)
Опять-же большая часть современных языков поддерживают структурную парадигму.
Процедурное программирование
Опять-же возрастающая сложность программного обеспечения заставила программистов искать другие способы описывать вычисления.
Собственно еще раз были введены дополнительные понятия, которые позволили по-новому взглянуть на программирование.
Этим понятием на этот раз была процедура.
В результате возникла новая методология написания программ, которая приветствуется и по сей день - исходная задача разбивается на меньшие (с помощью процедур) и это происходит до тех пор, пока решение всех конкретных процедур не окажется тривиальным.
Ключевые моменты:
Процедура - самостоятельный участок кода, который можно выполнить как одну инструкцию.В современном программировании процедура может иметь несколько точек выхода (return в C-подобных языках), несколько точек входа (с помощью yield в Python или статических локальных переменных в C++), иметь аргументы, возвращать значение как результат своего выполнения, быть перегруженной по количеству или типу параметров и много чего еще.
Основные понятия:
- ПроцедураПорожденные понятия:
- Вызов- Аргументы
- Возврат
- Рекурсия
- Перегрузка
Языки поддерживающие данную парадигму:
Как основную:
- C- C++
- Pascal
- Object Pascal
Как вспомогательную:
- C#- Java
- Ruby
- Python
- JavaScript
Поддерживают частично:
- Ранний Basic
Стоит отметить, что несколько точек входа из всех этих языков поддерживаются только в Python.
Модульное программирование
Который раз увеличивающаяся сложность программ заставила разработчиков разделять свой код. На этот раз процедур было недостаточно и в этот раз было введено новое понятие - модуль.
Забегая вперед скажу, что модули тоже оказались неспособны сдержать с невероятной скоростью растущую сложность ПО и в последствии появились пакеты (это тоже модульное программирование), классы (это уже ООП), шаблоны (обобщенное программирование).
Программа описанная в стиле модульного программирования - это набор модулей. Что внутри, классы, императивный код или чистые функции - не важно.
Благодаря модулям впервые в программировании появилась серьезная инкапсуляция - возможно использовать какие-либо сущности внутри модуля, но не показывать их внешнему миру.
Ключевые моменты:
Модуль - это отдельная именованная сущность программы, которая объединяет в себе другие программные единицы, близкие по функциональности.Например файл List.mod включающий в себя класс List
и функции для работы с ним - модуль.
Папка Geometry, содержащая модули Shape, Rectangle и Triangle - тоже модуль, хоть и некоторые языки разделяют понятие модуля и пакета (в таких языках пакет - набор модулей и/или набор других пакетов).
Модули можно импортировать (подключать), для того, чтобы использовать объявленные в них сущности.
Основные понятия:
- Модуль- Импортирование
Порожденные понятия:
- Пакет- Инкапсуляция
Языки поддерживающие данную парадигму:
Как основную:
- Haskell- Pascal
- Python
Как вспомогательную:
- Java- C#
- ActionScript 3
Поддерживают частично:
- C/C++
В некоторых языках для модулей введены отдельные абстракции, в других же для реализации модулей можно использовать заголовочные файлы (в C/C++), пространства имен, статические классы и/или динамически подключаемые библиотеки.
Вместо заключения
В данной статье я не описал популярные сейчас объектно-ориентированное, обобщенное и функциональное программирование. Просто потому, что у меня есть свое, довольно радикальное мнение на этот счет и я не хотел разводить холивар. По крайней мере сейчас. Если тема окажется полезной для сообщества я планирую написать несколько статей, изложив основы каждой из этих парадигм подробно.Также я ничего не написал про экзотические парадигмы, вроде автоматного, аппликативного, аспект/агент/компонент-ориентированного программирования. Я не хотел делать статью сильно большой и опять-же если тема будет востребована, я напишу и об этих парадигмах, возможно более подробно и с примерами кода.
Назначение модулей
Стандартный Паскаль не предусматривает механизмов раздельной компиляции частей программы с последующей их сборкой перед выполнением. Вполне понятно стремление разработчиков коммерческих компиляторов Паскаля включать в язык средства, повышающие его модульность.
Модуль – это автономно компилируемая программная единица, включающая в себя различные компоненты раздела описаний (типы, константы, переменные, процедуры и функции) и, возможно, некоторые исполняемые операторы инициирующей части.
Основным принципом модульного программирования является принцип «разделяй и властвуй». Модульное программирование – это организация программы как совокупности небольших независимых блоков, называемых модулями, структура и поведение которых подчиняются определенным правилам.
Использование модульного программирования позволяет упростить тестирование программы и обнаружение ошибок. Аппаратно-зависимые подзадачи могут быть строго отделены от других подзадач, что улучшает мобильность создаваемых программ.
Термин «модуль» в программировании начал использоваться в связи с внедрением модульных принципов при создании программ. В 70-х годах под модулем понимали какую-либо процедуру или функцию, написанную в соответствии с определенными правилами. Например: «Модуль должен быть простым, замкнутым (независимым), обозримым (от 50 до 100 строк), реализующим только одну функцию задачи, имеющим одну входную и одну выходную точку ».
Первым основные свойства программного модуля более-менее четко сформулировал Парнас (Parnas): «Для написания одного модуля должно быть достаточно минимальных знаний о тексте другого ». Таким образом, в соответствии с определением, модулем могла быть любая отдельная процедура (функция) как самого нижнего уровня иерархии (уровня реализации), так и самого верхнего уровня, на котором происходят только вызовы других процедур-модулей.
Таким образом, Парнас первым выдвинул концепцию скрытия информации (information hiding) в программировании. Однако существовавшие в языках 70-х годов только такие синтаксические конструкции, как процедура и функция, не могли обеспечить надежного скрытия информации, поскольку подвержены влиянию глобальных переменных, поведение которых в сложных программах бывает трудно предсказуемым.
Решить эту проблему можно было только разработав новую синтаксическую конструкцию, которая не подвержена влиянию глобальных переменных.
Такая конструкция была создана и названа модулем. Изначально предполагалось, что при реализации сложных программных комплексов модуль должен использоваться наравне с процедурами и функциями как конструкция, объединяющая и надежно скрывающая детали реализации определенной подзадачи.
Таким образом, количество модулей в комплексе должно определяться декомпозицией поставленной задачи на независимые подзадачи. В предельном случае модуль может использоваться даже для заключения в него всего лишь одной процедуры, если необходимо, чтобы выполняемое ею локальное действие было гарантировано независимым от влияния других частей программы при любых изменениях.
Впервые специализированная синтаксическая конструкция модуля была предложена Н. Виртом в 1975 г. и включена в его новый язык Modula. Насколько сильно изменяются свойства языка, при введении механизма модулей, свидетельствует следующее замечание Н.Вирта, сделанное им по поводу более позднего языка Модула-2: «Модули – самая важная черта, отличающая язык Модула-2 от его предшественника Паскаля».
По своей организации и характеру использования в программе модули Турбо Паскаля близки к модулям-пакетам (PACKAGE) языка программирования Ада. В них так же, как и в пакетах Ады, явным образом выделяется некоторая «видимая» интерфейсная часть, в которой сконцентрированы описания глобальных типов, констант, переменных, а также приводятся заголовки процедур и функций. Появление объектов в интерфейсной части делает их доступными для других модулей и основной программы. Тела процедур и функций располагаются в исполняемой части модуля, которая может быть скрыта от пользователя.
Рис.2. Последовательность разработки программного проекта
Значение модулей для технологии разработки программного проекта может быть продемонстрировано диаграммой на рис. 2.
Модули представляют собой прекрасный инструмент для разработки библиотек прикладных программ и мощное средство модульного программирования. Важная особенность модулей заключается в том, что компилятор размещает их программный код в отдельном сегменте памяти. Длина сегмента не может превышать 64 Кбайт, однако количество одновременно используемых модулей ограничивается лишь доступной памятью, что позволяет создавать большие программы.
Структура модулей
Всякий модуль имеет следующую структуру:
Unit <имя_модуля>;
i nterface
<интерфейсная часть>;
implementation
<исполняемая часть>;
<инициирующая часть>;
Здесь UNIT – зарезервированное слово (единица); начинает заголовок модуля;
<имя_модуля> - имя модуля (правильный идентификатор);
INTERFACE – зарезервированное слово (интерфейс); начинает интерфейсную часть модуля;
IMPLEMENTATION – зарезервированное слово (выполнение); начинает исполняемую часть модуля;
BEGIN – зарезервированное слово; начинает инициирующую часть модуля; причем конструкция begin <инициирующая часть> необязательна;
END – зарезервированное слово – признак конца модуля.
Таким образом, модуль состоит из заголовка и трех составных частей, любая из которых может быть пустой.
Ниже показана общая структура модуля, дополненная комментариями, поясняющими смысл и назначение каждого раздела модуля.
Unit ИдентификаторМодуля;
{Интерфейсный раздел }
interface
{В этом разделе описывается взаимодействие данного модуля} {с другими пользовательскими и стандартными модулями, а также} {с главной программой. Другими словами – взаимодействие } {модуля с «внешним миром». }
{Список импорта интерфейсного раздела }
{В этом списке через запятые перечисляются идентификаторы} {модулей, информация интерфейсных частей которых должна }
{быть доступна в данном модуле. Здесь целесообразно описывать} {идентификаторы только тех модулей, информация из которых} {используется в описаниях раздела interface данного модуля.}
{Список экспорта интерфейсного раздела }
const {Список экспорта состоит из подразделов описания констант,} type {типов, переменных, заголовков процедур и функций, которые} var {определены в данном модуле, но использовать которые разре-} procedure {шено во всех других модулях и программах, включающих имя} function {данного модуля в своей строке uses. Для процедур и функций} {здесь описываются только заголовки, но с обязательным} {полным описанием формальных параметров.}
{Раздел реализации }
implementation
{В этом разделе указывается реализационная (личная) часть} {описаний данного модуля, которая недоступна для других } {модулей и программ. Другими словами – «внутренняя кухня»}
{Список импорта раздела реализации }
{В этом списке через запятые перечисляются идентификаторы} {тех модулей, информация интерфейсных частей которых должна} {быть доступна в данном модуле. Здесь целесообразно описывать} {идентификаторы всех необходимых модулей, информация из} {которых не используется в описаниях раздела interface данного} {модуля и об использовании которых не должен знать ни один} {другой модуль. }
{Подразделы внутренних для модуля описаний }
label {В этих подразделах описываются метки, константы, типы,} const {переменные, процедуры и функции, которые описывают} type {алгоритмические действия, выполняемые данным модулем, и} var {которые являются «личной собственностью» исключительно} procedure{только данного модуля. Эти описания недоступны ни одному} function {другому модулю. Заголовки процедур и функций в этом} {подразделе допускается указывать без списка формальных} {параметров. Если заголовки указаны все же с параметрами, то} {их список должен быть идентичен такому же списку для} {соответствующей процедуры (функции) в разделе interface}
{Раздел инициализации }
{В этом разделе указываются операторы начальных установок,} {необходимых для запуска корректной работы модуля. Операторы} {разделов инициализации модулей, используемых в программе,} {выполняются при начальном запуске программы в том же } {порядке, в каком идентификаторы модулей описаны в } {предложении uses. Если операторы инициализации не требуются, } {то слово begin может быть опущено.}
end .
Заголовок модуля и связь модулей друг с другом
Заголовок модуля состоит из зарезервированного слова unit и следующего за ним имени модуля. Для правильной работы среды Турбо Паскаля и возможности подключения средств, облегчающих разработку больших программ, имя модуля должно совпадать с именем дискового файла , в который помещается исходный текст модуля. Если, например, имеем заголовок модуля
Unit primer;
то исходный текст этого модуля должен размещаться на диске в файле primer.pas.
Имя модуля служит для его связи с другими модулями и основной программой. Эта связь устанавливается специальным предложением:
uses <список модулей>
Здесь USES – зарезервированное слово (использует);
<список модулей> - список модулей, с которыми устанавливается связь; элементы списка – имена модулей через запятую.
Если в программе модули используются, то предложение uses <список модулей> должно стоять сразу после заголовка программы , т.е. должно открывать раздел описаний основной программы. В модулях могут использоваться другие модули. В модулях предложение uses <список модулей> может стоять сразу после слова interface или сразу после слова implementation. Допускается и два предложения uses, т.е. оно может стоять и там, и там.
Интерфейсная часть
Интерфейсная часть открывается зарезервированным словом INTERFACE . В этой части содержатся объявления всех глобальных объектов модуля (типов, констант, переменных и подпрограмм), которые должны быть доступны основной программе и (или) другим модулям. При объявлении глобальных подпрограмм в интерфейсной части указывается только их заголовок, например:
Procedure AddC(x,y: complex, var z: complex);
Procedure MulC (x,y: complex, var z: complex);
Модульное программирование - это такой способ программирования, при котором вся программа разбивается на группу компонентов, называемых модулями, причем каждый из них имеет свой контролируемый размер, четкое назначение и детально проработанный интерфейс с внешней средой. Единственная альтернатива модульности - монолитная программа, что, конечно, неудобно. Таким образом, наиболее интересный вопрос при изучении модульности - определение критерия разбиения на модули.
Концепции модульного программирования. В основе модульного программирования лежат три основных концепции:
Принцип утаивания информации Парнаса. Всякий компонент утаивает единственное проектное решение, т. е. модуль служит для утаивания информации. Подход к разработке программ заключается в том, что сначала формируется список проектных решений, которые особенно трудно принять или которые, скорее всего, будут меняться. Затем определяются отдельные модули, каждый из которых реализует одно из указанных решений.
Аксиома модульности Коуэна. Модуль - независимая программная единица, служащая для выполнения некоторой определенной функции программы и для связи с остальной частью программы. Программная единица должна удовлетворять следующим условиям:
· блочность организации, т. е. возможность вызвать программную единицу из блоков любой степени вложенности;
· синтаксическая обособленность, т. е. выделение модуля в тексте синтаксическими элементами;
· семантическая независимость, т. е. независимость от места, где программная единица вызвана;
· общность данных, т. е. наличие собственных данных, сохраняющихся при каждом обращении;
· полнота определения, т. е. самостоятельность программной единицы.
Сборочное программирование Цейтина. Модули - это программные кирпичи, из которых строится программа. Существуют три основные предпосылки к модульному программированию:
· стремление к выделению независимой единицы программного знания. В идеальном случае всякая идея (алгоритм) должна быть оформлена в виде модуля;
· потребность организационного расчленения крупных разработок;
· возможность параллельного исполнения модулей (в контексте параллельного программирования).
Определения модуля и его примеры. Приведем несколько дополнительных определений модуля.
· Модуль - это совокупность команд, к которым можно обратиться по имени.
· Модуль - это совокупность операторов программы, имеющая граничные элементы и идентификатор (возможно агрегатный).
Функциональная спецификация модуля должна включать:
· синтаксическую спецификацию его входов, которая должна позволять построить на используемом языке программирования синтаксически правильное обращение к нему;
· описание семантики функций, выполняемых модулем по каждому из его входов.
Разновидности модулей. Существуют три основные разновидности модулей:
1) "Маленькие" (функциональные) модули, реализующие, как правило, одну какую-либо определенную функцию. Основным и простейшим модулем практически во всех языках программирования является процедура или функция.
2) "Средние" (информационные) модули, реализующие, как правило, несколько операций или функций над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля. Примеры "средних" модулей в языках программирования:
a)задачи в языке программирования Ada;
b)кластер в языке программирования CLU;
c)классы в языках программирования C++ и Java.
3) "Большие” (логические) модули , объединяющие набор "средних" или "маленьких" модулей. Примеры "больших" модулей в языках программирования:
a)модуль в языке программирования Modula-2;
b)пакеты в языках программирования Ada и Java.
Набор характеристик модуля предложен Майерсом [Майерс 1980]. Он состоит из следующих конструктивных характеристик:
1) размера модуля;
В модуле должно быть 7 (+/-2) конструкций (например, операторов для функций или функций для пакета). Это число берется на основе представлений психологов о среднем оперативном буфере памяти человека. Символьные образы в человеческом мозгу объединяются в "чанки" - наборы фактов и связей между ними, запоминаемые и извлекаемые как единое целое. В каждый момент времени человек может обрабатывать не более 7 чанков.
Модуль (функция) не должен превышать 60 строк. В результате его можно поместить на одну страницу распечатки или легко просмотреть на экране монитора.
2) прочности (связности) модуля;
Существует гипотеза о глобальных данных, утверждающая, что глобальные данные вредны и опасны. Идея глобальных данных дискредитирует себя так же, как и идея оператора безусловного перехода goto. Локальность данных дает возможность легко читать и понимать модули, а также легко удалять их из программы.
Связность (прочность) модуля (cohesion) - мера независимости его частей. Чем выше связность модуля - тем лучше, тем больше связей по отношению к оставшейся части программы он упрятывает в себе. Можно выделить типы связности, приведенные ниже.
Функциональная связность. Модуль с функциональной связностью реализует одну какую-либо определенную функцию и не может быть разбит на 2 модуля с теми же типами связностей.
Последовательная связность. Модуль с такой связностью может быть разбит на последовательные части, выполняющие независимые функции, но совместно реализующие единственную функцию. Например, один и тот же модуль может быть использован сначала для оценки, а затем для обработки данных.
Информационная (коммуникативная) связность. Модуль с информационной связностью - это модуль, который выполняет несколько операций или функций над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля. Эта информационная связность применяется для реализации абстрактных типов данных.
Обратим внимание на то, что средства для задания информационно прочных модулей отсутствовали в ранних языках программирования (например, FORTRAN и даже в оригинальной версии языка Pascal). И только позже, в языке программирования Ada, появился пакет - средство задания информационно прочного модуля.
3) сцепления модуля с другими модулями;
Сцепление (coupling) - мера относительной независимости модуля от других модулей. Независимые модули могут быть модифицированы без переделки других модулей. Чем слабее сцепление модуля, тем лучше. Рассмотрим различные типы сцепления.
Независимые модули - это идеальный случай. Модули ничего не знают друг о друге. Организовать взаимодействие таких модулей можно, зная их интерфейс и соответствующим образом перенаправив выходные данные одного модуля на вход другого. Достичь такого сцепления сложно, да и не нужно, поскольку сцепление по данным (параметрическое сцепление) является достаточно хорошим.
Сцепление по данным (параметрическое) - это сцепление, когда данные передаются модулю, как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции. Этот вид сцепления реализуется в языках программирования при обращении к функциям (процедурам). Две разновидности этого сцепления определяются характером данным.
· Сцепление по простым элементам данных.
· Сцепление по структуре данных. В этом случае оба модуля должны знать о внутренней структуре данных.
4) рутинности (идемпотентность, независимость от предыдущих обращений) модуля.
Рутинность - это независимость модуля от предыдущих обращений к нему (от предыстории). Будем называть модуль рутинным, если результат его работы зависит только от количества переданных параметров (а не от количества обращений).
Модуль должен быть рутинным в большинстве случаев, но есть и случаи, когда модуль должен сохранять историю. В выборе степени рутинности модуля пользуются тремя рекомендациями.
· В большинстве случаев делаем модуль рутинным, т. е. независимым от предыдущих обращений.
· Зависящие от предыстории модули следует использовать только в тех случаях, когда это необходимо для сцепления по данным.
· В спецификации зависящего от предыстории модуля должна быть четко сформулирована эта зависимость, чтобы пользователи имели возможность прогнозировать поведение такого модуля.
Основным принципом модульного программирования является принц ип "разделяй и властвуй". Модульное программирование - это организация программы как совокупности небольших независимых блоков, называемых модулями, структура и поведение которых подчиняются определенным правилам.
Заметим, что нужно различать использование слова "модуль", когда имеется в виду синтаксическая конструкция языков программирования (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 непосредственных потомков.
После того как начинающий embedder наморгается светодиодом, он непременно решит написать нечто более серьезное и у него как у любого начинающего будет только одно желание «чтобы всё быстрее заработало!!!». В такой попытке самоутвердиться он будет писать всё в один файл, не задумываясь о структуре программы, но через некоторое время, когда часть задуманного будет реализована, станет понятно, что чем больше становится программа, тем тяжелее в ней что-либо найти. Это натолкнет его на мысль, что у программы должна быть структура и он пойдёт на просторах интернета смотреть, как решают этот вопрос другие embedder"ы. Посмотрев, как выглядят программы, написанные другими людьми, он сделал вывод, что программу разбивают на файлы, которые представляют законченные логические единицы, что часть функции и переменных выносят в хэдер и ещё много чего. Всё вышеописанное - мой опыт, но все начинающие проходят один и тот же путь, поэтому опишу здесь, то с чем столкнулся сам.
Предположим у нас есть программа, которая выводит температуру на lcd дисплей и что для lcd дисплея, что для датчика температуры(ds18b20 ), нужна инициализация, а также функции для работы с ними. Поэтому логично будет создать два отдельных файла lcd.c и ds18b20.с , которые будут содержать в себе функции необходимые для работы. Такие файлы называют модулями , хотелось бы отметить, что каждый модуль представляет собой независимую, логически-завершенную единицу, которую можно компилировать отдельно от остальной программы . При компиляции модуля компилятор сделает из него объектный файл.
Следующий вопрос, который возникает, раз модуль это независимая структура, можно сказать «вещь в себе
», то она не имеет связи с внешним миром, а нас это не устраивает. Для связи модулей с внешним миром используется заголовочные файлы, их также называют хэдерами/хидерами
и они имеют расширение .h
. Назвать хэдер можно как угодно, но удобнее, чтобы его название совпадало с названием модуля, lcd.h
и ds18b20.h
, также надо сказать, что все подключаемые файлы(#include
) удобно вынести в хэдер и подключать только его вначале модуля.
Когда хэдера не было, начало lcd.с выглядело так
#define F_CPU 8000000UL
#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 дисплей подключается файл с шрифтами.
На этом всё, мне кажется это минимум, который необходимо знать каждому начинающему программисту микроконтроллеров.
