ifis-67,
Вам прежде всего необходимо определиться, чего именно Вы хотели бы от программы в отношении арматуры. Это исключительно индивидуально. Возможно, она Вам нужна для расчётов гидравлики существующих режимов (и соответствующего контроля соответствия фактическим замерам). Может быть, Вы хотели бы использовать её для вариантного моделирования различных возможных режимов или подбора материалов и оборудования. Может быть, Вы вообще не нуждаетесь в её расчётных возможностях, а хотели бы использовать её как визуальное представление системы с визуальной сигнализацией состояния (наподобие SCADA). Или даже ещё какой-нибудь вариант использования, который никому больше ещё в голову не пришёл. От этого и будет зависеть, что именно Вам надо отразить в программе.
Сама по сибе система Zulu построена очень гибкой. За счёт того, что данные элементов хранятся в БД, и с учётом развитых средств программного доступа к данным, в ней можно сделать очень много того, чего даже сами разработчики не предполагают. Другое дело, что чем дальше от "запланированного" способа использования программой, тем меньше помощи и тем больше требования к предварительной доводке напильником.
Любая коммерческая фирма имеет главной своей целью извлечение выгоды. У неё есть ограниченные ресурсы - и финансовые, и людские, и временные. И естественно, что любая хотелка пользователя проходит через определённый фильтр.
Надо отметить, что здесь - один из самых отзывчивых коллективов разработчиков. Если некая функциональность не сложна в реализации, они добавляют её даже в ответ на единичный запрос. И если она требует каких-то усилий, но соответствует их концепции, они тоже не ждут, когда заявок наберётся вагон. Но если реализация чего-то требует пересмотра значительной части архитектуры системы, как это, видимо, случилось с моим запросом (см. первые посты), и при этом она не вполне стыкуется с вИдением разработчиков, то нужны действительно веские аргументы для убеждения. Например, финансовые (скажем, некий металлургический монстр мог бы предложить разработать нечто по отдельному договору
). Или должно быть множество заинтересованных (чтобы был виден спрос). И это нормально.
В моём запросе, если я не ошибаюсь, самая хитрая часть - это точки связи "внутренней структуры" узла и присоединяемых к нему участков. В существующей системе, например, задвижка может иметь только два присоединения, которые она в зависимости от состояния либо соединяет, либо разъединяет. Разветвление может иметь произвольное (?) число присоединений, но все они объединены между собой совершенно "равноправно", то есть у программы нет никаких трудностей в определении, какой вход соединять с каким выходом. А в случае со "сложным узлом" нужно предусмотреть систему взаимодействия программы с пользователем, чтобы можно было однозначно и удобно включить внутреннюю структуру узла во внешнюю сеть.
Конечно, у меня есть мысли по этому поводу. Но это - достаточно большая работа. Поэтому надоедать с этим вопросом не буду, пока не станет очевидно, что эта функциональность действительно нужна многим, причём действительно нужна. Вы, например, похоже, ещё не определились, что нужно именно Вам.
