Автоматизированная информационная система учета оргтехники

Размещено на http://www.allbest.ru/

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Автоматизированная информационная система учета оргтехники

В.А. Никонов

Самара 2017

Введение

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

Помимо дешевизны это еще и удобно, ведь базы данных в силу своей особенности не просто хранят данные, но еще и структурируют информацию, а процесс поиска, анализа и извлечения данных сводиться к минутам и секундам, по сравнению с часами или даже днями проведенными в бумажных архивах. В свое время клиен-серверная архитектура и десктопные программные обеспечения сделали настоящий прорыв. Однако, время не стоит на месте и сейчас на вооружении есть еще более мощные средства решения все тех же с одной стороны простых и тривиальных задач, с которыми прекрасно справлялись ручка и лист бумаги формата А4, но в тоже время достаточно сложными для написания программного кода, который бы охватывал весь спектр задач требуемой предметной области, а именно - Web- технологии. [1]

В настоявший момент происходит стремительное развитее индустрии Web-технологий и это дает некий запас прочности разрабатываемого приложения.

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

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

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

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

Предметом исследования выступают методы и алгоритмы разработки логики приложения.

Для достижения цели необходимо выполнить следующие задачи:

произвести анализ предметной области;

разработать информационно-логическую модель АИС;

спроектировать базу данных;

разработать серверную часть приложения;

разработать web-интерфейс пользователя.

В рамках работы была изучена литература таких авторов как Сибилёв В.Д., Гайдамакин, Н. А., а также техническая документация по языку программирования Java, JavaScript, по framework bootstrap, а также по системе управления базами данных Oracle.

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

Во введении приводится обоснование актуальности рассматриваемой задачи и выбранных методов ее решения. Основная часть бакалаврской работы состоит из 4 глав:

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

во второй главе выбор и обоснование инструментов разработки;

в третьей главе описываются этапы разработки приложения;

четвертая глава посвящена тестированию приложения.

В заключение приводятся основные результаты и выводы по работе. Приложение содержит:

исходный код приложения (Приложение А);

презентационный материал (Приложение Б).

1. Анализ предметной области

1.1 Анализ и описание задачи учета оргтехники в ГБПОУ «ПГК»

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

В задачи сотрудника входит:

составление заявок на обслуживание уже имеющейся оргтехники;

проверка сроков службы оргтехники и своевременное списание;

ведение учета вверенной оргтехники.

В задачи сотрудников по обслуживанию оргтехники входит:

анализ и учет случаев отказа оргтехники;

ведение учета и составление отчетности о выполненных работах;

контроль за движением оргтехники по территории;

обеспечение бесперебойного функционирования оборудования;

составление заявок на приобретение нового необходимого оборудования;

организация подсистемы справочной информации;

предотвращение сбоев в процессе работы оргтехники;

принятие оперативных мер по устранению нарушений в работе оргтехники;

установка и настройка аппаратных компонентов;

присвоение новой оргтехнике инвентарного номера;

обслуживание существующей оргтехники.

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

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

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

проблема поиска материально ответственного лица за оргтехнику;

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

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

проблема несвоевременного исполнения заявок;

проблема дублирования инвентарных номеров;

разрозненное хранение информации о всей имеющейся оргтехнике;

трудоемкость анализа имеющейся информации;

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

длительные задержки при передаче и списании оргтехники;

затяжной процесс инвентаризации всей оргтехники.

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

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

список сотрудников, несущих материальную ответственность;

перечень оргтехники, закрепленный за каждым из них;

инвентарные номера, закрепленные за оргтехникой;

год и стоимость оргтехники на момент приобретения;

срок службы оргтехники;

технические характеристики оргтехники.

Постановка задачи

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

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

создание новых инвентарных номеров;

ведение истории оборудования;

ведение истории кабинетов;

поиск оборудования по территории;

формирование отчетной документации;

сбор статистики;

