Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.cplire.ru/rus/telemed/rpr/reportIII.doc Дата изменения: Tue Dec 17 18:56:03 2002 Дата индексирования: Tue Oct 2 09:03:14 2012 Кодировка: koi8-r Поисковые слова: п п п п п п п п п п п п п п п п п п

Научно-исследовательский центр электронных диагностических систем "ЭЛДИС"
РАН (НИЦ ЭЛДИС РАН)





ОТЧЕТ


по государственному контракту
от 1 февраля 2002 г. ? 37.029.11.0028


по теме «Методы передачи медицинской информации, включая графическую, в
телекоммуникационных сетях телемедицины» федеральной целевой-научно-
технической программы «Исследования и разработки по приоритетным
направлениям развития науки и техники» на 2002-2006 годы, Блок 1, Раздел -
«Информационные технологии и электроника» (на 2002 год).


(промежуточный, 3 этап)





















Москва 2002 г.


На III этапе выполнения проета основная работа была связана с вопросами
разработки структуры словарей и шаблонов форм представления данных. Как
было отмечено ранее, процесс разработки современных стандартов заключается
не в фиксации существующих, сложившихся способов структурирования
медицинской информации, а представляет собой систематический процесс
проработки всего круга связанных вопросов телемедицины - от фазы выработки
требований до фазы реализации. При этом методология разработки
функциональных стандартов должна принимать во внимание и такие аспекты, как
совместимость, качество, время реализации стандарта, наличие в сети
разнообразных платформ и приложений, языковых различий. Методология
систематического процесса разработки функциональных стандартов представляет
собой типичный цикл разработки сложного информационного проекта, состоящего
из фазы выработки требований (ТЗ) - фазы анализа - фазы реализации. На
данном этапе основное внимание уделялось вопросам фазы анализа, более
конкретно - интерфейсам с пользователями системы.

На сегодняшний день одной из самых перспективных технологий анализа больших
проектам (не только в области медицинских стандартов) является технология
UML (универсальный язык моделирования). Диаграммы использования (UseCase)
UML идеальны с точки зрения прояснения границ области применимости,
интерфейсов и функциональности соответствующих стандартов. Кроме того,
UseCase-диаграммы являются эффективным способом наглядного графического
средства документирования стандартов.

На основе UseCase-модели в рамках объектно-ориентированного подхода UML
позволяет выделить основные блоки - классы объектов - для формирования
моделей сообщений. Эти диаграммы классов в совокупности, в иерархическом
порядке составляют: базовую информационную модель - информационную модель
области медицины - информационную модель сообщений. Дальнейшая работа
состоит в уточнении и детализации в рамках соответствующего стандарта
содержания объектов-классов и их функционального назначения.

Достоинствами проектирования с использованием методологии и нотации UML
являются следующие ее особенности и характерные черты:

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

. Модели UML допускают декомпозицию на более мелкие, легче анализируемые
подсистемы

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

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



Интерфейс пользователей системы функциональных стандартов


Требования к интерфейсам пользователей системы функциональных стандартов
оформляются в виде диаграмм использования (Use Case diagrams) на основе
анализа задач, которые должна система решать. С использованием этой техники
все заинтересованные стороны - эксперты, аналитики, разработчики формируют
первоначальное представление о системе в терминах ее границ и
фунциональности системы - перечисления всей совокупности задач, решаемых
непосредственно данной системой. Данное представление призвано четко
разделить пользователей системы - внешних по отношению к системе агентов и
решаемые системой для них задачи. В этом контексте можно выделить три
основные проблемы:


. Идентификация пользователей- внешних по отношению к границам системы
агентов (врачи, операторы, другие информационные системы, БД и т.д.).


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


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


В диаграммах использования UML концепция пользователя формируется на основе
понятия актера (Actor) и его специфической роли (role) в контексте способов
использования системы. Это сделано по той причине, что реальные
пользователи могут по-разному в разных обстоятельствах использовать
систему. Поэтому, для систематизации вариантов использования введено
абстрактное понятие актера и его роли. Таким образом, реальные пользователи
могут выступать в разных по отношению к системе ролях и за каждым
абстрактным актерам могут стоять разные пользователи.


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


