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

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

Смотрите также: Диаграмма классов

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

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

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

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

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

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

Смотрите также: Конечный автомат и Диаграмма состояний

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

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

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

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

Семантика действий была добавлена ​​в спецификацию UML в 2001 году. Запрос предложений по семантике действий был основан на предыдущей работе над языками действий, поддерживающими Метод Шлаера – Меллора. Существующие языки действий - это язык объектных действий (OAL), язык действий Шлаера – Меллора (SMALL), язык спецификации действий (ASL), язык спецификации модифицированных действий (MASL),[12] Этот язык действий (TALL), краткий язык взаимодействия Старра (SCRALL), платформо-независимый язык действий (PAL) и язык действий PathMATE (PAL). SCRALL - единственный язык графических действий.

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

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

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

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

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

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

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

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

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

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

  • Нет поддержки конструкций, специфичных для реализации, таких как агрегация и композиция.[14]
  • Обобщения всегда обозначаются как {полные, непересекающиеся}.
  • Связи между классами всегда с именами, иметь глагольные фразы на обоих концах, определяющие роли, и иметь множественность, указанную на обоих концах.
  • Кратности на концах ассоциации ограничены до 0..1 (от нуля до единицы), * (от нуля до многих), 1 (ровно до одного) или 1 .. * (от одного до многих).
  • Типы данных ограничены следующими основными типами данных: логическим, строковым, целочисленным, действительным, датой, отметкой времени и произвольным_id или одним из следующих типов данных, зависящих от предметной области: числовые, строковые, перечисляемые и составные. Зависящие от домена числовые и строковые типы данных могут представлять подмножества основных типов данных. Составной тип данных, зависящий от предметной области, всегда следует рассматривать как единое целое внутри домена. например, Адрес получателя Составной тип данных можно было объявить, но нельзя было извлечь из него информацию о городе.
  • Ограничения на исполняемых моделях UML можно представить как Язык объектных ограничений (OCL) или язык действий.

fUML и ALF

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

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

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

Публикации

  • Джерри Бойд (2003) "Исполняемый UML: диаграммы будущего. "опубликовано в devx.com, 5 февраля 2003 г.
  • Шейн Флинт и Клайв Боутон (2003) «Исполняемый / переводимый UML и системная инженерия». Практические подходы к сложным системам (SETE 2003).
  • Шейн Флинт, Генри Гарднер и Клайв Боутон (2004). "Исполняемый / переводимый UML в компьютерном образовании." Труды Шестой Австралазийской конференции по компьютерному образованию - Том 30. Австралийское компьютерное общество, Inc.
  • H.S. Лахман (2011). Модельно-ориентированная разработка: приложения. Эддисон-Уэсли Профессионал. ISBN  0-321-77407-8.
  • Стивен Дж. Меллор И Марк Бальсер (2002). Исполняемый UML: основа модельно-ориентированной архитектуры. Эддисон Уэсли. ISBN  0-201-74804-5. Глава 1 онлайн
  • Исполняемый и переводимый UML, заархивировано из оригинал на 2010-02-09, получено 2015-08-25
  • Стивен Дж. Меллор (2004). «Введение в исполняемый и переводимый UML». TechOnLine. Архивировано из оригинал на 2006-05-20. Получено 2006-04-25.
  • Стивен Дж. Меллор (2004). «Основа для аспектно-ориентированного моделирования» (PDF). Project Technology, Inc. Получено 2006-04-25.
  • Крис Рейстрик; и другие. (2004). Архитектура на основе модели с исполняемым UML. Издательство Кембриджского университета. ISBN  0-521-53771-1.
  • Леон Старр (2002). Исполняемый UML: как создавать модели классов. Прентис-Холл. ISBN  0-13-067479-6.

Рекомендации

  1. ^ Меллор и Бальсер 2002
  2. ^ Старр 2002, стр. 3.
  3. ^ Г. О'Киф (2006) «Семантика динамической логики для согласованности UML» в: Модельно-ориентированная архитектура - основы и приложения: Вторая европейская конференция, ECMDA-FA 2006, Бильбао, Испания, 10–13 июля 2006 г., Труды. Аренд Ренсинк ред. п. 124
  4. ^ Старр 2002, стр. 3.
  5. ^ Меллор и Бальсер 2002, раздел 1.4.
  6. ^ Меллор и Бальсер 2002, раздел 1.5.
  7. ^ Raistrick et al. 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, стр. ххх.
  15. ^ "Язык действий для основополагающего UML ™ (ALF ™)". www.omg.org. Получено 2016-12-21.

внешняя ссылка