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

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

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

На основе логической диаграммы классов БД разработана физическая диаграмма классов БД (Рис.3.12).

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

На рис. 3.13 рассмотрим логическую диаграмму классов, отражающую классы, которые включают в себя поля и методы. Так же на диаграмме представлен абстрактный класс Таблица (Table DB), от которого наследуют методы все классы диаграммы, соответствующие классам-сущностям на диаграмме класса анализа, класс «Соединение с БД» (Connection to BD) со своими атрибутами и методами. Кроме того, на диаграмме представлен класс для шифрования и расшифрования информации.

Рисунок 3.13 – Логическая диаграмма классов приложения

На основе логической диаграммы классов (рис. 3.13) разработаем физическую диаграмму классов (рис.3.14).

Рисунок 3.14 – Физическая диаграмма классов приложения

3.3.2 Диаграммы деятельности

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

Диаграммы деятельности удобно применять для визуализации алгоритмов, по которым работают операции классов.

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

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

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

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

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

Рисунок 3.16 – Диаграмма деятельности «Просмотр снимка»

3.4 Модель реализации

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

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

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

3.4.1 Диаграмма компонентов

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

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

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

• спецификации исполняемого варианта программной системы;

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

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

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

В языке UML выделяют три вида компонентов:

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

• рабочие продукты – это файлы с исходными текстами программ;

• исполнения, представляющие собой исполняемые модули (файлы с расширением ехе).

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

1. «file» – любой файл, кроме таблицы:

1. «executable» – программа (исполняемый файл);

2. «library» – статическая или динамическая библиотека;

3. «source» – файл с исходным текстом программы;

4. «document» – остальные файлы (например, файл справки);

1. «table» – таблица базы данных.

На рисунке 3.19, отображена диаграмма компонентов для разрабатываемой информационной системы. Клиентское приложение построено на взаимодействии форм, представленных стереотипом «form», и файлов с исходным текстом программы. Серверная часть представлена в общем виде как взаимодействие таблиц. Всю систему можно представить, как взаимодействие нескольких исполняемых файлов:

• DEXray.exe – приложение на компьютере рентгенолога, позволяющее создавать, просматривать и выдавать снимки на материальном носителе.

• DEXimage.exe – приложение стоматолога для просмотра снимков.

• BIOmetr.exe – приложение для шифрования и разграничения доступа к данным пациентов.

• Admin.exe – приложение для управления BIOmetr.exe, к которому имеет доступ администратор. Позволяет добавлять, удалять врачей из системы, предоставлять временный доступ, делать резервную копию базы данных.

Рисунок 3.19 – Диаграмма компонентов

3.4.2 Диаграмма развертывания

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

Главными элементами диаграммы являются узлы, связанные информационными путями. Узел (node) – это то, что может содержать программное обеспечение. Узлы бывают двух типов:

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

• среда выполнения – это программное обеспечение, которое само может включать другое программное обеспечение, например, операционную систему.

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

Диаграммы развертывания разрабатываются совместно системными аналитиками, сетевыми инженерами и системными техниками.

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

Рисунок 3.20 – Диаграмма развертывания

3.5 Руководство пользователя

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

3.5.1 Руководство администратора

Для получения доступа врачом стоматологом к снимкам, он сначала должен быть прописан в системе. Для этого используется модуль администратора (рис.3.21)

Рисунок 3.21 – Модуль администратора

Для того чтобы, стоматолог мог просмотреть данные чужого пациента, администратор использует форму «Временный доступ» (рис. 3.22). Он вносит данные о времени доступа, враче и пациенте, доступ к данным которого стоматолог хочет получить. После внесения информации происходит проверка: на наличие такого врача в системе (рис. 3.23).

Рисунок 3.22 – Форма временного доступа

Рисунок 3.23 – Сообщение об ошибке

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

Рисунок 3.24 – Форма добавления врача

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

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

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