Здравствуйте, господа!

Что-то мой текст из Ворда в ленту не вставляется. Поэтому завтра в конторе разберемся, а пока дам небольшую реплику на эти Ваши слова, Андрей.

> 1) Насколько я знаю, клеточные автоматы лежат в основе системы имитационного моделирования, как ее понимает Вадим. Сразу оговорюсь – ничего плохого я в этом не вижу.

А я вижу. Клеточные автоматы сюда никаким боком. Клеточные автоматы - это ячейки пространства, которые принимают различные состояния. Я всегда говорил о "многоуровневых кл.автоматах" и то потому, что не хотелось до поры до времени давать свое определение известному термину. У меня это понятие ближе к агентскому подходу, но последний слишком убог. Так что про мои "клеточные автоматы" лучше не говорить - это системное понятие, а не клеточно-автоматное. Да и речь у меня везде по текущей теме идет о фундаменте, а не о предметных надстройках - в т.ч. моделировании как это понимают предметники.

> Клеточные автоматы – достаточно общий метод, неплохо зарекомендовавший себя, в системе имитационного моделирования будут не только и столько методы манипулирования состояниями клеточных автоматов в их "классическом понимании".
2) Я не против новой расширяемой и модифицируемой информационной системы - покажите мне любого разумного человека, который против этого? Я не против имитационного моделирования, не против, чтобы функции ее были в ГИС, Инмете и пр.
Перечитайте мое сообщение – где я сказал: "имитационное моделирование – фуфло"? Весь вопрос во времени и на что направить усилия …

Я завтра скажу подробнее. Никто и не думает про фуфло. Я говорил, что наш опыт говорит, что даже на мелкие модификации нашего ПО у нас уходит слишком много ресурсов. И в большой степени это объясняется ошибками молодости, которые пора исправлять.

> По-поводу кадастровые системы = системы моделирования, только без Т.
Ну можно так считать, но все-таки круг задач и требований несколько разный.
Хотя бы по устойчивости от сбоев, объемам данных, скорости и пр.

Причем требования к системе моделирования покрывают требования к учетной системе. Учетная система внутри системы моделирования. Я не могу себе представить систему имитационного моделирования для большого количества объектов, если нет их реестра и достаточной полноты атрибутов у объектов. К тому же речь идет о создании архитектуры, которая должна будет иметь ПОТЕНЦИАЛ развития в сторону системы имитационного моделирования, а не "перескакивать" там через что-то. Вначале будет учетная подсистема, но в ней будут заложены такие принципы построения, чтобы над этой учетной подсистемой потом могла нараститься модельная. И аналитическая, кстати, тоже. Я не ставлю на один уровень анализ и моделирование. Анализ входит в моделирование как составная часть.

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

Вы, Андрей, похоже, сами себе здесь противоречите. То говорите о том, что мы собираемся "перепрыгнуть" через все сразу на моделирование, то вдруг говорите, что и перепрыгнуть-то нельзя. Так никто и не пытался. :) Это Вы так сказали, а теперь оппонируете своей же оценке.

Моделирующая система умеет и учитывать объекты, т.к. без этого и моделирования не провести. А анализ я бы тут вообще вторым уровнем не ставил. Это смотря какой анализ. Анализ как и прогноз - это всего лишь результат моделирования. Просто цели разные.

Так что моделирование как процесс покрывает и аналитические модели (аналитические не в смысле "формульные"), и прогнозные.

> Предельно просто, в чем я даже не "не схожусь с Вадимом", а какими задаюсь вопросами.
1) в условиях ограниченности ресурсов (это принципиально!) куда сосредоточить усилия? – на решение задач второго уровня или написания новой базы для последующего более легкого решения задач второго и третьего уровня.

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

> 2) Стоит ли систему моделирования интегрировать в ядро? Ясно, что чем боле все интегрировано, тем лучше, но тем и внутренне сложнее.

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

> 3) Что еще будет в новой инструментальной среде, кроме возможности имитационного моделирования? Список и приоритеты.

Андрей, Вы хотите всего и сразу - уже в течение этой недели. Если бы все было так просто, системы все бы только и лепили - хорошие и разные. А почему-то все не так. Чем крупнее система, тем почему-то меньше видим примеров.

> 4) Если новое ядро к 2009 году – это автоматически означает, что задача поддержки старого ядра в ближайшие 3 года перестает быть приоритетной. Устраивает это пользователей и партнеров или нет?

Что можно будет сделать без обрушения системы, будем делать. Но Вы должны и понимать, что даже эти переделки должны быть направлены к будущим целям. Иначе стиль работы, известный как "латание дыр", станется всегда. Лично мне этого не хочется. Если бы было меньше временнОго прессинга сейчас, то и ядро бы мы могли сделать много быстрее, чем к 2009г. Во всяком случае такое, которое достаточно для решения Ваших задач, может быть готово много раньше.

> 5) Вопрос совместимости на уровне API и как разделить ответственность…

А вот это как раз и есть одна из главных целей. Только не надо забывать, что "под API" лежит определенная архитектура, и API должен содержать эффективно работающие функции, а не просто "функционирующие". А это значит, что в вопросах эффективности функций API определяющую роль играет как раз архитектура системы.

> Вот пока, отвечая сам себе на эти вопросы, в соответствии с собственными приоритетами и приоритетами наших пользователей, я прихожу к выводу, что лучше модифицировать старое ядро под задачи анализа

"Модифицировать старое ядро" - это и есть изменение его архитектуры. В рамках существующих структур данных это сделать можно, но времени может уйти до того же 2009г.

> ...и может быть (это обсуждаемо) моделирование вывести за ядро в отдельное приложение - это будет и быстрее реализовано, и можно будет посмотреть, насколько востребовано.

Насчет моделирования я уже сказал. Это не есть "сбоку бантик". Можно не стремиться сразу же реализовывать ИМИТАЦИОННОЕ моделирование. [b]Ну так никто к этому и не стремится, и не говорил даже.[/b] Имитационная компонента - это то, что будет позже надстроено над ядром, а не сразу. Речь идет лишь о создании инструментального ядра, которое может обслуживать В ПЕРСПЕКТИВЕ и подсистему имитационного моделирования. К 2009г. будет основа для этого. А Ваши задачи, думаю, по пути будут решены раньше как промежуточный этап развития системы.

С уважением, Вадим