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

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

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

Чтобы пояснить отличие логического и физического представлений, рассмотрим в общих чертах процесс разработки некоторой программной системы. Ее исходным логическим представлением могут служить структурные схемы алгоритмов и процедур, описания интерфейсов и концептуальные схемы баз данных. Однако для реализации этой системы необходимо разработать исходный текст программы на некотором языке программирования (C++, Pascal, Basic/VBA, Java). При этом уже в тексте программы предполагается такая организация программного кода, которая предполагает его разбиение на отдельные модули.

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

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

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

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

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

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

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

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

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

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

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

Рис. 10.1. Графическое изображение компонента в языке UML

Так, в первом случае (рис. 10.1, а) с компонентом уровня экземпляра связывается только его имя, а во втором (рис. 10.1, б) – дополнительно имя пакета и помеченное значение.

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

Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается <имя компонента ":" имя типаХ При этом вся строка имени подчеркивается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В первом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу (рис. 10.4). Наличие такой стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс. Так, например, изображенный ниже фрагмент диаграммы компонентов представляет информацию о том, что компонент с именем «main.exe» зависит от импортируемого интерфейса I Dialog, который, в свою очередь, реализуется компонентом с именем «image.java». Для второго компонента этот же интерфейс является экспортируемым.

Рис. 10.4. Фрагмент диаграммы компонентов с отношением зависимости

Заметим, что изобразить второй компонент с именем «image.java» в форме варианта примечания нельзя именно в силу того факта, что этот компонент реализует интерфейс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания:

Примечание 7

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

Примечание 72

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

Примечание 73

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

Примечание 74

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

Примечание 75

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

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

Зачем она нужна?

Применение UML не заканчивается на моделировании всевозможного ПО. Также данный язык активно сегодня используется для моделирования различных бизнес-процессов, ведения системного проектирования, а также отображения организационных структур.

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

Также стоит отметить, что есть несколько видов таких диаграмм.

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

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

Стоит отметить тот факт, что есть несколько точек зрения на построение таких диаграмм в зависимости от того, каким образом они будут использоваться:

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

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

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

Диаграмма композитной/составной структуры

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

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

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

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

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

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

Диаграмма объектов

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

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

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

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

Диаграмма деятельности

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

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

Диаграмма автомата

Этот вид называется и несколько иначе - диаграмма состояний UML. Имеет представленный конечный автомат с простыми и композитными состояниями, а также переходами.

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

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

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

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

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

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

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

Коммуникации

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

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

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

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

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

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

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

Диаграмма сотрудничества

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

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

Диаграммы обзора взаимодействия

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

Стоит отметить тот факт, что данный формат объединяет в себе Collaboration и Sequence diagram, которые предоставляют возможность с разных точек зрения рассматривать взаимодействие между несколькими объектами в формируемой системе.

Диаграмма синхронизации

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

В чем преимущества?

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

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

Недостатки

Несмотря на то что построение UML-диаграмм отличается массой своих плюсов, довольно часто их и критикуют за следующие недостатки:

• Избыточность. В преимущественном большинстве случаев критики говорят о том, что UML является слишком большим и сложным, и зачастую это неоправданно. В него входит достаточно много избыточных или же практически бесполезных конструкций и диаграмм, причем наиболее часто подобная критика идет в адрес второй версии, а не первой, потому что в более новых ревизиях присутствует большее количество компромиссов «разработанных комитетом».
• Различные неточности в семантике. По той причине, что UML определяется комбинацией себя, английского и OCL, у него отсутствует скованность, которая является присущей для языков, точно определенных техникой формального описания. В определенных ситуациях абстрактный синтаксис OCL, UML и английский начинают друг другу противоречить, в то время как в других случаях они являются неполными. Неточность описания самого языка одинаково отражается как на пользователях, так и на поставщиках инструментов, что в конечном итоге приводит к несовместимости инструментов из-за уникального способа трактовки различных спецификаций.
• Проблемы в процессе внедрения и изучения. Все указанные выше проблемы создают определенные сложности в процессе внедрения и изучения UML, и в особенности это касается тех случаев, когда руководство заставляет инженеров насильно его использовать, в то время как у них отсутствуют предварительные навыки.
• Код отражает код. Еще одним мнением является то, что важность имеют не красивые и привлекательные модели, а непосредственно рабочие системы, то есть код и есть проект. В соответствии с данным мнением есть потребность в том, чтобы разработать более эффективный способ написания программного обеспечения. UML принято ценить при подходах, компилирующих модели для регенерирования выполнимого или же исходного кода. Но на самом деле этого может быть недостаточно, потому что в данном языке отсутствуют свойства полноты по Тьюрингу, и каждый сгенерированный код в конечном итоге будет ограничиваться тем, что может предположить или же определить интерпретирующий UML инструмент.
• Рассогласование нагрузки. Данный термин происходит из теории системного анализа для определения неспособности входа определенной системы воспринять выход иной. Как в любых стандартных системах обозначений, UML может представлять одни системы в более эффективном и кратком виде по сравнению с другими. Таким образом, разработчик больше склоняется к тем решениям, которые являются более комфортными для переплетения всех сильных сторон UML, а также других языков программирования. Данная проблема является более очевидной в том случае, если язык разработки не соответствует основным принципам объектно-ориентированной ортодоксальной доктрины, то есть не старается работать в соответствии с принципами ООП.
• Пытается быть универсальным. UML представляет собой язык моделирования общего назначения, который старается обеспечить совместимость с любым существующим на сегодняшний день языком обработки. В контексте определенного проекта, для того, чтобы команда проектировщиков смогла добиться конечной цели, нужно выбирать применимые возможности этого языка. Помимо этого возможные пути ограничения сферы использования UML в какой-то определенной области проходят через формализм, который является не полностью сформулированным, а который сам представляет собой объект критики.

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

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

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

