Embedded Files
https://habrahabr.ru/post/318232/
Прелестно!
Все верно. Все так и было когда-то. Похожую логику применяли и применяют многие инженеры.
Но все-таки ключевое слово - БЫЛО.
А теперь (примерно с 2009 года, может немного раньше), многое дополнено и изменено в методологии инженерной деятельности.
Далее я постараюсь коротко описать эти дополнения со своей точки зрения.
В качестве примеров используются данные реального проекта в химической отрасли (производство краски).
Просьба оценивать эту информацию, как дополнение к представленной в статье картине.
И предложение для методов комментирования и дискуссии по этой теме.
Предлагаю использовать не конкурентные точки зрения.
То есть не писать, что НЕ ВЕРНО в представленной информации, а писать что ВЕРНО И ПРАВИЛЬНО.
Потом добавлять информацию со своей точки зрения.
Получим тогда расширение семантической модели такого знания, вместо уточнения такой модели.
Проектирование предприятия ведется по-разному в разные моменты времени.
Создается не одна модель, а множество моделей.
По сути, архитектура предприятия всегда многомерная.
И во времени развивается тот или иной аспект этой архитектуры.
Красиво эта идея описана в статье "Как создать слона..."
http://ailev.livejournal.com/1088630.html
Одной из задач проектирования всегда была корректная классификация.
В стандарте ISO-81346-1 описан подход для классификации всех элементов моделей предприятия.
Там же определены правила и методы, как формировать именно многомерные модели архитектуры.
Далее я буду пользоваться терминами из этого стандарта.
Тексты стандарта по ссылке
Кстати, практическая реализация стандарта в электротехнике, гидравлике, пневматике - это программа Eplan.
На примере этой программы можно посмотреть, как можно работать с многомерным представлением в модели.
Прежде всего, вся архитектура существует одновременно в трех главных аспектах.
Аспекты
функций (=)
продуктов (изделий?) (-)
места расположения (+).
Значки использованы далее для определения названий аспектов.
Но может быть и больше аспектов, это возможно.
Причем только любой один аспект является обязательным.
Модели постоянно меняются во времени.
Обычно процесс проектирования ведется "сверху-вниз" и "снизу-вверх".
То есть идем от функций к продуктам и от продуктам к функциям.
То есть работа идет ОДНОВРЕМЕННО в двух аспектах (а иногда и в трех-четырех аспектах), а не только функции определяем.
Например, мне нужна функция "Смешать компоненты".
Эту функцию выполнит некий материальный объект, который где-то будет стоять в цеху.
Поэтому в модель архитектуры добавлен такой объект.
Каждый объект в модели может быть всегда и функцией, и нечто материальное, и часть бизнес процесса.
Но не каждый аспект определен сразу!
В начале функция "Смешать компоненты" в модель введена на функциональной (!) диаграмме в виде символа.
СЕЙЧАС и на данной диаграмме этот символ обозначает только функцию (- + =HW).
Однако в модели архитектуры этот символ обозначает "какой-то продукт, который где-то находится, который смешивает компоненты".
По сути, уточнили только один аспект. В трехмерной системе координат классификации это плоскость (зафиксирована одна координата из 3).
Но этот "символ" - контейнер, который может быть "наполнен" и иным содержанием (фиксируем иные координаты).
Причем инструмент построения таких моделей дает автоматическую синхронизацию всех представлений.
Далее я понимаю, что нужен именно смеситель типа -HW.200 (это смеситель на 200 литров).
В модели объект принимает вид -HW.200 + =HW
Это уже линия в системе координат, но на той самой плоскости.
В "контейнер" символа добавляются все параметры конкретного смесителя. Теперь он и продукт, и функция.
Он становится "смеситель на 200 литров, который где-то находится, который смешивает компоненты"
И потом, я понимаю, где его поставить в цеху (участок +GL1).
В модели архитектуры объект принимает вид -HW.200 +GL1 =HW.
Он становится "смеситель на 200 литров, который стоит на точке GL1, который смешивает компоненты".
Далее в иных моделях я использую любые из определенных аспектов для того, чтобы показать этот реальный объект для конкретного пользователя.
Например, в электросхеме - это некий потребитель энергии.
В схеме бизнес-процессов - это некий потребитель денег при функционально-стоимостном анализе.
В схеме потоков продукции - элемент технологии.
Но всегда идет ссылка на этот ОДИН "контейнер". Он всегда ОДИН, но он единый в РАЗНЫХ аспектах.
Это только часть возможностей, но суть многомерной архитектуры я постарался передать.
Ничего нового в таком подходе нет.
Если внимательно посмотреть, то видны все элементы RUP , BPR, SADT, IDEF и подобных методов и стандартов.
Те же подходы и в Управлении Проектами (PM).
То же самое в психологии, например в НЛП.
А если копать далее, то становится видно, что все эти методы имеют некую общую идеологию.
Эта методология - LFA.
Подробности по ссылке
https://sites.google.com/a/in-genium.in/spec_b/home/methodology_ru/lfa
Сама методология LFA построена на логике "банды трех": Аристотель, Платон, Сократ.
Да, они жили в разное время, но совместное творчество этой банды и породило все методы работы западной цивилизации.
А точнее - этику, эстетику, технологию и подобные дисциплины.
Именно эта банда придумала основы нашего мышления, цели, что хорошо, что плохо.
А вы-то наивно думаете, что мысли и цели в вашей голове рождаются по вашей воле?
Для начала, даже такое понятие, как "воля" - придумано это бандой много веков назад.
Что вы действуете по своей воле, что можете что-то поменять в этом мире, используя свою волю и силы - это все ТОЖЕ придумано этой же бандой!
"...эффективность человеческих действий мыслится как отпечаток некоторых идеальных форм, данных действию в качестве моделей, призванных спроецироватъся на окружающий нас мир и реализоваться в нем через посредство воли человека.
Суть этой традиции – в том, чтобы заранее составлять план действий и реализовывать его, быть может, совершая при этом героические подвиги.
Для нее важны отношения между средством и целью, между теорией и практикой."
А это?
Должна быть теория, практика.
Всегда нужно понимать цели, средства и оценивать результаты.
Важна эффективность шагов, которые мы делаем.
Нужны планы развития, концепции перестройки, целевые программы деятельности.
Так что да, Аристотель и сейчас "живее всех живых".
И все в науке, да и во всех технических и не технических дисциплинах пользуются именно его идеями.
Например, как только звучит слово "цель" - то все, приплыли. Он родимый, Аристотель.
Кстати, идея, что вообще можно что-то моделировать - это тоже оттуда, от него, родимого.
Но есть и иные методологии.
Они построены на иных принципах.
Так что учим мат. часть. То есть читаем книгу ФРАНЦУЗА, о том как КИТАЙЦЫ включили голову совсем в ином направлении, и что из этого вышло.
Типа философские основы нашего мышления и ихнего, в сравнении.
Книга небольшая, но сложная и тяжелая. Осилить очень сложно!
Но это стоит затраченных сил...
Вот ссылка на Франсуа Жюльен Трактат об эффективности
https://sites.google.com/a/in-genium.in/spec_b/home/philosophy
Итак, более менее определились на чем построены основы моделирования.
Для успешного моделирования реального мира можно применять основы методологии LFA (западный подход), можно применять методологии восточной традиции мышления (восточный подход).
Можно соединить их и пользоваться объединенной методологией.
Теперь про модели технологических операций, линий, предприятий, корпораций, целых стран и даже транс-национальных корпораций.
Модели можно строить разными методами.
Эти модели будут сложными, запутанными, неполными, неточными.
Что-то подобное было при моделировании реальных физических процессов.
Например, модель капающего крана. Построить модель зависимости частоты падения капель от уровня открытости крана (до момента появления струи).
Задачка очень не тривиальная.
Решение нашлось в теории хаоса (нелинейная динамика).
Суть решения: выбрать такую систему координат, где график явления будет доступен для анализа (не хаотический).
Отсюда возникла идея поиска "фазового пространства" для построения моделей.
Подробности - в книге Хаос. Создание новой науки.
https://bookmate.com/books/ZXjedlIu
Подход к моделированию реальных сложных систем может выглядеть тогда как-то так:
Реальный мир никак не устроен.
В реальном мире нет никаких частей, объектов или функций.
Чтобы не "залипать" думайте, что в мире есть "что-то".
Всегда помним об этом.
Для определенных целей аналитик может выделить в окружающем мире какие-то части.
Эти части существуют только в голове аналитики (например, в виде семантической модели).
И их "существование" всегда только абстрактное.
То есть всегда работаем только с "картой мира" а не с самим "миром".
Это требование определено в психологии, в НЛП.
Например, "черные дыры" существуют только в одной из моделей окружающего мира.
"Черные дыры" не существуют в реальном материальном мире.
Тогда не будем вводить в заблуждение обычных людей (не аналитиков).
Используем восточную и западную методологии (по факту, это почти холизм и редукционизм).
То есть всегда делим целость на части, но не забываем, что целость - не есть только сумма частей.
Анализируем и части, и целое.
Причем, можно разными методами, но всю информацию собираем в единой системе.
Точек зрения должно быть несколько.
Выбор точек зрения не сложный.
С каждой точки зрения часть системы должна выглядеть упорядоченно (то есть простая для анализа, понимания и разумения).
Это и есть корректное "фазовое пространство".
Опять же, все модели со всех точек зрения должны быть в единой информационной системе.
Все модели с разных точек зрения считаются правильными при соблюдении определенных условий:
Должно быть название точки зрения.
Должен быть указан хотя бы один аспект.
Должны быть указана цель модели.
Например, в "гипотетической модели искривленного пространства можно выделить "черные дыры". Цель: дайте бабло на продолжение исследований.
Количество выделенных частей в наблюдаемой части системы должно быть от 5 до 9.
Это простое требование позволяет строить вменяемые диаграммы и простое описание.
Требование выходит из психологии.
Модели должны быть построены на основе какой-то логики.
Какой логики - не очень важно. Важно прямо указать это при моделировании.
Может быть обычная логика Аристотеля.
Может быть непрерывная логика.
Может быть нечеткая логика.
Теперь про практический опыт построения моделей технологических операций, линий, предприятий, корпораций, целых стран и даже транс-национальных корпораций.
С определенной точки зрения увидели, что технологическую операцию можно представить в виде цепочки отдельных технологических ходов.
Оказалось, что с этой же точки зрения все логически объекты (линия, предприятие, отрасль, корпорация) имеют похожую упорядоченную структуру.
Что-то похоже на кристаллическую структуру композитного материала.
Одну архитектуру модели для технологической операции можно применять для всех уровней моделей.
От цеха, до транс-национальных корпораций.
Архитектура очень простая: цепочка последовательно соединенных объектов. Всегда, на любом уровне.
Логика построения: для получения продукта соединяем все необходимые функции последовательно.
Если без этой функции продукт не получить - то добавляем функцию в конец цепочки.
Последовательность функций в архитектуре не имеет значения.
Архитектура только показывает, что все функции необходимы.
Модель дискретно-событийная.
На вход цепочки подаем событие (так моделируется материал).
Событие двигается через всю цепочку функций.
Каждая функция "знает" что делать именно с этим видом события.
Функция получает событие, как-то его использует, и генерирует одно или несколько новых событий. Так моделируем технологию.
События с выхода функции попадают на вход следующей функции.
В конце цепочки - терминатор
Эта примитивная архитектура модели вполне адекватно позволяет работать с бизнес-структурами любого уровня.
Суть: структура модели простая, а поведение элементов сложное.
В реальности можно увидеть, что такие структуры выстраиваются "сами по себе".
Это композитные материалы: кости, зубы, армированный пластик.
Это технологические корпорации и даже небольшие заводы.
Это политические системы и структуры образования.
Мы просто "подглядели" принцип в имеющихся структурах.
Теперь про Захмана.
Есть в его шаблоне рациональное зерно.
Вот только шаблон попытались свести к двумерной табличке, впихнув невпихуемое на плоскость.
"Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? "
Кто выточил деталь - это один аспект модели. Например, аспект "кадры".
Почему выточил деталь - это второй аспект. Например, аспект "бизнес-процесс".
Тогда ответ на вопрос будет сочетание ответов из двух аспектов.
В начале моделирования:
"кто-то, по какому-то заданию"
В конце моделирования
"токарь, по технологической карте 134".
С точки зрения программиста:
Элемент модели в разное время будет то функцией, а то - объектом.
А может быть и функцией и объектом одновременно.
Теперь вопрос только в том, как это реализовать.
Какой инструмент использовать для моделирования и программирования.
Вопрос в том, чтобы часть реального мира представить в виде одного элемента модели.
Но этот элемент будет содержать в себе и объект, и функции, и атрибуты, и методы.
Пока криво все определено, надо бы точнее описать.
"Надо спрашивать: кто выращивает, почему он выращивает, что выращивает. Но тогда получается, что я могу описать деятельность субъекта, который выращивает кукурузу, но не могу описать сам рост. Смирившись с тем, что я не могу описать процесс роста, у меня все равно остаются неразрешенные вопросы: кто и почему выращивает кукурузу (см. выше)? "
Полная модель предприятия - это совокупность разнородных моделей частей предприятия. Плюс модель предприятия, как целостной структуры.
То есть целое - не только совокупность частей.
С этой точки зрения "деятельность субъекта, который выращивает кукурузу" - это часть модели, например в виде use-case (актор-действие).
Сам рост кукурузы - это часть модели, например в виде "диаграммы состояний".
А вот границы объекта в программе лучше определять на основе реального существования в материальном мире.
Например, есть человек, который ухаживает за кукурузой.
Это и будет элемент модели (объект в аспекте материального мира).
А вот "директор предприятия" - это только должность.
Она не существует, как материальный объект.
Поэтому вводить его в модель можно в ином аспекте, в нематериальном.
То же самое касается "бизнес-процессов".
В материальном мире они не существуют.
Поэтому можно их ввести, но в ином аспекте.
Будет много аспектов?
Не факт. Для большинства задач достаточно 3-4 аспекта.
Потом реализуем модели в каждом аспекте в виде отдельной программы.
Плюс интеракция аспектов - отдельная программа.
А полная программа - совокупность поведения во всех аспектах, плюс интеракция аспектов между собой.
Метафора: трехмерная логика работы программы.
Вот только в виде обычного текста такую программу наверное написать очень сложно.
Мне кажется, что назрела необходимость доработки инструментов для генерации программ из таких моделей.
Причем не просто перевод диаграмм в некий текст, а потом его компиляция.
А может быть перевод каждого аспекта в отдельный "слой" кода.
Потом генерация "слоя" кода для интеракции аспектов.
Потом выполнение каждого слоя на отдельной системе исполнения (на отдельном компе? на отдельном процессоре?).
И отдельно работает элемент, который обеспечивает интеракцию элементов системы исполнения.
Не надо ничего виртуализировать!
Каждому элементу модели - свой процессор.
Благо Espressif уже давно выпускает ESP8266 по доллару за ведро.
Ну и Google тоже веселится с Распределёнными вычислениями уже очень серьезно.
По сути, модель тогда можно сделать с динамическим изменением архитектуры во время исполнения.
Да и проблема расширения и уточнения модели будет решаться на уровне добавления программных и аппаратных модулей.
Хотя я тут не очень сильный специалист, может можно сделать и иначе.
Page updated
Report abuse