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

Игнацкая Ирина Владимировна ' г

МЕТОДОЛОГИЯ МОДЕЛИРОВАНИЯ НА ОСНОВЕ ГРАФА ВЗАИМОДЕЙСТВИЯ ПРИ СОПРОВОЖДЕНИИ ПРОГРАММНОЙ

СИСТЕМЫ

Специальность: 05.13.11 Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата физико-математических наук

Москва - 2010

1 б ДЕК 2010

004617489

Работа выполнена на кафедре вычислительной математики и программирования Московского авиационного института (государственного технического университета).

Научный руководитель:

кандидат физико-математических наук, доцент,

Лукин Владимир Николаевич

Официальные оппоненты:

доктор физико-математических наук, профессор,

Исаев Вячеслав Костантинович

доктор технических наук, профессор, Макаров-Землянский Николай Викулович

Ведущая организация: Институт системного программирования

Российской Академии Наук

Защита состоится чАмин. на заседании диссертационного

совета Д 212.125.04 Московского авиационного института (государственного технического университета) по адресу: 125993, г. Москва, А-80, ГСП-3, Волоколамское шоссе, д.4, Ученый совет МАИ.

С диссертацией можно ознакомиться в научной библиотеке Московского авиационного института (государственного технического университета).

Автореферат разослан <Д^» _ KfilÚfA 2010 г.

Ученый секретарь

диссертационного совета Д 212.125.04, кандидат физико-математических наук, доцент

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

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

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

Для достижения цели были поставлены и решены следующие задачи:

• провести анализ нотаций моделирования и области их применения;

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

• разработать аналитический аппарат для моделей на основе графа взаимодействия;

• обеспечить хранение и реализацию алгоритмов анализа модели на основе графа взаимодействий и связанной с ней дополнительной информации, в том числе документации и сведений для конфигурационного управления;

• определить порядок работы с моделью на этапе сопровождения.

Метод исследования. Для обоснования свойств предложенного принципа

моделирования используется системный анализ, методь! на основе теории графов, теории множеств и отношений.

Научная новизна работы состоит в следующем:

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

представить программную систему и снижает сложность настройки нотации представления.

• Для графа взаимодействий разработан аналитический аппарат с учетом его адаптивности к нотации.

• Предложена методология применения моделей для сопровождения системы на основе графа взаимодействий.

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

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

Апробация работы. Основные результаты диссертационной работы докладывались и обсуждались на 4-й, 5-й и 6-й Всероссийской конференции студентов, аспирантов и молодых учёных «Технологии Microsoft в теории и практике программирования» (Москва, 2007, 2008, 2009), на XV и XVI международной студенческой школе-семинаре "Новые информационные технологии" (Судак 2007, 2008), на XVI международной конференции по вычислительной механике и современным прикладным программным системам (ВМСППС'2009) (Алушта, 2009) и на VIII Международной конференции по неравновесным процессам в соплах и струях (NPN.T201Q) (Алушта, 2010), на научном семинаре Института Системного Программирования РАН (05.09.2010), на научном семинаре Института прикладной математики им. М.В.Келдыша (16.11.2010).

Публикации. Результаты работы опубликованы в девяти печатных работах [1-10], в том числе три работы [1,3] в изданиях, входящих в перечень ВАК.

Структура и объем работы. Диссертационная работа состоит из введения, трех глав, заключения и двух приложений. Общий объем работы -145 страниц. Список литературы включает 56 наименований.

ОСНОВНОЕ СОДЕРЖАНИЕ РАБОТЫ

В диссертационной работе рассматривается три научных направления: сопровождение программного обеспечения, моделирование программных систем, CASE-технологии и технологические аспекты создания прикладных программ. Все они тесно связаны между собой. Наибольший интерес представляет проблема сопровождения программного обеспечения, так как именно эта область достаточно мало изучена и отражена в научных работах. Проблемой сопровождения занимались Гласс Р., Нуазо Р., Купер А., Физерз М„ Фаулер М., Кериевски Д., Эрлих JL, Терехов А.Н. и другие.

Вопросы моделирования программных систем исследуются уже более полувека, однако эта область динамично развивается и находит все большее практическое применение. В различное время данное научное направление исследовалось в работах таких ученых, как Котов В.Е., Сабельфельд В.К., Ершов А.П., Марков А. А., Евстигнеев В.А., Питерсон Д., Ульман Дж., Хоар Кнут Д., Росс Д., Де Марко Т., Йодан Э., Гэйн К., Сарсон Т., Баркер Р., Чен П., Дейт К., Кодд Э., Буч Г., Рамбо Д., Джекобсон А., Селик Б, Меллор Д., Кларк А., Браун А., Футагами Т., Маклаков C.B., Кузнецов М.Б., Калянов Г.Н., Черемных C.B., Семенов И.О., Ручкин B.C. и другие.

Вопросы создания программного обеспечения и CASE-технологий стали изучаться на несколько десятилетий позже. Это направление в частности занимается использованием разработанных моделей и затрагивает сопровождение как часть жизненного цикла программного обеспечения. Этой тематике посвящены работы Брукса Ф., Гласса Р., Купера А., Фуксмана A.JL, Фаулера М., Йодана Э., Буча Г., Рамбо Д., Джекобсона А., Макгрегора Д., Эрлиха JL, Терехова А.Н., Вендрова A.M., Калянова Г.Н., Горбунова-Посадова М.М., Липаева В.В., Колдовского В., Новичкова А.Н., Лапыгина Д.В. и других.

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

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

Анализ выявил следующее:

• Моделирование редко используется при сопровождении программного обеспечения. Нотации представления программных систем ориентируются на другие задачи и этапы жизненного цикла.

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

• Усложнение анализа моделей, построенных по неформальным нотациям ограничивает применение моделей при сопровождении.

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

• Развитие инструментов и технологий разработки программного обеспечения приводит к устареванию нотаций моделирования. Со временем

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

• Формализация модели в сочетании с механизмами расширения нотации может снять эти проблемы. Однако для современных нотаций возможности расширения и настройки представления либо отсутствуют, либо ограничены. Требуется, чтобы новая терминология, которую вводит пользователь, брала за основу базовую терминологию нотации. Внутренняя организация расширяемых подходов достаточно сложна и склонна к разрастанию. Групповая обработка элементов модели (выборки, переклассификация, контроль взаимодействий) требует владения специальной терминологией и инструментами. Примером может служить метамодель UML - Unified Modeling Language. На практике трудоемкость настройки представления приводит к том)-, что из-за нехватки времени пользователи не решаются расширять и без того сложную терминологию, а при анализе отдают предпочтение анализу исходных текстов.

