Ремесло программиста

Объявление

форум на движке phpBB доступен для тестирования
www.strategia.space
www.strategia.space/forum/
по предложению Лиса - канал на Matrix - #remdev:matrix.org

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Ремесло программиста » Валентина » Операции над системами


Операции над системами

Сообщений 1 страница 23 из 23

1

Делаю виртуальную машину, которая должна поддерживать модель системного анализа в Валентине. Предлагайте операции над системами. Сейчас есть:
1. Добавление подсистемы
2. Удаление подсистемы
3. Перемещение/переименование подсистемы (пока тестится)

Планируется
1. Копирование подсистемы
2. Сравнение структур систем (это проверка соответствия всех подсистем друг другу, то есть грубо говоря сравнение узлов двух деревьев)
3. Сравнение функциональности систем (это проверка имен всех функций в системе (то есть во вложенных подсистемах не сравниваются)).
4. Сравнение целостности (это проверка только проверка имен дочерних подсистем (то есть без вложенных проверок))
5. Сравнение открытости (сравнение дочерних подсистем в открытой части систем)
6. Сравнение эмерджентности (это проверка только проверка имен и типов дочерних подсистем (то есть без вложенных проверок))

Что еще нужно для работы с системами?

2

utkin написал(а):

Что еще нужно для работы с системами?

Изменять. Свойства добавлять/удалять.

3

Да, свои встроенные свойства (такие как тип системы) модифицировать будет можно, а свойства которые нужны программисту это тоже системы. Создаете себе подсистему, она и будет нужным Вам свойством.
Например:
http://sf.uploads.ru/t/6xbL1.png
http://se.uploads.ru/t/Hkst8.png
Здесь я Вертолету в свойство Винт добавил Лопасти. В терминах языка - добавил подсистему Лопасти в систему Винт надсистемы Вертолет :). Уровень вложенности там по сути неограничен, но, естественно, влияет на производительность. Добавлять и удалять свойства можно (и нужно) во время работы программы.
1 - это базовый объект, вселенная, он виден в отладке. В рабочей модели в программе доступ к нему будет невозможен. То есть на картинке имеется два глобальных объекта - Вертолет и Машина.
И тут я уже могу Машину погрузить в Вертолет :)
http://sg.uploads.ru/t/sDimw.png
Если бы в ней имелись подсистемы (то есть свойства - поля и функции), они бы переехали вместе с Машиной в Вертолет. Вся работа проводится на уровне ссылок, физически объекты не меняют своего расположения в памяти. Для ускорения поиска систем они сортируются при помещении в надсистему (на картинках не видно, потому что систем мало).

4

Результат перемещения Машины со своими подсистемами в Вертолет:
http://sh.uploads.ru/t/cmB1W.png

5

utkin написал(а):

могу Машину погрузить в Вертолет


Хочу операцию склеивания систем с образованием новой системы.

Пример - приваривание корпуса машины к днищу вертолёта с целью получения вертолёта-на-модифицированном-шасси.

т.е. несколько систем образуют новую систему сразу, а после этого становятся её частями

Хотя это, конечно, можно сделать уже имеющимися операциями:
- создать новую
- добавить корпус
- добавить шасси

Если исходить из минималистичности дизайна, то такая операция не нужна

Отредактировано ВежливыйЛис (2017-07-29 10:31:25)

6

Если имеется ввиду операция типа:

Создать_систему Амфибия(Машина, вертолет, пароход)

, которая дает в результате:
Амфибия
.................Машина
.................Вертолет
.................Пароход

То, да это возможно, просто на сейчас операция копирования еще не реализована. Описания относительно простых систем (то есть не имеющих в своем составе закрытой части и функций) можно будет читать/записывать в файл (пока в обычный текстовый, но планируется и xml). Они будут являться аналогом записей в других языках программирования (struct или record). Сравните удобство - в struct что-то добавить нельзя (или сейчас уже можно?), то есть это статические записи.
Для систем планируются - статические объявления (сама программа это есть описание системы), динамические изменения систем (включая операции по перемещению и копированию из других систем) и экспорт/импорт (пока только в файлы). Наследование одиночное, то есть либо из описания системы (это аналог класса получается) или прямое полное копирование объекта под новым именем.

7

utkin написал(а):

Амфибия
.................Машина
.................Вертолет
.................Пароход

Хотелось бы узнать/почитать по-подробнее про типы систем. А то непонятно - тут три транспортных средства погружены в амфибию или являются её конструктивными частями

