В статье упомянуты связи, но пока не особо полно раскрыта их суть. Автор пишет, что статья ещё в процессе написания.
Триплеты из статьи по сути позволяют записывать связи из Методологии модель систем. В методологии Модель систем я предлагаю ссылаться на конкретные системы. Хотел в выходные выложить примитивную версию на django+typescript по описанию систем. В ней связи в соответствии с методологией это (система source, система target, система transfert). Если получится, то сегодня выложу на github и скину ссылку.
Пытаясь разобраться с вашим вопросом пришел к новому выводу.
Модель систем в определенной степени ориентируется на связи. Все компоненты в ней системы, но Связям уделяется особое внимание.
В модели систем методологически введен принцип первичности связей. Это не утверждение, что реальность есть совокупность связей, а предложение, что давайте анализировать реальность через совокупность связей.
А из первичности связей вытекает вывод, что проектирование, анализ нужно начинать с определения связей. Прежде всего со связей с внешней системой.
Ранее предложенный подход также можно использовать и он больше похож на ООП.
Модель систем предлагает начинать с определения внешних связей, затем определять элементы системы и их связи. По сути это связно-ориентированный подход программирования через потоки. Но модель систем не ограничена им и позволяет соединять ООП и связно-ориентированный подход в гибридный подход.
Постараюсь в ближайшее время представить выжимку из диалога с deepseek относительно связи модели систем с гибридными подходами программирования.
От меня благодарность за вопросы, которые расширяют мое собственной понимание ширины сформированной абстракции Модель систем.
И далее вы снова уточняет потребности смежных систем, над систем (пользователей, производителей датчиков и т.д.). Уточняем цели моделируемой системы и рекурсивно ее переделываем. А затем на основании новой версии системы создаём код.
Давайте попробуем решить вашу задачу на примере создания программы для управления роботом с использованием Deepseek.
Скопируй всю методологию из статьи и вставим в deepseek. И попросим его для примера:
С помощью модели систем выше давай спроектируем программу для управления игрушкой роботом. Для описания системы используй текстовое описание системы из методологии. Опиши верхнеуровневые элементы программы затем опиши каждый элемент как систему. Постарайся максимально подробно написать все элементы и их описание.
Получим следующее:
Скрытый текст
Отличный вызов! Давайте спроектируем программу для управления игрушечным роботом, используя Модель систем как методологию.
Мы построим иерархическую модель, где сначала определим корневую систему (программу в целом), а затем развернем каждый её элемент как отдельную систему с собственными целями, потребностями и связями.
Корневая система: Программа управления роботом
System(
name = "Программа управления игрушечным роботом",
description = "Абстрактная модель программного обеспечения, которое обеспечивает автономное или управляемое поведение игрушечного робота в ответ на команды пользователя и данные с сенсоров.",
goals = [
Goal(description = "Предоставить пользователю интерфейс для управления роботом",
source = "Пользователь",
metrics = "Задержка ответа на команду < 100 мс"),
Goal(description = "Обеспечить движение робота в пространстве",
source = "Пользователь / Автономная логика",
metrics = "Точность выполнения команды движения 95%"),
Goal(description = "Предоставить данные с сенсоров в понятном виде",
source = "Пользователь",
metrics = "Частота обновления данных 10 Гц"),
Goal(description = "Поддерживать энергоэффективность",
source = "Аккумуляторная система робота",
metrics = "Время работы от батареи ≥ 2 часов")
],
needs = [
Need(description = "Четкие команды от пользователя",
required = "Аппаратный или голосовой интерфейс",
metrics = "Распознавание команды с точностью > 90%"),
Need(description = "Стабильное электропитание",
required = "Аккумулятор",
metrics = "Напряжение 3.3В ±5%"),
Need(description = "Обратная связь от моторов и сенсоров",
required = "ШИМ-сигналы, I2C/SPI шины",
metrics = "Частота опроса ≥ 50 Гц"),
Need(description = "Возможность обновления прошивки",
required = "USB или OTA канал",
metrics = "Успешное обновление в 99% случаев")
],
elements = [
System(name = "Модуль ввода команд"),
System(name = "Движок поведения"),
System(name = "Драйверы исполнительных механизмов"),
System(name = "Модуль сенсоров и восприятия"),
System(name = "Монитор ресурсов"),
System(name = "Сервис телеметрии и логирования")
],
connections = [
Connection(source = "Модуль ввода команд", target = "Движок поведения",
transfer = "Парс-объект команды"),
Connection(source = "Модуль сенсоров", target = "Движок поведения",
transfer = "Матрица препятствий, уровень заряда"),
Connection(source = "Движок поведения", target = "Драйверы",
transfer = "Целевые скорости для моторов"),
Connection(source = "Монитор ресурсов", target = "Движок поведения",
transfer = "Сигнал ограничения мощности"),
Connection(source = "Движок поведения", target = "Сервис телеметрии",
transfer = "Журнал состояний и событий")
]
)
Декомпозиция элементов как отдельных систем
2.1. Модуль ввода команд
System(
name = "Модуль ввода команд",
description = "Отвечает за прием, распознавание и валидацию команд от пользователя или внешней системы.",
goals = [
Goal(description = "Принять команду из любого доступного канала (BLE, Wi-Fi, кнопка)",
source = "Пользователь", metrics = "Время сканирования каналов 10 мс"),
Goal(description = "Преобразовать сырой сигнал во внутреннее представление команды",
source = "Движок поведения", metrics = "Тип команды (движение/звук/свет)"),
Goal(description = "Отфильтровать недопустимые или опасные команды",
source = "Система безопасности", metrics = "Количество отклоненных команд/час")
],
needs = [
Need(description = "Доступ к аппаратным интерфейсам ввода",
required = "Драйверы BLE, GPIO, ADC", metrics = "IRQ latency < 1 мс"),
Need(description = "Словарь допустимых команд",
required = "Конфигурационный файл", metrics = "Размер словаря 20-50 команд"),
Need(description = "Таймаут на ожидание команды",
required = "Системный таймер", metrics = "Таймаут 5 сек")
],
elements = [
System(name = "Сканер каналов ввода"),
System(name = "Парсер команд (токенизатор)"),
System(name = "Валидатор безопасности"),
System(name = "Буфер команд с приоритетами")
],
connections = [
Connection(source = "Сканер", target = "Парсер", transfer = "Сырая строка/байт-код"),
Connection(source = "Парсер", target = "Валидатор", transfer = "Структурированная команда"),
Connection(source = "Валидатор", target = "Буфер", transfer = "Валидная команда с приоритетом"),
Connection(source = "Буфер", target = "Движок поведения", transfer = "Команда на исполнение")
]
)
2.2. Движок поведения
System(
name = "Движок поведения",
description = "Центральный координатор. Решает, что делать дальше на основе команды, текущего состояния и сенсорных данных.",
goals = [
Goal(description = "Выполнить поступившую команду с учетом ограничений",
source = "Пользователь", metrics = "Время реакции < 200 мс"),
Goal(description = "Предотвратить столкновения",
source = "Система безопасности", metrics = "0 столкновений за сеанс"),
Goal(description = "Переключать режимы (ручной/автономный/сон)",
source = "Монитор ресурсов", metrics = "Время переключения < 50 мс"),
Goal(description = "Плавно интерполировать движения",
source = "Пользовательский опыт", metrics = "Акселерация < 0.5g")
],
needs = [
Need(description = "Текущая команда из буфера",
required = "Модуль ввода", metrics = "Наличие команды"),
Need(description = "Карта препятствий",
required = "Модуль сенсоров", metrics = "Разрешение 5 см"),
Need(description = "Уровень заряда батареи",
required = "Монитор ресурсов", metrics = "Точность 1%"),
Need(description = "Математическая модель кинематики робота",
required = "Конфигурация", metrics = "Ошибка модели < 3%")
],
elements = [
System(name = "Планировщик траектории"),
System(name = "Машина состояний (конечный автомат)"),
System(name = "Контроллер безопасности (watchdog)"),
System(name = "Генератор целевых параметров")
],
connections = [
Connection(source = "Машина состояний", target = "Планировщик", transfer = "Текущий режим"),
Connection(source = "Планировщик", target = "Генератор", transfer = "Опорная траектория"),
Connection(source = "Контроллер безопасности", target = "Генератор", transfer = "Флаг аварийной остановки"),
Connection(source = "Генератор", target = "Драйверы", transfer = "Скорость_левого, Скорость_правого")
]
)
· ✅ Первичность связей · ✅ Рекурсивность (каждый модуль сам — система) · ✅ Цель = проекция потребности надсистемы · ✅ Формальное текстовое описание · ✅ Статическая структура + динамический сценарий
Снова дадим команду:
Реализуй примитивный код какого либо элемента из системы выше. Нужно только как пример применимости системы для проектирования программ.
Получаем код. Который пришлось удалить из-ограничения на сообщение в 55 тыс.символов. Оставлю только выводы deepseek. Возможно в ближайшее время все выложу примеры, полученные от deepseek
Скрытый текст
Как этот код отражает модель систем:
Элемент модели Реализация в коде System class SensorModule Goals Публичные методы getDistance(), getOrientation(), getWheelDelta() Needs begin() проверяет наличие IMU; конструктор требует пины; фильтры нужны для шумов Elements UltrasonicDriver, IMUDriver, WheelEncoderDriver Connections filter.update(rawDistance, dt) — связь между сырыми данными и фильтром Рекурсивность Каждый драйвер сам является системой (имеет свои begin(), update()) Наблюдатель printTelemetry() — сервис, наблюдающий за сенсорами
Ключевой вывод: Модель систем дала четкую структуру — мы знали, какие классы создавать, какие у них обязанности (Goals) и что им нужно от других (Needs). Код буквально следует текстовому описанию из предыдущего ответа.
Это как примитив. Начало для создания реальной программы. Вы можете сначала полностью проработать всю систему с помощью модели систем, а потом уже писать код, который будет полностью отражать построенную систему.
Тут я вам наверное ничего не подскажу. Формулы не моя сильная сторона. И думаю единой формулы не существует, как и единого процесса.
Если рассматривать процесс через модель систем, то его можно описать через совокупность срезов (систем) между началом процесса и его окончанием. Это как выше приведенный процесс по приготовлению супа. Мы из грязных овощей путем перехода от одной системе к другой получаем вкусный или не очень суп.
Также процесс можно описать через совокупность действий. Это связи, которые соединяют состояния (системы). Помыть, нарезать, положить, нагреть, помещать, налить, съесть. В представленной модели систем любая сущность может выступать системой.
Я в модели систем хотел дать свободу описания любой системы. Тут возникает сложность, что не на что опереться. Нужен опыт работы с системами. Но сама структура модели систем позволяет избегать ошибок. Аксиома, что потребность одной системы соответствует цели другой системы и соответствует связи между этими системами позволяет однозначно связывать системы между собой.
Связь в данной конструкции нужна лишь для удобства описания и понимания концепции.
Возвращаясь к вашему вопросу. Тут мне кажется нужно сначала описать желаемый процесс через модель систем, а потом заменить элементы и связи в нем на ваши символьные обозначения.
Постараюсь описать примитивным примером:
Система: Салат.
Элементы: огурцы, помидоры, масло.
Связи: помыть, нарезать, перемешать. Связи также являются системами, не забываем это.
Система 1: грязные овощи
Система 1 + Помыть = Система 2 (Чистые овощи)
Система 2 + Нарезать = Система 3 (Нарезанные овощи)
Система 3 + Перемешать = Система 4 (Салат).
Связи можно описать другими словами, чтобы можно было точнее понять что передается, ведь связь - это передаваемая сущность. Помыть - передается энергия, затрачиваемая на очистку овощей от грязи или отнять грязь или можно эту абстракцию назвать "чистота". Нарезать - передается энергия, которая тратится на разделение целого овоща на части или отнять целостность или можно это назвать "уменьшение формы овоща". Перемешать - передается энергия, затрачиваемая на перемешивание и придание салату однородной или нормально распределенной формы или можно это назвать "однородность". Название передаваемых абстракций зависит от многих факторов, прежде всего от опыта, что моделирует и называет абстракции.
Цель системы 1 = передать грязные овощи (грязь и овощи)
Потребность системы Помыть = Грязные овощи.
Цель системы Помыть = Чистота овощей
Потребность системы 2 = Чистота овощей (чистые овощи)
Цель системы 2 = передать готовность быть нарезанными, чистые овощи
Потребность системы Нарезать = Получить готовые к нарезки овощи (чистые овощи)
Цель системы Нарезать = придать определенную форму овощам (нарезанные овощи)
Потребность системы 3 = нарезка овощей определенной формы.
Цель системы 3 = передать нарезанные овощи
Потребность системы Перемешать = получить нарезанные овощи
Цель системы перемешать = смешать овощи с определенной степенью однородности.
Потребность системы 4 = получить смешанные овощи
Цель системы 4 = передать БЖУ, микроэлементы, эмоции, затраченное на приготовление салата время потребителю салата.
Описали все компоненты данного процесса. Грубо. Можно более детализировано или наоборот менее.
Далее уже каждый компонент можете заменить на математические формулы. Элементы в кг.
Да, мы делаем ошибки. Да, мы забываем. Но это не наша вина. Так и задумано.
Может лучше сказать: Это не до конца осознано и продумано создателем инструмента. Современные инструменты - это сложнейшие системы, которые требуют учета многих факторов, поведения смежных инструментов. Счет абстракций идет не на десятки, а на сотни и тысячи. Причем значение этих абстракций не всегда однозначны для всех людей.
Думаю, мало кто специально создает инструменты, которые порождают ошибки. Обычно это компромисс между потребностями и ограничениями создателя системы и возможностями создателя удовлетворить эти потребности через реализуемый функционал. Тут важнее проектировать системы, которые могут быть быстро исправлены при выявлении ошибок.
Создатели asyncio.create_task() явно описали, что задачу нужно сохранять. Но тысячи разработчиков всё равно теряли задачи. Python 3.11+ — теперь asyncio.create_task() без сохранения ссылки генерирует warning
А если вы разработчик чего-то массового, библиотеки там или языка программирования, то перед созданием любой фичи, пожалуйста, сядьте и подумайте, что там может пойти не так. Не закладывайте ошибки. Потому что мы их обязательно сделаем. И тогда я опять скажу, что мой плохой код — ваша вина.
если вы разработчик чего-то массового, библиотеки там или языка программирования, то явно требуйте того, что хочет ваш инструмент, а на все остальное выдавайте ошибку.
Если вам нужен Int, то явно это указывайте пользователю, а не надейтесь, что пользователь введет 123 вместо '123'. Потребность вашего инструмента должна явно совпадать с получаемыми от пользователя данными. Это затребует дополнительного времени, которого обычно нет, но позволит избежать множества ошибок.
Такие глубокие и фундаментальные, которые позволяют описать, спроектировать и проанализировать любую сущность, принятую за систему? Такие достаточно фундаментальные, но при этом простые для понимания?
Да, в статье много тезисов, мало описательного текста. Мало связей в виде примеров с действующим опытом читателей. Если пояснять все концепции, использованные в статье, то материала хватит на учебник. Я к сожалению пока не готов к этому.
Готов поучаствовать в конструктивном диалоге и пояснить слабые, по вашему мнению, места в статье.
Система "Борщ с мясом и чесночком". Цель: удовлетворить потребности человека в БЖУ, микроэлементах, положительных эмоциях (от вкусовых и культурных предпочтений, ностальгии и т.д.). Потребности: продукты питания (свекла, картофель, мясо, чеснок, ...), посуда (кастрюля, ложка, нож, разделочная доска, ...), источник энергии для нагревания кастрюли (газовая или электрическая плита, печка), алгоритм действий для соединения элементов системы и правильного последовательного преобразования одной системы в другую. Связи: вода для мытья овощей, физические усилия для мытья и нарезки овощей, тепловая энергия, грязь с овощей, грязная вода и т.д.
За точность системы не отвечаю, т.к. обычно беру чужие алгоритмы и четко следую им. Представленный набор систем обозначен лишь как пример для проектирования.
Система 1: 5 картошин, 1 свекла, 500 гр мяса, 3 литра воды, 1 зубчик чеснока, 1 морковь, ... Все представленные элементы системы грязные.
Добавляем к системе 1 систему "вода". На выходе получаем Систему 2 "Чистые овощи, пригодные для приготовления супа".
Добавляем к системе 2 систему "Физические усилия по разрезанию овощей и мяса" и систему тарелки. На выходе получаем систему 3 "нарезанные овощи и мясо, разложенное по тарелкам". В описании упустил систему "Разделочная доска". В процессе проектирования мы ее могли упустить, но если подробнее проектировать системы, то можем заметить, что у системы нарезанные овощи не удовлетворена потребность опора для разрезания овоща. Через удовлетворение данной потребности можем прийти к цели добавить систему "разделочная доска" или резать прямо на столе.
Элемент системы 3, а именно нарезанное мясо соединяем с системой кастрюля с водой на плите. На выходе получаем систему 4 "заготовка для бульона".
К системе 4 добавляем системы тепловая энергия. На выходе получаем систему 5 "Бульон".
Далее последовательно добавляем к системе 5 другие системы: нарезанная свекла, картошка, морковка, чеснок и т.д.
В результате проект системы "Борщ с мясом и чесночком" через переход между системами, через соединение элементов различных систем превратился в реальную систему "борщ с мясом и чесночком".
Если вы думали, что создание микропроцессора, создание бензина, чем то принципиально отличается от варки супа, но Модель систем демонстрирует, что принципиальные различия отсутствуют. Это переход от одной системы к другой, путем добавления или исключения некой связи.
А рецепт борща - это та же конструкторская документация с определенным уровнем допущений.
Создание чего то сложного - это поэтапное добавление тех или иных простых систем.
На 100% согласен. Вы четко определили, что в рамках анализа задачи можно выявить, что она не удовлетворяет потребности взаимодействующих систем и должна быть перепроектирована.
Любая задача через представленную методологию Модели систем также может быть спроектирована, проанализирована.
Может быть звучит занудно. Вы же хотели добавить юмора. Но представленная методология позволяет спроектировать, описать, проанализировать любую систему. Хоть микрочип, хоть атомная электростанция, хоть анекдот.
Можно проектировать, анализировать как статичные, так и динамические системы. Проектировать изменение системы. Ведь изменение это добавление или исключение какой-то части системы. Сам процесс изменения также является системой.
Любая система укладывается в представленную структуру: система, элементы, связи, цели, потребности.
Если вы хотите прямо сейчас, без рефлексии использовать данную методологию, то скопируйте ее полностью в какую-нибудь ИИ модель. Я пользуюсь Deepseek. Первым шагом попросите ее проанализировать данную методологию, вторым шагом дайте задание спроектировать систему (Например: с помощью представленной методологии спроектируй систему CRM для малого бизнеса. декомпозируй ее на 4 уровня глубины элементов системы). При необходимости повторите для каждого элемента системы. Это будет не идеальная система. Это будет начальное состояние. Далее можете уточнять параметры для каждого элемента. Лучше конечно, если вы сразу обозначите потребности взаимодействующей системы, тогда проектируемая система будет 100% удовлетворять потребностям.
Пока это лишь методология, которая предполагает наличие у пользователя определенных знаний и опыта.
Предполагаемая цель 1: высказать свое мнение по поводу прочитанной бегло статьи.
Предполагаемая цель 2: показать свое превосходство относительно нового пользователя.
Элементы системы: Три предложения, два из которых являются утверждениями, одно вопросом.
Связи системы: со смежной системой связана через ссылку на конкретный абзац, с внутренними элементами связана через передаваемый смысл, направленный на достижение целей.
Потребности: конкретные слова русского языка, несущие в себе ту или иную смысловую нагрузку.
Каждое предложение также можно описать как систему, затем каждое слово можно описать как систему, затем каждую букву можно описать как систему. Ваша фраза - это система систем)
Заранее извиняюсь, если не правильно определил цели вашей фразы. Вы их просто явно не указали и мне пришлось предполагать. Представленная методология позволили мне разобрать вашу фразу как систему.
Отвечая на ваш вопрос, да статьи проходят модерацию. Возможно статья немного коряво написана из за моего косноязычия, но она позволяет в первом приближении передать смысл, который я в нее вкладывал.
Любая сложность может быть разбита на более простые компоненты и все эти компоненты связаны не чем-то непонятным, а явными системами, которые мы не всегда видим, при этом у каждой системы есть как свои цели, так и потребности, которые связывают различные системы.
Да, конечно. Возьмем примитивную систему "Дом". Взаимодействующая система пусть будет "Человек". Потребности человека бывают разные, но в процессе их определения обозначим их для примера: сохранение тепла в регионе строительства (среднегодовая температура +10 градусов цельсия), обеспечение комфортного проживания семьи 5 человек.
Исходя из двух потребностей человека определяем Цели дома. Сохранять тепло, комфортное проживание 5 человек. Определим элементы системы дом. Эти элементы могут быть разные, в зависимости от системы, которую мы проектируем. Одна из версий набора элементов: стены, крыша, фундамент, пол, окна, двери. Другая версия набора элементов: гостинная, кухня, три комнаты, туалет, ванная, прихожая. В рассматриваемом примере для человека потребителя ближе будет второй набор элементов.
Как элементы Системы связаны между собой? Если мы говорим про комнаты, то передаваемым из одной комнаты в другую в данной системе может выступать: человек, воздушные массы, тепловая энергия, влажность, перемещаемые вещи в процессе жизнедеятельности. Что это дает для проектирования системы? Прежде всего понимание, что вытяжку из туалета не нужно делать в сторону кухни. Дверной проем нужно делать, чтобы в него прошел человек, но при этом в него помещалась либо стандартная, либо индивидуальная по размерам дверь. Для контроля влажности нужно предусмотреть вентиляцию.
Если говорить на тему программирования, то здесь все аналогично.
Потребности клиента = целям программного продукта.
Программный продукт состоит из различных элементов, которые связаны между собой. Представленная методология позволяет увидеть ЯВНО, что передается и получается, из чего состоит системы, зачем она нужна и что нужно ей для функционирования.
System(name = “Калькулятор”) .description = “Программа для выполнения арифметических операций над двумя числами”
Простая структура, состоящая из элементов, связей, целей и потребностей, позволяет рекурсивно описать любую систему. В примерах выше, вы можете описать комнату, из чего она состоит и как эти элементы взаимосвязаны, для чего они там находятся и что им нужно для выполнения своих функций. В системе калькулятор вы увидите, что каждый элемент является системой, что он может быть разобран на элементы, связи.
Выложил проект по описанию систем https://github.com/universalmodelsystems/system_designer
Пока в сыром состоянии, но первый шаг для дальнейшего развития.
В статье упомянуты связи, но пока не особо полно раскрыта их суть. Автор пишет, что статья ещё в процессе написания.
Триплеты из статьи по сути позволяют записывать связи из Методологии модель систем. В методологии Модель систем я предлагаю ссылаться на конкретные системы. Хотел в выходные выложить примитивную версию на django+typescript по описанию систем. В ней связи в соответствии с методологией это (система source, система target, система transfert). Если получится, то сегодня выложу на github и скину ссылку.
Пытаясь разобраться с вашим вопросом пришел к новому выводу.
Модель систем в определенной степени ориентируется на связи. Все компоненты в ней системы, но Связям уделяется особое внимание.
В модели систем методологически введен принцип первичности связей. Это не утверждение, что реальность есть совокупность связей, а предложение, что давайте анализировать реальность через совокупность связей.
А из первичности связей вытекает вывод, что проектирование, анализ нужно начинать с определения связей. Прежде всего со связей с внешней системой.
Ранее предложенный подход также можно использовать и он больше похож на ООП.
Модель систем предлагает начинать с определения внешних связей, затем определять элементы системы и их связи. По сути это связно-ориентированный подход программирования через потоки. Но модель систем не ограничена им и позволяет соединять ООП и связно-ориентированный подход в гибридный подход.
Постараюсь в ближайшее время представить выжимку из диалога с deepseek относительно связи модели систем с гибридными подходами программирования.
От меня благодарность за вопросы, которые расширяют мое собственной понимание ширины сформированной абстракции Модель систем.
И далее вы снова уточняет потребности смежных систем, над систем (пользователей, производителей датчиков и т.д.). Уточняем цели моделируемой системы и рекурсивно ее переделываем. А затем на основании новой версии системы создаём код.
.
Давайте попробуем решить вашу задачу на примере создания программы для управления роботом с использованием Deepseek.
Скопируй всю методологию из статьи и вставим в deepseek. И попросим его для примера:
С помощью модели систем выше давай спроектируем программу для управления игрушкой роботом. Для описания системы используй текстовое описание системы из методологии. Опиши верхнеуровневые элементы программы затем опиши каждый элемент как систему. Постарайся максимально подробно написать все элементы и их описание.
Получим следующее:
Скрытый текст
Отличный вызов! Давайте спроектируем программу для управления игрушечным роботом, используя Модель систем как методологию.
Мы построим иерархическую модель, где сначала определим корневую систему (программу в целом), а затем развернем каждый её элемент как отдельную систему с собственными целями, потребностями и связями.
Корневая система: Программа управления роботом
Декомпозиция элементов как отдельных систем
2.1. Модуль ввода команд
2.2. Движок поведения
2.3. Драйверы исполнительных механизмов
2.4. Модуль сенсоров и восприятия
2.5. Монитор ресурсов
2.6. Сервис телеметрии и логирования
Динамический пример: «Робот объезжает препятствие»
Применим сценарный анализ из методологии.
Состояние S₀: Робот едет прямо по команде «вперед». Сенсоры показывают чисто.
Переход: Ультразвуковой дальномер фиксирует препятствие на расстоянии 30 см.
Добавляемая связь: Connection(source=“Модуль сенсоров”, target=“Движок поведения”, transfer=“Distance=30cm, Obstacle_detected=true”)
Состояние S₁ (после обработки):
· Движок поведения вычисляет траекторию объезда. · Генерирует новые целевые скорости: левое колесо 0.3 м/с, правое 0.1 м/с. · Передает в драйверы.
Результат: Робот поворачивает направо, объезжая препятствие.
Эта модель полностью следует вашей методологии:
· ✅ Первичность связей · ✅ Рекурсивность (каждый модуль сам — система) · ✅ Цель = проекция потребности надсистемы · ✅ Формальное текстовое описание · ✅ Статическая структура + динамический сценарий
Снова дадим команду:
Реализуй примитивный код какого либо элемента из системы выше. Нужно только как пример применимости системы для проектирования программ.
Получаем код. Который пришлось удалить из-ограничения на сообщение в 55 тыс.символов. Оставлю только выводы deepseek. Возможно в ближайшее время все выложу примеры, полученные от deepseek
Скрытый текст
Как этот код отражает модель систем:
Элемент модели Реализация в коде System class SensorModule Goals Публичные методы getDistance(), getOrientation(), getWheelDelta() Needs begin() проверяет наличие IMU; конструктор требует пины; фильтры нужны для шумов Elements UltrasonicDriver, IMUDriver, WheelEncoderDriver Connections filter.update(rawDistance, dt) — связь между сырыми данными и фильтром Рекурсивность Каждый драйвер сам является системой (имеет свои begin(), update()) Наблюдатель printTelemetry() — сервис, наблюдающий за сенсорами
Ключевой вывод: Модель систем дала четкую структуру — мы знали, какие классы создавать, какие у них обязанности (Goals) и что им нужно от других (Needs). Код буквально следует текстовому описанию из предыдущего ответа.
Это как примитив. Начало для создания реальной программы. Вы можете сначала полностью проработать всю систему с помощью модели систем, а потом уже писать код, который будет полностью отражать построенную систему.
Уважаемый, Vadnag, честно не понимаю про что вы. Ваши абстракции не совсем понятны.
Тут я вам наверное ничего не подскажу. Формулы не моя сильная сторона. И думаю единой формулы не существует, как и единого процесса.
Если рассматривать процесс через модель систем, то его можно описать через совокупность срезов (систем) между началом процесса и его окончанием. Это как выше приведенный процесс по приготовлению супа. Мы из грязных овощей путем перехода от одной системе к другой получаем вкусный или не очень суп.
Также процесс можно описать через совокупность действий. Это связи, которые соединяют состояния (системы). Помыть, нарезать, положить, нагреть, помещать, налить, съесть. В представленной модели систем любая сущность может выступать системой.
Я в модели систем хотел дать свободу описания любой системы. Тут возникает сложность, что не на что опереться. Нужен опыт работы с системами. Но сама структура модели систем позволяет избегать ошибок. Аксиома, что потребность одной системы соответствует цели другой системы и соответствует связи между этими системами позволяет однозначно связывать системы между собой.
Связь в данной конструкции нужна лишь для удобства описания и понимания концепции.
Возвращаясь к вашему вопросу. Тут мне кажется нужно сначала описать желаемый процесс через модель систем, а потом заменить элементы и связи в нем на ваши символьные обозначения.
Постараюсь описать примитивным примером:
Система: Салат.
Элементы: огурцы, помидоры, масло.
Связи: помыть, нарезать, перемешать. Связи также являются системами, не забываем это.
Система 1: грязные овощи
Система 1 + Помыть = Система 2 (Чистые овощи)
Система 2 + Нарезать = Система 3 (Нарезанные овощи)
Система 3 + Перемешать = Система 4 (Салат).
Связи можно описать другими словами, чтобы можно было точнее понять что передается, ведь связь - это передаваемая сущность. Помыть - передается энергия, затрачиваемая на очистку овощей от грязи или отнять грязь или можно эту абстракцию назвать "чистота". Нарезать - передается энергия, которая тратится на разделение целого овоща на части или отнять целостность или можно это назвать "уменьшение формы овоща". Перемешать - передается энергия, затрачиваемая на перемешивание и придание салату однородной или нормально распределенной формы или можно это назвать "однородность". Название передаваемых абстракций зависит от многих факторов, прежде всего от опыта, что моделирует и называет абстракции.
Цель системы 1 = передать грязные овощи (грязь и овощи)
Потребность системы Помыть = Грязные овощи.
Цель системы Помыть = Чистота овощей
Потребность системы 2 = Чистота овощей (чистые овощи)
Цель системы 2 = передать готовность быть нарезанными, чистые овощи
Потребность системы Нарезать = Получить готовые к нарезки овощи (чистые овощи)
Цель системы Нарезать = придать определенную форму овощам (нарезанные овощи)
Потребность системы 3 = нарезка овощей определенной формы.
Цель системы 3 = передать нарезанные овощи
Потребность системы Перемешать = получить нарезанные овощи
Цель системы перемешать = смешать овощи с определенной степенью однородности.
Потребность системы 4 = получить смешанные овощи
Цель системы 4 = передать БЖУ, микроэлементы, эмоции, затраченное на приготовление салата время потребителю салата.
Описали все компоненты данного процесса. Грубо. Можно более детализировано или наоборот менее.
Далее уже каждый компонент можете заменить на математические формулы. Элементы в кг.
Приготовление салата = f3(f2(f1(0,3 * А + 0,3 * Б))+0,1 * С)
f3 = смешать, f2 = нарезать, f1= помыть
А = огурцы, Б = помидоры, С = масло.
Функции также можно описать через модель систем, т.к. это набор действий с определенной степенью детализации.
Спасибо за книгу. Начал читать. Надеюсь что-то подчеркну нового, чтобы можно было что-то ещё добавить в представленную Модель систем.
Может лучше сказать: Это не до конца осознано и продумано создателем инструмента. Современные инструменты - это сложнейшие системы, которые требуют учета многих факторов, поведения смежных инструментов. Счет абстракций идет не на десятки, а на сотни и тысячи. Причем значение этих абстракций не всегда однозначны для всех людей.
Думаю, мало кто специально создает инструменты, которые порождают ошибки. Обычно это компромисс между потребностями и ограничениями создателя системы и возможностями создателя удовлетворить эти потребности через реализуемый функционал. Тут важнее проектировать системы, которые могут быть быстро исправлены при выявлении ошибок.
Создатели
asyncio.create_task()явно описали, что задачу нужно сохранять. Но тысячи разработчиков всё равно теряли задачи. Python 3.11+ — теперьasyncio.create_task()без сохранения ссылки генерирует warningесли вы разработчик чего-то массового, библиотеки там или языка программирования, то явно требуйте того, что хочет ваш инструмент, а на все остальное выдавайте ошибку.
Если вам нужен Int, то явно это указывайте пользователю, а не надейтесь, что пользователь введет 123 вместо '123'. Потребность вашего инструмента должна явно совпадать с получаемыми от пользователя данными. Это затребует дополнительного времени, которого обычно нет, но позволит избежать множества ошибок.
А можете уточнить ваш комментарий?
Такие глубокие и фундаментальные, которые позволяют описать, спроектировать и проанализировать любую сущность, принятую за систему? Такие достаточно фундаментальные, но при этом простые для понимания?
Да, в статье много тезисов, мало описательного текста. Мало связей в виде примеров с действующим опытом читателей. Если пояснять все концепции, использованные в статье, то материала хватит на учебник. Я к сожалению пока не готов к этому.
Готов поучаствовать в конструктивном диалоге и пояснить слабые, по вашему мнению, места в статье.
Еще один пример для проектирования системы.
Система "Борщ с мясом и чесночком". Цель: удовлетворить потребности человека в БЖУ, микроэлементах, положительных эмоциях (от вкусовых и культурных предпочтений, ностальгии и т.д.). Потребности: продукты питания (свекла, картофель, мясо, чеснок, ...), посуда (кастрюля, ложка, нож, разделочная доска, ...), источник энергии для нагревания кастрюли (газовая или электрическая плита, печка), алгоритм действий для соединения элементов системы и правильного последовательного преобразования одной системы в другую. Связи: вода для мытья овощей, физические усилия для мытья и нарезки овощей, тепловая энергия, грязь с овощей, грязная вода и т.д.
За точность системы не отвечаю, т.к. обычно беру чужие алгоритмы и четко следую им. Представленный набор систем обозначен лишь как пример для проектирования.
Система 1: 5 картошин, 1 свекла, 500 гр мяса, 3 литра воды, 1 зубчик чеснока, 1 морковь, ... Все представленные элементы системы грязные.
Добавляем к системе 1 систему "вода". На выходе получаем Систему 2 "Чистые овощи, пригодные для приготовления супа".
Добавляем к системе 2 систему "Физические усилия по разрезанию овощей и мяса" и систему тарелки. На выходе получаем систему 3 "нарезанные овощи и мясо, разложенное по тарелкам". В описании упустил систему "Разделочная доска". В процессе проектирования мы ее могли упустить, но если подробнее проектировать системы, то можем заметить, что у системы нарезанные овощи не удовлетворена потребность опора для разрезания овоща. Через удовлетворение данной потребности можем прийти к цели добавить систему "разделочная доска" или резать прямо на столе.
Элемент системы 3, а именно нарезанное мясо соединяем с системой кастрюля с водой на плите. На выходе получаем систему 4 "заготовка для бульона".
К системе 4 добавляем системы тепловая энергия. На выходе получаем систему 5 "Бульон".
Далее последовательно добавляем к системе 5 другие системы: нарезанная свекла, картошка, морковка, чеснок и т.д.
В результате проект системы "Борщ с мясом и чесночком" через переход между системами, через соединение элементов различных систем превратился в реальную систему "борщ с мясом и чесночком".
Если вы думали, что создание микропроцессора, создание бензина, чем то принципиально отличается от варки супа, но Модель систем демонстрирует, что принципиальные различия отсутствуют. Это переход от одной системы к другой, путем добавления или исключения некой связи.
А рецепт борща - это та же конструкторская документация с определенным уровнем допущений.
Создание чего то сложного - это поэтапное добавление тех или иных простых систем.
На 100% согласен. Вы четко определили, что в рамках анализа задачи можно выявить, что она не удовлетворяет потребности взаимодействующих систем и должна быть перепроектирована.
Любая задача через представленную методологию Модели систем также может быть спроектирована, проанализирована.
Может быть звучит занудно. Вы же хотели добавить юмора. Но представленная методология позволяет спроектировать, описать, проанализировать любую систему. Хоть микрочип, хоть атомная электростанция, хоть анекдот.
Можно проектировать, анализировать как статичные, так и динамические системы. Проектировать изменение системы. Ведь изменение это добавление или исключение какой-то части системы. Сам процесс изменения также является системой.
Любая система укладывается в представленную структуру: система, элементы, связи, цели, потребности.
Если вы хотите прямо сейчас, без рефлексии использовать данную методологию, то скопируйте ее полностью в какую-нибудь ИИ модель. Я пользуюсь Deepseek. Первым шагом попросите ее проанализировать данную методологию, вторым шагом дайте задание спроектировать систему (Например: с помощью представленной методологии спроектируй систему CRM для малого бизнеса. декомпозируй ее на 4 уровня глубины элементов системы). При необходимости повторите для каждого элемента системы. Это будет не идеальная система. Это будет начальное состояние. Далее можете уточнять параметры для каждого элемента. Лучше конечно, если вы сразу обозначите потребности взаимодействующей системы, тогда проектируемая система будет 100% удовлетворять потребностям.
Пока это лишь методология, которая предполагает наличие у пользователя определенных знаний и опыта.
Система "Фраза пользователя equity_fa".
Предполагаемая цель 1: высказать свое мнение по поводу прочитанной бегло статьи.
Предполагаемая цель 2: показать свое превосходство относительно нового пользователя.
Элементы системы: Три предложения, два из которых являются утверждениями, одно вопросом.
Связи системы: со смежной системой связана через ссылку на конкретный абзац, с внутренними элементами связана через передаваемый смысл, направленный на достижение целей.
Потребности: конкретные слова русского языка, несущие в себе ту или иную смысловую нагрузку.
Каждое предложение также можно описать как систему, затем каждое слово можно описать как систему, затем каждую букву можно описать как систему. Ваша фраза - это система систем)
Заранее извиняюсь, если не правильно определил цели вашей фразы. Вы их просто явно не указали и мне пришлось предполагать. Представленная методология позволили мне разобрать вашу фразу как систему.
Отвечая на ваш вопрос, да статьи проходят модерацию. Возможно статья немного коряво написана из за моего косноязычия, но она позволяет в первом приближении передать смысл, который я в нее вкладывал.
Любая сложность может быть разбита на более простые компоненты и все эти компоненты связаны не чем-то непонятным, а явными системами, которые мы не всегда видим, при этом у каждой системы есть как свои цели, так и потребности, которые связывают различные системы.
Да, конечно. Возьмем примитивную систему "Дом". Взаимодействующая система пусть будет "Человек". Потребности человека бывают разные, но в процессе их определения обозначим их для примера: сохранение тепла в регионе строительства (среднегодовая температура +10 градусов цельсия), обеспечение комфортного проживания семьи 5 человек.
Исходя из двух потребностей человека определяем Цели дома. Сохранять тепло, комфортное проживание 5 человек. Определим элементы системы дом. Эти элементы могут быть разные, в зависимости от системы, которую мы проектируем. Одна из версий набора элементов: стены, крыша, фундамент, пол, окна, двери. Другая версия набора элементов: гостинная, кухня, три комнаты, туалет, ванная, прихожая. В рассматриваемом примере для человека потребителя ближе будет второй набор элементов.
Как элементы Системы связаны между собой? Если мы говорим про комнаты, то передаваемым из одной комнаты в другую в данной системе может выступать: человек, воздушные массы, тепловая энергия, влажность, перемещаемые вещи в процессе жизнедеятельности. Что это дает для проектирования системы? Прежде всего понимание, что вытяжку из туалета не нужно делать в сторону кухни. Дверной проем нужно делать, чтобы в него прошел человек, но при этом в него помещалась либо стандартная, либо индивидуальная по размерам дверь. Для контроля влажности нужно предусмотреть вентиляцию.
Если говорить на тему программирования, то здесь все аналогично.
Потребности клиента = целям программного продукта.
Программный продукт состоит из различных элементов, которые связаны между собой. Представленная методология позволяет увидеть ЯВНО, что передается и получается, из чего состоит системы, зачем она нужна и что нужно ей для функционирования.
System(name = “Калькулятор”) .description = “Программа для выполнения арифметических операций над двумя числами”
Простая структура, состоящая из элементов, связей, целей и потребностей, позволяет рекурсивно описать любую систему. В примерах выше, вы можете описать комнату, из чего она состоит и как эти элементы взаимосвязаны, для чего они там находятся и что им нужно для выполнения своих функций. В системе калькулятор вы увидите, что каждый элемент является системой, что он может быть разобран на элементы, связи.