Light-electric.com

IT Журнал
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

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

Основные принципы программирования: императивное и декларативное программирование

    Переводы, 26 января 2017 в 17:41

Рассказывает Тайлер МакГиннис, Google Developer Expert

Вы наверняка слышали о таких понятиях, как императивное и декларативное программирование, и скорее всего гуглили определения. И поэтому вы наверняка видели что-то подобное: “Императивное программирование — это описание того, как ты делаешь что-то, а декларативное — того, что ты делаешь. Это объяснение отлично подходит тем, кто уже разобрался в этом вопросе — но не новичкам.

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

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

Императивный подход (как): Я вижу, что тот угловой столик свободен. Мы пойдём туда и сядем там.

Декларативный подход (что): Столик для двоих, пожалуйста.

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

Я задам вам вопрос и хочу, чтобы вы придумали и императивный, и декларативный подход.

“Я у Ашана. Как мне пройти до твоего дома?”

“Пройди через северный выход парковки и поверни налево. Сядь на автобус 678 и выйди на остановке “Улица Победы”. Поверни направо, как если бы ты шёл в Икею. Иди прямо и поверни направо у первого светофора. На следующем светофоре поверни налево. Номер моего дома — 134.”

Мой адрес: Энск, улица Победы, дом 134.

Неважно, как я попаду к твоему дому, важно, на какой машине я приеду. У неё будет или императивная механическая КПП, или декларативная автоматическая КПП. Достаточно метафор?

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

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

Теперь мы перейдём от приятных метафор к реальному коду. Сперва посмотрим, какие языки являются декларативными, а какие — императивными:

  • Императивные: C, C++, Java.
  • Декларативные: SQL, HTML.
  • Смешанные (могут быть таковыми): JavaScript, C#, Python.

Вот типичные примеры на SQL и HTML:

Достаточно взглянуть на них, чтобы понять, что происходит. Они декларативны, заявляя, что должно быть сделано, а не как. Вы описываете желаемый результат, не углубляясь в инструкции. Неважно, как будут выбраны пользователи из Мексики. Неважно, как браузер распарсит ваш article . Важно, что вы получите мексиканских пользователей и новый header и paragraph на сайте.

Пока неплохо. Давайте рассмотрим примеры на JavaScript.

Представьте, что вы на собеседовании. Откройте консоль и ответьте на следующие вопросы.

  1. Напишите функцию, называющуюся double , которая принимает массив чисел и возвращает новый массив, каждый элемент которого в два раза больше входного: double([1,2,3]) -> [2,4,6] .
  2. Напишите функцию, называющуюся add , которая принимает массив и возвращает сумму всех его элементов: add([1,2,3]) -> 6 .
  3. Используя jQuery (или чистый JavaScript), добавьте обработчик события click к элементу с id , равным btn . По нажатию переключите класс highlight и смените текст на Add Highlight или Remove Highlight , в зависимости от текущего состояния элемента.

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

Разобравшись, что общего у этих императивных примеров, мы поймём, что именно делает их императивными.

  1. Очевидно, что все они описывают, как решить проблему: мы явно указываем все шаги.
  2. Это уже не так очевидно для тех, кто не привык думать декларативно, или даже функционально. В каждом примере происходит изменение какого-либо состояния. В первых двух примерах происходило изменение переменной results , а в третьей состояние было в самой DOM – и его мы тоже изменяли.
  3. Это уже субъективно, но я считаю, что код выше нечитаем. Я не могу с первого взгляда понять, что происходит — вместо этого мне приходится читать код построчно.

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

Заметьте, что в первых двух примерах я использовал встроенные методы JavaScript, map и reduce . Как видите, декларативные решения вновь оказались абстракциями над императивными реализациями. Но нас не интересует, как реализованы эти методы. Мы также не изменяем состояния, да и читается этот код лучше.

Ну а третий? В нём я немного схитрил, использовав React — но обратите внимание, что все три императивные ошибки исправлены. React замечателен тем, что в нём вы можете создавать декларативные пользовательские интерфейсы. Смотря на компонент Btn, сразу понятно, как будет выглядеть интерфейс. Кроме того, состояния «живут» не в DOM, а в самом React-компоненте.

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

WebDev → Императивное vs Функциональное программирование

Парадигма — это стиль написания исходного кода компьютерной программы. Существует несколько парадигм.

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

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

Для этой парадигмы характерно использование:

  • именованных переменных;
  • оператора присваивания;
  • составных выражений;
  • подпрограмм;
  • циклов.

К подвидам императивного программирования относят Процедурное и Объектно-ориентированное программирование (ООП).

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

К подвидам декларативного программирования относят Функциональное и Логическое программирование.

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

Для этой парадигмы характерно:

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

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

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

Читать еще:  С язык программирования с нуля

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

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

Примеры языков
Императивные: Ruby, PHP, Python, C++, C#, Java, JavaScript, Swift и т.д.
Функциональные: Haksell, Erlang
Логические: Prolog
Мультипарадигменные: Clojure, Ocaml, Scale, F#

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

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