• При повторном использовании моделей нотация не принципиальна. Многие алгоритмы анализа, используемые при сопровождении, можно обобщить на различные нотации. За основу, как правило, берут UML. Так, на примере UML описываются алгоритмы анализа и архитектурные шаблоны. Технологии Model Driven Architecture (MDA) и Model Driven Development (MDD) основаны на UML. Однако вместо UML можно взять любую достаточно выразительную нотацию.

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

Во второй главе приведено конструктивное определение графа взаимодействий. Граф взаимодействий - размеченный ориентированный граф <V, R>, где V - множество вершин, a R - множество дуг. Для того, чтобы провести соответствие между моделью и программной системой и согласовать вносимые изменения, множество вершин делится на две части:

V=EuF (1),

где Е - множество составляющих архитектуры программы, содержащее как абстрактные элементы так и элементы, близкие к структурным языковым конструкциям, a F - множество файлов, в которых содержатся исходные тексты программы. Масштаб элементов множества Е не ограничивается. К этому множеству можно отнести как функциональные модули, так и параметры функций.

На каждой части множества вершин вводится разбиение:

г ф

Е , Р = и^ >ГДе Ф и е - количество групп в группировке. (2)

Г.1 /=1

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

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

ЬЫ^иКзиКз, где К\={р:арЬ,а,Ье Е), К2={р:арЬ,а,Ье Р), Кз=1р: арЬ, а е Л Ь е Е]. (3)

Ориентация дуг в графе взаимодействий введена, чтобы определить смысловые роли в отношениях из множества ^иКх Например, в отношении «наследование между классами» дуги ориентированы в направлении от вершины-наследника к вершине-потомку. Для отношений между файлами и элементами внутренней структуры ориентация несущественна. Для определенности будем считать, что отношения между файлами и элементами внутренней структуры задаются как дуги от вершин множества Б к вершинам множества Е, дуги от элементов внутренней структуры к файлам отсутствуют.

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

XI К2 КЗ

Я] Д2 = и и Я3 = У я;з, где К1, К2, КЗ - количество групп в

¿1=1 ¿2=1 ¿3=1

группировках. (4)

В качестве примера видов связей из Я] можно привести отношения типа «процедура-параметр», «функция-результат», «переменная-тип». К группам второго вида можно отнести отношения между файлами: «предыдущая версия - следующая версия» или «включение» (один файл подставляется в другой при компиляции). Простейший пример типов связей третьего вида -«содержание описания» (файл содержит описание компоненты) и «содержание реализации» (файл содержит реализацию компоненты). Фактически группы й', представляют способы взаимодействия между элементами внутренней структуры программы, К;, - отношения между файлами, а ({¡} - особенности файловой организации. Пустые группы вершин и дуг из модели исключаются.

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

бессмысленны для других. Тогда каждому типу элементов внутренней структуры Ее ставится в соответствие множество I, допустимых типов связи:

Lr = { R'n,R'r...R'IL, RlLtVR',L+2...R,,L+,, > }■ (5)

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

Таким образом, процесс моделирования программной системы состоит из трех шагов:

1. Задается типизацию узлов и связей.

2. Группы заполняются фактическими составляющими программного комплекса.

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

Граф взаимодействий может выразить практически любую современную нотацию представления программной системы, включая нотации семейства IDEF (Integrated Computer Automated Manufacturing Definition), DFD (Data Flow Diagrams) нотации и нотации, входящие в UML. Для этого надо задать классификацию дуг и вершин, соответствующую терминологии представления.

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

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

Анализ графа взаимодействий позволяет решать задачи проверки корректности модели, проведения рефакторинга и оптимизации

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

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

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

* к к

для каждой группы: Б = а/,(е) + Ь^(Ф) + с/ъ(К1,К,,К3) + с1/11(—-,—,—1). (6)

2е ф 2 ф

Коэффициенты а,Ь,с,ё, а также эвристики оценки сложности Л, /2 ^ /3, /4 задаются в зависимости от представления и шкалы оценки. Параметры функций описаны в формулах 2, 3, 4 и 5.

Аналогичная оценка предложена для сложности самой системы:

е / к к к

Коэффициенты а,Ь,с1,с2,с3 определяются представлением и принятой шкалой, а функции /,',//, е,/Д е N - эвристики оценки сложности.

Аналогичные методики оценки применимы при анализе корректности, как модели, так и архитектуры программной системы. Для анализа вводится эвристическая функция, по значениям которой ведется шкала:

К = К(1£, ЦЕ2 <,...,1Ее ЦГ, 1,...!^ 1,1 Л,1 /... Ш2К1I...IЯ*г 0.(8)

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

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

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

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

• выявить изолированные, неиспользуемые и перегруженные части системы;

• выявить места в системе, требующие введения дополнительных уровней абстракции;

• отыскать все обращения к заданной компоненте;

• выявить типы дуг в классификации, которые не являются самостоятельными. Для этого исследуется кратные дуги.

В работе доказано, что, если отношение:

, где £>;=1{ p-.pt Я^арЬЗр, й Я),ар,Ь }|, (9)

\к1\

близко к единице, то это означает, что тип взаимодействия не самостоятельный. Аналогично, если величина:

где д; =\{р:ре КгарЬ,Ър„Ьр,а }1, (10)

/

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

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

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

• система описана в нескольких представлениях и среди них есть как минимум два никак не согласованных между собой

• выбранное представление не позволяет показать некоторые виды взаимодействия между некоторыми компонентами программной системы.

Исследование связности также позволяет вывести ограничение на количество дуг в разрезе типизации в зависимости от количества вершин.

В процессе сопровождения возникают сложные поисковые запросы. Граф взаимодействий позволяет формализовать критерии поиска в виде шаблона.

Шаблон представляет собой слабо связный граф, вершины и дуги которого классифицируются и подчиняются тем же ограничениям, что и вершины и дуги графа взаимодействий. Кроме того, к классификации дуг и вершин шаблона добавляется неопределенный тип для дуги и для вершины. Ограничения на использование этих типов нет. Шаблон представляет собой искомую комбинацию вершин и дуг графа взаимодействий. Классификация позволяет формализовать критерий соответствия подграфа шаблону: шаблон Т = [Т\',Т1<\ соответствует подграфу § = тогда и только тогда,

когда найдутся два отображения: г]У: ТУ gV для вершин и : ТК для дуг. Отображения должны быть инъективны, определены для всех составляющих шаблона и сохранять группу классификации. Неопределенный тип может соответствовать любому типу. В диссертации приводится алгоритм отыскания соответствия для шаблона в графе, который основывается на поиске в глубину подграфа, для которого существует такое отображение. Наличие классификации позволяет оптимизировать этот алгоритм по сравнению с обычными алгоритмами поиска подграфа в графе. Использование шаблонов эффективно при поиске дублирующегося кода, при оптимизации и структуризации системы, при поиске компонент системы для повторного использования, типовых решений и типичных ошибок. Шаблоны для графа взаимодействий можно применять как шаблоны рефакторинга.

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

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

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

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

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

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

В заключении ко второй главе отмечаются следующие достоинства предложенного подхода:

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

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

• простота. Представление в виде графа с типизацией вершин и принципы его расширения интуитивно понятны, не требуют

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

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

В третьей главе описывается использование данной модели при сопровождении. Приводится схема хранения модели с учетом ее адаптивности. Предлагается организовать граф взаимодействий на основе списков вершин и дуг. Все элементы графа (вершины и дуги) единообразно хранятся в репозитории (objects) со ссылкой на детальную информацию (id_global, id_workspace). Для удобства работы репозиторий разделяется на рабочие пространства (workspace) для хранения нескольких моделей одновременно.

