Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 5)

Окончание таблицы 2.3

3 Разработка компенсирующих мер

Из таблицы 2.3 видно, что для реализации мер ЗНИ.4 и ЗИС.21 требуются дополнительные (компенсирующие меры). Одной из специализированных медицинских программ, использующихся в поликлинике, является Dexis. Версия программы, установленной в стоматологической поликлинике №25 передает данные по локальной сети в незашифрованном виде и доступ к ним может получить любой врач.

Таким образом, можно рассмотреть реальную ситуацию, когда пациент приходит к стоматологу, тот направляет его на снимок, который делает рентгенолог, затем этот снимок отправляется на сервер и хранится там до момента просмотра его стоматологом. Соответственно каждый конкретный врач-стоматолог должен иметь доступ только к данным своих пациентов. Но, из-за отсутствия алгоритмов разграничения доступа к данным просмотреть их сможет любой имеющих доступ к АРМу. С помощью Secret Net Studio можно ограничить доступ того или иного пользователя к каталогам и назначить определенные права, но учитывая тот факт, что за день к рентгенологу обращаются не один и не два пациента назначить конкретному врачу-стоматологу доступ только к данным его пациента не представляется возможным.

На сайте производителя есть информация о новой версии (Dexis 9), позволяющей шифровать данные передаваемые базе данных и обратно, но обновление до текущей версии не бесплатно, кроме того нужно докупить модуль DEXsecurity программы для разграничения доступа. С обновлением программы придется обновить и базу данных. Кроме того, стоит учитывать стоимость установки, обучение персонала и время простоя, установки, так как ни один врач не сможет обратиться к снимкам своих пациентов, ровно, как и рентгенолог создать новый.

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

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

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

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

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

Для обеспечения безопасности данных на всех этапах их обработки, а именно:

• направление на снимок;

• создание снимка;

• просмотр снимка;

• выдача снимка на материальном носителе;

• создание резервной копии БД снимков.

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

• модуль администратора, позволяющий добавлять и удалять врачей из системы, предоставлять им временный доступ к файлам;

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

Проектирование информационной системы выполняется на основе объектно-ориентированного подхода и языка UML (Unified modeling language).

3.1 Модель вариантов использования

Для проектирования информационной системы будет использован объектно-ориентированный подход и язык UML (Unified modeling language). Модель, на которой формируются требования, – это модель вариантов использования. Она отображает существенные функциональные требования к системе в форме, удобной для всех заинтересованных лиц. Под существенными требованиями понимаются требования, реализация которых принесет пользователям ощутимый и значимый результат.

Построение данной модели помогает в таких вопросах как:

- выявление внешнего окружения, взаимодействующего с системой;

- определение основных функций системы (вариантов использования) с возможным уточнением технологии их выполнения;

- уточнение нефункциональных требований.

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

• диаграмма вариантов использования;

• диаграмма автоматов;

• диаграмма классов анализа;

• диаграмма последовательности;

• диаграмма коммуникации.

3.1.1 Диаграммы вариантов использования

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

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

В ходе анализа проектируемой ИС было определено несколько основных актеров:

• стоматолог;

• рентгенолог;

• администратор;

• служба;

• клиент.

Также были выделены следующие варианты использования:

• регистрация нового врача;

• выдача временного разрешения на использование снимка;

• удаление врача из базы данных;

• создание резервной копии базы данных снимков;

• просмотр снимка;

• направление на снимок;

• создание снимка клиента.

На основании полученных данных была построена контекстная диаграмма, описывающая общую схему взаимодействия актеров в пределах ИС (рис.3.1).

Рисунок 3.1 – Контекстная диаграмма вариантов использования

На рис.3.2 представлена декомпозиция варианта использования «Выдача результата на материальном носителе». Данная диаграмма является уточнением контекстной диаграммы для конкретного варианта использования. На этой диаграмме взаимодействуют 3 актера: служба, рентгенолог и клиент.

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

Рисунок 3.2 – Диаграмма декомпозиции варианта использования «Выдача информации на материальном носителе»

Далее рассмотрим рис.3.3 и диаграмму декомпозиции «Создание снимка клиента». На данной диаграмме представлены три актора: служба, клиент и рентгенолог.

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

Рисунок 3.3 – Диаграмма декомпозиции варианта использования «Создание снимка клиента»

Теперь можно перейти к диаграмме декомпозиции «Просмотр снимка» (рис.3.4), на ней взаимодействуют врач и служба.

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

Рисунок 3.4 – Диаграмма декомпозиции варианта использования «Создание снимка клиента»

3.1.2 Диаграммы автоматов

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

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

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

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

Характеристики

Список файлов ВКР