Моделироваение/проектирование - это все равно что програмирование!
Т.е. есть задача - ее решить можно 20 способами програмирования!
А с проетированием/моделироыванием как??? То же самое!
Если придерживаясь общих правил ты сделал и договорился с участниками кк ты делаешь, ты прав?
ДА!
Ваши измышлизмы!

З.Ы. Строго не судить - я на корпоротивном НГ ....

Ну ты дал. Наверное, здорово на резался:-))

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

В нашем случае моделирование <> проектирование в любом случае.
Моделирование = системный анализ во многом, только более формализованное и опирающееся на количественные характеристики.
Говорят - системный анализ средство генерации альтернатив, моделирование средство оценивания альтернатив, но не единственное, поскольку не для каждой альтернативы удается выстроить имитационную модель, потому используют качественные методы оценивания.

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

Естественно, что у реального объекта может быть бесконечное множество моделей, и бесконечное множество реализаций. Но СА считает, что для определенной цели может быть построена самая эффективная система (а модель и есть система). Однако не всегда это удается достичь: задача не детерминирована, имеет множество неопределенностей, которые не поддаются вероятностной оценки.

Часто имено с этой целью и вводят эксперименты с моделью.

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

Моделироваение/проектирование - это все равно что програмирование!
Т.е. есть задача - ее решить можно 20 способами програмирования!

То же самое можно сказать относительно кулинарного искусства, воспитания детей, и т.д. Я не думаю, что множественность методов решения задачи можно считать хорошими критериями для сходства дисциплин.

Моделирование направлено на изучение, описание, понимание проблемы и продумывание, детализацию и описание решения. Программирование - на реализацию решений. Разница примерно такая, как между Советом в Филях и Бородинским сражением.

Да, прочитал, что написал, ужас
Но имел немного другое. Я знаю чем моделирование отличается от проектирования и програмирования. Я просто к тому что, к сожалению, нельзя сделать СЛОЖНУЮ модель 10ью профессионалами по одинаковому. И привел для сравнения програмирование, там тоже можно запрограмировать по разному одно и тоже. Просто наболело, что получается всегда разная интерпритация разными людми одной и тоже по сути модели.

Просто наболело, что получается всегда разная интерпритация разными людми одной и тоже по сути модели.

Ну это же все из-за нормального человеческого мышления ))))
Мне, кажется, можно выделить несколько причин, применительно к моделированию:
1. Разный взгляд на вещи разных людей. Естественно что человек который 15 лет был программистом в НИИ, а потом стал архитектором спроектирует другую модель, нежели человек который 15 лет проработал программером в банке...
2. Некоторым недостает знаний, а некоторым наоборот... (в разных российских книжках по UML порой пишут вещи, противоречащие друг другу)
3. Иногда модель нужно интерпритировать как это нужно заказчику, а не как идеальный вариант модели...

Думаю, что если сильно формализовать моделирование, сделать его жестким, так чтобы все моделировали по одному шаблону, тоже не лучший вариант.... 

