gifts2017

Проектирование (параллельной) обработки данных.

Опубликовал Александр Рытов (Арчибальд) в раздел Программирование - Теория программирования

Если нужно обрабатывать разнородные информационные потоки...

Лет этак 25-30 назад весьма активно обсуждалось/развивалось потоковое программирование – в частности, "японский вызов" и ряд других проектов супервычислителей пятого поколения в той или иной степени предполагали использовать управление потоками данных. Способ потокового управления в его простейшей интерпретации состоит в реагировании на события всего одного вида – готовность блока данных к дальнейшей обработке. Важными принципами становится при этом единственность присваивания – каждая переменная (массив, коллекция, файл) инициализируется в процессе вычислений только один раз – а также отсутствие «побочных эффектов» исполнения операций, которые, как известно, являются источником самых труднообнаруживаемых ошибок в программах. Потоковые программы, в отличие от «обычных» становятся, таким образом, верифицируемыми.

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

Конечно, идея управления потоками данных никуда не исчезла и продолжает активно (и плодотворно) эксплуатироваться, в том числе, разработчиками компьютерного «железа». Накоплен и солидный теоретический багаж. Имеются потоковые языки программирования и их трансляторы/интерпретаторы.

Я же хочу обратить внимание на то, что графические схемы могут успешно применяться при проектировании систем обработки данных (СОД). Например, нам захотелось реализовать проект «Большой брат» - систему всеобъемлющего контроля производственного процесса. На разных участках его работают некие АСУТП, фиксирующие отдельные параметры,  входные и выходные потоки ТМЦ (сырье, продукция, технологические материалы, полуфабрикаты) фиксируются в учетных конфигурациях 1С (ага, вот при чем здесь 1С). Нам требуется оптимизировать производство хотя бы в части минимизации потерь на воровство и разгильдяйство.

Поскольку мы сейчас системные аналитики, будем пользоваться системотехническими принципами. В частности, принципом рекуррентного объяснения, который гласит, что свойства систем данного уровня выводятся из постулируемых свойств элементов – систем непосредственно нижестоящего уровня и связей между ними. На практике это означает, что на первом шаге мы рассматриваем будущую СОД как «черный ящик» с известным набором входных воздействий (данных)  и необходимым набором выходов (отчетов):

                                (Y1, Y2, Y3,...) = F(X1, X2, X3,...)

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

Математическая формализация (построение функционально полного класса корректных преобразований) не очень громоздка – две машинописные странички – но приводить ее здесь я не считаю целесообразным. Ну, разве что в качестве приложения. Отмечу только, что для построения наборов допустимых последовательностей вычислений мне пришлось дополнить область значений логических операторов {Истина, Ложь} значением «Не определено».

Опять трехзначная логика на службе корректности алгоритмов…

На картинке из лекции по потоковым ВС приведены возможные вычислительные модели: а – фон-неймановская; б – потоковая; в – макропотоковая; г – редукционная. У меня описывается декомпозиция по варианту в.

 

Скачать файлы

Наименование Файл Версия Размер
Матаппарат 16
.docx 24,43Kb
09.07.13
16
.docx 24,43Kb Скачать

См. также

Подписаться Добавить вознаграждение
Комментарии
0. Александр Рытов (Арчибальд) 15.11.11 04:54
Если нужно обрабатывать разнородные информационные потоки...

Перейти к публикации

1. Антон Долганин (antonds) 15.11.11 04:54
2. Константин Соболевский (Константин С.) 15.11.11 09:52
Ахренительная штуковина!!!!
3. Александр Рытов (Арчибальд) 15.11.11 09:55
4. Евгений (Djonny) 15.11.11 10:06
(2) "Ахренительная штуковина!!!!"
почему тогда "-" поставил?)
5. Александр Рытов (Арчибальд) 15.11.11 11:19
6. Евгений (Djonny) 15.11.11 11:57
7. MaxDavid (MaxDavid) 15.11.11 14:07
Хотел ответить вчера, но не смог вставить первый комментарий.
К сожалению, мои математические знания слишком малы, чтобы спорить аргументированно, но смысл я оценил. Безусловный плюс.
Смущает то, что применение троичной логики, если я правильно понял, не вытекает ниоткуда, кроме пункта 2 определения схемы счета. ИМХО, если убрать из фигурных скобок третий аргумент - ничего не изменится. Поправьте, если ошибаюсь.
Тем, кто, так же как и я, обнаружит, что основательно подзабыл математику - рекомендую ссылку.
Ну и по поводу оформления - как-то уже непривычно видеть вставку формул картинками - чего я совсем не ожидал - когда уже есть Microsoft Equation в Word'е и Match в OpenOffice.
8. Евгений Левченко (MYRZILKA123) 15.11.11 15:19
9. Александр Рытов (Арчибальд) 16.11.11 08:14
(7) Дело в том, что в данном случае теория следовала практике. В процессе реализации (виртуальной) потоковой машины (интерпретатора граф-программ) оказалось, что при определении возможности запуска очередного модуля (процесса) нужны две проверки: наличия входа (массива, файла) и его заполненности. Конечно же, логику мы использовали двоичную (мы ж на двоичной машине работали). Но реально моделировали троичную. Поэтому она и попала в формальное описание.
"Вставка формул картинками" - это где? Текст чисто в Ворде делался...
10. Александр Рытов (Арчибальд) 16.11.11 10:27
Добавил картинку для понятности...
11. Максим Кузнецов (Makushimo) 26.11.12 09:35
Смутно понимаю что это полезная вещь, для тех кто в теме.
Конретные примеры в студию. Как эту тему использовать в повседневной жизни 1С программиста?
ну вот .. дописать не успел, как забыл, о чем статья-то. Ах. да.. есть такая штука как потоковое программрование. И?
Ни плюс ни минус ставить не буду. т.к тема не раскрыта.
12. Александр Рытов (Арчибальд) 26.11.12 10:14
(11) В повседневной деятельности - никак. В повседневном мышлении - как сигнал "опасайся зашоренности".
13. Михаил Ражиков (tango) 26.11.12 10:22
ага... а вот при чем здесь 1С
?