Мультимоделирование для конкретных областей - Domain-specific multimodeling

Мультимоделирование для конкретных областей^[1] это парадигма разработки программного обеспечения, в которой каждое представление выражается в виде отдельного предметно-ориентированный язык (DSL).

Успешное развитие современной корпоративной системы требует конвергенции множества точек зрения. В процессе создания такой системы принимают участие бизнес-аналитики, эксперты в предметной области, дизайнеры взаимодействия, эксперты по базам данных и разработчики с разным опытом. Их различные рабочие продукты должны управляться, согласовываться и интегрироваться для создания работающей системы. У каждого участника процесса разработки есть особый язык, адаптированный для решения проблем, специфичных для его взгляда на систему. Проблема интеграции этих различных взглядов и избежания потенциальной какофонии множества разных языков является проблема координации.

Мультимоделирование для конкретных областей^[1] многообещающе по сравнению с более традиционными парадигмами разработки, такими как одноязычное программирование и универсальное моделирование. Чтобы воспользоваться преимуществами этой новой парадигмы, мы должны решить проблему координации. Эта проблема также известна как проблема фрагментации в контексте Управление глобальной моделью.

Одно из предложений по решению этой проблемы: метод согласования.^[1] Это трехэтапный метод преодоления препятствий, связанных с интеграцией различных взглядов и согласованием нескольких языков. Метод предписывает, как (1) идентифицировать и (2) определять ссылки через языковые границы, то есть перекрывает между разными языками. Наконец, метод предлагает конкретные предложения о том, как (3) применять эти знания в реальной разработке в форме последовательности, навигации и руководства.

Мотивирующий пример

Корпоративные системы на основе нескольких предметно-ориентированные языки в изобилии. Языки с метамоделью, определенной в расширяемый язык разметки (XML) получил особенно широкое распространение. Чтобы проиллюстрировать разработку с использованием нескольких языков, мы приведем пример из тематического исследования: Apache Open для бизнеса (OFBiz) система. Вкратце сказано: OFBiz является Планирование ресурсов предприятия система, которая включает стандартные компоненты, такие как инвентаризация, бухгалтерский учет, электронная коммерция и т.д. Эти компоненты реализованы смесью языков на основе XML и обычного кода Java. В качестве примера остановимся на управление содержанием компонент, особенно вариант использования, в котором пользователь-администратор создает онлайн-опрос, как показано на снимке экрана ниже. Мы будем называть этот пример создать опрос пример.

На рисунке показан снимок экрана административного интерфейса приложения для управления контентом в работающей OFBiz пример. Чтобы создать опрос, пользователь заполняет поля формы ввода и нажимает Обновить кнопка. Это создает новый опрос, который можно редактировать и позже опубликовать на веб-сайте внешнего интерфейса в OFBiz. За кулисами этот вариант использования включает несколько артефактов, написанных на разных языках. В этом примере давайте сосредоточимся только на трех из этих языков: Entity, Service и Form DSL.

Эти три языка примерно соответствуют структурному, поведенческому и пользовательский интерфейс беспокойство в OFBiz. Entity DSL используется для описания базовой модели данных и, следовательно, способа сохранения созданного опроса. Service DSL используется для описания интерфейса службы, которая вызывается, когда пользователь нажимает кнопку Обновить кнопка. Наконец, DSL формы используется для описания внешнего вида формы. Хотя три языка предназначены для разных целей, их нельзя разделить полностью. Пользовательский интерфейс вызывает определенную логику приложения, и эта логика приложения управляет данными приложения. Это пример неортогональные проблемы. Языки пересекаются, потому что проблемы, которые они представляют, нельзя полностью разделить. Давайте рассмотрим эти три языка в вверх дном манеры и указать на их совпадения.

Entity DSL

