Исполняемый UML

Исполняемый UML ( xtUML или xUML ) — это и метод разработки программного обеспечения, и высокоабстрактный язык программирования. Впервые он был описан в 2002 году в книге «Исполняемый UML: основа для архитектуры, управляемой моделями». [1] Язык «объединяет подмножество графической нотации UML ( Unified Modeling Language ) с исполняемой семантикой и правилами синхронизации». [2] Метод исполняемого UML является преемником метода Шлера–Меллора . [3]

Исполняемые модели UML «могут быть запущены, протестированы , отлажены и измерены на предмет производительности» [4] и могут быть скомпилированы в менее абстрактный язык программирования для целевой конкретной реализации . [5] Исполняемый UML поддерживает архитектуру на основе моделей (MDA) посредством спецификации платформенно-независимых моделей и компиляции платформенно-независимых моделей в платформенно-зависимые модели . [6] [7]

Обзор

Исполняемый UML — это более высокий уровень абстракции , чем языки программирования третьего поколения . Это позволяет разработчикам разрабатывать на уровне абстракции приложения. [8] Исполняемый UML направлен на разделение интересов . Предполагается, что это увеличит простоту повторного использования и снизит стоимость разработки программного обеспечения . Это также позволяет исполняемым доменам UML быть кроссплатформенными . Это означает, что он не привязан к какому-либо конкретному языку программирования, платформе или технологии.

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

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

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

Исполняемые строительные блоки UML

Система состоит из нескольких предметных областей, известных как домены в терминах Executable UML. Executable UML используется для моделирования предметной области на уровне абстракции ее предметной области независимо от проблем реализации. Результирующая модель предметной области представлена ​​следующими элементами:

  • Диаграмма доменов дает представление о моделируемом домене и его зависимостях от других доменов.
  • Диаграмма классов определяет классы и ассоциации классов для домена.
  • Диаграмма состояний определяет состояния , события и переходы состояний для класса или экземпляра класса.
  • Язык действий определяет действия или операции, которые выполняют обработку элементов модели.

Диаграмма домена

Исполняемый UML требует идентификации доменов (также известных как: аспекты [9] или проблемы ) системы. "Каждый домен - это автономный мир, населенный концептуальными сущностями" [10] Каждый домен может быть смоделирован независимо от других доменов в системе, что позволяет разделить проблемы . Например, домены для автоматизированной кассовой системы могут включать следующее:

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

Связи между доменами называются мостами . «Мост — это многоуровневая зависимость между доменами». [11] Это означает, что домены могут предъявлять требования к другим доменам. Рекомендуется, чтобы мосты согласовывались экспертами разных доменов.

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

Диаграмма классов

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

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

Ограничения на диаграмме классов могут быть записаны как на языке действий, так и на языке ограничений объектов (OCL).

Метод Executable UML ограничивает элементы UML, которые можно использовать в диаграмме классов Executable UML.

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

Диаграмма состояний

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

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

Язык действия

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

Action Semantics был добавлен в спецификацию UML в 2001 году. Запрос предложений по Action Semantics был основан на предыдущей работе над языками действий, поддерживающими метод Шлера–Меллора . Существующие языки действий: Object Action Language (OAL), Shlaer–Mellor Action Language (SMALL), Action Specification Language (ASL), Model Action Specification Language (MASL), [12] That Action Language (TALL), Starr's Concise Relational Action Language (SCRALL), Platform-independent Action Language (PAL) и PathMATE Action Language (PAL). SCRALL — единственный язык, который является графическим языком действий.

Тестирование и выполнение модели

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

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

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

Компиляция модели

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

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

В терминах MDA компилятор модели создает PSM . Разделение между PIM и PSM в исполняемом UML делает невозможным круговое проектирование модели и препятствует внесению изменений в PSM . [13]

Ключевые аспекты исполняемого UML

