77219

Расширение функциональности графического редактора языка DRL

Курсовая

Информатика, кибернетика и программирование

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

Русский

2015-02-02

474.5 KB

2 чел.

Санкт-Петербургский Государственный Университет

Математико-механический факультет

Кафедра системного программирования

Расширение функциональности графического редактора языка DRL.

Курсовая работа студента 444 группы

Василик Дмитрия

Научный руководитель             ……………… К.Ю. Романовский

ст. преп.        / подпись /

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

Введение.

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

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

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

Наиболее популярные системы для разработки сложной документации программного продукта в настоящее время – DITA(Darwing Information Typing Architecture) от компании IBM и DocBook. Первая из них отличается тем что предоставляет  возможность переиспользования блоков документации(«топиков»), вторая основана на идее единого исходного представления документации, из которого после может быть создана документация в различных форматах. Для разработки документации семейств программных продуктов обе эти системы не предоставляют необходимую функциональность. Они не имеют подходящих средств для тонкой и гибкой настройки использования небольших блоков документации, и, таким образом, и для реализации вариативности.

В статье [2] представлен новый подход к разработке документации, называемый DocLine, который воплощает в себе стратегическое, запланированное переиспользование компонент документации. Этот подход отличается тем, что архитектура документации создается по принципу вариативности, при этом процесс разработки архитектуры документации хорошо согласуется с процессом разработки архитектуры линии программных продуктов. Всё это позволяет создать документацию очень близкую по своему строению к архитектуре линии программных продуктов. DocLine также включает в себя язык разметки документации DRL/PR (Documentation Reuse Language/Phrase Representation) и визуальную нотацию для проектирования документации DRL/GR (Documentation Reuse Language/Graphical Representation). DRL/GR включает в себя нотацию трех диаграмм:

1. Главная диаграмма – диаграмма, представляющая список продуктов линии и список информационных продуктов (ИП) в документации.

2. Диаграмма вариативности – отражает структуру информационного элемента (ИЭ).

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

По сути своей DRL является предметно-ориентированным языком (DSL - Domain-Specific Language [11]), т.е. языком который создается специально для использования в рамках некоторой предметной области. В нашем случае язык создавался для построения документации; все его структуры так или иначе направлены на определение её архитектуры или разметки. DRL/GR является графическим DSL для создания архитектуры документации. На рынке существует большое разнообразие средств для разработки DSM-решений (Domain Specific Modelling решений) и создания редакторов для графических DSL с определяемой пользователем нотацией языка. Наиболее мощными и гибкими такими средствами на данный момент являются Eclipse GMF (Graphical Modelling Framework) на базе Eclipse и Microsoft DSL Tools на базе Microsoft Visual Studio.

Данная работа является расширением функционала системы, представленного в  работе [3]. В качестве платформы для создания DSM-решения, реализующего подход DocLine, в работе [3] была выбрана Eclipse GMF как наиболее зрелая из представленных на рынке. В этой работе А.А. Семеновым были реализованы редакторы для главной диаграммы и диаграммы вариативности, интегрированные с текстовым редактором DRL, представленным в работе [4] К.С. Яковлева. Каждый из этих редакторов представляет собой плагин для Eclipse.


Постановка задачи.

Основной целью данной работы является добавление новой функциональности для работы с диаграммой продукта к плагину для Eclipse, используемого для редактирования диаграммы вариативности и созданного А.А. Семеновым в работе [2]. Эта задача может быть разбита на следующие задачи:

  1.   Изучение платформы Eclipse GMF. Сложность задачи состоит в том что платформа имеет только отрывочную непрофессиональную документацию, и единственным способом её изучения является изучение её открытого исходного кода, который, к сожалению, также нередко не комментирован.
  2.  Реализовать следующие функции для ИП на диаграмме вариативности:
  •  Возможность выбрать стратегию создания СИП и создать его по заданному ИП.
  •  Возможность раскраски диаграммы вариативности в соответствии с выбранным СИП, реализующим ИП на ней представленный.
  •  Возможность перехода между диаграммами продукта и вариативности.


Обзор метода DocLine.

Метод DocLine [2,5] состоит из следующих частей:

  •  процесс разработки документации;
  •  язык разработки документации DRL (Document Reuse Language), включающий текстовую и графическую нотации;
  •  архитектура пакета инструментальных средств.

Процесс разработки документации в DocLine максимально приближен к процессу разработки линии и также состоит из двух частей – разработки структуры документации и разработка документации продуктов.

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

