Итак, под Multiplatform я предполагаю, что вы имеете в виду «должен работать в нескольких гетерогенных системах».
Вы столкнетесь с проблемой определения и реализации:
- Бизнес логика
- Пользовательский интерфейс
- Модели данных
- Связь между приложениями для управления распределением
Если вы будете следовать статье Voelter, вам нужно что-то, чтобы описать «архитектуру», а именно
как элементы каждой из этих частей составлены для достижения целого.
Если все ваши платформы не обслуживаются одним набором готовых технологий
(например, J2EE или что-то подобное), и он имеет большой срок службы, вы можете отделить спецификацию
из этих артефактов от их реализации.
(Если вам повезет, вы можете выбрать общий
язык, такой как Java, C # или C ++ для бизнес-логики и как цель компиляции для других DSL. Если вы сделаете это, конечно, будет соблазн закодировать все это на одном языке; если вы это сделаете, вы, вероятно, застрянете при следующем обновлении технологии, и, вероятно, их будет несколько в течение жизненного цикла этого приложения).
Чтобы отделить спецификацию и реализацию, вам понадобится набор DSL для описания этих спецификаций и соответствующий набор компиляторов DSL для каждой из платформ, чтобы все составляющие составляли
, Это означает, что вы, скорее всего, не сможете получить DSL из разнородных источников; нет никаких оснований полагать, что их сгенерированные результаты составляют. Таким образом, вы, вероятно, застряли, определяя эти и переводы реализации. Это не простая задача.
Но ни то, ни другое не создает долгоживущее мультиплатформенное приложение.
Существует ряд инструментов, которые можно использовать для реализации таких DSL. В другом ответе предлагается EBNF, который, на мой взгляд, необходим для описания DSL, и генераторы синтаксических анализаторов, которые, на мой взгляд, необходимы, но вряд ли достаточны.
Более совершенные механизмы реализации общего назначения Инструменты преобразования программ :
Все три из них позволят вам определить собственный синтаксис EBNF для различных DSL и построить преобразования, чтобы отобразить их для вас на различных платформах. Чтобы использовать их, вы, как правило,
вам нужны описания EBNF target языков, которые составляют несколько платформ, потому что
эти системы работают путем преобразования конструкций в вашем DSL в конструкции в целевом языке (ах) с использованием методов преобразования абстрактного синтаксического дерева. Каждый из них имеет различную степень доступности готовых описаний целевых языков. (Мы усердно работаем с DMS, чтобы удостовериться, что хорошо изучили часто используемые целевые языки).
Ничто из этого не выведет вас из тестирования. Вам нужно будет по крайней мере написать тесты на уровне спецификации, если не что иное, чтобы словарь / реализация тестов не были привязаны к конкретной платформе. Тесты должны быть как-то скомпилированы для запуска; если они закодированы в терминах DSL и у вас есть компиляторы DSL, их можно скомпилировать в (несколько) реализаций и запустить для проверки приложения, закодированного в DSL.
РЕДАКТИРОВАТЬ 31.10.2011: ОП намекает, что он хочет что-то еще; при чтении вопроса, кажется, есть некоторый акцент на DSL для спецификации архитектуры (статья Voelter). Самое близкое, на что я могу прийти, это обзор работ по Module Interconnection Languages (MIL) ; каждый из них является DSL и требует чего-то подобного описанному выше. Больше требуется с MIL; вам нужен способ применять его правила, иначе программисты проигнорируют все, что вы в нем напишите. Вы также можете использовать различные системы преобразования для реализации правоприменения, читая MIL и различные исходные коды, составляющие программное обеспечение. В идеале вы должны прочитать MIL и спецификации кода (при условии, что генераторы кода производят код, соответствующий спецификациям).