Выводы

Еесли кратко: императивная — манипулирование состоянием; декларативная парадигма — отсутствие состояния.

В общем и целом, декларативное программирование идет от человека к машине, тогда как императивное — от машины к человеку.

Декларативное и императивное программирование

Или насколько неверным было мое представление о React

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

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

Что такое декларативное и императивное программирование?

Согласно этой и этой информации:

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

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

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

Хорошо, вот метафора.

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

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

Продемонстрируй в коде

Ладно, ладно, вот несколько примеров кода. У нас есть кнопка, которая меняет цвет при нажатии. Я начну с императивного примера:

И пример нашего декларатвного React:

Возможно, различия незначительны. У нас по-прежнему есть логика, которая говорит: если красный, значит синий, но есть одна огромная разница. Пример c React никогда не затрагивает элемент. Он просто объявляет, что элемент должен отображаться с учетом нашего текущего состояния (далее — state). Он фактически не манипулирует самим DOM.

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

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

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

Чего следует избегать

Я либо допустил, либо позволил допустить все эти ошибки в коде, над которым работал. Это всего лишь советы.

  • Избегайте refs. Конечно, иногда они необходимы, но если вы чувствуете, что подбираетесь к refs, это часто означает, что вы делаете что-то неправильно. (В документации React указаны некоторые уместные способы использования refs).
  • Попытка манипулировать DOM напрямую (это очень тесно связано с Refs)
  • Вместо возвращения функций, которые рендерят компонент, лучше возвращайте функции, которые возвращают необходимую информацию для отображения компонента. В первом случае мы указываем, что делать (отобрази именно это), а во втором -возвращаем некоторую информацию (используйте эту информацию, чтобы что-то сделать).
  • Общение между siblings, а не через компоненты. Постарайтесь общаться только с другими компонентами через props.
  • Используйте чистые функциональные компоненты где это возможно. Поскольку эти компоненты не имеют методов жизненного цикла, они требуют, чтобы вы полагались на декларативный, основанный на props подход. Они также могут повысить производительность.

Императивное vs Декларативное программирование в javascript

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

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

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

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

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

Сложность этой темы, как заметил Merrick, в том, что «это одна из тех вещей, которые вы понимаете интуитивно, но не можете объяснить».

Читать еще:  Значок безопасное извлечение устройства не работает

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

Вернемся к изначальному определению, над которым я уже смеялся:

Императивное программирование похоже на то, «как» вы что-то делаете, а декларативное программирование больше похоже на «что» вы делаете».

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

Вы решаете, что тратите слишком много времени на споры об «изнурительном JavaScript» («JavaScript Fatigue» ™) и реактивном функциональном программировании (Reactive Functional Programming), и ваш супруг достоин хорошего свидания. Вы решили пойти в Red Lobster, так как вы слушали много Бейонсе в последнее время. Вы приезжаете в Red Lobster, подходите к стойке и говорите…

Императивный подход (КАК): я вижу, что стол под знаком Gone Fishin’ свободен. Мы бы хотели подойти к нему и занять.

Декларативный подход (ЧТО): Стол для двоих, пожалуйста.

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

Задам вопрос и хочу, чтобы вы подумали об «императивном» и «декларативном» ответе.

«Я из Wal-Mart. Как мне добраться до вашего дома отсюда?»

Императивный ответ: выйдите с северного выхода паркинга и поверните налево. Затем по I-15 на юг, пока не доберетесь до съезда с Bangerter Highway. Поверните направо, как будто вам нужно в ИКЕА. Идите прямо и поверните направо на первом светофоре. Двигайтесь дальше к следующему светофору, поверните налево. Мой дом 298.

Декларативный ответ: мой адрес — 298 West Immutable Alley, Draper Utah 84020.

Вне зависимости от того, как я доберусь до вашего дома, машину-то я вожу. Собираюсь ли я водить «императивную машину «на ручке» или «декларативную автоматическую машину». Хватит метафор?

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

Декларативный ответ сотруднику Red Lobster предполагает, что тот знает все необходимые шаги, чтобы разместить нас. Знание адреса предполагает, что у вас есть какой-то GPS, который в курсе императивных шагов, как добраться до вашего дома.

Автоматический автомобиль имеет какой-то уровень абстракции над переключением передач.

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

Если это предложение имеет для вас смысл, то вы молодец!

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

  • Императивные: C, C++, Java;
  • Декларативные: SQL, HTML;
  • Могут сочетать в себе оба подхода: JavaScript, C#, Python.

Подумайте здесь о типичном примере на SQL или HTML:

Изучив оба примера, у вас появится очень четкое понимание происходящего. Они оба декларативные. Они «обеспокоены» тем, ЧТО вы хотите сделать, а не КАК.

