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

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

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

В работе также кратко описываются статьи, представленныена семинаре «Consistency Problems in UML-based Software Development», который был проведён в рамках конференции UML 2003. Ряд описываемыхработ, например, [408], непосредственно подходят к идее проверки одноймодели, но пока предлагаемые решения выглядят всё ещё слишком концептуальными и теоретическими.Последний обзор решений в области целостности UML-моделей был представлен в работе [338]. В рамках обзора было выявлено более 900 опубликованных по данной тематике статей с 2001 по 2008 годы. Максимальныйвсплеск исследований по этой тематике был зафиксирован в 2004 году, но вдальнейшем интерес к этой теме стабилизировался, немногим уступая пико177вому значению.

Все это свидетельствует о значительном интересе к даннойпроблеме со стороны исследователей. При этом авторы обзора выбрали дляанализа 54 статьи, руководствуясь следующими критериями отбора: из итогового списка были удалены короткие статьи (short papers), не англоязычныестатьи, а также статьи, представленные не на международных конференциях.Интересен ряд выводов, которые сделали авторы данного обзора. Во-первых,они отметили, что только 12% подходов имеют механизмы для расширения,то есть могут быть распространены без существенных изменений на другиевиды диаграмм.

Этот факт свидетельствует о том, что подходы в этой области в незначительной степени поддерживают предметно-ориентированноемоделирование, так как в данном случае в каждом применении возникаютновые виды диаграмм, что отмечено и авторами обзора. Было также отмечено, что 53,1% подходов поддержаны программным инструментом, но только15,6% интегрированы с инструментами моделирования, что, безусловно, затрудняет индустриальное использование данных методов и свидетельствуетоб определённой незрелости данной области.Монография [425] посвящена методам валидации и верификации UMLмоделей.

Автор выделяет три аспекта качества моделей: синтаксический, семантический и эстетический. Автор также определяет три типа моделей: модели предметных областей (Models of Problem Spaces, MOPS), модели области решения, то есть всей системы (Models of Solution Space, MOSC) и модели архитектуры ПО (Models of Background Space, MOBS). Для каждого типамоделей рассматриваются соответствующие UML-диаграммы и вводятсяспособы проверки и списки проверки, то есть проверяемые свойства (QualityCheck Lists).

Однако в монографии не предлагаются расширяемые методыпроверки, ориентированные на модели, не попавшие в классификацию автора, а также валидация/верификация видов диаграмм, отличных от UML 2.0.В работе [356] даётся систематический обзор подходов к обеспечению качества моделей в рамках модельно-ориентированной разработки. Пик инте178реса к тематике снова приходится на 2004 год, потом снижается и стабилизируется, подобно тому, как это происходило с работами по UML целостности[338]. Всего для исследования было отобрано 40 статей. Рассмотрим подходы, которые обозначены в этом обзоре как решающие задачу контроля корректности моделей.В работе [250] решается задача повышения точности и однозначности моделей UML моделей — вариантов использования, конечных автоматов (используются для создания сценариев, в которых принимают участие вариантыиспользования) и классов, — путём добавления OCL-ограничений к элементам этих моделей.

В предложенном подходе связываются пост-условия вариантов использования, условия диаграмм состояний и переходов и постусловия операций в модели классов. OCL используется для задания дополнительной семантики моделей. Не обсуждаются вопросы автоматической обработки таких моделей и соответствующих OCL-спецификаций — решениенаправлено лишь на создание более точных моделей.В [361] также обсуждаются вопросы обеспечения корректности моделей,но на фоне решения задачи обеспечения качественного процесса моделирования (рассматриваемого как качественный коммуникационный канал).Предлагается также классификация видов качества моделей. Для обеспечения семантической корректности моделей рассматривается подход редукцииданных (cycle of data reduction), который заключается в последовательномкорректном обобщении больших объёмов информации по определённымправилам.

Однако статья является философски-концептуальной и не предлагает конкретных методов обеспечения корректности моделей.Близка к нашему исследованию работа [175], где автор предлагает формулировать правила корректности и реализовывать их с помощью специальныхпрограммных средств. Однако автор предлагает лишь готовые правила корректности (которые, как следует отметить, могут существенно меняться отодного DSM-проекта к другому) и соответствующий программный инстру179мент, реализующий эти правила для моделей, созданных в компании Siemens.Не обсуждаются вопросы расширения данного подхода и инструмента дляпроверки других правил.Ещё одной близкой к нашему исследованию работой является [436], гдевыдвигается идея анализа больших моделей, предназначенных для генерациикода.

В работе исследуются UML/SDL модели, предназначенные для генерации кода телекоммуникационного ПО. Данная предметная область совпадаетс той, для которой была выполнена первая апробация предложенного в данной диссертационной работе подхода к контролю корректности визуальныхспецификаций. Авторы вводят технику под названием «анализ моделей»(model analysis), утверждая, что её необходимо использовать помимо верификации и тестирования моделей (при этом верификацию авторы считаютбесполезной). Предложенный анализ авторы делят на простой, выполняемыйдо генерации кода по моделям, и сложный, выполняемый в рамках генерациикода.

