Диссертация (1145120), страница 38
Текст из файла (страница 38)
Кроме того, информационный продукт может содержать текст, являющийся шаблоном соответствующего документа (содержимое информационного продукта будет рассмотрено далее).227Руководство пользователяИсходящиезвонкиВходящиезвонкиНомеронабирательАОНАОН ГОСТ РФАвтоответчикАОН Caller IDРис 4.24. Пример диаграммы вариативностибаРуководствопользователя для«Унител-таксофон»Руководство пользователядля «Унителавтоответчик»Исходящие вызовыИсходящиевызовыНомеронабирательНомеронабирательВходящиевызовыАвтоответчикРис.
4.25. Диаграммы продукта: а — «Унител-таксофон», б — «Унителавтоответчик»Графический редактор DocLine создан с помощью технологии Eclipse GMF[398]. Для этого была разработана метамодель языка DRL, предназначеннаядля автоматизированной генерации графических редакторов (в терминахEclipse GMF это EMF-модель).На основе EMF-модели и нескольких вспомогательных моделей (моделиграфических символов, модели инструментов и связующей модели) средствами GMF был сгенерирован код редакторов диаграмм, а также функциисохранения и восстановления диаграмм и моделей.228В случае DocLine сериализационное представление модели должно соответствовать языку DRL/PR, поскольку в DocLine предусмотрено дальнейшее«ручное» редактирование DRL-спецификации с целью настройки повторногоиспользования и наполнения документации текстом.
Eclipse GMF поддерживает раздельное сохранение графической информации (координаты и размеры графических символов) и модельной информации, однако формат сохраняемой модельной информации содержит ряд служебных данных, затрудняющих дальнейшее ручное редактирование. Элементы, представленные на одной диаграмме, могут храниться в разных файлах, что сделано ради удобстваработы технического писателя.
Для решения этих проблем было создано дополнительное XSLT-преобразование, которое при сохранении диаграммыпреобразует её представление к формату DRL, а при чтении добавляет кDRL-спецификации необходимые служебные данные.На 4.26 показан пример DocLine с открытой диаграммой вариативности.Рис. 4.26. Графический редактор DocLine с открытойдиаграммой вариативности229Поскольку DRL-спецификации имеют два различных представления, товозникает задача синхронизации.
DRL/GR-спецификации могут быть восстановлены по имеющейся DRL/PR-спецификации, при этом потеряются толькосведения о размерах и расположении графических элементов. Переход отDRL/GR к DRL/PR и обратно осуществляется специальным XSLTпреобразованием. Случаи противоречивых изменений двух представленийредки и могут быть обработаны «вручную».
Таким образом, графический редактор интегрирован с текстовым — пользователю предоставляется возможность перейти от элемента диаграммы к его текстовому представлению.Апробация языка DRL была выполнена на промышленном семействе телекоммуникационных систем — программном обеспечении электронных автоматических телефонных станций. Семейство состояло из базового продукта иряда его модификаций — сельские, офисные, городские, транзитные телефонные станции.
Для применения DocLine было выбрано два представителясемейства — базовая городская телефонная станция (далее — ГАТС) и станция специального назначения (далее — САТС). Было рассмотрено руководство пользователя для рабочего места оператора станции (одна из подсистем,далее — РМО).
САТС являлась подмножеством ГАТС, доработанным подтребования конкретного заказчика. К документации заказчик сформулировалследующее требование: должны быть описаны только те функции, которыевошли в поставку, а описание остальных должно отсутствовать. Таким образом, на основе руководства по РМО для ГАТС было создано руководство поРМО для САТС. Именно к двум этим документам и был применён язык DRLи технология DocLine.Сходства и различия документов следуют из вариативности функциональности данных продуктов. Виды вариативности представлены ниже.1. Удаление — из базовой версии системы удаляется функциональность,которая не требуется в новом продукте. Соответственно, из документа230ции удаляется описание данной функциональности: отдельный фрагмент текста, целая глава или набор глав.
Однако часто текст, которыйдолжен быть удалён, не локализован, а распределён по различным частям документа, что значительно усложняет сопровождение документации.2. Добавление — в базовую версию продукта добавляется новая функциональность, и описание этой функциональности следует внести в документацию. Как и в предыдущем случае, изменения могут быть также нелокализованы в одной части документа. Эта операция не задействованав нашем случае, так как в САТС не произошло добавления новых относительно ГАТС возможностей.3. Изменение — существующие функциональные возможности значительно меняются; в этом случае в документацию также должны бытьвнесены соответствующие изменения, которые при этом не локальны.4.
Локальное изменение — меняется отдельный атрибут функционального свойства, например, количество обслуживаемых абонентов. В документации это приводит к локальным изменениям текста. Например, вприведённом выше примере будет изменено число в сводной таблицефункциональных возможностей.5. Семантические повторы — одна и та же функциональность описывается в разных документах по-разному, но смысл остаётся тем же.
Семантических повторов следует избегать и единообразно описывать одну иту же информацию.На рис. 4.27, 4.28 и 4.29 представлены результатыапробации — получив-шиеся диаграммы на DRL/GR. В табл. 4.2 приведены численные данные поизменениям по документации для САТС. В целом объем документации данного семейства составил около 200 страниц в DocBook/DRL. После выделения повторно использованных компонент текста конечный вид документациив pdf не изменился.231Табл 4.2. Распределение типов измененийв документации для САТСВид изменений Кол-во измененийУдаление 32Добавление 0Изменение 5Локальное изменение 26Семантические повторы 37232Рис.
4.27. Главная диаграмма семействаПредставленные выше эксперименты с анализом существующей документации и организации повторного использования привели автора к следующим идеям: автоматизированный рефакторинг документации (внешнее представление документации сохраняется, а внутреннее изменяется с учётом выделения повторно используемых активов) и автоматизация поиска повторов.Рефакторинг был реализован коллегами автора по Docline [76], [316] и в данной диссертационной работе обсуждаться не будет.
Поиск повторов был реализован непосредственно автором и будет изложен ниже49.Для решения этой задачи было решено воспользоваться техникой поискаклонов в программном обеспечении (Software Clone Detection) [153], [379] иготовым инструментом поиска клонов — CloneMiner [172]. Результаты такого поиска было предложено использовать при рефакторинге документации,должным образом изменив последний.49Изложение алгоритма поиска повторов в документации следует работе автора [79], внезначительной степени используя результаты из [80], [318].233Рис.
4.28. Диаграмма вариативности234Риc. 4.29. Диаграмма продукта для САТС235Алгоритм поиска повторов и рефакторинга представлен на рис. 4.30.Рис. 4.30. Алгоритм поиска повторов и рефакторинга документаНа входе имеется файл с документом, который нужно подвергнуть автоматизированному рефакторингу. С этим файлом выполняется определённая работа по его подготовке к процессу, затем запускается Clone Miner, которыйвыдаёт список групп клонов и их координаты в тексте.
По этому спискупользователь для любой из обнаруженных групп может выполнить автоматизированный рефакторинг. При рефакторинге все экземпляры клона заменяются ссылками на повторно используемое определение информационногоэлемента.Подготовка к поиску клонов. DocLine работает с файлами в формате DRL,а процедура поиска клонов может применяться только к информационномуэлементу. Однако хотелось бы применять поиск клонов к «плоскому» тексту(файлы в формате ASCI/Unicode) или к DocBook-документам. Это, в своюочередь, влечёт необходимость преобразовать такие документы в DRLформат, что может быть сделано с помощью операции рефакторинга «Преобразование в DRL». В результате появляется новый информационный элемент, содержащий весь исходный текст документа.Поиск клонов.
CloneMiner работает в режиме поиска в «плоском» тексте,поскольку результат поиска может разрывать XML-конструкции: нашей задачей является поиск повторов именно в тексте, а не поиск корректных повторяющихся XML-конструкций. Пример ниже показывает фрагмент текста,236в котором полужирным выделен найденный клон. Он включает открывающий тэг, но не включает закрывающего. Клоны делаются XML-корректнымипри выполнении рефакторинга, вместе с этим делается XML-корректным ито окружение документа, из которого они извлекаются.<section id="file-tree-isa-directory"><title>Reviving incoming calls </title><para>Once you receive an incoming call, the phone gets CallerIDinformation and reads it out.
But if...</para></section>Фильтрация результатов. Предложенный алгоритм выполняет фильтрацию результатов работы CloneMiner, следуя следующим шагам.1. Отбрасывается все группы клонов, которые содержат клоны меньше,чем 5 символов, исключая пробелы (например, «is a» содержит 3 символа). Обычно подобные клоны встречаются в большом количестве, ноне имеют содержательного смысла. Для текста размером около 900 Кбна английском языке находится в среднем 3000 таких «клонов», которые существенно затрудняют дальнейший анализ.2. CloneMiner находит пересекающиеся группы клонов. Наш алгоритмисключает пересечения, оставляя группы, в которых длина клонов является наибольшей, так как чем больше клон, тем больше вероятность,что этот клон является семантически значимым.3.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