создание заявок на обслуживание, передачу, списание оргтехники.

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

2. Выбор инструментов

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

В качестве СУБД для своего приложения я выбрал Oracle, по статистике всего рынка России за 2016 год, данная СУБД занимает более 60%, среди других СУБД и около 30% мирового рынка.

СУБД Oracle обладает следующим набором преимуществ: надежность, безопасность, высокая производительность, удобство в работе. Это главное, что характеризует продукты Oracle на протяжении уже многих лет. Это является наиболее важным для СУБД, ставшей на сегодняшний день практически обязательной частью любой серьезной информационной системы. Но не только эти характеристики позволяют продуктам Oracle удерживать лидерство на рынке СУБД. Стремительно развивающиеся информационные технологии требуют от современных СУБД расширения классической функциональности лишь по хранению и обработке данных. Двигаясь в ногу со временем, корпорация Oracle по сути ломает сложившиеся взгляды на СУБД, наделяя ее все новыми и новыми возможностями. [2]

Современная СУБД Oracle это мощный программный комплекс, позволяющий создавать приложения любой степени сложности. Ядром этого комплекса является база данных, хранящая информацию, количество которой за счет предоставляемых средств масштабирования практически безгранично. C высокой эффективностью работать с этой информацией одновременно может практически любое количество пользователей (при наличии достаточных аппаратных ресурсов), не проявляя тенденции к снижению производительности системы при резком увеличении их числа.

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

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

Встраивание в СУБД Oracle JavaVM, полномасштабная поддержка серверных технологий (Java Server Pages, Java-сервлеты, модули Enterprise JavaBeans, интерфейсы прикладного программирования CORBA), привело к тому, что Oracle на сегодняшний день де-факто является стандартом СУБД для Internet.

Еще одной составляющей успеха СУБД Oracle является многоплатформенность, так как она поставляется практически для всех существующих на сегодня операционных систем. Работая под Sun Solaris, Linux, Windows или на другой операционной системе с продуктами Oracle не будет возникать никаких проблем в работе. СУБД Oracle одинаково хорошо работает на любой платформе. Таким образом, компаниям, начинающим работу с продуктами Oracle не приходится менять уже сложившееся сетевое окружение. Существует лишь небольшое количество отличий при работе с СУБД, обусловленных особенностями той или иной операционной системы. В целом же это всегда та же самая безопасная, надежная и удобная СУБД Oracle. Также нельзя не сказать о грамотной миграционной политике Oracle.

Понимая, что переход с более старой версии СУБД на новую довольно трудоемкая процедура, связанная с тестированием работы существующих приложений в новом окружении, Oracle, при выпуске новых продуктов уделяет особое внимание совместимости снизу-вверх, делая этот переход практически безболезненным. Помимо этого, для переноса данных из СУБД других фирм в СУБД Oracle, Oracle бесплатно предлагает специальный инструментарий. Обладая удобным графическим интерфейсом, Oracle Migration Workbench в пошаговом режиме, полуавтоматически, поможет выполнить довольно непростую процедуру миграции.

Сервером приложений стал WildFly 8, полностью совместимый со стандартом Java EE 7 (прохождение Java EE TCK на 100%).

Wildfly - не новый продукт. Это ребрендинг и развитие JBoss AS7/EAP6 в области как администрирования, так и API для разработчика. Wildfly 8 построен с использованием Java SE 7 и требует Java SE7 (или выше) для работы. Этот релиз на 100% проходит Java EE 7 TCK. Минимальный размер дистрибутива -- 14 мегабайт, что идеально для построения framework с использованием Wildfly. И конечно доступны средства интеграции с основными Java IDE.

Изменения в администрировании:

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

использование встраиваемого высокопроизводительного масштабируемого web-сервера Undertow.io, предоставляющего блокирующие и неблокирующие API, основанные на NIO. Этот web- сервер может представлять большую гибкость благодаря архитектуре, основанной на композиции. С ней вы можете построить web-сервер комбинируя небольшие обработчики событий;

