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

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

Романовский

Константин Юрьевич

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

СЕМЕЙСТВ ПРОГРАММНЫХ ПРОДУКТОВ

05.13.11 – математическое и программное обеспечение

вычислительных машин, комплексов, систем и сетей

Диссертация на соискание ученой степени кандидата физико-математических наук

Научный руководитель – к.ф.-м.н., доцент Кознов Д.В.

Санкт-Петербург 2010 Содержание ВВЕДЕНИЕ

ГЛАВА 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. СРАВНЕНИЯ И СООТНЕСЕНИЯ

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ: СИНТАКСИС ЯЗЫКА DRL

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

Научная общественность активно занимается вопросами разработки технической документации. Одно из наиболее известных сообществ в этой области – ассоциация 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, а 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: А. Семенову, К. Яковлеву, Л.

Минчину, К. Вьюшковой, С. Василинцу, И. Чалову, В. Дорохову, А. Голубеву и Н. Соколову. Особую признательность хочется выразить Т. Дроздовой, которая оказала неоценимую помощь при апробации инструментальных средств, выступив в роли технического писателя и первого пользователя еще «сырого»

продукта.

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

Глава 1. Обзор существующих подходов В этом разделе рассматриваются основные существующие технологии разработки повторно-используемой технической документации, с акцентом на возможности повторного использования. Также затронуты подход повторного использования и разработки СПП, понятие рефакторинга, описывается открытая интегрированная среда разработки Eclipse, в которую встраивается инструментальный пакет DocLine. Наконец, приводится формализм спецификации языков, который мы используем для формального описания DRL.

1.1 Повторное использование Различают два вида повторного использования – случайное и плановое [42]. Случайное повторное использование предполагает, что разработчики подключают существующие компоненты, когда и если представляется такая возможность. Плановое повторное использование предполагает систематическую разработку компонент, подготовленных для повторного использования и дальнейшее применение таких компонент в разработке. Далее мы будем рассматривать плановое повторное использование, а именно рассмотрим универсальные методы повторного использования произвольной текстовой информации (фреймы Бассета и XVCL), а также диаграммы возможностей – подход управления повторным использованием.

1.1.1 Метод Бассета-Ерзабека Фреймы Бассета [15] – это универсальный подход к повторному использованию произвольной информации, разработанный в 1980-х годах Полом Бассетом в университете Йорк (г. Торонто, Канада). Пол Бассет проанализировал различные подходы к повторному использованию информации, а также практику их применения, и пришел к выводу, что в различных контекстах переиспользуемые модули должны различаться – такое повторное использование называется адаптивным. Информация в методе Бассета представляется в виде архетипа и набора дельт. Архетип – это модель или шаблон, общее в разных информационных объектах, дельта – это различия объектов.

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

Существует несколько вариантов языка разметки, реализующего метод фреймов. Их объединяет общий набор основных конструкций – фрейм (архетип), точки расширения (предусмотренные позиции, в которых архетип может быть модифицирован), адаптация фрейма (дельта). Последняя реализация языка фреймов – проект XVCL, разрабатываемый группой ученых из Университета Сингапура под руководством Станислава Ерзабека с начала 2000-х годов [36].

В этой реализации предлагается использовать XML как основу языка разметки.

XVCL предназначался для организации платформенно-независимого повторного использования в программных приложениях, наиболее впечатляющие успехи были достигнуты для Java-приложений [52]. Язык XVCL использовался также для повторного использования UML-спецификаций [36].

Классической реализацией метода Бассета является продукт Netron Fusion компании Netron1. Этот продукт появился в 1980-х годах, предназначался для реструктуризации программ на языке COBOL и имел значительный коммерческий успех. Популярность этого продукта связана с тем, что в оригинальном языке COBOL отсутствуют встроенные средства структуризации кода. ОбщеNetron Fusion Site URL: http://www.netron.com.

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

