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

X МОДЕЛИРОВАНИЕ СИСТЕМ И ПРОЦЕССОВ

УДК 004.421.4

МЕТОД ПОЛУЧЕНИЯ ОЦЕНОК ВРЕМЕНИ ВЫПОЛНЕНИЯ НА РАННИХ ЭТАПАХ ПРОЕКТИРОВАНИЯ СЛОЖНЫХ РАСПРЕДЕЛЕННЫХ ПРИЛОЖЕНИЙ

А. В. Гордеев,

доктор техн. наук, профессор

Санкт-Петербургский государственный университет аэрокосмического приборостроения Н. А. Кобзарев,

зам. начальника отдела разработки программного обеспечения ОАО «РИВЦ-Пулково»

Рассмотрены основные средства построения распределенных приложений, возможности средств моделирования. Предлагается новый подход к анализу моделей приложений, позволяющий определять потенциальные ошибки проектирования до выполнения стадии программирования и тестирования, не усложняя работу системного архитектора. Данный метод заключается в преобразовании исходных UML-диаграмм проекта к диаграммам Ганта. Необходимые данные для построения диаграмм Ганта предлагается получать на основе метаданных исходных UML-диаграмм.

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

В качестве основных средств графического отображения модели нового проекта можно выделить UML-диаграммы. Многие системы программирования предоставляют свои системы моделирования на основе UML. Все их перечислять не имеет смысла, функциональные возможности у них примерно одинаковы. Для примера можно обратить внимание на продукты Visual Studio Team System или Rational Software Architect как наиболее распространенные и передовые в смысле используемых технологий. Чтобы не пересказывать многочисленную литературу, лишь отметим, что приложения моделирования достигли большой гибкости, поддерживают различные технологии как моделирования, так и архитектуры распределенных приложений [1].

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

екта. Средства моделирования позволяют создавать код из диаграмм и наоборот — диаграммы из кода [1]. Элементы диаграмм не ограничены минимальным набором объектов, а поддерживают высокий уровень абстракций и необходимое количество скрытой вспомогательной информации — метаданных [2]. На основе метаданных производятся различные проверки, сопоставления и, в конечном счете, генерация шаблонов исходного кода. Без использования метаданных такие возможности были бы недоступны, но, тем не менее, диаграммы остаются инструментом проектирования и повышения наглядности. Многие системы позволяют производить тестирование модулей, но такие тесты возможны только после завершения процесса разработки. При этом тестируется работа программиста; произвести автоматизированный анализ архитектуры проекта на ранних этапах разработки с целью получения качественных характеристик не представляется возможным.

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

грамму на новый уровень, позволяя применить к этой диаграмме автоматизированные средства проверок и преобразований [2].

Для получения системным архитектором интересующих его оценок того или иного варианта проекта фактически требуется выполнить моделирование проекта. Иными словами, нужно определить поведение разрабатываемого проекта в реальной среде. Однако для получения таких оценок требуется ответить на вопрос, как моделировать проект, если он еще не закончен. Если (для примера) в качестве средства моделирования предложить имитационное моделирование на основе сетей Петри и их модификаций [3], то детализированная сетевая модель проекта может стать достаточно большой. Известно, что в то время, как сеть Петри растет, сложность работы с такой моделью растет намного быстрее, и в конечном итоге произвести моделирование и анализ станет практически невозможно [4]. Очевидно, что решение о применении имитационного моделирования не всегда приемлемо, накладные расходы на проведение моделирования и анализ свойств создаваемого проекта могут потребовать слишком много вычислительных ресурсов и времени.

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

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

Итак, мы уже отмечали, что в своей повседневной работе системный архитектор использует средства моделирования, позволяющие строить некоторые UML-диаграммы. Необходимо, не усложняя процесс проектирования и не требуя от архитектора дополнительных действий, произвести преобразование некоторого фрагмента проектируемой диаграммы к диаграмме Ганта, на основе которой можно рассчитать критические пути и потенциальные критические пути в будущем приложении [6].

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

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

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

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

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

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

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

Рис. 1. Схема приложения

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

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

Второй шаг — получить на исходной диаграмме путь прохождения и обработки данных. В нашем примере имеется три функции приложения, которые можно обозначить как функции ввода данных — Init, проверки — Check и просмотра — Rеport_browser. Требуется выделить только одну функцию, которая в данный момент интересует системного архитектора. Этот процесс назовем процессом редуцирования исходной схемы приложения. Полная схема приложения представлена на рис. 1. Процесс редуцирования предполагает получение пути от исходного процесса диаграммы до конечного посредством анализа взаимосвязей между процессами по метаданным диаграммы. Выделив на схеме начальный процесс — Init и конечный — Database, архитектор имеет возможность добавлять или убирать необходимые для анализа процессы.

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

