CC BY
42
значительное количество), ...
Соли: отсутствуют, ураты (единичные, значительное количество), оксалаты,...
Бактериоскопия (микрофлора): микрофлора отсутствует, кишечная палочка, гонококк, стафилококк и др.
Уробилиноген: имеется, отсутствует.
Диастаза: описывается числовыми значениями (норма до 64 ед.)
База наблюдений «урология» содержит 48 групп наблюдений, 210 наблюдений, из них простых 88, характеристик 569.
Метод реализации системы
Истории болезни формируются на основе модели предметной области (базы наблюдений) в области урологии. База наблюдений имеет большой объем и может изменяться (вводятся новые наблюдения, дополняются и изменяются существующие). Изменения базы наблюдений требуют модификации интерфейса, поэтому разработка пользовательского интерфейса для данного программного средства с помощью традиционных средств является крайне трудоемкой и затратной.
Принимая во внимание вышеизложенное, в качестве средства реализации было выбрано инструментальное средство для разработки и автоматической генерации пользовательских интерфейсов Onto Dev. Основными принципами разработки интерфейса с помощью данного инструментального средства являются: раздельное проектирование интерфейса и прикладной программы с последующим их связыванием; объединение однородной по содержанию информации в компоненты модели интерфейса; формирование компонентов модели интерфейса на основе моделей онтологий, отражающих специфику каждого его компонента.
Onto Dev представляет собой интегрированную среду, состоящую из редакторов для формирования компонентов модели интерфейса и генератора кода. Редакторы, управляемые моделями онтологий, позволяют разработчику в диалоговом режиме описать модель интерфейса. Генератор кода преобразует модель интерфейса в код на выбранном языке программирования (Java, C#), а также связывает код интерфейса и прикладной программы, реализуя (по выбору разработчика) локальное или распределенное приложение.
Применение OntoDev для разработки пользовательского интерфейса системы позволило значительно сократить трудоемкость разработки и упростить последующее сопровождение интер-
фейса системы, при этом максимально вовлечь экспертов предметной области в процесс разработки и сопровождения пользовательского интерфейса. Это удалось за счет следующих возможностей OntoDev: выделения базы наблюдений в отдельный компонент и предоставления экспертам предметной области редактора базы наблюдений для ее модифицирования; наличия средств сопоставления абстрактным терминам модели онтологии (онтологии наблюдений) их представления в интерфейсе и автоматического преобразования в заданные представления.
Архитектура и функции системы
Система состоит из двух основных частей -редактора базы наблюдений и редактора историй болезни. Редактор базы наблюдений, управляемый онтологией наблюдений, является компонентом Onto Dev. С его помощью эксперт предметной области формирует и сопровождает базу наблюдений по урологии в процессе жизненного цикла системы. Врач-уролог с помощью редактора истории болезни формирует историю болезни конкретного пациента. Система позволяет вносить информацию об осмотрах больного с уточнением даты и времени осмотра. Историю болезни можно просмотреть в структурированном виде и напечатать. Архив историй болезни формируется автоматически и может быть использован другими программными средствами.
В настоящее время система проходит опытную эксплуатацию. Основное преимущество системы - возможность сопровождения базы наблюдений данной предметной области ее экспертами. Особенности реализации (сопоставление абстрактным терминам модели онтологии наблюдений их представления в интерфейсе) позволяют автоматически изменять пользовательский интерфейс системы без изменения ее программного кода. Данная система может быть использована в других областях медицины, так как представленная в ней онтология наблюдений является универсальной для всех разделов медицины. Так, в настоящее время в отделе Интеллектуальных систем ИАПУ ДВО РАН разрабатывается Интернет-версия экспертной системы медицинской диагностики по офтальмологии, в которой данная система (с базой наблюдений «офтальмология») является пользовательским интерфейсом экспертной системы.
ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ ИМИТАЦИОННАЯ МОДЕЛЬ МУЛЬТИСЕРВИСНОЙ IP-СЕТИ
А.В. Мельников, К.А. Домбровский
Характерной тенденцией современного этапа развития компьютерных сетей является принци-
пиальное изменение структуры передаваемого ими трафика. Трафик сетей доступа в Интернет, а
также сетей крупных предприятий стал мультимедийным. При этом постоянно разрабатываются и внедряются новые алгоритмы, протоколы и технологии, улучшающие качество передачи трафика реального времени в /Р-сетях. Как следствие -существенное усложнение архитектуры сетей TCP//P, которые теперь характеризуются не просто как сети передачи данных, а как мультисер-висные.
Все это делает применение аппарата аналитического моделирования для исследования вновь создаваемых алгоритмов и протоколов достаточно сложным, а зачастую и невозможным. Альтернативным подходом являются имитационные модели компьютерных сетей, которые могут быть сколь угодно близки к моделируемой системе.
В большинстве существующих сетевых симу-ляторов создание и внедрение модуля вновь разрабатываемого протокола затрагивает если не всю, то большую часть архитектуры имитационной модели сети, так как возникает необходимость модификации других модулей. Таким образом, возникает зависимость между разработчиками. В этой связи актуальной является задача применения концепции объектно-ориентированного проектирования и анализа для построения имитационной модели мультисервисной сети.
Объектно-ориентированная имитационная модель мультисервисной 1Р-сети
В рамках подхода объектно-ориентированного анализа и проектирования имитационная модель
Рис. 1. UML-диаграмма логической структуры имитационной модели мультисервисной сети
мультисервисной сети представляет собой модель сложной системы, а именно:
• логическая структура мультисервисной сети включает в себя модель сетевой топологии, узла и линии связи;
• функциональная составляющая концептуальной модели представлена моделью сетевой нагрузки, генерирующей сетевой трафик;
• физическая модель сети является реализацией разработанной имитационной модели в рамках выбранного программного пакета.
Логическая структура объектно-ориентированной имитационной модели сети представлена с использованием нотации унифицированного языка моделирования UML на рисунке 1. Сетевой узел (класс Node) представлен моделью стека сетевых протоколов (класс ProtocolStack). Семиуровневая иерархия эталонной модели ISO/OSI нашла отражение в абстрактных классах Physical, DataLink, Network, Transport и Application. Последние три уровня модели общепризнано считаются избыточными и представлены классом Application. Далее указываются классы основных протоколов стека TCP/IP, относящиеся к тому или иному уровню. Объединение протоколов в стек указывается через отношение агрегации к классу TCP/IP, который, в свою очередь, является дочерним по отношению к классу ProtocolStack. Каждый протокол имеет собственный формат сообщения. Все сообщения являются дочерними классами по отношению к абстрактному классу Message, который, в свою очередь, является составляющей класса CALL. Данный класс представляет собой вызов, который производит протокол для осуществления вертикального взаимодействия в рамках стека.
Взаимосвязь узла и линии связи указана через отношение ассоциации между классом сетевого интерфейса NIC и классом интерфейса линии связи Connector. Сама линия связи представлена классом Link.
Проведенный авторами анализ показывает, что типовые сетевые топологии не позволяют учесть существенных свойств Интернет-сетей. Поэтому для имитационной модели предложено расширение модели «узкое горло» - модель «мно-гоканальность», которая показана на рисунке 2. Условно схема разделена на четыре области: сеть клиента, сеть Интернет-провайдера (ИП), сеть национального провайдера и магистральная сеть.
В имитационной модели для генерации потока пакетов используются три типа источников трафика - VoIP, HTTP и FTP, которые представляют функциональную компоненту концептуальной модели.
Модель источника VoIP-трафика можно разбить на три подмодели: модель голосового источника, модель выбора голосового кодека, модель потока звонков.
Глобальный Интернет (магистраль]
Рис. 2. Модель сетевой топологии «многоканальность»
Поведение голосового источника традиционно описывается моделью Брэди. Ключевыми элементами модели разговора человека являются активная речь (ON-период), паузы (OFF-период) и законы распределения длительности этих периодов.
До настоящего момента было проведено и опубликовано множество работ, авторы которых пытались на основе большого количества статистических данных установить адекватные вероятностные законы распределения ON- и OFF-пери-одов. Результаты последних исследований (см.: Biernacki A. Statistical analysis of VoIP streams. 7th Conference „Internet - Wroclaw 2005") показывают, что ON/OFF-периоды распределены согласно законам Парето и Вейбулла.
Авторами работы классическая модель Брэди была расширена путем введения третьего состояния - временной интервал между двумя звонками пользователя, состояние AIT (Average InterCall Time). В модели источника VoIP трафика используется кодек сжатия голоса G. 729 Annex B. В модели потока звонков определяются законы распределения времени между двумя звонками с одного источника и длительности самого звонка. Модель источника трафика IP-телефонии представлена на рисунке 3.
Параметры модели приведены в таблице 1.
/,
т* р
ON ) T0FIT ) 1-1/Tgap-1/Th
1/Tgap _У
7Л VÀ
"HT
Рис. 3. Модель источника VoIP-трафика
Таблица 2
Параметры имитационной модели web -трафика
Таблица 1
Параметры имитационной модели трафика VoIP
Параметр модели Функция параметра Значения
Время О]Ч-периода, Тэр Распределение ч a*ba Парето f(x) = 1 a=2,114; b=0,211
Среднее значение, сек 0,4011
Отклонение, сек 0,3637
Время ОЖЖ-периода, Tgap Распределение Вейбулла f(x) = a ( x J" e^a x > 0, a > 0, b > 0
Среднее значение, сек 0,5775
Отклонение, сек 1,1774
Длительность разговора, ТЬ. Распределение Экспоненциальное f(x) = jae"ax,x > 0, a > 0 [0 , x < 0 a = 0,0029
Среднее значение, сек 345,4
Интервал между звонками, Та. Распределение Экспоненциальное a=0,275
Среднее значение, сек 3,64
Кодек Тип G.729 Annex B
Длина пакета, байт 20
Межпакетный интервал, Т1, мс. 10
Параметр модели Функция параметра Значение
Время на просмотр пользователем вебстраницы, неактивный OFF-период Распределение Парето второго типа а * Ъа Г(х) = а Ь , (х + Ъ)а+1 а=2; Ъ=5
Среднее значение, сек. 10
Активный OFF-период Распределение Парето второго типа а=1,5; Ъ=0,167
Среднее значение, сек. 0,5
Количество объектов вебстраницы Распределение Парето второго типа а=1,5; Ъ=1
Среднее значение 3
Размер объекта Распределение Парето второго типа а=1,2; Ъ=2
Среднее значение, Кб 12
Для определения и описания структурных параметров модели web-трафика используется абстракция web-сеанса, которая включает в себя понятия страницы и объекта. Данная абстракция была предложена в SURGE-модели (см.: Barford P., Crovella M. Generating representative web workloads for network and server performance evaluation). В рамках данной модели процесс генерации web-трафика рассматривается как бесконечный цикл запросов web-страниц пользователем через определенный интервал времени.
К особенности данной модели следует отнести два OFF-периода «негенерации» трафика в сеансе. Неактивный OFF-период представляет собой время, которое пользователь тратит на просмотр текущей web-страницы. В общем случае web-стра-ница представляет собой совокупность нескольких объектов: текст, графика и т.д. Активный OFF-период представляет собой время на разборку браузером web-страницы и подготовки нового TCP-соединения для запроса web-компонент. Детали передачи компонент web-страницы зависят от используемого браузера и версии протокола HTTP. В рамках разработанной имитационной модели используется эмуляция протокола HTTP 1.1. Значения статистических параметров модели web-трафика взяты из работы Markovski V. «Simulation and Analysis of Loss in IP Networks» (табл. 2).
.FTP-трафик не является основным в мульти-сервисной сети, но он обеспечивает большую нагрузку на канал, так как формирует постоянный неинтерактивный поток. Для определения и описания структурных параметров модели используется абстракция ftp-сеанса, которая включает в себя понятие файла. Количественные и временные характеристики сеанса, как и в случае с голосовым и wefe-трафиком, определяются с помощью статистических вероятностных распределений и взяты из спецификации, предложенной институтом IEEE в рамках стандарта IEEE 802.20 (табл. 3.).
Физическая модель сети является реализацией разработанной имитационной модели в рамках выбранного программного пакета AnyLogic. Структура классов и схема их взаимодействия в программно реализованной имитационной модели мультисервисной сети соответствует логической структуре модели на рисунке 1.
Таблица 3
Параметры имитационной модели FTP-трафика
Параметр модели Функция параметра Значение
Время между сеансами Распределение Экспоненциальное a=0,006
Среднее значение, сек. 180
Количество файлов в сеансе Значение 1
Размер файла Распределение Логнормальное 1 -(lnx-д)2 f(x) = ,— e 282 , 8v 2nx x > 0 8 = 0,35; д =14,45
Среднее значение, Мб 2
Отклонение, Мб 0,722
Адекватность разработанной модели
Один из наиболее очевидных подходов к проверке точности модели состоит в сравнении выходов модели и реальной системы при одинаковых входах. Используя соответствующий критерий для двух выборок, можно проверить статистические гипотезы о том, что выборки выходов системы и модели являются выборками из различных совокупностей или что они практически принадлежат одной генеральной совокупности.
Таблица 4
Результаты обработки экспериментальных выборок согласно критерию Вилкоксона
Для получения выборок реальной системы был создан программно-аппаратный макет. Потоки HTTP, FTP и VoIP пакетов эмулируются генератором трафика «Distributed Internet Traffic Generator». С использованием критерий Вилкоксона был произведен сравнительный анализ выборок, полученных в ходе натурного и имитационного экспериментов. Результаты расчетов приведены в таблице 4 и свидетельствуют об адекватности разработанной имитационной модели.
Разработанная объектно-ориентированная имитационная модель мультисервисной IP-сети предоставляет возможность исследователю добавлять собственные и заменять существующие классы сетевых объектов, не меняя при этом концептуальную структуру модели. Таким образом, достигается независимость между разработчиками. Доказана адекватность разработанной объектно-ориентированной имитационной модели мульти-сервисной сети на основе характеристик трафика, полученных с использованием натурного стенда измерений характеристик качества обслуживания мультимедийного трафика.
Нижнее критическое значение Статистика Вилкоксона для выборок Верхнее критическое значение
31223,55 задержки пакетов VoIP 33755,45
32933
джиттера пакетов VoIP
33531
процента потерь пакетов VoIP
33275
ИСПОЛЬЗОВАНИЕ СОВРЕМЕННЫХ МЕТОДИК ОЦЕНКИ УЯЗВИМОСТЕЙ
В.В. Круглое, Е.А. Панкратова, М.В. Пряжевская
Процесс предотвращения или снижения критичности грозящих вычислительной системе опасностей состоит из трех этапов:
- классификация угроз безопасности, грозящих системе;
- определение методов защиты от опасно -стей;
- выбор технологии защиты.
Для классификации угроз безопасности (первый этап) может быть использована классификация, называемая STRIDE, по первым буквам английских названий категорий (см.: М. Ховард, Д. Лебланк. «Защищенный код», 2004).
• Подмена сетевых объектов (Spoofing identity) - атаки подобного типа позволяют взломщику выдавать себя за другого пользователя или подменять настоящий сервер подложным.
• Модификация данных (Tampering with data) - атаки этого типа предусматривают злонамеренную порчу данных.
• Отказ от авторства (Répudiation) - контрагент отказывается от совершенного им действия (или бездействия), пользуясь тем, что у другой стороны нет никакого способа доказать обратное.
• Разглашение информации (Information disclosure) - подразумевается раскрытие информации лицам, доступ к которой им запрещен.
• Отказ в обслуживании (Denial of service)
- в атаках такого типа взломщик пытается лишить доступа к сервису правомочных пользователей.
• Повышение привилегий (Elevation of privilege) - в данном случае непривилегированный пользователь получает привилегированный доступ, позволяющий ему взломать или даже уничтожить систему.
Модель STRIDE разработана фирмой «Microsoft» и успешно применяется для определения опасностей, грозящих разрабатываемым системам.
На втором этапе следует определить методы защиты от угроз безопасности. Для решения данной задачи авторами статьи был проведен анализ атак на объекты вычислительных систем и определены возможные методы защиты. Результаты исследований можно свести к следующим методам: аутентификация, авторизация, защита от несанкционированного доступа, аудит, фильтрация.
Для выбора одного из предложенных методов желательно выполнить количественную оценку риска опасности для конкретной вычислительной системы. Как правило, применяют следующие методы количественной оценки риска.
