Здравствуйте, LaptevVV, Вы писали:

LVV>Когда я преподавал технологию программирования,
LVV>я с удивлением обнаружил, что нет четкого понятия "архитектура системы"
LVV>и тем более нет понятия "хорошая" и "плохая" архитектура.

Да, я это тоже обнаружил. И ещё обнаружил забавный аспект: значимость хорошей архитектуры существенно возрастает при ограниченности ресурсов, например, если пишешь программу один или на пару с кем-то. Если работает толпа людей, то архитектура... здесь важнее наличие спецификаций и манагёров процесса. Шаблоны гораздо проще использовать в одиночку, чем заниматься обучением огромной команды. Зачастую это просто невозможно. На мой взгляд, где-то здесь и зарыта причина популярности конгломератных языков типа Java или C++ в его C-like ипостаси. Lisp, например, пока не завоевал такого же места под солнцем, а, ИМХО, жаль.

LVV>Вообще, даже слова "объектно-ориентированная архитектура" как-то не принято говорить.

ИМХО, совершенно справедливо, поскольку архитектура включает в себя компоновку сущностей и их свойств, следовательно объектов, следовательно архитектуры без ОО-подхода в том или ином виде не бывает.

LVV>ООпроктирование, ООподход, ООпрограммирование — но мне даже у Г.Буча не попадалось (может пропустил, или забыл — поправьте) ООархитектура.
LVV>А тем более — не ООархитектура.
LVV>А термин "хорошая" — это вообщее из области эмоциональных оценок.
LVV>А нужны ФОРМАЛЬНЫЕ критерии.
LVV>Что уважаемый форум думает? Особенно о формальных критериях оценки "хорошести"

ИМХО, формальные критерии оценки качества архитектуры нужно рассматривать только в свЯзи с экономикой ЖЦ программы. Идельная архитектура, ИМХО, ведёт к тому, что мы получаем программу с минимиальными расходами:
— вычислительных мощностей;
— людских ресурсов при разработке;
— людских ресурсов при доработках (независимо от того, каковы они).

Таких, естественно, не бывает, но, ИМХО, можно вывести несколько примерных признаков хорошей архитектуры. Собственно, это тоже ИМХО, относительно которого готов принять любую критику:

1. Символы программы организуются в чёткие подсистемы, модификация которых не вызвает необходимости модификации других подсистем.

Rational Систему проще анализировать.

2. Подсистемы используются декларативным порядком, т.е., факт объявления подсистемы и установления связей с другими подсистемами "автоматически" влечёт за собой адекватное изменение поведение системы.

Rational Системой проще пользоваться, повышается наглядность. Граф статических связей проще проанализировать, чем граф выполнения.

3. Объявление использования символа состоит из трех символов: символ, характеризующий набор операций (тип), символ метахарактеристики (связь с надсистемой), собственно символ.

Rational Такое использование проще всего уяснить (один символ типа — один метод использования) и в тоже время остаётся относительная свобода для модификаций за счёт символа метахарактеристики.

4. Для эволюционного цикла ОО-архитектур: строгое соблюдение LSP.

Rational Нарушение LSP свидетельствует о том, что существует некоторая "неосознанная" система взаимодействий между сущностями. А раз она неосознана и неисследована — жди беды. Фактически, наследование выполняет роль как раз того самого символа метахарактеристики из критрия 3.

Отсюда можно вывести оценки архитектуры для паттернов проектирования. Например, паттерн Adapter хорош тем, что удовлетворяет: критерию 1, поскольку организует взаимодействие с нижележащими символами в собственную систему; критерию 2, поскольку его использование влечёт за собой использование нижележащих подсистем и критерию 3, поскольку объявление использования адаптера состоит только из двух символов: имя сущности и типа адаптера.

Ну вот так. Список, естественно, можно продолжить.

Здравствуйте, LaptevVV, Вы писали:

LVV>я с удивлением обнаружил, что нет четкого понятия "архитектура системы"

Для разных систем оно разное. В целом это некий костяк, на который навешивается код, реализующий требуемую функциональность.

LVV>и тем более нет понятия "хорошая" и "плохая" архитектура.

