Мультимодельное моделирование в зависимости от предметной области

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

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

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

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

Пример мотивации [ править ]

Корпоративных систем, основанных на нескольких предметно-ориентированных языках, предостаточно. Особенно широко распространены языки с метамоделью, определенной в Extensible Markup Language (XML). Чтобы проиллюстрировать разработку с использованием нескольких языков, мы возьмем пример из тематического исследования: система Apache Open For Business (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 Database Connectivity ,Enterprise JavaBeans или даже какая-то устаревшая система .

 <entity  entity-name = "Survey"  ...  title = "Survey Entity" >  <field  name = "SurveyId"  type = "id-ne" />  <field  name = "surveyName"  type = "name" />  < field  name = "description"  type = "description" />  <field  name = "comments"  type = "comment" />  <field  name = "submitCaption"  type = "short-varchar" />  <field  name = "responseService"  type = "long-varchar" /> <field  name = "isAnonymous"  type = "indicator"  ... />  <field  name = "allowMultiple"  type = "indicator"  ... />  <field  name = "allowUpdate"  type = "indicator"  ... / >  <field  name = "acroFormContentId"  type = "id-ne"  ... />  <prim-key  field = "SurveyId" />  </entity>

Сервисный DSL [ править ]

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

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

 <service  name = "createSurvey"  default-entity-name = "Survey"  ...  location = "org / ofbiz / content / survey / SurveyServices.xml"  invoke = "createSurvey" > ... <имя-  службы- разрешения = "contentManagerPermission"  main-action = "CREATE" />  <auto-attributes  include = "nonpk"  mode = "IN"  optional = "true" />  <auto-attributes  include = "pk"  mode = "OUT"  optional = "ложный"/>  </service>

Форма DSL [ править ]

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

 <form  name = "EditSurvey"  type = "single"  target = "updateSurvey"  title = ""  default-map-name = "survey" >  <alt-target  use-when = "survey == null"  target = "createSurvey" />  <auto-fields-service  service-name = "updateSurvey" />  <field  use-when = "Survey ! = null"  name = "SurveyId"  ...  /> ... <field  name = "isAnonymous" >  <раскрывающийся  список no-current-selected-key = "N"  allow-empty = "false" >  <option  key = "Y" /> <option  key = "N" />  < / раскрывающийся список>  </field> ... <field  name = "submitButton"  title = "$ {uiLabelMap.CommonUpdate}"  widget-style = "smallSubmit" >  <submit  button-type = "button" />  </field>  </form>

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

Многоуровневая настройка [ править ]

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

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

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

 <service  name = "buildPdfFromSurveyResponse"  engine = "java"  location = "org.ofbiz.content.survey.PdfSurveyServices"  invoke = "buildPdfFromSurveyResponse" >  <attribute  name = "surveyResponseId"  mode = "IN"  optional = "false"  .. . />  <attribute  name = "outByteWrapper"  mode = "OUT"  optional = "false"  ... />  </service>

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

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

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

Проблема координации [ править ]

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

Координация как концептуальная задача [ править ]

Первая проблема, с которой сталкиваются разработчики, начиная разработку на нескольких языках, - это языковая какофония . Изучение разных языков и понимание их взаимодействия необходимо, чтобы понять сложный состав артефактов. OFBiz рамки, например , имеет семнадцать различных языков и более чем 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) приложения. Основное преимущество этого подхода состоит в том, что разработчики фактически протестировали нашу работу и предоставили нам отзывы. Такая оценка метода ценна тем, что снижает риск решения чисто гипотетической проблемы. В нескольких статьях представлены различные этапы метода координации, отчет об этой оценке и подробное описание технических аспектов каждого отдельного эксперимента. В целом результаты были многообещающими:В производственных системах было обнаружено значительное количество ошибок, что привело к конструктивному диалогу с разработчиками о будущих требованиях к инструментам. Процесс разработки, основанный на этих рекомендациях и поддерживаемый инструментами, представляет собой серьезную попытку решить проблему координации и сделать многомодельное моделирование для конкретной предметной области практическим предложением.

См. Также [ править ]

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

Ссылки [ править ]