Диссертация (1145120), страница 29
Текст из файла (страница 29)
Ограничения на языке OCL удобно обсуждать. Так, например, объёмOCL-спецификаций, созданных для описания ограничений корректности, существенно меньше написанного JavaScript кода, как указывалосьвыше. Простота и наглядность языка OCL позволяют оценить спецификацию ограничений, акцентируясь на декларативной (спецификации), а не императивной (реализации) составляющей. Обсуждениеограничений на естественном языке — либо устно, либо на основе текстовых описаний, становится источником неточностей и ошибок, которые приходится исправлять впоследствии.1672.
Устранение неточностей в ограничениях на этапе OCL-спецификацийменее трудоёмко, чем, например, на JavaScript. Так, например, при разработке ограничения 11 (см. табл. 3.4) лишь при обсуждении OCLспецификации стало понятно, что диаграммы, матрицы и требованиямогут размещаться только в одной из двух папок.3. Автоматизированная разработка итогового валидатора позволяет единообразно решить вопрос с генерацией отчётов по результату проверокограничений, а также предоставляется интерфейс для пакетного управления валидатором.4.
Необходимо отметить, что генератор валидаторов показывает приемлемую производительность.Остановимся теперь на ограничениях данного метода.1. Следует признать, что практическое применение OCL продолжаетоставаться на уровне академических исследований и отдельных передовых промышленных проектов. В целом труднопреодолимой пока является задача использования в программном проекте нескольких языков программирования и в особенности — языков разных концептуальных уровней.
Однако данная проблема является общей относительно языков формальных спецификаций и формальных методов. В целомже проблемы практического использования формальных методов в индустрии активно обсуждается и исследуется в научном сообществе[310], [402], [444], [414].2. При использовании предложенного метода требуются также навыкиразработки метамоделей — следует отметить, что данные навыки нераспространены в индустрии, на что указывалось, в частности, в [205].Более того, если в DSM-проекте в качестве DSM-платформы используется стандартный инструмент моделирования, то метамоделирование168часто не требуется, и, соответственно, данная экспертиза в проекте может отсутствовать.3. Необходимо отметить трудоёмкость спецификации связывания метамодели с инструментом моделирования. Использование во второйапробации аннотаций на JavaScript сильно снижает эффективностьпрактического использования метода.
С другой стороны, можносо-здавать шаблоны таких аннотаций для конкретного средства моделирования, сильно снижая трудоёмкость использования подхода на множестве (линейке) подобных проектов, а также свободно распространяя этишаблоны для отдельных пакетов моделирования вместе с самим методом и соответствующим программным обеспечением. Необходимо отметить, что наличие такой линейки, то есть длящаяся необходимостьразрабатывать ограничения корректности для различных проектов — ижелательно, в рамках одного коллектива — в целом создаёт предпосылки для практического применения метода.
Если такая надобностьвозникает лишь иногда, при этом в одном коллективе всего один-двараза, то освоение новой технологии не является эффективным, поскольку затраты на это будут, скорее всего, превышать выгоды.4. Требуется также отметить трудоёмкость реализации динамическойподдержки для инструмента моделирования. Однако, если метод применяется в нескольких проектах для данного инструмента, то даннаякомпонента может быть повторно использована.1693.4 Сравнения и соотнесенияС целью соотнесения и обоснования научной новизны предложенной модели v2v-трансформаций с имеющимися подходами рассмотрим краткоимеющиеся подходык использованию трансформацийв модельно-ориентированной инженерии.Трансформации активно используются для генерации одних моделей подругим, когда исходная и целевая модели представляют собой взгляды на систему с разных точек зрения (например, генерация исполняемых моделей помоделям проектирования).
Для задания таких трансформаций используютсяграфовые грамматики и трансформации графов [235], [395]. В [142] показано,как с этой целью можно использовать декларативный язык EXPRESS. Данный вид трансформаций используется также для генерации конечного кодапо моделям (примеры таких трансформаций можно найти в работе [271]), чтооказывается важным при использовании модельно-ориентированного подхода в стиле языка программирования [197]. Трансформации используютсятакже для синхронизации различных моделей: например, в [230] представлена технология, реализующая с помощью трансформаций механизм инкрементального распространения изменений из одной модели в другие.
Следуетотметить, что языки трансформаций ATL [165] и QVT [355] поддерживаютсинхронизационные режимы выполнения трансформаций. Трансформациииспользуются и для контроля целостности моделей — см., например, работу[230], где описан метод, в рамках которого модели дополняются специальными трансформациями, реализующими высокоуровневые изменения UMLмодели на основе используемых шаблонов проектирования. Обзоры различных исследований, посвящённых модельно-ориентированным трансформациям, можно найти в работах [239], [292]. Однако во всех этих подходах рассматривается только модель и не рассматриваются её представления.Трансформации используются также при рефакторинге моделей [437],[235] (под рефакторингом обычно понимают изменения некоторого артефак170та разработки ПО с целью сделать его структуру более удобной и понятной,сохраняя при этом неизменной его семантику [244]; в основном, рефакторингиспользуется при программировании, но также и при разработке других рабочих продуктов: документации [74], UML-моделей [353]).
В принципе, идеярефакторинга близка к основной идее модели v2v-трансформаций, посколькупоследние сохраняют неизменной модель, изменяя только её представления.Однако, в случае применения трансформаций для рефакторинга, последниеимеют дело только с моделями и не работают с представлениями. Предложенный в [74] подход к рефакторингу документации разделяет модель ипредставление, но имеет дело с внутренним представлением (моделью) документа, сохраняя неизменным его внешнее представление. Кроме того, данный подход не использует идею трансформаций.Наиболее близким к модели v2v-трансформаций является подход, описанный в [191]. Авторы этой работы ставят задачу визуализации сложных Javaприложений и используют трансформации на ATL для того, чтобы преобразовать Java-код в EMF-модели.
После этого используются различные Eclipseбиблиотеки для представления этих моделей на диаграммах. Как и в моделиv2v-трансформаций, возможно с помощью трансформаций задавать самыеразные выборки и визуализировать их. Однако данный подход применим кJava-приложениям (в более широком смысле — к произвольному программному коду), в то время как модель v2v-трансформаций может использоватьсядляпроизвольныхпредметныхобластей,например,длябизнес-инжиниринга. То есть подход, изложенный в [191], оказывается частнымслучаем модели v2v-трансформаций. Кроме того, данный подход, в отличиеот модели v2v-трансформаций, не рассматривает преобразование представлений, а занимается созданием этих представлений по моделям, которые извлекает из исходного кода.C моделью v2v-трансформаций можно сопоставить алгоритмы автоматической раскладки моделей и графов.
Примером реализации раскладки графов171может служить технология Graphviz [257], а, пожалуй, наиболее зрелым подходом к раскладке визуальных моделей является KIELLER [307]. АвторыKIELLER основной задачей автоматизированной раскладки считают освобождение пользователя графического редактора от необходимости располагать элементы на диаграмме «вручную», чтобы он помещал их на диаграмму,не заботясь об их размерах и расположении, а соответствующие алгоритмыбудут выполнять эту работу оптимальным способом. То есть будет выполняться неявная трансформация представлений. Однако такая трансформацияраскладка не меняет состав выборки, представленной на диаграмме, а всеголишь по-другому её располагает, в то время как модель v2v-трансформацийпредполагает изменение такойвыборки.Таким образом, алгоритмы рас-кладки являются составной частью модели v2v-трансформаций.Проблемы больших моделей, к сожалению, не находятся в фокусе исследователей и разработчиков средств моделирования.
Так, например, известный метод/пакет моделирования Web-приложений WebML/WebRatio [151],[385] не предлагает средств решения этой проблемы, хотя оперирует гипертекстовыми моделями (элементы интерфейса Web-приложения и переходымежду ними), которые даже для небольших приложений оказываются значительными по размерам. Та же проблема встречается при разработке диаграммклассов — модели по 100–200 классов и больше встречаются нередко.
Однако, несмотря на это, фактически, единственными работами, изучающимибольшие модели, являются статьи [175], [176]. В этих работах рассматриваются промышленные модели компании Siemens, формулируются различныеметрики качества и исследуется их выполнимость (с помощью специальногопрограммного средства, реализованного для этих целей в Siemens). Однакоостаётся открытым вопрос о программных инструментах, предоставляющихсредства разработки таких моделей, а не для пост-фактум анализа.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
