Этап проектирования является одним из наиболее важных этапов разработки информационной системы. Данный этап подразумевает «проектирование объектов данных, которые будут реализованы в базе данных; проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным; учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.» [3].
В качестве средства проектирования, определения целей и задач создания информационной системы является, без сомнения, унифицированный язык моделирования – UML.
Проанализировав особенности предметной области, для формирования требований к информационной системе «Расписание занятий вуза» [1] предлагаем следующую диаграмму вариантов использования (см. рис. 1).
Для дальнейшего проектирования мы предлагаем следующие диаграммы последовательности, которые, на наш взгляд, лучше всего отражают потоки событий в рамках соответствующих вариантов использования. Так, диаграмма последовательности действий студента изображена на рис. 2. Диаграмма последовательности действий преподавателя отличается от данной диаграммы только запрашиваемой информацией – для преподавателя важно именно его расписание, а не расписание по какой-либо студенческой группе. Данные пользователи информационной системы будут получать данные с сайта вуза со страницы, написанной на PHP.
Диаграмма последовательности действий сотрудника учебного управления, занимающегося заполнением и редактированием расписания, изображена на рис. 3. Эти сотрудники будут работать с единой базой данных расписания вуза, хранящейся на сервере (серверах) при помощи программы-клиента, написанной на языке Java. При этом очень важно исключить возможные коллизии одновременного доступа к общей базе данных разными сотрудниками, такие как взаимные блокировки, дедлоки и т.п. Возможные варианты решения это использование политик безопасности системы управления базами данных или встроенных механизмов выбранного языка программирования. Выбор конкретного решения можно сделать на этапе реализации информационной системы «Расписание занятий вуза».
При изменении расписания важно учитывать тот факт, что множественный ввод некорректных значений в случае проверки только на сервере может увеличить нагрузку на сеть. Однако проверка на соответствие в пределах программы не может гарантировать отсутствие конфликтов в расписании в виду того, что информация, полученная с сервера, устаревает. Как видно из рис. 3, планируется совершать две последовательные проверки.
Рис. 1. Диаграмма вариантов использования
Рис. 2. Диаграмма последовательности действий информационной системы и студента
Рис. 3. Диаграмма последовательности действий информационной системы и сотрудника учебного управления
Для создания базы данных была разработана следующая диаграмма классов, на которой изображены классы: преподаватель (Teacher), преподаваемая дисциплина (Subject), служебный класс для составления расписания звонков (Bell), кабинет для проведения занятий (Classroom), тип пары (лекция, лабораторная и т.д.) (TypeClasses), факультет (Depart), группа (Group), служебный класс для хранения дней недели (Day) и главный класс, отображающий записи из основной таблицы (Classes). В основной таблице хранится информация о каждой паре, которая проводится в вузе.
Как показывает практика, большинство сайтов вузов создано на хостингах с предустановленной системой управления базами данных MySQL. Она бесплатна и достаточно функциональна. Объем данных для работы системы составления расписания не слишком велик. Именно эти обстоятельства мы и предлагаем учитывать при выборе СУБД для хранения данных информационной системы «Расписание занятий вуза».
Рис. 4. Диаграмма классов для информационной системы «Расписание занятий вуза»
Инструментальное средство StarUML [4] (бесплатную актуальную русифицированную версию 5.0.2.1570 можно скачать по адресу https://staruml.soft32.com/) имеет в своём арсенале механизмы автоматической генерации кодов программ (в том числе и на языке Java), которые в дальнейшем могут быть адаптированы под конкретную реализацию и интерфейс системы.
При использовании механизма генерации по диаграмме классов на рис. 4 может быть сгенерирован псевдокод (описание классов без указания типов полей в них), либо классы, в которых все поля имеют тип Object. Для генерации кода системы укажем в диаграмме типы данных для каждого поля класса. Для базы данных, в виду её реляционной структуры, все идентификаторы хранятся как числа, а в каждой записи таблицы Classes хранятся идентификаторы соответствующих записей в таблицах Group (идентификатор groupID), Day (идентификатор dayID), TypeClasses (идентификатор typeClassesID), Bell (numberClasses) и др.
Для Java, как объектно-ориентированного языка программирования, корректнее хранить в полях groupID, dayID и др. ссылки на соответствующие объекты.
Таким образом, диаграмма классов с учетом типов в Java будет выглядеть так, как показано на рис. 5.
На рис. 6 изображен код класса Classes после генерации кода средствами StarUML.
Рис. 5. Диаграмма классов (с типами Java) для системы «Расписание занятий вуза»
Рис. 6. Сгенерированный код класса Classes для языка программирования Java.