Образцы и архитектура

Занимаясь разработкой архитектуры новой системы или развитием существу­ющей, вы в любом случае никогда не начинаете с нуля (см. главу 2). Напротив, прежний опыт и принятые соглашения наводят вас на мысль применить типичные способы для решения типичных проблем. Например, при построении системы, ак­тивно взаимодействующей с пользователем, вы можете прибегнуть к испытанному подходу «модель-вид-контроллер, который позволяет четко отделить объекта (модель) от их представления (вида) и от агентов, обеспечивающих синхрониза­цию между тем и другим (контроллеров). Аналогично при создании системы для дешифровки доказала свою полезность архитектура на основе «классной доски» (blackboard), хорошо приспособленная для решения сложных задач методом проб и ошибок.

То и другое является примером образцов, или паттернов, - типичных решений для типичных задач в данном контексте. Любая хорошо структурированная систем?

изобилует образцами на разных уровнях абстракции. Образцы проектирования описывают структуру и поведение сообщества классов, архитектурные образцы -структуру и поведение системы в целом.

Образцы входят в UML просто потому, что являются важной составляющей словаря разработчика. Явно выделив образцы в системе, вы сделаете ее более по­нятной и простой для развития и сопровождения. Например, если вам дадут не­известный исходный текст и попросят его модифицировать, вы будете долго недо­умевать, пытаясь понять, как его части связаны друг с другом. Вместе с тем, если вам дадут тот же текст и скажут, что перечисленные классы взаимодействуют на основе механизма публикации-подписки, вы получите гораздо более ясное пред­оставление о том, как все работает. Та же идея применима к системе в целом. Одна ^лишь фраза «система организована как набор конвейеров и фильтров» очень мно­го говорит об архитектуре системы, а понять это, просто глядя на код классов, было бы куда сложнее.

Образцы помогают при визуализации, специфицировании, конструировании и документировании артефактов программной системы. Можно заниматься пря­мым проектированием системы, выбрав подходящий набор образцов и применяя их к абстракциям, специфичным для данной предметной области, - или же обрат­ным проектированием, выявляя содержащиеся в системе образцы (хотя вряд ли этот процесс можно назвать очень продуктивным). Скорее наоборот, при поставке системы разумно было бы описать характерные для нее образцы, чтобы помочь тому, кто в дальнейшем захочет повторно использовать или модифицировать ваш код. На практике интерес представляют два вида образцов: образцы проектирова­ния и каркасы. В UML есть средства для моделирования и тех, и других. При моделировании любого образца вы обнаружите, что он, как правило, оказывается автономным в контексте некоторого большего пакета, если не считать отношений зависимости, связывающих его с остальными частями системы.

Механизмы

Механизм - это просто другое название образца проектирования, когда он применяется к сообществу классов. Например, типичная проблема проектирования, с который сталкивается программист, пишущий на языке Java, - как видоизменить класс, который умеет отвечать на некоторое множество событий, таким образом, чтобы он отвечал на события иного рода, не трогая кода исходного класса. Типич­ным решением этой проблемы является адаптер (Adaptor pattern) - структурный образец проектирования для преобразования одного интерфейса в другой. Этот образец является настолько общим, что имеет смысл дать ему название, а затем ис­пользовать в моделях всякий раз, как возникает аналогичная проблема. При моделировании механизмы проявляют себя двояко. Во-первых, как показано на рис. 28.1, механизм просто именует множество аб­стракций, которые совместно работают для обеспечения типичного поведения, Представляющего некий интерес. Такие механизмы моделируются как простые Кооперации (см. главу 27), поскольку являются всего лишь именами для сообще­ства классов. Раскрыв такую кооперацию, можно увидеть ее структурные аспекты (обычно изображаемые в виде диаграмм классов) и поведенческие (обычно изоб­ражаемые в виде диаграмм взаимодействия). Кооперации подобного типа захва­тывают разные абстракции системы; весьма вероятно, что некоторый класс будет членом нескольких коопераций.

Во-вторых, как показано на рис. 28.2, механизм именует шаблон для множества совместно работающих абстракций. Такие механизмы моделируются в виде пара­метризованных коопераций, которые в UML изображаются аналогично шаблонам классов (см. главу 9). Раскройте такую кооперацию - и вы увидите ее структурные и поведенческие аспекты. Сверните ее, и вы увидите, как образец применяется к вашей системе путем связывания частей кооперации с существующими в системе абстракциями. При моделировании механизма в виде параметризованной коопе­рации вы описываете те элементы управления и стыковки, с помощью которых можно адаптировать шаблон, меняя его параметры. Подобные кооперации мoгyт появляться в разных частях системы и связываться с различными абстракциями В приведенном примере классы Предмет и Наблюдатель образца связаны с кон­кретными классами ОчередьЗадач и Ползунок соответственно.

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