Wildfly 8 поддерживает богатый набор команд управления, которые были добавлены в Command Line Interface, такие как возможность патчить модульную основу сервера;

все протоколы в Wildfly мультиплексированы на 2 порта: 8080 для приложений и 9990 для управления. Это сделано для того, чтобы меньше времени администраторы тратили на настройки firewall. Очень важным улучшением стала поддержка Java Enterprise API 7 (100%

TCK, полная поддержка стандарта).

Некоторые важные улучшения, включенные в Wildfly:

поддержка WebSocket 1.0. До HTML5 традиционная модель «запрос-ответ» использовалась в HTTP. Необходимо было постоянно опрашивать сервер на предмет изменений. Протокол WebSocket представляет полнодуплексный канал между клиентом и сервером без проблем с задержками соединения. Используя эту технологию вместе с другими клиентскими технологиями, такими как JavaScript и HTML5, мы можем создавать мощные и красивые приложения в браузере;

Java API for JSON Processing 1.0 (JSON-P). Этот набор API улучшает возможности приложений, использующих JSON определяя новые API для парсинга, генерации, трансформации и запросов JSON документов. Поэтому вы сможете строить объектную модель JSON (подобно DOM для XML) и использовать ее в потоковом режиме (как в XML с StAX);

Batch Application API 1.0. Это API было спроектировано для стандартизации пакетной обработки для Java приложений. Вы можете подумать об этой технологии для использования вместо старых долгоработающих процедур для большого объема данных, управляемых shell скриптами или устаревшими языками (COBOL);

Concurrency Utilites for Java EE 1.0. Это расширение Java SE Concurrency Utility (JSR-166), которое предоставляет простой и стандартный API для использования многопоточности из JavaEE компонентов сохраняя целостность контейнера;

есть и множество других интересных нововведений типа JAX-RS 2.0, JMS 2.0 и др, о чем просто можно почитать в официальном руководстве.

В качестве языка программирования для серверной части мой выбор пал на Java - это сильно типизированный объектно-ориентированный язык программирования, который подходит под мой стиль программирования. Язык программирования - Java, был разработан компанией Sun Microsystems (в последующем приобретенной компанией Oracle). Приложения Java обычно транслируются в специальный байт-код, поэтому они могут работать на любой компьютерной архитектуре, с помощью виртуальной Java-машины. [3]

Java - один из наиболее гибких, удобных и популярных языков программирования. Многим известен его слоган - «Write once, run anywhere», что в переводе означает «Напиши один раз, запускай везде». Этим слоганом разработчики хотели подчеркнуть кроссплатформенность языка. То есть написав программу, вы сможете запустить ее на любом устройстве с любой операционной системой. [4]

Для обработки событий с клиентской стороны, был использован - JavaScript. JavaScript обычно используется как встраиваемый язык для программного доступа к объектам приложений. Наиболее широкое применение находит в браузерах как язык сценариев для придания интерактивности web-страницам. [5]

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

На JavaScript оказали влияние многие языки, при разработке была цель сделать язык похожим на Java, но при этом легким для использования непрограммистами. Языком JavaScript не владеет какая-либо компания или организация, что отличает его от ряда языков программирования, используемых в web-разработке. [6]

Для удобства написания Web-интерфейса мною выбран framework - Bootstrap 4. Так как это довольно мощный инструмент с хорошей документацией и множеством примеров.

Bootstrap (также известен как Twitter Bootstrap) -- свободный набор инструментов для создания сайтов и web-приложений. Включает в себя HTML- и CSS-шаблоны оформления для типографики, web-форм, кнопок, меток, блоков навигации и прочих компонентов web-интерфейса, включая JavaScript-расширения. [7]

