автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Метод повторного использования документации семейств программных продуктов

СЛНКТ-1 "ПЕТЕРБУРГСКИМ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

003434631

На правах рукописи

Романовский Константин Юрьевич

МЕТОД ПОВТОРНОГО ИСПОЛЬЗОВАНИЯ ДОКУМЕНТАЦИИ СЕМЕЙСТВ ПРОГРАММНЫХ ПРОДУКТОВ

05.13.11 — Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата физико-математических наук

Санкт-Петербург

2010 2 5 МДР ?П1Л

003494631

Работа выполнена на кафедре системного программирования математико-механического факультета Санкт-Петербургского государственного университета.

Научный руководитель:

кандидат физико-математических наук, доцент КОЗНОВ Дмитрий Владимирович

Официальные оппоненты: доктор технических наук, профессор,

ЛИСС Александр Рудольфович (ОАО «Концерн «Океанприбор»)

кандидат технических наук, профессор КОТЛЯРОВ Всеволод Павлович (Санкт-Петербургский государственный политехнический университет)

Ведущая организация:

Московский государственный университет приборостроения и информатики

Защита диссертации состоится "15" апреля 2010 г. в 14:00 часов на заседании совета Д 212.232.51 но защите докторских и кандидатских диссертаций при Санкт-Петербургском государственном университете по адресу: 198504, Санкт-Петербург, Петродворец, Университетский пр., 28, математико-механический факультет, ауд. 405.

С диссертацией можно ознакомиться в Научной библиотеке Санкт-Петербургского государственного университета по адресу: 199034, Санкт-Петербург, Университетская наб., д. 7/9.

Автореферат разослан 2010 года

Ученый секретарь диссертационного совета, доктор физико-математических наук,

профессор

Даугавет И.К.

Общая характеристика работы

Актуальность проблемы

Разработка семейств программных продуктов (СИП, Product Lines) - это промышленный подход разработки ПО, обеспечивающий эффективную совместную разработку и продвижение на рынке группы программных продуктов сходного назначения. Суть подхода заключается в плановом повторном использовании различных активов разработки, таких как исходный код, тесты, документация, инструменты разработки, организационные процедуры и т. д. Еще Парнас заметил, что создавать линейки продуктов часто бывает целесообразнее и экономичнее, чем разрабатывать отдельные продукты. В конце 90-х годов XX века сформировались два научных центра, вокруг которых сосредоточены основные исследования в области разработки СПП — Институт Программной Инженерии' Университета Карнеги-Мелол в США и Европейский Институт Программного Обеспечения2 в Европе. Ежегодно проводится несколько международных конференций, посвященных вопросам разработки СПП, издано несколько сотен научных статей по этой тематике, ведутся десятки исследовательских проектов. Многие крупные компании, такие как Nokia, Hewlett Packard, Motorola и др. успешно используют методы разработки СПП на практике.

Существующие на сегодняшний день подходы в этой области обеспечивают повторное использование различных активов разработки, главным образом кода, тестов, организационных процедур. В то же время для полноценной промышленной разработки СПП требуется в дополнении к работающему ПО выпускать также и документацию. Документация СПП может иметь много общего - одноименные документы для разных продуктов семейства (например, руководство пользователя), описывая одинаковую, общую для разных продуктов функциональность, очевидно, содержат многочисленные повторы. Для эффективной разработки и эволюции подобной документации требуются средства поддержки повторного использования повторяющихся фрагментов, что позволяет сократить сроки разработки и существенно повысить качество документации. Однако в области разработки СПП отсутствуют методики разработки документации, ориентированные на повторное использование, а существующие методы и средства разработки документации, такие как DITA, DocBook,

'SEI 2 ESI

- Software Engineering Institute, http://www.sei.cmu.edu. -European Software Institute, http://www.esi.es.

FrameMaker, поддерживают возможности повторного использования, но не позволяют гибко настраивать переиспользуемые фрагменты текста под особенности конкретного продукта и слабо поддерживают средства визуального планирования структуры сложных пакетов документации. Все это существенно затрудняет их применение при разработке документации для СПП.

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

Цель диссертационной работы

Целью работы является создание формального метода разработки документации СПП, обеспечивающего поддержку проектирования документации с вариативным повторным использованием.

Научно-методическая ба?а исследования

Данное исследование проводилось на стыке двух областей: первая область - это методы повторного использования и разработки СПП, вторая область — это подходы и средства создания технической документации. В работе использовался универсальный метод повторного использования Бассета-Ерзабека [10, 16], который адаптируется для разработки документации, и подход для анализа и проектирования общих и различающихся свойств продуктов СПП - диаграммы возможностей (Feature Diagrams) [13], - а также общие концепции визуального моделирования ПО [8]. В работе активно использовался подход единого исходного представления пакетов документов (Single Sourcing) и идея использования XML для внутреннего представления документации [17].

Научная новизна

На сегодняшний день существует ряд методов разработки СПП [8, 10, 12, 15], однако в них отсутствует поддержка разработки документации. С другой стороны, имеется ряд методов и средств разработки документации [14, 18], часть из которых в той или иной степени поддерживают повторное использование. Но эти подходы не обеспечивают поддержку вариативности общих активов, т.е. возможности модифицировать их по требованиям конкретного продукта. Поддержка вариативности хорошо

проработана в методе фреймов Бассета-Ерзабека [10, 16], который, однако, изначально ориентирован на поддержку повторного использования программного кода и не применялся для задач разработки документации. В данной диссертационной работе ставится задача восполнить пробел между методами разработки СПП и подходами разработки документации. В результате исследования был предложен метод разработки технической документации DocLine, включающий в себя оригинальный язык разработки документации DRL, процесс разработки документации, а также инструментальный пакет. Язык DRL, в дополнение к традиционному XML-представлению документации, предусматривает также и визуальную нотацию, предназначенную для проектирования и изучения схемы повторного использования документации. Визуальная нотация использует концепцию нескольких взглядов на разрабатываемую систему3, которая не использовалась при разработке документации — существующие XML-средства разработки технической документации (DITA, DocBook и др.) поддерживают только простые визуализаторы XML-структуры. Предложенный процесс разработки документации включает в себя рефакторинг документации - это достаточно традиционный инструмент в разработке ПО и, в частности, СПП, однако в области разработки документации рефакторинг пока не использовался.

Практическая ценность

В рамках работы был разработан пакет инструментальных средств, который интегрирован в широко распространенную в промышленном программировании среду разработки приложений Eclipse IDE4, что позволяет эффективно использовать метод в коммерческих проектах разработки СПП. При этом инструментальные средства предлагаются с открытым исходным кодом и опираются на свободно-распространяемое ПО, что позволяет легко расширять их под особенности конкретных задач.