Подробные сведения для файлов, элементов архитектуры и дуг хранятся в отдельных таблицах (physics, logics и relations), в каждой из которых есть ссылка на классификацию (id_type, id_relationtype). Классификация элементов архитектуры, файлов и дуг хранится в трех справочниках (logictypes, physicstypes и relatioritypes). Ограничения хранятся в отдельной таблице (permit), связывая типизацию элементов архитектуры и дуг. Подробные схемы хранения приводятся в приложении 2.

Файлы и элементы архитектуры именуются (пате). При этом для элемента архитектуры имя не является ключевым атрибутом. В архитектуре одной программной системы могут встречаться одноименные элементы, отличающиеся, например, уровнем локализации. Дуги графа идентифицируются по тем вершинам (id^parent, id_child), которые они связывают и по типу в классификации. Такая организация хранения направлена на то, чтобы пользователь воспринимал модель не как граф, а как совокупность взаимодействующих вершин.

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

Далее рассмотрим реализацию методик анализа на предлагаемой модели. Расчет количественных методик строится в разрезе групп классификации. Самая сложная задача - подобрать эвристику и коэффициенты. Они определяются многими факторами, в том числе технологиями и инструментами разработки, поэтому ориентация на какую-то конкретную формулу сузит круг анализируемых задач. Ограничимся расчетом параметров формул 6, 7 и 8.

ObjectType

Logics_

id_global (FK) id_workspace (FK)

name

ld_Typa (FK) elementcount servie einf

LogicTypes IdType

T

Name is_a)g is_complex discription

permit

m

Objects

id_global

id_workspace (FK)

ld_ObjType (FK) CreationDate

A

Relations

id_global (FK) ¡^workspace (FK)

id RelationType (FK) id~Parent (FK) id_Child (FK)

RelationsTypes

id_RelationType

name_act

namejjas

discription

first_Logicat

sec_Logical

is_single

workspace

Phisics

id_global (FK) id_wort<space (FK)

Idjype (FK) nama

ld_user (FK) CreationDate

PhisicsTypes

Рисунок ЕЯ-диаграмма структуры репозитория

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

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

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

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

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

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

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

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

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

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

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

Модель была апробирована при сопровождении модуля реальной программной системы. По предложенным схемам и алгоритмам был реализован программный макет, который использовался для хранения и обработки модели. Архитектурная часть построенной модели содержит около 5500-9500 вершин (из них около 500-800 соответствуют классам) и 6600-10000 дуг (из них около 5000-8000 для связи классов с их методами и свойствами). В приложении 2 содержится таблица с некоторыми количественными характеристиками архитектурной части предложенной модели.

Достоинства предложенного подхода состоят в следующем:

-Упрощение сбора и накопления данных о системе - сокращаются затраты на согласование информации.

-Упрощение внесения изменений в систему - модель становится инструментом локализации изменений. Упрощается «исследование» сопровождаемого продукта.

-Возможность описания алгоритмов анализа.

-Возможность обоснования алгоритмов анализа.

-Простая автоматизация обработки модели.

-Обобщение алгоритмов анализа для различных представлений.

-Упрощение процесса сопровождения в целом.

ОСНОВНЫЕ РЕЗУЛЬТАТЫ

На защиту выносятся:

- Принцип моделирования программной системы на основе графа взаимодействий, обеспечивающий уменьшение сложности настройки нотации представления [1-3,6,9,10].

- Аналитический аппарат для решения задач сопровождения системы [13,6,8,9].

- Методология моделирования систем с использованием предложенного аналитического аппарата [1-5,7,8,10].

- Уточнённые схемы хранения модели и связанной с ней информации, а также алгоритмы их анализа [1-5,8,10].

СПИСОК ПУБЛИКАЦИЙ ПО ТЕМЕ ДИССЕРТАЦИИ Публикации в журналах перечня ВАК

1. И.В Игнацкая, В.Н. Лукин. Моделирование программных систем на основе графа взаимодействий // Вестник Московского Авиационного Института 2009, т.16, №7, с 70-76

2. И.В Игнацкая. Представление и анализ архитектуры программных систем на основе графа взаимодействий // Труды МАИ http://www.mai.ru. Вып. 39, 2010.

3. И.В Игнацкая. Граф взаимодействий как инструмент сопровождения программных систем // Вестник Московского Авиационного Института 2011, т. 18, №1, с 52-58

Публикации в других изданиях

4. Игнацкая И.В. Универсальная система создания и анализа внутренней документации UNIDOC //Технологии Microsoft в теории и практике программирования: Труды IV Всероссийской конференции студентов, аспирантов и молодых учёных. Москва, 1-2 апреля 2008г -М.:Вузовская книга,2008, с.33-34