Хорошая архитектура это такая архитектура, которая позволит достигнуть при разработке хороших результатов, плохая соотв. наоборот.

LVV>Вообще, даже слова "объектно-ориентированная архитектура" как-то не принято говорить.

Потому что архитектура к ООП имеет опосредованное отношение.

LVV>А нужны ФОРМАЛЬНЫЕ критерии.

Формальный критерий — количество затрат на наращивание функционала.

Здравствуйте, LaptevVV, Вы писали:

LVV>Когда я преподавал технологию программирования,
LVV>я с удивлением обнаружил, что нет четкого понятия "архитектура системы"
LVV>и тем более нет понятия "хорошая" и "плохая" архитектура.
LVV>Вообще, даже слова "объектно-ориентированная архитектура" как-то не принято говорить.
LVV>ООпроктирование, ООподход, ООпрограммирование — но мне даже у Г.Буча не попадалось (может пропустил, или забыл — поправьте) ООархитектура.
LVV>А тем более — не ООархитектура.
LVV>А термин "хорошая" — это вообщее из области эмоциональных оценок.
LVV>А нужны ФОРМАЛЬНЫЕ критерии.
LVV>Что уважаемый форум думает? Особенно о формальных критериях оценки "хорошести"

При разработке системы можно выделить 5 основных вещей:

1. функциональные требования
   
2. спецификации системы
   
3. архитектура системы (мне лично больше нравится английское design, произносимое на русский лад)
   
4. код
   
5. тесты

Функциональные требования описывают те функции,
которые нужно предоставить пользователю (заказчику).
Грубо говоря, это то, что хочет заказчик.

По функциональным требованиям группа разработчиков разрабатывает
спецификации системы. Спецификации системы описывают что должна делать
система, для того, чтобы предоставить ту функиональность, которая нужна пользователю.
Очень важно, чтобы спецификации описывали только то, что должна делать система,
а не то, как она это должна делать.

Следующий уровень — это собственно архитектура системы
(еще раз повторюсь, считаю русский термин не совсем адекватным).
Архитектура описывает уже КАК должна быть устроена система и ЧТО она должна делать,
чтобы удовлетворять спецификациям.
Часто выделюят так называемый high level design (HLD) и low level design (LLD).
В HLD обычно описывают подсистемы, модули и их интерфейсы.
LLD — это описание того, что крупными кусками описано в HLD.
В LLD могут быть включены диаграммы классов (если мы говорим о С++),
спецификации классов и методов, диаграмы состояний и пр...

Про код и тесты думаю все понятно.

Такое вот место у архитектуры системы среди остальных вещей...

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

Что касается "хорошести"/"плохости" архитектуры системы,
то можно, кроме метрик, воспользоваться контрольными списками (check lists),
доступными в интернете.
Попробуй в гугле поискать по ключевым словам "software design review checklist"
Ссылок будет довольно много...

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

Паттерны проектирования — чем не элементы архитектуры?

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

Что касается хорошо или плохо, то для меня лично только практика
может дать ответ на этот вопрос.
Кстати, экспертная оценка — это тоже неплохой способ оценки архитектуры.
Т.е. если попросишь зубров-архитекторов оценить архитектуру системы,
то в итоге получишь ценное мнение, которое и будет оценкой "хорошести", "плохости".
Архитектура системы ведь рассчитана на человека.
Она должна быть удобной именно для человека, может потому логичнее,
чтобы оценивал архитектуру именно человек?

Hello, LaptevVV!
You wrote on Sat, 23 Aug 2003 11:49:13 GMT:

[]

