Автореферат (1145119), страница 5
Текст из файла (страница 5)
Объем кода длякаждой трансформации составил не более 50 строк на ATL. В случае разработки навигационных сервисов «вручную» потребовались бы значительные усилия на интеграцию такого кода с кодом сгенерированного редактора, и, кроме того, реализация содержала бы много однотипного кода по работе с коллекциями, который плохо поддаётся повторному использованию с помощью стандартных средств.
Сложность разработки трансформаций измерялась с помощью метрики, имеющей следующие значения: использование только базовых знаний ATL (легко, Л), необходимость знаниястандартных конструкций ATL (средне, Ср), необходимость глубокого знания ATL(сложно, С). Из 12 созданных трансформаций 2 имели сложность Л, 6 — сложностьСр, 4 — сложность Сл.Алгоритм слияния и-карт. Данный алгоритм является составной частью стратегииверсионного контроля, необходимость которого для DSM-решений обоснована в Методологии.
В данной работе использовался известный 3DM-алгоритм слияния XMLфайлов. Алгоритм был модернизирован следующим образом: (i) было реализовано18разрешение конфликтов слияния по умолчанию; (ii) конфликт Delete/Move автоматически разрешался в пользу сохранения информации (Move); (iii) сливаемые версиибыли неравнозначны (были выделены серверная и локальные версии), при разрешении конфликтов в автоматическом режиме предпочтение отдавалось серверной версии; (iv) информация о конфликтах сохранялась и использовалась в расширенном режиме (пользователь может исправить результат автоматического разрешения конфликтов); (v) edit-скрипт преобразовывал серверную версию (а не исходную) в целевую; (vi) была изменена процедура идентификации 3DM-алгоритма: использоваласьметрика близости для элементов, имеющих общее происхождение (использовалосьQ-расстояние между строками).
Предложенный алгоритм был реализован для системы Comapping. Для него был также спроектирован и реализован пользовательскийинтерфейс работы с конфликтами.Реализованный алгоритм был применён для сбора информации и начальной формализации требований в трёх индустриальных проектах. Измерялись следующие показатели (в скобках после каждого показателя приводятся цифровые данные для каждого из трёх исследованных проектов): количество узлов и-карты (439, 119, 206), максимальная глубина дерева (11, 5, 7), общий объем текста в и-карте (количество слов— 3903, 328, 811), количество участников процесса групповой работы (4, 3, 2), количество выполнений процедуры слияния (12, 5, 8). Несмотря на то что предложенныйалгоритм слияния запускался относительно нечасто, его наличие, по мнению разработчиков анализируемых проектов, обеспечивало надёжность процесса и сохранность собираемых данных.Метод конт роля качест ва визуальных спецификаций.
Известно, что предметноориентированный язык, реализованный с помощью стандартного инструмента моделирования (UML-пакет, ARIS, Mega пр.), имеет много ограничений, которые инструмент контролировать не в состоянии. С другой стороны, если предметно-ориен-тированный язык задаётся с помощью метамодели и далее реализуется с помощью DSMплатформ типа MetaEdit и GMF, генерирующих целевой графический редактор по метамодели, то с помощью метамодели затруднительно задать все особенности языка.В качестве примера можно привести спецификацию самого UML, в которой метамодель сопровождается большим количеством дополнительных ограничений.
Для ихспецификации целесообразно использовать декларативный язык OCL. Если говоритьо промышленных решениях, то для обоих обозначенных выше случаев общепринятойиндустриальной практикой является создание проверочных скриптов, которые будутавтоматически контролировать эти ограничения для реальных моделей. Авторомпредложен метод разработки таких скриптов и создания итогового валидатора, имеющего единый интерфейс запуска и работающего в режиме средств Build Management.
Предложена также методика и архитектура средств для поддержки разработкиограничений корректности на языке OCL с последующей генерацией кода целевого19валидатора. Автором также предложена идея включать в область проверки не толькомодели, но и способы их представления, в частности, проверять соблюдение правилразмещения элементов модели и диаграмм по различным папкам репозитория, атакже состав диаграмм на соблюдение некоторых правил, не контролируемых инструментом моделирования.
Предложенная архитектура была реализована с применением пакета Dresden OLC Toolkit. С помощью созданной технологии было разработано два целевых валидатора для двух промышленных проектов. Первый проектиспользовал диаграммы конечных автоматов для спецификации алгоритмов семейства телекоммуникационных систем с автоматической генерацией программногокода по диаграммам (использован инструмент моделирования Real). Второй проектиспользовал предметно-ориентированное моделирование для описания ИТ-архитектуры крупной нефтегазовой корпорации (использован инструмент моделированияARIS).
В диссертационной работе представлена расширенная метамодель для этогопримера, а также соответствующие OCL-ограничения. Чтобы обосновать эффективность предложенного метода, для последней апробации вместе со сгенерированнымвалидатором была выполнена «ручная» реализация соответствующих проверочныхскриптов, которую автор сравнил с автоматически сгенерированным валидатором.Измерялись следующие параметры: сложность разработки, объем кода и время работы. Сложность разработки OCL-ограничений оценивалась по следующей шкале:лёгкая (Л) — использование простых базовых конструкций OCL; средняя (Ср) — добавляются итераторы и процедуры; сложная (С) — создание больших спецификаций(по 20–50 строк) и использование OCL в полном объёме.
Из 11 рассмотренных ограничений 6 имели сложность Л, 5 — С, сложных не оказалось. Время работы сгенерированного валидатора на репозитории в 27 мегабайт (рабочий репозиторий КИТ-проекта, содержащий полное описание модели ИТ-архитектуры корпорации) составило35 минут. С учётом того что эксперименты проводились на виртуальной машине, в товремя как целевой валидатор должен работать на высокопроизводительном сервере,данная производительность оказывается приемлемой. С дальнейшим обсуждениемданного вопроса можно ознакомиться в тексте диссертационной работы.Четвёртая глава описывает созданные автором средства анализа, проектированияи разработки специализированных классов ПО, а также отдельных рабочих продуктовпроцесса разработкиПО,основанныхнапредметно-ориентированноммоделировании — см.
соответствующие виды DSM-решений, определённые в Методологии. Рассмотрим эти результаты.FSS-метод. Метод предназначен для анализа предметной области в контексте разработки ПО, реализующего государственные/публичные сервисы в некоторой предметной области (например, в контексте русско-финского приграничного сотрудничества или жилищно-коммунальное хозяйство Санкт-Петербурга).
Необходимость специального метода обусловлена большим количеством информации, которая должна20быть учтена при разработке такого ПО. Схема метода представлена на рис. 3. Отметим, что в рамках FSS-метода целевая Web-система может получаться как результатгенерации программного кода по моделям. При генерации кода главным является использование метафор Web-визуализации.
Такая метафора представляет собой схемуфрагмента пользовательского интерфейса, которая поддержана соответствующимуниверсальным кодом, который, в свою очередь, параметризуется данными из предметной области. Создание итогового кода производится специальным генератором.Однако программная поддержка метафор в рамках FSS-метода не входит в рамки данного исследования.На рис. 4 приведён пример модели документов. В этом примере сокращённо изображено дерево документов для выдачи загранпаспорта.
Начальным (центральным) узлом диаграммы является Input_Documents. Непосредственно с этим узлом связаныдокументы «Анкета», «Старый загранпаспорт», «Фотография для анкеты», «Квитанция об оплате госпошлины», которые обязательны для всех заявителей. Далее имеется два групповых узла – «До 18 лет» и «От 18 лет», поскольку дальнейшие документы, которые необходимо подать на загранпаспорт, зависят от этого параметра заявителя.Онтологияпредметной областиЗаконы инормативныеактыМодель процессовОписательная модельГенерацияМодельдокументовВнесениеизмененийЮристы иофициальныедолжностные лицаСпецификация сервисовМетафорыWebвизуализацииДоработкасистемыАналитикиЦелевая Web-системаРазработчикисервисовПользователисервисовРис.
3. Схема FSS-методаС узлом «От 18 лет» связаны документы «Дополнительная анкета», «Дополнительная фотография», «Паспорт гражданина РФ» и др., обязательные для заявителейстарше 18-ти лет. У этих заявителей имеется группа документов, зависящая от отношения к воинской обязанности. Здесь возможны следующие ситуации – «Отслуживший», «Военнослужащий», «Призывник». С узлами дерева могут быть также связаны21инфоблоки (InfoBlocks), с помощью которых задаётся дополнительная информация оситуации или о документе.Модель средств разработки семейств программно-аппаратных систем, создаваемых на основе компоновки аппаратной части. Опишем целевой класс приложений,на который ориентирована модель: (i) может быть создана общая база знаний оборудования продуктов семейства; (ii) может быть создан программный конструктор семейства, и целевые продукты семейства строятся на основе его компонент; (iii) программное обеспечение целевых систем в значительной степени определяется конфигурацией их аппаратной части.Для разработки таких систем предлагается следующая модель.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
