Содержание к диссертации
Введение
Глава 1. Мониторинг качественных характеристик программного проекта и его использование при управлении процессом разработки 17
1.1 Процесс разработки программного обеспечения 17
1.2 Задача мониторинга качества проекта на различных этапах разработки 20
1.3. Виды качественных характеристик 24
1.4 Основные методы и инструменты мониторинга качества проекта на различных этапах разработки 31
1.4.1 Методы оценки трудоемкости реализации проекта 31
1.4.2 Методы определения внутренних качественных характеристик проекта. 33
1.4.3 Инструменты обеспечения внутреннего качества 34
1.5 Постановка задачи автоматизированного мониторинга качественных характеристик ООПП 39
Результаты и выводы к первой главе 40
Глава 2. Метамодель объектно-ориентированного программного продукта 42
2.1 Элементы проекта ООПП 42
2.1.1 Язык UML 43
2.1.2 Программный код на императивных языках программирования 47
2.1.3 Исполняемые файлы 49
2.2 Проектная метамодель ООПП 50
2.3 Построение конкретной модели ООПП 53
2.3.1 Построение модели ООПП на основе диаграмм UML 53
2.3.2 Построение модели ООПП на основе программного кода 55
2.3.3 Построение модели ООПП на основе исполняемых файлов 56
2.3.4 Совместное использование элементов проекта для построения модели ООПП 57
2.4 Расчет метрических показателей проекта на основе построенной модели 59
Результаты и выводы ко второй главе 60
Глава 3. Метод определения качественных характеристик ООПП на основе метрических показателей 61
3.1 Определение качественных характеристик ООПП как задача нечеткой классификации 61
3.2. Метод определения качественных характеристик объектно-ориентированной проектной модели на основе метрических показателей 63
3.2.1 Основные положения метода определения качественных характеристик объектно-ориентированной проектной модели 63
3.2.2 Модель нечеткой нейронной продукционной сети 63
3.2.3 Структура нечеткой нейронной продукционной сети 66
3.2.4 Формирование базы правил 68
3.2.5 Обучение нечеткой продукционной нейронной сети 72
3.2.6 Паралич нечеткой продукционной нейронной сети 74
3.2.7 Общий алгоритм создания и обучения нечеткой нейросетевой модели... 75
3.3 Алгоритм определения качественных характеристик ООПП 78
Результаты и выводы к третьей главе 79
Глава 4. Определение некачественных элементов проекта ООПП и компетенций участников команды разработчиков на основе качественных характеристик 80
4.1 Автоматизация рефакторинга 80
4.2. Локализация некачественных элементов модели 82
4.3. Семейство нечетких нейронных сетей для решения задач локализации проблемных элементов проектной модели 84
4.4. Использование результатов решения задачи поиска некачественных элементов модели для построения системы поддержки принятия решений 88
4.5. Локализация проблем внутри команды 90
4.6 Способ определения компетенций персонала 91
4.7 Простой фактор влияния 93
4.8 Интегральный фактор влияния 94
4.9. Использование результатов решения задачи локализации проблем внутри
команды для построения системы поддержки принятия решений 96
Результаты и выводы к четвертой главе 96
Глава 5 Система поддержки принятия решений при разработке объектно-ориентированного программного обеспечения 98
5.1 Функциональные требования к СППР при разработке ООПП 98
5.2. Физическая архитектура СППР 101
5.3. Программное обеспечение СППР при разработке ООПП 102
5.4. Настройка, обучение и верификация СППР 104
Результаты и выводы к пятой главе 108
Основные Результаты выводы по работе 109
Литература ПО
Приложение 1. Каталог метрических показателей модели ООПП 120
Приложение 2.Свидетельство о регистрации программы для ЭВМ и акт о внедрении системы.. 129
- Задача мониторинга качества проекта на различных этапах разработки
- Проектная метамодель ООПП
- Модель нечеткой нейронной продукционной сети
- Семейство нечетких нейронных сетей для решения задач локализации проблемных элементов проектной модели
Введение к работе
Отрасль программной индустрии, связанная с разработкой программного обеспечения, на сегодняшний момент испытывает проблемы. Большие программные проекты повсеместно и постоянно выходят за рамки бюджета и установленные сроки. Основная причина этого явления — сложность, присущая программному обеспечению (ПО). Сложность ПО обуславливается четырьмя основными причинами: сложностью предметной области, трудностью управления разработкой ПО, необходимостью обеспечить гибкость программ и отсутствием удовлетворительных средств описания функционирования дискретных систем. Борьба со сложностью определяет все развитие информационных технологий (ИТ), которые сами являются чрезвычайно сложной предметной областью[48,49].
Основу программной инженерии (software engineering) составляет одна фундаментальная идея: разработка ПО является формальным процессом, который можно изучать и улучшать[9]. Базовым понятием программной инженерии является понятие жизненного цикла ПО (ЖЦ ПО). Согласно стандарту ISO/IEC 12207 структура ЖЦ ПО базируется на трех группах процессов: основных, вспомогательных и организационных^]. Из основных процессов важнейшими являются два: разработка и сопровождение. Процесс разработки обычно состоит из нескольких этапов: анализ, формулирование требований, проектирование, программирование и тестирование. Сопровождение представляет собой процесс модификации системы, целью которого является исправление выявленных при эксплуатации ошибок, улучшение эксплуатационных характеристик и развитие системы. Из вспомогательных процессов к числу важнейших относятся процесс документирования и процесс обеспечения качества ПО. Самым важным организационным процессом является процесс управления разработкой.
Долгое время основные усилия исследователей были направлены на
совершенствование процесса разработки ПО и его отдельных этапов.
Первоначально внимание было направлено на совершенствование методов и
средств программирования. В 60-е и 70-е годы было разработано множество
разнообразнейших языков программирования — они воплощали различные
парадигмы программирования: структурное, модульное, функциональное,
объектно-ориентированное, компонентное, декларативное, аспектно-
ориентированное программирование и другие. В настоящее время
превалирующей парадигмой является объектно-ориентированное
программирование[2,9,24].
Развивались и инструментальные средства разработки. Для облегчения труда программиста были созданы полезнейшие инструменты: мейкеры (maker), отладчики (debugger), профайлеры (profiler). Появление персональных компьютеров привело к революционным изменениям инструментальных средств: отдельные программы объединились в единую инструментальную среду разработки.
В 70-е и особенно в 80-е годы прошлого столетия основные усилия были направлены на разработку формализованных методов и средств проектирования ПО. Были разработаны и стандартизированы несколько графических языков, позволяющих представлять модели программ в виде различного рода схем или диаграмм. Самый известный из них — универсальный язык моделирования (Unified Modeling Language) — UML[48,49,50,51]. Этот язык ориентирован на разработку объектно-ориентированных моделей и к настоящему времени занимает доминирующее положение среди языков проектирования.
Формализация языков представления моделей позволила реализовать инструментальные системы проектирования, называемые CASE-средствами. С помощью этих систем создают документацию, управляют версиями программного продукта, проектируют структуру базы данных, автоматизируют
процесс тестирования ПО, генерируют заготовки программных модулей из моделей проекта.
Успехи в формализации и автоматизации процесса проектирования ПО в сочетании с развитием СУБД более всего способствовали превращению процесса разработки ПО в программную инженерию.
Другие исследования касались качества процесса управления разработкой ПО. Так, была предложена пятиуровневая «модель зрелости процесса разработки» (Capability Maturity Model — СММ)[20]. Были предложены и опробованы несколько моделей ЖЦ ПО. В 90-е годы прошлого века началась активная разработка стандартов в области производства программного ПО.
Таким образом, можно констатировать, что прогресс в программной инженерии очевиден. В настоящее время разработка программ превратилась в индустрию производства программ, и процесс разработки в значительной степени автоматизирован.
Однако исследования, регулярно проводимые компанией Standish Group International, показывают, что прогресс не столь велик[1]. Около 47% всех разрабатываемых программных проектов не укладываются в отведенные сроки или бюджет, а 22% вовсе отменяются из-за не рентабельности дальнейшей разработки. Кроме того, согласно данным той же компании, чем дороже разрабатываемый проект, тем меньше вероятность его успешного завершения (рис. 1.).
>$10млм. $6-10 млн. $3-6 млн. $750000- < $750 000
3млн.
Рис. 1. Данные компании Standish Group International по индустрии разработки
программного обеспечения на 2004 год.
Серьезные исследования зарубежных авторов, проводимые с начала 70х годов, свидетельствуют о том, что большинство проблем программного проекта - суммарно до 80% всех временных и финансовых потерь - возникает из-за ошибок в менеджменте и лишь 20% — по причинам технического характера. Ошибки менеджмента в свою очередь вытекают в основном из-за не правильной оценки трудозатрат во время планирования проекта и трудностей с отслеживанием качественных характеристик при его реализации [7].
Стандартным выходом при решении подобного рода проблем является привлечение внешних консультантов для анализа качества и трудозатрат по выполнению проектов [7,12]. Обычно независимые консультанты или консалтинговые компании проводят комплексное исследование одного из модулей системы и на основе полученных данных дают рекомендации по дальнейшему ведению проекта. Главным недостатком такого подхода является его дороговизна- консалтинговые услуги могут стоить до 30-40% от стоимости разработки. Кроме того, к услугам такого рода прибегают обычно уже при наличии определенных проблем в проекте.
Вопросами анализа качественных характеристик программного проекта занимались многие ученые как у нас в стране, так и за рубежом: Боем Б., Альбрехт А., Демарко Т., Майер И., Мейерс Г., Тейер Т., Липов М. Маккейб Ф., Чидембер Ш., Лоренц М., Кидд Дж., Парнас Д., Буч Г., Рамбо Дж., Джейкобсон
A. B.B. Липаев, Изосимов А.П., А.А. Саркисян, К. К. Рыжко, Кулаков В.В., Орлов С.А., Заболеева-Зотова А.В.
Работы этих авторов привели к разработке ряда методик оценки качества программных продуктов, большинство из которых используют аппарат метрических оценок. Однако сами по себе рассчитанные значения метрик ничего не говорят о качестве проекта. Для правильной интерпретации значений метрик необходимы знания и опыт экспертов, или же большая база накопленной статистической информации по сходным проектам, что позволяет оценивать качество по аналогии.
Таким образом, в настоящее время существует актуальная научная и
техническая проблема, состоящая в разработке метода, позволяющего
автоматизировать измерение и мониторинг показателей качества
программного обеспечения. Решение этой задачи позволит повысить качество проектных решений, улучшить управление проектом, и в конечном итоге, снизить затраты на производство программных продуктов.
Объектом исследования является проект объектно-ориентированного программного продукта (001Ш) как сложная система.
Предмет исследования - методы, модели и алгоритмы обработки информации и правила принятия решений при анализе качественных характеристик проекта объектно-ориентированного программного продукта.
Целью настоящей работы является повышение эффективности управленческих и проектных решений при разработке ООПП за счет автоматизированного мониторинга качественных характеристик проекта.
Поставленная цель достигается решением следующих задач: 1. Провести системный анализ процесса разработки ООПП, определить
ограничения и сформулировать задачу определения показателей качества
элементов проекта.
Разработать обобщенную метамодель проекта ООПП и ее качественные характеристики, определить характер их связи с основными объектно-ориентированными метриками.
Разработать способы автоматической генерации модели проекта ООПП на различных этапах процесса разработки.
Разработать метод опрделения качественных характеристик проекта ООПП.
Исследовать эффективность применения метода определения качественных характеристик ООПП для автоматизации рефакторинга и определения компетенций разработчиков.
Спроектировать и реализовать систему поддержки принятия решений процесса разработки ООПП.
Методы исследования. Для решения поставленной задачи применялись методы системного анализа, искусственного интеллекта, математический аппарат нейронных сетей и нечетких множеств.
Научная новизна состоит в следующем:
Разработана обобщенная метамодель проекта ООПП, построенная на принципах семантического единообразия данных, полученных при анализе UML-моделей, программного кода и исполняемых модулей, позволяющая вычислять метрические показатели на различных этапах разработки.
Предложен метод определения качественных характеристик элементов проекта ООПП на основе аппарата нечетких нейронных сетей Ванга-Менделя.
Разработан способ определения признаков некачественных элементов ООПП, позволяющий автоматизировать выбор способов рефакторинга для элементов проекта.
4. Предложен способ определения текущего уровня компетенций разработчиков ООПП на основе анализа их влияния на качественные характеристики проекта, что упростит управление персоналом. Практическая ценность работы:
Разработано программное обеспечение системы поддержки принятия решений (СППР) процесса разработки ООПП, реализующее мониторинг качественных характеристик проектной модели ООПП.
Использование разработанной СППР позволило повысить эффективность разработки программного обеспечения и снизить затраты на создание программных модулей автоматизированной системы управления вузом (АСУ ВУЗ).
Предложенная модель и принцип построения СППР используются в учебном процессе вуза при преподавании дисциплин, связанных с изучением технологий программирования и проектирования программного обеспечения.
Личный вклад автора.
В работах, выполненных в соавторстве, автору принадлежат формализация задачи, построение математической модели и методов, разработка алгоритмов, проектирование и реализация программного обеспечения.
Апробация научных результатов. Основные положения докладывались и обсуждались на всероссийской научно-практической конференции IT-инновации в образовании, международной научной конференции Математические методы в технике и технологиях - ММТТ-18 и ММТТ-20, 51-ой научно-практической конференции профессорско-преподавательского состава Астраханского государственного технического университета», международной научно-практической конференция «Информационные технологии в образовании, науке и производстве», международной научно-
практической конференции «Эволюция системы научных коммуникаций Ассоциации университетов Прикаспийских государств».
Публикации. Основные положения диссертационной работы отражены в 13 опубликованных научных работах, среди которых 2 статьи в журналах рекомендованных ВАК, 1 свидетельство о регистрации программы для ЭВМ и 10 публикаций в сборниках международных научных конференций.
Структура и объем работы. Диссертационная работа состоит из введения, пяти глав основного текста, заключения, списка литературы из 105 наименований и 2 приложений. Общий объем работы 131 страниц машинописного текста, который включает 21 рисунков, 12 таблиц и 30 формул.
Во введении отражена актуальность работы, сформулирована цель, определена научная новизна и практическая значимость результатов данной работы, приведено краткое содержание работы.
Первая глава посвящена литературному обзору и анализу предметной области управления разработкой объектно-ориентированного программного обеспечения. Приводится основные определения, применяемые в управлении разработкой программных проектов, рассматриваются основные виды деятельности осуществляемые в процессе разработки ПО. Подробно рассматриваются виды деятельности направленные на обеспечение качества программного продукта. Выявлены объекты анализа качества на различных этапах жизненного цикла ПО. Среди основных методов анализа качественных характеристик проектных моделей определены две группы: анализ метрических показателей и анализ взаимных зависимостей составляющих проектов.
Для решения задачи определения качественных характеристик требуется определить набор основных показателей качества программной системы. В первой главе диссертации на основе литературного обзора выделены пять основных внутренних качественных характеристик элементов проекта объектно-ориентированного программного обеспечения: сложность реализации (complexity), сложность модернизации (volatily), сложность сопровождения
(maintenance), подверженность ошибкам (weakness), возможность повторного использования (recycling). Перечисленные характеристики не могут быть выражены численно, а определяются как лингвистические переменные. Термы для соответствующих лингвистических переменных также определены в первой главе.
Во второй главе произведен анализ основных элементов проекта, создаваемых на разных этапах разработки, к которым относятся UML-диаграммы, код на императивных языках высокого уровня, исполняемые бинарные файлы. Для унификации процесса определения качественных характеристик было предложено перейти к обобщенной модели элементов проекта.
На основе проведенного семантического анализа основных элементов проекта были выявлены сущности и связи между ними, установлены соответствия между понятиями в различных элементах проекта и построена единая метамодель элементов проекта. Во второй главе диссертации установлены соответствия между понятиями, применяемыми в UML и в языках программирования, и понятиями проектной метамодели. Кроме того, разработаны способы построения конкретной проектной модели программного продукта на основе диаграмм UML, представленных в формате XMI, на основе исходного кода на императивных объектно-ориентированных языках программирования и на основе скомпилированных исполняемых файлов с использованием механизмов рефлексии и декомпиляции.
В третьей главе предлагается метод опрделения внутренних качественных характеристик объектно-ориентированного программного продукта (ООПП) на основе метрических показателей вычисленных с использованием обобщенной модели проекта.
Задача определения качественных характеристик состоит в отнесении исследуемого программного продукта к одному из определенных для данной характеристики классов. Поскольку характеристики выражаются
лингвистически, для формализации задачи предлагается применить аппарат нечеткой логики, задача определения качественных характеристик системы разделяется на две подзадачи: вычисление метрических показателей семантического графа модели системы и нечеткую классификацию системы по выбранным характеристикам на основе вычисленных метрических показателей.
Первая задача решена в рамках второй главы данной диссертации. Вторая задача может быть решена с использованием нечетких нейронных сетей. В качестве конкретной реализации нечеткой нейросетевой модели предлагается использовать нечеткую нейронную сеть Ванга-Менделя. В третьей главе описаны принципы построения, функционирования, проектирования и настройки нейросетевой модели.
В четвертой главе рассматриваются способы определения некачественных элементов проекта ООі Ш и определения компетенций команды разработчиков на основе вычисленных качественных характеристик.
В процессе разработки и модификации сложных программных систем часто возникает необходимость пересмотра и перепроектирования части программного продукта без изменения функциональности с целью улучшения внутренних качественных характеристик, что упрощает дальнейшее расширение и сопровождение приложения. Такой процесс называется рефакторингом. Автоматизация процессов рефакторинга - очень актуальная задача. Одной из первых и наиболее важных задач решаемых при рефакторинге является локализация некачественных элементов в проекте. Используя выводы, полученные в предыдущих главах, можно предложить подход к решению задачи локализации проблемных элементов проектной модели.
Основываясь на методе определения качественных характеристик, предложенном в третьей главе, разработана методика определения компетенций членов команды разработчиков. Оценивать компетенции персонала предлагается на основе оценки изменений в проекте, которые совершает каждый участник команды разработки.
В пятой главе описаны основные аспекты реализации и настройки базы знаний СППР. СППР при разработке объектно-ориентированного программного обеспечения предназначена для мониторинга качественных характеристик и выявления проблемных элементов в проекте объектно-ориентированной программной системы, а также для определения компетенций разработчиков, и может применяться в процессе разработки программного обеспечения и в качестве обучающей системы при преподавании дисциплин ориентированных на изучение технологий программирования и проектирования информационных систем.
При проектировании СППР были разработаны прецедентная, функциональная и инфо логическая модели системы. При разработке архитектуры автоматизированной системы использовался принцип открытой архитектуры. СППР представляет собой комплекс программных модулей интегрирующихся со средой Microsoft Visual . При необходимости возможно расширение и интеграция с другими средами и языками программирования.
Настройка базы знаний системы производилась с использованием обучающей выборки с метриками, автоматически рассчитанными по 200 реальным проектам, среди которых были: ряд разработок отдела АСУ АГТУ, работы созданные студентами АГТУ в процессе курсового и дипломного проектирования, свободные программные продукты с открытым исходным кодом. Каждый проект был оценен экспертами (сотрудниками отдела АСУ и преподавателями кафедры АСОИУ) по пяти предложенным параметрам качества. Итоговая ошибка обучения составила 5%.
Проверка достижения цели диссертационной работы, а именно — повышение эффективности, снижение затрат на разработку программного обеспечения была выполнена путем сопоставления результатов оценки качественных характеристик системой и экспертами на контрольной выборке, а также опытной эксплуатацией системы в отделе АСУ АГТУ. Контрольная
выборка составлялась по тем же принципам, что и обучающая, на основе 50 проектов. Проверка однородности выборок производилась с использованием критерия Бартлетта. Ошибка обобщения построенной нечеткой нейронной сети составила 27,5 %
Использование разработанной автоматизированной СППР позволило повысить эффективность разработки программного обеспечения и снизить затраты на создание программных модулей АСУ ВУЗ АГТУ в среднем на 30%. Предложенная СППР также используются в учебном процессе вуза при преподавании дисциплин «Анализ комбинаторных алгоритмов», «Технология программирования», «.NET программирование».
В приложениях приведены каталог объектно-ориентированных метрик использовавшихся для проектирования СППР; свидетельства о государственной регистрации программ для ЭВМ; акты о внедрении результатов научной работы.
Задача мониторинга качества проекта на различных этапах разработки
Процесс разработки программного обеспечения ставит своей целью получение качественного программного продукта, решающего поставленные вычислительные задачи с помощью набора математических методов. Процесс определяет последовательность разработки, систему принципов разработки, а также стандарты разработки [9, 61]. Кроме процесса, основными понятиями, связанными с разработкой ПО, являются продукт, проект и персонал [24].
Продукт - это набор результатов проектирования, включающий спецификацию требований к программному обеспечению, проектную модель, исходный и объектный код, а также тестовые процедуры. Проект - это совокупность действий, необходимых для создания того или иного результата проектирования. Проект включает: написание документации, построение проектной модели, написание кода и тестирование продукта. Персонал - это совокупность людских ресурсов и их взаимоотношений, так или иначе влияющих на процесс разработки программного обеспечения. Помимо программистов, проектировщиков, аналитиков и менеджеров к персоналу также относятся заказчики, пользователи и инвесторы. Взаимосвязь между проектом, продуктом, процессом и персоналом можно продемонстрировать, используя рисунок 1.1 [46]. Процесс разработки ПО Цель любого программного проекта состоит в производстве продукта, наиболее полно удовлетворяющего предъявляемым требованиям, на основе знаний о предметной области задачи и совокупности логико-математических методов[9,13,24]. То, как в рамках проекта производится продукт, определяет процесс. Персонал включается в рассмотрение, поскольку взаимоотношения внутри группы разработчиков являются критически важным фактором для успеха разработки. На протекание процесса влияют требования, предъявляемые к программному продукту, проекту, персоналу, а также требования к самому процессу разработки[24]. Требования к продукту разделяют на функциональные, относящиеся к функциональным характеристикам продукта, и нефункциональные, относящиеся к качественным характеристикам продукта[71]. Качество продукта, в этом случае, напрямую зависит от управляющего воздействия требований к продукту, проекту, процессу и персоналу. При изменении функциональных требований к разрабатываемой системе, качество продукта может снизиться, поскольку процесс или проект не будут в достаточной мере гибки для оперативной реакции на эти изменения. С другой стороны изменения в функциональных и нефункциональных требованиях (например, отказ от части изначально запланированной функциональности, переход на другую платформу) могут и ускорить выпуск продукта[24, 70].
Наиболее активно используются для управления процессом разработки требования к процессу и проекту. Например, упростив процедуру документирования или введя определенный стандарт оформления кода, можно достичь повышения качества продукта и увеличения гибкости проекта. Изменив стиль работы разработчиков, например, перейдя к парному программированию, можно также достичь повышения производительности труда и улучшения качества программного продукта[3, 4].
Для оптимизации управления процессом разработки следует использовать обратную связь. Проанализировав качество получившегося продукта можно сделать коррективы в требованиях к процессу, проекту и персоналу. Кроме того, используя ту же обратную связь, можно выявить дополнительные потребности пользователей, уточнить возможности команды разработчиков и изменить требования к продукту при разработке следующих его версий.
Обратную связь можно задействовать только при наличии уже разработанной, возможно не полностью, версии программного продукта. Именно поэтому для достижения наибольшей гибкости процесса разработки, выпуск версий должен производиться регулярно и как можно чаще [3, 4, 9, 71].
Необязательно производить регулирование требований к проекту, процессу и персоналу «с нуля» для каждой отдельной разработки. Процесс разработки может быть инвариантен по отношению к очень широкому кругу задач, поскольку зависит в большей степени от команды разработчиков [24]. Проект в отличие от процесса может давать хорошие или плохие результаты в зависимости от вида решаемой задачи.
Таким образом, анализ качества играет ключевую роль в управлении процессом разработки в целом и в создании качественного программного продукта в частности. Однако анализ качества программного продукта - задача сложно формализуемая.
Проектная метамодель ООПП
На основе проведенного семантического анализа основных элементов проекта были выявлены обобщенные сущности для различных элементов проекта и связи между ними [80]. Установлены соответствия между понятиями в различных элементах и построена единая проектная метамодель. Сущности метамодели и связи между ними в нотации диаграммы классов языка UML 2.0 показаны на рис. 2.1.
Главным семантическим понятием метамодели является программное решение (solution), которое может состоять из одного или большего числа программных проектов (project). В рамках предлагаемой метамодели будем считать, что проект после компиляции и сборки будет представлять собой единый исполняемый файл (единую сборку в терминологии платформы NET или единый пакетный файл в терминологии Java) и некоторое количество файлов ресурсов.
Все объекты внутри проектов разделены по различным пространствам имен (namespace), причем одно и тоже пространство имен может реализовываться несколькими проектами и один проект может реализовывать несколько пространств имен.
Типы данных (datatype) являются основными понятиями, включающимися непосредственно в пространство имен. Типы данных однозначно идентифицируются по составному имени, состоящему из имени пространства имен, включающему тип и собственного имени типа.
Типы данных можно разделить на две категории: атомарные (atom) и составные (complex). К атомарным типам следует отнести все типы данных, которые сводятся к типам непосредственно обрабатываемым ЭВМ, а также дополнительные включенные в большинство стандартов языков высокого уровня — строки (string), массивы (array) и перечисления (enum). К составным типам относятся классы и структуры. Дополнительной характеристикой составных типов является видимость (visibility). По видимости типы могут быть публичными (и в этом случае могут использоваться вне проекта, в котором определены) и внутренними. Классы отличаются от структур способом хранения в памяти и передачи. Классы являются ссылочными типами и хранятся в области памяти, называемой кучей, структуры - типами, передаваемыми по значению и хранящимися в стеке управляющего потока. Составные типы данных могут включать в себя определения других составных типов. В этом случае включенные типы называются вложенными (nested). Кроме того, типы данных могут принимать другие типы данных в виде параметров для поддержки генеративного программирования. Составные типы данных включаются в себя набор элементов данных (data member) и набор функций-членов (function member). Любой элемент данных идентифицируется именем и ограничивается типом данных. Элементы данных бывают двух основных видов: поля и свойства. Свойства имеют более интеллектуальное поведение и включают в себя одну или две функции-члена для установки и получения значения свойства (getter и setter). Функции-члены описывают операции допустимые для типа данных. В рамках метамодели определены следующие виды функций-членов: Конструкторы (constructor) — вызываются при создании экземпляров типов; Деструкторы (destructor) - вызывается при уничтожении экземпляров типов; Метод (method) - вызывается при необходимости из кода других функций-членов. Для функций-членов указывается тип возвращаемых данных, имя, флаг виртуальности, атрибуты видимости, а также список параметров (parameter), которые определяются именем и типом данных. Функция-член в предлагаемой метамодели представлена множествами операторов (operator) и объявлений локальных переменных (declaration), выступающих в качестве параметров операторов. Наиболее важными операторами, имеющими значение для анализа качества проекта ООГШ, являются следующие: Вызов метода (call) - вызов функции-члена. Можно различать внешние (вызов метода другого типа данных) и внутренние вызовы методов; Доступ к данным (data access) - получение или установка значения переменных, параметров, элементов данных; Операторные скобки (operator braces) — организация составного оператора; Циклы (cycle) — повторяет выполнение оператора, пока выполняется некоторое условие; Ветвления (condition) — выполняет только в случае, если истинно некоторое условие. 2.3 Построение конкретной модели ООПП Конкретную модель на основе предлагаемой метамодели можно строить на основе любых из трех вышеперечисленных типов элементов проекта [39]. 2.3.1 Построение модели ООПП на основе диаграмм UML Диаграммы UML выгодно отличает от других элементов проекта то, что они могут создаваться даже на самых ранних этапах разработки, и поэтому вовремя проанализировав их можно сократить затраты на реализацию неэффективных проектных решений, заранее отбраковав их. Построение модели ООПП на основе диаграмм UML должно производиться в два этапа (см. рис. 2.2). На первом этапе анализируются статические UML модели - диаграммы компонентов, пакетов и классов. При этом определяются элементы, соответствующие понятиям метамодели «проект», «пространство имен», «тип данных», «элемент данных», «функция-член».
Модель нечеткой нейронной продукционной сети
На основе представленного выше выражения строится четырехслойная нейросетевая структура без обратных связей и с пятью типами нейронов. Схематическое изображение нейронной сети показано на рис. 3. Слой 1 выполняет фаззификацию входных переменных. Элементы этого слоя принимают на вход четкие значения переменных и вычисляют значения функций принадлежности /иА.(х), заданных гауссовыми функциями принадлежности с параметрами atj и Ьу. Количество нейронов этого типа в сети соответствует сумме количества термов входных параметров модели. В слое 2, число элементов которого равно количеству правил в базе, осуществляется агрегирование степеней истинности предпосылок соответствующих правил. На вход каждого нейрона этого слоя поступает несколько значений вычисленных для входных переменных значений функций принадлежности. На выходе нейрона получается значение равное произведению входных значений. В слое 3 присутствуют всего два нейрона, на входы каждого из которых подаются все значения, вычисленные на предыдущем слое. Первый служит для активизации заключений правил в соответствии со значениями агрегированных степеней истинности предпосылок правил. Для этого слой умножает каждое из значений входа на соответствующий вес с, и суммирует результаты умножения. Второй элемент слоя проводит вспомогательные вычисления для последующей дефаззификации результата, он суммирует входные данные из предыдущего слоя. Слой 4, состоящий из одного элемента, выполняет дефаззификацию выходной переменной методом среднего центра. По сути, он просто делит одно первое из входных значений на второе. Параметрическими слоями сети являются первый и третий слои, а настраиваемыми параметрами служат, соответственно, параметры термов посылок и заключений ау, Ь0. и с, База правил для предлагаемой нечеткой нейросетевой модели строится на основе эвристической информации, получаемой от экспертов [38]. На первом этапе построения определяются входные метрические показатели, используемые для анализа качества ООПП. Затем производится разбиение пространств входных и выходных переменных. Для каждой входной и выходной переменной должны быть определены максимальные и минимальные значения, ограничивающие область допустимых значений. Для метрических показателей максимальные . и минимальные значения определяются, исходя из типа метрики: значения размерно-независимых метрик обычно лежат в диапазоне [0;1], для размерно-зависимых метрик определяют предполагаемое максимальное значение метрики. Для выходных качественных характеристик опорным множеством значений выбирается диапазон [0;1]. В области определения входных переменных экспертами выбираются точки, соответствующие максимальной степени уверенности для каждого из определенных для метрики термов. При этом может потребоваться ввести процедуру согласования экспертных оценок.
Семейство нечетких нейронных сетей для решения задач локализации проблемных элементов проектной модели
Диаграмма вариантов использования С1111Р Администратору доступны функции «Регистрация пользователей» и «Настройка ролей и прав доступа». Система должна обеспечивать сквозную авторизацию пользователей для работы с различными сервисами инфраструктуры разработки, включая управление версиями исходного кода, доступом к системе регистрации требований, системе постоянной интеграции и т.д. Администратор регистрирует данные пользователей и назначает им соответствующие права или задает им права предопределенной роли.
Программисту доступны функции предоставляемые сервисами постоянной интеграции и контроля версий. Он также может пользоваться базой метрик собираемых на основе автоматически строящейся проектной модели и запускать процедуру определения качественных характеристик, осуществляемую по алгоритму, описанному в третьей главе. Опрделение качественных характеристик может расширяться дополнительной функциональностью предоставляемой советующей подсистемой локализации проблемных элементов модели. Данный сервис доступен программисту как из web-интерфейса, так и из среды разработки.
Менеджер также использует функции оценки текущего состояния проекта и информацию советующей подсистемы автоматизации рефакторинга. Однако особое внимание для этой роли уделяется функциям управления персоналом. Прежде всего, менеджеру доступны функции настройки правил по управлению персоналом, структура которых описана в четвертой главе, и первоначальной настройки уровня компетенций участников команды. Данные по начальному уровню компетенций участников команды могут быть получены менеджером из результатов тестирования при приеме программиста на работу.
Кроме того менеджер может просматривать данные по результатам деятельности отдельных разработчиков, и просматривать вычисленные с использованием выводов четвертой главы факторы влияния на проект и текущие значения компетенций. Также менеджер может прибегать к помощи советующей подсистемы по управлению персоналом, которая работает на основе правил внесенных при настройке системы.
Эксперту доступны функции внесения данных по обучающей и контрольной выборке. При этом эксперт может воспользоваться встроенными в систему функциями по вычислению метрических показателей на основе анализа проектных элементов и построения проектной модели.
Эксперт также может запустить автоматический алгоритм генерации базы правил и обучения нейронной сети, описанный в третьей главе. Также возможна ручная корректировка правил экспертом. Однако после ручной корректировки обязательно должен быть запущен алгоритм переобучения нейронной сети Ванга-Менделя.
Для верификации настройки нейронной сети эксперту доступна для просмотра информация о результатах вычислений на контрольной выборке.
. Диаграмма развертывания СППР Основная часть системы расположена на web-сервере реализующем функции управления сервисами, сбора данных и вывода информации. Также на web-сервере располагаются советующие подсистемы, выполненные в виде Web 2.0 приложений. В текущей реализации системы в качестве средства реализации web-приложения выбрана технология ASP.NET MVC [95] с использованием библиотек NHibernate, jQuery и языка программирования С#. Поэтому в качестве платформы web- сервера используется Internet Information Services встроенный в операционную систему Windows 2003/ 2008.
Серверной постоянной интеграции (CI) развернут на основе бесплатного программного продукта CraiseControl.NET позволяющего осуществлять удаленную сборку проекта по требованию и расписанию, автоматическое модульное тестирование. Также он позволяет подключать дополнительные подключаемые модули, реализующие дополнительную функциональность. Таким способом реализован сервис анализа элементов проекта, который при сборке проекта автоматически- строит проектную модель одним из способов описанных во второй главе, и сохраняет ее в базу данных (MS SQL Server 2005).
Для постоянного хранения различных версий элементов проекта и обеспечения возможности обратной связи элементов с построенной проектной моделью используется система контроля версий Subversion.
Для использования системы на клиентских машинах должен быть установлен любой web-браузер поддерживающий современные стандарты HTML и JavaScript, а также клиентская часть системы контроля версий. Для программистов также предусмотрена реализация подключаемых модулей к используемой интегрированной среде разработке. В настоящее время разработан модуль для Microsoft Visual Studio 2005/2008.