1.1.2 Диаграммы возможностей При создании сложных систем в индустрии разработки ПО традиционно используются методы и средства визуального моделирования [5]. В частности, при разработке семейств программных продуктов нередко используются UML [14], а также модель возможностей (feature model) [18], [26], [37], [38] и предметно-ориентированные визуальные языки (Domain-Specific Modeling Languages) [49]. Основной источник проблем, возникающих при использовании визуального моделирования при разработке СПП, – необходимость моделировать все возможные различия продуктов семейства (т.е. вариативность семейства). В большинстве подходов интеграция вариативности в модели и визуальный язык приводит к тому, что модели и диаграммы становятся громоздкими и бесполезными.

Наиболее удачно проблема моделирования вариативности семейства продуктов решена в модели возможностей [21], впервые предложенной в работе [37] в 1990 г. группой исследователей из института программной инженерии США во главе с Кио Кангом (Kyo Kang). Основная цель этой модели – в наглядном виде формализовать архетипы и дельты в СПП. Ключевое понятие модели – это возможность (feature), то есть обособленное свойство системы, распознаваемое с точки зрения пользователя или разработчика. Модель возможностей – это набор возможностей и иерархических связей между ними с явно выделенным корнем иерархии, который называется концептом (concept) [26].

Иерархическая связь отображает декомпозицию концепта или возможности и называется отношением включения. Модель возможностей строится в основном на этапе анализа семейства программных продуктов и характеризует семейство в целом.

Основная задача модели возможностей – формализовать общие и различные свойства продуктов семейства. Для этого применяются различные разновидности отношения включения.

Для изображения модели возможностей используются диаграммы возможностей. Фрагмент диаграммы возможностей в классической нотации [26] изображен на Рис. 1.

Диаграмма на Рис. 1 описывает семейство телефонных аппаратов «Унител», в которых могут быть реализованы исходящие звонки, входящие звонки, автоответчик и АОН (автоматический определитель номера). Прямоугольником изображается концепт или возможность. Надпись, содержащаяся внутри прямоугольника – это имя соответствующей сущности. Линия, соединяющая концепт с возможностью либо две возможности между собой, изображает обязательное включение (возможность «исходящие звонки» требует наличия возможности «Номеронабиратель»), либо необязательное включение, если линия помечена кружочком со стороны подвозможности (телефонный аппарат может содержать возможность «Автоответчик»).

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

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

В ситуации, когда в каждом продукте может быть представлена не более чем одна возможность, используется ограничение «альтернативное включение»

(XOR-группа). Для обозначения альтернативного включения линии отношений, на которые накладывается ограничение, соединяются дугой. На Рис. 1 альтернативное включение используется для выражения того факта, что АОН может быть либо российским (ГОСТ), либо европейским (Caller ID).

Любое отношение включения, кроме обязательного включения, является точкой вариации. Точка вариации – это позиция в модели возможностей, которая описывает варианты различной компоновки возможностей в составе различных продуктов семейства.

Существует несколько реализаций диаграмм возможностей (например, Feature Modeling Plug-in1 и XFeature2), но все они являются исследовательскими проектами. Диаграммы возможностей в оригинальном варианте не имеют исполнимой семантики, то есть могут использоваться только на этапах анализа и, в меньшей степени, проектирования ПО и никак не связаны с артефактами последующих этапов, такими как программный код и документация. Различные методы разработки семейств программных продуктов могут определять собственную семантику модели возможностей. Например, она может применяться для конфигурирования продуктов семейства, как предлагается в методе FeaturSEB [31], или как основная модель семейства, вокруг которой интегрируется весь процесс разработки, как в методе DEMRAL [41].

http://gsd.uwaterloo.ca/projects/fmp-plugin/.

http://www.pnp-software.com/XFeature/.

1.1.3 Разработка СПП Разработка семейств программных продуктов завоевывает популярность как в среде исследователей, так и в индустрии [43]. Основная идея, лежащая в основе большинства методов разработки СПП, и впервые предложенная в методе FODA [37], заключается в явном разделении всего процесса на две части – разработку общих активов (domain engineering) и разработку конкретных продуктов семейства (application engineering) [17], [36], [37], [38].

В монографии [30] выделяются две составляющие процесса разработки СПП – разработка семейства продуктов (аналог domain engineering в FODA, см.

Рис. 2) и разработка продуктов (аналог application engineering в FODA, см. Рис.

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

На этапе анализа семейства необходимо определить, какие продукты могут разрабатываться в рамках семейства, а также выделить общие и вариативные свойства продуктов семейства.

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

Основные задачи

этапа реализации семейства – реализовать общие активы семейства, в том числе активы процесса в соответствии с планом автоматизации процесса разработки продуктов.

Анализ семейства продуктов семейства продуктов Определение границ предметной области Определение границ Анализ бизнеспоказателей Определение состава Процесс разработки продукта в рамках семейства изображен на Рис. 3.

Рис. 3. Процесс разработки продукта в рамках СПП.

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

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

Основная задача этапа разработки вспомогательных материалов – выпустить все необходимые активы продукта, не имеющие отношения к исполняемому коду, в частности, маркетинговые материалы, документацию, упаковку и т.п.

Главная задача этапа реализации продукта – разработать требуемый продукт.

1.1.4 Эталонные модели процесса разработки СПП Выделяются два типа процессов разработки СПП (также называемых типами эволюции СПП) – проактивные («сверху-вниз», тяжеловесные) [23] и гибкие («снизу-вверх», реактивные, легковесные) [39]. Проактивные процессы предписывают сначала выполнить проектирование семейства, разработать повторно-используемые компоненты, а только затем начинать разработку конкретных продуктов. Некоторые проактивные методы, например [40] предлагают сначала описать и реализовать все возможные конфигурации СПП, а затем получать продукты за счет сочетания и конфигурирования заранее предусмотренных возможностей. «Гибкие» подходы, напротив, предлагают начинать с конкретных продуктов и по мере необходимости выделять повторно используемые активы.

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

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

1.2 Разработка технической документации Зрелые подходы к разработке технической документации обеспечивают отделение содержания документа (контента) от его форматирования. Суть этого принципа состоит в том, что технический писатель при работе над текстом не должен беспокоиться о нюансах полиграфического оформления – достаточно соблюдать логическую структуру текста в виде глав, параграфов и других частей, а правила их форматирования задаются отдельно и могут быть модифицированы независимо от самого текста. Одной из первых реализаций этой идеи была система Дональда Кнута TeX [4]. Затем, с появлением форматов SGML и XML, эта идея стала активно использоваться во вновь создаваемых технологиях и подходах разработки документации (см., например, [51], [54]), а также в различных внутрикорпоративных решениях [29], [32], [12].

Другая тенденция современных подходов к разработке технической документации – использование принципа единого исходного представления (single sourcing), заключающийся в том, что из единого внутреннего представления текста могут быть сгенерированы различные целевые форматы – HTML, PDF и др. [27], [48], [33].

Рассмотрим несколько подходов подробнее.

1.2.1 DocBook Технология DocBook появилась в 1991 г. усилиями компаний HaL Computer Systems и O'Reilly&Associates. Ее основная идея – разделение содержания документа и его форматирования, что позволяет создать единое исходное представление документа (single source) и на его основе автоматически генерировать документацию в разных форматах, например, печатная документация (PDF), справочная система (HTMLHelp/WinHelp), электронная документация (HTML) [45].

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

DocBook-документация имеет «монолитную» структуру, что затрудняет повторное использование. Однако поскольку DocBook является XML-языком, для него доступны стандартные для XML средства выделения модулей и их подключения, такие как XInclude. Основной недостаток такого подхода – для указания включаемого фрагмента требуется указывать различные технические параметры, такие как имя файла и т.п. Также этот механизм предполагает, что подключаемые фрагменты используются «as is», без модификации под особенности контекста.

Organization for the Advancement of Structured Information Standards Site URL:

http://www.oasis-open.org/.

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

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

1.2.2 DITA Технология DITA была разработана компанией IBM в 2001 г. для создания модульной технической документации [54]. В отличие от «монолитной» документации DocBook, документация в DITA представляется в виде набора независимых топиков (topic), которые могут иметь различные типы. Таким образом поддерживается повторное использование крупных и логически завершенных фрагментов текста в разных контекстах. В дальнейшем будем называть такое повторное использование крупноблочном.

Язык форматирования документов DITA, также как и DocBook, основан на XML и позволяет не только описывать топики, но полностью задать форматирование текста. DITA позволяет также организовать повторное использование небольших фрагментов текста – отдельных слов, фраз, терминов, фрагментов предложений и т.д.

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

Инструментальные средства DITA содержат пакет преобразований документов DITA в различные выходные форматы. Формат DITA стандартизован международным комитетом OASIS и поддерживается многими XMLредакторами – XML Spy, Oxygen, Frame Maker и др. Стандартные инструменты DITA скорее являются экспериментальными и уступают DocBook в части полиграфического оформления текста. Тем не менее, в ряде крупных компаний, например в IBM, DITA вполне успешно применяется для разработки больших пакетов документов, содержащих много однообразной информации.

1.2.3 FrameMaker Продукт FrameMaker разрабатывается компанией Adobe1 и является универсальным текстовым WYSIWIG-редактором [57]. Благодаря стабильности при работе с большими пакетами документов, а также развитой поддержке полиграфии, FrameMaker, фактически, стал стандартом де-факто в разработке технической документации. FrameMaker поддерживает структурное редактирование документов на основе аналога XML-схем, с помощью своего встроенного языка, а также дает возможность использовать DocBook, DITA и другие языки XML-разметки.

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

Adobe FrameMaker Site URL: http://www.adobe.com/products/framemaker/.

1.3 Рефакторинг Рефакторинг – это процесс изменения программной системы, выполняемый таким образом, что внешнее поведение системы не изменяется, но при этом улучшается ее внутренняя структура [28]. Рефакторинг приобрел популярность в «гибких» подходах разработки ПО, поскольку он является альтернативой дорогостоящему предварительному проектированию, обеспечивая постоянные улучшения архитектуры системы с сохранением ее поведения в рамках итеративно-инкрементальной модели процесса разработки ПО, наиболее популярной в настоящее время на практике.

Рефакторинг помогает выполнить такие задачи, как улучшение структуры и внешнего вида программного кода (удаление недостижимого кода, упрощение условных выражений и т.п.), улучшение объектно-ориентированной иерархии (извлечение новых классов, перемещение полей вверх/вниз по иерархии и т.п.). Также есть так называемые «большие рефакторинги», например переход от процедурного к объектно-ориентированному подходу.

Рефакторинг ПО можно выполнять «вручную», однако при этом сложно убедиться в том, что поведение системы остается неизменным. Например, такое действие, как переименование метода, на первый взгляд, кажется тривиальным, однако оно включает в себя поиск и исправление всех вызовов этого метода (включая вызовы через объекты всех классов-потомков) и может затронуть весь исходный код приложения. Имеются инструментальные средства, облегчающие рефакторинг путем автоматизации типичных операций с обеспечением корректности преобразований исходных текстов программ (в данном случае корректность означает сохранение компилируемости кода и его внешнего поведения) – например, Eclipse для языка Java. Такие средства, как интегрированная среда разработки IntelliJ IDEA1 для языка Java поддерживают «ручной» рефакIntelliJ IDEA Site URL: http://www.jetbrains.com/idea/.

торинг, предоставляя средства для автоматизированного регрессионного тестирования выполненных изменений (в том числе включая модульное тестирование).

В рамках разработки СПП появляется важное направление для рефакторинга – повторно-используемые активы и архитектура семейства. Рефакторингу СПП посвящены многие исследования. Так в [19] предлагается метод рефакторинга модели возможностей для расширения множества возможных конфигураций семейства, то есть увеличения потенциала для создания новых продуктов. В [50] авторы предлагают метод декомпозиции приложения на набор возможностей – в результате такого преобразования монолитное приложение преобразуется в набор модулей, которые впоследствии можно использовать для разработки новых продуктов.

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

1.4 Предметно-ориентированное моделирование Предметно-ориентированное моделирование (DSM, Domain-Specific Modeling) [30] – подход, который был предложен в конце 1990-х гг. и в настоящее время поддерживается и развивается такими компаниями, как Microsoft, IBM, Borland и др. Его основная идея – ограничение предметной области (вплоть до специфики конкретного проекта разработки ПО) и повышение за счет этого уровня используемых абстракций визуальных языков [49]. DSM-подход является альтернативой стандарту в области визуального моделирования – языку UML, – поскольку последний, являясь универсальным языком, плохо подходит для решения отдельных, частных задач индустрии.

В настоящее время бурно развиваются различные технологи поддержки DSM-подхода. Одна из них, GMF (Graphical Modeling Framework)1, входит в состав платформы Eclipse и разрабатывается при участии таких компаний, как IBM, Borland, HP, BEA и Red Hat. Eclipse GMF позволяет по метамодели языка и набору описаний сгенерировать репозиторий, графические редакторы, процедуры сохранения/ восстановления моделей и диаграмм. Сгенерированные инструментальные средства интегрируются в платформу Eclipse, обеспечивая привычный для многих разработчиков пользовательский интерфейс и возможность взаимодействия с большим количеством бесплатных и коммерческих модулей расширения.

1.5 Средства формализации текстовых и графических языков Для современных систем программирования характерно, что у программ есть два основных представления: исходное и целевое. Исходное представление обычно определяется текстовым и/или графическим языком, таким как Java, C++, SDL и т.п. Целевое представление – это или исполнимый код в формате инструкций конкретной ЭВМ и заданной ОС (например, Intel x86 под управлением ОС Windows XP), или байт-код для заданной виртуальной машины (например, для Microsoft.NET Framework или для виртуальной машины Java). В области разработки документации также есть средства, поддерживающие разделение исходного и целевого представления документов. Одна из самых известных таких систем – это TeX [4]. Большинство современных промышленных методов и средств разработки документации (например, DocBook [51], DITA [54], FrameMaker [57]) также разделяют исходное и целевое представление документов. В качестве исходного представления, как правило, используетEclipse GMF URL: http://www.eclipse.org/modeling/gmf/.

ся XML-язык, а целевое представление может быть различным в зависимости от назначения – PDF для печатных документов, HTML для электронных и т.п.

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

Этот подход используется автором при описании языка DRL, поэтому остановимся на нем детальнее. Абстрактный синтаксис DRL формально задает все конструкции языка без привязки к конкретному представлению (текстовому или графическому). Для описания абстрактного синтаксиса используется форма представления грамматик НФБН (Нормальная Форма Бэкуса-Наура) [1]. Ниже представлен фрагмент описания конструкции.

Полная спецификация абстрактного синтаксиса языка DRL представлена в приложении.

Конкретный синтаксис для DRL – это описание графической нотации. Для описания графической нотации используется расширение НФБН, содержащее следующие бинарные инфиксные операторы: содержит, соединяется с. Оператор содержит означает, что графическое изображение левого аргумента содержит в себе отображение правого элемента. Следующий текст описывает графическую нотацию конструкции.

Пример изображения конструкции :

Оператор «соединяется с» означает, что левый аргумент и правый аргумент в графическом представлении связаны друг с другом, например, набор следующих правил:

описывает следующую графическую конструкцию:

Служебный синтаксис DRL совпадает с конкретным синтаксисом текстовой нотации и представляет собой XML-язык. Для описания служебного синтаксиса используется язык RelaxNG1, являющийся одним из стандартов описания схем документов XML. Описание служебного синтаксиса конструкции выглядит следующим образом.

Представленный формализм описания языка позволяет однозначно зафиксировать весь набор конструкций языка. Совместно с открытым исходным кодом инструментария поддержки языка, такая спецификация обеспечивает широкие возможности расширения языка как в промышленных условиях применения (как описано в работе [6]), так и в исследовательских целях. Отсутствие подобной полной спецификации, например, для языка моделирования Webприложений WebML [20] очень сильно затрудняет расширение языка, развитие и создание для него новых программных инструментов.

1.6 Выводы обзора Существует ряд зрелых подходов к разработке документации, часть из которых поддерживает повторное использование (DITA, DocBook, FrameMaker).

Также есть ряд общих методов повторного использования, в которых хорошо проработана адаптивность, но нет возможностей, нужных для разработки документации (фреймы Бассета). Имеются и методы моделирования общих и различных свойств систем, которые могут быть применены к задаче разработки документации (диаграммы возможностей). Однако нет единого метода разработки документации, поддерживающего проектирование сложной документаRelax NG Site URL: http://relaxng.org/.

ции и адаптивность повторного использования. Для документации СПП эти аспекты являются ключевыми.

При реализации DocLine использовались готовые открытые технологии – DocBook для описания форматирования текстов и публикации документов в целевых форматах и Eclipse GMF для реализации графических средств проектирования структуры сложных пакетов документации. То есть технологию не надо создавать «с чистого листа» и есть возможность сосредоточить основные усилия на главном – на поддержке адаптивного повторного использования документации.

Глава 2. Язык DRL Схема языка DRL представлена на Рис. 4.

DRL/GR предназначен для проектирования документации, то есть задания ее структуры и схемы повторного использования: продуктов семейства, шаблонов документов, связей между шаблонами и продуктами, повторноиспользуемых компонент и их связей между собой и с шаблонами документов.

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

Для реализации форматирования документации (выделения глав, вставки рисунков, таблиц, заголовков и т.д.) DocLine интегрируется с популярной технологией DocBook [51], так что собственных средств форматирования DRL/PR не предоставляет. Такое решение выбрано для облегчения перехода на DocLine для технических писателей, а также для повторного использования подсистем инструментального пакета DocBook, реализующих публикацию документов в различных форматах [55].

Рассмотрим последовательно DRL/GR, DRL/PR и интеграцию DRL с DocBook.

2.1 DRL/GR Проектирование повторно-используемой документации в DocLine осуществляется с помощью графической нотации DRL/GR, предлагающей следующие виды диаграмм:

главная диаграмма – содержит список продуктов семейства и состав документации типового продукта;

диаграмма вариативности – отображает набор повторно используемых фрагментов документации и правила их объединения в документы;

конкретному продукту СПП.

2.1.1 Главная диаграмма Описание документации в DRL начинается с создания схемы семейства – списка продуктов семейства и списка документов, составляющих документацию типового продукта.

Для спецификации схемы семейства в DRL/GR предназначена главная диаграмма. На Рис. 5 показан пример главной диаграммы:

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

Здесь и далее мы будем рассматривать пример семейства телефонных аппаратов «Унител» – это набор телефонных аппаратов различного назначения с разнообразной функциональностью. Главная диаграмма состоит из двух секций. Слева (секция «Продукты семейства») задается набор продуктов семейства, в данном случае это три вида телефонных аппаратов: «Унител-таксофон»

(уличный таксофон, поддерживающий только исходящую связь), «Унителавтоответчик» (домашний аппарат с функцией автоответчика), «Унител-АОН»

(домашний аппарат с поддержкой функции АОН). В правой секции («Информационные продукты») определяется состав типового пакета документации, содержащий «Руководство пользователя» и «Справочную систему». Части этого пакета называются информационными продуктами и, фактически, являются шаблонами целевых документов. Для каждого конкретного продукта семейства может требоваться произвольный набор информационных продуктов, что на диаграмме обозначается линией между продуктом и информационным продуктом. В данном случае для всех трех продуктов семейства создается руководство пользователя, а для «Унител-таксофон» создается также и справочная система.

Текстовая нотация DRL/PR является XML-языком и обеспечивает детальную спецификацию повторного использования. Фактически, графическая нотация дает альтернативный взгляд на документацию, позволяющий быстро просмотреть ее структуру. Все, что определяется с помощью визуальной нотации, записывается в конечном виде в XML-представлении. Рассмотрим DRL/PR представление главной диаграммы. Семейство и список продуктов описываются в корневой конструкции :

Для каждого продукта () указывается имя (name), которое отображается на диаграмме, а также внутренний идентификатор (id), используемый для указания продукта в тексте документации.

Информационные продукты описываются в корневой конструкции Для каждого информационного продукта () указывается имя, которое отображается на диаграмме, а также внутренний идентификатор, используемый для указания информационного продукта в тексте документации.

Кроме того, информационный продукт может содержать текст, являющийся шаблоном соответствующего документа (содержимое информационного продукта будет рассмотрено далее).

2.1.2 Диаграмма вариативности Следующий шаг после описания схемы семейства – создание переиспользуемой части документации, то есть шаблонов документов (информационных продуктов) и переиспользуемых строительных блоков, из которых составляются документы. Для описания состава информационного продукта предназначена диаграмма вариативности, основанная на диаграммах возможностей [26] (см.

пример на Рис. 6):

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

документация модуля «Исходящие звонки», документация модуля «Входящие звонки», документация модуля «Автоответчик», документация модуля «АОН».

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

С помощью связей на диаграммах вариативности показывается иерархия включений информационных элементов, причем один и тот же информационный элемент может быть включен в произвольное количество контекстов (отношение аналогичное «каталожному» агрегированию в модели классов UML [2]). В DRL для диаграмм вариативности используется модифицированная нотация Feature Diagrams [26].

На диаграммах вариативности помимо структуры включения информационных продуктов и элементов специфицируется также и простейший вариант адаптивности информационных продуктов – структурная адаптивность. Так включение отдельных информационных элементов может быть обязательным или необязательным. На Рис. 6 показано необязательное включение для элемента «Документация модуля «АОН», подразумевающее, что при создании руководства пользователя конкретного продукта семейства на основе информационного продукта «Руководство пользователя», можно включить или исключить документацию модуля «АОН» в соответствии с конфигурацией разрабатываемого телефонного аппарата. Включение элемента «Документация модуля «Номеронабиратель» на Рис. 6 является обязательным, то есть включаемый элемент должен обязательно присутствовать во всех текстах, куда включается элемент «Документация модуля «Исходящие звонки». Также могут задаваться правила включения групп элементов в рамках одного родительского узла: в примере на Рис. 6 указано, что, по крайней мере, один из элементов «Документация модуля «Исходящие звонки» или «Документация модуля «Входящие звонки» должен включаться в любое руководство пользователя, порожденное на основе информационного продукта «Руководство пользователя». Такой тип групп называется OR-группами. Второй тип групп – XOR-группы, из элементов, входящих в такую группу в каждый конкретный контекст может включаться только один (элементы «Документация модуля «АОН ГОСТ» и «Документация модуля «АОН Caller ID» на Рис. 6).

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

Для хранения диаграммы вариативности применяется DRL/PR. Для представления информационного элемента используется конструкция, задающая идентификатор и отображаемое имя информационного элемента. Так информационные элементы на Рис. 6 определяются следующим образом:

< Имя информационного продукта> ::

< Идентификатор информационного продукта> ::

< Имя информационного элемента> ::

< Идентификатор информационного элемента> ::

< Идентификатор ссылки на информационный элемент> ::

< Идентификатор группы> ::

< Специализированный информационный продукт> ::

Конкретный синтаксис DRL/GR Конкретный синтаксис DRL/GR определяется в терминах расширенной НФБН.

Семейство продуктов содержит содержит соединяется с ( соединяется с ) | ( соединяется с ) соединяется с < Включение информационного элемента или группы>* содержит ::=| соединяется с соединяется с соединяется с соединяется с Конкретный синтаксис DRL/PR и служебный синтаксис Конкретный синтаксис DRL/PR, который также является и служебным синтаксисом для всего языка DRL, задается с помощью схемы Relax NG.