Графическая нотация содержит диаграммы трех видов (см. рисунок 1):

  1.  Главная диаграмма содержит продукты семейства и доступные ИП, а также связи между ними, которые представляют собой СИП.

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

  1.  Диаграмма вариативности отражает структуру ИП или ИЭ. На этой диаграмме могут быть узлы двух типов: прямоугольник для отображения ИЭ (тонкая граница) или ИП (толстая граница), круг соответствует группе ссылок. Закрашенный круг обозначает группу типа OR (должна быть включена хотя бы одна ссылка из группы), не закрашенный - типа XOR (должна быть включена ровно одна ссылка из группы).

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

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

  1.  Диаграмма продукта передает структуру ИП, адаптированного СИП. Эту диаграмму можно рассматривать как раскрашенную диаграмму ИП, на которой отображаются только ИЭ, вошедшие в СИП. Элементы мелкозернистого редактирования на диаграмме продукта не отображаются.

Рисунок : DRL/GR - примеры диаграмм.

(пример заимствован из работы [5])

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

Текстовая нотация подробно описана в работах [2,5] и в данной на работе мы не будем на ней останавливаться.


Обзор платформ
Eclipse EMF, GEF и GMF.

Eclipse Modelling Framework(EMF) – Java-технология, созданная для генерации Java-кода по объектно-ориентированной модели. EMF состоит из двух фундаментальных частей: собственно ядра EMF, которое позволяет по модели генерировать Java-код, а также предоставляет некоторые инструменты для работы с имплементацией, и EMF.Edit, расширяющей базовую EMF возможностью генерации классов-адаптеров, которые позволяют просматривать и редактировать модель на основе Undo/Redo команд(поддерживающих отмену действия). EMF.Edit также содержит функционал для генерирования редактора DSL, построенного по модели. Этот редактор обладает очень простым базовым пользовательским интерфейсом, и непосредственно практически не используется, но он содержит очень мощный функционал по работе с файлами и моделью. Используя EMF.Edit, на базе модели, графической нотации и определения доступных инструментов редактора, Eclipse Graphical Modeling Framework (GMF) может сгенерировать тонко настраиваемый графический редактор с удобным интерфейсом пользователя.

GMF – платформа, интегрирующая EMF и Eclipse Graphical Editing Framework (GEF), которая предоставляет возможность по модели в нотации EMF сгенерировать код графического редактора DSL, определяемого этой моделью. Eclipse GEF – технология, используемая для создания графических редакторов, интегрируемых в Eclipse. GEF предоставляет набор классов для написания собственного графического редактора, GMF предоставляет возможность генерировать его по модели. GEF также состоит из двух частей: org.eclipse.draw2d – универсальный набор классов обеспечивающий отображение «легковесных» объектов внутри тяжеловесного «родителя» (SWT Control), и собственно самой GEF – библиотеки классов для разработки редакторов, построенных на архитектуре Model-View-Controller (MVC). org.eclipse.draw2d содержит:

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

Непосредственно GEF содержит:

  •  инструменты, такие как инструмент для выбора элемента на диаграмме, инструмент создания элемента, инструмент создания соединения между элементами и т.д..
  •  PaletteViewer, являющийся частью контроллера в модели MVC и выполняющую функцию панели инструментов.
  •  набор классов для работы с соединениями между элементами.
  •  два типа GEF-viewer (TreeViewer и GraphicalViewer) – элементов контроллера, которые используются для взаимодействия с пользователем самого верхнего уровня.
  •  набор классов контроллера, которые связывают модель и представление, а также обеспечивают поддержку Undo/Redo команд с помощью стека команд.


Особенности реализации.

Ядром Eclipse является платформа Equinox, которая в свою очередь является реализацией спецификации  OSGi Alliances Service Platform R4. Ключевое понятие OSGi – модуль, в спецификации OSGi модули называют bundles, в Eclipse же – plug-ins. Архитектура OSGi предназначена для максимально простой работы с модулями. OSGi платформа работает с модулями очень динамично, она позволяет в любое время сессии загружать и выгружать их, модули могут использовать информацию о других модулях, управлять их жизненным циклом, пользоваться их API и т.д. Именно благодаря этому Eclipse имеет такие широкие возможности расширения. Еще одно ключевое понятие OSGi – точки расширения. Смысл механизма точек расширения для пользователя Eclipse состоит в возможности динамического и слабосвязанного расширения функциональности любых плагинов Eclipse [13].