Архитектура системы — это ее скилет. Бывает ли скилет хорошим? Я думаю, нет.
Если он есть — это уже хорошо.
Каким образом можно определить, если у системы (программы, библиотеки,
функции, класса и т.д.) архитектура? Вопрос сложный.
Если бы существовали четкие критерии, возможно, ИТ индустрия была бы
совершенно на другом уровне. Как говорит Страуструп, ничего не может
заменить опыт и хороший вкус в этом деле.
Я лично, под архитектурой всегда понимаю четкое строение системы,
"правильные" взаимосвязи, соблюдение ОО принципов (инкапсуляция, повторное
использование кода посредством наследования и делегации, использование
гибких структур и другое). Когда система мне не кажеться гармоничной — я ее
передумываю и затем, возможно, переделываю или переписываю заново.
Для проектных решений (или библиотек) здесь идет речь о изнемении (работе
над) UML диаграммами. Для программ, классов или простых функций — работа с
кодом. Т.е., как правило, для функций не имеет никакого смысла, составлять
UML диаграмму (например, диаграмму взаимодействия). Это (одна функция или
небольшой класс) слишком малая абстракция.
При разработке архитектуры системы большое внимаение нужно уделять шаблонам.
В хорошо спроектированной системе использование шаблонов очень
распространено. Не стоит это воспринимать, как то, что шаблоны просто
обязаны использоваться. Просто, они сами приходят на ум, в результате поиска
наилучшего решения или редизайна. Я их повсеместно использовал до того, как
взял в руки первую книгу о шаблонах. Кстати, читать так подобные книжки
намного интереснее, потому что перед глазами встают реальные примеры из
собственного кода.
Архитектура должна быть реализуемой, прозрачной, согласованной и
непротиворечивой. Хотя эти параметры не имеют абсолютной шкалы оценки (у
каждого она своя), но, по крайней мере, архитектор должен стремиться
улучшить это показатели.
Существует масса материала, в котором делаються попытки формализовать методы
оценки, например:
— в хорошо спроектированной системе повторное использование кода велико
— в хорошо спроектированной системе просто разобраться
— хорошо спроектированнуй систему лекго модифицировать и поддерживать
и т.д.
Их можно, конечно, взять в расчет, но я считаю, что все же опыт и интуиция
важнее.
Например, с помощью .net framework моя программа может состоять практически
полностью из заранее написанного, готового кода. Но это не значит, что она
будет действительно хороша. Здесь важен комплексный подход.
На эту тему можно рассуждать очень долго: масса нюансов, литературы,
подходов и т.д. ИМХО, вопрос слишком общий. В данном конкретном проекте есть
смысл спорить и разбираться. А так вопрос выглядит риторическим.

With best regards, Alex Shirshov.

Здравствуйте, LaptevVV, Вы писали:

LVV>Когда я преподавал технологию программирования,
LVV>я с удивлением обнаружил, что нет четкого понятия "архитектура системы"
LVV>и тем более нет понятия "хорошая" и "плохая" архитектура.
LVV>Вообще, даже слова "объектно-ориентированная архитектура" как-то не принято говорить.
LVV>ООпроктирование, ООподход, ООпрограммирование — но мне даже у Г.Буча не попадалось (может пропустил, или забыл — поправьте) ООархитектура.
LVV>А тем более — не ООархитектура.
LVV>А термин "хорошая" — это вообщее из области эмоциональных оценок.
LVV>А нужны ФОРМАЛЬНЫЕ критерии.
LVV>Что уважаемый форум думает? Особенно о формальных критериях оценки "хорошести"

Понятность, эффективность, функциональность, стоимость внедрения, разработки — все это признаки качества.
Все это естетвенно привязано к опредленной предметной области.

Когда я преподавал технологию программирования,
я с удивлением обнаружил, что нет четкого понятия "архитектура системы"
и тем более нет понятия "хорошая" и "плохая" архитектура.
Вообще, даже слова "объектно-ориентированная архитектура" как-то не принято говорить.
ООпроктирование, ООподход, ООпрограммирование — но мне даже у Г.Буча не попадалось (может пропустил, или забыл — поправьте) ООархитектура.
А тем более — не ООархитектура.
А термин "хорошая" — это вообщее из области эмоциональных оценок.
А нужны ФОРМАЛЬНЫЕ критерии.
Что уважаемый форум думает? Особенно о формальных критериях оценки "хорошести"

Здравствуйте, LaptevVV, Вы писали:

LVV>Что уважаемый форум думает? Особенно о формальных критериях оценки "хорошести"

Формальными оценками являются метрики, и в этой области есть много нароботок.

-zork