На следующем шаге для всех задействованных процессов производятся вычисления необходимых параметров по функциям fa и fb. Следует отметить, что для процесса Interaction один из параметров недетерминирован. Это связано с тем, что для продолжения выполнения вычислений требуется вмешательство пользователя. В нашем примере — это время реакции пользователя на запрос системы. Поэтому результат вычисления будет функцией от времени реакции пользователя.

На основе экспертных оценок и полученных выражений связи исходных параметров (метаданных) с временными оценками для каждого процесса требуется получить оптимистические и пессимистические оценки времени выполнения fa и fb. Таким образом, рассчитывается ожидаемая продолжительность работы как

t _ 3aij + 2bij tij ~ 5 ,

где а — оптимистическая оценка длительности операции; b — пессимистическая оценка [6]. Индексы i и j обозначают номера процессов, тогда ti,j — это время выполнения процесса i и переход

■ Взаимные связи между элементами UML-диаграммы

Init Background Interaction Process Database

Init fla(); flb() + + - -

Background f2a(); f2b() - + -

Interaction f3a(); f3b() + -

Process f4a()’ f4b() +

Database f5a(); f5b()

к выполнению процесса ]. Процессы нумеруются от 1 до ш, а путь между событиями I и ] обозначается Ьц. Вид диаграммы Ганта для рассматриваемого примера представлен на рис. 2.

На основе этих данных можно рассчитать границы временного промежутка выполнения операции — раннего (р) и позднего (п) срока начала операции и резерва времени выполнения:

Т = Т + X , тп = То- Е Ъ = тп-тр.

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

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

,р.н _ тР +р.° _ тр + *

11,} 11 ’ Н,] 11 ~ГЧ,}>

*п.о _тп *п.н _тп_*

\] -, %] -%],

_ грп. грр . гсв — тр — тп — *

П,1 - Ч], Ч/ - Ч].

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

Наиболее важным параметром является критическое время выполнения Ткр — минимальное

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

ткр = У .

кр ^ I]

1,]<ёЬкр

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

— дисперсия реальной продолжительности операции

bij - aij 5

V

— дисперсия критического пути передачи информации

^кр =Х;

и]

— среднеквадратическое отклонение критического пути

^ кр

Вероятность того, что продолжительность кри-

P(t < T < t ) = Ф

V min _ кр _ max /

Г t - T Л

max кр

°кр

- Ф

гт -t ■ Л

кр min °кр

У

где Ф — функция Лапласа.

Например, для того чтобы вероятность успешного выполнения операции в заданный срок была в диапазоне 0,25 ^ 0,65, требуется, чтобы

*шт _ ткр _ 0,7 ^^, *тах _ ткр ^ 0,4^кр.

Таким образом, на этом шаге нашего алгоритма анализа архитектуры проекта мы осуществляем следующие вычисления:

— на первом проходе анализа полученной диаграммы Ганта для всех процессов вычисляем время выполнения каждого процесса;

— на втором проходе вычисляем ранние времена начала процессов и определяем критическое время выполнения всего пути;

тического пути не выходит за пределы tmin и tmax:

Название задачи Длитель- ность Начало Оконча- ние Предшест- венники 0 5 10 1 1 _!_ 1 1 1 I 1 1 1 1

1 Init 1 гт 0 1

2 Background 3 ШБ 1 4 1

3 Interaction 2 гтк 1 3 1

4 Process 5 тэ 4 9 2;3 | К

5 Database 1 тз 9 10 4 Г 1

■ Рис. 2. Вид диаграммы Ганта

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

Следующим шагом является структуризация информации и передача ее из полученной диаграммы Ганта на исходную UML-диаграмму.

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

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

— В соответствии с принципами диаграмм Ганта нет возможности анализировать циклические процессы, можно лишь развернуть путь данных в виде совокупности параллельных путей на оси времени.

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

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

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

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

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

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

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

— N продолжительностей работ;

— N4 ожидаемых границ времени выполнения;

— N2 резервов времени выполнения.

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

Литература /

1. Kunal Mittal. Introducing IBM Rational Software Architect. http://www.ibm.com/developerworks/rational/ library/05/kunal/?S TACT=105AGX99&S CMP=CP

2. Hundhausen R. Working with Microsoft visual studio 2005 team system. Microsoft Press, 2005. 320 p.

3. Гордеев А. В. Моделирование дискретных параллельных систем с использованием F-сетей Петри // Ин-формационно-управляющие системы и сети. Структуры, моделирование и алгоритмы: Сб. ст. СПб.: Политехника, 1999. С.56-69.

4. Hurson A. R., Zelkowitz M. V. Advances in Computers. Academic Press, 2005. 312 p.

5. Program Evaluation and Review Technique. http:// en.wikipedia.org/wiki/Pert

6. Ковыле в Ю. И., Тимошин С. И., Тихомиров О. И. Организация, планирование и управление приборостроительным предприятием / ЛИАП. Л., 1986. 70 с.