Формализация процедуры проектирования архитектур программной системы Текст научной статьи по специальности «Компьютерные и информационные науки»

СИСТЕМНЫЙ АНАЛИЗ, УПРАВЛЕНИЕ И ОБРАБОТКА ИНФОРМАЦИИ

УДК 004.41

В. Е. ГВОЗДЕВ, А. Е. КОЛОДЕНКОВА

ФОРМАЛИЗАЦИЯ ПРОЦЕДУРЫ ПРОЕКТИРОВАНИЯ АРХИТЕКТУР ПРОГРАММНОЙ СИСТЕМЫ

Рассматривается подход к формализации проектирования архитектур сложной программной системы. В основе подхода лежит построение матриц вида «объект-свойство», а также выделение на их основе непересекающихся классов объектов. Программная система ; матрица взаимосвязей ; иерархическая классификация (дендрограмма) ; архитектура требований ; архитектура информационных задач ; архитектура данных

ВВЕДЕНИЕ

Одним из основных вопросов, возникающих на ранних стадиях проектирования программной системы, является проектирование архитектуры. В известной литературе [1, 2], посвященной программным проектом, термин «архитектура программной системы» имеет множество толкований. В настоящей работе под архитектурой программной системы, следуя [3], понимается совокупность существенных решений, определяющих: организацию программной системы, выбор структурных элементов системы и их интерфейсов.

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

1. КОНЦЕПТУАЛЬНАЯ ОСНОВА

Концептуальной основой предлагаемого формализованного подхода к построению системы архитектур, соответствующей сложной программной системе, является описанная в литературе [4] «трехслойная архитектура приложений» (рис. 1).

Каждому из выделенных слоев соответствует своя архитектура требований; архитектура задач; архитектура данных. Этим архитектурам на логическом уровне ставится в соответствие иерархическая система, представленная на рис. 2. Здесь КТ1, КТ2,..., КТ^,..., КТМ - непере-секающиеся классы требований; КЗ1, КЗ2,..., КЗ^,..., КЗ^ - непересекающиеся классы информационных задач; КД1, КД2,..., КДд,..., КД -классы данных, обеспечивающие решение информационных задач.

Рис. 1. Уровни абстракции в рамках трехслойной архитектуры приложений

Контактная информация: (347)272-82-80

Рис. 2. Иерархическая схема архитектур, соответствующих разным уровнем абстракции

2. МЕТОДИЧЕСКАЯ ОСНОВА

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

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

В настоящей работе предлагается подход к выделению классов объектов на основе методов кластерного анализа.

Ограничения подхода:

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

имеют одинаковую значимость с точки зрения заказчика и не меняются в ходе проекта;

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

3) предположение о том, что число выделяемых подсистем заранее известно;

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

3. ПРОЦЕДУРА ФОРМИРОВАНИЯ АРХИТЕКТУР ПРОГРАММНОЙ СИСТЕМЫ

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

Формирование архитектуры основано на выделении классов требований, которые между собой связаны через классы информационных задач, расположенных на последующем уровне иерархии. Возможность представления требований в виде совокупности задач (visual table of contents) обосновано в литературе [6].

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

Технологическую основу формирования архитектуры требований программной системы составляет построение и обработка матриц взаимосвязей требований и реализующих их задач. Формирование упомянутых матриц основано на построении списка задач, реализующих j-е требование; формированию на их основе списка задач, реализующих все требования

N

{З} = Ц|{З} j ; формированию матриц вида

j=i

(табл. 1).

Т аблица 1

Сформированная матрица взаимосвязей «требования-задачи»

^"^^.^^Задачи Требования Зі З2 З^

Ті +

Т2 + +

ТN + + +

Здесь {З} - множество задач, решаемых при реализации /-го требования /є {1,2,...Д}; К -количество элементов {З}, т. е. общее число задач, необходимых для решения всех N требований.

Необходимость решения к-й задачи

кє {1,2,...,К} при реализации /-го требования обозначается знаком «+» (при пересечении к-го столбца и у-й строки матрицы).

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

