Для чего используется язык uml кратко

Обновлено: 05.07.2024

1. Предоставить в распоряжение пользователей легко воспринимаемый и выразительный язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем самого различного целевого назначения.

Речь идет о том, что важным фактором дальнейшего развития и повсеместного использования методологии ООАП является интуитивная ясность и понятность основных конструкций соответствующего языка моделирования. Язык UML включает в себя не только абстрактные конструкции для представления метамоделей систем, но и целый ряд конкретных понятий, имеющих вполне определенную семантику. Это позволяет языку UML одновременно достичь не только универсальности представления моделей для самых различных приложений, но и возможности описания достаточно тонких деталей реализации этих моделей применительно к конкретным системам.

Практика системного моделирования показала, что абстрактного описания языка на некотором метауровне недостаточно для разработчиков, которые ставят своей целью реализацию проекта системы в конкретные сроки. В настоящее время имеет место некоторый концептуальный разрыв между общей методологией моделирования сложных систем и конкретными инструментальными средствами быстрой разработки приложений. Именно этот разрыв по замыслу OMG и призван заполнить язык UML.

Отсюда вытекает важное следствие – для адекватного понимания базовых конструкций языка UML важно не только владеть некоторыми навыками объектно-ориентированного программирования, но и хорошо представлять себе общую проблематику процесса разработки моделей систем. Именно интеграция этих представлений образует новую парадигму ООАП, практическим следствием и центральным стержнем которой является язык UML.

2. Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области.

Хотя язык UML является формальным языком – спецификаций, формальность его описания отличается от синтаксиса как традиционных формально-логических языков, так и известных языков программирования. Разработчики из OMG предполагают, что язык UML как никакой другой может быть приспособлен для конкретных предметных областей. Это становится возможным по той причине, что в самом описании языка UML заложен механизм расширения базовых понятий, который является самостоятельным элементом языка и имеет собственное описание в форме правил расширения.

В то же время разработчики из OMG считают крайне нежелательным переопределение базовых понятий языка по какой бы то ни было причине. Это может привести к неоднозначной интерпретации их семантики и возможной путанице. Базовые понятия языка UML не следует изменять больше, чем это необходимо для их расширения. Все пользователи должны быть способны строить модели систем для большинства обычных приложений с использованием только базовых конструкций языка UML без применения механизма расширения. При этом новые понятия и нотации целесообразно применять только в тех ситуациях, когда имеющихся базовых понятий явно недостаточно для построения моделей системы.

Язык UML допускает также специализацию базовых понятий. Речь идет о том, что в конкретных7 приложениях пользователи должны уметь дополнять имеющиеся базовые понятия новыми характеристиками или свойствами, которые не противоречат семантике этих понятий в языке UML.

3. Описание языка UML должно поддерживать такую спецификацию моделей, которая не зависит от конкретных языков программирования и инструментальных средств проектирования программных систем.

Речь идет о том, что ни одна из конструкций языка UML не должна зависеть от особенностей ее реализации в известных языках программирования. То есть, хотя отдельные понятия языка UML и связаны с последними очень тесно, их жесткая интерпретация в форме каких бы то ни было конструкций программирования не может быть признана корректной. Другими словами, разработчики из OMG считают необходимым свойством языка UML его контекстно-программную независимость.

С другой стороны, язык UML должен обладать потенциальной возможностью реализации своих конструкций на том или ином языке программирования. Конечно, в первую очередь имеются в виду языки, поддерживающие концепцию ООП, такие как C++, Java, Object Pascal. Именно это свойство языка UML делает его современным средством решения задач моделирования сложных систем. В то же время, предполагается, что для программной поддержки конструкций языка UML могут быть разработаны специальные инструментальные CASE-средства. Наличие последних имеет принципиальное значение для широкого распространения и использования языка UML.

4. Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП.

Говоря об этой особенности, имеют в виду самодостаточность языка UML для понимания не только его базовых конструкций, но что не менее важно – понимания общих принципов ООАП. В этой связи необходимо отметить, что поскольку язык UML не является языком программирования, а служит средством для решения задач объектно-ориентированного моделирования систем, описание языка UML должно по возможности включать в себя все необходимые понятия для ООАП. Без этого свойства язык UML может оказаться бесполезным и невостребованным большинством пользователей, которые не знакомы с проблематикой ООАП сложных систем.

С другой стороны, какие бы то ни было ссылки на дополнительные источники, содержащие важную для понимания языка UML информацию, по мнению разработчиков из OMG, должны быть исключены. Это позволит избежать неоднозначного толкования принципиальных особенностей процесса ООАП и их реализации в форме базовых конструкций языка UML.

5. Поощрять развитие рынка объектных инструментальных средств.