В данной работе все действия привязывались к одной и той же стандартной точке расширения Eclipse org.eclipse.ui.popupMenus. Эта точка расширения позволяет добавить новый пункт в контекстное меню, появляющееся при нажатии правой кнопкой мыши на элемент соответствующий ИП на диаграмме вариативности. К нажатию привязывается действие, реализующее интерфейс org.eclipse.ui.IActionDelegate

В данной работе было реализовано три действия:

  1.  «Change view mode to product diagram mode» - действие для отображения одного из относящихся к данному ИП СИП. В результате этого действия открывается визард, предлагающий пользователю выбрать СИП, в соответствии с которым будет раскрашена диаграмма вариативности (так, как описано в пункте «Обзор DocLine»). При этом показываются только СИП, относящиеся к ИП, изображенному на диаграмме вариативности, и .drl файлы которых располагаются в одном проекте с данным ИП. Действие применимо только когда пользователь просматривает диаграмму в режиме вариативности, в противном случае ничего не произойдет.
  2.  «Change view mode to variation diagram mode» - действие для обратного перехода между способами отображения диаграммы. Действие применимо только когда пользователь просматривает диаграмму в режиме продукта.
  3.  «Create new product» - действие, в результате которого появляется мастер, позволяющий пользователю выбрать имя нового, адаптирующего данный ИП, СИП и его расположение на диске, а также стратегию по которой будет происходить адаптация.  Выбор стратегии разрешит будут ли адаптироваться опциональные элементы ИП, а также определит по какому правилу будут адаптироваться элементы OR и XOR групп (например, адаптируется всегда максимальное количество элементов в OR группе и первый в XOR группе, или адаптируется только первый в OR группе и любой один в XOR группе). Действие применимо только когда пользователь просматривает диаграмму в режиме вариативности.

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

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

Далее необходимо подготовить список ресурсов содержащих СИП, соответствующих выделенному ИП.

Здесь стоит отметить, что в Eclipse классически под ресурсами понимается несколько другое – класс org.eclipse.core.resources.Resource  является абстракцией над файлами, папками, проектами и воркспейсом. Он представляет собой наследника Container и предназначен для работы с объектом как с частью файловой системы. Класс org.eclipse.emf.ecore.resource.Resource также представляет абстракцию, но совсем другого рода. Как можно заметить по имени пакета он принадлежит платформе EMF. Resource EMF, если он «загружен», содержит бизнес модель, которая была описана в соответствующем файле, а также объектную модель, сгенерированную по этому файлу. Кроме того специальная утилита IdUtil, созданная А.А. Семеновымв работе [3], позволяет разрешать ссылки на элементы описанные в других файлах и программисту не проходится заботиться о корректной загрузке модели из файла.

Бизнес модель содержит объекты моделируемых элементов, в нашем случае это объекты, моделирующие конструкции языка DRL, такие как DocumentationCore, InfProduct, InfElement, InfElemRef и т.д. Всё это разрозненный набор экземпляров классов, и связей между ними, реализованных в виде свойств-ссылок, и навигация по такой модели без понимания её структуры невозможна. Так что непосредственно бизнес модель для создания и редактирования диаграмм непригодна, хотя и содержит всю необходимую информацию. Для нужд редактора одновременно с бизнес моделью строится объектная модель. Объектная модель представляет собой дерево с экземплярами Node в качестве узлов и экземплярами Edge в качестве ребер. Дерево всегда имеет выделенный корень – экземпляр DiagramRoot, наследующийся от Node. Как можно понять из сказанного выше Node представляет собой абстракцию, инкапсулирующую всю информацию о элементе бизнес модели как о вершине дерева, а Edge – как о его ребре. Node и Edge являются наследниками View, который содержит методы для получения списка входящих и исходящих ребер, а также несколько методов для работы с такими свойствами вершины как её видимость и изменяемость в дереве. Кроме того View содержит ссылку на соответствующий элемент бизнес модели. Node также содержит методы для работы с LayoutConstraint, а Edge методы для работы с точками соединения и свойства соответствующие своим «началу» и «концу».

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

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

Далее визард по выбранному СИП должен создать некий объект, который позволит определить какие из ИЭ ИП будут адаптированы для каждой точки вариации (т.е. выбор адаптировать ли опциональный элемент или выбор набора среди элементов в группе ссылок).

