Uml&enterprise architect: проектируем целевой процесс при создании автоматизированной системы

Построение UML диаграмм онлайн с помощью Lucidchart

В открывшемся окне выберите пункт Документы. В следующем окне необходимо нажать на кнопку в левой верхней части  + СОЗДАТЬ , а в выпадающем меню пункт  Документ Lucidchart.

Если Вы используете бесплатную версию, то может появиться окно, в котором надо нажать кнопку  Все равно создать. Может появиться форма, показанная на рисунке.

В ней надо выбрать Все равно создать документ.

В следующей форме, показанной на рисунке, если она появилась

 надо выбрать Начать пробный период, а в следующей форме выбрать кнопку Потом.

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

В этом списке надо выбрать UML и нажать кнопку Использовать выбранные фигуры.

После этого методика построения UML- диаграммы ничем не отличается от методики построения BPMN – диаграммы, описанная в статье “Программы создания диаграмм BPMN ”

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

Виды диаграмм на UML и средства для их построения

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

Хорошо известно, что в процессе проектирования информационных систем широкое применение нашел  способ организации и управления архитектурой проектируемой системы Model Driven Architecture (MDA). Этот подход поддерживается современными автоматизированными инструментальными средствами разработки информационных систем для определения моделей, а также для облегчения преобразований между различными типами моделей. Для построения моделей в рамках MDA широко используется построение диаграмм на унифицированном языке моделирования UML.

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

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

Поэтому для построения моделей проектируемых информационных систем в рамках курсового и дипломного проектирования применяются следующие  основные диаграммы на языке UML:

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

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

Построение UML диаграмм можно выполнять вручную на листе бумаги или на доске, а также с помощью специализированного программного обеспечения. Среди достаточно большого количества средств построения диаграмм на UML можно выделить два класса. Первый класс – простые и дешевые(иногда бесплатные) программы, позволяющие автоматизировать построения диаграммы без генерации программного кода. К таким программам относятся графический редактор MS Visio,  StarUML

Второй класс это, так называемые CASE-средства, представляющие собой набор инструментов, предназначенный для автоматизации визуального моделирования, проектирования, документирования и генерации кода реализации на выбранном алгоритмическом языке. К таким средствам относятся CASE-средства визуального моделирования и проектирования  компании IBM Rational Software Corp — Rational Rose и Rational Software Architect, продукт проектирования и интеграции компании Borland – Together и другие.

CASE-средство визуального моделирования  Rational Rose является хорошим и достаточно доступным инструментом создания артефактов проектирования информационных систем. В предыдущих статьях мы рассматривали его применение в курсовом и дипломном проектировании в процессе:

• выполнения предпроектного обследования предметной области,
• технического(архитектурного) проектирования и
• рабочего проектирования  информационной системы.

Плагины к IDE

Visual Paradigm SDE for Visual Studio

Тип: бесплатное ПО (Community Edition)

Сайт: https://www.visual-paradigm.com/product/sde/vs/editions/community.jsp

Возможности:

Use Case modelingSystem analysis and designPlug-in architecture

Скриншоты:

tangible T4 Editor plus UML modeling Tools for Visual Studio (2008/2010)

Тип: бесплатное ПО

Сайт: http://t4-editor.tangible-engineering.com/T4-Editor-Visual-T4-Editing.html

tangible T4 Editor поставляется вместе с инструментами UMLи позволяет генерировать диаграммы, схемы базы данных на базе xml, word, excel и других источников данных.

Скриншоты:

NetBeans IDE UML

Сайт: http://netbeans.org/features/uml/

UML плагин к NetBeans IDE:

• импорт NetBeans UML проектов
• возможность командной работы
• кодогенерация для Java, C++, PHP

Скриншоты:

Eclipse UML2 Tools

Сайт: http://www.eclipse.org/modeling/mdt/?project=uml2tools

Возможности:

• Structure diagrams
  • Class
  • Profile definition
  • Composite structures
  • Component
  • Deployment
• Behavior diagrams
  • Activity
  • State machine
  • Use Case
• Interaction diagrams
  • Sequence
  • Timing

Сайт: http://www.websequencediagrams.com/

Создание простых диаграмм:

yUML

Сайт: http://yuml.me/diagram/scruffy/class/draw

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

zOOml

Сайт: http://www.zooml.com/

В статье использовались материалы DevCurry.