Отредактировано ВежливыйЛис (2017-07-29 12:09:58)

8

Про типы немного позже, но скажу сразу что нельзя определить в каком отношении состоят системы, это зависит от Вас. Собственно Ваше утверждение не корректно имеет или. Погруженное транспортное средство может являться частью амфибии и из Вашего утверждения определить что-то невозможно. Аналогично и в системах - надсистема "владеет" подсистемой, а в каких она с ней состоит отношениях определить можно только с помощью программиста и функций. То есть в зависимости от того как обрабатываются подсистемы в системе так и будет известно что это груз или часть амфибии.
Типы систем Вам тут не помогут. Я вот к примеру могу забивать гвозди микроскопом. Тип микроскоп не предназначен для забивания гвоздей, но это же не проблема гвоздя, верно?

9

utkin написал(а):

Тип микроскоп не предназначен для забивания гвоздей, но это же не проблема гвоздя, верно?

А как-же защита от дурака? И веское слово? Если вы не будете описывать систему словами, а только функциями, то у вас не получиться системного языка, а будет функциональный.
Однако типы систем хорошо классифицированы в известной литературе. Почему их не использовать?

utkin написал(а):

а в каких она с ней состоит отношениях определить можно только с помощью программиста и функций.

Вот вы сейчас всю теорию систем превратили в туфтологию. Есть такая вещь критерии подобия. И что мне теперь, что-бы проверить системы на подобность нужно тыкать палкой программиста? А я думал мы в современном автоматизированном мире живём, когда это можно сделать одной кнопкой.

10

А как-же защита от дурака? И веское слово? Если вы не будете описывать систему словами, а только функциями, то у вас не получиться системного языка, а будет функциональный.

Примитивная защита от дурака будет, но полной защиты нет нигде. А в реальном мире тем более.

Однако типы систем хорошо классифицированы в известной литературе. Почему их не использовать?

Потому что они хорошо описаны для статической типизации, когда известно что черное это черное, а белое это белое.

Вот вы сейчас всю теорию систем превратили в туфтологию.

Ничего подобного. Почитайте как осуществляется построение систем человеком. Как строится модель предметной области? Кто определяет компоненты модели? Почему берется именно это свойство, а не какое-то другое (ведь модель никогда не рассматривает все свойства объекта)? Ответьте на эти вопросы.

И что мне теперь, что-бы проверить системы на подобность нужно тыкать палкой программиста?

Есть  типы систем, но они не отражают суть системы. Это просто формальный параметр. Ну например, аналогия. Вот смотрите, Вы идете в магазин, чтобы купить пакет молока. Ну Вы же не проводите химический анализ каждого пакета молока, чтобы определить молоко перед Вами или не молоко. Вы просто читаете ценник и читаете упаковку. То же самое и тип систем. Вы можете проверять тип системы, но это не означает, что в пакет производитель налил молоко, а не, например, яблочный сок. Пока не вскроете пакет (не начнете взаимодействовать) определить сок там или молоко проблематично. Вы сразу увидели различие с привычным для Вас миром и тут же категорически выступили против, вместо того чтобы попытаться понять. Вам нужно больше читать про системный анализ. Тип объекта строго говоря не означает что перед нами действительно объект данного типа. Это означает что ожидается объект данного типа (и в 99 процентах это соответствует действительности). Поэтому работа с типами в обобщенном виде должна предусматривать такие несоответствия. Ну например, Вы купили пакет молока, а там дохлая мышь. Соответственно каши на молоке не получится. То есть Вы как программист должны это понимать.

И что мне теперь, что-бы проверить системы на подобность нужно тыкать палкой программиста? А я думал мы в современном автоматизированном мире живём, когда это можно сделать одной кнопкой.

