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

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

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

При переходе от объектов ОМ к компонентам формируется компонентная модель:

КМ = RC, In, ImC, Fim, где

RC – базовые компоненты множества компонентов С, которые соответствуют базовым объектам модели ОМ;

In – интерфейс компонентов, среди параметров которого задается имя точки вариантности;

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

Fim () – функции преобразования входных и выходных параметров интерфейса и множество данных в сигнатуре интерфейса.

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

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

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

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

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

2.2.3 Модель вариабельности программной системы имеет вид:

MF_var = SV; AV, где

SV – подмодель вариабельности артефактов системы,

AV – подмодель архитектуры продуктов системы.

Подмодель SV = G_t, TR_t , Con, Dep, где

G_t = F_t, LF_t ) – граф артефактов типа t требования, компоненты, тесты и др.);

TR_t – двусторонние связи артефактов типа t;

Con и Dep – предикаты на декартовом произведении множеств артефактов, которые определяют ограничения и зависимости между функциями и показателями качества программной системы.

Подмодель AV = G, TR, G_t,), где

G - граф архитектуры программной системы из артефактов, готовых reuses (artifacts, assets, services, components) и вариантных характеристик; TR – связь элементов архитектуры и артефактов G_t.

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

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

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

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

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

Инженерия вариабельного программного продукта состоит из двух основных этапов: инженерии домена (domain engineering) и инженерии приложений (application engineering) [23].

Инженерия домена – процесс определения и реализации обязательных и необязательных компонентов повторного использования. Он состоит в определении и реализации общности (the commonality) с обеспечением вариабельности программного продукта, то есть возможности изменять продуктовую линию для изготовления нового варианта продукта.

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

Во время инженерии домена вариабельность представлена артефактами (requirements, architecture, components, test cases,и др.) в архитектуре, а в процессе инженерии приложения представлена артефактами, необходимыми пользователю. Внесение изменений в семейство программных систем может быть выполнено на уровне самого домена и его приложений.

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

2.3 Технология изготовления программного продукта

Согласно [1, 2] разработка продукта включает четыре базовых процесса: обработка требований к проекту, проектирование структуры домена, реализация домена, тестирование домена.

2.3.1 Требования к домену

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

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

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

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

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

2.3.2 Проектирование домена

Этот подпроцесс служит для определения стандартной архитектуры на продуктовой линии изделий. Архитектура представляет общую, высокоуровневую структуру для всех приложений продуктовой линии.

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

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

Проектирование домена отличается от проектирования общего вида систем, потому что:

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

– основывается на стандартной архитектуре, которая может быть приспособлена к требованиям будущих приложений;

– определяет общие правила для разработки специфики приложения, основанной на стандартной архитектуре;

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

2.3.3 Реализация домена

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

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

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

Область домена отличается от реализации обычных систем, потому что:

– состоит из свободно связанного, configurable компонентов выполняемого приложения;

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

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

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

2.3.4 Тестирование домена

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

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

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

Тестирование домена отличается от тестирования общего вида систем, потому что:

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

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

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

Artifacts, assets (артефакты и активы линии) образуют платформу линии программного продукта и запоминаются в общем хранилище. Они взаимосвязаны и гарантируют последовательное определение общего продукта и изменчивости линии программного продукта из всех artifacts.

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

Вариабельность в архитектуре документируется, включая:

– модель orthogonal с добавлением внутренней вариабельности, которая видна инженерам;

– область realisation artifacts охватывает проект системы и метод выполнения артефактов;

– повторно используемые компоненты программной системы и интерфейсы.

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

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

2.4 Процесс обеспечения вариабельности в ОКМ

Для обеспечения требуемой вариабельности семейства программных продуктов, в ОКМ выполняются следующие шаги (рис.10) [15].

Рис.10 - Процесс обеспечения вариабельности

Шаг 1. Идентификация вариабельности семейства программных продуктов предусматривает наличие совокупности вариантов и точек вариации. Для ее идентификации могут применяться методологии FODA, FORM (Feature-oriented Reuse Method), RSEB (Reuse-Driven Software Engineering Business), Feature RSEB, FAST и т.п. [16]. На протяжении своего жизненного цикла идентификация трансформируется до тех пор, пока не будет реализована программа программной системы.

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

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