1.8. Обоснование выбора программно-технических средств
В качестве одной из возможных концепций создания информационных систем рассматривается Клиент-серверная архитектура, а в качестве фундаментальной платформы для программной реализации такой архитектуры предлагается платформа семейства Unix-Linux и пр. из этого ряда.
Программное обеспечение, реализующее управление базой данных и поисковые функции разработано как веб-приложение (будем называть, просто «приложение»). По определению, веб-приложение – это «Клиент-серверное приложение, в котором Клиентом выступает браузер, а сервером – веб-сервер. Логика веб-приложения распределена между сервером и клиентом, хранение данных осуществляется, преимущественно, на сервере, обмен информацией происходит по сети [2,4].
Одним из преимуществ такого подхода является тот факт, что Заявители не зависят от конкретной операционной системы пользователя, поэтому веб-приложения являются межплатформенными сервисами (Википедия)».
Клиентская часть программного обеспечения реализует пользовательский интерфейс, формирует запросы к серверу и обрабатывает ответы от него. Серверная часть получает запрос от Заявителя, выполняет обработку, формирует веб-страницу и отправляет её Заявителю по сети.
Для реализации Клиент-серверной архитектуры выбрано трио базового программного обеспечения, базирующегося на Linux платформе — удаленный сервер со стандартным программным обеспечением Аpache, PHP, MySQL и широко распространенный пакет интерактивного удаленного управления базой данных phpMyAdmin. Эти программные средства являются той средой, на основе которой функционируют большинство веб-сайтов и веб-приложений. На текущий год на этой бесплатной платформе функционирует около 70% веб-сайтов.
Еще одним важным преимуществом является открытый код большинства программных продуктов, базирующихся на этой платформе. Что и использовалось в настоящем приложении.
Большинство веб-приложений базируется на веб-серверах общего пользования, так называемых разделяемых хостах (shared hostings), когда на одном или нескольких физических серверах располагается множество веб-сайтов, веб приложений.
Доступ к таким виртуальным хостам, находящимся в пользовании отдельных приложений осуществляется, как правило, посредством FTP— доступа. Для этого созданы специальные Клиентские программы типа GuteFTP 8 Professional и множество других. С помощью FTP- Клиентов можно легко администрировать веб-приложения на сервере.
СУБД MySQL – это система управления реляционными базами данных, которая, в том числе, работает в связке бесплатных мощных продуктов, таких как Unix, Linux …, Apache, PHP, что обеспечивает мощные инструменты поддержки и быструю разработку веб-приложений. MySQL является многопользовательским, «много потоковым» сервером и использует стандартный, принятый программистском мире структурированный язык запросов SQL (Structured Query Language)[4,9].
Для разработки веб-приложений используется также широко принятый во всем мире язык высокого уровня PHP. Язык PHP работает на стороне сервера и обеспечивает создание динамических веб-приложений, в том числе и взаимодействие с базой данных MySQL, посредством множества функций и классов. Программы написанные, в частности, на PHP называются сценариями.
В настоящем проекте использовались следующие языки и технологии для реализации веб-приложения: HTML, CSS, PHP, SQL, СУБД MySQL. Основным является язык PHP. На нем написано 90% кода настоящего приложения.
HTML (от английского Hyper Text Markup Language – язык разметки гипертекста). Это базовый язык в области средств создания веб страниц. Язык HTML предназначен для формирования и оформления веб-страниц, которые интерпретируется с помощью специальных Клиентских программ – браузеров ( Internet Explorer , Mozilla Farefox, и др.).
CSS ( Каскадные таблицы стилей или Cascading Style Sheets) – набор параметров форматирования, который применяется к элементам веб-страницы для управления их видом.
PHP. Это скриптовый язык программирования, созданный для генерации HTML-страниц на Веб-сервере и работы с базами данных. На данный момент он поддерживается 60% — ми поставщиков хостинга, входит в «стандартный» набор для создания сайтов (LAMP – Linux, Apache, MySQL, PHP), работает на стороне сервера.
SQL (Structured Query Language). Создан для работы с реляционными базами данных. Он позволяет пользователям взаимодействовать с базами данных (просматривать, искать, добавлять, управлять данными). MySQL – многопользовательский, многопоточный сервер базы данных SQL. Имеет хорошую скорость и гибкость, если использовать его для хранения изображений и файлов. MySQL соответствует спецификации ANSI 92 SQL [14,15,16].
Вывод по 1 главе
Проведя обзор деятельности государственного предприятия – отдела легализации Министерства иностранных дел РФ, понимаешь необходимость автоматизации процесса сбора и обработки заявок на истребование документов от граждан, находящихся в разных точках мира. Автоматизация данного процесса позволит значительно сократить время поступления заявок в отдел, сократит потерю данных о заявителях и истребуемых документах, позволит своевременно и оперативно получать информацию о стадии выполнения заявки, создать банк данных о заявителях и предоставленных документах, и, как следствие, за счет минимизации трудоемкости и длительности выполнения рутинных работ, повысит уровень работы отдела легализации МИД РФ.
Целью проекта является разработка веб-ориентированной информационной системы, веб-сайта для повышения эффективности деятельности отдела легализации МИД РФ за счет новых информационных технологий и сети интернет, разработка некоторых компонент базы данных ИС, разработка компонент программного обеспечения управления сайтом, базой данных, интерфейсом пользователей.
Разрабатываемая информационная система позволит осуществлять поиск информации по задаваемым критериям, получать отчеты о выполнении работ, предоставлять сведения по сотрудникам, заявкам, выполненным работам.
Глава 2. Проектная часть. Логическая структура базы данных и поисковые функции
2.1. Группы пользователей системы и распределенный доступ
Предполагается использование приложения несколькими группами пользователей и организация распределенного доступа для этих групп. Этими группами являются как сотрудники отдела легализации МИД РФ, так и заявители отдела, которые в свою очередь тоже могут подразделяться на группы, в зависимости от уровня доступа к ресурсам и данным системы. Так как для распределенного доступа необходима система регистрации и авторизации, то эта составляющая программного обеспечения представлена в системе будет реализована.
Предполагается, что в общем виде страницы создаваемого веб-приложения будут выглядеть следующим образом (рисунок 2.1).
На каждой такой странице, содержащей данные отдельной таблицы БД, реализованы операции удаления, обновления, добавления данных. Для этого предусмотрены кнопки «удалить», «обновить», «добавить».
Типовая схема процесса подачи заявки (заказа услуги) для заявителя, будет проходить в следующей последовательности:
- Посетитель (потенциальный заявитель) заходит на сайт организации для просмотра информации об услугах, перечне возможных истребованных документов, о ценах (если услуга платная).
- Если посетитель намерен сделать заказ-заявку, он регистрируется, с целью его дальнейшей авторизации и предоставления доступа в личный кабинет и соответствующим его статусу данным, в частности к оформленным заявкам, формам заполнения платежных данных. В дальнейшем, в личном кабинете он может отслеживать динамику прохождения заявки;
- Заявитель, как правило, отправляет заявку в письменном виде, а затем персонал отдела легализации МИД РФ проверяет данные и включает заявку в базу данных. В принципе разрабатываемая система позволяет заявителю оформить заявку онлайн. При этом заполнение заявки может дублироваться отправкой копии на электронный адрес персонала отдела легализации, который будет заниматься обработкой заявки (поэтому для системы не важно, кто оформляет заявку и заносит ее в базу данных – это вопрос выбора технологии прохождения заявок, а не возможностей системы).
- В дальнейшем, после согласования, заполнения формы заявки, возможна оплата через платежные системы интернет или наличными по факту предоставления истребуемого документа.
Таким образом, используя веб-приложение, заявитель может сократить количество очных посещений отдела легализации МИД РФ, с целью реализации его пожеланий, принимает решение о выборе того или иного варианта (или нескольких вариантов), подает заявку и контролирует результат его выполнения «не выходя из своего кабинета».
2.2. Технологическая последовательность работы с системой
Предполагается три основных этапа, три технологические последовательности работ:
- Инсталляция подсистемы аутентификации пользователей; генерация таблиц базы данных.
- Регистрация пользователей, в первую очередь заявителей. Наполнение базы данных.
- После этого система готова к штатной работе.
Подсистема аутентификации предназначена для регистрации пользователей, организации распределенного доступа к защищенным папкам, файлам компонентам системы и базе данных системы. Инсталляция системы очень проста. По сути, это само инсталляция, при которой сама подсистема создает все управляющие файлы. При инсталляции заносится только первоначальный логин и пароль администратора системы, чтобы он мог входить в панель управления подсистемы аутентификации. В дальнейшем, администратор может добавлять других администраторов, имеющих такие же права. В файлах подсистемы храниться информация о логинах и паролях пользователей, защищенных папках, данные о регистрации пользователей.
Кроме администратора предполагается две группы регистрируемых пользователей системы – заявителей и персонала отдела легализации МИД РФ. В настоящем прототипе системы предполагается, что персонал имеет доступ ко всем функциям и данным системы, хотя этот постулат можно изменить в зависимости от реально выполняемых функций каждым сотрудником. Регистрация пользователей происходит следующим образом. Во-первых, необходимо войти в систему. В настоящее время для входа в систему необходимо в адресной строке браузера набрать следующий адрес: http://www.diofant.com/Control_Clients_Mid/index.php
Появиться первая страница системы (далее еще будем говорить – веб-приложения или просто приложения). Необходимо кликнуть по пункту меню «Регистрация». Появится следующая для регистрации страница, где предусмотрена ссылка на начало регистрации. Регистрация подразумевает создание логина и пароля для дальнейшего входа в систему и занесения некоторых персональных данных. Регистрация займет определенное время. После заполнения форм регистрации, данные будут автоматически отправлены на адрес электронной почты администратора системы, который идентифицирует эти данные и подтвердит право на регистрацию в системе. После подтверждения регистрации, на указанный при заполнении форм адрес электронной почты будет отправлено подтверждающее сообщение с логином и паролем. В системе принято соглашение, что логином может быть, например ИНН или номер паспорта и т.д.
Рассмотрим формы и процедуру для регистрации заявителей. Для сотрудников вся процедура аналогична. Некоторые отличия существуют только в форме представления персональных данных. Представляются две формы для регистрации. Первая форма предназначена для регистрации логина и выбранного пользователем пароля и включает также поле для подтверждения выбранного пароля и адрес электронной почты.
После успешного прохождения этого шага в заполнении формы и нажатия клавиши «Далее» внизу формы, происходит переход к следующей форме регистрации, некоторых персональных данных о пользователе.
По персональным данным администратор системы, идентифицирует пользователя и решает, подтвердить или нет регистрацию пользователя, другими словами, «за кого он себя выдает», заявитель это или сотрудник.
После успешного прохождения второго шага в заполнении формы и нажатия клавиши «Регистрация» внизу формы, происходит переход к следующей форме – сообщению о том, что данные занесены верно и запрос на регистрацию отправлен администратору системы.
Данные пользователя автоматически отправляются администратору системы. Администратор системы получает на свой почтовый адрес сообщение в виде, изображенном на рисунке 2.2.
Администратор системы получает на свой почтовый адрес сообщение, идентифицирует пользователя. В настоящее время реализован вариант «ручной идентификации».
Если вы заявитель, а пытаетесь зарегистрироваться как сотрудник, то администратор системы вас не пропустит, и вы не будете зарегистрированы в системе. В дальнейшем возможно автоматическое распознавание и подтверждение регистрации, если существует база данных МИДа РФ и если произвести интеграцию с этой базой данных. Другими словами, если есть возможность такой интеграции, то при регистрации нет необходимости вводить персональные данные сотрудника, а достаточно зарегистрировать только логин и пароль для входа в систему и регистрация в системе будет проходить полностью в автоматическом режиме.
Для того чтобы подтвердить регистрацию пользователя, администратор просто кликает по ссылке, включенной в сообщение. После этого данные заносятся в подсистему аутентификации и на электронный адрес пользователя, который он указал в первой форме регистрации, отправляется сообщение о его успешной регистрации, а также зарегистрированный логин и пароль (тот, который он указал в первой форме регистрации, рисунок 2.3.)
В настоящем примере, для того, чтобы продемонстрировать процедуру регистрации и задействованные формы, использовался произвольный логин, но, по соглашениям программного обеспечения, необходимо заносить номер ИНН, или номер паспорта, или другой логин. После регистрации в системе, сотруднику необходимо занести данные заявителя в базу данных системы. Возможно также сопряжение подсистемы регистрации с базой данных системы. Тогда данные будут заноситься автоматически.
После регистрации заявителей и сотрудников можно приступать к штатной работе с системой. Вход в систему для заявителей и сотрудников происходит через кнопки меню «Сотрудник», «Заявитель» (в настоящей версии только для заявителей). После нажатия этих кнопок, появляется приглашение войти в систему для зарегистрированных пользователей со ссылкой для входа в систему и получения доступа. После нажатия ссылки появляется форма для авторизации пользователя с полями логина и пароля.
После авторизации клиентов и сотрудников можно приступать к штатной работе с системой.
2.3. Разработка функциональной модели
Анализ и описание некоторых бизнес-процессов отдела легализации МИД РФ. В разделе 1.2. было дано общее описание процессов работы отдела.
Метод структурного проектирования. Два типа моделей: IDEF0-диаграммы и диаграммы потоков данных (DFD, Data Flow Diagramming) обычно используются при решении задач функционального моделирования бизнес-процессов.
Диаграмма потоков данных отображает, как шаги бизнес-процесса, так и поток документов и управления. Кроме того на диаграмме можно отображать средства автоматизации шагов бизнес-процессов.
Диаграммы потоков данных DFD:
- это средство моделирования функциональных требований к проектируемой системе;
- разрабатываются с целью моделирования существующего движения информации;
- применяются для представления документооборота и обработки информации;
- используются как дополнительные модели к модели IDEFO с целью наглядного представления текущего документооборота и обмена информацией;
Диаграммы DFD дополняют то, что уже представлено в модели IDEF0, поскольку они описывают потоки данных, позволяют проследить движение и преобразование информации внутри системы, между процессами, а также между процессами с внешней информационным окружением.
DFD-диаграммы создавались как средство проектирования программных систем.
С помощью DFD-диаграмм требования к проектируемой информационной системы разбиваются на функциональные компоненты. Декомпозиции DFD-функций позволяет продемонстрировать, как каждый процесс преобразует свои входные данные в выходные. На схемах процесса отображаются:
- функции процесса;
- входящая и выходящая информация;
- внешние процессы, описанные на других диаграммах;
- точки разрыва при переходе на другие страницы.
При моделировании по методологии IDEF0 система рассматривается как сеть взаимосвязанных функций. При создании DFD-диаграммы система представляется совокупностью связанных функций, как совокупность сущностей (предметов).
Из сказанного выше, можно сделать выводы: при моделировании системы «как есть» оптимальным будет использование спецификации SADT, так как она традиционно применяется для моделирования процессов на предприятии;
- при построении модели системы «как должно быть» предпочтительнее использовать спецификации DFD. Данная методология дает больше преимуществ при проектировании информационной системы.
2.4. Логическая структура базы данных клиентов отдела легализации МИД РФ
При преобразовании объектов и атрибутов объекты переходят в таблицы Базы Данных заявителей, атрибуты объекта становятся атрибутами таблицы.
Структура базы данных в принципе может изменяться, но при этом все заголовки представлений таблиц на экране также должны синхронно меняться. Это не затрагивает существенным образом программного обеспечения, поддерживающего веб-приложение.
Взаимосвязь между таблицами можно проследить также на первой домашней странице настоящего приложения.
На этой странице умышленно выведены на экран первые строки таблиц, чтобы на примерах можно было увидеть смысл и типовое содержание столбцов.
Таблица 2.1. Объекты и атрибуты
| объект | атрибут | Ключ |
| 1_Clients | Client_Id — Код Client_Nm -Название Client_Adr — Адрес Client_Con — Контактное_Лицо Client_Ph — Телефон Client_Em — Электронный_Адр Client_Com — Примечания | Client_Id
|
| 2_Departments | Dep_Id — Код_Подразделения Dep_Nm -Название_Подразд Dep_Loc — Локализация Dep_Ph — Телефон Dep_Chief — ФИО Руководителя Dep_Com — Примечания | Dep_Id |
| 3_Groups | Gr_Id — Код(Номер)_Группы Gr_Nm — Наименование Gr_Loc — Локализация Gr_Ph — Телефон Gr_Chief — Руководитель Gr_Com — Примечания | Gr_Id |
| 4_ListZU | ZU_Id — Код (Номер) ЗУ ZU_Country — Страна ZU_Nm — Наименование ЗУ ZU_Address — Адрес ZU_Phone — Телефон Comm — Примечания | ZU_Id |
| Orders | Order_Id — Код_Заявки Client_Id — Код Order_Date — Дата_Заявки Ex_Date_Beg -Дата_Начала Ex_Date_End -Дата_Завершения Serv_Id — Код_Услуги Order_Qu — Количество Order_Pr — Цена Dep_Id — Код_Подразделения | Order_Id
|
| Payments | Pay_Id — Номер Pay_Date – Дата Client_Id — Код Order_Id — Код_Заявки Pay_Amt — Сумма | Pay_Id
|
| Services | Serv_Id — Код_Услуги Serv_Nm — Наименование Serv_Detail — Детализация Serv_1 — Еденица_Измерения Serv_Cost – Цена Serv_Com — Примечания | Serv_Id |
| Staff | Id_Empl — Код Сотрудника Empl_Nm — ФИО Сотрудника Empl_Post – Должность Empl_Sert – Сертификат/Дипл. Примечания | Id_Empl |
2.5. ER-модель базы данных Заявителей отдела легализации МИД РФ
Модель сущность-связь (англ. entity-relationship model, ERM, ER-модель) позволяет описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. ER-модель это формальная конструкция, не определяющая графических средств её представления. В качестве стандартного графического представления ER-модели, была разработана диаграмма сущность-связь ER-диаграмма (Entity Relationship Diagram – ER-диаграмма). При проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных.
Как известно, базовым понятием реляционных БД является таблица (отношение). Таблица используется для структуризации и хранения информации. В реляционных БД каждая ячейка таблицы содержит одно значение. Кроме того, внутри одной БД существуют взаимосвязи между таблицами, каждая из которых задает совместное пользование данными таблицы.
ER-диаграмма графически представляет структуру данных проектируемой БД. Сущности отображаются при помощи прямоугольников, таблиц, содержащих имя сущности – таблицы БД. Взаимосвязи сущностей отображаются в виде линий, соединяющих отдельные сущности.
Взаимосвязь показывает, что данные одной сущности ссылаются или связаны с данными другой.
Степень конца связи указывается графически, множественность связи изображается в виде «вилки» на конце связи. Модальность связи так же изображается графически — необязательность связи помечается кружком на конце связи. Именование связи выражается одним глаголом: «Имеет», «Принадлежит» и т. д. (WiKiPedia, рисунке 2.5).
Атрибуты сущности записываются внутри прямоугольника, изображающего сущность, и выражаются существительным в единственном числе.
Среди атрибутов выделяется ключ сущности. При создании сущности необходимо выделить группу атрибутов, которые могут быть первичным ключом, затем произвести отбор атрибутов для включения в состав первичного ключа:
- Первичный ключ должен быть подобран таким образом, чтобы по значениям атрибутов, в него включенных, можно было точно идентифицировать экземпляр сущности.
- Никакой из атрибутов первичного ключа не должен иметь нулевое значение.
- Значения атрибутов первичного ключа не должны меняться. Если значение изменилось, значит, это уже другой экземпляр сущности.
При выборе первичного ключа, как правило, в сущность вводится дополнительный атрибут, который становиться ключом. Так, для определения первичного ключа часто используют уникальные номера, которые могут автоматически генерироваться системой при добавлении экземпляра сущности в БД. Применение уникальных номеров облегчает процесс индексации и поиска в БД.
Первым шагом при создании логической модели БД является построение ER –диаграммы, состоящей из трех частей: сущностей, атрибутов и взаимосвязей.
Разработано множество инструментов визуального создания ER- диаграмм для различны платформ. В настоящем проекте использовалась разработка MySQL Workbench.
Этот инструмент упрощает проектирование баз данных и обслуживание, автоматизирует, отнимающие много времени и подверженные ошибкам задачи и улучшает связь среди команд разработчиков и архитекторами БД. Он позволяет архитекторам данных визуализировать требования, общаться с заинтересованными лицами по вопросам проектирования прежде, чем будут сделаны инвестиции в проект. Это обеспечивает управляемое моделью проектирование баз данных, которое является самой эффективной методологией для того, чтобы создать реальные и хорошо продуманные базы данных. ER-диаграмма базы данных организации (control_clients_mid) изображена на рисунке (рисунок 2.6). Две вертикальные черточки с одной стороны и «трезубец» с другой обозначают соответственно «связь один ко многим».
