Диаграммы реализации

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

• структуры компонентов в приложении;

• структуры используемых вычислительных ресурсов.

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

Диаграмма компонентов предназначена для перечисления и указания взаимосвязей артефактов моделируемой системы.

На диаграмме компонентов применяются следующие основные типы сущностей:

• компоненты;

• интерфейсы;

• классы;

• объекты.

На диаграмме компонентов обычно используются отношения следующих типов:

• зависимость;

• ассоциация (главным образом в форме композиции);

• реализация.

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

Компонент — это физически существующий и заменяемый артефакт системы.

Это определение подчеркивает основную прагматику, на которую авторы UML, видимо, ориентировались при разработке семантики диаграмм компонентов. Речь идет о компонентом программировании.

Что же является компонентом в смысле UML? Прежде всего, это компонент в смысле сборочного программирования: особым образом оформленная часть программного кода, которая может работать в составе более сложной программы. К сожалению, такое определение слишком расплывчато: отдельная строка исходного кода также может рассматриваться как компонент, но это, видимо, не совсем то, чего мы хотим. На самом деле абсолютно формальное определение компонента в UML дать невозможно. При выделении компонентов применяются следующие неформальные критерии.

• Компонент нетривиален. Это нечто более сложное и объемное, чем фрагмент кода или одиночный класс.

• Компонент независим, но не самодостаточен. Он содержит все, что нужно для функционирования, но предназначен для работы во взаимодействии с другими компонентами.

• Компонент однороден. Он выполняет несколько взаимосвязанных функций, которые могут быть естественным образом охарактеризованы как единое целое в контексте более сложной системы.

• Компонент заменяем. Он поддерживает строго определенный набор интерфейсов и может быть без ущерба для функционирования системы заменен другим компонентом, поддерживающим те же интерфейсы.

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

Для того чтобы как-то отражать такое разнообразие типов артефактов, являющихся компонентами, в UML предусмотрены стандартные стереотипы компонентов, перечисленные в таблице 9. Помимо стандартных стереотипов, многие инструменты поддерживают дополнительные стереотипы компонентов, часто со специальными значками и фигурами, обеспечивающими высокую наглядность диаграмм компонентов.

Таблица 9. Стандартные стереотипы компонентов

Стереотип	Описание
«executable»	Выполнимая программа любого вида. Подразумевается по умолчанию, если никакой стереотип не указан
«document»	Документ любого типа, например, файл с документацией к программе
«file»	Файл с исходным кодом программы или с данными, которые программа использует
«library»	Статическая или динамическая библиотека
«table»	Таблица базы данных

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

Закончим этот раздел примером из информационной системы отдела кадров. Какие компоненты разумно выделить в этой системе? Основное назначение системы — хранить данные о кадрах и выполнять по указанию пользователя некоторые операции с этими данными. Анализирую состав операций, мы видим, что они сводятся к созданию, модификации и удалению хранимых элементов данных. Стандартным решением в таких ситуациях является применение готовой СУБД для управления данными. С точки зрения проектирования информационной системы отдела кадров целесообразно считать используемую СУБД готовым компонентом. Мы можем не заострять внимания на структуре этого компонента — она стандартна и, наверное, достаточно хорошо описана вне нашей модели. Нам достаточно определить интерфейс, с помощью которого осуществляется взаимодействия. Подавляющее большинство СУБД поддерживают интерфейс ODBC, и мы можем предположить, что такова же и используемая нами система управления базам данных.

СУБД возьмет на себя все функции по непосредственному манипулированию данными: создание, удаление и поиск записей в таблицах и т. д. Реализация операций нашей информационной системы отдела кадров сводится к некоторой последовательности элементарных операций с данными. Например, операция перевода сотрудника с одной должности на другую, видимо, потребует изменения в трех элементах данных: в данных о сотруднике и в данных о старой и новой должностях. Однако, целесообразно ли считать, что определение и выполнение самой последовательности элементарных операций с данными также является прерогативой выделенного нами компонента — СУБД. Общепринятая практика отвечает на этот вопрос отрицательно. По многим причинам лучше выделить это в отдельный компонент, обычно называемый бизнес-логикой. Наконец, мы должны предположить, что в нашей системе должен быть компонент, ответственный за пользовательский интерфейс. В первом приближении мы приходим к структуре компонентов, приведенной на рисунке 3.27, которая называется «трехуровневая архитектура».

