Единое электронное информационное пространство (ЕИП)

[Кузнецов Сергей]

Oсновано на едином универсальном представлении данных произвольной структуры, оснащено единым универсальным программным инструментарием, мимикрирующим меню-интерфейсом.
Позволяет строить электронные модели ЛЮБЫХ физических, математических и информационных объектов.

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

Подробности на сайте:
http://sprspase.16mb.com/

[YorikER]

Возможно я пока еще не все понял  , но сложилось устойчивое впечатление, что представленная объектно-ориентированная модель (ООМ) ЕИП - смесь "простого дерева" иерархически структурированной СУБД и стандарта IDEF0.
1. Отсутствует понятие типа СВЯЗИ, существует только один тип связи "дочерний-родительский" (простая иерархическая СУБД - движение вверх-вниз). Для более полного описания ООМ необходимо ввести понятие типа связи. Дочерние объекты могут подчиняться родительскому по разным типам связей. Например возьмем структуру описания обыкновенной семьи:
   а) Родительский объект ОТЕЦ - связь ДЕТИ - дочерний объект СЫН (или ДОЧЬ).
   б) Родительский объект ОТЕЦ - связь ОДЕЖДА - дочений объект ПИДЖАК.
   в) Родительский объект СЫН - связь ДЕТИ - дочерний объект ВНУЧКА.
   г) Родительский объект ВНУЧКА - связь ОДЕЖДА - дочерний объект ПЛАТЬЕ...
2. Отсутствует понятие СОСТОЯНИЯ объекта. Для полного описания ООМ очень важное понятие.
3. Приветствуется попытка описания типа объекта - ПРОЦЕСС, описание очень похоже на стандарт IDEF0. Однако не понятно, почему ПРОЦЕСС не может содавать новые ОБЪЕКТЫ, а только осуществляет процедуру переноса (транспортировки) ОБЪЕКТОВ. Может я что-то не понял, но на мой взгяд именно ПРОЦЕСС является ОБЪЕКТОМ порождающим новые ОБЪЕКТЫ. Например процесс технологической подготовки производства порождает ОБЪЕКТ типа ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС, который (связь) СОСТОИТ ИЗ ... ОБЪЕКТОВ типа ОПЕРАЦИЯ, которая (связь) СОСТОИТ ИЗ ... ОБЪЕКТОВ типа ПЕРЕХОД.

Кроме этого, судя по описанию, каждый объект содержит список подчиненных объектов. Т.е. подразумевается реляционная модель хранения данных. На какой СУБД представленная ЕИП организована?
Вопросов достаточно много, но попытка создать универсальную модель ЕИП откровенно приветствуется! Побольше бы таких работ в среде IT-шников. Успехов!

[Кузнецов Сергей]

Цитата1.Отсутствует понятие типа СВЯЗИ, существует только один тип связи "дочерний-родительский" (простая иерархическая СУБД - движение вверх-вниз). Для более полного описания ООМ необходимо ввести понятие типа связи. Дочерние объекты могут подчиняться родительскому по разным типам связей. Например возьмем структуру описания обыкновенной семьи:

   а) Родительский объект ОТЕЦ - связь ДЕТИ - дочерний объект СЫН (или ДОЧЬ).

   б) Родительский объект ОТЕЦ - связь ОДЕЖДА - дочений объект ПИДЖАК.

   в) Родительский объект СЫН - связь ДЕТИ - дочерний объект ВНУЧКА.

   г) Родительский объект ВНУЧКА - связь ОДЕЖДА - дочерний объект ПЛАТЬЕ...

 

 

Давайте попробуем реализовать предложенное Вами понятие 'семьи обыкновенной' средствами ЕИП. И посмотрим, не подпадают ли некоторые элементы построенной модели под реализацию указанных Вами понятий "типа СВЯЗИ " и "Состояние объекта".

1.      Открываем редактор V-Studio (я в нем программирую) и начинаем создавать электронные объекты необходимых нам типов:

-          GFamily- электронный объект-список типа 'семъя'. Присвоим ему потом  имя 'Ивановы';

-          GHomo  - электронный объект-список типа 'человек'. Имя пока не присваиваем;

-          GFio       -  электронный объект-список типа 'фамилия/имя/отчество'.

-          GList      - электронный объект-список типа 'перечисление объектов'.

-          GGarderob- электронный объект-список типа 'элемент гардероба'.

-          Имеющимися средствами ЕИП формируем меню-интерфейс 'Модель семьи'.