Более 800 ведущих производителей программных и аппаратных средств, усилия которых сосредоточены в рамках OMG, видят перспективы развития современных информационных технологий и основу своего коммерческого успеха в широком продвижении на рынок инструментальных средств, поддерживающих объектные технологии. Говоря же об объектных технологиях, разработчики из OMG имеют в виду, прежде всего, совокупность технологических решений CORBA и UML. С этой точки зрения языку UML отводится роль базового средства для описания и документирования различных объектных компонентов CORBA.

6. Способствовать распространению объектных технологий и соответствующих понятий ООАП.

Эта задача тесно связана с предыдущей и имеет с ней много общего. Если исключить из рассмотрения рекламные заявления разработчиков об исключительной гибкости и мощности языка UML, а попытаться составить объективную картину возможностей этого языка, то можно прийти к следующему заключению. Следует признать, что усилия.достаточно большой группы разработчиков были направлены на интеграцию в рамках языка UML многих известных техник визуального моделирования, которые успешно зарекомендовали себя на практике (см. главу 2). Хотя это привело к усложнению языка UML по сравнению с известными нотациями структурного системного анализа, платой за сложность являются действительно высокая гибкость и изобразительные возможности уже первых версий языка UML. В свою очередь, использование языка UML для решения всевозможных практических задач будет только способствовать его дальнейшему совершенствованию, а значит и дальнейшему развитию объектных технологий и практики ООАП.

7. Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

Язык UML непрерывно совершенствуется разработчиками, и основой этой работы является его дальнейшая интеграция с современными модельными технологиями. При этом различные методы системного моделирования получают свое прикладное осмысление в рамках ООАП. В последующем эти методы могут быть включены в состав языка UML в форме дополнительных базовых понятий, наиболее адекватно и полно отражающие наилучшие достижения практики ООАП.

Чтобы решить указанные выше задачи, за свою недолгую историю язык UML претерпел определенную эволюцию. В результате описание самого языка UML стало нетривиальным, поскольку семантика базовых понятий включает в себя целый ряд перекрестных связей с другими понятиями и конструкциями языка. В связи с этим так называемое линейное или последовательное рассмотрение основных конструкций языка UML стало практически невозможным, т. к. одни и те же понятия могут использоваться при построении различных диаграмм или представлений. В то же время каждое из представлений модели обладает собственными семантическими особенностями, которые накладывают отпечаток на семантику базовых понятий языка в целом.

Учитывая эти особенности, принятая в книге последовательность изучения языка UML основывается на рассмотрении основных графических средств моделирования, а именно – канонических диаграмм. Все нужные для построения диаграмм понятия вводятся по мере необходимости. Тем не менее в этой главе следует остановиться на общих особенностях языка UML, которые в той или иной степени влияют на понимание его базовых конструкций.

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Назначение книги

Назначение книги Данная книга не является заменой справочников и различных руководств по операционной системе UNIX. Более того, сведения, представленные в книге, подчас трудно найти в документации, поставляемой с операционной системой. Эти издания насыщены практическими

12.2 Назначение DNS

12.2 Назначение DNS Система имен доменов (Domain Name System — DNS) обеспечивает более эффективный способ согласования имен и адресов Интернета. База данных DNS обеспечивает автоматизированную службу преобразования имен в адреса. Эта система успешно работает, и многие организации,

15.1.1 Назначение NFS

15.1.1 Назначение NFS Компания Sun разработала сетевую файловую систему (Network File System — NFS) для поддержки разделения ресурсов служб рабочих станций Unix в локальных сетях. NFS делает удаленный каталог с файлами частью локальной структуры каталогов — конечные пользователи и

15.6.1 Назначение Portmapper

15.6.1 Назначение Portmapper Архитектура RPC предоставляет метод для динамического обнаружения присвоенного службе порта. На каждом серверном хосте специальная программа RPC работает как хранилище данных о других программах RPC этого сервера. Такая программа называется portmapper

15.7.1 Назначение rpcbind

15.7.1 Назначение rpcbind Программа rpcbind основана на тех же принципах, что и portmapper. При инициализации программы RPC ей выделяется один или несколько динамически назначенных адресов для транспорта. Программа регистрирует полученные адреса в rpcbind, через которую они становятся

22.8.1 Назначение маршрутизаторов

22.8.1 Назначение маршрутизаторов Каждый маршрутизатор предоставляет хостам следующие сведения:? Свой адрес? Список всех адресных префиксов, используемых связью? Конкретный префикс, который должен использоваться хостом для создания своего адреса? Предполагаемое

Драйвера и их назначение

Драйвера и их назначение Для того чтобы подключить оборудование к компьютеру, недостаточно просто физически подсоединить его к системному блоку. Чтобы операционная система распознала это оборудование, необходимо наличие специальной программы – драйвер. Только после

Назначение

Назначение Электронные таблицы – это программа для автоматизации расчетов, а также для структурированного представления и обработки данных, составления их баз, построения диаграмм и многого другого. Все результаты работы могут быть выведены на печать или

Назначение

