Что такое модуль в компьютерной программе. «Забытые» парадигмы программирования. o зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения параметрического сцепления

Модульное программирование работает по принципу «разделяй и властвуй». Стоит разобраться.

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

Сам термин «модуль» начал использоваться в программировании в связи с внедрением модульного принципа при написании программ. В семидесятых годах модулем называли какую-то функцию или процедуру, которая была написана по определенным правилам. Так как на тот момент не было сформировано общепризнанных требований, то модулем называли любую процедуру, чей размер составлял до пятидесяти строк. Парнасом были сформированы первые конкретизированные требования к модулю: « Для формирования одного модуля должно быть достаточно самых минимальных знаний о содержании другого». Получается, именно Парнас впервые сформировал концепцию скрытия информации в программировании. Его определение приводит нас к тому, что модулем может называться любая отдельная процедура как самого нижнего, так и самого верхнего уровня иерархии. Надежно скрытие информации нельзя было обеспечить посредством использования конструкций, существующих в то время, так как они было подвержены сильному действию глобальных переменных, а их поведение в сложных программах предсказать весьма сложно. Необходимо было создать конструкцию, изолированную от этих переменных. Именно ее и назвали модулем, а на его основе и зародилось модульное программирование.

Изначально предполагалось, что реализация сложных программных комплексов может быть осуществлена при использовании модуля наравне с функциями и процедурами в качестве конструкции, объединяющей и скрывающей детали реализации какой-то конкретной подзадачи. Но в языке Turbo Pascal не был полностью реализован модульный принцип программирования. В этом языке полностью отсутствует поддержка внутренних модулей, импорт реализован недостаточно гибко, так как не позволяет осуществлять импорт объектов из каких-то других модулей. Совместное влияние этого обстоятельства с тем, что с распространением персональных компьютеров существенно расширился круг программирующих людей, что снизило средний уровень теоретической подготовленности, привело к тому, что при разработке приложений модули применялись в качестве средств создания проблемных библиотек функций и процедур. Лишь квалифицированными программистами применялась вся мощь данной языковой конструкции для операций по структурированию всех объектов.

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

Парадигмы программирования

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

Мо́дуль - функционально законченный фрагмент программы . Во многих языках (но далеко не обязательно) оформляется в виде отдельного файла с исходным кодом или поименованной непрерывной её части. Некоторые языки предусматривают объединение модулей в пакеты .

Энциклопедичный YouTube

  • 1 / 5

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

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

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

    Модульная система модулей

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

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

    История концепции модулей

    История концепции модулей как единиц компиляции восходит к языкам Фортран II и Кобол , то есть, к концу 1950-х годов . В 1976 году появилась публикация, в которой была развита концепция модульности - о языке Mesa (англ. ) , который был разработан в Xerox PARC . В 1977 году подробно ознакомился с этой концепцией учёный Никлаус Вирт , общаясь с разработчиками в Xerox PARC. Эти идеи были использованы Виртом при создании языка Модула-2 , публикация о котором вышла в 1977 году .

    Термин «модуль» в программировании начал использоваться в связи с внедрением модульных принципов при создании программ. В 1970-х годах под модулем понимали какую-либо процедуру или функцию, написанную в соответствии с определёнными правилами. Например: «модуль должен быть простым, замкнутым (независимым), обозримым (от 50 до 100 строк), реализующим только одну функцию задачи, имеющим одну входную и одну выходную точку».

    Первым основные свойства программного модуля более-менее чётко сформулировал Д. Парнас (David Parnas) в 1972 году : «Для написания одного модуля должно быть достаточно минимальных знаний о тексте другого». Таким образом, в соответствии с определением, модулем могла быть любая отдельная процедура (функция) как самого нижнего уровня иерархии (уровня реализации), так и самого верхнего уровня, на котором происходят только вызовы других процедур-модулей.

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

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

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

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

    Реализация в языках программирования

    Языки, формально поддерживающие концепцию модулей: IBM S/360

    ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ПРОГРАММ

    Введение

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

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

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

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

    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).

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

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

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


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

    Ладно. Введение это очень весело, но вы его все равно не читаете, так что кому интересно - добро пожаловать под кат!

    Императивное программирование



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

    Это были машинные коды, языки ассемблера и ранние высокоуровневые языки, вроде 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++), пространства имен, статические классы и/или динамически подключаемые библиотеки.

    Вместо заключения

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

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

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

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

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

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

    Также имеются дополнительные определения программного модуля.

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

    Функциональная спецификация модуля должна включать:

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

    Модули также разделяют на три категории:

    • - «Маленькие» (функциональные) модули. Они, обычно, реализуют одну или несколько функций. Во всех языках программирования высокого уровня имеется поддержка основного и простейшего модуля: процедуры и функции.
    • - «Средние» (информационные) модули, реализующие, в обычном случае, сравнительно небольшое количество операций или функций над так называемым информационным объектом, который считается за пределами модуля неизвестным. Наиболее известные примеры информационных модулей это классы в таких языках программирования как С, С++, С#, Java и другие.
    • - «Большие» (логические) модули, которые объединяют в себе некоторое количество как «маленьких» так и «средних» модулей. Примером "больших" модулей в языках программирования могут послужить пакеты или сборки в таких языках программирования, как Java.