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

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

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

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

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

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

Эдвард Деминг [3] предложил метод управления эффективной организацией программной индустрии семейства программных продуктов и выделил четыре функции для управления его вариабельностью (рис.8):

1) F1 – функция планирования вариабельности в артефактах семейства программных систем (на уровнях инженерии домена и приложений);

2) F2 – функция реализации вариабельности в структуре семейства программных систем;

3) F3 – функция системного мониторинга вариабельности семейства программных систем;

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

В основе управления вариабельностью положены требования R (Requriment):

1) R1 – обоснованность – наличие объективных оснований принятия решений для F1 – F4;

2) R2 – согласованность – одинаковость способа выработки и реализации решений на всех уровнях абстракции и на всех этапах процесса разработки семейства программных систем;

3) R3 – масштабируемость – независимость способа выработки и реализации этих решений от объема функциональных возможностей семейства;

4) R4 – трассированность – возможность отслеживания связей между характеристиками вариабельности на всех процессах разработки семейства;

5) R5 – визуализованность отмеченных проявлений вариабельности и связей между ними.

Обеспечение сформулированных требований R1 – R5 для функций F1 – F4 обеспечивается в адекватной модельной среде их реализации.

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

Рис.8. Функции действий в модели Дьоминга

Известны два типа подходов к моделированию вариабельности. В одном из них предлагается интегрировать вариабельность в существующие модели (вроде FD или UML), в другом – строить специальные модели вариабельности.

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

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

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

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

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

– модель вариабельности в семействе программных систем с определенной выше особенностью.

2.2 ОКМ моделирование программных систем и их семейств

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

Класс – это определенное множество объектов, имеющих общие переменные, структуру и поведение. Объект является экземпляром класса.

Одним из основных свойств объектов является инкапсуляция (свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя). Она реализуется с помощью интерфейсов, которые состоят из методов и атрибутов. Атрибут может определять внешние переменные экземпляра класса. Для каждой внешней переменной существуют методы выборки значения переменной (get-метод) и присвоение ей нового значения (set-метод). С общей методологической точки зрения, интерфейс экземпляра объекта состоит из переменных методов. Каждый объект может иметь несколько интерфейсов, которые определяют его функциональные свойства. Кроме того, объект может иметь специальный интерфейс, методы которого работают с экземплярами (например, Home-интерфейс в EJВ модели EJB языка Java). На абстрактном уровне интерфейс может рассматриваться как частичный вид абстрактного класса, которая сводится к операции приведения классов. Если выполняется операция приведения экземпляра класса в соответствии с определенным интерфейсом, то обязательным условием является реализация этим экземпляром всех методов соответствующего интерфейса.

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

< объектная ориентация> = <объекты> + <наследование>.

Каждое понятие предметной области, вместе с его свойствами и поведением является отдельным объектом, а вся предметная область - это совокупность объектов со связями, которые устанавливаются на базе отношений между этими объектами. В качестве объекта выступают как абстрактные образы, так и конкретные физические предметы или группы предметов с указанными общими характеристиками и функциями [7, 8].

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

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

2.2.1 Уровни проектирования объектной модели (ОМ)

Для проектирования объектной модели из объектов предложен логико-математический аппарат, применяемый на следующих уровнях:

– обобщающий понятие объекта в виде денотата в соответствии с теорией Фреге в виде <имя объекта> <концепт>;

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

– характеристический для логико-алгебраического представления характеристик объектов и их свойств;

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

Объект, имеющий одновременно статус множества (класса) и элемента какого-либо множества, имеет внешние и внутренние свойства и характеристики.

Под характеристикой понимается совокупность свойств объекта (унарных предикатов) и выделенных предикатов, удовлетворяющих условию, при которых каждый объект принимает значение истины на заданной паре IS – A / Part – Of и одновременно не больше, чем один предикат из совокупности. Характеристика может быть внешней и внутренней и к ней применяется отношение принадлежности "Part–of".

2.2.2 Модель графовой структуры предметной области

При проектировании предметной области из объектов на четырех уровнях формируется объектная модель вида:

OМ = G₁; G₂, G₃, G₄, где

G₁ – граф объектов предметной области, созданной на обобщающем уровне (t=1);

G₂ – функция FM (Feature Model) на характеристическом уровне (t=2);

G₃ – архитектурно-компонентная модель структурного уровня (t=3);

G₄ – интерфейсная модель взаимодействия семейства программных продуктов на поведенческом уровне (t=4).

Объектам функции G^t₁ и их характеристикам соответствуют методы и данные (уровня 2, 3), необходимые для реализации продуктов в семействе и обеспечения их взаимодействия. Функция FM = (F₁, F₂, …F_k)

включает базовые функциональные характеристики ОМ.

Итоговый граф G включает объекты типа I (рис.9), которые выполняют функцию вызова объектов и передачи им соответствующих данных в требуемом формате [27, 28].

Вершины данного графа G задают функциональные объекты – О₁, О₂, О₃, О₄, О₅, О₆, О₇, О₈ и интерфейсные объекты – O₅, O₆, О₇, О₈, которые размещаются в репозитории, а дуги соответствуют отношениям между всеми видами объектов. Результат связи двух объектов (например, link P₂(O’₆) - интерфейсный объект In O’₂).

Рис. 9 Граф G на множестве объектов и интерфейсов

Исходя из графа G (рис.9) можно задать программы из объектов P₁ – P₆ с использованием операторов объединения (сборки) в операторе link:

1) P₁ = О₂  О₅ , link P₁ =In O’₅ (О₂  О₅);

2) P₂ = О₂  О₆, link P₂ =In O’₆ (О₂  О₈);

3) P₃;

4) P₄ = О₄  О₇, link P₄ =In O’₇ (О₄  О₇);

5) P₅ = О₄  О₈, link P₄ =In O’₈ (О₄ О₈);

6) P₆ = (P₁ P₂ P₃ P₄ P₅).

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

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