Тип системы в данном случае просто строка. Вы можете читать и изменять его. Функции могут определять тип системы во время исполнения и предполагать, что работают с нужными системами. Вы должны понимать, что, во-первых, все динамично, во-вторых, практически все строгие системы типов имеют костыли для преобразования типов типа  Variant в паскаль/делфи. Каждая промышленная система (Паскаль, С++, Ява и т.д.) предполагают махинации с типами, выходящими за рамки модели строгой типизации. Почему? Потому что в реальном мире невозможно предсказать что тип определяет объект. Можно это только предполагать. Например, Вы миллион раз видели ручку, знаете как ведет себя ручка и сразу можете определить что такое ручка. Но всегда существует ничтожный шанс, что перед вами окажется не ручка, а например стилус или автоматический карандаш или еще что-то, но не ручка.
Еще пример в программировании. Зачем нужен GUID? Ведь известно что за система и какой ее тип? А может быть неизвестно? А может быть поведение системы настолько сложно, что проще представлять ее как уникальную систему? Ответьте на эти вопросы. Казалось бы Микрософт породил интерфейс. Кому как ему не знать назначение данного интерфейса (класса и еще кучи всего)? Но нет, этого оказывается мало. Почему? Зачем интерфейсу еще и свое собственное клеймо бахать? Ведь в исходнике четко известно какой это интерфейс. Или неизвестно?
Бытовой уровень. Вода и лед. Всем ведь известно что тип лед это тип вода? Но когда речь идет обо льде (например гололедица) никто не думает и не говорит, что вода достигла такого агрегатного состояния, что ходить стало опасно. Проще представлять отдельный феномен - лед. Такая вот модель со своими свойствами. И даже когда я морожу воду в морозильнике для виски, я не думаю о воде, я думаю о кубиках льда, которые будут подаваться гостям. Хотя лед здесь нужен ровно для того, чтобы потом растаять и стать водой (ну и конечно впечатление от мероприятия :) ). Никто ведь не предполагает - так переведу воду в другое состояния для придания других свойств, чтобы потом в спиртосодержащейся жидкости вернуть исходное состояние воды.
Все это живое отражение состояния систем и отношения к системам. Система вода. Состояние системы изменилось, и изменилось отношение к системе. Может быть настолько, что мы готовы рассматривать ее как иную систему. Почему и когда? Задумайтесь над этим. При этом мы применяем к ней иные методы (которые пригодны для льда, но не для воды в общем), но почему это происходит? Ведь вода будучи льдом осталось водой. Верно?
И еще по Вашим претензиям у меня к Вам встречный вопрос - вот Вы создаете сложный класс. А какой тип и вообще какие сведения определяют что входит в класс и почему это обычное целое 4-х байтовое число, а не 8-мибайтовое? Это прямо вот Ваша претензия иными словами. Кто решил, что для переменной цикла годится именно этот тип, а не другой? Почему Вы наследуетесь от этого класса, а не от какого-то другого? Ведь классов много и вероятность выбора одного из них крайне мала, почему именно он? Иными словами - кто решает что микроскопом можно забивать гвозди или нельзя? Тем более что микроскопом гвозди забивать можно?

11

А то непонятно - тут три транспортных средства погружены в амфибию или являются её конструктивными частями

Сделайте так чтобы было понятно. Например создайте Вертолету подсистему Грузовой отсек и считайте, что там хранится только груз.
http://s9.uploads.ru/t/zVPBk.png
Теперь при добавлении Машины будет понятно, что это такое - груз или часть вертолета. Засуньте в Грузовой отсек и считайте что груз. Засуньте в шасси и считайте, что у Вас Вертолет на базе КАМАЗа собран. Если последний вариант, то вертолет можно будет и переименовать в Амфибию или еще что-то такое.

12

Конструктор копирования:
http://sd.uploads.ru/t/DfRsK.png
Необходимо реализовать еще оператор копирования (для копирования в существующую систему) для работы с выражениями. Конструктор создает новую подсистему (то есть Вертолет был, а Вертолет.Машина не было).
Еще картинка:
http://s4.uploads.ru/t/zpWTY.png
То есть отличие от большинства языков программирования - это не ссылочное копирование (копирование указателя), а настоящий новый объект, одиночное наследование. Причем это возможно как по описанию системы так и динамически во время выполнения программы. Аналогично решается и вопрос удаления - так как все системы имеют одинаковую природу, имеется возможность создания общего деструктора, который можно вызывать автоматически, когда система не нужна (примитивная сборка мусора).

13

utkin написал(а):

Конструктор копирования

Копировать материальные объекты нельзя!
Материальные объекты собирают на заводах.
А живых существ порождают и выращивают.

14

Копировать материальные объекты нельзя!

Но это ведь не материальные объекты, а представления о материальных объектах.

15

utkin написал(а):

Но это ведь не материальные объекты, а представления о материальных объектах.

Написано "Машина", а не "3D-модель машины, нарисованная в blender".

У меня ещё про трюм (грузовой отсек) вопрос остался. Где-то рядом должны быть системы, описывающие типы связей, правильно? Хотелось бы примеров...