Назначение материалов

Назначение материалов Чтобы сделать тонированные изображения более правдоподобными, можно придать поверхностям объектов оптические свойства различных материалов. Материалы могут быть как реальными, так и не существующими в природе; в первом случае подбирают

Назначение материалов

Назначение программы

Назначение программы Основное назначение Sound Forge 9.0 – редактирование цифрового звука. С помощью этой программы можно обрабатывать фонограммы или звуковые дорожки фильмов практически всеми существующими способами.• Первоначальная запись и оцифровка звука с различных

Назначение материалов

Унифицированный язык моделирования (UML) играет важную роль в разработке программного обеспечения, а также в системах, не связанных с ИТ, во многих отраслях, поскольку он дает возможность визуально показать поведение и структуру системы или процесса. UML помогает продемонстрировать возможные ошибки в структурах приложений, поведении системы и других бизнес-процессах.

Почему UML?

Впервые UML появился еще в 1990-х годах благодаря трем инженерам-программистам — Грэди Бучу, Ивару Джекобсону и Джеймсу — поскольку они хотели разработать менее хаотичный способ представления разработки все более сложного программного обеспечения, в то же время отделяя методологию от самого процесса. Сегодня UML по-прежнему является стандартной практической нотацией для разработчиков, а также для руководителей проектов, владельцев бизнеса, технических предпринимателей и специалистов из разных отраслей.

Каковы преимущества UML?

Упрощает сложности
Сохраняет возможности открытого общения
Автоматизирует производство программного обеспечения и процессов
Помогает решить постоянные проблемы с архитектурой
Улучшает качество работы
Сокращает затраты и время выхода на рынок

Типы диаграмм UML

Существует два основных типа диаграмм UML: структурные диаграммы и поведенческие диаграммы (а внутри этих категорий имеется много других). Эти варианты существуют для представления многочисленных типов сценариев и диаграмм, которые используют разные типы людей.

От заказчиков и руководителей проектов до технических писателей, конструкторов, аналитиков, программистов и тестеров — представители каждой роли будут использовать конкретную диаграмму в соответствии со своими потребностями. Это означает, что каждый шаблон требует различного фокуса и уровня детализации. Цель UML — визуально представить диаграммы, которые легко понять каждому.

Пример базовой диаграммы последовательности UML. Шаблон доступен длязагрузки

Давайте посмотрим внимательнее:

Структурные диаграммы

Структурные диаграммы представляют статическую структуру программного обеспечения или системы, они также показывают различные уровни абстракции и реализации. Они используются, чтобы помочь визуализировать различные структуры, составляющие систему, например, базу данных или приложение. Они показывают иерархию компонентов или модулей и то, как они связаны и взаимодействуют между собой. Эти инструменты обеспечивают руководство работы и гарантируют, что все части системы функционируют так, как задумано по отношению ко всем остальным частям.

Поведенческие диаграммы

Основное внимание здесь уделяется динамическим аспектам системы программного обеспечения или процесса. Эти диаграммы показывают функциональные возможности системы и демонстрируют, что должно происходить в моделируемой системе.

Давайте подробнее рассмотрим различные типы диаграмм UML, которые относятся к каждой категории:

1. Структурные диаграммы UML

2. Поведенческие диаграммы UML

Модели базы данных

UML также завоевывает популярность как нотация для моделирования баз данных. Эти модели являются отличным визуальным инструментом для проведения мозгового штурма, создания диаграмм в свободной форме и совместной работы над идеями.

Хотя UML не имеет спецификаций для моделирования данных, он может быть полезным инструментом для построения диаграмм, тем более что данные из баз данных могут использоваться в объектно-ориентированном программировании.

Давайте рассмотрим различные типы моделей баз данных, которые вы можете создать:

Упрощение с помощью программного обеспечения

Создаете ли вы модели баз данных или диаграммы UML, использование программных инструментов упрощает и улучшает этот процесс. Обязательно выберите инструменты, которые позволят вам:

Создавать профессиональные диаграммы с готовыми шаблонами и тысячами форм в экосистеме контента, которая соответствует отраслевым стандартам, таким как UML 2.5, а также BPMN 2.0 и IEEE.
Внедрить диаграммы с помощью наложения данных, символов, цветов и графики, чтобы упростить их интерпретацию, включая одноступенчатую визуализацию данных в Excel.
Сотрудничайте с коллегами, используя совместное редактирование, комментирование и аннотации.
Установите одну версию модели и получите доступ к диаграммам практически из любого места, используя браузер или приложение на устройстве.

При разработке программного обеспечения и непрограммируемых систем во многих отраслях использование визуальных UML-диаграмм может играть важную роль в построении поведенческих процессов и структур. Узнайте больше о создании диаграмм UML с помощью программного обеспечения при помощи пошаговой инструкции: руководства.

Сведения об авторе

