Диссертация (1145120), страница 20
Текст из файла (страница 20)
В. Парфёнов, А. Н. Терехов, П. С. Лавров и др. [133], [145].Они предложили описывать схему семейства продуктов (набор базовых классов, каналы,интерфейсы и сообщения) с помощью специальной версии языка Algol68, созданной ими,а поведение классов — с помощью конечных автоматов языка SDL, где код в SDLсимволах создавался на той же версии Algol68. Линейка функционировала более 20 лет, сеё помощью были созданы десятки целевых систем.108[263], которые образуют единый цикл работ и посвящены вопросу разработки фабрик ПО (software factories). Фабрика ПО определяется как линейкапродуктов, использующая шаблон фабрики, основанный на схеме фабрикидля разработки и поддержки вариантов продуктов семейства с помощьюадаптации, сборки и конфигурирования базовых компонент.
Схема фабрики— это классификация всех активов фабрики, а также связей между ними.Конкретный продукт получается выборкой (разрешением) этих связей. Шаблон фабрики — это реализация обозначенных в схеме активов. При этом авторы подхода важную роль отводят предметно-ориентированному моделированию, предлагая создавать соответствующие визуальные языки и поддерживающие их программные средства для разработки повторно используемыхактивов.
Выдвигаются требования к программным средствам поддержки таких языков — наличие графического редактора, генератор кода, отладчик(чтобы отлаживать приложения в терминах предметно-ориентированногоязыка), средства для иных видов использования информации из моделей —генерация и исполнение тестов, конфигурационное управление и пр.Приэтом предлагается в большей степени настраивать и дорабатывать существующие языки и средства, чем создавать новые. Монография подробно обсуждает особенности моделирования в рамках разработки фабрик ПО, чего совсем не было у K. Czarnecki и U.
Eisenecker. Рассматриваются также особенности создания предметно-ориентированных языков, в частности, структураязыка разделяется на семантику, абстрактный, конкретный и служебный синтаксис. В целом монография всесторонне охватывает процесс разработкифабрик, но основывается на том, что имеются зрелые DSM-платформы (илибудут иметься в ближайшем будущем — авторы указывают, что DSMплатформы на момент выхода монографии — 2004 год — находятся ещё встадии разработки).
Разработка DSM-решений в монографии не рассматривается — специально подчёркивается, что речь идёт о настройке и конфигурации имеющихся средств разработки. Соответственно, не рассматривается109жизненный цикл DSM-средств, не выделяется DSM-решение как отдельныйпродукт, не рассматриваются риски создания таких решений. Предметноориентированное моделирование рассматривается как одно из средств, ноосновная тема монографии — фабрики ПО.Работы совместной исследовательской группы университета города Ювяскюля и компании MetaCase (J.–P. Tolvanen, S. Kelly и др.) [300], [302], [303],[304], [305], [306], [374], [375], [440] и обобщающая их монография [301],изданнаяв2008году,продолжаютразвиватьтемупредметно-ориентированного моделирования как комплексного инструмента разработкиПО. При этом, в отличие от предыдущих работ, монография [301] сфокусирована на предметно-ориентированном моделировании как таковом и не рассматривает подробно контекст его применения.
При этом, несмотря на то,что в монографии даётся достаточно широкое определение предметной области, для которой может быть создано DSM-решение, представленный подходв целом ориентирован на генерацию программного кода по моделям. Этоследует как из примеров, подробно разбираемых в монографии, так и изопределения DSM-решения (DSM-solution). Последнее разбивается на следующие компоненты: предметно-ориентированный язык, генератор кода,окружение (domain framework), средства поддержки (графический редактор ипр.). Под окружением понимается дополнительный код, который необходимдля того, чтобы результат генерации мог работать35. Приводится обстоятельный исторический обзор DSM-платформ, рассмотрены имеющиеся на настоящий момент DSM-платформы, делается обзор функционала и разных задач,которые необходимо решать при разработке.
Такая концентрация на генерации кода по моделям сужает область применения DSM-решений, фактически,исключая поддержку с помощью DSM дополнительных видов активности35В средах поддержки языков программирования такой код называют динамической поддержкой или поддержкой периода исполнения (run time); такой код не генерируется поисходным спецификациям, а создаётся «вручную», в виде библиотеки, и обслуживает всесгенерированные спецификации.110процесса разработки — разработку документации, конфигурационное управления и пр., — а также других предметных областей, где востребованы иныеспособы формальной обработки моделей (например, генерация отчётов вуправлении архитектурами предприятий).
Также решения, где отсутствуютсредства формальной обработки (например, для анализа ПО), не подходятпод это определение.Процесс разработки DSM-решения в монографии J.–P. Tolvanen и S. Kellyопределяется неформально, однако в нём можно выделить четыре главныхэтапа: (i) проектирование, (ii) разработка, (iii) внедрение, (iv) поддержка исопровождение.
В первый этап входит процедура принятия решения об использовании DSM-подхода, организация проекта, создание концепции. Вовторой этап входит создание языка, создание примеров и разработка сценариев использования решения, проектирование и разработка генератора иокружения, пилотный проект. В третий этап входит изучение вопроса об изменениях в компании (речь о тех изменениях, которые будут необходимыпри внедрении DSM-решения), доработка решения (polishing), создание дополнительных средств (инсталляторов, механизмов обновлений, документации и пр.), учебные материалы и обучение. В четвёртый этап входит создание процесса сопровождения и команды сопровождения. Процесс определёночень неформально (например, в обзоре главы этапов не четыре, а три).
В целом, неформальность в определении базовых понятий свойственна данноймонографии. Такое изложение создаёт лёгкое первое впечатление от знакомства с материалом и хорошо воспринимается опытными людьми, но оставляет в стороне многие вопросы — использование различных моделей процессаразработки DSM-решения, точный набор рабочих продуктов финальной поставки, вопросы управления DSM-проектами, риски и пр. Тем более затруднён перенос концепций DSM-подхода в другие области, где востребованысредства визуализации и их программная поддержка.111Неформальный и явно недостаточный обзор рисков DSM-проектов в[301] авторы компенсируют в [302], обсуждая неуспешные DSM-практики.Их можно сопоставить с моделью рисков, предложенных автором в рамкахметодологии предметно-ориентированного моделирования.
Неуспешныепрактики разбиты на следующие категории: начальные установки — мнение, что создавать язык могут только гении; недостаток понимания предметной области; создание совершенного и полного языка; разработка концепции языка — специализация объёмного стандартногоязыка вместо создания небольшого и удобного языка «с нуля»; низкийуровень абстрактности языка (ориентация на специфические библиотеки и др.
концепции кода); чрезмерная ориентация на возможностиDSM-платформы; разработка языка — создание или слишком общего, или слишком специализированного языка (потеря баланса); слишком сильная ориентация на отдельные особенности предметной области (например, когда насоздание языка позволяют влиять слишком многим различным специалистам); нотация языка — использование предопределённых парадигм вместопривлечения широкого спектра возможностей (включая и невизуальные элементы нотации — матрицы, таблицы); упрощённые символы(использование простых, очень похожих или невыразительных символов); использование языка — игнорирование процесса использования языка;недостаток обучения; стагнация языка после успешного внедрения.Очевидно, что данные трудности фокусируются преимущественно, на создании языка.
Подобно исследованиям J. Greenfield [263], авторы данной статьи считают вопрос создания программной части DSM-решения само собойразумеющимся. Также не рассматриваются риски внедрения DSM-решений,112свойственные любым ИТ-проектам, но имеющие в данном случае специфику(работа с требованиями, идентификация заказчика, концепция решения).Лишь последняя категория трудностей — использование языка — касаетсяпроцесса использования DSM-решения и вопросов его сопровождения и поддержки.
Однако даже в этом случае, например, про стагнацию говорится всмысле языка, а не всего решения, в то время как для индустриальных DSMрешений актуальной оказывается legacy-тенденция, которая подробно обсуждается в предложенной в данной диссертационной работе модели рисков.Монографии [268] и [213] посвящены обстоятельному изложению двух известных DSM-платформ — Eclipse Modeling Project и Microsoft ModelingSDK. В первой монографии подробно излагаются технологии, входящие всостав Eclipse Modeling Project, и не уделяется внимания методологическимвопросам.
Во второй монографии рассматривается технология MicrosoftModeling SDK и затрагивается ряд методологических вопросов.DSM-решение определяется в [213] как предметно-ориентированный язык, доменная модель и средства программной поддержки. Процесс разработки DSMрешения определяется следующим образом: (i) обобщение приложения:определение вариативности, принятие решения об использовании DSM, основные идеи языка и его проекций в программный код; (ii) разработка предметно-ориентированного языка и доменной модели; (iii) разработка нотацииязыка; (iv) уточнение языка; (v) разработка генератора кода; (vi) использованиеязыка;(vii)эволюцияязыка.Вданномслучаепредметно-ориентированное моделирование понимается как инструмент работы с определённым программным продуктом, и в монографии нет места энциклопедичности. DSM-решение понимается в стиле «гибких» методов разработки— минимум документации и «тяжеловесных» артефактов — методов использования, обучения и пр.
DSM-решение понимается как средство удобной генерации конечного кода. Разработка решения рассматривается как разработка языка (даже говоря об использовании и эволюции решения, авторы ис113пользуют вместо термина «решение» термин «язык»). Подход непосредственно связан со средой программирования Microsoft Visual Studio и ориентирован на разработку несложных DSM-решений.Следует отметить, что предметно-ориентированное моделирование начинает активно применяться за пределами программной инженерии — см.,например, технологию QReal:ROBOTS, предназначенную для визуальногопрограммирования роботов старшеклассниками [114], а также работы по использованию визуального моделирования при разработке роботов — стартовавший в 2014 году семинар «Workshop on Model-Driven Robot SoftwareEngineering» [241], [354].
Известны также работы об использовании предметно-ориентированного моделирования в бизнес-инжиниринге [152], [155],[156], [158], [247], [312], и очевиден рост количества этих работ в последниедва–три года. Однако самая развитая отрасль в области предметноориентированного моделирования — программная инженерия — не предоставляет соответствующих обобщений для данных областей, и применениеDSM-подхода там оказывается хаотическим. Предложенная методологияснимает эту проблему.1142.6 ВыводыПодведём итоги. В данной главе предложена методология предметноориентированного моделирования, предназначенная для разработки инструментов анализа и проектирования программного обеспечения на основе визуальных моделей и предоставляющая средства для спецификации итоговойпоставки DSM-проекта, описывающая дополнительные функциональныекомпоненты, не реализованные существующими техническим средствами,включающая средства для создания процесса разработки и сопровожденияDSM-решения, а также для анализа рисков.
Новизна методологии заключается в следующем.1. Имеющиесянасегоднякомплексныеподходыориентированному моделированию [204], [301], [263]кпредметно-рассматриваютего неформально, в то время как предложенная методология формализует предмет исследования, двигаясь от энциклопедий подходов и методов к промышленным рекомендациям.2. Существующие подходы концентрируются, преимущественно, на генерации программного кода [204], [301], [263], [268], [213] и слабо затрагиваютдругиеспособыформальнойобработкипредметно-ориентированной спецификаций.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
