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

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

Автор: Игнацкая, Ирина Владимировна

Шифр специальности: 05.13.11

Научная степень: Кандидатская

Год защиты: 2010

Место защиты: Москва

Количество страниц: 144 с.

Артикул: 4870629

Автор: Игнацкая, Ирина Владимировна

Стоимость: 250 руб.

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

ОГЛАВЛЕНИЕ
Оглавление.
Список условных обозначений.
Введение.
Глава 1. Развитие технологий моделирования программных систем.
1.2 Первые технологии моделирования программных систем
1.3 Структурный подход в моделировании.
1.3.1 Нотация II0.
1.3.2 Нотации
1.3.3 Нотации информационного моделирования
1.3.4 Структурные карты.
1.3.5 Нотации для описания динамики поведения
1.4 Объектный подход в моделировании.
1.4.Юбщая структура
1.4.2 Описание диаграмм
1.4.3 Использование при проектировании и сопровождении.
1.5 iv i. Архитектура, основанная на модели.
1.6 iv v. Разработка, основанная на моделировании.
1.7 Заключение.
Глава 2. Представление и анализ архитектуры программных систем на основе графа взаимодействий.
2.1 Введение.
2.2 Граф взаимодействий как модель.
2.3 Интеграция различных представлений системы.
2.4 Анализ графа взаимодействий
2.4.1 Количественные методики анализа графа взаимодействий.
2.4.2 Анализ топологии графа взаимодействий
2.4.2.1 Анализ смежности в графе взаимодействий
2.4.2.2 Анализ связности графа взаимодействий
2.4.2.3 Возможности поиска.
2.4.2.4 Повторное использование кода и архитектурных решений.
2.4.2.5 Анализ блоков
2.4.2.6 Анализ циклов
2.4.3. Конфигурационные методики анализа графа взаимодействий
2.5. Граф взаимодействий и нотации описания программных систем.
2.5.1 Отображение графа взаимодействий в нотации ГОЕР
2.5.2 Отображение графа взаимодействий в структурные карты Джексона и Константайна.
2.5.3 Граф взаимодействий и объектные модели.
2.5.4 Г раф взаимодействий и модели для описания поведения системы
2.5.5 Г раф взаимодействий и информационное моделирование
2.5.6 Расширение представления под конкретную задачу или новые требования.
2.6 Заключение.
Глава 3. Применение моделей на основе графа взаимодействий для сопровождения программного обеспечения.
3.1 Введение.
3.2 Организация хранения модели
3.3 Типовые операции над репозиторием
3.4 Обработка типизации элементов репозитория
3.5 Интеграция моделей.
3.6 Реализация операций анализа
3.7 Дополнительная информация в узлах графа
3.8 Документирование
3.9 Конфигурационное управление
3. Порядок работы с моделью.
3. Другие возможности и перспективы использования
3. Заключение
Заключение.
Литература


Они представляли программу в виде графа, в узлах которого стояли некоторые ее части, а дуги обозначали потоки передачи информации либо потоки управления. Для обоснования свойств модели применялись строгие теоретические методы. Особенность таких моделей заключалась в том, что их достаточно просто построить по исходным текстам программы. Наиболее известные модели: управляющий граф [], информационный граф [], Марковская и полумарковская граф-модель [], сети Петри [], а также представления на основе блок схем. Блок схемы - простое описание поведения программы, которое разделяет его на блоки и показывает передачу управления между ними с учетом циклов и ветвлений, выделяя начало, конец программы, а также блоки ввода и вывода. Пример блок схемы приведен в первом приложении на рисунке П1. Управляющий граф - более формальная модель представления управляющих потоков. Это ориентированный граф без параллельных дуг, у которого есть единственная вершина-вход, из которой достижимы все вершины, и единственная вершина-выход, достижимая из любой вершимы графа. В узлах графа могут стоять одиночные операторы либо их группы, если нет необходимости в детальном описании структуры программы. Аналогично строится информационный граф. Две вершины соединяются, если одна использует результат другой в качестве аргумента. Таким образом, описывается передача информации между компонентами программы. Марковская модель получается, если для дуг и вершин управляющего графа задать веса, являющиеся фиксированными значениями некоторых параметров, и соединить обратной дугой вход и выход. Веса вершин веса могут обозначать объем или время вычислений, а для дуг - вероятность передачи управления. Если веса, соответствующие вершинам - случайные величины, для которых определены дисперсии и средние значения, то получается полу марковская модель. Сеть Петри представляет собой двудольный ориентированный граф, состоящий из вершин двух типов — позиций и переходов, соединённых между собой дугами, вершины одного типа не могут быть соединены непосредственно. В позициях могут размещаться метки (маркеры), способные перемещаться по сети. Сети Петри применяются для моделирования последовательных и последовательно-параллельных структур управления. Пример блок схемы приведен в первом приложении на рисунке П1. Описанные представления удобны для анализа, но сложны для восприятия человеком, исключая, пожалуй, блок-схемы. Модели усложняются с ростом самой программы, тем более, если надо хранить историю изменений. В более поздних моделях можно отметить включение в модель данных, которые нельзя получить из кода программы. Однако эти данные не описывают семантику компонент программы и носят технический характер. Возможности показать структурные связи между компонентами модели почти отсутствуют. С другой стороны не ограничиваются инструменты и технологии, использованные при создании програлдлтой системы. Формируется понятие архитектуры, как первичной организации системы, совокупности ее компонент, отношений между ними и внешней средой системы [8]. В жизненном цикле программного обеспечения оформляются стадии анализа требований и проектирования спецификации системы, и именно эти стадии начинают представлять наибольший интерес. На ранних этапах жизненного цикла приходит понимание того, что будет делать будущая система, и каким образом она будет функционировать, чтобы удовлетворить предъявленным к ней требованиям. Нечеткость и неполнота системных требований, нерешенные вопросы и ошибки, допущенные на этом этапе, в дальнейшем порождают трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всей работы в целом. Для лучшего понимания требований к системе и ее реализации стал применяться структурный анализ -метод исследования, которое начинается с общего обзора системы и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Разрабатываются нотации, основанные на структурном подходе. Изначально структурные нотации предназначались для описания профаммной системы до ее реализации. Позднее выяснилось, что этот инструментарий подходит и для документирования [].

Рекомендуемые диссертации данного раздела

28.06.2016

+ 100 бесплатных диссертаций

Дорогие друзья, в раздел "Бесплатные диссертации" добавлено 100 новых диссертаций. Желаем новых научных ...

15.02.2015

Добавлено 41611 диссертаций РГБ

В каталог сайта http://new-disser.ru добавлено новые диссертации РГБ 2013-2014 года. Желаем новых научных ...


Все новости

Время генерации: 0.216, запросов: 244