Этот framework начал разрабатываться как внутренняя библиотека компании Twitter под названием Twitter Blueprint. После нескольких месяцев разработки он был открыт под названием Bootstrap 19 августа 2011 года.

Основными нововведениями второй версии, появившейся 31 января 2012 года, стали 12-колоночная сетка и поддержка адаптивности.

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

Работа над четвертой версией начата 29 октября 2014 года. Альфа версия вышла 19 августа 2015 года.

К недостаткам можно отнести бедную цветовую гамму стандартного набора иконок.

К преимуществам -- хорошую реализацию grid-сетки для масштабирования web-страницы, создания адаптивного дизайна.

В качестве среды разработки мною были использованы:

IntelliJ IDEA - back-end;

JetBrains WebStorm - front-end.

Несмотря на то, что IntelliJ IDEA тоже умеет работать с HTML разметкой, для разработки интерфейса я использовал другую среду - JetBrains WebStorm. Связанно это прежде всего с тем, что в IntelliJ IDEA помощник авто-завершения перемешивает в себе названия классов со стилями элементов. IntelliJ IDEA - это интегрированная среда разработки программного обеспечения, которая поддерживает множество языков, но наиболее часто ее рассматривают, как IDE для Java. Компания-разработчик предлагает две версии: Community (бесплатная) и Ultimate, но простому пользователю вполне хватит и бесплатной версии.

Очень удобно, что IntelliJ IDEA обладает «сборщиком мусора». Это значит, что во время программирования, когда вы задаете ссылку, для нее выделяется память. Если вы потом удалите ссылку, то у вас остается занятая память. «Сборщик мусора» эту память освобождает, если она нигде не используется.

IntelliJ IDEA - самая умная интегрированная среда разработки для Java, которая действительно понимает код. Среда пытается избавить программиста от рутины и позволяет сосредоточится на более существенных задачах. IDEA предугадывает ваши действия.

JetBrains WebStorm -- интегрированная среда разработки на JavaScript, CSS & HTML от компании JetBrains, разработанная на основе платформы IntelliJ IDEA.

WebStorm обеспечивает автодополнение, анализ кода на лету, навигацию по коду, рефакторинг, отладку, и интеграцию с системами управления версиями. Важным преимуществом интегрированной среды разработки WebStorm является работа с проектами (в том числе, рефакторинг кода JavaScript, находящегося в разных файлах и папках проекта, а также вложенного в HTML). Поддерживается множественная вложенность (когда в документ на HTML вложен скрипт на Javascript, в который вложен другой код HTML, внутри которого вложен Javascript) -- то есть в таких конструкциях поддерживается корректный рефакторинг.

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

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки, изменения копируются из одного репозитория в другой.

Удаленный доступ к репозиториям Git обеспечивается git-daemon, SSH-или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространенным и надежным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

Ядро Git представляет собой набор утилит командной строки с параметрами. Все настройки хранятся в текстовых файлах конфигурации. Такая реализация делает Git легко портируемым на любую платформу и дает возможность легко интегрировать Git в другие системы (в частности, создавать графические git-клиенты с любым желаемым интерфейсом).

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

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

Так же была использована библиотека иконок - Font Awesome Icons. Так как в сравнении со стандартной библиотекой иконок от Bootstrap их количество значительно выше.

И jQuery - библиотека JavaScript, помогающая взаимодействовать между HTML и JavaScript. jQuery позволяет осуществить доступ к любым компонентам HTML-страницы, взаимодействия с атрибутами, добавляя или удаляя классы. Также jQuery обеспечивает удобный способ подключения к API для дальнейшего использования технологии AJAX. [8]

Точно так же, как CSS отделяет визуализацию от структуры HTML, JQuery отделяет поведение от структуры HTML. Например, вместо прямого указания на обработчике события нажатия кнопки, управление передается JQuery, которая идентифицирует кнопки и затем преобразует его в обработчик события клика. Такое разделение поведения и структуры также называется принципом ненавязчивого JavaScript.

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

