3.3Результаты обзора
Значительная часть решений, описанных в обзоре, предоставляет возможности для составления учебного плана и контроля его выполнения, автоматического и ручного составления расписания, ведения текущего расписания, публикации и подготовки расписания к печати и выполнения других важных задач управления расписанием.Несмотря на это, ни одно из рассмотренных решений не обладает необходимой возможностью указывать произвольное число учеников и учебных групп для одного занятия.
Хотя некоторые решения позволяют объединять классы в параллели и разделять их на группы, их функциональности недостаточно для представления структуры расписания Школы. Тоже самое можно сказать и о возможностях верстки и форматирования расписания.
Большинство решений являются программами, предназначенными для работы на настольных компьютерах под управлением операционной системы MicrosoftWindows, то есть работа с этими программами с помощью планшетного компьютера невозможна. Также это означает, что доступ и работа с данными с различных компьютеров с помощью интернета могут быть невозможными или ограниченными.
Отдельно стоит отметить информационную систему «Профиль», авторы которой заявляют о возможности составления индивидуальных учебных планов. Такая возможность существует, но при этом в системе нет возможности создавать индивидуальные занятия.
Из всех рассмотренных решений наибольшее количество релевантной функциональности есть в системе LantivSchedulingStudio. Эта система значительно гибче, чем большинство аналогов, и позволяет создавать индивидуальные занятия и занятия с произвольным временем проведения. Тем не менее, ее возможностей недостаточно для точного учета выполнения учебного плана.
В результате обзора можно заключить, что подавляющее большинство существующих решений предназначены для работы с классно-урочной системой, а значит, не удовлетворяют требованиям, описанным в разделе 2.7, и не соответствуют особенностям структуры расписания и организации учебного процесса в Школе.
Это делает оправданным проектирование и разработку новой автоматизированной информационной системы управления расписанием, которая будет отвечать упомянутым выше требованиям.
4Проектирование, разработка и развертывание
4.1Архитектура системы
Проектирование информационной системы начинается с разработки ее архитектуры.
Согласно стандарту IEEE 1471[21], архитектура - это «фундаментальная организация системы, реализованная в ее компонентах, связях этих компонентов друг с другом и внешней средой и принципах, определяющих структуру и развитие системы».
Решения, принятые на этапе проектирования архитектуры очень сложно изменить в будущем. Это значит, что архитектура должна быть спроектирована в самом начале работы над системой, то естькак раз в то время, когда разработчик знает меньше всего о будущей системе. Таким образом, решения, связанные с выбором архитектуры проекта являются самыми ответственными во всем ходе работы над проектом.
Частично снизить риск и последствия ошибки на этом этапе может выбор максимально гибкой и универсальной архитектуры, такой, которая позволит отложить большинство решений до более поздних стадий разработки, либо поменять их в будущем.
С учетом вышеописанных соображений и в соответствии с итеративным подходом к разработке системы (описанным в разделе 1.4.1), на данном этапе были сформулированы только самые общие компоненты архитектуры.
Проектирование архитектуры основывалось на следующих требованиях и особенностях предметной области, сформулированных в главе 2:
Основная задача системы – предоставлять пользователю возможность работать (вносить, изменять, просматривать) с определенными данными.
Система должна быть кроссплатформенной, то есть иметь возможность работать более чем на одной аппаратной платформе и/или операционной системе. Основные поддерживаемые платформы: настольные компьютеры под управлением семейств ОС Windows, MacOSили Linuxпоследних версий, а также планшетные компьютеры под управлением OCAndroidи iOS.
Система должна предоставлять доступ к общему набору данных с различных устройств. Обеспечение возможности одновременного редактирования данных несколькими пользователями не требуется.
Система не должна зависеть отпостоянного соединения с интернетом.
Приложение В содержит диаграмму архитектуры системы.
Для данного проекта можно выделить три основных компонента системы:
хранилище данных, отвечающее за постоянное хранение всех данных, с которыми работает система;
«бизнес-логика», или логика предметной области, – компонент, отвечающий за реализацию модели данных (описанной в главе 4.2);
пользовательский интерфейс (графический), отвечающий за взаимодействие с пользователем.
Такое деление на компоненты является достаточно гибким, так как в принципе позволяет заменить реализацию одного из компонентов без необходимости внесения значительных изменений в остальные компоненты. Кроме того, оно реализует разделение ответственности между компонентами, разделяя между собой данные, их представление и способ их хранения. Это позволяет, например, сделать несколько версий приложения с разным интерфейсом (например, для разных устройств) не дублируя бизнес-логику или использовать разные хранилища данных, например, локальное и удаленное.
В начале работы над проектом рассматривалось несколько вариантов построения системы, которые в ходе дальнейшей работы были признаны неподходящими:
Классическое веб-приложение, в котором за бизнес-логику и хранение данных отвечает серверная часть, а интерфейс реализует клиентская часть, работающая в веб-браузере.Недостатком такой архитектуры является полная зависимость от подключения к интернету, что нарушает одно из основных требований к системе.
Настольное приложение, которое объединяет в себе все три компонента, используя файлы для постоянного хранения данных. С этим вариантом также связано несколько проблем в области реализации, а именно, сложность достижения кроссплатформенности, а также необходимость организовывать синхронизацию данных сторонними средствами, что увеличивает объем необходимой технической поддержки.
Для каждого из этих вариантов рассматривались возможные технологии реализации (подробнее в разделе4.3.6), после чего первые разработки системы были сделаны в виде классического веб-приложения. Вскоре после этого недостатки такого решения стали очевидны, и проект был переведен на похожую архитектуру, удовлетворяющую всем требованиям:
Автономное веб-приложение(offlineweb-application) с сервером для синхронизации данных.Такое приложение полностью работает в веб-браузере, и хранит данные в нем же. При этом для хранения «главной» копии данных и их синхронизации используетсяотдельный сервер. Соединение с интернетом необходимо для первого запуска приложения и синхронизации данных. Это возможно благодаря относительно новым технологиям, доступным в большинстве современных браузеров, в частности технологии офлайн-приложений [12], являющейся частью стандарта HTML5.
Такая архитектура сохраняет кроссплатформенность классических веб-приложений, не зависит от постоянного соединения с интернетом, но несколько ограничивает выбор средств реализации.
Кроме того, реализация системы в виде веб-приложения дает возможность распространять систему по модели SaaS (softwareasaservice– программное обеспечение как услуга), что упрощает установку, обновление и техническую поддержку системы. Стоит отметить, что хотя, строго говоря, автономное веб-приложение не полностью отвечает определению модели SaaS [23], оно все равно сохраняет большинство преимуществ этой модели.
|
