В данном случае, несмотря на то что в указанной статье есть, на наш взгляд, спорные места, автор четко обозначил, что излагает свое личное мнение. Заметьте также, что он формулирует свои замечания не «вообще», а применительно к конкретному аспекту моделирования. Это нормальное начало для обсуждения.

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

Моделирование вообще и в проектах

Прежде всего, главное: на моделировании базируется любой способ проектирования систем. Модели строятся в проектах постоянно, даже если так не называются. Другое дело, что они часто остаются на листках черновиков или «в голове» (и от этого — многие беды проектов).

Стандарты определяют, что на каждой стадии разработки системы создается модель, все более близкая к итоговой системе. Это относится не только к технике прототипирования, об этом давно говорят стандарты ГОСТ 34 для каскадных схем работы.

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

модель — это любой образ, аналог (мысленный или условный: описание, схема, чертеж, график, план, карта и т. п.) какого-либо объекта, процесса или явления;
моделирование — это исследование объектов путем построения и изучения их моделей, а также использование моделей для получения или уточнения характеристик и рационализации способов построения вновь конструируемых объектов.
Поэтому «Концепция системы» и «Техническое задание» — тоже модели системы. Более того, моделями являются многие из документов, исходных для проектирования. Так, инструкции по выполнению конкретных работ или положения о подразделениях предприятия — тоже модели, но уже не ИС, а этого предприятия (включая, может быть, его бизнес-процессы).

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

Моделирование и приближение к истине

Любая модель представляет только часть характеристик объекта, и для решения разных задач требуется строить разные модели объекта. Именно поэтому моделирование может дать истину только в «предпоследней инстанции». Понятно, что статьи и рекомендации по применению средств моделирования обладают тем же свойством!

Сказанное выше обозначим как «всеобщее правило ограниченности моделей». Из него следует, что не может существовать только один подход к моделированию систем в качестве универсального, равно как и сумма нескольких подходов в таком качестве.

Если все это покажется тривиальным, обратите внимание на следующее: регулярно приходится сталкиваться с попытками представить абсолютно все аспекты системы с помощью одного метода и одного класса моделей. И это — вовсе не UML и не IDEF0 в совокупности с IDEF1X. Как ни странно, в этих попытках используют системы дифференциальных уравнений!

Сказанное не означает, что дифференциальное исчисление вовсе не нужно в проектировании ИС или моделировании бизнес-процессов. Это показывает иное — вредность любого «уклона», будь то в «дифуры» или только в UML, EPC, ERM, DFD (пусть даже вместе взятые).