Помимо всего этого был так же использован SourceTree - это бесплатный клиент для Windows и Mac, предоставляющий графический интерфейс для работы с репозиторием Git.

3. Разработка АИС

3.1 Разработка информационно - логической модели АИС

При написании мною приложения была разработана информационно- логическая модель, содержащая UML-диаграммы приложения.

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

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

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

диаграмма состояний;

диаграмма деятельности;

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

Все из перечисленных диаграмм позволяют агрегировать и в тоже время уточнить всевозможные представления о «характере поведения» рассматриваемой АИС в терминах языка UML.

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

Диаграмма вариантов использования - это изначальное понимание о том, как что-либо должно работать. Эта диаграмма позволяет описать функционал АИС, иными словами то, какие задачи АИС способна выполнить в процессе своей работы.

Диаграмма вариантов использования, далее ДВИ, позволяет отразить следующее:

обозначить границы предметной области на первичных этапах разработки АИС;

составить техническое задание к разрабатываемой АИС;

определить общую концепцию АИС.

Задача ДВИ кроется в следующем: разрабатываемая АИС предполагается в виде использования так называемых сценариев, где пользователи, наделенные разными привилегиями, взаимодействуют между собой по средствам АИС. Одновременно сущностью может являться как субъект, так объект или даже система, воздействующая на АИС извне. Таким является специализированное оборудование, программа, подпрограмма, сам человек, любая другая система или плагин, который в свою очередь является источником взаимодействия с АИС так, как это заранее определено в сценарии. Использование таких диаграмм упрощает описание функционала, который система предлагает пользователю. При этом все варианты развития событий предопределены набором правил и действий, доступных для пользователя в данный момент. Но в тоже время на диаграмме не описывается то, как будет реализована связь пользователя с АИС.

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

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

При работе с АИС основной функционал администратора, включает в себя следующее:

добавление, удаление, редактирование новых учетных единиц;

составление заявок на приобретение нового необходимого оборудования;

присвоение новой оргтехнике инвентарного номера;

просмотр списка всей оргтехники;

списание оборудования;

составление ведомостей;

ведение контроля за движением оргтехники по территории;

подтверждение статусов.

При работе с АИС основной функционал пользователя, включает в себя следующее:

просмотр списка вверенной оргтехники;

составление заявок на обслуживание;

формирование ведомости инвентаризации;

создание договоров о передачи и списании.

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

Рис. 3.1 - диаграмма вариантов использования АИС

Диаграмма состояний

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

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

ДС отличается от других диаграмм следующим:

отображает алгоритм изменения состояний лишь одного элемента;

описывает поведение одного «реактивного объекта», то есть объекта, характер поведения которого обусловлен его реакцией на события извне.

Ниже приведены состояния, которые необходимо реализовать для объекта «Заявка»:

заявка добавлена в систему;

назначен ответственный за исполнение заявки;

ожидание времени, на которое назначено исполнение заявки;

заявка в стадии выполнения;

отсутствуют необходимые компоненты для выполнения заявки;

заявка была отменена;

заявка выполнена;

заявка не выполнена;

отправлена в архив.

Рис. 3.2 - диаграмма состояния заявки

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

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

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

Для этого в UML применяются диаграммы деятельности, далее ДД. Этот вид диаграмм схож с ДС, так как здесь так же присутствую переходы между состояниями, однако каждое состояние описывается примитивными функциями, а переход происходит, только по завершению их.

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

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

администрирование системы;

поиск информации;

редактирование уже существующей информации;

ввод новой информации.

На рис. 3.3 представлена диаграмма деятельности АИС.



Рис. 3.3 - диаграмма деятельности АИС

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

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

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

На рис. 3.4 представлена диаграмма последовательности, рассматриваемой АИС.

3.2 Проектирование базы данных

