CC BY
73
УДК 004.4'24
О. А. Дерюгина
Московский государствнный университет информационных технологий, радиотехники
и электроники
Семантика и семантически эквивалентные трансформации UML-диаграмм классов
В статье формализуются такие понятия, как объектно-ориентированная архитектура ПС, диаграмма классов, класс, интерфейс, отношение наследования, агрегация и т.д. В статье описывается формальная семантика UML-диаграмм классов, на основе которой возможно выполнять сравнение двух диаграмм классов между собой, производить трансформации, проверяя инвариантность семантического значения.
Ключевые слова: архитектура программного обеспечения, проектирование программного обеспечения, объектно-ориентированная архитектура, UML, семантика UML-диаграмм, формальная семантика.
O. A. Deryugina
Moscow State Institute of Radio Engineering, Electronics and Automation
UML class diagrams: semantics and semantically equivivalent transformations
The paper formalizes such concepts as object-oriented software architecture, class diagram, class, interface, inheritance, aggregation, etc. The paper describes the formal semantics of UML class diagrams, which allows one to compare two class diagrams with each other, to check the semantic invariance after transformation.
Key words: software architecture, software architecture design, object-oriented architecture, UML, UML diagram semantics, formal semantics.
1. Введение
В связи со всё нарастающей сложностью современных программных систем (ПС) возникает потребность в формализации процесса проектирования архитектуры программного обеспечения. Подобная формализация позволит повысить степень автоматизации данного процесса.
Для проектирования архитектуры программного обеспечения часто используется унифицированный язык моделирования UML (Unified Modelling Language), позволяющий производить визуальное проектирование, документирование и формальное описание программных систем.
К преимуществам использования UML можно отнести наличие развитых средств проектирования UML-моделей (Enterprise Architect, Visual Paradigm и др.) и чётких общепринятых стандартов (стандарты группы OMG).
Язык UML позволяет проектировать архитектуру ПС, в том числе в рамках объектно-ориентированной парадигмы программирования. Модель ПС описывается в виде набора связанных между собой диаграмм (классов, прецедентов, компонентов, последовательности и т.д.) Каждая диаграмма состоит из элементов (классов, интерфейсов, пакетов, объектов и т.д.), связанных между собой отношениями (наследование, агрегация, зависимость и т.д.).
Для проведения исследований в области эволюционного проектирования объектно-ориентированной архитектуры ПС необходимо создание формальной теории, описывающей объектно-ориентированную архитектуру ПС и её семантику.
В статье описывается формальная семантика UML-диаграмм классов, на основе которой возможно выполнять сравнение двух диаграмм классов между собой, проверять инвариантность семантического значения после трансформаций в ходе эволюционного поиска (рис. 1).
На рис. 1 приведён пример семантически эквивалентной трансформации UML-диаграммы классов, заключающейся в введении для классов Designer (Дизайнер), Secretary (Секретарь) и Manager (Менеджер) с одинаковым набором полей: id (уникальный идентификатор), FIO (ФИО), address (адрес), positionID (идентификатор должности), salary (заработная плата) - вводится родительский класс Employee (сотрудник) с набором полей id, FIO, address, positionID, salary, от которого их наследуют классы Designer, Secretary и Manager.
Рис. 1. Пример эквивалентной трансформации UML-диаграммы классов
2. Эволюционное проектирование объектно-ориентированной архитектуры
Объектно-ориентированное проектирование начинается с описания функциональности системы, а затем перечисления основных классов, методов и атрибутов, задания основных интерфейсов и иерархий наследования. Часто удобно применять готовые паттерны проектирования [1].
Различные подходы к объектно-ориентированному проектированию программного обеспечения методами поиска включают в себя: улучшение повторного использования существующих архитектур программного обеспечения через паттерны проектирования, построение иерархической декомпозиции для программной системы, проектирование структуры классов, проектирование архитектуры программного обеспечения на основе спецификаций.
В направлении создания инструментальных средств поддержки проектирования архитектуры программного обеспечения проводят исследования R. Outi [2], S. Mancoridis, B.S. Mitchell и др. [3], Di Penta [4] и др.
Важным этапом эволюционного поиска архитектуры программного обеспечения с улучшенными качествами является задание целевой функции. Часто используются комбиниро-
ванные целевые функции, в которых целевое значение складывается из нескольких факторов, каждому из которых задаётся свой вес. В ходе исследования веса могут настраиваться. Сами факторы (например, связность класса, зависимость классов друг от друга) рассчитываются на основе специальных метрик.
Обычно от пользователя требуется составить взвешенную целевую функцию, определяющую, какую архитектуру считать предпочтительнее.
Эволюционное проектирование архитектуры ПС относится к проектированию архитектуры на уровне PIM (Platform Independent Model - Платформо-независимая модель), поэтому характеристиками качества нельзя считать такие параметры, как оценка трудоёмкости выполнения операций, расходование памяти. Можно производить поиск архитектур с лучшими структурными качествами (баланс между максимальной внутренней связностью, минимальной внешней взаимозависимостью и требованием к модульному разбиению проекта).
Если говорить об оптимизации архитектуры систем на основе UML-диаграмм, то при трансформации UML-моделей в процессе поиска неизбежно возникает необходимость проверки корректности модели и семантической эквивалентности её оригиналу. В связи с этим встаёт вопрос о создании средств проверки UML-моделей на корректность и эквивалентность.
3. Теория объектно-ориентированной архитектуры программных систем
Для решения задачи сравнения двух диаграмм классов на предмет семантической эквивалентности автором статьи предложена семантика структуры UML-диаграмм классов. Для описания семантики UML-диаграмм классов формализуются такие понятия из парадигмы объектно-ориентированного проектирования, как архитектура ПС, диаграмма классов, класс, метод и др.
3.1. Понятие объектно-ориентированной архитектуры программной системы
Объектно-ориентированной архитектурой программной системы (ПС) называется архитектура А такая, что
А — {М, RESTR, F, S, IN, OUT},
где М - UML-модель ПС, RESTR - множество ограничений к ПС, F - множество функциональных требований к ПС, S - семантическое значение ПС, IN - входные данные ПС, OUT - выходные данные ПС.
UML-моделью ПС называется формальная модель М такая, что
М — {Dclasses, Duse_cases, Dstate charts, D components, D activity, D0f)jecfs},
где Dciasses - множество диаграмм классов, Duse cases - множество диаграмм прецедентов, Dstate charts - множество диаграмм состояний, Dcomponents - множество диаграмм компонентов, Dactivity - множество диаграмм активностей, D0bjects - множество диаграмм объектов.
Множество диаграмм классов Dciasses — {^classQ, •••dclassm}, где dclassi, ^ ^ 0, •••, ^ диаграммы классов.
UML -диаграммой классов dciass называется такая UML-диаграмма, что
dciass = {CL,INTR,REL},
где CL - множество классов CL — {classo, •••classk}, INTR - множество интерфейсов INTR — {interfaceo^Anterfacei}, REL - множество связей REL — {relation0•••relationg}. Классом class называется такой элемент диаграммы классов Dciassses, что
class — {ATR, METH, Р, ST, N},
где ATR - множество атрибутов ATR = {atro...atrn}, МЕТН - множество методов МЕТН = {meth0...methm}, Р - класс-родитель (равен null, если родителей нет), ST -признак того, что класс статический (равен 0 или 1), N - идентификатор класса (имя). Атрибутом называется такой элемент класса attribute, что
attribute = {visibility, type, virtual, static, final, name},
где visibility = {public, protected, private} - видимость атрибута, type - тип атрибута, virtual - признак виртуальности, static - признак статичности, final - признак запрета изменения, name - имя атрибута.
Методом называется такой элемент класса или интерфеса method, что
method = {visibility, type, virtual, static, final, name, PAR, LOC _PAR},
где visibility = {public, protected, private} - видимость метода, type - тип возвращаемого значения, virtual - признак виртуальности метода, static - признак статичности метода, final - запрет наследования, name - имя метода, PAR = {parameter0...parametern} - множество входных параметров метода, LOC_PAR = {parameter0...parameterm} - множество локальных параметром метода, где parameteri = {type, name}, где type - тип параметра, name - имя параметра.
Интерфейсом interface называется такой элемент UML-диаграммы классов, что
interface = {METH,N},
где МЕТН - множество методов МЕТН = {meth0...methm}, N - идентификатор интерфейса (имя).
Отношением relation называется такая связь между элементами UML-диаграммы, что
relation = {name, type, start, end, power},
где name - имя отношения, type - тип отношения, start - идентификатор начального участника отношения, end - идентификатор конечного участника отношения, power - мощность отношения.
Множество диаграмм прецедентов Duse_cases = {duse_caseo, ...duse_casem}, где dUse casi, i G 0,..., m - диаграммы прецедентов.
Диаграммой прецедентов duse casei называется такая UML-диаграмма, что
dUse_case = {ACT, UC, REL},
где ACT - множество акторов ACT = {actor0, ...actork}, UC - множество прецедентов UC = {use_case0...use_casei}, REL - множество связей REL = {relation0...relationg}.
Актор actor, прецедент usecase характеризуются именем. Отношение relation = {name, type, start, end,power}, где name - имя отношения, type - тип отношения, start - начальный участник отношения, end - конечный участник отношения, power - мощность отношения.
Множество диаграмм состояний Dstate^c^arts = {dState_charto, ...dstate_chartm }, где dstate_charti,i G 0,..., m - диаграммы состояний.
Диаграммой состояний dstate chart называется такая UML-диаграмма, что
dstate_chart = {EV, ST,, GC, ACT},
где EV - множество событий EV = {evento, ...events}, ST - множество состояний ST = {stateo...state¡}, GC - множество условий GC = {guard _condition0...guard_conditiong}, ACT - множество действий ACT = {action0...actionp}.
Множество диаграмм состояний Dc0mp0nenf;S — [dcamponentSQ , ...dcomponentsm }, где dcomponentsi, i G 0,..., m - диаграммы компонетов.
Диаграммой компонетов dcomponents называется такая UML-диаграмма, что
dcomponentsi — [СОМ Р, I NT R, REL},
где COMP - множество компонетов COMP — [component®, ...componentk}, INTR -множество интерфейсов INTR — [interface0...interfacei}, REL - множество связей REL — [relation0...relationg }.
Множество диаграмм активности Dactivity — [dactivityo, ...dactivitym}, где dactivityi, i G 0,..., m - диаграммы активности.
Диаграммой активности называется такая UML-диаграмма dactivity, что
d^ty — [ACT, DEC, SP, J},
где ACT - множество действий ACT — [actione, ...actionk}, DEC - множество решений DEC — [decisionQ...decisioni}, SP - множество ветвлений конкурирующих деятель-ностей SP — [slpito...splitg}, J - множество ветвлений конкурирующих деятельностей J — [joino...joing }.
Множество диаграмм объектов Dobjects — [dobjects0, ...d0bjectsm}, где d0bjectSi,г G 0,..., m - диаграммы объектов.
Диаграммой объектов d0bjects называется такая UML-диаграмма, что
dobjects — [OBJ, INTR, REL},
где OBJ - множество объектов OBJ — [objecto, ...objectk}, INTR - множество интерфейсов INTR — [interface0...interfacel}, REL - множество связей REL — [relation0...relationg }.
Множество ограничений к ПС RESTR может быть представлено на одном из языков задания спецификаций к UML-модели ПС.
Множество функциональных требований к ПС F — [uo...un}, где Ui, i G 0,..., n - сценарии использования (usecases).
Семантическое значение ПС S может быть выражено в терминах какой-либо формальной семантики UML-диаграмм (аксиоматической, операционной и т.д.).
Входные данные IN - данные, подаваемые на вход ПС для последующей обработки. Выходные данные OUT - данные, получаемые в результате работы ПС.
3.2. Семантика UML-диаграмм классов
Рассмотрим особенности семантики UML-диаграмм классов.
Пусть С = {{attr0,attri...attrn}, {metho,methi...methm}, static} - класс c множеством атрибутов attro, attrl...attrn и множеством методов metho,methl...methm, где static - признак статичности. I = {meth0,methl, ...methm} - интерфейс, реализующий множество методов meth0,methl, ...methm.
Под конструктором класса С будем понимать метод С(), вызов которого С.С() приводит к созданию в оперативной памяти объекта класса С.
Вызов конструктора класса возможен лишь у класса С, для которого C.static = false (для нестатических классов).
Под деструктором класса С будем понимать метод ~ С(), вызов которого С. ~ С() приводит к удалению из оперативной памяти объекта класса С.
Вызов деструктора класса возможен лишь у класса С, для которого C.static = false (для нестатических классов).
Выражение Сiviasso^C2Р2 означает, что класс С1 связан отношением ассоциации мощностью (pi, р2) (см. табл. 1) с классом С2, где р1, р2 - количество объектов класса С1 и С2 соответственно, участвующих в отношении.
Между классами возможны следующие виды отношений (relations): ассоциация (association), наследование - обобщение (generalization), агрегация (aggregation), композиция (composition), зависимость (dependency).
Между классом и интерфейсом возможно отношение реализации (realization).
Таблица1
Мощность отношений между классами
Мощность отношения (р1, р2)
один к одному (1,1)
один ко многим (1,1... п) или (1, 0 ... п)
многие ко многим (1,1 ...п, 1,1 ...п) или (0 ...п, 0 ...п)
многие к одному (1,1 ...п, 1) или (0 ...п, 1)
Например, запись Сliasso^C2o...n означает, что каждый объект класса С1 связан отношением ассоциации с 0...п объектов класса С2.
Выражение СlgenerC2 означает, что класс С1 наследует методы и атрибуты класса С2. Выражение С 1piaggregC2Р2 означает, что класс С1 связан с классом С2 отношением агрегации.
Аксиома 1. Пусть даны классы С1 = {{attr10,attr1i...attr1nl}, {meth10,meth1i...meth1ml}} и С 2 = {{attr20,attr2l...attr2n2},
{meth20, meth2l...meth2m2}}. Тогда
S[{С 1 = {{attr10,attr11...attr1ni}, {meth10,meth1l...meth1ml}},
С2 = {{attr2o,attr2i...attr2n2}, {rneth2o,meth2i...rneth2m2}}}, {...}, {С 1g_enerC2,...}] =
= [{С 1 = {{attr10,attr1i...attr1nl} U {attr20,attr2i...attr2n2},
{meth10,rneth1l...meth1mi}U {meth20,meth2i...rneth2m2}}, С2 = {{attr20,attr2i...attr2n2}, {meth20, meth2i...rneth2m2}}, {}, {}}].
Аксиома 2. Справедливо следующее выражение:
С 1piaggregC2р2 — 3atribute G С1 : (type = С2) V (type = Container < С2 >),
где type - тип атрибута atribute класса С1, Container < С2 > - контейнер объектов класса С2.
Выражение С 1picompC2Р2 означает, что класс С1 связан с классом С2 отношением композиции.
Аксиома 3. Справедливо следующее выражение:
(С 1picompC2Р2) Л С 1()) С2(),
где ~ С 1() - вызов деструктора класса С1, ~ С2() - вызов деструктора С2.
Примечание. Аксиома 3 означает, что удаление из оперативной памяти объекта класса С1 автоматически приводит к удалению из памяти связанного с ним отношением композиции объекта класса С2. Выражение С 1depC2 означает, что класс С1 связан с классом С2 отношением зависимости.
Аксиома 4. Справедливо следующее выражение:
С 1depC2 (3method G С1) Л ((3parameter G PAR) V (3parameter G LOC_PAR)) : type = C2,
где PAR - множество формальных параметров метода method, LOC_PAR - множество локальных параметров метода method, type - тип параметра parameter.
Тогда будем считать, что структурная семантика UML-диаграммы классов описывается следующим образом:
S = {{С 1 = {{attrli = {{attrlType,isVirtual,isStatic,isFinal,attrlName}}, attr12 = {...}, ...attr1n = {...}}, {meth1l = {{type,isVirtual,isStatic,isFinal, name, PAR = {parameter1ll = {type, name},parameter1l2 =
= {type, name}...parameter1ln = {type, name}}, LOC_PAR = {parameter1ll = {type, name}, parameter1l2 = {type,name}...parameter1lm = {type, name}}},},
meth12 = {...},.., meth1m = {...}}, isStatic},C2 = {...},...Ck = {}}, { 11 = {{meth1l = {{type, isVirtual,isStatic,isFinal, name,
PAR = {parameter1ll = {type, name}, parameter1l2 = {type, name}... ...parameter1ln = {type, name}}, LOC_PAR = { parameter1ll = {type, name},
parameter1l2 = {type, name}......parameter1lm = {type, name}}},},
meth12 = {...},..., meth1m = {...}}}, 12 = {...}, ...II = {...}}, { R1, R2, ...Rk} }.
Рис. 2. Пример диаграммы классов
Например, семантическое значение диаграммы классов на рис. 2 будет следующим:
S = {{С 1 = {{atr1l = {{Integer, false, false, false, „id,,}},
atr12 = {{String, false, false, false, „name,,}}, atr13 = {{
String, false, false, false, „address,,}},
atr14 = {{String, false, false, false, „telephone,,}},
atr15 = {{List < Order >, false, false, false, „orders,,}}},
{meth1l = {void, false, false, false, „creditHistory,,, PAR = {},
LOC_PAR = {}}, false, „Client,,},
С 2 = {{{atr1l = {{Integer, false, false, false, ,,id„ }},
atr22 = {{Boolean, false, false, false, „paid,,}},
atr23 = {{Double, false, false, false, „price,,}},
atr24 = {{DateTime, false, false, false, „recieveDate,,}},
atr25 = {{List < Product >, false, false, false, „products,,}}}, {
meth2l = {void, false, false, false, „send,,, PAR = {}, LOC_PAR = {}},
meth22 = {void, false, false, false, „close,,, PAR = {},
LOC_PAR = {}}}, false,,, Order,,},
С3 = {{atr3l = {{String, false, false, false,,, contractld,,}},
atr32 = {{String, false, false, false, „ credit Hi story „}},
atr33 = {{Double, false, false, false, „credit Limit,,}}}, {
meth3\ = {void, false, false, false, „remind,,, PAR = {}, LOC_PAR = {}},
meth32 = {void, false, false, false, „monthBill,,, PAR = {},
LOC_PAR = {}}}, false, „Corpor ateClient,,},
С 4 = {{atr4i = {{Integer, false, false, false, „creditCardNum,,}}},
{}, false, „IndividualClient,,},
С5 = {{}, {}, false, „Product,,}}, {}, {C!\aggregC20.n, С20.,naggregC55o..n, СЪдепегС 1, С4generC 1}}
Выражение Сlreaj, 11 означает, что класс С1 связан с интерфейсом 11 отношением реализации (реализует методы интерфейса 11), причём множество методов класса С1 Me i содержит в себе множество методов интерфейса 11 Mji: М!i С Mci.
3.3. Семантически эквивалентные трансформации ИЫЕ-диаграмм классов
Под трансформацией ИМЬ-диаграммы будем понимать такое изменение структурных элементов ИМЬ-диаграммы, которое обеспечивает инвариантность ее семантического значения
Теорема 1. (Следствие из Аксиомы 1) — Первая эквивалентная трансформация. Пусть в иЫЬ-диаграмме классов ¿с1аззвз дан класс-родитель С1 = {{аЫг1\,аЫг12, ...аЫг1п}, {теШ1\,теШ12, ...теШ1т}...} и даны классы С2 = {{аЫг2г}, {теШ23}...}...СМ = {{аПгЩ, {теШМ^}...}. Причем С2...СМдепегС 1. Тогда
3[йС1аззез] = в[{С 1 = {{аЫг1\,аЫг12, ...аЫг1п}, {теШ1\,теШ12, ...те^1т}...}, С2 = {{{{аЫг1\, аЫг12, ...аЫг1п} и {аЫг2^}, {{теШ1\,теШ12, ...теШ1т} и и{теШ2 ]}},...}, С3 = {{{{а«г11,аЫг12, ...аЫг1п} и {аЫг3г}}, ...{{теШ1\,теЬК12, ...теШ1т} и {тeth3j}},...}, ...СМ = {{{{аЫг1\,аЫг12,... аЫг1п} и {аЫгМ}}, {{теШ11,теШ12, ...теШ1т} и {теШМ^}},...}}, {}, {}}],
где аЫг2^, аЫг3г, ... аИгМ - атрибуты классов С2 ... СМ, теШ2^, теШЗ^, ... , те^М^ -методы классов С2 ... СМ. Доказательство.
Пусть в[йс1а88ез] = {{С 1 = {{аЫг1\, аЫг12,...аЫг1п}, {теШ1\,теШ12, ...теШ1т}...}, С2 = {{аЫг2г}, {теШ2з}...},...СМ = {{аПгЩ, {теШМ^}}, {}, {С2депегС 1, С Зд епегС 1...СМдепегС 1}}.
Поочерёдно заменяя по Аксиоме 1 класс а = {{аttrij}, {т&Ык}...} и отношение наследования адепегС 1 в левой части на
а = {{аttrij} и {аЫг1\,аЫ г12,...аЫ г1п}, {т&Ы к и {теШ1\,теШ12, ...те^1т}}...}, получаем
в[йсЫвзев] = 5[{{С 1 = {{аЫг1\,аЫг12, ...аЫг1п}, {теШ1\,теШ12, ...теШ1т}...}, С2 = {{аЫг1\, аЫг12, ...аЫг1п}и{аЫг21}}, {{теШ1\,теШ12, ...те^1т}и{теШ23}},...}, С3 = {{аЫг1\, аЫг12, ...аЫг1п}и{аЫг?^1}}, {{теШ1\,теШ12, ...те^1т}и{теШ?^3}},...},... ...СМ = {{аЫг1\,аЫг12, ...аЫг1п} и {аЫгМ^}, {{теШ1\,теШ12, ...теШ1т}и и{теШМ3}},...}}, {}, {}}]. Что и требовалось доказать.
Аксиома 5 (Вторая эквивалентная трансформация) — Интерфейс. Справедливо следующее соотношение:
5[{{С 1, С2}, {11}, {С2Plde^I 1р2, С 1геа}11}}] = 5[{{С 1, С2}, {0}, {С2рк!щС 1Р2}}].
Рассмотрим в качестве примера семантически эквивалентной трансформации UML-диаграммы классов шаблон проектирования Фасад, предложенный Гаммой [1].
Аксиома 6 (Третья эквивалентная трансформация) — Фасад (Facade).
Справедливо следующее соотношение:
5[{{С 1, C2..CN}, {...}, {... U {CKdep{C2 V С3 V .. V CN}...СМ
de^{C2 V С3 V .. V CN}}}] =
= S[{{С 1 = {{{attr1i} U {С2..CN}}, {{methU} U {{meth2j} U {meth3k} U
U{methNl}}}}, {...}, {... U {СК...СМйщС 1}}],
где С1 - класс-обёртка (фасад) для остальных классов СС2 ... CN, attr1i - атрибуты класса С1, meth1i - методы класса С1, {meth2j} U {meth3k} U ... U {methNi} - мето-ды,соответствующие вызову соответствующих методов, принадлежащих классам С2 ... CN с параметром visibility = public, С К ... СМ - классы, связанные с классами С2 ... CN отношением зависимости (dependency).
4. Заключение
В работе рассматриваются вопросы эволюционного проектирования объектно-ориентированной архитектуры программного обеспечения.
Приведено формальное описание таких понятий из объектно-ориентированной парадигмы проектирования, как архитектура ПС, диаграмма классов, диаграмма прецедентов, класс, интерфейс, метод, отношение наследования и т.д.
Предложен формальный аппарат для описания семантики UML-диаграмм классов, позволяющий ввести понятие семантически эквивалентной трансформации диаграммы классов. Данный аппарат необходим для реализации эволюционного проектирования архитектуры программного обеспечения (в частности - поиска диаграммы классов с улучшенными структурными свойствами, семантически эквивалентной исходной).
Так же в работе на основе разработанного формального аппарата описываются семантически эквивалентные трансформации (наследование, введение интерфейса, введение предложенного Гаммой паттерна проектирования Фасад (Facade)).
По теме статьи автором будет сделан доклад на предстоящей II Международной научной конференции «Инжиниринг и телекоммуникации» Москва, 18-19 ноября 2015 года.
Литература
1. Gamma E., Richard H., Ralph J. and John Vl. Design patterns: Abstraction and reuse of object-oriented design // Springer Berlin Heidelberg, 1993.
2. Raiha O. Genetic Synthesis of Software Architecture University of Tampere Department of Computer Sciences // Lic. Phil. Thesis, September 2008.
3. Mancoridis S., Mitchell B.S., Rorres C., Chen Y.F. and Gansner E.R. Proc. International Workshop on Program Comprehension (IWPC 98). 1998. P. 45-53.
4. Penta M. Di, Neteler M., Antoniol G. and Merlo E. // The Journal of Systems and Software. V. 77, I. 3. 2005. P. 225-240.
References
1. Gamma E., Richard H., Ralph J. and John Vl. Design patterns: Abstraction and reuse of object-oriented design. Springer Berlin Heidelberg, 1993.
2. Raiha O. Genetic Synthesis of Software Architecture University of Tampere Department of Computer Sciences. Lic. Phil. Thesis, September 2008.
3. Mancoridis S., Mitchell B.S., Rorres C., Chen Y.F. and Gansner E.R. Proc. International Workshop on Program Comprehension (IWPC 98). 1998. P. 45-53.
4. Penta M. Di, Neteler M., Antoniol G. and Merlo E. The Journal of Systems and Software. V. 77, I. 3. 2005. P. 225-240.
Поступила в 'редакцию 01.06.2015.