5. Игнацкая И.В. Универсальная система создания и анализа внутренней документации UN1DOC //"Новые информационные технологии". Тезисы докладов XV Международной студенческой школы-семинара - М.: МИЭМ, 2007, с.250

6. Игнацкая И.В. Использование модели на основе графа взаимодействий для построения и интеграции различных представлений программных систем. //Технологии Microsoft в теории и практике программирования: Труды V Всероссийской конференции студентов, аспирантов и молодых учёных. Москва,1-2 апреля 2009г-М.:Вузовская книга,2009, с.30-31

7. Игнацкая И.В. Использование представления программной системы на основе графа взаимодействий в конфигурационном управлении. //"Новые информационные технологии". Тезисы докладов XVI Международной студенческой школы-семинара - М.: МИЭМ, 2008, с. 94

8. Игнацкая И.В. Использование представления на основе графа взаимодействий для разработки и сопровождения программных систем //Материалы XVI Международной конференции по вычислительной механике и современным прикладгым программным системам(ВМСППС'2009),25-31 мая 2009г.,Алушта. -М: Изд-во МАИ-ПРИНТ,2009, с.346-348

9. Игнацкая И.В. Представление на основе графа взаимодействий как инструмент анализа архитектуры программных систем //Материалы XVI Международной конференции по вычислительной механике и современным прикладгым программным системам(ВМСППС'2009),25-31 мая

2009г.,Алушта. -М: Изд-во МАИ-ПРИНТ,2009, с.348-350

Ю.Игнацкая И.В. Граф взаимодействий как инструмент сопровождения программных систем //Материалы VIII Международной конференции по Неравновесным процессам в соплах и струях (NPNJ'2010), 25-31 мая 2010 г., Алушта. -М: Изд-во МАИ-ПРИНТ,2010, с.569-571

Игнацкая Ирина Владимировна

МЕТОДОЛОГИЯ МОДЕЛИРОВАНИЯ НА ОСНОВЕ ГРАФА ВЗАИМОДЕЙСТВИЯ ПРИ СОПРОВОЖДЕНИИ ПРОГРАММНОЙ СИСТЕМЫ

Специальность: 05.13.11 Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата физико-математических наук

Подписано в печать 20.11.2010г.

Усл.п.л. - 1.5 Заказ №03117 Тираж: ЮОэкз.

Копицентр «ЧЕРТЕЖ.ру» ИНН 7701723201 107023, Москва, ул.Б.Семеновская 11, стр.12 (495) 542-7389 www.chertez.ru

Оглавление.

Список условных обозначений.

Введение.

Глава 1. Развитие технологий моделирования программных систем.

1.2 Первые технологии моделирования программных систем.

1.3 Структурный подход в моделировании.

1.3.1 Нотация IDEF0.

1.3.2 Нотации DFD.

1.3.3 Нотации информационного моделирования.

1.3.4 Структурные карты.

1.3.5 Нотации для описания динамики поведения.

1.4 Объектный подход в моделировании.

1.4.1 Общая структура UML.

1.4.2 Описание диаграмм UML.

1.4.3 Использование UML при проектировании и сопровождении.

1.5 Model Driven Architecture. Архитектура, основанная на модели.

1.6 Model Driven Development. Разработка, основанная на моделировании.

2.2 Граф взаимодействий как модель.42

2.3 Интеграция различных представлений системы.46

2.4 Анализ графа взаимодействий.49

2.4.1 Количественные методики анализа графа взаимодействий.50

2.4.2 Анализ топологии графа взаимодействий.53

2.4.2.1 Анализ смежности в графе взаимодействий.53

2.4.2.2 Анализ связности графа взаимодействий.59

2.4.2.3 Возможности поиска.61

2.4.2.4 Повторное использование кода и архитектурных решений.65

2.4.2.5 Анализ блоков.66

2.4.2.6 Анализ циклов.69

2.4.3. Конфигурационные методики анализа графа взаимодействий.71

2.5. Граф взаимодействий и нотации описания программных систем.72

2.5.1 Отображение графа взаимодействий в нотации ГОЕБ.73

2.5.2 Отображение графа взаимодействий в структурные карты Джексона и Константайна.74

2.5.3 Граф взаимодействий и объектные модели.75

2.5.4 Граф взаимодействий и модели для описания поведения системы.77

2.5.5 Граф взаимодействий и информационное моделирование.78

2.5.6 Расширение представления под конкретную задачу или новые требования.79

2.6 Заключение.81

Глава 3. Применение моделей на основе графа взаимодействий для сопровождения программного обеспечения.82

3.1 Введение.82

3.2 Организация хранения модели.83

3.3 Типовые операции над репозиторием.86

3.4 Обработка типизации элементов репозитория.92