На основе матрицы взаимосвязей рассчитываются меры сходства (различия) для всех пар требований. Полученные после вычислений значения соответствующих мер сводятся в квадратные матрицы, симметричные относительно главной диагонали (так называемые матрицы мер сходства) [6].

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

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

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

Формирование упомянутой матрицы основано на построении списка данных, реализующих /-задачу (например, в виде IDEF0, DFD модели); формированию на их основе списка за-

К

дач, реализующих все задачи {Д} = и{Д} / ;

/=1

формированию матриц вида (табл. 2).

Здесь {Д} / - множество данных, использованных при решении у-й задачи /є {1,2,.,К}; Q - количество элементов {Д}, т.е. общее число

данных, необходимых для решения всех К задач.

Т аблица 2

Сформированная матрица взаимосвязей «задачи-данные»

анные Задачи Ді Д2 ДQ

Зі +

З2 + +

Зк + + +

Необходимость решения 7-х данных при решении ]-й задачи обозначается знаком «+» (при пересечении 7-го столбца и]-й строки матрицы).

Основу формализации информационной поддержки формирования архитектуры данных составляет формирование матриц взаимосвязей «данные-имена данных».

Формирование упомянутых матриц основано на построении списка имен данных, реализующих ]-е данные; формированию на их основе списка имен данных, реализующих все дан-

Z

ные {ИД} = У {ИД}; формированию матриц

1=1

вида (табл. 3).

Т аблица 3 Сформированная матрица взаимосвязей «данные-имена данных»

Здесь {ИД} - множество имен данных, решаемых при реализации 1-х данных уе{1,2,.,2}; 2 - количество элементов {ИД}, т.е. общее число имен данных, необходимых для решения всех Q данных.

4. ПРИМЕР

Дано:

а) пусть имеется пять требования Т={ТЬ Т2, Т3, Т4, Т5}, которым ставится восемь задач З={ЗЬ З2, Зз, З4, З5, Зб, З7, З8};

б) пусть имеется восемь задач {З}={ЗЬ З2, З3, З4, З5, Зб, З7, З8}, которым ставятся данные {д}={Дь Д2, Дз, Д4, Д5, Дб};

Требуется:

1) выбрать обоснованную процедуру для выделения классов требований;

2) выделить сходства классов задач. Решение:

1) а) составим матрицу взаимосвязей требований и реализующих их задач (табл. 4).

Т аблица 4 Матрица взаимосвязей «требования-задачи»

Задачи Требо^^ вания З1 З2 З3 З4 З5 Зб З7 Зв

Т1 + + + +

Т2 + + + +

Т3 + + + +

Т4 + + + + +

Т5 + + + + +

б) посредством методологии ЮЕЕО составим матрицу взаимосвязей задач и реализующих их данных (табл. 5).

Т аблица 5 Матрица взаимосвязей «задачи-данные»

^^^'^Данные Задачи^'''^^ Д1 Д2 Д3 Д4 Д5 Дб

З1 + + +

З2 + + + +

З3 + +

З4 + + +

З5 + + +

Зб + + +

З7 + + + +

З 00 + + + + +

2) а) Результаты, получаемые при обработке матрицы (см. табл. 4) методом Жаккара и коэффициентом ассоциативности, представлены на рис. 3-4.

На рис. 3 представлена дендрограмма, построенная с помощью метода Уорда.

Рис. 3. Дендрограмма, построенная на основе матрицы меры сходства (мера сходства Жаккара)

На рис. 4 представлена дендрограмма, построенная с помощью центроидного метода.

Требования

Рис. 4. Дендрограмма, построенная на основе матрицы меры сходства, сформированной с использованием коэффициента ассоциативности

вида Suj =

,0'.j)

v(i’j) pii

(i,j ) + 2( + P0ïj))

P\\

(i.j )

Здесь p"’J/ = p00

,0' ,j )

+p0ïj) + PÏ0.j) + p(ïj ),