Для этой цели был выбран один из самых простых путей, позволяющих дальнейшее расширение функциональности, - создание словаря decisionMap (java.util.Map), в качестве ключа которого используется строка – идентификатор ссылки на ИЭ (т.к. адаптируемые в СИП ИЭ представляются ссылками на них[5]), а значения – объект класса Adapter, моделирующего данный адаптер. В этом качестве также можно было использовать список (java.util.List) из идентификаторов ссылок на ИЭ. Этого также было бы достаточно для поставленной задачи, но в дальнейшем может потребоваться некая обработка соответствующих адаптеров (это может дать возможность, например, просматривать ИЭ добавленные в токах расширения).

EMF, GEF и GMF поддерживают концепцию Undo/Redo команд. GMF же кроме того поддерживает транзакции, в рамках GMF это обозначает что если выполнение команды было прервано по каким-то причинам, состояние всех элементов, которые затрагивала эта команда, будет возвращено к тому, которое было на начало выполнения команды. Для того чтобы это было возможно используются специальные команды с поддержкой Undo/Redo, которые должны выполняться в TransactionalEditingDomain. В данной работе было разработано три такие команды – по одной на каждое действие.

Каждой диаграмме соответствует один TransactionalEditingDomain, содержащий стек команд, реализация которого позволяет корректно откатывать невыполненные команды. TransactionalEditingDomain содержит ResourceSet, хранящий ресурсы EMF, каждому из которых соответствует файл в файловой системе. Таким образом TransactionalEditingDomain могут разделять общие ресурсы, но проблема обеспечения корректного выполнения транзакций над разделяемыми ресурсами не ложится на плечи программиста, а разрешается самим TransactionalEditingDomain: это упрощается тем что каждая команда при создании объявляет список файлов, которые могут быть изменены при выполнении этой команды.

Итак, визард создает в TransactionalEditingDomain команду DefaultChooseCommand, дочернюю к AbstractTransactionalCommand - базовой для Undo/Redo команд, и передает её конструктору в качестве параметра элемент диаграммы соответствующий выбранному ИП и decisionMap. После этого управление передается org.eclipse.core.commands.operations. OperationHistoryFactory, который исполняет команду в её TransactionalEditingDomain и записывает информацию об её исполнении в историю.

Как было сказано выше редакторы в GEF (а значит, и в GMF) строятся на основе архитектуры Model-View-Controller. Рассмотрим наиболее важные для понимания архитектуры редактора части компонент Model, View и Controller. В качестве Model исползуется объектная модель, описанная выше; org.eclipse.draw2d содержит интерфейс IFigure, объекты реализующие который, представляют собой объекты View. Кроме того как было сказано этот пакет содержит несколько реализованных стандартных фигур и всё необходимое для их рендеринга и работы с ними.

В роли части контроллера EditPart привязывают модель к представлению и содержат в себе логику необходимую для изменения модели (см. рисунок 2). EditPart получает от редактора запросы – экземпляры Request, которые описывают тип взаимодействия, изменяет соответствующий ей View согласно запросу, и возвращает экземпляр команды, инкапсулирующей все необходимые действия над моделью и изменения над представлениями других EditPart, если они необходимы.

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


Рисунок 2: MVC модель диаграммы в редакторе.

(пример заимствован из работы [13])

Вернемся к исполнению DefaultChooseCommand. Для раскраски диаграммы нужен некий обход представленного на ней в виде дерева ИП. Поскольку вся логика сосредоточена в EditPart, и кроме того требуются изменения не только в модели но и во View, нужно проводить обход именно классов контроллера EditPart, а не модели и View. Обходить ли дерево в глубину или  широту – не принцпиально, выбран был обход в глубину.  Для того чтобы избежать рекурсии этот обход реализуется с помощью FIFO-очереди. На каждой итерации производится обработка одной EditPart, первой в очереди, после чего она удаляется из очереди, а на её место помещаются её непосредственные потомки. Под непосредственными потомками здесь подразумеваются:

  •  для EditPart, являющейся контроллером вершины, - контроллеры всех ребер, исходящих из этой вершины
  •  для EditPart, которая является контроллером для ребра, - единственная EditPart – контроллер для вершины, являющаяся концом ребра.

Вместе с этим на каждой итерации строится отношение parentPart «потомок-родитель» для всех потомков EditPart, реализованное как словарь. Родителем любого ИЭ или группы ссылок в этом отношении может являться ИП, ИЭ или группа ссылок. Родителем ИП является он сам. Т.к. для раскраски вершины необходима только информация о ребре, входящем в неё, и её родителе, то уже построенной части этого отношения оказывается достаточно для обработки соответствующей EditPart.

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

