1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Предметная область

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

     При анализе предметной области принято выделять три этапа:

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

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

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

Выделим в курсовой работе предметную область.

Предметная область – система отображения графика работы врачей в поликлинике.

Задача – информационная поддержка деятельности поликлиники.

Задачи:

1. управление поликлиникой в соответствии с принятыми нормами;
2. обеспечение показа актуальной информации;
3. контроль корректности информации;
4. решение возникающих проблем.

Проектируемая система должна осуществлять:

• учет поликлиник;
• учет специальностей в каждой поликлинике;
• учет докторов по каждой поликлинике;
• информационную поддержку по графику работы сотрудника.

Предметная область обладает следующими особенностями:

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

Необходимость автоматизированного решения для поликлиники включает:

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

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

1. системный администратор гостиницы;
2. сотрудник/доктор;
3. незарегистрированный пользователь.

Планируемые функции системы:

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

Имеется программные продукты и сайты по ведению информации по поликлиникам.

1.2 Анализ существующей на рынке программных продуктов

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

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

Одним из самым распространённым веб-приложением для поликлиник Беларуси является «талон бай» (рисунок 1.1). К особенностям системы можно отнести:

1. просмотр актуальной информации о поликлиниках по всей Беларуси;
2. просмотр специальностей врачей в поликлинике;
3. просмотр графика работы врачей;
4. возможность записи больного на прием;
5. онлайн регистрация клиентов поликлиники по месту прописки.

Рисунок 1.1 – Сайт «Талон бай»

2 ОПИСАНИЕ ОСНОВНЫХ ПРОЦЕССОВ ПРЕДМЕТНОЙ ОБЛАСТИ

2.1 Модель AS-IS

Построению модели AS-IS предшествовало обследование деятельности поликлиники. Упомянутое включало в себя ознакомление с процессом составления графика работы врачей в поликлинике.

На основании полученной при этом информации была построена модель AS-IS в нотации IDEF0, показанная на рисунке 2.1 и представляющая собой «снимок» существующего положения дел.

Рисунок 1.1 – Контекстная диаграмма «Деятельность поликлиники (AS-IS)»

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

- стрелки входа – данные о поликлинике, информация о докторе, данные о специальностях врачей, данные о графике работы врача;

- стрелки выхода – прием на работу, информация о графике работы врачей, данные о враче в поликлинике;

- стрелки управления – положения о деятельности поликлиники, правила задания графиков работы врачей, правила трудоустройства врачей;

Разработанная контекстная диаграмма была разбита на 4 процесса:

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

На рисунке 2.2 показана декомпозиция процесса «Деятельность поликлиники (AS-IS)».

Рисунок 2.2 – Декомпозиция диаграммы «Деятельность поликлиники (AS-IS)»

1. Модель TO-BE

Существенным недостатком модели AS-IS является:

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

Найденные в модели AS-IS недостатки исправляются путем создания модели TO-BE, то есть модели новой организации процессов деятельности поликлиники. Создание и внедрение системы приводит к изменению условий выполнения отдельных операций, структуры процессов и компании в целом. Это приводит к необходимости изменения системы правил, используемых в компании, модификации должностных инструкций сотрудников. Функциональная модель TO-BE позволяет уже на стадии проектирования будущей системы определить эти изменения. Применение функциональной модели TO-BE позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям.

С учетом сказанного была построена модель TO-BE, показанная на рисунках 2.3 – 2.4. На рисунке 2.3 представлен контекстный процесс «Деятельность поликлиник (TO-BE)».

Рисунок 2.3 – Контекстная диаграмма «Деятельность поликлиник (TO-BE)»

На рисунке 2.3 представлена декомпозиция контекстного процесса «Деятельность поликлиник (TO-BE)» на 4 процесса:

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

Все данные хранятся в единой базе данных поликлиник.

Рисунок 2.4 – Декомпозиция контекстной диаграммы «Деятельность поликлиник (TO-BE)»

3 СПЕЦИФИКАЦИЯ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ СИСТЕМЫ

Можно выделить следующие действующие лица:

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

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

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

Данная система включает в себя следующие варианты использования для администратора (рисунок 3.1):

1) аутентификация;

2) управление и просмотр информацией о пользователях системы:

- добавление информации о враче;

- блокировка врача;

- редактирование о враче;

- просмотр информации о выбранном враче;

- поиск врача по заданным параметрам;

