| Both sides previous revision Previous revision Next revision | Previous revision |
| mdd:uml_artifacts_reuse [2016/12/24 21:43] – gezort | mdd:uml_artifacts_reuse [2026/08/29 07:59] (current) – external edit 127.0.0.1 |
|---|
| | ====== UML Artifacts Reuse: State of the Art ====== |
| | ===== Intro ===== |
| |
| | Цель переиспользования - получение выгод: ускорение производства, снижение стоимости, увеличение надежности, уменьшение рисков. С другой стороны есть некоторые минусы такого подхода: увеличение затрат на поддержание проекта, недостаток тех поддержки и др. |
| | |
| | Существуют два типа переиспользования: //систематическое// - в случае, когда используются компоненты, созданные как раз с целью их переиспользования - и //случайное//, когда разработчики понимают, что для производства новых продуктов могут быть использованы уже произведенные ранее компоненты. Систематическое переиспользование требует больше ресурсов и усилий, однако в результате дает более устойчивые и хорошо задокументированные артифакты. |
| | |
| | Есть четыре фазы переиспользования ПО: //представление, получение, адаптация// и //внедрение//. |
| | |
| | Представление - выбор компоненты(query), для которой планируется использовать имеющиеся артифакты. Получение - выбор компоненты с минимальной стоимостью адаптации, которой планируется заменять query. Адаптация - модификация выбраной компоненты для получения query. Внедрение - интеграция адаптированной компоненты. |
| | |
| | ===== Техники получения ===== |
| | |
| | ==== Graph Matching ==== |
| | Вершины графа - концеты артифактов(классы, интерфейсы и т.п.), а ребра - отношения между ними. Данный вид техник измеряет степень похожести графов. |
| | {{ :mdd:uml_reuse_1.png?200|}} |
| | |
| | Существует множество вариантов данных техник. Один из них - сведение к Message-Object-Order-Graphs(MOOGs), в которых вершины - моменты отправки и получения сообщений, а ребра - потоки сообщений между вершинами. Идея проверки схожести состоит в том, что у схожих кусков графа схожие соседи. |
| | |
| | Другой подход состоит в получении матрицы смежности для графа, считая классы вершинами, а отношения между ними - ребрами, и дальнейшего подсчета метрик по матрице. |
| | |
| | Однако есть ряд проблем связанных с тем, что задачи связанные с проверкой изоморфизма графов не решаются за полиномиальное время. |
| | |
| | ==== Case Based Reasoning ==== |
| | Суть данных техник в том, что проблемы решаются путем использования решений для других похожих проблем, возникавших ранее. При этом прошлый опыт сохраняется, как набор кейсов. После поиска похожих на query проблем происходит адаптация решение и обновление базы опыта. Как правило база опыта содержит в себе набор пар вида <кейс, решение>. Нередко определение похожести кейсов происходит по требованиям. |
| | |
| | ==== Ontology Based Techniques ==== |
| | Онтологии - способ организации информации с целью предоставления знаний о произведенных артифактах. Смысловая близость двух концептов часто пропорциональна их расстоянию в онтологии. |
| | |
| | Онтологии общего назначения (напр. WordNet) иногда не дают специфических знаний об изучаемой области. Специфичные же онтологии бывают двух видов: //application ontologies//(строятся один раз) и //domain ontologies//(свои для каждой области). Первые были разработаны для измерения близости классификаторов диаграмм классов и идентификаторов отношений. Вторые были использованы для сравнения названий классификаторов. Общая близость измеряется, как взвешенная сумма двух показателей. |
| | |
| | Также сюда относятся //таксономии//, которые показывают иерархическую зависимость между концептами. Как правило таксономии используются для подсчета концептуального расстояния между типами данных. {{ :mdd:uml_reuse_2.png?200|}} |
| | |
| | Информация из диаграмм вариантов использования об акторах и юз кейсах равно как и доп информация от пользователей интегрируются в Ontology Web Language(OWL) онтологии, которые хранятся в репо в реляционной БД. Для приведения запросов к БД в нужный формат используется OWL. |
| | ==== Information Retrieval Methods ==== |
| | Данный тип методов работает, как обычный информационный поиск. Как один из примеров - поиск по спецификациям с использованием косинусной метрики для измерения близости. |
| | |
| | Другой вариант - первичная классификация моделей в репо и вторичный поиск. Классификация происходит по шести пунктам и определяет функциональные требования модели. На стадии поиска измеряется соответствие пар описаний и ищется пара, максимально сответствующая нужной |
| | |
| | ==== Other ==== |
| | Также применяются генетические алгоритмы. Были варианты, в которых применялась Structured Mapping Engine, суть которой в разбиении информации на два множества основываясь на общих чертах отношений между объектами и включению объектов в отношения. |
| | |
| | Для поиска похожих описаний применяются в том числе и различные NLP техники. Существует вариант, в котором похожие диаграммы классов ищутся в репо основываяся на весе класса(который отражает его важность и влияние) и количестве общих имен классов |
| | |
| | ===== Поддержка артефактов ===== |
| | |
| | Список диаграм UML, к которым применялись техники получения описан в таблице II |
| | |
| | Три наиболее поддерживаемых типа диаграмм - диаграм классов, диаграммы последовательностей и диаграммы вариантов использования. |