Диссертация (1145120), страница 14

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 14)

В [356] сформулировано шесть измерений качества моделей: корректность (C1-Correctness) — семантическая и синтаксическая, задаваемая как метамоделью, так и дополнительными правилами; полнота (C2-Completeness) — вся необходимая информация определенав моделях; целостность (C3-Consistency) — отсутствие противоречий в модели(последние возникают из-за использования концепции множественныхточек зрения при моделировании [325]); понимаемость (C4-Comprehensibility) — модели доступны для понимания пользователям; ограниченность (C5-Confinement) — модели не содержат лишней информации; изменяемость (C6-Changeability) — в модели легко вносить изменения.Из этих целей выделим корректность, поскольку она в наибольшей степени может быть проконтролирована формальными методами и программнымиинструментами.

Относительно целостности можно сказать почти то же самое(то есть здесь существует много формальных подходов и программныхсредств — см. обзор [338]). Однако задача контроля согласованности разныхпредставлений системы оказывается трудно реализуемой на практике в виденадёжных и расширяемых методов, поддержанных инструментально, о чёмсвидетельствуют выводы обзора [338].

Отметим, что актуальна корректность,которая не контролируется средствами моделирования — стандартными илисозданными в рамках DSM-решений. То есть речь идёт о наборе свойств илиправил, которые не зафиксированы с помощью метамодели (в качестве примераможновспомнитьUML — егоспецификацияснабженаOCL74ограничениями, которые авторы стандарта не стали выражать в терминах метамодели).

Тогда корректность визуальной спецификации будем понимать,следуя [411], как истинность (инвариантность) ряда ограничений корректности, сформулированных относительно набора значимых свойств спецификации21. Различные варианты ограничений корректности можно найти в работах [175], [356], однако для нас важно, что они могут быть существенно различными ввиду использования не стандартного языка моделирования —UML BPMN и пр., — а предметно-ориентированных языков.

Ограничениякорректности могут быть специфицированы следующим образом. на естественном языке — и либо после этого контролироваться процессом и дисциплиной разработки модели, либо быть автоматизированы; на формальных языках — прежде всего OCL — и после этого контролироваться автоматически; имеется большое количество программныхсредств, поддерживающих OCL [255]; на скриптовых языках, использующих открытые программные интерфейсы средств моделирования.При этом известно, что OCL-подходы имеют ограниченное применение виндустрии [356], [408] (об этом же косвенно свидетельствуют результаты обзора [338]). Напротив, ограничения корректности на практике достаточнопросто специфицировать с помощью скриптовых языков (JavaScript, VBScriptи др.) и открытых программных интерфейсов средств моделирования.

Такиеинтерфейсы существуют и поддерживаются, согласно исследованиям автора,практически, всеми ведущими инструментами моделирования — EnterpriseArchitect, MagicDraw, UModel, ARIS, Mega и т.д., — а также DSM-платформами. Таким образом, индустриальные практики поддержки качества визу-21Термин Correctness часто выступает как синоним Consistency [195].

Однако следует отметить, что под Consistency как правило имеют ввиду согласованность ряда моделей, выполненных с разных точек зрения [338]. В работе [411], откуда мы заимствуем данноеопределение, речь шла также о Consistency. Однако если мы заменим множество моделейодной визуальной спецификацией, то данное определение, очевидно, не изменится.75альных спецификаций, ориентированные на автоматизацию, целесообразноориентировать на поддержку корректности, оставив остальные цели качестваметоду и процессу моделирования.Предположим теперь, что имеется два набора данных, имеющих семантическое пересечение, то есть синтаксически по-разному представляющиходну и ту же информацию (формально это пересечение может пониматьсятак, как это изложено, например, в[411]).

Тогда синхронизация(synchronization) — это процесс изменения этих наборов данных таким образом, чтобы они стали идентичными в своём семантическом пересечении. После синхронизации каждый из наборов данных продолжает своё существование и может отличаться от другого в тех частях, где он представляет своюуникальную информацию. Синхронизация может быть быстрая и отложенная. В первом случае два актива синхронизируются непосредственно послеатомарного изменения одного из них, во втором случае изменения накапливаются и вносятся во второй актив в результате специального действия посинхронизации. При этом существенно, что синхронизация не приводит кперегенерации одного набора данных на основе другого — вносятся именноизменения (change propagation [396]), поскольку ни тот, ни другой набор данных нельзя просто перегенерировать, чтобы не потерять уникальную информацию, принципиально не содержащуюся в другом наборе.