Задача команды Центра роста — помочь вам начать собственный бизнес, успешно управлять им и развивать его.

Начать работу с Visio

Visio поможет превратить ваши идеи, данные и процессы в наглядные схемы, которыми вы сможете делиться с любого устройства, где бы вы ни находились.

Unified Modeling Language (UML) был разработан тремя известными сотрудниками Rational Software в начале 90-х и принят в качестве стандарта Object Management Group в 1997 году. Потребность в создании подобного языка ощущалась к тому времени довольно остро, так как программное обеспечение становилось всё сложнее. Обсуждать, описывать и продумывать его работу было всё труднее.

Понимание важности стандартных нотаций для построения моделей пришло ко мне лет 20 назад. На тот момент, еще будучи разработчиком, я искал способ донести до руководства компании предложения по улучшению бизнес-процессов. Презентовать свои идеи я решил в виде диаграмм, а поскольку на тот момент не пользовался никакими нотациями, просто изобразил всё в виде аккуратных кружочков, прямоугольников и треугольников, соединённых стрелками.

На подготовку этих диаграмм у меня ушло довольно много энергии и времени, но презентация вместо ожидаемого триумфа принесла лёгкое разочарование. Руководитель компании, просмотрев диаграммы и прослушав мою презентацию, сказал, что видит в моих предложениях рациональное зерно, но совершенно не может ухватить детали. Откровенно говоря, я списал это на счёт самого руководителя, ведь в правильности диаграмм и прорывном характере идей я был уверен. Поэтому записи свои сохранил – до лучших времен.

Когда же через несколько лет в моё поле зрения попали 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, чтобы все айтишники его знали на 100%. На мой взгляд, нужно просто использовать UML разумно и рационально в тех случаях, когда он уместен.

Неочевидные случаи: опыт применения UML в Agile-проекте

Этот случай в моей практике был уникальным, но достаточно показательным. Он произошел лет 10 тому назад, когда UML уже стал для меня привычным инструментом анализа и продумывания решений.

Работая коучем с начинающими Agile-командами, я получил от одной из команд запрос на помощь в планировании. Суть проблемы состояла в том, что коллеги разработали 130 user stories, но описали их в виде простого линейного списка. Поэтому при планировании каждого спринта им приходилось весь этот список просматривать, что c каждым разом становилось всё труднее и труднее.

Поскольку в суть проекта я глубоко не вникал, пришлось попросить команду немного рассказать о том, какая система разрабатывается и для чего. Пока коллеги рассказывали, я рисовал на доске картинки – просто чтобы не упустить ничего важного.

Как правило, в технологии Agile-разработки не находится места долгим медитациям над UML-диаграммами, поэтому коллеги сначала приняли мои художества как кощунство и приверженность устаревшим технологиям. Но всё оказалось проще.

Благодаря диаграмме вариантов использования мы выделили главных действующих лиц, затем определили основные функциональные блоки и разбили их на фичи. А потом всё это обозвали эпиками и организовали в виде дерева. После этого осталось лишь распределить все user stories по узлам этого дерева (т.е. по эпикам). И чудо свершилось – вместо громоздкого и неудобного линейного списка мы получили удобную и логичную структуру, работать с которой стало несоизмеримо проще.

Ту диаграмму вариантов использования я безжалостно с доски стёр – свою задачу она уже выполнила, сохранять её в документах проекта просто не было смысла.

Таким образом, UML нужен не только для того, чтобы нарисовать красивую диаграмму и внести её в какой-то документ или опубликовать на сайте. UML является отличным инструментом для продумывания технических проблем и обсуждения их с коллегами. Диаграммы UML позволяют увидеть картину в целом, структурировать её, найти недостающие звенья, сформулировать вопросы заказчику или разработчикам. А потом обогатить диаграммы полученными ответами.

8.1.1. Где используется UML

8.1.2. Преимущества UML

8.1.3. Строительные блоки UML

8.1.4. Правила языка UML

8.2. Диаграммы классов

Унифицированный язык моделирования (UML) является стандартным инструментом для создания "чертежей" программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем.

UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию.

UML - это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем.

Язык состоит из словаря и правил, позволяющих комбинировать входящие в него слова и получать осмысленные конструкции. В языке моделирования словарь и правила ориентированы на концептуальное и физическое представление системы. Язык моделирования, подобный UML, является стандартным средством для составления "чертежей" программного обеспечения.

Моделирование необходимо для понимания системы. При этом единственной модели никогда не бывает достаточно. Напротив, для понимания любой нетривиальной системы приходится разрабатывать большое количество взаимосвязанных моделей. В применении к программным системам это означает, что необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки

Словарь и правила такого языка, как UML, объясняют, как создавать и читать хорошо определенные модели, но ничего не сообщают о том, какие модели и в каких случаях нужно создавать. Это задача всего процесса разработки программного обеспечения. Хорошо организованный процесс должен подсказать, какие требуются артефакты, какие ресурсы необходимы для их создания, как можно использовать эти артефакты, чтобы оценить выполненную работу и управлять проектом в целом.

