Ростелеком ТВ 

Диаграммы компонентов языка uml. UML-диаграмма. Виды диаграмм UML. Пример внутренней структуры экземпляра компонента

Особенности изображения диаграмм языка UML

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

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

· Графические взаимосвязи, которые представляются различными линиями на плоскости. Взаимосвязи в языке UML обобщают понятие дуг и ребер из теории графов, но имеют менее формальный характер и более развитую семантику.

· Специальные графические символы, изображаемые вблизи от тех или иных визуальных элементов диаграмм и имеющие характер дополнительной спецификации (украшений).

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

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



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

Диаграмма кооперации

Диаграммы кооперации предназначены для описания динамических аспектов моделируемой системы. Обычно они применяются для того, чтобы:

· показать набор взаимодействующих объектов в реальном окружении "с высоты птичьего полета";

· распределить функциональность между классами, основываясь на результатах изучения динамических аспектов системы;

· описать логику выполнения сложных операций, особенно в тех случаях, когда один объект взаимодействует еще с несколькими объектами;

· изучить роли, выполняемые объектами внутри системы, а также отношения между объектами, в которые они вовлекаются, выполняя эти роли.

Говоря о диаграммах кооперации, часто упоминают два "уровня" таких диаграмм:

· уровень экземпляров (примеров, Instance-Level): отображает взаимодействия между объектами (экземплярами классов); такая диаграмма обычно создается, чтобы исследовать внутреннее устройство объектно-ориентированной системы.

· уровень спецификации (Specification-Level): используется для изучения ролей, исполняемых в системе основными классами.

Она показывает взаимодействие между объектами, которое осуществляется путем посылки и приема сообщений.



Диаграмма компонентов

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

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

Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1, а также интерфейсы 2, посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:

· реализации между компонентами и интерфейсами (компонент реализует интерфейс);

· зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3.

Диаграмма развертывания

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

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

При разработке диаграммы развертывания преследуют следующие цели:

· определить распределение компонентов системы по ее физическим узлам;

· показать физические связи между всеми узлами реализации системы на этапе ее исполнения;

· выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.

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

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

Диаграмма компонентов разрабатывается для следующих целей:

визуализации общей структуры исходного кода программной системы;

спецификации исполняемого варианта программной системы;

обеспечения многократного использования отдельных фрагментов программного кода;

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

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

Компоненты

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

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

Отдельный компонент может быть представлен на уровне типа или на уровне экземпляра. Графическое изображение в обоих случаях одинаковое, но правила записи имени компонента отличаются. Если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы. Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается <имя компонента>":"<имя типаХ>. При этом вся строка имени подчеркивается.

В качестве простых имен принято использовать имена исполняемых файлов (с указанием расширения ехе после точки-разделителя), динамических библиотек (расширение dll), Web-страниц (расширение html), текстовых файлов (расширения txt или doc) или файлов справки (hip), файлов баз данных (DB) или файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение java для языка Java), скрипты (pi, asp) и другие.

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

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

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

В языке UML выделяют три вида компонентов:

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

рабочие продукты. Как правило, это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++;

исполнения, представляющие собой исполняемые модули - файлы с расширением ехе.

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

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

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

таблица (table) - также определяет первую разновидность компонента, который представляется в форме таблицы базы данных;

файл (file) - определяет вторую разновидность компонента, который представляется в виде файлов с исходными текстами программ;

документ (document) - определяет вторую разновидность компонента, . который представляется в форме документа;

исполнимый (executable) - определяет третий вид компонента, который может исполняться в узле.

Интерфейсы

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

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

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

Зависимости

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

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

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

Другим случаем отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов. Наличие подобной зависимости означает, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента. При этом характер изменений может быть отмечен дополнительно.

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

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

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

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

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

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

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

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

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

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

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

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

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

В следующей таблице описаны элементы, которые можно использовать на схеме компонентов, и их основные свойства.

Фигура

Элемент

Описание и основные свойства

Компонент

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

Можно скрывать или отображать внутренние части компонента с помощью элемента управления "развернуть/свернуть" (9).