- сортировка врачей.

3) управление информацией о графике работы:

- добавление графика работы для врача в базу данных;

- блокировка о графике работы из базы данных;

- редактирование информации о графике работы для врача;

4) управление информацией о поликлинике:

- регистрация новой поликлиники;

- блокировка поликлиники;

- редактирование поликлиники.

5) управление информацией о специальности:

- регистрация новой специальности;

- блокировка специальности;

- редактирование специальности.

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

Система включает в себя следующие варианты использования для зарегистрированного доктора (рисунок 3.2):

1) аутентификация;

2) управление и просмотр личной информации и изменение логина/пароля.

3) просмотр информации о личном графике работы.

4 ИНФОРМАЦИОННАЯ МОДЕЛЬ СИСТЕМЫ И ЕЁ ОПИСАНИЕ

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

• Проверка ролей: к какой роли (администратор, доктор или незарегистрированный пользователь) принадлежит пользователь сайта;
• Доктора на сайте может регистрировать только администратор сайта;
• Логин, телефон, адрес электронной почты должен быть уникальным;
• Пароль должен быть 6-12 символов;
• Незарегистрированный пользователь не имеет возможность доступа к страницам зарегистрированный пользователей.

Проверка на вводимые данные: проверка на вводимые символы, на заполненное поле, на содержание определённого количества символов, на уникальность логина и правильность ввода данных для поиска;

Данные поликлинике и специализации врача должные выбирается из списка доступных вариантов;

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

Выделим базовые сущности этой предметной области (таблица 4.1-4.6):

Пользователь системы. Сущность содержит: личный номер, ФИО, дату рождения, адрес прописки, кантатные данные, данные для входа в систему, комментарий.

Поликлиника. Сущность содержит: идентификационный номер поликлиники, название, адрес.

Специальность врача. Сущность содержит: номер специальности, личный номер пользователя.

Рабочий график. Сущность содержит: номер доктора, кабинет, признак первой смены, признак четного дня месяца.

Роль. Сущность содержит: номер роли, название.

Таблица 4.1 - Схема отношения Роль (Role)

Таблица 4.2 - Схема отношения Пользователь (User)

Таблица 4.3 - Схема отношения Поликлиника (Policlinic)

Таблица 4.4 - Схема отношения Специальность (Position)

Таблица 4.5 - Схема отношения Доктор (Personal)

 Таблица 4.6 - Схема отношения Расписание (Schedule)

Физическая модель данных показана на рисунке 4.1:

Рисунок 4.1 – Физическая модель данных

5 ОБОСНОВАНИЕ ВЫБОРА КОМПОНЕНТОВ И ТЕХНО-ЛОГИЙ ДЛЯ РЕАЛИЗАЦИИ КУРСОВОГО ПРОЕКТА

5.1 Назначение и описание компонентов программного обеспечения

Для разработки веб-приложений существует множество технологий и решений. Начиная с технологий по разработки сайтов с нуля, заканчивая системами управления содержимым.

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

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

Страницы, сгенерированные ASP.NET MVC, не содержат никаких данных View State, поэтому они могут быть в сотни килобайт меньше, чем обычные страницы, созданные при помощи ASP.NET Web Forms. Несмотря на современную широкополосную связь и быстрые подключения, эта экономия пропускной способности до сих пор чрезвычайно притягательна для конечных пользователей [9].

В качестве СУБД была выбрана SQL Server 2016, которая является не только быстрой и удобной в обращении, но и надежной.

SQL Server 2016 предоставляет графические инструменты, необходимые для проектирования, разработки, развертывания и администрирования реляционных баз данных, аналитических объектов, пакетов преобразования данных, топологий репликации, отчетов, серверов отчетов и серверов уведомлений. Кроме того, SQL Server 2016 включает программы командной строки, позволяющие выполнять из командной строки задачи администрирования. Основным инструментом администратора для взаимодействия с системой является среда управления SQL Server Management Studio.

SQL Server 2016 работает значительно быстрее прежних версий: на том же оборудовании запросы выполняются примерно на 25% быстрее, а при использовании некоторых новых средств SQL Server 2016 с обработкой в памяти выигрыш достигает 30 раз для OLTP-транзакций и 100 раз для запросов (данные Microsoft).

