Как составить диаграмму компонентов

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

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

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

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

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

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

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

Символы на диаграмме компонентов

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

Компонент

Существует три способа использования символа компонента.

1) Прямоугольник со стереотипом компонента (текст <<компонент>>). Стереотип компонента обычно используется над именем компонента, чтобы не перепутать форму со значком класса.

2) Прямоугольник со значком компонента в правом верхнем углу и названием компонента.

3) Прямоугольник со значком компонента и стереотипом компонента.

Предоставляемый интерфейс и требуемый интерфейс

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

Порт

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

Зависимости

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

Как рисовать диаграмму компонентов

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

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

Шаг 2: По мере выяснения взаимосвязей между элементами, которые вы определили ранее, создайте ментальный макет своей компонентной диаграммы

Шаг 3: По мере того, как вы рисуете диаграмму, сначала добавьте компоненты, группируя их внутри других компонентов, как вам кажется подходящим

Шаг 4: Следующим шагом является добавление других элементов, таких как интерфейсы, классы, объекты, зависимости и т.д. в вашу компонентную диаграмму и ее завершение.

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

Примеры схем компонентов

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

Схема компонентов для системы управления библиотекой

Схема компонентов для системы онлайн-покупок

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

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

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

Каковы ваши мысли в учебном пособии “Диаграмма компонентов”?

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

Мы недавно опубликовали руководства по диаграммам активности UML, а также по диаграммам классов, и если вы пропустили здесь ссылки;

Легкое руководство к диаграммам классов

Простое руководство к деятельности Диаграммы

Не забудьте сообщить нам о своих мыслях в разделе комментариев ниже.

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

• Часть 1. Что такое диаграмма компонентов UML
• Часть 2. Символы диаграммы компонентов UML
• Часть 3. Учебник по созданию диаграммы компонентов UML
• Часть 4. Часто задаваемые вопросы о диаграмме компонентов UML

Часть 1. Что такое диаграмма компонентов UML

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

Небольшой взгляд на диаграмму компонентов UML

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

Простое объяснение:

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

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

◆ Большой квадрат может быть системой. Также это может быть подсистема или компонент системы, который окружает внутренние компоненты.

Часть 2. Символы диаграммы компонентов UML

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

Примечание Символ

Это дает программистам возможность прикрепить метаанализ к диаграмме компонентов.

Символ узла

Он представляет элементы более высокого уровня, чем компоненты, такие как аппаратное или программное обеспечение.

Символ компонента

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

Символ интерфейса

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

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

Он получает услуги, функции или данные извне. Его еще называют леденцом.

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

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

Символ порта

Отдельно обозначена точка взаимодействия компонента и среды. Крошечный квадрат служит символом портов.

Символ упаковки

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

Символ зависимости

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

Часть 3. Учебник по созданию диаграммы компонентов UML

Вы хотите создать диаграмму компонентов UML, но вам нужна помощь, чтобы понять, с чего начать? Не беспокойтесь больше. В этой части вы найдете руководство по диаграмме компонентов UML. Таким образом, вы поймете, как создать диаграмму. Один из лучших инструментов, который вы можете использовать в MindOnMap. С помощью этого онлайн-инструмента создать диаграмму будет просто. Его интерфейс интуитивно понятен, что идеально подходит для всех пользователей. Кроме того, в нем есть различные элементы, необходимые для диаграммы. Он включает в себя фигуры, соединительные линии и стрелки, темы, стили шрифтов, цвета и многое другое. Кроме того, вы можете бесплатно использовать этот конструктор диаграмм, что делает его удобным для пользователей. Инструмент доступен для всех веб-браузеров, таких как Chrome, Firefox, Explorer, Edge и других.

Часть 4. Часто задаваемые вопросы о диаграмме компонентов UML

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

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

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

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

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

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

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

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

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

Компоненты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What is a Component Diagram in UML?

The main purpose of a component diagram is to show the structural relationships between the components of a system. In UML, Components are made up of software objects that have been classified to serve a similar purpose. Components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. By classifying a group of classes as a component the entire system becomes more modular as components may be interchanged and reused. Component diagrams document the encapsulation of the component and the means by which the component interacts via interfaces.

Component Diagram Notations

When to Draw Component Diagram?

1. Use component diagrams when you are dividing your system into components and want to show their interrelationships through interfaces.
2. The breakdown of components into a lower-level structure.

How to Draw a Component Diagram?

1. Decide on the purpose of the diagram
2. Add components to the diagram, grouping them within other components if appropriate
3. Add other elements to the diagram, such as classes, objects and interface
4. Add the dependencies between the elements of the diagram

You can also:

1. Draw subsystems for logical categorization of components
   

Component Diagram examples

Order Processing System Component diagram example

One main benefit of Component diagrams if to simplify the high-level view of the system. The Figure below is a much larger view of what is involved in a online store. By using a component diagram we see the system as a group of nearly independent component or subsystems that interact with each other in a specifically defined way.

Each component is responsible for the action for which it is named and interface(s) it provides. As long as those requirements are maintained changes to one component will not percolate to other components.

Ticket Selling System Component Diagram Example

There is a ticket seller component that sequentializes requests from both ticket selling system and clerks. A component that processes credit card charges; and the database containing the ticket information.

Component Example — Store Component — nested component structure

To show a nested component structure, you merely draw the component larger than normal and place the inner parts inside the name compartment of the encompassing component. The Figure below show’s the Store’s component nested structure.

Component Diagram Example — White-Box View of a Component

In the previous examples, those component diagrams are called black-box views. Ports are shown as squares bordering the component, these indicate how the interfaces of the component are used internally. Objects implementing a required interface are received via a port and objects implementing a provided interface are shared via a port.

In this example, the internal composition of components can also be modeled using component diagrams, this is called a white-box view of the diagram because we can see inside.

1. Ports are shown as squares bordering the component, these indicate how the interfaces of the component are used internally.
2. Objects implementing a required interface are received via a port and objects implementing a provided interface are shared via a port.

Component Diagram Example — Components in Deployment Diagram

Models the physical deployment of software components with UML deployment diagram. In deployment diagram, hardware components (e.g. web server, mail server, application server) are presented as nodes, with the software components that run inside the hardware components presented as artifacts.