Задачи синхронизации возникают там, где существуют два и более независимых процесса/программных инструмента для работы с данными, имеющими общуючасть. Например, существует задача синхронизации локальных версий данных при совместной работе нескольких пользователей, например, в Интернете с тем, чтобы быстро отображать изменение, сделанное любым из пользователей, для остальных [368]. Также синхронизацией является задача циклической разработки ПО (round trip engineering) [89], [164], [278], [396] —например, синхронизация диаграмм классов и соответствующего им программного кода.

На практике задача синхронизации часто возникает при76совместном использовании (интеграции) нескольких инструментальныхсредств. В этом случае её решение часто бывает затруднено в силу сложностей гибкого программного доступа к данным извне. В свою очередь, это часто приводит к отказу использовать такие инструменты совместно. Сложность практического решения задачи синхронизации показывает исследование, проведённое автором диссертационной работы и посвящённое имеющимся решениям частной задачи синхронизации — циклической разработкив UML-пакетах для случая синхронизации диаграмм классов и программногокода [89].

Были рассмотрены ведущие UML-пакеты — UModel, IBM RationalSoftware Architect, Enterprise Architect — и выявлено, что данная задача реализуется в стандартных инструментах моделирования, в основном, как демофункциональность (то есть функциональность, которая работает на модельных примерах, но плохо применима для решения реальных задач; используется для маркетинговых целей): не поддерживаются сложные проекции в код и нетривиальные сценарии использования; плохо реализованаидентификация сущностей в коде; неочевидна логика работы отдельныхфункций и пр.

Необходимо отметить, что речь идёт о задаче, имеющей ясную постановку и очевидную практическую значимость, которая, кроме того,исследовалась в течение более чем 10-ти лет [89], [164], [278], [396], [399] 22.Задача слияния (merge) информационных активов входит в набор задачверсионного контроля и, в более широком смысле, в конфигурационноеуправление [277]. С другой стороны, данная задача является частным случаем синхронизации с тем ограничением, что в итоге обе синхронизируемыеверсии данных становятся идентичными: их разные части объединяются, похожие сливаются, и в итоге одна из версий перестаёт существовать. При сли22Необходимо отметить, что синхронизацией часто называют задачу управления целостностью, особенно в случае контроля изменений (change propagation).

Однако мы не будемтак расширять нашу точку зрения, а остановимся на трактовке задачи синхронизации вконтексте совместного использования нескольких инструментов. Тем не менее, необходимо отметить, что трудно провести чёткую грань между задачами обеспечения синхронизации и поддержки целостности.77янии могут возникать конфликты: update/update — один и тот же узел былизменён в разных версиях; move/move — один и тот же фрагмент был перемещён в разных версиях в разные локации; delete/update — в одной из версийфрагмент был удалён, а в другой изменён. В [335], [336] справедливо указывалось на осторожность при автоматическом разрешении конфликтов.

В связи с этим возникает задача визуализации конфликтов и предоставления пользователю удобных средств по их разрешению. Необходимо также отметить,что существует две основных парадигмы слияния XML-файлов — 3 waymerge и 2 way merge. Алгоритмы первого вида используются при слияниитрёх активов: двух версий актива, а также исходного актива (в дальнейшем— базовая версия). Алгоритмы второго вида базовую версию не используют.Результат слияния (в дальнейшем мы будем называть его целевой версией) впервом случае получается более качественным, однако 2 way merge алгоритмы также необходимы в том случае, когда базовая версия недоступна или еёвообще не может быть (например, при слиянии онтологий — то есть в этомслучае сливаются не две версии, появившиеся из одного и того же источника,а два принципиально разных актива [401]).

Отметим также важность процедуры идентификации при сравнении/слиянии сложных структур данных. Этапроцедура позволяет определить, имеют ли два элемента в сливаемых наборах данных одно происхождение или нет. Эта задача может быть легко решена, если у элементов есть уникальные идентификаторы. В противном случае (например, при слиянии онтологий и баз данных, не имеющих общегопроисхождения [401]) могут использоваться алгоритмы сравнения расстояния между строк — см.

обзор таких алгоритмов в [130].Обсуждённыевышепонятияважныприразработкеследующихдополнительных функциональных компонент, которые создателям DSMпакетов часто приходится реализовывать самостоятельно: средства поддержки качества визуальных спецификаций,78 средстваинтеграцииDSM-решениясдругимипрограммнымисредствами, использующимися в данной предметной области (при этомприходится решать задачи синхронизации), средства работы с большими моделями, средства версионного контроля моделей (прежде всего слияние и поискразницы моделей).Особо прокомментируем средства версионного контроля.

Характеристики

Список файлов диссертации