Разрабатываемое приложение является веб приложением «Сервер виртуальной поликлиники». Сайт обеспечивает простоту работу с данными, которые содержаться в базе данных. Приложение позволяет осуществлять добавление, редактирование, удаление, группировки, поиска разнообразной информации, а также служит средством ее просмотра и отображения. Для осуществления всех этих возможностей приложение было разработано в виде Web-приложения используя Framework ASP.NET MVC.

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

• уровень представления;
• уровень бизнес-логики;
• уровень доступа к данным.

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

Уровень доступа к данным, используется для взаимодействия с базой данных. Для работы с базой данных используется ORM (Object-relationalmapping - Объектно-реляционное отображение) Entity Framework. ADO.NET Entity Framewor объектно-ориентированная технология доступа к данным, является object-relational mapping (ORM) решением для .NET Framework от Microsoft. Предоставляет возможность взаимодействия с объектами как посредством LINQ в виде LINQ to Entities, так и с использованием Entity SQL. Для облегчения построения web-решений используется как ADO.NET Data Services, так и связка из Windows Communication Foundation и Windows Presentation Foundation, позволяющая строить многоуровневые приложения, реализуя один из шаблонов проектирования MVC, MVP или MVVM.

Имеется три подхода к работе с данными в Entity Framework: Database First, Model First, и Code First. Для реализации уровня доступа к данным был выбран подход Code First, т.к. он минимизирует работу с базой данных тем самым помогая сосредоточиться на разработке бизнес-логики приложения.

Подход Code First позволяет вне зависимости от наличия базы данных вручную написать код классов и свойств, соответствующих сущностям в базе и использовать этот код с Entity Framework без использования файла модели данных.

API доступа к данным, разработанное для Code First, основано на классе DbContext. API может быть использован также и в процессе разработки с подходами Database First и Model First.

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

При помощи Package Manager Console были установлены основные пакеты для работы, такие как Microsoft.AspNet.Mvc, Ninject, Moq, EntityFramework, Bootstrap, FontAwesome, JSON, jQuery.Unobtrusive.Validation и другие.

Так как было выбрано использование и Code First, то вначале были созданы классы на языке C#, которые обычно представляют одну таблицу базы данных. Данные классы ничем не отличаются от стандартных классов описываем при разработке приложений. Диаграмма созданных классов показаны ниже на рисунке 5.1.

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

Следующим этапом разработки является создание класса EFDbContext контекста базы данных. Класс контекста базы данных должен быть унаследован от стандартного класса Entity Framework – DbContext и созданного интерфейса IDbContext. Данные классы предоставляет EntityFramework для описания собственных классов управления базой данных. В классе контекста описываются все таблицы базы данных, действия по таблицам и связи таблицей между собой. Имя свойства указывает таблицу, а параметр типа результата DbSet – тип модели, который инфраструктура Entity Framework должна использовать для представления строк в этой таблице.

Чтобы предоставить классам бизнес-логики удобный доступ к данным просто через методы. Было решено создать сервисы для работы с объектами. Был создан базовый сервис интерфейс

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

Все основные операции были описаны в классе GenericService<T>, который представляет необходимое хранилище. Он реализует интерфейс IService<T> и использует экземпляр IdbContext для извлечения данных из базы посредством Entity Framework.

При разработке приложения использовалась система ASP.NET Identit. Для взаимодействия с базой данных в Microsoft.AspNet.Identity.EntityFramework определен класс IdentityDbContext. Это обычный контекст данных, производный от DbContext, который уже содержит свойства, необходимые для управления пользователями и ролями: свойства Users и Roles.

Непосредственное управление пользователями осуществляется с помощью класса UserManager<T>, которое находится в пространстве имен Microsoft.AspNet.Identity. Для управления ролями в ASP.NET Identity имеется класс RoleManager<T>, где T представляет реализацию интерфейса IRole.

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

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

На рисунке 5.2 приведена диаграмма последовательности с иллюстрацией сообщений для варианта использования «Аутентификация».

На рисунке 5.3 приведена диаграмма последовательности с иллюстрацией сообщений для варианта использования «Работа с докторами поликлиники»:

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

На рисунке 5.4 приведена диаграмма последовательности с иллюстрацией сообщений для варианта использования «Работа с графиком работы».

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

На рисунке 5.5 приведена диаграмма последовательности с иллюстрацией сообщений для варианта использования «Просмотр информации о графике работы выбранного доктора».

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

