Диаграммы классов. Ассоциации.
В прошлой статье про UML, я описал в общих чертах диаграмму одиночного класса. Сегодня я постараюсь описать то, как связывать диаграммы отдельных классов в единую картинку. Но прежде, я хотел бы сделать небольшое теоретическое отступление, особо важное для понимания сути диаграмм, в начале пути.
Как я раньше уже замечал, основное назначение диаграмм – это представление структуры вашего кода в наглядном и понятном другим программистам виде. Но, я не сказал в каком контексте это “знание о программе” следует понимать.
Нет конкретных требований к построению диаграмм классов для всех программы. Например, не обязательно покрывать весь код этими диаграммами, а можно просто нарисовать на них основные моменты. Есть программисты, которые придерживаются этой точки зрения, а есть, которые предпочитают отображать всю картину в деталях.
Исходя из этого, выделяют три точки зрения на построение диаграмм: концептуальная, диаграмма как спецификация и точка зрения реализации. Описывать каждую я не стану – вы сами поймете, чем они отличаются, после того как начнете применять эту технологию проектирования. Поэтому не ограничивайте себя правилами на первых парах Что бы вы не отобразили на диаграмме классов – это в любом случае будет хоть какой-то полезной информацией для другого программиста и ваш труд не пропадет зря.
Теперь возвращаемся к практике. Сегодня я покажу, как можно отображать связи между классами. Всего есть два вида связи между классами – это ассоциации и подтипы. Тут все просто.
Допустим, у нас есть два класса – Клиент и Заказ. Нам нужно отобразить эти два класса на диаграмме и показать, как они между собой связаны. Диаграмма будет выглядеть так:
С двумя блоками мы уже знакомы, а вот линия, которая их соединяет – это и есть ассоциация. На каждом конце линии расположены знаки: 1 и * - они определяют кратность конца ассоциации. Другими словами, на диаграмме показано, что у 1-го Клиента может быть много Заказов. Вот и все ?
Кроме таких кратностей бывают еще и другие:
- 0..1 – необязательная кратность (один или вообще нет)
- 0..* - ни одного или любое кол-во
- 1..* - один или любое кол-во (0 быть не может)
Это самые частые, но, зная принцип, можно и другие придумать, мне кажется. Все равно будет понятно, что имеется в виду.
На этом все на сегодня. У этой темы есть некоторый пороговый момент, который надо преодолеть через практику. Попробуйте нарисовать несколько диаграмм – чтобы более глубоко понять эти принципы и как их нужно применять на практике.
Удачи.
[…] https://i-novice.net/diagrammy-klassov-associacii/ […]
Не совсем понятно, что такое диаграммы классов и для чего они нужны.
Диаграммы классов нужны в такой сфере, как программная инженерия. При написании реальных проектов нужно сначала детально описать все связи и структуру программы, а потом уже приступать к ее написанию.
Вы не могли бы в двух словах описать метод сценариев при проектировании модели классов.