[Буч. Г., Рамбо Д., Джекобсон А. Язык UML/ Руководство пользователя: пер.с англ. - М.: ДМК, 2000 - 432 с.: ил.]

UML - это язык визуализации.

Написание моделей на UML преследует одну простую цель — облегчение процесса передачи информации о системе: явная модель облегчает общение.

Некоторые особенности системы лучше всего моделировать в виде текста, другие - графически. На самом деле во всех интересных системах существуют структуры, которые невозможно представить с помощью одного лишь языка программирования. UML - графический язык, что позволяет решить вторую из обозначенных проблем.

UML - это не просто набор графических символов. За каждым из них стоит хорошо определенная семантика. Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим - или даже инструментальной программой.

UML - это язык специфицирования

В данном контексте специфицирование означает построение точных, недвусмысленных и полных моделей. UML позволяет специфицировать все существенные решения, касающиеся анализа, проектирования и реализации, которые должны приниматься в процессе разработки и развертывания системы программного обеспечения.

UML - это язык конструирования

UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.

Такое отображение модели на язык программирования позволяет осуществлять прямое проектирование: генерацию кода из модели UML в какой-то конкретный язык. Можно решить и обратную задачу: реконструировать модель по имеющейся реализации. Обратное проектирование не представляет собой ничего необычного. Если вы не закодировали информацию в реализации, то эта информация теряется при прямом переходе от моделей к коду. Поэтому для обратного проектирования необходимы как инструментальные средства, так и вмешательство человека. Сочетание прямой генерации кода и обратного проектирования позволяет работать как в графическом, так и в текстовом представлении, если инструментальные программы обеспечивают согласованность между обоими представлениями.

Помимо прямого отображения в языки программирования UML в силу своей выразительности и однозначности позволяет непосредственно исполнять модели, имитировать поведение систем и контролировать действующие системы.

UML - это язык документирования

Компания, выпускающая программные средства, помимо исполняемого кода производит и другие артефакты, в том числе следующие:

требования к системе;
архитектуру;
проект;
исходный код;
проектные планы;
тесты;
прототипы;
версии, и др.

В зависимости от принятой методики разработки выполнение одних работ производится более формально, чем других.

Упомянутые артефакты - это не просто поставляемые составные части проекта; они необходимы для управления, для оценки результата, а также в качестве средства общения между членами коллектива во время разработки системы и после ее развертывания.

UML позволяет решить проблему документирования системной архитектуры и всех ее деталей, предлагает язык для формулирования требований к системе и определения тестов.

[Змитрович А. И, Интеллектуальные информационные системы. – Мн.: НТООО "ТетраСистемс", 2007.]

8.1.1. Где используется UML

Язык UML предназначен прежде всего для разработки программных систем. Его использование особенно эффективно в следующих областях:

информационные системы масштаба предприятия;
банковские и финансовые услуги;
телекоммуникации;
транспорт;
оборонная промышленность, авиация и космонавтика;
розничная торговля;
медицинская электроника;
наука;
распределенные Web-системы.

[ Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose учеб. пособие [для вузов] А. В. Леоненков - М. Интернет Ун-т Информ. Технологий: БИНОМ. Лаб. знаний 2006 - 320 с. ил. ]

8.1.2. Преимущества UML

UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;

UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;

UML получил широкое распространение и динамично развивается.

[Анализ и проектирование информационных систем с помощью UML 2.0 [пер. с англ.] Лешек А. Мацяшек - 3-е изд. - М. Вильямс 2008 - 816 с. ил.]

8.1.3. Строительные блоки UML

Словарь языка UML включает три вида строительных блоков:

сущности;
отношения;
диаграммы.

Сущности - это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей.

Обобщение (Generalization) - это отношение "специализация/обобщение", при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка).

Рис. 8.1. Обобщения

Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями. Отношение реализации изображается в виде пунктирной линии с незакрашенной стрелкой, как нечто среднее между отношениями обобщения и зависимости (см. рис.8.2).

Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма - в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый распространенный вариант), или не присутствовать ни в одной (очень редко). Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы (см. следующий раздел).

Рис. 8.2. Реализации

Таким образом, в UML выделяют девять типов диаграмм:

диаграммы классов;
диаграммы объектов;
диаграммы прецедентов;
диаграммы последовательностей;
диаграммы кооперации;
диаграммы состояний;
диаграммы действий;
диаграммы компонентов;
диаграммы развертывания.

[Буч. Г., Рамбо Д., Джекобсон А. Язык UML/ Руководство пользователя: пер.с англ. - М.: ДМК, 2000 - 432 с.: ил.]

8.1.4. Правила языка UML

