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

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

G>>Первое — что такое "архитектура". Нет единого понимания данного термина, что служит поводом для спекуляций.

AL>Странно. Берем IEEE 1471-2000 и читаем:
AL>architecture:
AL>The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
AL>Далее, если говорить простыми словами, авторы стандарта показывают, что архитектура системы по сути является представлениями системы в виде двух "ящиков": "черного" -- с точки зрения взаимодействия с окружением; и "прозрачного" -- с точки зрения взаимодействия элементов внутренней структуры.

Действительно странно. Особенно странно то, что многие "серьезные дядьки" либо не знакомы с этим определением, либо не ставят его во грошь. А теперь берем базовый архитектурный курс по MCSD, и читаем там совсем другое, до крайности мутное определение, которое я даже затрудняюсь воспроизвести. Берем PSP/TSP, и не находим там термина "архитектура" вовсе. Что делать будем? Откроем википедию:

The distinction from detailed design
Software architecture, also described as strategic design, is an activity concerned with global design constraints, such as programming paradigms, architectural styles, component-based software engineering standards, design principles, and law-governed regularities. Detailed design, also described as tactical design, is an activity concerned with local design constraints, such as design patterns, architectural patterns, programming idioms, and refactorings. According to the Intension/Locality Hypothesis[9], the distinction between strategic and tactical design is defined by the Locality Criterion[9], according to which a statement about software design is non-local if and only if a program that satisfies it can be expanded into a program which does not. For example, the Client-Server style is architectural (strategic) because a program that is built by this principle can be expanded into a program which is not client server; for example, by adding peer-to-peer nodes.
Architecture is design but not all design is architectural. In practice, the architect is the one who draws the line between software architecture (architectural design) and detailed design (non-architectural design). There aren't rules or guidelines that fit all cases.

Получаем, некоторые другие авторы понимают "архитектуру" как "стратегический" дизайн, отличающийся от "тактического". И это по сути единственное, на чем все сходятся. Только и всего.

Есть разные системы определений. Каким надо пользоваться? Удобным в текущий момент, конструктивным, которое делает ситуацию очевидным. Мое тройное определение четко отделяет 100% "тактические" решения (алгоритмы и структуры данных), 100% стратегические (парадигмы и функдаментальные решения, вроде применения "клиент-сервер", плюс — прикладные фрейморки и их правила, если они есть), и те, что на границе (разбиение по модулям и прочим компонентам, и отношения между ними).

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

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

AL>Хотя можно, конечно, упереться и объявить паттерн и реализацию паттерна разными вещами и упражняться в риторике до посинения.

Давай не будем.

AL>Кстати, если рассматривать использование xml для сериализации в качестве архитектурного решения в отрыве от дизайна и ограничений на дизайн, то могут получаться удивительные по своей абсурдности вещи, как в некоторых middleware, когда для передачи по сети одного скалярного значения риалтаймовых данных с меткой времени требуется посылать по "веревке" килобайт xml-ной чепухи.

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

Еще пример — решаем, что все прикладные объекты хранят свое состояние в реляционной БД. Со всеми вытекающими, в частности — некая общая подсистема управления этим состоянием.

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

G>>Главное, архитектуру не путайте с дизайном. Думаю, как только вы мои определения почитали, вам уже все стало понятнее, не так ли? .

AL>И как же их не путать то? Может, для пользы дела примем дизайн/детальный дизайн в качестве одного из архитектурных представлений?

Следуя предложенному мной определению, не перепутать довольно легко.