Uml ссылка что это
Использование диаграммы классов UML при проектировании и документировании программного обеспечения
Предисловие
Парадигма объектно-ориентированного программирования (далее просто ООП) повсеместно используется при создании современного программного обеспечения. Модель объектов, заложенная в данную парадигму, способна достаточно точно описывать свойства и возможности сущностей реального мира. Разумеется, эти объекты не существуют обособленно друг от друга, они взаимодействуют друг с другом для достижения какой-то глобальной цели разрабатываемой системы.
Стандартная библиотека некоторого языка программирования – замечательный сборник полезных утилит. Однако разнообразие решаемых программистами задач так велико, что одной только стандартной библиотекой ограничиться не получится. Программисту часто приходится самому создавать необходимый ему набор функциональности. Это можно сделать, создав пакет функций или набор классов.
Создание собственных классов при разработке программы добавляет в проект новый уровень абстракции, который позволяет определить некоторый функционал системы и работать в дальнейшем только с ним.
Чем выше уровень абстракции, которым пользуется программист, тем выше уровень его продуктивности при разработке приложения.
Использование ООП может существенно упросить жизнь программисту. Это достигается за счёт сокрытия особенностей внутренней реализации классов. Программисту остаётся лишь пользоваться её удобствами. Кажется, что ООП – панацея от всех проблем. Однако на практике, если не иметь чёткого представления о том, какие классы нужно реализовать и как ими потом пользоваться, в результате может получиться очень запутанная система, которая начнёт порождать спагетти-коду (от англ. “spaghetti code”), который будет лишь мешаться, когда вы захотите добавить что-то новое в систему.
Чтобы избежать большинства проблем, возникающих при использовании ООП, нужно:
Иметь некоторый опыт создания программ и использования классов.
Строить структурные диаграммы классов.
Первое придёт со временем, а со вторым я могу вас познакомить прямо сейчас. Сегодня мы разберём диаграмму классов UML.
reference (ссылка)
Обозначение элемента модели; обычно называется указателем (pointer).
Элементы модели связываются друг с другом при помощи двух видов метаотношений: принадлежности и ссылки. Принадлежностью называется отношение между элементом и его составляющими, иначе говоря, его частями, которые определяются в нем и принадлежат ему. Отношение принадлежности образует строгое дерево. Включенные элементы подчинены своему элементу-контейнеру. На иерархии включения основываются отношение принадлежности, управление конфигурацией и хранение моделей.
Ссылка представляет собой отношение между элементами на одном уровне детализации или между элементами, содержащихся в разных контейнерах. Например, ссылками являются отношения между ассоциацией и классами, которые в ней участвуют, между атрибутом и классом или типом данных, который описывает тип атрибута, а также между связанным шаблоном и значениями его аргументов. Чтобы ссылка стала возможной, ссылающийся элемент должен иметь видимость по отношению к элементу, на который делается ссылка. В целом, это означает, что пакет, из которого производится ссылка, должен иметь видимость по отношению к тому пакету, в котором содержится целевой элемент этой ссылки. Это подразумевает наличие между пакетами отношений доступа или импорта. Кроме того, элемент, на который делается ссылка, должен иметь такую видимость, которая делала бы его видимым вне em пакета (если только ссылка на него не делается из того же самого пакета).
Обратите внимание, что ссылка является внутренним отношением метамодели, не видимым для полъзователя, и используется для построения других отношений.
UML-диаграммы классов
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования.
Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Словарь UML включает три вида строительных блоков:
Сущности – это абстракции, которые являются основными элементами модели, связи соединяют их между собой, а диаграммы группируют представляющие интерес наборы сущностей.
Диаграмма – это графическое представление набора элементов, чаще всего изображенного в виде связного графа вершин (сущностей) и путей (связей). Язык UML включает 13 видов диаграмм, среди которых на первом месте в списке — диаграмма классов, о которой и пойдет речь.
Диаграммы классов показывают набор классов, интерфейсов, а также их связи. Диаграммы этого вида чаще всего используются для моделирования объектно-ориентированных систем. Они предназначены для статического представления системы.
Большинство элементов UML имеют уникальную и прямую графическую нотацию, которая дает визуальное представление наиболее важных аспектов элемента.
Сущности
Диаграммы классов оперируют тремя видами сущностей UML:
Поведенческие сущности – динамические части моделей UML. Это «глаголы» моделей, представляющие поведение модели во времени и пространстве. Основной из них является взаимодействие – поведение, которое заключается в обмене сообщениями между наборами объектов или ролей в определенном контексте для достижения некоторой цели. Сообщение изображается в виде линии со стрелкой, почти всегда сопровождаемой именем операции.
Структурные сущности — классы
Класс – это описание набора объектов с одинаковыми атрибутами, операциями, связями и семантикой.
Графически класс изображается в виде прямоугольника, разделенного на 3 блока горизонтальными линиями:
Для атрибутов и операций может быть указан один из трех типов видимости:
Видимость для полей и методов указывается в виде левого символа в строке с именем соответствующего элемента.
Каждый класс должен обладать именем, отличающим его от других классов. Имя – это текстовая строка. Имя класса может состоять из любого числа букв, цифр и знаков препинания (за исключением двоеточия и точки) и может записываться в несколько строк.
На практике обычно используются краткие имена классов, взятые из словаря моделируемой системы. Каждое слово в имени класса традиционно пишут с заглавной буквы (верблюжья конвенция), например Sensor (Датчик) или TemperatureSensor (ДатчикТемпературы). 
Для абстрактного класса имя класса записывается курсивом.
Атрибут (свойство) – это именованное свойство класса, описывающее диапазон значений, которые может принимать экземпляр атрибута. Класс может иметь любое число атрибутов или не иметь ни одного. В последнем случае блок атрибутов оставляют пустым.
Атрибут представляет некоторое свойство моделируемой сущности, которым обладают все объекты данного класса. Имя атрибута, как и имя класса, может представлять собой текст. На практике для именования атрибута используются одно или несколько коротких существительных, выражающих некое свойство класса, к которому относится атрибут.
Можно уточнить спецификацию атрибута, указав его тип, кратность (если атрибут представляет собой массив некоторых значений) и начальное значение по умолчанию.
Статические атрибуты класса обозначаются подчеркиванием.
Операция (метод) – это реализация метода класса. Класс может иметь любое число операций либо не иметь ни одной. Часто вызов операции объекта изменяет его атрибуты.
Графически операции представлены в нижнем блоке описания класса.
Допускается указание только имен операций. Имя операции, как и имя класса, должно представлять собой текст. На практике для именования операции используются короткие глагольные конструкции, описывающие некое поведение класса, которому принадлежит операция. Обычно каждое слово в имени операции пишется с заглавной буквы, за исключением первого, например move (переместить) или isEmpty (проверка на пустоту).
Можно специфицировать операцию, устанавливая ее сигнатуру, включающую имя, тип и значение по умолчанию всех параметров, а применительно к функциям – тип возвращаемого значения.
Абстрактные методы класса обозначаются курсивным шрифтом.
Статические методы класса обозначаются подчеркиванием.
Изображая класс, не обязательно показывать сразу все его атрибуты и операции. Для конкретного представления, как правило, существенна только часть атрибутов и операций класса. В силу этих причин допускается упрощенное представление класса, то есть для графического представления выбираются только некоторые из его атрибутов. Если помимо указанных существуют другие атрибуты и операции, вы даете это понять, завершая каждый список многоточием.
Чтобы легче воспринимать длинные списки атрибутов и операций, желательно снабдить префиксом (именем стереотипа) каждую категорию в них. В данном случае стереотип – это слово, заключенное в угловые кавычки, которое указывает то, что за ним следует. 
Отношения между классами
Существует четыре типа связей в UML:
Эти связи представляют собой базовые строительные блоки для описания отношений в UML, используемые для разработки хорошо согласованных моделей.
Первая из них – зависимость – семантически представляет собой связь между двумя элементами модели, в которой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графически представлена пунктирной линией, иногда со стрелкой, направленной к той сущности, от которой зависит еще одна; может быть снабжена меткой.
Ассоциация – это структурная связь между элементами модели, которая описывает набор связей, существующих между объектами.
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в». В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации. 
Двойные ассоциации представляются линией без стрелок на концах, соединяющей два классовых блока.
Ассоциация может быть именованной, и тогда на концах представляющей её линии будут подписаны роли, принадлежности, индикаторы, мультипликаторы, видимости или другие свойства.
Пример кода и диаграммы классов для него
Программа получает данные с датчика температуры (вводятся с консоли) — по 5 измерений для каждого из двух объектов класса TemperatureMeasure и усредняет их. Также предусмотрен класс ShowMeasure для вывода измеренных значений.
Как язык UML помогает организовать работу IT-проекта
Авторизуйтесь
Как язык UML помогает организовать работу IT-проекта
эксперт по системному бизнес-анализу Luxoft Training; евангелист языка UML
«UML устарел»… «UML умер»… Статьи с вариациями на эту тему то и дело всплывают в Сети. Используя эту нотацию для построения моделей уже более 14 лет, я в корне не согласен с такой позицией. Наоборот, в противовес скептикам скажу, что язык жив и, вероятно, ещё долго будет жить. В этом материале постараюсь раскрыть, почему я так думаю.
Unified Modeling Language (UML) был разработан тремя известными сотрудниками Rational Software в начале 90-х и принят в качестве стандарта Object Management Group в 1997 году. Потребность в создании подобного языка ощущалась к тому времени довольно остро, так как программное обеспечение становилось всё сложнее. Обсуждать, описывать и продумывать его работу было всё труднее.
Понимание важности стандартных нотаций для построения моделей пришло ко мне лет 20 назад. На тот момент, еще будучи разработчиком, я искал способ донести до руководства компании предложения по улучшению бизнес-процессов. Презентовать свои идеи я решил в виде диаграмм, а поскольку на тот момент не пользовался никакими нотациями, просто изобразил всё в виде аккуратных кружочков, прямоугольников и треугольников, соединённых стрелками.
На подготовку этих диаграмм у меня ушло довольно много энергии и времени, но презентация вместо ожидаемого триумфа принесла лёгкое разочарование. Руководитель компании, просмотрев диаграммы и прослушав мою презентацию, сказал, что видит в моих предложениях рациональное зерно, но совершенно не может ухватить детали. Откровенно говоря, я списал это на счёт самого руководителя, ведь в правильности диаграмм и прорывном характере идей я был уверен. Поэтому записи свои сохранил – до лучших времен.
Спустя год, решив воплотить в жизнь одну из этих идей, я оказался ровно в таком же положении, что и руководитель компании во время моей презентации. В диаграммах явно чувствовалось рациональное зерно, но им не хватало понятной системы, а назначение «кружков», «прямоугольников» и «треугольников» к этому времени уже забылось. Именно в тот момент я и решил обратить внимание на стандартные нотации.
Когда же через несколько лет в моё поле зрения попали UML-диаграммы, они привлекли меня своей простой, но выразительной формой, хоть мне и не сразу удалось в них разобраться.
Для кого подходит UML
Как только начинаются споры о применимости UML в современных условиях, на ум приходят две известные шутки. Первая говорит о том, что в интернете на любой вопрос можно найти любой ответ. И не только в интернете, должен заметить. Книги, статьи, выступления на конференциях, мнения коллег и обсуждения на форумах демонстрируют полный спектр эмоций – от полного отрицания до фанатичной приверженности. Так кому же верить?
И тут всплывает в памяти другой диалог: «- Не люблю я котов… — Да вы их просто готовить не умеете!». На мой взгляд, секрет полезности (или неполезности) UML кроется именно в этом – в умении правильно «приготовить» диаграммы. Если человек говорит, что какая-то нотация не работает, возможно, он просто не потрудился разобраться в ней. Может быть, эта нотация не соответствует его стилю мышления. Так и с UML: одни специалисты пользуются и получают от этого удовольствие, другие нет. Это просто выбор каждого.
В нашем мире не существует абсолютных истин. В IT-сфере тем более не стоит искать правила, которые были бы одинаково применимы и эффективны для любого проекта или ситуации. Каждый проект, команда, заказчик выбирают для себя то, что удобно им. Поэтому всё, что говорится о UML или других нотациях, – всегда частное мнение.
К тому же для разных ролей в проектной команде UML имеет различную степень применимости. Например, UML отлично справляется с описанием технической стороны системы: архитектуры, алгоритмов, протоколов обмена, процессов и пр. Но руководителям проекта, техническим писателям и дизайнерам интерфейсов пользователя он, скорее всего, не пригодится.
Казалось бы, разработчики должны знать и использовать UML лучше и чаще всех. Но нет, довольно часто они говорят, что проще сразу начать писать код, не тратя время на рисование диаграмм. И в простых случаях такой подход действительно оказывается более выгодным.
Но при разработке больших систем с разветвлённой архитектурой и сложными структурами данных лучше сначала подумать, а потом уже кодить. Код, написанный без глубокого понимания задачи, потом будет много раз переделываться. В ходе переделок меняется логика функционирования системы, её структура становится более запутанной. Вносить очередные изменения становится всё сложнее и сложнее.
А полезен ли UML для аналитиков? Вполне! Например, системные аналитики, будучи ближе к технической реализации системы, могут использовать UML для моделирования структур данных или взаимосвязей между компонентами системы. Хотя для системных аналитиков придуманы и другие нотации, например, SysML, знание UML представляется для них ценным навыком.
Для бизнес-аналитиков применимость UML кажется заметно меньшей. Но опять-таки, это зависит от ситуации. Мне, например, UML помогает анализировать предметную область, продумывать некоторые задачи, описывать требования, проектировать структуры данных.
Чем может помочь UML
Во-первых, UML – это формальный язык, который подчиняется чётко определенным правилам. Каждая его диаграмма, каждый элемент или связь на диаграмме подчинены определённой логике, несут определённый смысл. А это означает, что следование таким правилам дисциплинирует сознание автора модели, направляет процесс его мышления по определённому руслу.
Здесь можно было бы посетовать на ограничение творческого самовыражения автора модели. Но разве это является нашей целью в ходе проекта? Пожалуй, гораздо важнее для нас донести свои идеи, открытия и решения до коллег. Донести так, чтобы не пришлось потом долго отвечать на дополнительные вопросы, а реализация в итоге соответствовала задумке.
Именно формализация позволяет создавать диаграммы, понятные другим людям (тоже знающим UML, разумеется) и не теряющие своей понятности с течением времени (как это было с моими доморощенными диаграммами годы назад).
Во-вторых, стандарт UML содержит почти полтора десятка диаграмм, что позволяет покрыть потребности разных ролей в проекте. Благодаря UML можно создать информационный фундамент для описания различных аспектов системы – начиная с верхнеуровневых требований до решений, непосредственно реализованных в коде.
К примеру, диаграмма классов (class diagram) помогает лучше понять, как распределить обязанности между разными частями системы. Причем речь идёт не только о тех классах, которые разработчик описывает в исходном коде программы. Через классы можно выразить даже понятия предметной области, что позволит лучше понять потребности заказчика и нюансы его работы.
Давайте в качестве иллюстрации попробуем описать часть системы для проведения онлайн-конференций. Судя по диаграмме ниже, встречу может создать только зарегистрированный пользователь, а участвовать в ней могут пользователи двух типов: простые участники и один или несколько ведущих (хостов). Если встреча является повторяющейся, тогда для неё задаются параметры периодичности.
На диаграмме присутствуют и английские названия, и русские, типы данных у одного класса выглядят стандартными, а у другого названы в свободной форме, у пары классов показаны атрибуты, у одного – только операции. Не очень аккуратно, да? Но если знакомый разработчик скажет вам, что это не классы, не верьте.
Это пример диаграммы концептуальных классов, с помощью которой мы можем описать предметную область на очень высоком уровне. Разработчики, конечно же, будут использовать другие классы, таблицы базы данных тоже будут выглядеть по-другому, но эта концептуальная диаграмма позволит аналитику и лучше разобраться в проблеме, и чётче описать требования к ее решению.
Диаграмма деятельности (activity diagram) описывает процесс, в котором одна операция следует за другой, подчиняясь определённой логике. Она позволяет изобразить алгоритмы принятия решений, бизнес-процессы или выполнение пользователями тех или иных действий в системе. Как правило, диаграммы этого типа бывают понятны даже далёким от IT-сферы людям.
Диаграмма вариантов использования (use case diagram) описывает сервисы, предоставляемые системой внешнему миру, и действующих лиц, которые имеют доступ к этим сервисам. Эта диаграмма бывает полезна в самом начале проекта, когда еще нет чёткого представления о том, как именно должна работать разрабатываемая система. Такое понимание как раз и формируется в ходе построения, обдумывания и обсуждения диаграммы.
Ещё одним важным результатом являются вопросы, которые неминуемо возникают у аналитика при построении диаграммы вариантов использования. Эти вопросы позволяют глубже изучить предметную область и потребности заказчика, уточнить требования к системе и в результате предложить наиболее подходящее для заказчика решение.
Эта статья не предполагает знакомство с каждым типом диаграмм UML, приведённые примеры стоит рассматривать лишь как очень поверхностную иллюстрацию возможностей UML и его пользы на различных этапах проекта.
Например, диаграмма состояний (state machine diagram) позволяет описать жизненный цикл объекта в виде графа, вершинами которого являются состояния, а дугами – события или действия, ведущие к смене состояния.
В-третьих, UML – это наглядный способ для поддержки процесса мышления. Он позволяет разбить задачу на части, продумать их по отдельности, а потом склеить в комплексное финальное решение.
Когда мы описываем что-либо с помощью текста, информация воспринимается последовательно. И не важно, о каком тексте идет речь: это может быть и текст требований, написанный на естественном (человеческом) языке, и исходный текст программы, написанный на алгоритмическом языке. В любом случае, чтобы понять смысл текста, мы должны читать его символ за символом, слово за словом, строку за строкой. Часть информации, прочитанная раньше, может забыться или исказиться. Плюс к этому, чтобы найти какой-то определённый фрагмент, приходится затрачивать время на повторный просмотр текста.
Но если информацию представить в виде диаграммы, вся картина будет видна полностью (разумеется, если диаграмма построена правильно и не перегружена деталями). В таком случае сразу видны все элементы и связи между ними, а взгляд без труда находит нужный фрагмент диаграммы. Такую диаграмму можно использовать в качестве «карты», помогающей ориентироваться в большом количестве проектных артефактов.
Какие подводные камни могут омрачить впечатление об UML
UML изучают в институтах, но довольно часто это процесс не привязывают к жизни, не подкрепляют реальными примерами. И вместо того, чтобы стать для IT-специалиста родным языком, UML начинает казаться языком мертвым, похожим на латынь.
Главная сложность в освоении UML состоит в том, что для построения диаграмм требуется определенный стиль мышления. Например, классы – это достаточно абстрактная концепция. Если приучить себя мыслить классами, видеть примеры во внешних предметах и событиях, построение диаграммы не вызовет больших затруднений. Если же человек не обладает стилем мышления, созвучным логике UML, моделирование будет казаться занятием непонятным, трудным и не очень полезным.
Критики, говоря о недостатках UML, упоминают:
Получается, что трудности в работе с UML – штука очень субъективная. Главное, что все эти трудности преодолимы (в основном) и управляемы. Если UML в целом нравится и человеку кажется, что он может применить его в своей практике, аргументы «за» найдутся легко. В противоположной ситуации доводы «против» подобрать также не составит особого труда.
Я не считаю, что нужно бороться за повсеместное внедрение UML, чтобы все айтишники его знали на 100%. На мой взгляд, нужно просто использовать UML разумно и рационально в тех случаях, когда он уместен.
Неочевидные случаи: опыт применения UML в Agile-проекте
Этот случай в моей практике был уникальным, но достаточно показательным. Он произошел лет 10 тому назад, когда UML уже стал для меня привычным инструментом анализа и продумывания решений.
Работая коучем с начинающими Agile-командами, я получил от одной из команд запрос на помощь в планировании. Суть проблемы состояла в том, что коллеги разработали 130 user stories, но описали их в виде простого линейного списка. Поэтому при планировании каждого спринта им приходилось весь этот список просматривать, что c каждым разом становилось всё труднее и труднее.
Поскольку в суть проекта я глубоко не вникал, пришлось попросить команду немного рассказать о том, какая система разрабатывается и для чего. Пока коллеги рассказывали, я рисовал на доске картинки – просто чтобы не упустить ничего важного.
Сначала это были абстрактные рисунки, но как только идея системы стала проясняться, я совершенно автоматически перешел к рисованию вариантов использования (use case diagram). Вот тут-то я впервые услышал вопрос «А что, UML ещё жив?». Оказалось, что не только жив, но и достаточно бодр.
Как правило, в технологии Agile-разработки не находится места долгим медитациям над UML-диаграммами, поэтому коллеги сначала приняли мои художества как кощунство и приверженность устаревшим технологиям. Но всё оказалось проще.
Благодаря диаграмме вариантов использования мы выделили главных действующих лиц, затем определили основные функциональные блоки и разбили их на фичи. А потом всё это обозвали эпиками и организовали в виде дерева. После этого осталось лишь распределить все user stories по узлам этого дерева (т.е. по эпикам). И чудо свершилось – вместо громоздкого и неудобного линейного списка мы получили удобную и логичную структуру, работать с которой стало несоизмеримо проще.
Кстати, как только мы распределили user stories по дереву, стало видно, что одна из трёх подсистем уже практически готова – оставалось доделать лишь одну стори. Раньше об этом никто и не подозревал, так как структура требований отсутствовала и, как следствие, было трудно понять, к чему относится каждая user story. Поэтому команда и «буксовала», не понимая, куда двигаться дальше.
Ту диаграмму вариантов использования я безжалостно с доски стёр – свою задачу она уже выполнила, сохранять её в документах проекта просто не было смысла.
Таким образом, UML нужен не только для того, чтобы нарисовать красивую диаграмму и внести её в какой-то документ или опубликовать на сайте. UML является отличным инструментом для продумывания технических проблем и обсуждения их с коллегами. Диаграммы UML позволяют увидеть картину в целом, структурировать её, найти недостающие звенья, сформулировать вопросы заказчику или разработчикам. А потом обогатить диаграммы полученными ответами.