Автореферат (1145119), страница 4
Текст из файла (страница 4)
Поэтому при создании DSM-решений общепринятых практик разработки ПО недостаточно, и требуются дополнительные средства. Именно таким средством являетсяпредлагаемая модель процесса разработки (рис. 2). Кратко опишем эту модель.13ВыработкаконцепцииИдея,требования,бюджет12Спецификация поставки DSMрешенияОпределениезаказчикаСпецификацияязыка ипримеровКоманда,инфраструктура, рискиРазработка ииспользованиеПланированиеВыбор DSMплатформыОпределение дополнительнойфункциональности4РазработкаИтерации разработки3Итерации разработкиСтабилизацияПередача5ПередачаинфраструктурыНадзорЭксплуатация исопровождение6Рис.
2. Сценарий разработки DSM-решения (модель процесса разработки)Выработ ка концепции. На этом этапе происходит создание и оформление идеиDSM-решения, определяются верхнеуровневые требования, бюджет, а также заказчик проекта; создаётся команда и инфраструктура проекта, определяются риски. Планирование — спецификация итоговой поставки DSM-решения, разработка и формализация языка моделирования, выбор DSM-платформы. Определение дополнительной функциональности решения: во-первых, рассматриваются вопросы качества — цена ошибок в моделях, необходимость дополнительных средств; во-вторых,определяются требования к версионированию моделей (в частности, процедуре слияния); в-третьих, решаются вопросы работы с большими моделями — средства декомпозиции, навигации, создания отчётов (в частности, Web-отчётов) и поддержкидисциплины/процесса разработки/сопровождения моделей; в-четвертых, рассматривается интеграция DSM-решения с окружением.
Разработ ка — создание работоспособной версии DSM-решения, стабилизация версии и передача её пользователям. Разработка выполняется итеративно с использованием метода Scrum. Разработ ка и использование — дальнейшая разработка решения, совмещённая с его использованием.DSM-решения часто создаются в контексте других проектов, и результаты требуютсяв кротчайшие сроки. Передача — сдача проекта и перевод его в режим поддержки и14сопровождения. Эксплуат ация и сопровож дение — обеспечение непрерывной поддержки DSM-решения: исправления ошибок, реализация новой функциональности,своевременный перенос решения на новые версии DSM-платформы, миграция моделей пользователей.Для каждого шага/элемента Методологии предлагается набор методов, моделей иалгоритмов.
Предполагается, что дальнейшие исследования в области предметноориентированного моделирования могут быть структурированы в рамках предложенной Методологии (в частности, могут быть созданы дополнительные модели процесса разработки DSM-решения).Третья глава описывает созданные автором новые модели, методы и алгоритмы,посвящённые разработке дополнительных функциональных компонент DSM-решений, определённых в рамках Методологии: работа с большими моделями, версионный контроль, поддержка качества визуальных спецификаций.
Представленные результаты облегчают практическое решение данных задач и показывают направлениедальнейших исследований. Рассмотрим эти результаты.Модель v2v-трансформаций. Данная модель посвящена созданию средств работыс большими моделями; необходимость этих средств была обоснована в Методологии.Пусть у нас имеется метамодель ℳ, определяющая некоторый язык моделирования.Определим метамодель как ℳ = 〈, ℐ, 〉, где — это множество основных элементов метамодели (типов сущностей и ассоциаций); ℐ — отношения наследованиямежду элементами , то есть ℐ ⊂ × ; — множество атрибутов элементов из .Пусть T = t1 , … t n — это набор статических представлений (видов диаграмм) данного языка моделирования.Определим модель как M = 〈E, A, φ〉, где E — это множество объектов и связеймодели (экземпляров элементов из ), A — значения атрибутов объектов, а φ: E ⟶ является функцией, сопоставляющей каждому элементу модели соответствующийтип в метамодели.
Будем обозначать как M ≻ ℳ тот факт, что модель M являетсякорректным экземпляром метамодели ℳ (функция φ этого не обеспечивает, так какэлементы соответствующих типов могут быть неправильно соединены, могут такжене выполняться различные ограничения на модели, сформулированные с помощьюOCL).Пусть у нас есть некоторая выборка элементов из модели. Тогда параметры отображения — это задание наличия в выборке атрибутов сущностей, например, показывать или нет атрибуты и методы класса, а если показывать, то следует ли отображатьзначение видимости и т.д.Определим множество всех возможных значений параметров отображения для элемента метамодели θ ∈ ℳ на выборках вида t , где t ∈ T, как DOθ,t (DO являетсясокращением от Display Options). Если DOθ,t = ∅, значит, элементы типа θ в выборки данного типа не входят.
Набор конкретных значений параметров отображения15элемента модели ∈ в выборке вида t будем обозначать doe,t . При этом doe,t ∈DOθ,t , где θ = φ(). Если DOθ,t = 1, значит, элементы вида θ отображаются в выборках типа t единственным образом.DOℳ,t = � DOθ,t , DOℳ = � DOℳ,t .θ ∈ℳt∈TОбозначим через ℳ метамодель динамических представлений, определяющуюструктуру выборок из моделей, с которыми пользователь может работать посредством диаграмм.
Динамическое представление — это выборка из модели вида t, гдеt ∈ T, которая может содержать повторы элементов модели, и каждый элемент этойвыборки содержит параметры отображения. Фактически, ℳ дополняет элементыℳ возможными параметрами отображений в соответствии с видами статическихпредставлений (элемент метамодели на диаграммах различных видов может иметьразличные виды параметров отображений, например, класс на диаграмме классов идиаграмме объектов). Формально определим ℳ как 〈ℳ, T, DO〉, где DO ⊂ ℳ ×T × DOℳ . Определим динамическое представление следующим образом:v = 〈t, M, Δ, ψ, β〉,где t ∈ T (то есть динамическое представление определяется для выборок вида t итаким образом t будем называть видом v), Δ является множеством элементов динамического представления модели M, ψ: Δ ⟶ E является функцией и позволяет определить, какому элементу модели соответствует данный элемент представления, β:Δ ⟶ DOℳ,t является функцией, действующей из множества элементов представления в множество всех возможных параметров отображения в выборках вида t, приэтом верно следующее утверждение: ∀ d ∈ Δ (β(d) ∈ DOψ(d),t ).
Таким образом, динамическое представление является выборкой из модели с повторами, и, кроме того,каждый из элементов этой выборки имеет набор параметров отображения. Множество всех возможных динамических представлений вида t для метамодели ℳ определим следующим образом:Vt = � { v | где вид v равен t}.M ≻ℳДиаграмма отличается от динамического представления тем, что всем элементампоследнего добавляются графические свойства (Graphical Options) – координаты фигуры, цвет и толщина линий фигуры и фона, параметры шрифтов и т.д. Пусть имеетсядиаграмма вида t, будем обозначать графические свойства элемента диаграммы d какgod,t .
Множество всех возможных графических свойств элементов диаграмм вида tопределим так:16GOt = � {god,t }.d ∈ VtРассматривая v2v-трансформации выделим следующие случаи: трансформации,действующие на фиксированном множестве элементов модели/диаграммы (далее —трансформации первого вида) и трансформации, применяемые ко всей диаграммецеликом (далее — трансформация второго вида).
Примерами для первого случаямогут служить все трансформации, применяемые к одному элементу (таких трансформаций оказывается большинство). Существенно меньше трансформаций, которыеможно задать для пары элементов. В качестве примера можно указать на случай, когда требуется определить все возможные пути в графе между двумя элементами(например, двумя состояниями в диаграммах состояний и переходов или для двухклассов на диаграмме классов). Для второго случая приведём пример, когда для классов всей диаграммы предложено изображать атрибуты и не изображать методы. Приэтом неизвестно, сколько именно будет классов.
Отметим, что трансформации обоихвидов не меняют модель.Формально определим v2v-трансформацию для первого случая. Определим подмножество модели M, состоящее из всех элементов, соответствующих некоторомутипу метамодели θ: M θ = {e ∈ M: φ(e) = θ }. Будем обозначать декартовое произведение нескольких таких множеств, определённое для одной модели M, следующим образом:� Mθi .=1..Определим функцию на отрезке натуральных чисел от 1 до n: : 1.
. ⟶ .Для фиксированной метамодели ℳ, t ∈ T и функции определим трансформациюпервого вида как функцию следующего вида:tr1ℳ,t,ζn ∶ � Mζn(i) ⟶ Vt ,=1..при этом M ≻ ℳ и принимает все возможные значения. Необходимо отметить, чтотрансформация может быть применена как к элементу модели (и тогда для него создаётся соответствующая выборка вида t, которая потом отображается на отдельнойдиаграмме), так и к элементу диаграммы. В последнем случае вид выборки не важен,поскольку в качестве аргумента нас не интересуют параметры отображения элементов модели, к которым применяется трансформация: например, если требуется отобразить для класса значение его атрибутов, включая значения видимости и значенияпо умолчанию, то не имеет значения, как данные атрибуты отображались до этого.Сделаем ещё одно замечание: трансформация действует на элементах модели с повторениями, так как можно, например, запросить построение всех путей из элементамодели в него же.17Теперь определим трансформацию второго вида как функцию следующего вида:tr2ℳ,t1,t2 ∶ Vt1 ⟶ Vt2 ,где t1 , t 2 ∈ T.
Таким образом, трансформация второго вида действует на все динамическое представление вида t1 , преобразуя его в представление вида t 2 . В большинствеслучаев t1 = t 2 .Определим навигационный сервис как следующую тройку:• v2v-трансформация;• спецификация элементов пользовательского интерфейса для задания параметров сервиса (диалоговое окно) и вызова сервиса: пункт контекстногоменю элемента на диаграмме, кнопка на панели инструментов, пункт главного меню и пр.;• алгоритм раскладки (layout algorithm), который изменяет графические свойства, но не меняет состав динамического представления.Для задания v2v-трансформаций предложено использовать язык трансформацийATL.
В работе представлена реализация подхода с помощью DSM-платформы GMF.Для выполнения трансформаций использована технология ATL, для выполнения раскладок — технология KIELLER. С помощью получившейся технологии был реализован редактор классов и 12 основных трансформаций диаграмм классов. Были проведены измерения эффективности этих трансформаций по следующим критериям: производительность, объем кода, сложность кода.
Производительность измерялась длядиаграммы размером в 100 классов и 90 связей и составила 2–3 секунды для каждогонавигационного сервиса. Основная работа уходила на подготовку и загрузку/выгрузку данных, ATL-трансформация исполнялась меньше секунды.