Компонент - это вид класса.

    Является неявно создаваемым экземпляром. Если значение true (по умолчанию), компонент существует только как артефакт конструкции. Во время выполнения существует только ее часть.

Предоставленный порт интерфейса

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

Требуемый порт интерфейса

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

Зависимость

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

Зависимости также можно использовать в более общем случае при работе с элементами модели, чтобы показать, что конструкция одного зависит от конструкции другого.

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

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

Чтобы создать часть нового типа, выберите инструмент Компонент и щелкните компонент-владелец.

Например, компонент Car имеет части engine:CarEngine, backLeft:Wheel, frontRight:Wheel и т. д.

Несколько частей могут иметь один и тот же тип, и разные компоненты могут иметь части одного типа.

    Тип. Тип части, определяемый в другом месте модели. Как правило, типом является другой компонент.

    Кратность. По умолчанию используется значение 1. Можно задать значение 0..1, чтобы указать, что часть может иметь значение null, или задать значение *, чтобы указать, что часть является коллекцией экземпляров данного типа. Также в качестве значения можно задать любое выражение, которое можно оценить в числовом диапазоне.

Сборка части

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

Делегирование

Связывает порт с интерфейсом одной из частей компонента. Указывает, что сообщения, отправленные компоненту, обрабатываются этой частью, или что сообщения, отправленные этой частью, отсылаются из родительского компонента.

(не показана)

Обобщение

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

Элемент управления "развернуть/свернуть"

Позволяет скрывать или отображать внутренние части компонента.

(не показана)

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

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

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

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

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

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


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

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

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

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

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

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

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

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

<

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

Интерфейсы

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

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


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

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

10.4. ДИАГРАММЫ UML

10.4.1. Типы визуальных диаграмм UML

UML позволяет создавать несколько типов визуальных диаграмм:

Диаграммы вариантов использования;

Диаграммы последовательности;

Кооперативные диаграммы;

Диаграммы классов;

Диаграммы состояний;

Диаграммы компонент;

Диаграммы размещения.

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

10.4.2. Диаграммы вариантов использования

Диаграммы вариантов использования отображают взаимодействие между вариантами использования, представляющими функции системы, и действующими лицами, представляющими людей или системы, получающие или передающие информацию в данную систему. Пример диаграммы вариантов использования для банковского автомата (ATM) показан на рис. 10.1.

Рис. 10.1. Диаграмма вариантов использования

На диаграмме представлено взаимодействие между вариантами использования и действующими лицами. Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования - это функции, выполняемые системой, а действующие лица - это заинтересованные лица по отношению к создаваемой системе. Диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. В сущности диаграмма вариантов использования может иллюстрировать требования к системе. В нашем примере клиент банка инициирует различные варианты использования: "Снять деньги со счета", "Перевести деньги", "Положить деньги на счет", "Показать баланс", "Изменить идентификационный номер", "Произвести оплату". Банковский служащий может инициировать вариант использования "Изменить идентификационный номер". От варианта использования "Произвести оплату" идет стрелка к Кредитной системе. Действующими лицами могут быть и внешние системы, в данном случае Кредитная система показана именно как действующее лицо - она является внешней для системы ATM. Стрелка, направленная от варианта использования к действующему лицу, показывает, что вариант использования предоставляет некоторую информацию действующему лицу. В данном случае вариант использования "Произвести оплату" предоставляет Кредитной системе информацию об оплате по кредитной карточке.

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

10.4.3. Диаграммы последовательности

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

Рис 10.2. Диаграмма последовательности снятия клиентом Джо $20 со счета

В верхней части диаграммы показаны все действующие лица и объекты, требуемые системе для выполнения варианта использования "Снять деньги". Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций. Следует отметить также, что на диаграмме последовательности показаны именно объекты, а не классы. Классы представляют собой типы объектов. Объекты конкретны; вместо класса Клиент на диаграмме последовательности представлен конкретный клиент Джо.

Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения - этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект "счет Джо" и инициализирует экран ATM. Экран запрашивает у Джо его регистрационный номер. Клиент вводит число 1234. Экран проверяет номер у объекта "счет Джо" и обнаруживает, что он правильный. Затем экран предоставляет Джо меню для выбора, и тот выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и Джо указывает $20. Экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "счет Джо". В то же время осуществляется проверка, что на этом счету лежат, по крайней мере, $20 и из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию "выдать чек и $20 наличными". Наконец, все тот же объект "счет Джо" дает устройству для чтения карточек инструкцию вернуть карточку.