Апробация работы н публикации

Результаты диссертации докладывались на международной конференции по методам системного программирования (3rd IFIP ТС2 Central and East European Conference on Software Engineering Techniques CEE-SET 2008, Брно, Чехия), на семинарах Института системного программирования Российской академии наук, Московского госу-

Данная концепция широко используется в программной инженерии - например, она лежит в основе языка визуального моделирования 11МЬ.

4 http://www.eclipse.org.

дарственного университета печати, кафедры системного программирования и НИИ ИТ математико-механического факультета СПбГУ.

Предложенный в работе метод был апробирован на документации двух промышленных семейств программных продуктов, результаты апробации опубликованы в работах [3, 4]. Первая апробация была выполнена при разработке документации семейства программно-аппаратных систем управления телевизионным вещанием (ООО «Фирма «ДИП», несколько продуктов, объем документации около 50 страниц). Документация была успешно создана с помощью DocLine, кроме того, был разработан и опробован механизм расширения DocLine по требованиям конкретного проекта - была реализована возможность автоматизированного включения в документацию и обновления иллюстраций, выполненных в Microsoft Visio. Более масштабная апробация была выполнена на документации промышленного семейства телекоммуникационных систем, разрабатываемых ЗАО «Ланит-Терком», - было переработано около 300 страниц документации и выделено 38 повторно-используемых фрагментов текста, создано 40 точек расширения.

Основные результаты диссертации изложены в семи научных работах [1-7]. Из них три работы [1-3] опубликованы в журналах из перечня ВАК. Работы [1,2,4,6,7] написаны в соавторстве.

В работе [1] Романовскому К.Ю. принадлежат основные идеи языка DRL, а также им выполнена формальная спецификация DRL. Кознов Д.В. предложил идею использовать визуальное моделирование для планирования повторного использования документации. В работе [2] Романовскому К.Ю. принадлежит идея идеального (сверху-вниз) процесса разработки документации и архитектура пакета инструментальных средств, а также разработка и формализация описания метода в целом. Ему же принадлежит разработка инструментальных средств. Кознов Д. В. предложил идею «легковесного» («гибкого», снизу-вверх) процесса разработки документации. В работе [4] Романовский К.Ю. написал раздел «Архитектура средств автоматизации». В работе [6] Романовский К.Ю. разработал и формально специфицировал операции рефакторинга, спроектировал средства их программной поддержки, а также разработал и описал примеры. Кознов Д.В. предложил идею рефакторинга документации. Минчин Л. реализовал операции рефакторинга в составе пакета DocLine. В работе [7] Романовский К.Ю. написал основной текст статьи и добавил новые операции рефакторинга. Кознов Д.В. предложил уточнение «гибкой» модели разработки документации.

Исследование поддержано Российским Фондом Фундаментальных Исследований (гранты РФФИ 08-01-00716-а, 08-07-08066-з). Разработка инструментальных средств поддержана Фондом содействия развитию малых форм предприятий в научно-технической сфере (программа СТЛРТ).

На пакет программных средств получено свидетельство о государственной регистрации программы для ЭВМ №2008612676, выданное 28 апреля 2008 г. Федеральной службой по интеллектуальной собственности, патентам и товарным знакам.

Структура и объем диссертации

Диссертация состоит из введения, шести глав (со сквозной нумерацией разделов, рисунков и таблиц), заключения, списка литературы и приложения. Текст диссертации изложен на 110 страницах и содержит 20 рисунков и 2 таблицы. Список литературы содержит 58 наименований.

Содержание работы

Во введении показывается актуальность выбранной темы исследований, излагается научный контекст диссертационной работы, а также приводится краткое описание предложенного в работе метода DocLine. DocLine охватывает весь жизненный цикл разработки документации от проектирования до публикации итоговых документов и поддерживает плановое адаптивное повторное использование документации. В DocLine, следуя сложившейся традиции, явно выделяется исходное и целевое представление документации. Целевое представление - это документы в привычных для пользователя форматах, таких как PDF для печатных документов, HTML для электронных, или HTML Help для справочной системы. Целевое представление может быть в любой момент получено из исходного автоматически — эта операция называется публикацией (наподобие получения исполняемого кода ПО из исходного кода с помощью компиляции). Для исходного представления документации в DocLine предлагается оригинальный проблемно-ориентированный язык DRL (Documentation Reuse Language). Язык DRL имеет две нотации - графическую (DRL/GR - Graphic Representation) и текстовую (DRL/PR - Phrase Representation). Графическое представление служит для проектирования структуры повторного использования документации (т.е. планирования повторного использования). Текстовое представление позволяет описать в виде XML-представления варианты конфигурирования повторно используемых компонент и конкретные конфигурации для порождения конечных документов. DRL/PR интегрирован с известным форматом DocBook для реализации фор-

7

матирования текста. В работе реализована поддержка двух целевых форматов - PDF и HTML.

Помимо языка метод DocLine также определяет эталонные модели процесса разработки документации: проактивную и «гибкую». В проактивном процессе сначала проводится проектирование схемы повторного использования и разработка адаптивных повторно-используемых компонент, а затем на основе созданной инфраструктуры создаются пакеты документов для конкретных продуктов. В «гибком» процессе сначала создаются требуемые документы, а затем по мере необходимости документация подвергается рефакторингу.

Для практического применения DocLine реализован пакет инструментальных средств, встроенный в интегрированную среду разработки приложений Eclipse.

В первой главе описан контекст исследований и существующие подходы разработки СПП и документации, в том числе подходы, на которые опирается DocLine. В результате обзора делаются следующие выводы. Существует ряд зрелых подходов к разработке документации, часть из которых поддерживает повторное использование (DITA [14], DocBook [18], FrameMaker [17]). Также есть ряд общих методов повторного использования, в которых хорошо проработана адаптивность, но нет возможностей, нужных для разработки документации (подход Бассета-Ерзабека [10, 16]). Имеются и методы моделирования общих и различных свойств систем, которые могут быть применены к задаче разработки документации (диаграммы возможностей [13]). Однако нет единого метода разработки документации, поддерживающего проектирование сложной документации и адаптивность повторного использования. Для документации СПП эти аспекты являются ключевыми.

