Сергей Вохмянин писал(а):
Здравствуйте, меня зовут Сергей Вохмянин
Здравствуйте, Сергей.
Сергей Вохмянин писал(а):
Хочу предложить вашему вниманию некоторые мои разработки в областях:
1. Жизни,
2. Образовании,
3. Работы...
Прошу поделиться мыслями, как людей опытных в вопросах программирования, на предмет:
1. Жизненности подобных схем.
Увы...
Сергей Вохмянин писал(а):
2. Областей их применения.
Снова, увы...
Сергей Вохмянин писал(а):
3. Если есть нечто подобное - прошу поделиться.
Нечто подобное, конечно есть... например, системы класса MRP-II, ERP, MES, SCADA и пр. Это большие (неуклюжие) и дорогие системы, требующие длительного цикла внедрения, знаний и опыта, нормативной базы, технологической документации (действующей!), налаженной системы учета и т.д. и т.п. Ваше желание решить задачу наскоком... понятно, но малопродуктивно. Еще менее понятно, зачем для данной задачи (по сути речь идет об автоматизированном управлении производством) язык Дракон? Здесь уже обсуждался вопрос о том, что Дракон можно использовать для описания алгоритмов, но для описания систем он не слишком подходит. Это первое.
Второе. Вопрос реализации, при разработке систем, вторичен. Как правило, первичен вопрос концепции, архитектуры. А именно этого нет (и не может быть в Дракон-схемах). Без качественной концепции, Вы обречены... на рефакторинг, то есть, на то чтобы стать пожизненным рабом своих собственных реализаций. Если не возражаете, я поясню простым примером, на основе Вашей первой схемы. Общеизвестно (со времен К. Маркса и Ф. Энгельса), что в основе любого(!) производства лежат три сущности:
1. Предмет труда (от сырья и полуфабрикатов до продукции);
2. Средства труда (инструменты, оборудование);
3. Живой труд (физический, умственный...).
Разумно предположить, что единичным элементом производства является операция, и, следовательно, операция должна включать в себя все три перечисленных выше сущности (ведь производство может состоять и из одной операции). В случае многопередельного производства, то есть, производства, состоящего из нескольких операций, операции связываются направленным графом (орграф). В полученном орграфе, который называется "технологический процесс/маршрут", вершинами являются операции, а ребрами - передачи полуфабрикатов(*) с одной операции на другую.
Для всех(!) операций по каждому типу/виду/классу предмета труда(!) существуют нормы расхода средств труда и живого труда. К ним относятся, в частности, нормы износа/амортизации оборудования и инструментов, нормы времени выполнения операции оборудованием и персоналом (по категориям/профессии/квалификации). Другими словами, каждая операция характеризуется тремя видами нормативов:
1. Нормы производства/выработки;
2. Нормы использования оборудования и инструментов;
3. Нормы использования персонала.
Нормы расходов могут параметризовываться, например, условиями труда, например, одно дело выемка песчаного грунта, совсем иное дело, выемка скального грунта; одно дело выемка песчаного грунта летом (+20С), совсем иное, выемка того же песчаного грунта зимой (-20С) (все это было в СНИПах). Параметризация нормативов относится не только к строительству, но и другим отраслям промышленности.
Помимо перечисленных нормативных характеристик операций есть и другие: рабочее время операции, время смены заготовки, время перехода на другую продукцию (время переналадки).
Далее. Сами операции могут быть обязательными или факультативными. Обязательные операции выполняются всегда, факультативные выполняются при некоторых условиях, например, по желанию заказчика или при низком качестве исходного сырья, или при повышенной влажности грунта и т.д.
Теперь, когда у нас есть описание технологического процесса (орграфа), где каждая операция имеет заданные нормативы, мы можем сказать: сколько, когда и каких материалов нам потребуется; сколько, когда и каких инструментов..., сколько и когда потребуется персонала в разрезе профессий и квалификаций. То есть, можно переходить к планированию производства. Если помимо плановых данных собирать и фактическую информацию (то есть, отслеживать отклонения от нормативных значений), то можно выявить проблемные места производства, а значит и получить информацию необходимую для устранения проблем (или, что реже, для корректировки соответствующих нормативов).
Если теперь представить, полученную по данному описанию модель, то она получится:
1. Существенно более компактной, чем любая из Ваших;
2. Существенно более простой и гибкой (настраиваемой под любые типы производств);
3. Существенно более расширяемой (например, зная фактическое время отработанное каждой единицей оборудования, можно планировать его ремонт, да, и сам ремонт любого вида оборудования можно представить все тем же тех. процессом; можно планировать закупки, и поступление денег от реализации; можно поддерживать актуальным список вакансий и пр. и пр. и пр.)...
И здесь мы подходим к основному вопросу... Исходная идея, о создании подобного программного обеспечения, должна получить концептуальную основу. Концепция - это конкретизированная идея, показывающая принципиальную возможность ее реализации. На основе концепции строится концептуальная модель, которая является основой для последующего проектного решения. Если сделать проекцию на строительство, то концепция - это общее эскизное решение архитектора. Концептуальное решение - это решение архитектора привязанное к местности, местным условиям. Проектное решение - это формальная модель, то есть такая модель, которая не допускает неоднозначного понимания. Для получения формальной модели, концептуальная модель перекладывается на некий формальный аппарат (описывается на формальном языке). Вы же идете с противоположного конца, незрелую идею Вы пытаетесь втиснуть в "прокрустово ложе" формального языка. Это тупик...
Идея, доросшая до концепции, сама конкретизирует средство своего формального описания... как правило (правда, бывают ситуации, когда необходимых средств формального описания просто нет). Например, я бы не взялся реализовывать представленное мной описание на Драконе, не потому, что я плохо знаю Дракон, и не потому, что Дракон плохой язык... Дракон - хороший язык для описания алгоритмов (хотя он явно делает попытки выйти за эти рамки... зря, IMHO), но он бесполезный язык для описания систем.
[(*) Примечание не всегда существует передача полуфабрикатов. Есть производства, где предмет труда перемещается между средствами труда (правильнее сказать, между производственными мощностями), а есть производства (строительство в их числе), где средства труда перемещаются между предметами труда: сегодня кран работает на объекте А, завтра - на объекте Б].