Plantuml 

Введение и содержание

Диаграмма классов занимает центральное место в проектировании объектно-ориентированной системы. Нотация классов используется на разных этапах проектирования и строится с различной степенью детализации. Язык UML применяется не только для проектирования, но и с целью документирования, а также эскизирования проекта. Я (в отличии от Гради Буча) не являюсь сторонником разработки проекта с использованием всех видов UML диаграмм, а также детального проектирования. Чаще всего я применяю UML для эскизирования, а также для проектирования по процессу ICONIX . В статье описана часть нотации классов UML, применение которой достаточно в большинстве случаев. Тут не будет информации о кратности ассоциаций и атрибутов, особенностях изображения параллельных операций, шаблонах (параметризованных классах) и ограничениях. При необходимости всю эту информации можно посмотреть в других книгах . Мы же ограничимся базовой частью нотации и больше внимания уделим применению диаграммы классов.

New Dimensions in UML 2.0

The structure and documentation of UML was completely revised in the latest version of UML 2.0. There are now two documents available that describe UML −

• UML 2.0 Infrastructure defines the basic constructs of the language on which UML is based. This section is not directly relevant to the users of UML. This is directed more towards the developers of modeling tools. This area is not in the scope of this
  tutorial.

• UML 2.0 Superstructure defines the user constructs of UML 2.0. It means those elements of UML that the users will use at the immediate level. This is the main focus for the user community of UML.

This revision of UML was created to fulfil a goal to restructure and refine UML so that usability, implementation, and adaptation are simplified.

UML infrastructure is used to −

• Provide a reusable meta-language core. This is used to define UML itself.

• Provide mechanisms to adjustment the language.

UML superstructure is used to −

• Provide better support for component-based development.

• Improve constructs for the specification of architecture.

• Provide better options for the modeling of behavior.

The important point to note is the major divisions described above. These divisions are used to increase the usability of UML and define a clear understanding of its usage.

There is another dimension which is already proposed in this new version. It is a proposal
for a completely new Object Constraint Language (OCL) and Diagram Interchange. These features all together form the complete UML 2.0 package.

Плагины к 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

История

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

До 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

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

Структурные сущности — классы

Класс – это описание набора объектов с одинаковыми атрибутами, операциями, связями и семантикой.
Графически класс изображается в виде прямоугольника, разделенного на 3 блока горизонтальными линиями:

• имя класса
• атрибуты (свойства) класса
• операции (методы) класса.

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

• — — private (частный)
• # — protected (защищенный)
• + — public (общий)

Видимость для полей и методов указывается в виде левого символа в строке с именем соответствующего элемента.
Каждый класс должен обладать именем, отличающим его от других классов. Имя – это текстовая строка. Имя класса может состоять из любого числа букв, цифр и знаков препинания (за исключением двоеточия и точки) и может записываться в несколько строк.
На практике обычно используются краткие имена классов, взятые из словаря моделируемой системы. Каждое слово в имени класса традиционно пишут с заглавной буквы (верблюжья конвенция), например Sensor (Датчик) или TemperatureSensor (ДатчикТемпературы).
Для абстрактного класса имя класса записывается курсивом. Атрибут (свойство) – это именованное свойство класса, описывающее диапазон значений, которые может принимать экземпляр атрибута. Класс может иметь любое число атрибутов или не иметь ни одного. В последнем случае блок атрибутов оставляют пустым.
Атрибут представляет некоторое свойство моделируемой сущности, которым обладают все объекты данного класса. Имя атрибута, как и имя класса, может представлять собой текст. На практике для именования атрибута используются одно или несколько коротких существительных, выражающих некое свойство класса, к которому относится атрибут.
Можно уточнить спецификацию атрибута, указав его тип, кратность (если атрибут представляет собой массив некоторых значений) и начальное значение по умолчанию.
Статические атрибуты класса обозначаются подчеркиванием.Операция (метод) – это реализация метода класса. Класс может иметь любое число операций либо не иметь ни одной. Часто вызов операции объекта изменяет его атрибуты.
Графически операции представлены в нижнем блоке описания класса.
Допускается указание только имен операций. Имя операции, как и имя класса, должно представлять собой текст. На практике для именования операции используются короткие глагольные конструкции, описывающие некое поведение класса, которому принадлежит операция. Обычно каждое слово в имени операции пишется с заглавной буквы, за исключением первого, например move (переместить) или isEmpty (проверка на пустоту).
Можно специфицировать операцию, устанавливая ее сигнатуру, включающую имя, тип и значение по умолчанию всех параметров, а применительно к функциям – тип возвращаемого значения.
Абстрактные методы класса обозначаются курсивным шрифтом.
Статические методы класса обозначаются подчеркиванием.
Изображая класс, не обязательно показывать сразу все его атрибуты и операции. Для конкретного представления, как правило, существенна только часть атрибутов и операций класса. В силу этих причин допускается упрощенное представление класса, то есть для графического представления выбираются только некоторые из его атрибутов. Если помимо указанных существуют другие атрибуты и операции, вы даете это понять, завершая каждый список многоточием.
Чтобы легче воспринимать длинные списки атрибутов и операций, желательно снабдить префиксом (именем стереотипа) каждую категорию в них. В данном случае стереотип – это слово, заключенное в угловые кавычки, которое указывает то, что за ним следует.