С другой стороны, имеющиеся методы и средства могут дать техническую базу для нового метода и позволяют сосредоточить основные усилия на главном - на поддержке адаптивного повторного использования документации. Так при реализации DocLine использовались готовые открытые технологии - DocBook для описания форматирования текстов и публикации документов в различных целевых форматах и Eclipse GMF для реализации графических средств проектирования структуры сложных пакетов документации.

Во второй главе описывается язык DRL. Графическая нотация DRL/GR определяет три вида диаграмм - главную диаграмму, диаграмму вариативности и диаграмму продукта. Главная диаграмма (Рис. 1) определяет состав продуктов семейства и набор информационных продуктов, представляющих собой шаблоны целевых документов,

таких как руководство пользователя или справочник. Здесь и далее в качестве примеров приводятся фрагменты описания телекоммуникационных систем, подготовленные в ходе апробации ОосЫпе в ЗЛО «Ланит-Терком».

Семейство продуктов «Телефонный аппарат Унител»

Продукты семейства , Информационные продукты

Унител-АОН Унител-автоответчик 1 1 1 \ 1 —Руководство \ пользователя

А Справочная / —1 система

Унител-таксофон 1 1 1

Рис. 1. Главная диаграмма.

Информационные продукты состоят из информационных элементов, представляющих собой контекстно-независимые повторно-используемые фрагменты текста. Каждый информационный элемент также может включать другие информационные элементы. Эти включения могут быть обязательными или не обязательными, а также их можно объединять в группы двух видов: OR-группы, допускающие включение любого набора элементов из группы (такие группы используются для перечисления «опций», которые могут в любом сочетании войти в разные продукты, например описание входящих и исходящих вызовов), и XOR-группы, допускающие включение не более чем одного элемента (применяются для объединения взаимоисключающих вариантов, например стандарта определителя номера - европейский Caller ID или российский ГОСТ). Подобные варианты сочетания повторно-используемых блоков задаются на диаграмме вариативности (см. Рис. 2). Фактически, диаграмма вариативности описывает допустимые варианты адаптации общих активов в соответствии с требованиями контекста на уровне блоков текста (информационных элементов).

Рис. 2. Диаграмма вариативности.

9