В настоящий момент при проектировании базы данных предъявляются следующие требования, которые считаются основными:

малое время отклика при запросе от пользователя или говоря

другим языком высокое быстродействие;

простой способ обновления данных;

независимое использование данных;

многопользовательский доступ к данным;

безопасность хранения данных;

защищенность данных;

корректное отображение данных.

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

Рис. 3.4 - диаграмма последовательности АИС

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

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

Под безопасностью данных понимается их защищенность и целостность хранения. Она предполагает:

проверку дублирования информации;

проверку при обновлении информации;

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

возможность восстановления данных.

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

Разработка же самой базы данных делится на 3 этапа:

разработка инфологической модели;

разработка логической модели;

разработка физической модели.

Инфологическая модель базы данных

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

На основе информации полученной из анализа предметной области предполагается 12 сущностей:

id_user - будет первичным ключом сущности: user;

id_device - будет первичным ключом сущности: device;

id_request - будет первичным ключом сущности: request;

id_event_device - будет первичным ключом сущности: history_device;

id_model - будет первичным ключом сущности: model;

id_brand_name - будет первичным ключом сущности:

brand_name;

id_type_device - будет первичным ключом сущности:

type_device;

id_parameter - будет первичным ключом сущности:

parameter;

id_device_parameter - будет первичным ключом сущности: device_parameter;

id_room - будет первичным ключом сущности: room;

id_event_room - будет первичным ключом сущности:

history_room;

id_building - будет первичным ключом сущности: building.

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

Между сущностями «user» и «device»:

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

множество устройств может числиться за одним пользователем.

Между сущностями «user» и «request»:

каждый пользователь может оформить множество заявок;

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

Между сущностями «device» и «request»:

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

во множестве заявок может упоминаться одно и тоже устройство.

Между сущностями «device» и «history_device»:

каждое устройство может иметь множество событий;

множество событий может быть связанно с одним и тем же устройством.

Между сущностями «device» и «model»:

множество устройств может быть одной модели;

каждая модель должна иметь хотя бы одно устройство. Между сущностями «model» и «brand_name»:

множество моделей может принадлежать одному производителю;

один производитель может выпускать несколько моделей. Между сущностями «brand_name» и «type_device»:

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

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

Между сущностями «type_device» и «parameter»:

каждый тип устройства может содержать множество характеристик;

множество характеристик может принадлежать одному типу устройств.

Между сущностями «parameter» и «device_parameter»:

каждая характеристика может иметь множество значений;

множество значений может принадлежать одной характеристике.

Между сущностями «model» и «device_parameter»:

каждая модель может иметь множество характеристик;

множество характеристик может принадлежать одной модели.

Между сущностями «model» и «type_device»:

каждая тип устройства может иметь множество моделей;

множество моделей может принадлежать одному типу устройства.

Между сущностями «device» и «room»:

множество устройств может находиться в одном кабинете;

в одном кабинете может находиться множество устройств. Между сущностями «room» и «history_room»:

в каждом кабинете может происходить множество событий;

множестве событий может происходить в одном кабинете. Между сущностями «room» и «building»:

в каждом здании должно находиться множество кабинетов;

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

Логическая модель базы данных

Логическая модель -- это абстрактное понятие определения совокупности объектов, которое является самодостаточным и придерживается четко прописанной логики взаимодействия доступа к данным, к которым обращается пользователь. С помощью операторов определяется то, каким будет поведение данных в базе данных, а сами объекты нужны для моделирования структуры. [9]

Ниже приведено описание основных сущностей АИС в таб.3.1-3.12.

Таблица 3.1 Описание сущности user

Атрибут	Описание
id_user	Код пользователя
role	Тип учетной записи
email	Адрес электронной почты
phone	Контактный номер связи
password	Пароль от учетной записи
full_name	Полное имя пользователя

Таблица 3.2