2.      Компилируем вновь созданные электронные объекты с включением их в состав программного ядра ЕИП.

3.      Запускаем программное ядро ЕИП на нашей ПЭВМ, вызываем интерфейс 'Модель семьи' и начинаем собственно формирование электронного объекта семьи 'Ивановы':

- Средствами интерфейса создаем головной обьект типа GFamilyс именем 'Ивановы';

- Создаем и добавляем в список подчиненных GFamily  объект GList   с именем 'Члены семьи';

- В список подчиненных GList   ('Члены семьи') добавляем вновь создаваемые объекты типа GHomo  (ЗАГОТОВКИ общего списка членов семьи);

Далее начинаем заполнять заготовки объектов-членов семьи. Например, первому GHomo   из списка присваиваем имя 'дедушка', добавляем ему в список подчиненных объекты GFio, GGarderob и объект-перечисление   GList   с именем 'дети', в который после оформления всех членов семьи включим ссылки на детей по линии данного дедушки. В обьект GGarderob для данного дедушки можем добавить объекты-перечисления   GList  ('одежда', 'обувь', 'головные уборы' и т.п.), состав которых по такому же принципу можно конкретизировать вплоть до последней пуговицы.

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

4.      Сохраняем созданную электронную модель на жестком диске в файловой структуре нашей ПЭВМ. Для этого платформах WINDOWSи LINUX существует стандартная процедура 'сереализации/десереализации'. Достаточно указать ей в параметрах адрес головного объекта (в нашем случае GFamily) и полное имя файла на диске, после чего созданная нами модель из памяти ПЭВМ будет упакована в бинарный файл и сохранена под указанным именем.

Теперь к вопросу о понятиях:

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

'СОСТОЯНИЕ ОБЪЕКТА'  В рамках ЕИП это физическое воплощение этого понятия можно реализовать в виде программного метода, анализирующего ряд параметров электронной модели и выдающего на выходе некое обезличенное резюме. Например:

Объект 'Семья'. Параметры: родители-алкаши, дети-дебилы, одежда-грязная. Состояние – семья неблагополучная.

Объект 'Отчет'. Параметры: исполнителей -10, отчитались -5. Состояние – готовность 50%.

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

 

Цитата3.Приветствуется попытка описания типа объекта - ПРОЦЕСС  Однако не понятно, почему ПРОЦЕСС не может содавать новые ОБЪЕКТЫ, а только осуществляет процедуру переноса (транспортировки) ОБЪЕКТОВ.

...Например процесс технологической подготовки производства порождает ОБЪЕКТ типа ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС, который (связь) СОСТОИТ ИЗ ... ОБЪЕКТОВ типа ОПЕРАЦИЯ, которая (связь) СОСТОИТ ИЗ ... ОБЪЕКТОВ типа ПЕРЕХОД.

 

Формулируя последнюю фразу Вы мысленно представляете себе ... что? Думаю, перед Вашим мысленным взором предстает некая блок-схема, т.е. рисунок. Ну, в лучшем случае, текстовое описание пока что абстрактного объекта ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС на некоем языке. Если это так, то возникает вопрос: а дальше что? Стоят ли за выделенными словами конкретные электронные модели, или каждое слово (понятие) предполагает лишь некий 'комплекс мер' по своей реализации? Т.е. для того, чтобы реализовать данную фразу (блок-схему/описание) потребуется закупать ПО, устанавливать его на рабочих местах, строить на его основе реальные (физические) информационные потоки, подбирать и обучать персонал, и еще много всякого всего! Если я угадал, то до практической  реализации указанной фразы – дистанция огромного размера. Так вот, процессное проектирование в рамках ЕИП призвано сократить эту дистанцию до одного шага, что я сейчас и попытаюсь пояснить.

 

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

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

1.      Командой 'Процессы/Создать' открываем в главном меню окно-заготовку новой процессной сборки.

2.                       В открывшемся окне начинаем строить блок-схему будущей процессной сборки (см. видео клип процессного проектирования). Построение включает в себя формирование логистической схемы процессной сборки из объектов-процессов первого типа, подключения к ее узлам генерирующих интерфейсов (процессов второго типа), и назначение исполнителей. Данная процедура может занять от нескольких минут до нескольких часов (зависит от сложности процесса и наполненности хранилищ шаблонов). В результате получается так называемый 'макет' будущего процесса (по аналогии cмакетом электрической схемы). Данный макет можно запустить в работу в тестовом режиме для проверки правильности функционирования и коррекции временных интервалов.

3.      Командой 'PLACE' элементы макета рассылаются исполнителям (они были назначены в процессе формирования). В процессе исполнения данной команды копии элементов макета автоматически по сети рассылаются на ПЭВМ исполнителей и включаются в иерархические структуры их программных узлов. С этого момента между общим макетом процесса и его элементами в узлах исполнителей устанавливается взаимная связь (синхронизация данных). Любое изменение данных в узлах исполнителей автоматически отображается на макете, и наоборот.

4.      Кнопкой 'START/STOP' запускаем теперь уже реальный процесс в работу. Далее начинается самостоятельная жизнь нового процесса: получившие задания исполнители начинают их исполнять, руководитель процесса через макет контролирует ход исполнения процесса.



Обратите внимание: в представленном сценарии ни на стадии создания, ни в процессе функционирования информационного процесса от его участников не требуется каких либо дополнительных ручных вмешательств. Это важнейшая задача процессного проектирования – максимально исключить ручное вмешательство на всех этапах. Человек является самым слабым звеном в любом процессе, и поэтому чем меньше он будет в нем задействован, тем надежнее и живучее будет процесс.

[СВ]

...
Обратите внимание: в представленном сценарии ни на стадии создания, ни в процессе функционирования информационного процесса от его участников не требуется каких либо дополнительных ручных вмешательств. Это важнейшая задача процессного проектирования – максимально исключить ручное вмешательство на всех этапах. Человек является самым слабым звеном в любом процессе, и поэтому чем меньше он будет в нем задействован, тем надежнее и живучее будет процесс.

(подчёркнуто мною)
Вопрос: а человек, который создал какое-либо ПО, он что - он что, слабым звеном не является? Или ПО пишут по сути боги, которые по определению не ошибаются?
(Вопрос - в полушутку, т.к. Вы, понятное дело, имеете в виду немножко другое. Но слепая, так сказать, вера во всемогущество чего-то там ... не совсем верный путь.)

[Кузнецов Сергей]

Конечно, имеется в виду технологическая цепочка.
В создании ПО - все наоборот.

[YorikER]

Уважаемый Сергей! Судя по всему, Вы обладаете серьезными аналитическими способностями. Создается впечатление (не претендую на истину в последней инстанции), что Вы, глубоко вникнув в реляционные системы управления данными, создали адекватную Вашему технологическому процессу информационную модель распределенную во времени и в пространстве. Если Вы претендуете на некую общность и универсальность в подходах для других технологических цепочек, искренне рекомендую сделать паузу и изучить другие системы, хотя ARIS Вы где-то уже упомянули. Может быть Вы изобретаете велосипед...
Несколько замечаний по вышесказанному...

• Компиляция нового типа объекта в системе - неудачное решение. Во многих системах это все решается простым моделированием (возьмите хотя бы ЛОЦМАН, раз Вы презентуетесь на этом форуме).
• Категорически не согласен со следующими тезисами (тем более, если Вы претендуете на универсальность):
      "1. Электронный процесс  НЕ ЗАНИМАЕТСЯ созданием новых данных и анализом СОДЕРЖИМОГО данных,  которыми он манипулирует.
      2. Основной функций электронного процесса является УПРАВЛЕНИЕ ПЕРЕМЕЩЕНИЕМ данных.  В функцию управления входит анализ факта наличия или отсутствия новых данных на входе, определения логики их перемещения внутри процесса, и отправка результатов внешним контрагентам."
      ПРОЦЕСС ОБЯЗАН (!) заниматься переработкой данных и созданием НОВЫХ объектов. Для примера возьмем простейший машиностроительный процесс назначения заготовки для изготовления какой-либо детали типа тело вращения: на складе у Вас лежит ТМЦ - круг 100 мм длиной 6000 мм, Вам необходимо отрезать 1000 мм в качестве заготовки для конкретной детали, Вы запускаете процесс, в котором у Вас изменяется информация о ТМЦ на складе и создается новый объект информационного пространства ДЕТАЛЬ...
  Поэтому либо Вы не точны в определениях, либо в ядре ЕИП заложены глобальные ограничения, которые судя по всему приведут к исскуственным манипуляциям, наподобие тем, как Вы описывали моделирование понятия СВЯЗИ в ЕИП. В других системах все это решено на уровне ядра...

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

[Кузнецов Сергей]

Цитата 1: "...создали адекватную Вашему технологическому процессу информационную модель"
+"претендуете на некую общность и универсальность в подходах для других технологических цепочек"
Вы совершенно правильно уловили сущность задачи, поставленной перед нами в начале пути.
Формулировалась она примерно так: построить распределенную во времени и в пространстве типовую электронную модель под названием "Электронное предприятие". Как Вы думаете, сколько технологических цепочек может содержать такая модель? Вот и я - не знаю!
Возможных путей решения видится два:
1.   Вариант первый (традиционный). Все-таки сосчитать ВСЕ технологические цепочки, смоделировать ВСЕ информационные процессы, собрать ВСЕ данные под одну огромную СУБД, накупить для обслуживания всей этой кухни самое современное ПО, связать его системой конверторов данных и поставить этого монстра под управление современной ERP/PDM/PLM-системы.
И здесь Вы угадали – это бессмертный ЛОЦМАН-PLM. Наисовременнейший продукт разработки середины 90-х годов прошлого столетия, обросший за годы всевозможными дополнениями и улучшениями, но по-прежнему имеющий еще доWINдусовую централизованную  вертикальную архитектуру модели, сложный, недружественный интерфейс и очень неприятный вопрос, на который авторы смущаются отвечать – 'а сможет ли данныя система переваривать те ТЕРРАбайты информации, которые будут циркулировать через ее централизованые сетевые узлы и базы данных?'

2.   Вариант второй (Нетрадиционный). Зачем для живого организма клепать мертвую статичную модель, и затем пытаться запхнуть живое в рамки мертвого. Ведь вариант 1 – всего лишь фотография реального предприятия. Уже в следующее мгновение после запуска объект моделирования изменится – где-то придут новые задания, где-то изменятся нормативные документы. Новые веяния сверху вообще льются как из худого ведра!
Отсюда и решение – модель живого должна быть тоже живой (изменяемой, динамичной). И строиться она должна не централизованно сверху-вниз, а наоборот! Да, конечно, в рамках общей архитектуры, но все-таки – снизу-вверх и параллельно во всех структурных подразделениях. В этом случае каждый разработчик на своем месте будет строить свой (знакомый и родной) кусочек модели, придерживаясь общей стратегии и  с учетом смежников. Единственное, что для этого нужно – программный инструментарий (нечто вроде электронного аналога конструктора LEGA), реализующий непротиворечивую, простую и понятную архитектуру модели. А в качестве строительного материала – один базисный электронный объект – настолько мелкий и универсальный, что все остальные возможные объекты будут заведомо больше базисного, а значит, могут быть представлены в виде его различных комбинаций.
Как Вы наверное догадались, Ваш покорный слуга пошел вторым путем – не в ногу. А вся рота пошла в ногу. И теперь, по истечение нескольких лет, сложилась дурацкая ситуация: огромная организация, 'осваивая' огромные вложения в проект, до сих пор не продвинулась дальше бумажных схем и отчетов,  поскольку не знает, как реализовать написанное. А тот, который 'не в ногу', решив задачу в целом, не может завершить решение 'в частности',  поскольку дальнейшее развитие проекта – работа коллектива, который занят своим безнадежным, но санкционированным проектом.

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

Цитата 3: " ПРОЦЕСС ОБЯЗАН (!) заниматься переработкой данных и созданием НОВЫХ объектов"Давайте разделим условно понятие 'процесс' на два понятия:
А) бизнес-процесс как абстрактное обозначение манипуляций с данными (Ваше представление)
Б) информационный процесс как обозначение конкретного программного модуля, занимающегося получением, сортировкой и отправкой файлов. (мое представление).
Улавливаете разницу? Бизнес процесс как абстрактное понятие может позволить себе объединить функции и переработки и создания новых данных и много еще чего другого. Потому что бизнес-процесс - всего лишь обозначение целого комплекса реальных действий, которые необходимо совершить для выполнения поставленной задачи. И Вам еще предстоит определиться – какими инструментами будут осуществляться эти действия и какими средствами будут управляться эти инструменты. Оказывается, при детализации Вашего понятия процесса мы неожиданно приходим к моему понятию: кто-то производит новый продукт, а кто-то управляет производителем.
В Вашем примере с назначением заготовки: Вы посылаете заявку с параметрами заготовки зав.складом -> зав.склад анализирует параметры и выдает задание рабочему того отделения склада, где хранятся подходящие ТМЦ->рабочий устанавливает ТМЦ на отрезной станок -> станок отрезает требуемую заготовку-> рабочий отправляет заготовка Вам и сообщает зав.складу об исполнении-> зав.склад фиксирует в журнале уменьшение ТМЦ и отправку Вам заготовки.
Обратите внимание, в представленной цепочке практических действий только один элемент занимается созданием нового объекта (заготовки). Это, извините, станок. Все остальные – чистые управленцы – ничего не производят, только командуют. И при этом действуют по единому алгоритму. Так вот, в ядре ЕИП электронный объект 'информационный процесс' олицетворяет всех управленцев вместе взятых. Просто в имена у них на разных участках цепочки разные (заказчик, зав.склад, рабочий и т.д).
И наконец, электронный аналог станка в ЕИП конечно же есть. И не один, а множество. Это тоже лежит всего один электронный объект и называется он 'интерфейс'. В ЕИП он еще определяется как 'генерирующий процесс', поскольку основная его функция – генерация новых данных. Генерирующий процесс в основе своей един (это программный модуль) а функционально – многолик, поскольку управляет набором подчиненных программных модулей, выполняющих определенный набор функций. В Вашем примере – это монитор станка ЧПУ с программой отрезания заготовки. Если Вы составляете заявку на компьютере, то Вы тоже генерируете новый продукт, используя для этого генерирующий интерфейс – текстовый редактор.
В заключение несколько слов об универсальности. Обратите внимание, если вместо заготовки Вы пожелаете получить например, ТУ из НТД, Вас обслужат те же самые электронные объекты, просто установлены они будут не на складе, а в НТД, поименованы будут немного по-другому и манипулировать будут не болванками, а книжками. А если еще внимательнее проанализировать работу например управляющих систем различных уровней, Вы увидите, что подавляющее большинство бизнес-процессов прекрасно укладываются в представленную схему.

[Николай]

Так за чем же дело стало? Имеющийся продукт, ЛОЦМАН, например, не даёт провести натурные испытания вашей системы ЕИП на конкеретом предприятии?

[YorikER]

1. Если взглянуть со стороны, Вы фактически подтвердили мой тезис о том, что ПРОЦЕСС ОБЯЗАН (!) иметь возможность заниматься переработкой данных и созданием НОВЫХ объектов. Просто Вы дали ему другое определение (генерирующий процесс или интерфейс - это не важно). Вы создали свою систему дефиниций, это Ваше право, как разработчика. Лично я смотрю на это несколько подругому. В любом случае все это процессы - т.е. какие-то действия над данными. Согласен с тем, что большинство процессов занимаются транспортировкой и, вместе с тем, все-таки первичной переработкой данных. Но (мое личное убеждение) в общем виде при описании объекта типа ПРОЦЕСС в ядре ЕИП необходимо предоставить данному объекту возможность генерировать новые объекты (лично я бы так и сделал).
2. ЛОЦМАН действительно давно застыл в своем ядре и фактически не развивается. По крайней мере по той информации, которой я владею (речь идет о ядре системы). Здесь я с Вами согласен. Хотя такие заявления необходимо делать с осторожностью, будучи в стороне от разработки системы. Несколько лет назад, когда я активно занимался разработками в среде ЛОЦМАНа, при обсуждении некоторых вопросов с разработчиками, высказывалась мысль о том, что в ядре не хватает базового объекта типа ПРОЦЕСС, на основе которого можно было бы строить более сложные процессы. Но дальше обсуждения дело не пошло. Кроме того в ЛОЦМАНЕ явно не хватает объектно-ориентированной системы моделирования интерфейса с БД. Существующие разработки оставляют желать лучшего. Если Ваши идеи процессного моделирования вложить в ядро ЛОЦМАНа, я думаю, получился бы неплохой и конкурентоспособный IT продукт...
3. По поводу хранения террабайт информации, идея распределенного пространства интересна. Правда есть вопросы безопасности как хранения собственно данных, так и хранения описания (или структуры) данных. Сегодня популярна идея предоставления распределенных виртуальных ресурсов (облака). Собственно система хранения данных и их описание централизованы, но организованы на виртуальных расширяемых по необходимости ресурсах. Вы (если я правильно понял) пошли дальше, предлагаете физически децентрализовать информационное пространство, причем как собственно данных, так и их описания. Насколько это безопасно мне пока трудно судить. Различные фрагменты ЕИП должны друг друга понимать, иметь общие интерфейсы и единую систему описания струтуры данных. При выпадении какого либо фрагмента из цепочки ЕИП может разрушиться.

В любом случае спасибо за дисскусию, за новые идеи и удачи!

[Кузнецов Сергей]

Цитата 1: "... объекту типа ПРОЦЕСС в ядре ЕИП необходимо предоставить возможность генерировать новые объекты

Так он их и генерирует! Просто в ЕИП объектов типа ПРОЦЕСС – ДВА!Тип 1  Процесс информационный управляющий (только управляет перемещением данных/объектов)
Тип2  Процесс информационный генерирующий (только генерирует данные/объекты)
Каждый выполняет свою простую и понятную функцию, а их комбинация дает многообразие вариантов. Когда по ходу построения общего бизнес-процесса нам требуется сгенерировать новые данные\объекты, мы просто ставим типу 1 в подчинение (под управление) нужный вариант типа 2.
В Вашем же непременном желании обьединить эти две функции заложено начало хаоса: По вашему варианту зав.склад должен в своих обязанностях иметь еще и функции рабочего и функции станка и много еще чего другого. А это уже, извините - бардак.

Цитата 2:.. идея распределенного пространства ... предлагаете физически децентрализовать информационное пространство, причем как собственно данных, так и их описания

Я не выдумал данную идею, я ее заимствовал!. Посмотрите на Интернет-пространство,  Где у него центр? Нет у него центра! Но есть система узловых точек разного размера: те, что поменьше – пользователи. Те, что побольше – сервера. Еще побольше – хранилища данных. Но среди этого сообщества нет главных – все примерно равны. А информация хранится именно распределенно. И обрабатывается параллельно. И передается одновременно по множеству маршрутов. Именно поэтому по интернету одновременно и свободно гуляют те самые террабайты данных.
ЕИП является надстройкой над программно-аппаратной структурой интернет-пространства и использует все его возможности по хранению, защите и перемещению данных, даже не замечая этого. Когда я завожу почтовый ящик на интернет-ресурсе, я практически не сомневаюсь в его надежности и совершенно не интересуюсь механизмом его обслуживания. Если засомневаюсь, заведу дублирующий на другом ресурсе. А еще сохраню свои данные на своей ПЭВМ. И тогда, даже если рухнет интернет, в его узловых ПЭВМ сохранятся все данные. Где-то просто собственно данные, где-то структура адресации – у кого что было. Восстановится интернет – запустим программу восстановления ЕИП.

Цитата 3:.. Различные фрагменты ЕИП должны друг друга понимать, иметь общие интерфейсы и единую систему описания структуры данных.

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

[Кузнецов Сергей]

Так за чем же дело стало? Имеющийся продукт, ЛОЦМАН, например, не даёт провести натурные испытания вашей системы ЕИП на конкеретом предприятии?

Перечитайте внимательнее часть диалога по поводу ЛОЦМАНа. Какие натурные испытания, когда ЛОЦМАН не имеет и сотой доли тех функциональных возможностей, которые требуются для организации полноценной ЕИП!

[СВ]

Перечитайте внимательнее часть диалога по поводу ЛОЦМАНа. Какие натурные испытания, когда ЛОЦМАН не имеет ...

Сергей ...вич, поясните, пожалуйста, это (и прочее) что: - критика Лоцмана, попытка отстоять свои взгляды (хотя никто их и не пытается у Вас отнять) или показ своего высокого профессионального уровня, до которого практически никто дотянуться не может? Если кто-то с Вами не согласен, зачем так ожесточённо что-то доказывать, ведь это ВЫ будете делать СВОЮ работу и никто не в силах ВАМ помешать.

[YorikER]

Уважаемый СВ, не нападайте на автора, дискуссия очень интересна и, я думаю, очень полезна, как для авторов ЛОЦМАНа, так и для других разработчиков группы компаний АСКОНа. Автором высказываются идеи, заслуживающие серьезного внимания.
Комментарии:
Цитата 1 - Вопрос снят, либо некорректно написано описание понятия ПРОЦЕССа, либо я не до конца разобрался...

Цитата 2 - Согласен, идея действительно похожа на Интернет-пространство.

