Методическое обеспечение ис

1. Модель ИС

На стадии анализа и проектирования системы построена функциональная модель потоков данных ИС. Функциональная модель «Учет достижений студента» описана с помощью диаграммы потоков данных (DFD), которая является основным средством моделирования функциональных требований проектируемой системы. При помощи диаграмм потоков данных эти требования разбиваются на функциональные компоненты и представляются в виде сети, связанной потоками данных.

Главные цели модели – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, выявить отношения между этими процессами. Функциональная модель ИС представлена на (рис. 2).

На стадии проектирования БД построили логическую и физическую модели данных.

2. Требования к точности, размерности и форматам представления данных

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

Размерность и формат вводимых данных должен соответствовать определениям типов полей в БД.

3. Информационная база ИС

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

С другой стороны процесс построения БД является весьма трудоемким, так как содержит большое количество этапов:

• изучение предметной области и, на основании этого, выделение сущностей;

• определение связей между сущностями;

• определение атрибутов сущностей, выделенных на первом этапе;

• среди атрибутов сущностей выделение первичных ключей;

• построение логической модели;

• построение физической модели.

4. Функциональная модель данных ИС

При построении функциональной модели изучила и проанализировала предметную область электронного портфолио. Функциональная модель системы приведена «как будет» показана на (рис. 2).

Рисунок 2 – Функциональная модель DFD – «как будет» (системный уровень)

5. Логическая модель данных ИС

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

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

Построение логической модели системы выполнено в ERWin 7.3.

При построении использована нотация IDEF1X. Логическая модель данных представлена на (рис. 3).

Рисунок 3 – Логическая модель данных

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

Таблица 2 – Сущности логической модели данных

6. Физическая модель данных ИС

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

Для реализации БД выбрала СУБД MySQL. На физической модели данных представлено 7 таблиц.

Спецификация таблиц представлена ниже в таблицах 3 и 4.

Функция обеспечения целостности данных на уровне СУБД осуществляется средствами:

• целостность сущностей (Primary Key);

• обязательные данные (Not Null);

• уникальные значения (Identity);

• ограничения для доменов (Check).

Физическая модель данных представлена на (рис. 4).

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

Таблица 3 – Спецификация таблиц БД

Таблица 4 – Спецификация таблиц БД

4. Описание используемых процедур и функций (листинг кода)

Аутентификация пользователей при входе в подсистему.

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

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

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

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

Ниже представлен листинг с кодом авторизации пользователя в системе на (рис.5).

После ввода данных имени и пароля в форму идет проверка в базе данных, правильно ли введены данные имени, пароля, есть ли данный пользователь, данный листинг кода представлен на (рис.6).

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

Рисунок 6 – Листинг «Проверка на авторизацию пользователя в системе»

Если пользователь не зарегистрирован, он проходит регистрацию в системе. Для этого он вводит свое имя, можно логин использовать, e-mail и пароль и регистрируется. Регистрация нужна для того, чтобы пользователь смог сохраниться в системе и войти в нее. Данный листинг кода представлен на (рис.7).

Рисунок 7 – Листинг «Регистрация пользователя в системе»

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

Рисунок 8 – Листинг «Подключение к базе данных»

Рисунок 9 – Листинг «Вывод данных из БД в систему электронного портфолио»

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

Если нужно какие-либо данные отредактировать, исправить снова обращаемся с запросом на изменение данных к базе данных. Если все введено правильно, данные все введены, такого студента нет в БД, идет успешное сохранение данных. Данный листинг код представлен на (рис.10).

Рисунок 10 –Листинг «Редактирование и сохранение измененных данных студента»

Так в системе у нас есть файлы, нужно прописать функцию загрузки файла на сервер (см. рис. 11).

Рисунок 11 – Листинг «Загрузка файла в базу данных системы»

В какой то момент информация о студенте или его личных данных может стать не актуальной и устареть, тогда мы удаляем эти данные (см. рис.12).

Рисунок 12 – Листинг «Удаление данных из базы данных»

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

Рисунок 13 – Листинг «Вход в аккаунт администратора»

Рисунок 14 – Листинг «Описание функций администратора»

Далее напишем код парсера или синтаксический анализатор , который часть программы, преобразует в входные данные (как правило, текст) в структурированный формат (рис.15).

Рисунок 15 – Листинг «Скрипт алгоритма работы парсера»