<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Ну надо же. В 84-86 годах на всяких ведомственных семинарах и конференциях мне доводилось делать доклады по графическому программированию. Не ожидал, что графическое программирование кто-то доведет до ума — и это при том, что в 85, кажется, году ВАК перестала принимать к рассмотрению «лингвистические» диссертации.
+ за ностальгию.
Как-то не верится….
(2) Там наработочки по эргономике приличные. Полезны для упорядочения мыслей заказчика/разработчика. Но вот транслятора/интерпретатора, похоже, нет, либо есть, но для очень экзотической платформы (у военных много эксклюзивных машин было тогда).
Да, там интерпретера нет, (кроме военного) есть только транслятор в Oberon 🙂
Но вообще-то наваять интерпретер сейчас не такая сложная штука для знающих yacc.
Но вот чем больше читаю, тем больше мне кажется что к 1С эта штука применима. Действительно — сейчас в управляемом приложении (8.2) есть компоновка для отчетов и автоформы. Осталось визуализировать всяческие циклы и if ы, что и делается здесь 🙂
И получим… ой, самому страшно мечтать становится.
Но мечтать не вредно, вредно не мечтать!
Циклы-циклами, а запросы как будут визуализированы?
Аля конструктор?
Дык, они уже неплохо визуализированы 🙂 Нафига изобретать велосипед еще раз? Сделать одну из иконок запросом и все… он же линеен по алгоритму.
Владимир, а тебе редактор драконов скачать удалось?
Автор интегрированной среды DRAKON – 1С программист 2-й категории Геннадий Николаевич Тышов 🙂
Очень интересно — почитаю. Спасибо.
Спасибо за ссылку. Мозг поразмять есть чем. 🙂
(5) Визуализировать запросы можно. Я даже придумывал нотацию для описания запросов в 1С. Искал готовую, но не нашел, пришлось придумывать. Помогла один раз при разгребании головоломного запроса. 🙂
Поигрался с редактором. Все ж таки минимально серьезный алгоритм сразу теряется в квадратиках. Наверное, такая штука хороша при преподавании информатики — в плане развития систематического мышления и архитектурных приемов. В исходной предметной области, когда общаются инженеры с алгоритмистами — тоже, наверное, хорошо. Управленческий сценарий написать можно. А учет — вряд ли.
Но и перечисленное весьма обширно.
(11) Не-а, не теряется. Если правильно все делать — разбивать на ветки и использовать свертку процедур, то любой алгоритм остается обозримым.
Но, конечно, экран желательно побольше чем 15 дюймов 🙂
Я тут посмотрел как делаются компилеры на .net — семь экранов кода.
Думаю, попробовать сделать свой дракон-редактор простенький, который бы exe-шник компилил.
Там очень прикольно обходятся некоторые 1С-проблемы. Например — длинные переменные, дающие необозримый код. Присваивание — в две строчки, сверху переменная, снизу выражение.
Использование для длинных переменных алиасов-псевдонимов, чтоб формулы писать.
Добавил прямые ссылки на основную книгу и на дракон-редактор
(12) Был бы хороший ActiveX по рисованию схем, тогда можно было бы прикрутить его в обработке и формировать алгоритмические схемы уже в контексте конфигурации, а отдельный редактор не взлетит 🙂
Не боитесь, что вместо нас начнут бухгалтера дорабатывать конфигрураци? 🙂
(15) ActiveX есть, но они только рисунок выдают, а хочется сразу код 🙂
(16) И пусть. Я лучше учет буду ставить в организациях, это всяко интереснее, чем тупое кодирование глючных алгоритмов. Программированию — высокий уровень! 🙂
Хотя, что боятся, ведь из 1с-ков хорошие бухгалтера получаются ))
(16) Им давали КОБОЛ в свое время. И незаметно было, чтоб кто-то все бросил и программить начал.
(16) Ну, значит КОБОЛ несовершенен. Excelом же они пользуются и вовсю!
(18) Предлагали мне и главбухом, и финдиректором у себя. Влом, однако.
(21) Не. Программировать это ведь не писать код, это ставить процессы, чтоб они потом независимо от тебя работали. Выработка технологий. А кто их исполняет — процессор или люди, это уже вопрос второй.
Все равно уже сейчас написание инструкций и обучение бывает не менее важно, чем само кодирование.
(22)Согласен. Кодирование, скорее, отвлекает от программирования, чем составляет основу.
«Хорошим программистом становится только тот, кто своевременно уходит от пульта» (с) Э.Дейкстра.
(23) Тут в обсуждении на партнерском форуме мысль возникла.
— Хороший программист думает сразу на языке программирования!
— Т.к. скорость думания зависит от совершенства языка (см. хотя бы алгебру до изобретения формул — ужас полный), значит можно реально повысить скорость программирования. В общем-то об этом книга и написана.
(24) Вах, зачем нехорошим программистом меня обозвал? 😉
Я на русском языке думаю. Ежели «Все видит, все понимает, а сказать не может» — это умный собак, а не прогрпммист.
(24) Мысль про «думает сразу на языке программирования» неверна, это давно известно 🙁
Хороший разработчик как раз не должен думать на языке программирования, он должен разрабатывать свои программы с использованием языка программирования.
Например, в 1С нет ООП, но можно придумать обходные пути.
ЗЫ рекомендую почитать книгу Макконелл «Совершенный код» — куча всего полезного.
На 1С мир еще не заканчивается, и есть куча способов обойти несовершенство конкретного языка программирования.
Ну, про «думает на языке» говорил мой оппонент.
(задумался, на каком же языке думаю я? 🙂
Прикол еще и в том, что в общем-то если убрать управляющие конструкции то большинство языков очень похожи.
(17) А что у Вас за ActiveX? Можно на него глянуть?
(28) Я подробно не смотрел, т.к. исходная задача была найти что-то в исходниках, чтоб текст программы или даже код генерить.
Где-то в районе
или
видел бесплатную ActiveX для vision-like диаграмм.
Уважаемые коллеги!
Меня зовут Владимир Паронджанов. Я автор книги «Как улучшить работу ума: Алгоритмы без программистов — это очень просто! М.: Дело, 2001. 360с».
Я также автор статьи в Компьютерре, о которой Вы знаете. Меня очень интересует тема Вашего обсуждения. Если ко мне есть вопросы, я с удовольствием отвечу.
Примерно в 2000 году специалист по 1С Александр Шилин из города Волжский написал материал под названием «Дракон помогает бухгалтеру» и прислал его мне. В нем сравниваются тексты 1С и дракон-схемы для алгоритмов «Работа с документом Приходный кассовый ордер» и «Обработка счета 62». Я решил использовать этот материал при переиздании своей книги и вставил его в одну из глав. Книга еще не опубликована.
Специально для Вас я повесил все это на Народе. Если хотите, можете скачать.
Мой мейл vdp2007@bk.ru
Московский тел (495)331-50-72
Желаю успеха Вашему обсуждению.
По поводу дискуссии Арчибальда и keleg в пунктах 11 и 12.
Предлагаю вашему вниманию
РЕКОМЕНДАЦИИ ПО ИСПОЛЬЗОВАНИЮ СИЛУЭТА
И ПРИМИТИВА
1. Силуэт — главное достоинство языка Дракон. Более того, силуэт — его ЕДИНСТВЕННОЕ достоинство.
2. Примитив не в счет, так как его вообще не следует использовать (почти).
3. Алгоритм (или программу) надо рассматривать как последовательную декомпозицию силуэтов. В том смысле, что каждый силуэт может содержать много вставок, каждая из которых раскрывается как силуэт. Примитивы при этом не используются (совсем или почти совсем).
4. Тем не менее, полностью отказываться от понятия «примитив» не следует по двум причинам.
5. Первая причина — педагогическая. Примитив — это прообраз (зародыш) ветки. Основные понятия и правила Дракона удобно объяснять на самой простой модели. То есть на примитиве. И только после этого переходить к рассказу о силуэте.
6. Вторая причина — необходимость описания «мелких огрызков». Откуда берутся «мелкие огрызки»? В процессе декомпозиции силуэта может случиться (очень редко), что какая-нибудь вставка окажется очень простой, элементарной. Настолько простой, что ее неудобно представлять в виде силуэта. Такую вставку можно назвать «мелким огрызком». Вот в этом (исключительном) случае полезно использовать примитив.
7. Добавим еще одну мысль. Ни в коем случае нельзя представлять программу как систему примитивов. Потому что в этом случае НЕВОЗМОЖНО БЫСТРО УВИДЕТЬ ГЛАЗАМИ, как эти примитивы логически связаны между собой. Чтобы понять эту связь, нужен трудоемкий мыслительный анализ, который требует усилий, отнимает время и снижает производительность труда.
8. Систему примитивов всегда можно превратить в силуэт. При этом каждый примитив превращается в ветку силуэта. (Иногда часть примитивов превращается в ветки силуэта более низкого уровня на лестнице декомпозиции).
9. В заключение повторим еще раз основные рекомендации.
• Алгоритмы и программы следует изображать как силуэты.
• Сложные алгоритмы и программы следует изображать как силуэты, в которых многократно используются иконы «вставка». Последние, в свою очередь, раскрываются как силуэты и т.д.
• Примитивы рекомендуется не использовать совсем или использовать только в крайних случаях.
Посмотрел материал. Интересно. Так и не понял, правда, чем указанное графическое представление отличается от блок-схем. Или блок-схему отсюда берут начало? Но не в этом дело. В сложных программах такое представление требует интеллектуальной, многоуровневой графической среды. Кстати, встречал такую среду, когда немного работал с ЧПУ. Был дорогущий пакет от Siemens, который позволял программировать полный цикл работы со станком именно по указанному принципу. Сперва программировался набор термов и лексем, применительно для описания предметной области и процессов станка. Затем составлялась блоксхема программы. После этого, можно было войти в любой участок блоксхемы и составлять программу, оперируя инженерными понятиями. Это мог делать уже не программист. В принципе, корректировать блоксхему тоже. Не скажу, что пакет был прост в эксплуатации. Описание занимало целый cd.
> Чтобы облегчить работу читателя и сделать алгоритм дружелюбным, разработчик дракон-схемы должен заблаговременно разрезать «длинную кишку» и разбить ее на смысловые части.
//
весь вопрос в том, что создание алгоритма и есть, по сути выделение смыслов, разбиение на процедуры/функции (реализующие эти смыслы)… готовый алгоритм красиво нарисовать — не сильно большая проблема (возмоно что при красивом рисовании смыслы будут упрощены/перетаосваны…)… ничего принципиально итересного не увидел.. тот же подход к проектированию «сверху вниз», который еще на вышке в 80-х годах усваивали… то, что разработана графическая удобная нотация — это да… а что еще???
> При этом разделение проблемы на N смысловых частей реализуется путем разбиения алгоритма на N веток.
…тихий хитрый ход, однако 😉
разделение проблемы на ЭН смысловых частей как выполняется — паралельно, сорри, человек еще мыслить не научился (шизофреники разве), все мышление идет линейно, проблема «пробегается» (прикидывается варинт решения) по линейной неделимой ветке, и потом ее начинаем укрупнять и делить/паралелить на отдельные смысловые цепочки…
..имхо НЕЛЬЗЯ РАЗБИТЬ АЛГОРИТМ НА ЭН ВЕТОК. это разбиение на ЭН веток применяется к уже ГОТОВОМУ АЛГОРИТМУ (а не рождаются ветки в процессе разработки алгоритма) — только сначала этот алгоритм нариован ЛИНЕЙНО, «В КРУПНУЮ КЛЕТКУ», а дальше — разворачивай алгоритм до нужной степени детализации сверху-вниз — вычленяй отдельные смыслы — закидывай их в отдельные блоки/векти и т.д.
…
не втыкаю…
простое соображение: так сложилось, что для нас привычнее читать/воспринимать слева-направо и сверху-вниз. Дракон предлагает перевернуть сног на голову: читать сверху-вниз и слева-направо. Возьмем средней величины алгоритм, развернем его в Дракон-нотацию (причем не сильно подробно!) — количество веток будет — МНОГО! притом, что в самой ветке — примитивов не так уж и много… получается гораздо выгоднее располагать ветки горизонтально! а не вертикально — возьмите тот же учетный алгоритм 1ски — да это сполшные если-то-иначе (ветки) и повестьте их как гирлянды в дракон-нотации — будут висет как серпантин и мешаться друг-другу……
хотя, конечно, может я и не в теме…
> Чтобы алгоритм был понятным, он должен быть стройным, красивым, упорядоченным, то есть эргономичным.
— опочки.. много чего намешано, без обоснования…
рассмотрим классическую задачу — «перключателя», требуется значение «флажка» перключать между крайними значениями (0,1/1,2) — типичная 1совская задача с пометками; для набора флажков 1 и 2, самое красивое решение: ф=3-ф; — оно стройное! красивое! и еще визуально упорядоченное! (не в пример конструкциям если). А вот понятен ли с ходу данный кусочек алгоритма…???
> До сих пор мы пользовались правилом «Чем правее, тем хуже». Однако здесь оно не имеет смысла. Поэтому на рис. 20 выбрано другое правило «Чем правее, тем больше скорость ракеты».
— предлагается на этапе разработки алгоритма выбрать правило некой оценки «сложности/красоты» алгоритма… а неизвестно, что взять за такой критерний!!! вот неизвестно с ходу — и все! сложность/красота алгоритма определяется желаемой конечной целью и способом ее достижения… зачастую алгоритм строится для получения конечного решения, а не для получения красивого решения (известная трилемма «дешево, качественно, быстро»)
> Правило хорошей хозяйки. Если постараться, порядок всегда можно навести.
Именно! даже штатные блок-схемы при правильной их отрисовке и выбора нужной стпени детализации будут понятны и прозрачны ничуть не менее чем Дракон-нотация…
из всего этого пока что какой можно сделать вывод? да как обычно: перед тем как что-то начать делать — спланируй и нарисуй, причем желательно — понятно не только для себя, но и для «соседа». Что предлагает Дракон — вполне определенную нотацию (набор правил), позволяющую «рисовать» понятные алгоритмы (на начальном этапе)… — чем это отличается от того, что мы знали раньше — да ничем…
> считаются вредными и категорически запрещены.
..масло масленное, типа как «немножко беременна». Т.е. что предлагает Дракон — он вдалбливает в меня мысль «ДАЖЕ НЕ ДУМАЙ О ТОМ, ЧТОБЫ НАРУШИТЬ ПРАВИЛО» (в противовес тому, что в иных «местах», допустимо такое: «если данное решение эффективно, то для его реализации можно пренебречь правилами) — вот и все… за счет уменьшения количества допустимых действий повышается «эффективность» алгоритма, заключающаяся в его визуальной понятливости для его быстрой оценки. — Это есть премущество? в каких-то местах (и их наверное подавляющее большинстов) — да (это как наборы очень коротких инструкций процессора — для реализации сложного оператора не изобретают сложный и дорогой автомобиль, а сажают на велосипед кучу маленьких гномиков)
> Таким образом, пример на рис. 24 подтверждает справедливость теоремы 21.
..очень опасное заявление.
рассмотрим теорему (типа ;-): для любых целых последовательных идущих друг за другом пятерки чисел справедливо равенство
a*a+b*b+c*c = d*d + e*e
..
например:
10*10+11*11+12*12 = 13*13+14*14
подтверждает ли данный пример справедливость теоремы — фигушки! (а по автору — подтверждает 😉 мало того — на числовой оси такая пятерка чисел — ЕДИНСТВЕННАЯ! сумма, кстати, = 365 (дней в году — ни на какие мысли не наводит?)
Например: у меня есть процедура, выполняющая некие действия.
и у меня есть потребность выполнить нескольо иные действия, очень похожие на исходные. Из типологии Дракона мне следует «нарисовать» две разные ветки, ибо смысл _немного_ разный? или все-таки усложнить исходную ветку, реализовав требуемый мне функционал за счет добавления в исходную ветку несколько «если»….? где он, баланс…?
ну и сама оболочка Дракон (по ссылкам) слабовата все-таки.. при выходе задается вопрос «сохранить — да или нет» и отсутсвует такая часто требуемая опция как отказаться от выхода!!! и продолжить работу!!!! видать Дракон проектировали не на Драконе… (а вот я когда писал диплом — транслятор отлаживал на самом себе — ккак снежный ком шло — быстро и эффективно)…
Хотя если применить предложенный Дракон-путь, то тут достаточно эффектно могут получиться конструкторы нужных инструментов/результатов»… некое ООП…
Спасибо, Че, за множество идей и комментариев.
Автор (Спасибо, Владимир! Я очень рад, что правильно понял Вас и мои выкладки совпали с вашими 🙂 очень правильно сказал, что силуэт это главное и единственное преимущество Дракона перед любой другой нотацией — текстовой или графической. А что главное в силуэте? Даже не ветки, они только иллюстрация принципа двумерности кода.
Любые сегодняшние блок-схемы это все равно одномерные структуры, параллельно-одномерность ведь тоже одномерность.
Создатель Дракона же «включил» в код двумерность изначально.
Возможно, это сделано не идеально. Но это ж не догма, это руководство к тому, чтобу думать и делать самому.
Дракон — первая цельная и полная система двумерного представления кода программы. И это, как минимум, ОЧЕНЬ интересно 🙂
(32) Принципиально не отличается. Добавлен набор эргомомиеских правил для повышения наглядности = снижения вероятности ошибок.
(34) В корне не согласен, что всякая задача изначально линейна (последовательна). Диаграммы Ганта — яркий пример «крупноблочных» параллельных задач. Примерно так: мы хотим получить результат (набор данных) А. Он зависит от данных Б, В, Г , т.е. А=F(Б,В,Г). Ниоткуда не следует, что мы должны получать аргументы последовательно, если конечно нет зависимости, скажем, В=G(Б,Г). Как только готовы исходные данные для блока (функции), мы можем запускать процесс, вычисляющий эту функцию. Процесс завершает свою работу прерыванием, сигнализирующим о готовности данных.
Программируем (мыслим) мы, конечно, последовательно, т.к. имеем всего один процессор. Система прерываний, однако, существует — это всякому известно — так что налицо квазипараллелизм мышления.
+46 Конечно, способ решения задачи «цель -> способ» не очень характерен для учетных задач. Там «событие -> представление события» в основном используется. Исключение составляет, пожалуй, алгоритм закрытия периода — существенно ветвящийся.
(47) А как пример автора из приведенной главы? Конечно, он несколько устарел с точки зрения бухгалтерии (НП давно уже нет) но как принцип?
(48)Примеры красивые. И, наверное бухгалтеру понятны => полезны. Однако я бы рассматривал их скорее как иллюстрацию к комменту Че (45)
(34) Che Burashka пишет:
«..имхо НЕЛЬЗЯ РАЗБИТЬ АЛГОРИТМ НА ЭН ВЕТОК. это разбиение на ЭН веток применяется к уже ГОТОВОМУ АЛГОРИТМУ (а не рождаются ветки в процессе разработки алгоритма)»
Ответ. Вы не совсем правы. Алгоритм (а если есть поддержка, то и программа) разрабатывется в процессе работы с дракон-редактором. Ветки рождаются в процессе разработки алгоритма. Допустим, Вы нарисовали алгоритма из 7 веток. Посмотрели — не понравилось (или увидели ошибку). Что делать?
Ответ ясен — исправлять, добавлять новые элементы, убирать старые, менять в них надписи и т.д. Одним словом, надо думать и работать.
В итоге число веток в вашем алгоритме может измениться. В конце работы их будет не 7, а 9 или 10 или еще что-нибудь. А может быть, их будет 6, потому что В сделали вставку (вызов процедуры, а в этой процедуре, в свою очередь, вы сделали (примерно таким же способом 8 веток.
(50) конечно же, согласен. Вопрос упирается в технологию работы и проектирования. Я очень сомневаюсь, что СРАЗУ при наброске дракон-алгоритма непростой задачи будет рождено 7-15 веток.. скорее всего, либо сначала будет глобальный примитив, или 2-3 укрупненные ветки…
Вообще, мне конечно понравилось, думаю взять на вооружение.
Было бы очень интересно посмотреть ролик разработки реального какого-нибудь (или учебного примера) поразвесистей размером — наблюдение за живой работой зачастую дает возможность оценить перспективность предлагаемого решения (Дракона как сути) гораздо быстрее и правильнее, чем чтение кучи книжек…
По-моему, кто-то сказал, что дракон не поддерживает параллельные процессы.
Это не так. Дракон ПОДДЕРЖИВАЕТ параллельные процессы. См. «Как улучшить…» , стр. 171-173 (см. также ссылки на рисунки).
Желаю удачи вашей дискуссии.
(52)НЕ поддерживает — не говорилось. Поддерживает — да, но не ориентирован на них. Или точнее: ориентирован на вычисления, управляемые командами. А для создания истинно параллельных вычислительных систем/алгоритмов характерна архитектура, при которой вычисления управляются данными. Сидит супервизор и обслуживает очередь (толпу) процессов и очередь (толпу) процессоров.
Читаю книжку описания языка.
Глава 3. Циклы
Рис.69 Пример цикла «пока» — напанятна!!!
в примере: 3 вертикальные линии, 4 излома.
а если примитивы цикла насадить на левый шампур (поменяв да-нет местами) — будет 2 вертикали и 2 излома — почему не так???
ага.. вроде дотумкал…
Жалко, что ветка заглохла… Исходный форум по Дракону — взял «на карандаш»…
Я тут готовлю потихоньку большую статью про 1С в свете Oslo и Дракона.
Есть интересные мысли
(57) Где бы почитать про эту «Oslo»?
(58) Гугл вам в руки по словам Microsoft Oslo
(57)Ждем-с
(52) (56) (57) (60)
Лучше бы конечно ветка в форуме была… Комментарии сложно отслеживать.
Ну да ладно. Оживлю немного дискуссию. 🙂
Долго изучал Дракон, пытаясь найти преимущества, по сравнению с классическими блок-схемами. К сожалению, больше нашел недостатков. И с удовольствием бы подискутировал на эту тему с господином Паронджановым.
По многим пунктам согласен с Сhe Burashka, и повторяться не вижу смысла.
Главное, с чем я никак не могу смириться — это отход от классических «замыкающихся» конструкций. Я имею в виду правило, что любой цикл или ветвление должно иметь один вход и один выход — соответственно, внизу схемы ветки снова должны сходиться в одной точке.
|
-<>-
| |
| |
——
|
Без этого правила схемы превращаются в мешанину с непредсказуемыми переходами (GOTO). Соответственно, ухудшается их читабельность и повышается вероятность ошибок.
Без этого правила схемы становятся немасштабируемыми, т. е. нельзя «свернуть» или вынести в отдельную функцию цикл или ветвление. Соответственно, усложняется процесс оптимизации алгоритма при помощи укрупнения блоков и растет количество ошибок при необходимости «выкусывания» незамыкающихся блоков.
Наконец, без этого правила автоматический перевод дракон-схем в программу на языке высокого уровня (в т. ч. 1С) становится достаточно сложной задачей.
Ну, и что еще поразило — это Дракон-редактор. И поразило не в лучшем значении этого слова. Редактор должен быть удобным и мощным, тогда дракон-схемы могли бы получить большее распространение, хотя бы на концептуальном уровне. К сожалению, автор программы похоже никогда не видел графических редакторов и не знаком с современным программным обеспечением, иначе, я не знаю, чем объяснить такой самобытный пользовательский интерфейс.
Попробую еще раз изобразить рисунок… 🙂
Показать полностью
Кроме того, в Драконе не хватает формализованного представления данных.
Данные — это неотъемлемая часть алгоритмом, а иногда и алогритмообразующая, как заметил Арчибальд. Без описания данных дракон-схемы будут иметь чисто академическое применение. Этим же страдают и классические блок-схемы.
Вот, если придумать грамотную нотацию описания данных: простую, масштабируемую, аналитичную… и удачно вплетающуюся в схему алгоритма… То в паре с ней Дракон-нотация (или даже обычные блок-схемы) могли бы приобрести практическое значение.
(63) Я тоже, когда закапываюсь на тему 1С и Дракона сразу упираюсь в данные — для 1С они вполне алгоритмообразующи.
Минимально необходимой, возможно, может быть обычная реляционная схема данных (типа используемой в Access).
Но в любом случае трудно представить себе схему данных неортогональной схеме алгоритма, очень уж по-разному они устроены.
Хотя… возьмем схему проведения документа 1С. Реквизиты документа, взаимодействуя друг с другом (иногда довольно сложным образом) пишутся в регистр.
Схема тут просто просится! На входе реквизит(ы) документа, на выходе реквизит(ы) регистра, схема показывает их взаимодействие, можно проследить для каждого откуда он берется.
Почти как в стековой машине — есть начальное состояние (значение реквизита), есть операции над ним и результат — тоже состояние.
(61) Современные языки все же очень отошли от классической Виртовской схемы «один вход — один выход». return, break, continue — суть упорядоченные goto. А ведь есть еще и exception…
(63, 64) Думается, для сложной программной системы следует использовать два типа графов.
Дракон-схема уместна при реализации «черного ящика», полученного при проектировании системы «от данных», т.е. модуля, реализующего получение набора выходных данных из набора входных.
При самом проектировании выделяются этапы преобразований входного (для системы) набора данных в выходной с выделением промежуточных наборов данных. Здесь может появиться параллелизм, а в целом граф будет подобен графу (диаграмме) Ганта. Событие — это готовность набора выходных данных модуля, т.е. завершение исполнения Дракон-схемы. Кстати, реализация «параллельного исполнения» графа Ганта алгоритмически несложна.
(65) В том-то и дело, что при варианте с «замкнутыми» ветками операторы return, break, continue можно изображать одним элементом, и без(!) всяких стрелок.
Потому что границы циклов и процедур легко обозреваются глазами и видно, куда перейдет управление.
(64) в свое время медитировал над нотацией, интуитивно понятной как пользователю, так программисту (я про проведение документов в 1С). Тем более, что поток данных в конфигурациях 1С строится строится по данным документа, т.е. в регистры информация попадает из документа + алгоритмические преобразования и доп. источники. Вот эту то связь и хотелось зафиксировать, чтобы на уровне между алгоритмами и функицианально-прикладном фиксировать логику работы систем (особенно когда работаешь с большими конфигурациями типа УПП 8.1, и комплексная конфигурация 7.7). Закончилось все шаблонными таблицами excel + были наброски системы проектирования бизнес-процессов на структуру данных тиражного решения (на 8-ке). А дальше все заглохло — проект зачах.
А вообще, задача визуализации/автоматизации процессов программирования всегда будет актуальной, особенно для людей, которые хорошо воспринимают графику (а визуалов думается большинство). Особенно это важно, когда нужно «перекинуть» мостик от проектирования к собственно адаптации/разработке решения на 1С.
Ссылки на темы: язык Дракон и интегрированная среда ИС Дракон.
Паронджанов В.Д. Учись писать, читать и понимать алгоритмы. 2012г. В продаже.
Геннадий Тышов.
Ефанов С.Д. сайт Описание практики проектирования и программирования микроконтроллерных устройств в ИС Дракон. Имеется 4 видео фильма. Описание дано по состоянию ИС Дракон на январь 2012г.
ИС позволяет выполнять проектирование алгоритмов и выполнять программирование на ряде языков, в т.ч. на 1С.
Mixail Заголовок сообщения: Re: Как алгоритмизировать клиентские задачи для 1С ?
Проектирование АРМ кассира.
С уважением,
Геннадий Тышов.
Выпуск ИС Дракон от 02.12.2012
Возможно последний в 2012 году — году Дракона.
Перечень выпусков
Прошу сообщать Ваши отзывы, замечания и предложения.
Если охота поиграться в «программирование без программирования» — то рекомендую попробовать HiAsm… Идея там довольно классная. Хотя к 1С отношения не имеет…
(73)
HiAsm то же самое программирование- for, ifelse. Только совершенно ненаглядное. В тексте гораздо проще ориентироваться, чем в HiAsm.
Дракон предлагает другой подход. Мы видим, что делает программа на человеческом языке. Интересует реализация, тогда смотрим код.
Плюс правила построения блок-схемы. Которые делают ее простой и наглядной.
В HiAsm в первом же примере мешанина из стрелок и блоков.
(10) Интересно было бы посмотреть… Может сохранилась? Иногда очень хочется иметь что-то типа того..
(75) В голове точно есть. В виде документа — надо искать. Спасибо, что напомнили. Возможно, опубликую как-нибудь. 🙂