Содержание к диссертации
Введение
1 Производительность в процессе разработки программного обеспечения 11
1.1 Производительность программного обеспечения 11
1.1.1 Понятие производительности 11
1.1.2 Метрики производительности 12
1.1.3 Методы оценки производительности 13
1.1.4 Значение производительности 15
1.2 Интеграция анализа производительности п жизненный цикл разработки программного обеспечения 17
1.2.1 Производительность и процесс разработки ПО 17
1.2.2 Требования к интеграции 19
1.2.3 Существующие технологии анализа производительности в процессе разработки ПО 20
1.2.4 Необходимость разработки технологии 29
1.3 Использование моделей UML для анализа производительности , 32
1.3.1 Анализ производительности на основе модели проектирования - 32
1.3.2 Существующие подходы к использованию моделей UML
для анализа производительности 34
1.4 Оценка средств построения и анализа модели производительности 36
1.4.1 Сети массового обслуживания 38
1.4.2 Сети Петри 43
1.4.3 Алгебры процессов 47
1.4.4 Имитационное моделирование 50
1.4.5 Сравнительная характеристика и выбор средства моделирования 52
Основные результаты и выводы к главе 1 55
Анализ производительности программного обеспечения на основе модели UML 56
2.1 Диаграммы UML и моделирование производительности 56
2.1.1 Моделирование структуры и поведения программного обеспечения 58
2.1.2 Моделирование окружения системы 60
2.2 Построение модели производительности 61
2.3 Анализ модели производительности 77
2.3.1 Редукция модели 79
2.3.2 Трансформация процессоров 81
2.3.3 Разбиение на подмодели 82
2.3.4 Анализ подмоделей 87
2.3.5 Интерпретация результатов 92
2.4 Место анализа производительности в жизненном цикле разработ ки программного обеспечения 93
2.4.1 Модель водопада 93
2.4.2 Итеративные методологии 94
2.4.3 Гибкие методологии 95
Основные результаты и выводы к главе 2 96
Программное решение для анализа производительности на основе моделей UML 98
3.1 Характеристика разработанного программного решения 98
3.2 Использование формата XMI для получения исходных данных . 99
3.3 Архитектура разработанного программного решения 101
3.3.1 Бизнес-логика : . 101
3.3.2 Графический пользовательский интерфейс 108
3.4 Оценка эффективности применения информационной тсхтюлогии 109
Основные результаты и выводы к глапе 3 112
Заключение 115
Приложения
- Понятие производительности
- Производительность и процесс разработки ПО
- Моделирование структуры и поведения программного обеспечения
- Использование формата XMI для получения исходных данных
Введение к работе
Актуальность работы. Одной из ключевых характеристик современного программного обеспечения (ПО) является производительность, Низкая производительность может обуславливать неэффективность работы пользователей и, как следствие, негативную реакцию на программный' продукт, потерю прибыли и клиентуры, доли рынка; перерасход средств вследствие затрат на модификации и перепроектирование. Более того, переработка кода с целью увеличения производительности с большой вероятностью может разрушить первоначальную структуру системы, сводя на нет преимущества от использования объектно-ориентированного подхода. Наконец, маловероятно, что переработанный код сможет довести производительность системы до уровня, на котором она могла бы быть в случае изначального проектирования с учетом вопроса производительности. В худшем случае, будет невозможно достичь поставленных целей простой модификацией исходного кода системы, что обусловит необходимость полного перепроектирования или остановки проекта. В литературе рассмотрены случаи, когда руководство было вынуждено инициировать полное переписывание системы [92] или, например, отложить запуск космического спутника [27]. В последнем случае программное обеспечение реализовывалось Национальным Аэрокосмическим Агентством США (NASA), и задержки, вызванные проблемами с производительностью, заставили Конгресс США рассматривать вопрос о способности NASA выполнять проект.
Очевидно, что большинство серьезных проблем с производительностью программного обеспечения вызвано недооценкой этого вопроса на ранних стадиях процесса разработки, в частности на этапе проектирования. Низкая производительность чаще всего обусловлена недостатками проектирования, а не
реализации. Однако п объектно-ориентированном сообществе распространена
тенденция откладывать рассмотрение вопроса производительности до момента, когда система реализована. Типичной является следующая формулировка классиков объектно-ориентированного программирования Ауэра и Бека: "Игнорируйте эффективность в течение всего цикла разработки. Выполняйте необходимые настройки производительности, когда программа работает корректно и структура системы выражает ваше понимание о том, как оптимально должен быть организован исходный код. Необходимые изменения будут ограничены соответствующими границами или выявят возможности для улучшения проектирования"[7]. Аналогичных взглядов придерживается и еще один признанный специалист в объектно-ориентированном подходе к разработке программного обеспечения Айвар Якобсон: "Изменения в архитектуре системы, вносимые для улучшения производительности, должны, как правило, откладываться до момента, когда система (хотя бы частично) построена. Практика показывает, что при принятии решений о местах системы, критичных по производительности, часто делают ошибки. Для того чтобы сделать правильную оценку, в большинстве случаев, необходимо иметь что-то, что можно измерить. Поскольку нам нечего измерять до момента построения системы, мы не можем выполнять подобную оптимизацию на ранних этапах"[41].
Подобные взгляды базируются на представлении о том, что производительность программного обеспечения трудно спрогнозировать, и модели, необходимые для прогнозирования производительности разрабатываемой системы, слишком сложны и требуют значительных затрат. Функциональность объектно-ориентированной системы децентрализована. Выполнение некоторой функции с большой вероятностью вовлекает в этот процесс много объектов различных классов. Эти взаимодействия могут быть множественными и очень сложными, а использование приемов объектно-ориентированного проектирования (например, полиморфизма) и таких широкораспространенных ныне подходов, как применение паттернов или распределенной архитектуры системы, затрудняет процесс моделирования.
Помимо этого, сложившаяся практика такова, что область проектирования
программного обеспечения с одной стороны и анализа производительности с другой - являются достаточно удаленными, практически изолированными, друг от друга. С точки зрения архитекторов и проектировщиков программных систем методики прогнозирования производительности видятся достаточно сложными математическими формализмами, которые если и возможно применять в процессе проектирования, то только при крайней необходимости (например, при разработке систем реального времени) и в тесном взаимодействии с экспертами в данных методиках.
Еще одним фактором, обуславливающим игнорирование вопросов производительности на ранних стадиях процесса разработки, является нежелание менеджеров ставить под угрозу сроки и бюджет проекта ради стратегических целей, таких как безусловное достижение всех установленных требований к производительности.
Несмотря на указанные проблемы, многие эксперты считают, что спроектировать программную систему с учетом вопросов производительностью практически возможно. Этой задаче посвящены работы таких авторов, как Смит К., Уильяме Л., Петриу Д., Вудсайд М., Хиллстон Дж., Ролиа Дж., Фрэнке Р. Регулярно проводятся международные конференции, посвященные вопросам анализа производительности программного обеспечения, в частности International Workshop on Software and Performance (WOSP).
Слабым местом существующих решений по анализу производительности программного обеспечения является необходимость создания и поддержки отдельной модели производительности в дополнение к уже существующим моделям (таким как модель проектирования, модель данных и т.д.). Кроме того, большинство подобных подходов рассчитано на непосредственное использование специализированных математических моделей, что повышает требование к подготовке участников команды разработки и, тем самым, снижает эффективность внедрения.
Таким образом, несмотря на активные разработки в данной области, проблема создания эффективного подхода к анализу производительности в процессе разработки программного обеспечения до конца не решена. Для того чтобы бы-
7 ло возможно учитывать вопросы производительности в течение всего процесса
разработки, начиная с ранних стадий, должна быть создана технология, позволяющая, не нарушая сложившийся подход к проектированию программного обеспечения, оценивать те или иные архитектурные решения с точки зрения производительности. При этом должны быть минимизированы издержки использования подобной технологии, для чего она должна опираться в основном на уже существующие артефакты проектирования и не требовать математической подготовки от участников коллектива разработчиков. Под артефактами проектирования понимаются данные моделирования, управления проектами, системной конфигурации, т. е. компоненты информационных систем, которые описывают информационные системы [118].
Цель работы: разработка информационной технологии анализа производительности в процессе разработки программного обеспечения, обеспечивающей повышение качества и снижение затрат на его создание.
Для достижения поставленной цели были поставлены и решены следующие задачи:
Формирование требований к интеграции анализа производительности в процесс разработки программного обеспечения.
Исследование существующих технологий анализа производительности в процессе разработки программного обеспечения, обоснование необходимости разработки информационной технологии, удовлетворяющей поставленным требованиям.
Анализ существующих средств моделирования производительпости программного обеспечения.
Разработка информационной технологии анализа производительности в процессе разработки программного обеспечения.
Разработка программного комплекса, реализующего предложенный подход.
8 Методы исследования. В ходе диссертационного исследования были использованы метод эксперттгых оценок, объектно-ориентированное проектирование и программирование, математическое моделирование, аппарат многоуровневых сетей массового обслуживания, методы математической статистики.
Научная новизна. Получены следующие основные результаты, обладающие научной новизной:
Разработана новая информационная технология, позволяющая внедрить анализ производительности п процесс разработки программного обеспечения с ранних стадий без необходимости привлечения специализированных моделей и средств.
Предложен алгоритм автоматической генерации модели производительности на основе диаграмм UML.
Модифицирован алгоритм анализа многоуровневых сетей массового обслуживания для эффективной поддержки моделей, полученных на основе диаграмм UML.
Практическая значимость. Разработанная информационная технология позволяет внедрить превентивный подход к вопросам производительности в процесс разработки программного обеспечения без необходимости привлечения специализированных моделей и средств, обеспечивая повышение качества и снижение затрат на создание ПО.
Реализовано программное решение, автоматизирующее формирование и анализ модели производительности на основе уже существующих артефактов проектирования. Применение продукта не требует от участников команды разработки каких-либо дополнительных знаний в области моделирования производительности.
Реализация результатов и их внедрение. Разработанная информационная технология и поддерживающее ее программное решение внедрены в процессе разработки ПО в ООО "ТВ-Система"(г. Томск), 000 "Интрайс"(г. Томск), Томском Политехническом Университете (г. Томск).
9 Апробация работы. Основные положения диссертации докладывались и
обсуждались на научных семинарах кафедры оптимизации систем управления АВТФ ТПУ; конференции Ассоциации научных и учебных организаций-пользователей сетей передачи данных "Е1ЕЬА1Ш"(Нижний Новгород, 1997); всероссийской научно-методической конференции "Телематика" (Санкт-Петербург, 1998); международной научно-практической конференции "Актуальные проблемы информатики и информационных технологий"(Тамбов, 2004); международном симпозиуме "KORUS"(Hoboch6hpck, 1999; Томск, 2004); международной научной конференции "Инновации в науке и образовании" (Калининград, 2004); всероссийской научно-практической конференции "Системы и средства автоматизации"(Томск, 2004); всероссийской научно-технической конференции "Проблемы информатики в образовании, управлении, экономике и технике"(Пенза, 2005).
Публикации. По результатам выполненных исследований опубликовано 11 работ.
Структура и объем работы. Диссертация состоит из введения, 3 глав и заключения. Объем диссертации составляет 135 страниц текста, 45 рисунков, 3 таблиц, список литературы из 117 наименований.
Основное содержание работы. В первой главе рассматривается проблема производительности как одной из ключевых характеристик программного обеспечения, метрики и методы оценки производительности. Показывается необходимость интеграции анализа производительности в процесс разработки программного обеспечения для гарантированного выполнения требований по производительности конечным продуктом, формулируются критерии эффективности подобного подхода.
Рассматриваются существующие технологии анализа производительности в процессе разработки программного обеспечения, такие как Software Performance Engineering (SPE), Performance Design & Engineering (PDE), Structure & Performance Specification (SP), Hierarchical Evaluation Tool (HIT). Обосновывается необходимость создания новой информационной технологии анализа производительности.
В рамках интеграции технологии с'уже существующими методологией и нотацией разработки предлагается использовать язык UML в качестве средства описания исходных данных.
Проводится анализ существующих средств построения и анализа модели производительности, включающий сети Петри, сети массового обслуживания, алгебры процессов и имитационное моделирование. С использованием предложенной системы критериев обосновывается выбор многоуровневых сетей массового обслуживания.
Во второй главе рассматривается авторский подход к моделированию производительности на основе диаграмм UML с помощью многоуровневых сетей массового обслуживания. Определяется набор дополнений к стандартной нотации UML, позволяющий отразить параметры производительности в модели. Описывается алгоритм формирования модели производительности с помощью многоуровневых сетей массового обслуживания на основе модели UML. Рассматривается используемый метод анализа многоуровневых сетей массового обслуживания, предлагается алгоритм редукции модели и правила интерпретации результатов анализа.
В третьей главе рассматривается разработанное программное решение, реализованное на языке Java, позволяющее генерировать и анализировать модель производительности. Приводится описание архитектуры приложения, иллюстрируемое диаграммами UML. Описывается проведенное исследование, направленное на оценку эффективности применения информационной технологии. Исходными данными для исследования послужило существующее программное приложение (информационный портал), реализованное с использованием UML моделирования.
В заключении сформулированы основные результаты работы, а также перспективы дальнейшего развития информационной технологии и реализованного для ее поддержки программного решения.
В приложении приведены документы о внедрении результатов диссертационной работы.
Понятие производительности
Для того чтобы однозначно оценить производительность программного обеспечения с количественной точки зрения используются метрики производительности. Метрика - это система {совокупность единиц и отношений между ними) измерения того или иного аспекта производительности системы.
Одна из основных метрик производительности - время отклика (response time). Эта величина определяется временем, проходящим с момента поступления запроса и выполнением этого запроса (получением конечного результата).
Другая часто используемая метрика - это пропускная способность (throughput), которая рассчитывается как количество запросов к ресурсу, выполняемых в единицу времени.
Загрузка (utilization) представляет собой отношение промежутка, в течение которого ресурс занят обработкой запросов, ко времени его простоя.
Все перечисленные метрики могут рассматриваться на различных уровнях абстракции в зависимости от глубины декомпозиции ресурса, обрабатывающего рассматриваемый запрос. Таким образом, например, если время отклика с точки зрения пользователя это время, прошедшее с момента инициации операции до момента получения конечного результата, то при более детальной декомпозиции системы - это может быть временем выполнения запроса к одному из модулей системы.
Фактически, с помощью перечисленных метрик можно сформировать полный набор требований к производительности программного продукта.
Для получения метрик производительности программного обеспечения используются два основных способа: [43] измерение; моделирование. Измерение производительности Измерение применяется в большинстве случаев, когда система существует и к ней имеется доступ. Различают следующие типы измерения производительности: [43] пассивное измерение; слабопассивное измерение; активное измерение.
Пассивное измерение производительности предполагает отсутствие какого-либо взаимодействия между измерителем и измеряемой системой. Измеритель просто фиксирует результаты деятельности системы. Примером пассивного измерения является прослушивание (sniffing) сетевых пакетов.
Слабопассивное измерение также не предполагает воздействия измерителя на систему, однако допускает вариант, при котором измеритель является частью измеряемой системы. В последнем случае измеряемая производительность системы может быть ниже реальной, так как часті) ресурсов расходуется на замеры. Примером слабопассивного измерения является профилирование (profiling) программной системы с помощью специализированных средств (для Java существуют, например, JProfiler и JProbe).
Активное измерение подразумевает воздействие измерителя на измеряемую систему - например, создание рабочей нагрузки и изменение ее состояния. В качестве примера можно привести эталонные тесты (benchmarks) и нагрузочные тесты (stress tests).
В некоторых случаях, для получения требуемых показателей различные типы измерения комбинируют. Например, для нахождения узких мест в системе можно создавать рабочую нагрузку с помощью нагрузочного теста и параллельно отслеживать производительность отдельных компонентов системы с помощью профилировщика. Моделирование производительности Моделирование производительности используется в том случае, когда система не существует в виде, пригодном для измерения, или измерение является сложным либо высокозатратным. В ряде случаев некоторые типы измерения в принципе невозможно произвести. Например, нагрузочный тест системы управления атомной станцией представляется достаточно опасным мероприятием.
При моделировании производительности абстрактное представление системы, называемое моделью, используется для отражения основных характеристик системы для воспроизведения ее производительности. Модель анализируется для определения поведения системы и нахождения значений метрик производительности [30].
Существуют два основных подхода к моделированию производительности: аналитическое моделирование; имитационное моделирование. Аналитическое моделирование предполагает использование математических моделей и методов для создания и анализа модели, тогда как имитационное моделирование предполагает написание специализированных компьютерных программ.
Производительность и процесс разработки ПО
Технология Performance Design & Engineering (PDE), разработанная фирмой Digital [50], ставит перед собой те же цели и задачи, что и SPE, и основывается на сходных принципах.
Технология PDE ориентирована на управление характеристиками производительности на протяжении всего жизненного цикла процесса разработки программного обеспечения. Технология выделяет два вида характеристик производительности: атрибуты рабочей нагрузки - это функциональные элементы системы, характеризующиеся степенью использования физических компонентов окружения системы: физические компоненты - ресурсы окружения системы, используемые программным обеспечением и характеризующиеся своей емкостью.
Фактически, характеристики рабочей нагрузки соответствуют модели выполнения программы в SPE, а характеристики физических компонентов - модели выполнения системы.
На основе двух наборов характеристик в PDE строится моделі, производительности с помощью формализма сетей массового обслуживания. Математический анализ модели производительности позволяет получить такие результаты как время отклика для пользователя системы; пропускная способность ресурсов; загрузка ресурсов.
Использование PDE позволяет выявлять причины низкой производительности разрабатываемого программного обеспечения и прогнозировать эффект от внесения изменений в архитектуру системы. Как уже было сказано выше, технология предполагает, что разработка и поддержка модели производительности должна вестись на протяжении всего жизненного цикла. Текущая производительности программного продукта должна контролироваться на каждой из контрольных точек (milestones) процесса разработки. Так же как и в SPE, точность модели растет от грубых оценок на начальных этапах, увеличиваясь с каждой пройденной стадией разработки.
Технология PDE выделяет следующие этапы анализа производительности: определение рабочей нагрузки - выделение высокоуровневых действий, выполняемых пользователями системы; идентификация бизнес-функций - определение целей и задач системы, функций, составляющих ее бизнес-логику; определение частоты выполнения бизнес-функций - расчет частоты использования тех или иных бизнес-функций в периоды пиковой нагрузки; анализ функций - высокоуровневое проектирование функций, составляющих бизнес-логику; определение элементов функций - построение детального иерархического дерева функций и подфункций; определение относительной частоты выполнения - расчет частоты использования тех или иных подфункций относительно родительских функций. Значения могут указываться в виде верхней и нижней границы; определение использования ресурсов - оценка использования ресурсов каждой функцией. Этот шаг является очень сложным и трудоемким, некоторые способы его выполнения: — прототипирование - построение прототипа и измерение характеристик выполнения конкретных функций; — декомпозиция функций - выделение неделимых низкоуровневых функций, таких как обращение к базе данных, у которых можно однозначно определить требования к ресурсам; — приближенный подсчет - отражение в оценке опыта экспертов. Данный метод дает грубые и приближенные оценки, поэтому по возможности он должен использоваться как можно реже; — указание требований к производительности - использование установленных требований к продукту в качестве оценок. Этот способ может использоваться только в редких случаях, когда команда уверена, что не берет на себя слишком большие обязательства; анализ производительности - определение аппаратной конфигурации и про гнозирование производительности разрабатываемого программного обеспе чения: — идентификация физических компонентов - определение списка физиче ских компонентов, составляющих окружение программного обеспечения; - формирование сети массового обслуживания - сеть очередей массового обслуживания строится на основе набора физических компонентов, частоты выполнения бизнес-функций и использования ресурсов бизнес-функциями; - прогнозирование производительности - математический анализ сформированной сети массового обслуживания позволяет получить такие метрики, как среднее время отклика и пропускная способность, загрузка физических компонентов, глубина очереди. Полученные результаты может быть детализированы до самых низкоуровневых неделимых функций; - внесение изменений в архитектуру или конфигурацию - если полученные результаты не удовлетворяют требованиям к производительности, необходимо либо рассмотреть варианты изменения архитектуры системы либо увеличить емкость ресурсов окружения. Для этого модель производительности позволяет выявить компоненты и функции, являющиеся узкими местами.
Технология PDE, также как и SPE, имеет средство автоматизации процесса анализа производительности, реализующее соответствующий подход [20].
Моделирование структуры и поведения программного обеспечения
Рассматривать поведение программного обеспечения необходимо начинать с высокоуровневых функций, доступных пользователям. Чаще всего именно оценка быстродействия с точки зрения пользователя является решающим фактором при оценке производительности.
В языке UML для описания высокоуровневых функций программного обеспечения используются варианты использования. Вариант использования соответствует последовательности действий, выполняемых системой для того, чтобы пользователь мог получить определенный результат [100]. Пользователь представлен в U ML а лементом, называемым актером (Actor). Взаимодействие актеров и вариантов использования изображаются на диаграммах вариантов использования.
С точки зрения моделирования производительности, нам необходимо определить, какое количество пользователей определенного типа одновременно работает с системой. Для этого мы дополним спецификацию актеров помеченным значением "multiplicity", определяющим множественность данного элемента. Если данное значение не определено, мы будем считать, что с системой работает один пользователь данного типа.
Кроме того, необходимо указать задержку между сеансами взаимодействия пользователя с системой. Для этого мы будем использовать помеченное значение "delay", определяющее задержку между обращениями актера к варианту использования. Значением по умолчанию будем считать 0, то есть отсутствие подобной задержки.
Нам также необходимо расширить свойства ассоциации между актером и вариантом использования, отображающей факт использования пользователем определенной функции системы. Необходимо определить количество вызовов функции за один сеанс взаимодействия с системой. Для этого мы установим для ассоциации помеченное значение "multiplicity", соответствующее этому параметру. Если данное значение не определено, мы будем считать, что за один сеанс взаимодействия с системой пользователь один раз вызывает соответствующую функцию.
Следующим уровнем детализации поведения системы является последовательность действий, выполняемых в рамках конкретного варианта использования. Такую информацию можно извлечь из диаграмм последовательности. Варианту использования может соответствовать одна или несколько таких диаграмм.
На диаграммах последовательностей внимание акцентируется на временной упорядоченности сообщений [100]. Объекты,.участвующие во взаимодействии, располагаются по оси X. По оси Y размещаются сообщения, которые объекты
принимают и посылают. Фактически диаграммы последовательности соответствуют сценариям рабочей нагрузки SPE [84].
Для того чтобы иметь возможность дальнейшей детализации модели, объекты, размещенные на диаграмме последовательности, должны быть экземплярами классов, определенных на диаграмме классов. Классы являются наиболее важными строительными блоками любой объектно-ориентированной системы [100] и непосредственно формируют ее архитектуру.
Так как время выполнения методов, из которых состоят класегл, в большой степени определяет обшую производительность системы, такая информация крайне необходимо для адекватного моделирования производительности. Поскольку она не содержится в стандартной нотации UML, мы дополним свойства операции класса и интерфейса помеченным значением "executionTime", определяющим ожидаемое время выполнения соответствующего метода.
Последним шагом в формировании модели производительности с точки зрения структуры и поведения программного обеспечения является выделение компонентов, которые используются при развертывании системы. Компоненты являются связующим звеном между текущей моделью и моделью окружения системы, поскольку с одной стороны они группируют классы реализации, а с другой - привязываются к аппаратным ресурсам окружения.
Аппаратные ресурсы окружения системы изображаются на диаграмме развертывания. Каждый узел диаграммы представляет собой некоторый тип вычислительного устройства. Соединения между узлами показывают коммуникационные каналы, с помощью которых осуществляются системные взаимодействия.
Диаграмма развертывания содержит информацию о размещении компонентов, входящих в диаграмму компонентов, в узлах системы, образуя, таким образом, последнее звено цепи, начинающейся с диаграмм вариантов использования, и продолжающейся последовательно с помощью диаграмм последовательности, классов и компонентов.
Очевидно, что характеристики аппаратных ресурсов и коммуникационных каналов достаточно сильно влияют на производительность системы. Поэтому, нам необходимо расширить свойства элементов, входящих в диаграмму развертывания, добавив в них необходимые параметры.
Для каждого узла, соответствующего некоторому аппаратному ресурсу, необходимо определить помеченное значение "capacity", соответствующее ее вычислительной мощности. Вычислительную мощность мы будем рассматривать как некий коэффициент, применяемый к продолжительности операции, выполняемой на данном устройстве. Значением по умолчанию будем считать единицу, что соответствует некоей эталонной производительности аппаратного ресурса.
Кроме того, необходимо определить пропускную способность коммуникационного канала, которому соответствует ассоциация между двумя узлами диаграммы развертывания. Это предлагается сделать, дополнив свойства ассоциации помеченным значением "communicationDelay", соответствующим среднему времени, требуемому на выполнение одного удаленного вызова между соответствующими аппаратными ресурсами.
Использование формата XMI для получения исходных данных
Использование специализированного программного инструментария является одним из критериев эффективности интеграции анализа производительности в процесс разработки программного обеспечения. Поэтому нельзя говорить об успешном внедрении предлагаемой информационной технологии без использования соответствующих средств автоматизации.
В рамках информационной технологии анализа производительности в процессе разработки программного обеспечения было реализовано программное решение, позволяющее генерировать и анализировать модель производительности.
Программное решение построено по принципу многоуровневого приложения и разделено на два основных архитектурных уровня: бизнес-логики, реализующей функциональность, необходимую для подерж-ки разработанной информационной технологии; графического пользовательского интерфейса, позволяющего выполнять анализ производительности.
Выделение бизнес-логики как отдельного элемента системы позволяет интегрировать ее функциональность в другие программные приложения, такие как средства моделирования, конфигурационного управления, автоматизированной генерации кода и т.д., тем самым сокращая количество используемых при разработке разнородных программных средств и не требуя их дополнительного изучения или адаптации к ним.
Программное решение реализовано на языке Java с использованием библиотеки SWING для создания графического пользовательского интерфейса. Исходный код системьі состоит из 81 класса, общий объем кода которых превышает 5000 строк. Вклад автора диссертации в прооектирование и разработку программного средства составил 100%.
Реализованное программное решение является переносимым и может использоваться на любой программно-аппаратной платформе, поддерживаемой Java SDK 5.0: Windows х86; Windows AMD64; Linux х8б; Linux AMD64; Solaris x86; Solaris SPARC 32-bit; Solaris SPARC 64-bit;
В настоящее время существует большое количество разнообразных средств моделирования, поддерживающих нотацию UML. Среди наиболее известных можно назвать Rational XDE, Borland Together, Microsoft Visio. Каждое из этих средств обладает своими достоинствами и недостатками с точки зрения функциональности, удобства пользования, требований к программной и аппаратной среде и т.д.
При реализации программного решения, использующего в качестве исходных данных модели UML, возникает естественная проблема, вызванная необходимостью поддержки различных средств моделирования. К счастью, большинство современных продуктов поддерживают экспорт и импорт моделей в формат XMI.
XMI (XML Metadata Interchange) [96, 25] - стандарт, принятый, также как и UML, некоммерческим консорциумом OMG. XMI предназначен для обмена метаданными между средствами моделирования (базирующимися на UML) и ре-позиториями метаданных (базирующимися на стандарте Meta Objects Facility) в распределенной гетерогенной среде.
Meta Objects Facility (MOF) - это еще один стандарт, определяющий расширяемую инфраструктуру для определения моделей метаданных и обеспечивающий программные интерфейсы для сохранения и доступа к метаданным в репозитории. [63]
Таким образом, с помощью MOF определяется метамодель, аХМІ определяет каким образом можно описывать в формате XML модель, соответствующую этой метамодели.
Спецификация ХМІ включает отображение метамодели UML на метамодель MOF. Более того, наиболее распространенным способом использования ХМІ является именно обмен моделями UML.
Таким образом, для того, чтобы иметь возможность использовать модель UML в качестве исходных данных и не быть привязанным к какому-либо конкретному средству моделирования, достаточно поддерживать стандарт ХМІ.
