Информационно-справочная система средней общеобразовательной школы

Отношения соответствуют третьей нормальной форме, если они находятся во 2NF и не содержат транзитивных зависимостей. Т.е. ни один неключевой атрибут не зависит от другого неключевого атрибута.

Данные отношения находится в 3NF. Проверку на соответствие форме Бойса-Кодда проводить не требуется, т.к. ключи не имеют общих атрибутов. Удаление, изменение или добавление любой строки таблицы не ведет к изменениям остальных строк - многозначные зависимости отсутствуют. Поэтому таблица находится в 4-ой НФ.

После нормализации всех таблиц была получена следующая схема данных (ErWin):

 

Рис. 2. Схема данных

Затем была произведена генерация  базы данных Interbase.

 

Серверная компонента комплекса должна представлять собой Windows-приложение.

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

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

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

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

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

- CLearnServerApp – реализует объект Windows приложения;

- CLearnServerDlg – реализует диалоговое окно сервера (Windows-окно).

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

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

Таким образом, диаграмма классов  сервера выглядит следующим образом:

 

Рис. 3. Диаграмма классов сервера

 

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

Была предложена следующая логика работы протокола:

- клиент отправляет серверу число, соответствующее ожидаемому клиентом от сервера действию;

-  сервер посредством управляющей структуры «switch-case» пытается обнаружить обработчик соответствующего сообщения (сообщения с соответствующим кодом);

- если обработчик не найден, то ничего не происходит и сервер ожидает дальнейших действий от клиента;

- если обработчик найден, то далее возможно несколько вариантов:

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

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

- клиент хочет получить данные: в этом случае сервер осуществляет выборку требуемых данных и отправляет их в формате тех же структур (одна структура – одна запись таблицы) клиенту. Отправка информация осуществляется последовательно, запись за записью. Прием каждой порции информации клиент должен подтвердить. Признаком окончания передачи данных сервером служит отправка клиенту структуры с установленным в -1 полем кода записи.

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

- информация об изучаемых в школе предметах:

struct Subjs

{int sCode; char sName[50];};

Содержит следующие  поля:

- код предмета (sCode);

- название предмета (sName).

- информация о родителях учеников:

struct Parents

{int Code; char ChildName[50]; char FIO[50]; char Comment[50]; char Phone[50]; char BDate[50];};

Содержит следующие поля:

- код родителя (Code);

- имя ребенка (ChildName);

- имя родителя (FIO);

- дополнительная информация о родителе (Comment);

- контактный телефон родителя (Phone);

- дата рождения родителя (BDate).

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

Использование структур значительно  проще и более оправдано в случае простого протокола.

Приведем блок-схему обобщенного  алгоритма работы серверной части комплекса:

Рис. 4. Блок-схемы обобщенного алгоритма работы серверной части комплекса

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

- пользователь осуществляет запуск компоненты-сервера;

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

- если соединение установить не удалось, то выдается сообщение об ошибке и сервер завершает работу;

- сервер пытается создать серверный («слушающий») сокет;

- если создание сокета привело к ошибке, то сервер выдает сообщение об ошибке и завершает работы;

- сервер в бесконечном цикле ожидает подключения клиентов к серверному сокету («accept»);

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

Функция потока, обслуживающего подключенного  к серверу клиента, работает по следующему алгоритму:

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

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

- в противном случае при помощи конструкции «switch-case» осуществляется поиск обработчика сообщения с соответствующим кодом;

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

- поток ожидает получения очередного кода сообщения.

 

Клиентские части комплекса  должны представлять собой Windows-приложения.

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

- клиенты будут работать с данными посредством окон представления списков (List views) и диалогов (CDialog). Элементы управления для работы с записями таблиц БД будут расположены непосредственно там, где отображаются данные, что упрощает понимание логики работы программы, поэтому использование меню, нескольких представлений для отображения данных, панелей инструментов не требуется. Основным требованием к пользовательскому интерфейсу клиентских приложений является его простота и понятность.

- клиентские приложения будут работать с удаленными данными, поэтому не имеет особого смысла следовать концепциям SDI/MDI, разнося по различным уровням работы с данными их представление, хранение и обработку.

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

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

- CLearnChildApp – реализует объект Windows приложения;

- CLearnChildDlg – реализует диалоговое окно клиента (Windows-окно).

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

Наиболее простым для понимания  и реализации в данной ситуации является использование блокнота свойств (tabbed pane). Его вкладки (property sheets) позволяют легко разделить представление данных комплекса.

Каждая вкладка блокнота страниц  свойств должна быть производным  классом от класса CDialog.

Необходимо реализовать следующие  классы страниц свойств:

- CPage01 – отвечает за просмотр и редактирование сведений об оценках учеников;

- CPage02 – отвечает за просмотр и редактирование учебных планов (списки изучаемых предметов по классам и годам обучения);

- CPage03 – отвечает за формирование отчетов по успеваемости учеников;

- CPage04 – отвечает за просмотр и редактирование информации об учащихся;

- CPage05 – отвечает за просмотр и редактирование информации о родителях учащихся;

- CPage06 – отвечает за просмотр и редактирование информации о классах школы;

- CPage07 – отвечает за просмотр и редактирование информации об изучаемых в школе предметах;

- CPage08 - отвечает за просмотр и редактирование информации информации о социальных группах учащихся;

- CPage09 - отвечает за просмотр и редактирование информации о физкультурных группах;

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

Каждая из страниц свойств должна обладать методами, отвечающими за:

- вызов диалога для добавления новой записи в соответствующую таблицу;

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

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

Каждый из этих методов должен иметь  префикс OnAdd, OnEdit и OnDel, соответственно.

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

Перечислим, например, некоторые такие  классы:

- CAddRangeDlg – отвечает за редактирование и добавление сведений об оценках учащихся, вызывается классом CPage01;

- CAddParentDlg – отвечает за редактирование и добавление сведений о родителях учащихся, вызывается классом CPage05 и т.д.

Каждый из этих классов должен реализовывать  следующие методы:

- DoDataExchange – отвечает за привязку переменных класса к элементам управления диалога;

- OnInitDialog – отвечает за инициализацию элементов управления диалога (добавление заголовков столбцов списков, установка начальных значений в комбинированных списках и т.п.) и выборку начальных данных для работы с диалогом (данные справочников);

- OnOKEdit – отвечает за подтверждение сделанных пользователем изменений в ходе работы с диалогом (добавление внесенных данных или изменение редактируемой записи);

- OnCancelEdit – отвечает за закрытие диалога без сохранения добавляемых или отредактированных данных.

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

 

Обоснование выбора языка и среды программирования

 

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

- функции ввода и отображения данных (Presentation Logic);

- прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);

- функции обработки данных внутри приложения (Database Logic);

- функции управления информационными ресурсами (Database Manager System);

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

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

- распределенная презентация (Distribution presentation, DP);

- удаленная презентация (Remote Presentation, RP);

- распределенная бизнес-логика (Remote business logic, RBL);

- распределенное управление данными (Distributed data management, DDM);

- удаленное управление данными (Remote data management, RDA).

 

Рис. 5. Модели распределения

 

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