Язык drl для проектирования и разработки документации семейств программных продуктов

Романовский К. Ю.; Кознов Д. В.

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

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

Введение. Семейство программных продуктов (product line) - это набор продуктов, совместно продвигаемых на рынке и разрабатываемых на основе общих активов с помощью хорошо определенного метода повторного использования [1]. Идея разрабатывать не один продукт, а сразу целое семейство была предложена в 1976 г. Парнасом [2]. К настоящему времени она нашла широкое практическое воплощение. Сформировалось два научно-практических центра, которые анализируют и распространяют успешный индустриальный опыт в данной области, создают стандарты и организуют конференции. Это Институт программной инженерии Университета Карнеги-Мелон в США и Европейский институт программного обеспечения **К

В качестве повторно используемых активов выступают программные компоненты, модели анализа и проектирования, практики менеджмента, тесты и пр. [1]. Однако документация в этот перечень почему-то не попала, а различные концепции, методы и подходы к проектированию и разработке семейств программных продуктов (обзоры можно найти в работах [1, 3, 4]) обходят задачу организации повторного использования документации стороной. В отдельных отчетах об индустриальных внедрениях product line подхода упоминается о повторном использовании документации (например, в [5]), но на этом не делается акцента.

А между тем задача создания документации при разработке программного обеспечения (ПО) является важной и трудоемкой. Объем пользовательской и проектной документации часто оказывается весьма значительным, ее требуется оперативно изменять, необходимы различные представления документации - компьютерные справочные системы, документы-книги, Интернет-документация и т. д. Существуют многочисленные подходы и технологии разработки технической документации - такие известные продукты как Adobe FrameMaker [6], AuthorIT [7], различные закрытые и открытые XML-форматы для представления документации -- DocBook [8], DITA [9], Juniper DTD [10] и др. В некоторых из них, в частности в DocBook и DITA, нашла отражение задача повторного использования. Однако она решается как вспомогательная, не затрагиваются такие важные аспекты как проектирование сложных пакетов документации с учетом повторного использования, адаптация повторно используемых фрагментов к требованиям контекста и др.

Продолжая развивать метод создания документации для семейств программных продуктов, предложенный в [11], в данной работе мы предлагаем новый язык DRL (Documentation Reuse Language) для проектирования и разработки документации с акцентом на повторное использование. Этот язык может применяться на всех этапах разработки сложной документации - от проектирования до публикации электронных документов. В DRL для проектирования структуры документации с учетом повторного использования включены графические средства, основанные на диаграммах возможностей (Feature Diagrams) [12, 13]. Собственно разработку документации предлагается

SEI - Software Engineering Institute (http://www.sei.cmu.edu/plp.).

**) ESI - European Software Institute (http://www.esi.es).

выполнять на основе специального XML-формата, также входящего в состав DRL, описанного в терминах XML Schema "К Наконец, для указания полиграфических свойств документов (глав, разделов, форматирования) в DRL допускаются вставки на языке DocBook. Полная DRL-спецификация транслируется в DocBook, что позволяет применять средства среды DocBook для автоматической генерации целевых документов в различных форматах (PDF для печатных документов, HTML для электронных документов и пр.). Описание DRL строго формализовано: определены абстрактный синтаксис (с помощью НФБН-грамматики **) ), графическая нотация (с помощью графического реасширения грамматик НФБН ***) ) и сериализационный синтаксис (в виде XML Schema).

1. Обзор существующих подходов. Данная работа находится на стыке двух предметных областей: а) методов создания семейств программных продуктов; б) технологий и языков разработки технической документации. В первой области выделим следующие подходы, которые были использованы в данной работе:

• диаграммы возможностей (Feature Diagrams), предложенные в работах [12, 13] для визуального отображения общих и частных свойств набора продуктов;

• язык XVCL [15], основанный на подходе Пола Бассета [16, 17] и реализующий языково-независимое управление повторным использованием программного кода.

Среди технологий и языков разработки технической документации ****) существуют такие подходы и формализмы, которые сходны по задачам с DRL:

• технология DocBook, обеспечивающая полиграфическое форматирование текстов и последующую публикацию их в различных выходных представлениях - HTML, PDF и т. п.;

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

Рассмотрим эти подходы более подробно.

1.1. Диаграммы возможностей (Feature Diagrams) предложены в 1990 г. в рамках метода FODA [13] группой исследователей из Института программной инженерии США во главе с Кио Кангом (Куо Kang). В настоящий момент имеется ряд инструментальных пакетов, поддерживающих создание диаграмм возможностей.

Основная задача диаграмм возможностей - формализовать общие и различные черты систем, входящих в семейство продуктов. Ключевым понятием формализма является возможность (feature) - обособленное свойство системы, распознаваемое с точки зрения пользователя или разработчика. Таким образом, диаграмма возможностей - это набор возможностей и иерархических связей между ними с явно выделенным корнем иерархии, который называется концептом (concept) [12]. Иерархическая связь отображает декомпозицию концепта или возможности и называется отношением включения. На диаграмме могут быть предусмотрены точки вариации - необязательные включения, а также условия на группы включений, которые могут по-разному интерпретироваться в контексте различных систем, описываемых диаграммой. Пример диаграммы возможностей показан на рис. 1, на котором концепт - Телефонный аппарат «Унител» - символизирует семейство телефонных аппаратов, поддерживающих

XML Schema - стандарт описания типов XML-документов (http://www.w3.org/XML/Schema).

**) НФБН (Нормальная Форма Бэкуса-Наура) - язык описания грамматик, является стандартом де-факто при формализации абстрактного синтаксиса языков программирования.

***) Использовался формализм, аналогичный примененному для описания языка SDL/GR [14].

*•**) Обзор таких технологий с акцентом на средствах повторного использования представлен в работе [11].

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

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

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

1.2. Язык XVCL и подход Бассета. XML-based Variant Configuration Language (XVCL) - язык конфигурирования вариантов, основанный на XML, разрабатывается Станиславом Джарзабеком и группой ученых из Университета г. Сингапура начиная с 2000 г. [15]. В его основе лежит подход Пола Бассета [16, 17], предложенный в 1987 г. и успешно использованный на практике для реструктуризации и реинжиниринга COBOL-приложений в составе продукта Netron Fusion [18].

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

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

1.3. Технология DocBook была впервые предложена в 1991 г. компаниями HaL Computer Systems и O’Reilly & Associates. В настоящее время формат DocBook стандар-

тизован консорциумом OASIS и поддержан множеством технологических средств -пакетами FrameMaker, XMLSpy **) , Oxygen ***) , VEX ****) и многими другими. Формат DocBook специфицирован несколькими способами: в виде DTD, XML Schema, а также Relax NG. Он является открытым стандартом, имеются также открытые реализации преобразований, обеспечивающих публикацию документов в различные целевые форматы. DocBook широко используется для разработки документации операционных систем семейства UNIX (FreeBSD, Linux), а также открытого ПО.

Язык DocBook является XML-языком, содержащим конструкции для определения полиграфической структуры документов (например, части, главы, параграфы) и высокоуровневого форматирования текстов (в частности, выделение текста, вставка иллюстраций). В DocBook разделяется детальное описание форматирования и описание содержимого публикации. Так, например, есть конструкция <book /> для определения списка авторов, названия документа и разнообразной дополнительной информации о нем. Конкретное представление этой конструкции устанавливается в наборе преобразований в целевые форматы. При этом в различных целевых форматах представление может отличаться, что является воплощением идеи единого исходного представления (single source) [19] - возможность на основе одного исходного документа с помощью набора преобразований получать целевые документы различного формата (PDF, Win-Help, HTML и др.).

С точки зрения повторного использования, DocBook фактически предлагает лишь реализацию идеи единого исходного представления, при этом не учитывая, что документы разного формата, как правило, и структурированы неодинаково [20]. Также отсутствуют встроенные средства поддержки разделения документации на части, и для этого приходится пользоваться штатными средствами XML, что существенно усложняет поддержание ссылочной целостности.

1.4- Подход DITA (Darwin Information Typing Architecture - архитектура типизации информации Дарвина) предложен компанией IBM в 2001 г. для разработки сложной модульной технической документации. Позднее DITA стандартизован консорциумом OASIS. Данный подход поддерживается рядом известных инструментальных средств, таких как XML Spy, Oxygen и др.

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

OASIS (Organization for the Advancement of Structured Information Standards) - международный некоммерческий консорциум, занимающийся разработкой и внедрением стандартов в области электронной коммерции (http://www.oasis-open.org).

**) XMLSpy - пакет разработки XML-документов от компании Altova (http://www.altova.com/).

***) Oxygen - пакет разработки XML-документов от компании SyncRO Soft Ltd., интегрируемый в платформу Eclipse (http://www.oxygenxml.com/).

***») VEX (Visual Editor for XML) - XML-редактор с открытым исходным кодом, интегрируемый в платформу Eclipse (http://vex.sourceforge.net/).

Топики обеспечивают крупноблочное повторное использование. Также DITA поддерживает простейшее «мелкозернистое» повторное использование с помощью механизма ссылок на содержание: любой тег может быть заменен на тег аналогичного типа с указанным идентификатором.

Основное преимущество DITA по сравнению с DocBook - принцип модульности документации. Однако DITA, так же как и DocBook, не предлагает механизмов настройки переиспользуемых элементов по требованиям контекста применения, которыми обладает, например, язык XVCL.

1.5. Выводы обзора. Формализмы, применяемые при проектировании и организации повторного использования различных активов, не рассчитаны на документацию, а языки и средства разработки документации не поддерживают специфичные для семейств программных продуктов возможности. В различных подходах к разработке документации реализуются лишь отдельные идеи: единое исходное представление в DocBook [8], модульность в DITA [9], адаптируемость во фреймах Бассета [17] и языке XVCL [15]. Однако отсутствует единый язык, ориентированный на разработку документации семейств программных продуктов и поддерживающий весь процесс разработки - от анализа и проектирования документов до их публикации.

2. Описание языка. В языке DRL, подобно SDL [14], предусмотрено две нотации - графическая и текстовая. Первая ориентирована на проектирование структуры документации, а также полезна в ситуациях, когда необходимо быстро получить обзорную информацию о документации в целом или о каком-либо ее фрагменте. Все, что можно показать с помощью графической нотации, можно выразить и в текстовом виде. Текстовая нотация предназначена для тонкой настройки повторного использования и подробного описания форматирования документов.

2.1. Графические средства проектирования. DRL поддерживает три вида диаграмм:

• главная диаграмма,

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

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

Главная диаграмма позволяет определить все продукты семейства и все главные шаблоны документов, а также связать продукты с шаблонами. Пример главной диаграммы показан на рис. 2. На ней представлено семейство продуктов «Телефонный аппарат Унител». Это программно-аппаратное семейство содержит ряд телефонных аппаратов различного назначения и функциональности - начиная от таксофонов и заканчивая полнофункциональными системами с автоответчиком и встроенным определителем номера. Пакеты документов различных продуктов семейства очень похожи, но тем не менее различаются. Как минимум в документации ряда продуктов нет описания функций, в них отсутствующих (например, в документации «Унител-таксофон» не описан модуль входящих звонков, поскольку таксофон не предоставляет такой услуги).

Семейство состоит из трех продуктов - «Унител-таксофон», «Унител-автоответчик», «Унител-АОН». Продукты семейства показываются в левой секции диаграммы, а в

*) Specification and Description Language - язык для моделирования телекоммуникационных систем, развиваемый с 1976 г. Международным комитетом CCITT, переименованным позднее в ITU-T (http://www.itu.int/lTU-T/). Данный язык используется на всех этапах разработки телекоммуникационного ПО, включая статическую и динамическую составляющие систем. SDL предлагает две различные нотации - графическую для наглядного представления алгоритмов и текстовую, предназначенную для подробной спецификации.

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

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

Унител-автоответчик

Унител-АОН

I 1 1 1 1 Руководство пользователя

1

1 1 Справочная

1 система

1 1

1 Учебные

1 1 материалы

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

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

правой приведены шаблоны различных целевых пользовательских документов: «Руководство пользователя» (как правило, единый документ в формате РБР), «Справочная система» (набор разделов справки, чаще всего в формате \VinHelp или НТМЬНе1р), «Учебные материалы» (достаточно часто в виде НТМЬ-страниц). Это именно шаблоны, называемые в терминологии Б11Ь информационными продуктами (ИП) и содержащие наборы глав и частей и пр. ИП настраивается и конкретизируется для каждого продукта семейства, превращаясь в документ.

Каждый ИП представляется в ОЛЬ с помощью диаграмм вариативности, основанных на диаграммах возможностей. Пример такой диаграммы для ИП «Руководство пользователя» дан на рис. 3. ИП находится в корне иерархии и изображается в виде прямоугольника с двойными границами. Остальные узлы данного дерева - информационные элементы (ИЭ): блоки документации, подготовленные для повторного использования. ИЭ могут состоять из других ИЭ, и отношения между ними могут иметь различную семантику: строгое альтернативное включение (ХОК), нестрогое альтернативное включение (011-включение), обязательное и необязательное включение. ИП «Руководство пользователя» (рис. 3) состоит из следующих ИЭ: «Документация модуля “Исходящие звонки”», «Документация модуля “Входящие звонки” », «Документа-

Рис. 4- Пример диаграмм продукта.

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

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

Далее документацию семейства нужно детализировать с помощью текстовой нотации DRL.

2.2. Введение в текстовый DRL. Диаграмма с рис. 2 транслируется в текстовое DRL-описание. Листинг 1 иллюстрирует текстовое представление продуктов семейства:

</PLScheme>

</ProductLine>

Конструкция ProductLine обозначает семейство продуктов, конструкция PLScheme -схему семейства продуктов, конструкция Product указывает на отдельный программный продукт семейства.

Шаблоны документов семейства (информационные продукты) в нашем случае транслируются в DRL-текст, показанный в листинге 2:

</Document at ion Core>

</PLDocumentation>

Конструкция PLDocumentation обозначает документацию семейства, конструкция DocumentationCore - это ядро документации, т. е. та ее часть, которая содержит набор повторно используемых компонент. Конструкция Inf Product указывает на ИП, конструкция InfElement - на ИЭ.

Соответствующая диаграмме с рис. 3 текстовая DRL-спецификация показана в листинге 3, который отражает часть диаграммы - корневой элемент (ИП) и узлы первого уровня (ссылки на ИЭ):

<book>

< t i 11e > <dictref dict="main" Entry="productname"/> </title>

</bookinfo>

</book>

</InfProduct>

Группа ИЭ определяется отдельной конструкцией InfElemRefGroup. Листинг 3 также иллюстрирует использование кода DocBook внутри элементов DRL.

2.3. Крупноблочное повторное использование. В большинстве случаев повторное использование эффективно, только если возможна адаптация компонент к требованиям конкретного контекста (вариативность). В DRL поддерживаются несколько механизмов вариативности. Наряду с простыми механизмами, такими как псевдопеременные и условные блоки, применяются также и точки расширения, которые задаются конструкцией Nest. Пример ИЭ с точками расширения показан в листинге 4: <InfElement id="A0H CallerlD" name="A0H CallerID">

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Индикация номера осуществляется следующим способом .

</Nest>

При успешном определении номер отображается на встроенном дисплее телефонного аппарата.

</Nest>

</ InfElement>

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

Для реального использования документации семейства необходимо описать, как именно документация специализируется для каждого продукта семейства. Разработка документации продукта начинается с создания специализированных информационных продуктов (FinallnfProduct). Специализированный информационный продукт (СИП) -это реализация ИП из документации семейства, привязанная к конкретному продукту семейства. Пример его описания показан в листинге 5:

<ProductDocument.ation productid=" callerid ">

<Insert—After nestid="Способы индикации номера">

Также предусмотрена возможность звуковой индикации номера.

</ Insert— After>

</ Adapter>

</FinalInfProduct>

</ ProductDocuinentation>

СИП описывает набор ИЭ с единственным допустимым видом отношений - обязательное включение. Выбор и настройка ИЭ осуществляются с помощью адаптеров (Adapter), описывающих настройки, которые необходимо применить к той или иной ссылке на ИЭ в контексте заданного продукта семейства.

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

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

<Dict.ionary id="main">

<Entry id="productname ">Название продукта</entry>

</Dic.tionary>

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

Помимо словарей, DRL предлагает также конструкцию Directory (каталог). Она содержит набор кортежей имя-набор атрибутов. Каталоги, так же как и словари, мо-

гут быть продуктозависимыми. Распространенный пример каталога - команды пользовательского интерфейса приложения. Для описания команд применяется большое количество различных данных - название команды, подсказка, пиктограмма, горячая клавиша и т. п. Тем не менее в документации упоминания команды могут отличаться по количеству деталей. При описании панели инструментов, например, осмысленно указывать название команды и пиктограмму, а в справочнике команд - напротив, все информационные поля. Для реализации различных способов отображения элемента каталога применяется конструкция DirTemplate (шаблон отображения элемента каталога). Листинг 7 иллюстрирует описание каталога (Directory), шаблона отображения (DirTemplate) и использования элемента каталога (DirRef):

<Attr id="name">0 программе</Attr>

<Attr id="hint ">Информация о программе</ Attr>

< Attr id=" icon ">ab out .jpg</Attr>

</Entry>

</Directory> <DirTemplate id="CommandNameHint " d ir ec t, or у i d=" commands ">

<AttrRef attrid="name "/>(<AttrRef attrid="hint " />)

</DirTemplate> <InfElement name=" Command List" id=" CommandList ">

Команды: <DirRef templid=" CommandNameHint " entryid=" About " /> </InfElement>

3. Формальные средства спецификации языка. Для формального описания языка DRL используется метод, описанный в [3]. В нем классическое описание языка (синтаксис, семантика, прагматика) уточняется в части описания синтаксиса, разбиваясь на абстрактный, конкретный и сериализационный синтаксис. Абстрактный синтаксис в общем виде описывает типы языковых конструкций и правила их сочетания; конкретный синтаксис определяет, как выглядят конструкции языка при написании текстов; сериализационный - форму представления конструкций языка, пригодную для долгосрочного хранения и передачи. Кроме этого, мы добавили таблицы соответствия графических и текстовых конструкций языка.

В рассматриваемом случае абстрактный синтаксис позволяет объединить графическую и текстовую части языка. Конкретный синтаксис для DRL - это описание графической нотации. Сериализационный синтаксис совпадает у нас с конкретным синтаксисом текстовой части языка, поскольку текстовый DRL является XML-языком.

Для описания абстрактного синтаксиса была использована форма представления грамматик НФБН. Пример спецификации абстрактного синтаксиса конструкции «Документация семейства» показан в листинге 8:

<Документация семейства> : : <Информационный продукт> +

<Информационный элемент>*

<Словарь>*

{<Каталог> <Шаблон элемента каталога>+ }*

Для описания текстовой нотации DRL применяется язык XML Schema, являющийся промышленным стандартом для схем документов XML. Все конструкции DRL содержатся в пространстве имен «drl».

Для описания графической нотации используется расширение НФБН. В исходную грамматику добавлены следующие бинарные инфиксные операторы: содержит и соединяется с. Так, например, набор правил на рис. 5, а описывает конструкцию «Именованный прямоугольник», изображенную на рис. 5, б.

а

«Именованный прямоугольник> ::

<Прямоугольн ик> соде рж и т < и м я >

< П р я м о у го л ь н и к > ::

Рис. 5. Пример описания графической нотации.

Таблица соответствия абстрактного синтаксиса и текстовой нотации

Абстрактный синтаксис Текстовая нотация

кодификатор группы> <xs:simpleType name="GroupModifier"> <xs:restriction base="xs:string"> <xs:enumeration value="0R"/> <xs:enumeration value="X0R"/> </xs ;restriction> </xs:simpleType>

Элементы графической нотации не всегда очевидным образом отображаются на элементы текстовой нотации. Спецификация DRL содержит таблицы соответствия абстрактного синтаксиса и конкретной нотации. Фрагмент одной из них показан в таблице.

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

4. Сравнения и соотнесения. Ряд принципов языка DRL основывается на хорошо зарекомендовавших себя идеях существующих языков. Диаграммы вариативности DRL основываются на диаграммах возможностей [12]. Для удобства добавления и удаления включения информационного элемента в группу мы добавили в нотацию диаграмм возможностей новый тип узла для обозначения типа включения.

Некоторые вспомогательные конструкции DRL основаны на конструкциях инструментального пакета FrameMaker [6]. Конструкции форматирования текста позаимствованы из языка DocBook [8], оттуда же взята идея единого исходного представления текста.

Новыми являются конструкции, обеспечивающие «мелкозернистое» переиспользо-вание текста, а именно конструкции определения и работы с каталогами. Также новым является понятие адаптера, разработанное на основе конструкции COPY фреймов Бассета [17] и конструкции adapt технологии XVCL [15]. Основное отличие адаптера DRL от указанных конструкций - возможность разделения описания семейства документов и специализации этих документов под требования конкретного продукта. Оригинальные конструкции COPY и adapt одновременно подключают и специализируют переиспользуемый фрагмент. В языке DRL подключение переиспользуемого фрагмента осуществляется отдельной конструкцией («включение информационного элемента»), поскольку возможность подключения определяется на этапе проектирования документации семейства без обязательной привязки к контексту того или иного продукта. Специ-

6

< и м я >

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

Заключение. Для DRL была выполнена пилотная реализация в среде Microsoft .NET/Visio. Подход был апробирован в проекте разработки документации семейства систем автоматизации телевещания, о чем рассказано в работе [21]. В результате использования DRL существенно упростилось сопровождение документации - изменения, внесенные в текст и диаграммы, автоматически распространялись по всем документам.

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

Также перспективным представляется добавление в DRL дополнительных средств для пакетизации: подсемейств, пакетов информационных продуктов и информационных элементов. -

Summary

Romanovsky К. Yu., Koznov D. V. DRL language for design and development of software product line documentation.

The DRL (Documentation Reuse Language) language is presented. This language is intended for design and development of software product lines documentation. The language has visual and textual representations. It applies a famous formalizm - Feature Diagrams - to the task of documentation design. The language supports both large-scale document reuse (on a level of units) and fine-grained reuse for small text parts. Reuse management mechanism permits adaptation of reusable parts to peculiarities of a usage context. The text notation of DRL is implemented as XML-language and defined by means of XML Schema. The textual part of DRL is integrated with popular documentation markup language DocBook to improve publication capabilities. DRL can be applied at all stages of complex documentation development starting with the design and up to electronic document publication.

Литература

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

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

3. 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.

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

5. Jaaksi A. Developing Mobile Browsers in a Product Line // Ibid. P. 73-80.

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

7. James-Tanny C. Single-sourcing with AuthorIT // Single-sourcing SIG online newsletter. 2002. June, http://www.stcsig.org/ss/articles062002/6-02_ss_authorit.htm .

8. Walsh N., Muellner L. DocBook: The Definitive Guide. New York, NY: O’Reilly, 1999. 644 p.

9. Day D., Priestley М., Schell D. Introduction to the Darwin Information Typing Architecture - Toward portable technical information, http://www-106.ibm.com/develo-perworks/xml/library/х-dital / .

10. Fraley L. Beyond theory: making single-sourcing actually work // Proc. of the 21st annual Intern. Conference on Documentation. New York: ACM Press, 2003. P. 52-59.

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

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

13. Kang K., Cohen S., Hess J., Novak J. et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study: Techn. report, CMU/SEI-90-TR-21. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1990. 87 p.

14. ITU-T Recommendation Z.100: Specification and description language (SDL). 1999. 244 p.

15. Jarzabek S., Bassett P., Hongyu Zhang, Weishan Zhang. XVCL: XML-based variant configuration language // Proc. of 25th Intern. Conference on Software Engineering. 2003. P. 810-811.

16. Bassett P. Frame-Based Software Engineering // IEEE Software. 1987. Vol. 4, N 4. P. 9-16.

17. Bassett P. Framing software reuse - lessons from real world. New Jersey: Yourdon Press, 1996. 365 p.

18. Netron Fusion, http://www.netron.com/ .

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

20. Clark D. Rhetoric of present single-sourcing methodologies // Proc. of the 20th annual Intern. Conference on Computer documentation. New York: ACM Press, 2002. P. 20-25.

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

22. 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.

Статья рекомендована к печати членом редколлегии проф. А. Н. Тереховым.

Статья принята к печати 24 мая 2007 г.

Язык drl для проектирования и разработки документации семейств программных продуктов Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Романовский К. Ю., Кознов Д. В.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Романовский К. Ю., Кознов Д. В.

DRL language for design and development of software product line documentation

Текст научной работы на тему «Язык drl для проектирования и разработки документации семейств программных продуктов»