Введение
Исполняемый UML (xtUML или xUML) является методом разработки программного обеспечения и высоко абстрактным программным языком. Впервые он был описан в 2002 году в книге "Выполнимый UML: основа для архитектуры, управляемой моделью". Язык "сочетает в себе подмножество графической нотации UML (Unified Modeling Language) с исполняемой семантикой и правилами синхронизации". Метод UML является преемником метода ShlaerMellor. Исполняемые UML-модели "могут быть запущены, протестированы, отлажены и измерены для производительности. ", и может быть скомпилирован в менее абстрактный язык программирования для целенаправленной реализации. Исполняемая UML поддерживает архитектуру, управляемую моделью (MDA), посредством спецификации независимых от платформы моделей и компиляции независимых от платформы моделей в конкретные модели платформы.
Обзор
Исполняемый UML является более высоким уровнем абстракции, чем языки программирования третьего поколения. Это позволяет разработчикам развиваться на уровне абстракции приложения. Исполняемая UML направлена на разделение проблем. Это должно упростить повторное использование и снизить стоимость разработки программного обеспечения. Это также позволяет исполняемым доменам UML быть кроссплатформенными. Это означает, что он не связан с каким-либо конкретным языком программирования, платформой или технологией. Исполняемая UML также позволяет переводить независимые от платформы модели (PIM) в платформы-специфические модели (PSM). Метод UML Executable позволяет оценить модель как интеллектуальную собственность, поскольку модель является полностью исполняемым решением для проблемного пространства. Действия определяются в языке действий. Это означает, что автоматическое генерация кода реализации из исполняемых моделей UML может быть выведена в оптимизированной форме. Исполняемая UML предназначена для использования как исполняемый код, так и для документации. Модели представляют собой графическую, исполняемую спецификацию проблемного пространства, которая компилируется в целевую реализацию. Они также предназначены для чтения человеком.
Исполняемые строительные блоки UML
Система состоит из нескольких предметов, известных как домены в исполняемых терминах UML. Исполняемый UML используется для моделирования домена на уровне абстракции его предмета независимо от проблем реализации. Полученная модель домена представлена следующими элементами: диаграмма домена предоставляет представление о моделируемом домене и зависимости, которые он имеет от других доменов. Диаграмма классов определяет классы и классовые ассоциации для домена. Диаграмма состояния определяет состояния, события и переходы состояния для класса или экземпляра класса. Язык действий определяет действия или операции, которые выполняют обработку элементов модели.
The domain chart provides a view of the domain being modeled, and the dependencies it has on other domains. The class diagram defines the classes and class associations for the domain. The statechart diagram defines the states, events, and state transitions for a class or class instance. The action language defines the actions or operations that perform processing on model elements.
График доменов
Исполняемая UML требует идентификации доменов (также известных как: аспекты или проблемы) системы. "Каждый домен - это автономный мир, населенный концептуальными существами" Каждый домен может быть смоделирован независимо от других доменов в системе, что позволяет разделить проблемы. В качестве примера, домены для автоматической кассовой системы могут включать следующее: Модель домена приложения бизнес-логики автоматической кассы. Модель домена безопасности различных вопросов, касающихся безопасности системы (таких как аутентификация и шифрование). Модель домена доступа к данным методов использования внешних данных. Модель домена регистрации различных методов, с помощью которых система может или должна регистрировать информацию. Модель домена пользовательского интерфейса взаимодействия пользователя с системой. Архитектурная доменная модель реализованной модели UML на аппаратных и программных платформах системы. Разделение проблем позволяет каждой области разработать и проверить независимо от других областей в системе соответствующими экспертами в области. Связи между доменами называются мостами. "Мост - это многоуровневая зависимость между областями". Это означает, что домены могут устанавливать требования к другим доменам. Рекомендуется, чтобы о мостах договорились различные эксперты в области. Домен может быть отмечен как реализованный, чтобы указать, что домен существует и не нуждается в моделировании. Например, домен доступа к данным, использующий базу данных MySQL, будет отмечен как реализованный.
The application domain model of the automated teller's business logic. The security domain model of various issues regarding system security (such as authentication and encryption). The data access domain model of methods for external data usage. The logging domain model of the various methods through which the system can or must log information. The user interface domain model of the user interactions with the system. The architecture domain model of the implemented of the Executable UML model on the system's hardware and software platforms. The separation of concerns enables each domain to be developed and verified independently of the other domains in the system by the respective domain experts. The connections between domains are called bridges. "A bridge is a layering dependency between domains". This means that the domains can place requirements upon other domains. It is recommended that bridges are agreed upon by the different domain experts. A domain can be marked as realized to indicate that the domain exists and does not need to be modeled. For example, a data access domain that uses a MySQL database would be marked as realized.
Диаграмма классов
Концептуальные сущности, такие как осязаемые вещи, роли, инциденты, взаимодействия и спецификации, специфичные для моделируемой области, абстрагируются в классы. Классы могут иметь атрибуты и операции. Отношения между этими классами будут обозначены ассоциациями и обобщениями. Ассоциация может потребовать дальнейшей абстракции как класс ассоциации. Ограничения на диаграмме классов могут быть написаны как на языке действия, так и на языке ограничений объектов (OCL). Метод Executable UML ограничивает элементы UML, которые могут быть использованы в диаграмме классов Executable UML. Диаграмма классов UML предназначена для отображения информации о домене. Слишком большая сложность в диаграммах состояния является хорошим показателем того, что диаграмма классов должна быть переработана.
Диаграмма состояния
У классов есть жизненные циклы, которые моделируются в исполняемом UML с диаграммой состояния. Диаграмма состояния определяет состояния, переходы, события и процедуры, которые определяют поведение класса. В каждом штате есть только одна процедура, которая выполняется при въезде в этот штат. Процедура состоит из действий, которые определяются в языке действий.
Язык действия
Сами по себе модели класса и состояния могут обеспечить только статический вид домена. Для того, чтобы иметь исполняемую модель, должен быть способ создавать экземпляры классов, устанавливать ассоциации, выполнять операции на атрибутах, вызвать события состояния и т. д. В исполняемом UML это делается с использованием языка действий, который соответствует семантике действий UML. Action Semantics была добавлена в спецификацию UML в 2001 году. Предложение о предоставлении услуг по семантике действий было основано на предыдущей работе по языкам действий, поддерживающим метод ShlaerMellor. Существующие языки действий - это язык действия объектов (OAL), язык действия ShlaerMellor (SMALL), язык спецификации действий (ASL), язык спецификации модельных действий (MASL), язык действия (TALL), краткий язык действия Старра (SCRALL), независимый от платформы язык действия (PAL) и язык действия PathMATE (PAL). SCRALL - единственный язык, который является графическим языком действия.
Испытание модели и выполнение
После того, как домен смоделирован, он может быть протестирован независимо от целевой реализации путем выполнения модели. Каждый домен может быть проверен и подтвержден независимо от любого другого домена. Это позволяет связывать обнаруженные ошибки с доменом и независимо от других проблем системы. Проверка будет включать такие вещи, как человеческий обзор моделей, выполненный экспертами в соответствующей области, и автоматизированная проверка семантики UML. т.е. проверка соответствия модели UML с метамоделью UML. Валидация обычно включает использование инструмента UML для выполнения модели. Исполнение может происходить до или после компиляции модели.
Сборка моделей
Для поддержки выполнения в целевой реализации модель домена должна быть переведена в менее абстрактную форму. Этот процесс перевода называется компиляцией модели. Большинство компиляторов моделей ориентированы на известный язык программирования, потому что это позволяет повторно использовать существующие технологии компилятора. Оптимизация моделей домена по целям реализации цели снизит уровень абстракции, негативно повлияет на независимость домена и увеличит стоимость повторного использования. В UML оптимизации выполняются компилятором модели либо автоматически, либо посредством маркировки. Маркировка позволяет нацелить конкретные элементы модели на конкретные реализации более низкого уровня и позволяет принимать более широкие архитектурные решения, такие как указание на то, что коллекции объектов должны быть реализованы в виде двойного списка. В терминах MDA компилятор модели создает PSM. Разделение между PIM и PSM в исполняемом UML отключает возможность проектирования модели в оборот и препятствует модификациям PSM.
Ключевые аспекты UML
Исполняемый UML определяет семантику исполнения для подмножества UML. Ключевые аспекты подмножества исполняемого UML включают следующее: отсутствие поддержки конкретных конструкций реализации, таких как агрегация и композиция. Обобщения всегда обозначаются как {полные, разрозненные}. Ассоциации между классами всегда имеют название, имеют глагольные фразы на обоих концах, определяющие роли, и имеют множественность, указанную на обоих концах. Множества на концах ассоциации ограничены 0 1 (от нуля до одного), * (от нуля до многих), 1 (точно один) или 1 * (от одного до многих). Типы данных ограничены следующими основными типами данных: булевой, строка, целое число, реальный, дата, метка времени и произвольный id, или одним из следующих типов данных, специфичных для домена: числовой, строка, перечисленный и составный. Специфические для домена числовые и строчные типы данных могут представлять подмножества основных типов данных. Составный тип данных, специфичный для домена, всегда рассматривается как единая единица в пределах домена. Например, можно было объявить составный тип данных MailingAddress, но информация о городе не могла быть извлечена из него. Ограничения на исполняемых моделях UML могут быть представлены как язык ограничений объектов (OCL) или язык действий.
No support for implementation specific constructs, like aggregation and composition. Generalizations are always notated as {complete, disjoint}. Associations between classes are always named, have verb phrases on both ends specifying the roles, and have multiplicity specified on both ends. Multiplicities on association ends are restricted to 0 1 (zero to one), * (zero to many), 1 (exactly one), or 1 * (one to many). Data types are restricted to the following core data types: boolean, string, integer, real, date, timestamp, and arbitrary id, or one of the following domain specific data types: numeric, string, enumerated, and composite. Domain specific numeric and string data types can represent subsets of the core data types. The domain specific composite data type is to always be treated as a single unit within the domain. e. g., a MailingAddress composite data type could be declared, but city information couldn't be extracted from it. Constraints on the Executable UML models can either be represented as Object Constraint Language (OCL) or action language.
fUML и ALF
Группа управления объектами стандартизировала основополагающий UML (fUML), на который сильно повлиял исполняемый UML. Action Language for Foundational UML (ALF) - стандартная спецификация языка действий, разработанная группой по управлению объектами.