научная статья по теме DOCLINE: МЕТОД РАЗРАБОТКИ ДОКУМЕНТАЦИИ СЕМЕЙСТВ ПРОГРАММНЫХ ПРОДУКТОВ Математика

Текст научной статьи на тему «DOCLINE: МЕТОД РАЗРАБОТКИ ДОКУМЕНТАЦИИ СЕМЕЙСТВ ПРОГРАММНЫХ ПРОДУКТОВ»

- СРЕДСТВА РАЗРАБОТКИ ПРОГРАММ -

УДК 004.434:004.42

DocLine: МЕТОД РАЗРАБОТКИ ДОКУМЕНТАЦИИ СЕМЕЙСТВ ПРОГРАММНЫХ ПРОДУКТОВ*

© 2008 г. Д. В. Кознов, К. Ю. Романовский

Математико-механический факультет, Санкт-Петербургский государственный университет 198504 Санкт-Петербург, Старый Петергоф, Университетский пр., 28 E-mail: dim@dkl2687.spb.edu, kromanovsky@yandex.ru Поступила в редакцию 13.11.2007 г.

В работе представляется метод DocLine, предназначенный для разработки документации семейств программных продуктов. Метод обеспечивает повторное использование фрагментов документов с адаптации под контекст использования. Метод состоит из языка DRL (Documentation Reuse Language), имеющего графическую (для проектирования структуры пакета документов) и текстовую (для реализации документации) части, включает процесс разработки документации и архитектуру программных средств на базе DSM-подхода и технологии Eclipse GMF.

ВВЕДЕНИЕ

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

Одно из наиболее активных сообществ в области разработки технической документации -ACM SIGDOC1, которое проводит многочисленные конференции, посвященные этой тематике. Существует много средств и методов разработки электронной документации. Простая документация разрабатывается в редакторах общего назначения, таких, как Microsoft Word. Для более сложной используются специализированные методы и средства, такие, как FrameMaker [1] (издательская система компании Adobe), DocBook [2] (open-source стандарт в области разработки

* Исследование выполнено при поддержке РФФИ (грант 08-01-00716-а), а также корпорации Intel.

1 Association for Computer Machinery's Special Interest Group on the Design of Communication.

документации для Unix/Linux-приложений), DITA [3] (метод разработки сложной модульной документации компании IBM) и другие.

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

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

К сожалению, в рамках СПП разработка пользовательской документации ПО не выделена в отдельную задачу, отсутствуют подходящие методы и инструментальные средства. Такие технологии, как FrameMaker, DocBook, DITA, поддерживают повторное использование, но не обеспечивает адаптивности, то есть повторно-используемые фрагменты должны быть идентичны во всех контекстах использования. Отсутствие поддержки адаптивности сильно ограничивает возможности повторного использования. Метод Бассета позволяет повторно использовать произвольную электронную информацию [5] и обеспечивает адаптивность. Однако он не применялся для управления повторным использованием документации. Наконец, существует очень перспективный подход к управлению повторным использованием с помощью визуального моделирования - это диаграммы возможностей (Feature Diagrams) [6]. Однако данный метод также не применялся для управления повторным использованием документации.

В [7] очерчены основные идеи метода DocLine, интегрирующего различные техники повторного использования в единую технологию разработки пользовательской документации СПП. В [8] подробно описана составная часть DocLine -язык DRL, который обеспечивает адаптивное повторное использование документации и состоит из двух частей - графического представления (DRL/GR) и текстового представления (DRL/PR). Графическое представление служит для проектирования пакета документации с учетом повторного использования, текстовое представление обеспечивает XML-реализацию повторного использования, а также служит для задания полиграфической разметки текста документов. В работе [9] представлена апробация метода DocLine в разработке документации для семейства систем управления телевещанием.

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

подхода и технологии GMF. Заложены средства интеграции с DocBook, а также многоуровневая диагностика корректности документации.

Мы хотим выразить признательность руководству лаборатории СПРИНТ (системного программирования и информатики), созданной при математико-механическом факультете СПбГУ при поддержке корпорации Intel, за помощь и поддержку в организации учебно-исследовательских проектов, результаты которых были использованы в данной статье.

1. ОБЗОР

В этом разделе мы рассмотрим контекст нашей работы - СПП-парадигму, а также технологии разработки технической документации, в которых есть средства повторного использования - DITA, DocBook, FrameMaker. Кроме того, мы кратко опишем ряд методов и технологий, которые мы использовали в нашем подходе:

• метод фреймов Бассета [5], предназначенный для адаптивного повторного использования электронной информации произвольной природы;

• подход к визуальному моделированию вариативных свойств семейств программных продуктов - Feature Diagrams [10];

• DSM-подход, допускающий быстрое проектирование и реализацию предметно-ориентированных средств визуального моделирования [11], а также конкретную DSM-технологию Eclipse GMF.

1.1. Семейства программных продуктов

Повторное использование ad hoc - когда-нибудь и кем-нибудь - не прижилось в индустрии. Не получили широкого использования компоненты, которые бы покупались и использовались в разработке в виде готовых блоков. Объем уникального кода в разработках ПО остается очень большим, что не позволяет увеличить размах производства ПО и понизить его трудоемкость и риски. Стало понятно, что повторное использование надо тщательно готовить.

Парадигма СПП, во-первых, сужает контекст повторного использования, ограничивая его группой сходных проектов одной компании.

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

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

Легковесный процесс "снизу вверх" [17] рекомендует начинать с разработки конкретного продукта. Затем, когда наступит очередь создавать второй продукт, необходимо выделить общие активы из первого продукта и на их основе выполнить разработку второго и рефакторинг первого. Основное отличие от тяжеловесного подхода - общие активы создаются только тогда, когда они действительно нужны более чем для одного существующего продукта.

1.2. Средства разработки документации

DocBook - технология разработки документации, предложенная в 1991 г. компаниями HaL Computer Systems и O'Reilly&Associates. Ее основная идея - разделение содержания документа и его форматирования, что позволяет создать единое исходное представление документа (single source) и на этой основе автоматически генерировать документацию в различных фор-

2 Идея совместной разработки группы программных систем была предложена еще в 1976 г. Парнасом [12]. Сегодня в мире существует два научных центра, вокруг которых сосредоточены исследования в области методов разработки линеек программных продуктов. Это Институт Программной Инженерии (SEI) университета Карнеги-Мелон в США [13] и Европейский Институт Программного Обеспечения [14]. Данной тематике посвящены сотни публикаций, многочисленные научные симпозиумы и конференции.

матах, например, печатную документацию (PDF), справочные системы (HTMLHelp/WinHelp), электронную документацию (HTML) [18].

Технология включает в себя язык, который позволяет выполнить полиграфическую разметку и форматирование текстов документов. Современная версия является XML-языком, описание схемы является открытым, стандартизовано консорциумом OASIS и доступно в нескольких форматах - DTD, XML Schema, Relax NC3.

Целый ряд инструментальных средств поддерживает разработку документов DocBook. В первую очередь, это пакет XSLT-трансформа-ций, позволяющий по документам DocBook получить документы в виде HTML, HTMLHelp, FO, PDF, RTF и в некоторых других форматах [19]. Также многие коммерческие XML-редак-торы (например, XML Spy и Oxygen) предлагают поддержку редактирования DocBook-документов.

В настоящее время DocBook широко используется для разработки документации операционных систем семейства UNIX (FreeBSD, Linux), а также в мире разработки открытого ПО.

Технология DITA п

Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.

Показать целиком