Здравствуйте, ZORK, Вы писали:

LVV>>Что уважаемый форум думает? Особенно о формальных критериях оценки "хорошести"

ZOR>Формальными оценками являются метрики, и в этой области есть много нароботок.

Знаю, скачал несколько английских книжек на эту тему. Но....
Кто-нить у НАС РЕАЛЬНО использовал это дело?
Спорить могу, что нет!
Так и рассуждаем на уровне хороший-плохой.
Слава Богу, стали книжки появляться не только о том, как надо программировать, но и о том, как НЕ НАДО этого делать.

Здравствуйте, LaptevVV, Вы писали:

LVV>Кто-нить у НАС РЕАЛЬНО использовал это дело?
LVV>Спорить могу, что нет!
LVV>Так и рассуждаем на уровне хороший-плохой.

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

-zork

Чисто сама по себе архитектура для того, чтобы являться хорошей, должна удовлетворять нескольким характеристикам, например: отсутствие цилклической зависимости между классами и т.д....
Но архитектура делается для того, чтобы её реализовали, и критерии "хорошести" нужно выводить отсюда, например, для меня это:
Если Тп — предполагаемое время реализации, Tр — реальное время, за которое была реализована, то архитектура хорошая, когда Tp/Tn <= 2. Для более серьёзных мужиков, цифра, будет стремиться к 1.

Здравствуйте, Gasy, Вы писали:

G>Если Тп — предполагаемое время реализации, Tр — реальное время, за которое была реализована, то архитектура хорошая, когда Tp/Tn <= 2. Для более серьёзных мужиков, цифра, будет стремиться к 1.

Кажется мне, что это не правильный и опастный критерий. Коэфицен близкий к 1, получается при программировании в тупую: пишем кусок; смотрим время; умножаем на количество кусков; размножаем их копированием, а на сложной архитектуре результат скорее всего будет сильно хуже — так как пойдет несопряжение и т.д. Также он не учитывает то как эта штука потом будет работать.

-zork

ZOR>Кажется мне, что это не правильный и опастный критерий. Коэфицен близкий к 1, получается при программировании в тупую: пишем кусок; смотрим время; умножаем на количество кусков; размножаем их копированием, а на сложной архитектуре результат скорее всего будет сильно хуже — так как пойдет несопряжение и т.д. Также он не учитывает то как эта штука потом будет работать.

Естественно не учитывает, но это и не нужно, так как есть такой дядька как заказчик, и для программерской конторы задача первой важности — удовлетворить закзчика за минимальные сроки и максимальные деньги. Так вот, архитектор строит архитектуру и говорит, что мы удовлетворим его за Tn (исчисляется в человекоднях, отсюда считается и себестоимость проекта), а в реале получается Tр... При этом заказчик говорит, согласен ли он на это время и на эти деньги.
Про куски я как-то не очень понял. Наверное имется в виду, что умножаем на предпологаемое количество кусков? Запаришься таким образом стремиться к единице, так как первый кусок я могу написать очень быстро, но если проект больше, чем 1 человекомесяц, то без маломальской архитектуры, скорее всего придётся ни раз переписывать, а последние куски будут длиться очень долго...

Здравствуйте, Gasy, Вы писали:

G>Естественно не учитывает, но это и не нужно...

То есть как это будет работать и дальше развиваться, это не важно, главное чтоб заказчик был доволен? Да уж

-zork

ZOR>То есть как это будет работать и дальше развиваться, это не важно, главное чтоб заказчик был доволен? Да уж

Если это будет работать плохо, то заказчик останется точно недовольным. Если нужно, чтобы программа развивалась, то это решают вначале, делают соответствующую данным требованиям архитектуру, которая может быть плохая или хорошая по моему критерию.

Здравствуйте, Alexey Shirshov, Вы писали:

AS>Архитектура системы — это ее скилет. Бывает ли скилет хорошим? Я думаю, нет.

Скелет

