Разработка программного комплекса построения оптимального маршрута обхода пациентов
Математическая модель алгоритма с модификацией муравьиной колонии. Выбор аппаратных и программных средств для разработки программы. Особенность построения оптимального маршрута обхода пациентов. Характеристика тестирования и отладки данного проекта.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 17.11.2017 |
| Размер файла | 1,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Таблица 2.2 Описание методов обработки запросов
|
Запрос |
Метод |
Действие |
|
|
GET /worker/ |
getWorker |
Возвращает распределение рабочего графика врача на текущую неделю. Формат данных: массив моделей worker |
|
|
GET /worker/ |
addWorker |
Добавляет рабочий график на заданный пользователем промежуток из двух дат (время и дата начала и конца) |
|
|
Запрос |
Метод |
Действие |
|
|
PUT /worker/ |
changeWorker |
Изменяет временной промежуток рабочего графика |
|
|
DELETE /worker |
deleteWorker |
Удаляет рабочий график |
|
|
GET /worker/all |
getDoctors |
Возвращает массив работающих врачей на текущий день, у которых занятость (estimated_time) не превышает конец минус начало рабочего графика |
|
|
GET /worker/all/:date |
infoWorkers |
Возвращает информацию о рабочих графиках врачей и их выполненных заявках, начиная с указанной даты в параметре запроса date |
|
|
GET /record/all |
getRecords |
Возвращает список записей пациентов на текущий (сегодняшний) рабочий график врача |
|
|
GET /record |
getRecord |
Возвращает текущую заявку пациента |
|
|
POST /record |
addRecord |
Регистрирует заявку пациента |
|
|
PUT /record |
changeRecor |
Изменяет данные текущей заявки |
|
|
DELETE /record |
delRecord |
Удаляет заявку |
|
|
GET /user |
getUser |
Возвращает модель текущего авторизированного пользователя |
|
|
PUT /user |
changeUser |
Изменяет данные пользователя |
|
|
GET /user/allUsers |
getUsers |
Возвращает список пользователей |
|
|
PUT /user/setRole |
setRole |
Изменяет роль пользователя |
|
|
DELETE /user |
delUser |
Удаляет пользователя |
|
|
POST auth/register |
register |
Регистрирует нового пользователя |
|
|
POST /auth |
authenticate |
Открывает сессию пользователя и возвращает JWT токен |
|
|
POST /auth/check |
check |
Возвращает токен JWT если сессия пользователя открыта |
Стоит отметить, что при создании, удалении или изменении (в случае смены врача) заявки, запускается алгоритм оптимизации маршрута, так как соответственно происходит изменение у врачасписка пациентов.
Интерфейс.Работу с запросами серверной стороны непосредственно берет на себя интерфейс программного средства и предоставляет пользователю следующие возможности:
1. Авторизация пользователей:
· Форма входа:
§ Адрес электронной почты
§ Пароль
· Форма регистрации:
§ Адрес электронной почты (уникальный)
§ Пароль
§ Подтверждение пароля
§ ФИО
§ Дата рождения
§ Адрес проживания
§ Номер полиса (уникальный)
2. Разделы пользователя - пациент:
· Форма для создания либо отмены заявки
§ Поле с возможность выбора работающего врача
§ Поле комментария
· Редактирование профиля
3. Разделы пользователя - врач:
· Календарь - планировщик рабочего времени
§ Добавление, редактирование и удаление распределения времени на текущий и последующие дни
· Сводка с панелями:
§ Таблица заявок в порядке оптимального маршрута
§ Текущий пункт назначения
§ Статистика по выполненным и ожидающим заявкам.
· Отчеты
· Редактирование профиля
4. Разделы пользователя - администратор:
· Сбор общей статистики врачей и их пациентов:
§ Календарь с распределением рабочего времени каждого врача и количество пациентов в течение дня
· Управление учетными записями пользователей:
§ Изменение ролей пользователей
§ Удаление пользователей
· Редактирование профиля
2.4 Тестирование и отладкапрограммного комплекса
Тестирование является одним из этапов жизненного цикла программного средства. Оно заключается в многократном выполнении программы с целью выявления ошибок и результатов не соответствующих требованиям. Основная цель тестирования - обнаружить как можно большее число ошибок. Если при тестировании не было найдено ошибок, то его результат называется неудачным. Существует несколько методов тестирования программного средства. Они делятся на статическое, детерминированное и стохастическое.
При статическом тестировании программный код не выполняется, а анализируется либо вручную, либо с помощью специальных инструментальных средств. Цель анализа - выявить ошибки и проблемы на ранних стадиях разработки.
Детерминированное тестирование требует многократного выполнения программы с использованием специально подобранных тестовых наборов данных.
Тестирование стохастическим методом подразумевает использование в качестве исходных данных множества случайных величин с соответствующими распределениями. Для сравнения полученных результатов используется также распределение случайных величин. Данное тестирование применяется в основном при тестировании сложных программных комплексов, для которых набор детерминированных тестов имеет громадную мощность.
Для проведения тестирования необходимо разработать тестовый набор данных. Разработка тестовых наборов основывается на двух основных подходах: структурное тестирование (тестирование по стратегии белого ящика) и функциональное тестирование (тестирование по стратегии черного ящика).
Тестирование белого ящика заключается в детальном изучении текста программы и проектировании таких наборов входных данных, которые основаны на одном из четырех критериев:
1. Покрытие операторов. Выбирается тестовый набор данных, который вызывает выполнение каждого оператора программы ровно один раз
2. Покрытие решений. Требуется создать тестовый набор данных, в котором в каждом узле ветвления, должен быть обеспечен проход по веткам «истина-ложь» как минимум один раз.
3. Покрытие условий. Для каждого узла ветвления содержащего более одного условия, необходимо разработать число тестовых наборов данных, достаточное, чтобы возможные результаты каждого условия в решении выполнялись как минимум один раз.
4. Комбинаторное покрытие условий требует создания такого числа тестовых наборов данных, чтобы все возможные комбинации результатов условия в каждом решении выполнялись как минимум один раз.
Задача функционального тестирования проверить соответствие реализованных функций требованиям, а также определить способность программного средства решать поставленные задачи [6].Тестирование черного ящика является тестированием по входу и выходу, то есть тестирование происходит непосредственно через интерфейс программного средства без доступа к его коду.
При разработке тестов важно учитывать, что правильно выбранный тест должен уменьшать число других тестов, разрабатываемых для обеспечения качества программного средства. Для разработки тестов используются методы формирования тестовых наборов. Среди них это методы эквивалентного разбиения и анализ причинно-следственных связей.
Анализ причинно-следственных связей. Спецификация разбивается на рабочие участки, то есть в ней определяются множество причин и следствий. Под причиной считается класс эквивалентности или отдельное входное условие, а под следствием выходное условие. Затем на основе анализа смыслового содержания перебираются всевозможные комбинации причин и определяются следствия для них. Далее таблица снабжается примечаниями, которые задают ограничения и описывают комбинации невозможные из-за синтаксических и внешних спецификаций. Единственным недостатком данного подхода это плохое исследование граничных условий.
Метод эквивалентного разбиения заключается, в разбиении на конечное число групп (классы эквивалентности) по каждому параметру область всех возможных наборов входных данных. Затем по принципу обнаружения схожих ошибок происходит объединение наборов данных. Соответственно, в случае если набор какого-либо класса обнаружит ошибку, то тогда все остальные тесты этого класса эквивалентности также обнаружат данную ошибку. Выделение классов эквивалентности опирается на следующие правила:
· если некоторый параметр может принимать значения в заданном интервале, то выделяется один правильный класс, соответствующий этому интервалу и два неправильных;
· если условие описывает множество входных значений, то для каждого значения выделяется по одному правильному классу эквивалентности и один неправильный;
· если условие описывает конкретное значение, то определяется один неправильный и один правильный классы эквивалентности.
При тестировании разработанногопрограммного комплекса в рамках выпускной квалификационной работы, преимущественным выбором является метод эквивалентных разбиений, по той причине, что он позволяет контролировать каждую комбинацию исходных данных и ее результаты. Как правило, при разработке программного средства места, где можно найти наибольшее число возможных ошибок оказываются интерфейс для работы с данными (сохранение, редактирование)иалгоритмы, решающие сложные задачи. Исходя из этого, необходимо провести тестирование следующих компонентов веб-комплекса:
· форма регистрации пользователей
· форма создания заявки пациента
· доступность разделов интерфейса по ролям пользователей
· алгоритм оптимизации маршрута по заявкам пациентов
Для разработки тестовых наборов данных были построены классы эквивалентности, представленные в таблице 2.3:
Таблица 2.3 Классы эквивалентности
|
Объект тестирования |
Правильный класс эквивалентности |
Неправильные класс эквивалентности |
|
|
Форма регистрации пользователей |
|||
|
Электронная почта |
Формат строки соответствует шаблону: <имя>@<доменное имя>. |
Не соответствует шаблону: <имя>@<доменное имя>. |
|
|
Пароль |
Длина не менее 6 символов и не более 255 |
Длина менее 6 символов или более 255 |
|
|
Подтверждение пароля |
Совпадает с полем «Пароль» |
Не совпадает с полем «Пароль» |
|
|
Фамилия Имя Отчество |
Формат строки соответствует шаблону: <Фамилия><Имя> [Отчество] Длина строки не более 255 символов |
Длина строки более 255 символов или не соответствует шаблону: <Фамилия><Имя> [Отчество] |
|
|
Адрес |
Обязательно для заполнения Длина строки не более 255 символов |
Не заполнено или длина строки более 255 символов |
|
|
Телефон |
Обязательно для заполнения Формат строки соответствует шаблону: +X(XXX)XXX-XX-XX Содержит только цифры |
Не заполнено или не соответствует шаблону: +X(XXX)XXX-XX-XX Или содержит недопустимые символы |
|
|
Создание/отмена заявки пациента |
|||
|
Выбор врача |
Врач выбран |
Врач не выбран |
|
|
Комментарий |
Длина строки не более 255 символов |
Длина строки более 255 символов |
|
|
Оптимизация маршрута врача при создании/отмены заявки |
Маршрут врача оптимизируется |
Маршрут врача не оптимизируется |
|
|
Доступность разделов интерфейса по ролям |
|||
|
Врач |
Доступны разделы: «Сводка», «Планирование», «Маршрут» Недоступны разделы: «Запись», «Управление» |
Доступны один или несколько разделов: «Запись», «Управление» Недоступен один или несколько разделов: «Сводка», «Планирование», «Маршрут» |
|
|
Пациент |
Доступны разделы: «Запись» Недоступны разделы: «Планирование», «Маршрут», «Сводка», «Управление», «Статистика» |
Доступны один или несколько разделов: «Сводка», «Планирование», «Маршрут», «Управление», «Статистика» Недоступен один или несколько разделов: «Запись» |
|
|
Администратор |
Доступны разделы: «Управление», «Статистика» Недоступны разделы: «Планирование», «Маршрут», «Сводка», «Запись» |
Доступны один или несколько разделов: «Планирование», «Маршрут», «Сводка», «Запись» Недоступен один или несколько разделов: «Управление», «Статистика» |
Далее, на основании построенных классов эквивалентности, разработаны тестовые наборы данных представление в таблице 2.4:
Таблица 2.4 Результаты тестирования
|
№ |
Входныеданные |
Предполагаемые выходные данные |
|
|
Форма регистрации пользователей |
|||
|
1 |
Электронная почта: dmitry@mail.ru Пароль: 123456 Подтверждение пароля: 123456 ФИО: Тишкин Дмитрий Сергеевич Адрес:. Богданова 48к1, кв. 42 Телефон: +7(999)999-99-99 |
Верно Верно Верно Верно Верно Верно Данные сохранены, пользователь зарегистрирован. |
|
|
2 |
Электронная почта: dmitrymaulru Пароль: 12345 Подтверждение пароля: 123 ФИО: Адрес: Телефон: +7(999)999-99-99-999999 |
Неверный адрес почты Длина пароля должна быть минимум 6 символов Пароли не совпадают Поле «ФИО» обязательно для заполнения Поле «Адрес» обязательно для заполнения Неверный номер телефона Ошибка, неверный ввод данных |
|
|
3 |
Электронная почта: dmitrymaulru Пароль: (более 255 символов) Подтверждение пароля: (строка 255 символов) ФИО: (более 255 символов) Адрес: (более 255 символов) Телефон: +7(999)TEL-TT-TT |
Неверный адрес почты Длина пароля должна быть не более 255 символов Пароли совпадают Поле «ФИО» не должно превышать 255 символов Поле «Адрес» не должно превышать 255 символов Неверный номер телефона Ошибка, неверный ввод данных |
|
|
Создание/отмена заявки пациента |
|||
|
4 |
Выбор врача: (выбран врач из списка) Комментарий: высокая температура |
Верно Верно Заявка зарегистрирована Маршрут выбранного врача перестроен и оптимизирован |
|
|
5 |
Выбор врача: Комментарий: (более 255 символов) |
Необходимо выбрать врача Комментарий не должен превышать 255 символов Ошибка. Заявка не зарегистрирована |
|
|
Доступные разделы интерфейса по ролям |
|||
|
6 |
Авторизация под пользователем с ролью «Пациент». Переход в разделы: «Запись» «Сводка» «Планирование» «Маршрут» «Управление» «Статистика» |
Доступен Недоступен Недоступен Недоступен Недоступен Недоступен |
|
|
7 |
Авторизация под пользователем с ролью «Врач». Переход в разделы: «Запись» «Сводка» «Планирование» «Маршрут» «Управление» «Статистика» |
Недоступен Доступен Доступен Доступен Недоступен Недоступен |
|
|
8 |
Авторизация под пользователем с ролью «Администратор» Переход в разделы: «Запись» «Сводка» «Планирование» «Маршрут» «Управление» «Статистика» |
Недоступен Недоступен Недоступен Недоступен Доступен Доступен |
В ходе тестирования были выявлены различные ошибки. В таблице 2.5 представлен анализ выявленных ошибок и их исправление.
Таблица 2.5 Анализ выявленных ошибок
|
№ |
Ошибка |
Тип ошибки |
Коррекция |
|
|
1 |
elem = matrix.elements[j].rows[i] |
Ошибка манипулирования данными |
elem = matrix.rows[i].elements[j] |
|
|
2 |
Record.findOne {id_patient: user.id} |
Ошибка манипулирования данными |
Record.findOne {id_patient: req.user.get "id"} |
|
|
3 |
bestAnt.ribs.feromon = @p * feromon + sum |
Ошибка манипулирования данными |
bestAnt.ribs[reb].feromon = @p * feromon + sum |
|
|
4 |
Math.random() * (min - max) + min |
Ошибка вычисления |
Math.random() * (max - min) + min |
|
|
5 |
sum = (@q / ants[item].timePath) |
Ошибка вычисления |
sum += (@q / ants[item].timePath) |
|
|
6 |
if req.body.email or req.body.password or req.body.login or req.body.address or req.body.latLng or req.body.phone or |
Ошибка логики |
if not req.body.email or not req.body.password or not req.body.login or not req.body.address or not req.body.latLng or not req.body.phone or not |
|
|
7 |
if (currentVarisnt j) and not (j in path) and (iisntitem.was) |
Ошибка логики |
if (currentVar is j) and not (j in path) and (i is item.was) |
|
|
8 |
if elem.timePath>bestAnt.timePath then bestAnt = elem |
Ошибка логики |
if elem.timePath<bestAnt.timePath then bestAnt = elem |
|
|
9 |
elem = arr.filter (item) -> rand <= item.min and rand >= item.max |
Ошибка логики |
elem = arr.filter (item) -> rand >= item.min and rand <= item.max |
|
|
10 |
if worker._doc.patients.length< 4 |
Ошибка логики |
if worker._doc.patients.length< 3 |
После отладки и исправления найденных ошибок было проведено завершающее тестирование с целью проверки корректности исправлений. В результате тестирования, программное средство показало стабильную работу, а именно:
· Регистрация пользователей осуществляется без ошибок и с проверкой правильности данных.
· Обработка заявок выполняется успешно. Маршрут врача перестраивается при появлении новых пациентов
· Достигается безопасность за счет запрета на переход и получения данных из недоступных разделов пользователю
2.5 Инструкция пользователю
Представленное руководство описывает основные функции, правила и инструкции, с которыми необходимо ознакомиться для использования данного программного средства.
Минимальные требования для полноценной работы с веб-комплексом:
· Процессор с частотой 1 ГГц
· Объем оперативной памяти 512 МБ
· Свободное дисковое пространство 100 МБ
· Интернет соединение - 256 Кбит/с
Состав программного обеспечения:
· БраузерGoogleChrome42илиSafari10 (а также мобильные версии)
· Операционная система - iOS 7, Android 5, WindowsVistaили MacOSLion
Веб комплекс построения оптимального маршрута обхода пациентов направлен на 3 группы пользователей, каждой из которых предоставляются необходимые средства для работы в системе:
· Пациент - возможность создавать и отменять ранее созданный вызов врача, оставлять комментарий с причиной вызова
· Врач - распределять рабочий график обхода, просматривать на карте текущие заявки пациентов, отмечать выполнение заявок в таблице ожидающих пациентов
· Администратор - изменять роли пользователей, назначать врачей и новых администраторов, наблюдать за статистикой и сравнивать сходимость фактического и оптимизированного времени потраченного врачами на обход пациентов
Навигация. На рисунке 2.10 отображены все разделы для навигации по веб-комплексу для каждой группы пользователей.
Рисунок 2.10. Навигация по веб-комплексу
Авторизация - предлагает вход или регистрацию для посетителей веб-комплекса.
Профиль - включает раздел «Редактирование», где пользователь может изменить личные данные (почту, пароль, адрес, ФИО и так далее).
Запись - раздел предоставляет форму создания заявки на вызов врача. В выпадающем списке (рисунок 2.11) пользователь может выбрать, работающего на текущий день, врача с подходящим временем прибытия на дом.
Рисунок 2.11. Список врачей
Далее заполнив поле «Комментарий» пользователю необходимо нажать кнопку «Записаться» для подтверждения заявки. Для отмены заявки нажать кнопку «Отменить».
Сводка - раздел доступный врачам. Отображает панель с диаграммой по текущим и выполненным заявкам. На панели «Ожидающие» таблица ожидающих пациентов, каждая строка таблицы относится к конкретному пациенту и имеет кнопку «Завершить». Когда пациент осмотрен, необходимо нажать на данную кнопку, чтобы заявка перешла в статус «Выполненная» и пункт назначения сменился на следующего пациента.
Планирование - планировщик рабочего графика врача. Представляет собой таблицу, где столбцы - дни текущей недели, строки часы дня. Для задания периода времени рабочего дня необходимо кликнуть или протянуть, зажав курсор от одной ячейки до другой.
Маршрут - раздел с картой, на которой маркерами отмечены заявки пациентов и текущее местоположение. Раздел в особенности применим, для врачей, которые мало знакомы с местностью.
Статистика - раздел отображает таблицу с завершенными периодами врачей обхода пациентов, где идет сравнение оптимального времени и затраченного фактического.
Управление - раздел управления пользователями, предоставляет возможность задавать и изменять роли пользователей.
В данной главе выпускной квалификационной работыбыли рассмотрены и определены программные и аппаратные средства, с помощью которых был реализован программный комплекс построения оптимального маршрута обхода пациентов на основе веб-технологий. Серверная часть программного средства разработана на основе Nodeв архитектуре REST. Клиентская часть построена как одностраничное приложение (SPA) с помощьюJavaScriptфреймворкаReact. В роле базы данных применяется не реляционная СУБД MongoDB. Затем были разработаны архитектура веб-комплекса и алгоритм оптимизации маршрута обхода пациентов, а также приведено подробное описание компонентов программного средства и их назначение. После завершения разработки системы было проведено тестирование методом эквивалентного разбиения с последующей отладкой и повторным завершающим тестированием, результат которого не показал дополнительныхошибок, что подтвердило возможность полноценного использования программного средства. Таким образом, программное средство готово для проведения дальнейших испытаний и оценки надежности и эффективности.
ГЛАВА 3. ОЦЕНКА ТЕХНИКО-ЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ РАЗРАБОТАННОГО ПРОГРАММНОГО КОМПЛЕКСА ПОСТРОЕНИЯ ОПТИМАЛЬНОГО МАРШРУТА ОБХОДА ПАЦИЕНТОВ
3.1 Испытания программного комплекса
В предыдущей главе по результатам тестирования и последующей отладкипрограммное средство продемонстрировало стабильную работу. Однако избавление от внешних дефектов не позволяет утверждать об общей стабильности веб-комплекса, в силу того, что для ее подтверждения необходимо проведение достаточного количество испытаний. Проведение испытаний даст возможность выявить неточности в реализации и установить степень надежности программного средства. Описанные ниже эксперименты испытания также направлены на проверку соответствия разработанного веб-комплекса поставленной задаче в первой главе:
1. Регистрация пользователей
2. Назначение пользователю роли «Врач»
3. Распределение рабочего графика врача
4. Просмотр работающих врачей в выпадающем списке и создание записей пациентовна врача
5. Просмотр раздела «Маршрут»
6. Просмотр списка ожидающих пациентов в разделе «Сводка»
7. Отмена заявки одним из пациентов
8. Просмотр изменения маршрута по причине отмены заявки
9. Перевод всех ожидающих заявок в статус «Выполненные»
10. Просмотр статистики сравнения оптимального и фактического маршрута
По итогам 10прогонов программного средства в сумме было выявлено и исправлено35 ошибок. В результате последнего прогона на основании полученных результатов ошибок не обнаружено:
1. Регистрация пользователей прошла успешно. В случае неверных данных программное средство блокировало завершение регистрации.
2. Изменение роли пользователя с «Пациента» на «Врач» прошло успешно. У пользователя также изменились доступные ему разделы.
3. Распределение графика врача прошло без ошибок
4. Врач появился в списке работающих на текущий день врачей. Создание записей пациентов - успешно
5. В разделе «Маршрут» отображены маркеры в соответствии с оптимизацией маршрута
6. Список ожидающих пациентов отображается корректно
7. Отмена заявки пациента прошла успешно, запущена оптимизация маршрута
8. После перестроения маршрута, пользователю «Врач» пришло уведомление об изменении
9. При завершении заявок пациентов ошибок не выявлено
10. Так как завершение заявок выполнено в срок, и фактически затраченное время не превосходит оптимальное - в разделе статистика нарушений не выявлено.
Таким образом, программное средство показало стабильную работу и соответствие с поставленной задачей. Следовательно, веб-комплекс готов к оценке качественных показателей.
3.2 Оценка качественных показателей разработанногопрограммного комплекса
Оценка качественных показателей позволяет определить пригодность программного обеспечения удовлетворять заданные потребности в соответствии с его назначением. Для определения оценочных характеристик качества существуетмеждународный стандарт ISO 9126 (ГОСТ Р ИСО / МЭК 9126-93) - «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению». Данный стандарт выделяет 6 качественных характеристик программного обеспечения:
1. Функциональность - характеризует соответствие функциональных возможностей программного обеспечения требуемой пользовательской функциональности
2. Надежность - свойство программного средства обеспечивать работоспособность за определенный период времени
3. Практичность -характеристика определяющая сложность понимания, изучения и использования программного средства
4. Эффективность - соотношение между уровнем качества функциональности программного средства и используемыми ресурсами в установленных условиях
5. Сопровождаемость - расположенность программного средства к изменениям (модификациям)
6. Мобильность - способность программного средства адаптироваться при изменении аппаратно-операционной среды
Среди всех характеристик качества программных средств на первом месте стоит надежность, по той причине, что к ней наблюдается в первую очередь устойчивый рост требованийсо стороны клиента. Даже не смотря на то, что программное средство после разработки проходит через несколько этапов тестирования, согласно требованиям международной системы контроля качества возможно появление недочетов в надежности продукта.
Для определения надежности применяются модели, которые можно разделить на две группы: аналитические и эмпирические модели.
Эмпирические модели основываются на анализе структурных особенностей программного средства. Модели, относящиеся к данной группе, как правило, не всегда дают конечных результатов показателей надежности, однако их использование на этапе проектирования программного средства, полезно в плане прогнозирования требуемых ресурсов и сроков завершения проекта.
Аналитические модели позволяют рассчитать качественные показатели надежности, основываясь на данных определенных в процессе тестирования. Применение аналитической модели надежности программного средства состоит из четырех шагов:
1. определение предложений связанных с процедурой тестирования программного средства;
2. выбор аналитической модели, основанной на предположениях о процедуре тестирования;
3. выбор параметров моделей, используя полученные данные;
4. расчет показателей надежности по модели.
Аналитические модели в свою очередь разделяются на статические и динамические. Статические модели в основном отличаются от динамических, тем, что в них не учитывается время появления отказов в процессе тестирования. Тогда как в динамических моделях поведение программы рассматривается во времени.
Для определения показателя надежности веб-комплекса для построения оптимального маршрута обода пациентов была выбрана модель Шумана.Данная модель относится к динамическим моделям дискретного времени. Преимуществом такого вида моделей является тестирование во времени, так как такой подход дает более точное представление о работе программного средства во время испытаний.
Применение модели Шумана заключается в тестировании в несколько этапов, где каждый этап представляет собой выполнение программного средства на комплексе тестовых данных. В процессе этапа регистрируются выявленные ошибки, затем на основании собранных данных на следующем этапе применяется модель Шумана для расчета показателей надежности и только после этого исправляются обнаруженные ошибки на предыдущем этапе. Модель Шумана строится с учетом следующих ограничений:
1. постоянное число операторов программы;
2. уменьшение ошибок по мере их исправления;
3. по сумме исправленных ошибок можно судить об оставшихся;
4. отказы программы пропорциональны числу ошибок.
Далее представлена более подробная модель Шумана для оценки надежности программного средства.
В процессе тестирования формируется таблица, в которой фиксируются данные о количестве ошибок и времени прогона для каждого этапа. Сначала вычисляется общее время всех этапов :
,
где - число безуспешных этапов; -время безуспешного этапа; - число успешных этапов; -время успешных этапов.
Далее предполагая, что интенсивность появления ошибок постоянна, то ее можно вычислить как число ошибок в единицу времени:
,
где - число ошибок на этапе ; - число успешных этапов.
Время безотказной работы программного средства вычисляется как:
,
Затем выбирая два различных момента тестирования и , выбор которых соответствуетусловию , гдеудельное число ошибок в момент времени рассчитывается по формуле (3.4):
,
И сопоставляя формулу (3.3) современем безотказной работы программного средства:
,
где -количество ошибок; - общее число операторов программного средства; -число ошибок за время тестирования на одну команду; где - время работы без отказов.
Откуда и :
,
,
Далее, вычисляя отношения (3.6) и (3.7), можно найти общее число ошибок программного средства до начала тестирования:
,
Подставляя в (3.6), коэффициент пропорциональности равен:
,
Получив неизвестные и , надежность программы, рассчитывается по формуле:
,
Оценка надежности разработанного программного средства в рамках выпускной квалификационной работы. Общее постоянное число операторов веб-комплекса составляет приблизительно 13200. В процессе испытания были обнаружены данные об ошибках и времени прогонов, которые представлены в таблице 3.1
Таблица 3.1 Данные об испытаниях ПС
|
a |
b |
||||||||||
|
№ этапа |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|
|
Количество ошибок |
5 |
7 |
3 |
4 |
6 |
4 |
3 |
2 |
1 |
0 |
|
|
Время прогона, мин. |
15 |
15 |
9 |
7 |
13 |
7 |
10 |
9 |
9 |
5 |
Выбирая две точки таким образом, чтобы число ошибок на интервале (1, a)было меньше чем на интервале (a, b), за точку aвозьмем этап номер 3, а за точку b- этап номер 9. Тогда удельные числа ошибок на данных интервалах будут равны соответственно:
;
;
Время тестирования на интервалах (1, a) и (a, b) равно:
; ;
Отсюда найдем интенсивность появления ошибок для двух интервалов:
;
;
Тогда число имеющихся ошибок до начала тестирования равно:
,
Коэффициент пропорциональности имеет значение:
,
Рассчитывая надежность программного средства, пусть t = 250 мин:
,
В итоге, за 250 минут вероятность безотказной работы примерно равна 0,99, что является высокимпоказателем надежности разработанного программного средства.
Во время проведения остальных показателей качества, установлены веса этих показателей (, так что , и соответствующие оценки в диапазоне от 0 до 1, исходя из следующего:
· 0 - свойство в программном средстве присутствует, но качество его не приемлемо;
· 0,5-1 - свойство в программном средстве присутствует и обладает приемлемым качеством;
· 1 - свойство в программном средстве присутствует и обладает очень высоким качеством.
В таблице 3.2 представлены качественные показатели в соответствие с их весами и оценками, установленными в ходе испытаний:
Таблица 3.2 Качественные показатели
|
Показатели качества |
Экспертная оценка (вес) |
Оценка, установленная экспериментом |
|
|
Портируемость |
0,2 |
0,8 |
|
|
Сопровождаемость |
0,1 |
1 |
|
|
Надежность |
0,3 |
0,99 |
|
|
Эффективность |
0,1 |
0,9 |
|
|
Функциональность |
0,2 |
0,8 |
|
|
Практичность |
0,1 |
1 |
Исходя из полученных данных, иерархическая взвешенная сумма всех весов равна:
,
На диаграмме (рисунок 3.1) визуально представлены качественные характеристики:
Рисунок 3.1. Диаграмма качественных показателей
Подводя итог данного раздела, испытания программного средства в соответствие с международным стандартом ISO 9126 отразили положительные результаты качественных показателей, авысокая надежность, в свою очередь, подтверждает стабильность и отказоустойчивость. Однако чтобы окончательно сделать вывод о том, что веб-комплекс готов к внедрению и вводу в эксплуатацию, необходимо рассчитать его экономическую эффективность.Об этом и пойдет речь в следующем параграфе.
3.3 Оценка экономической эффективности
Расчет экономической эффективности разработки программного средства заключается в сопоставлении затрат на решение задачи ручным методом решения с затратами, связанными с ее автоматизацией. К основным показателям экономической эффективности относится экономический эффект. Экономический эффект это результат после внедрения, в данном случае, программного продукта, выраженный в стоимостной форме, в виде экономии от его осуществления
Для расчета экономической эффективности веб-комплекса для оптимизации маршрута обхода пациентов, необходимо определить затраты по базовому и проектному варианту. Расчет производится с помощью следующих формул:
Абсолютное снижение трудовых затрат :
,
где - трудовые затраты по базовому варианту; - трудовые затраты по проектному варианту.
Коэффициент относительного снижения трудовых затрат :
,
Индекс снижения трудовых затрат при повышении производительности труда:
,
Абсолютное снижение стоимостных затрат :
,
где - стоимостные затраты по базовому варианту; - стоимостные затраты по проектному варианту;
Коэффициент относительного снижения стоимости затрат:
,
Индекс повышения производительности труда:
,
Годовой экономический эффект:
,
где - нормативный коэффициент эффективности капитальных вложений (значение коэффициента принято брать как 0,15); - капитальные вложения при переходе от базового варианта к проектному.
Капитальные вложения при переходе от базового варианта к проектному
,
где - капитальные затраты по базовому варианту; - капитальные затраты по проектному варианту;
Капитальные затраты по проектному варианту:
,
где - часовая оплата программиста; - число программистов; - время на разработку программного средства в часах.
Коэффициент эффективности :
,
Срок окупаемости затрат на внедрение программного средства:
,
Затраты до внедрения программного обеспечения. Регистратура и участковые врачи-терапевты каждый день при поступлении вызовов составляют журнал заявок до определенного времени. Прием заявок осуществляется в течение 4 часов. По факту вызова заполняется талон амбулаторного пациента. Затем прием заявок заканчивается, и врач начинает обход пациентов. Для каждого пациента выполняется фиксация посещения (заполнение медицинской и отчетной документации). После обхода заполняется отчет обслуженных и не обслуженных вызовов. Как правило, маршрут обхода происходит без оптимизации. Таким образом, имеются следующие временные затраты представленные в таблице 3.3:
Таблица 3.3 Временные затраты базового варианта
|
Задача |
Временные Затраты (мин.) |
|
|
Прием заявок (регистратура) |
240 |
|
|
Заполнение талонов пациентов (регистратура) |
20 |
|
|
Заполнение отчета обслуживания пациентов (врач-терапевт) |
20 |
|
|
Фиксации результатов посещения пациента (врач-терапевт) |
36 |
|
|
Средний путь и осмотр одного пациента (врач-терапевт) |
28 |
За час в среднем врач успевает посетить 2 пациента. Для каждого пациента выполняется фиксация результатов (заполнение медицинской и отчетной документации). Обход пациентов происходит в среднем 6 часов (зависит от объема пациентов и поликлиники), каждый день. Тогда временные затраты на фиксацию результатов составляют 24 минут. На осмотр и путь - 324 минуты. Таким образом, расчет временных затрат составляет:
,
,
Средняя заработная плата работника регистратуры составляет 35000 рублей в месяц, врача - 60000 рублей в месяц. Почасовая оплата составляет 198 и 341 рублей соответственно. Тогда стоимостные затраты по базовому варианту:
,
Затраты после внедрения программного обеспечения. После внедрения наблюдается снижение трудовых затрат врача-терапевта, а обязанности регистратуры берет на себя программное средство. Временные затраты представлены в таблице 3.4:
Таблица 3.4 Временные затраты проектного варианта
|
Задача |
Временные Затраты (мин.) |
|
|
Прием заявок (регистратура) |
0 |
|
|
Заполнение талонов пациентов (регистратура) |
0 |
|
|
Заполнение отчета обслуживания пациентов (врач-терапевт) |
1 |
|
|
Фиксации результатов посещения пациента (врач-терапевт) |
1 |
|
|
Путь и осмотр одного пациента (врач-терапевт) |
18 |
Так как программное средство позволяет оптимизировать маршрут, в результате уменьшилось и среднее время на путь, и осмотр пациентов. Расчеты на трудовые затраты по проектному варианту:
,
Абсолютное снижение трудовых затрат:
,
Коэффициент относительного снижения затрат:
,
Повышение производительности труда:
,
Для расчета стоимостных показателей, рассчитываются стоимостные затраты за год. Пусть стоимость часа работы сервера составляет 15 рублей. Коэффициент накладных ресурсов 0,1, тогда:
,
Данные расчеты отражают стоимостные затраты на проведение требуемой работы по выполнению основных процессов.
Абсолютное снижение стоимостных затрат:
,
Коэффициента относительного снижения трудовых затрат:
,
Тогда повышение производительности труда:
,
С учетом того, что обязанности регистратуры исключаются, трудовые затраты для данной задачи равны 0, тогда стоимостные затраты по проектному варианту:
,
Полученные результаты представлены в таблице 3.5:
Таблица 3.5 Результаты экономической эффективности
|
Затраты по базовому варианту |
Затраты по проектному варианту |
Абсолютное изменение затрат |
Коэффициент изменения затрат |
Индекс изменения затрат |
||
|
Трудоемкость |
2021 |
832 |
1189 |
59% |
2.4 |
|
|
Стоимость |
559317 |
324563,2 |
234753,8 |
42% |
1.7 |
Исходя из полученных данных, можно рассчитать показатели эффективности веб-комплекса для построения маршрута обхода пациентов. Для расчета годового экономического эффекта необходимо рассчитать капитальные затраты на внедрение. Трудоемкость разработки программного средства включает:
1. Изучение поставленной задачи: 8 часов
2. Проектирование программы: 25 часов
3. Кодирование программы: 200 часов
4. Тестирование программы: 125 часов
5. Документирование программы 100 часов
,
Количество разработчиков - 1. Следовательно, затраты труда на разработку программного средства составили 458 часов. Почасовая оплата разработчика составляет 350 рублей, тогда затраты на внедрение равны:
,
Годовой экономический эффект после внедрения программного обеспечения равен:
,
Расчетный коэффициент эффективности:
,
Срок окупаемости затрат на внедрение проекта:
,
Исходя из полученных результатов, внедрение веб-комплекса для оптимизации маршрута обхода пациентов, позволяет заметно снизить трудовые и стоимостные затраты. Срок окупаемости после внедрения программного средства составляет 8 месяцев и 6 дней.
В данной главе были проведены испытания программного средства, результаты которого подтвердили соответствие поставленной задачи в первой главе и показали готовность к работе веб-комплекса для оптимизации маршрута обхода пациентов. Затем была произведена оценка качественных показателей, которая показала положительные результаты. Для вычисления надежности программного средства использовалась модель Шумана. В результате применения данной модели был получен уровень надежности 0,99, что говорит о достаточно высокой степени безотказной работы веб-комплекса. И последним этапом был произведен расчет экономической эффективности, который показал, что использование программного обеспечения разработанного в рамках выпускной квалификационной работы, позволяет снизить примерно в половину финансовые и трудовые затраты, а срок окупаемости от внедрения, на основании проведённых расчетов, составляет 8 месяцев и 6 дней.
ЗАКЛЮЧЕНИЕ
В результате работы в рамках ВКР, был реализован веб-комплекс построения оптимального маршрута обхода пациентов.Разработанный веб-комплекс позволяет в режиме реального времени оптимизировать маршрут, тем самым появляется возможность обрабатывать и получать новые заявки уже в процессе обхода. Автоматизация процесса обработки вызовов, заменяет рутинную работу регистратуры с приемом заявок по телефону. Также программное средство формирует отчеты по результатам работы, что сокращает время на документацию. Преимуществом разработанного веб-комплекса, в сравнении с другими программными средствами, является работа с пешими маршрутами. Почти все системы не берут во внимание пешеходов, однако они не уступают в степени важности автомобильным маршрутам, особенно если задача решается в области медицины. Также, несмотря на узкую направленность, серверная часть веб-комплекса разработана как независимый модуль, который может быть встроен в другие системы и использован в других областях, где необходима оптимизация и построение маршрутов.
В первой главе проведено исследование среди существующих алгоритмов оптимизации, способных решить наиболее подходящим образом задачу построения и оптимизации маршрута обхода пациентов. В результате исследования был выбран муравьиный алгоритм с модификацией муравьиной колонии, который особенно отличился по скорости и точности оптимизации.Затем был проведен обзор существующих систем, что позволилопредусмотреть устранение выявленных недостатковв постановке задачи. И в заключение главы была составлена подробная математическая модель муравьиного алгоритма с примером ее использования.
Во второй главебыло принято решение реализации программного средства как веб-комплекса, с целью увеличения доступности и адаптивности под разные платформы. На основании чего были установлены аппаратные требования, выбраны необходимые программные инструменты и спроектирована архитектура. После разработки алгоритма, его работа на примерных входных данных сразу же показала положительный результат, а именно оптимизация и построение маршрута через заданные точки заметно сократила длину пути, что подтвердило его функциональность. По окончанию разработки было представлено подробное описание структуры базы данных, модулей, процедур и интерфейса прикладного программирования для серверной части веб-комплекса. Далее были разработаны тестовые данные с помощью классов эквивалентности и проведено функциональное тестирование, которое помогло выявить и исправить ошибки. И затем были приведены инструкция пользователю и системные требования для использования программного средства.
В последней главе выпускной квалификационной работы была проведена оценка технико-экономических показателей разработанного веб-комплекса для построения и оптимизации маршрута обхода пациентов. Перед оценкой качественных показателей, потребовалась разработкаэкспериментов испытаний и их проведение, которое позволило выявлять ошибки и исправлять их для последующих этапов испытания. По результатам испытания программного средства, его оценка надежности с помощью модели Шумана, показала высокую степень безотказной работы. Среди остальных показателей качества особенно выделились практичность и сопровождаемость. Практичность обусловлена тем, что программное средство является веб-комплексом, интерфейс которого достаточно прост для использования, доступен с любого устройства с установленным браузером и доступом в интернет. Сопровождаемость поддерживается благодаря разделению на независимые модули интерфейса и серверной части программного средства, реализованной в REST архитектуре.Также была проведена оценка экономической эффективности веб-комплекса. В результате было выявлено, что внедрение позволяет снизить примерно в половину финансовые и трудовые затраты, а срок окупаемости от внедрения, на основании проведённых расчетов, составляет 8 месяцев и 6 дней. По результатам оценки технико-экономических показателей, можно сделать вывод о том, что программное средство соответствует поставленной задаче и в полной мере выполняет свои функции.
Таким образом, полученные результаты показывают, что цель, поставленная в рамках выпускной квалификационной работы, достигнута.
СПИСОК ЛИТЕРАТУРЫ
1. ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.
2. ГОСТ 28806-90. Качество программных средств. Термины и определения.
3. ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению.
4. ГОСТ 28195-89. Оценка качества программных средств. Общие положения.
5. Батищев, Д.И., Неймарк, Е.А., Старостин Н.В. Применение генетических алгоритмов к решению задач дискретной оптимизации / Д.И. Батищев,Е.А. Неймарк // Нижний Новгород.- 2007. - 85 с.
6. Бейзер, Б.Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем / Б.Бейзер // СПб.: Питер. - 2004. - 124 с.
7. Браун, И. Веб-разработка с применением Node и Express. Полноценное использование стека JavaScript / И. Браун // СПб.: Питер. -2017. - 214 c.
8. Васильев, О.В. Модифицированный алгоритм муравьиных колоний для решения задачи коммивояжера / О.В. Васильев, Т. М. Леденева // Системы управления и информационные технологии. - 2011. - №3(2).- С. 45-55.
9. Гладков, Л.А., Курейчик В.В., Курейчик В.М. Генетические алгоритмы / Л.А. Гладков, В.В. Курейчик, В.М Курейчик // М.: ФИЗМАТЛИТ. - 2006. - 320 с.
10. Горбушие, А.М. Экономический эффект программного продукта / А.М. Горбушие // Мн.: ВШ, - 2007. - 275 с.
11. Джонс, М.Т. Основы современных алгоритмов / М.Т. Джонс // - М.: Техносфера, -2004. - 368 с.
12. Джонс, М.Т. Программирование искусственного интеллекта в приложениях / М.Т. Джонс // - М.: ДМК Пресс.-2004. - 312 с.
13. Лопатин, А.С. Метод отжига. / А.СЛопатин // СПб. : Изд-во СПбГУ. - 2005. -С. 133-149.
14. Пауэлл,Д.К. Разработка одностраничных веб-приложений / Д.К.Пауэлл // ДМК Пресс. - 2014. - 512 с.
15. Райзберг, Б.А. Современный экономический словарь / Б.А.Райзберг, Л.Ш. Лозовский, Е.Б. Стародубцева // ИНФРА-М. - 2006. -27с.
16. Савин, А.Н. Применение алгоритма оптимизации методом имитации отжига на системах параллельных и распределённых вычислений / А.Н. Савин, Н.Е. Тимофеева // Информатика. - 2012. - С. 110-116.
17. Сухов, К. Путеводитель по технологииNode.js. / К. Сухов // ДМК Пресс. - 2015. - 416 с.
18. Стефанов, С. React.js. Быстрый старт / С.Стефанов // СПб.: Питер.-2017. - 43c.
19. Флэнаган, Д. JavaScript. Подробное руководство / Д. Флэнаган// Символ-Плюс. -2008. - 504 с.
20. Штовба, С. Д. Муравьиныеалгоритмы / С. Д. Штовба// ExponentaPro.- 2003. - №4. -С. 70-75.
ПРИЛОЖЕНИЯ
Приложение A
Листинг программы
backend/building.coffee
Record = require('../models/record')
Worker = require('../models/worker')
User = require('../models/user.coffee')
requestify = require('requestify');
config = require('../../config/database')
moment = require 'moment'
getHref = (address, patients) ->
new Promise (resolve, reject) ->
href =
requestify
.get href
.then (response) ->
resolveresponse.getBody()
getMatrix = (matrix, patients) ->
matrix.best = []
fori in [0...matrix.rows.length]
priority = 1
switch patients[i]._doc.priority
when "low"
priority = 1
when "middle"
priority = 5
when "high"
priority = 100
matrix.destination_addresses[i] =
address :matrix.destination_addresses[i]
id : patients[i]._doc.id_patient._doc._id.toString()
priority : priority
for j in [0...matrix.rows[i].elements.length]
elem = matrix.rows[i].elements[j]
unlessi is j
minutes = Math.round(elem.duration.value / 60)
elem.time = minutes
elem.feromon = 1
elem.was = []
return matrix
module.exports.createPathRecord = (req, res) ->
new Promise (resolve, reject) ->
Worker.findOne({ _id: req.query.id_worker })
.populate('patients.id_patient', ['address', 'login', '_id'])
.exec (err, worker) =>
if worker._doc.patients.length< 3
return resolve()
patients = worker._doc.patients
address = patients.map (item) -> "Москва,#{item._doc.id_patient._doc.address}"
getHref(address.join('|'), patients).then (body) ->
m = new MatangetMatrix(body, patients)
matrix = m.solve()
newPatients = []
matrix.best[matrix.best.length - 1].path.forEach (item, i) ->
newPatients.push patients[item]
debugger
ifi is 0
newPatients[i].set("time_target", moment(worker.get("start")).minutes(15))
else
matrix.best[matrix.best.length - 1].ribs.shift()
timeRib = matrix.best[matrix.best.length - 1].ribs[0].time
matrix.best[matrix.best.length - 1].ribs.shift()
debugger
newPatients[i].set("time_target", moment(newPatients[i - 1].get("time_target")).add(timeRib + 15, 'm'))
Worker.findByIdAndUpdate {_id: req.query.id_worker}, { $set: { patients: newPatients }}, (err, worker) ->
console.log("complete optimization")
module.exports.createPath = (req, res) ->
Worker.findOne({ _id: req.query.id_worker })
.populate('patients.id_patient', ['address', 'login', '_id'])
.exec (err, worker) =>
patients = worker._doc.patients
address = patients.map (item) -> "Москва,#{item._doc.id_patient._doc.address}"
getHref(address.join('|'), patients).then (body) ->
m = new MatangetMatrix(body, patients)
res.json(success: true, data: m.solve())
classMatan
constructor: (matrix) ->
@matrix = matrix
alfa: 1
beta: 3
p: 0.5
q: 50
t: 1
pijkt: (tau, eta, vers, indexelem) ->
tau_eta = (t, e, index) =>
Math.pow(t, 1) * Math.pow(1 / e, @beta)
sum = (arr, index) =>
summ = 0
arr.forEach (elem) ->
summ += tau_eta(elem.item.feromon, elem.item.time, index)
summ
tau_eta(tau, eta, indexelem) / sum(vers, indexelem)
randomizer: (arr) ->
getRandomFloat = (min, max) ->
Math.random() * (max - min) + min
inter = 0
arr.forEach (item) ->
item.min = inter
inter += item.chance
item.max = inter
rand = getRandomFloat(arr[0].min, arr[arr.length - 1].max)
elem = arr.filter (item) ->
rand>= item.min&& rand <= item.max
elem[0]
solve: =>
countVer = @matrix.rows.length
countReb = ((countVer * countVer) - countVer) / 2
ants = []
for iterate in [0...100]
fori in [0...countVer]
c = Math.floor(Math.random() * (countVer - 1)) + 0
path = [0]
ribs = []
timePath = 0
currentVar = 0
forreb in [0...(countVer - 1)]
canArr = []
@matrix.rows[currentVar].elements.forEach (item, j) ->
if (currentVarisnt j) and not (j in path) and (iisntitem.was)
canArr.push
index: j
item: item
canElem = canArr[0]
ifMath.floor(Math.random() * (countVer - 1)) + 0 <countVer / 2
canArr.forEach (elem) ->
ifelem.item.feromon>canElem.item.feromon then canElem = elem
else
chanceArr = []
canArr.forEach (elem, indexCanElem) =>
chanceArr.push
index: indexCanElem
chance: (@pijkt elem.item.feromon, elem.item.time, canArr, elem.index)*100
chanceElem = @randomizer(chanceArr)
canElem = canArr[chanceElem.index]
timePath += @matrix.rows[currentVar].elements[canElem.index].time
@matrix.rows[currentVar].elements[canElem.index].was.pushi
@matrix.rows[canElem.index].elements[currentVar].was.pushi
ribs.push@matrix.rows[currentVar].elements[canElem.index]
ribs[ribs.length - 1].feromon =
((1 - @p) * ribs[ribs.length - 1].feromon) + (@p * @t)
ribs.push@matrix.rows[canElem.index].elements[currentVar]
ribs[ribs.length - 1].feromon = ribs[ribs.length - 2].feromon
path.pushcanElem.index
currentVar = canElem.index
ants.push
path: path
ribs: ribs
timePath: timePath
bestAnt = ants[0]
ants.forEach (elem) ->
ifelem.timePath<bestAnt.timePath then bestAnt = elem
@matrix.best.pushbestAnt
forreb in [(bestAnt.ribs.length - 1)..0]
feromon = bestAnt.ribs[reb].feromon
sum = 0
bestAnt.ribs[reb].was.forEach (item) =>
sum += (@q / ants[item].timePath)
bestAnt.ribs[reb].feromon = @p * feromon + sum
@matrix.rows.forEach (elem) ->
elem.elements.forEach (item) ->
ifitem.was then item.was = undefined
@matrix
backend/app.coffee
require('coffee-script')
express = require('express')
app = express()
mongoose = require('mongoose')
mongoose.Promise = global.Promise;
bodyParser = require('body-parser')
server = require('http').Server(app)
passport = require('passport')
config = require('./config/database')
io = require('socket.io')(server)
jwt= require('jsonwebtoken')
port = 4001
cors = require('cors')
userController = require('./app/controllers/user.coffee')
workerController = require('./app/controllers/worker.coffee')
recordController = require('./app/controllers/record.coffee')
buildingController = require('./app/controllers/building.coffee')
dashboardController = require('./app/controllers/dashboard.coffee')
waysController = require('./app/controllers/ways.coffee')
app.usecors()
app.usebodyParser.urlencoded
extended: false
app.usebodyParser.json()
mongoose.createConnection(config.database)
app.usepassport.initialize()
require('./config/passport')(passport)
apiRoutes = express.Router()
apiRoutes.post '/register', userController.register
apiRoutes.post '/authenticate', userController.login
apiRoutes.get '/check', passport.authenticate('jwt', { session: false }), userController.check
apiRoutes.post '/scheduler', passport.authenticate('jwt', { session: false }), workerController.addWorker
apiRoutes.get '/scheduler', passport.authenticate('jwt', { session: false }), workerController.getWorker
Подобные документы
Программные продукты для решения задачи построения оптимального маршрута. Выбор аппаратных и программных средств для построения маршрута обхода пациентов. Математическая модель муравьиного алгоритма: состав, структура, тестирование, отладка, реализация.
дипломная работа [1,9 M], добавлен 03.12.2017Основные типы электронных путеводителей, предназначение их мультимедийной разновидности. Применение электронного путеводителя для ГОУ ВПО "МГТУ им. Г.И. Носова". Выбор алгоритма поиска оптимального маршрута. Функциональные схемы работы программы.
дипломная работа [3,7 M], добавлен 13.04.2014Математическая модель решения задачи коммивояжера. Поиск кратчайшего замкнутого пути обхода нескольких городов и возвращения в исходную точку. Описание программы и результатов ее тестирования. Основная форма программы после вывода конечных данных.
курсовая работа [603,3 K], добавлен 21.10.2012Разработка программы нахождения оптимального пути обхода шахматной доски шахматным конем с обязательной визуализацией процесса и пошаговой демонстрацией. Тестирование графического интерфейса. Исходный код программы, составление и проверка алгоритма.
курсовая работа [468,3 K], добавлен 11.12.2012Разработка программы, относящейся к классу задач маршрутизации и системы принятия решения, предназначенной для выбора оптимального маршрута перемещения в лабиринте из начальной клетки в конечную, с учетом необходимости посещения определенных клеток.
контрольная работа [14,7 K], добавлен 11.11.2010Организационная структура и функциональная модель санатория "Дубрава" и функции ее основных элементов, сценарий бизнес-процессов и математическая модель оптимального питания. Реализация информационной системы: выбор программных средств, эффективность.
дипломная работа [1,7 M], добавлен 20.07.2014Реализация программного средства "Действия над матрицами". Разработка кода программного продукта на основе готовой спецификации на уровне модуля. Использование инструментальных средств на этапе отладки программного модуля. Выбор стратегии тестирования.
отчет по практике [296,1 K], добавлен 19.04.2015Сравнение различных способов обхода данных. Заполнение массива для случайного обхода. Изучение понятия кэш-памяти, ее основных размеров и функций. Оптимальный и неоптимальный алгоритм умножения двух матриц с точки зрения порядка обхода данных в памяти.
презентация [94,7 K], добавлен 02.06.2013Разработка проекта автоматизированной информационной системы, обеспечивающей учет пациентов в ОАО "Авитек". Методология построения моделей в нотациях IDEF0 и DFD. Изучение доступных инструментальных средств визуального моделирования бизнес-процессов.
курсовая работа [1,3 M], добавлен 22.08.2011Принципы и алгоритмы обработки прерываний. Набор действий по реализации этапов обработки прерываний микропроцессора. Разработка структуры и алгоритма резидентной программы. Реализация программы на языке Ассемблер, методы её отладки и тестирования.
курсовая работа [348,7 K], добавлен 22.12.2014
