Ещё раз про Use Case 3.0
Use Case 3.0 -- вместо инженерии требований (как выявить требования, а затем их удовлетворить), но без требований
Вокруг меня продолжают обсуждать Use Case 3.0, который вышел в мае 2024 года -- и вот добрался до широкой публики (https://www.ivarjacobson.com/files/use-case_3_ebook.pdf). Добавлю и я свои две копейки, как методолог и онтолог.
Ivar Jacobson и его соавторы книжки по Use Case 3.0 (Ian Spence и Keith de Mendoca) -- интуитивисты и культуртрегеры, "нюхают тренды" и популяризируют SoTA. Но вот с онтологией и контролем типов в их описаниях -- не очень, читать текст без слёз невозможно. Я это проверял: у меня как-то была с Ivar Jacobson и Ian Spence в Москве четырёхчасовая дискуссия по поводу OMG Essence, как раз накануне выхода стандарта, в 2013 году (https://ailev.livejournal.com/1092016.html). Я думаю, что Ивар честно считает, что статический контроль типов помогает не делать ошибок в программах (с учётом всей дискуссии о пользе языков, где такого контроля нет), но для стандартов, учебников и всего остального, связанного с методами -- это не нужно, там работает нейросетка людей, и главное -- "нейролингвистическое программирование", для которого важен общий образ, а не точность типов. Моё представление -- если есть шанс наладить строгий контроль типов, надо это делать, хотя на высоком уровне абстракции сами типы могут быть определены довольно туманно (вот только вчера обсуждал это в чате поддержки моих курсовых материалов, https://t.me/systemsthinking_course/29033). Но разговор и на верхних уровнях абстракции должен по возможности быть в строгих типах: это помогает обнаруживать ошибки, наводить критику, делать коммуникацию точной -- а ошибки помогают убрать время на переделки. Одно дело высказать гипотезу и проверить её, другое дело -- высказать что-то с заведомой ошибкой, затем ошибаться при проверке. В одном случае это полезная работа, в другом -- "переделки", лишняя работа, это неэлегантно, не lean.
При этом да, методология -- это алгоритмика-на-стероидах. Методы описываются алгоритмами, которые работают не только с обработкой данных (преобразования информации), но и обработкой всего чего угодно (преобразования физического мира). Мы тут же приходим, что императивное программирование -- это самый простой, но очень невыразительный способ говорить об алгоритмах, а следовательно -- говорить о методах. Универсальный разговор про обработку (создание и развитие) и данных, и вещей (в том числе и людей, и AI), хотя в случае данных про создание и развитие надо говорить онтологически очень осторожно, "не повторять в домашних условиях". Про всё это подробно рассказано в курсе "Методология", https://aisystant.system-school.ru/lk/#/course/methodology
Этот же ход на упрощение с попыткой задать онтику, но практики/методы с использованием этой онтики рассказывать на естественном языке с иллюстрациями через "последовательности шагов" и без контроля типов, наблюдаю в Use Case 3.0. Заодно там решается ещё и задача ухода от требований так, чтобы требования оставить: по факту весь текст про то, что Use Case 3.0 -- это и есть выражение требований. Практики работы с Use Case -- это по факту методы с требованиями. Это вот прямо не написано, но вполне можно такое вычитать, даже в глоссарном определении, что такое Use Case 3.0 -- A scalable set of agile practices that uses use-cases to capture a set of requirements and drive the incremental development of a system to fulfill them. Практики, чтобы выявить набор требований. Потом оказывается, что никакого "набора требований" там на выходе нет. Хотя и используется в дополнительных понятиях онтики System-Wide Requirements, который (как ни странно) на входе -- причём используется это больше в значении "архитектурные характеристики", хотя можно считать и так, что это вообще все требования, и тогда выяснится, что это тоже результат применения метода Use Case 3.0, где требования выявлены как документированные модели сценариев использования (без спецификации, на каком языке или в каком формате моделирования -- хоть на естественном языке, хоть в каком-нибудь редакторе UML или даже SysML).
А можно ли вообще без требований, а как-то иначе? Например, сразу идти к test cases? Да, конечно, но всё равно онтика того, что вы тестируете (какие-то состояния каких-то объектов после каких-то манипуляций с этими объектами) вам потребуется. Я описывал это пару дней назад в "Use Case, DDD, BDD и их методологический синтез", https://ailev.livejournal.com/1744571.html.
Онтологический дребезг в описании Use Case 3.0
Смотрю на эти 80 страниц глазами методолога и онтолога: сплошной дребезг. Раньше бы я написал большой пост с разбором деталей, но сейчас не буду этого делать, просто дам несколько критических мыслей, а затем поделюсь теми мыслями, которые пришли мне в голову по ходу знакомства с этой версией описания метода выявления требований (ну, или метода описания использования системы -- вычитать можно и так, и сяк. Помним, что требования выражали описание системы на её границе с окружением, описание "чёрного ящика" -- и делались они не сами по себе, а на основании потребностей. Уход от требований -- это уход от деонтики к гипотезам, а также уход от сбора всех вообще требований в большую пачку как убор межмодульных зависимостей, а также уход от "испорченного телефона" с аналитиками. А вот потребности внешних проектных ролей -- они остались, ибо описание поведения целевой системы на внешней её границе нужно не само по себе, а для удовлетворения потребностей внешних проектных ролей. Впрочем, подробней -- курс "Системная инженерия", там про это аж пара подразделов: https://aisystant.system-school.ru/lk/#/course/systems-engineering/2023-05-17/8250 и https://aisystant.system-school.ru/lk/#/course/systems-engineering/2023-05-17/8262).
Этот текст -- заход на синтез (conceptual integration) самых разных идей, которые выжили в самых разных проектах (то же, что делалось при создании Essence: что встретилось во всех 250 проектах, то и важно. Архитектура в 2012-2013 годах не встретилась во всех проектах, значит -- неважно!). Ход на культуру: определены принципы и основные понятия, совместно с Alistair Cockburn (автор книги по сценариям использования, соавтор Agile Manifesto), выпущено четырёхстраничное соглашение (https://alistaircockburn.com/Use%20Case%20Foundation.pdf). Никаких альф, девять принципов. Потом к "существующей культуре" тройка авторов фирмы "Ivar Jacobson International SA" добавляет десятый принцип: "10. A system can be developed in slices where each slice is one or more paths through one of the system’s use cases plus the relevant design, code and tests used to implement and verify them". Вроде как этот пункт вводит слайсы? Они ведь были уже в 2.0?
Нет, ход на то, чтобы use case как предмет практики Use case 3.0 (не запутались? косил косой косой косой -- где метод, где предмет метода) стал полноценной альфой процесса разработки. Дальше говорится, что эту альфу (слово не произносится, а выражается, как "эта практика применима") нужно отслеживать для любой методологии разработки -- и agile, и kanban, и водопад. Да, kanban -- это one piece flow, так и говорится, и это -- методология операционного менеджмента, а не разработки, но это ж мы понимаем, у этих авторов "кресты металлические, кресты католические" по типу не различаются. Для того, чтобы дотянуть использование альфы (то есть отслеживание use case) до самого конца проекта (в agile -- до выпуска релиза), вводится use case realization, как набор рабочих продуктов для слайса (включая проект/design, код и уже реализованные системой flows для слайса). А разработка и все остальные процессы моделируются через activities -- действия/стадии из Essence.
Use Case 3.0 -- это практика, ожидаем использования Essence. Нет, всё это даётся не в полном language стандарта, но только в языке действий/стадий и рабочих продуктов. Альфы в тексте есть, в том числе альфы kernel (даже Requirements), но слово "альфа" аккуратно вычищено! Как определить, что они вычищены, то есть сначала текст был с ними? Очень просто: ищём -- и находим случайно забытые упоминания. Оказывается, Use Case -- это alpha, но упомянуто это ровно один раз на все 80 страниц книги, на странице 45. Ну, и приводятся уже знакомые диаграммы графа состояний альфы use case, наряду с состояниями альфы use case slice. А дальше никаких альф и их состояний, только стадии и состояния рабочих продуктов.
С выражением процессов всё плохо: поскольку use case вроде как все способы использования системы, чтобы какой-то пользователь достиг своих целей, network of flows это the flow of events, flow -- это список всех особых случаев (если alternative) и последовательность шагов (если basic), в глоссарии flow -- это путь по нарративу(!), а ещё есть нарратив (который тоже иногда последовательность шагов, иногда смена состояний), но и requirements -- это что должна делать система (What the software system must do to satisfy the stakeholders). Смотрим glossary на странице 74 и видим, что всё там ещё и не бьётся по типам с определениями, которые приведены в тексте. Метонимия на метонимии: смотрим на событие -- думаем и говорим о flow, смотрим на flow -- думаем и говорим о нарративе, смотрим на нарратив -- думаем о состояниях объектов. Всё вроде про одно и то же, но ввиду полного небрежения типами -- полная каша.
Изо всей этой каши можно взять идею, что альфа (предмет внимания в проекте), выражаемая графом её состояний -- это нарратив, и даже Якобсон приводит ещё один синоним -- история. У него там мутно -- входят ли методы (практики) в этот нарратив, или не входят. В принципе, состояния там даются как результат выполнения метода на уровне сигнатуры, так что входят (ср. "дверь закрыта" как выполнение закрытия каким-то методом и "дверь фиолетовая" как просто описание состояния). Так что берём этот вопрос с альфами как предметами метода и нарративы и истории этих альф (ну, или рабочих продуктов для этих альф) для проработки, пополним синонимические ряды в курсе "Методология".
Эта книжка про Use Case 3.0 -- хороший пример для тренировки в ловле онтологического дребезга. Забавно: ход в Essence на альфы был хорош, и он позволял обсудить не только "стадии/этапы" работ с рабочими продуктами, но и практики/методы с их предметами (альфами). Если выкинуть из текста явное использование этих типов -- получаем онтологическую кашу, где use case даётся через описание шагов процесса (и там глаголы-императивы -- Browse Products, Provide Payment Details), а нарратив -- через совершённые действия, например, с самим Use Case -- Goal Established, Flow Structure Understood), и тут вдруг бах -- и те же alternative flow даются как "что угодно" (invalid card, non-standard amount, receipt required, card stuck, cash left behind).
Надо сразу отмести подозрение, что великий Якобсон теперь может ходить по разным фирмам и предлагать консалтинг: "я вам это всё мутное помогу реализовать на раз-два" -- и там раздавать карточки с отмоделированными по-нормальному практиками/методами (он ведь кратенько описывает разложение метода работы с Use Case, причём уже версию 3.0, но описание ведётся не в полном языке Essence и не очень аккуратно в части типов). Но, скорее всего, это получилось ненамеренно. Просто "сложное описание" (про методы -- это всегда сложно, если не понимаешь, как моделировать эти методы и как следить при этом за типами, чтобы не запутаться) было почищено от лишних понятий "для широкой публики" -- просто убрали упоминания лишних типов. Непонятную Альфу убрали, практики как "способ работы" оставили, а приятные бытовые слова (activity, они же стадии, фазы, этапы, работы -- и для них рабочие продукты) тоже оставили. Примеров, когда методы пытаются представить пошаговыми процедурами -- их тьма. Напомним того же Steve Blank с его startup owner's manual, там то же самое (Клиентоориентированность. CustDev, Lean Startup, Lean Innovation Management, https://ailev.livejournal.com/1740125.html). В принципе, это хорошо -- не пишем названия типов, пишем слова из предметной области. Кому надо, тот и сам поймёт, что там предмет метода (альфа), а что результат этапа (рабочий продукт). Но при этом следим за типами! Если не следить, то результат будет: "вроде всё понятно, но как это сделать для нашего проекта -- непонятно".
Что ещё надо включить в курсы, чтобы наши студенты могли самостоятельно разобраться с подобными работами?
Прежде всего -- мы видим попытку не столько разложения метода, сколько попытку синтеза метода с учётом огромного числа других теорий (хотя бы того же использования типов language Essence из situational method engineering, общие подходы к процессам итеративной разработки в системной и программной инженерии, азы инженерии требований). Так что надо бы включить в наши курсы больше каких-то разъяснений про Theory Integration, Conceptual Unification, Theoretical Consolidation, Unification of Concepts, Holistic Synthesis, Amalgamation of Theories, Unified Theoretical Framework, Integration of Paradigms, Convergence of Theories, Merging of Frameworks, Systematic Integration, Interdisciplinary Synthesis, Conceptual Integration, Synthesizing Paradigms, Coalescence of Theoretical Models, Ontology Merging -- там тысячи имён. И там ходы на методологию с синтезом метода (синтез программ -- до кучи, ага), и сразу там -- expression problem про пополнение числа операций и числа объектов. Авторы Use Case 3.0 явно хотели сделать синтез нескольких методов -- и вообще, системная инженерия как таковая представляет собой хороший пример синтеза самых разных успешных составляющих метода разработки успешных систем. Steve Blank тоже интегрировал в своей стартапной методологии несколько отдельных успешных методов. Наша школьная мета-мета-модель -- тоже пример такого синтеза (говорил об этом в "Программа "Организационное развитие" на пороге 2025").
Ещё надо больше материала про связи моделей в локальных и распределённых представлениях. Увы, тут сначала надо довольно много исследовать, это ж та самая неуловимая neuro-symbolic intelligence, причём и artificial, и natural. Ход на нейролингвистическое программирование именно человечьих мозгов я делал ещё в 2016, "Глубокое лингвистоидное обучение или опять про скрипку Энгельбарта", https://openmeta.livejournal.com/235870.html -- и начинал с примера "великого упрощателя" Donald Trump, который неожиданно для всех победил на свой первый срок, в том числе за счёт весьма убедительных речей, понятных вообще всем. Авторы Use Case 3.0, как и прочие "упрощатели" намеренно переходят на высоких онтологических уровнях на естественный язык вместо формальных конструкций. Не уверен, что Якобсону бы понравилось сравнение с Donald Trump, но в плане обращения к членам команд, которые формализм понимают только в отношении языка программирования, а во всём остальном с типами они что твои выпускники литературного института им.М.Горького -- мне кажется, они похожи. У нас в ШСМ большой опыт, на курсе "Рациональная работа" довольно много программистов-разработчиков, их за язык приходится хватать примерно так же часто, как и любых других людей: чуть поменял контекст, и про типы забыли. Алгоритмика для них -- это только классическое программирование, методология и сопутствующая онтология и семантика -- другой контекст, ни одна привычка контроля типов не срабатывает (да и само понимание, что "бег" и "бегун" разных типов -- оно обычно ново, даёт острые ощущения). В теоретическом плане надо понять, как знаковая семиотика и теоретическая теория понятий, стоящие за машинкой типов, связаны с альтернативным паттернированием мира в терминах суррогатов, важнейшими из которых являются нейросуррогаты. Изречённое дао -- не настоящее дао, в этом вопрос. Нейросуррогаты (суррогаты, включая нейро, см., например, https://docs.sciml.ai/Surrogates/dev/) можно смело начинать учитывать такие LLM (даже не MLLM), при этом я всё больше понимаю аргументы людей, которые пытались говорить про world models или foundation models, а ещё помним про "Заметки по лекции Miles Cranmer "Следующая большая научная теория прячется внутри нейронной сети" " https://ailev.livejournal.com/1723726.html. Так что эти нейросуррогаты точных формул онтик работают в том числе и на на такой аппаратуре, как человечьи мозги. Сегодняшняя эпистемология не ломается, она просто останется говорильней стариков, как и сегодняшняя лингвистика. Рационально будет использовать другие объяснения (как рационально сегодня используют парсеры не на правилах языка, а какие-то совсем другие варианты, на нейросетях). Кроме больших (нейро, распределённые представления с большим числом параметров) физических моделей дальше идут идеи про AI-агентов с необычными обменами знаковой информацией (DroidSpeak как первый звоночек). Идеи про то, что диффузионные сетки - это эволюция, а в эволюции неизбежно возникает какая-то странная семиотика вроде генов/мемов и требуется какая-то минимальная точность в воспроизводимости паттернов (знаки становятся "цифрами", они не аналоговы -- при репликации и обработках ошибка не накапливается). И там ещё куча идей про эволюционные алгоритмы и evolvability семиотических (в локальных представлениях) систем и несемиотических (в распределённых представлениях, representation learning). Тут же идут идеи расширенного эволюционного синтеза на знаниях, а ведь эволюция методов -- это эволюция алгоритмов, эволюция знаний, эволюционная эпистемология, которая тоже сегодня имеет обширную литературу буквально последних двух-трёх лет.
Старым эпистемологам, старым онтологам и старым методологам это всё неведомо. Рок-н-ролл оттуда уйдёт, дальше это будет заседание старичков, всегда на три шага сзади фронтира. Философы пока в обалдении (пардон мой френч), и говорят на уровне термина "AI", не понимая вообще, что такое "AI" и чем LLM отличается от AI-агента, и как работает порождающая модель, и чем она отличается от дискриминативной и где тут болтами прикрутить знакомую им семиотику. При этом плывут, как всегда, обычные понятия. Скажем, "DroidSpeak language - это не язык!" -- да, не язык, который изучал Хомский и прочие лингвисты вчерашнего дня . Я говорю, "понятие языка уже плывёт, и через пару лет это будет уже совсем-совсем язык - ибо все последующие работы будут на эту работу по DroidSpeak ссылаться, а там чётко указано -- язык!". А поняние токена (вместо слогов) буквально вчера обсуждалось, что уступит понятию патча, https://ai.meta.com/research/publications/byte-latent-transformer-patches-scale-better-than-tokens/. Всё, что связано с языком и семиотикой - посыпалось, но слово "язык" устоит, а старое содержание - нет. Нам нельзя уже учить классической семиотике и семантике, надо срочно обновляться. Ничего, прорвёмся и тут. Хотя тут с такой скоростью всё меняется, что мы и сотню студентов не будем успевать выучивать новому поколению знаний.
А ещё надо поисследовать, что там ещё можно найти про нарративы, выражаемые графами состояний предмета методов. Какие там есть ещё синонимы методов и описаний методов (сюжеты, истории и даже сами сценарии, причём иногда это методы, а иногда описания) -- это всё оттуда. Нарративизация как превращение в "последовательность шагов" -- оттуда, см. литературу и разъяснения в "Интеллект-стеке", в частности, в попытках разговора про интеллект-стек как нарративизацию онтики методов мышления, а также в разделе про риторику -- https://www.americanscientist.org/article/the-science-of-narrative, https://www.academia.edu/18784581/Narrative_and_Human_Existence_Ontology_Epistemology_and_Ethics_New_Literary_History_45_1_. Всё это разные варианты рассказа о методе, попытки выразить в тексте как последовательности знаков какого-то языка паттерны поведения, которые ни разу не знаковы -- помним, что все знаки -- это паттерны, но не все паттерны -- знаки (хотя некоторые -- обозначаются знаками, включая сами знаки). Это пересекается с предыдущим пунктом, но для меня это больше про расширение синонимического ряда для описаний методов: можно ли, например, граф состояний альфы назвать историей альфы (в русском тут плохо, ибо дух сразу прошедшего времени, в story такого вроде нет), можно ли его назвать нарративом -- и понимать при этом, что описывать надо не работы, не методы, а объекты и переходы их состояний прежде всего (Вася осознал, что надо купить квасу, Вася оделся, Вася вышел из дома, Вася вернулся домой, Вася сделал заказ доставки, квас ждёт курьера, квас доставлен, квас ожидает в холодильнике, квас выпит, Вася доволен -- дальше можно обсуждать, что там с методами для этих предметов, могут ли быть альтернативы, как планировать ресурсы и отслеживать выполнение этого сценария, или нарратива, или прохождение истории, или отслеживать изменения состояний альфы, или ещё как это всё называть.
* * *
Вот обзорная картинка по предметной области практики Use Case 3.0 (помним, что это всё кликабельно -- в ЖЖ поддерживаются картинки в большом разрешении, надо просто кликнуть в маленькую картинку). Это как раз пример результата онтологического моделирования предметной области бывшей "инженерии требований", у нас студенты делают такое в курсе "Рациональная работа" для своих предметных областей. Две альфы (use case и подальфа use case slice), место в стадиях итеративного процесса разработки ("шеврончики" -- это тип activity, и требования только тут), а также набор понятий (в тексте даются и concept map, но текст следует этим concept map весьма условно). Основные понятия -- это которые есть везде, дополнительные -- это которые используются в документе, но могут встречаться не во всех проектах (вот как не встречалась "архитектура" во всех софтверных проектах в 2012-2013 году, когда велась работа над Essence -- и поэтому её в kernel essence нет).
Вокруг меня продолжают обсуждать Use Case 3.0, который вышел в мае 2024 года -- и вот добрался до широкой публики (https://www.ivarjacobson.com/files/use-case_3_ebook.pdf). Добавлю и я свои две копейки, как методолог и онтолог.
Ivar Jacobson и его соавторы книжки по Use Case 3.0 (Ian Spence и Keith de Mendoca) -- интуитивисты и культуртрегеры, "нюхают тренды" и популяризируют SoTA. Но вот с онтологией и контролем типов в их описаниях -- не очень, читать текст без слёз невозможно. Я это проверял: у меня как-то была с Ivar Jacobson и Ian Spence в Москве четырёхчасовая дискуссия по поводу OMG Essence, как раз накануне выхода стандарта, в 2013 году (https://ailev.livejournal.com/1092016.html). Я думаю, что Ивар честно считает, что статический контроль типов помогает не делать ошибок в программах (с учётом всей дискуссии о пользе языков, где такого контроля нет), но для стандартов, учебников и всего остального, связанного с методами -- это не нужно, там работает нейросетка людей, и главное -- "нейролингвистическое программирование", для которого важен общий образ, а не точность типов. Моё представление -- если есть шанс наладить строгий контроль типов, надо это делать, хотя на высоком уровне абстракции сами типы могут быть определены довольно туманно (вот только вчера обсуждал это в чате поддержки моих курсовых материалов, https://t.me/systemsthinking_course/29033). Но разговор и на верхних уровнях абстракции должен по возможности быть в строгих типах: это помогает обнаруживать ошибки, наводить критику, делать коммуникацию точной -- а ошибки помогают убрать время на переделки. Одно дело высказать гипотезу и проверить её, другое дело -- высказать что-то с заведомой ошибкой, затем ошибаться при проверке. В одном случае это полезная работа, в другом -- "переделки", лишняя работа, это неэлегантно, не lean.
При этом да, методология -- это алгоритмика-на-стероидах. Методы описываются алгоритмами, которые работают не только с обработкой данных (преобразования информации), но и обработкой всего чего угодно (преобразования физического мира). Мы тут же приходим, что императивное программирование -- это самый простой, но очень невыразительный способ говорить об алгоритмах, а следовательно -- говорить о методах. Универсальный разговор про обработку (создание и развитие) и данных, и вещей (в том числе и людей, и AI), хотя в случае данных про создание и развитие надо говорить онтологически очень осторожно, "не повторять в домашних условиях". Про всё это подробно рассказано в курсе "Методология", https://aisystant.system-school.ru/lk/#/course/methodology
Этот же ход на упрощение с попыткой задать онтику, но практики/методы с использованием этой онтики рассказывать на естественном языке с иллюстрациями через "последовательности шагов" и без контроля типов, наблюдаю в Use Case 3.0. Заодно там решается ещё и задача ухода от требований так, чтобы требования оставить: по факту весь текст про то, что Use Case 3.0 -- это и есть выражение требований. Практики работы с Use Case -- это по факту методы с требованиями. Это вот прямо не написано, но вполне можно такое вычитать, даже в глоссарном определении, что такое Use Case 3.0 -- A scalable set of agile practices that uses use-cases to capture a set of requirements and drive the incremental development of a system to fulfill them. Практики, чтобы выявить набор требований. Потом оказывается, что никакого "набора требований" там на выходе нет. Хотя и используется в дополнительных понятиях онтики System-Wide Requirements, который (как ни странно) на входе -- причём используется это больше в значении "архитектурные характеристики", хотя можно считать и так, что это вообще все требования, и тогда выяснится, что это тоже результат применения метода Use Case 3.0, где требования выявлены как документированные модели сценариев использования (без спецификации, на каком языке или в каком формате моделирования -- хоть на естественном языке, хоть в каком-нибудь редакторе UML или даже SysML).
А можно ли вообще без требований, а как-то иначе? Например, сразу идти к test cases? Да, конечно, но всё равно онтика того, что вы тестируете (какие-то состояния каких-то объектов после каких-то манипуляций с этими объектами) вам потребуется. Я описывал это пару дней назад в "Use Case, DDD, BDD и их методологический синтез", https://ailev.livejournal.com/1744571.html.
Онтологический дребезг в описании Use Case 3.0
Смотрю на эти 80 страниц глазами методолога и онтолога: сплошной дребезг. Раньше бы я написал большой пост с разбором деталей, но сейчас не буду этого делать, просто дам несколько критических мыслей, а затем поделюсь теми мыслями, которые пришли мне в голову по ходу знакомства с этой версией описания метода выявления требований (ну, или метода описания использования системы -- вычитать можно и так, и сяк. Помним, что требования выражали описание системы на её границе с окружением, описание "чёрного ящика" -- и делались они не сами по себе, а на основании потребностей. Уход от требований -- это уход от деонтики к гипотезам, а также уход от сбора всех вообще требований в большую пачку как убор межмодульных зависимостей, а также уход от "испорченного телефона" с аналитиками. А вот потребности внешних проектных ролей -- они остались, ибо описание поведения целевой системы на внешней её границе нужно не само по себе, а для удовлетворения потребностей внешних проектных ролей. Впрочем, подробней -- курс "Системная инженерия", там про это аж пара подразделов: https://aisystant.system-school.ru/lk/#/course/systems-engineering/2023-05-17/8250 и https://aisystant.system-school.ru/lk/#/course/systems-engineering/2023-05-17/8262).
Этот текст -- заход на синтез (conceptual integration) самых разных идей, которые выжили в самых разных проектах (то же, что делалось при создании Essence: что встретилось во всех 250 проектах, то и важно. Архитектура в 2012-2013 годах не встретилась во всех проектах, значит -- неважно!). Ход на культуру: определены принципы и основные понятия, совместно с Alistair Cockburn (автор книги по сценариям использования, соавтор Agile Manifesto), выпущено четырёхстраничное соглашение (https://alistaircockburn.com/Use%20Case%20Foundation.pdf). Никаких альф, девять принципов. Потом к "существующей культуре" тройка авторов фирмы "Ivar Jacobson International SA" добавляет десятый принцип: "10. A system can be developed in slices where each slice is one or more paths through one of the system’s use cases plus the relevant design, code and tests used to implement and verify them". Вроде как этот пункт вводит слайсы? Они ведь были уже в 2.0?
Нет, ход на то, чтобы use case как предмет практики Use case 3.0 (не запутались? косил косой косой косой -- где метод, где предмет метода) стал полноценной альфой процесса разработки. Дальше говорится, что эту альфу (слово не произносится, а выражается, как "эта практика применима") нужно отслеживать для любой методологии разработки -- и agile, и kanban, и водопад. Да, kanban -- это one piece flow, так и говорится, и это -- методология операционного менеджмента, а не разработки, но это ж мы понимаем, у этих авторов "кресты металлические, кресты католические" по типу не различаются. Для того, чтобы дотянуть использование альфы (то есть отслеживание use case) до самого конца проекта (в agile -- до выпуска релиза), вводится use case realization, как набор рабочих продуктов для слайса (включая проект/design, код и уже реализованные системой flows для слайса). А разработка и все остальные процессы моделируются через activities -- действия/стадии из Essence.
Use Case 3.0 -- это практика, ожидаем использования Essence. Нет, всё это даётся не в полном language стандарта, но только в языке действий/стадий и рабочих продуктов. Альфы в тексте есть, в том числе альфы kernel (даже Requirements), но слово "альфа" аккуратно вычищено! Как определить, что они вычищены, то есть сначала текст был с ними? Очень просто: ищём -- и находим случайно забытые упоминания. Оказывается, Use Case -- это alpha, но упомянуто это ровно один раз на все 80 страниц книги, на странице 45. Ну, и приводятся уже знакомые диаграммы графа состояний альфы use case, наряду с состояниями альфы use case slice. А дальше никаких альф и их состояний, только стадии и состояния рабочих продуктов.
С выражением процессов всё плохо: поскольку use case вроде как все способы использования системы, чтобы какой-то пользователь достиг своих целей, network of flows это the flow of events, flow -- это список всех особых случаев (если alternative) и последовательность шагов (если basic), в глоссарии flow -- это путь по нарративу(!), а ещё есть нарратив (который тоже иногда последовательность шагов, иногда смена состояний), но и requirements -- это что должна делать система (What the software system must do to satisfy the stakeholders). Смотрим glossary на странице 74 и видим, что всё там ещё и не бьётся по типам с определениями, которые приведены в тексте. Метонимия на метонимии: смотрим на событие -- думаем и говорим о flow, смотрим на flow -- думаем и говорим о нарративе, смотрим на нарратив -- думаем о состояниях объектов. Всё вроде про одно и то же, но ввиду полного небрежения типами -- полная каша.
Изо всей этой каши можно взять идею, что альфа (предмет внимания в проекте), выражаемая графом её состояний -- это нарратив, и даже Якобсон приводит ещё один синоним -- история. У него там мутно -- входят ли методы (практики) в этот нарратив, или не входят. В принципе, состояния там даются как результат выполнения метода на уровне сигнатуры, так что входят (ср. "дверь закрыта" как выполнение закрытия каким-то методом и "дверь фиолетовая" как просто описание состояния). Так что берём этот вопрос с альфами как предметами метода и нарративы и истории этих альф (ну, или рабочих продуктов для этих альф) для проработки, пополним синонимические ряды в курсе "Методология".
Эта книжка про Use Case 3.0 -- хороший пример для тренировки в ловле онтологического дребезга. Забавно: ход в Essence на альфы был хорош, и он позволял обсудить не только "стадии/этапы" работ с рабочими продуктами, но и практики/методы с их предметами (альфами). Если выкинуть из текста явное использование этих типов -- получаем онтологическую кашу, где use case даётся через описание шагов процесса (и там глаголы-императивы -- Browse Products, Provide Payment Details), а нарратив -- через совершённые действия, например, с самим Use Case -- Goal Established, Flow Structure Understood), и тут вдруг бах -- и те же alternative flow даются как "что угодно" (invalid card, non-standard amount, receipt required, card stuck, cash left behind).
Надо сразу отмести подозрение, что великий Якобсон теперь может ходить по разным фирмам и предлагать консалтинг: "я вам это всё мутное помогу реализовать на раз-два" -- и там раздавать карточки с отмоделированными по-нормальному практиками/методами (он ведь кратенько описывает разложение метода работы с Use Case, причём уже версию 3.0, но описание ведётся не в полном языке Essence и не очень аккуратно в части типов). Но, скорее всего, это получилось ненамеренно. Просто "сложное описание" (про методы -- это всегда сложно, если не понимаешь, как моделировать эти методы и как следить при этом за типами, чтобы не запутаться) было почищено от лишних понятий "для широкой публики" -- просто убрали упоминания лишних типов. Непонятную Альфу убрали, практики как "способ работы" оставили, а приятные бытовые слова (activity, они же стадии, фазы, этапы, работы -- и для них рабочие продукты) тоже оставили. Примеров, когда методы пытаются представить пошаговыми процедурами -- их тьма. Напомним того же Steve Blank с его startup owner's manual, там то же самое (Клиентоориентированность. CustDev, Lean Startup, Lean Innovation Management, https://ailev.livejournal.com/1740125.html). В принципе, это хорошо -- не пишем названия типов, пишем слова из предметной области. Кому надо, тот и сам поймёт, что там предмет метода (альфа), а что результат этапа (рабочий продукт). Но при этом следим за типами! Если не следить, то результат будет: "вроде всё понятно, но как это сделать для нашего проекта -- непонятно".
Что ещё надо включить в курсы, чтобы наши студенты могли самостоятельно разобраться с подобными работами?
Прежде всего -- мы видим попытку не столько разложения метода, сколько попытку синтеза метода с учётом огромного числа других теорий (хотя бы того же использования типов language Essence из situational method engineering, общие подходы к процессам итеративной разработки в системной и программной инженерии, азы инженерии требований). Так что надо бы включить в наши курсы больше каких-то разъяснений про Theory Integration, Conceptual Unification, Theoretical Consolidation, Unification of Concepts, Holistic Synthesis, Amalgamation of Theories, Unified Theoretical Framework, Integration of Paradigms, Convergence of Theories, Merging of Frameworks, Systematic Integration, Interdisciplinary Synthesis, Conceptual Integration, Synthesizing Paradigms, Coalescence of Theoretical Models, Ontology Merging -- там тысячи имён. И там ходы на методологию с синтезом метода (синтез программ -- до кучи, ага), и сразу там -- expression problem про пополнение числа операций и числа объектов. Авторы Use Case 3.0 явно хотели сделать синтез нескольких методов -- и вообще, системная инженерия как таковая представляет собой хороший пример синтеза самых разных успешных составляющих метода разработки успешных систем. Steve Blank тоже интегрировал в своей стартапной методологии несколько отдельных успешных методов. Наша школьная мета-мета-модель -- тоже пример такого синтеза (говорил об этом в "Программа "Организационное развитие" на пороге 2025").
Ещё надо больше материала про связи моделей в локальных и распределённых представлениях. Увы, тут сначала надо довольно много исследовать, это ж та самая неуловимая neuro-symbolic intelligence, причём и artificial, и natural. Ход на нейролингвистическое программирование именно человечьих мозгов я делал ещё в 2016, "Глубокое лингвистоидное обучение или опять про скрипку Энгельбарта", https://openmeta.livejournal.com/235870.html -- и начинал с примера "великого упрощателя" Donald Trump, который неожиданно для всех победил на свой первый срок, в том числе за счёт весьма убедительных речей, понятных вообще всем. Авторы Use Case 3.0, как и прочие "упрощатели" намеренно переходят на высоких онтологических уровнях на естественный язык вместо формальных конструкций. Не уверен, что Якобсону бы понравилось сравнение с Donald Trump, но в плане обращения к членам команд, которые формализм понимают только в отношении языка программирования, а во всём остальном с типами они что твои выпускники литературного института им.М.Горького -- мне кажется, они похожи. У нас в ШСМ большой опыт, на курсе "Рациональная работа" довольно много программистов-разработчиков, их за язык приходится хватать примерно так же часто, как и любых других людей: чуть поменял контекст, и про типы забыли. Алгоритмика для них -- это только классическое программирование, методология и сопутствующая онтология и семантика -- другой контекст, ни одна привычка контроля типов не срабатывает (да и само понимание, что "бег" и "бегун" разных типов -- оно обычно ново, даёт острые ощущения). В теоретическом плане надо понять, как знаковая семиотика и теоретическая теория понятий, стоящие за машинкой типов, связаны с альтернативным паттернированием мира в терминах суррогатов, важнейшими из которых являются нейросуррогаты. Изречённое дао -- не настоящее дао, в этом вопрос. Нейросуррогаты (суррогаты, включая нейро, см., например, https://docs.sciml.ai/Surrogates/dev/) можно смело начинать учитывать такие LLM (даже не MLLM), при этом я всё больше понимаю аргументы людей, которые пытались говорить про world models или foundation models, а ещё помним про "Заметки по лекции Miles Cranmer "Следующая большая научная теория прячется внутри нейронной сети" " https://ailev.livejournal.com/1723726.html. Так что эти нейросуррогаты точных формул онтик работают в том числе и на на такой аппаратуре, как человечьи мозги. Сегодняшняя эпистемология не ломается, она просто останется говорильней стариков, как и сегодняшняя лингвистика. Рационально будет использовать другие объяснения (как рационально сегодня используют парсеры не на правилах языка, а какие-то совсем другие варианты, на нейросетях). Кроме больших (нейро, распределённые представления с большим числом параметров) физических моделей дальше идут идеи про AI-агентов с необычными обменами знаковой информацией (DroidSpeak как первый звоночек). Идеи про то, что диффузионные сетки - это эволюция, а в эволюции неизбежно возникает какая-то странная семиотика вроде генов/мемов и требуется какая-то минимальная точность в воспроизводимости паттернов (знаки становятся "цифрами", они не аналоговы -- при репликации и обработках ошибка не накапливается). И там ещё куча идей про эволюционные алгоритмы и evolvability семиотических (в локальных представлениях) систем и несемиотических (в распределённых представлениях, representation learning). Тут же идут идеи расширенного эволюционного синтеза на знаниях, а ведь эволюция методов -- это эволюция алгоритмов, эволюция знаний, эволюционная эпистемология, которая тоже сегодня имеет обширную литературу буквально последних двух-трёх лет.
Старым эпистемологам, старым онтологам и старым методологам это всё неведомо. Рок-н-ролл оттуда уйдёт, дальше это будет заседание старичков, всегда на три шага сзади фронтира. Философы пока в обалдении (пардон мой френч), и говорят на уровне термина "AI", не понимая вообще, что такое "AI" и чем LLM отличается от AI-агента, и как работает порождающая модель, и чем она отличается от дискриминативной и где тут болтами прикрутить знакомую им семиотику. При этом плывут, как всегда, обычные понятия. Скажем, "DroidSpeak language - это не язык!" -- да, не язык, который изучал Хомский и прочие лингвисты вчерашнего дня . Я говорю, "понятие языка уже плывёт, и через пару лет это будет уже совсем-совсем язык - ибо все последующие работы будут на эту работу по DroidSpeak ссылаться, а там чётко указано -- язык!". А поняние токена (вместо слогов) буквально вчера обсуждалось, что уступит понятию патча, https://ai.meta.com/research/publications/byte-latent-transformer-patches-scale-better-than-tokens/. Всё, что связано с языком и семиотикой - посыпалось, но слово "язык" устоит, а старое содержание - нет. Нам нельзя уже учить классической семиотике и семантике, надо срочно обновляться. Ничего, прорвёмся и тут. Хотя тут с такой скоростью всё меняется, что мы и сотню студентов не будем успевать выучивать новому поколению знаний.
А ещё надо поисследовать, что там ещё можно найти про нарративы, выражаемые графами состояний предмета методов. Какие там есть ещё синонимы методов и описаний методов (сюжеты, истории и даже сами сценарии, причём иногда это методы, а иногда описания) -- это всё оттуда. Нарративизация как превращение в "последовательность шагов" -- оттуда, см. литературу и разъяснения в "Интеллект-стеке", в частности, в попытках разговора про интеллект-стек как нарративизацию онтики методов мышления, а также в разделе про риторику -- https://www.americanscientist.org/article/the-science-of-narrative, https://www.academia.edu/18784581/Narrative_and_Human_Existence_Ontology_Epistemology_and_Ethics_New_Literary_History_45_1_. Всё это разные варианты рассказа о методе, попытки выразить в тексте как последовательности знаков какого-то языка паттерны поведения, которые ни разу не знаковы -- помним, что все знаки -- это паттерны, но не все паттерны -- знаки (хотя некоторые -- обозначаются знаками, включая сами знаки). Это пересекается с предыдущим пунктом, но для меня это больше про расширение синонимического ряда для описаний методов: можно ли, например, граф состояний альфы назвать историей альфы (в русском тут плохо, ибо дух сразу прошедшего времени, в story такого вроде нет), можно ли его назвать нарративом -- и понимать при этом, что описывать надо не работы, не методы, а объекты и переходы их состояний прежде всего (Вася осознал, что надо купить квасу, Вася оделся, Вася вышел из дома, Вася вернулся домой, Вася сделал заказ доставки, квас ждёт курьера, квас доставлен, квас ожидает в холодильнике, квас выпит, Вася доволен -- дальше можно обсуждать, что там с методами для этих предметов, могут ли быть альтернативы, как планировать ресурсы и отслеживать выполнение этого сценария, или нарратива, или прохождение истории, или отслеживать изменения состояний альфы, или ещё как это всё называть.
* * *
Вот обзорная картинка по предметной области практики Use Case 3.0 (помним, что это всё кликабельно -- в ЖЖ поддерживаются картинки в большом разрешении, надо просто кликнуть в маленькую картинку). Это как раз пример результата онтологического моделирования предметной области бывшей "инженерии требований", у нас студенты делают такое в курсе "Рациональная работа" для своих предметных областей. Две альфы (use case и подальфа use case slice), место в стадиях итеративного процесса разработки ("шеврончики" -- это тип activity, и требования только тут), а также набор понятий (в тексте даются и concept map, но текст следует этим concept map весьма условно). Основные понятия -- это которые есть везде, дополнительные -- это которые используются в документе, но могут встречаться не во всех проектах (вот как не встречалась "архитектура" во всех софтверных проектах в 2012-2013 году, когда велась работа над Essence -- и поэтому её в kernel essence нет).