AS>При разработке архитектуры системы большое внимаение нужно уделять шаблонам.
AS>В хорошо спроектированной системе использование шаблонов очень
AS>распространено. Не стоит это воспринимать, как то, что шаблоны просто
AS>обязаны использоваться. Просто, они сами приходят на ум, в результате поиска
AS>наилучшего решения или редизайна. Я их повсеместно использовал до того, как
AS>взял в руки первую книгу о шаблонах. Кстати, читать так подобные книжки
AS>намного интереснее, потому что перед глазами встают реальные примеры из
AS>собственного кода.

Это не архитектура, это реализация.

AS> — в хорошо спроектированной системе повторное использование кода велико
AS> — в хорошо спроектированной системе просто разобраться
AS> — хорошо спроектированнуй систему лекго модифицировать и поддерживать
AS>и т.д.

Это в общем то тоже

AS>Например, с помощью .net framework моя программа может состоять практически
AS>полностью из заранее написанного, готового кода. Но это не значит, что она
AS>будет действительно хороша. Здесь важен комплексный подход.

И это тоже.

Здравствуйте, LaptevVV, Вы писали:

LVV>Когда я преподавал технологию программирования,
LVV>я с удивлением обнаружил, что нет четкого понятия "архитектура системы"
LVV>и тем более нет понятия "хорошая" и "плохая" архитектура.

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

и другие.

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

LVV>Вообще, даже слова "объектно-ориентированная архитектура" как-то не принято говорить.

Естественно. Это все равно, что говорить "архитектура кирпичного дома".

LVV>А термин "хорошая" — это вообщее из области эмоциональных оценок.
LVV>А нужны ФОРМАЛЬНЫЕ критерии.

Можно измерять примерно как оптимальность алгоритма — решение задачи с наименьшими
затратами. Только в очень общем смысле. Скажем, можно провести оптимизацию алгоритма,
затратив N человеко-лет, и увеличить производительность вдвое. А можно взять комп
в 2 раза быстрее прямо сейчас, затратив в 10 раз меньше средств. Вот это пример
оптимального архитектурного решения, при неоптимальном программном.

Здравствуйте, LaptevVV, Вы писали:

LVV>Когда я преподавал технологию программирования,
LVV>я с удивлением обнаружил, что нет четкого понятия "архитектура системы"
У Буча архитектура определяется как (по памяти, так что прошу прощения за неточность, основной момент выделен) совокупность тактических и стратегических решений при создании программного продукта.
LVV>и тем более нет понятия "хорошая" и "плохая" архитектура.
LVV>Вообще, даже слова "объектно-ориентированная архитектура" как-то не принято говорить.
LVV>ООпроктирование, ООподход, ООпрограммирование — но мне даже у Г.Буча не попадалось (может пропустил, или забыл — поправьте) ООархитектура.
LVV>А тем более — не ООархитектура.
LVV>А термин "хорошая" — это вообщее из области эмоциональных оценок.
LVV>А нужны ФОРМАЛЬНЫЕ критерии.
А вот с этим, опа
LVV>Что уважаемый форум думает? Особенно о формальных критериях оценки "хорошести"

А> Скажем, можно провести оптимизацию алгоритма,
А>затратив N человеко-лет, и увеличить производительность вдвое. А можно взять комп
А>в 2 раза быстрее прямо сейчас, затратив в 10 раз меньше средств. Вот это пример
А>оптимального архитектурного решения, при неоптимальном программном.

А можно подождать 10 лет, когда компы будут в 100 раз быстрее. =)

LVV>Когда я преподавал технологию программирования,
LVV>я с удивлением обнаружил, что нет четкого понятия "архитектура системы"
LVV>и тем более нет понятия "хорошая" и "плохая" архитектура.
LVV>Вообще, даже слова "объектно-ориентированная архитектура" как-то не принято говорить.
LVV>ООпроктирование, ООподход, ООпрограммирование — но мне даже у Г.Буча не попадалось (может пропустил, или забыл — поправьте) ООархитектура.
LVV>А тем более — не ООархитектура.
LVV>А термин "хорошая" — это вообщее из области эмоциональных оценок.
LVV>А нужны ФОРМАЛЬНЫЕ критерии.
LVV>Что уважаемый форум думает? Особенно о формальных критериях оценки "хорошести"
Так!
Пока все разговоры — на уровне беллетристики: Это хорошо, потому, что — хорошо, а это плохо, потому, что — плохо!"
А между прочим, вопрос оказывается очень даже не простой, тянет на докторскую диссертацию, если удастся это дело формализовать и как-то классифицировать.
Раз уж термин из строительства, то может говорить об архитектурном стиле?
Классицизм там, барокко, ампир ...
У нас есть такие аналоги?
Я например, знаю только два способа реализации (или архитектуры ? ):
послойный метод Дейкстры
объектный метод (кого?)

