robossembler/robossembler.org
7
0
Fork 0
Code Issues 5 Pull requests Projects Releases Packages Wiki Activity Actions

Fix typos

Browse source
This commit is contained in:
Igor Brylyov 2024-02-06 13:54:02 +00:00
parent 52e64c1030
commit ab16cfe748
1 changed files with 2 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/information/cfs-models-pub-in-nix.md
View file

@ -21,7 +21,7 @@ git и сервисы, построенные вокруг него стали
### Роль инструментов управления зависимостями
Однако, одного инструмента контроля версии git оказалось недостаточно для сложных проектов разработки. Подход моно-репозитория, когда все компоненты сложной системы размещались в одном хранилище кода, упирался в административные барьеры (у репозитория один владелец) и технические возможности git. Новый функции git, такие как `подмодули`(`submodules`) не решили задачу управления зависимостями так, как это требует современная индустрия разработки. Вокруг каждого нового языка стали вырастать специальные инструменты управления зависимостями - `npm`, `pip` и многие другие. Это вывело возможности коллаборации на новый уровень. Например, сейчас в `Github` можно просмотреть в каких других проектах используется та или иная библиотека по `Network Graph`, что делает поиск аналогов простым и доступным. Ведь в open source зачастую важнее найти уже существующее, чем писать своё собственное, "изобретая велисипед". Тем не менее, специфичность отдельного пакетного менеджера для своих языков не облегчило процесс управления зависимостями в проектах, в состав которых входят программы на разных языках. К таким проектам относятся и `кибер-физические системы` (КФС), где используются слишком разнообразные инструменты разработки, форматы файлов и сборочные системы. Так сложилась потребность в независимом от языков и IDE способе управлять зависимостями, без которой проектирование много-сложных техническим систем затруднительно.
Однако, одного инструмента контроля версии git оказалось недостаточно для сложных проектов разработки. Подход моно-репозитория, когда все компоненты сложной системы размещались в одном хранилище кода, упирался в административные барьеры (у репозитория один владелец) и технические возможности git. Новые функции git, такие как `подмодули`(`submodules`), не решили задачу управления зависимостями так, как это требует современная индустрия разработки. Вокруг каждого нового языка стали вырастать специальные инструменты управления зависимостями - `npm`, `pip` и многие другие. Это вывело возможности коллаборации на новый уровень. Например, сейчас в `Github` можно просмотреть в каких других проектах используется та или иная библиотека по `Network Graph`, что делает поиск аналогов простым и доступным. Ведь в open source зачастую важнее найти уже существующее, чем писать своё собственное, "изобретая велисипед". Тем не менее, специфичность отдельного пакетного менеджера для своих языков не облегчило процесс управления зависимостями в проектах, в состав которых входят программы на разных языках. К таким проектам относятся и `кибер-физические системы` (КФС), где используются слишком разнообразные инструменты разработки, форматы файлов и сборочные системы. Так сложилась потребность в независимом от языков и IDE способе управлять зависимостями, без которой проектирование много-сложных техническим систем затруднительно.
### Пакетный менеджер общего назначения
@ -36,9 +36,7 @@ git и сервисы, построенные вокруг него стали
Современная системная инженерия (например, согласно стандарту IEC 81346—1:2022) выделяет несколько типов декомпозиции систем: функциональное, конструктивное, пространственное, стоимостное. Функциональное разбиение строится по иерархии функциональных компонентов, которые именуются по их роли и могут быть реализованы различными физическими объектами. Конструктивное - по ссылкам на конкретные классы оборудования или их модели. Пространственное - по локализации в пространстве надсистемы. Стоимостное - по стоимости работ и оборудования.
Система всегда имеет воплощение в физическом мире, занимает место в пространстве, что нельзя упускать из виду при любой разработке, а потому в качестве базиса для разбиения систем и их отражения в структуре зависимостей nix должна использоваться модульная/конструктивная/синтетическая структура системы в виде дерева/графа с рёбрами типа `является-частью` (в англоязычной литературе по онтологии `is-part-of`) по следующим причинам:
Основной причиной является то, что производство/сборка/модульный синтез осуществляется по конструктивным описаниям. По мере роста автоматизации возможна ситуация, когда машина сможет преобразовывать декларативное описание функций системы от человека в императивное описание способа построения, но при этом само преобразование не исчезнет - изменится актор, который будет это преобразование осуществлять.
Система всегда имеет воплощение в физическом мире, занимает место в пространстве, что нельзя упускать из виду при любой разработке, а потому в качестве базиса для разбиения систем и их отражения в структуре зависимостей nix должна использоваться модульная/конструктивная/синтетическая структура системы в виде дерева/графа с рёбрами типа `является-частью` (в англоязычной литературе по онтологии `is-part-of`). Дополнительным обоснованием этого решения является тот факт, что производство/сборка/модульный синтез осуществляется по конструктивным описаниям. По мере роста степени автоматизации возможна ситуация, когда машина сможет преобразовывать декларативное описание функций системы от человека в императивное описание способа построения, но при этом само преобразование не исчезнет - изменится актор, который будет это преобразование осуществлять.
Функциональное разбиение является более "субъективным" и часто формируется в контексте т.н. "сценариев использования". Например, в роли молотка может выступать множество предметов - да, в том числе микроскоп. Поэтому идентификация объектов по выполняемой функции может быть затруднительной.