У меня предложение обсудить в этой теме основные аспекты моделирования, поговорить о значении моделирования при разработе (проектировании если хотите) систем различного рода, решить для чего мы собственно строим модели и разобрать самые фундаментальные понятия.

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

Теперь предлагаю обсудить принципы моделирования, с которыми не очень согласен, из книги "Язык UML. Руководство пользователя" (Г.Буч, Д.Рамбо, И.Якобсон)
1. Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.
2. Каждая модель может быть представлена с различной степенью точности.
3. Лучшие модели - те, что ближе к реальности.
4. Нельзя ограничиваться созданием только одной модели. Наилучший способ при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга

Сильно. И в чём состоит тезис? "это всё неправильно"? Так мы слона не продадим.

Может стоит тему поуже сформулировать, а не замахиваться сразу на "Уильяма нашего, на Шекспира"? )

Теперь предлагаю обсудить принципы моделирования, с которыми не очень согласен, из книги "Язык UML. Руководство пользователя" (Г.Буч, Д.Рамбо, И.Якобсон)
1. Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.
2. Каждая модель может быть представлена с различной степенью точности.
3. Лучшие модели - те, что ближе к реальности.
4. Нельзя ограничиваться созданием только одной модели. Наилучший способ при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга

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

Присоединяюсь к предложению уточнить, с чем именно Вы не согласны в приведенной цитате?

"Любое правило, любой принцип, любое условие можно и должно подвергать сомнению, поскольку они имеют ограниченную область действия...", я не помню кто это сказал 

Ну меня, в общем, смущает немного 3й пункт...

3. Лучшие модели - те, что ближе к реальности.

Модель должна упрощать реальность. Это относится и к диаграммам, где гуру советуют не перегружать модели второстепенными элементами, из-за того что она станет визуально непонятной и сложной. И к тому же в качестве примера можно привести различные математические модели, которые бывает невозможно (по ряду причин: из-за недостаточной мощности компьютеров, развитие науки и тд), и зачастую даже ненужно уточнять, т.е. необходимо использовать определенную степень приближения. Конечно согласен, что чем подробней мы опишем систему, тем проще нам с ней будет работать в дальнейшем, но опять же точность модели зависит от поставленной задачи...

Модель должна упрощать реальность. Это относится и к диаграммам, где гуру советуют не перегружать модели второстепенными элементами, из-за того что она станет визуально непонятной и сложной. И к тому же в качестве примера можно привести различные математические модели, которые бывает невозможно (по ряду причин: из-за недостаточной мощности компьютеров, развитие науки и тд), и зачастую даже ненужно уточнять, т.е. необходимо использовать определенную степень приближения. Конечно согласен, что чем подробней мы опишем систему, тем проще нам с ней будет работать в дальнейшем, но опять же точность модели зависит от поставленной задачи...

А, ну так бы и говорили, что хотите обсудить правило максимальной адекватности модели моделируемому объекту.

Норберту Винеру приписывают слова, что "лучшей моделью кота является кот, а ещё лучше - тот самый кот".

Мне кажется, что всё-таки важно различать контекст моделирования как научного метода, и как промышленного метода.

В науке, как мы видим, систематически происходило уточнение моделей (Птолемей -> Коперник, Ньютон -> Эйнтшейна), которое сопровождалось новыми возможностями по использованию этих уточнённых моделей.

В науке правит бал беспредельное и чистое познание, не знающее преград. Цель учёного - создать как можно более точную модель, чтобы выявить новые, ранее не известные свойства объекта моделирования. Учёный ищет максимально точные, лучшие решения.

В индустрии центральное лицо - Инженер (для моделирования - инженер-исслдеователь). Его задача - поиск оптимальных моделей - т.е. максимально полезных в рамках имеющихся целей и ресурсов. Его примат - адекватность модели не только и не столько объекту моделирования, но и целям моделирования, т.е. прагматизм.

В механистических, редукционистских индустриальных подходах, таких как UML/ARIS/whatever... до последнего времени считалось, что если мы моделируем дискретную и/или реактивную систему, как это бывает в большей части современного типового бизнеса и соотв. ИС, то мы можем брать отдельные представления модели, такие как модель оргструктуры, модель бизнес-процессов, модель состояний и т.д.  и они будут в достаточной мере адекватности отражать моделируемую систему.

Холистические, системные подходы же говорят, что важны не только отдельные проекции, но и эмерджентные свойства системы, такие как "социальный капитал", "душа компании" и т.д.

