Эта статья была первоначально опубликована на Medium.
UML-диаграммы: Пиццерия. Обзор схемы компонентов с помощью… | автор: Джин Зейнисс | январь 2021 | Средний
Джин Зейнисс ・ 26 января 2021 года ・ 6 минут чтения.
Подумай о пицце. Воображаемый запах дерзкой, сырной, острой пиццы, выпекаемой в духовке, поражает меня. Иногда вам нужны новые начинки, в других случаях вам нужна другая основа. Его создают многие различные ингредиенты. Каждый из этих ингредиентов является отдельным компонентом, но они взаимодействуют и дополняют друг друга. Все они существуют в рамках большей системы, в данном случае пиццы.
Ты все правильно понял. В этой статье мы рассмотрим диаграмму компонентов Uml.
Диаграммы компонентов используются для визуализации того, как компоненты системы взаимодействуют (ну и дела!) и какие отношения они имеют между собой. Для целей UML термин “компонент” относится к модулю классов, которые представляют независимые системы с возможностью взаимодействия с остальной частью системы. Поскольку мы можем идентифицировать эти интерфейсы, мы можем найти части системы, которые можно заменить. Другими словами, мы смогли найти компоненты плагина.
Поиск компонентов плагина позволяет нам повторно использовать эти компоненты в других проектах. Это также помогает нам структурировать нашу работу, разделяя ее на несколько разработчиков или независимо работающих подгрупп.
Вернемся к пицце, но теперь более конкретно. Подумайте о гавайской пицце в меню ресторана. Вероятно, вы не найдете способов приготовления и приготовления пиццы. В меню просто указаны ингредиенты пиццы, такие как ветчина, ананас и кусочки бекона с красным соусом (чтобы быть совершенно точным). Перечисляя все ингредиенты, клиент может получить лучшее представление о том, понравится ли ему пицца или нет. То же самое относится и к диаграмме компонентов. В отличие от других диаграмм, компонентные диаграммы ориентированы на структуру высокого уровня, а не на их методы и конкретные реализации. Это своего рода взгляд на вашу программную систему с высоты птичьего полета.
…
При построении диаграммы компонентов первым шагом является определение основных компонентов, используемых в системе.
Компонент – это логический модульный блок системы, немного более высокая абстракция, чем классы. Это подсистема, если хотите. Когда подсистемы соединены, это создает единую систему.
Давайте предположим, что мы хотим создать небольшую семейную систему пиццерий. Нашими основными компонентами будут:
- Пиццайоло — профессиональный производитель пиццы, как утверждает Оксфорд.
- Клиент — фактический потребитель пиццы (любитель пиццы, тот самый, который, возможно, будет наслаждаться гавайской пиццей).
- Официант — это “Тот, Кто ждет” . Не бери в голову, я просто играю в ассоциации.
В UML компонент представлен в виде другого поля с этим символом головоломки в правом верхнем углу. Здесь вы можете ознакомиться с основными компонентами нашей пиццерии. Круто? Не совсем. Этой информации недостаточно, чтобы рассказать нам то, что нам действительно нужно знать. Каждый компонент имеет определенную связь с другим компонентом через предоставляемый им интерфейс. Существование этих интерфейсов – самая интересная часть.
Давайте немного расширим нашу диаграмму. Мы добавим некоторые украшения в наш клиентский компонент. Взгляните на диаграмму. Я начну с того, что расскажу о Заказе и оплате. Когда клиент приходит в пиццерию, сначала он должен выбрать и заказать пиццу. Верно? Вечеринка с пиццей обычно заканчивается оплатой счета. На языке компонентов Заказ и оплата – это интерфейсы, которые предоставляет (реализует или реализует) наш Клиент. Цель предоставляемого интерфейса – показать, что компонент предлагает интерфейс для взаимодействия с другими компонентами. Этот вид интерфейса представлен сплошной линией с леденцом в конце и именем над ним.
Теперь, чтобы предоставить конкретный платеж, клиент должен знать, сколько ему нужно заплатить. Полукруг (также называемый “ сокет “) в конце соединительной линии представляет требуемый интерфейс. Смысл этого в том, что наш честный клиент ожидает получить чек, предоставленный каким-либо другим компонентом (официантом!), Чтобы иметь возможность выполнять свои обязанности.
Подводя итог, можно сказать, что интерфейс описывает группу операций, используемых (обязательных) или созданных (предоставляемых) компонентами.
…
Определены наши основные компоненты. Затем определите все соответствующие библиотеки, необходимые для вашей системы.
Диаграммы компонентов не фокусируются исключительно на том, что вы реализуете. Все зависимости сторонней реализации также должны быть идентифицированы и интегрированы в диаграмму, где это уместно. Позже я подробнее расскажу о третьих сторонах.
…
Наконец, определите связи, обнаруженные между всеми этими компонентами. Посмотрите, как компоненты могут соединяться друг с другом. Именно это и лежит в основе такого дизайна.
Компоненты могут быть соединены свободно или плотно, как ремень на брюках до (и после) поедания пиццы.
Давайте начнем с разговора о том, как мы можем свободно соединять различные компоненты вместе.
Слабое Соединение
Это основной тип подключения диаграммы содержимого. Именно здесь мы можем определить наши подключаемые части системы. Когда интерфейс, предоставляемый одним компонентом, соответствует требуемому интерфейсу другого компонента, это называется assembly relationship . Здесь вы можете видеть, что Клиент и Официант связаны, как пазл. Компоненты соединяются вместе. Но вы также можете легко отключить их от сети. Связь между ними ослаблена. Вы можете вызвать службу официанта и заменить ее чем-то другим, например, начальником смены, или, может быть, Пиццайоло во плоти примет заказ. Это заменяемая часть нашей системы.
Плотное Соединение
Плотная связь между компонентами представлена сплошной линией между двумя компонентами. Это указывает на то, что заменить один из этих компонентов будет не так просто. Они тесно связаны друг с другом. Давайте подумаем о нашем примере, предположим, что клиент может выбрать пиццу только из меню пиццы. Его заказ сильно зависит от компонента меню. Клиент не может предоставить заказ без Меню. Избавление от одного из них, вероятно, потребует некоторой доработки для реализации этой замены.
…
Теперь давайте взглянем на своего рода завершенную, хотя и довольно небольшую, диаграмму компонентов. Вы можете видеть, что на диаграмме есть некоторые новые элементы, которые мы еще не рассматривали. Прежде всего, здесь у нас есть диаграмма внешних компонентов, называемая Пиццерией. Это вся наша система. Другие компоненты, находящиеся внутри этой коробки, являются частями, из которых состоит пиццерия. Он состоит из Пиццайоло, Официанта и Клиента. Клиент тесно связан с меню пиццерии.
Пара других вещей, на которые следует обратить внимание, – это взаимодействие с внешним миром из пиццерии. Обратите внимание на маленькие квадраты, расположенные на границах компонента Пиццерии. Эти квадраты называются ports , и они определяют отдельную точку взаимодействия между компонентом и средой.
В примере с Пиццерией порты представляют третьи стороны, такие как Кассовая служба, используемая официантом; Продуктовый магазин, который предоставляет продукты, необходимые Пиццайоло; Служба ранжирования пиццерий, которая зависит от отзыва, предоставленного удовлетворенным (или нет) Покупатель.
Поскольку мы не реализуем эти сервисы, достаточно показать только точку взаимодействия и направление зависимости (входящее или исходящее). Зависимости представлены пунктирными линиями , связывающими один компонент (или элемент) с другим.
…
Это все. Пока-пока!
Чтобы ознакомиться с некоторыми другими диаграммами UML, о которых я писал, перейдите в мой профиль.
Оригинал: “https://dev.to/behalf/uml-diagrams-component-diagram-overview-4hmh”