Взаимодействия между актерами и прецендентами на диаграммах использования
отображаются направленными или ненаправленными линиями - коммуникативными
ассоциациями (Associations). Если ассоциация является направленной, то ее
направление определяется инициатором взаимодействия. Ассоциациями также
могут быть связаны преценденты (но не актеры!), что впрочем имеет место
только во вполне определенных (типизированных) ситуациях.











Одним из результатов анализа системы функциональных стандартов является тот
факт, что недостаточно простой декларации о их структуре и содержании. При
динамическом обмене сообщениями (с заданной структурой и определенным
содержанием), необходимо разработать, предусмотреть дополнительные
требования к процедурам, выполняемым при получении/отправке сообщений
системы - определить ответственности сторон. Совокупность ответственностей
в контексте всей системы определяет в конечном счете требования
совместимости приложений с системой функциональных стандартов.


Поскольку основное внимание уделяется разработке системы сообщений, а не
поведению приложений, на начальном этапе Use Case анализа разрабатывается
виртуальная система, в которой актерами являются абстрактные медицинские
приложения способные получать/отправлять сообщения. Задачи виртуальной
системы при этом - компановка и отправление соответствующих сообщений.


Для реализации данного формализма специально разработана концепция ролей
приложений (Application Roles). С точки зрения диаграмм использования роли
приложений являются актерами в системе сообщений. Однако, в сравнении с
общим случаем, роли приложений являются актерами со своим собственным
набором ответственности.

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







Сопровождение Use-Case диаграммам UML дополнительной документацией.

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

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

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


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

Как отмечено выше, продуктивность (формального) анализа использования будет
выше, если ему предшествует процесс неформализованного описания. Подобноое
описание может бать результатом обсуждения требований к системе с
заинтересованными специалистами и экспертами. По завершени анализа должна
быть сформирована модель использования, основной целью которой является
определение предметной области, т.е. тех сообщений, которые будет
поддерживать система.
Формальный процесс анализа использования начинается с структурирования
вариантов использования "верхнего уровня" и заканчивается определением
недетализируемых далее вариантов использования "нижнего (leaf-level)
уровня". На диаграммах использования связанные варианты могут
группироваться в системы / подсистемы / пакеты / категории. Разные варианты
могут быть связаны типизированными ассоциациями (стереотипы <>,
<>, <>). Важно подчеркнуть, что декомпозиция сверху-вниз
осуществляется не по принципу уточнения функциональности, а на основе
архитектурной декомпозиции. Поэтому, как правило, варианты использования
нижнего уровня ассоциируются с полными циклами изменения состояний
сущностных классов RIM модели. Это соображение вместе с анализом
неформализованного описания облегчает выявление вариантов использования
нижнего уровня.
Каждый вариант использования должен быть подробно документирован при помощи
комментариев в виде произвольного текста, структурированных описаний
действий актеров (Actor Actions), ответов системы (System Responsibilities)
и нескольких поясняющих диаграм - активности, взаимодействия и т.д.
Варианты использования нижнего уровня кроме того должны содержать описание
инициализирующих событий (initiating trigger), формальную спецификацию
содержания сообщения, взимодействующих с ними ролей приложений и
ответственности при получении сообщений.
На основе модели использования в дальнейшем (на фазе анализа) определяются
кандидаты в объекты (классы) концептуальной модели, их взаимодействие и
кооперация.

Рукомендации к оформлению требований к системе сообщений документация
включает следующие документы:


Описание предметной области


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


Use Case диаграммы


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



Руководитель проекта
Д.ф.м.н. Обухов Ю.В.
-----------------------
актер

прецендент

Запись на прием к врачу

регистратура

врач

Выписка из истории болезни

система

Соотношение между реальной и виртуальной системами сообщений

регистратура

врач

Реальная системама

Система регистрации больных

Запись на прием к врачу

Система приема больных

Список на прием к врачу

подсистема сообщений

подсистема сообщений

подсистема сообщений системы регистрации больных

Виртуальная система сообщений HL7

Список больных

прилож. в роли отправит.

прилож. в роли получат.

подсистема сообщений системы приема больных

Виртуальная система сообщений HL7

Запрос списка больных

прилож. в роли отправит.

прилож. в роли получат.

Список больных

Запрос списка больных