В UML 2 по сравнению с UML 1 произошло значительное изменение, а именно, понятие "компонент" было разделено на две составляющие: логическую и физическую. Логическая составляющая, продолжающая носить имя компонент (component), является элементом логической модели системы, в то время как физическая составляющая, называемая артефактом (artifact), олицетворяет физический элемент проектируемой системы, размещающийся на вычислительном узле (node).

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

• структуру логических элементов (компонентов);
• отображения логических элементов (компонентов) на физические элементы (артефакты);
• структуру используемых ресурсов (узлов) с распределенными по ним физическими элементами (артефактами).

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

3.4.1. Интерфейс

∇ Встречающиеся в литературе варианты перевода: "реализованный", "предоставляемый".

∇∇ Встречающийся в литературе вариант перевода ‒ "запрашиваемый"

Однако, нельзя забывать, что сам по себе интерфейс ‒ это просто описание контракта, а обеспеченным или требуемым он становиться в зависимости от того, как этот интерфейс используется:

• если классификатор реализует интерфейс ‒ то для данного классификатора это обеспеченный интерфейс и данный факт показывается с помощью отношения реализации 3 ;
• если классификатор вызывает операции интерфейса - то для данного классификатора это требуемый интерфейс и данный факт показывается с помощью отношения зависимости 4 .

Разобравшись с интерфейсами, давайте перейдем к компонентам.

3.4.2. Компоненты, артефакты и узлы

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

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

Стандартом UML для компонентов предусмотрены стереотипы, приведенные в следующей таблице.

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

Аналогом компонента в смысле сборочного программирования является понятие артефакта в UML. Причем не любого артефакта, а только некоторых из его стереотипов.

Артефакт ‒ это любой созданный искусственно элемент программной системы.

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

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

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

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

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

Манифестация ‒ это отношение зависимости со стереотипом «manifest» , связывающее элемент модели (например, класс или компонент) и его физическую реализацию в виде артефакта.

Ниже представлен класс Company , который связан отношением манифестации (зависимость со стереотипом «manifest») с двумя артефактами со стереотипом «source» , которые в свою очередь определяют артефакт времени выполнения динамическую библиотеку (со стереотипом «library») Company .

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

Манифестацию графически изображают отношением зависимости со стереотипом «manifest» от артефакта к реализуемой сущности. Поскольку манифестация ‒ это отношение типа "многие ко многим", для полного описания отношения манифестации могут потребоваться несколько отношений зависимости в модели.

Третья сущность, рассматриваемая в этом параграфе ‒ узел.

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

В UML предусмотрено два стереотипа для узлов «executionEnvironment» и «device» .

Узел со стереотипом «executionEnvironment» позволяет моделировать аппаратно-программную платформу, на которой происходит выполнение приложения. Примерами среды выполнения являются: операционная система, система управления базами данных и т.д.

Узел со стереотипом «device» также моделирует аппаратно-программную платформу, но допускает возможность вложение одного узла в другой, как это показано на следующем рисунке.

Артефакты системы во время ее работы размещаются на узлах, что графически выражается либо их перечислением внутри узла 1 (см. рисунок выше), либо отношением зависимости со стереотипом «deploy» между артефактом и узлом 1 (см. рисунок ниже), либо изображением артефакта внутри изображения узла 2 (см. рисунок ниже). Все варианты нотации равноправны.

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

Спецификация развертывания изображается, как и классификатор (в виде прямоугольника), но со стереотипом «deploymentSpec» и связывается отношением зависимости с артефактом.

Последнее, что нам осталось рассмотреть в рамках данного параграфа ‒ это отношение ассоциации между узлами.