В книге Гультяева "Визуальное моделирование в Windows (MatLab)", даже главы две есть - моделирование- как наука, моделирование - как искусство.
Т.е. нужно считать в каждой человеческой деятельности есть и творческое начало и скажем механистическое, детерминисткое. Как мне кажется, творческое начало постепенно замещается научным... но до поры до времени, когда происходит качественный скачок, опять возникает отрыв и так бесконечно (. А может и к счастью

Такие авторитеты в данной области, как РАМБО, БУЧ и ЯКОБСОН не раз подчеркивали, что существует множество АДЕКВАТНЫХ моделей одной и той же системы. Соответственно адекватных реализаций ещё больще. Дело сводится к эффиктивности той или иной реализации.

существует множество АДЕКВАТНЫХ моделей одной и той же системы.

но не равнозначно АДЕКВАТНЫХ, все-таки существует единственная модель - адекватнее других в конкретных условиях, да и реализация - наиболее оптимальная всегда одна в конкретных условиях, другое дело каковы эти условия!!!

Кроме понятие адекватности модели и есть и другие, которые не менее важные...

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

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

Вот это более глубокий вопрос. С развитием UML и накоплением опыта разработки систем, в процессе которой использовался этот язык, складывается следующая ситуация. Многие разработчики такие как М.Фаулер, С.Кук, Д.Дэниелс, Дж.Рамбо, М.Блаха и т.д отмечают тот факт, что существует несколько точек зрения на построение моделей системы. Концептуальная или аналитическая модель системы. Модели данного типа служат для представления необходимых понятий изучаемой предметной области. При их анализе внимание уделяется предметам реального мира, которые придают системы смысл, делая её тем, что она есть. Далее модель спецификации или модель приложения. Эти модели относятся к компьютерным аспектам системы. Например, меню пользователя и т.д. Объекты приложения существуют не в предметной области. Они имеют смысл только в контексте программного приложения. В данных моделях рассматриваться только интерфейсы, но не реализация системы. И последнее это модель реализации. Это и есть воплощение системы в программном коде аппаратных частях и т.д. Сюда же включаются концептуальные элементы системы входящие в модель реализации. Например, итераторы, связанные списки, деревья двоичного поиска и п.р.  Если взглянуть на данное разделение, то легко видеть неоспоримые преимущества такого подхода. Построив аналитическую модель и модель приложения, в последствии мы можем строить миллионы моделей реализации, которые МИНИМАЛЬНО будут влиять на модели анализа. Архитекторов системы  не должно волновать, каким образом будет реализован поиск учетной записи пользователя – их тысячи. С другой стороны модель реализации получается более гибкой, так как изменения в ней самой не приводят к пересмотру других моделей. Получатся, что МОДЕЛИРОВАНИЕ применяется при построении всех трёх видов моделей, а программирование только при построении МОДЕЛИ реализации – скомпилированной программы.

СногСШИБАТЕЛЬНЫЕ аргументы:-)) Повалил на обе лопатки:-)) выкидываю белое полотенце...

Единственный вопрос, а реализация МОДЕЛИ РЕАЛИЗАЦИИ - одна или их может быть много:-)

Slav, вот интересная цитата

Применительно к решаемой проблеме рассмотрим один из необходимых принципов системного анализа — прин¬цип оптимальности. Известно, что характерной чертой современного развития (а развитие — это один из прин¬ципов диалектики!) является выбор наиболее подходящего варианта ТС. В живой природе подобное совершается в виде естественного отбора, хотя имеет место и искусст¬венный отбор, например в деятельности селекционеров. В развитии ТС мы также должны иметь дело с отбором. В ходе технического освоения научных достижений важ¬но выбирать такие творческие решения, которые являют¬ся лучшими по комплексу показателей для заданных усло¬вий. Но что значит «лучшие»? Разные авторы каждый по-своему определяет этот термин (Квейд Э. Анализ сложных систем. М.: Сов. радио, 1969; Оптнер С. Системный анализ для решения деловых и промышленных проблем. М.: Сов. радио, 1969; Хитч Ч., Маккин Р. Военная экономика в ядер¬ный век. М.: Воениздат, 1964 и др.). Как воспользоваться такими определениями в каждом конкретном случае — неизвестно.
Развитие методов системного анализа позволило вне¬сти в принцип оптимальности новое содержание. «Задача заключается не в том, чтобы найти решение лучше суще¬ствующего, а в том, чтобы найти самое лучшее реше¬ние из всех возможных» (Черчмен У. и др. Введение в исследование операции. М.: Наука, 1968). 

<...>А чем моделировение отличается от програмирования<...>

IMHO отличаются уровнями абстракции от двух вещей:
--предметной области
--маш. кода и аппаратной архитектуры

Модель предметной области - ближе к предметной области. Аналитическая модель - ровно посередине. Модель архитектуры - ближе к маш.коду. Код - ещё ближе к маш. коду.

Крамольная мысль:
"Только тем, что модель компиллирует человек, а не компиллятор, причём не всегда есть формальные правила преобразования модели в код.
Хотя, учитывая
--синхронизацию моделей с кодом в современных CASE-средствах
--концепции Domain-Driven Design и Model-Driven Design
--абстракции и поддержку паттернов современными языками программирования
различия между графической моделью (например, UML-диаграммой) и "текстовой" моделью (? кодом) становятся всё более размытыми."

2 AlexTheRaven
Я немного другое имел ввиду: http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=71.msg503#msg503
Но мысль тоже интерсная, в которой (что скоро усе будем только моделировать) я убеждаю народ давно, но неверят...