Строительные блоки UML нельзя произвольно объединять друг с другом. Как и любой другой язык, UML характеризуется набором правил, определяющих, как должна выглядеть хорошо оформленная модель, то есть семантически самосогласованная и находящаяся в гармонии со всеми моделями, которые с нею связаны.

В языке UML имеются семантические правила, позволяющие корректно и однозначно определять:

имена, которые можно давать сущностям, отношениям и диаграммам;
область действия (контекст, в котором имя имеет некоторое значение);
видимость (когда имена видимы и могут использоваться другими элементами);
целостность (как элементы должны правильно и согласованно соотноситься друг с другом);
выполнение (что значит выполнить или имитировать некоторую динамическую модель).

Модели, создаваемые в процессе разработки программных систем, эволюционируют со временем и могут неоднозначно рассматриваться разными участниками проекта в разное время. По этой причине создаются не только хорошо оформленные модели, но и такие, которые:

содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие);
неполные (отдельные элементы пропущены);
несогласованные (целостность модели не гарантируется).

8.2. Диаграммы классов

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы.

Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Поэтому диаграмму классов принято считать графическим представленном таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рис.8.3). В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).

Рис.8.3. Графическое изображение класса на диаграмме классов

Обязательным элементов обозначения класса является его имя. На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником с указанием только имени соответствующего класса (рис.8.3, а). По мере проработки отдельных компонентов диаграммы описания классов дополняются атрибутами (рис.8.3, б) и операциями (рис.8.3, в).

Предполагается, что окончательный вариант диаграммы содержит наиболее полное описание классов, которые состоят из трех разделов или секций.

Даже если секция атрибутов и операций является пустой, в обозначении класса она выделяется горизонтальной линией, чтобы сразу отличить класс от других элементов языка UML. Примеры графического изображения классов на диаграмме классов приведены на рис.8.4. В первом случае для класса "Прямоугольник" (рис.8.4, а) указаны только его атрибуты - точки на координатной плоскости, которые определяют его расположение. Для класса "Окно" (рис.8.4, б) указаны только его операции, секция атрибутов оставлена пустой. Для класса "Счет" (рис.8.4, в) дополнительно изображена четвертая секция, в которой указано исключение - отказ от обработки просроченной кредитной карточки.

Рис. 8.4. Примеры графического изображения классов на диаграмме

Таким образом, язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. Этот язык вобрал в себя наилучшие качества методов программной инженерии, которые с успехом использовались на протяжении последних лет при моделировании больших и сложных систем.

Лучше один раз увидеть, чем сто раз услышать. Именно этим принципом руководствовались создатели унифицированного языка моделирования (UML), который был задуман с целью стать единым наглядным языком в сложном мире разработки программного обеспечения и доступно передавать информацию представителям бизнес-среды и всем тем, кто хочет вникнуть в устройство той или иной системы. Приглашаем вас освоить азы составления диаграмм UML, а также познакомиться с их истоками, понятийной базой, разновидностями и правилами построения при помощи инструментов нашей платформы.

Читается за 18 мин.

Хотите создать собственную диаграмму UML? Попробуйте Lucidchart! Быстро, удобно и совершенно бесплатно.

Что такое UML?

Унифицированный язык моделирования (UML) был разработан с целью обеспечить единый визуальный язык с богатой семантикой и развернутым синтаксисом для проектирования и внедрения программных систем со сложной структурой и комплексным поведением. Стоит отметить, что UML применяется не только в разработке программ, но и в других сферах, например, в схематизации потоков производственных процессов.

UML напоминает стандарты, используемые в других отраслях, и поддерживает диаграммы нескольких типов. В целом, диаграммы UML описывают границы, структуру и поведение как всей системы, так и отдельных объектов в ее составе.

UML не является языком программирования, однако на базе диаграмм UML можно сгенерировать код на разных языках, и для этого существует ряд специальных инструментов. Зато с объектно-ориентированным анализом и дизайном унифицированный язык моделирования связан напрямую.

UML и его роль в объектно-ориентированном анализе и дизайне

В информатике, науке об алгоритмах и данных, существует множество парадигм и моделей решения задач. Выделяется четыре категории таких моделей — императивные, функциональные, декларативные и объектно-ориентированные. Объектно-ориентированные языки представляют алгоритмы посредством определения объектов и их взаимодействия друг с другом. Объекты существуют в реальном мире и подвергаются тем или иным действиям. Объектами могут быть здания, виджеты рабочего стола и даже люди.

Объектно-ориентированные языки преобладают в сфере программирования, так как моделируют объекты реального мира. UML сочетает в себе несколько разновидностей объектно-ориентированной нотации — объектно-ориентированный дизайн, технику объектного моделирования и разработку объектно-ориентированного программного обеспечения.

Объединяя в себе сильные стороны всех трех подходов, UML обеспечивает своим пользователям удобную и последовательную методологию и представляет собой набор эффективных методов схематизации и документирования различных аспектов моделирования программ и бизнес-систем.