Спасибо за внимание!

• Power Designer
• TopCoder UML Tool
• OmniGraffle для Mac OS X
• Artisan Studio Uno
• Altova UModel
• Sparx Enterprise Architect
• Visual Paradigm
• Poseidon for UML
• Umbrello UML Modeller
• Software Ideas Modeler
• Gliffy

3.5. Диаграммы состояний. (State diagram или State Machine)

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

Название Состояния является его описанием, т.е., например, состояние

означает, что пользователь находится в «незалогиненном» состоянии.

Переход (Transition) – элемент, отображающий путь перехода из одного состояния в другое.
Например:

Для обозначения начала и конца всего процесса переходов используются псевдо-состояния: Инициирующее (Initial)

иФинализирующее (Final)

Применятся они могут, например, так:

Если Состояние сопряжено с некоторой деятельностью, то это тоже отображается на диаграмме.

Например:

Если из одного Состояния возможно несколько переходов в несколько других различных состояний, то это тоже отображается на диаграмме. Как правило, в этом случае переходы именуются по своему смыслу. Например, по результатам деятельности.
Например:

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

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

Кроме обычных Состояний (State) существуют также Суперсостяния (StateMachine), которые могут включать в себя другие состояния и переходы.
При этом контекст Суперсостояния является актуальным для всех элементов, находящихся внутри этого Суперсостояния.
Например:

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

На одной диаграмме состояний может быть отображено несколько одновременных состояний одного и того же объекта, если эти состояния изменяются параллельно друг другу.
Например (из книги Фаулера):

Если несколько параллельных потоков переходов должны быть синхронизироваться в какой-то момент, то для это используется псевдо-состояние Synch

Существует также дополнительный элемент Fork/Join – используется для разбивки или объединения нескольких потоков состояний.
Например:

Замечания (описание)

Здесь представлен основной набор символов диаграммы деятельности, необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы деятельности самостоятельно!

Термин	Изображение	Описание
Начальный узел		Старт диаграммы
Ветвление		Ветвление (fork), имеет один входной поток и несколько выходных параллельных потоков.
Операция		См. раздел «Пример»
Поток / ребро		В UML 2 параллельно употребляются термины поток (flow) и ребро (edge) для обозначения связи между двумя операциями. Самый про стой вид ребра – это обычная стрелка между двумя операциями.
Решение		Каждый раз при достиже нии решения выбирается только один из выходных потоков, поэтому защиты должны быть взаимно исключающими.
Слияние		Слияние обозначает завершение условного поведения, которое было начато решением.
Объединение		При наличии параллелизма необходима синхронизация. Мы не закры ваем заказ, пока он не оплачен и не доставлен. Это показывается с по мощью объединения
Конец деятельности		Окончание диаграммы
Имя деятельности
Входной параметр
Выходной параметр
«Грабли»		Операции могут быть реализованы или как вложенные деятельности или как методы классов. Вложенную деятельность можно обозначить с помощью символа «граблей».
Вызов метода
Временной сигнал		Временной сигнал (time signal) приходит по прошествии времени. Та кие сигналы могут означать конец месяца в отчетном периоде или приходить каждую секунду в контроллере реального времени.
Принятие сигнала
Посылка сигнала
Прием сигнала
Разъем
Узел объекта
Контакт		Процедуры, как и методы, могут иметь параметры. Показывать на диа грамме деятельности информацию о параметрах не обязательно, но при желании можно отобразить параметры с помощью контактов (pins)
Выражение преобразования		Если требуется нарисовать точную диаграмму деятельности, то необходимо обеспечить соответствие выходных параметров одной процедуры входным параметрам другой. Если они не совпадают, то можно указать преобразование (transformation) (рис. 11.8) для перехода от од ной процедуры к другой.
Ключевое слово
Выходной список контактов
Область расширения		Область расширения (expansion region) отмечает область диаграммы деятельности, где операции выполняются один раз для каждого элемента коллекции.
Окончание потока		Окончание потока (flow final) означает завершение конкретного потока без завершения всей активности.
Описание объединения		Описание объединения (join specification) – это логическое выражение, присоединенное к объединению.

КАК РАЗРАБАТЫВАТЬ ДИАГРАММЫ BPMN НА ПРАКТИКЕ?