Entity DSL определяет структуру данных в OFBiz. В листинге ниже показано определение объекта Survey, который является бизнес-объектом, представляющим концепцию опроса. Код в листинге не требует пояснений: объект под названием Survey определен с 10 полями. У каждого поля есть имя и тип. Поле SurveyId используется как первичный ключ. Это определение загружено центральным компонентом в OFBiz называется двигатель сущности. Механизм сущностей создает соответствующий бизнес-объект. Целью механизма сущностей является управление транзакционными свойствами всех бизнес-объектов и взаимодействие с различными механизмами сохранения, такими как Подключение к базе данных Java, Enterprise JavaBeans или даже некоторые устаревшая система.

  <сущность имя-сущности ="Опрос" ... title =«Организация опроса»>    <поле имя ="SurveyId" type ="id-ne"/>    <поле имя ="SurveyName" type ="имя"/>    <поле имя ="описание" type ="описание"/>    <поле имя ="Комментарии" type ="комментарий"/>    <поле имя ="submitCaption" type ="короткий варчар"/>    <поле имя ="responseService" type ="длинный варчар"/>    <поле имя ="isAnonymous" type ="индикатор" .../>    <поле имя ="allowMultiple" type ="индикатор" .../>    <поле имя ="allowUpdate" type ="индикатор" .../>    <поле имя ="acroFormContentId" type ="id-ne" .../>    <прим-ключ поле ="SurveyId"/>  </entity>

Сервис DSL

Сервисный DSL определяет интерфейс сервисов в OFBiz. Каждая служба инкапсулирует часть логики приложения системы. Цель этого языка - иметь единообразную абстракцию для различных механизмов реализации. Отдельные сервисы могут быть реализованы на Java, язык сценариев, или используя механизм правил. В листинге ниже показан интерфейс службы createSurvey.

Помимо имени, элемент службы определяет расположение и команду вызова реализации для этой службы. Атрибут default-entity-name указывает, что эта услуга относится к объекту Survey, который был определен в предыдущем листинге. Это частичное совпадение двух языков, в частности, так называемый мягкая ссылка. Модель в Service DSL относится к модели в Entity DSL. Эта ссылка используется в двух элементах автоатрибутов ниже, которые определяют ввод и вывод службы в виде типизированных атрибутов. В качестве входных данных служба принимает атрибуты, соответствующие всем полям непервичного ключа (nonpk) объекта Survey, и эти атрибуты являются необязательными. В качестве выходных данных служба возвращает атрибуты, соответствующие полям первичного ключа (pk) Survey, то есть в данном случае поле SurveyId, и эти атрибуты являются обязательными. В данном случае цель ссылки на разные языки - уменьшить избыточность. Атрибуты службы createSurvey соответствуют полям объекта Survey, поэтому их необходимо указать только один раз.

  <сервис имя ="createSurvey" имя-сущности по умолчанию ="Опрос" ...           расположение ="org / ofbiz / content / survey / SurveyServices.xml"           invoke ="createSurvey"> ...    <разрешение-служба имя-службы ="contentManagerPermission"                        основное действие ="СОЗДАЙТЕ"/>    <автоатрибуты включить ="нонпк" режим ="В" необязательный ="правда"/>    <автоатрибуты включить ="pk" режим ="ВНЕ" необязательный ="ложный"/>  </service>

Форма DSL

Form DSL используется для описания макета и внешнего вида форм ввода в пользовательском интерфейсе. Язык состоит из таких понятий предметной области, как Форма и Поле. В листинге ниже показана реализация формы EditSurvey. На этот раз DSL формы перекрывается со служебным DSL. Атрибут target формы и элементы alt-target указывают, что ввод от отправки этой формы должен быть направлен либо в службы updateSurvey, либо в createSurvey. Элемент auto-fields-service указывает, что форма должна включать поле, соответствующее каждому из атрибутов службы updateSurvey (которые аналогичны атрибутам службы createSurvey). Это производит аналогичный эффект импорт определения из другой модели, как в случае элементов автоатрибутов в предыдущем листинге. Ниже мы видим, что можно настроить внешний вид этих импортированный такие поля, как isAnonymous. Наконец, добавляется submitButton с локализованным заголовком, чтобы пользователь мог отправлять свои данные в службу, на которую указывает ссылка.

  <форма имя ="EditSurvey" type ="не замужем" цель ="updateSurvey"        title ="" по умолчанию-карта-имя ="опрос">    <альтернативная цель использование-когда ="опрос == ноль" цель ="createSurvey"/>    <автополя-сервис имя-службы ="updateSurvey"/>    <поле использование-когда ="опрос! = ноль" имя ="SurveyId" ... />    ...    <поле имя ="isAnonymous">      <раскрывающийся список нет-текущий-выбранный-ключ ="N" разрешить пустой ="ложный">        <вариант ключ ="Y"/> <опция ключ ="N"/>      </drop-down>    </field>    ...    <поле имя ="submitButton" title ="$ {uiLabelMap.CommonUpdate}"           виджет-стиль ="smallSubmit">      <отправить button-type ="кнопка"/>    </field>  </form>