3.5 Интеграция моделей.94

3.6 Реализация операций анализа.95

3.7 Дополнительная информация в узлах графа. 101

3.8 Документирование. 103

3.9 Конфигурационное управление. 106

3.10 Порядок работы с моделью. 113

3.11 Другие возможности и перспективы использования. 116

3.12 Заключение.117

Заключение.120

Литература. 121

Глоссарий.126

Приложение 1. Примеры диаграмм.128

Приложение 2. Дополнения к главе 3.140

СПИСОК УСЛОВНЫХ ОБОЗНАЧЕНИЙ - начало доказательства. ▼ - окончание доказательства.

ВВЕДЕНИЕ

Цель работы - формализация подхода моделирования программных систем на основе графа взаимодействий, разработка аналитического аппарата для этого подхода и обоснование его применения на этапе сопровождения программных систем. Термин «методология» понимается как система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе [47].

Сопровождение - наиболее длительный, трудоемкий и дорогостоящий этап жизненного цикла программного обеспечения [21, 44]. Фактически длительность этого этапа определяет длину всего жизненного цикла программной системы. Основное содержание сопровождения - внесение изменений в программное обеспечение по требованию заказчика. Изменения могут быть вызваны изменением в требованиях к программному обеспечению или его модернизацией, а также исправлением выявленных ошибок. Поддержка этапа сопровождения особенно важна для крупных программных проектов, потому что разработка и внедрение новой системы в случае невозможности изменить старую сопряжена с большими затратами и может привести к потере критически важной информации [20]. При этом необходимо учитывать, что внесение изменений ограничивается по времени [44]. Несвоевременность внесения изменений тоже может вынудить заказчика отказаться от продукта.

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

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

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

На сегодняшний день существует множество методов и нотаций представления программных систем, предназначенных для описания систем вообще, программных систем или каких-либо их аспектов. Отдельные нотации ориентированы на работу в рамках определенных технологий, инструментов и предметных областей [17, 36]. Некоторые фирмы, занимающиеся производством программных систем, разрабатывают свои собственные методологии, которые наиболее полно соответствуют их деятельности и специфики предметных областей их программного обеспечения [20, 4]. При этом для развитых программных систем при длительном сопровождении адаптация представления к специфике предметной области делает систему более понимаемой и облегчает ее анализ.

Хранение и анализ информации о системе производится с помощью CASE-средств (Computer Aided System Engineering)^ 8, 37, 56]. Вопрос о том, какие нотации войдут в состав инструмента, решает производитель, а возможности расширения представления отсутствуют или ограничены. Такое положение дел ограничивает возможности анализа. Совместное использование нескольких инструментов требует согласования информации. В работе предлагается разработанный автором принцип моделирования программных систем, называемый графом взаимодействий и позволяющий наиболее полно подобрать представление сведений о системе необходимых для ее модификации при длительном сопровождении, построить модель системы в заданном представлении и обеспечить анализ введенных данных. Для достижения поставленной цели необходимо решить следующие задачи:

• обеспечить построение модели программной системы в заданной нотации.

• обеспечить расширяемость представления

• обеспечить интеграцию нескольких методологий

• обобщить методики анализа программных систем.

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

ЗАКЛЮЧЕНИЕ.

На защиту выносятся следующие результаты:

-Принцип моделирования программной системы на основе графа взаимодействий, обеспечивающий уменьшение сложности настройки нотации представления [27,28,34,29,30,33].

-Аналитический аппарат для решения задач сопровождения программной системы, в основе которого лежат доказанные в работе свойства графа взаимодействий при описании архитектуры программных систем [27,28,34,30,33].

-Методология моделирования систем с использованием предложенного аналитического аппарата [27-29,32,34,35].

-Уточнённые схемы хранения модели и связанной с ней информации, а также алгоритмы их анализа [27-29,32,34,35].

1. Brown A. An 1.troduction to Model Driven Architecture // IBM Rational DevelopER Works, 2004.

2. Common Warehouse Metamodel (CWM) Specification // http://www.omg.org/docs/foraial/03-03-02.pdf

3. Grant Larsen Using the IBM Rational Asset Manager Configurator to configure UML model profiles //http://www.ibm.com/developerworks/rational/library/08/0923larsen/

4. McGregor J. D. Software Architecture// Journal of Object Technology (JOT), vol.3, No. 5, pp. 65-77.

5. Meta Object Facility (MOF) 2.0 QuERy/View/Transformation Specification VERsion 1.0 //http://www.omg.org/docs/formal/08-04-03.pdf

6. Meta Object Facility (MOF) Core Specification OMG Available Specification VERsion 2.0 // http://www.omg.org/cgi-bin/doc7formal/06-01-Ol.pdf

