Пояснительная записка (1208558), страница 6

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

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

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

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

Рисунок 3.5 – Контекстная диаграмма автоматов

Рассмотрим более подробно подсистемы, которые становятся доступны после успешной аутентификации.

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

Рисунок 3.6 – Диаграмма автоматов для Подсистемы «Стоматолог»

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

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

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

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

• выдача временного разрешения на просмотр рентгеновских снимков.

3.2 Модель анализа

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

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

Построение этой модели необходимо:

• для выявления внутренней архитектуры (определения подсистем и основных классов);

• для поиска альтернативных вариантов реализации системы (подсистем) и выбора основного;

• для уточнения всех требований (функциональных и нефункциональных).

3.2.1 Диаграмма классов анализа

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

Существует три вида классов анализа:

• граничный;

• управляющий;

• сущности.

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

Рисунок 3.8 – Диаграмма классов анализа

3.2.2 Диаграммы последовательности

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

Для проектируемой информационной системы было построено две диаграммы последовательностей, рассмотрим первую из них «Создание снимка» (рис.3.9).

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

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

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

3.3 Модель проектирования

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

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

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

• уточнения требований;

• определения детализированных алгоритмов работы системы в целом и ее отдельных элементов.

Модель проектирования представляется диаграммами классов и диаграммами деятельности.

3.3.1 Диаграммы классов

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

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

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

• точка зрения спецификации – диаграмма классов применяется при проектировании информационных систем;

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

Понятие «класс» присутствует и в объектно-ориентированных языках программирования, то есть между классами UML и программными классами есть соответствие, являющееся основой для автоматической генерации программных кодов или для выполнения реинжиниринга. Каждый класс имеет имя, атрибуты и операции. С точки зрения структурного подхода, атрибуты – это переменные, а операции (методы) – это функции, описанные в теле класса. Классы могут иметь логическую и физическую реализации. Логические диаграммы классов в отличие от физических, строятся без привязки к языкам программирования.

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

Таблица 3.1 – Временный доступ (TimeAccess)

Таблица 3.2 – Врачи (DoctorInfo)

Таблица 3.3 – Каталог снимков (PictureDB)

Так как проектируемая система дорабатывает уже существующую, то при описании БД приходится опираться на реальные каталоги данных. По каждому пациенту есть папка, где хранится несколько файлов в разных форматах (inf, dex,dat,ini ), но использоваться из них будут только два: *.inf-содержит информацию по врачу и пациенту; *.dex – содержит сам рентгеновский снимок. Так как структура описывается каталогом, для представления ее на диаграмме классов БД применяются пакеты, также на логической диаграмме при помощи примечания обозначено к каким именно данным этой структуры происходит обращение. Данные о врачах и временном доступе также содержаться в отдельных файлах, учитывая размеры предполагаемых таблиц и базы данных, нецелесообразно использовать дополнительное программное обеспечение, для их хранения.

Каждая из диаграмм будет представлена в двух реализациях логической и физической. На первой диаграмме (рис.3.11) представлена логическое отображение БД, где отражены классы, соответствующие таблицам БД, атрибуты классов – полям таблиц БД. А также указаны связи между ними.

Р исунок 3.11 – Логическая диаграмма классов БД

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

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