Файл: Применение средств создания серверного программного обеспечения ( АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К ИНФОРМАЦИОННОЙ СИСТЕМЕ ).pdf
Добавлен: 28.03.2023
Просмотров: 763
Скачиваний: 3
СОДЕРЖАНИЕ
1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К ИНФОРМАЦИОННОЙ СИСТЕМЕ
1.2 АНАЛИЗ СУЩЕСТВУЮЩЕЙ ОРГАНИЗАЦИИ БИЗНЕС (ПРИКЛАДНЫХ) И ИНФОРМАЦИОННЫХ ПРОЦЕССОВ
1.3 ПОСТАНОВКА ЗАДАЧИ АВТОМАТИЗАЦИИ БИЗНЕС-ПРОЦЕССОВ
2 ПРОЕКТ АВТОМАТИЗАЦИИ ПРОЦЕССОВ В ОБРАЗОВАТЕЛЬНОМ УЧРЕЖДЕНИИ
2.1 ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ
2.4 ТЕХНОЛОГИЧЕСКОЕ ОБЕСПЕЧЕНИЕ
Чтобы начать работу с пользователями, прежде всего нужно зарегистрировать их в системе, дать соответствующий уровень доступа к базе данных и совершить обработку поступающих от них запросов. Для этой цели могут быть использованы следующие входные данные:
- имя пользователя;
- пароль;
- исходная база данных;
- запросы пользователя.
После того как пользователь отправит запрос базе, а та его выполнит, может произойти либо изменение содержимого базы (например, редактирование уже существующей новости, или добавление новой), либо пользователь просто получит необходимую ему информацию от системы (результат своих запросов). Отсюда следует, что у системы будут такие выходные данные:
- измененная база данных;
- результат запросов.
Сам механизм обработки запросов осуществляется через локальный сервер системы под контролем технического специалиста. Определившись с моделью системы, нарисуем контекстную диаграмму (Рисунок 4).
Рисунок 4 – Контекстная диаграмма системы[4]
Перейдем к декомпозиции этой модели. Предметом декомпозиции будет последовательность системы в работе с пользователем:
- определить какой у пользователя уровень доступа к системе;
- предоставить соответствующие полномочия;
- обратиться к системе;
- внести изменения в базу данных, если таковые были.
В итоге получится следующая диаграмма (рисунок 5).
Рисунок 5 – Декомпозиция обслуживания пользователя системы[5]
Теперь поочередно декомпозируем элементы получившийся диаграммы. Вначале устанавливается уровень доступа к системе через определение к какой категории относится пользователь. Введенное пользователем имя сверяется со списком имен в базе данных, а затем указывает на категорию к которой относится тот или иной пользователь системы. Эта категория в дальнейшем будет определять какими полномочиями будет обладать пользователь. Через объединение данных о полномочиях и уровне доступа к системе, мы создаем определенный список разрешенных пользователю действий. В итоге декомпозиция определения уровня доступа выглядит следующим образом (рисунок 6).
Рисунок 6 – Декомпозиция определения уровня доступа[6]
После того как пользователь прошел проверку на доступ к системе в соответствии со своей категорией, система начинает обработку его запросов. Следующим нашим шагом будет декомпозиция обработки запроса пользователя. Тут включается в работу база данных, которая уже импортирована в систему и подключена через локальный сервер. Дальнейшие действия будут выглядеть так:
- открыть доступ к базе данных;
- выполнить запросы;
- показать результат запросов.
На следующей диаграмме показан процесс обработки запросов и выдача результатов (рисунок 7).
Рисунок 7 – Декомпозиция обработки запроса[7]
Теперь составим спецификацию функциональных требований к информационной системе. У системы будет всего два типа пользователей: гость и системный администратор. У гостя может быть всего один основной сценарий - возможность отправить запрос на просмотр новостей, которые в итоге отобразятся на странице информационной системы. Сценарий просмотра новостей осуществляется за счет отправки запроса базе данных. В системе будет отдельная страница, которая как агрегатор показывает последние новости о курсах шитья в порядке даты публикации [22]. Вместо полного текста новости, отображается короткое описание и превью. После клика по превью пользователь попадает на страницу с самой новостью.
Администратор имеет еще два дополнительных сценария: редактирование и удаление новости. Оба сценария осуществляются с помощью взаимодействия с базой данных, которая подключается к информационной системе через локальный сервер. В итоге мы получаем схему функциональных требований к информационной системе (рисунок 8).
Рисунок 8 – Схема функциональных требований[8]
Требования к программно-технической среде администратора не сильно велики. В качестве языков разметки были выбраны html и css. Для взаимодействия с серверной частью используется PHP [23]. В качестве СУБД используется MySQL [24]. Вся разработка происходит на операционной системе Windows 10. Для написания и редактирования всего программного кода используется бесплатный редактор Atom с открытым исходным кодом. В качестве локального сервера выступает Open Server Panel, он позволяет настраивать и администрировать компоненты клиентской части информационной системы, а также включает в себя другой инструмент, которым я пользуюсь во время разработки – phpMyAdmin. Через phpMyAdmin создается база данных с таблицами, которая интегрируется в новую информационную систему для работы модуля Новостей. Результат программной разработки тестируется на интернет-браузере Google Chrome, версии 69.0.3497.100.
Требования для гостей еще ниже. Они нуждаются в минимуме компьютерных мощностей, которые присутствуют в любом современном девайсе. Рекомендуется использовать наиболее распространенные версии операционных систем для ПК:
- Windows:
- MacOS;
- Linux.
У смартфонов к таким операционным системам относятся:
- IOS;
- Android.
Помимо этого, пользователю необходим доступ в интернет и браузер, желательно последней версии.
После разработки, обновленная информационная система должна успевать загружать страницы не дольше чем за три секунды. Информационная безопасность базы данных сводится к защите логином и паролем для администратора. Гости не имеют функции входа в систему и проектировать защиту для этой группы нет необходимости.
2 ПРОЕКТ АВТОМАТИЗАЦИИ ПРОЦЕССОВ В ОБРАЗОВАТЕЛЬНОМ УЧРЕЖДЕНИИ
2.1 ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ
Составим Инфологическую ER-модель нашей базы данных. Главная цель такого моделирования – естественный для работника способ обработки и представления информации, которую он собирается хранить в базе. Главные части модели составляют сущности, а затем идут связи между ними и атрибуты.
Проектируемая нами система должна хранить статьи на тематику курсов и второстепенные параметры этих статей. Всего в базе будет семь ячеек для заполнения:
- id статьи;
- заголовок статьи;
- метатег description для поисковых роботов;
- метатег keywords для поисковых роботов;
- дата написания статьи;
- краткое описание для превью;
- полный текст статьи.
Выделим все основные сущности в перечисленном списке и проанализируем их:
- статья;
- метатеги;
- дата;
- id.
Уже сейчас можно выделить две главные сущности: Статья и Метатеги. Сразу же приходит на ум простая связь между сущностями – Статья имеет несколько метатегов, а метатеги прописываются каждой статье. Очевидная связь один-ко-многим. Первоначальный вариант ER-модели будет таким (Рисунок 9).
Рисунок 9 – ER-модель один-ко-многим[9]
Обратите внимание на знаки по обе стороны связи. Таким образом устанавливается количественное отношение между сущностями. Мы знаем, что каждая статья имеет свой уникальный id. Так же у любой статьи есть дата, которая вовсе не уникальна, ведь за день может выйти несколько публикаций. Исходя из этого, расширим модель дополнительными сущностями (Рисунок 10).
Рисунок 10 – Полная ER-модель системы[10]
Даталогическая модель представляет из себя схему взаимосвязей между параметрами базы данных и их содержанием. Даталогическая модель описывается при помощи информационных единиц, которые используются в отдельно взятой СУБД. Все параметры в нашей базе данных строятся следующим образом (Таблица 2):
Таблица 2 – Параметры и их тип[11]
|
№ |
Имя |
Тип |
Комментарий |
|
1 |
Id |
int(11) |
ID статьи |
|
2 |
Title |
varchar(255) |
Заголовок статьи |
|
3 |
Description |
varchar(255) |
Метатег description для поисковых роботов |
|
4 |
Keywords |
varchar(255) |
Метатег keywords для поисковых роботов |
|
5 |
Preview |
text |
Краткое описание статьи для превью |
|
6 |
Text |
text |
Полный текст статьи |
|
7 |
Data |
date |
Дата написания статьи |
Их схема взаимосвязей (Рисунок 11).
Рисунок 11 – Даталогическая модель[12]
Рассмотрим экранные формы этих типов данных. Такие поля могут содержать не только область для заполнения текстом, но другие способы ввода информации:
- переключатели;
- кнопки;
- выпадающее меню;
- календарь.
В нашем случае формы тоже имеют разные способы заполнения (Таблица 1).
Таблица 1 – Экранные формы[13]
|
№ |
Имя |
Тип |
|
1 |
Id |
Число |
|
2 |
Title |
Текст |
|
3 |
Description |
Текст |
|
4 |
Keywords |
Текст |
|
5 |
Preview |
Текст |
|
6 |
Text |
Текст |
|
7 |
Data |
Выбор из выпадающего календаря |
Во время заполнения текстовых полей, используется нормативно-справочная информация для языка HTML [17]. Язык определяет способ оформления текста, ссылок, вставки изображений, а также другие методы разметки статьи. На момент заполнения форм, пользователю видные все теги языка. Тем не менее, на стороне клиентской части информационной системы теги преобразуют текст в задуманный стиль и не будут видны пользователю. На странице нормативно-справочной информации содержатся такие данные как:
- список атрибутов;
- функции атрибутов;
- имя атрибута;
- элементы атрибута;
- описание атрибута.
После заполнения всех форм, необходимо нажать кнопку подтверждения, тем самым создав выходной документ – новую статью. Статья появится в базе и автоматически станет доступна в системе другим посетителям.
2.2 ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
Структура программного обеспечения клиент-серверной информационной системы состоит из трех категорий. Первая категория – это программное обеспечение, необходимое для написания кода клиентской части системы. Вторая категория отвечает за поддержку базы данных. Третья категория нужна нам чтобы обеспечить SEO оптимизацию.
Первыми идут инструменты для разработки клиентской части системы. Состав программ первой категории выглядит следующим образом:
- atom – текстовый редактор для написания кода программирования или зыков разметки. Имеет открытые исходники. В редактор можно добавлять персональные плагины [25];
- google chrome – основная среда для тестирования результатов изменения в коде. Используется версия 9.0.3497.100.
Вторая категория программ для СУБД:
- open server – серверная среда, для настройки и администрирования различных компонентов системы. Применятся для запуска локальных сетей на персональных компьютерах [11];
- phpMyAdmin – инструмент, необходимый для управления базами данных и их таблицами MySQL. Нужен в основном для работы с СУБД [10].
Третья категория программного обеспечения для SEO в основном состоит из сторонних веб-сервисов и не требует установки на персональный компьютер:
- liveInternet – рейтинг сайтов и подсчет статистики. Инструмент необходим для учета уникальных посетителей сайта;
- google аналитика – интернет-сервис от Google для веб-мастеров, цель которого заключается в анализе поведения пользователей на сайте. Инструмент дает подсказки администраторам, с помощью которых можно повысить рейтинг сайта в поисковой системе [27];
- яндекс метрика – тот же самый интернет-сервис, только от Yandex [28].