Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Парадигмы программирования
  • v
  • т
  • е

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

Он появился в конце 1950 - х годов с появлением Алгол 58 и Алгол 60 языков программирования, [1] с последним , включая поддержку блочных структур. Факторами, способствовавшими его популярности и повсеместному признанию, сначала в академических кругах, а затем среди практиков, являются открытие в 1966 году того, что сейчас известно как теорема о структурированной программе [2], и публикация влиятельного « Заявления о вреде » открытое письмо в 1968 году голландского ученого-информатика Эдсгера В. Дейкстры , который ввел термин «структурированное программирование». [3]

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

Элементы [ править ]

Структуры управления [ править ]

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

  • "Последовательность"; упорядоченные операторы или подпрограммы, выполняемые последовательно.
  • «Подборка»; один или несколько операторов выполняется в зависимости от состояния программы. Обычно это выражается такими ключевыми словами , как if..then..else..endif. Условный оператор должен иметь по крайней мере одно истинное условие, и каждое условие должно иметь одну точку выхода на макс.
  • «Итерация»; оператор или блок выполняется до тех пор, пока программа не достигнет определенного состояния или пока операции не будут применены к каждому элементу коллекции. Это, как правило , выражается с помощью ключевых слов , таких как while, repeat, forили do..until. Часто рекомендуется, чтобы у каждого цикла была только одна точка входа (а в исходном структурном программировании также была только одна точка выхода, и несколько языков это предписывают).
  • «Рекурсия»; оператор выполняется путем многократного вызова самого себя до тех пор, пока не будут выполнены условия завершения. Хотя на практике они похожи на итерационные циклы, рекурсивные циклы могут быть более эффективными с точки зрения вычислений и реализованы иначе как каскадный стек.
Графическое представление трех основных шаблонов - последовательности, выбора и повторения - с помощью диаграмм NS (синий) и блок-схем (зеленый).

Подпрограммы [ править ]

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

Блокирует [ править ]

Блоки используются для того, чтобы группы операторов можно было обрабатывать так, как если бы они были одним оператором. Блочно-структурированные языки имеют синтаксис для включения структур некоторым формальным образом, например, оператор if в квадратных скобках, if..fiкак в Алголе 68 , или раздел кода, заключенный в квадратные скобки BEGIN..END, как в PL / I и Pascal , отступы пробелов, как в Python - или фигурные скобки {...}из C и многих более поздних языков .

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

Структурированное программирование можно выполнять на любом языке программирования, хотя предпочтительно использовать что-то вроде процедурного языка программирования . Некоторые из языков, изначально использовавшихся для структурированного программирования, включают: ALGOL , Pascal , PL / I и Ada , но с тех пор большинство новых процедурных языков программирования включают функции, поощряющие структурированное программирование, а иногда и преднамеренно упускают возможности - особенно GOTO - в попытки усложнить неструктурированное программирование . Структурированное программирование (иногда известное как модульное программирование [ необходима ссылка ]) обеспечивает логическую структуру в написанной программе, чтобы сделать ее более эффективной и легкой для понимания и модификации.


История [ править ]

Теоретическая основа [ править ]

Теорема о структурированной программе обеспечивает теоретическую основу структурного программирования. В нем говорится, что трех способов комбинирования программ - последовательности, выбора и итерации - достаточно для выражения любой вычислимой функции . Это наблюдение не связано с движением структурного программирования; эти структуры являются достаточными для описания цикла команд из в центральном блоке обработки , а также работы машины Тьюринга . Следовательно, процессор всегда выполняет «структурированную программу» в этом смысле, даже если инструкции, которые он считывает из памяти, не являются частью структурированной программы. Однако авторы обычно приписывают результат работе Бема и Якопини 1966 года, возможно потому, чтоДийкстра сам цитировал эту статью. [4] Теорема о структурированной программе не касается написания и анализа хорошо структурированной программы. Эти вопросы были рассмотрены в конце 1960-х - начале 1970-х годов при большом вкладе Дейкстры , Роберта В. Флойда , Тони Хора , Оле-Йохана Даля и Дэвида Гриса .