Первый вид анализа ищет простые ошибки, второй, имея доступ ковсему приложению в виде дерева разбора, способен выполнять сложные проверки. В целом авторы выдвигают справедливое предположение, что анализмоделей должен выполняться регулярно, позволяя найти ошибки как можнораньше. Здесь авторы, фактически, подходят к идее регулярного запуска таких проверок в режимах build management, что предлагается в диссертационном исследовании, однако сами авторы таких выводов не делают. Авторывыделяют ряд типичных ошибок/точек контроля в моделях рассматриваемогокласса: посылки сообщения, которые не имеют получателя; недетерминированное поведение, которое допускается языком, но которого следует избегатьна практике; использование данных до инициализации; использование в моделях вставок текста на C/C++ — и, соответственно, задачу контроля корректность связей этих вставок с модельным контекстом и т.д.

Авторы реализовали собственный анализатор. Однако предложенный подход не масштабируется на другие виды моделей, например, модели ИТ-архитектуры, кото180рые тоже являются большими и нуждаются в подобном анализе, однако неимеют поведенческих моделей и требуют иных видов проверок.Приведённыевышеработынерассматривализадачипредметно-ориентированных моделей, фокусируясь на качестве отдельных видов модели. Проблема качества предметно-ориентированных моделей поднимается вработе [298].

Указывается недостаток работ в этой области по сравнению сисследованием качества UML-моделей (состояние на 2008 год). Вводится система успешных факторов для предметно-ориентированного языка моделирования (экспертиза в предметной области, хорошая локализация предметной области, эффективная поддержка программными инструментами и пр.);эти факторы распределяются по разным областям (техническая, организационная, социальная, персональная) и трансформируются в критерии оценкипредметно-ориентированного языка (на самом деле DSM-решения).

Результаты исследования могут использоваться в качестве концептуального подхода при разработке системы оценки качества DSM-решений, однако не предназначены для создания конкретного программного инструментария контроля качества визуальных спецификаций.Поскольку предлагаемый подход опирается на спецификацию ограниченийк моделям и генерации по ним программных средств проверки для конкретного DSM-решения, рассмотрим, как другие авторы используют ограниченияк моделям (в частности, как применяются OCL-ограничения).

Так, в работах[30], [33] предлагается собственный язык ограничений для задания дополнительной информации при автоматической генерации пользовательских интерфейсов по моделям. Эта информация используется для генерации связныхфильтров и других ограничений в пользовательских интерфейсах. В [231]OCL-ограничения используются для спецификации и автоматической генерации инвариантов к Java-классам. Следует отметить, что язык OCL активноиспользуется в различных академических исследованиях в сфере модельноориентированной инженерии, бизнес-инжиниринга и др.

областей, где визу181альное моделирование применяется для работы с информацией. Так работа[389] рассматривает вопросы создания расширений UML с целью разработкикодогенерационных решений. Справедливо полагается, что в этом случае визуальные спецификации должны иметь строгую семантику, и в качестве одного из способов для достижения необходимой строгости предлагается использовать OCL-ограничения на стереотипы. Работа [254] рассматриваетдляOCLработысостереотипами,новконтекстепредметно-ориентированных требований при разработке приложений баз данных.

В работе [451] исследуются вопросы разработки платформенно-независимыхкомпонентных моделей, для спецификации которых UML расширяется понятиями порт, компонента и коннектор (позднее эти абстракции были включены в официальную версию UML). С этой целью используется механизм расширения UML, и, в частности, язык OCL. Задача рефакторинга OCL-кодарассмотрена в [380]. В работе [154] делается обзор терминологии и задач, длякоторых применяется OCL.

Выделяются следующие способы использованияOCL: спецификация ограничений (например, в стандарте UML), причём здесьречь идёт именно о спецификациях, без автоматической обработки;именно в индустрии это бывает полезно, например, при формализациитребований к графическим редакторам, точнее, к языкам, которые онидолжны поддерживать; такие спецификации однозначно переходят в соответствующий проверочный код, но зачастую организовывать автоматическую генерацию такого кода нецелесообразно, поскольку он оказывается сильно интегрирован с другим кодом, который автоматически неполучить; валидация/верификация ограничений — то есть проверка того, что конкретные модели удовлетворяют сформулированным ограничениям44;44В [194] определяется разница между валидацией и верификацией следующим образом.За точку отсчёта принимается модель, то есть рассматривается валидация/верификация182 использование ограничений в качестве средства запросов к модели; разбор (парсинг) ограничений для дальнейшего применения созданногодерева разбора; разрешение ограничения — то есть нахождение одного случая, когдаограничение удовлетворено, не удовлетворено или не определено.Кроме этого, в работе приводится обзор использования OCL в ряде индустриальных проектов.Обзор OCL-инструментов можно найти в работах [196], [198].

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

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