В механистических, редукционистских индустриальных подходах, таких как UML/ARIS/whatever... до последнего времени считалось, что если мы моделируем дискретную и/или реактивную систему, как это бывает в большей части современного типового бизнеса и соотв. ИС, то мы можем брать отдельные представления модели, такие как модель оргструктуры, модель бизнес-процессов, модель состояний и т.д.  и они будут в достаточной мере адекватности отражать моделируемую систему.

Холистические, системные подходы же говорят, что важны не только отдельные проекции, но и эмерджентные свойства системы, такие как "социальный капитал", "душа компании" и т.д.

Отлично сказано, но... Мне, кажется , Денис ты тут переборщил.
Во-первых, не очень понимаю почему UML ARIS названы механистическими подходами. Для начала это языки описания, достаточно формализованные.
Во-вторых, холистический подход - очень красивое слово, когда системный уже не цепляет.

Моделирование столь же разнообразно, сколь и сложно.
Моделирование бывает разное. Моделирование суть инструмент. Использовать инстуремнт можно по-разному. Типичным являются два подхода: механистический от частного к целому, и системный от общего к частному. Тут естественны такие понятия как дедукция, индукция, абдукция.
Системность сама по себе предполагает эмерджетность, это одна из важных закономерностей системы.
Поэтому часто и подчеркивается, что система описывается совокупностью моделей

UML и ARIS походя названы мной "подходами" потому, что они, как и любой язык, опираются на парадигму мировосприятия, говорящую о том, что есть, что может быть, что важно, а что - нет. ARIS так явно позиционируется как методология (способ мышления о принцпах и методах моделирования), а не только язык и инструмент.

Почему именно "механицизм", цитирую:

...В более широком смысле механицизм есть метод «сведения» сложных явлений к их более простым составляющим, метод разложения целого на части, неспецифичные для данного целого (на биологические отношения, когда речь идёт о социальных явлениях, на физико-химические, когда речь идёт о биологии, и т. д.)...

...Для М. в целом как мировоззренческой установки характерно сведение сложного к простому, целого к сумме частей, отрицание качественно своеобразных законов у объектов с различным типом системной организации....

Именно это, имхо, и делают методологи моделирования Буч и Шеер - предлагают описывать целое как набор частей, не более.

То, что набор разноаспектных моделей далеко не всегда достоверно описывают систему, достаточно хорошо демонстрирует притча про 6-терых мудрецов и слона.

Да, слово "системный" порядком затаскано, без должного понимания употребляющими, которые зачастую под "системным" всё равно имеют в виду подход "аналитический, редукционистский".

Эд, скажи честно - где эмерджентность в классическом подходе 4+1?

Эд, скажи честно - где эмерджентность в классическом подходе 4+1?

Стоп, Ден, давай сначал определимся что такое классический подход 4 + 1. Подход типа RUP? Возможно я изнаю этот подход, но, вероятно, не под именем 4+1.

Далее возьмем это крассивое слово эмерджентность
emergence [I'mE:dZ(q)ns] n
1.   1) выход, появление; возникновение
emergence of seedlings - прорастание /появление/ всходов
the emergence of many new nations - возникновение многих новых государств
2) выход на поверхность
3) мор. всплытие, появление на поверхности
2.   выявление, проявление
3.   бот. эмергенцы
4.   геол. прирост (суши); отрицательное движение уровня моря

Т.е. появление какого-либо свойства отсутствующего у частей.

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

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

Однако!!! Мы все-таки говорим о моделировании, а моделирование это процесс - процесс построения модели или ее совокупностей, и процесс изучения модели с определенной целью: целью управления, целью познания, целью описания, целью соглашения, целью унификации ....

Все средства моделирования типа UML IDEF ARIS - это описательные системы моделирования, знаковые, языковые, символьные - это не все виды моделирования - а довольно узкая его часть.

"Любое правило, любой принцип, любое условие можно и должно подвергать сомнению, поскольку они имеют ограниченную область действия...", я не помню кто это сказал 

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

Определить, является ли элемент важным или второстепенным невозможно вне контекста создания и использования модели. Как отметил  выше Galogen - моделирование инструмент деятельности, но важно уточнить: инструментом оно является в контексте (деятельности) использования модели. В контексте создания модели сама модель является целевым объектом процесса создания модели. Мы можем либо верифицировать модель на соответствие правилам в процессе её создания, либо опытным путем - на соответствие целям Зазказчика модели в процессе её использования. Априорно определить второстепенные детали исходя из внутренней логики самой модели невозможно. Вне контекста можно обсуждать только наличие или отсутствие внутренних противоречий в самой модели с точки зрения внутренних правил  самой модели.