Дебаты [ править ]

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

Американские новообращенные подбрасывали эту интересную новость перед носом неподготовленным программистам на ассемблере, которые продолжали выдвигать извилистые кусочки логики и говорить: «Я уверен, что не могу это структурировать». Ни доказательство Бема и Якопини, ни наши неоднократные успехи в написании структурированного кода не привели их к реальности на один день раньше, чем они были готовы убедить себя. [5]

Дональд Кнут принял принцип, согласно которому программы должны быть написаны с учетом доказуемости, но он не согласился (и все еще не согласен [ необходима цитата ] ) с отменой оператора GOTO. В своей статье 1974 года «Структурированное программирование с помощью операторов Goto» [6] он привел примеры, в которых, по его мнению, прямой переход ведет к более ясному и эффективному коду без ущерба для доказуемости. Кнут предложил более слабое структурное ограничение: должна быть возможность нарисовать блок-схему программы со всеми прямыми ветвями слева, всеми обратными ветвями справа и без пересекающих друг друга ветвей. Многие из тех, кто разбирается в компиляторах и теории графоввыступали за разрешение только приводимых потоковых графов [ когда они определены как? ] . [ кто? ]

Теоретики структурного программирования приобрели главного союзника в 1970-х годах после того, как исследователь IBM Харлан Миллс применил свою интерпретацию теории структурированного программирования к разработке системы индексации для файла исследования The New York Times . Проект имел большой инженерный успех, и менеджеры других компаний ссылались на него в поддержку принятия структурированного программирования, хотя Дейкстра критиковал то, как интерпретация Миллса отличалась от опубликованной работы. [ необходима цитата ]

Еще в 1987 году еще можно было поднять вопрос о структурном программировании в журнале по информатике. Фрэнк Рубин сделал это в том году с открытым письмом, озаглавленным «GOTO считается вредным» считается вредным. [7] Последовали многочисленные возражения, в том числе ответ Дейкстры, в котором резко критиковался как Рубин, так и уступки, сделанные другими писателями, отвечая ему.

Результат [ править ]

К концу 20-го века почти все компьютерные ученые были убеждены, что полезно изучать и применять концепции структурного программирования. Языки программирования высокого уровня, в которых изначально отсутствовали структуры программирования, такие как FORTRAN , COBOL и BASIC , теперь имеют их.

Общие отклонения [ править ]

В то время как goto в настоящее время в значительной степени заменен структурированными конструкциями выбора (if / then / else) и повторения (while и for), немногие языки являются чисто структурированными. Наиболее распространенное отклонение, встречающееся во многих языках, - это использование оператора return для раннего выхода из подпрограммы. Это приводит к нескольким точкам выхода вместо одной точки выхода, требуемой структурированным программированием. Существуют и другие конструкции для обработки случаев, неудобных для чисто структурированного программирования.

Ранний выход [ править ]

Наиболее частым отклонением от структурного программирования является ранний выход из функции или цикла. На уровне функций это returnутверждение. На уровне циклов это breakоператор (завершение цикла) или continueоператор (завершение текущей итерации, переход к следующей итерации). В структурированном программировании их можно воспроизвести путем добавления дополнительных ветвей или тестов, но для результатов вложенного кода это может значительно усложнить работу. C - ранний и яркий пример этих конструкций. В некоторых новых языках также есть «помеченные разрывы», которые позволяют выйти не только из самого внутреннего цикла. Исключения также допускают ранний выход, но имеют дополнительные последствия, поэтому они рассматриваются ниже.

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

Наиболее распространенная проблема при раннем выходе состоит в том, что операторы очистки или final не выполняются - например, выделенная память не освобождается или открытые файлы не закрываются, что вызывает утечки памяти или ресурсов . Это необходимо делать на каждом сайте возврата, который является хрупким и может легко привести к ошибкам. Например, в более поздней разработке разработчик мог упустить из виду оператор return, а действие, которое должно быть выполнено в конце подпрограммы (например, оператор трассировки ), могло бы выполняться не во всех случаях. Языки без оператора возврата, такие как стандартный Pascal и Seed7 , не имеют этой проблемы.