Если узлы связаны между собой отношением ассоциации, то это означает то же, что и в других контекстах: возможность обмена сообщениями. Применительно к вычислительным сетям, состоящим из узлов, ассоциация означает наличие канала связи. Если нужно указать дополнительную информацию о свойствах канала, то это можно сделать, используя общие механизмы: стереотипы (например, «tcp/ip» см. на рисунке ниже), ограничения и именованные значения.

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

3.4.3. Применение диаграмм компонентов и размещения

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

Основное назначение проектируемой информационной системы ‒ хранить данные о кадрах и выполнять по указанию пользователя некоторые операции с этими данными. Анализируя состав операций, мы видим, что они сводятся к созданию, модификации и удалению хранимых элементов данных. Стандартным решением в таких ситуациях является применение готовой СУБД (DBMS ‒ Data Base Management System). С точки зрения проектирования информационной системы отдела кадров целесообразно считать используемую СУБД готовым компонентом с заранее определенными интерфейсами и протоколом взаимодействия. Мы можем не заострять внимания на структуре этого компонента ‒ она стандартна и, наверное, достаточно хорошо описана вне нашей модели.

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

∇ Крайне неудачный, но часто используемый термин, являющийся калькой английского business logic. Бизнес-логика не имеет никакого отношения ни к бизнесу (в российском понимании этого слова), ни к логике. Правильнее было бы использовать сложное словосочетание "правила обработки данных", но мы боимся оказаться непонятыми.

В версии UML 2 произошли следующие изменения в нотации диаграмм компонентов.

Во-первых, компоненты, как и любой классификатор, можно изображать единообразно, в виде прямоугольников, в которых, указывается либо стереотип «component» 1 , либо один из уточняющих стереотипов, приведенных в табл. Стандартные стереотипы компонент в параграфе 3.4.2 2 , либо соответствующий значок в правом верхнем углу прямоугольника 3 .

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

Сказанное иллюстрирует рисунок ниже на котором указаны те же сущности и отношения, что и на рисунке выше.

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

Допустим, что в проектируемой информационной системе отдела кадров требуется разграничить права на выполнение операций и доступ к данным для различных категорий пользователей. Хотя в нашем техническом задании про это не сказано ни слова, но для современных систем данное требование стало общим местом (иногда явно лишним), так что пример не является надуманным. Нам известно множество способов реализации разграничения прав доступа к данным, а неизвестных нам способов, наверное, существует еще больше. Мы не будем вдаваться в их описание и обсуждение, а ограничимся одним - очень простым, но действенным. У нашего приложения два действующих лица (см. параграф 2.2.1), т.е. две категории пользователей. Допустим, что достаточно разграничить права на уровне категорий пользователей. Тогда можно поступить следующим образом: сделать просто два различных приложения (или, как обычно говорят в таких случаях, два автоматизированных рабочих места ‒ АРМа). Пользователи, имеющие доступ к АРМу в целом, могут выполнять все операции АРМа и, таким образом, имеют те и только те права на доступ к данным, которые обеспечиваются операциями, реализованными в АРМе.

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

Принятое решение легко выражается на диаграмме компонентов.

Все что осталось сделать ‒ это определить состав компонентов, т.е. показать какие классы в какие компоненты входят.

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

Другой способ определения состава компонента ‒ рассматривать его как структурированный классификатор и использовать диаграмму внутренней структуры (см. параграф 1.6.2 и параграф 3.5.1).

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

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

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

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

Обе эти диаграммы являются диаграммами размещения, но каждая из них имеет свои особенности. На первой диаграмме упор сделан на указание соответствия между компонентами и артефактами, выражающийся в наличии большого количества отношений зависимости со стереотипом «manifest» (см., например, 1 на первой диаграмме). Вторая диаграмма показывает отношения между артефактами, или, другими словами, определяет, какой артефакт от какого зависит, например, запрашивает данные (в качестве примера см. 1 на второй диаграмме). На обеих диаграммах показаны вычислительные узлы и отношения между ними (2 на обоих диаграммах). Заметим, что на диаграмме появился дополнительный артефакт ‒ Help (например, 3 на второй диаграмме). Это документ, содержащий справочную информацию.

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

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

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

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

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

∇ Отметим еще раз, что во время выполнения мы имеем дело не с самими классификаторами, а с их экземплярами. Представлению экземпляров классификаторов посвящен параграф 3.5.4 .

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

Компонент (component)

Примеры изображения простого компонента и компонента с интерфейсами

Примеры изображения компонента в нотации черного и белого ящика

Интерфейсы

Представление интерфейсов в форме символа классификатора с отношениями зависимости и реализации

Порты

Собирающий соединитель (assembly connector)

10. Пример диаграммы компонентов с собирающими соединителями для одинаковых интерфейсов

11. Делегирующий соединитель (delegation connector)

12. Пример внутренней структуры экземпляра компонента

13. Пример отношений зависимости между компонентом

14. Отношения зависимости на диаграмме компонентов с интерфейсами

15. Реализация (realization)