Структурные (structural) модели:
- диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;
- диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;
- диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.
Модели поведения (behavioral):
- диаграммы вариантов использования (use case diagrams) - для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей с системой);
- диаграммы взаимодействия (interaction diagrams):
- диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами;
- диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;
- диаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или потоков управления.
UML 1.1 обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его.
К механизмам расширения UML 1.1 относятся:
- стереотипы;
- тегированные (именованные) значения;
- ограничения.
Методика моделирования RUP предусматривает построение двух моделей:
- модели бизнес-процессов (Business Use Case Model);
- модели бизнес-анализа (Business Analysis Model).
Следует так же отметить, что в ноябре 1997 г. версия UML 1.1 была успешно утверждена и принята на вооружение практически всеми крупнейшими компаниями - производителями программного обеспечения (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software, заявили о реализации поддержки UML в своих продуктах. (Paradigm Plus, System Architect, Microsoft Visual Modeler for Visual Basic, Delphi, PowerBuilder и др.).
2.3. Версии UML 1.2 (1.1) – 1.3.
В ходе работы над версией 1.1 UML в рамках консорциума OMG была образована инициативная группа по пересмотру языка (Revisoin Task Force, RTF), которую возглавил Крис Кобрин. Задача группы состояла в устранении неточностей языка UML. В июле 1998 внутри консорциума OMG была выпущена версия 1.2. Появление последней считается внутренним делом OMG, поскольку официальным стандартом UML оставалась версия 1.1. Поэтому версию 1.2 можно считать бета-версией языка UML. Однако в действительности эти изменения едва заметны, поскольку были опубликованы только изменения в стандарте языка UML: фиксированные типы, грамматические ошибки и т. п.
Более значительные изменения коснулись версии 1.3, которые заметно уточнили терминологию в отношении вариантов использования и диаграмм деятельности.
В апреле 1999 года инициативная группа RTF представила консорциуму OMG версию 1.3 в качестве нового официального стандарта языка UML. После чего эта группа взяла на себя дальнейшее развитие языка UML и рассмотрение его последующих обновлений.
Варианты использования
Изменения относительно вариантов использования заключаются в добавлении новых отношений между вариантами использования.
В языке UML версии 1.1 имелись только два отношения между вариантами использования: «использует» и «расширяет», каждое их которых является стереотипом обобщения. В версии 1.3 определены три отношения:
• Конструкция «включает» является стереотипом зависимости. Она означает, что выполнение одного варианта использования включает в себя другой вариант использования. Обычно это отношение встречается в ситуации, когда несколько вариантов использования имеют общие этапы или части. Включаемый вариант использования может предоставлять другим некоторое общее поведение
• Обобщение варианта использования означает, что один вариант использования является вариацией другого. Таким образом, можно иметь один вариант использования для «Выдать деньги по карточке» (базовый вариант использования) и другой вариант использования для ситуации, когда выдача денег невозможна по причине отсутствия средств на счету клиента. Отказ от выплаты денег можно представить в виде отдельного варианта использования, который уточняет базовый вариант использования.
• Конструкция «расширяет» является стереотипом зависимости. Она обеспечивает более управляемую форму расширения по сравнению с отношением обобщения. В этом случае в базовом варианте использования задается несколько точек расширения. Включающий вариант использования может вносить изменения в свое поведение только в этих точках расширения.
Таким образом, можно считать, что отношение со стереотипом «расширяет» расщепляется в версии 1.3 на два отношения: со стереотипом «расширяет» и обобщение.
Диаграммы деятельности
С появлением версии 1.2 языка UML была решена часть вопросов относительно семантики диаграмм деятельности, но не все. В версии 1.3 на большинство из этих вопросов были даны ответы, которые были закреплены в семантике языка UML.
В отношении условного поведения в версии 1.3 стало возможным использовать деятельность в форме ромба как для соединения, так и для ветвления. Хотя для описания условного поведения ни ветвления, ни разделения не являются необходимыми, т.к. все более общепринятым становился способ изображения, заключающий условное поведение в скобки.
Символ синхронизации в форме черты в версии 1.3 относится как к разделению (когда управление расщепляется), так и к слиянию (когда синхронизируемое управление объединяется снова). Однако, в отличие от версии 1.2, никаких дополнительных условий на слияние не накладывается. Необходимо лишь придерживаться правил, гарантирующих соответствие разделений и слияний. По существу это означает, что каждое разделение должно иметь соответствующее слияние, которое соединяет все параллельные нити процесса, берущие начало в исходном разделении. Хотя разделения и слияния могут быть вложенными, их можно удалить с диаграммы, если нити соединяют ветвления (или слияния) напрямую.
Слияния могут произойти только тогда, когда все входящие в него нити завершены. Однако можно определить некоторое условие для выходящей из разделения нити. Если это условие не выполняется, то соответствующая нить считается завершенной и может участвовать в слиянии остальных нитей.
Свойство множественной инициализации больше не поддерживается в версии 1.3. Вместо него можно определить динамическую параллельность в некоторой деятельности (указывается с помощью символа «*» внутри прямоугольника деятельности). Такая деятельность может выполняться параллельно несколько раз; все ее вызовы должны быть завершены, прежде чем сможет быть выполнен какой-либо выходящий из нее переход. Это в некоторой степени эквивалентно множественной инициализации и подходящему условию синхронизации, хотя и является менее гибким способом.
Хотя эти правила в какой-то степени уменьшают гибкость диаграмм деятельности, однако они гарантируют, что диаграммы деятельности являются поистине частными случаями автоматов. Отношение между диаграммами деятельности и автоматами стало предметом дискуссии инициативной группы RTF.
CASE - средства
Большинство разработчиков существующих инструментов моделирования, основанных на UML, сконцентрировало свои усилия на создании достаточно выразительных средств поддержки рисования диаграмм, представленных в разделе, описывающем нотацию UML, забывая при этом точно следовать семантике UML. Важно понимать, что диаграммы UML - это всего лишь проекции модели, проектируемой системы, и вообще говоря, между диаграммами и моделью нет взаимно однозначного соответствия. Конечно, диаграммы тоже важны, но уж точно не менее важна модель в целом, которая и является главным артефактом процесса моделирования. Отметим, что с моделью можно делать много полезного (генерация кода, проверка модели на удовлетворение определенным свойствам, например, непротиворечивость и т.п.) - а на диаграммы, в основном, можно только смотреть.
Начиная с версии UML 1.3 стандарт определяет формат текстового представления модели в XML Metadata Interchange (XMI). Большинство средств моделирования того времени, основанных на UML, поддерживали сериализацию в XMI, но они делали это по-разному - сохранение делалось в разные версии XML и при этом, не всегда корректно. Разработчики Together, зная, что им придется иметь дело с огромным количеством вариаций XMI, реализовали в своем инструменте импорт и экспорт в 7 различных форматов. Благодаря хорошему уровню интеграции между Rose и Together, стало возможным использовать совместно сильные стороны обоих этих продуктов.
UML 1.3 поддерживали следующие средства моделирования: Rational Rose Enterprise, Together CC, ArgoUML, Visial UML. MS Visio Enterprise поддерживал на тот момент только версию 1.2 языка UML. Наиболее полным и точным образом семантика UML реализована в ArgoUML. Причина этого в том, что модель, используемая в ArgoUML, получена непосредственной генерацией по модели стандарта, но не все элементы модели доступны из имеющегося пользовательского интерфейса. В Rational Rose модель основана на старой, поддерживающей методы Booch и ОМТ, что создает иногда заметные проблемы. MS Visio - вообше говоря, это приложение является редактором деловой графики, видимо поэтому UML-моделирование не самая его сильная сторона, справедливости ради, надо сказать, что разработчики UML-трафарета Visio, по крайней мере в одном аспекте, оказались впереди других - в Visio Enterprise реализована проверка модели на соответствие правилам непротиворечивости.
2.4. Версии UML 1.4 – 1.5.
Наиболее существенным дополнением в версии UML 1.4 по сравнению с предыдущей было руководство по написанию профилей – версий UML для конкретных прикладных областей.
Одной из самых популярных областей все в большей степени становится разработка Web-приложений, и в UML пояляется воответствующий профиль, содержащий конкретное множество стереотипов различных элементов модели и их связей. Другой пример профиля, появившегося в версии 1.4 – концептуальное моделирование и проектирование схем баз данных – реализуется посредством компонента Data Modeler, входящего в состав CASE-средства Rational Rose 2000. Ряд инициатив OMG и авторов UML связан с моделированием систем реального времени, распределенными вычислениями, компонентно-базированной разработкой (CORBA Component Model, Enterprise JavaBeans, COM+), хранилищами данных и др. Достаточно большой набор типовых решений по моделированию различных архитектурных механизмов (безопасность, многозадачность, распределенная обработка, многоуровневая архитектура и др.) развивается в рамках технологии Rational Unified Process (RUP) компании Rational Software.
В то же время начался процесс представления UML в качестве стандарта ISO. Преимущества утверждения UML в качестве стандарта ISO очевидны: широкое признание языка, расширение рынка для поддерживающих его продуктов.
Основные диаграммы UML 1.4:
диаграммы вариантов использования (use case diagrams);
диаграммы классов (class diagrams);
диаграммы поведения системы (behavior diagrams);
диаграммы взаимодействия (interaction diagrams);
диаграммы последовательности (sequence diagrams);
кооперативные диаграммы (collaboration diagrams);
диаграммы состояний (statechart diagrams);
диаграммы деятельностей (activity diagrams);
диаграммы реализации (implementation diagrams);
диаграммы компонентов (component diagrams
диаграммы размещения (deployment diagrams).
Язык UML версии 1.5 включает в себя нотацию и метамодель. Нотация представляет собой совокупность графических элементов, которые используются в моделях. Метамодель является средством придания языку UML большей строгости.
UML 1.5 включает в себя двенадцать типов диаграмм, разделенных на три категории:
- диаграммы, описывающие статическую структуру системы;
- диаграммы, описывающие динамическое поведение системы;
- диаграммы управления моделью включая Пакеты, Подсистемы и Модели.
Более подробное описание представленных диаграмм представлено ниже при рассмотрении современной версии языка UML 2.0.
На рынке CASE-средств представлены десятки программных инструментов, поддерживающих нотацию языка UML 1.4-1.5 и обеспечивающих интеграцию, включая прямую и обратную генерацию кода программ, с наиболее распространенными языками и средами программирования, такими как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk.
2.5. Настоящее UML: версия 2.0.
Консорциум OMG ответил на эти запросы повышения уровня абстракции, на котором задумываются, строятся и развиваются программные системы, выпуском UML 2.0 и концепцией архитектуры на базе моделей (Model Driven Architecture, MDA).
Основная работа при разработке версии 2.0 шла по следующим направлениям:
UML infrastructure – реорганизация внутренней структуры метамодели UML с целью улучшения механизмов расширения языка и интеграции с другими технологическими стандартами, входящими в сферу деятельности OMG – CORBA, XML и др. Это направление не затрагивает непосредственно пользователей языка, однако способствует облегчению процесса внесения изменений в язык и создания различных прикладных профилей, адаптированных к потребностям пользователей.
UML superstructure – совершенствование нотаций и средств моделирования различных аспектов архитектуры систем, расширяющее применение языка на различных стадиях процесса создания системы.
OCL (Object Constraint Language) – совершенствование декларативного языка ограничений, используемого в моделях UML – достаточно специфическое направление, не затрагивающее интересы большинства пользователей языка.
Diagram exchange format – создание формата обмена диаграммами UML между CASE-средствами различных поставщиков (то, чего не удалось добиться в рамках CASE-средств, реализующих структурный подход, ввиду отсутствия стандартов средств моделирования).
Кроме того, среди проблем, которые пытались решить архитекторы стандарта UML 2.0, были очевидное разбухание ранних версий UML и недостатки определения семантики. В процессе создания стандарта возникло требование включить в него поддержку разработки на базе MDD и, в частности, подхода к такой разработке с позиций архитектуры на базе моделей (Model Driven Architecture, MDA).
Те, кто незнаком с «кухней» стандартизации языка общественными усилиями, были поражены громоздкостью и сложностью UML 2.0. Кажется, конечный результат полностью противоречит благим намерениям, породившим радикальный пересмотр стандарта. Многочисленность концепций моделирования, плохо определенная семантика и облегченные механизмы расширения UML 2.0 затрудняют его изучение и применение в среде MDD.
Сторонники UML 2.0 утверждают, что этот язык отражает передовой опыт и лучшие методы моделирования. На первый план выдвигаются следующие его достоинства:
расширение представления об UML как о семействе языков с помощью профилей и точек семантических вариаций; они помечают преднамеренно оставленные без семантики части UML, чтобы облегчить добавление семантики, определенной пользователем;
большая выразительность моделирования, в том числе улучшенное моделирование бизнес-процессов, поддержка моделирования классификаторов многократного использования и архитектур распределенных гетерогенных систем;
интеграция семантики действий (Action Semantics), которую разработчики могут использовать для определения семантики среды выполнения моделей и обеспечения семантической точности, необходимой для анализа моделей и их преобразования в конкретные реализации.
Стандарт UML 2.0 содержит большой набор концепций моделирования, сложным образом связанных между собой. Оправдывая громоздкость и сложность UML 2.0, его архитекторы указывают, что язык предназначен для поддержки моделирования в самых разных областях. Чтобы справиться со сложностью, разработчики разделили стандарт на четыре части:
инфраструктура (infrastructure) — определяет базовые классы, на которых основаны модельные конструкции UML;
суперструктура (superstructure) — определяет концепции построения моделей UML;
язык описания объектных ограничений (object constraint language) — определяет язык, описания запросов, инвариантов и операций в моделях UML;
обмен диаграммами (diagram interchange) — определяет расширение метамодели UML, которое поддерживает хранение и обмен информацией, относящейся к компоновке моделей.
Суперструктура UML 2.0 описывает «видимые извне» части стандарта, т. е. концепции, используемые для описания систем. Чтобы появилась возможность справиться со сложностью, концепции суперструктуры организованы в единицы языка. Каждая из них служит для моделирования системы с определенной точки зрения. Например, единица «Взаимодействия» (Interactions) применяется для моделирования взаимодействий между элементами поведения, а «Деятельности» (Activities) — для описания потоков работ в приложениях. Кроме того, некоторые более сложные единицы языка организованы в виде приращений, каждое последующее из которых уточняет предыдущее. Так, «Деятельности» состоят из приращений Fundamental Activities, Structured Activities и Complete Structured Activities. Разделение UML 2.0 на относительно независимые языковые единицы позволяет выбирать для изучения лишь необходимые его части.
|
