Uml что это такое простыми словами с примерами
Зачем нам UML? Или как сохранить себе нервы и время
Многие программисты, столкнувшись со сложной задачей, пренебрегают этапом проектирования, ссылаясь на то, что проектирование — это потеря времени, и в данном случае оно будет мне только мешать.
Зачастую это утверждение оказывается верным, если задача и правда небольшая и квалификации программиста достаточно для определения наиболее оптимального решения.
Программисты, не использующие UML, делятся на несколько групп:
Можно провести аналогию с постройкой дома. Когда кто-то хочет построить дом, он не просто бьет молотком и приступает к работе. Ему нужно иметь план — план проектирования, чтобы он мог анализировать и модифицировать свою систему.
Если вы уже начали описывать на бумаге вашу задачу, это уже огромный плюс.
Что такое UML
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Проще говоря, если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики.
Важно, что UML переводится как Unified Modeling Language. Главное здесь слово Unified. То есть наши картинки поймём не только мы, но и остальные, знающие UML. Получается, это такой международный язык рисования схем.
Плюсы и минусы UML проектирования
Все представленные ниже диаграммы связаны между собой. Комбинируя их, мы можем добиться необходимого уровня декомпозиции отдельно взятых задач.
Предлагаю познакомиться с одними из самых полезных и часто используемых диаграмм.
Речь пойдет о диаграммах последовательности, состояний, деятельности и самой сложной из них — диаграмме классов.
Представьте, что вам нужно описать последовательность действий для заказа товара в интернет-магазине. Кто должен участвовать в процессе? Какие фазы проходит заказ прежде, чем он будет оформлен?
Обычно, мы пишем длинный список этапов, которые должна пройти заявка, чтобы получить гордый статус «Оформлена». Затем описываем, кто именно будет выполнять конкретное действие. И только после этого начинаем программировать.
В чем недостаток данного подхода? Он не нагляден.
Представьте, перед вами лежит длинный список описанных ранее этапов и комментариев к ним. Насколько просто вам будет разобраться в нем? Сколько времени может на это потребоваться? Предполагаю, что достаточно.
Альтернативой данному подходу является использование диаграммы последовательностей, представленной на рисунке ниже.
Сверху отображены действующие лица, а каждая стрелка это конкретное действие, связанное с ними. Подробнее о данной диаграмме можно узнать здесь
Диаграмма состояний. Настраиваем старые электронные часы
Диаграмма состояний позволяет описать поведение отдельно взятого объекта при определенных условиях. Также она покажет нам все возможные состояния, в которых может находиться объект, а также процесс смены состояний в результате внешнего влияния.
Предположим, мы программируем советские электронные часы.
Для настройки нам дано всего несколько кнопок. Довольно негусто. При этом мы знаем, что одна из кнопок переключает режим настройки часов. Другая кнопка в первом режиме меняет минуты, а во втором часы.
Инструкция по настройке и так достаточно небольшая, но благодаря диаграмме состояний она визуально воспринимается гораздо проще.
Подробнее о диаграмме состояний можно прочитать здесь.
Диаграмма классов, или как рассказать о своем коде без кода
Диаграммы классов используются при моделировании ПС наиболее часто. Они являются одной из форм статического описания системы с точки зрения ее проектирования. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними.
В различных документациях, описании паттернов проектирования, а также, читая хабр, все мы часто встречаем диаграмму классов. Почему же ее так часто используют?
Предположим, вам нужно спроектировать систему. Прежде чем приступить к реализации нескольких классов, вы захотите иметь концептуальное понимание системы, — какие классы мне нужны? Какая функциональность и информация будет у этих классов? Как они взаимодействуют друг с другом? Кто может видеть эти классы? И так далее.
Вот где появляются диаграммы классов. Диаграммы классов — это отличный способ визуализировать классы в вашей системе, прежде чем вы начнете их кодировать. Они представляют собой статическое представление структуры вашей системы.
Именно диаграмма классов дает нам наиболее полное и развернутое представление о структуре и связях в программном коде. Понимание принципов построения данной диаграммы позволяет кратко и прозрачно выражать свои мысли и идеи.
Рассмотрим, как с помощью диаграммы классов описать известный паттерн проектирования «Посетитель».
«Посетитель» — это поведенческий паттерн проектирования, который позволяет добавлять в программу новые операции, не изменяя классы объектов, над которыми эти операции могут выполняться.
Самыми значимыми достоинствами этой диаграммы являются:
Подробнее о диаграмме классов можно прочитать здесь, а о паттерне «Посетитель» здесь.
Диаграмма деятельности
Диаграмма деятельности – это технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ. Во многих случаях они напоминают блок-схемы, но принципиальная разница между диаграммами деятельности и нотацией блок-схем заключается в том, что первые поддерживают параллельные процессы.
Если говорить кратко, то диаграмма деятельности помогает нам описать логику поведения системы. Можно построить несколько диаграмм деятельности для одной и той же системы, причем каждая из них будет фокусироваться на разных аспектах системы, показывать различные действия, выполняющиеся внутри нее.
Именно на диаграмме деятельности представлены переходы от одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми активностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей.
Смысл диаграммы вполне понятен. На ней показана работа с веб-приложением, которое решает некую задачу в удаленной базе данных. Обратите внимание на расположение активностей на этой диаграмме: они как бы разбросаны по трем колонкам, каждая из которых соответствует поведению одного из трех объектов — клиента, веб-сервера и сервера баз данных. Благодаря этому легко определить, каким из объектов выполняется каждая из деятельностей.
Подробнее о диаграмме деятельности можно прочитать здесь.
Заключение
Надеюсь, что после этой статьи вы по-другому посмотрите на UML. Теперь при прочтении литературы или сайтов, посвященных данной теме, вам будет проще понять, какую цель преследует UML, и найти возможности для его применения. Попробуйте начать применять его и вы почувствуете всю силу и мощь, скрываемую за набором стрелок и квадратиков.
Оставьте комментарий, если вы думаете (или знаете), что что-то не так или могло быть описано лучше.
Что находится между идеей и кодом? Обзор 14 диаграмм UML
Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?
Этот цикл статей будет посвящен полезному, но порой ускользающему от молодой поросли знанию — диаграммам UML. И начну я его с обзора существующих диаграмм, поговорим немного об истории и зачем диаграмм должно быть так много.
UML — это сокращение от Unified Modeling Language, и, как мы знаем, он является стандартизированным языком моделирования, состоящим из интегрированного набора диаграмм, разработанных, чтобы помочь разработчикам систем и программного обеспечения в определении, визуализации, конструировании и документировании артефактов программных систем, а также, к примеру, для бизнес-моделирования.
UML представляет собой набор лучших инженерных практик, которые доказали свою эффективность в моделировании больших и сложных систем и является очень важной частью разработки объектно-ориентированного программного обеспечения.
UML использует в основном графические обозначения, чтобы выразить дизайн программных проектов. Использование UML помогает проектным группам общаться, изучать потенциальные проекты и проверять архитектурный дизайн программного обеспечения.
Происхождение UML
Цель UML — предоставить стандартную нотацию, которая может использоваться всеми объектно-ориентированными методами, а также выбрать и интегрировать лучшие элементы нотаций-предшественников. UML был разработан для широкого спектра приложений. Следовательно, он предоставляет конструкции для широкого спектра систем и видов деятельности (например, распределенных систем, анализа, проектирования и развертывания систем).
UML не возник на пустом месте, ему предшествовали несколько значимых событий, личностей и методологий. Например:
К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция «прецедентов») были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.
В противовес всем известной “Банде Четырех”, Команда Румбо, Буча и Якобсона известна как «Три Амигоса».
На UML также повлияли другие объектно-ориентированные нотации:
Почему UML?
По мере того как стратегическая ценность программного обеспечения возрастала для многих компаний, отрасль искала методы для автоматизации производства программного обеспечения, а также для повышения качества и сокращения затрат и времени выхода на рынок.
Эти методы включают технологию компонентов, визуальное программирование, шаблоны и структуры.
Компании также ищут методы для управления сложностью систем по мере увеличения их масштаба.
В частности, они признают необходимость решения повторяющихся архитектурных проблем, таких как физическое распределение, параллелизм, репликация, безопасность, балансировка нагрузки и отказоустойчивость.
Кроме того, разработка под Web хоть и упрощает некоторые вещи, в целом, она усугубляет эти архитектурные проблемы.
Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей.
Основные цели дизайна UML:
Структурные диаграммы показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь. Элементы в структурной диаграмме представляют значимые понятия системы и могут включать в себя абстрактные, реальные концепции и концепции реализации. Существует семь типов структурных диаграмм:
Диаграмма классов
Диаграмма классов — это центральная методика моделирования, которая используется практически во всех объектно-ориентированных методах. Эта диаграмма описывает типы объектов в системе и различные виды статических отношений, которые существуют между ними.
Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:
Ассоциация, которая представляет отношения между экземплярами типов, к примеру, человек работает на компанию, у компании есть несколько офисов.
Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.
Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.
Диаграмма компонентов
На языке унифицированного моделирования диаграмма компонентов показывает, как компоненты соединяются вместе для формирования более крупных компонентов или программных систем.
Она иллюстрирует архитектуры компонентов программного обеспечения и зависимости между ними.
Эти программные компоненты включают в себя компоненты времени выполнения, исполняемые компоненты, а также компоненты исходного кода.
Диаграмма развертывания
Диаграмма развертывания помогает моделировать физический аспект объектно-ориентированной программной системы. Это структурная схема, которая показывает архитектуру системы, как развертывание (дистрибуции) программных артефактов.
Артефакты представляют собой конкретные элементы в физическом мире, которые являются результатом процесса разработки.
Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.
В большинстве случаев это включает в себя моделирование конфигураций оборудования вместе с компонентами программного обеспечения, на которых они размещены.
Диаграмма объектов
Статическая диаграмма объектов является экземпляром диаграммы класса; она показывает снимок подробного состояния системы в определенный момент времени. Разница в том, что диаграмма классов представляет собой абстрактную модель, состоящую из классов и их отношений.
Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно — чтобы показать примеры структуры данных.
Диаграмма пакетов
Диаграмма пакетов — это структурная схема UML, которая показывает пакеты и зависимости между ними.
Она позволяет отображать различные виды системы, например, легко смоделировать многоуровневое приложение.
Диаграмма составной структуры
Диаграмма составной структуры аналогична диаграмме классов и является своего рода диаграммой компонентов, используемой в основном при моделировании системы на микроуровне, но она изображает отдельные части вместо целых классов. Это тип статической структурной диаграммы, которая показывает внутреннюю структуру класса и взаимодействия, которые эта структура делает возможными.
Эта диаграмма может включать внутренние части, порты, через которые части взаимодействуют друг с другом или через которые экземпляры класса взаимодействуют с частями и с внешним миром, и соединители между частями или портами. Составная структура — это набор взаимосвязанных элементов, которые взаимодействуют во время выполнения для достижения какой-либо цели. Каждый элемент имеет определенную роль в сотрудничестве.
Диаграмма профилей
Диаграмма профилей позволяет нам создавать специфичные для домена и платформы стереотипы и определять отношения между ними. Мы можем создавать стереотипы, рисуя формы стереотипов и связывая их с композицией или обобщением через интерфейс, ориентированный на ресурсы. Мы также можем определять и визуализировать значения стереотипов.
Диаграмма прецедентов
Диаграмма прецедентов описывает функциональные требования системы с точки зрения прецедентов. По сути дела, это модель предполагаемой функциональности системы (прецедентов) и ее среды (актеров).
Прецеденты позволяют связать то, что нам нужно от системы с тем, как система удовлетворяет эти потребности.
Диаграмма деятельности
Диаграммы деятельности представляют собой графическое представление рабочих процессов поэтапных действий и действий с поддержкой выбора, итерации и параллелизма.
Они описывают поток управления целевой системой, такой как исследование сложных бизнес-правил и операций, а также описание прецедентов и бизнес-процессов.
В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов.
Диаграмма состояний
Диаграмма состояний — это тип диаграммы, используемый в UML для описания поведения систем, который основан на концепции диаграмм состояний Дэвида Харела. Диаграммы состояний отображают разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Она помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии.
Диаграмма последовательности
Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.
Диаграмма Коммуникации
Как и диаграмма последовательности, диаграмма коммуникации также используется для моделирования динамического поведения прецедента. Если сравнивать с Диаграммой последовательности, Диаграмма коммуникации больше сфокусирована на показе взаимодействия объектов, а не временной последовательности. На самом деле, диаграмма коммуникации и диаграмма последовательности семантически эквивалентны и могут перетекать одна в другую.
Диаграмма обзора взаимодействия
Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.
Временная диаграмма
Временная диаграмма показывает поведение объекта (ов) в данный период времени. По сути — это особая форма диаграммы последовательности и различия между ними состоят в том, что оси меняются местами так, что время увеличивается слева направо, а линии жизни отображаются в отдельных отсеках, расположенных вертикально.
Зачем в UML столько диаграмм?
Причина этого заключается в том, что можно взглянуть на систему с разных точек зрения ведь в разработке программного обеспечения будут участвовать многие заинтересованные стороны, такие как: аналитики, конструкторы, кодеры, тестеры, контроль качества, клиенты, технические авторы.
Все эти люди заинтересованы в различных аспектах системы, и каждый из них требует разного уровня детализации.
Например, кодер должен понимать проект системы и уметь преобразовывать проект в код низкого уровня.
Напротив, технический писатель интересуется поведением системы в целом и должен понимать, как функционирует продукт.
UML пытается предоставить язык настолько выразительным образом, что все заинтересованные стороны могут извлечь выгоду, как минимум из одной диаграммы UML.
UML, Классы и Отношения
Существует много разработанных теорий, задокументированных технологий и парадигм программирования. Перед тем как углубиться с головой в их изучение было бы мудро изучить сам принцип взаимодействия программ и их структур. UML предлагаем вам разработанный стандарт что бы сделать это.
Эту статью я бы хотел посвятить одному из небольших разделов UML — диаграмме классов (class diagrams)
Перед изучением автор советует иметь под рукой UML редактор или «поиметь» сейчас один из след UML редакторов:
думаю они уже были разобраны вот в этой статье habrahabr.ru/blogs/webdev/42812
Эта статья не вдается во все тонкости UML, она посвящена базовым навыкам, таким как понимание связей и отношений классов или других структур данных
Что такое диаграммы классов?
Понятие класса диаграммы представляет собой описание сущности и его отношений. Сущность в большинстве случает представляет класс или интерфейс который содержится в вашем коде, но иногда сущность может ссылаться на более абстрактные объекты или даже на типы данных
Представление Классов
все очень просто:
Вверху пишется имя класса
Средняя часть компонента представлена в виде свойств, ссылок и атрибутов
Нижняя часть компоненты представлена в виде операций которые в большинстве случаев соответствуют методам в коде, подчёркнутые операции означают статическую операцию
Названия абстрактных классов будет выделено курсивом
Интерфейсы представлены идентично по отношению к классам за исключением того что в название будет добавлено ключевое слово
Пакеты
Пакет это сущность которая представляет собой группу классов и интерфейсов. В основах UML пакет представлен в след виде:
Типы данных
Типы данных — это тоже сущности, но за исключением классов они не могут быть представлены отдельно в диаграмме классов — они всегда связанны с атрибутом, принадлежат входным аргументам или возвращающим значением.
Представление различных типов видимости данных в UML
+ public
# protected
— private
UML не ограничена только виденьем членов класса — сам класс может иметь своё виденье тоже. Если вы хотите посмотреть «на всю картину» вам нужно использовать пакетную диаграмму.
Отношения
Последовательное представление отношений сущностей очень полезно. Самая главная часть диаграммы классов — это отношение.
Ниже представлены всех отношения которые мы будем рассматривать:
Associations
Bi-directional asociation (standart association)
Uni-directional association
Associationo class (drop class)
Aggregation
Regular aggregation
Composition (composite aggregation)
Generalizations
Dependencies
Assocations
Assocations — это отношение между двумя классификаторами, описывающее связь между их экземплярами. Ассоциации имеют навигацию, показывая отношение одного класса к другому. Каждая сущность вовлечённая в эту связь выполняет определённую роль, роли могут быть назначены.
Так же здесь могут быть разные отношения между сущностями:
0..1 ноль или один
1 только один
0..* ноль или много
1..* один или много
n Только n (где n > 1)
0..n ноль к n (где n > 1)
1. n один к n (где n > 1)
все эти параметры опциональные, но если вы их укажете, в дальнейшем может значительно улучшить читабельность диаграммы.
Если связь не указана то по умолчанию использует 1 к 1
Bi-directional naviageble association
Bi-directional подразумевает что оба класса осведомлены о свой зависимости к другому классу. Давайте рассмотрим диаграмму
Этот пример показывает что оба класса ShoppingCart и Customer осведомлены о существовании друг друга и таким образом взаимодействуют. Хотя ShoppingCart относиться к Customer и наоборот, они оба могут быть частью чего-то большего.
Обратите внимание на множественное отношение, в примере у покупателя может быть несколько покупательских тележек.
Давайте рассмотрим код приведенной выше диаграммы:
итак нам нужно запомнить что оба класса знают о существовании друг друга
Uni-direction navigable association
в Uni-direction отношении только один класс осведомлён о существовании другого
В этом примере, класс ShoppingCart ничего не знает об классе Customer, но! Customer осведомлен о ShoppingCart и в этом проявляется их отношение. Отметьте что мы оставили множественное значение, подчеркивая что класс Customer знает об множестве ShoppingCart, в то время как само множество ShoppingCart ничего не знает об классе Customer.
Для общности картины, отношение Customer to ShoppingCart может быть диагонально перевернуто, и тогда мы получим вот такую схему:
сейчас единственный класс ShoppingCart относиться ко множеству Customer, без их «виденья». Думаю этот пример Uni-directional должен быть вам знакомым
дайте рассмотрим сам код:
Association class:
Класс ассоциаций, или drop class это класс который показывает специфическую ассоциацию:
пунктирная линия в примере показывает нам что сущность Customer относиться к сущности ShoppingCart и при этом существует сущность WishList, те отношение между Customer и ShoppingCart зависит от существования WishList.
Drop class может принимать любое отношение, включая агрегированную ассоциацию (см след параграф) с любой навигацией.
Круг на зарисовке — опционален.
По традиции, конечно пример кода:
Aggregation (aggregate association)
Агрегирование — показывает что одна сущность является частью другой. Если говорить на простом программерском языке, то это означает что экземпляр сущности наследуется другим через свойства объекта.
Regular aggregation
В обычом агрегированнии цикл жизни сущности зависит от цикла жизни сущностей его образовавших, это и состовляет их отношение. Отмете что ромбообразная форма у края указывает на образующию сущность.
ниже нарисован сценарий, который должерн быть вам довольно знакомым:
Один экземпляр Customer наследует один экземпляр ShoppingCart, в роли currentCart. Однако, Customer
получает существующий объкт ShoppingCart, создавая тем самым зависимость экзепляра ShoppingCart от экземпляра Customer.
давайте рассмотрим код:
Composite Aggregagtion (composition)
В композитивном агрегированнии сам объкт это композиция частей других объектов чей жизненый цикл зависит от жизни самой композиции.
Здесь должна быть строгая связь, в которой целое это композиция его частей:
1. У машины есть колёса, но 4 колеса не состовляют машину
2. Mysql Кластер это композиции mysql серверов, но сам по себе mysql сервер не представляет кластер.
как видно из 2-го примера — у нас должна быть довольно строгая связь. Пользуясь этой связью давай приведем еще один пример:
США это композиция ее штатов:
Возможно все штаты америки не равны США, но здесь мы имеем строгую связь которую требует Composite Aggregation:
США не может сущестовать без своих штатов, машина не может выполнять свои функции без колес, а покупатель не существует без покупательской тележки.
Подумайте про силу связи перед тем как решить проблему зависимости жизненого цикла, а не наоборот:
При моделировании зависимость в жизненый циклах не должна усилять связи.
Если связь слабая — regular aggregation это лучший выбор:
в последствии, при развитии проекта, компоненты могут начать использовать части других компонент, что сведет диаграму на нет если у вас будет сильная жизненая зависимость.
давайте рассмотрим пример на нашей коммерческой системе:
в ней мы решили что ShopppingCart не может сущестовать без Customer (без этого наша система теряет смысл)
Мы так же решили что ShoppingCart это пуп вселенной, по крайней мере для нас, поэтому нам нужно постараться определить остальные объкты через связь с покупательской тележкой:
Результатом нашего решения будет вывод, что покупатель не может существовать без покупательской тележки, а не наоборот,
вы говорите — это магазин, ничего не покупаете — уходите 😛
в чем оптимальный выбор — это остаеться на усмотрение читателя, я же покажу диаграму:
Generalizations
Generalizations — представление кода «как он есть», это связи с которыми вы уже должны были подружиться,( за время програмирования =):
интерфейсы и наследование, я просто приведу вам небольшой пример натации обоих:
асбтракный класс ProductList наследуеться от интерфейса ItemList, ShoppingCart расширяет функциональность ProductList
Dependencies:
Dependencies показывать что изменение в одной структуре может потребовать изменение в другой, во многих случаях другие типы зависимостей уже подразумивают какую-либо зависимость, но есть вы хотите описать зависимости более детально — вы можете использовать dependency, что бы описать связь между эллементами. Это подразумевает что зависимость слабая и не пригодна для использования в associative relation.
давайте посмотрим след диаграмму:
Customer зависит от WishList тк он содержит желаемые предметы покупки. Пунктирная линия показывать что getWishList это статическая операция.
Customer зависит от работы ф-ции getWishList.
В противоречие ассоциации, Dependencies не несут дополнительной смысловой нагрузки и не указываться роли эллементов. При использовании Dependencies так же не обязательно иметь отношения с установленными сущностям (но в этих случаях автор советует использовать ассоицации). Множества не могут быть описаны с помощью зависимостей.
Что бы лучше посмотреть на зависимости — давайте вглянем на наш проект с высоты птичьего полета, будем использовать пакетную диаграмму
Мы видем два пакета: e-commerce и user_management, e-commerce зависит от user_management, для таких страшных вещей как аутентификация и тп.
Эта зависимость кажеться необходимой, но вашей главной задачей при проектировании системы являеться создание как можно меньше такого рода зависимостей между эллеметами а так же создание их взаимозаменяющей возможности. Не забывайте что диаграмма классов не может указать степень зависимости, то её можно принебрень, но не следует от этого отказываться полностью.