Атрибут	Описание
id_device	Код устройства
id_user	Код пользователя
id_model	Код модели устройства
id_room	Код кабинета
inventory	Инвентарный номер
year_of_purchase	Год закупки
price_of_value	Стоимость устройства
lifetime	Срок эксплуатации

Таблица 3.3 Описание сущности request

Атрибут	Описание
id_ request	Код заявки
id_user	Код пользователя
id_device	Код устройства
type	Тип заявки
date_time	Дата/Время
status	Статус заявки

Таблица 3.4 Описание сущности history_device

Атрибут	Описание
id_event_device	Код события
id_device	Код устройства
date_time	Дата/Время
event	Событие

Таблица 3.5 Описание сущности model

Атрибут	Описание
id_ model	Код модели устройства
id_brand_name	Код производителя
id_type_device	Код типа устройства
name	Название модели

Таблица 3.6 Описание сущности brand_name

Атрибут	Описание
id_brand_name	Код производителя
id_type_device	Код типа устройства
name	Название торговой марки

Таблица 3.7 Описание сущности type_device

Атрибут	Описание
id_type_device	Код типа устройства
name	Название типа

Таблица 3.8 Описание сущности parameter

Атрибут	Описание
id_ parameter	Код характеристики
id_type_device	Код типа устройства
name	Название характеристики

Таблица 3.9 Описание сущности device_parameter

Атрибут	Описание
id_ device_parameter	Код характеристики устройства
id_model	Код модели
id_ parameter	Код характеристики
value	Значение

Таблица 3.10 Описание сущности room

Атрибут	Описание
id_ room	Код кабинета
id_ building	Код здания
level	Этаж
number	Номер кабинета

Таблица 3.11 Описание сущности history_room

Атрибут	Описание
id_event_room	Код события кабинета
id_room	Код устройства
date_time	Дата/Время
event	Событие

Таблица 3.12 Описание сущности building

Атрибут	Описание
id_building	Код здания
name	Название
address	Адрес

Физическая модель базы данных

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

Таблица 3.13 Физическое описание сущности user

Атрибут	Тип
id_user	integer
role	integer
email	varchar
phone	integer
password	varchar
full_name	varchar

Таблица 3.14 Физическое описание сущности device

Атрибут	Тип
id_device	integer
id_user	integer
id_model	integer
id_room	integer
inventory	integer
year_of_purchase	datatime
price_of_value	decimal
lifetime	integer

Таблица 3.15 Физическое описание сущности request

Атрибут	Тип
id_ request	integer
id_user	integer
id_device	integer
type	integer
date_time	datatime
status	integer

Таблица 3.16 Физическое описание сущности history_device

Атрибут	Тип
id_event_device	integer
id_device	integer
date_time	datatime
event	varchar

Таблица 3.17 Физическое описание сущности model

Атрибут	Тип
id_ model	integer
id_brand_name	integer
id_type_device	integer
name	varchar

Таблица 3.18 Физическое описание сущности brand_name

Атрибут	Тип
id_brand_name	integer
id_type_device	integer
name	varchar

Таблица 3.19 Физическое описание сущности type_device

Атрибут	Тип
id_type_device	integer
name	varchar

Таблица 3.20 Физическое описание сущности parameter

Атрибут	Тип
id_ parameter	integer
id_type_device	integer
name	varchar

Таблица 3.21 Физическое описание сущности device_parameter

Атрибут	Тип
id_ device_parameter	integer
id_ parameter	integer
id_model	integer
value	varchar

Таблица 3.22 Физическое описание сущности room

Атрибут	Тип
id_ room	integer
id_ building	integer
level	integer
number	integer

Таблица 3.23 Физическое описание сущности history_room

Атрибут	Тип
id_event_room	integer
id_room	integer
date_time	datatime
event	varchar

Таблица 3.24 Физическое описание сущности building

Атрибут	Тип
id_building	integer
name	varchar
address	varchar

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

3.3 Основные алгоритмы работы системы

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