1. Необходимо запланировать начало и конец процесса. С этого начинается моделирование любого процесса. Так мы обозначаем рамки, в которых будем работать.
2. Для начала лучше всего описать линейную последовательность действий: шаг за шагом движение от начала к финальному результату. Далее при необходимости добавляются ветвления. В таком порядке работать намного проще, чем ставить две или более ветвей одновременно и путаться в стрелках, что откуда и куда идет.
3. Пришло время определить ответственных лиц. До этого мы работали с событиями «в чистом виде». Теперь у них появились исполнители и ответственные.
4. Добавляем данные, сноски, комментарии.

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

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

Для названий процессов лучше всего подойдут либо термины, принятые в конкретной организации для описания работы, либо – просто понятные интуитивно фразы.
Зоны ответственности также важно называть понятно для сотрудников компании, бизнес-модель работы которой вы описываете. Самое простое решение – выбирать названия среди существующих подразделений. А если необходимой должности или отдела в компании пока еще не существует, не бойтесь придумывать его сами. Но постарайтесь, чтобы название также было «говорящим», понятным для широкого круга бизнес-аудитории.
Подпроцессов должно быть столько, чтобы избежать ненужной детализации, но не более того. Помните о чувстве меры. Если подпроцессов будет слишком мало, то действия, которые стоило бы спрятать в них, будут находиться в общем процессе, создавая дополнительные объекты, стрелки, ветвления и, как следствие, путаницу. Если вы перестараетесь с желанием убрать все в подпроцессы, то диаграмма потеряет свою информативность, а какие-то изменения в подпроцессе начнут ненаглядно влиять на результаты всего процесса.
Не бойтесь ошибаться! Если вы ошибетесь в исполняемой методологии, это очень быстро выяснится в процессе исполнения (отладки) процесса. Если вы создаете просто наглядную схему, то мелкие ошибки не столь важны, главное, чтобы эта схема помогла вам и людям, для которых вы ее делаете (заказчики, технические специалисты), понять все нюансы вашей идеи. И в любом случае, на ошибках учатся, а исправления внести в бизнес-модель можно быстро и просто.

• Что такое бизнес-процесс и описание бизнес процесса
• Моделирование бизнеса. Основные подходы
• Знакомство с нотацией IDEF0 и пример использования
• Разбираемся с понятием BPM. Что такое управление бизнес процессами
• Что такое BPMS
• Использование GAP-анализа для выявления и согласования задач по проекту

ссылке

Контакты и преобразования

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

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

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

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

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

Отношения между классами

Существует четыре типа связей в UML:

• Зависимость
• Ассоциация
• Обобщение
• Реализация

Эти связи представляют собой базовые строительные блоки для описания отношений в UML, используемые для разработки хорошо согласованных моделей.
Первая из них – зависимость – семантически представляет собой связь между двумя элементами модели, в которой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графически представлена пунктирной линией, иногда со стрелкой, направленной к той сущности, от которой зависит еще одна; может быть снабжена меткой. 
Зависимость – это связь использования, указывающая, что изменение спецификаций одной сущности может повлиять на другие сущности, которые используют ее. Ассоциация – это структурная связь между элементами модели, которая описывает набор связей, существующих между объектами.
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в». В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации.

История

История объектно-ориентированных методов и обозначений

До UML 1.0

UML развивается со второй половины 1990-х годов и уходит своими корнями в методы объектно-ориентированного программирования, разработанные в конце 1980-х — начале 1990-х годов. Временная шкала (см. Изображение) показывает основные моменты истории объектно-ориентированных методов моделирования и обозначений.

Он изначально основаны на обозначениях в методе Буча , то объект-моделирования техника (ОМТ) и объектно-ориентированного программного обеспечения инженерно (OOSE), который он интегрирован в единый язык.

Rational Software Corporation наняла Джеймса Рамбо из General Electric в 1994 году, и после этого компания стала источником двух самых популярных подходов к объектно-ориентированному моделированию того времени: метод объектного моделирования Рамбо (OMT) и метод Грэди Буча . Вскоре в их усилиях им помог Ивар Якобсон , создатель метода объектно-ориентированной разработки программного обеспечения (OOSE), который присоединился к ним в Rational в 1995 году.

UML 1.x