Отредактировано ВежливыйЛис (2017-07-31 18:43:35)

16

Написано "Машина", а не "3D-модель машины, нарисованная в blender".

Машина это собирательное обозначение механизма. Абстракция. Есть поисковая машина, есть стиральная машина, губозакаточная....
http://cdn.st100sp.com/pictures/031864975

Где-то рядом должны быть системы, описывающие типы связей, правильно? Хотелось бы примеров...

Про какие типы связей идет речь?

17

utkin написал(а):

Машина это собирательное обозначение механизма. Абстракция.


Есть мозг, мышление которого мы имитируем. Мозг наблюдает объекты реального мира через глаза. И создаёт абстракции, соответствующие объектам, а так же абстракции более высокого уровня.

Если абстракция "машина" отражает физическую машину, то её нельзя копировать, потому что физические машины не копируются.

А если абстракция "машина" это обобщённая абстракция, то её не нужно копировать, так как в этом нет смысла (она одна такая, а все другие - другие (описывают другие предметы или обобщают другие понятия)).

18

И создаёт абстракции, соответствующие объектам, а так же абстракции более высокого уровня.

Нет, нет, нет. На самом деле точно ничего неизвестно. Можно только утверждать, что абстракция это какое-то обобщение, где выделяются важные для наблюдателя свойства. Ну грубый пример, идет девушка. Парень оценит размер груди, а другая девушка фасон платья (а бабка на лавочке скажет - проститутка :) ). Объект один, а отражения разные. И все таки в мире девушки, а не ходячие титьки и не вешалки с платьями. А вот какие выбираются свойства при построении модели сказать нельзя. Это зависит от того кто и зачем строит модель. Соответственно и остальной Ваш ход мыслей не верный. Потому что Вы занимаетесь не решением проблемы, а имитационным моделированием. Если проблема и есть максимально смоделировать физический объект, то пожалуйста. Но вы например, решая школьные задачи про паровоз идущий из пункта А в пункт Б не собираете реальный паровоз, а берете только те свойства, которые нужны для решения задачи.

так как в этом нет смысла (она одна такая, а все другие - другие (описывают другие предметы или обобщают другие понятия)).

В этом и есть соль, что Вы копируете обобщение, чтобы в дальнейшем модифицировать его, придать конкретики. Проставить заводской номер, задать конкретное значение цвета, массы и т.д. Поставить на вертолет шасси от камаза.  В реальности Вам бы пришлось немного помучиться. Так то согласно математике и факториал вычислять нет смысла, так как его уже однажды вычислили до Вас, а формулы своих свойств не меняют и при одинаковых параметрах дают одинаковый результат.

19

utkin написал(а):

Вы копируете обобщение, чтобы в дальнейшем модифицировать его, придать конкретики.

Так это же совсем другая операция, дружище! Операция "конкретизации", и никакое не копирование вовсе!

20

Нет это именно копирование, потому что определить что и как будет конкретизироваться в общем виде невозможно. Это можно сделать для ограниченного множества систем с известными свойствами под строго определенную задачу. Поэтому программист получает возможность скопировать объект быстро, а вот конкретизировать уже сам, ручками.

21

Операция присваивания:
http://sg.uploads.ru/t/VCTa0.png
Отличие - приемник должен существовать. Все его содержимое будет убито и поверх записано содержимое источника. Конструктор копирования создает новый узел, данная операция перезаписывает существующий узел (кроме имени разумеется).

22

Инициализатор системы - убивает все ее содержимое (при это функции перестают быть функциями и теряют свое тело, вернуть нельзя, только копированием с образца).
Исходные данные:
http://sa.uploads.ru/t/QUTEa.png
Результат операции:
http://s8.uploads.ru/t/7XG6S.png

Собственно, я уже достиг некоторой критической массы из операций, дальше будут добавлены операции установки/чтения свойств систем (например чтение типа системы и т.д.). После этого можно считать, что виртуальная машина для работы с моделями систем худо-бедно собрана. Ну и реализация кучи проверок (типа что система не содержит подсистем), но они простые и проблем доставлять не должны (так как не меняют состояния модели). Остается один больший этап - работа с функциями и можно будет собирать парсер и интерпретатор.

23

Операции над встроенными свойствами систем:
http://s1.uploads.ru/t/uQozt.png
Осталась реализация кода функций и можно пытаться собирать интерпретатор.


Вы здесь » Ремесло программиста » Валентина » Операции над системами