Истоки возникновения UML

OMG: новое значение знакомой аббревиатуры

OMG контролирует постоянство определений и параметров UML, давая программистам и разработчикам возможность применять единый язык в разных целях на всех этапах жизненного цикла программного обеспечения независимо от масштабов системы.

Цель существования UML согласно OMG

OMG определяет цель UML так:

предоставить системным архитекторам, программистам и разработчикам инструменты для анализа, проектирования и внедрения программных систем, а также моделирования бизнес- и других процессов;
способствовать развитию отрасли благодаря широкой совместимости инструментов наглядного моделирования (но стоит отметить, что для осмысленного обмена информацией о моделях, созданных с помощью разных инструментов, необходима согласованность семантики и нотации).

UML выполняет следующие функции:

UML и моделирование данных

Язык UML получил широкое распространение в среде программистов, однако в целом мало используется в разработке баз данных. Одна из причин этого заключается в том, что создатели UML не ставили базы данных в центр внимания. Тем не менее, UML эффективно применяется в концептуальном моделировании данных высоких уровней и подходит для создания различных видов диаграмм UML. Более подробно о том, как при помощи слоев преобразовать объектно-ориентированную модель в схему реляционной базы данных, можно узнать в нашей статье по моделированию баз данных с помощью UML.

Создание диаграмм быстро и легко с Lucidchart. Начните бесплатную пробную версию сегодня, чтобы начать создавать и сотрудничать.

Что нового в UML 2.0

Язык UML не перестает совершенствоваться. Стандарт UML 2.0 расширяет границы UML, охватывая новые аспекты разработки, в том числе в гибкой среде. Новый стандарт был введен с целью реструктурировать, усовершенствовать и упростить UML для удобства использования, внедрения и адаптации. Вот несколько примеров того, как изменились диаграммы UML:

более тесная интеграция между структурными и поведенческими моделями;
возможность задавать иерархию и разбивать структуру программ на компоненты и подкомпоненты;
повышение количества схем в UML 2.0 с 9 до 13.

Глоссарий терминов UML

Предлагаем вам ознакомиться с терминологией UML. Для этого здесь приведен список распространенных терминов из документа UML 2.4.1, предназначенного для тех, кто не входит в OMG.

Просмотреть полный документ по метаобъектным средствам (MOF)

Концепции моделирования в рамках UML

В целом, в разработке систем выделяется три основных системных модели:

Функциональная — схемы сценариев использования, описывающие функционал системы с точки зрения ее пользователя.
Объектная — диаграммы классов, описывающие структуру системы при помощи объектов, атрибутов, связей и операций.
Динамическая — диаграммы взаимодействия, состояний и активности, применяемые для описания внутренней работы системы.

Наглядное представление этих системных моделей осуществляется с помощью схем двух разных типов — структурных и поведенческих.

Объектно-ориентированные концепции в UML

Объекты в UML — это упрощенное представление предметов окружающего нас мира. В разработке программного обеспечения объекты используются для описания (или моделирования) создаваемой системы с применением терминологии соответствующей сферы. Объекты также позволяют разбить сложные системы на понятные составляющие и выстроить схему блок за блоком.

Ниже приведены некоторые фундаментальные концепции объектно-ориентированной методологии:

Объекты — сущности и простейшие строительные элементы схемы.
Класс — прообраз объекта.
Абстракция — поведение объекта реального мира.
Инкапсуляция — механизм, позволяющий объединить данные и скрыть их от внешнего мира.
Наследование — механизм создания новых классов на основе уже имеющихся.
Полиморфизм — механизм, позволяющий объектам существовать в разных формах.

Разновидности диаграмм UML

UML опирается на набор объектов, соединяемых между собой различными способами с целью создания схем, отражающих статичные (или структурные) либо динамические (поведенческие) аспекты системы.

Структурные диаграммы UML

Диаграммы классов — наиболее распространенная разновидность диаграмм UML и фундаментальная база любого объектно-ориентированного решения. Отображают классы внутри системы, а также атрибуты, операции и отношения между классами. Диаграммы классов применяются при схематизации крупных систем, так как позволяют объединять классы в группы.
Диаграммы компонентовотражают структурные отношения между элементами программной системы и чаще всего применяются при работе с комплексными структурами, состоящими из множества компонентов. Взаимодействие между компонентами осуществляется посредством интерфейсов.
Диаграммы композитной структуры применяются для схематизации внутренней структуры класса.
Диаграммы развертывания иллюстрируют аппаратное и программное обеспечение системы. Удобны в тех случаях, когда программный продукт применяется на нескольких компьютерах с индивидуальными настройками.
Диаграммы объектов отражают отношения между объектами посредством примеров из реального мира и показывают, как система будет выглядеть в заданный момент времени. Данные, содержащиеся в объектах, могут использоваться для характеризации связей между ними.
Диаграммы пакетов. Между пакетами выделяется два особых вида зависимости — импортирование и слияние. Пакеты могут символизировать разные уровни системы, позволяя воссоздать ее архитектуру. Чтобы показать механизм взаимодействия между уровнями, на схеме также можно отметить зависимость между пакетами.