Под техническим руководством этих троих (Рамбо, Якобсон и Буч) в 1996 году был организован консорциум под названием UML Partners, чтобы завершить спецификацию унифицированного языка моделирования (UML) и предложить ее Группе управления объектами (OMG) для стандартизации. Партнерство также включало дополнительные заинтересованные стороны (например, HP , DEC , IBM и Microsoft ). Проект UML 1.0 UML Partners был предложен OMG консорциумом в январе 1997 года. В том же месяце партнеры UML сформировали группу, разработанную для определения точного значения языковых конструкций, под председательством Криса Кобрина и под управлением Эда Эйкхолта, чтобы завершить спецификацию и интегрировать ее с другими усилиями по стандартизации. Результат этой работы, UML 1.1, был представлен OMG в августе 1997 года и принят OMG в ноябре 1997 года.

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

Разработанные стандарты (а также исходный стандарт) были отмечены как неоднозначные и непоследовательные.

Обозначение мощности

Как и базы данных Чен, Бахман и ISO ER диаграмма , модель класса указаны использовать «Двойник через» кардинальности , даже если несколько авторов ( Merise , Elmasri и Navathe среди других) предпочитает же сторону или «Двойник здесь» для ролей и минимальная, и максимальная мощности. Недавние исследователи (Feinerer, Dullea et al.) Показали, что метод «просмотра», используемый в UML- и ER-диаграммах, менее эффективен и менее согласован при применении к n- мерным отношениям порядка строго больше 2.

Файнерер говорит: «Проблемы возникают, если мы работаем в рамках семантики просмотра, используемой для ассоциаций UML. Хартманн исследует эту ситуацию и показывает, как и почему различные преобразования терпят неудачу», и: «Как мы увидим на следующих нескольких страницах, сквозная интерпретация привносит ряд трудностей, которые препятствуют расширению простых механизмов с бинарных на n- мерные ассоциации ».

UML 2

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

Хотя UML 2.1 никогда не выпускался в качестве формальной спецификации, версии 2.1.1 и 2.1.2 появились в 2007 году, а затем в феврале 2009 года появился UML 2.2. UML 2.3 был официально выпущен в мае 2010 года. UML 2.4.1 был официально выпущен в августе 2011 года. . UML 2.5 был выпущен в октябре 2012 года как «Выполняемая» версия и официально выпущен в июне 2015 года. Официальная версия 2.5.1 была принята в декабре 2017 года.

Спецификация UML 2.x состоит из четырех частей:

• Надстройка, определяющая обозначения и семантику для диаграмм и их элементов модели.
• Инфраструктура, которая определяет базовую метамодель, на которой основана надстройка.
• Язык объектных ограничений (OCL) для определения правил для элементов модели
• Обмен диаграммами UML, который определяет, как обмениваются макеты диаграмм UML 2.

До UML 2.4.1 последними версиями этих стандартов были:

• Надстройка UML версии 2.4.1
• Инфраструктура UML версии 2.4.1
• OCL версии 2.3.1
• UML Diagram Interchange версии 1.0.

Начиная с версии 2.5, спецификация UML была упрощена (без надстройки и инфраструктуры), и теперь последние версии этих стандартов:

• Спецификация UML 2.5.1
• OCL версии 2.4

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

Сравнение двух подходов структурирования диаграммы Activity (по мотивам «Белки»)

В 1-ой части статьи «От моделирования процессов к проектированию автоматизированной системы» мы моделировали процессы «сказочной» предметной области — строчки про белку из «Сказки о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди» А.С.Пушкина. И начали мы с диаграммы Activity, договорившись о структурировании поля диаграммы с помощью «плавательных» дорожек – Swim lanes. Имя дорожки соответствует типу элементов диаграммы, которые присутствуют на этой дорожке: «Входные и выходные артефакты», «Шаги процесса», «Участники» и «Бизнес-правила». Этот подход отличается от стандартного, когда дорожки обозначаются именами участников процесса, таким образом закрепляя за ними определенные зоны ответственности в процессе.

В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems .

Подробнее о применяемых подходах к моделированию см. .

Полную спецификацию UML см. здесь .

Повторю вариант диаграммы из прошлой статьи (Рисунок 1) и покажу перерисованную диаграмму со «стандартными» дорожками (Рисунок 2), постараюсь плюсы и минусы обозначить, может быть, и немного субъективно.

Рисунок 1. Диаграмма Activity – общий вид процесса

Рисунок 2. Диаграмма Activity – стандартное структурирование диаграммы