Исполняемый UML определяет семантику выполнения для подмножества UML. Ключевые аспекты исполняемого подмножества UML включают следующее:

  • Нет поддержки для специфичных для реализации конструкций, таких как агрегация и композиция. [14]
  • Обобщения всегда обозначаются как {полные, непересекающиеся}.
  • Ассоциации между классами всегда именованы, имеют глагольные фразы на обоих концах, указывающие роли, и имеют множественность, указанную на обоих концах.
  • Множественность на концах ассоциации ограничена значениями 0..1 (от нуля до одного), * (от нуля до многих), 1 (ровно один) или 1..* (от одного до многих).
  • Типы данных ограничены следующими основными типами данных: boolean, string, integer, real, date, timestamp и conditional_id или одним из следующих доменно-специфичных типов данных: numeric, string, enumerated и composite. Доменно-специфичные числовые и строковые типы данных могут представлять подмножества основных типов данных. Доменно-специфичный составной тип данных всегда должен рассматриваться как единое целое в домене. Например, составной тип данных MailingAddress может быть объявлен, но информация о городе не может быть извлечена из него.
  • Ограничения на исполняемые модели UML могут быть представлены либо как язык ограничений объектов (OCL), либо как язык действий.

fUML и ALF

Группа управления объектами стандартизировала Foundational UML (fUML) , на который сильное влияние оказал Executable UML.

Язык действий для фундаментального UML (ALF) [15] — это стандартная спецификация языка действий, разработанная Object Management Group .

Смотрите также

Публикации

  • Джерри Бойд (2003) «Исполняемый UML: диаграммы будущего». Опубликовано на devx.com 5 февраля 2003 г.
  • Шейн Флинт и Клайв Боутон (2003) «Исполняемый/транслируемый UML и системная инженерия». Практические подходы к сложным системам (SETE 2003) .
  • Шейн Флинт, Генри Гарднер и Клайв Боутон (2004). «Исполняемый/транслируемый UML в компьютерном образовании». Труды Шестой Австралазийской конференции по компьютерному образованию — том 30. Australian Computer Society, Inc.
  • HS Lahman (2011). Разработка на основе моделей: приложения . Addison-Wesley Professional. ISBN 0-321-77407-8.
  • Стивен Дж. Меллор и Марк Балсер (2002). Исполняемый UML: Основа для архитектуры, управляемой моделями . Эддисон Уэсли. ISBN 0-201-74804-5.Глава 1 онлайн
  • Исполняемый и переводимый UML
  • Стивен Дж. Меллор (2004), Введение в исполняемый и транслируемый UML
  • Стивен Дж. Меллор (2004), Структура аспектно-ориентированного моделирования
  • Крис Райстрик и др. (2004). Архитектура, управляемая моделями, с исполняемым UML . Cambridge University Press. ISBN 0-521-53771-1.
  • Леон Старр (2002). Исполняемый UML: Как построить модели классов . Prentice-Hall. ISBN 0-13-067479-6.

Ссылки

  1. ^ Меллор и Балсер 2002
  2. ^ Старр 2002, стр. 3.
  3. ^ G. O'Keefe (2006) "Dynamic Logic Semantics for UML Consistency" в: Model-Driven Architecture - Foundations and Applications: Second European Conference, ECMDA-FA 2006, Bilbao, Spain, July 10–13, 2006, Proceedings . Arend Rensink eds. p. 124
  4. ^ Старр 2002, стр. 3.
  5. ^ Меллор и Балсер 2002, раздел 1.4.
  6. ^ Меллор и Балсер 2002, раздел 1.5.
  7. ^ Райстрик и др. 2004, разделы 2.3.3 и 2.3.4.
  8. ^ Меллор и Балсер 2002, раздел 1.1.
  9. ^ Меллор и Балсер 2002, раздел 3.4.
  10. ^ Меллор и Балсер 2002, стр. 14.
  11. ^ Меллор и Балсер 2002, стр. 35.
  12. ^ "MASL — это язык действий на диалекте Шлера-Меллора и язык структурного моделирования.: xtuml/masl". xtUML. 27 декабря 2018 г. Получено 26 октября 2019 г.
  13. ↑ Меллор и Балсер 2002, глава 9.
  14. ^ Меллор и Балсер 2002, стр. xxx.
  15. ^ "Язык действий для фундаментального UML™ (ALF™)". www.omg.org . Получено 21.12.2016 .
  • http://executableumlbook.com Официальный веб-сайт «Исполняемый UML: основа для архитектуры, управляемой моделями».
Взято с "https://en.wikipedia.org/w/index.php?title=Исполняемый_UML&oldid=1245640295#fUML_and_ALF"