где

p0¿J ' - доля задач из всего множества задач

при реализации всех N требований, не решаемых при реализации i-го и j-го требований;

p0ï1 ) - доля задач из всего множества задач

при реализации всех N требований, не решаемых при реализации i-го требования и решаемых при реализации j-го требования;

(i, i)

p10 - доля задач из всего множества задач

при реализации всех N требований, решаемых при реализации i-го требования и не решаемых при реализации j-го требования;

piï1 ) - доля задач, решаемых при реализации i-го и j-го требований из всего множества задач при реализации всех N требований.

Для данной исходной матрицы (см. табл. 4) целесообразно выделить следующие классы требований:

1) мера сходства Жаккара:

• метод одиночной связи: Кл1={Т3, Т4}, Кл2={Т1, Т5}, Клз={Т2};

• метод полной связи: Кл1={Т3, Т4}, КД2={ТЬ Т5}, Клз={Т2};

• центроидный метод: Кл1={Т3, Т4},

КД2={ТЬ Т5}, Кл3={Т2};

• метод Уорда: Кл1={Т3, Т4}, Кл2={Т1, Т5}, Кл3={Т2};

• метод медиан: Кл1={Т3, Т4}, Кл2={Т1, Т5}, Кл3={Т2};

2) коэффициент ассоциативности S =

= pii :

pii + 2( pío + poi)

• метод одиночной связи: Кл1={Т3, Т4}, КД2={ТЬ Т5}, Кл3={Т2};

• метод полной связи: Кл1={Т3, Т4}, КД2={ТЬ Т5}, Кл3={Т2};

• центроидный метод: Кл1={Т1, Т2, Т4, Т5}, Кл2={Тз};

• метод Уорда: Кл1={Т3, Т4}, Кл2={Т1, Т5}, Клз={Т2};

• метод медиан: Кл1={Т1, Т3, Т4, Т5}, Кл2={Т2}.

б) Результаты, получаемые при обработке матрицы (см. табл. 5) методом Жаккара и коэффициентом ассоциативности, представлены на рис. 5-6.

На рис. 5 представлена дендрограмма, построенная с помощью метода Уорда.

Рис. 5. Дендрограмма, построенная на основе матрицы меры сходства (мера сходства Жаккара)

На рис. 6 представлена дендрограмма, построенная с помощью метода одиночной связи.

0,70

0,65

0,60

0,55

0,50 ■

0,45

0,40

0,35

0,30

0,25 ■

Рис. 6. Дендрограмма, построенная на основе матрицы меры сходства, сформированной с использованием коэффициента ассоциативности

2( ^ })

Здесь

,0'> ] )

,0' > ] )

. р0,}) + р0,}) + ро,}) + р0,})

гоо ~ .Рої ~.Г10 ~ Уи ■

где p00J' - доля данных из всего множества

данных при реализации всех L задач, не решаемых при реализации 7-й и j-й задач;

(i, j )

Рої - доля данных из всего множества данных при реализации всех L задач, не решае-

мых при реализации 7-и задачи и решаемых при реализации j-й задачи;

(7, j )

PiQ - доля данных из всего множества данных при реализации всех L задач, решаемых при реализации 7-й задачи и не решаемых при реализации j-й задачи;

pfr1 ) - доля данных, решаемых при реализации 7-й и j-й задач из всего множества данных при реализации всех L задач.

Для данной исходной матрицы (см. табл. 5) целесообразно выделить следующие классы задач:

1) мера сходства Жаккара:

• метод одиночной связи: Кл1={З1, З3, З8}, Кл2={З2, З5, З7}, Клз={З4}, Кл4={Зб};

• метод полной связи: Кл1={З4, З6}, Кл2={З1, З8}, Клз={З2, З5, З7}, Кл4={Зз};

• центроидный метод: Кл1={З2, З5, З7}, Кл2={З1, З4, З8}, Клз={Зб}, Кл4={Зз};