Архив

• ► 

  2021

  (1)

  ► 

  августа

  (1)

• ► 

  2018

  (1)

  ► 

  мая

  (1)

• ► 

  2017

  (2)

  ► 

  сентября

  (1)

  ► 

  апреля

  (1)

• ► 

  2016

  (12)

  ► 

  декабря

  (1)

  ► 

  ноября

  (2)

  ► 

  августа

  (3)

  ► 

  июля

  (1)

  ► 

  июня

  (3)

  ► 

  апреля

  (2)

• ► 

  2015

  (14)

  ► 

  декабря

  (1)

  ► 

  сентября

  (1)

  ► 

  августа

  (3)

  ► 

  июля

  (3)

  ► 

  июня

  (1)

  ► 

  апреля

  (1)

  ► 

  марта

  (2)

  ► 

  февраля

  (2)

• ► 

  2014

  (4)

  ► 

  декабря

  (1)

  ► 

  июня

  (1)

  ► 

  мая

  (1)

  ► 

  февраля

  (1)

• ► 

  2013

  (3)

  ► 

  сентября

  (1)

  ► 

  августа

  (1)

  ► 

  марта

  (1)

• ► 

  2012

  (4)

  ► 

  августа

  (2)

  ► 

  июля

  (1)

  ► 

  мая

  (1)

• ► 

  2011

  (23)

  ► 

  октября

  (2)

  ► 

  августа

  (3)

  ► 

  июля

  (4)

  ► 

  июня

  (3)

  ► 

  мая

  (3)

  ► 

  апреля

  (2)

  ► 

  марта

  (1)

  ► 

  февраля

  (2)

  ► 

  января

  (3)

• ► 

  2010

  (37)

  ► 

  декабря

  (3)

  ► 

  ноября

  (7)

  ► 

  октября

  (5)

  ► 

  сентября

  (7)

  ► 

  августа

  (5)

  ► 

  июля

  (4)

  ► 

  июня

  (3)

  ► 

  мая

  (1)

  ► 

  апреля

  (2)

• ▼ 

  2008

  (2)

  • ▼ 

    февраля

    (1)

    UML – быстрый старт

  ► 

  января

  (1)

• ► 

  2007

  (4)

  ► 

  июля

  (1)

  ► 

  июня

  (1)

  ► 

  мая

  (1)

  ► 

  апреля

  (1)

• ► 

  2006

  (1)

  ► 

  декабря

  (1)

Постановка задачи

Основные требования к решению

• условные схемы оборудования (установок, конвейеров, транспортных систем), на которых отображается состояние работы узлов, «по щелчку мыши» пользователь желает получать дополнительную информацию или вводить управляющие команды,
• аналитические графики (гистограммы, пузырьковые диаграммы), «по щелчку мыши» на элементы которых пользователь желает получать информацию, или же пользователь желает напрямую «подтаскивать» мышью элементы, изменяя картину в нужную сторону, чтобы узнать необходимые числовые показатели,
• визуальный анализ данных, представимых в виде графов (например: взаимосвязи между юридическими лицами в базе данных), пользователь желает «перетаскивать» элементы графа вручную, чтобы в итоге вставить получившуюся картинку в печатный отчёт,
• все средства визуального моделирования/конструирования чего-либо из блоков, в частности, все CASE-средства,