Итак, данная диаграмма последовательности иллюстрирует последовательность действий, реализующих вариант использования "Снять деньги со счета" на конкретном примере снятия клиентом Джо $20. Глядя на эту диаграмму, пользователи знакомятся со спецификой своей работы. Аналитики видят последовательность (поток) действий, разработчики - объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы последовательности полезны всем участникам проекта.

10.4.4. Кооперативные диаграммы

Кооперативные диаграммы отражают ту же самую информацию, что и диаграммы последовательности. Однако дела, ют они это по-другому и с другими целями. Показанная на рис. 10.2 диаграмма последовательности представлена на рис. 10.3 в виде кооперативной диаграммы.

Как и раньше, объекты изображены в виде прямоугольников, а действующие лица в виде фигур. Если диаграмма последовательности показывает взаимодействие между действующими лицами и объектами во времени, то на кооперативной диаграмме связь со временем отсутствует. Так, можно видеть, что устройство для чтения карточки выдает "счету Джо" инструкцию открыться, а "счет Джо" заставляет это устройство вернуть карточку владельцу. Непосредственно взаимодействующие объекты соединены линиями. Если, например, устройство для чтения карточки общается непосредственно с экраном ATM, между ними следует провести линию. Отсутствие линии означает, что непосредственное сообщение между объектами отсутствует.

Рис. 10.3. Кооперативная диаграмма, описывающая процесс снятия денег со счета

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

10.4.5. Диаграммы классов

Диаграммы классов отражают взаимодействие между классами системы. Например, "счет Джо" - это объект. Типом такого объекта можно считать счет вообще, т. е. "Счет" - это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Так, класс Счет содержит идентификационный номер клиента и проверяющие его действия. На диаграмме классов класс создается для каждого типа объектов из диаграмм последовательности или Кооперативных диаграмм. Диаграмма классов для варианта использования "Снять деньги" показана на рис. 10.4.

На диаграмме показаны связи между классами, реализующими вариант использования "Снять деньги". В этом процессе задействованы четыре класса: Card Reader (устройство для чтения карточек), Account (счет), ATM (экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс на диаграмме классов изображается в виде прямоугольника, разделенного на три части. В первой части указывается имя класса, во второй - его атрибуты. Атрибут - это некоторая информация, характеризующая класс. Например, класс Account (счет) имеет три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). Связывающие классы линии показывают взаимодействие между классами.

Рис. 10.4. Диаграмма классов

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

10.4.6. Диаграммы состояний

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

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

Рис. 10.5. Диаграмма состояний для класса Account

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

Когда клиент снимает деньги с открытого счета, счет может перейти в состояние "Превышение кредита". Это происходит, только если баланс по счету меньше нуля, что отражено условием [отрицательный баланс] на нашей диаграмме. Заключенное в квадратные скобки условие определяет, когда может или не может произойти переход из одного состояния в другое.

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

Когда объект находится в каком-то конкретном состоянии, могут выполняться те или иные процессы. В нашем примере при превышении кредита клиенту посылается соответствующее сообщение. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями.

Диаграммы состояний не нужно создавать для каждого класса, они применяются только в очень сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него, вероятно, потребуется такая диаграмма. Однако во многих проектах они вообще не используются. Если же диаграммы состояний все-таки были построены, разработчики могут применять их при создании классов.

Диаграммы состояний необходимы в основном для документирования.

10.4.7. Диаграммы компонент

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

