Краткие теоретические сведения. Для создания конкретной физической системы необходимо реализовать все эле­менты логического представления в конкретные материальные сущно­сти

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

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

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

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

Для представления физических сущностей в языке UML применяется специаль­ный термин – компонент.

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

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

Компонент служит для общего обозначения элементов физического пред­ставле­ния модели и может реализовывать некоторый набор интерфейсов. Для графиче­ского представления компонента используется специальный символ – прямоуголь­ник со вставленными слева двумя более мелкими прямоугольниками (рис. 68). Внутри объемлющего прямоугольника записывается имя компонента и, возможно, дополнительная информация. Этот символ является базовым обо­значением компо­нента в языке UML.

Рис. 68. Графическое изображение компонента

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

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

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

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

Если компонент представляется на уровне типа, то записывается только имя типа с заглавной буквы в форме: < Имя типа>. Если же компонент пред­ставляется на уровне экземпляра, то его имя записывается в форме: < имя ком­понента ‘: ' Имя типа>. При этом вся строка имени подчеркивается. Так, в пер­вом случае (рис. 68, а) для компонента уровня типов указывается имя типа, а во втором (рис. 68, б) для компонента уровня экземпляра – собственное имя ком­понента и имя типа.

Правила именования объектов в языке UML требуют подчеркивания имени от­дельных экземпляров, но применительно к компонентам подчеркива­ние их имени часто опускают. В этом случае запись имени компонента со строчной буквы харак­теризует компонент уровня примеров.

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

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

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

Для более наглядного изображения компонентов были предложены и стали об­щепринятыми следующие графические стереотипы:

- стереотипы для компонентов развертывания, которые обеспечивают непо­сред­ственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки (рис. 69, а), Web-страницы на языке разметки гипертекста (рис. 69, б) и файлы справки (рис. 69, в);

- стереотипы для компонентов в форме рабочих продуктов. Как правило – это файлы с исходными текстами программ (рис. 69, г).

Рис. 69. Варианты графического изображения компонентов

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

Другой способ спецификации различных видов компонентов — указание тек­стового стереотипа компонента перед его именем. В языке UML для компо­нентов определены следующие стереотипы:

- < < file> > (файл) – определяет наиболее общую разновидность компо­нента, кото­рый представляется в виде произвольного физического файла;

- < < executable> > (исполнимый) – определяет разновидность компонента-файла, который является исполнимым файлом и может выполняться на компь­ютер­ной платформе;

- < < document> > (документ) – определяет разновидность компонента-файла, кото­рый представляется в форме документа произвольного содержания, не являю­щегося исполнимым файлом или файлом с исходным текстом про­граммы;

- < < library> > (библиотека) – определяет разновидность компонента-файла, кото­рый представляется в форме динамической или статической библио­теки;

- < < source> > (источник) – определяет разновидность компонента-файла, пред­ставляющего собой файл с исходным текстом программы, который после компиля­ции может быть преобразован в исполнимый файл;

- < < table> > (таблица) – определяет разновидность компонента, который пред­ставляется в форме таблицы базы данных.

Следующим графическим элементом диаграммы компонентов являются интер­фейсы. В общем случае интерфейс графически изображается окружно­стью, которая соединяется с компонентом отрезком линии без стрелок (рис. 70, а). При этом имя интерфейса, которое рекомендуется начинать с заглавной бу­квы " I", записывается рядом с окружностью. Семантически линия означает реа­лизацию интерфейса, а наличие интерфейсов у компонента означает, что дан­ный компонент реализует со­ответствующий набор интерфейсов.

Рис. 70. Графическое изображение интерфейсов на диаграмме компонен­тов

Кроме того, интерфейс на диаграмме компонентов может быть изображен в виде прямоугольника класса со стереотипом < < interface> > и секцией поддер­живае­мых операций (рис. 70, б). Как правило, этот вариант обозначения ис­пользуется для представления внутренней структуры интерфейса.

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

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

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

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

Так, например, изображенный ниже фрагмент диаграммы компонентов пред­ставляет информацию о том, что компонент с именем «Control» зависит от импор­тируемого интерфейса «IDialog», который, в свою очередь, реализуется компонен­том с именем «DataBase». При этом для второго компонента этот ин­терфейс явля­ется экспортируемым. Изобразить связь второго компонента «DataBase» с этим ин­терфейсом в форме зависимости нельзя, поскольку этот компонент реализует ука­занный интерфейс.

Рис. 71. Отношения зависимости и реализации между компонентами

Другим случаем отношения зависимости на диаграмме компонентов явля­ется отношение программного вызова и компиляции между различными видами ком­понентов.

Для рассмотренного фрагмента диаграммы компонентов (рис. 72) наличие подобной зависимости означает, что исполнимый компонент «Control.exe» исполь­зует или импортирует некоторую функциональность компонентa «Library.dll», вы­зывает страницу гипертекста «Home.html» и файл помощи «Search.hlp», а исходный текст этого исполнимого компонента хра­нится в файле «Control.cpp». При этом ха­рактер отдельных видов зависимостей может быть отмечен дополнительно с помо­щью текстовых стереотипов.

Рис. 72. Графическое изображение отношения зависимости между компонен­тами

На диаграмме компонентов могут быть также представлены отношения зависи­мости между компонентами и реализованными в них классами. Эта ин­формация имеет значение для обеспечения согласования логического и физиче­ского представ­лений модели системы. Изменения в структуре описаний классов могут привести к изменению этой зависимости. Ниже приводится фрагмент за­висимости подобного рода, когда исполнимый компонент «Control.exe» зависит от соответствующих классов (рис. 73).

Рис. 73. Графическое изображение зависимости между компонентом и клас­сами

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

Рис. 74. Графическое изображение компонента с информацией о реали­зуемых им классах

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

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

Рис. 75. Графическое изображение компонента-экземпляра, реализую­щего отдель­ные объекты

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

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

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

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

Если же проект содержит физические элементы, описание которых отсут­ствует в языке UML, то следует воспользоваться механизмом расширения. В ча­стности, можно применить дополнительные стереотипы для отдельных нетипо­вых компо­нентов или помеченные значения для уточнения отдельных характе­ристик компо­нентов.

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

Пример: Программное средство представляет собой среду для автоматизиро­ванного построения графических объектов в 3D-пространстве. Оно обрабатывает входные данные, вводимые пользователем, обеспечивает их визуализацию, а также предоставляет возможность различных преобразований над объектами, вариантами их отображения. Программа позволяет строить различные графические объекты, как окружность, куб, гиперболоид, параболоид, различные двумерные и трехмерные графики. Также программа предоставляет возможность управления опциями, имеет файл справки и помощи.

Рис. 76. Пример диаграммы компонентов