В создать опрос Пример, описанный здесь, реализован с использованием моделей на трех разных языках. Полная реализация на самом деле включает в себя еще больше языков, таких как Screen DSL для определения макета экрана, на котором размещается форма, и Minilang DSL, который является языком манипулирования данными, используемым для реализации службы. Однако эти три языка действительно иллюстрируют основную идею конкретизации каждой проблемы. В этом примере также показан простой способ уменьшения избыточности, позволяя языкам немного перекрываться.

Многоуровневая настройка

Доменные языки, как и описанные выше, обладают ограниченной выразительностью. Часто необходимо добавлять фрагменты кода на языке общего назначения, таком как Java, для реализации специализированных функций, выходящих за рамки этих языков. Этот метод называется многоуровневая настройка.^[2]Поскольку этот метод очень часто используется в установках с несколькими языками, мы проиллюстрируем его продолжением примера. Назовем это построить PDF пример.

Предположим, мы хотим построить PDF файл для каждого ответа на опрос, который создают пользователи. Создание файла PDF выходит за рамки наших языков, поэтому нам нужно написать код Java, который может вызывать стороннюю библиотеку PDF для выполнения этой специализированной функции. Требуются два артефакта:

Во-первых, дополнительная модель службы, как показано ниже, в Service DSL, которая определяет интерфейс конкретной службы, чтобы к ней можно было получить доступ на уровне моделирования. Модель обслуживания описывает расположение реализации и входные и выходные атрибуты.

  <сервис имя ="buildPdfFromSurveyResponse" двигатель ="Ява"    расположение ="org.ofbiz.content.survey.PdfSurveyServices"    invoke ="buildPdfFromSurveyResponse">    <атрибут имя ="surveyResponseId" режим ="В"      необязательный ="ложный" .../>    <атрибут имя ="outByteWrapper" режим ="ВНЕ"      необязательный ="ложный" .../>  </service>

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

  общественный статический карта buildPdfFromSurveyResponse  (DispatchContext dctx , карта контекст) {    Строка мне бы = (Строка) контекст.получить("surveyResponseId");    карта Результаты = новый HashMap();    пытаться {      // ... ответ получен из базы данных ...      // ... pdf создается из ответа ...      // ... PDF-файл сериализуется как массив байтов ...    ByteWrapper outByteWrapper = ...;    Результаты.положил("outByteWrapper",outByteWrapper );    } ловить (Исключение е) {}    вернуть Результаты;  }

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

Проблема координации

Этот пример иллюстрирует некоторые преимущества использования нескольких языков при разработке. Однако есть и трудности, связанные с таким развитием. Эти трудности проистекают из наблюдения, что чем больше видов артефактов мы вводим в наш процесс, тем больше требуется координации усилий разработчиков. Мы будем называть эти трудности Проблема координации. Проблема координации имеет концептуальный и технический аспекты. Концептуально основная проблема - понять разные языки и их взаимодействие. Чтобы правильно проектировать и координировать модели на нескольких языках, разработчики должны иметь достаточное понимание того, как языки взаимодействуют. Технически основная проблема заключается в обеспечении согласованности. Должны быть предоставлены инструменты для раннего обнаружения несоответствий, то есть во время моделирования, и помощи разработчикам в устранении этих несоответствий. Далее мы рассмотрим эти два аспекта более подробно.

Координация как концептуальный вызов

Первая проблема, с которой сталкиваются разработчики при запуске разработки на нескольких языках, - это языковая какофония. Изучение разных языков и понимание их взаимодействия необходимо, чтобы понять сложный состав артефактов. В OFBiz framework, например, имеет семнадцать различных языков и более 200 000 строк кода предметно-ориентированного языка, поэтому сложность может быть огромной! В настоящее время не существует установленного метода описания различных языков, который позволял бы разработчикам быстро прийти к практическому пониманию. Инструменты важны здесь как для этого случая механизм для обучения и исследования, потому что разработчики обычно используют инструменты для обучения путем экспериментов. Особенно полезны инструменты для предметно-ориентированных моделей в трех областях:

1. Понимание языка
2. Понимание языковых взаимодействий
3. Понимание того, как использовать языки

Во-первых, понимание языка может быть трудным, и в случае предметно-ориентированных языков на основе XML частым и интуитивным возражением является синтаксис имеет значение возражение. Этот аргумент можно сформулировать следующим образом: «Различные языки трудны для понимания и только усугубляют путаницу, потому что их синтаксис, основанный на XML, особенно многословен и непонятен. Было бы лучше использовать единый язык общего назначения, такой как Java, потому что тогда разработчики могли бы полагаться на синтаксис, который они уже знают ». Хотя это возражение, безусловно, важно, оно упускает из виду центральный момент. XML или аналогичный формат представления может не быть синтаксисом, с которым фактически работают разработчики. Одним из преимуществ использования предметно-ориентированных языков на основе XML является то, что мы можем предоставить редакторы для предметной области. На рисунке ниже показано, как может выглядеть гипотетический редактор Entity DSL. Этот редактор представляет домен в простой и визуально привлекательной форме, но может очень хорошо использовать представление XML (и, возможно, конфигурацию макета) внизу.

Точно так же, как мы можем жаловаться на то, что XML - плохой выбор, мы также можем возразить, что язык общего назначения, такой как Java, является плохим выбором для некоторых задач. Более того, разработчики могут чувствовать себя менее запуганными редактором на рисунке, чем листингами кода в XML или Java. Если мы примем это синтаксис имеет значение тогда использование разных языков с специализированными редакторами становится разумной стратегией. Простота редактора делает язык более понятным и, следовательно, более простым в использовании. Другими словами, синтаксис имеет значение возражение может быть самой причиной того, что мы исследуем сферу Доменные языки.

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

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

В-третьих, чтобы понимать использование языка, мы должны уметь отличать правильные операции редактирования от неправильных в нашей среде разработки. Традиционные среды разработки уже давно служат руководством при написании программы. Инкрементальная компиляция позволяет среде предлагать разработчику подробные предложения, например, как завершить оператор. Существуют и более навязчивые виды указаний, например, синтаксически ориентированные редакторы, в которые можно вводить только ввод, соответствующий грамматике. Общие текстовые редакторы, которые можно параметризовать с помощью грамматики языка, существуют уже давно.^[3]

Существующие редакторы не принимают во внимание отношения согласованности между языками при предоставлении рекомендаций. В предыдущем примере идеальный редактор должен, например, иметь возможность предлагать сервис createSurvey как допустимое значение, когда разработчик редактирует целевой атрибут в определении формы. Среда, которая могла бы рассуждать об артефактах с разных языков, также могла бы помочь разработчику определить состояния программы, в которых была локальная, но не глобальная согласованность. Такая ситуация может возникнуть, когда модель правильно сформированный и, следовательно, локально согласован, но в то же время нарушает межъязыковые ограничения. Руководство или интеллектуальная помощь в форме предложений о том, как завершить модель, будут полезны для установок с несколькими языками и сложными ограничениями согласованности. Предлагаемые инструментами операции редактирования могут упростить для разработчика начало процесса обучения использованию языков.

Координация как техническая проблема

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

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

Взаимосогласованность достигается, когда могут быть разрешены ссылки через языковые границы. Этот вид согласованности может быть далее подразделен на (1) согласованность от модели к модели и (2) согласованность от модели к коду. Согласованность модели к модели касается ссылочная целостность а также ограничения высокого уровня системы. в создать опрос Например, атрибут default-entity-name из списка Service относится к атрибуту name из списка Entity. Если мы изменим одно из этих значений без обновления другого, мы нарушим ссылку. Существуют и более высокоуровневые ограничения согласованности в разных моделях, как обсуждается ниже. В проекте могут быть определенные шаблоны или соглашения для именования и связывания элементов модели. Текущие среды разработки должны быть адаптированы к конкретным языкам с помощью написанных от руки подключаемых модулей или аналогичных механизмов, чтобы обеспечить согласованность между языками, такими как языки из предыдущего примера.

Согласованность между моделью и кодом является важным требованием при многоуровневой настройке. Когда модели дополняются фрагментами кода, как в построить PDF Например, необходимо проверить, что модели и код действительно поместиться. Частично это вопрос обеспечения того, чтобы мягкие ссылки между моделями и кодом не нарушались, аналогично ссылочной целостности в согласованности между моделями. Но это также вопрос обеспечения того, чтобы код не противоречил ожиданиям, установленным в модели. в построить PDF Например, модель указывает, что outByteWrapper всегда будет частью вывода, то есть ключ outByteWrapper помещается в карту результатов. Анализ кода показывает, что outByteWrapper будет частью вывода только в том случае, если перед строкой 10 не возникнет никаких исключений. Другими словами, некоторые возможные исполнения кода будут нарушать спецификацию на уровне моделирования. В более общем плане мы можем заявить, что многоуровневая настройка налагает очень тонкие ограничения на задействованные модели и фрагменты кода.

Решение проблемы координации

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

Метод согласования

Цель метода согласования^[1] состоит в том, чтобы решить проблему координации и тем самым обеспечить лучшую поддержку разработки на нескольких языках. Чтобы правильно оценить метод, важно понимать, что он не предписывает дизайн отдельных языков. Для этого уже предложено множество методов и инструментов.^[4][5] Этот метод предполагает наличие настройки с несколькими языками, зависящими от предметной области. При такой настройке можно применить метод. Метод состоит из трех шагов, как показано на диаграмме ниже. Каждый шаг состоит из пары частей, которые показаны на диаграмме в виде маленьких квадратов. Прямоугольники с пунктирными линиями представляют автоматические процессы, а прямоугольники со сплошными линиями - ручные. Далее мы объясним эти шаги более подробно.

Шаг 1: идентификация

Цель этапа идентификации - выявить языковые совпадения. Как описано в примере, перекрытие - это область, в которой пересекаются проблемы двух языков. В мягкие ссылки Примеры таких совпадений - от Form DSL к Service DSL и от Service DSL к Entity DSL в сценарии использования создания опроса. Другой пример - случай, когда настраиваемый фрагмент кода используется для расширения модели. Такое совпадение часто встречается, когда выразительность языков общего назначения необходима для реализации специализированных требований, выходящих за рамки модели. Этап идентификации может быть ручным или автоматическим в зависимости от сложности перекрытий. Когда совпадения идентифицированы и сделаны явными, эта информация используется в качестве входных данных для второго шага метода: шага спецификации.

Шаг 2: спецификация

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

Шаг 3: приложение

Цель этапа приложения - воспользоваться координационной моделью. Координационная модель позволяет инструментам извлекать три уровня полезной информации. Во-первых, модель координации может использоваться для обеспечения согласованности на нескольких языках. Модель координации определяет отношения согласованности, например, как элементы из разных языков могут ссылаться друг на друга. Инструменты могут обеспечивать ссылочную целостность и выполнять статические проверки окончательной системы перед развертыванием. Во-вторых, отношения согласованности используются для навигации, визуализации и отображения Интернета на разных языках в настройках разработки. Эта информация используется для быстрого связывания элементов с разных языков и обеспечения прослеживаемости между различными моделями. В-третьих, на основе отношений согласованности и навигационной информации о том, как связаны элементы, инструменты могут предоставить руководство, в частности, завершение или помощь. Завершение модели, например, может быть обеспечено универсальным образом для инструментов, специфичных для предметной области.

Оценка метода согласования

Метод согласования^[1] лучше всего рассматривать как концептуальную основу, которая предписывает определенный рабочий процесс при работе с несколькими языками. Три последовательных шага, составляющих этот рабочий процесс, не поддерживаются интегрированной рабочей средой или средой разработки.Основное внимание уделяется расширению существующих сред разработчика для добавления поддержки (1) идентификации, (2) спецификации и (3) приложения. Основным преимуществом этого подхода было то, что разработчики фактически протестировали нашу работу и предоставили нам отзывы. Такая оценка метода ценна тем, что снижает риск решения чисто гипотетической проблемы. В нескольких статьях представлены различные этапы метода координации, отчет об этой оценке и подробно описаны технические аспекты каждого отдельного эксперимента. В целом результаты были многообещающими: в производственных системах было обнаружено значительное количество ошибок, что привело к конструктивному диалогу с разработчиками о будущих требованиях к инструментам. Процесс разработки, основанный на этих принципах и поддерживаемый инструментами, представляет собой серьезную попытку решить проблему координации и сделать многомодельное моделирование для конкретной предметной области практическим предложением.

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

• Доменный язык
• Доменно-ориентированное моделирование
• Модельно-ориентированная инженерия

использованная литература