На рис. 10.6 изображена одна из диаграмм компонент для системы ATM. На этой диаграмме показаны компоненты клиента системы ATM. В данном случае команда разработчиков решила строить систему с помощью языка C++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением. СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Выделенная темная компонента называется спецификацией пакета и соответствует файлу тела класса ATM на языке C++ (файл с расширением. СРР). Невыделенная компонента также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением. Н). Компонента АТМ. ехе является спецификацией задачи и представляет поток обработки информации. В данном случае поток обработки - это исполняемая программа.

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

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

Рис. 10.6. Диаграмма компонент

10.4.8. Диаграммы размещения

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

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

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

10.7. Диаграмма размещения

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

Из книги Microsoft Office автора Леонтьев Виталий Петрович

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

Из книги Компьютер на 100. Начинаем с Windows Vista автора Зозуля Юрий

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

Из книги Эффективное делопроизводство автора Пташинский Владимир Сергеевич

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

Из книги Excel. Мультимедийный курс автора Мединов Олег

Глава 8 Диаграммы Часто программу Excel используют для создания документов, представляющих собой различные статистические и аналитические отчеты. Это могут быть отчеты о продажах, таблицы замеров температуры воздуха, данные социологических опросов и т. д. Цифры не всегда

Из книги Word 2007.Популярный самоучитель автора Краинский И

Построение диаграммы Для первого примера вам понадобится создать таблицу, изображенную на рис. 8.1. Рис. 8.1. Таблица замера температурыМы построим простой график изменения температуры на основе данных этой таблицы.1. Выделите заполненный диапазон в таблице.2. Перейдите на

Из книги Самоучитель работы на компьютере автора Колисниченко Денис Николаевич

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

Из книги Объектно-ориентированный анализ и проектирование с примерами приложений на С++ автора Буч Гради

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

Из книги Технологии программирования автора Камаев В А

5.2. Диаграммы классов Существенное: классы и отношения между ними Диаграмма классов показывает классы и их отношения, тем самым представляя логический аспект проекта. Отдельная диаграмма классов представляет определенный ракурс структуры классов. На стадии анализа мы

Из книги Моделирование бизнес-процессов с BPwin 4.0 автора Маклаков Сергей Владимирович

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

Из книги OrCAD PSpice. Анализ электрических цепей автора Кеоун Дж.

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

Из книги VBA для чайников автора Каммингс Стив

10.4. ДИАГРАММЫ UML 10.4.1. Типы визуальных диаграмм UMLUML позволяет создавать несколько типов визуальных диаграмм: диаграммы вариантов использования; диаграммы последовательности; кооперативные диаграммы; диаграммы классов; диаграммы состояний; диаграммы

Из книги Самоучитель работы на Macintosh автора Скрылина Софья

1.2.6. Каркас диаграммы На рис. 1.2.26 показан типичный пример диаграммы декомпозиции с граничными рамками, которые называются каркасом диаграммы. Рис. 1.2.26. Пример диаграммы декомпозиции с каркасомКаркас содержит заголовок (верхняя часть рамки) и подвал (нижняя часть).

Из книги автора

Временные диаграммы Чтобы получить временные диаграммы входного и выходного напряжений, необходимо слегка изменить входной файл. Как и в предыдущем примере, будет использовано синусоидальное входное напряжение:Vi 1 0 sin (0 0. 5V 5kHz)Наряду с анализом переходных процессов

Из книги автора

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

Из книги автора

5.1.14. Диаграммы Диаграмм - графическое представление числовых данных таблицы. Pages предлагает несколько видов диаграмм: Column (Столбцовая), Stacked Column (Многоярусные столбцы), Ваг (Гистограмма), Stacked Ваг (Многоярусная гистограмма), Line (Линейная), Area (Площадь), Stacked Area (Многоярусная

Из книги автора

5.2.8. Диаграммы Диаграмма - графическое представление данных из выбранного диапазона.Для построения диаграммы придерживайтесь следующего алгоритма1. Создать таблицу расчетных значений.2. Выделить нужный диапазон (он может состоять из не смежных прямоугольных

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

Диаграмма компонентов и особенности ее построения

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

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

Физическая система ( physical system ) - реально существующий прототип модели системы.

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

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

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

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

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

Компоненты

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

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

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

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


Рис. 12.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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