7. MOF 2.0/XMI Mapping, VERsion 2.1.1 // http://www.omg.org/docs/formal/07-12-01 .pdf

8. Recommended Practice for Architectural Description of Software-Intensive Systems, ANSI/IEEE Std 1471-2000

9. Robert B. France, Sudipto Ghosh, Trung Dinh-Trong, Amor SolbERg. Model-Driven Development Using UML 2.0: Promises and Pitfalls, IEEE Computer, February 2006. IEEE Computer Society, 2006.

10. Selic B. Unified Modeling Language vERsion 2.0 // http://www.ibm.com/developERworlcs/rational/library/05/321 UML/index.htm

11. Selic В., The Pragmatics of Model-Driven Development. IEEE Software, September/October 2003. IEEE Computer Society, 2003

12. Stephen Mellor, Anthony Clark, Takao Futagami, Model-Driven Development. IEEE Software, September/October 2003. IEEE Computer Society, 2003

13. Thomas D. Agile Evolution -Towards The Continuous Improvement of Legacy Software // Journal of Object Technology (JOT), vol. 5, no. 7, September-October 2006, pp. 19-26

14. UML 2.0 OCL Specification // http://www.omg.org/cgi-bin/apps/doc?formal/06-05-01 .pdf

15. Vinoski S. Do You Know Where Your Architecture Is? // IEEE IntERnet Computing, September-October 2003.

16. Беркович В.,Чудин А. Практика применения паттернов проектирования.:RSDN Magazine #3

17. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. 2-е изд.:-СПб: ДМК Пресс, 2007

18. Вендров A.M. CASE-технологии. Современные методы и средства проектирования информационных систем. // http://CASEtech.h 1 .ru/library/vendrov/index.htm

19. Волкова Е. Д., Страбыкин А. Д. Анализ и трансформации исполняемых UML моделей. // Труды Института системного программирования. М.: ИСПРАН, 2006. С. 171-192.

20. Гласс Р. Факты и заблуждения профессионального программирования. СПб: Символ-Плюс, 2007.

21. Гласс Р., Нуазо Р. Сопровождение программного обеспечения. — М: Мир,1983

22. Горбунов-Посадов М.М. Конфигурация программ. Рецепты безболезненных изменений. 2-изд. испр. и доп. — М: Малип,1994

23. Дейт К.Д. Введение в системы баз данных. 8-е издание.: Пер с англ. — М.:Издательский дом «Вильяме», 2006

24. Дубина О. Обзор паттернов проектирования //http://www.citforum.ru/SE/project/pattem/

25. Евстигнеев В.А. Применение теории графов в программировании. Под ред. А.П. Ершова. — М.: Наука, Главная редакция физико-математической литературы, 1985.

26. Ершов А.П. Введение в теоретическое программирование. М.: Наука, 1973

27. И.В Игнацкая, В.Н. Лукин. Моделирование программных систем на основе графа взаимодействий // Вестник Московского Авиационного Института 2009, т. 16, №7, с 70-76

28. И.В Игнацкая. Представление и анализ архитектуры программных систем на основе графа взаимодействий // Труды МАИ http://www.mai.ru. Вып. 39, 2010.

29. Игнацкая И.В. Граф взаимодействий как инструмент сопровождения программных систем //Материалы VIII Международной конференции по Неравновесным процессам в соплах и струях (NPNJ'2010), 25-31 мая 2010 г., Алушта. -М: Изд-во МАИ-ПРИНТ,2010, с.569-571

30. Игнацкая И.В. Использование представления программной системы на основе графа взаимодействий в конфигурационном управлении. //"Новые информационные технологии". Тезисы докладов XVI Международной студенческой школы-семинара М.: МИЭМ, 2008, с.94

31. Игнацкая И.В. Граф взаимодействий как инструмент сопровождения программных систем // Вестник Московского Авиационного Института 2011, т.18, №1, с 175-178

32. Игнацкая И.В. Универсальная система создания и анализа внутренней документации UNIDOC //"Новые информационные технологии". Тезисы докладов XV Международной студенческой школы-семинара -М.: МИЭМ, 2007, с.250

33. Калянов Г.Н. CASE: структурный системный анализ (автоматизация и применение). М.: ЛОРИ. 1996.

34. Калянов Г.Н., Козлинский A.B., Лебедев В.Н. Сравнение и проблема выбора методов структурного системного анализа // PC WEEK/RE. 1996. N.34 (27 августа).

35. Кериевски Д. Рефакторинг с использованием шаблонов.: Пер с англ. -М: ООО «И.Д. Вильяме», 2006

36. Колдовский В. Разработка ПО: метрики программных проектов.//Компьютерное Обозрение №13 (581) 3 апреля 2007

37. Котов В.Е. Сабельфельд В. К. Теория схем программ. М.: Наука, 1991.