Алгоритм обработки ИЭ:

  1.  В случае если родитель ИЭ не включен в диаграмму1, ИЭ не может быть адаптирован. Он не включается в диаграмму продукта и становится невидимым на ней, как и входящее в него ребро. Потомки такого ИЭ также получают статус не включенных в диаграмму и в последствие станут на ней невидимыми вместе с соединяющими их ребрами. При этом каждый ИЭ заботится о включении своих потомков в диаграмму и не заботится о их видимости и видимости ребер, их соединяющих.
  2.  Если родитель ИЭ является группой ссылок, включенной в диаграмму, то ИЭ будет адаптирован в случае присутствия идентификатора ссылки на него в decisionMap. Если же сам ИЭ не адаптируется СИП, то он не включается в диаграмму, ребро соединяющее его с родителем остается без изменений, а сам ИЭ на диаграмме закрашивается серым цветом,  рамка его становится пунктирной. Как было сказано выше возможность для адаптируемых ИЭ показывать их непосредственных потомков, выделенных серым цветом, может быть полезной для редактирования диаграммы в дальнейшем.
  3.  В случае если родитель ИЭ включен в диаграмму, и ИЭ не является опциональным, он будет включен в диаграмму. Если ИЭ является опциональным, он будет адаптирован и включен в диаграмму в зависимости от присутствия соответствующего ключа в decisionMap (см. пункт 2).

Алгоритм обработки групп ссылок:

  1.  В случае если родитель группы не включается в диаграмму, все потомки группы также не могут быть адаптированы. Группа и ребро, соединяющее её с родителем, делаются невидимыми, а все потомки получают статус не включенных в диаграмму.
  2.  В случае если родитель группы адаптируется, группа остаетcя без изменений, а её потомки получают статус включенных в диаграмму в зависимости от присутствия соответствующего ключа в decisionMap и типа группы. В случае если условие группы не выполнено в СИП, выбрана будет одна произвольная ссылка из группы ссылок.


Заключение.

В данной работе достигнуты следующие результаты:

  1.  Создано средство для просмотра диаграммы продукта на основе редактора диаграмм вариативности, которое позволяет по заданному СИП раскрасить диаграмму вариативности базового для него ИП.
  2.  Разработан инструмент для создания СИП, реализующего данный ИП.


Литература.

  1.  Clements P. & Northrop L.M. (2003). Software Product Lines. // http://www.sei.cmu.edu/programs/pls/sw-product-lines_05_03.pdf
  2.  Романовский К.Ю. Метод разработки документации семейств программных продуктов. // Системное программирование. Вып. 2. Сб. статей / Под ред. А.Н.Терехова, Д.Ю.Булычева. СПб.: Изд-во СПбГУ, 2007
  3.  А. А. Семенов. Система визуального проектирования документации семейств программных продуктов, Дипломная работа, Санкт-Петербургский Государственный Университет, Математико-Механический факультет, кафедра информатики, 2007.
  4.  Яковлев К. Создание среды разработки документации для семейств программных продуктов, Дипломная работа, СПбГУ, Математико-Механический факультет, кафедра системного программирования, 2007.
  5.  Романовский К.Ю., Кознов Д.В. Язык DRL для проектирования и разработки документации семейств программных продуктов. // Вестник С.-Петербург. ун-та. Сер. 10.2007. Вып. 4. С.
  6.  Mikael Svahnberg and Jan Bosch, Issues Concerning Variability in Software Product Lines, University of Karlskrona/Ronneby Department of Software Engineering and Computer Science, S-372 25 Ronneby, Sweden.

Michel Jaring and Jan Bosch, Representing Variability in Software Product Lines: A Case Study, University of Groningen, Department of Mathematics and Computing Science, PO Box 800, 700 AV Groningen, The Netherlands.

  1.  Horst Lichter, Thomas von der Maßen and Thomas Weiler, Modelling Requirements and Architectures for Software Product Lines, ISSN 0935–3232,  Aachener Informatik Berichte, Department of Computer Science.
  2.  Романовский К.Ю., Кознов Д.В. Язык DRL для проектирования и разработки документации семейств программных продуктов. // Вестник С.-Петербург. ун-та. Сер. 10.2007. Вып. 4. С.
  3.  Официальный сайт Eclipse: www.eclipse.org.
  4.  Официальный сайт Eclipse GMF: wiki.eclipse.org/GMF_Documentation.
  5.  Кознов Д.В. Основы визуального моделирования. // М: Интернет-Университет Информационных Технологий; Бином. Лаборатория знаний, 2008.
  6.  Тьюториал по GEF: http://eclipsewiki.editme.com/GefDescription
  7.  Описание разработки плагинов в Eclispse: http://www.rsdn.ru/article/devtools/eclipse_plugins.xml

