Что это такое и почему они важны?
UML — это аббревиатура от Unified Modeling Language. С точки зрения непрофессионала, UML — это то, как все разработчики программного обеспечения во всем мире могут работать вместе с минимальными недоразумениями.
Диаграмма UML используется для понимания структуры программы с точки зрения ООП.
А теперь не надевай свое гневное лицо. Я объясню, что это значит.
Поговорим об ООП
ООП означает объектно-ориентированное программирование. Я не буду вдаваться здесь в суперконкретные детали, но в основном речь идет о превращении частей программы в животных.
Конкретные разделы программы могут быть идентифицированы и сгруппированы в объект.
У этого Объекта есть переменные, которые его описывают, так же как у животного либо есть шерсть, либо нет, либо вместо зубов есть клюв и так далее. Эти переменные называются атрибутами.
У Объекта также есть определенные вещи, которые он может делать, точно так же, как животное может ползать, ходить, прыгать или летать. Это так называемые методы.
Так что, когда вы создаете программу, вы можете просто вызвать любых животных и поставить с ними танец. Скажи этому идти сюда, а этому прыгать туда, показывать зубы и тому подобное.
Почему я забочусь об этих ООП-животных?
В конце концов вы понимаете, что создание нового животного/объекта с нуля каждый раз, когда оно вам нужно, и повторный список всех его методов и атрибутов раздражает, даже с помощью Ctrl+C.
Не проблема. Мы можем создать шаблон для всех животных/объектов определенного типа, который уже имеет необходимые атрибуты и методы этого типа. Затем каждый раз, когда требуется новое животное/объект указанного типа, мы просто обращаемся к его шаблону. Легкий!
Этот шаблон, который мы описали, называется классом. Звучит знакомо?
Существует различие между классами и классами, но ради тех, кто просто хочет узнать, как это работает, я попрошу всех читателей, которые знают об этом, любезно оставить свои оговорки, пока они не дойдут до раздела комментариев, тогда вы можете позволить мне иметь это :)
Диаграмма классов UML состоит из четырех частей:
- Имя класса
- Атрибуты класса
- Методы класса
- Отношения между разными классами
Имя класса написано в верхнем прямоугольнике. Все, что идет ниже, принадлежит этому классу.
Средний прямоугольник предназначен для перечисления атрибутов класса. Вы можете включить как имя атрибута, так и тип данных. Каждое имя атрибута должно быть уникальным в соответствующем классе.
Нижний прямоугольник предназначен для перечисления методов класса. Стиль, используемый на изображении выше, представляет собой нотацию верблюда с пустыми скобками, чтобы показать, что это функция (методы — это функции, принадлежащие классу, я очень надеюсь, что вы знаете, что такое функция).
Не поддавайтесь искушению пропустить пустые прямоугольники, если нет атрибутов или методов, которые можно было бы упомянуть. Это также важно.
Наконец, соединяющие их линии, маленькие ромбовидные символы и числа над линиями описывают отношения между классами.
Вместо того, чтобы использовать причудливые профессиональные термины для классовых отношений, я объясню их с точки зрения непрофессионала:
- Ромбовидный знак показывает, сколько «Объектов типа класса», которых он касается, может взаимодействовать с «Объектами типа класса», которых коснулись на другой стороне линии.
Например, многие клиентские объекты будут взаимодействовать с каждым серверным объектом.
Будьте осторожны, это также означает, что один и тот же клиентский объект не может взаимодействовать более чем с одним серверным объектом одновременно. - Цифры показывают минимальное количество экземпляров класса (объектов), которые могут существовать в отношениях.
Например, серверный объект может существовать без каких-либо прикрепленных к нему клиентских объектов (0…*[Может быть ноль или более 1 объектов на этом конце]), но клиентский объект не может существовать, если нет серверных объектов, к которым он может быть прикреплен (1 [на этом конце должен быть один и только один]).
Вывод
Я надеюсь, что мне удалось достаточно демистифицировать эту тему, чтобы любой, кто заинтересован в планировании простых ООП-программ, мог сделать это с легкостью.
В UML доступно гораздо больше возможностей для описания структуры и процесса программы, а не только те, что в приведенном выше примере. Вы можете найти их в книгах и на сайтах, посвященных этой теме. Надеюсь, теперь их станет немного легче понять.
Оставьте комментарий, если вы думаете (или знаете), что я что-то сделал не так, или это можно было бы описать лучше.
Увидимся.