Для более детальной настройки общих активов в [ЖЬ/РИ. предлагается механизм конфигурирования информационных элементов. Для того, чтобы была возможность конфигурировать информационный элемент в соответствии с особенностями конкретного контекста использования, в нем необходимо предусмотреть точки расширения в тех местах, в которых предполагается вариативность. Пример информационного элемента в нотации ИНУРК, содержащего точку расширения, представлен ниже. <ш/е1етеШ 1с1=Са1кгШеМ>После получения входящего вызова телефон запрашивает в сети информацию о звонящем абоненте и затем <пе& (с1=ЛОМОрИоп5>отображает на экране номер абонента</пез(>. </1п/е1етен1>

ХМЬ-теги <1п/е1етеп(/> и <яея/> задают информационный элемент и точку расширения соответственно.

Для упорядочивания терминологии в документах 0Ш7Р11 предлагает конструкцию словарь, включающую в себя набор пар (имя, значение). В произвольной точке документа можно подставить значение элемента словаря, указав его имя. В словарь могут быть включены такие элементы, как название продукта, версия, набор поддерживаемых операционных систем и т.п. - все они много раз используются в тексте и склонны меняться. Также ОИТ/РЯ предлагает обобщение словарей — каталоги, которые предназначены для унификации представления в тексте однородных элементов, более сложных, чем термины. Каталог — это набор элементов-кортежей (имя, атрибут 1, атрибут 2,...). Так, каталог команд пользовательского интерфейса может содержать коллекцию команд интерфейса, имеющих имя, пиктограмму, описание, «горячую клавишу», текст всплывающей подсказки, и т.д.

Для преобразования переиспользуемой документации в документ для конкретного продукта в 01117011 имеются диаграммы продукта, позволяющие описать, какие именно информационные элементы включаются в тот или иной продукт. На Рис. 3 (а) и (б) представлены две диаграммы продуктов для руководства пользователя, описанного на Рис. 2.

(а) (б)

Рис. 3. Диаграмма продукта.

Для настройки конфигурируемых информационных элементов служит специальная конструкция ЭКЬ/РК-адаптер. Адаптер специфицирует набор изменений, которые необходимо внести в информационный элемент, чтобы получить требуемый для конкретного контекста текст. Изменения могут вноситься только в предусмотренные точки расширения, с точками расширения допустимы следующие операции: замена содержимого, добавление текста перед/после точки расширения. Пример адаптера в нотации ГЖЬ/РЯ приведен ниже.

<а(1ар{ег 'т/е1етге[1й= "CallerIdentRef'>

<гер1асе-пе5( пе5М=АОКОрЧоп5>проговаривает номер абонента</гер1асе-пе51> </ас1ар1ег>

Тег <ш1ар1ег/> задает сам адаптер, тег <гер1исе~пе^1/> задает изменение типа «вставить вместо».

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

[Разработка схемы I семейства

[Проектирование схемьГ^ документации с точки зрения повторного использования

/"Создание [ переиспользуемых Усррагментов текста.

Главная Диаграмма

диаграмма вариативности

Тексты информационнох продуктов и элементов

Рис. 4. Схема процесса разработки повторно-нсполыуемой документации.

Когда общие активы документации созданы, на их основе порождается документация конкретных продуктов (см. Рис. 5). В случае, когда разрабатывается документация первого продукта, процесс имеет линейную структуру - дорабатываются необходимые общие активы и создается документация продукта. При добавлении к семейству последующих продуктов и модификации общих активов потребуются дополнительные действия — ведь от добавления нового документа существующие не должны меняться. Это означает, что вместе с модификацией общих активов необходимо внести соответствующие изменения в документацию существующих продуктов, при этом существующая документация (точнее, ее конечное, видимое читателями представление - PDF, HTML и т.д.) не должна измениться, в то время как ее внутреннее DRL-представление претерпевает значительные изменения. Такое изменение общих активов является рефакторингом документации.

Рефакторинг встраивается также и в «гибкий» вариант процесса разработки ПО. Согласно этому процессу сначала разрабатывается документация для первого продукта без учета повторного использования. Это соответствует «гибкому» подходу к разработке СПП, когда в начале делается необходимый минимум инфраструктурной работы и основное внимание уделяется тому, что нужно заказчику ПО. Далее, в процессе разработки документации следующих продуктов из существующей документации выделяются общие активы и на их основе создаются новые документы. При этом существующая документация подвергается рефакторингу, т.е. сама документация перестраивается для использования общих активов при сохранении ее конечного вида.

/Модификация общих активов\ и рефакторинг документации | I продуктов 1..N I

| Создание целевых^ 1 документов J

Рис. 5. Схема процесса разработки документации продуктов. Для облегчения рефакторинга документации DocLine предлагает ряд типовых автоматизированных операций рефакторинга, предназначенных для создания общих активов и их настройки, а также вспомогательные операции, такие как автоматизированные переименования различных вхождений одной и той же конструкции.

В четвертой главе описывается архитектура инструментального пакета, а также особенности его реализации. Пакет состоит из следующих компонент.

• Редакторы.

о Графический редактор DRL/GR.

о Текстовый XML-редактор DRL/PR, включающий систему автоматизированного рефакторинга документации, о Механизм циклической разработки, поддерживающий целостность различных представлений документации.

• Менеджер публикации.

о Модуль трансляции, преобразующий DRL-тексты в формат DocBook. о Модуль диагностики ошибок, выполняющий проверку корректности текстов на DRL, в том числе проверку корректности генерируемого DocBook-кода средствами пакета DocBook.

• Модуль сопряжения с DocBook, выполняющий генерацию конечных документов в форматах HTML и PDF основываясь на инструментарии DocBook.

Первая версия пакета была реализована на платформе Microsoft.NET в виде отдельного приложения (менеджер публикации и модуль сопряжения с DocBook). Далее была создана архитектура пакета для платформы Java/Eclipse: графический редактор DRL/GR был разработан с помощью технологии Eclipse GMF, а текстовый редактор базируется на стандартном открытом XML-редакторе Eclipse. Стоит также отметить алгоритм валидации документации, состоящий из трех этапов - проверки по схеме DRL, контроля ссылочной целостности и проверки по схеме DocBook.

13

В пятой главе описывается апробация предложенного метода. Результаты апробации обсуждаются и делаются выводы о применимости метода. В целом выяснилось, что применение DocLine при наличии модели вариативности СПП, практически, ничем не отличается по трудоемкости от применения, например, DocBook, однако при этом DocLine добавляет средства планирования и механизм адаптивного повторного использования. Основная сложность применения DocLine — необходимость техническому писателю владеть основами XML. Основные вопросы о возможности практического применения DocLine относятся к применимости подобных XML-технологий в принципе. Однако в западных университетах уже готовят технических писателей (специальность «технические коммуникации», technical writing), которые изучают XML-технологии. Такие XML-технологии как DocBook и DITA начинают активно применяться в индустрии, есть также сведения об их применении и в России. Кроме того, в России распространена практика использования языка TeX для верстки печатных изданий, а TeX намного сложнее, чем DocLine.

Затраты на внедрение DocLine оправданы, если требуется разработать ряд похожих и активно эволюционизирующих (дорабатываемых и исправляемых) документов. В такой ситуации DocLine позволяет уменьшить количество точечных изменений текста за счет однократного изменения повторно используемых активов. В том случае, когда документов мало и/или они статичны (разрабатываются один раз и навсегда), или же нет высоких требований к качеству документации, применение DocLine не даст преимуществ перед DocBook, однако сохранит возможность организации адаптивного повторного использования документации в будущем, если на каком-либо этапе развития СПП ситуация изменится.

В шестой главе приводится анализ новизны диссертационной работы.

В заключении сформулированы следующие основные результаты работы.

• Создан и формально специфицирован новый язык разработки документации DRL, включающий возможности визуального проектирования документации, средства для задания адаптивного повторного использования фрагментов документации в XML-формате, средства задания форматирования текста (интеграция с форматом DocBook).

• Предложены две эталонные модели процесса разработки документации СПП: проактивная («сверху-вниз») и «гибкая» («снизу-вверх»).

• Разработаны операции рефакторинга документации, позволяющие создавать и настраивать общие активы в процессе эволюции документации.

• Предложена архитектура пакета инструментальных средств для разработки документации СПП, выполнена реализация пакета на платформах Microsoft.NET (первая версия) и Java/Eclipse (вторая версия).

• Проведена апробация метода и инструментальных средств на документации реальных промышленных продуктов: .NET-версия применена для разработки документации семейства телевещательных систем (ООО «Фирма ДИП»), Eclipse-всрсия - для разработки документации ПО семейства телефонных станций (ЗЛО «Ланит-Терком»).

В Приложении представлено формальное описание синтаксиса языка DRL.

Публикации по теме диссертации из перечня ВАК

1. Романовский К.Ю., Кознов Д.В. Язык DRL для проектирования и разработки документации семейств программных продуктов // Вестн. С.-Петерб. ун-та. Сер. 10: Прикладная математика, информатика, процессы управления. 2007. Вып. 4. С. 110-122.

2. Кознов Д.В., Романовский К.Ю. DocLine: метод разработки документации семейств программных продуктов // Программирование. 2008. №4. С. 1-13.

3. Романовский К.Ю. Разработка повторно-используемой документации семейства телефонных станций средствами технологии DocLine // Вестн. С.-Петерб. ун-та. Сер. 10: Прикладная математика, информатика, процессы управления. 2009. Вып. 2. С. 166-180.

Остальные публикации по теме диссертации

4. Кознов Д.В., Перегудов А.Ф., Романовский К.Ю., Кашин А, Тимофеев А. Опыт использования UML при создании технической документации // Системное программирование. Вып. 1. Сб. статей / Под ред. А.Н. Терехова, Д.Ю. Булычева. СПб.: Изд-во СПбГУ, 2005. С. 18-36.

5. Романовский К.Ю. Метод разработки документации семейств программных продуктов // Системное программирование. Вып. 2 / Под ред. А. Н. Терехова, Д. Ю. Булычева. СПб.: Изд-во С.-Петерб. ун-та, 2007. С. 191-218.

6. К. Romanovsky, D. Koznov, L. Minchin: Refactoring the Documentation of Software Product Lines // Proceedings of 3rd IFIP TC2 Central and East European Conférence on Software Engineering Techniques CEE-SET 2008, Brno (Czech Republic), October 1315, 2008. P. 157-170.

7. Кознов Д.В., Романовский К.Ю. Автоматизированный рефакторинг документации семейств программных продуктов // Системное программирование. Вып. 4 / Под ред. А. Н. Терехова, Д. Ю. Булычева. СПб.: Изд-во С.-Петерб. ун-та, 2009. С. 128150.

Цитируемая литература

8. Кознов, Д.В. Основы визуального моделирования. М.: Изд-во Интернет-университета информационных технологий, ИНТУИТ.ру, БИНОМ, Лаборатория знаний. 2008. 248 с.

9. Atkinson С., Bayer J., Bunse С., et al. Component-Based Product Line Engineering with UML. Addison-Wesley Professional, 2001. 464 p.

10.Bassett, P. Framing software reuse - lessons from real world. Yourdon Press, Prentice Hall, 1997.

11. Bayer I, DeBaud, J.M., FJege, O., Knauber, P., Laqua, R., Muthig, D., Schmid, K. and Widen, T. PuLSE: A Methodology to Develop Software Product Lines // Proc. Symposium on Software Reusability, SSR'99, Los Angeles, May 1999. P. 122-132.

12. Clements, P., Northrop, L. Software Product Lines: Practices and Patterns. Boston, MA: Addison-Wesley, 2002. 608 p.

13.Czarnecki K., Eisenecker U., Generative Programming: Methods, Tools, and Applications. Reading, Mass.: Addison Wesley Longman, 2000. 864 p.

14. Day, D., Priestley, M., Schell, David A. Introduction to the Darwin Information Typing Architecture - Toward portable technical information // http://www-106.ibm.com/developerworks/xml/library/x-dital/

15. Greenfield J., Short K., Cook S., Kent S. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Indianapolis, Indiana: Wiley Publishing, Inc., 2004. P. 696.

16.Jarzabek, S.; Bassett, P.; Hongyu Zhang; Weishan Zhang. XVCL: XML-based variant configuration language // 25th International Conference on Software Engineering, 2003. Proceedings. 3-10 May 2003. P. 810-811.

17. Marques. M. Single-sourcing with FrameMaker // TECHWR-L Magazine Online, http://ww\v.tech'wr-l.com/techwhirl/magazine/technical/singlesourcing.html

18. Walsh N., Muellner L. DocBook: The Definitive Guide. O'Reilly, 2003.

Подписано к печати 05.03.10. Формат 60 *84 1/16 . Бумага офсетная. Гарнитура Тайме. Печать цифровая. Печ. л. 1,0. Тираж 100 экз. Заказ 4628. Отпечатано в Отделе оперативной полиграфии Химического факультета СПбГУ 198504, Санкт-Петербург, Старый Петергоф, Университетский пр., 26 Тел.: (812) 428-40-43,428-69-19

ВВЕДЕНИЕ.

ГЛАВА 1. ОБЗОР СУЩЕСТВУЮЩИХ ПОДХОДОВ.

1.1 Повторное использование.

1.1.1 Метод Бассета-Ерзабека.

1.1.2 Диаграммы возможностей.

1.1.3 Разработка СПП.

1.1.4 Эталонные модели процесса разработки СПП.

1.2 Разработка технической документации.

1.2.1 DocBook.

1.2.2 DITA.

1.2.3 FrameMaker.

1.3 Рефакторинг.

1.4 Предметно-ориентированное моделирование.

1.5 Средства формализации текстовых и графических языков.

1.6 Выводы обзора.

ГЛАВА 2. ЯЗЫК DRL.

2.1 DRL/GR.

2.1.1 Главная диаграмма.

2.1.2 Диаграмма вариативности.

2.1.3 Диаграмма продукта.

2.2 DRL/PR.

2.2.1 Адаптивное крупноблочное повторное использование.

2.2.2 Адаптивное «мелкозернистое» повторное использование.

2.2.3 Условные блоки.

2.3 Интеграция языка DRL с форматом DocBook.

ГЛАВА 3. ПРОЦЕСС РАЗРАБОТКИ ДОКУМЕНТАЦИИ.

3.1 Целесообразность применения DocLine.

3.2 Проактивный процесс.

3.3 «Гибкий» процесс.

3.4 Операции рефакторинга.

3.4.1 Создание общих активов.

3.4.2 Настройка общих активов.

3.4.3 Настройка «мелкозернистого» повторного использования

3.4.4 Переименование.

3.4.5 Пример применения рефакторинга.

ГЛАВА 4. ИНСТРУМЕНТАЛЬНЫЙ ПАКЕТ.

4.1 Архитектура инструментального пакета.

4.2 Текущий статус разработки.

4.3 Графический редактор и менеджер циклической разработки.

4.4 Текстовый редактор.

4.5 Рефакторинг.

4.6 Публикация конечных документов и проверка корректности.

ГЛАВА 5. АПРОБАЦИЯ.

5.1 Объект апробации.

5.2 Ход апробации.

5.2.1 Изучение и анализ предметной области.

5.2.2 Планирование повторного использования.

5.2.3 Выделение и спецификация переиспользуемых компонент.

5.2.4 Задание форматирования документов средствами DocBook.

5.3 Особенности использования DocLine.

5.3.1 Вариативность продуктов семейства.

5.3.2 Схема вариативности документации.

5.3.3 Настройка адаптивности.

5.4 Анализ результатов апробации.

ГЛАВА 6. СРАВНЕНИЯ И СООТНЕСЕНИЯ.

В современных проектах разработки промышленного программного обеспечения возникает множество задач, не менее важных, чем, собственно, само программирование. Одна из таких задач - это разработка документации. Распространенным классом технических документов является пользовательская документация ПО. Сложность современных программных комплексов (структурная сложность, изменчивость, многоверсионность, многообразие ролей пользователей, обилие функций, задачи администрирования и т.д.), а также необходимость их сопровождения на протяжении многих лет - все это предъявляет высокие требования к документации и к процессу ее разработки. Зачастую для одного программного продукта создается целый набор документов, описывающих его с различных сторон, например, руководство по быстрому старту, подробное руководство пользователя, справочник функций, встроенная справочная система, сайт поддержки, учебные материалы, руководство администратора. Все эти документы должны сопровождаться вместе с ПО, поскольку изменения ПО, затрагивающие функциональность или пользовательский интерфейс, должны быть отражены в документации.

Научная общественность активно занимается вопросами разработки технической документации. Одно из наиболее известных сообществ в этой области - ассоциация ACM SIGDOC (Association for Computer Machinery's Special Interest Group on the Design of Communication) [53]. В рамках этого сообщества проводятся ежегодные конференции, охватывающие широкий круг вопросов: специализированные языки и средства разработки электронной документации, качество («понятность») текстов, особенности перевода технических документов на иностранные языки, принципы разработки, сопровождения и обеспечения целостности больших пакетов документов и т.д.

Разработчики инструментального ПО также уделяют внимание задачам разработки технической документации. Существует целый спектр программных средств, обеспечивающих разработку как простых, «одиночных» документов, так и масштабных пакетов документов. Простая документация разрабатывается в редакторах общего назначения, таких как Microsoft Word. Преимущество подобных редакторов - в их простоте и удобстве: практически, любой пользователь ПК способен быстро освоить процедуру создания «одиночных» документов в подобных системах. Для более сложного ПО необходимы средства разработки пакетов документов, поддерживающие многоязычность, версио-нирование документов для различных операционных систем, множественные варианты конечного представления (PDF для печатного руководства, HTML Help для встроенной справочной системы и т.п.). Для таких задач используются специализированные методы и средства, такие как FrameMaker [57] (издательская система компании Adobe), DocBook [51] (open-source стандарт в области разработки документации для Unix/Linux-приложений), DITA [54] (метод разработки сложной модульной документации компании IBM) и другие.

В индустрии разработки ПО активно развивается подход повторного использования [42], основная идея которого состоит в том, что в ПО выделяются фрагменты, которые могут быть использованы неоднократно. Такие фрагменты обосабливаются в отдельные компоненты и затем ПО строится из них. Для разработчиков ПО существует множество подходов организации повторного использования кода, например параграфы в COBOL, функции в процедурных языках, классы и компоненты в объектно-ориентированных языках. Одно время в индустрии считали, что можно разработать набор типовых строительных блоков и потом все новые программные продукты собирать из этих блоков, причем предполагалось, что с такой работой может справиться неспециалист, который будет просто выбирать блоки, нужные для своей задачи. Однако разработка универсальных компонент «на все случаи жизни» оказалась довольно сложным и дорогостоящим занятием - универсальность ограничивала функциональность, и наоборот — развитая специфическая функциональность сужала сферу применения компонент. В этих условиях важнейшим направлением развития механизмов повторного использования становится поддержка адаптивности повторно-используемых блоков. Адаптивность означает возможность «подстраивать» переиспользуемые компоненты к особенностям конкретного контекста использования без влияния на остальные контексты. Примеры механизмов адаптивности — параметризованные функций в процедурном подходе и наследование с полиморфизмом в объектно-ориентированном подходе. Отметим также универсальный метод адаптивного повторного использования, предложенный Полом Бассетом - метод фреймов [16] — на основе которого Стен Ерза-бек разработал язык XVCL [36]. Идея метода фреймов и XVCL применима для организации повторного использования произвольной текстовой информации, однако, фактически, метод фреймов оптимизирован для программ на языке COBOL, a XVCL - для программ на языке Java.

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

Вернемся к задаче разработки документации. В больших пакетах пользовательской документации встречается много фрагментов текста, которые используются почти без изменений в различных контекстах. Это дает основание полагать, что в разработке документации также возможно применять повторное использование. Ряд методов разработки документации — DocBook [51], DITA [54] и др. — поддерживают повторное использование фрагментов текста. Однако на практике фрагменты повторяются не полностью идентично, а с некоторыми модификациями, что значительно осложняет поддержку повторного использования. Па сегодняшний момент поддерживается лишь простая адаптивность — условное включение фрагмента. Этот механизм можно использовать, например, для обработки незначительных различий поведения продукта в разных операционных системах, однако в целом повторно-используемые фрагменты должны быть идентичны во всех контекстах использования, что сильно ограничивает возможности повторного использования. Кроме того, имеется еще одна особенность - тексты предназначаются в первую очередь для человека, вследствие чего очень важную роль играет понятность документации. Поэтому одну и ту же функциональность часто описывают разными словами. В результате при разработке документации применяют простейший метод повторного использования - копирование и исправление (copy/paste/modify): нужный фрагмент копируется и затем модифицируется под требования контекста. Этот метод хорошо подходит для документов, которые создаются «раз и навсегда» и не требуют дальнейшего сопровождения. Однако в случае, когда сопровождение все-таки требуется, любые изменения (расширения, исправление ошибок и т.п.) необходимо вносить независимо во все копии, поскольку при копировании утрачивается связь между исходным фрагментом и его копией.

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

В данной работе предложен новый метод разработки документации семейств программных продуктов DocLine (основные идеи DocLine изложены в работах [8], [9]). Данный метод восполняет разрыв между методами разработки семейств программных продуктов и подходами разработки технической документации. DocLine охватывает весь жизненный цикл разработки документации от проектирования до публикации итоговых документов и поддерживает плановое адаптивное повторное использование. В DocLine явно выделяется исходное и целевое представление документации. Целевое представление - это документы в привычных для пользователя форматах, таких как PDF для печатных документов, HTML для электронных или HTML Help для справочных систем. Целевое представление может быть в любой момент получено из исходного автоматически - эта операция называется публикацией, подобно компиляции исполняемого кода ПО из его исходных текстов.

Для исходного представления документации в DocLine предлагается оригинальный проблемно-ориентированный язык DRL (Documentation Reuse Language) [11]. DRL, подобно другому проблемно-ориентированному языку SDL (Specification and Description Language, [34]), имеет две нотации - графическую (DRL/GR - Graphic Representation) и текстовую (DRL/PR - Phrase Representation). Графическое представление служит для проектирования структуры повторного использования документации. Текстовое представление позволяет описать варианты конфигурирования повторно используемых компонент и, собственно, сами конкретные конфигурации для порождения конечных документов.

Наряду с языком DRL метод DocLine определяет также эталонные модели процесса разработки документации — проактивную и «гибкую». В рамках про-активной модели сначала проводится проектирование схемы повторного использования и разработка адаптивных повторно-используемых компонент, а затем на основе созданной инфраструктуры создаются пакеты документов для конкретных продуктов. В «гибком» процессе сначала создаются требуемые документы, а затем, по мере необходимости, документация подвергается рефак-торингу [7], [47]. То есть на основе конкретных документов стоится инфраструктура повторного использования и исходное представление документов перестраивается на использование этой инфраструктуры, при этом целевое представление остается неизменным.

Для практического применения DocLine предложена архитектура пакета инструментальных средств, на основе которой реализована версия пакета, встроенная в интегрированную среду разработки приложений Eclipse. Также была реализована базовая версия пакета на платформе Microsoft.NET. Для порождения документов в различных целевых форматах (PDF и HTML) DocLine интегрирован с популярной технологией DocBook.

Метод DocLine был апробирован на примере пользовательской документации семейства телекоммуникационных систем, разрабатываемого ЗАО «Ланит-Терком». Продукты семейства — цифровые телефонные станции типа «Квант-Е» различного назначения - офисные, сельские, городские, транзитные и др. Объектом апробации стали руководства пользователя для двух разных продуктов семейства (общим объемом около 300 страниц). Были выделены общие для двух продуктов активы, затем сами руководства были переработаны для совместного использования общих активов. Еще одна апробация была выполнена для документации системы поддержки телевизионного вещания компании ДИП [6]. В семейство входят разнообразные устройства, предназначенные для воспроизведения видео, микширования и т.п. В ходе апробации была разработана документация для нескольких устройств с выделением повторно-используемых фрагментов.

Данная работа выполнена в рамках исследовательского проекта кафедры системного программирования Санкт-Петербургского государственного университета под руководством доцента кафедры к.ф.-м.н. Д. Кознова. Д. Кознов предложил использовать визуальное моделирование для проектирования повторного использования документации и выдвинул идею «гибкого» процесса разработки и рефакторинга. К. Романовский создал метод разработки документации, эталонные модели процесса, разработал и специфицировал язык DRL, спроектировал и разработал инструментальные средства поддержки, а также расширил подход рефакторинга и предложил набор автоматизированных операций рефакторинга. Под его руководством на кафедре системного программирования в рамках данного проекта было выполнено несколько дипломных работ.

Автор выражает благодарность научному руководителю и всем участникам этого проекта. Также автор выражает признательность проф. А. Терехову за методическую помощь и конструктивную критику предлагаемых идей; Т. Поповой, Б. Федотову, А. Тиуновой, А. Ежикову за помощь в понимании потребностей предметной области; А. Перегудову и Б. Любимову за содействие в проведении апробации, а также студентам математико-механического факультета, активно участвовавшим в проекте DocLine: А. Семенову, К. Яковлеву, JI. Минчину, К. Вьюшковой, С. Василинцу, И. Чалову, В. Дорохову, А. Голубеву и Н. Соколову. Особую признательность хочется выразить Т. Дроздовой, которая оказала неоценимую помощь при апробации инструментальных средств, выступив в роли технического писателя и первого пользователя еще «сырого» продукта.

Исследование было поддержано Российским фондом фундаментальных исследований (гранты РФФИ 08-01-00716-а, 08-07-08066-з), Фондом содействия развитию малых форм предприятий в научно-технической сфере (программа СТАРТ), ЗАО «Ланит-Терком», лабораторией СПРИНТ, организованной компаний «Интел» на математико-механическом факультете СПбГУ. На пакет программных средств получено свидетельство о государственной регистрации программы для ЭВМ №2008612676, выданное 28 апреля 2008 г. Федеральной службой по интеллектуальной собственности, патентам и товарным знакам.

Заключение

В ходе выполнения данного диссертационного исследования достигнуты следующие результаты.

• Создан и формально специфицирован новый язык разработки документации DRL, включающий возможности визуального проектирования документации, средства для задания адаптивного повторного использования фрагментов документации в XML-формате, средства задания форматирования текста (интеграция с форматом DocBook).

• Предложены две эталонные модели процесса разработки документации

СПП: проактивная («сверху-вниз») и «гибкая» («снизу-вверх»).

• Разработаны операции рефакторинга документации, позволяющие создавать и настраивать общие активы в процессе эволюции документации.

• Предложена архитектура пакета инструментальных средств для разработки документации СПП, выполнена реализация пакета на платформах Micro-soft.NET (первая версия) и Java/Eclipse (вторая версия).

• Проведена апробация метода и инструментальных средств на документации реальных промышленных продуктов: .NET-версия применена для разработки документации семейства телевещательных систем (ООО «Фирма ДИП»), Edipse-версия - для разработки документации ПО семейства телефонных станций (ЗАО «Ланит-Терком»).

В дальнейшем планируется развивать DocLine в следующих направлениях.

• Разработка специализированных шаблонов итоговых документов, например, для создания документации в соответствии с ГОСТ ЕСПД.

• Интеграция с существующими средствами разработки СПП.

• Разработка интеллектуальных операций рефакторинга, помогающих техническому писателю найти общие активы.

1. Ахо А. В., Лам М. С., Сети Р., Ульман Д. Д. Компиляторы: принципы, технологии и инструментарий, 2 издание. М.: Вильяме, 2008. 1184 с.

2. Буч Г., Рамбо Д., Якобсон А. Язык UML. Руководство пользователя. Второе издание. М.: ДМК-пресс. 2006. 496 с.

3. Кнут Д. Все про ТеХ. М.: Вильяме, 2003. 560 с.

4. Кознов, Д.В. Основы визуального моделирования. М.: Изд-во Интернет-университета информационных технологий, ИНТУИТ.ру, БИНОМ, Лаборатория знаний. 2008. 248 с.

5. Кознов Д.В., Романовский К.Ю. Автоматизированный рефакторинг документации семейств программных продуктов // Системное программирование. Вып. 4 / Под ред. А. Н. Терехова, Д. Ю. Булычева. СПб.: Изд-во С.-Петерб. унта, 2009. С. 128-150.

6. Кознов Д.В., Романовский К.Ю. DocLine: метод разработки документации семейств программных продуктов // Программирование. 2008. №4. С. 1-13.

7. Романовский К.Ю. Метод разработки документации семейств программных продуктов // Системное программирование. Вып. 2 / Под ред. А. Н. Терехова,

8. Д. Ю. Булычева. СПб.: Изд-во С.-Петерб. ун-та, 2007. С. 191-218.

9. Романовский К.Ю. Разработка повторно-используемой документации семейства телефонных станций средствами технологии DocLine // Вестн. С.-Петерб. ун-та. Сер. 10: Прикладная математика, информатика, процессы управления. 2009. Вып. 2. С. 166-180.

10. Романовский К.Ю., Кознов Д.В. Язык DRL для проектирования и разработки документации семейств программных продуктов // Вестн. С.-Петерб. унта. Сер. 10: Прикладная математика, информатика, процессы управления. 2007. Вып. 4. С. 110-122.

11. Albing В. Combining Human-Authored and Machine-Generated Software Product Documentation // Proceedings of the IEEE International Professional Communication Conference, 2003. 21-24 Sept. 2003. P. 6-11.

12. Assmann U. Automatic Roundtrip Engineering // SC 2003, Workshop on Software Composition. Warsaw, Poland, April 2003. Electronic Notes in Theoretical Computer Science (ENTCS) 82, No. 5. 2003. P. 1-9.

13. Atkinson C., Bayer J., Bunse C., et al. Component-Based Product Line Engineering with UML. Addison-Wesley Professional, 2001. 464 p.

14. Bassett P. Framing software reuse lessons from real world. Prentice Hall, 1996. 365 p.

15. Bassett P. Frame-Based Software Engineering, IEEE Software, July, 1987. P. 9-16.

16. Batory D., Lofaso В., Smaragdakis Y. JST: Tools for Implementing Domain-Specific Languages. // Proc. 5th Int. Conf. on Software Reuse, Victoria, ВС, Canada. 1988. P. 143-153.

17. Bayer J., DeBaud J.M., Flege O., Knauber P., Laqua R., Muthig D., Schmid K. and Widen T. PuLSE: A Methodology to Develop Software Product Lines, Proc. Symposium on Software Reusability, SSR'99, Los Angeles, May 1999. P. 122-132.

18. Calheiros F., Borba P., Soares S., Nepomuceno V., Vander Alv.: Product Line Variability Refactoring Tool. 1st Workshop on Refactoring Tools, Berlin. 2007.

19. Ceri S., Fraternali P., Bongio A. Web Modeling Language (WebML): a modeling language for designing Web sites // Computer Networks. 2000. Vol. 33, N 1-6. P. 137-157.

20. Chen L., Babar M. A., Ali N. Variability Management in Software Product Lines: A Systematic Review // Proceedings of 13th International Software Product Line Conference (SPLC 2009), Aug 24-28, 2009, San Francisco, CA.

21. Clark D. Rhetoric of Present Single-Sourcing Methodologies // Proceedings of the 20th ACM annual international conference on Computer documentation, Toronto, Ontario, Canada. 2002. P. 20-25.

22. Clements P. Being Proactive Pays Off. // IEEE Software July/August 2002. P. 28-30.

23. Clements P., Northrop L. Software Product Lines: Practices and Patterns. Boston, MA: Addison-Wesley, 2002. 608 p.

24. Critchlow M., Dodd K., Chou J,, van der Hoek A. Refactoring product line architectures // IWR: Achievements, Challenges, and Effects. 2003. P. 23-26.

25. Czarnecki K., Eisenecker U., Generative Programming: Methods, Tools, and Applications. Reading, Mass.: Addison Wesley Longman, 2000. 864 p.

26. Dunn M. Single-Source Publishing with XML // IEEE IT Professional, January/February 2003. P. 51-54.

27. Fowler M., et al. Refactoring: Improving the Design of Existing Code. Addison-Wesley. 1999.

28. Fraley, Liz. Beyond Theory: Making Single-Sourcing Actually Work // Proceedings of the 21st Annual International Conference on Computer Documentation. New York: ACM Press, 2003. P. 52-59.

29. Greenfield J., Short K., Cook S., Kent S. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Indianapolis, Indiana: Wiley Publishing, Inc. 2004. 696 p.

30. Griss M., Favaro J., d' Alessandro M. Integrating Feature Modeling with RSEB. // IEEE Proceedings of Fifth International Conference on Software Reuse, 1998. P. 76-85.

31. Haramundanis K., Rowland L. Experience paper: a content reuse documentation design experience // Proceedings of the 25th annual ACM international conference on Design of communication, El Paso, Texas, USA. 2007. P. 229-233.

32. Houser R. Single-sourcing Online Help and Training Manuals // Proceedings of IEEE International Professional Communication Conference. 2005. P. 404-413

33. ITU-T Recommendation Z.100: Specification and description language (SDL). 1999.244 р.

34. Jaaksi A. Developing Mobile Browsers in a Product Line // IEEE Software July/August 2002. P. 73-80.

35. Jarzabek S.; Bassett P.; Hongyu Zhang; Weishan Zhang. XVCL: XML-based variant configuration language // Proc. of 25th International Conference on Software Engineering, 3-10 May 2003. P. 810-811.

36. Kang K., Cohen S., Hess J., Novak J., et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study // Technical Report, CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, 1990.

37. Kang К., Lee J., Donohoe P. Feature-Oriented Product Line Engineering // IEEE Software July/August 2002. P. 58-65.

38. Krueger C. Eliminating the Adoption Barrier // IEEE Software July/August 2002. P. 30-31.

39. Krueger C. New Methods in Software Product Line Practice // Communications Of The ACM. December 2006/Vol. 49, No. 12. P. 37-^0.

40. McConnell S. Rapid Development. Microsoft Press, 1996. 680 p.

41. Northrop L. SEI's Software Product Line Tenets // IEEE Software July/August 2002. P. 32-40.

42. Parnas D. On the Design and Development of Program Families // IEEE Transactions on Software Engineering, March 1976. P. 1-9.

43. Rockley A., Kostur P., Maiming S. Managing Enterprise Content: A Unified Content Strategy. Berkeley, CA: New Riders Press, 2002. 592 p.

44. Romanovsky K. Generation-Based Software Product-Line Evolution: A Case Study. // Proceedings of 2nd International Workshop New Models of Business: Managerial Aspects and Enabling Technology. Edited by N. Krivulin, 2002. P. 178-186.

45. Steele К. The road to single-sourcing: a case study // Proceedings of IEEE International Professional Communication Conference, 2001. P. 141-149.

46. Tolvanen J., Kelly S. Defining Domain-Specific Modeling Languages to Automate Product Derivation: Collected Experiences. // Proceedings of Software Product Line Conference'2005. Lecture notes in computer science vol. 3714, 2005. P. 198— 209.

47. Trujillo S., Batory D., Diaz O.: Feature Refactoring a Multi-Representation Program into a Product Line. // Proc. of the 5th Int. Conf. on Generative Programming and Component Engineering, 2006. P. 191-200.

48. Walsh N., Muellner L. DocBook: The Definitive Guide. O'Reilly, 1999. 644 p.

49. Yang J., Jarzabek S. Applying a Generative Technique for Enhanced Reuse on J2EE Platform, 4th Int. Conf. on Generative Programming and Component Engineering, GPCE'05, Sep 29 Oct 1, 2005, Tallinn, Estonia. P. 237-255.

50. Association for Computing Machinery's Special Interest Group on the Design of Communication. URL: http://www.sigdoc.org/.

51. Day D., Priestley M., Schell, David A. Introduction to the Darwin Information Typing Architecture Toward portable technical information. URL: http://www-106.ibm.com/developerworks/xml/library/x-dital/.

52. The DocBook project Site. URL: http://docbook.sourceforge.net/.

53. Eclipse project official site. // http://www.eclipsc.org.

54. Marques M. Single-sourcing with FrameMaker. // TECHWR-L Magazine Online. http://www.techwr-l.com/techwhirl/magazinc/technical/singlesourcing.html.

55. Northrop L., Clements P et al. A Framework for Software Product Line Practice. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2007. URL: http://www.sei.cmu.edu/productlines/.