Вы описываете, чего вы пытаетесь достичь, не указывая как. Реализация выбора всех пользователей из Мексики была «абстрагирована». Вас не интересует, как веб-браузер анализирует вашу статью и отображает ее на экране. Ваше — это то, ЧТО такое пользователи из Мексики и новый заголовок и абзац на вашем сайте.

Все идет прекрасно! Перейдем к практической части на JavaScript.

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

Напишите функцию double, которая принимает массив чисел и возвращает новый массив после удвоения каждого элемента в этом массиве. double([1,2,3]) -> [2,4,6]

Напишите функцию add, которая принимает массив и возвращает результат сложения элементов массива. add ([1,2,3]) -> 6

Используя jQuery (или vanilla JavaScript), добавьте обработчик событий click к элементу с id=»btn» . При нажатии нужно переключить (добавить или удалить) класс подсветки, а также изменить текст, чтобы добавить подсветку или удалить подсветку в зависимости от текущего состояния элемента.

Рассмотрим наиболее распространенные подходы, которые также могут быть императивными:

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

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

Это может быть не столь очевидно, если вы не привыкли думать декларативно, или даже более конкретно — функционально. В каждом примере мы мутируем некоторую часть состояния (если Вы не знакомы с термином состояние (state), то это в основном информация о чем-то, что хранится в памяти, что должно звучать как очень похожее на переменные). В первых двух примерах мы создаем переменную results, а затем постоянно модифицируем ее. В третьем примере у нас нет переменных, но у нас есть состояние, живущее в DOM и затем мы изменяем это состояние в DOM.

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

Ладно, хватит уже bullshita’ в коде) Рассмотрим некоторые декларативные примеры. Идея в том, чтобы исправить все проблемы сверху. Таким образом, каждый пример должен описывать, ЧТО происходит, не может мутировать состояние и должен легко читаться с первого взгляда.

Обратите внимание, что в первых двух примерах мы использовали методы map и reduce «из коробки» JavaScript. Это восходит к тому, о чем мы говорим снова и снова в этой статье, что большинство декларативных решений являются абстракцией над некоторой императивной реализацией.

В каждом примере мы описываем то, ЧТО мы хотим, а не КАК (мы не знаем, КАК реализованы map и reduce, но нам это и не важно). Мы не мутируем state. Все мутации абстрагированы в map и reduce. Это также и более читабельно (как только вы привыкнете к map и reduce, конечно).

А как насчет № 3? Ну, я немного обманул вас и использовал React, но обратите внимание, что все три императивные ошибки исправлены. Настоящая красота React в том, что вы можете создавать декларативные UI. Глядя на наш компонент Btn, я могу легко понять, как будет выглядеть UI. Другое выгодное отличие — вместо того, чтобы состояние (state) «жило» в DOM, оно «живет» в компоненте React.

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

Читать еще:  C веб программирование

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

Одна вещь, которую я не рассматривал слишком детально, — это то, что функциональное программирование является подмножеством декларативного программирования. Если вы еще этого не проходили, я настоятельно рекомендую ознакомиться с методами функционального программирования в JavaScript. Начните с .map, .reduce, .filter и «разрабатывайте план действий» с них.

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

Ниже я привел некоторые другие определения из сети, которые могут быть полезными. Или не быть.

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

Императивные языки программирования

Императивные языки программирования манипулируют данными в пошаго­вом режиме, используя последовательные инструкции и применяя их к раз­нообразным данным. Считается, что первым алгоритмическим языком программирования был язык Plankalkuel (от plan calculus), разработанный в 1945-1946 годах Конрадом Цузе (Konrad Zuse).

Класс задач

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

2.1.2. Методология структурного императивного программирования

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

· последовательная декомпозиция алгоритма решения задачи сверху вниз;

· использование структурного кодирования.

Данная методология является важнейшим развитием импе­ративной методологии.

Происхождение

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

Методы

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

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

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

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

Основное отличие от классической методологии императивного программи­рования заключается в отказе (точнее, той или иной степени отказа) от опе­ратора безусловного перехода.

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

Класс задач

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

2.1.3. Методология императивного параллельного программирования

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

Происхождение

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

Методы и концепции

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

Вычислительная модель

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

Синтаксис и семантика

Прямым аналогом оператора в данной методологии является процесс. Основ­ное отличие этой методологии от императивной в том, что процессы могут исполняться параллельно.

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

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

· параллелизм на уровне микрокоманд;

· параллелизм на уровне операторов (кроме циклов);

· параллелизм на уровне циклов и итераций;

· параллелизм на уровне подпрограмм (процедур и функций);

· параллелизм на уровне потоков управления;

· параллелизм на уровне процессов;

· параллелизм на уровне приложений.

Традиционное средство структурирования высокого уровня в данной мето­дологии — процесс. Процессы могут работать параллельно. Они осуществ­ляют синхронизацию между собой с помощью примитивов синхронизации

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

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

Дата добавления: 2018-05-12 ; просмотров: 255 ;

Ссылка на основную публикацию
Adblock
detector