• метод Уорда: Кл1={З4, З6}, Кл2={З1, Зз, З8}, Клз={З2, З5, З7};

• метод медиан: Кл1={З2, З4, З5, З7, З8}, Кл2={Зб}, Клз={З1}, Кл4={Зз};

2) коэффициент ассоциативности S =

= 2(P11 + Po1) :

P + P11 + Poo

• метод одиночной связи: Кл1={З1, З2}, Кл2={З4, З5}, Клз={З7, З8}, Кл4={Зб}, Кл5={Зз};

• метод полной связи: Кл1={З1, З2},

Кл2={З4, З5}, Клз={З7, З8}, Кл4={Зб}, Кл5={Зз};

• центроидный метод: Кл1={З4, З5, З6, З7, З8}, Кл2={З1} Клз={З2}, Кл4={Зз};

• метод Уорда: Кл1={Зь З2}, Кл2={З7, З8}, Клз={Зз, З4, З5, Зб};

• метод медиан: Кл1={З4, З5, З6, З7, З8}, Кл2={З1}, Клз={З2}, Кл4={Зз}.

Метод иерархической классификации подбирается проектировщиком индивидуально для исследуемой предметной области с учетом ее специфики [7]. Единых правил выбора не существует. Главным критерием для выбора метода классификации может являться хорошая интерпретируемость получаемых результатов, не противоречащих физическому смыслу изучаемой предметной области.

5. ЗАКЛЮЧЕНИЕ

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

В силу неоднозначности подходов к выбору схожести задач, обработки матриц «объект-свойство», получаемые решения носят рекомендательных характер.

СПИСОК ЛИТЕРАТУРЫ

1. Макконенелл, С. Сколько стоит программный проект / С. Макконенелл. М. : «Русская редакция». СПб. : Питер, 2007. 297 с.

2. Бэгьюли, Ф. Управление проектом / Ф. Бэгьюли. М. : ФАИР-ПРЕСС, 2002. 208 с.

3. Крылов, Е. В. Техника разработки программ : Кн 2. Технология, надежность и качество программного обеспечения / Е. В. Крылов, В. А. Острейковский, Н. Г. Типикин. М. : Высшая школа, 2008. 469 с.

4. Васкевич, Д. Стратегии клиент/сервер. Руководство по выживанию для специалистов по реорганизации бизнеса / Д. Васкевич. Киев : Дианетика, 1996. 396 с.

5. Грекул, В. И. Проектирование информационных систем : учеб. пособие для студентов вузов, обучающихся по спец. в обл. инф. технологий / В. И. Грекул, Г. Н. Денищенко, Н. Л. Коровкина. М. : Интернет-ун-т инф. технологий, 2005. 304 с.

6. Майерс, Г. Надежность программного обеспечения / Г. Майерс. М. : Мир, 1980. 360 с.

7. Андрейчиков, А. В. Анализ, синтез и планирование решений в экономике / А. В. Андрейчиков, О. Н. Андрейчикова. М. : Финансы и статистика, 2002. 364 с.

8. Кульба, В. В. Оптимизация структур распределенных баз данных в АСУ / В. В. Кульба, А. Г. Мамиконов, С. А. Косяченков, И. А. Ужастов. М. : Наука, 1990. 240 с.

ОБ АВТОРЕ

Гвоздев Владимир Ефимович,

зав. каф. автоматиз. проектир. инф. систем. Дипл. инж. электрон. тех-ки (УАИ, 1978).

Д-р техн. наук по АСУ (УГАТУ, 2000). Иссл. в обл. АСУ, открытых инф. систем, прикл. статистики, теории надежности, контроля и управ. сост. окр. среды.

Колоденкова Анна Евгеньевна, доц. той же каф. Дипл. инж.-системотехн. по АСОИУ (УГАТУ, 2004). Канд. техн. наук (УГАТУ, 2007). Иссл. в обл. прикл. статистики, системн. анализа, контроля и управления территор. объектов, информац. систем, технологии системн. модел-я.