Поведенческие диаграммы UML

Как создать диаграмму UML: уроки и примеры

Чтобы научиться создавать разные виды диаграмм UML, рекомендуем вам пройти один или все наши уроки по построению структурных и поведенческих схем.

Уроки по созданию структурных схем

Диаграммы классов иллюстрируют статичные структуры внутри системы, включая классы, атрибуты, операции и объекты. В их состав могут входить как концептуальные, так и организационные данные в форме классов реализации и логических классов, соответственно. Стоит отметить, что данные две группы могут пересекаться.

Классы отображаются с помощью прямоугольных блоков, разбитых на три части. В верхней части помещается наименование класса, в средней — его атрибуты, а в нижней — операции класса (которые также называют методами).
Чтобы смоделировать отношения между объектами, поместите на свою диаграмму фигуры для обозначения классов. Возможно, вам также пригодятся подклассы.
Используйте соединительные линии, чтобы показать связь, наследование, множественность и другие виды отношений между классами и подклассами. Выбор правильных линий будет зависеть от вашего предпочитаемого стиля нотации.

Для изображения компонента на схеме используйте прямоугольный блок. Сбоку на нем должно располагаться два небольших прямоугольника (иногда они присутствуют прямо на значке фигуры).
Для обозначения связей используйте соединительные линии.

Диаграмма развертывания моделирует физическое развертывание и структуру аппаратных компонентов. Диаграммы этого типа демонстрируют, где и как компоненты системы будут работать друг с другом.

Уроки по созданию поведенческих схем

Диаграммы активности показывают движение процедурного потока подчиненных объектов класса в сочетании с организационными процессами, например, рабочими потоками компании. Такие диаграммы составляются из специального набора фигур, соединяемых стрелками. Нотационный набор диаграмм активности похож на набор для диаграмм состояний.

Поместите в начало диаграммы круг с заливкой.
Соедините круг с первым действием, для обозначения которого применяется прямоугольник со скругленными углами.
Теперь соедините действия между собой при помощи линий, символизирующих пошаговую последовательность всего процесса.
Также попробуйте воспользоваться разделительными дорожками, чтобы разграничить объекты, задействованные в выполнении каждого действия.

СХЕМЫ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ

Сценарий использования представляет собой список шагов, характеризующих взаимодействие между агентом (человеком или внешней системой) и самой системой. Схемы сценариев использования отображают их характеристики, а также моделируют функциональные единицы системы. Схематизация помогает разработчикам лучше вникнуть в требования системы, включая роль ее взаимодействия с человеком, а также выявить различия между сценариями использования. В схеме могут отображаться как все сценарии использования, так и их отдельные группы с похожим набором функций.

Начните построение схемы с добавления овала в центр холста.
Внутрь овала поместите название сценария использования.
По краям схемы поставьте фигурки человечков (они символизируют агентов), а затем проведите линии, показывающие отношения между агентами и сценариями.

Lucidchart заметно упрощает работу по созданию диаграмм UML

Начните создавать собственные диаграммы UML в Lucidchart уже сегодня! С нами строить схемы просто, эффективно и даже занимательно.

Удобный интерфейс. Если вы взялись за создание диаграммы UML, вы, безусловно, знаете, что делать, однако мы решили дополнительно упростить вам работу. Отполированный интерфейс и интуитивный редактор Lucidchart сэкономят вам драгоценные минуты.
Богатая библиотека фигур. С нами вы сможете составлять диаграммы состояний, активности и сценариев использования, как настоящий профессионал. В нашей обширной библиотеке фигур и соединительных линий вы найдете всё, что нужно для схем.
Максимальная интеграция. Платформа Lucidchart полностью интегрирована с G Suite. Начав работу в Lucidchart, вы найдете наш сервис прямо в наборе Google для продуктивной работы по соседству с Gmail и Google Drive. Кроме того, для входа на Lucidchart можно использовать учетные данные Google.
Возможность совместной работы. Созданной диаграммой UML можно с легкостью поделиться с коллегами, клиентами или начальством. Lucidchart позволяет встраивать диаграммы на веб-страницы, публиковать в формате PDF или использовать в качестве сопроводительных наглядных материалов с помощью режима презентации.
Импорт/экспорт из Visio. Чтобы ваша работа в Visio не пропадала зря, предлагаем вам возможность свободно импортировать и экспортировать свои файлы. Это займет совсем немного времени и не составит труда.

Дополнительные ресурсы

Хотите создать собственную диаграмму UML? Попробуйте Lucidchart! Быстро, удобно и совершенно бесплатно.

Читайте также: