Вопросы и ответы
ГИПЕРГРАФ
Как строится граф?
Модель знаний описывается в виде однорангового гиперграфа большой размерности, который коллективно конвергентно (сходимо, обеспечивая единое и целостное пространство описания) проектируется специалистами разных областей знания. Описание языка представлено в «Теории эволюционного моделирования», стр. 28-51. Методы и примеры моделирования представлены в видео.
В какой среде?
Разработано специализированное программное обеспечение (#Гиперграф:Платформа) со встроенными инструментами визуального совместного описания (проектирования) произвольной области знаний:
1). начинается проектирование с использования инструмента позволяющего выбрать необходимую базовую абстракцию (форма и/или содержание и/или поведение), как фрактал и от него отнаследовать предметную сущность.
Например, для медиков.
Описание предметной сущности – «условная болезнь» и «человеческий орган» начинается с
формирования реестра болезней и реестр органов (это и содержание, и форма, и поведение), для этого
выбирается онтокласс типа Реестр
(см. «Теорию эволюционного моделирования»), который уже включает знания о базовых свойствах
(параметры (характеристики) и методах (алгоритмы / математические операции) любого реестра: код
сущности (ручной ввод или автоувеличение с определенным методом), название сущности полное,
название сущности краткое, темпоральные характеристики, толкование, этимология, аббревиатура,
визуальный символ, группу статусов для алгоритмической обработки, системные параметры для
алгоритмической обработки и т.п.
2). после выбора базового онтокласса запускается инструмент «Наследовать», который в автоматическом режиме формирует две новые предметные сущности, в которой специалист вводит только их семантические названия,
Например, для медиков.
В отнаследованной модели поля заполняются значениями о болезнях и органах.
3). для описания связности знаний о предметных сущностях используется инструмент описания
связей структуризации и синтеза (см. «Теорию эволюционного моделирования»). Связь проектируется визуальным редактором путем перетаскивания и наложения одного класса на другой.
Например, для медиков.
Реестр болезней может быть структурно связан с классом классификаторы и синтетически связан с реестром органов.
4). при использовании перечисленных редакторов с 1 по 3 автоматически формируется структура хранения данных по их параметрам и связям, формы ввода и отображения данных и методы обработки данных (запускаются автономно и в форме). Также Специалист может на свой вкус с помощью соответствующих редакторов изменить и формы, и методы.
5). Специалист может запустить быструю операцию (автоматическое программирование) практического применения спроектированной модели для ввода и обработки исходных данных.
Например, для медиков.
Специалист заводит в форму конкретную болезнь и связанные с ней органы либо может завести орган и описывать связанные с ним болезни. Далее повторяя пп. 1-5 специалист может развивать модель знаний, например, симптоматики, диагностического оборудования, параметры анализов и т.п.
6). Специалист на Модели знаний может создать контейнеры (группы онтоклассов) для различных типов конечных пользователей, которые будут развивать модель знаний своими данными.
Например, для медиков.
Контейнер врача, студента, интерна, заведующего отделением, больного и т.п.
7). граф обладает встроенной системой информационной безопасности, которая определяет и документирует все действия всех пользователей, на этом построена система определения авторства изменения/дополнения моделей знаний.
Все эти пункты более полно описаны в руководстве пользователя, руководстве системного аналитика и руководстве системного администратора.
Чем определяются узлы, если у них нет названий и привязки к объектам?
Узлы графа на каждом уровне архитектуры их наследования имеют различное смысловое содержание. Привязка предметных сущностей каждому узлу происходит на предметно-ориентированном уровне проектирования модели знаний (см. пример выше).
Как определяются связи, особенно мультисвязи?
Связи семи типов – бинарные:
Связи проектирования классов:
1) Наследование.
Связи структуризации классов (соединяют классы одного типа):
2) Связи классов типа содержание-содержание (С→С).
3) Связи классов типа форма-форма (Ф→Ф).
4) Связи классов типа поведение-поведение (П→П).
Связи синтеза классов (соединяют классы различных типов):
5) Связи классов типа содержание-форма (С↔Ф).
6) Связи классов типа содержание-поведение (С↔П).
7) Связи классов типа форма-поведение (Ф↔П).
Связи трёх типов – множественные.
1.Контейнеры проектирования.
2.Контейнеры использования (Рабочие столы).
3.Контейнеры управления событиями.
Какой объем необходим, чтобы описать предметную область?
Минимальный объем знаний предметной области уже позволяет положить начало описания его в модели знаний, начиная, например со слов, их понятий и определений.
Если граф целостный и накапливаемый вами, то каков сейчас его объем?
Граф Модели знаний содержит примерно 100 000 узлов (каждый узел более 10 свойств (параметров и методов)), 2 млрд связей и много миллиардов записей данных.
Какой формализм используется, чтобы по графу могла производиться разработка ПО?
Этому посвящены РКД к #Гиперграф:Платформа, а также книги «Теория эволюционного моделирования», Конец информационного общества, Робот по программированию.
Что именно делается в автоматическом режиме: проектирование или конструирование или разработка ПО, наполнение базы знаний для работы?
В автоматическом режиме делаются:
С какими объектами работает ПО на основе гиперграфа?
С любыми.
В какой структуре хранятся объекты, если гиперграф не работает с сущностями, а только с классами?
Объекты могут быть неструктурированные, слабоструктурированные, структурированные, вектор, вектор с геопривязкой и т.п. с соответствующим хранилищем и СУБД.
Можно ли экспортировать онтологию из гиперграфа?
Из #Гиперграф:Платформа можно экспортировать данные в любые форматы.
Можно ли ее туда импортировать?
Есть специальный инструмент #Гиперграф:Интегратор для импорта данных.
Есть ли визуализация гиперграфа?
Есть. Пример можно посмотреть на видео.
Что (какой артефакт) является результатом построения системы в конструкторе? Скомпиллированый байт-код для некой виртуальной машины (какой?), исходный код (на каком языке?), исполняемый код (под какую операционную систему?), код на неком языке описаний (каком?).
Результатом работы аналитиков на #ГиперГраф:Платформе является:
модель на #ГиперГраф:Языке и исполняемый код #ГиперГраф:Система под операционные системы Unix, Windows, Linux,..
Сетецентрическая архитектура - YouTube
Проектирование и Автоматическое программирование - YouTube
Безопасность сетецентрической системы - YouTube
Робот программ (ПО) | ГиперГрафГрупп (gipergraf.ru)
Как этот артефакт деплоится, куда (сервер приложений?). Система централизована, т.е. все клиенты деплоятся в некое облако, которое держит вендор или есть возможность установки локальной версии у заказчика?
#ГиперГраф:Платформа включает свой сервер приложений и свой сервер блокировок. Клиенты могут работать с облаком, которое может держать вендор, франчайзи (партнёр) или клиент (заказчик).
Если есть возможность установки у заказчика, то какие требования по железу? Какой сёрд-пати софт необходим (база данных, библиотеки шифрования, сервера приложений)?
https://disk.yandex.ru/i/qRWloj0yGshVbA
Есть ли встроенные механизмы масштабирования, резервирования, бэкапов?
Есть встроенные механизмы масштабирования. Резервирование и бэкапирование делается средствами ОПО.
Есть ли API? Какая реализация?
Только для взаимодействия с внешними системами есть специальное руководство по видам и методам интеграции #ГиперГраф:Интегратор.
Какие есть встроенные средства разработки адаптеров для легаси систем?
См. ответ на вопрос: Есть ли API? Какая реализация?
Какие протоколы доступа и взаимодействия с внешними системами поддерживаются? Какие средства шифрования данных?
См. ответ на вопрос: Есть ли API? Какая реализация?
HASP-ключи
Какие протоколы доступа к самой системе?
Вопрос не корректен.
Что собой представляет пользовательский интерфейс — толстый, тонкий клиент?
Оба варианта реализации.
Есть ли возможность внесения изменений в систему каким-то способом отличным от дизайнера кодогенератора?
Нет, только изменением модели, в противном случае теряется обратимость, изоморфность и релевантность модели и самой системы.
Правильно ли утверждение, что любой новый класс – новая таблица в БД (база данных). Любой новый класс с наследованием – новая таблица в БД со внешними ключами, ссылающимися на класс (таблицу) базового класса.
Нет, новый класс может быть таблицей БД, формой, процедурой. Все классы в модели наследуются от соответствующих классов родителей, то есть в них есть ссылка на родителя плюс добавленные свойства (параметры, методы) и связи с другими классами.
Создание класса с наследованием влечет за собой формирование нового класса (таблицы) с копированием полей из родительского класса (классов) или же используются только ссылки на родительские классы?
Только ссылки.
Если используется ссылка на родительский класс, то при создании нового объекта (записи в таблицу) соответствующих образом заполняется (создаются требуемые объекты) все по иерархии “вверх” (от текущего класса формируются объекты во всех родительских-псевдородительских классах по цепочке наследования)?
Запись в таблице вообще не является ни классом, ни объектом, - используются совсем другие принципы (не путать с примитивами онтологий и семантических сетей). Гиперграф не про данные, а про мета уровень описания систем. Реализована иерархическая ссылка по дереву наследования у всех видов классов.
При введении 9 базовых классов (Руководство_системного_аналитика_Часть_1_Основы_работы_в_системе, стр. 16) вводится понятие “Универсальный класс”: Универсальный класс служит для обобщенного представления в модели непознанных на момент проектирования, не специфицированных сущностей. Является ли это полностью пустым классом, порождающим огромное количество новых классов при любом неизвестном (когда мы не можем сопоставить структуру входных данных с любым из существующих классов в системе) классов? Является ли наследование от универсального класса просто флагом того, что для нас это неизвестная сущность?
Универсальный класс является основой для исследования и обобщения опыта реализации новых специфических задач, он нужен для развития системы базовых классов и реализации управления жизненным циклом техническими требованиями и изменениями технических требований. Да, верно, это флаг и этот механизм используется для научных опытов и познания нового, результатом является новый предметно-ориентированный класс рекомендованный к общему использованию, реализацией эволюционного прироста модели гиперграфа.
При принадлежности нескольких подклассов классу “Универсальный класс” и наличию данных, которые структурно подходят под несколько подклассов (любой вложенности в рамках базового класса УК), как выбирается принадлежность данных классу?
Нельзя рассуждать о классах как о данных – у нас другой уровень описания смыслов, которые включают предельную совокупность описания через содержание, форму и поведение. Только наш подход позволяет смотреть на, кажется, несвязанные данные, как на связанные через какую-либо составляющую(ие), так в одноранговой сети гиперграфа оказываются взаимоувязаны: таракан, труба и партия «Клоунов».
Как, когда и при каких условиях возможно расширение/сужение/замена базовых классов? Структура и методы базовых классов формируются на первичном этапе проектирования системы или идут “из коробки”?
В ходе проектирования и накопления опыта повторяемые свойства в наследуемых классах могут всплывать по дереву наследования в базовые-родительские классы. За 25 лет производилась лишь нормализация свойств базовых классов, которые тут же становились частью всех отнаследованных. Каждый класс, который многократно используется в исполняемой модели по сути сам становится базовым классом, при этом совокупность классов называется онтоклассом, так, например, онтокласс – классификатор, при композиционном наследовании автоматически наследует следующую совокупность: класс содержания, класс ввода, класс запроса, класс процедуры, класс отчета и все они начинают работать всей совокупностью, что кратно сокращает усилия и исключает ошибки при создании модели. Такой механизм позволяет архитектору сформировать технические требования к системе в виде набора специализированных базовых классов, а системные аналитики работают в этих требованиях.
Какая логика работы системы при изменении одного из родительского-прародительского класса (удаление/добавление/изменение полей, удаление/добавление/изменение методов)? Действительно ли любое изменение порождает новую ветвь графа со всеми классами-потомками?
В системе ничего не удаляется ни свойства классов, ни классы, все они остаются как исторические, теряя связность, кроме наследования. Таким образом, в модели можно одновременно увидеть все три состояния: историческое, актуальное и прогнозное. В модели нет множественного наследования (родителей >1), реализовано композиционное наследование логически связанной совокупности классов. Изменения могут быть в свойствах имеющегося класса, добавлением нового класса, в связях структуризации и синтеза. Только новый класс порождает новый лист гиперграфа, этот лист может стать ветвью.
Как фиксируется для пользователя различие в разных версиях одного и того же класса, когда изменения, внесенные в родительский класс, несут изменение структуры для последующих сущностей классов-потомков? Как ведут себя формы при изменениях (вынуждены ли мы будем изменять вручную каждую из форм, которая теперь не отображает не ту информацию или имеет недостаточно информации).
Пользователь получает новые требуемые возможности. Есть быстрые операции, которые добавят новый параметр в форму по умолчанию, однако, если данное положение параметра в форме требуется переместить это можно очень быстро сделать с помощью редактора.
Формируются ли промежуточные классы-прототипы автоматически при компиляции?
Нет. Все классы делятся на проектируемые и исполняемые, последние для #Гиперграф:РоботПО выкладываются на рабочие столы. Всё, чего нет на рабочих столах, не компилится и не генерится, таким образом из большой модели можно выбрать подграф любой размерности и реализовать маленькую функциональную задачу.
Как построена работа с динамической информацией, поступающей извне? Возможно ли получение, структуризация и внесение данных в систему со сторонних сервисов в текущей реализации? Возможно ли подключение сторонних источников информации, требующих криптозащиту (либо любые другие закрытые протоколы получения информации). Например: связь с СДО, интеграция с 1С уровнем выше прямого подключения между БД и обмена файлами, СМЭВ.
Реализовано 5 основных методов интеграции с внешними системами, включая описание проекций внешних БД систем и использование данных внешних систем на чтение в режиме реального времени.
Есть ли у #Гиперграф:Платформы собственные вэб-службы? Есть ли разграничение между ними – открыты для интернета/существуют в рамках закрытого контура сети?
Есть веб-классы и редактор веб-форм в зачаточном состоянии.
Как реализован процесс миграции данных с существующих систем и сервисов, которыми пользуется заказчик, в систему?
Этот процесс начинается с конвертации хаотических данных внешних систем в нашу систему, далее инструментами нашей платформы делаются: нормализация, систематизация, структуризация, устранение избыточности, унификация, классификация, синхронизация и т.п. данных.
Отличается ли принцип работы и формирования виртуальных методов в рамках системы от классических виртуальных методов в ООП?
Да. Есть ряд отличий.
Является ли список типов, используемых в системе (указаны в Руководство системного аналитика Часть 1 Основы работы в системе стр. 95–96), полным? Как решаются типичные проблемы типа money при агрегации и других математических операциях? Как решаются типичные проблемы типов в с плавающей запятой?
При агрегации данных типа money используются ряд методов округления, их можно посмотреть в реализованных моделях.
В презентационных материалах одним из преимуществ продукта обозначается платформа G3 (GGG), которая подразумевает сообщество по всему миру, которое независимо друг от друга может создавать модули системы для интеграции в свои системы. На каких принципах строится это сообщество, как оно регулируется и как строится процесс разработки модулей в нем?
Есть понятие транзакций коллективного проектирования и конвергенции модели, которые являются одним из ключевых достоинств нашего подхода.
Возможна ли интеграция и внедрение модулей из других систем, работающих на #Гиперграф, в свою?
Возможна, но мы предлагаем проектировать у нас классы содержания и форм, а подключать внешние процедуры, например, уникальный датамайнинг, генетический алгоритм, метод свёртки, матлаб, нейронные сети и т.п. (особенно, если автор не хочет раскрывать метод).
На чьей стороне происходит проработка предметной области?
Системный аналитик погружается в предметную область и по предлагаемой нами методологии создания сетецентрических систем управления и производит полную цифровую трансформацию предметной области. Все, кто имеет, дизайнер независимы в проработке предметной области.
На чьей стороне происходит конфигурирование первичной, готовой к работе, конфигурации системы? На чьей стороне происходит изменение и обслуживание системы (создание новых классов, объектов, отображений и т. д.)
Любой вариант конфигурирования доступен при наличии платформы.
Если анализ плюсов и минусов функционала иностранных ERP систем и отечественных?
Есть большие объемные отчеты, в том числе внешних экспертов (Гартнер, IBM, ЦБ, Минобороны, Минфини др.).
Как оптимизируется БД, как происходит ее обслуживание? Есть ли перекрестный контроль за действиями администратора базы данных?
Администратор БД не требуется так как #Гиперграф:РоботПО автоматически с использованием генератора случайных чисел поддерживает целостность БД по таблицам, параметрам и записям. Отделенная от платформы БД не поддается дешифрации в разумные сроки. Вместе с этим мы исследуем процессы самоорганизации в эволюции БД при коллективной работе системных аналитиков.
Функционирование системы возможно только на Oracle/mssql server? Есть ли возможность миграции на open source решения?
Возможна миграция на любые реляционные БД, в частности были продажи на SYBase, Informics.
Какие иностранные решения/модули/системы используются в общей конфигурации Эталона в контексте импортозамещения и отечественно ПО?
Визуализатор гиперграфа Tom Soyer и пакеты для графического представления данных в зависимости от требований заказчика, например, MSGraph.
Примеры проблем текущих ERP систем, которые пропадают при использовании #Гиперграф?
Есть, см. приложение.
Что происходит с классами, которые перестали использоваться или стали ненужными по причине изменения конфигурации системы? (в рамках эволюционной модели можно обозвать это к умершему пути в графе/тупиковая ветвь развития, по которой уже нет активных объектов и которая не нужна).
Это наше уникальное преимущество и свойство гиперграфа: хранение полного жизненного цикла модели даёт возможность его осмысления, изучения и прогнозирования развития.
Есть ли тестовая среда или тренажер? Если да, то какие кейсы можно там посмотреть и в каком порядке возможно получить доступ к тестовой среде/тренажеру?
Есть, #Гиперграф:Государство (включает около 60 000 взаимоувязанных таблиц БД, 100 000 уникальных параметров и 2 000 000 000 связей и несколько миллионов записей в контрольном примере) и #Гиперграф:Корпорация (сопоставим по размеру с #Гиперграф:Государство). Предложено обучение при совместной реализации проекта.
Какие цели и задачи взаимодействия ООО «ГиперГрафГрупп» с Минпромторгом России?
Основной целью взаимодействия ООО "ГиперГрафГрупп" с Минпромторгом России является создание остроактуального глобально-масштабируемого прорывного цифрового продукта нового поколения: российской цифровой Системы управления транснациональной корпорацией (далее – ТНК) на основе новых графо-центричных принципов и технологий.
Данный продукт должен обеспечивать комплексное сбалансированное управление диверсифицированной деятельностью ТНК (включая задачи класса ERP & ESG & другие управленческие функции).
Все лидирующие сегодня международные и российские решения, представленные на глобальном и национальном рынке, не удовлетворяют требованиям реализации эффективной системы управления ТНК. В настоящее время объективная оценка позиции Российской Федерации и предпринимаемых шагов в этих направлениях – крайне негативная. При этом, большинство глобальных продуктов создавалось с участием программистов «Русского мира».
Новый продукт должен обеспечить лидерство, геополитическое доминирование, технологическое превосходство и преимущество над архаичными «лоскутными» зарубежными решениями и отвечать следующим фундаментальным критериям:
Реализация стратегических целей и успешное выполнение управленческих задач в настоящих условиях требует получения объективной транспарентной целостной картины текущей и прогнозной ситуации предприятий.
Одной из новых специфических особенностей нового продукта являются инновационные принципы «мобильного» управления организационно-правовой структурой холдинга без замены цифровой системы управления.
Любую компанию или часть компании графо-центричная Модель и Система управления может информационно (прогнозно или по фактическим данным) поглотить, выделить, объединить, преобразовать, продать. Предлагается обеспечить облегченную работу с комплексом юридических лиц, филиалов, обособленных структурных единиц и внутренних структур.
При этом причинами реформы правовой и организационной структуры могут быть: изменение системы владения, финансово-экономическое обоснование, производственно-технологическая оптимизация, требования безопасности, налоговая оптимизация, специфика госзаказчика, ГОЗа, мобрезерва, отношений по ВТС и многие другие.
Уникальность предлагаемых подходов и цифровых продуктов имеет глобальный потенциал спроса.
Какие результаты планирует ООО «ГиперГрафГрупп» от взаимодействия с Минпромторгом России?
Минпромторг России рассматривается как Стратегический Партнёр совместного инновационного инвестиционного цифрового проекта и, в то же время как базовый пилотный проект практической реализации (управление министерством, отраслью, группой промышленных предприятий) новых управленческих подходов и высокоинтеллектуальных цифровых графо-центричных технологий.
Продвижение и внедрение графо-центричной Системы управления предполагается на следующих группах предприятий:
Предлагаемый Стратегический проект ориентирован также на достижение цели, определенной Указом Президента Российской Федерации от 7 мая 2018 г. № 204 в части решения задач и достижения стратегических целей по направлению «Цифровая экономика», и реализацию Национальной программы «Цифровая экономика Российской Федерации» (паспорт которой утверждён президиумом Совета при Президенте РФ по стратегическому развитию и национальным проектам, протокол от 04.06.2019 № 7). Следовательно, дополнительными источниками софинансирования могут быть бюджетные субсидии и гранты.
Стратегический проект может быть осуществлен в рамках государственных программ Российской Федерации «Информационное общество», «Экономическое развитие и инновационная экономика» и других государственных программ Российской Федерации, включая отраслевые государственные программы субъектов Российской Федерации по направлениям:
Правообладатели: ООО "ГиперГрафГрупп" и частные лица.
Ценовая политика зависит от поставляемого функционального состава, количества конкурентных лицензий и услуг по жизненному циклу создания системы управления.
Перечень заказчиков, эксплуатирующих технологические решения ООО «ГиперГрафГрупп» с кратким описанием решаемых прикладных задач (автоматизируемых функций).
Реализованные проекты.pdf — Яндекс.Диск (yandex.ru)
Конкурентные преимущества технологических решений ООО «ГиперГрафГрупп» в общем виде, а также прикладные применения с ближайшими аналогами, доступными на рынке.
Анализ и оценка традиционных цифровых платформ и инновационных графо-центричных цифровых платформ по следующим ключевым критериям:
Модель знаний описывается в виде однорангового гиперграфа большой размерности, который коллективно конвергентно (сходимо, обеспечивая единое и целостное пространство описания) проектируется специалистами разных областей знания. Описание языка представлено в «Теории эволюционного моделирования», стр. 28-51. Методы и примеры моделирования представлены в видео.
В какой среде?
Разработано специализированное программное обеспечение (#Гиперграф:Платформа) со встроенными инструментами визуального совместного описания (проектирования) произвольной области знаний:
1). начинается проектирование с использования инструмента позволяющего выбрать необходимую базовую абстракцию (форма и/или содержание и/или поведение), как фрактал и от него отнаследовать предметную сущность.
Например, для медиков.
Описание предметной сущности – «условная болезнь» и «человеческий орган» начинается с
формирования реестра болезней и реестр органов (это и содержание, и форма, и поведение), для этого
выбирается онтокласс типа Реестр
(см. «Теорию эволюционного моделирования»), который уже включает знания о базовых свойствах
(параметры (характеристики) и методах (алгоритмы / математические операции) любого реестра: код
сущности (ручной ввод или автоувеличение с определенным методом), название сущности полное,
название сущности краткое, темпоральные характеристики, толкование, этимология, аббревиатура,
визуальный символ, группу статусов для алгоритмической обработки, системные параметры для
алгоритмической обработки и т.п.
2). после выбора базового онтокласса запускается инструмент «Наследовать», который в автоматическом режиме формирует две новые предметные сущности, в которой специалист вводит только их семантические названия,
Например, для медиков.
В отнаследованной модели поля заполняются значениями о болезнях и органах.
3). для описания связности знаний о предметных сущностях используется инструмент описания
связей структуризации и синтеза (см. «Теорию эволюционного моделирования»). Связь проектируется визуальным редактором путем перетаскивания и наложения одного класса на другой.
Например, для медиков.
Реестр болезней может быть структурно связан с классом классификаторы и синтетически связан с реестром органов.
4). при использовании перечисленных редакторов с 1 по 3 автоматически формируется структура хранения данных по их параметрам и связям, формы ввода и отображения данных и методы обработки данных (запускаются автономно и в форме). Также Специалист может на свой вкус с помощью соответствующих редакторов изменить и формы, и методы.
5). Специалист может запустить быструю операцию (автоматическое программирование) практического применения спроектированной модели для ввода и обработки исходных данных.
Например, для медиков.
Специалист заводит в форму конкретную болезнь и связанные с ней органы либо может завести орган и описывать связанные с ним болезни. Далее повторяя пп. 1-5 специалист может развивать модель знаний, например, симптоматики, диагностического оборудования, параметры анализов и т.п.
6). Специалист на Модели знаний может создать контейнеры (группы онтоклассов) для различных типов конечных пользователей, которые будут развивать модель знаний своими данными.
Например, для медиков.
Контейнер врача, студента, интерна, заведующего отделением, больного и т.п.
7). граф обладает встроенной системой информационной безопасности, которая определяет и документирует все действия всех пользователей, на этом построена система определения авторства изменения/дополнения моделей знаний.
Все эти пункты более полно описаны в руководстве пользователя, руководстве системного аналитика и руководстве системного администратора.
Чем определяются узлы, если у них нет названий и привязки к объектам?
Узлы графа на каждом уровне архитектуры их наследования имеют различное смысловое содержание. Привязка предметных сущностей каждому узлу происходит на предметно-ориентированном уровне проектирования модели знаний (см. пример выше).
Как определяются связи, особенно мультисвязи?
Связи семи типов – бинарные:
Связи проектирования классов:
1) Наследование.
Связи структуризации классов (соединяют классы одного типа):
2) Связи классов типа содержание-содержание (С→С).
3) Связи классов типа форма-форма (Ф→Ф).
4) Связи классов типа поведение-поведение (П→П).
Связи синтеза классов (соединяют классы различных типов):
5) Связи классов типа содержание-форма (С↔Ф).
6) Связи классов типа содержание-поведение (С↔П).
7) Связи классов типа форма-поведение (Ф↔П).
Связи трёх типов – множественные.
1.Контейнеры проектирования.
2.Контейнеры использования (Рабочие столы).
3.Контейнеры управления событиями.
Какой объем необходим, чтобы описать предметную область?
Минимальный объем знаний предметной области уже позволяет положить начало описания его в модели знаний, начиная, например со слов, их понятий и определений.
Если граф целостный и накапливаемый вами, то каков сейчас его объем?
Граф Модели знаний содержит примерно 100 000 узлов (каждый узел более 10 свойств (параметров и методов)), 2 млрд связей и много миллиардов записей данных.
Какой формализм используется, чтобы по графу могла производиться разработка ПО?
Этому посвящены РКД к #Гиперграф:Платформа, а также книги «Теория эволюционного моделирования», Конец информационного общества, Робот по программированию.
Что именно делается в автоматическом режиме: проектирование или конструирование или разработка ПО, наполнение базы знаний для работы?
В автоматическом режиме делаются:
- быстрые операции проектирования классов и онтоклассов модели знаний (форма, содержание, поведение) как фракталов,
- разработка исполняемого ПО,
- наполнение базы знаний от аналого-цифровых преобразователей,
- обработка данных, запускаемая по темпоральным и другим условиям,
- контролируются все действия.
С какими объектами работает ПО на основе гиперграфа?
С любыми.
В какой структуре хранятся объекты, если гиперграф не работает с сущностями, а только с классами?
Объекты могут быть неструктурированные, слабоструктурированные, структурированные, вектор, вектор с геопривязкой и т.п. с соответствующим хранилищем и СУБД.
Можно ли экспортировать онтологию из гиперграфа?
Из #Гиперграф:Платформа можно экспортировать данные в любые форматы.
Можно ли ее туда импортировать?
Есть специальный инструмент #Гиперграф:Интегратор для импорта данных.
Есть ли визуализация гиперграфа?
Есть. Пример можно посмотреть на видео.
Что (какой артефакт) является результатом построения системы в конструкторе? Скомпиллированый байт-код для некой виртуальной машины (какой?), исходный код (на каком языке?), исполняемый код (под какую операционную систему?), код на неком языке описаний (каком?).
Результатом работы аналитиков на #ГиперГраф:Платформе является:
модель на #ГиперГраф:Языке и исполняемый код #ГиперГраф:Система под операционные системы Unix, Windows, Linux,..
Сетецентрическая архитектура - YouTube
Проектирование и Автоматическое программирование - YouTube
Безопасность сетецентрической системы - YouTube
Робот программ (ПО) | ГиперГрафГрупп (gipergraf.ru)
Как этот артефакт деплоится, куда (сервер приложений?). Система централизована, т.е. все клиенты деплоятся в некое облако, которое держит вендор или есть возможность установки локальной версии у заказчика?
#ГиперГраф:Платформа включает свой сервер приложений и свой сервер блокировок. Клиенты могут работать с облаком, которое может держать вендор, франчайзи (партнёр) или клиент (заказчик).
Если есть возможность установки у заказчика, то какие требования по железу? Какой сёрд-пати софт необходим (база данных, библиотеки шифрования, сервера приложений)?
https://disk.yandex.ru/i/qRWloj0yGshVbA
Есть ли встроенные механизмы масштабирования, резервирования, бэкапов?
Есть встроенные механизмы масштабирования. Резервирование и бэкапирование делается средствами ОПО.
Есть ли API? Какая реализация?
Только для взаимодействия с внешними системами есть специальное руководство по видам и методам интеграции #ГиперГраф:Интегратор.
Какие есть встроенные средства разработки адаптеров для легаси систем?
См. ответ на вопрос: Есть ли API? Какая реализация?
Какие протоколы доступа и взаимодействия с внешними системами поддерживаются? Какие средства шифрования данных?
См. ответ на вопрос: Есть ли API? Какая реализация?
HASP-ключи
Какие протоколы доступа к самой системе?
Вопрос не корректен.
Что собой представляет пользовательский интерфейс — толстый, тонкий клиент?
Оба варианта реализации.
Есть ли возможность внесения изменений в систему каким-то способом отличным от дизайнера кодогенератора?
Нет, только изменением модели, в противном случае теряется обратимость, изоморфность и релевантность модели и самой системы.
Правильно ли утверждение, что любой новый класс – новая таблица в БД (база данных). Любой новый класс с наследованием – новая таблица в БД со внешними ключами, ссылающимися на класс (таблицу) базового класса.
Нет, новый класс может быть таблицей БД, формой, процедурой. Все классы в модели наследуются от соответствующих классов родителей, то есть в них есть ссылка на родителя плюс добавленные свойства (параметры, методы) и связи с другими классами.
Создание класса с наследованием влечет за собой формирование нового класса (таблицы) с копированием полей из родительского класса (классов) или же используются только ссылки на родительские классы?
Только ссылки.
Если используется ссылка на родительский класс, то при создании нового объекта (записи в таблицу) соответствующих образом заполняется (создаются требуемые объекты) все по иерархии “вверх” (от текущего класса формируются объекты во всех родительских-псевдородительских классах по цепочке наследования)?
Запись в таблице вообще не является ни классом, ни объектом, - используются совсем другие принципы (не путать с примитивами онтологий и семантических сетей). Гиперграф не про данные, а про мета уровень описания систем. Реализована иерархическая ссылка по дереву наследования у всех видов классов.
При введении 9 базовых классов (Руководство_системного_аналитика_Часть_1_Основы_работы_в_системе, стр. 16) вводится понятие “Универсальный класс”: Универсальный класс служит для обобщенного представления в модели непознанных на момент проектирования, не специфицированных сущностей. Является ли это полностью пустым классом, порождающим огромное количество новых классов при любом неизвестном (когда мы не можем сопоставить структуру входных данных с любым из существующих классов в системе) классов? Является ли наследование от универсального класса просто флагом того, что для нас это неизвестная сущность?
Универсальный класс является основой для исследования и обобщения опыта реализации новых специфических задач, он нужен для развития системы базовых классов и реализации управления жизненным циклом техническими требованиями и изменениями технических требований. Да, верно, это флаг и этот механизм используется для научных опытов и познания нового, результатом является новый предметно-ориентированный класс рекомендованный к общему использованию, реализацией эволюционного прироста модели гиперграфа.
При принадлежности нескольких подклассов классу “Универсальный класс” и наличию данных, которые структурно подходят под несколько подклассов (любой вложенности в рамках базового класса УК), как выбирается принадлежность данных классу?
Нельзя рассуждать о классах как о данных – у нас другой уровень описания смыслов, которые включают предельную совокупность описания через содержание, форму и поведение. Только наш подход позволяет смотреть на, кажется, несвязанные данные, как на связанные через какую-либо составляющую(ие), так в одноранговой сети гиперграфа оказываются взаимоувязаны: таракан, труба и партия «Клоунов».
Как, когда и при каких условиях возможно расширение/сужение/замена базовых классов? Структура и методы базовых классов формируются на первичном этапе проектирования системы или идут “из коробки”?
В ходе проектирования и накопления опыта повторяемые свойства в наследуемых классах могут всплывать по дереву наследования в базовые-родительские классы. За 25 лет производилась лишь нормализация свойств базовых классов, которые тут же становились частью всех отнаследованных. Каждый класс, который многократно используется в исполняемой модели по сути сам становится базовым классом, при этом совокупность классов называется онтоклассом, так, например, онтокласс – классификатор, при композиционном наследовании автоматически наследует следующую совокупность: класс содержания, класс ввода, класс запроса, класс процедуры, класс отчета и все они начинают работать всей совокупностью, что кратно сокращает усилия и исключает ошибки при создании модели. Такой механизм позволяет архитектору сформировать технические требования к системе в виде набора специализированных базовых классов, а системные аналитики работают в этих требованиях.
Какая логика работы системы при изменении одного из родительского-прародительского класса (удаление/добавление/изменение полей, удаление/добавление/изменение методов)? Действительно ли любое изменение порождает новую ветвь графа со всеми классами-потомками?
В системе ничего не удаляется ни свойства классов, ни классы, все они остаются как исторические, теряя связность, кроме наследования. Таким образом, в модели можно одновременно увидеть все три состояния: историческое, актуальное и прогнозное. В модели нет множественного наследования (родителей >1), реализовано композиционное наследование логически связанной совокупности классов. Изменения могут быть в свойствах имеющегося класса, добавлением нового класса, в связях структуризации и синтеза. Только новый класс порождает новый лист гиперграфа, этот лист может стать ветвью.
Как фиксируется для пользователя различие в разных версиях одного и того же класса, когда изменения, внесенные в родительский класс, несут изменение структуры для последующих сущностей классов-потомков? Как ведут себя формы при изменениях (вынуждены ли мы будем изменять вручную каждую из форм, которая теперь не отображает не ту информацию или имеет недостаточно информации).
Пользователь получает новые требуемые возможности. Есть быстрые операции, которые добавят новый параметр в форму по умолчанию, однако, если данное положение параметра в форме требуется переместить это можно очень быстро сделать с помощью редактора.
Формируются ли промежуточные классы-прототипы автоматически при компиляции?
Нет. Все классы делятся на проектируемые и исполняемые, последние для #Гиперграф:РоботПО выкладываются на рабочие столы. Всё, чего нет на рабочих столах, не компилится и не генерится, таким образом из большой модели можно выбрать подграф любой размерности и реализовать маленькую функциональную задачу.
Как построена работа с динамической информацией, поступающей извне? Возможно ли получение, структуризация и внесение данных в систему со сторонних сервисов в текущей реализации? Возможно ли подключение сторонних источников информации, требующих криптозащиту (либо любые другие закрытые протоколы получения информации). Например: связь с СДО, интеграция с 1С уровнем выше прямого подключения между БД и обмена файлами, СМЭВ.
Реализовано 5 основных методов интеграции с внешними системами, включая описание проекций внешних БД систем и использование данных внешних систем на чтение в режиме реального времени.
Есть ли у #Гиперграф:Платформы собственные вэб-службы? Есть ли разграничение между ними – открыты для интернета/существуют в рамках закрытого контура сети?
Есть веб-классы и редактор веб-форм в зачаточном состоянии.
Как реализован процесс миграции данных с существующих систем и сервисов, которыми пользуется заказчик, в систему?
Этот процесс начинается с конвертации хаотических данных внешних систем в нашу систему, далее инструментами нашей платформы делаются: нормализация, систематизация, структуризация, устранение избыточности, унификация, классификация, синхронизация и т.п. данных.
Отличается ли принцип работы и формирования виртуальных методов в рамках системы от классических виртуальных методов в ООП?
Да. Есть ряд отличий.
Является ли список типов, используемых в системе (указаны в Руководство системного аналитика Часть 1 Основы работы в системе стр. 95–96), полным? Как решаются типичные проблемы типа money при агрегации и других математических операциях? Как решаются типичные проблемы типов в с плавающей запятой?
При агрегации данных типа money используются ряд методов округления, их можно посмотреть в реализованных моделях.
В презентационных материалах одним из преимуществ продукта обозначается платформа G3 (GGG), которая подразумевает сообщество по всему миру, которое независимо друг от друга может создавать модули системы для интеграции в свои системы. На каких принципах строится это сообщество, как оно регулируется и как строится процесс разработки модулей в нем?
Есть понятие транзакций коллективного проектирования и конвергенции модели, которые являются одним из ключевых достоинств нашего подхода.
Возможна ли интеграция и внедрение модулей из других систем, работающих на #Гиперграф, в свою?
Возможна, но мы предлагаем проектировать у нас классы содержания и форм, а подключать внешние процедуры, например, уникальный датамайнинг, генетический алгоритм, метод свёртки, матлаб, нейронные сети и т.п. (особенно, если автор не хочет раскрывать метод).
На чьей стороне происходит проработка предметной области?
Системный аналитик погружается в предметную область и по предлагаемой нами методологии создания сетецентрических систем управления и производит полную цифровую трансформацию предметной области. Все, кто имеет, дизайнер независимы в проработке предметной области.
На чьей стороне происходит конфигурирование первичной, готовой к работе, конфигурации системы? На чьей стороне происходит изменение и обслуживание системы (создание новых классов, объектов, отображений и т. д.)
Любой вариант конфигурирования доступен при наличии платформы.
Если анализ плюсов и минусов функционала иностранных ERP систем и отечественных?
Есть большие объемные отчеты, в том числе внешних экспертов (Гартнер, IBM, ЦБ, Минобороны, Минфини др.).
Как оптимизируется БД, как происходит ее обслуживание? Есть ли перекрестный контроль за действиями администратора базы данных?
Администратор БД не требуется так как #Гиперграф:РоботПО автоматически с использованием генератора случайных чисел поддерживает целостность БД по таблицам, параметрам и записям. Отделенная от платформы БД не поддается дешифрации в разумные сроки. Вместе с этим мы исследуем процессы самоорганизации в эволюции БД при коллективной работе системных аналитиков.
Функционирование системы возможно только на Oracle/mssql server? Есть ли возможность миграции на open source решения?
Возможна миграция на любые реляционные БД, в частности были продажи на SYBase, Informics.
Какие иностранные решения/модули/системы используются в общей конфигурации Эталона в контексте импортозамещения и отечественно ПО?
Визуализатор гиперграфа Tom Soyer и пакеты для графического представления данных в зависимости от требований заказчика, например, MSGraph.
Примеры проблем текущих ERP систем, которые пропадают при использовании #Гиперграф?
Есть, см. приложение.
Что происходит с классами, которые перестали использоваться или стали ненужными по причине изменения конфигурации системы? (в рамках эволюционной модели можно обозвать это к умершему пути в графе/тупиковая ветвь развития, по которой уже нет активных объектов и которая не нужна).
Это наше уникальное преимущество и свойство гиперграфа: хранение полного жизненного цикла модели даёт возможность его осмысления, изучения и прогнозирования развития.
Есть ли тестовая среда или тренажер? Если да, то какие кейсы можно там посмотреть и в каком порядке возможно получить доступ к тестовой среде/тренажеру?
Есть, #Гиперграф:Государство (включает около 60 000 взаимоувязанных таблиц БД, 100 000 уникальных параметров и 2 000 000 000 связей и несколько миллионов записей в контрольном примере) и #Гиперграф:Корпорация (сопоставим по размеру с #Гиперграф:Государство). Предложено обучение при совместной реализации проекта.
Какие цели и задачи взаимодействия ООО «ГиперГрафГрупп» с Минпромторгом России?
Основной целью взаимодействия ООО "ГиперГрафГрупп" с Минпромторгом России является создание остроактуального глобально-масштабируемого прорывного цифрового продукта нового поколения: российской цифровой Системы управления транснациональной корпорацией (далее – ТНК) на основе новых графо-центричных принципов и технологий.
Данный продукт должен обеспечивать комплексное сбалансированное управление диверсифицированной деятельностью ТНК (включая задачи класса ERP & ESG & другие управленческие функции).
Все лидирующие сегодня международные и российские решения, представленные на глобальном и национальном рынке, не удовлетворяют требованиям реализации эффективной системы управления ТНК. В настоящее время объективная оценка позиции Российской Федерации и предпринимаемых шагов в этих направлениях – крайне негативная. При этом, большинство глобальных продуктов создавалось с участием программистов «Русского мира».
Новый продукт должен обеспечить лидерство, геополитическое доминирование, технологическое превосходство и преимущество над архаичными «лоскутными» зарубежными решениями и отвечать следующим фундаментальным критериям:
- Иметь долгосрочную направленность непрерывной адаптации и развития (более 50 лет с оптимизацией распределения по жизненному циклу совокупной стоимости владения).
- Формировать потенциал качественного и количественного изменения состава участников/собственников глобального цифрового рынка корпоративных систем управления.
- Предлагать фундаментальные решения проблем растущей сложности, взаимосвязанности и динамики глобально-распределенного управления диверсифицированной деятельностью (альтернатива «догоняющей» стратегии и бессмысленной гонке за лидерами, «обогнать не догоняя»).
- Создавать целостную ситуационную картину состояния ТНК (историческую, актуальную, прогнозную) и давать возможность гибкой правовой реструктуризации бизнеса «на лету» (для целей управления в санкционных режимах, оптимизации производственных цепочек и эффективного изменения центров прибыли).
- Формировать новый нематериальный актив – совокупность объектов интеллектуальной собственности.
Реализация стратегических целей и успешное выполнение управленческих задач в настоящих условиях требует получения объективной транспарентной целостной картины текущей и прогнозной ситуации предприятий.
Одной из новых специфических особенностей нового продукта являются инновационные принципы «мобильного» управления организационно-правовой структурой холдинга без замены цифровой системы управления.
Любую компанию или часть компании графо-центричная Модель и Система управления может информационно (прогнозно или по фактическим данным) поглотить, выделить, объединить, преобразовать, продать. Предлагается обеспечить облегченную работу с комплексом юридических лиц, филиалов, обособленных структурных единиц и внутренних структур.
При этом причинами реформы правовой и организационной структуры могут быть: изменение системы владения, финансово-экономическое обоснование, производственно-технологическая оптимизация, требования безопасности, налоговая оптимизация, специфика госзаказчика, ГОЗа, мобрезерва, отношений по ВТС и многие другие.
Уникальность предлагаемых подходов и цифровых продуктов имеет глобальный потенциал спроса.
Какие результаты планирует ООО «ГиперГрафГрупп» от взаимодействия с Минпромторгом России?
Минпромторг России рассматривается как Стратегический Партнёр совместного инновационного инвестиционного цифрового проекта и, в то же время как базовый пилотный проект практической реализации (управление министерством, отраслью, группой промышленных предприятий) новых управленческих подходов и высокоинтеллектуальных цифровых графо-центричных технологий.
Продвижение и внедрение графо-центричной Системы управления предполагается на следующих группах предприятий:
- государственные корпорации,
- ключевые предприятия ГК «Ростех»,
- частные корпорации с экстерриториальной деятельностью,
- корпорации стран СНГ и мирового рынка.
Предлагаемый Стратегический проект ориентирован также на достижение цели, определенной Указом Президента Российской Федерации от 7 мая 2018 г. № 204 в части решения задач и достижения стратегических целей по направлению «Цифровая экономика», и реализацию Национальной программы «Цифровая экономика Российской Федерации» (паспорт которой утверждён президиумом Совета при Президенте РФ по стратегическому развитию и национальным проектам, протокол от 04.06.2019 № 7). Следовательно, дополнительными источниками софинансирования могут быть бюджетные субсидии и гранты.
Стратегический проект может быть осуществлен в рамках государственных программ Российской Федерации «Информационное общество», «Экономическое развитие и инновационная экономика» и других государственных программ Российской Федерации, включая отраслевые государственные программы субъектов Российской Федерации по направлениям:
- Новое качество жизни.
- Инновационное развитие и модернизация экономики.
- Эффективное государство.
- Сбалансированное региональное развитие.
- Обеспечение национальной безопасности.
Правообладатели: ООО "ГиперГрафГрупп" и частные лица.
Ценовая политика зависит от поставляемого функционального состава, количества конкурентных лицензий и услуг по жизненному циклу создания системы управления.
Перечень заказчиков, эксплуатирующих технологические решения ООО «ГиперГрафГрупп» с кратким описанием решаемых прикладных задач (автоматизируемых функций).
Реализованные проекты.pdf — Яндекс.Диск (yandex.ru)
Конкурентные преимущества технологических решений ООО «ГиперГрафГрупп» в общем виде, а также прикладные применения с ближайшими аналогами, доступными на рынке.
Анализ и оценка традиционных цифровых платформ и инновационных графо-центричных цифровых платформ по следующим ключевым критериям:
- архитектура,
- управленческое пространство,
- система управления техническими требованиями к ППО и их изменениями,
- адекватность,
- надежность и работоспособность,
- безопасность.
Эксплуатационная документация в электронном виде, в том числе руководство пользователя, администратора, инструкцию по установке.
Эксплуатационная документация.
Руководство пользователя.
Руководство по инсталляции.
Руководство системного аналитика в 4х частях.
#Гиперграф:Интегратор,
#Гиперграф:Безопасность,
Методология проектирования.
Информацию о наборе инструментов, применяющихся при разработке, используемых сторонних библиотеках, в том числе библиотеки с открытым исходным кодом, копии лицензионных договоров на все применяемые сторонние библиотеки.
#Гиперграф:Платформа является средой разработки.
Описание инструмента #Гиперграф:Интегратор.
Обоснование снижения трудоемкости при использовании технологических решений ООО «ГиперГрафГрупп» по отношению к широко применяемым средствам разработки.
Концептуально изменён жизненный цикл разработки программного обеспечения. С описанием подходов можно ознакомиться в видеоматериалах:
Эффективность системы:
Границы и ограничения применимости графо-центричных технологий не выявлены.
Предложения по способу разграничения прав на данные, которые принадлежат разным заказчикам в едином гиперграфе, по способу организации требований ИБ при едином хранении, в том числе средств разграничения доступа, пояснения, каким образом организуется работа с гиперграфом при устаревании или потери актуальности части данных, что происходит с их производными.
Функциональный состав подсистемы информационной безопасности включает:
Идентификация пользователей (их учётных записей) осуществляется уникальной символьной последовательностью.
Разграничение доступа персонала к обрабатываемой информационной системой информации обеспечивается назначением им функциональных ролей, наделённых предварительно определёнными правами доступа к ресурсам системы.
Набор первоначальных ролей и перечень их прав на доступ к ресурсам Системы определяется по согласованию с Заказчиком на этапе ее настройки и адаптации. В Системе для системного администратора Заказчика предусмотрены средства управления изменениями ролей.
Допускается объединение пользователей в группы для обеспечения удобства администрирования их полномочий доступа к ресурсам Системы:
Минимальные требования по классу защищенности
не ниже 1Г в соответствии с РД ФСТЭК
Эксплуатационная документация.
Руководство пользователя.
Руководство по инсталляции.
Руководство системного аналитика в 4х частях.
#Гиперграф:Интегратор,
#Гиперграф:Безопасность,
Методология проектирования.
Информацию о наборе инструментов, применяющихся при разработке, используемых сторонних библиотеках, в том числе библиотеки с открытым исходным кодом, копии лицензионных договоров на все применяемые сторонние библиотеки.
#Гиперграф:Платформа является средой разработки.
- Проектирование сетецентрических систем,
- Сетецентрические Системы.
Описание инструмента #Гиперграф:Интегратор.
Обоснование снижения трудоемкости при использовании технологических решений ООО «ГиперГрафГрупп» по отношению к широко применяемым средствам разработки.
Концептуально изменён жизненный цикл разработки программного обеспечения. С описанием подходов можно ознакомиться в видеоматериалах:
- Проектирование сетецентрических систем,
- Сетецентрические Системы.
- единая цифровая графо-центричная экосистема,
- единая цифровая графо-центричная платформа и совокупность инструментов коллективной распределённой работы,
- описание модели объектов и процессов управления,
- исполняемая система управления описанными объектами и процессами,
- реализация 2х этапного жизненного цикла информационных систем управления,
- набор инструментальных средств коллективного пользования:
- среда коллективного эволюционного визуального моделирования,
- язык эволюционного моделирования,
- средства навигации в гиперграфе (открытость и транспарентность),
- система управления техническими требованиями (системными соглашениями),
- система управления изменениями требований,
- средства создания классов / онтоклассов «быстрыми» операциями,
- специализированные редакторы классов (типа содержание, форма, поведение),
- специализированные средства построения произвольных аналитических отчётов,
- средства ведения системных журналов состояния модели и системы,
- средства автодокументирования модели и системы,
- инструменты визуального представления подграфов гиперграфа классов,
- средства интеграции с внешними системами,
- средства интеграции с аналого-цифровыми преобразователями (АЦП),
- средства описания исторического, актуального и прогнозного состояния системы.
- модель системы управления,
- технология «робот по программированию»,
- исполняемая система управления,
- единая комплексная система безопасности.
Эффективность системы:
- эволюционно наращиваемый широкий функциональный состав решаемых задач системы коллективного управления,
- единое информационно-функциональное управленческое пространство,
- оптимизация бизнес-процессов, сокращение на порядки финансовых и временных затрат на разработку, сопровождение и развитие сложной информационной системы управления,
- сокращение времени принятия оптимальных решений на основе целостной ситуационной картины и широкого спектра аналитической деятельности (оперативное получение аналитических данных и Отчётов требуемого вида без участия программистов),
- персонификация работы и ответственности как пользователей системы, так и системных аналитиков при проектировании модели системы.
- обеспечен высокий уровень надежности, работоспособности, динамической адаптивности, соответствия современным и перспективным требованиям, безопасности,
- единство модели и системы: модель и автоматически созданная система релевантны и обратимы.
- обеспечение достоверности, целостности, непротиворечивости, синхронизации и транспарентности данных за счет использования единого взаимоувязанного хранилища однократно вводимых данных,
- единая система управления ЖЦ нормативно-справочной информации,
- единое пространство управления транзакционными и аналитическими данными со сквозной реализацией функций «roll-up» и «drill-down».
- обеспечение непрерывного адекватного эволюционного развития системы без участия программистов;
- система не зависит от создателей графо-центричных технологий и конкретных разработчиков специального программного обеспечения;
- кросс-функциональность системы: обеспечение оперативного «бесшовного» взаимодействия пользователей системы поверх организационных границ и функций структурных подразделений предприятия (в соответствии с установленными правами доступа к информации).
- гибкость конфигурирования системы:
- обеспечение быстрого изменения конфигурации системы в случае осуществления организационно-штатных изменений на предприятии (изменение организационной структуры, состава функций и полномочий структурных подразделений и сотрудников, штатного расписания предприятия и др.).
- простота обучения работы в системе: стандартизация принципов и методов работы в системе, единые эргономические принципы и стандарты интерфейсов, обеспечение быстрого обучения, преемственности и взаимозаменяемости пользователей.
- возможность накопления в системе знаний и опыта многих коллективов и индивидуальных авторов.
- новая теория мультицелевых систем управления глобальными структурами,
- холический подход к архитектуре сложных, динамических, слабо-детерминированных систем управления,
- новая единая графо-центричная цифровая архитектура модели и системы:
- использование математических структур типа однорангового гиперграфа классов, у которого осуществлена формализация конечного множества вершин (классов типа содержание, форма, поведение) и множества связей (наследование, структуризация, синтез), позволяющего описывать предметы и процессы любой сложности (цифровые аналоги) в виде фрактальных композиций,
- фрактальные принципы моделирования гиперграфа,
- управление гиперграфами классов (сравнение, выделение, слияние (мержирование) и т.п.),
- визуальный эволюционный язык моделирования,
- коллективное конвергентное описание цифровой модели знаний о предметах и процессах реального мира в виде свойств классов (параметры, методы) в гиперграфе классов,
- элементы и структура языка,
- реализация принципов объектно-ориентированного подхода (наследование, инкапсуляция, полиморфизм) при проектировании гиперграфа,
- предметно-ориентированные, дисциплинарные, отраслевые, функциональные, организационные и другие виды композиции классов в гиперграфе,
- конвергенция модели знаний в гиперграфе классов,
- новый жизненный цикл информационных систем,
- робот по программированию,
- новая цифровая глобальная сеть GRAPH (NET-WEB-GRAPH) коллективного управления деятельностью.
Границы и ограничения применимости графо-центричных технологий не выявлены.
Предложения по способу разграничения прав на данные, которые принадлежат разным заказчикам в едином гиперграфе, по способу организации требований ИБ при едином хранении, в том числе средств разграничения доступа, пояснения, каким образом организуется работа с гиперграфом при устаревании или потери актуальности части данных, что происходит с их производными.
Функциональный состав подсистемы информационной безопасности включает:
- Комплекс средств адаптивной защиты информации от несанкционированного доступа с минимальными требованиями по классу защищенности не ниже 1Г в соответствии с РД ФСТЭК;
- Выборочная криптозащита, ролевой и мандатный методы доступа, персонификация, идентификация действий, многоуровневая схема защиты данных;
- Управление пользователями Системы (создание, редактирование, назначение паролей, рабочих столов и т.д.);
- авторизация и аутентификация пользователей;
- разделение доступа пользователей к ресурсам на основе администрируемой ролевой и персональной политики;
- регистрация ввода информации (время, авторизация);
- регистрация изменения информации (время, авторизация);
- автоматический контроль и протоколирование изменений, проводимых в настройках и данных системы.
Идентификация пользователей (их учётных записей) осуществляется уникальной символьной последовательностью.
Разграничение доступа персонала к обрабатываемой информационной системой информации обеспечивается назначением им функциональных ролей, наделённых предварительно определёнными правами доступа к ресурсам системы.
Набор первоначальных ролей и перечень их прав на доступ к ресурсам Системы определяется по согласованию с Заказчиком на этапе ее настройки и адаптации. В Системе для системного администратора Заказчика предусмотрены средства управления изменениями ролей.
Допускается объединение пользователей в группы для обеспечения удобства администрирования их полномочий доступа к ресурсам Системы:
- Протоколирование и хранение протоколов авторизации и действий пользователей,
- Ведение протокола удалений данных,
- Разграничение доступа к Системе посредством присвоения пользователю ролей;
- Разделение пользователей на группы доверия;
- Обработка заявок на добавление и редактирование пользователей;
- Назначение режимов доступа по ролям к функциям Системы, таблицам, группам полей таблиц, группам записей таблиц, чтение/запись данных;
- Разделение полномочий пользователей, системных аналитиков по настройке и адаптации Системы, системных администраторов и лиц, обеспечивающих функционирование информационной Системы;
- Блокирование сеанса доступа в информационную систему после установленного времени бездействия (неактивности) пользователя или по запросу;
- Управление взаимодействием с информационными системами сторонних организаций (внешними информационными системами).
Минимальные требования по классу защищенности
не ниже 1Г в соответствии с РД ФСТЭК
Требования по обеспечению безопасности информации уточняются на этапе технического проектирования Системы, включая анализ необходимости использования (встраивания) криптографических средств защиты информации, с последующей реализацией принятого решения. Перечень программно-технических средств обеспечения безопасности Системы определяется на основании анализа данных, которые будет содержать Система.
Параметрами событий, подлежащими обязательной регистрации, являются:
Событиями, подлежащими обязательной регистрации, являются:
Перечень регистрируемых событий и параметров доступен только администратору информационной Системы. Регистрация действий персонала осуществляется в специальном системном журнале (протоколе), возможность редактирования которого исключена.
Разграничение прав на данные представлены в видеоматериалах по ссылке. В гиперграфе реализованы единая система времени, которая обеспечивает хранение, использование и сквозную релевантную ссылочность исторических, актуальных и прогнозных данных.
Дополнительно считаем целесообразным отметить:
В России исторически приоритетом для автоматизации и роботизации были: сложные, тяжёлые, вредные и опасные производства, транспортные автопилоты, планирование социального развития и управление межотраслевыми балансами, космические станции и многие другие социо-технологические системы.
Изначально в описании автоматизированных систем управления производственной деятельностью в рамках отечественных (СССР, Россия) научных подходов применялось следующее деление систем:
При этом, было чёткое понимание сложности деления и размытости границ между ними, так как в системах использовались одни и те же объекты управления с разным функциональным параметрическим составом обусловленным использованием в многообразных процессах управления.
В то же время западный «конкурентный» рынок автоматизированных систем формировался хаотически, без должной научной систематизации и структуризации, то есть исторически сложилось целеполагание, направленное на максимальное извлечение прибыли. Все перечисленные ниже в таблице классы систем западных ИТ-компаний имеют множественное функциональное пересечение и дублирование. Они специализированы и «наструганы» по мере понимания потребностей конкретных пользователей (пресловутые «лучшие практики»): по функциям (производственным и бизнес-процессам), по объектам управления, по органам управления, по видам обработки данных, по отраслям, по секторам деятельности и многим другим принципам – лишь бы продать побольше и подороже.
Большинство российских «специалистов» без должного критического подхода, профессиональных знаний, логического мышления, наконец, просто здравого смысла, послушно встали под знамёна западных ИТ-компаний, бросили передовые мировые уникальные ИТ-достижения русских учёных.
Параметрами событий, подлежащими обязательной регистрации, являются:
- дата и время события;
- идентификатор пользователя Системы;
- идентификатор выполняемой функции Системы;
Событиями, подлежащими обязательной регистрации, являются:
- доступ (вход и выход) пользователей к функциям Системы;
- операции пользователя с обрабатываемыми данными;
- вывод информации на носители информации;
- создание, изменение и удаление учётных записей пользователей.
Перечень регистрируемых событий и параметров доступен только администратору информационной Системы. Регистрация действий персонала осуществляется в специальном системном журнале (протоколе), возможность редактирования которого исключена.
Разграничение прав на данные представлены в видеоматериалах по ссылке. В гиперграфе реализованы единая система времени, которая обеспечивает хранение, использование и сквозную релевантную ссылочность исторических, актуальных и прогнозных данных.
Дополнительно считаем целесообразным отметить:
В России исторически приоритетом для автоматизации и роботизации были: сложные, тяжёлые, вредные и опасные производства, транспортные автопилоты, планирование социального развития и управление межотраслевыми балансами, космические станции и многие другие социо-технологические системы.
Изначально в описании автоматизированных систем управления производственной деятельностью в рамках отечественных (СССР, Россия) научных подходов применялось следующее деление систем:
- АСУП – автоматизированная система управления предприятием,
- АСУТП – автоматизированная система управления технологическим процессом.
При этом, было чёткое понимание сложности деления и размытости границ между ними, так как в системах использовались одни и те же объекты управления с разным функциональным параметрическим составом обусловленным использованием в многообразных процессах управления.
В то же время западный «конкурентный» рынок автоматизированных систем формировался хаотически, без должной научной систематизации и структуризации, то есть исторически сложилось целеполагание, направленное на максимальное извлечение прибыли. Все перечисленные ниже в таблице классы систем западных ИТ-компаний имеют множественное функциональное пересечение и дублирование. Они специализированы и «наструганы» по мере понимания потребностей конкретных пользователей (пресловутые «лучшие практики»): по функциям (производственным и бизнес-процессам), по объектам управления, по органам управления, по видам обработки данных, по отраслям, по секторам деятельности и многим другим принципам – лишь бы продать побольше и подороже.
Большинство российских «специалистов» без должного критического подхода, профессиональных знаний, логического мышления, наконец, просто здравого смысла, послушно встали под знамёна западных ИТ-компаний, бросили передовые мировые уникальные ИТ-достижения русских учёных.
Такое положение вещей привело к тому, что предприятие может многократно закупать одни и те же функции, например, купив одновременно следующее ППО:
Разберём подробнее этот пример «обувания» и собственников, и государственных служащих, и директоров, и специалистов производства на предприятии алчными айтишниками, которые год за годом увеличивают бюджеты расходов на цифровую трансформацию. Они собирают дорогостоящие коллекции[1] ППО, являясь объектами таргетированной манипуляции ИТ-поведением.
Так, MES-система предназначена для решения задач выпуска продукции. Аббревиатуру MES иногда расшифровывают как manufacturing enterprise solutions – корпоративные решения для управления производством, иногда термином MES обозначают совокупность функций автоматизированной системы, используемых для оперативного управления производством на уровне цеха.
MES-системы как правило выполняют следующие функции:
Даже просто прочитав данный перечень функций, образованный человек должен увидеть их дублирование как минимум в части документооборота (пусть и производственного), управления персоналом (пусть и рабочими), менеджмента качества (пусть и технологических операций), технического обслуживания и ремонтов (пусть и станков) и других.
Кроме того, часто отсутствует понимание, что системы, связанные с производственным процессом, обычно рассматривают как своеобразную «матрёшку», то есть функции системы MRP II включают функции систем PLM, которая включает функции систем MES с одними и теми же объектами управления производством. Кроме того, надо отметить, что многие ERP – Enterprise Resource Planning сегодня включают модули MRP II (PLM (MES)), например, это декларирует SAP. Но остановимся на триаде MRP II (PLM (MES)).
Приведём «стандартные, коробочные» функции этих систем из их описаний.
MRP II – планирование потребности предприятия не только в материалах, но и во всех производственных ресурсах (материалы, сырье, комплектующие, оборудование, персонал), позволяет вести учет заказов, планировать загрузку производственных мощностей, производственные затраты, моделировать ход производства, вести его учёт, планировать выпуск готовых изделий, оперативно корректировать планы и производственные задания:
PLM (product lifecycle management) жизненный цикл продукции (изделия) – совокупность процессов, выполняемых от момента выявления потребностей организации в определённой продукции до момента удовлетворения этих потребностей и утилизации продукта. PLM обычно автоматизирует следующие основные стадии жизненного цикла изделия: проектирование, производство, техническая эксплуатация, утилизация. Они «покрываются» модулями, которые рассматриваются часто как автономные и самодостаточные и могут быть приобретены отдельно и у разных производителей:
Таким образом, купив систему, например, PLM того или иного производителя прежде всего необходимо рассмотреть какие функции MES-систем в неё уже входят. И дополнительно отдельно систему MES не закупать, если нет «уникального неповторимого» вида производства.
Опыт исследований и практической деятельности показал, что на большинстве корпораций мира сложилась идентичная ситуация ошибочно принятых дорогостоящих решений о внедрении независимых отдельно закупленных у различных производителей коллекций MES, CAE, CAD, САМ, PDM, CRM, ERP, MRP, MRP II, WMS, PLM, BI, MDM и многих, многих других систем. При этом, ключевым неизменным местом встречи всех управленческих данных и попыток их использования для принятия решения остается WORD и EXCEL.
Все переживают катастрофический «комбинаторный взрыв» работ и затрат, при любом изменении требований к той или иной системе управления производством, когда несчётное количество автономных модулей, сервисов, приложений и соответствующих им API надо модифицировать, тестировать и опытно эксплуатировать до промышленного работоспособного, надёжного и безопасного применения.
ЧТО ДЕЛАТЬ?
Консорциум «Цифрогенез» во главе с ООО "ГиперГрафГрупп" для выработки обоснованных планов автоматизации и разработки оптимальной Стратегии цифровой трансформации предприятия формирует Единую целевую функциональную модель производственного и корпоративного управления на основе единой графо-центричной платформы #Гиперграф:Корпорация и реализует проект «цифровой аналог» предприятия в едином информационно-функциональном пространстве.
Более подробно читайте в статье «Эпик фейл цифровой трансформации БигТеха. ГДЕ КЛЮЧ к Левел ап? (Сокрушительный провал цифровой трансформации транснациональных корпораций. Где ключ к новому уровню управления?)», а также смотрите.
- MRP II (manufacturing resource planning) планирование производственных ресурсов;
- PLM (product lifecycle management) жизненный цикл продукции;
- MES (manufacturing execution system) система управления производством.
Разберём подробнее этот пример «обувания» и собственников, и государственных служащих, и директоров, и специалистов производства на предприятии алчными айтишниками, которые год за годом увеличивают бюджеты расходов на цифровую трансформацию. Они собирают дорогостоящие коллекции[1] ППО, являясь объектами таргетированной манипуляции ИТ-поведением.
Так, MES-система предназначена для решения задач выпуска продукции. Аббревиатуру MES иногда расшифровывают как manufacturing enterprise solutions – корпоративные решения для управления производством, иногда термином MES обозначают совокупность функций автоматизированной системы, используемых для оперативного управления производством на уровне цеха.
MES-системы как правило выполняют следующие функции:
- контроль состояния и распределение ресурсов (RAS, resource allocation and status);
- оперативное/детальное планирование (ODS, operations/detail scheduling);
- диспетчеризация производства (DPU, dispatching production units);
- управление документами (DOC, document control);
- сбор и хранение данных, циркулирующих в производственной среде предприятия (DCA, data collection/acquisition);
- управление персоналом (LM, labor management);
- управление качеством (QM, quality management);
- управление производственными процессами (PM, process management);
- управление техобслуживанием и ремонтом (MM, maintenance management);
- отслеживание и генеалогия продукции (PTG, product tracking and genealogy);
- анализ производительности (PA, performance analysis).
Даже просто прочитав данный перечень функций, образованный человек должен увидеть их дублирование как минимум в части документооборота (пусть и производственного), управления персоналом (пусть и рабочими), менеджмента качества (пусть и технологических операций), технического обслуживания и ремонтов (пусть и станков) и других.
Кроме того, часто отсутствует понимание, что системы, связанные с производственным процессом, обычно рассматривают как своеобразную «матрёшку», то есть функции системы MRP II включают функции систем PLM, которая включает функции систем MES с одними и теми же объектами управления производством. Кроме того, надо отметить, что многие ERP – Enterprise Resource Planning сегодня включают модули MRP II (PLM (MES)), например, это декларирует SAP. Но остановимся на триаде MRP II (PLM (MES)).
Приведём «стандартные, коробочные» функции этих систем из их описаний.
MRP II – планирование потребности предприятия не только в материалах, но и во всех производственных ресурсах (материалы, сырье, комплектующие, оборудование, персонал), позволяет вести учет заказов, планировать загрузку производственных мощностей, производственные затраты, моделировать ход производства, вести его учёт, планировать выпуск готовых изделий, оперативно корректировать планы и производственные задания:
- планирование продаж и производства (sales and operation planning);
- управление спросом (demand management);
- составление плана производства (master production scheduling);
- планирование материальных потребностей (material requirement planning, MRP);
- спецификация продуктов (bill of materials);
- управление запасами (inventory transaction subsystem);
- управление плановыми поставками (scheduled receipts subsystem);
- управление на уровне производственного цеха (shop flow control);
- планирование производственных мощностей (capacity requirement planning, CRP);
- контроль входа/выхода рабочих потоков (input/output control);
- материально техническое снабжение (purchasing);
- планирование ресурсов для распределения (distribution resource planning, DRP);
- планирование и контроль производственных операций (tooling planning and control);
- управление финансами (financial planning);
- моделирование для производственной программы (simulation);
- оценка результатов деятельности (performance measurement).
PLM (product lifecycle management) жизненный цикл продукции (изделия) – совокупность процессов, выполняемых от момента выявления потребностей организации в определённой продукции до момента удовлетворения этих потребностей и утилизации продукта. PLM обычно автоматизирует следующие основные стадии жизненного цикла изделия: проектирование, производство, техническая эксплуатация, утилизация. Они «покрываются» модулями, которые рассматриваются часто как автономные и самодостаточные и могут быть приобретены отдельно и у разных производителей:
- маркетинг и изучение рынка (CRM);
- проектирование и разработка продукта (САПР, CAE, CAD, САМ, PDM);
- планирование и подготовка производства (MES, PDM);
- закупка материалов и комплектующих (SCM, PDM);
- производство или предоставление услуг (АСУП, АСУТП, ERP, MRP, MRP II, SCM MES, PDM);
- упаковка и хранение (WMS, PDM);
- реализация (CRM, PDM);
- установка (монтаж) и ввод в эксплуатацию (CRM, PDM);
- техническая поддержка и обслуживание (PDM);
- послепродажное обслуживание (техобслуживание, ремонт и эксплуатация) деятельность или эксплуатация (PDM);
- утилизация и переработка (PDM).
Таким образом, купив систему, например, PLM того или иного производителя прежде всего необходимо рассмотреть какие функции MES-систем в неё уже входят. И дополнительно отдельно систему MES не закупать, если нет «уникального неповторимого» вида производства.
Опыт исследований и практической деятельности показал, что на большинстве корпораций мира сложилась идентичная ситуация ошибочно принятых дорогостоящих решений о внедрении независимых отдельно закупленных у различных производителей коллекций MES, CAE, CAD, САМ, PDM, CRM, ERP, MRP, MRP II, WMS, PLM, BI, MDM и многих, многих других систем. При этом, ключевым неизменным местом встречи всех управленческих данных и попыток их использования для принятия решения остается WORD и EXCEL.
Все переживают катастрофический «комбинаторный взрыв» работ и затрат, при любом изменении требований к той или иной системе управления производством, когда несчётное количество автономных модулей, сервисов, приложений и соответствующих им API надо модифицировать, тестировать и опытно эксплуатировать до промышленного работоспособного, надёжного и безопасного применения.
ЧТО ДЕЛАТЬ?
Консорциум «Цифрогенез» во главе с ООО "ГиперГрафГрупп" для выработки обоснованных планов автоматизации и разработки оптимальной Стратегии цифровой трансформации предприятия формирует Единую целевую функциональную модель производственного и корпоративного управления на основе единой графо-центричной платформы #Гиперграф:Корпорация и реализует проект «цифровой аналог» предприятия в едином информационно-функциональном пространстве.
Более подробно читайте в статье «Эпик фейл цифровой трансформации БигТеха. ГДЕ КЛЮЧ к Левел ап? (Сокрушительный провал цифровой трансформации транснациональных корпораций. Где ключ к новому уровню управления?)», а также смотрите.
СРАВНИТЕЛЬНЫЙ АНАЛИЗ
ТРАДИЦИОННЫХ ERP-СИСТЕМ УПРАВЛЕНИЯ (1C, Галактика, SAP R/3, ORACLE EBS и других) И СЕТЕЦЕНТРИЧЕСКИХ СИСТЕМ УПРАВЛЕНИЯ