6 МОДЕЛИ ПРЕДСТАВЛЕНИЯ СИСТЕМЫ И ИХ ОПИСАНИЕ

Проектируемая сайт «Сервер виртуальной поликлиники» имеет страницы для 3 видов пользователей:

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

Поведение системы может быть представлена в виде следующей диаграмм состояний, которые показана на рисунках 6.1-6.4, блок-схема программы представлена на рисунке 6.5.

Рисунок 6.1 – Диаграмма состояния для незарегистрированных пользователей

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

Администратор может:

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

Рисунок 6.2 – Диаграмма состояния для администратора по управлению врачами

Рисунок 6.3 – Диаграмма состояния для администратора по управлению графиком работы

Зарегистрированный в системе доктор может:

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

Не зарегистрированный пользователь может:

• Авторизоваться в системе;
• Просматривать данные поликлиник;
• Просматривать информацию по врачам в поликлиниках.

Рисунок 6.4 – Диаграмма состояния для просмотра графика работы врача

Блок-схема системы показана на рисунке 6.5. Блок-схема приложения включает в себя все основные действия, которые доступны на веб сайте.

Рисунок 6.5 – Блок-схема приложения

7 ОПИСАНИЕ ПРИМЕНЕНИЯ ПАТТЕРНОВ ПРОЕКТИРОВАНИЯ

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

В разрабатываемом приложении используется паттерн .Net MVC 5.

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

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

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

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

Рисунок 7.1 – Используемые контроллеры, Представления и Модели в приложении

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

Допустим, у нас есть одно подключение к базе данных MS SQL Server. Однако, что если в какой-то момент времени мы захотим сменить подключение с MS SQL на другое - например, к бд MySQL или MongoDB. При стандартном подходе даже в небольшом приложении, осуществляющем выборку, добавление, изменение и удаление данных, нам бы пришлось сделать большое количество изменений. Либо в процессе работы программы в зависимости от разных условий мы хотим использовать два разных подключения. Таким образом, репозиторий добавляет программе гибкость при работе с разными типами подключений.

Например, определен класс:

Имеется следующий класс контекста данных:

Интерфейс репозитория, обобщенный интерфейс, так как он более гибкий. 

Создана реализацию для работы с MS SQL Server:

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

8 РУКОВОДСТВО ПО РАЗВЕРТЫВАНИЮ СИСТЕМЫ

Для нормального функционирования клиентского приложения требуется: операционная система Window 7/8/10, 100 Мб свободного места на жестком диске, клавиатура, мышь, Microsoft.NET Framework 4.0, настроенная БД SQL Server 2016 или более новая, Micrisoft Visual Studio 2017 или более новая.

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

После того как настройка базы данных завершена, опубликуем веб-приложение ASP.NET MVC на веб-сервер IIS. Для этого сконфигурируем веб-сервер. Для этого откроем средство администрирования IIS: зайдем в Панель управления, затем выберем Администрирование->Диспетчер служб IIS. И нам откроется консоль управления IIS:

Будем размещать свой сайт в узле по умолчанию (в моем случае это Default Web Site). И для этого вначале создадим в каталоге этого узла папку для нашего приложения. По умолчанию каталогом для стандартного веб-узла является каталог C:\inetpub\wwwroot. Перейдем в нее и создадим в нем папку BookStore, которая будет содержать наше приложение.

Теперь нажмем правой кнопкой мыши на имя узла по умолчанию и выберем в появившемся меню пункт Добавить приложение:

Рисунок 8.1 – Добавление приложения

В появившемся окне введем соответствующие настройки (в качестве физического пути приложения созданный выше каталог):

Рисунок 8.2 – Настройка пути

Перейдем к приложению в Visual Studio. Нажмем правой кнопкой на название проекта и в появившемся меню выберем Publish:

Рисунок 8.3 – Публикация через Visual Studio

Перед нами откроется мастер публикации, который предложит нам пройти несколько этапов. Если не одного профиля не определено, то создадим, нажав на ссылку New... и выбрав какое-нибудь название.После создания профиля нажмем на Next и перейдем к следующему этапу - Connection. На этом этапе для опции Publish Method выберем File System.

Рисунок 8.4 – Настройка публикации сайта

Для опции Target Location определим физический путь к каталогу нашего сайта. А для поля Destination URL указываем url, по которому будет доступно приложение, а именно http://localhost/HostWeb.