Цитата 3 - В таком случае Вы изобретаете велосипед, который уже давно создан. И называется он - Microsoft Office. Расскажу о реальном опыте. Достаточно давно я посетил одно из предприятий Урала. В одном из подразделений руководство не стало создавать никаких IT систем. Просто описали производственный документооборот, создали шаблоны необходимых документов в Word и Excel, организовали структурированное хранилище папок в сети, правило создания и пересылок конечных документов от пользователя к пользователю, систему макросов транспортирования и первичной обработки информации из документа в документ - и все заработало. Несколько сложно, иногда сумбурно, но абсолютно реально. И самое главное, что документо- и, соответственно, информационный оборот достаточно легко был воспринят реальными юзверями на производстве. Конечно, надо отметить, что когда они дошли до аналитических, прогнозных задач, а также к вопросам интеграции с другими средами, система оказалась довольно-таки громоздкой и трудно осязаемой (хотя я думаю, что можно все вопросы решить). Такой опыт реально был, и я лично читал инструкции по организации документооборота на рабочих местах. Причем все это было сделано непосредственно менеджментом подразделения. Как первый шаг к созданию собственной ЕИП данный вариант был очень интересен! Стоит ли ломать копья, в Office все инструменты информационного обмена есть в наличии...

[Кузнецов Сергей]

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

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

[Кузнецов Сергей]

Сергей ...вич, поясните, пожалуйста, это (и прочее) что: - критика Лоцмана, попытка отстоять свои взгляды

Не обижайтесь, я вовсе не имею целью принизить достоинства ЛОЦМАН как программного продукта. Он занимает достойное место в сообществе информационно-поисковых систем, постоянно совершенствуется и это похвально. Но надо иметь мужество признать – он уже старенький! Средний срок жизни сложного программного комплекса не превышает 10-15 лет. Затем начинается моральное устаревание. Приходят новые методы программирования, а программное ядро (и главное, архитектура модели) остаются практически неизменными. Это вполне естественно. Только сумашедший решится вносить кардинальные изменения в сердце работающего сложнейшего организма – последствия скорее всего будут фатальными. Единственный доступный путь – попытаться продлить срок жизни проекта за счет косметических доработок, изменений и улучшений. Это на какое-то время поможет, но только на время. Ведь сколько не наноси макияжа на старушку, обратно девочкой она все равно не станет. Это не вина разработчиков, это проявление всеобщего закона жизни – все, что когда-то было рождено, рано или поздно должно умереть. Это общее свойство всех достаточно поживших программных продуктов (включая и WINDOWS). Посмотрите на последние версии уважаемых программных комплексов – растет их объем, усложняется (а значит- ухудшается) интерфейс, и главное, все чаще нарушается краеугольный принцип замещения ПО – новые версии все чаще становятся функционально несовместимыми со старыми данными. Я считаю данное явление признаком окончания этапа эволюционного развития ПО. Приближается момент эволюционного скачка: на основе новых моделей и платформ программирования, с учетом всего накопленного опыта, должно быть создано качественно новое ПО – компактнее, надежнее, эффективнее.

А раздражение действительно есть, только причиной его является не сам ЛОЦМАН, а то, как его собираются использовать. Если Вы не в теме, вкратце поясню суть вопроса.

Существует большой проект, претендующий на статус 'прорывного'. Название его мало соответствует его сути, поэтому я называю его проектом по созданию типовой модели 'Электронное предприятие' (по аналогии с Медведевским "Электронным правительством").

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

1. И ЛОЦМАН и ARIS и большинство других компонентов проекта являются программными комплексами на 'ручном' управлении, поскольку просто не предназначены для автоматического функционирования в режиме реального времени.
Вопрос: какой процент автоматизации можно обеспечить с их помощью?

2. Количество рабочих мест моделируемого объекта измеряется тысячами, количество информационных процессов – десятками тысяч. Из п.1 следует, что практически в каждом элементе будущей модели должен присутствовать человеческий фактор, выполняющий по нескольку процедур для реализации возложенных на него функций.
Вопрос: каковы будут надежность и быстродействие при таком управлении?
В каждый этап информационного процесса, это, как правило, новый вид манипуляции с данными, т.е. привлечение нового вида программного обеспечения со своей внутренней структурой данных. Для согласования потоков данных в таких случаях нужны программные конверты данных. Любой конвертор по сути своей является интерпретатором данных (выражаясь проще – переводчиком с одного языка на другой). При переводе всегда возможны ошибки и неточности. Если количество информационных процессов исчисляется десятками тысяч, количество этапов в каждом может варьироваться от единиц до сотен, то даже если количество сбоев при конвертировании будет 1:100, суммарное число сбоев только при передаче данных будет измеряться в десятках тысяч.
Вопрос: насколько стабильна и управляема будет модель?