• Картинка должна состоять из дискретных элементов различной графической сложности,
• Картинка должна быть масштабируемой и прокручиваемой, т. е. пользователь должен иметь возможность покрупнее разглядеть любой из фрагментов диаграммы, используя изменение масштаба и полосы прокрутки,
• Некоторые из элементов картинки должны быть «кликабельными», т. е. система в каждый момент должна «понимать», на какой именно элемент наведён указатель мыши, иметь возможность показывать для них всплывающие подсказки,
• Некоторые из «кликабельных» элементов должны быть «выделяемыми», т. е. пользователь должен иметь возможность «поставить выделение» на элемент щелчком мыши, должно быть доступно выделение группы элементов с нажатой клавишей Shift и при помощи «прямоугольного лассо». С выделенными объектами, в зависимости от задачи, могут производиться некоторые действия или изменение свойств.
• Некоторые из «кликабельных» элементов должны быть «перетаскиваемыми», т. е. пользователь должен иметь возможность передвинуть мышью один элемент или группу выделенных элементов:

четырёх ключевых условий

1. Объектно-ориентированный язык программирования.
2. Доступность объекта-«холста» (Canvas), с возможностью отрисовки графических примитивов (линий, дуг, многоугольников и т. п.).
3. Компоненты, реализующие управляемые полосы прокрутки.
4. Доступность обработки событий мыши.

этого руководстваhttps://github.com/inponomarev/graphexample

Трудности «наивного» подхода

• С усложнением картины растёт длина «процедуры отрисовки». Для сложной схемы процедура становится очень длинной и запутанной.
• Код, рисующий картинку, сам «по волшебству» не задаёт критерий, по которому можно было бы определить объект, выделяемый в текущий момент курсором мыши. Мы должны писать отдельную процедуру, определяющую объект, над которым находится курсор мыши, и при этом должны постоянно синхронизировать код процедуры отрисовки и процедуры распознавания объектов.
• Вместе со сложностью процедуры отрисовки растёт сложность процедуры распознавания.

«Один день из жизни белки» или от моделирования процессов к проектированию автоматизированной системы учёта материальных ценностей «Белка-1.0» (Часть 1)

При чем тут «белка»?

Сразу поясню, при чем тут «белка». Наткнувшись в Сети на забавные проекты для изучения UML с опорой на предметную область, заимствованную из сюжетов сказок (например, здесь ), я для своих студентов тоже решила подготовить подобный пример, чтобы можно было изучить для начала всего три вида диаграмм: Activity Diagram, Use-case Diagram и Class Diagram. Умышленно не перевожу на русский язык названия диаграмм, чтобы избежать споров о «трудностях перевода». Что для чего – поясню немного позже. В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems – хороший инструмент за разумные деньги. А в рамках учебных занятий применяю Modelio , неплохое бесплатное средство объектно-ориентированного проектирования, поддерживающее стандарты UML2.0 и BPMN, без излишних наворотов в части изобразительных возможностей, но вполне достаточное для изучения основ языка.

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

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

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

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

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

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

ссылке

Отношение обобщения

Заметим, что в нашей системе группы пользователей «Преподаватель» и «Классный руководитель» обладают схожими возможностями. Чтобы изобразить это на диаграмме, мы можем пойти одним из трёх путей:

1. Дублировать варианты использования, чтобы связать их с каждым схожим актёром (очевидно, неудачный вариант).

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

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

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

Разумеется, мы воспользуемся третьим путём. В этом нам поможет, так называемое, отношение обобщения. Отношение обобщения обозначается сплошной линией с полой треугольной стрелкой.

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

Ниже представлены несколько примеров использования отношения обобщения.

Покупка горного и скоростного велосипеда —
ЧАСТНЫЙ случай покупки велосипедаФизическое лицо и юридическое лицо
можно ОБОБЩИТЬ до обычного покупателя

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

Вернёмся к нашему основному примеру. Изобразим отношение обобщения от актёра «Кл. руководитель» к актёру «Преподаватель».

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

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

Изобразим это на диаграмме. Для этого создадим два варианта использования «Узнать среднюю оценку за некоторый период времени» и «Узнать среднюю оценку по предмету» и соединим их с вариантом использования «Узнать свои оценки» отношением обобщения.

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

Присоединим это к основной диаграмме:

Вторая версия диаграммы

Сущности

Диаграммы классов оперируют тремя видами сущностей UML:

• Структурные.
• Поведенческие.
• Аннотирующие.

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