Современные подходы и методы моделирования изменяемых программных систем (1187429), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Рис.3 - Общий подход к представлению объектов по Chernetski

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

В этой системе проводится построение модели вариабельности согласно приведенной схемы.

Рис.4 Схема построения модели характеристик

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

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

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

Этап анализа – это:

– определение предметной области;

– сбор всех релевантных знаний о предметной области;

– построение системы знаний в виде нескольких семантических нотаций и операций над ними;

– проектирование языка DSL, который лаконично описывает программный модуль в предметной области;

– подготовка правил последовательного преобразования моделей;

– определение предикатов, которые проверяют семантику модели.

Этап реализации – это

– разработка специального редактора, который реализует семантику языка DSL;

– создание библиотеки, которая реализует верификацию семантики;

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

Этап использования – это

– реализация модели с помощью спроектированного языка DSL;

– выполнение преобразований моделей и их интеграция на каждом этапе;

• генерация кода и его интеграция с выходным кодом.

Описание в языке DSL позволяет:

– улучшить тестирования программной системы и обеспечить полную автоматизацию программного обеспечения;

– трансформировать модели из одного DSL в другой DSL;

– давать описание предметной области на одном уровне абстракции и давать дополнительную детализацию на более низкие уровни;

– автоматизировать реструктуризацию системы и развертывать в среде.

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

1.5 Система конфигурационной сборки Grid Европейского проекта Калайдер

Система GRID построена по принципу моделирования систем с применением модели характеристик FM. Основным компонентом системы Grid, выполняюшим задачи моделирования вариабельных систем, является подсистема ETICS (EInfrastructure for Testing, Integration and Configuration Software). Она обеспечивает управление малыми и большими программными проектами с применением стандартной конфигурационной сборки, стандарта качества, интеграции пакетов из модулей и их тестирование в среде этой системы. Система используется для запуска удаленной сборки и тестирования на компьютерах пользователей, работающих на разных платформах в своих разных организациях(рис.5).

Процесс сборки и тестирования программного обеспечения в ETICS проходит три фазы:

1. Конфигурирование – это процесс регистрации программных компонентов для сборки и тестирования; создания конфигураций и присоединения команд контроля версий, команд сборки, команд тестирования, свойств, переменных и зависимостей. Функциональные возможности задачи предоставляются Веб-приложением Сборки и Тестирования (Build and Test Web Application) и Клиентом. Командная строка (Command-Line Client) обеспечивает доступ к Сервису Сборки и Тестирования (Build and Test Service).

Рис.5 - Инфраструктура Grid

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

2. Удаленная сборка/тестирование. Этот шаг позволяет запускать сборку и тесты на разных платформах Grid для подтверждения мобильности кода и генерации ряда отчетов о статическом и динамическом тестировании при разных условиях. Программные объекты могут быть следующих типов: “проект” (P), “подсистема” (S) и “компонент” (C). Их взаимосвязь показана на рис. 6.

Конфигурация в ETICS – это множество информационных структур, которое представляет определенную версию модуля.

Рис. 6 - Связь объектов ”Проект”, “Подсистема” и “Компонент”

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

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

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

Имеются три разных набора команд и два типа свойств (то есть свойства ETICS и переменные среды).

Команды VCS. Эти команды использованы для управления кодом, сберегаемым в системе контроля версий.

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

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

1.6 Конвейерная сборка разнородных объектов

Конвейерная сборка разнородных объектов (модуль, объект, компонент и др.) - объектно-компонентный метод (ОКМ) [20,27-28] - предложена в ряде работ и сделан доклад на конференции ICTERI. Лаврищева Е.М представила технологию сборки разных типов, разрабатываемых средствами соответствующих парадигм программирования в стандартной форме и конфигурируемых в новые вариантные структуры программных систем. Базовую основу составляет метод объектно-компонентного (ОКМ) моделирования программных систем с применением логико-математического аппарата, реализуемого на четырех уровнях проектирования объектной графической модели предметной области или домена. Особенности ОКМ будут рассматриваться ниже.

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

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

Глава 2. МОДЕЛИРОВАНИЕ ВАРИАБЕЛЬНОЙ СИСТЕМЫ

Клаус Похл ввел понятие вариабельности в виде модели характеристик (Feature Model) для элементов системы, помечаемых вариантными точками для изготовления программного продукта [1].

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

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

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

FODA (Feature-oriented domain analysis) является основоположником в сфере создания вариабельных систем и является простой моделью с признаками, которые организованы с использованием “состоит из” и “обобщение/специализация” отношений, используz И/ИЛИ граф. Модель характеристик имеет очень простую структуру отношений, альтернативность, факультативность и взаимозависимость. Рис.7 показывает пример FODA. Эта модель характеристик описывает продуктовую линию для мобильного телефона. На Рис.7 Камера, Сообщение и Экран являются факультативными признаками, а Звонок - обязательным. Резистивный и Емкостный являются альтернативными признаками. Также на Рис. 7 можно увидеть правило компоновки “Видео звонок” требует “фронтальную камеру”. Выбор между альтернативными признаками Резистивный и Емкостный производится на основе “Логических обоснований”, показанных на Рис.7. Например, в случае покупки мобильного телефона, если покупателя волнует цена и точность, то он выберет Резистивный экран.

Рис. 7 FODA признаковая модель продуктовой линии мобильного телефона

Задача обеспечения вариабельности программной системы базируется на методах разработки и конфигурирования продукта (product configuration) из готовых reuses и процессов управления конфигурацией (configuration management), направленных на определение и внедрение эффективных процедур разработки и эволюции систем, а также их адаптации к новым условиям функционирования в современных гетерогенных средах [2, 18-23].

2.1 Функции управления вариабельностью

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

Объектами управления вариабельностью в семействе программных систем являются:

— точка вариантности – место в разработанной программной системе, по которой осуществляется выбор варианта в системе;

Характеристики

Список файлов ВКР