Большинство современных языков обеспечивают поддержку на уровне языка для предотвращения таких утечек; [8] см. Подробное обсуждение в разделе « Управление ресурсами» . Чаще всего это делается с помощью защиты от размотки, которая гарантирует, что определенный код будет гарантированно запускаться, когда выполнение выходит из блока; это структурированная альтернатива блоку очистки и файлу goto. Это чаще всего называют try...finally,и считают частью обработки исключений . В случае множественных returnзаявлений введение try...finally,без исключений может выглядеть странно. Существуют различные методы инкапсуляции управления ресурсами. Альтернативный подход, встречающийся в основном в C ++, - это инициализация получения ресурсов., который использует обычное раскручивание стека (освобождение переменных) при выходе из функции для вызова деструкторов локальных переменных для освобождения ресурсов.

Кент Бек , Мартин Фаулер и соавторы утверждали в своих книгах по рефакторингу, что вложенные условные выражения могут быть труднее для понимания, чем определенный тип более плоской структуры, использующей множественные выходы, определяемые защитными предложениями.. В их книге 2009 г. категорически утверждается, что «одна точка выхода на самом деле не является полезным правилом. Ясность - ключевой принцип: если метод более ясен с одной точкой выхода, используйте одну точку выхода; в противном случае - нет». Они предлагают решение для преобразования функции, состоящей только из вложенных условных выражений, в последовательность защищенных операторов return (или throw), за которыми следует один неохраняемый блок, который предназначен для содержания кода для общего случая, в то время как защищенные операторы являются должен иметь дело с менее распространенными (или с ошибками). [9] Херб Саттер и Андрей Александреску также утверждают в своей книге советов по C ++ 2004 года, что единственная точка выхода является устаревшим требованием. [10]

В своем учебнике 2004 года Дэвид Ватт пишет, что «часто желательны потоки управления с одним входом и несколькими выходами». Использование концепции секвенсора ТеннентаВатт единообразно описывает конструкции потока управления, встречающиеся в современных языках программирования, и пытается объяснить, почему одни типы секвенсоров предпочтительнее других в контексте потоков управления с несколькими выходами. Ватт пишет, что неограниченные переходы (секвенсоры перехода) - это плохо, потому что назначение перехода не является самоочевидным для читателя программы, пока читатель не найдет и не изучит фактическую метку или адрес, являющийся целью перехода. В отличие от этого, Уотт утверждает, что концептуальная цель секвенсора возврата ясна из его собственного контекста, без необходимости исследовать его назначение. Ватт пишет, что класс секвенсоров, известных как escape-секвенсоры, определяемый как «секвенсор, который завершает выполнение команды или процедуры, содержащей текст», включает как разрывы из циклов (включая многоуровневые разрывы), так и операторы возврата. Ватт также отмечает, что, хотя секвенсоры переходов (gotos) были несколько ограничены в таких языках, как C, где цель должна быть внутри локального блока или охватывающим внешним блоком, одного этого ограничения недостаточно, чтобы сделать намерение gotos в C самим собой. -описание, и поэтому они все еще могут производить « спагетти-код ». Ватт также исследует, чем секвенсоры исключений отличаются от секвенсоров перехода и перехода; это объясняется в следующем разделе этой статьи. [11]

В отличие от вышесказанного, Бертран Мейер написал в своем учебнике 2009 года, что инструкции типа breakи continue«просто старые gotoв овечьей шкуре», и настоятельно рекомендовал не использовать их. [12]

Обработка исключений [ править ]

Основываясь на ошибке кодирования из-за катастрофы Ariane 501 , разработчик программного обеспечения Джим Бонанг утверждает, что любые исключения, создаваемые функцией, нарушают парадигму единственного выхода, и предлагает запретить все межпроцедурные исключения. В синтаксисе C ++ это делается путем объявления всех сигнатур функций как noexcept(начиная с C ++ 11) или throw(). [13] Бонанг предлагает, чтобы весь C ++, соответствующий единственному выходу, был написан следующим образом:

bool  MyCheck1 ()  throw ()  {  bool  success  =  false ;  try  {  // Сделайте что-нибудь, что может вызвать исключения.  если  ( ! MyCheck2 ())  {  бросить  SomeInternalException ();  }  // Другой код, аналогичный приведенному выше.  успех  =  правда ;  }  catch  (...)  {  // Все исключения перехватываются и регистрируются.  }  вернуть  успех ; }

Питер Ричи также отмечает, что, в принципе, даже одно throwправо перед returnфункцией in представляет собой нарушение принципа единого выхода, но утверждает, что правила Дейкстры были написаны до того, как обработка исключений стала парадигмой в языках программирования, поэтому он предлагает разрешить любое количество точек выброса в дополнение к одной точке возврата. Он отмечает, что решения, которые обертывают исключения ради создания единого выхода, имеют более высокую глубину вложенности и поэтому их труднее понять, и даже обвиняет тех, кто предлагает применять такие решения к языкам программирования, которые поддерживают исключения участия в мышлении культа карго. . [14]

Дэвид Ватт также анализирует обработку исключений в рамках секвенсоров (представленных в этой статье в предыдущем разделе, посвященном ранним выходам). Ватт отмечает, что ненормальная ситуация (обычно иллюстрируемая арифметическим переполнением или ошибками ввода / вывода, такими как файл не найден) является своего рода ошибки, которая «обнаружена в некоторой программной единице низкого уровня, но [для которой] обработчик более естественно расположен в программной единице высокого уровня». Например, программа может содержать несколько вызовов для чтения файлов, но действие, которое нужно выполнить, когда файл не найден, зависит от значения (цели) файла, о котором идет речь в программе, и, следовательно, процедура обработки этой ненормальной ситуации не может быть находится в системном коде нижнего уровня. Уоттс также отмечает, что введение тестирования флагов состояния в вызывающей стороне,поскольку это повлечет за собой структурированное программирование с одним выходом или даже секвенсоры возврата (с несколькими выходами), это приводит к ситуации, когда «код приложения имеет тенденцию быть загроможденным тестами флагов состояния» и что «программист может забывчиво или лениво пропустить тестирование флаг состояния. Фактически, нештатные ситуации, представленные флагами состояния, по умолчанию игнорируются! " Он отмечает, что в отличие от тестирования флагов состояния, исключения имеют обратноеповедение по умолчанию , в результате чего программа завершается, если программист явно не обрабатывает исключение каким-либо образом, возможно, путем добавления кода для его преднамеренного игнорирования. Основываясь на этих аргументах, Ватт заключает, что секвенсоры переходов или управляющие секвенсоры (обсуждаемые в предыдущем разделе) не так подходят, как выделенный секвенсор исключений с семантикой, рассмотренной выше. [15]

Учебник Лаудена и Ламберта подчеркивает, что обработка исключений отличается от таких структур структурированного программирования, как whileциклы, потому что передача управления «устанавливается в другой точке программы, чем та, где происходит фактическая передача. В точке, где передача фактически происходит. , может не быть синтаксического указания на то, что управление действительно будет передано ". [16] Профессор информатики Арвинд Кумар Бансал также отмечает, что в языках, реализующих обработку исключений, даже управляющие структуры, такие как for, которые имеют свойство единого выхода при отсутствии исключений, больше не имеют его при наличии исключений, потому что исключение может преждевременно вызвать досрочный выход в любой части управляющей структуры; например, если init()выдает исключение вfor (init(); check(); increm()), то обычная точка выхода после check () не достигается. [17] Ссылаясь на многочисленные предыдущие исследования, проведенные другими (1999–2004 гг.), И свои собственные результаты, Уэстли Веймер и Джордж Некула писали, что существенная проблема с исключениями заключается в том, что они «создают скрытые пути потока управления, о которых программистам трудно думать». . [18] : 8:27

Необходимость ограничить код точками единственного выхода возникает в некоторых современных средах программирования, ориентированных на параллельные вычисления, таких как OpenMP . Различные параллельные конструкции из OpenMP, например parallel do, не допускают раннего выхода изнутри наружу параллельной конструкции; это ограничение включает в себя все виды выходов, от breakдо исключений C ++, но все они разрешены внутри параллельной конструкции, если цель перехода также находится внутри нее. [19]

Множественная запись [ править ]

Дополнительная информация: Coroutine

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

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

Конечные автоматы [ править ]

Некоторые программы, особенно синтаксические анализаторы и протоколы связи , имеют ряд состояний, которые следуют друг за другом таким образом, что его нелегко свести к базовым структурам, и некоторые программисты реализуют изменения состояния с переходом к новому состоянию. Этот тип переключения состояний часто используется в ядре Linux. [ необходима цитата ]

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

См. Также [ править ]

  • ДРАКОН
  • Минимальная оценка
  • Диаграмма Насси – Шнейдермана
  • Структурная диаграмма
  • Заявление о переключении

Ссылки [ править ]

Цитаты [ править ]

  1. ^ Кларк, Лесли Б. Уилсон, Роберт Дж .; Роберт, Кларк (2000). Сравнительные языки программирования (3-е изд.). Харлоу, Англия: Эддисон-Уэсли. п. 20. ISBN 9780201710120. Архивировано 26 ноября 2015 года . Проверено 25 ноября 2015 года .
  2. ^ Бом, Коррадо; Джузеппе Якопини (май 1966 г.). «Блок-схемы, машины Тьюринга и языки только с двумя правилами формирования» (PDF) . Коммуникации ACM . 9 (5): 366–371. CiteSeerX 10.1.1.119.9119 . DOI : 10.1145 / 355592.365646 . S2CID 10236439 . Архивировано (PDF) из оригинала 23 сентября 2015 года.   
  3. ^ Дейкстра 1968 , «Необузданное использование оператора go to сразу же приводит к тому, что становится ужасно трудно найти значимый набор координат, в которых можно описать ход процесса. ... Оператор go to в его нынешнем виде - это просто слишком примитивно, это слишком много для того, чтобы испортить свою программу ».
  4. Перейти ↑ Dijkstra, EW (март 1968 г.). «Письма в редакцию: перейти к заявлению, признанному вредным». Коммуникации ACM . 11 (3): 147–148. DOI : 10.1145 / 362929.362947 . ISSN 0001-0782 . S2CID 17469809 .  
  5. ^ Plauger, PJ (12 февраля 1993). Программирование по назначению, Очерки по разработке программного обеспечения (1-е изд.). Прентис-Холл. п. 25 . ISBN 978-0-13-721374-0.
  6. ^ Дональд Кнут - Структурированное программирование с операторами перехода. Архивировано 23 октября 2013 г. в Wayback Machine.
  7. ↑ Франк Рубин (март 1987 г.). " " GOTO Считается вредным "Считается вредным" (PDF) . Коммуникации ACM . 30 (3): 195–196. DOI : 10.1145 / 214748.315722 . S2CID 6853038 . Архивировано из оригинального (PDF) 20 марта 2009 года.  
  8. ^ Elder, Джексон и Liblit 2008 .
  9. ^ Джей Филдс; Шейн Харви; Мартин Фаулер; Кент Бек (2009). Рефакторинг: Ruby Edition . Pearson Education. С. 274–279. ISBN 978-0-321-60350-0.
  10. ^ Херб Саттер; Андрей Александреску (2004). Стандарты программирования C ++: 101 правила, рекомендации и передовой опыт . Pearson Education. ISBN 978-0-13-265442-5. "Пример 4: Одна запись, один выход (" SESE "). Исторически некоторые стандарты кодирования требовали, чтобы каждая функция имела ровно один выход, то есть один оператор возврата. Такое требование устарело в языках, поддерживающих исключения и деструкторы, где функции обычно имеют множество неявных выходов. ")
  11. ^ Дэвид Энтони Уотт; Уильям Финдли (2004). Концепции проектирования языков программирования . Джон Вили и сыновья. С. 215–221. ISBN 978-0-470-85320-7.
  12. ^ Бертран Мейер (2009). Touch of Class: Учимся хорошо программировать с объектами и контрактами . Springer Science & Business Media. п. 189. ISBN. 978-3-540-92144-8.
  13. ^ «PragPub апрель 2012 - Прагматическая защита - Прагматическая книжная полка» . pragprog.com . Архивировано 10 июля 2017 года . Проверено 6 мая 2018 .
  14. ^ «Единый вход, единственный выход, должно ли это быть применимо к объектно-ориентированным языкам? - Блог Питера Ричи MVP» . Архивировано 14 ноября 2012 года . Проверено 15 июля 2014 .
  15. ^ Дэвид Энтони Уотт; Уильям Финдли (2004). Концепции проектирования языков программирования . Джон Вили и сыновья. С. 221–222. ISBN 978-0-470-85320-7.
  16. ^ Кеннет С. Лауден; Кеннет А. Ламберт (2011). Языки программирования: принципы и практика (3-е изд.). Cengage Learning. п. 423. ISBN. 978-1-111-52941-3.
  17. ^ Арвинд Кумар Bansal (2013). Введение в языки программирования . CRC Press. п. 135. ISBN 978-1-4665-6514-2.
  18. ^ Веймер, W & Некула, GC (2008). «Исключительные ситуации и надежность программ» (PDF) . Транзакции ACM по языкам и системам программирования . 30 (2). Архивировано (PDF) из оригинала 23 сентября 2015 года.
  19. ^ Рохит Чандра (2001). Параллельное программирование в OpenMP . Морган Кауфманн. п. 45. ISBN 978-1-55860-671-5.

Источники [ править ]

  • Эдсгер Дейкстра , Заметки о структурном программировании , стр. 6.
  • Бём, К .; Джакопини, Дж. (Май 1966 г.). «Блок-схемы, машины Тьюринга и языки только с двумя правилами формирования» (PDF) . Коммуникации ACM . 9 (5): 366–371. CiteSeerX  10.1.1.119.9119 . DOI : 10.1145 / 355592.365646 . S2CID  10236439 .
  • Дейкстра, Эдсгер В. (март 1968 г.). «Письма в редакцию: перейти к заявлению, признанному вредным» (PDF) . Коммуникации ACM . 11 (3): 147–148. DOI : 10.1145 / 362929.362947 . S2CID  17469809 .
  • Майкл А. Джексон , Принципы разработки программ , Academic Press, Лондон, 1975.
  • О.-Дж. Даль , Э. У. Дейкстра , Структурное программирование К. Хоара , Academic Press, Лондон, 1972. ISBN 0-12-200550-3 . 
    • этот том включает расширенную версию заметок по структурированному программированию , приведенную выше, включая расширенный пример использования структурированного подхода для разработки алгоритма поиска с возвратом для решения проблемы 8 Queens .
    • версия в формате pdf входит в серию книг ACM Classic
    • Обратите внимание, что третья глава этой книги Даля описывает подход, который легко узнать как объектно-ориентированное программирование. Это можно рассматривать как еще один способ «полезно структурировать» программу, чтобы показать ее правильность.
  • Старейшина, Мэтт; Джексон, Стив; Либлит, Бен (октябрь 2008 г.). Code Sandwiches (PDF) (Технический отчет). Университет Висконсина-Мэдисона . 1647, абстракция

Внешние ссылки [ править ]

  • BPStruct - инструмент для структурирования параллельных систем (программ, моделей процессов)
  • Дж. Дарлинтон; М. Ганем; HW To (1993), «Структурированное параллельное программирование», в моделях программирования для параллельных компьютеров. Издательство IEEE Computer Society Press. 1993 : 160–169, CiteSeerX  10.1.1.37.4610