Пробовали такое на нескольких самолётах. Раскручивали, правда, электромоторами. Пилоты жаловались, что сложнее определить момент касания. При раскрутке потоком воздуха есть опасность, что из-за несинхронного вращения колёс самолёт поведёт в сторону на касании. Ну и можно перераскрутить так, что они будут крутиться быстрее, чем нужно. А ещё раскрученные колёса работают как маховики, создавая дополнительный момент при маневрировании на заходе.
Переход всех госструктур на работу исключительно с документами в отечественом формате, открывающимися исключительно в отечественных программах, работающих исключительно под отечественными ОС, в том числе и при госзакупках, продвинул бы импортозамещение гораздо сильнее любых наказаний. </sarcasm maybe?>
Вижу, вы совсем съехали на лозунги. Дальше с вами обсуждать что-то просто неинтересно. Ни одного своего громкого утверждения вы так и не смогли толком обосновать и доказать.
Пардон, а вы сами программировали хоть раз? А с базой данных работали? В одной подпрограмме может быть произвольное количество разных обращений к БД. И это не проблема, это совершенно нормально. А уж когда мы расписываем не отдельную подпрограмму, а макроуровень программы, работающей с БД, то таких связей будет достаточно много. К тому же, БД - это только пример. На её месте может быть, например, документ или другой процесс.
«Автоматически взглядом» - это про что? Про структуру, а не про семантику.
То есть, если я уберу все надписи, то только по внешнему виду вы поймёте, что правильно, а что нет?
Речь идет о структурной и топологической правильности.
Не путайте правильность и соответствие синтаксису. Правильность - это не просто "синтаксически корректно", это "работает правильно". А что касается "структурной правильности", то я вам могу на драконе нарисовать, например, неявный цикл со входом в середину этого цикла. Конечные автоматы (силуэт) ещё и не такие чудеса позволяют.
ДРАКОН - это не фармацевтический препарат, который нужно испытывать на тысячах пациентов.
Как только вы вторгаетесь в область психологии - поздравляю, вы в медицине. И, поскольку речь идёт о человеческом восприятии, вещи достаточно субъективной, вам нужно слепое тестирование. Да, плацебо-контролируемого тут не сделать, но двойное слепое рандомизируемое вполне возможно.
Это инженерное применение давно установленных законов когнитивной науки.
Что такое "когнитивная наука"? Это точная наука или гуманитарная? В любом случае главный критерий в науке - эксперимент. Там, где он невозможен, как минимум должен быть статистический или математический аппарат, анализирующий факты (не домыслы). Пока у вас ничего этого нет - нет и никакой науки.
Требовать от ДРАКОНа новых масштабных исследований - все равно что требовать от создателей самолета заново доказывать закон Бернулли.
Не обязательно. Но создатели самолёта вполне могут сослаться на конкретные законы и подтверждающие эти законы эксперименты и научные работы. Где научные работы в области "когнитивной науки"?
Эта паутина не отвечает на критически важные вопросы: в какой последовательности происходит доступ?
А почему она должна быть какой-то определённой? Когда вы описываете конечный автомат (силуэт), вы ведь не можете заранее предсказать, в какой последовательности будут вызываться состояния этого автомата.
Вы должны создать четко обозначенную икону-вставку (например, «Выполнить запрос к БД»
И? Как она наглядно покажет, к какой именно БД осуществляется запрос и откуда ещё есть запросы к этой БД?
ДРАКОН-методология заставляет вас вынести работу с базой данных в отдельный силуэт
Пардон, каким образом? Обращения к БД вовсе не обязаны быть одинаковыми. В разных ветках они могут выполнять разные действия с БД, но сама то БД будет одной и той же.
То есть дракон изначально не предназначен для показа связей между объектами и/или процессами. Иначе запрет на пересечение линий был бы невозможен. А такие связи это, зачастую, существенная часть в понимании бизнес-логики.
Если у токаря каждый раз получается одна и та же деталь, независимо от того, какой ему в этот раз дали чертёж, то у него, конечно, алгоритм, но этот алгоритм особого смысла не имеет. По правильному алгоритму у него будет получаться деталь, соответствующая чертежу. Так что, для начала надо определиться, что мы понимаем под "нужностью и воспроизводимостью", да и просто под результатом. А так алгоритм может использовать в работе случайные числа, как тот же метод Монте-Карло. При этом результат будет нужный, правильный, но при каждом запуске немного другой.
Синтаксис ДРАКОНА... запрещает любые двусмысленности и неопределенности.
Вот только дьявол в деталях. Внутри икон можно писать что угодно, и вот это что угодно может быть каким угодно двусмысленным, трёхсмысленным, бессмысленным.
Алгоритм должен быть записан так, чтобы его правильность проверялась автоматически, взглядом
Вот только правильность алгоритма - это не только его маршруты. Найдите "автоматически, взглядом" ошибку в абсолютно корректной с точки зрения дракона схеме:
Вот этой
Ошибка
Классическое состояние гонки между двумя конкурентными процессами, монопольно использующими одни и те же ресурсы.
«пересечения и обрывы соединительных линий запрещены», а любая незавершенная логика сразу видна как «висящий хвост», который «кричит о себе»
Нет пересечений - невозможно наглядно показать взаимосвязи процессов, что в бизнес-логике необходимо регулярно. Например, как показать, что несколько веток выбора обращаются к одной и той же базе данных? Текст не предлагать - это не наглядно. Обрывы запрещены? В том же BPMN по правилам все потоки должны заканчиваться символом завершения (жирный кружок). Проверка встроена в редактор и места ошибок подсвечиваются. Так что "висящих хвостов" там быть не может.
BPMN в этой аналогии - это чертеж на птичьем языке, который инженер (аналитик) с трудом интерпретирует для заказчика (бизнеса).
Пардон, если аналитик не может говорить с бизнесом на языке бизнеса, то он плохой аналитик. Если он не может говорить с разработчиком на языке разработчика - он плохой аналитик. Если он не может переводить с одного языка на другой и обратно - он плохой аналитик.
Это - научно обоснованный когнитивный подход
Где можно почитать про научное исследование. Скажем слепое рандомизированное исследование (текстовой записи алгоритма, его же на драконе и его же на BPMN) хотя бы на несколько сотен участников и несколько десятков примеров? Без этого все слова о "научности" - маркетинговый буллшит.
ДРАКОН - это попытка создать гибридный язык, понятный обеим сторонам.
Но это не требуется. Бизнес должен говорить на языке бизнеса. Разработчик - на языке разработчика. Аналитик - на обоих языках сразу. Кстати, BPMN позиционирует себя практически теми же словами, что тут вы приводите для дракона:
BPMN is targeted at a high level for business users and at a lower level for process implementers. The business users should be able to easily read and understand a BPMN business process diagram. The process implementer should be able to adorn a business process diagram with further detail in order to represent the process in a physical implementation. BPMN is targeted at users, vendors and service providers that need to communicate business processes in a standard manner.
на выявление и структурирование знаний
Каким образом? Структурируя информацию? Так это делает любая схема, в любой нотации. Чем тут выделяется именно дракон - непонятно. Заявляемые часто "безошибочность" дракона, его "показ пробелов в логике" - это всё пустые слова, не имеющие под собой никаких доказательств.
Предполагаю, что если вместо дракона взять, например, BPMN, то принципиально ничего в вашем рассказе не поменяется. Основной компонент этого процесса именно аналитик. Он, как переводчик, должен уметь говорить с экспертом на языке бизнеса, а с разработчиком на языке программирования. И это, по определению, будут разные языки, иначе аналитик не был бы нужен, эксперт с разработчиком договорились бы и без него. И если аналитику дракон помогает структурировать информацию, то ради бога, пусть пользуется. Но при этом не стоит утверждать, что BPMN тут работает хуже только потому, что аналитик его не знает. Именно с точки зрения бизнес-процессов BPMN показывает всё гораздо нагляднее дракона.
Сама по себе LLM - это вполне себе алгоритм имитации нейросети, причём вполне детерминированный. Вот в сочетании с обрабатываемыми им данными сложность системы может возрасти многократно, так что человек уже не в состоянии разобраться исходя из чего были получены результаты. Но алгоритм от этого не перестаёт быть алгоритмом.
ДРАКОН же, благодаря своей принудительной простоте, действует как каркас или контрольный список.
Увы, но не действует. \
Пропущенное логическое условие (как "число < 0?") остается очевидным белым пятном на схеме.
Увы, но не остаётся. Например, вы пишете условия для обработки сигналов автомобильного светофора. Добавляете красный, жёлтый, зелёный. Вспоминаете про зелёный мигающий и одновременный красный + жёлтый. А, да, ещё жёлтый мигающий. Ну и неисправный светофор. Можете нарисовать схему и пусть она вам покажет, чего же не хватает в этой схеме.
И чего?
В Японии светофоры используют синий цвет вместо зелёного. Если вы не знаете этого, то дракон вам этот "пробел" не покажет.
Я применяю в процессе описания примерно 5-7 символов и у каждого из этих символов однозначное значение.
Значит и в BPMN вы можете ограничиться теми же 5-7 символами, даже с учётом комбинаторики. Вас никто не заставляет использовать всё.
один и тот же «ромб» может означать и «решение», и «параллельный запуск», и «ошибку».
Ромб не может означать ошибку. Это либо разветвление процесса, либо точка соединения ветвей. При этом шлюз задаёт правила ветвления или соединения. У дракона, например, при соединении ветвей непонятно, ждём ли мы прихода в него всех потоков управления или достаточно одного.
McDonald’s внедрил ИИ для приёма заказов. Он начал заказывать 260 наггетсов. Почему? Потому что в ТЗ не было чёткого правила: «максимум 10 позиций в заказе».
И что? Как дракон позволит добавить в ТЗ этот пункт, если о нём просто никто не подумал. Например, на вашей схеме нет пунктов "Клиент добавляет NULL наггетсов", "Клиент добавляет отрицательное число наггетсов", "Клиент добавляет больше наггетсов, чем есть полуфабрикатов". Почему вы не заложили эти варианты? Вы о них просто не подумали, так? И дракон не помог.
Федеральный закон "О связи" от 07.07.2003 N 126-ФЗ, п. 45.10
Подождите, а если этот ИП, не дай бог, неожиданно умрёт, то весь этот парк вещей через месяц перестанет работать? Bus factor == 1?
Пробовали такое на нескольких самолётах. Раскручивали, правда, электромоторами. Пилоты жаловались, что сложнее определить момент касания.
При раскрутке потоком воздуха есть опасность, что из-за несинхронного вращения колёс самолёт поведёт в сторону на касании. Ну и можно перераскрутить так, что они будут крутиться быстрее, чем нужно.
А ещё раскрученные колёса работают как маховики, создавая дополнительный момент при маневрировании на заходе.
Ведёт коммерческую деятельность? Значит тоже.
Переход всех госструктур на работу исключительно с документами в отечественом формате, открывающимися исключительно в отечественных программах, работающих исключительно под отечественными ОС, в том числе и при госзакупках, продвинул бы импортозамещение гораздо сильнее любых наказаний. </sarcasm maybe?>
Не забудьте предварительно прибить все инстансы хрома в памяти.
Обычно, когда говорят об объёме, то под кубом подразумевают кубический метр, под кубиком - кубический сантиметр.
Вижу, вы совсем съехали на лозунги. Дальше с вами обсуждать что-то просто неинтересно. Ни одного своего громкого утверждения вы так и не смогли толком обосновать и доказать.
Пардон, а вы сами программировали хоть раз? А с базой данных работали? В одной подпрограмме может быть произвольное количество разных обращений к БД. И это не проблема, это совершенно нормально. А уж когда мы расписываем не отдельную подпрограмму, а макроуровень программы, работающей с БД, то таких связей будет достаточно много.
К тому же, БД - это только пример. На её месте может быть, например, документ или другой процесс.
То есть, если я уберу все надписи, то только по внешнему виду вы поймёте, что правильно, а что нет?
Не путайте правильность и соответствие синтаксису. Правильность - это не просто "синтаксически корректно", это "работает правильно". А что касается "структурной правильности", то я вам могу на драконе нарисовать, например, неявный цикл со входом в середину этого цикла. Конечные автоматы (силуэт) ещё и не такие чудеса позволяют.
Как только вы вторгаетесь в область психологии - поздравляю, вы в медицине. И, поскольку речь идёт о человеческом восприятии, вещи достаточно субъективной, вам нужно слепое тестирование. Да, плацебо-контролируемого тут не сделать, но двойное слепое рандомизируемое вполне возможно.
Что такое "когнитивная наука"? Это точная наука или гуманитарная? В любом случае главный критерий в науке - эксперимент. Там, где он невозможен, как минимум должен быть статистический или математический аппарат, анализирующий факты (не домыслы).
Пока у вас ничего этого нет - нет и никакой науки.
Не обязательно. Но создатели самолёта вполне могут сослаться на конкретные законы и подтверждающие эти законы эксперименты и научные работы. Где научные работы в области "когнитивной науки"?
А почему она должна быть какой-то определённой? Когда вы описываете конечный автомат (силуэт), вы ведь не можете заранее предсказать, в какой последовательности будут вызываться состояния этого автомата.
И? Как она наглядно покажет, к какой именно БД осуществляется запрос и откуда ещё есть запросы к этой БД?
Пардон, каким образом? Обращения к БД вовсе не обязаны быть одинаковыми. В разных ветках они могут выполнять разные действия с БД, но сама то БД будет одной и той же.
То есть дракон изначально не предназначен для показа связей между объектами и/или процессами. Иначе запрет на пересечение линий был бы невозможен. А такие связи это, зачастую, существенная часть в понимании бизнес-логики.
Если у токаря каждый раз получается одна и та же деталь, независимо от того, какой ему в этот раз дали чертёж, то у него, конечно, алгоритм, но этот алгоритм особого смысла не имеет.
По правильному алгоритму у него будет получаться деталь, соответствующая чертежу.
Так что, для начала надо определиться, что мы понимаем под "нужностью и воспроизводимостью", да и просто под результатом.
А так алгоритм может использовать в работе случайные числа, как тот же метод Монте-Карло. При этом результат будет нужный, правильный, но при каждом запуске немного другой.
Вот только дьявол в деталях. Внутри икон можно писать что угодно, и вот это что угодно может быть каким угодно двусмысленным, трёхсмысленным, бессмысленным.
Вот только правильность алгоритма - это не только его маршруты. Найдите "автоматически, взглядом" ошибку в абсолютно корректной с точки зрения дракона схеме:
Вот этой
Ошибка
Классическое состояние гонки между двумя конкурентными процессами, монопольно использующими одни и те же ресурсы.
Нет пересечений - невозможно наглядно показать взаимосвязи процессов, что в бизнес-логике необходимо регулярно. Например, как показать, что несколько веток выбора обращаются к одной и той же базе данных? Текст не предлагать - это не наглядно.
Обрывы запрещены? В том же BPMN по правилам все потоки должны заканчиваться символом завершения (жирный кружок). Проверка встроена в редактор и места ошибок подсвечиваются. Так что "висящих хвостов" там быть не может.
Пардон, если аналитик не может говорить с бизнесом на языке бизнеса, то он плохой аналитик. Если он не может говорить с разработчиком на языке разработчика - он плохой аналитик. Если он не может переводить с одного языка на другой и обратно - он плохой аналитик.
Где можно почитать про научное исследование. Скажем слепое рандомизированное исследование (текстовой записи алгоритма, его же на драконе и его же на BPMN) хотя бы на несколько сотен участников и несколько десятков примеров? Без этого все слова о "научности" - маркетинговый буллшит.
Но это не требуется. Бизнес должен говорить на языке бизнеса. Разработчик - на языке разработчика. Аналитик - на обоих языках сразу.
Кстати, BPMN позиционирует себя практически теми же словами, что тут вы приводите для дракона:
Каким образом? Структурируя информацию? Так это делает любая схема, в любой нотации. Чем тут выделяется именно дракон - непонятно.
Заявляемые часто "безошибочность" дракона, его "показ пробелов в логике" - это всё пустые слова, не имеющие под собой никаких доказательств.
Предполагаю, что если вместо дракона взять, например, BPMN, то принципиально ничего в вашем рассказе не поменяется.
Основной компонент этого процесса именно аналитик. Он, как переводчик, должен уметь говорить с экспертом на языке бизнеса, а с разработчиком на языке программирования. И это, по определению, будут разные языки, иначе аналитик не был бы нужен, эксперт с разработчиком договорились бы и без него.
И если аналитику дракон помогает структурировать информацию, то ради бога, пусть пользуется. Но при этом не стоит утверждать, что BPMN тут работает хуже только потому, что аналитик его не знает. Именно с точки зрения бизнес-процессов BPMN показывает всё гораздо нагляднее дракона.
А вы?
Алгоритм - это заданный порядок действий. И LLM работает именно по фиксированному алгоритму, как во время обучения, так и во время работы.
Сама по себе LLM - это вполне себе алгоритм имитации нейросети, причём вполне детерминированный. Вот в сочетании с обрабатываемыми им данными сложность системы может возрасти многократно, так что человек уже не в состоянии разобраться исходя из чего были получены результаты. Но алгоритм от этого не перестаёт быть алгоритмом.
Увы, но не действует. \
Увы, но не остаётся. Например, вы пишете условия для обработки сигналов автомобильного светофора. Добавляете красный, жёлтый, зелёный. Вспоминаете про зелёный мигающий и одновременный красный + жёлтый. А, да, ещё жёлтый мигающий. Ну и неисправный светофор. Можете нарисовать схему и пусть она вам покажет, чего же не хватает в этой схеме.
И чего?
В Японии светофоры используют синий цвет вместо зелёного. Если вы не знаете этого, то дракон вам этот "пробел" не покажет.
Значит и в BPMN вы можете ограничиться теми же 5-7 символами, даже с учётом комбинаторики. Вас никто не заставляет использовать всё.
Ромб не может означать ошибку. Это либо разветвление процесса, либо точка соединения ветвей. При этом шлюз задаёт правила ветвления или соединения. У дракона, например, при соединении ветвей непонятно, ждём ли мы прихода в него всех потоков управления или достаточно одного.
И что? Как дракон позволит добавить в ТЗ этот пункт, если о нём просто никто не подумал. Например, на вашей схеме нет пунктов "Клиент добавляет NULL наггетсов", "Клиент добавляет отрицательное число наггетсов", "Клиент добавляет больше наггетсов, чем есть полуфабрикатов". Почему вы не заложили эти варианты? Вы о них просто не подумали, так? И дракон не помог.