Проектирование от процессов (DFD) и от объектов — это проектирование архитектуры?
SADT — это что?
Вообще, если о строителях говорить,то где у нас архитектурный проект, а где
инженерный. А проект производства работ — это, я понимаю, план-график исполнения.

Здравствуйте, Gasy, Вы писали:

G>Чисто сама по себе архитектура для того, чтобы являться хорошей, должна удовлетворять нескольким характеристикам, например: отсутствие цилклической зависимости между классами и т.д....
G>Но архитектура делается для того, чтобы её реализовали, и критерии "хорошести" нужно выводить отсюда, например, для меня это:
G>Если Тп — предполагаемое время реализации, Tр — реальное время, за которое была реализована, то архитектура хорошая, когда Tp/Tn <= 2. Для более серьёзных мужиков, цифра, будет стремиться к 1.


Ну, если уж на то пошлО, то пусть у нас есть 2 варианта архитектуры, так вот лучше будет та, у которой Тр меньше.
А по твоему критерию молучается, что если завысить на порядок предполагаемое время ("на всяк случай"), а потому как-то что-то склепать, то получится идеальная архитектура...

Здравствуйте, LaptevVV, Вы писали:

LVV>Когда я преподавал технологию программирования,
LVV>я с удивлением обнаружил, что нет четкого понятия "архитектура системы"
LVV>и тем более нет понятия "хорошая" и "плохая" архитектура.
...
LVV>Что уважаемый форум думает? Особенно о формальных критериях оценки "хорошести"

В моем понимании хорошей архитектуре присущи несколько качеств :

1) ПРОСТОТА ИСПОЛЬЗОВАНИЯ. Любая хорошо спроектированная архитектура должна "скрывать" от разработчиков, которые ее используют, детали реализации, предоставляя удобный для использования интерфейс. Здесь можно привести аналогию, например, с коробкой передач в автомобиле. Когда мы переключаем передачи, на самом деле внутри коробки перемещается уйма шестеренок, но все, что требуется от нас — выжать педаль сцепления и передвинуть рычаг из одной позиции в другую.

2) РАСШИРЯЕМОСТЬ. Должна быть возможность добавлять в архитектуру новые "фичи", не перетряхивая при этом весь уже имеюшийся код.По собственному опыту, для новой предметной области крайне редко удается создать такую архитектуру с "первого захода", обычно она "устаканивается" в течении нескольких итераций, пока не станет более-менее стабильной.

3) ПРОИЗВОДИТЕЛЬНОСТЬ. Любая архитектура, какой бы красивой и элегантной она не была, малополезна, если код с ее использованием сильно тормозит работу программы. За универсальность всегда приходится платить, но здесь важно найти некую золотую середину, чтобы все это работало достаточно быстро.

4) НАДЕЖНОСТЬ. Если при использовании архитектуры или фрамеворка у разработчиков нет достаточной уверенности, что код, реализующий архитектуру, стабильно работает, это ни к чему хорошему не приведет. Опять же по собственному опыту, одно из наиболее полезных средств здесь — unit-тесты. Можно спокойно менять дизайн для обеспечения пп 1)-3), не боясь, что что-то кардинально сломается — unit-тесты в любой момент покажут, все ли нормально. Естественно, чтобы это все работало, unit-тестами должно быть "прикрыто" подавляющее большинство критичных мест архитектуры. Насчет этого хорошо сказал один из разработчиков, по-моему, Рон Джефриз. Когда его спросили , для всего ли кода надо делать unit-тесты, он сказал : -Нет, только для того, что вы хотите чтобы работало.

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

P.S.
Это все IMHO.