Даже если рассматривать контексты научного моделирования и моделирования практический человеческой деятельности (бизнеса) сразу можно отметить отличия, связанные с разной природой сложности моделирования в этих контестах.

Контекст практической деятельности  человека (бизнеса):
1. При моделировании человеческой деятельности мы пытаемся постигнуть логику бизнеса, которая была придумана человеком. Человеческая деятельность может носить системный характер и логика модели может быть распределенной по раличным професиональным специалиазациям. Но принципиально важно, что для устоявшихся относительно медленно изменяющихся процессов пытаться понять их логику гораздо менее рискованное занятие чем пытаться построить модель для решения научной проблемы. Применительно к практике моделирования (анализа) человеческой деятельности мы ограничены рамками интеллекта создателей (и пользователей) бизнеса. А как сказал герой одного фильма: «Что один человек собрал, другой завсегда разобрать сможет…». И это выгодно отличает с точки зрения возможностей моделирования человескую деятельность от природных процессов и явлений.
2. Субъективность целевых оснований человеческой деятельности (эмерджентность - её проявление) – наоборот, затрудняет моделирование человеческой деятельности, по сравнению с моделированием природы. Полет мысли некоторых Заказчиков существенно опережает возможности  моделирования её результатов.


Контекст научного моделирования:
В практике же научного моделирования ученый пытается постигнуть логику (замысел) природы (Лейбниц: «Cum Deus calculat, fit mundus - Как Бог вычисляет, так мир и устроен»), разрешить парадоксы и проблемы, возникшие на границе (или за гранью   разумной практики человека.
Ученый лишен возможность общаться с природой на природном человеческом языке (Галилей: «Природа разговаривает с нами на языке математики…»), еще меньше возможностей у ученого моделировать природу исходя из целей природного замысла.

Поэтому, и средства моделирования и критерии адекватности модели реальности (лучше – действительности) нужно выбирать с учетом специфики контекста. И при моделировании человеческой деятельности важно исходить из целей моделирования.
Если мы моделируем целенаправленную деятельность человека, то, как правило, он уже пользуется моделью, может быть даже несовершенной. То, что эта модель умопостижима означает, что существуют и достаточно понятные способы представления этой модели. Аппеляция к сложности природных явлений в данном случае неуместна. Если человек (Заказчик модели) осуществляющий моделируемую практику, не имеет о ней умопостижимого представления, то моделирование (из позиции аналитика) невозможно (возможно толко уже из позиции предпринимателя), а Заказчик под видом бизнеса занимается только имитацией разумной деятельности. А вот как из него (Заказчика, заинтересованного лица) эти представления вытащить – это другой разговор, для этого  надо выбирать соответствующие средства. И правила рисования диаграмм (синтаксис языка моделирования и даже семантика моделируемой предметной области) – это только часть средств моделирования.

Стоп, Ден, давай сначал определимся что такое классический подход 4 + 1. Подход типа RUP? Возможно я изнаю этот подход, но, вероятно, не под именем 4+1.

Я имел в виду The 4+1 View Model of Architecture, хотя наверное не совсем прав, т.к. этот подход говорит об описании только архитектуры, а не всей системы, а Эмерджентность присуща системам, а не их архитектуре.

Все средства моделирования типа UML IDEF ARIS - это описательные системы моделирования, знаковые, языковые, символьные - это не все виды моделирования - а довольно узкая его часть.

Хорошо, узкая. А какая ещё часть есть?

Хорошо, узкая. А какая ещё часть есть?

Семиотика моделирования:
1. Синтаксис - правила конструирования систем знаков (сложных знаков - схем, дигаграмм) из простых.
2. Семантика - смысл и значение знаковых систем
3. Прагматика - практика, приемы и способы использования знаковых систем субъектами и сообществами.

Средства моделирования, как инструменты, включают 1 и 2. Объять прагматику моделирования в форме некоторого OTC продукта вряд ли вообще возможно. Тем не менее без прагматики построение модели невозможно.

Средства моделирования, как инструменты, включают 1 и 2. Объять прагматику моделирования в форме некоторого OTC продукта вряд ли вообще возможно. Тем не менее без прагматики построение модели невозможно.

Да, теперь понял. Правда, объём прагматики определяется сложностью и гибкостью языка, объёмом пространства моделирования. Если язык моделирования очень узок (например, Тетрис), то объём прагматики стремится к нулю.

Если говорить про UML, то его прагматика описывается в RUP и различной литературе, например у тех же Рамбо-Блаха и в материалах по образцам моделирования. Если говорить про ARIS как методологию, то его прагматика также излагается в соотв. литературе Шеера и прочих Логик Бизнеса.

Если возвращаться к теме дискуссии, то можно поставить вопрос так - позволяют ли Синтаксис, Семантика и Прагматика популярных методик моделирования в достаточной степени описывать существующие и создаваемые системы? Вредит ли избыточная детализация моделей? Если да, то как её избежать?

Если возвращаться к теме дискуссии, то можно поставить вопрос так - позволяют ли Синтаксис, Семантика и Прагматика популярных методик моделирования в достаточной степени описывать существующие и создаваемые системы? Вредит ли избыточная детализация моделей? Если да, то как её избежать?

Судя по тому, что OMG продолжает разрабатывать новые средства описания предметной области:
1. Business Motivation Model (BMM) Specification
 2. Semantics of Business Vocabulary and Business Rules (SBVR)

то OMG не считает вопрос создания средств моделирования закрытым. Один замах, судя по названиям, чего стоит!
Если обсуждать  достаточность существующих средств, то нужно бы уточнить:
1.   "достаточная степень описания" - достаточная для чего?.
2.   Какие качества существующих моделей (избыточноть?), которые мы связываем с используемыми средствами моделирования,  нас решительно не удовлетворяют?
3.   Что имеется в виду под избыточной детализацией моделей? Можно ли попытаться категориально проклассифицировать ситуации такой избыточности (чем вызвана, в частности, вызвана ли они именно средствами модлеирования, в чем проявляется)? Возможно, попробовать проиллюстрировать ситуацию такой избыточной детализации на примерах из тем данного форума ?

Хорошо, узкая. А какая ещё часть есть?

Ден! Когда я рассказываю студентам о моделировании, то я примерно так начинаю. Понятие модели и моделирования имеет очень широкую интерпретацию в зависимости от контекста. И это не противоречие. Модель и моделирование понятия многозначны. Причем последнее - скорее довольно однозначно - процесс создания модели и процесс изучения модели.
Действительно - модель платья - это в нашем ООП понимании скорее некий тип платья чем модель, но тоже называется моделью. 3D-модель - просто рисунок, а может и не просто. Ну и со фа...
Моделирование тоже бывает разных типов или видов:
Полное  Неполное  Приближенное
Детерминированное Стохастическое
Статическое   Динамическое
Дискретное Дискретно-непрерывное Непрерывное
Мысленное: Наглядное, Символическое, Математическое
Реальное: Натурное, Физическое

Очевидно, что моделирование в нашем UML2 контексте будет
Детерминированное, Статическое или Динамическое, Дискретное (дискретно-непрерывное), Мысленное(Символическое и Математическое)
Но это если в полном объеме, т.е. включая структурные, информационные, имитационные, прототипирование=макетирование, языковое,  знаковое.

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

Очевидно разные стороны системы по требуют разных моделей и разных типов(видов) моделирования.

Модель - это такая вещь, которая даёт обобщённое, упрощённое, иногда - идеализированное представление о чём-либо. Её ценность - только в том, что она упрощает понимание цели и структуры целого, а также поиск его частей. Сама по себе, в отрыве от реальности и исполнителей, она ценности не имеет. Если программистам удобнее без неё, чем с ней - значит, это плохая модель.
Не уверен, что имею опыт, позволяющий оспаривать классиков, но:
"4. Нельзя ограничиваться созданием только одной модели. Наилучший способ при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга" - не согласен. Модели одной вещи всегда будут зависимы друг от друга. Понимание этой связи - IMHO основа системного подхода.
Бизнес-мотивация, "социальный капитал" и "душа компании"... Здорово, но я бы бюджета на построение таких моделей не дал. По-моему, самостоятельной ценности они не имеют. Записать всё нельзя. Не все вещи могут быть формализованы без искажения. А перечисленные вещи должны быть в голове у каждого менеджера, записывать это - всё равно, что записывать, с кем и почему дружишь.