Обсуждение

Agile / Agent "один_большой_распределенный_План" ~= XP "метафора" ?

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

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

Слово "метафора" употреблять для кучи поминаемых вами понятий неправильно -- тем более "метафора из XP". Вы пишете про архитектурные паттерны, дизайн-паттерны и всю эту линию "открытия паттернов, как некоторого сорта повторений" с одной стороны. Но затем вы пишете про понимание и смысл (в отличие от содержания) -- т.е. про то, что тексты/схемы понимаются в зависимости от ситуации, т.е. по отношению к тому, что нужно делать, а не сами по себе. Еще у вас там мелькает тематика онтологических картин, идеальных объектов и предметов (научных предметов). Компьютерных онтологий и метаонтологий. Понятий и категорий. И совсем чуть-чуть -- действительно, метафора/аналогия. Если честно, то я ничего не смог понять -- кроме того, что вы по чуть-чуть касаетесь каждого из этих подходов, но в какой-то смеси. Наверное, вам будет интересно почитать книжки про философскую онтологию (не компьютерную!). Тех же СМД-методологов...