Введение

Представьте себе самое красивое из когда-либо виденных вами зданий - быть может, Тадж-Махал или Нотр-Дам. Достоинства той и другой конструкции не поддаются описанию. Хотя во многих отношениях оба строения архитектурно просты, но идеи, заложенные в них, исключительно глубоки. Во-первых, вы сразу распознаете определенную симметрию. Приглядитесь внимательнее, и вы замети­те детали, которые красивы сами по себе, но в совокупности привносят изящество и функциональность в большей степени, чем по отдельности.

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

Что же отличает эти два вида гражданской архитектуры? Во-первых, в величественных зданиях мы видим изящество дизайна, которого явно не достает забегаловкам. В настоящей архитектуре (см. главу 2) используется не так уж много стилей, которые удачно сочетаются друг с другом. Например, в конструкции Тадж Махала повсеместно применяются сложные, симметричные и сбалансированные геометрические элементы. Во-вторых, в тех зданиях, которые спроектированы с( вкусом, мы обнаруживаем общие структуры, которым подчинены все отдельные элементы конструкции. Так, в Нотр-Даме некоторые стены являются несущими и служат опорой куполу собора. А часть из них, вместе с другими архитектурным деталями, используется для отвода воды и нечистот.

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

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

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

В UML механизмы моделируются с помощью коопераций. Кооперация име­нует совокупность концептуальных строительных блоков вашей системы, вклю­чая как структурные, так и поведенческие элементы (структурное моделирование описывается в частях 2 и 3 данной книги, а поведенческое - в частях 4 и 5). На­пример, можно рассмотреть распределенную систему управления информацией, база данных которой размещается на нескольких узлах. С точки зрения пользова­теля обновление представляется атомарной операцией. Если же взглянуть на нее изнутри, все окажется не так просто, поскольку в обновлении участвует несколь­ко машин. Для создания иллюзии простоты необходимо ввести механизм транз­акций (Transactions), с помощью которого клиент сможет присвоить имя некоей операции, которая представляется единой атомарной операцией, несмотря на то что затрагивает несколько баз данных. В работе такого механизма могли бы при­нимать участие несколько кооперирующихся классов, совместно обеспечивающих семантику транзакции. Многие из них будут вовлечены и в другие механизмы, на­пример обеспечения устойчивого хранения информации. Такой набор классов (структурная составляющая), взятый вместе с взаимодействиями (см. главу 15) между ними (поведенческая составляющая), и образует механизм, который в UML представляется кооперацией.

Кооперации не только именуют системные меха­низмы, но и служат для реализации прецедентов (см, главу 16) и операций (см. главы 4 и 9).

Кооперация в UML изображается, как показано на рис. 27.1. Эта нотация позволяет визуализировать струк­турные и поведенческие строительные блоки системы особенно в ситуациях, когда они перекрываются с клас­сами, интерфейсами и другими элементами.

Примечание Эта нотация позволяет визуализировать кооперацию как единый фрагмент по отношению к внешним элементам. Но более интересно то, что находится внутри кооперации. Раскройте ее, и вы увидите другие диаграммы, из которых наиболее важны диаграммы классов (структурная составляющая кооперации, см. главу 8) и диаграммы взаимодействий (ее поведенческая составляющая, см. главу 18).