<?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='\
Можно еще один пример для наглядности. Какой нибудь сферический БП в организации, в вакууме. Допустим кадровая докладная — согласование, регистрация, рассмотрение.
Имеется классическая книга по теме:
Но, по имеющейся информации, методология SADT (IDEF0) не получила почему-то широкого распространения.
А про DFD статью не напишите или про сравнение нотаций? Почему вы используете IDEF0?
И часто ли вы используете иерархические схемы (когда вложение процессов используется)?
(3) Сравнение нотаций семейства IDEF0 не имеет смысла, так как цели их использования различны.
Почти всегда. В общим картину понимают все, заказчиков интересуют детали, читайте декомпозиция.
«Дэвид А. Марка и Клемент МакГоуэн. МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ SADT»
Классическая ?
У кого имеется и откуда взялась?
(4)
По глубине изложения материала вполне может претендовать. Если у Вас есть на примете другая книга под это определение, пожалуйста, предложите.
Из литературы. Я занимался моделированием около 10 лет назад, изучал разные источники. Очень мало было отсылок к SADT. Хотя мне самому эта методология очень нравится — строгость и простота.
(5)
Мне формулировка не нравится. Это не музыка и не художественная литература, поэтому считаю данную формулировка не корректной.
Из литературы. Я занимался моделированием около 10 лет назад, изучал разные источники. Очень мало было отсылок к SADT. Хотя мне самому эта методология очень нравится — строгость и простота.
10 лет назад…
Изучал самые разные источники…
Очень мало было отсылок к SADT….
Предоставьте пожалуйста аналитику и пруфы.
(6) Здесь не научная конференция. Я высказал субъективное мнение. Не настаиваю, чтобы со мной соглашались.
(7) Вы не делайте таких спорных утверждений и никто не будет вас спрашивать о пруфах. Я вас за язык не тянул.
(8)
Вот, например, точка зрения, с доводами об ограниченной применимости SADT:
(9) И что вы этим хотели сказать?
(0) ждем про UML теперь
Очень странный подход к описанию стандарта IDEF0, как уже было написано в одном из комментариев, у стандарта есть другое название SADT — методология структурного анализа и проектирования.
Мягко говоря очень странное утверждение, что при использовании SADT получится не 400 страниц техзадания, а компактное графическое представление.
При использование методологии SADT получится не 400 страниц техзадания, а 500, т.к. методология SADT это не только и не столько графическое представление.
SADT можно сравнить с объектно ориентированным программированием, новички наивно предполагают, что кода получится меньше, а кода получается не меньше а больше.
Даже при линейном программировании многие считают, что функции создают, исключительно чтобы повторно использовать код, а если видят что функция вызывается однократно, искренне негодуют.
Очень странно что в статье нет ничего про особенностью человеческого мышления, в особенности про краткосрочную память, а ведь именно на этом и построена вся методология SADT. 15 умножить на 17 многие ведь смогут в уме, а 15 на 173, уже ошибки пойдут, а 158 на 173 — а в чем проблема операция то ведь одна и та же, умножай да складывай простая ведь задача?»
Отдельно мне понравились комментарий что SADT не прижилась, за унифицированным языком моделирования UML будущее, мне вот интересно сами то пробовали применить RUP на практике? Очень интересно как у вас это получится применить язык созданный для ООП, к среде разработке которая не является ООП.
(12)Правильная ведь мысль была в статье, что вот было 400 страниц, и с этим невозможно работать.
Но примеры в статье мне напомнили сдачу дипломных работ.
У всех простейшие блок-схемы. И зачем эти схемы если у вас всего 4 действия и 6 входных данных?
Смысл то как раз в том, когда на входе 50 входных данных, и 30 действий, вот тогда нужно применять синтез.
Кроме того у всех на дипломной, такой замечательный и линейный процесс, ну как в книжках, из этого блока в этот.
Такого в реальной жизни, в принципе не бывает, всегда есть различные варианты.
Если не изменяет память, в книгах у Вендрова, есть более жизненные примеры, вот там кадр дня (все документы, действия), из него получается очень не маленькая табличка, и самих табличек получается не мало и вот с этим надо уже надо работать, вот и попробуйте туда свой UML прицепить.
(12) Согласен, только Вы смешали посты разных авторов.
Про SADT и UML говорили разные люди. И я не вижу, чтобы кто-то здесь говорил про UML как альтернативу SADT.
(14) Почитал конкретно ту статью, которую вы выложили.
Вкратце, диаграммы потоков данных лучше чем SADT, потому что потому.
Никогда не видел, чтобы DFD где-то применялись, слабо себе представляю практическое применение, разве что как нижний уровень в SADT моделях.
Может, дадите ссылки на какую-нибудь более детальную информацию по DFD.
(15)
Вкратце, диаграммы потоков данных лучше чем SADT, потому что потому.
Не согласен, там есть вполне конкретные тезисы. Например, такие:
SADT-диаграммы значительно менее выразительны и удобны для моделирования систем обработки информации (сравните рис. 9.1 и 9.4). Так, дуги в SADT жестко типизированы (вход, выход, управление, механизм). В то же время применительно к системам обработки информации стирается смысловое различие между входами-выходами, с одной стороны, и управлениями и механизмами, с другой: входы, выходы и управления являются потоками данных и/или управления и правилами их трансформации. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и недвусмысленным.
Более того, в SADT вообще отсутствуют выразительные средства для моделирования особенностей систем обработки информации. DFD с самого начала создавались как средство проектирования информационных систем (тогда как SADT — как средство проектирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).
По крайней мере, если Вы с этим не согласны, здесь есть конкретно чему можно возразить, а не просто «потому что потому». Это книга Г. Калянова «Консалтинг при автоматизации предприятий», у меня есть бумажное издание. Хотя мне самому субъективно ближе SADT, но мне его доводы кажутся весомыми. Вероятно, как Вы сказали, SADT — на верхнем уровне, DFD — на нижнем. И думаю, SADT можно вытащить в ТЗ, заказчик поймет, а вот DFD — больше для внутреннего применения разработчиков.
(15) Вот, выкопал ссылку на начало книги, там до нее трудно добраться 🙂
Упомянутая Вами книга Вендрова мне нравится, но, по моим ощущениям, она больше учебное, чем практическое пособие. Могу ошибаться, спорить не буду.
(17) Спасибо за ссылку на книгу.
У Вендрова есть разные книги, есть и учебные пособия, есть и практика.
(18) Да, видимо, мне как раз учебник тогда попался.
Скажите, пожалуйста, какие инструменты используете для моделирования BPMN и IDEF0?
мне кажется это все уже устарело.
сейчас другой мир уже..
(21) BPMN.IO и ERwin
(22) И каким же требованиям времени она не соответствует
(23) UML нельзя сравнивать с IDEF0
(23)
Коллеги, курите UML нотацию)
А курить-то надо бросать 😉
Тогда, может, и не будем сравнивать тёплое с мягким.
(24) Я говорю о том, что целесообразно использовать объектные методологии проектирования. В качестве аналога IDF0 — use case. На мой взгляд можно более детально описать бизнес — процесс … Есть возможность представить различные отношения между кейсами. Опять же в вариантах использования можно более наглядно декомпозировать конкретный процесс.
Коллеги, не в оправдание, но я просто хочу сказать, что мне более удобно использовать нотацию UML. Если кто — то до сих пор использует структурную методологию для проектирования — почему бы и нет =)
«UML нельзя сравнивать с IDEF0» — согласен. Скорее стоит все таки сравнивать в общем структурный подход и объектный. Цель обоих нотаций — наглядное описание бизнес — процесса, разве нет?
(25)
Николай, я лишь хотел сказать, что для описания бизнес — процесса при разработки (например) программных средств наиболее удобно, с моей точки зрения использовать вместо структурного подхода объектно — ориентированный. В частности я предложил использовать нотацию UML. На мой взгляд у объектного подхода есть все таки преимущества в описании.
(26)
Я полагаю, что диаграмма usecase — это скорее некая альтернатива DFD, чем SADT. И она, как мне представляется, элемент языка разработчиков, но не элемент техзадания, которое должен понимать также и заказчик.
Как Вы полагаете, целесообразно ли включать диаграммы прецедентов (вариантов использования) в ТЗ? Не покажутся ли они заказчику детскими картинками, и, главное, желает ли заказчик знать, что, например, такое «актант» и что такое отношение «расширяет»? Он бизнесмен, эти понятия не его сфера, деловые люди «грузиться» не любят. У заказчика может возникнуть подозрение, что ему морочат голову, а на этапе согласования ТЗ это крайне опасно для исполнителя.
А если показать заказчику диаграмму SADT, то, скорее всего, он больше заинтересуется и поймет. Эта диаграмма очень проста и строга. Вход, Выход, Управление, Механизм — что это такое, человек въезжает сразу, с полоборота, это интуитивно понятные термины. И, как я считаю, вести разговор в контексте схемы SADT с заказчиком будет намного проще и свободнее. Заказчик сможет оценить, правильно ли разработчик понял схемы бизнес-процессов предприятия и внести соответствующие коррективы.
А после согласования ТЗ с использованием SADT можно уже начинать проектирование — с составления диаграммы вариантов использования. А можно перед этим на бумажках нарисовать себе и DFD — если это сделает картину более прозрачной, а потом уже определять usecase’ы. Ну, а от них далее, к концептуальной модели — тут уже начинается «объектная» стадия проектирования…
Кстати, ведь диаграммы вариантов использования — это «дообъектная» стадия проекта, там еще никаких сущностей не выявляется. Только прецеденты. Так что со «структурными» диаграммами их совместить можно 🙂
(28)
Николай, не холивара ради … не везде могу с вами согласится =)
Попробую конкретизировать.
Я полагаю, что диаграмма usecase — это скорее некая альтернатива DFD, чем SADT.
Опять же не соглашусь. В качестве аналога DFD я бы представил диаграмму деятельности (activity diagram).
«Как Вы полагаете, целесообразно ли включать диаграммы прецедентов (вариантов использования) в ТЗ?»
Все зависит от того, знаком — ли заказчик с нотацией. В моей практике бывали случаи, когда от заказчика поступало «ТЗ», где описание было представлено в usecase. Не обязательно представлять сложные отношения между кейсами для поверхностного описания бизнес — процесса.
«А если показать заказчику диаграмму SADT, то, скорее всего, он больше заинтересуется и поймет. Эта диаграмма очень проста и строга. Вход, Выход, Управление, Механизм — что это такое, человек въезжает сразу, с полоборота, это интуитивно понятные термины.»
Знаете, вполне может быть. Та же IDF3 выглядит интуитивно понятно. Хотя я сейчас я редко встречаю практическое применение ….
«Кстати, ведь диаграммы вариантов использования — это «дообъектная» стадия проекта, там еще никаких сущностей не выявляется. «
Не выявляется … не вижу противоречий сказанному=) Сущности обычно выявляются уже к описанию концептуальной модели данных … на тех же диаграммах класса удобней моделировать.
Поймите правильно, не хочется спорить ради спорта. Если есть успешная практика применения структурного подхода, в частности SADT- это хорошо. Меня просто удивило то, что сейчас вообще данную нотацию (если хотите «методологию») вообще вспомнили=) Я с ней последний раз очень давно сталкивался.
(29) Да нет, Иван, я тоже не имею желания развязывать холивар. Я прочитал Ваши возражения и тоже подумаю над ними.
Холивар «объектное — структурное», на мой взгляд, не имеет под собой основания. Я полагаю, эти подходы можно «подружить» — в том смысле, что на верхнем уровне, на этапе согласования ТЗ, может пригодиться структурный подход. Я исхожу из пессимистического варианта — заказчик не знаком с UML, не владеет его понятийным аппаратом. Если владеет — это вообще подарок… Но, если у него экономическое образование, то это ему ни к чему. Т. е. для «непосвященных» считаю более понятными модели SADT.
Поэтому я и сказал «теплое с мягким»: UML и SADT — они о разном, и второе может помогать первому.
А на этапе разработки с SADT можно только сверяться, чтобы сильно не уйти от согласованного с заказчиком бизнес-процесса.
Мне очень нравятся книги Крэга Лармана по UML-разработке. Ну, и классика — книга «трех друзей» на эту тему.
(21) у предшественников хватило ума купить Business Studio. За неимением лучшего в ней и работаем.
Должен сказать, что производит впечатление сырой восьмерки (1с8), но для бизнес- процессов.
Интересно, только у меня картинки не открываются, или у всех так? 😉
Отдельный вид мазохизма — читать статью по IDEF0, без иллюстраций!
(32) Хм… Нашел эту же статью с картинками на Хабре
(32) Да, картинки в статье почему-то перестали грузиться. Раньше нормально было.
(3) сравнение различных нотаций есть в Конспекте лекций по курсу «Автоматизированные информационные системы» на этом сайте
Картинок не видно:((