В данной АИС реализовано несколько алгоритмов:

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

авторизация пользователей;

оформление заявки на передачу оргтехники;

оформление заявки на обслуживание оргтехники;

оформление заявки на списание оргтехники;

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

инвентаризация оргтехники;

поиск оргтехники и сбор статистики.

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

Алгоритм регистрации новых пользователей

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

Сам алгоритм регистрации нового пользователя осуществляется следующим образом:

сотрудник приходит к администратору и просит его,

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

администратор заходит в раздел добавления сотрудников и вводит туда ФИО нового пользователя, выставляет роль и нажимает кнопку «Создать»;

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

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

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

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

ER-диаграмма базы данных

Алгоритм авторизации пользователей

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

Если система обнаруживает что это первичный вход, то запускается процедура подтверждения данных со всеми описанными выше условиями, в противном случае происходит проверка роли пользователя. Как только роль установлена пользователь получает доступ к тому функционалу АИС, который ему отведен.

Алгоритм оформления заявки на передачу оргтехники

Для описания процедуры передачи оргтехники от одного пользователя, далее в этом пункте будет принято обозначение - пользователь А другому, далее в этом пункте будет принято обозначение - пользователь Б, необходимо проделать следующие действия:

пользователь А зайдя в сою учетную запись выбирает ту

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

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

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

если пользователь Б дал согласие на передачу лишь части оборудования, то пользователю А приходит уведомление о несогласии приема с причинами той оргтехники, которую пользователь Б не принял. После чего пользователь А либо снимает с передачи ту оргтехнику, которую не смог передать, либо же устраняет причины и посылает их повторно. Или же он может отказать в передаче всего списка;

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

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

Алгоритм оформления заявки на обслуживание оргтехники

Алгоритм обслуживания проходит следующие этапы:

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

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

далее администратор приступает к выполнению необходимой работы по обслуживанию оборудования, затем подтверждает в АИС об выполнении заявки;

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

Алгоритм оформления заявки на списание оргтехники

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

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

оргтехнику, ставя галочки напротив учетных единиц и нажимает кнопку «Списать»;

после чего АИС просит указать причину списания каждой единицы учета;

как только все причины будут указаны, администратор получает уведомление о списании;

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

после этого пользователь получает уведомление, в котором указан список разрешенного к списанию оборудования и список отказанного в списании оборудования. Здесь пользователю не разрешено спорить с администратором, и он может либо согласиться и списать только то что одобрено, либо отказаться и ничего не списывать;

если пользователь соглашается списать разрешенное оборудование, то администратор получает уведомление об этом;

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

Алгоритм добавления новой оргтехники в базу данных

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

к администратору поступает новое оборудование, он

производит его вскрытие, после по шаблону заносит данные в АИС. Для внесения данных ему необходимо либо выбрать уже существующую модель в базе и перейти к следующему этапу, либо создать новую, указав производителя, тип устройства, название модели по средствам выпадающего списка. Если какого-то параметра нет в базе, то его необходимо отдельно добавить в базу. После добавления необходимо указать основные характеристики устройства, опять же таки, если какой- то характеристики нет, то ее необходимо отдельно добавить;

как только вся информация о модели будет заполнена, администратор выбирает модель из списка и пишет количество добавляемой модели, а после нажимает кнопку «Добавить»;

АИС получив данные определяет свободные инвентарные номера и присваивает их оборудованию, заносит данные в базу и определяет новое оборудование на виртуальный склад, где оно будет дожидаться передачи на какое-либо ответственное лицо;

после чего администратор распечатывает инвентарные номера и расклеивает на оргтехнику. Более подробное описание инвентарного номера будет представлено в разделе посвященного его генерации.

Алгоритм инвентаризации оргтехники

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

администратор рассылает всем пользователям АИС уведомления о необходимости проведения инвентаризации, вверенной им оргтехники;

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