Без заголовка

прошу прощения за отвлечения от основной темы. Хочу у вас немного уточнить про метафору. Мне раньше (неправильно) представлялась следующая аналогия и следующий процесс... У нас есть некоторая БольшаяЗапутаннаяЗадача - предметная область, в которую включены как некоторые внешние процессы, так и еще не формализованные процессы пользователей. Для того, чтобы _понимать_ эту задачу необходима какая-то формализация. Формализация - как процесс некоторых выделений, акцентов, группировок (каким-то образом). Многие упускают то, что в скобках. На мой взгляд то что в скобках - и есть метафора. Метафора руководит формализацией. Даже простое пересказывание чужого текста накладывает специфику какого-то выбранного подохода. Например, формализация в терминах объектов: у нас есть объект, он имеет состояние, которое так-то изменяется. Формализация в терминах процессов: есть процессы и данные, процессы сквозят по слоям данным. Формализация в терминах агентов - у нас есть что-то, что коммуницирует, локально договаривается или делает выводы, исходя из локальных правил ("бежать куда и все"). Формализация в терминах каких управляющих точек ( у нас есть следующие параметры порядка, все остальное - не имеет значения). Хочу отметить, что формализация, думаю, гораздо теснее связана со схемой мышления (метафорой), чем привычно думать. Да, обычно разделяют 1) требования (анализ) 2) реализация (архитектура) . При это (мне казалось) считается, что 1 - нечто априорное, второе - как раз и зависит от методологии, конкретных способов и подходов. Здесь же я хочу у вас уточнить, считаете ли возможным, верным - сильное влияние способа _видения_ именно на этап требований, представления системы. Когда через метафору выбранна какая-то формализация, мы можем переходить к выработке (разработке) какой-то формальной схемы. А именно, жесткого способа который переводит Предметную Область в Комьютерно Формализированную Схему. При этом нужно задавать вопрос - насколько хорошо заданная формальная схема отражает формализацию. Здесь (могу пояснить..) схема предоставляет часто большее, чем формализация, а именно "неявные возможности использования", "продолжения математ. конструкций схемы" могут не совсем совпадать с формализацией. Теоретически, существует эквивалентность между различными формальными схемами (к примеру fastinfost, relaxng compact style, plain xml эквивалентны через infoset), существует эквивалентность между различными формализациями (например, в ряде случаев можно построить эквивалентность между процессы над данными и объектами) Да, метафора служит для понимания СложнойЗадачи. Для именования, для определения каким образом мы _видим_ систему. Rest Architecture Style (представления веб как связку ресурсы, репрезентации, и изменения состояния с помощью перехода между различными реперезантациями. Существительные (Ресурсы) как пермалинки и унифицированные GET/POST/DELETE глаголы), на мой взгляд - ИМЕННО метафора. Аналогично, на мой взгляд, другие видения Web-а - тоже метафоры. После уже которых идут формализация, формальные схемы, архитектуры для схем, конкретные программные реализации. Метафора - если совсем уже образно _общий контекст_. Только - как ни странно - этот контекст влияет, и может быть разным... Поэтому у меня и возникла такая аналогия, и поэтому пока не совсем понятен "отказ" (я, к сожалению, о нем не знал). Прошу прощения за сумбурное и неточное рассуждение. Если что-то покажется вам интересным, или напротив, вы видите, в чем я заблуждаюсь, буду рад услышать конкретные ремарки и выводы. :)