3. Вертикально-ориентированная архитектура с централизованным хранением данных – тип  модели, реализуемый  в официальном проекте. Данная архитектура предполагает существенную нагрузку на вычислительную сеть и на серверные ресурсы системы. Рассредоточение и дублирование хранилищ данных вряд ли даст значительный эффект как с точки зрения снижения вычислительной нагрузки, так и нагрузки на линии передачи данных.
Вопрос: Сможет ли аппаратно-программные средства обеспечить движение террабайтов данных через ограниченное число узловых элементов централизованной  модели. И что будет c системой в случае уничтожения центральных хранилищ данных?
Это только проблемы общего плана! А есть еще проблемы локальные. Например, как решать проблему конфиденциальности данных, которые в начале проектирования не имеют грифа, но далее, в процессе, при слиянии по совокупности приобретают гриф, а затем, разделяясь, частично вновь его теряют.

Любопытно, что внятного ответа ни на один из перечисленных здесь вопросов ни у идеологов, ни у исполнителей, мне получить не удалось. Может быть Вы можете что-то сказать по этому поводу? Буду благодарен!
С уважением, Сергей Алексеевич, к Вашим услугам.

P.S. Не подскажете, как оформить на форуме текстовой блок в скрытом виде, оставляя только строку-заголовок с крестиком? Я в этой кухне новичек...

[СВ]

 Вы говорите, что  руководство хочет создать "...модель самого предприятия, со всеми сотрудниками, службами и подразделениями, с системой взаимоотношений на всех уровнях, со всеми информационными, финансовыми, материальными и другими потоками, ежесекундно циркулирующими в его недрах".
Навскидку предполагаю, что такого дела ВСЕ сотрудники должны будут ПОСТОЯННО отмечаться в системе о каждом своём действии. Простой (очень простой) пример: сгорел эл/двигатель, цеховой человек должен подать эл-ю заявку на ремонт, ремонтник должен подать заявку на склад, склад - снабженцам, снабженцы - купить и привезти (заявки в бухгалтерию и др.), сообщить о покупке по нисходящей и пр., пр., пр. В конце "пути" цеховик ставит "резюме" - вопрос закрыт. Если хотя бы примерно так, то это будет похоже на современных врачей, которые большую часть времени пишут бумаги.
ОсноВНЕЙШАЯ проблема возникнет на начальном этапе. Т.к. ВСЕ "игроки" должны отмечаться в системе, то они и будут слабым звеном: пока хоть мало-мальски обучатся, неразбериха попьёт столько крови (бардак плюс потери времени и на работу в системе и на разгребание бардака), что бросят это дело на полпути. Ну, а если руководство упёртое, то переделают систему и оставят только жизненно важное.
НО ГЛАВНОЕ: какую бы систему супер-пупер отличную Вы не сделаете, она точно также на этапе внедрения будет "пить кровь". И проблемы будут объясняться не слабой квалификацией персонала, а Вашими недоработками.
Единственный реальный хороший (более-менее) вариант: когда руководство и Вы - в одной связке. Но этого же нет?

[tramp_m]

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

[Кузнецов Сергей]

Навскидку предполагаю, что такого дела ВСЕ сотрудники должны будут ПОСТОЯННО отмечаться в системе о каждом своём действии. Простой (очень простой) пример: сгорел эл/двигатель, цеховой человек должен подать эл-ю заявку на ремонт, ремонтник должен подать заявку на склад, склад - снабженцам, снабженцы - купить и привезти (заявки в бухгалтерию и др.), сообщить о покупке по нисходящей и пр., пр., пр. В конце "пути" цеховик ставит "резюме" - вопрос закрыт.

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

Разница в том, что Ваш вариант базируется на схеме ручного управления процессами, когда в каждой точке сидит человек (слабое звено) - отсюда затяжки, непонятки, проволочки, тот самый бардак.

В нашем варианте слабого звена вообще нет, а есть набор достаточно простых, но 'умных' программных модулей, умеющих самостоятельно открывать пришедшую почту и читать содержащиеся в ней сообщения. В Вашем случае ключевые слова сообщений достаточно просты: сгорел мотор марка ххххх, заказать мотор марка ххх, купить(оплатить) мотор маркаххх.
Я утрирую конечно последовательность действий и команд, но принцип понятен, да?. Это абсолютно реально выполнимая схема. Участие человека - только на этапе снятия/установки движка.
Согласитесь, здесь уже никакого бардака нет (если опять где-то не влезет ручками слабое звено)

[Кузнецов Сергей]

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

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

[Алхимик]

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

Человек настраивает эти линии? Или программа для управления производством генерируется автоматически?

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