Модульное программирование Модульность в программировании подобна честности в политике: каждый утверждает, что она — одно из его достоинств, но кажется, никто не знает, что она собой представляет. . . Йодан Э.
Основные понятия Модульное программирование – это такой способ программирования, при котором вся программа разбивается на группу компонентов, называемых модулями, причем каждый из них имеет свой контролируемый размер, четкое назначение и детально проработанный интерфейс с внешней средой. Альтернатива модульности – монолитная программа
Основные концепции: В основе модульного программирования лежат три основные концепции: Принцип утаивания информации Парнаса При разработке программ формируется список проектных решений, которые особенно трудно понять или которые , скорее всего, будут меняться. Затем определяются отдельные модули, каждый из которых реализует одно из указанных решений.
Большие программы должны использовать модули без каких-либо предварительных знаний об их внутренней структуре. Примерами удачных модулей могут служить программы ППП (пакетов прикладных программ) и стандартные процедуры. Сборочное программирование Цейтина. Модули – это программные «кирпичи» , из которых строится программа.
Модульность программы «Бизнес с пелёнок»
Основные концепции: Аксиома модульности Коуэна Модуль – независимая программная единица, служащая для выполнения некоторой определенной функции программы и для связи с остальной частью программы. Программная единица должна удовлетворять следующим условиям: Блочность организации Синтаксическая обособленность Семантическая независимость Общность данных Полнота определения
Характеристики модуля (Майерс, 1980) Размер модуля Связность (прочность) модуля Сцепление модуля с другими модулями Рутинность (независимость от предыдущих обращений) модуля
Размер модуля Модуль не должен превышать 60 строк В результате его можно поместить на одну страницу распечатки или легко просмотреть на экране монитора
Связность модуля – мера независимости его частей. Чем выше связность, тем больше связей он «упрятывает» в себе Типы связности: Функциональная Модуль с функциональной связностью реализует одну какуюнибудь функцию и не может быть разбит на два модуля с теми же типами связности Последовательная
Связность модуля Типы связности: Последовательная Модуль с такой связностью может быть разбит на последовательные части, выполняющие независимые функции, но реализующие совместно единственную функцию (например, оценка , а затем обработка данных)
Связность модуля Типы связности: Информационная Модуль с информационной связностью – это модуль, выполняющий несколько операций или функций над одной и той же структурой данных, которая считается неизвестной вне этого модуля (применяется для реализации, например, абстрактных типов данных таких как стек, очередь и др. )
Связность модуля: Следует избегать Временной связности — когда объединяются действия, связанные со временем (например, действия, которые должны быть выполнены в один и тот же момент времени) Логической связности — когда в модуль объединяются действия по признаку их некоторого подобия (например, функции для проверки корректности входных данных для всей программы) Случайной связности — когда действия объединяются произвольным образом Процедурной связности — когда действия сгруппированы вместе только потому, что они выполняются в течение одной и той же части процесса
Модули / Введение в программирование, урок 14 (JavaScript ES6)
Сцепление модулей Сцепление – мера относительной независимости модулей от других модулей. Независимые модули могут быть модифицированы без переделки других модулей. Чем слабее сцепление модуля, тем лучше.
Типы сцепления Независимые модули – идеальный случай. В этом случае модули ничего не знают друг о друге. Взаимодействие модулей организуется через их интерфейсы, когда выходные данные одного модуля передаются на вход другого. Достичь такого сцепления очень сложно, и в большинстве случаев не нужно.
Типы сцепления Сцепление по данным (параметрическое) – это сцепление, когда данные передаются модулю как значения его параметров или как результат его обращения к другому модулю для вычисления некоторой функции (Этот тип сцепления реализуется в языках программирования при обращении к функциям) Разновидности этого сцепления: Сцепление по простым элементам данных Сцепление по структуре данных (оба модуля при этом должны знать о внутренней структуре данных)
Типы сцепления Не рекомендуется использовать: Сцепление по управлению – это сцепление, в котором один модуль управляет решениями внутри другого с помощью передачи флагов, переключателей и т. п. В этом случае один модуль должен достаточно хорошо знать структуру вызывающего модуля Сцепление по внешним ссылкам – возникает, когда у одного модуля есть доступ к данным другого Сцепление по кодам – возникает, когда коды инструкций модулей перемежаются друг с другом (внутренняя область одного модуля доступна другому)
Рутинность модуля – это независимость модуля от предыдущих обращений к нему. Будем называть модуль рутинным, если результат его работы зависит только от количества переданных параметров (а не от количества обращений)
Рутинность модуля В некоторых случаях возникает необходимость в создании модулей, которые должны сохранять предысторию (не рутинные) В выборе степени рутинности пользуются тремя рекомендациями: В большинстве случаев делаем модуль рутинным Зависящие от предыстории модули следует использовать только в том случае, когда необходимо сцепление по данным В спецификации зависящего от предыстории модуля должна быть сформулирована эта зависимость
Свойства модуля На модуль можно ссылаться с помощью имени модуля. Модуль должен иметь один вход и один выход Модуль должен быть сравнительно невелик Возможность сепаратной компиляции Модуль может вызвать другой модуль или сам себя Модуль должен возвращать управление тому, кто его вызвал Модуль не должен сохранять историю своих вызовов для управления своим функционированием
Преимущества модульного программирования: Функциональные компоненты модульной программы могут быть написаны и отлажены порознь Модульную программу проще проектировать, легче сопровождать и модифицировать Становится проще процедура загрузки в оперативную память боль-шой программы, требующей сегментации
Недостатки модульного программирования: Может увеличиться время компиляции и загрузки. Может увеличиться время исполнения программы. Может возрасти объем требуемой памяти. Организация межмодульного взаимодействия может оказаться довольно сложной. Для современных компьютеров недостатка несущественны. первые три
Стандартные модули Разработка и использование стандартных библиотечных программ является одним из путей построения модульного программирования Преимущества стандартных модулей: 1) стандартные модули экономят время программирования; 2) они также могут экономить память компьютера и выполняться максимально быстро; 3) использование стандартных модулей защищает от ошибок программирования.
Стандартные модули Недостатки: Нужный стандартный модуль иногда бывает трудно найти. Еще труднее – подробную документацию к нему Стандартный модуль может оказаться более универсальным, чем это нужно пользователю Стандартный модуль может быть написан на другом языке Каждый программист решает самостоятельно использовать ему стандартные модули или разрабатывать свой собственный.
Подпрограммы (функции) Подпрограммы также являются средством для построения модульных программ Не всякая подпрограмма является модулем. Модуль должен удовлетворять перечисленным выше характеристикам и свойствам.
Источник: present5.com
Что такое модульный принцип в программировании
Модульный принцип — это подход, который позволяет разбить код на небольшие отдельные модули, каждый из которых выполняет определенную функцию. Такая структура упрощает понимание кода и его сопровождение.
Модули могут быть написаны на разных языках программирования и работать в разных средах. При этом они могут быть легко обновлены и переиспользованы в разных проектах.
Модульный принцип особенно полезен в больших проектах, где код достаточно сложный и необходимо сохранять его структуру и связи между модулями.
Для использования модульного принципа необходимо определить границы модулей и разработать структуру их отношений. Это поможет уменьшить связность между модулями и улучшить их независимость, что повышает гибкость и масштабируемость кода.
Модульный принцип в программировании
Модульный принцип – это подход к разработке программ, основанный на разбиении исходного кода на логически самостоятельные модули. Каждый модуль выполняет определенную задачу и может быть использован в различных проектах.
Модули могут быть написаны на разных языках программирования и могут использовать друг друга для выполнения задач. Это позволяет существенно ускорить процесс разработки, улучшить качество исходного кода и сделать его более удобным для сопровождения.
Кроме того, использование модульного принципа позволяет легче тестировать отдельные части программы и быстро исправлять ошибки. При этом изменения в одном модуле не влияют на работу других модулей, что делает код более надежным и устойчивым к изменениям.
Модули могут быть организованы в иерархическую структуру, где более крупные модули используют более мелкие. Это позволяет упростить процесс взаимодействия модулей и улучшить модульность программы в целом.
Важно понимать, что использование модульного принципа требует определенного уровня организованности и планирования реализации программы. Однако, правильное применение этого подхода может существенно упростить и ускорить процесс разработки программного обеспечения, повысить его качество и устойчивость к изменениям.
Определение и принцип работы
Модульный принцип – это методология программирования, основанная на создании независимо работающих частей программного кода, называемых модулями. Каждый модуль ответственен за выполнение конкретных задач, их переиспользование облегчает создание новых программ и расширение функционала уже существующих.
Основной принцип модульного программирования заключается в том, чтобы разбить сложную задачу на множество маленьких подзадач, каждая из которых решается отдельным модулем. Корректная организация модулей помогает разработчикам избежать дублирования кода и обеспечить его повторное использование в дальнейшем.
Каждый модуль должен решать только одну задачу и иметь ярко выраженный функционал. Это позволяет разработчикам создавать многофункциональные программы на основе множества небольших модулей. Другой важным принципом модульного программирования является минимизация связей между модулями, чтобы упростить разработку и поддержку программного кода.
Модульный принцип является основой современных методологий программирования и наиболее эффективно применяется в больших и сложных проектах. Его использование в разработке программных продуктов может драматически повысить производительность и упростить их сопровождение в дальнейшем.
Преимущества использования модульного принципа
Увеличение гибкости проекта. Разбивая проект на отдельные модули, можно легко добавлять, удалять и изменять их в любом порядке без проблем с другими частями приложения. Это позволяет быстро изменять направление разработки и вносить изменения, не затрагивая другие модули.
Улучшение повторного использования кода. Модульный подход помогает создавать независимые модули, которые могут быть использованы в различных проектах. Здесь может использоваться применение шаблонов проектирования для создания повторно используемых модулей, который дают возможность создания гибких и эффективных кодовых баз знаний.
Более простое тестирование и отладка. Тестирование и отладка проекта становятся более удобными, потому что модули имеют явные входы и выходы. Модули можно тестировать в отдельности, не затрагивая другие модули, что упрощает и ускоряет процесс разработки и обнаружения ошибок.
Улучшенное распределение заданий. Разбивая проект на модули, можно распределить задания между различными командами или разработчиками, которые могут работать независимо друг от друга. Каждый может работать с отдельным модулем независимо от других, что упрощает процесс совместной разработки и ускоряет работы.
Уменьшение сложности и упрощение проекта. Разбиение проекта на более мелкие модули упрощает понимание проекта в целом. Каждый программист имеет возможность разрабатывать отдельный модуль, имея лишь общее представление об этом проекте в целом. Это также позволяет более легко вносить изменения и добавления в проект, не затрагивая другие модули.
- Все приведенные выше преимущества позволяют:
- сократить время разработки
- упростить масштабирование проекта
- обеспечить лучшее обслуживание проекта в различных средах и платформах
- оптимально использовать ресурсы системы и аппаратного обеспечения
Как правильно использовать модульный принцип в проектах
Модульный принцип в программировании — это подход, который заключается в разбиении проекта на маленькие, автономные модули. Каждый модуль имеет свою собственную область ответственности и сам по себе может выполнять определенную задачу. Этот подход значительно упрощает разработку и управление проектом, а также снижает количество ошибок.
Однако, просто разбить проект на модули недостаточно. Нужно также правильно организовать взаимодействие между модулями. Вот несколько советов для правильного использования модульного принципа:
- Обдумайте структуру проекта. Проанализируйте проект и разбейте его на маленькие блоки, которые могут быть выполнены в отдельности. Убедитесь, что эти блоки не зависят друг от друга и могут быть использованы повторно в других проектах.
- Определите интерфейсы. Определите наборы данных, функций и методов, которые будут использоваться каждым модулем, а также их входные и выходные данные. Затем определите, каким образом модули будут использовать интерфейсы друг друга.
- Разработайте API. Разработайте простой, четкий API, который объединит все модули в один проект. Этот API должен быть понятен и легко использоваться другими разработчиками.
- Тестируйте каждый модуль отдельно. Каждый модуль должен быть протестирован, чтобы убедиться, что он работает корректно. Модульные тесты могут помочь идентифицировать ошибки и обеспечить правильную работу приложения.
Использование модульного принципа может значительно упростить процесс разработки проекта и улучшить его качество. Однако, чтобы достигнуть максимальной эффективности, следует правильно организовать модули, определить интерфейсы и разработать четкий API.
Источник: psk-group.su
Модульность
Аннотация: В лекциях 3-6 будут рассмотрены требования к разработке программного продукта, которые почти наверняка приведут нас к объектной технологии.
Второе [из правил, которые я решил твердо соблюдать] — делить каждую из рассматриваемых мною трудностей на столько частей, сколько потребуется, чтобы лучше их разрешить.
Третье — располагать свои мысли в определенном порядке, начиная с предметов простейших и легко познаваемых, и восходить мало-помалу, как по ступеням, до познания наиболее сложных, допуская существование порядка даже среди тех, которые в естественном ходе вещей не предшествуют друг другу.
Рене Декарт, «Рассуждения о методе» (1637)
Чтобы обеспечить расширяемость (extendibility) и повторное использование ( reusability ), двух основных факторов качества, предложенных в лекции 1, необходима система с гибкой архитектурой, состоящая из автономных программных компонент . Именно поэтому в лекции 1 введен термин модульность ( modularity ), сочетающий оба фактора.
Модульное программирование ранее понималось как сборка программ из небольших частей, обычно подпрограмм. Но такой подход не может обеспечить реальную расширяемость и повторное использование программного продукта, если не гарантировать, что элементы сборки — модули — являются самодостаточными и образуют устойчивые структуры. Любое достаточно полное определение модульности должно обеспечивать реализацию этих свойств.
Таким образом, метод проектирования программного продукта является модульным, если он помогает проектировщикам создать систему, состоящую из автономных элементов с простыми и согласованными структурными связями между ними. Цель этой лекции — детализация этого неформального определения и выяснение того, какими конкретно свойствами должен обладать метод, заслуживающий название «модульного». Наше внимание будет сосредоточено на этапе проектирования, но все идеи применимы и к ранним этапам — анализа и спецификации, также как и к этапам разработки и сопровождения.
Рассмотрим модульность с разных точек зрения. Введем набор дополнительных свойств: пять критериев ( criteria ), пять правил (rules) и пять принципов (principles) модульности, обеспечивающих при их совместном использовании выполнение наиболее важных требований, предъявляемых к методу модульного проектирования.
Для практикующего разработчика ПО принципы и правила не менее важны, чем критерии. Различие лишь в причинной связи: критерии являются взаимно независимыми (метод может удовлетворять одному из них и в тоже время противоречить оставшимся), в то время как правила следуют из критериев, а принципы следуют из правил.
Можно было бы ожидать, что эта лекция начнется с подробного описания того, как выглядит модуль . Но это не так, и для этого есть серьезные основания. Задача этой и двух следующих лекций — анализ свойств, которыми должна обладать надлежащим образом спроектированная модульная структура. Вопросом о виде модулей мы займемся в конце нашего обсуждения, а не в его начале.
И пока мы не дойдем до этой точки, слово » модуль » будет означать компонент разбиения рассматриваемой системы. Если вы знакомы с не ОО-методами, то, вероятно, вспомните о подпрограммах, имеющихся в большинстве языков программирования и проектирования, или, быть может, о пакетах (packages) языка Ada и (правда, под другим названием) языка Modula . Наконец, в последующих лекциях наше обсуждение приведет к ОО-виду модуля — классу. Даже если вы уже знакомы с классами и ОО-методами, все же следует прочитать эту лекцию для понимания требований, предъявляемых к классам, — это поможет правильному их конструированию.
Пять критериев
Метод проектирования, который можно называть «модульным», должен удовлетворять пяти основным требованиям:
- Декомпозиции (decomposability).
- Композиции ( composability ).
- Понятности (understandability).
- Непрерывности (continuity).
- Защищенности (protection).
Декомпозиция
Метод проектирования удовлетворяет критерию Декомпозиции, если он помогает разложить задачу на несколько менее сложных подзадач, объединяемых простой структурой, и настолько независимых, что в дальнейшем можно отдельно продолжить работу над каждой из них.
Такой процесс часто будет циклическим, поскольку каждая подзадача может оказаться достаточно сложной и потребует дальнейшего разложения.
Рис. 3.1. Декомпозиция
Следствием требования декомпозиции является разделение труда (division of labor): как только система будет разложена на подсистемы, работу над ними следует распределить между разными разработчиками или группами разработчиков. Это трудная задача, так как необходимо ограничить возможные взаимозависимости между подсистемами:
- Необходимо свести такие взаимозависимости к минимуму; в противном случае разработка каждой из подсистем будет ограничиваться темпами работы над другими подсистемами.
- Эти взаимозависимости должны быть известны: если не удастся составить перечень всех связей между подсистемами, то после завершения разработки проекта будет получен набор элементов программы, которые, возможно, будут работать каждая в отдельности, но не смогут быть собраны вместе в завершенную систему, удовлетворяющую общим требованиям к исходной задаче.
Наиболее очевидным примером обсуждаемого метода 1 Дальнейшее обсуждение метода нисходящего проектирования показывает, что этот метод не вполне согласуется с другими критериями модульности. , удовлетворяющим критерию декомпозиции, является метод нисходящего (сверху вниз) проектирования (top-down design). В соответствии с этим методом разработчик должен начать с наиболее абстрактного описания функции, выполняемой системой. Затем последовательными шагами детализировать это представление, разбивая на каждом шаге каждую подсистему на небольшое число более простых подсистем до тех пор, пока не будут получены элементы с настолько низким уровнем абстракции, что становится возможной их непосредственная реализация. Этот процесс можно представить в виде дерева.
Рис. 3.2. Иерархия нисходящего проектирования
Типичным контрпримером (counter-example) является любой метод, предусматривающий включение в разрабатываемую систему модуля глобальной инициализации. Многие модули системы нуждаются в инициализации — открытии файлов или инициализации переменных.
Каждый модуль должен произвести эту инициализацию до начала выполнения непосредственно возложенных на него операций. Могло бы показаться, что все такие действия для всех модулей системы неплохо сосредоточить в одном модуле, который проинициализирует сразу все для всех.
Подобный модуль будет обладать хорошей «согласованностью во времени» ( temporal cohesion ) в том смысле, что все его действия выполняются на одном этапе работы системы. Однако для получения такой «согласованности во времени», придется нарушать автономию других модулей. Придется модулю инициализации дать право доступа ко многим структурам данных, принадлежащим различным модулям системы и требующим специфических действий по их инициализации. Это означает, что автор модуля инициализации должен будет постоянно следить за структурами данных других модулей и взаимодействовать с их авторами. А это несовместимо с критерием декомпозиции.
Термин «согласованность во времени» пришел из метода, известного как структурное проектирование (см. комментарии к библиографии).
| В объектно-ориентированном методе каждый модуль должен самостоятельно инициализировать свои структуры данных. |
Источник: intuit.ru