CC BY
61
2009
ВЕСТНИК ТОМСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА Управление, вычислительная техника и информатика
№ 2(7)
ОБРАБОТКА ИНФОРМАЦИИ
УДК 613.6:004.8
А.Г. Иванов, М.П. Дьякович
ПОДХОДЫ К СОЗДАНИЮ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННО-АНАЛИТИЧЕСКОЙ СИСТЕМЫ ДИАГНОСТИКИ И ПРОГНОЗИРОВАНИЯ ПРОФЕССИОНАЛЬНЫХ НЕЙРОИНТОКСИКАЦИЙ
Настоящая работа посвящена вопросам создания информационной технологии и реализующей ее информационно-аналитической системы, которая использует в качестве источника информации клинико-биологические, социально-психологические и санитарно-гигиенические сведения о каждом работнике химического производства, подвергающемся воздействию нейро-тропных веществ, и предоставляет сервис экспертной поддержки принятия решения вопросов диагностики и прогнозирования профессиональных нейроинтоксикаций в профпатологической практике.
Ключевые слова: информационно-аналитическая система, экспертная система, диагностика профессиональных нейроинтоксикаций, программная архитектура, требования к системе.
Производственный контакт с нейротропными веществами 1 - 2 класса опасности создает угрозу развития у работников химических предприятий профессиональных поражений мозга, характеризующихся невозможностью полного восстановления здоровья и в постконтактный период [1, 2], что обусловливает важность ранней диагностики профессиональных нейроинтоксикаций (ПНИ) с целью своевременного осуществления медико-социальных реабилитационных мероприятий. Клиницисту необходимо не только определить нозологическую форму, при которой имеют место непротиворечивые отношения между множеством наблюдаемых признаков (нарушений в органах и системах) и интегрирующим их понятием диагноза, но и учесть уровни производственных факторов, с которыми каузально связаны эти признаки. Диагностика профессиональных нейроинтоксикаций -сложный и многоступенчатый процесс, требующий значительных временных, финансовых и производственных затрат, сокращение которых может быть достигнуто разработкой и внедрением компьютерной информационной технологии (ИТ) поддержки клинико-диагностического процесса.
Создание информационных систем в области медицины и автоматизация бизнес-процессов клинических учреждений является на сегодня научноинженерной областью, характеризующейся разнообразной и развивающейся практикой [3]. Внедрение информационных технологий в медицине охватывает регистрационно-учетные, вычислительные и аналитические функции медицинской структуры. В силу концептуальных трудностей, с которыми сталкиваются подходы к обобщению, упорядочению и формализации в сфере медицинской
диагностики, аналитические функции нуждаются в алгоритмическом и программном обеспечении систем искусственного интеллекта, в частности экспертных систем. Опыт применения систем данного рода в медицине достаточно позитивен, изучен и обобщен в иностранной литературе [4 - 6]. Отечественная практика столь же динамично развивает идеи применения средств искусственного интеллекта в медицине, включая выбор, разработку, тестирование и оценку применимости алгоритмов и методов к частным задачам диагностики и медицинского прогноза [7, 8]. В актуальных отечественных разработках описываются подходы к программной архитектуре и инфраструктуре медицинской информационно-аналитической системе (ИАС) [9]. В то же время, вопросы, касающиеся разработки создания ИТ, позволяющих оптимально сочетать опыт клиницистов в области профессиональной патологии с возможностями автоматизации сбора и интерпретации диагностических данных, а также создании баз знаний, позволяющих формировать алгоритмы дифференциальной диагностики, в доступной нам литературе освещены недостаточно.
Проблема создания медицинских ИАС является частью общей проблемы, требующей решения сопутствующих задач, связанных с недостаточным уровнем компьютеризации медицинской практики и отсутствием навыков работы с подобными системами у клиницистов. Трудность дифференцированной диагностики, высокая социальная значимость принятия врачами верного решения о признании связи с нейроинтоксикации с производством, прогноза течения заболевания, обусловливает необходимость разработки ИТ, включающей поддержку и техническое консультирование клиницистов-профпатологов при принятии диагностических решений. Целью настоящего исследования явилась разработка подходов к созданию автоматизированной информационно-аналитической системы диагностики и прогнозирования профессиональных нейроинтоксикаций, включающих анализ требований к ИАС, ее проектированию, разработке экспертной системы (ЭС) в ее составе и апробацией в клинических условиях.
1. Результаты и их обсуждение
Создание ИАС, включающей и координирующей работу регистрационных и аналитических сервисов, - нетривиальная задача. Сложность ее заключается в слабой структурированности медицинской предметной области, необходимости предварительных исследований эвристических экспертных знаний и алгоритма прогнозирования ПНИ, интеграции до 20 смежных функциональных процессов, развертывания прикладных сервисов с включением 2 классов пользователей, действующих на границе системы (математик и когнитолог). Анализ прецедентов позволил определить типологию функциональных процессов ИАС (см. табл.1).
Сбор и анализ требований к ИАС выполнялся дифференцированно, для каждого из выявленных пользовательских классов (см. табл.2).
Создание ИАС, обеспечивающей реализацию описываемой ИТ, требует организации жизненного цикла (ЖЦ) на основе модели, применимой для распределенной многопользовательской автоматизированной системы и характеризуемой акцентированной ролью этапов анализа требований и проектирования. Оценка применимости существующих процессов разработки программного обеспечения (ПО), проведенная с целью выбора эталонной модели системного ЖЦ, позволила определить в качестве таковой процесс RUP (Rational Unified Process), имеющий определенные соответствия нормативным характеристикам ИАС [10 - 12].
Т аблица 1
Типология функциональных процессов ИАС
№ Наименование прецедента Функциональный процесс
Граничные процессы
1 Извлечение знаний Мета-анализ диагностики ПНИ, формализация эвристических знаний экспертов
2 Прием-передача информации пользователей Прием и регистрация данных социально-гигиенических исследований, проводимых врачами-гигиенистами и социологами, результатов медицинских осмотров работников невроло-гами-профпатологами
Внутренние процессы
1 Использование ЭС Применение ЭС врачом-профпатологом с целью диагностики и прогнозирования ПНИ у отдельного пациента
2 Регистрация медицинской информации* Деятельность врачей-клиницистов по выполнению диагностических процедур, установлению и регистрации частных диагнозов
3 Ведение медицинской БД Применение методов многомерного анализа данных, верификация сведений, поступающих в систему
4 Поддержка базы знаний ЭС Деятельность когнитолога по модификации фактов, правил-продукций, лингвистических переменных, управлению резервированием базы знаний
5 Поддержка программной системы Деятельность разработчика-сопроводителя, реализующая управление программными компонентами, поддержка работы пользователей
6 Администрирование ИАС Деятельность системного администратора по управлению доступа к программно-аппаратной инфраструктуре ИАС и поддержке работы пользователей в системе
Примечание. * Соответствующий функциональный процесс развертывается в рамках каждой из 11 диагностических процедур, касающихся обследования основных систем организма.
Т аблица 2
Классификация функциональных ролей в ИАС
№ Классы пользователей Функции
1 2 3
Внутренние пользователи
1 Врач-профпатолог Установка диагноза ПНИ
2 Клиницист Узконаправленное исследование организма пациента и установление частного диагноза в соответствующей области медицины
3 Когнитолог Создание и поддержка базы знаний ЭС, привлечение и формализация знаний экспертов
4 Математик Верификация поставляемых в ИАС медицинских данных, их анализ с помощью методов многомерного анализа
5 Системный администратор Постоянная техническая поддержка ИАС, оказание консультативной помощи пользователям при работе в ИАС
6 Разработчик Создание, модификация и поддержка ИАС на уровне кодов приложений и объектов баз данных
Продолжение табл. 2
l 1 2 1 З
Внешние пользователи *
7 Врач- гигиенист Анализ и оценка условий труда
8 Социолог Оценка социально-бытовых условий жизни и социальнопсихологических характеристик работников
9 Невролог-профпа-толог поликлинического отделения Скрининговое обследование работающих, подготовка предварительного заключения по результатам углубленного медицинского осмотра работников, передача его в ИАС
lO Эксперт в области профпатологии нервной системы Источник эвристических знаний для ИАС, не является ее регулярным пользователем
Примечание. * Контакт с программной системой опосредован взаимодействием с пользователями классов 3, 4.
Развитие ИАС имеет итеративный характер. Перспективный план создания ИАС предполагает результатом первой итерации ЖЦ получение и внедрение научного прототипа, использующего контексты пациентов, которые формируются когнитологом (инженером по знаниям), исходя из информации о состоянии органов и систем организма, поставляемой клиницистами. На второй и следующих итерациях предусмотрены ввод в действие и интеграция в ИАС регистрационных подсистем для узких медицинских исследовательских процедур, которые будут использовать автоматизированное формирование контекстов пациентов. Дальнейшее развитие системы даст возможность реализовать экспертную поддержку установления частных диагнозов на основе обследований пациентов клиницистами. Таким образом, будет расширена область применения сервиса ЭС. Применение компонентной архитектуры лежит в основе архитектурной идеи ИАС. В качестве компонентов в проекте были рассмотрены единицы базового ПО, совместимого на уровне интерфейсов программирования, и программные компонентные каркасы. На основе анализа свойств современных программных средств ЭС было принято решение о совместном использовании оболочки ЭС «Jess 7»[13] и пакета обработки нечеткой информации «NRC FuzzyJ Toolkit» [14], реализованных в форме комплексов JAR(Java ARchive)-библиотек Java-классов и представляющих совместимые API (Application Programming Interface) в качестве стандартного пути интеграции в Java-приложения. Визуальное моделирование ПО с применением языка UML (Unified Modeling Language) - стандартная и неотъемлемая дисциплина RUP, обеспечивающая требуемый качественный уровень проектной информации при построении моделей.
Управление требованиями представляет особую важность. Значимость этапов анализа и проектирования в процессе создания ИАС были определены результатами исследования проблемной области. Предметом анализа и важным управляющим ресурсом для ЖЦ ИАС являются требования пользователей каждого из классов.
Реализация дисциплины управления требованиями включает анализ графовых моделей требований к создаваемой системе, позволяющий выявить и упорядочить по степени значимости ряд базовых функциональных и эксплуатационных характеристик ИАС. Собранные требования классифицируются по признакам принадлежности соответствующим типам пользователей и распределяются на категории функциональных и эксплуатационных, на основании которых, наряду со сводом
требований, составляющих внешнее описание программной системы, выполняется построение моделей функций и качества ИАС. Для усовершенствования таких построений и снятия возможных противоречий при переходе от свода требований к моделям функций и качества ИАС, была построена формальная модель, включающая построение и анализ двух основных графовых моделей-соответствий: «Классы пользователей - примитивы качества» и «Классы пользователей - функции программной системы». Анализ моделей позволит провести ранжирование по значимости функциональных и эксплуатационных характеристик ИАС.
Модель «Классы пользователей - примитивы качества» была построена в целях формализации соответствия потребностей пользователей ИАС составу примитивов качества программ. Иллюстрация построения модели на основе требований, собранных на начальной итерации ЖЦ ИАС, представлена на рис. 1.
Рис. 1. Формальная модель «Классы пользователей - примитивы качества»
Взвешенный неполный двудольный граф 06д7 со множествами вершин А (классы непосредственных пользователей ИАС) и В (примитивы качества программ по номенклатуре [15,16]) моделирует соответствие д: А^В, являющееся нефункциональным отображением А в В. Направление упорядоченности вершин - сверху вниз задано схематически. Любое ребро (аь Ь]) символизирует наличие в требованиях пользователей класса а, потребности в некоем качественном свойстве ИАС, представляемом примитивом Ь]. Над каждым символом а( приведен натуральный ряд, соответствующий весам ребер, инцидентных вершине аг-, ребра упорядочиваются также - сверху вниз. Весовой коэффициент к-го ребра, 1 < к < р(аг), 1 < I < 6, где р(аг) - степень вершины аь соответствует количеству выделенных единиц потребности пользователя класса а1 в свойстве качественного
примитива Ьу. Под единицей потребности здесь следует понимать уникальное упоминание описаний данного качественного свойства в контексте некоей максимально конкретизированной функции, действия или желаемой характеристики ИАС, принимаемые здесь атомарными. Для всех единиц потребностей значимость принимается равнозначной. Каждое выявленное не дублированное описание увеличивает значение соответствующего коэффициента ю,к на 1. Вычисление показателя совокупной значимости для любого из примитивов качества
V
р(ьу ) ■ 0=1.
1 < к < р(Ь,), 1 <у < 17,
где р(Ьу) - степень вершины, соответствующей данному примитиву качества, юук -весовой коэффициент к-го ребра, инцидентного вершине Ьу, относительно каждой вершины в В, дает ряд значений (рис. 2), иллюстрирующих эталонную значимость качественных примитивов, позволяющих определить приоритетные направления в обеспечении качества ИАС и выявить необходимость в добавлении недостающих требований. Важно, что модель будет нереалистична, если из свода требований предварительно, на неформальном этапе анализа, не будут исключены противоречия и неточности.
к=1
Рис. 2. Распределение формальной значимости по требованиям между примитивами качества в проекте ИАС
Третье подмножество вершин С символизирует стандартные критерии качества и вводится только для отображения соответствия примитивов качества - критериям. Никакие ребра, инцидентные вершинам множества С и при этом - вершинам множества В, не учитываются при подсчете степеней вершин множества
В. Значимость таких качественных критериев, как надежность и функциональность, со всеми зависимыми примитивами, рассматриваются как максимизируемое априори и не ставится в прямую зависимость от пользовательских требований к ИАС. Соответственно данные характеристики в настоящий анализ не включаются.
Таким образом, представленная модель позволяет обозначить и формализовать степень важности примитивов программного качества для классов пользователей, и, таким образом, упростить процесс управления требованиями и их применения для формирования проектных решений.
Наряду с моделью качества рассматривается модель «Классы пользователей -функции программной системы», при построении которой множество B формируется функциями ИАС, информация о которых находится на концептуальном уровне объектной модели анализа. Информация извлекается из прецедентов, включаемых, расширяющих и дифференцирующих прецеденты, определяющие прикладные сервисы ИАС и основные ее функциональные процессы (табл.1), представляемые в графе элементами множества C.
Соответствие q: B^C определяется отношениями зависимости и генерализации между основными и подчиненными прецедентами и не имеет прямого отношения к выявлению значимости рассматриваемых элементарными функций ИАС для классов пользователей. Алгоритм анализа данной графовой модели аналогичен изложенному, а результаты позволяют управлять приоритетами проекта ИАС в создании ее функциональности.
Совместное исследование формальной значимости в моделях качества и функций дает четкий ориентир при выборе составляющих системной архитектуры, направлений ее развития и опорных свойств. Для этого необходимо исследовать распределение формальной значимости только между примитивами конкретного качественного критерия, что позволит уточнить форму проявления данного критерия качества в ИАС. Так, особенности конфигурации свойства мобильности в ИАС включают необходимость создания кросс-платформенной компонентной системной архитектуры и исключают полную автономность приложений, развертываемых в ИАС, обуславливая их зависимость от базового ПО. Для улучшения баланса значимости в критерии мобильности необходимо уточнить требования с акцентом на значимость примитива структурированности. Указанное, наряду с анализом модели функций, позволило определить архитектуру ИАС как ярусную, включающую клиентский и представительский, а также ярусы функциональной логики и данных. Реализация критерия мобильности в ИАС состоит в выборе архитектурной платформы J2EE (Java2 Enterprise Edition), обеспечивающей независимость ИАС от аппаратно-программной платформы и позволяющей определять ее структуру на основе совместимых базовых компонент. Развертывание трех серверных ярусов будет обеспечено сервером приложений JBossAS 4.2.1 GA [17], который предоставляет контейнеры сервлетов и компонентов EJB3.0 (Enterprise Java Beans) и выполняется на базе процесса виртуальной машины Java, JVM (Java Virtual Machine), поставляемой в комплексе JDK (Java Development Kit) v5.0 [18]. Важным качественным критерием нами определена легкость применения. Доминирование примитивов устойчивости и коммуникабельности указывает на необходимость реализации робастных приложений на уровне функциональной логики, а также пользовательских интерфейсов, обеспечивающих простоту и удобство в работе конечного пользователя. Базовой технологией взаимодействия клиентского и представительского ярусов в ИАС нами выбрана AJAX (Asynchronous JavaScript and XML), использующая протоколы HTTP (Hypertext Transfer Protocol) и HTTPS (Hypertext Transfer Protocol over SSL (Secure Sockets Layer)) для организации передачи асинхронных сообщений между клиентом и сервером веб-приложения. AJAX опосредует взаимодействие обозревателя и веб-сервера (веб-контейнера на сервере приложений) использованием клиентского объекта XMLHTTPRequest,
управляемого кодом JavaScript, составляющим высококачественный пользовательский интерфейс с развитой событийной моделью, который обеспечивает непрерывность работы пользователя, отправляет запросы XMLHTTPRequest и обрабатывает отклики сервера в функциях обратного вызова [19]. Защищенность данного звена ИАС обеспечивается организационно-техническими мерами и изолированностью от Интернет посредством межсетевых экранов.
Обучающая и инструктивная документация востребована конечными пользователями как неотъемлемая часть ИАС. В критерии эффективности выделяется временная эффективность как примитив, наиболее различимый конечными пользователями. Критерий реализуется главным образом на уровне решений аппаратной платформы. Пользователи, обеспечивающие сопровождение ИАС, акцентируют значимость технической эксплуатационной документации и отмечают в критерии сопровождаемости ряд примитивов, максимально реализуемых при создании программной архитектуры.
Создание архитектуры включает моделирование логической структуры приложения на уровне классов и компонентов, развертываемых в контейнерах J2EE-сервера. Основным источником информации на этом этапе служит функциональная модель ИАС. Для реализации каждого функционального процесса в ИАС предусматривается отдельное программное приложение, развертываемое на четырех системных ярусах и предусматривающее распределение компонентов в рамках обобщенной структуры (рис 3).
Рис. 3. Обобщенная структура приложения в ИАС
Структура научного прототипа соответствует общей структурной модели отдельного приложения в ИАС. В качестве программной технологии, реализующей взаимодействие между клиентским и представительским уровнями на основе модели AJAX, выбирается технология GWT (Google Web Toolkit) [20], позволяющая разрабатывать AJAX-приложения на языке Java2 с последующей компиляцией в JavaScript и HTML для клиентского яруса и классы Java2, составляющих сервлеты, выполняемые в контейнере сервлетов на сервере приложений и обеспечивающие связь клиентского AJAX-интерфейса и части приложения на уровне функ-
циональной логики. Решение имеет ряд аналогов (ICEFaces и Ajax4JSF (AJAX for Java Server Faces), представляемых каркасом JBoss Seam 2.0, используемым в проекте ИАС в качестве интегрирующего средства) [21] и имеет преимущество перед ними, заключающееся в унификации цикла разработки на основе единой программной платформы и языка Java2. Главный процесс приложения обеспечивается сессионным EJB3.0 - компонентом с поддержкой состояний. По мере необходимости, он подключает дополнительные сессионные компоненты без поддержки состояний, расширяющие его функциональную логику, а также взаимодействует с компонентами-сущностями в ярусе данных для выполнения транзакций с постоянным хранилищем данных. Каждое приложение регистрирует все значимые программные события в системном журнале, необходимом для администрирования ИАС. Для этого сессионный компонент с поддержкой состояний использует службу передачи сообщений (JMS, Java Message Service) для установления асинхронной связи с журнализирующим EJB3.0-компонентом, управляемым сообщениями. При этом используется одна из очередей сообщений на сервере. Компоненты-сущности реализуют часть логики приложения, относящейся к обработке данных и взаимодействуют с базой данных (БД) через ряд последовательных интерфейсов, предоставляемых сервером приложений: диспетчер персистентности с функцией объектно-реляционного преобразователя (ORM, Object-Relational Mapping) - Hibernate, менеджер транзакций - JTA (Java Transaction API) и интерфейс соединений с БД - JDBC(Java DataBase Connectivity). Постоянное хранилище данных обеспечивается JDBC-совместимым сервером БД Oracle 10g XE.
Являясь центральным компонентом и прагматическим ядром ИАС, ЭС развертывается в рамках приложения аналогичной структуры. Классы оболочки ЭС Jess
7, реализующие продукционный решатель на основе Rete-алгоритма, а также графическую консоль и консоль командной строки, расширяются аналогичными классами API обработки нечеткой информации NRC FuzzyJ Toolkit, реализующем методы анализа нечетких множеств, методы нечеткой логики и лингвистические переменные Л. Заде [14, 22].
Программная реализация задачи вывода на основе нечетких фактов и посредством нечетких правил предполагает использование объектов классов-наследников, реализованных в NRC FuzzyJ Toolkit на основе базовых классов Jess7. Таким образом, подход к построению кода управления нечетким выводом предполагает использование объекта нечеткого решателя FuzzyRete вместо объекта Rete, представляющего решатель, реализованный в Jess7. Кроме того, объект Jess7 Console замещается аналогичным объектом FuzzyConsole с поддержкой обработки нечеткой информации. API ядра ЭС вызывается и используется сессионным компонентом с поддержкой состояний в приложении ЭС. Данные, составляющие основы контекста пациента, запрашиваются из БД и передаются в приложение посредством комплекса, функционирующего в ярусе данных. Для собственно формирования контекста пациента может быть вызван сессионный EJB3.0-компонент без поддержки состояний. Программная реализация базы знаний может включать текстовые файлы с кодом на языках CLIPS и JESS, а также представления нечеткой информации в формате, поддерживаемом NRC FuzzyJ Toolkit. На рис. 4 иллюстрируются две возможности использования функциональным приложением API ЭС, в ходе реализации которых NRC FuzzyJ Toolkit может быть использован автономно от Jess, равно как и средства Jess могут быть применены без привлечения поддержки нечеткой информации, однако целесообразно их совместное использование как слоистой системы.
Рис. 4. Модель организации API-ядра ЭС его интеграции в ИАС
Заключение
Внедрение предлагаемой информационной технологии и в ее рамках - новых и измененных функциональных процессов, программных продуктов и приложений, предназначенных для повышения эффективности и надежности клинико-диагностического процесса, позволит снизить ресурсоемкость процесса дифференциальной диагностики профессиональных нейроинтоксикаций для достижения организационных, экономических и медико-социальных эффектов, производимых совершенствованием процесса диагностики. Этап внедрения и испытательной эксплуатации информационно-аналитической системы диагностики и прогнозирования профессиональных нейроинтоксикаций потребует существенных усилий, присущих информатизации технологии традиционного ряда, однако помимо обозначенных выше прямых эффектов, будет положено основание для интеграции и развития новых прикладных медицинских сервисов. Решение совместимо с концепциями 80А (сервис-ориентированной архитектуры программного обеспечения), что определяет не только возможность расширения функциональности информационно-аналитической системы путем интеграции новых приложений и развертывания прикладных сервисов на их основе, по общему принципу, описанному нами, но и стандартность технологии управления сервисами информационно-аналитической системы.
ЛИТЕРАТУРА
1. Лахман О.Л., Колесов В.Г., Андреева О.К. и др. Течение энцефалопатии в отдаленном периоде профессиональной хронической ртутной интоксикации // Медицина труда и промышленная экология. 2003. № 3. С. 46 - 48.
2. Колесов, В.А. Мещерягин, О.Л. Лахман О.Л. и др. Психопатологические проявления отдаленного периоида профессиональной нейротнтоксикации // Журнал неврологии и психиатрии. 2005. № 1. С.25 - 29.
3. Гусев А.В., Романов Ф.А., Дунаев И.П., Воронин А.В. Медицинские информационные системы: монография. Петрозаводск: ПетрГУ, 2005. 404 с.
4. Ifeachor E. Neural networks & expert systems in medicine & healthcare. World Scientific Publishing Company, 1998. 350 p.
5. Barnett G.O., Cimino J.J., Hupp J.A., Hoffer E.P. Xplain D. An evolving diagnostic decision-support system // JAMA. 1987. Jul 3; 258(1). P. 67 - 74.
6. Система поддержки принятия диагностических решений DXPlain - описание проекта http:/www. lcs.mgh. harvard. edu/ projects /dxplain.html
7. Rebrova O., Kilikowski V., Olimpieva S., Ishanov O. Expert system and neural network for stroke diagnosis // International Journal of Information Technology and Intelligent Computing. 2006. V. 1. No. 2. P. 441 - 453.
8. Садыкова Е.В. Управление процессом постановки диагноза при помощи систем поддержки принятия решений врачом-клиницистом // Труды XVI Международной конференции «Новые информационные технологии в медицине, биологии, фармакологии и экологии». Украина. Ялта - Гурзуф, 2008. С. 74 - 75.
9. Глазатов М.В., Поваляев А.С., Пшеничников Д.Ю., Шульман Е.И. Предпосылки разработки и свойства медицинской информационной Intranet-системы // Сб. трудов Все-ройссийской конференции «Настоящее и будущее технологичной медицины». Ле-нинск-Кузнецкий, 2002. C. 19.
10. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. СПб.: Питер, 2002. 496 c.
11. Хавар Заман Ахмед, Кэри Е. Амри. Разработка корпоративных Java-приложений с использованием J2EE и UML: пер. с. англ. М.: Изд. дом «Вильямс», 2002. 272 с.
12. Орлов С.А. Технология разработки программного обеспечения. 3-е изд. СПб.: Питер, 2004. 527 с.
13. Официальный сайт оболочки для экспертных систем Jess (http://www.jessrules.com)
14. Orchard R. NRC Fuzzy Toolkit for the Java Platform, User's Guide, v.1.10, Institute for Information Technology National Research Council, Canada, September, 2006 (http://www.iit. nrc.ca/IR_public/fuzzy/fuzzyJToolkit2.html)
15. Боэм Б., Дж. Браун Дж., Каспар Х. и др. Характеристики качества программного обеспечения. М.: Мир, 1981. 200 с.
16. ЛипаевВ.В. Качество программного обеспечения. М.: Финансы и статистика, 1983.
17. Официальный сервер компании JBoss, подразделения компании Red Hat (http://www. jboss.com)
18. Официальный сервер компании Sun Microsystems, разработчика платформы Java2 (http://java.sun.com)
19. Статья с описанием технологии AJAX (http://www.adaptivepath.com/ideas/essays/ archives/000385.php)
20. Страница продукта GWT(Google Web Toolkit) от производителя (http://code.google. com/webtoolkit)
21. Seam 2.0 reference guide (http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/seam /Seam_Reference _Guide /index.html)
22. РыжовА.П. Элементы теории нечетких множеств и измерения нечеткости. М.: Диалог-МГУ, 1998. 116 с.
Иванов Антон Геннадьевич
Иркутский государственный технический университет
E-mail: thelogic@mail.ru
Дьякович Марина Пинхасовна
АФ-НИИ медицины труда и экологии человека
ГУ МЭ ВСНЦ СО РАМН (г. Ангарск).
E-mail: marik914@rambler.ru Поступила в редакцию 16 января 2009 г.