1. Нужно признать, что количество стрелок чуть меньше на 2-ой диаграмме.
2. Но на 2-ой диаграмме объекты «размазаны» по всему полю диаграммы, что, на мой вкус, не очень удобно.
3. Та же история с примечаниями — правилами. А еще чтобы правило про назначение дьякона вставить, пришлось все элементы диаграммы в какой-то момент двигать вниз.
4. Пришлось клонировать шаг «приема/передачи…», чтобы показать, что несколько участников на этом шаге присутствуют.
5. Во втором варианте пришлось отказаться от одного ветвления и одного слияния процесса, ну совершенно не получалось их «красиво» уложить! По хорошему, нужно было бы тогда повесить комментарий — правило.

На вкус и цвет, конечно, товарищей нет, но мне первый вариант кажется еще и более удобным для сбора данных о процессе.

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

Дополнение. Благодарю за комментарии и привожу немного видоизмененную диаграмму 2-го варианта: можно переставить дорожки (на Рисунке 2 их очередность повторяет очередность появления участников в повествовании), количество пересекающихся стрелок еще немного уменьшится (Рисунок 3).

Рисунок 3. Диаграмма Activity – стандартное структурирование диаграммы — переставлены дорожки

Статьи, по мотивам которых, появилась эта статья:От моделирования процессов к проектированию автоматизированной системы (Часть 1)От моделирования процессов к проектированию автоматизированной системы (Часть 2)

Построение UML диаграмм в MS Visio

Наиболее доступным, а поэтому и популярным средством построения не только  BPMN – диаграмм, но и диаграмм на языке UML является  графический редактор MS Visio.  Доступность MS Visio обеспечило практически свободное владение им большого количества специалистов в том числе и студентов.

Методика построения диаграмм на языке UML  в MS Visio во многом схожа с методикой построения BPMN – диаграмм. Отличием является то, что необходимо адаптировать графическую нотацию под набор элементов UML, выбрав шаблон “Схема модели UML”. После нажатия кнопки “Создать” появится окно с наборами элементов(фигурами, пиктограммами), которые соответствуют  шаблону (stencils): схеме модели UML.

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

Заключение и список литературы

В статье я постарался описать наиболее существенные элементы диаграммы классов, а также аспекты их применения. Просматривается, что диаграмма строится на начальном этапе проектирования (концептуальная модель) и является его результатом. На всех этапах проектирования созданная в начале диаграмма классов дорабатывается, т.е. я рассматриваю итеративный процесс (такой как RUP или ICONIX). Кроме того, показано, использование диаграммы классов в других целях — эскизирования, документирования, моделирования логической схемы БД. На других страницах этого блога вы можете найти множество примеров использования диаграммы классов.

• диаграмма шаблона проектирования Publish-Subscriber ;
• множество диаграмм, демонстрирующих шаги рефакторинга для приведения проекта в соответствие принципам SOLID ;
• диаграммы классов для паттерна адаптер и сетевого чата .
• Буч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. — М.: ООО «И.Д. Вильямс», 2010. — 720 с.
• Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ — Петербург, 2007. – 576с.
• Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. — М.: Издательский дом «Вильямс», 2001. — 496 с.
• Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
• Бадд Т. Объектно-ориентированное программирование в действии: Пер с англ. — СПб: «Питер», 1997. — 464 с. 2002
• Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. — М.: ДМК, 2000. — 432 с.
• Фаулер, М. UML. Основы / М. Фаулер, К. Скотт; пер. с англ. – СПб.: Символ – Плюс, 2002. – 192 с.
• SOLID принципы. Рефакторинг — URL: https://pro-prof.com/archives/1914
• Основы UML. Диаграммы последовательности — URL: https://pro-prof.com/archives/2769
• UML data modeling — URL: http://www.agiledata.org/essays/umlDataModelingProfile.html
• Использование doxygen — URL: https://pro-prof.com/archives/887
• Паттерны MVC и Publish-Subscriber — URL: https://pro-prof.com/archives/2400
• Работа с сетью в Qt. Сокеты. Паттерн Adapter — URL: https://pro-prof.com/archives/1372

Заключение

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

2. У PlantUML есть психологический барьер входа: мы слишком привыкли к визуальным редакторам и использование текста кажется шагом назад. Но если благодаря этому шагу назад получается повысить эффективность своей работы, почему его не сделать?

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