1 В случае если родителем является ИП, считается что он включен.


 

А также другие работы, которые могут Вас заинтересовать

16859. Система кровообращения – не продукт эволюции 232.5 KB
  Система кровообращения – не продукт эволюции Брэд Хараб ВВЕДЕНИЕ Система кровообращения выполняет много различных функций в организме. Мало того что она отвечает за перенос кислорода ко всем клеткам тела но она также поставляет питательные вещества которые и
16860. В отличие от знания, образованности, информированности мудрость есть способность принимать и усваивать опыт жизни предыдущих поколений, без чего невозможно развитие науки и культуры, а значит, и цивилизации 38 KB
  Наука и жизнь 200601 В отличие от знания образованности информированности мудрость есть способность принимать и усваивать опыт жизни предыдущих поколений без чего невозможно развитие науки и культуры а значит и цивилизации. Виктор Садовничий Мн...
16861. КОНЦЕПЦИЯ «ПОТОПА» КАК НОВАЯ ПАРАДИГМА ГЕОГРАФИЧЕСКОЙ НАУКИ 434.28 KB
  Голубчиков Ю. Н. КОНЦЕПЦИЯ ПОТОПА КАК НОВАЯ ПАРАДИГМА ГЕОГРАФИЧЕСКОЙ НАУКИ Юрий Николаевич Голубчиков кандидат географических наук ведущий научный сотрудник географического факультета Московского государственного университета им. М.В. Ломоносова. Преп
16862. Дизайн в живых организмах: моторы 117 KB
  Дизайн в живых организмах: моторы Джонатан Сарфати Из нашего ежедневного опыта мы обычно можем сказать было ли чтото спроектировано или нет. Основным доказательством является высокое информационное содержание.Информационное содержание любой последовательности –
16863. Чудеса воды 67 KB
  PAGE 1 Чудеса воды Джонатан Сарфати Вода Мы пьем ее готовим с ней пищу моемся и плаваем в ней и в основной принимаем ее как данное. Эта прозрачная и безвкусная жидкость является настолько неотъемлемой частью нашей жизни что мы редко задумываемся над е...
16864. Дыхание Жизни — не продукт эволюции 201.5 KB
  Дыхание Жизни не продукт эволюции Брэд Хараб Многие из нас слышали когданибудь такое выражение €œкак рыба вынутая из воды€. Эта известная идиома отображает несомненный факт того что рыбы не могут дышать или перемещаться на суше. Тем не менее учёные которые подд...
16865. Человеческое тело – шедевр, созданный Богом 81 KB
  PAGE 1 Человеческое тело – шедевр созданный Богом Иосиф Патури Доктор Иосиф Патури является Ректором Христианского Колледжа Темпл в Цинциннати Огайо США. Человеческий мозг является наиболее сложным и организованным устройством материи во вс
16866. КАК СООТНОСЯТСЯ ПОСТУЛАТЫ ВЕРЫ ЭВОЛЮЦИОНИЗМА И СОТВОРЕНИЯ МЕЖДУ СОБОЙ И С ЕСТЕСТВОЗНАНИЕМ 196.49 KB
  КАК СООТНОСЯТСЯ ПОСТУЛАТЫ ВЕРЫ ЭВОЛЮЦИОНИЗМА И СОТВОРЕНИЯ МЕЖДУ СОБОЙ И С ЕСТЕСТВОЗНАНИЕМ В.С.Ольховский доктор физикоматематических наук Институт ядерных исслед. НАНУ Научноисслед.центр Відгук Мин.здравоохр.Украиныolkhovsk@kinr.kiev.ua Выступление на открытой дискусс...
16867. Поезд эволюции движется в неправильном направлении 65.5 KB
  Поезд эволюции движется в неправильном направлении Карл Виланд Атмосфера в переполненном фойе лекционного зала была полна ожиданий и любопытства. Это было в конце 70х годов в ранние бурные дни креационного движения в Южной Австралии. Дебаты по сотворению/эволюции