38. Котов В.Е. Сети Петри. М.: Наука, 1984

39. Кузнецов М.Б. Трансформация UML-моделей и ее использование в технологии MDА // Программирование,2007. № 1. С. 65-78.

40. Кузнецов. М. MDA — новая концепция интеграции приложений // Открытые системы.2003. № 09.

41. Купер Э. Управление изменениями: неужели между качеством и скоростью разработки программного обеспечения должен быть компромисс. 2004// http://wwvv.intERface.ru/fset.asp?url=/ross/rossh.htm

42. Лапыгин Д. Новичков А. Конфигурационное управление проектами разработки программного обеспечения //http://www.citforum.ru/SE/qualily/configurationmanagement/

43. Липаев В.В. Документирование и управление конфигурацией программных средств. М: СИНТЕГД998

44. Липаев В.В. Управление разработкой программных комплексов. М.: Финансы и статистика, 1993

45. Маклаков C.B. Моделирование бизнес-процессов с AllFusion Process ModelER(BPWin 4.1). -M.:ДИАЛОГ-МИФИ,2003

46. Новичков А. Метрики кода и их практическая реализация в IBM Rational ClearCase.//http://www.ibm.eom/developERworks/m/edu/0108novich/index.html

47. Орлик С., Елманова Н. Роль моделирования в разработке приложений //BYTE,2004 №7 (71), июль 2004

48. Орлов С. Технологии разработки программного обеспечения: Учебное пособие. 2-е изд. СПб: Питер, 2003.

49. Фаулер M. UML. Основы, 3-е издание.-СПб:Символ-Плюс,2006

50. Фаулер М. Архитектура корпоративных программных приложений.: Пер с англ. -М.:Издагельский дом «Вильяме», 2008

51. Фаулер М. Рефакторинг: улучшение существующего кода.: Пер с англ. СПб: Символ-Плюс, 2008

52. Физерз М. Эффективная работа с унаследованным кодом. М: ООО «ИД. Вильяме», 2009

53. Черемных C.B., Семенов И.О. Ручкин B.C. Структурный анализ систем: IDEF-технологии. — М.: Финансы и статистика, 20011. ГЛОССАРИЙ1. CASE, 8 Архитектура, 71. CIM, 37 Ассоциация, 26

54. CWM, 38 Ассоциированный псевдограф, 59

55. DFD, 14, 15 Блок схемы, 10

56. FEO, 15 Взаимодействие, 25

57. EFO, 14 Временная диаграмма, 301.EF1, 17 Действие, 25

58. EF1X, 17 Диаграмма артефактов, 31

59. EF3, 20 Диаграмма деятельности, 29

60. MDA, 36 Диаграмма классов, 27

61. MDD, 39 Диаграмма компонентов, 31

62. MOF, 38 Диаграмма кооперации, 29

63. OCL, 23 Диаграмма обзора взаимодействий,1. OMG, 23 30

64. OSTN, 21 Диаграмма объектов, 28

65. PFDD, 21 Диаграмма пакетов, 32

66. PIM, 37 Диаграмма последовательностей, 28

67. PSM, 37 Диаграмма прецедентов, 27

68. QVT, 39 Диаграмма развертывания, 31

69. SADT, 13, 14 Диаграмма составной структуры, 28

70. STD, 20 Диаграмма состояний, 291. UML, 23 Длина пути, 59

71. XMI, 38 Достижимость вершин, 59

72. Автомат, 25 Зависимость, 26

73. Активный класс, 25 Интеграция моделей, 46

74. Анализ достижимости, 59 Интерфейс, 24

75. Анализ смежности, 53 Информационный граф, 10

76. Аннотационные сущности, 26 Класс, 24

77. Артефакт, 25 Кодогенерация, 34

78. Количественные методики анализа, 501. Компонент, 251. Компоненты связности, 591. Кооперация, 251. Кратные дуги, 541. Марковская модель, 111. Методология, 61. Механизм ограничений, 331. Множество потомков, 56

79. Множество предшественников, 561. Модель, 91. Модуль, 19

80. Нотация Гейна-Сарсона, 15 Нотация Йодана-Де Марко, 16 Обобщение, 26 Обратный инжиниринг, 35 Общие методики анализа, 49 Односторонне связный граф, 59 Оценка корректности модели, 52 Оценка сложности представления, 50

81. Оценка сложности программнойсистемы, 51 Петли, 54

82. Полумарковская модель, 11 Полу степень захода, 57 Полу степень исхода, 57 Помеченные значения, 33 Прецедент, 25

83. Структурные методологии, 13 Структурный анализ, 12 Теория схем программ, 10 Топологические методики анализа,53 Узел, 25

84. Управляющий граф, 10 Шаблон, 62

85. Шаблон проектирования, 34 Шаблон рефакторинга, 36, 65