После установки всех свойств жмем на кнопку Publish. После этого в Visual Studio в окне Output студия выдаст сводку об успешности или неуспешности публикации.

9 РЕЗУЛЬТАТЫ ТЕСТИРОВАНИЯ РАЗРАБОТАННОЙ СИСТЕМЫ, И ОЦЕНКА ВЫПОЛНЕНИЯ ЗАДАЧ

При работе с программой пользователь будет выдаваться сообщения об ошибках, если были введены не верные данные или пользователь не имеет доступа к страницам. Примеры сообщений об ошибках показаны на рисунках 9.1 – 9.6:

Рисунок 9.1 – Сообщение при авторизации пользователя при не верном вводе данных

Рисунок 9.2 – Сообщения, если пользователю не доступна страница

Рисунок 9.3 – Сообщения, если введенные данные не уникальны в системе

Рисунок 9.4 – Сообщения, если введенные данные являются не верными

Рисунок 9.5 – Сообщения при не заполнении данных

При загрузки web-сайта «Поликлиники» доступны следующие страницы для работы:

1. Главная страница сайта (рисунок 9.6) на которой можно выбрать интересующую поликлинику (рисунок 9.7) и просмотреть график работы врача (9.8);
2. Страница входа на сайт (рисунок 9.9);

Рисунок 9.6 – Главная страница сайта

Рисунок 9.7 – Страница просмотра информации по выбранной поликлинике

Рисунок 9.8 – Страница просмотра графика работы

Рисунок 9.9 – Страница авторизации

Если пользователь является администратором, то ему доступны страницы, которые можно выбрать на главной странице для администратора (рисунок 9.10):

• Страница настроек ролей (рисунок 9.11);
• Страница управления параметрами докторов (рисунок 9.12);
• Страница управления параметрами поликлиник (рисунок 9.13);
• Страница управления параметрами расписания врачей (рисунок 9.14);
• Страница управления параметрами специальностей врачей (рисунок 9.15);
• Страница настроек данных для входа (рисунок 9.16).

Рисунок 9.10 – Главная страница администратора

 Рисунок 9.11 – Страница настроек ролей

Рисунок 9.12 – Страница управления докторами 

Рисунок 9.13 – Страница управления параметрами поликлиник

 Рисунок 9.14 – Страница управления параметрами расписаний врачей

Рисунок 9.15 – Страница управления параметрами специальностей врачей

Рисунок 9.16 – Страница личных настроек

Если пользователь является доктором, то ему доступны страницы:

• Просмотр личного расписания (страница 9.17);
• Настройка личных данных (9.18).

Рисунок 9.17 – Страница просмотра личного расписания

Рисунок 9.18 – Личные данные сотрудника

10 СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Кунву Ли. Основы САПР. ПИТЕР, 2004.
2. Кондаков А.И. САПР технологических процессов и производств. ACADEMA, 2007.
3. Буч, Г. Язык UML:  Руководство пользователя /   Г. Буч, Д. Рамбо,  А. Джекобсон; пер. с англ. – М.: ДМК, 2000. – 432 с.
4. Рамодин Д. Купи себе немножечко CASE. – Режим доступа: www.caseclub.ru/articles/ rose1.html, свободный. – Загл. с экрана. – Яз. рус. 20.05.2018.
5. Автоматизация процессного управления и документооборота: TO-BE модель – Режим доступа: http://www.piter-soft.ru/automation/more/glossary/process/to-be-model/, свободный - Загл. с экрана. – Яз. рус. Дата доступа 20.05.2018.
6. 4 Трофимов С.А., CASE-технологии: практическая работы в Rational Rose. Изд. 2-е. - М.: Бином-Пресс, 2002 г. - 288 с.: ил. Дата доступа 20.05.2018.
7. Петкович Д., Microsoft SQL Server™ 2012. Руководство для начинающих: Пер. с англ. — СПб.: БХВ-Петербург, 2013. — 816 с.: ил.
8. Сандерсон, Стивен. ASP.NET MVC Framework с примерами на C# для профиссионалов. : Пер. с англ – М.: ООО «И. Д. Вильямс». 2010. – 560 с.: ил.
9. Фримен А., Сандерсон С., ASP.NET MVC 4 Framework с примерами на C# 5.0 для профессионалов. 4-е изд. : Пер. с англ – М.: ООО «И. Д. Вильямс». 2014. – 668 с.: ил.