Рисунок 3.27. Диаграмма компонентов

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

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

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

При разработке приложений, которые должны взаимодействовать с так называемыми унаследованными приложениями и данными, без диаграмм компонентов также трудно обойтись. Дело в том, что фактически единственным средством UML, позволяющим как-то описать и включить в модель унаследованные приложения и данные являются компоненты (и их интерфейсы). Сюда же относится случай моделирования физической структуры данных в базе, работать с которой требуется помимо "родной" СУБД.

Другим примером применения диаграмм компонентов является моделирование систем динамической архитектуры, то есть таких систем, которые меняют состав и количество своих компонентов во время выполнения. Например, многие приложения Интернета меняют свою конфигурацию во время выполнения в зависимости от текущей нагрузки.

Последним структурным аспектом, который необходимо обсудить, является описание размещения компонентов относительно участвующих в работе вычислительных ресурсов. В UML для этой цели предназначены диаграммы размещения. В UML 2.0 эти диаграммы переименованы в диаграммы развертывания. Если речь идет о настольном приложении, которое целиком хранится и выполняется на одном компьютере, то отдельная диаграмма размещения не нужна — достаточно диаграммы компонентов (а может быть, и без нее можно обойтись). При моделировании распределенных приложений значение диаграмм размещения резко возрастает: они являются описанием топологии развернутой системы.

На диаграмме размещения, по сравнению с диаграммами компонентов, применяются только один дополнительный тип сущности — узел и два дополнительных отношения: ассоциация между узлами и размещение компонента на узле. В остальном диаграммы размещения наследуют возможности диаграмм компонентов.

Узел — это физический вычислительный^{^[11]} ресурс, участвующий в работе системы. Компоненты системы во время ее работы размещаются на узлах. В UML узел является классификатором, т. е. мы можем (и должны!) различать описание типа вычислительного ресурса (например, рабочая станция, последовательный порт) и описание экземпляра вычислительного устройства (например, устройство COM1 типа последовательный порт). Данное различие моделируется согласно общему механизму UML: имя экземпляра узла подчеркивается, а имя типа узла — нет. На диаграмме узел представляется фигурой, изображающей прямоугольный параллелепипед.

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

Приведем пример из информационной системы отдела кадров. Допустим, что мы приняли архитектуру, приведенную на рисунке 3.27. Сколько компьютеров будет использоваться при работе данного приложения? На этот вопрос нужно отвечать также вопросом: а сколько пользователей будет у системы и сколько из них будут работать с приложением одновременно? Если имеется только один пользователь (или, хуже того, нашу систему установят "для галочки", а использовать не будут), то проблем нет — настольное приложение — один компьютер и диаграмма размещения не нужна. Допустим, что у нашей системы должно быть много пользователей и они могут работать одновременно. Тогда ответ очевиден: узлов должно быть не меньше, чем число одновременно работающих пользователей, потому что вдвоем за одним компьютером обычным пользователям работать неудобно. Скорее всего, узлов должно быть на единицу больше чем пользователей, т. к. в большинстве организаций есть специально выделенный компьютер (сервер) для хранения корпоративных данных, за которым никто не работает. Там мы и разместим нашу базу данных, в расчете на то, что нужная СУБД, скорее всего, на сервере уже установлена. Остается вопрос о размещении компонентов, реализующих бизнес-логику. Здесь возможны разные варианты: на компьютере пользователя, на промежуточной машине (сервере приложений), на корпоративном сервере баз данных. Если мы остановимся на последнем варианте (который на жаргоне называется "архитектура клиент/сервер с тонким клиентом"), то получим диаграмму, приведенную на рисунке 3.28.