4. Диагностика маршрута (traceroute) с использованием протокола udp и icmp

Traceroute отправляет на несуществующий порт удаленного узла последовательность UDP-дейтаграмм.

Номер используемого порта по умолчанию 33434.

Алгоритм работы:

• Посылаются дейтограммы с TTL=1 (время жизни пакета)

• Первый же маршрутизатор уменьшает TTL на 1, т.е. TTL=0 и пакет уничтожается, а отправителю посылается ICMP сообщение Time Exceeded.

• Посылаются дейтограммы с TTL=2 (время жизни пакета)

• Первый же маршрутизатор уменьшает TTL на 1, т.е. TTL=1 и пакет проходит дальше.

• Второй маршрутизатор уменьшает TTL на 1, т.е. TTL=1 и пакет уничтожается, а отправителю посылается ICMP сообщение Time Exceeded.

• И т.д.

• Попадая на получателя, пакет уничтожается, т.к. получатель не знает, что с ним делать (порт не существует), и отправителю посылается ICMP сообщение Destination Unreachable.

5. Верификация моделей. Проверка адекватности и корректировка имитационной модели

Верификация модели

Проверка адекватности и корректировка модели;

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

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

Планирование экспериментов;

• стратегическое планирование – план эксперимента

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

Собственно моделирование;

• анализ чувствительности;

Анализ результатов моделирования и принятие решения.

• Интерпретация – построение выводов по данным, полученным в результате имитации

• Реализация – практическое использование результатов эксперимента

• Документирование – регистрация хода осуществления проекта, а также документирование процесса создания и использования модели

Проверка адекватности и корректировка модели

1) После написания модели и до начала эксперимента – проверка адекватности модели.

Замечания: На самом деле этот этап – непрерывный процесс с момента создания модели до завершения экспериментов. Почему сразу, а не после начала экспериментов – стоимость эксперимента (если речь идет о сложной системы, сбор данных) и «гипноз» модели.

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

2.Строго регламентированного (научно обоснованного) формального процесса – «испытание» модели не существует. За исключением тривиальных случаев. Суть не в доказательстве, а в 1) достижении необходимого уровня уверенности пользователя, что любой вывод о поведении системы, сделанный на основании моделирования будет верным.

3.Не нужно стремиться доказать, что та или иная имитация является «правдивым» отображением реальной системы (за исключением тривиальных случаев). Важна не «правдивость» модели, не справедливость структуры модели, а ее функциональная полезность – т.е. справедливость тех умозаключений, которые будут получены в результате моделирования. 2) Выводы, полученные в результате моделирования, справедливы и корректны.

Таким образом, оценка адекватности имеет две стороны:

1) Достижение необходимого уровня уверенности пользователя;

2) Выводы, полученные в результате моделирования, справедливы и корректны.

2) Три стадии оценки адекватности имитационной модели:

• (этап отладки программы) Верификация– экспериментатор должен убедиться, что модель ведет себя так, как задумано.

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

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

6. Даталогическое проектирование.

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

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

• Описание концептуальной схемы БД в терминах выбранной СУБД.

• Описание внешних моделей в терминах выбранной СУБД.

• Описание декларативных правил поддержки целостности базы данных.

• Разработка процедур поддержки семантической целостности базы данных.

Проектирование схемы БД может быть выполнено двумя путями:

• путем декомпозиции (разбиения), когда исходное множество отношений, входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;

• путем синтеза, то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.

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

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

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

Билет №16